This chapter is from the book
This chapter is from the book
This chapter is from the book
Search Strategies
Once you have identified major themes, you can use them as sources of inspiration. Make educated guesses about the kinds of inventions that you will need based on the nature of your application and the things that are critical to it. Candidates generally represent the following:
The work your system performs
Things directly affected by or connected to the application (other software, physical machinery, hardware devices)
Information that flows through your software
Decision making, control, and coordination activities
Structures and groups of objects
Representations of real-world things the application needs to know something about
We guide our search from these perspectives. The kinds of inventions we seek are closely related to the role stereotypes.
If an application’s central mission boils down to computation, look to populate it with objects playing the role of service providers that calculate, compute, transform, and figure. You will likely invent objects that represent algorithms or operations along with objects that control work processes. If your application’s major activity is to assemble and move information from one place to another, identify candidates that model this information as objects along with others to coordinate their movement. If your application connects with other systems, invent external interfacers that form these connections. Most designs need objects that control or coordinate the work of others. Depending on the complexity of the control, this design decision may or may not be a prominent one. If your application needs to sort through, organize, and make connections between related objects, structurers need to be identified. There are relatively direct links between the kinds of objects you look for and the nature of the work your software carries out.
The best way to evaluate potential candidates that represent external things is to shift perspective. Climb into your software and look out at the world. Take your application’s viewpoint. Ask what you need to know about your users, the systems you connect to, and things out there that you affect.
As you look for candidates one question to ask is, “How much does our software need to know about things in the external and virtual worlds it is connected to?” At the borders, model connections to other systems as interfacer objects. You may include in your design objects that represent these other software systems. These service providers will be called upon by other parts of the application. But when should you model things that are outside a computer, such as your software’s users? If it is only their actions that matter and not whom they are, leave them out of the design. Users’ actions can be conveyed via user interface objects (objects charged with translating user requests and information to other parts of the system). There is no need to know who is pushing your application’s buttons! On the other hand, if whom users are makes your software behave differently, include some representation of them as a candidate. Some knowledge of its users (and objects to represent that knowledge) is needed if your software bases any decisions on whom it interacts with. For example, if different users have different access rights to accounts or if the ability to resume a game requires knowledge of whom the players are, then some representation of these users should be part of the design.
Tables 3-1 and 3-2 outline our search strategies for our two applications. Although we consider each perspective, typically only one or two are relevant to any particular theme. If we find that a particular perspective does not yield any insights, we move on. For each theme, we briefly summarize the perspectives that yielded insights and the kinds of candidates we are looking for.
Table 3-1. The initial search for online banking application candidates is based on exploring four themes.
| Theme | Perspective | Candidates That Specifically Support... |
| Online banking functions | The work our system performs | Performing financial transactions, querying accounts |
| Things our software affects | Accounts, backend banking system transactions | |
| Information that flows through our software | Information about transactions, account balances, transaction amounts, account history, payments | |
| Representations of real-world things | Customers, users, and the accounts they access | |
| Flexibly configuring behavior | Things our software affects | A common interface to backend systems |
| Information that flows through our software | Configurable display of Web page banners, text, messages, and account formats | |
| Sharing scarce resources | Structures and groups of objects | Managing limited connections to backend systems and our online banking application database |
| Different views of and access to accounts | The work our system performs | Restricting users’ views of and ability to perform banking transactions that modify account balances |
| Decision making, coordination, and control | Prohibiting access to accounts unless user has specific privileges |
Table 3-2. The initial search for Kriegspiel application candidates is based on the themes of game modeling, intelligent computerized game playing, and distributed games.
| Theme | Perspective | Candidates That Specifically Support... |
| Game modeling | The work our system performs | Assigning players to games, refereeing, storing and resuming suspended games, playing a game, determining the legality of a move, determining the outcome of a move, displaying the state of each player’s board |
| Information that flows through our software | Information about moves and player requests | |
| Representations of real-world things | Players and their actions | |
| Structures and groups of objects | Managing saved games, the various games, game pieces, and their locations on a game board | |
| Computer playing a game | The work our system performs | Playing a game with a user |
| Decision making, control, and coordination | Determining a reasonable move to make based on the current view of the game (which should be just as limited as any human player’s view) | |
| Partitioning responsibilities across distributed components | Decision making, control, and coordination | Communicating a player request to the referee and game state between players, detecting whether a player is still connected |
| Information that flows through our software | Player moves, updated boards, and game state |
We will identify candidates that support the relevant perspectives. Sometimes candidates leap right out of the page from our brief descriptions; are Player and PlayerAction good candidates based on the fact that we need to have candidates that support our game’s real-world view of “players and their actions”? Highly likely. At other times, we must speculate about exactly how our software might work in order to come up with candidates; perhaps there should be a BankingServicesConnectionManager that manages BankingServicesConnections or a DatabaseConnectionManager to manage DatabaseConnections that are scarce resources? Often, different themes and perspectives reiterate and reinforce the need for certain kinds of candidates. This is good. It builds confidence in the relevance a particular candidate has to our application. At other times, ideas do not come so quickly, and we must think more deeply to come up with potential candidates.
We won’t find all the key candidates in this first pass; nor will our initial ideas about our candidates remain fixed. Our notions change as we give candidates further definition. The initial candidates that we come up with will seed our design. So it is particularly important to give each candidate a strong name that suggests its role and purpose. So before we continue searching for candidates, let’s explore what it takes to find useful names.