Monopoly : Design Plan

Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises. — Daniel Jackson

This part is intended for your team to agree on the project's organization, priorities, and the primary architectures that will drive your design. Develop your ideas in enough detail to convincingly describe the public classes and public method signatures of your APIs, as well as how to use them, without writing any actual implementation code.

Submission

Create a folder within your doc folder in the team Gitlab repository, called plan, that contains all the files associated with your initial design plan. Your text documents must be completed using Gitlab's markdown format. Within this folder, create the following artifacts:

• Team Contract: Copy your Team Contract in a single file, CONTRACT.md, that describes your team work goals and responsibilities.
• Design: Write your planned design in a single file, DESIGN_PLAN.md, as described below. Note, this file can link to external image files (such as UML diagrams, planned GUI layouts, example game screens, etc.).
• User Interface Wireframe: Create a "runnable" wireframe of your GUI(s) that shows the basic interaction components (you do not have to draw out each separate Monopoly space). This is not intended to be a working Java program, instead you are encouraged to use a modern drag and drop layout tool for web or desktop apps (such as Adobe XD, Wix.com, or MockPlus) to create a rapid prototype that can be shared, critiqued, and updated easily.
• Use cases: In another file, USE_CASES.md, write at least 24 use cases for your project that describe specific features you expect to complete. Focus on those features you plan to complete during the first two sprints (i.e., the next two weeks — the project's highest priority features). Note, they can be similar to those given in the assignment specification, but should include more details based on your project's goals.
• APIs: Write any number of Java interfaces types in the folder doc/api, in appropriate packages, to represent your sub-teams' APIs. These must be Java code files that compile and contain extensive comments to explain the purpose of each interface and each method within the interface (the basic code can be generated directly from a UML diagram). Include any Exceptions you plan to throw because of errors that might occur within your methods. Note, this does not require that all of these types will remain as interfaces in the final implementation, just that the goal is for you to focus on each type's behavior and purpose.
• API Examples: Pick at least 6 use cases and provide example "implementations" of them, using only methods from your code interfaces. Note, these should be separate Java code files in the folder doc/usecases that compile and contain extensive comments explaining how you expect your different APIs to collaborate. Note, you can implement each feature either in a single class to show how the steps are connected "procedurally" or in separate classes that implement the necessary interfaces to show how the steps are "distributed" across the objects. In either case, you will likely need to create simple "mocked up" objects that implement your interfaces so you have something concrete to create, using new, and call methods on.
• Example data: Write any number of data files needed to represent one, simple, game. The goal of these example files (such as property files, XML files, and other resource files like HTML pages, images, or sounds) is to help the team agree to standard locations and formats for your shared data. Note, your example does not need to be exhaustive, just representative of the file's format.
• Project Plan: Write your project plan in a single file, PROJECT_PLAN.md, that describes the program components each team member plans to take primary and secondary responsibility for and a high-level plan of how the team will spend its time to complete the program. Specifically, each person should take responsibility for specific features and use cases they intend to work on during each Sprint. This requires the team to agree on the feature priorities and set a goal for what to show at the Midpoint Demo.

When you are satisfied with your design, push your results to the master branch to represent your submission for this part.

Specification

To represent your design at a reasonably high level and provide an organization to the plan document, break it into APIs rather than all the classes you can think of. In everything, focus on how to build a variety of games. Explain the key features in the concept that can vary, how you will support those features, and how you expect new variations to be written (i.e., what needs to be sub-classed, what accepts lambdas, what goes into resource files, and how communication will occur between your separate programs).

Note, the API agreed to between the sub-groups should not be changed after this document because it affects how the other's part might work. If it must be changed, the change and its reasons must be clearly described in a separate document, doc/API_CHANGES.md, included in the team's Gitlab repository.

Structure the plan document in the following sections:

• Introduction
  This section describes the problem your team is trying to solve by writing this program, the primary design goals of the project (i.e., where is it most flexible), and the primary architecture of the design (i.e., what is closed and what is open). Discuss the design at a high-level (i.e., without referencing specific classes, data structures, or code).
• Overview
  This section serves as a map of your design for other programmers to gain a general understanding of how and why the program was divided up, and how the individual parts work together to provide the desired functionality. Describe specific modules you intend to create, their purpose with regards to the program's functionality, and how they collaborate with each other, focusing specifically on each one's API. Include a picture of how the modules are related (these pictures can be hand drawn and scanned in, created with a standard drawing program, or screen shots from a UML design program). Discuss specific classes, methods, and data structures, but not individual lines of code.
• User Interface
  This section describes what components the user will interact with in your program (keep it simple to start) and how a game is represented to the designer and what support is provided to make it easy to create a game. Include design goals for the implementation of the UI that shows the kind of abstractions you plan to build on top of OpenJFX's standard components and how they can be flexibly exchanged within the GUI itself. Finally, describe any erroneous situations that are reported to the user (i.e., bad input data, empty data, etc.).
• Design Details
  This section describes each module introduced in the Overview in detail (as well as any other sub-modules that may be needed but are not significant to include in a high-level description of the program). Describe how each module handles specific features given in the assignment specification, what resources it might use, how it collaborates with other modules, and how each could be extended to include additional requirements (from the assignment specification or discussed by your team). Note, each sub-team should have its own API(s). Finally, justify the decision to create each module with respect to the design's key goals, principles, and abstractions.
• Example games
  Describe three example games in detail that differ significantly. Clearly identify how the functional differences in these games is supported by your design. Use these examples to help clarify the abstractions in your design.
  
• Design Considerations
  This section describes any issues which need to be addressed or resolved before attempting to devise a complete design solution. Include any design decisions that each sub-team discussed at length (include pros and cons from all sides of the discussion) as well as any ambiguities, assumptions, or dependencies regarding the program that impact the overall design.

Presentation

During lab, each team will be given 10 minutes to present their implementation and design plans with enough justification and detail to convince us your plan is sound. Each team should have a primary spokes-person, i.e., a master of ceremonies, but each team member should have a chance to present (if you cannot attend the presentation, you are expected to record a video about your part of the project and submit it separately).

Start by presenting your team's implementation plan:

• who is expected to work on which parts of the project
• what challenge feature(s) you are expecting to work on
• what features you expect to complete during each of the three Sprints
• demo your User Interface Wireframe to show how you expect to interact with the program

Then present your team's design plan, focusing on your APIs and their behavior instead of implementation decisions and class state:

• provide a CRC style overview of the project's parts: what is each component responsible for and what other components does it communicate with
• provide an overview of the project's design goals: what is expected to be flexible/open and what is fixed/closed
• describe two APIs in detail:
  • what service does it provide?
  • how does it provide for extension?
  • how does it support users (your team mates) to write readable, well design code?
• describe two use cases in detail that show off how to use one or more of the APIs you described
• describe one alternative design considered by the team and what trade-offs led to why it was not chosen

Prepare any material ahead of time for the presentation and make it available in the project repository, either as committed code, images, UML diagrams, or written text, in the form of Markdown, Javadoc or a wiki page on Gitlab. PowerPoint slides are discouraged because they are completely separate from project and unlikely to be maintained even if they are added to the repository, but here are some tools to convert Markdown to a slide style format.

Submission

Use GIT to push your team's code to the single, provided, monopoly_TEAM repository on the master branch as your team's submission of this part of the project. Note, any materials used in your presentation must also be completed with this submission.