Agent Internal Structural Modeling with UML2 and OCL2

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
Distributed Systems
Programming
Knowledge Representation
Databases
1965
Semantic Networks
Semantic Web
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 OOin Knowledge
Representation

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

8
UML as KR Language

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

9
UML Class Diagram

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

10
Classes Attributes

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

11
Classes Operations

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

12
Associations

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

13
N-ary Associations

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

14
Association Classes

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

Difference with ?
4
Elevator control
Queue
Elevator
15
Aggregations and Compositions

• Aggregation
• Association with part-whole semantics
• Associate composite class to its building blocks
• Static, definitional characteristic of the
  whole class

• Composition
• Special case of one-to-one or one-to-many
  aggregation where part(s) cannot exist(s) without
  the unique whole
• Deletion of the whole must therefore always be
  followed by automatic deletion of the parts

16
Class generalizations

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

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 Flightinv passengers -gt size()
lt plane.numberOfSeats
1
context Personinv PersonallInstances() -gt
isUnique(socSecNr) context PersongetMortgage(su
mMoney,securityHouse) pre self.mortgages.monthl
yPayment -gt sum() lt self.salary 0.3
context Mortgage inv security.owner
borrower inv startDate lt endDate
2
26
OCL Expression Contexts
27
OCL ContextsSpecifying 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 LoyaltyAccountinv oneOwner
  transaction.card.owner -gt asSet() -gt size()
  1
• In some context self keyword is required
• context Membershipinv participants.cards.Members
  hip.includes(self)

28
Specifying Default Attribute Values

• Initial values
• context LoyaltyAccountpoints integer init
  0
• context LoyaltyAccounttransactions
  Set(Transaction) init Set

29
Specifying Attribute Derivation Rules

• context CustomerCardprintedName
• derive owner.title.concat(
  ).concat(owner.name)
• context TransactionReportLine String derive
  self.date transaction.date
• ...
• context TransactionReport inv dates lines.date
  -gt forAll(d d.isBefore(until) and
  d.isAfter(from))
• ...

30
Specifying Query Operation Bodies

• Query operations
• context LoyaltyAccountgetCustomerName()
  Stringbody Membership.card.owner.name
• context LoyaltyProgramgetServices()
  Set(Services)body partner.deliveredServices
  -gt asSet()

31
Specifying Operations Pre and Post Conditions

• context LoyaltyAccountisEmpty() Booleanpre
  -- nonepost result (points 0)
• Keyword _at_pre used to refer in post-condition to
  the value of a property before the execution of
  the operation
• context LoyaltyProgramenroll(cCustomer)pre
  c.name ltgt post participants
  participants_at_pre -gt including(c)
• Keyword oclIsNew used to specify creation of a
  new instance (objects or primitive data)
• context LoyaltyProgramenrollAndCreateCustomer(n
  String,dDate)Customerpost result.oclIsNew()
  and result.name n and
  result.dateOfBirth d and participant
  -gt 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 -gt
  collect(points) -gt exists(pInteger
  p500)
• context LoyaltyAccount inv
  transactions.points -gt
  exists(pInteger p500)
• Use target class name to navigate roleless
  association
• context LoyaltyProgram inv levels -gt
  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 -gt sum() lt 10,000
• adds both Earning and Burning points
• Operator oclIsTypeOf allows hybrid navigation
  following associations and specialization links
• context ProgramPartner inv totalPoints
  deliveredServices.transactions -gt
  select(oclIsTypeOf(Earning)) .points -gt
  sum() lt 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 lt 200
• context ElectricStove inv temperature lt 300
• context Stoveopen()
• pre status StoveStateoff
• post status StoveStateoff and isOpen
• context ElectricStoveopen()
• pre status StoveStateoff and temperature
  lt 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(Datenow) and
  goodThru.isAfter(Datenow)
• 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
38
OCL Types Collections

• Collection constants can be specified in
  extension
• Set1, 2, 5, 88, Setapple, orange,
  strawberry
• OrderedSetblack, brown, red, orange,
  yellow, green, blue, purple
• Sequence1, 3, 45, 2, 3, Bag1, 3, 4, 3, 5
• Sequence of consecutive integers can be
  specified in intension
• Sequence1..4 Sequence1,2,3,4
• Collection operations are called using -gt 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, flattenSet1,2,Set3,Set4,5
  Set1,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, , ltgt, implies
• Ternary if-then-else
• Arithmetic host and parameters integer or real
• Comparison (return type boolean) , ltgt, lt, gt
  lt, gt,
• Operations (return type integer or real) , -,
  , /, mod, div, abs, max, min, round, floor
• String host string
• Comparison (return type boolean) , ltgt
• Operation concat(String), size(), toLower(),
  toUpper(), substring(ninteger,minteger)

41
OCL Library Generic Collection Operators
42
OCL LibrarySpecialized Collection Operators
43
OCL Constraints vs. UML Constraints
context ClassicalGuitar inv strings-gt forAll(s
s.oclIsType(plasticStrings))
context ElectricGuitar inv strings -gt forAll(s
\ s.oclIsType(MetalStrings))
context ClassicGuitar inv strings -gt
forAll(type StringTypeplastic)
context Guitar inv type GuitarTypeclassic
implies strings -gt forAll(type
StringTypeplastic inv type
GuitarTypeclassic implies strings -gt
forAll(type StringTypeplastic
context ElectricGuitar inv strings -gt
forAll(type StringTypemetal)
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
  agents knowledge
• It does not contain knowledge about the agents
  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
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)
50
MOF Meta-Model of a Simple Multi-Agent
Simulations Modeling Language (MASML)
KBAgent
1..
Agent
ReasoningComponent
KnowledgeBase
KBSentence
1..
PersistentKB
KBAgent
KBComponent
VolatileKB
0..
1..
GoalBasedKBAgent
AutomataKBAgent
GoalBasedAgent
AutomataAgent
6..
GoalBasedKBAgent
KBComponent
4..
4 ..
3 ..
AutomataKBAgent
KBComponent
4 ..
KBAgent
GoalKB
EnvironmentStateModelKB
KBAgent
EnvironmentStateModelKB
EnvironmentStateModel
VolatileKB
VolatileKB
Goal
EnvironmentStateModel