Object-Oriented Design CIS 375 Bruce R. Maxim UM-Dearborn 12/1/2018

OOA and OOD 12/1/2018

OO Design Layers Responsibility layer (highest layer) Message layer contains data structure detail and algorithmic detail for each object's attributes and operations Message layer defines system interfaces (internal and external) includes the collaborator communication details Class and object layer class hierarchy including object representations Subsystem layer (lowest level) contains representations of each subsystem and needed infrastructure to achieve customer's requirements 12/1/2018

OOD Issues - 1 Decomposability Composability Understandability part of design method that allows the designer to decompose the problem into subproblems Composability design method ensures that modules built for one project can reused in other projects Understandability component can be understood without having to examine other components 12/1/2018

OOD Issues - 2 Continuity Protection possible to isolate changes made in one module and restrict their propagation to other modules Protection architectural characteristic that reduces the propagation of side effects when errors occur 12/1/2018

Process Flow for OOD 12/1/2018

OOD Generic Steps - 1 Describe each subsystem and allocate its functions to processors and tasks Choose a design strategy for implementing data management interface support task management Design an appropriate system control mechanism 12/1/2018

OOD Generic Steps - 2 Perform object design by creating a procedural representation for each method and data structures for each attribute Perform message design based on the collaborations between objects and object-relationships Create a messaging model Review the design model and iterate as required 12/1/2018

Alternate Generic OOD Identify the data abstraction for each sub-system. Identify attributes for each data abstraction. Identify operations for each data abstraction. Identify communication between objects. Apply inheritance where appropriate. 12/1/2018

OOD (Booch-Abbot) - 1 Define problem. Develop process narrative for software realization of problem domain. Formalize strategy. Identify object & attributes. Identify operations which can be applied to objects. Establish interfaces by showing relationships between objects and operations. Resolve design details to allow implementation. 12/1/2018

OOD (Booch-Abbot) - 2 Recursively apply (2) & (3). Refine work done during OOA Represent data structures associated with object attributes. Represent procedural detail for each operation (method). 12/1/2018

Component Level Design Guidelines - 1 Components Establish naming conventions in during architectural modeling Architectural component names should have meaning to stakeholders Infrastructure component names should reflect implementation specific meanings Use of stereotypes may help identify the nature of components 12/1/2018

Component Level Design Guidelines - 2 Interfaces Use lollipop representation rather than formal UML box and arrow notation For consistency interfaces should flow from the left-hand side of the component box Show only the interfaces relevant to the component under construction 12/1/2018

Component Level Design Guidelines - 3 Dependencies For improved readability model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes) Component interdependencies should be represented by interfaces rather that component to component dependencies 12/1/2018

OO Component Design Principles - 1 Open-Closed Principle (OCP) class should be open for extension but closed for modification Liskov Substitution Principle (LSP) subclasses should be substitutable for their base classes Dependency Inversion Principle (DIP) depend on abstractions, do not depend on concretions 12/1/2018

OO Component Design Principles - 2 Interface Segregation Principle (ISP) many client specific interfaces are better than one general purpose interface Release Reuse Equivalency Principle (REP) the granule of reuse is the granule of release Common Closure Principle (CCP) classes that change together belong together Common Reuse Principle (CRP) Classes that can’t be used together should not be grouped together 12/1/2018

Object-Oriented Component Design Focuses on the elaboration of domain specific analysis classes and the definition of infrastructure classes Detailed description of class attributes, operations, and interfaces is required prior to beginning construction activities 12/1/2018

OO Component Design Undertake object oriented system requirements specification. Identify objects and their services. Establish interactions between objects services required & rendered Identify reusable components from previous designs. Implementation of low level objects. Introduce inheritance relationships superclass & subclass Class combination and generalization. 12/1/2018

Unified Modeling Approach to OOD System design UML (unified modeling language) design activity that focuses on software architecture and definition of subsystems Object design UML design activity that focuses on describing object and their interactions at a level of detail that will allow them to be implemented in some programming language 12/1/2018

OO System Design - 1 Partition the analysis model into subsystems subsystems should have well defined communication interfaces with few exceptions classes should collaborate within their subsystem keep number of subsystems small partition subsystem internally to reduce complexity Identify concurrency dictated by the problem Allocate subsystems to processors and tasks allocate each subsystem to an independent processor (or) allocate subsystems to same processor and provide concurrency support through operating system features 12/1/2018

OO System Design - 2 Develop user interface design Choose basic strategy for implementing data management management of data critical to the application itself creation of infrastructure for storage and retrieval of objects Identify global resources and control mechanisms to access them Design control mechanism for system (including task management) 12/1/2018

OO System Design - 3 Consider how subsystem boundary conditions should be handled list each request (contract) that can be made by subsystem collaborators for each contract and note the operations required to implement the responsibilities implied by the contract for each contract create a table with these entries: type, collaborators, class, operation, message format if subsystem interaction modes are complex create a subsystem-collaboration diagram Review and consider trade-offs 12/1/2018

OOA and OOD Models 12/1/2018

Object Design Process - 1 Object descriptions protocol description object interface specified by defining each message an object can receive and the operation triggered by message (or) implementation description shows implementation details for each operation implied a message passed to the object Designing algorithms and data structures algorithm categories: data manipulation, computation, monitors refinement of operations defined during OOA 12/1/2018

Object Design Process - 2 Design optimization review object-relationship model to ensure design leads to efficient resource utilization add redundancy where necessary revise attribute data structures and related operations to improve processing efficiency create attributes to save derived information and avoid recomputation Modularity is important aspect of object-oriented design quality (the PDL should support object definition) 12/1/2018

Modular Design Principles Linguistic modular units. (ADT’s should be supported) Few interfaces. Small interfaces (weak coupling). Explicit interfaces (use parameters – not common coupling). Information hiding. 12/1/2018

Specifying Operations Include anything needed to manipulate data elements Support inter-object communication 12/1/2018

Object Specification Attribute description: Instance connections: Attribute name. Attribute content. Attribute data (type/structure). External input to object. External output from object. Instance connections: (0:1, 1:1, 0:many, 1:many) Operation description: Operation name. Operation interface description. Operation processing description. Performance issues. Restriction and limitations. Message connections. 12/1/2018

Common OOD Errors Classes that make direct modifications to other classes. Classes with too much responsibility. Classes with no responsibility. Classes with unused responsibility . Misleading class names. Classes with unconnected responsibility. Inappropriate inheritance. Classes with repeated functionality. 12/1/2018

Design Pattern Specification Name Intent Design forces motivating the pattern Solution that mitigates these design forces Classes required to implement the solution Responsibilities and collaborations among the solution classes Implementation suggestions Source code examples or templates Cross-references to related design patterns 12/1/2018

Design Patterns in OOD Inheritance Composition makes use of an existing design pattern to create a template for a new subclass Composition assembling complex objects or subsystems out of selected design patterns using only interface information 12/1/2018