Software Architecture Document (SAD) sprint 4 - Pyxsys/SOEN390_19 GitHub Wiki

Software Architecture Document (SAD)

Version 1.3.3


Version History

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)
1.4.1 John Zeng 07/04/21 Kaysse Rachid 07/04/21 Diagrams (model, use-case)
1.4.2 Kaysse Rachid 07/04/21 John Zeng 07/04/21 Diagrams (sequence, component)

1 INTRODUCTION

1.1 PURPOSE

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.

1.2 SCOPE

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.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

  • 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

1.4 REFERENCES

[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

1.5 OVERVIEW

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.

2 ARCHITECTURAL REPRESENTATION

This document details the architecture using the views defined in the “4+1” model [Kruchten]. The views used to document the ERP system are:

Use Case View

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.

Logical View

The logical view provides the functional requirements of the system. An artifact used for the logical view is the design model which includes classes.

Data View

The data view provides the flow of data through the system along with a data model.

Deployment View

The deployment view shows the physical relationship between components. This is best represented with a UML diagram and a deployment model.

3 ARCHITECTURAL GOALS AND CONSTRAINTS

There are some key requirements and system constraints that have a significant bearing on the architecture. They are:

  1. 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.
  2. The architecture must be designed in such a way that it is easily serviceable.
  3. Design within the Node.js (Express.js) framework means compatibility with any device capable of running JavaScript. This is also a portability constraint.

4 USE CASE VIEW

4.1 ACTORS

User

The user is the primary actor that can call on login and register to fulfill his/her goals.

MongoDB Database

The database handles all information about storage and user authentication.

4.2 USE CASE REALIZATIONS

4.2.1 Login and Registration

Use Case diagram for login and registration features

4.2.2 Bike assembly and Inventory

Use Case diagram for assemble bikes and add to inventory

sp 3 use case new

4.2.3 Accounting

Use Case diagram for accounting

390 sprint 4

5 LOGICAL VIEW

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. Accounting has been added to the sprint. sprint 4

6 DATA VIEW

6.1 Login and Registration

Sequence diagram for login and registration features

6.2 Bike Assembly

6.3 Accounting

7 DEPLOYMENT VIEW

Component diagram of the system

We updated the Models and Routes necessary for the Accounting feature on the following component diagram.

⚠️ **GitHub.com Fallback** ⚠️