Your SlideShare is downloading. ×
PhD thesis defense
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PhD thesis defense

1,221
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,221
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • WITH RESPECT TO SOME REQUIREMENTS\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • SPA : Sense Plan Act\n
  • 8 minutes\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 22 minutes\n
  • \n
  • Leveraging the GPL’s type checker\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 35 minutes\n
  • \n
  • \n
  • \n
  • Representative applications\n
  • Representative applications\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • CURRENT PERSPECTIVES\n
  • \n
  • \n
  • \n
  • Transcript

    • 1. Leveraging Software Design to Guide the Development ofSense/Compute/Control Applications Damien Cassou
    • 2. Design is Crucial “The most important ingredient in ensuring a soft ware system’s long-term success is its design ” ICSE’11 c.f.p• A good design improves n1155: lf n162 ForLoop n536 start() n1704 n822 • collaboration ArcCond ArcSon ArcCond ArcCond n324 n1303 [name > len] n1304: Block Block error_mark visb: string = unk run_arch() ArcCond ArcCond ArcSon[2] [name <= len] stop_arch() n1702: Operator n1834: Operator • productivity op: string = fct_call ArcSon[1] op: string = fct_call n64: Literal ArcOpd[1] ArcOpd[2] value: string = 0 <<StartState . ActionState >> n7848 success << ActionState >> Suggest Itineraries NameRef n7848 n1966 RefersTo RefersTo NameRef ualFctParam error success n7840 RefersTo n7820: NameRef << EndState >> << EndState >> • maintenance NameRef value: string = len << ViewState >> startOver Display Itineraries RefersTo Try Again n471: Object success Cancel name: string = done n391: Function visb: string = unk name: string = exit static: bool = false << ActionState >> visb: string = pub extern: bool = false Select Itineraries virtual: string = non-virtual const: bool false assign book Instance RefersTo RefersTo n27: BuiltinType << SubFlowState >> finish << ActionState >> name: string = void n7828: NameRef n7846: NameRef Choose Itineraries Book Itineraries visb: string = unk name: string = done name: string = done success Confirmation 2
    • 3. Design FrameworkA good design requires a design frameworkwhich guides the architect with • a language n536 n1704 n822 start() n1155: lf n162 ForLoop ArcCond ArcSon ArcCond ArcCond n324 • a paradigm n1303 [name > len] n1304: Block Block error_mark visb: string = unk run_arch() ArcCond ArcCond ArcSon[2] [name <= len] stop_arch() n1702: Operator n1834: Operator op: string = fct_call ArcSon[1] op: string = fct_call n64: Literal ArcOpd[1] ArcOpd[2] value: string = 0 <<StartState . ActionState >> n7848 success << ActionState >> Suggest Itineraries NameRef n7848 n1966 RefersTo RefersTo NameRef ualFctParam error success n7840 RefersTo n7820: NameRef << EndState >> << EndState >> NameRef value: string = len << ViewState >> startOver Display Itineraries RefersTo Try Again n471: Object success Cancel name: string = done n391: Function visb: string = unk name: string = exit static: bool = false << ActionState >> visb: string = pub extern: bool = false Select Itineraries virtual: string = non-virtual const: bool false assign book Instance RefersTo RefersTo n27: BuiltinType << SubFlowState >> finish << ActionState >> name: string = void n7828: NameRef n7846: NameRef Choose Itineraries Book Itineraries visb: string = unk name: string = done name: string = done success Confirmation 3
    • 4. Programming FrameworkA good implementation requires aprogramming framework whichguides the developer with • abstractions • services 4
    • 5. Conformance An implementation must conform to its design n536 n1704 n822 start() n1155: lf n162 ForLoop ArcCond ArcSon ArcCond ArcCond n324 n1303 [name > len] n1304: Block Block error_mark visb: string = unk run_arch() ArcCond ArcCond ArcSon[2] [name <= len] stop_arch() n1702: Operator n1834: Operator op: string = fct_call ArcSon[1] op: string = fct_call n64: Literal ArcOpd[1] ArcOpd[2] value: string = 0 <<StartState . ActionState >> n7848 success << ActionState >> Suggest Itineraries NameRef n7848 n1966 RefersTo RefersTo NameRef ualFctParam error success n7840 RefersTo n7820: NameRef << EndState >> << EndState >>NameRef value: string = len << ViewState >> startOver Display Itineraries RefersTo Try Again n471: Object success Cancel name: string = done n391: Function visb: string = unk name: string = exit static: bool = false << ActionState >> visb: string = pub extern: bool = false Select Itineraries virtual: string = non-virtual const: bool false assign book Instance RefersTo RefersTo n27: BuiltinType << SubFlowState >> finish << ActionState >> name: string = void n7828: NameRef n7846: NameRef Choose Itineraries Book Itineraries visb: string = unk name: string = done name: string = done success Confirmation 5
    • 6. Requirements1. A design framework to guide the architect 2. A programming framework to guide the developer 3. A guaranteed conformance of the implementation relatively to the design Conformance 6
    • 7. Related WorksDesign Implementation Conformance Conformance 7
    • 8. Related Works GPLDesign Implementation + Conformance Conformance Java 8
    • 9. Related Works GPL LibraryDesign Implementation + ++ Conformance Conformance Spring 9
    • 10. Related Works GPL Library ADLDesign ++ Implementation + ++ Conformance Conformance C2 10
    • 11. Related Works GPL Library ADL ADL++Design ++ + Implementation + ++ + Conformance + Conformance ArchJava 11
    • 12. ThesisA paradigm-oriented framework for both design and implementation which maintains conformance all along the software life-cycle 12
    • 13. The ParadigmSense/Compute/Control (SCC) “applications that interact with an environment” Environment 13
    • 14. The SCC Paradigm sensecompute Environment control 14
    • 15. The SCC Paradigm sense GPS, flight plan computecomputedirection control control aileron, engine 15
    • 16. The SCC Paradigm motion detection sense compute Environmentintrusion? control trigger alarms 16
    • 17. The SCC ParadigmCovers various domains • pervasive computing • tier-system monitoring Environment • avionics • robotics • ... 17
    • 18. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 18
    • 19. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 19
    • 20. Design Language Environmentorders 20
    • 21. Design Language sources Environment• sources sense the environment orders 20
    • 22. Design Language sources Environment actions• sources sense the environment• actions impact the environment orders 20
    • 23. Design Language a concept for handling the interaction with the environment sources Environment actions• sources sense the environment• actions impact the environment orders 20
    • 24. Design Languageentity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environmentaction UpdateSt { updateStatus(message as String);} sources Entities Environment actions • sources sense the environment • actions impact the environment orders 20
    • 25. Design Languageentity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environmentaction UpdateSt { updateStatus(message as String);} sources Entities Environment actions 1 entity description for potentially many implementations orders 21
    • 26. Design Languageentity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environmentaction UpdateSt { updateStatus(message as String);} sources Entities Environment actions 1 entity description for potentially many instances orders 22
    • 27. Design Languageentity Keypad { source keycode as Integer; action UpdateSt;  attribute room as Integer;}action UpdateSt { updateStatus(message as String);} sources Entities Environment actions 1 entity description for potentially many instances➡ attributes to characterize instances orders (color, location, reliability, etc.) 23
    • 28. Design Language raw data a concept to refine raw data sources Entities Environment actionsorders 24
    • 29. Design Language raw data a concept to refine raw data context operators sources refinedinformation Entities Environment actionscontext BuildingSecured as Boolean { source keycode from Keypad;} orders  24
    • 30. Design Language raw data a concept to take decisions based on application-level data context operators sources refinedinformation Entities Environment actions orders 25
    • 31. Design Language raw data a concept to take decisions based on application-level data context operators sources refinedinformation Entities Environment actions control operators controller BuildingManager { context BuildingSecured; orders orders action UpdateSt on Keypad; }  25
    • 32. Design Language raw data The language features concepts Compute dedicated to the SCC paradigm context Sense operators sources refinedinformation Entities Environment actions control operators orders orders Control 26
    • 33. Application logic Environment handling context operators sources refinedinformation Entities Environment actions control operators orders 27
    • 34. context operators Information creation refinedinformation control operators Information use orders 28
    • 35. Design Language raw data context operators sources refinedinformation Entities Environment actions control operators orders orders 29
    • 36. Design Language actions control operators context operatorsorders sources 30
    • 37. Design Language actions control operators context operatorsorders sources 31
    • 38. Case Study: Anti-Intrusion actions control operators context operators sources 32
    • 39. Case Study: Anti-Intrusion actions control operators Intrusion context operators sources 32
    • 40. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operators sources 32
    • 41. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operatorsBuilding PresenceSecured sources 32
    • 42. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operatorsBuilding PresenceSecured keycode motionKeypad MotionSensor sources 32
    • 43. Case Study: Anti-IntrusionKeypad Alarm actionsUpdateSt OnOffSecurity Intrusion controlManager Manager operators Intrusion context operatorsBuilding PresenceSecured keycode motionKeypad MotionSensor sources 32
    • 44. Case Study: Anti-IntrusionKeypad Alarm Mailer actionsUpdateSt OnOff SendSecurity Intrusion controlManager Manager operators Intrusion context operatorsBuilding Scene PresenceSecured Image keycode motion imageKeypad MotionSensor Camera sources 32
    • 45. Case Study: Anti-IntrusionKeypad Alarm Mailer actionsUpdateSt OnOff SendSecurity Intrusion controlManager Manager operators Intrusion context operatorsBuilding Scene PresenceSecured Image keycode motion imageKeypad MotionSensor Camera sources 33
    • 46. Case Study: Anti-Intrusion IntrusionBuilding PresenceSecured 34
    • 47. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
    • 48. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
    • 49. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
    • 50. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations 35
    • 51. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
    • 52. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
    • 53. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
    • 54. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
    • 55. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
    • 56. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
    • 57. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
    • 58. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured the architect should express what he has in mind 35
    • 59. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured the architect should express what he has in mind  ➡interaction contracts 35
    • 60. Interaction Contracts context operator 36
    • 61. Interaction Contracts request1 Activation condition 1 context operator 36
    • 62. Interaction Contracts1 Activation condition context operator event 1 36
    • 63. Interaction Contracts1 Activation condition2 Data requirement context operator event 1 2 request 2 request source context Entity operator 36
    • 64. Interaction Contracts1 Activation condition 3 event2 Data requirement context operator3 Emission event 1 2 request 2 request source context Entity operator 36
    • 65. Interaction Contracts1 Activation condition2 Data requirement Intrusion3 Emission Buildingcontext Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { when provided Presence get BuildingSecured maybe publish }} 37 
    • 66. Interaction Contracts1 Activation condition2 Data requirement Intrusion 13 Emission Buildingcontext Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction {1 when provided Presence get BuildingSecured maybe publish }} 37 
    • 67. Interaction Contracts1 Activation condition2 Data requirement Intrusion 2 13 Emission Buildingcontext Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction {1 when provided Presence2 get BuildingSecured maybe publish }} 37 
    • 68. Interaction Contracts1 Activation condition 32 Data requirement Intrusion 2 13 Emission Buildingcontext Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction {1 when provided Presence2 get BuildingSecured3 maybe publish }} 37 
    • 69. Interaction Contracts1 Activation condition 32 Data requirement Intrusion 2 13 Emission Buildingcontext Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction {1 when provided Presence2 get BuildingSecured3 maybe publish related to automata } approaches} 37 
    • 70. Summary A design framework consisting of a design language, DiaSpec,which guides the architect by offering • concepts dedicated to the SCC paradigm • a separation between environment handling and logic • a separation between information creation and use • a dedicated description of interactions 38
    • 71. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 39
    • 72. A Programming Framework Generated from the Design DiaSpec GPL         40
    • 73. A Programming Framework Generated from the Design DiaSpec GPL        • separates 2 different roles with 2 different languages• leverages GPL tools, libraries and expertise• ensures conformance automatically 40
    • 74. A Programming Framework how to make a programming framework conform to a particular design? 41
    • 75. A Programming FrameworkThe code generator maps • each description to an abstract class • each interaction contract to an abstract method 42
    • 76. A Programming FrameworkThe code generator maps • each description to an abstract class • each interaction contract to an abstract methodBy leveraging the GPL type checker, the framework • guides the implementation of what is required • forbids anything not specified in the design 42
    • 77. A Programming FrameworkThe code generator maps • each description to an abstract class • each interaction contract to an abstract methodBy leveraging the GPL type checker, the framework • guides the implementation of what is required • forbids anything not specified in the design different than what isproposed by ADLs or MDE 42
    • 78. Generation context Presence as Boolean { source motion from MotionSensor; interaction { Presence when provided motion from MotionSensor get motion from MotionSensor motion always publishMotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select);} 43
    • 79. Generation context Presence as Boolean { source motion from MotionSensor; interaction { Presence when provided motion from MotionSensor get motion from MotionSensor motion always publishMotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select);} 44
    • 80. Generation context Presence as Boolean { source motion from MotionSensor; interaction { Presence when provided motion from MotionSensor get motion from MotionSensor motion always publishMotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select);} 45
    • 81. Generation context Presence as Boolean { source motion from MotionSensor; interaction { Presence when provided motion from MotionSensor get motion from MotionSensor motion always publishMotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select);} according to the interaction contract 46
    • 82. Generation context Presence as Boolean { source motion from MotionSensor; interaction { Presence when provided motion from MotionSensor get motion from MotionSensor motion always publishMotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select);} 47
    • 83. Implementing the Behaviorcontext Presence as Boolean { source motion from MotionSensor; interaction { abstract class AbstractPresence { when provided motion from MotionSensor abstract boolean onMotionFromMotionSensor( boolean motion, Select select); get motion from MotionSensor } always publish }}  class Presence extends AbstractPresence { boolean onMotionFromMotionSensor( boolean motion, Select select) { return motion; } }  48
    • 84. Implementing the Behavior when motion is detected ➡ there is presencewhen motion is not detected? ➡ ? The developer needs to ask all motion sensors class Presence extends AbstractPresence { boolean onMotionFromMotionSensor( boolean motion, Select select) { return motion; } }  49
    • 85. Entity SelectionRequired when an entityis the interaction’s target Guide the developer with an embedded and type-safe DSL  50
    • 86. Entity Selectionentity MotionSensor { source motion as Boolean; attribute room as Integer;}  Select all motion sensors: select.motionSensors().all()  51
    • 87. Entity Selection room = 1 room = 2 room = 3 1 2 3entity MotionSensor { source motion as Boolean; attribute room as Integer;}  0 4 room = 0 room = 4 Select all motion sensors in rooms 1 to 3:  select.motionSensors().whereRoom(between(1,3)) 52
    • 88. Commanding Entitiesentity Alarm { action OnOff { action OnOff; on();} off(); }  room = 0 room = 4 Triggering all alarms: select.alarms().all().on();  53
    • 89. Entity Selection Conformanceentity Alarm { action OnOff { action OnOff; on();} off(); }  room = 0 room = 4 Conformance It is not possible to send unsupported orders: select.alarms().all().start(); compile-time error 54
    • 90. Entity Selectioncontext Presence as Boolean { source motion from MotionSensor; interaction { when provided motion from MotionSensor get motion from MotionSensor always publish }}  Presence motion MotionSensor room = 0 room = 4 Conformance It is not possible to discover all kinds of entities: select.alarms().all(); compile-time error 55
    • 91. Implementing the Behaviorcontext Presence as Boolean { source motion from MotionSensor; interaction { abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor(...); when provided motion from MotionSensor } get motion from MotionSensor always publish }} class Presence extends AbstractPresence { boolean onMotionFromMotionSensor( boolean motion, Select select) { if (motion) return true; MotionSensors sensors = select.motionSensors().all(); for (MotionSensor sensor : sensors) if (sensor.getMotion()) return true; return false; }}  56
    • 92. SummaryThe developer is guided with • a support dedicated to the application  • an embedded DSL for entity selectionConformance is ensured by Conformance • generating a programming framework • leveraging a GPL type checker 57
    • 93. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 58
    • 94. Evaluation of the Approach• Expressiveness• Usability• Productivity 59
    • 95. Evaluation: ExpressivenessNumerous domains • home-automation • avionics • graphical user interfaces • health-care • telecommunications • tier-system monitoring • etc. 60
    • 96. Evaluation: UsabilityContext • 80 students during 3 years • sparse and oral-only documentationResults • 64 students completed the assignment • Identification of the interaction contracts 61
    • 97. Evaluation: Productivity We measured the amount of code generated automatically 62
    • 98. Evaluation: Productivity Specification 8% Implementation 10% Framework 82% 63
    • 99. Evaluation: Productivity Specification 8% Implementation 10% Framework 82% ➡ 76% actually executed 63
    • 100. Evaluation: Productivity Complexity of the developer’s codeWe used the Sonar platform to measure code qualitythrough numerous metrics 64
    • 101. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code” McCabe cyclomatic complexity 64
    • 102. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code” McCabe cyclomatic complexity1 3 7 10 ∞ 64
    • 103. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code” McCabe cyclomatic complexity“quite well structured ” {1 3 7 10 ∞ 64
    • 104. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code ” McCabe cyclomatic complexity“quite well structured ” “ ” very poor quality {1 3 7 10 ∞ 64
    • 105. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code ” McCabe cyclomatic complexity“quite well structured ” “ ” very poor quality {1 3 7 10 ∞ on average 64
    • 106. Summary• The approach covers various domains• The frameworks are easy to use• Few code is required and this code is of good qualityPursuing this evaluation with software engineers 65
    • 107. ResultsScientific contributions   Conformance • A design language dedicated to SCC (ICSE’11) • The generation of a dedicated programming framework (GPCE’09) • The evaluation of this approach (submitted)Technical contributions • A compiler for the design language (9 KLoC) • A code generator targeting Java (4 KLoC)Dissemination • Demonstrations (PerCom’10), posters (SPLASH’10), visits (Bern, Potsdam) • Public release (http://diasuite.inria.fr) 66
    • 108. A Research VehicleThis design language and code generator are part of aresearch project which involves • 4 industrial partnerships • 2 other research groups • > 20 real applications • 24/7 running platform • 28,000 lines of code 67
    • 109. A Research Vehicle7 PhD students leveraging DiaSpec and the generator • QoS (FASE’11) • error-handling (OOPSLA’10) • virtual testing (Mobiquitous’09 and ’10) • SIP (ICC’10, ICIN’09, IPTComm’08) • end-user programming (DSLWC’09) • security (ICPS’09) 68
    • 110. Perspectives• Can we support other stages of the software life-cycle?requirements design code testing maintenance     • Can we transpose the approach to another paradigm?• Can we help creating such approaches? 69
    • 111. 70
    • 112. Facilitating Evolution           • eases developer’s work by • showing mismatches    • leveraging development tools• ensures conformance all along the software life-cycle 71