Tropos: Agent -Oriented Software Engineering
description
Transcript of 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
2009 John Mylopoulos RICS’09 -- 2
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.
2009 John Mylopoulos RICS’09 -- 3
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?
2009 John Mylopoulos RICS’09 -- 4
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()
2009 John Mylopoulos RICS’09 -- 5
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.
2009 John Mylopoulos RICS’09 -- 6
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!
2009 John Mylopoulos RICS’09 -- 7
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.
2009 John Mylopoulos RICS’09 -- 8
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.
2009 John Mylopoulos RICS’09 -- 9
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
2009 John Mylopoulos RICS’09 -- 10
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
2009 John Mylopoulos RICS’09 -- 11
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
2009 John Mylopoulos RICS’09 -- 12
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
2009 John Mylopoulos RICS’09 -- 13
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.
2009 John Mylopoulos RICS’09 -- 14
An Actor Dependency ModelInitiatorContributeToMtg
AttendMtg
UsefulMtg
CalendarInfo
SuitableTime
SchedulerParticipant
ScheduleMtg
resourcetask
actor
2009 John Mylopoulos RICS’09 -- 15
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
2009 John Mylopoulos RICS’09 -- 16
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
2009 John Mylopoulos RICS’09 -- 17
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;
…
2009 John Mylopoulos RICS’09 -- 18
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?
2009 John Mylopoulos RICS’09 -- 19
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.
2009 John Mylopoulos RICS’09 -- 20
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
2009 John Mylopoulos RICS’09 -- 21
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.
2009 John Mylopoulos RICS’09 -- 22
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.
2009 John Mylopoulos RICS’09 -- 23
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).
2009 John Mylopoulos RICS’09 -- 24
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.
2009 John Mylopoulos RICS’09 -- 25
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).
2009 John Mylopoulos RICS’09 -- 26
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
2009 John Mylopoulos RICS’09 -- 27
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]
2009 John Mylopoulos RICS’09 -- 28
Monitoring and Diagnosis
[Wang07]
2009 John Mylopoulos RICS’09 -- 29
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.
2009 John Mylopoulos RICS’09 -- 30
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.
2009 John Mylopoulos RICS’09 -- 31
Questions?
2009 John Mylopoulos RICS’09 -- 32
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.
2009 John Mylopoulos RICS’09 -- 33
...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.
2009 John Mylopoulos RICS’09 -- 34
...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).