Managing Knowledge for Business Analysts: The Executive Information Portal - PowerPoint PPT Presentation

About This Presentation
Title:

Managing Knowledge for Business Analysts: The Executive Information Portal

Description:

Tropos: Agent-Oriented Software Engineering John Mylopoulos University of Toronto, CANADA University of Trento, ITALY 3rd International Conference on Research ... – PowerPoint PPT presentation

Number of Views:141
Avg rating:3.0/5.0
Slides: 35
Provided by: JohnM501
Category:

less

Transcript and Presenter's Notes

Title: Managing Knowledge for Business Analysts: The Executive Information Portal


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

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?

4
Object-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..
5
Agent 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.

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!

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.

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.

9
Goal Analysis Leads to Alternatives
(Functional/hard) Goals
AND
AND
OR
OR
OR
OR
OR
OR
AND
AND
10
Alternatives Lead to Designs/Plans
AND
AND
OR
OR
OR
OR
OR
OR
Tasks
AND
AND
Schedule
11
Softgoals 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
12
EvaluatingAlternatives with softgoals
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.

14
An Actor Dependency Model
Initiator
ContributeToMtg
actor
UsefulMtg
ScheduleMtg
CalendarInfo
Participant
Scheduler
AttendMtg
resource
task
SuitableTime
15
An 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.
16
So 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
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

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?

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

20
Tropos in Perspective
JACK
i
Tropos
GAIA
KAOS
AUML
SADT
Z
!! A GAP !!
UML and co.
Detailed design
Early requirements
Late requirements
Architectural design
Implementation
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.

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

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

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.

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

26
Autonomic (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

27
High-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
28
Monitoring and Diagnosis
  • Wang07

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.

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.

31
Questions?
32
References
  • 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).
Write a Comment
User Comments (0)
About PowerShow.com