1 / 19

The Prometheus-ROADMAP Methodology

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. Overview. Background

harlan-duncan
Download Presentation

The Prometheus-ROADMAP Methodology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 PDT • System Specification • Architectural Design • Detailed Design • Testing • Debugging PDT PDT • Implementation • Debugging • Testing

  6. Stakeholders Prometheus Initial system description • The System Specification Phase System goals System Specification Scenarios Actions, Percepts Functionality descriptors Architectural design

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

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

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

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

  11. System Overview Diagram Agents Data Protocols Percepts Actions

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

  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. Prometheus provides • details in these models • and a little in the • environment model Overview of Models Domain specific Application specific Reusable service models Goal Model Environment Model Social Model Role Model Knowledge Model Service Model Agent Model Interaction Model

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

  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: • Knowledge Model • Environment Model • Possibly need a Task Model • Social Model • Services 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

More Related