Beginning the Elaboration Phase

Before the Elaboration phase, Chris and Gary explored some of the technologies they would be working with. They met several times to discuss how PSP Tools might look, what the database needed to do, the tools they wanted to use, and so on. Now it was time to act on the decisions they made.

Which Java Platform?

We could use any one of several languages to develop PSP Tools. We knew we wanted one that would allow us to deploy to as many customers as possible, which meant we needed the program to run on many different computing platforms. We chose Java mainly for this reason, and for the fact that we were comfortable with programming in Java.

Java is more than a language. Sometimes we feel that if you create an acronym of any three or four letters starting with "J" you have identified yet another Java- related technology (for example, JDBC, JNI, JNDI, JMS, and so on). Simply put ” Java is BIG ! Our first task was to decide what parts of the Java platform to use.

If you stick to just the Java platform, the options for building GUIs (graphical user interfaces) are Swing and the more basic AWT (Abstract Window Toolkit), a graphics toolkit. The Java Swing components are designed for building GUIs for desktop applications, while AWT requires you to do more work. Many people have concerns about the performance of the Swing components , but we felt that performance wasn't a major issue for the PSP Tools user interface. Other graphic toolkits are available, but each would require additional startup time and would require us to distribute an additional library with PSP Tools. Swing seemed to be a good choice.

When we started PSP Tools, the Java 1.4 platform was in Beta testing. Some of the new features might have been useful, but we chose to use Java 1.3.1 instead. We know that Beta software is likely to change and that it is not as mature (that is, reliable and stable) as released versions of the software. In general, we recommend that you not base your product on Beta versions of any software or tools unless it is impossible to deliver your product without it . We think this is just a matter of applying common sense, yet it is amazing how many projects have Beta-quality or early releases of software on their list of critical needs in order to deliver their own product.

What About the Database?

The database was the other important technology we needed. The Java platform helped us here with the Java Database Connectivity (JDBC) API that is part of the Java 2 Enterprise Edition (J2EE) platform. JDBC gave us a standard, well-defined way of working with a database with Java. And, the J2EE distribution comes with the Cloudscape database DBMS as a reference implementation. In theory, if we were able to get the program working with Cloudscape, using only the JDBC API, we should be able to easily slide in a different DBMS in future releases. So, J2EE version 1.3 was our choice for the database technology.

Other Development Tools

We (Chris and Gary) decided to use two other tools at this point in the project. Rational ClearCase was a simple choice for our version control needs. We were both familiar with it and it was available to both of us on at least one of our computers.

Like Java, ClearCase is big. But once you set it up, it is very easy to use the few ClearCase features you work with regularly. It takes a little more effort to perform some of the advanced operations with ClearCase, but knowing those operations are available when you need them does bring development teams peace of mind.

Neither Chris nor Gary is a ClearCase administrator. We enlisted the help of one of the Rational ClearCase administrators to set up a VOB (versioned object base) for our project. The VOB is where all versions of a system, or part of a system, are stored. Once you have the VOBs you need, each team member who needs access to the files sets up a view onto the VOBs. The view selects the appropriate versions of each file based upon a specification, called a configuration specification . ^[1]

^[1] For more information on ClearCase, see the Rational Web site, www.rational.com, or look at the book Software Configuration Management Strategies and Rational ClearCase by Brian White.

ClearCase was overkill for PSP Tools. Yet, once it is set up, it is just as easy to use as any other version control or configuration management software tool. We had confidence that regardless of how our project grew, ClearCase could handle our needs and we wouldn't have to worry about switching tools.

The second development tool we selected was the Forte for Java Community Edition IDE. We already discussed the selection of IDEs in Chapter 6 and will not repeat it here.

Source Code Structure

We wanted our code structure to be as simple as possible, but no simpler. It should be easy to explain what the different packages and files contain, and it should be easy to remember the description.

We organized the PSP Tools code in two ways. The first was in terms of layers. Although the product was simple and didn't require a complex architecture, we wanted to have a good base for future additions. We chose to think of the application in three layers, shown in Figure 7.1. The layering scheme is simple, but it gave us an initial cut at where we needed to locate the different packages we created and the classes that went into the packages. Initially we were not sure whether there would be a single package in each layer or whether some layers would have multiple packages.

Figure 7.1. PSP Tools layers

Layers are one way to look at the architecture of a system, but understanding the layers is not sufficient to understand how the system is structured. As we began to design the different classes we wanted, we added some packages to the layers. Figure 7.2 shows the packages we ended up with.

Figure 7.2. Final PSP Tools packages

Due to the simplicity of the application, we ended up with one package per layer except for the persistent data layer. There are also some packages outside the three main layers. We could consider these packages as a utility layer , but in general they were not so cohesive that we felt they deserved the layer label. The utility packages contain helper classes that are used by the other layers.

Figure 7.2 also shows the main dependency arrows for the packages in the layers. A dependency is "A relationship between two modeling elements , in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element)." ^[2] A good design practice is to avoid two-way dependencies. We actually have some mutual dependencies that we will talk about when we discuss the Construction details in Chapter 9. The arrows in Figure 7.2 show the ideal dependencies.

^[2] UML glossary, version 1.5.