"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 Tidmus. 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! :-) Regards, Rick
begin:vcard n:Beton;Richard tel;pager:ICQ: 56840977 tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx tel;fax:01794 833434 tel;work:01794 833458 x-mozilla-html:TRUE url:http://www.beton.freeserve.co.uk/ org:Roke Manor Research Limited;Internet Technology & Networks adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK version:2.1 email;internet:richard.beton@xxxxxxxxxx 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 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature