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 / bailin.ascii < prev    next >
Text File  |  1993-10-19  |  17KB  |  330 lines

  1.  
  2.  
  3.  
  4.  
  5.            KAPTUR,  Elvis,  Hendrix,  and  Other  Acronyms:
  6.  
  7.  
  8.                              Domain  Engineering  at  CTA
  9.  
  10.  
  11.  
  12.                                              Sidney C. Bailin
  13.  
  14.  
  15.  
  16.                                            CTA Incorporated
  17.  
  18.                                       6116 Executive Boulevard
  19.  
  20.                                           Rockville, MD 20852
  21.  
  22.                                            Tel:  (301) 816-1200
  23.  
  24.                                         Email: sbailin@cta.com
  25.  
  26.  
  27.  
  28.                                                   Abstract
  29.  
  30.  
  31.     This is less a position paper than a short summary of what CTA's Software Development
  32. Automation Group (SDAG) is doing in the area of software reuse.  You can think of it as a
  33. statement of what we see as important, and the key techniques to b e pursued.  For background
  34. on our methodology of reuse, see my WISR 92 position paper, as well as others listed in the
  35. references section.
  36.  
  37.  
  38. Keywords: Domain Analysis, Reuse, Model-Based Reasoning, Case-Based Reasoning, Concept
  39. Formation, Repository Interconnection
  40.  
  41.  
  42. Workshop Goals: Networking. Checkpointing the state of thecommunity.
  43.  
  44.  
  45.  
  46.                                                   Bailin- 1
  47.  
  48.  
  49. 1      Background
  50.  
  51.  
  52.  
  53. We have been working in reuse for NASA/Goddard Space Flight Center's Data Systems Technology
  54. Division since 1986.  This work has led to the development of most of the tools described below.
  55. Recently, we have begun working as part of the Unisys STARS team to introduce KAPTURtech-
  56. nology into that environment, and to unify it withthe STARS Orgasnizational Domain Modeling
  57. (ODM) method.   We have  also  recently  begun  work  with  the  Air  Force's  Rome  Lab oratory to
  58. incorporate a Hendrix-like learning capability in the Knowledge Based Software Assistant.
  59.  
  60.  
  61.  
  62. 2      Position
  63.  
  64.  
  65.  
  66. KAPTUR: Domain Engineering Tool. KAPTUR (Knowledge Acquisition for Preservation of
  67. Tradeoffs and Underlying Rationales) isa to ol forrecording, structuring, and reusing engineering
  68. knowledge. Such knowledge includes issues that were raised during development, alternatives that
  69. were  considered, and  the  reasons  for  choosing  one  alternative  over  others.   KAPTUR organizes
  70. software knowledge into domains, which are families of similar systems (examples of domains include
  71. satellite control center software,  radar manager software,  etc.). Within a given domain, assetsQ
  72. existing systems and subsystems, object classes, function implementationsQare organized in terms
  73. of their distinctive features. Each distinctive feature represents an important engineering decision
  74. that went into the development of an asset.  The distinctive features provide a means of comparing
  75. and  contrasting  alternative  technical  approaches  in  a  domain.   Assets  at  any  hierarchical  level
  76. can be compared and contrasted in this way,  from system and subsystem architectures down to
  77. individual function implementations.
  78.  
  79.  
  80. Each feature of an asset has certain information that is always attached to it:
  81.  
  82.  
  83.  
  84.     ffla description of the engineering decision that the feature represents
  85.  
  86.  
  87.     ffla summary of the tradeoffs that were considered in arriving at the decision
  88.  
  89.  
  90.     fflthe ultimate rationale for the deicision.
  91.  
  92.  
  93.  
  94. KAPTUR uses  hypertext  techniques  to  allow  the  user  to  navigate  among  assets,  their  features,
  95. and the background information of a feature. The user can ask to see the altnernatives of a given
  96. feature, and will be pointed to those assets not possessing that feature.
  97.  
  98.  
  99. ElvisC - A Tool for Building a Domain Taxonomy. ElvisC 1 is a tool that applies a concept
  100. formation algorithm (called Cobweb) to automatically organize assets into a hierarchy of meaningful
  101. categories.  Asset descriptions are provided to ElvisC in terms of features.  The featurespace is
  102. open-ended, and can be interactively extended when an asset is entered. In essence, ElvisC looks
  103. for features that tend to occur together, and uses these as the basis for defining clusters of assets.
  104. ElvisC was  originally  developed  for  NASA/Goddard  as  a  tool  for  organizing  and  maintaining  a
  105. component repository, but we see it alsoas a domain analysis tool.  Domains typically go through
  106. a  process  of  evolution:  in  the  early  stages  a  faceted  classification  is often  the  most  natural  or
  107. feasible way to describe concepts in the domain; later, as practice becomes more regular and the
  108. alternatives become clearer, a hierarchical classification becomes feasible.  ElvisC can be used as a
  109. tool to facilitate this evolution by suggesting likely categories in a hierarchical classification.
  110. ___________________________________________________1
  111.      ElvisC stands for Experiment in Libraries with Incremental Schemata and Cobweb.
  112.  
  113.  
  114.                                                          Bailin- 2
  115.  
  116.  
  117. Repository Interconnection Standard. We are active in an AIAA working group to define a
  118. standard for reuse repository interconnection. This work is being performed in conjunction with
  119. the Reuse Library Interoperability Group (RIG). The work builds upon the Asset Library Open
  120. Architecture Framework (ALOAF) developed for the STARSprogram, and is based on a three-level
  121. information model which carries the ALOAFto a greater degree of detail. This work has just begun
  122. and is expected to result in prototype demonstrations towardsthe end of the calendar year.
  123.  
  124.  
  125. Domain  Analysis  in  Flight  Simulation.  The  Mission  Simulator  System  (MSS)  is  a  highly
  126. configurable flight simulator. MSS is sold as a product and has also served as the basisfor several
  127. part-task  trainers  (PTTs)  built  for  the  Government,  including  the  F-15/F-16 PTTs  for  the  Air
  128. National Guard. The configurability of MSS stems from the fact that instruments, controls, engines,
  129. weapons, operational flight programs (OFPs), jammers, artilleries, radars, and missiles (JARMs)
  130. can be added or deleted without affecting the remainder of the simulation.  MSS is a commercially
  131. successful example of domain engineering: the software adheres to a reference architecture for flight
  132. simulators that can be (and has been) instantiated to meet widely varying requirements.
  133.  
  134.  
  135. Domain Analysis in Satellite Control. In 1988 CTA performed a domain analysis of satellite
  136. control centers for NASA/Goddard Space Flight Center.  The analysis was based on a study of
  137. seven existing systems, from which a reference architecture was abstracted.  The architecture was
  138. then refined using object-oriented partitioning criteria. The KAPTUR tool was developed initially
  139. to support this work. Since then, a domain analysis of satellite command management systems has
  140. been performed for the same client, and the results put intoKAPTUR. Work is now continuing on
  141. the development
  142.  
  143.  
  144. Knowledge from Pictures Environment.  This is a multi-tool environment intended to support
  145. high-level  model-based  reasoning  about  software.  The  environment  infrastructure  consists  of a
  146. graphical language for describing component interconnection, a table-based behavior description
  147. language, and a model repository. The repository is a set of model descriptions that cross-reference
  148. one  another.  In  the  model  repository,  there  is  no  explicit  notion  of  system,  only the  notion  of
  149. component. A  component may contain other components, and in this sense it may be considered
  150. as  a  system; on  the  other  hand,  a  component  containing  other  components  may  itself  occur  as
  151. a subcomponent in a still higher-level component. This uniform treatment of "components" and
  152. "systems"  encourages  the  reuse  of  existing  models  as  building  blocks  in new  mo dels,  with  the
  153. consequent semantic benefits mentioned in the Introduction.
  154.  
  155.  
  156. We distinguish between component types and component instances.  Each model in the repository
  157. describes a component type. Instances of this type may occur in other (higher-level) models. The
  158. description  of  a  higher-level  model  M references  the  descriptions  of  the  component  typ es  whose
  159. instances M contains.
  160.  
  161.  
  162. The  distinction  between component  types  and  instances  has  a  couple  of  advantages.   First, a
  163. model can contain more than one instance of a given componenttype.  For example, the model
  164. of a building's climate control system may contain more than one air-conditioning unit.  Second,
  165. a  change  to  the  definition  of  a  component  typ e  is automatically  propagated  to  its  instances  in
  166. all  other  models.  The  user  of  the  tool  is  need  perform  multiple  updates  to  implement  a  single
  167. conceptual change.
  168.  
  169.  
  170. Tools  that  operate  in  the  KFP environment  include  the  Formal  Interconnection  Analysis  Tool
  171. for verifying design properties, the Diagnostics Inferred from Graphics Tool which generates fault
  172. detection and isolation rules from the model descriptions, and the Multi-Aspect Simulation Tool,
  173. described below.
  174.  
  175.  
  176.  
  177.                                                          Bailin- 3
  178.  
  179.  
  180. Multi-Aspect Simulation Tool (MAST). MAST is an environment for building and executing object-
  181. oriented  models  of  complex  electro-mechanical  systems.  The  design  is  based  on  the connection
  182. manager approach described in the Software Engineering Institute's (SEI's) recommendations for
  183. flight simulators. The SEI approach has been extended by independently formalizing each aspect
  184. of a component's behavior, integrating work on discrete event simulation done by Bernard Zeigler
  185. at the University of Arizona, and implementing the design using the object-oriented techniques of
  186. multiple inheritance and virtual base classes. The models produced in this environment are highly
  187. comprehensible  and  unusually  maintainable.  The  subcomponents  produced  during  construction
  188. of the model have been reused in different models without modification.  The types of behavior
  189. exhibited by the model during simulation have b een mo difiedand extended without difficulty.
  190.  
  191.  
  192. Hendrix:  A Meta-Tool.  Hendrix 2  is an existing meta-modeling capability which hasgrown
  193. out of CTAUs workfor NASA/Goddard and is based on CTA's Configurable Graphical Editor.
  194. Hendrix started off as an automated software design critic which is configurable to support different
  195. graphical  design  notations  and  different  design  rules.  The  Hendrix  rule  base is  implemented  in
  196. NASA's  CLIPS language.   Hendrix  supports  two  functions  that  have  made  its  evolution  into  a
  197. meta-tool a technically straightforward task: 1) the ability of the user to easily define newdesign
  198. rules (without having to code them in CLIPS), and 2) the ability of the user to define new design
  199. concepts in terms of previously defined concepts.
  200.  
  201.  
  202. Defining  new  rules  in  Hendrix.  The  user  defines  a  new  design-evaluation  rule  by  drawing  an
  203. example  of  the  erroneous  situation  which  is  to  be  caught  by  the  tool.   Hendrix  generalizes the
  204. example into a CLIPS rule that will detect instances of this situation within an engineering model.
  205. The user specifies a diagnostic message to be issued when the rule fires. The diagnostic message can
  206. reference the design elements in the exampleQthese element identifiers are replaced by variables in
  207. the generated rule, and in any particular model will be instantiated to the model elements involved
  208. in the violation.
  209.  
  210.  
  211. Defining new concepts in Hendrix.  A similar approach is used in Hendrix to allow the user to define
  212. new concepts. In this case, the user draws an example of an instance of the concept, and Hendrix
  213. generates a CLIPS rule that asserts the concept as holding whenever this pattern is detected in
  214. a model.  More than one pattern can be designated as examples of a particular concept.  Hendrix
  215. generates one recognition rule for each pattern (this allows the user to define recursive concepts).
  216.  
  217.  
  218. Associating concepts with graphical symbols in Hendrix. Having defined a new concept to Hendrix,
  219. the user is prompted to select either an arc type or a node type to represent the concept.  Apalette of
  220. available arc types (e.g., dotted, dashed, with/without arrows, etc.) and no de types (i.e., different
  221. geometric  shapes)  are  presented.  If  the  new  concept  is  a  relation  between  objects, the  user  is
  222. prompted to select an arc type; if the new concept is a type of object, the user is prompted to
  223. select a node type to represent that type of object.
  224.  
  225.  
  226.  
  227. 3      Comparison
  228.  
  229.  
  230.  
  231. The KAPTUR approach to domain analysis is similar in spirit andin some details to the STARS
  232. Organizational Domain Modeling method (see the paper by Roberta Burdick in this workshop).
  233. Specifically,  the  emphasis  on  describing  exemplars,  the  distinction  between  descriptive  and  pre-
  234. scriptive  modeling, the  use  of  a  hierarchical  feature  space  for  characterizing  alternatives  in  the
  235. domain, and the emphasis on capturing contextual information such as tradeoffs andrationales,
  236. ___________________________________________________2
  237.      Hendrix stands for Help Evaluating New Designs with Rules Interactively Extendible.
  238.  
  239.  
  240.                                                          Bailin- 4
  241.  
  242.  
  243. are  all  common  between  KAPTUR and  ODM.  This  has  led  us  to  seek  a  unification  of  the two
  244. approaches.
  245.  
  246.  
  247. Our work on model-based reasoning in software engineering draws on ideas developed at the Soft-
  248. ware Engineering Institute (see Sholom Cohen's paper in this workshop) and on ideas of Parnas
  249. (1990)  and  Harel  (1992).  The  basic  motivation  is  to  view  softwae  engineering  as  a  process  of
  250. creating models, asking questions about them, and refining them, with as much automated code
  251. geneation as possible to convert the models into code.
  252.  
  253.  
  254. There  has  been  a  fair  amount  of  experimental  work  in applying  machine  learning  to  aspects  of
  255. software  development  (Esteva  and  Reynolds,  1990;  O'Reilly  and  Oppacher, 1991; Reynolds  and
  256. Maletic, 1991; Willis and Paddon, 1991; Wu and Leong, 1991) but our work views learning as an
  257. essential aspect of a knowledge-based software development environment. In this sense, our work
  258. is guided more by encounters with the problems ofknowledge-based software assistance than by an
  259. interest in applying machine learning to a new domain.
  260.  
  261.  
  262.  
  263. 4      References
  264.  
  265.  
  266.  
  267. S.C.  Bailin  and  S.  Henderson.  A tool  for  reasoning  about  software  models.  Proceedings  of  the
  268. Computer Assurance Conference, ACM Press, June 1993.
  269.  
  270.  
  271. S.C. Bailin and S. Henderson. An application of machine learning to the organization ofinstitutional
  272. software repositories. To appear in Telematics and Informatics, September 1993.
  273.  
  274.  
  275. S.C. Bailin,  F. Paterra,  W. Truszkowski,  and S. Henderson.  Model- based reasoning for system
  276. and software engineering. To appear in Telematics and Informatics, September 1993.
  277.  
  278.  
  279. Esteva, J.C. and Reynolds, R.G., 1990. Learning to recognize reusable software by induction. Pro-
  280. ceedings of the 2nd International Conference on Software Engineering and Knowledge Engineering,
  281. Skokie, IL. June 1990.
  282.  
  283.  
  284. Harandi,  M. and Lee,  H-Y. Acquiring software design schemas:  a machine learning perspective.
  285. Proceedings of the 6th Annual Knowledge-Based Software Engineering Conference, IEEE Computer
  286. Society Press. 1991.
  287.  
  288.  
  289. Harel, D., 1992. Biting the silver bullet: Toward a brighter future for system development.  IEEE
  290. Computer, January 1992.
  291.  
  292.  
  293. Lee, K. et.  al., 1990.  An OOD paradigm for flight simulators, 2nd edition. Technical Report of the
  294. Software Engineering Institute, Carnegie Mellon University, Pittsburgh.
  295.  
  296.  
  297. O'Reilly, U.M. and Oppacher,F. Learning new features and heuristics for matching and using cases.
  298. Proceedings of the Fourth Florida Artificial Intelligence Research Symposium, Florida AI Research
  299. Society. April 1991.
  300.  
  301.  
  302. Parnas, D., Asmis, G., andMadey, J., 1990. Assesment of safety-critical software. Technical Report
  303. 90-295, ISSN 0836-0227.  Telecommunications Research Institute of Ontario.  Queens University,
  304. Kingston, Ontario.
  305.  
  306.  
  307. Reynolds, R.G. and Maletic, J.I., 1991. Operationalizing software reuse as a problem in machine
  308. learning. Proceedings of the Fourth Florida Artificial Intelligence Research Symposium, Florida AI
  309.  
  310.  
  311.  
  312.                                                          Bailin- 5
  313.  
  314.  
  315. Research Society. April 1991.
  316.  
  317.  
  318. Willis, C.P. and Paddon, D.J. Combining explanation-based learning and Knuth-Bendix comple-
  319. tion for equational reasoning.  Proceedings of the Fourth Florida Artificial Intelligence Research
  320. Symposium, Florida AI Research Society. April 1991.
  321.  
  322.  
  323. Wu, F.Y. and Leong, S. A syntax directed approach for learning software translation knowledge.
  324. Proceedings of the Fourth Florida Artificial Intelligence Research Symposium, Florida AI Research
  325. Society. April 1991.
  326.  
  327.  
  328.  
  329.                                                          Bailin- 6
  330.