Academia.eduAcademia.edu

Figure 12 – uploaded by Hugo Bruneliere

See full PDFdownloadDownload figure
Figure 12: An excerpt of the AVL RDE data model

Figure 12 An excerpt of the AVL RDE data model

Related Figures (22)

Figure 1: Considered DevOps process of complex systems in the context of the MegaM@Rt2 project [40]. However, while relying on MDE and some DevOps practices, the architecture proposed in MegaM@Rt2 was not natively integrating the use of AI/M talized chitec L as one of its core element. Thus, we capi- on the MegaM@Rt2 results and on other ar- tural experiences within various collaborative projects [36, 37] in order to iterate several times on the A what DOaRt architecture. The version presented in ollows is the final result of the application of such an iterative process.
Figure 1: Considered DevOps process of complex systems in the context of the MegaM@Rt2 project [40]. However, while relying on MDE and some DevOps practices, the architecture proposed in MegaM@Rt2 was not natively integrating the use of AI/M talized chitec L as one of its core element. Thus, we capi- on the MegaM@Rt2 results and on other ar- tural experiences within various collaborative projects [36, 37] in order to iterate several times on the A what DOaRt architecture. The version presented in ollows is the final result of the application of such an iterative process.
Figure 2: Overview of the AIDOaRt architecture
Figure 2: Overview of the AIDOaRt architecture
Figure 3: Mapping between the considered DevOps phases and the AIDOaRt architecture components
Figure 3: Mapping between the considered DevOps phases and the AIDOaRt architecture components
Figure 4: A representation of the two layers of the AIDOaRt mega-model.
Figure 4: A representation of the two layers of the AIDOaRt mega-model.
Figure 5: The AIDOaRt mega-model packages. This layer provides generic capabilities that are in- tended to be used by the other toolsets. It includes
Figure 5: The AIDOaRt mega-model packages. This layer provides generic capabilities that are in- tended to be used by the other toolsets. It includes
Figure 6: Horizontal integration between solutions based on the integration of their respective architecture components.
Figure 6: Horizontal integration between solutions based on the integration of their respective architecture components.
Furthermore, Figure ¢ shows the potential utility of this component and its related solutions in ad- dressing, at least to some extent, several case study requirements regarding the need for data representa- tion (cf. the satisfy links). Similarly, Figures 8, 9 and 10 depict the applicability of technical solutions and the satisfied requirements for the Model-Based, Engagement & Analysis and AI for Modeling capa- bilities components, respectively. Figure 7: Data Representation Capabilities component from the Data Engineering Tool Set, corresponding solutions anc potential links with AIDOaRt case study scenarios.
Furthermore, Figure ¢ shows the potential utility of this component and its related solutions in ad- dressing, at least to some extent, several case study requirements regarding the need for data representa- tion (cf. the satisfy links). Similarly, Figures 8, 9 and 10 depict the applicability of technical solutions and the satisfied requirements for the Model-Based, Engagement & Analysis and AI for Modeling capa- bilities components, respectively. Figure 7: Data Representation Capabilities component from the Data Engineering Tool Set, corresponding solutions anc potential links with AIDOaRt case study scenarios.
Figure 8: Model-Based Capabilities component from the Core Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios.
Figure 8: Model-Based Capabilities component from the Core Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios.
Figure 9: Engagement & Analysis Capabilities component from the Al-Augmented Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios. 6. Evaluation
Figure 9: Engagement & Analysis Capabilities component from the Al-Augmented Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios. 6. Evaluation
Figure 10: AI for Modeling Capabilities component from the Al-Augmented Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios.
Figure 10: AI for Modeling Capabilities component from the Al-Augmented Tool Set, corresponding solutions and potential links with AIDOaRt case study scenarios.
Figure 11: An excerpt of the Testing data model, its abstract elements, and the links to the case study related concrete elements.
Figure 11: An excerpt of the Testing data model, its abstract elements, and the links to the case study related concrete elements.
Table 1: Case studies from AIDOaRt partners
Table 1: Case studies from AIDOaRt partners
Figure 13: AVL RDE case study scenarios, derived require- ments, providing solutions, and instantiated architecture com- ponents.
Figure 13: AVL RDE case study scenarios, derived require- ments, providing solutions, and instantiated architecture com- ponents.
Figure 14: Alstom (BT) case study scenario, derived require- ments, provided solutions, and instantiated architecture com- ponents.
Figure 14: Alstom (BT) case study scenario, derived require- ments, provided solutions, and instantiated architecture com- ponents.
Figure 15: Alstom (BT) case study data model. The BT case study data model is illustrated in Figure 15. It supports the processing of system re- quirements written in natural language. Each sys- tem requirement specifies the system component af- fected, which customer requirement it addresses, and the recommended team allocation. Requirements are further elaborated with a requirement response. This case study data model is mapped to the AIDOaRt mega-model (cf. Section 5.2), particularly to the Requirements Engineering package. Along with other specific data models, it served to abstract their common elements into generic ones as part of the AIDOaRt Data Representation component. An excerpt of the affected subset of elements of the mega- model is included in Figure 16.
Figure 15: Alstom (BT) case study data model. The BT case study data model is illustrated in Figure 15. It supports the processing of system re- quirements written in natural language. Each sys- tem requirement specifies the system component af- fected, which customer requirement it addresses, and the recommended team allocation. Requirements are further elaborated with a requirement response. This case study data model is mapped to the AIDOaRt mega-model (cf. Section 5.2), particularly to the Requirements Engineering package. Along with other specific data models, it served to abstract their common elements into generic ones as part of the AIDOaRt Data Representation component. An excerpt of the affected subset of elements of the mega- model is included in Figure 16.
Figure 16: Mega-model excerpt for Requirements Engineering.
Figure 16: Mega-model excerpt for Requirements Engineering.
Figure 18: An excerpt of the VCE data model (with a focus on the model recommendation aspects). Figure 17: VCE case study scenario, derived requirements, provided solutions, and instantiated architecture components
Figure 18: An excerpt of the VCE data model (with a focus on the model recommendation aspects). Figure 17: VCE case study scenario, derived requirements, provided solutions, and instantiated architecture components
Figure 19: Mapping of case study requirements to the archi- tectural components
Figure 19: Mapping of case study requirements to the archi- tectural components
Figure 20: Mapping of solutions to the architectural compo- nents
Figure 20: Mapping of solutions to the architectural compo- nents
ous results and indicates both the number of so- lutions implementing one or more of the func- tional interfaces of the architecture components and the number of case study’s functional and data requirements that are possibly satisfied by each architecture component. This shows how, as a result of applying the AIDOAaRt com- ponents mediation pattern, a large number of requirements and solutions capabilities can be organized together and abstracted by a rela- tively small number of high-level components and functional interfaces. Furthermore, the gen- eralization of requirements and data represen- tations, through the Generic Requirements Me- diation Pattern and the Data Engineering me- diation pattern respectively, further contributes to the overall integration strategy. By employ- ing the Generic Requirements Mediation Pat- tern, 126 case study-specific requirements were organized and mapped into 47 generic require- ments. At the same time, the Data Engineering Mediation Pattern facilitated a standardized ap- proach for data representation, easing the inte- gration of disparate data sources. Figure 21: Summary of the solutions and requirements map- pings to the AIDOaRt architecture components
ous results and indicates both the number of so- lutions implementing one or more of the func- tional interfaces of the architecture components and the number of case study’s functional and data requirements that are possibly satisfied by each architecture component. This shows how, as a result of applying the AIDOAaRt com- ponents mediation pattern, a large number of requirements and solutions capabilities can be organized together and abstracted by a rela- tively small number of high-level components and functional interfaces. Furthermore, the gen- eralization of requirements and data represen- tations, through the Generic Requirements Me- diation Pattern and the Data Engineering me- diation pattern respectively, further contributes to the overall integration strategy. By employ- ing the Generic Requirements Mediation Pat- tern, 126 case study-specific requirements were organized and mapped into 47 generic require- ments. At the same time, the Data Engineering Mediation Pattern facilitated a standardized ap- proach for data representation, easing the inte- gration of disparate data sources. Figure 21: Summary of the solutions and requirements map- pings to the AIDOaRt architecture components
Figure 22: Collaborations and potential indirect links between solution and case study providers
Figure 22: Collaborations and potential indirect links between solution and case study providers
Related topics:
Software EngineeringModel-Driven DevelopmentArtifical Intelligence
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved