[logseq-plugin-git:commit] 2025-06-05T19:41:07.930Z

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

@@ -0,0 +1,420 @@
+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