## 3 Development of SoS Metamodels and Ontologies
### Extending SoS Ontologies Based on Flow
#### 3.3.1 Rationale and Related Concepts  
SoS is distinguished from a single system by the managerial and operational independence of the CSs [46]. To fully describe and model SoS, strategic domain views are needed to account for \"managerial independence\", and operational domain views are required to address \"operational independence\" [47]. This study focuses on both strategic and operational domains. Selecting architecture views and their sequence for a domain is challenging due to various model kinds (e.g., taxonomy, structure, connectivity, and process), capturing unique descriptions of SoS architecture. Flow-based functional representation [46] is a common approach in SE to characterize functions as transformations of flows. However, analyzing SoS architecture requires considering multiple domains and model kinds, and various flows and relationships must be described to reflect the main concerns of the different model kinds. Figure 3: OWL-based representation of SoS ontologies. This study proposes six model kinds and corresponding relationships and flows for them, as shown in Table 2. Instead of solely relying on the model kind's name, engineers can identify the focus of architecture views by examining the proposed relationships and flows. For example, a generalization relationship is defined as a hierarchical structure whereby a specialized (child) element is developed based on a more generalized (parent) element. The proposed context flow visually links general elements, enhancing the semantic interpretation of the generalization relationship. The context flow does not provide any specific properties of the flow but serves a schematic function within the relationship. A composition represents a whole-part relationship and is a type of aggregation. A dependency relationship between elements, similar to supporting functions [38], represents prerequisites that enable other elements. A connector flow summarizes exchanges of information, systems, personnel, and energy, among other things. A message flow defines specific communication between elements during an interaction. An edge flow signifies the flow of objects or information between activities, while a transition denotes a change in the state of the system or object being modeled. This study defines relationships and flows based on the Tuple from IDEAS for architecture modeling in the strategic and operational domains. Figure 4 illustrates three relationships for capturing capabilities in the strategic domain and another three relationships and five flows for the operational domain. As illustrated in Figure 1, the performer exhibits capability, represented by activities capturing a logical process. The specific relationships/flows that describe the operational performer are OperationalContext, PerformerGeneralization, PerformerComposition, OperationalConnector, and OperationalMessage, while those used to describe the operational process are ActivityComposition, OperationalActivityEdge, and Transition. Three questions should be answered to construct AFs for SoS architecture based on the relationships and flows in the early design phase: \begin{table}
\begin{tabular}{c c c} \hline \hline
**Model Kinds** & **Relationships** & **Flows** \\ \hline Taxonomy (Tx) & Generalization & Context \\ Structure (Sr) & Composition & / \\ Connectivity (Cn) & Dependency & Connector \\ Sequences (Sq) & / & Message \\ Process (Pr) & / & Edge \\ State (St) & / & Transition \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Relationships and flows in selected model kinds. Figure 4: Flow-based representation in strategic and operational domains. How to identify the general and specialized elements of the generalization relationship in the strategic domain? How to identify the context flow in the operational domain based on the capability analysis? How to identify the edge flow's source, target, and swimlanes? These questions connect the mission and capability analysis, strategic and operational domains, and operational engineering activity.