Software Engineering

Iteration 2

Due on October 13th at 11:59 PM.

The master branches of your group’s repository and wiki will be pulled at that time and its contents will be graded. Be sure that all materials – documentation, code, build instructions, etc. – are available in that repository. If some materials cannot be placed in that repository, contact your instructor for instructions on how to compensate.

Please be sure to follow appropriate etiquette when interacting with your group.

Note that this iteration is due on the evening of the Friday that you leave for break, not on Sunday evening as usual.

Overview

In this iteration, you will create a design to satisfy your requirements. You will also begin experimenting with the technology stack your design proposes. Most of Iteration 2 is documentation just as with Iteratin 1. The only coding will be to become familiar with the technologies you are using so you are prepared for Iteration 3.

Design Documentation

During Iteration 2, you will complete the following tasks. As with Iteration 1, your wiki must be well organized. Create a page called Design from which all of this material is accessible and create new pages as necessary to keep things manageable. If you like, you can have a single starting page that links to both Requirements and Design and refer to that starting page in your README.md.

Note that, with the exception of the first step below, all of your documentation is expected to cover the core features of your application. You are not required to design for the extended features and should not spend significant time on them, as what you learn from the core feature implementation may influence your design for the extended features.

  1. Update your Vision Statement, Features List, and UI Sketches to reflect your improved understanding of your project at this point. Check that your core features and extended features lists are appropriate.

  2. Revise your use cases as needed. Just as with Iteration 1, these may be in the form of UML use case diagrams, UML use case syntax, or a sequence of storyboards. As with Iteration 1, please include only non-trivial use cases.

  3. Describe the architecture of your application. Give the full technology stack as well as any other APIs or frameworks you plan to incorporate.
    • Include an architecture overview paragraph to give your reader a summary of what you intend to do.
    • Include a visual diagram of your technology stack (unless your stack consists of fewer than three elements).
    • List the frameworks and libraries you plan to use. This should include the web server, database, and helper libraries such as YAML/JSON parsers, Facebook API libraries, Google Maps, etc.
    • Although your architecture may not be entirely complete – you may discover new needs as your project proceeds – you should make a best effort to identify every dependency you can.
  4. Provide UML class diagrams of your design. Your goal is to provide a guide for your future development. In these diagrams, put more emphasis on identifying appropriate methods and internal properties of the classes than you did in your domain analysis. Remember not to include noisy information (like getter/setter methods); the purpose of these diagrams is to communicate ideas, not code.
    • If you did a UML class diagram for your domain analysis, you can include it (or an expanded version of it) here. It’s probably not the only diagram you’ll want, though, since a domain analysis doesn’t address e.g. user customization, networking functionality, etc.
    • You don’t need to use every feature of UML class diagrams; the pictures should be informative but not noisy. Include methods and variables, but don’t include getter/setter methods, mundane private helper routines, or inconsequential private fields. Make sure to use multiplicity annotations (e.g. 0..1, *, etc.) and reference/inheritance arrows where appropriate.
    • You should consider developing a diagram for each major component of the system. In an MVC GUI application using a database, for example, you may wish to create one class diagram for your data model and an another for your application model. Having many small diagrams is better than having one large, incomprehensible diagram.
    • You probably won’t need a class diagram of the user interface of your application. Just make sure you have a complete storyboard for your user interface as well as a highlight of the major classes or views and a one-line description of each such class.
  5. Include at least two behavioral UML diagrams to describe your application. Potential candidates include:
    • Creating an activity diagram for one or more of your most complex use cases.
    • Creating a state diagram for a significant stateful portion of your system.
    • Creating a sequence diagram to express a low-level interaction between components in your system.
    • Feel free to include these diagrams where they would be most appropriate (e.g. an activity diagram on your Use Cases page) rather than on a page of their own, but make sure (a) they’re easy to find and (b) they convey more information than the class diagrams.

  6. Carefully document all interfaces internal to your application. If you are developing a web application, for instance, you should specify all of your endpoints (as in e.g. the Spotify API documentation). Android applications should specify major Activity classes and the information they expect to receive from their Intent objects. If you are developing an MVC desktop application, your model interface should be clearly specified (along with any major helper components, such as a persistence layer). In the event that some or all of your interface documentation is specified by auto-documentation, you may include links to that documentation rather than duplicating it on your wiki.

  7. Create a prototype of your technology stack. That is, create an application demonstrating that you know at least a little bit about how to use the technology you’ve chosen. Also, create a prototyping wiki page describing what your prototype accomplishes.
    • If your project is an Android application with significant ties to Facebook, for instance, you may assemble an Android prototype with the ability to log in via Facebook’s API and show the user’s full name.
    • A web application with a backing database might demonstrate the ability to share the contents of a single table using Hibernate and a single endpoint.
    • Desktop MVC applications will be held to a slightly higher prototyping standard since we’ve covered this process in class. You’ll need to show that you can make use of more than just JavaFX: demonstrate familiarity with the libraries you’re using!
    • This code should be in a subdirectory of your GitHub project (e.g. /prototype/), not the root. You probably won’t use this work as your main project and it’s best to keep it separate.
    • All members of the group must be able to run the prototype. This is likely to be easy if you’re all working on the CS network. If any group member is using a personal machine for development, that machine should be able to run the prototype as well.

The general function of this documentation is to describe how your software will accomplish what your Iteration 1 documentation said it would do. As with the previous iteration, this documentation should be complete enough that, in theory, you could give it to another group and they could complete the implementation without any major questions regarding e.g. your domain model or user interface flow.

Deliverables

You must store all of the above documents in your group’s repository wiki. You must have a single page called Design representing the design document (like a table of contents), but you are encouraged to separate each of the design steps above into distinct wiki pages both for organization and to avoid merge conflicts. If you have any documentation which cannot be stored in your wiki, contact your instructor to discuss the situation.

Iteration Review

You are also required to submit an iteration review which assesses the work you and your peers completed and whether things are going well for you in class. This review is private; its content will not be shared without your consent. Click here to submit your Iteration 2 review.

It is in your interest to provide honest feedback, even if that feedback isn’t the most generous or positive; if there’s a problem, your instructor needs to know!