developerWorks > Rational >

Extending the RUP, Part 1: Process ModelingContents:

Introduction

Model-based process engineering

Modeling a process plug-in

Advanced modeling techniques

Conclusion

Resources

About the author

Rate this article

Subscriptions:dW newsletters

dW Subscription(CDs and downloads)

The Rational Edge

A step-by-step guide for creating RUP plug-insLevel: Introductory

Alfredo Bencomo (bencomo@us.ibm.com)IBM12 Jan 2005

This series begins a set of hands-on exercises that explore the use of IBM Rational tools to support the different activities involved in process engineering such as process modeling, process authoring, process configuration, process deployment, and process consumption. This first installment on Extending the RUP will show you the insights for modeling the static part of RUP plug-ins with the objective to override or extend the process elements in the base RUP or perhaps other plug-ins. Share your thoughts on this article with the author and other readers in the accompanying discussion forum.

IntroductionIn the last few years, an important research effort has been made in order to adapt UML (Unified Modeling Language) to the specific requirements of Software Process Model (SPM). As a result, some UML profiles and metamodels like SPEM or RUP, has emerged. The IBM Rational Process Workbench (see resources) performs process modeling within the conceptual framework of the RUP metamodel; which is encoded with the help of the lightweight extension mechanism provided by the UML (stereotypes and tagged values) to create the RUP profile and define a process modeling language (PML). It is worth mentioning that like the SPEM metamodel, RUP is also defined as an explicit extension of the UML metamodel. However, while the heavyweight extension ensures a proper language definition at the metamodel level, its transformation to UML profile guarantees conformance with UML.

Figure 1. RUP as a profile

Figure 2 shows an example of the definition of some descriptive stereotypes that take part in the RUP profile. Note the special kind of association where one extension-end references a stereotyped class and the other references a metaclass, so the UML metaclasses can fit in a specific domain such as SPM.

Figure 2. A fragment of the descriptive stereotypes

Model-based process engineeringThe objective of process modeling is to define a model of a process such that it can serve as the blueprint for creating a process configuration. A process is described in terms of its elements, and we use the UML elements of class to represent roles and artifacts involved in the particular process; and we use operation to represent their activities and collaborations. Figure 3 illustrates the process components semantic model used to specify process model concepts within RPW.

Figure 3. Process components semantic model

Process Model is the container of all process elements. There is exactly one process model per base process or plug-ins. A base process is modeled as a self-contained process model, which does not extend any other process model and represents a complete end-to-end process in itself. Process plug-ins, on the other hand, are modeled as extensions of base processes or possibly other plug-ins, and in themselves specify only those elements that are different from their base process.

Process Component groups related process elements and becomes the selectable unit of process upon configuration time. Typically, elements within a process component are closely related. For a process component to reference elements in other components, an UML dependency needs to be established between them. A process component can contain sub-components to form a component hierarchy.

Process Elements represent the structure and behavior of the process definition. They are defined using UML classes and operations, which are stereotyped to carry their specific meaning. In addition, the various relationships between elements are defined using associations, also stereotyped to their specific kind. Figure 4 presents a fragment of the process elements recognized by the RPW and how they relate to one another.

Figure 4. Fragment of RUP metamodel

The diagram above may seem complex at a first glance, but here is how to read it: The "things" in the diagram are process element types used to build our process models. In a way, these are the terms of the process modeling language. Each process element type defines how it is modeled (operation or classifier) and its associations to other process element types. For example, role elements are modeled as classifiers, and they define operations to represent their activities and steps.

As it is ilustrated in Figure 3, the RUP architecture is structured to support process componentization. This decentralization gives process engineers the ability to configure the set of processes they need for a given project, or project type, by supplementing the RUP framework with domain and tool specific guidelines. In RUP, the foundation for creating such configurations is the RUP Plug-in technology. The RPW provides an integrated set of tools that collectively support the activities involved in developing process plug-ins.

The RUP Modeler tool is an add-in to IBM Rational XDE that allows a process engineer to visually model processes using UML notation. This tool recognizes and enforces the RUP metamodel and supports the SPEM specification to define the concepts of process modeling.

The RUP Organizer tools is a standalone application that provides a workspace for associating process content to process model elements. The key features of RUP Organizer are the tree-structured presentation of process elements, called Layout, and the support for drag-and-drop population and organization of files associated to this structure.

Modeling a process plug-inThe development of a new process model always starts with the analysis activities. Typically, the input of a first analysis is the process knowledge of those people currently performing it. This knowledge can be recorded by means of use case diagrams, where every use case represents an activity within the process and the actors involved in their execution. Under this approach, the use cases become a semi-formal description of the process fragments that later will serve as a base for process definition.

The tailoring discipline depicted in Figure 5, provides a high-level view into the underlying PEP description for projects and organizations adopting RUP. It shows the data flow dependencies between the workflow details (WFDs). However, no all flow of controls are specified here and can be different. For instance, the process modeler may realize that the results of the analysis are incomplete or inconsistent and ask the process engineer to go back to this working area immediately.

Figure 5. Tailoring discipline

The requirement for our case study is to attempt to semi-formally define a set of the structural aspects of an archetypical COTS-based

system (CBS). The CBS model proposed here is based on those found in the literature and describes a limited set of concepts. The objective is to extend the RUP and provide a risk-based spiral framework to accommodate CBS concepts.

Figure 6 shows a brief overview of the most common activities involved in modeling a plug-in to extend the RUP. When you model a structural plug-in, you either create new elements not currently covered by the RUP base or you define extensions to elements that already exist in the RUP process model.

Figure 6. Activities involved in modeling a RUP plug-in

Setup plug-in environmentSince this first installment is mainly focused on modeling the structural aspects of processes, we will utilize the RUP Modeler tool the majority of the time through the course of this exercise. Now, before you can start modeling our structured plug-in, you must verify that all the applications required are installed. The prerequisites are:

● IBM Rational Process Workbench (RPW)● IBM Rational Unified Process (RUP)● IBM Rational XDE Modeler or XDE Java

Version RequiredAll products should be version 2003.06.00 or later and the Java JRE 1.4.1 or 1.4.2

Activate the RUP Modeler Add-In: 1. Launch XDE2. Select Windows > Preferences menu option3. Find Rational XDE in the list and select Add-ins4. Press the Add-in Manager... button5. Under Packages, highlight Rational XDE and enable the RUP Modeler add-ins, as shown in Figure 7.

Figure 7. Enable the RUP Modeler add-ins

6. Click OK your way out of the dialogs

Now that your RUP Modeler add-in is activated, let's create the XDE project to host the plug-in model: 1. On the File menu, select New > Project...2. For project type, select Modeling > Basic Modeling Project > Next3. Name the project RPW, unselect the use default checkbox, and specify the Project Contents directory to point to the rpw

folder (which is normally C:\Program Files\Rational\rpw)4. Press Finish.

Figure 8. Projects in the XDE Navigator

5. XDE will create a default model: XDE Model.mdx and present it in the model explorer pane. Right-click on the project entry and select Close.

6. Back to the Navigator pane (see Figure 8), you can delete the XDE Model.mdx file.

Structure process modelCreate a new model file for your plug-in. We recommend that the storage location is in a peer folder (same level) to the rup folder:

1. In the Navigator view, right-click the project entry (RPW) and select New > Folder2. Name the folder epic (epic stands for Evolutionary Process for Integrating COTS-Based Systems)3. Right-click on the new folder and select New > Model4. From the Create New Model wizard, select the Blank Model template and name it epic, as shown in Figure 9.

Figure 9. XDE Model wizard

5. Click Finish (Observe that the new model is opened in the Model Explorer view).

Apply the RUP profile to the new model. As described early, the RUP profile is a mechanism that allows metaclasses from the UML metamodel to be extended so that they can fit in a SPM domain such as RUP:

1. Select the new (and empty) model in Model Explorer.2. In the Properties view, select the AppliedProfiles attribute and click the more [...] button.3. In the dialog presented, check for the RUPModeler profile, as shown in Figure 10.

Figure 10. Profile properties

4. Click OK and save the model.5. In the Navigator view, double-click the RUP model (located under rup > rup.mdx) to open it in the Model Explorer view.

Both, your process model and the RUP process model are now listed in the tree browser of the model explorer pane. This lets you define dependencies between these two models, such as a generalization relationship from one classifier in your process model to a classifier in the RUP process model. Later, we will create such UML dependencies.

With the RUP profile applied, we can now use instances of the classes extended by it to define the process elements for our plug-in model:

1. In the Model Explorer view and inside your new project, create a top-level UML package named epic_plugin2. Select the epic_plugin package and assign it the <<rupProcessModel>> stereotype, by clicking the more [...] button of the

Stereotype attribute in the Properties view, as shown in Figure 11.

Figure 11. Stereotype properties

3. In the default diagram that gets created under the process model package, drag and drop the EPIC process model package and the RUP process model package. Then, define a UML Dependency from the plug-in to the RUP process model, as shown in Figure 12.

Figure 12. Plug-in process model extends the RUP process model

Create a process componentLet's create a new process component (a UML package) to hold the process elements that we will define for the CBS Implementation process:

1. In the Model Explorer view, right click on the plug-in process model package and select Add UML > Package. Name it cbs_implementation

2. In the Properties view, assign the <<rupProcessComponent>> stereotype.3. Right click on the process component package and select Add Diagram > Class. Name the class diagram process_elements

Create two new artifacts

1. On the new class diagram, create a UML Class. Name it cbs_product_selection2. In the Properties view, assign it the <<rupArtifactDocument>> stereotype.3. Repeat the two previous steps to define a second artifact. Name it cbs_integration_mechanism and assign the

<<rupArtifactSpecification>> stereotype.

Note that the model element name given here is not visible to the process consumers (practitioners). Instead, it is actually the presentation name given in RUP Organizer during the authoring activities that surfaces the published process confirmation.

Define a responsible role

1. From the process_elements class diagram, create a new UML Class. Name it cbs_integrator and stereotype it as <<rupRole>>

2. Next, make this role responsible for the two new artifacts by establishing a UML Directed Association from the role to each of the artifacts (cbs_product_selection and cbs_integration_mechanism).

3. In the Properties view, assign the <<rupResponsible>> stereotype to both of the drawn directed associations.

Create an activity to produce the new CBS artifacts

1. Right click on the new role, select Add UML > Operation to create an activity. Name it evaluateSystemComponents2. In the Properties view, assign the <<rupActivity>> stereotype.

Define the activity contextActivities are used to define fine-grained units of work that can be assigned to a specific role responsible for its execution. The objectives of the activity are usually defined in terms of creating or modifying artifacts; which are declared as output parameters from the activity context. To support an activity, it may also specify a set of artifacts used as input(s). Before we specify the input and output artifacts for the new activity, let's first establish a visibility to two RUP process components that will determine which artifacts will be available as candidate parameters.

UML packages allow for modular modeling of processes so that complex processes are separated into manageable fragments. This will play a significant role in the process configuration space, where they constitute the atomic units of configuration, allowing project managers to select the pieces of process components to be included in their process configuration.

1. Create a new class diagram. Named it component_dependencies2. Drag both the cbs_implementation package and the RUP Architecture and

Implementation packages onto the new diagram.3. Select the UML Dependency from the Toolbox view and establish a visibility

dependency from the plug-in package to the two RUP process components, as shown in Figure 13.

Figure 13. Process component visibilities

4. In the Model Explorer view, right click on the new activity, select RUP Modeler > Overview and define the following input/out artifacts: rup_implementation_element and rup_software_architecture_document

5. Select the rup_software_architecture_document element from the input list (upper right pane) and click the Mandatory button (this push button toggles the mandatory designation, so clicking again removes the mandatory designation).

6. Then, define cbs_integration_mechanism and cbs_product_selection as output artifacts, as shown in Figure 14.

Figure 14. Activity inputs and outputs

The mandatory input artifacts must exist in the closure of a process configuration for the configuration to be correct. On the other hand, the optional artifacts (those not explicitly marked as mandatory), cannot be present and the process configuration still be considered correct. All output artifacts are implicitly defined as mandatory.

7. Let's now assign the activity to a workflow detail so that it gets incorporated in the base RUP activity model. Go to the Workflow Detail tab.

8. Select the discipline rup_implementation_discipline_impl and the plan_integration_wfd workflow detail, as shown in Figure 15.

Workflow details (WFDs) are process elements that group activities that are performed "together" during enactment. The eligible WFDs that populate the selection lists are those that reside within the visibility scope of the performing Role (see Figure 13). Moreover, associations between Activities and WFDs are "bi-directional", and can be established on either side.

Figure 15. Associating activity to an existing WFD

9. Press OK to exit and save the model. At this point your acquisition_process class diagram should look as it is illustrated in Figure 16.

Figure 16. Structural process model

Create content library and layout

1. In the Model Explorer view, right click on the epic_plugin process model package and select RUP Modeler > Associate Content Library

2. Create a new folder and name it content_library under the home folder of the new plug-in directory, as shown in Figure 17.

Figure 17. Associated content library

3. Right click on the epic_plugin process model package and select RUP Modeler > Organize Process Content to launch RUP Organizer.

4. Press the Refresh from Model button to synchronize with the model and generate the plug-in layout. 5. Save the layout and close/exit RUP Organizer.

Advanced modeling techniquesFrom the RPW point of view, two key concepts are relevant in order to describe the elements involved in process modeling: composition relationships and class generalizations. This section focuses in these two aspects; which are part of the static model definition.

Composition relationshipsArtifacts may be atomic or composite. Composite artifacts are constituted of smaller (less complex) subartifacts. This can be modeled in RPW by means of composite aggregations. Let's apply composition into our EPIC process model and make the cbs_integration_build_plan element contribute to the rup_integration_build_plan artifact to express the composite artifacts:

1. Create a new class that will become the contributor (a placeholder), name it cbs_integration_build_plan and assign stereotype <<rupArtifactPlan>>

2. Define a UML composition relationship from the cbs_integration_build_plan artifact to each of the sub-artifacts.3. Drag the rup_integration_build_plan artifact from the RUP Implementation process component and drop it onto the diagram.4. Select the UML Generalization from the Toolbox view and establish a <<rupContributes>> generalization from the

cbs_integration_build_plan artifact to the RUP artifact, as shown in Figure 18.

Figure 18. Process structure embodying artifact composition

Class generalizationsAnother interesting relationship between classes is refinement, which can be modeled in RPW through inheritance. Figure 19 illustrate the three kinds of inheritance relationships that you can define within RUP Modeler.

Figure 19. Generalizations supported in RPW

The <<rupExtends>> inheritance creates an association from the subclass to its super-class. As result, when the process configuration is generated, both elements will be represented in the published web site and a link established from sub-class to its super-class. Use extension of an existing element when you want to:

● Add activities to an existing role that require additional skill sets of the individuals playing the role.

Using the <<rupContributes>> inheritance means adding properties and/or behavior to the base element. Multi-tiered contributions are accumulated into the ultimate receiving class (the root parent of the inheritance structure). Use contribution to existing element when you want to:

RUP Modeler only recognizes single inheritance. For instance, it is not possible to combine two existing RUP roles into a single role. If two or more elements in the closure specialize from the same base element, then there exists a conflict.

● Add an activity to an existing role.● Add a workflow detail to an existing discipline.● Add a phase to an existing lifecycle.● Add a tool mentor to an existing tool.● Add a sub-artifact to an existing artifact.● Add input / output artifacts to an existing activity.

The <<rupReplaces>> inheritance relationship allows you to define a specialization of a base element, resulting in a replacement of the generic element. Use replacement of an existing element when you want to:

● Provide a different description of the element.● Suppress an existing activity, workflow detail, phase, or tool mentor via the <<rupNoop>> stereotype.

The recommendation is to use the <<rupContributes>> relationship, as it offers the best support for an additive modeling approach.

The most "dangerous" relationship is the <<rupReplaces>> one, due to its intrusive nature and to the restrictions imposed to the other adjacent relationships. The following rules offer guidance to help you determine the effects of the replacement generalization:

● Replacement always occurs before contributions are considered. As a result, if a contribution receiver (super-class) is replaced, contributions to it are inhibited (cancelled) as shown in Figure 19.

● If a contributor (subclass) is replaced by another class, the replacement occurs first, and then the contributions. So, net effect is that replacing class gets contributed.

● Multi-tiered replacement (e.g. a replaced class replaces another class, which in turn replaces another class as well) leaves the last subclass active.

What these rules mean is that although the diagrams in the model state that certain elements may be present in the modeled process, these values are valid only if the conditions specified by the above constraints hold.

Let's now put in practice the concepts just described and make an existing RUP role become responsible for the CBS artifacts instead of the CBS Integrator. The RUP Integrator will now be responsible for the two artifacts, but since we should not modify a RUP element directly so we will have to use contribution again:

1. Drag the rup_integrator role from RUP Implementation process component, and drop it onto the process_elements class diagram.

2. Select the UML Generalization from the Toolbox view and establish a <<rupContributes>> generalization from cbs_integrator to rup_integrator role. Figure 20 summarizes the model we have created and the elements that embody them.

Figure 20. CBS Implementation structural process

Note that the composition paradigm also allows us to define a same-name activity to the top role, which has the effect that its artifact parameters, tool mentor associations, and workflow detail designations are contributed to the resulting activity in an additive fashion. In addition, any files associated to the contributing activity, such as guidelines, concepts, and so forth, are also contributed to the receiving activity.

ConclusionCongratulations! If you've made it this far, then you've successfully defined a structural process model utilizing the RPW tools. In this installment we have seen how our process model was created using UML notations and described using instances of the classes defined in the RUP metamodel to express concepts that are at a higher level than simple classes and operations. At the type level, processes are represented by class diagrams and by using the stereotypes described in the RUP profile, we can designate process elements to their particular kind. When we applied the stereotypes, we were basically saying to the modeling tool "I have a concept that is almost a class (or operation, association, and so forth), but is more specialized." The expressiveness of the object oriented paradigm and the constructs offered by UML, have proven appropriate to model the structural aspects of processes (e.g.: the elements that take part on it and their relationships).

We have seen that RUP process models are essentially free-form design models with some additional constraints imposed by the RPW. However, the RPW does not constrain the use of regular object-oriented modeling expressions to define variability of process elements. On the contrary, the use of such elements is encouraged and is also required in process model derivation. Therefore, a process model can contain additional model elements beyond the ones recognized by the RPW. For instance, it may be desirable to define artifact dependencies in order to provide a model over all artifacts.

Finally, note that you should avoid doing customizations of the RUP by modifying the RUP base since you might have to redo those customizations whenever new versions of the RUP product become available. By making your customizations through the means of plug-ins, you de-couple your implementation from the RUP so that the two can vary independently.

Resources

● Participate in the discussion forum on this article. (You can also click Discuss at the top or bottom of the article to access the forum.)

● IBM Rational Process Workbench (RPW) v2003.06.13 and Process Engineering Process (PEP) v1.0.

● The Object Management Group's UML page offers good UML information for both beginners and experts.

● The OMG's Software Process Engineering Metamodel (SPEM)

● An enabler for higher process maturity, this paper highlights the key concepts that a mature organization (CMM Level 3) has to demonstrate and how RUP components match these requirements. This is a must read if you are looking to explore software engineering processes, in particular RUP, to successfully fulfill CMM requirements.

● The Rational UML profile for business modeling presents a UML language for capturing business models and is supported by the Business Modeling Discipline in the RUP.

● Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview. CMU/SEI-2002-TR-009.

● Developing New Processes for COTS-Based Systems. L. Brownsword, T. Oberndorf, and C. A. Sledge, IEEE Software, vol. 17, pp. 48-55, 2000.

● Towards a Dedicated Object-Oriented Software Process Modelling Language. Workshop on Modeling Software Process and Artifacts, held at 11th ECOOP by Reimar, W. and Schaefer, W., Jyvaskyta (Finland) (1997).

● The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Addison Wesley, 2003), by Per Kroll and Philippe Kruchten, is an excellent reference on all aspects of the Rational Unified Process.

● Software Process: Principles, Methodology and Technology. Lecture Notes in Computer Science (LNCS), Vol. 1500. Springer-Verlag, Berlin Heidelberg New York (1999), by Derniame, J.-C.; Kaba, B.A.; Wastell, D.

● Models and Tools for Managing Development Processes. B. Westfechtel. LNCS 1646, Springer-Verlag (1999).

About the authorAlfredo Bencomo is a Software Engineer with the IBM RUP infrastructure team in Cupertino, California. He is currently contributing to the technical activities and architecture initiatives aimed at further integrating the RUP infrastructure into the open source platform and the process enactment domain. He is also responsible to develop and deliver the RPW Plug-in Workshop aimed at organizations that wish to adopt RPW for their process customizations.

Rate this article

This content was helpful to me:

Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5)

Send us your comments or click Discuss to share your comments with others.

developerWorks > Rational >