Advanced Modeling: Designing Components¶
Components are reusable models. Opening models as components aims to enhance their reusability and flexibility. This file helps device integration and management personnel quickly understand the process of designing components.
Prerequisites¶
Before creating a component, you must have edit permissions for the group where the model is located. For more information, refer to Model Management Permission Allocation.
Model Analysis¶
Consider setting a model as a component in the following scenarios:
Highly Generic Information
For instance, “Basic Device Information”, which includes general attributes such as device name, model, and manufacturing date, is suitable for abstraction into a reusable component. Other device models like wind turbines or photovoltaic inverters can reference this “Basic Device Information” component, avoiding redundant structure definitions.
Information Requiring Unified Maintenance and Updates
Some foundational information, once updated, may need to be uniformly updated across all models. For example, adding an “Administrative Region” attribute to every model. By designing it as a component, you only need to update the component once, and all models referencing it will automatically update, significantly simplifying maintenance.
Information Requiring Fine-grained Permission Management
Sensitive information, such as device MAC addresses or usage license details, can be abstracted into a separate model. Permissions to edit or delete these features can be restricted, enabling granular permission control. By abstracting such models as components and assigning them to a separate group, you can independently manage edit permissions using the group settings.
Note: Referencing a component is not limited by group boundaries. Even if a component is placed in a specific group, once shared with the current OU (Organizational Unit), models in other groups within the same OU can reference the component directly, greatly expanding its reusability.
Component Design Principles¶
When designing components, it is recommended to follow these principles:
Single Responsibility
For example, a “Geolocation” component should only include elements related to geographic information, such as latitude, longitude, and elevation, without unrelated information.
Extensibility
The design of the component should allow room for future expansion. For instance, a “Weather Information” component might initially include basic elements like temperature and humidity, with the possibility of adding rainfall and wind speed later.
Naming Regulations
The naming of components and their elements should follow a uniform standard. For example, “Geolocation” and “Basic Device Information” should have clear and meaningful names.
Complete Descriptions
Components and their internal elements should include comprehensive descriptions to explain the component’s functionality, applicable scenarios, and the meaning of each element. This ensures that other developers can quickly understand and use the components.
Operation Process¶
The process of designing components is as follows:
Create Model, and add model elements.
(Optional) If cross-OU referencing of components is required, share the component to other OUs from the developer’s OU。
Once completed, other integration personnel can Reference the Component in the designated OU .