CarroSELL Site Launch

Just about every person that has ever traveled by plane has stood in front of a carousel waiting for their luggage. CarroSELL realized that a captive audience is the best kind of audience and so got in to the business of selling advertising space on airport carousels.

Roles

System Architect
Database Designer
Web Developer

Technology

Active Server Pages (ASP)
Microsoft Visio 2000
COM
Microsoft Visual Basic 6.0 (VB)
DCOM
Microsoft Visual Interdev
DHTML
Microsoft Visual SourceSafe (VSS)
JavaScript
XML
Microsoft SQL Server 2000

Project Description

I usually follow a top-down approach when architecting a new system. In the following paragraphs you will see that I start with a rough outline of a system which I repeatedly refine until there is sufficient information describing each part of the system such that the actual programming of the system can begin.

My first step in designing this application was to understand how CarroSELL conducts business. The type of information gathered at this stage is very high-level, but it does identify major roles and processes. Typically, a flowchart (below, left) is sufficient to bring about agreement on what the major processes are.

Each of the major processes identified were further scrutinized with use cases (below, right). The use cases helped identify what people would use the system, the actions they would perform, and the objects on which these actions would be performed. The key to use cases is that they describe actions using the language of the business making them easy to explain to the end users. This is particularly important because the end users are the best resource for determining if a process is being modeled correctly or not. Typically, several dozen use cases are required to adequately describe a system.

Having identified the tasks that people would perform, it became possible to construct a site diagram (right). The site diagram was the first view of how users would move from screen to screen and what actions they would be able to perform on each screen. Each box shown on the site diagram represented a screen in the application. The use cases and the site diagram formed the basis of the system architecture.

Now that the screen flow has been determined, the actual data fields for each screen were decided upon. Combining the site diagram with the data fields resulted in screen mock-ups. Screen mock-ups were very valuable for identifying errors and omissions from previous steps as well as for getting the final go ahead from the end-users.

Looking at the screen mock-ups revealed that the application is made up of a few different types of screens. For instance, entry to most of the features of the CarroSELL application starts with a search screen. The search screen (right) is typical of the search screens used throughout the application and includes features such as filtering by a particular field; searching based on text entries; displaying

detailed yet compact search results; sorting by clicking on a column heading; and hyperlinking from the results to pages with more detail about the item in question.

Details about an airport, terminal, carousel, client, and other items are entered in what are referred to as entry screens. The screen to the right is one of the more complicated entry screens. Notice that the screen is broken down in to scrollable sections so as to keep the information manageable. To add or edit one of these sections the user clicks a button that brings up a pop-up window with fields specific to the section. Once the information has been edited and saved, the pop-up window is closed and the information on the parent screen is updated. Such interactive features are made possible through the use of DHTML and XML.

Up to this point the development process had focused on the end-user. Now that the end-user's needs had been met it was feasible to begin work on the database design. A good database design is a reflection of the screen designs and the business processes and, as with the other phases of this project, is an iterative process. The many steps included capturing all the fields as represented by the screens; adding fields not on the screens such as date stamps; determining field types and sizes; and applying normalization rules.

At this point there was enough documentation that my role could switch from system architect to lead web developer and my team of web developers could proceed with the coding effort. I realized that it was inevitable that the design would be continually tweaked and small modifications would be introduced by CarroSELL, but I was confident that the thoroughness of the previous steps would ensure that changes would be minor and manageable.