UML 2.0 Interfaces and their operations/methods

[Thomas Taeger]

Hi,
I am looking for a clean, non-redundant way
- to use provided and required UML 2.0 lollipops and
- all the same to declare the methods in one interface
- instead of within N classes!

In UML 1.x I used to
- avoid the lollipop notation for interfaces
- provide all methods in interfaces (i.e. similar to class symbols but with interface behaviour and stereotype).

Actually I am using Together Designer 2005.

My last (but not best) chance could be
- to declare methods within good old class symbols with interface stereotype
- to create additional lollipop interfaces extending the non-lollipos
- to draw the etches for provided interface and required interface to the lollipop.

Does anybody have a better idea?
Thanks in advance,
Thomas.
[ August 21, 2005: Message edited by: Thomas Taeger ]

[Ilja Preuss]

I'm not sure about your doubt - are you asking how to do it in UML 2, or how to do it in Together?

[Thomas Taeger]

Originally posted by Ilja Preuss:
... are you asking how to do it in UML 2, or how to do it in Together?

Hmmm, ... I think: both.

How to do it in Together Designer 2005 not offering a lollipop-notated link to a classifier-notated interface is my actual problem.

But also generally in UML 2 it is impossible to define the interface methods (within a classifier-notated interface) and the two roles "provided" and "required" within one single diagram.

One can eighther show the methods or the lollipops (in other words: a o-lollipop and one ore more c-sockets), not both on the same diagram.

The c-socket-edge can not be drawn to a classifier-notated interface.

How would you model both within one single diagram?

Thomas.

[Scott Ambler]

But also generally in UML 2 it is impossible to define the interface methods (within a classifier-notated interface) and the two roles "provided" and "required" within one single diagram.

One can eighther show the methods or the lollipops (in other words: a o-lollipop and one ore more c-sockets), not both on the same diagram.

The c-socket-edge can not be drawn to a classifier-notated interface.

How would you model both within one single diagram?

Draw the classifier notated interface as you describe. Give it the name X.

Then draw as many lollipops and c-socket on other classifiers (e.g. classes, components, ... ) and give them the name X. This is completely valid. For example, in example I show 3 lollipops with the name IXML.

- Scott

[Thomas Taeger]

Hi Scott,

Originally posted by Scott Ambler:
... I show 3 lollipops with the name IXML.

that looks logical in your example, and with the multiple lollippos shown it can even work in tools that also offer code generation.

But the mix of an interface-classifier and one or more interface-lollipops of the same name is even more important, especially in component diagrams showing the inter-component dependencies _and_ their provided interfaces:

- For showing the inter-component dependencies the provided and required lollipops might be sufficient.
- For showing the behavioural contract offered by the component the classifier-notation of its interface(s) is necessary.

Both in Together Designer 2005 and Rational Software Modeler V.6 (and probabely all code generating UML 2.0 tools) each of the following combinations (all having the same interface name) cause problems:
- interface-classifier plus interface-classifier
- interface-classifier plus interface-lollipop
- interface-lollipop plus interface-lollipop

The error messages are:
- Together Designer 2005: refuses all these combinations ("duplicate name").
- Rational Software Modeler V.6 allowes these combinations but warns (translated from German): "This change to the model does not violate the structural integrity of the model, but it can cause unexpected errors in the application".

This is not just a tool problem but a UML 2.0 specification problem - and remember the importance of interfaces as the "glue of OO"!
It would be necessary that UML 2.x explicitely should allow having on one single diagram:
a) one interface-classifier plus one or more interface-lollipops of the same name:
- here it is important (and sufficient) to allow only one interface-classifier of the same name for avoiding undesigned re-declarations,
- each interface-lollipop per definitionem must be a link to the one interface-classifier within the same diagram.
or
b) multiple interface-lollipops of the same name:
- each interface-lollipop per definitionem must be a link to the original interface residing within the model (presuming the first drawing of a lollipop-style interface generates the interface in the model and thereafter can be used for both presentations).

Allowing more does not make sense.
Allowing less forces impreciseness or uggly workarounds probabely being refused by code generating tools at compilation time. UML 2.0 should not act contrary to Model Driven "Architecture" (i.e. code generation).

Besides the link feature a feature (check box) for toggeling between the lollipop and the classifier presentation is absolutely necessary in UML 2.0 tools.

Thomas.
[ August 20, 2005: Message edited by: Thomas Taeger ]

[Ilja Preuss]

The joy of using UML as a programming language... :roll:

Sorry, I can't help you - I only use UML for sketching designs. For that, it works great...

[Thomas Taeger]

Originally posted by Ilja Preuss:
The joy of using UML as a programming language...

Designing interfaces, methods and method signatures is not programming yet but is designing their future behaviour and placement within a package structure appropriate for the project's architecture.

Additionally, if an architects (and business analysts?) team has discussed about the main business and technical operations anyway, why not design them as [Java] methods, even with their raw signatures?
This enables
- robustness analysis (a parameter having an undefined interface/class/type will not compile) and
- controlling the architecture-compliance of the implementation usually programmed by another team, maybe offshore!, instead of just telling what to do and goodbye... You might even want to re-import the code of the [offshore] programmers team to the UML model to detect architecture violations ("abbreviations" bypassing the service locator, client-side JDBC etc.).

Programming is giving each interface one or more implementing class and filling the implementing methods with code according to the detail design that should have been done between architecture and coding, usually by the developers/programmers team but maybe also by the architects team already known by the "shy" business analysts.

At least in complex J2EE projects we are accustomed to fullfill our specialized roles.

Thomas.
[ August 21, 2005: Message edited by: Thomas Taeger ]

[Ilja Preuss]

Let's just say that I'm not very positive about separating designing and coding in time and/or space. Your mileage may vary.