Your SlideShare is downloading. ×
Download
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Download

224
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
224
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tropos at the Age of 6: Status and Research Directions John Mylopoulos University of Trento March 2, 2006 DIT, UniTN, Trento
  • 2. Research Baseline
    • Modeling social settings with i* [Yu93].
      • Proposed as a modeling framework for early requirements, business process reengineering,…
    • Design of modeling languages
      • Taxis -- design language for information systems (1977-87)
      • Telos -- metamodeling language for integrated software development environments (1986-96)
  • 3. … Namur, Belgium,1995 … Tropos* Ontology St ructuring Processes, actors, dependencies, resources,... Application area Business re-engineering, virtual corporations, enterprise integration, software processes,... Contexts, denotation, representation (+ gene-ralization, aggregation, classification and attri-bution) Tools Process re-engineering, analysis, enactment support
    • Tropos (G reek) means manner (as in “manner of doing things ”)
    • [Odyssey, line 1: "…  "]
  • 4. … An Idea …
    • Software Engineering methodologies have come about in a “late-to-early” (or, “downstream-to-upstream”) fashion.
    • In particular, Structured Programming preceded (and influenced!) 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 to be conceived.
    • What would happen if we projected requirements concepts downstream to define software designs and even implementations?
  • 5. A Research Project
    • Develop a software development methodology founded on the notions of actor , , goal/softgoal , and strategic actor dependency .
    • These concepts are to be used in all phases of software development (as with UML).
    • If these are the concepts we use to conceive software, we are obviously developing agent-oriented software systems.
    • There are implementation environments for such systems; accordingly we focus on earlier phases.
  • 6. What is Software?
    • An engineering artifact, designed, tested and deployed using engineering methods; rely heavily on testing and inspection for validation ( Engineering perspective )
    • A mathematical abstraction, a theory, which can be analyzed for consistency and can be refined into a more specialized theory ( Mathematical perspective )
    • A non-human agent, with its own personality and behavior, defined by its past history and structural makeup ( CogSci perspective )
    • A social structure of software agents, who communicate, negotiate, collaborate and cooperate to fulfill their goals ( Social perspective )
  • 7. Research Tasks
    • Develop a methodology, illustrated through case studies ([Castro01], [Bresciani01]), supported by a prototype environment [->].
    • Develop formal analysis techniques for Tropos models:
      • Simulation through model checking, to explore temporal properties of models [Fuxman01];
      • Goal analysis that determine the fulfillment of a goal, given information about related goals [Giorgini02];
      • Social analysis that looks at configurations of actor dependencies [Bryl06].
  • 8. Probabilistic Goals
    • A generated design for a given (generic) goal is supposed to fulfill (all!) its instances …, but in general it won't!
    • Can we make precise claims about a design, e.g., "If D is true X% of the time, then an ambulance can be in the place of accident anywhere in London within 15' 85% of the time"
    • Modeling and reasoning with probabilistic actions (e.g., "submit paper to conference") also an issue.
    • Use DT-Golog, PhD thesis by Mikhail Soutchanski.
  • 9. Goal models By all means By email - - + + + + - - Collect timetables By person By system Have updated timetables Collect them Choose schedule Manually Automatically Schedule meeting Matching effort Collection effort Minimal conflicts Degree of participation Quality of schedule Minimal effort
  • 10. Designing for High Variability
    • …  software!
    • A goal model defines a space of alternatives for fulfilling a goal. Design a system that supports all alternatives rather than one.
    • Generate generic design views from a goal model (Yijun Yu, Alexei Lapouchnian, Sotiris Liaskos), [Yu06].
    • Characterise goal variability [Liaskos06].
    • Application of these ideas to the design of domotic software systems (helps an elderly person live at home [Hui03]).
  • 11. From a Goal Model to a Statechart
  • 12. Modeling Preferences
    • Our language for modeling preferences (softgoals, controbutions) is rather coarse-grained.
    • Use recent results from Knowledge Representation on representing and reasoning with preferences to offer a more expressive language for modeling preference, with suitable tool support.
    • When a planner looks for a plan to satisfy a goal, it prefers plans that satisfy preferences.
    • Based on work by Sheila McIlraith and her students (Liaskos).
  • 13. From Goals to Database Designs
    • Requirements Engineering (RE) has changed dramatically in the past 15 years: early requirements, goal-oriented RE,…
    • … but not database design!
    • Develop a systematic, tool-supported process for going from goal models, to information models, to conceptual (e.g., ER) schemas.
    • Lei Jiang, Thodoros Topaloglou, Alex Borgida [Jiang06].
  • 14. Designing Business Processes
    • Instead of generating software designs, let's generate business process designs.
    • Work with IBM's WebSphere Business Modeler group.
    • We have a tool-supported design process that can even generate BPEL.
    • Alexei Lapouchnian, Yijun Yu.
  • 15. Designing Autonomic Software
    • Autonomic software: can self-configure, self-repair, self-optimize, (self-protect).
    • For us,
    • autonomic = high-variability + monitoring + diagnosis + reconfiguring
    • We start from AI theories of diagnosis, develop design techniques for monitoring and diagnosis (Yiqiao Wang).
    • Computer Associates Inc. wants techniques for reengineering their logging and diagnostic facilities.
  • 16. Designing Virtual Organizations
    • Consider a technology park where several SMEs form vistual organizations to carry out large projects (that they can't conduct individually).
    • How do we design them? How do we analyze the designs?
    • Thesis work by Enzo Colombo at the Politecnico di Milano
    • Proposes a 3-view design process: social, intentional and process. Offers analysis techniues for each. i*/Tropos used for the social+intentional views. Patterns are proposed.
  • 17. The Longer Term
    • This is on-going work that is part of someone's PhD thesis.
    • There is some interest from industry (IBM, CA).
    • But what might be the longer term objective of all this research (including the work we do in Trento)?
    • A Science of Software Design!