1. Extending UML

2. Why to extend UML?
While modeling software products, designers may prefer to use their own simplified notations
Example
An array of objects is represented by two classes with an aggregation relationship
A designer may prefer to show it using only one icon
See the diagrams on the next slide
C-S 446/546

3. Preferred by another designer
Array of C
Array of C 1
Preferred by designer n n C
Array of C
Conventional
Preferred by another designer
C-S 446/546

4. Why to extend UML? (continued)
An organization may impose certain restrictions or standards to be followed in modeling
Similar to design standards and coding standards
Example
All model elements must have color codes
Red indicates newly created model element
Orange indicates revision of model element
Green indicates model element is finalized
C-S 446/546

5. Preferred by the organizationC B B C D D
Conventional
Preferred by the organization
C-S 446/546

6. Standard extensions of UML
Tagged values
Indicate additional information for each modeling element
May serve dual purposes
Administrative information such as date created, date modified, author of a model etc. can be recorded
Technical information can provide details for programmer
C-S 446/546

7. Standard extensions of UML (continued)
Constraints
Conditions can be added to any modeling element or relationship to enrich the semantics of the application
Stereotype extension
The most commonly used extension
This extension lets the designer create a new modeling element by extending one of the predefined modeling element
C-S 446/546

8. Tagged Values Used to add specific properties to modeling elements
Represented as
{ <tag> = <value> }
curly brackets are part of the syntax
Can be added anywhere in the model
Both <tag> and <value> are represented as strings
Both <tag> and <value> are UNINTERPRETED  designer can put any string value for <tag> or <value>
C-S 446/546

9. Tagged values – example 1
Check inventory
Update inventory
Database
Inventory manager
Inventory System
{ # of managers = 1 }
Tagged value
C-S 446/546

10. Tagged values – example 2
Account
{ author = Dr. Jones,
created on = Dec 11, 2003 }
tagged values
Account number : Integer
Owner id : Integer
Balance : Double { initial value = 0 }
Deposit (amt : Double)
Withdraw (amt : Double)
C-S 446/546

11. Tagged values – Example 3
Season change / changeColor()
Fall
{duration = 3 months}
Winter
{duration = 3 months}
Tagged values
C-S 446/546

12. Stereotypes Extends a meta class
A meta class defines the semantics of a modeling element
Allows user to create his/her own modeling element
Example
Extend the <class> definition to include a color code to indicate the status of development (mentioned in an earlier slide)
Same meta class can be extended several times into different stereotypes
Include, in the representation,
<<stereotype name>>
Can associate a graphical icon with a stereotype, but it is optional
C-S 446/546

13. Defining an interface using stereotype
MathFunctions
sin (x : Double) : Double
cos (x : Double) : Double
tan (x : Double) : Double
tanInverse (x : Double) : Double …
Note : there is no special graphical icon introduced for <<interface>>
C-S 446/546

14. Modified class definitions with new icons
<<finalized class definition>> C
Color
<<Modified class def>>
<<class still under revision>> C B
<<newly created class>>
Alternate representation A
Designer must provide necessary semantics
C-S 446/546

15. Object Constraint Language (OCL)
Previously part of UML; now, it is a separate entity
Started with simple syntax; now, it is enhanced into a formal constraint language by itself
A UML model DOES NOT NEED to include OCL expressions (constraints)
However, use of OCL along with UML enriches the semantics of the application being modeled
C-S 446/546

16. Why OCL? Constraints are important in a model to
Provide rich semantics
Capture some intrinsic properties of the application being modeled
Example: only one manager account in an ATM system
To correctly refine a model towards implementation
Otherwise, programmers may have too many choices or the model will become vague
C-S 446/546

17. Why OCL? (continued)
Constraints can be expressed in natural language(s), but
Inherent ambiguities in natural languages
Constraints may be misunderstood creating additional complexities to the problem
Longer constraints become confusing or difficult to specify
Not able to justify or derive additional properties from such constraints
C-S 446/546

18. More about OCL
Developed as a business modeling language within IBM Insurance Division
A pure and formal constraints language with no side effects
i.e., including OCL expressions in a model will not change the model (or the values in the model) at any time
It only enriches the model with additional constraints
C-S 446/546

19. More about OCL (continued)
OCL is not a programming language
OCL is independent of implementation and hence implementation languages
OCL expressions are conditions that are discrete and discontinuous
Two sets of constraints on the same model may be totally different and may specify two different properties of the model
OCL is STRONGLY TYPED
Every expression in OCL must be associated with a type; often, these are Boolean expressions
C-S 446/546

20. Where to use OCL within a UML model?
To specify invariants on classes and types
An invariant is a condition that is true for the lifetime of a class or a type
To specify pre- and post-conditions on operations
Precondition describes a condition that must be true before the operation is invoked
Post-condition describes a condition that must be true after the operation is completed
To specify guards and conditions on the model
C-S 446/546

21. Specifying an invariant
Context <<class_name>> inv : <<predicate>> OR
Context <<class_name>> inv <<invariant_name>> : <<predicate>>
Context <<variable>> : <<class_name>> inv : <<predicate>>
Context<<variable>> : <<class_name>> inv <<invariant_name>> : <<predicate>>
Keywords are shown in bold letters
C-S 446/546

22. Specifying an invariant - example
Context Company inv :
self.numberOfEmployees <= 50 OR
Context Company inv maxEmployees :
Context c : Company inv :
c.numberOfEmployees <= 50
Context c : Company inv maxEmployees :
C-S 446/546

23. Specifying pre and post-conditions
Context classname :: operationName
(param1 : Type1 , …, paramN : TypeN) :
ReturnType
pre : param1 > param2
post : result = param1 if param1 > paramK
= paramK if paramK > paramM
Keywords are shown in bold letters
You can also attach names to pre- and post-conditions
C-S 446/546

24. Specifying pre and post-conditions - example
Context Account :: Withdraw (amount : double): void
pre : amount <= self.balance
post : self.balance = –
amount
Context Account :: AccountBalance () : double
pre : none
post : self.balance
C-S 446/546

25. Specifying guards and conditions
Can be specified anywhere in the model using one or more modeling elements and on one or more modeling elements
See conditions in Class diagrams, State transitions diagrams and interactive diagrams (sequence and communication diagrams)
Context is implicit when specifying a guard or condition
C-S 446/546

26. Primitive types and operators
Boolean
and, or, not, implies, xor, if-then-else
Integer
+, -, *, /, abs()
Real
+, -, *, /, floor()
String
toUpper(), toLower(), concat()
C-S 446/546

27. OCL Example
As you can see, the model represents a very simple abstraction of persons who work or study at university.
C-S 446/546

28. University Example
Each Person has a firstName and a lastName, a birthDate and an age. Each Person could be married or not, specified by the boolean value isMarried. Each Person could have a Grade specified by the attribute grade and be supervised by one supervisor who is also an instance of the class Person. Furthermore, a Person could be the supervisor of between zero and n Persons.
The class Person has different subclasses:
Every Student is a Person who has a matriculation number (matNr) and a matriculation date (matDate).
Every Employee is a Person who has a social security number (soSecNr), a wage and a taxClass.
A PhDStudent is a special Employee who has a dissertation subject (dissSubject).
The class Grade specifies an academic grade a person could have. Each Grade has a name and a value. For example, a Grade could have the name 'diploma' or 'doctor' and therefore represents a diploma or a doctor.
C-S 446/546

29. OCL -- 1
Context Person
inv tudOclInv1: self.supervisor.grade.value > self.grade.value
is an invariant which makes sure that the grade of a Person which is the supervisor of other Persons must have a higher grade than the supervised Persons.
C-S 446/546

30. OCL -- 2
Context Student
inv tudOclInv2: self.supervisor.grade.value > self.grade.value
is semantically nearly identical to the first rule. It is an invariant, too, which assures that the grade of a Person which is the supervisor of Students has to be higher than the grade of the Students he/she supervises.
C-S 446/546

31. OCL -- 3 Context Employee
inv tudOclInv3: ((self.grade.name = 'diploma') implies (self.taxClass = 'tc1'))
and ((self.grade.name = 'doctor') implies (self.taxClass = 'tc2'))
and ((self.grade.name = 'professor') implies (self.taxClass = 'tc3'))
is an invariant, too. It defines that the taxClass of an Employee depends on his/her academic grade. It specifies that an Employee with the grade 'diploma' has the taxClass 'tc1', a 'doctor' implies the taxClass 'tc2' and finally a 'professor' implies the taxClass 'tc3'.
C-S 446/546

32. OCL
OCL is used to specify invariants of objects and pre-and post conditions of operations
Make UML (class diagram) more precise
OCL expressions use vocabulary of UML class diagram
OCL attribute access “navigate” through UML class diagram
“context” specifies about which elements we are talking about
“self” indicate the current object. “result” the return value
C-S 446/546

33. OCL OCL can talk about collections (sets, bags)
Operations on collections
Example operations: select, forAll, iterate
Context Polygon inv self.vertices->forAll(p1, p2 | (p1.x = p2.x and p1.y = p2.y) implies p1 = p2)
Iterate can simulate all other operations on collections
Queries(=side-effect-free operations) can be used in OCL expressions
C-S 446/546

34. Exercises
In the ATM example, introduce two types of accounts – one with permission for overdraft (to withdraw more than the balance but to a certain limit) and another without the privilege for overdraft. Show the class diagram. Include tagged values. Define invariant for each class and pre and post-conditions for each method using OCL.
C-S 446/546