11. OO Design
Venkat Subramaniam
OOD-1
OO Development
• Requirements
• Use case analysis
• OO Analysis
– Models from the domain and application
• OO Design
– Mapping of model to implementation specifics
• OO Programming
– Implementing the design model in language
of choice using frameworks, libraries, etc.
Venkat Subramaniam
OOD-2
Is Design up-front?
• Heavy weight methodologies do up-front
design
• Light weight methodologies have not
eliminated design
– A misconception that agile eliminates design
– Read Martin Fowler’s “Is Design Dead?”
article
• Design is very essential
• Differentiate between strategic design
and tactical design
Venkat Subramaniam
OOD-3
Design Process
• Identify classes
• Determine their semantics
• Determine the relationship between
objects and classes
• How to do that?
Venkat Subramaniam
OOD-4
Identifying classes
• Nouns from problem statement are
potential classes, verbs indicate
relationships
– Unfortunately, this heavily skews towards
entity classes–those that hold information.
Hard to identify control (business logic and
activity) and boundary (user interface)
classes
• A better approach is to take this from
more detailed requirements specifications
like use case or user stories
Venkat Subramaniam
OOD-5
Models
• Static Model
– Tells us about classes and how they are related
– Most common model
– However, does not tell us what goes on, only how
they are related
• Dynamic Model
– Tells us how objects communicate and interact
– Collaboration diagrams, sequence diagrams
– Often may be useful to develop the static model as
well
– Useful to explain the working of specific parts of the
system
Venkat Subramaniam
OOD-6
Subsystem Design
• Organizing artifacts of design mode in more
manageable pieces
• Subsystem must be cohesive, loosely coupled
• Subsystem can represent a separation of
design concerns
• Have trace to analysis packages and/or
analysis classes
• Represent large grained components
• Represent reused software products by
wrapping
• Represent legacy systems by wrapping
• Service subsystems used a lower level
Venkat Subramaniam
OOD-7
Interface
• Specify operations provided by design
classes and subsystems
• Separates specification of functionality
from the actual implementation of it
– facilitates substitution of design classes or
subsystems
• May be outlined as stable interfaces
earlier in life cycle - becomes part of the
requirement for development teams
designing
the
subsystem
Venkat Subramaniam
OOD-8
Deployment Model
• Physical distribution of system
– how functionality is distributed among computational
nodes
• Each node represents a computational resource
– processor, simulation hardware device
• Nodes have means of communication
• Describes several different network
configurations
• Functionality of node defined by components
deployed on the node
• Deployment model manifests between software
architecture and system architecture
Venkat Subramaniam
OOD-9
Architectural Design
• Outline design and deployment models by
identifying
– Nodes and their network connections
– Subsystems and their interfaces
– Architecturally Significant Design classes
– Design mechanism to handle common
requirements
Venkat Subramaniam
OOD-10
Identifying Nodes and
Network Configurations
• Three-tier pattern for
– clients (User Interface) on one tier
– Database functionality on one tier
– Business/application logic on one tier
• Aspects:
– Nodes involved and capacities (power, size)
– Connection and protocols between nodes
– Characteristics of the connections and
protocols
– Need for any redundant processing capacity,
backup of data, fail-over modes, process
migration, etc.
Venkat Subramaniam
OOD-11
Identifying Subsystems and
Interfaces
Application-specific layer
Application-general layer
Middleware layer
System-software layer
Venkat Subramaniam
OOD-12
Architecturally Significant
Design Classes
• Must be deferred to class design activity
• Some may be identified early
• May be identified from the entity classes
in analysis model
• Active classes based on
– concurrency requirements may be identified
– distribution across nodes
– requirements like startup, termination,
deadlock avoidance, etc.
Venkat Subramaniam
OOD-13
Identifying Generic Design
Mechanism
• Common requirements are handled here
– Persistency
– Transparent Object Distribution
– Security
– Error detection and recovery
– Transaction Management
• Design classes manifest to provide any of
these common requirements
Venkat Subramaniam
OOD-14
Design a Use-Case
• Identify design classes needed to
perform flow of events
• Interacting design objects/subsystems
will participate in the use-case
realization
• Define requirements on interfaces and
design classes/subsystems
• Capture implementation requirements
for the use-case
Venkat Subramaniam
OOD-15
Identify Participating Design
Classes
• Study analysis classes that participate in
corresponding use-case realization
– Identify design classes that trace to those
analysis classes
• Identify design classes that realize special
requirements
• Any missing design class must be
documented and communicated to
architects and component engineers
Venkat Subramaniam
OOD-16
Describing Design Object
Interaction
• Sequence diagram to depict the interaction between
the design classes that participate in the flow of events
– use case is invoked by a message from an actor
instance to a design object
– Each design class should have at least one design
object participating in a sequence diagram
– Messages are sent between object lifelines. Message
name will become an operation
– Sequence is the primary focus - chronological order
of message transmissions between objects
– Use labels and flow of events - design to
complement
– Should handle all relationships of the use case
Venkat Subramaniam
OOD-17
Design a Class
• Design class that fulfills its role in usecase realizations and nonfunctional
requirements
– Operations
– Attributes
– Relationships
– Methods that realize its operations
– Imposed states
– Dependencies to any generic design
mechanisms
– Requirements relevant to its implementation
– Correct realization of any interface it provides
Venkat Subramaniam
OOD-18
Outlining the Design Class
• One design class may represent one
interface
• Designing boundary classes may depend
on specific interface technology in use
• Designing entity classes representing
persistent information depends on using
specific database technology
• Designing control classes needs to
consider
– distribution issues
– performance issues
–
transaction
issues
Venkat Subramaniam
OOD-19
Identifying Class Members
• Identifying Operations
–
–
–
–
Responsibilities of any traced analysis class
Special requirements
Based on the interfaces that must be provided
Based on use-case realization - design
• Identifying Attributes
–
–
–
–
–
Attributes of any traced analysis class considered
Restricted to types available in the language
Try to reuse existing ones
No sharing of attribute among classes - move
Use separate class diagram if many/complex
attributes in a class
Venkat Subramaniam
OOD-20
Identifying Class Relationships
• Identifying Associations and
Aggregations
– Sequence diagram provides insight into
this
– Instances of association may be used for
reference
– May group objects into aggregation for
messaging
– Number of relationships must be
minimized
– Refine association multiplicities, role
names, association classes, etc.
– Resolve navigation of association
Venkat Subramaniam
OOD-21
Describing States
• Design objects may be state controlled
– state determines behavior when message
received
• Statechart diagram may be used to
describe different state transitions of a
design object
• Statechart diagram becomes a valuable
input to the implementation of the design
class
Venkat Subramaniam
OOD-22