Suchen

Systembeschreibung

Dynamische Softwarearchitektur für eingebettete Systeme

Seite: 3/6

Firmen zum Thema

Anforderungsdefinition

Neben funktionalen Anforderungen unterscheiden wir nicht-funktionale (oder extra-funktionale) Anforderungen. Nicht-funktionale Anforderungen beschreiben Forderungen an z.B. die Leistungsfähigkeit, Reaktionsgeschwindigkeit oder Skalierbarkeit des Systems. Da sie häufig Einschränkungen beschreiben unter denen ein System seine Aufgaben erfüllen soll, werden sie im weiteren Verlauf als Constraints bezeichnet.

In der System-Anforderungsanalyse werden nicht-funktionale Anforderungen formalisiert und als Constraints modelliert. Es handelt sich sowohl um statische als auch dynamische Constraints. Dabei wird aktuell zwischen den folgenden Typen von Contraints unterschieden:

Bildergalerie
Bildergalerie mit 10 Bildern
  • Zeit
  • Fläche oder Kosten
  • Leistung und Energie
  • Sicherheit und Zuverlässigkeit, Verfügbarkeit

Aufgrund der Erweiterbarkeit des Metamodells können einfach weitere Arten von Constraints hinzugefügt werden.

Constraints haben einen Gültigkeitsbereich, eine Menge von Modellelementen auf die sie wirken. Sie werden im Anwendungsmodell annotiert. Das erfolgt indem sie zwischen Ankerpunkten (Probes) spezifiziert werden. Diese Ankerpunkte können an jedes Modellelement der Anwendung gebunden werden. Um Constraints, deren Gültigkeitsbereich und Auswirkungen zu visualisieren, werden Symbole für Constraints definiert (vgl. Bild 3 in der Bildergalerie). Der Gültigkeitsbereich eines Constraints wird farblich hervorgehoben.

Die eigentliche nicht-funktionale Anforderung wird durch einen Ausdruck modelliert der für den Gültigkeitsbereich des Constraints erfüllt sein muss. Hierbei unterscheiden sich verschiedene Arten der Erfüllung, z.B. kann eine Constraint erfüllt sein, wenn er auf allen Elementen des Gültigkeitsbereichs in Summe erfüllt ist oder wenn er für jedes Element des Gültigkeitsbereichs einzeln erfüllt ist.

Als Beispiel kann eine zeitliche Einschränkung die maximale Reaktionszeit eines Signals spezifizieren (Formel 1).

Formel 1
Formel 1
(Bild: Universität Ulm)

Dieser Constraint wird mittels Ankerpunkten an die Kommunikations-Links der Anwendung annotiert die dieses Signal beinhalten (Gültigkeitsbereich). Damit wird im funktionalen Systementwurf auch die geforderte zeitliche Einschränkung des Signals visualisiert. Er wird im weiteren Verlauf auch an die Plattform des Systems annotiert und schränkt damit die verwendbaren Plattform-Elemente ein. Mittels dieser formalen Annotationen kann in frühen Entwurfsphasen die Einhaltung der nicht-funktionalen Anforderungen sichergestellt werden.

Plattformentwurf

Ausgehend vom funktionalen Systementwurf und den nicht-funktionalen Anforderungen (Constraints) kann eine passende Plattform abgeleitet werden. Die Modellierung der Plattform für digitale Systeme wird im Folgenden vorgestellt.

Schichtenmodell und Rollentrennung

Wesentliche Konzepte im Systementwurf sind Kapselung und Schichtenbildung. Eine SW-Plattform kann in verschiedene Schichten unterteilt werden. Unser Plattform-Modell ermöglicht die Bildung von Schichten über ein hierarchisches Modell. Damit entspricht die Modellierung einer Plattform-Schicht der Modellierung einer Anwendung die an die darunterliegende Plattform gebunden wird. Unser Plattform-Konzept basiert auf einer Schichtenbildung wobei jede Schicht nur mit ihrer direkt benachbarten höheren oder niederen Schicht kommuniziert.

Dieses Konzept vereinfacht auch die Rollen- und Zuständigkeitstrennung. In unserem generischen Schichtenmodell wird die unterste Schicht durch die HW-Plattform (Schicht 0) repräsentiert. Diese Schicht wird mittels des Plattform-Komponenten-Modells modelliert (siehe Kapitel ”Hardwarearchitektur”). Darüber liegende Plattform-Schichten stellen Dienste bereit die von der jeweils darüber liegenden Schicht (Anwendung) genutzt werden. Diese Schichten werden mittels des Plattform-Domänen-Modells beschrieben (siehe Kapitel ”Adressräume und Dienste des Betriebssystems”). Bild 4 in der Bildergalerie zeigt einen Überblick des Schichtenmodells.

Dadurch werden die Abhängigkeiten zwischen unterschiedlichen Rollen im Entwurfsprozess reduziert. Beispielsweise wird ein Hardware-Entwickler die Hardware-Plattform mittels des Plattform-Komponenten-Modells beschreiben und mit dem Plattform-Entwickler abstimmen. Direkte Abhängigkeiten zwischen Hardware-Entwickler und Anwendungs-Entwickler werden minimiert. Dieser hat im Allgemeinen nur mit dem Plattform-Entwickler Abstimmungsbedarf, denn er benötigt nur die oberste Schicht der Plattform um seine Anwendung zu modellieren.

Hardwarearchitektur

Das Plattform-Komponenten-Modell (eingeführt in [2]) besteht aus Modulen und Komponenten und unterstützt ähnlich dem Anwendungs-Modell hierarchisches Design indem Module aus Modulen oder Komponenten bestehen.

Module sind beispielsweise physikalische Einheiten wie Geräte, Steckkarten oder Chips bzw. SoC (Systems on Chip). Komponenten sind die atomaren Hardware-Elemente, sie enthalten Bus Control Interfaces die als Schnittstellen dienen (vgl. Bild 5 in der Bildergalerie). Ähnlich den Ports im Anwendungs-Modell können auch hier nur kompatible Bus Control Interfaces miteinander verbunden werden.

Weitere Elemente des Plattform-Komponenten-Modells sind Zeit-Elemente die Zeitgeber (Timer) und Uhren (Clocks). Sie können mit allen anderen Elementen verbunden werden und werden mittels eines Timing-Interface mit anderen Elementen verbunden (vgl. Bild 5 in der Bildergalerie).

Ziel dieser Modellierung ist es, die Hardwarearchitektur von Plattformen strukturell bzw. in ihren Bausteinen zu beschreiben. Die Hardwarearchitektur kann durch das im Folgenden Kapitel beschriebene Plattform-Domänen-Modell in Hinblick auf Ressourcen und Dienste substituiert werden. Diese Dienste ermöglichen im weiteren Verlauf die Bindung der Applikation an die Plattform.

(ID:44199816)