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.

Software Architectures and Documentation

Part I. Software Architecture Viewtypes and Styles

The Module Viewtype

Styles of the Module Viewtype

The Component-and-Connector Viewtype

Styles of the Component-and-Connector Viewtype

The Allocation Viewtype and Styles

Part II. Software Architecture Documentation in Practice

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints

References



Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net