The PrometheusROADMAP Methodology - PowerPoint PPT Presentation

About This Presentation
Title:

The PrometheusROADMAP Methodology

Description:

Focus on detailed guidance and structure to facilitate tool support. ... Focusses particularly on requirements analysis. Overview of Models. Goal Model. Role Model ... – PowerPoint PPT presentation

Number of Views:73
Avg rating:3.0/5.0
Slides: 20
Provided by: mikhailper
Category:

less

Transcript and Presenter's Notes

Title: The PrometheusROADMAP Methodology


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

PDT
PDT
PDT
  • Implementation
  • Debugging
  • Testing

6
Prometheus
  • The System Specification Phase

Initial system description

System goals
System Specification
Actions, Percepts
Scenarios
Functionality descriptors
Architectural design
7
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
Continue with goals and scenarios
5) Apply Goal Abstraction to system goals
6) Refine Goals (OR/AND refinement)
Maintain large range of books
Scenario
why?
how?
OR
Order books
Borrow books from other libraries
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
  • System specification artifacts

Actions, Percepts
Functionality descriptors
System goals
Scenarios
Interaction diagrams
Agent types
Architectural Design
System overview
Conversation protocols
Detailed design
11
System Overview Diagram
Agents
Data
Protocols
Percepts
Actions
12
Detailed Design Phase
  • Architectural design artifacts

System overview
Agent types
Conversation protocols
Agent overview
Process diagrams
Capability overview
Detailed Design
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
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 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
  • 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
Write a Comment
User Comments (0)
About PowerShow.com