Chapter 11

Chapter 11. Miscellany.

Philosophy

Interfaces

Generic

Hotspots

Graph

Workflow

Reporting

Drawing

Graph

G = <N,E>

N & E = 0

E = <N,N>

Graph - Node - Edge

================================

Graph

1. Graph

Enumeration getEdges()

Enumeration getNodes()

boolean isMember(Node)

boolean isMember(Edge)

int getEdgeCount()

int getNodeCount()

Node

Object getUserObject()

void setUserObject()

Edge

Object getUserObject()

void setUserObject()

Node getFromNode()

Node getToNode()

2. Node

Enumeration getIncomingEdges()

Enumeration getOutgoingEdges()

3. Graph

boolean isValid()

4. Graph

Mutable

addNode(Node)

removeNode(Node)

addEdge(Edge)

removeEdge(Edge)

Edge

Mutable ??

setFromNode()

setToNode()

5. Node

inNodes

outNodes

6. Graph

throws??

Decisions -

* Add edges to the nodes or the graph?

* Should createNode() and createEdge () be factory methods on Graph?

* Implementations - Node could have list of outnodes (with implicit edges), or perhaps independent nodes & edges in a bitarray.

Graph Applications:

Workflow

Bug-tracking

Trouble tickets

Student registration

DRAWING TOOL

Figure

bounds

position

draw

dependents

contains

Handle

Canvas

Tool

BACKGROUND THINKING

Frameworks in the small:

* Interface - trace specs Hoffman??

* Specsmanship - model

* Parnas

* Booch

* Meyer

FINAL GRAPH

Node

Object getUserObject()

void setUserObject(Object o)

Enum getInEdges(), getOutEdges()

Enum getInNodes(), getOutNodes()

Edge

Node getFromNode()

Node getToNode()

Object getUserObject() *

void setUserObject(Object o) *

* implications for independent representation

Graph

Enum getEdges()

Enum getNodes()

int getEdgeCount()

int getNodeCount()

bool isMember(node)

bool isMember(edge)

bool isValid()

MutableGraph - subtype

createNode([uo])

createEdge([uo])

removeNode(n)

removeEdge(e)

throw graph change exception??

OUTLINE

I. What is a framework?

Philosophy - generic, interface, hotspots

definitions

II. Graph - mini-framework

Domain - sample uses

Dimensions of flexibility

First few cuts - multiple implementations

Frameworks in the small

Final framework - code

Sample uses

web checker

traffic simulator

UML Diagrammer

Use of packages

INTERLUDE: Frameworks in the small

III. Patterns and Swing

IV. Workflow

Layered framework

model

framework

design patterns - policy vs implementation, strategy

uses

bug tracker

student registration

trouble tickets

V. Reporting

Predicate / Result

Groups

VI. Drawing

Separate framework

Connect to graph

VII. Assembly

VIII. Growth, Delivery, Engineering

HOFFMAN - FRAMEWORKS in the SMALL

* Consistent: "with partial knowledge, the remainder of the system can be predicted"

* Essential - omit needless features

* General: Open-ended (future expansion) and complete (all functions of class)

* Minimal - independent features are separate

* Opaque - information hiding. Each module hides a secret. The module needn't change its interface even if the secret changes.

Application:

Pop combines pop and top - bad

ungetc combines get and advance - bad

graph - node & edge deletion

combining get/set generally bad

Graph interface

Function Input Output Exceptions

s_init int - maxnodes

g_numnodes - int

----------------------------------------------------------

s_addnode int - nodenum, exnode

s_delnode int - notexnode

g_exnode int bool

----------------------------------------------------------

s_addedge int - exedge, len

int

real

s_deledge int - notexedge

int

g_exedge int bool

int

g_edgelen int real notexedge

int

----------------------------------------------------------

g_expath int bool

int

g_pathlen int real notexpath

int

g_firststep int int notexpath

int

--------------------------------------------------------

Note: ex=exist, g=get, s=set

Abstract Data Types

Completeness

Each method defined for each representation

Consequence

Does it accept null?

Does it return null?

Can args have illegal values eg out of range?

WHAT IS A GRAPH?

We aren't doing this to provide a pure mathematical graph: we're doing it so we can apply the idea of a graph to real problems. This leads us to other considerations:

* We have information to attach to nodes and edges

* Edge from node to itself?

* Do we want multiple occurrences of an edge? (Classical def doesn't allow it.)

* Are our graphs mutable or immutable? We might like to distinguish these cases.

* Do we want constraints on our graph? (eg connected or non-cyclic)

From our sample domains, we see the need to handle these cases:

* We need to attach information to both nodes and edges. Every application we examined could take advantage of this.

* We will allow multiple occurrences of edges. When an edge has extra information, it's not merely recording connectivitiy, it's attaching ther info to the edge, and many sets of information could connect two nodes.

* Mutable/immutable is a useful distinction. (Example jdk1.2 collections) Many situations may have an expensive construction stage, followed by read-only use.

* Validity of the graph is important. This may be useful in allowing for multiple implementations. Some can take advantage of limited graph structure.

APPROACH

Graph class

Develop class - subclass to use - critique interface

From class to framework

Move to interface - black-box via adding userObject

HOFFMAN _ BAD GRAPH

Function Input Output Exceptions

s_init int - maxnodes

g_numnodes - int

g_inf - real *1

s_addedge int - nodenum, len, src_q_dst

int

real

g_visited int real *2

int

g_pathlen int real

g_firststep int int notexpath

int

g_edgelen int real notexedge *3

int

*1 Infinity > any path length

*2 True if edge for node

*3 Length s to d, or g_inf if no path.

Notes: Assumes edge of length 0 between any node and itself.

Method g_first_step returns the first node in the shortest path to d. Pass in the previous result to compose a path.

Problems:

1. Can't add node without edges present

2. "self-loop" on node is a pain

3. Pathlen - can't find edge without also finding the path

4. No deletion except s_init

GRAPH CLASS - NOTES

Now - this is not a terrible class.

But there are things that can be improved.

Three things stand out:

2. The "name" field is in all subclasses - but some won't need it. Furthere - it's there as a public field - it should at least be wrapped. Probably best to remove it completely.

Guidelines:

Don't make subclasses pay for extra baggage

List of nodes:

Let's make them enumerations.

String name - remove it. Let subclasses add it if they need it.

// v0.2

public class Node {

private Vector nodes;

public void addEdge (Node n)

public void removeEdge(Node n)

public Enumeration getNodes()

public Enumeration pathTo(Node n)

}

PULLING OUT THE ABSTRACTION

The graph case is "easy", because we have the mathematical model to fall back on.

First, we see there is a class for Nodes, but none for the graph as a whole, so we'll add

public class Graph {

public Enum getNodes()

public void addNode(Node n)

public Enum getNodeCount()

public void removeNode(Node n)

}

Second, we may want edges to be explicit. This may make our overall representation a little more expensive, but we have information we need to associate with edges.

public class Edge {

public Node getFromNode()

public Node getToNode()

Edge(Node n1, Node n2)

}

We'd like to be able to look at all edges in the graph:

getEdges()

getEdgeCount()

Where do we add edges - the node or the graph? Probably want to add them to the graph.

add(edge)

remove(edge)

add(node)

remove(node)

Multiple implementations are a consideration.

GROWING INTO A FRAMEWORK

* Indepdent of implementation - strong barrier

* Inversion of control (vs library)

* Extensible - black-box

IDEAS

* Adapter classes

* Frameworks

* Pree - Hot spots

GUIDELINES

Rules - Interface

* Avoid getter/setter functions

* Look for missing abstractions

* Pre/post-conditions

* Defined behavior for all arguments (eg null)

* Consistency

* Independent features are separate (minimal)

* What's the secret?

* Don't expose attributes

* Essential: omit needless features

* General: open-ended and complete

Closed set - native types or frameworks'

Guidelines - framework

* Abstract classes

* Black-box, white-box

* Library

* Flow of control

* Hot spots

* Don't make subclasses pay for what they don't use (cost ala carte)

* Implementation -independent

* Class relationships to base class

* Seek models - steal ideas

Patterns in frameworks

* Template method

* Factory

* Composite

* Decorator

* Strategy

Lifetimes

* Expand/contract

* Release

* Testing

PATTERNS IN AWT

MVC/Event-Observer

Event mechanism

PLAF

Composite

JComposite -> Container

Flyweight

Border

Decorator

Border (Compound Border)

Template Method

JComponent paint, paintComponent, etc.

Strategy

LayoutManager

Factory Method

DateFormat

Interpreter

SimpleDateFormat

REPORTS

Query

Format

Accumulators

By type

By date

By page

References

Schmidt, Douglas. Using Design Patterns to Develop Reusable Object-Oriented Software. ACM Computing Surveys, 28(4), December, 1996.

J. Vlissides. Subject Oriented Design. C++ Report, Feb., 1998.

Harrison & Ossher. Subject-Oriented Programming. OOPSLA '93.

Testing OO

R.M. Poston. Automated Testing from Object Models. CACM Sept'94, v37 #9, pp 48-58.

G. Rothermel & M.J.Harrold. Selecting Regression[s] Tests for Object-Oriented Software. Proc Conf Software Maintenance, IEEE, 1994, pp 14-25.

D.E. Perry & G.E. Kaiser. Adequate Testing and Object-Oriented Programming. JOOP 1990 2(5) pp 13-19.

Sept '94 CACM. Special issue on object-oriented testing.

Jacobson. OOSE.

Marrick. The Craft of Software Testing.

McGregor. Object-oriented Software Development.

Siegel. Object-Oriented Software Testing.

Object Magazine. Pattern Language for Testing Object-Oriented Software. V5 #8 Jan'96. pp 32-38. "PLOOT" - Firesmith.

CACM Oct. '97 - Special issue on frameworks

Framework-Based Software Development in C++

Gregory F. Rogers, Jan. '97

CACM Oct' 96

Special issue on patterns

References

Online (URLs)

Books

Articles

Winograd/Flores

Reflection in Action