International audienceModeling 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 clarifies it and we use OCL to formally express constraints on it

Caplain, Alain

Combemale, Benoit

Coulette, Bernard

Crégut, Xavier

Scientific Publications of the University of Toulouse II Le Mirail

Towards a rigorous use of SPEMBenoˆıt Combemale, Xavier Cre´gut, Alain Caplain, Bernard CouletteTo cite this version:Benoˆıt Combemale, Xavier Cre´gut, Alain Caplain, Bernard Coulette. Towards a rigorous useof SPEM. Yannis Manolopoulos, and Joaquim Filipe, and Panos Constantopoulos, and Jose´Cordeiro. Eighth International Conference on Enterprise Information Systems, May 2006,Paphos, Cyprus. INSTICC, pp.530-533, 2006. <hal-00369873>HAL Id: hal-00369873https://hal.archives-ouvertes.fr/hal-00369873Submitted on 22 Mar 2009HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestine´e au de´poˆt et a` la diffusion de documentsscientifiques de niveau recherche, publie´s ou non,e´manant des e´tablissements d’enseignement et derecherche franc¸ais ou e´trangers, des laboratoirespublics ou prive´s.TOWARDS A RIGOROUS PROCESS MODELING WITH SPEMBenoit Combemale, Xavier Cre´gutIRIT-LYRE2, rue Charles Camichel, BP 7122F-31071 Toulouse Cedex 7{benoit.combemale, xavier.cregut}@enseeiht.frAlain Caplain, Bernard CouletteGRIMM-ISYCOM5, allee Antonio MachadoF-31058 Toulouse Cedex 9{caplain, coulette}@univ-tlse2.frKeywords: 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 throughclass diagrams. Unfortunately, it lacks a formal description of its semantics that makes it hard to use. So, wepropose a specialization of SPEM that clarifies it and we use OCL to formally express constraints on it.1 INTRODUCTIONA software application is a complex product whichmust be elaborated using a specific method : the soft-ware development process. The main aim of such aprocess is to guarantee the development of reliablesoftware, conforming to their specification within ex-pected deadlines and costs. Mastering the softwareappears to be a necessity because of the growing com-plexity and critical aspects of software. This must bedone with the aim of obtaining better quality and im-proving reuse. The industrialization of software de-velopment began with methods like OMT and grewat the end of the 90’s with unification proposals suchas UML and RUP. Today, the last step is the use ofModel Driven Engineering (MDE) for working on thecomplete lifecycle of software artifacts.MDE (Be´zivin, 2004) appeared with OMG propo-sals such as MOF (omg, 2002) and MDA (Miller andMukerji, 2003). It tries to unify processes detailingwith the crucial aim of reusing them. SPEM (SoftwareProcess Engineering Metamodel) (omg, 2005) is oneof the OMG proposals. It is a metamodel for softwaredevelopment process specification that gives a rigo-rous syntax but only partly formalizes the semantics(thus implying some ambiguities), and does not offerany help on how to build a process model. It is why wehave defined a specialization for its rigorous exploi-tation (Combemale, 2005). We first present the mainconcepts of SPEM (section 2) and then our specializa-tion of SPEM (section 3). Before the conclusion, wepresent related works on section 4.2 PRESENTATION OF SPEMSPEM is a metamodel used for the specification ofconcrete software development process. It offers anobject oriented approach using the UML notation. Asan OMG proposal, SPEM is integrated in the pyrami-dal architecture of MDA organization as a MOF me-tamodel and as a UML profile (Breton and Be´zivin,2001). SPEM takes up a great deal of UML dia-grams (packages, use cases, classes, activities, se-quences, statechart), excludes some elements (node,component, etc.) (omg, 2005, §11.1) and adds severalstereotypes that are presented hereafter (omg, 2005,§11).SPEM is based on the idea (fig. 1) that a softwaredevelopment process is a collaboration between activeabstract entities called roleswhich perform operationscalled activities on concrete and real entities calledFIG. 1: SPEM conceptual modelFIG. 2: Process Structure package of SPEMwork products. The different roles act upon one ano-ther 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 welldefined state.In fact, the SPEMmetamodel is more complex. Theextract given on fig. 2 proves it. SPEM defines theconcept of WorkDefinition which can be decomposedreflexively. Beside the activities there are other spe-cializations which are not drawn on fig. 2 : Lifecyclewhich is a sequence of Phases and Iterations to de-fine a complex work. An Activity can be divided intoSteps. A step is a specialization of ActionState (fig. 2)which implies a partial order (omg, 2004, §4.12).Each WorkDefinition is under the responsibility ofa unique role (ProcessPerformer). In the case of anActivity, a set of other roles (ProcessRole) can assistthe main role for the realization.SPEM also defines two important concepts : Pro-cess andDiscipline. A Process corresponds to the rootof a process model from which a tool can do the tran-sitive closing of a complete process. A Discipline al-lows, within the process, to partition activities accor-ding to a common “theme”. The output products ofeach of the activities of a discipline must be categori-zed under this same theme.3 ADDING RIGOR TO SPEMUsing SPEM is difficult because the OMG proposalis very generalist and provides no directives on howto use it. Furthermore, its semantics is essentially ex-pressed in natural language that leads to the construc-tion of inconsistent process models because of thelack of a formal definition of concepts. For example,the ProcessPerformer is a concept known as beingambiguous (Bendraou et al., 2005).So, we have decided to define a specialization ofthe SPEM metamodel whose purpose is to clearlydefine concepts and formally express their seman-tics with OCL (omg, 2003). Being more directive,our proposal brings more assistance in the industrialconstruction of a process and more facility in the useof 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 modelsconforms to SPEM.3.1 SPEM metamodel specializationOur metamodel (fig. 3) divides process models ac-cording to two main views. The structural view showsthe process hierarchy : a process is associated to a li-fecycle cut out in phases, themselves made up of ac-tivities (and iterations). The descriptive view detailswork definitions. It makes possible to classify themaccording to process roles and thus disciplines. Workdefinitions are specified through preconditions, goalsand products used or realized.As in SPEM, WorkDefinition metaclass is aconcrete class. It allows to instantiateWorkDefinitionswhich will not be typed yet and thus not yet semanti-cally defined in the process (e.g. analysis phase).Because ProcessPerformer (fig. 2) has no clear se-mantics in the initial SPEMmetamodel, we have mer-ged it with ProcessRole. This merge avoids confusionFIG. 3: Extract of our specialization of SPEM metamodelbetween ProcessPerformer and ProcessRole by onlydefining role which is a set of capabilities.In addition, most of the relations of our proposalare taken again from the original metamodel, eitheras is or by specialization. Thus, associations betweenLifecycle, Phase, Iteration and Activitymetaclasses fitto the redefinition of reflexive relation of theWorkDe-finitionmetaclass of SPEM (fig. 2). We have constrai-ned the multiplicity of the source of “0..*” by “1”(thus giving the composition semantics).The relations which are not directly taken fromSPEM metamodel are inherited or deduced fromUML 1.4 (from the Core package, (omg, 2004, p.22)).For example, the reflexive relation onWorkProduct isa deduction of the relations that link Classifier meta-classes in UML. The “use” and “realize” relations bet-weenWorkDefinition andWorkProduct are also dedu-ced fromUML as shown on fig. 2. They allow to makeexplicit the relations described in the SPEM concep-tual model (fig. 1).3.2 Semantic details with OCLBecause syntactic added is not suffisant to semanti-cally define the metamodel, we have used OCL (as re-commended by the OMG) to add formal constraints.These constraints limit the possible instanciations andthus the valid process models. Here is an example ofsuch a constraint : “A role must be responsible for allthe products carried out by activities of which he is incharge, and reciprocally”.context ProcessRole inv :let productsActivities : Set{WorkProduct} =– Definition of the WorkProduct set made by– the activities of which ’self’ is responsibleself.work→ select(a :WorkDefinition |a.oclIsTypeOf (Activity)).oclAsType(Activity).output→ asSet()inself.workProduct = productsActivitiesAnother OCL constraint formalizes the merge ofProcessPerformer and ProcessRole (sec. 3.1) in pro-hibiting the instanciation of the ProcessPerformer :context ProcessPerformer inv :self.allInstances() → size() = 0The static checks that we made are not suffi-cient and there should be extra dynamic checks. Forexample, it is impossible to ensure before enactmentthat an activity will respect its time limit but it canbe checked during enactment. Furthermore, this kindof check is meaningful only during real project enact-ment and not during process model simulation. Let usnote that a process model can not generally be com-pletely defined before the project starts. If the greatstages of the development are generally known, thedetail of their realization depends on the difficultiesencountered at the time of their realization. It couldthen be necessary to reinforce a team, to considerother solutions or another approach.4 RELATED WORKSThe process modelling domain has been very ac-tive during the 90’s. There was a strong separationbetween Process Description Languages (PDL) andprocess enactment engines. PDL could be classifiedinto different categories : some of them were based onprogramming languages (ProcessWise/PML (Green-wood et al., 1992) or RHODES/PBOOL (Cre´gut andCoulette, 1997)), others on rules (MARVEL/MSL(Kaiser et al., 1988), ADELE/TEMPO (Warboys,1994) or EPOS/SPELL (Warboys, 1994)), others onpetri nets (SPADE/SLANG (Bandinelli et al., 1995)),and the others are hybrid solutions. Each of these lan-guages had its own specific tools.The actual tendancy is to unify PDL. Let us quotefor example SPEM metamodel suggested by theOMG and XML-based languages like XPDL (XMLProcess Description Language) (WfMC, 2005) pro-posed by the WfMC(Workflow 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 define LDP’s concepts (Breton, 2002) byproposing a syntax in the form of a metamodel forSPEM 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 defined even if there are specific engines forspecific targets (e.g. BPEL4WS & BPEL-J).5 CONCLUSIONIn this article, we have presented our work on the mo-delling of software processes. Because the SPEMme-tamodel lacks rigorous and formal definition, we haveproposed a restriction of SPEM that remains compa-tible with the standard and puts the focus on hiera-chical decomposition of workdefinitions (the structu-ral view) and the categorization of process compo-nents (roles, products and workdefinitions) accordingto disciplines (the descriptive view). Semantics thatare not graphicaly captured are expressed using OCLconstraints either at the metamodel level or at the pro-cess level. Our SPEM specialization has been used tomodel a UML based method called MACAO (Com-bemale et al., 2006).Unfortunately, OCL can only capture structuralconstraints. Our future work is to define an operatio-nal semantic for SPEM in order to enact a process mo-del described in SPEM. So we are investigating seve-ral approaches including the ones that describe ope-rational semantics for metamodel such as Kermeta,Xion and xOCL.REFERENCES(2002). Meta Object Facility (MOF) 1.4 Specification.OMG, Inc. Final Adopted Specification.(2003). Business Process Execution Language for Web Ser-vices v1.1.(2003). UML Object Constraint Language (OCL) 2.0 Spe-cification. OMG, Inc.(2004). Unified Modeling Language (UML) 1.4.2 Specifi-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., andPicco, 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 softwareprocess modelling. In MoDELS’05, volume 3713,pages 17–38. Springer-Verlag.Breton, E. (2002). Contribution a` la repre´sentation de pro-cessus par des techniques de me´ta-mode´lisation. PhDthesis, Nantes University.Breton, E. and Be´zivin, J. (2001). Process-centered mo-del engineering. In 5th IEEE International Enter-prise Distributed Object Computing Conference, Seat-tle, Washington, USA. IEEE Computer Society.Be´zivin, J. (2004). In search of a basic principle formodel driven engineering. CEPIS, UPGRADE, TheEuropean Journal for the Informatics Professional,V(2) :21–24.Combemale, B. (2005). Spe´cification et ve´rification demode`les de proce´de´s de de´veloppement. Master’s the-sis, Toulouse II University, Master SLCP.Combemale, B., Cre´gut, X., Caplain, A., and Coulette, B.(2006). Mode´lisation rigoureuse en SPEM de proce´de´de de´veloppement. In Lavoisier, H. S. ., editor, LMO2006, pages 135–150.Cre´gut, X. and Coulette, B. (1997). PBOOL : an object-oriented language for definition and reuse of enactableprocesses. 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 TechnicalJournal.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. andMukerji, J. (2003). Model Driven Architecture1.0.1 Guide. OMG, Inc.Warboys, B. C., editor (1994). Proc. of EWSPT’94, volume772 of LNCS. Springer–Verlag.WfMC (2005). Process Definition interface – XML ProcessDefinition Language v2.0.

Towards a rigorous use of SPEM

https://hal.archives-ouvertes.fr/hal-00369873

Towards a rigorous use of SPEM

Abstract

Similar works

Full text

Available Versions

Scientific Publications of the University of Toulouse II Le Mirail