134
2 Spezifikation und Modellierung
• Klassendiagramme: Diese Diagramme beschreiben Vererbungsbeziehungen
zwischen Objektklassen.
• Kommunikationsdiagramme (in UML 1.0 Kollaborationsdiagramme genannt): Diese Graphen stellen Klassen, Relationen zwischen Klassen und zwischen diesen ausgetauschte Nachrichten dar.
• Komponentendiagramme: Diese stellen die Komponenten von Anwendungen
oder Systemen dar.
• Objektdiagramme, Interaktions-Überblicks-Diagramme, zusammengesetzte Strukturdiagramme: Diese drei Arten von Diagrammen werden seltener
verwendet. Einige davon sind auch Spezialfälle anderer Diagramme.
Die verfügbaren Werkzeuge erlauben es in begrenzter Weise, die Konsistenz zwischen verschiedenen Diagrammarten zu überprüfen. Eine komplette Überprüfung
scheint aber unmöglich zu sein. Eine Ursache hierfür ist, dass die Semantik von
UML ursprünglich nicht definiert wurde. Es wurde behauptet, dass dies absichtlich
geschah, da die Beschäftigung mit genauer Semantik erst in späteren Entwurfsphasen
erfolgen soll. Folglich lassen sich genaue ausführbare Spezifikationen nur dann aus
einer UML-Beschreibung erzeugen, wenn UML mit einer weiteren Sprache kombiniert wird. Einige verfügbare Werkzeuge kombinieren UML mit SDL [228] und
C++. Es gibt aber auch erste Ansätze, die Semantik von UML zu definieren.
Die Version 1.4 von UML war nicht für eingebettete Systeme entworfen worden.
Daher fehlen dieser Version eine Reihe von Eigenschaften, die zur Modellierung
eingebetteter System unerläßlich sind (siehe Seite 31). Insbesondere fehlen die folgenden Eigenschaften [387]:
• keine Partitionierung von Software in Tasks bzw. Prozesse,
• Zeitverhalten kann nicht beschrieben werden,
• die wesentlichen Hardwarekomponenten eines Systems können nicht in die Beschreibung integriert werden.
Durch die weiter zunehmende Menge an Software in eingebetteten Systemen gewinnt UML auch in diesem Bereich an Bedeutung. Es gibt daher verschiedene Vorschläge für UML-Erweiterungen, die Echtzeitanwendungen unterstützen [387, 137].
Diese wurden in der Entwurfsphase von UML 2.0 berücksichtigt. UML 2.0 beinhaltet 13 Arten von Diagrammen (im Vergleich zu 9 Arten in UML 1.4) [13]. Besondere
Profile berücksichtigen die Anforderungen von Echtzeitsystemen [369]. Diese Profile beinhalten Klassendiagramme mit Beschränkungen, Icons, Diagrammsymbole
und einige (partielle) Semantikbeschreibungen, lassen aber auch semantische Fragen
offen. Es gibt UML-Profile für folgende Aspekte und Aufgaben [369]:
• Schedulability, Leistung, und Zeitangaben [430],
• Testen [434],
• Dienstgüte (Quality of Service (QoS)) und Fehlertoleranz [434],
• Systemmodellierung mit einer Sprache namens SysML [432],
• Modellierung und Analyse von eingebetteten Echtzeitsystemen (MARTE) [431],
• Interoperabilität von UML und SystemC [469],
• Wiederverwendung von Intellectual Property (IP) mit dem SPRINT-Profil [505].
2 Spezifikation und Modellierung
• Klassendiagramme: Diese Diagramme beschreiben Vererbungsbeziehungen
zwischen Objektklassen.
• Kommunikationsdiagramme (in UML 1.0 Kollaborationsdiagramme genannt): Diese Graphen stellen Klassen, Relationen zwischen Klassen und zwischen diesen ausgetauschte Nachrichten dar.
• Komponentendiagramme: Diese stellen die Komponenten von Anwendungen
oder Systemen dar.
• Objektdiagramme, Interaktions-Überblicks-Diagramme, zusammengesetzte Strukturdiagramme: Diese drei Arten von Diagrammen werden seltener
verwendet. Einige davon sind auch Spezialfälle anderer Diagramme.
Die verfügbaren Werkzeuge erlauben es in begrenzter Weise, die Konsistenz zwischen verschiedenen Diagrammarten zu überprüfen. Eine komplette Überprüfung
scheint aber unmöglich zu sein. Eine Ursache hierfür ist, dass die Semantik von
UML ursprünglich nicht definiert wurde. Es wurde behauptet, dass dies absichtlich
geschah, da die Beschäftigung mit genauer Semantik erst in späteren Entwurfsphasen
erfolgen soll. Folglich lassen sich genaue ausführbare Spezifikationen nur dann aus
einer UML-Beschreibung erzeugen, wenn UML mit einer weiteren Sprache kombiniert wird. Einige verfügbare Werkzeuge kombinieren UML mit SDL [228] und
C++. Es gibt aber auch erste Ansätze, die Semantik von UML zu definieren.
Die Version 1.4 von UML war nicht für eingebettete Systeme entworfen worden.
Daher fehlen dieser Version eine Reihe von Eigenschaften, die zur Modellierung
eingebetteter System unerläßlich sind (siehe Seite 31). Insbesondere fehlen die folgenden Eigenschaften [387]:
• keine Partitionierung von Software in Tasks bzw. Prozesse,
• Zeitverhalten kann nicht beschrieben werden,
• die wesentlichen Hardwarekomponenten eines Systems können nicht in die Beschreibung integriert werden.
Durch die weiter zunehmende Menge an Software in eingebetteten Systemen gewinnt UML auch in diesem Bereich an Bedeutung. Es gibt daher verschiedene Vorschläge für UML-Erweiterungen, die Echtzeitanwendungen unterstützen [387, 137].
Diese wurden in der Entwurfsphase von UML 2.0 berücksichtigt. UML 2.0 beinhaltet 13 Arten von Diagrammen (im Vergleich zu 9 Arten in UML 1.4) [13]. Besondere
Profile berücksichtigen die Anforderungen von Echtzeitsystemen [369]. Diese Profile beinhalten Klassendiagramme mit Beschränkungen, Icons, Diagrammsymbole
und einige (partielle) Semantikbeschreibungen, lassen aber auch semantische Fragen
offen. Es gibt UML-Profile für folgende Aspekte und Aufgaben [369]:
• Schedulability, Leistung, und Zeitangaben [430],
• Testen [434],
• Dienstgüte (Quality of Service (QoS)) und Fehlertoleranz [434],
• Systemmodellierung mit einer Sprache namens SysML [432],
• Modellierung und Analyse von eingebetteten Echtzeitsystemen (MARTE) [431],
• Interoperabilität von UML und SystemC [469],
• Wiederverwendung von Intellectual Property (IP) mit dem SPRINT-Profil [505].