The goal of this service is to provide a common framework for easy creation and management of Domain and Deployment Models for LS.
Almost everyone project has to deal with some domain specific information/knowledge and with some deployment specific information (IP addresses, event topics and so on). Application specific deployment information is needed to configure LS for each particular application. Usually such deployment information is tightly connected with the domain model, as they both are related to the same objects from the physical world (e.g., buildings, rooms, appliances, sensors, actuators …). To avoid developing the same ideas several times or to hardcode deployment-specific properties of the entities it would be feasible to have a common framework for domain and deployment models, so that they all use the same concepts and data formats to describe different entities across components.
Domain and Deployment Models are going to be considered as:
- Domain Model - describing objects of the physical world relevant to the application, e.g., buildings, rooms, appliances, sensors and actuators.
- Deployment Model - describing deployment-specific properties of the entities in Domain Model, similar to the data available in the Resource Catalog, e.g., IP Address, MQTT broker/topic.
The goal is to have a common procedure to describe entities of the software systems getting build with and around LinkSmart, to have common understanding, and to increase code re-use. In the optimal case, there would be components dealing with generic application logic that can be dynamically configured and re-used across applications. For example, the Deployment Model can be used as a basis for unifying the configuration ofor other device integration components, which in turn will enable creating tools/GUI allowing to configure different Device Connectors, and etc.
Assuming that a UML is used to specify the Domain Model, encompassing at least a Class Diagram and an Object Diagram, then the Deployment Model is implemented by customization/extension of these Class and Object Diagrams. The Metadata Interchange (XMI) format will be used as standard data format to store and exchange the resulting UML models. XMI representation of the Deployment Model is used afterwards to automatically create awhich can be directly used by LinkSmart components and applications. The following diagram summarizes the overall process:
The following Class Diagram represents deployment information required by LinkSmart.
This Information should be available in the final Deployment Model. Considering a particular Domain Model as a starting point, to develop a Deployment Model from it the following actions are needed:
- Identify Domain Model classes which are kind-of LinkSmart classes (Device, Resource, …)
- Use Stereotypes to mark these classes in the Domain Model (in the UML Class Diagram)
- Extend the Domain Classes definition with attributes from the corresponding LS classes
- Identify associations in the Domain Model corresponding to associations in the LS Model
- Use stereotypes to mark/tag these associations.
The following Class and Association Stereotypes should be defined beforehand in the UML model:
- <<Device Stereotype>> - a class stereotype indicating correlation with LinkSmart Device class
- <<Resource Stereotype>> - a class stereotype indicating correlation with LinkSmart Resource class
- <<LS_association>> - an association stereotype indicating correlation with LinkSmart association (From: class Device, To: class Resource)
For Example, starting from a simple Domain Model with the following Class Diagram:
and with the following Object Diagram:
we have to identify the Domain Model classes which are kind-of LinkSmart classes and apply to them the appropriate stereotypes. Assuming that the Class_1 is a kind of LinkSmart Device and that the Class_2 is a kind of LinkSmart Resource and the association with the name Assoc is a kind of LinkSmart association, then the Domain Model Class Diagram is modified in the following form after the application of the stereotypes to it.
The Object Diagram is not much different from the original one after applying the Link Smart Stereotypes.
The current implementation is using a simplified version of the LinkSmart UML model, where the protocol information is specified as an attribute of the Resource class. The expected value is a string in JSON format as defined in the Serialization Format Specification.
The nest step is to extend the Class Definition of the identified classes with specification of additional attributes, covering the information in the respective LinkSmart classes. The names of these attributes are getting "ls_" as a prefix to easy distinguish them from the domain specific attributes in the implementation.
In the Domain Model Object Diagram we need to define appropriate values for all of the new attributes.
3. Repository Functionality
The Model Repository API section describes how the service can be used and what functions it provides.