22C22 Homework 5

Homework 5

22C:22 Object-oriented Software Development
Due Monday, February 26, 2007

12 points

A small company would like to design a "high definition" (HD) radio that can also record and playback songs. HD radio signals contain, in addition to the music, extra digital information such as song title, artists, duration of the song (in seconds), and total size in megabytes. The company's idea is to use really inexpensive hardware, which means using a minimum of buttons and displays for the interface. Here is what the hardware engineers can provide:

Three buttons, called A, B, and C. Pressing the A button generates an "A-click" event to the software, pressing a B button generates a "B-click" event to the software, and pressing a C button generates a "C-click" event.
Volume control and power-on/power-off operate independent of the software (the software gets no events or awareness of these things, so power-off can happen with no warning). Also, tuning stations is outside of software control.
An LCD display can show some text, such as a song title, an error message, or whatever the software decides to display (provided it's a pretty short amount of text).

Meanwhile, the marketing department has given us some draft of what they think should be in the user manual. Here are some of the main points:

There are three main "modes" of the radio recorder/player, once it is on. In the playback mode, the radio is playing back a song from flash memory. In the record mode, the recorder is copying a song to the flash memory in addition to playing it. Finally, there is the listen mode, where the radio is behaving like an ordinary radio, but the user can also press buttons to get or set some controls.
If any of the A-C buttons is pressed during playback or record modes, then the radio switches instantly to listen mode. Note that if the radio is in record mode and recording a song, any kind of interruption or exception (pressing a button, running out of space in flash memory, losing the radio signal due to noise or interference) just loses the entire recording of that song -- no error message (remember, this is supposed to be a really cheap radio). Similarly, if the user tries to record and flash memory is fully, then recording won't work, but there is no error message.
If a user starts the record mode in the middle of a song, then recording will actually begin with the next full song. You can assume this is pretty much a hardware function: that is, the hardware takes care of recording the music to flash, and when exactly the recording of a song begins and ends. At the instant that a song is successfully recorded, the software gets an event that a song has been recorded; the event also contains the song title and any other associated information provided by the HD radio channel.
In listen mode, pressing buttons is used to do such things as: scroll through song titles, start playing the song whose title is on the display, delete the song shown on the display.

That's pretty much it. A simple, cheap device with minimal controls. Of course, you need to design the software, and you can imagine various "commands" to initiate hardware actions (you need to invent these), some class/object or interface ideas for a directory of songs, and so on. But remember: we don't know at this point whether or not Java will actually be used in the implementation. So stick to UML, state diagrams, and so on to specify your design.

Your assignment:

Assuming that the song "Out da Alley" has been previously recorded to the flash memory, make a sequence diagram to show the interaction between user and the software/hardware to start playing "Out da Alley".
Make a state diagram of your design for the software. Document what each state "means" in the diagram (that is, give some written explanation of what that state represents). For arrows going from one state to another, say what event(s) correspond to that state transition and what software actions would be done when that transition is taken.
Write down what kinds of variables and objects would be needed to implement your state diagram.
If your design is going to be implemented by Java programming, each of the events in your state diagram will eventually be represented by some method invocation (we saw this in the previous homework, where mouse events turn into method calls). Choose one event relevant to the state diagram, and for that event, state what are the "pre" and "post" conditions for that event. The precondition is a generic description of variables and objects before the event, and the postcondition is a generic description of variables and objects after the event. So, in other words, your pre- and post-conditions will indicate specify what kind of change to variables and objects of Q3 are occur due to that event.
```
    Examples (will be covered in class)

    pre:  x==k and y==j 
    what event handler does:  {  if (x<100) { x=x+1;  y=y-1;}  }
    post:  k<100  ==> x==k+1 and y==j-1
           k>=100 ==> x==k and y==j   

    pre:  Q == R, where R is a queue of items [x1,x2,...]
    what the event handler does:  
          { a = Q.deQueue(); }
    post: R empty ==> a == NULL and Q is empty
          R == [x1,x2,...] ==> a == x1 and  Q == [x2,...]      
```
Write down an invariant property of the radio system in terms of the variables and objects you answered for Q3. Remember, an invariant is a quantitative or logical relationship between the variables and objects; this relationship does not change when a state transition occurs. This design is so simple that it may be hard to think of any invariant property; in that case, you might consider making the state diagram or your answer to Q3 more detailed in order to answer Q5.