Download Software Architecture Document

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Clusterpoint wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Database model wikipedia , lookup

Transcript
Software Architecture
Document
Highly Accurate Mobile Device Positioning based on
Wi-Fi Signals
Ankur Patel, Samuel Gottfried, Jeffrey Seaman, Joe Impellizzieri, Brandon
Pastuszek
3/8/2011
Table of Contents
1. Introduction .............................................................................................................................................. 4
2. Background ............................................................................................................................................... 4
3. Functional Requirements .......................................................................................................................... 4
4. Quality Attributes...................................................................................................................................... 4
Performance ............................................................................................................................................. 4
Availability ................................................................................................................................................. 5
Modifiability .............................................................................................................................................. 5
Security ..................................................................................................................................................... 5
Testability .................................................................................................................................................. 5
5. Patterns and Tactics .................................................................................................................................. 5
5.1 Availability ........................................................................................................................................... 5
5.1.1 Transactions ................................................................................................................................. 5
5.1.2 Exceptions .................................................................................................................................... 5
5.2 Performance ....................................................................................................................................... 5
5.2.1. Repository-Centric ...................................................................................................................... 5
5.3 Modifiability ........................................................................................................................................ 6
5.3.1 Abstracted System Interface ........................................................................................................ 6
5.4 Scalability ............................................................................................................................................ 6
5.4.1 Limit Processor-Intensive Tasks to the Web Server Layer ........................................................... 6
6. Views ......................................................................................................................................................... 7
6.1 System View ............................................................................................................................................ 7
6.1.1 Primary Presentation ....................................................................................................................... 7
6.1.2 Element Catalog ............................................................................................................................... 8
A. Elements ........................................................................................................................................... 8
2
B. Relationships ..................................................................................................................................... 8
6.1.4 Variability Guide............................................................................................................................. 10
6.1.5 Architecture Background ............................................................................................................... 10
6.2 Deployment View.................................................................................................................................. 11
6.2.1 Primary Presentation ..................................................................................................................... 11
6.2.2 Element Catalog ............................................................................................................................. 11
A. Elements ......................................................................................................................................... 11
B. Relationships ................................................................................................................................... 12
C. Interfaces ........................................................................................................................................ 12
6.2.3 Variability Guide............................................................................................................................. 12
6.2.4 Architecture Background ............................................................................................................... 12
7. Acknowledgements................................................................................................................................. 12
8. References .............................................................................................................................................. 13
3
1. Introduction
Overview: This system is intended to accurately locate Wi-Fi devices. The system will be seeded with
Wi-Fi devices and their signal strengths at a location and/or the location of access points. Using that
data, the Wi-Fi devices and their relative signal strengths reported by an end-user device will be
analyzed to determine the end-user device’s location.
2. Background
ZOS Communications uses the cell tower, GPS coordinates and Wi-Fi devices detected by an end-user
device to determine its location. However, indoor Wi-Fi device location can be incredibly difficult. ZOS
currently utilizes the GPS coordinates reported by an end-user device to record the location of a Wi-Fi
device. However, the GPS coordinates can be wildly inaccurate when inside of a building. This system
intends to allow more accurate location of an end-user device by utilizing a database of seeded and
learned information about stationary Wi-Fi devices at a location.
3. Functional Requirements
1. The system shall seed baseline data containing Wi-Fi access point MAC addresses and signal
strengths at a given location.
2. The system shall seed the GPS location of access points.
3. The system shall locate an end-user device based on seeded information.
4. The system shall self-learn and self-heal, increasing or decreasing confidence of Wi-Fi devices at
a location as they are continuously included or not included from end-user device readings.
Refer to the Software Requirements for Highly Accurate Mobile Device Positioning based on Wi-Fi
Signals document for use cases.
4. Quality Attributes
Performance
P.1. The system shall locate a device within 5-10 meters of accuracy.
P.2. Accuracy of end-user device location will take priority over the time the system requires to compute
the location.
P.3. The system will be scalable to accommodate additional users as needed without much strain on the
performance of the system.
4
Availability
A.1. The system will be available 99.99% of the time.
A.2. The database will support rollback in the event that an error occurs.
Modifiability
M.1. The system will be modifiable so that future groups will be allowed to add or modify existing
features. As long as the system gets the same input, we can swap out components in the web service as
needed in order to make changes and not affect the overall system.
Security
S.1. Only ZOS will be able to access this system. It is not accessible from the outside.
Testability
T.1. For a given input of Wi-Fi data, such as signal strength and location of Wi-Fi access points, there will
be an expected output that we can test against.
5. Patterns and Tactics
5.1 Availability
5.1.1 Transactions
All data alterations that occur during seeding and learning will occur inside a fault prevention technique
known as transactions. Once a transaction is started, changes are tracked until the transaction is over.
In the event of an error during a transaction the system can rollback the data's state to when the
transaction began. This will ensure that either all changes made to Wi-Fi device data is committed to
the database or none of the changes are.
5.1.2 Exceptions
Exceptions will be used to discover faults when connecting to the database to retrieve or alter
information and when validating input to the web service.
5.2 Performance
5.2.1. Repository-Centric
By using a repository centric pattern we can increase performance by placing all the package data into a
central repository. This frees our system from having to hold local copies of all Wi-Fi data and updating
regularly. This pattern can also save on system processing power, by allowing the system holding the
repository to do all the work searching for the desired data.
5
5.3 Modifiability
5.3.1 Abstracted System Interface
The entry point to the Wi-Fi Locationing System is abstract. As long as any internal modifications to the
system accept the same inputs and return the same outputs, there is no necessary change to any
external system utilizing this service.
5.4 Scalability
5.4.1 Limit Processor-Intensive Tasks to the Web Server Layer
In our environment, scaling a database is incredibility difficult but scaling a web server is very quick and
easy. Because of this, the most processor-intensive tasks will be performed on the web server.
6
6. Views
6.1 System View
6.1.1 Primary Presentation
7
6.1.2 Element Catalog
A. Elements
End-User/Seeding Devices – This element is either the device for which a location will be determined or
the device used to gather baseline readings of a location.
ZOS Locationing Web Service – This element is ZOS’s main locationing service. It will use GPS and cell
tower data to determine location. It also keeps a record of a device’s location.
System Communication Controller – This element controls the execution of the system. It is in charge of
receiving data about Wi-Fi devices at a location to use either in locating a device or to establish as a
baseline for a location.
Algorithm Controller – When locating a device, this element will invoke available algorithms with the
Wi-Fi devices and their relative signal strengths detected by an end-user device to determine a location.
When appropriate, it reconciles multiple location results into a single location to return.
Seeding Controller – When seeding information, this elements utilizes Wi-Fi devices detected by a
seeding device to create a baseline signature of a location.
Database Interface – This element serves as the sole method of interacting with the system’s data
source.
Database – This element manages and indexes persisted Wi-Fi device data.
B. Relationships
End-User/Seeding Devices to ZOS Locationing Web Service – End-user and Seeding devices would
upload information about Wi-Fi devices detected to the ZOS Locationing Web Service to either perform
a location of the device and/or to establish or improve information about a location.
ZOS Locationing Web Service to System Communication Controller – All seeding and location requests
originate from the ZOS Locationing Web Service and are sent to the System Communication Controller.
All location results are returned to the ZOS Locationing Web Service
System Communication Controller to Algorithm Controller – When locating an end-user device, the
System Communication Controller provides the Algorithm Controller with information about detected
Wi-Fi devices. The Algorithm Controller returns the location(s) of the device.
System Communication Controller to Seeding Controller – When seeding information about a location,
the System Communication Controller provides the Seeding Controller information about Wi-Fi devices
detected at a named location to use as a baseline for end-user device locations.
Algorithm Controller to Database Interface – The Algorithm Controller requests from the Database
Interface baseline information about detected Wi-Fi devices to use in locationing.
8
Seeding Controller to Database Interface – The Seeding Controller sends to the Database Interface
information about Wi-Fi devices to use as baseline data.
9
6.1.3 Context Diagram
6.1.4 Variability Guide
Since this system is internal and there is little change to its context, there are no major variabilities.
6.1.5 Architecture Background
The system makes use of the MVC-like Presentation, Controller and Model informational system
architectural pattern. Since data is persisted in a database, having the model of the system provide
transparency when retrieving data is crucial. The presentation layer serves as the input and outputs for
the system and the controllers of the system direct the necessary model components to process web
requests.
10
6.2 Deployment View
6.2.1 Primary Presentation
6.2.2 Element Catalog
A. Elements
Communication Controller – This component allows the transmission of Wi-Fi data from an end-user or
seeding device.
Locationing Web Service - This component is the main entry point into the locationing service. It
handles GPS and cell tower data to determine a location and relays any Wi-Fi information to the Wi-Fi
Locationing System to determine a location.
WCF Web Service - This component serves as the main entry point into the Wi-Fi Locationing System. It
relays end-user location and seeding requests to the appropriate subsystem.
MySQL – This component persists and indexes all Wi-Fi baseline data.
11
B. Relationships
End-User/Seeding Deivce – This device gathers information about detected Wi-Fi devices, cell towers
and GPS coordinates and then relays it to the ZOS Locationing System
Locationing Web Service – This interface is the main entry point into the ZOS Locationing System. When
available, it relays Wi-Fi information to the WCF Web Service to determine a location or establish a
baseline for a location.
WCF Web Service – This service is the main entry point into the Wi-Fi Locationing System. It directs the
request to the appropriate locationing or seeding subsystem. Each sub-system requests information
from or updates information to the database as needed.
MySQL – This component receives any data requests or updates from the WCF Web Service.
C. Interfaces
Locationing Web Service – This interface should expose publically the ability to locate a device and, with
privilege, the ability to establish a baseline for a location.
WCF Web Service – This interface should expose to ZOS the ability to locate an end-user device or
establish a baseline for a location.
MySQL – This interface should expose the ability to retrieve and update Wi-Fi baseline data.
6.2.3 Variability Guide
In this view there is the possibility that the end-user or seeding device can differ. The only common
requirement is that it be able to communicate via HTTP.
6.2.4 Architecture Background
This development diagram uses mainly client-server architecture. The end-user or seeding device
uploads Wi-Fi data to the ZOS Location System, which in turn relays the data to our system. When
available, a location is returned from the Wi-Fi Locationing System.
7. Acknowledgements
We would like to thank the clients who had a clear system in mind. They provided us with all of the
necessary details to create the system and responded to all questions we had.
We also would like to give credit to: Addison Wesley - Software Architecture in Practice, Second Edition
which we used as a reference for creating the views, addressing qualities, as well as architecture
patterns.
12
8. References
Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice. Boston: Addison-Wesley,
2003. Print.
13