Client-Server Technical Architecture, Team 5

Team members

History

The team began by reading through the problem.
They then chose mileposts for the afternoon:

List open issues from spec

Determine scope

Discuss impressions

Initial modeling

Discuss model with other teams

Design architecture

As happens frequently in real life, the allotted time expired before all the
mileposts were achieved.

Ward Cunningham, playing the customer, visited the room and answered the
team's questions about the problem's scope. After he left, the team discussed
the problem further. It quickly became clear that the team needed an assumptions
list that documented our understanding of the problem.

Assumptions

One client is connected to at most one server at a time. [The customer
later refuted this assumption.]

Replication is a secondary effect of the existing fat-client architecture;
we assume that updates to one server are automatically propagated in a timely
fashion.

A single client may have more than one session. [Replaced Assumption 1.]

All calculated columns (columns that represent behavior rather than
aspects) are easily & quickly calculated on the server.

Deletion or insertion of a row forces a window update on the client.

Transmission of client-server traffic is out of scope.

The team agreed that they were ready to begin designing objects. They began
creating objects as CRC cards on Post-It Notes, so that the objects could be
rearranged on the notepad as the design matured. The CRC cards never progressed
beyond naming classes; class responsibilities were agreed on during discussion,
but never written down. After the initial objects were identified, the team
sketched rough UML-like static diagram showing the objects and their
relationships.

A major stumbling block for the team was finding good nouns for class
identifiers. The team agreed that a good class name saves a lot of trouble down
the road, since it suggests (and sometimes embodies) the class's
responsibilities. Several of the class names selected were "for want of
something better", and would have been superseded had time and inspiration
permitted.

The final class list was:

Server Side

Session Manager

Session (holds client ID and date of last update)

Business Model

Row Filter (holds total rows, sort, and which rows client uses)

View Selection

Business View

Client Side

Row Filter (proxy for Session class)

View Selection (proxy for Session class)

Business View (proxy for Session class)

Window

Client Session

Scroll Command

Viewed Row

Ward came in for a second consultation. He blew away Assumption (1) by
explaining that there were multiple windows on each thin client.

At this point (3:30 PM), the teams broke up and rotated visiting the other
teams addressing the same problem. One interesting insight from this visit was
that another client-server team said "Hey, wait a minute, the client told
us that there would never be new rows added to the window!". We
agreed that this was typical client behavior.

When the team re-convened, they set a new pair of goals: by 4PM, they wanted
to have an interaction diagram, a sequence diagram, and a class diagram; by 5
PM, they wanted to have a validated architecture created by testing these
diagrams against the use cases.

The team divided on how to attack the problem; eventually, the moderator
suggested that they begin doing sequence diagrams of the use cases, and that
this would drive out issues.

After completing one-and-a-half sequence diagrams, the team noticed that it
was 4 PM, and decided to reexamine their strategy. The team created an Open
Issues list:

Open Issues

Client updates row on server

Client changes sort order

They decided to pick only the most critical use cases and concentrate on
those. Of the remaining use cases, the most urgent were

User updates thin client (use case 3)

Server inserts new row into client.

After the final visit from Ward, the team decided to do as many sequence
diagrams as possible in the remaining time. The team created a sequence diagram
of use case 1, client opens a window on the server and then exits. In rapid
sequence, the team created sequence diagrams for client closes window (end of
case 1) and client scrolls through window (case 2). Before we knew it, 5:00 had
arrived and the session was over. There was no time to draw conclusions or
discuss lessons learned.