Referat COMET-Basis von Rebekka Oeters im Rahmen des Seminars Entwicklung eingebetteter und verteilter Systeme WS 01/02

Referat „COMET-Basis“

von Rebekka Oeters

im Rahmen des Seminars

„Entwicklung eingebetteter und verteilter Systeme“ WS 01/02

COMET-Basis von Rebekka Oeters WS 01/02

2

Gliederung• Überblick über die

Softwareentwicklungsmethode COMET• Use Case Modellierung• Statische Modellierung• Klassen- und Objektstrukturierung• Modellierung von endlichen

Zustandsautomaten• Modellierung der Interobjektkommunikation• UML-RT• Fazit


3

Ü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


4

COMET – Objektorientiertes Softwarelebenszyklusmodel


5

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


6

Elevator Control System

E

3

1

2ElevatorButtons

321E

ElevatorLamps

Elevator Door

Direction Lamps

Floor Buttons

Motor

Arrival Sensor

Floor Lamps


7

Use Cases und Akteure des Elevator Control Systems


8

Akteure und Use Case Beziehungen

• Primäre versus sekundäre Akteure

• Use Case Beziehungen:– <<extend>>– <<include>>


9

Use Case Model des Elevator Control Systems


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


11

Klassendiagramm für das Elevator Control System


12

Systemkontextdiagramm für das Elevator Control System


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


14

Klassifikation von Anwendungsklassen mit Hilfe von Stereotypen

<<application>>

<<interface>> <<entity>> <<control>> <<application logic>>

<<user interface>> <<device interface>>

<<system interface>>

<<input / output device interface>>

<<state dependent control>>

<<input device interface>>

<<timer>>

<<output device interface>>

<<coordinator>>

<<business logic>> <<algorithm>>


15

Klassifikation von externen Klassen mit Hilfe von Stereotypen

<<external>>

<<external user>><<external system>><<external device>><<external timer>>

<<external input / output device>><<external output device>><<external input device>>


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


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


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


19

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


20

Statechart für den Use Case Stop Elevator at Floor


21

Top-level Statechart für das Elevator Control System


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


23

A9: Open Door

Aufbau der Bezeichnung von Messages

A9a: Off Elevator Lamp

A9a.1: Elevator Lamp Output

A9b: Arrived (Floor #)

A Use Case ID

9 message sequence number (main sequence)

Open Door message name

Floor # argument list

a concurrent message (parallel sequence to 9)

.1 numeric sequence following 9a


24

Kollaborationsdiagramm für den Use Case Stop Elevator at Floor


25

Sequenzdiagramm für den Use Case Stop Elevator at Floor


26

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>>


27

UML-RT: Modellierungselemente

<<capsule>> ExampleCapsule

fields

methods

ports

<<protocol>> BinaryProtocol

incomingSignal 1Signal 2

outgoingSignal

Kapsel: Protokoll:

Ports: Conjugate Ports:

End Port End Port

Relay Port Relay Port


28

UML-RT: Klassen- und StrukturdiagrammTopLevel-Capsule

World

helloPortlog

Hello

helloPorttiminglog

Greetings

hello

helloPort

aWorldaHello

helloPort

<<port>><<port>>

/ aHello: Hello / aWorld: World

Strukturdiagramm der TopLevelCapsule:


29

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


30

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

Documents

Referat COMET-Basis von Rebekka Oeters im Rahmen des Seminars Entwicklung eingebetteter und verteilter Systeme WS 01/02