HAL Id: hal-00804253
https://hal.archives-ouvertes.fr/hal-00804253
Submitted on 25 May 2021
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
The application of interoperability requirement
specification and verification to collaborative processes
in industry
Sihem Mallek, Nicolas Daclin, Vincent Chapurlat
To cite this version:
Sihem Mallek, Nicolas Daclin, Vincent Chapurlat. The application of interoperability requirement
specification and verification to collaborative processes in industry. Computers in Industry, Elsevier,
2012, to be appear. �hal-00804253�
The
application
of
interoperability
requirement
specification
and
verification
to
collaborative
processes
in
industry
S.
Mallek,
N.
Daclin
*
,
V.
Chapurlat
LGI2P–LaboratoiredeGe´nieInformatiqueetd’Inge´nieriedeProduction,Sitedel’EcoledesMinesd’Ale`s,ParcScientifiqueG.Besse,30035Nıˆmescedex1,France
1. Introduction
In recent decades, enterprises have developed and applied
variousprinciplesandorganizationalsystemstoimprove
collabo-rationwithexternalpartners(i.e.,inter-enterprisecollaboration),
and collaboration between internal teams (i.e., intra-enterprise
collaboration).Theseapproacheshaveallowedthemtomeetthe
challengescreatedbytheglobalizationofmarkets,andespecially
tobeabletofocusontheirowndomainofexpertisewithnolossof
performance,andtoshareexperiences,processes,andtoolswith
internal or external partners confidently. In this context, it is
importanttodescribeandformalizehowdifferentpartners(e.g.,
anisolatedplayer,team,department,orenterprise)canworkwith
othersandthroughtheirinteractionsachieveacommonobjective.
Thisformalizationisperformedusingtheprinciplesof
collabora-tiveprocesses,whichcanbepublic(‘‘processactivitiesbelongto
differentorganizations’’[2])orprivate(‘‘setofactivitiesorderedin
a set of procedural rules to achieve a specific goal within an
organizationandcarriedoutbyagroupofpersons’’[3])[1].The
ability of partners to interact is one of the key factors to
characterizeand assess,in ordertomeasure theoverall
perfor-mance of a collaborative process. This factor is related to the
conceptofinteroperabilitywhichcanbedefinedasthe‘‘abilityof
enterprisesandentitieswithinthoseenterprisestocommunicate
and interact effectively’’ [4]. Therefore, enterprises involved in
collaborativeprocesseshavetoimprovetheirinteroperability.In
order to accomplish this goal, they must be able to detect,
anticipate,andsolvetheirinteroperabilityproblems.Ourresearch
addressestheissueofdetectionfromananticipativepointofview
– i.e.,before theimplementation ofthe collaborativeprocess –
attempting to detect problems of interoperability that can be
inducedbythecharacteristicsandbehaviorsofpartners.Inthis
perspective, in order to anticipate problems, analysis of the
collaborativeprocessmodelmustfirstbeperformed.Second,the
anticipationofproblemsisperformedaccordingtothesatisfaction
ofinteroperabilityneedsbythecollaborativeprocessmodel.Inthis
way, to demonstrate that a need is satisfied, it must first be
formalizedintoarequirementandvariousverificationtechniques
mustbeappliedtothecollaborativeprocessmodel.Basedonthese
considerations, ourresearchaims,first,todefine,structure, and
formalizeinteroperabilityrequirementsthatpartnersmustsatisfy.
Second,it aims toenhanceand implementa setof verification
Keywords:
Interoperabilityrequirements Verification
Collaborativeprocess ABSTRACT
Interoperabilityisbecomingacrucialissueforindustry,andalackofinteroperabilitycanbeseenasan importantbarriertocollaborativework,inbothpublic(inter-enterprise)andprivate(intra-enterprise) collaborativeprocesses.Indeed,interoperabilityis generallydefinedastheabilityofenterprisesto interactwithinacollaborativeprocess.Priortoanyeffectivecollaboration,itisnecessarytoinform enterprises,whichaimtoworktogether,whetherornottheywouldbeabletointeroperate.Researchon interoperabilityhasshownthebenefitsofmeasuringandevaluatinginteroperability,byusingseveral frameworksandmaturitymodels.However,approachesfordetectingandanticipatinginteroperability problemsdonotseemtoexist.Ourresearchproposestouseformalverificationtechniquestodetect differenttypesofinteroperabilityproblems.Ontheonehand,thismeansbeingabletodefine the particularinteroperabilityneedstobeconsidered.Ontheotherhand,itrequires theseneedstobe formalizedas a set of unambiguousand, as formallystated as possible,requirements. Moreover, interoperabilityrequirementscan have temporalor a-temporalfeatures. Todetectinteroperability problemsinanticipativeway, interoperabilityrequirementsmust becheckedbymeansofatarget process model. Three complementary verification techniques are used to verify interoperability requirementsinacollaborativeprocessmodel.Theverificationtechniqueuseddependsontheaspect andthelevelofabstractionoftherequirementtobeverified.Thispaperfocusesandillustratesthe detectionofinteroperabilityproblemsusingverificationtechniques.
* Correspondingauthor.Tel.:+33466387066.
techniquesthatcanbeusedpriortoimplementinganystepsinthe
collaborativeprocess.
This paper focuses on the specification and verification of
interoperabilityrequirementswithincollaborativeprocesses,and
isorganizedasfollow.Section2reviewsseveralresearchprojects
focusingontheinteroperabilityanalysis.Section3presentsthe
differentstepsoftheproposedapproachtodetectinteroperability
problems. Section 4 explains how interoperability needs are
obtained.Section5proposesthedefinitionsandaclassificationof
interoperabilityrequirements.Section6presentstheanalysisof
interoperabilityrequirements using complementaryverification
techniques.The seventh sectiongives a case study in order to
illustratetheverificationofinteroperabilityrequirements.
2. Interoperabilityanalysis:existingresearchanddiscussion
The development of interoperability has become a crucial
questionforenterprisesthatwanttobecomemorecompetitivein
a globalized environment. As a consequence, a large body of
researchhasbeendevelopedinrecentyearsinordertoanalyze
interoperability (i.e., analysis that formalizes, evaluates, and
measures system interoperability). Concerning formalization,
interoperabilityframeworks(e.g.,IDEAS, INTEROP, AIF...)[5–7]
structure interoperability requirements according to different
aspectssuchasinteroperabilityproblemsthatcanoccurorlevelat
which interoperability takes place. For instance, the INTEROP
frameworkconsiderstwofundamentalaspects:the
‘‘interopera-bilitybarriers’’(conceptual,organizationalandtechnological)and
‘‘interoperability concerns’’ (data, services, processes and
busi-ness).Thegoalistoachieveefficientcollaborationbyovercoming
interoperability barriers relating to interoperability concerns.
Although these frameworks can be used to create a better
classificationandstructuringofthebasicaspectsof
interoperabili-ty,theycannotbeusedtoevaluateinteroperability.Theevaluation
ofinteroperabilityismostlyperformedwithmaturitymodels(LISI,
LCIM,OIM...)[8–10],whichcanbeusedtocharacterizetheability
of systems tointeroperate at a given moment withregards to
differentidentifiedinteroperabilitylevels.Someofthesemodels
giverecommendationstogofromoneinteroperabilityleveltoa
higher interoperability level. However, these maturity models
focusonthequalitativeevaluationofinteroperability,anddonot
offeraquantitativemeasurementofinteroperability.A
methodol-ogyhasbeenproposedtomeasureinteroperabilityofenterprises
inbothintra-andinter-enterprisecontexts[11].Thismethodology
measurescompatibilityandinteroperationperformance(i.e.,the
dynamicaspectofthecollaboration)simultaneously.Tomeasure
compatibility,acompatibilitymatrixisusedtoinformenterprises
astowhetherornot)ofinteroperabilityproblemsareexpectedto
occur.Tomeasureinteroperationperformance,somecriteriasuch
ascost ofinteroperation,time of interoperation,andquality of
interoperationaremeasured.Similarly,theresearchproposedby
[12]isbasedonthedevelopmentofseveralmodesof
interopera-bility aiming to offer operational effectiveness. However, this
researchdoesnotformalizeinteroperabilitysoastomeasureit,
andcannot beusedtodetectandidentifylocalinteroperability
problemsinaformalway.Fig.1providesacomparativeoverview
of the research presented above.1 It shows the six main
characteristics that have inspired our research work, which
include (1) the expression of interoperability needs, (2) the
measurementofinteroperability,(3)theformalizationof
interop-erability, (4) the use of verification techniques, (5) the local
detection of interoperability requirements, and finally (6), the
operationalaspectsofthecollaborativeprocess.
Thesedifferentresearchstudieshaveevaluatedorprovidedan
indicationastowhetherornotthereareinteroperabilityproblems,
but they do not specifically describe these problemsor givea
formalproofoftheirexistence.Inaddition,manygapsexist,such
as (1) a lack of interoperability needs and requirements
formalization, (2) a lack of collaborative processanalysis tools,
(3) a lack of detection principlesfor problems in collaborative
processmodels,whichwouldenablethemtobeanticipated,and
finally(4)alackofconsiderationoftheoperationalaspectsofthe
collaborativeprocess.Thesegapsareultimatelyrelatedtothelevel
offormalization,theproblemstobedetected,and theconcepts
needed to detect these problems. They are also related to
techniquesthatcanprovidetheirrefutableproofoftheexistence
of interoperabilityproblems formally(not only qualitatively or
quantitatively).
3. Detectionofinteroperabilityproblems:ourapproach
Todetectinteroperabilityproblemsincollaborativeprocesses
inananticipativeway,weproposeamodel-basedapproachfor
interoperabilityrequirementschecking.Ourapproachisinspired
by requirements engineering that can beused to describeand
structure interoperability requirements that are related to any
interoperabilityproblemthatmayhinderacollaborativeprocess.
Finally, this approachis based, on theonehand,on the useof
formalization, and on the other hand, on the use of various
verification techniquestoensure thatthe collaborative process
modelcomplies withtheseinteroperabilityrequirements.Thus,
thelocaldetectionofinteroperabilityproblemsisperformed by
theuseof modeling,formalization, and verificationtechniques.
ThisapproachisimplementedfollowingthestepsshowninFig.2.
First,interoperabilityneedsarecollectedandexpressedusinga
languageclosetotheoneusedbythestakeholdersinvolvedinthe
implementation,execution,andcontrolofagivenintra-or
inter-enterprise collaborativeprocess.The objectiveofthis stepis to
developarepositoryofinteroperabilityneedsthatisas
compre-hensiveandgenericaspossible.
Theseneedsarethenclarified,structured,andformulatedas
theso-calledinteroperabilityrequirementsdescribedbelow,then
gathered into a repository of interoperability requirements.
Fig.1.Comparativestudyofthedifferentresearchwork.
1
+++:bestaddresstheissue,++:partlyaddresstheissue,+:relevanttotheissue, :irrelevanttotheissue.
Formulatingandstructuringtherequirementsallowtheuserin
chargeofthecollaborativeprocessmodelanalysistoselectthe
appropriateinteroperabilityrequirementstobechecked,
accord-ingtoanalysisobjectives.Thismayinclude,forexample,interest
inprocessperformanceorinthecompatibilityofthetoolsusedin
thecollaborative process. Once these interoperability
require-mentshavebeen selected,theyare formalized intoproperties
throughtheuseofaformallanguagesothattheycanbechecked
onthemodelwithexistingformalverificationtechniques.From
this perspective, the collaborative process model must first
considertheinteroperabilityrequirements.Thus,the
collabora-tive process is modeled with an enriched version of BPMN
(BusinessProcessModelingNotation)[14]inordertointegrate
the concepts related to interoperability so as to make the
verificationofinteroperabilityrequirementspossible.Then,the
modelmustbetranslatedintoaformalstructuresupportingthe
proposedverificationtechnique,whichrequiresmodel
transfor-mation mechanisms. Finally, the result of the verification
indicateswhetherornotarequirementisreallysatisfiedbythe
collaborativeprocessmodel,whichinturnpointstotheexistence
ofaninteroperabilityproblem.Thus,ifallselectedrequirements
are satisfied by the collaborative process model, it can be
implemented.Ifnot,(1)thecollaborativeprocessmodelcanbe
challenged to provide adequate solutions to the problems
detected,and(2)theusercanselectotherrequirementsbefore
performingotherverifications.Thesestepsareexplainedindetail
inthefollowingsections.
4. Establishinginteroperabilityneeds
Thefirststepaimstocreatealistofinteroperabilityneeds.The
reviewofthestateoftheartpresentedinSection2,whichcovers
thedifferentworkrelated tointeroperability,identified several
interoperability needs. For example, the levels proposed in
maturity models,toachieve full interoperability,express many
interoperability needs. These maturity models cover the three
mainaspectsof interoperability(conceptual, organizationaland
technological),andexpressneedsrelatedtotheseaspectssuchas:
Need 1: ‘‘a communication protocol exists for exchanging data
betweenparticipatingsystems’’(LCIM–level1)[9].
Need 2: ‘‘recognized frameworks are in place to support
interoperabilityandsharedgoalsarerecognizedandrolesand
responsibilitiesareallocatedaspartofon-goingresponsibilities,
however,theorganizationsarestilldistinct’’(OIM–level2)[10].
Need3:‘‘Theconnectionsystemsareidentifiedbytheirabilityto
provideanunderstandingofthedataexchanged.Theemailsinclude
attachmentsandcontributetothesuccessoftrade’’(LISI–level2)
[8].
Need4:‘‘Thegovernanceoftheprocurementprocessexplicitlylinks
thebusinessrequirementstotechnicalarchitecturethroughproject
financing’’(IMM–level4)[15].
Toconsolidatethislistofneedsandtoenrichit,anindustrial
survey wasconducted. The purpose ofthis surveywas togive
partnerstheopportunitytodescribeproblemstheyfaceintermsof
interoperabilityandtoexpressthem.Thisquestionnairefocuses
on several aspects. The first aspect highlights the need for
collaboration withinand between partners, which canbe used
to differentiate between the needs in a private collaborative
process and a public collaborative process. The second aspect
focusesoninteroperabilityproblems(conceptual,organizational
andtechnological).Finally,theperformanceaspectsareconsidered
usingstandardcriteria:cost,time,andquality.Therequirements
listed below are extracted from the answers provided by the
industrialsurvey:
Need 5: ‘‘We need to send and receive exploitable data, and
be sure that they are received by the other partnerduring the
activity.’’
Need6:‘‘Homogenizecommunicationwhatevertheform,thenhave
asemanticunderstoodandsharedbybothpartners.’’
Need7:‘‘Keeptheperformanceasgoodaspossibleintermsofcost,
quality(productandservice)andtimespent,afterthepartnershipis
over,asbeforeitwasstarted.’’
Need8:‘‘Aresourcemustbeavailablewhenitisneeded.’’
Theneedscollectedinthebibliographicanalysisandtheneeds
collectedin thesurveyarebothexpressedinnaturallanguage.
They remain difficult to handle due to their nature and the
complexityoftheirexpression.Therefore,repetition,ambiguity,
imprecisionandincoherencemustberemoved.Toaddressthese
problems mainly related to the expressiveness of natural
language,theseneedsareformulatedandstructuredintheform
of requirements as proposed by requirements engineering
[16,17].
5. Interoperabilityrequirements:classificationandstructuring
A requirement is defined as: ‘‘a statement that specifies a
function,abilityoracharacteristicthataproductorasystemmust
satisfyinagivencontext’’[18].Interoperabilityrequirementsare
formulated thanks to the repository of interoperability needs
described intheprevious section.Theserequirementsmustbe
clearly expressed, identifiable,traceable,verifiable,
unambigu-ous, and not contradict another requirement from the same
repository.Allrequirementsobtainedareplacedinarepositoryof
interoperability requirements. This repository is used as a
reference repository to classify and structure interoperability
requirements.
5.1. Classificationofinteroperabilityrequirements
In general, interoperability is related to the concept of
compatibility.Compatibility meanstoharmonize enterprises in
termsof method,organization, andtools,sothat the
heteroge-neousinformationexchangedcanbeunderstoodandexploitedby
each of them with no extra interfacing efforts. However,
compatibilityisnotsufficienttodescribeinteroperability.Infact,
duringacollaborativeprocess,variousothersourcesofproblemscan
bedistinguished.Forinstance,twoenterprisesusethesamelanguage
tocodetheirdata,butoneofthemisunabletosenditsdata.Inthis
case,‘‘twointeroperablesystemsarecompatible,buttwocompatible
systemsarenotnecessarilyinteroperable’’[19].Thisstatementleadsto
thenotionthatinteroperabilityisrelatedtointeroperationduring
collaboration.Interoperationfocusesonrealinteractionsbetween
enterprises during collaboration (i.e., it concerns the ability of
enterprisestoworkefficientlytogetherthroughouttheinteractive
process and take into account various events that may occur).
Furthermore, interoperability is related to the preservation of
autonomy during collaboration, which means that partners can
worktogether(e.g.,exchangeservices)whilecontinuingtofollow
theirownlogicofoperation[6].Moreover,whencollaborationstops,
enterpriseswishtoreturntotheirpreviousperformancelevelwhile
remainingefficient. Forinstance, onepartnermaynote a lossof
performancewithregardstoitsperformancebeforethe
collabora-tion.Inthiscase,itisquestionofbeingsurethatagivenpartnerwill
beabletorecoverhisorherownperformancelevelaftertheendof
thecollaboration.Thus,interoperabilityisrelatedtoanotherconcept
calledreversibility[6].Reversibilitymeansthatpartnerscanreturnto
theiroriginalstateattheendofcollaborationwithregardstotheir
performance and including positive and/or negative variation
acceptedpriortoanyrealcollaboration.
In consideration of the aforementioned, an interoperability
requirementis definedas: ‘‘astatementthat specifiesafunction,
abilityorcharacteristic,relatedtotheabilityofapartnertoensureits
partnershipintermsofcompatibility,interoperation,autonomy,and
reversibility, that it must satisfy’’. Thus, four categories of
interoperability requirements are defined: compatibility,
inter-operation,autonomy,andreversibility.
A compatibility requirement is defined as ‘‘a statement that
specifies a function, ability, or characteristic, considered to be
invariablethroughoutthecollaborationandrelatedto
interoperabili-tybarriers(conceptual,organizational,andtechnological)foreach
interoperabilityconcern(data,services,processes,andbusiness),and
whichpartnersmustsatisfybeforecollaborationiseffective’’.
Compatibilityrequirementsfocusontheinterfacebetweenthe
partnersinvolved.Alloftheserequirementsmustbecheckedand
areinvariablethroughouttheduration ofthecollaboration.For
instance,threecompatibilityrequirementscanbeformulatedfrom
thefifthneedpresentedinSection4.
CDTTranslation2:‘‘Thereceivingpartnerhasthenecessarymeansto
translatethedataexchanged’’.ThisCRisrelatedtotechnological
aspects of interoperability at thelevel of data. Itreflects the
needs of thereceiving partnerin terms of the translation of
homogeneous or heterogeneous data, and subsequently their
exploitation.
CDOAuthorization:‘‘Thesendingpartnerhastherequiredpermissions
to carry out exchanges with the receiving partner’’. This CR is
relatedtoorganizationalissuesandreflectstheneedsofpartners
toexchangetheirdatasafely.
CSOManager: ‘‘Each service has a clearly defined manager with
authorityovertherestoftheteam’’.ThisCRisexpressedatthe
levelofservicesandisrelatedtotheorganizationalaspect.The
objectiveoftheimplementationofthisrequirementistoavoid,
forexample,lossoftimewhichmaybeharmfultotheprocess
duringitsexecution.
Aninteroperationrequirementis definedas‘‘astatementthat
specifies a function, ability or characteristic, considered to be
variableduringthecollaboration,relatedtotheperformanceofthe
interaction,andwhicheachpartnermustsatisfy’’.
Interoperationrequirementsarerelatedtotheexecutionphase
of the collaborative process. In addition, their veracity can be
consideredtobevariableduringthecollaborationwithregardsto
the interactions themselves. For example, some interoperation
requirementscanbeexpressedfromthefirstandeighthneed.
ISOReceipt:‘‘Thereceiversendsareceipttothesender’’.Formulated
fromneed number 1, this IR is related to theorganizational
aspectatthelevelofservices.
ISOAvailabilityTime:‘‘Resourceisavailablewhenanactivityneedsit’’.
Formulated from need number 8, this IR focuses on the
availabilityof theresource at themomentit is requested by
andforanactivity.
ISOExecutionTime: ‘‘Resource is active throughout the duration of
executionoftheactivity’’.ThisIRisformulatedtoensurethata
resourcecanreallybeexploitedwhileagivenactivityisbeing
executed.Thegoalis toensurethatthis resourcewillnot be
allocatedtoanotheractivityforthedurationofthefirstactivity
thatusesit.
An autonomy requirement is defined as ‘‘a statement that
specifiesafunction,abilityorcharacteristicrelatedtotheabilityof
partnerstoperformtheirowngovernanceandmaintaintheirown
operationalcapacityduringcollaboration,andwhicheachpartner
mustsatisfy’’.
Autonomyrequirementsarerelatedtotheabilityofpartnersto
maintaintheirindependencewhiletheyareinvolvedina
collabora-tiveprocess.Thisischaracterizedbyself-governanceandoperational
autonomy.Self-governanceisnecessaryforthepartnerstokeeptheir
freedomintheirdecisionwithoutconflictanddisagreements thatcan
hinderthecollaboration.Operationalautonomyisnecessarysothe
partnerscanmaintainacertaindegreeoffreedomintheiractionsto
achievetheirowngoals.Bothtypesofautonomymustbepresentat
thebusiness,process,andserviceleveloftheenterpriseandforeach
interoperabilitybarrier(conceptual,technological,and
organization-al). For instance, from need number 4 expressed above, three
autonomyrequirementscanbeformulated.
ABOGovernance: ‘‘Partner involved in a collaborative process is
responsible for selecting its suppliers’’ and ABOGovernanceCost:
‘‘Partner controlcostsrelated to the choice of suppliers’’. These
tworequirementsareexpressedatthebusinesslevelandforthe
organizational barrier.They ensurethat each partnerhasthe
choiceofitssuppliersandassociatedcosts.
APTOperational: ‘‘A process must keep required physical flow of
supply’’.ThisARconcernstheparticularoperationalautonomyin
aprocessandthetechnologicalbarriers.
A reversibility requirement is defined as ‘‘a statement that
specifiesafunction,abilityorcharacteristic,relatedtothecapacity
of a partner to go back to its original state (in terms of
performance)after collaboration,and which each partnermust
satisfy’’.
Reversibilityrequirementsarerelatedtothecapacityofagiven
systemtoreturntoitsinitialstateeveniftheimplementationof
the collaborative process leads to various adaptations and/or
changes(e.g.organization,workingmethod,newtool,etc.).Infact,
2Interoperabilityrequirementsareexpressedwiththefollowingconventions:
Firstletter:classofinteroperability Secondletter:interoperabilityconcern Thirdletter:interoperabilitybarrier Index:nameoftherequirement.
at the endof the collaboration, each partner must beable to
continuetofurtheritsownpurpose,itsmission,andachieveits
objectives. This mainly concerns the impact on the integrity,
stability, and performance of the system. With regard to
integrity,thesystem mustreturntoaknownoperatingmode.
Regarding stability, the system must be able to maintain its
viability.Regardingperformance, thesystem mustrecoverthe
levelofperformancethatcharacterizeditbeforethe
collabora-tionincludingvariations(i.e.,thesystemmayhavetoaccepta
lossof performance thatis knownanddefinedin advance.To
give an example, it is possible to extract three reversibility
requirementsfromneednumber7,whichfocusonperformance
criteria.
RSTPerformanceCost:‘‘Thecostofanactivityafterthecollaboration
corresponds to the cost before the collaboration including
variations’’.Thisrequirementconcernsthecostcriterion.
RSTPerformanceTime:‘‘Theexecution timeof anactivityafterthe
collaboration corresponds to the execution time before the
collaborationincludingvariations’’.Thisrequirementisrelated
tothetimecriterion.
RSTPerformanceQuality:‘‘Thenumberofproductsthatareprovidedby
anactivityaftercollaborationmatches–includingtolerances–the
number of products provided before the collaboration’’. This
requirementconcernstheperformancequalitycriterion.
Finally,aGraphofDecompositionofInteroperability
Require-ments(GRADEI)isproposedinordertofacilitatethedescription,
handling,anddecompositionofaninteroperabilityrequirement.
5.2. TheGRADEImodel:structureandpropagation
TheGRADEImodelisagraphusedtoformallyrepresentthe
requirements repository. It is based on (1) the principle of a
decomposition relationship between requirements, (2) the
previously proposed classification of interoperability
require-ments,and(3)theinteroperabilityframeworkdevelopedwithin
the INTEROP Network of Excellence [6]. It helps the user to
organize, reuse, and select the appropriate interoperability
requirementswithregardstoa givencollaborativeprocessfor
thepurposeofchecking.GRADEIisanorientedgraphaspresented
inFig.3.
Anoderepresentsarequirementatagivenlevelofdetail.Anarc
linkinganodeatonelevelofdetailtoothernodesatalowerlevelof
detail represents the decompositionrelationship. This
relation-ship, which links a target node (i.e., representing an abstract
requirementatlevelk)toitssourcenodes(i.e.,representingmore
preciserequirements at level k+1)is constrained by a logical
function.Thisfunctionexpressestheinfluenceofthesatisfactionof
requirementsrepresentedbythesourcenodesontherequirement
representedbythetargetnode.Thefollowingnotationsareusedto
formalizetheGRADEImodel:
p=numberoflevelsofdetail, p2N:
m=numberofnodesofthegraph,m2N:
n=numberofarcsofthegraph,n2N:
P
:setofmoments(times).String::=(‘a’...‘z’j‘A’...‘Z’)(‘a’...‘z’j‘A’...‘Z’j‘1’...‘9’j‘_’j‘-’)}
Fact={factjfact2VM[PM[Pr}where:
VM={variablesextractedfromtheprocessmodel}
PM={parametersextractedfromtheprocessmodel}
Pr={predicates extracted from the meta model of enriched
BPMN}
GRADEIisformalizedwithagraphG::=(A,N,N0)where:
A represents the set of arcs linking nodes: A={Aj/j2[0,n];
Aj::=(SourceN, TargetN)with(SourceN, TargetN)2NN,
Sour-ceN6¼TargetNandlevel(SourceN)>level(TargetN)}
Nrepresentsnodesofthegraph:N={Ni/i2[0,m];Ni::=(namei,
descriptioni,relationshipi,facti,leveli,valuei)}where:
(namei,descriptioni)2stringstring
relationi::=(T,
u
e,u
c)with:T
P
u
e: facti[T!{0,1} is thelogical function that describes thenecessarybutnotsufficient conditioninwhichthenodeNiis
verified. This condition is expressed only in the modeling
variables,parameters,andmodelingpredicatestakenfromthe
collaborativeprocessmodel.
u
c: NNi!{0,1}, i.e. {value(N1),..., value (Nk)}!{0,1} is thelogicalfunctionthatdescribesthenecessarybutnotsufficient
conditionwheretherequirementrepresentedbythenodeNiis
verified. This condition can be used to interpret the results
(values)ofnodessources.NNiisthesetofnodeNisourcesdefined
asfollows:
NNi={Nj/
9
Ak(Nj,Ni),k2[0,n],j2[0,m]withi6¼j}facti2Fact.
leveli2[0;p[indicatesthelevelofdetailoftherequirement.By
definition,therootelementhaslevel=0,i.e.interoperabilityin
thiscontextandlevel(Ni)returnstheleveliofnodeNi.
valuei2{0,1}showstheverificationresult,inabsentia0(false)
andwherevaluei=
u
e^u
c.9
!N0=(name0,description0,relation0,fact0,level0=0,value0)2NistherootnodeofthegraphGrepresentingthemostabstract
interoperabilityrequirement.
Itisworthnotingthatarequirementcanbecharacterizedbya
temporalaspect.Itcanbea-temporal,thatistosayindependentof
time.Inthiscase,itisverifiableatalltimes(thesetTisempty).It
canbetemporal,inotherwords,verifiableonlyatcertainstagesin
thecollaborationlifecycle.Thetemporalaspectofarequirementis
an important elementfor choosing theappropriate verification
technique.Furthermore,thechoiceofthelogicalfunction(
u
c)usedtolinkanabstractrequirementtomorepreciserequirementsisleft
totheuser’sdiscretion.Thus,therequirementsofeachlevelcanbe
analyzedseparately.Inthiscase,someoftherequirementsthatare
notsatisfied,canbeconsideredtobenegligibleorasrepresenting
anacceptableriskfortheuser.Theinteroperabilityrequirements
referencerepositoryobtainedisillustratedinFig.4.
As an example, for the GRADEI model presented Fig. 5,
propagation of interoperability requirements analysis is
performedusingthesefewequations:
Interoperability¼Compatibility^Interoperation
^Reversibility^Autonomy (1)
Compatibility¼BusinessC^ProcessC^ServicesC^DataC (2)
ServicesC¼ConceptualCS^TechnologicalCS^OrganizationalCS
(3)
ConceptualCS¼SyntaxCDS_SemanticCDS (4)
Inotherwords,byhypothesis,theoverallinteroperabilityofan
enterpriserequireseachcompatibility,interoperation,autonomy,
and reversibility requirement to be respected as expressed in
Eq.(1).Inthesameway,compatibilityisrespectedifandonlyif
eachrequirementrelatedtotheinteroperabilityconcerns
(busi-ness, process, services, and data) are themselves respected as
expressedinEq.(2).Then,interoperabilityconcernsarerespected
ifandonlyifinteroperabilitybarriersarerespectedasexpressedin
Eq.(3)attheserviceslevel.Finally,conceptualrequirementsare
respectedifthesyntaxorthesemanticrequirementisrespectedas
expressedinEq.(4).However,ifinteroperabilityisrequiredfor
onlyoneconcern(e.g.,processinteroperability),theusercanselect
andcheckonlyequationsrelatedtothisconcern.
6. Verificationofinteroperabilityrequirements
The objective of verificationis todemonstrate that a set of
selected interoperability requirements is satisfied. Indeed, the
GRADEI model presented above allowsusers to select relevant
requirementstobechecked.In ordertobeabletoperformthis
verificationbeforetheruntimeofthecollaborative process,this
one is done on a model of the collaborative process. Several
verification techniques exist in the literature such as informal
verificationtechniques(test,simulation,andexpertise)[20],and
formal verification techniques (model checking and theorem
proving)[21–23].
Thesimulationisdoneonatheoreticalmodelwhosebehavioris
consideredtobesimilartothebehaviorofthesystemconcerned.It
is done before the implementation of the system. However,
simulation is unable to assume all of the system’s behavioral
scenarios. It requires human expertise to analyze results and
formulatethedemonstration. Nevertheless,simulation isnowa
well-knowntechnique,whichisincreasinglydevelopedandused
inenterprises.Thetestisperformeddirectlyonanexistingsystem.
Itcancheck,forexample,capacityandrelevancetodetecterrors
beforesystemimplementation.Informalmethodsdo not
neces-sarilyrequiretheuseofamodel,butcanbeuseddirectlyonthe
realsystemtomaketheverification.Thesetechniquescanbeused
when a model of the system to analyze is not given or the
descriptionoftherequirementtoformalizeiscomplex.However,
thesemethodsrequirehumanskillsandcanbe,obviously,subject
tohumanerror.
Ontheotherhand,formalverificationtechniquescanbeusedto
exploreaformalmodelexhaustively(i.e.,amodelobtainedwitha
modelinglanguageusinga formalsemantics).In this case,it is
possibletoprovideaformalproofofwhetherornotarequirement
isrespectedindependentlyofanyhumaninterpretation.Formal
verification techniques can be used to analyze the behavioral
aspectofthecollaboration,whichoffersadynamicvisionofthe
system.However, thesemethods canbe difficulttoimplement
(e.g.,needforgreaterformalization)andaredifficulttoapplyin
somefields such as enterprise modeling (difficultto formalize
models).
Othertoolsdoexist,suchasconceptualgraphs,andcanbeused
as verification techniques [24]. For instance, verification using
conceptualgraphsisbasedonmathematicalmechanisms,suchas
projection, to ensure the veracity or simply the presence of
knowledgeinagivengraph.However,conceptualgraphsdonot
representthebehaviorofasystem,sotheyofferastaticviewofit.
Given theadvantages and disadvantages of each methodof
verification, we have proposed to use two formal verification
techniquesinacomplementarymanner,andtoalsomakeuseof
technicalexpertiseassummarizedinFig.6.
Thefirstverificationtechniqueisbasedonconceptualgraphs
[25]toverifya-temporalrequirements.The advantageofusing
conceptualgraphsis(1)todescribethecollaborativeprocessand
interoperabilityrequirementswiththesamelanguage,(2)tohave
a convenient graphical form to handle, and (3) to have a
mathematicalfoundationandmechanism(projection,rules,and
constraints).
Thesecondtechniqueisbasedonmodelchecking[23]forthe
temporalrequirements.Theadvantageofusingamodelcheckeris
(1) toincludetemporalaspectsofthecollaboration(i.e.,behavioral
modelof collaborativeprocess),(2) toconsiderallstates inthe
collaborativeprocessthroughoutthecollaboration,and(3)togive
formalproofoftheproblemsthatexist.
The finaltechnique is based on expertise.This technique is
deployedwheninteroperabilityrequirementshighlightparticular
pointsofviewoftheprocess,andcannotbedescribedduetoa
limitationimposedbythemodelinglanguage.Thisaspectisnot
consideredinthiswork.
ApplyingthesetechniquesrequiresustoassumethattheBPMN
modelinglanguageusedtobuildtheprocessmodelcanbeusedto
describeinteroperabilityrequirements.BPMNprovides
standard-izednotationthat isreadilyunderstandable byallstakeholders
involved in the design, development, and monitoring of a
collaborative process. However, it is necessary to enrich this
modeling languageto embed theinteroperability requirements
model. Theproposed conceptualenrichments described in[26]
includeinteroperabilityconceptssuchasthenatureoftheflow
exchanged (information,energy,material, orperson), the
avail-abilityofresourcesandtheiraptitudes.Furthermore,operational
enrichmentsaremadetostudythebehaviorofallrelevantBPMN
elements.
Theuseoftheseverificationtechniquesrequiresthe
collabora-tiveprocessmodeledwithenrichedBPMNtobetranslated–using
modeltransformationrules–intoanequivalentmodeluponwhich
the formal verification techniques can be appliedas shown in
Fig.7.Indeed,theproposedenrichedversionofBPMNsuffersfrom
a lack of formalization, and verification techniques cannot be
applied directly with regards to interoperability. The first
equivalent model was obtained using conceptual graphs. It
enabled ustoproducea-temporalrequirements proof,which is
presentedin[26].Inthiscase,verificationwasperformedwiththe
COGITANTtool[27].Thesecondequivalentmodelwasobtained
By using knowledge extracted from model: contextualised and provable By using knowledge coming
from the experts: cannot be ‘formally’ proven Interoperability requirements Model checker are verified by Conceptual Graphs temporal a-temporal Technical expertise
Fig.6.Proposedverificationtechniques.
usingabehavioralmodelinglanguagenamedNetworksofTimed
Automata for temporal requirements proof. In this case, the
UPPAALmodelcheckerisusedforvariousreasons:therichnessof
TCTLtemporallogic,itisanopensource,userfriendly,andstand
alonetool[23].Inbothcasesoftargetmodels,therequiredrules
for model transformation were developed with ATL (Atlas
TransformationLanguage)[28]inordertore-writethe
collabora-tiveprocessmodelintoConceptualGraphsandNetworksofTimed
Automata.InthecaseoftheConceptualGraphs,theobjectiveis
thereforetoassumethecoherenceoftheprocessmodel,thatisto
say to prove that each BPMN modeling entity used, and then
instantiatedintheprocessmodel,iswellandcompletelydefined.
Inthecase ofNetworksofTimedAutomata,thetransformation
ruleshave beenestablishedrespectinganequivalence between
BPMNentitybehaviorandstatemodelentitybehavior.Therefore,
interoperability requirements were formalized to make their
verificationpossible.Thus,a-temporalrequirementsare
formal-ized with conceptual graphs and temporal requirements are
formalized with TCTL. In addition, a non-formal verification
technique was used to verify, by expertise, interoperability
requirementsthatcannotbeformallyproven.Finally,theresults
ofthethreeverificationtechniquesareshowninthecollaborative
processmodel(modeledwithenrichedBPMN).Theseresultswere
further exploited with the GRADEI model to verify abstract
interoperabilityrequirementsusingtheprincipleofpropagation.
6.1. Verificationprocessfora-temporalrequirements
A conceptualgraphis definedas a graphwithtwo kinds of
nodes:conceptsandorientedrelationsasshowninFig.8witha
conceptualgraphthat canberead as: ‘‘Any activities(concept)
begin (relation) at a beginning date (concept)’’. Concepts and
relations aredescribed inhierarchicalstructures calledconcept
andrelationlattices.Individualmarkersareaddedtospecifythe
model(‘‘*’’meansgenericconcept).
TheCOGITANTtoolcanbeusedtohandleconceptualgraphs
uponwhichtheverificationprocessofa-temporalrequirementsis
based.Theverificationwithconceptualgraphsisbasedontheuse
of (1) a graph operation named projection, (2) a graph that
representsarequirement(alsonamedconstraintgraph)and,(3)a
graphthatdescribesthecollaborativeprocessmodel.Theprinciple
istochecktoseeifaconstraintgraphcanbeprojectedonthegraph
modelof theprocess.Ifprojection fails,therequirementisnot
verified and the causes can be highlighted by analyzing the
resultingconceptualgraph.TomakeverificationwithCOGITANT,
threetypesoffilesarenecessary,whicharecalledthesupport,fact,
andconstraintgraphs.
The‘‘support’’graphrepresentsalltheconceptsandrelations
fromtheenrichedBPMNmetamodelandmarkersrepresentingall
theinstancesoftheseconceptsandrelationsdefinedintheprocess
Fig.7.Verificationprocessforinteroperabilityrequirements.
[Acvity: *] (Begin) [Date: BeginningDate]
Fig.8.Exampleofaconceptualgraph.
model.The‘‘fact’’containstheequivalentconceptualgraphofthe
model obtained by applying ATL transformation rules and
respecting the support. Finally, the ‘‘requirement’’ to verify is
modeledinanotherconceptualgraphcalledthe‘‘constraint’’graph.
Verificationis performedusingtheprojection ofapositive ora
negativeconstrainton theconceptualgraphthatrepresentsthe
modeloftheprocessstudied.Apositive constraintisdescribed
witha causeand a conclusion and itsprojection is performed
accordingtothefollowinginterpretation:‘‘Ifthecauseistrue,then
theconclusionmustbetrueaswell’’.Anegativeconstraintisasingle
conceptualgraphanditsprojectionisinterpretedas:‘‘Ifanegative
constraint is not projected on the fact model, it is verified’’. The
projection mechanism is theprojection of a given requirement
translated in theconceptual graph on theobtained conceptual
graphthatrepresentsthetranslationofthemodel.
Forthepurposeofverification,weproposetotransformeach
enrichedBPMN element (UML class in themeta model)into a
concept. Then, we propose to convert each attribute of each
element(i.e.,attributesof eachclass)asaconceptalso.Finally,
relationsbetweenclasses(intheenrichedBPMNmeta-model)are
transformedintorelationsintheconceptualgraphasshowninthe
Fig.9.
ThreeATLtransformationsmustbeperformedtocompletethe
transformation from process model to COGITANT. Hereafter,
Fig.10representstheprincipleofthefirsttransformationtoget
thesupport model (the two others transformations – fact and
constraint–arebasedonthesameprinciplesandarenotdescribed
here).
Thefirsttransformationprocedure toobtainthesupportfile
(levelM1)startswiththeconsiderationofthemetamodels(level
M2) of the enriched BPMN language and COGITANT, which
conform,aswell,tothee-coremodel(levelM3).Thus,eachclass
(including its attributes)is translated into a concept and each
relationshipinthemeta-modelistranslatedintoarelationshipin
thesupportfile.Thistransformationismadeinordertoprovideall
the needed concepts and relationships used and subsequently
deployedinthefactfile.
Thesecondtransformationisusedtoobtainarepresentationof
the collaborative process model (fact) as a conceptual graph.
Finally,thelasttransformationisperformedtoobtainconstraints
(representingtherequirements)thathavetobeprojectedontothe
equivalent graph model of the process. In this case, the
requirementistranslatedintoapositive ornegativeconceptual
graphconstraintdependingontheuser’sintention.
Forexample,thecompatibilityrequirementCSOManager
previ-ouslypresentedanddescribedas:‘‘Eachservicehasaclearlydefined
manager who has authority over the rest of the team’’ can be
formalizedintoapositiveconstraintasshowninFig.11.
Theverificationofthisconstraintusingprojectionisperformed
withtheprojectionofthecauseontothefactsmodel.Ifthecause
canbesuccessfullyprojected,theconclusionmustbeprojectedtoo
inordertorespecttherequirement.
6.2. Verificationprocessfortemporalrequirements
The principle of a model checker is to verify properties
exhaustivelywithtemporizedandpossiblyconstrained
autom-atathatdescribethebehaviorofasystem.Obviously,herethe
system is the collaborative process model. Verification with
modelcheckersrequirestwophases.Thefirstphaseconsistsin
definingasetofequivalentbehavioralmodelsinthe
collabora-tive process model and in defining the collaborative process
Fig.10.TransformationfromenrichedversionofBPMNtosupportinCOGITANT.
modeltransformationrulestoapply.Thesecondphaseconsists
inreformulatingthetemporalrequirementsunder theformof
propertiesrespectingtheformallanguageadoptedbythechosen
modelchecker(inthisstudy,atemporallogic)[29].
TheUPPAALtoolcanthenbeusedtohandleabehavioralmodel
defined as a set of templates, which communicates with
synchronization (either in the form Expression! for sending or
Expression? for receiving synchronization), using channels and
syntaxlikesent/receive.Eachtemplatehaslocationsand
transi-tionstolinkalocationsourcetoatargetsource[23].
TheenrichedBPMNmodelmustbetransformedintoNetworks
ofTimedAutomatatoperformverificationoftemporal
require-ments.InFig.12,themodeltransformationprocedure(levelM1)
startswiththeconsiderationofthemetamodels(levelM2)ofthe
enrichedBPMNlanguageandUPPAALwhichconform,aswell,to
thee-e-e-coremodel(levelM3).
This transformation is made in order to provide all the
necessaryconceptsthatareusedanddeployedintheNetworks
ofTimedAutomata.Inthisway,itismandatorytoconsiderallthe
modelingentitieswhichwillbeusedinthecheckingtask.Thus,
eachclass(includingitsattributes)inthemeta-modelistranslated
intotemplates.Respectingthisconsideration,eachBPMNelement
canbeextractedfromthecollaborativeprocessmodelinorderto
produce the corresponding template representing Networks of
Fig.12.TransformationfromenrichedversionofBPMNtonetworksoftimedautomata.
Fig.13.Existingmodelandmodelwedeveloped.
TimedAutomata.Thus,thesetemplatesgatheralltheknowledge
describedinthemodel,and representthecollaborativeprocess
behavioralmodel.
Some behavioral models of BPMN elements, which use
NetworksofTimedAutomata,canbefoundintheliterature.For
instance,[30]proposethebehavioralmodeloftheBPMNelements
suchas:startandendevent,‘‘gatewaydatabasedparallel’’(AND),
the‘‘gatewaydatabasedexclusive’’(XOR),andthenativemodelof
Task.For instance,thebehaviorofataskis representedbyfour
locationsandtwosynchronizationsaspresentedinFig.13.Inthis
case,transformationrulesaredefineddirectly.Otherbehavioral
modelsthatdonotexist,butthatareconsideredtobefundamental
incollaborativeprocesses,arebeingdeveloped.Likewise,inthis
researchwork,wedevelopotherbehavioralmodelscorresponding
to(1)thetaskwhenaresourceisinvolved,(2)theresource,(3)the
‘‘gatewaydatabasedinclusive’’(OR)and(4)considerationofmany
in/outflow(includingsequenceand/ormessageflows)onatask.
Then,foreachenrichedBPMNelement,atransformationusingATL
isdefinedand performedtoobtainthebehavioralmodelinthe
formofNetworksofTimedAutomata.
Forinstance,thetranslationofataskwhenitusesaresource
andthetranslationofaresourcearepresentedFig.14.Initially,the
Fig.15.Behaviorofagatewaydatabasedinclusiveandmany(in/out)flows.
taskis waitingtostart.Then afterstarting,itusestheresource
whichisavailableatthebeginningbysendingitasynchronization
suchas‘‘in_resource!’’.Subsequently,theresourcereturnstoits
initialstatebyreceivingasynchronization‘‘out_resource?’’when
thetaskhasfinishedusingit.Finally,thetaskstops.
Furthermore, based on the templates given by [30] for the
gatewaydata based parallel (AND) and the‘‘gateway data based
exclusive’’(XOR),thebehaviorofthe‘‘gatewaydatabasedinclusive’’
(OR)andtheconsiderationofmany(in/out)flowsisproposedas
showninFig.15.Asaconsequence,weproposetorepresentthe
behavior of the‘‘gateway data based inclusive’’ by theuse of a
‘‘gatewaydatabasedexclusive’’and‘‘gatewaydatabasedparallel’’.
Then,we proposetosimulatetheexistence ofa ‘‘gateway data
basedparallel’’torepresentthein/outof manyflows(sequence
flowand/ormessageflow)ofatask.
Toenabletheimplementationofformalverificationtechniques,
thetemporal requirements areformalized intoTCTLproperties
(Timed Computation Tree Logic, i.e., the UPPAAL property
specification language) [23]. TCTL is an extension of CTL
(ComputationalTreeLogic)whichcanbeusedtoconsiderseveral
possiblefuturesbasedonthestateofasystem.TheUPPAALmodel
checkerhasfourTCTLquantifiers(A:forallpaths,E:apathexists,
[]:allstatesinapath,<>:somestatesinapath),whichcanbe
usedtowriteapropertyp:
- E<>p:reachability(i.e.,itispossibletoreachastateinwhichp
issatisfied).
- A[]p:invariantlyp(i.e.,pistrueinallreachablestates).
- A<>p:inevitablep(i.e.,pwillinevitablybecometrue).
- E[]p:potentiallyAlwaysp(i.e.,pispotentiallyalwaystrue).
- P!q:pleadstoq(i.e.,ifpbecomestrue,qwillinevitablybecome
true).
According to the UPPAAL property specification language
defined above, the temporal requirements written in natural
languagearemanuallyre-writtenintopropertiesusingTCTL.Then
theUPPAALmodelcheckerexhaustivelyverifiespropertiesinTCTL
throughalltheexecutionpathsofthebehavioralmodelsthatare
reachable.
For instance, the ISOExecutionTime requirement described as:
‘‘Resource is active throughout the duration of execution of
theactivity(5<T<10)’’canbeformalizedintoapropertyusing
TCTLas:
‘‘E<>Resource.ActiveandTask.WorkingandT>5andT<10’’
This property indicates that a path can exist, where the
resourceisactiveandthetaskisinthestateWorkingbetween
5<T<10. This property can be verified with the templates
representedFig.14.Thenextpartpresentsanapplicationcase
study.
7. Applicationcasestudy
ThecollaborativeprocessweproposeisshowninFig.16.Itaims
todesignandproducevehicles.Variousgeographicallydistributed
partners in the European territory wish to anticipate potential
defectsinherentintheirinteroperability.
Thecompatibilityrequirementstobeverifiedarerelatedtothe
organizationalbarrieratthelevelofservicesandareexpressedas
follow:
CSOManager:‘‘Eachservicehasaclearlyidentifiedmanager.’’
CSOAbility:‘‘Aresourcehastheabilitytodoactivityrequested.’’
CSOAuthorization: ‘‘The senderhas the necessaryauthorizationsto
interactwiththereceiver.’’
Thesecompatibilityrequirementsarea-temporal.Theymustbe
verified with conceptual graphs. As a result, they must be
formalizedintoconceptualgraphsasshowninFig.17.
ThecompatibilityrequirementCSOManagerisformalizedusinga
positiveconstraint. Thisconstraint expresses thefactthat each
service has a manager. However, it does not indicate if this
managerhasbeenidentified.Therefore,thisrequirementcanbe
decomposedintothreecompatibilityrequirementsdescribedas
follow:
CSOManagerName:‘‘Themanagerofaservicehasaname.’’
CSOManagerPhone:‘‘Themanagerofaservicehasaphonenumber.’’
CSOManager:‘‘Themanagerofaservicehasan’’
Thesecompatibilityrequirementsgivemoreinformationabout
themanager’sname,phonenumber,andtheycanbeformalized
withthreenegativeconstraintsasshowninFig.18.
ThecompatibilityrequirementCSOAptitudeisformalizedusinga
positiveconstraint.Thisconstraintisexpressedasfollows:foreach
service(task),theresourcesusedbythis servicemusthavethe
requiredskills.
The compatibility requirement CSOAuthorization is formalized
usinga positiveconstraint. Thisconstraint reflectsthefact that
each task interactingwith another taskrequires theresources
involved to have the relevant authorizations to perform the
exchanges.
The interoperationrequirements toverify arerelated tothe
organizationalbarrierattheserviceslevel,andareexpressedas
follow:
ISOTimeExecution: ‘‘Resource is active throughout the duration of
executionoftheactivity.’’
Fig.18.FormalizationofCSOManaagerwiththreenegativeconstraints.
ISOExchangeTime:‘‘Thetimeforexchangebetweenservicesisstrictly
lessthanntimeunits(TU).’’
ISOReceipt:‘‘Thereceiversendsareceipttothesender.’’
Thefirstandsecondinteroperationrequirementshave
tempo-ral aspects and must be formalized with TCTL to make their
verificationpossiblewith theUPPAAL modelchecker. The final
interoperationrequirementhasana-temporalaspectandmustbe
formalizedwithconceptualgraphstoverifyitusingtheCOGITANT
tool.ThefirstinteroperationrequirementISOTimeExecutionisusedto
verifyiftheactivities‘‘motorassembly’’and‘‘chassisassembly’’can
usethesameresource. Asaconsequence, this requirementhas
temporalaspectsandisformalizedusingthetwopropertiesshown
inFig.19.
ThesecondrequirementISOExchangeTimeischosentobeverified
toinforminteractingenterprisesif theexchangetime between
theiractivitiesisrespectedandlessthanthedesiredexchangetime
limit.Thistemporalrequirementisformalizedbyapropertyusing
TCTL.The finalinteroperationrequirement ISOReceipt is used to
ensurethatthereceiverhasreceivedstocks.Thisrequirementhas
ana-temporal aspect and is formalizedby a constraint with a
ConceptualGraph.
Furthermore,weproposetoverifyanautonomyrequirement
andareversibilityrequirement.Theserequirementsareexpressed
attheservicelevelfortheorganizationalbarrierandareexpressed
asfollows:
ASOResource: ‘‘A service canreplace a resource used by another
serviceinthepubliccollaborativeprocess.’’
RSOPerformanceResource: ‘‘The resources used in the collaborative
processhavethesameperformancelevel–includingtolerances–as
beforethecollaboration.’’
ASOResourceexpressesthefactthataserviceisabletoreplaceits
resource if it is used by another one. RSOPerformanceResource
represents the abilityof a resource to retrieveits past
perfor-mances. These requirements cannot be verified using formal
verificationtechniques;however,theycanbeverifiedusingthe
expertisetechnique.Finally,theresultoftheverificationusingthe
UPPAALand COGITANTtoolfortheverificationofcompatibility
andinteroperationrequirementsisshownFig.20.
Theresultsofa-temporalrequirementsverificationareshownon
theleftsideofFig.20.TherequirementsCSOManagerName,CSO
Mana-gerPhone and CSOManagerare satisfied by all tasks (no errors are
reported).Thismeansthatthemanagerisknownandidentified.The
CSOAptituderequirementwasnotsatisfiedbyalltasks.Indeed,wecan
notethatthe‘‘Motorassembly’’andthe‘‘Chassisassembly’’tasksuse
the sameresource.Thefirsttaskrequires the‘‘Motorcomponent
assembly’’abilitywhilethesecond taskrequires the‘‘Component
assembly’’ ability. However, the resource only has the ‘‘Motor
componentassembly’’ability.Asaresult,thetaskshouldchangethe
resource.Throughthedetectionofthisproblemusingtheapproach,
thechangeoftheresourcecanbemadebeforetheexecutionofthe
process.Ifthischangeisnotmadebeforerunningthecollaborative
process,thisproblemcanhinderthecollaborativeprocessinterms
ofexecutiontimetomakethischangeafterithasbeendetected.The
verificationoftheCSOAuthorizationrequirementindicatesthatithas
beensatisfiedbyallactivitiesthatrequireauthorizations.
Finally,verificationoftheISOReceiptinteroperationrequirement
indicatesthatthe‘‘Chassisreceptionandstorage’’,‘‘Supplyreception
andstorage’’,and‘‘Motorreceptionandstorage’’tasksdonotreturna
receiptforthetasksthatprovidedthemsupplies.Thepartnerthat
isinchargeofdeliveringthecomponentsfortheotherpartners
mustensurethat thedelivery ofeach componentis completed
successfullyto avoid possiblecosts for re-delivery and related
delays.
The verificationof temporal requirementsis shownonthe
rightof Fig.20. ThetwopropertiesrepresentingtheISO
TimeEx-ecution requirement for the ‘‘Motor assembly’’ and ‘‘Chassis
assembly’’ tasks are satisfied. Indeed, one resource is used by
thetwotasksatdifferentperiods.However, it isimportant to
keepinmindthatthisresourcedoesnothavetheskillsrequired
byonetask.Asaresult,theabilityofthetwotaskstousethe
sameresourcedoesnotmeanthatitcanbeused.Inconclusion,
itisimportanttotakealltheinteroperabilityrequirementsinto
consideration because the verifications with both tools are
complementary. Finally, the verification of the ISOExchangeTime
requirementcanbeused toconcludequicklyontheexchange
time between all tasks.The resultindicates thatone of tasks
doesnotrespectthemandatoryexchangetime.Theverification
oftheseinteroperabilityrequirementsprovideslocaldetection,
whichcanbeusedsubsequentlytosolvetheproblemsdetected.
However, this local detection is not sufficient. Indeed, these
problems can impact the collaboration at a global level. As a
result, we propose to use propagation mechanisms with the
GRADEImodelasshowninFig.21.
TheresultsoftheverificationwiththeUPPAALandCOGITANT
toolsforthetemporalanda-temporalrequirementsareusedby
the GRADEI model (requirements represented on the far left).
Requirementsmodeledingreen(satisfied)andred(notsatisfied)
representtheresultoftheexpertise.Theexpertcanvalidateornot
validatearequirementdirectlyintheGRADEImodel.Thelogical
function that links the abstract requirements to more specific
requirements is the logical ‘AND’ operator. The result of the
propagationindicatesthatevenifaresourceisavailabletoperform
a task, if it does nothave the requiredskills, thecollaborative
process has interoperability problems. In addition, the
non-verificationoftheserequirementsmeansthatthemoreabstract
requirement‘‘interoperability’’isnotsatisfied.
8. Conclusion
In a collaborative context, interoperability is becoming
increasinglyimportant.Apartnerinvolvedincollaborationwith
otherpartnersaimstodetectandsolveinteroperabilityproblems
asquicklyaspossible.Theapproachweproposeaimstoformulate,
formalize, and check interoperability requirements in order to
detect locally and globally interoperability problems in an
anticipativewaythatusesverificationtechniques.Theformulation
of interoperabilityleadstodefinefourcategoriesrelatedtothe
compatibility, interoperationautonomy and reversibility. These
categories are then split up and structured using the GRADEI
model. The analysis of interoperability requirements in a
collaborative process model uses model transformation
techni-ques, formal verification techniques for local verification and
propagationmechanismforglobalverification.Localverificationis
performedusingcomplementaryverificationtechniques.Thefirst
verificationtechniqueusesconceptualgraphstoverifya-temporal
interoperabilityrequirements.Thesecondverificationtechniqueis
a formal verification technique using model checkingto verify
temporal interoperability requirements. Finally, a non formal
verification technique such as expertise is applied to verify
requirementsthatcannotbeformallyverified.Thelocaldetection
ofinteroperabilityrequirementsisinsufficient.Indeed,theresult
oftheverificationofarequirementcaninfluencetheinterpretation
oftheresultofanotherrequirement.Sotheglobalverificationis
basedonthepropagationoftheresultsofthelocalverificationby
interpreting some parts of the GRADEI model. Futureresearch
mustfirstanalyzetheverificationofreversibilityandautonomy
requirements.Thisverificationcanbedonewithacomplementary
simulation approach based on distributed multi-agent systems
[31]toimprove interoperabilityproblemdetection. Finally,our
research work aims to find solutions for the interoperability
problemsdetected.
References
[1]J.Touzi,«Aidea` laconceptiondeSyste`med’InformationCollaboratif:supportde l’interope´rabilite´ desentreprises»,PhDThesis,InstitutNationalPolytechniquede Toulouse,November2007(inFrench).
[2]B.Aubert,A.Dussart,Syste`med’InformationInter-Organizationnel,Rapport Bour-gogne,GroupeCIRANO,March2002(inFrench).
[3]A.Esper,«Inte´grationdesapprochesSOAetoriente´eobjetpourmode´liserune orchestrationcohe´rentedeservices»,PhDThesis,InstitutNationaldesSciences Applique´sdeLyon,September2010(inFrench).
[4] ISO/DIS11345-1,Advancedautomationtechnologiesandtheirapplications,Part 1:Frameworkforenterpriseinteroperability,2009.
[5] IDEASProjectDeliverables,«WP1-WP7»,Publicreports,2003.
[6] INTEROP:EnterpriseInteroperability-Frameworkandknowledgecorpus–Final report,INTEROPNoE,FP6–Contractno.508011,DeliverableDI.3,May21st2007. [7] ATHENA IntegratedProject,«Guidelinesand best practicesfor applying the ATHENAinteroperabilityframeworktosupport SME participationindigital ecosystems»,ATHENAdeliverableA8.2,2007.
[8] C4ISRArchitectureWorkingGroupLevelsofInformationSystemsInteroperability (LISI),UnitedStatesofAmericaDepartmentofDefense,WashingtonDC,USA,30 March,1998.
[9]A.Tolk,J.A.Muguira,TheLevelsofConceptualInteroperabilityModel, Proceed-ingsofFallSimulationInteroperabilityWorkshop(SIW),Orlando,USA,2003. [10] T.Clark,R.Jones,OrganizationalInteroperabilityMaturityModelforC2,Proc.of
CommandandControlResearch&Techn.Symposium,Newport,USA,1999. [11] N.Daclin,D.Chen,B.Vallespir,Methodologyforenterpriseinteroperability,in:
17thIFACWorldCongress(IFAC’08),Seoul,Korea,2008.
[12] C.T.Ford,«Interoperabilitymeasurement»,PhDThesis,DepartmentoftheAir ForceAirUniversity,AirForceInstituteofTechnology,2008.
[14] BPMN,BusinessProcessModelingNotation,V1.2,http://www.bpmn.org/,2009. [15] NEHTA,«Interoperabilitymaturitymodel»,Version1.0,26March2007. [16] INCOSE,«SystemEngineering(SE)HandbookWorkingGroup,SystemEngineering
Handbook,A«HowTo»»,Version3.1,GuideForAllEngineers,http://www.incose. org,2007.
[17]ISO/IEC15288:2008(E),«IEEEStandards15288.2008–Systemsengineering– Systemlifecycleprocesses(2ndedition)»,2008.
[18] S.J.Scucanec,J.R.VanGaasbeek,Adayinthelifeofaverificationrequirement,in: U.S.AirForceT&EDays,LosAngeles,California,February,2008,2008. [19] M.Kasunic,W.Anderson,Measuringsystemsinteroperability:challengesand
opportunities,Softwareengineeringmeasurementandanalysisinitiative, Tech-nicalnoteCMU/SUE-2004-TN-003,2004.
[20] O.Balci,W.Ornwsby,Expandingourhorizonsinverification,validationand accreditationresearchandpractice,in:E.Yu¨cesan,C.-H.Chen,J.L.Snowdon,J.M. Charnes(Eds.),2002WinterSimulationConference,2002.
[21] M.Edmund,ClarkeJr.,O.Grumbereg,A.P.Doron,ModelChecking,TheMITPress, 1999.
[22] B.Be´rard,M.Bidoit,A.Finkel,F.Laroussinie,A.Petit,L.Petrucci,PhSchnoebelen,P. McKenzie,SystemsandSoftwareverification:ModelCheckingTechniquesand Tools, Springer,2001.
[23] G.Behrmann,A.David,K.G.Larsen, ATutorialon Uppaal, Department of ComputerScience,AalborgUniversity,Denmark,2004.
[24] V.Chapurlat,B.Kamsu-Foguem,F.Prunet,«Enterprisemodelverificationand validation:anapproach»,AnnualReviewinControl,vol.27,no.2,pp.185–197, 2003.
[25] J.F.Sowa,Conceptualgraphs,IBMJournalofResearchandDevelopment(1976). [26] M.Roque,V.Chapurlat,Interoperabilityincollaborativeprocesses:requirements characterisationandproofapproach,in:PRO-VE’09,10thIFIPWorking Confer-enceonVIRTUALENTERPRISES,Thessaloniki,Greece,7–9October,2009,2009. [27] CogitantCoGITaNTVersion5.2.0,ReferenceManual,http://cogitant.sourceforge.
net,2009.
[28] ATLASGroupeINA&INRIANantesATLAtlasTransformationLanguage, Specifi-cationoftheATLVirtualMachine,Version0.1,2005.
[29] R.Alur,C.Courcoubetis,D.Dill,Model-checkingindensereal-time,Information andComputation104(1)(1993)2–34.
[30]V.Gruhn,R.Laue,Usingtimedmodelcheckingforverifyingworkflows,Computer SupportedActivityCoordination7(2005)5–88.
[31] A.S.Rebai, V.Chapurlat, Systeminteroperabilityanalysis bymixingsystem modelingandMAS:anapproach,agent-based,technologiesandapplications forenterpriseinteroperability(ATOP),in:EighthInternationalJointConference on Autonomous Agents & Multi-Agent Systems (AAMAS 2009), Budapest, Hungary,May,2009,2009.
