tropos: agent -oriented software engineering

2009 John Mylopoulos RICS’09 -- 1

Tropos: Agent-Oriented Software

Engineering

John MylopoulosJohn MylopoulosUniversity of Toronto, CANADAUniversity of Toronto, CANADA

University of Trento, ITALYUniversity of Trento, ITALY

3rd International Conference on Research Challenges in Information

Science (RCIS’09), Fez Morocco, April 22-24, 2009


Abstract There is an ongoing paradigm shift in Software

Engineering from object-orientation to agent-orientation. We review some of the reasons for this, and briefly overview the state-of-the-art in Agent-Oriented Software Engineering (AOSE). We then sketch the Tropos methodology for building agent-oriented software and some of the tools that have been developed to support it. In addition, we discuss some threads of long-term research on autonomic software, software monitoring and diagnosis, and requirements evolution.

The research reported is the result of collaborations with colleagues at the Universities of Trento, Toronto, and a number of other collaborating academic institutions.


Model-Driven Software Development

All engineering disciplines use models to support the systematic design of artifacts.

After decades of being the one exception to the rule, Software Engineering (SE) has come to adopt a model-driven view of software development.

Hence the recent focus on UML, Model-Driven Architectures (MDA) and Model-Driven Development.

… But, what are the right models for software development?


Object-Oriented Software Development

Initiator Participant

ScheduleMtg

ValidateUser

EditConstraints

ProvideConstraintsWithdraw

<<extends>>

<<uses>>

Personnameemail

0..1

0..*1

has

Meetingtimeplace

attends

RequestedMtg

Timetable

initiates

2..*

1

0..*

MtgRequirement0..*

ScheduledMtg initiator

has0..*

1

initiator:Person

staff:Person

participant:Person

scheduler:Person

1:giveDetails()8:approveSchedule()

2:inform()4:remind()9:inform()

3:acknowledge()5:sendDetails()

6:prompt()

7:sendSchedule()


Agent Orientation in SE Over the past decade, a new paradigm has been

gaining strength … It’s basic premise is that software consists of an

associated purpose (end, requirements) and means for fulfilling that purpose.

The means by which a software system fulfills its purpose include the ability to plan, negotiate, delegate and commit to a particular course of action.

For all of the above reasons, this software paradigm has been named agent-oriented.


Why Agent-Oriented Software?

Next generation software will have to be founded on open, dynamic architectures where components can accomplish tasks in a variety of operating environments and domains.

Consider application areas such as eBusiness, web services, pervasive and P2P computing, social computing, and more …

These call for software components that find and compose services dynamically, establish/drop partnerships with other components and operate under a broad range of conditions.

Learning, planning, communication, negotiation, and self-management become essential features for such software components.

...agents!


Agent-Oriented Software Engineering (AOSE)

Many researchers working on it. Research on the topic generally comes in two

flavours: Extend UML to support agent communication,

negotiation etc. (e.g., [Bauer99, Odell00]); Extend current agent programming platforms

(e.g., JACK) to support not just programming but also design activities [Jennings00].

We have been working on the development of a methodology (Tropos, 2000 - ) for building agent-oriented software which supports requirements analysis, as well as design.


Requirements as Goals (~1993)

Goal-oriented analysis focuses on early requirements, when problems ( = stakeholder needs) are identified, and alternative solutions are explored and evaluated.

During goal-oriented analysis, we start with initial stakeholder goals such as “Fulfill every book request”, or “Schedule meeting” and keep refining them until we have reduced them to alternative collections of functional specifications each of which can satisfy the initial goals.

Initial goals may be contradictory and may not be defined.


Goal Analysis Leads to Alternatives

Schedulemeeting

Chooseschedule

By Person

Collecttimetables

Automatically

ManuallyCollect from usersCollect from

agents

Receiverequest

Send request

AND AND

AND AND

OR OR

OR ORBy

System

OR OR

(Functional/hard)Goals


Alternatives Lead to Designs/Plans

Schedulemeeting

Chooseschedule

By Person

Collecttimetables

Automatically

ManuallyCollect from usersCollect from

agents

Receiverequest

Send request

AND AND

AND AND

OR OR

OR ORBy

System

OR OR

Collect Schedule

Tasks


Softgoals for Representing Non-Functional Requirements

Programmability

+

+

++SupportChange of

ColoursSupport

Change ofState

SupportChange ofLanguage

ErrorAvoidance

InformationSharing

Ease of Learning

User Tailorability

Usability

Allow User-Defined Writing Tool

Modularity

UseComponents

UserFlexibility

Allow Change ofSettings

+

+

+

ANDAND ANDAND

ANDAND

Change colour Change

stateChange language


Schedule meeting

Collect timetables

Choose schedule

By Person By System

Manually Automatically

Minimal effort

Collection effort

Matching effort

Good quality schedule

Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

EvaluatingAlternatives

with softgoals


Stakeholders and Their Goals In some goal-oriented approaches, goals are global

objectives for the system-to-be. In i* [Yu93], goals are desired by actors and are

delegated to other actors for fulfillment. In this framework then, early requirements involve

identifying stakeholders and their goals, analyzing these goals, delegating them to other actors etc.

The result of this process consists of actor dependency and actor rationale models.


An Actor Dependency ModelInitiatorContributeToMtg

AttendMtg

UsefulMtg

CalendarInfo

SuitableTime

SchedulerParticipant

ScheduleMtg

resourcetask

actor


An Actor Rationale Model

Throughpersonal contact

By email

ScheduleScheduleMeeting Meeting goal treegoal tree

ScheduleScheduleMeeting Meeting goal treegoal tree

Reception

Actor dependencies are intentional: One actor wants something, another is willing and able to deliver.

By Person


So What? Early Requirements Phase

Early

Early

require

ments

require

ments Late

Late

require

ments

require

ments

Archite

ctura

l

Archite

ctura

l

design

design

Detaile

d

Detaile

d

design

design

Implem

entatio

n

Implem

entatio

n

KAOSKAOS

ZZ

UML and co.UML and co.

AUMLAUML

GAIAGAIA

!! A GAP !!!! A GAP !!

i*i* JACK

SADTSADT


Credits Many other researchers worked with goals a

decade or more ago, including: Martin Feather and Steve Fickas; Axel van Lamsweerde et al Colin Potts and Annie Anton; Janis Bubenko; Colette Rolland; Periklis Loucopoulos and Evangelia Kavakli;

…


The Tropos Project… An Idea ... (~2000)

Software Engineering methods have traditionally come about in a “late-to-early” phase (or, “downstream-to-upstream”) fashion.

In particular, Structured Programming preceded Structured Analysis and Design; likewise, Object-Oriented Programming preceded Object-Oriented Design and Analysis.

In both cases, programming concepts were projected upstream to dictate how designs and requirements are conceived.

What would happen if we projected requirements concepts downstream to define software designs

and even implementations?


The Tropos Methodology Proposes a set of primitive concepts adopted from i*

(actor, goal, actor dependency,…) and a process for building agent-oriented software.

Covers four phases of software development: Early requirements -- identify stakeholders ( -->

actors) and their requirements ( --> goals); Late requirements -- introduce system-to-be as

another actor who can accommodate some of these goals;

Architectural design -- more system actors are added and are assigned responsibilities;

Detailed design -- complete the specification of system actors.


Tropos in Perspective

Early

Early

require

ments

require

ments Late

Late

require

ments

require

ments

Archite

ctura

l

Archite

ctura

l

design

design

Detaile

d

Detaile

d

design

design

Implem

entatio

n

Implem

entatio

n

KAOSKAOS

ZZ

UML and co.UML and co.

AUMLAUML

GAIAGAIA

!! A GAP !!!! A GAP !!

i*i* JACK

SADTSADT

Tropos


Software Development as Multi-Agent Planning

Initialization: Identify stakeholder actors and their goals;

Step: For each new goal, the actor who owns it: adopts it; delegates it to another existing actor; delegates it to a new actor; decomposes it into new subgoals; declares the goal “denied”.

Termination condition: All initial goals have been fulfilled (…to an acceptable degree), assuming all actors deliver on their commitments.


Why is this Better? Traditionally, goals (and softgoals) are

operationalized and/or metricized before late requirements.

This means that a solution to a goal is frozen into a software design early on and the designer has to work within the confines of that solution.

This won’t do in situations where the operational environment of a system, including its stakeholders, keeps changing.

This won’t do either for software that needs to accommodate a broad range of users, with different cultural, educational and linguistic backgrounds, or users with special needs.


Analyzing Tropos Models

Models are used primarily for human communication Unfortunately, large models can be hard to understand,

or take seriously. We need formal analysis techniques which offer

evidence that a model makes sense: Simulation through model checking, to explore the

properties of goals, entities, etc. over their lifetime [RE'01, RE'03, REJ];

Goal analysis uses a SAT solver to determine whether a goal can be fulfilled [ER'02, JoDS'03, CAiSE'04];

Social analysis uses a planner to explore alternative delegations for a given set of actors and goals.

The tools we have developed use off-the-shelf inference engines (respectively nuSMV, MinWeight solver, LPG-td).


Looking Forward -- Design for Variability

Instead of choosing one solution for the fulfillment of a top-level goal, we could choose to support them all.

This leads to software solutions that can be customized in many different ways, depending on stakeholder preferences and environmental parameters.

Generic, customizable software solutions have been around for a while -- ERPs …

What's new here is a systematic, model-supported process for designing them.


Research on Variability Goal models define problem-level variability. From goals to generic designs: Develop a tool-

supported method for generating different design views from a given goal model; in our work we have focused on the generation of a feature model, a statechart model and a software architecture.

Characterize variability: Goal models constitute one source of variability (problem-level variability) in design, but there are also others. These may be dependent on what is the design about (e.g., software, business process, database) [RE'06a, RE'06b].

PhD theses by Sotiris Liaskos, Alexei Lapouchnian, Lei Jiang (Toronto).


Autonomic (Application) Software

(According to IBM) This is software that can self-configure, self-repair and self-optimize.

For us,Autonomicity =

High-Variability+Monitoring+Diagnosis+Compensation

Our goal-oriented framework may not be appropriate for autonomic system software (e.g., an OS) or middleware (e.g., a DBMS); But it certainly is for application software!

Different mechanisms required for Self-repair -- real-time reconfiguration and

recovery Self-configuring and self-optimization -- off-line

reconfiguration, no recovery


WID

WB Modeler

High-VariabilityBusiness Goal Model

BP Specifications for All the Alternatives

Open OME

BPEL, WSDL, XSD

Elicit/Analyze

Simulate/Analyze

Integrate

WPS

Deploy

WB Monitor

Business Measures

Monitor

High-Variability BPEL

WID

Integrate

From Business Requirements

To Adaptive Business Processes

CBEs/CEI

[Lapouchnian06]


Monitoring and Diagnosis

[Wang07]


Requirements Evolution Assuming that the run-time environment of a

software system consists of code, requirements models and traceability links between them, we would like to support: Version and configuration management for

goal models; Dynamic requirements views to support

usability; Support for traceability link evolution.

On-going PhD thesis work by Neil Ernst.


Conclusions AOSE introduces intentional and social

concepts in software development processes; also requirements models and traceability links for self-maintenance.

Software is conceived, designed and implemented as a collection of agents that cooperate with external agents to satisfy their respective goals.

The theoretical foundations of this work rest in ideas adopted from Knowledge Representation and Multi-Agent Systems in AI.


Questions?


References [Bryl06] Bryl, V., Massacci, F., Mylopoulos, J., Zannone, N., “Designing Secure

Systems by Planning”, 18th Int. Conf. on Advanced Information Systems Engineering (CAiSE’06), June 2006, Luxembourg.

[Castro02] Castro, J., Kolp, M., Mylopoulos, J., “Towards Requirements-Driven Software Development Methodology: The Tropos Project,” Information Systems 27(2), Pergamon Press, June 2002, 365-389.

[Chung00] Chung, L., Nixon, B., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Publishing, 2000.

[Dardenne93] Dardenne, A., van Lamsweerde, A. and Fickas, S., “Goal–directed Requirements Acquisition”, Science of Computer Programming, 20, 1993.

[Fuxman01] .Fuxman, A., Pistore, M., Mylopoulos, J. and Traverso, P., “Model Checking Early Requirements Specifications in Tropos”, Fifth International IEEE Symposium on Requirements Engineering, Toronto, August 2001.

[Jiang06] Jiang, L., Topaloglou, T., Borgida, A., Mylopoulos, J., “Incorporating Goal Analysis in Database Design: A Case Study from Biological Data Management”, 14th International IEEE Conf. on Requirements Engineering, Sept. 2006, Minneapolis/St. Paul.

[Jiang07] Jiang, L., Topaloglou, T., Borgida, A., Mylopoulos, J., “Goal-Oriented Conceptual Database Design”, 16th Int. IEEE Conf. on Requirements Engineering (RE’05), Delhi, Oct. 2007

[Jennings00] Jennings, N. “On Agent-Based Software Engineering”, Artificial lntelligence 117, 2000.


...More References… [Ladkin97] Ladkin, P., "Abstraction and Modeling" Research Report RVS-Occ-

97-04, University of Bielefeld, 1997; http://www.rvs.uni-bielefeld.de/publications/abstracts.html#AbsMod. [Lapouchnian07] Lapouchnian, A., Yu, Y., Mylopoulos, J., “Requirements-

Driven Design and Configuration Management of Business Processes”, 5th International Conference on Business Process Management (BPM’07), Brisbane, September 2007.

[Liaskos06] Liaskos, S., Lapouchnian, A., Yu, Y., Yu, E., Mylopoulos, J., “On Goal-Based Variability Acquisition and Analysis”, 14th International IEEE Conference on Requirements Engineering, September 2006, Minneapolis/St. Paul.

[Mylopoulos92] Mylopoulos, J., Chung, L. and Nixon, B., "Representing and Using Non-Functional Requirements: A Process-Oriented Approach," IEEE Transactions on Software Engineering 18(6), June 1992, 483-497.

[Odell00] Odell, J., Van Dyke Parunak, H. and Bernhard, B., “Representing Agent Interaction Protocols in UML”, Proceedings 1st International Workshop on Agent-Oriented Software Engineering (AOSE00), Limerick, June 2000.

[Penserini06] Penserini, L., Perini, A., Susi, A., Mylopoulos, J., “From Stakeholder Intentions to Software Agent Implementations”, 18th International Conference on Advanced Information Systems Engineering (CAiSE’06), June 2006, Luxembourg.


...More References… [Simon69] Simon, H., The Sciences of the Artificial, The MIT Press, 1969 [Wang07] Wang, Y., McIlraith, S., Yu, Y., Mylopoulos, J., “An Automated

Approach for Monitoring and Diagnosing Requirements”, ", 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE’07), Atlanta, November 2007.

[Wooldridge00] Wooldridge, M., Jennings, N., Kinny, D., “The Gaia Methodology for Agent-Oriented Analysis and Design,” J. of Autonomous Agents and Multi-Agent Systems 3(3), 2000, 285–312.

[Yu95] Yu, E., Modelling Strategic Relationships for Process Reengineering, Ph.D. thesis, Department of Computer Science, University of Toronto, 1995.

[Zambonelli00] Zambonelli, F., Jennings, N., Omicini, A., and Wooldridge, M., “Agent-Oriented Software Engineering for Internet Applications,” in Omicini, A., Zambonelli, F., Klusch, M., and Tolks-Dorf R., (editors), Coordination of Internet Agents: Models, Technologies, and Applications, Springer-Verlag LNCS, 2000, 326–346.

[Zannone06] 1. Massacci, F., Mylopoulos, J., Zannone, N., “Minimal Disclosure in Hierarchical Hippocratic Databases for Virtual Organizations”, Very Large Databases Journal 15(4), 370-387, Springer-Verlag, Oct. 2006.

[Zannone07] 1. Massacci, F., Mylopoulos, J., Zannone, N., “Computer-Aided Support for Secure Tropos”, Automated Software Engineering, Sprnger-Verlag (to appear).

tropos: agent -oriented software engineering

Documents