CSIS 4850: Senior Project Spring 2008 Object-Oriented Design

1. CSIS 4850: Senior Project Spring 2008 Object-Oriented Design

2. Part I Object-Oriented Design Summary of Class Handout

3. 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) Structured Design vs. OOD (1)

4. Structured Design 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 down to individual methods). - With OOD, system architecture has more to do with object collaboration than with control flow (as in Structured Design). - OOD methods provide better support for essential design concepts - abstraction, modularity, functional independence, information hiding, and reuse.

5. 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 The Big Picture

6. OOD Model OOA Model Classes Attributes Methods Relationships Behavior Objects Data Structures Algorithms Messaging Control Terminology Mapping

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

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

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

10. 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. See section 22.1.2 in the handout. Examples: - Booch method - Rumbaugh method - Jacobson method - Coad/Yourdon method - Wirfs/Brock method

11. Generic Components for OOD - Problem Domain Component: The subsystems that are responsible for implementing customer requirements directly. - Human Interaction Component: The subsystems that implement the user interface (this included reusable GUI subsystems). - Task Management Component: The subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems. - Data Management Component: The subsystem that is responsible for the storage and retrieval of objects.

12. OOA System Design Task Management Design Object Design Data Management Design Interface Design Unified Approach to OOD (1) Process flow:

13. Responsibilities Design OOD Process Object Design Message Design Class/Object Design System Design Subsystem Design Unified Approach to OOD (2)

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

15. 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), and - may include internal subsystems. (check use-cases) Note: Layering subsystems may be required (e.g., GUI layer, computing subsystems(s) layer, data management layer).

16. Step 1: Partition the Analysis Model (2) UML Class Diagram: During OOA, you created conceptual class diagrams - focus on classes that are apparent in the problem statement and of interest to the customer. - you didn’t worry about classes needed to implement the system! During OOD, you create specification class 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 details) - identify subsystems (using UML package notation)

17. Step 1: Partition the Analysis Model (3) Why 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.

18. Step 2: Identify Concurrency & Tasks Classes (subsystems) that are active at the same time (act on same events synchronously) are concurrent. How? - check object behavior diagram (statechart or activitydiagram) 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 processors considering performance requirements

19. 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 (see task template page 614) (Task name, description, priority, services (object operations), coordinated by (invoked by), input/output). - show task control object on the object behavior diagram (e.g., UML statechart).

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

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

22. 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 for each resource to coordinate access to that resource.

23. Step 7: Intersubsystem Communications Collaboration between subsystems is define by “contracts” or “subsystem interfaces” 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. (see figure 22.5 in the handout, page 617 ). - show collaborations (messages) on subsystem collaboration diagram (see figure 22.6 in the handout, page 618).

24. 2. Object Design Process Object design process is focused on providing detail design of the objects (attributes and methods) and their messages. Activities of object design process: 1 - Object description (message design) 2 - Algorithm design 3 - Data structure design

25. Step 1: Object Description Object description includes protocol (interface) description and implementation description. Protocol description is a listing of 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. Messages may be organized in categories (e.g., for SafeHome system: configuration, event, monitoring).

26. 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 Level of details should be sufficient enough so that it can be translated to syntax without additional help from the designer (designer’s knowledge of the language is essential!)

27. Step 3: Data Structure Design Defining data structures is done in conjunction with operation design since operation design may require knowledge of data structures that implement object attributes. Review of object design (algorithmic and data design) should be conducted to ensure efficient processing, ease of implementation, and efficient utilization of resources. Note: section 22.3.3 in the handout addresses program component design in relation to features of the implementation language (e.g., Ada packages).

28. Software Design Documentation RUP templates are more appropriate for capturing and expressing OOD details than those for structured systems. Note that section names and order may vary among documents. For this class, you may reuse your SRS template with the section outlines on the next slide. For sections 6 and 7 of the SDD (next slide), you can take the tables from your SRS and expand them to include design details for each class method and attribute. Make sure that you include a cover page (see slide #42)

29. 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.1.1 Object 1 6.1.2 Object 2 6.2 Objects in Subsystem 2 6.2.1 Object 1 6.2.2 Object 2 (use table format as in the SRS) 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 11. Supplementary Documentation Major Sections of OO SDD Other sections and subsection may be added as needed.

30. Links to Sample SDDs (1) 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 OO SDD Template: http://www-users.cs.umn.edu/~heimdahl/csci4081/guidelines/ DesignTemplate.htm Useful Links: http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/documents_page.htm SDD example: http://auss.abez.ca/SDD.html

31. Part II Here is what you need to do for your project...

32. OOD Model OOA Model Classes Attributes Methods Relationships Behavior Objects Data Structures Algorithms Messaging Control Utilize Unified Approach to OOD - Read Chapter 22 Handout - Design is answering the “How” question!

33. Step 1: System Design (1) Partitioning the Analysis Model - From your SRS description, identify potential subsystems. A subsystem is a self-contained and highly-independent groups of classes that define a main function of the system. - A subsystem has: - a well-define interface (check use-cases) - reasonable number of classes - classes that communicate with each others - possibly some internal subsystems. (check use-cases) Consider organizing subsystems in layers for better management and control (such as GUI layer, computing subsystems(s) layer, data management layer, etc…).

34. Step 1: System Design (2) Partitioning the Analysis Model - In section 5 of the SDD (see slide #29), provide a description for each subsystem and its interface. (separate table for each subsystem) - Provide a collaboration diagram to illustrate interactions among the subsystems (see figures 22.4 and 22.6 in the handout). Consider using UML package notation to represent subsystems. (see slide #23)

35. Step 2: Object Design (1) Here, focus on the detailed design of your objects (attributes and methods) and their messages. Apply the following activities of the design process (slide #24): 1 - Object description 2 - Algorithm design 3 - Data structure design Make sure to adhere to “information Hiding” and “functional independence” concepts as you design your objects.

36. Step 2: Object Design (2) - Create a specification class diagram: (see slide #16) Expand the class diagram in the SRS to include: - other classes and relationships needed for modeling the solution (those are classes of interest to you - the developer) - details of new classes (attributes and operations)

37. Step 2: Object Design (3) Object Description For each class in each subsystem, provide object description that includes interface description and implementation description. Interface description is a listing all message that an object of the class can respond to (i.e., all public methods it provides to its users). Implementation description is the internal (hidden) details of the operations that implement the interface methods. Follow the organization in section 6 of the SDD, using table format for each class.

38. Step 2: Object Design (4) Algorithm Design For each operation of the class, provide an algorithm description as a self-contained module. Consider dividing complex operations into separate smaller operations, such that each smaller operation performs a well-defined functions. Apply stepwise refinement, such that: - define operation interfaces (list of parameters if any) - fill-in operation body sections - refine body details as needed The level of details of your algorithmic description should be sufficient enough so that the implementer can translated it to source code without help from the designer.

39. Step 2: Object Design (5) Data Structure Design Define needed data structures of the class (if any) in conjunction with class operations. Document your data structures in section 8 of the SDD (see slide #29). Organize this section (sub-headings) similar to section 6.

40. Step 3: Object Collaboration In section 7 of the SDD (see slide #29), provide description of collaborations between objects of each subsystems. Provide a UML diagram similar to figures 22.4 and 22.6 in the handout to illustrate potential collaborations between objects of each subsystem. Notice that collaboration is required when a class cannot fulfill all of its responsibilities on its own (i.e., the class doesn’t have method(s) to manipulate its attributes). Most common collaborations arepart-ofand has-knowledge-of(see OOA slides).

41. Milestone #3 Each team is required to submit a printout of the software design document (SDD) in the class.Due Tuesday 2/12/2008 in class. Make sure that your submission has a cover page with the project title, group number, names of groups members, class information (CSIS 4850 – Spring 2008), and submission date. Feel free to modify any template you choose to fit your project design description as long as you include the sections outlined onslide #29. You may reuse your SRS template with the section outlines onslide #29. For sections 6 and 7 of the SDD (slide #29), you can take the tables from the SRS and expand them to include design details for each class method and attributes.

42. Final Project Submission The final submission is complete document that include the Project Plan, SRS document, SDD, Prototype or Implementation, and References as major sections. Add new section for updates made to each of those deliverables during project development, and a section for potential future functions of the system. Review the entire report for flow and consistency. Due Date: TBD Cover page: (project title, group number, names of groups members, class information, and submission date)