Architecture and Research

The architecture team got together on Tuesday morning to go over the whiteboard business processes from the initial meeting (Figure II-2.1).

Figure II-2.1. This whiteboard diagram shows the expense report business processes.

They needed to take the raw flow expressed in this diagram and translate it into a precise architecture diagram that represents the initial logical flow of the application. Because the architecture team was waiting on the research team to explore the new MX technologies, the team decided to focus on the logic of the application and ignore any specific technology concerns at this point. This architecture diagram (Figure II-2.2) explains that once the user logs in, the application decides whether the user is an employee or an administrator (Admin) and takes him or her into the respective Employee or Admin side of the application.

Figure II-2.2. This architecture diagram shows all of the major steps, decisions, and processes of the application.

The user (Employee) side of the application begins by checking to see if the user is online or not. If the user is offline, the flow continues to allow the user to enter a new expense report (and tells the application to store it locally). If the user is online, the application begins by checking to see if there are any pending locally stored expense reports (from a previous offline session) and promptly sends them to the database for retrieval by the Admin user. Next the application checks for any returned expense reports. At this point the Employee user can decide whether to redo a returned expense report or start a new one. If the user decides to start a new expense report, he or she must then choose an expense type (such as meal, travel, or entertainment) and then fill out the details in that expense wizard. The user continues to complete expense wizards until he or she feels the report is finished. At this point, the complete expense report is either saved locally (if the user is offline) or stored in the database (if the user is online) to be retrieved by the Admin user. If instead of starting a new expense report, the Employee user decides to redo a returned report, the details of the returned report are displayed, and the user can change any fields he or she would like. When the user is done changing fields, he or she can resubmit the report to the database for retrieval by the Admin user.

The Admin side of the application only operates while the Admin user is online (this is necessary because the database will need to be queried for pending expense reports). The Admin user can process pending expense reports. When a pending report is selected, the report details are displayed. From here the Admin user can either approve the report or deny it and give a reason. The results are stored in the database, and if the report was denied, the Employee user is notified.

As the application architecture was completed, reports started coming in from the research team.

Because of Jason's memo, the architecture team concluded that Shared LocalObjects would be an elegant way to store data locally when an Internet connection is unavailable.

After receiving these two memos, the team felt confident that using ColdFusion MX components with the Flash MX NetServices object would be the best way to have a rich user interface attach to a robust database back end.

This final memo from Trey reiterated the team's concerns about trying to build a mobile version of the application before the given due date. However, the team was comforted to know that Flash MX does have some features that will help with this future development effort.