Software Architecture Document (SAD) sprint 3 - Pyxsys/SOEN390_19 GitHub Wiki
| Version # | Implemented By | Revision Date | Approved By | Approval Date | Reason |
|---|---|---|---|---|---|
| 1.0 | Nirmal Randhawa | 31/01/21 | Kaysse Rachid | 01/02/21 | Initial Version |
| 1.1 | Kaysse Rachid | 02/02/21 | Nirmal Randhawa | 02/02/21 | Diagrams (use case, model, component) |
| 1.2.1 | Nirmal Randhawa | 02/02/21 | Kaysse Rachid | 24/02/21 | Diagrams (model) |
| 1.2.2 | Kaysse Rachid | 02/02/21 | Nirmal Randhawa | 24/02/21 | Diagrams (component) |
| 1.3.1 | John Zeng | 11/03/21 | Kaysse Rachid | 17/03/21 | Diagrams (model, use-case) |
| 1.3.2 | Kaysse Rachid | 16/03/21 | John Zeng | 17/03/21 | Diagrams (sequence, component) |
The purpose of the SAD is to provide a detailed overview of the ERP system and how it is structured. Using this information, non-developers and developers could communicate and better understand the architecture of the system. The architecture could be best described using the 4+1 view. These views are the logical, process, development, physical and use case.
The software architecture document applies to the many decisions that will be made while building the system. All implementation details will have to reflect the architectural decisions decided upon beforehand, and denoted in this architecture document.
- React - Front-end JavaScript framework
- HTML - Hypertex Markup Language
- Express.js - Back-end JavaScript framework based on Node.js
- MongoDB - NoSQL database
- UML Unified Modeling Language
- SAD Software Architecture Document
[Kruchten]: The “4+1” view model of software architecture, Philippe Kruchten, November 1995, http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf
In order to fully document all the aspects of the architecture, the Software Architecture Document contains the following subsections.
Section 2: describes the use of each view
Section 3: describes the architectural goals and constraints of the system
Section 4: describes the most important use-case realizations
Section 5: describes the logical view of the system including interface and operation definitions.
Section 6: describes significant persistence elements.
Section 7: describes how the system will be deployed.
This document details the architecture using the views defined in the “4+1” model [Kruchten]. The views used to document the ERP system are:
The use case view captures system functionality that users experience. It is developed by analysts and provides the functionality of the system behavior as seen in the use case model.
The logical view provides the functional requirements of the system. An artifact used for the logical view is the design model which includes classes.
The data view provides the flow of data through the system along with a data model.
The deployment view shows the physical relationship between components. This is best represented with a UML diagram and a deployment model.
There are some key requirements and system constraints that have a significant bearing on the architecture. They are:
- The document must be designed in such a way as to provide useful insight and information to future developers and designers who consult the SAD.
- The architecture must be designed in such a way that it is easily serviceable.
- Design within the Node.js (Express.js) framework means compatibility with any device capable of running JavaScript. This is also a portability constraint.
The user is the primary actor that can call on login and register to fulfill his/her goals.
The database handles all information about storage and user authentication.
So far the User, Business (with Suppliers and Clients), Bike, BikePart, Schedule and Assembler model have been implemented. You can find below the UML diagram.
We updated the Models and Routes necessary for the Inventory feature on the following component diagram.
