Analysis Patterns.Pdf

Symbols for mappings DLKING , : www.dlking.com Generalization notation DLKING , : www.dlking.com Contents Foreword v Foreword vii Preface xv Chapter 1. Introduction 1 1.1 Conceptual Models 1 1.2 The World of Patterns 4 1.3 The Patterns in this Book 8 1.4 Conceptual Models and Business Process Reengineering 10 1.5 Patterns and Frameworks 11 1.6 Using the Patterns 11 References 14 Part 1. Analysis Patterns 15 Chapter 2. Accountability 17 2.1 Party 18 2.2 Organization Hierarchies 19 2.3 Organization Structure 21 2.4 Accountability 22 2.5 Accountability Knowledge Level 24 2.6 Party Type Generalizations 27 2.7 Hierarchic Accountability 28 2.8 Operating Scopes 30 2.9 Post 32 References 33 Chapter 3. Observations and Measurements 35 3.1 Quantity 36 3.2 Conversion Ratio 38 3.3 Compound Units 39 3.4 Measurement 41 3.5 Observation 42 3.6 Subtyping Observation Concepts 46 3.7 Protocol 46 3.8 Dual Time Record 47 IX DLKING , : www.dlking.com x Contents 3.9 Rejected Observation 48 3.10 Active Observation, Hypothesis, and Projection 49 3.11 Associated Observation 50 3.12 Process of Observation 51 References 55 Chapter 4. Observations for Corporate Finance 57 4.1 Enterprise Segment 59 4.2 Measurement Protocol 65 4.3 Range 76 4.4 Phenomenon with Range 77 4.5 Using the Resulting Framework 82 References 83 Chapter 5. Referring to Objects 85 5.1 Name 86 5.2 Identification Scheme 88 5.3 Object Merge 90 5.4 Object Equivalence 92 References 93 Chapter 6. Inventory and Accounting 95 6.1 Account 97 6.2 Transactions 98 6.3 Summary Account 101 6.4 Memo Account 103 6.5 Posting Rules 104 6.6 Individual Instance Method 106 6.7 Posting Rule Execution 111 6.8 Posting Rules for Many Accounts 116 6.9 Choosing Entries 118 6.10 Accounting Practice 119 6.11 Sources of an Entry 122 6.12 Balance Sheet and Income Statement 123 6.13 Corresponding Account 124 6.14 Specialized Account Model 125 6.15 Booking Entries to Multiple Accounts 127 Further Reading 132 References 132 DLKING , : www.dlking.com Contents xi Chapter 7 Using the Accounting 7.1 Models 133 7.2 Structural Models 134 7.3 Implementing the Structure 137 7.4 Setting Up New Phone Services 138 7.5 Setting Up Calls 142 7.6 Implementing Account-based Firing 143 7.7 Separating Calls into Day and Evening 143 7.8 Charging for Time 145 7.9 Calculating the Tax 148 Concluding Thoughts 150 References 155 Chapter 8. Planning 157 8.1 Proposed and Implemented Action 158 8.2 Completed and Abandoned Actions 160 8.3 Suspension 161 8.4 Plan 162 8.5 Protocol 165 8.6 Resource Allocation 168 8.7 Outcome and Start Functions 172 References 174 Chapter 9. Trading 175 9.1 Contract 176 9.2 Portfolio 180 9.3 Quote 185 9.4 Scenario 188 References 196 Chapter 10. Derivative Contracts 197 10.1 Forward Contracts 198 10.2 Options 200 10.3 Product 205 10.4 Subtype State Machines 211 10.5 Parallel Application and Domain Hierarchies 216 References 223 DLKING , : www.dlking.com xii Contents Chapter 11. Trading Packages 225 11.1 Multiple Access Levels to a Package 226 11.2 Mutual Visibility 230 11.3 Subtyping Packages 233 11.4 Concluding Thoughts 234 References 235 Part 2. Support Patterns 237 Chapter 12. Layered Architecture for Information Systems 239 12.1 Two-Tier Architecture 240 12.2 Three-Tier Architecture 242 12.3 Presentation and Application Logic 245 12.4 Database Interaction 251 12.5 Concluding Thoughts 255 References 256 Chapter 13. Application Facades 257 13.1 A Health Care Example 258 13.2 Contents of a Facade 259 13.3 Common Methods 262 13.4 Operations 264 13.5 Type Conversions 265 13.6 Multiple Facades 267 References 269 Chapter 14. Patterns for Type Model Design Templates 271 14.1 Implementing Associations 274 14.2 Implementing Generalization 281 14.3 Object Creation 289 14.4 Object Destruction 290 14.5 Entry Point 291 14.6 Implementing Constraints 294 14.7 Design Templates for Other Techniques 295 References 295 DLKING , : www.dlking.com Contents xiii Chapter 15. Association Patterns 297 15.1 Associative Type 298 15.2 Keyed Mapping 301 15.3 Historic Mapping 303 References 307 Chapter 16. Afterword 309 References 310 Part 3. Appendix 311 Appendix A. Techniques and Notations 313 A.1 Type Diagrams 313 A.2 Interaction Diagrams 325 A.3 Event Diagrams 326 A.4 State Diagrams 327 A.5 Package Diagrams 328 References 330 Appendix B. Table of Patterns 331 Index 343 DLKING , : www.dlking.com 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 xv DLKING , : www.dlking.com xvi Preface 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.

Load more