End Game

Design thinking... This is from http://members.aol.com/acockburn/papers/endgame/endgame.htm, which describes the first half of the EndGame strategy. The first half describes the thinking; the second half will place the strategy into a context of design strategies.

There are times when you are not completely sure whether you will or will not use an object-oriented server. What do you do when your OO designers design in a relational mindset, or you might change technologies on the server (relational / OO)?

We had lots of OO-novices. Our assignment was to get OO newcomers to produce decent designs consistently, and protect the fact that the database might suddenly change from relational to object. The workstation design should be sound to start with, and stay that way, whatever happened to the server's database.

We found the EndGame design process compelling. It gave us a simple way of working, which new OO designers could use. The steps of the solution, illustrated on the "Account" situation, are:

1. Define the client-interface requirements on the workstation class(es).

2. Pretend the server simply does not exist, and create a good, OO, workstation-only design.

3. Add distribution concerns and define the workstation's interface requirements on the server.

4. Defer the server's internal design to its design team.

The pattern is interesting for people on a project, but what interests me more is the approach of design strategies. I am trying to place EndGame in the context of Polya's "How To Solve It" heuristics, Dijkstra's (EwDijkstra) program derivation techniques, CRCCards, and others. I'll post when I get the second half of the work done :-)

-- AlistairCockburn

Is the "second half of the work done"? 20020903

I guess he's forgotten about it. 20060823