PROJECT: MakerManager

Overview

MakerManager is an open-sourced, free desktop application created specifically for Users and Managers of MakerSpaces to manage 3-D printers and 3-D prints. It aims to help alleviate the hassle and stress related to sharing limited number of 3-D printers by providing an convenient way of organizing Prints, and optimising the usage of Printers. The app is driven mostly by Command Line Interface (CLI), and therefore optimised for makers who are more comfortable with typing.

MakerManager is based on AddressBook-Level 4, an application written by educators from the National Universtiy of Singapore to teach students the fundamentals of Software Engineering and Object Oriented Programming.

In summary, the MakerManager provides:

  • an overview of 3-D printers and PrintJobs within a MakerSpace

  • functionality to manage and monitor the progress of Prints in real-time

  • separate administrative privileges for Managers and normal Users through an Administrator login system.

  • automatic optimised allocation of prints to Machines for efficient use of the MakerSpace

To find out more about the Team behind MakerManager, please visit the About Us section!

Summary of contributions

  • Major enhancement: Reworked GUI display of the App #83

    • What it does: Displays a holistic view the current state of the MakerSpace, including highlighting the most recently modified Machines, dynamically displaying the progress of each print, as well as dynamically updating when there are changes to Jobs or Machines.

    • Justification: This feature is essential to the software, allowing MakerSpace users and managers to have a easily accessed overview of the MakerSpace that\ changes dynamically to reflect the status of Prints.

  • Major enhancement: added the ability to edit a Machine #47

    • What it does: Allows a user to edit the data fields of a Machine.

    • Justification: This feature is important because it allows Users to make changes to a Machine without affecting its Jobs, allowing the app to accommodate changes in the equipment in the makerspace.

  • Major enhancement: added commands for managing prints #151

    • What it does: allows users to manage prints in general, including moving, swapping, and shifting prints.

    • Justification: This feature is essential to the software, allowing MakerSpace users and managers to dynamically re-arrange and re-prioritise Jobs.

  • Minor enhancement: Non-Trivial reworking Model from storing Jobs and Machines in separate lists to storing Jobs within a List in each Machine. #126

  • Minor enhancement: Encapsulation of the LoggedIn state into the AdminSession object. #82

  • Minor enhancement: Implementation of a Timestamp object to handle time related operations. #83

  • Minor enhancement: Implemented automatic sorting of Jobs based on Status #151

  • Minor enhancement: Bug reports and fixes

  • Code contributed: Code Dashboard by Reposense

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.2 and v1.4(3 releases) on GitHub

    • Enhancements to existing features:

      • Integration of undo/redo with admin commands, to prevent non-admin users from modifying actions taken by the admin. #82

      • Integration of clear command to clear Machines and Jobs, but keep adminList for security. #126

    • Documentation:

      • Initialised Readme for MakerManager #3

      • ScreenShots and visual Aids: #153

    • Tools:

      • Integrated a new Github plugin (Coveralls) to the team repo to track coverage #3

      • Included Intellij CodeStyle Descriptor XML for convenient and standardised adherence to CodeStyle. #47

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Moving, Shifting and Swapping Jobs

Example: manageJob gears restart

  1. Delete a Print (Admin only)
    Deletes an existing print in the queue.
    Outcome: You will no longer see the specified print in the UI.

    Format: <manageJob> PRINT_NAME delete
    Example: manageJob gears delete

  2. Move a Print (Admin only)
    Moves an existing print that is not ONGOING to another machine. This command inserts the print at the bottom of the target Machine’s queue
    Outcome: Print is removed from its current Machine and added to the bottom of the queue of the target Machine.

    Prints are always displayed sorted in order of ONGOING, followed by QUEUED, then requestDeletion or CANCELLED or FINISHED. 
    Format: <manageJob> PRINT_NAME move MACHINE_NAME
    Example: manageJob gears move ultimaker

  3. Shifting a Print (Admin only)
    Shifts an existing print that is not ONGOING up or down in it’s queue.
    Valid shift options are:

    1. up

    2. down

      Prints are always displayed sorted in order of ONGOING, followed by QUEUED, then requestDeletion or CANCELLED or FINISHED. 
      Format: <manageJob> PRINT_NAME shift SHIFT_OPTION
      Example: manageJob chassis shift up

Finding and Listing Jobs

  • Finding Prints: Finds Jobs based on given keywords. You have to give at least 1 argument.
    Outcome: You will see only matching Jobs shown in the UI.

    After the filtered job list is displayed, use the listJobs command to return to the main menu.
    		 
    Format: findJob [JOB_NAME_1] [JOB_NAME_2]...
    Example: findJob gears chassis cup

  • Listing Prints
    Lists all prints.
    Outcome: All Prints will be visible in the UI.

    Format: listJobs
    Example: listJobs

Undo, Redo and History

  • Undoing and Redoing Commands
    The Maker Manager is remembers the sequence of commands entered, and provides the option for users to undo or redo actions should the need arises.

    The Commands help history findJob findMachine listJobs and listMachines do not count as commands for the purposes of undo and redo, and therefore trying to undo or redo these commands will instead undo or redo the most recent command that does not belong to the above list!

    1. Undo: This command reverts the state of Maker Manager to a state before the most recent successful command.

      Logout commands cannot be undone! 
      Format: undo

    2. Redo: This command reverts the state of Maker Manager to a state before the most recent successful undo command.

      Login commands cannot be redone! 
      Format: redo

    3. History: This command displays a list of commands entered by the user. 

      Format: history

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Managing Prints

This section describes how MakerManager manages the Jobs or Prints within the makerspace. More specifically, this section will detail the implementation of the manageJob command and its various sub-features.

The main command to manage and manipulate the Jobs in the makerManager is manageJob which has the following subcommands:

  • start - sets the status of a job to "ONGOING"

  • restart - sets the status of a job to "ONGOING", functionally the same as start, but used for restarting cancelled Jobs.

  • cancel - sets the status of a job to "CANCELLED"

  • remove - removes the Job from the Maker Manager

  • swap - Swaps the position of two Jobs

  • move - Moves a Job to another Machine

  • shift - Shift a Job’s order within a machine

The syntax for the commands are implemented in the following manner:

manageJob <Jobname> subcommand <operand2>

The subcommands start, restart and cancel do not make use of <operand2>, whereas the subcommands swap move and shift require require <operand2> to specify target Job for swap, Machine for move, and up/down for shift.

We have nested these commands as subcommands of manageJob to centralise the management of Jobs for users, therefore making it easier for users to manipulate Jobs.

Current Implementation

Our MakerManager keeps a record of all Jobs or Prints in a makerspace distributed across many machines. Within each Machine, Jobs are stored within a uniqueJobsList. The Machines are in turn stored in a UniqueMachineList in the VersionedAddressBook. The manipulation of the order and the content of the is facilitated by the ModelManager, which exposes the methods implemented by the VersionedAddressBook.

The diagram below shows the Jobs related section of the Model.

width:800

There are three main types of methods in VersionedAddressBook that concern the manipulation of Jobs:

  • Lookup Methods that return a handle to a Job or Machine:

    • findJob()

    • findMachine()

These Methods are used to obtain a handle a particular Job or Machine using each’s classes name property. All Jobs must have a unique name, and all Machines must also have a unique name. findJob() returns both a Job and its parent Machine as a JobMachineTuple, a utility class container object that contains a Job and a Machine.

  • Methods that mutate Jobs:

    • startJob()

    • cancelJob()

    • restartJob()

The sequence diagram for these methods are very similar, they follow a similar pathway and mutate the same property in Job. We will therefore only detail the sequence diagram of startJob().

The following diagram shows the sequence diagram for startJob().

width:800

  • Methods that mutates the UniqueJobList within a Machine:

    • swapJobs()

    • moveJob()

    • shiftJob()

Much like before, the sequence diagram for these methods are very similar, but will call methods from the UniqueJobsList as well.

Therefore, we can use the manageJob command to manipulate the prints Jobs to achieve a representation of the actual prints in the makerspace. This can be illustrated in the simple activity Diagram below.

The following diagram shows the generic activity diagram for a managing a Job.

width:800

The generic flow of a typical manageJob command is as follows:

  1. User enters a manageJob command

  2. The method associated with its subcommand will be called.

  3. Lookup methods findJob() / findMachine() will be called to obtain a handle on the target Job or Machine. If the these methods do not find the Job / Machine with the correct unique identifier (name), an Exception will be raised.

  4. If the handles are found, then the appropriate action will be taken.

Design Considerations

Aspect: Direct Mutation of Objects (Jobs and Machines)

  • Alternative 1 (current choice): mutate object’s data fields directly.

    • Pros: No new objects have to be created, therefore saving unnecessary computations since only the required data fields are changed.

    • Cons: Objects are mutable. Additional care needs to be taken in ensuring that these objects are accessed defensively by methods that might cause unintended mutation. Additionally, mutation events must be flagged and raised, since they mutations within the Objects are not observed by its container.

  • Alternative 2: Create a new instance with edited fields

    • Pros: Defensive. Objects will never mutate, therefore there is no chance of unintended or illegal mutation. Changes observed by Observable Containers since a new object is created/added.

    • Cons: More computationally intensive, commands will take longer to execute. Also less room for extension since performance is now inversely proportional to object size.