OOD OO Design

OOD-2 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.

OOD-3 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

OOD-4 Design Process Identify classes Determine their semantics Determine the relationship between objects and classes How to do that?

OOD-5 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

OOD-6 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

OOD-7 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

OOD-8 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

OOD-9 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

OOD-10 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

OOD-11 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.

OOD-12 Identifying Subsystems and Interfaces Application-specific layer Application-general layer

OOD-13 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.

OOD-14 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

OOD-15 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

OOD-16 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

OOD-17 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

OOD-18 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

OOD-19 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

OOD-20 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

OOD-21 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

OOD-22 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