Home > Store

How to Build Shlaer-Mellor Object Models

Register your product to gain access to bonus material or receive a coupon.

How to Build Shlaer-Mellor Object Models

Book

  • Sorry, this book is no longer in print.
Not for Sale

About

Features

  • considers the non-technical problems in using OOA — e.g., how to get constructive input on the information models being developed.
  • discusses possible technical problems in using OOA.
  • explores documentation problems in using OOA.
  • features step-by-step, illustrated examples that demonstrate the thinking that leads to a solution.
  • provides a quick notational reference in an appendix.

Description

  • Copyright 1996
  • Dimensions: 8" x 10"
  • Pages: 336
  • Edition: 1st
  • Book
  • ISBN-10: 0-13-207663-2
  • ISBN-13: 978-0-13-207663-0


20766-2

This book shows you how to build Object Information models that:

  • Resolve complex, subtle and conflicting application requirements
  • Lead to simplified state and process models
  • Can be translated into a reliable implementation

Plus Practical Advice On:

  • How to write useful model descriptions
  • How to get the most out of binary, reflexive, associative and supertype relationships
  • How to compare different model solutions of the same problem and pick the best one

Sample Content

Table of Contents



1.  Objects.

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.

Object categories.

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?



2.  Attributes.

What is an attribute?

Purpose • Descriptive attributes • Naming attributes • Naming or descriptive?

Identification role.

Single attribute identifiers • Compound identifiers • Multiple identifiers • Overlapping identifiers • Dependence on other attributes • Dependence on the identifier • Dependence on the whole identifier.

Value assignment.

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.

Origin.

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?



3.  Relationships.

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.



4.  Binary relationships.

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.

Conditional relationships.

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.

More examples.



5.  Associative relationships.

Creating a non-associative relationship instance.

Creating an associative relationship instance.

Why create an associative object?

Multiplicity.

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?



6.  Basic supertype relationships.

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?



7.  Advanced supertype relationships.

Multi-directional supertyping.

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.

Multi-level supertyping.

Better precision • Better adaptation to future requirements.

Questions that probe deeper.

Overlapping supertypes (selective generalization).

Overlapping sets.

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.

Summary.

How to build useful models.



8.  How to avoid model hacking.

The symptoms of model hacking.

The difference between modeling and analysis.

Focus on the analysis • Draw informal sketches.

Formal models vs. informal sketches.



9.  Why write model descriptions?

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.

Save time.

Improve progress in other subsystems • Get quality feedback • Control the implementation • Priorities change all the time.

Summary.



10.  How to write object descriptions.

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.

Describe behavior.

Don’t describe detailed behavior.

Don’t be wishy-washy.

How long should an object description be?

How much explanation is necessary?

Summary.



11.  How to write attribute descriptions.

Attribute categories.

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.

Coordinates.

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.



12.  How to write relationship descriptions.

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!

Summary.

Model patterns.



13.  Is zero-one-many specific enough?

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.

Conclusions.



14.  Reflexive patterns.

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.



15.  Network patterns.

Adjacent territories.

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.



16.  Linear 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.

Conclusion.

Summary.



17.  Tree patterns.

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.

Boundary cases.

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.

So what?

How much modeling is too much?

Make a decision, move on and learn from it.

Summary.

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

Updates

Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020