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.
Leon Starr
San Francisco, California
Acknowledgments
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.
Foreword
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.
Sally Shlaer
Stephen J. Mellor
Berkeley, California
To mom and dad