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.

Table 11.1. Rational Unified Process use case view

	Rational Unified Process Term	Our Term
Elements	Use case package
	Actors	Actors
	Use cases	Use cases
Relations	Include	Include
	Extend	Extend
	Generalize	Generalize

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.

Table 11.2. Rational Unified Process logical view

	Rational Unified Process Term	Our Term
Elements	Design packages
	Design subsystems	Module
	Class	Module, Class
	Interface	Interface
	Capsule	Component
	Port	Port
	Protocol	Connector
Relations	Association	Uses
	Generalization	Generalization
	Owns	Decomposition

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.

Table 11.3. Rational Unified Process implementation view

	Rational Unified Process Term	Our Term
Elements	Implementation subsystems	Module
	Components	Module
Relations	Association	Uses
	Generalization	Generalization
	Owns	Decomposition

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.

Table 11.4. Rational Unified Process process view

	Rational Unified Process Term	Our Term
Components	Classes stereotyped as process and/or threads	Concurrent units: task, process, thread
Connectors	Message/broadcast/RPC	Communication

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.

Table 11.5. Rational Unified Process deployment view

	Rational Unified Process Term	Our Term
Software components	Process/thread Deployment unit	Software element: process and/or thread from C&C viewtype
Environment components	Nodes/devices/connectors	Environmental element: processor, network
Relations	Communication channel	Communication
	Executes on	Allocated to

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:

To Achieve This RUP View	Use This Approach
Use case view	Adopt use cases to specify behavior, either associated with any of the views or as part of the documentation beyond views
Logical view	Use a module-based style that shows generalization, uses, and decomposition
Implementation view	Use a module-based style that contains implementation elements
Process view	Use the communicating-processes style of the C&C viewtype
Deployment view	Use the deployment style of the allocation viewtype

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.