Leveraging Software Design Frameworks
•Télécharger en tant que KEY, PDF•
2 j'aime•1,725 vues
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Leveraging Software Design Frameworks
- 1. Leveraging Software Design to Guide the Development of Sense/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 Framework A good design requires a design framework which 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 Framework A good implementation requires a programming framework which guides 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. Requirements 1. 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 Works Design Implementation Conformance Conformance 7
- 8. Related Works GPL Design Implementation + Conformance Conformance Java 8
- 9. Related Works GPL Library Design Implementation + ++ Conformance Conformance Spring 9
- 10. Related Works GPL Library ADL Design ++ Implementation + ++ Conformance Conformance C2 10
- 11. Related Works GPL Library ADL ADL++ Design ++ + Implementation + ++ + Conformance + Conformance ArchJava 11
- 12. Thesis A paradigm-oriented framework for both design and implementation which maintains conformance all along the software life-cycle 12
- 13. The Paradigm Sense/Compute/Control (SCC) “applications that interact with an environment” Environment 13
- 14. The SCC Paradigm sense compute Environment control 14
- 15. The SCC Paradigm sense GPS, flight plan compute compute direction control control aileron, engine 15
- 16. The SCC Paradigm motion detection sense compute Environment intrusion? control trigger alarms 16
- 17. The SCC Paradigm Covers various domains • pervasive computing • tier-system monitoring Environment • avionics • robotics • ... 17
- 18. Contributions 1. A paradigm-specific design framework 2. A programming framework dedicated to a design 3. An evaluation of the approach 18
- 19. Contributions 1. A paradigm-specific design framework 2. A programming framework dedicated to a design 3. An evaluation of the approach 19
- 20. Design Language Environment orders 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 Language entity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environment action UpdateSt { updateStatus(message as String); } sources Entities Environment actions • sources sense the environment • actions impact the environment orders 20
- 25. Design Language entity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environment action UpdateSt { updateStatus(message as String); } sources Entities Environment actions 1 entity description for potentially many implementations orders 21
- 26. Design Language entity Keypad { source keycode as Integer; a concept for handling action UpdateSt; } the interaction with the environment action UpdateSt { updateStatus(message as String); } sources Entities Environment actions 1 entity description for potentially many instances orders 22
- 27. Design Language entity 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 actions orders 24
- 29. Design Language raw data a concept to refine raw data context operators sources refined information Entities Environment actions context 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 refined information Entities Environment actions orders 25
- 31. Design Language raw data a concept to take decisions based on application-level data context operators sources refined information 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 refined information Entities Environment actions control operators orders orders Control 26
- 33. Application logic Environment handling context operators sources refined information Entities Environment actions control operators orders 27
- 34. context operators Information creation refined information control operators Information use orders 28
- 35. Design Language raw data context operators sources refined information Entities Environment actions control operators orders orders 29
- 36. Design Language actions control operators context operators orders sources 30
- 37. Design Language actions control operators context operators orders 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 operators Building Presence Secured sources 32
- 42. Case Study: Anti-Intrusion Alarm actions OnOff Intrusion control Manager operators Intrusion context operators Building Presence Secured keycode motion Keypad MotionSensor sources 32
- 43. Case Study: Anti-Intrusion Keypad Alarm actions UpdateSt OnOff Security Intrusion control Manager Manager operators Intrusion context operators Building Presence Secured keycode motion Keypad MotionSensor sources 32
- 44. Case Study: Anti-Intrusion Keypad Alarm Mailer actions UpdateSt OnOff Send Security Intrusion control Manager Manager operators Intrusion context operators Building Scene Presence Secured Image keycode motion image Keypad MotionSensor Camera sources 32
- 45. Case Study: Anti-Intrusion Keypad Alarm Mailer actions UpdateSt OnOff Send Security Intrusion control Manager Manager operators Intrusion context operators Building Scene Presence Secured Image keycode motion image Keypad MotionSensor Camera sources 33
- 46. Case Study: Anti-Intrusion Intrusion Building Presence Secured 34
- 47. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured what the architect has in mind 34
- 48. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured what the architect has in mind 34
- 49. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured what the architect has in mind 34
- 50. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations 35
- 51. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Building Presence Secured 35
- 52. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Building Presence Secured 35
- 53. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Building Presence Secured 35
- 54. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Building Presence Secured 35
- 55. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Intrusion Building Building Presence Presence Secured Secured 35
- 56. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Intrusion Building Building Presence Presence Secured Secured 35
- 57. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Intrusion Building Building Presence Presence Secured Secured 35
- 58. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Intrusion Building Building Presence Presence Secured Secured the architect should express what he has in mind 35
- 59. Case Study: Anti-Intrusion Intrusion Intrusion Building Building Presence Presence Secured Secured possible interpretations Intrusion Intrusion Building Building Presence Presence Secured Secured the architect should express what he has in mind ➡interaction contracts 35
- 60. Interaction Contracts context operator 36
- 61. Interaction Contracts request 1 Activation condition 1 context operator 36
- 62. Interaction Contracts 1 Activation condition context operator event 1 36
- 63. Interaction Contracts 1 Activation condition 2 Data requirement context operator event 1 2 request 2 request source context Entity operator 36
- 64. Interaction Contracts 1 Activation condition 3 event 2 Data requirement context operator 3 Emission event 1 2 request 2 request source context Entity operator 36
- 65. Interaction Contracts 1 Activation condition 2 Data requirement Intrusion 3 Emission Building context Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { when provided Presence get BuildingSecured maybe publish } } 37
- 66. Interaction Contracts 1 Activation condition 2 Data requirement Intrusion 1 3 Emission Building context Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { 1 when provided Presence get BuildingSecured maybe publish } } 37
- 67. Interaction Contracts 1 Activation condition 2 Data requirement Intrusion 2 1 3 Emission Building context Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { 1 when provided Presence 2 get BuildingSecured maybe publish } } 37
- 68. Interaction Contracts 1 Activation condition 3 2 Data requirement Intrusion 2 1 3 Emission Building context Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { 1 when provided Presence 2 get BuildingSecured 3 maybe publish } } 37
- 69. Interaction Contracts 1 Activation condition 3 2 Data requirement Intrusion 2 1 3 Emission Building context Intrusion as Boolean { Presence context Presence; Secured context BuildingSecured; interaction { 1 when provided Presence 2 get BuildingSecured 3 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. Contributions 1. A paradigm-specific design framework 2. A programming framework dedicated to a design 3. 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 Framework The code generator maps • each description to an abstract class • each interaction contract to an abstract method 42
- 76. A Programming Framework The code generator maps • each description to an abstract class • each interaction contract to an abstract method By 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 Framework The code generator maps • each description to an abstract class • each interaction contract to an abstract method By leveraging the GPL type checker, the framework • guides the implementation of what is required • forbids anything not specified in the design different than what is proposed 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 publish MotionSensor } } 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 publish MotionSensor } } 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 publish MotionSensor } } 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 publish MotionSensor } } 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 publish MotionSensor } } abstract class AbstractPresence { abstract boolean onMotionFromMotionSensor( boolean motion, Select select); } 47
- 83. Implementing the Behavior context 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 presence when 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 Selection Required when an entity is the interaction’s target Guide the developer with an embedded and type-safe DSL 50
- 86. Entity Selection entity 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 3 entity 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 Entities entity Alarm { action OnOff { action OnOff; on(); } off(); } room = 0 room = 4 Triggering all alarms: select.alarms().all().on(); 53
- 89. Entity Selection Conformance entity 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 Selection context 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 Behavior context 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. Summary The developer is guided with • a support dedicated to the application • an embedded DSL for entity selection Conformance is ensured by Conformance • generating a programming framework • leveraging a GPL type checker 57
- 93. Contributions 1. A paradigm-specific design framework 2. A programming framework dedicated to a design 3. An evaluation of the approach 58
- 94. Evaluation of the Approach • Expressiveness • Usability • Productivity 59
- 95. Evaluation: Expressiveness Numerous domains • home-automation • avionics • graphical user interfaces • health-care • telecommunications • tier-system monitoring • etc. 60
- 96. Evaluation: Usability Context • 80 students during 3 years • sparse and oral-only documentation Results • 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 code We used the Sonar platform to measure code quality through 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 complexity 1 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 quality Pursuing this evaluation with software engineers 65
- 107. Results Scientific 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 Vehicle This design language and code generator are part of a research 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 Vehicle 7 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
Notes de l'éditeur
- \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&#x2019;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