home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4424 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.8 KB
  1. Path: sparky!uunet!munnari.oz.au!metro!otc!tbird2!chrisf
  2. From: chrisf@nms.otca.oz.au (Christopher Fraser)
  3. Newsgroups: comp.software-eng
  4. Subject: Graphical Object Design Tools (OMT, Booch..)
  5. Keywords: object oriented design tools
  6. Message-ID: <chrisf.722257945@tbird2>
  7. Date: 20 Nov 92 11:12:25 GMT
  8. Sender: news@otc.otca.oz
  9. Lines: 44
  10.  
  11. I've been looking at James Rumhaugh's OMT design methodology over the past few
  12. days (well, actually, attending a seminar he's been presenting), and was
  13. wondering if anyone would like to share their experiences with actually
  14. applying a methodology like OMT or Booch (even if you just used the object
  15. notations to document your own design methodology). I'm particularly interested
  16. if you used a graphical design tool.
  17.  
  18. My general impression of OMT itself was fairly positive. The object model 
  19. basicly a sanitised version of ER techniques, with additional notations like
  20. inheritance (I though his concept of information paths was especially useful).
  21. The Dynamic model was based on state transition diagrams, with some nice
  22. techniques for modularising the schema. The functional model was, well,
  23. functional decomposition and was presented as something that could feed back
  24. into the object model (Rumhaugh talked a lot about iterative design ... which
  25. was comforting).
  26.  
  27. Methodology aside I though the actual OMT notion itself captures a lot of design
  28. information in a fairly succinctly, formal form. However, the thought of manually
  29. maintaining the diagrams didn't particularly appeal to me; hence this
  30. post. (Much more appealing was the thought of design tools developing into tools
  31. which could actually help the developer track design constraints, like Rhumbah's
  32. information paths).
  33.  
  34. I had a look at the Rational tool, Rose, and wasn't especially impressed.
  35. It's a nice drawing tool (but then, so is MacPaint!) using Booch's
  36. constructs. Mostly, it seemed lacking in the ways it could present the actual
  37. schema information you had painstaking entered; you couldn't filter out
  38. information on the schema, you couldn't merge them together and queries
  39. on the relationships an object was involved in only returned a textual list.
  40. (I probably shouldn't really comment, since I'm not especially familiar
  41. with building them, but schemas built using Booch's notation seem more
  42. cluttered and less design information dense than the equivalent OMT
  43. representation. The Booch notation certainly captures a lot more implementation
  44. semantics. Opinions?).
  45.  
  46. I was also told Ratonal were working on tools to reverse-engineer a Booch
  47. schema for C++ code. They also demonstrated a beta version of a tool for
  48. generating code stubs (which seemed lacking in the required configurability).
  49. Does anyone else know of work being done in these areas?
  50.  
  51. Cheers,
  52. --
  53. Christopher Fraser      "First time surrealists are often confused by the
  54. chrisf@nms.otca.oz.au    similarities between fish and telephones"
  55.