agent oriented software engineering · agent oriented software engineering ambra molesini alma...
TRANSCRIPT
unibo-logo
Agent Oriented Software Engineering
Ambra Molesini
Alma Mater Studiorum – Universita di Bologna (Italy)[email protected]
Bologna, Italy, 28th June 2010
Molesini (UniBo) AOSE AOSE 2010 1 / 237
unibo-logo
Outline
Part I: General ConceptsPart II: Agent Oriented Software EngineeringPart III: AOSE MethodologiesPart IV: Situational Method EngineeringPart V: Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 2 / 237
unibo-logo
Outline of Part I
1 Software Engineering
2 Software Process
3 Methodologies
Molesini (UniBo) AOSE AOSE 2010 3 / 237
unibo-logo
Outline
Part I: General ConceptsPart II: Agent Oriented Software EngineeringPart III: AOSE MethodologiesPart IV: Situational Method EngineeringPart V: Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 4 / 237
unibo-logo
Outline of Part II
4 Why do we need AOSE?
5 Why agents and MAS?
Molesini (UniBo) AOSE AOSE 2010 5 / 237
unibo-logo
Outline
Part I: General ConceptsPart II: Agent Oriented Software EngineeringPart III: AOSE MethodologiesPart IV: Situational Method EngineeringPart V: Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 6 / 237
unibo-logo
Outline of Part III
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 7 / 237
unibo-logo
Outline
Part I: General ConceptsPart II: Agent Oriented Software EngineeringPart III: AOSE MethodologiesPart IV: Situational Method EngineeringPart V: Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 8 / 237
unibo-logo
Outline of Part IV
8 Methodologies Documentation
9 Situational Method Engineering
10 Situational Method Engineering in AOSESPEM and AOSE processesMethod Fragment RepresentationPRODE: PROcess DEsign for design processes
11 Result Evaluation
Molesini (UniBo) AOSE AOSE 2010 9 / 237
unibo-logo
Outline
Part I: General ConceptsPart II: Agent Oriented Software EngineeringPart III: AOSE MethodologiesPart IV: Situational Method EngineeringPart V: Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 10 / 237
unibo-logo
Outline of Part V
12 Research directions and visions
13 Conclusions
14 List of interesting papers
Molesini (UniBo) AOSE AOSE 2010 11 / 237
unibo-logo
Part I
General Concepts
Molesini (UniBo) AOSE AOSE 2010 12 / 237
unibo-logo
Outline
1 Software Engineering
2 Software Process
3 Methodologies
Molesini (UniBo) AOSE AOSE 2010 13 / 237
unibo-logo
Software Engineering
What is Software Engineering?
Software Engineering is an engineering discipline concerned with theories,methods and tools for professional software development[Sommerville, 2007]
What is the aim of Software Engineering?
Software Engineering is concerned with all aspects of software productionfrom the early stage of system specification to the system maintenance /incremental development after it has gone into use [Sommerville, 2007]
Molesini (UniBo) AOSE AOSE 2010 14 / 237
unibo-logo
Software Engineering
What is Software Engineering?
Software Engineering is an engineering discipline concerned with theories,methods and tools for professional software development[Sommerville, 2007]
What is the aim of Software Engineering?
Software Engineering is concerned with all aspects of software productionfrom the early stage of system specification to the system maintenance /incremental development after it has gone into use [Sommerville, 2007]
Molesini (UniBo) AOSE AOSE 2010 14 / 237
unibo-logo
Software Engineering: Concerns
There is a need to model and engineer bothI the development process
F controllable, well documented, and reproducible ways of producingsoftware
I the softwareF ensuring a given level of quality (e.g., % of errors and performances)F enabling reuse, maintenance, and incremental development
This requires suitableI abstractionsI tools
Molesini (UniBo) AOSE AOSE 2010 15 / 237
unibo-logo
Software Engineering Abstractions
Software deals with abstract entities, having a real-world counterpart:I numbers, dates, names, persons, documents. . .
In what terms should we model them in software?I data, functions, objects, agents. . .I i.e., what are the ABSTRACTIONS we should use to model software?
May depend on the available technologies!I use OO abstractions for OO programming envsI not necessarily: use OO abstractions because they are better, even for
COBOL programming envs
Molesini (UniBo) AOSE AOSE 2010 16 / 237
unibo-logo
Tools
Notation tools represent the outcomes of the software developmentI diagrams, equations, figures. . .
Formal models prove properties of software prior to the developmentI lambda-calculus, pi-calculus, Petri nets. . .
CASE tools are based on notations and models to facilitate activitiesI simulators
CAPE tools support process engineering during the construction ofnew software development processes
Molesini (UniBo) AOSE AOSE 2010 17 / 237
unibo-logo
Software Engineering & Computer Science
Computer science is concerned with theory andfundamentals—modelling computational systems
Software engineering is concerned with the practicalities of developingand delivering useful software—building computational systems
Deep knowledge of computer science is essential for softwareengineering in the same way that deep knowledge of physic isessential for electric engineers
Ideally, all of software engineering should be underpinned by theoriesof computer science. . . but this is not the case, in practice
Software engineers must often use ad hoc approaches to developingsoftware systems
Elegant theories of computer science cannot always be applied to real,complex problems that require a software solution [Sommerville, 2007]
Molesini (UniBo) AOSE AOSE 2010 18 / 237
unibo-logo
Software Engineering & System Engineering
System engineering is concerned with all aspects of computer-basedsystems development including hardware, software and processengineering
System engineers are involved in system specification, architecturaldesign, integration and deployment—they are less concerned with theengineering of the system components
Software engineering is part of this process concerned with developingthe software infrastructure, control, applications and databases in thesystem [Sommerville, 2007]
Molesini (UniBo) AOSE AOSE 2010 19 / 237
unibo-logo
Outline
1 Software Engineering
2 Software Process
3 Methodologies
Molesini (UniBo) AOSE AOSE 2010 20 / 237
unibo-logo
Development Process
Development Process [Cernuzzi et al., 2005]
The development process is an ordered set of steps that involve allthe activities, constraints and resources required to produce a specificdesired output satisfying a set of input requirements
Typically, a process is composed by different stages/phases put inrelation to each other
Each stage/phase of a process identifies a portion of work definitionto be done in the context of the process, the resources to be exploitedto that purpose and the constraints to be obeyed in the execution ofthe phase
Case by case, the work in a phase can be very small or moredemanding
Phases are usually composed by a set of activities that may, in turn,be conceived in terms of smaller atomic units of work (steps)
Molesini (UniBo) AOSE AOSE 2010 21 / 237
unibo-logo
Software Process
Software Process [Fuggetta, 2000]
The software development process is the coherent set of policies,organisational structures, technologies, procedures and deliverables thatare needed to conceive, develop, deploy and maintain a software product
Molesini (UniBo) AOSE AOSE 2010 22 / 237
unibo-logo
Software Process: Concepts
The software process exploits a number of contributions and concepts[Fuggetta, 2000]
Software development technology — Technological support used in theprocess. Certainly, to accomplish software developmentactivities we need tools, infrastructures, and environments
Software development methods and techniques — Guidelines on how touse technology and accomplish software developmentactivities. The methodological support is essential to exploittechnology effectively
Organisational behavior — The science of organisations and people
Marketing and economy — Software development is not a self-containedendeavor. As any other product, software must address realcustomers’ needs in specific market settings
Molesini (UniBo) AOSE AOSE 2010 23 / 237
unibo-logo
Software Process: Activities
Generic activities in all software processes are [Sommerville, 2007]:
Specification — What the system should do and its developmentconstraints
Development — Production of the software system
Validation — Checking that the software is what the customer wants
Evolution — Changing the software in response to changing demands
Molesini (UniBo) AOSE AOSE 2010 24 / 237
unibo-logo
Specification
The process of establishing what services are required and theconstraints on the system’s operation and development
Requirements engineering processI application domain studyI feasibility studyI requirements elicitation and analysisI requirements specificationI requirements validation
Molesini (UniBo) AOSE AOSE 2010 25 / 237
unibo-logo
Development
The process of converting the system specification into an executablesystemSoftware design
I analyse the problem in order to create the first logical architectureI design a software structure/architecture that realises the specification
Design activitiesI architectural designI abstract specificationI interface designI component designI data structure designI algorithm design
ImplementationI translate the system architecture into an executable program
The activities of design and implementation are closely related andmay be inter-leaved
Molesini (UniBo) AOSE AOSE 2010 26 / 237
unibo-logo
Validation
Verification and validation is intended to show that a systemconforms to its specification and meets the requirements of thesystem customerInvolves checking and review processes and system testingSystem testing involves executing the system with test cases that arederived from the specification of the real data to be processed by thesystem
I component or unit testingF individual components are tested independentlyF components may be functions or objects or coherent groupings of these
entities
I system testingF testing of the system as a wholeF testing of emergent properties is particularly important
I acceptance testingF testing with customer data to check that the system meets the
customer’s needs
Molesini (UniBo) AOSE AOSE 2010 27 / 237
unibo-logo
Evolution
Software is inherently flexible and can change
As requirements change through changing business circumstances, thesoftware that supports the business must also evolve and change
Although there has been a demarcation between development andevolution (maintenance) this is increasingly irrelevant as fewer andfewer systems are completely new
Molesini (UniBo) AOSE AOSE 2010 28 / 237
unibo-logo
The Ideal Software Process
The Ideal Software Process?
There is no an ideal process[Sommerville, 2007]
Molesini (UniBo) AOSE AOSE 2010 29 / 237
unibo-logo
Many Sorts of Software Processes
Different types of systems require different development processes[Sommerville, 2007]
I real time software in aircrafts has to be completely specified beforedevelopment begins
I in e-commerce systems, the specification and the program are usuallydeveloped together
Consequently, the generic activities, specified above, may beorganised in different ways, and described at different levels of detailsfor different types of software
The use of an inappropriate software process may reduce the qualityor the usefulness of the software product to be developed and/orincreased
Molesini (UniBo) AOSE AOSE 2010 30 / 237
unibo-logo
Software Process Model
A Software Process Model is a simplified representation of a softwareprocess, presented from a specific perspective [Sommerville, 2007]
A process model prescribes which phases a process should beorganised around, in which order such phases should be executed, andwhen interactions and coordination between the work of the differentphases should be occur
In other words, a process model defines a skeleton, a template,around which to organise and detail an actual process
Molesini (UniBo) AOSE AOSE 2010 31 / 237
unibo-logo
Software Process Model: Examples
Examples of process models areI Workflow model — this shows sequence of activities along with their
inputs, outputs and dependenciesI Activity model — this represents the process as a set of activities, each
of which carries out some data transformationI Role/action model — this depicts the roles of the people involved in
the software process and the activities for which they are responsible
Molesini (UniBo) AOSE AOSE 2010 32 / 237
unibo-logo
Generic Software Process Models
Generic process models
Waterfall — separate and distinct phases of specification anddevelopment
Iterative development — specification, development and validationare interleaved
Component-based software engineering — the system is assembledfrom existing components
Molesini (UniBo) AOSE AOSE 2010 33 / 237
unibo-logo
Outline
1 Software Engineering
2 Software Process
3 Methodologies
Molesini (UniBo) AOSE AOSE 2010 34 / 237
unibo-logo
Methodologies vs. Methods: General Issue
Disagreement exists regarding the relationship between the termsmethod and methodology
In common use, methodology is frequently substituted for method;seldom does the opposite occur
Some argue this occurs because methodology sounds more scholarlyor important than method
A footnote to methodology in the 2006 American Heritage Dictionarynotes that
I the misuse of methodology obscures an important conceptualdistinction between the tools of scientific investigation (properlymethods) and the principles that determine how such tools aredeployed and interpreted (properly methodologies)
Molesini (UniBo) AOSE AOSE 2010 35 / 237
unibo-logo
Methodologies vs. Methods in Software Engineering
In Software Engineering the discussion continues. . .I some authors argue that a software engineering method is a recipe, a
series of steps, to build software, while a methodology is a codified setof recommended practices. In this way, a software engineering methodcould be part of a methodology
I some authors believe that in a methodology there is an overallphilosophical approach to the problem. Using these definitions,Software Engineering is rich in methods, but has fewer methodologies
Molesini (UniBo) AOSE AOSE 2010 36 / 237
unibo-logo
Method
Method [Cernuzzi et al., 2005]
A method prescribes a way of performing some kind of activity withina process, in order to properly produce a specific output (i.e., anartefact or a document) starting from a specific input (again, anartefact or a document).
Any phase of a process, to be successfully applicable, should becomplemented by some methodological guidelines (including theidentification of the techniques and tools to be used, and thedefinition of how artifacts have been produced) that could help theinvolved stakeholders in accomplishing their work according to somedefined best practices
Molesini (UniBo) AOSE AOSE 2010 37 / 237
unibo-logo
Methodology
Methodology [Ghezzi et al., 2002]
A methodology is a collection of methods covering and connectingdifferent stages in a process
The purpose of a methodology is to prescribe a certain coherentapproach to solving a problem in the context of a software process bypreselecting and putting in relation a number of methods
A methodology has two important componentsI one that describes the process elements of the approachI one that focuses on the work products and their documentation
Molesini (UniBo) AOSE AOSE 2010 38 / 237
unibo-logo
Methodologies vs. Software Process
Based on the above definitions, and comparing software processes andmethodologies, we can find some common elements in their scope[Cernuzzi et al., 2005]
I both are focusing on what we have to do in the different activitiesneeded to construct a software system
I however, while the software development process is more centered onthe global process including all the stages, their order and timescheduling, the methodology focuses more directly on the specifictechniques to be used and artifacts to be produced
In this sense, we could say that methodologies focus more explicitlyon how to perform the activity or tasks in some specific stages of theprocess, while processes may also cover more general managementaspects, e.g., basic questions about who and when, and how much
Molesini (UniBo) AOSE AOSE 2010 39 / 237
unibo-logo
Example: OO Software Engineering
Abstractions:I objects, classes, inheritance, services.
Processes:I RUP, OPEN, etc. . .
Methodologies:I object-oriented analysis and design. . .I centered around object-oriented abstractions
Tools (Modeling Techniques):I UML (standard), E-R, finite state automata, visual languages. . .
Molesini (UniBo) AOSE AOSE 2010 40 / 237
unibo-logo
Part II
Agent Oriented Software Engineering
Molesini (UniBo) AOSE AOSE 2010 41 / 237
unibo-logo
Outline
4 Why do we need AOSE?
5 Why agents and MAS?
Molesini (UniBo) AOSE AOSE 2010 42 / 237
unibo-logo
Why do we need Agent-Oriented Software Engineering?
Agent-based computing introduces novel abstractions and asks forI making clear the set of abstractionsI adapting methodologies and producing new tools
Novel, specific agent-oriented software engineering approaches areneeded!
Molesini (UniBo) AOSE AOSE 2010 43 / 237
unibo-logo
What are agents?
There has been some debate on what an agent is, and what could beappropriately called an agent
Two main viewpoints (centered on different perspectives onautonomy):
I the (strong) Artificial Intelligence viewpointF an agent must be, proactive, intelligent, and it must converse instead
of doing client-server computing
I the (weak) Software Engineering ViewpointF an agent is a software component with internal (either reactive or
proactive) threads of execution, and that can be engaged in complexand stateful interactions protocols
Molesini (UniBo) AOSE AOSE 2010 44 / 237
unibo-logo
What are Multiagent Systems?
Again. . .I the (strong) Artificial Intelligence viewpoint
F a MAS (multiagent system) is a society of individuals (AI softwareagents) that interact by exchanging knowledge and by negotiating witheach other to achieve either their own interest or some global goal
I the (weak) Software Engineering ViewpointF a MAS is a software systems made up of multiple independent and
encapsulated loci of control (i.e., the agents) interacting with eachother in the context of a specific application viewpoint. . .
Molesini (UniBo) AOSE AOSE 2010 45 / 237
unibo-logo
SE Viewpoint on Agent-Oriented Computing
We commit to weak viewpoint becauseI it focuses on the characteristics of agents that have impact on software
developmentF concurrency, interaction, multiple loci of controlF intelligence can be seen as a peculiar form of control independence;
conversations as a peculiar form of interaction
I It is much more generalF does not exclude the strong AI viewpointF several software systems, even if never conceived as agent-based one,
can be indeed characterised in terms of weak multi-agent systems
Let’s better characterise the SE perspective on agents. . .
Molesini (UniBo) AOSE AOSE 2010 46 / 237
unibo-logo
SE Implications of Agent Characteristics
AutonomyI control encapsulation as a dimension of modularityI conceptually simpler to tackle than a single (or multiple
inter-dependent) locus of control
SituatednessI clear separation of concerns between
F the active computational parts of the system (the agents)F the resources of the environment
InteractivityI communication, coordinationI collaborative or competitive interactionI not a single characterising protocol of interactionI interaction protocol as an additional SE dimension
Molesini (UniBo) AOSE AOSE 2010 47 / 237
unibo-logo
SE Implications of Agent Characteristics
SocialityI not a single characterising protocol of interactionI interaction as an additional SE dimension
OpennessI controlling self-interested agents, malicious behaviours, and badly
programmed agentsI dynamic re-organisation of software architecture
Mobility and LocalityI additional dimension of autonomous behaviourI improve locality in interactions
Molesini (UniBo) AOSE AOSE 2010 48 / 237
unibo-logo
MAS Characterisation
Molesini (UniBo) AOSE AOSE 2010 49 / 237
unibo-logo
Agent-Oriented Abstractions
The development of a multi-agent system should fruitfully exploitabstractions coherent with the above characterisation
I agents, autonomous entities, independent loci of control, situated in anenvironment, interacting with each other
I environment, the world agents perceive (including resources as wellother agents)
I interaction protocols, as the acts of interactions among agents andbetween agents and resources of environment
In addition, there may be the need of abstracting:I the local context where an agent lives (e.g., a sub-organisation of
agents) to handle mobility & opennes
Such abstractions translate into concrete entities of the softwaresystem
Molesini (UniBo) AOSE AOSE 2010 50 / 237
unibo-logo
Agent-Oriented Methodologies
There is a need for SE methodologiesI centered around specific agent-oriented abstractionsI the adoption of OO methodologies would produce mismatches
F classes, objects, client-servers: little to do with agents!
Each methodology may introduce further abstractionsI around which to model software and to organise the software process
F e.g., roles, organisations, responsibilities, beliefs, desires andintentions. . .
I not directly translating into concrete entities of the software systemF e.g. the concept of role is an aspect of an agent, not an agent
Molesini (UniBo) AOSE AOSE 2010 51 / 237
unibo-logo
Agent-Oriented Tools
SE requires tools toI represent software
F e.g., interaction diagrams, E-R diagrams, etc. . .
I verify propertiesF e.g., petri nets, formal notations, etc.. . .
AOSE requiresI specific agent-oriented tools
F e.g., UML per se is not suitable to model agent systems and theirinteractions (object-oriented abstractions not agent-oriented ones)
Molesini (UniBo) AOSE AOSE 2010 52 / 237
unibo-logo
Outline
4 Why do we need AOSE?
5 Why agents and MAS?
Molesini (UniBo) AOSE AOSE 2010 53 / 237
unibo-logo
Why Agents and Multi-Agent Systems?
Other lectures may have already outlined the advantages of(intelligent) agents and of multi-agent systems, and their possibleapplications
I autonomy for delegation (do work on our behalf)I monitor our environmentsI more efficient interaction and resource management
We mostly want to show that
agent-based computing, and the abstractions it uses, represent a new andgeneral-purpose software engineering paradigm!
MASs already proved effective in dealing with open, distributed, complexproblems that are considered hard challenges for classical softwareengineering approaches
Molesini (UniBo) AOSE AOSE 2010 54 / 237
unibo-logo
There is much more to agent-oriented software engineering
AOSE is not only for “agent systems”I most of today’s software systems features are very similar to those of
agents and multi-agent systemsI agent abstractions, methodologies, and AOSE tools suit such software
systems
AOSE is suitable for a wide class of scenarios and applications!I agents’ “artificial intelligence” features may be important but are not
central
But of course. . .I AOSE may sometimes appear to be too “high-level” for simple complex
systems. . .I there is a gap between the AOSE approach and the available
technologies
Molesini (UniBo) AOSE AOSE 2010 55 / 237
unibo-logo
Agents and Multi-Agent Systems are (virtually) Everywhere
Examples of components that can be modelled (and observed) interms of agents:
I autonomous network processesI computing-based sensorsI PDAsI robots
Example of software systems that can be modelled as multi-agentsystems:
I internet applicationsI P2P systemsI sensor networksI pervasive computing systems
Molesini (UniBo) AOSE AOSE 2010 56 / 237
unibo-logo
Part III
AOSE Methodologies & Meta-models
Molesini (UniBo) AOSE AOSE 2010 57 / 237
unibo-logo
AOSE Methodologies
In this part we present:I the meta-model ideaI some AO methodologies:
F ADELFE [Bernon et al., 2005a], [Capera et al., 2004],[Bernon and Capera, 2008]
F Gaia [Wooldridge et al., 2000] , [Zambonelli et al., 2003],[Cernuzzi et al., 2009]
F PASSI [Cossentino, 2005], [Cossentino et al., 2008],[Cossentino et al., 2007b]
F Tropos [Susi et al., 2005], [Bresciani et al., 2004], [Hadar et al., 2010]F Prometheus [Padgham and Winikof, 2003],
[Padgham and Winikoff, 2005], [DeLoach et al., 2009]F SODA [Molesini et al., 2010], [Molesini et al., 2008b],
[Molesini et al., 2009a]F INGENIAS [Grasia Group, 2009], [Pavon et al., 2005],
[Garcıa-Magarino et al., 2009]
Molesini (UniBo) AOSE AOSE 2010 58 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 59 / 237
unibo-logo
Meta-models
Definition
Meta-modelling is the analysis, construction and development of theframes, rules, constraints, models and theories applicable and useful forthe modelling in a predefined class of problems
A meta-model enables checking and verifying the completeness andexpressiveness of a methodology by understanding its deep semantics,as well as the relationships among concepts in different languages ormethods
The process of designing a system consists of instantiating the systemmeta-model the designers have in their mind in order to fulfill thespecific problem requirements [Bernon et al., 2004]
Molesini (UniBo) AOSE AOSE 2010 60 / 237
unibo-logo
Using Meta-models
Meta-models are useful for specifying the concepts, rules andrelationships used to define a family of related methodologies
Although it is possible to describe a methodology without an explicitmeta-model, formalising the underpinning ideas of the methodology inquestion is valuable when checking its consistency or when planningextensions or modifications
A good meta-model must address all of the different aspects ofmethodologies, i.e. the process to follow and the work products to begenerated
In turn, specifying the work products that must be developed impliesdefining the basic modelling building blocks from which they are built
Meta-models are often used by methodologists to construct or modifymethodologies
Molesini (UniBo) AOSE AOSE 2010 61 / 237
unibo-logo
Meta-models & Methodologies
Methodologies are used by software development teams to constructsoftware products in the context of software projects
Meta-model, methodology and project constitute, in this approach,three different areas of expertise that, at the same time, correspondto three different levels of abstraction and three different sets offundamental concepts
As the work performed by the development team at the project levelis constrained and directed by the methodology in use, the workperformed by the methodologist at the methodology level isconstrained and directed by the chosen meta-model
Traditionally, these relationships between modelling layers are seen asinstance-of relationships, in which elements in one layer are instancesof some element in the layer above
Molesini (UniBo) AOSE AOSE 2010 62 / 237
unibo-logo
MAS Meta-model
MAS meta-models usually include concepts like role, goal, task, plan,communication
In the agent world the meta-model becomes a critical element whentrying to create a new methodology because in the agent orientedcontext, to date, there are not common denominator
I each methodology has its own concepts and system structure
Molesini (UniBo) AOSE AOSE 2010 63 / 237
unibo-logo
Software Design: the role of system meta-model
Designing a software means instantiating its meta-model
Attribute Operation
Requirement
Class
1
1..n
1
1..n
META-MODEL MODEL
Molesini (UniBo) AOSE AOSE 2010 64 / 237
unibo-logo
Meta-model
The use of meta-models to underpin object-oriented processes waspioneered in the mid-1990s by the OPEN Consortium[OPEN Working Group, ] leading to the current version of the OPENProcess Framework (OPF)
The Object Management Group (OMG) then issued a request forproposals for what turned into the SPEM (Software ProcessingEngineering Metamodel) [Object Management Group, 2008]
Molesini (UniBo) AOSE AOSE 2010 65 / 237
unibo-logo
SPEM
SPEM (Software Process Engineering Meta-model)[Object Management Group, 2008] is an OMG standardobject-oriented meta-model defined as an UML profile and used todescribe a concrete software development process or a family ofrelated software development processes
SPEM is based on the idea that a software development process is acollaboration between active abstract entities called roles whichperform operations called activities on concrete and real entitiescalled work products
Each role interacts or collaborates by exchanging work products andtriggering the execution of activities
The overall goal of a process is to bring a set of work products to awell-defined state
Molesini (UniBo) AOSE AOSE 2010 66 / 237
unibo-logo
SPEM level of abstraction
SPEM
Molesini (UniBo) AOSE AOSE 2010 67 / 237
unibo-logo
SPEM
The goals of SPEM are to:I support the representation of one specific development processI support the maintenance of several unrelated processesI provide process engineers with mechanisms to consistently and
effectively manage whole families of related processes promotingprocess reusability
Molesini (UniBo) AOSE AOSE 2010 68 / 237
unibo-logo
SPEM
Molesini (UniBo) AOSE AOSE 2010 69 / 237
unibo-logo
SPEM
Clear separation betweenI Method Contents — introduce the concepts to document and manage
development processes through natural language descriptionI Processes — defines a process model as a breakdown or decomposition
of nested Activities, with the related Roles and input / output WorkProducts
I Capability patterns — reusable best practices for quickly creating newdevelopment processes
Molesini (UniBo) AOSE AOSE 2010 70 / 237
unibo-logo
SPEM: Method Content and Process
Molesini (UniBo) AOSE AOSE 2010 71 / 237
unibo-logo
SPEM Notation
WorkProduct Definition and Use
Tool DefinitionTask Definition and Use
Role Definition and Use
Process Pattern
Process ComponentProcess
Milestone
Guidance
Composite role and TeamCategory
ActivitySymbolStereotype
Molesini (UniBo) AOSE AOSE 2010 72 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 73 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 74 / 237
unibo-logo
Characteristics of ADELFE
ADELFE is dedicated to the design of systems that are complex, openand not well-specified (Adaptive Multi-Agent Systems)
The primary objective of ADELFE method is to cover all the phasesof a classical software design
RUP has been tailored to take into account specificities coming fromthe design of AMAS
ADELFE follows the vocabulary of RUP
Only the requirement, analysis and design work definitions requiremodifications in order to be adapted to AMAS, other appearing in theRUP remaining the same
ADELFE is supported by several Tools
Molesini (UniBo) AOSE AOSE 2010 75 / 237
unibo-logo
Adaptive Multi-Agent Systems Theory
The openness and dynamics are source of unexpected events and anopen systems plugged into a dynamic environments has to be able toadapt to these changes, to self-organise
Self-organisation is a means to make the system adapt but also toovercome complexity
If a system is complex and its algorithm unknown, it is impossible tocode its global function
This function has then to emerge at the macro level (system level)from the interaction at the micro level (component level)
It is sufficient to build a system whose components have cooperativeattitude to make it realise an expected function
Cooperation is the local criterion that enables component to find theright place within the organisation
Molesini (UniBo) AOSE AOSE 2010 76 / 237
unibo-logo
Adaptive Multi-Agent Systems
Adaptive Multi-Agent Systems are composed of agents thatpermanently try to maintain cooperative interactions with other.
Any cooperative agent in AMAS follow a specific lifecycle thatconsists in:
I the agent gets perceptions from its environmentI it autonomously uses them to decide what to do in order to reach its
own goalI it acts to realise the action on which it has previously decided
Molesini (UniBo) AOSE AOSE 2010 77 / 237
unibo-logo
The ADELFE Meta-model
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
•Belongs to no predefined organization (AMAS)
•Has local goal•Is cooperative• Detects and removes NCS
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
An agent owns some skills e.g. specific knowledge that enables it to realize its own partial function
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
Aptitudes show the ability of an agent to reason both about knowledge and beliefs it owns
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
An agent may possess some characteristics which are its intrinsic or physical properties (for instance, the size of an agent or the number of legs of a robot-like or ant-like agent)
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
An agent observes some cooperation rules and avoids NCS (Non Cooperative Situations)
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Meta-model
An agent has perception of the environment elements
Molesini (UniBo) AOSE AOSE 2010 78 / 237
unibo-logo
The ADELFE Process
Molesini (UniBo) AOSE AOSE 2010 79 / 237
unibo-logo
ADELFE: Example
!"#"$#%&#'%#("%$)*!&#&)*+%),%&#+%!"#"$#&)*%-*!%.(-#%-$#&)*+%#("%-/"*#%01+#%2"3,)30%#)%!"-4%.&#(%%
67% ,)44).&*/% #("% 23"8&)1+47% !"+$3&9"!% 23)$"++'% #(3""% #))4+% -3"%-8-&4-94"5%:&3+#'%#("%;2"*<))4=%/3-2(&$-4%#))4%-44).+%!"+&/*"3+%#)%3"-4&>"% #("%!&,,"3"*#%?@ABC?@A%!&-/3-0+%-*!%+)0"%8-4&!-#&)*+%),% #("% +),#.-3"% +2"$&,&$-#&)*% -*!% !"+&/*5% <("*'% #("% -!"D1-$7%C@CE% #))4% ("42+% !"+&/*"3+% &*% $())+&*/% C@CE% #"$(*)4)/7% #)%!"+&/*% +7+#"0+5% :&*-447'% #("% &*#"3-$#&8"% #))4% "-+"+% ,)44).&*/% #("%CFGA:G%23)$"++5%
!" #$%&'##()*+#,*-.%(+%*;2"*<))4=% &+% -% !"8"4)20"*#% #))4'% .3&##"*% &*% #("% ;<E$3&2#%4-*/1-/"'%.(&$(%&+%!"+&/*"!%-*!%!&+#3&91#"!%97%<HIJK-4&)+7+'%)*"%),% #("% CFGA:G% 2-3#*"3+5% ;*% #("% )*"% (-*!'% ;2"*<))4% &+% -%$)00"3$&-4&>"!%/3-2(&$-4%#))4%4&L"%M-#&)*-4%M)+"%-*!%+122)3#+%#("%?@A% *)#-#&)*% #)% 0)!"4% -224&$-#&)*+% .(&4"% -++13&*/% #(-#% #("%23)!1$"!% 0)!"4+% -3"% 8-4&!5% @)3"% +2"$&,&$-447'% &#% ,)$1+"+% )*%-*-47+&+%-*!%!"+&/*%),%+),#.-3"%.3&##"*%&*%N-8-5%;*%#("%)#("3%(-*!'%;2"*<))4% "*-94"+% 0"#-J0)!"4&*/% &*% )3!"3% #)% !"+&/*% +2"$&,&$%$)*,&/13-#&)*+5%
<(&+% 4-##"3% ,"-#13"% (-+% 9""*% 1+"!% #)% "O#"*!%;2"*<))4% ,)3% #-L&*/%&*#)%-$$)1*#%#("%+2"$&,&$&#&"+%),%-!-2#&8"%014#&J-/"*#%+7+#"0+%-*!%#(1+% &*$41!&*/% #("0% &*#)% CFGA:G5% <("3",)3"'% #("% C?@A%*)#-#&)*'% .(&$(% -44).+% !"+$3&9&*/% C/"*#% I*#"3-$#&)*% P3)#)$)4+%1+&*/%23)#)$)4%!&-/3-0+'%(-+%9""*%&*#"/3-#"!%#)%;2"*<))45%
:13#("30)3"'% ?@A% (-+% 9""*% 0)!&,&"!% #)% -4+)% "O23"++% #("+"%+2"$&,&$&#&"+5%<.)%+)41#&)*+%$-*%9"%$)*+&!"3"!%#)%0)!&,7%#("%?@A%*)#-#&)*Q% 1+&*/% -% ?@A% 23),&4"% )3% -% 0"#-J0)!"4% "O#"*+&)*% RST5%?+1-447% #(&+% 4-##"3% +)41#&)*% &+% $()+"*%.("*% !)0-&*% $)*$"2#+% -3"%."44% !",&*"!5% H).-!-7+'% +"8"3-4% !&,,"3"*#% 2)&*#+% ),% 8&".% -9)1#%@CE% "O&+#5% :)3% "O-024"'% &*% CFGA:G'% ."% 1+"% )*"% +2"$&,&$%$)*$"2#%)*%-!-2#&8"%014#&J-/"*#%+7+#"0+%&*%.(&$(%-/"*#+%(-8"%#)%+"4,J)3/-*&>"5% 61#% &*% <M;P;E% )3% UCIC'% -/"*#% 3)4"+% -3"% ."44JL*).*% -*!% #("% )3/-*&>-#&)*% $-*% -% 23&)3&% 9"% /&8"*5% E)'% ?@A%23),&4"+%(-8"%9""*%$()+"*%#)%"O#"*!%#("%*)#-#&)*5%%
<("*'% &*% CFGA:G'% *&*"% +#"3")#72"+% $-*% 9"% 1+"!% #)% 0)!&,7% #("%+"0-*#&$+%),%$4-++"+%-*!%,"-#13"+%!"2"*!&*/%)*%#("%+2"$&,&$&#&"+%),%$))2"3-#&8"% -/"*#+5% I*$41!&*/% #("+"% +#"3")#72"+% &*% ;2"*<))4%"*-94"+% #("% !"8"4)2"3% #)% !"+&/*% -/"*#+% -*!% &*$)32)3-#"% #("0%!13&*/% (&+% 0)!"4&*/% -$#&8K% @)3")8"3'% ;2"*<))4% 23)8&!"+%+"8"3-4%0"$(-*&+0+%#)%/1&!"%!"+&/*"3+%#)%$)33"$#47%&024"0"*#%-*!%1+"%#("+"%-/"*#+5%
E)0"% $)("3"*$7% 314"+'% -##-$("!% #)% "-$(% +#"3")#72"'% -3"% !",&*"!%1+&*/% #("%;<E$3&2#% 4-*/1-/"%-*!% -3"% &024"0"*#"!% &*%;2"*<))45%;<E$3&2#% &+% #("%-$#&)*%4-*/1-/"%),%;2"*<))4%#(-#%$-*%9"%1+"!%#)%0)!"4%#("%9"(-8&)3%),%-/"*#+V%!"+&/*"3+%(-8"%W1+#%#)%"O23"++%+)0"%314"+% #(-#%.&44% 9"%23)$"++"!%97% #("%+&014-#&)*% #))4%),%;2"*<))45%<(&+%"*-94"+%!"+&/*"3+% #)%+&014-#"%-*!%$("$L%#("%9"(-8&)3%),% #("%-/"*#+% #(-#% -3"% &*8)48"!% &*% -% +7+#"05%@)3")8"3'% #(&+% +&014-#&)*%$-*% 9"% ("42,14% #)% ,&*!% &,% +)0"% 2)++&94"% $))2"3-#&)*% ,-&413"+% -3"%0&++&*/5%;2"*<))4% #("*%("42+%!"+&/*"3+% #)% 8-4&!-#"% #("%9"(-8&)3%),% -/"*#+% -+% ."44% -+% #)% +""% &,% +)0"% )#("3% 2)&*#+% -3"% 8-4&!% X#(&+%$)33"+2)*!+%#)%#("%-$#&8%YZ%&*%:&/13"%Y[Q%
• I*#"3-$#&)*% 23)#)$)4+Q% &#% &+% 2)++&94"% #)% ,&*!% &,% +)0"% !"-!4)$L+%$-*% #-L"% 24-$"% .&#(&*% -% 23)#)$)4'% )3% &,% +)0"% 23)#)$)4+% -3"%1+"4"++%)3% &*$)*+&+#"*#555% <(1+'% #("%9"(-8&)3% ),% +"8"3-4% -/"*#+%$)14!% 9"% W1!/"!% $)*,)30% X)3% *)#[% #)% #("% +"D1"*$"% !&-/3-0+%!"+$3&9"!%&*%#("%-*-47+&+%.)3L%!",&*&#&)*5%%
• @"#()!+Q% #("&3% 2)++&947% 1+"4"++*"++'% #("&3% "O(-1+#&8"*"++% $-*%9"%#"+#"!5%%
• <("%/"*"3-4%9"(-8&)3%),%-/"*#+Q%#)%$)*#3)4%&,%#(&+%9"(-8&)3%&+%&*%-$$)3!-*$"%.&#(%.(-#%.-+%"O2"$#"!5%%
<"+#+% $-*% 9"% 3"-4&>"!% ,&3+#47'% 97% $3"-#&*/% #("% +&014-#&)*%"*8&3)*0"*#%&*%$)44-9)3-#&)*%!&-/3-0'%-*!%#("*'%97%&024"0"*#&*/'%.&#(%;<E$3&2#'%+)0"%0"#()!+%!"+&/*"3+%0-7%.-*#%#)%#"+#5%
!"/ 01234352*67899*.38:;8<9*<("%,&3+#%0)!&,&$-#&)*%-!!"!%#)%;2"*<))4%$)*$"3*+%#("%+#-#&$%8&".%),% #("% 0)!"4Q% #("% $4-++% !&-/3-05% F&,,"3"*#% CFGA:GJ+2"$&,&$%9)O"+%-3"%!",&*"!%#)%#-L"%&*#)%-$$)1*#%#("%23"J!",&*"!%+#"3")#72"+%.&#()1#%!"$3"-+&*/% "3/)*)0&$% -+2"$#+%),% $4-++%!&-/3-0+%9"$-1+"%),% #("% 4-3/"% *109"3% ),% -8-&4-94"% +#"3")#72"+5% <(1+'% ,&"4!+% -*!%0"#()!+%-3"%-33-*/"!%.&#(&*%9)O"+%&*%#"30+%),%#("&3%+#"3")#72"+5%
G-$(% !!"##$%&'()*%+ ',%-(..% +#"3")#72"!% $4-++% 01+#% &*("3&#% ,3)0%"&#("3% #("% 23"J!",&*"!% /##$%&'()*%0,%-(% $4-++% )3% -*)#("3%!!"##$%&'()*%+ ',%-(..% +#"3")#72"!% $4-++5% <("3",)3"'% "-$(% -/"*#%$4-++%(-+%-#%4"-+#%,)13%0"#()!+%\%31*'%2"3$"&8"'%!"$&!"%-*!%-$#%\%#)%+&014-#"%&#+%4&,"%$7$4"5%
:&/13"% ]% +().+% -*% "O-024"% ),% $4-++% !&-/3-0% &*% .(&$(% -/"*#%$4-++"+% -22"-35% E&*$"% -/"*#% $4-++"+% -3"% )9W"$#% $4-++"+'% -44% #("%)2"3-#&)*+%)3%-++)$&-#&)*+%)*%)9W"$#%$4-++"+%-3"%2)++&94"%)*%-/"*#%$4-++"+Q% $)02)+&#&)*'% -//3"/-#&)*'% -*!% ("3&#-/"5% ^"3"'% ,)3% #("%G<<;% "O-024"'% #("% 1%$&%2%-('()*%0,%-(% $4-++% &+% $)02)+"!% ),%+"8"3-4%3##4)-,0,%-(5%;*%#("%)#("3%(-*!'%5(67%-(8$ -*!%9%'":%&%-/"*#% $4-++"+% &*("3&#% ,3)0% 1%$&%2%-('()*%0,%-(% $4-++% -*!% #("*%&*("3&#%&#+%,&"4!+%-*!%0"#()!+5%%
+3:=;5*>"*'?5*8:5@A*B7899*238:;8<*41;*%''#"*'C1*<83@*8:5@A*
B789959D* 9A5;51AEF52* !!"##$%&'()*%+ ',%-(..D* 8;5* 2543@52G*1%$&%2%-('()*%0,%-(! 8@2* 3##4)-,0,%-("* 1%$&%2%-('()*%0,%-(2* B8@*;5F;595@A* 53A?5;* 9A=25@A* :;1=F9* H5(67%-(8$* B7899I* 1;*A58B?5;9* H9%'":%&* B7899I"*1%$&%2%-('()*%',%-(* B7899* 39* B1<F1952*14* 95J5;87*3##4)-,0,%-(2* C?3B?* A89K* 39* A1* 43@2* A3<5971A* 3@* A?5*A3<5A8L75"*Molesini (UniBo) AOSE AOSE 2010 80 / 237
unibo-logo
ADELFE: Example
!"# $%&'&(&)*+,-.%-/0*!"# !$%&'%# ()*")"# +,)# !-.&# /# !0)1+# -1232)4# .54)66210#&710*70)# 89:;# /# 35(<762"<# =!0)1+>-.&?# +5#<54)6# 21+)(7@+251"#A)+B))1# 70)1+"C# DE)1F556# B7"# )1,71@)4# +5# @51"+(*@+# !GH# /#!0)1+# G1+)(7@+251# H(5+5@56# /# 4270(7<"I# !GH# 4270(7<"# 7()# 71#)J+)1"251# +5# )J2"+210# -.&# ")K*)1@)# 4270(7<"# +,7+# 7665B"#4233)()1+# <)""70)# ")14210# @7(421762+L# =!M$C# DN# 5(# ODN?I# G1#DE)1F556C#+,)")#4270(7<"#7()#4)"201)4#7"#0)1)(2@#4270(7<"#21#+,)#")1")# +,7+# +,)L# 45# 15+# *")# 21"+71@)"# 53# @67"")"# A*+# 516L# (56)"# 53#@67"")"I# F,2"# 15+251# 53# (56)# B7"# 744)4# +5# +,)# DE)1F556# <)+7><54)6I#F5#()"E514#+5#!$%&'%#714#!.!P#+,)5(L#"E)@232@2+2)"C#B)#744)4#"5<)#")<71+2@"#+5#E(5+5@56#4270(7<"I#'2("+C#7#+(200)(#@5142+251#2"#"E)@232)4#+5#67*1@,#+,)#E(5+5@56I#G1#+,)#'20*()#QC#+,)#!""#$%&'&(%)#B2+,# +,)#*+,-".$%&/(012(.'&(%)# (56)# ()@)2R)"# +,)#3""#$%&'&(%)4((%#)R)1+# 7"# 7# +(200)(# +5# A)021# +,)# 1)05+27+251# B2+,# +,)#5116,7$%&/(012(.'&(%)I#.5()5R)(C# !-.&# 15+7+251# ()<721"# 3*SSL# 51# +,)# ODN# 714#DN#A(71@,)"# @51@)(1210# +,)# 4)@2"251# <7T210# 53# <)""70)# ")14210I#F,)#@,52@)#53#7++7@,210#71#880,)$)69(::#"+)()5+LE)4#<)+,54#+5#+,)#154)# =ODN#5(#DN?#7665B"# +5# "E)@23L# +,2"#E521+I#'5(#)J7<E6)C# 21#+,)#'20*()#QC#+,)#$;<""=>$))$%&#<)+,54#2"#7++7@,)4#+5#+,)#32("+#ODN#154)U# 2I)IC# 21# +)(<"# 53# +,)# ()"*6+# 53# +,2"# <)+,54C# +,)#*+,-".$%&/(012(.'&(%)# <7L# )2+,)(# ()K*)"+# 35(# 2135(<7+251# +5#()"*<)# 2+"# )JE65(7+251# 53# +,)# +2<)+7A6)# 5(# A)021# +5# 1)05+27+)# 21#+)(<"#53#+,)#@51"+(721+"#53#+,)#+B5#70)1+"I#$)"201)("#@71#76"5#)7"26L#7""201#E(5+5@56"#+5#70)1+"#21#DE)1F556I#D1@)#7#E(5+5@56# 2"# 7++(2A*+)4# +5# 71#70)1+# 35(#7# (56)C# +,)#<)+,54"#+,7+# 7EE)7(# 21# +,)#E(5+5@56# 35(# +,)# @,5")1# (56)# 7()# 7*+5<7+2@766L#
744)4# +5# +,)# 70)1+# @67""# 7"# 88$%)(.01)$"%::# "+)()5+LE)4# <)+,54"I#'21766LC#+5#E()E7()#+,)#V'7"+#H(5+5+LE210W#7@+2R2+L#53#+,)#E(5@)""C#4)"201)("#@71#7*+5<7+2@766L#0)1)(7+)#"+7+)><7@,21)"#/51)#E)(#(56)#/#3(5<#+,)#E(5+5@56#4270(7<"#+5#"2<*67+)#+,)<#21#DE)1F556I##
1" 2324*2+567289*:;;<*F,71T"#+5#7@+2R2+L#!99#B,2@,#,7"#A))1#744)4#21#+,)#7176L"2"#B5(T#4)3212+251C# 4)"201)("# @71# T15B# 23# +,)# 7EE62@7+251# +5# 4)R)65E#()K*2()"#+5#A)#4)"201)4#*"210#+,)#!.!P#+)@,15650LI##
F,2"#74)K*7@L#2"#"+*42)4#A5+,#7+#+,)#065A76#6)R)6#=+,)#"L"+)<#6)R)6?#714#7+#+,)#65@76#51)#=+,)#6)R)6#53#+,)#4233)()1+#E7(+"#@5<E5"210#+,)#"L"+)<C#+,)#70)1+"?I#F5#"+*4L#+,)#74)K*7@L#53#+,)#!.!P#+,)5(L#7+#+,)#065A76#6)R)6C#)20,+#@(2+)(27#,7R)#A))1#4)321)4X#
9I G"# +,)# 065A76# +7"T# 21@5<E6)+)6L# "E)@232)4Y# G"# 71# 7605(2+,<# 7#E(25(2#*1T15B1Y#
ZI G3#")R)(76#@5<E51)1+"#7()#()K*2()4#+5#"56R)#+,)#065A76#+7"TC#45#+,)L#1))4#+5#7@+#21#7#@)(+721#5(4)(Y#
QI G"# +,)# "56*+251# 0)1)(766L# 5A+721)4# AL# ()E)+2+2R)# +)"+"U# 7()#4233)()1+#7++)<E+"#()K*2()4#A)35()#3214210#7#"56*+251Y#
[I \71#+,)#"L"+)<#)1R2(51<)1+#)R56R)Y#G"#2+#4L17<2@Y#]I G"# +,)# "L"+)<# 3*1@+251766L# 5(# E,L"2@766L# 42"+(2A*+)4Y# !()#")R)(76#E,L"2@766L#42"+(2A*+)4#@5<E51)1+"#1))4)4#+5#"56R)#+,)#065A76#+7"TY#D(#2"#7#@51@)E+*76#42"+(2A*+251#1))4)4Y#
^I $5)"#7#0()7+#1*<A)(#53#@5<E51)1+"#1))4)4Y#:I G"#+,)#"+*42)4#"L"+)<#151>621)7(Y#_I '21766LC# 2"# +,)# "L"+)<# )R56*+2517(L# 5(# 5E)1Y# \71# 1)B#@5<E51)1+"#7EE)7(#5(#42"7EE)7(#4L17<2@766LY#
F,)")#K*)"+251"#7()#7"T)4#+5#4)"201)("#*"210#7#0(7E,2@76#21+)(37@)#B,2@,# 2"# R2"*762S)4# 21# '20*()# [I# F,)# 4)"201)(# *")"# 7# "624)(# +5#71"B)(# 7# K*)"+251# 714# +5# 02R)# 7# (7+)# 7<510# +B)1+L# E5""2A262+2)"#(710210#3(5<#VL)"W#+5#V15WI#`2"#71"B)("#7()#+,)1#7176LS)4#AL#+,)#"*EE5(+# 4)@2"251# +556# +5# 2135(<# ,2<# 23# *"210# 71# !.!P# +5#2<E6)<)1+#+,)#"L"+)<#2"#*")3*6I##
=,.>%?* @"* A?%?* ,0* -B* ?C-/D)?* &E* D%&'&(&)* F?'G??B* 'G&*
!""#$%&'&(%);* GH,(H* %?D%?0?B'0* 'G&* I,EE?%?B'* '?-(H?%0"* :H?*E,%0'*-.?B'*,0*?CD)&%,B.*'H?*',/?'-F)?*'&*E,BI*J-),I*',/?0)&'*-BI*
%&&/"* :H?* 0?(&BI* -.?B'* ,0* -)%?-IK* &((>DK,B.* -* %&&/* -'* -*
D%?(,0?* ',/?0)&'"* :H,0* D%&'&(&)* I,-.%-/* ?CD)-,B0* 'H?*
B?.&',-',&B* F?'G??B* 'H?* 'G&* -.?B'0"* :H,0* B?.&',-',&B* /-K*
%?0>)'* &B* 'H?* E,%0'* -.?B'L0* )?-J,B.* &%* &B* 'H?* E,%0'* -.?B'L0*
F&&M,B."*
=,.>%?*!"*2324*-I?N>-(K*.%-DH,(-)*'&&)*-DD),?I*'&*5::;*
Molesini (UniBo) AOSE AOSE 2010 81 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 82 / 237
unibo-logo
The Gaia Methodology
It is the most known AOSE methodologyI firstly proposed by Jennings and Wooldridge in 1999I extended and modified by Zambonelli in 2000I final Stable Version in 2003 by Zambonelli, Jennings, WooldridgeI many other researchers are working towards further extensions. . .
Molesini (UniBo) AOSE AOSE 2010 83 / 237
unibo-logo
The Gaia Methodology
Starting from the requirements (what one wants a software system todo)
Guide developers to a well-defined design for the multi-agent system
Model and dealing with the characteristics of complex and openmulti-agent systems
Easy to implement
Molesini (UniBo) AOSE AOSE 2010 84 / 237
unibo-logo
The Gaia Methodology
Exploits organisational abstractionsI conceive a multi-agent systems as an organisation of individual, each of
which playing specific roles in that organisationI and interacting accordingly to its role
Introduces a clear set of abstractionsI roles, organisational rules, organisational structuresI useful to understand and model complex and open multi-agent systems
Abstract from implementation issues
Molesini (UniBo) AOSE AOSE 2010 85 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Meta-model
LivenessProperty SafetyProperty
SafetyRule LivenessRule
OrganizationalStructure
Environment
Actiontype
Activity
Resourcenamedescription
0.. *
1
0.. *
1
*
1
+permitted action*
1
Responsibility
OrganizationalRule
Protocolnameinitiatorpartnerinputsoutputsdescription
Comm unication
0..*0..*
observes
1
1..*
1
1..*
Organizationcontrol regimetopology
collaborates/interacts
**
0.. *0.. *
observes
Role
1..*1..*
0..* 10..* 1acts on/interacts with
1..*
1
1..*
1has
0..*
*
0..*
*
observes
*1+ini tiator/participant
*1
Serviceinputsoutputspre-conditionspost-conditions
AgentTypecollaborates
*
1
+member*
1
...
1
...
1
plays
1..* 11..* 1
provides
Permission
Molesini (UniBo) AOSE AOSE 2010 86 / 237
unibo-logo
The Gaia Pocess
Analysis Architectural Design Detailed Design
Molesini (UniBo) AOSE AOSE 2010 87 / 237
unibo-logo
Gaia: Example
September 4, 2009 9:33 WSPC/INSTRUCTION FILE CMOZ-JSEKE2008
30 L. Cernuzzi, A. Molesini, A. Omicini and F. Zambonelli
Table 3. The ReviewCatcher functional role schema.
Role Name: ReviewCatcher
Description:
This role is in charge of selecting reviewers and distributing papers among them.
Protocol and Activities:
GetPaper, CheckPaperTopic, CheckRefereeExpertise,CheckRefereeConstraints, AssignPaperReferee,ReceiveRefereeRefuse, UpdateDBSubmission, UpdateDBReferee
Permissions:
Reads paper submitted in order to check the topic and authorsreferee-data in order to check the expertise and constraint (i.e. the referee
is one of the authors, or belong to the same organization
Changes DB Submission assigning a referee to the paperDB Referee assigning the paper to the referee incrementing the number
of assigned papers
Responsibilities:
Liveness: ReviewCatcher = (GetPaper.CheckPaperTopic.CheckRefereeExpertise.CheckRefereeConstraints.AssignPaperReferee.[ReceiveRefereeRefuse] |UpdateDBSubmission.UpdateDBReferee)n
Safety: ∀ paper: number of referees ≥ n
Referee �= Author
Referee organization �= Author organization
Molesini (UniBo) AOSE AOSE 2010 88 / 237
unibo-logo
Gaia: Example
September 4, 2009 9:33 WSPC/INSTRUCTION FILE CMOZ-JSEKE2008
Adaptable Multi-Agent Systems: The Case of the Gaia Methodology 29
Table 2. The Environment Model for the Review Sub-organization.
Action Environment Abstraction Description
Reads Paper Submitted the Web site receives a paperReview Submitted the Web site receives a review
Changes DB Submission insert in the data base the paper or thereview received; one per each track
DB Reviewer insert in the data base the personaldata of the reviewer, the topic of expertise and themaximum number of papers the referee accepted to review
September 4, 2009 9:33 WSPC/INSTRUCTION FILE CMOZ-JSEKE2008
32 L. Cernuzzi, A. Molesini, A. Omicini and F. Zambonelli
Table 5. The ReceivePaperAssignement interaction protocol.
Protocol Name: ReceivePaperAssignement
Initiator: ReviewCatcher Partner: ReviewPartitioner Input: paper submitted
Description: The ReviewPartitioner, having checked the area Output: The paper isof the paper, assigns the paper to the corresponding ReviewCatcher assigned to a specific area(the Vice-Chair in charge of that area). and the DB Submission is up-
dated
Molesini (UniBo) AOSE AOSE 2010 89 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 90 / 237
unibo-logo
The PASSI Methodology
PASSI (Process for Agent Societies Specification andImplementation) is a step-by-step requirement-to-code methodology
The methodology integrates design models and concepts from bothObject Oriented Software Engineering and MAS using UML notation
PASSI refers to the most diffuse standards: UML, FIPA, JAVA,Rational Rose
PASSI is conceived to be supported by PTK (PASSI Tool Kit) anagent-oriented CASE tool
Molesini (UniBo) AOSE AOSE 2010 91 / 237
unibo-logo
The PASSI Methodology
PASSI process supports:I modelling of requirements is based on use-casesI ontology that as a central role in the social modelI multiple perspectives: agents are modelled from the social and internal
point of view, both structurally and dynamicallyI reuse of existing portions of design code; this is performed through a
pattern-based approachI design of real-time systemsI the design process is incremental and iterative
Extends UML with the MAS concepts
Molesini (UniBo) AOSE AOSE 2010 92 / 237
unibo-logo
The PASSI Meta-model
Molesini (UniBo) AOSE AOSE 2010 93 / 237
unibo-logo
The PASSI Process Technical Report xxxxxx
SPEM 2.0 description of the PASSI process !
7/29
!!!
!"#$%&''($%)*+#,,$-./#+0+-#$!
!
!!
Figure 2. The PASSI process phases
!"#$$%!&'()*+,-!.&/,!012-,-!2332'4,+!&'!2'!&5,325&/,6&'(3,7,'52)!038(,--!78+,)!9-,,!:&4*3,!;<=!!
• $>-5,7!?,@*&3,7,'5-=! %5! (8/,3-! 2))! 51,!012-,-! 3,)25,+! 58!?,@A! B)&(&525&8'C! 2'2)>-&-!2'+!24,'5-638),-!&+,'5&.&(25&8'
• #4,'5! $8(&,5>=! #))! 51,! 2-0,(5-! 8.! 51,! 24,'5! -8(&,5>! 23,! .2(,+=! 8'58)84>C!(877*'&(25&8'-C!38),-!+,-(3&05&8'C!%'5,32(5&8'!03858(8)-
• #4,'5!%70),7,'525&8'=!#!/&,D!8'!51,!->-5,7E!-!23(1&5,(5*3,!&'!5,37-!8.!()2--,-!2'+!7,518+-!58!+,-(3&F,!51,!-53*(5*3,!2'+!51,!F,12/&83!8.!-&'4),!24,'5A
• G8+,=! #! )&F323>! 8.! ()2--! 2'+! 2(5&/&5>! +&24327-!D&51! 2--8(&25,+! 3,*-2F),! (8+,! 2'+!-8*3(,!(8+,!.83!51,!5234,5!->-5,7A
• H,0)8>7,'5=! I8D! 51,! 24,'5-! 23,! +,0)8>,+! 2'+! D1&(1! (8'-532&'5-! 23,!+,.&',+6&+,'5&.&,+!.83!51,&3!7&4325&8'!2'+!78F&)&5>A
!B2(1! 012-,! 038+*(,-! 2! +8(*7,'5! 5125! &-! *-*2))>! (8708-,+! 2443,425&'4! JKL!78+,)-! 2'+!D83M!038+*(5-! 038+*(,+! +*3&'4! 51,! 3,)25,+! 2(5&/&5&,-A! B2(1! 012-,! &-! (8708-,+! 8.! 8',! 83! 783,! -*FN012-,-!,2(1!8',!3,-08'-&F),!.83!+,-&4'&'4!83!3,.&'&'4!8',!83!783,!235,.2(5-!5125!23,!0235!8.!51,!(833,-08'+&'4! 78+,)! 9.83! &'-52'(,! 51,! $>-5,7! ?,@*&3,7,'5-! 78+,)! &'()*+,-! 2'! 24,'5!&+,'5&.&(25&8'!+&24327!5125!&-!2!M&'+!8.!JKL!*-,!(2-,!+&24327-!F*5!2)-8!-87,!5,O5!+8(*7,'5-!)&M,!2!4)8--23>!2'+!51,!->-5,7!*-,!-(,'23&8-<A!!P1,!+,52&)-!8.!,2(1!012-,!D&))!F,!+&-(*--,+!&'!51,!.8))8D&'4!-,(5&8'A!!
Molesini (UniBo) AOSE AOSE 2010 94 / 237
unibo-logo
PASSI: Example Technical Report xxxxxx
SPEM 2.0 description of the PASSI process
!
19/29
!"#$%&'(#$%)*)+,%)-$&
"#$%#&'(!)%*+!$'!,-.!/$-.!0&$(%$+1!2$/3$(.-!$%.!,-.0!#*!(%*,2!),'/#&*'$4&#&.-!#5$#!6&44!7.!$--&('.0!#*!$'!$(.'#!865*-.!'$+.!&-!#5.!'$+.!*)!#5.!2$/3$(.9:!"#.%.*#;2.-! *)! %.4$#&*'-5&2-! 7.#6..'!,-.! /$-.-! *)! 0&)).%.'#! 2$/3$(.-! 8$(.'#-9! $%.! /*'<.%#.0! #*!=/*++,'&/$#.>!-&'/.!0&)).%.'#!$(.'#-!/$'! &'#.%$/#!*'4;! &'!#5&-!6$;:!?&%./#&*'!*)!#5.!%.4$#&*'-5&2-!(*.-!)%*+!#5.!&'&#&$#*%!#*!#5.!2$%#&/&2$'#:!!!@5.!0&$(%$+!&-!/*+24.#.0!7;!#5.!)*44*6&'(!&')*%+$#&*'A!
!"#$%& .#/+0)1%)-$&&234$+%)-$,5&6#789&
:1#+),5&6#74)0#;#$%/&
! ! !"#$%&'()*+ ,(-#&+ .,.+ /%.$(0+ 1#20*+3"#%4,5*+6,7'8'()*+9:+
!!
6-5#/&'(#$%)*)+,%)-$&
?,%&'(!#5&-!25$-.!$44!#5.!2*--&74.!/*++,'&/$#&*'!2$#5-!7.#6..'!$(.'#-!$%.!%.2%.-.'#.0:!B!2$#5!0.-/%&7.-!$!-/.'$%&*!*)!&'#.%$/#&'(!$(.'#-!6*%3&'(!#*!$/5&.<.!$!%.C,&%.0!7.5$<&*,%!*)!#5.!-;-#.+:!D$/5!$(.'#!+$;!7.4*'(!#*!-.<.%$4!-/.'$%&*-1!65&/5!$%.!0%$6'!7;!+.$'-!*)!-.C,.'/.!0&$(%$+-!&'!65&/5!*7E./#-!$%.!,-.0! #*! %.2%.-.'#! %*4.-! 8/*44./#&*'!*)! #$-3-!2.%)*%+.0!7;!$(.'#! &'!2,%-,&'(!$!-,7F(*$49:!!!!
Molesini (UniBo) AOSE AOSE 2010 95 / 237
unibo-logo
PASSI: Example
Technical Report xxxxxx
SPEM 2.0 description of the PASSI process !
20/29
!!
"#$%!&'#()#*!'+!$,*-./0/&!12!0%/!3,..,4'5(!'53,)*#0',56!
Role Name Agent which plays it Description Responsibilities
!
!"#$%&'()*+*)",*-.%
7$0'8'02!&'#()#*+!#)/!9+/&! 0,! +%,4! 0%/!1/%#8',9)!,3!/#$%!#(/50!-,'50'5(!#00/50',5! '5!4%#0! '0! '+!$#-#1./! 0,! &,:! ;/.#0',5+%'-+! 1/04//5! #$0'8'0'/+! +'(5'32!*/++#(/+! #5&! $,**95'$#0',5+! 1/04//5!0#+<+!,3!0%/!+#*/!#(/50:!7!=#+<!+-/$'3'$#0',5!&'#()#*!)/-)/+/50+!0%/!-.#5!,3!0%/!#(/50!1/%#8',):!>0!+%,4+! 0%/! )/.#0',5+%'-+! #*,5(! 0%/! /?0/)5#.! +0'*9.'! )/$/'8/&! 12! 0%/! #(/50! #5&! '0+! 1/%#8',9)!@/?-)/++/&!'5!0/)*+!,3!3')/&!0#+<+A:!!
!!!!
Molesini (UniBo) AOSE AOSE 2010 96 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 97 / 237
unibo-logo
The Tropos Methodology
Tropos is an agent-oriented software development methodologyfounded on two key features
I (i) the notions of agent, goal, plan and various other knowledge levelconcepts are fundamental primitives used uniformly throughout thesoftware development process
I (ii) a crucial role is assigned to requirements analysis and specificationwhen the system-to-be analysed with respect to its intendedenvironment
Then the developers can capture and analyse the goals of stakeholders
These goals play a crucial role in defining the requirements for thenew system: prescriptive requirements capture the what and the howfor the system-to-be
Molesini (UniBo) AOSE AOSE 2010 98 / 237
unibo-logo
The Tropos Methodology
Tropos adopts Eric Yu’s i* model which offers actors (agents, roles, orpositions), goals, and actor dependencies as primitive concepts formodelling an application during early requirements analysis
GoalGoal
TaskTask
ResourceResource
SoftgoalSoftgoal
Actor
Molesini (UniBo) AOSE AOSE 2010 99 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
The Tropos Meta-model
Molesini (UniBo) AOSE AOSE 2010 100 / 237
unibo-logo
Tropos: Example
© P. Giorgini! 34!
Early requirements!
Molesini (UniBo) AOSE AOSE 2010 101 / 237
unibo-logo
Tropos: Example
© P. Giorgini! 35!
Late requirements!We introduce the system actor and analyze its dependencies with actors in its environment identifying system"s functional and non-functional requirements!
Molesini (UniBo) AOSE AOSE 2010 102 / 237
unibo-logo
Tropos: Example
© P. Giorgini! 36!
Late requirements!The goals decomposition, means-end and contribution analysis are performed on the system"s goals!
Molesini (UniBo) AOSE AOSE 2010 103 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 104 / 237
unibo-logo
The Prometheus Methodology
Prometheus is a detailed process for specifying, designing, andimplementing intelligent agent systems
The goal in developing Prometheus is to have a process with defineddeliverables which can be taught to industry practitioners andundergraduate students who do not have a background in agents andwhich they can use to develop intelligent agent systems
Prometheus distinguishes itself from other methodologies bysupporting the development of intelligent agents:
I providing start-to-end support,I having evolved out of practical industrial and pedagogical experience,I having been used in both industry and academia, and, above all, in
being detailed and complete
Molesini (UniBo) AOSE AOSE 2010 105 / 237
unibo-logo
The Prometheus Methodology
Prometheus is also amenable to tool support and provides scope forcross checking between designs
The methodology consists of three phases: system specification,architectural design, and detailed design
Although the phases are described in a sequential fashion it isacknowledged that like most Software Engineering methodologies,practice involves revisiting earlier phases as one works out the details
Molesini (UniBo) AOSE AOSE 2010 106 / 237
unibo-logo
The Prometheus Overview
Molesini (UniBo) AOSE AOSE 2010 107 / 237
unibo-logo
Prometheus: Example
202 L. Padgham, J. Thangarajah, and M. Winikoff
Fig. 5. Refined Analysis Overview Diagram
Fig. 6. Scenario example - Paper Review
There is typically substantial iteration between scenario development and goal hi-erarchy development until the developer feels that the application is sufficiently de-scribed/defined. At this stage goals are grouped into cohesive units and assigned toroles which are intended as relatively small and easily specified chunks of agent
Molesini (UniBo) AOSE AOSE 2010 108 / 237
unibo-logo
Prometheus: Example
The Prometheus Design Tool – A Conference Management System Case Study 203
Fig. 7. Goal Overview Diagram
Fig. 8. System Roles Diagram
functionality. The percepts and actions are then also assigned to the roles appropri-ately to allow the roles to achieve their goals. This is done using the ‘System Roles’diagram.
Molesini (UniBo) AOSE AOSE 2010 109 / 237
unibo-logo
Prometheus: Example
204 L. Padgham, J. Thangarajah, and M. Winikoff
For example, Figure 8 shows that the ‘Assignment’ role is responsible for the goals tocollect preferences (from the reviewers) and assign papers (to the reviewers). To achievethese goals the role needs the input (reviewer info) and reviewer preferences (prefs) andshould perform the actions of requesting preferences from reviewers (request prefs) andgiving out the paper assignments (give assignments).
4 Architectural Design
The next stage is the architectural design where we specify the internal composition ofthe system. The main tasks here are to decide the agent types (as collections of roles)and to define the agent conversations (protocols) that will happen in order to realise thespecified goals and scenarios. Decisions regarding grouping of roles into agents are cap-tured in the ‘Agent-Role Grouping Diagram’. Figure 9 shows the roles of assigning pa-pers to reviewers (Assignment) and managing the review process (review management)as being part of a Review manager agent. A number of issues must be considered indetermining how to group roles into agents, including standard software engineeringissues of cohesion and coupling. The relationships of roles to data are also consideredin determining role groupings. The Data Coupling anA. gent Acquaintance diagrams canassist the designer in visualising these aspects.
Fig. 9. Agent-Role Grouping Diagram
Once decisions have been made about how roles are grouped into agents, informa-tion can be propagated from the role specifications, to show which percepts and ac-tions are associated with which agents. This information is automatically generatedinto the ‘System Overview Diagram’ which, when completed, provides an overview ofthe internal system architecture. What must be done to complete this overview is to de-fine interactions between the agents (protocols), and to add any shared data. Figure 10shows the system overview for our conference management system design. Observ-ing the ‘Papers manager’ agent we can see that it receives papers (percept) fromauthors and provides an acknowledgment (action) to them. It interacts with the ‘Se-lections manager’ agent via the ‘selection decision’ protocol to be able to send authors
Molesini (UniBo) AOSE AOSE 2010 110 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 111 / 237
unibo-logo
SODA: Societies in Open and Distributed Agent spaces
SODA . . .
. . . is an agent-oriented methodology for theanalysis and design of agent-based systems. . . focuses on inter-agent issues, like theengineering of societies and environment forMAS. . . adopts agents and artifacts – after theA&A meta-model [Omicini et al., 2006] – asthe main building blocks for MASdevelopment. . . introduces a simple layering principle inorder to cope with the complexity of systemdescription. . . adopts a tabular representation
Molesini (UniBo) AOSE AOSE 2010 112 / 237
unibo-logo
SODA: Overview
RequirementsAnalysis Analysis
ArchitecturalDesign
DetailedDesign
ReferencesTables
TransitionsTables
MappingTables
Requirements Tables
Domain Tables
Relations Tables
Responsibilities Tables
Dependencies Tables
Topologies Tables
Entities Tables
Interaction Tables
Topological Tables
Agent/Society Design Tables
Environment Design Tables
Analysis
Design
Constraints Tables Interaction Design Tables
Topological Design Tables
Molesini (UniBo) AOSE AOSE 2010 113 / 237
unibo-logo
The SODA Meta-modelSODA 2008/09/04
Actor Requirement
*1
Relation LegacySystem ExternalEnvironment
* 1
Task
1..*
1
Dependency
**
participates
**
participates
* *
participates
Function
* *participates
Topology
*
*
participates
*
*
participates
1..*
1
1..*
1
0..*
1
0..*
1
0..*
1
Role
Action
1..*
1
performs
Interaction
Resource
Operation
1..*
1provides
1..*
1
1
1..*
1..*
1
1
1..*
Space *
*
participates
1..*
1..*
participates*
1
0..*
connection
1..*
1
1..*
1
Workspace
1..*
1..*
Agent
1
1..*
Artifact
1..*
1
perceives 1..*
1
is allocated
Composition
Society Aggregate
Individual Artifact
Social Artifact
Environmental Artifact
1..*
1
participates
Rule
0..*
1..*
constrains
connection
** participates* *
participates
1..* 1..*constrains
1..*1..*
constrains
1..*
1..*constrains
1
1..*
1
1..*
1
1..*
Uses1..*1..* 1..*1..*
Manifests1..*
1..*1..*
1..*
Speaks to 1..* 1..*
participates
1..*
1..*
Links to
1..*
1..*
Autonomous Behaviour
exhibits
exhibits
Functional Behaviour
exhibits
exhibits
1..*
1..*
participates
Requirements Analysis
Analysis
Architectural Design
Detailed Design
Molesini (UniBo) AOSE AOSE 2010 114 / 237
unibo-logo
The SODA Meta-modelSODA 2008/10/22
Actor Requirement
*1
Relation LegacySystem ExternalEnvironment
* 1
Task
1..*
1
Dependency
**
participates
**
participates
* *
participates
Function
* *
participates
Topology
*
*
participates
*
*
participates
1..*
1
1..*
1
0..*
1
0..*
1
0..*
1
Role
Action
1..*
1
performs
Interaction
Resource
Operation
1..*
1
provides
1..*
1
1
1..*
1..*
1
1
1..*
Space*
*
participates
1..*
1..*
participates
*
1
0..*
connection
1..*
1
1..*
1
Workspace
1..*
1..*
Agent
1
1..*
Artifact
1..*
1
perceives1..*
1
is allocated
Composition
Society Aggregate
Individual Artifact
Social Artifact
Environmental Artifact
1..*
1
participates
Rule
0..*
1..*
constrains
connection
** participates
* *
participates
1..* 1..*
constrains
1..*1..*
constrains
1..*
1..*constrains
1
1..*
1
1..*
1
1..*
Uses1..*1..* 1..*1..*
Manifests1..*
1..*1..*
1..*
Speaks to 1..* 1..*
participates
1..*
1..*
Links to
1..*
1..*
Autonomous Behaviour
exhibits
exhibits
Functional Behaviour
exhibits
exhibits
1..*
1..*
participates
Requirements Analysis
Analysis
Architectural Design
Detailed Design
Molesini (UniBo) AOSE AOSE 2010 114 / 237
unibo-logo
The SODA Meta-modelSODA 2008/10/22
Actor Requirement
*1
Relation LegacySystem ExternalEnvironment
* 1
Task
1..*
1
Dependency
**
participates
**
participates
* *
participates
Function
* *
participates
Topology
*
*
participates
*
*
participates
1..*
1
1..*
1
0..*
1
0..*
1
0..*
1
Role
Action
1..*
1
performs
Interaction
Resource
Operation
1..*
1
provides
1..*
1
1
1..*
1..*
1
1
1..*
Space*
*
participates
1..*
1..*
participates
*
1
0..*
connection
1..*
1
1..*
1
Workspace
1..*
1..*
Agent
1
1..*
Artifact
1..*
1
perceives1..*
1
is allocated
Composition
Society Aggregate
Individual Artifact
Social Artifact
Environmental Artifact
1..*
1
participates
Rule
0..*
1..*
constrains
connection
** participates
* *
participates
1..* 1..*
constrains
1..*1..*
constrains
1..*
1..*constrains
1
1..*
1
1..*
1
1..*
Uses1..*1..* 1..*1..*
Manifests1..*
1..*1..*
1..*
Speaks to 1..* 1..*
participates
1..*
1..*
Links to
1..*
1..*
Autonomous Behaviour
exhibits
exhibits
Functional Behaviour
exhibits
exhibits
1..*
1..*
participates
Requirements Analysis
Analysis
Architectural Design
Detailed Design
Molesini (UniBo) AOSE AOSE 2010 114 / 237
unibo-logo
The SODA Meta-modelSODA 2008/10/22
Actor Requirement
*1
Relation LegacySystem ExternalEnvironment
* 1
Task
1..*
1
Dependency
**
participates
**
participates
* *
participates
Function
* *
participates
Topology
*
*
participates
*
*
participates
1..*
1
1..*
1
0..*
1
0..*
1
0..*
1
Role
Action
1..*
1
performs
Interaction
Resource
Operation
1..*
1
provides
1..*
1
1
1..*
1..*
1
1
1..*
Space*
*
participates
1..*
1..*
participates
*
1
0..*
connection
1..*
1
1..*
1
Workspace
1..*
1..*
Agent
1
1..*
Artifact
1..*
1
perceives1..*
1
is allocated
Composition
Society Aggregate
Individual Artifact
Social Artifact
Environmental Artifact
1..*
1
participates
Rule
0..*
1..*
constrains
connection
** participates
* *
participates
1..* 1..*
constrains
1..*1..*
constrains
1..*
1..*constrains
1
1..*
1
1..*
1
1..*
Uses1..*1..* 1..*1..*
Manifests1..*
1..*1..*
1..*
Speaks to 1..* 1..*
participates
1..*
1..*
Links to
1..*
1..*
Autonomous Behaviour
exhibits
exhibits
Functional Behaviour
exhibits
exhibits
1..*
1..*
participates
Requirements Analysis
Analysis
Architectural Design
Detailed Design
Molesini (UniBo) AOSE AOSE 2010 114 / 237
unibo-logo
The SODA Process
Requirements Analysis
Analysis
Layering
Architectural Design
Layering
Detailed Design
Is the problem well specified?
no
Is the system well specified?
yes
yes no
Are there problems in the system?
yes
no
Molesini (UniBo) AOSE AOSE 2010 115 / 237
unibo-logo
The SODA Layering
In-zoom Out-zoom
Projection
Select Layer
increases detail increases abstraction
new layer?
no
yes
Molesini (UniBo) AOSE AOSE 2010 116 / 237
unibo-logo
SODA: Example
Requirement Description
ManageStartUp creating call for papers anddefining the rules of the or-ganisation
ManageSubmission managing user registrationand paper submissions
ManagePartitioning partitioning papers based onthe conference structure
ManageAssignment managing the assignment pro-cess according to the organi-sation rules
ManageReview managing the review processand sending reviews to au-thors
Molesini (UniBo) AOSE AOSE 2010 117 / 237
unibo-logo
SODA: Example
Function Description
management user managing user information
management review managing review information
management paper managing paper information
management assignment managing assignment infor-mation
management partitioning managing partitioning infor-mation
management process managing start-up informa-tion
webSite web interface of the confer-ence
Molesini (UniBo) AOSE AOSE 2010 118 / 237
unibo-logo
SODA: Example
Rule Description
Deadline-Rule paper can be sent only if cur-rent time precedes the dead-line
User-Rule get user is possible if the re-quested user is the requester
or the requester is the PC-chair
Author-Rule author can access and modifyonly his public paper informa-tion
Match-Rule papers can be partitioned ac-cording key words
AutRev-Rule the PC-member cannot beone of the paper authors
Review-Rule the PC-member cannotaccess private informationabout his papers
Molesini (UniBo) AOSE AOSE 2010 119 / 237
unibo-logo
Outline
6 Meta-model
7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS
Molesini (UniBo) AOSE AOSE 2010 120 / 237
unibo-logo
The INGENIAS Methodology
The INGENIAS methodology covers the analysis and design of MASand it is intended for general use
The methodology is supported by the INGENIAS Development Kit(IDK), which contains a graphical editor for MAS specifications
Besides, the INGENIAS Agent Framework (IAF), integrated in theIDK, has been proposed for enabling a full model-driven developmentand transforming automatically specifications into code in the JavaAgent Development Framework
The software development process proposed by the methodology isbased on RUP [Kruchten, 2003]
The methodology distributes the tasks of analysis and design in threeconsecutive phases: Inception, Elaboration and Construction
Each phase may have several iterations (where iteration means acomplete cycle of development)
Molesini (UniBo) AOSE AOSE 2010 121 / 237
unibo-logo
The INGENIAS Methodology
INGENIAS follows the Model Driven Development(MDD), so it isbased on the definition of a set of meta-models that describe theelements that form a MAS from several viewpoints
The specification of a MAS is structured in five viewpoints:1 the definition, control and management of each agent mental state2 the agent interactions3 the MAS organisation4 the environment5 the tasks and goals assigned to each agent
Molesini (UniBo) AOSE AOSE 2010 122 / 237
unibo-logo
The INGENIAS Meta-model
Molesini (UniBo) AOSE AOSE 2010 123 / 237
unibo-logo
The INGENIAS Process
Molesini (UniBo) AOSE AOSE 2010 124 / 237
unibo-logo
INGENIAS: Example
Molesini (UniBo) AOSE AOSE 2010 125 / 237
unibo-logo
INGENIAS: Example
Molesini (UniBo) AOSE AOSE 2010 126 / 237
unibo-logo
Part IV
Methodologies Documentation & Situational MethodEngineering
Molesini (UniBo) AOSE AOSE 2010 127 / 237
unibo-logo
Outline
8 Methodologies Documentation
9 Situational Method Engineering
10 Situational Method Engineering in AOSESPEM and AOSE processesMethod Fragment RepresentationPRODE: PROcess DEsign for design processes
11 Result Evaluation
Molesini (UniBo) AOSE AOSE 2010 128 / 237
unibo-logo
AOSE & Processes
As said before, in the software engineering field, there is commonagreement in that there is not a unique methodology or process,which fits all the application domains
This means that the methodology or process must be adapted to theparticular characteristics of the domain for which the new software isdeveloped
There are two major ways for adapting methodologies:I tailoring: particularization or customization of a pre-existing processesI Situational Method Engineering (SME): process is assembled from
pre-existent components, called fragments, according to user’s needs(see next section)
The research on SME has become crucial in AOSE since a variety ofspecial-purpose agent-oriented methodologies have been defined inthe past years to discipline and support the MASs development
Molesini (UniBo) AOSE AOSE 2010 129 / 237
unibo-logo
AOSE & Processes
Each of the AO methodologies proposed until now presents specificmeta-model, notation, and process
These characteristicsI are fundamental for a correct comprehension of a methodologyI should be documented in a proper way for supporting the creation of
new ad-hoc AOSE methodologies
SME is strictly related to the documentation of the existingmethodologies
→ the successfully construction of a new process is based on the correctintegration of different fragments that should be well formalised
→ The methodologies’ documentation should be done in a standard wayin order to facilitate
I the user’s comprehensionI the adoption of automatic tools able to interpret the fragment
documentation
Molesini (UniBo) AOSE AOSE 2010 130 / 237
unibo-logo
Methodologies Documentation
The IEEE FIPA Design Process Documentation and Fragmentation(DPDF) working group [DPDF, 2009] has recently proposed atemplate for documenting AO methodologies
This templateI has been conceived without considering any particular process or
methodology → all processes can be documented using itI is neutral regarding the MAS meta-model and/or the modelling
notation adopted in describing the processI has a simple structure resembling a tree, so documentation is made in
a natural and progressive way:F addressing in first place the general description and meta-model
definition which constitute the root elements of the processF detailing in a second step the branches which are the phases
I is easy to use for a software engineer as it relies on few previousassumptions
I suggests as notation the use of the OMG’s standard SPEM[Object Management Group, 2008] with few extensions[Seidita et al., 2008] (see next section)
Molesini (UniBo) AOSE AOSE 2010 131 / 237
unibo-logo
Template structure
1.Introduction1.1.The (process name) Process lifecycle1.2.The (process name) Metamodel1.2.1. Definition of MAS metamodel elements
2.Phases of the (process name) Process2.1.(First) Phase2.1.1.Process roles2.1.2.Activity Details2.1.3.Work Products
2.2 (Second) Phase2.2.1.Process roles2.2.2.Activity Details2.2.3.Work Products
. . . (further phases) . . .3.Work Product Dependencies
Molesini (UniBo) AOSE AOSE 2010 132 / 237
unibo-logo
Methodologies Documentation: benefits
The template helpsI in easily catching/understanding/studying the methodology: it seems
evident the facility of studying another methodology when the new oneuses an approach we already know
I in reusing partsI in identifying similarities and differences in the methodologies
Molesini (UniBo) AOSE AOSE 2010 133 / 237
unibo-logo
Methodologies Documentation: examples
Examples. . .
Molesini (UniBo) AOSE AOSE 2010 134 / 237
unibo-logo
Outline
8 Methodologies Documentation
9 Situational Method Engineering
10 Situational Method Engineering in AOSESPEM and AOSE processesMethod Fragment RepresentationPRODE: PROcess DEsign for design processes
11 Result Evaluation
Molesini (UniBo) AOSE AOSE 2010 135 / 237
unibo-logo
Methodologies
As for software development, individual methodologies are oftencreated with specific purposes in mind [Henderson-Sellers, 2005]
I particular domainsI particular segments of the lifecycle
Users often make the assumption that a methodology in not in factconstrained but, rather, is universally applicable
This can easily lead to methodology failure, and to the total rejectionof methodological thinking by software development organisation
The creation of a single universally applicable methodology is anunattainable goal
We should ask ourselves how could we create a methodologicalenvironment in which the various demands of different softwaredevelopers might be satisfied altogether
Molesini (UniBo) AOSE AOSE 2010 136 / 237
unibo-logo
Method Engineering
Method Engineering [Brinkkemper, 1996]
Method engineering is the engineering discipline to design, construct andadapt methods, techniques and tools for the development of informationsystems
Molesini (UniBo) AOSE AOSE 2010 137 / 237
unibo-logo
Method & Methodology
? ??
Method?Methododology?
All the concepts and ideas usedin the Method Engineering arealso applicable to our definitionsof methodology and method
Method Engineering tries tomodel methodological processesand products by isolatingconceptual method fragments
These fragments act asmethodological “buildingblocks”
Molesini (UniBo) AOSE AOSE 2010 138 / 237
unibo-logo
Method & Methodology
? ??
Method?Methododology? All the concepts and ideas usedin the Method Engineering arealso applicable to our definitionsof methodology and method
Method Engineering tries tomodel methodological processesand products by isolatingconceptual method fragments
These fragments act asmethodological “buildingblocks”
Molesini (UniBo) AOSE AOSE 2010 138 / 237
unibo-logo
Method Engineering: Motivations
Adaptability – to specificprojects, companies, needs &new development settings
Reuse – of best practices,theories & tools
Molesini (UniBo) AOSE AOSE 2010 139 / 237
unibo-logo
Method Engineering: Motivations
Adaptability – to specificprojects, companies, needs &new development settings
Reuse – of best practices,theories & tools
Molesini (UniBo) AOSE AOSE 2010 139 / 237
unibo-logo
Method Engineering: Concerns
Similarly as software engineering is concerned with all aspects ofsoftware production, so is method engineering dealing with allengineering activities related to methods, techniques and tools
The term method engineering is not new but it was alreadyintroduced in mechanical engineering to describe the construction ofworking methods in factories
Even if the work of Brinkkemper is dated, most of the open researchissues he presented are not well addressed yet
I meta-modelling techniquesI tool interoperabilityI situational method(ology)I comparative review of method(ologie)s and tools
Molesini (UniBo) AOSE AOSE 2010 140 / 237
unibo-logo
Situational Methodologies
A situational method is an information systems development methodtuned to the situation of the project at hand
Engineering a situational method requires standardised buildingblocks and guide-lines, so-called meta-methods, to assemble thesebuilding blocks
Critical to the support of engineering situational methods is theprovision of standardised method building blocks that are stored andretrievable from a so-called method base
Furthermore, a configuration process should be set up that guides theassembly of these building blocks into a situational method
The building blocks, called method fragments, are defined as coherentpieces of information system development methods
Molesini (UniBo) AOSE AOSE 2010 141 / 237
unibo-logo
Configuration Process [Brinkkemper, 1996]
Molesini (UniBo) AOSE AOSE 2010 142 / 237
unibo-logo
Situational Method Engineering I
Every project is different, so it is essential in the method configurationprocess to characterise the project according to a list of contingencyfactors
This project characterisation is an input to the selection process,where method fragments from the method base are retrieved
Experienced method engineers may also work the other way round,i.e. start with the selection of method fragments and validate thischoice against the project characterisation
The unrelated method fragments are then assembled into asituational method
As the consistency and completeness of the method may requireadditional method fragments, the selection and validation processescould be repeated
Finally, the situational method is forwarded to the systems developersin the project
Molesini (UniBo) AOSE AOSE 2010 143 / 237
unibo-logo
Situational Method Engineering II
As the project may not be definitely clear at the start, a furtherelaboration of the situational method can be performed during thecourse of the project
Similarly drastic changes in the project require to change thesituational method by the removal of inappropriate fragmentsfollowed by the insertion of suitable ones
Molesini (UniBo) AOSE AOSE 2010 144 / 237
unibo-logo
And Now?
Two important questionsI how to represent method
fragments?I how to assembly method
fragments?
To assemble method fragmentsinto a meaningful method, weneed a procedure andrepresentation to model methodfragments and impose someconstraints or rules on methodassembly processes
Molesini (UniBo) AOSE AOSE 2010 145 / 237
unibo-logo
Outline
8 Methodologies Documentation
9 Situational Method Engineering
10 Situational Method Engineering in AOSESPEM and AOSE processesMethod Fragment RepresentationPRODE: PROcess DEsign for design processes
11 Result Evaluation
Molesini (UniBo) AOSE AOSE 2010 146 / 237
unibo-logo
Agent Oriented Situational Method Engineering
The development methodology is built by the developer by assemblingpieces of the process (method fragments) from a method base
The method base is composed of contributions coming from existingmethodologies and other novel and specifically conceived fragments
This is the approach used within the FIPA Technical CommitteeMethodology (2003-2005)
Molesini (UniBo) AOSE AOSE 2010 147 / 237
unibo-logo
The normal agent development process
Molesini (UniBo) AOSE AOSE 2010 148 / 237
unibo-logo
Situational Method Engineering
Molesini (UniBo) AOSE AOSE 2010 149 / 237
unibo-logo
Situational Method Engineering
Molesini (UniBo) AOSE AOSE 2010 149 / 237
unibo-logo
Adopting Situational Method Engineering
What do I need?I a collection of method fragmentsI some guidelines about how to assemble fragmentsI a CAME (Computer Aided Method Engineering) toolI an evaluation framework (is my new methodology really good?)
Molesini (UniBo) AOSE AOSE 2010 150 / 237
unibo-logo
CAME Tool
This tool is based on the method meta-model and it is responsible formethod fragment specification, i.e. their product and process partsdefinition
Method fragment specification can be done “from scratch”, byassembly or by modification
In the first case product and process models of the fragments aredefined by instantiating the method meta-model used by the tool
In the second case fragments are assembled in order to satisfy somespecific situation
In the third case fragments are obtained by modification of otherfragments in order to better satisfy the method goal
Depending to the method meta-model, the CAME tool should offergraphical modelling facilities and special features
Molesini (UniBo) AOSE AOSE 2010 151 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
All methodologies are expressed in a
standard notation (we adopt SPEM by OMG)
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
Fragments are identified and
described according to the previous discussed
definition
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
New fragments are defined if necessary
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
A method fragments repository is composed
with all existing fragments
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
The desired MAS-Meta-Model is
composed according to problem specific needs (for instance including or not self-organizing
agents)
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
A CAME (Computer Aided Method
Engineering) tool assists in the selection
of fragments and composition of design
process
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
A new and problem specific methodology is
built
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
A CASE (Computer Aided Software
Engineering) tool is used to effectively
design the multi-agent system
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
The new process production
ExistingMethodo-
logies
MethodBase
MethodFragmentsExtraction
NewMethod
Fragments
CAME tool SpecificMethodo-
logy
MASMeta-Model
CASE tool Specificproblem
MAS runningon agent platforms
MASModelDeployment
The multi-agent system has been
coded, tested and is ready to be deployed
Molesini (UniBo) AOSE AOSE 2010 152 / 237
unibo-logo
So we need..
A meta-model for modelling and design an AOSE process
A specific description of an AOSE fragment
A way for assembly AOSE fragments
Molesini (UniBo) AOSE AOSE 2010 153 / 237
unibo-logo
The process description
Three are the main elements of a design processI activityI process roleI work product
AOSE processes are also affected byI MAS Meta-model (MMM) Element
SPEM does not support the MMM Elements
Molesini (UniBo) AOSE AOSE 2010 154 / 237
unibo-logo
Extending SPEM Specifications [Seidita et al., 2009a]
MMM is the starting point for the construction of a new designprocess
I each part (one or more elements) of this meta-model can beinstantiated in one (or more) fragment(s)
Each fragment refers to one (or more) MMM element(s)I refers = instantiates/relates/quotes/refines
The MMM element is the constituent part of a Work Product
The MMM is not part of the SPEM meta-modelI it is the element which leads us in modifying and extending SPEM
diagram
Molesini (UniBo) AOSE AOSE 2010 155 / 237
unibo-logo
Extending SPEM Specifications [Seidita et al., 2009a]
The need for establishing which is the real action a process roleperforms on a MMM element when he is carrying out a specificactivity
The set of actions:I define – it is performed when a MMM element is introduced for the
first time and its features are defined in a portion of process (hence ina fragment)
I relate – when a relationship is created (defined) among two or moreMMM elements previously defined in another portion of process
I quote – a MMM element or a relationship is quoted in a specific workproduct
I refine – a MMM element attribute is defined or a value is identified forit
We also find useful to specify the work product kind by referring to anexplicit set of WP kinds
Molesini (UniBo) AOSE AOSE 2010 156 / 237
unibo-logo
Proposed icons
Molesini (UniBo) AOSE AOSE 2010 157 / 237
unibo-logo
Method fragment meta-model
The FIPA Methodology Technical Committee in 2003-2005 proposedthe following definition of method fragment [Cossentino et al., 2007a]
Molesini (UniBo) AOSE AOSE 2010 158 / 237
unibo-logo
What is a Method FragmentA fragment is a portion of the development process, composed as follows:
A portion of process (what is to be done, in what order), defined with aSPEM diagramOne or more deliverables (like (A)UML/UML diagrams, text documentsand so on)Some preconditions (they are a kind of constraint because it is notpossible to start the process specified in the fragment without therequired input data or without verifying the required guard condition)A list of concepts (related to the MAS meta-model) to be defined(designed) or refined during the specified process fragmentGuideline(s) that illustrates how to apply the fragment and best practicesrelated to thatA glossary of terms used in the fragment (in order to avoidmisunderstandings if the fragment is reused in a context that is differentfrom the original one)Other information (composition guidelines, platform to be used,application area and dependency relationships useful to assemblefragments) complete this definition.
Molesini (UniBo) AOSE AOSE 2010 159 / 237
unibo-logo
The PRODE approach for Agent-Oriented MethodEngineering [Seidita et al., 2009b]
MMM
Molesini (UniBo) AOSE AOSE 2010 160 / 237
unibo-logo
The PRODE Process Representation
Molesini (UniBo) AOSE AOSE 2010 161 / 237
unibo-logo
PRODE divided in three main areas of research
MMM
1) A collection of process fragments
Molesini (UniBo) AOSE AOSE 2010 162 / 237
unibo-logo
PRODE divided in three main areas of research
MMM
2) Guidelines for fragment assembling
Molesini (UniBo) AOSE AOSE 2010 162 / 237
unibo-logo
PRODE divided in three main areas of research
MMM
3) A CAPE (Computer Aided Process Engineering)
tool
Molesini (UniBo) AOSE AOSE 2010 162 / 237
unibo-logo
The CAPE tool: Metameth
Metameth is an (open-source) agent-oriented tool we built to supportour experiments in methodologies composition and their applicationin real projects.
Metameth is:I a CAPE tool: since it supports the definition of the design process
life-cycle and the positioning of the different method fragments in theintended place
I a CAME tool: since it allows the definition of different methodfragments
I a CASE tool: since it supports a distributed design process, it offersseveral (by now UML) graphical editors and an expert system forverifying the resulting system
Molesini (UniBo) AOSE AOSE 2010 163 / 237
unibo-logo
Metameth tool architecture
Molesini (UniBo) AOSE AOSE 2010 164 / 237
unibo-logo
Outline
8 Methodologies Documentation
9 Situational Method Engineering
10 Situational Method Engineering in AOSESPEM and AOSE processesMethod Fragment RepresentationPRODE: PROcess DEsign for design processes
11 Result Evaluation
Molesini (UniBo) AOSE AOSE 2010 165 / 237
unibo-logo
Results Evaluation: an open problem?
MMM
Results Evaluation is crucial also in process
improvement/reengineering
Molesini (UniBo) AOSE AOSE 2010 166 / 237
unibo-logo
AO Design Process Evaluation
Q.N. Tran, G. C. Low (2005). Comparison of Ten Agent-OrientedMethodologies. In Agent-Oriented Methodologies, chapter XII, pp.341-367. Idea Group.L. Cernuzzi, G. Rossi (2002). On the evaluation of agent orientedmethodologies. In: Proc. of the OOPSLA 2002 Workshop onAgent-Oriented Methodologies, pp. 21-30.Arnon Sturm, Dov Dori, Onn Shehory (2004). A Comparative Evaluationof Agent-Oriented Methodologies, in Methodologies and SoftwareEngineering for Agent Systems, Federico Bergenti, Marie-Pierre Gleizes,Franco Zambonelli (eds.)Khanh Hoa Dam, Michael Winikoff (2003). Comparing Agent-OrientedMethodologies. In proc. of the Agent-Oriented Information SystemsWorkshop at AAMAS03. Melbourne (AUS).P. Cuesta, A. Gomez, J. C. Gonzalez, and F. J. Rodriguez (2003). AFramework for Evaluation of Agent Oriented Methodologies.CAEPIA’2003L. Cernuzzi, M. Cossentino, F. Zambonelli (2005). Process Models forAgent-Based Development. International Journal on EngineeringApplications of Artificial Intelligence (EAAI). Elsevier.
Molesini (UniBo) AOSE AOSE 2010 167 / 237
unibo-logo
Details on AO processes evaluation[Numi Tran and Low, 2005]
Structure of the evaluation framework
Molesini (UniBo) AOSE AOSE 2010 168 / 237
unibo-logo
Details on AO processes evaluation
From:I Arnon Sturm, Dov Dori, Onn Shehory. A Comparative Evaluation of
Agent-Oriented Methodologies, in Methodologies and SoftwareEngineering for Agent Systems, Federico Bergenti, Marie-PierreGleizes, Franco Zambonelli (eds.)
Evaluation is based on:I concepts and properties (autonomy, proactiveness, . . . )I notations and modeling techniques (accessibility, expressiveness)I process (development context, Lifecycle coverage)I pragmatics (required expertise, scalability, . . . )
Molesini (UniBo) AOSE AOSE 2010 169 / 237
unibo-logo
Details on AO processes evaluation
From:I Khanh Hoa Dam, Michael Winikoff (2003). Comparing Agent-Oriented
Methodologies. In proc. of the Agent-Oriented Information SystemsWorkshop at AAMAS03. Melbourne (AUS).
Based on aquestionnaire
Reused andextended inAL3-AOSETFG3a
aSee AL3 AOSETFG 1-3 Final Reportat:http://www.pa.icar.cnr.it/cossentino/al3tf3/
Molesini (UniBo) AOSE AOSE 2010 170 / 237
unibo-logo
Details on AO processes evaluation
The Capability Maturity Model Integration (CMMI) [SEI, 2006a]I the overall goal of CMMI is to provide a framework that can share
consistent process improvement best practices and approaches, but canbe flexible enough to address the rapidly changing needs of thecommunity
I SCAMPI (Standard CMMI Assessment Method for ProcessImprovement)[SEI, 2006b] it is a schema for process evaluation in fivesteps: activation, diagnosis, definition, action, learning
Molesini (UniBo) AOSE AOSE 2010 171 / 237
unibo-logo
Details on AO processes evaluation: CMMI discrete levels
Levels are used in CMMI to describe an evolutionary pathrecommended for an organisation that wants to improve the processes
The maturity level of an organization provides a way to predict anorganization’s performance in a given discipline or set of disciplines
A maturity level is a defined evolutionary plateau for organizationalprocess improvement
Molesini (UniBo) AOSE AOSE 2010 172 / 237
unibo-logo
Details on AO processes evaluation: CMMI discrete levels
Maturity Level
Description
1-Initial processes are usually ad hoc and chaotic2-Managed processes are planned and executed in accordance
with policy3-Defined processes are well characterized and understood,
and are described in standards, procedures, tools, and methods
4-Quantitatively managed
the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes
5-Optimizing an organization continually improves its processes based on a quantitative understanding of the common causes of variation inherent in processes
AOSE processes are (at most) at level 3!!(only a few of them)
Molesini (UniBo) AOSE AOSE 2010 173 / 237
unibo-logo
Open issues
SME is perceived to be a difficult disciplineI this is only partially true. All new design processes creator performed
(usually in a disordered way) the steps proposed and studied by SMEI a greater diffusion of AO-SME can have positive effects on the
development of new AO design processes (specifically in new areas likeself-org)
Major problems with AO-SMEI AO processes deals with MAS metamodels and they are an open issue
in the agent communityI lack of standards (ISO specification vs FIPA proposal)
F lack of standard repository of fragments
I lack of stable (commercial quality) CAPE/CAME toolsI design process evaluation is still an open issue in both AO and OO
software engineering
Molesini (UniBo) AOSE AOSE 2010 174 / 237
unibo-logo
Part V
Research directions and conclusions
Molesini (UniBo) AOSE AOSE 2010 175 / 237
unibo-logo
Outline
12 Research directions and visions
13 Conclusions
14 List of interesting papers
Molesini (UniBo) AOSE AOSE 2010 176 / 237
unibo-logo
Mainstream AOSE Researches
MethodologyI dozens of methodologies proposed so farI mostly “pencil and papers” exercises with no confrontation with real
world problems. . .
Meta-methodologiesI interesting and worth to be explored, but. . .I these would require much more research coordination and more
feedback from real-world experiences
Models & NotationsI of great help to clarify agent-oriented abstractionsI no specific standard still exists
InfrastructuresI very interesting models but. . .I (the lack of) a pure agent-oriented language slows down the
implementation phase
Molesini (UniBo) AOSE AOSE 2010 177 / 237
unibo-logo
Is This Enough?
Let’s ask ourselves a simple basic question:I what does it mean engineering a MAS?I what is the actual subject of the engineering work?
What is a MAS in a world of:I world-wide social and computational networksI pervasive computing environmentsI sensor networks and embedded computing
There is not a single answer:I it depends on the observation level
In the physical world and in micro-electronics[Zambonelli and Omicini, 2004]
I micro level of observation: dominated by quantum phenomena (andand to be studied/engineered accordingly)
I macro level of observation: dominated by classical physicsI meso level of observation: quantum and classical phenomena both
appears (and have to be taken into account)
Molesini (UniBo) AOSE AOSE 2010 178 / 237
unibo-logo
AOSE Observation Levels
Micro scaleI small- medium-size MASsI control over each component (limited complexity single stakeholder)I this is the (only) focus of mainstream AOSE
Macro scaleI very large scale distributed MASsI no control over single components (decentralisation, multiple
stakeholders)I the kingdom of “self-organization” people
Meso scaleI micro scale components deployed in a macro scale scenarioI my own system influence and is influenced by the whole
Very rarely a fully fledged study can be limited to a single level ofobservation
I most MASs (even small scale) are openI deployed in some sort of macro scale systemI dynamically evolving together with the system
Molesini (UniBo) AOSE AOSE 2010 179 / 237
unibo-logo
Micro-Level Challenges (1)
Assessing AOSE AdvantagesI AO has clear advantages. What about AOSE?I methodologies, methodologies, methodologies. . . ;-(
F qualitative workI we need to show that AOSE
F helps saving money and human resourceF leads to higher quality software productsF quantitative comparison of AOSE vs. non-AOSE complex software
development
Pay Attention to the Software ProcessI most methodologies assume a “waterfall” model
F either implicitly or explicitlyF with no counterpart in industrial software development
I Need for:F agile processesF agent-specific flexible processes
I Cf. Knublauch 2002 “Extreme programming for MAS”, Cossentino2006: “Agile PASSI”
I Can meta-models be of help in that direction?
Molesini (UniBo) AOSE AOSE 2010 180 / 237
unibo-logo
Micro-Level Challenges (2)Agent-specific notations
I AUML is ok to spread acceptance but. . .F is it really suited for MASs?F and for complex systems in general?F even the mainstream SE community doubts about that. . .
I do more suitable notations exists?F agent-specific ones to be inventedF other non-UML approaches
I Cf. Sturm et al. 2003: OPM/MASI AML by Whitestein [Cervenka et al., 2005]I A proposal of unified notation by L. Padgham, M. Winikoff, S. De
Loach, M. Cossentino [Padgham et al., 2009]Intelligence engineering
I selling AI has always been difficultF lack of engineering flavor. . .
I agents can help with thatF embodied, modular, intelligenceF observable rationality
I our role should be that of:F exploiting scientific results from the AI-oriented MAS communityF turn them into usable engineered products
Molesini (UniBo) AOSE AOSE 2010 181 / 237
unibo-logo
Macro-Level Challenges (1)
The macro level deals with complex collective behaviour in large scaleMASs
I some say this is not AOSE. . .F scientific activityF observing and reproducing biology
I but it must become an engineering activityF challenging indeed
Universality in MASsI can general laws underlying the behaviour of complex MASs be
identified?F as they are starting being identified in the “complex systems” research
communityF phase transitions, edges of chaos, etc.
I letting us study and engineer complex MASF abstracting from the specific characteristics of agents (from ants to
rational BDI agents)F abstracting from the specific content of their interactions
I Cf. Van Parunak 2004: “Universality in MAS”
Molesini (UniBo) AOSE AOSE 2010 182 / 237
unibo-logo
Macro-Level Challenges (2)Measuring Complex MASs
I how can we characterise the behavior of large-scale MASs?F when we cannot characterise the behavior of single components
I macro-level measures must be identifiedF to concisely express properties of a systemF Cf. Entropy, Macro-properties of complex network, etc
I and tools must be provided to actually measure systemsI but measuring must be finalised
Controlling Complex MASsI given a measurable property of a MASsI software engineers must be able to direct the evolution of a system,
i.e., to tune the value of the measurable propertyF in a fully decentralised wayF and with the possibility of enforcing control over a limited portion of
the MASI software engineering will become strictly related to control systems
engineering
Emergent behaviors, physics, biology, etcI Cf. The activity of the “SELF ORGANIZATION” Agentlink group
Molesini (UniBo) AOSE AOSE 2010 183 / 237
unibo-logo
Meso-Level Challenges (1)
It is a problem of deploymentI engineering issues related to deployment of a MAS (typically
engineered at a micro level of observation). . .I . . . into a large scale system (to be studied at a macro-level of
observation)
Impact AnalysisI how will my system behave when it will deployed in an existing open
possibly large scale networked system?I how I will influence the existing system?I micro-scale aspects:
F tolerance to unpredictable environmental dynamics on my systemF internal handlings
I macro-scale aspect:F can my “small” MAS change the overall behaviour of the global
system?F “butterfly effect”?
Molesini (UniBo) AOSE AOSE 2010 184 / 237
unibo-logo
Meso-Level Challenges (2)Identifying the Boundaries
I how can I clearly identify what is part of my system and what is not?I I should identify
F potential inter-agent and environmental interactionsF shape the environment (i.e., via agentification)F engineer the interactions across the environment
I in sum: engineering the boundaries of the system
TrustI I can (provably) trust a “small” system of rational agentsI I can (probabilistically) trust a very large-scale MASsI what I can actually say about the small system deployed in the
large-scale oneF how can I measure the “degree of trust”?
Infrastructures for Open SystemsI are configurable context-dependent coordination infrastructure the
correct answer?I are normative approaches the correct ones?
F we know what we gain but we do not know what we lose
I Cf. Incentives in social and P2P networks
Molesini (UniBo) AOSE AOSE 2010 185 / 237
unibo-logo
Research directions and visions: conclusions
There is not a single AOSEI depends on the scale of observation. . .
The micro scaleI overwhelmed by researchI often neglecting very basic questions. . .
The macro scaleI some would say this is not AOSEI but it must become indeed. . .
The meso scaleI fascinating. . .I very difficult to be tackled with engineering approaches. . .
What else?I there is so much to engineer around. . .I emotional agents, mixed human-agent organisations, interactions with
the physical world. . .
Molesini (UniBo) AOSE AOSE 2010 186 / 237
unibo-logo
Outline
12 Research directions and visions
13 Conclusions
14 List of interesting papers
Molesini (UniBo) AOSE AOSE 2010 187 / 237
unibo-logo
Reflections
In this lecture we have spoken about Software Engineering and AgentOriented Software Engineering
Some reflections are necessary:I what are the aspects related to Engineering?I what are the aspects related to Software Engineering?I what are the aspects related to the paradigms adopted?
Molesini (UniBo) AOSE AOSE 2010 188 / 237
unibo-logo
What are the Aspects Related to Engineering?
Following a clear and disciplined development process
Adopting a design methodology
Creating an appropriate (mathematical?) model of a problem thatallows to analyse it
Testing potential solutions
Evaluating the different design choices and choosing the solution thatbest meets requirements
Using of: prototypes, scale models, simulations, destructive tests,nondestructive tests, and stress tests
Molesini (UniBo) AOSE AOSE 2010 189 / 237
unibo-logo
What are the Aspects Related to Software Engineering?
Customization to the specific kind of product: SoftwareI specific software development processes tied to the software lifecycleI specific methodologiesI specific kinds of model tied to the concept of software productI testing potential solutionsI using of specific techniques for: prototypes, scale models, simulations,
tests, and stress tests
Molesini (UniBo) AOSE AOSE 2010 190 / 237
unibo-logo
What are the Aspects Related to the paradigm?
The building blocks for creating the models
The level of thinking / abstraction
Functions, objects, agents lead to different ways of thinking both theproblems and the solutions
I the paradigm adopted leads to different levels of model complexity:complicated problems are well captured by objects and agents, whilefunctions could lead to have very very complex models for representingthe problem
I in the same way the models of the solution are heavily influenced bythe paradigm
Molesini (UniBo) AOSE AOSE 2010 191 / 237
unibo-logo
Outline
12 Research directions and visions
13 Conclusions
14 List of interesting papers
Molesini (UniBo) AOSE AOSE 2010 192 / 237
unibo-logo
Introduction to Agents and Multiagent Systems
(this is a very PARTIAL list, lots of very interesting refs are not reportedhere)
A. Newell, The Knowledge Level [Newell, 1982]
P. Wegner, Why Interaction is More Powerful than Algorithms[Wegner, 1997]
M. Wooldridge, Reasoning About Rational Agents [Wooldridge, 2001]
M. Wooldridge, N. Jennings, Intelligent Agents: Theory and Practice[Wooldridge and Jennings, 1995]
D. Chess, C. Harrison, A. Kershenbaum, Mobile Agents: are They aGood Idea? [Chess et al., 1996]
V. Parunak, Go to the Ant: Engineering Principles from NaturalAgent Systems [Parunak, 1997]
N. R. Jennings, An Agent-Based Approach for Building ComplexSoftware System [Jennings, 2001]
Molesini (UniBo) AOSE AOSE 2010 193 / 237
unibo-logo
Introduction to AOSE
N.R. Jennings, On Agent-Based Software Engineering[Jennings, 2000]
N. R. Jennings, P. Faratin, T. J. Norman, P. O’Brien, B. Odgers,Autonomous Agents for Business Process Management[Jennings et al., 2000]
M. J. Wooldridge and N. R. Jennings, Software Engineering withAgents: Pitfalls and Pratfalls [Wooldridge and Jennings, 1999]
Y. Shoham, An Overview of Agent-Oriented Programming[Shoham, 1997]
K. Siau and M. Rossi, Evaluation of Information Modeling Methods –A Review [Siau and Rossi, 1998]
F. Zambonelli, N. Jennings, M. Wooldridge, OrganizationalAbstractions for the Analysis and Design of multi-agent system[Zambonelli et al., 2001]
Molesini (UniBo) AOSE AOSE 2010 194 / 237
unibo-logo
Relevant References on AOSE(this is a very PARTIAL list, lots of very interesting refs are not reported here)
Books on AOSEI M. Luck, R. Ashri, M. D’Inverno, Agent-Based Software Development
[Luck et al., 2004]I F. Bergenti, M.-P. Gleizes, F. Zambonelli, Methodologies and Software
Engineering for Agent Systems [Bergenti et al., 2004]I B. Henderson-Sellers and P. Giorgini, Agent-Oriented Methodologies
[Henderson-Sellers and Giorgini, 2005]
Surveys and other papers on AOSEI F. Zambonelli, A. Omicini, Challenges and Research Directions in
Agent-Oriented Software Engineering [Zambonelli and Omicini, 2004],I C. Bernon, M. Cossentino, J. Pavon An Overview of Current Trends in
European AOSE Research [Bernon et al., 2005c],I C. Bernon, M. Cossentino, J. Pavon, Agent-oriented software engineering
[BERNON et al., 2006]I C. Iglesias, M. Garijo, J. C. Gonzales, A Survey of Agent-oriented
Methodologies [Iglesias et al., 1999]
Molesini (UniBo) AOSE AOSE 2010 195 / 237
unibo-logo
References on others AO Methodologies
ASPECS: [Cossentino et al., 2010]
MaSE: [DeLoach et al., 2001], [DeLoach and Kumar, 2005]
O-MaSE: [DeLoach, 2008], [DeLoach, 2006]
MESSAGE: [Caire et al., 2002], [Caire et al., 2004],[Garijo et al., 2005]
CommonKDS [Iglesias and Garijo, 2005]
AOR [Taveret and Wagner, 2005]
OPM-MAS [Sturm et al., 2003]
Molesini (UniBo) AOSE AOSE 2010 196 / 237
unibo-logo
References on Meta-models
C. Bernon, M. Cossentino, M.P. Gleizes, P. Turci, A Study of SomeMulti-agent Meta-models [Bernon et al., 2005b]
M. Cossentino, N. Gaud, S. Galland, V. Hilaire, A. Koukam, AHolonic Metamodel for Agent-Oriented Analysis and Design[Cossentino et al., 2007c]
M. Cossentino, S. Gaglio, L. Sabatucci, V. Seidita, The PASSI andAgile PASSI MAS Meta-models Compared with a Unifying Proposal[Cossentino et al., 2005]
A. Molesini, E. Denti, A. Omicini, MAS Meta-models on Test: UMLvs. OPM in the SODA Case Study [Molesini et al., 2005]
A. Molesini, E. Denti, A. Omicini, From AO Methodologies to MASInfrastructures: The SODA Case Study [Molesini et al., 2008a]
A. Susi, A. Perini, J. Mylopoulos, P. Giorgini, The Tropos Metamodeland its Use [Susi et al., 2005]
INGENIAS Home Page [Grasia Group, 2009]
Molesini (UniBo) AOSE AOSE 2010 197 / 237
unibo-logo
References on Processes
L. Cernuzzi, M. Cossentino, F. Zambonelli, Process Models forAgent-based Development [Cernuzzi et al., 2005]
B. Henderson-Sellers, C. Gonzalez-Perez. A comparison of fourprocess metamodels and the creation of a new generic standard[Henderson-Sellers and Gonzalez-Perez, 2005]
A. Molesini, N. Nardini, E. Denti, A. Omicini, SPEM on Test: theSODA Case Study [Nardini et al., 2008],
A. Molesini, N. Nardini, E. Denti, A. Omicini, Situated ProcessEngineering for Integrating Processes from Methodologies toInfrastructures [Molesini et al., 2009b]
A. Molesini, N. Nardini, E. Denti, A. Omicini, AdvancingObject-Oriented Standards Toward Agent-Oriented Methodologies:SPEM 2.0 on SODA [Molesini et al., 2008b],
A. Molesini, Meta-Models, Environment and Layers: Agent-OrientedEngineering of Complex Systems [Molesini, 2008]
Molesini (UniBo) AOSE AOSE 2010 198 / 237
unibo-logo
References on Method Engineering
S. Brinkkemper, Method engineering: engineering the informationsystems development methods and tools [Brinkkemper, 1996]
S. Brinkkemper, M. Saeki, F. Harmsen, Meta-Modelling BasedAssembly Techniques for Situational Method Engineering[Brinkkemper et al., 1999]
J.P. Tolvanen, Incremental method engineering with modeling tools:Theoretical principles and empirical evidence [Tolvanen, 1998]
B. Henderson-Sellers, J. Debenham, Towards open methodologicalsupport for agent-oriented systems development[Henderson-Sellers and Debenham, 2003]
M. Cossentino, S. Gaglio, A. Garro, V. Seidita. Method Fragments foragent design methodologies: from standardization to research[Cossentino et al., 2007a]
Molesini (UniBo) AOSE AOSE 2010 199 / 237
unibo-logo
References on MAS Infrastructures
Communication (FIPA-based) InfrastructuresI F. Bellifemine, A. Poggi, G. Rimassa, Developing Multi-Agent Systems with
a FIPA-Compliant Agent Framework [Bellifemine et al., 2001]I S. Poslad, P. Buckle, and R. Hadingham, The FIPA-OS Agent Platform:
Open Source for Open Standard [Poslad et al., ]I JACK Intelligent Agents [Busetta et al., ]
Coordination InfrastructuresI P. Ciancarini, A. Omicini, F. Zambonelli, Multi-agent System Engineering:
The Coordination Viewpoint [Ciancarini et al., 2000]I G. Cabri, L. Leonardi, F. Zambonelli, Engineering Mobile Agent
Applications via Context-Dependent Coordination [Cabri et al., 2002]I M. Viroli, M. Casadei, A. Omicini, A Framework for Modelling and
Implementing Self-Organising Coordination [Viroli et al., 2009]I A. Ricci, M. Piunti, M. Viroli, A. Omicini, Environment Programming in
CArtAgO [Ricci et al., 2009]
Molesini (UniBo) AOSE AOSE 2010 200 / 237
unibo-logo
Open Research Directions & Visions
F. Zambonelli, V. Parunak, From Design to Intention: Signs of aRevolution [Zambonelli and Parunak, 2002]V. Parunak, S. Bruekner, Entropy and Self-Organization in AgentSystems [Van Dyke Parunak and Brueckner, 2001]R. Albert, H. Jeong, A. Barabasi, Error and Attack Tolerance of ComplexNetworks [Albert et al., 2000]G. D. Abowd, E. D. Mynatt, Charting Past, Present and Future Researchin Ubiquitous Computing [Abowd and Mynatt, 2000]H. Abelson, D. Allen, D. Coore, C. Hanson, G. Homsy, T. Knight, R.Nagpal, E. Rauch, G. Sussman and R. Weiss, Amorphous Computing[Abelson et al., 2000]M. Mamei, F. Zambonelli, L. Leonardi, A Physically Grounded Approachto Coordinate Movements in a Team [Leonardi et al., 2002]A. Roli, F. Zambonelli, What Can Cellular Automata Tell Us About theBehavior of Large Multiagent Systems? [Zambonelli et al., 2002]J. Doyle, J. M Carlson, Highly Optimized Tolerance: A Mechanism forPower Laws in Designed Systems [Carlson and Doyle, 1999]
Molesini (UniBo) AOSE AOSE 2010 201 / 237
unibo-logo
Bibliography I
Abelson, H., Allen, D., Coore, D., Hanson, C., Homsy, G., Knight, Jr.,T. F., Nagpal, R., Rauch, E., Sussman, G. J., and Weiss, R. (2000).Amorphous computing.Commun. ACM, 43(5):74–82.
Abowd, G. D. and Mynatt, E. D. (2000).Charting past, present, and future research in ubiquitous computing.ACM Trans. Comput.-Hum. Interact., 7(1):29–58.
Albert, R., Jeong, H., and Barabasi, A.-L. (2000).Error and attack tolerance of complex networks.Nature, 406(6794):378–382.
Bellifemine, F., Poggi, A., and Rimassa, G. (2001).Developing multi-agent systems with a fipa-compliant agentframework.Software—-Practice & Experience, 31(2):103–128.
Molesini (UniBo) AOSE AOSE 2010 202 / 237
unibo-logo
Bibliography II
Bergenti, F., Gleizes, M.-P., and Zambonelli, F., editors (2004).Methodologies and Software Engineering for Agent Systems: TheAgent-Oriented Software Engineering Handbook, volume 11 ofMultiagent Systems, Artificial Societies, and Simulated Organizations.Kluwer Academic Publishers.
Bernon, C., Camps, V., Gleizes, M.-P., and Picard, G. (2005a).Engineering adaptive multi-agent systems: the adelfe methodology.In Agent Oriented Methodologies, chapter VII, pages 172–202. IdeaGroup Publishing.
Bernon, C. and Capera, Davyand Mano, J.-P. (2008).Engineering self-modeling systems: Application to biology.In ESAW, pages 248–263.
Bernon, C., Cossentino, M., Gleizes, M., and Turci, P. (2005b).A study of some multi-agent meta-models.Agent-Oriented Software Engineering V: 5th International . . . .
Molesini (UniBo) AOSE AOSE 2010 203 / 237
unibo-logo
Bibliography III
Bernon, C., Cossentino, M., Gleizes, M. P., Turci, P., and Zambonelli,F. (2004).A study of some multi-agent meta-models.In Odell, J., Giorgini, P., and Muller, J. P., editors, AOSE, volume3382 of Lecture Notes in Computer Science, pages 62–77. Springer.
Bernon, C., Cossentino, M., and Pavon, J. (2005c).An overview of current trends in european aose research.Informatica Journal, 29(4).
BERNON, C., COSSENTINO, M., and PAVON, J. (2006).Agent-oriented software engineering.The Knowledge Engineering Review, 20(02):99–116.
Molesini (UniBo) AOSE AOSE 2010 204 / 237
unibo-logo
Bibliography IV
Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., and Perini,A. (2004).Tropos: An agent-oriented software development methodology.Autonomous Agent and Multi-Agent Systems, 3:203–236.
Brinkkemper, S. (1996).Method engineering: engineering of information systems developmentmethods and tools.Information & Software Technology, 38(4):275–280.
Brinkkemper, S., Saeki, M., and Harmsen, F. (1999).Meta-modelling based assembly techniques for situational methodengineering.Inf. Syst., 24(3):209–228.
Molesini (UniBo) AOSE AOSE 2010 205 / 237
unibo-logo
Bibliography V
Busetta, P., Ronnquist, R., Hodgson, A., and Lucas, A.Jack intelligent agent.http://www.agent-software.com.au/.
Cabri, G., Leonardi, L., and Zambonelli, F. (2002).Engineering mobile agent applications via context-dependentcoordination.Software Engineering, IEEE Transactions on, 28(11):1039–1055.
Caire, G., Coulier, W., Garijo, F., Gomez-Sanz, J., Pavon, J., Kearney,P., and Massonet, P. (2004).The MESSAGE methodology.In [Bergenti et al., 2004], chapter 9, pages 177–194.
Molesini (UniBo) AOSE AOSE 2010 206 / 237
unibo-logo
Bibliography VI
Caire, G., Coulier, W., Garijo, F. J., Gomez, J., Pavon, J., Leal, F.,Chainho, P., Kearney, P. E., Stark, J., Evans, R., and Massonet, P.(2002).Agent oriented analysis using Message/UML.In Wooldridge, M., Weiss, G., and Ciancarini, P., editors,Agent-Oriented Software Engineering II, volume 2222 of LNCS, pages119–135. Springer.2nd International Workshop (AOSE 2001), Montreal, Canada, 29 May2001. Revised Papers and Invited Contributions.
Capera, D., Picard, G., and Gleizes, M.-P. (2004).Applying adelfe methodology to a mechanism design problem.In AAMAS ’04: Proceedings of the Third International JointConference on Autonomous Agents and Multiagent Systems, pages1508–1509, Washington, DC, USA. IEEE Computer Society.
Molesini (UniBo) AOSE AOSE 2010 207 / 237
unibo-logo
Bibliography VII
Carlson, J. M. and Doyle, J. (1999).Highly optimized tolerance: A mechanism for power laws in designedsystems.Physical Review E, 60(2):1412–1427.
Cernuzzi, L., Cossentino, M., and Zambonelli, F. (2005).Process models for agent-based development.Engineering Applications of Artificial Intelligence, 18(2):205–222.
Cernuzzi, L., Molesini, A., Omicini, A., and Zambonelli, F. (2009).Adaptable multi-agent systems: The case of the gaia methodology.International Journal of Software Engineering and KnowledgeEngineering.
Molesini (UniBo) AOSE AOSE 2010 208 / 237
unibo-logo
Bibliography VIII
Cervenka, R., Trencansky, I., Calisti, M., and Greenwood, D. (2005).AML: Agent Modeling Language Toward Industry-Grade Agent-BasedModeling.Agent-Oriented Software Engineering V: 5th International Workshop,AOSE 2004, New York, NY, USA, July 19, 2004: Revised SelectedPapers.
Chess, D. M., Harrison, C. G., and Kershenbaum, A. (1996).Mobile agents: Are they a good idea?In Vitek, J. and Tschudin, C. F., editors, Mobile Object Systems,volume 1222 of Lecture Notes in Computer Science, pages 25–45.Springer.
Molesini (UniBo) AOSE AOSE 2010 209 / 237
unibo-logo
Bibliography IX
Ciancarini, P., Omicini, A., and Zambonelli, F. (2000).Multiagent system engineering: The coordination viewpoint.In Jennings, N. R. and Lesperance, Y., editors, Intelligent Agents VI.Agent Theories, Architectures, and Languages, volume 1757 of LNAI,pages 250–259. Springer.6th International Workshop (ATAL’99), Orlando, FL, USA,15–17 July 1999. Proceedings.
Cossentino, M. (2005).From requirements to code with the PASSI methodology.In [Henderson-Sellers and Giorgini, 2005], chapter IV, pages 79–106.
Molesini (UniBo) AOSE AOSE 2010 210 / 237
unibo-logo
Bibliography X
Cossentino, M., Fortino, G., Garro, A., Mascillaro, S., and Russo, W.(2008).Passim: A simulation-based process for the development ofmulti-agent systems.International Journal on Agent Oriented Software Engineering(IJAOSE).
Cossentino, M., Gaglio, S., Garro, A., and Seidita, V. (2007a).Method fragments for agent design methodologies: fromstandardisation to research.International Journal of Agent-Oriented Software Engineering(IJAOSE), 1(1):91–121.
Molesini (UniBo) AOSE AOSE 2010 211 / 237
unibo-logo
Bibliography XI
Cossentino, M., Gaglio, S., Sabatucci, L., and Seidita, V. (2005).The passi and agile passi mas meta-models compared with a unifyingproposal.In Proc. of the CEEMAS’05 Conference. Lecture Notes in ComputerScience, pages 183–192. Springer Verlag, Budapest, Hungary.
Cossentino, M., Gaglio, S., and V., S. (2007b).Adapting passi to support a goal oriented approach: a situationalmethod engineering experiment.In Proc. of the Fifth European workshop on Multi-Agent Systems(EUMAS’07).
Cossentino, M., Gaud, N., Galland, S., Hilaire, V., and Koukam, A.(2007c).A Holonic Metamodel for Agent-Oriented Analysis and Design.LECTURE NOTES IN COMPUTER SCIENCE, 4659:237.
Molesini (UniBo) AOSE AOSE 2010 212 / 237
unibo-logo
Bibliography XII
Cossentino, M., Gaud, N., Hilaire, V., Galland, S., and Koukam, A.(2010).Aspecs: an agent-oriented software process for engineering complexsystems.International Journal of Autonomous Agents and Multi-Agent Systems(IJAAMAS).
DeLoach, S., Wood, M., and Sparkman, C. (2001).Multiagent Systems Engineering.International Journal of Software Engineering and KnowledgeEngineering, 11(3):231–258.
Molesini (UniBo) AOSE AOSE 2010 213 / 237
unibo-logo
Bibliography XIII
DeLoach, S. A. (2006).Engineering organization-based multiagent systems.In Garcia, A. F., Choren, R., Lucena, C., Giorgini, P., Holvoet, T., andRomanovsky, A., editors, Software Engineering for Multi-AgentSystems IV. Research Issues and Practical Applications, volume 3914of LNCS, pages 109–125. Springer.
DeLoach, S. A. (2008).Developing a multiagent conference management system using theO-MaSE process framework.volume 4951 of LNCS, pages 168–181. Springer.8th International Workshop (AOSE 2007), Honolulu, HI, USA, May14, 2007, Revised Selected Papers.
DeLoach, S. A. and Kumar, M. (2005).Multi-agent systems engineering: An overview and case study.In [Henderson-Sellers and Giorgini, 2005], chapter XI, pages 317–340.
Molesini (UniBo) AOSE AOSE 2010 214 / 237
unibo-logo
Bibliography XIV
DeLoach, S. A., Padgham, L., Perini, A., Susi, A., and Thangarajah,J. (2009).Using three aose toolkits to develop a sample design.IJAOSE, 3(4):416–476.
DPDF (2009).IEEE FIPA Design Process Documentation and FragmentationHomepage.http://www.pa.icar.cnr.it/cossentino/fipa-dpdf-wg/.
Fuggetta, A. (2000).Software process: a roadmap.In ICSE ’00: Proceedings of the Conference on The Future ofSoftware Engineering, pages 25–34, New York, NY, USA. ACM Press.
Molesini (UniBo) AOSE AOSE 2010 215 / 237
unibo-logo
Bibliography XV
Garcıa-Magarino, I., Gutierrez, C., and Fuentes-Fernandez, R. (2009).The ingenias development kit: a practical application forcrisis-management.In The 10th International Work conference on Artificial NeuronalNetworks (IWANN2009).
Garijo, F. J., Gomez-Sanz, J. J., and Massonet, P. (2005).The MESSAGE methodology for agent-oriented analysis and design.In [Henderson-Sellers and Giorgini, 2005], chapter VIII, pages203–235.
Ghezzi, C., Jazayeri, M., and Mandrioli, D. (2002).Foundamental of Software Engineering.Prentice Hall, second edition.
Grasia Group (2009).Ingenias meta model.http://grasia.fdi.ucm.es/main/?q=en/node/135.
Molesini (UniBo) AOSE AOSE 2010 216 / 237
unibo-logo
Bibliography XVI
Hadar, I., Kuflik, T., Perini, A., Reinhartz-Berger, I., Ricca, F., andSusi, A. (2010).An empirical study of requirements model understanding: Use case vs.tropos models.In SAC ’10: Proceedings of the 2010 ACM Symposium on AppliedComputing, pages 2324–2329, New York, NY, USA. ACM.
Henderson-Sellers, B. (2005).Creating a comprensive agent-oriented methodology: Using methodengineering and the OPEN metamodel.In [Henderson-Sellers and Giorgini, 2005], chapter XIII, pages236–397.
Molesini (UniBo) AOSE AOSE 2010 217 / 237
unibo-logo
Bibliography XVII
Henderson-Sellers, B. and Debenham, J. (2003).Towards open methodological support for agent-oriented systemdevelopment.In Procs. First International Conference on Agent-Based Technologiesand Systems, pages 14–24, Canada.
Henderson-Sellers, B. and Giorgini, P. (2005).Agent Oriented Methodologies.Idea Group Publishing, Hershey, PA, USA.
Henderson-Sellers, B. and Gonzalez-Perez, C. (2005).A comparison of four process metamodels and the creation of a newgeneric standard.Information and Software Technology, 47(1):49 –65.
Molesini (UniBo) AOSE AOSE 2010 218 / 237
unibo-logo
Bibliography XVIII
Iglesias, C., Garijo, M., and Gonzalez, J. (1999).A Survey of Agent-Oriented Methodologies.Intelligent Agents V: Agent Theories, Architectures, and Languages:5th International Workshop, Atal’98: Paris, France, July 1998:Proceedings.
Iglesias, C. A. and Garijo, M. (2005).Agent-oriented methodology MAS-CommonKADS.In [Henderson-Sellers and Giorgini, 2005], chapter III, pages 46–78.
Jennings, N. R. (2000).On agent-based software engineering.Artificial Intelligence, 117(2):277–296.
Jennings, N. R. (2001).An agent-based approach for building complex software systems.Communication ACM, 44(4):35–41.
Molesini (UniBo) AOSE AOSE 2010 219 / 237
unibo-logo
Bibliography XIX
Jennings, N. R., Faratin, P., Norman, T. J., O’Brien, P., and Odgers,B. (2000).Autonomous agents for business process management.Int. Journal of Applied Artificial Intelligence, 2(14):145–189.
Kruchten, P. (2003).The Rational Unified Process: An Introduction.Addison-Wesley Professional, 3rd edition.
Leonardi, L., Mamei, M., and Zambonelli, F. (2002).A physically grounded approach to coordinate movements in a team.In ICDCSW ’02: Proceedings of the 22nd International Conference onDistributed Computing Systems, pages 373–378, Washington, DC,USA. IEEE Computer Society.
Molesini (UniBo) AOSE AOSE 2010 220 / 237
unibo-logo
Bibliography XX
Luck, M., Ashri, R., and DInverno, M. (2004).Agent-Based Software Development.Artech House.
Molesini, A. (2008).Meta-Models, Environment and Layers: Agent-Oriented Engineeringof Complex Systems.PhD thesis, Dottorato in Ingegneria Elettronica, Informatica e delleTelecomunicazioni, Bologna, Italy.
Molesini, A., Denti, E., and Omicini, A. (2005).MAS meta-models on test: UML vs. OPM in the SODA case study.In Pechoucek, M., Petta, P., and Varga, L. Z., editors, Multi-AgentSystems and Applications IV, volume 3690 of LNAI, pages 163–172.Springer.
Molesini (UniBo) AOSE AOSE 2010 221 / 237
unibo-logo
Bibliography XXI
4th International Central and Eastern European Conference onMulti-Agent Systems (CEEMAS’05), Budapest, Hungary,15–17 September 2005, Proceedings.
Molesini, A., Denti, E., and Omicini, A. (2008a).From AO methodologies to MAS infrastructures: The SODA casestudy.In Artikis, A., O’Hare, G., Stathis, K., and Vouros, G., editors,Engineering Societies in the Agents World VIII, volume 4995 of LNCS,pages 300–317. Springer.8th International Workshop (ESAW’07), 22–24 October 2007, Athens,Greece. Revised Selected Papers.
Molesini (UniBo) AOSE AOSE 2010 222 / 237
unibo-logo
Bibliography XXII
Molesini, A., Denti, E., and Omicini, A. (2009a).RBAC-MAS & SODA: Experimenting RBAC in AOSE.In Artikis, A., Picard, G., and Vercouter, L., editors, EngineeringSocieties in the Agents World IX, volume 5485 of LNCS. Springer.9th International Workshop (ESAW’08), 24–26 September 2008,Saint-Etienne, France. Revised Selected Papers.
Molesini, A., Denti, E., and Omicini, A. (2010).Agent-based conference management: A case study in SODA.International Journal of Agent-Oriented Software Engineering,4(1):1–31.
Molesini (UniBo) AOSE AOSE 2010 223 / 237
unibo-logo
Bibliography XXIII
Molesini, A., Nardini, E., Denti, E., and Omicini, A. (2008b).Advancing object-oriented standards toward agent-orientedmethodologies: SPEM 2.0 on SODA.In Baldoni, M., Cossentino, M., De Paoli, F., and Seidita, V., editors,9th Workshop ”From Objects to Agents” (WOA 2008) – Evolution ofAgent Development: Methodologies, Tools, Platforms and Languages,pages 108–114, Palermo, Italy. Seneca Edizioni.
Molesini, A., Nardini, E., Denti, E., and Omicini, A. (2009b).Situated process engineering for integrating processes frommethodologies to infrastructures.In Shin, S. Y., Ossowski, S., Menezes, R., and Viroli, M., editors, 24thAnnual ACM Symposium on Applied Computing (SAC 2009),volume II, pages 699–706, Honolulu, Hawai’i, USA. ACM.
Molesini (UniBo) AOSE AOSE 2010 224 / 237
unibo-logo
Bibliography XXIV
Nardini, E., Molesini, A., Omicini, A., and Denti, E. (2008).SPEM on test: the SODA case study.In Wainwright, R. L., Haddad, H. M., Menezes, R., and Viroli, M.,editors, 23th ACM Symposium on Applied Computing (SAC 2008),volume 1, pages 700–706, Fortaleza, Ceara, Brazil. ACM.Special Track on Software Engineering.
Newell, A. (1982).The knowledge level.Artificial Intelligence, 18(1):87–127.
Numi Tran, Q.-N. and Low, G. C. (2005).Comparison of ten agent-oriented methodologies.In [Henderson-Sellers and Giorgini, 2005], chapter XII, pages 341–367.
Molesini (UniBo) AOSE AOSE 2010 225 / 237
unibo-logo
Bibliography XXV
Object Management Group (2008).Software & Systems Process Engineering Meta-Model Specification2.0.http://www.omg.org/spec/SPEM/2.0/PDF.
Omicini, A., Ricci, A., and Viroli, M. (2006).Agens Faber: Toward a theory of artefacts for MAS.Electronic Notes in Theoretical Computer Sciences, 150(3):21–36.1st International Workshop “Coordination and Organization” (CoOrg2005), COORDINATION 2005, Namur, Belgium, 22 April 2005.Proceedings.
OPEN Working Group.Open home page.http://www.open.org.au/index.html.
Molesini (UniBo) AOSE AOSE 2010 226 / 237
unibo-logo
Bibliography XXVI
Padgham, L. and Winikof, M. (2003).Prometheus: A methodology for developing intelligent agents.In Giunchiglia, F., Odell, J., and Weiss, G., editors, Agent-OrientedSoftware Engineering III, volume 2585 of LNCS, pages 174–185.Springer.3rd International Workshop (AOSE 2002), Bologna, Italy,15 July 2002. Revised Papers and Invited Contributions.
Padgham, L. and Winikoff, M. (2005).Prometheous: A practical agent oriented methodology.In [Henderson-Sellers and Giorgini, 2005], chapter V, pages 107–135.
Padgham, L., Winikoff, M., DeLoach, S., and Cossentino, M. (2009).A unified graphical notation for aose.In Agent-Oriented Software Engineering 2008. Lecture Notes inComputer Science, 5386-0086.
Molesini (UniBo) AOSE AOSE 2010 227 / 237
unibo-logo
Bibliography XXVII
Parunak, H. V. D. (1997).“go to the ant”: Engineering principles from natural agent systems.Annals of Operation Research, 75:69–101.
Pavon, J., Gomez-Sanz, J. J., and Fuentes, R. (2005).The INGENIAS methodology and tools.In [Henderson-Sellers and Giorgini, 2005], chapter IX, pages 236–276.
Poslad, S., Buckle, P., and Hadingham, R.The fipa-os agent platform: Open source for open standard.http://fipa-os.sourceforge.net.
Molesini (UniBo) AOSE AOSE 2010 228 / 237
unibo-logo
Bibliography XXVIII
Ricci, A., Piunti, M., Viroli, M., and Omicini, A. (2009).Environment programming in CArtAgO.In Bordini, R. P., Dastani, M., Dix, J., and El Fallah Seghrouchni, A.,editors, Multi-Agent Programming II: Languages, Platforms andApplications, Multiagent Systems, Artificial Societies, and SimulatedOrganizations, chapter 8, pages 259–288. Springer.
SEI (2006a).Cmmi for development version 1.2.Technical report, Software Engineering Institute of the CarnagieMellon University.
SEI (2006b).Standard cmmi appraisal method for process improvement (scampi) a,version 1.2: Method definition document.Technical report, Software Engineering Institute of the CarnagieMellon University.
Molesini (UniBo) AOSE AOSE 2010 229 / 237
unibo-logo
Bibliography XXIX
Seidita, V., Cossentino, M., and Gaglio, S. (2008).Using and extending the spem specifications to represent agentoriented methodologies.In Luck, M. and Gomez-Sanz, J. J., editors, AOSE, volume 5386 ofLecture Notes in Computer Science, pages 46–59. Springer.
Seidita, V., Cossentino, M., and Gaglio, S. (2009a).Using and extending the spem specifications to represent agentoriented methodologies.In Agent-Oriented Software Engineering 2008. Lecture Notes inComputer Science, volume 5386-0086. Springer-Verlag GmbH.
Seidita, V., Cossentino, M., Galland, S., Gaud, N., Hilaire, V.,Koukam, A., and Gaglio, S. (2009b).The metamodel: a starting point for design processes construction.International Journal of Software Engineering and KnowledgeEngineering (IJSEKE).
Molesini (UniBo) AOSE AOSE 2010 230 / 237
unibo-logo
Bibliography XXX
Shoham, Y. (1997).An overview of agent-oriented programming.pages 271–290.
Siau, K. and Rossi, M. (1998).Evaluation of information modeling methods – a review.In HICSS ’98: Proceedings of the Thirty-First Annual HawaiiInternational Conference on System Sciences-Volume 5, page 314,Washington, DC, USA. IEEE Computer Society.
Sommerville, I. (2007).Software Engineering 8th Edition.Addison-Wesley.
Molesini (UniBo) AOSE AOSE 2010 231 / 237
unibo-logo
Bibliography XXXI
Sturm, A., Dori, D., and Shehory, O. (2003).Single-model method for specifying multi-agent systems.In AAMAS ’03: Proceedings of the Second International jointconference on Autonomous Agents and Multiagent Systems, pages121–128. ACM Press.
Susi, A., Perini, A., Mylopoulos, J., and Giorgini, P. (2005).The tropos metamodel and its use.Informatica (Slovenia), 29(4):401–408.
Taveret, K. and Wagner, G. (2005).Towards radical agent-oriented sotware engineering processes based onAOR modelling.In [Henderson-Sellers and Giorgini, 2005], chapter X, pages 277–316.
Molesini (UniBo) AOSE AOSE 2010 232 / 237
unibo-logo
Bibliography XXXII
Tolvanen, J.-P. (1998).Incremental method engineering with modeling tools: Theoreticalprinciples and empirical evidence.PhD thesis.
Van Dyke Parunak, H. and Brueckner, S. (2001).Entropy and self-organization in multi-agent systems.In AGENTS ’01: Proceedings of the fifth international conference onAutonomous agents, pages 124–130, New York, NY, USA. ACM.
Viroli, M., Casadei, M., and Omicini, A. (2009).A framework for modelling and implementing self-organisingcoordination.In Shin, S. Y., Ossowski, S., Menezes, R., and Viroli, M., editors, 24thAnnual ACM Symposium on Applied Computing (SAC 2009), volumeIII, pages 1353–1360, Honolulu, Hawai’i, USA. ACM.
Molesini (UniBo) AOSE AOSE 2010 233 / 237
unibo-logo
Bibliography XXXIII
Wegner, P. (1997).Why interaction is more powerful than algorithms.Commun. ACM, 40(5):80–91.
Wooldridge, M. (2001).Reasoning about rational agents.MIT Press, Cambridge, MA, USA.
Wooldridge, M. and Jennings, N. R. (1995).Intelligent agents: Theory and practice.Knowledge Engineering Review, 10(2):115–152.
Wooldridge, M., Jennings, N. R., and Kinny, D. (2000).The gaia methodology for agent-oriented analysis and design.Autonomous Agents and Multi-Agent Systems, 3(3):285–312.
Molesini (UniBo) AOSE AOSE 2010 234 / 237
unibo-logo
Bibliography XXXIV
Wooldridge, M. J. and Jennings, N. R. (1999).Software engineering with agents: Pitfalls and pratfalls.IEEE Internet Computing, 3(3):20–27.
Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2001).Organizational abstractions for the analysis and design of multi-agentsystem.In First international workshop, AOSE 2000 on Agent-orientedsoftware engineering, pages 235–251, Secaucus, NJ, USA.Springer-Verlag New York, Inc.
Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2003).Developing multiagent systems: The Gaia methodology.ACM Transactions on Software Engineering and Methodology(TOSEM), 12(3):317–370.
Molesini (UniBo) AOSE AOSE 2010 235 / 237
unibo-logo
Bibliography XXXV
Zambonelli, F., Mamei, M., and Roli, A. (2002).What can cellular automata tell us about the behavior of largemulti-agent systems?In Garcia, A. F., Pereira de Lucena, C. J., Zambonelli, F., Omicini, A.,and Castro, J., editors, SELMAS, volume 2603 of Lecture Notes inComputer Science, pages 216–231. Springer.
Zambonelli, F. and Omicini, A. (2004).Challenges and research directions in agent-oriented softwareengineering.Autonomous Agents and Multi-Agent Systems, 9(3):253–283.Special Issue: Challenges for Agent-Based Computing.
Zambonelli, F. and Parunak, H. V. D. (2002).From design to intention: signs of a revolution.In AAMAS, pages 455–456. ACM.
Molesini (UniBo) AOSE AOSE 2010 236 / 237
unibo-logo
Agent Oriented Software Engineering
Ambra Molesini
Alma Mater Studiorum – Universita di Bologna (Italy)[email protected]
Bologna, Italy, 28th June 2010
Molesini (UniBo) AOSE AOSE 2010 237 / 237