# Digital Twins in Software Engineering--A Systematic Literature Review and Vision
## 4 Results
### RQ3: How Can a DT Be Built in the Context of the Software Industry?
The DT generated through this approach can cover general scenarios to gain efficiency and save costs for most organizations, such as the following:  
* Test plan predictions and the impact of issues expected with the changes in a specific release cycle;
* Risk evaluation of issues in performance or by customers;
* Predictions on the time to complete a release cycle;
* An evaluation of the requirements and architecture changes involved;
* An evaluation of dependencies;
* An evaluation of budget to simulate budget consumption for project pipelines in the products roadmap;
* Anomaly detection with the flow of the release. The exchange of information between a DT and its real counterpart must be decoupled to switch on the DT or the real counterpart indistinctly. [PERSON] et al. [144] propose the construction of DTs based on web technologies with a common skeleton and a way to cooperate. The inferencing skills of the DTs can improve with this cooperation among DTs. The information exchange between the DT and the real counterpart can be achieved based on OSLC (similar to AAS). Moreover, the DT must manage the persistence and processing of data information extracted from the assets or counterparts using data repositories such as data lakes or graph databases. This ensures more capabilities for reasoning over the linked data, as with [PERSON] et al. [167]. The data extraction and preparation can take significant time in the total implementation when the expected sync rate and the harmonization of information are also important topics. Message queue systems and data lake-creating channels to operate, as in [145; 151; 165], might be required. Creating relatively rigid DTs--or DTs excessively bound to a specific vendor--would be problematic for their maintenance [134; 135; 144; 145; 146; 153; 161; 165; 167; 202]. A total of 64% of the articles speak about accelerated DT generation using metamodel languages and tools to build DTs based on a reference architecture. This approach to generating DTs in a low-code or automatized way matches the context of constantly changing organizations and the DevOps culture flows, encouraging short feedback loops. Hence, changes are pretty frequent, and a way to validate the model is implicit in the metamodel restrictions. This can also help to quickly generate DTs based on a cockpit template for different purposes. Based on the analyzed articles, metamodels are an excellent approach. They must include information to cover the following:  
* Specific notation for DT description: A level of abstraction about the definition, the status of the DT, the description, and operation (deployment, configuration, installation, and instantiation) ([PERSON] et al. [144], [PERSON] et al. [151], [PERSON] et al. [139], [PERSON] et al. [128], and [PERSON] et al. [163]). [PERSON] [116] characterizes the most relevant attributes of a DT. In contrast, [PERSON] et al. [139] also introduce a way to describe DTs with three layers and 14 characteristics and tested the approach in different scenarios. Some examples are as follows:
* A micro-language called SMOL [161];
* DT definition documents, such as DTDL, the Web of Things Description Language, or AAS ([PERSON] [144]);
* MDD with Montigem with UML, as with [PERSON] [145];
* UML + OCL, as in [151];
* A metamodel with ADOxxx, as in [202]. * Domain context: It includes the information managed in the SuS and its environment as humans, or agents to consider. [PERSON] et al. [161] explore using knowledge graphs so they can be queried algorithmically. There are even projects to create knowledge graphs for the world avatar, as in [PERSON] et al. 's study [214]. When the SuS is the developed software, [PERSON] et al. [139] comment on product architecture with DTs enabled by design, allowing products to add DTs seamlessly and offering patterns to include as part of the architectural drivers on the design of products. From an ALM perspective, some systems, such as application performance management (APM), can track the product's performance.