1 / 21

Geoinformation III

Geoinformation III. Vorlesung 6a. Software-Technik: (fortgeschrittene) Klassendiagramme. 1. "Software-Technik". "Anwendung von Methoden, Prinzipien und Techniken auf den Entwurf und die Implementierung von Programmen und Programmsystemen" engl.: "Software Engineering"

marlee
Download Presentation

Geoinformation III

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Geoinformation III Vorlesung 6a Software-Technik: (fortgeschrittene) Klassendiagramme

  2. 1 "Software-Technik" • "Anwendung von Methoden, Prinzipien und Techniken auf den Entwurf und die Implementierung von Programmen und Programmsystemen" • engl.: "Software Engineering" • Zielgruppe: Programmentwickler, Projektleiter • Schwerpunkt: Objektorientierte Methoden (Werkzeug: UML - Unified Modeling Language) • Anwendungsbeispiele: angelehnt an ALKIS (Amtliches Liegenschaftskataster-Informationssystem)

  3. 2 Überblick über Vorlesung (6 Termine) • UML - (fortgeschrittene) statische Diagramme (Klassendiagramme) • UML - dynamische Diagramme • Software-Demo: CASE-Tool "Together" • Korrektheit: Testen von Programmen • Normen und Standards in GIS (2 Termine)

  4. 3 UML Klassendiagramme – Wh. aus GIS I • Klassen mit Attributen und Methoden • Assoziationen mit Multiplizitäten • Aggregation und Komposition • Generalisierung

  5. 4 UML Klassendiagramme – neue Konzepte • Abstrakte Klassen • Abgeleitete Attribute und Assoziationen • Zusicherungen (Object Constraint Language) • Invarianten • Vor- und Nachbedingungen

  6. A 5 UML - Klassendiagramm (Wh.) DieKlasseListe Klassenname Liste - erstesElement: Element Attribute - letztesElement: Element + FügeEin(Objekt) Methoden + Lösche(Objekt) + Suche(Objekt): boolean Zugriff auf Klasse nur über Methoden (Geheimnisprinzip)FAbstrakter Datentyp + Länge():integer + ....... 6x

  7. jedes Grundstück hat mindestens drei Kanten jede Kante begrenzt genau zwei Grundstücke Multiplizität Name A 6 Beziehungen in UML (Wh.) 7x

  8. 7 Mögliche Multiplizitäten ( Wh.) 1 genau eins 0..1 null oder eins 0..4 zwischen null und vier 3,7 drei oder sieben 0..* größer oder gleich null (Standard) * dto. 1..* größer oder gleich eins 0..3, 7, 9..*

  9. Aggregation: eine spezielle Assoziation, deren beteiligte Klassen eine Ganzes-Teile-Hierarchie darstellen Komposition:eine strenge Form der Aggregation, bei der die Teile vom Ganzen existenzabhängig sind 8 Aggregation und Komposition (Wh.) Ganzes Ganzes 1 n Teil Teil

  10. 9 Generalisierung und Spezialisierung (Wh.) • Die „GeomFigur“ ist ein allgemeineres Konzept als „Dreieck,“ „Kreis“ oder „Rechteck“ • GeomFigur ist Oberklasse,Dreieck, Kreis und Rechteck sind Unterklassen • Unterklassen erben die Attribute der Oberklasse und fügen ggf. weitere hinzu GeomFigur Dreieck Kreis Rechteck

  11. A 10 Und was ist mit Methoden? (Wh.) GeomFigur Methoden werden vererbt oder überschrieben -Mittelpunkt : Punkt -sichtbar : Boolean +anzeigen() +entfernen() +verschieben() Kreis Rechteck Dreieck -radius : Zahl -a : Zahl -a : Zahl -b : Zahl anzeigen() -b : Zahl entfernen() -c : Zahl anzeigen() entfernen() +anzeigen() +entfernen() 4x

  12. 2. Alternative 1. Alternative Quadrat Rechteck a: double a: double b: double Rechteck Quadrat b: double {a = b} A 11 Generalisierung: Probleme • eine Seitenlänge zuviel • F Redundanz • Gefahr: Inkonsistenzen (z.B. a=2, b=5) • Fehlerhafte Modellierung • z.B. Anzahl der Quadrate umfasst Rechtecke • Rechteck ist kein Quadrat 3x

  13. A 12 1. Rekursive Aggregation (Beispiel ALKIS) abstrakte Klasse: es werden keine Instanzen erzeugt (nur Instanzen der Unterklassen) Raumbezogenes Objekt abstract 1 .. * 1 Raumbezogenes zusammengesetztes Objekt Raumbezogenes Elementarobjekt Raumbezogenes Elementarobjekt: REO Zusammengesetztes Objekt: ZUSO 1x

  14. ZUSO REO 13 Klassendiagramm: Instanzendiagramm: Raum- bezogenes Objekt abstract 1 .. * NRW Reg. Bez. D‘dorf Reg. Bez. Köln 0..1 Kreis Euskirchen Kreis Rhein - Sieg Raum- bezogenes zusammen- gesetztes Objekt Raum- bezogenes Elementar- objekt Flurst. 12 Flurst. 1 Flurst. 21 Flurst. 444

  15. /besteht aus Gemeinde /Flächeninhalt Flächeninhalt wird aus Polygon ermittelt A 14 2. Abgeleitete Attribute und Assoziationen Abgeleitetes Attribut:Ermittlung aus Flächeninhalten der Teile Staat /Flächeninhalt Abgeleitete Assoziation/Aggregation:Ermittlung aus beiden Aggregationen besteht aus Abgeleitetes Attribut:Ermittlung aus Flächeninhalten der Teile Bundesland /Flächeninhalt Notiz besteht aus Abgeleitetes Attribut: Ermittlung aus Polygon Repräsentation Polygon 7x

  16. 15 Abgeleitete Attribute und Assoziationen • Syntax: / vor Namen des Attributs bzw. der Assoziation • Zwei Möglichkeiten der Umsetzung • Ableitung bei jedem Zugriff • Informatik-Begriff: "Virtuelle Sicht" • Konsistenz gewährleistet • Effizienzprobleme • Ableitung und Speicherung • Informatik-Begriff: "Materialisierte Sicht" • Konsistenz? • UML macht keine Aussage, ob a) oder b) verwendet wird

  17. {subset} {or} A 16 3. Einschränkungen Hauptstadt muss im Staat liegen Entweder Punkt oder Polygon, nicht beides zugleich („exklusives oder“) liegt in 1..* Staat Stadt Hauptstadt von Raumbezug2 Raumbezug1 Liste statt Menge {ordered} Polygon Stützpunkt Punkt 3..* 6x

  18. 17 Zwischenresümé: Korrektheit • Zweck der bisher vorgestellten Konzepte (Multiplizitäten, abgeleiteten Attribute/Assoziationen, Einschränkungen): Zustände, die in der realen Welt nicht vorkommen, sollen im Modell ebenfalls nicht auftreten • Korrektheit der Modelle / der Software • Viele Realwelteigenschaften lassen sich mit bisherigen Mitteln jedoch nicht darstellen • Ansatz im UML: Formulierung von Invarianten

  19. 18 4. Invarianten • Ziel: Anreicherung von UML, um in der Realität nicht mögliche Zustände auszuschließen • Invarianten sind boolesche Ausdrücke (wahr/falsch) • Invarianten müssen immer gelten (immer den Wert "wahr" ergeben) • Andere Begriffe: Integritätsbedingungen, Konsistenzbedingungen, engl. Constraints • Formalismus zur Formulierung in UML: OCL (Object Constraint Language) • Beispiele ....

  20. Auftrag Ware: String Wert: int Kunde Alter: int Bonität: String vorbestraft: bool context Auftrag inv: Wert > 0 1 0..* Auftragnehmer context Kunde inv: Alter >= 12 context Auftrag inv: Ware = "Waffen" implies Auftragnehmer.vorbestraft = false A 19 OCL: Einfache Invarianten - Beispiel I and Auftragnehmer.Alter >= 18 4x

  21. 20 OCL: Invarianten I • Invariante bezieht sich auf eine Klasse • Bsp.: context Auftraginv: • Invariante kann Bedingung an Attribute der Klasse stellen (z.B. Wert > 0, Alter > 12) • Invariante kann auch Bedingung an Attribute anderer Klassen stellen, die mir der Klasse eindeutig in Beziehung stehen (Multiplizität 1) • Syntax: Beziehungsname.Attributname, Bsp: Auftragnehmer.vorbestraft = false • Kombination der einzelnen Bedingungen mit booleschen Operatoren and, or, not, implies • Notation der Invariante: in Notiz an Klasse

More Related