Title: Managing Knowledge for Business Analysts: The Executive Information Portal
1Tropos Agent-Oriented Software Engineering
John Mylopoulos University of Toronto,
CANADA University of Trento, ITALY
3rd International Conference on Research
Challenges in Information Science (RCIS09), Fez
Morocco, April 22-24, 2009
2Abstract
- 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.
3Model-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?
4Object-Oriented Software Development
7sendSchedule()
scheduler Person
initiator Person
6prompt()
1giveDetails() 8approveSchedule()
3acknowledge() 5sendDetails()
participant Person
staff Person
2inform() 4remind() 9inform()
Meeting
Person
attends
name
time
email
place
2..
0..
1
0..
initiates
has
0..
has
0..1
1
initiator
1
0..
5Agent Orientation in SE
- Over the past decade, a new paradigm has been
gaining strength - Its 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.
6Why 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!
7Agent-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.
8Requirements 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.
9Goal Analysis Leads to Alternatives
(Functional/hard) Goals
AND
AND
OR
OR
OR
OR
OR
OR
AND
AND
10Alternatives Lead to Designs/Plans
AND
AND
OR
OR
OR
OR
OR
OR
Tasks
AND
AND
Schedule
11Softgoals for Representing Non-Functional
Requirements
Usability
AND
AND
User Tailorability
AND
AND
Information Sharing
Error Avoidance
Ease of Learning
AND
AND
User Flexibility
Programmability
Allow Change of Settings
Modularity
Support Change of Language
Support Change of Colours
Support Change of State
Allow User-Defined Writing Tool
Use Components
Change colour
Change language
Change state
12EvaluatingAlternatives with softgoals
13Stakeholders 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.
14An Actor Dependency Model
Initiator
ContributeToMtg
actor
UsefulMtg
ScheduleMtg
CalendarInfo
Participant
Scheduler
AttendMtg
resource
task
SuitableTime
15An Actor Rationale Model
Schedule Meeting goal tree
By Person
Through personal contact
Reception
By email
Actor dependencies are intentional One actor
wants something, another is willing and able to
deliver.
16So What? Early Requirements Phase
JACK
i
GAIA
KAOS
AUML
SADT
Z
!! A GAP !!
UML and co.
Detailed design
Early requirements
Late requirements
Architectural design
Implementation
17Credits
- 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
18The 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?
19The 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 ( --gt
actors) and their requirements ( --gt 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.
20Tropos in Perspective
JACK
i
Tropos
GAIA
KAOS
AUML
SADT
Z
!! A GAP !!
UML and co.
Detailed design
Early requirements
Late requirements
Architectural design
Implementation
21Software 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.
22Why 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 wont do in situations where the operational
environment of a system, including its
stakeholders, keeps changing. - This wont 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.
23Analyzing 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).
24Looking 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.
25Research 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).
26Autonomic (Application) Software
- (According to IBM) This is software that can
self-configure, self-repair and self-optimize. - For us,
- Autonomicity
- High-VariabilityMonitoringDiagnosisC
ompensation - 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
27High-Variability Business Goal Model
BP Specifications for All the Alternatives
From Business Requirements To Adaptive Business
Processes
Elicit/Analyze
Simulate/Analyze
High-Variability BPEL
BPEL, WSDL, XSD
Business Measures
CBEs/CEI
Monitor
Integrate
Integrate
Lapouchnian06
Deploy
28Monitoring and Diagnosis
29Requirements 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.
30Conclusions
- 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.
31Questions?
32References
- Bryl06 Bryl, V., Massacci, F., Mylopoulos, J.,
Zannone, N., Designing Secure Systems by
Planning, 18th Int. Conf. on Advanced
Information Systems Engineering (CAiSE06), 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., Goaldirected 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 (RE05), Delhi, Oct.
2007 - Jennings00 Jennings, N. On Agent-Based
Software Engineering, Artificial lntelligence
117, 2000.
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/abst
racts.htmlAbsMod. - Lapouchnian07 Lapouchnian, A., Yu, Y.,
Mylopoulos, J., Requirements-Driven Design and
Configuration Management of Business Processes,
5th International Conference on Business Process
Management (BPM07), 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 (CAiSE06), June 2006,
Luxembourg.
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 (ASE07), 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, 285312. - 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,
326346. - 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).