Re: Interface usage best practices

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 04/13/04 

Date: Tue, 13 Apr 2004 17:23:49 GMT

Responding to Gauld...

>>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...

Back in the mid-'80s I was attending OO conferences and my recollection
is that he was already closely allied with the C++ camp even though it
was just out. He was touting that every feature of his notation was
directly mapped to C++, down to "protected" and "friend" that none of
the other OOPLs directly supported (some could emulate them but they
weren't explicit syntactic features).

[I think I actually heard Booch use that expression himself in an
informal discussion. However, now that I am in the Metamucil Generation
the credibility of that sort of twenty-year recollection is pretty
minimal. And I certainly don't recall the context even if it was accurate.]

>>Hence GIGO.
>
>
> GIGO???

Garbage In; Garbage Out.

>
>
>>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...

OK, I'll bite. What do you mean by 'dynamic-physical model'?

>
>
>>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! :-)

Rational's contribution was mainly in the original UML proposal that was
obviously theirs. But by v1.3 they were just a member of the crowd.

>
>
>>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!)

OCL isn't proprietary but it is a specific implementation of a
constraint language. UML is supposed to be a semantic meta model so
specific implementations have no business being blessed. It's like
saying C++ is the only officially blessed OOPL.

>
>
>>>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

First, whatever the adornments are, they still have precise, complete,
and unambiguous semantics. Every EE looking at the graphic knows
exactly what it means.

Second, a lot of what you cite is simply evolution as new technologies
appeared and the standards were expanded for them. For example, ECL
became a Player long after TTL and modern fabrication techniques like
TAB and SMT didn't exist when the standards were originally created.

Third, a lot of what you cite is simply an example of the notion of
extensibility. One of the advantages of extensibility is that once
certain extensions become commonplace, they can be readily incorporated
in the standard so that they are no longer extensions. Thus
extensibility facilitates trial ballooning for standards.

Fourth, whether symbols are monolithic or composed of multiple elements
doesn't affect the fact the semantics is well defined. A standard that
allows optional adornments to some base just reflects flexibility; each
element (and consistency among them) is semantically defined by the
standard in a rigorous fashion.

>
> 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.

The code has to be generated one way or another. Whether it is
automatic or manual really doesn't matter, other than a programmer can
guess.

The effort that goes into a translation-quality OOA model is the same as
that an elaboration developer /should/ put in. The translation
developer just doesn't have the option of being sloppy because it will
be detected immediately rather later.

>
> [ 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. ]

Translation engine technology has been around since the mid-'80s.
However, it wasn't until the late '90s that optimization was good enough
in an 80/20 sense. [Note that it usually takes nearly a decade before a
new 3GL has reasonably good optimization. The optimization problem for
a translation engine is much more complex than managing an instruction
set.] So translation wasn't really viable until recently.

As a direct answer, it depends upon the engine design approach. The
basic compiler approach depends on efficient optimization being
built-in. Because the computing space is so complex the number of
factors that affect optimization can be quite large. Those have to be
specified to the engine much like compiler switches, usually via
pass-through tags attached to the OOA artifacts.

[For example, the optimal implementation of a simple 1:* relationship
can depend on any or all of the following list of factors: maximum
number of participants; average number of participants; whether the
number of participants is fixed; whether participants can be replaced;
whether participants on the *-side are accessed directly based on
identity or attribute values; etc. And that's just the factors I could
think of off the top of my head. As a result, a compiler-style code
generation engine like Rhapsody may have dozens of possible tags to
adorn a single 1:* relationship.]

The other major approach is template-based (Pathfinder's PathMATE is an
example). The code is implemented based upon code templates at the code
fragment level. There is a special template language employed in the
templates themselves. Typically the templates are exposed to the
customer so that they can be modified directly. (Template selection
from among alternatives can still be made via the tag approach used by
traditional compilers.)

Typically the template approach is used in environments where
performance is very critical. It effectively allows the customer to
deal with the 20% of situations where normal optimization won't cut it
and one would have to resort to hand-tuning or Assembly anyway. The
downside is that messing with templates requires more skill than
providing OOA tags that are <hopefully> related to problem space
characteristics.

[The compiler-style engines usually have back doors that allow the code
generation to be tweaked. However, doing so tends to be seriously
convoluted compared to the template-based approach.]

Realistically I would say that OTS optimization for translation engines
is still not where it could be. It is adequate for maybe 80% of R-T/E
problems and something pretty close to 100% of IT problems. For the
remaining 20% of R-T/E or 1-2% of IT problems, one is going to have to
tweak. It will take another decade of so to get optimization comparable
to today's C or FORTRAN compilers.

>
>
>>>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!)

Frankly, I don't see the difference. A UML stereotype simply alerts the
model reader that a non-standard semantics is applied to a existing
model element. That non-standard semantics must still be explained
somewhere and the reader has to understand it. So if I attach <<event>>
to an Operation in a Class, the reader is going to have to go look up my
definition of <<event>> to understand my semantics.

Exactly the same thing is true for a graphical adornment. The semantics
of the adornment must be defined somewhere and the model reader must
understand that semantics. So if I attach a butterfly graphic to an
Operation, the model reader is going to have to look up the definition
of the butterfly graphic to understand my semantics.

>
> 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!

Actually, in UML it /is/ language independent. The stereotype simply
provides an identifier for the modeler's semantics. That semantics is
necessarily found outside the model (e.g., in a methodology that
provides a specific MDA profile that includes the stereotype semantic
definition).

>
>
>>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)

But that is exactly what an MDA profile provides. It identifies a
relevant subset of UML that is appropriate for the problem in hand. The
UML elements in a translation OOA profile is well under half of the UML
elements.

I don't follow the last sentence. What would one be modeling with UML
if not software solutions? It's an OOA/D notation designed for modeling
software solutions. It's not a notation for requirements specification,
data modeling, or hardware modeling. [Note that in the MOF/MDA context,
UML is simply an instance of a meta meta-model for the particular
context of software development.]

>
>
>>[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.

They were pretty mature in the '50s when I took my EE courses. [Alas,
transistors were mostly academic curiosities and pentode vacuum tubes
represented the cutting edge. B-) Whole different set of symbols but
R/L/C still looked the same.]

There is a difference between a standard being expandable by adding new
symbols and a standard being extensible by adding custom symbols
locally. The EE standards were and are constantly expanded. The notion
of being able to add something not expressly sanctioned by the standard
is relatively new, though.

In addition, through the '70s the symbols were monolithic; two symbols
might look the same except for some squiggle that indicated a different
flavor, but from the standard's viewpoint they were independent semantic
entities that just happened to share a bunch of stuff. So the symbol
for a zener diode wasn't just an adornment to a diode symbol; they were
entirely different symbols. Thus the idea of defining semantics in
terms of {base + optional adornments} is also a relatively new idea.

I'll go further and speculate that both of these notions migrated to EE
and other engineering disciplines from software development in general
and OO in particular (due to the emphasis on polymorphism in various
flavors). Ideas like abstraction, substitutability, and extension
existed long before software but it was software that refined them and
provided cookbook mechanisms for applying them in arbitrary situations.

>
>
>>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?

As I indicated above, I don't see a difference. However, though there
are tools that will draw a nice schematic from it, VHDL itself is a pure
text language.

>
>
>>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.

As I indicated two paragraphs below, the demonstration is indirect,
which I explained below (the second half of the explanation elided).

>
>
>>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?

The only point here is that having a responsibility is inherently
static; a class has it or it doesn't. The ambiguity lies in the
ambiguity lies in the fact that one /only/ identifies them. IOW, as
soon as synonyms are introduced, the Class no longer unambiguously
identifies what behavior responsibilities it has. So one can't
determine, say, how many behavior properties a class has by counting the
names.

>
>
>>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!)

When one associates an AD with an operation, one is using the AD to
describe how the responsibility is implemented. The context here is
identifying a behavior responsibility and addressing a message to it.

>>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...

OK, that seems reasonable. (In the methodology I practice use case are
employed informally so we don't use the AD formalism.) But I would
regard this as a part of requirements analysis. That is, it is
something one does as a prelude to developing the software solution.
IOW, it helps organize the developer's thinking about mapping use cases
into an actual solution.

>>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.

I didn't say it /was/ a methodology. The OOA/D part was a leap of
context, though, to how it is used in the UML/MDA context. It is used
in some UML tools (e.g., Tau) as an abstract action language for
describing behaviors. Just as OCL is one of many possible constraint
languages, so SDL is one of many possible abstract action languages. So
as a concrete implementation of the UML meta semantics, it doesn't
belong in UML. [Some question whether it is even compliant with the UML
action semantics, but I don't know enough about it to argue that point.]

>
> 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! :-)

That's true of any thread on this forum that goes more than 3-4 responses.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages

  • Re: Interface usage best practices
    ... > The dynamics of the physical elements of the design. ... anything one does with software can be described with existing UML. ... >>and unambiguous semantics. ... On the standard side, the squiggle definitions and the organizational ...
    (comp.object)
  • Re: implementing attributes as objects
    ... I'm certainly you to UML. ... you need to extend the existing model element semantics ... In this case Account ID is an explicit account identifier while Customer ... it is also possible that you can abstract your problem space so ...
    (comp.object)
  • Re: Aggregation vs composition
    ... I think UML does have a meaning for "destroy". ... Whole *must* create the part for the relationship to be a composite, ... it is the responsibility of the GC system to do this. ... > only be in one folder at a time. ...
    (comp.object)
  • Re: Ada and UML
    ... As you said, UML ... has no formally specified semantics - but this is also true for most ... Ada is not formally specified in the mathematical sense, but at least it answers such questions well. ... Subset may enforce clearer meaning, while not extended the notation, so that it is not tied to a particular language. ...
    (comp.lang.ada)
  • Re: Ambiguities of the Harel/UML FSM model
    ... resolving the action sequence/context. ... Pretty much every standard in computer science leaves such leeway, ... proper execution model for UML represented a major hole in the UML spec ...
    (comp.object)