SDS
- Introduction Document Goals
- Main Product Features & Capabilities
- Related Documentation
- UML Modeling
- Persistence
- Non-functional Requirements
- Initial Test Plan
This document will outline in detail the software architecture and design for the Project 'Hands' web application. This document will provide several views of the system's design in order to facilitate communication and understanding of the system. It intends to capture and convey the significant architectural and design decisions that have been made for this project.
- Persistent Database - One of the primary requirements of the client is the ability to store & manipulate data.
- Risk answered: The risk of losing information for one. the Database will always keep persistant data.
- Chat system - Another primary requirement made by the client is the ability to send instant messages between project members and the ability to pin important information
- Risk answered: The risk of volunteers missing important information because they use Whatsapp and the messages get pushed to the top when new messages come in. Our chat system will pin information to the top and will open different room for each renovation.
- Sign-up and Log-In system - The web app is intended for the use of only the organization's volunteers, thus requires user verification
- Risk answered: the risk of divulging sensitive information to people who shouldnt get access to it. The sign-up system is there for extra layer of protection.
- Data Export - for archiving and auditing purposes the web app will support data export into an external document
- Risk answered: 2 risks. first, the risk of having volunteers who are of old age and might have problems with new technology, we will export the data to a file that can be printed to ease their use of the system. Second, the risk of a network failure which will render the records inaccessible until the network is back up. having physical files as an offline solution.
- Dashboard - present all the user's relevant data in a concise and easy to understand manner.
- Risk answered: the risk of making the user experience too cumbersome. the volunteers are not "professionals" so they simply want to get the needed information as fast as possible. The dashboard will be centralized and easy to understand.
- [Risk Management] (../wiki/Risk-Management)
- User Manual
- SDS Review Summary
- The Deployment Diagram Purpose: to show what hardware components ("nodes") exist, what software components ("artifacts") run on each node, and how the different pieces are connected.
- This Diagram is meant to show how the Client can only interact with the interfaces of the web application, and the Chat interface will pull and push information from its own DB on the server. the Renovation Project info will pull and push from Renovation DB. The data export system will receive information from the Renovation Project Info (and not directly from the database). The User Verification will interact with its own Volunteer Database.
- Web Application - the site itself which the Client (user) will be able to interact. including all the logic and GUI.
- Server - the Database server from an external site. e.g. Microsoft Azure. the inner DB are simply collections in Mongo.
- We have decided to go in that approach for the simplicity and fast response of this design. User will interact with site and site with Database (Pushing and Pulling data).
- The Risk it handles: Data Security. The user will only be able to access what the site introduce to him. the Database is separate and protected.
- CRC Diagram Purpose: It focuses us, as designers, on the essentials of the class and prevents us from getting into its details and implementation at a time when such detail is probably counter-productive. It also discourages giving the class too many responsibilities.
- Dashboard is the main hub for the volunteer to access the relevant info for him. thus the dashboard will be responsible for Displaying user info, User Assigned Renovations and will allow him to sign up for new Renovations.
- The Chat system will be minimal by only being responsible for Sending and Receiving messages and also pinning important information.
- The Database will basically be responsible for giving and receiving new Data to its seperate small databases (collections, since its in MongoDB)
- Renovation Info will be responsible for showing the relevant info for a specific project and will show a chat box for the relevant room.
- Class Diagram Purpose: a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects.
- a single Database will always exist. it can communicate with more than 1 chat room (since each renovation has its own chat room). it can send information to more than one renovationInfo pages since more than one will be open at any given time. It will also send information to the Volunteer Dashboard, which is per Volunteer and thus has more than one at any given time.
- State Diagram Purpose: a type of diagram used to describe the behavior of systems.
- This is a simple state diagram showing how a Team Manager or a Volunteer (simply differ in permissions) will interact with the system using a Dashboard page to make the user experience easy and smooth.
Click image to view in full size
- Sequence Diagram Purpose: an interaction diagram that shows how processes operate with one another and in what order.
- This sequence diagram is showing the way a volunteer will register to the site and get the approval it needs to start using the site (upper part of diagram). once the Register process is done and approved - he can log in to the site (bottom part of diagram)
#### Renovation Creation and Volunteers assignment
Click image to view in full size
- This Sequence Diagram Describes the flow of Renovation creation and assignment of Volunteers to it
The Renovations data will be saved in a Mongo database structured in following collections:
- User
- Renovation
- Renovation Event
- Mission
- Massage
- chat_room
- Donor
- Donation
Updated tables
- The system will be cross-platform including Web, Android and IOS. It will require no installation.
- The system will be modular, making it maintenance easy and open to future changes.
- The Dashboard will provide a user friendly interface to access all the web app capabilities.
- Part of the project will be a Corporate Website for the organization to appeal to more people to join the organization.
-
Planned Unit Testing - Developed using Karma & Jasmine and tested continuously during development
- Database methods - CRUD. (Create, Read, Update, Delete)
- Chat methods - Send/Receive messages, server broadcast.
-
Planned System Testing - Manual testing on every prototype made or changes made to those systems
- Login/Sign-up System
- Data Export
- Planned Usability / UX Testing - Manual testing on every prototype, sending prototype to the client for feedback.
- Handling Errors - the point of failure will be tracked down and debugged, fixing the errors will be done in a modular and clean way in order to avoid issue regression & revisiting the code in the future.
- Added Risks to Main Product Features & Capabilities
- Added new sequence diagram that describes main use case
- Updated first two non-functional requirements
- Added collection diagram for our MongoDB