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.
These tools proved to be invaluable in the beginning because they allowed us to verify whether the code we wrote was working. For example:
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 DatabaseThere 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]
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 DesignIt 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:
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. |