Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PhD thesis defense

2,214 views

Published on

Published in: Technology
  • Be the first to comment

PhD thesis defense

  1. 1. Leveraging Software Design to Guide the Development ofSense/Compute/Control Applications Damien Cassou
  2. 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. 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. 4. Programming FrameworkA good implementation requires aprogramming framework whichguides the developer with • abstractions • services 4
  5. 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. 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. 7. Related WorksDesign Implementation Conformance Conformance 7
  8. 8. Related Works GPLDesign Implementation + Conformance Conformance Java 8
  9. 9. Related Works GPL LibraryDesign Implementation + ++ Conformance Conformance Spring 9
  10. 10. Related Works GPL Library ADLDesign ++ Implementation + ++ Conformance Conformance C2 10
  11. 11. Related Works GPL Library ADL ADL++Design ++ + Implementation + ++ + Conformance + Conformance ArchJava 11
  12. 12. ThesisA paradigm-oriented framework for both design and implementation which maintains conformance all along the software life-cycle 12
  13. 13. The ParadigmSense/Compute/Control (SCC) “applications that interact with an environment” Environment 13
  14. 14. The SCC Paradigm sensecompute Environment control 14
  15. 15. The SCC Paradigm sense GPS, flight plan computecomputedirection control control aileron, engine 15
  16. 16. The SCC Paradigm motion detection sense compute Environmentintrusion? control trigger alarms 16
  17. 17. The SCC ParadigmCovers various domains • pervasive computing • tier-system monitoring Environment • avionics • robotics • ... 17
  18. 18. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 18
  19. 19. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 19
  20. 20. Design Language Environmentorders 20
  21. 21. Design Language sources Environment• sources sense the environment orders 20
  22. 22. Design Language sources Environment actions• sources sense the environment• actions impact the environment orders 20
  23. 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. 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. 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. 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. 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. 28. Design Language raw data a concept to refine raw data sources Entities Environment actionsorders 24
  29. 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. 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. 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. 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. 33. Application logic Environment handling context operators sources refinedinformation Entities Environment actions control operators orders 27
  34. 34. context operators Information creation refinedinformation control operators Information use orders 28
  35. 35. Design Language raw data context operators sources refinedinformation Entities Environment actions control operators orders orders 29
  36. 36. Design Language actions control operators context operatorsorders sources 30
  37. 37. Design Language actions control operators context operatorsorders sources 31
  38. 38. Case Study: Anti-Intrusion actions control operators context operators sources 32
  39. 39. Case Study: Anti-Intrusion actions control operators Intrusion context operators sources 32
  40. 40. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operators sources 32
  41. 41. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operatorsBuilding PresenceSecured sources 32
  42. 42. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operatorsBuilding PresenceSecured keycode motionKeypad MotionSensor sources 32
  43. 43. Case Study: Anti-IntrusionKeypad Alarm actionsUpdateSt OnOffSecurity Intrusion controlManager Manager operators Intrusion context operatorsBuilding PresenceSecured keycode motionKeypad MotionSensor sources 32
  44. 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. 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. 46. Case Study: Anti-Intrusion IntrusionBuilding PresenceSecured 34
  47. 47. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
  48. 48. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
  49. 49. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured what the architect has in mind 34
  50. 50. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations 35
  51. 51. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
  52. 52. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
  53. 53. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
  54. 54. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion Building Presence Secured 35
  55. 55. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
  56. 56. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
  57. 57. Case Study: Anti-Intrusion Intrusion IntrusionBuilding Building Presence PresenceSecured Secured possible interpretations Intrusion IntrusionBuilding Building Presence PresenceSecured Secured 35
  58. 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. 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. 60. Interaction Contracts context operator 36
  61. 61. Interaction Contracts request1 Activation condition 1 context operator 36
  62. 62. Interaction Contracts1 Activation condition context operator event 1 36
  63. 63. Interaction Contracts1 Activation condition2 Data requirement context operator event 1 2 request 2 request source context Entity operator 36
  64. 64. Interaction Contracts1 Activation condition 3 event2 Data requirement context operator3 Emission event 1 2 request 2 request source context Entity operator 36
  65. 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. 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. 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. 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. 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. 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. 71. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 39
  72. 72. A Programming Framework Generated from the Design DiaSpec GPL         40
  73. 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. 74. A Programming Framework how to make a programming framework conform to a particular design? 41
  75. 75. A Programming FrameworkThe code generator maps • each description to an abstract class • each interaction contract to an abstract method 42
  76. 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. 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. 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. 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. 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. 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. 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. 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. 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. 85. Entity SelectionRequired when an entityis the interaction’s target Guide the developer with an embedded and type-safe DSL  50
  86. 86. Entity Selectionentity MotionSensor { source motion as Boolean; attribute room as Integer;}  Select all motion sensors: select.motionSensors().all()  51
  87. 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. 88. Commanding Entitiesentity Alarm { action OnOff { action OnOff; on();} off(); }  room = 0 room = 4 Triggering all alarms: select.alarms().all().on();  53
  89. 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. 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. 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. 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. 93. Contributions1. A paradigm-specific design framework2. A programming framework dedicated to a design3. An evaluation of the approach 58
  94. 94. Evaluation of the Approach• Expressiveness• Usability• Productivity 59
  95. 95. Evaluation: ExpressivenessNumerous domains • home-automation • avionics • graphical user interfaces • health-care • telecommunications • tier-system monitoring • etc. 60
  96. 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. 97. Evaluation: Productivity We measured the amount of code generated automatically 62
  98. 98. Evaluation: Productivity Specification 8% Implementation 10% Framework 82% 63
  99. 99. Evaluation: Productivity Specification 8% Implementation 10% Framework 82% ➡ 76% actually executed 63
  100. 100. Evaluation: Productivity Complexity of the developer’s codeWe used the Sonar platform to measure code qualitythrough numerous metrics 64
  101. 101. Evaluation: Productivity Complexity of the developer’s code “ number of linearly independent paths in a source code” McCabe cyclomatic complexity 64
  102. 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. 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. 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. 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. 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. 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. 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. 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. 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. 111. 70
  112. 112. Facilitating Evolution           • eases developer’s work by • showing mismatches    • leveraging development tools• ensures conformance all along the software life-cycle 71

×