Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 30.12.10 00:35, Dmitry A. Kazakov wrote:

I'll put this up front:

> Ada declarations inform, guide and mean something. I see no difference.

UML elements inform, guide and mean something.
Something slightly different.

>> No. Man-made programming things are not arbitrary.  Ada source
>> text follows Ada language rules and Ada culture.  Similarly,
>> UML diagrams would not be drawn arbitrarily, either.
> 
> It is the superior UML culture, which makes Ada usage impossible? And where
> is the guidance?

The UML repertoire for expressing ideas makes you model
in terms of UML.  That's useful in many modeling cases.
It is not useful if modeling is misunderstood: it is not
the same as programming.


> I am interested in software design. Why UML is better for designing
> software than Ada and what does Ada lack to become as good as UML allegedly
> is.

The question is *when* is UML better for what kind of
design.

UML, for example, has simple elements for simply expressing
control as part of the system that would be external to the
program you will be writing, as mentioned many times.


>>> If we are talking about a *real* domain, like designing an application X
>>> that does Y, then convince me that UML does it better than Ada and what
>>> does prevent Ada from providing same level of support.
>>
>> External control in a given setup is easily and formally
>> communicated in a modeling language.
> 
> I don't know what external control is, but let me a shot:
> 
> "External control in a given setup is easily and formally
> communicated in Ada."
> 
> Is it wrong? How much of X doing Y is "external control"? Let's take matrix
> inversion program as an example.

Suppose the matrix inversion program can be split into
a number of jobs (huge matrices).  The operating system requires
that each job do not exceed a given quota.  Each job may
just fail because the OS decides it should fail for some
reason (including economic/commercial reasons).
 It may be re-allocating processors and therefore
some jobs would have to be terminated.  In some systems,
there is no way for your job to be told about its
imminent death.  In any case, in order to deal with this, you
need some means of communication: each job must

(1) register itself
(2) communicate success

via some non-failing "message box" external to almost
everything.  Other jobs must try to look into the message
box and see if there are pending jobs. If not, they see whether
all jobs have reported success.  These manager jobs may need
 to run some of the same jobs again. This, again, requires that
the jobs themselves be made such that they can be run once
more, ideally in arbitrary order.

The important part here is the external data store and
control mechanisms.  They are easily expressed if you
abstract away the specifics of the heterogeneous system.
A data store is very much part of modeling tools.
A data store abstractions can be programmed in Ada.
There is no direct support for a data store in Ada, the
language.  There is, with some tools.


>>>> The crucial part is that an Ada compiler guides you by
>>>> answering the question "Which case distinctions do I
>>>> have to change?" (provided you don't use C style "others"
>>>> for subtypes typically appearing in case statements).

>> (GCC's C compiler can be instructed to issue a warning:
>> sw.c:7: warning: enumeration value οΏ½FourοΏ½ not handled in switch
>> GCC's Ada compiler rejects the program.)
> 
> How is this related to UML?

It is related to how one tool (compiler for some language) provides
more guidance than another when performing necessary changes
of case distinctions in source code.


> In GPS I see a call Send_Message. I can even refactor Send_Message and
> rename it to Send_An_Excellent_Message. Can UML refactor arrows?

In Ada, then, you need to embed another language into Ada
in order to be able to say "this is a message".
(pick some convention for choosing identifiers)

Wheras "Message" is a built-in in some modeling tools.


> Surely not, because it is untyped. I don't send strings, I send messages.
> Message is an object.

The external software expects a \0-terminated string,
sent in message style.


>>>> This is because, when
>>>> modeling, humans have expressed one set of notions. This
>>>> set is slightly different from the set expressed in Ada source.
>>>
>>> Certainly yes, if you compare UML input with its output. But I don't buy
>>> this trick. You have to show that the guidance given while connecting
>>> blocks is better than the guidance given by Ada compiler when compiling Ada
>>> program. It is NOT.
>>
>> Use cases.
>> Permissible call orders of a type's operations.
>> Answering questions about program structure at large.
> 
> GPS has this sort of stuff (see "tools" in the menu),

GPS lets me draw actors and actions of use cases?

> but I don't count it
> for guidance or even valuable comparing to typing, reuse, information
> hiding, encapsulation and modularity, which Ada offers and UML does not.

UML and others make all of these readily available.
They are ready.  You don't need to construct anything.
Even second level information hiding (excluding
parts of the model from sight) in not unusual with
those tools.

>> UML is typed, its universe of things
>> is full of categorized modeling elements and associated
>> "operations" (things you can do with them in diagrams).
> 
> This equally apply to Assembler. It is a universe of things (registers,
> commands, labels) and associated operations. It is perfectly typed in the
> "sense" that MOV R1,R0 is OK, but R0 MOV,R1 is not OK.

The assembly language universe of things is
much smaller than Ada's and UML's, obviously, and does not
include anything like a package or an actor.

>>> IS-A at the language level is a relationship between two types. UML does
>>> not have this.
>>
>> UML does not relate its modeling elements?
> 
> Yes, what you operate is not what you are.

The interpretation of typed associations in UML is not
subject to other operations that the informed brain's
understanding the relations.

At the level of modeled things, things *are* related.
At the level of UML language, items *are* related as
described by (Meta-)UML, AFAIK (a class model is a ...).

>> And even so, I couldn't care less about (meta)programming
>> in UML.
> 
> That is another issue. My point merely was that UML as a language is not as
> advanced as Ada. Therefore I wonder why do you insist that UML can do more
> than Ada ever could. That looks illogical.

It becomes logical when you concentrate on structure:
static structure, dynamic structure.  I don't want to be
forced into messy detail, choice of implementation,
choice of language, just to see the big picture (typed
picture!).



>>   type T is new ...
>>
>> *expresses* T IS-A ... by employing the word "new" in
>> this context.
> 
> It does not expresses is-a, it constructs a new type.

Text does not construct anything.  It denotes, with
the help of an reader interpreting the text.

The text "type T is new T0" expresses a relationship
between T and T0 (T being derived from T0).  This mode
of expression corresponds to another where you would
say "class T IS-A class T0".


> Relation is a Boolean
> operation of two arguments. 

I thought that a relation is a thing between two things.
And "operation" in a programming context is not usually
an abstracted static function table?  A text does not
operate.  Neither does an arrow.

When a write "T is new T0", I am expressing a relationship.
When I place a specific arrow between a boxed "T" (denoting
a named model item of type class) and a boxed "T0" (denoting
another named model item of type class), I am expressing a
relationship.  The same, in the modeling sense. The second
mode of expression does not depend on the choice of a
programming language.

> There is nothing problematic to construct such
> operation in Assembler.

To construct is not the same as to express. To me, that is
an important difference.
Assembly language permits the construction of anything
but no expression of assembly language comes close
"type T is new T0".  "New" is simply not part of assembly
language.


> Talking about certain properties of types, you should first show me
> 
> 1. an equivalent of a type in UML. E.g. arrow might be a value of some type
> of arrows.

It is.  This is also irrelevant, because you use "UML elements"
not to construct the language UML, or to construct "UML
programs", but you use UML elements to express static
and dynamic structure of your model.

> 2. construct a new type, e.g. new type of arrows.

That's available with some UML tools, and some other tools
do not have anything but elements constructed in this way.
I don't find this universally helpful, though, because you
loose one important property of a language like UML: that
everyone understands it.

> 3. show how the language treats values of new type substitutable in
> operations of the old one, e.g. operation "connect two blocks."

One example would be adorned associations.  The fact of
association is not lost when the ornaments are dropped.
Therefore, one arrow can be used in place of the other.
Since it is up to the team to decide on a correspondence of
UML elements and Ada source text, they can construct rules
of correspondence that take ornaments into account.

> you mean that these entities cannot be modeled by values, types,
> operations, packages?

You'd need a larger set of Ada constructs, you'd need to choose,
and you won't have standard elements. You do all this in order
to arrive at the modeling equivalent of some simple model
element.
In many modeling cases, such specifics will be distracting.



>> A model element isn't external to the model.
> 
> So it has some interface internal to my program,

First, your "program" is a notion that does not have a counterpart
in  "model", unless there is a model element for "program".

> otherwise the program
> cannot become aware of its existence.

Second, the interface is not one that is an element of Ada's
immediate repertoire.  You'd have to choose, construct,
etc., in some project-specific way.  Which is what should
be done when deciding how the message sending/receiving
source text should correspond to the model element.

>>>> An external control can be an element of a UML diagram or
>>>> other modes of expression, but not in Ada (not directly).
>>>
>>> Why?
>>
>> Because "external" means beyond reach of the Ada language,
>> by definition.
> 
> Maybe there is something wrong with that definition?

The definition of Ada includes the word "external".
I think there are hints near it as to why some things
external are not covered by Ada.

> You have to describe these thing in order to be
> able to talk to and about them. In Ada it is called interface.

You'd be creating interfaces in Ada that match the
repertoire of UML.  Well... Wouldn't you be creating
a UML tool, then?

> Last time I looked at UML it was all about
> relationships between concrete instances.

(Some of UML is about relationships between concrete instances.
But not all.)

> They cannot
> capture the system architecture and behavior at the level of details
> necessary for designing and maintaining the system.

Precisely! At least if you exclude the tools that turn technical
drawings full of all necessary detail into an executable program.

But you don't necessarily loose detail when modeling (as opposed
to programming).
You can, however, get lost in detail when not modeling.