CS 415 Bama Mobile Registration Android Software Requirements Specifications

Version <1.6>

Unclassified

BMR Incorporated, 2009

Page 1

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

Revision History
Date 10/06/2009 10/07/2009 10/12/2009 10/13/2009 10/25/2009 11/09/2009 11/21/2009 Version 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Description Created the initial draft Created draft of section 3 Revision of Document Final Revision Revision as per Teachers Instructions Additions Final Revision for Demo Author Paul Kilgo Xiannuan Liang Joshua K. Sullivan Joshua K. Sullivan Joshua K. Sullivan Joshua K. Sullivan Joshua K. Sullivan

Unclassified

BMR Incorporated, 2009

Page 2

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 Product perspective 2.1.1 Interfaces 2.2 Constraints 3. Specific Requirements 7 3.1 Functional Requirements 3.1.1 <Search Class Catalog> 3.1.2 <Add/Drop Classes> 3.1.3 <Confirm Schedule> 3.1.4 <View Transcript> 3.2 Non-Functional Requirements 3.1.2 <Security> 3.1.3 <Visual Aesthetics> 3.2.3<Connection Permanency > 4. Use Case Diagram 5. Use Case Scenarios 6. Activity Diagrams 7. Test Cases 8. Software Architecture 8.1 Introduction 8.1.1 Purpose 8.1.2 Scope 8.1.3 Definitions, Acronyms, and Abbreviations 8.1.4 Overview 8. 2 Architectural Representation 8.3 Architectural Goals and Constraints 8.4 Use-Case View 8.4.1 Use-Case Realizations 8.5 Logical View 8.5.1 Overview 8.5.2 Architecturally Significant Classes 8.6 Interface Description 8.7 Size and Performance 8.8 Quality 9. Conceptual Architecture (Activity Flow Chart) Unclassified BMR Incorporated, 2009 5 5 5 5 5 5 6 6 6 7

7 7 7 7 7 7 7 7 7 8 9-16 17-24 18-28 28-31 28 28 28 28 28 27 28 28 29 29 29 29 29 29 30 31 Page 3

Bama Mobile Registration Software Requirements Specifications Bmr-Android 10. System Architecture 11. Class Architecture 12. Sequence Diagram

Version: <1.6> Date: 11/21/2009

32 33 34

Unclassified

BMR Incorporated, 2009

Page 4

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

Software Requirements Specifications

1. Introduction
The basic goal of this document is to provide an overview of the software specifics of our project. 1.1 Purpose The purpose of this document is to outline the software project Bama Mobile Registration for Android. This document outlines the external behavior of this application, including nonfunctional requirements, design constraints and other miscellaneous specifications for this software. 1.2 Scope The scope of the project includes creating a user interface to the MyBama registration system as well as a backend that will emulate some of its behavior, specifically for testing. We will then make this user interface and the backend interact. Additionally, this project may extend to add in some nicer features which are not a part of the bare minimum requirements, just some feature thought would be nice to include. 1.3 Definitions, Acronyms, and Abbreviations Bama Mobile Registration can be abbreviated BMR. 1.4 References All public information can be found at the following web address. http://groups.google.com/group/bmr-android?hl=en 1.5 Overview The current class registration system for the University of Alabama is MyBama, which has no known APIs to accomplish our most basic goal. So, instead, we have split the project into two parts: one part to handle the emulation of MyBama. Essentially, we are creating our own API. The second part is the client itself which will exist on the user's mobile device. The end-user to this product is the student who wishes to use a mobile device to manage his or her class schedule. University of Alabama students are the customer for this project. It is important to note this since our design will stem only from the software team's experience using the registration system. The product will have four main screens: the login screen, semester management screen, search screen, and the class listing screen. Each of the four screens will provide certain functionality. Using this product a University of Alabama student will be able to successfully 1 Login to the system 2 Manage their semester through adding and dropping classes 3 View the information about a class 4 Search and find classes

Unclassified

BMR Incorporated, 2009

Page 5

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

2. Overall Description
This section will contain information about the project as a whole including perspectives and constraints. 2.1 Product perspective 2.1.1 Interfaces The product will have four main screens: the login screen which allows a user to log into the system, semester management screen which allows a user to manage their classes, class listing screen which will provide a user with all information about a class, and class search screen which allows users to search for classes. Each of the four screens will provide certain functionality. 2.1.1.1 Login Screen The login screen will allow the user to choose from list of accounts which have been used in the past. The user can select an existing account or add a new one. When the user adds a new one, the user name will appear in the list. If the user chooses an account from the list and the password for the chosen accounts is unsaved, the user will be prompted for a password and also granted the option to save the password. If the password is saved, the system will attempt to log in. If the login is unsuccessful, the user will be prompted to update the password. The accounts should be editable. A long-click, clicking down and holding down your click on the screen, should be able to invoke an option to delete an account, and if the password is saved, an option to forget the password. A successful login will bring up the Semester Management Screen. 2.1.1.2 Semester Management Screen Upon first viewing this screen (presumably after successful login), the user will be presented with a list of classes for which they have registered. If the user has not registered for any classes in the current semester, no classes are presented. Class information should be presented in the list: course title, course code, instructor, and meeting times. A menu action should present to option to switch terms or search for classes. Electing to switch terms will invoke a pop-up screen asking the user which semester they would like to switch to. A search action will bring up the Class Search Screen. Clicking a class in the list will bring up the Class Listing Screen. Long-clicking a class will bring up a menu to drop the class. If the user selects to drop the class, they are asked to confirm. If confirmed, the program issues commands to the back-end to drop the class. 2.1.1.3 Class Listing Screen This screen should show all known information about a given class. A menu action shall present the user with an option to add this class if the user is not already taking the class. 2.1.1.4 Class Search Screen Upon entering this screen, the user will be prompted by a search box, already highlighted, to provide a search term. The user should be able to type in any string of characters. The user can search for specific classes by class code (e.g., CS124), CRN, or just by a generic search term. The backend will sort out what kind of data the user has entered and try to match this against the database. The results of a search are listed just below the search box in a similar fashion as on the Semester Management Screen. Unclassified BMR Incorporated, 2009 Page 6

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

A user can click a result to view its class listing on the Class Listing Screen. The user can long-click a result to try and add the class. Adding the class does not return the user to the Semester Management Screen. 2.2 Constraints The system has the constraint of working on an android cell-phone. This includes limited power and resources. The product is also limited by the android platform. The team is also constrained by time.

3. Specific Requirements
3.1 Functional Requirements 3.3.1 Search Class Catalog The user will have the ability to search the class catalog for various classes and find information on each of the classes in the catalog. This will be integrated in with the Class Search Screen. 3.3.2 Add/Drop Classes The user will have the ability to add or drop the classes that they have found. This feature will be useful for setting up a new schedule or for changing classes after a semester has already started. The Class Management screen will provide the use with the screen that will show them their current classes. If the user wants to add or drop they will then go to the Class Listing Screen which will have the add and drop option. 3.3.3 Confirm Schedule The user will have the ability to confirm their schedule through the application. This involves either clicking confirm because the user has adequate funding to pay for the semester or paying for the semester then clicking confirm. 3.2 Non-Functional Requirements 3.2.1 Security Security will be an issue because of the possibility of monetary transactions as well as the various student data being transferred over a wireless connection. Because of these issues the application will have various security features to enable to user to know that all action performed on the application will be safe. 3.2.2 Visual Aesthetics The application will be aesthetically appealing to the user in order to make the application more desirable. We will test whether or not we have successfully created an aesthetically appealing application by using team members as test subjects. 3.2.3 Connection Permanency The application will be availability 24/7 so that the users can asses all features of the application no matter the time.

Unclassified

BMR Incorporated, 2009

Page 7

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

4.Use Case Diagram

Unclassified

BMR Incorporated, 2009

Page 8

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.Use Case Scenarios

5.1

Name: Add User Identifier: UC01 Preconditions 1. Application exists on Android device Basic Course 1. User starts application 2. User decides to add a new username to local database 3. User inserts username and password 4. User selects whether or not to save the password 5. Information is determined to exist in MyBama backend and is saved into local database. 6. The users current term is displayed Alternate Course A: Username/password determined to be incorrect Condition: User enters a username/password combination that does not exist within MyBama A.1 Message is displayed that informs user that the combination entered is incorrect A.2 List of users is displayed. Post conditions 1. User list is displayed without new username 2. Users current term is displayed

Unclassified

BMR Incorporated, 2009

Page 9

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.2 Name: Login Identifier: UC02 Preconditions 1. Application exists on Android device 2. User has a legitimate username/password in the MyBama system 3. Username exists within local database Basic Course 1. User starts application 2. User selects username from list 3. If prompted, the user enters password 4. Users current term is displayed Alternate Course A: Stored password is incorrect Condition: If the users password has been modified since the most recent login A.1 User is prompted to enter new password Post conditions 1. Users current term is displayed

Unclassified

BMR Incorporated, 2009

Page 10

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.3 Name: Add Class Identifier: UC03 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. User navigates to class search 4. User searches for class 5. User then selects class that was searched for 6. User adds this class to current term Alternate Course A: class searched for does not exist Condition: the class the user searches for does not exist within MyBama A.1 User is returned to search page to search for a different class Alternate Course B: class selected has already been added to schedule Condition: the class the user tries to add already exists in the students schedule B.1 Message is displayed informing user that the class has already been added B.2 User is returned to the class search page Post conditions 1. Current term page is displayed

Unclassified

BMR Incorporated, 2009

Page 11

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.4 Name: Drop Class Identifier UC04 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. User navigates to current term 4. User selects class to drop 5. User drops class Post conditions 1. Updated current term is displayed

Unclassified

BMR Incorporated, 2009

Page 12

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.5 Name: Confirm Schedule Identifier UC05 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. User navigates to current term 4. User selects confirm schedule 5. Message is displayed telling user the schedule is confirmed Alternate Course A: Schedule is already confirmed Condition: User tries to confirm schedule that has already been confirmed A.1 Message is displayed informing user that schedule is already confirmed Post conditions 1. Updated current term is displayed

Unclassified

BMR Incorporated, 2009

Page 13

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.6 Name: Switch Term Identifier UC06 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. User initiates switch term 4. User selects term to display 5. New term is displayed Post conditions 1. Updated term is displayed

Unclassified

BMR Incorporated, 2009

Page 14

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.7 Name: Search Classes Identifier UC07 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. User navigates to current term 4. User selects Search classes 5. Class search is displayed Post conditions 1. Class search is displayed

Unclassified

BMR Incorporated, 2009

Page 15

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

5.8 Name: View Classes Identifier UC08 Preconditions 1. Application exists on Android device 2. User has a valid username/password Basic Course 1. User starts application 2. User selects username to login 3. Current term is displayed Post conditions 1. Updated current term is displayed

Unclassified

BMR Incorporated, 2009

Page 16

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

6. Activity Diagrams
6.1 Add user

Unclassified

BMR Incorporated, 2009

Page 17

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.2 Login

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 18

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.3 Add Class

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 19

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.4 Drop Class

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 20

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.5 Confirm Schedule

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 21

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.6 Switch Term

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 22

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.7 Search Classes

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 23

Bama Mobile Registration Software Requirements Specifications Bmr-Android 6.8 View Classes

Version: <1.6> Date: 11/21/2009

Unclassified

BMR Incorporated, 2009

Page 24

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

7. Test Cases
The test cases are listed below as well as the steps a test must step through as they search for bugs in the system. If the tester reaches the last step without find a bug then the test case passes. 7.1 User logs in using a valid user name and password and is granted access.--Pass, Josh & Ben, 11/14/2009 a. b. c. d. e. f. g. Start application-Pass, Josh & Ben, 11/14/2009 Add new user name to local database.--Pass, Josh & Ben, 11/14/2009 Insert Username and Password.--Pass, Josh & Ben, 11/14/2009 Select to save password.--Pass, Josh & Ben, 11/14/2009 Information is saved in local database.--Pass, Josh & Ben, 11/14/2009 Current term is displayed.--Pass, Josh & Ben, 11/14/2009 Return to step a and work through till step d except this time do not save password, continue on to step f . If f passes then 7.1 is complete.--Pass, Josh & Ben, 11/14/2009

7.2 User logs in with invalid credentials and is denied access.--Pass, Josh & Ben, 11/14/2009 a. b. c. d. Start application.--Pass, Josh & Ben, 11/14/2009 Select user name from List.--Pass, Josh & Ben, 11/14/2009 If prompted, enter an incorrect password.--Pass, Josh & Ben, 11/14/2009 Access denied pop up should be viewable.--Pass, Josh & Ben, 11/14/2009

7.3 User adds class which he/she has necessary requirements to register for and the class is added to their schedule. --Pass, Josh & Ben, 11/14/2009 a. b. c. d. e. f. Start application.--Pass, Josh & Ben, 11/14/2009 Select user name and login.--Pass, Josh & Ben, 11/14/2009 Navigate to class search.--Pass, Josh & Ben, 11/14/2009 Search for a class.--Pass, Josh & Ben, 11/14/2009 Select the search class.--Pass, Josh & Ben, 11/14/2009 Add class to current term.--Pass, Josh & Ben, 11/14/2009

Unclassified

BMR Incorporated, 2009

Page 25

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

7.4 User adds class which results in a failure imposed by the back-end (no prerequisite, not open for registration, too many students signed up, current term not manageable).--Pass, Josh & Ben, 11/14/2009 a. b. c. d. e. f. g. Start application.--Pass, Josh & Ben, 11/14/2009 Select user name and login.--Pass, Josh & Ben, 11/14/2009 Navigate to class search.--Pass, Josh & Ben, 11/14/2009 Search for a class.--Pass, Josh & Ben, 11/14/2009 Select the search class.--Pass, Josh & Ben, 11/14/2009 Add class to current term.--Pass, Josh & Ben, 11/14/2009 Class should not be added.--Pass, Josh & Ben, 11/14/2009

7.5 User drops class successfully. --Pass, Josh & Ben, 11/13/2009 a. b. c. d. e. Start application.--Pass, Josh & Ben, 11/13/2009 Select user name and login.--Pass, Josh & Ben, 11/13/2009 Navigate to current term.--Pass, Josh & Ben, 11/13/2009 Select the class to drop.--Pass, Josh & Ben, 11/13/2009 Class will drop from list of classes current being taken.--Pass, Josh & Ben, 11/13/2009

7.6 User drops class which ends in failure (co-requisite with an incomplete class, current term not manageable). --Pass, Josh & Ben, 11/13/2009 a. Start application.--Pass, Josh & Ben, 11/13/2009 b. c. d. e. Select user name and login.--Pass, Josh & Ben, 11/13/2009 Navigate to current term.--Pass, Josh & Ben, 11/13/2009 Select the class to drop.--Pass, Josh & Ben, 11/13/2009 Class will not drop.--Pass, Josh & Ben, 11/13/2009

7.7 User searches for class by its class code (CS123), CRN, or with a generic search term.--Pass, Josh & Scott, 11/13/2009 a. b. c. d. e. Start application.--Pass, Josh & Scott, 11/13/2009 Select user name and login.--Pass, Josh & Scott, 11/13/2009 Navigate to current term.--Pass, Josh & Scott, 11/13/2009 Select the Search class.--Pass, Josh & Scott, 11/13/2009 Class search will be viewable.--Pass, Josh & Scott, 11/13/2009

Unclassified

BMR Incorporated, 2009

Page 26

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

7.8 User performs a search which yields no results.--Pass, Josh & Scott, 11/13/2009 a. b. c. d. e. Start application.--Pass, Josh & Scott, 11/13/2009 Select user name and login.--Pass, Josh & Scott, 11/13/2009 Navigate to current term.--Pass, Josh & Scott, 11/13/2009 Select the Search class for a class that doesnt exist.--Pass, Josh & Scott, 11/13/2009 Class not found will be displayed.--Pass, Josh & Scott, 11/13/2009

7.9 User views the class information for a class listing returned from a search result.--Pass, Josh , 11/14/2009 a. b. c. d. e. f. Start application.--Pass, Josh , 11/14/2009 Select user name and login.--Pass, Josh , 11/14/2009 Navigate to current term.--Pass, Josh , 11/14/2009 Select the Search class.--Pass ,Josh , 11/14/2009 Class search will be viewable.--Pass, Josh , 11/14/2009 Click the class to view all extra information about the class on the class listing. --Pass, Josh , 11/14/2009

7.10 User views the class information out of the list of classes in the current semester. --Pass, Ben, 11/12/2009 a. b. c. d. Start application.--Pass, Ben, 11/12/2009 Select user name and login.--Pass, Ben, 11/12/2009 Navigate to current term.--Pass, Ben, 11/12/2009 Click the class to view all extra information about the class on the class listing.--Pass, Ben, 11/12/2009

8 Software Architecture 8.1 Introduction

The purpose of this document is to provide an overview of the architecture for the Bama Mobile Registration project for Android. The project includes writing a client for a currently nonexistent API for the MyBama course registration system implemented at the University of Alabama. Because the API is nonexistent, we will include a mostly nonfunctional but approximate backend of what the API should be able to do. 8.1.1 Purpose This document will provide the reader with a good overview of how we intend to solve the problem of registering for class via a mobile phone. The view of the project will be very high-level and will lack specifics, but should provide some guidance on how the software should be structured. 8.1.2 Scope This document only defines what is to be done on the mobile platform and the medium through which it Unclassified BMR Incorporated, 2009 Page 27

Bama Mobile Registration Software Requirements Specifications Bmr-Android communicates with the backend.

Version: <1.6> Date: 11/21/2009

8.1.3 Definitions, Acronyms, and Abbreviations Bama Mobile Registration is occasionally abbreviated BMR. ClaXML is the name given to the XML subset the client and server will use to communicate. 8.1.4 Overview The remainder of this document defines the model we have chosen to use for our client-server communication and the roles and responsibilities are assigned.

8.2 Architectural Representation

The easiest way to imagine this project is a simple client-server model that communicates in some way with a server via a cell carrier's data connection or other IP interface. We do not concern ourselves with the specifics of this communication as this is covered in the scope of the Android SDK. We are then introducing the model elements of the central server, the mobile device, and the communication layers that connect them. In terms of the OSI Model, we place ourselves just over the application layer as we intend to make the client and server communicate over HTTP or in later implementations, HTTPS. For this project, we are most interested in making the software for the client. So this essentially means that the user is somewhere else in the world and communicates with a central server which should contain all of the class backing, authentication information, et cetera. With this in mind, it's easy to see that we can't allow the user's phone perform the majority of the decision-making as this will be performed by the central server since it holds the database. We will essentially be designing a dumb client which makes requests to the server and displays the result to the user. Stepping into the intricacies of what goes on inside the client, we can start to see a few of the components flesh out. For one, we should have four major screens: a login screen, a semester management screen, a class listing screen, and a class search screen. As well, it makes sense to have a component whose purpose is to maintain the session and communicate with the server. We can refer to this component as Session. For the platform we are designing for, an easy way is offered for parsing XML: SAX. This introduces a component which is a SAX handler for ClaXML, called ClaXMLHandler, and as well a data set that it produces, ClaXMLSet. The user will navigate through the screens or Activities for Android terminology. These Activities will make calls to the Session object to connect to and retrieve data from the central server. The Activities will then display the result to the user. The Session object sits idly by and will handle making calls to SAX, constructing ClaXMLSets, and presenting the result in a manner that programmatically makes sense.

8.3 Architectural Goals and Constraints

With any network communication, there comes the possibility of security and privacy. This is an especial concern when dealing with monetary transactions, as confirming a schedule would normally involve. In final implementations, encryption would be absolutely necessary. There is a problem of connection loss that we expect to experience when using cell phones with spotty connections. We will have to design around this as there is not much we can do to remedy the problem. The phone will end up knowing very little about what classes are available for the user to take. A data Unclassified BMR Incorporated, 2009 Page 28

Bama Mobile Registration Software Requirements Specifications Bmr-Android connection would be absolutely necessary to use this application.

Version: <1.6> Date: 11/21/2009

With the phone not having any data backing for itself, the application could end up being very slow if it makes too many requests to the server. We will have to be intelligent about network usage and make clever use of data caching. On the plus side, the dumb client will be on the easier side to implement. Since we are relying on the backend to do most of the class registration logic, all we will have to do is make the client respond to the server's messages in an appropriate way. Our dependencies indicate that we need to work from the bottom-up in terms of implementation. We should start with the ClaXML objects as they are required by Session, then we can work on Session, as it is required by the Activities. The non-functional portions of the Activities may be worked on in parallel with the Session and ClaXML objects.

8.4 Use-Case View

The important use cases for this document are Add Class, Drop Class, Confirm Schedule, and Login as they suggest something about what will be passed over the network to t he server. Also, our communication medium will need to be able to support these kinds of commands. Otherwise, it's up to us as the software designers to place these use cases in areas which will make the most sense to the user. For example, it only makes sense to add a class after we have searched for it first, so it makes sense we place the Add Class use case somewhere inside the class search screen. 8.4.1 Use-Case Realizations Almost all of the use cases work in very similar ways, but perhaps the most complicated is the Search use case. Let us examine it in detail. First, the user will interact with the user interface inside the Search Activity and perform some input which causes the system to pass a search string that the user has entered to the Session object. The Session object will then construct the appropriate URL to handle the search action. The Session object will then make a call to the SAX libraries and pass it a ClaXMLHandler object and the constructed URL. SAX will call this URL, take the data returned, and parse it. We can then mine a ClaXMLSet object out of ClaXMLHandler and examine its contents. We can check for errors and throw an exception if any exist. Otherwise, we can return the data set back to the Activity. The Activity will then take this data source and bind it to a user interface component and display the search result to the user.

8.5 Logical View

8.5.1 Overview On the client side, we are looking at just two main packages. One package which relates specifically to BMR, and the other which deals primarily with ClaXML. The BMR package decomposes into a Session object and four Activities which represent the individual screens. The ClaXML package decomposes into a handler for SAX and a data set that we can return back to the classes inside the BMR package.

Unclassified

BMR Incorporated, 2009

Page 29

Bama Mobile Registration Software Requirements Specifications Bmr-Android 8.5.2

Version: <1.6> Date: 11/21/2009

Architecturally Significant Classes The Session object will be in charge of all of the communication with the server. It is essentially the only exit point for the mobile device in our most high-level view of this project. The Activity classes represent the melding with the user. They will be in charge of responding to inputs issued by the user.

8.6 Interface Description

All of our Activities are intended to be ListActivities, which means we will have a very list-based user interface. As most actions involve choosing an item out of a set of items, it seemed most appropriate. We intend to use Android's standard methods of interaction with the user. For example, we make use of single-clicks as selections for items in lists, long-clicks for data-altering actions (Edit/Delete), and for any other actions we intend to put inside the Menu.

8.7 Size and Performance

One thing to consider when designing this software is of course that we are developing for a mobile platform. That means for one screenful of user interface, we can only accomplish so much. This is why we ended up with four screens with very discrete functions. We should be careful to minimize the amount of network communication our application poses as data connections could end up being very slow or very costly to the user if they have no data plan. Our XML subset should be very minimal and light.

8.8 Quality
Since we have very discrete actions for each Activity, it becomes rather easy to add on a new element of functionality. All that's needed is to add an Activity to support this functionality and a bridging to it from another Activity. If network functionality is needed, the new Activity can just make a call to Session. Our application calls for very basic usage of the user interface, the hardware of the target device probably won't be a big issue to us. We are designing with a touch screen in mind, but Android provides alternative ways of navigation and we can always add support for other input methods in our user interface with relative ease. It will probably be backwards-compatible across Android versions. Our application has a very good chance of becoming multilingual as all of the software we are creating has good support for multiple languages. For the client-server messages, if the server sends a message in some language, the device would only display character-by-character what the server told it. So, if the server has been translated, a lot of the client's user interactions have been as well. As well, Android has good support for different device locales.

Unclassified

BMR Incorporated, 2009

Page 30

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

9. Conceptual Architecture (Activity Flow Chart)

Unclassified

BMR Incorporated, 2009

Page 31

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

10.System Architecture

Unclassified

BMR Incorporated, 2009

Page 32

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

11. Class Architecture

Unclassified

BMR Incorporated, 2009

Page 33

Bama Mobile Registration Software Requirements Specifications Bmr-Android

Version: <1.6> Date: 11/21/2009

12.Sequence Diagram

Unclassified

BMR Incorporated, 2009

Page 34