## 2 Related Work
### Stakeholder-Informing Matrices (SIM)  
We review several examples for the theory and application of SIMs, including design structure matrices, multi-domain matrices, system architecting matrices, and pivot tables. The Department of Defense Architecture Framework (DoDAF) encourages the use of matrices in some viewpoints [18]. However, there are no formal requirements for the structure or layout of the matrices. In some cases, the term _matrix_ is used to describe other tabular structures that are not matrixial in essence. For instance, a table of inputs with some attributes is not a matrix. The Unified Architecture Framework (UAF), a profile of UML, is a model-based extension of DoDAF [33]. UAF advocates that aspects of the architecture specification's traceability to operational specifications, services, resources, standards, activities, etc., are represented as matrices; however, there are no data structures or illustrations to demonstrate how matrices should be extracted from the profiles. Design Structure Matrices/Dependency Structure Matrices (DSMs) are powerful tools for analyzing interrelated aspects, comprehension, and decision making [34]. Transforming models into DSMs is studied in [35; 36; 37]. DSMs require explicit definition of row and column ontologies. This is not trivial for sematic ontology, which reflects the modeled system or domain. Multi-Domain Matrices (MDMs) extend DSMs by including multiple sets on each dimension and composing multiple matrices [38; 39]. MDMs are difficult to construct and visualize due to their size. MDMs require an underlying definition of (a) a single super-set of concept terms, (b) a set-to-set mapping for all set pairs, and (c) a member-member mapping for each pair of set members. System Architecture Matrices (SAMs) are special MDMs for system architecture analysis, e.g., a two-domain SAM that maps [Systems, Processes] to [Systems, Processes] [37]. The mapping relations can be determined per sub-SAM according to the desired analysis. An example is illustrated in Table 1a. The mappings _Instrument_, _Effect_, _Generation_, and _Consumption_ are drawn from the set of OPM relations. Additionally, the mappings _Attribute_, _Input_, _Output_, and _ID_ are defined as indirect yet more intuitive relations. For example, _Attribute_(S) is the set of model entities \(\mathrm{E_{i}}\) that participate in an _Exhibition-Characterization_ relation to S: _Exhibition_(S,\(\mathrm{E_{i}}\)) or _Characterization_(\(\mathrm{E_{i}}\)S). _Input_(\(\mathrm{P_{column}}\)) is the set of entities \(\mathrm{E_{i}}\) with an _Instrument_(\(\mathrm{E_{i}}\)P\(\mathrm{{}_{column}}\)) or _Consumption_(\(\mathrm{E_{i}}\)P\(\mathrm{{}_{column}}\)) relation to \(\mathrm{P_{column}}\). A 3x3 SAM, consisting of Processes, Operands (inputs, resources, and outputs), and Components, is illustrated in Table 1b, based on [24]. Each sub-SAM has a relation with which the row item relates to the column item, which can be static or dynamic. A row-cell-column tuple in the matrix would read: <row item (iRow)> <cell item (iRow, iCol)> <column item(iCol)>. For example: [Process P2] requires [Operand O2]; [Component C3] exhibits [Process P2]. Classifying model entities as set members (Process, Operand, Component) is a challenge. An ML that defines syntactic types simplifies identification of type-corresponding set members. However, the problem domain or solution domain may include types that exceed the ML's syntax. Even common terms such as _Stakeholder_ and _Operand_ are not  
Figure 3: Equivalent representations of relations between pairs of objects as: (**i**) a digraph, (**ii**) an adjacency matrix (cell (_r_,_c_) holds the arrow value of row object (r) to column object (c), and (**iii**) a set of tuples (triplets of source object (S), target object (T), and value (V), relating S to T.  
included in syntactically-rich MLs like SysML [40].