Martin Fowler 1997
Contents |
Fowler's analysis patterns book
Analysis Patterns: Reusable Object Models by Martin Fowler.
This is the AnalysisPatterns book. Coming only 2 years after the GangOfFour1995, it extended patterns definitively beyond the realm of design. Most of the chapters discuss patterns for various business domains.
Fowler (p. xv) says:
- "This book is about patterns in analysis, patterns that reflect conceptual structures of business processes rather than actual software implementations."
- "These patterns are important because they help us to understand how people perceive the world."
- "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."
This suggests that analysis patterns are closely related to Domain modelling.
Quotes from the foreward
- "Many of the patterns are more powerful than they might appear at first. Patterns like Accountability can be applied in nearly any project." --Ralph Johnson
- "A growing number of us in the OO development community feel we have misplaced out collective attention for some time. We no longer need to focus on tools, techniques, notations or even code. We already have in our hands the machinery to build great programs. When we fail, we fail because we lack experience."
- "Martin Fowler has found a way to give us what we need: experience in book form." --Ward Cunningham
Updates
This book predates UML, but some [versions] of the diagrams are now on the web.
Fowler is working on [patterns book 2].
Modelling principles
Interspersed with Fowlers analysis patterns are several modelling principles that guide the construction of analysis models. Some relevant ones are:
- Models are not right or wrong; they are more or less useful.
- Conceptual models are linked to interfaces (types) not implementations (classes).
- Patterns are a starting point, not a destination.
- Whenever defining features for a type that has a supertype, consider whether placing the features on the supertype makes sense.
- Explicitly divide a model into operational and knowledge levels.
- When multiple attributes interact with behaviour that might be used in several types, combine the attributes into a new fundamental type.
- The operational level has those concepts that change on a day to day basis. Their configuration is constrained by a knowledge level that changes much less frequently.
- If a type has many many similar associations, make all of these associations objects of a new type. Create a knowledge level type to differentiat between them.
- When more than one equivalent set of features can be provided, pick the one that the domain expert is most comfortable with. If the domain expert feels that both are very valuable, show both and mark one as derived.
- Marking a feature as derived is a constraint on the interface and does not affect the underlying data structures.
- When making a process a feature of a type, the process should be given an abstract interface so that the implementation can easily vary by subclassing. A purely hard-coded implementation is one subclass, various parameter-driven approaches are others.
- A generalization should not be used where the supertype is in a narrow domain and the subtype is widely used.
- If the difference between two similar types is often ignored, then an abstract supertype can be used. If the distinction between them is usually important, then an abstract supertype should not be used.
- If an abstract type never needs more effort for a client to use it, then it should be provided.
- When information can be retrieved from an information source or calculated from other available figures, an abstract interface with sourcing and calculation as subclasses should be provided.
- When faced with alternative approaches, choose the simplest first and change to a more complex one as needed.
- When there is little to choose between modelling alternatives, follow the instincts of the domain expert.
- Subtyping should be used only when all the features of the supertype are appropriate to the supertype and it makes sense conceptually to say that every instance of the subtype is an instance of the supertype.
- Do not duplicate base [non-derived] associations that have the same meanings. Following this principle leads to types with well-separated responsibilities.
- Be consistent in the allocation of responsibilities. Be wary of a type that sometimes is responsible for something and sometimes delegates that responsibility. (This behaviour may be correct but it should always be questioned.)
- The effect of generalization on state charts is not well understood. It is important to ensure that all events on a supertype can be handled by the subtype. Any state chart that can be subtyped must allow unknown events.
- A postcondition defines a condition that must be true of the object after the operation. Other changes that are not mentioned by the postcondition can take place.
- The decision between a one-way and two-way association is a trade-off between less work for the developers of the types involved (by reducing their coupling) and convenience for the users of the types.
- If a package only needs visibility to part of another package, consider splitting the latter package into two mutually visible packages.
Other types of patterns
The book is in two parts. Part Two is smaller, and describes "support patterns", including an early discussion of what are now known as ArchitecturalPatterns and some patterns/idioms for OO relationships.
Architecture
Two tier: Applications directly access databases. Three tier: A domain model tier is inserted between applications and databases. More tiers:
- Presentation (GUI) separated from application logic.
- Database interface separated from DB implementation.
This material is more fully developed in MartinFowler2003.
Associations
Several patterns (idioms?) for handling relationships of various multiplicities and directionalities are presented.
The main idea is the usual many-to-many association class. Fowler notes the constraint that duplicate objects should not be created. The use of dictionaries (Maps) is an alternative.
