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

2. OOA and OOD

3. OO Design Layers • Responsibility layer (highest 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

4. OOD Issues - 1 • Decomposability • 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

5. OOD Issues - 2 • Continuity • 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

6. Process Flow for OOD

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

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

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

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

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

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

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

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

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

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

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

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

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

21. 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)

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

23. OOA and OOD Models

24. 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

25. 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)

26. 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.

27. Include anything needed to manipulate data elements Support inter-object communication Specifying Operations

28. Attribute description: 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. Object Specification

29. 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.

30. 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

31. Design Patterns in OOD • Inheritance • 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