Previous Next V-Model Official Homepage by IABG  
Header  
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
  • Produktfluß

    von Produkt nach Methoden Werkzeug Anf. Ext. Normen
    Aktivität Zustand Kapitel Titel Aktivität Zustand
    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 (1)
    DVER (4)
    FS (5)
    LSE09
    LSE11
    LSE21
    - - 2 SW-Entwurf (Modul).
    Beschreibung
    SE5.2-SW in Bearb. AVK (1)
    KOM (2)
    CRC (2)
    DVER (4)
    FS (5)
    IAM (2)
    MODIAG (2)
    PCODE
    ZUSTO (3)
    LSE10
    LSE20
    SS211
    LSE22
    LSE24
    LSE27
    LSE28
    LSE29
    LSE30
    LSE31
    - - 2 SW-Entwurf (Datenbank).
    Beschreibung
    SE5.2-SW in Bearb. DNAV (6)
    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

    Abwicklung

    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 (1) Erstellen
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    CRC - Class Responsibility Collaboration (2) Erstellen
    DVER - Designverifikation (4) Erstellen
    FS - Formale Spezifikation (5) Erstellen
    IAM - Interaktionsmodellierung (2) Erstellen
    MODIAG - Moduldiagramme (2) Erstellen
    Kapitel 2.4
    SW-Entwurf (Modul).
    Realization of the SW Komponent/ SW Module
    PCODE - Pseudocode Erstellen
    ZUSTO - Zustand Modeling in the OO Field (3) Erstellen
    Kapitel 2.6
    SW-Entwurf (Modul).
    Exceptional Behavior
    PCODE - Pseudocode Erstellen
    Kapitel 2
    SW-Entwurf (Datenbank).
    Beschreibung
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    CRC - Class Responsibility Collaboration (2) Erstellen
    Kapitel 2.2
    SW-Entwurf (Datenbank).
    Schema Definition
    DNAV - Data Navigation Modeling (6) Erstellen
    LOGM - Logische DB-Modellierung Erstellen
    NORM - Normalisierung Erstellen
    Kapitel 2
    Data Dictionary.
    Data Description
    AVK - Analyse verdeckter Kanäle (1) Erstellen
    DVER - Designverifikation (4) Erstellen
    FS - Formale Spezifikation (5) Erstellen
    Kapitel 3
    Data Dictionary.
    Data Realization
    AVK - Analyse verdeckter Kanäle (1) Erstellen
    DVER - Designverifikation (4) Erstellen
    FS - Formale Spezifikation (5) 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.

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