logseq/pages/hls__Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework.md

file-path:: file://C:/Users/david/Zotero/storage/PAUWRAG9/Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf

• file:: [Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf](file://C:\Users\david\Zotero/storage/PAUWRAG9/Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf) file-path:: file://C:/Users/david/Zotero/storage/PAUWRAG9/Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf
• IoTMoF, a model-driven framework for requirements development, design and code generation of adaptive IoT systems ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c133de-c9b2-4b09-996b-a4003c5fd7f5
• a domain modelling language conforming to the IoT Architectural Reference Model (ARM ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c13469-d794-40ef-8f06-4d2b68f75cd9
• Code for the IoT platform is then generated from the Statechart mode ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c25cae-0d8b-4a22-83cf-ccdb47651f8d
• exceptional situations along with handling functionality. ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c25ed9-3424-429c-b809-687fd501c288
• Existing work7 on model-driven engineering (MDE) of IoT systems typically8 cover design, implementation, or management activities (Wolny9 et al. 2018). ls-type:: annotation hl-page:: 1 hl-color:: purple id:: 63c25f12-591d-4598-9027-e8f5c22f82fd hl-stamp:: 1673682708952
• the adaptive nature of IoT14 systems introduces complexities and challenges that need to be15 addressed at the early stages of developmen ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c25f45-034e-4e93-9bc9-5dc3a1469207 hl-stamp:: 1673682759671
• Deviations from the expected behaviour19 that are not identified during requirements development might20 eventually lead to an incomplete or ambiguous system speci ls-type:: annotation hl-page:: 1 hl-color:: green id:: 63c25f6e-fa95-4914-b3f4-10111a692af5
• Use Case 33 Modelling for Internet of Things) language (Boutot et al. 2021) ls-type:: annotation hl-page:: 1 hl-color:: purple id:: 63c25fa6-a543-4fe0-9d00-0c7b98f42db8 hl-stamp:: 1673682856732
• IoTMoF extends the UCM4IoT requirements development approach with support for domain modelling and also provides support for design-level modelling and code generation. hl-stamp:: 1673685319975 hl-page:: 2 ls-type:: annotation id:: 63c268eb-34fb-4254-bf4a-325f2b28b957 hl-color:: yellow
• Model7 transformations enable generation of the Statechart model and8 the code to be deployed on the microcontroller. ls-type:: annotation hl-page:: 2 hl-color:: yellow id:: 63c26988-9e3d-49c3-80db-ea7b7f71b7e5
• main success scenario ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26a04-097a-49f4-b1e3-3093680bc537 hl-stamp:: 1673685511956
• Exceptions in use cases refer to exceptional situations that36 interrupt the normal flow of interaction and may require special37 handling to be carried out ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26a4a-155c-452f-8c60-d554c84f1f7a
• Exceptions may also occur in the environment and change the42 context of the interaction. ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26a7a-9cd8-4eaa-81c0-80dd30dd19d1
• he exceptions need43 to be detected and addressed by defining handling mechanisms ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26a86-0bff-4e8f-bea0-a17f3815f5b6
• handler use case, is45 used to specify the exceptional interactions required to handle46 an exception. ls-type:: annotation hl-page:: 2 hl-color:: blue id:: 63c26abb-6e2a-4d24-8a96-d73f35a51f39 hl-stamp:: 1673685695683
• formalism for the modelling of the be-52 haviour of reactive systems ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26d50-8ce7-4e48-9d7e-fd7436d79ac7 hl-stamp:: 1673686356209
• The IoT Architectural Reference Model (ARM) (Bassi et al. 612016) was established as a step towards standardizing a ref- 62 erence model for the IoT domain. ls-type:: annotation hl-page:: 2 hl-color:: purple id:: 63c26d84-eed5-43d5-a040-d4bf1a0e9a40 hl-stamp:: 1673686407750
• No- 71 tions of virtual entity and augmented entity (composition of a 72 virtual and physical entity) are also part of the domain mode ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26dbd-1eec-4eb3-8261-ccf117befe01 hl-stamp:: 1673686463508
• extual use case models, use case diagrams, and IoT domain 81 models ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26de6-00f7-4971-b470-68248ebb2336
• IoT-specific constructs found in 87 a UCM4IoT model include typed actors (human, software, de- 88 vice, physical entity), and typed exceptions (hardware, software, 89 network, environment). ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26e05-fdce-4b31-802b-c4f8f9ebb382
• We have extended UML use case diagrams with IoT-specific 91 elements, in particular, typed actors, typed exceptions, and 92 handler use cases. The diagram provides a summary view of all 93 IoT actors and IoT-related exceptions and associated handler ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26e58-c9e1-4f3f-abbf-3c9645c8f124
• ervices, resources, types of devices (tag, 102 actuator, reader) and physical entities ls-type:: annotation hl-page:: 2 hl-color:: green id:: 63c26e70-42e4-41a1-9c7f-6ab3cf7325ff
• many designers are not5 familiar with the correct syntax and semantics of the domain6 modelling language (class diagrams in our approach ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63c26ec8-849a-4687-b14e-e3bae27253e0
• g to existing standards, i.e, the IoT ARM, is highly11 desirable. In our approach, we have created a bridge to IoT12 ARM by allowing our use case models to be automatically13 mapped to IoT ARM domain models. Thus, this enables the14 domain models to be used as input to the IoT ARM design15 process. ls-type:: annotation hl-page:: 3 hl-color:: purple id:: 63c26eef-1356-43d8-b4fa-8c139ccd0dab hl-stamp:: 1673686769626
• IoFMoF only allows attributes to be21 added to domain models ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63c26f0c-f30c-409a-b09b-7f85a172d41d hl-stamp:: 1673686800556
• information model24 is built on top of this domain model. The information mo ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63c26f26-368c-44d1-b3fb-4bdc6d6346b0
• s. The model identifies the resources in the system28 as well the devices on which they are hosted. ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63c26f38-3d03-43b0-89e9-4113874ebd96
• All exceptions and handlers 43 identified during requirements development are integrated in 44 this model ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63c26fc1-3285-4b5a-b0b3-5d24b0721c7d
• The configuration model 52 describes what pins are connected to which device ls-type:: annotation hl-page:: 3 hl-color:: yellow id:: 63c26fe4-cece-4fe8-bc10-a7521dd51438 hl-stamp:: 1673687022595
• The code generated 58 from the statechart implements the microcontroller behaviour ls-type:: annotation hl-page:: 3 hl-color:: yellow id:: 63c270f8-1ed1-4156-af18-2f3c90798188
• Adapted ls-type:: annotation hl-page:: 5 hl-color:: yellow id:: 63c2715b-19d1-435d-b928-e72edec013d6 hl-stamp:: 1673687390667
• UCM4IoT model consists of two types of elements: ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c27812-2498-4c89-9f6b-3d7de537b883 hl-stamp:: 1673689132070
• hardware, software, network,19 and environment ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c2782a-9760-415b-875f-7bcfbf6aff21 hl-stamp:: 1673689134004
• he main difference is that an alternative35 block represents an alternative behaviour, and an exceptional36 block defines behaviour for an exceptional situation ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c27869-ed67-4a9c-ab82-8b6cde5821ab
• Interaction steps found in summary40 and user-goal level use cases must include the system and an41 actor from the list of actors from the use case. ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c2787a-cd9e-484f-870c-95c4fd1b39d3
• . ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c27881-b9e7-41e6-8c12-eee4ec82d052
• UCM4IoT ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c27882-c42d-42da-97cb-44b00820c7ef
• Main50 success scenarios cannot continue to another step. For more51 details on the UCM4IoT language, please refer to (Boutot et al.522021). ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63c27898-277b-43fe-9590-2b80a3db9709 hl-stamp:: 1673689242350
• we go beyond the textual use case language 65 support for requirements modelling (proposed in (Boutot et al. 662021)) and create bridges to UML and IoT ARM. ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63c2c008-c2d6-4d6e-8891-0cb5abd5b26c
• UML use case diagrams are popularly used for modelling a 69 high-level behavioural view of the systems requirements ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c2c0c0-cc01-41bc-ac3f-5edbd21a94e5
• IoTMoF addresses these limitations in traditional 76 software development and supports automatic transformation 77 of textual use cases to a domain-specific use case diagram ls-type:: annotation hl-page:: 4 hl-color:: purple id:: 63c2c111-0b70-4158-a022-809e22b2f089
• This is an extension of the UML use case diagram with 86 IoT-specific constructs aligned with the UCM4IoT language. 87 The metamodel is shown in Fig. 3. ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63c2c153-a60f-4018-8e8e-dfda6580cc00
• any use case found within the ex- 90 tended use case diagram can be either a handler use case or a 91 standard use cas ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c2c1b6-9aa3-4c68-82d0-4d20808e5bf9
• s they handle exceptions from ls-type:: annotation hl-page:: 4 hl-color:: red id:: 63c2c225-9e97-402f-b60d-1b9d08c2a856
• hardware, software, network, and environment ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63c2c267-bab0-4f6f-9bd6-9d631e48f572
• invoked ls-type:: annotation hl-page:: 4 hl-color:: red id:: 63c2c2b8-402b-487c-8d1c-f84acf216dc3
• excluding the area outlined in red i ls-type:: annotation hl-page:: 5 hl-color:: yellow id:: 63c2c306-30fc-4c6a-83c9-b68072ee0158
• sers can interact with physical entities, and13 they can invoke service ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63c2c33d-7c01-434d-8a04-cbe613a0aeb4
• invokes ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63c2c344-b1c2-4783-8cfa-655436ecf2a9
• monitors ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63c2c34e-a2ae-43bd-a6da-365853001f50
• acts ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63c2c353-4da5-47b1-8c59-9cbb1028f601
• IoTMoF maps an UCM4IoT model to an IoT domain model 23 using Xtend and Sirius ls-type:: annotation hl-page:: 5 hl-color:: purple id:: 63c2c36b-a005-4794-8a2a-9871d557f619
• evolve the domain 30 model to a design class diagram, namely, information model ls-type:: annotation hl-page:: 5 hl-color:: yellow id:: 63c2c384-cae6-4652-a59f-0ccc040c0094
• A user interacts with a physical entity12 when there exists a step in the use case model that describes13 such an interaction ls-type:: annotation hl-page:: 6 hl-color:: green id:: 63c2c577-cae5-40f3-8ffb-50f1b4d1dbfe
• oTMoF provides a modelling editor to extend and25 evolve the domain model into a design-level information model. ls-type:: annotation hl-page:: 6 hl-color:: green id:: 63c2c5ae-3e82-4c40-9b83-a20ae6b7e25a
• For example, the 40 modeller may say that a particular actor invokes a service or a 41 virtual entity represents some physical entity. ls-type:: annotation hl-page:: 6 hl-color:: yellow id:: 63c2c5e9-1f18-455a-9a5c-d731de867cd1
• Figure 18 Smart Lights System: Statechart Model (Part 1) ls-type:: annotation hl-page:: 11 hl-color:: yellow id:: 63c2c686-990b-4bf6-a1ff-cdbb0d2509ad
• Hence, 45 it was more feasible to use a textual modelling language for 46 facilitating the generation process ls-type:: annotation hl-page:: 6 hl-color:: yellow id:: 63c2fb03-2cfb-412f-979a-f0db28e21517
• M2M transformation ls-type:: annotation hl-page:: 6 hl-color:: yellow id:: 63c2fd77-f120-4a98-88c0-bf73f28a9d4f
• The map- 52 ping is exception-aware and the adaptive behaviour of the sys- 53 tem is realized in this model with dedicated handler states and 54 exception events ls-type:: annotation hl-page:: 6 hl-color:: yellow id:: 63c2fd84-003f-44b8-9c23-6016f0106998
• The wrapper code will initialize the statechart with 51 the setup function that is automatically called after it configures 52 the pins on the microcontroller ls-type:: annotation hl-page:: 7 hl-color:: yellow id:: 63c2fe33-00aa-49de-8d1e-91a934a1497f
• The loop function will update 53 the statechart periodically. ls-type:: annotation hl-page:: 7 hl-color:: yellow id:: 63c2fe38-2411-4b1e-911b-7e99317e7e27
• A smart lights system is an automated 66 system consisting of smart lights, devices that contain both a 67 sensor that detects the surrounding light intensity, and a light 68 that turns on or off depending on the brightness of the physical 69 surroundings ls-type:: annotation hl-page:: 7 hl-color:: green id:: 63c2fe62-d8d1-477e-b53d-44fe1092967b
• Each smart light communicates their status to 70 some server, called a hub, in the system ls-type:: annotation hl-page:: 7 hl-color:: green id:: 63c2fe67-fb75-48ea-915e-491695f7e889
• This hub is responsible 71 for receiving data logs from each smart light, and storing those 72 logs in a database. ls-type:: annotation hl-page:: 7 hl-color:: yellow id:: 63c2fe6d-d021-4fa5-8bc8-b34ce85e56a4
• The device continuously sends the light intensity of the sur- 80 roundings to the hub. ls-type:: annotation hl-page:: 7 hl-color:: yellow id:: 63c2ff84-33fa-4d0f-857d-984cde02ab39
• igure 8 Smart Lights System: Use Smart Lights ls-type:: annotation hl-page:: 8 hl-color:: yellow id:: 63c2ff9c-ba07-4fdd-b493-9cbafe5877f3
• The WiFi LED displays when the device2 connects and sends data to the hub, and the Error Display indi-3 cates any exceptional situations such as being unable to connect4 to WiFi. ls-type:: annotation hl-page:: 8 hl-color:: green id:: 63c3ade8-e50b-4c9d-bc0e-759cfebc4c06
• The handler that handles these three exceptions 20 are shown in Fig. 10 ls-type:: annotation hl-page:: 8 hl-color:: yellow id:: 63c3b07c-6416-404f-a1c6-a0bda6e07d31
• information model that was built on top 36 of the IoT domain model ls-type:: annotation hl-page:: 8 hl-color:: green id:: 63c3b124-63ea-4971-a6fe-b5bd23c74bb6
• design-level details ls-type:: annotation hl-page:: 8 hl-color:: yellow id:: 63c3b143-e450-43f1-9826-e796f0c84544
• The types of functions the devices can perform are listed for 17 each relationship between a device and a physical entity or use ls-type:: annotation hl-page:: 9 hl-color:: green id:: 63c3b1be-7300-470c-b8d1-befb93de80c8
• The configuration model, shown in Fig. 16, takes as input 26 the attributes and functions from the IoT information model and 27 maps them to components and functions in the configuration 28 model. ls-type:: annotation hl-page:: 9 hl-color:: yellow id:: 63c3b1e6-9176-4504-91c4-987ca229fe59
• For visualization purpose, we present a graphical version of14 the generated statechart model in Yakindu6 in Fig. 18 and 19. ls-type:: annotation hl-page:: 10 hl-color:: yellow id:: 63c3b271-63d3-4fcf-af98-598268e7ef5e
• non-critical IoT systems ls-type:: annotation hl-page:: 10 hl-color:: green id:: 63c3b2f5-3c6a-4841-8050-ff4c9ef229a3
• it does not incorporate adaptive be-8 haviour (exceptions and handlers in our work) defined in the9 requirements at this level. ls-type:: annotation hl-page:: 13 hl-color:: green id:: 63c3b40a-a875-4084-bb51-9fa9344c9fcb
• adaptive behaviou ls-type:: annotation hl-page:: 13 hl-color:: green id:: 63c3b45d-6a4b-4e03-8986-9736558378fa
• Papyrus for50 IoT is not compatible with recent Eclipse versions and is not51 available for download. ls-type:: annotation hl-page:: 13 hl-color:: green id:: 63c3b470-67f0-4319-a1ef-14c531085d4b
• IoT concepts and also supports the adaptive na- 59 ture of such a domain with the use of exceptions and handlers 60 in use case ls-type:: annotation hl-page:: 13 hl-color:: green id:: 63c3b48f-ccf4-4199-a493-7047dc55871d
• UCM4IoT Language, IoT Use Case Diagram, IoT 63 Domain Modelling Language, IoT Information Modelling Lan- 64 guage, TStatechart Language (a textual statechart language), 65 and Configuration Modelling Language ls-type:: annotation hl-page:: 13 hl-color:: yellow id:: 63c3b49e-7b15-4396-b542-6c9cbe99ee4e