System and Software Architecture Description (SSAD)

Similar documents
Transition Plan (TP)

System and Software Architecture Description (SSAD)

Operational Concept Description (OCD)

System and Software Architecture Description (SSAD)

Feasibility Evidence Description (FED)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD) Cash Doctor 3.0 Mobile APP Team 12. Primary Role. Operational Concept Engineer

Transition Plan (TP)

System and Software Architecture Description (SSAD)

Avancier Methods (AM) Software Architecture Diagrams

System/Software Architect. Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

Prototype Report Version 3.0. Prototype Report. LADOT Scanning. Team 08. Name Primary Role Secondary Role

System/Software Architect. Description (SSAD)

System and Software Architecture Description (SSAD)

System and Software Architecture Description (SSAD)

Feasibility Evidence Description (FED)

System and Software Architecture Description (SSAD)

Prototype Report. Leamos. Team Number 7

System and Software Architecture Description (SSAD) City of Los Angeles Personnel Department Mobile Applications

System Admin Manual <SNAPVALET> <Team No- 03>

Prototype Report. Leamos. Team Number 7

System and Software Support Plan (SSSP)

System and Software Architecture Description (SSAD)

Transition Plan (TP)

Prototype Report (PRO) Version 4.0. Prototype Report. Smart Locks Control. Team 05. Spring 2018 Team Members: Terence Williams William Goishi

System and Software Architecture Description (SSAD)

Supporting Information Document (SID)

Operational Concept Description (OCD)

System and Software Architecture Description (SSAD) ThrdPlace Social Networking. Team 07

Software System Architecture Document (SSAD)

Transition Plan (TP)

Introduction to Software Engineering. ECSE-321 Unit 9 Architectural Design Approaches

System and Software Architecture Description (SSAD)

index_ qxd 7/18/02 11:48 AM Page 259 Index

Test Plan and Cases (TPC)

Feasibility Evidence Description (FED)

Iteration Plan (IP) Leamos. Team number 7. Name Address Primary Role Secondary Role

Object-Oriented Analysis and Design Using UML (OO-226)

Prototype Report. Frenzy. Team 01

System and Software Architecture Description (SSAD)

System/Software Architect. Description (SSAD)

System and Software Architecture Description (SSAD) Yanomamo Interactive CDROM. Team [06]

System and Software Architecture Description (SSAD)

Prototype Report. LEMA Pilot School Integrated Family Accountability System. Team 4

Prototype Report. LEMA Pilot School Integrated Family Accountability System. Team 4

Operational Concept Description (OCD)

Software User's Manual

Test Plan and Cases (TPC)

Transition Plan (TP)

Prototype Report. Tour Conductor. Team 5

System and Software Architecture Description (SSAD)

Prototype Report. Farm Worker Safety Application. Team 09. Life Cycle Planner Developer. Developer. Quality Focal Point. Developer.

Feasibility Evidence Description (FED)

Feasibility Evidence Description (FED)

System and Software Architecture Description (SSAD)

Feasibility Evidence Description (FED)

S1 Informatic Engineering

Transition Plan (TP)

Cisco ACI - Application Policy Enforcement Using APIC

Introduction to the Azure Portal

Operational Concept Description (OCD)

The ATCP Modeling Framework

IBM Rational Software

Transition Plan (TP)

JBPM Course Content. Module-1 JBPM overview, Drools overview

Prototype Report Template Version 1.1. Prototype Report. Leamos. Team Number 7. Monty Shah Project Manager Life Cycle Planner

Training Plan. Tour Conductor. Team-05

USER MANUAL TABLE OF CONTENTS. Admin Actions Audit Log. Version: 0.1.1

CHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN

Prototype Report. Scriptonomics Team - 07

Prototype Report. Healthy Kids Zone Survey App. Team 14. Name Primary Role Contact Jessie Kim. carson malcoln Representative

Prototype Report. Farm Worker Safety Application. Team 09

Lecture 16: (Architecture IV)

Software User's Manual

Prototype Report. Team 02. Member Name Role . Rajat Verma Project Manager, Lifecycle Planner, Dev

Acceptance Test Plan and Cases (ATPC)

Prototype Report. Software Quality Analysis as a Service (SQAaaS) Team Number Kavneet Kaur Requirement Engineer. George Llames IIV & V

Passport Automation System

Operational Concept Description (OCD)

Architectural Design

DYNAMICS 365 BUSINESS PROCESS VISUALIZATION USING VISIO

Prototype Report Version 2.0. Prototype Report. Transportation Grant Fund. Team 14. Operational Concept Engineer

Transcription:

System and Software Architecture Description (SSAD) Mobil Application for Mobile-Controlled Lighting Team 13 Saumil Kasbekar Sayali Sakhalkar Anuradha Saini Priyank Mishra Sagar Sarda Ashutosh Kale Corey Stall Feasibility Analyst Software Architect Life Cycle Planner Project Manager Requirements Engineer Prototyper Requirements Engineer/Shaper

10/11/2014 SSAD_FCP_F14a_T13_V1.0 ii Version Date: 10/11/2014

Version History Date Author Version Changes made Rationale 10/11/14 PM 1.0 Original template for use with Instructional ICM-Sw v1.0 Initial draft for use with Instructional ICM-Sw v1.0 SSAD_FCP_F14a_T13_V1.0 iii Version Date: 10/11/2014

Table of Contents System and Software Architecture Description (SSAD)... i Version History... iii Table of Contents... iv Table of Tables... v Table of Figures... vi 1. Introduction... 1 1.1 Purpose of the SSAD... 1 1.2 Status of the SSAD... 1 2. System Analysis... 2 2.1 System Analysis Overview... 2 2.2 System Analysis Rationale... 6 3. Technology-Independent Model... 7 3.1 Design Overview... 7 3.2 Design Rationale... 9 4. Technology-Specific System Design... 10 4.1 Design Overview... 10 4.2 Design Rationale... 11 5. Architectural Styles, Patterns and Frameworks... 12 SSAD_FCP_F14a_T13_V1.0 iv Version Date: 10/11/2014

Table of Tables Table 1: Actors Summary... 2 Table 2: Artifacts and Information Summary... 3 Table 3: Process Description... 4 Table 4: Typical Course of Action... 5 Table 5: Alternate Course of Action... 5 Table 6: Exceptional Course of Action... 5 Table 7: Hardware Component Description... 7 Table 8: Software Component Description... 8 Table 9: Supporting Software Component Description... 8 Table 10: Design Class Description... 8 Table 11: Hardware Component Description... 10 Table 12: Software Component Description... 10 Table 13: Supporting Software Component Description... 11 Table 14: Design Class Description... 11 Table 15: Architectural Styles, Patterns, and Frameworks... 12 SSAD_FCP_F14a_T13_V1.0 v Version Date: 08/15/09

System and Software Architecture Description (SSAD) Template Version no x.x Table of Figures Figure 1: System Context Diagram... 2 Figure 2: Artifacts and Information Diagram... 3 Figure 3: Process Diagram... 4 Figure 4: Hardware Component Class Diagram... 7 Figure 5: Software Component Class Diagram... 7 Figure 6: Deployment Diagram... 7 Figure 7: Supporting Software Component Class Diagram... 7 Figure 8: Design Class Diagram... 8 Figure 9: Process Realization Diagram... 9 Figure 10: Hardware Component Class Diagram... 10 Figure 11: Software Component Class Diagram... 10 Figure 12: Deployment Diagram... 10 Figure 13: Supporting Software Component Class Diagram... 10 Figure 14: Design Class Diagram... 11 Figure 15: Process Realization Diagram... 11 SSAD_FCP_F14a_T13_V1.0 vi Version Date: 10/11/2014

1. Introduction 1.1 Purpose of the SSAD The objective of this document is to describe software architecture of the project and the design decisions taken during the design process and the basis for each of them. 1.2 Status of the SSAD This is the first draft of this document. SSAD_FCP_F14a_T13_V1.0 1

2. System Analysis 2.1 System Analysis Overview The primary purpose of the Mobile-Controlled Lighting is making buildings switch free. This system will help able users to control lights of their home and offices from mobile devices. User can turn on or off the switch, all switches of the room, and all switches on one click. User can group switches to room, floor. It will help to save electricity and also energy as we don t have to walk to switch to toggle it. 2.1.1 System Context Figure 1: System Context Diagram Table 1: Actors Summary Actor Description Responsibilities User General User Any User can only switch on/off a switch. Admin An admin who give access permissions to other users Add gateway, configure gateway, add switch and provide access rights to other users. SSAD_FCP_F14a_T13_V1.0 2

2.1.2 Artifacts & Information Figure 2: Artifacts and Information Diagram Table 2: Artifacts and Information Summary Artifact Android Application Node JS Server SQL Lite DB Hardware Purpose To access the switches from an app Backend server to handle the request from app and send response. Database for the system. For gateway and switch. SSAD_FCP_F14a_T13_V1.0 3

2.1.3 Behavior 2.1.3.1 Capability x 2.1.3.1.1 Process y Figure 3: Process Diagram Table 3: Process Description Identifier Purpose Requirements Development Risks Pre-conditions Post-conditions Controlling the switch with an app. Ease of use. Hardware(gateway and switch), Software(in server and in app) People are not willing to use the new system. Login, gateway is configured, switch is added. Added gateway should not be added again, added switch should SSAD_FCP_F14a_T13_V1.0 4

not be added again and revoked access user will not be able to use the system until permission has been given again. Table 4: Typical Course of Action Seq# Actor s Action System s Response 1 Add image for each switch Update the image in the database 2 Assign gateway names Update the database if succeed 3 Delete gateway Delete the gateway entry in the database. 4 Switch On/Off switches Update the state of the switch in the database. 5 Add favorite screen Update the database with the favorite screen having list of switches for a particular user. Table 5: Alternate Course of Action Seq# Actor s Action System s Response 1 Add image for each switch Failure and try again. 2 Assign gateway names Failure and try again 3 Delete gateway Failure and try again 4 Switch On/Off switches Failure and try again 5 Add favorite screen Failure and try again Table 6: Exceptional Course of Action Seq# Actor s Action System s Response 1 Any user action and server is No response from server down 2 Configuring gateway but gateway is not configured No response from gateway. 2.1.4 Modes of Operation The system will operate in two modes: 1) Normal User Mode 2) Admin Mode In admin mode, the user has all the privileges in the system like add Gateway, configure gateway, delete gateway, add/delete switches, switch on/off the light. In normal user mode, the user has only the privilege of switching on/off the light. SSAD_FCP_F14a_T13_V1.0 5

2.2 System Analysis Rationale The rationale in system analysis is that the users are willing to use the mobile controlled lighting and not the traditional switches. They are willing to add gateway, add switches and give the access permissions to others for using them. SSAD_FCP_F14a_T13_V1.0 6

3. Technology-Independent Model 3.1 Design Overview 3.1.1 System Structure << This section should contain a UML hardware component class diagram a UML software component class diagram a UML deployment diagram If necessary, a class diagram for the system's supporting software infrastructure and descriptions of the hardware components, software components, and, if necessary, the supporting software infrastructure components of the technology/platform-independent system architecture More information and example can be found in ICM EPG> Task: Define Technology- Independent Architecture >> <<Hardware Component Class Diagram>> Figure 4: Hardware Component Class Diagram <<Software Component Class Diagram>> Figure 5: Software Component Class Diagram <<Deployment Diagram>> Figure 6: Deployment Diagram <<Optional: Supporting Software Infrastructure Diagram>> Figure 7: Supporting Software Component Class Diagram Table 7: Hardware Component Description Hardware Component Description SSAD_FCP_F14a_T13_V1.0 7

Table 8: Software Component Description Software Component Description Table 9: Supporting Software Component Description Support Software Component Description 3.1.2 Design Classes This section should contain: UML class diagrams showing all the boundary, entity, and control classes in the design of the system being developed and a description of each class in the diagram More information and example can be found in ICM EPG> Task: Define Technology- Independent Architecture >> 3.1.2.1 <Classes n> <<Design Classes Class Diagram>> Figure 8: Design Class Diagram Table 10: Design Class Description Class Type Description SSAD_FCP_F14a_T13_V1.0 8

3.1.3 Process Realization << This section shows how the proposed architecture can be realized by constructing sequence diagrams. More information and example can be found in ICM EPG> Task: Define Technology-Independent Architecture >> <<Process Realization Diagram>> Figure 9: Process Realization Diagram 3.2 Design Rationale << This section should contain an explanation of how/why the architecture/design described in previous sections was chosen. More information and example can be found in ICM EPG> Task: Define Technology-Independent Architecture >> SSAD_FCP_F14a_T13_V1.0 9

4. Technology-Specific System Design << Once you know specific technology that you team is going to use, design the system and software architecture and document them in this section. >> 4.1 Design Overview 4.1.1 System Structure <<Hardware Component Class Diagram>> Figure 10: Hardware Component Class Diagram <<Software Component Class Diagram>> Figure 11: Software Component Class Diagram <<Deployment Diagram>> Figure 12: Deployment Diagram <<Optional: Supporting Software Infrastructure Diagram>> Figure 13: Supporting Software Component Class Diagram Table 11: Hardware Component Description Hardware Component Description Table 12: Software Component Description Software Component Description SSAD_FCP_F14a_T13_V1.0 10

Table 13: Supporting Software Component Description Support Software Component Description 4.1.2 Design Classes 4.1.2.1 <Classes n> <<Design Classes Class Diagram>> Figure 14: Design Class Diagram Table 14: Design Class Description Class Type Description 4.1.3 Process Realization <<Process Realization Diagram>> Figure 15: Process Realization Diagram 4.2 Design Rationale SSAD_FCP_F14a_T13_V1.0 11

5. Architectural Styles, Patterns and Frameworks << Describe any implementation architecture styles (e.g. the Prism style and 3-tier architecture), patterns (e.g. pipe-and-filter and client-server), or frameworks (e.g. Java and CORBA) used to describe the system architecture. >> Table 15: Architectural Styles, Patterns, and Frameworks Name Description Benefits, Costs, and Limitations SSAD_FCP_F14a_T13_V1.0 12