Streamlined Object Modeling: Patterns, Rules, and Implementation

Description

• A rigorous and practical framework for modeling business systems
• Pares object modeling down to its core concepts, making it easier than ever.
• Twelve object collaboration patterns that address virtually any business scenario
• Powerful techniques–not fancy notation!

Streamlined Object Modeling presents the first rigorous, practical framework for object modeling complex business domains, rules, and systems. Three world-renowned leaders in object development have pared object modeling down to the core concepts for all business domains, business rules, and business services. Starting from the first principles of "object think," the authors offer a fully integrated approach to building, validating, and critiquing object models. Coverage includes:

• Proven principles and techniques for successfully modeling the structure and operations of any business domain.
• Guidelines for finding and associating objects, assembling object models, and distributing system behavior among objects.
• Rigorous methods for discovering, organizing, and implementing business rules around objects.
• Twelve all-encompassing "collaboration patterns"–what they represent, how they relate, and how to apply them.
• Five kinds of business rules, three types of services, and six categories of properties completely specify object-oriented business requirements

From start to finish, the book makes extensive use of examples drawn from real commercial applications. To illustrate how streamlined object modeling flows from analysis to code, it also presents a complete case study derived from a real-world application, and implemented in two leading object-oriented languages-Java, and the Squeak implementation of Smalltalk.

Extras

Related Articles

Designing Objects with Business Rule Checking

Enforcing Business Rules with Objects

Object Inheritance: Definition, Uses, and Motivations

Sample Content

Online Sample Chapters

Effective Business Object Modeling

How to Find Business Objects

Object Think: A Perspective on Objects

Table of Contents

PLEASE PROVIDE

Preface

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 related objects into one generalization, or pull out a reusable policy object, keep in mind that you must explain that generalization or reusable object to your client. Go ahead and make that generalization or policy object in your design, but keep the business object model verbose and simple for the client's sake. Also, there is a difference between verbose and cluttered. Limit the model to only those objects, services, and attributes that are necessary to understand the business rules.

Who Should Read This Book?

This is not an introductory software development book. While much of the book is non-technical, it does assume a working knowledge of the Unified Modeling Language (the UML) and general object-oriented development terminology. That being said, this book has three primary audiences: business analysts, system analysts, and software developers who receive system requirements and translate them into system designs. Those who belong to more than one of these groups should get added benefits.

For business and systems analysts, this book offers a new method for gathering and organizing business requirements. This method is significant for incorporating business rules into the object model, and for organizing objects in patterns that communicate with the client. A secondary goal is learning how to prototype a modeled system in one of two programming languages: Java or Squeak.

For software developers, this book offers two benefits. First, since the patterns in this book address modeling business requirements in object-oriented terms, the patterns structure business requirements in a format understandable by most developers. When receiving a business object model, developers will better appreciate the meanings behind the objects. When receiving a functional requirements document, developers can use the patterns to transform it into a more object-oriented representation. Second, once the developers understand the 12 patterns and the ways in which the pattern objects interact, the developers can quickly take the business rules of a domain and apply the prototyping guidelines provided in the later chapters. This effectively jump-starts the development process.

Outline of This Book

The first six chapters of this book outline the activities of streamlined object modeling. These chapters are required reading for business analysts and software developers. Don't skip these chapters if you want a solid understanding of the methodology.

Chapter 1 is a general discussion about the use of object modeling for analysis.

Chapter 2 discusses principles for finding and categorizing objects.

Chapter 3 applies the principles from Chapter 2 to derive the core set of patterns. There are 12 patterns consisting of collaborating pairs of objects. Therefore, we call them collaboration patterns.

Chapter 4 discusses how to organize business rules around objects using the 12 collaboration patterns.

Chapter 5 covers modeling information and business processes and uses the 12 collaboration patterns to distribute processing among the objects.

Chapter 6 explains "object inheritance," a powerful modeling technique for sharing information among objects. Object inheritance underlies several of the collaboration patterns.

Chapters 7 and 8 are geared more toward software developers. They provide guidelines for realizing objects, collaborations, services, and business rules in code. These guidelines are intended to aid understanding of how the methodology translates into a working system, and to validate the business rules through a working implementation. Because they follow from a business object model, and not a refined, optimized system design, the guidelines are not the final story in a coding methodology. We offer them here as a starting point and organizational framework.

Chapter 7 presents an implementation template for translating business objects into programming code. The objective here is to put the code for each object into a common template and establish naming standards and practices to be used later when coding business rules.

Chapter 8 shows how to implement the business rules modeled in Chapter 4 within the templates established in Chapter 7.

Chapters 9 and 10 are for both business analysts and software developers. These chapters examine how collaboration patterns form the basis for new patterns, and structure documentation for business object models.

Chapter 9 presents a "periodic table" of the objects involved in the collaboration patterns. By examining the "chemical properties" of the pattern objects, new patterns can be created by snapping together collaboration patterns through shared objects and by overlaying pattern objects to create new patterns.

Chapter 10 presents documentation outlines we have used to describe streamlined object models. They are by no means the final word on documentation, but show two ways to augment the relationships and rules displayed in the object model diagrams with textual descriptions.

Appendix A lists important principles of streamlined object modeling. It is organized around the core activities and concepts. Each principle refers back to the chapter text where it was first described. Use these principles to guide your object modeling efforts.

Appendix B summarizes the core patterns and concepts of streamlined object modeling in a convenient reference format. Each summary includes hints and examples to assist understanding and application of the pattern or concept. Use these summaries as a quick refresher.

Updates

Submit Errata