CS 48, Spring 2018

Draft Project Instructions

The object of this assignment is to complete at least one full development iteration, including a working software system and associated analysis and design documentation.

Domain Analysis

Perform a domain analysis for the current development iteration, and prepare the following artifacts:

  1. Begin a static class diagram - similar to this Figure 12.9 from the Larman text. Include domain classes only at this stage. Use proper UML notation. Class attributes should be included now, but attribute types are optional. You will complete this diagram during the design phase.
  2. System sequence diagrams - like this Figure 9.1 from Larman (but omit the annotations). A separate diagram should be prepared for each use case in this development cycle. It is up to you whether you want to include use case text with the diagram like this Figure 9.5 example from the Larman text.

System Design

Design a system to satisfy the current iteration requirements, and prepare/improve the following design artifacts:

  1. Expanded and upgraded static class diagram(s) - with design features as appropriate. First be sure to allocate your classes to meaningful sub-systems (a.k.a. packages).
    • Add operations, showing parameters and types, and return types if not void.
    • Show attribute types (e.g., score : double) now too.
    • Remember to add any new classes introduced during system design.
    • Exclude details of packages not to be created this quarter by your group - use the UML notation for a package to show each such item as a single box in your diagrams. For example, if you use any wxWidgets components, then just show a package named wxWidgets in your diagram.
  2. At least two interaction diagrams. See several example diagrams and explanations about interaction diagram notation in Larman's Chapter 15.
    • Ideally you would create one interaction diagram for each system event. For this assignment we want you to choose at least two interesting events - i.e., ones that involve multiple steps and objects.
    • If a diagram cannot fit neatly on a page, consider splitting it into two diagrams.
  3. One or more state diagram(s) like this Figure 29.3 from the Larman text. Focus on external system events in the context of use cases.

Implementation, Testing and User Instructions
  1. Implement the system for the current development iteration - i.e., write the necessary source code, and get the system working well enough to demonstrate all of its current functionality.
    • Each C++ class (except nested ones) must be defined in a separate .h file, and implemented in a separate .cpp file, unless the class is so simple that all functions are defined inline.
    • All .h files must include proper comments for every non-private member. Describe parameters and return values, pre- and post-conditions and any exceptions thrown by member functions.
    • If you are using a different OOP language than C++, then follow that language's conventions, but still keep separate classes in separate files.
  2. Fully test the system. Do both unit and integration testing, and test overall functionality. (Note - any "test drivers" and "stubs" used for unit testing must not be included with the system that you turn in.)
  3. Prepare a README file (README.txt or README.md) as follows.
    • List precise instructions to build and execute your system. Be sure to tell us about necessary libraries, and about any operating system or other restrictions.
    • Include any necessary details about where to store data files too.
    • Also include any other special information we need to know in order to test your system properly (a list of known bugs, for example).
    • Finally include brief guidance about how to use the system (e.g., how to play the game).

Deliverables

System

The system includes source code, data, and the read-me file.

All of this must be in your github repo. Specify the link and branch name (if not master) and source root directory in the document you turn into the TAs. The source root directory/folder must include the following:

  1. Source code in github repo in subdirectories that correspond to your system's packages. We must be able to build the project using a makefile or script. Include the steps to do so in the README file.
  2. All necessary data files must be turned in too - any data, graphics, sound, or other files (like libraries) necessary to compile and/or execute the system.
  3. Include the README file in the root of this file structure. This file must include the exact steps (cut/past-able) to build and run your project. (AND TEST THEM ON A CLEAN CLONE TO MAKE SURE THEY WORK.)

Documentation

Text must be typewritten. Hand-drawn diagrams are okay, but we suggest you learn and use a UML drawing tool instead. Assemble artifacts into a single PDF document in the following order:

  1. Cover page with group ID, project title, and project team (member names).
  2. Analysis and design artifacts in this order: system sequence diagrams, static class diagram, interaction diagrams, and state diagram(s).
  3. Glossary (begun in the Requirements Analysis) - be sure to add names and descriptions of all classes, class attributes, associations, system events/operations, packages, methods, and any other important terms. Also remember to revise or delete any existing faulty glossary entries if necessary.

Due Friday, May 18, before 6:30 pm

Turn in the PDF document to Gauchospace. Your github repo must be ready at that time too.

Updated April 10, 2018 by C. Michael Costanzo, with thanks to Prof. Chandra Krintz (W'2018 instructor) for helpful additions/modifications.

CS 48 homepage