Disclaimer

I provide absolutely no guarantee, neither for the accuracy of this documentation nor for any property or feature of the software described here.

Do not use this software in critical situations or projects.

1. Einführung und Ziele

Dukecon ist eine Anwendung zur Visualisierung von Konferenzenprogrammen. Die Idee ist auf der Javaland 2015 entstanden.

1.1. Aufgabenstellung

Beim Besuch einer Konferenz möchte man sich vor Ort über die nächsten Vorträge informieren. Oftmals ist der Zugriff auf das Internet und damit auf die Webseite der Konferenz stark eingeschränkt. Das Ziel von Dukecon ist das Bereitstellen des Konferenzprogramms auf mobilen Geräten, wobei man nach einem initialen Holen der Daten auch offline arbeiten können muß.

Da viele Besucher im Vorfeld einer Konferenz das Programm auf anderen Geräten (Desktoprechner, Laptop, Tablet) anschauen und ggf. Favoriten auswählen, soll die Sychronisation über die verschiedenen Geräte erfolgen können, so dass vor Ort auf dem mobilen Endgerät die ausgewählten Vorträge wieder angezeigt werden können.

1.2. Qualitätsziele

  • Offlinefähigkeit

  • Bedienbarkeit

  • Datensicherheit

  • Synchronisation über verschiedene Clients

  • Anwendbar auf verschiedene Konferenzen

1.3. Stakeholder

Die folgende Tabelle zeigt Ihre konkreten Stakeholder für das System sowie deren Interessen oder Beteiligung.

Tabelle 1. Stakeholder des Systems
Rolle Beschreibung

Auftraggeber

DOAG/iJUG für die Javaland-Konferenz

Fachbereich

DOAG und Kern-Team

Entwickler

JUG Darmstadt, JUG Kaiserslautern und Einzelpersonen

Betrieb

Wartung der Stage- und Produktionsumgebungen

Tester

Treffen beim Usability-Testessen

Kern-Team

Entwickler, Architekten, Betriebler

Anwender

Konferenzbesucher

2. Randbedingungen

(engl.: Architecture Constraints)

Inhalt

Fesseln, die Software-Architekten in ihren Freiheiten bezüglich des Entwurfs oder des Entwicklungsprozesses einschränken.

Motivation

Architekten sollten klar wissen, wo Ihre Freiheitsgrade bezüglich Entwurfsentscheidungen liegen und wo sie Randbedingungen beachten müssen. Randbedingungen können vielleicht noch verhandelt werden, zunächst sind sie aber da.

Form

Informelle Listen, gegliedert nach den Unterpunkten dieses Kapitels.

Beispiele

siehe Unterkapitel

Hintergründe

Im Idealfall sind Randbedingungen durch die Anforderungen vorgegeben, spätestens die Architekten müssen sich dieser Randbedingungen bewusst sein.

Den Einfluss von Randbedingungen auf Software- und Systemarchitekturen beschreibt [Hofmeister+1999] (Software-Architecture, A Practical Guide, Addison-Wesley 1999) unter dem Stichwort „Global Analysis“.

2.1. Technische Randbedingungen

Inhalt

Tragen Sie hier alle technischen Randbedingungen ein. Zu dieser Kategorie gehören Hard- und Software-Infrastruktur, eingesetzte Technologien (Betriebssysteme, Middleware, Datenbanken, Programmiersprachen, …​).

Tabelle 2. Technische Randbedingungen
Hardware-Vorgaben

Randbedingung1

Randbedingung2

Software-Vorgaben

Randbedingungi

Vorgaben des Systembetriebs

Randbedingungj

Programmiervorgaben

Randbedingungk

2.2. Organisatorische Randbedingungen

Inhalt

Tragen Sie hier alle organisatorischen, strukturellen und ressourcenbezogenen Randbedingungen ein. Zu dieser Kategorie gehören auch Standards, die Sie einhalten müssen und juristische Randbedingungen.

2.2.1. Organisation und Struktur

<hier Randbedingungen einfügen>

2.2.2. Ressourcen (Budget, Zeit, Personal)

<hier Randbedingungen einfügen>

2.2.3. Organisatorische Standards

<hier Randbedingungen einfügen>

2.2.4. Juristische Faktoren

<hier Randbedingungen einfügen>

2.3. Konventionen

Inhalt

Fassen Sie unter dieser Überschrift alle Konventionen zusammen, die für die Entwicklung der Software-Architektur relevant sind.

Form

Entweder die Konventionen als Kapitel hier direkt einhängen oder aber auf entsprechende Dokumente verweisen.

Beispiele
  • Programmierrichtlinien

  • Dokumentationsrichtlinien

  • Richtlinien für Versions- und Konfigurationsmanagement

  • Namenskonventionen

3. Kontextabgrenzung

dukecon systemcontext

3.1. Schnittstellen

Die DukeCon Anwendung kommuniziert mit seiner Umgebung über folgende Schnittstellen:

DOAG Backoffice (externes System):

Als Datenlieferant nutzt DukeCon eine BackOffice-Lösung der DOAG (Deutsche ORACLE-Anwendergruppe e.V.). Ein Back-Officer der DOAG aktualisiert das Konferenzprogramm, aktualisierte Daten stehen damit auch der DukeCon-Anwendung zur Verfügung.

Konferenzteilnehmer (Anwender):

Die DukeCon-Anwendung offeriert eine Benutzungsschnittstelle für Konferenzteilnehmer. Sie ermöglicht das Zusammenstellen und Abrufen des Konferenzplanes.

3.2. Technologien:

DOAG-Backoffice Lösung und DukeCon-Anwendung:

Übertragung der Konferenzdaten aus der DOAG-Backoffice Lösung in die DukeCon-Anwendung mittels eines REST-Services. (Beispiel-Datensatz)

DukeCon-Anwendung und Konferenzteilnehmer:

Nutzungsschnittstelle implementiert in HTML5 mit JavaScript auf Basis von Knockout. Parallel dazu ist eine natives Frontend auf Basis von Flex implementiert.

4. Lösungsstrategie

Inhalt

Kurzer Überblick über Ihre grundlegenden Entscheidungen und Lösungsansätze, die jeder, der mit der Architektur zu tun hat, verstanden haben sollte.

Motivation

Dieses Kapitel motiviert übergreifend die zentralen Gestaltungskriterien für Ihre Architektur. Beschränken Sie sich hier auf das Wesentliche. Detailentscheidungen können immer noch bei den einzelnen Bausteinen oder im Kapitel 10 festgehalten werden. Das Kapitel soll Ihren Lesern die gewählte Strategie verdeutlichen.

Form

Fassen Sie auf wenigen Seiten die Beweggründe für zentrale Entwurfsentscheidungen zusammen. Motivieren Sie ausgehend von Aufgabenstellung, Qualitätszielen und Randbedingungen, was Sie entschieden haben und warum Sie so entschieden haben. Verweisen Sie – wo nötig – auf weitere Ausführungen in Folgekapiteln.

=== Einstiegshilfe

In diesem Kapitel beschreiben wir Stellen im Code anhand von Klassen oder Methode, an denen wichtige fachliche Funktionalität implementiert ist und/oder die im weiteren Lebenszyklus der Anwendung potenziell geändert werden.

Tabelle 3. Einstiegshilfe
Fall Konsequenz Stelle Hinweise

(Beispiel:) Neue Entität einführen

Ggf. neue UseCases implementieren

de.arc42.sample.ManagerCRUDImpl

ggf Factory Methoden erweitern

5. Bausteinsicht

Inhalt

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.

Motivation

Dies ist die wichtigste Sicht, die in jeder Architekturdokumentation vorhanden sein muss. In der Analogie zum Hausbau bildet die Bausteinsicht den Grundrissplan.

Form

Die Bausteinsicht ist eine hierarchische Sammlung von Blackbox- und Whitebox- Beschreibungen (siehe Abbildung unten):

Baustein Sichten

Ebene 1 ist die Whitebox-Beschreibung des Gesamtsystems (System under Development / SUD) mit den Blackbox- Beschreibungen der Bausteine des Gesamtsystems

Ebene 2 zoomt dann in einige Bausteine der Ebene 1 hinein. Sie enthält somit alle vorhandenen Whitebox-Beschreibungen von Bausteinen der Ebene 1, zusammen mit den Blackbox-Beschreibungen der Bausteine von Ebene 2.

Ebene 3 zoomt in einige Bausteine der Ebene 2 hinein, usw.

Whitebox-Template

Enthält mehrere Bausteine (== Blackboxes), zu denen Sie jeweils eine Blackbox Beschreibung erstellen können.

Blackbox-Template (Kurzfassung)

Für jeden Baustein aus dem White-Box-Template können Sie folgende Angaben machen: (Kopieren Sie diese Punkte in die folgenden Unterkapitel)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 4. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

(eine ausführlichere Fassung des Blackbox-Templates finden Sie weiter unten.)

5.1. Whitebox Gesamtsystem

An dieser Stelle beschreiben Sie die Whitebox-Sicht der Ebene 1 gemäß dem Whitebox-Template.

Das Überblicksbild zeigt das Innenleben des Gesamtsystems mit den darin enthaltenen Bausteinen 1 .. n, sowie deren Zusammenhänge und Abhängigkeiten.

Begründen Sie die Struktur: Warum gibt es diese Bausteine mit diesen Abhängigkeiten/Schnittstellen.

Erklären Sie ggfs. auch verworfene Alternativen, mitsamt Begründung, warum sie verworfen wurden.

Bausteinname Whitebox

Übersicht / Struktur

Die folgende Abbildung zeigt die inneren Bestandteile von _Bausteinname und deren Abhängigkeiten.

<hier Überblicksdiagramm einfügen>

Begründung

Begründen oder erläutern Sie die Struktur

Enthaltene Bausteine

hier beschreiben Sie (kurz) Name und Zweck der enhaltenen Bausteine

Baustein 1

Beschreibung 1

Verweis auf Blackbox-Beschreibung

Baustein 2

 Beschreibung 2

Verweis auf Blackbox-Beschreibung

Baustein 3

Beschreibung 3

Schnittstellen

hier beschreiben Sie (kurz) Name und Zweck der (internen+externen) Schnittstellen der Bausteine.

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

dukecon architecture

5.1.1. Baustein 1 (Blackbox)

Beschreiben Sie diesen Baustein anhand des Blackbox-Templates. Nachfolgend finden Sie eine kompakte und eine ausführliche Fassung davon.

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 5. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 6. Schnittstellen Bausteinname

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Tabelle 7. Erfüllte Anforderungen

Anforderung 1

Bemerkung 1

Anforderung 2

 Bemerkung 2

Anforderung 3

Bemerkung 3

Variabilität: hier beschreiben Sie, in welchen Aspekten der Baustein variabel, flexibel oder konfigurierbar ist.

Tabelle 8. Offene Punkte

OP 1

Bemerkung 1

OP 2

 Bemerkung 2

OP 3

Bemerkung 3

Tabelle 9. Organisatorisches

Version

Bemerkung 1

Autor

 Bemerkung 2

Änderungsdatum

Bemerkung 3

(…​)

…​

(In den folgenden Abschnitten finden Sie nur noch die Kurzfassung des Blackbox-Template)

5.1.2. HTML5 Client (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 10. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

5.1.3. Baustein n (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 11. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

5.2. Ebene 2

An dieser Stelle können Sie den inneren Aufbau (einiger) Bausteine aus Ebene 1 als Whitebox beschreiben.

5.2.1. Baustein 1 (Whitebox)

  • …​zeigt das Innenleben von Baustein 1 in Diagrammform mit den lokalen Bausteinen 1.1 - 1.n, sowie deren Zusammenhänge und Abhängigkeiten.

  • begründet diese Struktur

Bausteinname Whitebox

Übersicht / Struktur

Die folgende Abbildung zeigt die inneren Bestandteile von _Bausteinname und deren Abhängigkeiten.

<hier Überblicksdiagramm einfügen>

Begründung

Begründen oder erläutern Sie die Struktur

Enthaltene Bausteine

hier beschreiben Sie (kurz) Name und Zweck der enhaltenen Bausteine

Baustein 1

Beschreibung 1

Verweis auf Blackbox-Beschreibung

Baustein 2

 Beschreibung 2

Verweis auf Blackbox-Beschreibung

Baustein 3

Beschreibung 3

Schnittstellen

hier beschreiben Sie (kurz) Name und Zweck der (internen+externen) Schnittstellen der Bausteine.

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Baustein 1.1 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 12. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 1.2 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 13. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 1.n (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 14. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

5.2.2. HTML5 Client (Whitebox)

  • …​zeigt das Innenleben von Baustein 2 in Diagrammform mit den lokalen Bausteinen 2.1 - 2.n, sowie deren Zusammenhänge und Abhängigkeiten.

  • begründet diese Struktur

Bausteinname Whitebox

Übersicht / Struktur

Die folgende Abbildung zeigt die inneren Bestandteile von _Bausteinname und deren Abhängigkeiten.

<hier Überblicksdiagramm einfügen>

Begründung

Begründen oder erläutern Sie die Struktur

Enthaltene Bausteine

hier beschreiben Sie (kurz) Name und Zweck der enhaltenen Bausteine

Baustein 1

Beschreibung 1

Verweis auf Blackbox-Beschreibung

Baustein 2

 Beschreibung 2

Verweis auf Blackbox-Beschreibung

Baustein 3

Beschreibung 3

Schnittstellen

hier beschreiben Sie (kurz) Name und Zweck der (internen+externen) Schnittstellen der Bausteine.

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

html5 architecture
Baustein 2.1 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 15. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 2.2 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 16. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 2.n (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 17. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

5.2.3. Baustein 3 (Whitebox)

  • …​zeigt das Innenleben von Baustein 3 in Diagrammform mit den lokalen Bausteinen 3.1 - 3.n, sowie deren Zusammenhänge und Abhängigkeiten.

  • begründet diese Struktur

<Hier Whitebox-Erläuterung für Baustein 3 einfügen>

Baustein 3.1 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 18. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 3.2 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 19. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 3.n (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 20. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

5.3. Ebene 3

An dieser Stelle können Sie den inneren Aufbau (einiger) Bausteine aus Ebene 2 als Whitebox beschreiben.

Welche Bausteine Ihres Systems Sie hier beschreiben, müssen Sie selbst entscheiden. Bitte stellen Sie dabei Relevanz vor Vollständigkeit. Skizzieren Sie wichtige, überraschende, riskante, komplexe oder besonders volatile Bausteine. Normale, einfache oder standardisierte Teile sollten Sie weglassen.

5.3.1. Baustein 1.1 (Whitebox)

  • …​zeigt das Innenleben von Baustein 1.1 in Diagrammform mit den lokalen Bausteinen 1.1.1 - 1.1.n, sowie deren Zusammenhänge und Abhängigkeiten.

  • begründet diese Struktur

Bausteinname Whitebox

Übersicht / Struktur

Die folgende Abbildung zeigt die inneren Bestandteile von _Bausteinname und deren Abhängigkeiten.

<hier Überblicksdiagramm einfügen>

Begründung

Begründen oder erläutern Sie die Struktur

Enthaltene Bausteine

hier beschreiben Sie (kurz) Name und Zweck der enhaltenen Bausteine

Baustein 1

Beschreibung 1

Verweis auf Blackbox-Beschreibung

Baustein 2

 Beschreibung 2

Verweis auf Blackbox-Beschreibung

Baustein 3

Beschreibung 3

Schnittstellen

hier beschreiben Sie (kurz) Name und Zweck der (internen+externen) Schnittstellen der Bausteine.

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Baustein 1.1.1 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 21. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

Baustein 1.1.2 (Blackbox)

Bausteinname Blackboxbeschreibung

Zweck: hier beschreiben Sie Zweck oder Verantwortung des Bausteins

Tabelle 22. Schnittstellen Bausteinname:

Schnittstelle 1

Beschreibung 1

Schnittstelle 2

 Beschreibung 2

Schnittstelle 3

Beschreibung 3

Ablageort/Datei: Verweisen Sie auf den Einstieg in den Sourcecode, den/die Paket-/Modulnamen oder die wichtigsten Klassen

6. Laufzeitsicht

Inhalt

Diese Sicht beschreibt, wie sich die Bausteine des Systems als Laufzeitelemente (Prozesse, Tasks, Activities, Threads, …​) verhalten und wie sie zusammenarbeiten.

Als alternative Bezeichnungen finden Sie dafür auch:

  • Dynamische Sichten

  • Prozesssichten

  • Ablaufsichten

Suchen Sie sich interessante Laufzeitszenarien heraus, z.B.:

  • Wie werden die wichtigsten Use-Cases durch die Architekturbausteine bearbeitet?

  • Welche Instanzen von Architekturbausteinen gibt es zur Laufzeit und wie werden diese gestartet, überwacht und beendet?

  • Wie arbeiten Systemkomponenten mit externen und vorhandenen Komponenten zusammen?

  • Wie startet das System (etwa: notwendige Startskripte, Abhängigkeiten von externen Subsystemen, Datenbanken, Kommunikationssystemen etc.)?

Anmerkung: Kriterium für die Auswahl der möglichen Szenarien (d.h. Abläufe) des Systems ist deren Architekturrelevanz. Es geht nicht darum, möglichst viele Abläufe darzustellen, sondern eine angemessene Auswahl zu dokumentieren. Kandidaten sind:

  1. Die wichtigsten 3-5 Anwendungsfälle

  2. Systemstart

  3. Das Verhalten an den wichtigsten externen Schnittstellen

  4. Das Verhalten in den wichtigsten Fehlerfällen

Motivation

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.

Form

Dokumentieren Sie die ausgesuchten Laufzeitszenarien mit UML-Sequenz-, Aktivitäts-, oder Kommunikationsdiagrammen. Mit Objektdiagrammen können Sie Schnappschüsse der existierenden Laufzeitobjekte darstellen und auch instanziierte Beziehungen. Die UML bietet dabei die Möglichkeit zwischen aktiven und passiven Objekten zu unterscheiden.

6.1. Login mit Keycloak

Login sequence
Abbildung 1. Login sequence
Login sequence with social provider
Abbildung 2. Login sequence with social provider

6.2. Laufzeitszenario 2

  • Laufzeitdiagramm

  • Erläuterung der Besonderheiten bei dem Zusammenspiel der Bausteininstanzen in diesem Diagramm

…​

7. Verteilungssicht

Inhalt

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. Die Verteilungssicht zeigt das System aus Betreibersicht. Zeigen Sie in dieser Sicht auch, wie die Bausteine des Systems zu Verteilungsartefakten zusammengefasst oder –gebaut werden (engl. deployment artifacts oder deployment units).

Motivation

Software ohne Hardware tut wenig. Das Minimum, was Sie als Software-Architekt daher brauchen, sind so viele Angaben zu der zugrunde liegenden (Hardware-) Verteilung, dass Sie jeden Software-Baustein, der für den Betrieb interessant ist, irgendwelchen Hardware-Einheiten zuordnen können. (Das gilt auch für Standardsoftware, die Voraussetzung für das Funktionieren des Gesamtsystems ist). Sie sollen mit diesen Modellen die Betreiber in die Lage versetzen, die Software auch komplett und richtig zu installieren.

Form

Die UML stellt mit Verteilungsdiagrammen (Deployment diagrams) eine Diagrammart zur Verfügung, um diese Sicht auszudrücken. Nutzen Sie diese, evtl. auch geschachtelt, wenn Ihre Verteilungsstruktur es verlangt. (Das oberste Deployment- Diagramm sollte bereits in Ihrer Kontextsicht enthalten sein mit Ihrer Infrastruktur als EINE Black-Box. Jetzt zoomen Sie in diese Infrastruktur mit weiteren Deployment- Diagrammen hinein. Andere Diagramme Ihrer Hardware-Kollegen, die Prozessoren und Kanäle darstellen sind hier ebenfalls einsetzbar. Abstrahieren Sie aber auf die Aspekte, die für die Software-Verteilung relevant sind.

7.1. Infrastruktur Ebene 1

7.1.1. Verteilungsdiagramm Ebene 1

  • zeigt das Verteilung des Gesamtsystems auf 1 - n Prozessoren (oder Standorte) sowie die physischen Verbindungskanäle zwischen diesen.

  • beschreibt wichtige Begründungen, die zu dieser Verteilungsstruktur, d.h. zur Auswahl der Knoten und zhur Auswahl der Kanäle führten

  • verweist evtl. auf verworfene Alternativen (mit der Begründung, warum es verworfen wurden

7.1.2. Prozessor 1

Struktur gemäß Knoten-Template (node-template):

  • Beschreibung

  • Leistungsmerkmale

  • Zugeordnete Software- Bausteine

  • Sonstige Verwaltungsinformationen

  • Offene Punkte

7.1.3. Prozessor 2

Struktur gemäß Knoten-Template:

  • Beschreibung

  • Leistungsmerkmale

  • Zugeordnete Software- Bausteine

  • Sonstige Verwaltungsinformationen

  • Offene Punkte

…​

7.1.4. Prozessor n

Struktur gemäß Knoten-Template:

  • Beschreibung

  • Leistungsmerkmale

  • Zugeordnete Software- Bausteine

  • Sonstige Verwaltungsinformationen

  • Offene Punkte

7.1.5. Kanal 1

Inhalt

Spezifikation der Eigenschaften des Kanals, soweit für die Software- Architektur interessant ist.

Motivation

Spezifizieren Sie mindestens die Eigenschaften der Übertragungskanäle, die Sie brauchen, um nicht-funktionale Anforderungen nachzuweisen, wie maximaler Durchsatz, Störungswahrscheinlichkeiten oder ähnliche.

Form

Verwenden Sie ein ähnliches Muster wie für die Prozessorspezifikationen. Oftmals verweisen Sie auf einen Standard (z.B: CAN-Bus, 10Mbit Ethernet, Druckerkabel, …​).

7.2. Infrastruktur Ebene 2

Inhalt

Weitere Deploymentdiagramme mit gleicher Beschreibungsstruktur wie oben.

Motivation

Zur Verfeinerung der Infrastruktur soweit, wie Sie es für die Verteilung der Software benötigen.

8. Konzepte

Inhalt

Die folgenden Kapitel sind Beispiele für übergreifende Aspekte.

Falls einige der Aspekte für Ihr Projekt nicht wichtig sind oder nicht zutreffen, so halten Sie diese Information ebenfalls fest, anstatt das Kapitel zu löschen.

Motivation

Manche der Aspekte lassen sich nur schwer "zentral" als Baustein in der Architektur unterbringen (z.B. das Thema "Sicherheit". Hier ist der Platz im Template, wo Sie Konzepte zu derartigen Themen geschlossen behandeln können.

Alle Aspekte, die in der Architektur an vielen Stellen Konsequenzen zeigen, beispielsweise ein Domänen-/Fachklassen- oder Business-Modell, haben ebenfalls hier einen guten Platz.

Schließlich kommen manche Strukturen in der Architektur wiederholt vor, beispielsweise ein an mehreren Stellen eingesetztes Pattern. Auch solche Aspekte können Sie hier zentral erläutern.

Form

Kann vielfältig sein. Teilweise Konzeptpapiere mit beliebiger Gliederung, teilweise auch übergreifende Modelle/Szenarien mit Notationen, die Sie auch in den Architektursichten nutzen.

8.1. Fachliche Strukturen und Modelle

Fachliche Modelle, Domänenmodelle, Business-Modelle – sie alle beschreiben Strukturen der reinen Fachlichkeit, also ohne Bezug zur Implementierungs- oder Lösungstechnologie.

Oftmals tauchen Teile solcher fachlichen Modelle an vielen Stellen in der Architektur, insbesondere der Bausteinsicht, wieder auf.

8.2. Typische Muster und Strukturen

Oftmals tauchen einige typische Lösungsstrukturen oder Grundmuster an mehren Stellen der Architektur auf. Beispiele dafür sind die Abhängigkeiten zwischen Persistenzschicht, Applikation sowie die Anbindung grafischer Oberflächen an die Fach- oder Domänenobjekte. Solche wiederkehrenden Strukturen beschreiben Sie möglichst nur ein einziges Mal, um Redundanzen zu vermeiden. Dieser Abschnitt erfüllt genau diesen Zweck.

8.3. Persistenz

Persistenz (Dauerhaftigkeit, Beständigkeit) bedeutet, Daten aus dem (flüchtigen) Hauptspeicher auf ein beständiges Medium (und wieder zurück) zu bringen.

Einige der Daten, die ein Software-System bearbeitet, müssen dauerhaft auf einem Speichermedium gespeichert oder von solchen Medien gelesen werden:

  • Flüchtige Speichermedien (Hauptspeicher oder Cache) sind technisch nicht für dauerhafte Speicherung ausgelegt. Daten gehen verloren, wenn die entsprechende Hardware ausgeschaltet oder heruntergefahren wird.

  • Die Menge der von kommerziellen Software-Systemen bearbeiteten Daten übersteigt üblicherweise die Kapazität des Hauptspeichers.

  • Auf Festplatten, optischen Speichermedien oder Bändern sind oftmals große Mengen von Unternehmensdaten vorhanden, die eine beträchtliche Investition darstellen.

Persistenz ist ein technisch bedingtes Thema und trägt nichts zur eigentlichen Fachlichkeit eines Systems bei. Dennoch müssen Sie sich als Architekt mit dem Thema auseinander setzen, denn ein erheblicher Teil aller Software-Systeme benötigt einen effizienten Zugriff auf persistent gespeicherte Daten. Hierzu gehören praktisch sämtliche kommerziellen und viele technischen Systeme. Eingebettete Systeme (embedded systems ) gehorchen jedoch oft anderen Regeln hinsichtlich ihrer Datenverwaltung.

8.4. Benutzungsoberfläche

IT-Systeme, die von (menschlichen) Benutzern interaktiv genutzt werden, benötigen eine Benutzungsoberfläche. Das können sowohl grafische als auch textuelle Oberflächen sein.

8.5. Ergonomie

Ergonomie von IT-Systemen bedeutet die Verbesserung (Optimierung) deren Benutzbarkeit aufgrund objektiver und subjektiver Faktoren. Im Wesentlichen zählen zu ergonomischen Faktoren die Benutzungsoberfläche, die Reaktivität (gefühlte Performance) sowie die Verfügbarkeit und Robustheit eines Systems.

8.6. Ablaufsteuerung

Ablaufsteuerung von IT-Systemen bezieht sich sowohl auf die an der (grafischen) Oberfläche sichtbaren Abläufe als auch auf die Steuerung der Hintergrundaktivitäten. Zur Ablaufsteuerung gehört daher unter anderem die Steuerung der Benutzungsoberfläche als auch die Workflow-Steuerung.

8.7. Transaktionsbehandlung

Transaktionen sind Arbeitsschritte oder Abläufe, die entweder alle gemeinsam oder gar nicht durchgeführt werden. Der Begriff stammt aus den Datenbanken - wichtiges Stichwort hier sind ACID-Transaktionen (atomar, consistent, isolated, durable).

8.8. Sessionbehandlung

Eine Session, auch genannt Sitzung, bezeichnet eine stehende Verbindung eines Clients mit einem Server. Den Zustand dieser Sitzung gilt es zu erhalten, was insbesondere bei der Nutzung zustandsloser Protokolle (etwa HTTP) wichtige Bedeutung hat. Sessionbehandlung stellt für Intra- und Internetsysteme eine kritische Herausforderung dar und beeinflusst häufig die Performance eines Systems.

8.9. Sicherheit

Die Sicherheit von IT-Systemen befasst sich mit Mechanismen zur Gewährleistung von Datensicherheit und Datenschutz sowie Verhinderung von Datenmissbrauch.

Typische Fragestellungen sind:

  • Wie können Daten auf dem Transport (beispielsweise über offene Netze wie das Internet) vor Missbrauch geschützt werden?

  • Wie können Kommunikationspartner sich gegenseitig vertrauen?

  • Wie können sich Kommunikationspartner eindeutig erkennen und vor falschen Kommunikationspartner schützen?

  • Wie können Kommunikationspartner die Herkunft von Daten für sich beanspruchen (oder die Echtheit von Daten bestätigen)?

Das Thema IT-Sicherheit hat häufig Berührung zu juristischen Aspekten, teilweise sogar zu internationalem Recht.

8.10. Kommunikation und Integration mit anderen IT-Systemen

Kommunikation: Übertragung von Daten zwischen System-Komponenten. Bezieht sich auf Kommunikation innerhalb eines Prozesses oder Adressraumes, zwischen unterschiedlichen Prozessen oder auch zwischen unterschiedlichen Rechnersystemen.

Integration: Einbindung bestehender Systeme (in einen neuen Kontext). Auch bekannt als: (Legacy) Wrapper, Gateway, Enterprise Application Integration (EAI).

8.11. Verteilung

Verteilung: Entwurf von Software-Systemen, deren Bestandteile auf unterschiedlichen und eventuell physikalisch getrennten Rechnersystemen ablaufen.

Zur Verteilung gehören Dinge wie der Aufruf entfernter Methoden (remote procedure call, RPC), die Übertragung von Daten oder Dokumenten an verteilte Kommunikationspartner, die Wahl passender Interaktionsstile oder Nachrichtenaustauschmuster (etwa: synchron / asynchron, publish- subsribe, peer-to-peer).

8.12. Plausibilisierung und Validierung

Wo und wie plausibilisieren und validieren Sie (Eingabe-)daten, etwa Benutzereingaben?

8.13. Ausnahme-/Fehlerbehandlung

Wie werden Programmfehler und Ausnahmen systematisch und konsistent behandelt?

Wie kann das System nach einem Fehler wieder in einen konsistenten Zustand gelangen? Geschieht dies automatisch oder ist manueller Eingriff erforderlich?

Dieser Aspekt hat mit Logging, Protokollierung und Tracing zu tun.

Welche Art Ausnahmen und Fehler behandelt ihr System? Welche Art Ausnahmen werden an welche Außenschnittstelle weitergeleitet und welche Ausnahmen behandelt das System komplett intern?

Wie nutzen Sie die Exception-Handling Mechanismen ihrer Programmiersprache? Verwenden Sie checked- oder unchecked-Exceptions?

8.14. Management des Systems & Administrierbarkeit

Größere IT-Systeme laufen häufig in kontrollierten Ablaufumgebungen (Rechenzentren) unter der Kontrolle von Operatoren oder Administratoren ab. Diese Stakeholder benötigen einerseits spezifische Informationen über den Zustand der Programme zur Laufzeit, andererseits auch spezielle Eingriffs- oder Konfigurationsmöglichkeiten.

8.15. Logging, Protokollierung, Tracing

Es gibt zwei Ausprägungen der Protokollierung, das Logging und das Tracing . Bei beiden werden Funktions- oder Methodenaufrufe in das Programm aufgenommen, die zur Laufzeit über den Status des Programms Auskunft geben.

In der Praxis gibt es zwischen Logging und Tracing allerdings sehr wohl Unterschiede:

  • Logging kann fachliche oder technische Protokollierung sein, oder eine beliebige Kombination von beidem.

  • Fachliche Protokolle werden gewöhnlich anwenderspezifisch aufbereitet und übersetzt. Sie dienen Endbenutzern, Administratoren oder Betreibern von Softwaresystemen und liefern Informationen über die vom Programm abgewickelten Geschäftsprozesse.

  • Technische Protokolle sind Informationen für Betreiber oder Entwickler. Sie dienen der Fehlersuche sowie der Systemoptimierung.

  • Tracing soll Debugging -Information für Entwickler oder Supportmitarbeiter liefern. Es dient primär zur Fehlersuche und -analyse.

8.16. Geschäftsregeln

Wie behandeln Sie Geschäftslogik oder Geschäftsregeln? Implementieren die beteiligten Fachklassen ihre Logik selbst, oder liegt die Logik in der Verantwortung einer zentralen Komponente? Setzen Sie eine Regelmaschine (rule-engine) zur Interpretation von Geschäftsregeln ein (Produktionsregelsysteme, forward- oder backward-chaining)?

8.17. Konfigurierbarkeit

Die Flexibilität von IT-Systemen wird unter anderem durch ihre Konfigurierbarkeit beeinflusst, die Möglichkeit, manche Entscheidungen hinsichtlich der Systemnutzung erst spät zu treffen. Konfigurierbarkeit kann zu folgenden Zeitpunkten erfolgen:

  • Während der Programmierung: Dabei werden beispielsweise Server-, Datei- oder Verzeichnisnamen direkt ("hart") in den Programmcode aufgenommen.

  • Während des Deployments oder der Installation: Hier werden Konfigurationsinformationen für eine bestimmte Installation angegeben, etwa der Installationspfad.

  • Beim Systemstart: Hier werden Informationen vor oder beim Programmstart dynamisch gelesen.

  • Während des Programmablaufs: Konfigurationsinformation wird zur Programmlaufzeit erfragt oder gelesen.

8.18. Parallelisierung und Threading

Programme können in parallelen Prozessen oder Threads ablaufen - was die Notwendigkeit von Synchronisationspunkten mit sich bringt. Die Grundlagen dieses Aspekten legt die Parallelverarbeitung. Für die Architektur und Implementierung nebenläufiger Systeme sind viele technische Detailaspekte zu berücksichtigen (Adressräume, Arten von Synchronisationsmechanismen (Guards, Wächter, Semaphore), Prozesse und Threads, Parallelität im Betriebssystem, Parallelität in virtuellen Maschinen und andere).

8.19. Internationalisierung

Unterstützung für den Einsatz von Systemen in unterschiedlichen Ländern, Anpassung der Systeme an länderspezifische Merkmale. Bei der Internationalisierung (aufgrund der 18 Buchstaben zwischen I und n des englischen Internationalisation auch i18n genannt) geht es neben der Übersetzung von Aus- oder Eingabetexten auch um verwendete Zeichensätze, Orientierung von Schriften am Bildschirm und andere (äußerliche) Aspekte.

8.20. Migration

Für die meisten Systeme gibt es existierende Altsysteme, die durch die neuen Systeme abgelöst werden sollen. Denken Sie als Architekt nicht nur an Ihre neue, schöne Architektur, sondern rechtzeitig auch an alle organisatorischen und technischen Aspekte, die zur Einführung oder Migration der Architektur beachtet werden müssen.

  • Konzept, Vorgehensweise oder Werkzeuge zur Datenübernahme und initialen Befüllung mit Daten

  • Konzept zur Systemeinführung oder zeitweiliger Parallelbetrieb von Alt- und Neusystem

Müssen Sie bestehende Daten migrieren? Wie führen Sie die benötigten syntaktischen oder semantischen Transformationen durch?

8.21. Testbarkeit

Tests werden mit Jasmine (Unit/Frontend), Spock (Unit/Backend) und JGiven (Integration/End-To-End) automatisiert.

Unterstützung für einfache (und möglichst automatische) Tests. Diese Eigenschaft bildet die Grundlage für das wichtige Erfolgsmuster "Continous Integration". In Projekten sollte mindestens täglich der gesamte Stand der Entwicklung gebaut und (automatisch) getestet werden - daher spielt Testbarkeit eine wichtige Rolle. Wichtige Stichworte hierzu sind Unit- Tests und Mock-Objekte.

8.22. Skalierung, Clustering

Wie gestalten Sie Ihr System „wachstumsfähig“, so dass auch bei steigender Last oder steigenden Benutzerzahlen die Antwortzeiten und/oder Durchsatz erhalten bleiben?

8.23. Hochverfügbarkeit

Wie erreichen Sie hohe Verfügbarkeit des Systems? Legen Sie Teile redundant aus? Verteilen Sie das System auf unterschiedliche Rechner oder Rechenzentren? Betreiben Sie Standby-Systeme?

8.24. Codegenerierung

Wie und wo verwenden Sie Codegeneratoren, um Teile Ihres Systems aus Modellen oder domänenspezifischen Sprachen (DSL’s) zu generieren?

8.25. Buildmanagement

Das HTML5-Frontend wird als eigenständiges Projekt (Git/Maven) gepflegt und gebaut und als WAR-Overlay über das Backend an den Browser ausgeliefert.

Der Backend-Server wird als Docker-Image erstellt, um ihn * für Entwickler bereitzustellen und * ohne Änderung über die verschiedenen Test-Stages bis in Produktion ausrollen zu können.

Als Build-System kommt Maven zum Einsatz, Jenkins als Build-Server, sowie Nexus als Repository-Server für Artefakte.

Wie wird das gesamte System aus Sourcecode Bausteinen gebaut? Welche Repositories (Versionsverwaltungssysteme) enthalten welchen Sourcecode, wo liegen Konfigurationsdateien, Testdaten und/oder Build-Skripte (make, ant, maven, gradle oder Ähnliche)?

8.26. Stapel-/Batchverarbeitung

Welche Geschäftsprozess-Schritte lassen sich in Stapelverarbeitung erledigen? Wie werden dazu Datenflüsse und Verarbeitungsschritte organisiert? Welche Mechanismen zur Fehlerverarbeitung werden eingesetzt? Sollen fehlgeschlagene Schritte wieder aufgesetzt werden können? Welche Bereinigungsschritte sind dazu notwendig? Welche Ablaufrahmen (Batch-Framework) wird dazu eingesetzt?

8.27. Drucken

Welche spezifischen Anforderungen zum Ausdrucken von Tabellen, Listen, Reports hat das System: z.B. Formate, Layouts, Druckmengen, Lieferzeiten, techn. Integration und Schnittstellen? Welche Eigenschaften haben die Druckgeräte? Können Spool-Verfahren eingesetzt werden?

8.28. Reporting

Welche Anforderungen gibt es zum Erstellen von Berichten / Reports inkl. Kennzahlen? Welche Repoorting-Werkzeuge werden eingesetzt? Welche Berechtigungen sind mit bestimmten Kennzahlen verbunden? Wie schützt man die Echtheit der Reports vor Manipulation? Müssen Reports sicher abgelegt werden können?

8.29. Archivierung

Ist für das System zu erwarten, dass bestimmte Daten aus technischer oder fachlicher Sicht archiviert werden müssen, ggf. periodisch? Welche Konzept existiert dazu? Wie lauten die Rahmenbedingen für die Archivierung (Dauer der Aufbewahrung, Geschwindigkeit der Wiederherstellung, usw.)?

9. Entwurfsentscheidungen

Inhalt

Dokumentieren Sie hier alle wesentlichen Entwurfsentscheidungen und deren Gründe!

Motivation

Es ist wünschenswert, alle wichtigen Entwurfsentscheidungen geschlossen nachlesen zu können. Wägen Sie ab, inwiefern Entwurfsentscheidungen hier zentral dokumentiert werden sollen oder wo eine lokale Beschreibung (z.B. in der Whitebox-Sicht von Bausteinen) sinnvoller ist. Vermeiden Sie aber redundante Texte. Verweisen Sie evtl. auf Kap. 4 zurück, wo schon zentrale Architekturstrategien motiviert wurden.

Form

informelle Liste, möglichst nach Wichtigkeit und Tragweite der Entscheidungen für den Leser aufgebaut.

Alternativ auch ausführlicher in Form von einzelnen Unterkapiteln je Entscheidung. Die folgende Mindmap (Quelle: Kolumne „Architekturen dokumentieren“ von S. Zörner im Java Magazin 3/2009) soll Sie dabei unterstützen, wichtige Entscheidungen zu treffen und festzuhalten. Die Hauptäste stellen dabei die wesentlichen Schritte dar. Sie können auch als Überschriften innerhalb eines Unterkapitels dienen (siehe Beispiel unten).

Entwurfsentscheidungen

Die Fragen sind nicht sklavisch der Reihe nach zu beantworten. Sie sollen Sie lediglich leiten. In der Vorlage löschen Sie diese heraus, und lassen nur die Inhalte/Antworten stehen.

9.1. Entwurfsentscheidung 1

9.1.1. Fragestellung

Was genau ist das Problem?

Warum ist es für die Architektur relevant?

Welche Auswirkung hat die Entscheidung?

9.1.2. Rahmenbedingungen

Welche festen Randbedingungen haben Sie einzuhalten?

Welche Einflussfaktoren sind zu beachten?

9.1.3. Annahmen

Welche Annahmen haben Sie getroffen?

Welche Annahmen können wie vorab überprüft werden?

Mit welchen Risiken müssen Sie rechnen?

9.1.4. Entscheidungskriterien

Nach welchen Kriterien treffen Sie (oder die jeweiligen Entscheider) diese Entscheidung? Denken Sie an technische, organisatorische, juristische oder kommerzielle Kriterien, befragen Sie dazu die relevanten Stakeholder

9.1.5. Betrachtete Alternativen

Welche Lösungsoptionen ziehen Sie in die nähere Auswahl?

Wie bewerten Sie jede einzelne?

Welche Optionen schließen Sie bewusst aus?

9.1.6. Entscheidung

Wer (wenn nicht Sie selbst) hat die Entscheidung getroffen?

Wie ist sie begründet?

Wann wurde entschieden?

…​

10. Qualitätsszenarien

Dieses Kapitel fasst alles zusammen, was Sie zur systematischen Bewertung Ihrer Architektur gegen vorgegebene Qualitätsziele benötigen.

10.1. Qualitätsbaum

Inhalt

Der Qualitätsbaum ( a la ATAM) mit Qualitätsszenarien an den Blättern.

Motivation

Insbesondere wenn Sie die Qualität Ihrer Architektur mit formalen Methoden wie ATAM überprüfen wollen, bedürfen die in Kapitel 1.2 genannten Qualitätsziele einer weiteren Präzisierung bis auf die Ebene von diskutierbaren und nachprüfbaren Szenarien. Dazu dient dieses Kapitel.

Form

Eine mögliche Darstellung ist eine baumartige Verfeinerung des Begriffes „Qualität“

10.2. Bewertungsszenarien

Inhalt

Szenarien beschreiben, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht. Sie charakterisieren damit das Zusammenspiel von Stakeholdern mit dem System. Szenarien operationalisieren Qualitätsmerkmale und machen sie messbar.

Wesentlich für die meisten Software-Architekten sind zwei Arten von Szenarien:

  • Nutzungsszenarien (auch genannt Anwendungs- oder Anwendungsfallszenarien) beschreiben, wie das System zur Laufzeit auf einen bestimmten Auslöser reagieren soll. Hierunter fallen auch Szenarien zur Beschreibung von Effizienz oder Performance. Beispiel: Das System beantwortet eine Benutzeranfrage innerhalb einer Sekunde.

  • Änderungsszenarien beschreiben eine Modifikation des Systems oder seiner unmittelbarer Umgebung. Beispiel: Eine zusätzliche Funktionalität wird implementiert oder die Anforderung an ein Qualitätsmerkmal ändert sich.

Falls Sie sicherheitskritische Systeme entwerfen, ist eine dritte Art von Szenarien für Sie wichtig, die

  • Grenz- oder Stress-Szenarien beschreiben, wie das System auf Extremsituationen reagiert. Beispiele: Wie reagiert das System auf einen vollständigen Stromausfall, einen gravierenden Hardwarefehler oder ähnliches.

Szenarien

Abbildung: Schematische Darstellung von Szenarien (nach [Bass+03])

Szenarien bestehen aus folgenden wesentlichen Teilen (hier zitiert aus [Starke05], die ursprüngliche Gliederung stammt aus [[[Bass+03]]] ):

  • Auslöser (stimulus): beschreibt eine spezifische Zusammenarbeit des (auslösenden) Stakeholders mit dem System. Beispiele: Ein Benutzer ruft eine Funktion auf, ein Entwickler programmiert eine Erweiterung, ein Administrator installiert oder konfiguriert das System.

  • Quelle des Auslösers (source): beschreibt, woher der Auslöser kommt. Beispiele: intern oder extern, Benutzer, Betreiber, Angreifer, Manager.

  • Umgebung (environment): beschreibt den Zustand des Systems zum Zeitpunkt des Auslösers. Befindet sich das System unter Normal- oder Höchstlast? Ist die Datenbank verfügbar oder nicht? Sind Benutzer online oder nicht? Hier sollten Sie alle Bedingungen beschreiben, die für das Verständnis des Szenarios wichtig sind.

  • Systembestandteil (artifact): beschreibt, welcher Bestandteil des Systems vom Auslöser betroffen ist. Beispiele: Gesamtsystem, Datenbank, Webserver.

  • Antwort (response): beschreibt wie das System durch seine Architektur auf den Auslöser reagiert. Wird die vom Benutzer aufgerufene Funktion ausgeführt? Wie lange benötigt der Entwickler zur Programmierung? Welche Systemteile sind von Installation/Konfiguration betroffen?

  • Antwortmetrik (response measure): beschreibt, wie die Antwort gemessen oder bewertet werden kann. Beispiele: Ausfallzeit in Stunden, Korrektheit Ja/Nein, Änderungszeit in Personentagen, Reaktionszeit in Sekunden.

Motivation

Szenarien benötigen Sie zur Prüfung und Bewertung von Architekturen. Sie dienen als "Maßstab" und helfen Ihnen, die "Zielerreichung" der Architektur hinsichtlich der nichtfunktionalen Anforderungen und Qualitätsmerkmale zu messen.

Form

Entweder tabellarisch oder als Freitext. Sie sollten die Bestandteile (Quelle, Umgebung, Systembestandteil, Antwort, Antwortmetrik) explizit kenntlich machen.

Hintergründe

Es gibt inhaltliche Zusammenhänge zwischen Szenarien und Laufzeitsicht. Häufig können Sie die Szenarien der Laufzeitsicht für die Bewertung wieder verwenden oder zugrunde legen. In die Bewertungsszenarien fließen (im Gegensatz zu den Laufzeitszenarien) noch Antwortmetriken ein, die bei der reinen Ablaufbetrachtung der Laufzeitsichten häufig entfallen.

Tabelle 23. Bewertungsszenarien
Szenario Auslöser Metrik

11. Risiken

Inhalt

Eine nach Prioritäten geordnete Liste der erkannten technischen Risiken

Motivation

"Risikomanagement ist Projektmanagement für Erwachsene" (Tim Lister, Atlantic Systems Guild.) Unter diesem Motto sollten Sie technische Risiken in der Architektur gezielt ermitteln, bewerten und dem Projektmanagement als Teil der gesamten Risikoanalyse zur Verfügung stellen.

Form

Risikolisten mit Eintrittswahrscheinlichkeit, Schadenshöhe, Maßnahmen zur Risikovermeidung oder Risikominimierung, …​

Tabelle 24. Risiken
Risiko Priorität

Konsequenz

Erläuterung

12. Glossar

Inhalt

Die wichtigsten Begriffe der Software-Architektur in alphabetischer Reihenfolge

Motivation

Sie sollten relevante Begriffe im Rahmen eines Systems oder eines Teams konsistent verstehen und verwenden.

Form

einfache zweispaltige Tabelle mit <Begriff> und <Definition>

Tabelle 25. Glossar
Begriff Definition

<Begriff-1

Beschreibung-2

<Begriff-2

Beschreibung-2

Anhang A: Literatur und Verweise

Starke-2014

Gernot Starke: Effektive Softwarearchitekturen - Ein praktischer Leitfaden. Carl Hanser Verlag, 6, Auflage 2014.

Starke-Hruschka-2011

Gernot Starke und Peter Hruschka: Softwarearchitektur kompakt. Springer Akademischer Verlag, 2. Auflage 2011.

Zörner-2013

Softwarearchitekturen dokumentieren und kommunizieren, Carl Hanser Verlag, 2012

Anhang B: Beispiele

Anhang C: Danksagung + Mitwirkung

arc42 stammt ursprünglich von Dr. Peter Hruschka und Dr. Gernot Starke.

Quellen

Wir pflegen arc42 zur Zeit im asciidoc Format, gehosted bei GitHub unter der arc42-Organisation.

Issues

Wir pflegen eine Liste offener Punkte und Fehler.

Wir freuen uns, wenn Sie Fehler/Unklarheiten in einem Fork korrigieren und uns einen pull request schicken!

Mitwirkende

Wir danken ausdrücklich allen aktiven und früheren Mitwirkenden sowie den zahlreichen (anonymen) Ratgebern, Fehlerfindern und Anwendern für Ihre Hilfe und Unterstützung.

Zur Zeit aktiv

  • Gernot Starke

  • Stefan Zörner

  • Markus Schärtel

  • Ralf D. Müller

  • Peter Hruschka

  • Jürgen Krey

Frühere Mitwirkende

(in alfabetischer Reihenfolge)

  • Anne Aloysius

  • Matthias Bohlen

  • Karl Eilebrecht

  • Manfred Ferken

  • Phillip Ghadir

  • Carsten Klein

  • Prof. Arne Koschel

  • Axel Scheithauer

Anhang D: Approved Practitioner for arc42

(TODO)