## 5 Model Transformations
### Execution and Implementation of the Model Transformations
The figure shows the fUML activities that replace the OpaqueBehaviors (e.g., _xOp5 method$1_ and _Connector1_ConnectorCls$method$1_). For example, _xOp5 method$1_ is the fUML activity implementing the connector behavior for routing and merging requests. Figure 13(b) shows the inner model elements for this activity, and Figure 13(c) shows the internal model elements of the _structured activity node_ inside this activity. Figure 13: E2 level composite structure diagrams and UML models for the request barrier connector: (**a**) Composite structure diagram for the request barrier connector. (**b**) Composite structure diagram for the connector class. (**c**) E2 level UML model. ## 7 Application of Enhanced Connectors in Avionics Software Projects

This section presents the applications of enhanced connectors in real-life projects. We show examples from real-life projects in which using enhanced connectors simplifies the design and increases reusability. We examined six large-scale safety-critical avionics software projects. We developed a tool that searches the project model files to find cases where the application of the enhanced connectors is appropriate. We searched the model files for two cases. For the first case, we searched for classes having more than one port requiring the same interface. For the second case, we searched for classes that provide and require the same interface at multiple ports. Figure 15 illustrates the cases searched. We studied the results for both cases to determine if we can use enhanced connectors instead of existing connectors. In the following sections, first, we present background information regarding the development environment and the requirements for the projects we have studied. After that, we introduce the cases where using enhanced connectors is beneficial. Figure 14: (**a**) E3 UML model for the request barrier connector class. (**b**) E3 UML model for the request barrier connector fUML activity. (**c**) Inner elements of the E3 model request barrier connector fUML activity. ### Background

The studied projects conform to _DO-178C_, _Software Considerations in Airborne Systems and Equipment Certification_[30]. DO-178C is the primary document by which the certification authorities such as _Federal Aviation Administration_, _European Union Aviation Safety Agency_, and _Transport Canada_ approve all commercial software-based aerospace systems. Because of the inability to accurately apply reliability models to software, the concept of _development assurance_ is applied by most safety-focused industries, including the aviation industry [31]. Table 2 shows the development assurance levels defined in DO-178C according to the safety impact of functionalities implemented in software. Level-A is the highest assurance level. Errors in level-A software can have catastrophic consequences leading to the loss of the aircraft, flight crew, or attendants. Level-D defines the development assurance level with the lowest safety impact. Level-E corresponds to _no safety impact_. DO-178C defines 71 objectives, all of which must be satisfied for level-A software. Moreover, 30 of the objectives require independence for level-A software. For example, independence for software requirement reviews means that the engineers who develop the requirements cannot be the reviewer of the requirements, or they cannot develop the test cases for these requirements. In addition to DO-178C, the avionics software projects we examined conform to ARINC-653 [32]. ARINC-653 is a software specification for space and time partitioning in safety-critical avionics real-time operating systems. Implementation of the standard allows hosting multiple applications of different software development assurance levels on the same hardware in the context of _integrated modular avionics_ (IMA) [33] architecture. ARINC-653 decouples running applications from the real-time operating system using the application programming interface called the _application executive_ (APEX). Each application software is called a _partition_.