This is a description of the underlying model, sometimes called a meta-model, of the Rational Unified Process (RUP). It is not meant as a complete and syntactically correct specification of the meta-model. It is more a means of giving a process engineer an understanding of the underlying structure of a RUP based process. For an introduction to the basic concepts of the RUP, see the Overview.

For additional information on extending the RUP, and for a more detailed guide to the design of the RUP, see the Process Engineering Process (PEP). The PEP is a RUP-like process that provides guidance in the area of process engineering. It is included with the Rational Process Workbench(TM), available for download from the Rational Developer NetworkSM.

Topics

High-level view of the RUP To top of page

The underlying model of the RUP is organized around first-class process elements, categorized as structural or behavioral. These elements are structured into process components, the packaging mechanism in the process model. A plug-in to RUP defines its own process model that complies with this structure.

Diagram described in accompanying text.

A model of the high-level structure of the RUP

Detailed view of the RUP - first-class elements To top of page

The first-class process elements constitute the modeled part of the RUP process, such as the roles, artifacts and activities. The diagram below shows a model of the first-class elements of the RUP, as defined in the RUP meta-model. This meta description enumerates the element types of the RUP, and describes the valid relationships between them.

Diagram described in accompanying text.

The meta-model representation of the first-class elements of RUP

The three core elements of the RUP is Role, Artifact and Activity. The backbone of any software engineering process is the description of who (roles) does what (artifacts) and how (activities) to do it. The notion of when (phases) is a central supplement to help plan and execute a project. The 3 core elements are briefly described below:

  • A role is a grouping mechanism that defines a set of responsibilities in terms of activities that this role can perform. A role may be performed by an individual or a set of individuals working together as a team. An individual may also assume multiple roles. Sometimes a role may relate directly to an individual's job title, but it does not have to.
  • An activity is a unit of work a role may be asked to perform. An activity is described by it's steps and input and output artifacts. The goal of an activity is to create or update one or more artifacts.
  • Artifacts are the products of a software project. A given artifact might serve as both input to and output from a set of activities. To better be able to describe an artifact using a well-defined process language, the RUP meta-model defines a set of artifacts types, each identified by a specific stereotype. The valid RUP artifacts are listed below:
  • A model, such as the Use-Case Model or the Design Model
  • A model element, that is, an element within a model such as a class or a subsystem.
  • A document, such as the Vision Document
  • A specification document, such as the Supplementary Specification
  • A data store, such as the Project Repository
  • A plan document, such as the Software Development Plan
  • An assessment document, such as the Iteration Assessment
  • An executable artifact, such as the User-Interface Prototype
  • An infrastructure oriented artifact, such as the Development Infrastructure
  • A generic artifact, used when none of the above are applicable

Detailed view of the RUP - second-class elements To top of page

The RUP meta-model defines a set of second-class process element types, also know as supporting file types, aimed at supplementing the first-class elements with additional process guidance. These elements differ from the first-class elements in that they are not defined as part of the process model, they don't have a UML representation as such. Below is an illustration of the most common file-type-to-element mapping. Whitepapers and Roadmaps are files that often span several elements or sometimes even don't address specific first-class elements. A second-class element can be associated with more than one first-class element.

Diagram described in accompanying text.

An overview of second-class elements and how they map to first-class elements

The Rational Process Workbench product provides a work space for creating instances of these file types and and associating them to one or more of the first-class process elements.

Ways of organizing the process To top of page

Different process stakeholders may see the RUP from different perspectives. A RUP Website is constructed to allow for different navigation paths to be taken through the process. Below are a few examples of typical perspectives into a RUP based process:

  • The discipline-based organization is useful when you work within a certain 'area-of-concern', such as Analysis & Design. Each discipline has one diagram showing the workflow of the discipline, expressed in terms of workflow details. The primary purpose of a workflow detail is to describe how activities are performed in reality. Normally, several activities are performed together. Workflow details are groupings of activities that are done together, presented with input and resulting artifacts. The workflow details are not necessarily performed in sequence and you may alternate between them during an iteration.
  • The time-based organization is very relevant when you try to plan activities or measure progress. The lifecycle element defines the breakdown of the timeline into a set of phases, the standard RUP phases are Inception, Elaboration, Construction and Transition. Each phase defines a workflow that is typical for an iteration in this phase. The workflow defines a set of workflow details, each of which points to the relevant set of core elements (roles, activities and artifacts), at a given time.
  • The role-based organization is useful for any practitioner, to narrow down the number of process elements to be only the relevant pieces of the process for a given individual. A role based view of the process is often organized around a set of closely related roles, such as all the Analyst roles. By navigating the role's overview pages, we get to the set of activities performed by these roles or to the artifacts modified by these roles.
  • Organizing the process around tools is yet another valid perspective on the RUP. Tool mentors provide tool specific guidance on related activities, and the Extended Help capability provides hocks into the process from certain tool contexts.

Miscellaneous To top of page

There are some additional items in the RUP. The most important of these are listed below:

  • Introductory material that describes key concepts of the RUP and gives an overview of all the process related content.
  • A glossary of all terms used in the RUP.
  • References to external sources.
  • A search database allowing users to search for information based on keywords.

© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13