Chapter 2: A Tour of Rose

The analysis classes might also appear on some Interaction diagrams in the Use Case view. Once the analysis classes have been identified, the team can change each one to a design class. A design class is a class that has language−specific details. For example, we may have an analysis class that's responsible for talking to another system. We don't worry about what language the class will be written in—we focus only on what information and behavior it will have. When we turn it into a design class, however, we look at the language−specific details. We may decide that now we have a Java class. We might even decide that we need two Java classes to actually implement what we uncovered in analysis—there isn't necessarily a one−to−one mapping between analysis classes and design classes. Design classes are shown on the Interaction diagrams that appear in the Logical view.

The focus of the Logical view is on the logical structure of the system. In this view, you identify the pieces of the system, examine the information and behavior of the system, and examine the relationships between the pieces. Reuse is one of the main considerations here. By carefully assigning information and behavior to classes, grouping your classes together, and examining the relationships between the classes and the packages, you can identify classes and packages that can be reused. As you complete more and more projects, you can add new classes and packages to a reuse library. Future projects then become more of a process of assembling what you already have, rather than building everything from scratch.

Nearly everyone on the team will use information from the Logical view, but the primary users will be the developers and architect. The developers will be concerned with what classes are created, what information and behavior each class should have, and what relationships exist between the classes. The architect, who is more concerned with the structure of the overall system, is responsible for ensuring that the system has a stable architecture, that reuse has been considered, and that the system will be flexible enough to change as requirements change. Analysts will look at the classes and Class diagrams to help ensure that the business requirements will be implemented in the code. Quality assurance staff will look at the classes, packages, and Class diagrams to see what pieces of the system exist and need to be tested. They will also use the Statechart diagrams to see how a particular class should behave. The project manager will look at the classes and diagrams to ensure that the system is well structured, and to get an estimate of how complex the system is.

Once you've identified the classes and diagrammed them, you can move on to the Component view, which focuses more on the physical structure.

Component View

The Component view contains information about the code libraries, executable files, run−time libraries, and other components in your model. A component is a physical module of code.

In Rose, components and Component diagrams are displayed in the Component view, as shown in Figure 2.9. The Component view of the system allows you to see the relationships between the modules of code.

42

Chapter 2: A Tour of Rose

Figure 2.9: Component view

The Component view includes:

Components, which are physical modules of code.

Component diagrams, which show the components and their relationships to each other. Relationships between the components let you know what the compilation dependencies are. With this information, you can determine the compilation order of the components.

Packages, which are groups of related components. As with packaging classes, reuse is one of the considerations when packaging components. A group of related components may be very easy to pick up and reuse in other applications, so long as the relationships between the group and other groups are carefully monitored. We'll discuss these issues in detail later.

The main users of the Component view are those people responsible for controlling the code and compiling and deploying the application. Some of the components will be code libraries. Others will be run−time components, such as executable files or dynamic link library (DLL) files. Developers will also use the Component view to see what code libraries have been created and which classes are contained in each code library.

Deployment View

The final view in Rose is the Deployment view. The Deployment view is concerned with the physical deployment of the system, which may differ from the logical architecture of the system.

For example, the system may have a logical three−tier architecture. In other words, the interface may be separated from the business logic, which is separated from the database logic. However, the deployment may

43

Chapter 2: A Tour of Rose

be two−tiered. The interface may be placed on one machine, while the business and database logic are located on another machine.

Other issues, such as fault tolerance, network bandwidth, disaster recovery, and response time, are also handled using the Deployment view. The Deployment view is shown in Figure 2.10.

Figure 2.10: Deployment view

The Deployment view includes:

Processes, which are threads that execute in their own memory space.

Processors, which include any machines with processing power. Each process will run on one or more processors.

Devices, which include any hardware without processing power. Examples are dumb terminals and printers.

A Deployment diagram shows the processes and devices on the network and the physical connections between them. The Deployment diagram will also display the processes, and show which processes run on which machines.

Again, the whole team will use the information in the Deployment view to understand how the system will be deployed. However, the primary users will be the staff responsible for distributing the application.

44