3 Folien/Seite

Transcription

3 Folien/Seite

4.
Softwarearchitektur und Softwareentwurf
4.3
Architektur von eingebetteten und
Echtzeitsystemen
.KVGTCVWT
5QOOGTXKNNG
$CN\GTV.'
,CNQVG
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Echtzeit-Systeme
• Echtzeit-System bzw. Realzeit-System (real time system):
– Korrektes Funktionieren für eine gegebene Eingabe definiert als:
» richtige Ausgabe und rechtzeitige Ausgabe
– Zeitbegrenzung in "echter" Zeit, d.h. nicht relativ zu systeminternen
Maßgrößen
• "harte" Echtzeitanforderungen:
– Funktion verfehlt bei Nichteinhalten der Zeitbedingung
(z.B. Flugzeugsteuerung, Ampelsteuerung)
• "weiche" Echtzeitanforderungen:
– Funktion verschlechtert bei Nichteinhalten der Zeitbedingung
(z.B. Telefonvermittlung, Videopumpe)
• "feste" Echtzeitanforderungen:
– Kombination aus weicher Echtzeitanforderung und harter Schranke
(z.B. Beatmungsmaschine)
Prof. Hußmann
Besonderheiten von Echtzeitsystemen
• Oft: Hardware- und Software-System oder embedded system
– Spezielle Peripheriegeräte, spezielle Hardwarearchitektur
• Reaktivität
– Bereitschaft zur Reaktion auf Ereignisse, die in nicht vorhersehbarer
Reihenfolge und zu nicht vorhersehbarer Zeit erfolgen
• Nebenläufigkeit (concurrency)
– Gleichzeitigkeit von Ereignissen der Umgebung
– Interne Nebenläufigkeit des Systems
• Verteilung (distribution)
– Manchmal durch die Anwendung unvermeidbar
(z.B. Telekommunikation)
– Hilfsmittel zur Erreichung von schneller Reaktion und hoher
Zuverlässigkeit (Redundanz)
• Dynamische Anpassung an die Umgebung
– z.B. Umbau einer rechnergesteuerten Produktionsanlage
Prof. Hußmann
Seite 1
Realzeitsystem: Grundsätzliche Architektur
Systemumgebung
Sensor 1
...
Sensor n
Effektor 1
...
Effektor n
Hardware-Interface
Anwendungs-Software
Echtzeit-Systemsoftware
• Oft sehr kleine ergänzbare "microkernel" (z.B. 8 kByte)
Beispiele: OS-9, Chorus, QNX, LynxOS, VxWorks
Prof. Hußmann
Softwareentwurf für Echtzeitsysteme und
eingebettete Systeme
• Weitgehend vorgegebene physikalische Sicht der Architektur
– Architekturdiskussion in der Analyse
• Berücksichtigung gegebener Architektur im Entwurf
– Hardwareschnittstellen
– Betriebssystemschnittstellen
– Kommunikation und Verteilung
• Modellierung verwendbar für praktische Realisierung
– Relativ kleine Differenz
Analysemodell-Entwurfsmodell-Implementierung
– Gute Werkzeugunterstützung
– Effektive Codegenerierung aus Modellen möglich
• Deshalb: Diskussion von weiteren (implementierungsnahen)
Modellierungssprachen
Prof. Hußmann
Entwicklungsmethoden für Echtzeitsysteme
• Aufbauend auf Strukturierter Analyse:
– Structured Analysis/Real Time (SA/RT) – "Industriestandard"
» Ward/Mellor 1985, Hatley/Pirbhai 1987
• Aufbauend auf Objektorientierter Analyse:
– Real-Time Object-Oriented Modeling (ROOM)
» Selic/Gullekson/Ward 1994
– UML for Real-Time Systems
» Selic/Rumbaugh 1998
• Aufbauend auf Programmablaufplänen (Kontrollflußdiagrammen):
– System Design Language (SDL)
» Standard in der Telekommunikation
» Derzeit in Integration mit objektorientierten Ansätzen (SDL-2000)
Prof. Hußmann
Seite 2
Beispiel: Alarmanlage
• Zu überwachen sind mehrere (im Beispiel 2) Räume
• Jeder Raum hat (im Beispiel):
1 Bewegungsmelder, 1 Türsensor, 1 Fenstersensor
• Die Anlage wird über eine Schalteinrichtung aktiviert und
deaktiviert.
• Nach Aktivierung gelten drei Minuten Vorlauf,
bevor die Anlage "scharf" geschaltet wird.
• Reaktionszeit für Alarm: 1/2 Minute
• Bei Alarm ist folgendes zu tun:
– Notruf absetzen (Sprachsynthese)
– Licht einschalten
– Sirene auslösen
Prof. Hußmann
SA/RT: Kontextdiagramm
Bewegungsmelder
Türsensor
Fenstersensor
Signal TS
Signal BM
Hauptschalter
Bedienfeld
Einstellungen
SirenenStg.
Signal FS
steuere
Alarmanlage
LichtStg
Sirene
Kontrollfluß
Datenfluß
NotrufStg.
Licht
Ansage
Notruf
Prof. Hußmann
SA/RT: Ebene 0
BM
angebundene
Kontrollspezifikation
TS
FS
FS
TS
Aktivierung
BM
BM TS
überwache
Raum 1
überwache
Raum 2
FS
Hauptschalter
Aktivierung
betreibe
Bedienfeld
überwache
Objekt
Anruf
Li
erz.
Ansage
rufe
Hilfe
Einstellungen
Einstellungen
Sir
Prof. Hußmann
Seite 3
SA/RT: Kontrollspezifikations - Automat
• Kontrollspezifikation:
– besteht aus Zustandsautomat und/oder Entscheidungstabelle
– wird an das Flußdiagramm durch Balkennotation angebunden
Aktivierung = ein
Initialisierung
Inaktiv
Aktiv
BM, TS, FS
Auslösen
Aktivierung = aus
Alarm
Prof. Hußmann
SA/RT: Kontrollspezifikations - Tabelle
Prozeß
Steuerüberw.
aktion
Raum 1
aus Automat
Initialisierung
Auslösen
überw.
Raum 2
Sir.
Licht
erz.
Ansage
rufe
Hilfe
1
2
0
0
0
0
0
0
4
3
1
2
• Im allgemeinen: Entscheidungstabelle
• Bedeutung: Prozeßaktivierungstabelle
• Einträge: Reihenfolge der Aktivierung
Prof. Hußmann
SA/RT: Zeitspezifikationen
Eingabesignal Ereignis
Hauptschalter
ein
BM, TS, FS
ein
Ausgabesignal Ereignis
Aktivierung
Anruf
ein
wählen
Zeitbedingung
180 sec
< 30 sec
• Weitere Zeitbedingungen (z.B. Frequenz einer Sensor-Abfrage)
im Data Dictionary (Requirements Dictionary)
Prof. Hußmann
Seite 4
SA/RT: Zusammenfassung
• Ausgereifte, aber komplexe Darstellungsformen
– Zusammenspiel verschiedener Diagramme
– Nicht einfach zu verstehen
• Methodische Unterstützung vorhanden
• Relativ geringe Unterschiede zwischen Analyse, Entwurf und
Implementierung
– Spezifikation = abstrakte Sicht auf Implementierung
– Simulation von Spezifikationen
• Konsistenzbedingungen sehr komplex
• Keine Daten- oder Verhaltenskapselung
• Schlechte Unterstützung für mehrfache Instanzen desselben
Verhaltens
Prof. Hußmann
Objektorientierte Realzeit-Modellierung
• Verfeinerte Zustandsmodellierung:
– Shlaer/Mellor 1992 ("Modelling the World in States")
• Einführung zusätzlicher Strukturelemente ("Aktoren")
– Selic/Gullekson/Ward 1994
(ROOM - Real-Time Object-Oriented Modelling)
• Realzeit-Modellierung mit "purem" UML
– Douglass (1998, 1999)
(Angelehnt am Werkzeug "Rhapsody" der Firma i-Logix)
• Von ROOM zu UML/ROOM:
– ROOM-Werkzeug: ObjecTime Ltd. (Kanada), B. Selic et al.
– 1998: "White Paper" von B. Selic (ObjecTime)/J. Rumbaugh (Rational)
– 1999: Fusion von ObjecTime und Rational
» ObjecTime-Werkzeug nun spezielle Version von Rose (Rose-RT)
• Entscheidung über "offizielle" Realzeit-Version von UML noch
offen.
Prof. Hußmann
Sprachelemente von ROOM/UML
• ROOM/UML gibt zusätzlich zu den UML-Sprachelementen
bewährte Architekturmuster für Echtzeitsysteme mit einer
einfachen Kurznotation vor.
• Kapsel (capsule):
(in ROOM: Aktor (actor))
– Komplexes, möglicherweise verteiltes physikalisches Objekt, das mit
seiner Umgebung über Signale kommuniziert.
• Port:
– Physikalischer Teil der Implementierung einer Kapsel, über den die
Kapsel mit der Außenwelt durch Austausch von Signalen
kommuniziert.
– Assoziiert mit dem Port ist ein Protokoll, das die über den Port
ausgetauschten Informationen beschreibt.
• Konnektor (connector):
(in ROOM: Bindung (binding))
– Abstrakte Sicht auf einen Kommunikationskanal, der zwei oder mehr
Ports verbindet.
– Partner-Ports eines Konnektors müssen aufeinander abgestimmte
Protokolle benutzen (komplementäre Protokoll-Rollen)
Prof. Hußmann
Seite 5
Metamodell für Kapseln
Kapsel
1..*
Protokoll- 2..*
Rolle
Port
Protokoll
*
Konnektor
• Alle aufgeführten Klassen sind Spezialfälle des UML-Konstrukts
"Klasse".
– Stereotypen <<capsule>>, <<port>>, <<protocol>>, <<protocolRole>>
• Für Port-, Protokoll- und Protokoll-Rolle-Klassen werden i.a. keine
individuellen Attribute spezifiziert
• Kapsel-Klassen enthalten private Attribute und Operationen.
• Protokolle definieren Signale (Operationen der Protokoll-Rollen)
zur Kommunikation zwischen Kapseln.
• Die meisten Protokolle kennen zwei Standard-Rollen
(z.B. master und slave genannt)
Prof. Hußmann
ROOM/UML-Notation für Kapsel-Klassen
<<capsule>>
Raumüberwachung
• Spezialisierung der UMLKlassennotation:
ports
+ s[0..5]: SensorStg~
+ c: RaumStg
• Abkürzung für unten dargestelltes
Klassendiagramm
– zusätzliches "compartment" (ports)
<<capsule>>
Raumüberwachung
0..5 s
<<port>>
RÜberwSensPort
1 c
<<port>>
RÜberwRStgPort
<<protocol role>>
slave
<<protocol role>>
master
<<protocol>>
SensorStg
<<protocol>>
RaumStg
Prof. Hußmann
Protokoll-Spezifikation in ROOM/UML
• Zwei-Partner-Protokolle:
<<protocol>>
SensorStg
– Master- und Slave-Rolle
"konjugiert", d.h. ableitbar
aus demGegenstück
– Kurznotation:
Protokollname (=Master)
Protokollname~ (=Slave)
incoming
status(): Integer
rücksetzen()
outgoing
auslösen()
• Mehr-Partner-Protokolle:
– selten
<<protocolRole>>
Master
incoming
status(): Integer
rücksetzen()
outgoing
auslösen()
<<protocolRole>>
Slave
incoming
auslösen()
outgoing
status(): Integer
rücksetzen()
Prof. Hußmann
Seite 6
Beispiel: Klassendiagramm in ROOM/UML
Alarmsystem
• Alle Kapsel-Klassen mit
Port-Information
• Alle Ports mit zugehörigem
Protokoll und jeweiliger
Rolle
Sensor
*
1
1..10
RaumÜberwachung
– Details später
• Assoziationen: "Kenntnis"
voneinander
*
1
Bedienung
1
– Auf Instanzenebene:
Konnektoren
1
1
Alarmsteuerung
1
1
1
1
1
Sirene
Licht
1
1 Nachrichtensynthese
1
Notruf
Prof. Hußmann
Spezifikation des Verhaltens einer Kapsel
• Zwei Möglichkeiten (je Port wählbar):
• Spezifikation durch Zustandsdiagramm
– end port
– Zur Kapsel assoziierte Zustandsmaschine behandelt alle Signale des
dem Port zugeordneten Protokolls
• Verfeinerung durch enthaltene Kapseln
– relay port
– Port dient nur zum Weiterreichen von Signalen an Unterkapseln
– Das Gesamtsystem kann als eine Kapsel verstanden werden
» Hierarchische Zerlegung des Gesamtsystems in Kapseln
– In ROOM/UML beschrieben durch Kollaboration von Instanzen innerer
Kapseln
» Spezialfall des UML-Kollaborationsdiagramms
Prof. Hußmann
Einfaches Zustandsdiagramm für Kapsel
<<protocol>>
SensorStg
<<capsule>>
Sensor
incoming
status(): Integer
rücksetzen()
outgoing
auslösen()
ports
+ a: SensorStg
• Zugeordnetes Zustandsdiagramm für Kapsel Sensor:
nicht
ausgelöst
ext.Signal / auslösen()
ausgelöst
stg.rücksetzen()
stg.status()/return=1
stg.status()/return=0
Prof. Hußmann
Seite 7
ROOM/UML Instanzendiagramm
(Strukturdiagramm)
TS1:
Sensor
a: SensorStg
R1:Raumüberwachung
s[k]: SensorStg~
ist Kurzform für:
<<capsule>>
<<capsule>>
TS1:
Sensor
R1: Raumüberwachung
<<connector>>
<<port>>
<<port>>
a:SensorPort
s[k]: RSensorPort
<<protocolRole>>
<<protocol>>
<<protocolRole>>
Master
SensorStg
Slave
Prof. Hußmann
Beispiel: Innere Kapseln
Alarmsystem
s: SensorStg~
0..5
R[k]:Raum-1..10
überwachung
c: RaumStg
BedienKdo
stg:Alarmsteuerung
SirStg
LiStg NotrStg
NachrStg
Prof. Hußmann
Beispiel: ROOM/UML-Instanzendiagramm
für Gesamtsystem
TS1:
Sensor
:SensorStg
FS1:
Sensor
BM1:
Sensor
:SensorStg
TS2:
Sensor
...
k:BedienKdo
:Bedienfeld
...
:Alarmsystem
FS2:
Sensor
BM2:
Sensor
...
n:NachrStg
...
:Nachrichtensynthese
nr:RufStg
s:GerStg
:Sirene
l:GerStg
:Licht
Prof. Hußmann
:TelefonAnlage
Seite 8
Sequenzdiagramme für Echtzeitsysteme
:Bedienfeld
:Alarmsystem
ein()
: Sensor
: Sirene
: Licht
: Telefonanlage
auslösen()
180 s
a
{30s£
b–a£ 60s}
b
(wird
aktiv)
auslösen()
erzeugeNotruf()
ein()
{c–b£ 60s}
c
ein()
Zeitbedingungen schon in Anforderungsbeschreibung und -Analyse!
Prof. Hußmann
Zustandsdiagramme in UML/ROOM
Beispiel: Zustandsdiagramm für Kapsel "Alarmsteuerung"
k.ein()
/ setTimer(t1, 180)
t1.timeOut()
/ forall i: r[i].start()
Aktiv.Vorlauf
Aktiv
forone i: r[i].alarm()
/ setTimer(t2, 30)
Inaktiv
k::aus()
/ s::aus()
k::aus()
Alarm
AlarmVorlauf
t2.timeOut()/
m=n.synthNotruf();
nr.call(polizei); nr.transmit(m);
s.ein(); l.ein()
Hinweis: Darstellung ist nur angelehnt an realen Aktionssprachen!
Prof. Hußmann
Aktionssprachen für Realzeitsysteme
• Eingebettet in UML als "Aktionen" von Zustandsdiagrammen
• Programmiersprache:
– Sequentielle Komposition
– Evtl. Schleifenkonstrukte
– Berechnungen
– Senden von Signalen über Ports
– Aufrufen von Systemdiensten (z.B. Timer = Stoppuhr)
» ROOM/UML: Interner Port "TimeServiceSAP"
• Ablauflogik und Fallunterscheidungen in Zustandsdiagramm
• Ereignisse:
– Eintreffen von Signalen auf Ports
– Systemereignisse (z.B. timeout)
• Simulierbar und compilierbar zu Programmcode
Prof. Hußmann
Seite 9
UML/ROOM: Zusammenfassung
• Ausgereifte, in UML eingebettete Darstellungsformen
– Vorgabe wichtiger, allerdings fixierter, Standard-Architekturelemente
– Abgrenzung zu Standard-UML etwas unklar
– Konkurrierender Ansatz basierend auf Rhapsody
• Sehr gute Werkzeug-Unterstützung vorhanden,
Dokumentation/Methodik leider unbefriedigend
• Fliessender Übergang zwischen Analyse, Entwurf und
Implementierung
– Spezifikation = abstrakte Sicht auf Implementierung
– Simulation von Spezifikationen
• Daten- und Verhaltenskapselung wird unterstützt
• Unterstützung für mehrfache Instanzen desselben Verhaltens
– Prinzipiell gegeben (besser als z.B. in SA/RT)
– Relativ kompliziert
(warum keine Konnektoren in Klassendiagrammen?)
Prof. Hußmann
4.
Softwarearchitektur und Softwareentwurf
4.4
Objektorientierter Systementwurf
Analyse
Entwurf
Grobentwurf
Implementierung
Test,
Integration
Wartung
Feinentwurf
.KVGTCVWT
5QOOGTXKNNG
$CN\GTV.'
,CNQVG
Prof. Hußmann
Objektorientierter Komponentenentwurf
• Ausgangspunkt:
– Grobdefinition der Architektur:
» Zerlegung in Subsysteme
» Verteilungskonzept
» Ablaufmodell
• Ergebnis:
–
–
–
–
OO-Modell für jedes Subsystem der Architektur
OO-Modell für unterstützende Subsysteme
Spezifikationen der Klassen
Spezifikationen von externen Schnittstellen
Prof. Hußmann
Seite 10
Verfeinerung des Analysemodells
•
•
•
•
Entwurfsmodell ist detaillierter als Analysemodell
Listen der Attribute und Operationen: vollständig
Attribute und Operationen: Datentypen, Sichtbarkeit
Operationen: Spezifikation
– z.B. Vor- und Nachbedingungen
• Assoziationen/Aggregationen: Optimierung der Navigation
– Navigationsrichtung, Ordnung, Qualifikation
• Einbindung in Infrastruktur, Altsysteme etc.
• Verwaltungsklassen
• Zusammenhang zu den Anforderungen:
– Schlüsselszenarien als detaillierte Sequenzdiagramme
Prof. Hußmann
Beispiel: Analysemodell
Session
Owner
Party
IsVirtual
Number
0..1
Session
joins
2..*
Connection
Owner
0..*
Connection
0..*
0..*
Status
is connected by
0..*
Leg
Status
Direction
0..*
Auszug aus einem realen Projekt im Bereich der Telekommunikation
(Session-Management)
Prof. Hußmann
Beispiel: Entwurfsmodell (Überblick)
Line Access COBI
Call Service
Calling Party
CCF
Database
Communication
Object for Dialled
Connections
Third Party Call
Manager
TDP-Manager
give_TDP_N_List
give_TDP_R
Detection Point
DP_Number
Monitor_Mode
3
DP-Manager
armEDP
SCP_Request
SCP_Notification
SCP_Response_Info
Drop_SSF
EDP
TDP
SCP_ID
Service_Key
SSM Object
ID
Read_ID
SSM Leg
SSM Connection
*Notification
0..2 *End_Of_Call
GetDPManager
ArmStatusChange
*Notification
*Request
*EndOfCall
*Exception
*Release
ArmStatusChange
Report_SSM
SSM Party
0..2
Is_Virtual
Address
SSM Session
Bearer
independent
Connection
Release
User initiated
Bearer
Connection
Release
Complete
Continue
Protocol stack
TCAP Component
Handler
TCAP Transaction
Handler
Third Party initiated
Bearer Connection
Release
Establish
SCF Access Manager
Send_Invoke
Send_Error
TC_CONTINUE
TC_END
TC_U_ABORT
TC_P_ABORT
SendSTUI
Add_Bearer
Add_Parties_And_Bearer
Join_Party_And_Bearer
Join_Party_And_Link_Leg
Drop_Party
Release_Connection
Release_Session
Request_Report_SSM_Change
Continue
Error
SSFTimerExpiry
SSMTimerExpiry
ServiceRequest
Report_SSM_Change
Connection_Released
Notation: OMT
Prof. Hußmann
Seite 11
Teilaufgaben beim Objektorientierten Entwurf
• Verfeinerung des Analysemodells
– OOD umfaßt mehr Detailinformation als OOA
• Vervollständigung der Architektur
–
–
–
–
Anbindung an Benutzungsoberfläche
Anbindung an Datenhaltung
Anpassung an gewählte Verteilung
Ablaufsteuerung
Entwurfsmuster
• Optimierung des Entwurfs
• Anpassung an Implementierungssprache
Prof. Hußmann
Seite 12

3 Folien/Seite

Transcription

Similar documents

Lebenslauf

Softwarearchitektur verteilter Systeme