Re: Interface usage best practices

From: Alan Gauld (alan.gauld_at_btinternet.com)
Date: 04/12/04 

Date: Mon, 12 Apr 2004 19:42:30 +0100

On Mon, 12 Apr 2004 16:07:15 GMT, "H. S. Lahman"
<h.lahman@verizon.net> wrote:
> > Interfaces were certainly not part of the first UML drafts (we
> They were there by v1.1 because they are in the UML Reference Manual by
> the Three Amigos.

Yes, Robert Martin seems to have confirmed that they were added
as a sop to Microsoft as part of the v1.x combining of efforts
for OMG.

> the initial versions. The early proposal was a melange of Rumbaugh's
> OMT and Booch's Graphical C++

I'd have thought Booch's method was more like graphical ADA since
that's where his background was. Certainly it had lots of ADA
features that weren't part of C++ at the time, including generic
packages and co-routines/tasks. Also the original OOD book was
based on 5 languages, it was only the second edition that
(mistakenly IMHO) dropped the multi-lingual approach and used C++
exclusively - a clear pandering to the then-predominant market
leader...

> (I forget what Booch actually called it).

Just "the Booch notation". And it is still in the public domain.
It is far superior to UML in many respects (again IMHO).

> Hence GIGO.

GIGO???

> driven by MDA. The original UML meta model was either inconsistent or
> had crucial stuff completely missing.

It still has! The dynamic-physical model for example...

> of CORBA. So I don't think CASE vendors in particular had that much
> overall influence over v1.3 through v1.5.

Given Rational's influence and their main product I don't agree
on that one! :-)

> story. Now that MDA shows real substance CASE vendors are coming out of
> the woodwork to get their own proprietary implementations anointed in
> the standard just like OCL.

Why do you see OCL as a proprietary standard? Where does it come
from? I thought it was a joint effort. (I also don't see many
folks using it!)

> > However when the OMG got interested in UML it all started to get
> > tightened up significantly. (Personally I think this is a
> > mistake, Software Engineering badly needs a standard notation
> > it doesn't need a rigorous modelling tool, again IMHO! :-)
>
> But a standard notation needs to have precise, complete, and unambiguous
> semantics.

Nope, The electronic engineering symbols are deliberately
flexible in semantic meaning. A rsistor symbol can be adorned to
provide tight specific meaning or it can be left blank in which
case it can suggest any kind of impedance device(including RCL)

Similarly the transistor symbol, canbe specific as to type,
fabrication technique etc or left unadorned to suggest any kind
of gate driven device. It is the ability to tighten up the design
as time prohgresses (or even allow different suppliers to provide
their own variations) that makes it so powerful. It does of
course rely on a tight underlying specification in the final
design, equivalent to Z/VDM or maybe OCL in UML etc

I can't speak for the other engineering disciplines since
I'm only formally trained in electronics.

But it depends a lot on what you want to use UML for, if its
machine generated code then the rigour must be there I agree.
The question is whether the rigour can be added by adornment
rather than being intrinsic to the symbols.

> [Since we do 100% code generation, there is no need for the developer to
> even look at the code, much less edit it.

In general I favour that approach, its how SDL tools work too in
most cases. But see the caveat below...

[ OT point: How do you handle peformance tuning? I've yet to find
a coe generator that can produce 100% of the code without tuning.
SDL code generators can generate functionally correct code but
they invariably need hand tuning at some point. ]

> > The only kludge that I find I need to use is the horrible textual
> > <<stereotype>> mess. Adding textual adormnemts to change the
> > semantics of a graphical notation is anathema to me. I'd prefer
> > more symbols, even if it takes more effort to learn - compare
> > with the huge number of symbols used by electronics, chemical and
> > civil engineers...
>
> That's a philosophical issue and we are on opposite ends. The basic
> problem is: What to do if one encounters a local situation that the
> standard's authors didn't anticipate.

I'm not against flexibility in the notation, I'm against textual
based flexibility. This places barriers in the
internationalisation of the model - if engineers on a project are
from diferent language groups - and slows down comprehension
bvecause you have to look at the contained text to see if, for
example, a class is a meta class or mixin or vanilla.

Graphical adorments avoid both problems. (And I'm aware that UML
allows stereotypes to be mapped to new graphical symbols but that
brings its own problem when diffeent units use the same synbol
for the same stereotype or different symbols for the same
stereotype!)

Of course no extension mechanism can be totally language
indepemdant because somewhere you need to explain the extensoion.
But if the symbols are explained once in a key its better than
translating every occurence on the model!
 
> Doesn't it bother you just a bit to advocate this view and at the same
> criticize UML for having too much stuff in it? B-))

I'm not criticizing it for habing too much stuff, rather the
opposite. I'm just saying that the models can be built using as
much or as little of the "stuff" you need to communicate your
intentions. If you aren't even modeling software then most of the
stuff can be left off, (or a new set of stuff invented to suit)

> [BTW, I would point out that the symbols in other engineering
> professions evolved long before the notion of extensible standards
> became popular.

Is that true? The EE standards only matured in the 1960s and
extensibility was built in by that time. And indeed the notations
are still being extended with new symbol sets being added evey 2
years.

> VHDL in electronic design) today, they tend to be extensible using
> similar mechanisms to stereotypes.]

My experience with VHDL is purely theoretical - I'd mived to
software before CAD/CAM became de-rigor, but I thought they
were in the form of graphical adornments not textual additions?

> If you list multiple Operations in the Class, how do you know which are
> duplicates? Why do they have different names if they do the same thing?

It could be to cater for pre-existing code that already has a
protocol established (mixing two protocols in the same object
with a single implementation - I've done that in Lisp before)

> To avoid that sort of ambiguity each Operation must represent a unique
> behavior responsibility.

I don't actually see that requirement anywhere in the UML spec.
Its just the normal way of using it.

> Remember the Class Diagram describes only static structure so it only
> identifies that the /intrinsic/ responsibility exists. It says nothing
> about what it actually does, what its implementation is,

WE may be talking at cross purposes here, thats kind of what I
said above. The operation name implies a responsibility, it says
nothing of the implementation. Or am I missing an element here?

> I don't have a copy handy but the limitation is indirect. The only
> thing one can put in the third subsection of the Class box are
> Operations. I'm pretty sure that is explicitly stated somewhere. So
> one can't identify state machine transitions in the Class;

But you can associate an activity chart with an operation. The AC
can have states within it and the signal arrival can trigger a
different behaviour depending on state. THe activity chart is
where the implementation of the operation is defined and by
embedding the state model and message arrival within it allows
for behavioural variation of an operation deoending on state.
(Including the non acceptance of a message!)

> The Activity Diagram is my favorite UML artifact (when I'm in a
> whimsical mood). It is the Duck Billed Platypus of UML.

It is, thats why I like it :-)

> served two needs. The first was to provide a Flow Chart-like or
> DFD-like notation for describing what went one within methods

FWIW I don't like the object flow stuff in ACs, just too messy,
but as control flow representations I think they work fine.

> The second was to provide support for state machines whose behavior
> spanned objects.

And the third was to document end to end process flow of a Use
Case. This last tends to be where I use them most...

> happy. [I heard a rumor that in v2.0 an Activity Diagram was no longer
> a "kind of" state machine, but I haven't verified that personally. If
> true, that is a step in the direction of digging out of the morass.]

My OMG UML2 book says "The activity Diagram is *similar* to a
state machine, but has a different purpose,...."

There are lots of changes in Activity Diagrams in UML2...and I'm
still trying to assimilate most of them.

> As far as SDL is concerned, I understand there is a move afoot to
> include it specifically in UML. I don't think it belongs in UML any
> more than OCL does. It is a language that is tailored to a specific
> OOA/D methodology

SDL is not an OO methodology at all! It is usually implememted in
vanilla C or Modula or ADA. Several attempts have been made to
map SDL onto OO concepts, mainly because the SDL community
accepts that SDL is strongest in detailed design and weak in
analysis and arch itecture. As a result there are moves to
combine SDL and UML, specifically to map UML onto the higher
levels of SDL (blocks and processes) and then use SDL to define
the detailed representations, and from there generate code.

Hmm, it occurs to me that this thread has meandered quite a long
way away from the OPs question about the use of interfaces in
Java! :-)

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Relevant Pages

  • Re: Booch and UML
    ... > the new standard OO modeling notation.". ... > to UML specifically made within the book. ... The first edition of the book used the Booch notation. ...
    (comp.object)
  • Re: SDL -> UML 2 Book ?
    ... >> Did you swap UML and SDL in your sentence? ... In protocol, the higher architecture level is the protocol ... > just using packages, much as you use boxes in SDL. ...
    (comp.object)
  • Re: SDL -> UML 2 Book ?
    ... >> I was a SDL user, and I am triyng to migrate to UML 2. ... "send and wait" protocol with Tau G2, ... Marc Boyer ...
    (comp.object)
  • Re: SDL -> UML 2 Book ?
    ... > Did you swap UML and SDL in your sentence? ... the perceived weakness in SDL is at the high level ... > there is no efficient way to navigate through the ... just using packages, much as you use boxes in SDL. ...
    (comp.object)
  • Re: SDL -> UML 2 Book ?
    ... >> what is closest of the SDL processes is the State Machine Diagram, ... > The UML state diagrams are like the top level state machnines ... > processing then Activity diagrams are more akin to SDL. ...
    (comp.object)