CS522A (Fall 2003) Assignment 3 - SOLUTION

Thomas

Download: [PDF] [PS]

Contents

• Assumption
• Implementation
• Brief Explanation

Assumption

The only assumption is that the MP3 file that this MP3 player plays is not currupted. In that case, it is very hard to tell how the statechart model and the underlying PyGame library would behave.

As a side remark, it is very hard to capture exceptions in a statechart model. In an other word, statecharts are not fault tolerant. One has to ensure that the model will never go to a ``strange'' state (or unexpected state). If this happens, usually the simulation does not crash but just reacts in a strange way, or does not react at all!

Implementation

The textural design is written (manually) in MP3Solution.des. To run this model, these files in the distribution package are necessary: MP3Library.py (MP3 hardware library), MP3PlayerGUI.py (MP3 model-specific graphical interface), Fwd.gif, PlayPause.gif, Rew.gif and Stop.gif.

Figure 1 shows the equivalent graphical representation of this statechart model.

Figure 1: Graphical statechart model for MP3 player

Brief Explanation

There are some notes for this model:

• To ensure every time a new state is entered (such as MP3.Playing.Normal, MP3.Stopped and so on), all the buttons are enabled/disabled correctly, enter actions are used heavily. Macro [SETBTN(...)] with flexible number of parameters is useful.¹
• Exit actions are used to show the time when state MP3.Playing.Paused or MP3.Playing.Seeking.Display is left. This is important since it is uncertain whether the time field is shown or hidden because of the blanking.
• Hardware events provide a better means to control the hardware and to obtain information from it. For example, whenever event ``Playing Stopped'' is raised, the model goes to state MP3.Stopped, whether this stop is caused by the user's clicking on the stop button or the MP3 file ends unexpectedly.
• As this might not have been clearly specified in statechart description, leaving one of the orthogonal components results in leaving all its siblings. As a result, when the model is in MP3.Playing.Seeking.Control.Forward and event ``GUI Forward Released'' is raised, the model not only leaves MP3.Playing.Seeking.Control but also MP3.Playing.Seeking.Display (and the exit action of the latter is executed).
• There is slight incompatibility between SVM 0.23 and 0.3. In the former version, enter actions of the new state are executed before the output of the transition that changes the state. This is why the transition from MP3.Stopped to MP3.Playing has to include mp3.play() in its output part. The enter action of MP3.Playing (mp3.play()) is executed before the output action of this transition (mp3.rewind()), and as a result, the file is rewinded and no sound is played. This execution sequence deviates from David Harel's statechart specification. It is fixed in SVM 0.3. So in the new version, mp3.play() is not necessary for the output of this transition. (Of course, playing twice causes no problem.)

Footnotes

... useful.¹

The use of macros also limits language dependency. To port a Python model to Java only requires rewriting the set of macros.