<Projektname>
Assetarchitekturdokument
[Dieser Abschnitt gibt einen Überblick über das gesamte Assetarchitekturdokument. Die Einführung gibt außerdem Verwendungszweck, Umfang, Definitionen, Akronyme, Abkürzungen und Referenzen des Assetarchitekturdokuments an.]
Dieses Dokument liefert einen umfassenden architekturbezogenen Überblick über das <Asset>. Das Dokument soll die signifikanten architektonischen Entscheidungen, die bezüglich der Zusammenstellung der einzelnen Asset-Artefakte getroffen wurden, erfassen und vermitteln.
[Dieser Abschnitt beschreibt die Assetanforderungen und -zielsetzungen, die signifikante Auswirkungen auf die Architektur haben (wie Benutzerfreundlichkeit, erforderliche Qualifikationsstufe, Verwendung eines gebrauchsfertigen Produkts oder vorhandenen wiederverwendbaren Assets, Verwendung einer speziellen Standarddarstellung für das Asset usw.). Er beschreibt auch die eventuell zu beachtenden speziellen Einschränkungen. Dazu gehören die Design- und Implementierungsstrategie, Entwicklungstools, Teamzusammensetzung, Zeitplan und vorhandene Artefakte.]
[Dieser Abschnitt beschreibt die Umgebungen/Kontexte, in denen das Asset eingesetzt werden soll. Dazu gehören der Entwicklungskontext, der Deployment-Kontext, der Geschäftsbereichskontext usw.
Im Folgenden sind einige Kontexte aufgeführt, für die Werte erfasst werden können:
- Deployment-Kontext: Identifiziert die Server und die Laufzeitumgebung, für die das Asstet vorgesehen ist, z. B. "WebSphere".
Development-Kontext: Identifiziert die Entwicklungsumgebung, in der das Asset entwickelt/erweitert werden soll.
- Geschäftsbereichkontext: Identifiziert den Geschäftsbereich des Assets, z. B. "Versicherung".
- Kontext für den Umfang der Wiederverwendung: Identifiziert die Organisationsbereiche, in denen das Asset wiederverwendet werden soll, z. B. Projektteam, Abteilung oder Unternehmen.
- Testkontext: Identifiziert die Kontexte, in denen das Asset getestet werden soll, z. B. Belastungstest, Leistungstest, Funktionstest.]
[Dieser Abschnitt beschreibt die Beziehungen, die das Asset zu anderen Assets haben kann. Das Asset kann beispielsweise von einem anderen Asset, das einen bestimmten Service bereitstellt, abhängig sein. Es kann aber auch von einem anderen Asset abhängen, das eingesetzt werden muss, bevor es selbst eingesetzt werden kann.]
[Dieser Abschnitt beschreibt, wie der Assetkonsument das Asset verwenden sollte. Er kann als Ausgangsmodell für die Verwendung des Assets betrachtet werden.]
[Dieser Abschnitt enthält das Anwendungsfallmodell für das Asset. Er listet die Akteure des Assets (d. h. die Assetkonsumenten) und die Anwendungsfälle oder Szenarios (Beschreibungen der Verwendung des Assets durch den Akteur) auf. Die Anwendungsfälle sollten den Funktionen in der Assetvision direkt entsprechen.]
[Dieser Abschnitt veranschaulicht die eigentliche Funktionsweise der Assets. Er enthält einige wenige ausgewählte Anwendungsfallrealisierungen (oder Szenarien) und erläutert den Beitrag der verschiedenen Assetartefakte zur Funktionalität dieser Anwendungsfälle.]
Im Kontext eines wiederverwendbaren Assets beschreiben Anwendungsfallrealisierungen, wie Assetartefakte dazu beitragen, die im Anwendungsfall beschriebene Funktionalität bereitzustellen.]
[In diesem Abschnitt ist die relative Priorität der im Abschnitt "Anwendungsmodell" beschriebenen Asset-Features aufgelistet. Diese Informationen werden während der Iterationsplanung für die Entwicklung der Assetartefakte verwendet.]
[Dieser Abschnitt beschreibt die gesamte logische Organisation des Assets und listet die im Asset enthaltenen Artefakte auf. Neben der Pakethierarchie sollte auch die logische Grundlage für die Organisation dokumentiert werden.]
[Dieser Abschnitt beschreibt die gesamte logische Organisation des Assets einschließlich der Pakethierarchie und aller wichtigen Beziehungen zwischen den Paketen.]
[Nehmen Sie für jedes Paket einen Unterabschnitt mit einem Namen, einer Kurzbeschreibung des Pakets sowie einer Liste aller im Paket enthaltenen Assetartefakte (und ggf. Unterpakete) auf.
Geben Sie für jede signifikante Klasse im Paket den Namen, eine Kurzbeschreibung und optional eine Beschreibung der wichtigsten Zuständigkeiten, Operationen und Attribute an.]
[Dieser Abschnitt beschreibt die gesamte physische Organisation des Assets (d. h. der Assetdateien und -verzeichnisse).
Die physische Organisation des Assets unterscheidet sich normalerweise von der logischen Organisation, da die physische Organisation des Assets von dem für das Packen des Assets verwendeten Format (z. B. der Reusable Asset Specification) beeinflusst wird. Daher wird die physische Organisation normalerweise nicht im Voraus, sondern unmittelbar vor bzw. unmittelbar nach dem Packvorgang definiert.]
[Dieser Abschnitt beschreibt die gesamte physische Organisation des Assets. Er listet die physischen Verzeichnisse auf, die die Assetdateien enthalten, sowie alle Regeln, die festlegen, welche Dateien in welches Verzeichnis aufgenommen werden können.
Wenn für das Asset eine Standarddarstellung ausgewählt wurde, sollten die Auswirkungen auf die physische Organisation des Assets hier beschrieben werden.]
[Nehmen Sie für jedes physische Verzeichnis einen Unterabschnitt auf, der den Namen und eine Kurzbeschreibung des Verzeichnisses sowie eine Liste aller Dateien (und eventuell Unterverzeichnisse), die im Verzeichnis enthalten sind, angibt.]
[Wenn das Asset explizite Anpassungsoptionen für spezifische Kontexte bereitstellt (z. B. Instanzierung eines Architekturframework mit einer spezifischen Backend-Datenbank, Instanzierung eines Deployment-Service für ein spezifisches Produkt), sollten diese Anpassungsoptionen in diesem Abschnitt beschrieben werden.
Dieser Abschnitt sollte explizit beschreiben, was angepasst werden kann, und dann Richtlinien für die Umsetzung der Anpassung bereitstellen. Im Falle eines Assets, das eine Schablone oder ein Framework ist, sollte er die formalen Parameter, die im Rahmen der Instanzierung des Assets an tatsächliche Parameter gebunden werden müssen, beschreiben und Vorschläge zu deren Funktion machen. Detaillierte Anweisungen sind, da in der Assetdokumentation enthalten, hier nicht erforderlich. Ziel ist, diejenigen Aspekte des Assets, die angepasst werden sollen, zu identifizieren.]