This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2020 Jan-Apr
  • Full Timeline
  • Week 1 [from Mon Jan 13]
  • Week 2 [from Wed Jan 15 noon]
  • Week 3 [from Wed Jan 22 noon]
  • Week 4 [from Wed Jan 29 noon]
  • Week 5 [from Wed Feb 5 noon]
  • Week 6 [from Wed Feb 12 noon]
  • Week 7 [from Wed Feb 19 noon]
  • Week 8 [from Wed Mar 4 noon]
  • Week 9 [from Wed Mar 11 noon]
  • Week 10 [from Wed Mar 18 noon]
  • Week 11 [from Wed Mar 25 noon]
  • Week 12 [from Wed Apr 1 noon]
  • Week 13 [from Wed Apr 8 noon]
  • Textbook
  • Admin Info
  • Report Bugs
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • repl.it link
  • Java Coding Standard
  • Forum Activities Dashboard
  • Participation Dashboard

  •  Individual Project (iP):
  • Individual Project Info
  • Duke Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Week 6 [from Wed Feb 12 noon] - Project

    iP:

    1. Add Increments as parallel branches: Level-6, Level-7
    2. Add Increment: A-Jar

    tP:

    1. Conceptualize v1.0
    2. Draft the UG midnight before the tutorial
    3. Refine the product design

    iP

    1 Add Increments as parallel branches: Level-6, Level-7

    • Practice using parallel git branches, as explained below:
      1. First, do Level-6 in a branch named branch-Level-6, but do not merge it.
      2. Then, go back to the master branch and implement Level-7 in a separate branch named branch-Level-7.
      3. Now, go back to the master branch and merge the two branches one after the other.
        If there are merge conflicts, you'll have to resolve them first.
      4. As before, tag the commit (in the master branch, after merging) that achieves the respective deliverable, and push to your fork.
    • As before, Merge without a fast-forward so that git creates a separate commit for the merge.
      Remember to push the branches to your fork so that the bot can detect them.
      Advanced git users: do not delete the branch after merging.
    Level-6: Delete

    Level 6. Delete

    Add support for deleting tasks from the list.

    Example:

    list
    ____________________________________________________________
    Here are the tasks in your list:
    1.[T][✓] read book
    2.[D][✓] return book (by: June 6th)
    3.[E][✗] project meeting (at: Aug 6th 2-4pm)
    4.[T][✓] join sports club
    5.[T][✗] borrow book
    ____________________________________________________________

    delete 3
    ____________________________________________________________
    Noted. I've removed this task:
    [E][✗] project meeting (at: Aug 6th 2-4pm)
    Now you have 4 tasks in the list.
    ____________________________________________________________

    When implementing this feature, you are also recommended to implement the following extension:

    A-Collections

         Use Java Collections classes

    Use Java Collections classes for storing data. For example, you can use an ArrayList<Task> to store the tasks.

    Level-7: Save

    Level 7. Save

    Save the tasks in the hard disk automatically whenever the task list changes. Load the data from the hard disk when Duke starts up. You may hard-code the file name and location e.g., [project_root]/data/duke.txt

    The format of the file is up to you. Example:

    T | 1 | read book
    D | 0 | return book | June 6th
    E | 0 | project meeting | Aug 6th 2-4pm
    T | 1 | join sports club

    If you use file paths in your code,

    • remember to use relative paths rather than absolute paths such as C:\data. If not, your app can cause unpredictable results when used in another computer.
    • remember to specify file paths in an OS-independent way. If not, your app might not work when used on a different OS.

    Your code must handle the case where the file doesn't exist at the start. Reason: when someone else takes your Duke and runs it for the first time, the required file might not exist in their computer. Similarly, if you expect the data file to be in as specific folder (e.g., ./data/), you must also handle the 'folder does not exist yet' case.

    2 Add Increment: A-Jar

    • In case this increment does not require any code changes, you may tag the commit at which this was achieved as A-Jar (even if that commit has another tag already).
    • Upload the jar file to your fork as explained in the panel below. You can ignore the point about using Gradle.
    A-Jar: Create a JAR File

    A-Jar

         Package the App as a JAR file

    Package the app as an executable JAR file so that it can be distributed easily.

    You can assume the user will run the jar file in the following way only:

    • Copy the jar file into an empty folder
    • Open a command window in that folder
    • Run the command java -jar {filename}.jar e.g., java -jar Duke.jar (i.e., run the command in the same folder as the jar file)

    Do not commit the JAR file created. Instead, you can make the JAR file available in the following manner.

    • Go to your fork on GitHub and create a new release.
    • In the page where you fill the details of th release,
      • give an appropriate version number e.g., v0.1
      • attach the JAR file where it says Attach binaries by dropping them ....

    If you are using Gradle for your project, refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to create a jar file using Gradle.

    A-Gradle

         Automate project builds using Gradle

    Use Gradle to automate some of the build tasks of the project. Refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to set up Gradle for your project.

    • Minimal: Set up gradle so that you can build and run Duke using gradle.
    • Recommended: Set up gradle to run unit tests.
    • Stretch Goal: Use gradle to automate more things in your project.



    tP: Product Concept

    1 Conceptualize v1.0

    • Based on your user story selected previously, conceptualize the product in terms of how it will look like at v1.0. Suggestion: this can be in the form of a feature list.
     

    Requirements → Specifying Requirements → Feature Lists →

    What

    Feature list: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.

    A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):

    1. Basic play – Single player play.
    2. Difficulty levels
      • Medium-levels
      • Advanced levels
    3. Versus play – Two players can play against each other.
    4. Timer – Additional fixed time restriction on the player.
    5. ...

    2 Draft the UG midnight before the tutorial

    • Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v1.0.
      • We recommend that you follow the AB3 User Guide in terms of structure and format.
      • As this is a very rough draft and the final version will be in a different format altogether (i.e., in markdown format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
      • Do try to come up with concrete command syntax for the CLI commands that you will deliver at v1.0.
      • Include only features that will be delivered in v1.0.
      • Submission: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., CS2113T-W09-1.pdf, and upload to LumiNUS.

    Recommended: Divide documentation work (in the User Guide and the Developer Guide) among team members equally; preferably based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.

    Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.

    4. Project Grading: Documentation [ 5 10 marks]

    Evaluates: your contribution to project documents

    Method: Evaluated in two steps.

    • Step 1: Evaluate the whole UG and DG. This is evaluated by peers who tested your product, and tutors.

    Q Compared to AddressBoook-Level3 (AB3), the overall quality of the UG you evaluated is,
    Evaluate based on fit-for-purpose, from the perspective of a target user. For reference, the AB3 UG is here.

    Q Compared to AB3, the overall quality of the DG you evaluated is,
    Evaluate based on fit-for-purpose from the perspective of a new team member trying to understand the product's internal design by reading the DG. For reference, the AB3 DG is here.

    • Step 2: Evaluate how much of that effort can be attributed to you. This is evaluated by team members, and tutors.

    Q The team members' contribution to the User Guide is,

    Q The team members' contribution to the Developer Guide is,

    • In addition, UG and DG bugs you received in the PE will be considered for grading this component.

    These are considered UG bugs (if they hinder the reader):

    Use of visuals

    • Not enough visuals e.g., screenshots/diagrams
    • The visuals are not well integrated to the explanation
    • The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

    Use of examples:

    • Not enough or too many examples e.g., sample inputs/outputs

    Explanations:

    • The explanation is too brief or unnecessarily long.
    • The information is hard to understand for the target audience. e.g., using terms the reader might not know

    Neatness/Correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.

    These are considered DG bugs (if they hinder the reader):

    These are considered UG bugs (if they hinder the reader):

    Use of visuals

    • Not enough visuals e.g., screenshots/diagrams
    • The visuals are not well integrated to the explanation
    • The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

    Use of examples:

    • Not enough or too many examples e.g., sample inputs/outputs

    Explanations:

    • The explanation is too brief or unnecessarily long.
    • The information is hard to understand for the target audience. e.g., using terms the reader might not know

    Neatness/Correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.

    UML diagrams:

    • Notation incorrect or not compliant with the notation covered in the module.
    • Some other type of diagram used when a UML diagram would have worked just as well.
    • The diagram used is not suitable for the purpose it is used.
    • The diagram is too complicated.

    Code snippets:

    • Excessive use of code e.g., a large chunk of code is cited when a smaller extract of would have sufficed.

    Problems in User Stories. Examples:

    • Incorrect format
    • All three parts are not present
    • Benefit does not match the function
    • Important user stories missing

    Problems in NFRs. Examples:

    • Not really a Non-Functional Requirement
    • Not well-defined (i.e., hard to decide when it has been met)
    • Not reasonably achievable
    • Highly relevant NFRs missing

    Problems in Glossary. Examples:

    • Unnecessary terms included
    • Important terms missing

    3 Refine the product design

    • Review the UG to ensure the features written by each member fit together to form a cohesive product. Note that cohesiveness of the product can affect the grading of the product design aspect.

    1. Project Grading: Product Design [/ 5 marks]

    Evaluates: how well your features fit together to form a cohesive product (not how many features or how big the features are) and how well does it match the target user

    Evaluated by:

    • tutors (based on product demo and user guide)
    • peers from other teams (based on peer testing and user guide)

    Q Quality of the product design,
    Evaluate based on the User Guide and the actual product behavior.

    Criterion Unable to judge Low Medium High
    target user not specified clearly specified and narrowed down appropriately
    value proposition not specified The value to target user is low. App is not worth using Some small group of target users might find the app worth using Most of the target users are likely to find the app worth using
    optimized for target user Not enough focus for CLI users Mostly CLI-based, but cumbersome to use most of the time feels like a fast typist can be more productive with the app, compared to an equivalent GUI app without a CLI

    In addition, feature flaws reported in the PE will be considered when grading this aspect.

    These are considered feature flaws:
    The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
    Hard-to-test features
    Features that don't fit well with the product
    Features that are not optimized enough for fast-typists or target users

    Note that 'product design' or 'functionality' are not critical learning outcomes of the tP. Therefore, the bar you need to reach to get full 5 marks will be quite low. For example, the Medium level in the rubric given in the panel above should be enough to achieve full marks. Similarly, only cases of excessive 'feature flaw' bugs will affect the score.