Re: [UML Forum] What type of UML relationships exist in this case?
30 views
Skip to first unread message
H. S. Lahman
Sep 1, 2012, 1:22:25 PM9/1/12
to umlf...@googlegroups.com
Responding to ARROCAL...
The association describes the nature of logical connectivity between members of classes, not specific communciations. So it doesn't matter what the message being passed is. The relationship only defines the structure used to navigate from sender to receiver (i.e., which objects are allowed to exchange messages). Therefore, you can use pretty much any flavor of association you want.
However, if you are doing OOA/D, passing references to problem space objects in messages is a Really Bad Idea because it is the worst form of coupling. It seriously impedes maintainability by trashing encapsulation and can trash performance in interoperability contexts. But the worst side effect is that it makes it very difficult to properly manage concurrency at the OOP level. Generally, in OOA/D you prefer not to pass any data in messages (except in situations where a "snapshot" of data in time is needed). (Object methods triggered by messages are supposed to navigate relationships to get to any data they need that is owned by other objects.) And when you do pass data, it should be pure by-value data.
Caveat 1: This applies to problem space objects, not computing space data holder objects like String and Array. (At the OOA/D level those computing space data holders are usually represented as Abstract Data Types (ADTs), so it appears that you are passing scalar data values anyway.)
Caveat 2: When messages are passed between subsystems, all the necessary state data needs to be passed in the message because the receiver has no access to the sender subsystem's internals. So one commonly employs message objects for the data packet to eliminate coupling between the subsystems. Such data packet objects exist only for the transmission of the message and they are encoded/decoded from/to object attributes within each subsystem, usually by the subsystem interface.
Caveat 3: There are some situations at the OOP level where one needs to pass object references to implement optimization for nonfunctional requirements. In those situations, the OOP developer needs to be very careful about issues like data and referential integrity in interoperability and concurrency situations. However, if the OOA/D was well-formed, it should be possible to deal with the issues properly with minimal hassles (which is why full, optimized code generation from UML models is possible).
What type of UML relationships exist between 2 classes when a method of a class A have like parameter an object off the class B?
The association describes the nature of logical connectivity between members of classes, not specific communciations. So it doesn't matter what the message being passed is. The relationship only defines the structure used to navigate from sender to receiver (i.e., which objects are allowed to exchange messages). Therefore, you can use pretty much any flavor of association you want.
However, if you are doing OOA/D, passing references to problem space objects in messages is a Really Bad Idea because it is the worst form of coupling. It seriously impedes maintainability by trashing encapsulation and can trash performance in interoperability contexts. But the worst side effect is that it makes it very difficult to properly manage concurrency at the OOP level. Generally, in OOA/D you prefer not to pass any data in messages (except in situations where a "snapshot" of data in time is needed). (Object methods triggered by messages are supposed to navigate relationships to get to any data they need that is owned by other objects.) And when you do pass data, it should be pure by-value data.
Caveat 1: This applies to problem space objects, not computing space data holder objects like String and Array. (At the OOA/D level those computing space data holders are usually represented as Abstract Data Types (ADTs), so it appears that you are passing scalar data values anyway.)
Caveat 2: When messages are passed between subsystems, all the necessary state data needs to be passed in the message because the receiver has no access to the sender subsystem's internals. So one commonly employs message objects for the data packet to eliminate coupling between the subsystems. Such data packet objects exist only for the transmission of the message and they are encoded/decoded from/to object attributes within each subsystem, usually by the subsystem interface.
Caveat 3: There are some situations at the OOP level where one needs to pass object references to implement optimization for nonfunctional requirements. In those situations, the OOP developer needs to be very careful about issues like data and referential integrity in interoperability and concurrency situations. However, if the OOA/D was well-formed, it should be possible to deal with the issues properly with minimal hassles (which is why full, optimized code generation from UML models is possible).
-- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared. H. S. Lahman H.la...@verizon.net software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Reply all
Reply to author
Forward
0 new messages