Transcript ddd - ICAR-CNR

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
Prometheus overview
ROADMAP overview
Integration issues
Current plans
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!!
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
Prometheus
 System Specification
PDT
 Architectural Design
PDT
 Detailed Design
PDT
•Implementation
 Testing
•Debugging
 Debugging
•Testing
Prometheus
 The System Specification Phase
Initial system
description
System
Specification
System
goals
Stakeholders
Scenarios
Functionality
descriptors
Architectural
design
Actions, Percepts
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
check-out books
Admin
Librarian
order books
process returned books
Continue with goals and scenarios
5) Apply Goal Abstraction to system goals
6) Refine Goals (OR/AND refinement)
7) Link goals to (sub) scenarios
Maintain large
range of books
how?
OR
Borrow books
from other libraries
why?
Order books
AND
Find cheapest price
Scenario
how?
Organise delivery
Log Order
Develop Scenarios
Scenario
 Trigger: …
 Body




1: GOAL …
2: SCENARIO
3: GOAL …
4: ACTION …
 Variations …
Structured Entities
(also includes information
on data and functionalities).
Architectural Design Phase
System specification artifacts
Actions,
Percepts
Architectural
Design
Scenarios
System
goals
Interaction
diagrams
Conversation
protocols
System
overview
Detailed design
Functionality
descriptors
Agent
types
System Overview Diagram
Agents
Data
Percepts
Protocols
Actions
Detailed Design Phase
Architectural design artifacts
Detailed Design
Conversation
protocols
Process
diagrams
System
overview
Agent
types
Agent
overview
Capability
overview
Plan
types
Implementation
Prometheus strong points
 Structured processes to refine design.
 Automated consistency checking between
(some of) the design artifacts.
 Hierarchical and modular views.
 Actively continuing development…
ROADMAP
 More abstract and high level than
Prometheus.
 Concerned with high level view of models
needed.
 Focusses particularly on requirements
analysis.
Overview of Models
Domain specific
Environment
Model
Knowledge
Model
Prometheus provides
details in these models
-and a little in the
environment model
Application specific Reusable service
models
Goal Model
Role Model
Agent Model
Interaction
Model
Social
Model
Service
Model
Goal Model
Role
Goal
Soft
goal
User
Librarian
Borrow book
Large
choice
Friendly
Select
book
Register
borrower
Provide
return date
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
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
• Social Model
• Environment Model
• Services Model
• Possibly need a Task Model
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