1 / 8

RAD Review

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

craig
Download Presentation

RAD Review

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

  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)

  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 ]

  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]

  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]

  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 • Key Roles • Architect • Architecture Liaisons – member of subsystem team • Document Editor • Configuration Manager • Reviewer

  7. Iteration!

  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)

More Related