1. 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. History of Object-Oriented Languages
Software Engineering
Programming
Databases
Knowledge
Representation
Distributed
Systems
1965
Simula
Sketchpad
Smalltalk
UML1
Semantic Networks
Frames
Description
Logics
C++
OQL
Java
Frame Logics C#
SQL’99
OCL1
MOF1
OWL
OCL2
UML2
MOF2
Semantic Web
CHORD
SWSL
2006

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: Activity 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
Type
Multiplicity
Default value
Property
Return type
Object methods: called on objects
Class methods: called to manipulate class attributes
Operations for KR: as many fields as possible!

12. Associations Association: Fields: Navigation:
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
Difference with: ? 4
Elevator
control
Queue
Elevator

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

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

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

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

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

26. OCL Expression Contexts
Operation

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

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

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

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

31. Specifying Operations Pre and Post Conditions
context LoyaltyAccount::isEmpty(): Boolean pre: -- none post: result = (points = 0)
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 = -> including(c)
Keyword oclIsNew used to specify creation of a new instance (objects or primitive data):
context LoyaltyProgram:: enrollAndCreateCustomer(n:String,d:Date):Customer 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

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

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

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

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

36. Simplified OCL Meta-Model

37. The OCL Types Meta-Model
UML Metaclass
OCL Metaclass

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

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

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

41. OCL Library: Generic Collection Operators

42. OCL Library: Specialized Collection Operators

43. OCL Constraints vs. UML Constraints
context: ClassicalGuitar inv: strings -> forAll(s | s.oclIsType(plasticStrings))
context ElectricGuitar inv: strings
-> forAll(s \ s.oclIsType(MetalStrings))
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
context ElectricGuitar inv: strings
-> forAll(type = StringType::metal)

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

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

46. Simplified MOF2 Meta-Model of itself
NamedElement
BehavioralFeature
StructuralFeature
Operation
Parameter *
Property *
Classifier
Feature
TypedElement
Type
ValueSpecification
1..*
Relationship
RedefinableElement *
NamedElement
Element *
InstanceSpecification
Constraint *
Generalization *
Association
Class
AssociationClass
DataType
PrimitiveType
Enumeration
Interface

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

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

49. MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)
2..*
Environment
Agent
Sensor
Actuator
1..*
Percept
AgentAction
ReasoningComponent
Agent
ReflexAgent
ReflexComponent
ReasoningComponent
Sensor
Actuator
1..*
Agent
AutomataAgent
EnvironmentStateModel
ModelInitializationComponent
PercpetInterpretationComponent
RamificationComponent
ModelBasedBehaviorStrategyComponent
ReasoningComponent
Actuator
Sensor
4..*
1..*
AutomataAgent
GoalBasedAgent
Goal
GoalInitializationComponent
GoalUpdateComponent
GoalBasedBehaviorStrategyComponent
ReasoningComponent
3..*
EnvironmentStateModel
ModelBasedBehaviorStrategyComponent

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