home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / object / 4744 < prev    next >
Encoding:
Text File  |  1993-01-10  |  3.0 KB  |  87 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!cbnewsk!cbnewsk!dwwx
  3. From: dwwx@cbnewsk.ATT.COM (david.w.wood)
  4. Subject: Re: Domain Analysis references
  5. Organization: AT&T Bell Laboratories
  6. Date: Mon, 11 Jan 1993 03:48:21 GMT
  7. Message-ID: <DWWX.93Jan10224821@cbnewsk.ATT.COM>
  8. In-Reply-To: ematz@world.std.com's message of 7 Jan 93 13:55:42 GMT
  9. References: <C0HLCu.JxM@world.std.com>
  10. Sender: dwwx@cbnewsk.cb.att.com (david.w.wood)
  11. Lines: 74
  12.  
  13. In article <C0HLCu.JxM@world.std.com> ematz@world.std.com (Ed Matz) writes:
  14.  
  15.    Not sure if this is the appropriate newsgroup to post this query,
  16.    but I encountered the term while doing some reading on the subject
  17.    of OOA/OOD.   Can anyone out there provide me with some references
  18.    to Domain Analysis so I can find out what it is?   Just about all
  19.    I know about it is its name, but it sounds intrigueing . . .
  20.  
  21.    Please reply via mail.
  22.  
  23.    Thanks.
  24.  
  25.    Ed Matz        ematz@world.std.com
  26.  
  27. Ed,
  28. Domain Analysis is a fairly new area in software engineering.  It is
  29. concerned with analyzing and understanding the "domain" of an
  30. application or set of applications.  For example, in banking one
  31. could write an application concerning morgages.  Now, the usual
  32. process of developing the program is to develop a model and requirements
  33. just sufficiently "broad" to cover the problem(s) to be solved by
  34. the program.  Then when another morgage program is needed, we repeat
  35. the process and for the next one, we repeat the process.
  36.  
  37. Domain analysis is were we would explore the complete area of morgages,
  38. not just explore the domain for one program.  The results of the
  39. analysis are captured in a model.  We can then use that model to
  40. develop applications which are more general or to better partion the
  41. domain into areas of applications.  The results are not just better
  42. requirements, and therefore applications, but we can continuely REUSE
  43. the domain model to develop cohesive programs (in fact, by using
  44. the domain model to organize requirements, and the underlying architectures,
  45. designs, code and test cases, we can achieve reuse throughout the domain).
  46.  
  47. David Wood
  48. AT&T Bell Labs
  49. 3E-337
  50. 200 Laurel Ave
  51. Middletown, NJ 07748
  52.  
  53. (908) 957-3852
  54.  
  55. REFERENCES:
  56.  
  57. R. Prieto-Diaz and G. Arango,
  58. Domain Analysis and Software Systems Modeling
  59. IEEE Computer Society Press
  60. Los Alamos, CA 1991
  61.  
  62. This is a collection of papers on different aspects of Domain Analysis.
  63. It also contains a complete bibliography of articles, books, etc
  64. on domain analysis.
  65.  
  66.  
  67.  
  68. J.M. Neighbors
  69. The Draco approach to constructing software from reusable components
  70. IEEE Transactions Software Engineering
  71. Vol SE-10
  72. pp 564-574
  73. Sept. 1984
  74.  
  75. D.R. Harris and W.L. Johnson
  76. Sharing and reuse of requirements knowledge
  77. In Proc. 6th Annual Knowledge-Based Software Engineering (KBSE-91) Conf.,
  78. pp 65-77
  79. Sept 1991
  80.  
  81. Gerhard Fischer, Andreas Girgensohm, Kumiyo Nakakoji and David Redmiles
  82. Supporting Software Designers with Integrated Domain-Oriented Design Environments
  83. IEEE Transactions on Software Engineering
  84. Vol 18
  85. No 6
  86. June, 1992
  87.