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 applicableat 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 IDs. Isnt 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. Dont 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 cant 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. Shouldnt there be a diamond on associative relationships? Can more than three objects participate in an associative relationship? Do I put Rs 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 downmulti-directional Percolate upmulti-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. Dont 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 Dont 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 Dont get cocky The video effects application. The issue that wouldnt 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 meaningnot 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. Dont describe detailed behavior. Dont 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 Dont be wishy-washy. Measurements need units. Quantities dont 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 setStatus Close setTypes 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? Lets get confused. What every relationship description must contain. The heading The meaning Multiplicity and conditionality Formalization. Dont write the relationship descriptions last! Summary. Model patterns. 13.Is zero-one-many specific enough? Why Shlaer-Mellor doesnt use numbers. A case where zero-one-many isnt 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 dont worry. Self-referencing in analysis and programming. Isnt 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. Summaryreally 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 Routesanother dead end. Taking another look. Subtyping by position Subtyping by referencing role Subtyping both ways. Precluding malformed Routes. The boundary conditionminimal Route. The Solutionadding a special case for the Start Waypoint. Mission editor summary. Which linear pattern model should you use? The simpler the information modelthe 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 isnt 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.
