Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 361 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
361
Dung lượng
1,82 MB
Nội dung
Symbols for mappings DLKING , : www.dlking.com Generalization notation DLKING , : www.dlking.com Contents Foreword v Foreword vii Preface xv Chapter Introduction 1.1 Conceptual Models 1.2 The World of Patterns 1.3 The Patterns in this Book 1.4 Conceptual Models and Business Process Reengineering 1.5 Patterns and Frameworks 11 1.6 Using the Patterns 11 References 14 Part Analysis Patterns Chapter Accountability 15 17 2.1 Party 18 2.2 Organization Hierarchies 19 2.3 Organization Structure 21 2.4 Accountability 22 2.5 Accountability Knowledge Level 2.6 Party Type Generalizations 27 2.7 Hierarchic Accountability 28 2.8 Operating Scopes 30 2.9 Post 32 References 33 Chapter Observations and Measurements 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 24 35 Quantity 36 Conversion Ratio 38 Compound Units 39 Measurement 41 Observation 42 Subtyping Observation Concepts Protocol 46 Dual Time Record 47 46 IX DLKING , : www.dlking.com 10 x Contents 3.9 Rejected Observation 48 3.10 Active Observation, Hypothesis, and Projection 3.11 Associated Observation 50 3.12 Process of Observation 51 References 55 Chapter Observations for Corporate Finance 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 References 83 Chapter Referring to Objects 57 82 85 5.1 Name 86 5.2 Identification Scheme 88 5.3 Object Merge 90 5.4 Object Equivalence 92 References 93 Chapter 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 49 Contents xi Chapter Using the Accounting 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 Models 133 Structural Models 134 Implementing the Structure 137 Setting Up New Phone Services 138 Setting Up Calls 142 Implementing Account-based Firing 143 Separating Calls into Day and Evening 143 Charging for Time 145 Calculating the Tax 148 Concluding Thoughts 150 References 155 Chapter 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 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 References 223 DLKING , : www.dlking.com 216 xii Contents Chapter 11 Trading Packages 225 11.1 Multiple Access Levels to a Package 11.2 Mutual Visibility 230 11.3 Subtyping Packages 233 11.4 Concluding Thoughts 234 References 235 Part Support Patterns 226 237 Chapter 12 Layered Architecture for Information Systems 12.1 Two-Tier Architecture 240 12.2 Three-Tier Architecture 242 12.3 Presentation and Application Logic 12.4 Database Interaction 251 12.5 Concluding Thoughts 255 References 256 Chapter 13 Application Facades 239 245 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 References 295 DLKING , : www.dlking.com 295 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 References Part Appendix 309 310 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 Index 331 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 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 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 DLKING , : www.dlking.com ... simple examples Analysis Patterns: Reusable Object Models is a different kind of book Instead of focusing on the process—how to modeling—it concentrates on the result of the process—the models themselves... Odell Object- Oriented Methods: A Foundation Englewood Cliffs, NJ: Prentice-Hall, 1995 DLKING , : www.dlking.com Introduction 1.1 Conceptual Models Most books on object modeling talk about analysis. .. models Despite a few tricky areas (see Chapter 14), the resulting models are not difficult to turn into object- oriented software One caution I need to raise now, however, is that conceptual models