OOAD – III
Software Design
Nupul Kukreja
10th 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
• Virtual Machine
• Client-Server
Dataflow Styles
• Batch-sequential
• Pipe-and-filter
Shared Memory
• Blackboard
• Rule-based
Implicit Invocation
Interpreter
REST
Peer-to-Peer
• Publish/Subscribe
• Event-based
• Interpreter
• Mobile code
• Representational State Transfer (e.g. WWW)
• (e.g. Gnutella, Skype, Napster etc.,)
Twin Peaks:
Requirements and Architecture
General
Level
of
Detail
Requirements
Detailed
Independent
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”
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
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  rarely
done  documentation obsolete  Architectural
degradation