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.

ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

994 views

Published on

Presentation given at 29th Symposium On Applied Computing (SAC'14) - Dependable and Adaptive Distributed Systems track.

It is mainly based on the work done during my Ph.D.

Published in: Software, Technology
  • I pasted a website that might be helpful to you: ⇒ www.HelpWriting.net ⇐ Good luck!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • To get professional research papers you must go for experts like ⇒ www.WritePaper.info ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

  1. 1. ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures SAC’14 - DADS 28.3.2014 Philippe Collet Robert B. France Colorado State University
 Computer Science Department USA Université Nice Sophia Antipolis I3S - CNRS UMR 7271
 France University Lille 1 / LIFL
 INRIA Lille
 France Filip Křikava
  2. 2. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures CONTEXT Jeff Kephart - Autonomic Computing: The First Decade, ICAC’11 keynote Electronic Retailer - Application Diagram • Ever growing complexity of computing systems • Taming this complexity by skilled IT professionals does not scale • New operation modes are needed
  3. 3. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures TOWARDS SELF-ADAPTIVE SOFTWARE SYSTEMS Monitoring Reconfiguration Decision Making sensors effectors Target System events actions measures decisions Feedback Control Loop (FCL) Systems that adjust themselves in accordance with some higher-level goals • response time • utilization • scheduling • concurrency policies
  4. 4. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Engineering of self-adaptive software systems is a challenge Designing an adaptation engine Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ CHALLENGES
  5. 5. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Engineering of self-adaptive software systems is a challenge Designing an adaptation engine Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ CHALLENGES Integrating an adaptation engine into a target system API LOGS CONFIGURATIONS COMMANDS AOP PROFILER • Consistent monitoring across all sensors • Coordination of adaptation action
  6. 6. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Engineering of self-adaptive software systems is a challenge Designing an adaptation engine Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ CHALLENGES Integrating an adaptation engine into a target system API LOGS CONFIGURATIONS COMMANDS AOP PROFILER • Consistent monitoring across all sensors • Coordination of adaptation action
  7. 7. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Integrating an adaptation engine into a target system Adaptation Engine Target System Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ API LOGS CONFIGURATIONS COMMANDS AOP PROFILER • Adhoc Implementations • Extensive handcrafting of non-trivial code • Cumbersome and error-prone • Accidental complexities CHALLENGES
  8. 8. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Integrating an adaptation engine into a target system Adaptation Engine Target System Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ API LOGS CONFIGURATIONS COMMANDS AOP PROFILER • 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 CHALLENGES
  9. 9. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Derived requirements for integrating self-adaptation into software systems Generality • Domain-agnostic • Technology-agnostic • Explicit FCLs, their process and interactions • Verification support Visibility • Reusable FCL parts across adaptation scenarios Reusability • Remote distribution of FCL Distribution • Composition • Reflection Complex control • Prototyping • Automating Tooling REQUIREMENTS
  10. 10. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Monitoring Reconfiguration Decision Making sensors effectors Target System events actions measures decisions Controller Target System Transduc er + - = mX i=1 1 d = m d ⇥(N) = µ = m d µ d = m (N)µ API LOGS CONFIGURATIONS COMMANDS AOP PROFILER Generality Visibility Reusability Distribution Complex control Tooling CONTRIBUTIONS Feedback Control Definition Language1 The ACTRESS Modeling Environment2 Approach facilitating systematic integration of self-adaptive mechanisms into software systems through feedback control loops.
  11. 11. 28.3.2014, SAC’14 - DADSACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures FCDL: Feedback Control Definition Language 1
  12. 12. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures FEEDBACK CONTROL DEFINITION LANGUAGE 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements 3. Explicit interactions 4. Provide reflection and composition capabilities 5. Embed remoting Monitoring Decision Making Reconfiguration measures events decisions actions General Purpose Language (GPL)Generality Visibility Reusability Distribution Complex control
  13. 13. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting Domain-Specific Modeling FEEDBACK CONTROL DEFINITION LANGUAGE
  14. 14. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting Domain-Specific Modeling • Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic Monitoring Reconfiguration Decision Making sensors effectorsevents actions measures decisions FEEDBACK CONTROL DEFINITION LANGUAGE
  15. 15. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures 1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting Domain-Specific Modeling • Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic Monitoring Reconfiguration Decision Making sensors effectorsevents actions measures decisions • The Actor Model • Message passing actor networks • Message x State -> Message(s) • Reactive • Concurrent • Dynamic • Scalable • Remoting through location transparency actor actor actor FEEDBACK CONTROL DEFINITION LANGUAGE
  16. 16. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Monitoring Reconfiguration Decision Making sensors effectorsevents actions measures decisions Processor in input out output Effector in input Sensor out output Target System in input Controller in input out output Processor out output FEEDBACK CONTROL DEFINITION LANGUAGE - IN A NUTSHELL Network of Adaptive Elements - actor-like entities
  17. 17. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Monitoring Reconfiguration Decision Making sensors effectorsevents actions measures decisions Processor in input out output Effector in input Sensor out output Target System in input Controller in input out output Processor out output in input providedEffectorprovidedSensor out output FEEDBACK CONTROL DEFINITION LANGUAGE - IN A NUTSHELL Network of Adaptive Elements - actor-like entities
  18. 18. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Idea: service time = fixed overhead + data-size dependent overhead Abdelzaher et al., 1999, 2002 QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value Prerequisite: preprocessed content (different quality and size) ILLUSTRATION
  19. 19. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Idea: service time = fixed overhead + data-size dependent overhead Abdelzaher et al., 1999, 2002 QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value /1/photo.jpg /2/photo.jpg /photo.jpg full quality degraded quality Prerequisite: preprocessed content (different quality and size) ILLUSTRATION
  20. 20. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Idea: service time = fixed overhead + data-size dependent overhead Abdelzaher et al., 1999, 2002 QoS management control of web servers by content delivery adaptation Goal: maintain server load around some pre-set value /1/photo.jpg /2/photo.jpg /photo.jpg full quality degraded quality normal load overload Prerequisite: preprocessed content (different quality and size) ILLUSTRATION
  21. 21. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Idea: service time = fixed overhead + data-size dependent overhead Abdelzaher et al., 1999, 2002 QoS management control of web servers by content delivery adaptation ... serve from tree #2 serve from tree #1 Rejection Level Minimum Content Full Content Goal: maintain server load around some pre-set value /1/photo.jpg /2/photo.jpg /photo.jpg full quality degraded quality normal load overload Prerequisite: preprocessed content (different quality and size) ILLUSTRATION
  22. 22. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Idea: service time = fixed overhead + data-size dependent overhead Abdelzaher et al., 1999, 2002 QoS management control of web servers by content delivery adaptation ... serve from tree #2 serve from tree #1 Rejection Level Minimum Content Full Content Goal: maintain server load around some pre-set value /1/photo.jpg /2/photo.jpg /photo.jpg full quality degraded quality normal load overload Prerequisite: preprocessed content (different quality and size) ILLUSTRATION Distribution Complex control Generality Visibility Reusability Using FCDL
  23. 23. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ILLUSTRATION Compute severity of adaptation (G) Compute the requests rate (R), bandwidth (W) and utilization (U) Compute the number of requests (r) and size of responses (w)1 2 3
  24. 24. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ILLUSTRATION Compute the number of requests (r) and size of responses (w)1 accessLog : FileTailer out lines file=/var/log/apache2/access.log access_log active sensor FileTailer { push out port lines: String ! property file: String } processor Accumulator { push in port input: long pull out port sum: long } processor AccessLogParser { push in port lines: String push out port size: int push out port requests: int } Generality Visibility Reusability requestCounter : Accumulator responseSizeCounter : Accumulator in input out sum out sum in lines out sizeout requests accessLogParser : AccessLogParser
  25. 25. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ILLUSTRATION Generality Visibility Reusability access_log active processor PeriodTrigger<T> { pull in port input: T push out port output: T ! property initialPeriod = 10.seconds } requestCounter : Accumulator responseSizeCounter : Accumulator scheduler : PeriodTrigger loadMonitor : LoadMonitor in input out sum out sum in requests in size out utilization in input out output initialPeriod=10s accessLog : FileTailer in lines out lines file=/var/log/apache2/access_log out sizeout requests accessLogParser : AccessLogParser Compute the requests rate (R), bandwidth (W) and utilization (U)2
  26. 26. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ILLUSTRATION Generality Visibility Reusability content_tree access_log utilController : UtilizationController requestCounter : Accumulator responseSizeCounter : Accumulator scheduler : PeriodTrigger loadMonitor : LoadMonitor in input out sum out sum in requests in size out utilization in input out output in utilization out contentTree initialPeriod=10s adaptor : ContentAdaptor in contentTree accessLog : FileTailer in lines out lines file=/var/log/apache2/access_log out sizeout requests accessLogParser : AccessLogParser k=? U*=? Compute severity of adaptation (G)3
  27. 27. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ILLUSTRATION GeneralityVisibilityReusability composite ApacheQOS { ! feature accessLog = new FileTailer { file = “/var/log/apache2/access_log” } ! feature accessLogParser = new AccessLogParser feature requestCounter = new Accumulator feature responseSizeCounter = new Accumulator feature loadMonitor = new LoadMonitor feature scheduler = new PeriodTrigger<Double> feature utilController = new UtilizationController feature adaptor = new ContentAdaptor ! 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 } Complete model of the first prototype ApacheQOS utilController : UtilizationController in input requestCounter : Accumulator responseSizeCounter : Accumulator scheduler : PeriodTrigger loadMonitor : LoadMonitor in input out sum out sum in requests in size out utilization in input out output in utilization out contentTree system layer control layer initialPeriod=10s adaptor : ContentAdaptor in contentTree accessLog : FileTailer in lines out lines file=/var/log/apache2/access_log out sizeout requests accessLogParser : AccessLogParser k=? U*=?
  28. 28. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures COMPOSITION Generality Visibility Reusability Hierarchical organization of Adaptive Elements using composites ApacheQOS utilController : UtilizationController in input requestCounter : Accumulator responseSizeCounter : Accumulator scheduler : PeriodTrigger loadMonitor : LoadMonitor in input out sum out sum in requests in size out utilization in input out output in utilization out contentTree out requests out size system layer control layer composite name initialPeriod=10s adaptor : ContentAdaptor outsize in contentTree out size outrequests out requests incontentTree port promotion in contentTree ApacheWebServer server : ApacheWebServer accessLog : FileTailer accessLogParser : AccessLogParser in lines out lines file=/var/log/apache2/access_log k=? U*=? composite ApacheWebServer { ! property accessLogFile: String feature accessLog = new FileTailer { file = accessLogFile } ! feature accessLogParser = new AccessLogParser feature adaptor = new ContentAdaptor connect accessLog.lines to accessLogParser.lines ! promote accessLogParser.size promote accessLogParser.requests promote adaptor.contentTree ! }
  29. 29. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ApacheQOS control : QOSControl in contentTree apache : ApacheWebServer in requests in size out requests out size out contentTree control layer system layer QOSControl utilController : UtilizationController utilization : UtilizationMonitor out contentTree scheduler : PeriodTrigger out utilization in input out output in utilization out contentTreein requests in size in requests in size LighttpdQOS control : QOSControl in contentTree lighttpd : LighttpdWebServer in requests in size out requests out size out contentTree control layer system layer QOSControl utilController : UtilizationController utilization : UtilizationMonitor out contentTree scheduler : PeriodTrigger out utilization in input out output in utilization out contentTreein requests in size in requests in size COMPOSITION Generality Visibility Reusability
  30. 30. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures REMOTE DISTRIBUTION Remote distribution of Adaptive Elements remote-main remote-apache network ApacheQOS in contentTree in requests in size out requests out size out contentTree Apache.apache endpoint= akka.tcp://actress@remote-apache/user/Apache/apache referenced feature Apache in contentTree in requests in size out requests out size out contentTree ApacheQOS.control endpoint=akka.tcp://actress@remote-main/user/ApacheQOS/control apache: ApacheWebServer control : QOSControl composite feature // 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" // ... } Distribution Visibility
  31. 31. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures REFLECTION Visibility ApacheQOS control layer sysLoad : SystemLoad meta-control layer periodController : PeriodController out output in load out period system layer sysLoadTrigger : PeriodTrigger in input out output in contentTree apache : ApacheWebServer in requests in size out requests out size out contentTree QOSControl scheduler : PeriodTrigger in input out output setPeriod provided in setPeriod ... ... provided effectorpromotion provided in setPeriod control : QOSControl 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 // ... } Complexcontrol
  32. 32. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Visibility Complexcontrol ApacheQOS control layer sysLoad : SystemLoad meta-control layer out output in load out period system layer in contentTree apache : ApacheWebServer in requests in size out requests out size out contentTree QOSControl scheduler : PeriodTrigger in input out output setPeriod provided in setPeriod ... ... provided effectorpromotion provided in setPeriod control : QOSControl periodControl : AdaptiveMonitoring REFLECTION - ADAPTIVE MONITORING Reusability
  33. 33. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures INTERACTION CONTRACTS in input : Accumulator out sum • Activated on input push request • Activated on sum pull request
  34. 34. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures INTERACTION CONTRACTS in input : Accumulator out sumin reset out output • 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 • ....
  35. 35. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures INTERACTION CONTRACTS in input : Accumulator out sumin reset out output • Behavior not explicitly stated in the architecture - Black Box • Limits verification support • Limits code-generation support 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") }
  36. 36. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures INTERACTION CONTRACTS in input : Accumulator out sumin reset out output • Describe allowed interactions among components Visibility • 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 processor Accumulator { push in port reset: int push in port input: long pull out port sum: long push out port output: long ! act onInput(input; ; output) act onSum(sum; ; ) act onReset(reset; ; ) }
  37. 37. 28.3.2014, SAC’14 - DADSACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures The ACTRESS Modeling Environment 2
  38. 38. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Modeling VerificationCode Generation Tooling • Reference implementation of FCDL based on Eclipse Modeling Framework • Facilitate the use of FCDL THE ACTRESS MODELING ENVIRONMENT
  39. 39. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ACTRESS - MODELING SUPPORT 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 // returns the result G } } • xFCDL (Extended FCDL) • Textual DSL for authoring FCDL models • Additionally supports • Modularity • Java interoperability • Implementation specification
 using Xbase • Eclipse IDE support utilController : UtilizationController in utilization out contentTree k=? U*=?
  40. 40. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ACTRESS - CODE GENERATION SUPPORT accessLogParser accessLog adaptor apache control requestCounter responseSizeCounter loadMonitor utilization scheduler utilController ApacheQOS ACTRESS Runtime actor actor with event listener composite actor containment message passing ApacheQOS utilController : UtilizationController in input requestCounter : Accumulator responseSizeCounter : Accumulator scheduler : PeriodTrigger loadMonitor : LoadMonitor in input out sum out sum in requests in size out utilization in input out output in utilization out contentTree out requests out size initialPeriod=10s in contentTree server : ApacheWebServer k=? U*=? Code generator Model-to-Text transformation ACTRESS Domain Framework FCDL Model Executable System • Xbase compiled to Java • Skeleton implementation
  41. 41. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ACTRESS - CODE GENERATION SUPPORT - SKELETON IMPLEMENTATION @SuppressWarnings("all") public class UtilizationControllerAct extends AdaptiveElementAct { ! // ... ! protected double activate(final double utilization) { // TODO: compute and output value for contentTree port } ! // ... ! } utilController : UtilizationController in utilization out contentTree k=? U*=? • Prescriptive • Restrictive Visibility
  42. 42. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ACTRESS - VERIFICATION SUPPORT • Architecture • Consistency • Determinacy • Completeness • Interaction contracts verification @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 { • User-defined structural constraints • xFCDL OCL annotations • User temporal constraints • FCDL to PROMELA transformation • SPIN model checker ⇤ ( accessLogParseractivate ! (⌃ utilControlleractivate)) FCDL Verification • Model well-formedness • Data-type compatibility • Port connections • Required properties • and others • Meta-model constraints
  43. 43. 28.3.2014, SAC’14 - DADSACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures Assessment and Summary 3
  44. 44. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ASSESSMENT • Illustration case study - running example • Additional case studies in the area of HTC computing • HTCondor Local Job Submission Overload Control • HTCondor Distributed Job Submission Overload Control c 0 1 2 1 2 Overall implementation effort Separation of concerns
  45. 45. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ASSESSMENT Generality Visibility Reusability • Reused elements across scenarios • Potentially any self-* property • Abstraction is close to block diagrams from control theory • Control complex schemes through reflection • FCDL is technology agnostic • xFCDL with Xbase depends on Java • ACTRESS runtime depends on Java Distribution Complex control • Case Study 2 deployed on 10 Grid5000 hosts • All case studies use hierarchical control • Eclipse based modeling environment • Model to code synthesis Tooling • Explicit FCLs • Explicit AE • Explicit AE interactions • Known concepts such as ports and composites • Higher-level of abstraction using control theory concepts
  46. 46. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures ASSESSMENT Generality Visibility Reusability • Reused elements across scenarios • Potentially any self-* property • Abstraction is close to block diagrams from control theory • Control complex schemes through reflection • FCDL is technology agnostic • xFCDL with Xbase depends on Java • ACTRESS runtime depends on Java Distribution Complex control • Case Study 2 deployed on 10 Grid5000 hosts • All case studies use hierarchical control • Eclipse based modeling environment • Model to code synthesis Tooling • Explicit FCLs • Explicit AE • Explicit AE interactions • Known concepts such as ports and composites • Higher-level of abstraction using control theory concepts • Performance1 • ACTRESS runtime accounts for ~1.5MB • AE accounts for 400 bytes • 5000 messages accounts for 5% of CPU utilization 1 MacBook Pro 2.53 Ghz Intel i5, 8GB RAM, Java 1.70_17, Akka 2.2.0
  47. 47. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures SUMMARY • Combining self-adaptive software systems with principles of MDE to provide systematic and tooled approach for integrating control mechanisms into software applications. ! • A reference implementation and tools facilitating the language use including modeling, code synthesis and verification support.
  48. 48. Thank you Filip Křikava filip.krikava@inria.fr
  49. 49. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures CASE STUDIES HTCondor Client Host schedd DAGMan 1 DAGMan 2 DAGMan N User Interface Submit workflows ... Executes HTCondor cluster of worker nodes Users Spawns Submitjobs Case Study 1 Case Study 2
  50. 50. 28.3.2014, SAC’14 - DADS ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures CASE STUDIES HTCondor Client Host schedd DAGMan 1 DAGMan 2 DAGMan N User Interface Submit workflows ... Executes HTCondor cluster of worker nodes Users Spawns Submitjobs Case Study 1 User Interface 1 User Interface 2 User Interface N Executes HTCondor cluster of worker nodes Users Users Users Submit workflows Submit jobs ... Central schedd Case Study 2

×