Principles of Object-Oriented Software Development

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Application development

After studying general issues in the design and software engineering of object-oriented applications and frameworks, it is time to focus in somewhat more detail on actual application development.

In this chapter we will look at the drawtool application, as a representative of a broader category of interactive editing tools.

Application development

the drawtool applications
guidelines for design
from specification to implementation

Additional keywords and phrases: hush framework, interactive editors, law of Demeter, formal specification in Z, abstract systems

slide: Application development

The drawtool application is a Java application using the multiparadigm hush framework. However, in discussing its development, we will concentrate on specifying the requirements and issues of design.

After that we will treat some miscellaneous issues in the design of classes. This chapter will be concluded with a case study, a concise, yet detailed, example of a more formal approach to the development of an object-oriented application.

The drawtool application

Interactive editors are an interesting category of applications. Interactive editors, which include word processors and drawing tools, are the kind of applications the average (end) user is most familiar with. From a software engineering perspective, interactive editors are interesting because they combine interactive and functional features. See also [GOF94], which provides many patterns for interactive editors.

In the Software Engineering curriculum at the Vrije Universiteit, we have repeatedly used interactive editors as a medium-term assignment for CS2 students (five weeks for groups of four or five students). One example of such an assignment is the Interactive Design Assistant discussed in section IDA. Another example is the musical score editor (see appendix Projects), which has been chosen by a selected group of CS3 and CS4 students as a practical assignment for the Object-Oriented Software Development course.

In this section we will look at the drawtool application, which is a representative realization of a (rather simple) drawing editor. The implementation of drawtool presented here is realized in the Java version of the hush framework. The hush C++ framework has been used for a number of years in the Software Engineering curriculum, but has recently been replaced by Java with Swing. The drawtool application is nevertheless interesting because it acted for many years as the basic example of an interactive editor for quite a number of students.

Before studying drawtool, we will first look at the realization of a drawing canvas in hush

A simple drawing canvas in hush

The Tcl/Tk toolkit provides a very powerful scripting environment for realizing graphical user interfaces, [Ousterhout91]. The hush Java/C++ library gives convenient access to the Tcl/Tk toolkit in an object-oriented style. See also [HUSH].

slide: The hush class hierarchy

The hush library provides three kinds of classes, namely (a) the widget classes, which mimic the functionality of Tk, (b) the handler and event classes, which are involved in the handling of events and the binding of Java/C++ code to Tcl commands, and (c) the classes kit and session, which encapsulate the embedded interpreter and the window management system,

In the widget class hierarchy depicted on the right in slide hush-overview, the widget class represents an abstract widget, defining the commands that are valid for each of the descendant concrete widget classes. The widget class, however, is not an abstract class in Java or C++ terms. It may be used for creating references to widgets defined in Tcl. In contrast, employing the constructor of one of the concrete widget classes results in actually creating a widget.

slide: Drawing canvas

Widgets are the elements from which a GUI is made. They appear as windows on the screen to display text or graphics and may respond to events such as motioning the mouse or pressing a key by calling an action associated with that event. The interface of the widget class may be defined by the (pseudo) interface below.


  public interface widget {    widget  


  
  public String path();
  
  public void eval(String cmd);
  
  public void pack(String s);
  
  public void bind(handler h,String s);
  public void bind(String p, handler h,String s);
  
  public void configure(String cmd);
  public void geometry(int x, int y);
  
  public void xscroll(widget w);
  public void yscroll(widget w);
  
  public widget self(); // to define compound widgets
  public void redirect(widget inner);
  };

The function path delivers the path name of a widget object. Each widget created by Tk actually defines a Tcl command associated with the path name of the widget. In other words, an actual widget may be regarded as an object which can be asked to evaluate commands. For example a widget `.b' may be asked to change its background color by a Tcl command like .b configure -background blue The function eval enables the programmer to apply Tcl commands to the widget directly, as does the configure command. The function geometry sets the width and height of the widget.

As an example look at the code for the drawing canvas widget depicted in slide drawing-canvas.


  import hush.dv.api.event;
  import hush.dv.widgets.canvas;
  
  class draw extends canvas {    draw   go.java    


  boolean dragging;
  
  public draw(String path) {
  	super(path); 
  	dragging = false;
  	bind(this);
  	}
  
  
  public void press(event ev) {
  	dragging = true;
  	}
  
  public void release(event ev) {
  	dragging = false;
  	}
  
  public void motion(event ev) {
  	if (dragging)
  		circle(ev.x(),ev.y(),2,"-fill black");
  	}
  };

The class draw has an instance variable dragging, that reflects whether the user is actually drawing a figure. If dragging is true, motions with the mouse will result in small dots on the screen.

slide: Drawing canvas

A structural view of the draw class is given in slide draw-structure. The draw class is derived from a canvas, which is itself (indirectly) derived from a handler class. The handler class dispatches events to predefined handler methods, such as press, motion and release.

For the draw class we must distinguish between a handler and a canvas part. The handler part is defined by the methods press, release and motion. The canvas part allows for drawing figures, such as a small circle.

slide: Drawing canvas

In slide draw-interact it is depicted how these two parts interact when the user draws a figure. Actions of the user result in events that activate the handler. Note that the UML sequence diagrams are not completely adequate here, since it is difficult to express information concerning the events and the state of the draw instance.

Widgets may respond to events. To associate an event with an action, an explicit binding must be specified for that particular widget. Some widgets provide default bindings. These may, however, be overruled.

The function bind is used to associate handlers with events. The first string parameter of bind may be used to specify the event type. Common event types are, for example, ButtonPress, ButtonRelease and Motion, which are the default events for canvas widgets. Also keystrokes may be defined as events, for example Return, which is the default event for the entry widget. The function $bind(handler,String)$ may be used to associate a handler object with the default bindings for the widget. Concrete widgets may not override the bind function itself, but must define the protected function install. Typically, the install function consists of calls to bind for each of the event types that is relevant to the widget.

In addition, the widget class offers two functions that may be used when defining compound or mega widgets. The function $redirect(w)$ must by used to delegate the invocation of the eval, configure and bind functions to the widget w. The function $self()$ gives access to the widget to which the commands are redirected. The function path will still deliver the path name of the outer widget. Calling redirect when creating the compound widget class suffices for most situations. However, when the default events must be changed or the declaration of a handler must take effect for several component widgets, the function install must be redefined to handle the delegation explicitly.

The drawtool application

slide: The drawtool interface

In this section we will look at the realization of simple drawing tool. The example illustrates how to use the hush library widgets, and serves to illustrate in particular how to construct compound widgets.

A structural view of the drawtool application is given in slide drawtool-structure.

slide: A (partial) class diagram

Usually, the various widgets constituting the user interface are (hierarchically) related to each other, such as in the drawtool application which contains a canvas to display graphic elements, a button toolbox for selecting the graphic items and a menubar offering various options such as saving the drawing in a file. Widgets in Tk are identified by a path name. The path name of a widget reflects its possible subordination to another widget. See slide widget-hierarchy.

slide: Widget containment

Pathnames consist of strings separated by dots. The first character of a path must be a dot. The first letter of a path must be lower case. The format of a path name may be expressed in BNF form as


   path ::= '.'  $|$  '.'string  $|$  path'.'string

For example `.' is the path name of the root widget, whereas `.quit' is the path name of a widget subordinate to the root widget. A widget subordinate to another widget must have the path name of that widget as part of its own path name. For example, the widget `.f.m' may have a widget `.f.m.h' as a subordinate widget. Note that the widget hierarchy induced by the path names is completely orthogonal to the widget class inheritance hierarchy. With respect to the path name hierarchy, when speaking of ancestors we simply mean superordinate widgets. Our drawing tool consists of a tablet, which is a canvas with scrollbars to allow for a large size canvas of which only a part is displayed, a menubar, having a File and an Edit menu, and a toolbox, which is a collection of buttons for selecting from among the drawing facilities. In addition, a help facility is offered.

slide: An interaction diagram

A typical interaction (or use case) with drawtool is depicted in slide drawtool-interact. On selecting the circle menu entry (or toolbox button), the circle handler is activated to assist in the drawing of a circle. Details will be given when discussing the tablet widget.

The toolbox component

As the first component of drawtool, we will look at the toolbox. The toolbox is a collection of buttons packed in a frame.


  import hush.dv.api.*;
  import hush.dv.widgets.frame;
  
  public class toolbox extends frame {     toolbox  


  
  tablet tablet;
  
  public toolbox(widget w, tablet t) {
      super(w,"toolbox");
      tablet = t;
      new toolbutton(this,"draw");
      new toolbutton(this,"move");
      new toolbutton(this,"box");
      new toolbutton(this,"circle");
      new toolbutton(this,"arrow");
  }
  
  
  public int operator() {
          tablet.mode(_event.arg(1)); // reset tablet mode
          return OK;
          }
  
  };

Each button is an instance of the class toolbutton.


  import hush.dv.api.*;
  import hush.dv.widgets.button;
  
  public class toolbutton extends button {    toolbutton  


  public toolbutton(widget w, String name) {
          super(w,name); 
          text(name);
          bind(w,name); 
          pack("-side top -fill both -expand 1"); 
          }
  };

When a toolbutton is created, the actual button is given the name of the button as its path. Next, the button is given the name as its text, the ancestor widget w is declared to be the handler for the button and the button is packed. The function text is a member function of the class button, whereas both handler and pack are common widget functions. Note that the parameter name is used as a path name, as the text to display, and as an argument for the handler, that will be passed as a parameter when invoking the handler object. The toolbox class inherits from the frame widget class, and creates a frame widget with a path relative to the widget parameter provided by the constructor. The constructor further creates the five toolbuttons. The toolbox is both the superordinate widget and handler for each toolbutton. When the

operator()

function of the toolbox is invoked in response to pressing a button, the call is delegated to the mode function of the tablet. The argument given to mode corresponds to the name of the button pressed. The definition of the toolbutton and toolbox illustrates that a widget need not necessarily be its own handler. The decision, whether to define a subclass which is made its own handler or to install an external handler depends upon what is considered the most convenient way in which to access the resources needed. As a guideline, exploit the regularity of the application.

The menubar component

The second component of our drawing tool is the menubar.


  import hush.dv.api.widget;
  
  public class menubar extends hush.dv.widgets.menubar {    menubar  


  
  public menubar(widget w, tablet t, toolbox b)  {
      super(w,"bar");
      configure("-relief sunken"); 
  
      new FileMenu(this,t); 
      new EditMenu(this,b);
      new HelpButton(this); 
      }
  };

The class menubar, given above, is derived from the hush widget menubar. Its constructor requires an ancestor widget, a tablet and a toolbox. The tablet is passed as a parameter to the {\em file_menu}, and the toolbox to the {\em edit_menu}. In addition, a {\em help_button} is created, which provides online help in a hypertext format when pressed.

A menubar consists of menubuttons to which actual menus are attached. Each menu consists of a number of entries, which may possibly lead to cascaded menus. The second button of the menubar is defined by the EditMenu. The EditMenu requires a toolbox and creates a menubutton. It configures the button and defines a menu containing two entries, one of which is a cascaded menu. Both the main menu and the cascaded menu are given the toolbox as a handler. This makes sense only because for our simple application the functionality offered by the toolbox and EditMenu coincide.

slide: Tablet

The tablet component

The most important component of our drawtool application is defined by the tablet widget class given below.


  import hush.dv.api.*;
  import hush.dv.widgets.*;
  
  public class tablet extends canvas {    tablet  


  
  int _mode;
  canvas canvas;
  handler[] handlers;
  
  final int DRAW = 0;
  final int MOVE = 1;
  final int CIRCLE = 2;
  final int BOX = 3;
  final int ARROW = 5;
  
  
  public tablet(widget w, String name, String options) {
  
  	super(w,name,"*");
  
  	handlers = new handler[12];
  
          init(options);
          redirect(canvas); // to delegate to canvas
          bind(this); // to intercept user actions 
  	
          handlers[DRAW] = new DrawHandler(canvas);
          handlers[MOVE] = new MoveHandler(canvas);
          handlers[BOX] = new BoxHandler(canvas);
          handlers[CIRCLE] = new CircleHandler(canvas);
          handlers[ARROW] = new ArrowHandler(canvas);
  
          _mode = 0; // drawmode.draw;
          }
  
  
  public int operator() { 
  	handlers[_mode].dispatch(_event);
  	return OK;
  	}
  
  
  public int mode(String s) { 
  	int m = -1;
  	if ("draw".equals(s)) m = DRAW; 
  	if ("move".equals(s)) m = MOVE; 
  	if ("box".equals(s)) m = BOX; 
  	if ("circle".equals(s)) m = CIRCLE;
  	if ("arrow".equals(s)) m = ARROW; 
  	if (m >= 0) _mode = m;
  	return _mode;
  	}
  
  
  void init(String options) {
  
          widget root = new frame(path(),"-class tablet");
  
  	canvas = new canvas(root,"canvas",options);
  	canvas.configure("-relief sunken -background white");
  	canvas.geometry(200,100);
  	
  	scrollbar scrollx = new Scrollbar(root,"scrollx");
  	scrollx.orient("horizontal");
  	scrollx.pack("-side bottom -fill x -expand 0");
  	
  	scrollbar scrolly = new Scrollbar(root,"scrolly");
  	
  	scrolly.orient("vertical");
  	scrolly.pack("-side right -fill y -expand 0");
  	
  	canvas.pack("-side top -fill both -expand 1");
  	
  	canvas.xscroll(scrollx); scrollx.xview(canvas);
  	canvas.yscroll(scrolly); scrolly.yview(canvas);
  	}
  
  };

The various modes supported by the drawing tool are enumerated as final constants. The tablet class itself inherits from the canvas widget class. This has the advantage that it offers the full functionality of a canvas. In addition to the constructor and

operator()

function, which delegates the incoming event to the appropriate handler according to the {\em _mode} variable, it offers a function mode, which sets the mode of the canvas as indicated by its string argument, and a function init that determines the creation and geometrical layout of the component widgets. As instance variables, it contains an integer {\em _mode} variable and an array of handlers that contains the handlers corresponding to the modes supported. Although the tablet must act as a canvas, the actual tablet widget is nothing but a frame that contains a canvas widget as one of its components. This is reflected in the invocation of the canvas constructor (super). By convention, when the options parameter is

*

instead of the empty string, no actual widget is created but only an abstract widget, as happens when calling the widget class constructor. Instead of creating a canvas right away, the tablet constructor creates a top frame, initializes the actual component widgets, and redirects the eval, configure and bind invocations to the subordinate canvas widget. It then binds itself to be its own handler, which results in binding itself to be the handler for the canvas component. Note that reversing the order of calling redirect and bind would be disastrous. After that it creates the handlers for the various modes and sets the initial mode to move. The

operator()

function takes care of dispatching calls to the appropriate handler. The dispatch function must be called to pass the tk, argc and argv parameters.

The drawtool class

Having taken care of the basic components of the drawing tool, that is the toolbox, menubar and tablet widgets, all that remains to be done is to define a suitable {\em file_handler}, appropriate handlers for the various drawing modes and a {\em help_handler}. We will skip these, but look at the definition of the drawtool class instead. In particular, it will be shown how we may grant the drawtool the status of a veritable Tk widget, by defining a drawtool handler class and a corresponding drawtool widget command.


  import hush.dv.api.*;
  import hush.dv.widgets.frame;
  import hush.dv.widgets.canvas;
  
  public class drawtool extends canvas {    drawtool  


  
  widget root;
  tablet tablet;
  
  public drawtool() { System.out.println("meta handler created"); } 
  
  public drawtool(String p, String options) {
          super(p,"*");                 // create empty tablet
  	init(options);
  	}
  
  
  public int operator() {
  	System.out.println("Calling drawtool:" + _event.args(0) );
  	String[] argv = _event.argv();
  	if ("self".equals(argv[1])) tk.result(self().path());
  	else if ("drawtool".equals(argv[0]))
  		create(argv[1],_event.args(2)); 
  	else if ("path".equals(argv[1])) tk.result(path()); 
  	else if ("pack".equals(argv[1])) pack(_event.args(2));
  	else self().eval( _event.args(1) );  // send through
  	return OK;
  	}
  
  void create(String name, String options) {
  	drawtool m = new drawtool(name,options);
  	}
  
  
  void init(String options) {
  	root = new frame(path(),"-class Meta");
  
  	frame frame = new frame(root,"frame");
  
  	tablet = new tablet(frame,"tablet",options);
  
  	toolbox toolbox = new toolbox(frame,tablet);
  	menubar menubar = new menubar(root,tablet,toolbox);
  
          toolbox.pack("-side left -fill y -expand 0");
  	tablet.pack("-side left -fill both -expand 1");
  
  	menubar.pack();
  	frame.pack("-expand 1 -fill both");
  
  
  	redirect( tablet );  // the widget of interest
  	}
  };

Defining a widget command involves three steps: (I) the declaration of the binding between a command and a handler, (II) the definition of the

operator()

function, which actually defines a mini-interpreter, and (III) the definition of the actual creation of the widget and its declaration as a Tcl/Tk command. Step (I) is straightforward. We need to define an empty handler, which will be associated with the drawtool command when starting the application. The functionality offered by the interpreter defined by the

operator()

function in (II) is kept quite simple, but may easily be extended. When the first argument of the call is drawtool, a new drawtool widget is created as specified in (III), except when the second argument is self. In that case, the virtual path of the widget is returned, which is actually the path of the tablet's canvas. It is the responsibility of the writer of the script that the self command is not addressed to the empty handler. If neither of these cases apply, the function eval is invoked for

self()

, with the remaining arguments flattened to a string. This allows for using the drawtool almost as an ordinary canvas.


  	Canvas c = new DrawTool("draw","");
  	tk.bind("drawtool",c);
  	c.circle(20,20,20,"-fill red");
  	c.rectangle(30,30,70,70,"-fill blue");
  	c.pack();

In the program fragment above, the Tcl command drawtool is declared, with an instance of drawtool as its handler. (It is assumed that the tk variable refers to an instance of kit.) In this way, the drawtool widget is made available as a command when the program is used as an interpreter. In this case, the actual drawtool widget is made the handler of the command, to allow for a script to address the drawtool by calling drawtool self.

Guidelines for design

subsections:

Individual class design
Establishing invariants
An objective sense of style

Computing is a relatively young discipline. Despite its short history, a number of styles and schools promoting a particular style have emerged. However, in contrast to other disciplines such as the fine arts (including architecture) and musical composition, there is no well-established tradition of what is to be considered as good taste with respect to software design. There is an on-going and somewhat pointless debate as to whether software design must be looked at as an art or must be promoted into a science. See, for example, [Knuth92] and [Gries]. The debate has certainly resulted in new technology but has not, I am afraid, resulted in universally valid design guidelines. The notion of good design in the other disciplines is usually implicitly defined by a collection of examples of good design, as preserved in museums or (art or music) historical works. For software design, we are still a long way from anything like a museum, setting the standards of good design. Nevertheless, a compendium of examples of object-oriented applications such as [Pinson90] and [Harmon93], if perhaps not setting the standards for good design, may certainly be instructive.

Development process -- cognitive factors

model $->$ realize $->$ refine

Design criteria -- natural, flexible, reusable

abstraction -- types
modularity -- strong cohesion (class)
structure -- subtyping
information hiding -- narrow interfaces
complexity -- weak coupling

slide: Criteria for design

The software engineering literature abounds with advice and tools to measure the quality of good design. In slide 3-design-criteria, a number of the criteria commonly found in software engineering texts is listed. In software design, we evidently strive for a high level of abstraction (as enabled by a notion of types and a corresponding notion of contracts), a modular structure with strongly cohesive units (as supported by the class construct), with units interrelated in a precisely defined way (for instance by a client/server or subtype relation). Other desirable properties are a high degree of information hiding (that is narrowly defined and yet complete interfaces) and a low level of complexity (which may be achieved with units that have only weak coupling, as supported by the client/server model). An impressive list, indeed. Design is a human process, in which cognitive factors play a critical role. The role of cognitive factors is reflected in the so-called fractal design process model introduced in [JF88], which describes object-oriented development as a triangle with bases labeled by the phrases model, realize and refine. This triangle may be iterated at each of the bases, and so on. The iterative view of software development does justice to the importance of human understanding, since it allows for a simultaneous understanding of the problem domain and the mechanisms needed to model the domain and the system architecture. Good design involves taste. My personal definition of good design would certainly also involve cognitive factors (is the design understandable?), including subjective criteria such as is it pleasant to read or study the design?

Individual class design

A class should represent a faithful model of a single concept, and be a reusable, plug-compatible component that is robust, well-designed and extensible. In slide class-design, we list a number of suggestions put forward by [McGregor92].

Class design -- guidelines

only methods public -- information hiding
do not expose implementation details
public members available to all classes -- strong cohesion
as few dependencies as possible -- weak coupling
explicit information passing
root class should be abstract model -- abstraction

slide: Individual class design

The first two guidelines enforce the principle of information hiding, advising that only methods should be public and all implementation details should be hidden. The third guideline states a principle of strong cohesion by requiring that classes implement a single protocol that is valid for all potential clients. A principle of weak coupling is enforced by requiring a class to have as few dependencies as possible, and to employ explicit information passing using messages instead of inheritance (except when inheritance may be used in a type consistent fashion). When using inheritance, the root class should be an abstract model of its derived classes, whether inheritance is used to realize a partial type or to define a specialization in a conceptual hierarchy. The properties of classes, including their interfaces and relations with other classes, must be laid down in the design document. Ideally, the design document should present a complete and formal description of the structural, functional and dynamic aspects of the system, including an argument showing that the various models are consistent. However, in practice this will seldom be realized, partly because object-oriented design techniques are as yet not sufficiently matured to allow a completely formal treatment, and partly because most designers will be satisfied with a non-formal rendering of the architecture of their system. Admittedly, the task of designing is already sufficiently complex, even without the additional complexity of a completely formal treatment. Nevertheless, studying the formal underpinnings of object-oriented modeling based on types and polymorphism is still worthwhile, since it will sharpen the intuition with respect to the notion of behavioral conformance and the refinement of contracts, which are both essential for developing reliable object models. And reliability is the key to reuse!

Inheritance and invariance

When developing complex systems or class libraries, reliability is of critical importance. As shown in section contracts, assertions provide a means by which to check the runtime consistency of objects. In particular, assertions may be used to check that the requirements for behavioral conformance of derived classes are met.

Invariant properties -- algebraic laws


  class employee {    employee  


  public:
  employee( int n = 0 ) : sal(n) { }
  employee* salary(int n) { sal = n; return this; }
  virtual long salary() { return sal; }
  protected:
  int sal;
  };

Invariant


     k == (e->salary(k))->salary()

slide: Invariant properties as algebraic laws

Invariant properties are often conveniently expressed in the form of algebraic laws that must hold for an object. Naturally, when extending a class by inheritance (to define a specialization or refinement) the invariants pertaining to the base class should not be disrupted. Although we cannot give a general guideline to prevent disruption, the example discussed here clearly suggests that hidden features should be carefully checked with respect to the invariance properties of the (derived) class. The example is taken from [Bar92].

In slide object-invariant, we have defined a class employee. The main features of an employee are the (protected) attribute sal (storing the salary of an employee) and the methods to access and modify the salary attribute. For employee objects, the invariant (expressing that any amount k is equal to the salary of an employee whose salary has been set to k) clearly holds.

Now imagine that we distinguish between ordinary employees and managers by adding a permanent bonus when paying the salary of a manager, as shown in slide hidden-bonus. The reader may judge whether this example is realistic or not.

Problem -- hidden bonus


  class manager : public employee {    manager  


  public:
  long salary() { return sal + 1000; }
  };

Invariant


      k =?= (m->salary(k))->salary()

slide: Violating the invariant

Then, perhaps somewhat to our surprise, we find that the invariant stated for employees no longer holds for managers. From the perspective of predictable object behavior this is definitely undesirable, since invariants are the cornerstone of reliable software. The solution to this anomaly is to make the assignment of a bonus explicit, as shown in slide explicit-bonus.

Solution -- explicit bonus


  class manager : public employee {    manager'  


  public:
  manager* bonus(int n) { sal += n; return this; }
  };

Invariant -- restored


       k + n == ((m->salary(k))->bonus(n))->salary()

slide: Restoring the invariant

Now, the invariant pertaining to managers may be strengthened by including the effects of assigning a bonus. As a consequence, the difference in salary no longer occurs as if by magic but is directly visible in the interaction with a manager object, as it should be.

An objective sense of style

The guidelines presented by [LH89] were among the first, and they still provide good advice with respect to designing class interfaces.

Good Object-Oriented Design

organize and reduce dependencies between classes

Client

-- A method m is a client of C if m calls a method of C

Supplier

-- If m is a client of C then C is a supplier of m

Acquaintance

-- C is an acquaintance of m if C is a supplier of m but not (the type of) an argument of m or (of) an instance variable of the object of m

C is a preferred acquaintance of m if an object of C is created in m or C is the type of a global variable
C is a preferred supplier of m if C is a supplier and C is (the type of) an instance variable, an argument or a preferred acquaintance

slide: Clients, suppliers and acquaintances

Demeter

client

supplier

safe

unsafe

acquaintances

suppliers

safe


  screen->cursor()->move();

which instructs the cursor associated with the screen to move to its home position. Although screen may be assumed to be a safe supplier, the object delivered by

screen->cursor()

need not necessarily be a safe supplier. In contrast, the call


  screen->move_cursor();

does not make use of an indirection introducing a potentially unsafe supplier.

The guideline concerning the use of safe suppliers is known as the Law of Demeter, of which the underlying intuition is that the programmer should not be bothered by knowledge that is not immediately apparent from the program text (that is the class interface) or founded in well-established conventions (as in the case of using special global variables). See slide 4-demeter.

Law of Demeter

ignorance is bliss

Do not refer to a class C in a method m unless C is (the type of)


   1. an instance variable
   2. an argument of m
   3. an object created in m
   4. a global variable

Minimize the number of acquaintances!

Class transformations

lifting -- make structure of the class invisible
pushing -- push down responsibility

slide: The Law of Demeter

To remedy the use of unsafe suppliers, two kinds of program transformation are suggested by [LH89]. First, the structure of a class should be made invisible for clients, to prohibit the use of a component as (an unsafe) supplier. This may require the lifting of primitive actions to the encompassing object, in order to make these primitives available to the client in a safe way. Secondly, the client should not be given the responsibility of performing (a sequence of) low-level actions. For example, moving the cursor should not be the responsibility of the client of the screen, but instead of the object representing the screen. In principle, the client need not be burdened with detailed knowledge of the cursor class. The software engineering principles underlying the Law of Demeter may be characterized as representing a compositional approach, since the law enforces the use of immediate parts only. As additional benefits, conformance to the law results in hiding the component structure of classes, reduces the coupling of control and, moreover, promotes reuse by enforcing the use of localized (type) information.

From specification to implementation

subsections:

Designing an object-oriented system requires the identification of object classes and the characterization of their responsibilities, preferably by means of contracts.

In addition, one must establish the relationships between the object classes constituting the system and delineate the facilities the system offers to the user. Such facilities are usually derived from a requirements document and may be formally specified in terms of abstract operations on the system.

In this section we will look at the means we have available to express the properties of our object model, and we will study how we may employ abstract specifications of system operations to arrive at the integration of user actions and the object model underlying a system in a seamless way. The approach sketched may be characterized as event-centered.

Structural versus behavioral encapsulation

Object-oriented modeling has clearly been inspired by or, to be more careful, shows significant similarity to the method of semantic modeling that has become popular for developing information systems. In an amusing paper, [Ki89] discusses how semantic modeling and object-oriented modeling are related. Apart from a difference in terminology, semantic modeling differs from object-oriented modeling primarily by its focus on structural aspects, whereas object-oriented modeling is more concerned with behavioral aspects, as characterized by the notion of responsibilities.

Structural versus behavioral encapsulation

semantic model object-oriented

abstraction structural behavioral

inheritance subtypes subclasses

	semantic model	object-oriented
abstraction	structural	behavioral
inheritance	subtypes	subclasses

Semantic modeling -- constructing types

aggregation, grouping by association

slide: Semantic modeling

Typically, semantic modeling techniques provide a richer repertoire for constructing types, including a variety of methods for aggregation and a notion of grouping by association. See slide 3-semantic. The object-oriented counterpart of aggregation may be characterized as the has-a or part-of relation, that is usually expressed by including the (part) object as a data member. Associations between objects cannot be expressed directly in an object-oriented framework. On an implementation level, the association relation corresponds to membership of a common collection, or being stored in the same container. However, the absence of an explicit association relation makes it hard to express general m-n relations, as, for example, the relation between students and courses.

Object-oriented modeling

is-a -- inheritance
has-a, uses -- delegation
uses -- templates

slide: Relations between objects

The influence of a semantic modeling background can be clearly felt in the OMT method. The object model of OMT is a rather direct generalization of the entity-relationship model. Entities in the entity-relationship model may only contain (non-object) data members, which are called attributes.

In contrast, objects (in the more general sense) usually hide object and non-object data members, and instead provide a method interface. Moreover, object-oriented modeling focuses on behavioral properties, whereas semantic modeling has been more concerned with (non-behavioral) data types and (in the presence of inheritance) data subtypes.

Relations, as may be expressed in the entity-relationship model, can partly be expressed directly in terms of the mechanisms supported by object-oriented languages. For instance, the is-a relation corresponds closely (although not completely) with the inheritance relation. See slide 3-challenges. Both the has-a and uses relation is usually implemented by including (a pointer to) an object as a data member. Another important relation is the is-like relation, which may exist between objects that are neither related by the inheritance relation nor by the subtype relation, but yet have a similar interface and hence may be regarded as being of analogous types. The is-like relation may be enforced by parametrized types that require the presence of particular methods, such as a compare operator in the case of a generic list supporting a sort method.

Model-based specification

State and operations

$state == [ decls | constraints ]$
$op == [ %D state; decls | constraints ]$

Change and invariance

$ %D state == state /\ state' $
$ %X state == state = state' $

Verification

$ state /\ pre( op ) => op $

slide: Model-based specification

Several development methods, including Responsibility Driven Design and Fusion (see section Fusion), allow for the specification of user interactions in a semi-formal way by means of pre- and post-conditions. These approaches have been inspired by model-based specification methods such as VDM and Z, which offer a formal framework for specifying the requirements of a system. Model-based specification methods derive their name from the opportunity to specify a mathematical model capturing the relevant features of the system. Operations, which may correspond to user actions, can then be specified in a purely logical way.

In the following, an outline of the specification language Z will be given. More importantly, the specification of a simple library system will be discussed, illustrating how we may specify user actions in an abstract way. (The use of the Z specification language is in this respect only of subsidiary importance.) In the subsequent section, we will look at the realization of the library employing an abstract system of objects and events corresponding to the user actions, which reflects the characterization given in the formal specification. The specification language Z is based on classical (two-valued) logic and set theory. It has been used in a number of industrial projects, [Hayes92], and to specify the architecture of complex intelligent systems, [Craig91]. The central compositional unit of specification in Z is the schema. A schema may be used to specify both states and operations in a logical way. The logic employed in Z is a typed logic. The specification of a schema consists of a number of declarations followed by constraints specifying conditions on the variables introduced in the declarations. Declarations may include other schemas, as in the example specification of the operation op. The schema $%D state$ itself is a compound schema that results from the logical conjunction of the schema state and its primed version $state'$, which denotes state after applying op. Both schema inclusion and schema conjunction are examples of the powerful schema calculus supported by Z, which enables the user to specify complex systems in Z. Moreover, schemas may be decorated to specify the effects of an operation. Invariance may be specified as in $%X state$, which expresses that the state before applying the operation is the same as the state (denoted by $state'$) after applying the operation. Since schemas are specified in a logical manner, both pre- and post-conditions are implicitly specified by the constraints included in the schema. Hence, to verify that an operation op is legal for a state it is merely required to verify that the conditions specified for state hold, and that, together with the pre-conditions (which are implicitly specified by the schema for op), they imply the logical formula characterizing op. See slide 10-model.

State

Counter

  
  \begin{schema}{Counter}
  n : \nat
  \where
  n \geq 0
  \end{schema}

Operations

  
  \begin{schema}{Incr}
  \Delta Counter
  \where
  \mbox{ $ n' = n + 1 $ }
  \end{schema}
  
  \begin{schema}{Decr}
  \Delta Counter
  \where
  n > 0 \\
  \mbox{ $ n' = n - 1 $ }
  \end{schema}

slide: The specification of a Counter in Z

An important property of Z is that it allows for a graphical layout of schemas, as illustrated in the specification of a Counter given in slide z-ctr. The state of a Counter is given by the Counter schema declaring an integer variable n, which is constrained by the condition $ n \geq 0 $. The operations Incr and Decr are specified by defining the state following the operation by, respectively, $ n' = n + 1 $ and $ n' = n - 1 $. Both operations require the declaration $%D Counter$ to indicate that the state specified by Counter will be modified. In addition, the operation Decr requires as a pre-condition that $n > 0$, needed to prevent the violation of the invariant, which would happen whenever n became less than zero.

Counter


   $Counter \defs [ n : \nat | n \geq 0 ] $
   $Counter::Incr \defs [ \%D Counter, v? : \nat | n' = n + v? ]$
   $Counter::Decr \defs [ \%D Counter | n > 0;  n' = n - 1 ]$
   $Counter::Value \defs [ \%X Counter; v! : \nat | v! = n ]$

Bounded counter


   $Bounded::Counter \defs [ Counter | n \leq Max ]$
   $Bounded::Incr \defs [ Counter::Incr | n < Max ]$

slide: An alternative specification of the Counter

An alternative specification of the Counter is given in slide z-ctr-2. To emphasize that we may regard the Counter as an object, the operations have been prefixed by Counter in a C++-like manner. This is only a syntactic device, however, carrying no formal meaning. In addition, both the operations Incr and Decr declare an integer variable $v?$ which acts, by convention, as an input parameter. Similarly, the integer variable $v!$ declared for the operation value acts, again by convention, as an output parameter. Since Z allows the inclusion of other schemas in the declaration part of a schema, we may easily mimic inheritance as illustrated in the specification of $Bounded::Counter$, which is a Counter with a maximum given by an integer constant Max.

Similarly, we may specify the operations for the $Bounded::Counter$ by including the corresponding operations specified for the Counter, adding conditions if required.

From a schema we may easily extract the pre-conditions for an operation by removing from the conditions the parts involving a primed variable. Clearly, the post-condition is then characterized by the conditions thus eliminated.

For example, the pre-condition of the $Counter::Incr$ operation is $v? \geq 0$, whereas the post-condition is $n' = n + v?$ which corresponds to the implementation requirement that the new value of the Counter is the old value plus the value of the argument $v?$. In a similar way, the pre-condition for applying the $Bounded::Incr$ operation is $n + v? \leq Max$. Note, however, that this pre-condition is stronger than the original pre-condition $v? \geq 0$, hence to conform with the rules for refinement we must specify what happens when $ n + v? > Max $ as well. This is left as an exercise for the reader.

Clearly, although Z lacks a notion of objects or classes, it may conveniently be employed to specify the behavior of an object. In [Stepney], a number of studies are collected which propose extending Z with a formal notion of classes and inheritance. The reader interested in these extensions is invited in particular to study Object-Z, OOZE and Z++. As an historical aside, we may note that Z has been of significant influence in the development of Eiffel (see Meyer, 1992b). Although the two approaches are quite divergent, they obviously still share a common interest in correctness.

In contrast to Eiffel, which offers only a semi-formal way in which to specify the behavior of object classes, Z allows for a precise formal specification of the requirements a system must meet. To have the specification reflect the object structure of the system more closely, one of the extensions of Z mentioned above may be used. An example of using (plain) Z to specify the functionality of a library system is given below.

The specification of a library

Imagine that you must develop a program to manage a library, that is keep a record of the books that have been borrowed.

State

Library (1)

  
  \begin{schema}{Library}
  books : \power Book \\
  borrowed : Book \pfun Person
  \where
  \dom borrowed \subseteq books
  \end{schema}

slide: The specification of a library

Before developing a detailed object model, you may well reflect on what user services the library must provide. These services include the borrowing of a book, returning a book and asking whether a person has borrowed any books, and if so which books. These operations are specified by the schemas Borrow, Return and Has in slide z-lib-2.

Operations

Library (2)

  
  \begin{schema}{Borrow}
  \Delta Library; b? : Book; p? : Person
  \where
  b? \not\in \dom borrowed \\
  b? \in books \\
  borrowed' \mbox{ $ = $ } borrowed \cup { b? \mapsto p? }
  \end{schema}
  
  \begin{schema}{Return}
  \Delta Library; b? : Book; p? : Person
  \where
  b? \in \dom borrowed \\
  borrowed' \mbox{ $ = $ } borrowed \hide { b? \mapsto p? }
  \end{schema}
  
  
  \begin{schema}{Has}
   \Xi Library; p? : Person; bks : \power Book
  \where
  bks! \mbox{ $ = $ } borrowed ^{-1} \limg { p? } \rimg
  \end{schema}
  
slide: The library operations

Don't be frightened of the mathematical notation in which these operations are specified. The notation is only of secondary importance and will be explained as we go along. Since we are only interested in the abstract relations between people and books, we may assume Book and Person to be primitive types. The specification given in slide z-lib-1 specifies an abstract state, which is actually a partial function delivering the person that borrowed the book if the function is defined for the book. The function is partial to allow for the situation where a book has not been borrowed, but still lies on the shelves. The invariant of the library system states that the domain of the function borrowed must be a subset of the books available in the library. Given the specification of the state, and some mathematical intuition, the specification of the operations is quite straightforward. When a Borrow action occurs, which has as input a book $b?$ and a person $p?$, the function $borrowed'$ is defined by extending borrowed with the association between $b?$ and $p?$, which is expressed as the mapping $b? |-> p?$. As a pre-condition for Borrow, we have that borrowed must not be defined for $b?$, otherwise some person would already have borrowed the book $b?$. The Return action may be considered as the reverse of the Borrow action. Its pre-condition states that borrowed must be defined for $b?$ and the result of the operation is that the association between $b?$ and $p?$ is removed from $borrowed '$. Finally, the operation Has allows us to query what books are in the possession of a person $p?$. The specification of Has employs the mathematical features of Z in a nice way. The output, which is stored in the output parameter $bks!$, consists of all the books related to the person $p?$. The set of books related to $p?$ is obtained by taking the relational image of the inversion of borrowed for the singleton set consisting of $p?$, that is, each book x for which an association $ x |-> p? $ is in borrowed is included in the set $bks!$. Again, it is not the notation that is important here, but the fact that the specification defines all top-level user interactions.

Abstract systems and events

User actions may require complex interactions between the objects constituting the object model of a system. Such interactions are often of an ad hoc character in the sense that they embody one of the many possible ways in which the functionality of objects may be used. What we need is a methodology or paradigm that allows us to express these interactions in a concise yet pragmatically amenable way. In [Henderson93], a notion of abstract systems is introduced that seems to meet our needs to a large extent. See slide 3-abstract.

Abstract systems -- design methodology

abstract system = abstract data types + protocol

Events -- high level glue

realization of the interaction protocol

slide: Abstract systems and events

Abstract systems extend the notion of abstract data types to capture the (possible) interactions between collections of objects. The idea underlying the notion of an abstract system is to collect the commands available for the client or user of the system. The collection of commands comprising an abstract system are usually a (strict) subset of the commands available in the combined interface of the abstract data types involved. In other words, an abstract system provides a restricted interface, restricted to safeguard the user from breaking the protocol of interaction implicitly defined by the collection of abstract data types of which the system consists. An abstract system in itself merely provides a guideline on how a collection of objects is to be used, but does not offer a formal means to check whether a user plays by the rules. After presenting an example of an abstract system, we will look at how events may be used to protect the user against breaking the (implicit) laws governing the interaction.

Example -- the library

The abstract system comprising a library may be characterized as in slide 3-library. In essence, it provides an exemplary interface, that is, it lists the statements that are typically used by a client of the library software. We use typical identifiers to denote objects of the various types involved.

Abstract system -- exemplary interface

library


  p = new person();
  b = new book();
  p = b->borrower;
  s = p->books;
  tf = b->inlibrary();
  b->borrow(p);
  p->allocate(b);
  p->deallocate(b);
  b->_return(p);

For person* p; book* b; set<book>* s; bool tf;

slide: The library system

The commands available to the user of the library software are constructors for a person and a book, an instruction to get access to the borrower of a particular book, an instruction to ask what books a particular person has borrowed, an instruction to query whether a particular book is in the library, and instructions for a person to borrow or return a book. To realize the abstract system library, we evidently need the classes book and person. The class book may be defined as follows.


  class book {    book  


  public:
  person* borrower;
  book() {}
  void borrow( person* p ) { borrower = p;  }
  void _return( person* p ) { borrower = 0; }
  bool inlibrary() { return !borrower; }
  };

It consists of a constructor, functions to borrow and return a book, a function to test whether the book is in the library and an instance variable containing the borrower of the book. Naturally, the class book may be improved with respect to encapsulation (by providing a method to access the borrower) and may further be extended to store additional information, such as the title and publisher of the book.


  class person {    person  


  public:
  person() { books = new set(); }
  void allocate( book* b ) { books->insert(b); }
  void deallocate( book* b ) { books->remove(b); }
  set* books;
  };

The next class involved in the library system is the class person, given above. The class person offers a constructor, an instance variable to store the set of books borrowed by the person and the functions allocate and deallocate to respectively insert and remove the books from the person's collection. A typical example of using the library system is given below.


  book* Stroustrup = new book();  example


  book* ChandyMisra = new book();
  book* Smalltalk80 = new book();
  
  person* Hans = new person();
  person* Cees = new person();
  
  Stroustrup->borrow(Hans);
  Hans->allocate(Stroustrup);
  ChandyMisra->borrow(Cees);
  Cees->allocate(ChandyMisra);
  Smalltalk80->borrow(Cees);
  Cees->allocate(Smalltalk80);

First, a number of books are defined, then a number of persons, and finally (some of) the books that are borrowed by (some of) the persons.

Note that lending a book involves both the invocation of $book::borrow$ and $person::allocate$. This could easily be simplified by extending the function $book::borrow$ and $book::_return$ with the statements $p->allocate(this)$ and $p->deallocate(this)$ respectively. However, I would rather take the opportunity to illustrate the use of events, providing a generic solution to the interaction problem noted.

Events

[Henderson93] introduces events as a means by which to control the complexity of relating a user interface to the functionality provided by the classes comprising the library system. The idea underlying the use of events is that for every kind of interaction with the user a specific event class is defined that captures the details of the interaction between the user and the various object classes. Abstractly, we may define an event as an entity with only two significant moments in its life-span, the moment of its creation (and initialization) and the moment of its activation (that is when it actually happens). As a class we may define an event as follows.


  class Event {      Event    


  public:
  virtual void operator()() = 0;
  };

The class Event is an abstract class, since the application operator that may be used to activate the event is defined as zero.


  class Borrow : public Event {    Borrow  


  public:
  Borrow( person* _p, book* _b ) { _b = b; _p = p; }
  void operator()() {
  	require( _b && _p ); // _b and _p exist
  	_b->borrow(p);
  	_p->allocate(b);
  	}
  private:
  person* _p; book* _b;
  };

For the library system defined above we may conceive of two actual events (that is, possible refinements of the Event class), namely a Borrow event and a Return event.

The Borrow event class provides a controlled way in which to effect the borrowing of a book. In a similar way, a Return event class may be defined.


  class Return : public Event {    Return  


  public:
  Return( person* _p, book* _b ) { _b = b; _p = p; }
  void operator()() {
  	require( _b && _p );
  	_b->_return(p);
  	_p->deallocate(b);
          }
  private:
  person* _p; book* _b;
  };

The operation Has specified in the previous section has an immediate counterpart in the $person::books$ data member and need not be implemented by a separate event.

Events are primarily used as intermediate between the user (interface) and the objects comprising the library system. For the application at hand, using events may seem to be somewhat of an overkill. However, events not only give a precise characterization of the interactions involved but, equally importantly, allow for extending the repertoire of interactions without disrupting the structure of the application simply by introducing additional event types.

Summary

This chapter looked at application development. We started with a simple example and subsequently discussed guidelines for class design. We then looked at a more formal approach, involving the transition from a formal specification to the actual implementation based on a notion of abstract systems and events.

The drawtool application

drawing canvas -- in hush
drawtool -- compound widgets

slide: Section 4.1: The drawtool application

In section 1 we looked at how to develop applications in hush, as a typical example of inplementing an interactive editor.

Guidelines for design

individual class design
establishing invariants
an objective sense of style

slide: Section 4.2: Guidelines for design

In section 2, some guidelines for design were presented. We looked at issues that may arise when attempting to establish class invariants. Finally, we discussed the rules imposed by the Demeter method.

From specification to implementation

structure versus behavior
model-based specification
abstract systems

slide: Section 4.3: From specification to implementation

In section 3, we discussed the distinction between structural and behavioral aspects of a system. We looked at the application of formal methods to specify the requirements for a system, and we studied an implementation based on abstract systems and events which was derived from the original formal specification.

Questions

Give an example of your choice to describe OO application development.
Discuss possible guidelines for individual class design.
Discuss how inheritance may affect class invariants.
What would be your rendering of the Law of Demeter? Can you phrase its underlying intuition? Explain.
Define the notions of client, supplier and acquaintance. What restrictions must be satisfied to speak of a preferred acquaintance and a preferred supplier?
Characterize the differences between semantic modeling and object-oriented modeling.
How would you characterize the notion of abstract systems?
Explain how events may be employed to maintain system integrity. Give an example!