TU Dresden - Institut für BauinformatikFolie-Nr.: 1
WP3-13 Bauinformatik Vertiefte Grundlagen
2. Vorlesung
Repräsentation von Systemen (IDEF0)
Nürnberger Str. 31a2. OG, Raum 204
TU Dresden - Institut für Bauinformatik
Prof. Dr.-Ing. R. J. Scherer
TU Dresden - Institut für BauinformatikFolie-Nr.: 2
Repräsentation von Systemen (IDEF0)• Input(1) und Output (2) ist nicht ausreichend für eine zufriedenstellende
Repräsentation von Systemen. Es werden zusätzlich gebraucht:
• (3) Steuerung(4) Mechanismus (= Methoden, Akteure)
Die Grafische Modellierungssprache IDEF0• IDEF0 = funktionale Beschreibung des Systems
• IDEF0 = Modellierungssprache assoziierte Regeln und Techniken zur Entwicklung strukturierter grafischer Repräsentationen eines Systems oder einer Firma
• IDEF0 = Integration Definition Function Modelling, Level 0
• IDEF0 = basiert auf der (US) Air Force Wright Aeronautical Laboratories Integrated Computer-Aided Manufacturing (ICAM) Architecture
TU Dresden - Institut für BauinformatikFolie-Nr.: 3
Anwendung von IDEF0
• Für neue Systeme kann IDEF0 zur Verbesserung der Entwurfs-arbeit verwendet werden, erstens für die Definition von Anforde-rungen und Spezifikation der Funktionen und dann zum Entwurf einer Implementierung, die die Anforderungen erfüllt und die Funktionen ausführt.
• Für bestehende Systeme kann IDEF0 zur Analyse der System-funktionen, des Systemverhaltens und der Mechanismen, die zu ihrer Ausführung führen, verwendet werden.
TU Dresden - Institut für BauinformatikFolie-Nr.: 4
Funktion
• Eine Aktivität, Prozess oder Transformation (modelliert durch ein IDEF0 Rechteck)
• beschrieben durch ein Verb, das den Inhalt der Aktivität beschreibt.
Funktions-Name
TU Dresden - Institut für BauinformatikFolie-Nr.: 5
Input
• Reale Objekte oder Daten, die zur Ausführung der Funktion notwendig sind.
• Benannt mit einem Substantiv
Funktions-Name
Input
TU Dresden - Institut für BauinformatikFolie-Nr.: 6
Output
Funktions-Name
Output
• Objekte oder Daten die das Resultat der Funktion nach Transformation des Inputs sind
• Benannt mit einem Substantiv
TU Dresden - Institut für BauinformatikFolie-Nr.: 7
Steuerung
• Bedingungen, die zur Produktion eines korrekten
Outputs erforderlich sind
• Benannt mit einem Substantiv
Funktions-Name
Steuerung
TU Dresden - Institut für BauinformatikFolie-Nr.: 8
Mechanismus
• Mechanismus (Person, Gerät, oder Daten) der die Funktion ausführt
• Benannt mit einem Substantiv
Funktions-Name
Mechanismus
TU Dresden - Institut für BauinformatikFolie-Nr.: 9
Die beiden Primären Modellkomponenten sind Funktionen und Daten/Objekte, die mit diesen Funktionen in Wechselwirkung stehen
Funktions-Name
Input Output
Steuerung
Mechanismus
Rechtecke repräsentieren Funktionen die angeben was erreicht werden soll. Der Funktionsname ist ein Verb
Pfeile repräsentieren Daten oder Objekte, die von der Funktionen benötigt oder durch sie produziert werden. Jeder Pfeil wird durch ein Substantiv benannt.
Repräsentation von Systemen mit IDEF0
TU Dresden - Institut für BauinformatikFolie-Nr.: 10
Dekomposition in Sub-Systeme
A0
A0
A-0
Eltern Diagram
Kind Diagramm
Allgemein
Detailliert
0
Dieses Rechteck ist Elter dieses Kinddiagramms
1
2
3
4A4
Top-Level Kontext Diagramm
Subsysteme können geschachtelt oder sequenziell sein
Elterndiagramme repräsentieren einen
höheren Abstraktionsgrad als Kinddiagramme
TU Dresden - Institut für BauinformatikFolie-Nr.: 11
Dekomposition in Sub-Systeme
A4
1
2
3A43
A43
1
2
3
Diese Nummerierung zeigt, dass die Funktion detailliert wurde
Ein Diagramm enthält maximal 6 und mindestens 3 Funktionen
TU Dresden - Institut für BauinformatikFolie-Nr.: 12
Geklammerte Pfeile
• Die Klammerung eines Pfeils am Rechteck bedeutet, dass die Daten oder Objekte, die durch diese Pfeile ausgedrückt werden nicht notwendig für das Verständnis nachfolgender Dekompositionsebenen sind und daher nicht im Kinddiagramm enthalten sind.
(
)
(
)
( )
( )
I1
M1
C1
O1
TU Dresden - Institut für BauinformatikFolie-Nr.: 13
Geklammerte Pfeile
• Die Klammerung am ungebundenen Ende bedeutet, dass die Daten oder Objekte am nächst höheren (Eltern) Dekompositionsgrad nicht notwendig sind und daher nicht mit der Eltern-Funktion verbunden sind.
(
)
(
)
( )
( )
TU Dresden - Institut für BauinformatikFolie-Nr.: 14
Nummerierung von Funktionen
• Jede Funktion soll in der rechten unteren Ecke innerhalb des Rechtecks nummeriert werden.
• Dieses Nummerierungssystem ist erforderlich, um die eindeutige Identifikation der Funktionen innerhalb des Diagramms sowie Verweise darauf zu ermöglichen.
• Sie werden auch zur Referenzierung auf die Funktionen aus textuellen Beschreibungen der Diagramme benutzt.
• Die Funktionsnummer für die alleinstehende Funktion auf dem A-0 Kontextdiagramm hat die Nummer 0 (null).
• Die Nummern für die Funktionen in allen anderen Diagrammen sollen 1,2,3 bis max. 6 sein.
0
TU Dresden - Institut für BauinformatikFolie-Nr.: 15
Verweis-Nummern
• Eine Verweisnummer steht an der rechten unteren Ecke außerhalb des Rechtecks. Sie kennzeichnet die Funktion als Eltern-Funktion und ist gleichzeitig die Diagrammnummer des Kind-Diagramms.
• Die Verweisnummer wird angeführt von der Diagrammnummer des Elterndia-gramms gefolgt von der Nummer der Elternfunktion, die detailliert werden soll.z.B.: die Verweisnummer der Funktion 2 im Diagramm A25 ist A252.
2
A252
TU Dresden - Institut für BauinformatikFolie-Nr.: 16
Output
• Output kann Steuerung werden
• Output kann Input werden
A
A
TU Dresden - Institut für BauinformatikFolie-Nr.: 17
Bündelung und Gabelung
Gabelung des Pfeils A resultiert in Pfeilen B und C
C
B
A
A
BC
Bündelung der Pfeile B und C zu Pfeil A
Die Kombination von Pfeilen (Bündelung) zu einem Pfeil oder die Separation eines Pfeils in mehrere Pfeile (Gabelung) wird durch die Pfeilvereinigungs- bzw. Pfeil-verzweigungssyntax ausgedrückt.
TU Dresden - Institut für BauinformatikFolie-Nr.: 18
Beispiel: Wasserversorgungssystem
versorgen mit Wasser
gespeichertesWasser
Wasserbedarf des Abnehmers
Topographie, etc.
Versorger
Rechtecke repräsentieren Funktionen, die angeben was erreicht werden soll. Der Funktionsname ist ein Verb.
Pfeile repräsentieren Daten oder Objekte, die von der Funktionen benötigt oder durch sie produziert werden. Jeder Pfeil wird durch ein Substantiv benannt.
TU Dresden - Institut für BauinformatikFolie-Nr.: 19
Definition von Zielen und Zwischenzielen
Druckdaten Fließdaten VerbrauchsdatenVersorgungsdaten
Rauhigkeit Verlust
Kosten aus erhöhter Pumpleistung + Verlust Einnahmen
Bewertung der Rentabilität
Bericht Aktueller Zustand
Ziel
Zwischen-ziele
TU Dresden - Institut für BauinformatikFolie-Nr.: 20
Beispiel: Überwachung eines Wasserversorgungssystems
überwache Lebenszyklus
Betriebsdaten
Anforderungen anQualität und Quantität
Betreiber
Kosten aufgrunderhöhter Pumpleistung und Wasserverlust
Top-Level Kontext Diagramm
0
A-0 Überwachung des Wasserversorgungssystems
ZWECK: Überwachung und Info-verarbeitung zur Wartung des Wasserversorgungssystems
SICHT: Wartungsteam und Entscheidungsträger
Planungsdaten
A0
TU Dresden - Institut für BauinformatikFolie-Nr.: 21
Der ganze Prozess ist zeitabhängig, d.h. er muß regelmäßig aktualisiert werden.
TITEL:KNOTEN: NR.:A0 Soll-Ist-Vergleich
4
vergleiche
3
summiere zu Gesamtkosten
Ct
5
bewerte Rentabilität
Ct/CPr
Prognose der künftigen
Entwicklung
Betriebswirt
Betriebswirt
Bauing.
Planungsdaten
1
A1
berechne Pumpkosten
2
A2
berechne Verlustkosten
Betriebsdaten
Bauing.
Bauing.
Beispiel: Überwachung eines Wasserversorgungssystems
TU Dresden - Institut für BauinformatikFolie-Nr.: 22
SystemverhaltenSystemverhalten = Aggregation des Verhaltens aller Grund-Subsysteme
Jedes Basis-Subsystem ist ein isoliertes System
1. Gesetz der Thermodynamik gilt
Erhaltung der totalen Energie
"Element Leitung"transportiere
Wasser
Q1
hLoss,1
v1
p1
Q2
hLoss,2
v2
p2
Zustands-
variablen
Rauhigkeit
Erhalt der totalen Energie
Zustands-
variablen
TU Dresden - Institut für BauinformatikFolie-Nr.: 23
Elementverhalten eines Grundelements
konst)h,v,p,,z(fh LossELT
2...1,Lossh
2z
NN
EL
HGL
Annahme: stationärer Fluss, reibungsfreie und inkompressible Flüssigkeit
ELT
g2
v22
g
p2
1,Lossh
g2
v21
g
p1
1z
1 2
p = hydrostat. Druck ρ = Dichte des Wassers v = Fließgeschwindigkeit g = Erdbeschleunigungz = Höhe Rohr hLoss = Druckverlust
)v,d,L,(fh 1ii,Loss
= ReibungskoeffizientL = Rohrlängedh = hydraulischer Durchm.
L
)d,k(Re,f hk = relative Rauhigkeit der RohrwandRe = Reynolds Zahl
vAQ
Erhalt der totalen Energie
),,v,d(fRe μ = dynamische oder absolute Viskosität
TU Dresden - Institut für BauinformatikFolie-Nr.: 24
Beispiel: Wasserversorgungssystem
2
berechne notwendigen
Einspeisedruck
3
berechne Pumpkostenpmin,input
Alle QVerbrauch
Bauing.
Bauing.
Cp
TITEL:KNOTEN: NR.:A1 Berechnung der Pumpkosten
Alle pmin,Verbrauch
TU Dresden - Institut für BauinformatikFolie-Nr.: 25
TITEL:KNOTEN: NR.:A2 Berechnung der Verlustkosten
1
A21
berechne Verlust
2
berechne Verlustkosten
DV
Bauing.
Bauing. Cw
Betriebsdaten
Beispiel: Wasserversorgungssystem
TU Dresden - Institut für BauinformatikFolie-Nr.: 26
TITEL:KNOTEN: NR.:A21 Berechnung Wasserverlust
1
summiere
2
berechne Differenz
Entnahme aus Wasserspeicher
Verbrauch proAbnehmer
SVerbrauch
Verlust
Beispiel: Wasserversorgungssystem
TU Dresden - Institut für BauinformatikFolie-Nr.: 27
Nachteile von IDEF0
Bei der Anwendung von IDEF0 sollte man sich folgender Nachteile bewusst sein:• Komplexität der Diagramme• Unterscheidung und Trennung unterschiedlicher Sichten• Schwierige Identifikation und Unterscheidung zwischen Steuerung und Inputs• Unzureichende Semantik zur Repräsentation der Verzweigungen der Abläufe• Ungenaue Spezifikation der Daten (nur textuelle Beschreibung)
IDEF0 ist eine Top-Level Beschreibung eines Systems, besonders geeignetfür die Kommunikation zwischen Auftraggeber und Entwickler.
Eine weitere Möglichkeit auf diesem Level bietet z. B. UML durch diesog. USE CASE (Anwendungs-) Diagramme und Szenarien.
TU Dresden - Institut für BauinformatikFolie-Nr.: 28
Modellierungsansätze• Ein Modell ist eine vereinfachte
Abbildung der Realität• Ein Modell wird zur Repräsentation
einer Menge von Komponenten eines Systems oder einer Domäne genutzt.
• Die Abbildung ist beschränkt auf die Ojekte, die für die Untersuchung relevant sind
• Um das Modell handhabbar zu machen, müssen Modellverein-fachungen eingeführt werden
• Vereinfachungen sind irreversibel für eine Detaillierung ist ein neues Modell und eine neue Berechnung erforderlich!
Ver
ein
fach
un
g
Umkehrung Unmöglich
TU Dresden - Institut für BauinformatikFolie-Nr.: 29
Literatur
Draft Federal Information Processing Standards Publication 183: "INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)", 1993http://www.idef.com/pdf/idef0.pdf
Object Management Group: „OMG Unified Modeling Language Specification“, Framingham, MA,1998. http://www.omg.org
W.W. Royse:„Managing the development of large software systems“ in: „Tutorial: Software Engineering project management“, IEEE Computer Socienty, Washington DC, pp. 118 – 127, 1970.
Top Related