tropos metamodel and its use

Informatica 25 page xxx–yyy 1

The Tropos Metamodel and its Use

Angelo Susi and Anna Perini and John MylopoulosITC-irst, Via Sommarive, 18, I-38050 Trento-Povo, [email protected], [email protected], [email protected]

Paolo GiorginiDepartment of Information and Communication TechnologyUniversity of Trento, via Sommarive 14, I-38050 Trento-Povo, [email protected]

Keywords: Agent Oriented Software Engineering Methodology, Metamodel

Received: May 9, 2005

Tropos is a software development methodology founded on the key concepts of agent-

oriented software development. Specifically, Tropos emphasizes concepts for modelling

and analysis during the early requirements phase. This phase precedes the prescriptive

requirements specification of the system-to-be. In this paper, we present the Troposmetamodel starting from the basic concepts of actor, goal, plan, resource and social

dependency and then we illustrate its use by introducing an extension intended to in-

troduce concepts for modelling security concerns. We also sketch the Tropos modelling

environment and compare with the metamodels of other software development method-

ologies.

1 Introduction

Software development paradigms have exploiteda wealth of models to capture requirements anddesign information about a software system (the“system-to-be”) throughout its development pro-cess. Structured software development usedSADT and Data Flow Diagrams. Object-orientedsoftware development has used a range of mod-elling languages which have been integrated intoUML. Not surprisingly, agent-oriented softwaredevelopment is following on the same footsteps.

To formally analyze software models, we needa means to define their syntax and semantics.Metamodels have been used for the former task.Metamodels define a set of possible instantiations,which are all and only the syntactically correctmodels in some modelling language. As such,metamodels have been used for more than twodecades as a basis for defining the syntax of (usu-ally graph-theoretic) modelling languages, such asUML as well as Tropos.

The objective of this paper is to introduce theTropos metamodel, discuss some of its uses, and

compare it to other metamodels of agent/goal-oriented software development methodologies.Section 2 of the paper sketches the Troposmethodology, while Section 3 presents the meta-model and explains its features. Section 4presents one extension of the metamodel to in-clude security-related concepts. In Section 5we sketch the Tropos development environment,which uses the metamodel in its basic core. Sec-tion 6 relates the proposed metamodel to othersin the same family of modelling languages, whileSection 7 concludes the paper.

2 Models and Methodology

Tropos is founded on the idea of using the agentparadigm and related mentalistic notions duringall phases of the development software process.The methodology [6] adopts the i* [26] modellingframework, which proposes the concepts of (so-cial) actor, goal, task, resource and social de-pendency to model both the system-to-be andits organizational operating environment. Thei* framework includes the strategic dependency

2 Informatica 25 page xxx–yyy A. Susi et al.

model (actor diagrams in Tropos) for describingthe network of inter-dependencies among actors,as well as the strategic rationale model (goal di-agrams in Tropos) for describing and supportingthe means-ends analysis conducted by each actoras it attempts to ensure that – through delega-tions to other actors – its goals will eventually befulfilled.

An actor diagram is a graph whose nodes rep-resent actors (agents, positions, or roles), whileedges represent dependencies among them. A de-pendency represents an agreement between twoactors where one actor (the depender) dependson another (the dependee) to fulfill a goal, per-form a task or deliver a resource (the dependum).Dependencies may also involve softgoals (such as“having a good quality meeting”) which representvaguely-defined goals, with no clear-cut criteriafor their fulfillment.

A goal diagram is also a graph where nodesrepresent goals or plans1, while edges repre-sent goal/plan relationships, such as AND/OR-decomposition (i.e., a goal/plan can be decom-posed into a set of other goals/plans. Goals/planscan also be related to softgoals through qualita-tive relationships (labelled “+” or “-”) to indicatethat the goal/plan contributes positively or neg-atively to the fulfillment of the softgoal. Goaldiagrams appear inside a balloon associated witha single actor. This is the actor whose goals/plansare being analyzed to determine how they can befulfilled/executed.

The Tropos methodology supports four phasesof software development: Early RequirementsAnalysis, Late Requirements Analysis, Architec-tural Design, and Detailed Design. Early require-ments is concerned with understanding the or-ganizational context within which the system-to-be will eventually function. During early require-ments analysis, the requirements engineer identi-fies the domain stakeholders (who have a stake inthe system-to-be) and models them as social ac-tors, who have goals and depend on each other forgoals to be fulfilled, plans to be performed, and re-sources to be furnished. Late requirements, on theother hand, is concerned with a definition of thefunctional and non- functional requirements of thesystem-to-be. This is accomplished by treatingthe system as another actor (or a small number

1Plans in Tropos correspond to tasks in i*.

of actors) who are dependers/dependees in depen-dencies that relate them to external actors. Theshift from early to late requirements occurs whenthe system actor is introduced and it participatesin delegations from/to other actors.

Architectural design is concerned with theglobal structure of the system-to-be. Unsurpris-ingly, subsystems and system components are rep-resented as actors too, and their dependencies toother system components are social, rather thanprocedural/structural. This means that systemcomponents need to have the ability to monitordependencies to other actors to make sure theywill be fulfilled. As well, system components needto be able to cancel dependencies that seem inef-fective and replace them with new ones throughplanning, negotiation, etc. As with conventionalsoftware architectures, architectural styles consti-tute critical support for the software developer.Since the fundamental concepts of Tropos archi-tectures are intentional and social, we have turnedto theories which study social structures to definearchitectural styles: namely Organization Theoryand Strategic Alliances.

Detailed design focuses on the specification ofactor communication and behavior. To supportthis phase, we have adopted existing agent com-munication languages such as FIPA-ACL [20] orKQML [11]; also message transportation mecha-nisms and other related concepts and tools. Wehave also proposed and defined a set of stereo-types, tagged values, and constraints to accom-modate Tropos concepts within UML [5].

Through the models constructed during thesephases, one can answer “why” questions, in addi-tion to “what” and “how” ones, regarding systemfunctionality. For example, one can ask “Whydoes this component of the system need to no-tify library users when a book becomes avail-able”. Answers to why questions ultimately linksystem functionality to stakeholder needs, prefer-ences and objectives. Such answers serve as ulti-mate justifications for all elements of a proposeddesign.

3 The Metamodel

Figure 1 shows the portion of the Tropos meta-model, where agent, role and position are spe-cialization of the concept of actor. A position

THE Tropos METAMODEL AND ITS USE Informatica 25 page xxx–yyy 3

Actor Dependency

Goal

Plan

Resource

SoftGoalHardGoal

depender

dependee

1

0..n

0..n

wants 0..n

wantedBy1

dependum

dependum

dependum

1

1

1

0..1 0..1 0..11

executedBy

execute 0..n

why

why

why

0..1

0..1

0..1

0..n1

{XOR}

0..n

0..n

{XOR}

RoleAgentPosition

playoccupy1..n

cover

0..n0..n

0..n0..n

Figure 1: The UML class diagram specifying the actor concept and the dependency relationship inthe Tropos metamodel. UML notation is compliant with the OMG MOF 1.4.

reviewpapers

Reviewer

PCChair

reviewform

PCMember

reviewthe

papers

assignedpapersactor goal

resource

KEY

dependumdepender dependee

be fair in reviews

assignment

papers

conflicts conflicts

softgoal

reviewform

plan

Figure 2: The Tropos actor diagram describing asketch of the conference review process.

can cover 1 . . . n roles, whereas an agent can play0 . . . n roles and can occupy 0 . . . n positions. Anactor can have 0 . . . n goals, which can be bothhard and softgoals and are wanted by 1 actor.

An actor dependency is a quaternary relation-ship and relates respectively a depender, de-pendee, and dependum (i.e. goal, plan, resource).It is possible to specify also a reason for the de-pendency (labeled as why).

A model is an instance of the metamodel andcan have a graphical representation in terms ofactor and goal diagrams.

Figure 2 depicts an example of an actor dia-gram for the domain of the Conference ReviewProcess and represents a model that can be ob-tained instantiating the metamodel discussed so

far. Three actors are involved: the Program Com-mittee Chair (PC Chair), the Program Commit-tee Member (PC Member) and the Reviewer. De-pendencies take place between them; in particularthe goal review papers is delegated by the PC

Chair to the PC Member, moreover the PC Chair

also expects to have the information of the possi-ble conflicts (a resource dependency) betweenthe PC Member and the authors of the papers. Onthe other hand, the PC Member depends on the PCChair to obtain the papers to distribute and thereview form. Many critical goal and resourcedependencies occur between the PC Member andthe Reviewer. In particular, the PC Member de-pends on the Reviewer for review the papers

and to obtain the information about the possibleconflicts on assigned papers. The Reviewer

depends on the PC Member in order to obtain a setof assigned papers as well as the review form.Finally, the PC Member wants to be fair in the

review assignment, and this is represented as asoftgoal wanted by the PC Member.

The concepts related to the Tropos goal dia-gram are depicted in Figure 3. The central con-cept of goal is represented by the class Goal.Goals can be analyzed, from the point of viewof an actor, by Means-end analysis, Contributionanalysis and Boolean decomposition. Means-endAnalysis is a ternary relationship defined amongan Actor, whose point of view is represented inthe analysis, a goal (the end), and a Plan, Re-


Actor Decomposition

Goal

Plan

Resource

Boolean Decomposition+Type: String

Contribution+Metric: String

Means-End Analysis

0..n

1

1

1

pointOfView

pointOfView

pointOfView1

1

1

contributeTo

contributeTo

contributeTo

contributedBy1

0..n

0..n

0..n

0..n 0..n

1

0..n

end

means0..n 1 1

end1

0..n means 0..n

1

1

root

root

0..n 0..n0..n 0..n{XOR}

{XOR}

Figure 3: The UML class diagram specifying the concepts related to the goal diagram in the Troposmetamodel.

reviewpapers

collectthe

reviews

PCMember

assignpapers toreviewers

AND decomposition

contribution (positive)

+KEY

++

be fair in reviews

assignment

Reviewer

conflictsreviewthe

papers

selectreviewers

sendthe papers

verifyconflicts

verifycompetences

sendpapers by

e-mail

Means-end analysis

Figure 4: The Tropos goal diagram related to theactor PC Member.

source or Goal (the means). Contribution Anal-ysis is a ternary relationship between an actor,whose point of view is represented, and two goals.Contribution analysis strives to identify goals thatcan contribute positively or negatively towardsthe fulfillment of other goals (see association rela-tionship labeled contribute in Figure 3). A contri-bution can be annotated with a qualitative met-ric, as proposed in [8], denoted by +,++,−,−−.In particular, if the goal g1 contributes positivelyto the goal g2, with metric ++ then if g1 is sat-isfied, so is g2. Analogously, if the plan p con-tributes positively to the goal g, with metric ++,

this says that p fulfills g. A + label for a goalor plan contribution represents a partial, positivecontribution to the goal being analyzed. Withlabels −−, and − we have the dual situation rep-resenting a sufficient or partial negative contri-bution towards the fulfillment of a goal. Decom-position, whose metamodel is described in Fig-ure 3, is also a ternary relationship which defines ageneric boolean decomposition of a root goal intosubgoals, that can be in particular an AND- oran OR-decomposition specified via the attributeType in the class Boolean Decomposition special-ization of the class Decomposition.

The concept of plan in Tropos is specifiedin Figure 2 and 3. Means-end analysis andAND/OR decomposition, defined above for goals,can be applied to plans also. In particular,AND/OR decomposition allows for modelling theplan structure.

Figure 4 gives a sketchy view of goal dia-gram for the actor PC Member and for the goalreview papers and for the softgoal be fair in

the review assignment.

The goal review papers has been AND-decomposed in two sub goals: assign papers

to reviewers and collect the reviews. Thislatter represents the “Why” for the depen-dency review the papers between PC Member

and Reviewer, as shown in Figure 1. The goalassign papers to reviewers is decomposed intwo subgoals: send the papers, that is op-


erationalized as send papers by e-mail, andselect reviewers decomposed in verify the

competences and verify conflicts. This lat-ter represents the “Why” for the resource de-pendency conflicts between the PC Member andthe reviewer. Moreover, the fulfillment of thesetwo sub-goals can contribute positively to the ful-fillment of the softgoal be fair in the review

assignment as described by the positive contri-bution relationships in the diagram.

4 Metamodel Extension

Secure Tropos has been proposed in [16] as a for-mal framework for modelling and analyzing se-curity. It enhances Tropos introducing four newconcepts and relationships behind Tropos depen-dency: trust, delegation, provisioning, and own-ership. The basic idea of ownership is that theowner of a resource (goal or plan) has full au-thority concerning access and disposition of hisresource (goal or plan). The distinction betweenowning a resource makes it clear how to modelsituations in which, for example, a client is thelegitimate owner of his/her personal data and aWeb Service provider that stores customers’ per-sonal data, provides the access to her/his data.We use the relation for delegation when in thedomain of analysis there is a formal passage ofauthority (e.g. a signed piece of paper, a digitalcredential is sent, etc.). The trust relations havetheir intuitive meaning among agents, namely thebelieve of an agent that the actor does not misusesome resources.

Figure 5 shows the the new part of the Tro-pos metamodel concerning trust and ownership.An actor (the truster) trusts another actor (thetrustee) about the achievement of a goal, the ful-fillment of a plan or the delivering of a resource.The content of the trust relationship is calledtrustum. An actor can be the owner of a resource,a plan and goal and he/she has authority concern-ing the use of the resource, the execution of theplan and achievement of the goal, respectively.

The metamodel describing delegation relation-ships is basically identical to the metamodel forthe dependency relationship as presented in Fig-ure 1. The delegater delegates the delegatee forthe achievement of a goal, the execution of a planor the delivering of a resource. As for the de-

Actor Trust

Goal Plan Resource

truster

trustee

1

0..n

0..n

trustum

0..1 0..1 0..1

1

{XOR}

trustum1 1 1 trustum

0..n 0..n 0..n

1 ownedBy

owns owns owns

Figure 5: The Tropos metamodel related to theconcept of Trust.

pendency relationship, it is also possible here tospecify the reason (why) of a delegation.

We have shown in [17] how the original conceptof Tropos dependency can be expressed in termsof trust and delegation. Roughly, when an actordepends on another actor to achieve a goal (tofulfill a task or to deliver a resource), it is implic-itly intended that the actor trusts the other actorand delegates it for such activities. A precise for-malization of dependency refinement in terms oftrust and delegation has been presented in [17].

Figure 6 presents an example of application theextended metamodel. The Author trusts the PC

Chair to implement a fair review process

and he/she is the owner of the paper sent to thePC Member and reviewed by the Reviewer. ThePC Chair trusts and delegates PC Member to re-view a certain number of papers, and in turn thePC Member trusts and delegates the Reviewer toreview the papers. The PC member (Reviewer)depends on the PC Chair (PC Member) to receivethe paper to review.

reviewpapers

Reviewer

PCChair

PCMember

reviewthe

papers

assignedpapers

papers

Author

implement a fair review

process

T

T

(T,Del) (T,Del)

OO

(T,Del)

(T,Del)

Figure 6: The Tropos actor diagram with thetrust concepts.


5 A Modelling Environment

In order to support the specific analysis tech-niques adopted in Tropos, different tools havebeen developed, such as a tool for the verifica-tion of requirements specification through model-checking technique (T-Tool) [13], a tool whichsupports forward and backward reasoning onthe goal analysis structures (GR-Tool) [15]. Inthis section, we will give details of a modellingenvironment, called TAOM4e (Tool for Agent-Oriented Modelling for Eclipse), which is based onan implementation of the metamodel described inthe previous sections. The metamodel has beenspecified following the OMG’s MDA [21] standardfor metamodel interoperability, that is the MetaObject Facility (MOF)2 which offers a mecha-nism for automatically deriving a concrete syn-tax based on XML DTDs and/or schemas knownas XML Model Interchange (XMI). This is a pre-liminary step towards the adoption of the model-to-model transformation approach proposed byMDA.

Among the main requirements we considered indeveloping this tool are the following [23]:

– Visual Modelling. The modelling environ-ment should support the user during thespecification of an AO model (e.g., accord-ing to the Tropos visual notation). Moreover,the environment should allow us to representnew entities that will be included in the Tro-pos metamodel, language variants, such asthose presented in Section 4, as well as torestrict its use to a subset of entities of themodelling language.

– Specification of model entities properties.The modelling environment should allow usto easily annotate the visual model withmodel properties like invariants, creation orfulfillment conditions that are typically usedin Formal Tropos specification.

– Automatic Model Translation. The mod-elling environment should allow us to savea model in a standard format (e.g., XMLand XMI), and provide automatic trans-formation into a different specification lan-guage. The model-to-model transforma-

2http://www.omg.org/technology/documents/modeling spec catalog.htm#MOF

tion approach should be also compliantwith Query/View/Transformation (QVT) re-quirements [14], as discussed in [24].

– Extensibility. The modelling environmentshould be extensible and allow for differ-ent configurations by easily integrating othertools at will.

ECLIPSE

EMF GEF

TAOM4e

TAOM4e model

TAOM4e platform

Figure 7: The architecture of TAOM4e.

An effective solution to the requirement of aflexible architecture and to the component inte-gration issue is offered by the Eclipse Platform.

New tools are integrated into the platformthrough plug-ins that provide the environmentwith new functionalities. A plug-in is the smallestunit of function in Eclipse and the Eclipse Plat-form itself is organized as a set of subsystems,implemented in one or more plug-ins, built onthe top of a small runtime engine. The TAOM4earchitecture is depicted in Figure 7. It followsthe Model View Controller pattern and has beendevised as an extension of two existing plug-ins.First, the EMF plug-in3 offers a modelling frame-work and code generation facilities for buildingtools and other applications based on a struc-tured data model. Given an XMI model specifi-cation, EMF provides functions and runtime sup-port to produce a set of Java classes for the model.Most importantly, EMF provides the foundationfor interoperability with other EMF-based toolsand applications. The resulting plug-in, calledTAOM4e model implements the Tropos meta-model. It represents the Model component of theMVC architecture. Second, the Graphical Edit-ing Framework (GEF) plug-in4 allows developersto create a rich graphical editor around an ex-isting metamodel. The functionality of the GEFplug-in helps to cover the essential requirementof the tool, that is supporting a visual develop-ment of Tropos models by providing some stan-

3http://www.eclipse.org/emf/4http://www.eclipse.org/gef/


dard functions like drag & drop, undo-redo, copy& paste and others. The resulting plug-in, calledTAOM4e platform represents both the Controllerand the Viewer components of the tool. In Fig-

Figure 8: The Graphic User Interface of TAOM4e.

ure 8 a snapshot of the modeler: the diagram ed-itor window on the right, the project and modelbrowsers on the left, the entity properties windowat the bottom.

6 Related Work

Many Agent-Oriented Software Engineeringmethodologies have been proposed and comparedover the last few years [18, 25]. An analysisof the metamodels of three methodologies,ADELFE [4], GAIA [27] and PASSI [7] has beenpresented in [3]. The aim of this work was toface interoperability issues between differentmethodologies.

In this section we extend this analysis includingTropos. We will focus on four dimensions: AgentStructure, Agent Interaction, Agent Organizationand Agent Development (e.g., CASE tools at sup-port of the development process). Table 1 sum-marizes the comparison. In ADELFE the con-cept of agent (Cooperative Agent) is defined asthe composition of aptitudes, skills, characteris-tic, communication and representation. Not ex-plicit concept of role is given, the concept of goalis implicitly used to identify agent skills, but it isnot representable as well as the concept of plan,since a plan is an entity that will be built atrun time and which is not representable at de-sign time. In GAIA, an agent (Agent Type) isspecified as a composition of roles. Each role is

responsible of a specific set of activities associatedwith the role. Goals cannot be explicitly mod-eled, but they are implicitly used to characterizea role. In PASSI, an agent (Agent) is defined asthe composition of roles and each role is definedas the manifestation of the agent activity in somescenario. Goals are implicitly considered whenspecifying non-functional requirements attachedto agent duties. In Tropos, the concept of Actorgeneralizes the concepts of agent and role (or setof roles), an actor can have individual goals and itcan be able to execute plans to satisfy goals. Goalanalysis in Tropos drives the modelling process,as discussed in Section 2 and allows us to repre-sent goal decomposition, means to satisfy a goalor contribution towards goal satisfaction throughdifferent goal relationships.

The concepts used to specify the interactions ofan agent with another agent or with the environ-ment are similar in ADELFE, GAIA and PASSI.Basically, they use the concept of communication,role, and protocols. Tropos adopts the AgentUnified modelling Language (AUML) Agent In-teraction Diagram, described in [2, 22] (proposedby the FIPA –Foundation for Physical IntelligentAgents– [12] and the OMG Agent Work group)where agent communicative acts are representedas messages in a UML sequence diagram.

In GAIA, the concept of organization is aprimary concept, organization rules specify con-straints that the organization should observe. InPASSI, agent organization aspects are modeledimplicitly in terms of services that can be ac-cessed by agents in a given scenario. In ADELFE,agent organization and society emerges from theevolving interactions between the agents whichare compliant with cooperation rules.

In Tropos the strategic dependencies betweenactors in a domain makes explicit the organi-zational dimension and provide basic entities tomodel organizational patterns [19]. Moreover, theTropos metamodel has been extended to includeconcepts of business processes and security.

Both ADELFE and PASSI provide CASE toolsat support of modelling and for ad-hoc analysison part of the resulting specification. Tropos pro-vides modelling and analysis tools (details can befound in http://www.troposproject.org) as well ascode generation tools [10].

This comparison shows that different metamod-


Agent Structure ADELFE GAIA PASSI Tropos

Agent Cooperative Agent Agent Type Agent Actor

Role Not explicit Role in a organization Role in a scenario Specialization of Actor

Goal Not explicit Not explicit Not explicit Goal and goal relationships

Plan Not explicit Activity of a Role Ontology of Action Plan and plan relationships

Agent Interaction

Comm. & Protocol Agent Communication Communication associated Communication associated Not in the current metamodel.

Agent Interaction to a role and protocols to a role and AUML interaction diagram

Protocols associated Messages as UML sequence diagram

associated to a communication components messages

to communication of communication for communication acts

A. Organization

Structure & Rules Cooperation rules OrganizationStructure, Not explicit Strategic Dependency,

Organization, Ownership, Delegation

OrganizationalRule and Trust

Organizational patterns

A. Development

Modeler Open-Tool — PASSI Toolkit TAOM, OME, DW-Tool, ST-Tool

Analysis tooos Open-Tool — PASSI Toolkit GR-Tool, DW-Tool, ST-Tool,T-Tool

Code Generation — — PASSI Toolkit SKwyRL

Table 1: Comparison of the meta-models of four Agent-Oriented methodologies.

els (methodologies) may allow us to model dif-ferent properties of a system (e.g., organizationalaspects, communications and protocols). On theother hand, it shows that even if metamodelsshare a comparable set of concepts, they can beused in a different way by the different method-ologies. This can be found also considering re-quirements engineering methodologies based onmetamodels. For instance, in KAOS [9], the con-cept of agent is used to assign leaf goals resultingfrom goal analysis.

Finally, other related work on i* and Troposmetamodels are worth to be mentioned. The i*metamodel [26] represents the basis for the Tro-pos metamodel. Other extensions of the i* meta-model have been proposed. For instance, in [1]where a methodology for COTS selection is pro-posed.

7 Conclusion

We have presented an overview of the Troposmetamodel. Like other software developmentmethodologies, Tropos supports a variety of mod-els that need to be analyzed for syntactic andsemantic consistency. The metamodel serves asa basis for checking for syntactic consistency.Making it richer, could also help in supportingsome forms of semantic consistency currently con-ducted through a series of tools offered within theTropos software development environment.

References

[1] C. Ayala, C. Cares, J. P. Carvallo, G. Grau,M. Haya, X. Franch G. Salazar, E. Mayol,and C. Quer. A Comparative Analysis of i*-Based Agent-Oriented Modeling Language.In Proc. of AOSDM Ws in SEKE’05 Con-ference, July 2005.

[2] B. Bauer, J.P. Muller, and J. Odell. AgentUML: A formalism for specifying multiagentinteraction. In Proc. of the 1st Int. Work-shop on Agent-Oriented Software Engineer-ing, AOSE’00, pages 91–104, Limerick, Ire-land, 2001.

[3] C. Bernon, M. Cossentino, M. P. Gleizes,P. Turci, and F. Zambonelli. A Study ofSome Multi-agent Meta-models. In Agent-Oriented Software Engineering V: 5th In-ternational Workshop, AOSE 2004, volume3382 of LNCS, pages 62 – 77, New York,USA, NY, July 2004.

[4] C. Bernon, M.P. Gleizes, S. Peyruqueou, andG. Picard. ADELFE, a Methodology forAdaptive Multi-Agent Systems Engineering.In Third International Workshop Engineer-ing Societies in the Agents World (ESAW-2002), Madrid, Spain, 2002.

[5] G. Booch, J. Rumbaugh, and I. Jacob-son. The Unified Modeling Language: UserGuide. Addison-Wesley, 1999.

[6] P. Bresciani, P. Giorgini, F. Giunchiglia,J. Mylopoulos, and A. Perini. Tropos:An Agent-Oriented Software Development


Methodology. Autonomous Agents andMulti-Agent Systems, 8(3):203–236, July2004.

[7] A. Chella, M. Cossentino, and L. Sabatucci.Tools and patterns in designing multi-agentsystems with PASSI. WSEAS Transactionson Communications, 3(1):352 – 358, Jan2004.

[8] L. K. Chung, B. A. Nixon, E. Yu, and J. My-lopoulos. Non-Functional Requirements inSoftware Engineering. Kluwer Publishing,2000.

[9] A. Dardenne, A. van Lamsweerde, andS. Fickas. Goal-directed requirements acqui-sition. Science of Computer Programming,20(1–2):3–50, 1993.

[10] T. T. Do, M. Kolp, and S. Faulkner. AgentOriented Design Patterns: The SKwyRLPerspective. In Proc. of the 6th InternationalConference on Enterprise Information Sys-tems (ICEIS 2004), Porto, Portugal, April2004.

[11] T. Finin, Y. Labrou, and J. Mayfield. KQMLas an agent communication language. In J.M.Bradshaw, editor, Software Agents. MITPress, 1997.

[12] FIPA. The Foundation for Intelligent Physi-cal Agents. At http://www.fipa.org, 2001.

[13] A. Fuxman, M. Pistore, J. Mylopoulos, andP. Traverso. Model checking early require-ments specification in Tropos. In Proc. ofthe 5th IEEE International Symposium onRequirements Engineering, Toronto, CA, Au-gust 2001.

[14] T. Gardner, C. Griffin, J. Koehler, andR. Hauser. A review of omg mof 2.0 query/ views / transformations submissions andrecommendations towards the final standard.In MetaModelling for MDA Workshop, York,England, 2003.

[15] P. Giorgini, J. Mylopoulous, and R. Sebas-tiani. Goal-Oriented Requirements Analysisand Reasoning in the Tropos Methodology.Engineering Applications of Artificial Intel-ligence, 18(2), 2005.

[16] P. Giorgini, F. Massacci, J. Mylopoulous,and N. Zannone. Requirements Engineeringmeets Trust Management: Model, Method-ology, and Reasoning. In Proc. of iTrust’04,LNCS 2995, pages 176–190. Springer-Verlag,2004.

[17] P. Giorgini, F. Massacci, J. Mylopoulous,and N. Zannone. Modeling Security Re-quirements Through Ownership, Permissionand Delegation. In Proc. of the The 13thIEEE Requirements Engineering Conference(RE’05), August-September 2005.

[18] B. Henderson-Sellers and P. Giorgini, edi-tors. Agent-Oriented Methodologies. IdeaGroup Inc., Hershey, PA, USA, 2005.

[19] M. Kolp, P. Giorgini, and J. Mylopou-los. A goal-based organizational perspec-tive on multi-agents architectures. In Proc.of the 8th Int. Workshop on IntelligentAgents: Agent Theories, Architectures, andLanguages, ATAL’01, Seattle, USA, August2001.

[20] Y. Labrou, T. Finin, and Y. Peng. Thecurrent landscape of agent communicationlanguages. Intelligent Systems, 14(2):45–52,1999.

[21] Stephen J. Mellor, Kendall Scott, Axel Uhl,and Dirk Weise. MDA Distilled. Addison-Wesley, 2004.

[22] J. Odell, H. Van Dyke Parunak, andB. Bauer. Extending UML for agents. InProc. of the 2nd Int. Bi-Conference Work-shop on Agent-Oriented Information Sys-tems, AOIS’00, pages 3–17, Austin, USA,July 2000.

[23] A. Perini and A. Susi. Developing Toolsfor Agent-Oriented Visual Modeling. InG. Lindemann, J. Denzinger, I.J. Timm,and R. Unland, editors, Multiagent SystemTechnologies, Proc. of the Second GermanConference, MATES 2004, number 3187 inLNAI, pages 169–182. Springer-Verlag, 2004.

[24] A. Perini and A. Susi. Automating ModelTransformations in Agent-Oriented mod-elling. In Agent-Oriented Software Engineer-


ing VI: AOSE 2005, LNCS. Springer, August2005.

[25] A. Sturm and O. Shehory. A Framework forEvaluating Agent-Oriented Methodologies.In M. Winikoff P. Giorgini, B. Henderson-Sellers, editor, Proc. of AOIS 2003, num-ber 3030 in LNCS, pages 94 – 109. Springer-Verlag, 2003.

[26] E. Yu. Modelling Strategic Relationships forProcess Reengineering. PhD thesis, Univer-sity of Toronto, Department of ComputerScience, 1995.

[27] F. Zambonelli, N. R. Jennings, andM. Wooldridge. Developing MultiagentSystems: The Gaia Methodology. ACMTransactions on Software Engineering andMethodology, 12(3):317 – 370, July 2003.

tropos metamodel and its use

Documents