UNU/IIST International Institute for Software Technology
Integrating and Refining UML Models Zhiming Liu, Xiaoshan Li, Jing Liu and He Jifeng March 2004
UNU-IIST Report No. 295
R
UNU-IIST and UNU-IIST Reports UNU-IIST (United Nations University International Institute for Software Technology) is a Research and Training Centre of the United Nations University (UNU). It is based in Macau, and was founded in 1991. It started operations in July 1992. UNU-IIST is jointly funded by the Governor of Macau and the governments of the People’s Republic of China and Portugal through a contribution to the UNU Endownment Fund. As well as providing twothirds of the endownment fund, the Macau authorities also supply UNU-IIST with its office premises and furniture and subsidise fellow accommodation. The mission of UNU-IIST is to assist developing countries in the application and development of software technology. UNU-IIST contributes through its programmatic activities: 1. Advanced development projects, in which software techniques supported by tools are applied, 2. Research projects, in which new techniques for software development are investigated, 3. Curriculum development projects, in which courses of software technology for universities in developing countries are developed, 4. University development projects, which complement the curriculum development projects by aiming to strengthen all aspects of computer science teaching in universities in developing countries, 5. Schools and Courses, which typically teach advanced software development techniques, 6. Events, in which conferences and workshops are organised or supported by UNU-IIST, and 7. Dissemination, in which UNU-IIST regularly distributes to developing countries information on international progress of software technology. Fellows, who are young scientists and engineers from developing countries, are invited to actively participate in all these projects. By doing the projects they are trained. At present, the technical focus of UNU-IIST is on formal methods for software development. UNU-IIST is an internationally recognised center in the area of formal methods. However, no software technique is universally applicable. We are prepared to choose complementary techniques for our projects, if necessary. UNU-IIST produces a report series. Reports are either Research R , Technical T , Compendia C or Administrative A . They are records of UNU-IIST activities and research and development achievements. Many of the reports are also published in conference proceedings and journals. Please write to UNU-IIST at P.O. Box 3058, Macau or visit UNU-IIST’s home page: http://www.iist.unu.edu, if you would like to know more about UNU-IIST and its report series.
Chris George, Acting Director
UNU/IIST International Institute for Software Technology
P.O. Box 3058 Macau
Integrating and Refining UML Models Zhiming Liu, Xiaoshan Li, Jing Liu and He Jifeng
Abstract We use a formal object-oriented specification language (OOL) to formalize and combine some UML models. With the formalization, we develop a set of refinement laws of UML models that captures the essential nature, principles, nature and patterns of object-oriented design. With the support of the incremental and iterative features of object-orientation and the Rational Unified Process (RUP), our method supports precise and consistent UML model transformation. Keywords: Design patterns, model consistency, model integration, model refinement
Zhiming Liu is a Research Fellow at UNU/IIST, on leave from Department of Computer Science at the University of Leicester, Leicester, England where he is lecturer in computer science. His research interests include theory of computing systems, emphasising sound methods for specification, verification and refinement of fault-tolerant, real-time and concurrent systems, and formal techniques for OO development. His teaching interests are Communication and Concurrency, Concurrent and Distributed Programming, Internet Security, Software Engineering, Formal specification and Design of Computer Systems. E-mail:
[email protected]. Xiaoshan Li is an Associate Professor at the University of Macau. His research areas are interval temporal logic, formal specification and simulation of computer systems, formal methods in system design and implementation. E-mail:
[email protected]. Jing Liu is a Fellow of UNU-IIST from Shanghai University, China, where she is an Associate Professor. Her research areas include Software architecture, development processes and Application of formal methods in system development. E-mail:
[email protected]. He Jifeng is a Senior Research Fellow of UNU/IIST. He is also a professor of computer science at East China Normal University and Shanghai Jiao Tong University. His research interests include the Mathematical theory of programming and refinement methods, design techniques for the mixed software and hardware systems. E-mail:
[email protected].
c 2004 by UNU-IIST, Zhiming Liu, Xiaoshan Li, Jing Liu and He Jifeng Copyright
Contents
i
Contents 1 Introduction
1
2 The Theoretical Basics
3
3 An Overview of OOL 3.1 Variables and states of an object-oriented program 3.2 Object-oriented systems . . . . . . . . . . . . . . 3.3 Expressions . . . . . . . . . . . . . . . . . . . . 3.4 Class declarations . . . . . . . . . . . . . . . . . 3.5 Commands . . . . . . . . . . . . . . . . . . . . 3.5.1 Semantics of a class declaration . . . . . 3.5.2 Well-definedness of a declaration section 3.5.3 Semantics of a program . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 5 7 8 8 9 10 11 12
4 Formalization of UML Models 4.1 OOL specification of a class diagram . . . . . . . . . . . . . 4.2 OOL Specification of sequence diagrams and state machines 4.3 Model consistency . . . . . . . . . . . . . . . . . . . . . . 4.4 Requirement models and design models in UML . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
15 16 17 20 21
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 Model Refinement
22
6 Conclusion and Discussion
26
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Introduction
1
1 Introduction In a UML-based development process, such as the RUP [JBR99, Kru00], several kinds of UML models are used to represent and analysis the artifacts created in a certain phase of the system development: class diagrams for representing static analysis (static view), state machines for dynamic behavioral specification and validation (behavioral view), sequence diagrams and collaboration diagrams interactions between objects (interaction), OCL specifications functionalities and constraints of objects (functional view), etc . The UML multiview modelling has advantages. The modeler is allowed to split a model of a system to several views to decompose it in chunks of manageable sizes. Each single view focuses on a different aspect so that the analysis and understanding of the various features of the modelled system [AR03]. However, a multiview model is confronted with the following difficult and interrelated problems and the solutions to them are in the core of model driven development [MB02].
• Model consistency: Models of different viewpoints are required to be syntactically and semantically compatible with regards to the aspects of the systems which are described in the submodels [EKG02, AR03], • Model transformation and evolution: It is required that a refined a model must be semantically consistent with the one it refines – vertical consistency [EKG02, AR03], • Model traceability: A change in a model of one viewpoint leads to consistent changes in the other submodels. • Model integration: The production of the system needs to combine the viewpoints together.
Research on consistency and formal analysis of UML models (e.g. [Eva98, BPP99, ARRV00, Eng01, Egy01, HR00, Reg01]) has been active in recent years. However, the majority of them are only concerned with formalization of individual diagrams and consistency of models of one kind or two, such as the consistency of class diagrams or that of state machines. To our knowledge, there is very little work so far about how to systematically deal with refinement of UML models. Another phenomenon in research on formal use of UML is that different communities intend to emphasize different models and use the full or even extended power of, say sequence diagrams or state machines. This leads to the loss of the benefit of multiview modelling with the increase in the complexity of a certain kind of models and the reduction of the role that the other kinds of UML models can play. Nevertheless, many researchers, e.g. [EKG02, AR03], have realized that consistency problems are hard. The conditions and solutions for consistency depend on the diagrams involved, the development process employed, and the current stage of the development. The source of inconsistency are in fact the advantages that UML offers. The difficulties in defining consistent conditions and checking them are due to the reasons, among others, that UML does not have a precise semantics and there is relatively much less restrictions on the (informal) semantics and syntax compared to a formal modelling notation. There are too many optional features: the use of role names in classes diagrams and object names in sequence diagrams are all optional. For example, statecharts in theory can specify all semantic information of sequence diagrams (and activity diagrams) and vice versa. This situation does no harm if UML is only used
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Introduction
2
Catalog
Uses 1
1
Store 1
Logscompleted
name address
1
Has
1
* ProductSpecification descrisption price upc
*
Contains Describes 1
* LineItem
0..1 quantity
Sale date time Bool isComplete 1 1
IsPaidBy
Payment amount
Figure 1: A diagram for an automated checking out system in a shop in its sketchy mode, but not satisfactory for the modes of blueprint and programming language [Fow03]. Also different models describe overlapping aspects of a system. Some particular kinds of diagram have the power or potential to describe nearly all aspects of a system. A good project should restrict the roles of the diagrams to the viewpoints that they intend to represent to keep a “balance” among them in the whole model so as to keep the model cohesive. We propose for a development phase, the system is modelled by a tuple M = hΓ, ∆, Ω, Θi, called a system model, of a class diagram1 Γ, a family ∆ of sequence diagrams, a family Ω of state machines and a system constraint Θ. Some classes and associations in Γ may be conceptual while the others are design classes and associations. A conceptual class does not have methods and its attributes are all public. A conceptual class will be designed (or removed if found irrelevant to the requirements) to a design class by assigning it with methods to realize some responsibilities [Lar01] required at a level above in a later design, and by making some attributes private or protected for data encapsulation . A conceptual association has no direction of visibility or navigation. It will be refined to a design association by fixing its direction when one end of the association is designed to delegate functionalities to the other end. The development process starts from a model RM = hΓr , ∆r , Ωr , Θr i, called the (system) requirement model. Class diagram Γ contains all the domain classes and their associations are conceptual. Figure 1 shows an example of a conceptual class diagram for an automated checking out system used in retail shops [Lar01]. The sequence diagrams ∆r describe the interaction of the actors and the system to carry out the use cases, and state machines Ωr describe the behavior and functionality of the use cases. By behavior, we mean the change in control states, and functionality is about the change of data states. Such a model can be built by horizontal refinement to incrementally add more and more information and more use cases. A development cycle goes through a number of steps of vertical refinement to transform the requirement model into a (system) design model DM1 = hΓd1 , ∆d1 , Ωd1 , Θd1 i: RM1 ⊑ M1 ⊑, . . . , Mn ⊑ DM1
In the design class diagram, Γd1 only has design classes and associations. This is then followed by another iteration to add more requirements with use cases and conceptual classes and associations to evolve the system. Such an incremental and iterative development process is shown in Figure 2. As shown by the dashed arrows, the models in a later iteration (or version) are built based on the design model of its previous iteration and thus the RMi contains both conceptual and design classes and associations. In this article, we use the object-oriented specification language (OOL) defined in [HLL04] to give an integrated formalization of UML system models M and investigate how analysis and development of a 1
For simplicity, we do not consider UML packages.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
The Theoretical Basics
3
Iteration1
Iteration2
Iteration3
RM1
RM2
RM3
. . .
. . .
. . .
DM1
DM2
DM3
. . .
. . .
Figure 2: The development process system models can be supported the refinement calculus for object-oriented designs (RCOOD) [HLL04]. Refinement ensures that the change in a system model will preserve the consistency and the correctness of the system. Take the executable UML models and formalize them in OOL, we can also expect the approach to support model driven development [MB02] that has been a hot topic at UML conferences 2 . We present the theoretical basics in Section 2. We give an overview of OOL in Section 3. Section UML, shows with examples how a system model can be described in OOL with a definition of model consistency. We devote Section 5 to showing how a model is refined consistently. We will conclude the article in Section 6.
2 The Theoretical Basics Our work is based on Hoare and He’s Unifying Theories of Programming (UTP) [HH98], in which a program or a program command is identified as a design, which is represented by a pair (α, P ), where • α denotes the set of variables of the program. • P is a predicate of the form def p(x) ⊢ R(x, x′ ) = (ok ∧ p(x)) ⇒ (ok ′ ∧ R(x, x′ ))
where – we call α the alphabet of the design and P the contract of the design; α declares the variables (including logical ones) whose values form the state of the program at a moment of time, and the contract specifies the behavior of the program in terms of what change in state that its execution may cause. – x and x′ stand for the initial and final values of program variables x in α, – predicate p, called the precondition of the program, characterizes the initial states in which the activation of the program will lead its execution to termination, 2
There was a workshop and a panel at 2003.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
The Theoretical Basics
4
– predicate R, called the post-condition of the program, relates the initial states of the program to its final states, and – we describe the termination behavior of a program by the Boolean variables ok and ok ′ , where the former is true if the program is properly activated and the later becomes true if the execution of the program terminates successfully. Definition 1 For a given alphabet α and two contracts P1 and P2 , the sequential composition P1 ; P2 is defined as the relation composition def (P1 (x, x′ ); P2 (x, x′ )) = ∃m · P1 (x, m) ∧ P2 (m, x′ )
We also define the composite design (α, P1 ); (α, P2 ) by (α, P1 ; P2 ).
Within this model, the Hoare Triples and concept of refinement is defined as predicate implication. Definition 2 (Hoare triple) Let D = (α, P re ⊢ P ost) be a design and p and q predicates over variables in α. def {p}D{q} = ∀x, . . . , z · (p ⇒ P re ∧ ∀x′ , . . . , z ′ · (P ost ⇒ q ′ ))
where x, . . . , z are the free state variables in p, q and D, and q ′ is the predicate obtained from q by replacing every free program variable with its primed version. Definition 3 (Design refinement) Design D2 = (α, P2 ) is a refinement of design D1 = (α, P1 ), denoted by D1 ⊑ D2 , if P2 entails P1 , i.e. ∀x, x′ . . . , z, z ′ , ok, ok′ · (P2 ⇒ P1 )
where x, . . . , z are variables contained in α. D1 ≡ D2 if and only if D1 ⊑ D2 and D2 ⊑ D1 . Definition 4 (Data refinement) Let ρ be a mapping (that can also specified as a design) from α2 to α1 . Design D2 = (α2 , P2 ) is a refinement of design D1 = (α1 , P1 ) under ρ, denoted by D1 ⊑ρ D2 , if (ρ; P1 ) ⊑ (P2 ; ρ). In this case, ρ is called a refinement mapping. A program command usually modifies a subset of the program variables in α. Let V be a subset of α , the notation V : (p ⊢ R) denotes the (framed) design p ⊢ (R ∧ w′ = w), where w contains all variables in α but those in V . V is called the frame of the design p ⊢ R. In examples, we often omit the frames of
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
5
designs by assuming that a design only changes the value of a variable x if its primed version x′ occurs in the design. For simplicity, the above model adopts a universal data type and does not allow reference types. This assumption will not be applicable to modelling object-oriented designs anymore. In this paper, we still follow this classical way of defining a state-based model for a programming language to define our OOL in terms of alphabets, values, states, expressions, commands, declarations and programs. However, we needs to define the alphabet of an object-oriented design.
3 An Overview of OOL OOL is an object-oriented language with a rich variety of features including subtypes, reference types, visibility, inheritance, dynamic binding, polymorphism and local variable nested declarations. The language is designed for reasoning about object-oriented software at different levels of abstraction including specifications, designs and programs. We give an overview of the specification language and we refer the reader to [LHLL03] for a full account the syntax and semantics.
3.1
Variables and states of an object-oriented program
An object-oriented program in general consists of a number of classes and a main program or main method. Each class has a name C, a set of attributes attr(C) and a set of methods or operations op(C). An object o is a structure href, type, statei that has an identity ref , a type which is a class name and denoted by type(o), and a state which is a mapping from attr(type) to values. A value is either a member of a built-in primitive type or an object reference. We therefore assume an infinite set CN of class names, a set T of built-in primitive types, such as the Booleans Bool, the integers Int, etc., and an infinite set of REF of object identities or references. Our model describes the behavior of an OO program by a design containing the following logical variables as its free variables that form the alphabet of the program. 1. cname: its value is the set of classes which are declared so far, and it is modified by a class declaration. 2. Each class C ∈ cname is associated with (a) pria(C), proa(C) and puba(C): the sets of private, protected (declared or inherited) and public (declared and inherited) attributes of class C, each is of the form small {ha1 : T1 , d1 i, · · · , ham : Tm , dm i} where Ti and di are the type and initial value of attribute ai , and will be referred by decltype(C.ai ) and init(C.ai ) respectively. Let attr is the union of the three sets. We also abuse the notation a ∈ attr(C) and use it to denote ∃T, d · (ha : T, di ∈ attr(C))
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
6
Again, we do not allow attribute hiding (or redefinition) in a subclass. We also use an attribute name to represent its value and a type name to denote the set of its legal values. (b) op(C): the set of (declared and inherited) methods of class C. We allow method overriding, but not signature redefinition in a subclass. {m1 7→ (x1 : T 11 , y 1 : T 12 , z 1 : T 13 , D1 ), ···, mk 7→ (xk : T k1 , y k : T k2 , z k : T k3 , Dk )}
which states that each method mi has xi , y i and z i as its value, result and value-result parameters respectively, that are denoted by val(C.mi ), res(C.mi ), and valres(C.mi ), and the behavior of mi is defined by the design Di referred by Ψ(C.mi ) that will be defined in Section 3.8. When we are not interested in distinguishing the value, result and value-result parameters, we simply denote each element in op(C) as mi 7→ (parasi , Di ). We also sometimes abuse the notation m ∈ op(C) and use it to denote ∃paras, D · (m 7→ (paras, D) ∈ op(C))
The variables in (a) and (b) are modified by class declarations. (c) Σ(C): the set of objects of class C that currently exist in the execution of the program, and it will be updated through object creation or destruction. We let def Σ =
[
Σ(C)
C∈cname
These variables, {Σ(C) | C ∈ cname} are changed by the creation of a new object (and the destruction of an existing object or garbage collection that we do not consider in this article). We call Σ the system state of the program. It in fact corresponds to the current configuration of the program in [PdB03]. 3. superclass: the partial function mapping a class in cname to its direct superclass. This variable is also modified by a class declaration. 4. glb: the set of global variables with their types known to the program {x1 : T1 , . . . , xk : Tk }. The type Ti of xi , denoted by decltype(xi ), can be either a primitive type or a class name. We assume they are declared at the beginning of the main program and will not be changed afterwards. 5. locvar: its value is the set of local variables which are known to the current scope of the program. Since our language allows nested declaration, locvar associates each variable with a sequence of types {(x1 , hT11 , . . . , T1m i), · · · , (xn , hTn1 , . . . , Tnk i)}
where Ti1 , for i = 1, . . . , n is the most recently declared type of xi and denoted by decltype(xi ). We use var to denote locvar ∪ glb, and var(x) to denote the sequence of declared types of x (only its type if x ∈ glb). 6. visibleattr: its value is the set of attributes which are visible from inside the current class, i.e. all its declared attributes plus the protected attributes of its super classes and all public attributes. Every time before a method of an object is executed, this set is set to the attributes of the class of the object, and it will be reset after the execution of the method.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
7
7. x: this logical variable represents the state of variable x ∈ var. Since a local variable can be redeclared, its state usually comprises a nonempty finite sequence of values, whose first (head) element represents the current value of the variable. x for x ∈ glb contains at most one value. When there is no confusion, we use x to denote the head of x (i.e. the current value of x). A variable of a primitive data type can take any member of that type as its value. However, an object variable can store an object name or identity as its value. The current values of all variables in var include the information of the current local context in [PdB03] that is required to evaluate an expression in the execution of the program, but we allow global variables and redeclaration of a variables.
3.2
Object-oriented systems
In our model, an object system (or program) S is of the form cdecls • P , where cdecls is a declaration of a finite number of classes, and P is called the main method and is of the form (glb, c) consisting of a finite set glb of global variables with their types and a command c. P can be understood as the main method if S is taken as a Java program. We do not allow any direct access to class attributes in the main method P , thus except for manipulation of variables in glb, P can only call methods of classes in the declaration section. The semantics of a method call will be explained later. The other syntactic categories of OOL includes class declarations, class declaration sections, commands and expressions. We treat class declarations in the same way as commands and their semantics are to be defined as designs as in Hoare and He’s UTP [HH98] in terms of preconditions and postconditions. The semantics of OOL is fairly intuitive. One can informally understand the meaning of a program as the execution of its Java counterpart, once it is compiled correctly. However, it is important to note that the validity of an expression D(e) is defined and should be checked when it is evaluated. An expression e is valid only if the types and variables used in e are declared. The dynamic type type(e) of an expression is recorded during evaluation. The semantics of a command c is a design of the form D(c) ⇒ Spec
where D(c) defines the well-definedness of command c, Spec is a design as in UTP of the form: p(x) ⊢ R(x, x′ ). The semantics of c ensures that if c is not well-defined it will behave like chaos. For example, a method call o.m() is not well-formed if m is not a method of the class type(o), where type is the function that gives the dynamic type of an object. Thus, any correction of non-well-definedness will be a refinement. Though this idea sounds very simple, it is important for the refinement calculus to support incremental and iterative UML-like development.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
3.3
8
Expressions
Expressions in OOL, which can appear on the right hand sides of assignments, are constructed according to the rules below. e ::= x | null | self | e.a | f (e)
where null represents the special object of the special class NULL that is a subclass of all classes and has null as its unique object, self will be used to denote the active object in the current scope (some people use this), e.a is the a-attribute of e, (C)e is the type casting, e is C is the type test. An expression can be evaluated only when it is well-defined: • A simple variable x is well-defined if it is declared, i.e. in var, its type is either a primitive type or a class, if its type is primitive its value must be a member of that type, and if its type is a class its value must be an object of that class. • null is always well-defined and its type is Null. • self is well-defined if it is declared as a local variable and it has a type in cname. Its current value represents the currently active object. • An attribute le.a is well-defined if le is well-defined with a type in cname, a is a an attribute of the type of le. We can have more expressions, such as type testing and type casting, but they are not needed in this paper.
3.4
Class declarations
A declaration cdecls is of the form: cdecls := cdecl | cdecls; cdecl, where cdecl is a class declaration of the following form Class N extends M { private U1 u1 = a1 , . . . , Um um = am ; protected V1 v1 = b1 , . . . , Vn vn = bn ; public W1 w1 = d1 , . . . , Wk wk = dk ; method m1 (T 11 x1 , T 12 y 1 , T 13 z 1 ){c1 }; ···; mℓ (T ℓ1 xℓ , T ℓ2 y ℓ , T ℓ3 z ℓ ){cℓ } }
Note that
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
9
• N and M are distinct names of classes, and M is called the direct superclass of N. • The private declaration declares the private attributes of the class, their types and initial values, and similarly, the protected and public declarations for the protected and public attributes. • the method declaration declares the methods, their value parameters (T i1 xi ), result parameters (T i2 y i ), value-result parameters (T i3 zi ) and bodies (ci ). We sometimes denote a method by m(paras){c}, where paras is the list of parameters of m and c is the body command of m. • A method body ci is a command that will be defined later. We will use Java convention to write a class specification, and assume an attribute protected when it is not tagged with private or public. We have these different kinds of attributes to show how visibility issues can be dealt with. We can have different kind of methods too for a class. The above class declaration is well-defined if N has not been declared before, i.e. N 6∈ cname, the names of the attributes are distinct, the types of the initial values of the attributes match the types of the attributes, and the names of the parameters of each methods are distinct. If the declaration is welldefined, it then records (i.e. adds) the class name N in cname, and the direct sub-super class relationship with M in superclass, the methods in op and the attributes in pria(N ), proa(N ) and puba(N ).
3.5
Commands
Our language supports typical object-oriented programming constructs, but we also allow some commands for the purpose of specification and refinement: c ::=
skip | chaos | var T x=e | end x | c; c |cbc |c⊓c |b∗c | le.m(e, v, u) | le := e | C.new(x) | P |c ∨ c | c ∧ c | Q ⇒ c
termination abort local variable declaration local variable undeclaration sequence conditional choice nondeterministic choice iteration method call assignment Creating a new object design specification and logic operations
where b is a Boolean expression, e is an expression, P a design, Q a predicate, and le is an expression which may appear on the left hand side of an assignment and is of the form le ::= x | le.a where x is a simple variable and a an attribute name. Here, we use le.m(e, v, u) to denote a call of method m of the object denoted by the left-expression le with actual value parameters e for input to the method, actual result parameters v for the return values, and value-result parameters u that can be changed during
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
10
the execution of the method call and with their final values as return values too; and use the command C.new(x) to create a new object of class C with the default initial values of its attributes. Thus, C.new(x) uses x with type C to store the newly created object. We allow local variables to be redefined by using var x in its scope. Consequently, their states will usually comprise sequences of values. This is needed in object-orientation as a local variable, denoted by self, that denotes the current active object can be repeatedly declared in the execution of a method that calls other methods too. Most of the commands have their classic meanings in the imperative setting. We only explain the following commands which are typical to object-oriented programming. • An Assignment: le := e is well defined when le and e are well-defined and the type of e is a subtype of the declared type of le. In the case of a simple assignment x := e, when the assignment is well-formed it only modifies x by assigning it with the value of e which is an element of the type of e if the type is primitive or a reference if that type is a class. In the case of an modification of an object’s attribute, le.a := e changes the a-attribute of the object that le refers to the value of e. • A Method Call: A method call le.m(v, r, vr) is well-defined if le is non-null object and m(x, y, z) is a method declared in the type of le. When it is well-defined, its execution assigns the reference of the active object le to eslf, and the values of the actual parameters v and vr to the formal parameters x and z of m, and then executes the body of the method under the environment of class of the active object. After the execution of the body terminates, the values of the result and value-result parameters of m are passed back to the actual parameters r and vr. • An Object Creation: C.N ew(x) is well-defined if C is a declared class. Its execution creates a object of class C with a fresh reference, attaches it to variable x, and attaches the initial values of the attributes of class C to the attributes of x too.
3.5.1
Semantics of a class declaration
A class declaration cdecl given in Section 3.4 is well-defined if the following conditions hold. 1. N has not been declared before: N 6∈ cname. 2. N and M are distinct: N 6= M. 3. The attribute names in the class are distinct. 4. The method names in the class are distinct. 5. The parameters of every method are distinct.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
11
Let D(cdecl) denote the conjunction of the above conditions for the class declaration of cdecl. The class declaration cdecl adds the structural information of class N to the state of the following program, and this role is characterized by the following design. def cdecl = {cname, superclass, pria, prota, puba} : D(cdecl) ⊢ cname′ = cname ∪ {N} ∧ superclass′ = superclass ⊕ {N 7→ M} ∧ pria′ = pria ⊕ {N 7→ {hu : U , ai}} ∧ prota′ = prota ⊕ {N 7→ {hv : V , bi}} ∧ puba′ = puba ⊕ {N 7→ {hw : W , ci}} ∧ op′ = op ⊕ {N 7→ {(m1 7→ (paras , c1 )), 1 ······, (mℓ 7→ (parasℓ , cℓ ))}}
where the logical variables pria, prota and puba are introduced to record the declared attributes of N, from which the state attr can later be constructed. Similarly, the dynamic behavior of the methods cannot be defined before the dependency relation among classes is specified. At the moment, the logical variable op(N) binds each method mi to code ci rather than its definition which will be calculated in the end of the declaration section.
3.5.2
Well-definedness of a declaration section
A class declaration section cdecls comprises a sequence of class declarations. Its semantics is defined from the semantics of a single class declaration given in the previous subsection, and the semantics of sequential composition. However, the following well-definedness conditions need to be enforced onto a declaration section:
1. All class names used in the variable, attribute and parameter declarations are defined in the section: def _ D1 = T ∈ cname ∪ T x:T ∈S
where S denotes the set of variables, attributes, and parameters that occur in the declaration section: def S =
[
para(C) ∪ attr(C)) ∪ var
C∈cname
where para(C) is the set of all the parameters of the methods of C.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
12
2. The function superclass does not induce circularity: def D2 = superclass+ ∩ 1cname = ∅
where we abuse the notation by treating superclass as a binary relation, and define superclass+ as the transitive closure of superclass and 1cname is the identity relation over cname. 3. Any superclass of a declared class is declared too def D3 = ∀N, M · (N ∈ cname) ∧ (superclass(N ) = M ) ⇒ M ∈ cname
4. No attributes of a class can be redefined in its subclasses: def D4 =
∀N, M ∈ cname· ((N, M) ∈ superclass+ ⇒ attrname(N) ∩ attrname(M) = ∅)
where for a class C def attrname(C) = {a | ∃T, d · ha : T, di ∈ attr(C)}
5. No method is allowed to redefine its signature in its subclass: def D5 =
∀N, M ∈ cname, m ∈ dom(op(N)) ∩ dom(op(M))· (N, M) ∈ superclass+ ⇒ (π1 (op(N)(m)) = π1 (op(M)(m)) ∧ (π2 (op(N)(m)) = π2 (op(M)(m)) ∧ (π3 (op(N)(m)) = π3 (op(M)(m))
For the above example, we can “mechanically” calculate the semantics def declBST = declAccount; declCA; declSA; declBank
and check it is well-defined.
3.5.3
Semantics of a program
Let cdecls be a class declaration section and P main method of the form (glb, c), the meaning of a program (cdecls • P ) is defined as the composition of the meaning of class declarations cdecls (defined in Section 3.5), the design init, and the meaning of command P . However, the correctness of a a program
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
13
is only concerned with the initial values and final values of the global variables in glb. Therefore, we have to hide the internal variables in the definition of the semantics of a program. Let stateV be the set of variables listed in Section 3.3 except for those in glb. The semantics of a program is defined by def
cdecls • P = ∃stateV, ∃stateV ′ · (cdecls; init; c) where ∃setV for a set setVof variables is a short hand for applying ∃ to each of the variables in the set, and the design init performs the following tasks 1. to check the well-definedness of the declaration section, 2. to decide the values of attr and visibleattr from those of pria, prota and puba. 3. to define the meaning of every method body c, 4. to check the well-definedess of glb, i.e. its consistency with the class declarations: def D(glb) = ∀(x : T ) ∈ glb · (T ∈ T ∪ cname)
The design init is formalized as: def init = {visibleattr, attr, op} : D ∧ D2 ∧ D3 ∧ D4 ∧ D5 ∧[ D(glb) ⊢ 1 {N.a | a ∈ puba(N)} visibleattr′ = N∈cname ∧ ∀N ∈ cname · attr′ (N) = pria(N)∪ S {prota(M) ∪ puba(M) | N M} ∧ op′ (N) = {m 7→ (paras, Ψ(N.m)) | (m 7→ (paras, c)) ∈ op(M) ∧ N M}
where the family of designs Ψ(N.m) is defined in the rest of this section. The family of designs Ψ(N.m) captures the dynamic binding and is defined by a set of recursive equations, which contains for each class N ∈ cname, each class M such that N M, and every method m ∈ op(M) an equation Ψ(N.m) = FN.m (Ψ)
where supercalss(N) = M
where F is constructed according to the following cases.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
An Overview of OOL
14
(1) m is not defined in N , but in a superclass of N , i.e. m 6∈ op(N ) ∧ m ∈ ∪{op(M ) | N M }. Then a call to the method m in the environment of N will be executed according to the definition of m in the lowest superclass of N that declares the method. Let M be that lowest superclass of N , i.e. m is declared in M but no subclass of M declares m. The defining equation for FN.m (Ψ) in this case is def FN.m (Ψ) = Set(N ); φN (body(M.m)); Reset
(2) m is a method defined in class N. In this case, the behavior of the method N.m is captured by its body body(N.m) and the environment in which it is executed def FN.m (Ψ) = Set(N); φN (body(N.m)); Reset
where the design Set(N) finds out all attributes visible to class N in order for the invocation of method m of N to be executed properly, whereas Reset resets the environment to be the set of variables that are accessible to the main program only: def Set(N) = {visibleattr} : true ⊢ {N.a | a ∈ pria(N)}∪ S visibleattr′ = SNM {M.a | a ∈ prota(M)}∪ M∈cname {M.a | a ∈ puba(M)} def Reset =
{visibleattr} : S true ⊢ visibleattr′ = M∈cname {M.a | a ∈ puba(M)}
The function φN renames the attributes and methods of class N in the code body(N.m) by adding object
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
15
reference self that represents the active object of the method being currently invoked: def def φN (skip) = skip, φN (chaos) = chaos def φN (p1 ; p2 ) = φN (p1 ); Set(N); φN (p2 ) def φN (P1 b P2 ) = φN (P1 ) ⊳ φN (b) ⊲ φN (P2 ) def φN (P1 ⊓ P2 ) = φN (P1 ) ⊓ φN (P2 ) def φN (b ∗ P ) = φN (b) ∗ (φN (P ); Set(N)) def φN (var x : T = e) = var x : T = φN (e) def φN (end x) = end x def φN (C.new(x)) = C.new(φN (x)) def φN (le := e) = φN (le) := φN (e) def φN (le.m(v, r, vr)) = φN (le).m(φN (v, r, vr)) def φN (v, r, vr) = (φN (v), φN (r), φN (vr)) def φN (m(v, r,vr)) = self.m(φ S N (v), φN (r), φN (vr)) def self.x x ∈ NM attrname(M) φN (x) = x otherwise def def φN (self) = self, φN (le.a) = φN (le).a def def φN (null) = null, φN (f (e)) = f (φN (e))
Notice that we did not introduce the syntax super.m to explicitly indicate the call to a method according to its definition in the superclass. Instead the a method call will be executed according to the definition of method at the lowest position in the inheritance hierarchy. There is no difficulty to introduce super.m and define its semantics accordingly.
4 Formalization of UML Models In this section, we illustrate how to use OOL to specify a system model. Let M = hΓ, ∆, Ω, Θi be a system model. The class diagram Γ defines the system data state space and each state is a UML object diagram. Γ also provides signatures of the methods of its design classes. The system invariant Θ enforces constraints on the data state space. For the definition of consistency conditions, we require a role name at the “arrow” end of each directed (design) association in Γ, and each message in a sequence diagram of ∆ is prefixed with the role name at the end receiving class. This indicates the association link along which the message is passed (although we do not show this in our example diagrams).
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
4.1
16
OOL specification of a class diagram
A class diagram Γ is easily specified as a class declaration section, denoted as Spec(Γ) in the following way. • A class C in Γ is declared as a skeleton of class declaration in Spec(Γ) with their attributes and method signatures. • A conceptual association in Γ is also declared as as class with roles of the association as the attributes and the role classes as their types. • A generalization-specialization relation between two classes Ci and Cj in Γ is specified by Cj extends Ci . • For design association from Ci to Cj in Γ, if multiplicity of Cj in this association is 0..1 or 1, there is an attribute a in declaration cdecli of Ci that has a declared type Cj ; and if the multiplicity of Cj is more than 0..1, there is in cdecli an attribute a-set of type of the powerset PCj and an attribute a of type Cj . • Constraints, such as those appearing in comment boxes, multiplicities and aggregation, are specified in the system constraint Θ. OCL [WK99], as part of UML, can be used to specify constraints. However, rather than defining OCL as a subset of OOL, we use OOL alone for specifying both UML models and constraints.
Example 1 Here we specify the classes and associations of the conceptual class diagram in Figure 1. The others can be written in the same way. Class Store { public String name, String address }; Class Catalog { }; Class ProductSpecification { public String description, Price price, UPC upc }; Class Sale { public Date date, Time time, Bool isComplete }; Class LineItem { public Quantity quantity }; Class Payment { public Amount amount }; / ∗ ∗Association Classes Below ∗ ∗/ Class Contains { public Sale sale, LineItem lineitem }; Class Uses { public Store store, Catalog catalog }; Class Has { public Catalog catalog, ProductSpecification spec }; Class Describes { public ProductSpecification spec, LineItem li }; Class LogsCompleted { public Store store, Sale completedSale }; Class IsPaidBy { public Sale sale, Payment payment }
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
Store 1
17
1
address: Address name: Text
ProductSpecification
ProductCatalog
1 Uses
addSale()
description: Text price: Quantity upc: UPC
Has specification() loadProdSpecs()
1
1
1..*
1 Houses
Looks−in
1
Describes
* LineItem
Sale date: date time: Time isComplete: Boolean
BuyItems−Controller
Contains quantity: Integer 1
1..*
1 endSale() enterItem() makePayment()
subtotal()
Records 1
Logs−completed
1
1
becomeComplete() makeLineItem() makePayment() total()
IsPaid−by 1
Payment 1 amount: Quantity
*
Figure 3: A design class diagram for BuyItems use case A specification of design class Sale in Figure 3 is given as: Class Sale { private Date date, Time time, Bool isComplete, PLineItem li-set, LineItem li, Payment p; method makeLineItem(< ProductSpecification spec >, < >, < Amount total >), makePayment(< Amount amount >, < Amount balence >, < >), becomeComplete(), total() }
where attribute PLineItem lines models the one to many association Has from Slae to LineItem.
2
4.2
OOL Specification of sequence diagrams and state machines
State machines Ω specify the behavioral patterns of the objects of classes and the functionalities of method invocations. The sequence diagrams ∆ represent the pattern of interactions among objects of the classes in Γ. We restrict ourself to flat state machines [M. 03]. Each general state machine can be translated to a flat machine [DJPV03]. A state machine SC = (L, ℓ0 , ζ) for a class C consists of a set L of control locations (or states), an initial location ℓ0 ∈ L and a transition relation ζ ⊆ L × Label × L. A transition from a location ℓ to another ℓ′ is labelled with a triple t = hEvent, Action, Guardi ∈ Label, where Event, called a triggering event,is a
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
new
18
enterItem()
enterItem() isComplete endSale()
makePayment()
isComplete
Figure 4: A state machine for BuyItems method signature, Action is an OOL command and Guard is a predicate about the attributes of the class t and local variables in Action. We denote a transition by ℓ → ℓ′ . We do not consider concurrent systems in this article, all state machines (except for that of the main program which take the control of the execution of the program) are passive. Taking the UML run-tocomplete semantics of state machines, we assume there is no location in which a choice is allowed among transitions triggered by external invocations of methods and transitions caused by the object’s actions. This implies that the execution of an invoked method cannot be interrupted by external events. We also use sequential composition to collapse a sequence or a loop of non-externally triggered transitions. Therefore, each state transition t must have a triggering event, although the action part is optional. In the development of a system we can use UML models with different amount of details for different purposes, such as the three modes, i.e. the sketch mode, blueprint model and programming language model, of UML usage that Fowler discussed at 2003 [Fow03]. The state machine in Figure 4 for use case BuyItems of a check point system used in a retail shop only shows the triggering events and the changes of control states. Let loc be a state variable introduced as private attribute of the class t of the state machine. The change of control state by a transition ℓ → ℓ′ is specified in OOL as guarded design
def cs(t) = (loc = ℓ)⊤ ; (true ⊢ loc′ = ℓ′ )
where a guarded g ⊤ is defined as the conditional choice skipgfalse and we allow omit the precondition true in a design true ⊢ R. In general, for each triggering event m(), we can identify a set T (m()) of transitions that has m() as their triggering event. The behavior of the state machine, and hence the objects of the class, in reaction to the invocation of m(), can be specified by the method definition: m() {⊓t∈T (m()) cs(t) }.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
19
:BuyItems−Controler Cashier enterItem(upc, quantity) endSale( ) makePayment(amount)
Figure 5: The use-case sequence diagram for BuyItems Example 2 Figure 5(a) gives a sequence diagram for BuyItems use case. This use case is handled by a use-case controller class [LHLC03] shown in Figure 5(b). The state machine in Figure 4 for this class is specified in OOL as: where we use, say New for loc = new for a location BuyItems-Controller :: enterItem(){ (New⊤ ; (¬IsComplete′ ∧ ¬N ew′ )) ⊓ (¬N ew ∧ ¬IsComplete)⊤ } endSale(){ (¬New ∧ ¬IsComplete)⊤ ; IsComplete′ } makePayment(){IsComplete⊤ ; N ew′ }
2 t
A general transition ℓ → ℓ′ with an action and a guard in t is specified as: def Spec(t) = Guard⊤ ; (cs(t) k Action) def
where (p1 ⊢ R1 ) k (p2 ⊢ R2 ) = (p1 ∧ p2 ⊢ R1 ∧ R2 ). Such a compositional formalization supports the separation of concerns and helps us avoid making mistakes. Also, we can use simple state machines which do not have details of complex functionalities, and use OOL commands for specification of the functionalities. Let ti = hm(), Actioni , Guardi i, for i ∈ {1, . . . , k} be the transitions in a state machine of a class C triggered by event m(). They can be specified as a method definition:
C :: m() {Spec(t1 ) ⊓ . . . ⊓ Spec(tk ) ⊓ (¬(
k _
gi ) ⊢ chaos)}
i=1
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
20
where gi is the guard of ti , for i ∈ {1, . . . , k}. To be precise, we should also have a state CHAOS from which any event will trigger a transition to CHAOS itself. Also from any state, an enabled transition whose action Action equals chaos will change the state to CHAOS.
Example 3 We refine the methods defined in Example 2 for the simple state machine in Figure 4 by adding the definitions of the actions to fire after the invocation of the methods: enterItem() :: def act@new =
def act@¬isComplete =
∃spec ∈ Σ(ProductSpecification) · (spec.upc = upc) ⇒ W (Sale.New(x); ( spec.upc=upc (LineItem.New(li); (li.quantity := quantity)∧ (total := total + quantity × spec.price); Contains.New(y); (y.sale := x) ∧ (y.line := li)) ∃spec W ∈ Σ(ProductSpecification) · (spec.upc = upc) ⇒ ( spec.upc=upc (LineItem.New(li); (li.quantity := quantity)∧ (total := total + quantity × spec.price); Contains.New(y); (y.sale := x) ∧ (y.line := li))
def endSale() :: act@¬isComplete = skip / ∗ ∗This can be omitted
makePayment() :: act@isComplete
def = ∧
(Payment.New(p); p.amount := amount) (amount ≥ total ⇒ balance := amount − total)
where act@loc indicates which of the state change of the machine that this action is to be composed with. 2 A skeleton class declaration section and the method definitions can be easily merged to obtain an OOL class declaration section.
4.3
Model consistency
The submodels of a model M must be consistent such that the following conditions hold. 1. Any class name in ∆ must have a corresponding class in Γ.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Formalization of UML Models
21
2. If a.m() is a message to an object : C in a sequence diagram, then (a) class C in Γ is a design class with m() as a method, ai .mi ()
(b) Let follows(a.m()) = {: C → : Ci | mi before mi+1 , i = 0, . . . , k} be a set of messages going out of : C after : C receives a.m() but before the return of a.m(). Then ai .mi () must appear in an alternative of the body of m() in Spec(M), and the order in which these invocations are executed when method is called must agree with the order that are given in the sequence diagram. 3. If there is a state machine SC in Ω, there must be a class C in Γd . a.m()
4. For each message : C1 → : C2 in a sequence diagram of ∆, there must in Spec(M) be an attribute C2 a declared in C1 and method m() declared in class C2 . Notice that C2 could be a powerset type. This is true iff there is in Γ a design association from C1 to C2 with a role name a at the C2 end. 5. If there is a state machine SC for a class C, then every triggering event m() in SC must be fully defined by this machine, that is the method Wkdefinition C :: m(){c} in Spec(M) is obtained by C :: m(){Spec(t1 ) ⊓ . . . ⊓ Spec(tk ) ⊓ ¬(( i=1 gi ) ⊢ chaos)}, where ti , for i = 1, . . . , k are all the transitions in SC triggered by m(). 6. Spec(M) must be well-defined in OOL, and each command in a body of a method of a class is well-defined. 7. The constraint Θ of the model must be ensured by the method definitions. Notice that from condition 5, specifications of some methods in Γ are obtained by the OOL specification of the state machines, but we allow direct specifications of methods in OOL too. The consistency between ∆ and Γ is also implied by the above definition. Notice that from condition 5, specifications of some methods in Γ are obtained by the OOL specification of the state machines, but we allow direct specifications of methods in OOL too. The consistency between ∆ and Γ is also implied by the above definition.
4.4
Requirement models and design models in UML
As we said in the Introduction Section, a UML requirement model of a system consists of a (conceptual) class diagram , e.g. Figure 1, a family of use-case diagrams, a family of (system) sequence diagrams (one for each use case), e.g. Figure 5(a), a family state diagrams or state charts (one for each use case), e.g. Figure 4, and possibly some activity diagrams if concurrency . In this article, we do not consider activity diagrams. All the classes and associations are conceptual in the class diagram. Following the GRASP facade controller pattern [Lar01], we use a use-case controller class to document these operation, e.g. Figure 5(b) for use case BuyItems. We introduce a stereotype for this purpose. All the attribute and associations in the conceptual classes are directly visible to all the use-case controller classes. The use case diagrams provide the information about the design associations among the use-case controller classes. If use case U1 includes use case U2 in a use-case diagram, then there is an association from class U1 -Controller to U2 -Controller. Each system sequence diagram only describes the interaction between the actors and the system treated as a black box, e.g. Figure 5(a), and the interactions among some use-case controller classes showing how one use case includes another. Each sequence diagram identifies the system operations to be carried out when performing the use case. A state machine for a use case is the state machine for its use-case controller class. Therefore, a requirement model is a model RM = hΓ, ∆, Ω, Θi in which only the use-case controller classes are design classes and only associations involved in use-case controller classes are design associations, ∆ is a family of system sequence diagrams, one for each use-case controller, and Ω is a family of state machines, one for each use-case controller. The consistency of RM implies that the structure and dada modelled by conceptual class diagram support the realization of the use cases3 . A model M is a design model if all the classes and associations in its class diagram are design classes and design associations. class diagram in a design model is shown in Figure 6. A correct design model DM must refine the requirement model RM, i.e. RM ⊑ DM.
5 Model Refinement There are three interrelated kinds of refinement are involved in an object-oriented design: refinement between commands that is defined in Section 2, refinement between object-oriented systems, and refinement between declaration sections [HLL04]. Definition 5 Let S1 and S2 be object programs which have the same set of global variables glb. S1 is a 3
Not in the sense of computability, but in terms enough information about data and links.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Model Refinement
23
refinement S2 , denoted by S1 ⊒sys S2 , if its behavior is more controllable and predictable than that of S2 : ∀x, x′ , ok, ok′ · (S1 ⇒ S2 ) where x are the variables in glb
This means the external behavior of S1 , that is, the pairs of pre-global and post-global states, is a subset of that of S2 . To prove one program S1 refines another S2 , we require that they have the same set of global variables and there exists a refinement mapping from the variables of S1 to those of S2 that is identical on global variables [HLL04].
Definition 6 Let cdecls1 and cdecls2 be two declaration sections. cdecls1 is a refinement of cdecls2 , denoted by cdecls1 ⊒class cdecls2 , if the former can replace the latter in any object system to give a refinement of that system: def cdecls1 ⊒class cdecls2 = ∀P · (cdecls1 • P ⊒sys cdecls2 • P )
where P stands for a main method (glb, c).
Intuitively, it states that cdecls1 supports at least the same set of services as cdecls2 . The main method corresponds to the application program using the services (i.e. methods of the classes in the UML model). Thus, in this article, we are only interested in refinement between declaration sections. We allow the following refinements to a declaration section. 1. Adding a class declaration: this corresponds to adding a class into the class diagram, sequence diagrams and state machines of the methods of the new class. 2. Introducing a fresh private attribute to a class: This corresponds to adding a fresh attribute of a primitive type to the class or adding a directed association from the class to another in the class diagram. 3. Promoting a private attribute of a class to a protected attribute, and a protected attribute to a public attribute. 4. Adding a fresh method into a class: this allows us to add a method signature into the class in the class diagram, and add a sequence diagram, modify the state machine to incorporate this method. The newly added methods must not violate any state constraint required by the model. 5. Refining the body command of a method m(){c} in a class: this leads to the replacement of the subsequence diagrams corresponding to the occurrences of m(), and refine the actions of transitions with m() as the triggering event in the state machine of the class.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Model Refinement
24
6. Introducing inheritance: If none of the attribute of class N is defined in class M or any superclass of M , we can make M a direct superclass of N . 7. Moving some attributes from a class to its direct superclass. 8. Introducing a fresh superclass to a class: If M is not in the class declaration, we can introduce M and make it a superclass of an existing class N. 9. Moving common attributes of classes which are direct subclasses of a class to the superclass. 10. Moving a method from a class to its direct superclass. 11. Copying (NOT removing) a method of a class to its direct subclass. 12. Removing unused attributes: for a private attribute, it can be removed if it does not appear in any method of the class; for a protected attribute, it can be removed if it does not appear in any method of the class or any of its subclasses; for a public attribute, it can be removed if it does not appear in any method. This is because the main method does not access attributes directly. Refinement will also allow the remove of inheritance, but this understandably needs to change (or fix) in the interface with the main method. In addition to those simple refinement rules above, we also have interesting refinement rules to capture object-oriented design patterns. In an object-oriented design, the often used design technique is the General Responsibility Assignment Software Patterns (GRASP) [Lar01]. In fact, among them, we have already used the facade controller in a requirement specification. Another of them, possibly the most important one, is the expert pattern which shows how a class can delegate part of the functionality to another class. Pattern 1 (Expert) If a method of a class contains a subcommand that can be realized by a method of another class, we can replace that subcommand with a method invocation to the of the latter class. This law is shown in Figure 7. N o: M n{c[c (o.x)]} 1
M x m{c1 (x)}
N o:M n{c[o.m]}
M x m{c1 (x)}
Figure 7: Expert Pattern
Notice that the sequence diagrams and state machines involving N :: m() can be refined too, but we do not show them here because of the space limit. The Low Coupling Pattern of GRASP allows us to remove associations to keep the classes loosely coupled for ease of reuse and maintenance.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Model Refinement
25
M1
M2
o2
M1 m1{c[o2.m2()]
m1{c[o1.m3()]
M2
o2
m2{o3.m3()}
o3
o3
M3
M3
m3()
m3()
o1
.
o: M1 o.o2.o3=o.o1
Figure 8: Low Coupling Pattern Pattern 2 (Low Coupling) A call from one class to a method of another can be realized via a third class that is associated with these two classes. This is shown in Figure 8.
The High Cohesion Pattern gives the principle of decomposing a complex class into a number of related classes to keep the classes simple for ease of reuse and maintenance.
Pattern 3 (High Cohesion) Assume there in a class M are two methods m1 () and m2 () such that m1 does not depend on m2 (though m2 () may call m1 ()), we can decompose the class into three associated classes so that the original class M only delegates the functionalities to the newly introduced classes. There are two ways of doing this as shown in Figure 9. M M
x y
m 1 {o 1. .m 1 }
m 1{c 1 (x)} m 2 {c 2 [m 1 ]}
m 2 {o 2. .m 2 }
M
M
x y o : M . (o . o1 = o . o2 . o1 )
m 1 {o 1. .m 1 }
m 1{c 1 (x)} m 2 {c 2 [m 1 ]}
m 2 {o 2. .m 2 } o
o M1
o M2 y M 1 o1
1
x m 1 {c 1 (x)}
m 2 {c2 . [o 1 . m1 ] }
(a)
2
M2
2
o
y m 1{o1 . m 1 } m 2 { c2 [o 1 . m 1] }
1
M1 x m 1 {c 1 (x)}
(b) Figure 9: High Cohesion pattern
Notice that case (a) in Pattern 3 requires M to be coupled with both M1 and M2 ; and in case (b) M is only coupled with M2 , but needs more interactions between M2 and M1 . The other design patterns in [Gam95], such as Adaptor Pattern, Observer Pattern, Strategy Pattern and Abstract Factory Pattern can also be formalized.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
Conclusion and Discussion
26
Example 4 The conceptual class diagram in Figure 1, the state machine in Figure 4 and the sequence diagram together with the BuyItems-Controller class in Figures 5 form a requirement model. The OOL specification is a combination of the parts given in Example 1, Example 2 and Example 3. We can apply the refinement calculus to this requirement model for the design of the operation enterItem() to obtain the design class diagram in Figure 3 and the sequence diagram in Figure 6 step by step: 1. by Expert Pattern, the use-case controller class delegates the responsibility of creating a new sale to Sale class, 2. the use-case controller delegates the job of finding the specification using upc matching to Catalog, which delegates the job further to the multi-object ProductSpecification, 3. the use case controller delegates the task of making a line item to Sale. Each of the methods in the sequence diagrams can be further modelled by state machines of the design classes in Figure 3 or by direct OOL specification. Notice that different designs are possible for the requirement model. For example, BuyItems-Controller could directly invoke the constructor of LineItem to make a line item and then send a message to Sale to add the line item to the multi-object of LineItem. However, this would require to directly couple the use-case controller with LineItem. We have thus used the Low Coupling Pattern to avoid this.
6 Conclusion and Discussion This work is towards a formal foundation for component and object systems development. A normal form specification of an object system in OOL is a combination of a sequence of class declarations. These different parts for attributes, method signatures and method body definitions have counter parts in UML models. This enables us to convert the complex consistency problem of UML models [AR03] to the well-formedness conditions and the semantics of OOL specifications. With the development process and restrictions on the use of UML models, such as the restricted form of state machines and the use of role names in class diagrams and sequence diagrams, the definition and check of consistency conditions and identification of inconsistencies become clearer. These restrictions imply our suggestion that one can apply the sketchy model of UML usage [Fow03], such as sketchy state diagrams and sketchy sequence diagrams for operations or even parts of operations, in the process of creating a normal specification of a development phase, but these final model of that phase has to conform to the restrictions. The stepwise refinement of UML models within the development process supports to the maintenance of consistency during model transformation and evolution. This has taken the initiative of developing UML as a formal modelling language proposed in [Eva98] an essential step forward. It also provides fundamental support to UML based model driven development [MB02, Fow03].
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
References
27
With a fixed interface, i.e. a set of methods of some classes, to the environment of the system, the refinement rules in Section 5 are reversible and we believe a design model can be reversed back to a requirement model. However, this needs further investigation. Future work also includes the integration of activity diagrams into this framework for dealing with concurrency, and the extension of OOL with the notation of components to deal with component diagrams of UML2.0. We have also started to investigate tool development based on this framework [LLH04]. Regarding our related work, article [LLH02] uses general transition systems to provide a integrated model of conceptual class diagrams and use cases, but without a specification notation and the treatment of sequence diagrams, state machines and use case diagrams. A version of OOL without reference types is presented in [HLL02] and its is used in [LHLC03] for the specification of the integrated model of [LLH02]. Article [LLHL04] uses OOL for the specification of design class diagrams and sequence diagrams, but without rules for model transformation. Acknowledgement We would like to thank our colleagues Chris George and Dang Van Hung for reading and commenting on earlier versions of the article. We also thank Dines Bjørner at Technical University of Denmark, Anders Ravn from Aalborg University of Denmark and Uday Reddy from Birmingham University for their helpful comments. UNU-IIST fellows Quan Long, Bhim Upadhyaya and Jing Yang also read and gave useful comments on earlier versions of the article. The first author would also like to thank the students at the University of Leicester and those participants of the UNU-IIST training schools and courses who took his course on Software Engineering and System Development for their feedback on the understanding of the use-case driven, incremental and iterative object-oriented development and the design patterns.
References [AR03]
E. Astesiano and G. Reggio. In Proc. WADT 2002, LNCS 2755. Springer Verlag, 2003.
[ARRV00] P. Andre, A. Romanczuk, J.-C. Royer, and A. Vasconcelos. Checking the consistency of UML class diagrams using Larch Prover. In Proc. ROOM’2000, York, UK, 2000. [BPP99] R.J.R. Back, L. Petre, and I.P. Paltor. Formalizing UML use cases in the refinement calculus. In Proc. UML’99. Springer-Verlag, 1999. [DJPV03] W. Damm, B. Josko, A. Pnueli, and A. Votintseva. Understanding UML: a formal semantics of concurrent and communication in real-time UML. In F.S. de Boer, M. Bonsangue, S. Graf, and W.-P. de Roever, editors, Formal Methods for Components and Objects, Lecture Notes in Computer Science 2852. Springer, 2003. [Egy01] A. Egyed. Scalable consistency checking between diagrams: The Viewintegra approach. In Proc. 16th IEEE ASE, San Diego, USA, 2001. [EKG02] G. Engels, J.M. Kuester, and L. Groenewegen. Consistent interaction of software components. In Pro. of IDPT2002, 2002.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
References
28
[Eng01] G. Engels, et al. A methodology for specifying and analyzing consistency of object-oriented behavioral models. In The Proc. FSE-10, Austria, 2001. [Eva98] A. Evans, et al. Developing the UML as a formal modelling notation. In Proc. UML’98, LNCS 1618. Springer-Verlag, 1998. [Fow03] M. Fowler. What is the point of UML. In P. Srevens, J. Whittle, and G. Booch, editors, 2003 -The Unified Modeling Language, 6th International Conference, LNCS 2863, San Fancisco, CA, USA, 2003. Springer. [Gam95] E. Gamma, et al. Design Patterns. Addison-Wesley, 1995. [HH98]
C.A.R. Hoare and J. He. Unifying Theories of Programming. Prentice-Hall, 1998.
[HLL02] J. He, Z. Liu, and X. Li. Towards a refinement calculus for object-oriented systems (invited talk). In Proc. ICCI02, Alberta, Canada. IEEE Computer Society, 2002. [HLL04] J. He, Z. Liu, and X. Li. A predicative calculus for object-oriented system development. UNU-IIST, P.O. Box 3058, Macao SAR, China. Submitted for publication, 2004. [HR00]
D. Harel and B. Rumpe. Modeling languages: Syntax, semantics and all that stuff - part I: The basic stuff. Technical Report MCS00-16, The Weizmann Institute of Science, Israel, September 2000.
[JBR99] I. Jacobson, G. Booch, and J. Rumbaugh. Addison-Wesley, 1999.
The Unified Software Development Process.
[Kru00] P. Kruchten. The Rational Unified Process – An Introduction. Addison-Wesly, 2000. [Lar01]
C. Larman. Applying UML and Patterns. Prentice-Hall International, 2001.
[LHLC03] Z. Liu, J. He, X. Li, and Y. Chen. A relational model for formal requirements analysis in UML. In J.S. Dong and J. Woodcock, editors, Formal Methods and Software Engineering, ICFEM03, LNCS 2885, pages 641–664. Springer, 2003. [LHLL03] Z. Liu, J. He, X. Li, and J. Liu. Unifying views of UML. Research Report 288, UNU/IIST, P.O. Box 3058, Macao, 2003. Presented at UML03 Workshop on Compostional Verification of UML and To Appear in the Final Proceedings in the ENTCS. [LLH02] Z. Liu, X. Li, and J. He. Using transition systems to unify uml models. Technical report, Dept. of Maths and Computer Science, the University of Leicester, England., May 2002. [LLH04] X. Li, Z. Liu, and J. He. Generating a prototype from UML model of system requirements. UNU-IIST, P.O. Box 3058 Macao SAR, China. Submitted for publication, 2004. [LLHL04] J. Liu, Z. Liu, J. He, and X. Li. Linking UML models of design and requirement. In Pro. ASWEC’2004, Melbourne, Australia, 2004. IEEE Computer Sciety. [M. 03]
M. Kyas et al. Formalization UML models and OCL constraints in PVS. Eletronic Notes of Theoretical Computer Science, 2003.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
References
29
[MB02] S.J. Mellor and M.J. Balcer. Executable UML: a foundation for model-driven architecture. Addison-Wesley, 2002. [PdB03] C. Pierik and F.S. de Boer. A syntax-directed hoare logic for object-oriented programming concepts. Technical Report UU-CS-2003-010, Institute of Information and Computing Science, Utrecht University, 2003. [Reg01] G. Reggio, et al. Towards a rigorous semantics of UML supporting its multiview approach. In H. Hussmann, editor, Proc. FASE 2001, LNCS 2029. Springer, 2001. [WK99] J. Warmer and A. Kleppe. The Object Constraint Language: precise modeling with UML. Addison-Wesley, 1999.
Report No. 295, March 2004
UNU-IIST, P.O. Box 3058, Macau
