Digital Sound Recorder: A case study on designing embedded systems using the UML notation. Ivan Porres Paltor Åbo Akademi University, Department of Computer Science, Lemminkäisenkatu 14, FIN-20520 Turku, Finland email: Ivan.Porres@abo.fi Johan Lilius Åbo Akademi University, Department of Computer Science, Lemminkäisenkatu 14, FIN-20520 Turku, Finland email: Johan.Lilius@abo.fi Turku Centre for Computer Science TUCS Technical Report No 234 January 1999 ISBN 952-12-0367-6 ISSN 1239-1891 Abstract This document is an example of the object-oriented analysis and design of an embedded system using the Unified Modelling Language (UML). The analysed system is a digital sound recorder, or Dictaphone. The design has been implemented using an embedded processor and the C++ programming language. Keywords : object-oriented design, UML, embedded systems. TUCS Research Group Programming Methodology Research Group 1 1 Introduction The Unified Modelling Language [BJR1, BJR2], provides a standardised notation to express object-oriented software analysis and design [CY90, MO92, SS95]. UML diagrams are able to model complex software systems including real-time embedded systems. However, UML is not a software process. UML does not specify the different stages of the development of a software project. The UML standard specifies a notation for several different diagrams, but it does not describe how to create and apply each diagram. [Dou98] presents a methodology for building embedded systems using the UML notation and object-oriented analysis and design techniques. This document describes the object-oriented design and implementation of a digital sound recorder, or Dictaphone, using the UML notation and the method described by Douglass. There are several digital sound recorders commercially available in the market. The model described here has been designed following the specifications of a commercial product from a well know manufacturer. These requirements are described in the second section of this document. The third section discusses the object model of the system and presents the main class diagram. The fourth section continues the object-oriented analysis but focusing in th internal behaviour of each object. The fifth section deals with the architectural design. We show the hardware architectur of the sound recorder and the concurrency model, where we assign each object to an execution thread. The design continues defining the collaborations between the different objects. This is done in section number six, where design patterns [GHJV95] are used to glue together the classes defined in the analysis phase. The most specific design issues are discussed in the section number seven. Finally, The eighth section discusses the implementation. We have implemented th software in the C++ programming language and built the hardware platform to run the code using a 32 bits RISC embedded processor. 1. 2. 2 Requirements Analysis A digital sound recorder is a consumer electronic appliance designed to record and play back speech. The messages are recorded using a built-in microphone and they are stored in a digital memory. The user can quickly play back any message at any moment trough a speaker placed in the front of the device. It should be small, light, easy to use, and battery operated. Figure 2.1 shows what our sound recorder could look like. It is a hand held unit with flat display and fairly large buttons. 2 NoYes     Figure 2.1: External appearance The main features of the product that we are going to consider in our design are: • Capacity for ten different messages. The length of each message is limited by the available memory. • Easy to use with on screen menus. • Direct access to any message. • Alarm clock with year-2000-ready calendar. The user can set a daily alarm. The alarm beeps until the user presses a key, or after 60 seconds. • Full Function LCD Display. The current date and time is always shown in the display. The display also shows clear directions about how to use it and what it is doing. • Battery-level indicator. The system beeps when the battery is low. • Stand-by mode. It economises the battery power. The system switches off th peripherals when they are not in use. The normal operation is resumed when the user presses a key. • Good sound quality. Sound is processed at 6Khz using eight bits per sample. 2.1 External Events An embedded system is constantly interacting with its environment. In this first stage of the analysis, we can consider our system as a black box reacting to the requests and messages from the environment. The environment is composed of several agents. Each agent interacts with our system with a different purpose and it exchanges a different set of messages. Context-Level Diagram Figure 2.2 shows all the agents that interact with our system. We have identified thre agents: the user, the battery and the time. It also shows the interfaces, sensors and actuators that allow our system and the agents to exchange messages. These messages can be requests from the agents to the system, or responses and services from the system to the agents. The sensors for the messages from the user are the microphone and the buttons. The actuators for the user agent are the speaker and the display. The battery level meter senses the state of the battery. 3 Digital Sound Recorder User Sensors/Actuators +Buttons +Microphone +Screen +Speaker +Battery Level Meter Interfaces -Analog To Digital -Digital To Analog -Digitral to Digital System Battery Power Record message, set alarm, set time Play message, beep alarm, show time Time next second Figure 2.2: Context-Level diagram The Time agent sends a message to our system whenever the time passes. It represents the source of messages like “next second” or “next hour”. In the real implementation, a hardware timer measures the pass of the time. Events An event is an important message from the environment. A real-time reactive system has to react to the external events in a bounded time. The following table shows all the external events that can occur in our system. The direction of an event can be “In”, from the environment to the system, or “Out”, from the system towards the environment. The arrival pattern (A) can be Periodic, if the event occurs on a fixed time basis, or Episodic, if its arrival time is random. The Response time sets an upper bound for the system response actions. The system will behave incorrectly if it does not react within the response time. Event System Response Direction A Resp. 1 A second passes a. Update internal clock b. Check alarm c. Update clock display, d. Update task progress display. In P 0.5 s 2 A sample period passes a. Play or record next sample In P ½ period 3 User presses a command button a. Show task progress display b. Start recording or playing a message In E 0.5 s 4 User presses the “stop” button a. Current task is stopped b. Update display In E 0.5 s 5 Low battery alarm a. Warn the user and stop current task In E 1 s. 6 Enter stand-by mode a. Switch off the display In E 1 s. 7 Wake up, user presses a button while in stand-by mode. a. Leave stand-by mode, power up display, etc. In E 1 s. 4 User Playback message Record a message Set alarm time Watch time Digital Sound Recorder Set clock time Delete message Figure 2.3: Use Case diagram 2.2 Use Cases Use cases describe the functionality of the system from the user’s point of view. The user may be a person or another machine. Each use case is a different way to use the system and the completion of each use case produces a different result. In our system there are six different use cases, represented in the Figure 2.3. Record a message The user selects a message slot from the message directory and presses the ‘record’ button. If the message slot already stores a message, it is deleted. The system starts recording the sound from the microphone until the user presses the ‘stop’ button, or the memory is exhausted. Playback a message The user selects a recorded message slot and then presses the ‘play’ button. If th message slot contains a recorded message then it is played trough the speaker until its end or until the user presses the stop button. Delete a message The user selects a used message slot and then presses the ‘delete’ button. The message is permanently deleted from the memory and its memory space is recycled. Set the alarm time The user can switch on and off the alarm and set the time when the alarm will sound. This is done by selecting the different options of the alarm menu. 5 Set the clock time The user can set the clock time and adjust it to the current time zone. Watch the time The system constantly shows the current time and date on the display. The user just looks at it. 2.3 Scenarios The scenarios should describe the interaction between the active external actors (the user, the battery and the time) with the system. Even if the role of each actor is usually clear, it can be difficult to study all the possible interactions between all the actors and the system. E.g., we have to study what happens when the battery goes low while th system is playing a message, or what to do if the alarm sounds while the system is recording a message. Figure 2.4 shows an scenario for the Play Message use case. << actor >> User : System :Speaker 1: Play Message 2: Start playing sound {0.5 s.} 3: Display Progress Indicator 4: Next Second 5: Display Clock { 0.5 s. } 6: Display Progress Indicator 7: Stop 8: Stop playing sound {0.5 s.} Figure 2.4: Playing message scenario Figure 2.5 shows what should happen when the alarm sounds while the user wants to play a message. We have decided to give priority to the alarm sound. 6 << actor >> User : System :Speaker 1: Play Message 3: Display Progress Indicator 4: Next Second 5: Display Clock 6: Display Progress Indicator 12: Next Second 13: Display Cock 2: Start playing sound 7: Alarm! 8: Start playing alarm 9: Display Alarm Indicator 10: Stop 11: Stop playing alarm sound { 0.5 s} Figure 2.5: Alarm while playing scenario The system can switch on and off the screen backlight, the microphone and the speaker. These elements use a considerable amount of battery power. By switching them off the system saves energy and increases the battery life. The battery can also warn the system when it is almost out of energy. Then the system should switch off all the peripherals and enter the stand-by mode. When the user charges the battery, the system will leave the stand-by mode. While the system is in stand-by mode, the messages are still kept in the memory. Figure 2.6 shows a scenario where the system enters stand-by mode, then it is woken up by the alarm clock. After another battery warning, it enters again stand-by mode. 7 : System :Speaker: Display: Battery 1: Next second 2: Next Second 3: Switch off display 4: Switch off amplifier 5: Next second 6: Alarm ! 7: Switch on display 8: Switch on amplifier 9: Start playing alarm sound 10: Next second 11: No Power! 12: Stop playing alarm sound 13: Switch off amplifier 14: Switch off display After some minutes without any activity Figure 2.6: Entering and exiting stand-by mode scenario 3. 8 3 Analysis: Object structure After the requirement analysis, [SS95] proposes the Domain Analysis phase. In this phase, we should analyse the requirements and present a class diagram as a general solution for the problem. The domain diagram shows the main classes of the system and their relations, but it omits their interface. The first step in building the class diagram is identifying the objects involved in it. 3.1 Identifying objects Active Objects Message Player & Recorder A “digital tape”. Buttons, Screen The user can press the buttons. The screen shows a menu and indications to the user. Alarm Clock It shows the time and it can wake up the user Services Battery level sensor Measures the remaining battery power level Analogue to digital converter The interface between the microphone and the processor Digital to analogue converter The interface between the processor and the microphone Screen controller Generates the image on the LCD screen Real-World Items Date Time Speech, Sound Physical Devices Microphone, Speaker Battery Keyboard, Display Key Concepts Speech, Sampling, Sound sample We must study how a discrete digital system can capture and process an analogue and continuos sound signal. Sound message Persistent objects Collection of recorded messages The contents of the digital tape Current Time, Date Alarm Time When to warn or wake up the user Transactions Message Visual elements Menu, Menu option, Menu selection Clock, Alarm on/off indicator Calendar Status bar, help line, Task progress indicator Play , Record, Stop, Yes, No, Up, Down, Left, Right Buttons The user interacts with the system by pressing the buttons. There are nine different buttons [...]... is a wrapper for a hardware timer The Microphone class is a hardware wrapper for the physical microphone A Microphone class can record one sound sample The Speaker class is able to play back sound sample through the hardware speaker 10 AudioController Message Synthesiser AudioBlock getSample( ) addSample( ) playMessage( ) recordMessage( ) deleteMessage( ) playAlarm( ) stop( ) getAudioBlock( ) appendAudioBlock(... shows the current time, date and the alarm time At the bottom, there is a short help message for the user 3.2 Building the class diagrams The Sound Recorder Class Diagram The user interacts with the system through the display and the keyboard These are somehow passive objects, so we decide to add a user interface object that manages the interaction with the user The User Interface class relies on the Audio... time The Alarm Clock uses a timer to measure the pass of the time Each second updates the internal representation of the time, by using the nextSecond method When the Time object wraps around, then the date is updated using the nextDay method The class diagram for the Alarm clock is shown in Figure 3.9 The User Interface Class Diagram The User Interface class manages the interaction with the user It... indication on the display and play an alarm sound with the help of the Audio Controller The Battery object periodically measures the battery power level When the battery goes low then it reports the event to the User Interface Figure 3.2 represents graphically the main classes of the digital sound recorder The class diagrams provide a general overview of the whole system by abstracting from the details... debugging the software They are connected to the processor serial channels and are RS-232 compatible thanks to an MAX232 The EPROM also contains code to initialise the serial ports, send and receive data up to 38400 bps The analog to digital converter has seven input channels The converter can sample at more than 60Khz with a resolution of 12 bits The main board is described in [HEVB] We use the analog to digital. .. program image but a non-volatile memory containing the program The linker must statically link all the libraries into the program and allocate all th program symbols into absolute memory addresses The program must include some code to initialise and check the hardware and rearrange the executable program into th RAM That includes initialising the processor stack, copying the initialised variables from the. .. playing it 13 : AudioOutput Time Now get( ) set( ) nextSecond( ) cycleHour( ) cycleMinute( ) AlarmClock getTime( ) getDate( ) getAlarm( ) getAlarmState( ) setAlarmState( ) AlarmTime Date get( ) set( ) nextDay( ) cycleDay( ) cycleMonth( ) cycleYear( ) Today Figure 3.9: Alarm clock class diagram The Alarm Clock Class Diagram The Alarm Clock class keeps the current time and date and the alarm time The Alarm... languages Therefore, the designer should build a mechanism that transforms a hardware interrupt in message to an object We have wrapped this mechanism in an abstract class called ISR A subclass of the ISR class can implement interrupt service routines as a normal method 6.2 Collaboration between the reactive objects and the User Interface The keyboard, the battery level meter, the alarm clock and the. .. After the creation of the wrapper, the device is ready to be used The methods of the wrapper configure the device, but also can start or stop some activity Usually a wrapper has few attributes, because the state of the wrapper is the state of the hardware device The detailed design and implementation of a hardware wrapper requires a precise knowledge of the hardware devices In this design, the speaker,... Controller to perform the tasks The Audio Controller is the core of the system and it executes the tasks suggested by the user interface The audio controller uses the Audio Input and Audio Output classes to produce the sounds These classes are related with a microphone and speaker hardware wrapper [AKZ96] Keyboard UserInterface Display Battery AlarmClock AudioController MessageMemory 1 AudioInput AudioOutput