Transcript Managing Knowledge for Business Analysts: The Executive

Tropos: Agent-Oriented
Software Engineering
John Mylopoulos
University of Toronto, CANADA
University 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 -- 1
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 -- 2
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 -- 3
Object-Oriented Software
Development
Initiator
ValidateUser
7:sendSchedule()
Participant
<<uses>>
6:prompt()
1:giveDetails()
8:approveSchedule()
<<extends>> Provide
Constraints
staff
Edit
Constraints
:Person
Withdraw
ScheduleMtg
scheduler
:Person
initiator
:Person
3:acknowledge()
5:sendDetails()
2:inform()
4:remind()
9:inform()
participant
:Person
Meeting
time
place
Person
attends
name
2..* email
0..*
0..*
initiates 1
has
0..*
has
0..1
Timetable
1
ScheduledMtg
initiator
RequestedMtg
1
0..*
MtgRequirement
2009 John Mylopoulos
RICS’09 -- 4
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 -- 5
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 selfmanagement become essential features for such software
components.

2009 John Mylopoulos
... agents!
RICS’09 -- 6
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 agentoriented software which supports requirements analysis,
as well as design.
2009 John Mylopoulos
RICS’09 -- 7
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 -- 8
Goal Analysis Leads to Alternatives
Schedule
meeting
(Functional/hard)
Goals
AND
AND
Collect
timetables
OR
Choose
schedule
OR
By
System
By
Person
OR
OR
OR
Manually
Collect from
users
Collect from
agents
AND
Send
request
2009 John Mylopoulos
OR
Automatically
AND
Receive
request
RICS’09 -- 9
Alternatives Lead to Designs/Plans
Schedule
meeting
AND
AND
Collect
timetables
OR
Choose
schedule
OR
By
System
By
Person
OR
OR
OR
AND
Collect
2009 John Mylopoulos
Manually
Collect from
users
Collect from
agents
Tasks
OR
Send
request
Automatically
AND
Receive
request
Schedule
RICS’09 -- 10
Softgoals for Representing NonFunctional Requirements
Usability
AND
Error
Avoidance
AND
AND
AND
Information
Sharing
User
Tailorability
Ease of Learning
AND
AND
User
Flexibility
Allow
Change of
Settings
Support
Change of
Colours
+ + +
Support
Change of
State
Change
colour
Change
state
2009 John Mylopoulos
Programmability
+
+
Modularity
Support
Change of
Language
+
Use
Components
+
Allow User-Defined
Writing Tool
Change
language
RICS’09 -- 11
Good quality
schedule
Minimal
effort
AND
AND
AND
AND
Minimal
conflicts
Matching
effort
Collection
effort
AND
Collect
timetables
+
Evaluating
Alternatives
with softgoals
+ +
OR
Choose
schedule
OR
OR
By System
OR
Collect from
Agents
+
+
-
OR
By Person
OR
Collect from
Users
Manually
Automatically
AND
Accurate
Constraints
2009 John Mylopoulos
Schedule
meeting
AND
-
Minimal
Disturbances
Good
participation
AND
+
Send
Request
Receive
Response
RICS’09 -- 12
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 -- 13
An Actor Dependency Model
ContributeToMtg
actor
UsefulMtg
Initiator
ScheduleMtg
CalendarInfo
Participant
Scheduler
AttendMtg
resource
task
SuitableTime
2009 John Mylopoulos
RICS’09 -- 14
An Actor Rationale Model
Schedule
Meeting
goal tree
By Person
Reception
Through
personal
contact
By
email
Actor dependencies are intentional: One actor wants
something, another is willing and able to deliver.
2009 John Mylopoulos
RICS’09 -- 15
So What?
Early Requirements Phase
JACK
i*
GAIA
KAOS
AUML
SADT
!! A GAP !!
2009 John Mylopoulos
Z
UML and co.
RICS’09 -- 16
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 -- 17
The Tropos Project
… An Idea ... (~2000)



Software Engineering methods have traditionally come
about in a “late-to-early” phase (or, “downstream-toupstream”) fashion.
In
particular,
Structured
Programming
preceded
Structured Analysis and Design; likewise, ObjectOriented 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 -- 18
The Tropos Methodology


Proposes a set of primitive concepts adopted from i* (actor,
goal, actor dependency,…) and a process for building agentoriented 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 -- 19
Tropos in Perspective
i*
JACK
Tropos
KAOS
GAIA
AUML
SADT
!! A GAP !!
2009 John Mylopoulos
Z
UML and co.
RICS’09 -- 20
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 -- 21
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 -- 22
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 -- 23
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 -- 24
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 -- 25
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 -- 26
High-Variability
Business Goal Model
BP Specifications for All
the Alternatives
Open OME
WB Modeler
Elicit/Analyze
Simulate/Analyze
High-Variability BPEL
Business Measures
WID
WB Monitor
From Business Requirements
To Adaptive Business
Processes
BPEL, WSDL, XSD
WID
CBEs/CEI
Integrate
Monitor
Integrate
WPS
[Lapouchnian06]
2009 John Mylopoulos
Deploy
RICS’09 -- 27
Monitoring and Diagnosis
[Wang07]
2009 John Mylopoulos
RICS’09 -- 28
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 -- 29
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 -- 30
Questions?
2009 John Mylopoulos
RICS’09 -- 31
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 -- 32
...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 NonFunctional 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 -- 33
...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., “AgentOriented 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).
2009 John Mylopoulos
RICS’09 -- 34