|
Submitted Change Requests |
| Date | March 7, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | detailed design / phil
user manual / phil |
| Proposed Change | Save all data in our 3 text panes to a log on exit ( 3 logs? ) |
| Rationale | Jonathan needs the logs in order to complete/create his tests. Will be useful in analysing whether or not a test is effective/works and what the results are (pass, fail, kinda). |
| Impacts | |
| Change Control Board's Decision | (March 8) ACCEPTED
Done. |
| Date | Feb 25, 2001 |
| Name | Mike Power |
| Work Product / Admin | user manual / phil |
| Proposed Change | One of the menu's probably test needs to have a check box or toggle or something to display the Component View. This checkbox or toggle should probablty be disabled while there is no instantiated object and while that object is not derived from type Component |
| Rationale | Right now the Component View only comes up when the user first Instantiates a class. If the user clicks the x the Component View forever goes away. |
| Impacts | This would mean the creation of a new Action and also I would like to change the syntax of the setComponentPreview so that it sets a boolean. |
| Change Control Board's Decision | Add a view in menubar, component preview becomes viewable anytime.
Rejected. |
| Date | Feb 25, 2001 |
| Name | Mike Power |
| Work Product / Admin | user manual / phil |
| Proposed Change | That ParameterData's objects that represent a primitive type output the value of that object rather than the user defined name. |
| Rationale | In the fields panel when a user clicks on the name button to get the value of the field. A new ParameterData is created with the name of the field and the value of the field. The new ParameterData is then selected in the ParameterObjectComboBox. The result is the name of the field being repeated twice. The second time under the value column which is suppose to tell the user what the value is. |
| Impacts | The ParameterData would have to do an if(isPrimitive) and output different strings depending on the result of the if |
| Change Control Board's Decision | Defect, doesn't match the prototype. |
| Date | Feb 22, 2001 |
| Name | Mike Hebron |
| Work Product / Admin | detailed design / phil
user manual / phil |
| Proposed Change | If a user tries to instantiate a main test class or test data item -object type, the instantiateclassdialog that pops up should just list one 'default' constructor, like "NameOfClass()" |
| Rationale | currently, the dialog just crashes if it tries to show non-existent constructors. this is bad. if we don't show an instantiate class dialog, we still need some way for the user to name the new class he wants to instantiate. this can be done with a simple JOptionPane dialog, but the consistency of having the InstantiateClassDialog be the place where you name a new object is lost. |
| Impacts | 1. instantiateclassdialog constructor needs modification (test for
0-length array of constructors) 2. etamainmodel.addparameterdata and etamainmodel.instantiateclass need
3. user manual needs short notes to document this behavior when trying
|
| Change Control Board's Decision | Assigned to Mike H. |
| Date | Feb 21, 2001 |
| Name | Mike Power |
| Work Product / Admin | Detailed Design / Phil |
| Proposed Change | Put each of the following components in a SplitPane; MethodPane, FieldPane, ObjectPool, and StatusPane. A SplitPane will allow the user to resize the different components as he sees fit. |
| Rationale | The current implementation can cause components to have all of their space shoved off the screen. Most commonly the StatusPane is squished to death. It will be easier to use SplitPanes then trying to figure out why GridBagLayout is squishing them and how to fix it. |
| Impacts | An earlier attempt at this ended in frustrated. It will take a person some time to research how to setup the splitpanes appropriately. |
| Change Control Board's Decision | Mike H. researched it and it has been resolved that we will use
splitpanes after all.
Done. |
| Date | Feb 15, 2001 |
| Name | Mike Power |
| Work Product / Admin | ETAMainModel |
| Proposed Change | New parameter inside InstantiateClass, replacing "testmain object" with the parameter name of the string. |
| Rationale | So there won't be two main test objects listed in the object pool. |
| Impacts | The behaviour of the InstantiateClass has to change(Constructor) |
| Change Control Board's Decision | (Feb 22) ACCEPTED
See Change Request 14's Resolution. Assigned to Mike P. Done. |
| Date | Feb 15, 2001 |
| Name | Mike Power |
| Work Product / Admin | ETAMainView |
| Proposed Change | change the ActionPerformed of InstantiateClassAction to call getName on InstantiateClassDialog |
| Rationale | So the user can select the nameof the main test class |
| Impacts | Pass the name to ETAMainModel, InstantiateClass. |
| Change Control Board's Decision | (Feb 22) ACCEPTED
See Change Request 14's Resolution. Assigned to Mike P. Done. |
| Date | Feb 11, 2001 |
| Name | Mike Power |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | change the type of mainTestObject from Object to ParameterData |
| Rationale | Allows the ETAMainModel to handle the creation of new Main Test Objects
What this will look like from the user perspective. The User opens up a class "java.lang.String". He Instantiates the string which puts "Main Test Object" in the object pool. The user then decides that was fun, but he really wants to open "java.lang.Object". So the "Main Test Object" in the Object Pool changes its name to "user created java.lang.String 1". Then the user decides to instantiate "java.lang.Object" which puts "Main Test Object" in the object pool. Under our current design there would be two "Main Test Object" one of type java.lang.String and the other of type "java.lang.Object" which would confuse the user. |
| Impacts | Internal code of ETAMainModel will have to be changed, and a method loadObject(Object) will have to be changed to loadObject(ParameterData) |
| Change Control Board's Decision | (Feb 22) ACCEPTED
When 2 objects are instantiated the next one gets a number appended. The drop down menu will be dynamic and the instantiate class dialog will have a field when instantiated. Assigned to Mike P. Done. |
| Date | Feb 10, 2001 |
| Name | Mike Hebron |
| Work Product / Admin | User Manual / Requirements specification / Wes |
| Proposed Change | Remove the requirement that the user be able to create new primitive test data items simply by typing in a value in a parameter object combo box. In other words, make all parameter object combo boxes non-editable |
| Rationale | 1. the swing method that we need to use in order to do this returns
the incorrect value when a combo box is editable, and it would take a lot
of effort to find a work around to this quirk
2. confusion about the purpose of the parameter object combo box would be removed. before, the user might wonder what exactly is he suppose to type in thecombo box, or why he can type there at all. does he type in a new value for a primitive? does he type in the name of an already existing test data item to do a 'quicksearch'? does he rename the test data item currently shown there? 3. another piece of functionality (being able to instantiate a class or test data items by calling constructors) will remain broken (because of the quirk mentioned in #1) as long as the parameter object combo boxes are editable |
| Impacts | program might become clearer to use, since user can only create test
data items in one place (namely the object pool)
the user manual and ui prototype will need to be updated the ParameterObjectComboBox constructor will need to be modified so that all instances are non-editable |
| Change Control Board's Decision | (Feb 22) ACCEPTED
It is to be left uneditable. Done. |
| Date | Feb 10, 2001 |
| Name | Mike Power |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | Move whoListeningTo, fireParameterDataChanged, fireParameterDataAdded, fireParameterDataRemoved of ETAMainModel to ObjectPool |
| Rationale | Only Object Pool has a list of parameterData's something needs to inform new parameterDatalisteners of all the parameterData's that are already there. So whoever is adding a listener also needs a list of parameterdatas and also the means to convert the type string to class and determine which listener is listening to which parameterData. |
| Impacts | Code of ETAMainModel will have to be copied to Object Pool |
| Change Control Board's Decision | (Feb 10) ACCEPTED
the methods mentioned above will be moved to the Object Pool by Mike P Done. |
| Date | Feb 3, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | All 4 data classes need a reference to ETAMainModel - FieldData, MethodData, ParameterData, Returned Data. |
| Rationale | They need this reference so that they can call "random stuff" in the main model. |
| Impacts | The reference to the main model can either be added by altering the constructor or adding a function that adds the reference. This means that we need to modify the function calls or add new function calls. This also means that the javadocs et al need updating. |
| Change Control Board's Decision | (Feb 6) ACCEPTED
ETAMainModel functions that construct the 'xxxxData' classes will be modified so that a reference to the ETAMainModel is passed to the 'xxxxData' constructors 'xxxxData' classes will have a new member data to hold the reference to the ETAMainModel, constructors will be modified Done. |
| Date | Feb 3, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | ETAMainModel needs a method named "inspect". |
| Rationale | The data classes need an way to call the inspect function of ObjectInspector. This function will perform that duty. |
| Impacts | This is just another pass through function. It should be easy to implement. The javadocs et al need updating too. |
| Change Control Board's Decision | (Feb 6) ACCEPTED
ETAMainModel will have a new method called 'inspect' ReturnedData and ParameterData inspectObjectValue methods will call ETAMainModel's inspect method Done. |
| Date | Feb 3, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | ETAMainModel need a method named "removeReturnedData". This method will call "removeReturnedData" in ObjectPool. |
| Rationale | Right now, the ReturnedData class has no way to access the ObjectPool class. This method is needed to help implement "delete" in returned objects panel. |
| Impacts | All we need to add is a pass through function in ETAMainModel. Also, class diagram, interaction diagrams and javadocs will need to be updated (but they need updating already). |
| Change Control Board's Decision | (Feb 6) ACCEPTED
removeParameterData and removeReturnedData methods will be added to ETAMainModel. removeParameterData is needed for the same reason as removeReturnedData; ParameterData class has no way to access the ObjectPool class Done. |
| Date | Feb 3, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | Software Architecture / Jon
User Interface Prototype / Wes User Manual / Wes |
| Proposed Change | We need to decide on whether or not we will display public/private/protected/packaged local constructors, and if we do, how they will be displayed. Mike P. suggests 4 tabs across the top of the NewTestDataItem/InstantiateClass dialog. |
| Rationale | This application is supposed to allow users to fully test their code. If we don't add this, the user can't fully test it. |
| Impacts | This involves more gui work in InstantiateClassDialog.java (adding 4 tabs). |
| Change Control Board's Decision | (Feb 22) ACCEPTED
List for the constructors with a seperator/List heading for each seperate section (i.e. Private, Public, etc.) Assigned to Mike P. Done. |
| Date | Feb 3, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | ETAMainModel needs a method named "arrayName". This method will convert all of the "[B"'s and "[C"'s to "byte [ ]" and "char [ ]". I suppose arrays of anything will be cut off like that also. This method will fix it. |
| Rationale | Passing "[B" to methods as byte arrays doesn't work. We need this method as a translator. |
| Impacts | If we don't write this method, "anything that displays the name of an array will look lousy" (Mike P). Writing this method shouldn't be too hard to implement. |
| Change Control Board's Decision | (Feb 6) ACCEPTED
Mike P will find out methods impacted by change and notify module authors Done. |
| Date | Jan 25, 2001 |
| Name | Mike Power |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | editing of test data item names and values for primitives is moved out of the Object Pool tabs and into the Object Inspector |
| Rationale | bring all editing of test data item attributes (both field values and the item's name) into one place instead of having it spread in two locations |
| Impacts | redesign of several key classes |
| Change Control Board's Decision | (Feb 22) ACCEPTED
The field loses the cursor if "enter", "escape", or the focus is moved. Pressing "enter" is the only way to have changes occur. It shades grey with black font when the "enter" button is pressed and it's white with black font when editing. Done. |
| Date | Jan 25, 2001 |
| Name | Mike Power |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | syntax for session log messages need to be documented and baselined |
| Rationale | there's no official documented syntax for the messages yet |
| Impacts | user manual will need to have a section documenting the syntax of session log messages, ui prototype's status panel screenshots with the session log will need to be updated, code that uses the ETA.log output stream will need to follow the documented syntax |
| Change Control Board's Decision | (Jan 25) ACCEPTED
user manual will be updated with section explaining session log and agreed upon syntax, ui prototype and code will use same syntax Done. |
| Date | Jan 25, 2001 |
| Name | Mike Power |
| Work Product / Admin | Software Architecture / Jon |
| Proposed Change | set 'Name' buttons in rows of Methods panel to disabled while no valid parameters are selected |
| Rationale | user won't be confused when he tries to click on a method name button to invoke a method that he hasn't set parameters for, and nothing obvious happens (right now if user tries this, only messages tab blinks) |
| Impacts | code changes so that 'name' button has actionListeners listening to the combo boxes in a MethodRow |
| Change Control Board's Decision | (Jan 25) ACCEPTED
action listeners will be added to appropriate class Done. |
| Date | Jan 25, 2001 |
| Name | Jonathan Lee |
| Work Product / Admin | User Interface Prototype / Wes |
| Proposed Change | Object Inspector's 'OK' button should be labeled 'Close' |
| Rationale | 'OK' signifies acceptance of changes, but this dialog isn't editable |
| Impacts | String changes in code that creates OK button, all references to Object Inspector dialog in UI prototype, pics in user manual need to be changed |
| Change Control Board's Decision | (Jan 25) ACCEPTED
ETAInspectorView.okButton will be renamed UI Prototype and User Manual will be updated Done. |
| Date | Author | Change |
| 03/07 | ayahinia | Updated change requests 1 - 17, added change request 19 |
| 03/01 | ayahinia | Updated change requests 1, 2, 6, 12, 13, 14, 16, 17, 18 |
| 2/24 | ayahinia | Posted resolution to Change Request 15 |
| 2/12 | mhebron | corrected week numbers, posted requests/resolutions 11, 12 |
| 2/11 | mhebron | posted request and resolution to change request 10 |
| 2/6 | mhebron | added resolutions to requests from 2/3 |
| 2/3 | mhebron | added requests from 2/3, changed list order to most-recent-first |
| 1/25 | mhebron | initial posting with requests from 1/25 and decisions from 1/25 meeting |