>-----Original Message-----
>From: Simon Wright [mailto:[log in to unmask]]
>Sent: 14 February 2003 21:02
>To: [log in to unmask]
>Subject: Re: Designing for Ada 95?
>
>
>> From: "Bruce Hennessy" <[log in to unmask]>
>
>> My point really was just that a common nomenclature is better than
>> everyone having their only personal drawing methodology - it saves
>> alot of time if we are all speaking the same language. For companies
>> trying to make money off developers perhaps confusion and
>> differences are better things, but I think there is a strong case
>> for the opposite as well. With a common design language as a
>> commodity, there is then much room for money to be made in tools to
>> help automate software development processes... This is happening
>> now with UML and the model driven architecture -
>> http://www.omg.org/mda/.
>
>Agreed  with all that, really.
>
>At least with a common set of diagramming techniques and some semantic
>background you have somewhere to start from.
>

This is fine but does not represent the current situation.  Currently we have a "common set of diagramming techniques" but we do not have much (if any) "semantic background" and, unfortunately, many people seem to regard UML and design to be "finished" rather than "somewhere to start from".

The problem at present, especially when targeting Ada, is that UML, as described in books and as implemented in current tools, drives you down a path of programming by class extension which may not be appropriate for all problem domains.  It compounds this problem by not providing standard support for those areas where Ada is _more_ expressive and capable of _better_ abstraction than the design notation.  Ada's packages and private types for example.  I have even heard UML tool vendors describing Ada as "deficient" because it does not match UML's model of the world properly.

The end result is that real design skills are being supplanted by knowledge of particular tools and mechanical ways of using them.  In the end we reach the farcical levels of Shlaer Mellor where the very existence of a software design process is denied (SM alleges that once you have done the OO analysis, you just code the objects and tip them in a box and stir - no software design is required at all).

At Praxis we have a put a lot of effort into a design approach for SPARK (and hence for Ada) called INFORMED; this places great emphasis on minimising coupling between units by reducing information flow (which is measured by the SPARK Examiner) to a functional minimum.  The method used to minimise information flow is careful choice of where "state" is located; e.g. an instance of an abstract data type as a local variable of a subprogram creates less information flow than use of a library-level abstract state machine.  We have found it interesting how hard it is to get these concepts across to UML users and tool vendors who tend to see location of state as an implementation detail where for us it is a prime design driver!

Peter

PS.. I wonder if there is any connection between the exporting of software engineering jobs to India etc. and this trend to see design as a mechanical, tool-driven process?  Real insight is rather harder to export.



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept 
for the presence of computer viruses.

www.praxis-cs.co.uk
**********************************************************************