Computer Science 362: Object-Oriented Analysis and Design

Spring 07: Com S 362 - Object-Oriented Analysis and Design

Project

In this class, you will work as a team on a term project. The team will be formed on the first day of the class. This team will pick a project to work on for the rest of the semester. As a team, you can also consult with the instructor to decide on the scope of the project.

You will use an iterative software development process for this project. We will discuss this process in class and describe the difference between iterative and waterfall process. You will do two iterations of analysis, design, development, and verification for this project. The rough timeline for various deliverable are as follows:

Project Deliverables and Approximate Timeline

Analysis

Mon, Jan 08

Team Formation

Deliverables: Team name, Team Member Names
Fri, Jan 12

Informal Project Proposals

Deliverables: Short Problem Description - Please analyze the problem that your project is going to solve and present a short project proposal in class.
Wed, Jan 17

Project Prototypes

Deliverables: Project Prototype - The objective of this assignment is to analyze your customer requirements better. To do that your team will produce a model or prototype for the system. You as a team will bring an electronic copy of 2-3 PowerPoint slides that gives a rough idea of what your system is going to look like. You are also encouraged to solicit comments from your potential customers (extra credit).
Fri, Jan 19

Project Goals Finalized.
Wed, Jan 24

Deliverables: Project: First Iteration Use Cases, Use Case Diagrams Due - The objective of this assignment is to develop a first set of use case scenarios and corresponding use case diagrams for your project. For the purpose of this assignment, discuss and write at least five different scenarios per member for your project e.g. if your team has three members you are expected to submit at least 15 scenario. Each scenario should discuss a different use of your system. Be prepared to discuss and defend your scenarios in the class. Each team should submit one document containing all these use cases. You should also identify the person responsible for each scenario.

Use Case Format: You will use the casual format for writing use cases. This format is described in Section 6.6 in your textbook (Larman 05). An example is also presented on page 63 of the textbook (Larman 05). Additional examples are also available from here. The description should contain
- Actors
- Main Success Scenarios [Identify contributing member for each scenario]
- Alternate Scenarios [Identify contributing member for each scenario]
- Total number of scenarios >= 5 * Number of Members in Your Team
The tests described on page 87 of the Larman textbook will be helpful in determining the adequacy of your use cases and will be used to judge them.

Use Case Diagram Format: The objective of this part of the assignment is to develop the visual description of the use cases for the first iteration of your projects. An example use case diagram is shown on Page 90 of your Larman textbook. Additional examples are also available from here. You do not need to draw separate use case diagrams for each use case scenario. You may group them together as shown in the Figure 6.3. Both handwritten and typed formats are acceptable; however, if you are turning in a handwritten copy please write legibly. You should also identify the person responsible for each scenario.
Domain Models Due on Wed, Jan 31, 2007, System Sequence Diagrams Due on Mon, Feb 5, 2007

Deliverables : Project - First Iteration Domain Models and System Sequence Diagrams. The objective of this assignment is to develop an understanding of the input and output events related to the system that you are building in your project as well as to understand and model the domain of your system.

Domain Model Format: An example domain model is shown on Page 133, Figure 9.2 of your Larman textbook. Additional example is also available from here. Both handwritten and typed formats are acceptable; however, if you are turning in a handwritten copy please write legibly. There should be
- Conceptual classes, attributes, and associations for all actors from your use case submission.
- Multiplicity of associations should be specified.
- If there is a significant amount of information required for an entity in your domain, it should be modeled as a combination of conceptual class and description class.
- A team member should identify his/her contributions, by labeling conceptual classes that they came up with.
System Sequence Diagram Format: An example system sequence diagram is shown on Page 175, Figure 10.2 of your Larman textbook. Both handwritten and typed formats are acceptable; however, if you are turning in a handwritten copy please write legibly. There should be
- Separate system sequence diagrams for each use case scenario.
- Primary and secondary actors should be shown wherever necessary.
- Correspondence between the use case scenario and system sequence diagrams should be made explicit. For example, one can label the system sequence diagram as "Main Success Scenario", where "Main Success Scenario" is a use case scenario.
- All success and alternate scenarios should be present.
- A team member should identify his/her contributions, similar to the use case deliverables.

Architecture and High-Level Design

Fri, Feb 09 (tentative)

Deliverables : Project - First Iteration Software Architecture and Package Diagrams Due. The objective of this assignment is to analyze and document the software architecture that will be appropriate for your system. This assignment is designed to improve your understanding of software architectures. You should meet with your team members and discuss before you submit your team deliverables. It is NOT ACCEPTABLE to work on these deliverables individually and then combine them later without discussing it with your team members.

Expected Format: Both handwritten and typed formats are acceptable; however, if you are turning in a handwritten copy please write legibly. Your deliverable should contain:
- Part 1: An analysis of the following architectural styles with respect to the system under design. The analysis should include arguments to support whether an architectural style can or cannot be used. Your system may use a combination of more than one architectural style.
  - Pipe Filter Systems
  - Event Based Implicit Invocation
  - Layered Architecture
  - Repositories
  - Interpreters
  - Process Control
  - Client Server
  - Peer-to-Peer
  - Service-oriented Architecture
  - Plug-in Architecture
- Part 2: An architectural description of your system. This description should include:
  - Components in the System
  - Connectors (or interactions) between component
  - Patterns of interactions
  - Architectural Constraints on interactions
- A team member should identify his/her contributions, by labeling parts of the analysis and description that they came up with.

Detailed Object-Oriented Design

Wed, Mar 28: CRC Cards

Deliverables : Project - first iteration CRC cards due. The objective of this assignment is to understand the CRC process in the context of your project. You should meet with your team members and discuss before you submit your team deliverables. It is NOT ACCEPTABLE to work on these deliverables individually and then combine them later without discussing it with your team members.

Exercise: Download the CRC card template from the course website [PDF][WORD]. Conduct the CRC process as documented in Beck and Cunningham and in Butler’s CRC Tutorial. During the CRC process, consider all use case scenarios that you have developed for your project.

Expected Format of Deliverables: Both handwritten and typed formats are acceptable; however, if you are turning in a handwritten copy please write legibly. Your deliverable should contain:
- Part 1: Unfiltered class list
- Part 2: Filtered class list and the rationale for dropping the classes from the unfiltered class list.
- Part 3: Collaboration drawings
- Part 4: Final set of CRC cards
- Part 5: Contribution of team members: A team member should Identify his/her contributions, by labeling CRC cards, rationale, and collaboration drawings that they came up with.
Wed, Apr 4: Class diagram and interaction diagrams

Deliverables : Project - first iteration class diagrams and interaction diagrams due. The objective of this assignment is to take the output of your CRC process and describe it using UML class diagrams and interaction diagrams. You should meet with your team members and discuss before you submit your team deliverables. It is NOT ACCEPTABLE to work on these deliverables individually and then combine them later without discussing it with your team members.

Exercise: Read chapter 15 and 16 from the Larman’s textbook. Using the formats described in the textbook, create the class diagrams for each class that was generated as part of your CRC process. The responsibilities assigned to a class in the CRC process will determine the operations (i.e. methods) and attributes (i.e. fields) provided by a class in the class diagram. The collaborations between classes as determined during the CRC process will dictate the associations between classes in the class diagram and the interaction diagram. Please use ArgoUML to draw your class and interaction diagrams.

Expected Format of Deliverables: Please turn in a printed version of your diagrams drawn in ArgoUML. Please also turn in the ArgoUML (.zargo) files for your deliverables.
- Part 1: Class Diagram - Identify the corresponding class from the CRC process. If any class was added or removed in this process, give rationale. Describe (by either labeling the class diagram) or on a separate sheet, how different responsibilities that were assigned to the class in the CRC process translate to the operations and attributes provided by the class. Describe (again by either labeling the class diagram) or on a separate sheet, how collaboration between classes is modeled as associations in the class diagrams.
- Part 2: Interaction Diagram - Your interaction diagrams will be derived from two deliverables that you have produced previously: sequence diagrams (during analysis - See Section 15.1 in your Larman’s textbook) and collaboration drawings (during the CRC process). Your interaction diagrams should show how each use case scenario that you developed previously is being handled internally by the system. Specifically, the classes in the system that are involved, responsibilities that they are handling, order of the operations, etc. Describe (by labeling the interaction diagram), the correspondence between usecases, collaboration drawings and interaction diagrams.
- Part 3: Contribution of team members: A team member should identify his/her contributions, by labeling class diagrams and interaction diagrams that they contributed.

Object-Oriented Implementation

Wed, Apr 11: Implementation

The objective of this class is to study the design process in detail. Therefore, the implementation and verification part of the term project is intentionally kept short. This is not to downplay the importance of verification and validation activities. In real world, they still consume a significant portion of efforts in a software development life cycle and involve a number of phases such as unit testing, integration testing, system testing, stress testing, etc.

Thursday, Apr 12: First Iteration Complete, Brief Status Presentation, Team Meetings with Instructor

Wed, Apr 25: Final Project Report Due, 11:00 AM, Sweeney 1120

Your project report should be structured in the following fashion:

a. An informal introduction to your system (1-2 pages)
b. Use cases of your system (include use case diagrams)
c. Your first design - class and interaction diagrams
d. Description of your learning's when you started implementing your first design. (2-3 pages)
e. The final design of your system
f. Appendix: Annotated screen shots of your working system.

The suggested outline for your presentation follows:

Introduction, motivation.
Overview of the use cases of your system.
Discuss your first design.
Describe the learning's from the first iteration going from design to implementation.
Discuss the changes to your initial design that led to your final design.
Demo.
Q & A.

Wed, Apr 25: Final Project Presentation, 11:00 AM - 12:00 PM, Sweeney 1120

11:00 - 11:20: Team 1
11:20 - 11:40: Team 2
11:40 - 12:00: Team 3

Fri, Apr 27: Final Project Presentation, 11:00 AM - 11:50 AM, Sweeney 1120

11:00 - 11:20: Team 4
11:20 - 11:40: Team 5