Assemblies and Interfaces - Can they be related?

[bknoth2]

EA Version 6.5

I know how to create an interface and call it, say "Interface1". I can also create an exposed interface and give it the type "Interface1". I even know how to create an assembly (the neat ball/socket connector that shows how two components connect through interfaces).

What I can't figure out is how to create an assembly and give it the type "Interface1" so that it relates to an interface I defined in my model. All I know how to do is give the assembly a link name of "Interface1", which is not the same thing and does not tie the assembly to the interface I have defined.

How do I bond assemblies with interface definitions so they are tied together in the model?

[thomaskilian]

You can't. Both shall be used in different contexts. I fiddled around with that recently and found a way to manage this. I'm a bit short of time now. Maybe I'll write a longer response later - if someone else isn't faster.

[bknoth2]

I'd appreciate your insights, including what you mean by "both shall be used in different contexts."

- Bruce

[sargasso]

YMMV (as may Paolo's)

On my planet we tend to use assemblies as an "architectural" element, rather than a "design" element.

By way of explanation.  At the architecture stage we are concerned about the component choices that can be made, either from pre-built components or from locally crafted ones.  At this point we are interested in component structure, not component design.  "The knee.dll is connected to the thigh.dll is connected to the hip.dll etc." Each of these connections is of a particular type, or (in OMG's "never use the same term for less than 5 distinct things" paradigm,) is an interface (aka a "wiring" (defn 1)).  We don't care, particularly, at this stage what the exact definition of the provided/required interfaces (defn2) and specifically aren't concerned with the exact services i.e. realised interfaces (defn 3) provided by the component in a more than general way.  

So to us venusians, the assembly linkage is a quick and dirty architectural level trick or placeholder that will be replaced by the required and provided interfaces at the next level of design, and when I say replaced I mean remove the assembly and replace it with a required/provided pair linked with a dependency.

So why have them?  To consider alternate architectures, to annotate alternate implementations (SQL Server, MySQL, Oracle etc) in n-tier architectures or just to confuse the heck out of the designers.

bruce
(with a small b ! (c) )

p.s. defn 4 - a contract that realising classes must observe
defn 5 - a specification of messages passed between two distinct execution elements.

[thomaskilian]

Thanks for saying what I meant, bruce (never noticed that (b) before). I might add some comments regarding Interface and Required/ProvidedInterface later - if time will permit then...

[bknoth2]

Ok, I'll buy the explanation from bruce (given that I am Bruce (large B), this thread got me confused.) It would be nice if assemblies could be related to defined interfaces to make the overall model more consistent and robust.

At this point, I'm describing, in broad terms, how a proposed hardware/software system will interact with an existing hw/sw system. I'm identifying interfaces and the format of the information that flows through them (or, for hardware, the type of connector required.) The data format is predefined, as one half of the system already exists.

Assemblies will work for me. I had to walk through the EA documentation to figure out what to do. At first, I tried dragging lollipops onto sockets in hopes that they would interlock (that seems intuitive), but they didn't. Then I found assemblies, but discovered they don't relate to actual interfaces defined on the components. I guess there's room for improvement in EA here, but I can live with it.

Thanks for your help,

Bruce

[thomaskilian]

I try to summarize what I'm doing. Once I'm about to remove the wiring, I create an Interface Classe for one wire. Now I draw a <<realize>> from the implementing component and a simple Dependency from the requiring component. Having done that I additionally insert Embedded Elements in both components: a ProvidedInterface in the first and RequiredInterface in the second component. Now I draw a Dependency from the Req. to the Prov.Iface. Additionally I draw <<trace>> Dependencies from the Req./Prov.Iface to the Interface Class. (I wish EA could do that automatically, but I likely have to write another add-in for that.)

Now why all this work? Simply for tracability by humans and all of my add-ins that support me in maintaing hundreds of interfaces. Having the Embedded Elements makes it easy to create diagrams showing the connections between components. Having the <<trace>>s will make it easy to find the real interface classes. Unfortunaltely you have to do this manually as EA only relates them via the name (you can nicely select from a dropdown, but tha only picks the name and does not leave a trace to the Interface Class itself ). It took some time to come to that solution and I also need some add-ins to permanently check the consistency. But for me it does pay the price.

[«Midnight»]

Well said Thomas.

What might be needed here is something like a few other dialogs in EA - I don't remember which just now - that allow you to choose (say) a specific classifier (not the shape, but the actual definition in the model) for whatever purpose. This would prevent namespace conflicts.

Who knows how much of a chore this would be? Perhaps if we can get together and phrase the requirement well, we can get Sparx to consider it for 7.1. [I suspect they are very close to a production 7.0 release, although I'd much rather wait through another beta.]

David

[Paolo F Cantoni]

Perhaps a new section on the Wiki?

Paolo

[Paolo F Cantoni]

YMMV (as may Paolo's)
[size=13][SNIP][/size]
So to us Venusians, the assembly linkage is a quick and dirty architectural level trick or placeholder that will be replaced by the required and provided interfaces at the next level of design, and when I say replaced I mean remove the assembly and replace it with a required/provided pair linked with a dependency.

Well, my reading of the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification suggests that the Assembly is actually a rendering placeholder that represents what both you and Thomas have said (at a minimum: one required, one provided interface and a dependency from the required to the provided interfaces).  EA implements the Assembly as a single "thing", but I'm not sure that's correct.  The reason is that if you look at the Superstructure there are a number of assembly combinations in the various diagrams which can't be represented by a single Assembly "thing", but could be rendered appropriately from the various individual, but related, "Assemblies".

Paolo

[thomaskilian]

Perhaps a new section on the Wiki?

Paolo

You probably know that joke: In the forest a woodworker is busy lumbering a tree. A passerby remarks that he could be faster if he would sharpen his axe. "Too busy to do that. I have to lumber trees", he replies.

[Paolo F Cantoni]

You probably know that joke: In the forest a woodworker is busy lumbering a tree. A passerby remarks that he could be faster if he would sharpen his axe. "Too busy to do that. I have to lumber trees", he replies.

Yes,

I quote it often...

Paolo