Chapter 2: A Tour of Rose

Figure 2.6: Log window

Exploring Four Views in a Rose Model

There are four views in a Rose model: the Use Case view, the Logical view, the Component view, and the Deployment view. Each of these four views addresses a different audience and purpose. In the following sections, we'll take a brief look at each of these views. In the remainder of this book, we'll discuss the detailed model elements that appear in each of these views.

Use Case View

The Use Case view includes all of the actors, use cases, and Use Case diagrams in the system. It may also include some Sequence and Collaboration diagrams. The Use Case view is an implementation−independent look at the system. It focuses on a high−level picture of what the system will do, without worrying about the details of how the system will do it. Figure 2.7 illustrates the Use Case view in the Rose browser.

38

Chapter 2: A Tour of Rose

Figure 2.7: Use Case view

The Use Case view includes:

Business use cases, which are workflows within the organization.

Business actors, which are people, companies, or other entities outside the organization who interact with the business.

Business workers, which are roles within the organization

Organizational units, which are groups of business cases and/or business workers.

Activity diagrams, which are used to describe the workflow within a business use case or a flow of events through a use case.

Actors, which are external entities that interact with the system being built.

Use cases, which are high−level pieces of functionality the system will provide.

Use case documentation, which details the flow through the use case, including any error handling. This icon represents an external file that has been attached to your Rose model. The icon used will depend upon the application you used to document the flow of events. Here, we used Microsoft Word.

Use Case diagrams, which show the actors, the use cases, and the interactions between them. There are typically several Use Case diagrams per system, each showing a subset of the actors and/or use cases.

Interaction diagrams, which display the objects or classes involved in one flow through a use case. There may be many Interaction diagrams for each use case. Interaction diagrams can be created in either the Use Case view or the Logical view. Any Interaction diagrams that are implementation−independent are typically created in the Use Case view. Any Interaction diagrams that are language−specific are located in the Logical view.

39

Chapter 2: A Tour of Rose

Packages, which are groups of use cases, actors, or other modeling elements. A package is a UML mechanism that helps you to group related items together. In most cases, there are few enough use cases and actors that packaging is not essential. However, it's a tool that is always available to help you organize the Use Case view. In particular, it can be convenient to package these elements for configuration management.

When the project first begins, the team may optionally produce a business model in the Use Case view. If this task is undertaken, the team members that will be needed include the customer, the project manager, and analysts who focus on business processes (frequently termed business analysts). The rest of the team—including designers, coders, testers, and so on—will refer to the business model throughout the project

to gain an understanding of the overall business and how the new system fits into its organizational structure. We will discuss the business model in more detail in Chapter 3, "Business Modeling."

Once the business model has been completed, the team moves on to the use case model. Customers, analysts, and project managers will work with the use cases, Use Case diagrams, and use case documentation to agree on a high−level view of the system.

Note This view focuses only on what the system will do. Implementation details should be left for future discussions. In an object−oriented system, use cases are the system requirements.

As the project goes along, all members of the team can look at the Use Case view to get a high−level understanding of the system being built. The use case documentation will describe the flow of events through a use case. With this information, quality assurance staff can begin to write testing scripts. Technical writers can begin the user documentation. Analysts and customers can help ensure that all requirements were captured. Developers can see what high−level pieces of the system will be created, and how the system logic should flow.

Once the customer has agreed to the use cases and actors, they have agreed to the system scope. The development can then continue to the Logical view, which focuses more on how the system will implement the behavior spelled out in the use cases.

Logical View

The Logical view, shown in Figure 2.8, focuses on how the system will implement the behavior in the use cases. It provides a detailed picture of the pieces of the system, and describes how the pieces interrelate. The Logical view includes, among other things, the specific classes that will be needed, the Class diagrams, and the Statechart diagrams. With these detailed elements, developers can construct a detailed design for the system.

40

Chapter 2: A Tour of Rose

Figure 2.8: Logical view

The Logical view includes:

Classes, which are the building blocks for a system. A class consists of a little bit of information (its attributes) and a little bit of behavior (its operations), grouped together. For example, an Employee class might store information about the employee's name, address, and social security number, and might include behavior such as hiring or firing an employee. There are different types of icons that are used for different types of classes. We will discuss these further in Chapter 6, "Classes and Packages."

Class diagrams, which are used to view the classes in the system, their attributes and operations, and their relationships to each other. Typically, a system will have several Class diagrams, each showing a subset of all the classes.

Interaction diagrams, which include Sequence and Collaboration diagrams, are used to display the classes that participate in one flow of events through a use case. As we mentioned above, Interaction diagrams can be created in either the Use Case view or the Logical view. Interaction diagrams in the Use Case view tend to be high−level and implementation−independent, while Interaction diagrams in the Logical view are more detailed.

Statechart diagrams, which show the dynamic behavior of an object. A Statechart diagram includes all of the states in which a particular object can exist. It also illustrates how the object moves from one state to another, what state the object is in when it is first created, and what state the object is in when it is destroyed. A Statechart diagram can be useful in detailing business rules.

Packages, which are groups of related classes or other modeling elements. Packaging isn't required, but it is certainly recommended. A typical system may have a hundred classes or more. Packaging your classes can help reduce the complexity of your model. To get a general picture of the system, you can look at the packages. To see a more detailed view, you can go into any of the packages and view the classes inside.

Frequently, teams take a two−pass approach to the Logical view. In the first approach, they identify analysis classes. Analysis classes are language−independent classes. By focusing first on analysis classes, the team can begin to see the structure of the system without getting bogged down in the implementation−specific details. In UML, analysis classes can be represented using the following icons:

41