$EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE 4ITOS 3ARIDAKIS  6AL©RIE )SSARNY ).2)!)2)3! #AMPUS DE "EAULIEU  2ENNES #©DEX &RANCE !BSTRACT 4HE CONSTRUCTION OF DEPENDABLE SOFTWARE SYSTEMS IS RECOGNIZED AS A COMPLEX TASK THE SYSTEM DEVELOPER HAS TO ADDRESS THE USAGE OF FAULT TOLERANCE TECHNIQUES IN ADDITION TO THE DESIGN OF THE FUNCTIONAL ASPECTS THAT ARE SPECIFIC TO THE SYSTEM 4HIS PAPER PROPOSES A FRAMEWORK AIMED AT EASING THE DEVELOPMENT OF DEPENDABLE SYSTEMS BY PROVIDING SOFTWARE DESIGNERS WITH A REPOSITORY OF DEPENDABLE SOFTWARE ARCHITECTURES ! DEPENDABLE SOFTWARE ARCHITECTURE SHOWS HOW TO INTEGRATE A FAULT TOLERANCE TECHNIQUE WITH A GIVEN SYSTEM SO AS TO MAKE THE SYSTEM DEPENDABLE &URTHERMORE THE DEPENDABILITY BEHAVIORS OF ARCHITECTURES ARE FORMALLY SPECIFIED WHICH ALLOWS TO UNAMBIGUOUSLY INTERPRETING THE VARIOUS FAULT TOLERANCE TECHNIQUES AS WELL AS TO ORGANIZE THE REPOSITORY OF CORRESPONDING ARCHITECTURES INTO A REFINEMENT BASED LATTICE STRUCTURE +EY WORDS $EPENDABILITY FORMAL SPECIFICATION SOFTWARE ARCHITECTURE SOFTWARE REUSE SPECIFICATION REFINEMENT  ).42/$5#4)/. -AKING A SYSTEM DEPENDABLE IS RECOGNIZED AS A COMPLEX TASK )N ADDITION TO THE TREATMENT OF FUNCTIONAL ASPECTS THAT ARE SYSTEM SPECIFIC THE SYSTEM S DESIGNER HAS TO COPE WITH THE INTEGRATION OF THE FAULT TOLERANT MECHANISMS THAT SATISFY THE SYSTEM S DEPENDABILITY REQUIREMENTS (OWEVER THE FIELD OF DEPENDABILITY HAS REACHED A SUFFICIENT LEVEL OF MATURITY TO CAPTURE ITS VARIOUS RAMIFICATIONS )N PARTICULAR THERE EXIST A SIGNIFICANT NUMBER OF FAULT TOLERANT MECHANISMS TO HANDLE VARIOUS DEPENDABILITY NEEDS OVER DIFFERENT SYSTEM PLATFORMS 4HUS THERE IS AN A PRIORI KNOWLEDGE OF THE MECHANISMS THAT ARE ELIGIBLE TO MAKE A SYSTEM DEPENDABLE WITH RESPECT TO THE SYSTEM S   4ITOS 3ARIDAKIS  6AL©RIE )SSARNY DEPENDABILITY REQUIREMENTS AND UNDERLYING PLATFORM &URTHERMORE THE UNDERSTANDING OF FAULT TOLERANCE MECHANISMS AND ASSOCIATED ABSTRACTIONS ENABLES A SEPARATION OF CONCERNS IN SYSTEM DESIGN BY ADDRESSING INDEPENDENTLY THE DESIGN REGARDING FUNCTIONAL AND DEPENDABILITY ASPECTS )N THAT CONTEXT WE PROPOSE A FRAMEWORK FOR MAKING A SYSTEM DEPENDABLE THROUGH THE REUSE OF APPROPRIATE FAULT TOLERANCE ABSTRACTIONS /UR WORK BUILDS ON RESULTS OF THE SOFTWARE ARCHITECTURE FIELD 0ERRY AND 7OLF  3HAW AND 'ARLAN   ! SYSTEM S SOFTWARE ARCHITECTURE ABSTRACTLY DESCRIBES THE SYSTEM S GROSS ORGANIZATION IN TERMS OF COMPONENTS IE UNITS OF COMPUTATION AND CONNECTORS IE UNITS OF INTERACTION  4HIS ALLOWS THE PRACTICAL USE OF FORMAL METHODS TO DEFINE THE BEHAVIORS OF COMPONENTS AND CONNECTORS AND TO CARRY OUT COMPLEMENTARY SYSTEM ANALYSES /UR FRAMEWORK FOR THE CONSTRUCTION OF DEPENDABLE SYSTEMS CONSISTS OF CHARACTERIZING DEPENDABLE SOFTWARE ARCHITECTURES THAT ARE GENERIC WITH RESPECT TO THE BASE FUNCTIONAL ARCHITECTURAL ELEMENTS IE FUNCTIONAL COMPONENTS AND CONNECTORS AMONG THEM  4HE DEPENDABILITY BEHAVIORS OF THE ARCHITECTURES ARE FURTHER DEFINED FORMALLY WHICH ENABLES THEIR UNAMBIGUOUS INTERPRETATION AS WELL AS TO ORGANIZE THE SET OF DEPENDABLE ARCHITECTURES ACCORDING TO A REFINEMENT RELATION OVER THEIR BEHAVIOR 0RACTICALLY THE DEVELOPER IS PROVIDED WITH A REPOSITORY OF DEPENDABLE ARCHITECTURAL PATTERNS FROM WHICH HE MAY SELECT THE ONE THAT MEETS THE DEPENDABILITY REQUIREMENTS OF HIS SYSTEM 5LTIMATELY THE FAULT TOLERANCE CONSTITUENTS OF A DEPENDABLE ARCHITECTURE MAY CORRESPOND TO IMPLEMENTED MECHANISMS 3UCH MECHANISMS CAN BE DIRECTLY INTEGRATED WITH THE SYSTEM S FUNCTIONAL STRUCTURE ACCORDING TO THE STRUCTURE SHOWN BY THE DEPENDABLE ARCHITECTURE 4HIS PAPER IS ORGANIZED AS FOLLOWS 3ECTION  DETAILS OUR APPROACH TO THE FORMAL SPECIFICATION OF DEPENDABILITY BEHAVIORS 3ECTION  INTRODUCES OUR FRAMEWORK FOR MAKING SYSTEMS DEPENDABLE PRESENTING A REPOSITORY OF DEPENDABLE SOFTWARE ARCHITECTURES &INALLY WE CONCLUDE IN 3ECTION  SUMMARIZING OUR CONTRIBUTION AND COMPARING IT WITH RELATED WORK  &/2-!, 30%#)&)#!4)/. /& $%0%.$!"),)49 "%(!6)/2 4O BE PRACTICALLY BENEFICIAL FOR SOFTWARE DEVELOPMENT A FORMAL FRAMEWORK SHOULD SATISFY TWO CONDITIONS I IT SHOULD BE EASY TO UNDERSTAND AND USE AND II IT SHOULD BE EXPRESSIVE ENOUGH TO CAPTURE ALL OR AT LEAST A BIG MAJORITY OF THE TARGETED PROPERTIES IE PROPERTIES RELATING TO DEPENDABILITY IN OUR CASE  "OTH THESE CONDITIONS ARE SATISFIED BY AN $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  EXTENSION OF PREDICATE LOGIC WITH THE PRECEDENCE RELATION ,AMPORT  BINARY OPERATOR k < { SPECIFYING A PARTIAL ORDER IN WHICH PREDICATES ARE VERIFIED "ASED ON THE PRECEDENCE RELATION WE DEFINE THE RELATIONS EVENTUALLY UNARY OPERATOR k ◊ { AND IN THE PAST UNARY OPERATOR k ∇ { WHICH DENOTE THAT A PREDICATE WILL BE VERIFIED IN THE FUTURE OR WAS VERIFIED IN THE PAST 4HE EXTENDED PREDICATE LOGIC PROVIDES COMPREHENSIBLE AND EASY TO EMPLOY MEANS FOR COMBINING THE CONSTRAINTS ON SYSTEM STATES THAT SHOULD BE REACHED AFTER A FAILURE WITH THE PARTIAL ORDER OF ACTIONS THAT SHOULD BE PERFORMED TO REACH THESE STATES .OTICE THAT THE USE OF TEMPORAL LOGIC RELATIONS IS NOT INDISPENSABLE FOR MODELING THE TEMPORAL PRECEDENCE OF THE PREDICATE )NDEED MEANS HAVE BEEN INVENTED LIKE HISTORY LISTS WHICH ARE EMPLOYED BY A NUMBER OF APPROACHES EG SEE #HRYSANTHIS AND 2AMAMRITHAM  AND 3TOLLER AND 3CHNEIDER  IN ORDER TO AVOID TEMPORAL RELATIONS FOR ORDERING THE OCCURRENCES OF EVENTS IN A SYSTEM AND TO REMAIN PURELY FIRST ORDER LOGIC (OWEVER WE USE THEM BECAUSE WE BELIEVE THAT THEY RENDER THE FORMULAS MORE LEGIBLE 4HE FORMAL FRAMEWORK WE USE IS PRESENTED HEREAFTER FOLLOWED BY OUR APPROACH TO THE SPECIFICATION OF SYSTEM BEHAVIORS WITH RESPECT TO DEPENDABILITY INTRODUCING THE SPECIFICATION OF DEPENDABILITY PROPERTIES AND A REFINEMENT RELATION OVER THEM  &ORMAL FRAMEWORK ! SYSTEM IS A SET OF VARIABLES WHICH CAN BE ASSIGNED DIFFERENT VALUES ACCORDING TO THE SYSTEM SPECIFICATIONS ! STATE OF THE SYSTEM IS A MAPPING OF VARIABLES TO VALUES WHERE THE VALUES OF SOME VARIABLES CAN BE UNDEFINED 7HEN THE VALUES OF ONE OR MORE VARIABLES LAY OUTSIDE THE RANGE DEFINED IN SYSTEM S SPECIFICATIONS A FAILURE IS SAID TO OCCUR !N EXECUTION OF A SYSTEM IS A PARTIALLY ORDERED SET OF SYSTEM STATES WHERE ONE STATE IN THE SET IS DISTINGUISHED AS BEING THE INITIAL STATE IE THE STATE PRECEDING ALL OTHER STATES IN THE SET !N OBJECT OF THE SYSTEM IS AN ENTITY HAVING SOME STATE (ENCE A SYSTEM CAN BE SEEN AS A SET OF OBJECTS !N ACTION IS A STATE TRANSITION WHICH CAN BE CAUSED BY SOME INTERNAL OBJECT COMPUTATIONS OR BY SOME )/ OPERATION !CTIONS ARE ASSOCIATED TO OBJECTS AND WE ASSUME DETERMINISTIC ACTIONS IE GIVEN THE SPECIFICATIONS OF AN OBJECT AN OBJECT STATE AND AN ACTION ON THAT STATE THE RESULTING STATE AFTER PERFORMING THE ACTION IS UNIQUELY DEFINED (OWEVER WE DO NOT CONSTRAIN THE CHOICE OF THE NEXT ACTION TO BE PERFORMED WHICH CAN BE A RANDOM CHOICE AMONG DIFFERENT ALTERNATIVES (ENCE ALTHOUGH ACTIONS ARE DETERMINISTIC THE EXECUTION OF AN OBJECT AND CONSEQUENTLY THE EXECUTION OF THE ENTIRE SYSTEM ARE NON DETERMINISTIC )N  4HE TERM OBJECT SIGNIFIES A LOGICAL ENTITY AND NOT ENTITIES SPECIFIC TO PROGRAMMING LANGUAGES EG # OBJECTS   4ITOS 3ARIDAKIS  6AL©RIE )SSARNY THIS CONTEXT AN EVENT IS THE EXECUTION OF SOME ACTIONS OR THE REACH OF SOME STATE )N THE REMAINDER OF THIS DOCUMENT WE USE THE FOLLOWING NOTATIONS • • • • • /BJECTS ARE DENOTED BY THE FIRST FIVE LOWER CASE 'REEK LETTERS PRIMED OR FOLLOWED BY A SUBSCRIPT VALUE EG α βI ETC  σ PRIMED OR FOLLOWED BY A SUBSCRIPT VALUE DENOTES A SYSTEM STATE &OR OBJECT STATES WE PREFIX THE OBJECT NAME EG ασ  7E NEGLECT THE OBJECT NAME WHEN IT IS OBVIOUS IN A GIVEN CONTEXT Σ DENOTES SYSTEM SPECIFICATIONS &OR OBJECT SPECIFICATIONS WE PREFIX THE OBJECT NAME EG αΣ  8 DENOTES A SYSTEM EXECUTION WHICH IS A PARTIALLY ORDER SET OF SYSTEM STATES 7HEN FOLLOWED BY THE SUPERSCRIPT # IT DENOTES A FAILURE FREE EXECUTION !CTIONS ARE WRITTEN IN LOWER CASE ITALICS FOLLOWED BY A LIST OF ARGUMENTS IN PARENTHESES 4O DISTINGUISH AMONG ACTIONS OF DIFFERENT OBJECTS WE PREFIX THE OBJECT NAME TO THE ACTION EG αIMPORTβ DATA  7E NEGLECT THE OBJECT NAME WHEN IT IS OBVIOUS IN A GIVEN CONTEXT 4HE STRUCTURAL ELEMENTS OF THE SYSTEM MODEL PRESENTED ABOVE DO NOT SUFFICE TO DESCRIBE THE PROPERTIES OF A SPECIFIC SYSTEM IE THE RELATIONS AMONG CONSTITUENT OBJECTS THEIR INTERACTIONS THEIR INVARIANTS AND THEIR CONSTRAINTS &OR THIS A SET OF PREDICATES IS NEEDED TO CAPTURE THE ESSENTIAL PROPERTIES OF SYSTEM ENTITIES 4HIS SET OF PREDICATES SHOULD BE MINIMAL IN ORDER TO BE EASY TO USE AND UNDERSTAND 7E PRESENT BELOW A SET OF PREDICATES THAT CAPTURE THE FACT THAT THE SYSTEM IS IN A GIVEN STATE AND THE EXECUTION OF )/ ACTIONS .OTICE THAT THIS SET OF PREDICATES IS NOT UNIQUE ANOTHER SET OF PREDICATES RICHER OR MORE FRUGAL CAN BE CHOSEN IF IT FACILITATES THE SYSTEM PROGRAMMER S REASONING EG ADDITIONAL PREDICATES THAT CAN BE DEFINED ARE INIT EXIT BEGIN COMMIT AND ABORT TO DESCRIBE THE ACTIONS RELATED TO OBJECT INITIALIZATION AND TERMINATION OR THE ACTIONS RELATED TO TRANSACTIONAL PROPERTIES  )N THE REMAINDER OF THIS DOCUMENT WE USE THE FOLLOWING PREDICATES • 4HE PREDICATE EXPRESSING THAT A SYSTEM IS IN STATE σ IS INTRODUCED BY THE UNARY OPERATOR ; = IE ;σ= IS TRUE WHEN THE SYSTEM IS IN STATE σ  3IMILARLY ;ασ= IS VERIFIED WHEN OBJECT α IS IN STATE σ  • 4HE PREDICATE EXPORT EXPRESSING THE )/ ACTION PERFORMED BY AN OBJECT α WHEN IT SENDS TO AN OBJECT β THE DATA D 4HE DATA D SENT ARE A FUNCTION OF SOME α S STATE PRECEDING THE )/ ACTION AND IF SOME β S STATE IS A FUNCTION OF DATA D THE EXPORT ACTION PRECEDES THIS STATE -ORE FORMALLY THE PREDICATE IS DEFINED AS EXPORTα β D ≡ ∃ασ  ∇;ασ= ∧ D  Fασ ∧ βσ  GD ⇒ ◊;βσ= $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE •  4HE PREDICATE IMPORT EXPRESSING THE )/ ACTION PERFORMED BY AN OBJECT β WHEN IT RECEIVES THE DATA D SENT BY OBJECT α 4HE EXPORT OF DATA D FROM α TO β PRECEDED AND SOME STATE OF β AFTER RECEIVING D IS A FUNCTION OF THE RECEIVED DATA -ORE FORMALLY THE PREDICATE IS DEFINED AS IMPORTα β D ≡ ∇EXPORTα β D ∧ ∃βσ  βσ  GD ∧ ◊;βσ= .OTICE THAT THE PREDICATES EXPORT AND IMPORT αEXPORTβ D AND βIMPORTα D ACTIONS RESPECTIVELY  CORRESPOND TO THE $EPENDABILITY PROPERTIES 'IVEN THE ABOVE FORMAL FRAMEWORK WE ARE ABLE TO DEFINE DEPENDABILITY PROPERTIES WHICH SERVE TO CHARACTERIZE DEPENDABILITY BEHAVIORS OF SOFTWARE ARCHITECTURES ,ET US POINT OUT HERE THAT THE DEPENDABILITY PROPERTIES INTRODUCED IN THE FOLLOWING REFLECT MORE THE AUTHORS PERSPECTIVE ON THE ISSUE RATHER THAN A WIDELY ACKNOWLEDGED CHARACTERIZATION !LTERNATIVE SPECIFICATIONS OF DEPENDABILITY BEHAVIORS CAN BE ENVISIONED )N THE SAME WAY THERE MAY EXIST ALTERNATIVE INTERPRETATIONS FOR THE TERMS WE USE TO QUALIFY THE DEPENDABILITY PROPERTIES (ERE WE BASE OUR WORK ON THE FAULT TOLERANCE PERSPECTIVE INTRODUCED BY ,APRIE ,APRIE   4HE IMPORTANT POINT WE WANT TO MAKE WITH RESPECT TO OUR APPROACH TO THE SPECIFICATION OF DEPENDABILITY PROPERTIES IS THAT IT ENABLES US TO CHARACTERIZE THE VARIOUS BEHAVIORS OF A SYSTEM IN THE PRESENCE OF FAILURE WHICH ARE ATTAINABLE USING EXISTING FAULT TOLERANCE TECHNIQUES 4HE SET OF THESE BEHAVIORS MAY FURTHER BE EXPANDED AS NEW FAULT TOLERANCE TECHNIQUES EMERGE )N THE REMAINDER WE PRESENT THE SPECIFICATION OF SOME REPRESENTATIVE DEPENDABILITY PROPERTIES SO AS TO GIVE THE READER THE INTUITION OF HOW DEPENDABILITY PROPERTIES ARE CHARACTERIZED IN GENERAL "ASICALLY DEPENDABILITY PROPERTIES FALL INTO TWO GROUPS I !BSTRACT PROPERTIES SPECIFIED IN TERMS OF SYSTEM STATES WHICH ARE DEFINED INDEPENDENTLY OF ANY FAULT TOLERANCE TECHNIQUE 4HEY SERVE TO CHARACTERIZE THE DEPENDABILITY BEHAVIOR OF AN OVERALL ARCHITECTURE WHEN THIS BEHAVIOR IS TOO ABSTRACT TO ASSOCIATE A SPECIFIC FAULT TOLERANCE TECHNIQUE WITH IT II #ONCRETE PROPERTIES SPECIFIED IN TERMS OF SYSTEM ACTIONS WHOSE DEFINITION IS CLOSELY RELATED TO SOME FAULT TOLERANCE TECHNIQUE 4HEY SERVE TO CHARACTERIZE THE DEPENDABILITY BEHAVIORS ASSOCIATED TO ARCHITECTURAL ELEMENTS WITH RESPECT TO A GIVEN FAULT TOLERANCE TECHNIQUE  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY ,ET US FIRST GIVE ABSTRACT PROPERTIES DEFINED AT THE STATE LEVEL 4HE MOST ABSTRACT DEPENDABILITY PROPERTY SIMPLY QUALIFIED AS $EPENDABILITY ENSURES THAT A SYSTEM MAKES PROGRESS DESPITE THE OCCURRENCE OF FAILURE 4HE 3AFETY PROPERTY DEFINES THAT AFTER A FAILURE THE SYSTEM SHOULD ENTER AN ERROR FREE STATE WHICH IS SOME SUBSET OF A STATE REACHED BEFORE THE OCCURRENCE OF THE FAILURE 4HE BASIC CHARACTERISTIC OF THIS ABSTRACTION IS THE REMOVAL OF THE FAILURE PRODUCTS 4HE SPECIFICATION OF THE !VAILABILITY PROPERTY INDICATES THAT THE STATE REACHED AFTER A FAILURE IS A STATE CONTAINED IN SOME FAILURE FREE SYSTEM EXECUTION 4HE BASIC CHARACTERISTIC OF THIS ABSTRACTION IS THE REPAIR OF FAILURE EFFECTS !NOTHER SPECIFICATION IS THE 2ELIABILITY PROPERTY WHICH DEFINES THAT THE STATE REACHED AFTER A FAILURE INCLUDES A STATE THAT SHOULD HAVE BEEN REACHED IN THE ABSENCE OF FAILURES 4HE BASIC CHARACTERISTIC OF THIS PROPERTY IS THE TRANSITION TO THE EXPECTED STATE DESPITE THE OCCURRENCE OF FAILURES -ORE SPECIFIC DEPENDABILITY PROPERTIES ARE THE ONES OF $ETECTION AND &MASK WHERE THE FORMER CHARACTERIZES FAILURE DETECTION AND THE LATTER THE SYSTEM CAPABILITY TO MASK THE OCCURRENCE OF FAILURES ,ET FAULTY BE THE PREDICATE EXPRESSING THAT A SYSTEM STATE CONTAINS AN ERRONEOUS MAPPING OF VARIABLES TO VALUES IE FAULTYσ IS TRUE WHEN SOME OF THE VARIABLES OF σ HAVE BEEN ASSIGNED VALUES NOT DEFINED BY SYSTEM S SPECIFICATIONS 3IMILARLY FAULTYασ IS VERIFIED WHEN THE OBJECT STATE ασ CONTAINS AN ERRONEOUS MAPPING FROM VARIABLES TO VALUES 4HE UPPER PART OF 4ABLE  GIVES THE SPECIFICATIONS OF THE AFOREMENTIONED DEPENDABILITY PROPERTIES FOR A SYSTEM 3 4HE PROPERTIES IN THE UPPER PART OF 4ABLE  CHARACTERIZE ONLY THE SYSTEM STATE THAT IS REACHED AFTER A FAILURE OCCURRENCE 4HEY DO NOT MAKE EXPLICIT THE SYSTEM OBJECTS THAT ARE INVOLVED IN FAULT TREATMENT NOR THE NEEDED INTERACTIONS AMONG THEM 4HIS IS CAPTURED BY CONCRETE PROPERTIES DEFINED AT THE ACTION LEVEL &OR INSTANCE THE $ETECTION AND &MASK PROPERTIES MAY BE RESPECTIVELY REVISED INTO THE SPECIFICATION OF $ETECTION/BJ AND &MASK/BJ 4HE SPECIFICATION OF THE FORMER EXPRESSES THE FACT THAT A SYSTEM OBJECT TRANSMITS A MESSAGE TO SOME OTHER OBJECT IN THE SYSTEM AFTER A FAILURE OCCURRED 4HIS MESSAGE CONTAINS THE INFORMATION OF THE OCCURRED FAILURE WHICH IMPLIES THAT THE TRANSMITTING OBJECT CAPTURES THIS KNOWLEDGE IN ITS STATE 3IMILARLY THE SPECIFICATION OF THE LATTER EXPRESSES THE FACT THAT FOR A FAILED OBJECT THERE EXISTS AN EQUIVALENT OBJECT NOT NECESSARILY A DIFFERENT ONE WHICH REACHES A CORRECT STATE THAT FOLLOWS ALL THE FAILED OBJECT S STATES PRECEDING THE FAILURE )N OTHER WORDS THIS MEANS THAT THE STATE THAT WOULD HAVE BEEN REACHED BY A GIVEN OBJECT IN THE ABSENCE OF FAILURES IS EVENTUALLY REACHED EVEN IF A FAILURE OCCURS ON THE OBJECT IN QUESTION 4HE FORMAL EXPRESSIONS THAT DESCRIBE THE AFOREMENTIONED PROPERTIES ARE GIVEN IN THE LOWER PART OF 4ABLE  .OTICE THAT THE INTERACTION EVENTS ARE EXPRESSED BY THE EXPORT AND IMPORT PREDICATES AND THEIR PARAMETERS DEFINE THE EXACT $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  INTERACTION PATTERN BETWEEN THE TWO OBJECTS INDICATED BY THE PREDICATE PARAMETERS /BJECT ε IS USED TO SIGNIFY ANY OBJECT OF THE ENVIRONMENT )N ADDITION THE EQUIVALENCE OF OBJECT SPECIFICATIONS NOTED ≡3 IS DEFINED WITH RESPECT TO THE OBSERVABLE BEHAVIOR OF OBJECTS IE THE SPECIFICATIONS OF TWO OBJECTS ARE EQUIVALENT IF THE SEQUENCES OF IMPORT AND EXPORT ACTIONS PERFORMED BY THE OBJECTS ARE EQUIVALENT 4ABLE  4HE FORMAL SPECIFICATIONS OF SOME DEPENDABILITY PROPERTIES $EPENDABILITY 3 ≡ ;σ= ∧ FAULTYσ 3AFETY3 ≡  ;σ= ∧ FAULTYσ ⇒ ∃ σ ∈ Σ  ;σ= < ;σ= ⇒  ∃ σ σ ∈ Σ  ;σ= < ;σ= ∧ ;σ= < ;σ= ∧ σ ⊆ σ !VAILABILITY3 ≡  ;σ= ∧ FAULTYσ ⇒  ∃ σ ∈ Σ  ;σ= < ;σ= ∧ σ ∈ 8# 2ELIABILITY3 ≡  ;σ= ∧ FAULTYσ ⇒  ∃ σ σ ∈ Σ  ;σ= < ;σ= ∧ σ ∈ 8# ∧ ∀ σP  ;σP= < ;σ= ⇒ ;σP= < ;σ= ∧ σ ⊆ σ $ETECTION3 ≡ ;σ= ∧ FAULTYσ &MASK3 ≡ ∀ σ ∈ Σ   ∃ σF  FAULTYσF ∧ ;σ= < ;σF= ⇒  ∃ σ ∈ Σ  ;σF= < ;σ= ∧ σ ⊆ σ $ETECTION/BJα ≡  ∃ β  ;βσ= ∧ FAULTYβσ ⇒ ;βσ= < EXPORTα ε Fβ FAILED &MASK/BJα ≡ (;ασ= ∧ FAULTYασ ⇒ ∃ β  βΣ ≡S αΣ ∧ ;ασ= < ;βσ= ∧ ¬FAULTYβσ ∧ ∃ασ   ;ασ= < ;ασ= ⇒ ∃ βσ  βσ  ασ ∧ ;βσ= < ;βσ= !S MORE CONCRETE EXAMPLES LET US CONSIDER THE ENFORCEMENT OF DEPENDABILITY FOR AN OBJECT USING A REPLICATION TECHNIQUE !CHIEVING REPLICATION CONSISTS OF REPLICATING AN OBJECT INTO A GROUP OF OBJECTS AND MAKING THE GROUP BEHAVE AS A SINGLE OBJECT FROM THE PERSPECTIVE OF THE GROUP S ENVIRONMENT 4HE BEHAVIOR OF THE OBJECTS GROUP MAY DIFFER DEPENDING ON THE REPLICATION TECHNIQUE IE ACTIVE SEMI ACTIVE PASSIVE THAT IS USED 4HE FORMULAS OF 4ABLE  CHARACTERIZE THE DEPENDABILITY PROPERTIES FOR THE ACTIVE AND PASSIVE REPLICATION TECHNIQUES WHERE IDD UNIQUELY IDENTIFIES THE DATA D AMONG ALL THE DATA EXCHANGED IN THE SYSTEM 4HE ID FUNCTION IS DEFINED SO THAT IDD  IDD IF D AND D ARE EXPORTED BY OBJECTS HAVING EQUIVALENT SPECIFICATIONS AND THE EXPORT ACTIONS CORRESPOND IN THE SEQUENCES OF THE )/ ACTIONS PERFORMED BY THE OBJECTS  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY 4ABLE  &ORMAL SPECIFICATION OF ACTIVE AND PASSIVE REPLICATION !CTIVEα . ≡ ∃ α  α.   '  [α α  α. ] ∧ 2EPLICATION' ∧ &ILTER' ∧ !TOMIC$ELIVERY' 2EPLICATION'  [αI]I. ≡ ∀ αI, αJ ∈ '  αIΣ ≡S αJΣ ∧ ¬FAULTYαIΣ ⇒ FAULTYαJΣ &ILTER'  [αI]I. ≡ ∃ β   αI, αJ ∈ ' ∧ IMPORTαI β DI ∧ IMPORTαJ β DJ ∧ IDDI  IDDJ ⇒ ∃
EXPORTβ ε D ∧ IDD  IDDI  IDDJ !TOMIC$ELIVERY'  [αI]I. ≡ ∃ α ∈ '  IMPORTε α D ⇒ ∀ αI ∈ '  IMPORTε αI D ∧ ∃ α ∈ '  IMPORTε α D < IMPORTε α D ⇒ ∀ αI ∈ '  IMPORTε αI D < IMPORTε αI D 0ASSIVEα ≡ ∃ γ β  2EPLICATION[α β] ∧ 3TABLE3TORAGEα γ ∧ 2ESTOREα β γ 3TABLE3TORAGEα γ ≡ IMPORTα γ F ∧ F  ασ ∧ ;ασ= < EXPORTα γ F ∧ ¬∃ γσ  FAULTYγσ 2ESTOREα β γ ≡ ∃ ασ  ;ασ= < ;ασ= ∧ IMPORTγ β F ∧ F  ασ ∀ ε D  ;ασ= < EXPORTε α D ⇒ IMPORTε β D  ∧ 2EFINEMENT RELATION "ASED ON THE PROPOSED APPROACH TO THE SPECIFICATION OF DEPENDABILITY PROPERTIES WE ARE ABLE TO DEFINE A REFINEMENT RELATION OVER THESE PROPERTIES 4HIS RELATION ALLOWS REFINING AN INITIAL DEPENDABILITY REQUIREMENT INTO MORE CONCRETE DEPENDABILITY PROPERTIES WHICH ULTIMATELY CORRESPOND TO THE BEHAVIOR OF FAULT TOLERANCE MECHANISMS FOR WHICH AN IMPLEMENTATION IS AVAILABLE #ONSIDERING TWO DEPENDABILITY PROPERTIES 03 AND 03 THE LATTER IS A REFINEMENT OF THE FORMER IF 03 Æ 03  &OR ILLUSTRATION &IGURE  DEPICTS THE REFINEMENT RELATION THAT HOLDS OVER THE DEPENDABILITY PROPERTIES INTRODUCED IN THE PREVIOUS SUBSECTION )N THE FIGURE EACH PROPERTY 0 IS REPRESENTED BY A BOX THAT CONTAINS A SET OF BOXES TO DENOTE ALTERNATIVE CORRECT REFINEMENTS OF 0 AND EACH OF THESE SUB BOXES POINTS TOWARDS A SET OF PROPERTIES WHOSE CONJUNCTION IS A CORRECT REFINEMENT OF 0 $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  $EPENDABILITY !VAILABILITY 2ELIABILITY $ETECTION &MASK $ETECTION/BJ &MASK/BJ !CTIVE !T$ELIVERY &ILTER 3AFETY 2EPLICATION 0ASSIVE 3T3TORAGE 2ESTORE &IGURE 3OME REFINEMENTS OF THE $EPENDABILITY PROPERTY  2%0/3)4/29 /& $%0%.$!",% 3/&47!2% !2#()4%#452%3 4HE PROPOSED SPECIFICATION OF DEPENDABILITY PROPERTIES PROVIDES MEANS TO UNAMBIGUOUSLY DESCRIBE THE DEPENDABILITY BEHAVIOR OF AN ARCHITECTURE BUT IT IS OF LIMITED HELP FROM THE STANDPOINT OF EASING THE DEVELOPMENT OF DEPENDABLE SYSTEMS 4O FACILITATE THEIR USE WE PROPOSE TO ATTACH TO EACH DEPENDABILITY PROPERTY THE STRUCTURE IE THE SOFTWARE ARCHITECTURE OF THE  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY CORRESPONDING SYSTEM WITH RESPECT TO THE FAULT TOLERANCE TECHNIQUE THAT IS USED TO ENFORCE THE GIVEN PROPERTY 4HE REFINEMENT RELATION OVER DEPENDABILITY PROPERTIES PROVIDES THE ADEQUATE BASE GROUND TO ORGANIZE THE REPOSITORY OF DEPENDABLE SOFTWARE ARCHITECTURES 4HE REPOSITORY IS ORGANIZED AS A LATTICE STRUCTURE DEFINED ACCORDING TO THE REFINEMENT RELATION AND EACH NODE STORES THE ACQUIRED KNOWLEDGE ABOUT A GIVEN DEPENDABILITY PROPERTY &OR SOME PROPERTY 0 THIS KNOWLEDGE INCLUDES I THE PROPERTY NAME II THE FORMAL SPECIFICATION OF THE DEPENDABILITY PROPERTY III THE SET OF DEPENDABILITY PROPERTIES THROUGH REFERENCES TO ADEQUATE NODES INTO WHICH 0 MAY BE REFINED AND IV THE DEPENDABLE SOFTWARE ARCHITECTURE !0 ASSOCIATED TO 0 4HE REPOSITORY MAY BE DEPICTED IN A WAY SIMILAR TO THE GRAPH GIVEN IN &IGURE  EXCEPT THAT EACH NODE NOW EMBEDS THE DESCRIPTION OF THE DEPENDABLE SOFTWARE ARCHITECTURE CORRESPONDING TO THE PROPERTY DEFINED BY THE NODE 4HE DEPENDABLE ARCHITECTURE CORRESPONDING TO AN ABSTRACT PROPERTY IS A BLACK BOX COMPONENT EMBEDDING THE SYSTEM SINCE THE PROPERTY IS TOO ABSTRACT TO HAVE A FAULT TOLERANCE TECHNIQUE ASSOCIATED TO IT /N THE OTHER HAND THE ARCHITECTURE DEFINED FOR A CONCRETE PROPERTY EXPOSES THE SYSTEM S STRUCTURE WITH RESPECT TO SOME FAULT TOLERANCE TECHNIQUE 4HE FOLLOWING SUBSECTION FURTHER ELABORATES ON THE DESCRIPTION OF DEPENDABLE ARCHITECTURES WHICH AS SHOWN IN 3UBSECTION  MAY BE DERIVED FROM THE SPECIFICATION OF DEPENDABILITY PROPERTIES 3UBSECTIONS  AND  THEN INTRODUCE THE MAIN FUNCTIONS USED FOR THE MANAGEMENT OF THE ARCHITECTURE REPOSITORY THEY RELATE TO THE INTRODUCTION AND RETRIEVAL OF A DEPENDABLE ARCHITECTURE WITH RESPECT TO A GIVEN PROPERTY 0RIOR TO DETAIL THE DESCRIPTION OF DEPENDABLE SOFTWARE ARCHITECTURES LET US NOTICE THAT WE CONCENTRATE HERE ON THE DEFINITION OF ARCHITECTURES WITH RESPECT TO THE FAULT TOLERANCE TECHNIQUE THAT IS USED TO ENFORCE A GIVEN DEPENDABILITY PROPERTY 4HE PROPOSED ARCHITECTURAL DESCRIPTION MAY BE ENRICHED WHEN THERE IS AN AVAILABLE MECHANISM TO IMPLEMENT THE EMBEDDED FAULT TOLERANCE TECHNIQUE &OR INSTANCE THE ARCHITECTURAL DEFINITION COULD THEN INCLUDE THE SPECIFICATION OF THE COMPONENT S INTERACTION PROTOCOL EG USING 7RIGHT !LLEN AND 'ARLAN  AND OF THE COMPONENT S FUNCTIONAL INTERFACE )N THE SAME WAY THE DEFINITION OF CONNECTORS COULD BE INTRODUCED SO AS TO DETAIL THE INTERACTION PROTOCOL USED BY THE MECHANISM )N GENERAL THE DESCRIPTION OF A DEPENDABLE SOFTWARE ARCHITECTURE INCLUDES AT LEAST THE SPECIFICATION OF THE DEPENDABILITY BEHAVIOR OF ITS COMPONENTS AND MAY BE EXTENDED USING THE CAPABILITIES OF EXISTING !$,S !RCHITECTURE $ESCRIPTION ,ANGUAGES  )N PARTICULAR A DEPENDABLE ARCHITECTURE MAY BE DEFINED USING !#-% 'ARLAN ET AL  SO AS TO EXPLOIT DIFFERENT !$,S AND THUS ALLOW VARIOUS ARCHITECTURE ANALYSES $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE   $EPENDABLE SOFTWARE ARCHITECTURE &OR BEING HELPFUL TO SYSTEM DEVELOPERS THE DESCRIPTION OF DEPENDABLE ARCHITECTURES MUST MAKE CLEAR HOW TO COMPOSE A DEPENDABLE SYSTEM FROM A BASE SYSTEM 4HE COMPONENTS OF A DEPENDABLE ARCHITECTURE MAY BE OF EITHER OF THE TWO FOLLOWING KINDS 'ENERIC IN WHICH CASE THE COMPONENT CORRESPONDS TO THE INITIAL SYSTEM THAT IS TO BE MADE DEPENDABLE OR $EPENDABLE IN WHICH CASE THE COMPONENT IS SPECIFICALLY INTRODUCED FOR ENFORCING SOME DEPENDABILITY BEHAVIOR 4HEN GIVEN A SOFTWARE ARCHITECTURE PROVIDING SOME CONCRETE DEPENDABILITY PROPERTY A SYSTEM CAN BE INTEGRATED WITH THE CORRESPONDING FAULT TOLERANCE TECHNIQUE BY MAPPING THE SYSTEM ONTO THE GENERIC COMPONENTS 7E PROPOSE THE FOLLOWING DESCRIPTION FOR DEPENDABLE ARCHITECTURES $EPENDABLE !RCHITECTURE .AME  $EPENDABILITY !RCHITECTURE S DEPENDABILITY PROPERTY #OMPONENTS [#OMPONENT .AME 4YPE#OMP $EPENDABILITY BEHAVIOR ] #ONFIGURATION $ESCRIPTION OF A CONFIGURATION THROUGH BINDINGS AMONG COMPONENTS WHERE THE SPECIFICATIONS OF DEPENDABILITY BEHAVIORS AND PROPERTIES ARE EXPRESSED ACCORDING TO OUR APPROACH DISCUSSED IN THE PREVIOUS SECTION ! DEPENDABILITY BEHAVIOR MAY SIMPLY BE 425% IF THERE IS NO DEPENDABILITY REQUIREMENT ASSOCIATED TO THE ARCHITECTURAL ELEMENT 4HE TYPE OF A COMPONENT IDENTIFIES WHETHER THE COMPONENT IS GENERIC OR DEPENDABLE 7E FURTHER ASSUME THAT EACH ARCHITECTURAL COMPONENT INCLUDING THE ARCHITECTURE ITSELF HAS AN )MPORT AND AN %XPORT PORT &OR ILLUSTRATION 4ABLE  GIVES THE DESCRIPTIONS OF THE ARCHITECTURES ASSOCIATED TO THE 2EPLICATION &ILTER AND !TOMIC$ELIVERY PROPERTIES ,ET US REMARK THAT THE PROPOSED ARCHITECTURAL DESCRIPTIONS EXPOSE ONLY STRUCTURAL INFORMATION REGARDING FAULT TOLERANCE )N PARTICULAR ONLY BINDINGS DEDICATED TO FAULT TOLERANCE ARE CHARACTERIZED #ONSIDERING THE PROPOSED DESCRIPTION OF DEPENDABLE ARCHITECTURES A SYSTEM 3 MAY BE MODIFIED SO AS TO ENFORCE A GIVEN DEPENDABILITY PROPERTY 0 BY MAPPING 3 ONTO EACH GENERIC COMPONENT OF THE ARCHITECTURE ASSOCIATED TO 0 WHILE ENSURING THE DECLARED DEPENDABILITY BEHAVIOR AND PROVIDING AN ADEQUATE IMPLEMENTATION FOR THE DEPENDABILITY SPECIFIC COMPONENTS  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY !LTERNATIVELY THE REPOSITORY OF DEPENDABLE ARCHITECTURES MAY FURTHER BE EXPLOITED TO FIND OUT MORE REFINED ARCHITECTURES WHICH POSSIBLY CORRESPOND TO AVAILABLE FAULT TOLERANCE MECHANISMS 4ABLE  !RCHITECTURAL DESCRIPTIONS ASSOCIATED TO THE 2EPLICATION &ILTER AND !TOMIC$ELIVERY PROPERTIES $EPENDABLE !RCHITECTURE  2EPLICATION  $EPENDABILITY  2EPLICATION'  #OMPONENTS  ';I .=  'ENERIC 2EPLICATION'  #ONFIGURATION  NIL  $EPENDABLE !RCHITECTURE  !TOMIC$ELIVERY  $EPENDABILITY  !TOMIC$ELIVERY'  #OMPONENTS  ';I .= 'ENERIC  I.  IMPORTε 'I D ⇒ ∀J ∈ [1, Ν]  IMPORTε 'J D ∧ IMPORTε 'I D < IMPORTε 'I D ⇒ ∀J ∈ [1, Ν]  IMPORTε 'J D < IMPORTε 'J D  #ONFIGURATION  I .  !TOMIC$ELIVERY)MPORT TO 'I )MPORT $EPENDABLE !RCHITECTURE  &ILTER  $EPENDABILITY  &ILTER'  #OMPONENTS  ';I .=  'ENERIC  425%  &  $EPENDABLE  I J ∈ ; .= ∧ IMPORT'I & D ∧ IMPORT'J & D ∧ IDD  IDD ⇒ ∃
EXPORT& ε D  IDD  IDD  #ONFIGURATION  I .  'I %XPORT TO &)MPORT &%XPORT TO &ILTER%XPORT  $ERIVING DEPENDABLE ARCHITECTURES FROM PROPERTIES SPECIFICATIONS )DEALLY ONE WOULD LIKE TO HAVE A SYSTEMATIC WAY TO DERIVE THE STRUCTURE OF A DEPENDABLE ARCHITECTURE FROM ITS ASSOCIATED FORMAL SPECIFICATION !LTHOUGH NOT DIRECT THE PROPOSED SPECIFICATION OF DEPENDABILITY PROPERTIES EMBEDS THE NEEDED INFORMATION ,ET US GIVE A CLOSE LOOK AT DEPENDABILITY PROPERTIES &ROM A PROPERTY SPECIFICATION WE ARE ABLE TO INFER I THE OBJECTS INVOLVED IN THE ENFORCEMENT OF THE PROPERTY WHICH ARE ALL THE OBJECTS APPEARING IN THE SPECIFICATION II THE OBJECTS BEHAVIORS WITH RESPECT TO DEPENDABILITY WHICH ARE GIVEN BY PART OF THE SPECIFICATION THAT REFERS TO THE OBJECT AND III THE NEEDED INTERACTIONS AMONG OBJECTS WHICH ARE GIVEN BY PART OF THE SPECIFICATION EXPRESSED IN TERMS OF IMPORT AND EXPORT PREDICATES 4O SYSTEMATICALLY INFER THE ABOVE INFORMATION AND HENCE A DEPENDABLE ARCHITECTURE FROM A PROPERTY SPECIFICATION WE PROPOSE TO STRUCTURE THE $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  SPECIFICATION OF DEPENDABILITY PROPERTIES ACCORDINGLY &OR /BJECT4YPE STATING WHETHER THE OBJECT IS GENERIC OR NOT AND PARAMETERS 6AR.AME BEING OF TYPE INTEGER 4ABLE  GIVES THE FORM OF THE SPECIFICATIONS OF A PROPERTY 0 FOLLOWED BY AN ILLUSTRATION OF ITS EMPLOYMENT USING AS AN EXAMPLE THE &ILTER PROPERTY 4ABLE  4HE FORM OF PROPERTY SPECIFICATION AND AN EXAMPLE 0OBJECTS [/BJECT.AME  /BJECT4YPE]  )ND [6AR.AME] OBJECTS  [/BJECT.AME  /BJECT4YPE ] BEHAVIORS  [/BJECT.AME  FORMULA ] CONFIGURATION  FORMULA  ¢ &ILTER'  'ENERIC; .= ¢ OBJECTS  &  $EPENDABLE  BEHAVIORS  I .  'I  425%  &  IMPORT'I & D ∧ IMPORT'J & D ∧ IDD  IDD ⇒ ∃
EXPORT& ε D  IDD  IDD  CONFIGURATION  I .  IMPORT'I & D ∧ EXPORT& ε D  )NTUITIVELY WE CAN INFER FROM THE SPECIFICATION OF THE &ILTER PROPERTY THAT THE CORRESPONDING DEPENDABLE ARCHITECTURE IS MADE OF THE SET OF GENERIC COMPONENTS 'I AND OF THE DEPENDABLE COMPONENT & )N ADDITION THE FORMULA GIVEN IN THE CONFIGURATION PART ENABLES TO DEDUCE INTERACTION AMONG COMPONENTS BASED ON THE SEMANTICS OF THE IMPORT AND EXPORT PREDICATES IMPORTα β D AS WELL AS EXPORTα β D IMPLIES THAT THE %XPORT PORT OF α IS BOUND TO THE )MPORT PORT OF β 7E FURTHER RECALL THAT ε IS USED TO SIGNIFY ANY OBJECT OF THE ENVIRONMENT 4HUS IMPORTα ε D RESP IMPORTε α D SIGNIFIES THAT THE %XPORT RESP )MPORT PORT OF α IS BOUND TO THE ARCHITECTURE S )MPORT RESP %XPORT PORT 4HE SAME APPLIES FOR THE EXPORT PREDICATE 0RECISELY THE INFERENCE OF THE LOGICAL FORMULA AND OF THE SOFTWARE ARCHITECTURE CORRESPONDING TO A GIVEN DEPENDABILITY PROPERTY IS ACHIEVED AS FOLLOWS ,ET 0 BE DEFINED AS 0 OBJECTS /  ≤ I ≤ N  VAR  ¢ OBJECTS  /  ≤ I ≤ N  BEHAVIORS  /  "  ≤ I ≤ M  CONFIGURATION  "  I I I I 4HE CORRESPONDING LOGICAL FORMULA IS EQUIVALENT TO ∃ Ο1, ..., Ο , ∃ / " /  " ∧ ∧ N N IM  I ,ET US REMARK HERE THAT THE PROPOSED SPECIFICATION OF PROPERTIES MAY LEAD TO EXTEND THE ORIGINAL SPECIFICATIONS 4HIS IS EXEMPLIFIED BY THE NEW  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY DEFINITION OF &ILTER WHICH EXTENDS THE ORIGINAL ONE WITH THE FORMULA STATED IN THE CONFIGURATION PART !S ANOTHER EXAMPLE LET US CONSIDER THE !TOMIC$ELIVERY PROPERTY 4HE EMBEDDED FORMULA ∃ α ∈ '  IMPORTε α D ⇒ ∀ α ∈ '  IMPORTε α D RELATES TO THE BEHAVIOR OF THE αS )T ALSO RELATES TO THE ARCHITECTURE S CONFIGURATION ALL THE αS ARE ACCESSIBLE BY OBJECTS OF THE ENVIRONMENT 4HUS THIS FORMULA MUST APPEAR IN TWO PARTS OF THE PROPERTY SPECIFICATION (OWEVER THE FORMULA FOR CONFIGURATION IS SIMPLIFIED INTO ∀ α ∈ '  IMPORTε α D  )N GENERAL WE DO NOT SEE THE REQUIRED MODIFICATION OF PROPERTY SPECIFICATION AS A MAJOR DRAWBACK GIVEN THE RESULTING BENEFIT FOR THE PRODUCTION OF ARCHITECTURAL DESCRIPTIONS ,ET US NOW EXAMINE THE INFERENCE OF THE ARCHITECTURE ASSOCIATED TO 0  )T CONSISTS OF DEFINING THE INTERPRETATION OF EACH CONSTITUENT OF THE PROPERTY SPECIFICATION IN TERMS OF ARCHITECTURAL DESCRIPTION 4HE TREATMENT OF THE OBJECTS AND BEHAVIORS PARTS OF THE SPECIFICATION IS DIRECT EACH OBJECT GIVEN IN THE OBJECTS LISTS TRANSLATES INTO AN ARCHITECTURAL COMPONENT WHOSE TYPE IE DEPENDABLE OR GENERIC IS THE ONE DECLARED IN THE EMBEDDING LIST AND EACH OBJECT BEHAVIOR GIVEN IN BEHAVIORS IS ATTACHED TO THE CORRESPONDING ARCHITECTURAL COMPONENT 4HE INTERPRETATION OF THE CONFIGURATION PART IS LESS DIRECT IT REQUIRES TO INTERPRET EACH ELEMENT OF THE CORRESPONDING LOGICAL FORMULA 0RECISELY A FORMULA DEFINING A CONFIGURATION IS OF THE FORM ∧ 0 WHERE EACH 0 IS EXPRESSED AS EITHER AN IMPORT OR AN EXPORT PREDICATE WHOSE PARAMETERS MAY POSSIBLY BE UNIVERSALLY QUANTIFIED 4HUS EACH 0 IS TRANSLATED INTO BINDINGS AMONG COMPONENTS ACCORDING TO THE PARAMETERS OF THE IMPORT OR EXPORT PREDICATES I I I I I I I I  5PDATING THE REPOSITORY 5PDATING THE ARCHITECTURE REPOSITORY REQUIRES PROVIDING FUNCTIONS FOR THE ADDITION AND REMOVAL OF DEPENDABILITY PROPERTIES (OWEVER SINCE THE TREATMENT OF THE LATTER IS QUITE STRAIGHTFORWARD WE ADDRESS ONLY THE FORMER IN THE FOLLOWING 4HE INTRODUCTION OF A DEPENDABILITY PROPERTY 0 LEADS TO INSERT THE CORRESPONDING NODE . WITHIN THE REPOSITORY ACCORDING TO THE REFINEMENT RELATION OVER PROPERTIES )NSERTING A PROPERTY ,ET US USE THE FOLLOWING NOTATIONS • • • • • 0 DENOTES THE SET OF DEPENDABILITY PROPERTIES . DENOTES THE SET OF NODES OF THE REPOSITORY 0ROP. IS THE FUNCTION THAT RETURNS THE PROPERTY DEFINED BY NODE . !NC.0 DENOTES THE SET OF IMMEDIATE ANCESTOR NODES OF . WITH RESPECT TO THE DEPENDABILITY PROPERTY 0 $EC. DENOTES THE SET OF IMMEDIATE SUCCESSOR NODES OF . $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE •  0/78 DENOTES THE POWER SET OF 8 ,ET US FIRST CONSIDER THE INTRODUCTION OF A PROPERTY 0 REFINING A PROPERTY OF THE REPOSITORY IE 0 NEEDS NOT TO BE CONJUNCTED WITH ANOTHER PROPERTY  &OR INSTANCE IF WE CONSIDER &IGURE  0 MAY BE 2ELIABILITY BUT NOT &MASK WHICH HAS TO BE CONJUNCTED WITH $ETECTION TO BE A REFINEMENT OF AN EXISTING PROPERTY 'IVEN OUR ASSUMPTION THE NODE . FOR PROPERTY 0 MUST BE INTRODUCED WITHIN THE REPOSITORY IN A WAY THAT GUARANTEES THE FOLLOWING TWO CONDITIONS #0 !NC 0  ∀. ∈ !NC 0  0 ⇒ 0ROP. 0 ⇒ 0ROP. ⇒ 0ROP. #0 $EC . ∧ ¬∃ . ∈ . [. ]  . .  ∀ . ∈ $EC   0ROP. ⇒ 0 ∧ ¬∃ . 0ROP. ⇒ 0ROP. ⇒ 0 ∈. . [. ]  ,ET US NOW CONSIDER THE INTRODUCTION OF A PROPERTY 0 THAT REFINES AN EXISTING ONE WHEN CONJUNCTED WITH A SET OF COMPLEMENTARY PROPERTIES 7E REQUIRE ALL THESE PROPERTIES TO BE INSERTED IN THE REPOSITORY AT ONCE USING THE FOLLOWING )NSERT FUNCTION 'IVEN A SET OF PROPERTIES [0 ] TO INSERT AND THE CURRENT NODES OF THE REPOSITORY THE FUNCTION RETURNS THE ANCESTOR NODES THAT ARE COMMON TO ALL THE . S DEFINING THE 0 S WITH RESPECT TO THE PROPERTY ∧ 0 AND THE SET OF SUCCESSOR NODES FOR EACH .  I I IN IN I I I )NSERT  0/70 × 0/7. → 0 × 0/70/70 )NSERT[0 ] I IN .  ∩ !NC ∧ 0 [$EC ] #∧ 0 ∩ !NC ∧ 0 ∀I ∈ [1, N]  #0 $EC IN IN .I JN I J IN .I .I I IN JN J IF AND .I 7HEN A NODE DEFINING A CONCRETE PROPERTY 0 IS CREATED WITHIN THE REPOSITORY THE NODE SHOULD BE COMPLETED WITH ITS CORRESPONDING ARCHITECTURE DESCRIPTION 4HIS IS REALIZED BY INFERRING THE ARCHITECTURE DESCRIPTION FROM THE PROPERTY SPECIFICATION AS DISCUSSED IN THE PREVIOUS SUBSECTION #ORRECT ARCHITECTURE REFINEMENT 5P TO THIS POINT WE HAVE SEEN THAT THE INTRODUCTION OF A PROPERTY WITHIN THE REPOSITORY IS ACHIEVED ACCORDING TO THE REFINEMENT RELATION OVER DEPENDABILITY PROPERTIES ,ET US CONSIDER TWO PROPERTIES 0 AND 0 SUCH THAT 0 REFINES 0  &ROM THE DEVELOPER S STANDPOINT THIS MEANS THAT THE ARCHITECTURE ! ASSOCIATED TO 0 MAY BE SAFELY USED TO ENFORCE PROPERTY 0  ,ET US NOW ASSUME THAT THE ARCHITECTURE ! ASSOCIATED TO 0 WAS ORIGINALLY SELECTED TO MAKE A SYSTEM DEPENDABLE BUT           4ITOS 3ARIDAKIS  6AL©RIE )SSARNY WAS LATER REPLACED BY ! EG SUCH A REPLACEMENT MAY BE DUE TO THE AVAILABILITY OF THE MECHANISMS EMBEDDED BY !  4HE REPLACEMENT OF ! BY ! IS PRACTICAL ONLY IF BOTH ARCHITECTURES HAVE COMPATIBLE STRUCTURES IE ! EXPOSES THE STRUCTURE OF ! S ARCHITECTURAL ELEMENTS )N THIS WAY THE LATER REPLACEMENT OF A DEPENDABLE ARCHITECTURE BY AN ARCHITECTURE ENFORCING A STRONGER PROPERTY DOES NOT IMPACT ON THE DESIGN DECISION MADE SO FAR 4HUS WHEN A PROPERTY 0 REFINES A PROPERTY 0 WE REQUIRE THE ARCHITECTURE ! ASSOCIATED TO 0 TO BE COMPATIBLE WITH THE ARCHITECTURE ! ASSOCIATED TO 0  7E SAY THAT ! IS A CORRECT REFINEMENT OF ! WITH RESPECT TO THEIR ARCHITECTURAL STRUCTURES  ,ET US NOTICE THAT IN THE CASE OF ARCHITECTURES CORRESPONDING TO AVAILABLE MECHANISMS THE REFINEMENT RELATION OVER ARCHITECTURES COULD ADDITIONALLY BE CONSTRAINED ACCORDING TO THE DEFINITION OF -ORICONI ET AL   ,ET US FIRST CONSIDER THE SIMPLEST CASE THAT IS WHEN 0 CORRESPONDS TO A SINGLE NODE THE CORRESPONDING ARCHITECTURE ! IS A CORRECT REFINEMENT OF AN ARCHITECTURE ! IF 0 REFINES THE DEPENDABLE PROPERTY ASSOCIATED TO ! AND IF ! DEFINES A SET OF SUB ARCHITECTURES THAT MAPS ONTO THE COMPONENTS OF !  ,ET US USE THE FOLLOWING NOTATIONS                     • • • • • • •  !N ARCHITECTURE ! IS DEFINED BY THE TRIPLET 0 # "  0 DENOTES THE DEPENDABILITY PROPERTY OF ! # DENOTES THE COMPONENTS OF ! #I #I ∈ # DEFINES THE ARCHITECTURAL BINDINGS "  [#I #I ] AMONG ! S COMPONENTS #OMP  0/7" → 0/7# IS THE FUNCTION THAT RETURNS THE SET OF COMPONENTS EMBEDDED IN A GIVEN SET OF BINDINGS ! DENOTES THE SET OF DEPENDABLE ARCHITECTURES "EH  0 × # → 0 IS THE FUNCTION THAT RETURNS THE DEPENDABLE BEHAVIOR OF A GIVEN COMPONENT BELONGING TO THE SPECIFICATION OF A GIVEN DEPENDABILITY PROPERTY ! ! ! ! ! IN ! ! 7E INTRODUCE THE FOLLOWING FUNCTION TO IDENTIFY WHETHER AN ARCHITECTURE !2 IS A CORRECT REFINEMENT OF AN ARCHITECTURE ! WITH RESPECT TO THE ARCHITECTURES STRUCTURES 2EFINE  ! × ! → "//, 2EFINE! !2  ∃ TOTAL FUNCTION -  # → 0/7"!2 SUCH THAT - IS  TO  AND ONTO AND ∀ # # ∈ #  # ≠ # ∧ #OMP-# ∩ #OMP-#  ∅ AND ∀ # ∈ #  $EPENDABILITY0!2 -# ⇒ "EH0 # ! ! ! ! $EPENDABILITY GIVES THE DEPENDABILITY BEHAVIOR OF THE SUB ARCHITECTURE GIVEN BY A SET OF BINDINGS AMONG COMPONENTS $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  $EPENDABILITY  0 × 0/7" → 0 $EPENDABILITY0 "  ∧ D ⇒ EXPORT# # D #I ∈ #OMP" "EH0 # I ∧ ∧∀ # # ∈ "IMPORT# # ,ET US NOW CONSIDER THE CASE WHERE A CONJUNCTION OF DEPENDABILITY PROPERTIES 0  ≤ I ≤ . IS INTRODUCED AS A REFINEMENT AS AN EXISTING PROPERTY 0 7E MUST DEFINE THE SOFTWARE ARCHITECTURE ! THAT RESULTS FROM THE COMBINATION OF THE SET OF ARCHITECTURES !  ≤ I ≤ . ASSOCIATED TO EACH PROPERTY 0 AND THEN VERIFY THAT ! IS A CORRECT REFINEMENT OF THE ARCHITECTURE ASSOCIATED TO 0 ACCORDING TO THE DEFINITION OF 2EFINE 7E HAVE SEEN THAT THE COMPONENTS OF AN ARCHITECTURE SUBDIVIDE INTO GENERIC AND DEPENDABLE COMPONENTS ,ET US FURTHER RECALL THAT GENERIC COMPONENTS CORRESPOND TO THE SAME FUNCTIONAL COMPONENT THAT IS THE SOFTWARE SYSTEM TO BE MADE DEPENDABLE (ENCEFORTH THE GENERIC COMPONENTS OF THE ! S CORRESPOND TO THE SAME COMPONENTS 4HUS GENERIC COMPONENTS ARE MAPPED ONTO THE SAME COMPONENTS IN THE ARCHITECTURE ! AND THEIR DEPENDABLE BEHAVIOR IS THE CONJUNCTION OF THE BEHAVIOR DECLARED IN EACH OF THE ! S FOR GENERIC COMPONENTS /N THE OTHER HAND THE DEPENDABLE COMPONENTS OF AN ARCHITECTURE ARE IN GENERAL SPECIFIC TO THIS ARCHITECTURE 4HUS THE DEPENDABLE COMPONENTS OF ! ARE THE UNION OF THE DEPENDABLE COMPONENTS OF THE !  (OWEVER THERE ARE TWO CASES WHERE DEPENDABLE COMPONENTS OF DISTINCT ARCHITECTURES MAY HAVE TO BE MERGED INTO A SINGLE COMPONENT /NE OF THESE CASES IS EXEMPLIFIED BY THE ARCHITECTURES USED TO ENFORCE 0ASSIVE REPLICATION THE γ OBJECT IS SHARED BY THE ARCHITECTURES ENFORCING 3TABLE3TORAGE AND 2ESTORE )N GENERAL THIS CASE IS DETECTED THROUGH THE DEFINITION OF THE CONJUNCTION OF PROPERTIES WHICH MAY EXPLICITLY SHARE OBJECTS 4HE OTHER SITUATION WHERE DEPENDABLE COMPONENTS OF DISTINCT ARCHITECTURES MAY BE MERGED IS WHEN THERE IS A RELATION OF LOGICAL IMPLICATION BETWEEN EACH PAIR OF ASSOCIATED DEPENDABLE BEHAVIORS (ERE WE CAN KEEP ONLY THE DEPENDABLE COMPONENT THAT ENFORCE THE STRONGEST DEPENDABILITY BEHAVIOR AMONG THE SET OF COMPONENTS 3O FAR WE HAVE STATED HOW TO INFER THE SET OF GENERIC AND DEPENDABLE COMPONENTS OF AN ARCHITECTURE RESULTING FROM THE COMPOSITION OF SOME ARCHITECTURES 4HE SET OF BINDINGS AMONG THESE COMPONENTS ARE FURTHER THE ONES THAT ARE SPECIFIED FOR THE CORRESPONDING COMPONENTS WITHIN THE ! S I I I I I I I  5SING THE REPOSITORY 5SING THE ARCHITECTURE REPOSITORY FOR THE CONSTRUCTION OF A DEPENDABLE SYSTEM CONSISTS OF RETRIEVING THE SOFTWARE ARCHITECTURE ASSOCIATED TO THE DEPENDABILITY PROPERTY THAT IS TARGETED FOR THE SYSTEM ,ET ⊥ BE THE UNDEFINED NODE 4HE RETRIEVAL FUNCTION IS DEFINED AS 2ETRIEVE  0 → . ∪ ⊥ WITH  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY 2ETRIEVE0  . IF . ∈ . ∧ 0ROP. ⇒ 0 ∧ ¬∃ . ∈ .  0ROP. ⇒ 0ROP. ⇒ 0 OR ⊥ IF ¬∃ . ∈ .  0ROP. ⇒ 0 4HE NODE . RETURNED BY THE 2ETRIEVE FUNCTION ALLOWS TO IDENTIFY ALL THE DEPENDABLE ARCHITECTURES THAT ARE ELIGIBLE TO MAKE A SYSTEM DEPENDABLE WITH RESPECT TO THE GIVEN DEPENDABILITY PROPERTY 4HESE ARCHITECTURES ARE ALL THE ARCHITECTURES DEFINED BY THE NODES OF THE SUB LATTICE WHOSE ROOT IS . 3OME OF THE ELIGIBLE ARCHITECTURES MAY POSSIBLY BE COMBINATIONS OF ARCHITECTURES WHEN PROPERTIES OF THE SUB LATTICE ARE REFINED INTO A CONJUNCTION OF PROPERTIES !RCHITECTURE COMBINATION IS ACHIEVED ACCORDING TO THE APPROACH DISCUSSED IN THE PREVIOUS SUBSECTION 'IVEN ELIGIBLE ARCHITECTURES IT IS UP TO THE SYSTEM DEVELOPER TO SELECT THE ONE THAT IS THE MOST APPROPRIATE FOR THE SYSTEM 3EVERAL FACTORS MAY INFLUENCE THE SELECTION PROCESS !MONG THE MOST PROMINENT FACTORS WE FORESEE THE EXISTENCE OF IMPLEMENTATION FOR ALL OR PART OF THE DEPENDABLE COMPONENTS EMBEDDED IN THE ARCHITECTURES !T THIS TIME THE SELECTION OF THE MOST APPROPRIATE DEPENDABLE ARCHITECTURES AMONG THE SET OF ELIGIBLE ONES IS LEFT UPON THE SYSTEM DEVELOPER 7E ARE CURRENTLY EXAMINING SOLUTIONS TO HELP THE DEVELOPER IN THE SELECTION PROCESS BY COUPLING THE ARCHITECTURE REPOSITORY WITH AN IMPLEMENTATION REPOSITORY 4HE BENEFIT OF OUR PROPOSAL FOR THE CONSTRUCTION OF DEPENDABLE SYSTEMS LIES IN PROVIDING A REPOSITORY OF DEPENDABLE ARCHITECTURES WHOSE BEHAVIORS ARE PRECISELY CHARACTERIZED USING TEMPORAL FIRST ORDER LOGIC 4HIS CHARACTERIZATION ALLOWS I TO INFER AN ARCHITECTURAL DESCRIPTION FROM A PROPERTY SPECIFICATION II TO RETRIEVE AN ARCHITECTURE PROVIDING THE DEPENDABILITY PROPERTY TARGETED FOR A GIVEN SYSTEM AND III TO USE AN ARCHITECTURE SELECTED FROM THE REPOSITORY TO KNOW HOW TO EXTEND A BASE NON DEPENDABLE SYSTEM WITH APPROPRIATE FAULT TOLERANCE MECHANISMS (OWEVER WE CANNOT EXPECT SYSTEM DEVELOPERS TO CARRY OUT THE PROOFS APPERTAINED TO THE MANAGEMENT OF THE REPOSITORY OF DEPENDABLE ARCHITECTURES 4OOLS MUST BE PROVIDED TO ASSIST THIS MANAGEMENT 4HESE TOOLS INCLUDE • • ! TOOL FOR THE INFERENCE OF A DEPENDABLE ARCHITECTURE FROM THE SPECIFICATION OF A DEPENDABILITY PROPERTY ! TOOL FOR UPDATING THE REPOSITORY AND RETRIEVING ARCHITECTURES 4HIS TOOL SUBDIVIDES INTO A TOOL FOR CLASSICAL DATABASE MANAGEMENT AND A THEOREM PROVER FOR IMPLEMENTING THE DATABASE FUNCTIONS THAT ARE DEFINED OVER DEPENDABILITY PROPERTIES $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  7E ARE CURRENTLY IMPLEMENTING THE FIRST TOOL AS WELL AS THE ONE RELATING TO DATABASE MANAGEMENT THEIR FEATURES ARE DIRECT FROM THE PRESENTATION WE MADE IN THIS PAPER &ROM THE STANDPOINT OF PROVIDING A THEOREM PROVER WE ARE CURRENTLY EXAMINING EXISTING PROVERS EG -ANNA ET AL  SO AS TO REUSE AN EXISTING ONE FOR OUR FRAMEWORK  #/.#,53)/.3 4HIS PAPER HAS PRESENTED A FRAMEWORK AIMED AT EASING THE CONSTRUCTION OF DEPENDABLE SYSTEMS 4HE FRAMEWORK RELIES ON THE FORMAL SPECIFICATION OF DEPENDABILITY PROPERTIES USING TEMPORAL FIRST ORDER LOGIC 4HE PROPOSED SPECIFICATION OF DEPENDABILITY PROPERTIES ALLOWS TO INFER THE DEPENDABLE SOFTWARE ARCHITECTURE CORRESPONDING TO A PROPERTY WHICH CHARACTERIZES THE STRUCTURE OF A DEPENDABLE SYSTEM WITH RESPECT TO THE FAULT TOLERANCE TECHNIQUE ENFORCING THE GIVEN PROPERTY 4HE STRUCTURE OF A DEPENDABLE ARCHITECTURE FURTHER MAKES CLEAR HOW TO COMPOSE A DEPENDABLE SYSTEM FROM A BASE SYSTEM &ORMAL SPECIFICATION OF DEPENDABILITY PROPERTIES ENABLES US TO PROVIDE A REPOSITORY OF DEPENDABLE ARCHITECTURES WHICH IS ORGANIZED ACCORDING TO THE REFINEMENT RELATION HOLDING OVER DEPENDABILITY PROPERTIES /UR PROPOSAL RELATES TO A NUMBER OF RESEARCH EFFORTS OF THE SOFTWARE ENGINEERING DOMAIN )N PARTICULAR IT BUILDS ON RESULTS IN THE AREA OF ARCHITECTURE DESCRIPTION LANGUAGES AND OF SOFTWARE REUSE &ROM THE STANDPOINT OF EXISTING !$,S THERE HAVE BEEN MANY PROPOSALS BASED ON FORMAL TECHNIQUES (OWEVER THESE PROPOSALS AIM AT COMPLEMENTARY GOALS TO OURS &OR INSTANCE OBJECTIVES FOR !$,S BASED ON FORMAL TECHNIQUES INCLUDE COMPARISON OF ARCHITECTURAL STYLES USING THE : NOTATION !BOWD ET AL  REASONING ABOUT INTERACTION PATTERNS OF ARCHITECTURAL STYLES USING A #30 BASED CALCULUS !LLEN  COMPARISON OF ARCHITECTURE DESIGNS AND PROVING PROPERTIES WITH REGARD TO A SPECIFIC ARCHITECTURE USING THE CHEMICAL ABSTRACT MACHINE MODEL )NVERADI AND 7OLF  VERIFICATION OF RECONFIGURATION CORRECTNESS OF ARCHITECTURES USING GRAPH GRAMMARS ,E-ETAYER  DEFINITION OF EXECUTABLE PROTOTYPES FOR ARCHITECTURES USING PARTIALLY ORDERED SET OF EVENTS ,UCKHAM ET AL  AND CORRECT STEPWISE REFINEMENT OF ARCHITECTURES USING FIRST ORDER LOGIC -ORICONI ET AL   4HE LAST REFERENCE APPEARS TO BE THE MOST CLOSELY RELATED TO OUR PROPOSAL (OWEVER IN THIS REFERENCE THE ARCHITECTURAL REFINEMENT RELATES TO PRESERVING TOPOLOGICAL CONSTRAINTS OF THE ARCHITECTURAL ELEMENTS /N THE OTHER HAND WE ARE CONCERNED WITH CHARACTERIZING THE SEMANTICS OF AN ARCHITECTURE  4ITOS 3ARIDAKIS  6AL©RIE )SSARNY FROM THE STANDPOINT OF PROVIDED DEPENDABILITY PROPERTIES 4HIS CHARACTERIZATION FURTHER SERVES TO PROVIDE DEVELOPERS WITH A REPOSITORY OF DEPENDABLE ARCHITECTURES THAT SHOW HOW TO MAKE A BASE SYSTEM DEPENDABLE USING A FAULT TOLERANCE TECHNIQUE ENFORCING THE TARGETED DEPENDABILITY 4HERE IS A SIGNIFICANT AMOUNT OF WORK IN THE AREA OF SOFTWARE REUSE +RUEGER   )N THIS SUBSECTION WE CONCENTRATE ON TWO RESEARCH EFFORTS ON THIS TOPIC SYSTEMATIC COMPONENT RETRIEVAL AND SOFTWARE REUSE FOR CUSTOMIZING EXECUTION ENVIRONMENT 4O OUR KNOWLEDGE SYSTEMATIC COMPONENT RETRIEVAL BASED ON A SPECIFICATION OF COMPONENTS USING FIRST ORDER LOGIC HAS FIRSTLY BEEN EXPERIMENTED IN THE )NSCAPE ENVIRONMENT 0ERRY   4HIS ENVIRONMENT BELONGS TO THE FAMILY OF DEVELOPMENT ENVIRONMENTS THAT CAN BE SEEN AS ANCESTORS OF THE ONES BASED ON !$, IE APPLICATIONS ARE DESCRIBED USING A MODULE INTERCONNECTION LANGUAGE WHICH IS ROUGHLY AN !$, WITHOUT THE CONNECTOR NOTION 4HE )NSCAPE ENVIRONMENT DEMONSTRATED THAT IT WAS FEASIBLE TO USE THE SPECIFICATION OF COMPONENTS IN TERMS OF PRE AND POST CONDITIONS TO GUIDE COMPLEX SYSTEM DESIGN BUT ALSO TO RETRIEVE COMPONENT IMPLEMENTATIONS IN A SYSTEMATIC WAY 3UCCESSORS OF THIS PROPOSAL THEN ENHANCED THE PRACTICALITY OF SYSTEMATIC SOFTWARE RETRIEVAL ! SOFTWARE RETRIEVAL TOOL THAT MAY BE USED IN ANY DEVELOPMENT ENVIRONMENT IS PRESENTED IN 2OLLINS AND 7ING   4HIS CAPACITY IS FURTHER ENHANCED IN :AREMSKI AND 7ING  WHICH PROVIDES A FRAMEWORK TO SUPPORT THE DEFINITION OF VARIOUS REFINEMENT RELATIONS %FFICIENCY OF SOFTWARE RETRIEVAL IS ADDRESSED IN -ILI ET AL  WHICH PROPOSES TO ORGANIZE THE SOFTWARE DATABASE ACCORDING TO A REFINEMENT RELATION OVER SOFTWARE SPECIFICATIONS 4HIS WORK AND ITS MORE RECENT VERSION *ILANI ET AL  SUPPLY MOREOVER A RETRIEVAL FUNCTION THAT RETURNS A SOFTWARE COMPONENT APPROACHING A SPECIFICATION IF THERE IS NO AVAILABLE COMPONENT MATCHING THE REQUESTED SPECIFICATION 4HE PROPOSAL PRESENTED IN 3CHUMANN AND &ISCHER  ALSO ADDRESSES EFFICIENCY OF THE SOFTWARE RETRIEVAL PROCESS IT CONSISTS OF USING REJECTION FILTERS BASED ON SIGNATURE MATCHING AND MODEL CHECKING TECHNOLOGY TO RULE OUT NON MATCHING COMPONENTS AS EARLY AS POSSIBLE /UR PROPOSAL BUILDS ON THE ABOVE RESULTS AND APPLIES THEM TO THE DOMAIN OF RETRIEVING A SOFTWARE ARCHITECTURE WITH RESPECT TO A REQUESTED DEPENDABILITY PROPERTY INSTEAD OF A FUNCTIONAL ONE #USTOMIZING EXECUTION PLATFORMS SO AS TO ADAPT TO APPLICATION NEEDS IS NOW A GROWING CONCERN IN THE SOFTWARE ENGINEERING DOMAIN 4HIS HAS LED TO THE DEFINITION OF NOTATIONS TO EASE THE DEVELOPMENT OF CUSTOMIZED SYSTEMS USING EXISTING SOFTWARE %XAMPLES OF ENVIRONMENTS OFFERING SUCH A FACILITY CAN BE FOUND IN "ATORY AND /-ALLEY  (ILTUNEN AND 3CHLICHTING  3TRUMAN AND !GHA   4HESE PROPOSALS DIFFER FROM OURS IN THAT WE ARE ADDRESSING CUSTOMIZATION OF EXECUTION PLATFORMS BASED ON THE REFINEMENT OF REQUESTED DEPENDABILITY PROPERTIES WHILE THEY PROVIDE A WAY TO CONSTRUCT SUCH PLATFORMS BASED ON ITS ADEQUATE STRUCTURING 4HUS $EVELOPING $EPENDABLE 3YSTEMS 5SING 3OFTWARE !RCHITECTURE  THESE ENVIRONMENTS COULD BE CONVENIENTLY EXPLOITED IN OUR FRAMEWORK TO TAKE OVER THE CONSTRUCTION OF THE DEPENDABLE SYSTEM AFTER THE SELECTION OF THE ADEQUATE DEPENDABLE ARCHITECTURE 2%&%2%.#%3 !BOWD ' ET AL  &ORMALIZING 3TYLE TO 5NDERSTAND $ESCRIPTIONS OF 3OFTWARE !RCHITECTURE !#- 4RANSACTIONS ON 3OFTWARE %NGINEERING AND -ETHODOLOGY    !LLEN 2  ! &ORMAL !PPROACH TO 3OFTWARE !RCHITECTURE 0H$ 4HESIS $EPARTMENT OF #OMPUTER 3CIENCE #ARNEGIE -ELLON 5NIVERSITY 0ITTSBURGH 0! 53! !LLEN 2 AND 'ARLAN $  ! &ORMAL "ASIS FOR !RCHITECTURAL #ONNECTION !#4RANSACTIONS ON 3OFTWARE %NGINEERING AND -ETHODOLOGY    "ATORY $ AND /-ALLEY 3  4HE $ESIGN AND )MPLEMENTATION OF (IERARCHICAL 3OFTWARE 3YSTEMS WITH 2EUSABLE #OMPONENTS !#- 4RANSACTIONS ON 3OFTWARE %NGINEERING AND -ETHODOLOGY    #HRYSANTHIS 0 AND 2AMAMRITHAM +  3YNTHESIS OF %XTENDED 4RANSACTION -ODELS USING !CTA !#- 4RANSACTIONS ON $ATABASE 3YSTEMS    'ARLAN $ ET AL  !#-% !N !RCHITECTURE )NTERCHANGE ,ANGUAGE 4ECHNICAL 2EPORT $EPARTMENT OF #OMPUTER 3CIENCE #ARNEGIE -ELLON 5NIVERSITY 0ITTSBURGH 0! 53! (ILTUNEN - ! AND 3CHLICHTING 2$  #ONSTRUCTING A #ONFIGURABLE 'ROUP 20# 3ERVICE 0ROCEEDINGS OF THE TH )%%% )NTERNATIONAL #ONFERENCE ON $ISTRIBUTED #OMPUTING 3YSTEMS PAGES   )NVERARDI 0 AND 7OLF ! ,  &ORMAL 3PECIFICATION AND !NALYSIS OF 3OFTWARE !RCHITECTURES 5SING THE #HEMICAL !BSTRACT -ACHINE -ODEL )%%% 4RANSACTIONS ON 3OFTWARE %NGINEERING    *ILANI , , ET AL  2ETRIEVING 3OFTWARE #OMPONENTS THAT -INIMIZE !DAPTATION %FFORT 0ROCEEDINGS OF THE )%%% )NTERNATIONAL #ONFERENCE ON !UTOMATED 3OFTWARE %NGINEERING PAGES   +RUEGER # 7  3OFTWARE 2EUSE !#- #OMPUTING 3URVEYS    ,AMPORT ,  4IME #LOCKS AND THE /RDERINGS OF %VENTS IN A $ISTRIBUTED 3YSTEM #OMMUNICATIONS OF THE !#-    ,APRIE * #  $EPENDABILITY "ASIC #ONCEPTS AND 4ERMINOLOGY $EPENDABLE #OMPUTING AND &AULT 4OLERANT 3YSTEMS 3PRINGER 6ERLAG ,E-ETAYER $  3OFTWARE !RCHITECTURE 3TYLES AS 'RAPH 'RAMMARS 0ROCEEDINGS OF THE !#- 3)'3/&4 3YMPOSIUM ON &OUNDATIONS OF 3OFTWARE %NGINEERING PAGES   ,UCKHAM $ # ET AL  3PECIFICATION AND !NALYSIS OF 3YSTEM !RCHITECTURE 5SING 2APIDE )%%% 4RANSACTIONS ON 3OFTWARE %NGINEERING    -ANNA : ET AL  34E0 4HE 3TANFORD 4EMPORAL 0ROVER 4ECHNICAL 2EPORT .O  #OMPUTER 3CIENCE $EPARTMENT 3TANFORD 5NIVERSITY 3TANFORD #! 53! -ILI 2 ET AL  3TORING AND 2ETRIEVING 3OFTWARE #OMPONENTS ! 2EFINEMENT "ASED 3YSTEM )%%% 4RANSACTIONS ON 3OFTWARE %NGINEERING    -ORICONI - ET AL  #ORRECT !RCHITECTURE 2EFINEMENT )%%% 4RANSACTIONS ON 3OFTWARE %NGINEERING    0ERRY $ %  4HE )NSCAPE %NVIRONMENT 0ROCEEDINGS OF THE TH )NTERNATIONAL #ONFERENCE ON 3OFTWARE %NGINEERING PAGES   0ERRY $ % AND 7OLF ! ,  &OUNDATIONS FOR THE 3TUDY OF 3OFTWARE !RCHITECTURE !#3)'3/&4 3OFTWARE %NGINEERING .OTES     4ITOS 3ARIDAKIS  6AL©RIE )SSARNY 2OLLINS % * AND 7ING * -  3PECIFICATIONS AS 3EARCH +EYS FOR 3OFTWARE ,IBRARIES 0ROCEEDINGS OF THE TH )NTERNATIONAL #ONFERENCE ON ,OGIC 0ROGRAMMING PAGES   3CHUMANN * AND &ISCHER "  ./2!(!--2 -AKING $EDUCTION BASED 3OFTWARE #OMPONENT 2ETRIEVAL 0RACTICAL 0ROCEEDINGS OF THE TH )%%% )NTERNATIONAL #ONFERENCE ON !UTOMATED 3OFTWARE %NGINEERING PAGES   3HAW - AND 'ARLAN $  3OFTWARE !RCHITECTURE 0ERSPECTIVES ON AN %MERGING $ISCIPLINES 0RENTICE (ALL 3TOLLER 3 $ AND 3CHNEIDER & "  !UTOMATED !NALYSIS OF &AULT 4OLERANCE IN $ISTRIBUTED 3YSTEMS 4ECHNICAL 2EPORT .O $EPARTMENT OF #OMPUTER 3CIENCE #ORNELL 5NIVERSITY )THACA .9 53! 3TURMAN $ # AND !GHA ' !  ! 0ROTOCOL $ESCRIPTION ,ANGUAGE FOR #USTOMIZING &AILURE 3EMANTICS 0ROCEEDINGS OF THE 4HIRTEENTH )%%% 3YMPOSIUM ON 2ELIABLE $ISTRIBUTED 3YSTEMS PAGES   :AREMSKI ! - AND 7ING * -  3PECIFICATION -ATCHING OF 3OFTWARE #OMPONENTS !#- 4RANSACTIONS ON 3OFTWARE %NGINEERING AND -ETHODOLOGY