Model of Things (MoT)

• Model of Things (MoT) is a model-driven, low-code framework that abstracts Cloud-of-Things complexity by decoupling domain logic from cloud protocols and APIs.
• MoT leverages a custom UML profile and automated transformations to generate deployable artifacts such as Node-RED flows and serverless packages, expediting development.
• Its approach fosters provider-agnostic interoperability and reduces manual integration effort, enabling rapid prototyping and ease of application deployment.

The Model of Things (MoT) is a model-driven, low-code engineering approach designed to address the complexity of developing Cloud-of-Things (CoT) applications. MoT systematically decouples domain logic from the intricacies of protocol management, disparate cloud APIs, and hand-written integration code by leveraging a custom UML profile, automated model transformations, and a tool-supported workflow. Its principal objectives are the abstraction of CoT features into high-level stereotyped models, seamless interoperability across cloud providers, and a reduction in the technical entry barrier for application development and deployment. MoT’s strategy centers on representing IoT and cloud service concepts as UML stereotypes, from which executable artifacts—such as Node-RED flows and serverless deployment packages—are generated automatically, significantly accelerating the prototyping and delivery of real-world CoT solutions (Welter et al., 16 Dec 2025).

1. Scope and Architectural Objectives

MoT targets the end-to-end software lifecycle of CoT applications with a focus on abstraction, automation, interoperability, and accessibility. The approach replaces direct manipulation of low-level network protocols (e.g., MQTT, HTTP), heterogenous cloud APIs (e.g., AWS Lambda, Azure Functions, Google Cloud Pub/Sub), and hand-authored "glue code" with a set of domain-specific UML stereotypes. Models are created strictly at the use-case level, expressing system behavior in terms of functional features (e.g., sensor subscription, data storage, dashboard rendering, event-driven notifications) linked to standardized abstractions. This model-driven paradigm allows for both rapid prototyping and decreased DevOps friction by hiding infrastructure details behind provider-agnostic interfaces. The current implementation supports behavioral modeling through UML use-case diagrams, direct mapping to IoT protocols and cloud services, and automatic generation of Node-RED workflows and serverless deployment specifications for mainstream cloud back ends (Welter et al., 16 Dec 2025).

2. UML Profile and Metamodel: MoT.Profile

Central to the MoT infrastructure is the MoT.Profile—a lightweight custom UML profile extending the UseCase metaclass. MoT.Profile introduces domain-specific stereotypes that encapsulate canonical CoT building blocks, each equipped with a minimal set of tagged values for configuration. These stereotypes enable practitioners to describe CoT concerns without explicit reference to protocols or provider APIs. Table 1 outlines the standardized stereotype taxonomy:

Category	Stereotype	Description
IoT	SensorSubscribe	Subscribe to an MQTT broker topic for sensor data streams
	SensorPublish	Publish messages to MQTT to drive actuators
Storage	DatabaseSave	Persist incoming data to a database service (e.g., MongoDB)
Dashboard	DashboardGauge	Real-time gauge widget on web dashboard
	DashboardChart	Time-series chart visualization
Social	TwitterPost	API-based Twitter posting
	SendEmail	Outbound notification via SMTP
Emotiv BCI	FacialExpression	Capture of facial expression events via Emotiv headset
	MentalCommand	Capture of mental-command events from Emotiv profile

Each stereotype is mapped to configuration parameters (e.g., brokerUrl, topic, qos for SensorSubscribe; connectionString, collectionName for DatabaseSave), supporting a declarative, model-based specification of system behavior.

3. Model-Driven Development Workflow

MoT’s workflow consists of seven orchestrated steps, enabling domain experts to generate complete CoT systems with minimal manual intervention:

1. Application Modeling: Practitioners draw UML use-case diagrams and annotate use cases with MoT.Profile stereotypes, then export the model to XMI.
2. Diagram Transformation: The MoT.Transformer ingests XMI models, scans for stereotyped use cases, and resolves each stereotype to abstract components based on a JSON mapping repository.
3. Component Configuration: Leaf components are configured through web forms that collect tagged value data (credentials, endpoints) and cloud-provider selections. Service provisioning (e.g., database instance creation) is automated as needed.
4. Model-to-Model/Text Transformation: Abstract components are translated into platform-specific artifacts, particularly Node-RED flow definitions (JSON) and serverless framework descriptors (serverless.yml), encapsulating all resolved dependencies and credentials.
5. Application Deployment: MoT.Builder executes setup scripts to install local runtimes (Node-RED, serverless framework) and bootstrap cloud resources.
6. Delivery Customization: Sensitive credentials and additional adjustments are introduced via the Node-RED browser interface or similar post-generation configuration.
7. Application Delivery: Production deployment is triggered through automated serverless deployment commands, establishing endpoints, functions, storage buckets, and dashboards in the target cloud environment.

4. Transformation and Code Generation Mechanisms

The transformation pipeline in MoT is dual-phased. The first (model-to-model) stage translates stereotyped use-case elements into an intermediate tree of abstract components, each recursively resolved via JSON mappings. The second (model-to-text) phase emits platform-specific artifacts. Notably, MoT diverges from conventional ATL (Atlas Transformation Language) code generation, instead implementing a recursive assembler and model-to-text engine. For example, a SensorSubscribe use case with the required tagged values will yield a corresponding MqttIn Node-RED node and the relevant broker configuration in the deployment script. Artifacts are bundled as Node.js projects containing all necessary Node-RED flow files, module dependencies, configuration payloads, and serverless setup scripts.

5. Toolchain Architecture

MoT’s toolchain is structured into three logically independent modules:

• MoT.Modeling: Authoring and exporting annotated UML models using standard tools (e.g., Papyrus, Modelio) supporting profiles and XMI serialization.
• MoT.Transformer: Interpreting XMI input, mapping stereotypes to abstract components, orchestrating user configuration workflows, and emitting platform artifacts. It is implemented as an ASP.NET Core web application leveraging Microsoft SQL Server and a web-based front end for user interaction and service provisioning.
• MoT.Builder: Responsible for code generation, local environment orchestration (Node-RED runtime), and automated deployment via Node.js and the Serverless Framework.

The interaction sequence involves exporting an XMI file from the UML tool, processing into a deployment-ready package by the MoT.Transformer, and then automated deployment via MoT.Builder to cloud and Node-RED targets (Welter et al., 16 Dec 2025).

6. Empirical Evaluation and Results

MoT was empirically evaluated through a case study in a hospital environment monitoring scenario and a Technology Acceptance Model (TAM) assessment. Twelve participants—all advanced students or professionals—executed the full MoT workflow on a multi-step scenario, including temperature monitoring, data storage, dashboard visualization, and alerting. The TAM questionnaire measured Perceived Ease of Use (PEOU), Perceived Usefulness (PU), Attitude Toward Use (ATU), and Behavioral Intention to Use (BI) on a five-point Likert scale.

Key results were:

• Ease of Use: 100% of participants agreed that MoT is easy to use, learn, and master.
• Usefulness: 100% perceived MoT as facilitating CoT application development, enhancing productivity, and reducing delivery time.
• Abstraction and Automation: All participants found IoT and cloud abstraction effective in reducing complexity.
• Adoption Potential: 100% agreed MoT could be used for industry CoT apps; 83% believed non-technical users could build home CoT apps with MoT.
• Qualitative Feedback: Users highlighted the convenience of stereotype-driven modeling, automatic cloud service provisioning, and the intuitiveness of post-generation flow customization in Node-RED.

No inferential statistical tests were performed due to sample size constraints.

7. Benefits, Current Limitations, and Outlook

MoT demonstrates a significant reduction in manual coding effort for MQTT integration, database connectors, and UI dashboards. Developers benefit from a rapid prototyping model leveraging familiar UML abstractions and automated, provider-agnostic deployment. However, the current support is limited to use-case diagrams and lack explicit handling of class, sequence, or activity diagrams. Automated end-to-end lifecycle support for scaling and monitoring in production remains undeveloped. Further customization beyond available stereotypes necessitates manual editing of generated flows.

Future directions include extending support to UML class and activity diagrams, integrating formal flow validation (e.g., OCL-based rules), comparative studies of development time efficiency, and broadening deployment capabilities to additional serverless and edge platforms.

The strong positive user evaluations and successful proof-of-concept deployments support the viability of MoT as an accessible, automatable, and scalable model-driven framework for CoT application development (Welter et al., 16 Dec 2025).