Fakultät BauingenieurwesenInstitut für Bauinformatik , Prof. Dr.-Ing. Scherer
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer1
WP4-33: Systementwicklung7.Semester
Vorlesung 3: Aktivitätendiagramm
Prof. Dr. Raimar J. Scherer
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer2
Allgemeines BIM-basiertes Kooperationsszenario
coordinationpoint j
design session
designer 1,:Architektur
HKL, alternative 1
HKL, alternative 2
designer 2: Statiker
persistentcommondata model j
temporaryinfo
coordination
check-incheck-out
localconsolidateddesign
persistentcommondata model i
coordinationpoint i
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer3
Verallgemeinertes Kooperationsdiagramm-Aktivitätendiagramm
ArchitekturGebäudeentwurf
KostenberechnungMengenermittlung
z.B. ARRIBA
z.B. NemetschekAllplan
StatikTragwerksplanung
z.B. Sofistik
TGAHKLS-Planung
z.B. DDS-CAD
1) Welche Aktivitäten sind (für Informationsaustausch) erforderlich?
2) Welche Informationen werden benötigt und wie sind sie miteinander verknüpft?
3) Wie ist der Informationsfluss (Kommunikation)?
4) Wer/Was bearbeitet welche Informationen (Planungsumgebung)?
5) (Sonstige) Randbedingungen aus Planungsumgebung und Fachdomäne
Systemanalyse anhand
Aktivitätendiagramm
?
?
?
1. Schritt der Datenmodellerstellung ist ein Aktivitätendiagram (ISO10303-STEP
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer4
Eine allgemeine Methode zur Systembeschreibung ist IDEF0
o Representation des (integrierten) Systems aus Funktions-orientierter Sichto Eine Funktion ist definiert durch:
o Eingabeo Ausgabeo Steuerungo Mittel (Methode, Akteur etc.)
o IDEF0 – Integrated Definition for Function Modelingo IDEF0 = Modellierungssprache assoziierte Regeln und Techniken zur
Entwicklung strukturierter grafischer Representationen eines Systems oder Unternehmens
o IDEF0 wurde im Rahmen des Integrated Computer-Aided Manufacturing (ICAM) Programms der US-Luftwaffe entwickelt und basiert auf der ICAM-Architektur
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer5
Geschichte von IDEF0
Während der 1970er suchte das U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM) nach Möglichkeiten um die Produktivität der Produktion durch systematische Anwendung der Computertechnologie zu verbessern.
Als Resultat entwickelte das ICAM Programm eine Serie von Techniken, die als IDEF (ICAM Definition) Techniken bekannt sind, und die folgendes beinhalten:: IDEF0, zur Entwicklung eines “Funktionsmodells”. Ein Funktionsmodell ist eine
strukturierte Repräsentation von Funktionen, Aktivitäten oder Prozessen des modellierten Systems oder Fachgebiets.
IDEF1, zur Entwicklung eines “Informationsmodells”. Ein Informationsmodell repräsentiert die Struktur und die Semantik von Information des modellierten Systems oder Fachgebiets.
IDEF2, zur Entwicklung eines “Dynamischen Modells”. Ein dynamisches Modell repräsentiert die zeitabhängigen Verhaltens-Charakteristika des modellierten Systems oder Fachgebiets.
1983, erweiterte das U.S. Air Force Integrated Information Support System Programm die IDEF1 Informationsmodellierungstechnik weiter zur IDEF1X (IDEF1 Extended), einer semantischen Datenmodellierungstechnik.
IDEF0 und IDEF1X werden weitgehend durch Regierung, Industrie und Geschäftssektoren genutzt um die Modellierungsansträngungen in einem breiten Bereich von Geschäfts- und Anwendungsfeldern zu unterstützen.
Unterstützender Text
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer6
Anwendung von IDEF0
o Für neue Systeme kann IDEF0 zur Verbesserung der Entwurfsarbeit
verwendet werden, erstens für die Definition von Anforderungen und
Spezifikation der Funktionen und dann zum Entwurf einer
Implementierung, die die Anforderungen erfüllt und die Funktionen
ausführt.
o 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.
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer7
Funktion
o Eine Aktivität, Prozess oder Transformation wird in IDEF0 als Rechteck modelliert
o Beschrieben durch ein Verb, das den Inhalt der Aktivität beschreibt
Funktions-Name
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer8
Input
o Reale Objekte oder Daten die zur Ausführung der Funktion notwendig sindo Bezeichnet durch ein Substantiv
Funktions-NameInput
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer9
o Objekte oder Daten, die das Resultat der Funktion nach Transformation des Inputs sind
o Bezeichnet durch ein Substantiv
Output
Funktions-Name Output
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer10
Steuerung
o Bedingungen, die zur Produktion eines korrekten Outputs erforderlich sind
o Bezeichnet durch Substantiv
Funktions-Name
Steuerung
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer11
Mechanismus
o Mechanismus (Person, Gerät oder Daten), der die Funktion ausführt
o Bezeichnet durch ein Substantiv
Funktions-Name
Mechanismus
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer12
Erweiterte Systembeschreibung (IDEF0)
Die zwei grundlegenden Modell-Komponenten sind Funktionen und Daten/Objekte, die mit diesen Funktionen in Wechselwirkung stehen
Funktions-Name
Input Ouput
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.
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer13
Dekomposition in Sub-Systeme
A0
A0
A-0
Eltern Diagram
Kind Diagramm
Allgemein
Detailliert
0
Dieses Rechteck ist Elter dieses Kinddiagramms
12
34
A4
Top-Level Kontext
Diagramm
Subsysteme können geschachtelt oder sequenziell sein
Elterndiagramme repräsentieren einen
höheren Abstraktionsgrad als
Kinddiagramme
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer14
Top-Level Kontext Diagramm
o Jedes Modell soll ein Top-Level Kontext-Diagramm haben, auf dem der Sinn des Modells durch eine einzige Funktion und seine Begrenzenden Inputs, Outputs, Steuerungen und Mechanismen repräsentiert wird. Dieses Kontext-Diagramm erhält die Nummer A-0. Die Pfeile auf diesem Diagramm führen zu nicht mit abgebildeten Funktionen ausserhalb des Modellierungsgebiets. Sie definieren den Modellfokus. Da das ganze Modell hier durch ein einziges Rechteck repräsentiert wird, ist der beschreibende Name in diesem Rechteck sehr allgemein. Das selbe gilt für die Schnittstellenpfeile, da diese ebenfalls die gesamte Menge an externen Schnittstellen zum modellierten Gegenstand repräsentieren. Das A-0 Diagramm definiert außerdem den Anwendungsbereich bzw. die Anwendungsgrenzen und die Ausrichtung.
o Das A-0 Kontext-Diagramm soll auch kurze Erläuterungen bezüglich der Sichtweise und des Zwecks des Modells geben, die helfen sollen die Erstellung und die Begrenzung des Modells zu unterstützen.
o Die wichtigsten Aspekte werden in der ersten Hierarchieebene modelliert und werden in Subfunktionen aufgeteilt bis alle relevanten Details adäquat ausgedrückt sind.
o Jede Subfunktion wird individuell durch ein Rechteck repräsentiert, wobei ein Elternrechteck durch Kinddiagramme auf dem nächst niedrigeren Ebene detailliert wird. Alle Kinddiagramme müssen im Geltungsbereich des Kontext-Diagramms der übergeordneten Ebene liegen.
Unterstützender Text
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer15
Kind-Diagramm
o Die einzige Funktion des Kontext-Diagramms der übergeordeten Ebene kann durch Erstellung von Kind-Diagrammen in Sub-Funktionen zerlegt werden.
o Jede dieser Sub-Funktionen kann wiederum in Kind-Diagrammen zerlegt werden.o Aus einem gegebenen Diagramm können einige, keine oder alle Funktionen
zerlegt werden. o Jedes Kinddiagramm enthält Kindfunktionen und Pfeile, die zusätzliche Details zur
Verfügung stellen.o Das Kinddiagramm, das aus der Zerlegung einer Funktion stammt umfasst den
selben Modellbereich wie die Elternfunktion. Daher kann das Kinddiagramm als “Inhalt” der Elternfunktion betrachtet werden.
Unterstützender Text
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer16
Eltern-Diagramm
o Ein Eltern-Diagramm enthält eine oder mehrere Eltern-Funktionen. o Jedes normale (nicht-kontext) Diagramm ist auch ein Kind-Diagramm, da es per
Definition eine Elternfunktion detailliert.o Damit kann ein Diagramm sowohl ein Eltern-Diagramm als auch ein Kind-
Diagramm sein. o Desgleichen kann eine Funktion sowohl eine Eltern-Funktion als auch eine Kind-
Funktion sein.o Die primäre hierarchische Beziehung besteht zwischen der Eltern-Funktion und
der Kind-Funktion, die die Eltern-Funktion detailliert.
Unterstützender Text
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer17
Dekomposition in Sub-Systeme
A4
12
3A43
A43
12
3
Diese Nummerierung zeigt, dass die Funktion
detailliert wurde
Ein Diagramm enthält maximal 6 und mindestens
3 Funktionen
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer18
Geklammerte Pfeile
o 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
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer19
Geklammerte Pfeile
o 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.
( )
( )
( )
( )
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer20
Nummerierung von Funktionen
o Jede Funktion soll in der rechten unteren Ecke innerhalb des Rechtecks nummeriert werden.
o Dieses Nummerierungssystem ist erforderlich, um die eindeutige Identifikation der Funktionen innerhalb des Diagramms sowie Verweise darauf zu ermöglichen.
o Sie werden auch zur Referenzierung auf die Funktionen aus textuellen Beschreibungen der Diagramme benutzt.
o Die Funktionsnummer für die alleinstehende Funktion auf dem A-0 Kontextdiagramm hat die Nummer 0 (null).
o Die Nummern für die Funktionen in allen anderen Diagrammen sollen 1,2,3 bis max. 6 sein.
0
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer21
Verweis-Nummern
o 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.
o 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.
0A0
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer22
Output
o Output kann Steuerung werden
o Output kann Input werden
A
A
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer23
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.
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer24
Beispiel: Top-Level-Diagramm Bauwesen (allg.)
Vorsicht:Ist kein IDF0
Sondern ein Prozessmodell
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer25
Kooperationsszenario
GebäudeplanungKooperations-
szenario
A1
Planer,Fachplaner
Bauherr
Planungs-vorleistungen
Planungs-ergebnis
A0 Prozess Gebäudeplanung
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer26
Kooperationsszenario
A1 Kooperationsszenario
Architektur-planung
A11
A12
Statik-planung
TGA-Planung
A13
Architekt
Bauherr
Statiker
TGA-Planer
Bauherr
A14
Kosten-planung
Kosten-planer
A15
Planungs-koordination
Bauherr
Bauherr
Projekt-leiter
Bauherr
Architektur-entwurf
TragwerksentwurfTGA-Entwurf
Kosten
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer27
Kooperationsszenario
A1 Kooperationsszenario
Architektur-planung
A11
A12
Statik-planung
TGA-Planung
A13
Architekt
Bauherr
Statiker
TGA-Planer
Bauherr
A14
Kosten-planung
Kosten-planer
A15
Planungs-koordination
Bauherr
Bauherr
Projekt-leiter
Bauherr
Architektur-entwurf
TragwerksentwurfTGA-Entwurf
Kosten
Änderungsanforderungen an Architektur
Änderungsanforderungen an Statik
Änderungsanforderungen an TGA
Änderungsanforderungen an Kosten
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer28
Last-ermittlung
Kooperationsszenario - Statik
Ermitteln und Zusammen-
stellen der TW-Elemente
A121
A123
Tragwerks-Entwurf
A122
CAD-Zeichnungen
Text-dokumente/
Skizzen
CAD-System
A12 Statik-Planung
Protokolle
Bauherr
Baugrund
DIN 1055Nutzung
Tab-Kalkulation
Tragwerks-bemessung
A125
DIN/EC
CAD-System
Baugrund
CAD-Zeichnungen
Lage
StatischeBerechnung
Tragwerks-Modellierung u.
-BerechnungA124
Berechnungs-sofware
Text-dokumente/
Skizzen Schnittgrößen/Verformungen
Änderungsanforderungen an Entwurf
Belastung
Tragwerksmodell
Tragwerkselemente
Berechnungsmodell
Last-/Schnittgrößenmodell
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer29
Last-ermittlung
Kooperationsszenario - Statik
Ermitteln und Zusammen-
stellen der TW-Elemente
A121
A123
Tragwerks-Entwurf
A122
CAD-Zeichnungen
Text-dokumente/
Skizzen
CAD-System
A12 Statik-Planung
Protokolle
Bauherr
Baugrund
DIN 1055Nutzung
Tab-Kalkulation
Tragwerks-bemessung
A125
DIN/EC
CAD-System
Baugrund
CAD-Zeichnungen
Lage
StatischeBerechnung
Tragwerks-Modellierung u.
-BerechnungA124
Berechnungs-sofware
Text-dokumente/
Skizzen Schnittgrößen/Verformungen
Änderungsanforderungen an Entwurf
Belastung
Tragwerksentwurf
Tragwerksanalyse
Architekturentwurf
Tragwerksentwurf
Tragwerkselemente
Berechnungsmodell
Tragwerksmodell
Last-/Schnittgrößenmodell
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer30
Last-ermittlung
Kooperationsszenario - Statik
Ermitteln und Zusammen-
stellen der TW-Elemente
A121
A123
Tragwerks-Entwurf
A122
CAD-Zeichnungen
Text-dokumente/
Skizzen
CAD-System
A12 Statik-Planung
Protokolle
Bauherr
Baugrund
DIN 1055Nutzung
Tab-Kalkulation
Tragwerks-bemessung
A125
DIN/EC
CAD-System
Baugrund
CAD-Zeichnungen
Lage
StatischeBerechnung
Tragwerks-Modellierung u.
-BerechnungA124
Berechnungs-sofware
Text-dokumente/
Skizzen Schnittgrößen/Verformungen
Änderungsanforderungen an Entwurf
Belastung
Tragwerksmodell
Tragwerkselemente
Berechnungsmodell
Last-/Schnittgrößenmodell
Architekturmodell Tragwerks-modell
Berechnungsmodell (z.B. FE-Struktur)
Last-/Schnittgrößen-modell
Bemessungs-modell
Produktdatenmodell – IFC ?
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer31
Beispiel: Planungsphasen nach HOAIAufgestellt von Prof Menzel Uni College Cork
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer32
Beispiel: Planungsphasen nach HOAI
TechnischeUniversitätDresden
Institut für Bauinformatik, Prof. Dr.-Ing. Scherer33
Beispiel: Planungsphasen nach HOAI