BN.com Gift Guide

Streamlined Object Modeling: Patterns, Rules, and Implementation [NOOK Book]

Overview

  • 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 ...

See more details below
Streamlined Object Modeling: Patterns, Rules, and Implementation

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac

Want a NOOK? Explore Now

NOOK Book (eBook)
$26.99
BN.com price
(Save 42%)$46.99 List Price

Overview

  • 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.

Read More Show Less

Editorial Reviews

From The Critics
Three leaders in object development present this text for business analysts, systems analysts, and software developers who receive system requirements and translate them into system designs. The text is organized into sections covering the activities of streamlined object modeling; guidelines—as a starting point and organizational framework—for realizing objects, collaborations, services, and business rules in code; and an examination of how collaboration patterns form the basis for new patterns, and structure documentation for business object models. The text assumes a working knowledge of the Unified Modeling Language (the UML) and general object-oriented development terminology. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780132797368
  • Publisher: Pearson Education
  • Publication date: 10/5/2001
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 1
  • Pages: 400
  • Sales rank: 1,342,046
  • File size: 4 MB

Meet the Author

JILL NICOLA is an independent software consultant in Houston, TX who has worked in object-oriented software for over 15 years as a programmer, mentor, modeler, and architect. She specializes in helping organizations apply object techniques to develop strategies and model business processes, and co-authored Object-Oriented Programming with Peter Coad.

MARK MAYFIELD is the Object Guru at Chelsea Market Systems in Houston, TX. A leading authority on object modeling patterns, he has created hundreds of object models in a wide range of commercial environments, and co-authored Object Models: Strategies, Patterns, & Applications and Java Design with Peter Coad.

MIKE ABNEY is a Senior Java Developer at Chelsea Market Systems in Houston, TX who has performed many roles in software development, including analysis, user interface and software architecture design, coding, and project management.

Read More Show Less

Read an Excerpt

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.

Read More Show Less

Table of Contents

Preface
Acknowledgements
Ch. 1 Object Modeling 1
Ch. 2 Finding Objects 13
Ch. 3 Collaboration Patterns 27
Ch. 4 Collaboration Rules 51
Ch. 5 Services and Properties 95
Ch. 6 Object Inheritance Strategies 125
Ch. 7 Implementing Collaboration Pairs 157
Ch. 8 Implementing Business Rules 227
Ch. 9 Combining Collaboration Patterns 275
Ch. 10 Object Model Documentation 297
App. A Streamlined Object Modeling Principles 315
App. B Streamlined Object Modeling Summary 333
Bibliography 343
Index 345
Read More Show Less

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 madeother 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 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.

Chapt 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.

Read More Show Less

Introduction

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 aroundthem, 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 object 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.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted May 11, 2002

    A great tutorial and reference

    After reading the book the first time and assimilating its content, I started applying it in one of the object models I was working on. I used the Streamlined Object Modeling techniques a little bit at first, and, after realizing some of the great benefits, I used them extensively, refactoring my model according to the book's principles. I've got yellow sticky notes throughout it, as it serves as a reference for me now; I wouldn't want to do analysis, design, or implementation without it.<p> When I discovered Peter Coad's Object Modeling in Color book (ISBN 013011510X), where I was introduced to his 'domain neutral component' (DNC), I had an epiphany. Then, after experiencing the fractal application of the DNC, I started to notice the patterns that Nicola, Mayfield, and Abney lay down quite nicely. It is a natural maturation of thought from Coad's DNC; Coad himself even acknowledges the importance of the book. <p> If you want to become a good object oriented analyst, read this book, then read it again. If you think you're a good object oriented analyst, read this book, then read it again. In either case, after applying the principles described, I think you'll wonder how you ever got along without them. <p> Kudos to Nicola, Mayfield, and Abney for an intellectual milestone in object oriented technology. I wish someone had handed this book to me when I first started working with object oriented languages.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)