Modern software systems need to function with great reliability, as software has become critical to advancement in many areas of human endeavour. Software systems can be large-scale with complex layers of control such as air traffic control systems, telecommunication systems or can be small scale and simple, such as a pocket calculator, a mobile device, etc. These systems are used in various application domains such as healthcare patients control systems [Abu- rub et al., 2007], real time embedded systems (elevator systems) [Fernandes et al., 2007,Radjenovic and Paige, 2010] and computer system networks (cloud
computing) [web services, ,Microsoft, ]. The development of these software sys- tems require (or at least benefit from) strong modelling and analysis methods including quantitative modelling and formal verification.
Modelling a software system is a core area in a software development pro- cess. Software design models can be mainly categorised into two types: graphi- cal design models or formal design models (see Section 2.4 for more details). A graphical design model represents a system using diagrammatic notations. For example, the Unified Modelling Language (UML) is an industrially well-known standard, but mostly an informal graphical modelling language for the design of software systems. Live Sequence Charts (LSC) [Harel et al., 2005, D. Harel, 2003, Harel and Kugler, 2002], and Message Sequence charts (MSC) [ITU, 1999, Alur et al., 2003, Uchitel and Kramer, 2001] can be considered as other popular design models with scenario-based descriptions. Scenario or interac- tion is the observable behaviour of information exchange between participating entities that perform a task. In this section, we describe UML as a graphical design model.
UML is a widely used object-oriented modelling language in present soft- ware development. UML has been standardised by the Object Management Group (OMG) [OMG, 2011a] and incorporates the best practises in modelling techniques and software engineering. UML modelling can be applied to many systems in a variety of application domains varying from simple standalone applications to global enterprise solutions [Bernardi et al., 2002, Gherbi and Khendek, 2006,Tang et al., 2010,Dinh-Trong et al., 2006,Tran et al., 2006,Hau- gen et al., 2006,Anda et al., 2009,Haugen et al., 2005,Campos and Merseguer, 2006]. Hence, UML is a general purpose language for system modelling.
This thesis considers UML 2, which was released in 2005. UML 2 facilitates the design of complete system models with the use of new graphical syntax
compared to previous UML 1.x versions [Arlow and Neustadt, 2005, OMG, 2011a, Douglass, 2004]. For example, UML 2 contains notations that support abstraction and real-time features in a system model. Also, UML 2 is featured with nested classifiers, which are a powerful concept in software modelling that allows one to model complex behaviours.
Figure 2.4: The structure of UML diagrams (adapted from [Arlow and Neustadt, 2005]).
A UML model can consist of many diagrams of different types, where each diagram presents a different view of the system. Figure 2.6 shows the organi- sation of UML diagrams that can be used to model structural and behavioural aspects of a software system [Arlow and Neustadt, 2005, OMG, 2011a, Dou- glass, 2004].
Structure diagrams such as class, object, component, deployment, and package diagrams depict a structural view of the system including concepts and properties. Behavioural diagrams such as activity, use case, state machine and interaction diagrams depict a behavioural views of a system including
methods, collaborations, activities, and state histories. Interaction diagrams can be further categorised into sequence diagrams, communication diagrams, interaction overview diagrams and timing diagrams. We consider sequence di- agrams as the main design model in this thesis and Chapter 3 describes this in more detail.
The expressive power of UML 2 models can be enhanced using the con- structs of the Object Constraint Language (OCL) [Arlow and Neustadt, 2005, OMG, 2006]. OCL is a widely used constraint language that specifies extra information on UML models [Cabot et al., 2008, Cabot et al., 2010b, Cavarra and Filipe, 2004]. These OCL constructs can be directly associated with UML elements as tagged values or notes. Since OCL is a passive and pure specifi- cation constraint language, the OCL constructs do not affect the UML model by changing any value.
Even though the intuitive notations of UML diagrams greatly improve the communication among developers, the lack of a formal semantics makes it difficult to automate analysis and verification of the software design models. Generally, the UML standard [OMG, 2011a] has focused on defining the syntax of models specifying the valid combination of model elements that are based on meta-models. The semantics that defines the mapping of the model language elements into a domain of values has only been defined informally. i.e. UML models cannot be used directly for formal model analysis and verification of design models.
Much work has been done or proposed for representing UML semantics in a formal way in order to enable model validation, model checking and consistency checking of design models [Harel and Maoz, 2007, Cimatti et al., 2011, Kong et al., 2009, Straeten et al., 2007, Zhang et al., 2009, Li et al., 2004, St¨orrle, 2004, Shen et al., 2008a, Lund and Stølen, 2006, Dan et al., 2007, Shen et al.,
2008b].
There is a range of approaches for defining semantics of UML models. For- mal representation using denotational semantics is a well-established approach that maps every syntactic construct to a semantic construct of the model [Harel and Maoz, 2007,Lano, 2009,St¨orrle, 2004,Cengarle et al., 2006,Hammal, 2006]. For example, the work done in [St¨orrle, 2003a, Halvorsen et al., 2007, Haugen et al., 2006,Haugen et al., 2005,Cengarle and Knapp, 2004] has described deno- tational trace semantics in order to capture the meaning of sequence diagrams with time information.
Other widely used formal representations are based on operational [Lund and Stølen, 2006, Zhang et al., 2009], transformational [Kong et al., 2009], al- gebraic, axiomatic, and meta-modelling approaches [Lano, 2009]. Algebraic approaches map the language constructs into a mathematical algebra and meta-modelling approach uses a subset of UML itself as a semantic domain for UML.
Axiomatic semantics defines an interpretation of UML into a mathemat- ical formalism such as first-order set theory. i.e. this technique maps lan- guage constructs into logical theories, consisting of mathematical structures together with axioms defining their properties. For example, the work done in [Cimatti et al., 2011] describes the formal representation of class diagrams, and combines fragments of first order logic (to describe rich data and relation- ships between attributes and entities) with temporal operators (to describe the evolution of the scenarios). A partial order semantics for UML interaction diagrams is presented in [St¨orrle, 2003b] and an automata theoretic semantics for scenario-based descriptions of reactive systems is presented in [Grosu and Smolka, 2005, Moschoyiannis et al., 2009]. Moreover, logic based semantics for UML interactions is defined in [Bowles, 2006, St¨orrle, 2003a, Runde et al.,
2005].
Operational approaches map a language into structures of an abstract exe- cution environment. For example, work done in [Zhang et al., 2009] has defined an operational semantics for real-time state-charts, and work done in [Li et al., 2004] has presented a formal semantics in abstract syntax form to check the consistencies among different UML diagrams.
Transformational approaches map a language into another language, which already has semantics, in order to assign semantics to the source language. For example, behavioural semantics for statechart diagrams has been specified using graph transformation techniques in [Kong et al., 2009], and sequence dia- grams have been formalised using Abstract State Machines (ASMs) in [Cavarra and K¨uster-Filipe, 2004].
Different approaches to formal representations have unique advantages and disadvantages and support different forms of analysis. For example, algebraic approaches are particularly good for reasoning about the equality of models. Axiomatic approaches support general reasoning and a comprehensive expres- sion of language features, but at the cost of using elaborate formalisms for which the support tools may not exist. Meta-modelling and transformation approaches require the existence of a language with a well-defined semantics (for example Petri-nets). Section 2.4 describe this in more detail.
Instead of relying on basic mathematics, related work often have proposed the use of specialised formalisms such as Z [Spivey, 1992], VDM [Jones, 1990], B-specification [Idani and Ledru, 2006], Event-B [Mosbahi et al., 2011] and Object-Z [Derrick and Wehrheim, 2010] and Template semantics [Shen et al., 2008a].
In this thesis, we avoid the use of more specialised notations when defining the formal representation of UML sequence diagrams (Chapter 3), as these
notations are general and not adequate to express all concepts in UML. In particular, some of these formal notations have preferences such as use with theorem provers, constraint solvers (Alloy analyser [Nimiya et al., 2010]), time automata (UPPALL [Firley et al., 1999]) and model checkers (SPIN model checker [Holzmann, 1997, Amstel et al., 2007, Limaa et al., 2009, Yatake and Aoki, 2010]) when it comes to model analysis. For example, some of these techniques lack MDD-based high-level software concepts such as abstraction and not sufficient for object-oriented modelling [Spivey, 1992, Jones, 1990]. Further, some are capable of modelling and analysis of functional requirements [Nimiya et al., 2010,Anastasakis et al., 2010]or structural behaviour or untimed [Limaa et al., 2009] or timed behaviour [Firley et al., 1999], only. We kept the design model free of this bias to ensure that we obtain a true syntax and semantics which can be used for formal model transformation that enables future formal verifications. For these reasons we use only mathematics when formalising the design models considered in this thesis.