Basic Structural Modeling with UML2 and OCL2

1. Basic Structural Modelingwith UML2 and OCL2 Jacques Robin

2. Outline • Object-orientation for software engineering • UML2 class diagrams • OCL2 for UML2 class diagrams

3. Review of Key Object-Orientation Concepts • Class (or concept, or category): abstract representation of a set of individuals with common structural and/or behavioral properties • A class defines a complex type • Object (or individual, or instance): individual instance of a given class • An object conforms to the complex type defined by its class • An object is created by instantiating its class (constructor method) • Each object has a unique identifier (oid) that distinguishes it from other instances of the same class sharing the same properties • The structural properties of a class are a set of attributes (also called fields or slots), which value is constrained to be of a certain subset of types (primitive types or classes) • The structural properties of an object are specific values for these attributes within the ranges defined by its class • The behavioral properties of a class are a set of operations (also called methods, procedures, deamons or functions) that its instances can execute • The signature of a class is the set of type constraints on its attributes and on the parameters and return value of its operations • The properties of a class have various visibilities such as public, protected and private allowing their encapsulation • Classes are organized in a generalization (specialization) hierarchy • Properties are inherited down the hierarchy from a class to its subclasses and its objects

4. Motivation for OO in Software Engineering • Improved productivity, quality, legibility and maintainability in developing software artifacts • Software reuse instead of rewriting or cut and paste • More intuitive • Divide software in abstract entities and relations that directly match common cognitive abstraction of modeled domain • Easy to learn • Unifying notation • Single representation paradigm for all software process stages • Single, unified modeling language (UML)

5. UML Class Diagram • Categories represented as classes (nodes) • Classes encapsulates: • Primitive type properties, attributes • Behaviors, operations • Relationships between classes represented as associations (edges) • Special associations for: • Specialization-Generalization relationship • partOf relationship (aggregation and compositions) • Reified relationships represented as association classes • Role names and cardinality constraints on associations • Many other logical constraints built-in class diagram syntax • Arbitrary logical constraints relating any part of the class diagram using Object Constraint Language (OCL)

6. Classes: Attributes • Common characteristics of the class members • Fields (slots): • Base or derived • Visibility (public, protected, private) • Name • Type (Primitive Built-In or Used-Defined Enumerations) • Initial default value • Property • Object attributes: different value for each object • Class attributes: same value for all objects • Attributes for MDE: as many fields as possible!

7. Classes: Operations • Common signature of services provided by the class members • Fields: • Visibility • Name • Input parameter • Direction • Name • Type • Multiplicity • Default value • Property • Return type • Property • Object methods: called on objects • Class methods: called to manipulate class attributes • Operations for MDE: as many fields as possible!

8. Associations • Association: • Generic relation between N classifiers • Fields: • One or two Names • Navigation direction • Two Ends, each with: • One Multiplicity Range (default = 1) • Zero to One role • Zero to one Qualifier • Navigation: • Role if present • Otherwise destination class name • Associations for MDE: as many fields as possible!

9. N-ary Associations • Single association between N classes • Different from N-1 binary associations • Different from one binary association class • Example: • Ca has objects A1, A2 • Cb has objects B1, B2 • Cc has objects C1, C2 • No link in the ternary association Ca-Cb-Cc corresponding to pair of links A1-B1, B2-C1

10. Association Classes • Class connected to an association and not to any of its ends • Allows associating properties and behaviors to an association • One object of the association class for each link of the connected association • A one-to-many or many-to-many association class cannot be substituted by a simple class and a pair of simple associations • Example: • Ca has objects A1, A2, A3, A4 • Cb has objects B1, B2, B3, B4 • Extent of association class Cc between Ca and Cb with * multiplicity at both ends has necessarily 16 instances • Class Cc associated to Ca through association Aca and to Cb through association Acb could have only 4 instances Difference with: ? 4 Elevator control Queue Elevator

11. Aggregation: Association with “part-whole” semantics Associate composite class to its building blocks Static, definitional characteristic of the “whole” class Composition: Special case of one-to-one or one-to-many aggregation where part(s) cannot exist(s) without the unique whole Deletion of the whole must therefore always be followed by automatic deletion of the parts Aggregations and Compositions

12. Class generalizations • Taxonomic relation between a class and one of its more general direct super-class • Special case of generalization between any two classifiers • Several generalizations form a taxonomic tree free of generalization cycles • Sub-classifier inherits the features from all its direct super-classifiers • Private attributes and operations notaccessible from sub-classes • Protected attributes and operations accessible from sub-classes but not from associated classes • UML generalizations allowmultiple inheritance and overriding • Instances of a sub-class mustsatisfy all the constraints on all its super-classes(principle of substitutability)

13. Abstract Classes • Class that cannot be instantiated • Only purpose: factor gradual refinements of common and distinct structures and behaviors down a taxonomic hierarchy • Abstract operation: common signatures of distinct implementations specified in subclasses • Supports polymorphism: generic call signature to distinct operations, with automatic dispatch to the implementation appropriate to each specific call instance

14. Generalization Sets • Subclass set that can be labeled as: • complete or incomplete • overlapping or disjoint • Complete and disjoint generalization sets form a partition of the super-class • Sub-subclass can specialize members of two overlapping generalization sets

15. Power Types • Generalization set of a super-class defined in terms of a class associated to it • Subclasses of each power type inherits features from the associated class of the super-class that defines the power type • Allows separation of orthogonal concerns • Useful for MDA as a rich modeling element

16. UML Object Diagrams • Object Diagram contains: • Specific (named) or generic (named after role, unnamed) instances of classes • Possibly several instances of the same class • Specific instances of associations (links) among objects • Possibly several instances of the same association • Illustrates specific instantiation patterns of associated class diagram

17. Active objects Instances of active classes Possess their own, continuous execution thread Concurrent to other active objects Exchange data with other active objects asynchronously through message passing Does not wait for the other active object target of the message to respond to pursue its own processing Can be pro-active: execute behavior on its own initiative without waiting to receive a request from another object Passive (regular) objects Instances of passive (regular) classes Share a single thread with the other passive objects constituting a sequential application Exchange data with other passive objects synchronously through method invocation Interrupts its processing, waiting for an answer of the other passive object before pursuing its own processing Purely reactive: execute behavior only as response to a method invocation request from another object UML2 Active x Passive Objects

18. UML2 Active Classes and Objects • UML2 classes can encapsulate other classes • Thus, UML2 objects can encapsulate other objects

19. What is OCL? Definition and Role • A textual specification language to adorn UML and MOF diagrams and make them far more semantically precise and detailed • OCL2 integral part of the UML2 standard • OCL complements UML2 diagrams to make UML2: • A domain ontology language that is self-sufficient at the knowledge level to completely specify both structure and behaviors • A complete input for the automated generation of a formal specification at the formalization level to be verified by theorem provers • A complete input for the automated generation of source code at the implementation level to be executed by a deployment platform • OCL forms the basis of model transformation languages • such as Atlas Transformation Language (ATL) or Query-View-Transform (QVT) • which declaratively specify through rewrite transformation rules the automated generation of formal specifications and implementations from a knowledge level ontology • OCL expressions are used in the left-hand and right-hand sides of such rules • To specify objects to match in the source ontology of the transformation • To specify objects to create in the target formal specification or code of the transformation

20. What is OCL?Characteristics • Formal language with well-defined semantics based on set theory and first-order predicate logic, yet free of mathematical notation and thus friendly to mainstream programmers • Object-oriented functional language: constructors syntactically combined using functional nesting and object-oriented navigation in expressions that take objects and/or object collections as parameters and evaluates to an object and/or an object collection as return value • Strongly typed language where all expression and sub-expression has a well-defined type that can be an UML primitive data type, a UML model classifier or a collection of these • Semantics of an expression defined by its type mapping • Declarative language that specifies what properties the software under construction must satisfy, not how it shall satisfy them • Side effect free language that cannot alter model elements, but only specify relations between them (some possibly new but not created by OCL expressions) • Pure specification language that cannot alone execute nor program models but only describe them • Both a constraint and query language for UML models and MOF meta-models

21. What is OCL?How does it complement UML? • Structural adornments: • Specify complex invariant constraints (value, multiplicity, type, etc) between multiple attributes and associations • Specify deductive rules to define derivedattributes, associations and classes from primitive ones • Disambiguates association cycles • Behavioral adornments: • Specify operation pre-conditions • Specify write operation post-conditions • Specify read/query operation bodies • Specify read/query operation initial/default value

22. OCL: Motivating Examples • Diagram 1 allows Flight with unlimited number of passengers • No way using UML only to express restriction that the number of passengers is limited to the number of seats of the Airplane used for the Flight • Similarly, diagram 2 allows: • A Person to Mortgage the house of another Person • A Mortgage start date to be after its end date • Two Persons to share same social security number • A Person with insufficient income to Mortgage a house 1 2

23. OCL: Motivating Examples contextFlightinv:passengers-> size()<=plane.numberOfSeats 1 contextPersoninv:Person::allInstances() -> isUnique(socSecNr) context Person::getMortgage(sum:Money,security:House) pre: self.mortgages.monthlyPayment -> sum() <= self.salary * 0.3 contextMortgageinv:security.owner=borrower inv:startDate<endDate 2

24. Operation OCL Expression Contexts

25. OCL Contexts:Specifying Class Invariants The context of an invariant constraint is a class When it occurs as navigation path prefix, the self keyword can be omitted: • context Customer inv: self.name = ‘Edward’ • context Customer inv: name = ‘Edward’ Invariants can be named: • context Customer inv myInvariant23: self.name = ‘Edward’ • contextLoyaltyAccountinv oneOwner:transaction.card.owner-> asSet() -> size() = 1 In some context self keyword is required: • context Membershipinv: participants.cards.Membership.includes(self)

26. Specifying Default Attribute Values Initial values: • contextLoyaltyAccount::points: integerinit:0 • contextLoyaltyAccount::transactions : Set(Transaction)init:Set{}

27. Specifying Attribute Derivation Rules • contextCustomerCard::printedName derive:owner.title.concat(‘ ‘).concat(owner.name) • context TransactionReportLine::datederive date = transaction.date • ... • context TransactionReportinvdates: lines.date -> forAll(d | d.isBefore(until) and d.isAfter(from)) • ...

28. Specifying Query Operation Bodies Query operations: • contextLoyaltyAccount::getCustomerName(): Stringbody: Membership.card.owner.name • context LoyaltyProgram::getServices(): Set(Services)body: partner.deliveredServices -> asSet()

29. context LoyaltyAccount::isEmpty(): Booleanpre: -- nonepost: result = (points = 0) Keyword @pre used to refer in post-condition to the value of a property before the execution of the operation: contextLoyaltyProgram::enroll(c:Customer)pre:c.name<> ‘ ‘post:participants=participants@pre ->including(c) Keyword oclIsNew used to specify creation of a new instance (objects or primitive data): contextLoyaltyProgram::enrollAndCreateCustomer(n:String,d:Date):Customerpost:result.oclIsNew() and result.name=nand result.dateOfBirth =d and participant -> includes(result) oclIsNew only specifies that the operation created the new instance, but not how it did it which cannot be expressed in OCL Specifying Operations Pre and Post Conditions

30. Association Navigation • Abbreviation of collect operator that creates new collection from existing one, for example result of navigating association with plural multiplicity: • contextLoyaltyAccountinv:transactions-> collect(points) ->exists(p:Integer | p=500) • contextLoyaltyAccountinv:transactions.points ->exists(p:Integer | p=500) • Use target class name to navigate roleless association: • context LoyaltyPrograminv:levels->includesAll(Membership.currentLevel) • Call UML model and OCL library operations

31. Generalization Navigation • OCL constraint to limit points earned from single service to 10,000 • Cannot be correctly specified using association navigation: contextProgramPartnerinv totalPoints:deliveredServices.transactions.points-> sum() <10,000 adds both Earning and Burning points • Operator oclIsTypeOf allows hybrid navigation following associations and specialization links contextProgramPartnerinv totalPoints:deliveredServices.transactions-> select(oclIsTypeOf(Earning)).points-> sum() <10,000

32. By default, OCL expressions ignore attribute visibility i.e., an expression that access a private attribute from another class is not syntactically rejected OCL constraints are inherited down the classifier hierarchy OCL constraints redefined down the classifier hierarchy must follow substituability principle Invariants and post-condition can only become more restrictive Preconditions can only become less restrictive Examples violating substituability principle: contextStoveinv:temperature<= 200 contextElectricStoveinv:temperature<=300 context Stove::open() pre: status = StoveState::off post: status = StoveState::off and isOpen context ElectricStove::open() pre: status = StoveState::off andtemperature <= 100 post: isOpen OCL Visibility and Inheritance

33. OCL Expressions: Local Variables • Let constructor allows creation of aliases for recurring sub-expressions context CustomerCard inv: let correctDate: Boolean = validFrom.isBefore(Date::now) andgoodThru.isAfter(Date::now) in if valid then correctDate = true else correctDate = false endif • Syntactic sugar that improves constraint legibility

34. OCL Metamodel

35. OCL Metamodel

36. OCL Metamodel

38. OCL Type System Real Unlimited Integer Integer Boolean String

39. OCL Types: Collections • Collection constants can be specified in extension: • Set{1, 2, 5, 88}, Set{‘apple’, ‘orange’, ‘strawberry’} • OrderedSet{‘black’, ‘brown’, ‘red’, ‘orange’, ‘yellow’, ‘green’, ‘blue’, ‘purple’} • Sequence{1, 3, 45, 2, 3}, Bag{1, 3, 4, 3, 5} • Sequence of consecutive integers can be specified in intension: • Sequence{1..4} = Sequence{1,2,3,4} • Collection operations are called using -> instead of . • Collection operations have value types: • They do not alter their input only output a new collection which may contain copies of some input elements • Most collections operations return flattened collections • ex, flatten{Set{1,2},Set{3,Set{4,5}}} = Set{1,2,3,4,5} • Operation collectNested must be used to preserve embedded sub-structures • Navigating through several associations with plural multiplicity results in a bag

40. OCL Library: Generic Operators • Operators that apply to expressions of any type • Defined at the top-level of OclAny

41. OCL Library: Primitive Type Operators • Boolean: host, parameter and return type boolean • Unary: not • Binary: or, and, xor, =, <>, implies • Ternary: if-then-else • Arithmetic: host and parameters integer or real • Comparison (return type boolean): =, <>, <, > <=, >=, • Operations (return type integer or real): +, -, *, /, mod, div, abs, max, min, round, floor • String: host string • Comparison (return type boolean): =, <> • Operation: concat(String), size(), toLower(), toUpper(), substring(n:integer,m:integer)

42. OCL Library: Generic Collection Operators

43. OCL Library:Specialized Collection Operators

44. OCL Constraints vs. UML Constraints context: ClassicalGuitar inv: strings-> forAll(s | s.oclIsType(plasticStrings)) context ElectricGuitar inv: strings -> forAll(s \ s.oclIsType(MetalStrings)) context Guitar inv: type = GuitarType::classic implies strings -> forAll(type = StringType::plastic inv: type = GuitarType::classic implies strings -> forAll(type = StringType::plastic context ClassicGuitar inv: strings -> forAll(type = StringType::plastic) context ElectricGuitar inv: strings -> forAll(type = StringType::metal)