Formale Techniken in der Software-Entwicklung Verfeinerungskonzepte für Zustandsdiagramme Christian Prehofer in Zusammenarbeit mit Christian Kroiß SS 2011
Überblick Vorlesung Block 3: Verfeinerung von Zustandsdiagrammen Motivation, Beispiel Verfeinerungskonzepte und Regeln 2 Literatur Cornel Klein, Christian Prehofer und Bernhard Rumpe, Feature Specification and Refinement with State Transition Diagrams, In: Fourth IEEE Workshop on Feature Interactions in Telecommunications Networks and Distributed Systems, IOS-Press, 1997. Christian Prehofer, Plug-and-Play Composition of Features and Feature Interactions with Statechart Diagrams, Sosym, 2004, Springer-Verlag
Refinement Concepts and Statecharts 3 Goal: Statecharts to describe behavior of objects Here, focus is on specification, less implementation Semantics is loose, i.e. all behavior which is compatible with the specification is permitted Behavior is modeled by traces on Input/Output Black-box view of a component Only consider stream of input and output events as behavior This is considered a trace of a system An automaton specifies many possible traces
Statecharts Statechart describes behavior of an object Transition by external function call or internal action called_function() [condition] / action This creates trace of input/output events Also internal and silent transitions possible
Example Statechart Model 5
Refinement on Statecharts Refinement of a statechart means to add behavior Or implementation detail 6 Refinement as system development process Start simple and add more details incrementally Semantic view on refinement Refinement can restrict behavior, but not invalidate all traces Establishes compatibility Refined statechart can be used in place of original one
Email arrived deliver() Waiting Verfeinerung Kompatibilität incoming() deliver() Plain Mail {reply_active} Reply Verfeinerung Hinzufügen von Details Weiterentwicklung /decrypt() {reply_inactive} {mail_wasencrypted()} / replycrypto() / BasicEmail.deliver() Reply Done {else} /reply() Email arrived incoming() Waiting
8 Correct Graphical Refinement Rules 1. Addition of new states. New states may be introduced, since they are unreachable and therefore do not affect the behavior. 2. Removal of states. Likewise, states which are not reachable may be removed. 3. Refinement of states. A state may be partitioned into several ones, if all transitions leaving or ending in the state are partitioned accordingly. 4. Addition of transitions. If in a state s no transition exists for a certain input i, the behavior of the component sfor the input is completely unspecified. Therefore, an arbitrary set of transitions labeled with as source state and as input message can be added. 1. Note, that if an internal transition with the same source state exists and the precondition does not evaluate to false, the internal transition can always be taken and therefore no addition of transitions is allowed. 5. Removal of transitions. If in a state several transitions with the same input message exists, then one of them is chosen nondeterministically or some transition is taken. Therefore, these transitions may be removed, as long as there exists at least one transition labeled with this input or with 6. Removal of initial states. Initial states may be removed, as long as at least one initial state remains.
Feature-oriented Design with Statecharts Modularity for statechart diagrams Cross-cut complex statecharts into small parts (features) Modular composition of statecharts from features Graphical description of features Features & interactions are specified with partial statecharts Refinement rules for combining partial statechart diagrams Based on refinement concepts for statechart diagrams Interaction handlers ( adaptors ) as a glue for combining features Adaptors are represented graphically
Example Telecomunication: Features to be modeled 10
Basic Model of a Call 11
12 Adding new states Abandoning Phone Calls
13 State Refinement Subscriber / Phone Abstraction
Call Blockiging Features 14
Call blocking and Forwarding 15
Example: Email Features Features of an Email System (R. Hall, FIW 2000) Encryption of Emails Forwarding Emails Auto-reply Filtering of Emails Virus scanner... Feature Interactions Encryption and Forwarding forward only encrypted Encryption and Auto-reply Titel of email sent in plain as reply
Feature-based Design with Statecharts Problem: Statecharts can get large and bulky Goal: Modular representation of features of a statechart Composition of statecharts from Features Object specification: statechart Feature: partial statechart Feature composition: statechart refinement Modular development of statecharts from features
Feature model with partial statecharts Example: 3 features which add states domaintenance() Email Error resume() entermaintenance() Mainten ance error() leavemaintenance() Email arrived deliver() Waiting incoming()
Classes of Features/Statecharts 1. Base features with a complete statechart includes an initial state. 2. State-oriented features with a partial statechart some states and transitions, but initial/final states not required E.g. feature MaintenanceMode with one new state Only reachable by new transitions from other features. 3. Transition-oriented features which define transitions No (persistent) state Interaction specification ( adaptors ) according to these classes Combination rules according to these classes
Combination of 2 Features Email Error error() resume() Email arrived deliver() Waiting incoming()
Composition as Semantic Refinement Use Chaos -Semantic based on external black box view Permit as many traces as possible If unspecified action occurs, anything is possible ( chaos ) Refinement shall adds specific details Reduces the number of possible traces Refinement steps for statechart diagrams Add new behavior, which was not specified before e.g. add new states and new transitions Eliminate transitions if alternatives exits Add internal or compatible behavior; do not change old behavior Need to abstract from new operations E.g. refine transition by statechart with internal transitions only Eliminate/restrict transitions for exceptional cases Conditional refinement
Combination of 3 Features error() Email Error entermaintenance() resume() entermaintenance() Mainten ance domaintenance() [ noerrors] / leavemaintenance() Email arrived deliver() Waiting incoming()
Feature Description (2) Forwarding and Auto-Reply Features Transitions with internal actions Feature Forwarding: forward() {forward_active} Forward /do_forward() {forward_inactive} Feature Reply: reply() {reply_active} Reply /do_reply() {reply_inactive}
Combination Rules for Features Combination by refinement of transitions Rules for adapting one feature to the other ( interaction handling ) BasicEmail Decryption/Forwarding Refinement describes the internal behavior of a transition by a statecharts BasicEmail Decryption: deliver() /decrypt() Plain Mail /deliver() BasicEmail Forwarding: deliver() /forward() Fwd Mail /deliver()
Basic Email and Forwarding deliver() Transition Refinement [forward active] Forward /do_forward() [forward inactive] Fwd Mail /BasicEmail.deliver() Email arrived deliver() incoming() Waiting
Combination of 3 Features (1) Basic Email, Forwarding and Decryption deliver() Forward /do_forward() Fwd Mail [forward_active] [forward_inactive] /decrypt() /BasicEmail.deliver() Plain Mail Email incoming() arrived Waiting
Combination of 3 Features (2) Basic Email, Auto Reply und Decryption deliver() Plain Mail {reply_active} Reply {mail_wasencrypted()} / replycrypto() {else} /reply() /decrypt() {reply_inactive} / BasicEmail.deliver() Reply Done Email arrived incoming() Waiting
Conclusions Cross-cutting state description diagrams Modularity concepts for statechart diagrams Supports flexible composition of features Classify different kinds of partial statechart diagrams Main benefit is graphical combination of features Compose just models of desired features Includes feature interactions Different variations or extensions of a software component are needed.