Re: question about component integration or assembly

Responding to Bordin...

However how could we connect X to Y, if don't
have the source code of X and Y?
The short answer is that you don't. The component is a module with a
particular semantic responsibility that is abstracted by its interface
for various clients to use.
Yes I thought the answer had to be not, however I have a confusion
between the concept (as described above) and the practical
implementation of the component integration.

Thanks again for your response.

Han

Maybe much of the confusion (at least for me) comes from the fact that
the term "component" sometimes indicate a *type* and sometimes
indicates an *object*, especially in the books you cited. But
practically, the situation may be quite different: for example in UML,
a component is basically a class: if you want to wire components A and
B you have to:
- instantiate an instance of A; instantiate an instance of B; wire
them (maybe invoking a setter on A passing the reference to B?)
- Have another component C which has properties (class members) typed
to A and B and wire those two properties (and of course instantiate C)

One has to be careful to distinguish between type systems and class systems. Type systems are a 3GL mechanism for conveniently mapping to the hardware computational models. But OOA/D is about class systems; the only place where types appear is in ADTs for knowledge attributes.

Type systems are about property access and interfaces. Thus an object is defined by how it is seen by others (i.e., what its interface is). Class systems are closer to pure sets and are about identity and set membership. Fortunately the mapping between the views is unambiguous (usually) because both are defined in terms of properties (shared by all members for classes and supported by all entities having the type).

Since UML is an OOA/D notation, it is concerned with the class view rather then the type view. Thus the object interface is a separate model element from the class that it encapsulates. (Thereby preserving the OO separation of message and method that the 3GL type systems marry.)

It is also important to note the unique role relationships have in OOA/D (that is largely obscured in the OOPLs). In OOA/D there are three distinct aspects of relationships: implementation, instantiation, and navigation.

There are exactly three ways to implement a relationship: (1) via a referential attribute, usually a pointer; (2) temporarily by passing a reference as a method argument; and (3) via a class-level Find that searches members based on identity. (3) is the RDB model and it is rarely seen in OO applications for performance reasons. (2) is almost always a bad idea in well-formed OO applications because it creates unnecessary dependencies in the caller implementation. So, by default (1) is the preferred way to "wire" instances together.

Instantiation of a relationship is an inherently dynamic activity and it usually depends very strongly on context. THIS dog is owned by THAT person. In the OO paradigm relationship instantiation is a primary tool for limiting access. If you have a Dog and need to access its owner, the relationship instantiation ensures that the only Person you can reach from the Dog is the actual owner. Thus instantiation provides a structure that is subsequently used to limit access during collaborations.

Navigation is also a dynamic activity to address messages. When one object needs to collaborate with another, it "walks" a relationship path -- that is constrained to find the "right" receiver due to instantiation -- and then sends a message to that object. Thus navigation provides the immediate mechanism for collaboration.

It is important to note that navigation is triggered by a need to collaborate. IOW, it is about When one needs to collaborate. Instantiation, OTOH, is about Who should collaborate. Generally the business rules and policies that determine When to collaborate will be different that the rules and policies that determine Who should collaborate. Separating those concerns is why it is common OOA/D practice to isolate and encapsulate relationship instantiation, usually with object instantiation. Hence we have a bunch of GoF construction patterns.

<aside>
This is why (2) is usually a bad idea. Typically the caller knows that something it did has changed the state of the solution, so it is logical for it to notify anyone who cares about that with a message. IOW, the message sender should know When to collaborate. But it may not (and usually doesn't) know exactly Who to collaborate with. That may be determined by some other object that instantiates the relationship. More to the point, it certainly should not who the message receiver needs to collaborate with. (The receiver collaborates with the passed object reference or there would be no point in passing it.) Who the receiver collaborates with is none of the message sender's business. So knowing what reference is the right one to pass requires the sender's implementation to know something quite carnal about the receiver and its response.
</aside>

So what has all this got to do with your comments? The main point is that Who gets "wired up" is driven by unique rules and policies that are probably encapsulated somewhere other than in the client of A or B. If A and B are "wired" together, then that is none of the client's business.

Note that UML doesn't have much to do with this, at least in a Class Diagram where classes are defined or a Component Diagram where components are defined. At that level all one knows is that a connection must be implemented. The dynamics of actually instantiating the relationship at the object/component level would, at best, be described in abstract action language for some method or state action. That method/action would encapsulate the rules and policies that limit Who can collaborate in the problem space.


Now, how you do the wiring between the required port of a component
*instance* to the provided ports of another component *instance* is
still unclear to me (look at a previous post which was sadly left
unanswered http://groups.google.com/group/comp.object/browse_thread/thread/62ec406d8dced3a4).

I am not the best person to respond since I never use ports. B-(

AFAICS, OMG introduced them to placate the systems engineering lobby. That <rather vocal> lobby happens to advocate a functional decomposition view of SE that dates from the Structured Programming days and (IME) isn't seen much outside of DoD anymore. Since higher level nodes in the functional decomposition tree can represent quite complex functionality that implies that the interfaces are more complex than simple function calls and ports are an artifact to capture that complexity. Thus one can associate state machine protocols with the ports rather than with the component.

Since OMG seems to be trying to integrate two mutually incompatible paradigms, it does not surprise me that the exposition might be a bit obtuse or inconsistent. B-) However, I think the issue you raise is more of interest to tool developers than application developers. One can map ports into things like Facade patterns during OOP, but that really should not matter much to the OOA/D developer using UML. [Of course I am biased because, as a translationist, I wash may hands of the application when the OOA model is done and rely on the transformation engine to do the right thing when I push the button. B-)]



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.

Quantcast