Behavioral Design Topics in Behavioral Design Based on
Behavioral Design Topics in Behavioral Design Based on Material in [Rosenblum 94][Budgen 94] [Ghezzi 91] [Harel 88] Software Design (Behavioral) © SERG
Behavioral Design Topics • State Transition Diagrams • Petri Nets • Higraphs and Statecharts Software Design (Behavioral) © SERG
State Transition Diagrams Software Design (Behavioral) © SERG
State Transition Diagrams (STD) • Systems exist in a finite set of possible states. External events are triggers that lead to transitions between the states. • Since most systems have many states, a partial model of the system may be a good compromise. • STDs are the cornerstone of more powerful diagrams for specifying system behavior, such as Petri Nets and State Charts. Software Design (Behavioral) © SERG
Partial Unix vi STD o i l Command Mode ZZ / : return ESC Text Insertion Mode Line Command Software Design (Behavioral) © SERG
Formal Definition of an STD Software Design (Behavioral) © SERG
Combination Safe STD Safe Locked 1 L any other dial movement 1/3 Unlocked 3 R 2/3 Unlocked any other dial movement 2 L Safe Unlocked any other dial movement Sound Alarm Software Design (Behavioral) © SERG
stop Compiling IDE STD run Compiled error events Start stop success finished stop pause Running no events hiccup resume events Pausing events Executing Software Design (Behavioral) © SERG
Petri Nets Software Design (Behavioral) © SERG
A Simple Petri Net P 1 t 1 P 2 t 3 t 2 P 3 Software Design (Behavioral) P 4 © SERG
A Marked Petri Net P 1 t 1 P 2 t 3 t 2 P 3 Software Design (Behavioral) P 4 © SERG
A Marked Petri Net After Firing t 1 P 1 t 1 P 2 t 3 t 2 P 3 Software Design (Behavioral) P 4 © SERG
Definition of a Petri Net • PNet = (P, T, A, M 0) – P is a finite set of places (labeled circles), where a place holds tokens. – T is a finite set of transitions (bars), where a transition represents an activity. – A is a finite set of directed arcs, where an arc connects a place and a transition. – M 0 is the initial marking of PNet, where a marking is an arrangement of tokens in places representing state. Software Design (Behavioral) © SERG
Petri Net Execution Model • Input Place: Place P is an input place for transition T if there is an arc from P to T. • Output Place: Place P is an output place for transition T if there is an arc from T to P. • Enabled Transition: A transition is enabled if there is at least one token at each of its input places. Software Design (Behavioral) © SERG
Petri Net Execution Model (Cont’d) • Firing a Transition: An enabled transition is non deterministically selected and fired by removing one token from each of its input places and depositing one token at each of its output places. • Firing Sequence: A firing sequence <t 0, t 1, …, tn> such that t 0 is enabled and fired in M 0, t 1 is enabled and fired in M 1, . . . Software Design (Behavioral) © SERG
Petri Net Firing Software Design (Behavioral) © SERG
A Petri Net Describing an ATM Machine Ready Valid Card Accepted Notes in Dispenser Correct Pin Valid Request Sufficient Funds Card in Slot Sufficient ATM Cash Software Design (Behavioral) © SERG
A Marked Petri Net Semaphore IN 1 IN 2 IN = Input of Process OUT = Output of Process CR = Critical Region SEM = Semaphore CR 1 SEM OUT 1 CR 2 OUT 2 Software Design (Behavioral) © SERG
Enabled Transitions IN 1 CR 1 IN 2 SEM OUT 1 CR 2 OUT 2 Software Design (Behavioral) © SERG
After Non-Deterministic Firing IN 1 CR 1 IN 2 SEM OUT 1 CR 2 OUT 2 Software Design (Behavioral) © SERG
Enabled Transition IN 1 CR 1 IN 2 SEM CR 2 OUT 1 OUT 2 Software Design (Behavioral) © SERG
After Firing IN 1 CR 1 IN 2 SEM CR 2 OUT 1 OUT 2 Software Design (Behavioral) © SERG
Petri Net Static Analysis • Invariants are properties of a Petri net that hold (are true) in all markings. • For example, the sum of all tokens in CR 1, CR 2, and SEM are equal to 1 in all reachable markings. That is, |CR 1| + |CR 2| + |SEM| = 1 Software Design (Behavioral) © SERG
Deadlock and Starvation • A Petri Net with a given marking is in deadlock iff no transition is enabled in that marking. • A Petri Net with a given marking is in starvation iff one or more transitions have been permanently disabled. • A Petri Net is live if every transition can eventually be fired. Software Design (Behavioral) © SERG
A Deadlocked Petri Net Software Design (Behavioral) © SERG
A Petri Net that can Enter a Deadlocked State Software Design (Behavioral) © SERG
A Deadlocked Petri Net Software Design (Behavioral) © SERG
Modification into a Live Petri Net Software Design (Behavioral) © SERG
A Petri Net that can go into Starvation t 1 t 2 t 3 t 4 Software Design (Behavioral) © SERG
Starving Transitions t 2 and t 4 t 1 t 2 t 3 t 4 Software Design (Behavioral) © SERG
Shortcoming of Basic Petri Nets • The Simplicity of building blocks leads to complexity in nets. • For example, a semaphore of N processes requires 2 N transitions and 3 N+1 places. • Would like: – Enable and fire as computations. – Tokens as data, not just control. – Ability to reduce high-level Petri nets to basic Petri nets for analysis. Software Design (Behavioral) © SERG
Higher-Level Net Semaphore 19 71 p s s > 0 transition predicate p s-1 token value 3 p s true p s+1 Software Design (Behavioral) arc expression © SERG
Enabled Transition 19 71 p s s > 0 transition predicate p s-1 token value 3 p s true p s+1 Software Design (Behavioral) arc expression © SERG
After Firing 19 p s s > 0 transition predicate p s-1 71 token value 2 p s true p s+1 Software Design (Behavioral) arc expression © SERG
Enabled Transitions 19 p s s > 0 transition predicate p s-1 token value 2 71 p s true p s+1 Software Design (Behavioral) arc expression © SERG
After Firing p s s > 0 transition predicate p s-1 19 token value 1 71 p s true p s+1 Software Design (Behavioral) arc expression © SERG
Enabled Transition p s s > 0 transition predicate p s-1 19 token value 1 71 p s true p s+1 Software Design (Behavioral) arc expression © SERG
After Firing p s s > 0 transition predicate p token value 2 71 p s true 19 s-1 p s+1 Software Design (Behavioral) arc expression © SERG
A Software Change Process New MRs 19 7 Approved MRs true 33 11 8 (MR) (Developer) true (MR, Developer) (MR) Olga Tom Tony (MR, Developer) Maria (MR, Developer) Assigned MRs true (MR, Developer) Completed MRs Software Design (Behavioral) © SERG
After Firing (New Assigned MR) New MRs 19 Approved MRs true 33 11 8 (MR) (Developer) true (MR, Developer) 7, Tom (MR) Olga Tony (MR, Developer) Maria (MR, Developer) Assigned MRs true (MR, Developer) Completed MRs Software Design (Behavioral) © SERG
After Firing (New Assigned MR) New MRs 19 Approved MRs true 33 11 (MR) (Developer) (MR, Developer) (Developer) true Tony Maria (MR, Developer) (MR, 8, Olga Developer) 7, Tom Assigned MRs true (MR, Developer) Completed MRs Software Design (Behavioral) © SERG
After Firing (New Completed MR) New MRs 19 Approved MRs true 33 11 (MR) (Developer) (MR, Developer) (Developer) true (MR, Developer) (MR) Tony Maria (MR, Developer) 7, Tom Assigned MRs true (MR, Developer) 8, Olga Completed MRs Software Design (Behavioral) © SERG
After Firing (New Assigned MR) New MRs 19 Approved MRs true 33 (MR) (Developer) (MR, Developer) (Developer) true Maria (MR, Developer) (MR, 11, Tony Developer) 7, Tom Assigned MRs true (MR, Developer) 8, Olga Completed MRs Software Design (Behavioral) © SERG
After Firing (New Approved MR) New MRs 19 Approved MRs true 33 (MR) 8 (Developer) (MR, Developer) (Developer) true Olga Maria (MR, Developer) (MR, 11, Tony Developer) 7, Tom Assigned MRs true (MR, Developer) Completed MRs Software Design (Behavioral) © SERG
Higraphs and Statecharts Software Design (Behavioral) © SERG
Higraphs • Higraphs are based on: – Euler graphs – hypergraphs – Venn diagrams Graph Hypergraph Q^R Q R P^Q^R P^Q P^R P Software Design (Behavioral) © SERG
Higraphs Supports Cartesian Products. A B D F C G H J P O T K Q S R I L N M E Software Design (Behavioral) © SERG
Formal Definition of a Higraph Software Design (Behavioral) © SERG
Specialized Higraphs: State Charts • State Charts are a higraph-based extension of standard state-transition diagrams, where blobs represent states and arrows represent transitions. • State Charts = state diagrams + depth + orthogonality + broadcast communication Software Design (Behavioral) © SERG
Depth of State Charts D A A e e f g(c) B g(c) f B f C h • e, f, g, h: events that trigger the transitions • g(c): is the transition by event g when condition c is true. • Being in state D means being in one of states A or C. • The f arrow leaving D applies to both A and C. • A is the default state. • C is the default state when in D. Software Design (Behavioral) © SERG
Orthogonality of State Charts Y A D B k E G H n e e F e C, E m I g k p n H Software Design (Behavioral) g rp C g h B, E h B, F mo f [in{G}] e k C, F h e p mo rp e B, G e f C, G p e I © SERG
Broadcasting of State Charts Y A D B e k E f/g C n F g G H e m/e I n/f J Software Design (Behavioral) © SERG
State Chart Describing ATC in flight take off cruising on ground parked stacked taxiing landing approach touch down Software Design (Behavioral) © SERG
State Chart Describing a Computer CPU Computer Main Memory Fetching Instruction instr. cmpl. instr. avail. Execution Instruction get. Addr put. Addr Waiting for Request Put Addr. Data Written Data Read Get Addr. Memory Write Cycle Read Cycle Software Design (Behavioral) © SERG
Display State of Digital Watch displays update hour c c date min c sec c date b d d time c a a stopwatch alarm a b c up-alarm c hour 2 -min [not in(stopwatch)] c min sec c Software Design (Behavioral) © SERG
Stopwatch State of Digital Watch time a stopwatch zero d [in(off)] b disp b reg d [in(on)] on d lap run b b off Software Design (Behavioral) © SERG
High-Level Description of Digital Watch dead alive main power displays weak strong bt-weak light b on beep-rt t-hits-tm [in(enable)] beep off b-up alarm-state d[in(alarm)] enable disable d[in(alarm)] Software Design (Behavioral) © SERG
State Chart of Digital Watch dead bat-in alive power 2 -min [not in(stopwatch)] main displays update hour min c sec date d disp run reg on d lap beep-rt b alarm b c on off b-up up-alarm b off light b a b strong bt-weak time c a b weak d c stopwatch zero d date b c c d bat-rn hour c sec alarm-state c min c beep t-hits-tm [in(enable)] d[in(alarm)] enable disable d[in(alarm)] Software Design (Behavioral) © SERG
References • [Rosenblum 94] D. Rosenblum, A. L. Wolf, Formal Software Engineering, Tutorial SIGSOFT’ 94 FSE, New Orleans, Dec. , 1994. • [Budgen 94] D. Budgen, Software Design, Addison. Wesley, 1994. • [Ghezzi 91] C. Ghezzi, M. Jazayeri, D. Mandrioli, Fundamentals of Software Engineering, Prentice-Hall, 1991. • [Harel 88] D. Harel, On Visual Formalisms, CACM, Vol. 31, No. 5, 1988. Software Design (Behavioral) © SERG
- Slides: 59