agent oriented software engineering · agent oriented software engineering ambra molesini alma...

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


unibo-logo

Outline of Part I

1 Software Engineering

2 Software Process

3 Methodologies


unibo-logo

Outline



unibo-logo

Outline of Part II

4 Why do we need AOSE?

5 Why agents and MAS?


unibo-logo

Outline



unibo-logo

Outline of Part III

6 Meta-model

7 AOSE MethodologiesADELFEGaiaPASSITROPOSPrometheusSODAINGENIAS


unibo-logo

Outline



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


unibo-logo

Outline



unibo-logo

Outline of Part V

12 Research directions and visions

13 Conclusions

14 List of interesting papers


unibo-logo

Part I

General Concepts


unibo-logo

Outline


2 Software Process

3 Methodologies


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]


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


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


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


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]


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]


unibo-logo

Outline


2 Software Process

3 Methodologies


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)


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


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


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


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


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


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


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


unibo-logo

The Ideal Software Process

The Ideal Software Process?

There is no an ideal process[Sommerville, 2007]


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


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


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


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


unibo-logo

Outline


2 Software Process

3 Methodologies


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)


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


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


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


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


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


unibo-logo

Part II



unibo-logo

Outline




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!


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


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


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


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


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


unibo-logo

MAS Characterisation


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


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


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)


unibo-logo

Outline




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


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


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


unibo-logo

Part III

AOSE Methodologies & Meta-models


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]


unibo-logo

Outline

6 Meta-model



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]


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


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


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


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


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]


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


unibo-logo

SPEM level of abstraction

SPEM


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


unibo-logo

SPEM


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


unibo-logo

SPEM: Method Content and Process


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


unibo-logo

Outline

6 Meta-model



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


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


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


unibo-logo

The ADELFE Meta-model


unibo-logo


•Belongs to no predefined organization (AMAS)

•Has local goal•Is cooperative• Detects and removes NCS


unibo-logo


An agent owns some skills e.g. specific knowledge that enables it to realize its own partial function


unibo-logo


Aptitudes show the ability of an agent to reason both about knowledge and beliefs it owns


unibo-logo


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)


unibo-logo


An agent observes some cooperation rules and avoids NCS (Non Cooperative Situations)


unibo-logo


An agent has perception of the environment elements


unibo-logo

The ADELFE Process


unibo-logo

ADELFE: Example

!"#"$#%&#'%#("%$)*!&#&)*+%),%&#+%!"#"$#&)*%-*!%.(-#%-$#&)*+%#("%-/"*#%01+#%2"3,)30%#)%!"-4%.&#(%&#5%

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&*/% -$#&8&#75% @)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&#7%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&#6$ -*!%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&#6$* 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::;*


unibo-logo

Outline

6 Meta-model



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


unibo-logo


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


unibo-logo


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


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


unibo-logo

The Gaia Pocess

Analysis Architectural Design Detailed Design


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


unibo-logo

Gaia: Example


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


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


unibo-logo

Outline

6 Meta-model



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


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


unibo-logo

The PASSI Meta-model


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!!


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&#2*+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:!!!!


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:!!

!!!!


unibo-logo

Outline

6 Meta-model



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


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


unibo-logo

The Tropos Meta-model


unibo-logo

Tropos: Example

© P. Giorgini! 34!

Early requirements!


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!


unibo-logo

Tropos: Example

© P. Giorgini! 36!

Late requirements!The goals decomposition, means-end and contribution analysis are performed on the system"s goals!


unibo-logo

Outline

6 Meta-model



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


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


unibo-logo

The Prometheus Overview


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


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.


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


unibo-logo

Outline

6 Meta-model



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


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


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


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


Analysis


Detailed Design


unibo-logo

The SODA Process


Analysis

Layering


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


unibo-logo

The SODA Layering

In-zoom Out-zoom

Projection

Select Layer

increases detail increases abstraction

new layer?

no

yes


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


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


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


unibo-logo

Outline

6 Meta-model



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)


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


unibo-logo

The INGENIAS Meta-model


unibo-logo

The INGENIAS Process


unibo-logo

INGENIAS: Example


unibo-logo

Part IV

Methodologies Documentation & Situational MethodEngineering


unibo-logo

Outline






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


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


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)


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


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


unibo-logo

Methodologies Documentation: examples

Examples. . .


unibo-logo

Outline






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


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


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”


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”


unibo-logo

Method Engineering: Motivations

Adaptability – to specificprojects, companies, needs &new development settings

Reuse – of best practices,theories & tools


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


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


unibo-logo

Configuration Process [Brinkkemper, 1996]


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


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


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


unibo-logo

Outline






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)


unibo-logo

The normal agent development process


unibo-logo

Situational Method Engineering


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?)


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


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


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

All methodologies are expressed in a

standard notation (we adopt SPEM by OMG)


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

Fragments are identified and

described according to the previous discussed

definition


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

New fragments are defined if necessary


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

A method fragments repository is composed

with all existing fragments


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

The desired MAS-Meta-Model is

composed according to problem specific needs (for instance including or not self-organizing

agents)


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

A CAME (Computer Aided Method

Engineering) tool assists in the selection

of fragments and composition of design

process


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

A new and problem specific methodology is

built


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

A CASE (Computer Aided Software

Engineering) tool is used to effectively

design the multi-agent system


unibo-logo


ExistingMethodo-

logies

MethodBase


NewMethod

Fragments


logy

MASMeta-Model



MASModelDeployment

The multi-agent system has been

coded, tested and is ready to be deployed


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


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


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


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


unibo-logo

Proposed icons


unibo-logo

Method fragment meta-model

The FIPA Methodology Technical Committee in 2003-2005 proposedthe following definition of method fragment [Cossentino et al., 2007a]


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.


unibo-logo

The PRODE approach for Agent-Oriented MethodEngineering [Seidita et al., 2009b]

MMM


unibo-logo

The PRODE Process Representation


unibo-logo

PRODE divided in three main areas of research

MMM

1) A collection of process fragments


unibo-logo


MMM

2) Guidelines for fragment assembling


unibo-logo


MMM

3) A CAPE (Computer Aided Process Engineering)

tool


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


unibo-logo

Metameth tool architecture


unibo-logo

Outline






unibo-logo

Results Evaluation: an open problem?

MMM

Results Evaluation is crucial also in process

improvement/reengineering


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.


unibo-logo

Details on AO processes evaluation[Numi Tran and Low, 2005]

Structure of the evaluation framework


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, . . . )


unibo-logo


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/


unibo-logo


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


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


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)


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


unibo-logo

Part V

Research directions and conclusions


unibo-logo

Outline


13 Conclusions



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


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)


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


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?


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


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”


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


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”?


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


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


unibo-logo

Outline


13 Conclusions



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?


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


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


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


unibo-logo

Outline


13 Conclusions



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]


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]


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]


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]


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]


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]


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]


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]


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]


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


unibo-logo


Ambra Molesini

Alma Mater Studiorum – Universita di Bologna (Italy)[email protected]

Bologna, Italy, 28th June 2010


agent oriented software engineering · agent oriented software engineering ambra molesini alma...

Documents