## 3 State of the Art
### IFM Framework
\begin{table}
\begin{tabular}{p{142.3 pt} p{284.5 pt}} \hline \hline
**View** & **Description** \\ \hline Process flow view & The main aim of the process flow view is to visualize the flow of sequential or parallel processes that are related to one specific use case in a qualitative manner. These processes may be interaction or transformation processes. For every use case, a set of views is generated, which is associated with the use case. In the horizontal direction, process blocks are arranged from left to right for enabling a direct link to the actor view below. Vertically, the process flow is visualized in relation to time; this corresponds to the gradual evolution of states in the associated state view. \\ \hline State view & The main aim of the state view is to represent the states from the initial state to the final state of both operands and actors and also of the changes of states associated with the related processes. \\ \hline Actor view & The main aim of the actor view is to indicate the involvement of one or more actors in the realization of processes. The involvement of these actors can be active or passive. The actors can be part of the system or can be in the surrounding of the system. \\ \hline Use case view & The main aim of the use case view is to indicate the involvement or association of processes in the different use cases. \\ \hline Effect view & The main aim of the effect view is to represent the effects that enable certain processes. The effects are provided by actors. For every process block included in the process flow view, a separate effect view can be generated. \\ \hline Interaction view & The main aim of the interaction view is to map the bilateral impacts between actors and operands and also their complementary contributions or other kinds of dependency between them in the realization of use cases and associated processes. The interaction view represents the structure of the system. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Associated views in the IFM Framework. Reprinted with permission from [17]. operands are specifications of energy, material and signals. The actors are technical systems (hard- and/or software), such as assemblies and components, which actively or passively contribute to the fulfilment of functions, as well as human beings who may be involved in carrying out a function. Furthermore, the notion of \"actors\" includes relevant parts of the surrounding that provide influences onto the system. Finally, the term \"interaction processes\" describes \"cross-boundary\" interactions between different actors that jointly contribute to the fulfilment of functions (similar to [PERSON] and [PERSON] [37], [PERSON] [38], [PERSON] et al. [39], [PERSON] [40], [PERSON] and [PERSON] [41], and [PERSON] [42]). What this means is that some processes can only be carried out through interaction from the outside (by actors that are external to the system under development); thus, these processes are visualized as part of a use case, but formally separated from processes that need to be supported by the system to be developed itself. Figure 5 shows the specific entity-relations in the IFM Framework using a UML-based diagram. A single instance of a system modeled with the IFM Framework creates an integrated function model (IF model hereafter). In principle, as the IFM Framework uses interlinked matrices, designers may start with any view to start modeling a system. This is particularly true when an existing system is modeled; for novel design projects, it might not be clear in every case where to start. Logically, designers could initiate employing the IFM by deriving the central use cases that the future technical system will have to fulfil from the given system requirements. Subsequently, the designer would determine the main processes for the use cases and would gradually detail them. This, in turn, will permit determining some of the involved operands and integrating some already known actors.