This chapter is from the book
This chapter is from the book
This chapter is from the book
Why Tell a Design Story?
We suggest you create a framework for searching for potential candidates by writing a story about your application. After you’ve done this, the candidates you identify should fall into place and support various aspects of your story. When you state things in your own words, you get to decide what’s important. Everybody may have been talking about what your design should do and what will make it great, but you should make a few bold statements of your own. In this design story, identify the things about your application that you know with certainty, as well as things you don’t yet know. Rather than being driven by one particular view of your software—whether it be use cases, requirements, architecture, users, or sponsors—pull together all these factors and craft your own description.
Write a rough story—two paragraphs or less is ideal. Don’t take a lot of time revising and polishing it. Be quick and to the point. What is notable about your application? What is it supposed to do? How will it support its users? Is it connected to a real-world example that you can study? Have you done something similar? What will make your design a success? What are the most challenging things to work out? What seems clear? What seems ill defined? You need not answer all these questions. Simply write about the critical aspects of your application. If it helps you make your point, draw a rough sketch or two. Focus on the main ideas.
If you are a member of a larger design team, write your own story first and then share it with your team. See how your concerns differ from others’. The team can draft a single, unified story, but this isn’t necessary. More importantly, identify the important themes in these design stories. Then look for candidates that support these themes.
Here are two design stories that were written quickly. The first one rambles. It tells of an online banking application:
This application provides Internet access to banking services. It should be easily configured to work for different banks. It should support fast access to banking services for potentially thousands of users at a time. There is a limited number of software resources, such as database connections and connections to backend banking software, that are available. A critical element in the design is the declaration of a common way to call in to different backend banking systems and a reliable means of sharing scarce resources. We will define a common set of banking transactions and a framework that will call into banking-specific code that “plugs into” the standard layer implementing the details. The rest of our software will only interface with the bank-independent service layer.
We’ve developed a prototype implementation of this layer and have configured it to work for two different banks. Although it is still a prototype, we understand how to write a common banking service layer. Lately, our bank has been busy acquiring other banks and integrating their software. We’ve been through three system conversions in the past year. We want to focus on making this service layer easy to implement and test. At the heart of our system is the ability to rapidly configure our application to work for different backends and to put a different pretty face on each. This includes customizing screen layouts, messages, and banner text. The online banking functions are fairly simple: Customers register to use the online banking services and then log in and access their accounts to make payments, view account balances and transaction histories, and transfer funds. This is straightforward, easy to implement. There is added complexity. Customers record information and notes about each online transaction. This extra information will be maintained by our application in its own database because preexisting bank software has no way to store it. We want a customer to view human-readable information, not ancient bank software detailed transaction records. When a customer asks to view an account’s transaction history we’ll have to merge this data with records supplied from the backend software. Multiple users can access a customer’s accounts, each with potentially different access rights. Certain users might have no access to sensitive accounts. A company executive might view only account balances, whereas a clerk in the accounts payable department could make payments and a comptroller might be able to transfer funds between accounts.
This next, more focused, story is about a Web-based game. It describes new design challenges as well as, to us, familiar territory:
This game playing application supports an Internet variant of chess called Kriegspiel. Kriegspiel is a chess version of the popular game Battleship. The novelty is that players make moves not knowing where their opponent’s pieces are located. Our immediate concern is how to distribute responsibilities among major software components. In this distributed application, we need to consider time lags and limited communication bandwidth between architectural components. We also need to consider the unpredictability of Internet communications. Each player interacts with our application via a Web browser. Hundreds of games can be played simultaneously. A user logs in and requests to play a game with another. If no one is available, the user can elect to play a game with the computer. We will need to design our software to play a credible game of Kriegspiel as well as referee games played by humans. A game can be suspended and resumed. From our computer gaming experience, we know that computerized games generally have player input directives, rules about legal actions, some representation of the current state of the game, and animations. In this application, our animations are simple and not a major concern. It is worth stating how Kriegspiel is played, although our application won’t mimic the real-world game. We will draw design ideas from this description.
In the game of Kriegspiel, three boards and sets of chessmen are used. There is a referee, whose chess set is in the center, with two players seated back-to-back, each at his own board. Each player moves his own chessmen, and the referee duplicates each move on his own board. The referee tells a player when his attempted move is impossible. Each player tries to guess what move his opponent is making. When a player completes a legal move, the referee announces, “Black (or White) has moved.” When a player tries an illegal move, the referee waves his hand to prevent it but does not let the opponent know. When a move results in a capture, the referee announces, “Black (or White) captures on (the rank, file, long or short diagonal)” and removes the captured piece from the board of the player who lost it. A player may ask, “Any?” and be told by the referee if he has a possible capture with a pawn. That’s the only question he is permitted. Having asked the question he must try at least one pawn capture before making a different move. To summarize, players make moves, ask “Any?,” suspend or resume a game, claim a draw, or concede.
Let’s contrast what we can glean from each story and then sketch out our candidate search strategies. The underlying requirement for the online banking system is flexibility. Functionality, implementation, and information need to be configurable. The application will maintain additional user-supplied information and construct account history from online and other banking transactions.
Our strategy for identifying candidates for this application will be to focus initially on modeling concepts that represent online banking services, the common interface to backend banking systems, and accounts. We should have objects that are responsible for performing banking functions and storing application-specific information about online transactions. Because we are building a multiuser online system, we also need objects that are responsible for managing access to limited resources such as the database and backend banking system connections. The key themes in the banking story are
Modeling online banking services
Flexibly configuring behavior
Sharing scarce software resources among thousands of users
Supporting different views of accounts and access privileges
The Kriegspiel application, even though it too is an Internet application, has fundamentally different drivers. As with any gaming application, we need to take a step back from our vivid real-world reference of the physical board game and ponder what mechanisms and inventions are needed by a computerized game. This is always a major design challenge with gaming applications. It is one we are familiar with from past experience. Our goal in designing Internet Kriegspiel isn’t to simulate the real world but instead to construct a model that represents what is needed to run a computerized game. Choosing the right abstractions to represent the game and moves will be critical. We also need to consider how running over the Internet will impact our design. This will affect how we divide the work between application components. Finally, we’ll need to implement a semi-intelligent computerized game player—something that is smart enough to play a decent game against a human opponent. Our central concerns for Internet Kriegspiel:
Game modeling
Computer playing a game
Partitioning responsibilities across distributed components