Previous Next V-Model Official Homepage by IABG  
Header  
SE 4.1-SW: SW-Architektur entwerfen  

  SD4.1-SW - SW Architecture Design

Inhalt  
  • Produktfluß
  • Abwicklung
  • Erläuterungen
  • 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 Arch. Design

    SE2 akzeptiert Alle Systemarchitektur - -    
    SE3 akzeptiert Alle Technische Anforderungen - -    
    SE2 in Bearb. Existierend Schnittstellenübersicht SE4.2-SW
    SE5-SW
    KM4.3
    vorgelegt KOM (2)
    MODIAG (2)
    SSM (2)
    LSE22
    LSE23
    LSE24
    LSE29
    LSE30
    LSE31
    SE3 in Bearb. Existierend Betriebsinformationen:
    Anwendungshandbuch
    Diagnosehandbuch
    Betriebshandbuch
    Sonstige Einsatzinformationen
    SE4.3-SW in Bearb.    
    - - Alle SW-Architektur SE4.2-SW
    SE4.3-SW
    SE5-SW
    vorgelegt AVK (7)
    KOM (2)
    DVER (6)
    FS (5)
    IAM (2)
    MODIAG (2)
    OBJE (8)
    PZIM (3)
    PRODIAG (2)
    SSM (2)
    ZUST (4)
    STRD (8)
    LSE01
    LSE03
    LSE04
    LSE20
    LSE22
    LSE23
    LSE24
    LSE25
    LSE28
    LSE29
    LSE30
    LSE31

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

    Abwicklung

    * SW-Architektur entwerfen

    Die SW-Architektur beschreibt die Zerlegung einer SW-Einheit in SW-Komponenten, Prozesse, SW-Module und Datenbanken. Vorschläge für mögliche SW-Architekturen werden erarbeitet und bewertet; für die weitere Bearbeitung ist ein Lösungsvorschlag auszuwählen.

    SW-Einheiten bestehen im allgemeinen aus mehreren Prozessen oder Tasks, die parallel oder quasi-parallel ablaufen. Ziel ist es, eine SW-Einheit unter dem Gesichtspunkt notwendiger oder möglicher Parallelverarbeitung zu strukturieren. Dabei sind die Gegebenheiten des Betriebs- und Laufzeitsystems und die Erfordernisse und Einschränkungen der Hardware und der Programmiersprache zu berücksichtigen. Die SW-Architektur enthält eine Beschreibung des Prozeß-Ensembles samt seiner Strukturierung, Kommunikation, Synchronisation und Darstellung des dynamischen Ablaufmodells.

    Zu jedem Baustein (Prozeß, SW-Komponente, SW-Modul, Datenbank) des ausgewählten Vorschlags sind eine kurze Leistungsbeschreibung und die Relevanz hinsichtlich der Sicherheit (Kritikalitätsstufe, sicherheitsspezifische Funktion, sicherheitsrelevante Funktion) anzugeben.

    Die aufgrund von Architekturentscheidungen festgelegten Schnittstellen sind in der SW-Architektur zu identifizieren und in der Schnittstellenübersicht zu dokumentieren.

    Die vollständige Abdeckung der Anforderungen durch die in der SW-Architektur definierten Prozesse, SW-Komponenten, SW-Module und Datenbanken ist nachzuweisen.

    Auf der Basis der SW-Architektur sind Angaben für die Betriebsinformationen (Anwendungshandbuch, Diagnosehandbuch, Betriebshandbuch, Sonstige Einsatzinformationen) zu erarbeiten.

    * IT-Sicherheitsaspekte beachten

    Neben den Abhängigkeiten der IT-Sicherheitsfunktionen sind die Wechselwirkungen der IT-Sicherheitsmechanismen, die zur Realisierung der IT-Sicherheitsfunktionen gewählt wurden, zu untersuchen. Es sind die Auswirkungen, die die Realisierung der IT-Sicherheitsfunktionen auf andere SW-Einheiten haben könnte, zu untersuchen. Ebenso sind die Abhängigkeiten von Funktionen hinsichtlich der Kritikalität zu untersuchen.

    Es ist festzustellen, ob und gegebenenfalls welche IT-sicherheitsspezifischen oder IT-sicherheitsrelevanten Anteile(1) in anderen SW-Komponenten/SW-Modulen/Datenbanken bei der Realisierung entstehen.

    Die Schnittstellen vom IT-sicherheitsrelevanten zum IT-sicherheitsunkritischen Teil sind in jeder SW-Einheit zu minimieren. Diese Schnittstellen in jeder SW-Einheit und zwischen den einzelnen SW-Einheiten sind exakt zu definieren.

    Erläuterungen

    In der Regel werden neben den für die Realisierung von operationellen Anwendungsfunktionen erforderlichen SW-Komponenten/SW-Modulen auch SW-Komponenten/SW-Module benötigt, die lediglich technische Hilfsfunktionen zur Verfügung stellen und deshalb nicht aus den operationellen Anforderungen, sondern aus den Gegebenheiten des technischen Lösungsansatzes herzuleiten sind (z. B. Gateway-Elemente). Diese sind bei der Festlegung der SW-Architektur mit zu berücksichtigen.

    Einfluß auf diese Modularisierungsentscheidungen haben::

    Rollen

    Rolle Beteilungsarten
    SW-Entwickler verantwortlich
    Technischer Autor mitwirkend
    Produkt Methodenzuordnung Benutzung
    Kapitel 2
    SW-Architektur.
    Solution Proposals
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    MODIAG - Moduldiagramme (2) Erstellen
    PRODIAG - Prozeßdiagramme (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 3
    SW-Architektur.
    Modularization/Datenbank Design
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    MODIAG - Moduldiagramme (2) Erstellen
    PRODIAG - Prozeßdiagramme (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 3.1
    SW-Architektur.
    Overview of SW Komponente, SW Modules,
    Processes and Databases
    OBJE - Objektentwurfstechnik (8) Erstellen
    STRD - Structured Design (8) Erstellen
    Kapitel 3.2
    SW-Architektur.
    Individual Descriptions
    AVK - Analyse verdeckter Kanäle (7) Bewertenment
    DVER - Designverifikation (6) Erstellen
    FS - Formale Spezifikation (5) Erstellen
    PZIM - Prozeß Interaktionsmodellierung (3) Erstellen
    ZUST - Zustand Transition Modeling (4) Erstellen
    Kapitel 3.3
    SW-Architektur.
    Dynamic Sequence Model
    AVK - Analyse verdeckter Kanäle (7) Bewertenment
    DVER - Designverifikation (6) Erstellen
    FS - Formale Spezifikation (5) Erstellen
    IAM - Interaktionsmodellierung (2) Erstellen
    PZIM - Prozeß Interaktionsmodellierung (3) Erstellen
    Kapitel 4
    SW-Architektur.
    Interfaces
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 3
    Schnittstellenübersicht.
    System-Internal Interfaces
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    MODIAG - Moduldiagramme (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen

    Werkzeuganforderungen

    Produkt Funktionale Werkzeuganforderungen
    Kapitel 2
    SW-Architektur.
    Solution Proposals
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen
    LSE24 - Moduldiagramme unterstützen
    LSE25 - Prozeßdiagramme unterstützen
    LSE29 - Formale Spezifikation
    LSE30 - Formal verifizieren
    LSE31 - Analyse verdeckter Kanäle
    Kapitel 3
    SW-Architektur.
    Modularization/Datenbank Design
    LSE03 - Architekturentwurf unterstützen
    LSE04 - Prozeßmodellierung unterstützen
    LSE20 - Code rückwärts transformieren
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen
    LSE24 - Moduldiagramme unterstützen
    LSE25 - Prozeßdiagramme unterstützen
    LSE29 - Formale Spezifikation
    LSE30 - Formal verifizieren
    LSE31 - Analyse verdeckter Kanäle
    Kapitel 3.3
    SW-Architektur.
    Dynamic Sequence Model
    LSE28 - Interaktionsmodellierung unterstützen
    Kapitel 4
    SW-Architektur.
    Interfaces
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen
    LSE29 - Formale Spezifikation
    LSE30 - Formal verifizieren
    LSE31 - Analyse verdeckter Kanäle
    Kapitel 5
    SW-Architektur.
    Requirements Allocation
    LSE01 - Anforderungen erfassen
    Kapitel 3
    Schnittstellenübersicht.
    System-Internal Interfaces
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen
    LSE24 - Moduldiagramme 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 Architectural Design (s. Part 3 - ISO 3.2.1)

    Verknüpfungen mit der V-Modell Mailingliste

    Mail 0724 - Re: Abdeckungsmatrix (724)
    Mail 0524 - Mehrere Fragen zum V-Modell (524)
    Mail 0251 - Midestanforderungen (251)


    (1 ) Unter "IT-sicherheitsspezifischen oder IT-sicherheitsrelevanten Anteilen" werden auch die Funktionen hoher Kritikalität verstanden, die durch entsprechende Maßnahmen realisiert werden.

    (2 ) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.

    (3 ) Die Methode PZIM ist anzuwenden, wenn der Entwurf mehrere parallel auszuführende Prozesse enthält.

    (4 ) Die Methode ZUST ist anzuwenden, wenn beim Ablauf der Funktion oder des Prozesses komplexe Situationen zu berücksichtigen sind.

    (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 ) 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.

    (7 ) 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.

    (8 ) Die Methode OBJE ist anzuwenden für eine realzeitorientierte Entwicklung mit nebenläufigen Prozessen; sonst ist die Methode STRD anzuwenden.

    Previous Next This page online  •  GDPA Online  •  Last Updated 07.Mar.2004 by C. Freericks