Transcript A Formal Descriptive Semantics of UML and Its Applications

A Formal Descriptive
Semantics of UML
Lijun Shan
Dept of Computer Science
National University of Defense Technology,
Changsha, China
Hong Zhu
Department of Computing and Electronics
Oxford Brookes University,
Oxford, UK
Outline
 What
is descriptive semantics?
 The
 How
concept and motivation
to specify descriptive semantics?
 The
formal framework
 Mappings from diagrams to first order logic (FOPL)
 Application to UML class, interaction and state
machine diagrams
 Application
of descriptive semantics to
consistency checking of UML models
 Conclusion
What is the meaning of UML diagrams?

The system has two classes called
Member
Member and Book,
0..1
(There are two types of objects called
Borrow
member and book)
0..10
 There is an association between them,
which is called Borrow
Book
(Members can borrow books)
Library system
 The upper limit of borrowing is 10
(Each member can only borrow up to 10
books at any time)
Instances of
the class Book
 The upper limit for a book to be borrowed
is 1
(Each book can only be borrowed by atInstances of the
class Member
most 1 member at any time)
Semantics of modelling languages
 ‘A model
is a set of statements about some
system under study’ [Seidwitz, 2003]
Software model, and models
in all scientific disciplines
 The
semantics of a modelling language is the
satisfaction relationship |= between a model and
A well-formed model
a system.
A system in the subject
domain D, i.e. universe
of systems that the
language is modelling.
s |= m
in the modelling
language.
s is an instance of the
model m, i.e. s satisfies the
statements of the model m
Two types of semantics


Descriptive semantics
Describe the system based on
a set of basic concepts, such
as class, association
multiplicity upper bound, etc.
Example:



The system has two classes
called Member and Book


Functional semantics
Define how the system
functions at run time.
Example:

There are two types of objects
called members and books.
Class(Member), Class(Book),
Asssociation(Borrows), …
Existing work on UML semantics often occurs as a
combination of them. They are at ‘object level’.
Example:
x.(Member(x) ||{y | Book(y)  Borrows(x,y)}||  10)
Difficulties in the formalisation of UML

Interpretation in different subject domains:

One model can be interpreted in several different subject
domains
 Library system model:
• When interpreted on the subject domain of real world systems,
the library of Oxford Brookes University is an instance
• When interpreted on the computer software, …

Extension with new concepts:


New basic concepts and constructs can be introduced through
extension facilities, such as introduce new stereo types in
profile definitions
Uses in different context:

One model may have different meanings in different context
Example:

Which of the following programs is the
correct semantics of the model on the right?



There are exactly three different classes such that
…;
There are at least three different classes such that
…;
Member
Staff
Student
Which of the following programs can be
considered as satisfying the model?
class Member
{…}
class Staff extends Member
{…}
Class Student extends Member
{…}
class MScStudent extends Student
{…}
class Member {
public enum MemberType {
Staff, Student }
public MemberType
TypeOfMember;
…
}
UML gives no definition on
this issue!
Overview of our approach
This is consistent with the theory of institution proposed by Goguen
and Burstall (1992) for formal specification languages.
The formal framework
Definition 1. (Semantics of a modelling language)
A formal semantic definition of a modelling language consists of
the following elements.
 A signature Sig, which defines a formal logic system;
 A set AxmD of axioms about the descriptive semantics, which is
in the formal logic system defined by Sig;
 A set AxmF of axioms about the functional semantics, which is
also in the formal logic systems defined by Sig;
 A mapping T from models to a set of formulas in the formal
logic system defined by Sig. The formulas are the statements for
the descriptive semantics of the model;
 A mapping H from models to a set of formulas in the formal
logic system defined by Sig. The formulas represent the
hypothesis about the context in which the descriptive semantics
is interpreted.
Definition 2. (Semantics of a model)
Given a semantics definition of a modelling language
as in Definition 1, the semantics of a model M under the
hypothesis H, written SemH(M), is defined as follows.
SemH(M) = AxmD AxmF T(M)  H(M)
where T(M) and H(M) are the sets of statements obtained
by applying the semantic mappings T and H to model M,
respectively. The descriptive semantics of a model M
under the hypothesis H, written DesSemH(M), is defined
as follows.
DesSemH(M) = AxmD T(M) H (M)
Satisfaction relation
Definition 4. (Subject domain)
A subject domain Dom of signature Sig with an interpretation Eva
is a triple <D, Sig, Eva>, where D is a collection of systems on
which the formulas of the logic system defined by Sig can be
evaluated according to a specific evaluation rule Eva. The value of
a formula f evaluated according to the rule Eva in the context of
system sD, written as Eva(f, s), is called the interpretation of the
formula f in s. We write s|=Evaf, if a formula f is evaluated to true in
a system sD, i.e. s|=Evaf iff Eva(f, s)= true. 
Definition 5. (Satisfaction of a model)
Let Sig be a given signature and Dom a subject domain of Sig. A
system s in D satisfies a model M according to a semantic definition
SemH(M) if s|= SemH(M), i.e. for all formulas f in SemH(M), s|=f. 
Signature Mapping
The signature mapping S from a metamodel M to a signature 
= S (M) is defined by a set of signature rules so that statements
representing the descriptive semantics of models are  -sentences of
first order predicates.
Signature Rules
S1. For each metaclass named MC in the metamodel, we define a
unary atomic predicate MC(x).
S2. For each metaassociation from a metaclass X to a metaclass Y
in a metamodel, if MA is the association end on the Y side of the
metaassociation, a binary predicates MA(x, y) is defined.
S3. For each metaattribute named MAttr of type MT in a metaclass
MC in a metamodel, a unary function MAttr(x) is defined with
domain MC and range MT.
S4. For each enumeration value EV given in an enumeration
metaclass ME in a metamodel, a constant EV is defined.
A Simplified Metamodel of Class Diagram
TypedElement
ValueSpecification
+lowerValue
Relationship
NamedElement
+upperValue
Feature
MultiplicityElement
Type
+isStatic: Boolean
+type
DirectedRelationship
+general
StructuralFeature
Parameter
Classifier
BehaviouralFeature
+isAbstract: Boolean +specific
+ownedParameter
+direction: ParameterDirectionKind
Property
Operation
*
0..1
+aggregation: AggregationKind
*
+ownedOperation
+ownedAttribute
2..*
+ownedAttribute
+memberEnd
<<enumeration>>
ParameterDirectionKind
+in
+out
+inout
+return
<<enumeration>>
AggregationKind
+none
+shared
+composite
DataType
+ownedOperation
+associateTo
Generalisation
Class
Interface
Association
Signal
0..1
<<enumeration>>
VisibilityKind
<<enumeration>>
Boolean
+t
+f
+public
+private
+protected
+package
Example:
+general
Metamodel
Classifier
Class
Generalisation
+specific
 Signature
elements:
 unaryWoman
predicates
:
 Class(x),
 Classifier(x),
 Generalisation(x)
 binary
predicates:
 general(x, y)
 specific(x, y)
Person
Translation mapping
Translation mapping is defined by a set of translation rules that
generate formulas in the signature from a UML model M.
Translation Rules
T1: Classification of elements.
For each identifier id of concrete type MC, a formula in the form of
MC(id) is generated.
T2: Properties of elements.
For each element a in the model and every applicable function
MAttr that represents a metaattribute MAttr, a formula in the form
of MAttr(a)=v is generated, where v is a’s value on the property.
T3: Relationships between elements.
For each pair (e1, e2) of elements related by relationship R, a
formula in the form of R(e1, e2) is generated to specify the
relationship by applying binary predicate R(x1, x2).
Example:
+general
Metamodel
Classifier
Class
Generalisation
+specific
Model
Woman

Person
Signature elements:

unary predicates : Class(x), Classifier(x), Generalisation(x)
 binary predicates general(x, y) and specific(x, y)

Statements of the model:


Class(Woman), Class(Person), Generalisation(wp)
specific(wp, Woman), general(wp, Person)
Interpretation in different contexts


The context in which a model is interpreted can be specified as
hypothesis.
A hypothesis can be defined as a rule that maps from a model to
formulas in the signature.
Hypothesis Rules
H1: Distinguishability of elements.
A hypothesis that the elements of type MC in the model are all different from
each other can be generated as formulas in the form of ei ej, for ij {1,2,…,k}.
H2: Completeness of elements.
A hypothesis on the completeness of elements of type MC can be generated as
a formula in the following form.
x. MC(x) -> (x = e1)  (x = e2)  …  (x = ek)
H3: Completeness of relations.
A hypothesis on the completeness of relation R in the model can be generated
as a formula in the following form.
x1,x2.R(x1,x2)->((x1=e1,1)(x2=e1,2))((x1= e2,1) (x2= e2,2))
… ((x1= en,1) (x2= en,2))
Axiom mapping
It is defined by a set of rules that maps metamodel to sentences as axioms of the models. These rules represents the
semantics of OO concepts applied to meta-modelling.
Axiom rules:
A1: Completeness of classification.
Let MC1, MC2, …, MCn be the set of concrete metaclasses in a
metamodel. We have an axiom x. MC1(x)  MC2(x) …  MCn(x)
A2: Disjointness of classification.
Let MC1, MC2, …, MCn be the set of concrete metaclasses in a
metamodel. For each pair of different concrete metaclasses MCi
and MCj, ij, we have an axiom x. MCi(x)  ¬ MCj(x).
A3: Logical implication of inheritance.
For a generalisation relation from metaclass MA to MB in a
metamodel, we have an axiom x. MA(x)  MB(x).
Strict metamodelling principle

Axiom rules also contain ‘hypothesis’ on the uses of class
diagrams as metamodels, such as the strict meta-modelling
principle, which is to ensure that a metamodel is a well-defined
abstract syntax of modelling language.
Strict Metamodelling:
In an n-level modelling architecture M0, M1, …, Mn, every
element of an Mm-level model must be an instance-of exactly
one element of an Mm+1-level model, for all 0  m < n-1, and
any relationship other than the instance-of relationship
between two elements X and Y implies that level(X) = level(Y).
Axiom Rules (Continue)
A4: Completeness of specialisations.
Let MA be a metaclass in a metamodel and MB1, MB2, …, MBk be the set of metaclasses
specialising MA. We have an axiom x. MA(x)  MB1(x)  MB2(x)  …  MBk(x).
A5: Types of parameters of predicates.
For each binary predicate MA(x, y) derived from an association from metaclass MC1 to MC2
in a metamodel, we have an axiom x, y. MA(x, y)  MC1(x)  MC2(y).
A6: Domain and range of functions.
For each function MAttr(x) derived from a metaattribute MAttr of type MT in a metaclass
MC, we have an axiom x,y. MC(x)  (MAttr(x) = y)  MT(y).
A7: Multiplicity of binary predicate. For each binary predicate MA(x, y) derived from an
association from metaclass MC1 to MC2 in a metamodel, let Mul be the multicity value
specified on the association end MA, we have axioms in the following form.
If Mul = 0..1:
x, y, z. MC1(x)  MA(x, y)  MA(x, z)  (y = z)
If Mul = 1 or unspecified: x. MC1(x)  y. MA(x, y) and
x, y, z. MC1(x)  MA(x, y)  MA(x, z) (y = z)
If Mul = 1..*:
x. MC1(x)   y. MA(x, y)
If Mul = 2..*:
x. MC1(x)   y, z. MA(x, y)  MA(x, z)  (y z)
If Mul = 0..2:
x, y, z, u. MC1(x)  MA(x, y)  MA(x, z)  MA(x, u)
 (y = z)  (y = u)  (u = z)
Axiom Rules (continue)
A8: Multiplicity of function.
For each function MAttr(x) derived from a metaattribute MAttr of type MT in a
metaclass MC, let Mul be the multicity value of the metaattribute MAttr, we have
axioms:
If Mul = 0..1:
x, y, z. MC(x)  (MAttr(x) = y)  (MAttr(x) = z) -> (y = z)
If Mul = 1:
x. MC(x) ->  y. (MAttr(x) = y) and
x, y, z. MC(x)  (MAttr(x) = y)  (MAttr(x) = z) -> (y = z)
If Mul = 1..*:
x. MC(x) ->  y. (MAttr(x) = y)
A9: Distinguishability of the literal constants.
For each pair of different literal values a and b of an enumeration type, we have an
axiom a b.
A10: Type of the literal constants.
For each enumeration value a defined in an enumeration metaclass ME, we have an
axiom in the form of ME(a) stating that the type of a is ME.
A11: Completeness of the enumeration.
An enumeration type only contains the listed literal constants as its values, hence for
each enumeration metaclass ME with literal values a1, a2, …, ak, we have an axiom
in the form of
x. ME(x) -> (x = a1)  (x = a2) … (x = ak).
Axiom Rule 12: Well-formedness rules.
For each WFR formally specified in OCL, we have a corresponding axiom in the first order
language.
Semantics of Interaction and State Machine


Same signature, axiom and formula mappings are applied to the
meta-models of UML state machine and interaction diagrams.
Additional Axiom Rules for inter-metamodel connections
Axiom Rules
A10: Cross metamodel association and inheritance.
For each cross metamodel inheritance from metaclass MA to external metaclass
MB, we have an axiom in the form of x. MA(x) -> MB(x).
A2’: Completeness of specialisations across metamodels.
Let MA be a metaclass depicted in two metamodels MM1 and MM2. Let
metaclasses MB1, MB2, …, MBk be the set of metaclasses that specialise MA in
metamodel MM1, and MC1, MC2, …, MCp be the set of metaclasses that
specialise MA in metamodel MM2. We have the following axiom when a model
is defined by MM1 and MM2.
x. MA(x) -> MB1(x)  …  MBk(x)  MC1(x)  …  MCp(x)
A Simplified Metamodel of Interaction Diagram
Classifier(from Kernel)
+context
Behaviour
BehaviouralFeature (from Kernel)
+specification
TypedElement(from kernel)
Interaction
+lifeline
Lifeline
+message
+sender
Message
+after
+receiver
+represents
ConnectableElement
+event
MessageEvent
+operation
Operation (from Kernel)
+signal
SendOperationEvent
SendSignalEvent
Signal (from Kernel)
A Simplified Metamodel of State Machine
Behaviour (from Interaction)
DirectedRelationship(from Kernel)
StateMachine
+transition
+vertex
ProtocolStateMachine
+specificMachine
BehaviourStateMachine
+target
Transition
+source
+generalMachine
ProtocolConformance
Vertex
PseudoState
+trigger
State
Trigger
+kind: PseudostateKind
<<enueration>>
PseudostateKind
+initial
+final
+deepHistory
+shallowHistory
+join
+fork
+junction
+choice
+entry +exit +doActivity
StateBehaviour
+effect
+guard
Constraint
The Tool LAMBDES
LAMBDES stands for
Logic
Metamodel
Model
Analyser of
Modelling tool StarUML
Model/Metamodel
Based on LAMBDES
User Interface
Descriptive
Metamodel in XMI
Model in XMI Modelling
Semantics
Context
Proof Goal
Design Pattern
Specification
Design
Pattern
Spec
Repository
Domain
Generator
Signature
Generator
Axiom
Generator
Formula
Generator
Hypothesis
Generator
Conjecture
Generator
Auxiliary
constants &
formulas
Signature
Axioms
Statements
Hypothesis
Conjecture
Logic system for model
Logic system for metamodel
Theorem prover SPASS
Inference result
Applications of Descriptive Semantics
Definition 3. (Properties of a model)
Let SemH(M) be the semantics of a model M. M has a property P
(represented as a formula in the logic system defined by Sig)
under the semantics definition SemH(M) and the hypothesis H, if
and only if AxmDAxmFT(M) H(M) |- P in the formal logic
system. Similarly, we say that M has a property P in descriptive
semantics, if and only if AxmDT(M) H(M) |- P in the formal
logic system. 





Consistency checking of UML models
Validation of consistency constraints for UML models
Consistency checking of UML meta-models
Conformance checking of designs to design patterns
Consistency checking of specification of design patterns
Consistency checking of UML models
Definition 6. (Logical consistency)
Let SemH(M) = AxmD AxmF T(M) H(M) be the semantics of
a model M. Model M is said to be logically inconsistent in the
semantic definition SemH(M) if SemH(M)|-false; otherwise, we say
that the model is logically consistent. 
Definition 7. (Consistent interpretation in a subject domain)
Let Dom=<D, Sig, Eva> be a subject domain as defined in
Definition 4. The interpretation of formulas in signature Sig is
consistent with first order logic if and only if for all formulas q
and p1, p2, …, pk that p1, p2, …, pk |- q, and for all systems s in D
that Eva(pi, s) =true for i=1,2,…, k, we always have Eva(q, s)
=true. 
Validity of consistency checking
Theorem 1. (Unsatisfiability of inconsistent model)
A model M that is logically inconsistent in the semantic definition
SemH(M) is not satisfiable on any subject domain whose
interpretation of formulas is consistent with first order logic.



Inconsistent model => it cannot be implemented (not satisfiable)
Consistency model => not necessarily implementable
Other issues effect satisfiability:
 Property of the subject domain: e.g. whether the
programming language is powerful enough to implement
 Non-logic property of the model: e.g. whether the system is
feasible
Validation of consistency constraints

Consistency constraints:

Logic statements about models,
 e.g. ‘a life line must represent an instance of a class’
x, y, z. Lifeline(x)  represent(x,y)  type(y, z) -> Class(z)
Definition 8. (Consistency w.r.t. consistency constraints)
Given a set of consistency constraints C={c1, c2, …, cn}, the
consistency of a model M with respect to the constraints C under
the semantics definition SemH(M) is the consistency of the set U
= SemH(M) C of formulas. In particular, we say that a model
fails on a specific constraint ck, if SemH(M) is consistent, but
SemH(M) {ck} is not. 
Results of experiments:
•
A number of sample UML models were checked to be consistent.
•
Mutants of the models were checked and inconsistency in
mutants were detected.
Definition of validity and effectiveness
Definition 9. (Validity of consistency constraints)
Let AxmD and AxmF be the sets of axioms for descriptive semantics
and functional semantics, respectively. A set C={c1, c2, …, cn} of
consistency constraints is descriptively valid if AxmDC is
logically consistent. The set C of consistency constraints is
functionally valid AxmDAxmFC is logically consistent. 
Definition 10. (Effectiveness of consistency constraints)
Let A be a set of semantics axioms. A set C={c1, c2, …, cn} of
consistency constraints is logically ineffective with respect to the set
A of axioms if A |- C. 
Results of Experiments:
A set of 5 consistency constraints were validated by using
LAMBDES tool. They were proved valid and effective.
Consistency checking of meta-models
Definition 11 (Inconsistency of meta-model).
A meta-model M is inconsistent if AxmD(M) is logically inconsistent.
Experiments:
 Subjects:
Simplified UML, UML 2.0 metamodel, AspectJ profile
 Findings:
 Simplified metamodel: consistent
 UML 2.0:
16 inconsistencies due to voilation of strict meta-modelling
 1 inconsistently as abstract and concrete metaclasses in
different metamodel class diagrams.
 AspectJ:
Incomplete definition of 7 meta-classes
2 inconsistency due to violation of strict meta-modelling
Conclusion

Separation of functional semantics from descriptive semantics
can simplify the formal semantic definition of UML and it is
scalable





Applicable for all types of diagrams defined in meta-model uniformly
Applicable to multiple views defined by multiple meta-models, and
addressed the extendability issues
Addressed the issue due to flexibility in the uses of modelling language in
different development context
Addressed the issue for different interpretation of modelling languages in
different subject domains
Reasoning about models in first order logic can be feasible and
useful in model drive software development


Can be automated by tools such as LAMBDES + SPASS + StarUML
Can reason about properties that are not possible for semantics at object
level, such as
 The validation of consistency constraints,
 The consistency of meta-model, etc.
 The conformance of designs to patterns,
Future work

Further development of the axioms for functional
semantics;
 Theoretical analysis of the logic properties of the
semantics definition



Soundness of the rules: yes
Consistency of the rules: yes
Completeness of the rules:
 In what sense?
 How to prove?

Case studies on reasoning about other properties of
designs, such as


Platform specific models, platform independence, etc.
Transformation of models,