Rational Unified Process/Kruchten 4+1

Rational Unified Process Kruchten 4+1

The Rational Unified Process (RUP) introduces a five-view approach to documenting software architectures, based on Kruchten's 4+1 approach.

• The use case view contains use cases and scenarios of architecturally significant behavior.
• The logical view contains the most important design classes.
• The implementation view captures the architectural decisions made for the implementation.
• The process view contains the description of the tasksprocesses and threadsinvolved.
• The deployment view contains the description of the various physical nodes for the most typical platform configurations.

The RUP describes the use case view as representation of an architecturally significant subset of the use case model, which documents the system's intended functions and its environment. The use case view serves as a contract between the customer and the developers and represents an essential input to activities in analysis, design, and test.

Use cases are a vehicle for describing behavior, and behavior is a part of every view's supporting documentation. Consequently, you can document use cases as a behavior description of the system or parts of it. Table 11.1 shows the correspondence of terminology.

Documenting a logical view of the RUP can be done by using the module or the C&C viewtype. A union of the module decomposition style, the module uses style, and the module generalization style allows you to represent the structural part of the logical view by using such elements as subsystems and classes, whereas a C&C viewtype allows you to represent the runtime aspects by using components and ports. Table 11.2 shows the correspondence of terminology.

An implementation view can be represented by using a combination of the module decomposition style, the module uses style, and the module generalization style. The implementation view represents implementation elements, such as implementation subsystems and components. The RUP distinguishes between a design and an implementation model to separate general design aspects from implementation aspects introduced by the use of a specific programing language. To describe the relationships between elements of the design model and the implementation model, the mapping should be documented. Table 11.3 shows the correspondence of terminology.

The RUP process view provides a basis for understanding the process organization of a system, illustrating the decomposition of a system into processes and threads and perhaps also showing the interactions among processes. The process view also includes the mapping of classes and subsystems onto processes and threads.

The communicating-processes style of the component-and-connector viewtype can be used to represent a process view. To accommodate the process view, define a style that uses the components as defined in the communicating-processes styletask, process, threadand connectors that are based on the communication connector but are refined into more specific connectors, such as broadcast or remote procedure call. Table 11.4 shows the correspondence of terminology. To describe the relationships between processes and elements, such as subsystems and classes, the mapping among them should be documented.

A RUP deployment view describes one or more physical networkhardwareconfigurations on which the software is deployed and runs. This view also describes the allocation of processes and threadsfrom the RUP process viewto the physical nodes. The deployment style of the allocation viewtype is a good match for the RUP deployment view. Table 11.5 shows the correspondence in terminology.

The RUP deployment view also allows you to assign deployment units to nodes. A deployment unit consists of a buildan executabledocuments, and installation artifacts. It is a packaging of implementation elements for selling and/or downloading purposes. This is not part of architectural documentation and therefore is not mentioned in this book. Nevertheless, you can define a style of the module viewtype, showing implementation elementssubsystems/classesand how they are packaged as deployment units.

The following list reconciles the prescribed Rational Unified Process views with our advice in this book:

Furthermore, RUP does not preclude using additional views that may be useful, and so you are free to choose any others that can play a helpful role in your project.

Beyond its five views, RUP does not prescribe other kinds of documentation, such as interface specifications, rationale, or behavior of ensembles. It doesn't call for a view catalog, a mapping between views, view templates, or style guides. But it certainly does not rule these things out, either.

If you've chosen to follow RUP, you can certainly document the five suggested views, using viewtypes and styles in this book. But don't stop there. You are also free to consider additional views that may be important in your project's context, and you should do so. You should also augment the primary presentation of each view with the supporting documentation called for in Section 10.2, and you should complete the package by writing the documentation that applies beyond views, as described in Section 10.3. The result will be an RUP-compliant set of documentation having the necessary supporting information to complete the package.