rj@tcom.stc.co.uk (Ray Jones) (07/20/88)
I've just been browsing through the sw-eng digest and have come across
discussions about software design methods, that, being a newcomer to
the net, I have previously missed. Sorry if this is a little late
but...
I am astounded that I have not heard more talk about formal
methodologies that we in the UK have imported (I think) from the USA.
Haven't (most of you) heard of Ed Yourdon or Michael Jackson (no, no,
the *other* one) and their respective methodologies. I was introduced
to the Yourdon method for real-time systems design, a while ago, only
to find that I've been using the same tools as he suggests for years
(i.e. data flow diagrams, state transition diagrams and structure
charts) but in a less formal way. Yourdon has formalised a structured
method that good analysts and designers would, I think, find very
familiar. If you want to know more about this, check out the books
published by the Yourdon Press (available from Prentice-Hall, in the
UK) by authors such as Ward and Mellor, DeMarco, Yourdon and others.
Don't buy them yourself, though, they cost a fortune (in the UK at
least).
Changing the subject slightly...
One tool that I have not used in years (don't you dare!) is the flow
diagram. The traditional flow diagram is ok for describing simple
systems that have already been designed, but as a design tool they can
be a menace. They encourage non-structured programming and the
indiscriminent use of gotos (let's not get into a discussion about
gotos though, please). Flow diagrams do not, directly, support the
constructs used in modern languages, i.e. while loops, case statements
functions, etc., and are more suitable to the construction of programs
in Fortran IV (Oh, God those were the days...) than languages such as C
and Pascal (and even F77). I find that a high level pseudo-code or
structured English, is a more suitable method of describing the
procedural aspects of a system.
Enough of that, anyone know about any good books on object orientated
design ?
Keep on hacking you guys (snigger, snigger)
Ray
simont@praxis.co.uk (Simon Tait) (07/21/88)
In article <1440@bute.tcom.stc.co.uk> Ray Jones <rj@stc.UUCP> writes: > > I am astounded that I have not heard more talk about formal > methodologies that we in the UK have imported (I think) from the USA. > Haven't (most of you) heard of Ed Yourdon or Michael Jackson (no, no, .. and goes on to describe a number of other methods. None of these would seem to be truly "formal", however. The term "formal methods" is usually reserved for development and specification methods based on mathematics, such as VDM, Z, OBJ, Larch etc. JSP, OOD, etc are usually termed "semi-formal" methods. Michael Jackson is based in London :-) ------------------------------------------------------------------------------- Simon P Tait, ELLA Group, Telephone (0225) 444700. Praxis Systems plc, Telex 445848 PRAXIS G. 20 Manvers Street, Facsimile (0225) 65205. Bath BA11PX, England. -------------------------------------------------------------------------------
acwf@ivax.doc.ic.ac.uk (Anthony Finkelstein) (07/23/88)
Simon Tait in article <2672@newton.praxis.co.uk> writes that JSP and OOD are normally termed semi-formal methods. This is the normal usage but is inaccurate - something is either formal or not! I prefer to use the term formatted to describe such methods - it more accurately captures the essence of the representation schemes associated with such techniques. Pedants rule OK! Anthony Finkelstein
david@geac.UUCP (David Haynes) (07/23/88)
In article <1440@bute.tcom.stc.co.uk> Ray Jones <rj@stc.UUCP> writes: > > Enough of that, anyone know about any good books on object orientated > design ? This, through a tangential leap of astronomic proportions, triggered off a thought which I was going to ask you folks about... In working through possible extensions to my design of a thing called Prism, I was struck by the fact that, while I was not proposing to have a 3GL as the main interface, I was not planning on having a 4GL either, or even an object oriented approach. (in my understanding of the term) A little history: Prism is a protocol-driven, windowed, forms system which works equally well for dumb ascii terminals as it does for, say, X11. The system employs the use of ``smart agents'' to isolate the presentational aspects from the computational aspects of the code, so that the application folk have minimal changes to go from, say, English to French. (or Hebrew or kanji Japanese). When thinking of what sort of language should be used to program this beastie, I was struck by the fact that the language really supports ``transitions'' via ``events''. That is to say, the processing is driven by (almost) random changes in the data. Perhaps, it is clearer to say that the system must handle changes to any of a set of data elements at any time... Where am I leading with all this? Well, the problem is that a dataflow system will not aid the user in the design of this type of system, a flow chart is useless, and the state transition diagram for this would quickly be unweildly (think of a spreadsheet as a form in this system). In some object-oriented systems, this sort of triggered action would be assigned to ``methods'', but I don't think that is a really viable analysis of what is going on here. Your thoughts? -david-
eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) (07/28/88)
>In article <382@gould.doc.ic.ac.uk> acwf@doc.ic.ac.uk (Anthony Finkelstein) >writes: >>Simon Tait in article <2672@newton.praxis.co.uk> writes that JSP and >>OOD are normally termed semi-formal methods. This is the normal usage >>but is inaccurate - something is either formal or not! I prefer to >>use the term formatted to describe such methods - it more accurately >>captures the essence of the representation schemes associated with >>such techniques. Pedants rule OK! >> > "Formatted" ?? Sounds aweful! Anyway, why invent yet another tag when those methods have been called "STRUCTURED" since time immemorial. Incidentally, pedantry is a pre-requisite to working in formal methods! Rich -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keywords: Parallel, Applicative, and Object-Oriented Languages and Systems --------------------------------------------------------------------------- Dr. Richard Artym, + UUCP : ..!ukc!pyr.swan.ac.uk!eeartym Electrical Engineering Dept., + JANET : eeartym@uk.ac.swan.pyr University of Wales, + Phone : [(0792) or (+44 792)] 295536 Swansea, SA2 8PP, + Fax : [(0792) or (+44 792)] 295532 U.K. + Telex : 48358 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ralf@mucs.UX.CS.MAN.AC.UK (Ralf Kneuper) (07/28/88)
In article <382@gould.doc.ic.ac.uk> acwf@doc.ic.ac.uk (Anthony Finkelstein) writes: >Simon Tait in article <2672@newton.praxis.co.uk> writes that JSP and >OOD are normally termed semi-formal methods. This is the normal usage >but is inaccurate - something is either formal or not! I prefer to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >use the term formatted to describe such methods - it more accurately >captures the essence of the representation schemes associated with >such techniques. Pedants rule OK! > >Anthony Finkelstein Sorry, but there can be no method that is 100 percent formal, formality is a question of degree. The problem is that if you want to be formal, you have to use a language and method with formally defined semantics, The language for describing these has to be defined formally itself, etc. - you never get to the bottom of it. At some stage you just have to say "Ok, I *know* what this means and I am not going to take formalization any further". In some way, this is similar to axiomatization in mathematics. When defining the semantics of something you always have to use some language for describing them and just assume that you know what its constructs mean. The difference between informal, semi-formal and formal methods then lies in how far you take this process - do you explain what the various objects of your method mean in terms of natural language plus pretty pictures, in terms of mathematics (in particular mathematical logic), or do you stop somewhere in between? If you are interested, this was put rather strongly by Naur (Formalization in Program Development, BIT 22, 1982, pp 437-453), but he then went over the top and claimed that formal methods are no use since you cannot be completely formal. Ralf -- Ralf Kneuper, Dept of Computer Science, The University, Oxford Road, Manchester M13 9PL, UNITED KINGDOM. UUCP: uunet!mcvax!ukc!man.cs.ux!ralf | Tel: (+44) 61-275 2000 Ext 6134 JANET: ralf@uk.ac.man.cs.ux