 |
 |
 |
|
 |
|||
| 8.2.8.1 SW-Architektur (SwArc) |
 Inhalt
|
|
|---|
Einleitung
In der SW-Architektur (Grobentwurf) werden Vorschläge für mögliche SW-Architekturen und die ausgewählte Dekomposition der SW-Einheit angegeben: dynamisch in einzelne Prozesse, statisch in SW-Komponenten, SW-Module und Datenbanken. Die Zusammenhänge zwischen Prozessen, SW-Komponenten, SW-Modulen und Datenbanken werden dargestellt. Ferner werden die externen und internen Schnittstellen der SW-Einheit identifiziert und abschließend die Zuordnung zu den Anforderungen hergestellt.
Für jede SW-Einheit existiert ein solches Produkt.
Inhalt des Dokuments
1. Allgemeines2. Lösungsvorschläge
3. Modularisierung/Datenbankentwurf
3.1. Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken
3.2. Einzelbeschreibungen
3.2.m. SW-Komponente/SW-Modul/Prozeß/Datenbank (m)
3.3. Dynamisches Ablaufmodell
3.4. Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken
3.5. Sonstige Entwurfsentscheidungen
4. Schnittstellen
4.1. Externe Schnittstellen der SW-Einheit
4.2. Interne Schnittstellen der SW-Einheit
5. Anforderungszuordnung
Aufbau des Dokuments
1. Allgemeines
Siehe Gliederungspunkt 1. Allgemeines.2. Lösungsvorschläge
Dieses Kapitel nimmt eine Beschreibung und anschließende Bewertung möglicher Architekturen der SW-Einheit auf.Lösungsvorschläge für die Architektur der SW-Einheit werden skizziert. Sie beschreiben auf grobem Niveau die Zerlegung der SW-Einheit in Prozesse sowie in SW-Komponenten, SW-Module und Datenbanken.
Für jeden Lösungsvorschlag werden einzeln die Vor- und Nachteile (z. B. bzgl. Schnittstellenkomplexität, Verwendbarkeit von Fertigprodukten, usw.) und die Realisierbarkeit dargestellt. Die Auswahl eines Lösungsvorschlags wird dokumentiert und begründet.
3. Modularisierung/Datenbankentwurf
Die Modularisierung gibt die statische Zerlegung einer SW-Einheit in SW-Komponenten und SW-Module sowie die realzeitspezifischen Zusammenhänge an. Ferner enthält dieses Kapitel einen Grobentwurf der Datenbanken (falls vorhanden) der SW-Einheit.3. 1. Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken
Alle SW-Module, Prozesse, SW-Komponenten und Datenbanken werden mit ihren Identifikatoren und einer Langbezeichnung aufgelistet. Daneben sollte ergänzend eine grafische Darstellung (Baum) gewählt werden, aus der die "Besteht-aus"-Hierarchie deutlich wird.3. 2. Einzelbeschreibungen
3. 2. m. SW-Komponente/SW-Modul/Prozeß/Datenbank (m)
Die SW-Komponente/das SW-Modul/der Prozeß/die Datenbank wird durch eine Leistungsbeschreibung (Zweck und Funktion) und die in Anspruch genommenen Ressourcen (CPU, Speicher, Peripherie, Prozessoren) definiert.Sofern relevant, erfolgt hier ferner die Zuordnung der SW-Komponente/des SW-Moduls zum realisierenden Prozess.
Hinweis: "m" wird verwendet für eine fortlaufende Numerierung der Einzelbeschreibungen von 3.2.1 bis 3.2.n und als Platzhalter für den Bezeichner der SW-Komponente, des SW-Moduls, des Prozesses oder der Datenbank gemäß den im KM-Plan festgelegten Konventionen zur Identifikation.
3. 3. Dynamisches Ablaufmodell
Dieses Kapitel beschreibt die dynamischen Zusammenhänge von Prozessen. Zur Darstellung eignen sich vorwiegend grafische Methoden.Weiter enthält dieses Kapitel die von der Laufzeitumgebung bereitgestellten und bei der Realisierung der Prozesse angewandten Mechanismen und Konzepte.
3. 4. Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken
In Tabellenform wird jeder SW-Komponente/jedem SW-Modul/jedem Prozeß/jeder Datenbank eine Kritikalitätsstufe zugeordnet. Die Kritikalitätsstufe leitet sich aus der Kritikalität der Funktion ab, die die SW-Komponente/das SW-Modul/der Prozeß/die Datenbank realisiert.3. 5. Sonstige Entwurfsentscheidungen
In diesem Kapitel werden sonstige Entwurfsentscheidungen, soweit sie obenstehend noch nicht genannt wurden, erläutert.4. Schnittstellen
Die aus den Technische Anforderungen und der Systemarchitektur resultierenden externen Schnittstellen der SW-Einheit und die sich aus der Struktur der SW-Einheit ergebenden internen Schnittstellen werden identifiziert und den SW-Komponenten, SW-Modulen und Datenbanken zugeordnet.Dieses Kapitel wird in das Produkt Schnittstellenübersicht übernommen.
4. 1. Externe Schnittstellen der SW-Einheit
Externe Schnittstellen sind Schnittstellen der SW-Einheit zu seiner Umgebung, d. h. zu anderen SW-Einheiten oder HW-Einheiten und zum Nutzer.4. 2. Interne Schnittstellen der SW-Einheit
Interne Schnittstellen der SW-Einheit sind Schnittstellen zwischen SW-Komponenten, SW-Modulen und Datenbanken.5. Anforderungszuordnung
Die Bezüge zu den Technischen Anforderungen werden hergestellt. Es ist zu dokumentieren, ob alle Anforderungen an die betreffende SW-Einheit abgedeckt werden und wie die Anforderungen auf Prozesse/SW-Komponenten/SW-Module/Datenbanken heruntergebrochen wurden.Folgende Punkte sind bei der Anforderungszuordnung zu beachten:
- Jede Anforderung wird auf das in der Detaillierungsschichtung niedrigste Element zugeordnet, das die Erfüllung der Anforderung komplett ermöglicht
- Jede Anforderung muß auf mindestens ein Element, im Idealfall auf genau ein Architekturelement zugeordnet werden.
- Sofern eine Anforderung von element-übergreifender Bedeutung ist, muß im Rahmen der Zuordnung genau abgewägt werden, welche einzelnen Architekturelemente diese Anforderung letztendlich zu erfüllen haben.
- Die Zuordnung muß so erfolgen, daß durch die Prüfung des entsprechenden Elements die Erfüllung der Anforderung nachgewiesen werden kann.
Verknüpfungen mit der V-Modell Mailingliste
Mail 0685 - SW-Architektur (Grobentwurf) (685)Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0251 - Midestanforderungen (251)
|
|
|
This page online • GDPA Online • Last Updated 17.Jul.2003 by C. Freericks |