From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,486d4972706e99db
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Bug rate and choice of programming language
Date: Wed, 11 Aug 2010 06:36:14 +0100
Organization: A noiseless patient Spider
Message-ID: <m2eie5zp69.fsf@pushface.org>
References: <9b242840-3400-4d5c-aa1e-db238701aebe@l6g2000yqb.googlegroups.com>
	<3e1c5adb-a0b8-4ffd-9268-fcaa2e3ad13c@v15g2000yqe.googlegroups.com>
	<op.vg8y581rxmjfy8@garhos>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 11 Aug 2010 05:36:16 +0000 (UTC)
Injection-Info: mx03.eternal-september.org;
 posting-host="KCXegvZb5vh43D+f3BR6Ew";
	logging-data="4301"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18tYhOn5VPeTl+GStQ6JbtuiBr57diTTkI="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin)
Cancel-Lock: sha1:Ht/OEKpsl4ZDYycd5erfitNkj6Y=
	sha1:AHCHhEIjA8lFVq902sqFZiX+kLM=
Xref: g2news1.google.com comp.lang.ada:13102
Date: 2010-08-11T06:36:14+01:00
List-Id: <comp.lang.ada>

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Tue, 10 Aug 2010 22:53:25 +0200, Phil Thornley
> <phil.jpthornley@gmail.com> a écrit:
>> http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html
>
> Another quote from the source
>
>> Control flow analysis can be conducted using tools or done manually at
>> various levels of abstraction (module, node, etc.) and is done for the
>> following reasons:* Ensure the code is executed in the right sequence.
>> * Ensure the code is well structured.
>> * Locate any syntactically unreachable code.
>> * Highlight the parts of the code (e.g., loops) where termination
>>   needs to be considered.
>> This may result in diagrammatic and graphical representations of the
>> code being produced.
>
> I feel the last sentence (previous text was quoted for context), may
> be a good reason to mitigate some (bad) evaluation of UML or UML- like
> representations. It seems their experience shows some graphical
> representation at some level may help. This does not really advocate
> for UML, rather for some kind of multi-dimensional representations,
> like graphical representations are.

What you would get from this is a representation of the code.

UML is not a good match for full Ada (not sure it's that good a match
for Java, come to that; mainly because it's a hotchpotch of
techniques without a huge amount of semantic precision).

What can be done is to specify a 'profile', ie tie down a subset of UML
and add extensions to give UML constructs a more precise meaning; and
then you can specify a translation from thence to the language of your
choice. I should add that I'm coming from a Shlaer-Mellor OOA background
(http://en.wikipedia.org/wiki/Shlaer-Mellor).

What this approach won't do is to support round-trip development (change
the model, generate code, change the code, automatically import the
changes back into the model), because the generation process chooses
appropriate templates based on model structure and annotations, and
these are necessarily a particular subset of full Ada.