Tropos: Agent -Oriented Software Engineering

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 (RCIS’09), 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. Initiator Participant ValidateUser <<uses>> RequestedMtg ScheduledMtg MtgRequirement Timetable <<extends>> Provide Constraints Withdraw ScheduleMtg Edit Constraints Object-Oriented Software Development 7:sendSchedule() scheduler :Person initiator :Person 6:prompt() 1:giveDetails() 8:approveSchedule() 3:acknowledge() 5:sendDetails() participant :Person staff :Person 2:inform() 4:remind() 9:inform() Meeting Person attends name time place email 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 … • It’s 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. Schedule meeting Choose schedule By Person Collect timetables Automatically Manually Collect from users Collect from agents Receive request Send request By System Goal Analysis Leads to Alternatives (Functional/hard) Goals AND AND OR OR OR OR OR OR AND AND

10. Schedule meeting Choose schedule By Person Collect timetables Automatically Manually Collect from users Collect from agents Receive request Send request By System Collect 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 AND AND User Tailorability 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 ( --> actors) and their requirements ( --> 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 won’t do in situations where the operational environment of a system, including its stakeholders, keeps changing. • This won’t 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-Variability+Monitoring+Diagnosis+Compensation • 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. WID WID WB Monitor Open OME WPS WB Modeler 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 Business Measures BPEL, WSDL, XSD 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 (CAiSE’06), 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., “Goal–directed 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 (RE’05), 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/abstracts.html#AbsMod. • [Lapouchnian07] Lapouchnian, A., Yu, Y., Mylopoulos, J., “Requirements-Driven Design and Configuration Management of Business Processes”, 5th International Conference on Business Process Management (BPM’07), 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 (CAiSE’06), 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 (ASE’07), 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, 285–312. • [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, 326–346. • [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).