Referat „COMET-Basis“

Präsentation zum Thema: "Referat „COMET-Basis“"—  Präsentation transkript:

1 Referat „COMET-Basis“
von Rebekka Oeters im Rahmen des Seminars „Entwicklung eingebetteter und verteilter Systeme“ WS 01/02 Begrüssung Vorstellung Einführungsreferat zur COMET Methode halten zuerst soll die Gliederung des Referats vorgestellt

2 COMET-Basis von Rebekka Oeters WS 01/02
Gliederung Überblick über die Softwareentwicklungsmethode COMET Use Case Modellierung Statische Modellierung Klassen- und Objektstrukturierung Modellierung von endlichen Zustandsautomaten Modellierung der Interobjektkommunikation UML-RT Fazit Use Case Modellierung => Anforderungsmodellierung Statische - Interobjektkommunikation => Analysemodellierung Entwurfsmodellierung und alle weiteren Phasen der COMET Methode werden in späteren Referaten vorgestellt! UML-RT => als ergänzende Möglichkeit der Modellierung von Objektinterkationen COMET-Basis von Rebekka Oeters WS 01/02

3 COMET-Basis von Rebekka Oeters WS 01/02
Überblick über COMET COMET ist eine Softwareentwicklungs-methode für nebenläufige, verteilte und Echtzeitsysteme Iterativer Softwarelebenszyklus Use Case Modellierung als Ausgangspunkt für alle weiteren Entwicklungsphasen Methode zum Entwurf nebenläufiger, verteilter und Echtzeitsoftwaresysteme COMET steht für ... Ausgangsthese der COMET Methode ist, dass Use Cases verschieden granular in allen Entwicklungsstufen des zu entwickelnden Softwaresystems betrachtet und eingesetzt werden können => System wird in alle Phasen ausgehend von den modellierten Use Cases schrittweise verfeinert und detaillierter beschrieben Nun sollen die einzelnen Phasen der COMET Methode kurz erläutert werden COMET-Basis von Rebekka Oeters WS 01/02

4 COMET – Objektorientiertes Softwarelebenszyklusmodel
Begonnen wird mit der Anforderungsmodellierung, also der Definition der funktionalen Anforderungen an das zu entwicklende Softwaresystem Das Anforderungsmodell wird mit Hilfe von Use Cases, natürlichsprachlichen Beschreibungen dieser und mit Hilfe von Akteuren aufgestellt => das System wird als black box betrachtet Die Erstellung eines throwaway-Prototypen kann zur Anforderungsfindung beitragen Besonders in dieser Phase ist die aktive Partizipation der Nutzer des Systems wichtig Analysemodellierung: in dieser Phase liegt der Fokus auf dem zu modellierenden Problembereich und der Identifizierung der statischen und dynamischen Aspekte des Systems zur Definition der Klassen und ihrer Beziehungen für den zu modellierenden Problembereich wird ein Klassendiagramm erstellt zur Festelegung der Grenze zwischen dem System und seiner Umgebung wird ein Systemkontectdiagramm erstellt Klassen- und Objektstrukturierungskriterien dienen zur Findung der für das System relevaten Klassen und Objekte innerhalb der dynamischen Modellierung werden Objektintrakommunikationen mit Hilfe von Statecharts und Objektinteraktionen mit Hilfe von Kollabrotationsdiagrammen definiert Entwurfsmodellierung: ist nicht mehr Bestandteil dieses Referats, dient zur Beschreibung der Architektur des zu entwickelnden Systems, also des Aufbaus und der Unterteilung in Subsysteme Inkrementellen Softwarekontruktion: Entwurf, Implementierung und Testen der einzelnen Subsysteme und Integration in bereits konstruierte Subsysteme Softwareintegration: Durchführung von Integrationstest basierend auf den entsprechenden Use Cases => jedes Softwareinkrement wird als inkrementeller Prototyp betrachtet => bei Festelltung von Fehlern / Problemen / neuen oder geänderten Anforderungen Iterationen!!! Systemtest: entwickeltes Softwaresystem bzgl. Der Anforderungen testen Es soll nun genauer auf die Phase der Anforderungsmodellierung eingegangen werden ... COMET-Basis von Rebekka Oeters WS 01/02

5 COMET-Basis von Rebekka Oeters WS 01/02
Use Case Modellierung Beschreibung der funktionalen Anforderungen an das System in Form von Use Cases und Akteuren Identifikation und Dokumentation von Use Cases 4 Arten von Akteuren: Menschliche Nutzer Externe Systeme Externe Ein- oder Ausgabegeräte Timer Ziel der Anforderungsmodellierung ist die Beschreibung der funktionalen Anforderungen an das System in Form von Use Cases und Akteuren Use Case: stellt einen Anwendungsfall und Verhaltensaspekt des Systems dar und definiert eine Abfolge von Interaktionen zwischen den Akteuren und dem System; System wird als black box betrachtet Eine gpnstige Vorgehensweise ist es, zurest die Akteure, also die Nutzer, die mit dem System interagieren, zu betrachten und dann die Aktionen, die sie innerhalb des Systems auslösen daraus ergeben ist Interaktionsabfolgen zwischen einem oder mehreren Akteuren und dem System, die in Abhängigkeit von ihrem inhaltlichen Schwerpunkt zu verschiedenen Use Cases zusammengefasst werden können ein Use Case kann neben einem Hauptszenario (Interaktionsabfolge) mehrere alternative Szenarien beinhalten COMET Methode schlägt folgende natürlichsprachliche Dokumentation von Use Cases vor: Name, kurze inhaltliche Beschreibung, Akteure, Vorbedingungen, Hauptinteraktion, alternative Szenarien, Nachbedingung nach Ausführung der Haputinteraktion, ggf. noch zu klärende Fragen Innerhalb der COMET Methode werden vier Arten von Nutzern unterschieden Im folgenden sollen beispielhaft ein menschlicher Nutzer und ein externes Eingabegerät als Akteure innerhalb eines Elevator Control Systems betrachtet werden Dieses System soll nun kurz vorgestellt werden... COMET-Basis von Rebekka Oeters WS 01/02

6 Elevator Control System
3 1 2 Elevator Buttons Lamps Elevator Door Direction Lamps Floor Buttons Motor Arrival Sensor Floor Lamps Bei dem Elevator Control System handelt es sich um ein nebenläufiges System; es kontrolliert einen oder mehrere Elevator, muss parallel mehrere Nutzeranfragen verarbeiten und die Elevator dementsprechend koordinieren Folgende Bestandteile sind bei der Modellierung des Elevator Control Systems relevant: ... Innerhalb des Elevators: Elevator Buttons und Elevator Lamps Elevator Door, Elevator Motor auf jeder Etage: ein Arrival Sensor im Elevator Schacht, Floor Buttons, Floor Lamps, die zeigen, ob ein Floor Button gedrückt wurde und Direction Lamps, die die Fahrtrichtung des Elevators anzeigen Nun zu den beiden Akteuren, die mit dem System interagieren... COMET-Basis von Rebekka Oeters WS 01/02

7 Use Cases und Akteure des Elevator Control Systems
Innerhalb des Elevator Control Systems gibt es zwei Akteure Zum einen den Elevator User, der mittels der Floor und Elevator Buttons mit dem System interagiert Zum anderen den Arrival Sensor, der dem System mitteilt, auf welcher Ebene sich der Elevator gerade befindet Um die funktionalen Anforderungen an das System zu beschreiben, werden folgende zwei Use Cases modelliert: Select Destination Use Case: beschreibt den Anwendungsfall, dass der sich im Elevator befindende Elevator User einen Elevator Button drückt, die Anfrage innerhalb des Systems verarbeitet wird, der Elevator sich in Richtung der dementsprechenden Etage bewegt, der Arrival Sensor jeweils bei Errreichen einer Etage dies dem System mitteilt und der Elevator letztendlich bei Errreichen der vom Elevator User gewähtlen Etage anhält Request Elevator Use Case: beschreibt den Fall, dass sich der Elevator User auf einer Etage befindet und mit Hifle eine Floor Buttons einen Elevator anfordert; diese Anfrage wird wiederum innerhalb des Systems verarbeitet, der Elevator wird in Richtung der angeforderten Etage in Bewegung gesetzt und hält an der vom Elevator User ausgewählten Etage an und die Elevator Door öffent sich Beiden Use Cases ist gemein, dass zum einen der Arrival Sensor bei Bewegung des Elevators dem System mitteilt, dass der Elevator die entsprechende Etage erreicht hat und das System darufhin prüft, ob der Elevator aufgrund einer vorliegenden Anfrage angehalten werden soll oder nicht Zum anderen muss das System nach Abarbeitung einer Anfrage immer prüfen, ob eine weitere Anfrage vorliegt und in Abhängigkeit davon die Elevator Door schlissen und dem Elevator Motor mitteilen, den Elevator in die entsprechende Richting zu bewegen Bevor ich auf die Möglichkeit eingehe, diese in beiden Use Cases vorkommenden Interaktionsfolgen in abstrkate Use Cases auszulagern, möchte ich noch kurz auf die Klassifizeirung von Akteuren und die möglichen Beziehungen zwischen Use Case eingehen... COMET-Basis von Rebekka Oeters WS 01/02

8 Akteure und Use Case Beziehungen
Primäre versus sekundäre Akteure Use Case Beziehungen: <<extend>> <<include>> Es wird zwischen primären und sekundären Akteuren unterschieden ein primärer Akteur ist ein solcher, der einen Use Case initiiert ein sekundärer Akteur ist ein Akteur, der innerhalb eines Use Cases partizipiert, ihn aber nicht initiiert Bei der Use Case Modellierung können desweiteren Beziehungen zwischen Use Cases modelliert werden extend Beziehung: dient zum einen dazu, die Komplexität eines Use Cases mit vielen alternativen Interaktionsabfolgen durch Aufspaltung des Use Cases zu reduzieren => Resultat ist ein Basis-Use Case und mehrere diesen Use Case erweiternde Use Cases, die die alternativen Interaktionsabfolgen beinhalten zum anderen können mit Hilfe der extend Beziehung sogenannte extension points innerhalb eines Use Cases definiert werden, die genau festlegen, in welchen Punkten ein Use Case erweitert werden kann; ein Basis-Use Case ist unabhängig von der Existenz der ich nerweiternden Use Cases, umgekehrt gilt dies jedoch nicht! Mit Hifle der include Beziehung können abstrakte Use Cases modelliert werden, deren Interaktionsabfolgen in Use Cases, die einen abstrakten Use Case inkludieren, weiderverwendet werden können. Dies ist im Elevator Control System wie vorher schon erläutert der Fall... COMET-Basis von Rebekka Oeters WS 01/02

9 Use Case Model des Elevator Control Systems
Wie schon im ersten Use Case Modell für das Elevator Control System gesehen, sind die beiden Use Cases Select Destination (User ist im Elevator und drückt Elevator Button) und Request Elevator (User ist auf Etage und drückt Floor Button) innerhalb des Use Case Modells enthalten Neu hinzugekommen sind die beiden folgenden bereits inhaltlich beschriebenen Use Case: Dispatch Elevator: das System muss nach Abarbeitung einer Anfrage immer prüfen, ob eine weitere Anfrage vorliegt und in Abhängigkeit davon die Elevator Door schliessen und dem Elevator Motor mitteilen, den Elevator in die entsprechende Richting zu bewegen Stop Elevator at Floor: der Arrival Sensor teilt dem System bei Bewegung des Elevators mit, dass der Elevator die entsprechende Etage erreicht hat und das System darufhin prüft, ob der Elevator aufgrund einer vorliegenden Anfrage angehalten werden soll oder nicht Hierbei handelt es sich um das komplette Use Case Modell für das Elevator Control System, die Phase der Anforderungsmodellierung ist somit abgeschlossen und ich möchte nun die Phase der Analysemodellierung beginnend mit der statischen Modellierung vorstellen... COMET-Basis von Rebekka Oeters WS 01/02

10 Statische Modellierung
Ziel ist die Definition der problem-spezifischen und statischen Strukturaspekte des Systems Erstellung eines Systemkontext-diagramms zur Festlegung der Schnittstelle zwischen dem System und der externen Umgebung Ziel der statischen Modellierung ist die Definition der problemspezifischen und statische nStrukturaspekte innerhalb eines Klassendiagramms, das Klassen, deren Attribute und Beziehungen mit anderen Klassen beschreiben soll besondere Bedeutung komment der im Problembereich enthaltenen Informationen, die im System gepsiechert werden sollen zu, sowei der Modellierung von physikalischen Klassen bei eingebetteten Systemen Das aus dieser Phase resultierende Klassendiagramm enthält nicht alle später einmal im System vorhandenen Klassen, sondern meist nur datenintensive, sogenannte Extity-Klassen und physikalische Klassen wie z.B. physikalischen Geräte, externe Systeme oder Timer Beispielhaft soll das Klassendiagramm des Elevator Control Systems vorgestellt werden Auf die verwendeten Modellierungselemente wie z.B. Assoziationen, Kompositionen und Multiplizitäten soll hier nicht näher eingegangen werden, da diese sicherlich allen bekannt sind => Klassendiagramm zeigen!!! Die Erstellung des Systemskontextdiagramms ist notwendig, um die Schnittstelle zwischen dem zu entwicklenden System und der externen Umgebung zu definieren Bei der Erstellung des Systemkontextdiagramms kann neben dem Klassenmodell das Use Case Modell zu Hilfe gezogen werden, da die innerhalb des Klassenmodells enthaltenen Akteure identifiziert werden können, die ausserhalb des Systems liegen desweiteren stellen die im Klassendiagramm modellierten physikalischen Klassen meist externe Klassen dar Ich möchte beispielhaft das Kontextklassendiagramm des Elevator Control Systems vorstellen ... COMET-Basis von Rebekka Oeters WS 01/02

11 Klassendiagramm für das Elevator Control System
Das Klassendiagramm definiert die für das Elevator Control System relavanten Klassen z.B. Elevator, der aus ... Besteht und die Beziehungen zwischen den Klassen z.B. stehen Elevator und Arrival Sensor miteinander in Beziehung Ich möchte nun auf die Erstellung die Systemkontextdiagramms eingehen... WIEDER ZURUECK BLAETTERN!!! COMET-Basis von Rebekka Oeters WS 01/02

12 Systemkontextdiagramm für das Elevator Control System
Bei der Erstellung des Systemkonstectdiagramms wird das Systems als Aggregat betrachtet und mit dem dem Stereotyp <<system>> gekennzeichnet Ein Stereotyp ist eine semantische und syntaktische Erweiterung eines vorhandenen Modellelements des UML-Metamodells Ebenso wie das Systemaggregat werden auch die ausserhalb des Systems liegenden Klassen mit Stereotypen gekennzeichnet auf die zur Verfügung stehenden Stereotypen wird im nächsten Kapitel bei der Klassenstrukturierung noch einmal genauer drauf eingegangen Das Systemkontextdiagramm für das Elevator Control System bringt also zum Ausdruck, dass alle Ein- und Ausgabegeräte ausserhalb des Systems liegen Nach dieser Modellierung der problemspezifischen und statischen Strukturaspekte des zu entwickelnden Softwaresystems sollen in der nächsten Entwicklungsphase nun die für das System relevanten Objekte identifiziert werden ... COMET-Basis von Rebekka Oeters WS 01/02

13 Klassen- und Objekt-strukturierung
Kategorisierung von systeminternen und externen Klassen des Systems mit Hilfe von Stereotypen Ziel ist die Identifizierung der konkreten Softwareobjekte, aus denen das System komponiert wird Verwendung von Objektstrukturierungs-kriterien und Stereotypen zur Klassifizierung Bevor auf die Identifizierung der für das System relevanten Objekte eingegangen wird, möchte ich kurz noch auf die Klassifizierung von externen und internen Klassen des Systems eingehen Ziel der Klassifizierung von Klassen mit Hilfe von Stereotypen ist es, ein besseres Verständnis für das zu entwickelnde System zu bekommen, da einige der angeführten Klassenkategorien in vielen Systemen vorhanden sind ´BLAETTERN!! COMET-Basis von Rebekka Oeters WS 01/02

14 Klassifikation von Anwendungsklassen mit Hilfe von Stereotypen
<<application>> <<interface>> <<entity>> <<control>> <<application logic>> <<business logic>> <<algorithm>> <<user interface>> <<device interface>> <<system interface>> <<timer>> <<coordinator>> <<state dependent control>> Die von Gomaa vorgestelle Klassengruppierung findet auf einer abstrakteren Ebene statt, als die später vorgestellte Kategorisierung von Objekten des Systems Ich stelle die Klassifikationshierachie an dieser Stelle vor, daeinige der aufgefürhten Stereotypen auch bei der später vorgestellten Objektstrukturierung wieder auftauchen so z.B. das Stereotyp entiy, verschiedene device interfaces und control - Stereotypen!! Wie schon im Systemkontextdiagramm ersichtlich, führt Gomma auch für externe Klassen verschiedene Stereotypen ein - an dieser Stelle soll nun kurz die dazugehörige Klassifikationshierarchie vorgestellt werden ... BLAETTERN!!! <<input device interface>> <<output device interface>> <<input / output device interface>> COMET-Basis von Rebekka Oeters WS 01/02

15 Klassifikation von externen Klassen mit Hilfe von Stereotypen
<<external>> <<external timer>> <<external device>> <<external system>> <<external user>> Die genaue Klassifizierung der externen Klassen mit Hilfe von Stereotypen erleichtert die im folgenden vorgestellte Identifikation der im System enthaltenen Objekte Dies ist damit zu erklären, dass es meist für jede externe Klasse eine Schnittstellenklasse innerhalb des Systems geben muss, die die für das System relevaten Eingaben von den externen Klassen empfängt bzw. die vom System erzeugten Ausgaben an die externen Klassen weiterleitet Nachdem nun Klassifizierungsmöglichkeiten für Klassen vorgestellen wurden, möchte ich nun auf die Identifikation und Kategorisierung der Objekte innerhalb eines Softwaresystems eingehen... <<external input device>> <<external output device>> <<external input / output device>> COMET-Basis von Rebekka Oeters WS 01/02

16 Objektstrukturierungskriterien (1)
Ziel ist die Klassifikation der Objekte, die in einem System enthalten sind, bzgl. ihrer Rolle, die sie im System spielen Verwendung von Objektstrukturierungskriterien: Interface Objects: Device Interface Objects User Interface Objects System Interface Objects Ziel dieser Phase der Softwareentwicklung ist die Klassifikation der Objekte, die in einem System enthalten sind, bzgl. Iherr Rolle, die sie im System spielen Dabei findet gleichzeitig eine Dekomposition des Systems in Objekte statt, die es ermöglicht, Teilkomponenten des Systems inkrementell zu entwickeln Folgende Objektstrukturierungskriteiren werden zur Klassifikation der Objekte verwendet: Interface Objekte stellen eine Schnittstelle zwischen dem System und der externen Umgebung dar und werden wie folgt unterteilt: Device Interface Objete: interagieren mit externen Geräten => innerhalb des Elevator Control Systems gibt es z.B. folgende Device Interface Objekte: ArrivalSensorInterface-Objekt, das eine Schnittstelle zum ArrivalSensor darstellt User Interface Objekte stellen Schnittstellen zu menschlichen Nutzern mittels Standard-Ein- und Ausgabegeräten dar System Interface Objekte dienen als Schnittstekke zu externen Systemen COMET-Basis von Rebekka Oeters WS 01/02

17 Objektstrukturierungskriterien (2)
Weitere Objektstrukturierungskriterien: Entity Objects Control Objects: Coordinator Objects State dependent control Objects Timer Objects Application Logic Objects: Business Logic Objects Algorithm Objects Bei Entity Objekten handelt es sich um langlebige Objekte, in denen Informationen abgespeichert werden beim Elevator Control System stellt das Elevator Status & Plan Objekt ein solches Objekt dar, da es Informationen bzgl. Der Bewegungsrichting eines Elevators enthält, den letztbesuchten Floor abspeichert und eine Liste aller noch zu besuchenden Floors enthält Control Objekte koordinieren mehrere einem Use Case angehörende Objekte und werden wie folgt unterteilt: Coordinator Objekte: bestimmen die Partizipationsreihenfolge zwischen Objekten in Abhängigkeit von den Eingaben, die sie erhalten State dependent Control Objekte: verarbeiten Eingaben in Abhängigkeit von ihrem inneren Zustand; sie werden mit Hilfe von Zustandsautomaten definiert und innerhalb eines Systems kann es mehrere Instanzen von einem solchen Objekt geben wie z.B. im Elevator Control System, wo jedem Elevator genau ein Elevator Control Objekt zugeordnet ist, das z.B. den Elevator Motor und die Elevator Door kontrolliert! Timer Objekte sind Objekte, die von externen Timern aktiviert werden und dann Aktioen selbst ausführen oder an anderen Objekte weiterleiten Application Logic Objekte werden unterteilt in: Business Logic Objets: kapseln geschäftspezifische Anwendungslogiken bzgl. Der Verarbeitung von Nutzeranfragen Algorithm Objets kapseln problemspezifische Algorithmen und werden z.B. in Echtwzitsystemen oder wissenschaftlichen Systemen verwendet Nachdem nun alle für das System relevanten Objekte mit Hifle der Objektstrukturierungskriterien identifiziert worden sind, soll nun die Kommunikation innerhalb und zwischen Objekten betrachtet werden, es soll also die Phase der dynamischen Modellierung vorgestellt werden. COMET-Basis von Rebekka Oeters WS 01/02

18 Endliche Zustandsautomaten
Ziel ist die Modellierung der zustands-abhängigen Aspekte eines Systems Ein Statechart beschreibt alle möglichen Zustände, die ein Objekt einnehmen kann Ein Statechart repräsentiert meist ein zustandsabhängiges Objekts innerhalb eines Systems Entwicklung von Statecharts mit Hilfe der in den Use Cases beschriebenen Interaktionsabfolgen Endliche Zustandsautomaten spielen besonders bei der Entwickung von Realzeitsystemen eine grosse Rolle, da sie zum einen zur Modellierung der zustandsabhängigen Aspekte des Systems eingesetzt werden können, also solchen Aspekten, die neben den Nutzereingaben auch vom Zustand des Systems abhängen zum anderen bieten sie die Möglichkeit, alle Zustände, die ein Objekt einnehmen kann, zu definieren und stellen deshalb ein mächtiges Modellierungselement innerhalb des Softwareentwicklungsprozesses dar Endliche Zustandsautomaten werden graphisch als Zustandsübergangsdiagramme oder -tabellen dargestellt; COMET verwendet die UML Notation von Zustandsübergangsdiagrammen, und zwar Statecharts Ein Statechart repräsentiert meist ein zustandsabhängiges Objekt innerhalb eines Systems, und zwar ein state dependent control Object es besteht jedoch die Möglichkeit, verschiedene in einem Statechart enthaltene Aspekte zur Komplexitätsreduzierung in mehrere Statecharts aufzuspalten Die Entwicklung von Statecharts, also die jeweilige Identifizierung aller Zustände und Zustandsübergänge, kann mit Hilfe der in den Use Cases beschriebenen Interaktionsabfolgen vorgenommen werden ... COMET-Basis von Rebekka Oeters WS 01/02

19 COMET-Basis von Rebekka Oeters WS 01/02
Statecharts Zustände und Events Events und Conditions: event[condition] Actions: event / action Entry Actions: entry / action Exit Actions: exit / action Activities: do activity Hierarchische Statecharts Orthogonale Statecharts Ein Statecharts besteht aus Zustände und Transitionen zwischen Zuständen Ein Zustand ist eine wiederkehrende Situation, in der sich das Statechart für eine bestimmte Zeit befindet Diese Transitionen werden durch Events ausgelöst Beispielhaft soll das zu dem Use Case Stop Elevator st Floor gehörige Statechart aus dem Elevator Control System vorgestellt werden und daran sollen dann auch alle noch wichtigen Begriffen bzgl. Statecharts erklärt werden COMET-Basis von Rebekka Oeters WS 01/02

20 Statechart für den Use Case Stop Elevator at Floor
Use Case beschreiben und dabei die Zustände des Statechrts durchgehen!!! => Der Use Case Stop Elevator At Floor hat den Anwendungsfall beschrieben, dass ein Elevator in Bewegung ist und ein Arrival Sensor bei Ankunft des Elevators das System benachrichtigt. Daraufhin prüft das System, ob es bei dieser Etage zu halten hat oder nicht. Wenn eine Anfrage bzgl. Der Etage besteht, teilt das System dem Motor mit, anzuhalten - wenn der Motor angehalten hat weist das System die Elevator Door an, sich zu öffnen. Wenn keine Anfrage vorliegt, fährt der Elevator in der vorigen Richting weiter. Ein Event ist ein atomares Geschen, das zu einem bestimmten Zeitpunkt auftritt und konzeptionell betrachtet die Dauer null hat; die Bezeichnungen der Events entspricht denen, die bei der Definition der Interaktionsdiagramme, die im folgenden vorgestellt werden, verwendet werden ein timer event wird durch das Schlüsselwort after gekennzeichnet und drückt aus, dass ein Ereignis nach einer angegebenen Zeit, dem timeout auftritt! => zeigen!! Event können um Constraints erweitert werden, so dass ein Zustandsübergang nur stattfindet, wenn die angegebene Bedingung erfüllt ist Aktionen sind Methoden, die bei einem Zustandsübergang ausgeführt werden; wenn mehrere Aktionen bei einem Zustandübergang ausgeführt werden, werden sie konzeptionell betrachtet alle simultan ausgeführt, so dass es keine Abhängigkeiten zwischen ihnen geben darf (Beispiel A9 ...!!!) Wenn genung Zeit => zurückblättern!!: entry actions: Aktionen, die bei Eintritt in einen Zustand ausgeführt werden exit actions: Aktionen, die bei Austritt aus einem Zustand ausgeführt werden activites: Methoden, die einem Zustand zugeordnet sind und solange ausgeführt werden, wie das Statechart in dem Zustand ist Dann weiter bei hierarchischen Statecharts: Die Einführung von Superzuständen und die hierarchische Dekomposition von Statecharts dient der Komplexitätsreduzierung und soll ermöglichen, komplexe Systeme übersichlicher und leichter lesbar zu gestalten Als Beispiel für ein hierarchische Statechart soll das des Elevator Control Systems gezeigt werden... COMET-Basis von Rebekka Oeters WS 01/02

21 Top-level Statechart für das Elevator Control System
Bis auf den Zustand Elevator Idle und Checkung Next Destination sind alle im vorher gezeigten Statechart enthaltenen Zustände in dem Superzustand Moving to Floor enthalten Hierarchische Statecharts können in flache Statecharts überführt werden, sie sind also semantisch äquivalent die hierarchische Dekomposition von Statecharts wird auch als ODER-Dekomposition bezeichnet und bedeutet, dass sich ein Objekt immer genau in einem Subzustand des Superzustandes befindet Neben der hierarchischen ODER-Dekompoistion kann auch eine UND-Dekomposition von Statecharts modelliert werden, die innerhalb der COMET Methode lediglich dazu dient, verschiedene Aspekte eines Objekts auszudrücken und deshalb nicht als paralle, sondern als orthogonale Dekomposition bezeichnet wird. COMET-Basis von Rebekka Oeters WS 01/02

22 Modellierung der Interobjektkommunikation
Ziel ist die Definition der Kommunikation zwischen Objekten Kollaborationsdiagramme versus Sequenzdiagramme Beide Diagramme stellen jeweils immer nur eine Interaktionsabfolge innerhalb des Systems dar Bezeichnung von Messages Ziel dieser Phase der Softwareentwicklung ist die Definition der Objektinterkationen Dabei werden Sequenz- und Kollaborationsdiagramme als zwei unterschiedliche Modelle zur Modellierung der Interkation zwischen Objekten vorgestellt Wichtig ist, anzumerken, dass mit Hilfe eines Sequenz- oder Kollaborationsdiagramms jeweils nur eine Interaktionsabfolge mit evlt. Vorhandenen alternativen Interaktionen modelliert werden kann, nicht jedoch alle innerhalb des Systems stattfindenden Objektinteraktionen aus diesem Grund sind Sequenz- und Kollaborationsdiagramme bzgl. Ihrer Ausdruckskraft nicht so möchtig wie Statecharts Bei der Modellierung der Interaktionsdiagramme werden die während der Anforderungsmodellierung defnierten Use Cases und mit Hifle der Objektstrukturierungskriterien identifizeirten Objekte betrachtet und deren Kommunikation definiert Wenn ein Use Case mehrere alternative Interaktionsabfolgen enthält, bietet es sich aus Gründen der Übersichtlichkeit an, mehrere Interaktionsdiagramme zu modellieren Wenn ein state dependent control object innerhalb eines use cases enthalten ist, müssen die entsprechenden Ereignisse zwischen Objekten sowohl innerhalb des Statecharts, als auch bei der Modellierung des Interaktionsdiagramms ausgedürckt werden in der Analysephase liegt der Schwerpunkt der COMET Methode auf der Definition der Informatinen und Nachrichten, die zwischen Objekten ausgetauscht werden und nicht auf der Beschreibung der durch die Nachrichten ausgelösten Operationen daher werden alle Nachrichten als einfache Nachrichten betrachtet, es wird an dieser Stelle keine Unterscheidung zwischen synchronen und asynchronen Nachrichten gemacht die Interaktion von Objekten wird mit Hilfe von Nummerierungen der Nachrichten in eine zeitliche Abfolge gebracht Bevor auf den Unterschied zwischen Kollaborations- und Sequentdiagrammen eingegangen wird, soll zuerst die Bezeichnung der Nachrichten erklärt werden COMET-Basis von Rebekka Oeters WS 01/02

23 Aufbau der Bezeichnung von Messages
A  Use Case ID Open Door  message name A9: Open Door 9  message sequence number (main sequence) A9a: Off Elevator Lamp a  concurrent message (parallel sequence to 9) A9a.1: Elevator Lamp Output Nachrichten sind ein Mechanismus, mit dem Objekte untereinander kommunizieren können; eine Nachricht führt zur Ausführung einer Operation beim entsprechenden Objekt ein Nachricht besteht aus einem Sequenzausdruck, einem Namen und einer optionalen Argumentliste ein Sequenzausdruck besteht immer aus einer Message Sequenznummer und optional aus einem Ausdruck, der eine bedingungsbezogene oder iterative Ausführung der Nachricht ausdrücken kann eine Message Sequenznummer kann bestehen aus: 1. Erster optionaler Zeichensequen: identifizeirung des dazugehörigen Use Cases 2. Message Sequenznummer: Reihenfolge der Nachrichten modellieren 3. Zweiter optionaler Zeichnsequenz: Kleinbuchstaben: parallele Ausführung Grossbuchstaben und Bedingung: alternative Interaktionsabfolgen Es soll nun beispielhaft das Kollaborationsdiagramm für den Use Case Stop Elevator at Floor des Elevator Control Systems vorgestellt werden ... .1  numeric sequence following 9a A9b: Arrived (Floor #) Floor #  argument list COMET-Basis von Rebekka Oeters WS 01/02

24 Kollaborationsdiagramm für den Use Case Stop Elevator at Floor
Einmal durchlaufen mit Zettel => ÜBEN!!! Bei der COMET Methode wird die Verwendung von Kollaborationsdiagrammen zur Modellierung von Objektinteraktionen geneüber Sequenzdiagrammen bevorzugt, da diese den Übergang zur Erstellung der Softwarearchitektur in der Entwurfphase durch explizite Darstellung, welche Objekte miteinander kommunizieren, erleichtern Sequnezdiagramme stellen die Interaktion zwischen Objekten in einer zeitlichen Sequenz dar Da erst in der Entwurfsphase entschieden wird, ob Objete aktive oder pasiv sind, werden die Lebenslinien der in einem Sequenzdiagramm enthaltenen Objekte gestrichelt dargestellt Ich habe versucht, das obige Kollaborationsdiagramm in ein Sequnzdiagramm zu überführen => er wurde schnell sehr unübersichtlich, so dass ich nur alle beteiligten Objekte dargestellt habe ... COMET-Basis von Rebekka Oeters WS 01/02

25 Sequenzdiagramm für den Use Case Stop Elevator at Floor
COMET-Basis von Rebekka Oeters WS 01/02

26 COMET-Basis von Rebekka Oeters WS 01/02
UML-RT UML Erweiterung zur Modellierung von verteilten, eingebetteten Echtzeitsystemen UML-RT wurde bei der Firma Rational Software von Bran Selic und Jim Rumbaugh entwickelt und geht in den UML 2.0 Standard ein Ziel ist die Defintion des genauen und vollständigen Kommunikationsablaufes zwischen Objekten mit der Möglichkeit, Klassen und Komponenten wiederzuverwenden Einführung von fünf Stereotypen: <<capsule>> <<connector>> <<port>> <<protocol>> <<protocol role>> UML-RT ist eine Erweiterung der UML für die Modellierung von verteilten, eingebetteten Echtzwitsystemen UML-RT wurde bei der Firma Rational Software von Bran Selic und Jim Rumbaugh entwicklet und geht in den UML 2.0 Standard ein Ziel ist die Definition des genauen und gesamten Kommunikationsablaufes zwischen Objekten und dadurch die Erlangung der Möglichkeit, Klassen und Komponenten wiederzuverwenden UML-RT führt folgende Stereotypen ein: ... Diese möchte ich nun jeweils erklären und gleichzeitig die graphische Notation vorstellen... BLÄTTERN!!! COMET-Basis von Rebekka Oeters WS 01/02

27 UML-RT: Modellierungselemente
Kapsel: Protokoll: Capsule (class): Kapseln stellen eine Menge von parallel arbeitenden, aktiven und ggf. verteilten Objekten dar eine Kapsel kann mehrere Schnittstellen, sogenannte Ports besitzen, it Hilfe derer sie mit ihrer Umgebung eine Kapsel kann aus einem Zustandsautomaten bestehn, mit Hifle dessen ihr Verhalten modelliert wird, oder aus mehreren Subkapseln, die ihr Verhalten chrakterisieren connector (associationClass): ein Konnektor ist ein Kommunikationsobjekt, das Messages zwischen Ports entsprechend dem Protokoll, das zu dem Konnektor gehört, überträgt man kann also sagen, dass ein Konnektor eine Kommunikationsverbindungist, die einen Kommunikationskanal zum Versenden von Informationen in Form von Siganeln darstellt, dabei beginnt und endet eine Kommunikationsverbindung an einem Port und verbindet Zustandautomaten von Kapseln miteinander port (class): ein Port stellt einen Interaktionspunkt zwischen mehreren Kapseln dar jede Kapsel besitzt mehrere Ports, die als Verankerungspunkt für Kommunikationsverbindungen dienen und die Kommunikation einer Kapsel mit anderen lediglich über diese Ports zulassen ein port ist entweder ein end port, der an dem Zustandsautomaten der dazugehörigen Kapsel hängt, oder ein relay port, der mit einem Port einer Subkapsel der dazugehörigen Kaspel verbunden ist und dazu dient, Signale von innen nach aussen oder umgekehrt weiterzuleiten einem Port ist jeweils genau eine Protokollrolle zugeordnet, die den Typ des Ports definier protocol(collaboration): ein Protokoll defniert die an einem Port mögliche Kommunikationsabfolge zwischen zwei oder mehreren Kaspeln bzgl der versendeten Signale mit ggf. genauen zeitlichen Angaben es beschreibt Protokollrollen, die die Kommunikationspartner während der Kommunikation einnehmen können in der Praxis werden meist nur binäre Protokolle, also Protokolle, die die Kommunikation zwischen zwei Kommunikationspartnern beschreiben, verwendet bei der Definition von binären Protokollen muss lediglich eine Protokollrolle, die sogenannte Base Role, mit den dazugehörigen Ein- und Ausgabesignalen definiert werden, die dazugehörige zweite Protokollrolle, die sogenannte conjugate Role, ergibt sich durch Vertauschung der ein- und Ausgabesignale protocol role (classifierRole): Protokollrollen ermöglichen die Definition der Ein- und Ausgabesignale und die Abfolge des Signalaustuasches mit Hilfe von Zustandsautomaten, die zwischen den Kommunikationspartnern ausgetauscht werden <<capsule>> ExampleCapsule fields methods ports <<protocol>> BinaryProtocol incoming Signal 1 Signal 2 outgoing Signal Ports: Conjugate Ports: Relay Port Relay Port End Port End Port COMET-Basis von Rebekka Oeters WS 01/02

28 UML-RT: Klassen- und Strukturdiagramm
TopLevel- Capsule Strukturdiagramm der TopLevelCapsule: aHello aWorld / aHello: Hello / aWorld: World Hello World Bei der Modellierung eines Systems mit UML-RT werden folgende Diagrammarten verwendet: Klassendiagramme und Kollaborationsdiagramme werden zur Modellierung der Struktur eines Systems verwendet: Klassendiagramme dienen zur Definition der Kapsel- und Protokollklassen samt deren Eigenschaften und Darstellung der Beziehungen zwischen diesen Kollaborationsdiagramme werden zur Definition der internen Struktur von Kapseln verwendet und daher auch als Strukturdiagramme bezeichnet Statecharts und Sequenzdiagramme werden zur Modelluerung des Verhaltens eines Systems verwendet BEISPIEL erklaren => selbst vorher Notizen auf Folie machen!!! helloPort timing log helloPort log <<port>> <<port>> helloPort helloPort Greetings hello COMET-Basis von Rebekka Oeters WS 01/02

29 COMET-Basis von Rebekka Oeters WS 01/02
Fazit Inkrementelle, Use Case basierte und iterative Softwarewareentwicklung ermöglicht flexible Reaktionen bei auftretenden Problemen oder sich ändernden Anforderungen Hoher Konsistenzanspruch bzgl. der Dokumente z.B. zwischen Use Cases, Statecharts und Kollaborationsdiagrammen UML-RT bietet im Gegensatz zu Kollaborations-diagrammen die Möglichkeit, Interaktionen zwischen Objekten genau und vollständig zu spezifizieren COMET-Basis von Rebekka Oeters WS 01/02

30 COMET-Basis von Rebekka Oeters WS 01/02
Literaturangaben ”Designing Concurrent, Distributed, And Real-Time Applications with UML”, Hassan Gomaa, 2000 Unified Modeling Language 2.0 Proposal version 0.63 (draft) ”Einsatz der Unified Modeling Language zur Entwicklung von Kfz-Steuerungssoftware”, Mark-Oliver P. Reiser, 2000 ”Mapping Architectural Concepts to UML-RT”, Shang-Wen Cheng und David Garlan, 2001 COMET-Basis von Rebekka Oeters WS 01/02