Martin Fowler 1997

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.

The analysis patterns

Fowler provides chapters on:

Accountability	The concept of accountability applies when a person or organisation is responsible to another. It is an abstract notion that can represent many specific issues, including organisation structures, contracts, and employment. These analysis patterns look at describing relationships that define responsibilities between those types of parties. See AccountabilityDesign.
Observations and Measurements	This is about recording information about objects in the real world. Information can be represented in computer systems as records, attributes, objects, and various other representations. The typical route is to record a piece of information as an attribute to an object. For example, the fact that I weigh 80 kgs would be recorded in an attribute of a person type. This group of analysis patterns suggests more sophisticated approaches and why the example described fails. Also included here are Observation for Corporate Finance.
Referring to Objects	Within an OO computer system, each object has a unique ID, which is used as a guarantee that any object can be directly accesssed. We still need some way to refer to a particular object though: For example, I might need to find a particular person to whom I need to send a bill, and a doctor may need to mark a patient down as suffering from diabetes. Object systems provide us with powerful browsing capabilities that exploit the natural relationships between conceptual objects, but sometimes a more explicit identifier is required. These analysis patterns are about conceptual references to objects - references that humans use. That is, the indexing we need when referring exactly to objects in our working life.
Inventory and Accounting	A large proportion of commercial computing systems are designed to track the money moving through an enterprise, recording how it is earned and spent. The fundamental idea behind accounting and inventory tracking is that there are various pots of money and good, and we must record how money and goods move among these pots. The analysis patterns here are born from this fundamental idea. They present a core set of concepts that we can use as the basis for financial accounting, inventory, or resource management. The patterns do not describe these processes directly, rather they describe the underlying ideas from which processes can be built. See: AccountingPatterns
Planning	Planning is a vital part of any large endeavor. Many managers spend most of their time developing and tracking plans. These analysis patterns here, examine the relation ship between standard plans and one-off plans, and how to plan and record the use of resources.

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.

See also

• Analysis patterns
• Design patterns
• Domain modelling