Deferring Database Creation

When you consider the use-case scenarios we decided to implement in our Elaboration iteration plan, you might wonder how we created a database. After all, the only database- related use case we planned to implement was Open Project Database. But we believed that adding database creation code to the iteration would not address any additional technical risk and it would delay the Elaboration phase.

We chose to use a standard database implementation, one that supported JDBC and the SQL query language. So, we created an SQL script to populate a database. This solution was sufficient for the time being. The script, createdb .sql , used a series of create and insert SQL statements to create a database with a few initial records. We used this script during the Elaboration phase to test code and to ensure that we were meeting our goals.

We started designing the application using the PointBase database that comes with the Forte environment. When we changed to use Rational XDE, we decided to switch the database implementation as well. We decided to use the Cloudscape database, delivered as the JDBC reference database implementation with the J2EE platform. ^[12] For the J2EE 1.3.1 release, we found a useful utility program called Cloudview that let us interact directly with the database.

^[12] J2EE and the Java SDK can be downloaded from http://java.sun.com.

These tools proved to be invaluable in the beginning because they allowed us to verify whether the code we wrote was working. For example:

• Because we implemented only minimal functionality, we didn't yet have the ability to use the PSP Tools code to query the database. Using Cloudview, we performed early versions of the queries that we later implemented in our code.

• During early acceptance testing, Jas and Liz used Cloudview and the scripts Gary wrote to create the databases they needed.

We recommend that you use a general-purpose tool such as Cloudview for the database management software you choose to work with.

An Alternative to the Database

There are different schools of thought about whether you need to design and implement database code during the Elaboration phase. An alternate approach to the one we took is to defer the database implementation until you absolutely need it. In the meantime, you can define the interfaces for accessing the data and create alternate data provider classes. This follows good design practice, which says you should separate the responsibilities between the physical representation of the data and the classes that access the data. ^[13]

^[13] There are several good books that describe the best object-oriented design principles. In this book, we will not address these topics in detail.

By creating alternate data storage classes you might be able to create a simpler system than if you start with a more complex solution, such as a database. For example, for PSP Tools, we might have started by using a simple file-based data store for the project database. This would have worked for a single user , but not for multiple simultaneous users. Later, we would have needed to do some amount of rework when we finally added the database.

However, we had the requirement for multiple simultaneous users, so we implemented the database early in the project. Also, database design and implementation was a major risk for the project's success. None of us had any recent, useful experience with database software. A goal of the Elaboration phase was to prove to ourselves that the database would not be a blocking factor for finishing the project. In the end, it was a relief to have implemented the database early. It was also a good decision to defer writing the final creation and query code because these aspects of the project didn't pose technical risks.

Database Design

It turned out that implementing the database was quite simple. Our data model for PSP Tools isn't complex. Figure 6.10 shows a UML representation of the data in our database.

Figure 6.10. PSP Tools data model

This diagram illustrates the usefulness of UML diagrams. It took about five minutes to capture the information in XDE, and the diagram shows a lot in a small space, for example:

• There is one DBInfo object for the project database. (The DBInfo object records the properties of the database, such as the name , description, and so on.)

• There must be at least one User in every project database, but there can be more than one.

• A project database can contain any number of Tasks.

• Each Task has time entries and defect entries associated with it.

• Every Task is associated with exactly one user.

The diagram could be more detailed or more consistent, but the level of detail was enough for Gary to create a working database and communicate to others how the database was structured. In fact, the createdb.sql script shows that there is a separate table for each of the classes in Figure 6.10.