Chapter 2: A Tour of Rose

This chapter concludes our introduction to UML and Rose. After reading this chapter, you will be armed with enough information to embark on learning the fundamentals of designing systems with Rose. In this chapter, we discuss what Rational Rose is and what a Rational Rose model includes, and then take you on a visual tour, discussing the various parts of the screen and how to navigate through the product. We'll discuss the four views of a system that are available through Rose and how to work with Rose. Finally, we'll look at how to publish a Rose model to the Web, and how to manage versions of a Rose model.

What Is Rose?

Rational Rose is a powerful visual modeling tool to aid in the analysis and design of object−oriented software systems. It is used to model your system before you write any code, so you can be sure that the system is architecturally sound from the beginning. Using the model, you can catch design flaws early, while they are still inexpensive to fix.

Rational Rose supports business modeling, helping you to understand the business around the system. It helps with systems analysis by enabling you to design use cases and Use Case diagrams to show the system functionality. It will let you design Interaction diagrams to show how the objects work together to provide the needed functionality. Class diagrams can be created to show the classes in a system and how they relate to each other. Component diagrams can be developed to illustrate how the classes map to implementation components. Finally, a Deployment diagram can be produced to show the network design for the system.

A Rose model is a picture of a system from various perspectives. It includes all of the UML diagrams, actors, use cases, objects, classes, components, and deployment nodes in a system. It describes in great detail what the system will include and how it will work, so developers can use the model as a blueprint for the system being built.

A blueprint is a good analogy for a Rose model. Just as a house has a set of blueprints that let different members of the construction crew see it from different perspectives (plumbing, electrical, and so on), a Rose model contains a number of different diagrams that let the project team see the system from different perspectives (customer, designer, project manager, tester, and so on).

Having a blueprint ahead of time helps alleviate an age−old problem. The team has talked to the customers and documented the requirements. Now the developers are ready to code. One developer (we'll call him Bob) takes some of the requirements, makes certain design decisions, and writes some code. Jane, another developer, takes some requirements, makes completely different design decisions, and writes some more code.

This difference in programming style is perfectly natural; 20 developers given the same requirements may code 20 different systems. The problem comes about when someone needs to understand or maintain the system. Without conducting detailed interviews with each of the developers, it's hard for anyone to see what design decisions were made, what the pieces of the system are, or what the overall structure of the system is. Without a documented design, it's hard to be sure that the system you built is actually the system the users had in mind.

Traditionally, we follow a process that looks like this:

27

Chapter 2: A Tour of Rose

The requirements are documented, but the design is inside Bob's brain, so no one other than Bob has a good idea of the system structure. If Bob leaves, that information leaves with him. If you've ever been the one taking over for Bob, you can appreciate how difficult it can be to understand a system with little documentation.

A Rose model gives us a process that looks like this:

Now the design is documented. We get rid of Bob (figuratively speaking, of course!) and replace our dependency on him with a documented design. The developers can all gather to discuss the design decisions before the code is written. You don't have to worry about everyone going off in a separate direction with the system design.

But the developers aren't the only ones to use the model:

∙

The entire team will use the Business Use Case diagrams to get an understanding of the business surrounding the system.

∙

Customers and project managers will use the Use Case diagrams to get a high−level view of the system and to agree on the project scope.

∙

Project managers will use the Use Case diagrams and documentation to break the project down into manageable pieces.

∙

Analysts and customers will look at the use case documentation to see what functionality the system will provide.

∙

Technical writers will look at the use case documentation to begin to write the user manual and training plans.

∙

Analysts and developers will look at Sequence and Collaboration diagrams to see how the logic in the system will flow, the objects in the system, and the messages between the objects.

∙

Quality assurance staff will use the use case documentation and the Sequence and Collaboration diagrams to get the information they need for testing scripts.

∙

28

Chapter 2: A Tour of Rose

Developers will use the Class diagrams and Statechart diagrams to get a detailed view of the pieces of the system and how they relate.

∙

Deployment staff will use the Component and Deployment diagrams to see what executable files, DLL files, or other components will be created, and where these components will be deployed on the network.

∙

The whole team will use the model to be sure the requirements are traced to the code, and that the code can be traced back to the requirements.

Rose, therefore, is a tool meant to be used by the entire project team. It is a repository of scope, analysis, and design information that each team member can use to get the information they need.

In addition to the above, Rational Rose will help developers by generating skeletal code. It can do this for a number of different languages available on the market, including C++, Ada, CORBA, Java, COM objects, Visual Basic, and XML. Further, Rose can reverse engineer code and create a model based on an existing system. Having a model in Rose for an existing application is very beneficial. When a change occurs to the model, Rose can modify the code to incorporate the change. Similarly, when a change occurs in the code, you can incorporate that change into the model automatically. These features help you keep the model and the code synchronized, reducing the risk of having an outdated model.

Rose can also be extended using RoseScript, a programming language packaged with Rose. Using this programming language, you can write code to automatically make changes to your model, create a report, or perform other tasks with your Rose model.

There are three different versions of Rose currently available:

∙

Rose Modeler, which allows you to create a model for your system, but will not support code generation or reverse engineering.

∙

Rose Professional, which allows you to generate code in one language.

∙

Rose Enterprise, which allows you to generate code for C++, Java, Ada, CORBA, Visual Basic, COM, Oracle8, and XML. A model can have components that are generated in different languages.

What 's New in Rose 2002

In the last several years, Rose has been enhanced to accommodate some of the newer UML notation and diagrams. The following list includes the newest of the enhanced Rose features at the time of this writing:

∙

A main diagram for each package can now be selected.

∙

Items on a diagram can now be moved around using the arrow keys.

∙

29