1. The Prometheus-ROADMAP Methodology Lin Padgham in collaboration with Leon Sterling and Michael Winikoff School of Computer Science and IT, RMIT University, Melbourne, Australia and School of Computer Science and Software Engineering The University of Melbourne

2. Overview  Background  Prometheus overview  ROADMAP overview  Integration issues  Current plans

3. Background and motivation  5-7 years ago there were no AOSE methodologies.  It was an important gap.  Now there are many (30+) with 5-6 moderately well established.  Better value if we integrate and work together.  Especially true when we are only 2km from each other!!

4. Prometheus Overview  Methodology developed over 7-8 years in collaboration with industry partner. Feedback from many students and industry partner clients.  Focus on detailed guidance and structure to facilitate tool support.  Mixture of graphical for overview and (structured) text for detail.  Hierarchical and modular.  Prototype tool available and used externally

5. Prometheus  System Specification  Architectural Design  Detailed Design  Testing  Debugging Implementation Debugging Testing PDT

6. Prometheus  The System Specification Phase Actions, PerceptsScenarios Functionality descriptors Architectural design SystemSpecification System goals Initial system description Stakeholders

7. 4) Add a corresponding system goal for each use-case Steps in Prometheus (Example) 1) Identify actors 2) Identify top-level scenarios for each actor 3) Identify inputs/outputs (actions/percepts) process returned books check-out books book borrowed customer receipt order books Order Books

8. Continue with goals and scenarios 5) Apply Goal Abstraction to system goals 6) Refine Goals (OR/AND refinement) Order books Find cheapest priceOrganise delivery Maintain large range of books Borrow books from other libraries Log Order why?how? OR AND 7) Link goals to (sub) scenarios how ? Scenario

9. Develop Scenarios  Trigger: …  Body  1: GOAL …  2: SCENARIO  3: GOAL …  4: ACTION …  Variations … Scenario Structured Entities (also includes information on data and functionalities).

10. Architectural Design Phase System specification artifacts Actions, Percepts Scenarios Functionality descriptors Detailed design ArchitecturalDesign System goals System overview Agent types Interaction diagrams Conversation protocols

11. System Overview Diagram Agents Protocols Data Percepts Actions

12. Detailed Design Phase Architectural design artifacts Implementation Detailed Design System overview Agent types Conversation protocols Agent overview Capability overview Plan types Process diagrams

13. Prometheus strong points  Structured processes to refine design.  Automated consistency checking between (some of) the design artifacts.  Hierarchical and modular views.  Actively continuing development…

14. ROADMAP  More abstract and high level than Prometheus.  Concerned with high level view of models needed.  Focusses particularly on requirements analysis.

15. Overview of Models Goal Model Role Model Agent Model Interaction Model Environment Model Knowledge Model Social Model Service Model Domain specificApplication specificReusable service models Prometheus provides details in these models -and a little in the environment model

16. Goal Model Librarian User Borrow book Goal Soft goal Select book Register borrower Provide return date Role Friendly Large choice

17. Integration with Prometheus  Prometheus actors/stakeholders and functionalities become external/internal roles  Can identify goals or scenarios at top level  Add soft goals as annotations on all entities  Percepts and actions possibly wait till architectural design  Still need to decide common notation

18. The ROADMAP models…  Goal hierarchy (Requirements, propagates down)  Roles associated with goals (Requirements)  Interaction model:  Scenarios (Requirements).  Protocols (Architectural design) Requiring more work: Social Model Services Model Knowledge Model Environment Model Possibly need a Task Model

19. Current plans  Work with others to get shared and/or interoperable processes  Maintain focus on automated tool support  Work with others to standardise notation  Explore team and organisational modelling  Integrate tool support within Eclipse  Extend tool  Integrate completed work on debugging/testing