Preface This book started as a guide for how to apply object modeling to real-world problems. Our plan was to apply existing patterns and principles to real-world examples and write about the results. However, while working on real-world applications, we uncovered inadequacies in the existing patterns and the associated information-gathering processes. We found two things especially troubling: first, the existing patterns showed only structure and simple behavior; second, there was no method for capturing business rules in terms of objects. Also bothersome was our inability to justify the use of one set of existing patterns over another. Our consulting and development work gave us the opportunity to experiment with patterns, make refinements, and consider the results. We became particularly interested in finding the primary patterns for representing people, places, things, and events. From those we knew, we could derive all other patterns for modeling business domains.

Over time, we distilled a set of 12 patterns and were successfully applying these patterns to many diverse domains. This convinced us that those patterns were the core set of irreducible patterns from which all other patterns could be derived. Our work also revealed that business rules are encapsulated behaviors of collaborating objects. Just as similar objects appearing in different object models suggested patterns, similar business rules occurring around our core patterns suggested strategies for discovering and organizing business rules around objects. Now we knew we had something powerful. Indeed, once we determined the core patterns and based the business rules organization around them, we made other discoveries: new principles for distributing behaviors and rule-checking among the objects, new modeling techniques utilizing "object inheritance," and new strategies for implementing patterns and business rules. Together, our discoveries, which are presented in this book, form a methodology that addresses the problems we saw inherent in earlier methods. We are presently applying this method to commercial applications.

We are also looking to expand it in two ways: back into business and technical strategies, and further into design and implementation. But, this expansion is a story for another day. This book describes our object methodology and its uses in modeling business domains and implementing business rules. We call this methodology "streamlined object modeling" because its foundation rests on a streamlined set of patterns that organize and accelerate the modeling and implementation process. The Value of This Book The dot-com frenzy encouraged software development trends that put action ahead of thought. Advocates of these techniques were extremely harsh to object modeling, labeling it as an elitist, time-consuming, impractical activity. Well, we beg to differ. We believe in thought before action, and any activity that increases understanding of a problem and decreases the effort of reaching a solution is hardly impractical.

You should read this book if you like thinking through a problem and getting an insightful understanding of it before you try hacking up a solution. This requires some up-front time and effort. But it is not nearly as time-consuming as the trial-and-error programming we observe programmers routinely undertaking to produce code with no apparent organization and that is understandable only to them. With streamlined object modeling, once a problem is modeled in the core patterns, and the business rules described, the implementation is a straightforward application of our strategies and templates. The resulting code reflects the organization of the object model and follows naming standards set in the implementation strategies and templates. With our core set of patterns, we have moved object modeling from a guru practice closer to a disciplined science. Principles guide object selection, object collaboration, business rule description, behavior placement, and property specification. While it still requires analytical thinking to object model, we have eliminated much of the guesswork for newcomers to object modeling, and provided experienced object modelers with tools for more precise organization and implementation of objects.

What Is in This Book? When defining any software system, there are three important questions to be answered: why, what, and how. "Why" explains the overall goals and purpose of the system. "What" defines the information, rules, and processes necessary for the system to achieve its goals and purposes. "How" refines each aspect of "what" and creates a blueprint for assembling those aspects into a working system. In short, "why" means discovery of motivation (often called strategy), "what" means requirements analysis, and "how" means application design. Leaving one or more of these three questions unanswered or incompletely answered increases the difficulty of successfully creating a system. Without motivation (why), it is difficult to weigh the value of features to be analyzed (what). Without knowledge of requirements (what), it is impossible to guess which technologies and design strategies (how) will be best for the final system.

While all three questions are important, what is in this book is a great deal about "what." More specifically, this book describes a method for modeling and implementing information, rules, and processes with object-oriented concepts. While other methodologies cover modeling information and processes with objects, this methodology goes further than most by modeling the rules governing the information and processes. These rules, which are commonly known as "business rules," are a major component of any complete requirements analysis. This book shows not only how to organize business rules around objects, but also provides guidelines for implementing business rules. Examples are provided in Java and Squeak. Our simple, strong motivation for spending so much time on system business rules is this: they are the rules that make the business work. To put it another way, business rules are the foundation of what businesses will and will not allow.

Your bank allows you to deposit money into a checking account and withdraw it when you need it, but it will not allow you to withdraw more than you deposit-at least not without charging you a fee. The rules that define who can put money into your account, who can take it out, and what happens when money moves, are what make the checking account behave the way the bank wants checking accounts to behave. A larger group of these rules, including rules about checking accounts, savings accounts, loans, and what the bank is allowed to do with the money while it is in their hands, is what makes the bank behave the way the bank thinks it should. A key object-oriented concept is encapsulation: keeping related things together. Business rules make objects behave correctly: they keep the interactions legal, and safe, thereby keeping the system together. We encapsulate business rules inside the business objects they govern so that the mechanisms that bind the system together and keep it from coming apart are held within the business objects. We want the herd of cattle to herd itself; we want the heart to regulate its rhythm; we want the product to track its own inventory. We don''t want to have to hire wranglers, wear pacemakers, or build "inventory manager" objects.

Too many existing methods proscribe the externalization of business rules. Business rules enforced externally by user interfaces and databases that work across entity objects tend to be more problematic over the life of the system. Such rules are not encapsulated; they are kept in many places, but not necessarily in a logical place, and certainly not with the objects they govern. Together the business objects and their encapsulated business rules are referred to as the business domain. While the business domain is the major component of the system analysis, requirements for other components are important, too. Part of the "what" of a system includes its user interface analysis and its technical requirements such as load factors, availability, and system scalability. No system analysis is complete without these other aspects. However, without knowing the business rules, the interface design might allow something to happen that it shouldn''t.

Also, requirements such as load factors, availability, and system scalability are closely tied to business rules. For example, system availability requirements might vary according to company policies preventing system access after business hours. For these reasons, we do not cover user interface analysis or technical requirements gathering. We do, however, encourage you to take whatever you can from this book and apply it in those areas. How to Read This Book This book emphasizes communication and "object" thinking. Just as you tailor your words for your audience, so we tailor our object models. With streamlined object modeling, our primary audience comprises the clients of the analysis. To ensure accuracy of the model, clients must be able to understand it and validate it.

For this reason, the models produced use simplified notation and are verbose. When you read the models in this book, remember that these models are not the final design of the system. They are not refined into reusable components, optimized for efficiency, or heavily annotated. They do not include "stereotypes" in any of the diagrams, and class inheritance is not used until the later chapters that deal with prototyping. These concepts, while useful, detract from the client''s ability to understand the model. While reading this book, it will help to imagine you are building a model for a business client. Although you may be tempted to collapse re.