Arc42 Template 6.0 - Versionsgeschichte

Jochen am 15. Februar 2019 um 07:38 Uhr

2019-02-15T07:38:08Z

← Nächstältere Version		Version vom 15. Februar 2019, 09:38 Uhr
Zeile 1:		Zeile 1:
	~~__TOC__~~		'''<Ihr Name>'''

			arc42 Template Revision: 6.0 DE (Release Candidate), 19. März 2012

	~~= Architekturdokumentation =~~		We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke. For additional contributors see http://www.arc42.de/about/contributors.html

	~~'''<big><Ihr System></big>'''~~

	~~erstellt von~~		__TOC__

	~~'''<Ihr Name>'''~~

	~~arc42 Template Revision: 6.0 DE (Release Candidate)~~
	~~19. März 2012~~

	~~We acknowledge that this document uses material from the arc 42 architecture~~
	~~template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke. For additional contributors see arc42.de/about/contributors.html~~

Jochen: Jochen verschob die Seite Arc42 Template nach Arc42 Template 6.0, ohne dabei eine Weiterleitung anzulegen

2016-10-04T20:36:48Z

Jochen verschob die Seite Arc42 Template nach Arc42 Template 6.0, ohne dabei eine Weiterleitung anzulegen

← Nächstältere Version	Version vom 4. Oktober 2016, 22:36 Uhr
(kein Unterschied)

Jochen am 4. Oktober 2016 um 20:16 Uhr

2016-10-04T20:16:50Z

Änderungen zeigen

Jochen: /* Qualitätsszenarien */

2016-10-04T20:08:43Z

Qualitätsszenarien

← Nächstältere Version		Version vom 4. Oktober 2016, 22:08 Uhr
Zeile 1.405:		Zeile 1.405:
	</i></blockquote>		</i></blockquote>

	~~11.1~~ Qualitätsbaum
	Inhalt		== Qualitätsbaum ==

			<blockquote><i>
			'''Inhalt'''<br/>
	Der Qualitätsbaum ( a la ATAM) mit Qualitätsszenarien an den Blättern.		Der Qualitätsbaum ( a la ATAM) mit Qualitätsszenarien an den Blättern.
	Motivation
			'''Motivation'''<br/>
	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.		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
			'''Form'''<br/>
	Eine mögliche Darstellung ist eine baumartige Verfeinerung des Begriffes „Qualität“		Eine mögliche Darstellung ist eine baumartige Verfeinerung des Begriffes „Qualität“
			</i></blockquote>


			== Bewertungsszenarien ==

	~~11.2 Bewertungsszenarien~~		<blockquote><i>
	Inhalt		'''Inhalt'''<br/>
	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.		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:		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.		* 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.		* Ä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		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.		* 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.


			[[File:Szenarien.png]]<br/>
	Abbildung: Schematische Darstellung von Szenarien (nach [Bass+03])		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]):		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.		* 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.		* 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.		* 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.		* 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?		* 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.		* 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
			'''Motivation'''<br/>
	Szenarien benötigen Sie zur Prüfung und Bewertung von Architekturen. Sie dienen als "Maßstab" und helfen helfen Ihnen, die "Zielerreichung" der Architektur hinsichtlich der nichtfunktionalen Anforderungen und Qualitätsmerkmale zu messen.		Szenarien benötigen Sie zur Prüfung und Bewertung von Architekturen. Sie dienen als "Maßstab" und helfen helfen Ihnen, die "Zielerreichung" der Architektur hinsichtlich der nichtfunktionalen Anforderungen und Qualitätsmerkmale zu messen.
	Form
			'''Form'''<br/>
	Entweder tabellarisch oder als Freitext. Sie sollten die Bestandteile (Quelle, Umgebung, Systembestandteil, Antwort, Antwortmetrik) explizt kenntlich machen.		Entweder tabellarisch oder als Freitext. Sie sollten die Bestandteile (Quelle, Umgebung, Systembestandteil, Antwort, Antwortmetrik) explizt kenntlich machen.
	Hintergründe
			'''Hintergründe'''<br/>
	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.		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.
			</i></blockquote>


	~~12.~~ Risiken		= Risiken =
	Inhalt
			<blockquote><i>
			'''Inhalt'''<br/>
	Eine nach Prioritäten geordnete Liste der erkannten technischen Risiken		Eine nach Prioritäten geordnete Liste der erkannten technischen Risiken
	Motivation
			'''Motivation'''<br/>
	"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.		"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
			'''Form'''<br/>
	Risikolisten mit Eintrittswahrscheinlichkeit, Schadenshöhe, Maßnahmen zur Risikovermeidung oder Risikominimierung, ...		Risikolisten mit Eintrittswahrscheinlichkeit, Schadenshöhe, Maßnahmen zur Risikovermeidung oder Risikominimierung, ...
			</i></blockquote>

	~~13.~~ Glossar
	Inhalt		= Glossar =

			<blockquote><i>
			'''Inhalt'''<br/>
	Die wichtigsten Begriffe der Software-Architektur in alphabetischer Reihenfolge		Die wichtigsten Begriffe der Software-Architektur in alphabetischer Reihenfolge
	Motivation
			'''Motivation'''<br/>
	Die Notwendigkeit für ein Glossar sollte nicht erläutert werden müssen. Oder haben Sie es in Ihren Projekten noch nie vermisst?		Die Notwendigkeit für ein Glossar sollte nicht erläutert werden müssen. Oder haben Sie es in Ihren Projekten noch nie vermisst?
	Form
			'''Form'''<br/>
	einfache zweispaltige Tabelle mit <Begriff> und <Definition>		einfache zweispaltige Tabelle mit <Begriff> und <Definition>
			</i></blockquote>

Jochen: /* Entwurfsentscheidungen */

2016-10-04T20:02:38Z

Entwurfsentscheidungen

← Nächstältere Version		Version vom 4. Oktober 2016, 22:02 Uhr
Zeile 1.321:		Zeile 1.321:

	= Entwurfsentscheidungen =		= Entwurfsentscheidungen =
	Inhalt
			<blockquote><i>
			'''Inhalt'''<br/>
	Dokumentieren Sie hier alle wesentlichen Entwurfsentscheidungen und deren Gründe!		Dokumentieren Sie hier alle wesentlichen Entwurfsentscheidungen und deren Gründe!
	Motivation
			'''Motivation'''<br/>
	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.		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
			'''Form'''<br/>
	informelle Liste, möglichst nach Wichtigkeit und Tragweite der Entscheidungen für den Leser aufgebaut.		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).		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).


			[[File:Entwurfsentscheidungen.png]]


	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.		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.
			</i></blockquote>

	~~10.1~~ Entwurfsentscheidung 1
	~~10.1.1~~ Fragestellung		== Entwurfsentscheidung 1 ==

			=== Fragestellung ===

			<blockquote><i>
	Was genau ist das Problem?		Was genau ist das Problem?

	Warum ist es für die Architektur relevant?		Warum ist es für die Architektur relevant?

	Welche Auswirkung hat die Entscheidung?		Welche Auswirkung hat die Entscheidung?
	~~10.1.2~~ Rahmenbedingungen		</i></blockquote>


			=== Rahmenbedingungen ===

			<blockquote><i>
	Welche festen Randbedingungen haben Sie einzuhalten?		Welche festen Randbedingungen haben Sie einzuhalten?

	Welche EInflussfaktoren sind zu beachten?		Welche EInflussfaktoren sind zu beachten?
	~~10.1.3~~ Annahmen		</i></blockquote>


			=== Annahmen ===

			<blockquote><i>
	Welche Annahmen haben Sie getroffen?		Welche Annahmen haben Sie getroffen?

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

	Mit welchen Risiken müssen Sie rechnen?		Mit welchen Risiken müssen Sie rechnen?
	~~10.1.4~~ Betrachtete Alternativen		</i></blockquote>


			=== Betrachtete Alternativen ===

			<blockquote><i>
	Welche Lösungsoptionen ziehen Sie in die nähere Auswahl?		Welche Lösungsoptionen ziehen Sie in die nähere Auswahl?

	Wie bewerten Sie jede einzelne?		Wie bewerten Sie jede einzelne?

	Welche Optionen schließen Sie bewusst aus?		Welche Optionen schließen Sie bewusst aus?
	~~10.1.5~~ Entscheidung		</i></blockquote>


			=== Entscheidung ===

			<blockquote><i>
	Wer (wenn nicht Sie selbst) hat die Entscheidung getroffen?		Wer (wenn nicht Sie selbst) hat die Entscheidung getroffen?

	Wie ist sie begründet?		Wie ist sie begründet?

	Wann wurde entschieden?		Wann wurde entschieden?
	~~10.2~~ Entwurfsentscheidung n		</i></blockquote>


			== Entwurfsentscheidung n ==


			= Qualitätsszenarien =

	~~11. Qualitätsszenarien~~		<blockquote><i>
	Dieses Kapitel fasst alles zusammen, was Sie zur systematischen Bewertung Ihrer Architektur gegen vorgegebene Qualitätsziele benötigen.		Dieses Kapitel fasst alles zusammen, was Sie zur systematischen Bewertung Ihrer Architektur gegen vorgegebene Qualitätsziele benötigen.
			</i></blockquote>

	11.1 Qualitätsbaum		11.1 Qualitätsbaum

Jochen: /* Konzepte */

2016-10-04T19:56:39Z

Konzepte

Änderungen zeigen

Jochen: /* Laufzeitsicht */

2016-10-04T19:46:25Z

Laufzeitsicht

Änderungen zeigen

Jochen: /* Ebene 1 */

2016-10-04T19:38:06Z

Ebene 1

Änderungen zeigen

Jochen: /* Bausteinsicht */

2016-10-04T19:23:17Z

Bausteinsicht

← Nächstältere Version		Version vom 4. Oktober 2016, 21:23 Uhr
Zeile 644:		Zeile 644:


	~~5.1~~ Ebene 1		== Ebene 1 ==

			<blockquote><i>
	An dieser Stelle beschreiben Sie die White-Box-Sicht der Ebene 1 gemäß dem Whitebox-Template. Die Struktur ist im folgenden bereits vorgegeben.		An dieser Stelle beschreiben Sie die White-Box-Sicht der Ebene 1 gemäß dem Whitebox-Template. Die Struktur ist im folgenden bereits vorgegeben.

	Das Überblicksbild zeigt das Innenleben des Gesamtsystems in Form der Bausteine 1 - n, sowie deren Zusammenhänge und Abhängigkeiten.		Das Überblicksbild zeigt das Innenleben des Gesamtsystems in Form der Bausteine 1 - n, sowie deren Zusammenhänge und Abhängigkeiten.

	Sinnvoll sind hier auch Beschreibungen der wichtige Begründungen, die zu dieser Struktur führen, insbesondere die Beschreibung der Abhängigkeiten (Beziehungen) zwischen den Bausteinen dieser Ebene.		Sinnvoll sind hier auch Beschreibungen der wichtige Begründungen, die zu dieser Struktur führen, insbesondere die Beschreibung der Abhängigkeiten (Beziehungen) zwischen den Bausteinen dieser Ebene.
	Evtl. verweisen Sie auch auf verworfene Alternativen (mit der Begründung, warum es verworfen wurde
			Evtl. verweisen Sie auch auf verworfene Alternativen (mit der Begründung, warum es verworfen wurde.

	Die folgende Abbildung zeigt die Hauptbausteine unseres Systems und deren Abhängigkeiten.		Die folgende Abbildung zeigt die Hauptbausteine unseres Systems und deren Abhängigkeiten.

	<hier Überblicksdiagramm einfügen>		<hier Überblicksdiagramm einfügen>

	Erläuterung zu Struktur und Abhängigkeiten der Ebene 1:		Erläuterung zu Struktur und Abhängigkeiten der Ebene 1:
			</i></blockquote>


	5.1.1 Bausteinname 1 (BlackBox-Beschreibung)		5.1.1 Bausteinname 1 (BlackBox-Beschreibung)

Jochen: /* Externe Schnittstellen */

2016-10-04T19:21:24Z

Externe Schnittstellen

Änderungen zeigen