TK,
Well, I've been using extensively for weeks and let me tell you I am no less confused han when kex started this thread
I thonk though we (the forum we) need to be very clear in explaining which d ;Dn interfaces, lollipops and models we are talking about.
I reckon....
1. Assembly's only belong in component level models and then only at the component to component level of discussion - as help etc says "to discuss the wiring of components together". They dont seem to have a detail level semantic of use. Further they can be conveniently used to model any type of "wiring" be it transport level or logical data flow. However, their directionality is poor!
2. Their seems to me to be too many interface elements, all with very similar (read "sometimes, exactly the same") representation.
Let's talk at the class level.
We have:
a class stereotyped as an interface
an interface element based on a class element
two embedded elements representing interfaces of the type "provided" and "required"
and
two "exposed" interface elements that are not the same as the above provided/required interfaces but look exactly the same.
Try this exercise and see if it helps.
1. Create a class model with 7 classes - c1 to c7.
2. Add an o-O interface - i1 - an make it use circle notation
3. Add another class - i2 - just leave it for the minute
4. Create a dependency from c1 to i1, then use Insert Embedded Element/Show Dependent Interfaces on c1.
Now change the line color for c1 - note the line color of the lollipop socket changes. Also, you can double click on the lollipop socket and get the class details form. Note also that double clicking on i1 gets you a detail form that does not include a "Details" tab. However, you can add BOTH operations and attributes to i1 using the Current Element toolbar. Finally, you can generate code (C#) for i1 but any attributes (correctly) are ignored.
5. Lets attack c3, open it up and sets its stereotype to "interface". Add an attribute and a couple of operations, say "int voltage" and "bool connect" and "bool disconnect". You can generate code for this that looks exactly like an implementable class - coz it is.
Go back to i1 and using the toolbar add the same attribute and operations. Now change the visual representaiton of i1 from circle to normal. Now both the class and the interface have the same representation! Change i1 back to circle notation before we get too confused. Now change the name of c3 to i1. Now quickly change it back to c3 .... :-/
Create a dependency fom c2 to c3 and switch on Show Dependent Interfaces for c2 - OK it acts the same as the c1 to i1 dependency, change colors etc to check.
Now create a realisation link from c2 to i1, dont override anything - and turn on Show Realised Interfaces for c2, now we have a realised lollipop for c2 that acts (as in diagram wise) the same as the dependent interface. If you generate code for this it will include the skels for i1's operations as it should. Now delete the realisation link - note the interface stereotype on c2 remains! - then re-add it, this time overriding the operations. Add an attribute "float voltage". Now we have an interface sterotyped class that generates implementation class code with a decendancy on i1 which implements i1 and "overrides" both the attribute and the operations.
I guess I'd better get to this meeting, so I'll explain c3 to c7 later
Bruce
