Simulation komplexer technischer Anlagen Teil II: Elemente zum Bau virtueller Anlagenkomponenten Kapitel 4: Objektorientierte Analyse mit der Unified Modelling Language Inhalt Teil I Objektorientierte Analyse mit der Unified Modelling Language Teil II Beispiel: Wärmebedarf eines Wohngebäudes Anhang UML Quick Reference Ergänzung: Praktikum -Analyse und Entwurf mit Rational Rose am Beispiel Wärmebedarf eines Wohngebäudes

Beispiel: Berechnung des Wärmebedarfs eines Gebäudes Problemanalyse Die Wärmeschutzverordnung verlangt den Nachweis, dass bei neu zu erstellenden Gebäu-den die Energieverbräuche bestimmte Grenzen nicht überschreiten. Der Energieverbrauch wird über Jahresbilanzen bestimmt. Der Norm-Wärmebedarf setzt sich aus dem Transmissionswärmebedarf und dem Lüftungswärmebedarf zusammen. Für unsere Beispiel betrachten wir zunächst die Wärmeverluste durch Transmission. Der Transmissionswärmebedarf eines Gebäudes ist die Summe der Wärmeströme, die seine Räume durch Wärmeleitung an die Umgebung abgeben. Der Wärmestrom eines Raumes ist proportional zur Temperaturdifferenz zur Umgebung und zur Oberfläche des Raumes (bzw. der Flächen der Wände, Fenster, Türen, des Bodens und der Decke). Ein Wärmedurchgangskoeffizient beschreibt die Wärmedämmeigenschaften der einzelnen Elemente. Es gibt eine Vielzahl von Möglichkeiten, diese Vorgänge zu modellieren. Die folgenden Folien zeigen Beispiele.

Beispielproblem: Wärmebedarf eines Wohngebäudes Solare Wärmegewinne Lüftungs- verluste Transmissions- verluste Interne Wärmegewinne Wärmebedarf Ta Ti

Beispielgebäude EFH - Isometrie

Beispielgebäude EFH - Datenblatt

Physikalisches Modell Zonenweise stationäre Energiebilanz bei vorgegebener Sollinnentemperatur

Mathematisches Modell Transmissionsverluste: Lüftungsverluste: Interne Wärmegewinne: Solare Wärmegewinne bleiben unberücksichtigt Mittlere interne Wärmegewinne auf der Basis eines durchschnittlichen 2,7-Personenhaushaltes pro Tag und Wohnraumfläche

Anforderungen an das Berechnungsprogramm - Pflichenheft - Berechnung des Verlaufs des Wärmebedarfs über ein Jahr auf der Basis einer täglichen stationären Energiebilanz bei einer konstanten Soll-Innentemperatur. Berücksichtigt werden sollen dabei Transmission, Lüftung und interne Wärmegewinne. Soll-Innentemperatur, Lüftungsrate und Nutzungsgrad sowie Gebäudegeometrie- und Materialkonstanten sollen variabel sein. Für jeden Zeitschritt soll der tägliche Wärmebedarf, sowie dessen Anteile an Transmission, Lüftung und interner Wärmegewinne berechnet und in ein Datenfile ausgegeben werden. Für den gesamten Berechnungszeitraum sollen die Summenwerte auf dem Bildschirm ausgegeben werden. Weitere Anforderungen gemäß dem Gebäudedatenblatt

Modellelemente der UML Aktuelle Fassung: http://www.oose.de/uml Glossar http://www.oose.de/glossar Klassen zur Beschreibung der Objekte Beziehungen zum Bau von Systemen Diagramme zur Beschreibung verschiedener Sichten auf ein System Alle Elemente können rekursiv eingesetzt werden: Aus Klassen werden Pakete und Komponenten

Beispiel für ein Use Case-Diagramm Die Anwendung Gebäudeberechnung enthält Berechnungen nach EN 832 und VDI 2067. Sie wurde um eine Berechnung der GT-Anlage erweitert.

Elemente eines Klassendiagramms Vererbung: Klasse A erbt von der Klasse B Klasse Abhängigkeit: Klasse A hängt von der Klasse B ab - Änderung in B erfordert Änderung in A Assoziation: Klassen A und B stehen in einer Beziehung zu einander Instanzen sind Objektverbindungen, die durch die Assoziation beschrieben werden Aggregation: Klasse A beinhaltet die Klasse B B ist Teil von A

Finden von Klassen CRC - (Class - Responsibility - Collaboration) Methode Hauptwortmethode: Hauptwörter ergeben Klassen. Aber Achtung: Hauptwörter, die eher Werte haben (Länge, Breite, etc.), sind meist Attribute evtl. viel zu viele Klassen evtl. wichtige Klassen vergessen Formularanalysen (Altsysteme) Standardbegriffe wie Kunde, Adresse, Vertrag, etc. Rollen als Klassen (Geschäfts-)Prozesse (Abläufe im Modell) als Klassen Technische Systeme: verwende Technische Objekte

Methoden zum Finden von Objekten und Klassen Es gibt kein einheitliches Vorgehensmodell für die Modellierung mit Objekten. Die Auswahl einer Modellierungsmethode ist eine projektspezifische Entscheidung und kann - abhängig von der Problemstellung - sehr unterschiedlich ausfallen. Für Ingenieurprobleme hat sich eine Top-down Analyse analog der strukturierten Analyse bewährt. Sie beginnt in der Regel mit einer Use Case-Modellierung (analog Kontext Diagramm). Booch, Rumbaugh Jacobson Use-Case-Modellierung Zustandsmodellierung Booch, Rumbaugh CRC-Cards Klassen-/Objekt- modellierung Interaktionsmodellierung Booch, Rumbaugh Subsystemmodellierung Moduldiagramme Prozessdiagramm Booch Shlaer, Mellor Booch

Beziehungen zwischen Klassen - das statische Modell Die Funktion eines Systems wird durch die Zusammenarbeit vieler Objekte er-bracht. Auf der Beschreibungsebene - statisches Modell - wird die Zusammen-arbeit über die Beziehungen zwischen Klassen beschrieben. Folgende Konstrukte haben sich als nützlich erwiesen: Objekte müssen modifiziert werden - dies geschieht über Vererbung. Objekte müssen Methoden anderer Klassen verwenden können - dies geschieht über Assoziationen. Ist die Verbindung nur unter Einschränkungen möglich, so müssen ihr eigene Attribute zugeordnet werden - dies geschieht über Abhängigkeiten. Objekte müssen zur Bildung komplexerer Objekte einsetzbar sein - dies geschieht über Aggregationen.

Analyseergebnis (1) Klassen zur Beschreibung des Systems Gebäude werden durch beheizte thermische Zonen modelliert.Diese spezialisieren thermische Zonen.Thermische Zonen werden über ihre Nutzung definiert und mittels Begrenzungsflächen beschrieben. Äußere Begrenzungsflächen sind Außenflächen oder Decke und Boden und spezialisieren Begrenzungsflächen. Sie haben eine Beziehung zur Umwelt

Analyseergebnis (2) Beziehungen zwischen Klassen Vererbung Abhängigkeit Assoziation Aggregation

Entwurfs-/Analyseergebnis (3) Zuordnung von Methoden public - für alle sichtbar und benutzbar protected - für Klasse, Unterklassen und friends s + b private - für Klasse und friends s + b

Analyseergebnis (4) Zuordnung von Attributen

Objektorientierte Systeme Eines der Ziele, die mit der Einführung des objektorientierten Paradigmas verbunden ist, ist die inter-disziplinäre Erstellung großer Systeme. Deswegen sind weitere Konstrukte zur Reduktion der Komple-xität nötig. Man greift dabei auf die klassischen Konstrukte des Softwareengineerings zurück wie etwa Ÿ Bildung von Schichten z.B. Dialogschicht - Anwender Modellierungsschicht - Fachspezialist Fachklassenschicht - Anwendungsprogrammierer Kommunikations/Datenbank-Schicht - Systemspezialist Ÿ Bildung von Subsystemen oder Packages, in denen verwandte Klassen zusammengefasst werden. Ÿ Bildung von Modulen oder Komponenten, in denen der Programmcode der einer Komponente zugeordneten Klassen steht. In C++ benötigt jedes System ein Hauptprogramm (Funktion main). Von ihm aus wird das System aktiviert, jedoch nicht mehr wie in konventionellen Programmen der Systemablauf gesteuert. Zusätzlich wird es erlaubt, dass gleichlautende Nachrichten für Objekte unterschiedlicher Klassen ein unterschied- liches Verhalten bewirken (Polymorphismus). Durch die Technik des dynamischen Bindens wird es möglich, einer Nachricht erst beim Empfang, d.h. zur Programmlaufzeit, eine konkrete Operation zuzuordnen.

Analyseergebnis (5) Bildung von Packages

Entwurf und Implementierung erfordern Modifikationen

RenArch Domain, a model for the simulation thermal performance of residential buildings based on En832 . Use m_pUse 1 m_pEnvironment Enclosure Use adjacent to 1 Environment ThermalZone 1 1 1 1 InternalEnclosure ExternalEnclosure 1 0.* adjacent to HeatedThermalZone UnheatedThermalZone 1 m_pHeatedThermalZone AdjacentWall ExternalWall Floor 1 HeatedThermalZone 1 enumOrientation m_enumOrientation 1 1 Building _ENUMOrientation

Erweiterung des Gebäudemodelles um Stockwerke und Räume

Beziehungen zwischen Objekten - das dynamische Modell Klassen beschreiben Modelle, Objekte repräsentieren konkrete Modellzustände. Da Model-le nur eine beschränkte Gültigkeit haben, unterliegen die Objekte einer Klasse bestimmten Regeln und es sind durch das Modell nur ausgewählte Zustände beschreibbar. Das dyna-mische Modell versucht, diese Zusammenhänge zu formalisieren. Folgende Konstrukte haben sich als nützlich erwiesen: Abgrenzung des Anwendungsszenarios im Anwendungsfalldiagramm (Use Case) Beschreibung der Zustände und ihrer Übergänge im Zustandsdiagramm Beschreibung der Nachrichten und ihrer Auswirkung im Kollaborationsdiagramm Beschreibung des zeitlichen Ablaufs des Nachrichtentausches im Sequenzdiagramm. Die Beschreibungselemente der UML sind für technische Systeme weniger geeignet, da sie häufig als kontinuierliche Systeme beschrieben werden. Es empfiehlt sich, hier als Ergän-zung etwa Methoden der strukturierten Analyse zu verwenden.

Sequenzdiagramm Darstellung von dynamischen Abläufen Kommunikation zwischen Objekten Wenn (viele) Botschaften zwischen wenigen Objekten ausgetauscht werden

Sequenzdiagramm- Beispiel Experiment Raum_1 : Wand_1 : Wand_2 : Fenster_1 : Umwelt : Raum Wand Wand Fenster Umwelt BerechneTemperatur( ) BerechneTemperatur() BerechneTemperatur( ) GetTemperatur( ) BerechneWärmedurchgang( )

Kollaborations-Diagramm Dieselbe Information wie im Sequenz-Diagramm Darstellung von dynamischen Abläufen Kommunikation zwischen Objekten Wenn wenige Botschaften zwischen vielen Objekten ausgetauscht werden evtl. später auch für Debugging von Programmen

Kollaborations-Diagramm - Beispiel Experiment 1: BerechneTemperatur( ) Raum_1 : 2: BerechneTemperatur( ) Raum Wand_1 : 5: BerechneWärmedurchgang( ) Wand Fenster_1 : Fenster 4: GetTemperatur( ) Umwelt : Umwelt Wand_2 : Wand

UML Quick Reference (1)

UML Quick Reference (2)

UML Quick Reference (3)

UML Quick Reference (4)

UML Quick Reference (5)

Diese Fragen sollten Sie jetzt beantworten können Was ist die UML und was nicht Wie beschreibt die UML Klassen Wichtige Beziehungen zwischen Klassen Was ist ein Use Case Was ist ein Klassendiagramm Wie beschreibt man eine Komponente Wie liest man ein UML Diagramm Zu was sind Case Tools nötig