Architectural Design

Given the criteria stated in the use case definition, it is clear that a desktop application will not be a good choice. We are therefore going to go for a Web application. Remember that as discussed in the lectures, the flexibility, maintainability and scalability of a (Web) application is, by the most part, determined by its overall architecture.

The way to go about defining a solid architecture is to study the problem carefully and define application views, models, stores and controllers before any coding action takes place.

The User Interface

The first milestone in this process is the selection of views. It is the task of the architect to identify how users will interact with the application and what will be the result of such interaction. The outcome of this analysis will be a set of views with a clearly defined role in the application.

Following the developments in technology, Web applications have become more and more responsive over the last years. This trend gives developers increasing number of ways and techniques to help users to interact with different types of content. In our case this content can be classified in three distinctive groups and as such we can assume that they can be presented separately to the users. One of the possible ways to achivee that, is by using a creating an interface with a number of tabs, each of which provides access to a specific type of content. This means one tab for statistical data, one tab for transport data and one more for planning data. All three combined in a single main application view. The application object that will correspond to this main view will be called HomeView. This view will be the first application component to be render in the browser. The internal elements of this view will simply be the panels for the various types of content of the application.

The layout of the statistics tab will include an area for a base map and an area for statistical charts. We will call the application object for this view StatisticsView (see Figure 1-1).

The transport tab is much simpler and will only include an area for a base map where all details of the status of the public transport can be displayed. The application object corresponding to this view is called TransportView (see Figure 1-2).

The Planning tab is the most elaborated of them all, with a larger number of elements. A map for citizen orientation. A grid for data about citizen reports. A strreview of the areas where reports have been filed. And a floating editor window which will enable citizens to type in the details of reports. The application object for this view will be called PlanningView (see Figure 1-3).

The Application Structure

The base JavaScript library we are using, ExtJS, follows a unified directory structure that is the same for every application. This means that all application code components are placed inside a folder, named after the actual name of the application, which in turn contains sub-folders to namespace models, views, controllers and stores. To be in line with the functionality of the application, we are going to call it CityApp. Inside this folder we will encapsulate all the components of the application. Figure 1-4 shows how the folder structure for the application should look like once it is complete:

Use this figure as a reference for all your file and folder creation. If you are unsure as to where a certain file should be placed, then come back to this figure and check its precise location.