From state diagrams to sequence diagrams: a

International Journal of Computers and Applications

ISSN: 1206-212X (Print) 1925-7074 (Online) Journal homepage: http://www.tandfonline.com/loi/tjca20

From state diagrams to sequence diagrams: a requirements acquisition approach Bingyang Wei, Harry S. Delugach & Yi Wang To cite this article: Bingyang Wei, Harry S. Delugach & Yi Wang (2017): From state diagrams to sequence diagrams: a requirements acquisition approach, International Journal of Computers and Applications, DOI: 10.1080/1206212X.2017.1408982 To link to this article: https://doi.org/10.1080/1206212X.2017.1408982

Published online: 12 Dec 2017.

Submit your article to this journal

Article views: 11

View related articles

View Crossmark data

Full Terms & Conditions of access and use can be found at http://www.tandfonline.com/action/journalInformation?journalCode=tjca20 Download by: [State University NY Binghamton]

Date: 12 January 2018, At: 10:54

INTERNATIONAL JOURNAL OF COMPUTERS AND APPLICATIONS, 2017 https://doi.org/10.1080/1206212X.2017.1408982

From state diagrams to sequence diagrams: a requirements acquisition approach Bingyang Weia , Harry S. Delugachb and Yi Wangc a Computer Science Department, Midwestern State University, Wichita Falls, TX, USA; b Computer Science Department, University of Alabama in Huntsville, Huntsville, AL, USA; c Department of Electrical and Computer Engineering, Manhattan College, Riverdale, USA

Downloaded by [State University NY Binghamton] at 10:54 12 January 2018

ABSTRACT

Multiple-viewed requirements modeling allows modelers to focus on different aspects of a system’s requirements and express them in appropriate modeling notations. As a result, the requirements are scattered in a set of different models. The semantic overlap among them makes model transformation possible, and such a transformation can be used for acquiring requirements knowledge. In this paper, we demonstrate the process of deriving a set of sequence diagrams with requirements knowledge acquisition opportunities from a state diagram. This set can be used as a requirements elicitation medium for sequence diagram modelers. The transformation is based on the rich semantic relationship between the two diagrams and proved graph theory algorithms for finding sequences. The set of derived sequence diagrams is consistent with the state model and achieves minimum state transition path coverage in the state diagram. Such a set of sequence diagrams with knowledge acquisition opportunities can be used as a modest spur to induce human modelers to provide valuable requirements knowledge.

1. Introduction Developing complex systems always has to deal with varied requirements. Properly modeling those requirements is crucial. Multiple-viewed modeling approaches have the advantage of separating concerns, thus each model is responsible for describing one aspect of the system requirements, and all the models together constitute the overall description of the system [1,2]. The set of models of a system forms a requirements ‘ecosystem’ where models evolve concurrently (Figure 1) by acquiring more requirements. Those models are not unrelated; there exist requirements overlap among them [2]. This overlap makes model transformation possible. Delugach and Wei proposed an iterative approach [3–5] which leverages model transformations for generating new models and completing incomplete models in the context of a requirements ‘ecosystem.’ This approach is illustrated in Figure 2. The basic idea is to transform requirements of currently available models in the ‘ecosystem’ into a target model to be developed (A target model is one to be constructed or needs to acquire requirements, for example, Modelx in Figure 2). As a result, the requirements in the existent models are expressed in the notation of Modelx so that a new target model with semantic holes is generated and presented to the modelers of the target model. In this work, semantic holes are parts of the target model that cannot be directly generated based on CONTACT Bingyang Wei

[email protected]

© 2017 Informa UK Limited, trading as Taylor & Francis Group

ARTICLE HISTORY Received 20 January 2017 Accepted 21 November 2017 KEYWORDS

Sequence diagrams; state diagrams; model transformation; requirements acquisition

the requirements in other models. The newly generated target model with semantic holes provides insights of the system to the modelers and invites them to complete the model by filling in the holes with missing requirements or correcting inconsistent requirements acquired from other models. After this reconciliation process, this more complete target Modelx would affect other models (dotted lines in Figure 2), causing reconciliation processes in those models. The process will continue until no more new requirements can be acquired by transforming models. This approach shows a general idea of how model transformations can be used to drive the process of developing requirements models and acquiring requirements from human modelers. In this paper, we consider two different but related UML requirements models, state diagrams and sequence diagrams, and illustrate the process of transforming a state diagram to a set of sequence diagrams that contain semantic holes. The reverse transformation, i.e. transformation from sequence diagram to state diagram is an active thread of research, and there are several papers focused on such transformation [6–8]. As indicated by Figure 2, the work in this paper is part of a larger project which aims to automate the pairwise model transformations between several UML diagrams for the purpose of requirements acquisition [9]. The motivation that justifies the need for this transformation

2

B. WEI ET AL.


Figure 1. Ecosystem of multiple-viewed requirements modeling.

Figure 2. A framework for requirements acquisition through model transformations.

(from state diagram to sequence diagram) is as follows: Sequence diagrams can be used for both understanding requirements [10] and deriving test cases [11,12]. Developing sequences from scratch can be a tedious and time-consuming process. The goal of this work is that, given an existing state diagram of a software system, this transformation can help discover possible interacting objects, messages passing among them, and the temporal order of the messages. Such information is important for determining interaction patterns inside a software system. The resulting set of sequence diagrams with semantic holes can be exploited as a medium to further elicit missing requirements knowledge from human modelers. For example, a possible semantic hole generated for sequence diagram might be showing that a message is received by an object but the kind of the message or the sender of the message is not clear. Semantic holes in the set of generated sequence diagrams reveal such missing requirements, thus help human modelers find the information that is not currently captured in the models of the system explicitly. In this work, semantic holes are marked with K.A. Opportunities labels (Knowledge Acquisition Opportunities label is explained in Section 3.2). The difficulty in the transformation from state diagrams to sequence diagrams is rooted in the nature of the two diagrams. A sequence diagram describes a specific

instance of an interaction in which objects of the system collaborate to achieve a task, while a state diagram describes the entire behavior for an object in the system across many interactions. So the state diagram is a more general and complete diagram while a sequence diagram a more specific and partial one. Since we are transforming from a general model to a concrete model, one state diagram can result in multiple sequence diagrams. It is impossible and impractical to generate and present all of them to the modelers. For the purpose of knowledge acquisition, the set of generated sequence diagrams from a state diagram possesses the following five properties that can be verified: (1) Each sequence diagram in the set starts with the initial state (the object is created) and ends in a final state (the object is destroyed); (2) Every state transition in the state diagram is covered at least once in the set of generated sequence diagrams; (3) The number of sequence diagrams is minimum given that property 2 is satisfied; (4) Each sequence diagram in the set has only one lifeline which represents the object owning the state diagram; (5) There are knowledge acquisition opportunities so the modeler is given a chance to fill in the missing requirements. The above list summarizes the properties of the set of generated sequence diagrams in this work. Property 1 makes sure that each of the generated sequence diagrams conveys a complete scenario to the sequence diagram modeler. Property 2 and 3 guarantee that the modeler is presented with UML messages implied by all the state transitions in state diagram and meanwhile the set of sequence diagrams is minimum, so it will not overwhelm the modeler. Since one state diagram only captures the behavior of one object, property 4 says each sequence diagram only has one lifeline. Property 5 shows the modeler knowledge acquisition opportunities in the form of meaningful labels so that she can start filling in the semantic holes with missing requirements knowledge. Subject to some limitations (see Section 5), we claim our approach is a reasonable way to generate some initial sequence diagrams from a state diagram, and a good start for the modelers to design sequence diagrams that can be further developed. The remainder of this paper is structured as follows. Section 2 briefly introduces state diagrams and some concepts in graph theory needed in this work, selected elements of sequence diagrams are also introduced. Section 3 explains the detailed transformation from state diagram to sequence diagrams. Section 4 applies our

INTERNATIONAL JOURNAL OF COMPUTERS AND APPLICATIONS

method to an example to demonstrate the transformation process. Section 5 discusses the strength and limitations of this work. Section 6 concludes the paper.


2. State diagrams and sequence diagrams The Unified Modeling Language is the de-facto standard for modeling object-oriented software systems. Different aspects of the system are captured in various UML views, and each view may have one or more diagrams display it [13]. The two views we considered in this work are the state machine view displayed by state diagrams and the interaction view displayed by sequence diagrams. Both views capture the dynamic behavior aspect of the system but have different focuses. In the eyes of an Object-Oriented modeler, the system consists of a society of objects which collaborate to accomplish a purpose. A state diagram captures the dynamic behavior by specifying possible states an object can potentially go through during its lifetime and how it reacts to events, while a sequence diagram by modeling the sequence of message exchanges among objects in a collaboration and providing a more holistic view of the behavior of a set of objects [14]. In this section, we briefly introduce the two diagrams and some graph theory concepts needed in this work. Section 2.1 mainly discusses state diagram’s graphical properties from the aspect of graph theory. Section 2.2 introduces sequence diagrams and some of its elements. For a detailed explanations of elements in the two diagrams, see [13]. 2.1. State diagrams A state diagram consists of states connected by transitions. The occurrence of an event might fire a transition that causes the object to exit the current state and enter a new state. When a transition fires, an effect attached to the transition is performed. State diagram is aimed at capturing all admissible sequences of state transitions. The rest of Section 2.1 introduces the concepts in graph theory that we will be using in Section 3. 2.1.1. State graph Each state diagram has a corresponding state graph which represents its structure. A state graph is a pair of sets (V, E), where V is the set of vertices representing states in state diagram and E is the set of edges representing transitions in state diagram. Figure 3 shows a state diagram and its state graph. In the state graph, labels on vertices and edges correspond to state names and the transition names in state diagram, respectively. So edge tr1 between vertex State A and vertex

3

State B represents the transition between State A and State B in the state diagram. In this work, we are using the state graph as an intermediate representation to derive knowledge about sequence of messages which is crucial for generating sequence diagrams. However, because we take the state diagram that has rich meaning and turn it into a state graph with no inherent meaning, from now on, we will frequently refer back to the concepts in the original state diagram so that we do not lose the meaning of the state diagram as we process the state graph. The state graph generated from the state diagram possesses several important properties: the graph is directed since transitions have directions; the graph may be cyclic since a state might be revisited during the execution of a state diagram; the graph starts with a source vertex s and ends in a sink vertex t, since there are two special kinds of states in a state diagram: initial state and final state (there can be more than one final state in state diagram, but all final states can be combined in the state graph); vertex s can reach every other vertex in the graph. With all the properties of a state graph being clearly stated, we then introduce three graph theory concepts which will be used later on. They are path, path cover, and flow network. A path from one vertex to another in a graph is an alternating sequence of vertices and edges. In a state graph, a path corresponds to a state transition path in its originating state diagram. A state transition path is an alternating sequence of states and transitions which depicts the consequence of receiving a specific sequence of events by an object during the execution of the system. One state graph can lead to many paths which represent all the possible behaviors of an object during the execution of a system. In this work, we use s-t path in a state graph to mean any path from the source vertex s to the sink vertex t in the state graph. Such a path describes a particular initial-to-final state transition path which starts from an initial state and ends in a final state in the state diagram. For example, in Figure 3, an s-t path: Initial, tr0, State A, tr1, State B, tr2, Final in the state graph on the right depicts one possible initialto-final state transition path an object goes through during its lifetime. If we omit the vertices, the s-t path results in a sequence of edges: (tr0, tr1, tr2) which corresponds to a sequence of event occurrences in the originating state diagram: (evt0, evt1, evt2). A path cover for the edges in a graph is defined as a set of s-t paths such that each edge in the graph appears in at least one s-t path in the set. There are multiple path covers for one state graph. A path cover P is a minimum path cover if and only if there is no path cover such that its cardinality is less than that of P [15].

4

B. WEI ET AL.


Figure 3. A state diagram and its state graph.

Figure 4. A state graph expressed as a flow network.

A flow network G = (V, E) is a single-source and single-sink directed acyclic graph. Flow generated by the vertex s reaches vertex t by traveling through all the other vertices and edges connecting them in the graph. Think of a flow network as a traffic network where each edge is carrying a certain number of flow units. In a flow network, each edge (u, v) ∈ E is associated with a lower flow requirement and a current flow (see Figure 4), the current flow that an edge carries must be no less than the lower flow requirement at any time. Another important property about a flow network is that the amount of flow entering a vertex through incoming edges must be equal to that of leaving through the outgoing edges. For example, in Figure 4, two units of flow enters vertex State A in the flow network, then the summation of flow on each outgoing edges is also two units. 2.1.2. State graph expressed as a flow network In this work, a state graph is further expressed as a flow network (Figure 4). The flow in the state graph is defined in terms of s-t paths of a path cover. A single s-t path can be considered as a unit of flow flowing from the source vertex to the sink vertex through the s-t path. So one s-t path in the path cover would add one flow unit on each of the edges in the s-t path. For example, the s-t path Initial, tr0, State A, tr1, State B, tr2, Final adds one unit of flow to the current flow (second number in parentheses in Figure 4) of edge tr0, tr1 and tr2. When all the s-t paths in a path cover are considered this way, the current flow on each edge of the state graph denotes the number of times that edge appears in all s-t paths of a path cover. Recall that the lower flow requirement (first number in parentheses in Figure 4) means that the edge must be used at least a

certain number of times (in our case, it is 1). Since every edge must be covered at least once according to property 2 of our generated sequence diagrams, each lower flow requirement is set to one. For example, in Figure 4, tr0: (1, 2) on the edge connecting vertex Initial and vertex State A means that the edge tr0 must appear at least once in the set of s-t paths and in fact it appears twice. So in brief, we convert a state diagram to a state graph, and then express it as a flow network by labeling lower flow requirement and current flows for each edge in the state graph based on all s-t paths of a path cover. Those flows are deterministically derivable from the state diagram. In Section 3, we will minimize the number of times each edge appears in the path cover but still guarantee that each edge is used at least once so that we get a minimum path cover to fulfill the property 3 of our generated sequence diagrams. 2.2. Sequence diagrams A sequence diagram arranges a set of messages passed between objects in temporal order. Objects are shown as vertical lifelines and messages are shown as horizontal arrows between lifelines [13]. Figure 5 shows a sequence diagram example which illustrates the process of handling dropping seminar requests in a university information system [16]. The sequence diagram in Figure 5 has three lifelines with types: EnrollInSeminar, Seminar and Database, and one signal message: student dropped requests. A state Full shown as a small state symbol is placed on the lifeline of the seminar: Seminar. The state must be true at the time of the next event on the lifeline. The diagram also consists of one interaction use: get student status and two combined fragments: loop and alt. An interaction use is a reference to a sequence diagram within the body of another sequence diagram. It is shown as a rectangle with the tag ref. The rectangle covers the lifelines that are included in the referenced sequence diagram. As with any modular reference, such as procedures, this allows the reuse of a definition in several different contexts. The combined fragment loop and alt are used to show looping and conditional behaviors, respectively,


sd Handle dropping seminar requests : EnrollInSeminar «Controller»

seminar: Seminar

: Database

Full student dropped requests

5

Table 1. Key pieces of knowledge in sequence diagram and counterparts in state diagram. Elements in sequence diagram

Corresponding elements in state diagram

Messages Sequence of messages

Events State transition path

loop [get next drop request] ref get student status

alt [InWaitingList] deleteFromWaitingList()


[InSeminarList] deleteFromSeminarList()

enrollFromWaitingList()

Figure 5. Sequence diagram example.

for example, in the alt fragment in Figure 5, the top compartment of the fragment is executed if the condition InWaitingList is true.

3. Transformation from state diagram to sequence diagrams This section elaborates the process of transforming a state diagram to a set of sequence diagrams with semantic holes for knowledge acquisition purpose. Section 3.1 describes the steps for selecting qualified sequences from a state diagram. Once the set of sequences is formed, detailed mapping between elements of the two diagrams are needed to complete the generation of sequence diagrams. This is covered in Section 3.2. Possible semantic holes that are annotated in the generated sequence diagrams are also introduced in this section. Section 3.3 goes through each of the steps mentioned in Sections refsec3.1 and 3.2 using an artificial example. 3.1. Transformation strategies and steps A sequence diagram describes a specific interaction in terms of a sequence of messages exchanged among objects. So the generation of a sequence diagram requires two key pieces of requirements knowledge: messages and a time sequence of those messages. Both pieces of requirements knowledge can find their counterparts in a state diagram: events and state transition path. The relationship is shown in Table 1.

Events in a state diagram imply reception of messages, for example, a call event in the state diagram of an object implies the reception of a call message by the object in the sequence diagram. Messages can be generated in this way. Since a state transition path in a state diagram depicts the consequence of receiving a specific sequence of events by an object, it is a good candidate for generating a sequence of messages for a sequence diagram. However, a state diagram usually implies a large number of distinct state transition paths, it is not feasible to use all of them for generating sequence diagrams for the purpose of knowledge acquisition. So our strategy of generating sequence diagrams is as follows: first, we are only interested in transforming initial-to-final state transition paths i.e. state transition paths that will take an object from initial state to final state. As a result, each of the generated sequence diagrams conveys a complete scenario from the initialization of an object to the destruction of that object; second, in order to reduce the number of generated sequence diagrams, we will be satisfied to find a minimum set of initial-to-final state transition paths that is sufficient to cover all the state transitions, so the modeler is presented with messages implied by all the events on state transitions in the state diagram. The minimum set of initial-to-final state transition paths is then transformed into a set of sequence diagrams which processes the five properties stated in the Introduction section. The eight steps of generating a set of sequence diagrams from a state diagram are listed and briefly explained here. • Step 1: Collapse composite states in state diagram; • Step 2: Generate state graph from a state diagram; • Step 3: Collapse strongly connected components (SCCs) in the state graph; • Step 4: Find a minimum path cover for edges in the reduced state graph; • Step 5: Form subsequences using SCCs; • Step 6: Form subsequences using each vertex (state); • Step 7: Form subsequences using buckles on vertices; • Step 8: Annotate guards on transitions in sequence diagrams. After steps 1 and 2, a state diagram is converted into a state graph. We then get rid of cycles in the state graph

6

B. WEI ET AL.

Table 2. Mapping rules between state diagram and sequence diagram. Elements in state diagram


The current state machine Message events Effect on transition Entry action, Exit action, Do activity States Guard on transition Guard on self-transition

Corresponding elements in sequence diagram One object at the top of a lifeline (K.A. Opportunity) Signal message or call message (K.A. Opportunity) The specification of the execution of an activity, operation, or behavior The specification of the execution of an activity, operation, or behavior Annotated state information between message passing along the lifeline and a ref box K.A. Opportunity Combined fragment loop

by collapsing each of the strongly connected components into one vertex and removing buckles (an edge that connects a vertex to itself) in step 3. The output of step 3 is a directed acyclic state graph with a single-source vertex and a single-sink vertex. As mentioned earlier in this section, we will find and transform a minimum set of initial-to-final state transition paths into sequence diagrams. Such a set is identified by finding a minimum path cover for edges in the state diagram’s state graph. In step 4, three graph algorithms are applied to the state graph in order to generate a minimum path cover for all edges. In brief, the minimum path cover problem is solved by solving a particular minimum flow problem [15]. The resulting minimum path cover helps us identify a set of initial-to-final state transition paths that cover all the state transitions in the state diagram. The set of state transition paths is then transformed into sequence diagrams based on the semantic mapping between state and sequence diagrams (explained in Section 3.2). This step fulfills the property 3 mentioned in the Introduction section. Steps 5–7 generate subsequences in order to complete the set of generated sequence diagrams in step 4. The strongly connected components and buckles that are ignored in step 3 are used to form subsequences in steps 5 and 7, respectively. Step 6 forms a sequence for each state with entry, exit and do activities. By going through steps 1–7, our approach deterministically transforms a state diagram to a set of sequence diagrams. In step 8, we consider the feasibility of the set of generated sequence diagrams by annotating guard information in the sequence diagrams.

3.2. Semantic overlap between the two diagrams State diagrams and sequence diagrams share a rich semantic overlap [17]. In this subsection, we map the elements in state diagrams to elements in sequence diagrams based on their semantic relationships (Table 2) so that the set of initial-to-final state transition paths can be translated to a set of sequence diagrams.

Figure 6. K.A. Opportunities in the generated sequence diagrams.

A sequence diagram is concerned with the message passing among several objects in an interaction. A state diagram describes how one object reacts to events detected in the rest of the world during its lifetime, so only one lifeline representing an instance of the class that owns the state machine is generated in a sequence diagram. There is a K.A. Opportunity (Knowledge Acquisition Opportunity), shown as a UML note (shown as (1) in Figure 6), in the generated sequence diagram so that the modeler is given a chance to consider and provide possible interacting objects in the same sequence diagram. These are considered as semantic holes. Events that trigger transitions in a state diagram are caused by either receipt of messages by the object owning the state machine or the satisfaction of a certain Boolean condition. To be more specific, events can be categorized in four kinds: signal event (receipt of a signal message), call event (receipt of a call message), change event (satisfaction of a Boolean condition), and time event (satisfaction of a time expression). Signal and call events are also named message events implying the reception of a signal or call message. However, there are no visual cues in the state diagram to distinguish a signal event from a call event [10]. There is a K.A. Opportunity (shown as (2) in Figure 6) attached to the generated message indicating there exists a semantic hole to be filled. The sequence diagram modeler needs to consider and specify the nature of the message and the sender of the message. Effects, entry, exit activities, and do activities are actually the response of the event detected, and all of them are treated as an execution specification in sequence diagram


7


Figure 7. A state diagram StateMachineDemo.

Figure 8. State graph expressed as a flow network with 1-lower limit on each edge.

Table 3. Minimum path cover for edges of the state graph. Path ID 1 3 6 4 7

s-t paths Initial, tr0, StateX, tr1, StateA, tr3, StateB&C&D&E, tr8, StateF, tr9, Final Initial, tr0, StateX, tr10, StateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr12, StateA, tr3, StateB&C&D&E, tr11, stateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr13, Final Initial, tr0, StateX, tr14, StateI, tr17, StateJ, tr18, Final

along the lifeline (shown as double line replacing part of the lifeline in a sequence diagram). The states in the state diagram are used as annotated state information between messages along the lifeline. The resulting sequence diagram thus also provides state information to sequence diagram modelers. The guard on a state transition results in a K.A. Opportunity (shown as (4) in Figure 6) attached to the sequence diagram. In this work, a sequence diagram is generated from a particular initial-to-final state transition path in state diagram. But whether such a state transition path is possible depends on the guards along the path: since a transition triggered by an event cannot fire when the guard is false. However, there is no way to know the truth

value of a guard on a transition when the execution flow encounters the transition, the modeler needs to provide necessary additional information to guarantee that the guard becomes true. This is also considered as a semantic hole in our K.A. framework. Up until now, we have explained the semantic mappings between key elements of the two diagram, and possible semantic holes. The rest of Section 3 illustrates our detailed approach of generating a set of sequence diagrams from a state diagram. We elaborate the transformation steps using an example state diagram StateMachineDemo which is shown in Figure 7. The state diagram example StateMachineDemo is deliberately built so that it contains most of the elements


8

B. WEI ET AL.

Figure 9. Part of generated sequence diagrams.

in a state diagram. It consists of one initial state, one final state, one composite state, and 10 simple states. The composite state State F has its own initial, final state together with two simple substates. Events and guards on the transitions between states are also labeled. After following eight steps in the previous section, a set of sequence diagrams which covers all the state transitions in the state diagram is generated so that modelers can start filling in semantic holes or otherwise modify it. 3.3. Transforming state diagram to sequence diagrams The eight steps of transforming state diagrams to sequence diagrams are detailed in the appendix. In this section, we only show some important intermediate results. During the transformation, we first reduced the

complexity of the state diagram by converting it to a reduced state graph (Figure 8). We then reduced the problem of finding a set of sequence diagrams to a graph theory problem: finding minimum path cover. Once that is done (Table 3), we followed the steps in graph algorithms without needing any knowledge of the content of the state diagram. When handling SCCs, loops, and states, we considered the semantics of them and complete our set of sequence diagrams. In step 8, we wrapped up the transformation process by considering the feasibility of the generated sequence diagrams, and making the resulting set feasible to increase the change of acquiring knowledge. A part of sequence diagrams generated from StateMachineDemo is shown in Figure 9. Note not all sequence diagrams are included in this figure due to space.


9

Table 4. Minimum path cover for Seminar state graph. Path number

s-t paths

1 2 3 4

Initial, tr0, Proposed, tr1, Scheduled, tr2, OpenForEnrollmet&Full, tr10&tr9, ClosedToEnrollment, tr12, Final Initial, tr0, Proposed, tr1, Scheduled, tr2, OpenForEnrollment&Full, tr11, Final Initial, tr0, Proposed, tr1, Scheduled, tr3, Final Initial, tr0, Proposed, tr13, Final

Table 5. Textual explanation of the one generated sequence diagram. Message number 1 2


3 4 5 6 7

8 9

Explanation Seminar object receives a scheduled message (K.A. Opportunity: type and sender need to be provided); The scheduled message might cause certain activities (K.A. Opportunity: missing execution spec) Seminar object receives an open message (K.A. Opportunity: type and sender need to be provided); Execution flow goes to sequence diagram sd OpenForEnrollment & Full 1; Seminar object performs logSize() when flow enters sequence diagram sd OpenForEnrollment Seminar object keeps receiving student enrolled messages (K.A. Opportunity: type and sender need to be provided) while guard seat remaining is greater than zero; Seminar object responds by keeping performing addStudent() in sequence diagram sd OpenForEnrollment & Full 1 and logSize() in sequence diagram sd OpenForEnrollment When the guard of the loop is no longer true (K.A. Opportunity: the modeler needs to guarantee that), Seminar object receives a student enrolled message (K.A. Opportunity: type and sender need to be provided); Seminar object performs addToWaitingList() and waitingList++ When the execution enters sequence diagram sd Full, Seminar object receives a student enrolled message (K.A. Opportunity, the modeler needs to guarantee that) and performs addToWaitingList() Seminar object keeps receiving student dropped messages (K.A. Opportunity: type and sender need to be provided); Seminar object responds by either performing enrolFromWaitingList() and entering sd Full or only entering sd Full based on conditions of combined fragment alt;Every time object execute sd Full, we assume it receives a student enrolled message When the guard of the loop is no longer true (K.A. Opportunity: the modeler needs to guarantee that), Seminar object receives a student dropped message (K.A. Opportunity: type and sender need to be provided); Seminar object performs logSize() and enters sequence diagram sd OpenForEnrollment; The execution of sd OpenForEnrollment & Full 1 is over at this point, flow goes back to sd SeminarSeq1 Seminar object receives a closed message (K.A. Opportunity: type and sender need to be provided); Execution flow enters sequence diagram sd CosedToEnrollment;Seminar object performs notifyInstructor() Seminar object receives a canceled message (K.A. Opportunity: type and sender need to be provided); Seminar object is destroyed

4. A case study

5.1. Knowledge acquisition capability

In this section, we use a concrete state diagram example in a university information system [16] to demonstrate our approach. Figure 10 presents an example state diagram. Instances of a Seminar class can be in the Proposed, Scheduled, OpenForEnrollment, Full, and ClosedToEnrollment states. The state diagram is converted to a state graph (left side of Figure 11), and strongly connected component is collapsed into one vertex OpenForEnrollment&Full (right side of Figure 11). Algorithms in step 4 of Section 3 are then applied to the reduced state graph, and a minimum path cover (Table 4) is identified. In order to save space, we show here the resulting sequence diagram deduced based on the first s-t path path 1 and omit step 5 to 8. The complete sequence diagram transformed from path 1 is shown in Figure 12. Table 5 gives the textual explanation of the generated sequence diagram.

This work is primarily oriented around the task of using generated sequence diagram as a means of knowledge acquisition, so discovering semantic holes and producing clear knowledge acquisition opportunities are key parts of our approach. The generated sequence diagram in Figure 12 is annotated with many K.A. Opportunities, which invite human modelers to complete the sequence, thus acquiring additional knowledge; for example, any time a message is received by the Seminar, it must come from some other objects’ lifelines; however, since there is no deterministic way to acquire such information from the Seminar state diagram, the modelers need to make that determination, thereby filling in the semantic holes as we want them to do. In this work, we demonstrate that it is possible for the holes to be identified automatically and thereby guide the human modelers toward filling in the holes.

5. Discussion

5.2. Limitations of the set of generated sequence diagrams

In this section, we discuss the strength, limitation of this work, and related work.

Based on Ntafos and Hakimi’s conclusion [15], we can determine the minimum number of sequence diagrams


10

B. WEI ET AL.

Figure 10. State diagram of class Seminar.

Figure 11. State graph and reduced state graph of Seminar state diagram.

generated for a given state diagram in order to achieve state transition coverage. However, it did not specify the sequences in that set. As a matter of fact, there may exist many different sets of sequence diagrams that would constitute minimum sets for a particular state diagram. Some of the sets might be more valuable with respect to knowledge acquisition or give us better metrics than others. But we did not compare those sets in this work, our approach only guarantees that we can deterministically generate a set of sequence diagrams that meets the properties mentioned in the Introduction. Another issue about the generated sequence diagram is that, although they are ‘feasible,’ we have no guarantee that they are all ‘meaningful.’ ‘Meaningful’ here means that a sequence diagram describes what people really want the system to do and is determined by the modeler’s experience, domain knowledge, and other human-based knowledge [11], while ‘feasible’ means the sequence is possible or executable. In our work, all we can be certain is that we have a set of sequence diagrams that legitimately cover all states and transitions in the state diagram, and are feasible.

However, one reason that the sequence diagram might not be ‘meaningful’ is that knowledge about ‘meaningful’ or knowledge about ‘typical’ or ‘reasonable’ does not exist in the state diagram itself. Moreover, according to the purpose of this work, acquiring real requirements knowledge about real systems involves human modelers, so the issue of this approach actually means there are semantic holes to be filled in which is, for our purposes, a good thing. The fact that those sequences may not be obviously ‘meaningful’ provides the human modelers with a perfect opportunity to fill in the holes thus gather useful knowledge. 5.3. Relationship with test case generation approach This subsection discusses the relation between our set of sequence diagrams and the generating of a test case set from state diagram. Our set of generated sequence diagrams with K.A. Opportunities is used as a modest spur to induce human modelers to come forward with valuable requirements

11



Figure 12. sd SeminarSeq1 with semantic holes to be filled.

knowledge. A test suite, however, is used for the purpose of discovering errors and flaws in a state diagram. A theoretical way to test is get all the sequences of events

whatever it is and to test against the state diagram. However, generating all possible sequences of events is intractable, so several testing criteria are proposed to gen-


12

B. WEI ET AL.

erate test cases. Coverage criterion is used to find out whether a set of test cases is sufficient for testing a given software [18]. Several test criteria for the state diagram are listed here: (1) transition coverage; (2) full predicate coverage; (3) transition-pair coverage; and (4) transition path coverage [11]. Our approach of generating sequence diagrams is conceived in the spirit of transition path coverage in testing state machines, where a test set T is said to achieve transition path coverage if given a state graph G, T causes each possible transition path in G to be taken at least once [11]. However, in our work, we pick a minimum set of initial-to-final state transition paths. Such a set is not sufficient for testing purpose but would be good enough for the purpose of eliciting sequence diagram knowledge from modelers. The generated set of sequence diagrams may still be used to test the state diagram: if there are errors in the originating state diagram, they will be deterministically translated into the set of sequence diagram which is examined by the human modelers of sequence diagrams, after correcting those errors and filling semantic holes in the sequence diagram, and the set of sequence diagram is then translated back to state diagram (Figure 2); inconsistencies or errors are revealed in the newly generated state diagrams. It is not our purpose to test, or to identify mistakes in state diagrams, but our approach can do that in some cases.

6. Conclusion and future work We have developed an approach to transform a state diagram into a legitimate set of sequence diagrams with K.A. Opportunities. Our approach is based on the semantics of the two diagrams and proved graph theory algorithms. While there are many such legitimate sets, our approach is deterministic in finding a set that satisfies these properties: (1) Each sequence diagram in the set starts with the initial state (the object is created) and ends in a final state (the object is destroyed); (2) Every state transition in the state diagram is covered at least once in the set of generated sequence diagrams; (3) The number of sequence diagrams is minimum given that property 2 is satisfied; (4) Each sequence diagram in the set has only one lifeline which represents the object owning the state diagram; (5) There are knowledge acquisition opportunities so the modeler is given a chance to fill in the missing requirements.

This set of properties may not be necessary or useful in all cases. For our purposes, we wanted to develop a set of sequences that can be used to support knowledge acquisition and therefore are quite satisfied if they are not ‘complete’ or ‘perfect’ with respect to any arbitrary criteria. Indeed, it is the imperfections and incompleteness that lend our approach its strength with respect to acquiring more knowledge from software modelers. As for the future work, the current approach only considers transforming one state diagram for a single class, thus the resulting sequence diagram contains only a single lifeline. In future work, we would consider relating multiple state diagrams for different objects so that we can connect them up and form a sequence diagram with several objects. Another limitation of the current approach is that our algorithm only handles nested one level deep, that is, we did not consider the situation that there are composite states in a composite states. However, we are confident that, if we have a composite state within another composite state, we can apply the current approach recursively, so we treat the nested composite state the same way. In the current approach, we did not consider the concurrent composite state. Paper [19] provides us a way to handle composite states in state diagram. Concurrent composite states are flattened and the state diagram is transformed into Extended State Machine. In conclusion, this approach can not only provide knowledge acquisition opportunities for human modelers using state diagrams and sequence diagrams, but it can also serve as an illustration of how apparently ‘incomplete’ transformations can generally support knowledge acquisition for a wide range of software development modeling approaches.

Disclosure statement No potential conflict of interest was reported by the authors.

Notes on contributors Bingyang Wei is an assistant professor at Midwestern State University, and his research interests are Requirements Engineering, Knowledge Representation and Reasoning, and Natural Language Processing. Harry S. Delugach is an associate professor at the University of Alabama in Huntsville, and his research interests are Knowledge Acquisition, Conceptual Modeling and Team Mental Models. Yi Wang is an assistant professor at Manhattan College, and his main research interests include machine learning, image processing and cyber security.



References [1] Delugach HS. Specifying multiple-viewed software requirements with conceptual graphs. J Syst Softw. 1992;19(3):207–224. [2] Nuseibeh B, Kramer J, Finkelstein A. A framework for expressing the relationships between multiple views in requirements specification. IEEE Trans Softw Eng. 1994;20(10):760–773. [3] Delugach HS. An approach to conceptual feedback in multiple viewed software requirements modeling. In: Joint Proceedings of the Second International Software Architecture Workshop (ISAW-2) and International Workshop on Multiple Perspectives in Software Development Viewpoints’ 96) on SIGSOFT’96 Workshops. San Francisco (CA): ACM; 1996. p. 242–246. [4] Wei B, Delugach HS. A Framework for Requirements Knowledge Acquisition Using UML and Conceptual Graphs. In: Lee R, editor. Software engineering research, management and applications. Towson (MD): Springer; 2016. p. 49–63. [5] Wei B, Delugach HS. Transforming UML models to and from conceptual graphs to identify missing requirements. In: Sangi Y, editor. International Conference on Conceptual Structures. London: Springer; 2016. p. 72–79. [6] Grønmo R, Møller-Pedersen B. From UML 2 sequence diagrams to state machines by graph transformation. J Obj Technol. 2011;10(8):1–22. [7] Harel D, Kugler H. Synthesizing state-based object systems from LSC specifications. Int J Found Comput Sci. 2002;13(01):5–51. [8] Uchitel S, Brunet G, Chechik M. Synthesis of partial behavior models from properties and scenarios. IEEE Trans Softw Eng. 2009;35(3):384–406. [9] Wei B. A comparison of two frameworks for multipleviewed software requirements acquisition [Ph. D. thesis]. University of Alabama in Huntsville, Diss. 2015. [10] Rumbaugh J, Booch G, Jacobson I. The unified modeling language user guide. Upper Saddle River (NJ): AddisonWesley; 1999.

13

[11] Offutt J, Liu S, Abdurazik A, et al. Generating test data from state-based specifications. Reliab Verif Softw Test. 2003;13(1):25–53. [12] Sokenou D. Generating test sequences from UML sequence diagrams and state diagrams. GI Jahrestagung. 2006;2:236–240. [13] Rumbaugh J, Jacobson I, Booch G. The unified modeling language reference manual. Upper Saddle River (NJ): Addison-Wesley Professional; 1999. [14] Van Lamsweerde A. Requirements engineering: from system goals to UML models to software specifications. West Sussex, England; 2009. [15] Ntafos SC, Hakimi SL. On path cover problems in digraphs and applications to program testing. IEEE Trans Softw Eng. 1979;5:520–529. [16] Ambler SW. The object primer: agile model-driven development with UML. New York City (NY): Cambridge University Press; 2004. [17] Selonen P, Koskimies K, Sakkinen M. Transformations between UML diagrams. J Database Manage (JDM). 2003;14(3):37–55. [18] Samuel P, Mall R, Bothra AK. Automatic test case generation using unified modeling language (UML) state diagrams. IET Softw. 2008;2(2):79–93. [19] Kim YG, Hong HS, Bae D-H, et al. Test cases generation from UML state diagrams. IEE Proc Soft. 1999;146(4):187–192. [20] Even S. Algorithmic combinatorics. Vol. 549. New York (NY): Macmillan; 1973. [21] Brandizi M, Kurbatova N, Sarkans U, et al. graph2tab, a library to convert experimental workflow graphs into tabular formats. Bioinformatics. 2012;28(12):1665–1667. [22] Hierholzer C, Wiener C. Über die Möglichkeit, einen Linienzug ohne Wiederholung und ohne Unterbrechung zu umfahren. Math Ann. 1873;6(1):30–32. [23] Dijkstra EW. A note on two problems in connexion with graphs. Numer Math. 1959;1(1):269–271. [24] Robinson H. Graph theory techniques in modelbased testing. In: International Conference on Testing Computer Software. 1999. p. 999.

14

B. WEI ET AL.

Appendix 1. Step 1: Collapse composite states in state diagram


In this step, any composite state in the state diagram is treated as a single state, and the substates it contains are hidden. Figure A1 shows the resulting state diagram. Note that composite state State F is now shown as a simple state.

Figure A1. State diagram StateMachineDemo without considering substates in State F.

Step 2: Generate state graph from a state diagram Before we start to obtain a minimum set of state transitions for a state diagram, we need to convert the state diagram into a graph to which graph algorithms can be applied. The state graph of StateMachineDemo is shown in Figure A2. Note that self-transition tr2 in a state diagram is treated as a buckle in state graph. In graph theory, a buckle is an edge that connects a vertex to itself.

Figure A2. Corresponding State graph of StateMachineDemo.

Step 3: Collapse strongly connected components (SCCs) in the state graph In some cases, in a state diagram, there exists a set of states in which for any pair of states X and Y, there exists at least one state transition path from state X to state Y and vice versa. Such a set of states in a state diagram forms a strongly connected component (SCC) in its corresponding state graph. In graph theory, a strongly connected component is a directed graph in which every vertex is reachable from every other vertex. There is one SCC in the example state diagram which is shown in Figure A3. Since every pair of vertices are mutually reachable in an SCC, only one path is needed to cover all the vertices and edges in the SCC. We therefore decide to generate paths for SCCs in a separate step (step 5) and replace the SCCs of the state graph with single vertices. The


15


Figure A3. SCC in the StateMachineDemo and its graph representation.

Figure A4. Reduced state graph of StateMachineDemo.

Figure A5. FindAllSTPaths algorithm used to initialize the flow network.

Table A1. Complete path cover for edges in reduced state graph. Path number 1 2 3 4 5 6 7

s-t paths Initial, tr0, StateX, tr1, StateA, tr3, StateB&C&D&E, tr8, StateF, tr9, Final Initial, tr0, StateX, tr1, StateA, tr3, StateB&C&D&E, tr11, StateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr10, StateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr13, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr12, StateA, tr3, StateB&C&D&E, tr8, StateF, tr9, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr12, StateA, tr3, StateB&C&D&E, tr11, stateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr17, StateJ, tr18, Final

state graph after this step is called a reduced state graph. The reduced state graph of state diagram StateMachineDemo is shown in Figure A4. Note the SCC is now shown as a single vertex State B&C&D&E. The buckle on vertex State A is reduced as well. In brief, this step reduces the complexity of state graph, so it is relatively easy to generate a minimum path cover in later steps. But keep in mind, the things that we omitted for now will be handled in later steps. The resulting reduced state graph in step 3 is a single-source and single-sink directed acyclic graph. The next step will identify a minimum set of s-t paths which covers all the edges in the reduced state graph. Such a set corresponds to the minimum set of initial-tofinal state transition paths in the originating state diagram.

16

B. WEI ET AL.


Figure A6. State graph expressed as a flow network with 1-lower limit on each edge.

Table A2. Minimum path cover for edges of the state graph. Path number 1 3 6 4 7

s-t paths Initial, tr0, StateX, tr1, StateA, tr3, StateB&C&D&E, tr8, StateF, tr9, Final Initial, tr0, StateX, tr10, StateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr12, StateA, tr3, StateB&C&D&E, tr11, stateG, tr16, StateJ, tr18, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr13, Final Initial, tr0, StateX, tr14, StateI, tr17, StateJ, tr18, Final

Step 4: Find a minimum path cover for edges in the reduced state graph Our approach of finding a minimum path cover for edges in the state graph is based on the conclusion of Ntafos and Hakimi’s paper [15]. They proved that a minimum path cover problem for a directed acyclic graph can be solved by solving a particular minimum flow problem in a flow network. In the spirit of their conclusion, we first express our reduced state graph (Figure A4) acquired from step 3 as a flow network and then solve the minimum flow problem in that flow network, so that in the end, we can obtain a minimum path cover for edges in the state graph from the minimized flow network. As mentioned in Section 2, a flow network is a directed graph where each edge has a lower flow requirement and a current flow. We express the state graph as a flow network by labeling each edge with a lower flow requirement and a current flow. In this work, a unit of flow on an edge of a state graph is considered as one appearance of that edge in the s-t paths of a path cover of the state graph. The recursive algorithm FindAllSTPaths (Figure A5) generates a complete path cover which includes all the distinct s-t paths in the state graph. In this example, the FindAllSTPaths algorithm identifies seven s-t paths in the state graph (Table A1) which correspond to seven initial-to-final state transition paths in the originating state diagram. The state graph is then labeled and thus expressed as a flow network (Figure A6) based on the paths in the complete path cover. For the tuple on each edge, the first number is the lower flow requirements of each edge, it is always one—i.e. each edge must be used at least once in the set of paths; the second number is the current flow which represents the number of times that edge is, in fact, used in the set of paths. For example, tr3: (1, 4) in Figure A6 means that edge tr3 appears in four different s-t paths in the complete path cover showed in Table A1. The current overall flow of the entire flow network is seven (current flow of edge tr0) which, unsurprisingly, is equal to the total number of s-t paths in the complete path cover. The state graph is expressed now as a flow network with flows, and the problem of finding a minimum set of s-t paths that covers all the edges in the state diagram is reduced to the problem of minimizing the current flow of the flow network. The modified Ford and Fulkerson algorithm [20,21] can then be used to minimize the flow in the flow network in Figure A6. The modified Ford-Fulkerson algorithm (Figure A7) iteratively decreases the flow in the flow network. During each iteration, the algorithm decreases the units of flow by identifying a decreasing path. A decreasing path is an s-t path in the flow network such that the current flow of each edge on that path is greater than one. When such a path is found, each current flow of the edges on that path is decreased by one unit of flow. The algorithm terminates when there is no way to find such a decreasing path in the flow network, in other words, every s-t path in the flow network contains at least one edge whose current flow is one. The result of applying modified Ford-Fulkerson algorithm to the flow network is shown in Figure A8. The minimum flow of the flow network is now five (the current flow of tr0). We successfully reduced two units of flow from the original flow network in Figure A6. So five s-t paths is sufficient to cover all the edges in the state graph and no less. In the end, GenerateMinimumPathCover (Figure A9) algorithm is used to identify the minimum path cover from the minimized flow network. The s-t paths generated by this algorithm are listed in Table A2. Compared with the complete path cover in Table A1, path 2 and path 5 are eliminated. The five s-t paths in state graph corresponds to five initial-to-final state transition paths in the originating state diagram. If we considered the semantic mapping in Section 3.2, we could generate the sequence diagrams in Figures A10 and A11 based on the set of state transition paths. In order to save space, we include only the K.A. Opportunities labels in the first generated sequence diagram sd seq1 in Figure A10. In summary, in order to find a minimum path cover for edges in the state graph, we translate the problem into a minimum flow problem and use well-known algorithms to acquire the minimum flow of the flow network. Given the minimized flow network, the minimum path


17


Figure A7. Modified FF algorithm.

Figure A8. Flow network with the minimum flow.

Figure A9. Minimum path cover generation algorithm.

cover can be generated. In this example, the desired s-t paths is reduced from 7 to 5. The number of the minimum set is fixed based on the conclusion of Ntafos and Hakimi’s paper; however, the actual sequences in the set may vary. This is the source of our claim that more than one set of sequences matching our properties can come out of this approach. From step 1 to step 4, we first converted the given state diagram to a reduced state graph from which a complete path cover is generated using FindAllSTPaths algorithm. The current flow on each edge of the reduced state graph was then labeled based on the number of times each edge appears in the complete path cover. The modified Ford-Fulkerson algorithm was then applied to minimize the flow of the labeled state graph (i.e. flow network). In the end, we looked for the minimum path cover from the minimized flow network using GenerateMinimumPathCover algorithm. Step 4 identifies the minimum set of sequence diagrams as shown in Figures A10 and A11. However, a closer look at the sequence diagrams in the two figures would reveal many red ref boxes (interaction use) which mean the sequence diagrams are far from complete. Each ref box is a reference to another interaction, which is usually defined in its own sequence diagram. There are some subsequences missing for sequence diagrams in Figures A10 and A11: the subsequences for traversing the SCCs, the subsequence for entering and leaving a state, and the subsequences for buckles on vertices. The following steps are used to complete the transformation by providing subsequences in the ref boxes. They are auxiliary to the overall approach, but required for completeness. The strongly connected components and buckles that are ignored in step 3 are considered to form subsequences in step 5 and step 7, respectively. Step 6 forms a sequence for each state with entry, exit, and do activities. In order to save space, we show only the process of completing sequence diagram sd seq 1 (i.e. create a sequence diagram for each ref box) since it contains all the elements, we are discussing in the following steps.

Step 5: Form subsequences using SCCs Before we applied the algorithms of step 4 to find a minimum path cover in a state graph, each of the strongly connected components (SCC) is contracted into a single vertex in step 3. The real vertices and edges in the SCC are not taken into consideration when generating a minimum path cover. As a result, in the set of sequence diagrams generated based on the minimum path cover in step 4, the sequences for those collapsed SCCs are missing and are represented as ref boxes. For example, the SCC StateB&C&D&E in the minimum path cover (appears in path 1 and path 6 in Table A3) is represented as a ref box StateB&C&D&E in the sequence diagram in Figures A10 and A11 which needs to reflect a subsequence of the SCC. In this step, we form paths for covering edges in SCCs. The path for each SCC corresponds to a separate sequence diagram that is referenced by the set of sequence diagrams in step 4 through use of ref box. In order to form a path for an SCC vertex in an s-t path, we need to solve two issues: First, determine the starting and ending vertices of the path for an SCC. For example, in Figure A12, the starting and ending vertex of SCC StateB&C&D&E in path 1 (Table A3) are vertex State B and State E, respectively. Second, find a path that covers all the edges at least once in the SCC. With the two issues in mind, our strategy of forming a path for an SCC includes finding an Euler cycle from starting vertex to itself and a shortest path from starting vertex to ending vertex of the SCC. In graph theory, an Euler cycle starts and ends on the same vertex and visits every edge exactly once in a graph. So the Euler cycle is sufficient to solve the second issue. After identifying an Euler cycle that

B. WEI ET AL.


18

Figure A10. Generated sequence diagrams sd seq 1, sd seq3.



Figure A11. Generated sequence diagrams sd seq 6, sd seq4, sd seq7.

19

20

B. WEI ET AL.


Figure A12. The reduced state graph and the contracted SCC.

Figure A13. Euler cycle (EC) and shortest path (SP) for SCC StateB&C&D&E in path 1.

Table A3. Two s-t paths including SCC. Path number 1 6

s-t paths Initial, tr0, StateX, tr1, StateA, tr3, StateB&C&D&E, tr8, StateF, tr9, Final Initial, tr0, StateX, tr14, StateI, tr15, StateH, tr12, StateA, tr3, StateB&C&D&E, tr11, stateG, tr16, StateJ, tr18, Final

Table A4. Euler cycle and shortest path for SCC StateB&C&D&E in path 1. Path name Euler cycle (EC) Shortest path (SP)

Path details StateB, tr4, stateC, tr5, StateD, tr6, StateE, tr7, StateB StateB, tr4, stateC, tr5, StateD, tr6, StateE

starts and ends on the starting vertex, we need to find a way to exit the SCC from a proper vertex and stay on the s-t path which includes the SCC. So a shortest path from the starting vertex to the ending vertex of this path is added after the Euler cycle. So, in brief, we use an Euler cycle which starts and ends on the starting vertex of the SCC to make sure that we cover all the edges exactly once in the SCC, and then use a shortest path from the starting vertex to the ending vertex to make sure the generated path is compatible with the s-t path in which it is inserted. We demonstrate the generation of a path for SCC StateB&C&D&E in path 1 (Table A3). In Figure A13, we use bold arrows to show the Euler cycle which covers all the edges in the SCC exactly once on the left and a shortest path from starting vertex State B to ending vertex State E on the right. The two paths are also listed in Table A4. The path generated for the SCC StateB&C&D&E in path 1 is the concatenation of EC and SP: StateB, tr4, stateC, tr5, StateD, tr6, StateE, tr7, StateB, tr4, stateC, tr5, StateD, tr6, StateE. The path for the SCC StateB&C&D&E corresponds to a state transition path in the originating state diagram which is transformed into a separate sequence diagram in Figure A14 named sd StateB&C&D&E1. When the execution encounters the interaction use ref StateB&C&D&E1 sequence diagram sd seq1, sd StateB&C&D&E1 will be executed. In order to save space, we also include the results of later steps in Figure A14. The left sequence diagram is the one generated from step 4, the middle one is sequence diagram for the SCC, and the right two diagrams are for simple state State A and composite state State F, respectively. So in later steps, we will reference back to this figure often. The Euler cycle guarantees that every edge in a SCC is covered exactly once and a shortest path makes sure the path gets out of the cycle in the SCC and stay on the main sequence in step 4. Finding Euler cycle is a well-known problem that can be efficiently solved in linear time. Hierholzer’s 1873 paper [22] provides a method for finding Euler cycles. Shortest paths can be generated using Dijkstra’s algorithm [23]. However, not every SCC graph has an Euler path. A directed and strongly connected graph has an Euler cycle if and only if the number of incoming arrows is equal to the number of outgoing arrows for each vertex. In the light of the above theorem, we need to Eulerize the sate graph before extracting an Euler cycle. Eulerizing a graph can be found in [24]. Robinson used Eulerization technique in generating testing cases for a strongly connected state diagram. Interested readers can reference that paper to see detailed Eulerization process.



21

Figure A14. Sequence diagram sd seq1 and its reference sequence diagrams.

Step 6: Form subsequences using each vertex (state) Based on the semantic analysis of a state, we find that a state is a good candidate for generating sequence. The object itself might perform certain activities in a sequence while being in a state, so we try to represent the hidden sequence information from a state in this step. The sequences generated by states are defined in the ref box with the name of the state. A state in a state diagram may include entry activity, exit activity, internal transition, and do activity. A separate sequence diagram is developed in the ref box for each state based on the order of entry, exit, and do activities. In the example StateMachine Demo, the sequence diagram generated for state State X is shown in sd State X in Figure A14 and referenced by sequence diagram sd seq1, and the exit activity is inserted in the original sd seq1 in order to complete the sequence for State X. Composite states that were contracted in step 1 are also considered here. In the example StateMachineDemo, the sequence diagram generated for composite state State F is shown in sd State F in Figure A14. The nested level issue is discussed in the Discussion section of this paper.

22

B. WEI ET AL.


Figure A15. Self-transition case 1.


Step 7: Form subsequences using buckles on vertices The way we process a buckle is different from that of a normal edge. This is because in a state diagram, a self-transition normally implies the repetition of event occurrences that do not take the object to a different state. So instead of just covering it only once in the sequence diagram, we use a combined fragment loop in sequence diagram to represent to the continuation of receiving the same message. We considered three situations based on the event and guards on the self-transition: Case 1: One self-transition with no guards (left side of Figure A15). This pattern in state diagram is transformed to the sequence diagram on the right side of Figure A15: message implied by Event1 is received several times until a certain condition is no longer true and then reception of a message implied by Event2 takes the object to a different state. The sequence diagram modeler will need to fill in the loop condition. This is considered as a semantic hole in the sequence diagram. If the modeler does not think there should be a loop in the sequence diagram, he can simple take out the combined fragment loop. But this is our default assumption of a self-transition. Case 2: One self-transition with guard (left side of Figure A16). In this case, the self-transition and the transition to another state share the same event. The sequence we created for this pattern is shown on the right side of Figure A16, which means the repeated reception of message implied by Event will not take the object to a different state while guard1 is true. This decision comes from the fact that in a real state diagram, it is very likely that for a self-transition; the occurrence of an event would change the truth value of the guard1. Case 3: Two self-transitions with guards. In this case, two self-transitions and one transition to another state share the same event but different guards (left side of Figure A17). This implies that it is not possible for both guard1 and guard3 to be true at the same time. The sequence diagram for this case is shown in Figure A17, which means that while guard2 is not true, the repeated reception of the message implied by Event would either trigger the first or the second self-transition based on whether guard1 or guard2 is true. The combined fragment alt and loop are used together to describe this case. Note that in all three cases, the compartments in the combined fragments are left empty, a sequence diagram modeler will be presented with those blanks and start filling in the missing requirements. In the example StateMachineDemo, the subsequence caused by the self-transition on State A is developed in sequence diagram sd State A in Figure A14.

Step 8: Annotate guards on transitions in sequence diagrams By going through step 1 to step 7, our approach deterministically transforms a state diagram to a set of sequence diagrams. Each of the sequence diagrams is generated based on a particular initial-to-final state transition path in the state diagram, for example, the bold arrows in Figure A18 shows the state transition path which is transformed into the sequence diagram sd seq1 (shown in Figure A14). In this step, we annotate guards in the sequence diagrams to guarantee their feasibility. In a state diagram, whether a state transition path can actually occur or not depends on the truth values of guards in the path. If any guard along a path evaluates to false, the rest of the sequence of events along that path will never have a chance to trigger transitions; therefore, the state transition path is considered as infeasible. For example, in the bold state transition path in Figure A18, if guard1 on the transition between State X and State A evaluates to false


23



Figure A18. A sequence of state transitions implied by sd seq1.

when evt1 occurs, the transition will not fire; thus, the rest of this state transition path is infeasible. Since sequence diagram sd seq1 is generated based on such a state transition path, we must guarantee that guard1 is properly handled in sd seq1. In order to solve this problem, we attach a K.A. Opportunity note to every message in the sequence diagram that might trigger a transition with a guard in the state diagram. The K.A. Opportunity note basically reminds the modeler the existent of a guard at this point and the guard must evaluates to true in order to proceed in the sequence. For example, in Figure A14, we attached a note ‘K.A. Opportunity: Insert sequence to guarantee guard is true’ to the message ev1 in sd seq1 to remind the modeler that additional information is needed at this point to guarantee the guard is true.