telecooperation/rbg technische universität darmstadt copyrighted material; for tud student use only...

Telecooperation/RBG

Technische Universität Darmstadt

Copyrighted material; for TUD student use only

Grundlagen der Informatik I

Thema 14: Schrittweise Verfeinerung

Dr. G. RößlingProf. 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?




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 ProgrammV. 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




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




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);}




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




Ö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)




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() {...}}




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.




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);}




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





• 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




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





• 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




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 Spezialisieten

übernommen, die sich um einzelne Aspekte kümmern– Der Koordinator (hier: GStringArray) stellt sich selbt

ein passendes Team für die Aufgabe zusammen

Wir werden einen ähnlichen Ansatz für unser String-Array verfolgen




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 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!




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




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 Hiding18




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




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

Server

Server

ausgewählter

Klient benötigt Service

Klient nutzt Service





• 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





• 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




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




Top-Level Design

24

private String[] values = …; // actual valuespublic void run() { GStringArray stringArray = new GStringArray(values, 100, 100); add(stringArray);} //...

class GStringArray extends GObject { public GStringArray(String[] values, double x, double y) { // … }}




Arbeiter entwerfen: Alternative 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.





• 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.





• 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




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

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

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




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(); }}




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




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(); //... }}




UML- Klassendiagramm

34

Die UML Bezeichnung für Assoziation

Contractor

+ doTheJob()

<<interface>>

Worker+ work()

X+ work()

Y+ work()

Z+ work()

internalMethodA() internalMethodB()internalMethodC()

internalMethodD()

ken : Workertim: Workerlinda: Worker…

benutzt

gatherTeam()





• 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 von

Bauunternehmers ein Haus bauen lassen35

telecooperation/rbg technische universität darmstadt copyrighted material; for tud student use only...

Documents