Analysis Patterns

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $4.89
Usually ships in 1-2 business days
(Save 93%)
Other sellers (Hardcover)
  • All (25) from $4.89   
  • New (9) from $44.82   
  • Used (16) from $4.89   

Overview

Recognizing that conceptual patterns cannot exist in isolation, the author also presents a series of "support patterns" that discuss how to turn conceptual models into software that in turn fits into an architecture for a large information system. Included in each pattern is the reasoning behind their design, rules for when they should and should not be used, and tips for implementation. The examples presented in this book comprise a cookbook of useful models and insight into the skill of reuse that will improve analysis, modeling and implementation.


Intended for analysts, designers and programmers, this book describes patterns in object-oriented models of business software. The first section provides analysis patterns from conceptual business models. It catalogs modeling results and covers analysis patterns in domains such as trading, measurement, accounting and organizational relationships. The second section focuses on support patterns. The support patterns show how analysis patterns fit into information systems architecture and how conceptual models turn into software interfaces. It also covers layered architecture, application facades, associated patterns and design templates. te>

Read More Show Less

Editorial Reviews

From Barnes & Noble

Fatbrain Review

Intended for analysts, designers and programmers, this book describes patterns in object-oriented models of business software. The first section provides analysis patterns from conceptual business models. It catalogs modeling results and covers analysis patterns in domains such as trading, measurement, accounting and organizational relationships. The second section focuses on support patterns. The support patterns show how analysis patterns fit into information systems architecture and how conceptual models turn into software interfaces. It also covers layered architecture, application facades, associated patterns and design templates.
Read More Show Less

Product Details

  • ISBN-13: 9780201895421
  • Publisher: Addison-Wesley
  • Publication date: 10/4/1996
  • Series: Addison-Wesley Object Technology Series
  • Edition description: New Edition
  • Pages: 357
  • Product dimensions: 7.81 (w) x 9.62 (h) x 1.00 (d)

Meet the Author

Martin Fowler is an independent consultant who has applied objects to pressing business problems for more than a decade. He has consulted on systems in fields such as health care, financial trading, and corporate finance. His clients include Chrysler, Citibank, UK National Health Service, Andersen Consulting, and Netscape Communications. In addition, Fowler is a regular speaker on objects, the Unified Modeling Language, and patterns.

Read More Show Less

Read an Excerpt

Not long ago, no books were available on object-oriented analysis and design. Now there are so many that it is impossible for any practitioner to keep up with them all. Most of these books concentrate on teaching a notation, suggesting a simple process for modeling, and illustrating it with a few simple examples. Analysis Patterns: Reusable Object Models is a different kind of book. Instead of focusing on the process - how to do modeling - it concentrates on the result of the process - the models themselves.

I am a consultant in object modeling for information systems. Clients ask me to train staff on modeling and to provide mentoring on projects. Much of my skill comes from a knowledge of modeling techniques and how to use them. More important, however, is my experience in actually creating many models and regularly seeing problems repeat themselves. Frequently I find that many aspects of a project revisit problems I have faced before. That experience allows me to reuse models I have built before, improve them, and adapt them to new demands.

Over the last few years, more and more people have also become aware of this phenomenon. We have realized that the typical methodology books, though valuable, only present the first step in a learning process that must also capture the actual things that are built. This realization has flowered into the patterns movement. This is a varied group of people, representing many different interests and opinions yet sharing the goal of propagating useful patterns of software systems.

As a result of the diversity of this patterns community, we have had difficulty in defining the term pattern. We all think we can recognize a patternwhen we see it, we think most of us would agree in most cases, but we cannot come up with a single definition. Here is my definition: A pattern is an idea that has been useful in one practical context and will probably be useful in others.

I like to leave the definition quite loose because I wish to stay as close to the underlying motivation of patterns, without adding too many restrictive amendments. A pattern can have many forms, and each form adds specializations that are useful for that kind of pattern. (Section 1.2 discusses the current state of the patterns world and where this book fits in.)This book is about patterns in analysis, patterns that reflect conceptual structures of business processes rather than actual software implementations. Most of the chapters discuss patterns for various business domains. Such patterns are hard to classify into traditional vertical areas (manufacturing, finance, health care, and so on) because they are often useful in several areas. These patterns are important because they help us to understand how people perceive the world. It is valuable to base a computer system's design on this perception and, indeed, to change that perception - which is where business process reengineering (BPR) comes in.

Conceptual patterns cannot exist in isolation, however. Conceptual models are only useful to software engineers if they can see how to implement them. In this book I present patterns that can be used to turn conceptual models into software, and I discuss how that software fits into an architecture for a large information system. I also discuss specific implementation tips with the patterns.

I wrote this book because this was the book that I wanted to read when I started out. Modelers will find ideas in this book to help them begin working in a new domain. The patterns contain useful models, the reasoning behind their designs, and when they should and should not be applied. With this information a modeler can adapt the models to fit a specific problem. The patterns in this book can also be used in reviewing models - to see what might have been left out and to suggest some alternatives that may lead to improvement. When I review a project, I usually compare what I see with the patterns I have learned from previous work. I have found that being aware of patterns in my work helps me to apply my past experiences more easily. Patterns like this also uncover modeling issues that go beyond what can be covered in a simple text book. By discussing why we model things the way we do, we gain a greater understanding of how to improve our modeling, even if we don't use the patterns directly.

Structure of this Book This book is divided into two sections. The first section covers analysis patterns, which are patterns from conceptual business models. They provide key abstractions from domains such as trading, measurement, accounting, and organizational relationships. The patterns are conceptual because they represent the way people think about the business, rather than the way a computer system is designed. The chapters in this section stress alternative patterns that can be used, and the strengths and weaknesses of those alternatives. Although each pattern will clearly be useful to those working in the same domain, the basic pattern is often useful in other domains.

The second section focuses on support patterns, which help you use analysis patterns. Support patterns show how analysis patterns fit into an information systems architecture, how the constructs of conceptual models turn into software interfaces and implementations, and how certain advanced modeling constructs relate to simpler structures.To describe these patterns, I need a notation. The appendix provides a brief discussion of the notation I use and what the symbols mean. I do not use a single method but prefer to mix techniques from different methods. The appendix is not designed to be a tutorial on techniques, but it should provide an outline and refresh your memory. It also tells you where to find a tutorial on the techniques I use.

Each section is divided into chapters. Each chapter on analysis patterns contains patterns that are related by a loose notion of subject area, influenced by the projects that spawned them. This organization reflects the fact that any pattern must come from a practical context. Each pattern appears in its own subsection within a chapter. I do not use any of the formal headings for patterns that are used by some patterns authors (see Section 1.2.2). I describe each pattern in a form that is as close to the original project form as is reasonable, with a minimum of abstraction. I add examples to show the use of the pattern within its original domain and also to suggest how the pattern might be used in other domains. One of the greatest difficulties of patterns is abstracting them into other domains; I follow the principle that this should be left to the reader (see Section 1.2.3).

This book is thus a catalog, rather than a book to be read from cover to cover. I have tried to write each chapter in such a way that it can be read independently from the other chapters. (This is not always possible, however. Whenever a chapter requires that another chapter be read first, I say so in the chapter introduction.) Each chapter has an introduction that explains the general subject area of the chapter, summarizes the patterns in the chapter, and says what projects the patterns originated from.

How to Read this BookI suggest reading all of Chapter 1 first and then reading each chapter introduction. Then feel free to delve into the chapters in any order you like. If you are not familiar with the approach I take to modeling, or the notation and concepts I use, read the appendix. The Table of Patterns gives a brief summary of what each pattern is about, so you can use that to help you explore or to find a pattern when you come back to the book at a later time. It is important to stress that each pattern in this book is useful outside the domain that gave it birth. Thus I encourage you to look into chapters that you might think are outside your field of interest. For example, I found that models of observation and measurement designed for health care proved to be very useful for corporate financial analysis.

Who Should Read this BookThis book can be useful to a range of readers, although different readers will learn different things from it and may need some different preparations.I expect my biggest audience to be analysts and designers of object-oriented (OO) computer systems, particularly those working at the analysis end. Such readers should have made at least some use of an OO analysis and design method. This book does not provide any introduction to this subject, so I would suggest first reading a book on OO analysis and design if you are new to this field. I must stress that the patterns in this book are conceptual in nature, and I use a very conceptual approach to modeling. This leads to some stylistic differences from those texts that use a more implementation-based approach to modeling.

A small, but very important, audience consists of those people who act as domain experts for a modeling project. Such readers do not require a knowledge of computers but do need to know about conceptual modeling. One of the main reasons I use conceptual models in this book is to make things easier for this group of readers. The modeling project here may be analysis for computer system development or BPR. I have taught many professionals (including doctors, financial traders, accountants, nurses, and payroll supervisors) this kind of modeling and have found that a software background is neither an advantage nor a disadvantage to conceptual modeling. The business model patterns are as much about business modeling as they are about computer systems analysis (see Section 1.4). Any such reader should take a course on OO analysis that stresses the conceptual aspect. (Odell's book Martin, J., and J. Odell, Object-Oriented Methods: A Foundation, Englewood Cliffs, NJ: Prentice-Hall, 1995 is particularly valuable in this respect.)

I hope many programmers will delve between these covers, although some programmers may take exception to the lack of code and the conceptual slant. For these readers I suggest you take particular note of Chapter 14, which should help to explain the relationship between the conceptual models and the resulting software.

This is an object-oriented book, and I do not hesitate in proclaiming my belief that the object-oriented approach is the superior way to develop software. These models, however, are primarily conceptual models, and many data modelers have had a long tradition of using conceptual (or logical) models. Data modelers should find many of the patterns useful, particularly if they use more advanced semantic techniques. The object-oriented features of the models will reveal many of the differences between object-oriented and traditional approaches. I would encourage such readers to use this book in conjunction with an OO analysis book that stresses the conceptual side of modeling and the links between OO and semantic data modeling.

Managers will find the book useful as a starting point for development activity. Starting from a pattern can help to clarify goals, and project planning can take advantage of the broad ground that patterns map out.

I have not aimed this book at students. I've written it more for the professional software engineer. I hope, however, that some students will take a look. When I was learning analysis and design, I found it difficult because there were few good examples I could learn from, examples that came out of the world outside the university. Just as looking at good code can teach you a lot about programming, looking at good models can teach you a lot about analysis and design.

A Living BookEvery author I know shares a frustration: Once a book is published it is fixed. The book spreads its advice around the community, yet the author has little way of expressing changes. I know how much I keep learning, and I am sure this learning will modify my ideas. I want these changes to be passed on to my readers.

With this book, Addison-Wesley will provide a web site which will be used to pass on further materials to keep this book alive. At this stage I am not sure exactly what it will contain, but I expect the following:

  • any new things I learn about the patterns in the book
  • answers to questions about the book
  • useful commentary from others about the patterns
  • new analysis patterns by myself, and by others
  • When the Unified Modeling Notation appears (or whatever it is called by then) I will redraw all the diagrams in the book in the new notation and put them on the site.

This site will be a complement to the book, so keep an eye on it and use it to let me know how to improve and develop the ideas between these pages.

AcknowledgmentsAny author is indebted to many others who help. For this book this is particularly true since so many of the patterns were built with the help of my clients, colleagues, and friends. I would like to give my sincere thanks to the following, both named and implied.First and foremost, Jim Odell has been an essential part of my career. He has taught me much about developing information systems and has been a constant source of inspiration, helpful advice, and strange humor. I can safely say that without his support this book would not have happened.

The team at Coopers & Lybrand in London helped with much of the early work and helped pass many evenings at Smithfield's.

John Edwards formed many of my early ideas about conceptual modeling and its role in software development, as well as introducing me to many interesting ideas, including those of Christopher Alexander.

John Hope urged me to think of the domain first and technology second, as well as casting a helpful spell at several key points in my career.

Tom Cairns and Mark Thursz, doctors at St. Mary's Hospital in London, worked with me in developing the health care models that form the basis of Chapters 2, 3, and 8. They are proof that a computer background is not necessary to be a top-class conceptual modeler. Mark also was a willing source for health care examples with impressive-sounding medical terminology.The health care projects also involved many software and health care professionals from St. Mary's, the Hospital for Sick Children (HSC), St. Thomas's Hospital, and the University of Wales. Anne Casey, a nurse at HSC, and Hazim Timimi, an analyst, helped put together the final Cosmos model. Gerry Gold set up this work and made sure it kept going.

Brad Kain has had a great impact on my thinking on reuse and components, as well as undertaking the important task of showing me the nightlife of Boston.

Applying the health care models to corporate finance in Chapter 4 was the experience that, for me, proved the usefulness of analysis patterns across different domains. Lynne Halpin and Craig Lockwood led the MBFW team at Xerox, and Vivek Salgar got our conceptual ideas into the brutal reality of C++.

David Creager, Steve Shepherd, and their team at Citibank worked with me in developing the models from which I drew the financial patterns in Chapters 9-11. They also further developed many of the architectural ideas of Chapter 12 from their health care origins, and taught me much about the frenetic life in The City.

Fred Peel set up and maintained my work at Citibank, when not scaring me with his driving.

Daniel Poon and Hazim Timimi from Valbecc got many of my fuzzy ideas into detailed specifications.

The accounting patterns in Chapter 6 have had a long gestation. Tom Daly, Peter Swettenham, Tom Hadfield, and their respective teams developed models that gave birth to the patterns in this book. Rich Garzaniti got my accounting terminology sorted out. Kent Beck did much to improve my Smalltalk.

Chapter 14 was written with the help of James Odell.

I have been very much a latecomer to the patterns community, getting to know it well only after most of this book was written. It is a very open and friendly group that has done much to encourage my work. Kent Beck, Ward Cunningham, and Jim Coplein encouraged me to get involved with the community and to develop my ideas as patterns. Ralph Johnson provided particularly helpful comments on the first draft of this book.

I have had first-class comments from my many reviewers whom I would like to name: Dave Collins, Ward Cunningham (Cunningham & Cunningham, Inc.), Henry A. Etlinger (Department of Computer Science, RIT), Donald G. Firesmith (Knowledge Systems Corporation), Erich Gamma, Adele Goldberg, Tom Hadfield (TesserAct Technology), Lynne Halpin (Netscape Communications), Brian Henderson-Sellers, Neil Hunt (Pure Software), Ralph E. Johnson (University of Illinois at Urbana-Champaign), Jean-Pierre Kuilboer (University of Massachusetts, Boston), Patrick D. Logan (Intel Corporation), James Odell, Charles Richter (Objective Engineering, Inc.), Douglas C. Schmidt (Washington University), and Dan Tasker. I will mention that Don Firesmith went above the call of duty in tracking down problems that needed to be fixed.

As this is my first book, I'm particularly grateful to those at Addison-Wesley who helped me through the process. Carter Shanklin directed affairs and assembled a formidable panel of reviewers with much assistance from Angela Buenning. Teri Hyde coordinated the book production on a painfully tight schedule and Barbara Conway rescued my prose from its usual erratic state, and ruthlessly eliminated my native accent.

Read More Show Less

Table of Contents

Foreword
Foreword
Preface
Ch. 1 Introduction 1
Ch. 2 Accountability 17
Ch. 3 Observations and Measurements 35
Ch. 4 Observations for Corporate Finance 57
Ch. 5 Referring to Objects 85
Ch. 6 Inventory and Accounting 95
Ch. 7 Using the Accounting Models 133
Ch. 8 Planning 157
Ch. 9 Trading 175
Ch. 10 Derivative Contracts 197
Ch. 11 Trading Packages 225
Ch. 12 Layered Architecture for Information Systems 239
Ch. 13 Application Facades 257
Ch. 14 Patterns for Type Model Design Templates 271
Ch. 15 Association Patterns 297
Ch. 16 Afterword 309
App. A. Techniques and Notations 313
App. B. Table of Patterns 331
Index 343
Read More Show Less

Preface

Not long ago, no books were available on object-oriented analysis and design. Now there are so many that it is impossible for any practitioner to keep up with them all. Most of these books concentrate on teaching a notation, suggesting a simple process for modeling, and illustrating it with a few simple examples. Analysis Patterns: Reusable Object Models is a different kind of book. Instead of focusing on the process - how to do modeling - it concentrates on the result of the process - the models themselves.

I am a consultant in object modeling for information systems. Clients ask me to train staff on modeling and to provide mentoring on projects. Much of my skill comes from a knowledge of modeling techniques and how to use them. More important, however, is my experience in actually creating many models and regularly seeing problems repeat themselves. Frequently I find that many aspects of a project revisit problems I have faced before. That experience allows me to reuse models I have built before, improve them, and adapt them to new demands.

Over the last few years, more and more people have also become aware of this phenomenon. We have realized that the typical methodology books, though valuable, only present the first step in a learning process that must also capture the actual things that are built. This realization has flowered into the patterns movement. This is a varied group of people, representing many different interests and opinions yet sharing the goal of propagating useful patterns of software systems.

As a result of the diversity of this patterns community, we have had difficulty in defining the term pattern. We all think we can recognize a pattern when we see it, we think most of us would agree in most cases, but we cannot come up with a single definition. Here is my definition: A pattern is an idea that has been useful in one practical context and will probably be useful in others.

I like to leave the definition quite loose because I wish to stay as close to the underlying motivation of patterns, without adding too many restrictive amendments. A pattern can have many forms, and each form adds specializations that are useful for that kind of pattern. (Section 1.2 discusses the current state of the patterns world and where this book fits in.)This book is about patterns in analysis, patterns that reflect conceptual structures of business processes rather than actual software implementations. Most of the chapters discuss patterns for various business domains. Such patterns are hard to classify into traditional vertical areas (manufacturing, finance, health care, and so on) because they are often useful in several areas. These patterns are important because they help us to understand how people perceive the world. It is valuable to base a computer system's design on this perception and, indeed, to change that perception - which is where business process reengineering (BPR) comes in.

Conceptual patterns cannot exist in isolation, however. Conceptual models are only useful to software engineers if they can see how to implement them. In this book I present patterns that can be used to turn conceptual models into software, and I discuss how that software fits into an architecture for a large information system. I also discuss specific implementation tips with the patterns.

I wrote this book because this was the book that I wanted to read when I started out. Modelers will find ideas in this book to help them begin working in a new domain. The patterns contain useful models, the reasoning behind their designs, and when they should and should not be applied. With this information a modeler can adapt the models to fit a specific problem. The patterns in this book can also be used in reviewing models - to see what might have been left out and to suggest some alternatives that may lead to improvement. When I review a project, I usually compare what I see with the patterns I have learned from previous work. I have found that being aware of patterns in my work helps me to apply my past experiences more easily. Patterns like this also uncover modeling issues that go beyond what can be covered in a simple text book. By discussing why we model things the way we do, we gain a greater understanding of how to improve our modeling, even if we don't use the patterns directly.

Structure of this Book

This book is divided into two sections. The first section covers analysis patterns, which are patterns from conceptual business models. They provide key abstractions from domains such as trading, measurement, accounting, and organizational relationships. The patterns are conceptual because they represent the way people think about the business, rather than the way a computer system is designed. The chapters in this section stress alternative patterns that can be used, and the strengths and weaknesses of those alternatives. Although each pattern will clearly be useful to those working in the same domain, the basic pattern is often useful in other domains.

The second section focuses on support patterns, which help you use analysis patterns. Support patterns show how analysis patterns fit into an information systems architecture, how the constructs of conceptual models turn into software interfaces and implementations, and how certain advanced modeling constructs relate to simpler structures.To describe these patterns, I need a notation. The appendix provides a brief discussion of the notation I use and what the symbols mean. I do not use a single method but prefer to mix techniques from different methods. The appendix is not designed to be a tutorial on techniques, but it should provide an outline and refresh your memory. It also tells you where to find a tutorial on the techniques I use.

Each section is divided into chapters. Each chapter on analysis patterns contains patterns that are related by a loose notion of subject area, influenced by the projects that spawned them. This organization reflects the fact that any pattern must come from a practical context. Each pattern appears in its own subsection within a chapter. I do not use any of the formal headings for patterns that are used by some patterns authors (see Section 1.2.2). I describe each pattern in a form that is as close to the original project form as is reasonable, with a minimum of abstraction. I add examples to show the use of the pattern within its original domain and also to suggest how the pattern might be used in other domains. One of the greatest difficulties of patterns is abstracting them into other domains; I follow the principle that this should be left to the reader (see Section 1.2.3).

This book is thus a catalog, rather than a book to be read from cover to cover. I have tried to write each chapter in such a way that it can be read independently from the other chapters. (This is not always possible, however. Whenever a chapter requires that another chapter be read first, I say so in the chapter introduction.) Each chapter has an introduction that explains the general subject area of the chapter, summarizes the patterns in the chapter, and says what projects the patterns originated from.

How to Read this Book

I suggest reading all of Chapter 1 first and then reading each chapter introduction. Then feel free to delve into the chapters in any order you like. If you are not familiar with the approach I take to modeling, or the notation and concepts I use, read the appendix. The Table of Patterns gives a brief summary of what each pattern is about, so you can use that to help you explore or to find a pattern when you come back to the book at a later time. It is important to stress that each pattern in this book is useful outside the domain that gave it birth. Thus I encourage you to look into chapters that you might think are outside your field of interest. For example, I found that models of observation and measurement designed for health care proved to be very useful for corporate financial analysis.

Who Should Read this Book

This book can be useful to a range of readers, although different readers will learn different things from it and may need some different preparations.I expect my biggest audience to be analysts and designers of object-oriented (OO) computer systems, particularly those working at the analysis end. Such readers should have made at least some use of an OO analysis and design method. This book does not provide any introduction to this subject, so I would suggest first reading a book on OO analysis and design if you are new to this field. I must stress that the patterns in this book are conceptual in nature, and I use a very conceptual approach to modeling. This leads to some stylistic differences from those texts that use a more implementation-based approach to modeling.

A small, but very important, audience consists of those people who act as domain experts for a modeling project. Such readers do not require a knowledge of computers but do need to know about conceptual modeling. One of the main reasons I use conceptual models in this book is to make things easier for this group of readers. The modeling project here may be analysis for computer system development or BPR. I have taught many professionals (including doctors, financial traders, accountants, nurses, and payroll supervisors) this kind of modeling and have found that a software background is neither an advantage nor a disadvantage to conceptual modeling. The business model patterns are as much about business modeling as they are about computer systems analysis (see Section 1.4). Any such reader should take a course on OO analysis that stresses the conceptual aspect. (Odell's book Martin, J., and J. Odell, Object-Oriented Methods: A Foundation, Englewood Cliffs, NJ: Prentice-Hall, 1995 is particularly valuable in this respect.)

I hope many programmers will delve between these covers, although some programmers may take exception to the lack of code and the conceptual slant. For these readers I suggest you take particular note of Chapter 14, which should help to explain the relationship between the conceptual models and the resulting software.

This is an object-oriented book, and I do not hesitate in proclaiming my belief that the object-oriented approach is the superior way to develop software. These models, however, are primarily conceptual models, and many data modelers have had a long tradition of using conceptual (or logical) models. Data modelers should find many of the patterns useful, particularly if they use more advanced semantic techniques. The object-oriented features of the models will reveal many of the differences between object-oriented and traditional approaches. I would encourage such readers to use this book in conjunction with an OO analysis book that stresses the conceptual side of modeling and the links between OO and semantic data modeling.

Managers will find the book useful as a starting point for development activity. Starting from a pattern can help to clarify goals, and project planning can take advantage of the broad ground that patterns map out.

I have not aimed this book at students. I've written it more for the professional software engineer. I hope, however, that some students will take a look. When I was learning analysis and design, I found it difficult because there were few good examples I could learn from, examples that came out of the world outside the university. Just as looking at good code can teach you a lot about programming, looking at good models can teach you a lot about analysis and design.

A Living Book

Every author I know shares a frustration: Once a book is published it is fixed. The book spreads its advice around the community, yet the author has little way of expressing changes. I know how much I keep learning, and I am sure this learning will modify my ideas. I want these changes to be passed on to my readers.

With this book, Addison-Wesley will provide a web site which will be used to pass on further materials to keep this book alive. At this stage I am not sure exactly what it will contain, but I expect the following:

  • any new things I learn about the patterns in the book
  • answers to questions about the book
  • useful commentary from others about the patterns
  • new analysis patterns by myself, and by others
  • When the Unified Modeling Notation appears (or whatever it is called by then) I will redraw all the diagrams in the book in the new notation and put them on the site.

This site will be a complement to the book, so keep an eye on it and use it to let me know how to improve and develop the ideas between these pages.

Acknowledgments

Any author is indebted to many others who help. For this book this is particularly true since so many of the patterns were built with the help of my clients, colleagues, and friends. I would like to give my sincere thanks to the following, both named and implied.First and foremost, Jim Odell has been an essential part of my career. He has taught me much about developing information systems and has been a constant source of inspiration, helpful advice, and strange humor. I can safely say that without his support this book would not have happened.

The team at Coopers & Lybrand in London helped with much of the early work and helped pass many evenings at Smithfield's.

John Edwards formed many of my early ideas about conceptual modeling and its role in software development, as well as introducing me to many interesting ideas, including those of Christopher Alexander.

John Hope urged me to think of the domain first and technology second, as well as casting a helpful spell at several key points in my career.

Tom Cairns and Mark Thursz, doctors at St. Mary's Hospital in London, worked with me in developing the health care models that form the basis of Chapters 2, 3, and 8. They are proof that a computer background is not necessary to be a top-class conceptual modeler. Mark also was a willing source for health care examples with impressive-sounding medical terminology.The health care projects also involved many software and health care professionals from St. Mary's, the Hospital for Sick Children (HSC), St. Thomas's Hospital, and the University of Wales. Anne Casey, a nurse at HSC, and Hazim Timimi, an analyst, helped put together the final Cosmos model. Gerry Gold set up this work and made sure it kept going.

Brad Kain has had a great impact on my thinking on reuse and components, as well as undertaking the important task of showing me the nightlife of Boston.

Applying the health care models to corporate finance in Chapter 4 was the experience that, for me, proved the usefulness of analysis patterns across different domains. Lynne Halpin and Craig Lockwood led the MBFW team at Xerox, and Vivek Salgar got our conceptual ideas into the brutal reality of C++.

David Creager, Steve Shepherd, and their team at Citibank worked with me in developing the models from which I drew the financial patterns in Chapters 9-11. They also further developed many of the architectural ideas of Chapter 12 from their health care origins, and taught me much about the frenetic life in The City.

Fred Peel set up and maintained my work at Citibank, when not scaring me with his driving.

Daniel Poon and Hazim Timimi from Valbecc got many of my fuzzy ideas into detailed specifications.

The accounting patterns in Chapter 6 have had a long gestation. Tom Daly, Peter Swettenham, Tom Hadfield, and their respective teams developed models that gave birth to the patterns in this book. Rich Garzaniti got my accounting terminology sorted out. Kent Beck did much to improve my Smalltalk.

Chapter 14 was written with the help of James Odell.

I have been very much a latecomer to the patterns community, getting to know it well only after most of this book was written. It is a very open and friendly group that has done much to encourage my work. Kent Beck, Ward Cunningham, and Jim Coplein encouraged me to get involved with the community and to develop my ideas as patterns. Ralph Johnson provided particularly helpful comments on the first draft of this book.

I have had first-class comments from my many reviewers whom I would like to name: Dave Collins, Ward Cunningham (Cunningham & Cunningham, Inc.), Henry A. Etlinger (Department of Computer Science, RIT), Donald G. Firesmith (Knowledge Systems Corporation), Erich Gamma, Adele Goldberg, Tom Hadfield (TesserAct Technology), Lynne Halpin (Netscape Communications), Brian Henderson-Sellers, Neil Hunt (Pure Software), Ralph E. Johnson (University of Illinois at Urbana-Champaign), Jean-Pierre Kuilboer (University of Massachusetts, Boston), Patrick D. Logan (Intel Corporation), James Odell, Charles Richter (Objective Engineering, Inc.), Douglas C. Schmidt (Washington University), and Dan Tasker. I will mention that Don Firesmith went above the call of duty in tracking down problems that needed to be fixed.

As this is my first book, I'm particularly grateful to those at Addison-Wesley who helped me through the process. Carter Shanklin directed affairs and assembled a formidable panel of reviewers with much assistance from Angela Buenning. Teri Hyde coordinated the book production on a painfully tight schedule and Barbara Conway rescued my prose from its usual erratic state, and ruthlessly eliminated my native accent.

0201895420P04062001

Read More Show Less

Customer Reviews

Average Rating 4.5
( 3 )
Rating Distribution

5 Star

(1)

4 Star

(2)

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 all of 3 Customer Reviews
  • Anonymous

    Posted November 29, 2005

    A bit dated in a few spots, but quite good

    This is Martin Fowler's first book, published in 1997. The book is divided into two large sections. The first section details analysis patterns that Fowler has encountered across industries. These chapters cover several common domain patterns including representing organizational hierarchies, inventory, accounting, and others. Fowler approaches these chapters by starting with a simple model and repeatedly expanding on this model to fit more and more complex needs. This section of the book is interesting from an academic and a practical perspective. It was interesting to see how Fowler has approached different domain problems and I expect to reference these chapters as I tackle similar problems in the future. The second section of the book covers what Fowler calls Support Patterns. In these chapters Fowler discusses tiered architecture, presentation layers, facades, and association patterns. The second section on support patterns is less useful and some chapters are quite dated. While this information may have been useful in 1997, if you are looking for more information on layered architectures read Enterprise Application Architecture - a more recent book by the same author. I found this book to be quite good. I enjoy Fowler's style of writing and for the most part I found the book easy to follow. However, this is Fowler's first book and it lacks the polish of his more recent other books -- in a few spots it was hard for me to follow the author's train of thought. This book predates UML and the diagrams used throughout the book take a while to understand. There is a key to the models on the inside cover of the book, but if the diagrams had been updated to UML they would have been easier to understand. If needed, you can find UML diagrams for this book on Martin Fowler's website. I think sample code would have helped clarify some of the models as well, as was used in the 'Gang of Four' book. If you are designing a domain model for a complex business, I think this book would be useful for you. If you are looking for similar books, I would suggest Design Patterns by Gamma, et al. ('Gang of Four' book), Patterns of Enterprise Application Architecture, and Refactoring both by Fowler.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted December 11, 2000

    Invaluable for Fairly New Builders of Trading Systems

    Analysis Patterns devotes a number of chapters to describing how the basic (core) elements of trading systems might be modeled in an OOP environment. When, I first read those trading chapters in Martin's book a year ago, I didn't find the material easy going. It was only later, I came to truly understand and appreciate much of the material after I had a chance to work on some additional releases of a large trading system. The fact that some of the material is presented in the style of a college text book by referencing other works didn't help my original efforts to understand it. However, I will say, that if you are involved in the modeling or building of an OOP trading system, (and use some modeling language such as UML), then this book is a good buy. The more experience you have with trading applications the easier the read will be. Most importantly, it outlines some keep practical considerations to modeling trading systems. Now that I'm involved with designing a new trading system, I'm again busy reading Martin's book. In fact, I've just bought an additional copy for the office. In the future, I'd love to see more on domain models for businesses.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 15, 2011

    No text was provided for this review.

Sort by: Showing all of 3 Customer Reviews

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