Assembly link versus interface dependency

[mhdhallak]

Hi

I'm at this stage of my project where I've defined my functional and user interfaces and I'm trying to develop a component diagram in order to package these interfaces.

Reading in Component Diagram article in the EA documentation, I've come across two notations for specifying interface dependencies between components. Check out the following diagram:

I'm having some sort of consfusion as to when should we use the assembly link (which is supposedly new in UML 2) versus the good old interface-to-interface dependency link (seen in the above diagram as the dotted link).

Could someone clarify the difference for me please?

[Paolo F Cantoni]

Hi AL,

FWIW, as I understand UML 2, when the names of the interfaces at both ends are the same, you can use the ball-and-socket form (because they are (both sides of) the same interface).

Where the names are different, you must use the more conventional dependency.  However, it's really just a rendering issue.  There's still a dependency between the ball and the socket, even in the ball-and-socket form.  You just can't see it!

In my view, this is analogous to the concision created by allowing the special rendering of a binary relationship Association Class as the binary association with the "attached" Association Class.  It's just a special rendering of the more general n-ary relationship Association Class/Association Lozenge (see my pronouncements on that topic elsewhere).

Does that help?

Paolo

[mhdhallak]

Hi AL,

FWIW, as I understand UML 2, when the names of the interfaces at both ends are the same, you can use the ball-and-socket form (because they are (both sides of) the same interface).

Where the names are different, you must use the more conventional dependency.  However, it's really just a rendering issue.  There's still a dependency between the ball and the socket, even in the ball-and-socket form.  You just can't see it!

Paolo

Yeah I guess that makes kinda sense. Though refering back to the example above, how could AccountDetails interface have a dependency on a required interface (Payment)? This semantic isn't making sense to me  

[Paolo F Cantoni]

Yeah I guess that makes kinda sense. Though referring back to the example above, how could AccountDetails interface have a dependency on a required interface (Payment)? This semantic isn't making sense to me  

I didn't say the model was semantically correct...  

Only syntactically...

However, that having been said, you can see that the ball-and-socket rendering guarantees that the names are the same.  There is a strong implication that the interfaces are the same (no guarantees - I think).

Also, just because the names are different, doesn't actually mean the two interfaces can't talk to each other...

A validator process should be able to check the details as part of model validation.

Remember:
Manage Complexity,
       Reduce Ambiguity,
               Eliminate Inconsistency! ^TM

HTH,
Paolo

[sargasso]

IMO Fowler has the best take on these beasts.

Assembly links are just shorthand.  Use them at high level modelling to show you know there is a "wiring" bewteen component A and component B necessary to get the system to work.  We do not care what the physical provided/exposed/required interfaces are called at this level, just that they are needed.

e.g. "MyEAAddin" needs to interact with the "Enterprise Architect Object Model 2.0" COM component in order to work.  I am not interested in the internals of the tlb at this point, I'm more interested in what "MyEAAddin" does and how it works.

Later when we get down to the "code" design we will be looking at the exact ports and interfaces provided by the automation library, but not at the component design level which should be about "what new and existing stuff am I going to use to build this system.

e.g.  I could (if I were dumb enough) write my own version of the EA library using raw access to the repository and circumvent using COM altogether.  There may be crazy enough reasons for doing this.  I may want to, heaven forbid, get at something the EA component doesn't provide.  This might be a "partial" set, it might itself use the COM library to get at the "normal" stuff.  etc etc

...

OTOH if there are well-known exposed/provided/required interfaces at this level of design then there is no L.A.W. that says you can't use 'em.

This is just my alternative take on

FWIW, as I understand UML 2, when the names of the interfaces at both ends are the same, you can use the ball-and-socket form (because they are (both sides of) the same interface).

- I dont care about the name as much as the existence of the "wire" in my system and when the coders build it they better damnwell use that component's services rather than waste time building their own.

JM20CW
bruce

[Paolo F Cantoni]

- I don't care about the name as much as the existence of the "wire" in my system and when the coders build it they better damn-well use that component's services rather than waste time building their own.

I'm not disagreeing with you. Just reinforcing that if you DO name the assembly connector then it is the name of (both) the interface(s).

You don't need to name the assembly connector and thus you're just left with the "wire".

Paolo

[mhdhallak]

Yeah I guess that makes kinda sense. Though refering back to the example above, how could AccountDetails interface have a dependency on a required interface (Payment)? This semantic isn't making sense to me  

Oh I'm sorry, did I say semantic? I really meant the syntax.

My confusion, referring back to the above diagram, is how could a provided interface depend on a required interface (in our case, the AccoundDetails interface depends on the Payment interface).

I always thought it should be the other way around.

[mhdhallak]

And to make matters worse, the Payment interface isn't even provided.

[Paolo F Cantoni]

My confusion, referring back to the above diagram, is how could a provided interface depend on a required interface (in our case, the AccoundDetails interface depends on the Payment interface).

I always thought it should be the other way around.

Well, From first principles, I believe you are right.  However, the [size=13]UML 2.1 Superstructure (interim)[/size] Specification Figure 8.14 (Section 8.3.1 Component) DOES show a dependency "going the other way".  However, in turn, this seems contradicted by Figure 8.13!

As bruce has mentioned off-line to me - the UML Standard is sometimes self inconsistent.  I think this is the case here.

So, AL, I plead a slip of the mind....

FWIW, in my view, the dependency should be directed from the required to the provided interfaces.

Paolo

[sargasso]

and if you wan to get really confused read the bottom half of 7.3.12.  (from Notation thru Example).  It makes absolutely no sense to me.  In the first place, natural interpretation of the notation statement would indicate that the dependency is exactly the other way around (Car depends on CarFactory/VehicleType).  Secondly (in 2.1), the example is boofle, car class is NOT an instance of CarFactory at all - its an instance of something created by CarFactory. But, in the 2.0 final, the text reads "Car class is an instance of VehicleType class" which is also IMO garbage.

:-/
bruce

[mhdhallak]

So, AL, I plead a slip of the mind....

FWIW, in my view, the dependency should be directed from the required to the provided interfaces.

Paolo

Well that puts me in a peace of mind. You know what, I'm just gonna stick with the tried-and-true interface dependency links, especially that I have all my interfaces figured out and everything.

[Paolo F Cantoni]

and if you want to get really confused read the bottom half of 7.3.12.  (from Notation thru Example).  It makes absolutely no sense to me.  In the first place, natural interpretation of the notation statement would indicate that the dependency is exactly the other way around (Car depends on CarFactory/VehicleType).  Secondly (in 2.1), the example is boofle, car class is NOT an instance of CarFactory at all - its an instance of something created by CarFactory. But, in the 2.0 final, the text reads "Car class is an instance of VehicleType class" which is also IMO garbage.

bruce, in case you haven't got a copy of the [size=13]UML 2.1 Superstructure (interim)[/size] Specification, you''l be pleased to know the 2.1 specification has only partly corrected the text (at least):
Issue 8091 - Correct example text.
In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class.

Now, as to whether the dependency makes sense...

Assuming (for the present) that you need a CarFactory to create an instance of a Car, then I would have drawn the «instantiate» dependency with Car as the client and CarFactory as a supplier.  In other words, the opposite to that shown on the diagram  (which shows an «instantiate» dependency with client CarFactory and supplier Car)...  

You are correct with regard to the text also...  In my view it should read:
In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where an instance of the Car class is instantiated by an instance of the CarFactory class.

I repeat the aphorism I've coined and mentioned earlier...
Manage Complexity,
       Reduce Ambiguity,
               Eliminate Inconsistency! ^TM

Let confusion depart!

(By George, I think he's got it!)

Paolo

[dpresler]

I found this thread quite interesting, but I'm interested in a closely related point that wasn't really addressed.  I understand that the assembly is for high level diagrams, but one of the beauties of a model is the ability to "drill down" from the higher level to explore the details.  Shouldn't there be a way to link an assembly with (an) interface(s).  You can then see at the high level that two components interface, but you could also find out what specific interface(s) is (are) referred to by the assembly.

Trouble is, I haven't found a way to make that link.  Any suggestions?

[sargasso]

Dear dpressler.

Just in case you think your being ignored.  I think your idea is quite sound,  but it has some (quite) large considerations.

I am looking at a model transform of this type.  However I keep mentally stumbling on the fact that i see these diagrams as very abstract.  When one wants to start to "drill down" one (seems to) need to either have a preconceived notion of the final product or one needs to have this drilldown effect quite flexible.

Your input would be valuable.

bruce

[jonniesavell]

Sargasso,

I want to begin with a quote from Paolo:

if you DO name the assembly connector then it is the name of (both) the interface(s).

I would like to propose this as an axiom (because I agree with it).

I don't have an idea about drill down, but I would like to propose that the Link Name of the assembly to draw from (via a dropdown) the list of interfaces which are REQUIRED by one component and PROVIDED by the other.

Is this reasonable?

Sincerely,
Jon Savell