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
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."
Maintainability
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.
Extensibility
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
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.
Availability
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
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.
