Mobile Client Query Application (MCQA)

From MCS Wiki
Jump to: navigation, search
MCQA Home Screen

Mobile Client Query Application (MCQA) is an Android application that was designed and developed by the 2010 - 2011 Capstone team at The University of Virginia's College at Wise.

Capstone projects allow students to combine an entire curriculum worth of studies into a single project. This paper presents a case study of the 2010-2011 UVA-Wise Capstone Project. Specifically, this paper describes the processes the students used to complete the software life cycle (requirements, design, construction, testing, deployment) of the MCQA system with emphasis on the lessons learned and experiences gained.

2010-2011 Capstone Team: Dru Luce-Edwards, Jeremy Smith, Steven Clark, Brandon Hines, and Matthew Whitt.

College computer science and software engineering courses are focused on individual pieces of the field. Students in those classes gain knowledge about that individual piece of the field and the homework and projects for those courses are also limited to that piece as well. Capstone projects allow students to combine an entire curriculum worth of studies into a single project. In addition to that, they are the closest representation to a real world project that any class offers, in fact, in this case, the capstone is a real world project. The project was originally presented as a brief statement of work from a defense contracting company and all subsequent developments were initiated by the capstone team.

In addition to providing real world experiences, capstone projects can offer other benefits that correspond to taking additional classes. For example, this project is developing on the Android platform, thus making the project count for a mobile devices class. Not only can the capstone incorporate multiple classes in itself but, it can also be used as a prime example for the lower level courses to look at and get involved in. For example, this project's testing phase was conducted by the testing class itself, thus giving the testing class a real project to work on while providing the capstone team with an outside testing team. Since the capstone, by definition, "is a course or project near the end of a program which integrates knowledge, concept and skills associated with an entire sequence of study"[1], it makes sense to include earlier parts of the curriculum in it, especially since those students will one day be in charge of the project.

Contents

Project Description and Requirements

The MCQA project followed an agile model of software engineering by following the basic software engineering model, requirements, design, modeling, construction, testing, deployment, while working on related phases in parallel. The team choose an agile method due to the low number of developers, changing requirements, and time constrains as a result of each individuals schedule. The lead software engineers for the MCQA project also took on the responsibility of project managers. They had to manage the resources for the project by assigning tasks to individuals and keeping track of the progress of the project through the schedule using Microsoft Project. In addition to managing the technological and personnel resources, the project managers also sent status reports to the client every week.

Statement of Work

The project began with a brief Statement of Work (SOW) that included an overview of the expectations of the project and prioritized requirements. Upon receiving the SOW, the team began the requirements phase of the project by following the SWEBOK guide for requirements engineering[2], specifically; requirements elicitation, analysis, specification, and validation.

As part of requirements elicitation, the team compiled a list of requirements based on the SOW and soon after held a kickoff meeting with a representative of the contracting company. During that meeting, project requirements were gathered from the customer and the list of project requirements was updated to reflect the changes from the meeting.

Requirements

Upon completion of the meeting, the team began the analysis phase by having brainstorming sessions to; examine the requirements they have already gathered, for redundancy and conflicts, and generate new requirements that handle issues undefined by the customer, such as software quality requirements.

For the specification phase of requirements engineering, the team developed the Software Requirements Specification (SRS) by following IEEE standard 830-1998[3]. The SRS includes: the project's purpose, scope, functional requirements, nonfunctional requirements, and an indexed list of all requirements. In addition, the team developed use cases for each requirement that would later be translated into test cases to verify those requirements.

To validate the requirements, the team sent the SRS to the customer and after feedback, revised it based on that feedback and the customer accepted the SRS.

After the requirements phase, the project was clearly defined. The project was defined to be an Android application that allows users to enter a unique identifier to search for, and update, an item whose data is stored on a central server.

Design Approach

For the design phase, the lead software engineers took the SRS and used that to develop a comprehensive design for the system that adhered to the requirements. They developed the software architecture, detailed design, and HCI design. Each design is described in detail below. Upon completion of each design, the engineers compiled all the designs in a Software Design Document (SDD) for the project following IEEE standard 1016-2009[4]. The SDD includes each design complete with the rationale behind that design as well as a requirements matrix that maps the requirements to their representation in the design.

Software Architecture

The software architecture follows the client-server architectural style, where client subsystems send and receive data to and from a server subsystem via XML. Both client and server components (individually) follow the layered architectural style

Mobile Client Subsystem Architecture (left) communicates via XML Messages with the Server Subsystem Architecture (right)

Mobile Client Subsystem

The client system employs three different layers: the User Interface Layer, the Application Layer, and the Device Layer.

The User Interface Layer is the interaction element of the client subsystem. The user will see and interact with the UI Layer and all code that is specific to graphics is contained in this layer, for example, the UI screens for the Android are written in XML and that code is only found in this layer. The UI Layer also contains an observer object that updates the UI Layer when the Application Layer has changed.

The brains of the client subsystem is the Application Layer. This layer handles the messages from the server and contains all of the data for the rest of the application. It stores the data for the UI Layer to use. The Application Layer is an observable object that updates the UI Layer when it changes, after the UI Layer registers with the Application Layer.

The Device Layer handles all of the features the hardware of the device supports. In this case, that is all of the features that come standard on an Android phone, for example, vibrate, Wi-Fi, GPS etc.

Each layer has an interface to that individual layer which serves as the access point to that layer. The layers communicate with interfaces by using messages. For example, the UI Layer sends a Search Message to the Application Layer via the Application Layer Interface, the message is interpreted, converted to XML, and sent to the Device Layer to be sent to the server. The messages are contained in their own Message Layer. This layer encompasses both XML type messages that can be sent between the client and server and also inter system messages such as those used for logging events. This layer also includes the actual client object that stores all the relevant information that is contained in the Application Layer which is observed by the User Interface Layer. All objects that handle the creation and parsing of XML messages sent to and from the device are also located here.

Server Subsystem Architecture

The Server Subsystem Architecture was based on the Mobile Client Subsystem Architecture for quality purposes of improving maintainability, readability, and reusability. The Server Subsystem subsumes a User Interface Layer, Server Manager Layer, Database Layer, and a Communication Layer.

The User Interface Layer for the Server Subsystem is a web client, a program that is used to contact and obtain data or service from a server computer[5], represented as a Java desktop application. The lead designers choose this based on the customer's requirements about using a web page to access the server remotely.

The Server Manager Layer handles the messages received by the communication layer and web client. It uses threads to handle each message so it can process multiple database requests at the same time.

The Database Layer houses the MySQL database that the system uses.

This view depicts the interaction between subsystems. Each mobile client subsystem(up to n client subsystems) can access the server but not other mobile clients and there is only one central server subsystem.

The Communication Layer provides all the functionality to send and receive UDP and TCP data to and from the server.

These Layers interact with each other in the same manner as the Client System, via messages. To finish the example from the Client System, the Communication Layer receives the XML Message from the Client, sends that message to the Server Manager, the Server Manager spawns a thread to handle that message, the thread converts the message to a database query. The thread then converts the data received back into a message and sends that message back to the Communication Layer to be sent back to the Client System.

The driving forces behind these design choices were the customer’s requirements for portability and extensibility of the system for future use with other mobile devices. By using the client server pattern with XML messaging, any mobile device that supports XML, which almost all modern devices do, can connect to the server. By using the component and facade pattern, any component can be swapped out for a device specific component as long as it does not change the facade, thus allowing the software to be easily portable. The software was also required to work on an unlimited amount of devices which required us to create a design that would allow the software to work on the maximum amount of devices. In order to fulfill that requirement the team created a design that would allow all of the subsystems to connect via XML messaging to the server subsystem.

Detailed Design

Each component has its own detailed design which breaks the component down into classes, complete with attributes and functions. Components also employ the use of the singleton, observer, and facade patterns. For example, the Application Layer functions as the logical layer of the mobile client, updating item information, and through the observer pattern notifies the User Interface Layer which then updates based to reflect those item updates and from the singleton pattern, ensures that only one instance of the Application Layer will be in memory at any given time. The lead engineers used UML to model each component. These UML designs were completed using StarUML and Rational Rose.

In order to increase the level of abstraction, a standardized message system was developed to handle the passing of data from one component to another. These messages have a unique ID based on what type of message it is and each component supports the handling of those messages. By using the messaging system, components can be updated, replaced, or new ones can be added as long as they handle the messages. Also, new messages can be added due to the messages being an independent structure, so if a component requires a new message, all of the components would be able to see that new message immediately. All of these features and benefits of using the standardized messaging system support the customer's requirements for maximum portability and extensibility.

User Interface Design

Item Information Screen which lets client see any information regarding the item searched.

Upon establishing the requirements and design the team began working on the Graphical User Interface for the application. First the team started with a prototype which we created in PowerPoint. The layouts had click-able buttons so that screen changes could be shown and so that the client could provide feedback on what they thought the product should actually look and feel like. Following several modifications and approval from our client the team began coding the User Interface in XML. Droid Draw, an open source tool which provides a drag and drop interface to create GUI layouts and auto generated code for the Android devices, was the first step to the Android GUI. Once the team gained familiarity with the Android based XML, all coding was done strictly in the Android/Eclipse environment. After all design requirements were met, screen shots of the UI were taken and sent to the client for validation. Through a series of requests and changes from the client, the team finalized the GUI.

Testing

Software testing is performed by searching for item numbers via UDP connection and retrieving a set of information from a central database, item information can also be updated from the device and all changes will be sent to the database. The testing process was done using the black-box testing technique; the team used the college's Software Testing class as the outside test group. They had no experience with the capstone so they had neither opinions nor knowledge on how the system was to work; this provided the team with a detailed test of the entire system. The class will be divided into two groups, one for the client side and one for the server side. These two groups will test the systems individually and eventually test the system together. Our team was responsible for the unit and integration test procedures.

The Unit Tests were derived from the Use Cases that were developed by the team during the requirements phase. The Unit Tests were based on a template that was developed by the team leads and are all validated with the Project Managers before being given to the test groups. Following the information gathered by the test groups, the team then fixed any bugs and then validated the program.

The results gathered by the testing group were maintained using ClearQuest, which was used to submit all reports and bugs found in the MCQA program. Testing was necessary to find any underlying issues in the program so that the team could fix any problems before releasing the final product to our customer. The team realized the importance of releasing a quality product to the client and spent a lot of time in the test phase.

Quality

Releasing a high quality product was very important to the team, Quality validation began with our requirements phase where we began discussing the various nonfunctional requirements we had in our SRS. These Software Quality Factors were accessed to each nonfunctional requirement so that the team insured that no ambiguous requirements were being formed. For example, under the nonfunctional Performance Requirements it states, SQM-1: The software modules shall be limited to 30 statements. This statement was based off the Maintainability Software Quality Factor.

Software Quality Factors

  • Efficiency
  • Correctness
  • Reliability
  • Usability
  • Maintainability
  • Flexibility
  • Testability
  • Portability
  • Interoperability

To insure that we created a quality and maintainable project all code was required to be done in accordance to the Java Coding Style Guide[6]. This required file names to be created in a specific manor, ClassOrInterfaceName.java was how the team represented any source code file names with a capital letter at the beginning of each word. In order to create a more readable code the Style Guide also specified the use of white space and when to use tabs and spaces.

Configuration Management

The team decided that we would need use a Software Configuration Management tool to maintain the software and all supporting documents and information for the project that every member of the team would have access to. The first step was setting up a Basecamp[7] account as a way to notify team members of any changes in activity and for setting any Milestones and To-Dos. The Team then decided on an Open Source version control system and started with git[8] as the SCM tool using github [9] as our repository. Due to difficulty getting the GIT database to work with roaming profiles in Windows, the team decided to use Subversion[10] instead. Subversion is also open source and still met our requirements. The team's Project Managers then created a guide for how team members would be documenting any additions and updates, special descriptions were required for deleting any files or folders.

Software Change Control Process

The team followed the change control process in order to evaluate necessary and unnecessary changes and additions to the project, change controlling was our way of doing peer review. The change process starts with a request of a team member or from the client, from there the team evaluated the request and decided whether it shall be implemented or not. Following the implemented change we validated the changes and incorporated the new changes to the project.

Change Controlling was essential for choosing what the team wanted to add or change in the project since the client requested that the product would maximize the available technology, including geo locations to find positions of the items on the map via GPS and Optical Character Recognition (OCR) by utilizing the camera on the devices. This process helped us to decide what we had time for and what was realistic to finish before the deadline.

Lessons Learned

Throughout the year the team has learned many lessons and expanded their knowledge of the software engineering world. One of the primary experiences gained was the importance of working in a team environment and being held to a strict schedule. Before the Capstone Project, the team had very little experience working with a team which is essential to the software engineering field. The team was very fortunate to have an opportunity to work with a client and be able to go through all of the development cycles to produce a working product. The team did not just learn about the basics during this course, many obstacles had to be overcome throughout the project. One of the first difficulties came when the team was implementing the SCM tools. Also the project managers had to make some difficult decisions with persons who could not follow the set deadlines and were not showing up to meetings, some of which were removed from the project.

For the project managers it was a first chance to lead a team and project. This was the first time that the team had an opportunity to create our own schedules and decide what the requirements would be. The team was required to take a lot of extra time, outside of the designated class time, in order to get some of the phases done so that the deadlines could be met. There was a lot of time spent learning the required languages that were needed to complete the project. The team had not experienced any mobile development before the start of the project; the team was required to learn java, XML, and Android. The team spent a majority of time researching all of the necessary information that was needed in order to develop this product. Most of the team needed to learn the tools and developing environments as well, this was the most in depth project that we had been required to do and required the team to learn a lot of very important tools. Through research the team found several useful tools and information. For example the mapping functionality on the Android emulator did not work when running the level 8 API (Android 2.2) yet it worked on the actual phone device. But when switching the API level to 7 (Android 2.1) the mapping functionality worked on the emulator. Differences between the emulator and the actual device were sometimes quite significant when it came time to test features such as event logging and crash recovery which would not function properly on an emulated device.

Unfortunately the team did not have a review team for this project so the effects of not having a proper Software Configuration Management Process became evident when the project managers had to permanently delete excess and unneeded files and versions from the Subversion Repository. The team recognized the importance of needing an established process where the project managers would be in charge of evaluating, approving, implementing, and validating any changes to Subversion.

Following the requirements phase the design phase was started. Before the Capstone Project the team had little knowledge about the importance of design. The members of the team now recognize the importance of the design and see it as a blueprint for the software. The design was how the team validated how the code was to be constructed and how each class would connect with the other. Perhaps the most important thing that the team learned through the year was that everything can change. Throughout the project the team needed to recognize that some of the requirements in the beginning did not work when it came to the actual coding or implementing the software to the device. Scheduling conflicts also existed which required scheduling changes, either a deadline being moved to a later date or to an earlier date, which were unforeseeable when the schedule was initially made. Along the same lines, the importance of effective communication between team members and managers was also realized.

Through the teams experience a series of Templates and Tutorials were developed that are available to the other Software Engineering and Computer Science students at The University of Virginia's College at Wise who will likely encounter a similar project. The team has created a variety of tutorials which include, how to use Subversion, GUI's in Android, and Rational Rose Quick Guide. The team overall learned much more about how the real process of software engineering works and what it is like to be in the job field.

Demo Video

MCQA Demo (youtube)

Supporting Documents

Tutorials and Templates

Resources

  1. Definitions of Capstone, "[1]", 2011-03-5
  2. SWEBOK Software Requirements, "[2]", 2011-03-15
  3. IEEE, "[3]", 2011-03-15
  4. IEEE SDD, "[4]", 2011-03-15
  5. Basic Terminology: Web Technology "[5]", 2011-03-15
  6. Java Coding Style Guide, Achut Reddy, PDF, 2011-03-15
  7. Basecamp, "[6]", 2011-03-21
  8. git, "[7]", 2011-03-21
  9. github, "[8]", 2011-03-21
  10. Subversion, "[9]", 2011-03-21
Personal tools