The Five Phases Examined

for RuBoard

When you build anythingwhether it's a software product, a house, a statue, anythingyou go through a series of phases or steps that hopefully results in a finished product. The procedure is no different when you build applications. This series of steps isn't something you have to commit to memory and hope you don't forget. On the contrary, it's completely intuitive and is borne of simple logic. Rather than some rigid code that you must always be careful to follow, the five general processes I outlined earlier will likely occur to you naturally as you design databases and build applications.

As far as the actual work of constructing a database application is concerned , you can focus on just the first three of the five general processes. It's during the first three phases that the application is actually developed. Most of the challenges of building database apps lie in these three phases. This isn't to say that testing and deployment can be relegated to the end of the development process. On the contrary, they should occur throughout the process. However, the formal testing phase of a project (e.g., prerelease or beta testing) usually occurs once the software is pretty far along, and, obviously, deployment (release to manufacturing, or RTM) occurs after the software is thought to be complete.

Analysis

The first application development phase is the analysis phase. Here you analyze what your application needs to do. You begin with a general statement of purpose, then qualify the statement with specific functions that the app must perform or allow the user to perform to serve its intended purpose. It is during the analysis phase that process modeling occurs. Process modeling amounts to describing the underlying business processes, resources, and data flows necessary for the application to fulfill its purpose.

Design

The second phase is the design phase. Here you turn the analysis you performed in the first phase into a logical design. You translate the business processes modeled during your analysis into logical application and database design elements. This logical design describes what you're building in specific terms. The focus shifts from what the application will do to how it will do it. Here, you determine the application and database components necessary to implement the business process models defined in the analysis phase. One of the ways you do this is through logical data modeling and E-R diagrams. The end result is that you'll develop a separate design for each layer of your application.

Construction

The third database application development phase is the construction phase. Here you turn the logical design you developed during the design phase into physical objects. This means that the logical database design you created will be translated into real database objects. Likewise, the application design you produced during the design phase will materialize as forms, code, services, components, and other program objects.

The last two of the five phasestesting and deploymentare mostly postdevelopment concerns, so I won't get into them much here. As I said, each can and should be ongoing in nature, but they are still distinct phases of the overall process. Often, they result in a return to the first three phases anyway (through bugs being detected or requests for enhancements from users), so I'll only touch on them in our discussion of database design.

On the Complexities of Database Development

The process of developing database applications is straightforward and intuitive. It's not unlike the approach one takes to building any other type of application, regardless of whether the app accesses databases. This may seem a bit simplistic, but it's from this perspective that I approach the task of developing database applications.

The difficulty that arises when applying this basic methodology to SQL Server application development is that there are at least two distinct pieces to even the simplest SQL Server application: the server portion and the client portion. Moreover, the objects that end up being created on the server are foundational to the application. That is, it's advantageous, if not mandatory, that they exist before the application itself is constructed. Also, the app won't work correctly if the database has problems. This duality doubles the work necessary to construct robust applications. Not only must the application be analyzed , designed, and constructed , the database must also go through the same process. In addition to this client- and server-side work, there is also the issue of getting the client and server to communicate with one another. Sometimes this is a task in and of itself. And adding middleware to the mix makes things even more interesting.

There's no easy way to completely remove the complexities surrounding database applications. CASE tools help, but applications must still be developed by developers. Modern database apps are complex, multilayer pieces of software. It's understandable that creating them requires some amount of expertise.

This chapter takes you through the analysis, design, and construction phases as they relate to databases. Getting the database design right is every bit as important as getting the application design right. If either one is faulty, your app isn't going to work very well.

Database Theory Applied

Something you'll notice about this chapter is that I consider database design and database application design to be intrinsically linked. This seems obvious enough to me, although there are those who feel the two are completely different disciplines. From the pragmatist's point of view, the process of designing a database is foundational to the process of designing applications that use it. One certainly affects the other. I've never designed a database that wasn't intended to be accessed in some way by an application.

You have to remember that the database is just a means to an endit's your way of meeting a customer's needs. Similarly, the client application functions as the conduit between the user and the database server. It, too, is just a tool for servicing your customer. Both the client app and the database server must work together to produce solutions that your users find acceptable.

In this chapter I'll take you through the process I use when designing database applications. I'll base the discussion on a solid grounding in database theory, with the emphasis on the task of constructing real applications.

Defining the Purpose of the Application

The first step in designing any applicationdatabase or nondatabaseis to define the purpose of the application. What is the application to do? An application's statement of purpose should consist of a single sentence that includes the subject, the verb, and the verb's object. The subject is always the application, such as "This system" or "The RENTMAN System". The verb describes what the application is supposed to do, for example, "The system will manage" or "The RENTMAN System will facilitate". The object denotes the recipient of the application's actions. For example, "The system will manage summer camp registration" or "The RENTMAN System will facilitate rental property management."

The statement of purpose needs to be as simple and concise as you can make it. Don't waste time with flowery language or needless details. For example, avoid "for the organization" and "for the client" at the end of the statement because they're implicit. Also, try to avoid compound statements and conjunctions. Reducing the sentence to its simplest possible form will help keep you on course as you further describe what the app is supposed to do. You can expound more on your app's purpose when you later define the functions required to accomplish it.

Once you've developed a statement of purpose for the application, show it to the potential users of the new application and see if they agree. Don't be surprised if they don't understand your brevity, but try to get them to sanction your statement as accurate and complete. Although the statement will not enumerate the specifics of the application, it still needs to be broad enough to encompass the overall purpose of the application. Assure your users that the precise functions of the application will be addressed in a separate step. Get their thoughts on what they think those functions should be.

Defining the Functions of the Application

Once the statement of purpose is in place, it's time to determine the application's prerequisite functions. What does the application need to do to accomplish its statement of purpose? Try to keep this to no more than a handful of major tasks , if possible. It's a great idea to develop these items using an outline. These functions should further define the application's statement of purpose, not go beyond it. Follow the same three-part format you used with the statement of purpose. For example, "The RENTMAN System will facilitate rental property management":

• It will log and maintain property leases.

• It will track ongoing property maintenance work.

• It will generate tenant billing information.

• It will provide historical information on individual properties.

Make sure you cover all the major functions of the application, but don't overdo it with excessive detail. Also, be sure that the tasks you list don't overlap. Don't list a task that's already covered by another item on the list.

Designing the Database Foundation and Application Processes

One of the first things you discover about database design is that there's a lot more to it than merely designing databases. Business process modeling, E-R diagrams, and logical data modeling all play a part in the design process. You can think of the steps from business process modeling to constructing database objects as a continuum. Beginning with a 30,000- foot view of the business processes that will compose your app and zooming all the way down to individual database column definitions, you progress from the general to the specific. You progressively refine your understanding of the app's purpose until you're ready to translate that understanding into the app itself. This progression of refinement provides a systematic method of transforming the conceptual notions of what it is your app is supposed to do into real-life program elements.

The actual work of designing a database is not as arduous as it may seem. It begins with process modeling and ends with designing the physical objects that will make up the database. In this chapter we'll reduce database design to these three steps:

1. Document the business processes necessary to accomplish the app's required functions.

2. Diagram the entity relationships necessary to service these processes.

3. Create the logical database design necessary to implement these entity relationships and business processes.

See Figure 5-1 for an illustration of the correlation between the five application development processes and these three steps. Once you've developed your application's statement of purpose and derived its critical functions, the remaining analysis and design work boils down to just these three steps. You begin by modeling business processes that correspond to the functions you defined, then you diagram the entity relationships necessary to support those processes. You finish up by translating the E-R diagrams and business processes you developed into a logical model of your data. It's this logical schema that will be used to build your database during the construction phase.

Figure 5-1. A model showing the various elements of the five application development processes.

The progression from process modeling to logical data modeling needn't be done manually. CASE tools are extremely capable at these sorts of things. As you'll soon see, they can help simplify the development process even further.

CASE Tools

I suppose I should begin the discussion of CASE tools by saying that I don't believe that CASE tools are appropriate for every development project or that they will ever replace adequate planning or software craftsmanship. On the contrary, because they're computer-based, CASE tools have the same weaknesses that any other kind of software hasthey do what you tell them to do, not necessarily what you want them to do.

I also happen to believe that CASE tools that attempt to automate every aspect of the development process get in the way of proficient application con struction. Rather than aid in the process, they hinder it by attempting to automate things that cannot or should not be automated. Like George Jetson and his computerized treadmill, developers and modelers spend more time recovering from this overautomation than they would have spent had they not automated things so much in the first place.

As with anything designed to save time, you can reach a point of diminishing returns. When this happens, it's time to get back to the basics and focus on automation that is a help rather than a hindrance.

The role that CASE software should play in database development is that of a tool in the modeler's toolbox. Tools require skill to use. They also do not think for you or plan how you should approach solving problems. They merely help you more readily perform tasks that you could probably perform through other means. This is the ideal role for CASE tools in application modeling. No matter what tools you use, you still need to have a basic understanding of database design concepts and the workings of your back-end DBMS to develop optimal database applications.

Because much of the exploratory work that must be done to eventually arrive at a database design amounts to modeling real-world objects, it only makes sense that CASE tools should somehow figure into the mix. Today's CASE tools have come a long way from the pioneers of yesteryear. Without a doubt, it's now safer and faster to utilize CASE tools to assist in the design process than to do everything by hand.

By allowing us to model objects before they actually exist, CASE tools allow us to perform "what if" analysis on design elements before they become reality. Also, CASE tools can assist with the design process itself, and can even warn of potential problems with the design decisions we make. By constructing a model of what we want to do, we give the CASE tool the information it needs to help us do it. Some types of modeling to which CASE tools are particularly well-suited are:

Business process modeling Applications consist of interrelated processes that perform functions essential to the app. Business process modeling involves formally diagramming those processes and how they interrelate. There are CASE tools with specific support for process modeling. Computer Associates' BPwin is one example; Microsoft's Visio is another.

E-R modeling E-R diagrams are considered indispensable by most data modelers and designers. They provide a method of separating the logical representation of data from its physical implementation. E-R diagrams facilitate thinking of data elements in terms of the real-world objects they represent. There are many CASE tools dedicated to E-R modeling. Computer Associates' ERwin is one such tool; Embarcadero's ER/Studio is another.

Relational data modeling Despite the popularity of E-R modeling, it represents only part of the relational data modeling process. E-R diagrams are one way of expressing database relationships, but there are many others. There are a number of CASE tools that go beyond simple E-R diagramming and address the larger task of designing entire logical database schemas. Sybase's PowerDesigner is one such tool; CAST Software's AppBuilder is another.

In this chapter I'll show you how to use CASE tools to model real-world applications and how to transform these models into database and application objects. As Figure 5-2 illustrates, physical database objects evolve from logical data models. Logical data models are in turn borne of E-R diagrams, and E-R diagrams are derived from business process models. Business process models, for their part, embody the application's purpose and key functions. The progression from defining an application's purpose and essential functions to constructing it physically represents a gradual evolution in our understanding of what the application is supposed to do.

Figure 5-2. CASE tools help transform ideas into physical database and application objects.

for RuBoard