Ontologies Reasoning Components Agents Simulations Agent-Oriented Knowledge Representation Jacques Robin.

Slides:



Advertisements
Similar presentations
UML State chart/machine diagram State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state.
Advertisements

Architecture Representation
SEG4110 – Advanced Software Design and Reengineering TOPIC D Metamodelling.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Ontologies Reasoning Components Agents Simulations Software Components and the KobrA Model-Driven Component-Based Software Engineering Methodoloy Jacques.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega
Object-Oriented Analysis and Design
C OMPONENT & D EPLOYMENT D IAGRAMS Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Ontologies Reasoning Components Agents Simulations Ontologies and Agent Oriented Knowledge Representation Jacques Robin.
Unified Modeling (Part I) Overview of UML & Modeling
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Ontologies Reasoning Components Agents Simulations Basic Structural Modeling with UML2 Jacques Robin.
Ontologies Reasoning Components Agents Simulations Agent Modeling Language: An Overview Wendell Véras Vinícius Remígio Jacques Robin.
SE-565 Software System Requirements More UML Diagrams.
Teamwork Know each other Compete Leadership Strengths and Weaknesses
An Introduction to Rational Rose Real-Time
Ontologies Reasoning Components Agents Simulations Agent Modeling Language: Behavioral Models Rafael Oliveira Ricson Santana Vinícius Remigo Jacques Robin.
UML Packages & Related Diagrams
Systems Analysis and Design in a Changing World, Fifth Edition
(C) 2009 J. M. Garrido1 Object Oriented Simulation with Java.
An Introduction to Software Architecture
Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
What is MOF? The Meta Object Facility (MOF) specification provides a set of CORBA interfaces that can be used to define and manipulate a set of interoperable.
Ontologies Reasoning Components Agents Simulations Structural Modeling with UML2 Jacques Robin.
SaveUML System design. System overview Possible...
4. UML. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.1. Motivation The Unified Modeling Language tries to integrate older approaches Developed.
CSC480 Software Engineering Lecture 11 September 30, 2002.
An Ontological Framework for Web Service Processes By Claus Pahl and Ronan Barrett.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
TAL7011 – Lecture 4 UML for Architecture Modeling.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
MOF Meta-Models and UML Profiles
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
Ontologies Reasoning Components Agents Simulations Architectural Modeling with UML2 Composite Structures and Components Jacques Robin.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Software Engineering Lecture 8 Object-Oriented Analysis.
UML / UML 2.0 Diagrams (Part I) 1. Overview of the 13 diagrams of UML Structure diagrams 1.Class diagram 2.Composite structure diagram (*) 3.Component.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega. PLAN OF TALK  Introduction about components  Components and component diagrams in uml 2.0  Case study.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
MOF Meta-Models and UML Profiles
1 Unified Modeling Language, Version 2.0 Chapter 2.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 32. Review Behavioral Patterns – Observer Pattern – Chain of command.
UML Profile BY RAEF MOUSHEIMISH. Background Model is a description of system or part of a system using well- defined language. Model is a description.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML: UML 2 Metamodel Note to Instructor: The material in this.
Ontologies Reasoning Components Agents Simulations An Overview of Model-Driven Engineering and Architecture Jacques Robin.
CS 501: Software Engineering Fall 1999 Lecture 15 Object-Oriented Design I.
UML (Unified Modeling Language)
Method – Notation 8 Hours.
UML Diagrams By Daniel Damaris Novarianto S..
Course Outcomes of Object Oriented Modeling Design (17630,C604)
COMPONENT & DEPLOYMENT DIAGRAMS
Unified Modeling Language
UML Diagrams Jung Woo.
UML dynamic Modeling (Behavior Diagram)
Agent-Oriented Knowledge Representation
Chapter 2, Modeling with UML, Part 4 UML 2 Metamodel
Agent Internal Structural Modeling with UML2 and OCL2
MOF Meta-Models and UML Profiles
Object-Oriented Knowledge Representation
An Introduction to Software Architecture
Software Components Jacques Robin.
Software Architecture & Design
Presentation transcript:

Ontologies Reasoning Components Agents Simulations Agent-Oriented Knowledge Representation Jacques Robin

Outline  MOF2 and Metamodeling  UML2 Active classes and objects  UML2 Components  UML2 Protocol state machines  UML2 Profiles  A UML2 Profile for Multi-Agent Systems (MAS)  A simple MAS model using the profile

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)

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

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

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

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

UML 2.0 Component Meta-Model Class Component EncapsulatedClassifier StrcuturedClassifier part * required * * provided ConnectableElementConnectorEnd 2..* * Connector * Interface Classifier * Property Structural Feature Type Classifier TypedElement Association PackagableElementPort *

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

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

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

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

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

Agents as Active UML2 Components: MAS Simulation Specification Class Diagram > SimStateKind running stopped > Simulation +run +stop > Simulation +state:SimStateKind SimAg SimEnv Sim Realization relationship: component realizes services provided by interface Port: encapsulated classifier connection point with environment

> Simulation +state:SimStateKind Agents as Active UML2 Components: MAS Simulation Realization Class Diagram > Agent SimAg Sensors Effectors > Environment SimEnv Sensors Effectors SimAg SimEnv > AgPubStateKind empty initialized perceptReceived actionSent > SimStateKind running stopped > EnvPubStateKind empty initialized perceptsSent actionsReceived > SimEnv +create +terminate +getEnvState():EnvPubStateKind > SimAg +create +terminate +getAgState():AgPubStateKind Sim Dependency relationship: component requires services provided by interface to provide the services it itself realizes Port for connection w/ sub-component

> :Simulation Agents as Active UML2 Components: MAS Simulation Realization Object Diagram > : Environment Effectors Sensors Sim > Ag1:Agent SimAg Sensors Effectors > AgN:Agent SimAg Sensors Effectors... SimAg SimEnv

Agents as Active UML2 Components: Agent Specification Class Diagram > Agent SimAg Sensors Effectors > Environment SimEnv Effectors Sensors > SimStateKind running stopped > Simulation +state:SimStateKind SimAg SimEnv > SimAg +create +terminate +getAgState():AgPubStateKind Percept Percept1Percept2 > Sensors +receive1():Percept1 +receive2():Percept2 > Effectors +send1(p:Percept1,,ag:Agent) +send2(p:Percept2.ag:Agent) > AgPubStateKind empty initialized perceptReceived actionSent Action Action1Action2 > Sensors +receive1(ag:Agent):Action1 +receive2(ag:Agent):Action2 > Effectors +send1(ac:Action1) +send2(ac:Action2) Sim

Agents as Active UML2 Components: Agent Specification Object Diagram > : Simulation SimAg SimEnv > :Agent SimAg Sensors Effectors > : Environment SimEnv Effectors Sensors Sim

> :Agent Agents as Active UML2 Components: Agent Realization Class Diagram SimAg > updateFromPredictedActionEffect +update(o:AgSimModel,a:Action):AgSimModel > ActionEffectPredictor Sensors Effectors AgSimModel SimModel > BeliefReviser > updateFromPercept +update(o:AgSimModel,p:Percept):AgSimModel > ActionChooser > chooseAction +choose(m:AgSimModel):Action >

:Agent Agents as Active UML2 Components: Agent Realization Object Diagram SimAg Sensors Effectors m0:AgSimModel > :ActionChooser :Action :Percept > :BeliefReviser > m1:AgSimModel m2:AgSimModel > :ActionEffectPredictor

Agents as Active UML2 Components: Environment Specification Class Diagram > Environment SimEnv > Agent > SimStateKind running stopped > Simulation +state:SimStateKind SimAg SimEnv > SimEnv +create +terminate +getEnvState():EnvPubStateKind Percept Percept1Percept2 > Sensors +receive1():Percept1 +receive2():Percept2 > Effectors +send1(p:Percept1,,ag:Agent) +send2(p:Percept2.ag:Agent) > EnvPubStateKind empty initialized perceptsSent actionsReceived Action Action1Action2 > Sensors +receive1(ag:Agent):Action1 +receive2(ag:Agent):Action2 > Effectors +send1(ac:Action1) +send2(ac:Action2) SimAg Sensors Effectors Sim

Agents as Active UML2 Components: Environment Specification Object Diagram > : Simulation SimAg SimEnv > Ag1:Agent SimAg Sensors Effectors > : Environment SimEnv Effectors Sensors > AgN:Agent SimAg Sensors Effectors... Sim

Agents as Active UML2 Components: Environment Realization Class Diagram > Environment +EnvPubState:EnvPubStateKind SimAg > Ramifier > updateFromRamifications +update(o:EnvSimModel):EnvSimModel Sensors Effectors EnvSimModel SimModel > DirectEffectUpdater > updateFromDirectEffects +update(o:EnvSimModel,ac:Action):EnvSimModel > computeNewPercepts +percept(o:EnvSimModel,a:Agent):Percept > PerceptUpdater >

:Environment Agents as Active UML2 Components: Environment Realization Object Diagram SimAg Sensors Effectors :Action m0:EnvSimModel > :Ramifier > :Percept > :PerceptUpdater m2:EnvSimModel m1:EnvSimModel > :DirectEffectUpdater >

UML2 Common Behaviors BehavioralFeature Feature Operation TimeEvent ValueSpecification ChangeEvent Class Classifier SignalReception Class isActive = true Interface * 0..1 * * SendSignalEvent Event ReceiveSignalEvent SendOperationEvent ReceiveOperationEvent BehavioredClassifier Classifier method Behavior specification Activity Interaction StateMachine 0..1 Trigger * StructuralFeature *

UML2 Protocol State Machines  Specialization of state machines to specify interaction protocols between concurrent components, i.e.,  How the state S of component C restricts the operations O s 1,... O s k that another component can request C to execute  What are the states S 1,... S k, that result from the execution in S of O s 1,... O s k (respectively)  Useful for represent cooperation, competition and negotiation protocols among agents  Meta-model: source target outgoing incoming postCondition preCondition StateMachine ProtocolStateMachine State VertexProtocalTransition Constraint Operation * * Pseudostate kind:Pseudostatekind > PseudostateKind initial join fork junction choice entryPoint exitPoint terminate * 1..* Concrete transition syntax: [ ] /

UML2 Protocol State Machines: Examples emptyinitialized init()/create()/ perceptsReceivedactionsSent receive()send(action)/ AgentPSM {protocol} emptyinitialized init()/create()/ perceptsSent actionsReceived send(agent1,percept1)/ receive(agentN/) EnvironmentPSM {protocol} send(agentN,perceptN)/ receive(agent1)/... PseudoState State Operation ProtocolTransition

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

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

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

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