CSIS 4850: Senior Project Spring 2009 Object-Oriented Design

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

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

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

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

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

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

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

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

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

10. Step 1: System Design (2) Partitioning the Analysis Model - In section 5 of the SDD (see slide #8), 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.

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

12. Step 2: Object Design (2) 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 (next slide). Follow the organization in section 6 of the SDD, using table format for each class.

13. Step 2: Object Design (3) 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.

14. Step 2: Object Design (4) 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 #8). Organize this section (sub-headings) similar to section 6.

15. Step 2: Object Design (5) - Create a specification class diagram: - 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) - 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)

16. Step 3: Object Collaboration In section 7 of the SDD (see slide #8), 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).

17. Milestone #3 Each team is required to submit a printout of the software design document (SDD) in the class.Due date is Thursday 3/4/2009 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 2009), 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 #8. You may reuse your SRS template with the sections outlined onslide #8. For sections 6 and 7 of the SDD (slide #8), you can take the tables from the SRS and expand them to include design details for each class method and attributes.

18. 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: To be decided Cover page: (project title, group number, names of groups members, class information, and submission date)