1 Object Models 6.170 Lecture 6 Fall 2005 Today we turn to the subject of object models: a diagrammatic notation that allows us to capture sets of snapshots. Until now, we’ve had to illustrate the heap configurations of a program by showing individual snapshots using object diagrams. Object models are far more powerful, because they allow us to describe an infinite set of snapshots all at once. As the term progresses, we’ll make more and more use of object models. not only for describing snapshots of programs, but also for describing more abstract properties of a problem domain. Object Diagrams In our last lecture, we used object diagrams to show particular configurations of objects, or ‘snap-shots’. Here is an object diagram showing a snapshot of an Account object and the objects reachable from its fields: (Vector) (Trans)(Account) transv elts (Trans) elts name (String) date date (Date) (Date) We’re no longer concerned now to explain how assignment and so on works; instead, we’re going to focus on structural constraints on object configurations. That’s why the Account object isn’t referenced by a variable in the diagram. It’s not that the object is not reachable, but just that we’re not concerned about how it’s reached in the code. Note that we’ve also omitted the primitive values (the balance field of Account and the amount field of Trans), since we’re primarily concerned about objects and their relationships. Often, we’ll want to elide collection objects such as the vector and only show the more interesting user-defined objects. The Vector is part of the representation of the Account object, and a client that calls the methods of Account sees only a Trans and not the Vector itself. So we might draw this diagram: 1(Trans)(Account) (Trans)name (String) date date (Date) (Date) trans trans in which the abstract field arrow labelled trans from the Account object to the Trans object hides the Vector. This isn’t actually new; we did the same thing with Vector itself, not showing that it was implemented with an array. Many states can be created using these classes, but not all of them will be desirable. Here are two bad states. In the first, two Account objects share a name; this will mean that names cannot be used as unique identifiers: (Account) (Account) name name (String) In the second, a transaction belongs to two accounts: (String) (String) (Trans) date (Date) name name (Account) (Account) trans trans Whether these are in fact problematic depends on the intent of the designer of these classes, and the properties of the problem domain. For example, a transaction may be shared between two accounts if it represents a transfer; two accounts may share the same name if there is some other way to identify the accounts; it may cause no problems for two transactions to be recorded as occurring simultaneously. So we cannot say for sure whether these configurations are right or wrong. What’s important is to understand that such constraints do arise in practice, and you need a way to record them. 22 The crucial point is that the code itself does not indicate how it is to be used, so in addition to succinctly summarizing some code features (such as which classes and fields there are), the object model adds constraints about potential clients of the code. In these diagrams, we’ve omitted the variable bindings and the primitive values, which are less relevant than the objects. It will often be convenient to draw object diagrams and object models that correspond to only part of the state, and sometimes we will even omit objects. Sometimes we will want to talk about the representations of objects, and for these we will not want to elide intermediate objects, such as the vector. The diagram below shows a problematic state that might arise. This may be created by clients of the code we have seen, but should not be. (Account) (Account) transv transv (Vector) If two Account objects share a vector, an execution of the post method on one will cause a transaction to to be added to the vector (see Lecture 3), but the balance of only one of the accounts to be updated. This will violate a representation invariant that the balance should always be the sum of the amounts of the transactions in the vector. Later, we will describe this problem as a representation exposure, in which part of the representation of an Account object – its vector – has leaked out, and become accessible from the outside, thus compromising the invariant. Object Model Basics We’ve drawn lots of object diagrams showing various configurations. When we want to talk about a program and the configurations that can arise, it would be tedious if we had to draw object diagrams to illustrate different cases. So instead we’ll draw object models. An object model is related to an object diagram the way a grammar is related to a sentence: while an object diagram denotes a single snapshot, an object model denotes a set of snapshots, usually infinite. Here’s an object model that corresponds to our class Account, whose code appears in Lecture 3: String transv elts Account Vector Trans Date datename Each box corresponds to a class: it represents the set of all objects that belong to that class (in some given state). The arrows are relations, sometimes called associations, and they represent the 3fields that connect classes. For example, the arrow labelled transv from Account to Vector shows that each object of the Account class has a field whose value is a Vector object. The object model specifies a set of object diagrams, by imposing the constraint that each object in the diagram belong to one of the object model boxes, and that any field arrow in the object diagram connect objects from the appropriate boxes. So our object model allows, for example, this state: (Vector) (Trans)(Account) transv elts but not this state: (Account) date (Date) Note that the object model (at least without multiplicity constraints, which we’ll talk about below) can’t require that any object or field be present; it says what cannot be present. The model above places no constraints on the relative numbers of objects, so it admits crazy states such as: (Vector) (Trans)(Account) transv elts date (Date) (Date) date which the code