Client-Server Technical Architecture, Team 5

Team members

History

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

  1. List open issues from spec
  2. Determine scope
  3. Discuss impressions
  4. Initial modeling
  5. Discuss model with other teams
  6. 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

  1. One client is connected to at most one server at a time. [The customer later refuted this assumption.]
  2. 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.
  3. A single client may have more than one session. [Replaced Assumption 1.]
  4. All calculated columns (columns that represent behavior rather than aspects) are easily & quickly calculated on the server.
  5. Deletion or insertion of a row forces a window update on the client.
  6. 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

Client Side

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

  1. Client updates row on server
  2. 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

  1. User updates thin client (use case 3)
  2. 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.


Report by Elizabeth Hanes Perry.