AOSE - Agent Oriented Software Engineering - PowerPoint PPT Presentation

About This Presentation
Title:

AOSE - Agent Oriented Software Engineering

Description:

... of abstraction, we find meaningful collections of entities that collaborate to ... of the MAS organizational structure allows the MAS designer to know which ... – PowerPoint PPT presentation

Number of Views:234
Avg rating:3.0/5.0
Slides: 39
Provided by: disiU
Category:

less

Transcript and Presenter's Notes

Title: AOSE - Agent Oriented Software Engineering


1
AOSE - Agent Oriented Software Engineering
  • Alvaro Magri
  • 1999s099_at_educ.disi.unige.it

2
AOSE index
  • AOSE introduction
  • Agent-based approach
  • GAIA methodology
  • Tropos methodology
  • Prometheus methodology
  • Comparison among the three methodologies

3
AOSE Introduction (1)
  • Agent-based computing is a synthesis of both
    Artificial Intelligence (AI) and Computer Science
  • An agent is an encapsulated computer system that
    is situated in some environment and that is
    capable of flexible, autonomous action in that
    environment in order to meet its design
    objectives 1
  • Agents are being advocated as a next generation
    model for engineering open, complex, distributed
    systems
  • Open components can join or leave the dynamic
    operating environment and the operating
    conditions change in unpredictable ways
  • Complex the software has a large number of
    components that interact following complex
    interaction protocols every agent has a partial
    view of the environment and there is no
    centralized control

4
AOSE Introduction (2)
  • In real-world applications the environment is
    open, complex and dynamic. As a consequence,
  • Interaction among components cannot be completely
    foreseen at compile-time
  • The system's inherent organizational structure
    must be explicitly represented
  • We need the right abstractions, methodologies and
    instruments to correctly engineer applications of
    this kind

5
AOSE Agent-Based approach (1)
6
AOSE Agent-Based approach (2)
  • Why should we use an agent-based approach in
    software development?
  • Traditional SE techniques for tackling system
    complexity involve
  • DECOMPOSITION Agents like active objects
  • ABSTRACTION Booch 2 '' at any given level of
    abstraction, we find meaningful collections of
    entities that collaborate to achieve some higher
    level view ''
  • ORGANISATION Organizational constructs are
    first-class entities in agent system

7
AOSE Agent-Based approach (3)
  • AB approach models real-world systems so
  • The patterns and the outcomes of interactions are
    inherently unpredictable
  • Predicting the behavior of the overall system
    based on its constituent components is extremely
    difficult

8
AOSE Agent-Based approach (4)
  • To avoid building a methodology from scratch, the
    researchers have extended existing methodologies
    in two areas
  • 1) OO methodologies
  • 2) KE knowledge engineering
  • In OO extensions agents are not simply objects
    the interaction between roles follows complex
    protocols and agents are characterized by their
    mental state
  • Existing OO extensions are AO Analysis and
    Design 3, Agent Modelling Technique for Systems
    of BDI agents 4, MASB 5 6, the AO
    Methodology for Enterprise modeling 7, Gaia,
    Tropos, Prometheus, AUML
  • In KE extensions, techniques for modeling the
    agent knowledge are provided. These methodologies
    are not as extendibles as the OO ones
  • Existing KE extensions are CoMoMAS 8,
    MAS-CommonKADS 9 and Cassiopeia 10

9
AOSE Gaia (1)
  • Gaia is a methodology initially proposed by M.
    Wooldridge, N.R. Jennings, and D. Kinny in the
    article ''A methodology for Agent-Oriented
    Analysis and Design'' (1999) 11
  • Recently, a new version of Gaia has been proposed
    by M. Wooldridge, N.R. Jennings and Franco
    Zambonelli (3-10-2003) 12.The new version
    extends the range of applications to which Gaia
    can be applied

10
AOSE Gaia (2)
  • REQUIREMENTS Gaia does not explicitly deal with
    the activities of requirements capturing
  • ANALYSIS
  • The Organization multiple organizations have to
    co-exist in the system and become autonomous
    interacting MASs (Multi-Agent Systems)
  • Environmental Model The environment is modelled
    in terms of abstract computational resources as
    variables or tuples, made available to the agents
    for sensing, for effecting, or for consuming

11
AOSE Gaia (3)
  • Preliminary Role Model definition of the
    organization's roles and protocols. There are two
    main attribute classes
  • Permissions what can or cannot be done while
    carrying out the role
  • Responsibilities
  • Liveness propertiesgiven centain conditions,
    ''something good happens''
  • Safety properties are invariants, '' nothing bad
    happens ''
  • Preliminary Interaction Model protocol
    definition for each type of inter-role
    interaction with particular attributes protocol
    name, initiator, partner, inputs, outputs,
    description
  • Organizational Rules it is possible to
    distinguish between liveness and safety
    organizational rules.
  • Liveness rules define how the dynamics of the
    organization should evolve over time
  • Safety rules define time-independent global
    invariants for the organization

12
AOSE Gaia (4)
  • ARCHITECTURAL DESIGN
  • During this engineering stage, various notations
    and graphical representations can be adopted to
    describe and present roles and their interactions
    (e. g., AUML diagrams)
  • Completion of Role and Interaction Models
  • The identification of the MAS organizational
    structure allows the MAS designer to know which
    roles will interact with other roles and which
    protocols will be followed during interaction

13
AOSE Gaia (5)
  • DETAILED DESIGN
  • Agent Model identifies which agent classes are
    to be defined to play specific roles and how many
    instances of each class have to be instantiated.
  • Services Model identifies the services
    associated with each agent class. For each
    service the documentation related to its inputs,
    outputs, pre-conditions and post-conditions must
    be provided
  • IMPLEMENTATION Gaia does not deal with
    implementation issues

14
AOSE Prometheus (1)
  • Prometheus is a methodology proposed by L.
    Padgham and M. Winikoff in the article ''
    Prometheus A methodology for Developing
    Intelligent Agents '' (2002) 13
  • Prometheus was the wisest Titan in Greek mythology

15
AOSE Prometheus (2)
  • SYSTEM SPECIFICATION
  • In this stage ''percepts'' and ''actions'' that
    characterize the agent's interaction with the
    environment are defined
  • Functional descriptors that contain a name,
    description, actions, percepts, data used, and
    produced and a description of interactions are
    defined
  • Use cases contain an identification number, a
    natural language overview, an optional field
    context, the scenario , a summary of all the
    information used, and a list of small variants

16
AOSE Prometheus (3)
  • ARCHITECTURAL DESIGN
  • During this stage the following activities are
    performed
  • Identification of which agents should belong to
    the MAS
  • identification of groups of agents which share
    the same functionalities
  • identification of the agent acquaintance diagram
    which defines the links among interacting agents

17
AOSE Prometheus (4)
  • definition of the agent descriptors,
    characterized by name, description, cardinality,
    functionalities, reads data, writes data,
    interacts with
  • definition of the events, messages and shared
    data objects

- identification of the system overview diagram
which ties together agents, events and shared
data objects - definition of the interaction
diagrams and interaction protocols using AUML
18
AOSE Prometheus (5)
  • DETAILED DESIGN
  • Focuses on developing the internal structure of
    each agent and how it will achieve its task
    within the system
  • The developer must define capabilities, internal
    events, plans and detailed data structures
  • Capability descriptor contains inputs and
    produced events, a description of functionality,
    a name, interactions with other capabilities,
    inclusions and a reference to read and write data
  • Agent overview diagram shows capabilities within
    an agent
  • Capability overview diagram takes a single
    capability and describes its features
  • The final design artifacts are the individual
    plan, even and data descriptors
  • The Plan descriptor provides an identifier, the
    triggering event type, the plan steps, a context
    and a list of data read and written

19
AOSE Tropos (1)
  • Tropos is a methodology proposed by J.
    Mylopoulos, M. Kolp and P. Giorgini in the
    article '' Agent Oriented Software Development ''
    (2002, but since 2000 was matter of study) 14
  • This presentation is based on the latest article
    written by P. Bresciani, P. Giorgini, F.
    Giunchiglia, J. Mylopoulos and A. Perini
    ''TROPOS An Agent-Oriented Software Development
    Methodology '' (May 2004) 15
  • FIVE MAIN DEVELOPMENT PHASES
  • Early Requirements
  • Late Requirements
  • Architectural Design
  • Detailed Design
  • Implementation

NOTE Tropos from Greek ''tropé'' which means
''easily changeable'', also ''easily adaptable''
20
AOSE Tropos (2)
  • MODELING ACTIVITIES
  • Actor modeling, which consists of identifying and
    analyzing both the actors of the environment and
    system' s actors and agents
  • Dependency modeling
  • Goal modeling based on 3 basic techniques
    means-end analysis, contribution analysis, and
    AND/OR decomposition
  • Plan modeling
  • Capability modeling

21
AOSE Tropos (3)
  • EARLY REQUIREMENTS ANALYSIS consists of
    identifying and analyzing the stakeholders and
    their intentions. We must create Actor Diagrams
    and Goal Diagrams

22
AOSE Tropos (4)
23
AOSE Tropos (5)
  • LATE REQUIREMENTS ANALYSIS focuses on the
    system-to-be within its operating environment.
    System-to-be is represented with a goal diagram
    as one actor which has a number of dependencies
    with the other actors of the organization.
  • ARCHITECTURAL DESIGN defines the system' s
    global architecture in terms of sub-systems
    (actors) interconnected through data and control
    flows (dependencies). It is articulated in 3
    steps
  • Step 1 the overall architecture is defined (
    extended actor diagram)
  • Step 2 the capabilities is defined from actor
    dependencies
  • Step 3 a set of agent types with one or more
    different capabilities (agent assignment) is
    defined

24
AOSE Tropos (6)
  • DETAILED DESIGN deals with the specification of
    the agents' micro level
  • Capability diagrams model a capability with UML
    activity diagrams. In particular action states
    model plans
  • Plan diagrams each plan node of a capability
    diagram can be further specified by UML activity
    diagrams
  • Agent interaction diagrams AUML sequence
    diagrams
  • IMPLEMENTATION in JACK Intelligent Agents 16,
    an agent-oriented development environment

25
Comparison (1)
  • In order to compare Agent-Oriented Methodologies
    we must have a comparison framework
  • In order to compare Gaia and Tropos we refer to
    the framework presented by A. Sturm and O.
    Shehory in ''A Framework for Evaluating
    Agent-Oriented Methodologies'' 17
  • In order to compare Prometheus and Tropos we
    refer to the framework presented by K.H. Dam and
    M. Winikoff in ''Comparing Agent-Oriented
    Methodologies'' 18

26
Comparison (2)
  • GAIA AND TROPOS
  • The Evaluation Framework
  • Properties autonomy, reactiveness, pro
    activeness, sociality
  • Concepts agent, belief, desire, intention
    message, norm, organization, protocol, role,
    service, Society, task
  • Notation and Modeling Techniques properties
    accessibility, analyzability, complexity
    management, executability, expressiveness,
    modularity, preciseness
  • Process development context, life cycle coverage
    (requirements, analysis, design, implementation,
    testing)
  • Pragmatics resources, required expertise,
    language (paradigm and architecture) suitability,
    domain applicability, scalability
  • Metric scale from 1 to 7

27
Comparison (3)
28
Comparison (4)
  • PROMETHEUS AND TROPOS
  • The Evaluation Framework
  • Concepts agents, autonomy, adaptability, mental
    notions (BDI), relationship, communication,
    goals, agent role, capabilities, percepts,
    actions and events
  • Modeling language usability, technical criteria
    ( unambiguity, consistency, traceability)
  • Process enterprise modeling, domain analysis,
    requirements analysis, design, implementation and
    testing
  • Pragmatic management and technical issues

29
Comparison (5)
30
Comparison (6)
31
Comparison (7)
  • PROMETHEUS AND GAIA
  • No existing framework
  • Gaia stresses the role organization
  • Prometheus is more detailed in the definition of
    single agents
  • Prometheus adheres to the BDI model, while Gaia
    does not

32
Useful link (1)
  • http//www.science.unitn.it/recla/aose/
    (contains links to all AOSE methodologies)

33
References (1)
  • 1 M. Wooldridge, Agent-Based software
    engineering, IEE Proc. Software Engineering 144
    (1) (1997) 26-37.
  • 2 G. Booch, Object-Oriented analysis and Design
    with Applications, Addison-Wesley, Reading, MA,
    1994.
  • 3 Birgit Burmeister. Models and methodology for
    agent-oriented analysis and design. In K fischer,
    editor, Working Notes of the KI'96 Workshop on
    Agent-Oriented Programming and Distributed
    Systems, 1996. DFKI.
  • 4 David Kinny, Michael Georgeff, and Anand Rao.
    Amethodology and modelling techniques for systems
    of BDI agents. In W. van der Velde and J.
    Perrram, editors, Agents Breaking Away
    Proceedings of the Seventh European Workshop on
    Modelling Autonomous Agents in a Multi-agent
    World MAAMAW'96, (LNAI Volume 1038).
    Springer-Verlag Heidelberg, Germany, 1996.

34
References (2)
  • 5 B. Moulin and L. Cloutier. Collaborative work
    based on multiagent architectures A
    methodological perspective. In Fred Aminzadeh and
    Mohammad Jamshidi, editors, Soft Computing Fuzzy
    Logic, Neural Networks and Distributed Artificial
    Intelligence, pages 261296. Prentice-Hall, 1994.
  • 6 Bernard Moulin and Mario Brassard. A
    scenario-based design method and an environment
    for the development of multiagent systems. In D.
    Lukose and C. Zhang, editors, First Australian
    Workshop on Distributed Artificial Intelligentce,
    (LNAI volumen 1087), pages 216231.
    Springer-Verlag Heidelberg, Germany, 1996.
  • 7 Elisabeth A. Kendall, Margaret T. Malkoun,
    and Chong Jiang. A methodology for developing
    agent based systems for enterprise integration.
    In D. Luckose and Zhang C., editors, Proceedings
    of the First Australian Workshop on DAI, Lecture
    Notes on Artificial Intelligence.
    Springer-Verlag Heidelberg, Germany, 1996.

35
References (3)
  • 8 Norbert Glaser. Contribution to Knowledge
    Modelling in a Multi-Agent Framework (the CoMoMAS
    Approach). PhD thesis, L'Universtite Henri
    Poincare, Nancy I, France, November 1996.
  • 9Carlos A. Iglesias, Mercedes Garijo, Jose C.
    Gonzalez, and Juan R. Velasco. Analysis and
    design of multiagent systems using
    MAS-CommonKADS. In AAAI'97 Workshop on Agent
    Theories, Architectures and Languages,
    Providence, RI, July 1997. ATAL. (An extended
    version of this paper has been published in
    INTELLIGENT AGENTS IV Agent Theories,
    Architectures, and Languages, Springer Verlag,
    1998.
  • 10 Anne Collinot, Alexis Drogoul, and Philippe
    Benhamou. Agent oriented design of a soccer robot
    team. In Proceedings of the Second International
    Conference on Multi-Agent Systems (ICMAS-96),
    pages 4147, Kyoto, Japan, December 1996.
  • 11 M. Wooldridge, N. R. Jennings and D. Kinny.
    A Methodology for Agent-Oriented Analysis and
    Design. Proceedings of the 3rd International
    Conference on Autonomous Agents (Agents-99),
    Seattle, WA, 69-76. 1999. http//www.ecs.soton.ac.
    uk/nrj/download-files/aa99.ps

36
References (4)
  • 12 F.Zambonelli and N.R.Jennings and
    M.Wooldridge,Developing Multiagent Systems The
    Gaia Methodology,ACM Transactions on Software
    Engineering and Methodology, Vol. 12, No. 3,
    2003. http//polaris.ing.unimo.it/Zambonelli/pubbl
    ica.html
  • 13 L. Padgham and M. Winikoff. Prometheus A
    Methodology for Developing Intelligent Agents.
    Proceedings of the First Intemational Joint
    Conference on Autonomous Agents and Multi-Agent
    Systems (AAMAS 2002). July, 2002, Bologna, Italy.
    http//goanna.cs.rmit.edu.au/winikoff/Papers/aose
    02.pdf 
  • 14J. Mylopoulos, M. Kolp and P. Giorgini. Agent
    Oriented Software Development. Proceedings of the
    2nd Hellenic Conference on Artificial
    Intelligence (SETN-02), April 2002.
    http//dit.unitn.it/tropos/papers_files/hai-jm.pd
    f

37
References (5)
  • 15 P. Bresciani, P. Giorgini, F. Giunchiglia,
    J. Mylopoulos and A. Perini. TROPOS An
    Agent-Oriented Software Development Methodology.
    In Journal of Autonomous Agents and Multi-Agent
    Systems, Kluwer Academic Publishers Volume 8,
    Issue 3, Pages 203 - 236, May 2004.
    http//dit.unitn.it/tropos/papers_files/jaamas04.
    pdf
  • 16 M. Coburn, ''JACK Intelligent Agents User
    Guide,'' AOS Technical Report, Agent Oriented
    Software Pty Ltd, July 2000. http//www.jackagents
    .com/docs/jack/html/index.html.
  • 17 Arnon Sturm and Onn Shehory, A Framework for
    Evaluating Agent-Oriented Methodologies, Workshop
    on Agent-Oriented Information System (AOIS),
    Melbourne, Australia, July 14, 2003.
    http//www.technion.ac.il/sturm/
  • 18 Khanh Hoa Dam, Michael Winikoff, Comparing
    Agent-Oriented Methodologies, to appear in the
    proceedings of the Fifth International
    Bi-Conference Workshop on Agent-Oriented
    Information Systems to be held in Melbourne in
    July (at AAMAS03). http//www.cs.rmit.edu.au/agent
    s/Papers/aois2003.pdf

38
AOSE Gaia
  • Organizational Rules the notation
  • The notation for each type is the temporal logic
    formalism.
  • There is an alternative approach
  • For liveness properties based on regular
    expressions
  • For safety requirements based on constrains over
    the variable listed in a role' s permissions
    attribute
Write a Comment
User Comments (0)
About PowerShow.com