Interaction-based Behavior Modeling of Embedded ... - CiteSeerX

Interaction-based Behavior Modeling of Embedded Software using UML 2.0 Sang-Uk Jeon† †

Jang-Eui Hong‡

Division of Computer Science Department of EE and CS KAIST, Korea {sujeon, bae}@se.kaist.ac.kr

Abstract Many prior approaches in UML-based embedded software design incorporate state-based behavior modeling. However, interaction-based behavior modeling provides more intuitive view of a system. In this paper, we propose an approach to interaction-based behavior modeling of embedded software using UML 2.0. We use the interaction overview diagrams and the sequence diagrams to model the behavior. We present the method of constructing interaction-based behavior model with an example. We also briefly describe the idea of generating executable code from it.

1. Introduction Many products, such as mobile telephones and automobiles, today contain software. Due to the advances of information technology, more products will contain software. Moreover, embedded systems are becoming more complex because of the demand for new and complicated features. A key to success in embedded software development is the ability to develop high-quality ones on time[8]. For efficient development, many approaches to model embedded software were proposed. The Unified Modeling Language(UML)[2] has become the de facto standard for visually describing the structure and behavior of software. Now it is emerging in embedded system design[1, 12]. Especially the latest release of it, UML 2.0[10], incorporates more modeling notations in the embedded software domain. There are several works for modeling embedded software using UML 2.0. Frick et al. presented architecture design for embedded control software with UML 2.0[6]. Their focus is on modularization and variant design. The services of the module are realized in terms of a statemachine and/or attributes and

Doo-Hwan Bae† ‡

School of Electrical& Computer Engineering Chungbuk National Univ., Korea [email protected]

operations. Schattkowsky and Muller proposed a modelbased approach of designing embedded systems using UML 2.0 subset[11]. In behavior modeling, they combined the statemachine diagrams and the sequence diagrams. The behavior of each object is described with the statemachine diagrams. These approaches incorporate state-based behavior modeling, in which the behavior is shown for each object. Thus the overall behavior of the system cannot be seen in state-based behavior model. So the designers in industry usually prefer to use interaction-based modeling for specifying behavior[14]. Interaction-based modeling focuses on the global interactions between actors and components in a system. It is a good way to get an overall view of a system. Although it is more intuitive for designers to describe software behavior than state-based modeling, there are few approaches that use interaction-based behavior model because it is said that interaction-based modeling shows only partial behavior[13]. In this paper, we propose an approach to interactionbased behavior modeling of embedded software based on UML 2.0. We use two interaction diagrams for behavior modeling; interaction overview diagrams and sequence diagrams. The interaction overview diagrams, newly introduced in UML 2.0, are a variant of activity diagrams that define interactions in a way that promotes overview of the control flow[4, 5, 10]. In the interaction overview diagrams, as well as the sequence diagrams, specifying real-time properties such as time constraints is possible. We use interaction overview diagrams to realize use cases. In most software development methodologies, the sequence diagrams are used to realize use cases[9]. The main scenario of a use case is described in one sequence diagram. However, in our approach, a sequence diagram represents a part of a use case scenario. That means, several sequence diagrams are composed to describe a use case. It is the interaction overview diagrams that show how those sequence diagrams are composed to realize a use case. By reflecting the alternative and failure scenarios as well as the main scenario

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing 0-7695-2561-X/06 $20.00 © 2006

IEEE

Behavior Modeling

Use Case Model

DoorSensor

Light

Beeper

Identify External Events 1

1

Structural Modeling Identify Classes

1

Map external events to use cases

1 1

Button

OvenController 1

Define relationships between classes

...

Construct diagram in terms of external events

Behavioral Model

1

PowerTube Incorporate alternative scenario

Construct sequence diagrams

Structural Model

1

CookButton

CancelButton

Figure 2. The class diagram of the microwave oven

Figure 1. The overview of our approach.

of each use case, the issue that interaction-based modeling handles partial system view is resolved. This paper presents how to construct interaction-based behavior model from use cases. We also present some idea of generating code from the model. The remainder of this paper is organized as follows: Section 2 presents our approach to modeling the behavior of embedded software. Section 3 briefly describes about generating executable code from our model. Finally, conclusions and future work are discussed in Section 4.

2. Behavior Modeling Using Interaction Diagrams Figure 1 shows the overview of our approach. In structural modeling phase, the structural model, i.e. class model is constructed from use case model. Since the construction method is the same as those of typical object oriented embedded software development[3, 7], we will not discuss about it. With the use case model and the structural model, the behavioral model is constructed. In behavioral modeling phase, first we identify external events. After mapping external events to use case scenarios, we construct initial interaction overview diagrams. By incorporating alternative scenarios, we finalize the interaction overview diagram for each use case. Then, for each node in the interaction overview diagrams, corresponding sequence diagrams are constructed. In this section, we present each step of the behavior modeling phase in detail.

2.1. Example Description For clear understanding of our approach, we provide an example system. The system to be modeled is a simple microwave oven. Following is a part of the requirements for the system.

• The microwave oven has two buttons: a cook button and a cancel button. When the cook button is pressed once, the oven will cook for 1 minute. Cooking can be terminated at any time by pressing the cancel button. • Whenever the oven is cooking, the light inside the oven must be on to allow the cook to see the food. The light should also go on when the oven door is opened. At all other times, the light must be off. • Pressing the cook button while the oven is cooking extends the cooking time by 1 minute. One can then press the cook button any number of times during cooking to add as many minutes as desired. • When the oven completes cooking, the power tube and the light are turned off. The oven will then alert the cook by beeping three times. • While the oven is cooking, opening the door will interrupt cooking. Any remaining cooking time is cleared and the oven will not beep.

2.2. Describing Use Cases In this example, only one use case is identified. Assume that the name of use case is ”Cook”, whose actors are the user and a external timer. We will omit the use case diagram for page limit. Figure 2 show the class diagram for the microwave oven. Details in classes such as attributes, operations and signals are omitted. When describing use case scenarios, we assume that alternative(or failure) scenarios are described as well as main success sequence scenario. The sample scenario description of ”Cook” use case is as follows: Main Success Scenario 1. The user opens the door. 2. The light is turned on. 3. The user closes the door. 4. The light is turned off.

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing 0-7695-2561-X/06 $20.00 © 2006

IEEE

5. The user presses the cook button. 6. Single beeps. 7. The light is turned on. 8. The power tube is energized. 9. The system signals the timer to add 60 seconds. 10. The system signals the timer to start. 11. After elapsing the cook time, the timer notifies the system. 12. The power tube is turned off. 13. The light is turned off. 14. Beep three times. Alternative Scenario 1a. The user presses the cook button without putting food. 1b. The user presses the cook button when the door is open. 11a. Before elapsing the cooking time, The user presses the cook button to increase cooking time. 11a-1. The system signals the timer to add 60 seconds. 11a-2. Continue to step 11 11b. Before elapsing the cooking time, The user presses the cancel button to cancel cooking. 11b-1. Single beeps. 11b-2. The power tube is turned off. 11b-3. The light is turned off. 11b-4. The system signals the timer to stop. 11b-5. The scenario ends. 11c. Before elapsing the cooking time, The user opens the door and the cooking is canceled. 11c-1. The power tube is turned off. 11c-2. The light is turned off. 11c-3. The system signals the timer to stop. 11c-4. The scenario ends.

2.3. From Use Case to Interaction Overview Usually, in typical object oriented development, one sequence diagram is constructed from a use case. That makes the traceability of use cases. In our approach, one interaction overview diagram is constructed from a use case. The sequence diagrams are used to describe InteractionUses[10] in the interaction overview diagrams. We will discuss about the sequence diagrams in Section 2.4. In this section, we describe each step of constructing interaction overview diagrams. Step 1 : Identify external events In embedded systems, external messages (including events) play an important role in constraining and defining the system behavior[3]. So the first step is identifying such external events. Table 1 shows an external event list for the microwave oven system. From events 1 to 4 are initiated by the user and event 5 is initiated by the timer. Events 6 to

1 2 3 4 5 6 7 8

Table 1. External event list. Event Type(Actor) Arrival Pattern DoorOpened Input(User) Episodic DoorClosed Input(User) Episodic CookBtnPressed Input(User) Episodic CancelBtnPressed Input(User) Episodic TimerExpired Input(Timer) Episodic Add60SecToTimer Output(Timer) Episodic StartTimer Output(Timer) Episodic StopTimer Output(Timer) Episodic

Table 2. Mapping external events to use cases. Use Case Scenario External Events 1. User opens door. DoorOpened 3. User closes door. DoorClosed 5. User presses cook button. CookBtnPressed 9. The system signals timer Add60SecToTimer to add 60 sec. 10. The system signals timer StartTimer to start. 11. After 1 minutes of cook time, TimerExpired timer notifies the system

8 are sent from the system to the timer actor. We assume that if the timer receives ’StopTimer’ event, the timer clears remaining time as well as stops. Step 2 : Map external events to use case After identifying external events, the next step is to find which external events are addressed in use case scenarios. By following the use case scenario, we can easily find which external events are addressed. Table 2 shows the mapping of external events to ”Cook” use case scenario in the microwave oven system. Step 3 : Construct diagram in terms of external events The next step is constructing interaction overview diagram in terms of external events and their reactions. The basic idea is simply constructing diagram according to the steps of the main use case scenario. If a certain step maps to an external event that the system sends or receives, it is modeled as a SendSignalAction[10] node or AcceptEventAction[10] node, respectively. Otherwise, it is modeled as an InteractionUse, which is regarded as a response to previous external event. If a sequence of steps is not mapped to any external event, like steps 6-8 of Table 2, it is modeled as one InteractionUse. The resulting diagram for main scenario of ”Cook” use case in this step is shown in Figure 3.

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing 0-7695-2561-X/06 $20.00 © 2006

IEEE

DoorOpened

ref

ref

ref

Door Closed

ref

DoorOpened

Door Opened

Door Closed

DoorClosed

DoorClosed ref

CookBtnPressed

CookBtnPressed

Door Opened

ref

CookBtn Pressed

CookBtn Pressed Add60Sec ToTimer

StartTimer

Add60Sec ToTimer

TimerExpired

CookBtnPressed

ref

Increase Cooking Time

StartTimer TimerExpired

ref

Cooking Complete ref

Figure 3. The diagram of main scenario of ”Cook” use case

Cooking Complete

Figure 4. The diagram after incorporating scenario 11a of ”Cook” use case

Step 4 : Incorporate alternative scenarios Now we finally construct basic interaction overview diagram for a use case by incorporating alternative scenarios into the diagram. An alternative scenario occurs when a certain condition is not satisfied or the system receives an external event such as an I/O interrupt. Thus we regard the first step of an alternative scenario as a DecisionNode[10] or AcceptEventAction in an InterruptableActivityRegion[10]. In case of step 11a in ”Cook” use case scenario, it is initiated by an external event;i.e. ”CookBtnPressed” event. So it is modeled as an AcceptEventAction. This causes the node which corresponds to step 11 of the scenario to be located inside an InterruptableActivityRegion. The resulting diagram, which incorporates the alternative scenario 11a, is shown in Figure 4.

2.4. Constructing Sequence Diagram As we stated earlier, we use sequence diagram to describe InteractionUse in interaction overview diagram. Thus, one sequence diagram represents a part of a use case scenario. In Section 2.3, we mapped one step or a sequence of steps of use case scenario into an InteractionUse node. So the sequence diagram for that node can be easily constructed by following the steps. When constructing sequence diagram, some modifications to the interaction overview diagrams may occur. For example, a DecisionNode and its subsequent nodes in interaction overview diagram could be hidden in an InteractionUse. Or a fragment in a sequence diagram could appear

in interaction overview diagram. These kinds of modification depend on the modeler. The modeler should decide the level of abstraction that the interaction overview diagrams show. The final interaction overview diagram of the ”Cook” use case is shown in Figures 5.

3. Code Generation Most of recent works related with embedded software modeling include automatic generation of executable code from model[11]. Usually they use state-based behavior model rather than interaction-based behavior model as the source of code generation. In our approach, executable code is generated by generating control-flow-graph(CFG) from the interaction-based behavior model. We have developed algorithms to generate CFGs from our model. Since this paper does not focus on the code generation, we will not describe about it. In addition to the code generation, we can simulate the model with the generated CFG. From the user-specified scenario, external events are identified as inputs for the simulation. Then the simulation engine traces the CFG according to the inputs, and displays the state of each object. By simulating the model, we can validate whether the model reflects the requirements well. Non-functional requirements, such as time constraints and concurrency requirements, could be checked with the simulation.

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing 0-7695-2561-X/06 $20.00 © 2006

IEEE

sd Cook

Acknowledgement ref

Waiting

DoorOpened

ref

Door Opened

DoorClosed

ref

Door Closed

CookBtnPressed

This work was supported in part by IT Leading R&D Support Project funded by Ministry of Information and Communication, Republic of Korea and by the MIC (Ministry of Information and Communication), Korea, under the ITRC (Information Technology Research Center) support program supervised by the IITA(Institute of Information Technology Assessment).

[Door.isOpen()==false] [Door.isOpen()==true] ref

sd Single Beep

CookBtn Pressed

Add60Sec ToTimer

OvenCtrl

Beeper StartTimer

beep()

CookBtnPressed CancelBtnPressed TimerExpired

ref

Cooking Complete

DoorOpened

Add60Sec ToTimer ref

CancelBtn Pressed

ref

DoorOpened

References StopTimer

Figure 5. The revised interaction overview diagram

4. Conclusion We have proposed an approach to model the behavior of embedded software using two interaction diagrams of UML 2.0;the interaction overview diagrams and sequence diagrams. For each use case scenario, external events are identified. Those external events are mapped to several steps in the use case scenario. Based on the mapping, one interaction overview diagram is constructed for each use case. The InteractionUse in the interaction overview diagrams are specified by the sequence diagrams. We also presented brief idea of generating executable code from it. Reflecting the alternative and failure scenarios as well as the main scenario of each use case, we argue that the constructed interaction overview diagrams show the whole behavior of use cases. Our approach enables intuitive behavior modeling by making the behavior model to be constructed following use case descriptions. Since it gives traceability between the use cases and the behavior model, the addition of new functionalities and the modification of existing ones can be done easily. And, by nesting the interaction overview diagrams and the sequence diagrams, our approach supports hierarchical modeling. That reduces the complexity of the model. Several works should be done to mature our approach. First, we are trying to generate state-based reachability graph from our interaction-based behavioral model as a branch subject. It will be helpful to validate our behavioral model. And we plan to apply our approach to the development of multi-processor system-on-chip(MPSoC) embedded software. To do that, we should investigate the method of partitioning and deploying the model according to the distributed hardware components. We also have to develop the way of verifying the partitioned model.

[1] K. Berkenkotter. Using uml 2.0 in real-time development: A critical review. Proceedings of SVERTS workshop, 2003. [2] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1999. [3] B. Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns. Addison-Wesley, 1999. [4] H. Eriksson, M. Penker, B. Lyons, and D. Fado. UMLT M 2 Toolkit. Wiley, 2003. [5] M. Fowler. UML Distilled 3rd Edition. Addison-Wesley, 2003. [6] G. Frick, B. Scherrer, and D. Muller-Glaser. Designing the software architecture of an embedded system with uml 2.0. UML 2004 Workshop on Software Architecture Description and UML, October 2003. [7] H. Gomaa. Designing Concurrent, Distributed, and RealTime Application with UML. Addison-Wesley, 2000. [8] B. Graaf, M. Lormans, and H. Toetenel. Embedded software engineering: The state of the practice. IEEE Software, November 2003. [9] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley Longman, 1999. [10] OMG. UML 2.0 Superstructure Specification (ptc/04-1002). Available from : http://www.omg.org. [11] T. Schattkowsky and W. Muller. Model-based design of embedded systems. Proceedings of the Seventh IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2004. [12] B. Selic. Using uml for modeling complex real-time systems. Proceedings of the ACM SIGPLAN Workshop on Languages, Compilers, and Tools for Embedded Systems, 1998. [13] S. Uchitel, J. Kramer, and J. Magee. Synthesis of behavioral models from scenarios. IEEE Transactions on Software Engineering, 29(2), February 2003. [14] K. Weidenhaupt, K. Pohl, M. Jarke, and P. Haumer. Scenarios in system development: Current practice. IEEE Software, 15, March-April 1998.

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing 0-7695-2561-X/06 $20.00 © 2006

IEEE