Control Flow Analysis of UML 2.0 Sequence Diagrams

1. Control Flow Analysis of UML 2.0 Sequence Diagrams Vahid Garousi, Lionel Briand and Yvan Labiche Software Quality Engineering Laboratory (SQUALL) Department of Systems and Computer Engineering Carleton University, Ottawa, Canada ECMDA Conference November 9th, 2005

2. Outline • Motivation • Related Works • Model-based Control Flow Analysis (MBCFA) • Challenges of CFA based on SDs • Our Approach • CFA of an Example SD • Conclusions and Future Works

3. Definitions • Control Flow Analysis (CFA) is a widely used approach for analyzing structured and object-oriented programs. A Control Flow Graph (CFG) is a static representation of a program that represents all alternatives of control flow. • Based on the source of information to derive the control flow information of a system, we can divide the CFA techniques into two groups: • Code-based CFA (CBCFA): The traditional CFA, in which control flow information is derived from the available source code. • Model-based CFA (MBCFA): Derivation of control flow information from the design model (such as UML) of a software system.

4. Motivations

5. Related Works • There have been several MBCFA techniques in the literature. But there is none which addresses all the following set of criteria (at the same time): • Support of UML 2.0 SDs • Formal metamodel for the produced Control Flow Model (CFM) • Formal transformation/mapping rules (to ease implementation) • Support for concurrent control flow due to asynchronous messages • Inter-SD control flow support • Loop support • Condition support • Support for polymorphism in SD lifelines • And that is the goal of the current work…

6. Challenges of SDs’ CFA • Impact of Asynchronous Messages • Resulting in concurrent control flow

7. Challenges of SDs’ CFA (cont.) • Impact of Asynchronous Messages • Impact of par Interaction Operator • Resulting in concurrent control flow

8. The Need for a Control Flow Model • One might argue that an intermediate CFM is not needed for MBCFA and an algorithm can be built to derive CFPs directly from a SD. • However, a requirement that necessitates an intermediate CFM for SD is that concurrent control flow information of SDs (due to asynchronous messages and parallel interaction operands) cannot be explicitly derived without an intermediate CFM. • Furthermore, such a CFM can be graphically represented by UML CASE tools to visualize/animate concurrent control flow in SDs. • This can be useful in model execution/comprehension/walk-through/etc.

9. Towards a CFM: Concurrent CFG (CCFG) • UML activity-diagrams, Petri-nets… • Which activity-diagram package to use? • Re-use or extend? Exception handling Advanced data flow features Edge weights (# of tokens allowed)

10. CCFG Corresponding to an Example SD:How it should be.

11. CCFG metamodel (Extension to IntermediateActivities)

12. Our Approach

13. A Set of OCL-based Mapping Rules

14. An Example (Rule #2)First Message End  Flow between InitialNode and first Control Node • Visualization • Metamodel instances

15. An Example (Rule #2) (cont.) • Consistency of metamodel instances • OCL rule For every instances of interaction fragment interFragin the SD context, there should be an instance in of initial node in the CCFG context, such that: • The activity corresponding to in corresponds to the CCFG corresponding to interFrag • … SD::InteractionFragment.allInstances->forAll(interFrag:InteractionFragment| CCFG::InitialNode.allInstances->exits(in:InitialNode| in.activity=Utility::Util.getCCFG(interFrag) and in.outgoing->includes(flow:ControlFlow| getCCFG(interFrag).node->exits(mn:ActivityNode| mn.inFlow->includes(Utility:: Util.getFirstMessage(interFrag).sendEvent) and flow.target=mn ) ) ) )

16. Concurrent Control Flow Paths (CCFP) • We have defined a grammar to derive CCFPs from a CCFG, based on: Regular Expressions and Interleaving. • A compact, legible representation

17. Conclusions • A control flow analysis methodology for UML 2.0 sequence diagrams • Based on OCL consistency rules • To ensure the completeness of the rules and the CCFG metamodel with respect to our CFA purpose • And to enable their verification. • The output of our technique can be used in Sequence Diagram-based test techniques and other Model-Driven Development (MDD) activities. • We have already used the output of MBCFA in: • Model-Based Predictability Analysis (e.g. Resource Usage Analysis) • Model-Based Traffic-aware Stress Testing • Model-Based Dynamic Dependency Analysis • Furthermore, we have defined a grammar to derive Concurrent Control Flow Paths (CCFP), which are a generalization of the conventional Control Flow Path.

18. Future Works • Definition of test-based coverage criteria in CCFGs and CCFPs • Devising a consistency-rule based Data Flow Analysis (DFA) technique to derive data flow information from SDs • Implementing OCL transformation rules to transform a SD into a CCFG, i.e., using a MDA transformation definition language. • The idea is similar to the transformation rules given in to transform a PIM (Platform Independent Model) to a PSM (Platform Specific Model) in the context of the MDA framework. • Investigation of model-based test techniques and other applications which can make use of MBCFA outputs.

19. Questions/Answers…