Suchen

Systembeschreibung

Dynamische Softwarearchitektur für eingebettete Systeme

Seite: 2/6

Firmen zum Thema

Der epizyklische Entwurfsprozess

Unsere Entwurfs-Methodik erweiterte objektorientierte Entwurfsmethoden wie in [3] auf einen Technologie-unabhängigen komponentenbasierten Ansatz. Er ist iterativ und enthält einen Hauptprozess der aus Teilprozessen besteht. Wir visualisieren unseren Ansatz mittels Kreisen um darzustellen, dass es sich um Iterationen handelt. Alle Teilprozesse sind als Epizyklen auf dem Hauptprozess dargestellt und wird daher als epizyklischer Entwurfsprozess bezeichnet. Bild 1 gibt einen Überblick über den epizyklischen Entwurfsprozess.

Eine Iteration des Hauptprozesses erzeugt eine Ausprägung (Version, Produkt) eines eingebetteten Systems. Eine Iteration besteht aus 5 Teilprozessen die aus Entwurfsschritten besteht. Teilprozesse erzeugen Arbeitsprodukte (Zwischenprodukte) und haben Abhängigkeiten zueinander. Die folgenden 5 Teilprozesse sind definiert:

Bildergalerie
Bildergalerie mit 10 Bildern
  • 1. System-Anforderungsanalyse
  • 2. funktionaler Systementwurf
  • 3. Plattformentwurf
  • 4. Komponenten-Implementierung
  • 5. System-Integration (Implementierung)

Der Hauptprozess kann iterativ kann mehrfach durchlaufen werden. Das zu entwerfende eingebettete System wird in mehreren Iterationen entwickelt (Ausprägungen, Versionen, Baumustern). Eine Iteration des Hauptprozesses ist vergleichbar mit dem einmaligen Durchlaufen des klassischen V-Modells.

Teilprozesse können ebenfalls iterativ mehrfach durchlaufen werden. Sie produzieren Arbeitsprodukte für andere Teilprozesse sowie bei Bedarf interne Arbeitsprodukte und benötigen Inputs anderer Teilprozesse oder aus der Umgebung.

Das Ziel des epizyklischen Entwurfsprozesses ist einerseits eine automatisierte Erstellung von Systemen anwendungszentriert zu ermöglichen. Andererseits soll die systematische und wiederholbare Erstellung von Systemen ermöglicht werden. Die konkrete Plattform bzw. das System entsteht aus Kundenanforderungen bzw. Anforderungen der Anwendung und verfügbaren Plattform-Modellelementen. Dadurch kann sowohl ein optimal auf die Anwendung angepasstes System entwickelt werden als auch der Plattformansatz effizient verfolgt werden.

System-Anforderungsanalyse und funktionaler Systementwurf

Die System-Anforderungsanalyse beinhaltet das klassische Requirements-Engineering mit textuellen Anforderungen die von Bildern/Diagrammen ergänzt werden. In dieser Phase werden Kundenanforderungen aufgenommen, bewertet und abgestimmt. Da die hier erfassten Anforderungen und ihr Einfluss auf das zu entwerfende System in allen nachfolgenden Phasen benötigt werden, werden insbesondere die nicht-funktionalen Anforderungen hier bereits modelliert (formalisiert, wie im Kapitel ”Anforderungsdefinition” beschrieben). Das Ergebnis dieser Phase ist eine Anforderungs-Spezifikation.

Der Funktionale Systementwurf beinhaltet die Modellierung eines funktionalen Systems (auch Anwendung) anhand der funktionalen Anforderungen. Die nichtfunktionalen Anforderungen werden im Modell annotiert um die Auswirkungen auf Anwendung und später Plattform berücksichtigen zu können.

Das Anwendungs-Modell

Das Metamodell für die Anwendung und das umgebende System besteht aus Modulen, Tasks, Ports und Links. Ports dienen als Verbindungspunkte zwischen Modulen und Tasks und werden mittels Links verbunden. Wir unterscheiden zwischen strukturellen Ports und transferorientieren Ports. Im Folgenden werden nur transferorientierte Ports berücksichtigt.

Wir unterscheiden eine Technologie-unabhängige Modellierung und in der nächsten Verfeinerung eine Technologie-abhängige Modellierung. Der Übergang zwischen beiden Phasen wird als Technologie-Bindung bezeichnet (siehe [9]). Anwendungs-Module sind Elemente die andere Elemente wie Module und Tasks enthalten können. Sie werden verwendet um einen hierarchischen Entwurf zu ermöglichen. Ein Modul ist ein strukturelles Element das der Kapselung von Funktionen dient (Geheimnisprinzip). Module dienen der Gruppierung von Tasks oder Modulen mit hoher funktionaler Kopplung.

Module sind keine Elemente physischer Kapselung und sie korrespondieren nicht zwangsläufig mit Elementen der Plattform. Module beschreiben entweder ein Umgebungsmodell oder ein technisches System (die Anwendung).

Das Umgebungsmodell ist ein Modell eines relevanten Ausschnitts der realen Welt das im direkten Zusammenhang mit dem zu entwerfenden technischen System steht. Das technische Systemmodell interagiert mit dem Umgebungsmodell um die geforderten Aktionen/Reaktionen zu erreichen, also die funktionalen Anforderungen zu erfüllen.

Zusammen mit seiner Plattform realisiert ein technisches Systemmodell ein eingebettetes System.

Dem Gedanken des hierarchischen Enthaltenseins von Modulen folgend ist die gesamte Anwendungs-Architektur ebenfalls ein Modul das sowohl das technische System als auch notwendige Umgebungsmodelle enthält.

Anwendungs-Tasks (Tasks) beschreiben und modellieren das Verhalten von Anwendungen. Tasks kapseln das Verhalten und können über Ports miteinander kommunizieren. Ein Task ist ein Entwurfselement das eine Basis-Funktionalität (Verhalten) mit Eingangsgrößen und Ausgangsgrößen bereitstellt. Tasks können beispielsweise Modelle, Gleichungen oder Funktionen sein. Jeder Task besitzt mindestens einen Port.

Neben Tasks mit Basis-Funktionalität gibt es spezielle Tasks die mit anderen Technologien interagieren. Sie werden als Transformations-Tasks bezeichnet und ermöglichen den Austausch zwischen unterschiedlichen Technologien. Andere Spezial-Tasks interagieren mit der Plattform eines technischen Systems. Wir unterscheiden hier Zeit-Tasks die eine Schnittstelle zu Zeit-Informationen der Plattform (Zeit-Ereignissen) bereitstellen und Speicher-Tasks die eine Schnittstelle zu Speicher-Ressourcen der Plattform bereitstellen.

Ports dienen als Kommunikations-Endpunkte für Tasks und Module. Ports werden untereinander durch Links verbunden. Sowohl Ports als auch Links sind durch ihre Schnittstellenbeschreibung typisiert. Nur kompatible Ports können durch passende Links miteinander verbunden werden. Ports modellieren die Ein- und Ausgänge von Tasks und Modulen und beschreiben deren Schnittstellen. Es werden Eingangs- und Ausgangs-Ports unterschieden.

Module können nur spezielle Ports besitzen die als Proxy-Ports bezeichnet werden. Sie dienen als externe Schnittstelle eines Moduls und verbinden die Umgebung des Moduls mit den internen Modulen oder Tasks. Es handelt sich um virtuelle Ports die der Sicherstellung von Kapselung und Geheimnisprinzip des Moduls und der enthaltenen Tasks und Module dient.

Ein Link verbindet zwei kompatible Ports. Ein Ausgangs-Port liefert Entitäten (zum Beispiel Informationen) abhängig von seiner Schnittstellenbeschreibung und ein Eingangs-Port empfängt diese Entitäten. Der verbindende Link erbt seine Schnittstellenbeschreibung von den Ports. Die Art der Schnittstelle kann mittels Symbolen am Link visualisiert werden.

Im ersten Entwurfsschritt werden die funktionalen Anforderungen in eine technologieunabhängige Anwendung überführt. Der nächste Schritt verfeinert diese Anwendung (technisches System) indem Entscheidungen über die realisierenden Technologien getroffen werden. Dieser Schritt wird Technologie-Bindung genannt. Hier werden im Rahmen des funktionalen Systementwurfs die ersten Plattform-Entscheidungen getroffen, denn jede Entscheidung über die Technologie bedingt Entscheidungen und Anforderungen an die Plattform. Hier wird z.B. die Entscheidung zwischen Digitaltechnik oder Analogtechnik getroffen. Wie weiter oben beschrieben wird die Verbindung zwischen unterschiedlichen Technologien durch sog. Transformations-Tasks modelliert.

Ein Modul kann unterschiedliche Technologien enthalten: ein mathematisches Modell, Digitaltechnik (Computersystem oder elektronisches System), ein analoges elektronisches System (Analogtechnik) oder ein physikalisches System (z.B. Mechanik, Optik, Akustik; häufig bei Umgebungsmodellen).

(ID:44199816)