How to Build Shlaer-Mellor Object Models / Edition 1

Paperback (Print)
Buy New
Buy New from BN.com
$67.74
Used and New from Other Sellers
Used and New from Other Sellers
from $2.06
Usually ships in 1-2 business days
(Save 97%)
Other sellers (Paperback)
  • All (13) from $2.06   
  • New (4) from $44.91   
  • Used (9) from $2.06   

Overview

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-worl experience, and these examples are used to make concrete the abstractions 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.
Read More Show Less

Product Details

  • ISBN-13: 9780132076630
  • Publisher: Pearson Technology Group 2
  • Publication date: 6/25/1996
  • Series: Yourdon Press Series
  • Edition number: 1
  • Pages: 340
  • Product dimensions: 7.50 (w) x 9.25 (h) x 0.71 (d)

Read an Excerpt

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

Read More Show Less

Table of Contents

1 Objects 3
2 Attributes 23
3 Relationships 47
4 Binary relationships 61
5 Associative relationships 77
6 Basic supertype relationships 93
7 Advanced supertype relationships 115
8 How to avoid model hacking 143
9 Why write model descriptions? 153
10 How to write object descriptions 165
11 How to write attribute descriptions 181
12 How to write relationship descriptions 199
13 Is zero-one-many specific enough? 209
14 Reflexive patterns 215
15 Network patterns 223
16 Linear patterns 237
17 Tree Patterns 261
Index 281
More patterns and OOA updates 311
Read More Show Less

Preface

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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted October 12, 2010

    prompt delivery, book condition as advertised

    The book I received was brand new, though the quality of the print was not as I expected from Yourdon Press. There were two layers of weather-proof packaging which preserved the condition of the softcover. Delivery was within 2 weeks even at this opposite end of the world.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)