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

Loading...

PPT – Managing Knowledge for Business Analysts: The Executive Information Portal PowerPoint presentation | free to download - id: 1b7e77-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Managing Knowledge for Business Analysts: The Executive Information Portal

Description:

9th International Conference on Object-Oriented Information Systems (OOIS'03) ... OOIS'03 -- 13. Important Concepts in Goal Analysis ... – PowerPoint PPT presentation

Number of Views:31
Avg rating:3.0/5.0
Slides: 39
Provided by: johnmyl
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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, --gt 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 Requirements External 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))
  • gt (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.
About PowerShow.com