Overview Ordering detials Updates How to Build Shlaer-Mellor Object Models By Leon Starr If you've got a question about any topic, example or figure in my book, send it to me! (I'll respond as soon as I can) Send your questions and comments to: book@modelint.com Contents Is there a story behind the ant? Why does "on-line movie" need a processor-id? "Interaction" vs. "associative" objects How can X-Start and Y-Start be a unique identifier? Corresponding objects vs. instances of an object Is there a story behind the ant? I stole (licensed, actually) the ant concept from my ex-girlfriend Judith (who is also responsible for my photo on the back cover). She used to draw these hilarious comics back when we were living together - way back in the days when I worked at Yourdon. Anyway, I wanted some kind of character to highlight important analysis concepts, but the only character I could draw was a stickman. Sadly, I can't draw anywhere near as well as that Dilbert guy. It turns out that it doesn't take much talent to draw an ant, and they are far more expressive than a boring old stickman. Why does "on-line movie" need a processor-id? (page 49) Regarding the object "on-line movie", why does it need "processor-ID" as part of the identifier if an on-line movie can only belong to one processor? Can't you uniquely identify the on-line movie by it's ID? The Shlaer-Mellor method allows you to model it either way. It depends on how we define the On-line Movie.ID attribute. If we say that On-line Movie.ID is numbered independently on each Movie Processor (M1,M2,M3... on P1 and M1,M2,M3... on P2, ...) then M1-P2 is a different On-line Movie than M1-P1 and we need both the Processor ID and the On-line Movie ID to uniquely identifier an On-Line Movie. On the other hand, if we say that On-line Movie ID is numbered (M1, M2, M3 ...) independent of Movie Processors, then this ID would stand on it's own. The advantage of choosing one approach over another is probably the more interesting question. When you specify the primary identifier of an object, should you create a single-attribute identifier or a multiple-attribute identifier? Model 2.1 on page 26 of my book shows an example where a single-attribute identifier is chosen. In this example, a Camera is an invented object (it represents a point of view in a graphic animation system). Since we get to invent the object, it is easiest to just define a single attribute which will generate a unique value (CAM1, CAM2, ...) for each new instance of Camera. In general, we like to use single-attribute identifiers because they are simple. Figure 2.2 on page 28 shows physical objects in a ring network. The identification policy for Interface instances has each Interface numbered uniquely for each Ring Net. So if we would get (I1,I2, ...) Interfaces in Ring Net R1, then (I1, I2, ...) Interface instances in Ring Net R2, and so forth. There were two motivations for taking this multiple-attribute identifier approach for the Interface object. First, in the Ring Net application, we just felt more comfortable thinking about Interfaces numbered this way than uniquely across all Ring Nets. I'm not sure why, but it just was. Second, the multiple-attribute strategy makes it possible to formalize the PRECEDES relationship so that you can't accidentally specify an Interface in Ring Net R1 which precedes an Interface in Ring Net R2. You don't need any special logic in the state models to ensure that Interfaces are adjacent only to other Interfaces in the same Ring Net as you would if you took a single-attribute identifier approach on the Interface object. Finally, Model 2.3 on page 27 shows another reason for choosing a multiple-attribute identification strategy. In this example we are modeling pieces on a chess board which I would call Discovered Objects since we are capturing soft objects (it's a computer game) but the rules are already well defined prior to the analysis. These rules provide three mechanisms for guaranteeing the uniqueness of any piece on the board - each of which is a multiple-attribute identifier policy. But the Shlaer-Mellor method permits you to create yet another attribute, Chess Piece.ID, for example that could hold values like (P1,P2,...). I would have to see the rest of the information model to decide whether or not this invented single-attribute identifier simplified the model sufficiently to justify its addition. The factors that influence driving identification policy selection are: a) making the application policies as clear as possible b) model simplification c) ease of relationship formalization ... pretty much in that order of importance. "Interaction" vs. "associative" objects. (pages 15-16) Aren't an "interaction" object and an "associative" object one and the same, why say Interactions are modeled with associative objects and confuse the concept? One or the other? They are not the same thing. An associative object is part of the Shlaer-Mellor object modeling language. It is a mechanism for formalizing a binary relationship between objects A and B. You take the ID of object A and the ID of object B and put them together in an associative object C, and voila, you've formalized the relationship. If the binary relationship is many to many (M:M), then you must create an associative object. If the relationship is 1:1 or 1:M, you will probably formalize the relationship by placing the ID of A in B as a referential attribute or vice versa using the rules summarized on page 71 of my book. But you can still use an associative object anyway if you have a compelling need for the object. An interaction, on the other hand, is not an official model construct. It's just a commonly observed real world activity. It turns out that an interaction is readily modeled as an associative object. But this is just one use for the associative object model construct. In fact, page 17 points out how a role can also be modeled using an associative object. How can X-Start and Y-Start be a unique identifier? (page 43) In object Line Segment, how can X-Start and Y-Start be a unique identifier? Can't multiple line segments begin at the same point of origin, and if they do, how will X-Start and Y-Start distinguish between the two instances? Multiple Line Segments cannot originate from the same Point. Relationship R1 specifies that a Point is connected to at most one other point 1-(1c). Here are some connected points... (1,3)----(9,-2)-----(4,10)----(1,3) ...which form a triangle. There are three instances of Point, and their connections yield three instances of Line Segment: (1,3) is connected to (9,-2) (9,-2) is connected to (4,10) (4,10) is connected to (1,3) The identifier values are in the left column. The point (1,3) cannot form a new connection to another Point without first disconnecting from (9,-2), according to R1. You've probably noticed that R1 - "is connected to" does not imply direction, as would be the case if we were modeling vectors - "points to". Section 4.1 of the OOA96 report, v1.0 refers to a non-directional relationship like R1 as a symmetric relationship. Since R1 is symmetric, you could argue that each point (in a polygon) is, in fact, connected to TWO points. While that may be true, the single arrow head on the associative relationship constrains us to create only ONE Line Segment between any two Points. The rule for assigning identifiers in an associative object in a 1-(1c), relationship forces us to declare that X Start, Y Start is an identifier of Line Segment. Since we can't have two instances with the same values in it's identifier, it is impossible to create more than one Line Segment between any two connected Points. (By the way, the same rule for assigning identifiers dictates that X End, Y End is also an identifier of the Line Segment object. I arbitrarily chose X Start,Y Start to be the primary identifier. Corresponding objects vs. instances of an object. What is the difference between having a specification object and a corresponding actual object vs. having an object and instances of that object? This is one of those questions that is best answered using specific examples. In the context of an Auto Manufacturer's material tracking system, I can rephrase the original question as follows: What's the difference between having a Car Model (design) and a corresponding Car vs. having a Car and instances of Car? Let's start with the case where we lack a specification object. We have the following physical object, Car (VIN#, Model, Color, Engine Size, Current Location, Inspection Code) which corresponds to a fully assembled automobile parked somewhere in or around the factory. Now let's say that we want to support the following requirements: 1) Find out which assembly workers operated on a given automobile 2) Store information about what options come with different car models 3) Track the reliability of any given model The first requirement can be accommodated without a specification object. We would need to relate the objects Worker and Car in a model which would probably include other physical objects like Assembly Station, Assembly Line, Work Group, and so forth. What about requirement #2? Let's say that all Jeep Wrangler's come with a choice of 4 or 6 cylinder engines while all Jeep Cherokee's come with 6 or 8 cylinder engines. (Which may or may not be true in the real world - I'm making this up as I go along...) I can't model this real world fact with physical objects alone. It may turn out that all instances of Car with Model=JeepWrangler just happen to have a NumberofCylinders=4 or 6, but the model isn't enforcing any rules. To enforce the rule, we need specification objects like the following: Model (NAME, Base Price) and Engine Type (Name, Size). And we would change our Car object like so: Car(VIN#,Model (R1), Color, Current Location, Inspection Code). The relationship (R2) between Model and Engine Type is (M:Mc) since a Model must offer at lease one type of Engine Type (two in both of our examples) and an Engine Type could be included in any number of Models - including zero if a Model is discontinued before the Engine Type or if a new Engine Type is developed in advance of any compatible Models. So we need an associative object to formalize R2 as follows: Engine Option (MODEL NAME (R2), ENGINE TYPE NAME (R2)) The relationships look like this: Engine Type <<c--R2-->> Model <--R1-c>> Car -Engine Option (MODEL NAME, ENGINE TYPE NAME) To suit our example, we would find two instances of Engine Option for the Jeep Wrangler Model (Wrangler-V4 and Wrangler-V6) and two instances for the Jeep Cherokee Model (Cherokee-V6 and Cherokee-V8). Finally, let's take a look at Requirement #3. How do we track the reliability? Like the number of recalls issued, for example. It doesn't make any sense to track that for each individual Car because a recall applies to all Cars of a given Model. So we need to add a Number of Recalls attribute to the Model object. Another approach - reduce the scope With all this said, consider the case where an auto manufacturer makes exactly ONE model of car. Let's say that the Uranus company introduces the Uranus-1 car. Now we CAN accommodate requirements 2 and 3 without using a specification object. Number 2 is rendered mostly moot since we only have one model. But let's say that we offer two engine options. We just define the domain of the Engine Type attribute (of the Car object) to be either a V4 or a V6. There is no need to abstract the Engine Type or Model objects. As for requirement 3, again since we only have one model of car, we could introduce another physical object - Auto Manufacturer (containing only one instance - Uranus) and then we would add the attribute Number of Recalls. This works only until we decide to track recalls for each model year. At which point we could add a Model Year object and put the Number of Recalls attribute there. Of course, what auto manufacturer is going to introduce only one car model? One of the tricks to building software that extends readily is to identify those specification objects early on.