D2. Design Document

Platform Selection

Note: This the continuation of a previous project. Therefore, there are some decisions that we have decided to continue using and that we do not have a choice to change.

  • Frontend – Python GUI Library, tkinter
    • Pros: Very easy to use, most compatible with Python, nothing extra to download, simple programming, time efficient, it was already being used by the previous group.
    • Cons: Not the most aesthetically pleasing, doesn’t have much functionality or reactive nature.
    • Alternatives: React.js, Vue.js, Angular.
    • Reasoning: we ended up choosing Python GUI is because it would take too much time to code up an entire new frontend, it is not in the interest of our client that we do that. All the fixes and new functionality can be done from the current framework.
  • Backend – Python
    • Pros: One of the most well-known and used languages, easy to understand (low-level and syntax), compatible with a wide range of libraries / frameworks.
    • Cons: No con in particular about Python, just maybe losing out on the opportunity to use a more Object-Oriented programming language that could potentially have simplicity benefits.
    • Alternatives: Java.
    • Reasoning: apart from Python being the language all our team is most proficient on, previous teams started working on this project in Python too so we will be continuing to add to this project with the same language.
  • Hardware Control – Studio5000
    • This piece of our platform selection was one that we could not modify since it is the program that controls the motors. Our software connects to it and makes the corresponding calls to Studio5000 in order to run the hardware.
  • Database Management – MongoDB (implemented with Python)
    • Pros: no schema creation, high performance speed, flexibility.
    • Cons: can be difficult to set up, more complicated to use than relational SQL databases.
    • Alternatives: PostgresSQL, SQLlite.
    • Reasoning: the final and most important reason to consider is that most probably another team or other people will build up on top of our code. Therefore, having a NoSQL database (non-relational) will allow for flexibility. Migrating databases to new schemas can become very complicated and take a lot of time; therefore, MongoDB will future users just add fields and modify data easily.
  • Testing – PyTest
    • Pros: simplicity (expressive syntax), efficient, provides functions like fixtures and parametrized testing for discovery, execution and reporting.
    • Cons: setting up can be complicated, limited documentation.
    • Alternatives: unittest, nose2, doctest.
    • Reasoning: even though it can be a challenging library to use, it is a good opportunity for us to learn it. Also, our project will not require particularly complicated testing. Finally, it is compatible with MongoDB, which is basically the most essential part of our testing.

Architecture Diagram