This book shows you how to build Object Information models that:
Plus Practical Advice On:
What is an object?
The object symbol.
The difference between objects and instances.
Anatomy of an object table.
Object table rules.
All attribute values are atomic.
Instance order is ignored.
Attribute order is ignored.
Each instance is unique.
Hard or physical objects • Soft objects • Discovered objects • Invented objects • Simulated objects • Specification objects • Incident objects • Interaction objects • Role objects.
Frequently asked questions about objects.
Is it okay to have an object with only one attribute? • Can an object have only one instance? • What does it mean when an object is drawn with a dashed border?
What is an attribute?
Purpose • Descriptive attributes • Naming attributes • Naming or descriptive?
Single attribute identifiers • Compound identifiers • Multiple identifiers • Overlapping identifiers • Dependence on other attributes • Dependence on the identifier • Dependence on the whole identifier.
Changing a non-identifier value • Changing an identifier value • Universal meaning • Always applicable • Never applicable (for some instances) • Not applicable—at the moment • Delayed assignment • More than one meaning.
Native attributes • Referential attributes • Origin and identifiers.
Summary of Attribute Properties.
Frequently asked questions about attributes.
How many attributes can an object have? • How do I know I have all of the attributes? • The S-M method seems to require a lot of invented ID’s. Isn’t that inefficient?
What is a relationship?
Abstracting a relationship • The relationship symbol • Relationships and rules • Relationships define application policies • Example 1: Master shapes • Example 2: Copied shapes.
Relationships are important.
Relationship types • Visualizing relationship types • Snapshot notation • Type 1: Binary Relationships • Binary relationships and relationship instances • Type 2: Associative Relationships • Type 3: Supertype Relationships.
And now for some examples.
Don’t get instances and abstractions confused.
How to keep it all straight.
Icons • Blobs, dots and arcs • Tables • Non-reflexive binary relationships • Multiplicity • One to one • One to many • Many to many.
Where to put the referential attribute • Reflexive relationships • When to use a reflexive relationship • Why a sequence can’t be numbered • How to formalize a reflexive relationship • Graphic representation of reflexive relationships.
Creating a non-associative relationship instance.
Creating an associative relationship instance.
Why create an associative object?
Assign attributes to a relationship • Model the behavior of a relationship • Multiplicity on associative relationships • Single associative multiplicity • Many associative multiplicity • Decomposing a many-associative • Decompose M-(n:n) relationships.
Conditionality on associative relationships.
Conditionality on one side • Conditionality on both sides.
Frequently asked questions about associative relationships.
Shouldn’t there be a diamond on associative relationships? • Can more than three objects participate in an associative relationship? • Do I put R’s on the identifiers in the associative object? • How do I name an associative object?
Supertype or subtype?
What is a supertype relationship? • What the supertype relationship does • Set partitioning • Set membership • When to use supertype relationships.
Generalization and specialization.
Specialization • Generalization • Mutual exclusion • More exclusion • How supertypes are formalized • Supertype identifier policies • Policy #1: Instances are born in the supertype (trickle down) • Policy #2: Instances are born in the subtypes (percolation).
Which policy should you use?
Use existing policies • Impose a labeling scheme.
Frequently asked questions about supertype relationships.
When should an object be subtyped according to its states?
Is multi-directional subtyping legal? • Multi-directional subtype identifier schemes • Trickle down—multi-directional • Percolate up—multi-directional • Why multi-directional subtyping is usually a bad idea.
Better precision • Better adaptation to future requirements.
Questions that probe deeper.
Overlapping supertypes (selective generalization).
Eliminating duplicate attributes.
The danger of supertype hacking.
Don’t waste time with minute details.
How to avoid thrashing.
How to organize subtype levels.
Subtype migration • Migrating subtypes • Non-migrating subtypes • When to subtype an object according to its states • Look for states where relationships and attribute relevance changes • Don’t overdo the hierarchical thing • Sometimes the wrong thing is subtyped.
How to build useful models.
The symptoms of model hacking.
The difference between modeling and analysis.
Focus on the analysis • Draw informal sketches.
Formal models vs. informal sketches.
How do you write good descriptions?
Five reasons to write model descriptions • The goals of technical notes and model descriptions are different • Don’t get cocky • The video effects application.
The issue that wouldn’t die.
A decision was made • How the issue resurfaced.
Improve progress in other subsystems • Get quality feedback • Control the implementation • Priorities change all the time.
Describe meaning—not syntax.
Use both drawings and text.
Use drawings to communicate • Use drawings to analyze • Illustrate physical objects • Illustrate soft objects.
Use terminology appropriate to the problem domain.
Refer to other model elements in the same problem domain.
Don’t describe detailed behavior.
Don’t be wishy-washy.
How long should an object description be?
How much explanation is necessary?
Descriptive attribute descriptions.
Use pictures • Clarify the meaning of the attribute • Descriptive numeric domains • Don’t be wishy-washy.
Measurements need units.
Quantities don’t need units.
Specify precision when it is crucial to the application.
Avoid implementation data.
Specify the coordinate system • Internal constraints.
Descriptive set attributes.
Close set—Status • Close set—Types • Open Sets • Not quite so open sets.
Constraining a domain with a specification object.
Descriptive name attributes.
Invented identifiers • Found identifiers.
Referential attribute descriptions.
Use the active voice • Refer to the original description • Referenced attribute groups.
Why relationship descriptions are neglected.
What can you say about relationships?
Let’s get confused.
What every relationship description must contain.
The heading • The meaning • Multiplicity and conditionality • Formalization.
Don’t write the relationship descriptions last!
Why Shlaer-Mellor doesn’t use numbers.
A case where zero-one-many isn’t enough.
An attempt at modeling two-ness.
The trick is to abstract the positional roles as objects.
Reflexive relationships and graphs.
Modeling graph constraints.
Reflexive models can be trivial • Reflexive models can get ugly • But don’t worry.
Self-referencing in analysis and programming.
Isn’t self-referencing an implementation concept?
Like all relationships, a reflexive relationship can be viewed from two perspectives.
Implementation mechanisms disguised as application policy.
Simple and complex graphs.
No islands, acyclic • Making a relationship acyclic • Communicating processes • Cycles, islands, and single connections • Cycles, islands, and multiple connections.
A,B and B,A mean the same thing.
Directional and multiple.
Making the graph directional • Multiple non-directed Channels • Multiple directed Channels • Bi-directional Channels.
Separating Channel from Data Flow.
Subtyping by role.
Summary—really important stuff.
Important advice about using patterns.
Example 1: Mission editor in a flight simulator.
Connecting the waypoints.
Adding battle units to follow the Waypoints • Adding the Route object • Those unsightly gaps between Waypoints • Closed Routes—another dead end.
Taking another look.
Subtyping by position • Subtyping by referencing role • Subtyping both ways.
Precluding malformed Routes.
The boundary condition—minimal Route.
The Solution—adding a special case for the Start Waypoint.
Mission editor summary.
Which linear pattern model should you use?
The simpler the information model—the more complex the state model.
Early exposure argues for capturing as many rules as possible in the information model.
Example #2: Polyline draw tool in an illustration program.
A simple tree.
A simple tree of parts • Problem: Part storage is sloppy • A tree with a root • Only Assemblies are stored • A tree with leaves • Vendor supplied parts.
Stealing and adapting the linear pattern.
A review of parts vocabulary.
The danger of diluting object meanings.
Better semantics • When is and when isn’t a Part in an Assembly?
What does a Warehouse really store?
The finished product.
How much modeling is too much?
Make a decision, move on and learn from it.
This book is a collection of models, modeling tips, and analysis tech- niques that have worked for me (and my colleagues) on real projects. It conveys some of the experience that I have gained in 10 years of build- ing Shlaer-Mellor models. I have written this book for those of you who have had an introduction to the Shlaer-Mellor method through some combination of courses and books. I presume that you are either about to start applying the method on your project, or that you have been building Shlaer-Mellor models for a year or two. This text is geared toward those of you who do the hard work of boiling down application requirements, formalizing these requirements into fully detailed models and in getting those models translated into working software.
This book is not a complete statement or grammar of the Shlaer-Mellor modeling language. For that, you need to read the books by Steve and Sally. Instead I show you some of the ways that I use important features of the object modeling language. I also provide some guidance in how to deal with a few thorny issues.
Experience on multiple projects has taught me many things. One of the most important lessons is that you can't skimp on the information mod- els and get away with it. You must ensure that your application require- ments are thoroughly captured, in great detail, in your information models. This takes time and hard work. Whenever my colleagues and I have cut corners we have run afoul of the following consequences: 1) the state models become ridiculously complex; 2) one or two critical requirements lie hidden until late in the modeling process leading to time consuming re-work; 3) new requirements which should have been anticipated arise late in the modeling process and wreak havoc. On the other hand, a good information model leads to simple, stable state mod- els. This book focuses on building good information models because that is the key to success.
Coming from a function-oriented programming background, learning to build information models has been challenging to say the least. I've noticed that engineers new to the Shlaer-Mellor method grapple with many of the same questions that I did: What model structures are legal? (Can I do that with a supertype relationship?), How much detail should go into information model? How do I build a model that won't fall apart when the requirements change? What's the difference between a good information model and a bad information model? Why do I need to write object descriptions? How do I formalize a relationship between exactly three (not zero one or many - but three) things? What's the best way to model a hierarchy of things? Should I ever model a hierarchy? This book contains answers to these questions and many others.
Another big key to success is to use your time effectively. A common mistake is to spend too much time modeling and not enough time doing analysis. Few software engineers appreciate the value of distinguishing the activities of analysis and modeling. I don't know how many times I've seen a novice analyst spend hours building the perfect model to suit a set of perceived requirements. Later on the requirements change, or they turn out to be the wrong requirements, or they turn out to be based on some aspect of the system which is so volatile that no attempt to nail down the requirements can be successful. As a consequence the whole model unravels. I wrote Section XX to show how this kind of disaster can be avoided.
To become a good programmer, not only do you need to write a lot of code, but you also need to look at code written by other people. The same is true when it comes to analysis and modeling. The models in this book will give you something helpful to look at from time to time as you build lots of models. Have fun.
San Francisco, California
This page is for all of the colleagues and friends that helped me create this book and get it out the door.
Here is a list of my beta testers (technical reviewers). They were invalu- able in the task of rooting out flaws in the text, tables, figures and mod- els.
Tonya Bargash, Yeelan Johnson, Michael Lee, Steve Mellor, Walt Murphy, Linda Ruark, Jonathon Sandoe, Sally Shlaer and Phil Zakhour
Highly entertaining conversations with Michael Lee about project man- agement, politics, training and technical issues provided considerable guidance and inspiration which fueled my enthusiasm throughout this project.
Thousands of hours of intensely focused project work with most of my reviewers, as well as Ruth Knipe, provided me with the analysis and modeling experience that made this book possible. Tracy Yim deserves credit for convincing me to start this project and for providing support and encouragement all along the way.
I am thoroughly indebted to Walt Murphy for his highly technical and meticulous evaluation of every chapter and for creating the index.
I would like to thank Candice Kollar and Karen Cornell for the book cover and back design and I would like to thank Judith Jauhal for the photograph.
Lastly, but most importantly, I want to thank Steve Mellor and Sally Shlaer for all of the training, support and especially their method.
Leon Starr's book is a practical guide. It starts from the beginning by explaining the essentials of the method and it illustrates the implications of these essentials as they apply in practice. The book contains a wealth of examples drawn from real-world experience, and these examples are used to make concrete the abstrac- tions you encounter in real projects. The book tells you--and shows you--how to build useful models quickly. There is a good deal of excellent advice on how to manage your own analysis activities to get the most useful models for the least work.
But the heart of the book is the illustration of how to think about a problem by extracting its essential nature. Consider the problems of modeling a sheet with an image on each side, or pipe length separated by a valve. These seemingly trivial problems are more difficult than they appear because they are highly constrained. This book leads you through the choices you must make so that the concept of 'two-sidedness' stands exposed. And you acquire an understanding of the analysis thinking process that led to it.
A glance through the book will show that it focuses on object information model- ing. There are two reasons for this. First, the selection of abstractions is the most important step in the method and these abstractions constitute the framework around which everything else is built. Second, if you get the object information model right, the state models become radically simpler. Mr. Starr knows this from experience: he has built Shlaer-Mellor OOA models for a very wide variety of applications and learned the hard way that the object information model is key.
Leon began work on Shlaer-Mellor models with us at Project Technology, Inc. in 1985. This was before, as he likes to say, his "warranty ran out." It was fun to work with Leon then, and it is now. You will see Leon's twisted sense of humor all over these pages, sometimes belying the depth of his experience. Don't let it fool you. Read the book, learn from it, and--most of all--enjoy it.
Stephen J. Mellor
To mom and dad