Alan Cameron Wills (email@example.com)
Wed, 26 Jul 2000 18:31:08 +0100
Sorry I missed this exchange when it was originally going on. Skip this if you've had enough of Links and Associations!
LINK AS PATH> Robert France: "For communication to take place between
"When conceptual modeling we will interpret
a link between two objects as just meaning that they know about each other
in some way."
> objects the sending object must know the identity of the receiving object.
> If you interpret a link as one object "having knowledge" (knows the
> identity) of the other object (where the direction of the link indicates
> which object knows about the other) then a link must exist between objects
> for communication to take place
> Daniel Jackson doesn't agree: "In a conceptual model, a link doesn't
> mean the two objects "know about each other". It simply means that there is
> a property that holds for the pair. "
I agree with Daniel, because I find that interpretation more practically useful. It is also in line with the OO principle of encapsulation. Here's why.
One of the most useful applications of UML is in describing not implementations, but interfaces. Interfaces between objects, interfaces between chunky components, and interfaces between systems in a large enterprise. Interfaces are important for pluggability (or polymorphism if you prefer).
For example, if you're the chief architect of a large company with many interoperating systems, you need to make sure they all work according to the same conceptual model and the same business rules. There will be confusion if the Dispatch Department systems think that a customer can have any number of outstanding orders, while the Accounts Department thinks he can only have one. So you make a model of the business concepts, and check that the different systems in the company all conform to it.
Now some of these interconnected programs might be legacy systems, and some of them might be written after our conceptual model. They might well all have different internal implementations. The Accounts Department's support system might be an RPG program atop a relational database; the Dispatch Department might be a nice new OODB system written in Java; another might be all tab-separated fields and Unix shell scripts.
But they can all conform to the model, in the important practical sense that:
* We could build an API to each application, providing for manipulation of whatever is its internal representation of customers etc; the APIs will be used for intercommunication between the applications via some convenient messaging framework.
* We can run tests on each application, through its API, to see (for example) whether it allows multiple orders per customer; and to check that it represents the other concepts in (some prescribed subset of) the model; and that it keeps to other rules of the model, that we might have expressed in OCL.
Another useful thing in this model is to define the effects of operations. We want to say that, for example, dispatching a customer's order marks the order as completed, and adds the price to the customer's account. But we don't want to define an implementation: there is no point in saying whether the customer object sends a message to the order object, because (a) all of the applications are implemented differently and (b) some of them don't have objects inside anyway.
Nevertheless, the links are useful. Why?
Firstly, because they represent the state of conforming applications. In practical terms, links represent queries: there is a way of finding out (directly or otherwise), through a conforming application's API, what order(s) are --ahem -- associated with a particular customer.
Secondly, because they can be used to characterise the constraints and the effects of the operations. Using instance diagams, you can clearly illustrate configurations of objects that do or don't conform to the rules; using pairs of instance diagrams, you can illustrate the effects of an operation, showing the states before and after, without saying anything about messages between the objects, or what responsibilities they take. (See the pic below.)
This interpretation isn't just about enterprise integration. It's also necessary wherever you need to specify the behaviour of a system or component or object from the outside, whilst allowing many implementations or subtypes --- good old encapsulation.
Illustrating a postcondition with a (superposed) pair of instance diagrams.
Alan Cameron Wills
Trireme International Ltd
Catalysis: Objects, Components and Frameworks with UML