CSIS 4850: CS Senior Project Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented...

CSIS 4850: CS Senior Project – Spring 2009

CSIS 4850: Senior Project

Spring 2009

Object-Oriented Design


Structured Design vs. OOD (1)

Design Patterns (domain Objects)

ResponsibilitiesDesign

Subsystem Design

Class/Object Design

MessageDesign

interfacedesign

architecturaldesign

datadesign

Component design


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.


The Big Picture

OO AnalysisOO DesignImplementationOO TestingDeployment

ObjectRelationship

ModelingClass

Modeling

ObjectBehaviorModeling

OO AnalysisOO DesignImplementationOO TestingDeployment

Class Design

Sub-SystemDesign

MessageDesign



Mapping OOA to OOD

Design Patterns(domain Objects)


Subsystem Design

Class/Object Design

MessageDesign

UseCases

Object Behavior Model

Class Model

Object Relatio-nships

AttributesOperations

Collaborators


Unified Approach to OOD (1)


Subsystem Design

Class/Object Design

MessageDesign

OOD Process

Object Design

System Design


Unified Approach to OOD (2)

- Read Chapter 22 Handout- Design is answering the “How” question!

Classes

Attributes

Methods

Relationships

Behavior

OOA Model

Objects

Data Structures

Algorithms

Messaging

Control

OOD Model


Major Sections of OO SDDOther sections and subsection may be added as needed.Table of Contents1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References2. Glossary3. Use Cases4. Design Overview 4.1 Introduction 4.2 System Architecture 4.3 System Interfaces 4.4 Constraints and Assumptions5. 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 28. Data design

9. Dynamic Model 9.1 State Diagrams 9.1.1 State Diagram 1 9.1.2 State Diagram 210. Non-functional requirements11. Supplementary Documentation


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


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.


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 description2 - Algorithm design3 - Data structure design

Make sure to adhere to “information Hiding” and “functional independence” concepts as you design your objects.


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.


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 besufficient enough so that the implementer can translated it tosource code without help from the designer.


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.


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)


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 are part-of and has-knowledge-of (see OOA slides).


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 on slide #8. You may reuse your SRS template with the sections outlined on slide #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.


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)

CSIS 4850: CS Senior Project Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented...

Documents

Transcript of CSIS 4850: CS Senior Project Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented...