This document describes the architecture and design for the Pocket Campus Tour application being developed for the University of Missouri—Kansas City (UMKC). Pocket Campus Tour is a PDA application that turns a GPS enabled PDA into a personal tour guide providing audio commentary on the buildings and notable structures on the UMKC campus. Pocket Campus Tour has a roaming mode that requires zero computer skills. Visitors simply carry the device with them as they stroll the campus and it provides audio commentary relevant to the visitor’s current location. For those who can’t or don’t want to stroll the campus, the application also offers a self-directed mode where the same position-dependent audio commentary is available from an interactive onscreen campus map.

The purpose of this document is to describe the architecture and design of the Pocket Campus Tour application in a way that addresses the interests and concerns of all major stakeholders. For this application the major stakeholders are:

· Users and the customer – they want assurances that the architecture will provide for system functionality and exhibit desirable non-functional quality requirements such as usability, reliability, etc.

· Developers – they want an architecture that will minimize complexity and development effort.

· Project Manager – the project manager is responsible for assigning tasks and coordinating development work. He or she wants an architecture that divides the system into components of roughly equal size and complexity that can be developed simultaneously with minimal dependencies. For this to happen, the modules need well-defined interfaces. Also, because most individuals specialize in a particular skill or technology, modules should be designed around specific expertise. For example, all UI logic might be encapsulated in one module. Another might have all logic related to GPS coordinates.

· Maintenance Programmers – they want assurance that the system will be easy to evolve and maintain on into the future.

The architecture and design for a software system is complex and individual stakeholders often have specialized interests. There is no one diagram or model that can easily express a system’s architecture and design. For this reason, software architecture and design is often presented in terms of multiple views or perspectives [IEEE Std. 1471]. Here the architecture of the Pocket Campus Tour application is described from 4 different perspectives [1995 Krutchen]:

1. Logical View – major components, their attributes and operations. This view also includes relationships between components and their interactions. When doing OO design, class diagrams and sequence diagrams are often used to express the logical view.

2. Process View – the threads of control and processes used to execute the operations identified in the logical view.

3. Development View – how system modules map to development organization.

4. Use Case View – the use case view is used to both motivate and validate design activity. At the start of design the requirements define the functional objectives for the design. Use cases are also used to validate suggested designs. It should be possible to walk through a use case scenario and follow the interaction between high-level components. The components should have all the necessary behavior to conceptually execute a use case.

2 Design Goals

There is no absolute measure for distinguishing between good and bad design. The value of a design depends on stakeholder priorities. For example, depending on the circumstances, an efficient design might be better than a maintainable one, or vise versa. Therefore, before presenting a design it is good practice to state the design priorities. The design that is offered will be judged according to how well it satisfies the stated priorities.

The priorities for the design that follows are:

· The design should minimize complexity and development effort.

· The design should take into account the development environment which is 6-7 small teams with complementary skills that work across time and space (teams are not co-located). Ideally the design should result in 6-7 loosely coupled components of equal size and complexity. If the components have well-defined interfaces each team can work independently coding to the interfaces of the other components. The concerns of each component should be narrow so that each team can specialize on a particular technology or skill.

· The design shouldn’t inhibit reusability. The two previous design goals are more important, but the ability to reuse components is also desirable.

3 System Behavior

The use case view is used to both drive the design phase and validate the output of the design phase. The architecture description presented here starts with a review of the expect system behavior in order to set the stage for the architecture description that follows. For a more detailed account of software requirements, see the requirements document.

Figure 1 System Behavior

4 Logical View

The logical view describes the main functional components of the system. This includes modules, the static relationships between modules, and their dynamic patterns of interaction.

In this section the modules of the system are first expressed in terms of high level components (architecture) and progressively refined into more detailed components and eventually classes with specific attributes and operations.

4.1 High-Level Design (Architecture)

The high-level view or architecture consists of 5 major components:

Figure 2 System Architecture

· The GPS device provides the user’s location on campus (longitude and latitude coordinates). In basic mode, the user’s position is used to decide which buildings to announce.

· The Database is a central repository for data on buildings, their locations and associated audio segments.

· The Audio Player controls playback of audio files.

· Given a position on earth, the Mapping Logic will calculate nearby buildings.

· The Application Control Logic is the main driver of the application. It presents information to the user and reacts to user inputs.

4.2 Mid-Level Design

Figure 3 Mid-Level design components and their relationships

Figure 4 shows the dynamic behavior of mid-level components in basic mode.

Figure 4 Basic Mode Sequence Diagram

Figure 5 shows the dynamic behavior of mid-level components in self-directed mode.

Figure 5 Self-Directed mode sequence diagram

4.3 Detailed Class Design

5 Process View

Each loop represents a thread of control.

6 Development View

7 Physical View

[TBD]

8 Use Case View

(The following is more algorithm than use-case view. Fix later.)

Basic Tour:

1. Get instance of GPS Device.

2. Start GPS Device.

3. Register as a listener for events: OnConnectionObtained, OnConnectionLost, and PositionChanged.

4. Display welcome message on screen. Play welcome audio.

5. While (! Interrupted) do looking(); if (connected and !interrupted) do map();

looking()

1. if (connected) return;

2. Display “Looking for satellites …”

3. Play associated audio.

4. Play one minute of soothing music. (interruptible)

5. while (! Connected and ! Interrupted) Play one minute of soothing music. (interruptible) Play “still looking”

map()

1. Ask CampusData for small map

2. Create and display CampusImage

3. Center the image on the display so user’s location is at the center

4. While (connected and !interrupted) get current position from GPSDevice get building near current position pick one play audio data for selected building

OnConnectionObtained

play 1 second of silence to stop current audio

OnConnectionLost

connected = false

OnPositionChanged

center image around new position

Welcome

Basic Tour

Self-Dir

Mode

“Searching for satellites …”

Mode

“Welcome to basic mode. In basic mode …”

Application

Basic Mode

Audio Player

Mapping Logic

Database

GUI Thread

GPS Device

Self-Dir Mode

*Self-Directed mode will create a temporary thread to play audio after a screen click event. [TBD: redraw class diagram using uml 2.0 active class notation.]

Page 2 of 12

$63 fixed project work

Pocket Campus Tour

Architecture/Design Document

Table of Contents

1 Introduction