General Information

Course Home

News

Contacting Us

Syllabus

Reading List

HW, Exams, and Project

Homework

Term Project

Changes

Exercises

Past Exams

Course Policies

Grading Policy

Academic Honesty Policy

Reference

FAQs

Links

Computer Sc.

ISU

Com S 362 - Object-Oriented Analysis and Design (Fall 2007 Edition)

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, Aug 20

  Team Formation

  Deliverables: Team name, Team Member Names

• Fri, Aug 24

  Informal Project Proposals

  Deliverables: Short Problem Description - Please analyze the problem that your project is going to solve and send us a short project proposal.

• Wed, Aug 29

  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 send 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. Please send these slides to cs362@cs.iastate.edu with the subject line that reads "[team name here]-Deliverable-1".

• Fri, Aug 31

  Project Goals Finalized.

• Mon, Oct 1

  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 the lecture notes for Friday 9/21/07. Some examples are also available from here. The description should contain

  • Actors
  • List of Primary Actors
  • List of Secondary Actors
  • List of Offstage 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

  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. Examples are available from here. You do not need to draw separate use case diagrams for each use case scenario. You may group them together. 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, Oct 3, 2007, System Sequence Diagrams Due on Fri, Oct 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 is 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: 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

• Monday, Oct 29: CRC Cards

  Deliverables : Project - first iteration CRC cards due. The objective of this exercise is to understand the CRC process and responsibility-driven design 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.

• Wednesday, Oct 31

  Deliverables : Project - First Iteration Software Architecture 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

• Monday, Nov 5: 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: 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 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

• Friday, Nov 16: 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.

Friday, Nov 16: First Iteration Complete. Bring a demo to the class. Make all material about your project available at a wiki, provide the information to the rest of the class.

Friday, Nov 16 - Wednesday, Nov 28: Change Simulation Period

This is truly the test of the design efforts that went into your project. During this week, the rest of the class will point out reasonable changes to your application. Every individual will have around 10 days to study the documentation, design and implementation of every other team in the class (except their own) and to point out n requirement changes for each project, whereas 1<=n<=3. Each such change will briefly describe (a) change in requirement, (b) change in class and interaction diagram, (c) change in the implementation that will need to be carried out by the project team to respond to such change, and (d) an explanation of whether in that project, the implementation is modular enough to minimize the impact of that requirement change. A change that does not provide at least all four component will not be considered a reasonable change. Once submitted, you may not withdraw a change. Neither can you replace such change.

Such description is due by 5pm on Wednesday, November 28.

Changes are accepted on a first-come-first-serve basis. Similar changes will be attributed to the person, who submitted it first based on the time-stamp and the order in the mailbox. Therefore, submit your change at the earliest possible moment. If you end up coming up with the change at 4 AM in the morning, send an e-mail to cs362@cs.iastate.edu with the following subject, [your cs account name]-[project]-change-[Number of change]. Please include the description of the change that you came up with (see components above).

Throughout this week, I will update the web-page at (our earliest possible convenience) the URL to reflect changes that have already been documented in order to save you effort. We will put the change there irrespective of whether it has been accepted or rejected. These inputs will be anonymous. Only the TA, and the instructor will know the identity. Please also note in the change request, if the project's design, documentation, and implementation was hard-to-understand, unclear, and if there was poor traceability from requirements to design to implementation.

Each approved (i.e. sane, reasonable, and interesting change at the discretion of the instructor) will count for an extra credit. Note that the emphasis is not to significantly increase the work of the other team but to discover interesting flaws in their design that could be fixed, had they designed slightly differently. For each such change that is accepted by the instructor, an individual will receive one point (as extra credit). This extra credit is worth one point on your final grade e.g. if your final grade was 89, and you were getting the letter grade A-, this point will push your grade to A.

An individual MAY NOT have more than one change accepted per project. They may have changes accepted in all projects. So if the number of groups in the class is 5, maximum amount of changes accepted by a single person is 5, which is equal to enhancement in letter grade by one e.g. A- to A.

Wednesday, Nov 28 - Wednesday, Dec 5: Change Response Week

At the beginning of this week, instructor and the TA will select m changes from the list proposed during the previous week, where m is the number of members in the team and the team will be asked to enhance their project to accomodate that change. Please note that at this time, teams will not receive the insights on how to complete the change request from the original change-request submitter, only the short change description will be provided. There is no official deliverable for this week. You are strongly suggested to also finish the first draft of your report by the end of the week of Nov 26-30.

Wednesday, Nov 28 - Wednesday, Dec 5: Reflection period

During this time, each team will discuss and compile the change responses, i.e. how your design and implementation evolved to accomodate the changes that were assigned to you. There is no official deliverable for this time, this is just a suggested time to analyze your project's design and implementation in detail, which will reflect in your final report. It is also strongly suggested to polish your report the week during the period Nov 30 - Dec 4.

Wed, Dec 5: Final Project Report Due, 11:00 AM, Atanasoff B0029

This report will be evaluated to determine 25 points of your total grade. Please treat accordingly.

Formatting restrictions: You MUST use the ACM SIG proceedings template for formatting your final report. These templates are available for both Word and LaTeX. You are encouraged but not required to use LaTeX.

TEMPLATES: http://www.acm.org/sigs/publications/proceedings-templates

Page limits: Your final report may not contain more than 12 pages.

Your project report should be structured in the following fashion:

• An informal introduction to your system (1-2 pages)
• Use cases of your system
• Your first design space - design parameters, their range, constraints and interdependence between design parameters
• Your first design - snippets from class and interaction diagrams that serve to illustrate some important point, design structure matrix containing key components. Reflections on your design decisions and how they changed the design structure matrix.
• Description of your learning's when you started implementing your first design. What worked out during the implementation, what had to be changed.
• The final design of your system, again including your class and interaction diagrams and the design structure matrix containing key components. Highlight the change-requests that you implemented and description of changes that you had to make in the design and the implementation of the system to accomodate such changes.
• Reflection on the role of your first design on the change impact, what decisions you could have made differently that could have reduced the impact of the change-requests on your system.

The suggested outline for your presentation follows the report and it serves to make the points made in the report clearer.

Wed, Dec 5: Final Project Presentation, 11:00 AM - 12:00 PM, Atan B0029

Key objective of this presentation is to discuss the key aspects of your design and to highlight important parts of your report.

• 11:00 - 11:20: Team 1
• 11:20 - 11:40: Team 3
• 11:40 - 12:00: Team 4

Fri, Dec 7: Final Project Presentation, 11:00 AM - 11:50 AM, Atan B0029

• 11:00 - 11:20: Brief Q&A for Team 1,3, and 4
• 11:20 - 11:40: Team 5
• 11:40 - 12:00: Team 6