Create IoT Context View; Requirement process; Derive other views.Figure 66 : UML activity diagram of the IoT architecture-generation process
(requirement generation and transformation into a concrete architecture).In this figure, dashed arrows represent dependency, while solid arrows
represent control flow (can be understood as either the next step or expressing
a logical contingency of the target on the source).
As one can see, the creation of the Physical-Entity View and IoT Context View
(see Figure 65 ) are explicit activities in the architecting process. All other views
are comprised in the activity ―derive other views‖. Before we have a deeper look
into each of these activities let us come back to the question of architecture
methodology and how the IoT ARM relates to them.
5.2.3 Compatibiliy with other architecting methodologies
From Figure 66 , one could get the impression that we prescribe a sequential
approach for the generation of architectures: (1) define the scope, i.e. the
business goals; (2) create the Physical-Entity View and the IoT Context View;
(3) define requirements; and (4) generate the remaining views. Such a
sequential approach to architecting lies, for instance, at the heart of the waterfall
approach [Royce 1970]. This interpretation of Figure 66 is indeed true if one
understands all arrows in Figure 66 as arrows in time. However, they can also
be understood as logical contingencies. For instance, in order to conduct the
requirement process one needs a set of formulated business goals, an IoT
Context View, and a Physical-Entity View. If one interprets the process
described in this section in the latter way, it can be mapped onto a plethora of
popular architecting methodologies, such as Model-Driven Engineering