A Domain Ontology for Software Process Architecture Description

Fadila Aoussat

, Mourad Oussalah

and Mohamed Ahmed-Nacer

LINA Laboratoy, University of Nantes, CNRS UMR 6241, 2, Rue de la Houssini

ere, BP 92208, 44322, Nantes, France

LSI Laboratory, Sciences and Technology Houari Boumediene University, BP 32, Bab Ezzouar, Algeria

Keywords:

Software Process Reusing, Software Architectures Principles, Domain Ontology, Software and Systems

Process Engineering Metamodel (SPEM), Heterogeneous Knowledge, Ontology Instantiation.

Abstract:

This paper presents a part of an approach for software processes reuse based on software architectures. This

solution is proposed after the study of existing work on software process reuse ﬁeld. Our study focuses on

approaches for reusing based on software architectures and domain ontology.

AoSP (Architecture oriented Software Process) approach exploits the progress of two research ﬁelds that

promote reusing for the Software process reusing: Ontology and software architectures.

This article details how the software process architectures are described and discusses the software process

ontology conceptualization and instantiation.

1 INTRODUCTION

The quality of the software product depends on the

quality of the software process models that is used for

the development and the maintenance of this software

product. Software Process (SP) models are complex

structures used to deﬁne the steps performed during

the software development. Many kinds of information

must be integrated to describe these steps (resources,

roles, input and output products...). Therefore, an im-

portant number of concepts, paradigms and languages

are developed to cover the different development as-

pects. However, there are always difﬁculties to model

SPs that deal with the software development preoccu-

pations such as understandability, ﬂexibility and dy-

namicity.

Reuse SPs, is one of the practices used to improve

SPs. The objective is to exploit best practices and

know-how capitalized from the precedent SP model-

ing and execution experiments. However, the diver-

sity and the wide range of SP models make SP model

reusing very difﬁcult. A number of studies are being

conducted nowadays in order to provide better sup-

port regarding SP reuse. Unfortunately, no reusing

method has emerged as reference in the SP reusing

domain.

In order to suggest a solution to cover engineer-

ing ”by” reusing SPs, we focus our researches on SP

reuse approaches based on software architectures. We

think that the reusability, ﬂexibility and abstraction of

software architecture are relevant characteristics that

can be used to provide a pertinent reusing approach to

model high quality SP models.

Moreover, In order to cover the engineering ”for”

reusing SPs, we focus our researches on SP reuse ap-

proaches based on domain ontology. Our aim is to

share common understanding among Stakeholder by

capitalizing the best practices of the SP domain. We

think that using a domain ontology can manage not

only the heterogeneity of the used concepts, but also

the heterogeneity of the used terminology.

This paper presents a part of an approach for

reusing SPs: AoSP (Architecture oriented Software

Process); this approach focuses on the existing ap-

proaches insufﬁciencies and suggests a pertinent so-

lution to reuse SP models. AoSP exploits software

architectures principles to model reusable SPs. It de-

scribes and deploys SP architectures. On the other

hand, to reuse existing SP models, AoSP exploits a

domain ontology to capitalize the pertinent know-how

extracted from heterogeneous SP models. Our objec-

tive is to:

• Suggest a Generic Solution: that can be applied

for different kinds of SP models.

• Increase the SP Quality: we aim to model

SPs that have the essential characteristics such

as comprehension, modeling and analyzing facil-

ities, agility and execution control.

• Increase the SP Reusing: by exploiting the

128

Aoussat F., Oussalah M. and Ahmed-Nacer M..

A Domain Ontology for Software Process Architecture Description.

DOI: 10.5220/0003973401280133

In Proceedings of the 7th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2012), pages 128-133

ISBN: 978-989-8565-13-6

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

precedent SP modeling and enactment experi-

ences.

• Increase the SP Re-usability: by modeling

reusable SP models and handling SP models com-

plexity.

Our article is organized as follows: section-2-

summarizes the insufﬁciencies of the studied reusing

approaches. Section-3- presents AoSP approach and

the steps to model reusable SPs. AoSP describes SP

architectures, thus, Section-4- provides the adopted

semantics to describe SP architectures. styles deﬁned

for SP architectures. Section-5- details how our do-

main SP ontology is designed and generated. To al-

low describing SP architectures, our ontology must

capitalize deferent kinds of knowledge, section-6- de-

tails how heterogeneous SP knowledge are capital-

ized. Section -7- concludes the article and announces

the future work.

2 INSUFFICIENCIES OF THE

APPROACHES FOR REUSING

SOFTWARE PROCESSES

2.1 Insufﬁciencies of the Reusing

Approaches based on Software

Architectures

In most reusing approaches based on components

(Coulette et al., 2000) (Dai et al., 2008) the central

concept is the ”Process Component”. A SP compo-

nent in an activity (Works Unit) or an activities se-

quence. SP Component is explicit in most approaches

and can be adapted to be reused except for (Dai et al.,

2008) where the SP component is considered as black

box components and cannot be modiﬁed. In general

the SP component interface is the Work Product re-

quired or given by the SP component (OMG-SPEM,

2008).

The conﬁguration is used in the approaches based

on software architectures (Alloui and Oquendo, 2001)

(Choi and Scacchi, 2001), however formal rules that

describe the assembling of the SP component are not

deﬁned explicitly.

For the connector concept there is no consensus

on its interpretation (Aoussat et al., 2011), the idea

that emerges is that the connector is a dependency be-

tween activities, it can be a precedence link or a del-

egation link, which often depends on the used PML

(Process Modeling Language). Each approach de-

ﬁnes its own SP connector vision. We resume the

insufﬁciencies of these approaches as follows:

• Limited Reuse: The reusable elements such as SP

Component, SP connector are deﬁned to the inter-

nal use.

• Under exploitation of architectural elements:

Conﬁguration and assembling constraints are

not exploited; architectural styles and explicit

reusable connectors are not proposed.

• No General Solution: Every approach deals with

a particular problem and uses a particular PML.

• No SP Architecture Deployment: No process de-

ployment is proposed.

2.2 Insufﬁciencies of the Reusing

Approaches based on Domain

Ontlogy

Table 1: Approaches for reusing SPs based on domain on-

tology.

Appoach objective Ontology

OnSSPKR

Framework (He

et al., 2007)

Deal with

CMM, CMMI,

ISO/IEC15504,

ISO9001 models.

Three different

ontologies

SPO (Software

Process Ontolo-

gie)(Liao et al.,

2005)

Mapping between

CMMI model and

the ISO/IEC 15504

model

SP basic con-

cepts

PCE based ontol-

ogy (Tomohiko

et al., 1996)

Generate SP plans Two ontologies

(artifacts and ac-

tivities )

Approach based

descriptive logic

(Rilling et al.,

2007)

Framework for soft-

ware maintenance

Concepts

that affect

the software

maintenance

Flexible PML

based ontology

(Shen and Chen,

2006)

Flexible SP model Process ele-

ments

To suggest a domain ontology one of the ﬁrst steps

is to study the existing ones and consider there exten-

sion, fusion, adaptation or reuse.

Many SP modeling approach based on domain

ontology are deﬁned (He et al., 2007)(Liao et al.,

2005)these approaches use one or many ontologies to

represent the SP model. However these solutions are

speciﬁc and deal with particular SP models and do not

suggest a general solution that can applied for a large

range of SPs.

Table 1- resumes the objectives and the ontologies

structures of the studied approaches.

ADomainOntologyforSoftwareProcessArchitectureDescription

129

3 AoSP APPROACH

DESCRIPTION

AoSP (Architecture oriented Software Process) ap-

proach is an approach that gives a solution to increase

the SPs reuse. AoSP covers the engineering for and

by reusing:

• For Reusing: By capitalizing the SP best prac-

tices and know-how extracted from existing SP

models.

• By Reusing: By describing and deploying the ex-

tracted software processes knowledge as software

architectures.

According to software architectures speciﬁcities,

AoSP suggests a particular SP modeling approach:

SP modeling is decomposed of two steps:

• Pre Modeling: Model the different SP preoccu-

pations separately (structure, interaction and treat-

ment). This step increases SP model comprehen-

sion and has a direct impact on SP modeling, an-

alyzing and execution control facility.

• Final Modeling: Deploy the SP architecture that

can be done with different PMLs speciﬁc to differ-

ent SP kinds. The deployment must be in an auto-

matic way by developing deployment programs.

This possibility gives to our approach a generic

aspect and increases the modeling facility.

4 SOFTWARE PROCESS

ARCHITECTURE

DESCRIPTION

Based on existing SP reusing approaches insufﬁcien-

cies, combining with ADL (Architecture Description

Language) approaches, AoSP approach suggests a

complete semantic to describe and deploy SP archi-

tectures.

Our objective is to describe the SP model as soft-

ware architecture and exploit the advantages offered

by the software architecture domain. The interac-

tions have a central place in the SP model (Alloui and

Oquendo, 2001), moreover, the SP is human centered;

thus, it is important to manage the different kinds of

the SP interactions. Our analysis is oriented to give

a solution to handle the different kinds of SP interac-

tions. Deﬁning generic explicit reusable SP connec-

tors that can adapt and facilitate the SP interactions is

the adopted solution.

We deﬁne our SP connector as an activity (Work

Unit) that ”facilitate and control” data and control

Table 2: Adopted semantics for Architecture oriented Soft-

ware Process (AoSP) approach.

Software Process Concepts. SP architectural

concepts.

Activity that creates new products. SP Component

Input or output ﬂow of a creation

Activity .

SP Port (given or

required)

Activity that adapts or controles

the ﬂow.

SP Connector

Input or output ﬂow of an adapta-

tion Activity .

SP Connector Role

Precedence link between a creation

Activity and an adaptation Activity.

Attachement

Delegation link between two activi-

ties (adaptation or creation).

Binding

Process structure. SP Conﬁguration

Recurrent structure or recurrent ex-

ecution policy.

SP style

transmissions between SP activities. SP Connec-

tors do not create new products, but adapt, evalu-

ate and control existing products. The distinction

between ”creation” activities ( SP components) and

”adaptation and control” Activities (SP connectors) is

the basis of the SP architectural concepts interpreta-

tion. Table–2 resumes the architectural intrperation

for SPs.

5 SOFTWARE PROCESS

DOMAIN ONTOLOGY

To capitalize the SP knowledge we use a domain on-

tology, in addition, our aim is to offer a tool to will

allow the reasoning and the emergence of new solu-

tions. Thus our ontology must:

• Be coherent, not ambiguous and commonly ac-

cepted.

• Offer a conceptualization to store and retrieve SP

architectures knowledge.

• Manage the heterogeneity of the conceptual of the

different SPs: offer a conceptualization that can

be exploited for different SP models, without fo-

cusing on a particular SP kind.

• Manage the heterogeneity at the instance level:

Capitalize knowledge from various SP models can

create ambiguities, indeed, even if there is consen-

sus on the used terminology for SP modeling, the

developers can use their own vocabulary.

• Restore a comprehensible knowledge: A vocab-

ulary reference that represents the vocabulary of

the ﬁnal user must be deﬁned and stored.

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

130

5.1 Software Process Ontology

Conceptualization

Heterogeneity on the concept level is handled by ex-

ploiting the SPEM conceptualization. SPEM (System

and Software Process Engineering Metamodel) is a

UML proﬁle adopted by the OMG to describe large

range system and software processes (OMG-SPEM,

2008). We adopt SPEM as basic conceptualization as

it is a standard metamodel accepted by the commu-

nity, it regroups all the important concepts used on the

SP engineering independently from the kind or a con-

cerned domain. The majority of the SP models are

conform to the SPEM, or at least, their metamodels

can be mapped with SPEM.

SPEM introduces the reusing based process com-

ponents through the Method Plugin proﬁle; however,

to describe SP architectures, SPEM lacks important

architectural concepts. In fact, the lack of ”SP Con-

ﬁguration”, ”SP Style” and ”explicit Connector” con-

cepts disallow describing and deploying SP architec-

tures (Aoussat et al., 2011). Having a complete se-

mantic to describe a SP architecture, we had extended

Method Plugin proﬁle, for this purpose, we had intro-

duced new stereotypes to describe the architectural el-

ements of the SP architectures (Aoussat et al., 2011).

SPEM proﬁle extension is not the subject of the ar-

ticle, we resumes only the architectural elements that

describe SP architectures integrated on SPEM. Thus,

two kinds of classes are added:

• Classes that Describe the SP Architecture: A

SP Conﬁguration is composed from SP Compo-

nents and SP Connectors. the assembling is done

via attachments.

• Classes that Describe the SP Style: The SP style

is composed of Activity Deﬁnitions. As SP com-

ponent and SP connector are activities, an Activity

Deﬁnition describes the type of the SP connector

and the SP component. In the same manner, Work

Product Deﬁnition describes the types of SP ports

and the types of SP connector roles.

5.2 SPEMOntology Structure

SPEMOntology is the result of successive ATL trans-

formations applyed on SPEM. It is constitute from 56

concepts and an important number of data and object

properties. In order to facilitate its understanding, it is

important to describe its organization. SPEM is struc-

tured into seven packages (OMG-SPEM, 2008). By

analyzing the SPEM packages (after the extension),

we notice that every SPEM package has its abstract

class that regroups the common behavior of the pack-

ages classes.

Figure 1: Main abstract SPEMOntology concepts.

After the ATL transformations we can identify this

organization (ﬁgure -1-). The SPEM packages view

can be identiﬁed through the main abstract concepts

of SPEMOntology. The concepts of our ontology

have kept the same name as the SPEM classes; how-

ever, we have added the preﬁx ”pro” to identify the

stereotyped elements. This preﬁx is added during the

execution of ”applySPEMproﬁle2SPEMmodel” mod-

ule.

6 SPEMOntology INSTANTIATION

The concepts heterogeneity ﬁnds solution by exploit-

ing a standard metamodel. The heterogeneity at

instance level deals with separating every kind of

knowledge. Indeed, our ontology must store four

kinds of knowledge:

• The SP Architecture Knowledge: The knowl-

edge concerns SP conﬁguration and SP styles.

• The used Knowledge: The knowledge concerns

the know-how of existing SP models:

• The Reference Vocabulary: The knowledge

concerns the vocabulary used by the ﬁnal stake-

holders.

• The Instance Heterogeneity Management: our

ontology must manage the heterogeneous vocab-

ulary.

Our ontology respects SPEM metamodel concept-

ADomainOntologyforSoftwareProcessArchitectureDescription

131

ualization and has the same packages structure. We

exploit this structure to deal with the instance hetero-

geneity. Every SPEM package is used to store a kind

of knowledge. We detail the adopted solution in the

next paragraphs.

6.1 The SP Architectures Knowledge

Capitalization

The SP expert stores the SP conﬁgurations and the SP

styles of the company. This step is very important as it

allows describing formally the company development

strategies and practices.

The instantiation is done on the Process Architec-

tural Element concepts that describe the SP conﬁgu-

ration behavior and the SP style knowledge is capital-

ized by using the Method Content architectural con-

cepts (ﬁgure-2-).This step is done manually by a SP

expert of the company. However, the advantage is that

it is done once and it will be reused independently

from the SP expert intervention.

Figure 2: SP architectural concepts of SPEMOntology.

6.2 The used Knowledge Capitalization

We instantiate the concepts of ”Process with Method”

and ”Process Structure” packages. We use these con-

cepts to capitalize the used knowhow that are col-

lected from the existing SP models. This step is done

automatically; we apply a reverse engineering on ev-

ery SP model that will be reused. For each PML we

develop an instantiation program that identiﬁes the

pertinent concepts and allows the extraction of the

pertinent knowledge.

6.3 The Reference Vocabulary

Capitalization

In SPEM the ”Method Content” package is dedicated

to describe development methods independently from

their use (OMG-SPEM, 2008). We use these con-

cepts, to describe the vocabulary reference.

The Method content concepts are solicited to de-

scribe many kinds of knowledge: Method Content

Elements, Vocabulary Reference and Architectural

Types. To distinguish between these kinds of knowl-

edge, for each Method Content concept we add a data

type property ”concept role” that can have the next

values: ”MC” for method content knowledge, ”VR”

for vocabulary reference and ”AT” for architectural

type.

The weakness of this step is that the instantiation

is done manually.

However, the advantage of this manual step is that

allow to deﬁne ”formally” the glossary of the com-

pany. It allows not only a better comprehension of

the SP models, but also, constitutes a contribution to

capitalize company know-how, that will be used and

reused formally independently from the SP experts

and its tacit knowledge.

6.4 The Correspondence between the

Vocabulary Reference and the used

Knowledge

This correspondence is done by using existing asso-

ciations between Method Content Concepts and Pro-

cess With Method concepts, these associations are

used to deﬁne the correspondence between the Used

Knowledge and the Reference Vocabulary.

7 CONCLUSIONS

This paper presents a partial view of AoSP (Architec-

ture oriented software Process) approach to reuse SP

models. The objective of AoSP is to suggest a stan-

dard solution to increase the reuse and the reusability

of the SP models.

AoSP offers an innovative vision of the SP mod-

eling by separating the SP modeling preoccupations:

Work Product treatments (Components), Work Prod-

uct transmissions (Data Flow connectors) and execu-

tion control (Control Flow connectors). This new vi-

sion is possible by exploiting software architectures

characteristics; it allows modeling more comprehen-

sible, ﬂexible and controllable SP models. On the

other hand, AoSP exploits the precedent good model-

ing and enactment experiments to model high quality

SP models. AoSP uses a domain ontology to capi-

talize the best practices of the software development

domain. It exploits the capitalized knowledge to re-

trieve and deploy SP architectures.

The ontology conceptualization is discussed, it is

based on SPEM; however, SPEM architectural con-

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

132

cepts disallow describing SP architectures,thus, we

had extended SPEM metamodel by introducing the

required architectural concepts. The ontology was

generated by transformation model techniques; to

achieve this aim, we use ATL (Atlantique Transfor-

mation Language).

SPEMOntology must store different kinds of

knowledge: The used know-how, the SP architec-

ture knowledge and a reference vocabulary, in addi-

tion, it must do a correspondence between these kinds

of knowledge. To this aim, we exploit the SPEM

structure (organized into packages) to store separately

these kinds of knowledge. We add adequate proper-

ties to have to keep the knowledge coherence.

Actually we are working on deﬁning inference

rules to infer tow kinds of knowledge: ”equivalent SP

conﬁguration” to identify the SP conﬁgurations that

can replace the required conﬁguration and ”equiva-

lent SP components” to identify the components that

can replace the required SP component. We are also

working on retrieving SP architectures, the hole algo-

rithm is deﬁned, good results are obtained but must

reﬁned before their publishing.

REFERENCES

Alloui, I. and Oquendo, F. (2001). Supporting decentralised

software-intensive processes using zeta component-

based architecture description language. In ICEIS,

pages 207–215.

Aoussat, F., Oussalah, M., and Nacer, M. A. (2011). Spem

extension with software process architectural con-

cepts. Computer Software and Applications Confer-

ence, 0:215–223.

Choi, S. J. and Scacchi, W. (2001). Modeling and simulat-

ing software acquisition process architectures. Jour-

nal of Systems and Software, 59(3):343–354.

Coulette, B., Thu, T. D., Crgut, X., and Thuy, D. T. B.

(2000). Rhodes, a process component centered soft-

ware engineering environment. In ICEIS, pages 253–

260.

Dai, F., Li, T., Zhao, N., Yu, Y., and Huang, B. (2008).

Evolution process component composition based on

process architecture. In International Symposium on

Intelligent Information Technology Application Work-

shops, pages 1097–1100.

He, J., Yan, H., Liu, C., and Jin, M. (2007). A

framework of ontology-supported knowledge repre-

sentation in software process. http://www.atlantis-

press.com/php/download paper.php?id=1180.

Liao, L., Qu, Y., and Leung, H. K. N. (2005). A soft-

ware process ontology and its application. In Work-

shop on Semantic Web Enabled Software Engineer-

ing(SWESE).

OMG-SPEM (2008). SPEM:Software & Sys-

tems Process Engineering Metamodel, v2.0.

http://www.omg.org/cgi-bin/doc?Formal/2008-04-01.

Rilling, J., Zhang, Y., Meng, W. J., Witte, R., Haarslev,

V., and Charland, P. (2007). A Uniﬁed Ontology-

Based Process Model for Software Maintenance and

Comprehension. In Models in Software Engineering:

Workshops at MoDELS, volume 4364, pages 56–65.

Shen, B. and Chen, C. (2006). The design of a ﬂexible soft-

ware process language. In SPW/ProSim, pages 186–

194.

Tomohiko, K. M., Mori, K., and Shiozawa, T. (1996).

Process-centered software engineering environment

using process and object ontologies. In the Second

Joint Conference on KnowledgeBased Software Engi-

neering, pages 226–229.

ADomainOntologyforSoftwareProcessArchitectureDescription

133