P7: Final Report

P7: Final Report #

Deadline: Apr 04, 11:59pm Eastern Time

The final report should be a PDF document. Formatting requirements: page limit 8–12 pages (excluding acknowledgements and references); letter size; main text font size 11pt.

The document should include the following sections:

App Description #

suggested length: 1 page

Using one paragraph and a few screenshots, describe the app you built and its key features. This should be similar to a front page of the app in the app store.

Development Process #

suggested length: 1-2 page(s)

  • Document a changelist of the major changes to the project (functional requirements, non-functional requirements, use cases) compared to the proposal.

  • Summarize the tasks that were completed during each of the following periods:

    • start–W6 (by Iteration 1)
    • W7–W9 (by Iteration 2)
    • W10–W11 (by Iteration 3)
    • W12–W13 (by Final Presentation)

Requirements #

suggested length: 2-3 pages

  • List the functional requirements implemented in your app. For each functional requirement, please also point to the code locations (e.g., a package or class) where that requirement is implemented, and the tests for that requirement if you wrote any.
  • List the non-functional requirements achieved in your app. They should be specific enough to enable us to verify whether or not your app supports them in a measurable way.
  • Note: there is no limit on the number of functional/non-functional requirements, so please simply include all the items that are completed by the time of submitting this report.
    • The list here will be used to determine the utility, polish, and difficulty scaling factors of your project grade.
    • If the list deviates too much from the proposal (modulo the strength goals) without clear communication with the TA, that may affect the completeness scaling factor of your project grade.

Architecture #

suggested length: 2-3 pages

  • Identify 2 architectural styles used in your app. For each of them:
    • Point out the code locations corresponding to it.
    • Describe the subsystems/components and their interactions, with the help of appropriate architectural views (see more requirements in the next bullet point).
    • Discuss the rationale for using this architectural style, e.g.,
      • how it reduces coupling between components and improves cohesion within components,
      • how it can accommodate future requirement changes,
      • what non-functional requirements it can improve,
      • why it is used instead of alternative styles.
    • You can choose from the following list of architectural styles:
      • MVVM / MVC / MVP
      • Layered
      • Repository
      • Server-Client
      • Microservices
      • Serverless
      • Pipe-Filter
      • Implicit Invocation / Event-Driven / Publish-Subscribe
      • Process-Control
      • if you want to describe a style that is not in the list, seek approval from the instructor first.
  • Use at least 2 types of architectural views (i.e., UML diagrams) throughout your description.
    • Although 2 types is the minimum, you may want to target 2-3 diagrams for each architectural style for clarity.
    • You can choose from the following list of architectural views:
      • Component diagram
      • Deployment diagram
      • Sequence diagram
      • Communication diagram
      • State machine diagram
      • Activity diagram

Design #

suggested length: 2-3 pages

  • Draw a mega class diagram for all the key classes/packages in your app.

    • This can be based on a class diagram automatically generated by tools or plugins, but you may want to clean it up for better readability.
    • You can hide non-important attributes and operations like constructors, getters, setters, etc. You can also hide some non-important classes, or showing multiple classes as a package if appropriate.
    • Your class diagram should be clear and readable, to an extent that enables a junior programmer to understand the system and implement some subsets of it.

  • Identify 2 design patterns used in your app.

    • Point out the code locations corresponding to it.
    • Draw a class diagram for the part of your code using the design pattern.
    • Discuss the rationale for using this design pattern, e.g.,
      • how it reduces coupling between components and improves cohesion within components,
      • how it can accommodate future requirement changes,
      • what non-functional requirements it can improve,
      • why it is used instead of alternative patterns.
    • You can choose from the following list of design patterns:
      • Factory method
      • Abstract factory
      • Builder
      • Prototype
      • Object pool
      • Adapter
      • Composite
      • Decorator
      • Facade
      • Bridge
      • Flyweight
      • Proxy
      • Observer
      • Template method
      • Iterator
      • State
      • Chain of responsibility
      • Command
      • Mediator
      • Memento
      • some of the trivial patterns (e.g., Singleton, Strategy) are intentionally excluded from the list; please focus on the non-trivial and more interesting patterns.
      • if you want to describe a pattern that is not in the list, seek approval from the instructor first.

How to Submit #

Submit the PDF report on Learn. Your file should be named as p7-XX.pdf where XX is your team number.