Lab 1: Introducing the STUpload Application

The purpose of this lab is to introduce the application that you will develop throughout the labs in this course. You will be presented with the customer requirements and are encouraged to think about the solution in terms of the MSF models.

Customer Requirements

Your customer, StockWatch Data Services, Inc. (SDS), is an information services company that specializes in providing stock market information to brokers and fund managers. SDS receives a large volume of data every week in the form of ASCII text files automatically downloaded from mainframe computers around the world. Their request is for an application, which will allow operators in the company data center to load the data contained in these text files, perform visual verification that the data is correct, and upload verified data to a central database server. The application must meet the following requirements:

• The application will be deployed on a Microsoft Windows NT 4.0 network accessible by up to 50 users, all of whom will be working from desktop computers in the data center.
• Data downloaded from mainframe computers around the world will arrive on the operators' computers in the form of text files attached to electronic mail messages. The text files have the file extension .dat.
• Each file will contain data from one particular market, for example NASDAQ or the London Stock Exchange, although each file might contain data for a number of funds.
• The text files will be in standard 8-bit ASCII format and will consist of one header row detailing the source market and the file date, and any number of data rows in which the fields are delimited by fixed column widths, as illustrated in Figure 1.9.

Figure 1.9 The format of the ASCII download file

• The text files often contain duplicate lines, lines with zero price values, or lines containing corrupted data, and the application needs to ensure that such lines are filtered out, and only valid data lines are loaded into the application.
• The application should allow users to load the text file, and then display all of the fund names contained in that file in a list.
• When the user chooses one of the fund names, the price data for that fund will be displayed in a line graph for visual verification that the data appears correct.
• Once the operator is satisfied that the data contained in the file is accurate, he or she can upload it to the central database server.
• This server runs SQL Server 7.0, located within the data center domain.
• This server will be handling updates from all of the installations of our application, as well as requests for data from other applications.
• To each row appended to the database table, two additional fields will need to be added to enable an audit trail of the uploaded data: one to record the upload date, and another to contain the name of the user who uploaded the record.
• Duplicate records should not be allowed on the table.
• Once the data from a text file has been loaded into the application, it can be saved in the application's own document format.
• The application documents will be retained as an archive.
• The operator will be able to load any number of .dat files into the application so that several text files can be merged into one upload transaction and one archive file.
• The customer has specified that this is to be the first of several applications that will append records to a database.
• The customer has requested that the application modules that update the database be designed for maximum reusability within a Windows NT environment.
• The application will allow the user to query the central database, specifying a fund name, a start date, and an end date for the query.
• The user will be able to browse through a read-only result set—for example, to ensure that the data he or she is about to upload does not already exist on the server.
• The existence of a live connection to the database will be indicated on the UI.
• If the database is offline, the user will still be able to load and view text files and save them as application documents, which can be reopened and uploaded when the database connection becomes available.

Steps Toward a Solution Design

Consider how the concepts you learned in Lesson 1 might help you think about the design of your solution from both the logical and the physical design perspectives.

Logical Design

Think about who is going to use the application, and where. The client has initially specified that about 50 users, all in the same Windows NT domain, will be uploading data to a central server. This scenario suggests that you should be thinking in terms of a fairly small-scale client/server application. However, you might consider asking the client about their expansion plans. Is this application likely to grow so that it is distributed across more than one department, or across more than one site? Is the usage of the application likely to grow to the point where insufficient resources (such as concurrent database connections) start to affect the performance of the application?

You might also ask the client if they foresee a need to extend the application to include a Web-based interface. If the company is already running an intranet, you might ask whether it might not be better to host the application inside a browser to allow staff to access the application from any computer anywhere. This option could also simplify deployment and upgrade issues.

You should also consider the business rules that the application is to implement. Consider whether the business rules need to be implemented in their own middle-layer component tier, or whether they can be integrated into the presentation tier or the data tier. The business rules in our scenario are few. The business rule specifying that duplicate rows are not allowed on the database can be taken care of by a primary key constraint—a rule specified for a table that won't allow the addition of duplicate rows to the table. The requirements that relate to the "cleaning up" of garbage data and duplicate lines from the text files can easily be implemented in the client application.

SDS decides that, given their budget and their business projections, an application based on a client/server model will be most suitable for their present requirements. They agree that a two-tier architecture is an appropriate model. However, they reiterate their requirement that the database update modules should be designed for maximum reusability, with the possibility of future expansion in mind.

To meet this requirement, you design the database update module as a set of cooperating components with clearly defined interfaces describing services that can be used by other client applications. You do not need to implement these components as a separate tier—they can be installed as part of the desktop ap-plication and distributed as application DLLs. In the future, however, they can be reused as part of the middle tier of a distributed application.

Physical Design

The physical design of your solution is what comprises the labs in this book. Your client might be surprised that you are using Visual C++ to implement the solution. They might feel that you could develop a solution that is just as adequate, and that you could do so more quickly by using Visual Basic.

Visual C++ does have many features that, in the hands of an experienced C++ developer, allow rapid application development. For example, the MFC AppWizard will be used to generate the basic structure of the client-side application, onto which you will be able build your application-specific functionality. The visual design features of Visual C++ will enable you to quickly develop the UI and link user-interface elements to code. MFC provides efficient, easy-to-use data structures, such as variable-length strings and object collections. The ADO data control can be used to visually design a database query screen in minutes. ATL can be used to implement the reusable component-based database update module that the client requires.

The overall result is that Visual C++ enables you to rapidly develop applications and components that are smaller and faster than those built with any other Windows development tool. Components built using ATL are quite efficient—ATL was created to meet the need for extremely lightweight components in the Internet environment. This means that your clients can be sure that the database access components you will build for them using ATL will be suitable for deployment in future Web-based applications. Also, the use of COM means that the services that the components provide will be available to a wide range of clients on a variety of platforms.

STUpload Application

In this first lab, you will simply get acquainted with the STUpload application. Each lab throughout the course will build upon the previous lab so that when you are finished with the course, you will have a complete working application that meets the specification of your imaginary customer, SDS. Your Chapter1\ Lab folder contains the finished version of the STUpload.exe file and the Chapter1\Data folder contains a sample data file Ch1Test.dat, which contains data for you to load into the application and to upload to the database server.

The recommended procedure is to build the STUpload application in the order presented by each lab. Follow the labs in numerical order. Save your work and use it in the next lab to continue developing the STUpload application. If you do not complete a lab, you can start the next lab with the project in the \Labs\Labn\Partial folder, which will allow you to proceed from the appropriate starting point.

You should check your work against the \Labs\Labn\Solution folder project after you complete each lab.

To run the STUpload application

1. Double-click the STUpload.exe application icon in the Labs\Lab1\Solutions folder. The STUpload application opens.
2. Explore the application menus. Hover the pointer over any unfamiliar toolbar buttons to learn their function.
3. On the Data menu, click Import.
4. Use the File dialog box to locate the Ch1Test.dat file in the Chapter1\Data folder. Click the file and click Open to import the text file in the STUpload application.
5. Read the message box that reports the status of the import, and then click OK to complete loading the file.
6. The Select Fund window appears. Click the ARSC item to view the price history for the ARSC fund, as shown in Figure 1.10.



Figure 1.10 The STUpload application

7. On the File menu, click Save. Save the file as Lab1.stu in the Chapter1\Data folder.
8. On the Data menu you will notice two additional items, QueryDatabase and Upload. These options will not work on your machine until you have configured the application's connection to the database and registered the data Upload COM component on your machine. You will perform both of these tasks in the course of these labs.
9. Close the STUpload application.