RAD Review
description
Transcript of RAD Review
COP 3331 Object-Oriented Analysis and Design 1
RAD Review
Describes system completely from actors’ point of view Basis of client – developer communication Platform for launch of system design & development Provides these specific items:
Set of nonfunctional requirements and constraints Use case model describing functionality of system from client’s perspective Object model describing entities manipulated by system Sequence diagram for each use case showing sequence of interactions among
participating objects
“Analysis Model”
COP 3331 Object-Oriented Analysis and Design 2
Design Overview
Design Overview (Ch 6) Review of RAD System Design System Design Concepts System Design Goals
(Global) System Design (Ch 7) Design Goals Software Architecture Boundary Use Cases SDD
Subsystem Design Patterns (Ch 8) Interfaces (Ch 9) Mapping to Code (Ch 10)
COP 3331 Object-Oriented Analysis and Design 3
System Design Concepts
Subsystems Relate to Analysis Objects Coupling and Cohesion Services / Subsystem Interfaces Hierarchical Decomposition
open v closed Partition Decomposition
Architectural Styles [pp. 237 – 246] Repository [classic DB] Model/View/Controller Client/Server Peer to Peer 3-Tier [Interface | Application Logic | Storage] 4-Tier [Client Interface | Server Interface | Application Logic | Storage] Pipe & Filter [ ps auswww | grep lacher | sort | more ]
COP 3331 Object-Oriented Analysis and Design 4
System Design Activities
0. Starting Point: RAD
1. Identify Design Goals [from non-functional requirements] performance criteria [p. 249] dependability criteria [p. 249] cost criteria [p. 250] maintenance criteria [p. 250] end user criteria [p. 251] Design Goal Tradeoffs [p. 251]
2. Identify Subsystems influenced by
use cases lower cross-boundary associations [lower coupling] functionally related objects [ higher cohesion]
COP 3331 Object-Oriented Analysis and Design 5
System Design Activities (cont)
3. Address Design Goals
Note: BEFORE subsystem designs Select OTS & legacy components Map subsystems to hardware
Proxy Design Pattern Plan infrastructure for management of persistent data
Identify persistent objects Select storage management strategy [see fig 7-7, p. 269]
– flat files
– relational DB
– OODB Specify access control policies [ can of worms]
Global access table Access control map (associated with each class) [table.column] Capability map (associated with each actor) [table.row]
COP 3331 Object-Oriented Analysis and Design 6
System Design Activities (cont)
3. Address Design Goals (cont) Design global control flow
Procedure Driven Event Driven Threaded
Identify boundary conditions Configuration Startup / Shutdown Exception Handling Administration Use Cases – generated by design team
4. Key Roles Architect Architecture Liaisons – member of subsystem team Document Editor Configuration Manager Reviewer
COP 3331 Object-Oriented Analysis and Design 7
Iteration!
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1
Describe boundaryconditions
Define Definesubsystems
Map subsystemsto hardware/
Manage
Select a
Define access
design goals
persistent data
control policies
global
Implementsubsystems
software platform
control flow
Figure 7-1, The activities of system design.
COP 3331 Object-Oriented Analysis and Design 8
Closing the Gap
[Client with problem] ... [Machine] : huge distance Analysis, resulting in [RAD] ... [Machine]: gap is smaller System Design, resulting in [SDD] ... [Machine]: smaller still At this point SDD should specify a virtual machine VM Object design and mapping to code reduce gap even further, to
point where compilers completely close the gap Notice that we always work from left to right (with feedback
loops): Client -> Analysis -> RAD -> System Design -> SDD -> Object Design
-> Code -> Build -> executable system Feedback loops at each stage Changes at any stage usually require re-work of all following stages, so emphasis
should be on localized feedback loops (i.e., go back only one step, repeat until correct)