prescribe its use early on in the architecting process. This has not only
advantages for the architecture generation itself, but also for other usages, such
as architecture reuse. If common concepts, semantics, structures and
relationships are fused into the core of an architecture description it greatly
enhances the ease of reusing aspects of the architecture description or even
the entire architecture. This can, for instance, be interesting for architecture
development within a technology roadmap (see Section 2.1.6). Also, trust,
security, privacy, and safety are contingent upon system borders and thus on
what functionalities and hardware resides inside and outside the system border.
The IoT Domain Model readily comprises both the ―inside‖ and the ―outside‖ of a
system and provides thus a deeper insight on relations between the system
entities and also to interactions with the ―outside world.‖ For all of these
reasons, it is beneficial to conduct a domain-model analysis before embarking
actions such as threat analysis and requirement engineering.
So what are other reasons for expanding the context view ―inward,‖ namely also
covering the system itself? Why not just adding a view to the architecting,
namely the IoT Domain View, to the architecture description? The main reason
is that both models are complementary and need to be applied early on in the
architecting process. This is why we chose to pair the two system views. Notice
that the context in IoT Context View has an extended meaning to that in the
―traditional‖ context view. In the former it eludes to the context in which the
system finds itself in relation to its surrounding. The IoT Context View expands
on this by also including the entities within the system and by setting each of
these entities in relation – context! - to the other entities.
The IoT Domain Model, on the other hand, provides a semantic and ontological
overlay for the context view in which it provides guidance on the core entities of
an IoT system and how the entities relate to each other. It also aids in
identifying system boundaries, which is one of the main questions to be
addressed in the context view. For more information on the IoT Domain Model
see Section 3.3 and for guidance on how to generate a concrete IoT Domain
Model see Section 5.4.1.
Notice, that since all are listed and characterised in the IoT Context View, this is
also the natural place for where to address the roles of all entities. These roles
can for instance, be categorised as permissions, prohibitions, and obligations.
For more information on these categories the reader is referred to elsewhere in
the literature [Raymond 1995]. For a discussion of how these roles figure into
the system composition see Section 3.5.2.1).
An exhaustive discussion of the context view is available the literature [Woods
2008], but in order to increase to immediate usability of the IoT ARM we
provide a short summary below.