Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik I Thema 14: Schrittweise.

Präsentation zum Thema: "Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik I Thema 14: Schrittweise."—  Präsentation transkript:

1 Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik I Thema 14: Schrittweise Verfeinerung Prof. Dr. Max Mühlhäuser Dr. Guido Rößling

2 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Problemstellung 2 Aufgabe: Angenommen, wie möchten eine grafische Repräsentation für ein String[] entwerfen. Natürlich nutzen wir dafür die Klassen von ACM JTF. Grob könnte das Ganze in etwa wie folgt aussehen: Wir stehen zunächst einmal vor einem großen Problem. Aber können wir das Problem durch eine schrittweise Verfeinerung lösen?

3 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Schrittweise Verfeinerung I.Analyse: Was ist das Problem? II.Planung: Wie lösen wir das Problem? III.Testen/Verifikation Ausprobieren/Beweisen Ja Weiter!Nein zu Schritt I. / II. IV.Implementierung: Lösung als Programm V.Testen/Verifikation Ausprobieren/Beweisen Haben wir das Problem gelöst? Ja Fertig!Nein zu Schritt I. / II. 3 schrittweise meint top-down: Schreibe zuerst die Aufgaben in einer Methode. Benutze dabei beliebige Klassen und Operationen nach Bedarf setze voraus, es existiert alles was gebraucht wird Spezifiziere die neuen Robotertypen und Operationen Schnüre alles zu einem kompletten Programm Verfeinere Programm und Robotertypen wiederum schrittweise Behauptung: OOP unterstützt schrittweise Verfeinerung und eine architektonische Denkweise Vergleich Design-Rezept: Verstehen, was der Zweck des Programms ist Datenanalyse Wunschliste von (Hilfs-)Funktionen Programmbeispiele ausdenken Den Programmkörper implementieren Testen

4 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 I. Analyse Wir versuchen durch Fragen das Problem zu zerlegen. –Wie sieht die Problemdomäne aus? Was für Beteiligte gibt es? –Texte –Arrayzellen Was für einzelne Aufgaben gibt es? –Texte erstellen und positionieren –Arrayzellen erstellen und positionieren –Elemente dem Canvas hinzufügen Idee: Wir entwerfen passende Grafik-Objekte, die unser Problem lösen –Was für ein Grafiktyp könnte unser Problem lösen? Wir brauchen einen guten Plan! 4

5 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 II. Planung 5 Erster Plan Wir benutzen Begriffe aus der Problemdomäne und nicht primitive GObject -Befehle (oder gar Maschinenbefehle) public void buildArray(String[] contents, double x, double y) { setLocation(x, y); // store position double x0 = x; // initial x position for (int i=0; i<contents.length; i++) { // loop... createDataEntry(contents[i], x0, y); // value createBoxForEntry(i); // array cell x0 += getWidthForEntry(i); }

6 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 III. Testen des Plans 6 Testen auf diesem Abstraktionslevel… Dieser Plan scheint das Problem zu lösen... wenn wir erst einmal einen Schritt weitergegangen sind und die Klasse GStringArray definiert haben Erster Plan

7 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Öffentliche ( public ) Funktionen, markiert mit + in UML IV. Implementierung 7 Hilfsfunktionen dienen zur Implementierung der öffentlichen Schnittstelle (interface) Wir implementieren eine Grafik-Klasse, die alle Aufgaben übernimmt. GStringArray + buildArray(String[], double, double) createDataEntry(String, double, double) createBoxForEntry(int) getWidthForEntry(int)

8 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 IV. Implementierung 8 public class GStringArray extends GObject { // Konstruktor (weggelassen) public void buildArray(String[] c, double x, double y) { setLocation(x, y); // store initial position double x0 = x; for (int i=0; i<c.length; i++) { // loop over all elems createDataEntry(c[i], x0, y); // create actual entry createBoxForEntry(i); // create "fitting" box x0 += getWidthForEntry(i); // adapt x position } void createDataEntry(String s, double x, double y) {...} void createBoxForEntry(int index ) {...} double getWidthForEntry(int index ) {...} void paint(Graphics g ) {...} GRectangle getBounds() {...} }

9 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 void createBoxForEntry(int index) { // Retrieve text GPoint v=getStartOf(index); double x0 = v.getX() – 5; double y0 = v.getY() – 15; v = getEndOf(index); double x1 = x0 + w.getX() + 5; double y1 = y0 + y.getY() +15; createAndStoreBox(x0, y0, x1, y1); } V. Evaluation 1. Implementierung Einige Operationen sind immer noch sehr lang. Andere Operationen sind schwer zu verstehen Die Speicherung der Daten ist unklar 9 Erster Plan Evaluation fehlgeschlagen; kehre zurück zu Schritt II.

10 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Nächster Schritt der Verfeinerung II. Planung (2. Durchlauf) –Zerlege die einzelnen Operationen weiter IV. Implementierung (2. Durchlauf) –Für die anderen Operationen lassen sich ähnliche Zerlegungen finden 10 void createBoxForEntry(int index){ GPoint p0 = determineStartPoint(index); GPoint p1 = determineEndPoint(index); Grect cell = createRect(p0, p1); storeAndAdd(cell); }

11 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Vorteile übergeordneter Operationen Übergeordnete Operation können aus Begriffen der Problemdomäne hergeleitet werden. Programm ist besser strukturiert und einfacher zu verstehen, insbesondere, wenn passende Namen gewählt wurden. Der Programmierer der run -Methode, die das GStringArray verwendet, muss sich nicht mit den Details der Realisierung von buildArray auseinandersetzen. 11 Fähigkeit zu abstrahieren

12 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Vorteile übergeordneter Operationen Das menschliche Gehirn kann nur eine begrenzte Menge von Informationen auf einmal wahrnehmen. –Das Zerlegen der Programme in modulare Einheiten und die Fähigkeit unwichtige Details zu ignorieren, ist eine große Hilfe. Verständliche Operationen –Nicht länger als 5 bis 10 Anweisungen Anfänger neigen dazu, zu lange Operationen zu schreiben. Besser: viele kleine und sinnvoll benannte Operationen –Kommentare schreiben! Insbesondere, wenn Operationen nur unter bestimmten Bedingungen korrekt arbeiten. 12

13 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Vorteile abstrakterer Operationen Abstraktion durch Komposition von Elementen zu Verbünden kennen wir schon von Scheme. OOP verbessert die Möglichkeiten, über irrelevante Details (eines Blickpunkts) mittels Vererbung zu abstrahieren. –Wiederverwendung größerer Blöcke –Erleichtert das Anpassen der Programme an neue Aufgaben 13

14 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Vorteile übergeordneter Operationen Testen des Programms wird erleichtert –Eine übergeordnete Operation kann separat getestet werden. Sie enthält weniger Operationen als für die Realisierung einer ganzen Aufgabe notwendig wären einfacher zu testen als die gesamte Aufgabe. –Eine getestete Operation kann beim Testen des restlichen Programms als eine korrekt funktionierende (primitive) Anweisung betrachtet werden. –Übergeordnete Operationen erzwingen eine modulare Struktur, die es ermöglicht, Fehler leichter zu lokalisieren. Wir lokalisieren zunächst fehlerhafte Operationen. Danach können wir uns bei der weiteren Suche auf die Anweisungen dieser Operationen konzentrieren. 14

15 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 V. Evaluation 2. Implementierung 15 Sollte sich eine Klasse alleine um alle Aspekte des StringArrays kümmern? Wird zu umfangreich Muss sehr viel wissen Evaluation fehlgeschlagen; kehre zurück zu Schritt I./II. Das Erstellen komplexer Objekte ist… komplex –Wird am Besten von einem Team von Spezialisten übernommen, die sich um einzelne Aspekte kümmern –Der Koordinator (hier: GStringArray ) stellt sich selbst ein passendes Team für die Aufgabe zusammen Wir werden einen ähnlichen Ansatz für unser String-Array verfolgen

16 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design als Teamwork 16 Der Kern von Problemlösungen mit OO: Teamwork. Anstelle eines Super-Objekts, das alles tut, arbeitet eine Menge von Objekten zusammen Dabei ist jedes Objekt spezialisiert und dafür verantwortlich, einen wohl definierten Teil der Arbeit zu erledigen. Achten Sie auf Probleme in Ihrem Design, wenn Sie nur eine oder wenige große Klassen haben!

17 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 II. Planung (3. Durchlauf) Nächster Schritt der Verfeinerung: Wir entwerfen ein Team, welches die Aufgabe löst: –Bestimmen eines Koordinators des Teams –Mehrere Arbeitskräfte, die sich auf die einzelnen Aufgaben spezialisieren Man kann so das Bearbeiten von Teilen des StringArrays an Spezialisten delegieren: –Die Koordinator-Rolle übernimmt unsere Klasse GStringArray –Zum Bauen von Textelementen nutzen wir die Dienste von GLabel. –Das Anlegen von Textboxen übernehmen Dienste von GRect. –Das Zeichnen wird an alle Unterelemente delegiert. Das Aufteilen von Aufgaben auf Objekte ist vorzuziehen, wenn Abstraktion besser unterstützt werden soll Grundlegende Idee dahinter ist, dass Objekte bestimmte Dienste anbieten, die von anderen Objekten genutzt werden. 17

18 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Vergleich zu Scheme Einführung von Hilfsfunktionen für Objekte hat die selbe Motivation wie in Scheme: –Eine Abstraktionsebene nach der anderen entwerfen –Unterstützt Datenabstraktion –Verbergen der Implementierungsdetails der unteren Ebenen –Implementierungen können leichter geändert werden, ohne die höheren Abstraktionsebenen zu verändern Hierarchische Dekomposition/Komposition von Funktionalität –In Scheme: Strukturen und (Hilfs-)Funktionen –In Java: Strukturieren eines Raums von Objekte mit Operationen Gleiche Vorteile: Abstraktion / Information Hiding 18

19 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design – Klienten und Server Asymmetrische Beziehung: Klient - Server –Klient zeigt auf Server (kennt ihn als Attribut, Variable oder Parameter) Er muss den Server nicht unbedingt alleine besitzen, wie es bei den Arbeitern der Fall ist. –Server kennt Klienten nicht –Klient ruft Service auf –Klient wartet auf Ergebnis auf Verhaltensänderung 19 ausgewählter Server Klient benötigt Service

20 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design – Klienten und Server Ein Server erbringt Services entweder selbst oder durch anderen Server (selbst ein Klient). Dies ist für Klienten transparent 20 Server ausgewählter Klient benötigt Service Klient nutzt Service

21 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design – Klienten und Server Wir haben bereits die Technik schrittweise Verfeinerung zum Entwerfen einer einzelnen Klasse diskutiert… –Beginne das Entwerfen einer Lösung durch fragen, welche Services von der Klasse verlangt werden. –Als nächstes entwerfe komplexe Services der Klasse als Dekomposition in einfachere Services. –Fahre mit der Dekomposition bis zu primitiven Operationen fort. Wir haben zwei Arten von Operationen unterscheiden: (s. Folie 7) –Öffentliche Operationen, z.B. buildArray(), in der Klasse GStringArray der 1. Implementierung, waren für Anfragen von Klienten gedacht (die main -Method im Beispiel) –Helfer Operationen, z.B. createDataEntry(), waren für den internen Gebrauch als Teil der Dekomposition gedacht. 21

22 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design – Klienten und Server Als nächstes verallgemeinern wir diese Technik, indem wir das Design aus einer breiteren Perspektive betrachten: –Wir erkennen, dass wir eventuell mehrere Klassen benötigen, um eine Aufgabe auszuführen. –Diese Klassen müssen vielleicht irgendwie zusammenarbeiten. Verallgemeinerung: Es wird mit dem Design der öffentlichen Servern und deren öffentlichen Services, die sie anbieten begonnen. –Serverklassen werden dann (vielleicht) andere Befehle ausführen oder sogar Hilfsobjekte erzeugen und deren Services benutzen, um öffentliche Services anzubieten. –Wir können schrittweise Verfeinerung benutzen, um die anderen Befehle und die Hilfsklassen zu entwerfen. 22

23 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Schrittweise OOD am Beispiel Wir haben eine Klasse GStringArray Neue Instanzen dieser Klasse kümmern sich um den Aufbau eines passenden StringArrays auf dem Bildschirm Klienten rufen einfach den Konstruktor mit entsprechenden Parametern auf –Die Arbeit wird dann irgendwie erledigt –Dem Klient ist es egal, wie das GStringArray die Aufgabe ausführt, solange das Ergebnis in Ordnung ist Beachten Sie, dass wir vorläufig nur die Klasse GStringArray entwerfen, mit einer öffentlichen Methode: dem Konstruktor –Wir können später feststellen, dass wir mehr Methoden und mehr Klassen benötigen. –Wir wissen auch, dass wir wahrscheinlich nur eine Instanz der Klasse GStringArray benötigen Nennen wir sie stringArray. 23

24 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Top-Level Design 24 private String[] values = …; // actual values public void run() { GStringArray stringArray = new GStringArray(values, 100, 100); add(stringArray); } //... class GStringArray extends GObject { public GStringArray(String[] values, double x, double y) { // … }

25 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Arbeiter entwerfen: Variante 1 Wir können uns entscheiden, dass: –GArrayCell Instanzen die Methode createCellBox(int, double, double) anbieten Das GStringArray sagt der GArrayCell, wo die Zelle hin soll. –GArrayElement den Dienst createArrayValue(String, double, double) anbietet: Das GStringArray muss dem Objekt sagen, welcher Wert an welche Position geschrieben wird 25 Nachteil: der Koordinator muss jede Operation der Arbeiter kennen - das macht ihn komplizierter.

26 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Arbeiter entwerfen: Variante 2 Jeder spezialisierte Arbeiter kennt seine eigene Aufgabe: –Er kennt auch die Namen der Aufgaben und Unteraufgaben, die er erledigen muss. –Wenn der Koordinator ihm einfach befiehlt work(), weiß er schon, was er zu tun hat. Wir können diese Schnittstelle mit einem Interface Worker festlegen –Die anderen Klassen implementieren dieses Interface dann, indem sie die neue Methode implementieren. –Jede Arbeiter-Unterklasse implementiert work in einer anderen Art und Weise. 26 interface Worker { void work(); } Vorteil: der Koordinator kann alle Arbeiter über einen gemeinsamen Interfacetypen verwenden.

27 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Arbeiter entwerfen: Variante 3 Wir verwenden direkt passende Klassen von ACM JTF: –Arraywerte werden über GLabel repräsentiert –Arrayzellen werden mittels GRect erstellt –Wir müssen also im Wesentlichen nur die Konstruktoren nutzen! Allerdings muss der Koordinator für jedes Element die Position festlegen Die Arraywerte und –zellen speichern wir in jeweils einem Array Wir müssen auch an die Implementierung der Methoden paint(Graphics) und getBounds() denken –paint(Graphics g): Durchlaufe die Arrays in einer Schleife und jede jedem Element die Nachricht paint(g) –getBounds(): Bestimme Anfangs- und Endposition der ersten und letzten Zelle berechne daraus Anfang, Breite und Höhe 27

28 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Die vereinfachte GStringArray Klasse 28 package acm.graphics; import java.awt.Graphics; public class GStringArray extends GObject { private GLabel[] array; private GRect[] cellBoxes; public GStringArray(String[] values, double x, double y) { setLocation(x, y); // set the base location int nrElems = values.length; // nr of array elements array = new GLabel[nrElems]; // allocate value storage cellBoxes = new GRect[nrElems]; // create cell storage double x0 = x; // initial x position for (int i = 0; i < nrElems; i++) { // iterate... x0 = createAndStoreElement(values[i], i, x0, y); }

29 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Die vereinfachte GStringArray Klasse 29 private double createAndStoreElement(String string, int index, double x, double y) { array[index] = new GLabel(string, x + 5, y + 15); // add padding cellBoxes[index] = new GRect(x, y, array[index].getWidth() + 10, 20); return x + cellBoxes[index].getWidth(); } public GRectangle getBounds() { double x0 = array[0].getX(); double y0 = array[0].getY(); GRect lastRect = cellBoxes[cellBoxes.length - 1]; double width = lastRect.getX() + lastRect.getWidth() - x0; double height = lastRect.getY() + lastRect.getHeight() - y0; return new GRectangle(x0, y0, width, height); }

30 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Die vereinfachte GStringArray Klasse 30 public void paint(Graphics g) { for (int i = 0; i < array.length; i++) { // iterate over all cellBoxes[i].paint(g); // paint current box array[i].paint(g);// paint current elem } Der Code ist immer noch sehr lang… Zum Glück bietet ACM JTF auch hier noch eine Hilfe! –Klasse GCompound modelliert zusammengesetzte Objekte –GCompound kümmert sich automatisch um…: Die Berechnung von getBounds() Die Zeichenmethode ( paint(Graphics)); diese zeichnet alle Objekte, die zuvor mit add(GObject) eingefügt wurden Die Elemente werden intern gespeichert

31 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Weitere Vereinfachung mit GCompound 31 package acm.graphics; public class GStringArrayCompound extends GCompound { public GStringArrayCompound(String[] values, double x, double y) { setLocation(x, y); // set the object's location // create Strings and boxes double x0 = x; // initial x position for (String value: values) // iterate over all input values x0 = makeEntry(value, x0, y); // create object at (x0, y) markAsComplete(); } private double makeEntry(String value, double x, double y) { GLabel text = new GLabel(value, x + 5, y + 15); // some offset GRect arrayCell = new GRect(x, y, text.getWidth()+10, 20); add(arrayCell); // add the element to the canvas -> visible add(text); // add the element to the canvas -> visible return x + arrayCell.getWidth(); }

32 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Verallgemeinerung In komplexeren Fällen muss der Koordinator Zugriff auf sein Team haben – auch nach der Erstellung der Elemente –Dafür werden die Namen der Helfer als private Attribute in der Koordinator-Klasse deklariert, anstatt als globale Namen. Der Klient will keine Details darüber wissen, wie der Koordinator die Arbeit organisiert. Das verhindert effektiv, dass der Klient des Koordindators den Arbeitern direkt sagt, was sie tun sollen. Einkapselung! Der Koordinator muss sein Team versammeln können, also brauchen wir dafür eine Methode gatherTeam –Diese sollte wahrscheinlich intern vom Koordinator ausgerufen werden, wenn er mit der Arbeit beginnt. 32

33 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 Die allgemeine Contractor -Klasse 33 class Contractor extends GObject { // Konstruktor (versteckt) Worker ken = new...(...); Worker tim = new...(...); Worker linda = new...(...); void gatherTeam() { // Nachrichten fuer die Initialisierung // des Teams. } public void buildHouse() { gatherTeam(); ken.work(); tim.work(); linda.work(); //... }

34 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 UML- Klassendiagramm 34 Die UML Bezeichnung für Assoziation Contractor + doTheJob() > Worker + work() X Y Z internalMethodA() internalMethodB() internalMethodC() internalMethodD() ken : Worker tim: Worker linda: Worker … benutzt gatherTeam()

35 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T14 OO Design – Klienten und Server Der Koordinator ist eine Server-Klasse. Ihr Klient ist die Methode, die die Server-Methode aufruft. –Auch wenn es sich dabei um einen Konstruktor handelt! Auch der Koordinator kann Klient von anderen Klassen sein, weil diese Services (Bau von Elementen, …) anbieten. Tatsächlich ist es relativ üblich in der realen Welt, dass Klienten und Server gegenseitig verbunden sind. –So können sich auch die Arbeiter eines Bauunternehmers ein Haus bauen lassen 35