1. Ontologies Reasoning Components Agents Simulations Object and Agent Oriented Knowledge Representation Jacques Robin

2. Outline  Review of object-oriented concepts  History of object-oriented languages  UML2 as a domain knowledge representation language  Ontologies and object-oriented knowledge reuse  The Object Constraint Language (OCL) an ontology specification language  The Meta-Object Facility (MOF) as a language to represent structural meta-knowledge  UML2 profiles, a built-in mechanism to extend UML2 beyond object- orientation  UML2 constructs to model agents  A UML2 profile for agent-oriented knowledge representation

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. Categories  The organization of objects in categories is a vital part of knowledge representation  Most human reasoning occurs at the abstract level of general categories (intentional knowledge), rather than at the level of individual objects (extensional knowledge)  Partial information:  coming for example from the sensors of an agent,  about an object can be sufficient to classify it into a set of fixed categories  about which general knowledge has been formalized  The missing information:  needed for example for an agent to make a decision about how to handle the object or predict its behavior  about the object can then be derived from the properties of the category  Complex taxomonies involving generalization and composition relationships among categories form a rich network of abstract knowlege onto which to base the reasoning of an agent

9. Properties of Categories  Disjointness  No common elements  Ex.: male and female  Exhaustive decomposition  Covers the entire set of entities in the represented domain  Ex.: an animal that is not male, must be female  Partition  Exhaustive decomposition into disjoint categories  Counter-example: citizenships  Composition  A category of objects has another category of objects as one of its constituing parts  Ex.: A state is part of federal nation, a chapter is part of a book

10. Semantic Networks  Category-oriented knowledge visual modeling  Each category and instance is represented by a network node  Each relationship between categories and instances is represented by a network link  Special subsetOf and partOf relationships among categories  Special memberOf relationship between a category and its instances  Early semantic networks had single isa relationship that did not distinguish between subsetOf and memberOf  Efficient algorithms to derive instance properties from their category:  By value inheritance  By link path query

11. Semantic Networks: Examples  Network with four categories and four instances  Network with N-ary relationship reified as a category instance

12. Semantic Networks x CFOL: Examples (  P, person(P)  mammal(P))  (  P, fenalePerson(P)  person(P))  (  P, malePerson(P)  person(P))  (  P, person(P)  (  M hasMother(P,M)  femalePerson(M))) (  P, person(P),  abnormal(P,person,legNumber)  legNumber(P,2))  femalePerson(mary)  malePerson(john)  sister(mary,john)  malePerson(john)  abnormal(john,person,legNumber)  legNumber(john,1) fly(shankar,newYork,newDelhi,yesterday)

13. Early Semantic Networks  Shortcut the formalization level of knowledge representation  Directly mapped the graphical, knowledge level to the user-hidden programming code, implementation level  Inference engines implemented reasoning that was unsound with semantic networks defined by most users, due to lack of:  Well-defined semantics for non-monotonic inheritance and reification of N-ary relationships as categories  Distinction between categories and instances

14. Late Semantic Networks  Incorporated ever increasing types of links to get back expressive power close to that of CFOL  Lost visual modeling simplicity and intuitiveness  Remaining limitations:  Inheritance and link navigation sole inference services  No construct to represent behavioral knowledge  No construct to represent behavioral knowledge, state changes, events and time  Currently obsolete, superseded by Description Logics  Most recent DL engines use CFOL theorem proving techniques instead of graph traversal techniques to reason correctly and efficiently

15. Frames  A frame has a name as its identification and describes a complex category or instance using a set of attributes (called slots)  A frame system is a hierarchical organized set of frames.  An evolution of semantic networks  They also implement monotonic and non-monotonic inheritance  Nodes are replaced by frames  Edges are replaced by attributes (slots)  Procedures may be attached to the slots of a frame to:  Represent behavioral knowledge  Implement other forms of reasoning than mere inheritance  Provide a knowledge acquisition user-interface  Provide a reasoning explanation user-interface

16. Frames  Categories (classes) and instances (objects) represented by Frames  A frame is composed by slots  A slot is composed by facets  Facets may be:  Value specification (known or by default)  Constraint over value (type, cardinality)  Procedures (triggers for when the slot is acessed, modified or necessary to derive some fact during reasoning)  Frames hierarchically organized with multiple inheritance of slots  Inheritance is complex (without no formal definition) due to the variety of facets and interactions  Reasoning is implemented combining inheritance and triggers  Frames used for:  Knowledge representation  Inference engine implementation  Knowledge acquisition interface implementation  Reasoning explanation interface implementation  Frames are always an extension of some host programming language (Lisp, C++, Prolog, etc.)

17. Frames: example Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtby Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtby Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 Frame: BasCourse in KB University Is-a: Course Slot: taughtby Type: Professor Frame: BasCourse in KB University Is-a: Course Slot: taughtby Type: Professor Frame: Professor in KB University Slot: degree Default: PhD. Frame: Professor in KB University Slot: degree Default: PhD. Frame: Student in KB University Frame: GradStudent in KB University Is-a: Student Slot: degree Default: Bachelor Frame: GradStudent in KB University Is-a: Student Slot: degree Default: Bachelor Frame: Undergrad in KB University Is-a: Student Frame: Undergrad in KB University Is-a: Student

18. Frames x CFOL: Example partOf(course,kbUniversity)  fsfv(course,enrolls,type,student)  fsfv(course,enrolls,minCard,2)  fsfv(course,enrolls,maxCard,30)  fsfv(course,taughtBy,type,courseTaughtByType)  ((courseTaughtByType = gradStudent)  (courseTaughtByType = professor))  fsfv(course,taughtBy,minCard,1)  fsfv(course,taughtBy,maxCard,1)  partOf(advCourse,kbUniversity)  isa(advCourse,course)  fsfv(advCourse,enrolls,type,advCourseEnrollsType)  includes(advCourseEnrollsType,gradStudent)  excludes(advCourseEnrollsType,undergradStudent)  partOf(professor,kbUniversity)  fsfv(professor,degree,default,phd) Missing: formulas axiomatizing in CFOL the semantics of partOf, isa and all the slots (minCard,maxCard,type, default, etc) Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtBy Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtBy Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 Frame: Professor in KB University Slot: degree Default: PhD. Frame: Professor in KB University Slot: degree Default: PhD.

19. Frames: limitations  Non-declarative behavior knowledge representation as host programming language code as prevents direct acquisition from domain expert  No formal semantics  No distinction between categories and instances  Ad-hoc implementation of deduction and abduction usually inefficient as compared to logic-based ones  There are no inductive inference engines for frame learning  Lacks key reuse-oriented facilities of modern OO programming languages such as visibility, interfaces, components, etc.

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

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

22. 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!

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

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

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

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

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

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

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

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

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

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

33. What is an Ontology?  Explicit, formal (or semi-formal) specification of a shared conceptualization  Conceptualization:  Conceptualization: model of entities, relations, constraints and rules of a given domain or field;  Formal:  Formal: machine-processable, allowing automated reasoning, with declarative semantics;  Shared:  Shared: by a knowledge community, allowing common understanding and effective communication of largely implicitly specified content, completed by inference based on the shared explicit knowledge in the ontology  Knowledge base reusable across AI applications  Independent from any specific application requirement  Linguistic ontology  Linguistic ontology: based on vocabulary and deep syntactic roles of one or several natural languages (ex, http://wordnet.princeton.edu/)http://wordnet.princeton.edu/)  Domain conceptual ontology  Domain conceptual ontology: common core of KB from application family in a given domain  Common-sense conceptual ontology  Common-sense conceptual ontology: domain-independent, high-level concepts from one or several common sense knowledge aspects

34. Elements of an Ontology: Concept Generalization Hierarchy  Entity Classes:  Each entity class defined by a set of slot-facet-value triple  Correspond to:  Classes of OO models  Entities of relational models  Terms of logical models  Property slots x relational slots  Filled by atomic values (primitive data types) x by other concepts  Epistemological status of the value (defined by the facet)  Precisely known, default, possibilistic, plausibilistic, probabilistic  Generic Relations:  With or without generalization hierarchy running parallel to concept generalization hierarchy  Correspond to:  Associations, aggregations, compositions and complex object filled attributes of OO models  Relations of relational model  Predicates of logical models

35. Elements of an Ontology: Constraints and Derivation Rules  Constraints:  On the domain values of attributes from  One concept (type constraints)  Several related concepts (integrity constraints)  To prohibit semantically invalid concepts instances or semantically inconsistent concept instance set  Correspond to:  Class signatures and invariants in OO models  Typing predicates, sorts (partition of constant symbol alphabet) and integrity constraints in logical models  Typing and integrity constraints in database schemas  Rules to derive:  The value of attribute concepts from set of other such values  The existence of concept instances from the existence of other such instances  Correspond to:  Declarative methods in OO models  Implicative clauses of logical models  Database views

36. Elements of an Ontology: Constraints x Derivation Rules  As a constraint, the formula:   C, person(C)   ! M, person(M)  mother(M,C)  prohibits the creation of person concept instances with zero or multiple mothers;  As a derivation rule, this same formula allows inferring: - From the existence of each instance C of the person concept the existence of another instance M of that concept, related to C by an instance of the mother relation; - From the existence of two instances M and M’ of the person concept, both related to the same third instance C of that concept by the mother relation, that M = M’  Concept instances generally not part of an ontology  Exception: special values that correspond to constant value declaration in programming language as opposed to variable binding

37. Cross-Disciplinary History of Ontologies Organization Knowledge Management since 1990 Data Integration since 1995 Multi-Agent Systems since 1995 Web Information Retrieval since 2000 Cognitive Psychology since 1960 Linguistics since 1960 Expert Systems since 1980 Natural Language Processing since 1980 Ontologies Philosophy since 350 A.C. Software Engineering (Business Modeling) since 1990

38. Top-Level Common Sense Conceptual Ontology Domain or Task Specific Ontology Domain or Task Specific Ontology

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

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

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

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

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

44. OCL Expression Contexts Operation

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

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

47. 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)) ...

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

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

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

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

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

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

54. Simplified OCL Meta-Model

55. The OCL Types Meta-Model OCL MetaclassUML Metaclass

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

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

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

59. OCL Library: Generic Collection Operators

60. OCL Library: Specialized Collection Operators

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

62. Meta-modeling and MOF2  Q: What is a meta-model?  A: A base of structural meta-knowledge that defines the constructs (vocabulary) and their possible relations (grammar) of the knowledge representation language used to specify an agent’s knowledge  It does not contain knowledge about the agent’s environment, only about the language that the agent uses to represent such knowledge  MOF2 key ideas:  Reuse structural core of UML2 for meta-modeling purposes  While a class diagram specifying knowledge about a given domain is part of a UML model, a class diagram specifying constructs of a knowledge representation (or modeling) language is a MOF meta-model  The abstract constructs and concrete visual syntax of a UML domain model and MOF meta-model are the same, only the modeling purposes and levels are different  Meta-circularity: MOF2 is its own meta-model (the meta-meta-model)

63. MOF2 Meta-Models vs. BNF Grammars  Same purpose  Advantages of MOF:  Abstract instead of concrete syntax (more synthetic)  Visual notation instead of textual notation (clarity)  Graph-based instead of tree-based (abstracts from any reader order)  Entities (classes) have internal structure and behavior (strings do not)  Relations include generalization and undirected associations instead of only order  Specification reuse through inheritance and package relationships  Additional advantages with OCL:  OCL constraint apply equally well to meta-models than to models  Allows expressing arbitrary complex logical constraints among language elements (more expressive)  Allows defining formal semantics without mathematical syntax

64. Simplified MOF2 Meta-Model of itself InstanceSpecification Parameter * Generalization * Association Class AssociationClass DataType PrimitiveType Enumeration Interface * 1..* Relationship NamedElement Constraint * TypedElement TypeProperty ValueSpecification Classifier FeatureClassifierRedefinableElement * Element * NamedElement BehavioralFeature StructuralFeature Operation *

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

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

67. UML2 Components: Key Distinctions Component Classes  UML2 Component Classes appearing in Class Diagrams together with UML2 Classes, Associations, Interfaces, Dependency and Realization Relationships Component Instances  UML2 Component Instances appearing in Object Diagrams together with UML2 Objects, Links, Ports and Connector Relationships  UML2 Component Specification  UML2 Component Specification diagram that,  represents the component as a black box,  describes only what the component does, i.e., its provided services and externally visible states  and what the component needs from its external environment, i.e., its required services. Component Realization  UML2 Component Realization diagram that,  represents the component as a white box,  describes how the component does what it does,  by way of an internal assembly from lower granularity components, classes and assoiciations that it encapsulates.

68. Component Class vs. Standard OO Programming Class Component class:  Medium granularity intermediate between system and class, corresponding to that of a module, a library, an API or a package  Necessarily encapsulates behavior, possibly also data  Possesses meta-data describing its services and requirements to compose/assemble it with other components  Necessarily designed by contract by realizing and requiring interfaces  Relationships with other component classes: essentially horizontal clientship, possibly also encapsulating containment and conceptual generalization  Compiled independently of other components, allowing binary, source code language independent compatibility  Not necessarily object-oriented OOP class:  Fine grained unit  Necessarily encapsulates data, possibly also behavior  Does not possess descriptive meta- data  Not necessarily designed by contract  Relationship with other classes: essentially conceptual generalization, possibly also horizontal clientship and encapsulating containment  Compiled together with the other classes of a program, thus preventing binary, source code language independent compatibility

69. Component Class vs. Module, Library, Package and API  API:  Ambiguous term, can mean only an interface specification or an interface specification and its implementation  A component class always means the latter  Modules, libraries, packages and APIs:  Not independently deployable  Single unit of compilation  Source code language dependent  Only encapsulates behavior not data  No user interface nor testing interface  No meta-data  Libraries and APIs:  No conceptual generalization relationships  No encapsulating containment relationships  Modules and Packages:  Merely a source code structuring namespaces  No instantiation as run-time entity

70. Component Instance vs. Object Component Instance:  Independently deployable  At run time subject to service invocation  At deployment time subject to composition/assembly  Possesses meta-data accessible at run time through access methods that describe its services and requirements  Possesses a user-interface for stand- alone deployment  Not necessarily object-oriented  A server component instance can be substituted by another one that conforms to its contract with no need to recompile or even to interrupt the client component instances  Client component code independent of server component deployment location Object:  Must be wrapped inside a program to be executed  Only subject to method invocation  Two object that cooperate to provide a service must be recompiled together to modify one of them  Client object method code dependent of server object method code deployment location

71. UML2 Components  Instantiating a component class to create a component object is a complex process that involves:  Instantiating of its encapsulated owned components, classes and associations, and  Assembling these instances together through connectors  Principles of component-based object-oriented representations:  Recursive decomposition: components are internally assembled from smaller and smaller ones down to those made of a single class  Uniformity: everything is a component, including the entire system  Locality: a given diagram shows only the part of the entire model that is visible from the local perspective of a single >  Q: Why are UML2 components interesting for AI system engineering?  A: In essence, agents are UML2 active components

72. UML2 Profiles  Self-extension mechanism to customize UML2 towards:  Specific application families (i.e., multi-agent simulations)  Specific implementation platforms (i.e., EJB,.net, web services)  A profile is a set of stereotypes  Concrete syntax: > and/or icon  Stereotypes are specializations of meta-classes from the UML2 meta-model PackageClass PropertyAssociation Profile ProfileApplication * * * meta-class Extension Stereotype * Image icon ExtensionEnd * UML2 Superstructure Meta-Model UML2 Extension/Customization Language Meta-Model

73. MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML) MAS 2..* EnvironmentAgent SensorActuator 1..* Percept 1..* AgentAction 1..* MAS ReasoningComponent 1..* Agent ReflexAgentReflexComponent ReflexAgent ReasoningComponent Sensor Actuator 1..* AutomataAgentGoalBasedAgent Goal GoalInitializationComponent GoalUpdateComponent GoalBasedBehaviorStrategyComponent ReasoningComponent GoalBasedAgent 3..* EnvironmentStateModel ModelBasedBehaviorStrategyComponent AgentAutomataAgent EnvironmentStateModel ModelInitializationComponent PercpetInterpretationComponent RamificationComponent ModelBasedBehaviorStrategyComponent ReasoningComponent AutomataAgent Actuator Sensor 4..* 1..*

74. MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML) Agent KBAgentKBComponent KBAgent ReasoningComponent 1..* KnowledgeBase PersistentKB VolatileKB 0..* KBSentence 1..* ReflexAgent ReflexKBAgentReflexKBComponent ReflexKBAgent ReflexComponent KBAgentKBComponent PersistentKB ReflexKB context ReflexKBComponent inv Volat ileKB.isEmpty() AutomataKBAgent AutomataAgent AutomataKBAgent KBComponent KBAgent EnvironmentStateModelKB 4..* VolatileKB EnvironmentStateModel 4..* GoalBasedKBAgent GoalBasedAgent GoalBasedKBAgent KBComponent KBAgentGoalKB EnvironmentStateModelKB 6..* VolatileKBGoal EnvironmentStateModel 4..*3..*

75. UML2 Profile for MAS  MASML Meta-Model  UML2 Meta-Model MAS Environment Agent Sensor Actuator Percept AgentAction ReasoningComponent EnvironmentStateModel KnowledgeBase KBSentence Component isActive = true ComponentInterface Signal Model Package PackagableElement TypedElement *