SE 5.1-SW: SW-Komponente/-Modul/Datenbank beschreiben



		SE 5.1-SW: SW-Komponente/-Modul/Datenbank beschreiben

SD5.1-SW - Description of SW Component/Module/Database

Inhalt
Produktfluß
Abwicklung
Rollen
Methoden

Werkzeuganforderungen
Externe Normen
Verknüpfungen mit der V-Modell Mailingliste

Inhalt		Produktfluß Abwicklung Rollen Methoden		Werkzeuganforderungen Externe Normen Verknüpfungen mit der V-Modell Mailingliste

Produktfluß

von		Produkt		nach		Methoden	Werkzeug Anf.	Ext. Normen
Aktivität	Zustand	Kapitel	Titel	Aktivität	Zustand	Methoden	Werkzeug Anf.	Ext. Normen
SE1	akzeptiert	Alle	Anwenderforderungen	-	-			/ISO IEC 12207/ Devlp. Proc.: SW Detail. Design
SE3	akzeptiert	Alle	Technische Anforderungen	-	-
SE4-SW	akzeptiert	Alle	SW-Architektur	-	-
SE4-SW	akzeptiert	Alle	Schnittstellenübersicht	-	-
SE4-SW	akzeptiert	Alle	Schnittstellenbeschreibung	-	-
KM4.1	in Bearb.	Existierend	Datenkatalog	KM4.1 SE5.2-SW SE6-SW	in Bearb., vorgelegt	AVK ⁽¹⁾ DVER ⁽⁴⁾ FS ⁽⁵⁾	LSE09 LSE11 LSE21
-	-	2	SW-Entwurf (Modul). Beschreibung	SE5.2-SW	in Bearb.	AVK ⁽¹⁾ KOM ⁽²⁾ CRC ⁽²⁾ DVER ⁽⁴⁾ FS ⁽⁵⁾ IAM ⁽²⁾ MODIAG ⁽²⁾ PCODE ZUSTO ⁽³⁾	LSE10 LSE20 SS211 LSE22 LSE24 LSE27 LSE28 LSE29 LSE30 LSE31
-	-	2	SW-Entwurf (Datenbank). Beschreibung	SE5.2-SW	in Bearb.	DNAV ⁽⁶⁾ LOGM NORM	LSE09 LSE11 SS211 LSE22 LSE29 LSE30 LSE31
SE4-SW	in Bearb.	Existierend	Betriebsinformationen: Anwendungshandbuch Diagnosehandbuch Betriebshandbuch Sonstige Einsatzinformationen	SE8	in Bearb.

+ "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250

Gegenstand dieser Aktivität ist die softwaretechnische Realisierung der SW-Komponenten, SW-Module und Datenbanken. Die Konstruktion jedes SW-Modul und jeder SW-Komponente bis auf die Ebene einer Programmiervorgabe muß beschrieben werden. Jede Datenbank ist bis auf ihre elementaren Bestandteile (Daten und Attribute) festzulegen.

Die Betriebsinformationen sind hier um entwurfsbezogene Details zu ergänzen. Die SW-Architektur und der SW-Entwurf (Modul,Datenbank) bieten Anhaltspunkte für die weitere Bearbeitung der Betriebsinformationen (Anwendungshandbuch, Diagnosehandbuch, Betriebshandbuch, Sonstige Einsatzinformationen).

* a) SW-Komponente/SW-Modul beschreiben:

Die SW-Komponenten und SW-Module müssen hinsichtlich ihrer Umgebung, der Realisierung ihrer Funktionalität, der Datenhaltung, Ausnahme- und Fehlerbehandlung, usw. spezifiziert und bis hin zu einer Programmiervorgabe formuliert werden.

* b) Datenbank beschreiben:

Vor dem Hintergrund des DB-Entwurfs in der SW-Architektur und abhängig von Zugriffshäufigkeiten müssen die Datenbanken hinsichtlich ihres Schemas bis hinunter auf Datenelementebene spezifiziert werden. Dabei ist jede Datenhaltung entsprechend ihrer typspezifischen Ausprägung detailliert zu beschreiben. Für Filesysteme werden dementsprechend die Satzaufbauten und die darin enthaltenen Datenelemente festgelegt. Bei hierarchischen Datenbanken werden die DB-Segmente, die darin enthaltenen Datenelemente und die DB-Segmenthierarchien definiert. Bei relationalen Datenbanken werden Tabellen, gegebenenfalls Views und die darin enthaltenen Datenelemente (u. a. auch die Fremdschlüssel) definiert. Ferner sind die Integritätsbedingungen festzulegen.

* Datenkatalog erstellen:

Die in der SW-Einheit benutzten Daten sind im Datenkatalog aufzunehmen. Die Eingangsinformationen für den Datenkatalog liefern die DB-bezogenen Informationen in der SW-Architektur und im SW-Entwurf(Modul/Datenbank). Im Datenkatalog sind implementierungsabhängige Informationen, wie Bezeichner, Datentyp, Datenformat, Lebensdauer, Zugriffsart, Zugriffs- und Entstehungszeiten und -frequenzen, Zuordnung zu Datenbanken, Speicherart, Speicherplatzbedarf usw. festzuhalten.

Da der Datenkatalog ein projektumfassendes Produkt ist, wird durch QS lediglich die Qualität der neu hinzugefügten Inhalte geprüft. Der Datenkatalog darf den Zustand "akzeptiert" nur erreichen, wenn die zentrale Datenadministration zustimmt (Aktivität KM4.1 - Daten administrieren).

* Betriebsinformationen ergänzen:

Die Beschreibungen der SW-Module, SW-Komponenten und Datenbanken liefern die entwurfsbezogenen Angaben zur weiteren Vervollständigung der Betriebsinformationen. Auf dieser Basis sind die genauen Angaben zu Anwendung und Betrieb und zu Fehlerfällen bei Nutzung der Anwenderfunktionen (Informationen zum Anwendungshandbuch), zu den Diagnosemöglichkeiten und -maßnahmen (Informationen zum Diagnosehandbuch), zu Initialisierung, Beendigung und Überwachung des Betriebs (Informationen zum Betriebshandbuch) und zu Installation und Datenübernahme (Sonstige Einsatzinformationen) zu erstellen.

Rollen

Rolle	Beteilungsarten
SW-Entwickler	verantwortlich
Technischer Autor	mitwirkend

Methoden

Produkt	Methodenzuordnung	Benutzung
Kapitel 2 SW-Entwurf (Modul). Beschreibung	AVK - Analyse verdeckter Kanäle ⁽¹⁾	Erstellen
	KOM - Klassen-/Objektmodellierung ⁽²⁾	Erstellen
	CRC - Class Responsibility Collaboration ⁽²⁾	Erstellen
	DVER - Designverifikation ⁽⁴⁾	Erstellen
	FS - Formale Spezifikation ⁽⁵⁾	Erstellen
	IAM - Interaktionsmodellierung ⁽²⁾	Erstellen
	MODIAG - Moduldiagramme ⁽²⁾	Erstellen
Kapitel 2.4 SW-Entwurf (Modul). Realization of the SW Komponent/ SW Module	PCODE - Pseudocode	Erstellen
	ZUSTO - Zustand Modeling in the OO Field ⁽³⁾	Erstellen
Kapitel 2.6 SW-Entwurf (Modul). Exceptional Behavior	PCODE - Pseudocode	Erstellen
Kapitel 2 SW-Entwurf (Datenbank). Beschreibung	KOM - Klassen-/Objektmodellierung ⁽²⁾	Erstellen
Kapitel 2 SW-Entwurf (Datenbank). Beschreibung	CRC - Class Responsibility Collaboration ⁽²⁾	Erstellen
Kapitel 2.2 SW-Entwurf (Datenbank). Schema Definition	DNAV - Data Navigation Modeling ⁽⁶⁾	Erstellen
	LOGM - Logische DB-Modellierung	Erstellen
	NORM - Normalisierung	Erstellen
Kapitel 2 Data Dictionary. Data Description	AVK - Analyse verdeckter Kanäle ⁽¹⁾	Erstellen
	DVER - Designverifikation ⁽⁴⁾	Erstellen
	FS - Formale Spezifikation ⁽⁵⁾	Erstellen
Kapitel 3 Data Dictionary. Data Realization	AVK - Analyse verdeckter Kanäle ⁽¹⁾	Erstellen
	DVER - Designverifikation ⁽⁴⁾	Erstellen
	FS - Formale Spezifikation ⁽⁵⁾	Erstellen

Werkzeuganforderungen

Produkt	Funktionale Werkzeuganforderungen
Datenkatalog	LSE09 - Informationsstrukturierung unterstützen LSE11 - Spezifikation der Datenbanken unterstützen LSE21 - Datenbanken, Datenstrukturen rückwärts transformieren
Kapitel 2 SW-Entwurf (Datenbank). Beschreibung	LSE09 - Informationsstrukturierung unterstützen LSE11 - Spezifikation der Datenbanken unterstützen LSE21 - Datenbanken, Datenstrukturen rückwärts transformieren LSE22 - Klassen-/Objektmodellierung unterstützen LSE29 - Formale Spezifikation LSE30 - Formal verifizieren LSE31 - Analyse verdeckter Kanäle
Kapitel 2 SW-Entwurf (Modul). Beschreibung	LSE10 - Spezifikation der Komponenten und Module unterstützen LSE20 - Code rückwärts transformieren LSE21 - Datenbanken, Datenstrukturen rückwärts transformieren LSE22 - Klassen-/Objektmodellierung unterstützen LSE24 - Moduldiagramme unterstützen LSE27 - Zustand Modeling in the Object-Oriented Field unterstützen (Kapitel 2.4) LSE28 - Interaktionsmodellierung unterstützen LSE29 - Formale Spezifikation LSE30 - Formal verifizieren LSE31 - Analyse verdeckter Kanäle

Externe Normen

Norm	Prozeß	Kapitel	Bemerkung
/ISO IEC 12207/	Development Prozeß	Software Detailed Design	(s. Part 3 - ISO 3.2.1)

Verknüpfungen mit der V-Modell Mailingliste

Mail 0578 - Re: Kenngrößen (578)
Mail 0304 - Re: Anwenderforderung zur Datenhaltung auf Ebene der SE 1.2
Mail 0261 - SE 5.1 in zwei Teile trennen (261)

Hinweise:

(1) Die Methode AVK ist gemäß [ITSEC] anzuwenden, wenn verdeckte Kanäle in den Sicherheitsvorgaben ausgeschlossen werden und ab der Evaluationsstufe E4 für die Bewertung der Konstruktions- und der operationellen Schwachstellen; als formale Analyse ist AVK ab E6 einzusetzen.

(2) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.

(3) Die Methode ZUSTO ist für die dynamische Systemmodellierung bei objektorientierter Vorgehensweise anzuwenden.

(4) Voraussetzung für den Einsatz von DVER ist eine formale Spezifikation auf zwei verschiedenen Abstraktionsebenen. Aufgrund des hohen Aufwands sind die kritischsten Anteile einer Spezifikation auszuwählen, für die DVER einzusetzen ist. Die Methode DVER ist gemäß [ITSEC] ab Korrektheitsstufe E4 für den Beweis des formalen Sicherheitsmodells anzuwenden. Der Einsatz von DVER zum Beweis, daß der Grobentwurf mit dem Sicherheitsmodell konsistent ist, wird gemäß [ITSEC] in E6 gefordert.

(5) Die Methode FS ist anzuwenden bei besonderen Anforderungen an die Korrektheit, z. B. aufgrund sehr hoher Kritikalität. FS wird gemäß [ITSEC] ab Korrektheitsstufe E4 für die Beschreibung des formalen Sicherheitsmodells gefordert. Der Einsatz von FS für den Grobentwurf wird gemäß [ITSEC] in E6 verlangt.

(6) Die Methode DNAV ist für hierarchische oder netzwerkartige Datenbanktypen anzuwenden.

GDPA Online Last Updated 01.Mar.2002 Updated by Webmaster Last Revised 01.Mar.2002 Revised by Webmaster