Referat COMET-Basis von Rebekka Oeters im Rahmen des Seminars Entwicklung eingebetteter und...
-
Upload
anselma-rehn -
Category
Documents
-
view
109 -
download
5
Transcript of Referat COMET-Basis von Rebekka Oeters im Rahmen des Seminars Entwicklung eingebetteter und...
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
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
4
COMET – Objektorientiertes Softwarelebenszyklusmodel
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
6
Elevator Control System
E
3
1
2ElevatorButtons
321E
ElevatorLamps
Elevator Door
Direction Lamps
Floor Buttons
Motor
Arrival Sensor
Floor Lamps
COMET-Basis von Rebekka Oeters WS 01/02
7
Use Cases und Akteure des Elevator Control Systems
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>>
COMET-Basis von Rebekka Oeters WS 01/02
9
Use Case Model des Elevator Control Systems
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
COMET-Basis von Rebekka Oeters WS 01/02
11
Klassendiagramm für das Elevator Control System
COMET-Basis von Rebekka Oeters WS 01/02
12
Systemkontextdiagramm für das Elevator Control System
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
COMET-Basis von Rebekka Oeters WS 01/02
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>>
COMET-Basis von Rebekka Oeters WS 01/02
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>>
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
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
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
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
20
Statechart für den Use Case Stop Elevator at Floor
COMET-Basis von Rebekka Oeters WS 01/02
21
Top-level Statechart für das Elevator Control System
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
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
24
Kollaborationsdiagramm für den Use Case Stop Elevator at Floor
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
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>>
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
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:
COMET-Basis von Rebekka Oeters WS 01/02
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
COMET-Basis von Rebekka Oeters WS 01/02
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