Enabling high level application development for internet of things
Download as PPTX, PDF4 likes1,377 views
The document presents research by Pankesh Patel on enabling high-level application development for the Internet of Things (IoT), outlining challenges such as device heterogeneity and the large scale of applications. It discusses existing development approaches and introduces a comprehensive framework that utilizes modeling languages to facilitate IoT application development while reducing effort. The proposed framework encourages collaboration among stakeholders and separates concerns to enhance reusability and maintainability.
![Internet of Things (IoT)
“A global networked infrastructure, linking physical and
virtual things through the exploitation of data capture and
communication capability.”
[CASAGRAS project] http://www.grifs-project.eu/data/File/CASAGRAS%20FinalReport%20(2).pdf
3](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-3-320.jpg)
![Goal
“Enable development** of IoT applications
with minimal effort by various stakeholders*
involved in development process”
**Development -- “a set of related activities that leads to a production of a software product.’’ [Ian
Sommerville, Software Engineering (9th edition) , 2010]
*Stakeholders in software engineering to mean – people, who are involved in the application
development. Examples of stakeholders defined in [Taylor et al., Software Architecture, 2009] are
software designer, developer, domain expert, technologist, etc.
6](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-6-320.jpg)
![Application development challenges
Application Heterogeneity
designed/implemented
into a set of distributed tasks for
Large scale
heterogeneous devices
Development
Multiple expertise
Different life-cycle
phases
Tasks has to be
decomposed
in a large number of
devices
Deployment
Evolution
Changes in application
requirements
Changes in deployed devices
Software development life cycle phases -- requirement analysis, design, implementation, testing,
evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]
11](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-11-320.jpg)
![Existing approaches
Node-centric programming
Think in terms of activities of
individual device & encode
interactions
Olympus with Gaia middleware,
Context Toolkit, nesC with TinyOS,
physical-virtual mashup
Olympus with Gaia [Ranganathan et al., Percom, 2005], Context Toolkit
[Dey et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual
mashup [Guinard et al., NSS, 2010]
13](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-13-320.jpg)
![Existing approaches
Node-centric programming
Database approach
Queries to SN
Collects, aggregates, &
sends data to base station
Not flexible to introduce a
customized application logic
TinyDB, Semantic streams,
TinyREST, TinySOA
queries
Stakeholder
collects
result
Base station
TinyDB [Madden et al., TODS ,2005], Semantic streams [Whitehouse et
al., , EWSN, 2006], TinyREST [Luckenbach et al., REALWSN, 2005],
TinySOA [Aviles-Lopez , SOCA, 2009]
14](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-14-320.jpg)
![Existing approaches
Node-centric programming
Database approach
WSN macroprogramming
Abstractions for high-level
collaborative behaviors
Lack of software engineering
methodology to support life
cycle phases – results in
difficult to maintain, reuse,
and platform-dependent
design
Regimant, MacroLab
Regiment [Newton et al., IPSN, 2007], MacroLab [Hnat et
al. , SenSys, 2008]
15](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-15-320.jpg)
![Existing approaches
Node-centric programming
Database approach
WSN macroprogramming
Model-driven development
ATaG, RuleCaster (sensor
network)
DiaSuite, PervML, Pantagruel
(pervasive and ubiquitous
computing)
Horizontal
Separation of
Concerns (SoC)
PIM
C1
Vertical
separation of
concerns
C2
…
Cn
Transformation and
code generators
…
ATaG [Pathak et al., DCSN, 2011], RuleCaster [Bischoff
PSM
et al., EuroSSC, 2006], DiaSuite [Cassou et al., TSE,
2012], PervML [Serral et al., Journal of Pervasive and
E.g., J2SE
Mobile computing, 2010], Pantagruel [Drey et al., Percom,
2010]
16 our work takes inspiration from ATaG, which is a WSN framework to develop SCC
applications
PSM
E.g., .Net](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-16-320.jpg)
![Contributions
A comprehensive approach that utilizes advantages
of existing MDD and WSN macroprogramming
approaches, while focusing on ease of IoT
application development
Set of modeling languages to specify different concerns of
IoT applications
Development framework* to integrates modeling
languages
and automation techniques
*It includes support programs, code libraries, high-level languages or other software that help
stakeholders to develop and glue together different components of a software product [Ian
Sommerville, Software Engineering (9th edition) , 2010].
18](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-18-320.jpg)
![Commonality
at various levels
Building fire
state
Room
temperature
Domain
(e.g. building
automation)
“Entities of Interest (EoI) is an object,
including the attributes that describes it, and
its state that is relevant from a user or an
application perspective.”
[Stephan Haller, Internet of Things, 2010]
Functionality
(e.g., building (e.g., home
HVAC) fire detection
Deployment
(e.g., Inria
Office)
19
(e.g., Google
Office)
“Reusability
across concerns”](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-19-320.jpg)
![Contributions
Set of modeling languages to specify different concerns of
IoT applications
Development framework* to integrates modeling
languages and automation techniques
*It includes support programs, code libraries, high-level languages or other software that help
stakeholders to develop and glue together different components of a software product [Ian
Sommerville, 9th edition, 2010].
32](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-32-320.jpg)
![Existing model-driven approaches for IoT
Heterogeneity
Scale
Multiple
expertise
Life cycle
ATaG
[2011]
Partially
Yes
No
Yes
RuleCast
er [2007]
Partially
Yes
No
Yes
PervML
[2010]
Yes
No
Partially
Partially
(Manual
deployment)
DiaSuite
[2011]
Yes
No
Partially
Partially
(Manual
deployment)
Pantagru
el [2009]
Partially
No
Partially
Partially
(Manual
deployment)
62](https://image.slidesharecdn.com/enablinghigh-levelapplicationdevelopmentforinternetofthings-140107010911-phpapp01/85/Enabling-high-level-application-development-for-internet-of-things-62-320.jpg)
Enabling high level application development for internet of things
- 1. Enabling High-Level Application Development for the Internet of Things Pankesh Patel PhD defense 25th November, 2013
- 2. Growing number of ``things” Smoke detectors Air pollution controllers Temperature sensors Lights HVAC system Fire alarms Smart phones Structural health monitors 2 Image credit: http://www.libelium.com/ Parking space controller Smart Water car leakage detector Traffic signals
- 3. Internet of Things (IoT) “A global networked infrastructure, linking physical and virtual things through the exploitation of data capture and communication capability.” [CASAGRAS project] http://www.grifs-project.eu/data/File/CASAGRAS%20FinalReport%20(2).pdf 3
- 4. IoT application Involves a large number of heterogeneous devices, processing elements Composes multiple activities Interacts with users whenever necessary 4
- 5. Illustrative example: building system Large numbers of heterogeneous devices An application - compose multiple activities (e.g., detect user’s entry , query, set threshold) For situation awareness (e.g., avg. temperature of building), devices involved in collaborative activities Temperature sensor 5 Heater Smoke detector Fire alarm Badge reader User with badge Data storage Light User interfaces (e.g., display, mobile phones)
- 6. Goal “Enable development** of IoT applications with minimal effort by various stakeholders* involved in development process” **Development -- “a set of related activities that leads to a production of a software product.’’ [Ian Sommerville, Software Engineering (9th edition) , 2010] *Stakeholders in software engineering to mean – people, who are involved in the application development. Examples of stakeholders defined in [Taylor et al., Software Architecture, 2009] are software designer, developer, domain expert, technologist, etc. 6
- 7. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work 7
- 8. Application development challenges Heterogeneity Types of devices (e.g., sensor, actuator, storage, processing elements, user interfaces) Interaction modes (e.g., publish/subscribe, request/response, command) Platforms (e.g., Android, JavaSE) Spreads into the application code, Makes the portability of code difficult 8
- 9. Application development challenges Heterogeneity Large scale Application logic in terms of a set of distributed tasks for hundreds to thousands of devices To reason at such levels of scale is impractical in general 9
- 10. Application development challenges Heterogeneity Large scale Multiple expertise Application domain Platform-specific knowledge Knowledge from multiple concerns intersect Algorithm design, programming languages Software design Clear conflict with skill possessed by the individual developer 10 Deployment area
- 11. Application development challenges Application Heterogeneity designed/implemented into a set of distributed tasks for Large scale heterogeneous devices Development Multiple expertise Different life-cycle phases Tasks has to be decomposed in a large number of devices Deployment Evolution Changes in application requirements Changes in deployed devices Software development life cycle phases -- requirement analysis, design, implementation, testing, evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010] 11
- 12. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work 12
- 13. Existing approaches Node-centric programming Think in terms of activities of individual device & encode interactions Olympus with Gaia middleware, Context Toolkit, nesC with TinyOS, physical-virtual mashup Olympus with Gaia [Ranganathan et al., Percom, 2005], Context Toolkit [Dey et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual mashup [Guinard et al., NSS, 2010] 13
- 14. Existing approaches Node-centric programming Database approach Queries to SN Collects, aggregates, & sends data to base station Not flexible to introduce a customized application logic TinyDB, Semantic streams, TinyREST, TinySOA queries Stakeholder collects result Base station TinyDB [Madden et al., TODS ,2005], Semantic streams [Whitehouse et al., , EWSN, 2006], TinyREST [Luckenbach et al., REALWSN, 2005], TinySOA [Aviles-Lopez , SOCA, 2009] 14
- 15. Existing approaches Node-centric programming Database approach WSN macroprogramming Abstractions for high-level collaborative behaviors Lack of software engineering methodology to support life cycle phases – results in difficult to maintain, reuse, and platform-dependent design Regimant, MacroLab Regiment [Newton et al., IPSN, 2007], MacroLab [Hnat et al. , SenSys, 2008] 15
- 16. Existing approaches Node-centric programming Database approach WSN macroprogramming Model-driven development ATaG, RuleCaster (sensor network) DiaSuite, PervML, Pantagruel (pervasive and ubiquitous computing) Horizontal Separation of Concerns (SoC) PIM C1 Vertical separation of concerns C2 … Cn Transformation and code generators … ATaG [Pathak et al., DCSN, 2011], RuleCaster [Bischoff PSM et al., EuroSSC, 2006], DiaSuite [Cassou et al., TSE, 2012], PervML [Serral et al., Journal of Pervasive and E.g., J2SE Mobile computing, 2010], Pantagruel [Drey et al., Percom, 2010] 16 our work takes inspiration from ATaG, which is a WSN framework to develop SCC applications PSM E.g., .Net
- 17. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work 17
- 18. Contributions A comprehensive approach that utilizes advantages of existing MDD and WSN macroprogramming approaches, while focusing on ease of IoT application development Set of modeling languages to specify different concerns of IoT applications Development framework* to integrates modeling languages and automation techniques *It includes support programs, code libraries, high-level languages or other software that help stakeholders to develop and glue together different components of a software product [Ian Sommerville, Software Engineering (9th edition) , 2010]. 18
- 19. Commonality at various levels Building fire state Room temperature Domain (e.g. building automation) “Entities of Interest (EoI) is an object, including the attributes that describes it, and its state that is relevant from a user or an application perspective.” [Stephan Haller, Internet of Things, 2010] Functionality (e.g., building (e.g., home HVAC) fire detection Deployment (e.g., Inria Office) 19 (e.g., Google Office) “Reusability across concerns”
- 20. Domain Room temperature Building fire state Actuator User interface Domain (e.g. building automation) Concepts that are responsible for interacting with EoI of a domain - Sensor, actuator, storage, user interface Sensor 20 Storage
- 21. Functionality Building fire state Room temperature Actuator User interface Domain (e.g. building automation) command Computational service Functionality Building HVAC Home fire detection Computational service Concepts that are responsible for - processing data and taking decisions 21 publish/ subscribe request Sensor response Storage
- 22. Concepts to describe various properties of devices Deployment Building fire state Room temperature Actuator User interface Device Domain Device (e.g. building automation) command Device Device Functionality Building HVAC Computational service Computational service Home fire detection Deployment publish/ subscribe Inria office 22 Google office request Device Sensor response Storage Device
- 23. Modeling languages Srijan* interface User Vocabulary Language (SVL) Actuator Device Domain (e.g. building automation) Functionality Building HVAC Deployment Inria office 23 Device Computational Srijan* service Deployment Srijan* Home fire Language Architecture detection (SDL) Language Computational Device service (SAL) Google office Device Sensor Storage *Srijan is the sanskrit word for “creation”, and this word is derived form Srijan toolkit for sensor network macroprogramming in our group.
- 26. Srijan vocabulary language BadgeDetected BadgeReader profile • SVL provides abstractions to specify heterogeneous entities • 1 entity description for many instances and implementations TempStruct tempValue: double; unitofMeasurement : String; BadgeReader generate badgeDetected:BadgeDetectedStruct; ProfileDB generate profile:TempStruct accessed-by badgeID:String; ProfileDB Heater Off() SetTemp() User interface 26 request, command Heater action Off(); action SetTemp(temp:TempStruct); User interface request profile(badgeID); command setTemp(temp);
- 27. Srijan architecture language To reduce scale, devices can be grouped based on their spatial relationship • Cluster head is elected, responsible for processing data of that cluster. Monitor Display() hops:0:Building Building AvgTemp Building hops:0:Building Floor AvgTemp Floor hops:0:Floor RoomAvgTemp consume tempMeasurement from hops:0:Room; generate roomAvgTemp:TempStruct; in-region:Room; Room AvgTemp hops:0:Room Scope of Deployment 27 Scope of consuming data. temp Measurement Temperature Sensor Room
- 28. Srijan architecture language Proximity generate tempPref:TempStruct; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0:Room; request profile(badgeID); in-region:Room; Computational service may compose multiple activities. Room Proximity pub./sub. hops:0:Room badgeDetectedresponse badgeDisappeared 28 Badge Reader request profile ProfileDB To facilitate, SAL provides abstractions to manage heterogeneous interactions
- 29. Srijan deployment language Building fire state Room temperature SDL provides abstractions to describes various properties of devices Actuator User interface Device Domain (e.g. building automation) Device Device Device Functionality Building HVAC Computational service Computational service Home fire detection Deployment publish/ subscribe Inria office 29 Google office request Device Sensor response Storage Device
- 30. Deployment specification Device1: region: Building:15 ; Location of device Floor:11; Room:1; resources:TemperatureSensor, Heater; type:JavaSE; Type platform a device runs on Device2: … Device3: … 30
- 31. Summary of modeling languages Srijan vocabulary language Srijan architecture language Abstractions for heterogeneous entities of domain 1 entity description for potentially many implementations and instances Use domain to specify functionality in global manner Abstractions for processing elements & heterogeneous interactions, scope constructs to enable scalable operations Srijan deployment language 31 Use domain concepts to specify device details (individually)
- 32. Contributions Set of modeling languages to specify different concerns of IoT applications Development framework* to integrates modeling languages and automation techniques *It includes support programs, code libraries, high-level languages or other software that help stakeholders to develop and glue together different components of a software product [Ian Sommerville, 9th edition, 2010]. 32
- 33. Domain & Functional concern Domai n expert User interface request/command/ action Domain expert (e.g. biologist, medical system designer) understands domain concepts. SVL Actuator action Computational service Software designer – understands software architecture concepts SAL Computational service Vocabulary Compilation spec. of vocabulary 33 Software designer sensor measurement retrieval Sensor Architectur e spec. Storage
- 34. Functional concern Domai n expert Architecture framework (in object-oriented GPL) - Contains abstract classes - Concrete methods - Abstract methods Application developer – skilled in algorithm design & use of programming lang. Vocabulary Compilation spec. of vocabulary Architectur e spec. 34 Application logic Compilation of architecture Software designer Application developer Architectur e framework
- 35. Implementing application logic separation application logic & interaction code, known location for application logic Proximity generate tempPref:TempStruct; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0:Room; request profile(badgeID); in-region : Room; Concrete method for Subscriptio n request Concrete method for Receiving notification s 35 Compiler generat es private String partitionAttribute = "Room"; public void subscribebadgeDetected() { PubSubMiddleware.subscribe(this, "badgeDetected", subscriptionCondition); } public void notifiedReceived (String event Name, Object arg, Device deviceInfo) { if (eventName.equals(“badgeDetected”) { onNewBadgeDetected((BadgeDetectedStruct) arg) ; } } public abstract void onNewBadgeDetected (BadgeDetectedStruct arg);
- 36. Deployment concern Understands the specific target area SDL Mapper – decides device where each computational service will be executing Domai n expert Mapping files Deployment spec. Mapper Vocabulary Compilation spec. of vocabulary Network manager Architectur e spec. 36 Application logic Compilation of architecture Software designer Application developer Architectur e framework
- 37. Platform concern Domai n expert Device develope r Device driver • Device developer – understands inputs/outputs, protocols of device platform Vocabulary Framework • Abstract classes with concrete methods, interfaces Vocabulary framework Mapping files Deployment spec. Mapper Vocabulary Compilation spec. of vocabulary Network manager Architectur e spec. 37 Application logic Compilation of architecture Software designer Application developer Architectur e framework
- 38. Linking Domai n expert Device develope r Device driver Combines and packs the code generated by various stages into packages that can be deployed on devices. Vocabulary framework Android devices Mapping files Deployment spec. Mapper Vocabulary Compilation spec. of vocabulary Linker PC Network manager PC Architectur e spec. 38 Application logic Compilation of architecture Software designer Application developer Architectur e framework
- 39. Summary of development framework Promotes suitable division of work among stakeholders Separates development in different concerns (deal with each individually at evolution, enables reusability across IoT applications) Integrates a set of modeling languages & supports automation techniques to reduce development effort Defines a sequence of steps to follow to develop IoT applications 39
- 40. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work 40
- 41. Evaluation Goal : To describe how well approach addresses our aim in a quantitative manner. Development effort : indicates effort required to create an application Reusability : indicates reuse of specifications and implementations across applications 41
- 42. Development effort Vocabulary spec. 2% Code coverage** : 92.22% Architecture spec. 1% Deployment spec. 4% Device driver 5% Application logic 6% Generated code* 82% *Lines of code using Metrics 1.3.6 Eclipse plugin, **Code coverage using EclEmma Eclipse plug-in. 42
- 43. Fire detection application Alarm User interface Activate( ) GetNotification( ) hops:0:Building hops:0:Building Building Building FireController RoomFireState hops:0:Building FloorFireState RoomFireState Floor Floor FireState RoomFireState hops:0:Floor FloorFireState Room Room FireState FloorFireState hops:0:Room Building FireController hops:0:Room Smoke presence Smoke Detector Smoke detector Room AvgTemp hops:0:Room Building 43 Room Temperature sensor Alarm User interface temp Measurement Temperature Sensor
- 44. Reusability Handwritten Lines of code Domain Building Automation Applications Smart building Fire detection 44 Voca b. spec. Arch. spec. Deploy. spec. Applicatio n logic Device driver Developme nt effort 55 28 81 131 151 446 21 72 93
- 45. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work 45
- 46. Summary Application development challenges: Existing approaches Separation of concerns, modeling languages, automation, development framework Evaluation 46 Node-centric programming, database, WSN macroprogramming, model-driven development Our approach Heterogeneity, large scale, multiple expertise, different life cycle phases Reduce development effort
- 47. Future work Supporting testing phase of application development Emulates execution before deployment, Identifies conflicts, reducing application debugging effort. Integration of open source simulator (Siafu?) Run-time adaptation in IoT applications 47 How changes can be injected into the running application that would adapt itself accordingly? e.g., when a new device is added, an application include device and assign a new task to contribute
- 48. Backup slides
- 49. Development effort remains constant independent of a number of devices Development effort Number of devices Vocab Spec. Arch Spec. Deploy Spec. Device Driver Application Logic 10 41 28 81 98 131 34 41 28 273 98 131 50 41 28 401 98 131 62 41 28 497 98 131 86 41 28 689 98 131 110 41 28 881 98 131 200 41 28 1601 98 131 300 41 28 2401 98 131 350 41 28 2801 98 131 500 41 28 4001 98 131 49
- 50. Generated code snippet from high-level specifications Generate (or publish) interaction mode Command interaction mode Request interaction mode Vocabulary framework 50 Class diagram of vocabulary framework Factory class
- 51. Generated code for “generate” Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler generat es protected void setTempPref(UserTempPrefStruct newValue) { PubSubMiddleware.publish("tempPref", newValue, myDeviceInfo); } 51
- 52. Generated code for “command’’ RegulateTemp command SetTemp(setTemp) to hops:0: Room; command OffLight() to hops:0: Room; in-region : Room; Compiler generat es protected void SetTemp(TempStruct arg) { PubSubMiddleware.sendCommand(“SetTemp", arg, myDeviceInfo); } protected void OffLight() { PubSubMiddleware.sendCommand(“OffLight", arg, myDeviceInfo); } 52
- 53. Generated code for “request” Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler generat es protected TempStruct getprofile(String arg) { return (TempStruct) PubSubMiddleware.sendRequest("getprofile", arg, myDeviceInfo); } 53
- 54. Class diagram Contains interfaces to implement for device developer IBadgeReader Contains concrete methods for interacting with other entities BadgeReaderFactory Implements AndroidBadgeReader Device-specific implementation by device developers 54 BadgeReader Provide interface to obtain an instance of different platform-specific device driver implementations without having to know what implementation the concrete class obtains.
- 55. Implementing device driver BadgeReader generate badgeDetected:badgeDetectedStruct; Compiler Device developer implements interfaces generates public interface IBadgeReader { public BadgeDetectedStruct getbadgeDetected(); public void getbadgeDetected(ListenerbadgeDetected handler); } 55
- 56. Generated factory class BadgeReader generate badgeDetected: badgeDetectedStruct; Compiler generat es public class BadgeReaderFactory { public static IBadgeReader getBadgeReader(String nameBadgeReader) { if(nameBadgeReader.equals("Android")) return new AndroidBadgeReader(); if (nameBadgeReader.equals(“J2SE")) return new J2SEBadgeReader(); } } 56
- 57. Iterative development for handing evolution Evolution in functionality Evolution in deployment Evolution in platform Evolution in domain 57
- 58. Iterative development for change in functionality 1. 2. 3. 4. Adding a computational service Removing a computational service Extending a functionality of a computational service Changing a functionality of an application.
- 59. Iterative development for change in deployment Change in Deployment Specification • Adding, removing, or shifting a device • Change in a target deployment 59
- 60. Iterative development for change in platform Adding new software features 60
- 61. Iterative development for change in domain 1. Adding new resources (i.e., sensor, actuator, storage, user interface) 2. Removing resources 3. Extending resources 61
- 62. Existing model-driven approaches for IoT Heterogeneity Scale Multiple expertise Life cycle ATaG [2011] Partially Yes No Yes RuleCast er [2007] Partially Yes No Yes PervML [2010] Yes No Partially Partially (Manual deployment) DiaSuite [2011] Yes No Partially Partially (Manual deployment) Pantagru el [2009] Partially No Partially Partially (Manual deployment) 62
- 63. Srijan architecture language Heater Off() SetTemp() hops:0:Room Room RegulateTemp Manager hops:0:Room Proximity 63 hops:0:Room Room AvgTemp RoomTempManager consume roomAvgTempMeasurement from hops:0:Room; consume tempPref from hops:0:Room; command SetTemp(setTemp) to hops:0:Room; command Off() to hops:0:Room; in-region:Room;
- 64. Class diagram of domain-specific concepts Vocabulary 1..* Region 1..* Structure 1..* 1..* Resource Request * Sensor 1..* Sensor Measurement 64 Actuator 1..* Action Storage User interface * Command * Action 1..* Retrieval
- 65. Class diagram of functionality-specific concepts Architecture * Structure 1..* 1..* Input Consume 65 1..* Computational Service 1..* Region 1..* Output Generate Request Command
- 66. Class diagram of deployment-specific concepts Deployment 1..* Device 1..* Region 66 * Resource