Architecture Modeling Techniques

Techniques for modeling the architecture of a software-based system are numerous, and their study is its own substantial field within software engineering. We briefly summarize current thinking here in order to situate the work, but do not go into great depth.

Clements et al.: Documenting Software Architectures

Clements et al. state that architecture documentation consists of elements, their relations to one another, and their properties [11]. An architectural style is comprised of a “specialization of element and relation types, together with a set of constraints on how they can be used”, and the result of applying the style to a system is a view of that system’s architecture. That is, a view is “a representation of a set of system elements and the relationships associated with them.” Clements et al. identify three main categories of architectural styles:

ˆ Module Views: focus on modules, which are “implementation [units] of software that [provide] a coherent set of responsibilities.”

ˆ Component and Connector Views: focus on components, which are runtime entities that are processing units in an executing system, and connectors, which are runtime pathways of interaction between two or more components.

ˆ Allocation Views: focus on “the mapping of software units to elements of an environ- ment in which the software is developed or executes.”

Standards-Based Approaches

As in the system and medical-device safety domains, there are standards that address the techniques used to document software-based systems. Two particularly relevant standards are IEC 10746 and IEEE 42010.

IEC 10746 ISO/IEC 10746, titled Information Technology – Open Distributed Processing (ODP) focuses on five viewpoints of a system and the correspondences between them [53]. Note that, unlike Clements et al., these viewpoints do not necessarily correspond cleanly to design- or run-time constructs (e.g., modules or components, respectively) but rather “to five clear groups of users of a whole family of standards.” [54] The five viewpoints, which are summarized by Linington et al. in [54] are:

1. Enterprise: This viewpoint covers the needs of the enterprise (where enterprise is defined as “any activity of interest”), including the “objectives, business rules, and policies that need to be supported by the system being designed.”

2. Information: This viewpoint aims to synchronize the information stored and manip- ulated in the system between the other perspectives, so as to prevent incongruous definitions from cropping up amongst the viewpoints.

3. Computational: This viewpoint considers the “high-level [object-oriented] design of the processes and applications supporting the enterprise activities” and refers to the information viewpoint for the actual data stored in the particular objects. Allocation to runtime resources is not specified in this viewpoint.

4. Engineering: This viewpoint describes the interactions between the various computa- tional constructs. These descriptions form a set of guarantees provided to the compu-

tational viewpoint, which are referred to as transparencies.

5. Technology: This viewpoint considers the realization of the system in the real world, and “represents the hardware and software components of the implemented system, and the communication technology that provides links between these components.” Additionally, Linington et al. discuss the language(s) for representing ODP viewpoints, and note that textual, graphical, or machine-readable formats may be desirable for various stakeholders/tasks. The different languages and notations used by the stakeholders gives rise to the need for correspondences, which provide links between the elements of different viewpoints.

IEEE 42010 ISO/IEC/IEEE 42010, which is titled Systems and Software Engineering— Architecture Description, generalizes the notion of stakeholder-driven viewpoints [55]. Clements et al. explain that this concept is found in IEC 10746 as well as other existing approaches, “such as Kruchten’s 4+1 approach, Zachman’s Architecture Framework, and even the DoD Architecture Framework. . . ” [11] At a high level, the standard requires a) the identifica- tion of stakeholders, b) identification of their “architecture-related concerns,” c) a set of viewpoints that collectively address those concerns, d) a set of views that have a one-to-one mapping onto the set of viewpoints, e) a set of models that compose the views, and f) ra- tionale justifying the architectural decisions made [11].

Techniques Used in this Work

Clements et al. explain that the approach detailed in [11] is compatible with IEEE 42010, and provide a mapping; a similar mapping has been proposed for describing this work in terms of IEC 10746. In this work, though, we primarily use the following styles, as identified by Clements et al.:

ˆ Decomposition: This design-time, module-based style is used to relate software and hardware elements to their containing systems (e.g., MAP apps are composed of med-

ical devices and software, the software is composed of processes which are themselves made up of threads, etc.).

ˆ Pipe and Filter: This run-time, component-and-connector based style is used to show how information arrives in a component via some input port, is transformed by the component, and then leaves via some output port.

While these are some of the architectural documentation styles most well-suited to the MAP app domain, our choice was also guided to a large extent by our use of the architectural modeling language AADL.