configuration

The application of UML to the design of processes supporting
product configuration management
P. JIANGy, Q. MAIR*z and J. NEWMANz
ySchool of Informatics, University of Bradford, BD7 1DP, UK
zSchool of Computing and Mathematical Sciences, Glasgow Caledonian University, Glasgow G4 0BA, UK

 

Product configuration management (PCM) is an important issue for complex products
with long life cycles. In this paper a unified-modelling-language (UML)-based approach is
introduced to define a PCM process model developed, as part of the Framework V
DIECoM project, for use in the aerospace and automotive industries. This paper presents
an integrated modelling methodology that extends the semantics of UML to support the
automated generation of workflow management coalition (WfMC) XML process
definition language (XPDL) workflow templates from XML metadata interchange
(XMI) definitions. As a result workflow definition is achieved by transforming the XMI
file, representing the serialized UML model, into XPDL by the application of a customized
extensible stylesheet language (XSL) stylesheet. The modelling methodology is illustrated
using the change configuration management process. The process model is defined using
Rational Rose and transformed into XPDL for workflow enactment using ENOVIA LCA.
Keywords: Product configuration management; Business process modelling; Workflow;
UML; XML

 

 

 

1. Introduction
For complex industrial products, such as aircrafts and
automobiles, product configuration management (PCM) is
required in order to organize different configuration
management (CM) teams together to support a complete
product life cycle. This includes both the management of
information about the product and the definition of a
process to manage changes to the product. The managed
information details the hardware, software, processed
materials, services and related technical documentation
making up a complex product; the use of a reliable and
elaborated business process keeps activity schedules and
process information clear, concise and valid and accommodates
the integration of the various actors involved in
the different stages of the life cycle. Consequently a modern
PCM system needs to be able to integrate information from
different domains including product data management
(PDM), software configuration management (SCM) and
electrical data management (EDM). This can be achieved
with the combined aid of (i) a common information model

providing the integrity, correctness and traceability of a
product configuration; and (ii) a process model describing
integrated activities for product configuration.
In the last decade enterprises have attempted to surmount
organizational barriers to form virtual enterprises. In such
virtual enterprises an organization-oriented business approach
is often replaced by a process-oriented business
approach. The life cycle of the development of a processoriented
business process can be described by the three phases
shown in figure 1, i.e. as business process modelling, business
process implementation and business execution phases.
The business process modelling phase is usually conducted
by a business analyst for the purpose of capturing
and understanding a business process. It is modelled based
on existing enterprise business practices or customer
scenarios and may be subject to process evolution and
refinement, e.g. following recommendations from standards
bodies. In terms of configuration management
the International Organisation for Standardization (ISO)
recommends both a data standard (ISO10303) and a
process standard (ISO10007) (Yao and Trappey 2000).

 

Many representations and modelling techniques currently
exist for business process modelling (Aguilar-Saven
2004). One approach is to use a subset of the diagrams
available from the unified modelling language (UML).
UML has proven to be a versatile modelling language for
software development as well as for business systems. As
such there is both a good availability of both UML
computer aided software engineering (CASE) tools and inhouse
expertise in most leading industrial companies.
However UML has nine different diagram types to reflect
different views of a system. Each view is not clearly
orthogonal or complementary and there is a lack of a clear
(and formalized) semantics. There is also a lack of
standardization for applying UML to business process
modelling and any approach may require the use of one of
UML’s extension mechanisms, e.g. stereotypes or profiles.
However as a result this adds additional complexity to the
UML model; a process model defined in UML might
therefore have the drawbacks of being excessively large or
of containing fragmented information.
After the business process modelling phase the model is
transferred to the business process implementation phase.
Here a transformation takes place mapping the model from
the view of the business analyst to that of the IT specialist,
i.e. to a workflow model defined in a workflow definition
language. Usually a workflow definition model will be
generated for computerized enactment, i.e. as a high-level
implementation language that either is directly executable
or can be translated automatically to another target
language. The business execution phase describes the
enactment of this workflow model. Many workflow
definition language standards exist today, e.g. the workflow
management coalition (WfMC) workflow process definition
(XPDL) for distributed workflow (The Workflow
Management Coalition 2002), NIST process specification
language (PSL) for business processes (Schlenoff et al.
2000) and IBM/Microsoft business process execution
language (BPEL) for web services (The Business Process
Management Initiative 2001). However the transformation,

e.g. from UML to XPDL, is usually performed by expert
human intervention, retrieving and combining information
from various UML diagrams and then generating a
workflow model in accordance with the defined operational
semantics of the target workflow definition language. At
this level mismatching or misunderstanding of the corresponding
constructs in the two standards may occur and
thus require the iterative model correction or evolution
shown in figure 1. In fact there is a significant abstraction
gap (Frankel 2003) between business process models and
enactable workflow definitions and research about effective
and reliable mappings is necessary (Koehler and Tirenni
2002).
This paper describes the distributed business model
definition and implementation approach defined in the
DIECoM project. [DIECoM (distributed integrated
environment for configuration management) was an IST
project funded under the EC’s Framework V programme.
DIECoM ran from September 2001 to November 2003.
The project members were: Alenia, Dassault Systemes,
EADS-CCR, IBM, Glasgow Caledonian University,
Renault and SIA. See http://www.diecom.org.]
The central concept of the approach outlined in the
DIECoM project, shown in figure 2, is to design a business
process from its inception incorporating executable semantics.
UML is selected as the modelling language because of
its multiple viewpoints, extensibility and wide acceptance in
industry. While the versatility and flexibility of UML make
its use attractive, its semantics are left largely unspecified or
unclear for business process modelling (Bruno et al. 2002).
Unlike software development, in which the rational unified
process (RUP) outlines a meta-process for software development
projects, there is a lack of guidance on how and
when to apply the use of UML diagrams to define business
process models. This paper defines an organizational
architecture for UML diagrams compliant with the XPDL
meta-process model ofWfMC. In addition, this organization
addresses the abstraction gap by incorporating XPDL
semantics into UML diagrams. The UML process model
can be used to generate the corresponding serialized XML
metadata interchange (XMI) representation for model
exchange (functionality which is available for most UML
tools). Although there are different workflow definition
languages from different vendors and standards bodies, the

reference model defined by WfMC covers features provided
by most vendors. As a result an extensible stylesheet
language (XSL) stylesheet can theoretically be developed
for transformation from UML into any target representation,
e.g. XPDL, BPEL etc. This paper takes the change
configuration management process of PCMdeveloped in the
DIECoM project as a case study example to illustrate the
organization and development of the business process model
for bridging the business view to the IT implementation. In
this case study Rational Rose is used as the UML CASE
tool and DS/IBM ENOVIA LCA is used as the workflow
engine; XPDL is the workflow definition target language.
2. Product change life cycle management and
its IT architecture
The mission of DIECoM is to model, validate and provide
tool support for cross-organizational PCM within the
context of an extended or virtual enterprise. It is expected
to support product evolution in all areas and cover the
entire product life cycle. A product goes through different
steps that constitute this product life cycle: feasibility study,
early definition, development, certification, production and
in-service support. During this long product life cycle (cars/
automobiles about 10 to 15 years; aircraft about 10 to 50
years) a request for product evolution dealing with change
may happen at any stage triggered by:
(i) corrective (mandatory) modification related to a
problem correction;
(ii) evolution of services (e.g. a new customer service
using an onboard internet connection) or improvement
of the product (e.g. a new optimization of an
electronic system for reducing fuel consumption).
Product change management is mainly supported by the
coordinated work of individual domains:
(i) the project/programme management domain
where global product data are managed in configuration
(PCM);

(ii) the systems architecture where the consistency
of the whole system is guaranteed (PDM);
(iii) the electric/electronic/telematic (EET) domain
where electronic hardware data are managed in
configuration (EDM).
(iv) the software domain where software is managed in
configuration (SCM).
Therefore to support effective and efficient evolution of a
complex product it is important to define a change
management process to govern the product change life
cycle. In DIECoM the product change life cycle defined in
figure 3 is used for the automotive and aerospace industries.
In figure 3 the entire evolution life cycle is controlled by
the centralized management of change control. Once a
trigger of change happens the change control unit will
coordinate all the teams involved from the different
domains to go through the following sequence of phases:
(i) change early definition: evaluate a change request
and investigate its repercussions;
(ii) change development: detailed definition of the
engineering change request and integration tests;
(iii) change certification: certification of the product by
the relevant authorities.
(iv) change deployment: update all necessary databases
and send all information necessary to perform the
change;
(v) change application: implementation of the change
and application of the change on new manufactured
products and in-service products.
To support this multidisciplinary and multi-domain development,
an IT infrastructure has been implemented in the
DIECoM project as shown in figure 4. This is a distributed
integration management system connecting various applications
from different domains and further connecting with
the many instances of in-service products via the internet.
As a result the whole distributed system exhibits dynamic
and mobile properties, where in-service products maintain
a relatively loose relation with the manufacturer. For

 

example the owner of a vehicle may change his/her car’s
configuration without informing the car’s manufacturer.
On the off-board PCM system side, the DIECoM system
is organized on top of the DIECoM integration framework
which utilizes IBM’s WebSphere integration product. The
system is structured to conform to IBM’s framework for
e-business, which defines an e-business as an organization
that interacts with its customers, suppliers, business
partners and employees using web technologies. There are
five elements in the integration framework: portal server,
application server, workflow server, integration broker and
connector. Within them the connector enables the access to
the various DIECoM application environments, i.e. PCM
(ENOVIA LCA), PDM (ENOVIA LCA), EDM (CATIA
V5) and SCM (PVCS). The workflow server is used to
distribute, route and track PCM level enquiries and
changes according to a business process model. The
business model is defined in UML using a CASE tool
(Rational Rose) and is transformed into a workflow model
defined in WfMC XPDL for workflow execution. As a
result, product evolution is driven by the UML process
model across different domains to maintain product models
and track changes; these are identified through domain
databases (manufacturing BOM, software DB and hardware
DB) and further integrated into the product DB as a
product configuration skeleton in the PCM system. The
portal server allows users to buy software components
through the internet for in-service product evolution, e.g. a
new service for a car is advertised through a marketing
portal and users can update their cars’ embedded software
remotely. The after sales configuration management
(ASCM) system maintains a catalogue of available services
and defines sales rules (who is permitted to buy the services)
and installation conditions (the compatibility with already
installed components).

 

 

On the in-service product side, the telematic control unit
(TCU) constitutes the telematic gateway of an embedded
system in a product. Through a wireless network (GPRS,
IEEE 802.11b), the product can be connected to the
internet and can be installed with new services remotely
using the OSGi framework. OSGi defines a component
model and provides a dynamic and versatile platform for
embedded software evolution. In OSGi a component is
called a ‘bundle’. Bundles register their services and utilize
the services provided by the other bundles. The framework
manages the bundles and implements the interaction
protocol between the bundles (OSGi Alliance 2000). All
the bundles can be reused and reconfigured. Thus
embedded software development and evolution becomes
writing new components or assembling the existing
components to achieve new functionalities. There are two
types of bundles registered in the framework: one is a
configuration bundle responsible for managing the evolution
process and the others are application bundles
consisting of interface bundles, and implementation bundles
corresponding to changeable software components.
The configuration bundle controls new component installation,
old component removal and component bindings
based on a configuration file written in XML. The
configuration file is an XML fragment extracted from the
in-service product model which defines the software
component version, start sequence, component bindings,
etc. Once evolution is requested a new configuration file is
generated by the ASCM system and downloaded into a
product; the configuration bundle can then control the
evolution of the software components accordingly.
In the DIECoM system shown in figure 4 product
evolution management consists of a centralized PCM
system and multiple mobile on-board configuration systems.
The PCM system on the manufacturer side responds

 

to the change requests from various actors, e.g. managers,
engineers or customers, and provides new services or
upgrades old services. The PCM system can precisely
answer questions of which service can be accepted by what
kind of product configuration and assess the consistency of
a new service in a specific configuration.
Throughout this paper we take the change configuration
management process from product life cycle management
developed in the DIECoM project as a case study example.
3. Organization of UML business process models
compliant with XPDL
A process meta-model can be used to define the top-level
entities contained within a process definition together with
their relationships and attributes. In XPDL a package is
introduced as the container for the workflow processes,
workflow participant specification, workflow application
declaration and workflow relevant data entities, as shown in
figure 5. This forms the basis in this paper for the organization
of UML diagrams for business process modelling.
As previously stated UML has nine different types of
diagram to reflect different views of a system. Each view is
not orthogonal and lacks clear semantics for execution. To
ensure consistency with the WfMC meta-model entities in
figure 5, a conceptual mapping between UML diagrams and
XPDL entities is proposed in table 1, in which a correlation
is established between the types of UML diagram and
XPDL. The organizational relationships of the UML
diagrams in the conceptual model are shown in figure 6.
(1) Use case diagram: corresponds to a package in
figure 5 defining the static relationships between use
cases, actors and the relevant tools involved in a
business process. Provides the functional aspects
detailing the relationships between use cases, actors
and tools.
(2) Actor definition use case diagram: corresponds to a
workflow participant in figure 5 defining the actors
involved in a business process and provides
organizational details about which actors are
involved in the execution of the workflow.

 

 

(3) Meta-data model class diagram: corresponds to
workflow relevant data in figure 5 defining the
product structure and its dependencies. Instances of
the meta-data model precisely describe the components
and composition of any product and provide
informational aspects about what data are passed
during workflow execution;
(4) Tool definition class diagram: corresponds to a
workflow application in figure 5 defining details of
the attached software tools from each of the
integrated application domains, i.e. the PCM,
PDM, SCM and EDM tools;
(5) Statechart diagram, sequence diagram and activity
diagram: these define the dynamic behaviour (i.e. the
workflow) of business processes in a package i.e.
what will be done during workflow execution and
how. The three diagram types play different roles in
business process modelling. Sequence diagrams are
used as an intermediate tool to collect the user

 

 

scenarios of a process for generation of reusable
statechart diagrams and activity diagrams. A
statechart diagram, owned by a use case diagram,
corresponds to a group of workflow processes in
figure 5 collecting together all the discrete states in a
workflow. Each state in a statechart diagram is an
individual workflow process implemented by an
activity diagram. Figure 7 shows the relationship
between a statechart diagram and activity diagrams.
A statechart diagram has a root workflow process
activity diagram as shown in figure 7 which acts as a
top-level process synchronously initiating workflow
process subflows, themselves defined as activity
diagrams for the other states. The activity diagram
owned by each state defines the state’s dynamic
behaviour and may refer to other states as subflows.
This is illustrated in figure 7 by the fact that the
central subflow activity diagram returns control to
the activity diagram associated with the root state.
Therefore a statechart diagram defines the state
space of a use case and activity diagrams define the
behaviour of the states necessary for execution.
Working with this paradigm, business process modelling
using UML becomes a process of collecting the necessary
information for workflow enactment and definition. This
can be achieved by the sequence of steps outlined below:
(1) Analyse each use case to identify the discrete states
of the process and then define the corresponding
statechart diagram describing the corresponding life
cycle. In terms of the DIECoM change life cycle
shown in figure 3, in total of six independent states
can be identified i.e. change control, change early
definition, change development, change certification,
change deployment and change application.
Change control is the root process as shown in

 

figure 7 that coordinates the different states
managing the entire change life cycle. A statechart
is then used to describe these states, state change
relationships and the input/output data to a state/
process as shown in figure 8. Therefore a statechart
is a high-level abstraction of a process.
(2) Manual collection of workflow instances in terms of
each state into sequence diagrams. A thorough
investigation of workflow instances in terms of
every identified state is conducted, by scenarios
analysis, considering existing business processes
and an appraisal of international standards
recommendations e.g. ISO10007 for product configuration
management. Sufficient instances are
expected to reflect all aspects of a state and each
instance results in a sequence diagram as a formal
description;
(3) Workflow extraction from the instances of each state
to form an executable activity diagram. The sequence
diagrams representing state instances are merged
into a unique activity diagram. Some sophisticated
approaches can be adopted for carrying out this step
e.g. the inducing method (Herbst and Chrysler 1999)
and the discovery method (Hwang and Yang 2002).
The generated activity diagram is the workflow
process definition for the state. It addresses all
activity instances described by the collected sequence
diagrams. It is necessary that activity diagrams
contain all the information needed for workflow
execution. The next sections detail how UML can be
extended in order to capture all the necessary
information and how to generate an XPDL workflow
template automatically.
4. Workflow entity definition in UML models
(It should be noted that this section outlines work based on
UML 1.4. The authors note, however, that UML 2.0 has
substantially revised the semantics of activity diagrams,
bringing them into line with Petri nets.)
In the proposed UML-based business process modelling,
we define a workflow definition (process or sub-process)
using activity diagrams. Although activity diagrams in
UML 1.X are special cases of UML state diagrams their
semantics are left largely unspecified or, for some features,
not defined strictly enough to be used directly as a
workflow modelling language for input into a workflow
engine. In other words simply defining a process using
activity diagrams in UML cannot include all the necessary
and detailed information for workflow execution. The
solution is to specify the workflow entities required by
XPDL, e.g. transition, relevant data and participant as a
Figure 7. Statechart and activity diagrams. mapping using UML stereotypes, attributes, actions and

 

swimlanes, etc. An activity diagram can thus be defined in a
way with sufficient detail to be compliant with the WfMC
meta-model. A general conceptual mapping between
activity diagram elements and XPDL workflow entities is
proposed in table 2.
The detail the UML implementation of the mapping is
presented in the following subsections.
4.1. Workflow process activity
A process definition consists of one or more activities with
different implementation types. We define the following
stereotypes in UML to distinguish these implementation
types:
(1) <<Route>>
A stereotype <<Route>> denotes a dummy
activity for the implementation of split or join
transitions. In XPDL the ‘transition restriction’
attribute of a route should be assigned with a type
of either AND or XOR.
(2) <<No>>
An activity with a stereotype of <<No>> means
that it is a manual activity performed by human

actors. As a result the activity attribute of ‘finish
mode’ can be set to manual mode that requires
explicit user interaction to cause the activity to
finish. As a participant of no implementation
activity, the performer should be always of the
HUMAN type.
(3) <<Tool>>
An activity with a stereotype of <<Tool>> means
that the activity is implemented by one or more
application programs. The activity definition of
XPDL is required to provide extra information
including application name, application type and
invocation parameter to the workflow management

 

system. In UML we define the information using
the action specification for a given activity as shown
in table 3.
(4) <<Subflow>>
An activity with the <<Subflow>> stereotype is
refined as a subflow invocation. The states in the
statechart diagram are <<Subflow>> activities
with their associated activity diagram as the body of
the subflow. The subflow associated attributes are
subflow Id, execution manner and actual parameters.
Wedefine the following mapping relationship
between UML and XPDL using action specification
in the activity diagram as shown in table 4.
(5) <<Loop>>
The activity <<Loop>> stereotype indicates
repetitive execution of a loop body that is defined
by a sub-diagram of the parent activity diagram.
The corresponding loop condition can be defined
in two different ways: ‘WHILE. . . .DO. . .’ and
‘REPEAT. . .UNTIL’ which are defined by the
‘loop kind’ attribute as shown in table 5.
4.2. Workflow transition
Workflow execution is based on a network of connected
activities. The transition information defines the connections
and conditions that enable or disable a transition.
There are three types of transition. A ‘NOLOOP’-type
transition represents the regular sequential execution of a
workflow and the ‘FROMLOOP’ or ‘TOLOOP’ transitions
only connect with a <<Loop>> activity to indicate entry
or exit to/from a loop body. In addition to the transition

 

 

types a transition definition should provide information
about the connected source and target. This is defined using
‘From’ and ‘To’ attributes associated with a transition in
XPDL. Table 6 summarizes the defined mapping between
UML and XPDL.
4.3. Workflow participant
Workflow participant defines actors or applications that
can act as the performers of various activities. There are six
types of workflow participants: resource set, resource,
organizational unit, role, human and system. The mapping
between UML concepts and XPDL workflow participant
definitions is defined as shown in table 7 below. The
participant ‘Id’ should be an instance of any actor or tool
defined in the DIECoM main actors use case diagram or
the DIECoM tools class diagram.
4.4. Workflow application
The workflow application declaration is a list of applications
or tools required and invoked by a workflow process.
Only the ‘Id’ of an application should be defined. In
a workflow package we collect all activities with a
<<Tool>> implementation type and take the application
or procedure name as the associated workflow application
declaration (within a particular package scope).
4.5. Workflow relevant data
Workflow relevant data define all data objects, which are
required and processed by a workflow activity. In UML we

 

 

use the On_Entry and On_Exit actions to represent the ‘IN’
and ‘OUT’ data of a workflow activity respectively.
‘DataType’ is constrained to Basic Type and Declared
Type. The Basic Type includes string, float, integer,
reference and datetime. The Declared Type can be any
user-defined class e.g. DIECoMDATA as defined in the
DIECoM project. Therefore the mapping of UML definitions
to XPDL definitions can be described as in table 8.
Based on the workflow relevant data of an activity
diagram, the Formal Parameters of XPDL can define the
parameters passed to an activity diagram implementing a
process or subflow. In the proposed organization of UML
diagrams any process or subflow is represented by a state in
a statechart; therefore the declaration of Formal Parameters
should be given for all states in a statechart diagram
using the On_Entry and On_Exit event attributes as defined
in table 8. An example of the definition of Formal
Parameters in UML can be found in figure 8. For example,
the state of ‘certification’ has three formal parameters: ECO
as input, CertificationDossier and JustificationDossier as
output. When the certification subflow is invoked these
parameters must be transferred into the certification activity
diagram. See the certification activity in figure 9.
5. Change control workflow definition as a UML model
After mapping the XPDL entities to UML all states in
figure 8 can be refined by activity diagrams for workflow
definition. This section will take the change control state as
an example to illustrate its workflow model in UML.
The change control state in figure 8 is an abstraction of
the entire change management life cycle and can be refined

 

 

by a root process in a form of activity diagram. As the main
process of the entire change life cycle the change control
state coordinates all the teams involved from the different
domains that go through the change life cycle. The change
control process is started upon reception of a change
request (CR). This change request may come from the:
(i) quality or customer support division of a manufacturer
or in special cases directly from a customer
or one of the suppliers; this is particularly true for
corrective change requests;
(ii) marketing division of a manufacturer or directly
from a customer for innovative evolution of
products and/or services;
(iii) engineering department of a manufacturer;
(iv) manufacturing department of a manufacturer.
When a CR is received the first action is the evaluation
of the request. This activity, lead by the change
request management committee (CRMC), decides if
the request has grounds for being developed. If the CR is
accepted the change control process starts a sequence
of subflows and an engineering change request is initiated
by the CRMC in order to be able to study the change
request:
(1) Change early definition evaluates a change request
and investigates any potential repercussions. Technical
activities are carried out to identify possible
solutions to the change request (CR). An associated
engineering change request (ECR) is gradually
enriched by a multi-disciplinary team so that the
development process can achieve an optimum
solution.
Type: Sub-process
Formal parameters:
Input parameter: CR
Input and output parameters: ECR
(2) Change development for detailed definition of
engineering change request and integration tests.
Develop and validate the new configuration for
products after change early definition has been
carried out. An associated engineering change order
(ECO) is enhanced. A change note is created by
multi-disciplinary experts for deployment purposes
and relevant product/service data are updated in
the BOM, PDM, EDM and SCM databases.
Type: Sub-process
Formal parameters:
Input parameter: ECR
Input and output parameters: ECO
Output parameter: Change Note
(3) Change certification: The change is certificated by
relevant authorities.

 

 

Type: Sub-process
Formal parameters:
Input parameter: ECO
Output parameter: CertificationDossier and
JustificationDossier
(4) Change deployment for updating all necessary databases
and sending all necessary information to perform
the change: On receiving the released engineering
change order (ECO) change notes are refined and
issued in order to transfer information to other
departments (production units, marketing, in-service,
etc.). Change notes define clearly which
product/services are impacted and when, i.e. whether
the change will be applicable on new and/or inservice
products, that the change will concern only a
batch of products or that it will be applicable on all
products being manufactured from a given date.
Type: Sub-process

 

 

Formal parameters:
Input parameter: ECO
Input and output parameter: change note
(5) Change application: Apply the change to all
impacted departments identified in the change note
e.g. in after-sales a new service is ready for updating
in-service products and mandatory correction is
issued to the impacted customers through the inservice
support network.
Type: Sub-process
Formal parameters:
Input parameter: change note
All the identified activities and the associated information
of the change control process are collected and summarized
in table 9.
Following the approach used for the definition of
workflow entities proposed in section 4 and the change

 

 

control process summary in table 9, the workflow process
can be represented as a UML activity diagram compliant
with the WfMC meta-model.
In the activity diagram in figure 9 we use UML
swimlanes to delineate workflow performers. Additionally,
as outlined in section 4, we use On_Entry and On_Exit
actions for input and output data definition and transition
guard conditions. In addition to the <<No>> manual
implementation stereotype, stereotypes of <<Subflow>>
and <<Loop>> have been used to support the hierarchical
organization of the process model. An activity with the
<<Subflow>> stereotype specifies that a state transition
happens and the associated activity diagram of this subflow
is specified by the XPDL actual parameters attribute e.g.
the change development subflow will be defined in an
XPDL file called AC_ChangeDevelopmentXPDL.xml. The
activity of change early definition loop has a <<Loop>>
implementation stereotype. Following the definition in
section 4 we use the events of an activity to define
associated attributes. In this example we define a REPEAT
. . .UNTIL loop with a loop body defined as an activity
named ChangeEarlyDefinitionLoopBody. The loop body is
defined as a sub-diagram of the calling activity. With
reference to table 9, there are three activities in the loop
body. The sub-diagram ChangeEarlyDefinitionLoopBody
is shown in figure 10.
6. XSL stylesheet transformation from UML to XPDL
At this point a UML process model has been defined which
is compliant with XPDL covering all the descriptive
features of a workflow necessary for the purposes of
execution. A business process manager can therefore
analyse and define a business process and define its

 

 

runtime details using UML with a standard CASE tool
e.g. Rational Rose. XMI, as proposed by OMG, is an
XML-based language intended to facilitate the serialization
of UML models thus enabling the easy interchange
of metadata between CASE tools and between metadata
repositories in distributed heterogeneous environments.
For example Rational Rose provides an XMI add-on for
serializing and exporting a UML model to an XMI file. In
this work the defined UML process model is exported to
XMI facilitating integration with workflow engines, i.e. it
acts as an intermediate language between business analysis
and workflow definition. Owing to the popularity of
XML-based languages several workflow standards are
defined in terms of XML and most current generation
workflow engines can accept one or more of these XMLbased
workflow standards. As a result the integration of
business analysis with workflow engines can be reduced to
the process of XML translation shown in figure 2. XSL
transformation (XSLT) is a mechanism used to transform
an XML document into another format and therefore can
be applied here to support different XML-based workflow
definition formats. To carry out an XSLT transformation,
three components are required:
(i) the XML document that is to be transformed;
(ii) an XSL stylesheet, which will contain the instructions
for the transformation: a different stylesheet
is necessary here for every target workflow definition
format;
(iii) an XSLT engine, which is a software tool used to
carry out the transformation instructions in the
stylesheet.
In the DIECoM project ENOVIA LCA contains a workflow
server that can import and enact XPDL templates.

 

 

Therefore an XSL stylesheet for transformation from XMI
to XPDL has been defined (see Appendix A).
The extensible style sheet language (XSL) is an XMLbased
language used to create stylesheets. These stylesheets
contain details of the desired output (result tree), as well as
details of the input data to be transformed (source tree).
The input is not processed sequentially line by line. Rather
the input XML document is treated as a tree structure. An
XSLT stylesheet consists of a set of template rules, each of
which takes the form ‘if this condition is encountered in the
input, then generate the following output.’ Each template
rule is applied to a node in the tree.
For XMI to XPDL translation, transformation templates
are the fundamental structure used in the creation of
XSLT stylesheets. They identify workflow-relevant information
in an XMI file (source tree) as well as providing a
description of what the corresponding XPDL output
should be (result tree). A top-level template of the
stylesheet mapping the root of an XMI tree to the root of
an XPDL tree, while defining the overall structure of
XPDL, can be found in Appendix A.
In this root template, a workflow package is built for
each use case diagram. All contained processes are the
states of the associated statechart diagram. Each process
can be further defined by the state’s activity diagram. The
process entities, e.g. data fields definition, participants
definition, activities definition and transitions definition,
can be detailed by retrieving the relevant information from
XMI according to the mapping definition in section 4. The
information retrieval is achieved by applying templates
specifically for detecting particular information from a
specific XMI tree. As a result the task of translating XMI to
XPDL (or to any other target workflow definition
language) is to reorganize the workflow-relevant information
into a particular target structure. The developed XMI
to XPDL stylesheet has been successfully demonstrated in
the DIECoM project, integrating Rational Rose with
ENOVIA LCA thus linking two well-known and widely
accepted standards and their definition formats together.
7. Conclusions
One of the fundamental premises of virtual enterprises is
that they must leverage existing methodologies and
integrate existing toolsets to have viable uptake. Many
high technology products are now so complicated that it is
impossible for deliverables to be produced by single
companies. For any set of companies coming together in
collaborative partnership to design and maintain a complex
product, an engineering process model must be defined
which integrates the working practices of PDM, EDM and
SCM. The helps to ensure the proper integration of all the
work necessary to create or change the product, and also
the quality of the resultant changes.

 

 

We have shown that it is possible to use the industry
standard UML tool to design such collaborative workflows
by extending the semantics of UML. We have used UML
as a business process modelling language and as a
computer-interpretable workflow modelling language simultaneously.
As a result business process managers can
analyse business processes and specify execution details for
workflow enactment. This simplifies the iterative development
and evolution of a business process model by
connecting a UML environment with a workflow engine
directly. In order to close the abstraction gap between
business process model design and workflow definition the
WfMC process meta-model is articulated into UML. This
allows all the information necessary to define the workflow
definition as the business process model in the form of
standard UML statechart and activity diagrams. A defined
business process model is then serialized in XMI. A
customized XSL stylesheet can be developed to automate
the transformation of XMI to the target workflow
definition language.
As a case study we took, from the DIECoM project
results, the change configuration management process from
product life cycle management to demonstrate the proposed
modelling method. Rational Rose and ENOVIA LCA were
used as the UML modelling CASE tool and workflow
engine respectively. An XSL stylesheet defining the transformation
from UML to XPDL was developed and
demonstrated successfully as part of the DIECoM project.
Acknowledgements
The authors are grateful to the partners and reviewers of
the DIECoM project for their work in supporting this
research. In addition they are grateful to the European
Commission for funding the project under its Framework
V programme (Project IST 2000–2870).
Appendix A: XSL stylesheet from UML to XPDL
5xsl:template match¼"/"4
1) Package definition
5xsl:element name¼"Package"4
5xsl:attribute name¼"Id"4
5!–Get the Use Case Diagram name from
XMI–4
5/xsl:attribute4
5xsl:attribute name¼"Name"4
5!–Get Use Case Diagram name from
XMI–4
5/xsl:attribute4
5xsl:attribute name¼"xmlns:xpdl"4http://
www.wfmc.org/standards/docs/xpdl