Applying Software Design Techniques to the Web
By Scott Baker
The days of static Web pages are coming to an end. More and more developers are populating the Internet with increasingly complicated sites, built with the help of scripting languages, dynamic HTML, Java applets, and a number of other complex and esoteric technologies. As Web pages become more like multifaceted Web applications, it's crucial that anyone creating large Web sites learn solid software design techniques.
Software design is not a new term, although traditional software programmers may be more comfortable calling it software engineering. The idea is the same—break down a problem, model the possible solutions, and create the final application. On the Web, where development cycles are incredibly short and sites often change from day to day, it's especially important to build well-designed applications that are efficient and can be updated with ease.
The Process
You can apply software design techniques to your Web application at the project's conception. In fact, the software design process should begin the moment your company (or your customer) provides you with a description of a desired Web product. Your objective at this point is to break down the end product into individual pieces that will be used to generate a solution. In the programming world, these individual pieces are typically objects, packages, and modules. On the Web, the individual pieces are often scripts and HTML documents.
From there, you should create a model that outlines the various interactions between the pieces of the application. As a Web developer, you've probably already applied modeling techniques, whether you knew it or not. Web sites generally have some hierarchy that imposes a specific control path for a user to follow. The flow of control that you create with page linking, for example, is a high-level model of the Web solution.
Once you have a model in place, you can begin to address specific platform constraints. And once you've made those decisions, you can massage the design into a solution that is built on simplicity and employs a sense of modularity. The end result will be a sound, robust Web solution delivered to the customer for use with the targeted Internet/intranet community.
Dividing the Application
Division is the act of separating an object into parts, sections, or groups. This is an important step in the design process, because here you break the solution into the individual components that you'll implement. All too often, developers feel overwhelmed by the depth of their assigned projects, but dividing the application creates mentally digestible components that can be addressed individually. In other words, divide and conquer. The developer can then attack each component as a separate object and, upon completion, combine them with the remaining objects to construct the solution.
To illustrate the design process presented in this article, I've included an example based on Active Server Pages (ASP) and the Visual Intercept Software Developers Kit (SDK) from Elsinore Technologies, where I'm a lead developer. Visual Intercept is a software package that tracks bugs, change requests, and other incidents related to software development. This example addresses satellite managerial needs of Simian, a fictitious company with managers who are constantly on the go. The Web solution lets those managers log on to a Visual Intercept data source and access the incidents related to their assigned projects. These incidents are presented in a table and separated by their identifier, subject, status, and the user to whom the incident is assigned.
After receiving the specifications for the example Web solution, I easily could have written it all in one HTML file. But doing this would create a nightmare for maintainability and support. Instead, I identified the responsibilities of the solution, and used those as a basis for separating the code into individual files. For instance, the default.asp page is responsible for presenting the necessary components to facilitate the log-on process. The prLogon.asp page processes the data and attempts the log on. The fmIncd.asp page handles all efforts associated with retrieving and displaying the incidents related to the manager's project. Finally, by using an include statement from within the fmIncd.asp page, a prIncd.inc file is incorporated. The prIncd.inc file contains the server-side code that is used to fetch the incidents and present them in the table view. From a design standpoint, this division of labor is efficient, organized, easily maintained, and provides an outline for the solution's model.
Modeling
As I mentioned earlier, your solution should be based on a model. In Web development, there are three types of modeling to consider; they are the architectural, code-level, and data-modeling stages.
Architectural modeling shows you what the solution should look like. Code-level modeling describes how the solution should be built. Data modeling specifies how the solution will transfer or receive data. Using these three stages lets you create a solution that's not only consistent internally, but with references between itself and the outside world that appear seamless.
Architectural Modeling. During this phase, you'll decide on naming conventions, identify the pages that will comprise the end solution, specify how these pages will interact (both internally and externally), and generate diagrams, charts, and sketches that outline the solution.
For the Visual Intercept project, I sketched the relationship the pages have between the client and the server (see
Figure 1). Just by looking at the figure, developers can grasp the server-side requirements, in that a copy of the Visual Intercept Software Developers Kit and a valid Visual Intercept Data Source must exist for this solution to work.
Code-Level Modeling. At this stage, you must identify the combination of languages you'll use. (Traditional software programmers often work with only one language, but on the Web, developers often need to use a number of technologies, including HTML, VBScript, ASP, JavaScript, Java, and so on.) You'll also specify the script-level naming conventions, establish Web-object boundaries, and select the components and third-party products that you'll need.
For my project, I decided to build the solution with ASP and develop it with Microsoft InterDev. I also decided to name each page according to its responsibility and bind the Web pages used to one and only one task. Therefore, I resolved that pages displaying data would be prefixed with "fm," such as fmIncd.asp. Pages that process data from those pages that display it will contain a "pr" prefix, such as prIncd.asp. And pages that contain scripts shall be named mnemonically and include an ".inc" extension, such as prIncd.inc.
When scripting, I decided that I would use a modified Hungarian notation, where I would prefix all integer variable names with "n," all long variable names with "l," and all Visual Intercept object names with "vi." Finally, the solution will need a set of third-party Component Object Model (COM) objects. These objects are hosted through the Visual Intercept SDK, and provide an interface to the Visual Intercept data source.
Data Modeling. In the final stage you decide how to transfer data. Here, you must answer questions about the information you'll need to gather and store. Also, will you need to use cookies? Will you need to gather credit card numbers? Will you need to use a transaction server? Obviously, more questions may surface, but these examples should get you started.
My solution lets users post client-side actions that are handled with server-side scripts. These scripts should interact with the data source, via the SDK, and the modified documents that are sent down to the client. The internal SDK COM objects will be used when working with the SDK to extract data from the source. Garbage collection for those objects will be performed internally by the SDK when the application goes out of scope.
Platforms and Constraints
Modeling produces a side effect—constraints. Identifying constraints is one of the most overlooked software design issues. Simply put, every design decision that you make impacts the end result. For instance, your decision to use ASP means that your server must support that technology (which in turn imposes many other hardware and operating system constraints). Additionally, the scripting language you choose may limit your solution to supporting only one type of browser. I often argue that there are more constraints imposed on developing Web solutions than on a typical desktop application. Here are a few constraints to consider:
Know Your Audience. If you're creating a Web solution that targets the average home user, keep in mind that many of them will access your site at 28.8 kbps. A graphics-laden solution could result in the loss of impatient users. If your users have handheld devices or laptops, this may also influence your design. There's nothing worse than hitting a site that's built for a 1040x760 resolution screen on a machine that only allows 640x480 pixels.
Consider how much you want the browser to constrain your solution. For example, selecting VBScript effectively ties you to Internet Explorer. That might be a reasonable constraint on an intranet, but is likely to be too confining on the public Internet.
Commit Your Company to the Model. Although your company (or your customer) will specify the end application, remember that you drive the design. Bringing your customer in during this design phase, when possible, is a good idea. Not only will they see progress, but they may also be able to identify more constraints that you may have missed.
Identify Your Solution's Life Span. Knowing how long and where the solution will exist will let you address maintenance requirements, operating efficiency, and reliability issues.
One last note on constraints: Identify them prior to pouring your heart and soul into your solution. It is incredibly disappointing to be halfway through the development process and realize that your customer isn't happy that the scripting language you chose supports only one browser.
The Massage
After the model is complete and you've accounted for your constraints, start massaging the plans into an actual solution. As you examine the following issues, you may need to change your plan accordingly:
Reliability. Is your solution complete and consistent? Does it work in all cases and provide meaningful messages for failures?
Efficiency. Use metrics like load time, graphics size, and media dependencies to measure the overall efficiency of your application.
Maintainability. Earlier, I suggested that you should identify your solution's life span as a constraint. As solutions get larger and more costly, the need for a long service lifetime increases in parallel. Recognizing the principle of maintainability at the initial design stage and addressing it during development ensures that you can easily upgrade and modify the site.
Usability. There are many issues that can affect usability, but for most Web solutions, the design of the interface is an important component. The interface influences other design decisions, such as graphics formats, audio and media types, and whether to use embedded scripting languages.
Scalability. This addresses the performance of your solution as your needs increase. Accounting for this factor will let your application grow with ease as your user base and traffic volume increase.
Despite all the requirements, constraints, and things to remember, it's important to remember simplicity. Albert Einstein said it best: "Things should be made as simple as possible—but no simpler." It may seem impossible, but try to create a solution that is simple, yet still incorporates the five attributes into the design.
One hint for accomplishing this is to conceal code and data in common libraries. For example, I often place routines in separate files that other scripts refer to with server-side includes (SSI). By using SSI, you can alter the code in the common file without having to modify all the files that refer to it. Not only does this approach keep the size and contents of my Web pages to a minimum, but it also imposes modularity and code reuse. This approach also reduces the amount of disk space for the solution because many pages refer to the same code snippet. More importantly, hiding information keeps the solution simple and maintainable.
What About Objects?
Most existing Web solutions are action-oriented. The user accesses the site, fills out a form, reads some text, hits some hyperlinks, and so on. Regardless of the capabilities offered, solutions typically follow a static sequence of events. Action-oriented design makes it difficult to reuse code between projects because it's normally content-centric and optimized for one specific solution. It can also inhibit scalability and maintainability. Often object-oriented design is a better choice than action-oriented design. Keep in mind that you won't remove action from the solution. Instead, you'll organize your design to model the data inherent in your site and let the actions be a function of the data, not the other way around.
A complete overview of object-oriented programming (OOP) is beyond the scope of this article—although many of the techniques I've used fall into the category of OOP. There's a wealth of literature available about object-oriented design and programming. If you want to pursue it further, you can read Data Abstraction and Structures Using C++ by Mark R. Headington and David D. Riley. Also, this month's "Java@Work" column covers basic and intermediate object-oriented design practices.
Solid software design techniques can be a major asset to Web developers. Well-designed code can help you in three areas: efficiency, maintenance, and reuse. Furthermore, a firm methodology offers a design mentality that you can apply to any endeavor. It's up to you to embrace these techniques, apply them to your efforts, and spread them to those who might otherwise plunge ahead without a plan.
(Get the source code for this article here.)
Scott is a lead developer for Elsinore Technologies (www.elsitech.com), where he designs the Software Developers Kit and integrates incident management into various Microsoft applications. He is also a computer science graduate student at Columbia Southern University. He can be reached at [email protected].
