TOWARDS A RIGOROUS PROCESS MODELING WITH SPEM

Benoit Combemale, Xavier Cr

egut

IRIT-LYRE

2, rue Charles Camichel, BP 7122

F-31071 Toulouse Cedex 7

Alain Caplain, Bernard Coulette

GRIMM-ISYCOM

5, allee Antonio Machado

F-31058 Toulouse Cedex 9

Keywords:

Process engineering, Model engineering, SPEM, Semantics, OCL.

Abstract:

Modeling software process is a good way to improve development and thus quality of resulting applications.

The OMG proposes the SPEM metamodel to describe software processes. Its concepts are described through

class diagrams. Unfortunately, it lacks a formal description of its semantics that makes it hard to use. So, we

propose a specialization of SPEM that clariﬁes it and we use OCL to formally express constraints on it.

1 INTRODUCTION

A software application is a complex product which

must be elaborated using a speciﬁc method : the soft-

ware development process. The main aim of such a

process is to guarantee the development of reliable

software, conforming to their speciﬁcation within ex-

pected deadlines and costs. Mastering the software

appears to be a necessity because of the growing com-

plexity and critical aspects of software. This must be

done with the aim of obtaining better quality and im-

proving reuse. The industrialization of software de-

velopment began with methods like OMT and grew

at the end of the 90’s with uniﬁcation proposals such

as UML and RUP. Today, the last step is the use of

Model Driven Engineering (MDE) for working on the

complete lifecycle of software artifacts.

MDE (B

ezivin, 2004) appeared with OMG propos-

als such as MOF (omg, 2002) and MDA (Miller and

Mukerji, 2003). It tries to unify processes detailing

with the crucial aim of reusing them. SPEM (Soft-

ware Process Engineering Metamodel) (omg, 2005)

is one of the OMG proposals. It is a metamodel for

software development process speciﬁcation that gives

a rigorous syntax but only partly formalizes the se-

mantics (thus implying some ambiguities), and does

not offer any help on how to build a process model. It

is why we have deﬁned a specialization for its rigor-

ous exploitation (Combemale, 2005). We ﬁrst present

the main concepts of SPEM (section 2) and then our

specialization of SPEM (section 3). Before the con-

clusion, we present related works on section 4.

2 PRESENTATION OF SPEM

SPEM is a metamodel used for the speciﬁcation of

concrete software development process. It offers an

object oriented approach using the UML notation. As

an OMG proposal, SPEM is integrated in the pyrami-

dal architecture of MDA organization as a MOF meta-

model and as a UML proﬁle (Breton and B

ezivin,

2001). SPEM takes up a great deal of UML diagrams

(packages, use cases, classes, activities, sequences,

statechart), excludes some elements (node, compo-

nent, etc.) (omg, 2005, §11.1) and adds several stereo-

types that are presented hereafter (omg, 2005, §11).

SPEM is based on the idea (ﬁg. 1) that a software

development process is a collaboration between active

abstract entities called roles which perform operations

called activities on concrete and real entities called

Figure 1: SPEM conceptual model.

530

Combemale B., Crégut X., Caplain A. and Coulette B. (2006).

TOWARDS A RIGOROUS PROCESS MODELING WITH SPEM.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 530-533

DOI: 10.5220/0002455205300533

 SciTePress

Figure 2: Process Structure package of SPEM.

work products. The different roles act upon one an-

other or collaborate by exchanging products and trig-

gering the execution of certain activities. The objec-

tive of a process is to lead a set of products to a well

deﬁned state.

In fact, the SPEM metamodel is more complex.

The extract given on ﬁg. 2 proves it. SPEM deﬁnes

the concept of WorkDeﬁnition which can be decom-

posed reﬂexively. Beside the activities there are other

specializations which are not drawn on ﬁg. 2: Lifecy-

cle which is a sequence of Phases and Iterations to de-

ﬁne a complex work. An Activity can be divided into

Steps. A step is a specialization of ActionState (ﬁg. 2)

which implies a partial order (omg, 2004, §4.12).

Each WorkDeﬁnition is under the responsibility of

a unique role (ProcessPerformer). In the case of an

Activity, a set of other roles (ProcessRole) can assist

the main role for the realization.

SPEM also deﬁnes two important concepts :

Process and Discipline. A Process corresponds to the

root of a process model from which a tool can do the

transitive closing of a complete process. A Discipline

allows, within the process, to partition activities ac-

cording to a common “theme”. The output products

of each of the activities of a discipline must be cate-

gorized under this same theme.

3 ADDING RIGOR TO SPEM

Using SPEM is difﬁcult because the OMG proposal

is very generalist and provides no directives on how

to use it. Furthermore, its semantics is essentially

expressed in natural language that leads to the con-

struction of inconsistent process models because of

the lack of a formal deﬁnition of concepts. For ex-

ample, the ProcessPerformer is a concept known as

being ambiguous (Bendraou et al., 2005).

So, we have decided to deﬁne a specialization of

the SPEM metamodel whose purpose is to clearly de-

ﬁne concepts and formally express their semantics

with OCL (omg, 2003). Being more directive, our

proposal brings more assistance in the industrial con-

struction of a process and more facility in the use

of SPEM. Thanks to the restrictions put on SPEM,

it is possible to ensure the coherence of its models.

Our proposal being a restriction of SPEM, our mod-

els conforms to SPEM.

3.1 SPEM Metamodel Specialization

Our metamodel (ﬁg. 3) divides process models ac-

cording to two main views. The structural view shows

the process hierarchy : a process is associated to a

lifecycle cut out in phases, themselves made up of ac-

tivities (and iterations). The descriptive view details

work deﬁnitions. It makes possible to classify them

according to process roles and thus disciplines. Work

deﬁnitions are speciﬁed through preconditions, goals

and products used or realized.

As in SPEM, WorkDeﬁnition metaclass is a con-

crete class. It allows to instantiate WorkDeﬁnitions

which will not be typed yet and thus not yet semanti-

cally deﬁned in the process (e.g. analysis phase).

Because ProcessPerformer (ﬁg. 2) has no clear

semantics in the initial SPEM metamodel, we have

merged it with ProcessRole. This merge avoids con-

TOWARDS A RIGOROUS PROCESS MODELING WITH SPEM

531

Figure 3: Extract of our specialization of SPEM metamodel.

fusion between ProcessPerformer and ProcessRole

by only deﬁning role which is a set of capabilities.

In addition, most of the relations of our proposal

are taken again from the original metamodel, either

as is or by specialization. Thus, associations between

Lifecycle, Phase, Iteration and Activity metaclasses ﬁt

to the redeﬁnition of reﬂexive relation of the WorkDe-

ﬁnition metaclass of SPEM (ﬁg. 2). We have con-

strained the multiplicity of the source of “0..*” by “1”

(thus giving the composition semantics).

The relations which are not directly taken from

SPEM metamodel are inherited or deduced from

UML 1.4 (from the Core package, (omg, 2004, p.22)).

For example, the reﬂexive relation on WorkProduct is

a deduction of the relations that link Classiﬁer meta-

classes in UML. The “use” and “realize” relations be-

tween WorkDeﬁnition and WorkProduct are also de-

duced from UML as shown on ﬁg. 2. They allow

to make explicit the relations described in the SPEM

conceptual model (ﬁg. 1).

3.2 Semantic Details with OCL

Because syntactic added is not sufﬁsant to seman-

tically deﬁne the metamodel, we have used OCL

(as recommended by the OMG) to add formal con-

straints. These constraints limit the possible instan-

ciations and thus the valid process models. Here is

an example of such a constraint : “A role must be re-

sponsible for all the products carried out by activities

of which he is in charge, and reciprocally”.

context ProcessRole inv :

let productsActivities : Set{WorkProduct} =

– Deﬁnition of the WorkProduct set made by

– the activities of which ’self’ is responsible

self.work→ select(a:WorkDeﬁnition |

a.oclIsT ypeOf (Activity)).

oclAsT ype(Activity).output→ asSet()

self.workProduct = productsActivities

Another OCL constraint formalizes the merge of

ProcessPerformer and ProcessRole (sec. 3.1) in pro-

hibiting the instanciation of the ProcessPerformer:

context ProcessPerformer inv :

self.allInstances() → size() = 0

The static checks that we made are not sufﬁcient

and there should be extra dynamic checks. For exam-

ple, it is impossible to ensure before enactment that an

activity will respect its time limit but it can be checked

during enactment. Furthermore, this kind of check

is meaningful only during real project enactment and

not during process model simulation. Let us note that

a process model can not generally be completely de-

ﬁned before the project starts. If the great stages of the

development are generally known, the detail of their

realization depends on the difﬁculties encountered at

the time of their realization. It could then be neces-

sary to reinforce a team, to consider other solutions

or another approach.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

532

4 RELATED WORKS

The process modelling domain has been very ac-

tive during the 90’s. There was a strong separation

between Process Description Languages (PDL) and

process enactment engines. PDL could be classiﬁed

into different categories: some of them were based on

programming languages (ProcessWise/PML (Green-

wood et al., 1992) or RHODES/PBOOL (Cr

egut and

Coulette, 1997)), others on rules (MARVEL/MSL

(Kaiser et al., 1988), ADELE/TEMPO (Warboys,

1994) or EPOS/SPELL (Warboys, 1994)), others on

petri nets (SPADE/SLANG (Bandinelli et al., 1995)),

and the others are hybrid solutions. Each of these lan-

guages had its own speciﬁc tools.

The actual tendancy is to unify PDL. Let us quote

for example SPEM metamodel suggested by the

OMG and XML-based languages like XPDL (XML

Process Description Language) (WfMC, 2005) pro-

posed by the WfMC(Workﬂow Management Coali-

tion) or BPML (Business Process Management Lan-

guage) (Arkin, 2002) proposed by the BPMI (Busi-

ness Process Management Initiative). All these ap-

proaches deﬁne LDP’s concepts (Breton, 2002) by

proposing a syntax in the form of a metamodel for

SPEM or a XML schema for XPDL and BPML. Se-

mantics is only described informally (in natural lan-

guage). Furthermore, process enactment is not for-

mally deﬁned even if there are speciﬁc engines for

speciﬁc targets (e.g. BPEL4WS & BPEL-J).

5 CONCLUSION

In this article, we have presented our work on the

modelling of software processes. Because the SPEM

metamodel lacks rigorous and formal deﬁnition, we

have proposed a restriction of SPEM that remains

compatible with the standard and puts the focus on hi-

erachical decomposition of workdeﬁnitions (the struc-

tural view) and the categorization of process com-

ponents (roles, products and workdeﬁnitions) accord-

ing to disciplines (the descriptive view). Semantics

that are not graphicaly captured are expressed using

OCL constraints either at the metamodel level or at

the process level. Our SPEM specialization has been

used to model a UML based method called MACAO

(Combemale et al., 2006).

Unfortunately, OCL can only capture structural

constraints. Our future work is to deﬁne an opera-

tional semantic for SPEM in order to enact a process

model described in SPEM. So we are investigating

several approaches including the ones that describe

operational semantics for metamodel such as Ker-

meta, Xion and xOCL.

REFERENCES

(2002). Meta Object Facility (MOF) 1.4 Speciﬁcation.

OMG, Inc. Final Adopted Speciﬁcation.

(2003). Business Process Execution Language for Web Ser-

vices v1.1.

(2003). UML Object Constraint Language (OCL) 2.0 Spec-

iﬁcation. OMG, Inc.

(2004). Uniﬁed Modeling Language (UML) 1.4.2 Speciﬁ-

cation. OMG, Inc.

(2005). Software Process Engineering Metamodel (SPEM)

1.1. OMG, Inc.

Arkin, A. (2002). Business Process Modeling Language.

Business Process Management Initiative.

Bandinelli, S., Fuggetta, A., Lavazza, L., Loi, M., and

Picco, G. P. (1995). Modeling and improving an in-

dustrial software process. IEEE Transactions on Soft-

ware Engineering, 21(5):440–454.

Bendraou, R., Gervais, M.-P., and Blanc, X. (2005).

Uml4spm : A uml2.0-based metamodel for software

process modelling. In MoDELS’05, volume 3713,

pages 17–38. Springer-Verlag.

Breton, E. (2002). Contribution

a la repr

esentation de

processus par des techniques de m

eta-mod

elisation.

PhD thesis, Nantes University.

Breton, E. and B

ezivin, J. (2001). Process-centered model

engineering. In 5th IEEE International Enterprise

Distributed Object Computing Conference, Seattle,

Washington, USA. IEEE Computer Society.

ezivin, J. (2004). In search of a basic principle for

model driven engineering. CEPIS, UPGRADE, The

European Journal for the Informatics Professional,

V(2):21–24.

Combemale, B. (2005). Sp

eciﬁcation e t v

eriﬁcation d e

mod

eles de proc

es de d

eveloppement. Master’s the-

sis, Toulouse II University, Master SLCP.

Combemale, B., Cr

egut, X., Caplain, A., and Coulette, B.

(2006). Mod

elisation rigoureuse en SPEM de proc

de d

eveloppement. In Lavoisier, H. S. ., editor, LMO

2006, pages 135–150.

egut, X. and Coulette, B. (1997). PBOOL: an object-

oriented language for deﬁnition and reuse of enactable

processes. Software Concepts & Tools, 18(2).

Greenwood, R. M., Guy, M. R., and Robinson, D. J. K.

(1992). The use of a persistent language in the imple-

mentation of a process support system. ICL Technical

Journal.

IBM and BEA (2004). BPELJ: BPEL for Java.

Kaiser, G. E., Feiler, P. H., and Popovich, S. S. (1988). Intel-

ligent Assistant for Software Development and Main-

tenance. IEEE software, 5(3):40–49.

Miller, J. and Mukerji, J. (2003). Model Driven Architecture

1.0.1 Guide. OMG, Inc.

Warboys, B. C., editor (1994). Proc. of EWSPT’94, volume

772 of LNCS. Springer–Verlag.

WfMC (2005). Process Deﬁnition interface – XML Process

Deﬁnition Language v2.0.

TOWARDS A RIGOROUS PROCESS MODELING WITH SPEM

533