[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a few questions

"Gerald H. Hilderink" wrote:

> <snipped>

> I am not entirely pessimistic about the UML. The UML is considered to be a
> third-generation modelling language providing common notations and a
> rigorous semantic framework for writing software blueprints. The UML may be
> used to visualize, specify, construct, and document the artefacts (analysis,
> design, and implementation) of a software intensive system.
> In the UML one can describe aspects of the software that cannot be described
> by data-flow diagrams. For example, describing database-oriented programs in
> the UML seems to be very effective using entity relation diagrams. Also,
> data-flow diagrams can describe concurrency more efficiently than the UML.
> Concurrency in the UML is a mess.
> IMHO, software development starts with the analysis of task domains that
> operate concurrently. This result in a network of communicating processes,
> thus, a data-flow diagrams. THEN I might be interested in the objects I can
> use to implement these processes. The UML can help me structuring the
> sequential nodes in the network.
> There are many problems with the UML. For example, in the UML design process
> you start with classes or use cases. These more or less eliminate
> concurrency from the start. We should use data-flow diagrams from the start
> in the UML process.
> Some applications are more concurrent than others. Your examples are highly
> concurrent consisting of many small sequential processes in parallel.
> Windows programs often contain few concurrent processes that are largely
> sequential. A data-flow diagram shows use the degree of parallelism, which
> the UML cannot do so easily.

I was recalling today the book "Practical Parallel Programming" written by Chalmers and Tidmus in 1996 (I met one of the
authors today). In one important respect it is a really good book: it distills the chief body of knowledge, learned by
the community at large during the transputer heyday, concerning how to design parallel systems by means of the
occam/transputer paradigm.

Why is this interesting? Because systems are concurrent in a whole variety of different ways. The obvious way is that
the system consists of large chunks of 'algorithm' between which data is passed. By encouraging the wider use of
dataflow diagrams in UML in the interests of clean system design, it is possible that this obvious way is the only way
that is ever noticed and implemented. This would clearly be a missed opportunity if ever such systems are to benefit
from parallel execution hardware. As an example of what I mean, consider a processor farm (i.e. a system in which the
work can be broken into chunks that can each be executed independently by one of many processors in a 'processor pool').
I think (and I stand to be corrected) that it is highly unlikely that farm-style concurrency would be readily apparent
in a UML + dataflow approach, unless the designer(s) already knew the sort of techniques summarised by Chalmers and

As a digression, in talking of 'object-oriented design', we must be clear in recognising that most people take this to
mean 'class-oriented design', not the ambiguous alternative 'instance-oriented design'. So the instance view (i.e. the
dataflow diagram) is widely felt to be rather unimportant. I guess I just stated the obvious! :-)


tel;pager:ICQ: 56840977
tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx
tel;fax:01794 833434
tel;work:01794 833458
org:Roke Manor Research Limited;Internet Technology & Networks
adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK
title:Internet Consultant
note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A
fn:Rick Beton

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature