Making explicit domain knowledge in formal system development

Any correspondence concerning this service should be sent

to the repository administrator:

[email protected]

This is an author’s version published in:

http://oatao.univ-toulouse.fr/24847

To cite this version: Ait Ameur, Yamine and Mèry,

Dominique Making explicit domain knowledge in formal system

development. (2016) Science of Computer Programming, 121.

100-127. ISSN 0167-6423

Official URL

DOI :

https://doi.org/10.1016/j.scico.2015.12.004

Open Archive Toulouse Archive Ouverte

OATAO is an open access repository that collects the work of Toulouse

researchers and makes it freely available over the web where possible

Making

explicit

domain

knowledge

in

formal

system

development

✩

Yamine

Ait-Ameur

a

,

Dominique

Méry

b

a _{IRIT,INPT-ENSEEIHT,France} b _{LORIA,UniversitédeLorraine,France}

a b s t r a c t Keywords:

Systemdesignmodels Explicitvs. implicitsemantics Ontologiesandontologyengineering Modelsverificationandvalidation Domainknowledge

Modeling languages are concerned with providing techniques and tool support for the design,synthesisandanalysisofthemodelsresultingfromagivenmodelingactivity,this activity being usually part of a system development model or process. These languages quitesuccessfullyfocusedontheanalysisofthedesignedsystemexploitingtheexpressed semantic power of theunderlying modeling language. The semantics of these modeling languagesarewellunderstoodbythesystemdesignersand/orthemodelinglanguageusers i.e.implicitsemantics.

In general, modeling languages are not equipped with resources, concepts or entities handling explicitly domain engineering features and characteristics (domainknowledge) inwhichthemodeledsystemsevolve.

Indeed, the designer has to explicitly handle the knowledge issued and/or mined from an analysis ofthis applicationdomain i.e. explicit semantics. Nowadays,making explicit thedomainknowledgeinsidesystemdesign modelsdoesnotobeytoanymethodological rule validated by the practice. The modeling languages users introduce through types, constraints,profiles,etc.thesedomainknowledgefeatures.

Ourclaimisthatontologiesaregoodcandidatesforhandlingexplicitdomainknowledge. They define domain theories and provide resources for uniquely identifying domain knowledge concepts. Therefore, allowing models to make references to ontologies is a modularsolutionformodelstoexplicitlyhandledomainknowledge.

Overcomingtheabsenceofexplicitsemantics expressioninthemodeling languagesused to specify systems models will increase therobustness of the designed system models. Indeed,theaxiomsandtheoremsresultingfromtheontologies,thankstoreferences,can beusedtostrengthenthepropertiesofthedesignedmodels.

Theobjectiveofthispaperistoofferrigorousmechanismsforhandlingdomainknowledge indesignmodels.Thispaperalsoshowshowthesemechanismsaresetupinthecasesof static,dynamicandformalmodels.

✩ _{ThisworkwassupportedbygrantANR-13-INSE-0001(TheIMPEXProjecthttp://impex.gforge.inria.fr)fromtheAgenceNationaledelaRecherche(ANR).}

E-mailaddresses:[email protected](Y. Ait-Ameur),[email protected](D. Méry). URLs:http://yamine.perso.enseeiht.fr/(Y. Ait-Ameur),http://www.loria.fr/~mery/(D. Méry).

1. Introduction

Problemstatement A lotof efforts have been devoted to thestudy ofontologies and their applications inthe areaof se-manticwebandinformationretrieval.Intheseareas,studiedobjectsareusuallycorpusesofdocumentsliketexts,videos,or images withweak designmodels(characters,signals,pixels)onwhichitisveryhardtoperformaccurateandrichanalyses. Several approaches fordescribing,designing, formalizingontologies for these application domains havebeen produced by many authors.Moreover, these approachesfocused on establishing formallinks betweenthese ontologies and the studied domain objects.Themajorityofthese approachespaidalotofattention totheuseofontologies inordertomakeexplicit thesemanticsofthese objectsandinterpretthem.Intheseapproaches,theobjectivesaretoallowusers1)tointerpretand tounderstandwhatisthesemanticscarriedoutbytheseobjects,and2)toquerythesecorpusesofdocumentsand extract relevantinformation.Here,termsandpatternsarefundamentaltoperform suchanalysesandreasoningcapabilitiesoffered bytheontologies playanimportantrole.

Insystemengineering,designmodelsarericherthan theonesassociatedwithtexts,images orvideos.Engineersdefine, using a modeling language, complex design models. Several design models may be defined for the same system. They perform differentanalysesofthesemodelsaccordingtothemodelinglanguageandtechniquestheyareusing.

Althoughengineers usecomplex design descriptionsto design their models,they still miss some relevant information related tothedomainofinterest.Inmostofthecases,thisisdue to

1. thefactthatengineersusetheavailablemodelinglanguagestohardencode,onthefly, specificdomainpropertieswith theirown pointof view,using thesemantics oftheavailablemodeling languages(implicit semantics). Sucha process maylead to incomplete and/orinconsistent descriptions, especiallyin the caseof modelcomposition, decomposition, abstractionand/orrefinement;

2. and to the absence of resources allowing an engineer to make explicit the domain knowledge of interest (explicit semantics).Themainproblemisrelatedtotheabsence,inthedesignmodelinglanguages,ofresourcessupportingsuch knowledgedomaindescriptions.

Objectives The objective of thispaperis to show that domain knowledge formalizedby ontologies on the one hand and design models on the other hand can be integrated. Once this integration is realized, new properties issued from the domainknowledgeenrichthedesignmodelsandimprovetheirverificationandvalidation.Thisintegrationhasthemeritto strengthen designmodels.

Our approach advocates the useof domain ontologies in order to make explicit thedomain knowledge and to enrich design models with relevant domain properties expressed in these domain ontologies. For this purpose, we propose to formalizelinksbetweendomainontologiesand designmodelsusingannotations.

Ourcontribution In this paper, we give an overview of ontologies when used for in other domains than semantic web. Indeed, we study domain ontologies for modeling specific domains particularly in system engineering domain modeling with a specific focus on engineering. By focus on engineering, we mean the use of ontologies to increase the quality of formaldesignmodelsdevelopedforsystemengineering.

Wereporton theuseofdomain knowledgemodelsexpressed byontologies toannotatedesign models. Byannotation, wewantthedefinitionofspecificmechanismstomakeexplicitdomainknowledgeindesignmodels.Theproposedapproach shall show howdomain knowledgeinformationcanbeexploited bythedesign modelsinorderincreasetheir qualityand expressiveness. Axiomsand theoremscarriedoutbyontologies,modelingknowledgedomains,shallbeexploitedbysystem design models.Weillustratethedefined annotation-basedapproachontwodifferentcasesofformalmodeling.

1. First,weconsider thecomparisonofbehavioralmodelsexpressedbylabelledtransitionsystems(lts).Traditional tech-niquesusesimulationorbi-simulation relationships[1]tohandlesuchcomparisonsoflts sharingasamesetoflabels. Theneedtocomparelts withdifferentsetsoflabelsmayoccur indifferentsituationslikesemantic-webservices[2–4] orplastic humancomputer-interfaces [5,6]. Relations borrowedfrom ontologies areused torewrite labels inorder to obtainlts withthesameset oflabels.Bi-simulationpropertiescanbecheckedontheobtainedlts.

2. The second situation is illustrated by proof and refinement based formal methods. We show how the Event-B [7] methodhandles the definitionand theexploitation ofontologies inorder to enrich classical models with ontological invariantsdescribed withdomain ontologies.New propertiesissued from domainknowledge expressionwhich enrich theEvent-Bmodelsbecomeverifiable.

Structureofthepaper Thispaperisstructuredasfollows.Nextsectiondiscussessemanticaspectsandgives our interpreta-tionofmakingexplicitdomainknowledgeindesignmodels.Itdiscussesimplicit andexplicit semantics.Section3overviews the main characteristics of ontologies when defined for characterizing engineering knowledge domains.We focuson the definition and on the useof theontologies insystem and software design. Then, section 4 discusses theexisting separa-tion ofdomain modelsand design modelsand theneed tointegrate themwhendesigning asystem. Ourmethodology to handle thesemanticofadomainexpressedbyanontology inadesignmodel ispresentedinsection 5. Theuseofformal methodsisdiscussed.Finally,sections6and7aredevotedtothedeploymentofourmethodologyinthecaseoftwoformal

methods:modelcheckingonlabelledtransitionsystemsandproofandrefinement-basedformalmethods.Lastsectiongives conclusionandfutureresearchdirections.

2. Implicitversusexplicit

Ingeneral, thedefinitionofamodelinglanguageisassociated tothenotionofformalsystemwhich definesthreemain elements.

1. Asyntax givingthesyntacticrepresentationofthelanguageconstructs.

2. A semantics given by a satisfaction relationship, usually denoted by |= expressing the possible interpretations of the syntacticconstructsexpressedwithinthemodelinglanguage.Thisrelationshipdescribesthelogicalnotionsof interpre-tationand model.

3. A proofsystem defined byanentailmentrelationship denoted by⊢expressing thecapability to deducenewtheorems fromaxiomsandalreadyprovedtheorems.

Modeling languages are used for engineering softwareand/orsystems and it is necessary to have a clear correct and completemeaningoftheadjectivesimplicit and explicit,inaformalframework.

2.1. Implicitsemantics

When consideringthetermimplicit inmodelinglanguages(forinstance, Event-B[8],orlabelledtransitionsystems[9]), we refer to underlying semantic aswell aspragmatic features, which are expressing the semantics of modeling elements (sets, axioms,datastructures,state-variables,safetyproperties,events,. . . ).Theunderstandingofthoseunderlyingfeatures becomes tacit through the learning of the modeling language, which is supported byspecific consistent semantics-based techniques and pragmatic tools (for instance, Rodin [10] is an environment for developing Event-B models, or the CADP toolbox [11]equippedwithamodelcheckerforanalyzingautomata-basedmodels).

2.2. Explicitsemantics

In general usage, explicit means fullyrevealed or expressedwithoutambiguity,whilst implicit means implied orexpressed indirectly or tacit.Themeaningof thesetwo adjectivesisrelated to semanticalfeatures ina currentcontext and itshould be notedthat thereis some inconsistency, withinthecomputer science and software engineeringcommunities, regarding the precise meaning of these adjectives. For example, in logic and belief models [12] asentenceisexplicitlybelievedwhen itisactivelyheldtobetruebyanagentandimplicitlybelievedwhenitfollowsfromwhatisbelieved. However, in thesemantic web[13]orinsystemengineering,Semanticscanbeimplicit,existingonlyinthemindsofthehumans[. . . ].Theycanalsobeexplicit andinformal,ortheycanbeformal. The Explicit Semantic Analysis (ESA) [14] interprets semantics of unrestricted natural language textsand representsmeaninginahigh-dimensionalspaceofconceptsderivedfromWikipedia,thelargestencyclopediain existence.Themeaningofanytextisexplicitly representedintermsofWikipedia-basedconcepts.Therequirementsengineering communityusesthetermstodistinguishbetweendeclarative(descriptive)andoperational(prescriptive)requirements[15], wheretheyacknowledgetheneedforaformalmethodforgeneratingexplicit,declarative,type-levelrequirementsfromoperational, instance-levelscenariosinwhichsuchrequirementsareimplicit.

2.3. Separationofconcerns

Nowadays,severalresearchprojectsandapproaches[16–18]aimatformalizingmathematicaltheoriesthatareapplicable in the formal developments of systems. These theories are helpful for building complex formalizations, expressing and reusingproofofproperties.Theneedforhandlingdomainknowledgehasbeenidentifiedsofarbythesoftwareengineering community[19–21].FollowingtheDomainEngineeringDogma,D. BjørnerandA.Eir[22]emphasizetheroleofunderstanding thedomain, when designing a software system. They describe structures usingan ontology aspect. An ontology consistsof entitiesoffourkindsofspecificationtypes:simpleentities,operations,eventsandbehaviors. Usually, these theories are defined within contexts, that are imported and and/or instantiated. They usually represent the implicitsemantics of the systems and areexpressed bytypes,logics, algebras, etc.based approaches.Domainengineering [16–18]adequately addressesthe formal description of domains expressing the semantics of the universe in which the developed systems run and their integrationintheformaldevelopmentprocess.However,thisdomaininformationisusuallydefinedinanontology [23].

Severalrelevantproperties—safety,security,liveness,forinstance—arecheckedusingformalmethods.Theseproperties are defined intheimplicit semanticsassociated to theformaltechniquebeing used.When consideringthese properties in their context withtheassociated explicitsemantics, these properties maybeno longer respected ormay have adifferent

meaning. AccordingtoD.Bjørnerand A.Eir[22],. . . Thedomaindescription,. . . ,is(best)expressedwhenbothinformallynarrated andformally specified. The formalization is based on a list of explicit properties defined as axioms. The identification of

properties as axioms is a crucialstep when dealing withdomain engineering,since itisbased on engineeringknowledges and expertises.

Webelievethatwithoutamoreformalsoftwareand/orsystemengineeringdevelopmentapproach,basedonseparationofimplicit andexplicitsemantics, the composition of software and/or system components in common contexts risks compromising correct operationoftheresulting system.Thisisasignificantproblemwhensoftware and/orsystemsareconstructed from heterogeneouscomponents[24]thatmustbereliableinunreliablecontexts[25].

2.4. Needforintegratingtheimplicitandexplicitconcepts

We areconcernedwith theseparation ofconcerns whenreasoning about propertiesof models.Althoughthe concerns needtobecleanlyseparated,themodelsneedtobetightlyintegrated:achievingbothisasignificantchallenge.

Allowingformalmethodsusersand developerstointegrate—inaflexibleand modularmanner—boththeimplicit se-mantics,offeredbytheformalmethodsemantics,andtheexplicitsemantics,providedbyexternalformalknowledgemodels like ontologies,isa majorchallenge. Indeed, theformal modelsshouldbe defined intheformal modelinglanguage being used,andexplicitreferenceand/orannotationmechanismsmustbeprovidedforassociatingexplicitsemanticstotheformal modeling concepts. Once thisintegrationisrealized, theformalization and verification ofseveral properties related tothe integrationofheterogeneousmodelsbecomes possible.The mostimportantproperties that needto beaddressedrelate to interoperability, adaptability,dissimilarity,re-configurability andidentificationofdegradedmodes.Refinement/instantiation and composition/decomposition couldplay a majorrole for specifying and verifyingthese properties.Currently, no formal methodnorformaltechniqueprovidesexplicitmeansforhandlingsuchanintegration.

Inthecontextofformalmethods,itiswellknownthat severalformalmethodsforsystem designand verificationhave been proposed.Thesetechniquesarewellestablishedonasolidformalbasisandtheirdomainofefficiency,theirstrengths and weaknessesarewellacknowledgedbytheformalmethodscommunity.Although,somead-hocformalizationofdomain knowledge [16–18] withinformal methodsis possible, noneof these techniques offers abuilt-in mechanismfor handling explicitsemantics.

Regardingontologiesand domainmodeling,mostoftheworkhasbeenachieved inthelargesemanticweb,information retrieval, naturallanguageprocessing,. . . researchcommunities.There,theproblemconsistsofannotatingwebpagesand/or documentswith semanticinformation availableinontologies.Thus,ontologieshave mainlybeenused forassigning mean-ingsandsemanticstotermsoccurringindocuments.Once,thesemeaningsareassigned,formalreasoningcanbeperformed ontheontologysideduetotheirformaldescriptivelogicsbasis.Ingeneral,however,thedocumentstobeannotateddonot conformtoanymodel(orconformtoweakmodels,usuallybasedonXMLdescriptionsexpressingdocumentstructures)and thedomainassociatedto thedocumentsisnotfixed.Therefore,ontologies behavelikeamodelassociated totheresources that areannotated.Asaconsequence,ontologies,asamodel,avoidsimplicitsemanticsalignmentbetweenthesemanticsof theontologyandoftheannotatedresourcesmodelinglanguages.

We propose tointegratebothworlds. On theone hand, formal methodsfacilitate prescriptive modeling whereas,on the other hand, ontologies providemechanisms forexplicit descriptive semantics. Weconclude by notingthat, inmost cases, the formal models are usually defined in afixed and limited application domain wellunderstood by thedevelopers and in main case studies, expertises in a given domain as avionics, transportations, medecine or energy, . . . are required for providingaclear,correctand completemodelofthesystemunderengineering.

3. Ontologiesaregoodcandidatesfordomainknowledgemodeling

As mentionedabove, alotof effortshave beendevoted to thestudyof ontologiesand their applicationsin theareaof semantic web and information retrieval. Several approachesfor describing,designing and formalizing ontologies forthese application domainshave been proposed bymany authors. Models [26–31], browsers like Protégé1 _{[32,33]or PlibEditor,}2

reasoners [34–37],annotators[38,39],XML-basedtranslators[40,41]havebeen developedto engineersuchontologiesand establish formallinkswiththestudieddomainobjectsliketexts,images,videos,signals,. . . . Mostoftheseapproachespaid alotofattentiontotheuseofontologiestointerprettheseobjectsand/orprovideclassificationsoftheseinterpretedobjects. Next subsection recallsbasic definitionsof ontologiesand their characteristics.Itgives ourviewofdomainontologies and theircharacteristics withaspecificfocusonsystemengineering.

3.1. Domainmodeling:ontologies 3.1.1. Definition

Gruberdefinesanontologyasanexplicitspecificationofaconceptualization[23].Anotherdefinitionreliesonthenotionof dictionary,where[42]considersadomainontologyasaformalandconsensualdictionnaryofcategoriesandpropertiesofentities ofadomainandtherelationshipsthatholdamongthem.Here,anentityrepresentsanyconceptbelongingtotheconsidered do-main.Thetermdictionary entailstwomajorconcepts.First,itmakesexplicittheexistence,throughaconstructivedefinition or declaration, ofentities in thedomain under considerationand second that any entity orrelationship described inthis

1 _{http://protege.stanford.edu/.} 2 _{http://www.plib.ensma.fr/.}

ontologyisdirectlyreferencable,foranypurposeandfromanycontext,independentlyoftheotherentitiesorrelationships. Reference iscarried by asymbol defining an identifier. This identification symbol may beeither a language-independent identifier, or alanguage-specific set ofwords. However, whatever thissymbol is,and unlikein linguistic dictionary,it di-rectly denotes a domain entity or relationship. Each description of each entity or relationship is formally stated using an ontologymodelinglanguageequippedwithaformalsemantics.Itallowsautomaticreasoningand consistencychecking.

3.1.2. Somefundamentalcharacteristics

A domainontology is anexplicit conceptualizationof domain entities and relationships [23].Ontology definitions will fulfil threefundamentalcriteria[42].

1. Formality. An ontology is a conceptualization expressed within a modelling language. It has an underlying formal semanticsandmayofferreasoning.

Similartomodeling languages,thesemantics ofontology modelinglanguagesisexpressed usingasatisfactionand an entailementrelationships.If anontologyOnt is definedintheontologymodellinglanguage O ,then

– thesatisfactionrelationship (|=O)offers interpretation capabilities.It isusefull to check whetheran instance oran

individual of a given concept of the ontology Ont belongs to the model (set of all its instances) defined by the consideredontology;

– the entailment relationship (⊢O) handles proofs. Entailment expresses the sequence of deductions (sequents) that

leads to a given theorem (expressed as a statement in the ontology modelling language O ) can be deduced from axiomsandtheoremsdefined bytheontologyOnt.

Automaticor semi-automaticreasoning techniquesareassociated to anontologymodelling language O .They support instancechecking(|=O)andreasoning (⊢O).Asaconsequence,checkingpropertiesexpressedovertheontology-defined

concepts and individuals, becomes possible, thanks to the associated theory, either by automatic or semi-automatic reasoningtechniques.

2. Consensuality. Agreementontheconceptualizationdefinedbyanontologyneedstobereachedforalargecommunity ofusers.Thiscommunityisnotrestrictedtousersortodevelopersofaspecificapplication:itgathersallthepotential users and developers of other applications related to the conceptualized domain. Consequently, an ontology will be sharedbyseveralapplications and designmodels.For example,ISO 13584-compliant(PLIB) [31,30]product ontologies aredefinedaccordingtoaformalstandardizationprocess.TheyarepublishedasISOand/orIECinternationalstandards. Thiscriterionexcludesconceptualmodelsdefined foraspecificapplication.

3. Capabilitytobereferenced. Asstated intheprevious definition,each conceptdefined in anontology isassociated to anidentifierprovidedto allowapplicationsto referthisconcept fromanyenvironment. Moreover,thisconceptcanbe referencedwhateveristheontologymodelset uptodescribethisconcept.

3.2. Ontologymodels

Severalontology modelinglanguagesweredevelopedduringlasttenyears,asfor example,Ontolingua[43]forartificial intelligenceapplications,DAML+OIL[26],RDFS[27]andOWL[28,29]forWebapplications,andPLIB[30,31]forengineering applications.

In [44], authorshave identified some relevant characteristics associated toontology modelinglanguages. These charac-teristics havebeenextendedwithnewonesinordertohandlethesystemengineeringaspects.

• Wordsandconcepts. Ontologymodels offer thecapability to describewords and concepts.Various relationships are offeredbythese languages:betweenwords, betweenconceptsandbetweenwordsand concepts.Thepresenceofsuch relationshipsleads to two ontologies designprocesses [42]:from wordsto concepts (e.g.semanticweb) orfrom con-ceptstowords(e.g.engineeringcatalogues).

• Strongtyping. Ontology modelinglanguages are equipped with atype system characterizing classes, properties, rela-tionshipsand domainvalues.Accordingtothemodelinglanguage,thistypesystemmaybemoreorless astrongtype system. For example, the PLIB ontology modeling language uses a strong typing system (e.g. unit types are built-in types)whiledescriptionlogicsdonotrequirestrongtyping.Typesareusefulforindexation,andthus forthedefinition ofpersistentframeworkslikesemanticdatabases[45–50]tosorebothontologiesandtheirinstances.

• Algebraicoperators maybeassociatedtothetypesavailableintheontologylanguage.Operators onclasseslikeunion, intersection,etc.areavailableinmostoftheontologymodelinglanguages.Forexample,operatorsonreals,areavailable inthePLIBontologymodel.Theymakeitpossibletoexpresspropertyderivation(e.g.diameterequalstwotimesaray). Thesedefined algebraic operators define abstractdata types and givecomplete definitionof thedata typesdiscussed above.

• Constraintsdescription constructs are offered by the ontology modeling language to define constraints on classes, propertiesoron whole ontology. Inthe engineeringdomain,the moretheconstraintdescriptionlanguage isrich, the moretheexpressed conceptsoftheontologiesarepreciselydescribed.Checkingthese constraintsdepend ontheused constraintsolvingtechniquesassociated totheontologymodelinglanguage.

• CWAvs. OWA. Closed world assumption (CWA) implies that a complete knowledge is known and, if a fact is not a consequence oftheontology model,thenits negationis,while inopen worldassumption (OWA) thisreasoningis no longeravailable.Ingeneral,CWAisusedinsystemengineering,whilesemanticwebconsidersOWA.

• Contextmodeling. Intheengineeringdomain,thecontextinwhichapropertyisdefinedisimportant[51].At the on-tologylevel,thedomainofacontextdependentpropertyisnotonlyitsclass,butitisalsoacontextdescription(usually aclass). Forexample, thedefinitionof thelifetime(property)of atyre(class) dependson theaverage temperatureof use(contextofuse). NotethatPLIBoffersbuilt-inconstructsforsuchproperties.

• Inheritanceandinstantiation. Classesmay belinkedbysingleormultipleinheritancerelationships. Inheritancehelps to factorize objects with the same properties, it also contributes to the definition of the subsumption relationship. Instancesofaclassrepresent theindividuals,and anindividualmaybelongtoasingleclass(mono-instantiation)orto severalclasses(multi-instantiation).Ontologymodelinglanguagesofferdifferentformsofinheritanceand instantiation. For example OWL supports multiple inheritance and multi-instantiation while PLIB supports single inheritance and mono-instantiation.

• Reasoning. Inontologyengineering,reasoningessentiallyconcernssubsumption(e.g.tolink ontologiesclasses incase ofintegration), classmembershipchecking (e.g.formigrationofinstancesfromoneontologyclasstoanotherone)and classification(e.g.to buildnewclasshierarchiesaccordingto somecriteria).Otherlogical aspectsofreasoningconcern thespecific properties ofthe underlying logiclike symmetry, reflexivity,equivalence etc are useful forknowledge in-ference.Differentreasoningtechniques and tools havebeen defined.Onecancite[34–37],runningin centralmemory havebeen defined.Like for model checking, these approaches mayface the problemsof memory saturation orspace exploration.Other reasoningtechniquemorecommonlyusedbyformalmethodshavealso beensetuptohandleproof ofpropertiesinontologies.Theseapproaches,whichproved scalable,useoftheoremprovers likeCOQ with[52,53]or Event-B[24]toinferontologies properties.

• Exchangeformats. All the ontology modeling languages offer exchange formats based on the XML language. When expressedinthisexchangeformat,classes andtheirinstancescanbeinterpretedintheindifferentcontextsofuse.

3.3. Ontologiesinengineering

Our work does not address semanticweb applications. In our study of design models, we have been involved in the engineeringarea.Wefocuson domainontologieswhere thewhole knowledgeonthedomainisdescribed intheprovided ontology. Dueto the system engineeringtargeted application domain,we useontologies conforming to thePLIB ontology model [54–57]. This ontology model advocates the useof strong typing with arich typesystem (similarto the one of a programming language more specific types like units), propertyderivation with algebraic operators corresponding to the defined types,firstorderlogicand settheoryasaconstraintlanguage,CWA andcontextdependentproperties.

Like in usual engineering practices and unlike OWL, additional models may be added to a technical object descrip-tion. Indeed, asetof differentfunctionalmodels, eachonerepresenting aparticulardiscipline-specificrepresentation (e.g., safety,realtime,energyconsumption,geometryprocurement,simulation,etc.)canbeassociated toagiventechnicalobject described withinthePLIBontologymodel.

Finally, anumber ofdomainontologies based on thismodelalready exist. Examples aretheISO 13584 and ISO 15926 (e.g. mechanical fasteners, measure instruments, cutting tools)and IEC 61360(e.g. electroniccomponents, process instru-ments)seriesofontologiesdevelopedwithininternationalstandardizationorganizations(e.g.ISO,IEC)ornationalones(e.g. JEMIMA,3 _CNIS4_{)that coverprogressivelyallthetechnicaldomain.}

3.4. Ontologiesandchanges

Ontologies may evolve in time. The continuousontologicalprinciple requires that any evolution does not contradict the previousontologyversion.Severalevolutionscenariosfulfillingthisprinciplehavebeen definedlike

– extendingbysubsumptionaconcept byanotherone.Anewconceptissubsumedbyanexistingone(inheritance), – definingnewequivalentconcepts where newconceptsdeclaredasequivalenttoanotheroneisintroduced, – introducingnewproperties byaddingnewattributestogivenconcepts,

– . . .

Afterevolutions,newontologyversionsareissued. Theversioning mechanismsdefineaversionmanagementprotocolwith acurrent referenceversionand oldversionsarepreserved.Specificconfigurationattributesareassociatedtoeachontology concept in order to record the different evolutions. Finally, suppression of concepts is not allowed in order to preserve the reference to ontologies concepts mechanism (annotation for example). In case of suppression, obsolete concepts are introducedand theassociatedconfigurationmanagementattributeisset totheobsoletevalue.

3 _{JapanElectricMeasuringInstrumentsManufacturersAssociation.} 4 _{ChineseInstituteforStandardization.}

4. Systemmodelingversusdomainmodeling

Theprevioussectionhas presentedanoverviewofthefundamentalcharacteristics ofontologiesand ontologymodeling languages. We have shown that different ontology languages can be set up to describe domain ontologies. Application domains, semantics, constraints expressiveness, reasoning capabilities, assumption on the universe of discourse etc. are some of the characteristics to be assessed before designing a domain ontology. Ontologies are used to describe domain models.Thissectionisdevotedtothecomparisonofdomainmodelsanddesign models.

4.1. Systemmodeling:designmodels

Designmodelsaddressthedefinitionofmodelsofsystemstoberealized.Theyaredescribedwithinmodelinglanguages and theycorrespondtoabstractionsoftheconsideredsystem.Semanticsofthemodelinglanguageisgivenbyasatisfaction relationship (|=M) checking if a model is satisfiable and an entailment relationship (⊢M) defining a proof system where

properties can be proved from axioms, theorems and proof rules applications). Some examples of such formal modeling languagesare[8,58–61].Obviously,othermodellinglanguagesareavailable,andwecanadd allthelanguagesderived from theUMLmodellinglanguage[62,63].

Variousanalyses,propertieschecking, modelsmanipulations,etc.areperformedon suchmodelsdependingonthe pro-videdmodelinglanguage,itssemantics, itsassociatedverificationprocedure andontheabstractionlevelwheremodelsare defined. As aconsequence, different models of a samesystem may beproduced along thedesign process. These models mayrecordabstractorconcretelevels(top–downorbottom–updesign approaches)ortheymay,atagivendesignstep, de-scribe differentmodelscorrespondingtodifferentviewsofathesystemunderdesign. Thus,severalheterogeneousmodels expressedwithdifferentmodelinglanguagesareproduced.Thisheterogeneitymayleadtoambiguitiesintheinterpretation ofthesystemcharacteristicsand/orbehaviorineachproduceddesignmodel.

4.2. Domainmodeling:ontologiesversussystemmodeling:designmodels

In[42],authorshaveproposedacomparisonofontologiesanddesignmodels.Modelinglanguagesarerequiredtoexpress both ontologies and design models. These modeling languages offer different verification techniques according to their semantics. Assuch,bothontologiesand designmodelsaremodels.Theydefineaconceptualizationofapartofthesubject concernedbythroughmodelsdefinedwithinmodelinglanguages.So,onemayguessthatfromthispointofview,ontologies anddesignmodelsaresimilar,sincetheyshareacommongoal,namelymodeling.However,ifweconsiderthethreecriteria identified aboveinsection 3.1.2,wecanidentifysome significantdifferences.

Designmodelsareequippedwithformalsemantics Inthissense, theyfit theformality criterion. Theyaregrounded on rigor-ouslydefined semanticsandassociated topropertyverification systemswhichusereasoningandlogical theories.However, accordingto [42], design modelsareclosely relatedto thesystemunderdesign. In otherwords, adesign model prescribes and enforces whichsystemcharacteristicswill beavailableinthemodeltoperformaspecificanalysisortreatment.Indeed, as mentioned above, a single system may have different design models (safety oriented model, real time model, energy consumptionmodelandanarchitecturalmodelforexample).Fromthisobservation,wecanconcludethattheconsensuality

criterionisnot(orpartly)fulfilledbydesignmodels.Finally, ifweconsider namingprocessesindesign modelsanddesign modeling languages, there is no rule requiring a single identificationof entities (variables, constants, states, events, etc.) manipulated by design models. A typical example of such a naming rule relates to the description of point coordinates, whereapairoffloats(v1,v2) maybeinterpreteddifferentlyinamodelreferringtopolarcoordinates(r,θ )andinanother

model referring to cartesian coordinates (x,y). Engineering abounds insuch examples. The entityidentificationis unique in the context of the considered design model, but it may beused with a different semantics in another model. So, the

capabilitytobereferenced criterionisnotfulfilledbydesignmodels.

Previously identified differences do not constitute a drawback. The simultaneous use of both ontologies and design modelsinanengineeringcontext,strengthensthemodelingprocesses.

The subjectofthispaperisnot tooppose ontologies and designmodels. Thepreviouslyidentified differencesadvocate for the use of both ontologies and design models in a single framework. Ontologies carry relevant information usually handled implicitlyindesign models.For example,thepreviouslydefined pointscan bedefined eitherinanabsolute,orin arelative coordinatesystem.When ontologies anddesign modelsareintegrated(orcomposed),domainpropertiesmaybe explicitly usedinthedesign modelsand intheassociatedsystemdevelopmentprocesses.

4.3. Ontologiesandannotations

One of the main use of ontologies is annotation. Let us consider a set of entities available in a given corpus. These entities may bewords or sentences in a document, images or videos, entities of a design model, etc. By annotation, we denote thelinkthat mayexistbetweenanontologyconcept(class, instance,property,etc.)andanentityoftheconsidered corpus.Theannotationprocessconsistsindefiningandrunningasetofrulesleadingtotheproductionofannotations.This processmaybecompletelyautomated,semi-automaticwithuservalidationorcompletelyinteractive.Automaticannotation

provedpowerfulintheareaofthesemanticwebandnaturallanguageprocessingwheretheentitiesofthecorpusarewords appearing intexts.Severaltools(orannotators)havebeen developedforvariousontologiesanddifferentnatural languages [64,65,38,39,66].Otherapproachestoannotateimages andmulti-mediadocumentshavealsobeendeveloped [67].

Intheareaofsystemdesign,theobjectiveofmodelannotationistoincreasemodelinteroperability.Consensualdomain ontologies are shared bydifferent systemmodels correspondingto different engineeringviews.Annotations allowthe de-signer to link differententities of differentsystem models to ontologyconcepts. Reasoningatthe ontology level makesit possible to check some domain properties. Model annotations have been produced using semi-automatic and/or interac-tive approaches.Automatic annotation is notrecommended in such application domains.For example, model annotations havebeen producedforproductlifemanagement(PLM)modelsin[68],forpetroleumengineeringmodelsin[69,70]orfor aircraft system modelingin[71]. Allthese examplesused controlledannotation techniquesbeing eithersemi-automaticor interactive.

4.4. Semanticmismatch

Theseparationofconcernsprinciplefollowedwhendesigningsystemsthatexploitdomainmodelsexpressedby ontolo-gies may lead to semantic heterogeneity. Indeed, when system design models and ontologies aremodeled with different modelinglanguages,thiscanleadtodifferentsemanticinterpretations.Moreover,thecapabilitytoverifytherelevant prop-ertiescorrespondingtosystemrequirementdependsontheproofsystemassociatedtothemodelinglanguage.Thisproblem can be expressed in a more formalway as follows.When anontology modeling language (with its own satisfaction |=O

and entailment⊢O relationships)isusedtodescribethedomainmodelassociatedtothedesignofagivensystemwhichis

expressed ina design modelinglanguage(with itsown satisfaction|=M andentailment ⊢M relationships) thereisaneed

of semanticalignment due to different semantics of these two modeling languages. This topic isoutside thescope of this paper.

5. Embeddingontologiesintosystemdesignformalmodels

5.1. Whatiftheontologyandthedesignmodelwerelinked?

Usually,designmodelsdonothandle,inanexplicitmanner,theknowledgeoftheapplicationdomainorcontextwhere modelsaredesigned.Therefore,someusefulpropertiesavailableinthedomainknowledgearenotconsideredbythedesign models,more,thesepropertiescouldbeviolatedbythedesignmodel.Forinstance,thenosegearvelocitysystemmeasures the velocity on the ground ofan aircraft. To do so, it uses a 16-bitregister variable to storethe numberof cycles ofthe wheels(tocomputethedistancetravelledandtheaircraftspeed).Therefore,itisimportanttoknow the maximallengthof the runway on earthin orderto check that thechosen size oftheregister variable(16-bit) iscorrect. In termsof system engineering, thedetermined size ofthisregister comes fromflight mechanics,more preciselyfrom thelift oftheaircraft. Without anexplicitdefinitionofthisknowledge,engineerswouldnotbeabletosetupsuchavaluefortheregistersize.

So, linkingknowledge domains,expressed byontologies,withthedesign models strengthensthedesigned modelsand support moreverifications, sincethepropertiesexpressed intheontologies willbepartofthedesignedmodels.Moreover, thankstothecapabilitytoreferencedomainentities,itbecomespossibletoavoidambiguous definitionsofthesameentity intwodifferentmodels.

Modelannotationisthemechanismclassicallysetuptolinkdomainontologieswithdesignmodels.Itconsistsin defin-ingspecificrelationshipsto relateontologyconceptswithmodelsentities.Theannotation mechanismextendstheonethat has beendefinedbythesemanticwebcommunitytoannotateweb pages[64,65,38,39,66]orimages[67].

5.2. Modelinglanguages

Different modeling languages may be used for building both ontologies, design models and annotation models. These languagesmayhavethesamesemanticsand verificationprocedure,but thesemaybedifferent.Twosituationsoccur.First, asmentionedinsection4.4,thesemanticsandtheverificationprocedurecanbeexpressedinasinglemodelinglanguage.In thiscase,thereisnosemanticmismatchandbothdesignmodels,ontologiesand annotationcanbeformalizedinthesame modeling language. The second option considers different semantics of both modeling languages. This case is out of the scope ofthispaper, itrequires semanticalignment. Severalapproachesto alignsemantics haveproposed inthe literature, theyarebasedonthedefinitionofinstitutionsasmodels[72–74].

5.3. Ourapproach

Ourapproachadvocates theexploitationofdomainknowledge,carriedoutbyontologies,indesign models.Wepropose a stepwise methodology, composed of four steps, to establish a formal link between these two models. The approach is basedonthedefinitionofanannotation mechanismthatrepresentsthislink.Thedefinitionofthismechanismdependson theusedmodelinglanguagesforbothontologies anddesignmodels.Fig. 1showstheoverallschemaoftheapproach.

Fig. 1. A four steps methodology for integrating domain knowledge and design models.

1. Formalizationofdomainknowledge. Domain informationareformalizedinanontologymodelinglanguage.Concepts, entities, relationships, constraints, rules, etc. are explicitly defined. The result is a formal ontology expressed in the chosenontologymodelinglanguage.Thesemanticsofthislanguageand theassociatedverificationtechniques areused toestablishpropertiesoftheontology. Theexpressivepowerofthislanguagehas animpacton thedefinedontologies (e.g.differentconstraintdescriptionlanguagesmaybeused).Finally,theontologyshallbedefinedindependentlyofany contextofuse.Itmayalsobebuiltfromalready existingontologies(e.g.standardontologies).

2. Definitionofdesignmodels. Any formal modeling language is used to describe design models. Within this formal modelinglanguage, usersdefineand formalizespecific designmodels correspondingto agiven specification.Different analysesallowedbythemodelinglanguageanditsassociatedverificationtechniquemaybeperformedonthedesigned model.

3. Annotationofdesignmodelbyreferencestoontologies. Using specificmechanisms availableinthe formalmodeling language, annotation of design models are explicitly described. Annotation consists of defining specific relationships between design models entities and ontology concepts. Different relationships are available, they have their specific properties. For example, the Is_a relationshipcan be used to assert that a given design model entity isan ontology concept (annotation by subsumption). Annotation is made explicit in the design models thanks to the use of these relationships.

4. Expressionandverificationofproperties. Oncedesignmodels areannotated bydomainontologies,theproof context ofthedesign modelsisenrichedbythedomainpropertiesexpressed intheontology.Itbecomespossible tocheck on theonesidetheconsistenceofthedesignmodelsalreadyestablishedbeforeannotation (theymaybenolongercorrect afterannotation)andontheotherhandotherpropertiesthat emergedafter annotation.

At the endofthis process, anew design model enrichedwith new informationof thedomain knowledgeis obtained. This modelmakesanexplicitrepresentationofdomainconceptsand propertiesborrowedfromtheontologythankstothe annotation.

5.4. Somecomments

1. Itisimportantthatthespecifiedandusedontologies aredefinedinaconsensualmannerbythestakeholdersinvolved inthesystemunderdesign.Moreover,theyshouldhaverelationshipswiththedomainofthedesignmodel.

2. Steps 1and 2of theprevious methodologyareindependent. Theymay berun inparallel. Ontologies maybedefined priortothedesignmodelortheymaypreexist.

3. Inthesemanticweb area,lotofeffortsaredevotedtothedefinitionofautomaticannotationmechanisms[64,65,38,39, 66,67].Theretheannotatedmodelsaredocumentsingeneralandontologiesusuallyexploittermsratherthanconcepts. Thedefinitionoftheannotations mayberealizedeitherbymanual,semi-automaticorautomaticprocesses[68–71,24]. Inthispaper,we areconcernedwithformal designmodels targeting systemdesign. Therefore,ourapproach relieson aninteractiveannotationperformedbythedesigner.

4. Thesituationwhereadesignmodelisanextension (byspecializationoftheontologyorthedesignmodelissubsumed by the ontology) of the defined ontology may occur. This situation is ideal, it occurs when the design model is an extension of the domainontology. In thiscase, reasoning by subsumptionis possible. However, other situations may

occur.Forexampleincasethespecificdesignmodeliscrosstoseveraldomainontologies(i.e.multi-domainmodel)and usesitsownconcepts,suchaspecializationisnotstraightforward. Morecomplex mappings(e.g.algebraicexpressions, orotherstructuralrelationships)arerequired.Thereasoningcapabilities offeredbysubsumptionmaybelostandmore complexreasoningmechanisms maybeneeded.

5.5. Associatedtheory

Following the previously defined stepwise methodology to make explicit domain knowledge expressed by ontologies in design models, we propose a general formal setting in which sucha methodology can bedeployed for specific formal methods.

Aswedonotaddressheterogeneoussemantics,therestofthispaperconsidersthatthesamesatisfaction|=and entail-ment⊢relationshipsareusedforbothoftheontologymodelinglanguageand forthedesignmodelinglanguage.

1. FormalizationofDomainKnowledge. Anontologyisdescribedwithanontologymodelinglanguage.Itdefinesaxioms

AO1,. . . ,AOm andproofdeductionrulesfromwhichpropertiesi.e.theorems TO1,. . . ,TOn maybededuced.

• Ontologies shall besound(healthiness of theontology).This means that thereexists amodel MO that satisfiesthe

axioms oftheontology.Wewrite MO|=AOi for1≤i≤m

• Each theorem can be deduced from the axioms and the other theorems. We write AO1,. . . ,AOm ⊢ TO1 and

AO1,. . . ,AOm,TO1, . . . ,TOi−1⊢TOi forall2≤i≤n

2. Definitionofdesignmodels. Thestudiedsystemsaredescribed inthechosenmodelinglanguage.Ifthemodeling lan-guagesupportspropertiesverification,thenpropertiesmaybeexpressedandchecked.Axioms A1, . . . ,Ak andtheorems T1, . . . ,Tldescribingthemodelpropertiesaredefined.

• Describedsystemmodelsshallbesound(healthinessofthedesignmodel).Thismeansthatthereexistsamodel MD

that satisfiestheaxiomsdefined forthesystemmodel.Wewrite MD|=Ai for1≤i≤k

• Each theorem expressing properties on thedesign model can be deduced from the axioms and the other demon-stratedtheorems.Wewrite A1,. . . ,Ak⊢T1and A1,. . . ,Am,T1, . . . ,Ti−1⊢Ti forall2≤i≤l

3. Annotationofdesignmodelbyreferencestoontologies. Annotation consists in integrating domain knowledge ex-pressedbyontologies inthedesignmodel.

• Integratedaxiomsdefineasoundannotation(healthinessoftheannotatedmodel).ThereexistsamodelM satisfying

theaxiomsofboththeontologyandthedesign model.WewriteM|=A1 ∧ . . . ∧ Ak∧ AO1 ∧ . . . ∧ AOm.

4. Expressionandverificationofproperties. Theproperties T1,. . . ,Tl shallbere-proved again oncethemodel hasbeen

enrichedbyontologies.Moreover,newemergingproperties P1,. . . ,Pt maybeinferred fromtheannotatedmodel.

• The properties of the design model before annotation need to be re-proved again. Indeed, the ontology may have brought relevant information that falsify 0 or more properties. We write A1,. . . ,Ak,AO1,. . . ,AOm ⊢T1 and

A1,. . . ,Ak,AO1,. . . ,AOm,TO1, . . . ,TOn,T1, . . . ,Ti−1⊢Ti forall2≤i≤l

• When domainknowledgedescribedbyontologiesisembeddedinthedesignmodels,newproperties P1, . . . ,Pt may

arise.Theyshouldbeproved.Wewrite: A1,. . . ,Am,AO1,. . . ,AOm,⊢Pi forall0≤i≤t

Remark.Asmentionedinsection4.4,wehaveassumedthatthesamedeductionlogic(with⊢and|=)isassociatedtoboth theontologyandthedesignmodels.If thisisnotthecase,alignmentofthesemanticsoftheontologies andofthemodels shouldbeperformed.Thisisoutofthescopeofthispaper.

5.6. Twocases

As statedpreviously, thechosen modelinglanguageforontologies,design modelsandannotations impactsboththe de-scriptionofthedifferentinvolvedmodelentitiesandthesupportedpropertychecking.Weconsiderthat domainontologies aredescribed withinset theoryand firstorderlogic.Weshowthatsuchdomainontologiesareusefultostrengthenformal system developmentandverificationintheengineeringdomain.

In this paper, theapproach is deployed in two different situations with the sameontology model for bothsituations. It modelsconceptswithattributesand inheritance.Weshow twoapplications casesofthemethodologydefined aboveon two formalmethodsrepresentativeofoneofthetwowell-known familiesofformalmethods

1. Thefirst caseismodel-checking in section 6, itdescribes how state transitionsystemscan beannotatedbyontologies andcheckedwithinmodelcheckers,and

2. The second case, in section 7, addresses the annotation of formal models expressed with the refinement and proof formalmethodEvent-B.

Notethatwestudythecaseoftwoillustrativeformalmodelinglanguagesandanontologymodelinglanguagewhichare allexpressedwithsettheoryandfirstorderlogic.Thus,thesemanticmismatchisnolonger presentinbothcases.

6. Ontologies,behavioralmodelsandmodel-checking

The first case related to design models annotation addressed by this paper concerns behavioral models and model checking. By behavior, we target process based models like web services, business processes, distributed systems, human computer interfaces,etc.Ingeneral, thebehaviorofsuchsystemsiscaptured bymodelsexpressedwithlabelledtransition systems(lts)[9].

Thissectionstudiesthecaseoflabelledsystemsasunderlyingdesignmodelsforthestudiedsystems.Severalproperties canbecheckedonsuchsystems.Here,wefocusonthespecificpropertyweakbi-simulation[1,75]. Thispropertyisuseful tocompare twolts.Itestablishesbehavioralequivalenceoftwolabelledtransitionsystems.

6.1. Designmodels:thecaseoflts asdesignmodelsandbi-simulation

Thissectiongivesthebasicdefinitionofthebi-simulationrelationship.

6.1.1. Labelledtransitionsystems

ALabeledTransitionSysteml is astructurel= hS,s0E,−→i where S isa setof states,s0∈S denotesaninitial state,

E isasetoflabelsand−→ ⊆S×E×S isatransitionrelationbetweenstates.

When specifying systems by labelled transition systems, labels denote actions and the specific label

τ

∈E is used to denote internalactionsi.e.non-observable actions.

6.1.2. Thebi-simulationrelationship

The notion ofbi-simulation wasinitially defined byMilner [1] tocompare processes (called observational equivalence). This relation defines equivalence on states oflts. Dependingon the kindof considered actions(internal

τ

orobservable), two kindsofobservationalequivalenceexist:strongbi-simulation whichconsidersobservableactionsand weakbi-simulation

whichconsiders boththeobservableand internal

τ

(stuttering)actions[1,75].

Weconsiderthedefinitionofbi-simulationfortwodifferentlts.Letlts= hS,s0E,−→iandlts′= hS′,s′₀E,−→′ibetwo

transitionsystemswiththesamesetoflabels E and S∩S′_=∅.

Definition1.Strongbi-simulation. Strongbi-simulation relation ∼⊆S×S′_{,isabi-simulationequivalence defined onstates.}

For agiven actione,atransition−→e andtwostates pi and qi,wesaythat (pi,qi)∈∼if

∀

p_i

−→

e p_j

∈−→: ∃

q_i

−→

e ′q_j

∈−→

′

∧(

p_j

,

q_j

) ∈∼

∀

qi e

−→

′qj

∈−→

′

: ∃

pi e

−→

pj

∈−→ ∧(

qj

,

pj

) ∈∼

By extension of this definition, two lts are strongly bi-similar (noted ≃lts) if their initial states are bi-similar i.e.

(s0,s′₀)∈∼(astrongbi-simulationincludinginitialstatescanbebuilt).

Definition2.Weakbi-simulation. Weakbi-simulationrelationshipnoted≈ ⊆S×S′_{,isabi-simulationequivalencedefined}

on states.For agiven actione,atransition−→e andtwostates pi andqi,wesaythat (pi,qi)∈≈if

∀

pi e

−→

pj

∈−→ ∃

qi τ⋆_.e.τ⋆

−→

′ qj

∈−→

′

∧(

pj

,

qj

) ∈≈

∀

pi τ

−→

pj

∈−→ ∃

qi

−→

τ ⋆ qj

∈−→

′

∧ (

pj

,

qj

) ∈≈

∀

q_i

−→

e ′q_j

∈−→

′

∃

p_iτ

−→

⋆.e.τ⋆p_j

∈−→ ∧(

q_j

,

p_j

) ∈≈

∀

qi τ

−→

′qj

∈−→

′

∃

pi τ⋆

−→

pj

∈−→ ∧(

qj

,

pj

) ∈≈

Byextensiontwo lts areweaklybi-similar(noted≅lts)iftheirinitialstatesareweaklybi-similari.e. (s0,s′0)∈≈ (aweak

bi-simulation includinginitialstatescanbebuilt).

6.2. Someremarks

One of the maininterests of bi-simulation is the capabilityto compare the behaviorof two lts. From theengineering pointofview,applicationsofsucharelationcanbethesubstitutionofanlts byanotheroneiftheyarebi-similarsincethey have thesameobservedbehavior. Applicationsofthisresultsinsystem engineeringarenumerous,wecanciteadaptation, maintenance,substitution,redundancy,self-healing,etc.

Bi-simulationrelationships are defined ona singleset oflabels and compare transitions withthe samelabels.So, in a specificdesigncontextwhereallthelabels(actions)aresharedbythedesignmodel,lts comparisoncanbeperformedusing thisdefinition.Several formalverificationtechniques offerthecapabilitytocheck whether twolts arebi-similar(examples areproofand refinementwith[10]andmodelcheckingwith[11]).

6.3. Ontology:anontologyoflabels

When consideringdifferent applicationdomains, itappearsthat several behavioralsystemsmay bedefined indifferent contexts.Asaconsequence,asinglesystembehaviormaybedescribedbydifferentbehavioralmodelsassociatedtodifferent labeled transition systems.In this case,comparing thebehavior ofsuch lts using bi-simulation as defined above may fail due totheappearanceofdifferentsetsoflabelsindifferentlts.

One solution could bethe definition relations between sets labels independently of any context of use. In particular, these relation mayexpress equivalence orsubsumptionson labels. Anontologyof setsof labelsis wellsuitedto describe suchrelations.

We introduce a relation, Ŵ on pairs of labels, used to rewrite different labels. Let lts= hS,s0 E, −→i and lts′ =

hS′_,s′

0E′,−→′i be two transition systems such that S∩S′=∅, E*E′ and E′*E. Let A be another set of labels

dif-ferentfromtheonesofE∪E′_{,inotherwords A∩ (E∪E}′_)=∅

Definition3.Bi-directionalrelationonlabels. Ŵ ⊆E−E′_×E′_{−E isarelationonlabelsoftwolabelledtransitionsystems}

defined by

∀

α

∈

E

−

E′

, ∃ β ∈

E′

−

E such that

(

α

, β) ∈ Ŵ

∀ β ∈

E′

−

E

, ∃

α

∈

E

−

E′such that

(

α

, β) ∈ Ŵ

Theleftand rightprojectionfunctions Proj_l and Proj_r areassociated toŴ.

Informally, Ŵ links labels belonging to the set of labels that are not in E∩E′_{. Note that this relation belongs to the}

defined domainontology.

6.4. Annotation:establishingcorrespondencesbetweenlabelsoflts

Theannotationoflts asdesignmodelsconsistsinexploitingtherelationshiponlabelsborrowedfromthedefineddomain ontologies of labels.Thisontology expressesequivalence orsubsumptionoflabels. Theannotation process consistsfirst in rewritingthedifferentlabelsinordertoobtainlts withthesamelabelsandsecondcheckbi-simulationofthetransformed

lts.

6.4.1. Rewritinglabels

Torewritelabels,wedefinearewritingfunctiononlabelsbelongingtosetsoflabelsoftheontology.

Definition4.Rewritingfunctiononlabels.Let 8:E×E′_{−→ (A∪E∪E}′_{∪ {}

_τ

_{})beafunctiononlabelsoftwosetsoflabels}

intheontology.8isdefined by

∀ (

α

, β) ∈ Ŵ ∃

γ

∈

A such that

8(

α

, β) =

γ

Thedefinitionoftherewritingfunctionentailsfourdifferentapplications.

1. Substitution.If ∃e∈A such that8(a,b)=e thenlabelsa andb arereplacedbyanewlabele in A.

2. Rightreplacement.If∃b ∈ E′ _{suchthat8(a,b)=a thenlabelb∈E}′ _{isreplacedbyalabela∈E.}

3. Leftreplacement.If∃a ∈ E suchthat 8(a,b)=b thenlabela∈E isreplacedbyalabelb∈E′_.

4. Hiding.8(a,b)=

τ

denotesthecaseofapairoflabelsthatshouldbehiddenonbothlabelledtransitionsystemsafter rewriting.

Remark.Whenanontologyisused, substitutionmeans thatasubsumingconcept isavailableandleft(resp.right) replace-mentmeansthatleft(resp.right)labelissubsumedbytheright(resp.left)one.Hidingmeansthatthelabelisnotrelevant forcheckedproperty.IfŴisempty,thennocomparisonispossible.

6.4.2. Relationalbi-simulation

Oncetherewritingfunctionisappliedandifsucceeded,itbecomespossibletodescribetheprocesstotransformtwolts

intotwonewlts withthesamesetoflabels.

Definition5.Transforminglabelledtransitionsystems.lts= hS,s0E,−→iand lts′= hS′,s′₀E,−→′i arerespectively

rewrit-ten to lts⊤= hS⊤_,s⊤ 0 E⊤, −→⊤i and lts⊤ ′ = hS⊤′_,s⊤′ 0 E⊤ ′

, −→⊤′_{i according to the label relation Ŵ and to the rewriting}

functiononlabels8asfollows. – S⊤_{=S and S}⊤′

=S′ _{i.e.samesetsofstates.}

– s⊤₀ =s0 ands⊤

′

– E⊤_{= (E−Proj}

l(Ŵ))∪A∪ {

τ

}and E⊤

′

= (E′_−Proj

r(Ŵ))∪A∪ {

τ

}setsoflabelsenrichedwiththerewrittenlabelsthanks

tothe8rewritingfunction.

– transitionrelationsareredefinedonthenewlabels−→⊤⊆S⊤_×E⊤_×S⊤_{and −→}⊤′

⊆S⊤′ ×E⊤′ ×S⊤′ where

−→

⊤

= {

s

−→

e t

∈−→| ∀

e′

∈

E′

. (

e

,

e′

) /

∈ Ŵ} − {

s

−→

e t

∈−→| ∀

e′

∈

E′

. (

e

,

e′

) ∈ Ŵ}

∪ {

s

−→

a t

| ∃(

e

,

e′

) ∈ Ŵ ∧ 8(

e

,

e′

) =

a

}

−→

⊤′

= {

s′

−→

e′ t′

∈−→

′

| ∀

e

∈

E

. (

e

,

e′

) /

∈ Ŵ} − {

s′ e′

−→

′t′

∈−→

′

| ∀

e

∈

E

. (

e

,

e′

) ∈ Ŵ}

∪ {

s′ a

−→

′t

| ∃(

e

,

e′

) ∈ Ŵ ∧ 8(

e

,

e′

) =

a

}

6.5. Verification:propertyverificationonannotatedlts

Thelts⊤ andlts⊤′ obtainedafterannotation arelabelledtransitionsystemswiththesameset oflabels,since E⊤_=E⊤′_.

Itbecomespossibletocomparethemwithclassicalbi-simulationrelationship.

Thisprocess leads tothedefinitionof therelationalbi-simulationthat exploitsarelation definedout ofthecontext of useofthedesignmodels.

Definition6.Relationalweakbi-simulationrelationship onlts.Let hlts,lts′,Ŵ,8ibeastructurewhere – lts andlts′ aretwolabelledtransitionsystemssuchthat S∩S′_{=∅, E*E}′ _{and E}′_*E,

– Ŵ ⊆E×E′ _{isarelationshipon labelsaccordingtoDefinition 3,}

– 8isalabelrewritingfunctionaccordingtoDefinition 4. Then, ≅Ŵ,8

lts ⊆LTS×LTS is relationalweak bi-simulation relationship on labelledtransition systems if there exists a weak

bi-simulation relationshiponlabelledtransitionsystemsbetweenthetransformedlts.Wewrite

(

lts

,

lts′

) ∈≅

Ŵ,8_lts

⇐⇒ (

lts⊤

,

lts⊤′

) ∈≅

lts

Itbecomespossibletocomparelabelledtransitionsystemswithdifferentsetsoflabels.

6.6. Casestudies

The principleofannotatinglabelled transitionsystemshas been usedin twocasestudies: formalverification ofplastic interfacesandofwebservicescomposition.

6.6.1. Plasticuserinterfaces

Plastic userinterfacesare humancomputer interfacesthat may beadapted to thecontext of use.With theavailability of differentinteraction modes(mouse,voice, touch screens,etc.)many user interfacesto interact withagiven application canbeenvisioned.For twouserinterfacesUI1 andUI2 ofasingleapplication, twolts namelylts1 andlts2 canbemodeled.

Their labelscorrespondtothedifferentinteractionmodes.

According toan ontologyOntUI definingarelation ŴOntUI oninteraction modesand arewriting function8OntUI,wesay that UI1 andUI2 satisfyplasticityproperty[76,77]if

lts1

≅

Ŵ_OntUI,8_OntUI

lts lts2

Note that if Ŵ =∅∧E16=E2 the plasticity property does not hold. We have experimented this approach with labelled transitionsystemsexpressedwithintheLOTOSprocess algebraand thebi-simulationcheckedwiththeCADP[11]toolbox.

6.6.2. Webservicescomposition

Web servicescompositionmayalsogetbenefits fromourmethodology.If weconsider twocomposite servicessw1 and

sw2 expressed inacompositionlanguagelike BPEL[78],itispossible tomodel sw1 and sw2 withtwolabelledtransitions

systemslts1and lts2withatomicservicesaslabels[79–81].AssuminganontologyofservicesOntSW [2–4]isavailable,then

onecanidentifyservicesthatachievethesamegoal.Forexample,thesendingbyemail andthesendingbysurfacemail atomic

services or thesendingelectronicinvoice and sendingpaperinvoice atomic services oftheontology OntSW are consideredas equivalentsincetheyachieve similarfunctions.

Then, one cancheck if acomposite service sw1 can besubstitutedby anothercomposite service sw2 in caseoffailure

or loss of quality of service etc. So, accordingto an ontology OntSW defining a relation ŴOntSW on atomic services and a rewriting function8OntSW,wesaythatsw1 canbesubstitutedbysw2[4]if

lts1

≅

Ŵ_OntSW,8_OntSW

lts lts2

Note thatifŴ =∅∧E16=E2 the substitutionpropertydoesnothold.

These two examples show how the benefits of making explicit domain knowledge in order to improve the quality of design models.

7. Ontologies,behavioralmodelsandrefinementandproof-basedformalmethods

Thissectionpresentsthecaseofexploitationofontologiesbyaproofand refinementbasedformalmethod.

7.1. ThecaseofEvent-B

7.1.1. Designmodels:theEvent-Bmodelinglanguage

Event-B is a formal modeling language for expressing state-based models of reactive systems. It is supportedby two proof-assistant-basedenvironments,namelyRodin[10]andAtelier-B[82].Thetwoenvironmentscanbeusedfordeveloping thesamemodels;bothenvironmentsusethesamekernelproof moduleandany Event-Bmodeldevelopedinoneofthese environmentscanbeexportedintheotherenvironment.TheRodinplatformisanopentoolsetplatform,whichisused for developing, analysing,validatingand experimentingtheEvent-Bmethodology.Atelier-Bisfreelydistributedbutremainsan industrial tool. Moreover, Atelier-Bhas first providedfunctionalities forbuilding classical Bmodels, which are modelsfor developingonlysoftware.TheconstructionofanEvent-Bmodelisbasedonconceptslikesets,constants,axioms,theorems, variables, invariants, events; these syntactic constructions are organised in two kinds of structures, namely contexts and machines. Fig. 2 contains the general form of each possible component. Contexts express axiomatic static properties of the modelsand machines express dynamicbehavioral properties (state-basedfeatures) of themodels,which may contain variables,invariants,theoremsandevents.AmachineM sees acontext D.

Contexts maycontaincarriersets, constants,axioms, and theorems.Axioms describeproperties ofcarriersetsand con-stants. Theorems derive properties that can be proved from the axioms. Proof obligations associated with contexts are straightforward:thestatedtheoremsmustbeproved,whichfollowfromthepredefinedaxiomsandtheorems.Additionally, acontextC canbeseenbyamachineM indirectlyifthemachineM explicitlyseesacontextD whichisanextensionofthe context C .Variables v representsthestateofthemachine M.Variables,likeconstants, correspondtosimplemathematical objects:sets, binaryrelations,functions,numbers,etcetera.Theyareconstrainedbyinvariants I(v).Invariantsaresupposed toholdwhenevervariablevalueschange.

Amachineis organizingeventsmodifying thestatevariablesand it uses staticinformation defined inacontext. These basicstructuremechanismsareextendedbytherefinementmechanismwhichprovidesamechanismforrelatinganabstract model and a concrete model by adding new events or by adding new variables. This mechanism allows us to develop gradually Event-B models and to validate eachdecision step usingthe proof tools. The refinement relationship shouldbe expressed as follows: amodel M is refined by amodel P , when P is simulating M.The final concrete model is close to thebehaviorofrealsystemthatisexecutingeventsusingrealsourcecode.Wegivedetailsnowonthedefinitionofevents, refinementandguidelinesfordevelopingcomplex systemmodels.

TheconsistencyofacontextoramachineinEvent-Bisachievedbyprovingproofobligations generatedbytools[82,10] and sound withrespectto theresultsof theprevioussection. If theseproof obligations aredischarged, thenthestructure (contextormachine)iscorrectatleastwithrespecttothetyping.

AnEvent-Bmodelorganizesasetofevents statinghowstate-variablesmaybemodified,whenobservingtheoccurrence of one ofthem.Intuitively, anevent is triggeredwhen guard(thetriggering condition of anevent) evaluatesto true. Due to non-determinism, if a given guard evaluates to true does not mean that the corresponding event is triggered. Indeed, several eventsmayhaveguards evaluatingtotrueandonly oneofthemistriggered(interleavingofevents).

Each event can be defined by a relationship before–after denoted as BA(x,x′_{). An event is characterized by its guard}

whichisdeterminedatthemodelingphaseanditcanonlybetriggerediftheguardistrue.Wewilldetailproofobligations generated for a given event e and explain the meaning of these proof obligations. For each event e, proof obligations are generated and discharged by theenvironment Rodin [10]. Thesetwo concepts allowsus to illustrate therelationship betweenontologies andformalmodels andwhatmaybethegainofontologiesintheformalmodelingprocess.Themodeling process deals with various languages, as seen by considering the triptych of Bjørner [16–18,83]: D,S −→ R. Here, the domain D deals with properties, axioms, sets, constants, functions, relations, and theories and it is written as a context enrichedbyontologicalinformation.Thesystem modelS expressesamodelorarefinement-basedchainofmodelsofthe system. Finally, Rexpresses requirementsforthesystem tobedesigned. ConsideringtheEvent-B modeling language,we notice that thelanguagecan expresssafety properties, whichare eitherinvariants ortheorems in amachinecorresponding tothesystem.

Acontext(seeFig. 2)providesthedefinitionofthesets,constants, axiomsforsetsandconstants,and theoremsthat can bederivedfromtheaxiomsofthecontextD.ThecontextADisapreviouscontextthathasalreadybeendefined,and itis extendedtothecurrentcontext.Acontextisvalidatedwhensets S1,. . . ,Sn,constants C1,. . . ,Cm,and axiomsax1,. . . ,axp

arewellformedandwhenalltheoremsth1,. . . ,thq areproved.

A context clearly states the static properties of the (system) model under construction. The extends construct enables re-usebyextendingapreviouslydefinedcontext.

Theproof processisbasedonthemanagementofsequents, withanassociated environmentforproofcalledŴ(D).The proof environmentincludesaxioms, properties,andtheorems alreadyproved.Anenvironmentisinitiallyprovided,butthe intentionistoaddnewtheorems.Thismeansthatweintendtoprovethefollowingpropertiesinthesequentcalculusstyle: