Martin Fowler.compiled by Tom Verhoeff in March 2003. Bold face emphasis is mine.
Analysis Patterns: Reusable Object Models
ISBN 0-201-89542-0 [ See this book at Amazon.com]
|Part 1||Analysis Patterns||15|
|3||Observations and Measurements||35|
|4||Observations for Corporate Finance||57|
|5||Referring to Objects||85|
|6||Inventory and Accounting||95|
|7||Using the Accounting Models||133|
|Part 2||Support Patterns||237|
|12||Layered Architecture for Information Systems||239|
|14||Patterns for Type Models||271|
|A||Techniques and Notations||133|
|B||Table of Patterns||133|
"This book is about patterns in analysis, patterns that reflect conceptual structures of business processes rather than actual software implementations."
"... When doing analysis you are trying to understand the problem. To my mind this is not just listing requirements in use-cases ... Analysis also involves looking behind the surface requirements to come up with a mental model of what is going on in the problem."
"Modeling Principle Conceptual models are linked to interfaces (types) not implementations (classes)."
"One principle of pattern form that I do agree with unreservedly is taht they should be named. ... [so] we can communicate our design ideas [sic: not analysis?] very effectively. ... it is a common technique of technical writing [and any commercial, religious, ... communication] to coin new terms for concepts, but looking for patterns encourages this process."
"I find it useful to think about building type diagrams from three perspectives: conceptual, specification and implementation. Conceptual models model the way people think about the world."
"Implementation models lay bare the internals of a class."
"In this book I consider an attribute to be the same as a single-valued mapping. Sometimes I show an attribute inside a type's rectangle, sometimes with an association. The difference is merely that of notational convenience."
"Some [design and analysis] methods use aggregation relationships, which are part/whole relationships. ... I don't find the concept terribly useful for domain models, because most of its semantics are on any association." [Do you understand the latter part of that sentence?]
"The second question is whether an object can change its type. ... Dynamic classification allows objects to change type within the subtyping structure, while static classification does not."
"One way of looking at dynamic classification is that it unifies the notions of state and type. When using static classification we must pay attention to state-dependent behavior separately from subtyping. Dynamic classification treats both the same."