OOAD – III Software Design

Nupul Kukreja 10

th

October, 2014

• • • •

Agenda

Technical Architecture (TA) – What?

– Good TA – – Winbook TA Why/When?

Detailed Design – What/How?

– Sequence Diagrams (SD) • What/Why?

• How?

Hands on In class – Robustness Diagram – High level SD – Low level SD Conclusion

Diving Deeper

TECHNICAL ARCHITECTURE

Language Influenced • Main program and sub-routines • Object-oriented Layered Dataflow Styles Shared Memory • Virtual Machine • Client-Server • Batch-sequential • Pipe-and-filter • Blackboard • Rule-based Implicit Invocation • Publish/Subscribe • Event-based Interpreter • Interpreter • Mobile code REST • Representational State Transfer (e.g. WWW) Peer-to-Peer • (e.g. Gnutella, Skype, Napster etc.,)

General

Twin Peaks: Requirements and Architecture

Level of Detail Detailed Independent

Requirements Architecture

Implementation Dependence Dependent

Good Technical Architecture

• • • • • • Built to satisfy business and level of service requirements of the system Describes: – – Deployment model (topology, servers etc.,) Package/component model (separation of concerns) – Data Model (ER diagram etc.,) Addresses –ilities effectively (i.e., scalability, security, availability etc.,) Testable Shows external systems to be interfaced with Increase confidence of “being right”

Presentation Layer: Tomcat/Restlet Client: HTML/JS Data Access Layer: Spring/JDBC Database

Technical Architecture – When & Why?

• • Done much before robustness analysis – In parallel to/before requirements negotiation – Refined as more learned about system You must know the high-level “how” to derive the low/design-level “how” – Allocating methods to classes – Which classes/services to involve?

– Which methods to call and in what order?

– To think about the code before coding it

Diving into design

SEQUENCE DIAGRAMMING

Detailed OOD

• • • • • Domain modeling, use-case and robustness analysis  discovering “classes” Detailed design  “allocating” behavior i.e., allocating methods to classes Works within the technical architecture defined Reifies our initial guess of how classes really interact with each other Sequence diagrams are “one” way to drive detailed design – Use case  Robustness  Sequence Diagram

Sequence Diagram Notation

“Why” Sequence Diagramming

• • • Allocate behavior to classes – Controllers  operations on classes or separate controller objects Show detailed interaction among classes over lifetime of use-case – “how” do objects communicate to realize use case Finalize distribution of operations among classes – Who’s doing what and to whom?

“How” to do it?

• – Start from where you left off with Robustness Analysis (RA) One sequence diagram per use case 1. Copy the correct, detailed & explicit use case text to SD 2. Copy entity objects from RA diagram to SD 3. Copy boundary objects and actors from RA diagram to SD 4. Assign operations to classes (actual thinking work)

HANDS ON EXERCISE

A user enters the their email id and password on the login page. The system checks if the user is registered by validating their account against the set of registered users. If the user is registered he is taken to the page showing the list of projects

Alternative course:

-Invalid login/ password: The system displays invalid username/ password

Blank 1

Blank 2

Reiteration of Steps

1. Create an initial high level OO sequence diagram only involving boundary/entity objects from RA diagram 2. Add implementation level details/classes to sequence diagram – Allocate/call appropriate framework methods 3. Review SD to validate correctness 4. Update static class diagram with implementation classes and identified methods 5. Repeat for each use case 6. Move to coding after thorough reviewing 7. Update SD as you identify gaps in design done  documentation obsolete degradation   rarely Architectural