Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 121 of 229

Enumeration starts by evaluating a single stimulus to the system and determining the appropriate response for each stimulus. • Precondition: Machine is ON and there is one soda in the machine TABLE 1 Soda machine stimuli and response abbreviations Stimulus Initialize Quarter Soda select Change return Sold out Abbreviation I a 55 CR so TAB Line Number 1 2 3 4 5 Enumeration level 1 Enumeration Level Response Equivalence Requirement 4 illegal illegal illegal illegal none none none none Res onse Soda deposited Change return Sold out light Power on light so Abbreviation CHR SOL LIGHT • Description: A use r walks up to the machine and deposits two quarters. He then presses the soda button. Nothing comes out because three quarters are required to get a soda. The user hits the change return to get his change. He then leaves to get another quarter. He returns with three quarters, deposits the quarters and selects a soda. This is the last soda in the machine so the "Sold Out" light comes on • Exceptions: None • Postconditions: There is no soda left in the machine and the "Sold Out" light is ON Other use cases can be developed TABLE 3 Enumeratton levels 1 and 2 Line Number 1 2 3 4 5 Enumeration Level Stimuli Se uence Response Equivalence Requirement 4 none none none none 4 1 01 2 02 is a story about the usage of a system told from the end user's perspective. It consists of: • Preconditions- what must be avail- able and done before the perfor- mance of the use case • Description- the story • Exceptions- exceptions in the nor- mal flow of the story • Illustratio ns-figures understand the use case to he lp • Postconditions-the state of the system and actors after the use case has been pe rformed Use cases are desirable because th ey: • Analyze and improve functional requirements • Model the functionality of the sys- tem as soon as possible • Allow the customer to understand the operation of the sy tern Use cases must specify the most important fun ctional requirements. A use case depicts a typical way of using the system but nothing more. In gen- eral, a use case should not try to define all possible ways of performing a task. Certain important exception condi- tions are described in "secondary" use cases or in exceptions within a use case. A simple use case for the soda machine can be as follows: 120 SEPTEMBER 2000 Embedded Systems Programming depending on the various business cases for this system. Once we have a general idea of what the system should do (something use cases are helpful for determining), we can then per- form a sequence enumeration to more completely map all possible combina- tions of stimuli to responses. To start with, it's a good idea to represent the system as a "black box," showing the stimuli and the responses that are possible. The black box for the soda machine is shown in Figure 3. Table 1 lists the abbreviations used for each stimulus and response in the sys- tem enumeration. A sequence enume ratio n can be done in a spreadsheet. Enumeration starts by evaluating a single stimulus to the system and determining the appropriate response for each stimu- lus. Table 2 shows the first level enu- meration for the system. As th e table shows, each stimulus is separately evaluated. The table shows that if th e Initialize stimulus (I ) occurs (the power is applied and the system is initialized ), the Powe r o n light response (LIGHT) is produced, as required by requiremen t 4. If any othe r stimulus occurs, the response is null and it is considered an illegal sequence (you cannot select a soda if th e power is not on, for example).

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10