MODELLING THE UNEXPECTEDBEHAVIOURSOF EMBEDDEDSOFTWAREUSING UML SEQUENCEDIAGRAMS Hee-jin Lee, In-Gwon Song,Sang-UkJeon,Doo-Hwan Bae Department of EE and CS,KAIST, Daejeon, Republic of Korea leehj, igsong, suj eon,
[email protected]
Jang-EuiHong School of Electrical & Computer Engineering, Chungbuk National University, Cheongju, Korea j
[email protected]
Keyrvords: Embeddedsoftware,Exceptional behaviourmodelling, UML Sequencediagram. Abstract:
Realtime and embeddedsystemsmay be left on unexpectedstatesbecausesystem'suser can generatesome incident eventsin various conditions.Although the UML 2.0 sequencediagramsrecently incorporateseveral modelling features for embedded software, they have some difficulties to depict unexpected behaviours of embeddedsoftware conveniently.In this paper,we proposesome extensionsto UML 2.0 sequencediagrams to model unexpectedbehaviours of embeddedsoftware. We newly introduce notations to describe exceptions and interupts. Our new extensions make the sequencediagrams simple and easy to read in describing such unexpectedbehaviours.These featuresare explainedand proved with an example of call-setupprocedureof CDMA mobile ohone.
1 INTRODUCTION Thedevelopment of embedded software is getting moreattention by researchersand developers as the sizeand complexity of embedded software increase. Embeddedsoftware has special requirements on timing,performance,and device interface.Moreover, thereare some considerationsin embeddedsoftware modelling as follows: -
Embeddedsoftware has timing constraintsin theaspectsof soft real-time or hard real-time. - Eventsfrom input and to output are limited to specificresources. - It is impossibleto forecastwhen the input eventsfrom external users occur.
Embedded softwareis a reactivesystem.Depending onthe input events, adequatebehaviour should be performed. There are mainly two types of embedded software behaviours.First, predefined behaviour is executed by expectedinputs. Second,unexpectedor abnormalbehaviour occurs by undefined inputs whicharefrom usersor environmentsunexpectedly. Notto mention the importance of the first case, the
secondcase is also important in embeddedsystem, becauseunexpectedinput may causethe systemhalt or do harm. Therefore, the reactions for unexpected inputs as well as normal or defined inputs should be consideredin the modelling of embeddedsoftware. It is known that sequencediagrams in UML are adequateto model the dynamic system behaviours. The latest release of it, version 2.0, incorporates several notations for the modelling of embedded software.Although the representationof unexpected behavior,rssuch as intemrpts or exceptions in standard sequence diagrams is possible, the sequence diagrams describing those behaviours 'Ihus, becomecomplicatedand intricate. we propose extended notations with the def-rnition of their syntaxes and semantics to avoid unreadable sequence diagrams in describing unexpected behaviours. We also explain and show the effectiveness of the unexpected behaviours modelling in the aspectsof readability, abstraction, and simplicity. The rest of this paper is organizedas follows.: Section 2 explains the characteristics and the usefulness of sequence diagrams and Section 3 describesour extensionsof sequencediagrams for embedded software. Section 4 comDares our
257
CONFERENCE ON SOFTWAREAND DATA TECI$iOLOCIES ICSOFT2006- IN-TERNATIONAL
extended sequence diagrams and MSCs with example scenarios. Section 5 addressesrelated works. Finally, Section 6 concludesthe paper and discussesabout future work.
2
BACKGROUND
When describing the dynamic behaviours of a systemwith UML, we use sequencediagrams,state machine diagrams,and activity diagrams(Douglass 2004). The activity diagram is a model to describea business process or a method of a class. The statemachinediagram describesthe states and the actions of each object in its lifetime. Although the activity and statemachine diagrams are capable of modelling the dynamic behavioursof the system,the sequencediagrams seem to be more practical for software engineers in industry to describe the behaviours of embedded systems. It is because sequencediagramsare suitableto draw models from requirements straightforwardly and easy to understandfor developers.Also, they describe the global interactionsas well as the partial behaviours between objects.Due to the intuitiveness,sequence diagrams are generally preferred to the statemachine diagrams for describing software behaviours. ln addition to the usefulness of sequence diagrams as described above, UML 2.0 sequence diagrams become more expressive in system behavioural modelling by consolidating the inline expressionsand the time concepts of MSCs (ITU 1999, Mauw 2000, Damm 2001, Haugen 2004, and Haugen2001). Even though the expressivepower ofsequence diagramsis enhanced,the modelling of unexpected behaviours often causes redundancies of other behaviours and makes sequence diagrams unreadable. Unexpected behaviours such as interruptsand exceptionsare generallycontrolledbv sysremcalls of the operating system.However, we focus on special situations that those unexpected behavioursshould be handledin applicationlevel or in bare machine which has no operating system. From thesemotivations,we realizethat the UML 2.0 sequence diagrams should be extended to describe unexpected behaviours of embedded software.
2-58
3 MORE FEATURESIN SEQUENCEDIAGRAMS Exceptions and interrupts occur frequently in the operations of embedded software. Therefore,they should be represented in sequence diagramsto depict unexpected behaviours in a view of userdefinedevent modelling. -:
*prof'le----l Emherlrjedsuom.i
I
! qLh afiqrcai llcratur I,n ,elerirlrcrorsr.irY
dsllrsl
l l
Figurel: UML profilefor extended sequence diagrams.
We extend the combined fragmentsof sequence diagrams to describe the handling of exceptionsand interrupts. Extended interaction operators are 'try' for an exception handling and 'intemrpt' for an intemrpt handling. An exception scenario is recognized as an unsuccessfulscenario. It occurs when certain constraintsare not satisfied.Generally, an intemrpt is controlled by system calls of the operating system. I{owever, we define an intemrpl of as one of the events that occurs in the scenarios applicationlevel. When an exceptionor an intemrpt occurs, the execution of the current scenanols stopped and a handling scenario is executed. lrruwu/€1, inerc are ciriierences between the handlings of two unexpected scenarios. The occurrenceof an exception is dependenton cunent executing action. However, an interrupt occurs regardless ofthe currentaction. Figure I shows an UML profile (Eriksson2003) for our extension of exceptions and intemrpts in embeddedsoftware.A stereotype'Catch' anda class 'Exception' 'try' are added for interactionoperator. 'Catch' The stereotype is a kind of the stereotype 'Message'. The inherited classes from the class 'Exception' are selectively used in sequence diagramsaccordingto their properties.
USINCUML SEQUENCL BEHAVIOURSOF IMBEDDED SOFTWz\RE MODELLINGTHE LINEXPECTED DIAGRAN4S
3.1 Exception Handling Fragment UML 2.0 s€quence diagrams do not provide notations for specifliing or handling exceptions. 'try' which Therefore, we introduce a fragment handlesexceptionalbehaviour.The processingof an exceptionis consideredin two aspects:a raising and a handling(Stonle 2004). The exception raising is described with three parts:the trigger, the scope of readiness,and the scope of preemption (Stonle 2004). Under our notation,the trigger is one of 'DurationConstraint', 'TimeConstraint'and 'Statelnvariant'.The scope of readiness is a place or a point that the exceptioncan arise, and the scope of preemption is the first operandof 'try' fragment.
Figure 2 shows an example scenarioof playing 'FrameDecoder'decodesmovie movie files. Object 'DisplayDevice' files and sendsthe decodeddata to object. If the decoding is not completed within certain duration, a DCE exception will occur. The bottom fragment in Figure 2 shows the handling of suchexceotion.
Table1: Symbolsusedin interaction operator'try'. SYMBOL
FEATUf]E
Fragment
try'
F,"==,'.=,".". > Catch(el)
Catch message
An exceptioncan occur during the execution of 'try' fragment. When normal scenarios within the the exception occurs, an appropriate handling scenariowill be performed. Symbols used for an handling'try' are shown in Table l. exception InteractionOperator'try' : The cornbined fragment'try' consistsof two or more fragments.The first fragment describesa scenarioin which exceptionsmay occur.Each fragmentof the rest describesthe handling scenarioof eachof thoseexceptions. Catchmessage:Catch messagewith stereotype 'Catch'recognizesException'e1'occurs in the first fraement. Thereare three kinds of exception types; DuratronTimeConstra ConstraintException (DCE), intException(TCE) and StatelnvariantException (SlE)(Goodenough 1975,Strohmeier2001). -
-
DCE is on the handling of durationexception. If an eventis not progressedwithin a predefinedduration,DCE will occur. Whenan eventdoesnot happenat a particular time,TCE occurs. Sid occurt
satisfied.
wiv-ri
