VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

VB .NET - Learn Visual Basic .NET

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 1

Case Study: Sales-Order Entry System

Your company wants a new order processing system that will make available data from its legacy corporate mainframe system to users in a networked Windows NT environment. Eventually (exact timetable is uncertain) the legacy database will be converted to SQL Server.

Individual users will have state-of-the-art workstations with the fastest available processors and a lot of memory. Management anticipates high growth for the system, both because business itself will increase, creating the need for new data-entry personnel, and because users from other departments will begin to use the system as the business operations become more integrated. Marketing, finance, and accounting groups (and possibly others as well) will access the same data at some point in the future, and their exact needs are unknown at the moment.

Again, management has not decided at what point in the system's development that the cutover from the legacy database storage to SQL Server will happen.


The major concerns for this scenario seem to be scalability, availability, and extensibility, with perhaps a secondary need for good maintainability. Scalability is an issue, because rapid growth in the number of users and connections could overwhelm a single server before management has a chance to upgrade hardware to keep pace with demand.

Availability is also an issue, going hand in hand with scalability, because the business objects implemented by this system will need to be available to growing numbers of new users in the future in different locations.

The system must be extensible as well, because different groups of users in the future may have different needs that require different user interfaces and perhaps even enhanced sets of business rules.

A secondary requirement would then be maintainability, because the dynamic nature of the environment implies that there may be numerous far-reaching changes and enhancements to the system in the future.


Because of the high need for extensibility and maintainability, you will definitely want a multitier application divided into at least the following components:

• A client-side user interface tier, which you might consider implementing as a DHTML application over the corporate intranet. This would enable you to offload some businessrule processing from network servers to those high-powered client workstations.

Less server-side activity would improve scalability, because increases in user population would create less of an increase in demand on server resources.

The DHTML solution would at the same time preserve maintainability, because the DHTML application download could be updated in the server deployment files and automatically would download the updated files when users connect with their browsers. Finally, the DHTML client-side interface could be split into several versions for different user groups, and thus provide high extensibility as well.

• One or more business logic tiers, which may split in the future depending on the needs of new groups of users. This would enhance extensibility. The business logic tiers could be implemented as out-ofprocess COM components for best maintainability and extensibility. When business logic required a change, you could just swap out the old components for their new and improved counterparts.

• A data-access tier separate from the dataservices tier. This would help insulate the business logic tiers from changes in the back-end data-services tier when the cutover from the legacy data services to SQL Server happens. You could write the dataaccess tier as a COM component exposing a set of data-aware object classes. The actual data-access technology would be private to the object classes, so the business logic clients would need no change if the data-access technology changed when the data-services tier changed.

• A data-services tier, which would initially be the legacy database engine and would at some point be replaced by SQL Server. It would be best to implement as few data integrity or business rules at this level in the legacy database engine, because any such implementation would have to be re-created in SQL Server when the cut-over happened.


<< Previous | Contents | Next (Chapter 2) >>


Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved