OOAD – IIISoftware Design

Nupul Kukreja10th 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

TECHNICAL ARCHITECTUREDiving Deeper

•Main program and sub-routines

•Object-oriented

Language Influenced

•Virtual Machine

•Client-Server

Layered

•Batch-sequential

•Pipe-and-filter

Dataflow Styles

•Blackboard

•Rule-based

Shared Memory

•Publish/Subscribe

•Event-based

Implicit Invocation

•Interpreter

•Mobile code

Interpreter

•Representational State Transfer (e.g. WWW)

REST

•(e.g. Gnutella, Skype, Napster etc.,)

Peer-to-Peer

Twin Peaks: Requirements and Architecture

Requirements Architecture

General

Detailed

Level of

Detail

Implementation Dependence

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

Client: HTML/JS

Presentation Layer: Tomcat/Restlet

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

SEQUENCE DIAGRAMMINGDiving into design

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 SD3. Copy boundary objects and actors from RA

diagram to SD4. 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 Steps1. Create an initial high level OO sequence diagram only

involving boundary/entity objects from RA diagram2. Add implementation level details/classes to sequence

diagram– Allocate/call appropriate framework methods

3. Review SD to validate correctness4. Update static class diagram with implementation

classes and identified methods5. Repeat for each use case6. Move to coding after thorough reviewing7. Update SD as you identify gaps in design rarely done

documentation obsolete Architectural degradation