Component/ports/interface + Comp. internals Model

[Tom_Evans]

My goal is to build a model of a portion of a client's Enterprise systems intergrations, showing systems and their interfaces at two levels of detail.

[1] Big Picture / Low detail:  Diagram(s) of Black box components + ports + interfaces...interconnected to other components via interfaces & ports.

This view shows many different interfaces in use between system level components, i.e main frames, stand alone apps, etc.  A diagram might show 15 systems and 25 interfaces.

[2] Zoom in, High detail:  White box view of a single component (C1), with the same ports and interfaces as displayed in the [1] diagram.  Now I need the component as a full drawing with its internal elements (Components, Parts, Classes...what ever works best for the overall approach).  I also want to spec the details of the interface (style,... frequency of use, etc)

The approach below is my best guess...but, I cannot find a way for the interfaces/ports in diagram [1] to be the SAME model elements as the interfaces/ports in diagram [2].

I do not know if I have a thinking limitation, a tool limitation, or a UML limitation.

So,

I can: Create Component diagram, add two components (C1, C2), add a port to each component.  select each port, add...embedded Required Interface, then and add..."embedded Provided Interface" to each respective Component's port.
Select "Assembly" and connect the two interfaces.
So far so good.

On the other hand,

I can
create a composite diagram, add some Parts, add some ports, and interfaces, and hook up the insides....

If, by going to the model browser, I attempt to take the port from component C1 (above) and drop it onto this diagram so I can build out what is internal to C1 and connect it to the port from the first diagram I get this message:
 when dropping embedded elements (parts, ports, object nodes, etc)
 onto a diagram you must drop them onto their correct owner.

So, how can I have the Componet as the "frame" of a diagram so I can detail the insides of the component, where the port in the "black box diagram" of many top level componets is the same port as in a diagram of the insides of one of the components?

Thanks!
Tom

[thomaskilian]

Just size the frame to be large enough and drop anything you need inside? Note that this way the elements inside are glued to the frame, thus moving with it.

[Paolo F Cantoni]

Hi Tom,

To some extent, EA's unique user interface strikes again...  

In order to achieve (what I believe) you are trying to do you have to do things in two steps...

It turns out that in the case of embedded components, EA (correctly) restricts the location of the embedded element to the owner.  To illustrate this, drag a component onto a new diagram.  You'll note ONLY the Component outline is visible - NOT any embedded elements.  Now, drag one of the embedded ports onto the diagram and let it go as far away from the owning component as you can.  It will be sited within the owning element.

The message you are receiving is because you are trying to drag and interface onto a diagram that doesn't yet have the corresponding port on it.   You have to manually build the component in each diagram - in the correct order... Component, port, interface.

However, if you [Ctrl-drag] the component onto the diagram, you can get EA to automatically expose the embedded elements,  This will cut down on the occurrence of the error message you received.

HTH,
Paolo

[Tom_Evans]

Hi all,
Thanks for the replies..I should have included an awareness of placing the Componet on a diagram, stretching the Component to a larger size and drop elements onto the Component.

My intent is to have the component "insides" be modeled as a Diagram, similar to the way the behavior of a Class can be modeled as a Harel State Chart diagram.

One approach may be to select the Component in the overview diagram and pick Advanced Settings ...> Composite Element

This will create a new Composite Diagram associated with the Component - GOOD! Double click on the Component leads to this diagram (Good)
So now I am prepared to build the model of the composition of this Component, and I want to connect the internals, the elements of the composition to the ports/interfaces already realized on the Component itself (in the parent drawing).

How?  I am Inside the Componet, so, I can't place the Componet symbol in this drawing (self reference), so I need an equivlent symbol to attach the ports and interfaces and then make connections from the inside side of the ports to the elements of the Composition.

Clear as mud?  ... Thanks - Tom

[thomaskilian]

Hi Tom,
I momentarily can't verify that, but I think I know what you mean. What about (despite the recursion) putting the frame inside the containing diagram. I guess there's probably no way around that since EA will not offer you any dock in a mere diagram.

[Tom_Evans]

Hi again,
OK, hangs head, shakes it foolishly.  I -though- I went through all of these options, well a month ago or so.  Hmmmm, I am using a newer version (6.1.798 ), maybe thats my story  : - ).

Yes, in fact, you can drop the Component described by the Composition Diagram onto the Composition Diagram.  It then could be the "frame" for attaching the port and interface elements....So I have not tested an XMI export/import, but it seems reasonable - Thoughts?


Next issue...Recommendations for documenting systems level interfaces.
The Interface Lollipops do not have property sheets.  On the other hand, the Interface element found on the Composite menu, a Class with an <<interface sterotype>> can be fully documented, and it can be associated with the Lollipop.

What is valid UML / best practice for documenting interfaces presented as Lollipops?

Thanks again!

[Paolo F Cantoni]

The Interface Lollipops do not have property sheets.  On the other hand, the Interface element found on the Composite menu, a Class with an <<interface stereotype>> can be fully documented, and it can be associated with the Lollipop.

1st recommendation:  EA inconsistently has two elements named Interface.  A true UML 2 Interface and an older UML 1.x Class with stereotype «interface».  You need to decide which form you are going to use.  Mixing them is NOT recommended!

2nd recommendation:  Interface lollipops DO have property sheets - AFTER you assign a real UML 2 Interface as the base Interface to the Exposed Interface instance (see my posting: Components and embedded Elements).  You do this by using the drop-down OR the builder button on the [Alt+Enter] Properties page.  As with much of EA's unique user interface, it's not clear why there are two mechanisms and what the differences are between them (and there are differences).  However, once you've assigned the base Interface (you can't assign an «interface» Class, so take the hint on the first recommendation above), you will then have a new Context Menu entry: Advanced Settings|Base Interface Properties - which will expose the base Interface property sheet.

HTH,
Paolo

Manage Complexity,
       Reduce Ambiguity,
               Eliminate Inconsistency! ^TM

[sargasso]

...not much time....

Dont forget, EXposed Interfaces are not the same as Provided interfaces - the lollipops work different.  6 months later I still haven't finished my discourse on this.

...  meeting time.....


bruice

[Paolo F Cantoni]

Don't forget, Exposed Interfaces are not the same as Provided interfaces - the lollipops work different.  6 months later I still haven't finished my discourse on this.

Hi bruce,

Couldn't find any reference to Exposed Interface in either the [size=13]UML 2.1 Superstructure (interim)[/size] Specification or the [size=13]UML 2.0 Superstructure (formal)[/size] Specification.

From EA Help file:
The expose interface toolbox element is a graphical way to depict the required and supplied interfaces of a component, class, or part.

Now assuming supplied means the same as provided...  I can't see any difference.

Can you enlighten (at least in summary).

Paolo

[sargasso]

a port on a component exposes an interface provided by one of its internal thingees.  paragraph 2 in 8.1 in final.

EA provides both types, one is an adornment only the other is a manipulatable element in its own right.

... back to meeting stage 2....


bruce

[sl@sh]

*dusting off  some ancient postings*

Hi everyone,

Excuse me for digging out this old topic, but during my attempt to design several exposed interfaces of a complex component I stumbled over a particular problem regarding exposed interfaces. Searching over the forums over the past 9999 days showed exactly one result: this thread. Since it doesn't quite address my real problem I thought I'd ask:

I want to picture the connections from specific instances of my component to different instances of other components. Since the type of interfaces used are different, depending on the instance of either component, I added seperate instances of the original components on the diagram. Unfortunately those instances do not appear to inherit the (exposed) interfaces of the original components. Shouldn't they?

I tried to drag&drop the exposed interfaces from the original component to the instance, but as a result EA constructed a new object of type object!?   Clearly, this looks like an error to me, or if not, why is this so?  

My second thought was to create a new exposed interface object for this instance. This works, and after reading the above posting about linking to a real interface at least I got it working (in a way).

All of this looks awkward. I shouldn't need to define three (or more) different objects that are all essentially the same. Moreover, a component instance should automatically inherit its original's parts.

Is there any way to tell EA an instance has the same parts as it's original? Or at least a way to drag and dop the parts that are required to another diagram without wrongly creating a new object? Any help would be appreciated, thanks.

[edit]eliminated remarks/questions regarding solved issues[/edit]

[meierch]

There is a checkbox in the dialog for embedded elements (popup menu for the instance) which makes 'inherited' interfaces visible ...