Extending UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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