TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik Vertiefte Grundlagen 2. Vorlesung Repräsentation von Systemen (IDEF0) Nürnberger.

Präsentation zum Thema: "TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik Vertiefte Grundlagen 2. Vorlesung Repräsentation von Systemen (IDEF0) Nürnberger."—  Präsentation transkript:

1 TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik Vertiefte Grundlagen 2. Vorlesung Repräsentation von Systemen (IDEF0) Nürnberger Str. 31a 2. OG, Raum 204 TU Dresden - Institut für Bauinformatik Prof. Dr.-Ing. R. J. Scherer

2 TU Dresden - Institut für Bauinformatik Folie-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

3 TU Dresden - Institut für Bauinformatik Folie-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.

4 TU Dresden - Institut für Bauinformatik Folie-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

5 TU Dresden - Institut für Bauinformatik Folie-Nr.: 5 Input Reale Objekte oder Daten, die zur Ausführung der Funktion notwendig sind. Benannt mit einem Substantiv Funktions- Name Input

6 TU Dresden - Institut für Bauinformatik Folie-Nr.: 6 Output Funktions- Name Output Objekte oder Daten die das Resultat der Funktion nach Transformation des Inputs sind Benannt mit einem Substantiv

7 TU Dresden - Institut für Bauinformatik Folie-Nr.: 7 Steuerung Bedingungen, die zur Produktion eines korrekten Outputs erforderlich sind Benannt mit einem Substantiv Funktions- Name Steuerung

8 TU Dresden - Institut für Bauinformatik Folie-Nr.: 8 Mechanismus Mechanismus (Person, Gerät, oder Daten) der die Funktion ausführt Benannt mit einem Substantiv Funktions- Name Mechanismus

9 TU Dresden - Institut für Bauinformatik Folie-Nr.: 9 Die beiden Primären Modellkomponenten sind Funktionen und Daten/Objekte, die mit diesen Funktionen in Wechselwirkung stehen Funktions- Name InputOutput 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

10 TU Dresden - Institut für Bauinformatik Folie-Nr.: 10 Dekomposition in Sub-Systeme A0 A-0 Eltern Diagram Kind Diagramm Allgemein Detailliert 0 Dieses Rechteck ist Elter dieses Kinddiagramms 1 2 3 4 A4 Top-Level Kontext Diagramm Subsysteme können geschachtelt oder sequenziell sein Elterndiagramme repräsentieren einen höheren Abstraktionsgrad als Kinddiagramme

11 TU Dresden - Institut für Bauinformatik Folie-Nr.: 11 Dekomposition in Sub-Systeme A4 1 2 3 A43 1 2 3 Diese Nummerierung zeigt, dass die Funktion detailliert wurde Ein Diagramm enthält maximal 6 und mindestens 3 Funktionen

12 TU Dresden - Institut für Bauinformatik Folie-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

13 TU Dresden - Institut für Bauinformatik Folie-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. ( )

14 TU Dresden - Institut für Bauinformatik Folie-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

15 TU Dresden - Institut für Bauinformatik Folie-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

16 TU Dresden - Institut für Bauinformatik Folie-Nr.: 16 Output Output kann Steuerung werden Output kann Input werden A A

17 TU Dresden - Institut für Bauinformatik Folie-Nr.: 17 Bündelung und Gabelung Gabelung des Pfeils A resultiert in Pfeilen B und C C B A A B C 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.

18 TU Dresden - Institut für Bauinformatik Folie-Nr.: 18 Beispiel: Wasserversorgungssystem versorgen mit Wasser gespeichertes Wasser 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.

19 TU Dresden - Institut für Bauinformatik Folie-Nr.: 19 Definition von Zielen und Zwischenzielen DruckdatenFließdatenVerbrauchsdatenVersorgungsdaten RauhigkeitVerlust Kosten aus erhöhter Pumpleistung + Verlust Einnahmen Bewertung der Rentabilität Bericht Aktueller Zustand Ziel Zwischen- ziele

20 TU Dresden - Institut für Bauinformatik Folie-Nr.: 20 Beispiel: Überwachung eines Wasserversorgungssystems überwache Lebenszyklus Betriebsdaten Anforderungen an Qualität und Quantität Betreiber Kosten aufgrund erhö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

21 TU Dresden - Institut für Bauinformatik Folie-Nr.: 21 Der ganze Prozess ist zeitabhängig, d.h. er muß regelmäßig aktualisiert werden. Beispiel: Überwachung eines Wasserversorgungssystems

22 TU Dresden - Institut für Bauinformatik Folie-Nr.: 22 Systemverhalten Systemverhalten = 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 Q 1 h Loss,1 v 1 p 1 Q 2 h Loss,2 v 2 p 2 Zustands- variablen Rauhigkeit Erhalt der totalen Energie Zustands- variablen

23 TU Dresden - Institut für Bauinformatik Folie-Nr.: 23 Elementverhalten eines Grundelements NN EL HGL Annahme: stationärer Fluss, reibungsfreie und inkompressible Flüssigkeit ELT 12 p = hydrostat. Druckρ = Dichte des Wassers v = Fließgeschwindigkeitg = Erdbeschleunigung z = Höhe Rohrh Loss = Druckverlust = Reibungskoeffizient L = Rohrlänge d h = hydraulischer Durchm. L k = relative Rauhigkeit der Rohrwand Re = Reynolds Zahl Erhalt der totalen Energie μ = dynamische oder absolute Viskosität

24 TU Dresden - Institut für Bauinformatik Folie-Nr.: 24 Beispiel: Wasserversorgungssystem

25 TU Dresden - Institut für Bauinformatik Folie-Nr.: 25 Beispiel: Wasserversorgungssystem

26 TU Dresden - Institut für Bauinformatik Folie-Nr.: 26 Beispiel: Wasserversorgungssystem

27 TU Dresden - Institut für Bauinformatik Folie-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 geeignet für die Kommunikation zwischen Auftraggeber und Entwickler. Eine weitere Möglichkeit auf diesem Level bietet z. B. UML durch die sog. USE CASE (Anwendungs-) Diagramme und Szenarien.

28 TU Dresden - Institut für Bauinformatik Folie-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! Vereinfachung Umkehrung Unmöglich

29 TU Dresden - Institut für Bauinformatik Folie-Nr.: 29 Literatur Draft Federal Information Processing Standards Publication 183: "INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)", 1993 http://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.