Analysis Patterns: Reusable Object Models by Martin Fowler

Martin Fowler.
Analysis Patterns: Reusable Object Models
Addison-Wesley, 1997.
ISBN 0-201-89542-0 [ See this book at Amazon.com]

Table of Contents

Preface

p. xv

Here is the author's definition of a pattern: "A pattern is an idea that has been useful in one practical context and will probably be useful in others."

"This book is about patterns in analysis, patterns that reflect conceptual structures of business processes rather than actual software implementations."

Introduction

p. 1

"Most books on object modeling [sic] talk about analysis and design. There is little agreement on where the boundary between these two activities lies. An important principle in object development [sic] is designing software so that its structure reflects that of the problem. One result of this principle is that the models produced from both analysis and design end up deliberately similar ..."

"... 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."

p. 2

"Modeling Principle   Models are not right or wrong; they are more or less useful."

p. 3

"... It is essential to have domain experts involved in conceptual modeling."

p. 4

"One caution I do need to raise now, however, is that conceptual models relate closely to software interfaces rather than software implementations. One of the important things about object-oriented software is that it separates interface from implementation."

"Modeling Principle   Conceptual models are linked to interfaces (types) not implementations (classes)."

p. 6

"It is commonly said that a pattern, however it is written, has four essential parts: a statement of the context where the pattern is useful, the problem that the pattern addresses, the forces that play in forming a solution, and the solution that resolves those forces. ... it supports the definition of a pattern as "a solution to a problem in a context", a definition that [unfortunately] fixes the bounds of the pattern to a single problem-solution pair."

p. 7

"... any technical writing ususally includes context, problem, forces, and solution."

"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."

p. 13

"Modeling Principle   Patterns are a starting point, not a destination."

Techniques and Notations

p. 313

"The type diagram shows a structural view of a system [not a problem?]. It concentrates on describing the types of objects in the system and various kinds of static relationships that exist among them. The two most important kinds of relationshiops are associations ... and subtypes."

p. 314

"The second problem [with using UML for the purposes of this book] is that the Unified Modeling Language concentrates on implementation modeling rather than conceptual modeling ..."

"... A type describes the interface to a class ..."

"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."

p. 315

"Specification models are models that can be used to define the interface of the software components in the system."

"Implementation models lay bare the internals of a class."

p. 315

"Associations represent relationships among instances of types." [I don't understand this if you view a type as an interface.]

"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?]

p. 318

"Inheritance and subclassing in OO languages is an implementation approach in which the subclass inherits the data and operations of the super class. It has a lot in common with subtyping, but there are important differences. Subclassing is only one way of implementing subtyping ... Subclassing can also be used without subtyping--but most authors rightly frown on this practice. Newer languages and standards increasingly try to emphasize the difference between interface-inheritance (subtyping) and implementation-inheritance (subclassing)."

p. 319

"Two questions arise concerning the relationship between an object and a type. First, does an object have single type that can inherit from supertypes (single classification), or does it have several types (multiple classification)? Multiple classification is different than multiple inheritance. With multiple inheritance a type can have many supertypes, but each instance is of a sinle type that may have supertypes. Multiple classification allows multiple types for an object without defining a specific type for the purpose."

"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."

p. 320

"In a conceptual model all subtyping is considered dynamic, unless explicitly denied by the short semantic statement [immutable]."

p. 321

"Associations and subtypes allow us to say much about types, but not all. ... A constraint is a logical expression about a type that must always be true. Constraints are often missing from OO methods although they have been present in Eiffel (where they are called invariants) for a long time."

p. 323

"In traditional data modeling the world is often divided into entities and attributes. The division is somewhat arbitrary."