VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering

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

Assessing the logical design's impact on the physical design

The main objective of this section is to list the following ways that a logical design can impact the physical system derived from it:

The following sections discuss each of these design considerations.


Performance considerations include the speed and efficiency with which the system does its tasks. Performance needs to be evaluated from two points of view:

  • The timeliness of activities from the point of view of system requirements.

  • The timeliness of system activities from the users' point of view, both in terms of perceived speed (slow perceived speed can be a frustration factor) and in terms of allowing them to do their jobs appropriately. (You don't want phone calls backing up for an order entry clerk because the system takes too long to approve the current order.)

You must often balance performance against some of the other considerations, because the features that can give better performance often degrade other desirable aspects of the system.If users all have very powerful workstations and the server's resources are limited, for instance, performance might improve if more processing were delegated to the server.

Putting more processing logic on the workstations might compromise maintainability, however, because there would be more distribution problems when a change was needed, because it would be likely that the elements needing maintenance would reside on the users' systems. Improving performance may, however, have a positive effect on considerations of scalability, as described in the section titled "Scalability."


The two basic rules for better system maintainability may seem to contradict each other:

  • Centralize the location of services whenever possible so that there are as few copies of the same software entity as possible (preferably, only a single copy). This centralization means that, if a component breaks, you have very few locations where you need to replace it with the fixed version.

  • Break services into smaller components that have completely well-defined interfaces. Such modularization will keep problems isolated to very specific areas, making them easier to track down and fix. With well-encapsulated, smaller modules, the chances are smaller that a problem will affect a large area of the application and that fixing it will have complex ramifications.

The apparent contradiction between these two rules can be resolved by stating them together as a single, simpler rule:

  • Break services into smaller, encapsulated components and put them all in a centralized location.

This drive toward more encapsulated, more specialized components has been part of the general movement away from the simple client/server (two-tier) Enterprise Application Model toward a threetier and finally an n-tier model. The rationale for such multiplication of tiers in terms of maintainability lies in the following reasoning: If you want to centralize processing, you need to take more processing away from the client (a "thin client"). This would imply at least another tier (a "business services tier" in addition to the more traditional "data tier") on the server.

If you want to break services down into a number of components, once again you multiply the number of tiers as follows:

  • The business tier might break up into several components.

  • The data tier could split into a back-end data tier (representing the database server itself, such as SQL Server) and a business data-access tier (representing customized data access procedures to be used by the data objects). The section titled "Designing VB Data-Access Components for a Multitier Application" discusses data-access component design in more detail.

The method of deployment, or distribution, to users also affects maintainability. If it is harder to get changes out to users, the solution is inherently more difficult to maintain. Therefore, a solution that must be distributed to users on disks and that depends on the users to run a setup routine will be less maintainable than a solution that is implemented as an Internet download, because the Internet download happens automatically as soon as a user connects to the application's Web page.

An even more maintainable solution is one that doesn't depend on any user action at all to effect changes. Such solutions would be contained in tiers that reside entirely on a server. When developers need to make changes, they just replace components on the server without having to require any action from the users.


In the context of VB itself, extensibility means the capability to integrate other applications (such as Visual SourceSafe, Component Object Manager, Visual Data Manager, and many others) into the development environment. However, extensibility is best understood as the capability to use a core set of application services for new purposes in the future, purposes which the original developers may not have foreseen.

The following list details some of the ways that you might achieve high extensibility in your design:

  • Break services into smaller, encapsulated components and put them all in a centralized location. Note that this particular technique for extensibility is identical to the chief technique for ensuring maintainability, as discussed earlier. Smaller components, representing smaller units of functionality, are more likely to be reusable as the building blocks in new configurations. To make the components more flexible, they should be highly parameterized so that their behavior can be controlled more flexibly by client applications.
  • COM components implemented through ActiveX on the server always make for good extensibility, because COM components can be programmed from many platforms. This leaves your system more open to unforeseen uses in the future.
  • If your solution is Web-based and you cannot predict the type of browser that the users will employ, consider using the technology of IIS applications (WebClasses) as described in Lesson 17. Because IIS applications prepare standard Web pages server-side before transmitting them to the client, they are independent of the type of browser used by the client.


Scalability refers to the ease with which an application or set of services can be moved into a larger or more demanding environment. A client/server or n-tier application is said to scale well if any of the following can happen with little impact on the system's behavior or performance:

  • The number of users can increase.

  • The amount of system traffic can increase.

  • You can switch the back-end data services or other services (usually in the direction of more powerful processing engines).

You can look at scalability as a specialized aspect of performance. It should therefore come as no surprise that measures to improve performance might also improve scalability, such as the following:

  • Putting more business-rule processing in the user-interface tier on local workstations. Of course, this measure is usually a bad idea for other considerations (such as maintainability).
  • Using a DHTML application, as described in lesson 17. This provides a more maintainable way to offload processing to workstations. A DHTML application provides an ActiveX DLL component that downloads to the user's workstation when the user opens a Web page with Internet Explorer. You could include business rules in this ActiveX component and thereby put less demand on server resources as more users begin to use the system.
  • Partitioning data access into a data tier (the actual database server, such as SQL Server) and one or more data-access tiers. This will allow the data server to be more or less painlessly switched out, perhaps with only a recompile of the data-access tier to point to a different data-access library or data engine, or maybe even just a change in initialization files or Registry entries.
  • Using other data-access techniques that offload processing from the server to workstations.This would include the use of client-side servers and offline batch processing, as described in detail in Lesson 9.
  • Splitting processing into multiple component tiers. This opens the door to moving these tiers to different servers in the future, thus relieving the load on a particular server.


Optimum availability of a solution means that it can be reached from the most locations possible and during the greatest possible amount of time. Availability is therefore affected by the method of deployment:

  • Local
  • Network
  • Intranet
  • Internet

The best choice for availability depends on the nature of the solution and on the usage scenarios for the solution.
For a desktop application, local availability might be perfectly acceptable. If the users are mobile laptop users, then Internet availability might be the best bet.


Security is the most readily understandable issue of all those mentioned here. For best security, a system's services should be centralized in a single physical location (to simplify administration and give less slack to would-be violators of security). Such a requirement might conflict with availability, scalability, and performance needs.


<< Previous | Contents | Next >>


Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved