home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / ascii / prieto.ascii < prev    next >
Text File  |  1993-10-19  |  12KB  |  231 lines
  1.  
  2.  
  3.  
  4.  
  5.                     Some  Experiences  in  Domain  Analysis
  6.  
  7.  
  8.  
  9.                                            Ruben Prieto-Diaz
  10.  
  11.  
  12.  
  13.                                                 Reuse, Inc.
  14.  
  15.                                     12365 Washington Brice Rd.
  16.  
  17.                                             Fairfax, VA 22033
  18.  
  19.                                       Tel & Fax: (703) 620-5385
  20.  
  21.                                Email: 70410.3014@compuserve.com
  22.  
  23.  
  24.  
  25.                                                   Abstract
  26.  
  27.  
  28.     In this position paper I describe three of my experiences in doing domain analysis and in
  29. transferring the technology.  Specifically I describe analyses in the domains of command and
  30. control systems, flight simulators, and avionics displays.  These domains are rich enough to
  31. demonstrate the value of domain analysis and show, at the same time, the relatively immature
  32. state of domain analysis.
  33.  
  34.  
  35. Keywords: domain analysis, the "sandwich" method, command and control systems, avionics
  36. systems.
  37.  
  38.  
  39. Workshop Goals: to share experiences in the application of domain analysis methodologies.
  40.  
  41.  
  42. Working Groups: domain analysis and engineering.
  43.  
  44.  
  45.  
  46.                                                Prieto-Diaz- 1
  47.  
  48.  
  49. 1      Background
  50.  
  51.  
  52.  
  53. Domain  analysis  is  a  concept  that  keeps  troubling  organizations  implementing  reuse  programs.
  54. Although  domain  analysis  is  a  simple  concept,  like  reuse,  its  practice  is  not  simple.   Domain
  55. analysis is similar to systems analysis but for a class or family of systems rather than for a single
  56. application. The objective in domain analysis is to find commonalities among systems in the same
  57. domain or application area and synthesize generic models or architectures that characterize families
  58. of applications. Domain analysis is a key activity in pre-planned reuse.
  59.  
  60.  
  61. One of the objectives in pre-planned reuse is to have a repeatable process for doing domain analysis.
  62. Some guidelines and methods have been proposed but it is still a research area.  These methods
  63. are very recent and data on their performance is not available yet. The three leading methods for
  64. domain analysis are: FODA (Feature Oriented Domain Analysis) from the Software Engineering
  65. Institute in Pittsburgh [1]; the STARS Reuse Library Process Model, also known as the Sandwich
  66. method [2 ]; and the Domain Analysis and Design Process from DISA/CIM (Defense Information
  67. Systems Agency/Center for Information Management),in Arlington, Virginia [3 ].
  68.  
  69.  
  70.  
  71. 2      Position
  72.  
  73.  
  74.  
  75. I am an advocate of the Sandwich method since, of course, Iam its inventor (btw, a possible name
  76. for this method could be Ruben's Sandwich.)  I have used this method in several occasions and
  77. taught it to several organizations. The following three experiences providea flavor of what you can
  78. expect from doing domain analysis using this method.
  79.  
  80.  
  81. My first experience in applying this method was for the domain of command and control systems.
  82. My employer at the time was interested in reducing development costs and improving quality by
  83. reusing parts from their legacy systems. I was assigned to work with a veteran expert with 17 plus
  84. years of experience in developing C2 systems. We decided to focus on three operational systems
  85. that were well documented. Requirements documents were made available to us, however, we did
  86. not have access to source code. C2 systems are highly classified.
  87.  
  88.  
  89. We began bottom-up by inspecting selected samples from the massive requirements specifications.
  90. We  did  a  preliminary  vocabulary  analysis  and  were  able  to  separate  mechanized  from  manual
  91. activities. This separation helped us to properly scope the domain and draw a domain boundary.
  92. Human driven activities such as decision making, information review, comparing courses of action,
  93. etc.   were  considered  outside  the  domain.   We  also  found  a  high  incidence  of  activities  related
  94. to message processing.  This finding gave us aclue to pay close attention to the role of message
  95. processing in C2 systems.
  96.  
  97.  
  98. Next, we attempted a top-down analysis. We began by comparing the architectures of the three
  99. systems and could not find any similarity; each architecture looked completely different.  One of
  100. the  reasons,  as  explained  by  the  expert,  was  that  the  designs  of  these  systems  were  hardware-
  101. driven, that is, the equipment was selected first and the requirements drafted to accommodate the
  102. hardware. Software was, in most cases, considered the glue that makes systems work.  We stepped
  103. back from this approach and reviewed basic principles and theory of C2 systems.  We then went
  104. back to the architectures and were ableto recognize common patterns.
  105.  
  106.  
  107. After several iterations and consultations with other experts, we were able to propose a high-level
  108. generic architecture,  common not only to all three systems, but,  to future systems as well.  We
  109.  
  110.  
  111.  
  112.                                                       Prieto-Diaz- 2
  113.  
  114.  
  115. went back to our bottom-up analysis and did a vo cabulary analysis on the data manipulated by C2
  116. systems. We discovered that all data that flows through the system could be formatted in a small
  117. set of standard templates.  We went back to the architecture postulated during initial top-down
  118. and refined it to accommodate for standard (i.e., template) processing of messages. Here we were
  119. fully engaged in a sandwich process.
  120.  
  121.  
  122. The new re-structuring of the architecture allowed us to discover yet another interesting character-
  123. istic of our architecture- almost every subsystemof a C2 system can be represented as a specialized
  124. message processor.  We then proposed a generic architecture for message processors and demon-
  125. strated that a C2 system could be build by assembling different instantiations of message processors.
  126. Needless to say, our work was initially received with skepticism, however, as the idea of being able
  127. to build C2 systems out of leggo-like parts sank in, the engineers b ought into it completely.
  128.  
  129.  
  130. This effort took us six months working half time, a total of 3 MM. The following two cases are
  131. short experiments on trying to teach domain analysis hands-on.  Since domain analysis is a difficult
  132. and complex technique, and since it has notevolved into a mature process or method yet, I decided
  133. to teach it by example on domains familiar to theparticipants.  Idesigned a three-day course. The
  134. first day for presenting concepts and the method and the lasttwo for starting a domain analysis
  135. on a domain selected by the class (i.e., the customer.)
  136.  
  137.  
  138. The organization in the first case wanted to use the course to analyze the domain of flight simulators.
  139. After an initial scoping, the class realized the domain of flight simulators was broad and complex.
  140. I proposed two alternatives:  to do a high level,  general analysis of the domain,  or to look for a
  141. subdomain suitable for a more detailed analysis.  The class selected the latter. After lo oking at
  142. several components and activities of flight simulators, we found that the design and validation of
  143. empirical equations that characterize aircraft behavior was an extremely time consuming endeavor.
  144.  
  145.  
  146. Typically, designers work with a virtual aircraft, one that exists on a drawing board and in mathe-
  147. matical models. In order to achieve realistic simulation,the coefficients of several complex equations
  148. have to be found. The process is by trial and error.  The designer, literally, plays with the coeffi-
  149. cients until the expected behavior is observed. To be able to do this, an engineer has to create an
  150. interactive environment forplotting the equation and for manipulating the coefficients.  Unfortu-
  151. nately, each environment is different because equations are different.  As a result engineers spend
  152. most of their time creating and tuning the environments and only a fraction of their time playing
  153. with the coefficients.
  154.  
  155.  
  156. We did a preliminary vocabulary analysis of the concepts in this activity and produced a taxon-
  157. omy of classes of equations, behaviors, and environments.  We then designed generic scripts (i.e.,
  158. templates) in their high level graphical language for instantiating different kinds of environments.
  159. Since this was a two day effort only, we were limited to planning the next steps:  to implement
  160. several scripts and to make them available in a catalog to design engineers.  A few months later I
  161. learned that design engineers were reusing predefined templates that they could quickly customize
  162. for playing with their equations.
  163.  
  164.  
  165. The domain of avionics displays was thetopic of the next experience.  Again, the class recognized
  166. that  the  domain  was  broad  and  complex, but  in  this  case  they  decided  to  take  a  stab  at  the
  167. whole domain. We started bottom-up with a vocabulary analysis of all concepts, keywords, nouns,
  168. and  verbs  used  in  avionics  displays.   The  concept  of  "tapes"  appear  to  recur  in  most  kinds  of
  169. displays. Tapes are display elements with graduation marks used tomeasure variable parameters.
  170. Temperature,  airspeed,  attitude,  pressure,  etc.,  all  are  displayed  in  some  kind  of  a  tape  form.
  171. Since each parameter was considered unique,engineers were designing their own tapes. The course
  172.  
  173.  
  174.  
  175.                                                       Prieto-Diaz- 3
  176.  
  177.  
  178. helped them to realize that designing a generic tape packageor a family of tape classes would make
  179. their job easier,  promote reuse,  and help them to agree on some standards.  Although a generic
  180. architecture of avionics displays was not derived during the seminar, the concept of standard tapes
  181. more than paid off for the unmet expectations.
  182.  
  183.  
  184. I hope  that  these  experiences  demonstrate  the  value  of  domain  analysis  and  show, at  the  same
  185. time, the relative immature state of domain analysis. There is significant research efforts aimed at
  186. improving domain analysis and at integrating domain analysis as part of software development. I
  187. also hope that these brief descriptions have proven useful and provide some reusable experiences.
  188.  
  189.  
  190.  
  191. References
  192.  
  193.  
  194.  
  195. [1]  K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, "Feature-Oriented Domain Analysis
  196.      (FODA)  Feasibility Study,"  Tech. Rep. CMU/SEI-90-TR-21, Software Engineering Institute,
  197.      Carnegie Mellon University, Pittsburgh, PA, November 1990.
  198.  
  199.  
  200. [2]  "Sandwich  Method  -  A  Domain  Analysis  Method  Developed  by  Reuse, Inc.  and  Available
  201.      in Reuse Library Pro cessMo del," Tech. Rep. IBM STARS CDRL 03041-001, U.S. Air Force
  202.      Electronic  Systems  Center,  Hanscom  Air  Force  Base,  MA,  July  1991.  Also  available  from
  203.      ASSET, (304)594-3954.
  204.  
  205.  
  206. [3]  DISA/CIM Software Reuse Program, 701 South Courthouse Rd., Arlington, VA, 22204-2199,
  207.      Domain Analysis and Design Process, March 1993. POC: Sherrie Chubin (703)285-6900.
  208.  
  209.  
  210.  
  211. 3      Biography
  212.  
  213.  
  214.  
  215. Ruben Prieto-Diaz is president and founder of Reuse, Inc., a software-reuse consulting company.
  216. He is contract consultant to ScientificApplications International Corporation for STARS, devel-
  217. oped the STARS Reuse Library Process Model, and is participating in the STARS Demonstration
  218. Project. He is co-editor of Domain Analysis and Software Systems Modeling, IEEE Computer So-
  219. ciety, 1991, and Software Reusability, Ellis Horwood Workshop Series, Chichester, England, 1993,
  220. and the author of several technical papers in software reuse, classification, and domain analysis.
  221.  
  222.  
  223. Prieto-Diaz received a BS in aerospace engineering from St. Louis University, a MS in engineer-
  224. ing design and economic evaluation, and a MS in electrical engineering both from University of
  225. Colorado, Boulder, and a PhD in computer science from University of California, Irvine.  He is a
  226. member of IEEE, IEEE-CS, and ACM.
  227.  
  228.  
  229.  
  230.                                                       Prieto-Diaz- 4
  231.