Łabiak G., Miczulski P. (IIE, UZ, Zielona Góra, Poland)

Transcription

1 UML STATECHARTS AND PETRI NETS MODEL COMPARIS FOR SYSTEM LEVEL MODELLING Łabiak G., Miczulski P. (IIE, UZ, Zielona Góra, Poland) The system level modelling can be carried out with using some miscellaneous models. Two of such models are UML statecharts and Petri nets. The main goal of this paper is to show the common features and the main similarities and differences between UML statecharts and Petri nets and point out the mutual relationship between these models. 1. Introduction Recent advances in information technology caused that embedded systems gain more and more popularity. This situation poses a new challenge to modern engineers, forcing them to pay particular attention to functionality of the system under design [4][6]. For average potential end-user functionality is the ultimate determinant of satisfaction gained from acquired device. Hence, system level modelling, where functionality is a focal point, carried through in thoughtful and thorough way has decisive impact on final commercial and market success of a designer and his company. 2. System level modelling The system level modelling can be carried out with using various approaches, concerning different aspects like activities, behaviour or modules [6]. Every aspect is essential, but it seems that behavioural model plays central role affecting modules and activities and controls data exchange. Modelling behaviour often is realised by engineers with strong support of contracting party. The latter usually does not have technical education, he rather knows what a system should perform than how, and yet modelled behaviour can be very complex. Hence, from one side, desired behaviour modelling methodology should be capacious enough to model complex behaviour and on the other side, easy to understand for non-specialist, to document project. These rather opposite requirements have been met in Petri nets and statecharts. Historically, Petri nets have been created as a mathematical model of concurrent computation [8]. Basically, Petri nets are natural extension of sequential automata and their great appeal is intuitive graphical notation. In this model local states are depicted as circles and transition as bars, interconnected with oriented arcs, which determine direction of control flow. Today Petri nets gained numerous applications, for example, in modelling logistic systems, databases and in designing real time digital controllers of embedded systems. The main drawback of Petri nets is lack of means which support abstract modelling, it means that designer is always forced to deal with the smallest details (place, transition) instead of general notions which prevent from top-down approach. This disadvantage was a main motivation for developing of statecharts. Statecharts were invented as a visual formalism for complex systems [5]. Similarly to Petri nets, they offer

2 support for sequential automata and concurrency. But unlike Petri nets, they provide means for hierarchy, with the help of it a designer can apply top-down approach. Graphically, embedding state transition graph of sequential automaton within boundary of compound state represents hierarchy. In case of concurrency, in the diagram, two or more sequential automata are separated with a dashed line. Actually, statechart diagrams are mainly known as graphic notation in UML technology, where they are used in program object modelling [9], but their popularity is growing rapidly. Since their conceiving Petri nets have been subjecting very thorough research, which yielded solid mathematical apparatus and numerous algorithms and techniques of various application domains. Their syntax and semantics are firmly established, especially taking into account their application in digital controller design [1][3]. In this regard statechart diagrams are still premature. There are still some syntax and semantics issues which needs to be resolved. It seems that researching statechrts it is worthily to know Petri nets theory and relationship between the methodologies. 3. Behavioural characteristics This chapter presents main characteristic of UML statecharts and hierarchical Petri nets. Sequentiality, concurrency, hierarchy of states, communication and synchronisation issues of both semantics are compared. 3.1 Sequentiality Sequentiality means activity at most one state of automaton and there is no essential difference between the models (Fig. 1). predicates STATECHART snd / {change} mt / {change} snd change Sound do / {loud} Mealy type output PETRI NET mt change loud Moore type output Fig. 1. Equivalence of sequential automata A single state of UML Statechart directly responds to a place in Petri net. For example the states NORMAL and TVTEXT ( and also) in statechart diagram are the places in Petri nets. Fig. 1 depicts, so called, interpreted Petri nets, it means that the net through reaction on input signals generates output signal to its environments. Depending on how generated signals (or events) are assigned to places or transitions, there are two kinds of interpreted Petri nets, respectively, Moore and Mealy type. In both notations Mealy s output are those events associated with transitions. When transition fires event or events are broadcast. To fire transition it is necessary to fulfil predicate imposed on transition. Moore type output are those assigned to states or places. As long as a place or state

3 is active, event or events assigned to it are broadcast. In case of UML statecharts it is executed by do action. 3.2 Concurrency The concurrency means activity two or more sequential automata simultaneously and is equally obvious like sequentiality. Fig. 2 (statechart taken from [9]) depicts the main idea of equivalence of concurrency between two models. Transition T1 represents forking control in two separate sequential automata, while transition T2 joins control. Transition T2 also synchronises these two automata, it means that state or place CLEANUP will be active after both states A2 and B2 are active. It is essential to recollect, that transition is enabled when every input place (state) has a token (is active) and that firing transition removes tokens (activity) from its all input places (states) and transfer them (activity) to its all output places (states). SETUP T1 A1 B1 PROCESS A2 B2 T2 CLEANUP fork transitions SETUP T1 PROCESS A1 A2 T2 join transitions CLEANUP 8 B1 B2 Fig. 2. Equivalence of concurrency 3.3 Hierarchy Hierarchy is powerful methodology, which allows dealing with complexity in elegant manner. Behaviour can also be modelled in hierarchical way, as a result yielding relation between more overall behaviour and its more detailed subordinated behaviours. exception transition off on Picture Sound basic state p1 t1: on t6: off NORMAL t8: off t2 t3 txt* t4 t5 p2 NORMAL txt* txt* TVTEXT snd* mt* macro transition txt* t7: off TVTEXT snd* mt* t9: off abstract state macro t10 Fig. 3. Statechart with hierarchy and equivalent Petri net As far as grouping behaviour is concerned both methodologies offer equally convenient measures. In statecharts case there are composite states whom other

4 automata (sequential or concurrent) representing behaviours can be ascribed. In Petri nets specified behaviour can be arranged in structure of interconnected macros called macronet [3]. The main difference between those two methodologies relies on modelling transition that removes activity from states subordinated to its source state and transfers it to the target state. Transitions of this type sometimes are called abstract or exception transitions. To describe this case in statecharts, it is enough to draw one arc. Transition from state to state (Fig. 3) can serve as an example. To realise this in Petri nets with macros, it is necessary to introduce additional transitions (t6, t7, t8, t9 and t10) and places (p1, p2) which, when event off come, transfer token to the place located outside macro [7]. 3.4 Synchronisation and communication The standard means of synchronisation of concurrent processes is synchronisation transition (see also chapter 3.2 and Fig. 2), which finishes some concurrent processes. synch states START helper places END Fig. 4. Example of automata synchronisation Sometimes, besides simultaneous ending parallel processes, there is a necessity to assure their synchronous run, for example, when one region leaves a particular state before another region can enter a particular state. In Fig. 4 (statechart taken from [9]) is shown that before electricity can be installed in frame of a building, the frame must be built. In UML statecharts it is realised by means of pseudo states called synch states (oval with a star inside, located on a border of two concurrent regions) and fork and join transitions. In classic Petri net [8] synch states are replaced with helper places. In case of Petri nets used for digital controller design [1][2][3], the same behaviour can be achieved by inhibitor and enabling arcs (Fig. 5). An inhibitor arc allows the absence of token in a place to be tested, and so it disables a transition

5 when the place has token. An enabling arc is used to test for the presence of token in a place, and so it enables a transition when the place has token. In comparison with classic Petri net, this solution can decrease hardware resources consumption. enabling arc START END inhibitor arc Fig. 5. Petri net with inhibitor and enabling arcs The main communication means are events or in case of hardware implementation signals. Events are mainly generated through firing transitions or through action assigned to state (places, see Fig. 1). UML statecharts offer yet another possibility for generating events. Every state can be attributed entry action and exit action, it means that set of events is broadcast when, respectively, state is activated or losing activity. Generated events can be part of predicates imposed on transition, thus can serve as simple synchronisation mechanism. 4. Summary As far as sequentiality and concurrency are concerned UML statecharts and Petri nets offer similar measures. The main difference concerns abstract transition by which statecharts allow to model in abstract way. Pointing out similarities and differences between both notations make Petri nets theory fertile substrate in the research on statecharts semantics. Moreover, not every behaviour can be modelled by means of statechers and vice versa not everything can be easily modelled in Petri nets. So, it seems that it would be interesting to join those two methodologies together, because, they can complement each other. The scientific work is sponsored by State Committee for Scientific Research in the years as a research project number 4 T11C References: 1. M. Adamski, SFC, Petri Nets and Application Specific Logic Controllers, Proc. of The IEEE Int. Conf. on Systems, Man and Cybernetics San Diego, USA Nov. 98, ss K. Biliński, Application of Petri Nets in parallel controllers design, PhD. Thesis, University of Bristol, Electrical and Electronic Engineering Department, Bristol, J.M. Fernandes, M.Adamski, A.J.Proenca, VHDL Generation from Hierarchical Petri Net Specifications of Parallel Controllers, IEE Proc.: Computers and Digital Techniques, no. 144, vol. 2, Mar., 1997, pp D.D. Gajski, F.Vahid, S.Narayan, J.Gong, Specification and Design of Embedded Systems, Prentice Hall, Englewood Cliffs, New Jersey, D. Harel, Statecharts: A visual formalism for complex Systems, Science of Computer Programming, Vol.8, D. Harel, M. Politi, Modeling Reactive Systems With Statecharts: The Statemate Approach, McGraw Hill Text; ASIN: ; October 8, 1998 [54] 7. G. Łabiak, Modelling Statecharts Diagram by Means Of Petri Nets, VI Interantional Conference on Advanced Computer Systems, Szczecin Poland 1999, pp C. A. Petri, Kommunikation mit Automaten, Ph.D. thesis, Technical University of Darmstadt, UML Resource Center, Rational Software Corporation 2002,