Multi-Design: designing self-adaptation of smart space features João Pedro Sousa George Mason University USA Dagstuhl Seminar 10431―Oct 24-29, 2010 Software Eng for Self-adaptive Systems

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems situate the work what adaptation footprint 2 Intentional user input in respose to: change Environment metrics System faults System metrics System events parameters QoS goals Executable models Functional requiremts Computation / behavior Run-time structure Code base context- aware phone ring automated MDD self-mod code Rainbow SASSY multi-Design app w/ config file

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems smart spaces merge computing and physical world 3 spaces public streets, train stations organizational buildings, buses private homes, cars apps safety and surveillance energy management health & assisted living work & entertainment anywhere …

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems smart spaces merge computing and physical world 4 spaces public streets, train stations organizational buildings, buses private homes, cars users move between spaces bring expectations aka reqs features, QoS

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems this talk multi-Design self-adaptation stems from sharing of cyber-physical services explicit intentions in design artifacts 5 multi-user design: one design for multiple users multi-Design: system may adopt multiple designs depending on which users are present

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems middleware design notations w/ complete semantics fully automated deployment 6 users deploy and retire design artifacts at will middleware takes design artifacts as input discovers and briefs/coordinates the required services spatial constraints in the design guide discovery

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems middleware expectations of mobile users captured as design artifacts 7 set of available design artifacts change as users come and go

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems middleware users share physical spaces and the services deployed therein purely software services can be replicated and sandboxed offering each user a logically separate system even if deployed on the same device(s) 8 set of available design artifacts change as users come and go

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems middleware multi-design 9 set of available design artifacts change as users come and go cyber-physical services may be logically shared among users multi-touch table thermostat next slide design of a situated system run-time view: which components it includes and how they are interconnected changes with the designs users bring to a space and decide to deploy

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems logical sharing of services may result in conflicting settings users may create designs to set the thermostat in each space Bob prefers 72ºF, Fred prefers 68ºF other examples: TV channel, music volume, any numeric setting what should happen when Bob and Fred are present? 10 SASSY a relative of BPMN

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems approach: promote resolution mechanisms to design level so that stakeholders may change policies at will space stakeholders define resolution policy for accessing shared service(s) access: authorized, open multiplexing: exclusive, shared resolution : fcfs, priority, least misery,… 11 SASSY a relative of BPMN (c) Schema made by the stakeholders at a specific space t:thermostat setTemp ask rem setTemp default O S LM

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems approach: promote resolution mechanisms to design level so that stakeholders may change policies at will space stakeholders define resolution rules for accessing shared service(s) principles are transferrable to different design notations 12 TeC – a relative of spreadsheets anywhere thermostat track(Fred) set anywhere thermostat track(Bob) set

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems outline self- adaptation in multi-Design 13 Intentional user input in respose to: change Sensor (env) metrics System faults System metrics System events parameters QoS goals Executable models Functional requiremts Comput. / behavior Run-time structure Code base context- aware phone ring automated MDD self-mod code Rainbow SASSY multi-Design

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems self-adaptation captured in a design artifact a smart power meter at Bob’s home issues pricing signals Bob wants clothes dryer to suspend drying during high rates and to resume only when night rates are in effect Bob’s wife would like to have her clothes dry regardless 14 save Bob.org/home smart meter dry track(Bob) pricey save done cheap pause resume drying control deployment of sub-systems start stop

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems in summary multi-Design self-adaptation of cyber-physical SOA systems system goals: dynamic, temporary, multiple, possibly conflicting adaptation triggers: functional, foreseeable mechanisms: assisted by middleware structural: merging of systems, start and stop subsystems parametric: conflict resolution effects: mission-critical, safety-critical applicable to a variety of design notations SASSY – relative of BPMN – for domain experts TeC – relative of spreadsheets – for end users 15

Dagstuhl Seminar 10431―Oct 24-29, 2010 ― Software Eng for Self-adaptive Systems questions 16