A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

1
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 fausto_at_itc.it -
http//sra.itc.it
2
Outline

• Key ideas
• Modeling language
• case study
• metamodel
• Transformational approach
• case study revisited
• tranformational operators
• composition of transformations intuition
• Conclusion
• Future work
• Related work

3
Key ideas
4
Key ideas

• 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

5
Key ideas (1.1)

• The 5 phases of the Tropos framework
• Early requirements
• Late requirements
• Architectural design
• Detailed design
• Implementation

6
Key ideas (1.2)

• we adopt a requirementsdriven 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

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

7
Key ideas (1.3)
Filling the gap
Agent-oriented programming
i
Early requirements
Late requirements
Detailed design
Architectural design
Implementation
8
Key ideas (2)

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

9
Key ideas (3.1)

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

10
Key ideas (3.2)

• 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

11
Modeling language
12
Modeling languagecase study
13
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).

14
The eCulture system case study Following the 5
phases of the Tropos framework down to the
implementation
Tropos social actors Agents

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

15
Early requirementsMain activities
We analyze the environment (i.e. existing
organizational setting) and model it in terms of
relevant actors and their respective dependencies
16
Early requirementsThe stakeholders of the
eCulture domain
Citizen
Museum
PAT
Visitor
17
Early requirementsThe stakeholders of the
eCulture domain
Citizen
get cultural information
Museum
PAT
increase internet use
Visitor
enjoy visit
18
Early requirementsThe stakeholders of the
eCulture domain
Citizen
taxes well spent
get cultural information
Museum
PAT
increase internet use
Visitor
enjoy visit
19
Early requirementsThe stakeholders of the
eCulture domain
20
Early requirementsGoal-decomposition and
Means-ends analysis for PAT
21
Late requirementsMain activities
We introduce the system actor and analize its
dependencies with actors in its environment
identifying systems functional and
non-functional requirements
22
Late requirementsRationale diagram for eCulture
System
23
Revision of dependencies Early Requirements
revised
Citizen
PAT
24
Late requirementsdependencies with environmental
actors
25
Architectural design Main activities

• 3 steps
• decomposing and refining the system actor diagram
  
• at three different levels of abstraction
• identifying capabilities
• from actors to agents

26
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

27
Architectural design (step 1) taking into
account functional requirements eCulture System
decomposition into sub-actors
28
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

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

• identifying actor capabilities from the analysis
  of dependencies in the actor diagram
• an intuitive idea of this process

31

Architectural design (step 2) Actor capabilities
32

Architectural design (step 2) Actor capabilities
33
Architectural design (step 2) Actor capabilities
34
Architectural design Step 3
from actors to agents .
35
Architectural design (step 3) from actors to
agents
36
Architectural design (step 3) from actors to
agents
37
Detailed design Main 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
38
Detailed design BDI platform case

• We model
• capabilities
• capability diagrams (currently AUML activity
  diagrams)

39
Detailed design Capability diagram
40
Detailed design BDI platform case

• We model
• capabilities
• capability diagrams (currently AUML activity
  diagrams)
• plans
• plan diagrams (currently AUML activity diagrams

41
Detailed design Plan diagram - plan evaluate
query
42
Detailed design BDI 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

43
Detailed designAgent interaction diagram
44
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.
45
ImplementationJack Intelligent system, AOS
46
Modeling languagemetamodel
47
Metamodel

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

48
Metamodelactors, goals, softgoals,

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

49
Metametamodel Entity
50
Metametamodel N-ary Relatioship
51
Metamodel Actor
52
Metamodel Goal
53
Metamodel Plan
54
Transformational approach
55
case study revisited early requirement again
taxes well spent
citizen
PAT
get cultural information
3
get cultural information
4
1
buy eCulture system
build eCulture system
5
visit web site
visit cultural institution
7
provide eCult. services
2
good services
6
interenet available
eCulture sys. available
eCulture sys. available
8
good cultural services
56
transformational operators
and so on ...
57
composition of primitives intuition
citizen
PAT
get cultural information
good services
good cultural services
58
composition of primitives intuition

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

59
Conclusion
60
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

61
Related work
62
Related work

• AOSE
• OOP
• Requirement engineering

63
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
64
Future work
65
Future work

• Formal Tropos
• Architectural patterns
• Formalization of the transformational approach
  (primitives and strategies)

66
The Tropos group

• Fausto Giunchiglia, Paolo Giorgini, Fabrizio
  Sannicoló
• University of Trento - Dept. of information and
  communication technology
• Paolo Bresciani, Anna Perini, Marco Pistore,
  Paolo Traverso
• SRA 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, Brazil
• Daniel Gross, Linda Lin Faculty of information
  Studies, University of Toronto

67
The Tropos 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