ObjectOriented Design CIS 375 Bruce R Maxim UMDearborn
Object-Oriented Design CIS 375 Bruce R. Maxim UM-Dearborn 12/5/2020 1
OOA and OOD 12/5/2020 2
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 12/5/2020 3
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 12/5/2020 4
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 12/5/2020 5
Process Flow for OOD 12/5/2020 6
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/5/2020 7
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 objectrelationships • Create a messaging model • Review the design model and iterate as required 12/5/2020 8
Alternate Generic OOD • Identify the data abstraction for each subsystem. • Identify attributes for each data abstraction. • Identify operations for each data abstraction. • Identify communication between objects. • Apply inheritance where appropriate. 12/5/2020 9
OOD (Booch-Abbot) - 1 1. Define problem. 2. Develop process narrative for software realization of problem domain. 3. Formalize strategy. a. Identify object & attributes. b. Identify operations which can be applied to objects. c. Establish interfaces by showing relationships between objects and operations. d. Resolve design details to allow implementation. 12/5/2020 10
OOD (Booch-Abbot) - 2 4. Recursively apply (2) & (3). 5. Refine work done during OOA 6. Represent data structures associated with object attributes. 7. Represent procedural detail for each operation (method). 12/5/2020 11
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/5/2020 12
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/5/2020 13
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/5/2020 14
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/5/2020 15
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/5/2020 16
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/5/2020 17
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/5/2020 18
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/5/2020 19
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/5/2020 20
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/5/2020 21
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/5/2020 22
OOA and OOD Models 12/5/2020 23
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/5/2020 24
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 objectoriented design quality (the PDL should support object definition) 12/5/2020 25
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/5/2020 26
Specifying Operations • Include anything needed to manipulate data elements • Support inter-object communication 12/5/2020 27
Object Specification • 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) 12/5/2020 • Operation description: Operation name. Operation interface description. Operation processing description. Performance issues. Restriction and limitations. • Message connections. 28
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/5/2020 29
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/5/2020 30
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 12/5/2020 31
- Slides: 31