OOD-1 11. OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis Models from the domain and application OO Design Mapping of model

OOD-1Venkat SubramaniamVenkat Subramaniam

11. OO Design


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.


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


Design Process• Identify classes

• Determine their semantics

• Determine the relationship between objects and classes

• How to do that?


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


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


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


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


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


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


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.


Identifying Subsystems and Interfaces

Application-specific layerApplication-specific layer

Application-general layerApplication-general layer

Middleware layerMiddleware layer

System-software layerSystem-software layer


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.


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


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


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


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


Design a Class• Design class that fulfills its role in use-case

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


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


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


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

• Identifying Generalization– Used based on the semantics defined by language


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

Documents

OOD-1 11. OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis Models from the domain and application OO Design Mapping of model