OntologiesReasoningComponentsAgentsSimulations

Object and Agent OrientedObject and Agent OrientedKnowledge RepresentationKnowledge Representation

Jacques Robin

OutlineOutline

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

Review of Key Review of Key Object-Orientation ConceptsObject-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

InheritanceInheritance

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

Software Engineering DistributedSystems

History of Object-Oriented History of Object-Oriented LanguagesLanguages

Programming KnowledgeRepresentation

Databases

Simula

Sketchpad

Java

C#

Semantic Networks

DescriptionLogics

Frame Logics

SQL’99

Frames

Smalltalk

1965

2006

C++

OQL

UML1

OCL1MOF1

OCL2UML2MOF2

Semantic Web

OWL

SWSL

CHORD

Motivation for OO Motivation for OO in Software Engineeringin 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)

Initial Motivation for OOInitial Motivation for OOin Knowledge Representationin 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

CategoriesCategories

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

Properties of CategoriesProperties 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

Semantic NetworksSemantic 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

Semantic Networks: ExamplesSemantic Networks: Examples

Network with four categories and four instances

Network with N-ary relationship reified as a category instance

Semantic Networks x CFOL: Semantic Networks x CFOL: ExamplesExamples

(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)

Early Semantic NetworksEarly 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 ofN-ary relationships as categories

Distinction between categories and instances

Late Semantic NetworksLate 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

FramesFrames

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

FramesFrames

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

Frames: exampleFrames: 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 UniversityFrame: 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

Frames x CFOL: ExampleFrames 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.

Frames: limitationsFrames: 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.

UML as KR LanguageUML 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

UML Class DiagramUML 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)

Classes: AttributesClasses: 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!

Classes: OperationsClasses: 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!

AssociationsAssociations

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!

N-ary AssociationsN-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

Association ClassesAssociation 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

Elevatorcontrol

Queue Elevator

Difference with: ?

4

Aggregations and CompositionsAggregations 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

Class generalizationsClass 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)

Abstract ClassesAbstract 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

Generalization SetsGeneralization 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

Power TypesPower 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

UML Object DiagramsUML 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

What is an Ontology?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

LinguisticLinguistic ontology ontology: based on vocabulary and deep syntactic roles of one or several natural languages (ex, http://wordnet.princeton.edu/)

Domain conceptualDomain conceptual ontology ontology: common core of KB from application family in a given domain

Common-sense conceptualCommon-sense conceptual ontology ontology: domain-independent, high-level concepts from one or several common sense knowledge aspects

Elements of an Ontology:Elements of an Ontology:Concept Generalization HierarchyConcept 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

Elements of an Ontology:Elements of an Ontology:Constraints and Derivation RulesConstraints 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

Elements of an Ontology:Elements of an Ontology:Constraints x Derivation RulesConstraints 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

Cross-Disciplinary History of Cross-Disciplinary History of OntologiesOntologies

OrganizationKnowledge

Managementsince 1990

DataIntegrationsince 1995

Multi-AgentSystems

since 1995

WebInformation

Retrievalsince 2000

CognitivePsychologysince 1960

Linguisticssince 1960

ExpertSystems

since 1980

Natural LanguageProcessingsince 1980

OntologiesPhilosophy

since 350 A.C.

SoftwareEngineering

(Business Modeling)since 1990

Anything

AbstractObjectsEvents

Sets Numbers RepresentationalObjects

Categories

Sentences Measurements

Intervals PlacesPhysicalObjects Processes

MomentsThings Stuff

Animals Agents

Humans

Solid Liquid Gas

Top-Level Common Top-Level Common SenseSense

Conceptual OntologyConceptual Ontology

Domain or TaskSpecific Ontology Domain

or TaskSpecific Ontology

What is OCL? What is OCL? Definition and RoleDefinition 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

What is OCL?What is OCL?CharacteristicsCharacteristics

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

What is OCL?What is OCL?How does it complement UML?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

OCL: Motivating ExamplesOCL: 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

OCL: Motivating ExamplesOCL: Motivating Examples

1

2

context Flightinv: passengers -> size() <= plane.numberOfSeats

context Mortgage inv: security.owner = borrowerinv: startDate < endDate

context Personinv: Person::allInstances() -> isUnique(socSecNr)

context Person::getMortgage(sum:Money,security:House)pre: self.mortgages.monthlyPayment -> sum() <= self.salary * 0.3

OCL Expression ContextsOCL Expression Contexts

Operation

OCL Contexts:OCL Contexts:Specifying Class InvariantsSpecifying 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)

Specifying Default Attribute ValuesSpecifying Default Attribute Values

Initial values: context LoyaltyAccount::points : integer

init: 0 context LoyaltyAccount::transactions

: Set(Transaction) init: Set{}

Specifying Attribute Derivation RulesSpecifying 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))

...

Specifying Query Operation BodiesSpecifying Query Operation Bodies

Query operations: context

LoyaltyAccount::getCustomerName() : Stringbody: Membership.card.owner.name

context LoyaltyProgram::getServices(): Set(Services)body: partner.deliveredServices -> asSet()

Specifying Operations Pre and Post Specifying Operations Pre and Post ConditionsConditions

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:

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):Customerpost: 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

Association NavigationAssociation 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

Generalization NavigationGeneralization 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,000adds both Earning and Burning points Operator oclIsTypeOf allows hybrid navigation following associations and specialization linkscontext ProgramPartner inv totalPoints: deliveredServices.transactions -> select(oclIsTypeOf(Earning)) .points -> sum() < 10,000

OCL Visibility and InheritanceOCL 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::offpost: status = StoveState::off and isOpen

context ElectricStove::open()pre: status = StoveState::off and temperature <= 100post: isOpen

OCL Expressions: Local VariablesOCL Expressions: Local Variables

Let constructor allows creation of aliases for recurring sub-expressions

context CustomerCardinv: 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

Simplified OCL Meta-ModelSimplified OCL Meta-Model

The OCL Types Meta-ModelThe OCL Types Meta-ModelStructuralFeature Classifier

OclMessageType OclModelElementType DataType VoidType

TupleType Primitive CollectionType

SetType SequenceType BagType

OrderedSetType

OperationSignal

+elementType

1

+collectionTypes

0..4

0..*

+type

1

+referredSignal0..1 +referredOperation0..1

OCL MetaclassUML Metaclass

OCL Types: CollectionsOCL 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

OCL Library: Generic OperatorsOCL Library: Generic Operators

Operators that apply to expressions of any type Defined at the top-level of OclAny

OCL Library: Primitive Type OCL Library: Primitive Type OperatorsOperators

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)

OCL Library: Generic Collection OperatorsOCL Library: Generic Collection Operators

OCL Library:OCL Library:Specialized Collection OperatorsSpecialized Collection Operators

OCL Constraints OCL Constraints vs.vs. UML Constraints 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::plasticinv: type = GuitarType::classic implies strings -> forAll(type = StringType::plastic

Meta-modeling and MOF2Meta-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)

MOF2 Meta-Models MOF2 Meta-Models vs.vs. BNF BNF GrammarsGrammars

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

Simplified MOF2 Meta-Model of itselfSimplified MOF2 Meta-Model of itself

InstanceSpecification

Parameter*

Generalization

*

AssociationClass

AssociationClass

DataType

PrimitiveType Enumeration

Interface*

1..*Relationship

Relationship

NamedElement

Constraint

*

TypedElementType

Property

ValueSpecification

Classifier

Feature Classifier

RedefinableElement

*

Element

*

NamedElement

BehavioralFeature StructuralFeature

Operation

*

UML2 Active x Passive ObjectsUML2 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

UML2 Active Classes and ObjectsUML2 Active Classes and Objects

UML2 classes can encapsulate other classes

Thus, UML2 objects can encapsulate other objects

UML2 Components: Key DistinctionsUML2 Components: Key Distinctions

UML2 Component ClassesComponent Classes appearing in Class Diagrams together with UML2 Classes, Associations, Interfaces, Dependency and Realization Relationships

UML2 Component InstancesComponent Instances appearing in Object Diagrams together with UML2 Objects, Links, Ports and Connector Relationships

UML2 UML2 Component SpecificationComponent 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. UML2 Component RealizationComponent 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.

Component Class vs. Component Class vs. Standard OO Programming ClassStandard 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

Component Class vs. Component Class vs. Module, Library, Package and APIModule, 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

Component Instance Component Instance vs.vs. Object 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

UML2 ComponentsUML2 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 <<subject component>>

Q: Why are UML2 components interesting for AI system engineering?

A: In essence, agents are UML2 active components

UML2 ProfilesUML2 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: <<string>> and/or icon

Stereotypes are specializations of meta-classes from the UML2 meta-model

Package Class

Property Association

Profile

ProfileApplication*

**

meta-class

ExtensionStereotype*

Image

icon

ExtensionEnd*

UML2 Superstructure Meta-Model

UML2 Extension/Customization Language Meta-Model

MOF Meta-Model of a Simple Multi-Agent MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)Simulations Modeling Language (MASML)

MAS2..*

EnvironmentAgent

Sensor Actuator

1..* 1..*

Percept1..*

AgentAction1..*

MAS

ReasoningComponent1..*

Agent

ReflexAgent ReflexComponent

ReflexAgent

ReasoningComponent

Sensor

Actuator1..*

1..*

AutomataAgentGoalBasedAgent

Goal

GoalInitializationComponent

GoalUpdateComponent

GoalBasedBehaviorStrategyComponent

ReasoningComponent

GoalBasedAgent

3..*

EnvironmentStateModel

ModelBasedBehaviorStrategyComponent

AgentAutomataAgent

EnvironmentStateModel

ModelInitializationComponent

PercpetInterpretationComponent

RamificationComponent

ModelBasedBehaviorStrategyComponent

ReasoningComponent

AutomataAgent

Actuator

Sensor4..*

1..*

MOF Meta-Model of a Simple Multi-Agent MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)Simulations Modeling Language (MASML)

Agent

KBAgent KBComponent

KBAgent

ReasoningComponent

1..*

KnowledgeBase

PersistentKB VolatileKB

0..*

KBSentence1..*

1..*

ReflexAgent

ReflexKBAgent ReflexKBComponent

ReflexKBAgent

ReflexComponent

KBAgent KBComponent PersistentKB

ReflexKB

context ReflexKBComponent inv Volat ileKB.isEmpty()

AutomataKBAgent

AutomataAgent

AutomataKBAgent KBComponent

KBAgent EnvironmentStateModelKB

4..*

VolatileKB EnvironmentStateModel

4 ..*

GoalBasedKBAgent

GoalBasedAgent

GoalBasedKBAgent KBComponent

KBAgent GoalKB EnvironmentStateModelKB

6..*

VolatileKB Goal EnvironmentStateModel

4 ..*3 ..*

UML2 Profile for MASUML2 Profile for MAS

MASML Meta-Model UML2 Meta-Model

MAS

Environment

Agent

Sensor

Actuator

Percept

AgentAction

ReasoningComponent

EnvironmentStateModel

KnowledgeBase

KBSentence

Component

isActive = true

Component

Interface

Signal

Model Package

PackagableElement

TypedElement

*