Copyright 1995-2001 by Bytesmiths. All rights reserved.

Please patronize sponsors of this page!

Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!

• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Crafted By Carol -- handcrafted jewelry and beadwork
• All in the Memory -- bookkeeping services
• Dymond Graphics -- note cards, pet/people photography
• Village of Willamette Arts Festival -- annual visual/performing arts festival, September 23/24, 2001

Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.

Client-Server Technical Architecture, Team 5

Team members

• Jana Kjebon, Telia Data AB
• Ned Konz
• Jim Wood, Siemens
• Grady Booch (moderator)
• Elizabeth Hanes Perry (recorder)

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

• 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

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.