The Fujaba Statechart Synthesis Approach

Size: px

Start display at page:

Download "The Fujaba Statechart Synthesis Approach"

Elinor Morrison
5 years ago
Views:

1 The Fujaba Statechart Synthesis Approach Thomas Maier, Albert Zündorf University of Kassel, Germany Abstract The Fujaba project tries to provide tool support for iterative software development with the UML. Each iteration starts with a textual scenario description for some new usecase. Then this textual scenario is refined by UML scenario diagrams, i.e. activity diagrams or collaboration diagrams or sequence diagrams. Along with these scenarios, we derive class diagram elements for all used kinds of objects, relations, attributes and messages. From such UML scenarios we try to systematically derive precise operational UML specifications for the behavior of employed active objects and for the used methods. Combining the class diagram and these precise behavior specifications, the Fujaba environment generates the whole Java code of the desired system. In [Mai02] Fujaba has been extended by a generator that derives statecharts from sequence diagrams according to the ideas of the SCED [KMST94] and the MAS system [KMS01]. In addition, we adapted some ideas from [WKS02] and [WKS03] concerning higher level statechart features like complex states and history states. This paper discusses our sequence diagram extensions and outlines our statechart synthesis algorithm. 1. Introduction The Fujaba environment is a free, open source, UML based CASE tool trying to provide roundtrip engineering support for all project phases, cf. [Fu03]. The core of Fujaba already provides reasonable roundtrip functionality for the design and implementation phases, i.e. Fujaba has code generators for class diagrams, statecharts, activity diagrams and especially collaboration diagrams, and Fujaba has reverse engineering functionality from Java code to the just mentioned UML diagrams (only reverse engineering of statecharts is not yet implemented). Fujaba supports a software development process called Story Driven Modelling (SDM). SDM is an iterative software development process where each iteration realizes one usecase. In the requirements definition phase, the usecase is described using textual scenario description. In the analysis phase this textual scenario description is refined using UML scenarios, i.e. a combination of activity diagrams, collaboration diagrams and sequence diagrams. In parallel, the class diagram is extended by appropriate declarations for all object kinds, attributes, relations and method invocations that are employed in the scenario diagram. In the design phase, the user systematically derives precise operational UML specifications for the behavior of methods and active objects. From such a behavior specification together with the corresponding class diagram, the Fujaba environment automatically generates the whole Java code of the desired application. To support this process beyond code generation, in [Mai02] we have developed a generator for the derivation of statecharts from sequence diagrams. Basically, our statechart synthesis algorithm follows the ideas of the SCED [KMST94] and the MAS system [KMS01]. This means, for a single life line within a sequence diagram, incoming messages are interpreted as events attached to certain transitions and outgoing messages are interpreted as doactions of certain states. Following the lifeline of a given object, the generator tries to reuse already existing transitions and states in the corresponding statechart as long as possible. New transitions and states are created, otherwise. Similar to [WKS02] and [WKS03], we made the experience that certain frequently occurring types of textual scenario description are not easily expressed within sequence diagrams. These are requirements like... at any point during the above steps the system may be suspended by signal x... or... after handling the request, the system continues work at the step where it has been interrupted... or... in parallel to these steps the following steps are executed.... Looking at these requirements more carefully, it turned out that they correspond to higher level statechart features like or-states, history states and and-states. These higher level features have proven to be extremely valuable for statecharts and we are convinced that they are indispensable for sequence diagrams, too. First of all, there is no other way to express above textual requirements within sequence diagrams. Second, it is not sufficient to skip these requirements in the scenarios and to express them in complex statecharts,

2 directly. While this is possible, many people like non-it customers have difficulties to understand statechart behavior while such non-it people usually come along with sequence diagrams much easier. Third, we consider sequence diagrams and statecharts as dual views on the system behavior: while statecharts focus on the complete behavior of a single object, sequence diagrams allow to focus on the collaboration of multiple objects in certain typical situations. To allow the specification of a system in both views, we need equal expressiveness in both kinds of diagrams. Thus we tried to adapt the proposal of [WKS02] and [WKS03] using some additional pseudo messages allowing to express above kinds of scenarios. Unfortunately, in [WKS02] and [WKS03] this idea is not very elaborated and thus we had to add some missing features for or-state and history state related scenarios and we are still seeking for more accurate ways to express and-state related scenarios. However, we now have a number of pseudo messages allowing to express above requirements in sequence diagrams easily and this additional pseudo messages allow to generate statecharts employing complex states and history states, easily, and we anticipate that the propagation of statechart changes to sequence diagrams is facilitated, too. The following chapter introduces our sequence diagram extensions with the help of some examples. Chapter 3 outlines the Fujaba statechart synthesis approach and in chapter 4 we discuss our results and outline some future work. 2. Notational extensions of sequence diagrams Figure 1 shows a fairly usual sequence diagram for an automatic, track based transportation system within a production site. This case study stems from the ISILEIT project funded by the German Research Society (DFG Schwerpunktprogramm). Some user assigns a continuous transportation task to a shuttle s1. The shuttle sends go (src) signals to its drive until the producer src is reached. Then the shuttle fetches some good and sends go (tgt) signals to its drive until the consumer tgt is reached. At the consumer, the shuttle delivers the transported good and continues its transportation task with go(src) signals. From the usual parts of the sequence diagram of Figure 1 the Fujaba statechart generator creates the core behavior of shuttle objects shown in the or-state active of Figure 3. The additional pseudo messages startphase and init allow to encapsulate states go(src), fetch, go(tgt) and deliver within the or-state active. startphase and endphase pseudo messages allow to group a sequence of steps within a sequence diagram (see also Figure 2). Our statechart generator turns such a grouping into an or-state containing a sub-statechart that matches the grouped steps. Figure 1. "Usual" sequence diagram for an automatic track based transportation system. init pseudo messages model, that the corresponding orstates are entered via their initial state. Our statechart generator utilizes this information by connecting the transition entering the or-state to the outer border of the or-state and by marking the first state visited within the or-state as initial state. Figure 2 shows an example for an interrupt situation modelled by a sequence diagram using our notational extension. The startphase message models that the shuttle is in phase active. severalothersteps pseudo messages are a placeholder for a sequence of steps that is intentionally left unspecified. This placeholder may be used to model that the corresponding object reaches any sub-state of the orstate corresponding to the current phase. Thus, in Figure 2 the shuttle is at some unspecified step within phase active when it receives an emergencystop signal. The shuttle reacts with an endphase( active ) message

3 a specific sub-state (no pseudo message) or from its border (severalothersteps). Note, nested startphase / endphase messages allow to model nested or-states. 3. Algorithm outline Figure 2. Modelling interrupt handling with sequence diagrams. modelling that the corresponding phase is interrupted and a halted message modelling the actual reaction of the shuttle, i.e. that it has stopped. In Figure 3 this creates an emergencystop transition leaving the border of or-state active towards state halted. This means, severalothersteps messages may be used to model requirements like At any time during this phase,.... After the halted message, the user in Figure 2 sends a resume message to reactivate the shuttle. In this example we want to model that the execution is continued at the point, where the emergencystop signal has interrupted it. This is achieved using a resumehistory pseudo message. resumehistory pseudo messages model the entering of a phase / an or-state via the history mechanism of statecharts. In Figure 2 the shuttle reacts to the resume message by a startphase( active ) message modelling, that the sample execution returns to this phase. This is followed by a resumehistory message modelling that the phase active is not started as usually (with an init message) nor the phase active is entered at an explicitly modelled step but the next step within the scenario is the one that continues the operation sequence that has been interrupted by the emergencystop signal. The Fujaba statechart generator turns this part of the example scenario into a resume transition from state halted to a history state within or-state active. Thus, we have specific pseudo messages setting up the borders of or-states (startphase and endphase) and specific pseudo messages for entering an or-state via the initial state (init) or at an explicit state (any usual message send by the corresponding object) or via a history state (resumehistory). Similarly, an or-state may be left from As already mentioned, our statechart synthesis algorithm follows the ideas of the SCED [KMST94] and the MAS system [KMS01]. This means, for a single life line within a sequence diagram, incoming messages are interpreted as events attached to certain transitions and outgoing messages are interpreted as do-actions of certain states. Following the lifeline of a given object, the generator tries to reuse already existing transitions and states in the corresponding statechart as long as possible. New transitions and states are created, otherwise. Here the crucial design decision is, how existing states and transitions are identified for reuse. The approach of [WKS02] and [WKS03] requires that the user provides elaborated pre- and post-conditions for all messages employed in the sequence diagrams. These pre- and post-conditions are used to identify appropriate source and target states for transitions. We consider this as an unacceptable burden for the user and thus we have decided to reuse states based on similar names of the performed do-action, as done in the SCED and the MAS system. This relieves the user from a lot of tedious work but increases the complexity of the statechart synthesis algorithm. Developing our statechart synthesis algorithm we focused on extendability and maintainability instead of runtime efficiency. Thus, our algorithm just starts at the beginning of the lifeline of the considered object and it looks up all statechart elements that matches the first message attached to this lifeline. We call such elements possible start elements. For an incoming message this is a transition with the same name for an outgoing message this is a state with the same do-action. Assume for example that in the statechart of Figure 3 the or-state active has not yet any substate. If we now integrate the lifeline of the shuttle from the sequence diagram of Figure 1 the outgoing shuttleisready() message matches to the initial state of our statechart, only, thus there is only one possible starting point. For each such possible start element, we compute the number of subsequent messages that match to subsequent statechart elements without the need to create new elements. We call this the matching length and the visited statechart elements the corresponding match. We consider the possible start elements in descending order according to their matching length. Thus, we reuse the statechart element that promises to integrate a large number of subsequent steps easily, first. However, we keep the alternatives for backtracking purposes. Then we assign statechart elements matching lifeline messages up to the corresponding matching length. In our example we have chosen the initial state

4 Figure 3. Statechart generated from Figure 1. of our statechart as the only possible starting point. The subsequent assign and startphase messages from the sequence diagram match to the assign transition leaving the initial state and to the or-state, respectively. Since we assume that the or-state is empty, the init message and the go(src) message do not yet have matches in the statechart. Thus, the matching length of our starting point is 3 and the corresponding match consists of the initial state, the assign transition and the or-state. If not yet all lifeline elements are consumed, we have now reached some place within the statechart where we need to create new statechart elements to be able to continue. Usually, there is an incoming message at the lifeline that has no appropriate outgoing transition at the reached state. In this case we just create a new transition leaving the current state but without a target state, yet. However, in subsequent runs, such a targetless transition may be the end of a match and we may continue by creating a state. In our example, the init and the go(src) message of Figure 1 would create state 36 of Figure 3 and an initial state marker attached to it. After creating a new statechart element, the matched lifeline elements are considered consumed and the algorithm continues recursively with the remaining lifeline elements and with the additional information of the current statechart element. Thus, our example would continue with the incoming notreached message. This message has no possible match in the current statechart and thus we would create a notreached transition leaving the go(src) state 36 and without a target state, yet. The subsequent go(src) message in the lifeline now has exactly one possible match which is the just created go(src) state 36. Matching length is only one, but we use this information to assign state 36 as target state for the just created notreached message. The following reached, fetch, goon, go(tgt) and the notreached message all create new statechart elements. The second go(tgt) message reuses state 41. The next messages again create new statechart elements, only the last go(src) message reuses state 36 as target for the previous goon transition. Note, the reuse of states in our example creates loops within the statechart that may be iterated arbitrary often. Thus the statechart allows behavior beyond the provided example scenarios. To some extent this is desired: a small number of characteristic scenarios suffices to create a much more general behavior specification. On the other hand, such iterations may be considered as erroneous by the user. This problem is known as overgeneralization problem. To deal with this problem, we plan to adopt implied scenario techniques creating additional possible scenarios and asking the user for approval, cf. [UKM01]. Note, the chosen statechart start element for a given part of a lifeline and the matching of the subsequent steps may also end in a conflict situation. The matching may end at a transition that already has a target state and the do-action of this target state does not match the next message in the considered lifeline. Thus, the corresponding object receives a messages and it reacts differently compared to the last reception of the same message. In this case, the reuse of the transition was not allowed. This implies that the reuse of the previous statechart element and finaly of the whole match up to the starting point was illegal. At this point backtracking occurs. Recall, at the start of the algorithm we compute the set of all possible start elements for a matching and then we choose the one that is most promising. If this creates a conflict, we just reconsider this choice and try another starting element. Note, we may finally run out of possible starting elements. In this case, we create a new statechart element for the first element of the lifeline and restart the algorithm with the next lifeline element. This especially happens when the statechart is totally empty and we are considering the very first lifeline to be integrated. After integrating a lifeline, our algorithm may have created some transitions without a target or without a source state. Thus we will have to add surrogate states in order to be able to show a complete statechart at the user in-

5 terface. These surrogate states are to be removed before another lifeline is added to the corresponding statechart. Note, there are a number of additional cases to be handled with care. For example, there may be multiple incoming or outgoing messages in a row. For multiple incoming messages you have to decide, whether the order of reception is mandatory or if they may be received in any order. [WKS02] and [WKS03] propose another pseudo message any order to flag the latter case. We have not yet adopted this message since its scope is not clear and we do not like the and-states created by this pseudo message, cf. [WKS02] and [WKS03]. We have an idea to handle this case more elegantly using vectors of flag collecting the received messages until all of them have arrived, but this is not yet done. Thus, currently our approach would create a sequence of transitions where the connecting states have no do-action. In case of multiple outgoing messages, we create a set of matching states connected by triggerless transitions. Altogether, it was very easy for us to implement the outlined algorithm and especially it was very easy to deal with the additional pseudo messages. Basically, when we reach a startphase message, we look for or we create the corresponding or-state. Subsequent messages are restricted to statechart elements within this or-state until an endphase message is reached. init messages just create init markers attached to the next reached state. severalothersteps messages just change the source state of a subsequent transition / incoming message and resumehistory messages just change the init marker of the corresponding or-state to become a history marker and the subsequent incoming message / transition is redirected to this history marker. Note, our algorithm allows a * argument to resumehistory to distinguish between shallow and deep history. Note, our pseudo messages may cause a number of additional matching conflicts. For example, a startphase, init message combination may be followed by different outgoing messages in different scenarios. This would force our algorithm to create different init marker for different substates of a given or-state, which is illegal. In such a situation our algorithm flags an inconsistency between different scenarios that need to be resolved by the user. Another problem is triggered if one scenario lacks startphase / end- Phase messages while another scenario with similar steps has startphase / endphase messages. This creates a conflict whether the states and transitions visited by the latter scenario are contained in an or-state or not. So far this conflict is flagged by our algorithm but we plan to resolve this conflict automatically by adding appropriate startphase / end- Phase messages to the former scenario, automatically. The same mechanism could be used if the user adds or-states to the resulting statechart manually and we want to propagate such changes into the corresponding scenarios. 4. Summary and Future Work So far, our statechart synthesis algorithm is able to deal with or-state and history state related pseudo messages. And-state related pseudo messages are current work. However, we claim that our pseudo messages for or-states are more elaborated than the ones of [WKS02] and [WKS03]. In contrast to [WS00], our synthesis algorithm does not rely on extensive specifications of all messages with explicit pre- and post-conditions. The SCED [KMST94] and the MAS system [KMS01] provide additional post compression mechanisms that try to compactify the generated statechart e.g. by combining the do-actions of a series of states that are connected by triggerless transitions into a single state with multiple do-actions. We are trying to adopt these mechanisms, too. Currently, we use TogetherJ as an editor for sequence diagrams and its XML export feature as input for our statechart synthesis algorithm. However, a sequence diagram editor has just been added to Fujaba and we are currently switching to this integrated sequence diagram editor. This also will enable us to do propagations of manual editing of the statecharts to appropriate changes of the affected sequence diagrams. Similarly, sequence diagrams may be changed after statechart synthesis and the consistency between sequence diagrams and statecharts should be maintained. References [Fu03] [KMS01] [KMST94] [Mai02] [UKM01] J. Koskinen, E. Mäkinen, T. Systä: Minimally Adequate Synthesizer Tolerates Inaccurate Information during Behavioral Modeing, SCASE 2001, Enschede, Netherlands K. Koskimies, T. Männistö, T. Systä,J. Tuomi: SCED - An environment for dynamic modeling in object-oriented software construction, Nordic Workshop on Progr. Environment Research 94 T. Maier: Generation of complex statecharts from sequence diagrams, Master Thesis, Uni. Braunschweig, 2002 (in German) S. Uchitel, J. Kramer and J. Magee: Detecting Implied Scenarios in Message Sequence Chart Specifications, ESEC/FSE 01, Vienna, Austria [WKS02] Whittle J., Schumann J.: Statechart Synthesis From Scenarios: an Air Traffic Control Case Study, ICSE 2002, SCESM Workshop, Orlando, Florida [WKS03] [WS00] Jon Whittle, Richard Kwan, Jyoti Saboo: From Scenarios to Code: An Air Traffic Control Case Study, ICSE2003, Portland, USA J. Whittle, J. Schumann: Generating Statechart Designs From Scenarios, ICSE 2000, Limerick, Ireland

Statechart Modeling with Fujaba

GraBaTs 04 Preliminary Version Statechart Modeling with Fujaba Leif Geiger Albert Zündorf University of Kassel, Software Engineering Research Group, Wilhelmshöher Allee 73, 34121 Kassel, Germany {leif.geiger