# Enhancing Sustainable IoT Systems Through a Goal-Oriented Requirements Analysis Framework
## 4 Goal-Oriented Requirements Analysis Approach for IoT Software Systems
### Application Example: IoT System for Monitoring Air Quality
#### 4.2.5 QVT for Model-to-Model Transformations  
QVT is a model-to-model transformation language, with which it is possible to define a set of transformation rules to convert the i* RA model into a UML class diagram. The i* model will be transformed into a UML class structure that represents the classes, attributes, and relationships needed for the IoT air quality monitoring system. To define a set of QVT transformation rules (model-to-model) for generating a UML class diagram from the i * RA model of an IoT system for air quality pollution monitoring,it is necessary to break down the RA model into specific components that need to be transformed into class diagram elements. The transformation process must consider key aspects of sustainability, including energy efficiency, real-time data processing, and scalability. These rules will guide the process of converting the i* RA model to a class diagram, ensuring that the system adheres to these principles while focusing on achieving the goals of the IoT system. The QVT transformation rule will map the actors in the i* model to the classes in the UML model. Each actor in the i* model corresponds to a UML class that encapsulates the behavior and responsibilities of the actors in the IoT system. The goals in the i* RA model will be transformed into class attributes or operations. The services and tasks in the i* model will become methods or associations in the UML class diagram. The resources (e.g., sensors) will also be transformed into classes or attributes. The decomposition of the i* RA model is detailed below. * User (end user interacting with the system). * MobileApp (software for accessing data). * IoTSystem (the core system processing sensor data). * Monitor air quality (main goal). * Improve air quality (outcome goal for the system). * Establish network connection (connectivity goal). * Calculate sensor values (measurement goal). * Get sensor identifier (for identifying the sensor). * Read sensor data (reading from IoT sensors). * Humidity Sensor. * CO2 Sensor. * Temperature Sensor. The transformation rules are discussed next. Figure 1: Requirements analysis for the application example using a i* 2.0 modeling framework. Rule for Transforming i* Actors to UML Classes: In the i* model, actors represent entities that interact with the system (e.g., User, MobileApp, IoTSystem, etc.). These actors will be transformed into UML classes, see QVT rule in Listing 1. ```
rule actor2 Class{ from iStarModel::Actor(actorName:String) to umlModel::Class(name=actorName); }
```  
Rule for Transforming i* Goals into UML Class Attributes: Goals are the intended outcomes of the system. They will be represented as attributes of the corresponding classes in the UML diagram, see QVT rule in Listing 2. ```
rulegoal2 Attribute{ from iStarModel::Goal(goalName:String) to umlModel::Attribute(name=goalName); }
```  
Rule for Transforming i* Tasks/Services to UML Methods: Tasks or services in the i* model will be transformed into methods in the corresponding UML classes, see QVT rule in Listing 3. ```
ruletask2 Method{ from iStarModel::Task(taskName:String) to umlModel::Operation(name=taskName); }
```  
Rule for Transforming i* Dependencies into UML Associations: The dependencies between actors and goals in the i* model will be transformed into associations in the UML diagram, see QVT rule in Listing 4. ```
ruledependency2 Association{ from iStarModel::Dependency(source:Actor,target:Goal) to umlModel::Association(source=source,target= \(\hookrightarrow\)target); }
```  
Rule for Transforming i* Resources to UML Classes: Resources (e.g., sensors) will be converted into UML classes representing the individual sensor components, see QVT rule in Listing 5. ```
ruleresource2 Class{  from iStarModel::Resource(resourceName: String) to umModel::Class(name=resourceName); }
```  
The transformation process follows a structured execution flow comprising four primary phases: Initialization, Matching, Execution, and Completion.