IsyFact Systementwurf <System>
1. Allgemeine Hinweise zur Dokumentvorlage
|
Dieses Kapitel beschreibt den Zweck der Vorlage zum Systementwurf und gibt allgemeine Hinweise zum Ausfüllen. Es ist vor der Veröffentlichung des Systementwurfs zu entfernen! |
1.1. Zweck
Die Dokumentvorlage enthält die Gliederung für einen V-Modell-konformen Gesamtsystementwurf eines Softwaresystems (Software-Entwicklungsprojekt). Es legt fest, welche Inhalte für einen Systementwurf einer gemäß IsyFact entwickelten Anwendung festgelegt werden sollen.
Der Systementwurf dient dabei mehreren Zwecken:
- Grundlage für die Abstimmung mit dem Auftraggeber
-
Verschiedene Aspekte, wie zum Beispiel die Einbettung in die Anwendungslandschaft, müssen frühzeitig abgestimmt werden.
- Anleitung der Entwicklung, Vorbereitung auf die Implementierung
-
Je nach Vorkenntnissen der SW-Entwickler und der Komplexität den umzusetzenden fachlichen Anforderungen müssen diese Vorgaben angemessen detailliert sein.
1.2. Umfang
In der Regel wird für jede Anwendung jeweils ein eigener Systementwurf angelegt. Für einzelne IT-Systeme der Anwendung kann ein eigener Systementwurf angelegt werden, falls für die IT-Systeme grundsätzlich andere Vorgaben oder Architekturentscheidungen vorliegen, und ein gemeinsamer Systementwurf daher zu unübersichtlich wäre.
1.3. Nutzung
Sukzessive sollen Ausfüllhinweise und Beispiele in den jeweiligen Kapiteln ergänzt werden. Vorgehen, Beispiele und Hinweise sind mit einem Rahmen markiert und später zu entfernen.
1.3.1. Beschreibung der Software-Architektur
Der Systementwurf folgt dem Ansatz "top-down":
-
Zunächst zeigt er, wie sich die Anwendung in die Anwendungslandschaft einfügt.
Kapitel: Einbettung in die Anwendungslandschaft -
Danach stellt er die Zerlegung der Anwendung in IT-Systeme dar und beschreibt, wie die IT-Systeme zusammenarbeiten.
Kapitel: Systemüberblick -
Danach beschreibt er die IT-Systeme. Zunächst werden die Komponenten des IT-Systems (Schichten bzw. Fachkomponenten) und ihr Zusammenspiel erklärt, dann wieder die Fachkomponente selbst. Diese schrittweise Vertiefung setzt sich bis zum benötigten Detaillierungsgrad fort.
Schnittstellen eines Systems werden immer in der Dokumentation und dem Systementwurf des Implementierers beschrieben. Beim Aufruf einer Schnittstelle eines anderen Systems wird lediglich beschrieben, wie die konkrete Nutzung aussieht, also z. B. wie die internen Daten des Systems auf die Daten der Schnittstelle abgebildet werden.
Generell muss in diesem Dokument nichts erklärt und beschrieben werden, was schon an anderer Stelle, insbesondere in der Referenzarchitektur, den Bausteinen und der Methodik der IsyFact, enthalten ist.
2. Einleitung
|
Der Systementwurf enthält alle Informationen, welche für die an der Erstellung der Software beteiligten Parteien (Betrieb, Netzwerk-Administration, Auftraggeber, Entwickler) benötigt werden. Er behandelt eine Vielzahl unterschiedlicher Themenbereiche. Der Detaillierungsgrad, in welchem die Themenbereiche beschrieben werden, ist nicht für alle Systementwürfe gleich: Er hängt von der Art und Komplexität der Problematik und der Erfahrung des Zielpublikums ab. In diesem Dokument werden deshalb beispielsweise keine Vorgaben für den Umfang und die Art der Beschreibung von Anwendungslogik jenseits der Anwendungsfall-Klassen aufgestellt. Systementwürfe sollen grundsätzlich mit der vorliegenden Vorlage und im Einklang zu den beschriebenen Vorgaben und Ausfüllhinweisen erstellt werden. |
2.1. Zusammenfassung
|
Dieser Abschnitt beinhaltet eine knappe Zusammenfassung der Anwendung:
Der Abschnitt kann auf die Zusammenfassung der Systemspezifikation verweisen. |
2.2. Ziel des Dokuments
Der Systementwurf dient folgenden Zwecken:
-
Er ist die Grundlage zur Abstimmung zwischen dem Projektmanagement, der Softwareentwicklung des Auftraggebers/–nehmers und dem Systembetrieb.
-
Er dient als Vorgabe und zur Anleitung für die Entwicklung.
-
Er ist Grundlage für die Erstellung und frühzeitige Abstimmung weiterer Dokumente (zum Beispiel des Sicherheitskonzepts nach IT-Grundschutz).
3. Fachlicher Überblick
3.2. Einbettung in die Anwendungslandschaft
|
Dieser Abschnitt beschreibt, wie sich die zu entwickelnde Anwendung (im Beispiel: BSP-GA) in die Anwendungslandschaft einfügt. Dies wird in der Regel durch ein UML-Diagramm der Anwendungslandschaft dargestellt, in der die Anwendung hervorgehoben ist. |
| Das UML-Diagramm der Anwendungslandschaft sollte so abstrahiert sein, dass es nicht oft Änderungen von außen unterworfen ist. Ein solches Diagramm veraltet sehr schnell und macht häufige Änderungen am Entwurf nötig, ohne dass die Anwendung selbst sich ändert. |
| Anwendungen, mit denen die zu entwickelnde Anwendung (im Beispiel: BSP-GA) nicht kommuniziert, sollten nicht dargestellt werden. Die Domänen, die sich selten ändern, können hingegen umrissen werden. |
3.3. Fachliche Randbedingungen und Annahmen
|
Dieser Abschnitt verweist auf die Randbedingungen und Annahmen in der Systemspezifikation. |
Fachliche Randbedingungen und Annahmen sind in der Systemspezifikation erreichbar unter (Verweis/URL) beschrieben.
4. SW-Architektur BSP-GA
|
Dieses Kapitel stellt den Überblick über die technische Umsetzung der Geschäftsanwendung dar. Es beschreibt außerdem die Aspekte, die für mehrere der IT-Systeme gelten, in welche die Geschäftsanwendung zerlegt wird. Das können Verfahren, Festlegungen oder die Beschreibung gemeinsam genutzter Komponenten sein. In der Regel zerlegt sich eine Geschäftsanwendung in:
Festlegungen, die bereits in übergeordneten Dokumenten der IsyFact oder der Organisation (z.B. IsyFact-Referenzarchitektur, Sicherheitsrichtlinie der Organisation, …) enthalten sind, werden referenziert. Abweichungen hiervon sind zu begründen! |
4.1. Systemüberblick
|
Der Systemüberblick beschreibt, in welche IT-Systeme die Geschäftsanwendung zerlegt wird, und von welchem IT-Systemtyp diese sind. Die Referenzarchitektur der IsyFact definiert die IT-Systemtypen Backend, Frontend, Batch und Gateway. Dieses Kapitel ist die nächste Stufe der Konkretisierung nach der Einbettung in die Anwendungslandschaft. Das Kapitel besteht aus einem UML-Diagramm, das darstellt, aus welchen IT-Systemen die Geschäftsanwendung besteht, wie diese sich gegenseitig aufrufen und welche Nachbarsysteme aufgerufen werden. Zur besseren Orientierung sind der Farbcode und das Layout der Referenzarchitektur zu beachten. Für die Schnittstellen und Services soll ein geeigneter Abstraktionsgrad gewählt werden. Übersichtlichkeit steht klar über der Beschreibung von Details! Das UML-Diagramm beschreibt ein begleitender Text, der sich folgender Fragen annimmt:
Die folgende Abbildung 2 basiert auf der Beispielzerlegung der Referenzarchitektur. Es zeigt nicht nur die Zerlegung, sondern schafft auch den Rückbezug auf die Systemspezifikation. Wenn dies der Übersicht nicht dienlich ist, kann der Rückbezug auch textuell oder tabellarisch hergestellt werden. 
Abbildung 2. Zerlegung der BSP-GA in IT-Systeme
Im begleitenden Text wären die Aufrufbeziehungen der IT-Systeme untereinander knapp zu erläutern. Ebenso wäre zu beschreiben, wieso die Verbindung zum IAM-Service von der fachlichen Klammer der Anwendung ausgeht. In diesem Beispiel soll dies verdeutlichen, dass alle enthaltenen IT-Systeme den IAM-Service aufrufen. |
4.2. Technische Randbedingungen und Annahmen
|
Dieser Abschnitt beschreibt technische Randbedingungen und Annahmen, die für den Systementwurf relevant sind, ausführlich. Annahmen sind Aussagen, deren Gültigkeit für möglich gehalten wird, die aber nicht bewiesen oder verifiziert sind. Annahmen benötigen immer eine Begründung (das heißt: "Warum nehmen wir das an?") und sollten während des Vorhabens periodisch überprüft werden. Randbedingungen (auch als Rahmenbedingungen bezeichnet) sind Umstände, die nur mit großem Aufwand oder gar nicht beeinflussbar sind oder sich aus der Problemstellung zwingend ergeben, und daher als gegeben betrachtet werden. |
4.3. Nichtfunktionale Anforderungen
|
Architekturrelevante nichtfunktionale Anforderungen konkretisieren in der Regel die Qualitätsziele der Anwendung. Sie machen diese Qualitätsziele messbar und durch Tests überprüfbar. Die Strukturierung dieses Kapitels sollte sich an den Qualitätskriterien der ISO 25010 orientieren:
|
4.4. Konformität zur Referenzarchitektur
|
In diesem Kapitel wird die Konformität des Systems zur Referenzarchitektur bestätigt und auf eventuell vorhandene Erweiterungen, Abweichungen und abweichende Versionen verwiesen. Eine Übersicht über die Software-Artefakte der IsyFact findet sich in Tabelle 1. Die Spalte "Status" nimmt die folgenden Werte an:
In den letzten drei Fällen (Erweiterung, Abweichung sowie abweichende Versionen) sind im folgenden Kapitel, Abweichungen und Erweiterungen zur Referenzarchitektur, Architekturentscheidungen in Form von ADRs zu dokumentieren und in Form von Verweisen auf die ADRs in der Spalte "Referenzen" der jeweiligen Elemente aufzuführen. |
Das Anwendung BSP-GA wird konform zur Referenzarchitektur der IsyFact umgesetzt. Die folgende Tabelle führt die verwendeten Elemente der IsyFact auf.
| Thema | Status | Version | Referenzen |
|---|---|---|---|
Allgemein |
|||
IsyFact |
berücksichtigt |
5.x |
|
Referenzarchitektur |
|||
Backend |
berücksichtigt |
Standard |
|
Batch |
berücksichtigt |
Standard |
|
Frontend |
berücksichtigt |
Standard |
|
Gateway |
berücksichtigt |
Standard |
|
Kommunikation |
berücksichtigt |
Standard |
|
Bausteine (IsyFact-Standards) |
|||
Datum & Zeit |
berücksichtigt |
… |
|
Fehlerbehandlung |
berücksichtigt |
Standard |
|
Logging |
berücksichtigt |
Standard |
|
Polling |
berücksichtigt |
… |
|
Security |
berücksichtigt |
… |
|
Sonderzeichen |
berücksichtigt |
… |
|
Task Scheduling |
Abweichungen |
… |
|
Überwachung |
berücksichtigt |
Standard |
|
Util |
berücksichtigt |
… |
|
Bausteine (IsyFact-Erweiterungen) |
|||
Angular |
berücksichtigt |
… |
|
Bedienkonzept |
berücksichtigt |
… |
|
… |
… |
… |
|
Plattform |
|||
Deployment-Konzept |
berücksichtigt |
Standard |
|
Methodik |
|||
Namenskonventionen |
berücksichtigt |
Standard |
|
Versionierung |
berücksichtigt |
Standard |
|
Java-Programmierkonventionen |
berücksichtigt |
Standard |
|
TypeScript-Programmierkonventionen |
berücksichtigt |
Standard |
|
Vorlagen |
berücksichtigt |
Standard |
|
Diagrammerstellung |
berücksichtigt |
Standard |
|
Werkzeuge |
|||
OpenAPI Editor |
berücksichtigt |
Standard |
|
OpenAPI Generator |
berücksichtigt |
Standard |
|
4.5. Abweichungen und Erweiterungen zur Referenzarchitektur
|
In diesem Kapitel werden Abweichungen und Erweiterungen zur Referenzarchitektur in Form von Architecture Decision Records (ADRs) dokumentiert. Falls mehr als die von der Vorlage vorgesehenen Informationen erfasst werden müssen, kann die ADR-Vorlage um weitere Zeilen ergänzt werden. Es sollten auch abgelehnte und abgelöste ADRs im Systementwurf enthalten sein, um das in ihnen enthaltene Wissen festzuhalten. |
Die folgenden Architekturentscheidungen begründen Abweichungen und Erweiterungen zur Referenzarchitektur. Sie gelten für das im Dokument beschriebene Gesamtsystem. Darüber hinaus sind folgende, übergreifende Architekturentscheidungen zu beachten: übergreifende Architekturentscheidungen.
4.5.1. ADR-BSP-GA-1: Titel
Entscheidung |
Architekturentscheidung im Wortlaut. |
|---|---|
Begründung |
Begründung der Architekturentscheidung. |
Entscheidende |
Aufzählung der Personen, welche die Entscheidung getroffen haben. Im Fall einer Abstimmung auch Enthaltungen und Gegenstimmen dokumentieren, ggf. mit kurzem Bezug auf wesentliche Gegenargumente. |
Datum |
Datum der Entscheidung. |
Alternativen |
Optional: Beschreibung der Alternativen mit den wesentlichen Beweggründen ihrer Betrachtung, in jeweils wenigen Sätzen. |
Auswirkungen |
Optional: Beschreibung von Auswirkungen, vor allem falls nicht direkt ersichtlich oder durch Zusammenspiel mit anderen (übergreifenden) ADRs, in jeweils wenigen Sätzen. |
4.6. TI-Architektur
|
Das Kapitel enthält eine kurze Beschreibung der wichtigsten Eckpunkte der TI-Architektur. Die Beschreibung besteht aus Deployment-Diagrammen mit begleitendem Text. Die Diagramme beschreiben die Zuordnung der Server bzw. Laufzeitumgebungen zu den Zonen sowie die Zuordnung der Deployment-Einheiten auf die Server/Laufzeitumgebungen. Es enthält keine konkreten Adressen, Portnummern und Dimensionierungen, sondern eine logische Sicht. Die Kommunikationsbeziehungen werden zum Load Balancer bzw. zur Firewall dargestellt. Es soll klar werden, über welche Zonengrenzen hinweg mit welchen Protokollen kommuniziert wird. Existierende Nachbarsysteme werden in der Regel nicht dargestellt. 
Abbildung 3. TI-Architektur BSP-GA (teilweise)
Das Beispiel-Diagramm in Abbildung 3 zeigt mit einem Backend und einem Batch einen Teil der BSP-GA. |
4.6.1. Laufzeitumgebung
|
Der Abschnitt erläutert die eingesetzten Produkte für die Laufzeitumgebung. Diese Umgebung ist durch den Produktkatalog der IsyFact zum größten Teil vorgegeben. |
Die Laufzeitumgebung für die IT-Systeme der Geschäftsanwendung BSP-GA besteht gemäß aus den folgenden Produkten:
| Kategorie | Name | Version | Bemerkung |
|---|---|---|---|
Betriebssystem |
Linux 64 bit |
Kernel >= 4.12 |
|
Java-Laufzeitumgebung |
25.x |
||
Servlet-Container |
Apache Tomcat |
Z.B. 8.5.x |
4.6.2. Ressourcen
|
Der Abschnitt enthält eine Abschätzung der Ressourcen in der Produktionsumgebung:
Die Abschätzung geschieht in tabellarischer Darstellung und mithilfe erläuterndem Text. |
4.6.2.1. Mengengerüst für die Datenbank
In Tabelle 3 ist eine Abschätzung für die Datenbankgröße enthalten. Hier ist allerdings nur die Größe der Rohdaten angegeben. Für eine Berechnung der Größe der Table-Spaces müssen noch Spezifika der konkret verwendeten Datenbank berücksichtigt werden. Die Berechnung der Größe der Table-Spaces erfolgt durch die Datenbank-Administration auf der Basis der hier genannten Zeilenanzahl je Tabelle.
| Tabelle/Index | Typ | Anzahl/Zeilen | Größe Rohdaten | Bemerkung | |
|---|---|---|---|---|---|
Zeile |
Tabelle |
||||
… |
|||||
… |
|||||
… |
|||||
4.6.2.2. Platzbedarf für Dateien
|
Der Abschnitt enthält eine Abschätzung der Ressourcen in der Produktionsumgebung:
Die Abschätzung geschieht in tabellarischer Darstellung und mithilfe erläuterndem Text. |
In Tabelle 4 ist eine Abschätzung für die auf dem lokalen Laufwerk gespeicherten Dateien enthalten.
| Datei | Größe | Bemerkung |
|---|---|---|
… |
||
… |
5. SW-Architektur Backend BSP_1+2-GK
|
Im Kapitel SW-Architektur BSP-GA wurde die in der Systemspezifikation beschriebene Anwendung in IT-Systeme zerlegt. Diese werden ab hier in eigenen Unterkapiteln der Reihe nach beschrieben. Dieses Kapitel enthält vornehmlich eine Top-Down-Beschreibung des IT-Systems anhand seines IT-Systemtyps. Die Beschreibung umfasst die Aufteilung des IT-Systems in Komponenten und deren Bezug zur Systemspezifikation. Der Detailgrad der Beschreibung der Komponenten hängt u.a. vom Maß an nötigen Abweichungen und Erweiterungen zur Referenzarchitektur sowie von der vorhandenen Erfahrung in den Architektur- und Entwicklungsteams mit der IsyFact und den verwendeten Produkten ab. Weiterhin referenziert das Kapitel übergeordnete Designprinzipien und Patterns, die beim Entwurf des IT-Systems eine Rolle spielen. Schließlich enthält es weitergehende Details, Hinweise und Besonderheiten, deren Kenntnis für die Entwicklung und Wartung des IT-Systems hilfreich sind. |
| Wenn sich Beschreibungen in den folgenden Kapiteln doppeln, ist es sinnvoll, ein Kapitel voranzustellen, das Gemeinsamkeiten aller IT-Systeme bzw. einzelner IT-Systemtypen (zum Beispiel aller Backends) erläutert. Wenn diese Gemeinsamkeiten die Referenzarchitektur oder bestehende Bausteine der IsyFact betreffen, können sie auch Einzug in die Querschnittskonzepte halten. |
Dieses Kapitel beschreibt die Systemarchitektur des Backends BSP_1+2-GK.
5.1. Überblick
|
Dieser Abschnitt zeigt einen Überblick über das IT-System. Dies erfolgt in der Regel mit einem UML-Komponentendiagramm und einem knappen begleitenden Text, der die einzelnen Komponenten und ihr Zusammenspiel erklärt. Als Leitfaden für das Diagramm kann die Beschreibung des technischen Kontextes von arc42 dienen. Im Unterschied dazu ist hier vorgesehen, auch die Innensicht des betrachteten IT-Systems zu zeigen. Ein Diagramm, das den technischen Kontext des Gesamtsystems zeigt, befindet sich in der SW-Architektur BSP-GA. Das Komponentendiagramm zeigt eine Übersicht der fachlichen Schnittstellen und sowohl fachlichen als auch technischen Komponenten des IT-Systems. Es stellt die Zusammenhänge und Beziehungen zwischen den Bestandteilen des IT-Systems dar. Es beschreibt nicht die Logik der Verarbeitung. Die folgende Abbildung 4 zeigt eines der Backends aus der Beispielzerlegung der Referenzarchitektur. 
Abbildung 4. Backend der Beispielzerlegung
Hinweise zur Darstellung:
|
5.2. Bibliotheken & Produkte
|
Auflistung der benötigten Bibliotheken für die Entwicklung des IT-Systems in tabellarischer Darstellung. Wenn keine Version eingetragen wird, richtet sich die Version nach dem Produktkatalog der IsyFact-Version, die in Konformität zur Referenzarchitektur benannt ist. Abweichungen von der Referenzarchitektur sind in der Spalte "Bemerkung" zu hinterlegen. Zusätzliche, nicht von der IsyFact vorgeschriebene und empfohlene Produkte sind ebenfalls zu kennzeichnen. Transitive Abhängigkeiten sind nicht einzutragen. |
Das IT-System BSP_1+2-GK benötigt gemäß Produktkatalog der IsyFact die folgenden Bibliotheken bzw. Produkte:
| Kategorie | Name | Version | Bemerkung |
|---|---|---|---|
Programmiersprache |
Java |
||
Application Framework |
Spring Boot |
||
… |
… |
5.3. Anwendungskern
|
Dieser Abschnitt beschreibt die technische Umsetzung der Anwendungskomponenten (ANK) in Fachkomponenten. Die Tiefe der Darstellung richtet sich nach der fachlichen Komplexität der umzusetzenden Funktionalität, das heißt Anwendungsfälle (AWF) und Modellkomponenten (MKO), aus der Systemspezifikation. |
Die folgenden Abschnitte beschreiben die technische Umsetzung der Anwendungskomponenten.
5.3.1. ANK_BSP_1
|
Die Beschreibung einer Anwendungskomponente enthält in der Regel ein UML-Komponentendiagramm und erklärenden Text. Das Diagramm beschreibt den Aufbau der Anwendungskomponente und gibt einen Überblick über ihre wichtigsten Klassen. Ein Beispiel für eine generische Fachkomponente mit Klassen für Anwendungsfälle und Anwendungsfunktionen ist in der Beschreibung des Anwendungskerns der Referenzarchitektur enthalten. |
|
Rückbezug auf die Systemspezifikation
Die Komponente stellt in ihrer Beschreibung den Bezug zur Spezifikation dar:
|
5.4. Persistenzschicht
|
Die Vorgaben zur Persistenzschicht sind in der Referenzarchitektur Backend beschrieben. Dieser Abschnitt kann Besonderheiten der Persistenzschicht erläutern, die über die Vorgaben der Referenzarchitektur hinausgehen. Ebenfalls sinnvoll ist der Verweis auf zusätzliche, fachliche Konzepte, die Auswirkungen auf die Persistenzschicht haben. Beispiele hierfür sind der Umgang mit Sperren oder Löschfristen. |
5.5. Serviceschicht
|
Die Vorgaben zur Serviceschicht sind in der Referenzarchitektur Backend beschrieben. Dieser Abschnitt kann Besonderheiten der Serviceschicht erläutern, die über die Vorgaben der Referenzarchitektur hinausgehen. Ebenfalls sinnvoll ist der Verweis auf zusätzliche, fachliche Konzepte, die Auswirkungen auf die Serviceschicht haben. Die konkrete Konstruktion der einzelnen Services sind in einem eigenen Unterabschnitt pro Service beschrieben. |
|
Rückbezug auf die Systemspezifikation
Die Komponente stellt in ihrer Beschreibung den Bezug zur Spezifikation dar:
|
5.6. Querschnitt
|
Dieser optionale Abschnitt enthält Konzepte des Querschnitts, welche nur für das vorliegende Teilsystem gelten. |
5.7. Datenmodell
|
Beschreibung des logischen und physischen Datenmodells des Backends als UML-Klassendiagramm. Die Entitäten des Datenmodells werden den Fachkomponenten des Anwendungskerns zugeordnet. Die Fachkomponenten werden in den Diagrammen durch Boundaries repräsentiert. Das übliche Vorgehen besteht aus den folgenden Schritten:
|
5.7.1. Logisches Datenmodell
|
Das logische Datenmodell entsteht aus dem fachlichen Datenmodell der Systemspezifikation. Es ist weitgehend identisch, passt jedoch z. B. die Namensgebung der Entitäten den Coding-Richtlinien an und legt fest, in welcher Richtung Relationen navigierbar sind. Das Diagramm ist eine Übersicht über das logische Datenmodell des IT-Systems. Es enthält alle persistenten Entitäten des Systems. Darstellung
Innerhalb einer Komponente sollen die folgenden Regeln für die Anordnung von Tabellen eingehalten werden:
Die Wichtigkeit von Entitäten soll über ihre Position und Größe dargestellt werden. Das Ziel ist ein intuitiv möglichst gut verständliches Diagramm zu erstellen, in dem z.B. die Hauptentität groß in der Mitte dargestellt wird. Durch die Gruppierung nach Komponenten und die Verwendung des Standard-Layouts wird das Diagramm äußerst groß (Tapete). Dies wird in Kauf genommen: Das Layout ist mit die wichtigste Information. Die Optimierung des Diagramms in Hinblick auf den benötigten Platz ist nicht gewünscht. Beispiel für ein logisches Datenmodell 
Abbildung 5. Logisches Datenmodell
|
5.7.2. Physisches Datenmodell
|
Das physische Datenmodell ist die Umsetzung des logischen Datenmodells in der DB. Dort wird z. B. festgelegt, an welchen Stellen Denormalisierungen und Redundanzen aufgenommen werden oder wie Vererbungsbeziehungen abgebildet werden. Zum physischen Datenmodell werden ebenfalls ein oder mehrere UML-Diagramme analog zum logischen Datenmodell erzeugt. Darstellung
Layout Die Tabellen sollen nach Komponenten gruppiert werden. Jede Komponente soll als Boundary um die Tabellen der Komponente dargestellt werden. Innerhalb einer Komponente sollen die folgenden Regeln für die Anordnung von Tabellen eingehalten werden:
Die Wichtigkeit von Tabellen soll über ihre Position und Größe dargestellt werden. Das Ziel ist ein intuitiv möglichst gut verständliches Diagramm zu erstellen, in dem z.B. die Hauptentität groß in der Mitte dargestellt wird. Durch die Gruppierung nach Komponenten und die Verwendung des Standard-Layouts wird das Diagramm äußerst groß (Tapete). Dies wird in Kauf genommen: Das Layout ist mit die wichtigste Information. Die Optimierung des Diagramms in Hinblick auf den benötigten Platz ist nicht gewünscht. |
6. SW-Architektur Batch BSP_1+2-GKBATCH
|
Die allgemeinen Vorgaben zu Batches sind in der Referenzarchitektur Batch der IsyFact beschrieben. Sie können bei Bedarf referenziert werden. Da sich Batches laut Referenzarchitektur oft den Anwendungskern und die Persistenzschicht mit einem Backend teilen, kann auf die entsprechenden Kapitel referenziert werden. Falls dies nicht der Fall ist, ist das Backend wie ein Nachbarsystem zu behandeln und die Batches erhalten einen Anwendungskern mit einem Service Consumer pro benötigtem Service. Weiterhin wird hier der Rückbezug zur Systemspezifikation hergestellt, indem die Batches der Spezifikation den Batches der Software zugeordnet werden. Dies kann textuell oder durch eine UML-Grafik geschehen. |
6.1. Überblick
| Der Überblick richtet sich nach dem in Überblick beschriebenen Vorgehen. |
6.2. Bibliotheken & Produkte
|
Auflistung der benötigten Bibliotheken für die Entwicklung des IT-Systems in tabellarischer Darstellung. Wenn keine Version eingetragen wird, richtet sich die Version nach dem Produktkatalog der IsyFact-Version, die in Konformität zur Referenzarchitektur benannt ist. Abweichungen von der Referenzarchitektur sind in der Spalte "Bemerkung" zu hinterlegen. Zusätzliche, nicht von der IsyFact vorgeschriebene und empfohlene Produkte sind ebenfalls zu kennzeichnen. Transitive Abhängigkeiten sind nicht einzutragen. |
Das IT-System BSP_1+2-GKBATCH benötigt gemäß Produktkatalog der IsyFact die folgenden Bibliotheken bzw. Produkte:
| Kategorie | Name | Version | Bemerkung |
|---|---|---|---|
Programmiersprache |
Java |
||
Application Framework |
Spring Boot |
||
Batch-Framework |
Spring Batch |
s. Spring Boot Dependency Management |
nur für BSP_1+2-GKBATCH, Entscheidung für Alternativprodukt gemäß ADR-BSP-GA-1 |
… |
… |
7. SW-Architektur <IT-Systemtyp> <IT-System-Bezeichner>
|
Analog zu SW-Architektur Backend BSP_1+2-GK und SW-Architektur Batch BSP_1+2-GKBATCH: für jedes IT-System entsteht ein eigenes Unterkapitel gemäß seines IT-Systemtyps. |
8. Systementwicklung
|
Dieses Kapitel verweist, wo möglich, auf übergreifende Regelungen (Entwicklungshandbuch, Coding Guidelines, …). Die Tiefe dieses Kapitel passt sich den Vorkenntnissen des Entwicklungsteams an. Es ist kein Selbstzweck und kann sich auf wenige Punkte beschränken oder ggf. sogar ganz entfallen. Wenn es keine übergreifenden Regelungen gibt, adressiert das Kapitel unter anderem folgende Themen:
|
9. Betrieb
|
Dieses Kapitel verweist, wo möglich, auf ein Betriebshandbuch (oder dazu ähnliche Dokumente). Es verweist in der Regel auf folgende Themen:
|