Re: Ada and UML

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 31 Aug 2010 18:34:11 +0200, Matteo Bordin  
<matteo.bordin@gmail.com> a écrit:
> Hello Yannick,
Hi Matteo :)


> UML semantics can be found in the UML metamodel superstructure at
> http://www.omg.org/spec/UML/2.3/Superstructure/PDF/. As you said, UML
> has no formally specified semantics - but this is also true for most
> languages we use everyday (including Ada): I think it is really unfair
> to keep bashing UML for not having a "formal semantics" while
> basically all languages we use suffers of the same problem.
I did not want to be unfair and I had this “be fair” requirement in mind.  
While I should not have used the “formal” qualifier, you are right (formal  
may means multiple things, just like semantic, safe, etc).

I have read some UML tutorial in the paste, and found it was always  
talking about syntax, and just a few about meaning. But as I am not a  
specialist in this domain, I wanted to be sure and seek for UML semantic  
docs. Among others, I found this one:
http://www.imamu.edu.sa/DContent/IT_Topics/UML%20Semantics%20FAQ.pdf
which confirm there is a lack of semantic. As an example: they state UML  
does not even tell anything about weither or not a message queued to a  
task will be always processed or not. Ada is not formally specified in the  
mathematical sense, but at least it answers such questions well.

TBH, see also a later comment below about UML and semantic.

> The only
> exceptions I am aware of are SPARK and some languages of the
> synchronous family (Lustre, Esterel, ...).
Thanks for other references ;) Will be worth reading I feel.

> Mapping Ada on UML means treating UML as graphical coding: in my
> personal opinion this defeats the main purpose of UML.
Fully agree. I said “the purpose of UML is clearly underspecification”.

> Ada profiles for UML surely exists, but
> they make UML models implicitly not implementable on any other
> programming language.
Good point.

> I personally find language-specific UML profiles
> a total non-sense. Having said that, it is unfortunate that an
> incestuous relationship between UML and Java/C++ exists.
I have never talk about UML profile ;) I talked about meaning of  
notational elements and attempted to express them in terms of Ada  
construct meaning. There is no worry about stating UML Name Space better  
match Ada's package than UML Package does. This is not an UML profile.  
Except may be for restriction like “only use the ~ visibility modifier”.  
But this could be as well a required UML subset to match some design  
criteria, just like there are Ada subsets (Ranvenscar, SPARK, and may be  
others).

Also note that an Ada profile and UML profile does not stands for the same  
thing: UML profile means possibly adding notational components to UML via  
prototypes, while Ada profile means strict subset of Ada, don't even think  
about adding anything. These are two opposite!

I was talking about UML subset. This should match both expectations, yours  
and mine. Subset may enforce clearer meaning (as an example, avoiding to  
have multiple notation to express the same thing), while not extended the  
notation, so that it is not tied to a particular language (I love your  
comment about it). I agree with the criteria (UML should not be tied to  
any design language).

> Anyway, one reasonable approach to represent Ada packages in
> "standard" UML is to use a non extendible (isLeaf=true) UML singleton
> class.
An UML class to represent a package ? Can you tell more ? What is the  
difference with the name-space choice ?

> Package-level variables, constants and non-primitive operations
> can be mapped as static features (isStatic=True) of the singleton
> class.
I have played a bit with a textual variant of UML which generates graphs  
via GraphViz ; this is called PlantUML. And actually it does not provide  
the attributes you mentioned.
http://plantuml.sourceforge.net/

> Types declared within the Ada package can be represented as
> nested non-singleton classes contained in the singleton class above (a
> UML nested classifier is equivalent to Java/C++ nested classes). Ada
> child packages can be mapped as nested, non-extensible singletons. As
> you can see, this representation does not sound very natural from a
> UML point-of-view, but covers the Ada semantics.
So all can be done with class and no need anymore for UML package ? Class  
can be static, leaf and so on. OK. I did not read UML Superstructure,  
because it is a very long document, and that is not handy to read such  
long document on a computer screen. I wish I will do later (I just get a  
quick overview so far).

> The extend relationships relates to UML types only: in UML, a Package
> is not a type, so it cannot be extended in the UML sense.
So the schemas I "draw" was wrong. I used the Extends relation on package.

> You also
> cannot directly use UML NameSpace because it is an abstract semantic
> element (an abstract metaclass).
>
> Cheers,
>
> Matteo
OK.

Above I said will lave a comment about UML and semantic. Here is: as UML  
is notation and notation + method, its semantic was likely to be less  
precise. I had a look at Merise too, because I do not trust arguments like  
“every body wants UML, no one ask for Merise which is dead” (I do not know  
about HOOD, so I have no way to talk bout it, due to lack of online  
documents). I did not care and and try to get an overview, and feel UML  
notation was more rich and Merise's method makes me think about the V  
cycle which is famous for its flaws. I though UML = richer notations, so  
better coverage, may be better suited for repetitive reification, which  
seems common, especially for people working alone (better suited in this  
context). Then about lack of semantic, I though: if used as an  
architecture and design outliner, implicit reference to a predefined  
implementation language may not be so bad after all. Wiether one use Ada  
or C, and provided this choice is done for good reason, and the choice is  
made a the very beginning, the one could always refer to task as an  
example, the way the target language handles this. After all, when one say  
“the app will need three concurrent task”, this one will then just say  
“Ada tasking model is like this, C way to handle task is like this”.  
Talking about task this way, is design talking, not implementation  
talking. If UML is design and architecture talking, may be its fuzzy  
semantic is not so much likely to cause trouble.

Note: the semantic matter arise a detailed level, less at the big picture  
level. This is important to note.

Although contradictory to the above, if ever a mathematically defined  
semantic of UML was ever there, this would still be welcome. But then,  
this would implies the process would not be the same as the one suggested  
above.

I was a bit long with this reply, let go for a summary: give UML the  
semantic of the target language (implies this choice is maid à-priori),  
use notation restrictions as much as needed (should be documented, which  
is OK, as UML seems to have provision for so called Preface).


-- 
“Dual licensing is the Perl's way to disinfect the GNU General Public  
Virus!” (anonymous)