Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Introduction to Computer Science I Topic 14: Stepwise

Telecooperation/RBG

Technische Universität Darmstadt

Copyrighted material; for TUD student use only

Introduction to Computer Science ITopic 14: Stepwise Refinement

Prof. Dr. Max MühlhäuserDr. Guido Rößling

Dr. G. RößlingProf. Dr. M. Mühlhäuser

RBG / Telekooperation©

Introduction to Computer Science I: T14

A New Problem

2

Let us assume we now want to design a graphical representation of a String[].Of course, we want to use the classes of ACM JTF.Our design could roughly look like this:

This seems to be a large problem.How can we solve this problem by stepwise refinement?




Stepwise refinement

I. Analysis: What is the problem?II. Planning: How do we solve the

problem?III. Testing/Verification sample/proof

yes continueno to step I. / II.IV. Implementation: solution in form of

programV. Testing/Verification sample/proof

Have we solved the problem?yes done! no to step I. / II.

3

• Claim: OOP supports stepwise refinement and architectural thinking

• “stepwise” basically means “go top-down”:• Start by writing the task in a main method. Use types and

operations as they are needed … just assume you have everything you need

• Specify the new types and operations• Bundle everything in a complete program• Refine the program and the types stepwise

Compared to the design recipe:

• Understand the purpose of the program• Data analysis• Wish list of

helper functions• Consider program

examples• Implementing the

body of the program• Testing




I. Analysis• We try to split the problem by asking questions.

– What is the domain of our problem?• What entities are involved?

– Texts– Array cells

• What tasks are there?– Creating and positioning texts– Creating and positioning array cells– Adding elements to the Canvas

• Idea: We design appropriate graphical objects that will solve our problem– What sort of graphical object could solve our problem?

We need a good plan!

4




II. Planning

5

First Plan

We use terms from the problem domain, not primitive GObject commands (let alone machine code)

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. Testing the plan

6

Testing on this level of abstraction…

This plan seems to solve the problem... Once we have taken the next step and defined the class GStringArray

First Plan




public methods, marked with „+“ in

UML

IV. Implementation

7

Helper method assist us in

implementing the public interface

We implement a new graphical object class that will handle all tasks.

GStringArray+ buildArray(String[], double, double)createDataEntry(String, double, double)createBoxForEntry(int)getWidthForEntry(int)




IV. Implementation

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 of first implementation

• Some operations are still rather long.

• Other operations are hard to understand

• How data is stored remains unclear

9

First Plan

Evaluation failed; return to step II.




Next Refinement Step

• II. Planning (Second Approach)– Divide the operations further

• IV. Implementation (Second Approach)

– We can find similar division for the other operations

10

void createBoxForEntry(int index){ GPoint p0 = determineStartPoint(index); GPoint p1 = determineEndPoint(index); Grect cell = createRect(p0, p1); storeAndAdd(cell);}




Advantages of higher-order operations

• Higher-order operation can be derived from the the terms used in the problem domain.

• The program has a better structure and is easier to understand, especially if appropriate names were chosen.

• The programmer of the run method that uses the GStringArray does not have to consider the details of the implementation of buildArray.

11

Ability to abstract




Advantages of higher-order operations

• The human brain can only work on a limited number of pieces of information at any given time.– Splitting programs into modular units and the ability

to ignore irrelevant facts can be a large help.

• Understandable operations– Not longer than 5-10 statements

• Beginners tend to write operations that are too long.• Better: implement many small, precisely named

operations– Write comments!

• Especially if operations only work correctly if certain conditions are met.

12




Advantages of higher-level operations

• Abstracting by composition of elementary to compound is something we already know about from Scheme

• OOP increases the ability to abstract over irrelevant details (according to some point of view!) by means of inheritance– Can reuse bigger pieces of functionality – Eases the adoption of programs to new

tasks

13




Advantages of higher-level operations

• Testing the program is simplified – A higher operation may be tested separately

• Each individual operation composes less primitive operations than needed for the realization of the whole task easier to test than the whole task

– A tested operation can be considered as a correctly working (primitive) instruction when verifying the remaining parts of the program.

– Higher operations enforce a good modular structure in the program that eases locating bugs. • We locate malfunctioning operations first. • We may concentrate on the instructions in

this operations afterwards. 14




V. Evaluation of Second Implementation

15

Should one class take care of all aspects of a StringArray?• Will become rather large• Has to know much

Evaluation failed; return to step I./II.

• Creating complex objects is… complex– It is best done by a team of specialists that take care of

specific aspects– The coordinator (here: GStringArray) will gather a

fitting team for the task

We will use a similar approach for our String-Array




OO Design as Teamwork

16

• The core of OO problem solving: “teamwork”.• Instead of a „Super-Robot“ that does everything…• …use a set of cooperating objects, where each robot is

specialized and responsible for a well-defined sub-part of the work

• Watch out for problems in your design if you have only one or a few huge classes!




II. Planning (Third Approach)Next refinement step:• We design a team for solving the problem:

– Determining a coordinator for the team– Several workers who focus on one task each

• In this way, we can delegate the creation of parts of a StringArray to specialists: – The coordinator role is taken by our class GStringArray– For creating tet elements, we use the services provided by

GLabel.– For creating text boxes, we use services providede by GRect.– Painting will be delegated to the subelements.

• Sharing the work among objects is preferable if this provides a better degree of abstraction

• The basic idea is that objects offer certain services that can be used by other objects.

17




Comparison with Scheme

• The introduction of helper functions has the same motivation as in Scheme: – Design one level of abstraction after the next– Supports data abstraction– Hides the implementation details of the lower levels– The implementation can be changed easily without

affecting the higher levels of abstraction

• Hierarchical decomposition/composition of functionality – In Scheme: Structures und (helper) functions– In Java: Structuring a space of objects with

operations

• Same Advantages: abstraction / information hiding

18




OO Design with Clients and Servers

• Asymmetric relation: Client - Server– Clients refer to servers (know them as

attributes, or in other ways we will consider soon)

• Do not necessarily exclusively own servers as it is the case with the workers

– Servers do not know clients

– Clients call services

– Clients await• A result• State change

19

serverselected

Client needs service




OO Design with Clients and Servers• Servers provide services either directly or by being

themselves clients of other servers• Whether a server provides a service directly or

delegates it, is transparent for the clients

20

server

server

server

selected

Client needs service

client uses service





• We discussed the step-wise refinement technique for designing a single class… – Start designing a solution by asking what services

are needed by the class– Next, design complex services of the class as a

decomposition into simpler services– Continue decomposing until primitive operations

• We have distinguished two kinds of operations: (see slide 7)– The first kind, e.g., buildArray() in the GStringArray class of the 1st Implementation, was meant to be requested by clients (the main method in that example)

– The other kind, e.g., createDataEntry(), was meant to be used internally, as part of problem decomposition.

21





• Next, we generalize this technique, looking at design from a broader perspective: – We recognize that we may need several classes of

robots to carry out some task – These classes may need to cooperate in some

way

• Generalizing: The place to begin design is with the public services and the servers providing them. – Server classes will then, perhaps, execute other

instructions, or even create other helper classes and use their services to provide the public services.

– We can use successive refinement to help design the other instructions and helper classes.

22




Stepwise OOD: An Example• We have a class GStringArray• New instances of this class will take care of assembling a

„fitting“ StringArray on the screen• Clients simply call the constructor with appropriate

parameters– The work is then done „somehow“– The client does not care, how GStringArray will do this, as long as the

result is OK• Keep in mind, that we will for now focus on designing the

class GStringArray with one public method: its constructor– Later on, we may notice that we need more methods or

classes.– We also know that we will probably need only one

instance of the class GStringArray for each StringArray let us call it 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) { // … }}




Designing Workers: Alternative 1

• We may decided that…:– GArrayCell objects offer the service createCellBox(int, double, double)

• The GStringArray will tell the GArrayCell where to put the cell.

– GArrayElement objects offer the service createArrayValue(String, double, double)

• GStringArray has to tell the object which value is put where

25

Consequence: the coordinator has to know all operations of its workers – that makes it more complex.





• Each specialized worker knows its tasks:– It also knows the names of all tasks and subtasks it has to

do.– If the coordinator simply orders the worker to work(), it

will know what has to be done. • We can fix this interface using an Interface Worker

– The other classes will implement this interface by implementing the new method.

– Each worker subclass will implement work in ist own specific way.

26

interface Worker { void work(); }

Advantage: the coordinator can use a shared interface type for all workers.





• We can also directly use the „fitting“ classes from ACM JTF:– Array values are represented by GLabel objects– Array cells are rendered using GRect– We essentially only have to use the constructors!

• However, the coordinator has to fix the position for each element

• The array values and cells will be stored in one array each

• We also have to consider the implementation of the methods paint(Graphics) and getBounds()– paint(Graphics g) : Iterate the value and cellBoxes array in a

loop and send the message paint(g) to each element– getBounds(): Determine the start and end position of the first

and last cell and use this to determine start, width and height

27




The simplified GStringArray class

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

• The code is still rather long…• Luckily, ACM JTF offers us additional support!

– Class GCompound models composed objects– GCompound directly takes are of…:

• The determination of getBounds()• The painting method ( paint(Graphics)); this simply paints

all objects inserted before using add(GObject)• The elements are stored internally




Further simplification using 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 more complex cases, the coordinator needs access to ist team – even after the creation of the elements– We declare the names of the helpers as private

attributes in the coordinator class, instead of as global names.

• The client is not interested in details on how the coordinator will organize the workers.

• This also effectively prevents the client from giving orders to the workers.

• Encapsulation!

• The coordinator has to be able to gather ist team, so we need a method for this gatherTeam– This method should probably be called internally

by the coordinator when it starts working.

32




The generalized Contractor Class

33

class Contractor extends GObject { // Constructor (hidden) Worker ken = new ...(...); Worker tim = new ...(...); Worker linda = new ...(...);

void gatherTeam() { // Messages for the initialization // of the workers. } public void buildHouse() { gatherTeam(); ken.work(); tim.work(); linda.work(); //... }}




UML Class Diagram

34

The UML name for association

Contractor

+ doTheJob()

<<interface>>

Worker+ work()

X+ work()

Y+ work()

Z+ work()

internalMethodA() internalMethodB()internalMethodC()

internalMethodD()

ken : Workertim: Workerlinda: Worker…

uses

gatherTeam()




OO Design – Klienten und Server

• The coordinator is a server class. Its client is the method that calls the server method.– Even if this is a constructor call!

• The coordinator can also be a client of other classes, if they offer services (creation of element, …).

• In fact, it is rather usual in the „real world“ that clients and servers will be linked. – For example, the workers of a constructor can also

have a house built for themselves.

35

Documents

Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Introduction to Computer Science I Topic 14: Stepwise