Managing Knowledge for Business Analysts: The Executive Information Portal

1
From Object- to Agent-Oriented Information Systems
John Mylopoulos University of Toronto (jm_at_cs.toro
nto.edu) 9th International Conference on
Object-Oriented Information Systems
(OOIS03) September 2-5, 2003, Geneva
2
Abstract

• Abstract. Emerging technologies, such as the
  Internet and the World-Wide Web has created
  overnight new application areas for software,
  including eBusiness, web services, ubiquitous
  computing, and peer-to-peer networks. These
  areas demand software that is robust, can operate
  within a wide range of environments, and can
  evolve over time to cope with changing
  requirements. Moreover, such software has to be
  highly customizable to meet the needs of a wide
  range of users, and sufficiently secure to
  protect personal data and other assets on behalf
  of its stakeholders. We argue that such
  challenges can only be met by software components
  that are intentional in the sense that they have
  associated goals they are supposed to satisfy
  under different circumstances.
• We are developing a methodology, called Tropos,
  for building such agent-oriented software
  systems. The methodology covers five software
  development phases early requirements analysis,
  late requirements analysis, architectural design,
  detailed design, and implementation. Throughout,
  the concepts offered by i Yu95 are used to
  model both the stakeholders in the system's
  environment, and the system itself. These
  concepts include actors, who can be (social)
  agents (organizational, human or software),
  positions or roles, also

3
Abstract (contd)

• social dependencies for defining the obligations
  of actors to other actors (called dependees and
  dependers respectively.) Dependencies may involve
  a goal, to be fulfilled by the dependee on behalf
  of the depender, a task to be carried out by the
  dependee, or a resource to be delivered.
• The presentation sketches on-going research on
  the Tropos methodology, a formal language we
  have designed founded on i, formal analysis
  techniques under development, as well as design
  pattern ideas we are exploring inspired by
  organizational theory.
• Yu95 Eric Yu, Modelling Strategic Relationships
  for Process Re-Engineering, PhD thesis,
  Department of Computer Science, University of
  Toronto, 1995.

4
Object-Oriented Information System Evolution

• Ever-changing business environments
• Emerging application areas, e.g., web services,
  peer-to-peer computing, eBusiness and more!
• We need new concepts, methods and tools for
  building software systems that are continuously
  evolving and are based on open, dynamic, and
  distributed architectures.
• Where are these concepts, methods
• and tools going to come from?

5
Agent-Oriented Software!

• We retain object orientation, behavioral
  encapsulation and other abstractions, as found in
  object-oriented software development.
• We augment these with intentional encapsulation
  for certain objects (agents) by associating
  goals to such objects.
• Goal analysis (both informal and formal) becomes
  a centerpiece of the new methodology.

6
Why Agent-Oriented Software?

• We need 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 exception handling become essential features
  for such software components.
• ... agents!

7
Agent-Oriented Software Engineering

• 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.
• In the Tropos project, we are developing a
  methodological framework for building
  agent-oriented software that supports both
  requirements analysis, as well as design.

8
What is an Agent?

• A person, an organization, certain kinds of
  software.
• Why worry about human/organizational agents?
  Because their goals lead to software
  requirements, and these influence the design of a
  software system.
• Note the role of such agents in OOA, -- use
  cases.
• Also note the role of agents in up-and-coming
  requirements engineering techniques such as KAOS
  Dardenne93 where requirements analysis begins
  with a set of goals these are analysed/decomposed
  to simpler goals which eventually either lead to
  software requirements, or are delegated to
  external agents.

9
The Tropos Methodology

• We propose a set of primitive concepts and a
  methodology for agent-oriented requirements
  analysis and design.
• We want to cover four phases of software
  development
• Early requirements -- identifies stakeholders and
  their goals
• Late requirements -- introduce system as another
  actor which can accommodate some of these goals
• Architectural design -- more system actors are
  added and are assigned responsibilities
• Detailed design -- completes the specification of
  system actors.

10
Early Requirements?

• Early requirements identify stakeholders and
  their goals.
• The KAOS project defines the state-of-the-art on
  modeling early requirements in terms of goals
  also offers well-developed analysis techniques
  and tools for generating late requirements.
• We adopt the i framework of Eric Yu Yu95. In
  this framework, stakeholders are represented as
  actors who have goals (hard or soft).
• Moreover, Actors Agents ? Positions ? Roles.

11
Early RequirementsExternal Actors and their
Goals

• A social setting consists of actors, each having
  goals (and/or softgoals) to be fulfilled.

Low cost scheduling
Manager
Participant
actor
Good meeting
Schedule meeting
Productive meetings
Schedule meeting
goal
softgoal
12
Goal Analysis

-

-

-
-

Collect timetables
Choose schedule
By person
By system
Manually
Automatically
By all means
By email
Have updated timetables
Collect them
13
Important Concepts in Goal Analysis

• An alternative (solution) to the fulfillment of a
  goal G consists of one or more leaf goals which
  together fulfill the root goal.
• A goal model defines a space of alternatives for
  the fulfillment of its root goal.
• An alternative A1 is better than A2 in fulfilling
  goal G with respect to softgoals G1, G2, if A1s
  net contributions to G1, G2, (I.e., positive
  minus negative contributions) is greater than
  that of A2.
• In general, goals and softgoals can be
  contradictory. Given a set of root goals and
  softgoals, there may not be an optimal solution
  Simon68. Hence the search for good-enough
  solutions.

14
Actor Dependencies
Schedule meeting
Collect timetables
task
Through personal contact
Reception
By email
Actor dependencies are intentional One actor
wants something, another is willing and able to
deliver.
15
Actor Dependency Models
Initiator
ContributeToMtg
UsefulMtg
ScheduleMtg
CalendarInfo
Scheduler
Participant
AttendMtg
resource
SuitableTime
16
Design Software with these Concepts

• During early requirements, these concepts are
  used to model external stakeholders (people,
  organizations, existing systems), their relevant
  goals and inter-dependencies.
• During late requirements, the system-to-be enters
  the picture as one or a few actors participating
  in i models.
• During architectural design, the actors being
  modelled are all system actors.
• During detailed design, we are not adding more
  actors and/or dependencies instead, we focus on
  fully specifying all elements of the models we
  have developed.

17
Late Requirements with i
Initiator
ContributeToMtg
UsefulMtg
ScheduleMtg
System
CalendarInfo
Timetable manager
Scheduler
Participant
Manage CalendarInfo
AttendMtg
MtgInfo
Reporter
SuitableTime
18
Software Architectures with i
System
Timetable manager
Collect CalendarInfo
Participant
Update MtgInfo
CalendarInfo
InfoGatherer
Retrieve MtgInfo
Reporter
Updater
Process query
Retriever
19
...Yet Another Software Development Process

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

20
What is Different?

• Goal refinement extends functional decomposition
  techniques, in the sense that it explores
  alternatives.
• Actor dependency graphs extend object interaction
  diagrams in that a dependency is intentional,
  needs to be monitored, may be discarded, and can
  be established at design- or run-time.
• In general, an actor architecture is open and
  dynamic evolves through negotiation, matchmaking
  and like-minded mechanisms.
• The distinction between design and run-time is
  blurred.
• So is the boundary between a system and its
  environment (software or otherwise.)

21
Why is this Better (Sometimes)

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

22
The Tale of Two Designs
Controller
Controller
Display(Please see Smith tomorrow morning at
9am)
Communicate (mtg062)
Interface
Interface
An actor fulfils a goal by trying out one or
more alternative solutions these can be
determined at design- or run-time.
23
So, Where is the Payoff for Software Evolution?

• Top level goals remain relatively constant
  softgoal priorities change, leading to different
  good-enough alternatives.
• A software design model, consisting of
  requirements and design diagrams can serve as
  blueprint for software evolution. Evolution is
  supported for alternatives within a given design
  space.
• Moreover, the system itself can be endowed with
  facilities (negotiation, planning, ) for
  evolving at run-time to meet its early
  requirements goals.

24
Formal Tropos

• Each concept in a Tropos diagram can be defined
  formally, in terms of a temporal logic inspired
  by KAOS.
• Actors, goals, actions, entities, relationships
  are described statically and dynamically.

Claims payout
Insurance Company
Premium payment
Customer
Repairs covered
25
A Formal Tropos Example

• Entity Claim
• Has claimId Number, insP InsPolicy, claimDate,
  date Date, details Text
• Necessary date before insP.expDate
• Necessary ("x)(Claim(x) Ù lClaim(x) Þ
  RunsOK(x.insP.car))
• end Claim
• Action MakeRepair
• Performed by BodyShop
• Refines RepairCar
• Input cl Claim
• Pre ?RunsOK(cl.insP.car)
• Post RunsOK(cl.insP.car)...

26
Analysing Models

• Models are used primarily for human communication
• But, this is not enough! Large models can be hard
  to understand, or take seriously!
• We need 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
• Goal analysis which determine the fulfillment of
  a goal, given information about related goals
• Social analysis which looks at viability,
  workability, for a configuration of social
  dependencies.

27
Model Checking for Tropos

• Goal Apply model checking to richer models than
  those that have been tried before.
• Approach
• Definition of an automatic translation from
  Formal Tropos specifications to the input
  language of the nuSMV model checker Cimatti99.
• Verification of temporal properties of state
  representations of finite Tropos models.
• Discovery of interesting scenarios that represent
  counterexamples to properties not satisfied by
  the specifications.
• Model simulation.

28
A Formal Goal Model

• We use S(atisfied), D(enied) and dont assume
  that they are logically exclusive (remember,
  goals may be contradictory!)
• We offer several axioms for every goal
  relationship.
• ?g1,g2,g3AND(g1,g2,g3) Þ ((S(g1)?S(g2))Þ
  S(g3))
• ?g1,g2,g3OR(g1,g2,g3) Þ ((S(g1)?S(g2))Þ
  S(g3))
• ?g1,g2(g1,g2) Þ (S(g1) Þ S(g2))
• ?g1,g2(g1,g2) Þ ?g(g?g2?S(g)?S(g1)) Þ
  S(g2)
• ?g1,g2,g3AND(g1,g2,g3) Þ ((D(g1) ? D(g2))Þ
  D(g3))
• ?g1,g2,g3OR(g1,g2,g3) Þ ((D(g1) ? D(g2))Þ
  D(g3))
• ?g1,g2(g1,g2) Þ (D(g1) Þ D(g2))
• ?g1,g2(g1,g2) Þ ?g(g?g2?(D(g)?D(g1))) Þ
  D(g2)
• ...more axioms for predicate D, goal
  relationships --, -...

29
Goal Graph

-

-

-
-

Collect timetables
Choose schedule
By person
By system
Manually
Automatically
By all means
By email
Have updated timetables
Collect them
30
Qualitative Goal Analysis

• Given a goal graph, we can instantiate these
  axioms into a collection of propositional Horn
  clauses, e.g.,
• ?g1,g2,g3AND(g1,g2,g3) Þ ((S(g1)?S(g2))Þ
  S(g3))
• (S(collectTbl)?S(chooseSchl))Þ
  S(scheduleMtg)
• We are also given some S and D labels for some
  goals, e.g., S(haveUpdatedTbl)
• There is an O(N) proof procedure which will
  generate all inferences from these axioms. Our
  proof procedure works as a label propagation
  algorithm.
• We have also developed algorithms to accommodate
  probabilities and criticalities for goals.

31
Dependency Graph Analysis

• Given a set of actors, each with associate root
  goals, and a goal graph for each root goal, find
  a dependency graph which fulfills all root goals

A1
A2
A1
G
G
A1
G2
G1
A2
G2
G2
G1
32
Well-Formed Dependency Graphs

• Some dependency graphs dont make sense...
• What is a good dependency graph assuming that
  we are interested in
• minimizing dependence
• distributing work.
• Algorithms for transforming dependency graphs.

A1
A2
G
G
33
The Media Shop Example

• Media taxonomy
• on-line catalog
• DBMS
• E-Shopping Cart
• Check In
• Buying
• Check Out
• Search Engine
• catalog browser
• Keywords
• full-text
• Secure
• transactions
• orders
• Multimedia
• description
• samples

34
Related Work
JACK
i
TROPOS
GAIA
KAOS
Z
AUML
UML, Catalysis Co.
!! The GAP !!
Detailed design
Early requirements
Architectural design
Late requirements
Implementation
35
The Tropos Project

• Project was launched in April 2000.
• The team of participating researchers includes
• UToronto (Canada) Ariel Fuxman, Manuel Kolp,
  Linda Liu, Eric Yu
• UTrento/IRST (Italy) Paolo Bresciani, Paolo
  Giorgini, Fausto Giunchiglia, Anna Perini, Marco
  Pistore, Marco Roveri, Roberto Sebastiani, Paolo
  Traverso
• FUPernambuco (Brazil) Jaelson Castro
• Publications and other information about the
  project can be found at
• http//www.cs.toronto.edu/km/tropos

36
Conclusions

• We have argued that software evolution entails
  software that is intentional, hence the call for
  agent-orientation.
• We proposed a set of concepts and sketched a
  methodology (Tropos) that can support
  agent-oriented software development.
• We sketched on-going work on formal analysis
  tools for Tropos models.
• Remember
• This is on-going work!

37
References

• Bauer99 Bauer, B., Extending UML for the
  Specification of Agent Interaction Protocols. OMG
  document ad/99-12-03.
• 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.
• Fuxman01a .Fuxman, A., Pistore, M., Mylopoulos,
  J. and Traverso, P., Model Checking Early
  Requirements Specifications in Tropos,
  Proceedings Fifth International IEEE Symposium on
  Requirements Engineering, Toronto, August 2001.
• Fuxman01b Fuxman,A., Giorgini, P., Kolp, M.,
  Mylopoulos, J., Information Systems as Social
  Organizations, Proceedings International
  Conference on Formal Ontologies for Information
  Systems, Ogunquit Maine, October 2001.
• Iglesias98 Iglesias, C., Garrijo, M. and
  Gonzalez, J., A Survey of Agent-Oriented
  Methodologies, Proceedings of the 5th
  International Workshop on Intelligent Agents
  Agent Theories, Architectures, and Languages
  (ATAL-98), Paris, France, July 1998.

38
...More References

• Jennings00 Jennings, N. On Agent-Based
  Software Engineering, Artificial lntelligence
  117, 2000.
• 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.
• Simon69 Simon, H., The Sciences of the
  Artificial, The MIT Press, 1969
• Wooldridge00 Wooldridge, M., Jennings, N., and
  Kinny, D., The Gaia Methodology for
  Agent-Oriented Analysis and Design, Journal 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.