A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

ATAL - Seattle, August 1st, 2001 1

A Knowledge Level Software Engineering A Knowledge Level Software Engineering Methodology for Agent Oriented Methodology for Agent Oriented

ProgrammingProgramming

The Tropos framework

Fausto GiunchigliaDept. 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– tranformational operators– composition of transformations: intuition

• Conclusion• Future work• Related work


Key ideas


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

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

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

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

Key ideasKey ideas


Key ideas (1.1)Key ideas (1.1)

The 5 phases of the Tropos framework:

• Early requirements• Late requirements• Architectural design• Detailed design• Implementation


– 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 whywhy

– the conceptual notions thus introduced are used along the whole development process



Filling the gap

Early

requirements

Late

requirements

Architectural

design Detailed

design

Implementatio

n

i *Agent-orientedprogramming



• The notion of agent and goal is used along all the phases, therefore the key elements and dependencies describing the organizational setting can be used to justify and motivate each design and implementation choice.

• 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). System behaviour is easier to understand, explain, motivate.

Key ideas (2)Key ideas (2)


We adopt a transformational approach:(for early and late requirements, and partially for the architectural design)

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



Advantages of the (transformational) approach :

• provides systematic description of the process• allows for process analysis• provides guidelines to the engineer• provides a sound basis for describing and evaluating

requirement acquisition and design strategies



Modeling languageModeling language


Modeling languageModeling languagecase studycase 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 studyThe eCulture system case study


The eCulture system case studyThe eCulture system case study Following the 5 phases of the Tropos framework down to the implementation

•Early requirements•Late requirements•Architectural design•Detailed design

•Implementation

Tropos social actors

Agents


We analyze the environmentenvironment (i.e. existing organizational setting) and model it in terms of relevant actorsrelevant actors and their respective dependenciesdependencies

Early requirementsEarly requirementsMain activities


Early requirementsEarly requirementsThe stakeholders of the eCulture domain

PAT

Museum

Citizen

Visitor



PAT

Museum

Citizen

Visitor

get cultural information

increase internet

use

enjoy visit



PAT

Museum

Citizen

Visitor


increase internet

use

taxes well spent

enjoy visit




Early requirementsEarly requirementsGoal-decomposition and Means-ends analysis for PAT


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

Late requirementsLate requirementsMain activities


Late requirementsRationale diagram for eCulture System


Revision of dependencies Revision of dependencies Early Requirements revised

PAT

Citizen eCulture sys. available


eCulture sys. available


eCultureSystem


Late requirementsLate requirementsdependencies with environmental actors


Architectural designArchitectural design Main activities

3 steps:

1. decomposing and refining the system actor diagram

… at three different levels of abstraction

2. identifying capabilities

3. from actors to agents


Architectural design: Architectural design: step 1step 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

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


Architectural designArchitectural design (step 1) taking into account functional requirements : eCulture System decomposition into sub-

actors


Architectural design: Architectural design: step 1step 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 designArchitectural design (step 1) extending actor diagram taking into account architectural styles - the Info BrokerInfo Broker


Architectural designArchitectural design Step 2

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

…an intuitive idea of this process


Architectural designArchitectural design (step 2) Actor capabilities


Actor Name

Capability #

Area Classifier

1) Get area specification form

2) Classify area3) Provide area

information4) Provide service

description




Actor Name Capability #Area Classifier 1) Get area specification form

2) Classify area3) Provide area information4) Provide service description

Info Searcher 5) Get area information6) Find information source7) Compose query8) Query source9) Provide query information Provide service description

Results Synthesizer 10) Get query information11) Get query results12) Provide query results13) Synthesize area query results Provide service description

Sources Interface Manager 14) Wrap information source

User Interface Manager 15) Get user specification16) Provide user specification 17) Get query results18) Present query results to the user Provide service description


Architectural designArchitectural design Step 3

from actors to agents ….


Actor Name Capability #Area Classifier 1) Get area specification form

2) Classify area3) Provide area information4) Provide service description

Info Searcher 5) Get area information6) Find information source7) Compose query8) Query source9) Provide query information Provide service description

Results Synthesizer 10) Get query information11) Get query results12) Provide query results13) Synthesize area query results Provide service description

Sources Interface Manager 14) Wrap information source

User Interface Manager 15) Get user specification16) Provide user specification 17) Get query results18) Present query results to the user Provide service description

Architectural designArchitectural design (step 3) from actors to agents


Architectural designArchitectural design (step 3) from actors to agents

Agent Name Capability #

Query Handler 1) Get area specification form3) Provide area information4) Provide service description 5) Get area information7) Compose query8) Query source9) Provide query information 10) Get query information11) Get query results12) Provide query results

Classifier 2) Classify area4) Provide service description

Searcher 4) Provide service description 6) Find information source

Synthesizer 13)Synthesize area query results14)Provide service description

User Interface Agent 15, 16, 17, 18, 4

Wrapper 14, 4


Detailed designDetailed design Main activities

Specification of the agents’ micro leveltaking 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 designDetailed design BDI platform caseBDI platform case

We model:

• capabilities– capability diagrams (currently AUML

activity diagrams)


Detailed designDetailed design Capability diagram



We model:


activity diagrams)

• plans– plan diagrams (currently AUML activity

diagrams


Detailed designDetailed design Plan diagram - plan evaluate query



We model:


activity diagrams)

• plans– plan diagrams (currently AUML activity

diagrams

• agents interaction– agent interactions diagrams (currently

AUML sequence diagrams


Detailed designDetailed designAgent interaction diagram


Implementation Implementation Main activities

… follow step by step the detailed design specification …

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


ImplementationImplementationJack Intelligent system, AOS


Modeling languageModeling languagemetamodelmetamodel


A detailed definition is available for the early and late requiremet models.

Tropos conceptual entities (actors, goals, softgoals, …) of a tropos model are seen as instances of classes in a metamodel described by UML class diagrams.

MetamodelMetamodel


Actor: the actor is the central primitive notion in Tropos. It corresponds both to human stakeholders (single persons and organizations) and artificial agents (software and hardware systems and components).

Goal: actors may depends each other in order to attain some goal. The depending actor is called depender, and the actor that is depended upon is called dependee. The object of the dependency is called dependum.

…

MetamodelMetamodelactors, goals, softgoals, …


Language Element

Actor

EntitySystem Formula

PlanGoal

Attribute

Basic

ResourceDependency

invariant

creation

fulfillment

0..n

fulfillment

N-ary Relationship

MetametamodelMetametamodel Entity


Metametamodel Metametamodel N-ary Relatioship

N-ary Relationship

ContributionDependency

Language Element

AND-OR decomposition Means-Ends Analysis


Metamodel Metamodel Actor

DependencyActordependee

depender

Resource PlanGoal

Belief

has

wantedby

dependum dependumdependum

0..n

1..n

wants0..n

0..narebelieved

{XOR}


Metamodel Metamodel Goal

Means-Ends analysis

Resource

Hardgoal

Goal

Plan

Softgoal

Contribution

0..nend

means0..n

root

pointview

means means

0..n 0..ncontributes to

contributed by

AND-OR decomposition

Actor

OR-decomposition AND-decomposition0..n

0..n

1..n

pointviewpointview

e.g.,++,+,-,--,...

child

child


Metamodel Metamodel Plan

Means-Ends analysis

Resource

Plan0..n end

means0..n

root

pointview

means

0..n

AND-OR decomposition

Actor

1..n

is capable ofpointview

Hardgoal

1..n

fulfills

OR-decomposition AND-decomposition0..n

0..n

child

child


Transformational Transformational approachapproach


case study revisited: case study revisited: early requirement againearly requirement again

citizen

taxes wellspent

PAT

visit website

visit culturalinstitution

interenetavailable

buy eCulturesystem

build eCulturesystem

provide eCult.services

good culturalservices

goodservices

get culturalinformation

eCulture sys.available





1

2

34

5

6

7

8


transformational operators


composition of primitives: intuitioncomposition of primitives: intuition

citizen PAT

taxes wellspent

visit website

visit culturalinstitution

provide eCult.services

good culturalservices

goodservices

buy eCulturesystem

build eCulturesystem


interenetavailable




4

5

67

8

3

1

2

taxes wellspent


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

composition of primitives: intuitioncomposition of primitives: intuition


ConclusionConclusion


ConclusionConclusion

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 workRelated work


Related workRelated work

1) AOSE2) OOP3) Requirement engineering


AOSE approachesAOSE approaches

Early

requirements

Late

requirements

Archite

ctural

design Detaile

d

design

Implementatio

n

Tropos Gaia, Wooldridge, et al.

AUML, Odell et al.AAII, Kinny et al.

Development process methodologies, organizational analysis ontology

Extension of OO specification languages - methodologies

MSEM, Wood et al.


Future workFuture work


Future workFuture work

• Formal Tropos

• Architectural patterns

• Formalization of the transformational approach (primitives and strategies)


The The TroposTropos group group

Fausto Giunchiglia, Paolo Giorgini, Fabrizio Sannicoló University of Trento - Dept. of information and communication technology

Paolo Bresciani, Anna Perini, Marco Pistore, Paolo TraversoSRA Division at ITC-IRST

John Mylopoulos, Eric Yu, Manuel Kolp, Luiz Cysneiros, Ariel D. Fuxman Computer Science Dept. - University of Toronto

Yves Lespérance York University, Toronto Jaelson Castro Universidade Federale de Pernambuco, Recife, BrazilDaniel Gross, Linda Lin Faculty of information Studies, University of Toronto


The The TroposTropos framework framework where 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. 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

[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. Proc. Int. Workshop ATAL-2001

Date post:	18-Mar-2016
Category:	Documents
Upload:	astin
View:	56 times
Download:	6 times

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

Documents