home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4963 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  4.3 KB
  1. Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!latcs1!amdahl1.lat.oz.au!baragry
  2. Newsgroups: comp.software-eng
  3. Subject: Re: What is Software Design?
  4. Message-ID: <1992Dec15.013037.6513@latcs1.lat.oz.au>
  5. From: baragry@amdahl1.lat.oz.au (Jason Baragry)
  6. Date: Tue, 15 Dec 1992 01:30:37 GMT
  7. Sender: news@latcs1.lat.oz.au (news)
  8. References: <Bz7KMv.M5z@fiu.edu>
  9. Organization: Comp Sci, La Trobe Uni, Australia
  10. Nntp-Posting-Host: amdahl1.lat.oz.au
  11. Lines: 81
  12.  
  13. In article <Bz7KMv.M5z@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
  14. |> 
  15. |> I've just finished reading an article in the latest edition of _The C++
  16. |> Journal_.  The article is named _What is Software Design_ and it was 
  17. |> authored by Jack Reeves.
  18. |> 
  19. |> The ideas that he presents confirmed my suspicions about some of the problems
  20. |> that we currently have in software engineering.  I whole-heartedly suggest
  21. |> that anyone who can find the article do so and read it.
  22.  
  23.     There is a while heap of related articles which have been published,
  24. the problem is being able to locate them! I haven't read the article you mention
  25. but I would bet that I have "read it" with a different title by a different
  26. author, published in a different journal. Everyone talks about the same thing
  27. but not to many people do anything about it.
  28.  
  29. |>  
  30. |> Here are some of the key points as I read them:
  31. |>  
  32. |> -There are some key differences between developing hardware and developing
  33. |>  software.
  34.  
  35.     There was a big discussion about this a while ago on this newsgroup.
  36. If you want so summary I'd be happy to send it to you.
  37.  
  38. |> -After hardware is designed, it is produced.  The cost of production is
  39. |>  often in excess of the cost of design.
  40.  
  41.     As Brad Cox would gladly point out, this is mainly because you have to
  42. purchase the components. You can't simply electronically copy them.
  43.  
  44. |> -For a meaningful parallel between hardware and software development to 
  45. |>  exist, the coding of software should be considered part of the design process.
  46. [...]
  47. |> -Engineering designs must be complete so that production can be carried out
  48. |>  successfully.
  49.  
  50.     I believe one of the major differences is that when you design an
  51. engineering system, your final design actually represents the implementation
  52. because the objects depicted in the design are actually members of the 
  53. implementation medium. The traditional design process used in software 
  54. development, does not finish with a representation of the implementation.
  55.     People I have talked with (programmers) then argue that if we did 
  56. that for software our diagrams would be to complex because our implementation
  57.  medium is the programming language.
  58.     This is then the point where we have to look at our view of
  59.  implementation medium. Should it be the programming language level ? I agree
  60. with the article in IEEE Software (Nov 90) by Brad Cox, which discusses
  61. objectifying software modules. This is the type of implementation medium I 
  62. believe we should be looking at. Modules with a defined functionality, which 
  63. may be implemented in any way (OO, proceduraly, rules, etc) but can be
  64. "fitted together" to construct a design which represents the implementation.
  65.  
  66.     I am currently working on a design method which would support such 
  67. ideas (but it is still relatively earrly).
  68.  
  69. [other points deleted].
  70.  
  71. |> 
  72. |> All of these are basically changes in perception.  However, one consequence
  73. |> of this change would be the recognition that coding as early in the process
  74. |> as possible is useful.  But this should be no surpise to us, given the shifts
  75. |> that we are seeing toward rapid prototyping and the like.
  76. |>  
  77. |> Comments?
  78. |> 
  79.  
  80. I can see what you are saying, but I think it means generating components in the
  81. design which are represented by the implementation medium. Instead, of moving
  82. code further up the design process I think it means using high-level 
  83. components with predefined functionality which can be implemented by a piece
  84. of previously implemented code.
  85.  
  86. Jason.
  87. -------------------------------------------------------------------------------
  88. Jason Baragry.            |    Amdahl Australian Intelligent 
  89. Dept Comp. Sci. & Comp. Eng.,    |        Tools Program
  90. La Trobe University.,        |    baragry@latcs1.lat.oz.au
  91. Bundoora. 3083.            |    Phone:    +61 3 479 1477
  92. Australia.            |    Fax:    +61 3 470 4915
  93. --------------------------------------------------------------------------------
  94.