Systemstruktur

Mit der Systemstruktur verfolgen wir die Idee, den Aufbau eines Software-Produktes zu erfassen. Entscheidungen und Konzepte aus der Architekturdefinition führen zu einer bestimmten Struktur von technischen Komponenten. Ein nachrichten-orientierter Architekturansatz mit verteilten Komponenten (Microservice) ergibt eine andere Struktur als eine Realisierung mit einem Applikationsserver und JEE-basierten Komponenten (Beans). Ein Software-Produkt hat jedoch noch weitere Strukturen. Die Entwickler nutzen Build-Projekte und Code-Repositories für die Strukturierung von Code und Unit-Tests. Innerhalb der Code-Basis gibt es sprachabhängige Konstrukte zur Definition von Namensräumen. Tester nutzen Werkzeuge wie Fitnesse, um Akzeptanz- und Integrationstests zu strukturieren. Eine weitere wichtige Dimension ist die Verteilung der Komponenten auf “echter” Hardware oder in einer Cloud.


ARC42: Bausteinsicht

Statische Zerlegung des Systems in Bausteine (Module, Komponenten, Subsysteme, Teilsysteme, Klassen, Interfaces, Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers, Funktionen, Makros, Operationen, Datenstrukturen…) sowie deren Beziehungen. Dies ist die wichtigste Sicht, die in jeder Architekturdokumentation vorhanden sein muss. Wenn Sie es mit dem Hausbau vergleichen ist das der Grundrissplan. Die Bausteinsicht ist eine hierarchische Sammlung von BlackBox- und White-Box-Beschreibungen.


ARC42: Laufzeitsicht

Diese Sicht beschreibt, wie sich die Bausteine des Systems als Laufzeitelemente (Prozesse, Tasks, Activities, Threads, …)  verhalten und wie sie zusammenarbeiten. [..] Sie müssen (insbesondere bei objektorientierten Architekturen) nicht nur die Bausteine mit ihren Schnittstellen spezifizieren, sondern auch, wie Instanzen von Bausteinen zur Laufzeit miteinander kommunizieren.


ARC42: Verteilungssicht

Diese Sicht beschreibt, in welcher Umgebung das System abläuft. Sie beschreiben die geographische Verteilung Ihres Systems oder die Struktur der Hardwarekomponenten, auf denen die Software abläuft. Sie dokumentiert Rechner, Prozessoren, Netztopologien und Kanäle, sowie sonstige Bestandteile der physischen Systemumgebung. [..] Sie sollen mit diesen Modellen die Betreiber in die Lage versetzen, die Software auch komplett und richtig zu installieren.


SWEBOK: Software Design

Design is defined as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of that process”. [..] Different high-level facets of a software design can be described and documented. These facets are often called views: “A view represents a partial aspect of a software architecture that shows specific properties of a software system”. Views pertain to distinct issues associated with software design — for example, the logical view (satisfying the functional requirements) vs. the process view (concurrency issues) vs. the physical view (distribution issues) vs. the development view (how the design is broken down into implementation units with explicit representation of the dependencies among the units). Various authors use different terminologies — like behavioral vs. functional vs. structural vs. data modeling views. In summary, a software design is a multifaceted artifact produced by the design process and generally composed of relatively independent and orthogonal views.


SWEBOK: Software Configuration Management

A system can be defined as the combination of interacting elements organized to achieve one or more stated purposes. The configuration of a system is the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product; it can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to serve a particular purpose. Configuration management (CM), then, is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle.