Applying modeling techniques on a project can save significant time and effort through improved communication within the team. Using a modeling tool in conjunction with those modeling techniques can turbo-charge the entire process.
A modeling tool can be an invaluable asset for supporting the software engineer throughout the design process. Although a modeling tool will not turn an inexperienced object-oriented designer into an expert, it will increase the productivity of those software engineers who are already proficient in model-based development methods.
Modeling tools have enjoyed a revival in recent years, with many newer commercial products establishing a market for themselves. The tools available range from simple drawing packages to fully integrated design and development environments.
This section looks at the required feature set of a modeling tool and covers how each feature of the tool can save the software engineer time and effort.
Choosing a Modeling Tool
Selecting a modeling tool that best fits your development needs depends essentially on what you intend to use the tool for and how much you wish to pay. Many companies are guilty of using high-end modeling tools as nothing more than expensive drawing packages, while others struggle to gain the full benefits of model-based development due to the limitations of a low-cost modeling product.
It is advisable to decide on the exact level of functionality you want from the tool before purchasing. Remember that some of the more expensive tools are very sophisticated, so don't forget to factor training into the total cost.
Table 5-2 lists some of the popular modeling tools. For those wishing to try their hand at modeling, most product vendors provide either limited-functionality community editions or fully featured evaluation versions. All of the tools included are Java-based and so should be available for most platforms.
Most of the UML diagrams in this book were produced using Borland's Together range of modeling tools.
In choosing the right tool for your needs, you must appreciate the different features modeling tools offer and how these features can be of benefit during the modeling process. Here are some of the main features to look for in a modeling tool:
Like all languages, the UML has its own particular syntax and semantics. A modeling tool should be able to validate the UML to ensure correct use of the language. A UML diagram communicates a huge volume of information, and using the UML incorrectly can result in serious misinterpretations of the design. The language-checking ability of the modeling tool can help prevent this confusion.
Most tools support all of the main UML diagrams to a lesser or greater degree. You should take into account the level of support a tool provides for each diagram type based upon your expected usage of a particular diagram. For example, if you intend only to model during the analysis phase of the project, then strong support for deployment and component diagrams is of less value than if planning to model throughout the entire software development lifecycle.
The version of the UML supported by the tool is also a factor. The UML is an evolving language, and the standard is governed by the Object Management Group (OMG). As the language changes, tool vendors must rush to keep their products in step with the new versions. The need to have the latest version of the UML would therefore be a reason for choosing one tool over another.
An interaction diagram provides proof that the components of the system can execute a specific use case. Removing a component from the model or changing a component's interface affects the flow of messages involved in executing a particular use case.
Unlike the basic drawing tools that can only reproduce UML notation, a modeling tool should detect inconsistencies between the object model and any of the interaction diagrams.
When defining interaction diagrams, modeling tools enforce the passing of messages between objects. If the appropriate method has not been defined on a class, then it is impossible to pass that particular message to an instance of the class. The modeling tool's governance of message passing helps to highlight omissions in the design model and prevents objects being organized in a manner that will fail to execute a particular use case.
Validation of the model's interaction diagrams is beneficial for projects following an iterative development process, since the system's design is continually evolved over the course of several iterations. Early detection of design errors prevents these inadvertent but time-wasting mistakes from being implemented in the application.
Forward and Reverse Engineering
Building a model requires nothing more than a pen and paper, but this can be very limiting for large-scale projects. If we are to use a model to drive the development process, then it is essential that the model be kept updateda tedious chore if the model is paper-based.
The ability to both generate Java source from the model and import Java code back into the model is therefore an important consideration when selecting a modeling tool. The process of exporting and importing is called forward and reverse engineering:
Not all of the UML diagrams make good candidates for the code- and model-generation process. Most tools forward- and reverse-engineer to and from class diagrams. Some tools also support the forward and reverse engineering of interaction diagrams.
A roundtrip is the process of continually jumping between model and code. This process enables changes made in the code to be reflected in the model and vice versa. Figure 5-8 illustrates the roundtrip process as a UML activity diagram.
Figure 5-8. Activity diagram showing the roundtrip process.
These are the main advantages of roundtrip support in a modeling tool:
The process of performing a roundtrip with a modeling tool is demonstrated in Chapter 7.
The ability to roundtrip safeguards against one of the worst fates that can befall a modelit becomes out-of-date.
To be of real use, the life of the model should extend beyond the design phase. As has been covered, the model enables change to be assessed throughout the entire software development lifecycle, including when the project has been delivered and has transitioned into a maintenance phase.
One of the biggest project failings is that the model ceases to be maintained after the initial design work is completed. Without the ability to update the model from the code, the two quickly diverge, leaving the code as the only true representation of the design.
If the model is perceived as being out of date, developers cease to trust the information held in the model and turn instead to the code for answers. Unfortunately, code does not give up its design secrets in as easily a digestible form as a UML diagram. Consequently, developers must hunt through the source code to determine the workings of the system.
It is therefore imperative that model and source code are kept synchronized as the project progresses. Roundtrip support enables this to be achieved relatively painlessly. Someone still has to take on the responsibility of reverse engineering the code back into the model, but this is a far less arduous a task than updating the model manually.
Roundtrip support is important when undertaking an iterative development process. As the model is revisited as part of the design process at the start of each iteration, the model must reflect changes in the code made during the previous iteration's implementation effort.
The ability of any modeling tool to synchronize model and code cannot be understated. As soon as the model falls behind the code, the project team will discard it. Tools that offer good roundtrip support help instill in the developers faith that the model is accurate and reliable. Getting developer buy-in to the model ensures it can continue to drive the development process.
Design Pattern Support
Design patterns are a powerful tool for software reuse, and software reuse is an essential ingredient for rapid development. Design patterns form the basic building blocks of architecture, and with their application, the designer can construct an architecture based on proven, best-practice designs.
Patterns enable high-quality solutions to be arrived at quickly and easily. A good modeling tool should facilitate the designer in the application of design patterns, making it easy to incorporate best-of-breed design constructs into any solution.
Modeling tools can support design patterns by providing pattern templates or pattern wizards for automatically generating standard patterns. Figure 5-9 shows a screenshot of a pattern-selection dialog from Together ControlCenter.
Figure 5-9. Together ControlCenter pattern template.
Here, the designer chooses from a list of patterns. In this example, the Business Delegate pattern, as defined in the book Core J2EE Patterns [Deepak, 2003], has been selected. Via the dialog, the designer can specify the class names generated from the template. A link to reference documentation for the pattern appears in the lower pane of the dialog window.
From this template, the classes defined by the pattern are created and added to the active diagram with the relationships between the classes correctly modeled.
Figure 5-10 displays the classes that resulted from the pattern template. As Figure 5-10 illustrates, the classes have been created in strict compliance with the pattern. Together Control-Center has also generated much of the boilerplate code involved in the pattern, leaving the software engineer free to concentrate on the implementation detail.
Figure 5-10. Classes generated from the Business Delegate template.
Working with patterns using a template-driven approach has some distinct advantages over simply building the pattern a class at a time:
First, the modeling tool ensures the pattern is laid down in compliance with the original specification of the pattern. Like the UML, design patterns are an example of a common vocabulary for software engineers, who can use patterns to describe application designs as well as build with them. Incorrect interpretation of a design pattern negates the advantages of this common vocabulary and can cause confusion, making ongoing maintenance of the application difficult. The use of a pattern template ensures each pattern is applied correctly, thereby removing the opportunity for the designer to misinterpret them in the design.
Having patterns so easily accessible also encourages extensive use of patterns in the design process. A traditional approach would see the designer referring to a pattern's specification and then tediously defining each class and all the relationships. With a modeling tool, a comprehensive list of patterns is only a few keystrokes away. The designer not only can apply patterns quickly to a design but also can experiment with different patterns and pattern combinations as part of the model.
Template use is analogous to painting a room in a house. Painting a wall with a narrow, fine brush would get the job done but would take all day. A far more practical tool than the small brush for this task would be a wide paint roller, which would see the job completed in considerably less time. Pattern templates are therefore our software equivalent of a paint roller.
In addition to providing templates for the established design patterns, the modeling tool should allow designers to create their own pattern templates. This feature enables designers to build the experience of quality designs gained from other projects into the modeling tool. If the modeling tool is used as part of a team environment, these patterns become available to the rest of the team, thereby sharing valuable design knowledge among the group.