18649 - Issue Log

18649 Spring 2010
Group 7 - Justin Ray/justinr2

This table has an entry for each design issue during the semester. Add new entries to the bottom of the table (you may need to add new rows). Leave all the previous entries in place so that at the end of the project you have a complete list of the design changes that you have made throughout the project. The meaning of the table entries is as follows:

Issue number - unique identifier for each entry
Date found - the date the issue was found
Date fixed - the date the issue was fixed
Change made by - andrewID of the person or persons responsible for the change
Origin - the earliest artifact where the issue was present. For example, if the a bug in the code is ultimately the result of an incorrect sequence diagram, then the origin would be that particular sequence diagram
Description - brief description of the issue
Resolution - brief description of the changes made to resolve the issue. If the entry is not resolved, put a note like "Pending" here.
Artifact(s) changed - a list of the artifacts that were modified to resolve the issue. This should be a specific list, such as "doorcontrol requirements", "SD 1.4A", "DriveControl statechart", "doorcontrol.java"

Issue #	Date Found	Date Fixed	Change Made By	Origin	Description	Resolution	Artifact(s) Changed
1	1-19-2010	1-20-2010	justinr2	SD	Sequence diagrams description of button behavior doesn't include the Empty sensor	Added Empty sensor and messages.	SD1C, SD2A
2	1-20-2010	1-20-2010	justinr2	ET Requirements	In ET Requirements for VendPositionControl, logic for stopping the VendMotor was incorrect.	Adjusted the logic for ER5.12, 5.13, 5.14. Removed ER5.11. Updated traceability.	VendPositionControl ET requirements
3	1-21-2010	1-21-2010	justinr2	TT Requirements	Coin Control TT requirements were missing requirements related to coin return (these had been present in the ET reqs)	Added requirement 2.4a and 2.4b, updated CoinControl statechart	CoinControl TT Requirements and Statecharts
4	1-23-2010	1-23-2010	justinr2	SD	In sequence diagrams 1C and 2A, arcs 2A and 2B had their behavior reverse. The flash sequence should start with a false (light off) since the light was already on to begin with.	Changed the values in the 2a and 2b arcs so that ButtonLight[s](false) precedes ButtonLight[s](true).	SD1C, SD2A
5	1-24-2010	1-24-2010	justinr2	Requirements	Found several typos, mispellings, and minor inconsistencies in the Requirements documents.	Fixed minor errors. These changes did not affect the design or function of the soda machine.	Requirements I and II documents
6	1-25-2010	1-25-2010	justinr2	Sequence Diagrams	Omitted arc from Vend to Empty in the SD (indicating that a soda has been vended and the count has decreased).	Added arc 4h to SD 1C and 2A	SD1C, SD2A, SD to requirements traceability (ET and TT)
7	1-25-2010	1-25-2010	justinr2	TT Requirements	CoinControl would enter the coin return state when coin release was pressed, even if no coins had been inserted.	Fixed the TT requirements, statecharts, and code to also check the coinCount condition.	R3.4, T3.6 (CoinControl statechart), CoinControl.java
8	2-3-2010	2-3-2010	justinr2	Implementation	Through unit testing, identified two implementation bugs: the flash period of the ButtonControl was too long and the transition logic for T2.1 was incorrect (reading the mButton message instead of localButton physical input).	Changed the T2.4 to <= and T2.1 logic to use localButton	ButtonControl implementation
9	2-4-2010	2-4-2010	justinr2	Implementation	Through unit testing, identified an implementation bug: transition T3.10 erroneously set the controller state to RETURN_2 instead of VEND.	Changed T3.10 to set state to VEND	CoinControl implementation
10	2-4-2010	2-4-2010	justinr2	Implementation	Through unit testing, identified a bug that the mCoinCount message object had not been identified or registered. This was a tricky bug because it is only used in the If statement for T4.1, but it is ANDed with other conditions, so the test (and bug) are not activated in all cases because of the way Java evaluates Boolean experssions. Double checking other objects led to the revision of VendPositionControl to fix the same bug.	Initialized the mCoinCount object	VendControl and VendPositionControl implementations
11	2-4-2010	2-4-2010	justinr2	Requirements	Unit testing identified a bug where the previous logic (STOP if the terminal position is reached) would prevent the controller from even leaving the terminal location.	Added a condition that the terminal position must be true while the motor is commanded to move the "wrong" way (e.g. LEFT from position 1).	R5.5, T5.2, and VendPositionControl implementation.
12	2-9-2010	2-9-2010	justinr2	Sequence Diagrams	Missing arc in SD3A for setting the CoinReturn message to false after 200ms	Added missing arc 3A.1c	SD3a, traceability
13	2-9-2010	2-9-2010	justinr2	Sequence Diagrams	While constructing test, realized we are missing a CoinIn false arc on SD 1C	Added arc 1C.1e	SD1A, traceability
14	2-9-2010	2-9-2010	justinr2	Requirements	Integration test 1C revealed a condition where the button returns to the VEND state after a VEND cycle if the button is still depressed the mVend message is not checked on transition T2.1. This is traced back to a conflict betwen (ER2.4 and ER2.7) and (R2.4 and 2.5). In the processo of making this change, also identified and fixed erroneous IF condition on ER2.2.	ER2.4 and R2.4 converted from SHALL to SHOULD. T2.1 changed to check mVend ER2.2 no longer checks ButtonState. Updated unit tests	ER2.2., ER2.4., R2.4, T2.1, ButtonControl implementation, unit tests
15	2-9-2010	2-9-2010	justinr2	Architecture	Further testing on issue #14 revealed that the button control needs to know the coin count to know whether or not to start flashing. (See Note 1)	Added mCoinCount(n) to the input interface for ButtonControl. Added ER2.8, ER2.9, Added CoinCount check to ER2.4 and R2.4 Updated traceability Updated unit tests	ButtonControl interface SD 1C, 2A ER2.8, ER2.9, ER2.4 R2.4 SD to reqs traceability ButtonControl Statecharts, Implementation, and unit tests
15	2-10-2010	2-10-2010	justinr2	Implementation	In acceptance testing, bugs in coin handling were occuring. Not all coins would be returned. This issue was caused by the periods for the modules being set to values other than those determined in the network schedule	Fixed the periods in the code.	Control.java
16	2-10-2010	2-10-2010	justinr2	Requirements	Even after the fix in Issue #15 fixed most coin handling problems, there were still a few errors in the acceptance tests. In spite of the statement in the original requirements that the CoinOut pulse could be of any width, acceptance testing revealed that jitter in message delivery could result in a framework message produced by a controller for exactly one controller period might not be delivered in all cases. This resulted in the CoinOut pulse not being read by the ChangeMachine (system object) in some cases, causing customers not to receive a coin that should have been returned.	Revised the requirements for CoinOut to be at least 150ms long. Added the OVERPAY_STRETCH and RETURN_STRETCH states and associated transitions, and updated implementation, traceability, and unit and integration tests.	CoinOut requirements (see Note 1) Requirements ER3.5a, R3.4a CoinControl statechart, CoinControl statechart-to-reqs traceability CoinControl Implementation statecharts-to-code traceability Update and execute coincontrol unit tests Update and execute integration tests for sd1b and sd3a
17	2-10-2010	2-10-2010	justinr2	Implementation	Simulation to verify the network bandwidth revealed that the bandwidth was higher than expected, which was traced to an incorrect message period of 10 ms (instead of the 100ms from the schedule) being used for the mCoinReturn smart sensort message.	Fixed the message period for mCoinReturn	Modules.java (see Note 1)
18	2-16-2010	2-16-2010	justinr2	Implementation	Previous implementation of ButtonControl implemented a flattened statechart and had a failure of traceability because the T2.2 and T2.3 were traced to multiple locations in the code. This implementation fixes that by directly implementing the nested states.	Modified the implementation of ButtonControl to conform to the statechart given in the requirements.	ButtonControl implementation sc-to-code traceability
19	2-16-2010	2-16-2010	justinr2	Requirements	Missing a TT requirement for the falling edge detection in CoinControl	Added R3.6	CoinControl requirements, sc-to-reqs traceability, sd-to-requirements traceability reqs-to-constraints traceability

Note 1: The system objects used for the soda machine are less mature than those for the elevator. Although it is still possible that there are bugs in the system objects, you may not modify these objects or their requirements unless the change is specified by a project writeup or you obtain PRIOR permission from the course staff.