-
Notifications
You must be signed in to change notification settings - Fork 0
System Architecture
This document is intended to be a complete look at the structure and layout of the Mobile Trail Mapping (MTM) system. It provides a set of functional requirements for the system, describes the architectural design patterns in use in the system's code, and shows aspects of the system's compartmentalization and dependencies. Users unfamiliar with the system should first consult the project requirements and expected use cases before beginning this document.
The Mobile Trail Mapping project is intended to be a complete suite of mobile and server applications that provide information and mapping services for the Linn County Trails System. Developed primarily for the Android and iOS platforms, the MTM applications provide users with the location of trails and points of interest across every trail in Linn County, Iowa, as well as additional information about certain landmarks and the ability to report problems within the trails system. The primary stakeholders in this system are the members of the Linn County Trails Association (LCTA), as well as any user of the trails in or near Cedar Rapids, Iowa. By April 2011, the MTM team intends to deliver two mobile applications and a server-side backend for the use of the LCTA. For more details, see the project problem statement.
The MTM system has a complete set of functional requirements documented at the requirements and use cases pages; refer to those documents for full requirements information. Briefly, the key functional requirements for the MTM system are:
- Provide a server backend with a simple, remotely accessible API
- Integrate fully with the existing LCTA site
- Support authentication of users for management purposes
- Integrate with Google Maps for display of trails and landmark information
- Allow posts back to the server with geotagged, photographic information
In addition to the functional requirements outlined above, the MTM system must adhere to a certain set of quality attributes as well. The following subsections detail the precise attributes a finalized MTM system must have.
Availability - The trails system does not completely close, per se, at any point; as such, even though individual trails may be closed, the MTM system must be available as much as possible. If necessary, downtime must be concentrated during the evenings or in winter, when trail usage is likely to be much lower.
Source: End users
Stimulus: Regular usage
Environment: Any operating environment or condition
Artifact: Server backend (the MTM team cannot control uptime of individual mobile applications)
Response: Provide expected trails data and landmark information to mobile application and accept any problem reports or authorization actions, or display notification of server downtime
Measure: Time before response (either expected or downtime notification) reaches user
Functionality - The MTM system, when up, must operate within the constraints imposed by the requirements document, the mobile application, and the end user; generally, this means handling data as it is provided and requested, and not encountering any unexpected system terminations.
Source: End user
Stimulus: Normal usage
Environment: Normal operating environment
Artifact: Entire system
Response: Respond to user data as specified in use cases
Measure: Time to expected response is delivered (taking into account network delay)
Usability - As most of the expected users of the MTM system are decidedly nontechnical, usability is an extremely important quality attribute for the mobile applications. The team will be following the restrictions laid out by the Apple Human Interface Guidelines and the Android user interface recommendations.
Source: End user
Stimulus: Normal use
Environment: Normal operating environment
Artifact: Mobile application user interface
Response: Provide a consistent, clean, intuitive interface; respond quickly to user requests
Measure: Ratio of successful to unsuccessful actions; number of clicks to desired user action
Security - While the trail data itself is public, some information (such as authenticated user credentials) must be stored and transmitted securely within the MTM system. Keeping this information secure protects the integrity of the trails data.
Source: Unauthorized user
Stimulus: Authorization request via mobile application
Environment: Normal operating environment
Artifact: Server authentication mechanism
Response: Deny authentication request
Measure: Number of unauthorized users allowed access; percentage of authorized requests incorrectly denied
Testability - In order to ensure many of the other quality attributes in this list, the MTM system must be developed in a way that allows for easy testing. Being able to properly test the system will make it much easier for developers to discover errors in functionality, usability, and availability.
Source: Developers
Stimulus: SickBeard system must undergo unit and acceptance testing
Environment: Development and deployment
Artifact: All MTM applications
Response: Able to locate and run tests over system-level methods and architecture objects, and confirm system at all levels is running properly
Measure: Time taken to locate and run tests; time taken to run tests; test passed vs. tests failed
Modifiability - The primary maintainer of the MTM system after May 2011 will be members of the LCTA, who are not paid or full-time developers; as such, the system must be as well-documented and easy to maintain as possible. In addition, since the MTM system is an open-source project, being able to easily modify the code is an important aspect of the system. MTM applications should be easy for new developers to understand and make meaningful contributions to.
Source: Developers
Stimulus: Changes need to be made to the MTM system
Environment: Development, testing, deployment
Artifact: Any MTM application
Response: Able to locate place in code to modify and make desired change with a minimum of searching and debug effort
Measure: Time taken to locate target code; time spent making change; time spent debugging and verifying proper behavior
In order to further enhance the quality of the MTM system as measured by the attributes listed above, the team is following established object-oriented design practices, including the use of known object structural patterns.
Availability - The MTM team is relying largely on the underlying platforms' reliability to ensure a high uptime of the platform itself. As such, the availability of the system will be largely determined by the reliability of the actual executable code; to ensure a solid system in this regard, the team is providing unit testing on all critical code paths, to ensure that all queries - even invalid ones - are met with the appropriate response, and that no query triggers a system malfunction. The team is also turning to the established practices in the area of exception handling (which vary platform to platform).
Functionality - In order to ensure the appropriate functionality is implemented simply, the MTM team is keeping the representation gap as low as possible. The object design within the database (and, hence, the model provided within the code of the mobile applications) mirrors actual trails system concepts (e.g. trail point, point of interest, etc.). This strategy is a common practice within the object-oriented design community.
Usability - The usability tactics are largely proscribed by the Apple and Android policies; the MTM team will follow these guidelines as closely as possible. In addition, the team will seek to extend the fluid and intuitive behavior provided by Google Maps on both mobile platforms.
Security - Security is an end-to-end concern for the MTM team. The unit tests put in place by the team will include possibly dangerous inputs, to ensure that appropriate sanitization takes place. Furthermore, frameworks in place on the mobile devices themselves will provide secure storage for user data such as login credentials.
Testability - Testing is an area of focus for the MTM team. The entire system is being developed under a test-driven process, which includes everything from writing tests at the individual method level to defining data-validating XML schemas for data transfer. As such, the team is forced during development to ensure that methods are compartmentalized appropriately and all individually provide valid responses, increasing confidence in the appropriate behavior of the system as a whole.
Modifiability - The representational structure and test-driven development described above also contributes to modifiability; since the system closely mirrors reality, it should be relatively simple to understand and modify conceptually, and the existence of a corpus of tests makes it simple to ensure that no change breaks the system or triggers a regression in behavior.