PhD Thesis Defense

1,937 views
1,794 views

Published on

The vision of Autonomic Computing and Self-Adaptive Software Systems aims at realizing software that autonomously manage itself in presence of varying environmental conditions. Feedback Control Loops (FCL) provide generic mechanisms for self-adaptation, however, incorporating them into software systems raises many challenges.

The first part of this thesis addresses the integration challenge, i.e., forming the architecture connection between the underlying adaptable software and the adaptation engine. We propose a domain-specific modeling language, FCDL, for integrating adaptation mechanisms into software systems through external FCLs. It raises the level of abstraction, making FCLs amenable to automated analysis and implementation code synthesis. The language supports composition, distribution and reflection thereby enabling coordination and composition of multiple distributed FCLs. Its use is facilitated by a modeling environment, ACTRESS, that provides support for modeling, verification and complete code generation. The suitability of our approach is illustrated on three real-world adaptation scenarios.

The second part of this thesis focuses on model manipulation as the underlying facility for implementing ACTRESS. We propose an internal Domain-Specific Language (DSL) approach whereby Scala is used to implement a family of DSLs, SIGMA, for model consistency checking and model transformations. The DSLs have similar expressiveness and features to existing approaches, while leveraging Scala versatility, performance and tool support.

To conclude this thesis we discuss further work and further research directions for MDE applications to self-adaptive software systems.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,937
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PhD Thesis Defense

  1. 1. Domain-Specific Modeling Language for Self-Adaptive Software System Architectures Filip Křikava PhD defense Advisors: Philippe Collet and Johan Montagnat CNRS, University of Nice Sophia Antipolis, I3S Laboratory, MODALIS research group November 22, 2013, Sophia Antipolis
  2. 2. Context and Motivation Electronic Retailer - Application Diagram Jeff Kephart - Autonomic Computing: The First Decade, ICAC’11 keynote • • • Ever growing complexity of computing systems Taming this complexity by skilled IT professionals does not scale New operation modes are needed 2
  3. 3. Towards Self-Adaptive Software Systems • Towards Self-Adaptive Software Systems • Realizing system that adjusts themselves in accordance with some higher-level goals 3
  4. 4. Towards Self-Adaptive Software Systems • Towards Self-Adaptive Software Systems • Realizing system that adjusts themselves in accordance with some higher-level goals measures Monitoring events decisions Decision Making Reconfiguration sensors effectors Target System Feedback Control Loop (FCL) 3 actions
  5. 5. Challenges Engineering of self-adaptive software systems is a challenge CONFIGURATIONS API AOP + Controller - ⇥( N ) Target System COMMANDS Transduc er = µ = m d µ d= = m (N )µ m X i=1 PROFILER 1 m = d d LOGS Designing an adaptation engine Integrating the adaptation engine into the target system 4
  6. 6. Challenges Engineering of self-adaptive software systems is a challenge CONFIGURATIONS API AOP + Controller - ⇥( N ) Target System COMMANDS Transduc er = µ = m d µ d= = m (N )µ m X i=1 PROFILER 1 m = d d LOGS Designing an adaptation engine Integrating the adaptation engine into the target system 4
  7. 7. Challenges CONFIGURATIONS API AOP + Controller - ⇥( N ) Target System COMMANDS Transduc er = µ = m d µ d= = m (N )µ m X i=1 1 m = d d Integrating the adaptation engine into the target system Adaptation Engine LOGS Target System Adhoc Implementations • • • PROFILER Extensive handcrafting of non-trivial code Cumbersome and error-prone Accidental complexities 5
  8. 8. Challenges CONFIGURATIONS API AOP + Controller - ⇥( N ) Target System COMMANDS Transduc er = µ = m d µ d= = m (N )µ m X i=1 1 m = d d Integrating the adaptation engine into the target system Adaptation Engine PROFILER LOGS Target System Reusing and adapting existing work • • • • • Often target specific types of adaptation problems (Bertran’12) Require the use of certain adaptation mechanism (Garlan’04) Applicable to single domain (Rouvoy’08) or technology (Asadollahi’09) Do not support remoting or complex control schemes (Adamczyk’08, Gorton’06) Limiting their applicability 6
  9. 9. Requirements Identified requirements for integrating self-adaptation into software systems Generality • • Visibility • • Domain-agnostic Technology-agnostic Reusability • Reusable FCL parts across adaptation scenarios 7 Explicit FCLs, their process and interactions Verification support
  10. 10. Requirements Identified requirements for integrating self-adaptation into software systems Generality • • Visibility • • Domain-agnostic Technology-agnostic Reusability • Distribution Reusable FCL parts across adaptation scenarios Complex control • • Explicit FCLs, their process and interactions Verification support Composition Reflection 7 • Remote distribution of FCL
  11. 11. Requirements Identified requirements for integrating self-adaptation into software systems Generality • • Visibility • • Domain-agnostic Technology-agnostic Reusability • Distribution Reusable FCL parts across adaptation scenarios Complex control • • Explicit FCLs, their process and interactions Verification support • Remote distribution of FCL Tooling • • Composition Reflection Lightweight approach 7 Prototyping Automating
  12. 12. Objectives “ Provide an approach to facilitate systematic integration of self-adaptive mechanisms into software systems through feedback control loops. ” 8
  13. 13. Contributions Integrating the adaptation engine into the target system CONFIGURATIONS API AOP + Controller - ⇥( N ) measures Target System decisions Decision Making COMMANDS Transduc er = µ = m d µ d= = m (N )µ PROFILER Monitoring m X1 i=1 m = d d Reconfiguration LOGS events sensors effectors actions Target System Contributions Feedback Control Definition Language Generality Visibility Reusability Distribution Complex control Facilitates language use The ACTRESS Modeling Environment Tooling The SIGMA Model Manipulation Languages Lightweight approach 9 Facilitates tooling implementation
  14. 14. Plan 1. Feedback Control Definition Language 2. The ACTRESS Modeling Environment 3. The Sigma Model Manipulation Languages 4. Conclusions and Perspectives 10
  15. 15. Plan 1. Feedback Control Definition Language 2. The ACTRESS Modeling Environment 3. The Sigma Model Manipulation Languages 4. Conclusions and Perspectives 11
  16. 16. Feedback Control Definition Language 1. Raise the level of abstraction Generality Visibility Reusability General Purpose Language (GPL) 2. Fine-grained decomposition of FCL elements Monitoring Decision Making Reconfiguration 3. Explicit interactions measures decisions events Complex control actions 4. Provide reflection and composition capabilities 5. Embed remoting Distribution 12
  17. 17. Feedback Control Definition Language 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements Domain-Specific Modeling 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting 13
  18. 18. Feedback Control Definition Language 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements Domain-Specific Modeling 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting measures Decision Making Monitoring events decisions Reconfiguration sensors effectors actions 13
  19. 19. Feedback Control Definition Language 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements Domain-Specific Modeling 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting measures Decision Making Monitoring events • decisions Reconfiguration sensors effectors actions Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic 13
  20. 20. Feedback Control Definition Language 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements Domain-Specific Modeling 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting actor measures Decision Making Monitoring events • decisions actor Reconfiguration sensors effectors actor actions • Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic The Actor Model • Network of actors communicating via • • • • 13 message passing Message x State -> Message(s) Reactive Concurrent Dynamic
  21. 21. Feedback Control Definition Language actor actor measures Decision Making Monitoring events • actor decisions • Reconfiguration sensors effectors The Actor Model • Network of actors communicating via • • • • • • • • actions Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic 14 message passing Message x State -> Message(s) Reactive Concurrent Dynamic Thread safe Scalable Remoting support Programming support
  22. 22. Feedback Control Definition Language - Adaptive Element measures Monitoring events decisions Decision Making Reconfiguration sensors effectors actions in input out output Controller Processor out output in input in input Processor out output in input out output Effector Sensor Target System 15
  23. 23. Feedback Control Definition Language - Adaptive Element measures Monitoring events decisions Decision Making Reconfiguration sensors effectors actions out output in input providedSensor providedEffector in input out output Controller Processor out output in input in input Processor out output in input out output Effector Sensor Target System 15
  24. 24. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation • • • Typical example of a control-based solution to a well-known and well-scoped problem Design of a sophisticated control mechanisms Integration left for adhoc implementation 16
  25. 25. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) Abdelzaher et al., 1999, 2002 17
  26. 26. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality Abdelzaher et al., 1999, 2002 17
  27. 27. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality d n loa rmal o over load Abdelzaher et al., 1999, 2002 17
  28. 28. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality d n loa rmal o over load serve from tree #2 serve from tree #1 Rejection Level ... Minimum Content Full Content Abdelzaher et al., 1999, 2002 17
  29. 29. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality d n loa rmal o over load serve from tree #2 serve from tree #1 Rejection Level ... Minimum Content Full Content Abdelzaher et al., 1999, 2002 17
  30. 30. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality d n loa rmal o over load serve from tree #2 Using FCDL serve from tree #1 Generality Visibility Reusability Rejection Level ... Minimum Content Full Content Abdelzaher et al., 1999, 2002 17
  31. 31. Feedback Control Definition Language - Illustration QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Idea: service time = fixed overhead + data-size dependent overhead Prerequisite: preprocessed content (different quality and size) /photo.jpg /1/photo.jpg full quality /2/photo.jpg degraded quality d n loa rmal o over load serve from tree #2 Using FCDL serve from tree #1 Generality Rejection Level Visibility Distribution Reusability Complex control ... Minimum Content Full Content Abdelzaher et al., 1999, 2002 17
  32. 32. Feedback Control Definition Language - Illustration 1. Compute the number of requests (r) and size of responses (w) 2. Compute the requests rate (R), bandwidth (W) and utilization (U) 3. Compute severity of adaptation (G) 18
  33. 33. Feedback Control Definition Language - Illustration 1. Compute the number of requests (r) and size of responses (w) processor Accumulator { push in port input: long pull out port sum: long } out sum out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input out requests accessLogParser : AccessLogParser processor AccessLogParser { push in port lines: String push out port size: int push out port requests: int } out size in lines out lines file=/var/log/apache2/access.log accessLog : FileTailer Generality active sensor FileTailer { push out port lines: String Visibility } Reusability access_log 19 property file: String
  34. 34. Feedback Control Definition Language - Illustration 2. Compute the requests rate (R), bandwidth (W) and utilization (U) loadMonitor : LoadMonitor scheduler : PeriodTrigger out utilization in requests out output in input in size initialPeriod=10s out sum out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input out requests accessLogParser : AccessLogParser out size active processor PeriodTrigger<T> { pull in port input: T push out port output: T in lines out lines file=/var/log/apache2/access_log accessLog : FileTailer } Generality Visibility Reusability access_log 20 property initialPeriod = 10.seconds
  35. 35. Feedback Control Definition Language - Illustration 3. Compute severity of adaptation (G) loadMonitor : LoadMonitor scheduler : PeriodTrigger out utilization in requests utilController : UtilizationController out output in input in size in utilization out contentTree initialPeriod=10s out sum k=? U*=? out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input out requests accessLogParser : AccessLogParser out size in lines in contentTree out lines file=/var/log/apache2/access_log accessLog : FileTailer adaptor : ContentAdaptor Generality Visibility Reusability content_tree access_log 21
  36. 36. Feedback Control Definition Language - Illustration Complete model of the first prototype composite ApacheQOS { control layer ApacheQOS loadMonitor : LoadMonitor scheduler : PeriodTrigger out utilization in requests out output in input in size k=? U*=? in utilization out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input in input out requests system layer feature feature feature feature feature feature feature out contentTree initialPeriod=10s out sum feature accessLog = new FileTailer { file = “/var/log/apache2/access_log” } utilController : UtilizationController accessLogParser : AccessLogParser file=/var/log/apache2/access_log connect accessLog.lines to accessLogParser.lines connect accessLogParser.size to responseSizeCounter.input connect accessLogParser.requests to requestsCounter.input connect requestCounter.output to loadMonitor.requests connect responseSizeCounter.output to loadMonitor.size connect loadMonitor.utilization to scheduler.input connect scheduler.output to utilController.utilization connect utilController.contentTree to adaptor.contentTree out size in lines in contentTree out lines accessLog : FileTailer adaptor : ContentAdaptor } Generality Visibility Reusability 22 accessLogParser = new AccessLogParser requestCounter = new Accumulator responseSizeCounter = new Accumulator loadMonitor = new LoadMonitor scheduler = new PeriodTrigger<Double> utilController = new UtilizationController adaptor = new ContentAdaptor
  37. 37. Feedback Control Definition Language - Composition Hierarchical organization of Adaptive Elements using composites ApacheQOS composite name loadMonitor : LoadMonitor initialPeriod=10s out utilization control layer utilController : UtilizationController in requests out output in input in size in utilization out contentTree scheduler : PeriodTrigger out sum k=? U*=? out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input in input system layer out size in contentTree out requests composite ApacheWebServer { ApacheWebServer out size property accessLogFile: String ! accessLogParser : AccessLogParser out requests in lines in contentTree out lines port promotion accessLog : FileTailer adaptor : ContentAdaptor feature accessLog = new FileTailer { file = accessLogFile } in contentTree out requests out size server : ApacheWebServer feature accessLogParser = new AccessLogParser feature adaptor = new ContentAdaptor ! connect accessLog.lines to accessLogParser.lines file=/var/log/apache2/access_log Generality Visibility promote accessLogParser.size promote accessLogParser.requests promote adaptor.contentTree! Reusability } 23
  38. 38. Feedback Control Definition Language - Composition QOSControl QOSControl utilization : UtilizationMonitor out utilization in size in requests in utilization in input out output scheduler : PeriodTrigger utilController : UtilizationController out utilization in utilization in input in requests utilization : UtilizationMonitor utilController : UtilizationController in requests out contentTree in size in size scheduler : PeriodTrigger ApacheQOS out contentTree LighttpdQOS in requests in requests out contentTree control layer control layer out contentTree in size control : QOSControl in size control : QOSControl out size system layer system layer out size out requests out contentTree in size in requests out contentTree out output in contentTree apache : ApacheWebServer Generality Visibility Reusability 24 out requests in contentTree lighttpd : LighttpdWebServer
  39. 39. Feedback Control Definition Language - Distribution Distribution Visibility Remote Distribution of Adaptive Elements Apache ApacheQOS endpoint=akka.tcp://actress@remote-main/user/ApacheQOS/control in requests in requests out contentTree in size out contentTree control : QOSControl ApacheQOS.control in size referenced feature composite out size out requests feature out size in contentTree out requests Apache.apache in contentTree apache: ApacheWebServer endpoint= akka.tcp://actress@remote-apache/user/Apache/apache network remote-main remote-apache // deployed at remote-apache composite Apache { feature apache = new ApacheWebServer { ... } feature control = ref ApacheQOS.control @ "akka://remote-main/user/ApacheQOS/control" } // deployed at host remote-main composite ApacheQOS { feature control = new QOSControl { ... } feature apache = ref Apache.apache @ "akka://remote-apache/user/Apache/apache" // ... } 25
  40. 40. Feedback Control Definition Language - Reflection Adaptive Element Reflection Complex control meta-control layer ApacheQOS in load Visibility periodController : PeriodController provided in setPeriod QOSControl provided in setPeriod out output control layer out period in requests out contentTree sysLoadTrigger : PeriodTrigger in size in input control : QOSControl setPeriod promotion system layer out output out size out requests sysLoad : SystemLoad ... in contentTree provided effector in input out output ... scheduler : PeriodTrigger apache : ApacheWebServer active processor PeriodicTrigger<T> { pull in port input: T push out port output: T provided effector setPeriod: Long } property initialPeriod = 10.seconds composite QOSControl { // ... promote scheduler.setPeriod // ... } 26
  41. 41. Feedback Control Definition Language - Reflection Complex control Adaptive Monitoring Pattern Visibility meta-control layer ApacheQOS in load Reusability out period periodControl : AdaptiveMonitoring provided in setPeriod QOSControl provided in setPeriod in requests control layer out contentTree in size control : QOSControl setPeriod promotion system layer out output out size out requests sysLoad : SystemLoad in contentTree ... provided effector in input out output scheduler : PeriodTrigger apache : ApacheWebServer 27 ...
  42. 42. Feedback Control Definition Language - Interaction Contracts out sum in input : Accumulator • • Activated on input push request Activated on sum pull request 28
  43. 43. Feedback Control Definition Language - Interaction Contracts in reset out sum in input out output : Accumulator • • • • • • • Activated on input push request Activated on reset push request Activated on input / reset request Activated on sum pull request Activated on input push request always pushing data on output Activated on reset push request always pushing data on output .... 29
  44. 44. Feedback Control Definition Language - Interaction Contracts When it receives data on its input port, it pushes to its output port the input value plus the sum of all the input values it has received since the last time the reset port was triggered, similarly, when pulled on the sum port, it returns the sum of all the input values since the last reset, and finally receiving any data on its reset port, sets the current accumulated value back to 0. if (!input.isEmpty()) { value += input.get output.send(value) } else if (!reset.isEmpty()) { reset.get() value = 0 } else if (!sum.isEmpty()) { sum.send(value) } else { throw new IllegalStateException("Invalid execution") } in reset out sum in input out output : Accumulator • • • Behavior not explicitly stated in the architecture - Black Box Limits verification support Limits code-generation support 30
  45. 45. Feedback Control Definition Language - Interaction Contracts Interaction Contracts Visibility Describe allowed interactions among components in reset out sum in input processor Accumulator { push in port reset: int push in port input: long pull out port sum: long push out port output: long out output : Accumulator 31 } act onInput(input; ; output) act onSum(sum; ; ) act onReset(reset; ; )
  46. 46. Feedback Control Definition Language - Interaction Contracts Interaction Contracts Visibility Describe allowed interactions among components in reset out sum in input processor Accumulator { push in port reset: int push in port input: long pull out port sum: long push out port output: long out output : Accumulator } act onInput(input; ; output) act onSum(sum; ; ) act onReset(reset; ; ) Originally developed by Cassou et al. for SCC systems • Our extensions • • • • • • Elements with multiple output ports Multiple port connections Composites Composite interaction contract inference algorithm Optional contracts Completion verification algorithm 31
  47. 47. Plan 1. Feedback Control Definition Language 2. The ACTRESS Modeling Environment 3. The Sigma Model Manipulation Languages 4. Conclusions and Perspectives 32
  48. 48. ACTRESS Overview The ACTRESS Modeling Environment • • Reference implementation of FCDL based on Eclipse Modeling Framework Facilitate the use of FCDL Modeling Code Generation Verification Tooling 33
  49. 49. ACTRESS - Modeling Support xFCDL (Extended FCDL) • • • utilController : UtilizationController Textual DSL for authoring FCDL models Additionally supports • Modularity • Java interoperability • Implementation specification using Xbase Eclipse IDE support in utilization k=? U*=? out contentTree controller UtilizationController { // ... // interaction contract act activate(utilization; ; contentTree) // beginning of Xbase implementation implementation xbase { var G = M // interaction contract act activate { // computes the error val E = targetUtilization - utilization // computes new extend of adaptation G = G + k * E // correct bounds if (G < 0) G = 0 if (G > M) G = M } 34 } // returns the result G
  50. 50. ACTRESS - Code Generation Support ApacheQOS loadMonitor : LoadMonitor out utilization in requests utilController : UtilizationController initialPeriod=10s out output in input in size in utilization scheduler : PeriodTrigger out sum out sum responseSizeCounter : Accumulator requestCounter : Accumulator in input k=? U*=? out contentTree FCDL Model in input out size out requests in contentTree server : ApacheWebServer Model-to-Text transformation ACTRESS Domain Framework Code generator Xbase compiled to Java Skeleton implementation ACTRESS Runtime ApacheQOS apache control utilization accessLogParser accessLog adaptor scheduler composite actor containment actor actor with event listener responseSizeCounter message passing requestCounter loadMonitor Executable System 35 utilController
  51. 51. ACTRESS - Code Generation Support Skeleton Implementation utilController : UtilizationController in utilization @SuppressWarnings("all") public class UtilizationControllerAct extends AdaptiveElementAct { // ... k=? U*=? protected double activate(final double utilization) { // TODO: compute and output value for contentTree port } out contentTree // ... } Prescriptive Descriptive Visibility 36
  52. 52. ACTRESS - Verification Support FCDL Verification 37
  53. 53. ACTRESS - Verification Support Model Well-Formedness • • • • Data-type compatibility Port connections Required properties and others meta-model constraints (SIGMA) FCDL Verification 37
  54. 54. ACTRESS - Verification Support Model Well-Formedness • • • • Architecture Data-type compatibility Port connections Required properties and others meta-model constraints (SIGMA) • • • FCDL Verification 37 Consistency Determinacy Completeness interaction contracts verification (SIGMA)
  55. 55. ACTRESS - Verification Support Model Well-Formedness • • • • Architecture Data-type compatibility Port connections Required properties and others meta-model constraints (SIGMA) • • • FCDL Verification User Structural Constraints @OCL(invDifferentSource="self.ports ->select(p | p.name = 'size' || p.name = 'requests') // select ports ->collect(p | p.connections) // select their connects ->collect(p | p.parent) // select owning instances ->asSet()->size() == 2 // there must be two different ones ") processor LoadMonitor { xFCDL OCL Annotations 37 Consistency Determinacy Completeness interaction contracts verification (SIGMA)
  56. 56. ACTRESS - Verification Support Model Well-Formedness • • • • Architecture Data-type compatibility Port connections Required properties and others meta-model constraints (SIGMA) • • • Consistency Determinacy Completeness interaction contracts verification (SIGMA) FCDL Verification User Structural Constraints @OCL(invDifferentSource="self.ports ->select(p | p.name = 'size' || p.name = 'requests') // select ports ->collect(p | p.connections) // select their connects ->collect(p | p.parent) // select owning instances ->asSet()->size() == 2 // there must be two different ones ") processor LoadMonitor { xFCDL OCL Annotations ( User Temporal Constraints activate → (♦ FCDL to PROMELA activate transformation SPIN model checker 37 activate )) ac
  57. 57. ACTRESS Evaluation Case Study 1 DAGMan 1 DAGMan 2 ... Users Submit jobs User Interface Spawns Submit workflows Executes schedd DAGMan N HTCondor Client Host HTCondor cluster of worker nodes 38
  58. 58. ACTRESS Evaluation Case Study 1 DAGMan 1 User Interface DAGMan 2 ... Users Submit jobs Spawns Submit workflows Executes schedd DAGMan N HTCondor Client Host HTCondor cluster of worker nodes Case Study 2 User Interface 1 Users Submit Submit jobs workflows Users Users Executes User Interface 2 Central schedd ... HTCondor cluster of worker nodes User Interface N 38
  59. 59. FCDL / ACTRESS Evaluation Generality • • • • Visibility Potentially any self-* property FCDL is technology agnostic xFCDL with Xbase depends on Java ACTRESS runtime depends on Java • • • Reusability • Reused elements across scenarios 39 Explicit FCLs Explicit AE Explicit AE interactions
  60. 60. FCDL / ACTRESS Evaluation Generality • • • • Visibility Potentially any self-* property N ∗ = 1000, FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10 xFCDL with Xbase depends on Java ACTRESS runtime depends on Java • • • Explicit FCLs Explicit AE Explicit AE interactions Reusability • Reused elements across scenarios Reuse 1 2 1 2 39
  61. 61. FCDL / ACTRESS Evaluation Generality • • • • Visibility Potentially any self-* property N ∗ = 1000, FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10 xFCDL with Xbase depends on Java ACTRESS runtime depends on Java • • • Reusability • Distribution Reused elements across scenarios • Complex control • Explicit FCLs Explicit AE Explicit AE interactions Case Study 2 deployed on 10 Grid5000 hosts Tooling • All case studies use hierarchical control Eclipse based modeling environment Reuse 1 2 1 2 39
  62. 62. FCDL / ACTRESS Evaluation Generality • • • • Visibility Potentially any self-* property N ∗ = 1000, FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10 xFCDL with Xbase depends on Java ACTRESS runtime depends on Java • • • Reusability • Distribution Reused elements across scenarios • Complex control • Explicit FCLs Explicit AE Explicit AE interactions Case Study 2 deployed on 10 Grid5000 hosts Tooling • All case studies use hierarchical control Eclipse based modeling environment Overall implementation effort 1 2 1 2 40
  63. 63. FCDL / ACTRESS Evaluation Generality • • • • Visibility Potentially any self-* property N ∗ = 1000, Nc = 5000, FCDL is technology agnostic p = 5, ρ0 = 10 xFCDL with Xbase depends on Java ACTRESS runtime depends on Java • • • Reusability • Distribution Reused elements across scenarios • Complex control • Explicit FCLs Explicit AE Explicit AE interactions Case Study 2 deployed on 10 Grid5000 hosts Tooling • All case studies use hierarchical control Eclipse based modeling environment Overall implementation effort 1 Separation of concerns 2 1 2 41
  64. 64. Plan 1. Feedback Control Definition Language 2. The ACTRESS Modeling Environment 3. The Sigma Model Manipulation Languages 4. Conclusions and Perspectives 42
  65. 65. SIGMA ACTRESS Modeling Environment Model Manipulation Model Consistency Checking Model Transformations Eclipse Modeling Framework (EMF) 43
  66. 66. SIGMA ACTRESS Modeling Environment Model Manipulation Model Consistency Checking Model Transformations Eclipse Modeling Framework (EMF) GPL • • • Low level of abstraction Limited expressiveness Accidental complexities 43
  67. 67. SIGMA ACTRESS Modeling Environment Model Manipulation Model Consistency Checking Model Transformations Eclipse Modeling Framework (EMF) GPL • • • External DSLs • • • • • Low level of abstraction Limited expressiveness Accidental complexities 43 Limited tool support Limited versatility Limited interoperability Limited testability Accidental complexities
  68. 68. SIGMA ACTRESS Modeling Environment Model Manipulation Model Consistency Checking Model Transformations Eclipse Modeling Framework (EMF) GPL • • • Low level of abstraction Limited expressiveness Accidental complexities Internal DSLs • • • • • Internal DSLs in Scala for model manipulation Embeds domain-specific constructs into a GPL Small API Efficient Directly reuse the host language infrastructure SIGMA Lightweight approach 43 External DSLs • • • • • Limited tool support Limited versatility Limited interoperability Limited testability Accidental complexities
  69. 69. SIGMA Quick Example Check that all instances within a composite have unique names
  70. 70. SIGMA Quick Example Check that all instances within a composite have unique names OCL invariant UniqueNamesWithinType: parent.allFeatures->forAll(e | e <> self implies e.name <> self.name);
  71. 71. SIGMA Quick Example Check that all instances within a composite have unique names OCL invariant UniqueNamesWithinType: parent.allFeatures->forAll(e | e <> self implies e.name <> self.name); SIGMA def invUniqueNamesWithinType = self.parent.allFeatures forall (e => e != self implies e.name != self.name)
  72. 72. SIGMA Quick Example Check that all instances within a composite have unique names OCL invariant UniqueNamesWithinType: parent.allFeatures->forAll(e | e <> self implies e.name <> self.name); SIGMA def invUniqueNamesWithinType = self.parent.allFeatures forall (e => e != self implies e.name != self.name) • • • Similar expressiveness Easy to edit Easy to test • • Easy to debug Easy to integrate into model manipulation workflow
  73. 73. SIGMA Quick Example Check that all instances within a composite have unique names OCL invariant UniqueNamesWithinType: parent.allFeatures->forAll(e | e <> self implies e.name <> self.name); SIGMA def invUniqueNamesWithinType = self.parent.allFeatures forall (e => e != self implies e.name != self.name) • • • Similar expressiveness Easy to edit • • Easy to test Easy to debug Easy to integrate into model manipulation workflow def invUniqueNamesWithinType = self.parent.allFeatures find (e => e != self && e.name == self.name) match { case None => Passed case Some(e) => Error(s”Element $e has the name”) .quickFix(“Rename ‘${self.name}’ to ‘${self.name}’_2”) { self.name += “_2” } } • • Different levels of severity User feedback • • Inconsistency repair and more
  74. 74. SIGMA Architecture Requirements SIGMA • Tool support • Expressiveness • Usability • Model-to-Text Transformation Model-to-Model Transformation Task-specific DSLs Testability Model Consistency Checking Model Navigation Model Modification SIGMA EMF bridge Scala Eclipse Modeling Framework (EMF) ANR-09-SEGI-012 ANR EMERGENCE 45 Common Infrastructure
  75. 75. Plan 1. Feedback Control Definition Language 2. The ACTRESS Modeling Environment 3. The Sigma Model Manipulation Languages 4. Conclusions and Perspectives 46
  76. 76. Summary • Combining self-adaptive software systems with principles of MDE to provide systematic and tooled approach for integrating control mechanisms into software applications. • Design of a domain-specific modeling language for defining complex feedback control loop architectures on a flexible, high level of abstraction. • A reference implementation and tools facilitating the language use including modeling, code synthesis and verification support. • A family of internal DSLs in Scala for lightweight model manipulations including model consistency checking, model transformations. 47
  77. 77. Summary • Combining self-adaptive software systems with principles of MDE to provide systematic and tooled approach for integrating control mechanisms into software applications. • Design of a domain-specific modeling language for defining complex feedback control loop architectures on a flexible, high level of abstraction. • A reference implementation and tools facilitating the language use including modeling, code synthesis and verification support. • A family of internal DSLs in Scala for lightweight model manipulations including model consistency checking, model transformations. • Materialized in 2 software stacks • The ACTRESS Modeling Environment http://fikovnik.github.io/Actress • The SIGMA Model Manipulation DSLs http://fikovnik.github.io/Sigma 47
  78. 78. Perspectives Short-term further work • • Improvements in both ACTRESS and SIGMA implementations Extend the validation on more use cases, gather more experience Further Research Directions • On Self-Adaptive Software Systems • • • • Towards Higher-Level Abstractions Towards Model@run.time Towards DSL composition On Model Manipulations • • • Towards deep DSL embedding Towards domain-specific optimization and error checking Taming the leaking abstraction of internal DSLs 48
  79. 79. Merci! • P. Collet, F. Křikava, J. Montagnat, M. Blay-Fornarino, D. Manset. Issues and Scenarios for SelfManaging Grid Middleware, Workshop on Grids meets autonomic computing (GMAC '10), 2010 • F. Křikava, P. Collet, M. Blay-Fornarino. Uniform and Model-Driven Engineering of Feedback Control Systems, International Conference on Autonomic Computing (ICAC'11), 2011 short paper • F. Křikava, P. Collet. A Reflective Model for Architecting Feedback Control Systems, International Conference on Software Engineering and Knowledge Engineering (SEKE'11), 2011 • F. Křikava, P. Collet. On the Use of an Internal DSL for Enriching EMF Models, Workshop on OCL and Textual Modelling (OCL'12), 2012 • F. Křikava, P. Collet, R. France. Actor-based Runtime Model of Adaptable Feedback Control Loops, Workshop on models@run.time (MRT'12), 2012 • F. Křikava, P. Collet, R. France. ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures, International Conference on Dependable and Adaptive Distributed Systems, SAC’14 (to appear) • F. Křikava, P. Collet, R. France. Exploring Internal Domain-Specific Languages for Model Manipulations, International Conference on Programing Languages, SAC’14, short paper (to appear) SIGMA model manipulation DSLs have been also presented at: • • EclipseCon Europe 2012 Modeling Symposium − Enriching EMF Models with Scala, Ludwigsburg, Germany Scala Workshop 2013 − Model Manipulation Using Embedded DSLs in Scala, Montpellier, France 49

×