Mechanical Engineering Machine Scheduler

From Mindworks
Jump to navigation Jump to search
Mechanical Engineering Machine Scheduler
Sponsors University of Idaho
Team Name MErge
Duration Fall 2019 - Spring 2020
Faculty Adviser Bruce Bolden
Mentor Bruce Bolden
Client Michael Maughan
  • University of Idaho: Mechanical Engineering
Team Members
  • Delaney Fitzgerald
  • Blakely Frechette
  • Gabriel Hasenoerhel
  • Irven Perez

The goal of the project is, to create a website that will have an automated system for students and professors alike that improve upon the current whiteboard based system for scheduling and reserving machine times for mechanical engineering students.


Problem Definition[edit | edit source]

Background[edit | edit source]

As Mechanical Engineer students at the University of Idaho, there is currently not an efficient way to schedule machine shop times for specific machines, outside of the email-based system currently in use. As enrollment increases and the university grows the current system of requesting machine shop times with machines will be difficult to manage, and an improved system will help greatly in this regard. This system will also allow for automatic powering off and on of machines for their specific scheduled machine usage times.

Deliverables[edit | edit source]

Deliverables for our project consist of:

Client Specifications

These deliverables were accomplished in our final product, and can be seen on this website https://me-machineshop.herokuapp.com/ [This link will not work in the future]

Specifications[edit | edit source]

Our website uses multiple systems in order to communicate with the user and the database. Below is a basic outline of how these systems communicate with each other.

Client Specifications

Design Considerations[edit | edit source]

Frameworks:[edit | edit source]

React (Chosen Framework)[edit | edit source]

A JavaScript library – it is loosely referred to as a framework – for building user interfaces. React is one of the most commonly used web frameworks for frontend development. React’s virtual DOM makes the manipulation of the DOM faster than other frameworks due to JSX syntax. It can be used server side or client side. The component-based architecture allows for easy reuse of code throughout a project, allowing for easier team development.

   Pros: 
   + Reusable components 	
   + Scalable  
   + Big open source community 
   + Has many add-on components we can use from other developers – extensive libraries and extensions 
   + Can be for native or web apps (for later down the road) 
   Cons 
   - No clear documentation compared to other frameworks 
   - JSX – mixture of HTML and JavaScript. Could be large learning curve 
   - Fast paced development – may lead the website to needing more maintenance than wanted 
   - None of the team has used React before 

Potential Cost:
React is an open source – so there are no costs involved in using the framework.


Conclusions:
This framework appears to be one of the more durable and scalable of the frameworks for the project that it will be implemented for. This will allow for easier updates and maintenance of the site in the future, as well as during the development.

Angular[edit | edit source]

Angular is an open source JavaScript framework that can build web applications in JavaScript, HTML, and Typescript. From the initialization of an Angular app it provides built-in features for animation, HTTP service and materials. Angular uses more of a traditional approach of the MVC for the design than just a view design like React and Vue use.

   Pros 
   + Lots of documentation and tutorials available 	
   + TypeScript – much easier adaptation of JavaScript 
   + Has a lot of add-on components we can use from other developers – extensive libraries and extensions 
   + Some experience with team members with the framework 
   + Angular CLI 
   Cons 
   - Not as component-based as React – may cause merge conflicts in the team 
   - Considered complicated to learn 
   - May be a heavier-weight framework than we need 
   - Many different versions out – with the most recent not having as much documentation (most notably significant dependency changes)

Potential Cost:
Angular is an open source – so there are no costs involved in using the framework.


Conclusions:
This framework adds a lot more features right out of the box than other frameworks, leading to a potentially bloated project. While the feature built into the framework are useful, other frameworks allow for the same functionality without as much clutter.

Project Learning[edit | edit source]

Website Design: ( React Web Framework )[edit | edit source]

   Use Case:
   -  The React framework makes web development easier by initializing a starter app that comes with a built-in npm/yarn scripts, testing folders, and a base starter page to work from. This 
      allows for a more organized approach to starting the web page. 
   -  The component-based architecture allows for easy re-usability of code. 
   -  The large open-source community and libraries means that there will be more off the shelf technology available for use. 
   Setup: 
   The repository was initialized with the create-react-app started application for React. This app is aimed towards beginners and single page applications but allows for scaling for more 
   complicated websites later. 
Required Environment Setup: Node.js -- version: 12.11.1 Npm – version: 6.11.3 Yarn – version: 1.19.0 Brew – version: 2.1.11 Npx – version: 6.11.3
   Complications: 
   -  No current testing of the component has happened, so there are no concerns of complications yet.

Material-Ui Dashboard[edit | edit source]

Material-Ui Dashboard template is a mixture of an admin and dashboard template. It allows for more of a pre-made admin role organization in the website, dashboard navigation for ease of use for the website, and other add-ons that can be used including a login portal.

   Use Case: 
   -  The template would allow for already built-in admin, navigation, and login portal pages for the project. Allowing for more time to focus on other aspects of the project. 
   -  The design is simple and clean, allowing for less time for the team to design a clean design. 
   Complications: 
   -  Unfamiliarity of React and JavaScript now is holding us back from implementing the design at the moment, but later addition of the individual components is possible. 
   -  The template would need to be gutted of a lot of features that the project either doesn’t need or want to implement for the website. 

React-Big-Scheduler NPM:[edit | edit source]

React-big-scheduler NPMpackage is an immediately useful and easy to install component that could possibly be useful for multiple points in our project. The organization of adding resources and locking the time slots allows for more of a product that is useful for our project.

   Use Case: 
   -  This npm package allows for easy installation and use of the scheduler for the project. This component would also be easy for support teams down the road to update the calendar with 
      new releases of the component. 
   -  Simplistic look and design make the calendar easy to read, as well as easy for us to change the functionality of how a user can interact with it. 
   Complications: 
   -  No current testing of the component has happened, so there are no concerns of complications yet.


API Flow[edit | edit source]

APIFlowMErge.png
   Overview:    
   -  Mongoose manages create, read, update, and delete (CRUD) actions with model schema with database​
   -  Express creates a route and HTTP method for the frontend to utilize​
   -  Fronted can receive JavaScript Object Notation (JSON) objects or create, update, and delete data via HTTP method​






Security Design[edit | edit source]

SecurityDesignMErge.png
   Overview:    
   -  Express.js uses Passport.js ldap-auth package to validate user against University Active Directory​
   -  If valid Passport.js returns with the JavaScript Object Notation (JSON) object of the user and then checks the database for the user role​
   -  Database returns JSON object of the user the role​
   -  Passport.js assigns a JSON Web Token (JWT) token and returns a JSON object with the User and Token which is passed to the frontend via 
      API endpoint



Final Design[edit | edit source]

Our final product is a functional hosted website, in which its main features allow users to schedule times for equipment [See Figure 1.1], save scheduled information to our database, authenticate scheduled times with billing codes, and allows administrators to manage and add machines to this scheduler.

This design is a beta implementation for the Mechanical Engineering Machine Scheduler. More testing needs to take place for this website to be put into working production, which the testing will be addressed in this section, but you can reach the current website at, https://me-machineshop.herokuapp.com/ [This link will expire in the future].

Figure 1.1 - Reservation Functionality

Each user will have the ability to see upcoming and past reservations for machines [See Figure 1.2]. These are all stored on a database, and will keep records of this, which can be exported to CSV files for easier formatting outside of the website. As well as keep a personal backlog on your own machine.

Figure 1.2 - Reservation Backlog


There are multiple roles for users, which give each role a different set of features they can use on the website. These roles consist of undergraduate, graduate, and administrator roles. The final design gives each role the following features.

Undergraduate Role[edit | edit source]

Figure 2.1 - Undergraduate Features

The undergraduate student role consists of:

   -  Making reservations for various machines
   -  Checking upcoming and previous reservations from their account window

[See figure 2.1]

For an undergraduate to make a reservation, most machines will require the assistance of a graduate student. This is for safety reasons, and before requesting a graduate student the undergraduate student is expected to talk with them prior to this reservation online.

The next features most machines will require is a billing code. This is for wear and tear of machines, and will be used to help maintain the machines.



Graduate Role[edit | edit source]

Figure 2.2 - Graduate Features

The graduate student role consists of

   -  Making reservations for various machines
   -  Checking upcoming and previous reservations from their account window
   -  Future Implementation (Cancel upcoming reservations with undergraduate students)
   -  Future Implementation (Send and receive notifications to their email)

[See figure 2.2]

Graduate students have all the same features as undergraduate students, with more. The biggest difference implemented currently is when reserving time with a machine, a graduate student does not need have to be required to have another graduate student assisting them. Thus, graduate students only need a billing code in order to reserve a time slot for a machine.

One of the biggest issues with the graduate student role, is the required features they needed were changed multiple times. Graduate students, in earlier iterations, had to schedule their available times into the database, and then a undergraduate student when reserving a time slot would see all graduate students qualified for those machines and available at that time. This changed due to schedules changing constantly, so it is now a list of all graduate students to select from when an undergraduate wants to make a reservation. Then it is expected for undergraduate students to talk with graduate students before scheduling a time slot with a machine.

Administrator Role[edit | edit source]

Figure 2.3 - Administrator Features

The administrator role consists of

   -  Making reservations for various machines
   -  Checking upcoming and previous reservations from their account window
   -  Future Implementation (Cancel upcoming reservations with undergraduate students)
   -  Future Implementation (Send and receive notifications to their email)
   -  Manage all machines       (add, delete, edit)
   -  Manage all users          (delete, change role)
   -  Manage all billing codes  (add, delete, edit)
   -  MAnage all reservations   (add, delete, edit)

[See figure 2.3]

Administrators have the same abilities as graduate students, and undergraduate students with various other features. The main purpose of administrators is to manage all the information graduate and undergraduate students will be able to see. This will be managing machines, which administrators can add new machines, delete machines, and edit information of each machine. Such as machine name and ID number.

Administrators can also edit user roles and delete users. As each user is given an undergraduate role by default (for ease of not having to assign everyone to an undergraduate role every new semester for new students), administrators will have to go through and change roles to graduate students, and to other new administrators for this system.

Administrators will also be able to add, delete, and edit billing codes. When a student is reserving time with a machine most of them will require a billing code for use. As a reservation is made the students imputed billing code will verify it is indeed a real billing code with our database. All of these real billing codes will be manually added into the database by administrators.

Lastly, administrators will also be able to manage all reservations. They will be able to create new reservations, delete any reservation, or edit any reservation. This feature is here if for some reason a reservation must be deleted for reasons such as a student lost access to the machine shop, a reservation had to be moved ahead a few hours because of scheduling, or etc.




Suggestions To Future Teams[edit | edit source]

Future Testing[edit | edit source]

Figure 3.1 - Browser Support

As this project was a beta implementation with varying setbacks due to Covid-19 the amount of testing we were able to accomplish was set back. The major testing that needs to take place before this should be pushed into production is security. There was nearly no testing of security for our system, besides encrypting passwords to our database. As information is being pushed to our database by users through the reservation feature, there is sure to be some breach in security possible here. This also being said, our database should be used temporarily, as it is a free version and set up to show functionality with our website.

More focus groups is the next phase of testing that needs to be accomplished. As new features are implemented users will give feedback on if they are intuitive or not. This will help a lot later down the line, and all the focus groups we had were incredibly helpful.

More browser support and testing will also need to be worked on. [See figure 3.1 for current browser support and features] As the ability to reserve time on a smartphone is not possible, this could be added in the future. As well as, Safari does not like to have the page refreshed, which is being forced after a reservation. This sometimes results in an infinite loop only on Safari.

Future Features[edit | edit source]

The largest future feature that we agree needs to be the main priority is migrating this project to using Microsoft Azure. We tried many times throughout this project to get the University of Idaho to allow us to use Azure, but as we were a new project we were told no. As this project is in its beta implementation now, we highly encourage the next team to push for Azure support. This is because the University of Idaho is switching most of its websites to using the Azure service, and some websites are being shut down as they are not secure. Azure will ensure that this website will be more secure, will last longer, and will easily facilitate the University of Idaho login credentials. This will allow for features such as hooking up our website with students outlook calendars, allowing to easily email students for notifications about their reservation, and easily allow students to be able to log into the Machine Scheduler website without having to register every single user with our database. Which also brings us to back to our database is temporary and should be expanded upon with more security testing.

   Migration to Azure:
   -  Better security / authentication
   -  Long term support
   -  Facilitates University of Idaho's login credentials

Notifications for our website is another major feature that should be added. This would consist of notifications for:

   -  When a graduate student has a requested time scheduled from an undergraduate student
   -  Undergraduate will receive a notification if their reservation is canceled
   -  Students can receive a notification if the machine was damaged during their reservation time usage

Validation[edit | edit source]

As we approached our final product we had two focus groups to test our website. One focus group consisting of faculty and administrators. The second focus group consisted of graduate students, and undergraduate students. In purpose of both of these focus groups was the hear concerns and opinions on how our website was structured and worded. Through these tests one of the largest changes was brought up about how users will schedule time with a machine. It previously was through multiple pages to click through and windows. It was determined this was not user friendly, and could be simplified. Thus, we condensed the reservation function to only be on one page.

   Focus Group (Faculty and Administrators):
   -  Condense reservation process to one page
   -  Some machines will have billing codes and some will not
   -  Add a new role of blocked or view-only for students who abuse the system
   -  Admins can add notes to past reservations
   -  Some machines will have to have a graduate students while some do not
   Focus Group (Graduate and Undergraduate):
   -  Undergraduates must validate with graduate students for requested time
   -  Undergraduates and graduate students receive an email on the day of
   -  Graduate students can delete reservations, which will send a notification to undergrads.  There will also be a reason given to undergrads for the reason it was canceled.  Such 
      as "Have a meeting at that time, schedule for two hours later." etc.

Team Members[edit | edit source]

Delaney.jpg

Delaney Fitzgerald
Major: Computer Science
Hometown: Twin Falls, ID
Responsibility: Portfolio Manager
Email: fitz6051@vandals.uidaho.edu


Blakely.png

Blakely Frechette
Major: Computer Science
Hometown: Boise, ID
Responsibility: Client Communications
Email: frec4175@vandals.uidaho.edu


Gabriel.jpg

Gabriel Hasenoehrl
Major: Computer Science
Hometown: Lewiston, ID
Responsibility: Documentation Manager
Email: hase2378@vandals.uidaho.edu

MErgeIrv.jpg

Irven Perez
Major: Computer Science
Hometown: Boise, ID
Responsibility: Meeting Manager
Email: pere5381@vandals.uidaho.edu


Additional Documentation[edit | edit source]

Project Schedule
Our revised schedule that we kept to and accomplished.
RevisedScheduleMErge.png



Our first schedule. This was our projected time frame for completing this project, and we did not keep to this schedule.
MErgeSchedule.png

Meeting Minutes

File:TEAM MEETING 1.pdf
File:TEAM MEETING 2.pdf
File:TEAM MEETING 3.pdf
File:TEAM MEETING 4.pdf
File:TEAM MEETING 5.pdf
File:TEAM MEETING 6.pdf
File:TEAM MEETING 7.pdf
File:TEAM MEETING 8.pdf
File:TEAM MEETING 9.pdf
File:TEAM MEETING 10.pdf
File:TEAM MEETING 11.pdf
File:TEAM MEETING 12.pdf
File:TEAM MEETING 13.pdf
File:TEAM MEETING 14.pdf
File:TEAM MEETING 15.pdf
File:TEAM MEETING 16.pdf
File:TEAM MEETING 17.pdf
File:TEAM MEETING 18.pdf

Presentations

File:SnapshotMErge.pdf
File:SnapshotMErge2.pdf

Client Interview

File:CLIENT MEETING.pdf
File:TEAM CLIENT MEETING 2.pdf
File:TEAM ADVISOR MEETING.pdf
File:EngineeringReleaseReview.pdf