Overview of Object-Oriented Design: Concepts, Components, and Process

1. Overview of Object-Oriented Design Highlights of OOD Concepts, Components, and Process

2. Responsibilities Design Component design a i n t e r f c e d e s i g n Message Design a r c h i t e c t u r a l d e s i g n Class/Object Design d a t a d e s i g n Subsystem Design Design Patterns (domain Objects) SD vs. OOD - 1

3. SD vs. OOD - 2 - With OO development, think objects (data and operations) rather than functional procedures (during analysis and design). - OOD focuses more on the collaboration among objects than data flow between components of the system. - OOD exhibits different levels of modularity (subsystem modules to method). - With OOD, system architecture has more to do with object collaboration than with control flow (as in SD). - OOD methods provide better support for essential design concepts - abstraction, modularity, functional independence, information hiding, and reuse.

4. OO Analysis OO Design Implementation OO Testing Deployment OO Analysis OO Design Implementation OO Testing Deployment Object Relationship Modeling Class Design Sub-System Design Class Modeling Object Behavior Modeling Responsibilities Design Message Design OOA and OOD

5. Attributes Operations Collaborators Responsibilities Design Object Relatio- nships Class Model Message Design Use Cases Class/Object Design Object Behavior Model Design Patterns (domain Objects) Subsystem Design Mapping OOA and OOD

6. Design Model Analysis Model Classes Attributes Methods Relationships Behavior Objects Data Structures Algorithms Messaging Control OOA and OOD Terminology Another mapping view:

7. OOD Layers - 1 - Design Patterns: Deals with reusable designs (domain objects). (repeated (reusable) classes and objects that found to solve specific design problems, e.g., user login and authentication, integrated circuit, car air-condition system, shopping cart, etc…) - Subsystem Design: Deals with subsystems that form the overall system architecture. (detailed design of self-contained and highly-independent groups of classes that define specific requirements (major functions of the system))

8. OOD Layers - 2 - Class/Object Design: Deals with relationships among classes that define each subsystem. (detailed design of inheritance hierarchies for subsystems) - Message Design: Deals with internal and external interface design. (detailed design of messages exchanged among objects and interactions between system objects and external entities) - Responsibilities Design: Deals with data structures and algorithm design. (internal detailed design of each class - its attributes and operations)

9. OOD Methods OOD methods vary in their processes, presentation forms (diagrams), notations, and terminologies. However, they all produce similar results. A design method must support building modular architectures with fewer interfaces, small interfaces (less data passed around), and explicit interfaces (well-defined interfaces), and information hiding. Examples: - Booch method - Rumbaugh method - Jacobson method - Coad/Yourdon method - Wirfs/Brock method

10. Generic Steps of OOD 1. Identify subsystems and allocate to processors and tasks 2. Design data management, interface support, and task management 3. Design system control mechanism 4. Perform object design (operations and data structures) 5. Perform message design (collaboration among objects) 6. Create message model (behavior modeling) 7. Review the design and refine as needed (iterative process)

11. Responsibilities Design OOD Process Object Design Message Design Class/Object Design System Design Subsystem Design Unified Approach to OOD

12. System Design Process Activities of system design process: Step 1. Partition the analysis model into subsystems. Step 2. Identify concurrency (dictated by the problem) and allocate subsystems to processors and tasks. Step 3. Design an appropriate control mechanism for task management. Step 4. Develop a design for the user interface. Step 5. Choose a basic strategy for implementing data management. Step 6. Identify global resources and the control mechanisms required to access them. Step 7. Consider how boundary conditions should be handled (intersubsystem communications). Step 8. Review the design and consider trade-offs.

13. Step 1: Partition the Analysis Model - 1 Identify potential subsystems (self-contained and highly independent groups of classes that define specific functions) How? A subsystem - has a well-define interface (check use-cases) - has reasonable number of classes - has classes that communicate with each others only (not with outside classes) (check object behaviour diagram) - may include internal subsystems (check use-cases) Note: Layering design of subsystems may be required (e.g., GUI layer, computing subsystems(s) layer, data management layer).

14. Step 1: Partition the Analysis Model - 2 UML Class Diagram: During OOA, create conceptual class diagrams - focus on classes that are apparent in the problem statement and of interest to the customer. - don’t worry about classes needed to implement the system During OOD, create specificationclass diagrams - add classes and relationships needed for modeling the solution (classes of interest to the developer) - add more details into individual classes (attributes and operations) - identify subsystems and use package notation.

15. Step 1: Partition the Analysis Model - 3 Class diagrams: - used to document classes and show static structure of classes/subsystems. - don’t show how classes interact (messages). Collaboration and sequence diagrams show that (dynamic view). - describe association, generalization, and aggregation relationships among classes. - show class details (attributes and operations). - show class interface. - show individual object instances within the class structure. - used throughout the development cycle.

16. Step 2: Identify Concurrency & Tasks Class (subsystems) that are active at the same time (act on the same events synchronously) are considered concurrent. How? - check object behavior diagram (state machine or activity diagram) for parallel threads of control (i.e., an object sends a message to another and continues processing) - consider each control thread as a task - allocate tasks to HW processors considering performance requirements (or same processor using OS mutli-threading capability)

17. Step 3: Task Management Objects Task initiation and management are modeled by control objects. How? - determine task characteristics such as its initiation (event- or clock-driven), priority for resources, and criticality (should continue to operate with low resources). - define control object (attributes/operations) required to coordinate the task with others. (Task name, description, priority, services (object operations), coordinated by (invoked by), input/output). - show task control object on the object collaboration (behavior) diagrams.

18. Step 4: User Interface Design User interface is often modeled as a subsystem. How? - check use-cases to identify system users (actors) - from use-cases, derive command hierarchy to define menu components for each actor and its usage scenario. - Refine the command hierarchy until all uses-cases can be navigated via the command hierarchy. - Note that most interface classes are reused from libraries or system environment.

19. Step 5: Data Management Data management is accomplished by attributes and operations defined to manipulate, store, and retrieve data objects (from system database) How? - include such attributes and operations within classes that manipulate data objects. - or, design special class(es) to host such attributes and operations (i.e., to save and load data objects as needed by the system).

20. Step 6: Resource Management Subsystems may compete for resources (HW and data resources). Resource allocation control may be a required part of the design. Often, resource management is performed by the OS and DBMS. How? - If resources are part of the application, the designer my define an object (guardian or gatekeeper object) for each resource to coordinate access to that resource.

21. Step 7: Intersubsystem Communications Collaboration between subsystems is define by “contracts” or “subsystem interfaces” and is implemented by message(s) among the subsystems. How? - for each contract (interaction), define its type, collaborating subsystems(s), classes(s) within the subsystem(s), operation(s) within the class(es), and the message format. - show collaborations (messages) on subsystem collaboration diagrams.

22. Object Design Process Object design process is focused on providing detailed design of the objects (attributes and methods) and their messages. Component-level design principles (Ch-11, textbook) are application to object design. Activities of object design process: 1 - Object description (message design) 2 - Algorithm design 3 - Data structure design Program Design Language (PDL) is used to express object design (PDLs come in different flavors).

23. Step 1: Object Description Object description includes protocol (interface) description and implementation description. Protocol description is a listing all message that the object can respond to (services it provides). This is important for clients (users) of the object. Implementation description provides internal (hidden) details of operations that implement the protocol. PDL is used to express object description (protocol and implementation). Messages may be organized in categories (e.g., for SafeHome system: configuration, event, monitoring).

24. Step 2: Algorithm Design Each operations of the class is expressed as an algorithm and is implemented as a self-contained module. A complex operation may be divided into separate operations, such that each operation performs a well-defined task. Stepwise refinement may be applied: - define operation interfaces (list of parameters if any) - fill-in operation body sections - refine body details as needed Key Points: The level of details should be sufficient enough so that it can be translated to target PL syntax without additional help from the designer (designer’s knowledge of the PL is essential!)

25. Step 3: Data Structure Design Defining data structures is done in conjunctions with operation design since operation design may require knowledge of data structures that implement object attributes. Optimization of objects design (algorithmic and data design) should be conducted to ensure efficient processing, ease of implementation, and efficient utilization of resources.

26. Software Design Documentation For structured design, IEEE 1016-1993 standard (next slide) sections 1 through 5 describe the software architecture and section 6 describes detailed design. For OOD, section 6 can be replaced with detailed description of classes (see the following 29) RUP templates are more appropriate for capturing and expressing OOD details. Note section names and order may vary among documents.

27. Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 2. References 3. Decomposition description 3.1 Module decomposition 3.1.1 Module 1 description 3.1.2 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.2.1 Data entry 1 description 3.2.2 data entry 2 description 4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description 6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 details 6.1.2 Module 2 details 6.2 Module detailed design 6.2.1 Data entry 1 details 6.2.2 Data entry 2 details IEEE 1016-1987 Standard for SDD

28. Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 2. Glossary 3. Use Cases 4. Design Overview 4.1 Introduction 4.2 System Architecture 4.3 System Interfaces 4.4 Constraints and Assumptions 5. System Object Model (System Design) 5.1 Introduction 5.2 Subsystems 5.3 Subsystem Interfaces • 6. Object Descriptions (Object Design) • 6.1 Objects in Subsystem 1 • 6.2 Objects in Subsystem 2 • . . . . • 6.n Sequence Diagrams • 7. Object collaboration (Process View) • 7.1 Objects in Subsystem 1 • 7.2 Objects in Subsystem 2 • 8. Data design • 9. Dynamic Model • 9.1 State Diagrams • 9.1.1 State Diagram 1 • 9.1.2 State Diagram 2 • 10. Non-functional requirements • Supplementary Documentation RUP Major Sections of OO SDD Other sections and subsections may be added as needed.

29. Useful Links RUP Templates (complete set): http://jdbv.sourceforge.net/RUP.html Software Architecture document sample: http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/SDP/Architecture_guidelines.htm Software Architecture template sample: http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/documents/ ArchitectureDesignTemplate_Word.dot Useful Links: http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/documents_page.htm SDD example: http://auss.abez.ca/SDD.html

30. End of Overview