1. Ontologies Reasoning Components Agents Simulations Agent Internal Structural Modeling with UML2 and OCL2 Jacques Robin

2. Outline  Object-orientation for software and knowledge engineering  Short history of object-oriented languages  UML2 as a knowledge representation language  OCL2  UML2 Components  Agent and UML2 Components

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. Inheritance  Allows concise knowledge representation through reuse of specifications and implementations among classes and objects down a specialization hierarchy  Types of inheritance:  Structural inheritance  Attribute signature inheritance (constraint inheritance)  Value inheritance  Behavioral inheritance  Operation signature inheritance (constraint inheritance)  Operation code inheritance  Inheritance multiplicity  Simple inheritance (each class restricted to having a single super-class, and each object restricted to belong to a single class)  Multiple inheritance of different properties from different sources  Multiple inheritance of same property from different sources  Inheritance monotonicity  Monotonic inheritance: simple without overriding  Non-monotonic inheritance: with overriding, logically equivalent to default reasoning, semantics beyond Classicial First-Order Logic

5. Software EngineeringDistributed Systems History of Object-Oriented Languages ProgrammingKnowledge Representation Databases Simula Sketchpad Java C# Semantic Networks Description Logics Frame Logics SQL’99 Frames Smalltalk 1965 2006 C++ OQL UML1 OCL1 MOF1 OCL2 UML2 MOF2 Semantic Web OWL SWSL CHORD

6. 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)

7. Initial Motivation for OO in Knowledge Representation  Reasoning at the level of categories  Inheritance as reasoning task  Representing structural knowledge with a notation that is more intuitive than formal logic  Easier to acquire, understand, maintain, etc.  Reasoning about classifying instances into categories and inheritance can internally reuse a logic-based theorem prover, but in a way that is transparent, hidden from the domain expert  Benefits of software engineering carrying over to knowledge (base) engineering

8. UML as KR Language  Class diagram:  Modern, well-founded version of semantic networks  Activity diagram  Modern, well-founded version of flow charts  Graphical syntax for procedures  Class diagrams + Activity diagrams :  Graphical syntax of expressive power approximately equivalent to that of Frames  Strengths:  Universal standard, well-thought, well-known and well-tooled (CASE)  Facilitates convergence between software and knowledge engineering  Limitations:  Lack of full UML compilers to executable languages  Lack of inference engine to automatically reasoning with knowlege represented only as UML models  No mathematically defined formal semantics yet  Thus:  Only useful at the knowledge level  Need to be used in conjunction with other language(s) that provide the formalization and/or implementation level

9. 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)

10. 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 KR: as many fields as possible!

11. 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 KR: as many fields as possible!

12. 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 KR: as many fields as possible!

13. 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

14. 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 Elevator control QueueElevator Difference with: ? 4

15. Aggregations and Compositions  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

16. 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 not accessible from sub-classes  Protected attributes and operations accessible from sub-classes but not from associated classes  UML generalizations allow multiple inheritance and overriding  Instances of a sub-class must satisfy all the constraints on all its super-classes (principle of substitutability)

17. 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

18. 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

19. 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

20. 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

21. UML2 Active x Passive Objects 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

22. UML2 Active Classes and Objects  UML2 classes can encapsulate other classes  Thus, UML2 objects can encapsulate other objects

23. 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

24. 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

25. 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 derived attributes, 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

26. 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

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

28. OCL Expression Contexts Operation

29. 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’  context LoyaltyAccount inv oneOwner: transaction.card.owner -> asSet() -> size() = 1 In some context self keyword is required:  context Membership inv: participants.cards.Membership.includes(self)

30. Specifying Default Attribute Values Initial values:  context LoyaltyAccount::points : integer init: 0  context LoyaltyAccount::transactions : Set(Transaction) init: Set{}

31. Specifying Attribute Derivation Rules  context CustomerCard::printedName derive: owner.title.concat(‘ ‘).concat(owner.name)  context TransactionReportLine: String derive self.date = transaction.date ...  context TransactionReport inv dates: lines.date -> forAll(d | d.isBefore(until) and d.isAfter(from)) ...

32. Specifying Query Operation Bodies Query operations:  context LoyaltyAccount::getCustomerName() : String body: Membership.card.owner.name  context LoyaltyProgram::getServices(): Set(Services) body: partner.deliveredServices -> asSet()

33. Specifying Operations Pre and Post Conditions  context LoyaltyAccount::isEmpty(): Boolean pre: -- none post: result = (points = 0) Keyword @pre used to refer in post-condition to the value of a property before the execution of the operation:  context LoyaltyProgram::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):  context LoyaltyProgram:: enrollAndCreateCustomer(n:String,d:Date):Cust omer post: result.oclIsNew() and result.name = n and 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

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

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

36. OCL Visibility and Inheritance  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: context Stove inv: temperature <= 200 context ElectricStove inv: temperature <= 300 context Stove::open() pre: status = StoveState::off post: status = StoveState::off and isOpen context ElectricStove::open() pre: status = StoveState::off and temperature <= 100 post: isOpen

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

38. Simplified OCL Meta-Model

39. The OCL Types Meta-Model OCL MetaclassUML Metaclass

40. 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

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

42. 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)

43. OCL Library: Generic Collection Operators

44. OCL Library: Specialized Collection Operators

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