Jul 4, 2006 - by building mathematically rigorous models of complex systems are considered to be of .... enumeration of the instance variables of the object, forms a repre- sentation or state .... B-Tool Reference Manual. An Abstract ..... Schaum's outlines UML, chap- ter 2, pages ... [15] Pathfinder Solutions. Model-driven ...
Description and Validation of visual specification languages (UML (MDA)) using Object-Z Gasso Wilson Mwaluseke Institute for Computing Research London South Bank University July 4, 2006 Key Words: Object-oriented,Formalism, Concurrency, Inheritance, Semantics, Verification, UML and Notations, Real-Time, Reactive systems, MDA, embedded systems. Abstract The Unified Modelling Language (UML) is a visual specification language that provides a way for people who analyze and design objectoriented systems to visualize, construct and document the artifacts of software systems and to model the business organization that use such systems. However, the syntax and semantics of a number of UML constructs are not formal which makes it hard to understand. The use of mathematical techniques to model mathematical entities by building mathematically rigorous models of complex systems are considered to be of utmost importance because it is possible to verify the systems’ properties in a more thorough fashion than empirical testing. When correctly and appropriately applied, these techniques have proven themselves to result in systems of highest quality, improved system reliability, improved design time and comprehensibility and provability. In this paper, we evaluate some of the formal methods on the basis of concurrency, inheritance support, semantics and the mapping process, traces, representation of abstract syntax components, notation, tool support and automatic verification of behaviour as applied to dynamic models of UML semantics . This work leads to the establishment of the degree of formalism of a formal method that will be deemed generally acceptable for formalizing dynamic models of UML semantics and notations and thus making UML models suitable for Model-Driven Architecture (MDA) purposes. MDA is a standard framework for modeling software system [15] whose input depends on UML models.
1
1
Introduction
UML is a graphical notation whose model (specification of a system) is composed of different kinds of diagrams each representing a different view or part of the system [8]. These diagrams can be classified into two categories namely static and dynamic groups. UML is said to be a semi-formal language because its syntax and static semantics (the model elements, interconnections and well-formedness) are defined precisely, but its dynamic semantics are specified neither formally nor algorithmically [2]. UML suffers from a lack of formal semantics which is a common trend for many Object Oriented (OO) methods from which UML is derived. This does not only lead to confusions and different interpretations when analyzing a model but also decreases the ability to develop tools and guidelines to help the specification and design. To be able to check, validate, verify and refine software, designers require a more formal semantics of UML. Real-Time embedded and Reactive systems require more care and understanding in their design stages than other systems because of their complexity and also time handling. UML works hand in hand with Object Constraint Language (OCL) [2]. However, OCL and UML are both semi-formal notations. This means that the two are prone to misinterpretations and thus not very good modeling languages as far as Real-Time, embedded and Reactive systems which demand high level of correctness, concurrency, timeliness, responsiveness and fault tolerance. Model Driven Architecture (MDA) is a standard framework for modeling software systems [15]. A model that conforms to these standards captures and delineates the objectives, attributes, and operations of the embedded system. When the models are processed with MDA automation and transformation tools, the following are achieved: (1) automation and execution of application model for testing and validation purposes - before writing any code, (2) the automatic transformation of models into tested, deployable application. MDA systems comprise two parts namely: the Platform Independent Model (PIM) that specifies what the system does and Platform Specific Model (PSM) that specifies how the system is implemented. MDA depends on UML to capture the requirements. In order to define a formal semantics for UML, we list some features common to UML and indeed to object-oriented systems and use these features to select the suitable formal method(s) available in the market that best fits into the work of formalizing UML. In this paper, the matching of features of UML with the suitable formal method(s) is done in two stages namely listing down some features and then aligning these features with the features of some formal methods to see if such formal methods are capable of formalizing them for we strongly be2
lieve that mapping between UML and formal methods can only be achieved if their features match. The rest of the paper is arranged as follows: A cross section of formal methods, summary of formal methods properties, reasons for choosing Object-Z, formalism conclusion, UML Model Verification and Validation for embedded systems, related work and conclusion.
2
Some dynamic features of UML
UML has many features which are quite common for object-oriented systems. However, in this paper we have just picked a few of them which we believe are very common in complex systems. These features are explained below:
2.1
Concurrency and real-time
There are two reasons for constructing systems which show concurrent behavior: 1. Concurrency can be an important aspect of the world being modeled if the problem domain consists of co-existing elements that the model of the domain recognizes concurrently as active components. 2. Speeding up large computation may involve subdividing the computation into parts which can be computed concurrently thereby gaining time on a multi-processor machine. This can lead to highly parallel systems, with hundreds, or even thousands of executions of some basic algorithm executing simultaneously. In the real world concurrency is the norm. The world consists of collections of entities, people, machines, etc., which co-exist each of which may be pursuing its life and objectives, modifying its own state and the state of other objects in its environment, concurrently with others. The state of a world entity is represented in the model by its data variables; its laws of behavior are captured in the algorithms of the code. If the objects are active then they must be concurrently active. If an object in the real world changes its state spontaneously, by its own actions, then in the computer model its algorithms should execute concurrently with those of other world objects, they will be concurrent processes. The Unified Modeling Language (UML) is capable of modeling a system that exhibits concurrency and with some extensions, it is also capable of modeling real-time systems. UML notations fall under two categories namely those dealing with static features 3
and those dealing with dynamic features with the extension to deal with real-time features.
2.2
Inheritance support
This is one of the key features of any object-oriented methodology or language. It is divided into two main categories namely: 1. Representational inheritance. The composed structure, built from the enumeration of the instance variables of the object, forms a representation or state of the object. This representation is completely determined by the class definition in which case a type can be associated to each class definition representing the state. The definition of a subclass of an existing class introduces an extended type for the subclass. The type definitions may form a long chain of types, which are ’backwards’ assignment compatible in the direction of the root type. However, it is important to note that the extended type is not a subtype because it contains elements of different types than those of the basic type. In general, this representation inheritance scheme for a subclass implies inheritance of all invariant expressions from superclasses. Representational inheritance is restricted to strictly single inheritance. 2. Functional inheritance. Inheritance of methods in a strongly typed environment might lead to conflicts with the notion of typing. A good example of such a conflict is trying to add a vertex to a square without deforming the square. The addition of a vertex to a square does result in a polygon but different from the square. This can be avoided by introducing the notion of controlled inheritance which lets the user to specify the behavior without automatic coupling to the representational inheritance. This leads to multiple inheritance. UML is capable of capturing and presenting both single and multiple inheritance at design level.
2.3
Consistency checking
In UML, consistency checking is very important. For instance interaction diagrams involves the allocation of operations to classes. These operations must be listed against the correct classes in the class diagrams and if operation signatures have been specified in full these must be consistent [1]. 4
Likewise statecharts diagrams must be consistent with other models. Tools developed should be able to trace and verify the consistence between models.
3
A cross section of formal methods
With increasing complexity of software, and a greater requirement for software reliability, it has become clear that the old ad hoc informal methods of programming are no longer stringent enough [7]. The following is a list of some formal methods that have been picked up for matching with the above UML features:
3.1
The Z specification language
Z is a state-based specification language that has not been used for the specification of concurrent systems partly because it lacks a means of conveniently specifying systems in terms of components (which is an implementation issue) [13]. The Unified Modeling Langauge (UML) is a visual language that provides a way for people who analyze and design object-oriented systems to visualize, construct and document the artifacts of software systems and to model the business organizations that use such systems. Using Z specification language to formalize some of the UML constructs will prove to be insufficient. However, Z specification language is ideal for specifying toplevel functionality of a system. For example, a simple buffering system that can store up to ten items can be modeled in Z as follows: System[T ] s : seqT #s ≤ 10 Init[T ] System[T ] s = hi In[T ] ∆System[T ] in? : T #s < 10 s 0 = s a hin?i 5
Out[T ] ∆System[T ] out! : T s h i s = hout!i a s 0
3.2
Object-Z language
Object-Z is an extension of Z which includes a special class construct to encapsulate a state schema with the operations which may effect that state and is designed to support an object-oriented specification style. In ObjectZ, a system is thought of as a collection of distinct, interacting components called objects. The above example could be modeled in Object-Z using one class inside of which there are one nameless state and three operations namely initializing operation, in and out operations as indicated below: Buffer [T ] buf : P T #buf ≤ 9 INIT buf = ∅ In ∆(buf )item? : T buf = buf 0 = {item?} Out ∆(buf )item? : T buf = {item!}buf 0 =
In Object-Z, an operation can refer only to the state of the object to which it belongs whereas a Z specification typically defines a number of schemas defining state and operations.
6
3.3
Vienna Development Method (VDM)
Like Z, Vienna Development Method is a state-based specification language that allows not only specification, but also the ability to move from the highlevel abstract data types of the original specification to the data types of the target programming language. It also embodies a principle known as operational decomposition which enables decomposition of specified functions and operations into more implementable versions of the target language. However, VDM does not include the ability to specify concurrent processes [7] and this is a disadvantage in the specification of communications protocol and other areas such as UML statecharts and sequence diagrams. A lot of work is done to make VDM have the ability to handle concurrency but none has been documented and approved by ISO.
3.4
VDM++
VDM++ is an object-oriented specification based on VDM-SL. It consists of a set of class definitions which provide templates for objects that possess attributes and operations (methods) whose types and properties are defined in the classes. There are also features provided that are specifically related to concurrency and real-time. Concurrent systems are often confused with real-time systems because real-time systems are often concurrent and vice versa [18].
3.5
Language Of Temporal Ordering Specification (LOTOS)
LOTOS is a formal description technique designed to describe distributed concurrent information processing systems, in particular for service definition and protocol specification within the OSI (Open Systems) architecture and related standards [7]. It is a well-defined mathematical notation providing a good basis for analysis and the development of support tools, including simulators, compilers and test sequence generators. The basic constructs of LOTOS allow modeling of sequencing, choice, concurrency and non-determinism in an entirely unambiguous way. It also permits modeling of synchronous and asynchronous communication.
3.6
Extended State Transition Language (Estelle)
Estelle is a modification and extension to Pascal where program-level constructs have been replaced by constructs to define finite-state modules exchanging queued messages. Estelle specification defines a system of hierar7
chically structured state machines. A distributed system specified in Estelle is viewed as a collection of communicating components called module instances. Modules are declared either as processes or activities which can be used to represent loose parallelism, where concurrency is expressed by interleaving of parallel actions.
3.7
Larch
Larch is a property-oriented specification language combining both axiomatic and algebraic specifications in two-tier specification namely the auxiliary specification and the interface specification. Larch is particulary good when verifying an implementation.
3.8
The B-Method Specification Language
The B-Method is not intended for creating software in the application layer, since applications usually have informal requirements, but it is intended for producing software in the API layer and the component layer because in these layers, the requirement is often formally expressed [19]. B-Method is an implementation formal specification language. The B-Method is a collection of mathematically based techniques for the specification, design and implementation of software components. Systems are modeled as a collection of interdependent Abstract Machines, for which an object-based approach is employed at all stages of development. Abstract Machine constructs are described by the following BNF-like syntax; the order in which optional clauses appear is not significant. Here, the syntax exp1 | exp2 indicates exp1 or exp2 (choice), < exp > indicates zero or one occurrence of exp (optionality) and > indicates zero or more occurrences of exp (repetition). Identifier, UpperCaseIdentifier, Rule, Bnumber, Formula and ProgramLikeFormula are as defined in the section on the B-Platform and in the B-Tool Reference Manual. An Abstract Machine is described using the Abstract Machine Notation (AMN). A uniform notation is used at all levels of description, from specification, through design, to implementation. AMN is a state-based formal specification language in the same school as VDM and Z. An Abstract Machine comprises a state together with operations on that state. In a specification and a design of an Abstract Machine the state is modeled using notions like sets, relations, functions, sequences etc.. The operations are modeled using Pre- and Post-conditions 8
using AMN. In an implementation of an abstract machine the state is again modeled using a set-theoretical model, but this time we already have an implementation for the model. The operations are described using a pseudoprogramming notation that is a subset of AMN. The B-Method prescribes how to check the specification for consistency (preservation of invariant) and how to check designs and implementations for correctness (correctness of data refinement and correctness of algorithmic refinement). The B-Method further prescribes how to structure large designs and large developments, and promotes the re-use of specification models and software modules, with object orientation central to specification construction and implementation design.
3.9
Communicating Sequential Processes (CSP)
Communicating Sequential Processes, or CSP, is a language for describing patterns of interaction. It is supported by an elegant, mathematical theory, a set of proof tools, and an extensive literature. CSP is a process-based specification language that models concurrent systems as a collection of of processes which interact via a ’handshake’ mechanism. However CSP is not ideally suited to the specification of higher-level functionality [14]. It supports concurrency but not very keen with inheritance and classes. 3.9.1
TROLL
TROLL Stands for Textual Representation of Object Logic Language. The TROLL approach supports the declarative specification of conceptual models. It integrates concepts for modelling of dynamic, structural and process aspects. It combines the intuitive diagrammatic notation OMTROLL with a textual one. TROLL allows the modeling of concurrent object system.
4
Summary of Formal Methods properties table
It is apparent from the above explanations that most of the object-oriented formal methods can be considered to be suitable for formalization of UML semantics because they combine both the static and dynamic aspects which are the properties of UML. The following table shows a summary of the formal methods and their properties.
9
Language Concurrency Inheritance Animation Tool Model-based Z NO No Yes Yes Yes Object-Z Yes Yes Yes Yes Yes VDM No No Yes Yes Yes VDM++ Yes Yes Yes Yes Yes Estelle Yes No Yes Yes No Larch Yes No Yes Yes Yes LOTOS Yes No Yes Yes Yes B-Method No No Yes Yes Yes CSP Yes No Yes Yes Yes TROLL Yes Yes Yes Yes Yes From the above table Object-Z emerges favourable to formalizing UML semantics and notations. The work of formalization of UML semantics and notations is very important for model validation and verification to be possible. The Model Driven Architecture will be incomplete if UML will be in its current state. However not all formal methods are capable of formalizing all the semantics and notations that UML can exhibit as depicted in different domains of systems. In all fairness, almost of all the above formal methods can formalize the UML semantics to some extent. However, some can do so the hard way whereas others one need not work very hard to accomplish the goals.
5
Reasons for choosing Object-Z to formalize UML semantics
There are several reasons that have led us to choose Object-Z as the main formal specification language for formalizing UML semantics and other notations over other formal specification languages . These reasons are based on Style, Syntax, Inheritance, Concurrency, Refinement, Simulation, Animation and consistency checking as well as correctness proving as described below:
5.1
Styles
Formal methods are broadly classified into two main categories namely Constructive (i.e mathematical models are constructed of a system) and Behavioural (i.e system is expressed in terms of properties of its input and outputs). The categories give rise to different specification styles and methodologies all based on discrete mathematics. According to these styles, it is
10
Refinement Yes Yes Yes Yes No No Yes Yes Yes No
apparent that some are suited to specifying particular types of computer systems (e.g, protocols) and some are suited to mechanistic manipulation for proof analysis or animation [7]. These two categories are respectively named as Model-Oriented Specification and Property-Based specification languages. Under model-oriented specification, the model is represented as an abstract mathematical model and operations and functions within these systems are expressed in terms of standard collections of basic data types and other type constructors. Specifications can be represented implicitly (expressing operations in terms of what they are required to accomplish without the consideration as to how the task is to be done) or explicitly (i.e specifications are given in terms of how the operations will be carried out) or in a mixture of these styles. Model-based specification methods are, however, better suited to describing certain systems than property-based. Implicit statements can therefore be refined to more explicit statements whereas explicit specifications can be expressed in a number of styles such as: imperative (i.e state-based) and declarative (i.e applicative or logical). Under Property-based or axiomatic specifications, the behaviour of a system is defined indirectly by stating a set of axioms defining properties that the system must satisfy. Object-Z is a model-based specification language. However, Objet-Z contains other features which are not usually found in many model-based formal specification languages that enable it to behave as a property-based specification language (implementation). These features include Concurrency handling, inheritance and many more that will also be discussed in this report. Among other model-based formal specification languages such as VDM++, LOTOS and others, Object-Z still excels higher because of its root on Z which is very popular in the formal methods industry and also because of its Object-Oriented features.
5.2
Syntactical constructs
There are two notable differences between the form of a Z specification and one in Object-Z. The first is the strict ordering and roles of schemas within the class definition. In Z, the order of whether the initial state schema appears before or after the operation schemas is irrelevant. In Object-Z, the role of each schema within the class and its order with respect to other schema is strictly defined. Here is an example of a UML class in Object-Z: [Classes]
11
A class in UML is a descriptor of a set of objects with common properties in terms of structure, behaviour, and relationship. A class has a name, attributes and operations. An attribute has a name, a visibility, a type, and a multiplicity. An operation has a name, a visibility and parameters. Each parameter of an operation has a name and a given type. Prior to formaliZing classes, a given set name is defined from which the names of all classes, attributes, operations, operation parameters, associations and roles are drawn. 1. Attributes The Object-Z class OZAttribute is a formal description of attributes. Each attribute has a name, a type, and a multiplicity constraining the number of values that the attribute may hold. It also has an attribute, relationship, to represent whether this attribute models a relationship between objects. Like UML, relationships between objects can be common reference relationships, shared or unshared containment relationships. Hence, the enumeration relationshipKind, can have its values as relNone, reference, sharedContainment, and unsharedContainment. relNone represents pure attributes of a class. The attribute navigability represents the direction of the relationship. Visibility in Object-Z can be public or private. OZAttribute name : Name type :↓ OZType visibility : VisibilityKind multiplicity : P1 N relationship : relationshipKind navigability : NavigabilityKind
The downarrow sysmbol attached to a type indicates that the type corresponds to its instances and instances of all its subtypes. RelationshipKind ::= relNone | reference | sharedContainment | unsharedContainment NavigabilityKind ::= navNone | bi | one 2. Semantics of attributes An attribute is a named slot within a class that describes a range of values that instances of the class can have 12
for the attribute. In a metamodel an attribute is associated with a set of AttributeLink , which is a named slot in an object holding the value of an attribute. Formal description of AttributeLink is as follows: AttributeLink attribute : OZAttribute value :↓ Instance The downarrow has the same meaning as described in class OZAttribute example above. 3. Semantics of types The semantics of a type is a set of instances of that type. The following is a formal description of an Instance. Instance type :↓ OZType
4. The semantics of classes In Object-Z, an object has a type that declares its structure and behaviour and it has a set of attribute values including object-identities of the other instances that it may reference. Inheritance in Object-Z does not imply instances of a subclass are also instances of its superclasses. Instead it has a notation ↓, which can be attached to a type to allow polymorphism for object types. This is in contrast with UML. An attribute with a down-arrow attached to the type can be defined as a PolyType. There are two functions namely descendents and allDescendents that return children of a class and all descendents of a class respectively. Other two functions are containedObjects and allContainedObjects that return objects directly or indirectly contained by an object respectively. OZType is a top level metaclass from which all possible types in Object-Z can be drawn. Classes are a kind of type in which case OZClass inherits from the OZType. All other types in Object-Z such as given types, cartesian types, schema types and so on [3], are abstracted as a metaclass called OtherTypes.
13
PolyType : P ↓ OZType; PolyType ⊆ OtherTypes; The following is a formal description of object: Object Instance c slot : P AttributeLink ° type ∈ OZClass {s : slot • s.attribute} = type.attributes ∀ a : type.attributes • #{s : slot | s.attribute = a} ∈ a.multiplicity ∀ s : slot • s.attribute.type ∈ PolyType ⇒ s.value ∈ {i : Instance | i .type ∈ {s.attribute.type} ∪allDescendents(s.attribute.type)} s.value ∈ Object ∧ s.attribute.navigability = bi ⇒ ∃ is : s.value.slot • is.value = self self 6∈ allContainedObject(self ) #{o : Object | (∃ s : o.slot | s.attribute.relationship • unsharedContainment ∧ s.value = self )} ≤ 1
The invariants defined in the predicate state that: • The circled c models a containment relationship. This means that each type has a name and contains a collection of its own features such as attributes and operations. • type is part of OZClass. • The attributes of slots must be equal to the attributes of the types. • The number of attribute links that map to an attribute should satisfy the multiplicity constraint given for that attribute. • If the type of the slot is a PolyType, the value of the slot corresponds to the instances of the type or subclasses of the type. • If an attribute slot of an object represents a bi-directional relationship, the referenced object should have a slot that has the referencing object as its value. This assures links between objects. 14
• When an object has a containment relationship with other objects, any circular or self containment should be prohibited. • For all objects, there can be only one composite object for them. The second difference is that Z has a principle that definition must come first before use, which does not hold for class operations which may be defined recursively and it does not hold also for variables whose values are object identities. In Object-Z, this is possible to allow flexibility when structuring specifications such as self and mutually recursive structure. A class definition in Object-Z captures the object-oriented notion of a class by encapsulating a single state schema with its initial state schema and all the operations which can affect its variables. Object-Z therefore not only uses object oriented notion but also makes it acceptable in the object-oriented world. For instance, classes in Object-Z can be used to specify entire systems or components of systems where the components of these systems are not classes themselves but objects of the classes. The following is an example of a simple multiplexer which comprises three components; two input queues and a single output queue of messages. The messages on the input queues are merged onto the output queue. The multiplexer is either idle, when both inputs are empty or busy, otherwise [12]. The multiplexer is also specified by a class. Other definitions are: the interface variable Status, the initial state schema, operations join1 and join2 modeling the joining of the message onto one and other input queues respectively and also Transfer modeling the transfer of a message from an input to the output queue and an operation leave modeling a message leaving the output queue. The type of messages and type of variable can be defined as thus: [Message] Status ::= idle | busy The multiplexer is then specified by the class Multiplexer as follows:
15
Multiplexer
¹(status, INIT , join1, join2, Transfer , Leave) input1, input2output : Queue[Message] source : Queue[Queue[Message]] δ status : Status input1 6= input2 ∧ input1 6= output ∧ input2 6= output status = idle ⇔ output.count = input1.count + input2.count INIT input1.INIT ∧ input2.INIT ∧ output.INIT ∧ source.INIT join1 = b input1.join join2 = b input2.join Leave1 = b input1.Leave ∧ source.join[input1/item?] Leave2 = b input2.Leave ∧ source.join[input2/item?] Transfer = b (Leave1 [] Leave2) k output.join Leave = b output.Leave ∧ source.Leave The delta δ symbol above divides variables into primary and secondary variables.
5.3
Inheritance
This is one of the key features of any object-oriented methodology or language. It is divided into two main categories namely: 1. Representational Inheritance. The composed structure, built from the enumeration of the instance variables of the object, forms a representation or state of the object. This representation is completely determined by the class definition in which case a type can be associated to each class definition representing the state. The definition of a subclass of an existing class introduces an extended type for the subclass. The type definitions may form a long chain of types, which are ’backwards’ assignment compatible in the direction of the root type. However, it is important to note that the extended type is not a subtype because it contains elements of different types than those of the basic type. In general, this representation inheritance scheme for a subclass implies inheritance of all
16
invariant expressions from superclasses. Representational inheritance is restricted to strictly single inheritance. 2. Functional Inheritance. Inheritance of methods in a strongly typed environment might lead to conflicts with the notion of typing. A good example of such a conflict is trying to add a vertex to a square without deforming the square. The addition of a vertex to a square does result in a polygon but different from the square. This can be avoided by introducing the notion of controlled inheritance which lets the user to specify the behavior without automatic coupling to the representational inheritance. This leads to multiple inheritance. Object-Z supports Inheritance. A class may be specified as specialization or extension of another class using inheritance . The inheriting class or subclass, implicitly includes all of the features of the inherited class, or superclass, and may also modify and add to these features. Z does not support subclass.
5.4
Concurrency
There are two reasons for constructing systems which show concurrent behavior: 1. Concurrency can be an important aspect of the world being modelled if the problem domain consists of co-existing elements that the model of the domain recognizes concurrently as active components. 2. Speeding up large computation may involve subdividing the computation into parts which can be computed concurrently thereby gaining time on a multi-processor machine. This can lead to highly parallel systems, with hundreds, or even thousands of executions of some basic algorithm executing simultaneously. In the real world concurrency is the norm. The world consists of collections of entities, people, machines, etc., which co-exist each of which may be pursuing its life and objectives, modifying its own state and the state of other objects in its environment, concurrently with others. The state of a world entity is represented in the model by its data variables; its laws of behavior are captured in the algorithms of the code. If the objects are active then 17
they must be concurrently active. If an object in the real world changes its state spontaneously, by its own actions, then in the computer model its algorithms should execute concurrently with those of other world objects, they will be concurrent processes. The Unified Modeling Language (UML) is capable of modeling a system that exhibits concurrency and with some extensions, it is also capable of modeling real-time systems. UML notations fall under two categories namely those dealing with static features and those dealing with dynamic features with the extension to deal with real-time features. Most model-based specification languages (i.e., Z, VDM) do not support concurrency. Traditionally, state-based specification languages such as Z, VDM and others have not been used for the specification of concurrent systems because they lack a means of conveniently specifying systems in terms of components. State-based specification languages are ideal for specifying top-level functionality and not the implementation level. However, Object-Z, LOTOS, CSP, RAISE, ESTELLE and VDM++ do support concurrency but differ in specification styles. While CSP (Communicating Sequential Processes) or CCS (Communication and Concurrency) are ideal for specifying the interactions between processes, they are not particularly suited to modelling complex data structures which may be needed to describe the processes themselves [11]. There have been attempts to integrate the semantics of specification languages to solve complex systems which exhibit incompatibilities with single formal specification language the results of which are just at experimental level. One example of such integration is found in Open Distributed Processing (ODP) which has adopted a viewpoint approach for the specification of distributed systems in which Z and LOTOS (Language Of Temporal Ordering Specification) have been proposed as languages for specifying particular views. Despite the fact that ODP utilizes the existing languages making it more accessible to many users who are already familiar with the languages, the approach produces a number of specifications which must be checked for consistency. Another problem in adopting such approach is that most state-based specification languages lack constructs identifiable with processes in a process algebra. Another example of proposed semantic integration is between CSP and Object-Z. However, Object-Z and CSP both support concurrency very well. A class in Object-Z is given a failure-divergence semantics identical to that of CSP process this is because of the close relationship between object-oriented and concurrent systems and in particular the notion of class corresponds closely to that of process. This correspondence allows classes defined in Object-Z part of the specification to be used directly in the CSP part [11]. Thus Object-Z is well suited to modelling concurrent systems which is essentially an implementa18
tion issue.
5.5
Refinement
In Refinement, implicit statements are normally refined to more explicit statements, converting the specification from what is required to how it will be carried out. Explicit specifications can be expressed in a number of styles namely state − based , declarative or in a mixture of both [7]. Refinement in CSP is defined in terms of failures and divergences. For instance, a process Q is a refinement of a process P if failures Q ⊆ failures P and Divergence ⊆ divergence P. Refinement in a state-based systems is based on the concept of simulations. There are two types of simulations namely: Downward simulation; P 2 is a downward simulation of P1 if there is a relation D ⊆ S 1 x S 2 such that: 1. ∀ σ1 ∈ S 1, σ2 ∈ S 2 • σ1 Dσ2 ⇒ nextp1( sigma1 ) = nextp2(σ2 ) 2. ∀ σ1 ∈ S 1, σ2 , σ2 ∈ S 2, e ∈ A • σ1 Dσ2 ∧ σ2 The upward simulation states thus: P2 is an upward simulation of P 1 if there is a relation ∪ ⊆ S 1 x S 2 such that: 1. ∀ σ2 ∈ S 2 • ∃ σ1 ∈ S 1 • σ1 ∪ σ2 ∧ nextp1(σ1 ) ⊆ nextp2(σ2 ) An Object-Z class C is downward simulation of the class A if there is a retrieve relation Abs such that every abstract operation AOp is recast into a concrete operation COp and the following hold. DS.1 ∀ Astate; Cstate • Abs ⇒ (PreAOp ⇔ PreCOp) DS.2 ∀ Astate; Cstate; Cstate 0 • Abs ∧ COp ⇒ ∃ Astate 0 • Abs 0 ∧ AOp DS.3 ∀ Cinit • ∃ Ainit • Abs The upward simulation can likewise be represented in Object-Z. The purpose of this exercise is to show the possibility of verification and thus provability. More proof will be presented in our research to show the difference between CSP and Object-Z as far as refinement is concerned and which one of the two is preferred and why though it has been found through research that Refinement is the Same as Simulation the proof of which is deferred to a later work.
6
Formalism conclusion
In Conclusion, Object-Z is the choice that maps well with most of the semantics of UML and other constructs and thus our work on formalization of the UML semantics and other constructs is based on the reasons summarized above. We have also found out that other formal methods such 19
as CSP, B-Method and others are good or probably the best for particular systems or applications whereas Object-Z’s application is wider than others.
7
UML Model Verification and Validation for embedded systems
In UML a Model is an abstraction of a system or subsystem from a particular perspective or view [1] and it is complete and consistent at the level of abstraction that has been chosen. Different views of a system can be presented in different models and a diagram is a graphical representation of a set of elements in the model of the system. The models developed change along three main dimensions: • Abstraction • Formality • Level of detail The Verification and Validation of a software system (models) is the generic term for checking processes which ensure that the software meets its requirements and that the requirements meet the need of the software procurer [16]. UML like any other modeling languages consists of semantic elements and syntactic elements. The set of all semantic elements of a model is referred to as the model. The fact that these semantics are semiformal makes whatever validation and verification to be almost impossible to achieve. The full range of primitives in UML is quite wide. UML diagrams can be created from a number of perspectives including conceptual , specification and implementation. Analysis in MDA is performed from the UML Conceptual perspective, and is expressed through the subset of UML, namely the Domain Model (consisting of the system, Domain and bridge), class Model (comprising the class, inheritance relationship, association, associative class), Scenario model (showing the pattern of communication between services and state models within a domain), the State Model (comprising the state, superstate/substate, event), and the Action Model (this is the detailed specification of a procedure- a state action or service action at the level of analysis). Both UML and MDA can reach the level expected in Software Engineering if the domain analysis is fully formalized. Despite the fact that MDA is well-suited for embedded software development because it separates functional logic from implementation details, it will be far from being a complete standard if UML semantics, on which it depends, will not 20
be formalized using proper formal methods. There are three kinds of rules about how the elements of UML can be combined as described below: 1. Abstract syntax Abstract syntax of UML is specified using the notation of the metamodel which is the subset of UML notation, using the UML class diagram to specify the elements of UML models and the relationships among them. For example Operation and Method are metaclasses and are both subclasses of the abstract metaclass BehaviouralFeature and that the Operation is a specification of a Method . 2. Well-formedness rules The well-formedness rules apply to instances of metaclasses (operations, methods, classes etc..). They provide rules that instances of the metaclasses must conform to as a set of invariants (constraints that cannot be broken: Must be true for the model to be meaningful). These rules are specified in Object Constraints Language (OCL) ). For example, the specification for the metaclass Class states that (if the class is concrete (not abstract), then every operation should have a method that realizes it). This constraint is expressed in OCL as thus: notself .isAbstractimpliesself .allOperations− > forAll (op | self .allMethods− > exists(m | mspecification− > includes(op))). These constraints on the metamodel are applied to check that the model conforms to the rules of UML and is well-formed. This expression is still a semi-formal expression that needs a lot of inputs to be provable. 3. UML Semantics Like the well-formedness rules, the semantics of UML are documented in English. A good example is the description of a metaclass Operation. Operation is a conceptual construct, while Method is the implementation construct. Their common features, such as having a signature, are expressed in the BehaviouralFeature metaclass, and the specific semantics of the Operation. The Method constructs are defined in the corresponding subclass of BehaviouralFeature. This kind of description needs to be formalized to be proved. Part of such formalization could start with the argument shown below: A class in UML is a descriptor of a set of objects with common properties in terms of structure, behaviour, and relationship [5]. A class has a name, attributes and operations. An attribute has a name, a visibility, a type and a multiplicity. An operation has a name, a visibility and parameters. Each parameter of an operation has a name and s given type. A set Name from 21
which all classes, attributes, operations, operation parameters, associations and roles are drawn is defined as thus: Name An Object-Z class UMLType is a meta type from which all possible types can be derived. Each type has a name and contains a collection of its own features namely attributes and operations as shown below: UMLType name : Name c attributes : F UMLAttribute ° c operations : F UMLOperation ° The circled c attached to the types attributes and operations models a containment relationship in Object-Z. The attributes and parameters are defined below. Multiplicity in UMLAttribute describes the possible number of data values for the attribute that may be held by an instance whereas visibility in UML can be private, public or protected: VisibilityKind ::= private | public | protected UMLAttribute
UMLParameter
name : Name type : ↓UMLType visibility : VisibilityKind multiplicity : P1 N
name : Name type : ↓UMLType
Within the operation, parameter names are unique as shown below: UMLOperation name : Name visibility : VisibilityKind c parameters : seq UMLParameter ° ∀ p1, p2 : ran parameters • p1.name = p2.name ⇒ p1 = p2
22
The Object-Z class UMLClass is defined below. Since a class is a type, it inherits from UMLType. Hence attribute names defined in a class are different and operations have different signatures: UMLClass UMLType ∀ a1, a2 : attributes • a1.name = a2.name ⇒ a1 = a2 ∀ op1, op2 : operations • (op1.name = op2.name ∧ #op1.parameters = #op2.parameters ∧ (∀ i : 1 . . #op1.parameters • op1.parameters(i ) = op1.parameters(i ) ∧ op2.parameters(i ) = op2.parameters(i )) ⇒ op1 = op2 we can then conclude that out of the three dimensions named above namely, abstraction, formality, and level of detail along which a model changes, if proper formality is missing, then even the level of detail will not be consistent with the abstraction. Emphasis is laid on the proper formal method for the model so that it can be verified and validated.
8
Current research work and conclusion
We are currently working on the formalization of UML semantics and notation (both static and dynamic) using Object-Z and thereby building up a formal tool using the existing open source tool called ArgoUML together with experimental model checking and theorem proving tools, namely SAL. Unfortunately none of the current model checking and theorem proving tools support Object-Z. We have started experimenting and integrating Object-Z with a friendly tool SAL (Symbolic Analysis Laboratory) for the purpose of model checking. These experiments involve translating UML models into SAL models and converting them via XML to Object-Z models and typechecking them. This work has just started and some reckonable results expected in September.
References [1] S. Bennett, S. McRobb, and R.Farmer. Object-Oriented Systems Analysis and Design Using UML, chapter 8, pages 58–96. Addison-Wesley, 1999. 23
[2] S. Bennett, J. Skelton, and K. Lunn. Schaum’s outlines UML, chapter 2, pages 6–23. McGraw-Hill, 2001. [3] R. Duke and G. Rose. Formal Object-Oriented Specification using Object-Z. Macmillan Press, 2000. [4] M. Fowler. Use cases. Addison-Wesley, 2004. [5] Object Management Group. OMG unified modelling language specification, version 1.3r2, 1999. [6] W3C H. Haas. Component-based software development. URL:http://www.W3.org/TR/ws-gloss/, February 2004. [7] A. Harry. Formal Methods VDM and Z, chapter 1, pages 1–7. John Wiley, 1996. [8] J. Lilius and I. Paltor. The Semantics of UML State Machines. Technical Report 273, Turku Centre for Computer Science, Finland, 1999. [9] Communications of the Association for Information Component-based development. URL:http://cais.isworld.org/articles/, JUNE 2002.
Systems.
[10] J. Schmuller. Introducing Use cases. Sams Publishing, 1999. [11] G. Smith. A semantic integration of object-z and csp. Alexander Von Humboldt-Stiftun, 1998. [12] G. Smith. Object-Z Specification Language, chapter 1, pages 1–25. Kluwer Academic Publishers, 2000. [13] G. Smith. The Object-Z specification language. Kluwer Academic Publisher, 2000. [14] G. Smith and R. Duke. Specifying concurrent systems using object-z. 15th Australian Computer Science Conference, 1992. [15] Pathfinder Solutions. Model-driven architecture MDA for embedded systems. URL:http://www.pathfindermda.com, APRIL 2004. [16] I. Sommerville. Software Validation. Addison-Wesley, 1992. [17] P. Stevens and R. Pooley. Addison-Wesley, 2000.
Using UML, chapter 5, pages 56–73.
24
[18] P. Stevens and R. Pooley. Using UML Software Engineering With Objects And Components, chapter 10, pages 131–137. Addison-Wesley, 2000. [19] J. B. WORDSWORTH. Software Design. Addison-Wesley, 1996.
25
