Echtzeiterweiterungen in UML 2.0 und UML-RT

Liste V Embedded Systems WS 03/04

Einführung:

Im folgenden Dokument, das im Rahmen der Lehrveranstaltung Embedded Systems an der Fachhochschule in Wiesbaden entstanden ist, gehe ich auf die Echtzeiterweiterungen in UML 2.0 bzw. UML-RT ein. Es ist von Vorteil wenn sie mit UML vertraut sind, da sich das Verstehen sonst teilweise etwas kompliziert darstellt.

Das Dokument ist zweigeteilt zu betrachten.

Zum ersten sind ca. zwanzig Seiten, die sich mit den Erweiterungen und Notationen für UML beschäftigen wie z.B. neue Notationen für das Sequenzdiagramm oder aber auch den vollkommen neuen Diagrammtypen des Timingdiagramms. Im Anschluss daran habe ich die bisher in UML-RT verwendeten Erweiterungen mit ihren neuen Gegenstücken in UML 2.0 verglichen und gehe noch kurz auf den Mechanismus der Profiles und im Speziellen auf das Profile for Schedulability, Performance, and Time ein. Im zweiten Teil des Dokuments sind sämtliche Stereotypen, die als Erweiterungen für UML im Profile for Schedulability, Performance, and Time sind aufgelistet.

  Liste V Embedded Systems WS 03 /04  

Inhaltsverzeichnis:

  Einführung:  2

  Inhaltsverzeichnis:  3

  Sequenzdiagramm:  5

  Duration Observation:  5

  Duration Constraint:  5

  Time Observation:  6

  Time Constraint:  6

  Timingdiagramm:  7

1.  Form  7

2.  Form  8

3.  Form  8

  Notationen:  9

Vergleich  UML - RT in UML 2 0 :  10

  UML-RT:  10

  Capsules  10

  Ports:  11

  Connectoren:  11

  Protokolle:  12

  Statecharts:  12

  UML 2 0 :  13

  Komponenten:  13

  Ports  13

  Connectoren:  14

  Signale:  14

Interfaces:....................................................................................................................   15

  Statecharts:  16

  Profiles:  17

  Profile for Schedulability, Performance and Time:  18

  RTresourceModeling:  21

  GRMacquire  21

  GRMcode  22

  GRMdeploys  22

  GRMrealize  22

  GRMrelease  23

  GRMrequires  23

  Tagged Values:  24

  RTtimeModeling  24

  RTaction  24

  RTclkInterrupt  25

  RTclock  25

  RTdelay  26

  RTevent  26

  RTinterval  27

  RTnewClock  28

  RTnewTimer  28

  RTpause  29

  RTreset  30

  Christian H. Becker Seite  3

  christian h becker t-online de  

  Liste V Embedded Systems WS 03 /04  

  RTset  30

  RTstart  31

  RTstimulus  31

  RTtime  32

  RTtimeout  33

  RTtimer  33

  RTtimeService  34

  RTtimingMechanism  34

  Tagged Values:  35

  RTconcurrencyModeling  36

  CRaction  36

  CRasynch  36

  CRconcurrent  37

  CRcontains  37

  CRdeferred  38

  CRimmediate  38

  CRmsgQ  39

  CRsynch  39

  SAprofile  39

  SAengine  40

  SAowns  41

  SAprecedes  41

  SAresource  42

  SAresponse  42

  SAschedRes  43

  SAscheduler  43

  SAsituation  44

  SAtrigger  44

  SAusedHost  45

  SAuses  45

  PAprofile  45

  PAclosedLoad  45

  PAcontext  47

  PAhost  47

  PAopenLoad  48

  PAresource  48

  PAstep  49

  Tagged Values:  51

  RSAprofile  51

  RSAchannel  51

  RSAclient  52

  RSAconnection  52

  RSAmutex  54

  RSAorb  55

  RSAserver  55

  Quellenangabe:  56

  Christian H. Becker Seite  4

  christian h becker t-online de  

Liste V Embedded Systems WS 03/04

Sequenzdiagramm:

Das aus UML 1.x bereits bekannte Sequenzdiagramm wurde um Notationen erweitert, die es einem ermöglichen zeitliche Aspekte im Diagramm zu modellieren. Diese Erweiterung ist nicht extra für Echtzeitanwendungen gedacht bietet jedoch eine Möglichkeit einige Anforderungen darzustellen. Bei den Erweiterungen handelt es sich um vier an der Zahl.

1) Duration Observation

2) Duration Constraint 3) Time Observation 4) Time Constraint

Duration Observation:

Diese Notation wird verwendet um eine Dauer zu überwachen / messen. Das bedeutet man kann damit die Dauer der Übertragung einer Nachricht messen / überwachen. Diese Dauer wird im Bild unten mit „d“ gekennzeichnet.

Duration Constraint:

Mit dieser Notation wird eine einzuhaltende Zeitspanne vorgegeben. Damit will ich sagen, dass wie im Bild unten der Vorgang zwischen „d“ und maximal „3*d“ abgeschlossen sein muss. Mit Vorgang ist alles zwischen den Markierungen gemeint.

Liste V Embedded Systems WS 03/04

Time Observation:

Diese Notation wird verwendet, um von einem Zeitpunkt „t“ aus den zeitlichen Verlauf zu überwachen. Beim Bild oben wird damit ein Zeitpunkt „t“ bestimmt ab dem der zeitliche Verlauf überwacht wird.

Time Constraint:

Diese Notation wird verwendet, um eine Zeitspanne zu definieren die ab dem Zeitpunkt „t“ eingehalten werden muss. Im Bild ist dies frühestens „t“ und spätestens „t+3“ wobei mit „3“ drei Zeiteinheiten gemeint sind.

Auf die Standardnotationen gehe ich hier nicht ein, da diese aus UML 1.X bekannt sein sollten.

Liste V Embedded Systems WS 03/04

Timingdiagramm:

Das Timingdiagramm ist ein Diagrammtyp der in UML 2.0 erstmals verwendet wird. Es stammt aus dem Elektro-Ingenieurwesen und dient dazu das Verhalten einer Instanz im zeitlichen Verlauf zu sehen. Die im Kapitel Sequenzdiagramm erklärten Notationen wie Duration Constraint, Time Observation, Duration Observation und Time Constraint können auch hier verwendet werden. Zur genaueren Erläuterung bitte ich sie in diesem Kapitel nachzulesen. Ein Timingdiagramm kann in drei Formen dargestellt werden.

Das Diagramm oben zeigt eine Instanz der Klasse User mit den Zuständen Idle, WaitCard und WaitAccess. Dadurch wird auch ein weiterer Unterschied zum Sequenzdiagramm deutlich, nämlich das Anzeigen von Zuständen. Die tick mark values und der timing ruler sind Notationen um den zeitlichen Verlauf einzuteilen, darzustellen und Zeitmarken zu setzen. Die Bezeichner Code, CardOut und OK sind Messages, wie im Sequenzdiagramm.

Liste V Embedded Systems WS 03/04

2. Form

Diese Darstellungsform wird verwendet um Nachrichtenlose

Zustandsübergänge auch mit Zeitverlauf darzustellen. Die Zustände werden im inneren der Lifeline gezeichnet und das Kreuzen der beiden Außenlinien zeigt eine Zustandsänderung der Instanz an.

3. Form

Diese Form ist eigentlich identisch mit der 1. allerdings zeigt sie zwei Klassen im Verhalten zueinander.

Liste V Embedded Systems WS 03/04

Notationen:

Die Grafiken auf dieser Seite sind alle von [1]

Christian H. Becker

Liste V Embedded Systems WS 03/04

Vergleich UML - RT in UML 2.0:

Auf den folgenden Seiten werde ich die Echtzeiterweiterung UML-RT kurz erläutern und anschließend aufzeigen, wie diese in UML 2.0 umgesetzt wurden.

UML-RT:

UML-RT wurde 1999 erstmals in UML 1.1 eingebracht. Nicht in der Standartnotation sondern als Erweiterung. Alle in diesem Teil erklärten Notationen sind in UML-RT definiert. UML-RT wurde verwendet um UML zur Echtzeitmodellierung verwenden zu können. Die Definitionen wurden größtenteils von ROOM übernommen. Daher stammt auch der Name UML-RT, welcher vom Tool ROSE-RT abgeleitet wurde.

Capsules

Jede Capsule repräsentiert ein potentiell aktives Objekt, welches entweder für sich alleine stehen kann oder aber stark hierarchisch in Subcapsules gekapselt ist. Bei einer solchen Schachtelung delegiert die Muttercapsule sozusagen die Subcapsules. Die Kommunikation zwischen Capsules, egal ob Extern oder Intern, geschieht ausschließlich durch gepufferten asynchronen Nachrichtenaustausch der über Ports geschieht. Sollte der Port beim eintreffen einer Nachricht gerade blockiert sein, wird diese in einer Queue gespeichert bis sie bearbeitet werden kann. Das Verhalten einer Capsule wird mittels eines Statecharts definiert. Der aus ROOM bekannte Name Actor wurde in UML-RT nicht verwendet, da es zu Konflikten mit dem im Use Case Modell verwendeten Actor geführt hätte.

Die Grafik zeigt eine Capsule CLS mit den Subcapsules CommandHandler und MotorControl, die über Ports mit der Muttercapsule oder anderen

Liste V Embedded Systems WS 03/04

Externen Capsules verbunden sind. Auf die Port Typen gehe ich in der Erläuterung Ports ein.

Ports:

Ports sind wie im Kapitel Capsules beschrieben der Kommunikationsweg der Capsule. Obwohl jede Capsule mehrere Ports haben kann, kann ein Port nur ausschließlich zu einer Capsule gehören. Der Port erwartet und versendet die Signale nach einem fest definierten Protokoll. Darauf wird im Kapitel Protokoll eingegangen. Es gibt zwei Arten von Ports und zwar die Relay Ports und die End Ports.

Die Grafik zeigt wo der Unterschied zwischen den beiden Porttypen ist. Während der End Port zur Kommunikation mit der Capsule zu der er gehört dient, wird der Relay Port dazu verwendet die Nachrichten an Subcapsules weiterzuleiten oder umgekehrt. Dadurch kann die Subcapsule ihrerseits mit der Muttercapsule kommunizieren.

Connectoren:

Connectoren sind der definierte Übermittlungsweg für Nachrichten zwischen Ports. Ports die nicht über Connectoren miteinander verbunden sind können auch nicht miteinander kommunizieren.