How to build Shlaer-Mellor object models
Author(s)
Bibliographic Information
How to build Shlaer-Mellor object models
（Yourdon Press computing series）
Yourdon Press, c1996
Available at / 3 libraries
-
No Libraries matched.
- Remove all filters.
Note
Includes bibliographical references and index
Description and Table of Contents
Description
In their attempts to apply the highly effective Object-Oriented Analysis method to real projects, many engineers often encounter numerous organizational, political, and technical obstacles that hamper their success with OOA and discourage their efforts. For such engineers, this easy-to-use reference guide is the next best thing to having an expert OOA analyst at their side. KEY TOPICS: Identifies the common organizational, political, and technical obstacles and provides practical solutions, illustrated with anecdotes and examples. MARKET: For engineers working on projects where the Shlaer/Mellor Object-Oriented Analysis (OOA) method is being applied.
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.
by "Nielsen BookData"
