RAD Review

8
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”

description

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 - PowerPoint PPT Presentation

Transcript of RAD Review

Page 1: 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”

Page 2: RAD Review

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)

Page 3: RAD Review

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 ]

Page 4: RAD Review

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]

Page 5: RAD Review

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]

Page 6: RAD Review

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

Page 7: RAD Review

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.

Page 8: RAD Review

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)