A knowledge level software engineering methodology for agent oriented programming
Sponsored Links
This presentation is the property of its rightful owner.
1 / 66

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on
  • Presentation posted in: General

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. The Tropos framework. Fausto Giunchiglia Dept. of Information and Communication Technology University of Trento SRA Division - ITC-irst Trento [email protected] - http://sra.itc .it. Outline. Key ideas

Download Presentation

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

The Tropos framework

Fausto Giunchiglia

Dept. of Information and Communication TechnologyUniversity of Trento

SRA Division - ITC-irstTrento

[email protected] - http://sra.itc.it


Outline

  • Key ideas

  • Modeling language

    • case study

    • metamodel

  • Transformational approach

    • case study revisited

    • transformation operators

    • composition of transformations: intuitions

  • Conclusion

  • Future work

  • Related work


Key ideas


Key ideas

The Tropos framework rests on three key ideas:

  • Consider the overall software development process, from early requirements down to implementation

  • Use the notion of agent and all the related mentalistic notions in all phases of software development

  • Adopt a transformational approach, namely perform refinement steps, inside one phase or between phases, using a set of transformation operators


Key ideas (1.1)

5 phases:

  • Early requirements

  • Late requirements

  • Architectural design

  • Detailed design

  • Implementation


Key Ideas (1.2): AOSE approaches

Development process methodologies, organizational analysis ontology

Extension of OO specification languages - methodologies

MSEM, Wood et al.

AAII, Kinny et al.

AUML, Odell et al.

Gaia, Wooldridge, et al.

Tropos

Early

requirements

Late

requirements

Detailed

design

Architectural

design

Implementation


Key ideas (2.1)

  • we adopt a requirements­driven software development approach, exploiting goal analysis and actor dependencies analysis techniques

    (i* by E. Yu, NFR by Chung et al., Kaos by Dardenne et al.)

Model the what, how and the why


Key ideas (2.2)

Filling the gap

Agent-oriented

programming

i *

Early

requirements

Late

requirements

Detailed

design

Architectural

design

Implementation


Key ideas (2.3)

  • Notions of agent and goal are used along all the development phases.

  • The key elements and dependencies describing the organizational setting can be used to and motivate design and implementation choices. Each artifact (including code) can be retraced back to the analysis performed during requirement phases.

  • There is a direct and natural correspondence between requirement analysis (social actors) and implemented code (software agents).


Key ideas (3.1)

We adopt a transformational approach:

  • start with a limited list of Tropos conceptual elements (actors, goals, softgoals,...)

  • iteratively and incrementally:

    • add details

    • revise dependency relationships

      Each step corresponds to the introduction/deletion of relationships/elements in the model.


Key ideas (3.2)

Advantages of the approach :

  • provides systematic description of the process

  • allows for processanalysis

  • provides guidelines to the engineer

  • provides a sound basis for describing and evaluating requirement acquisition and design strategies


Modeling language


Modeling languagecase study


The eCulture system case study

  • a web-based broker of cultural information and services for the province of Trentino

  • usable by a variety of users (e.g.Trentinos, tourists, scholars and students).


The eCulture system case study… following the 5 phases of the Tropos framework

  • Early requirements

  • Late requirements

  • Architectural design

  • Detailed design

  • Implementation

Tropos social actors

Agents


Early requirementsMain activities

  • We analyze the environment (i.e. existing organizational setting)and model it in terms of relevant actors and their respective dependencies


Early requirementsThe stakeholders of the eCulture domain

Citizen

Museum

PAT

Visitor


Early requirementsThe stakeholders of the eCulture domain

Citizen

get cultural information

Museum

PAT

increase internet use

Visitor

enjoy visit


Early requirementsThe stakeholders of the eCulture domain

Citizen

taxes well spent

get cultural information

Museum

PAT

increase internet use

Visitor

enjoy visit


Early requirementsThe stakeholders of the eCulture domain


Early requirementsBalloon: goal-decomposition andMeans-ends analysis for PAT


Late requirementsMain activities

  • We introduce the system actor and analize its dependencies with actors in its environment identifying system’s functional and non-functional requirements


Late requirementsRationale diagram for eCulture System


get cultural information

get cultural information

eCulture

System

eCulture sys.available

eCulture sys.available

Revision of dependencies Early Requirements revised

Citizen

PAT


Late requirementsdependencies with environmental actors


Architectural designMain activities

  • 3 steps:

    • decomposing and refining the system actor diagram

      • … at three different levels of abstraction

    • identifying capabilities

    • from actors to agents


Architectural design: step 1

  • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals

  • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals

  • b:inclusion of new actors according to the choice of a specific architectural style (design patterns)

  • c:inclusion of new actors contributing positively to the fulfillment of someNon Functional Requirements


Architectural design(step 1)taking into account functional requirements : decomposition into sub-actors


Architectural design: step 1

  • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals

  • b:inclusion of new actors according to the choice of a specific architectural style (design patterns)

  • c:inclusion of new actors contributing positively to the fulfillment of someNon Functional Requirements


Architectural design(step 1)extending actor diagram taking into account architectural styles - the Info Broker


Architectural designStep 2

  • identifying actor capabilities from the analysis of dependencies in the actor diagram

  • …an intuitive idea of the process


Architectural design(step 2)Actor capabilities


Architectural design(step 2)Actor capabilities


Architectural design(step 2)Actor capabilities


Architectural designStep 3

from actors to agents ….


Architectural design(step 3)from actors to agents


Architectural design(step 3)from actors to agents


Detailed designMain activities

Specification of the agents’micro level

taking into account the implementation platform.

Objective: to perform a design that will map directly to the code.

We consider a BDI multiagent platform, so …


Detailed designBDI platform case

  • We model:

    • capabilities

      • capability diagrams (currently AUML activity diagrams)


Detailed designCapability diagram


Detailed designBDI platform case

  • We model:

    • capabilities

      • capability diagrams (currently AUML activity diagrams)

    • plans

      • plan diagrams (currently AUML activity diagrams


Detailed designPlan diagram - plan evaluate query


Detailed designBDI platform case

  • We model:

    • capabilities

      • capability diagrams (currently AUML activity diagrams)

    • plans

      • plan diagrams (currently AUML activity diagrams

    • agents interaction

      • agent interactions diagrams (currently AUML sequence diagrams


Detailed designAgent interaction diagram


Implementation Main activities

… follow step by step the detailed design specification …

In JACK (BDI multiagent platform)agents are autonomous softwarecomponents that have explicit goals (desires), events to handle, beliefs and capabilities. Agents are programmed with a set of plans that make them capable of achieving goals.


ImplementationJack Intelligent system, AOS


Modeling Language

Metamodel


Modeling language

So far only for early and late requirement diagrams

Tropos conceptual entities (actors, goals, …) are instances of classes in a (meta)metamodel described by UML class diagrams.


MetametamodelEntity


Metametamodel N-ary Relatioship


Metamodel Actor


Metamodel Goal


Metamodel Plan


Transformational approach


eCulture sys.

available

eCulture sys.

available

Case study revisited: early requirements again

taxes well

spent

citizen

PAT

get cultural

information

3

get cultural

information

4

1

buy eCulture

system

build eCulture

system

5

visit cultural

institution

visit web

site

7

provide eCult.

services

2

good

services

6

interenet

available

eCulture sys.

available

eCulture sys.

available

8

good cultural

services


Transformational operators

and so on ...


taxes well

spent

eCulture sys.

available

6

7

4

buy eCulture

system

build eCulture

system

taxes well

spent

8

visit cultural

institution

visit web

site

1

provide eCult.

services

5

3

interenet

available

eCulture sys.

available

eCulture sys.

available

2

Composition of operators: intuitions

citizen

PAT

get cultural

information

good

services

good cultural

services


Composition of operators: intuitions

  • Different transformation sequences may have different chances to lead to a satisfactory design;

  • even when the same design is obtained, different transformation sequences in the design process may lead at discovering/facing/discarding relevant elements at different times;

  • different analyses may have different costs;

  • balancing analysis costs and good results is a hard (human) planning task.


Conclusion


Conclusion

The Tropos framework is a novel approach in Agent Oriented Software Engineering, resting on the following 3 key ideas:

  • the Tropos approach framework spans the overall software development process, from early requirements down to implementation

  • we use the notion of agent and all the related mentalistic notions in all phases of software development

  • we adopt a transformational approach, i.e., we perform refinement steps, inside one phase or between phases, using a set of transformation operators


Related work


Related work

AOSE

OOP

Requirement engineering


Future work


Future work

  • Formal Tropos

  • Architectural patterns

  • Formalization of the transformational approach (primitives and strategies)


The Tropos group

Fausto Giunchiglia, Paolo Giorgini, Fabrizio Sannicoló

University of Trento, Trento

Paolo Bresciani, Anna Perini, Marco Pistore, Paolo Traverso

SRA Divisionat ITC-IRST, Trento

John Mylopoulos, Eric Yu, Manuel Kolp, Luiz Cysneiros, Ariel D. Fuxman, Daniel Gross, Linda Lin

University of Toronto, Toronto

Yves Lespérance York University, Toronto

Jaelson Castro Universidade Federale de Pernambuco, Recife, Brazil


The Tropos frameworkwhere to find what I talked about

[1]A. Perini, P. Bresciani, F. Giunchiglia, P. Giorgini and J. Mylopoulos, A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. Proc. ACM Int. Conf. Agents 2001

[2]P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, J. Mylopoulos, Modeling early requirements in Tropos: a transformation based approach. AOSE workshop at Conf. Agents 2001, LNAI Lectures Notes

[3]P. Giorgini, A. Perini, J. Mylopoulos, F. Giunchiglia, P. Bresciani. Agent-Oriented Software Development: A Case Study. Proc. Int. Conf. on Software Engineering & Knowledge Engineering (SEKE01), 2001

[4]A. Fuxman, M. Pistore, J. Mylopoulos, P. Traverso.Model Checking Early Requirements Specifications in Tropos. IEEE Int. Symp. on Requirements Engineering, 2001

[5]M. Kolp, P. Giorgini, J. Mylopoulos. A Goal-Based Organizational Perspective on Multi-Agent Architectures.Int. Workshop ATAL-2001, LNAI Lecture notes


  • Login