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 / bhansali.ascii < prev    next >
Text File  |  1993-10-19  |  13KB  |  267 lines

  1.  
  2.  
  3.  
  4.  
  5. Reusing  Software  Design  :  A  Generic  Architecture-based  Approach
  6.  
  7.  
  8.  
  9.                                                    Sanjay Bhansali
  10.  
  11.  
  12.  
  13.                           Knowledge Systems Laboratory, Stanford University
  14.  
  15.                            701 Welch Road, Building C, Palo Alto, CA 94304
  16.  
  17.                                       Tel: (512)-331-3541,(415)-723-8387
  18.  
  19.                   Email: bhansali@austin.slcs.slb.com, bhansali@hpp.stanford.edu
  20.  
  21.  
  22.  
  23.                                                         Abstract
  24.  
  25.  
  26.           We are attempting to build a framework and computational environment to assist software
  27.       designers in designing software systems efficiently and reliably.  Our approach is based on ab-
  28.       stracting the design as well as the process involved in designing a software system and reusing
  29.       them to design new systems. The emphasis is on building an environment in which the system
  30.       acts as an assistant that delivers the relevant knowledgeto a designer so that he or she may
  31.       make informed decisions. Our work may be characterized as a semi-formal approach that aims
  32.       to create a system that would be usable by software designers who are not well-versed with
  33.       formal methods.
  34.  
  35.  
  36.       Keywords: Reuse, software design, domain analysis, software process.
  37.  
  38.  
  39.       Workshop Goals:  Networking and exchanging ideas with other researchers in similar areas,
  40.       identifying problems of practical as well as theoretical interest in software reuse.
  41.  
  42.  
  43.       Working Groups: Domain analysis/engineering, To ols andenvironments, Reuse process mod-
  44.       els.
  45.  
  46.  
  47.  
  48.                                                        Bhansali- 1
  49.  
  50.  
  51. 1      Background
  52.  
  53.  
  54.  
  55. I am interested in the application of novel techniques and to ols for improving the efficiency and
  56. quality  of  software  development  through  reuse.   My earlier  research  in  this  area  was  concerned
  57. with issues of reuse in the context of program synthesis.  Specifically, I investigated how a program
  58. synthesizing system could be made more efficient by reusing the derivation history of analogous
  59. programs  that  had  been  synthesized  earlier[1].  Subequently, I  have  b ecome interested  in  issues
  60. involved in the design of large software systems.  I am currently co-leading the KASE (Knowledge
  61. Assisted Software Engineering) project at the Knowledge Systems Lab oratory, Stanford which is
  62. engaged in building a knowledge-based environment that can assist software designers to design
  63. systems by reusing generic software designs represented as generic architectures [2, 3 ].
  64.  
  65.  
  66. I am also interested in software processes and issues concerning the reuse of processes in a process-
  67. driven environment. I have been involved (in collaboration with Pankaj Garg at Hewlett-Packard
  68. Laboratory) in the design and implementation of a system that can support the automated gener-
  69. ation of process fragments by generalizing a sequence of useractivities in a work session [4 ].
  70.  
  71.  
  72.  
  73. 2      Position
  74.  
  75.  
  76.  
  77. One of the most effective principle for reuse is the principle of abstraction.  Abstraction consists
  78. of extracting the inherent, essential aspects of an artifact,while hiding its irrelevant or incidental
  79. properties. It fosters reuse by providing a class of artifacts that can be instantiated or customized
  80. to  produce  several  different  artifact  instances  meeting different  requirements.   The  abstraction
  81. principle can also be used to automate the construction of artifacts that would normally require a
  82. creative process. Examples of successful application of this principle can be found in commercially
  83. available  expert  system  shells,  application  generators,  and  more  recently  in  algorithm  synthesis
  84. [5] in the KIDS system which contains abstractions of several different classes of algorithms in the
  85. form of algorithm theories which can be (semi-) automatically instantiated to synthesize specialized
  86. algorithms for different problem instances.
  87.  
  88.  
  89. The goal of the KASE project is to support software designers in designing software systems more
  90. efficiently  and  more  reliably.   We  believe  that  designing  software  systems  is  a  creative  and  ill-
  91. understood  process  that  is  performed  by  a  small  group  of  designers.  However, the  process  and
  92. the final design is typically not well documentedleading to po or reuseand exp ensive maintenance.
  93. Our  approach  to  this  problem  is  based  on  abstracting b oth  the software  system  design  and  the
  94. design process. In brief, our approach consists of (1) identifying useful classes of softwaresystems
  95. and  the  problems  they  solve, (2)  abstracting  the  design  of  the  system  as  a  generic  architecture
  96. for that class of problems, (3) abstracting the design process in the form of rules and procedures
  97. for  customizing  the  generic  architecture  based  on  specific  problem  descriptions,  (4)  providing  a
  98. computational environment that enables designers to construct specific systems semi-automatically
  99. by customizing the generic architecture.
  100.  
  101.  
  102. A guiding theme in our research is to provide a set of software tools that support the way humans
  103. design. The objective is to produce a mixed-initiative system in which the design task is divided be-
  104. tween a human designer and the system. Typically, KASE provides design alternatives and default
  105. suggestions for architectural parameters, explanations for its suggestions, dependency maintenance
  106. between different design decisions, and consistency checking. The human designers determines the
  107. order  in  which  the  various  design actions  are  initiated,  the  final  choice  for  each  design  decision
  108.  
  109.  
  110.  
  111.                                                         Bhansali- 2
  112.  
  113.  
  114.  
  115.  
  116.  
  117.                                      Figure 1: Overview of the KASE system
  118.  
  119.  
  120.  
  121.                  Figure 2: Process model for synthesizing software systems using KASE.
  122.  
  123.  
  124.  
  125. (which may or may not be based on the suggestionsoffered by KASE), and steps to be taken when
  126. a design inconsistency is reported. In essence, KASE acts as an assistant that delivers the relevant
  127. knowledge in the appropriate context to a designerso that he or she can make informed decisions
  128. and helps the designer in detecting errors early in the design process.
  129.  
  130.  
  131. Figure   1  shows  an  overview  of  the  KASE  system.  The  shadowed  boxes  represent  knowledge
  132. components that are part of KASE. Figure 2 illustrates the process of synthesizing systems using
  133. KASE.
  134.  
  135.  
  136. A designer initiates the design process by first selecting ageneric architecture from a library based
  137. on the problem  class for his particular problem andthe desired solution  features.  Each problem
  138. class has an associated specification in the form of a problem-classschema as well as a problem-class
  139. model. An individual problem instance is specified by instantiating the problem class schema; the
  140. problem class model contains the vocabulary of terms that help in the instantiation.  Associated
  141. with pairs of generic architectures and problem classes is customization know ledge which contains
  142. knowledge for customizing the generic architectureand is the basis for KASE's intelligent support.
  143. Finally, the constraint checker is used to check for the consistency of the design with respect to
  144. certain architecture-specific constraints.
  145.  
  146.  
  147.  
  148.                                                         Bhansali- 3
  149.  
  150.  
  151. Our approach may be characterized as a semi-formalapproach.  It is not completely formal where
  152. the semantics of a problem specification and architectural descriptions are contained entirely within
  153. a set of mathematical equations. Nor is it completely informal where the name of a symbol carries
  154. all the information for a human is in, e.g. systems like IBIS [6].  Our approach does use keywords
  155. and assumes the availabilityof an accepted domain-specific ontology which is not formally defined.
  156. However, there are explicitly represented constraints and rules that provide some semantics to the
  157. symbols.  We were motivated in adopting this approach because we wanted to create a practical
  158. system that could be used by software designers not well-versed in formal, mathematical notation;
  159. and, at the same time we wanted a representation that is interpretable by a machine so that it
  160. could provide intelligent assistance todesigners.
  161.  
  162.  
  163.  
  164. 3      Comparison
  165.  
  166.  
  167.  
  168. KASE shares the general goal of the Domain Specific Software Architecture (DSSA) project spon-
  169. sored by DARPAwhich is to demonstrate the benefits of synthesizing software systems by reusing
  170. domain specific architectures. We have demonstrated the applicability of our approach in two dif-
  171. ferent domains [2, 3 ]: a tracking domain anda graphical interface domain. In each of these domains
  172. a common generic architecture and customization knowledge was used to generate specific designs
  173. for different problem instances.
  174.  
  175.  
  176. The  LEAP project  at  Lockheed  [7 ]  and  the  ROSE-2  system  [8 ]  represent  two  other  works  that
  177. aim to synthesize systems by reusing high-level design abstractions.  In LEAP there is a greater
  178. emphasis on code generation from a high level specification whereas in KASE and ROSE-2 there
  179. is a greater emphasis on high-level design issues and their representation.
  180.  
  181.  
  182. Other related work on software architectures includes the work by researchers at Carnegie Mellon
  183. University  (e.g.  [9,  10]).  Their  work  includes  the  identification  of  commonly  used  architectural
  184. paradigms,  the  relationship  between  various  architectural  paradigms  and  problem  classes,  and
  185. analysis of trade-offs involved in choosing one design over another /citeSha91. Lane [10 ] describes
  186. a user-interface software architecture and design rules for building specific user interface systems.
  187. The approach consists of creating a space of design alternatives and formulating rules that indicate
  188. good and bad design choices based on problem requirements - which is quite similar to the approach
  189. in KASE. However, it seems that there is less support for semi-automated or automated conversion
  190. of the resultant design into code.
  191.  
  192.  
  193. There is some similarity between our approach of synthesizing software systems and parameterized
  194. programming. In parameterized programming, a generic program represents a parameterized alge-
  195. braic theory which can be instantiated by using aview (theory morphism) that binds actual and
  196. formal parameters. from this perspective, KASE can be thought of as providing a library of highly
  197. parameterized programs (the generic system design) as well asto ols to assist a user in instantiating
  198. them based on the requirements of a particular application.
  199.  
  200.  
  201.  
  202. References
  203.  
  204.  
  205.  
  206.   [1] S.  Bhansali  and  M.  T.  Harandi, "Synthesis  of  unix  programs  using  derivational  analogy,"
  207.       Machine Learning, vol. 10, no. 2,pp. 7-55, 1993.
  208.  
  209.  
  210.  
  211.                                                         Bhansali- 4
  212.  
  213.  
  214.   [2] S. Bhansali and H. P. Nii, "Software design by reusing architectures," in Proceedings of the
  215.       7th Annual Knowledge-Based Software Engineering Conference, (McLean, Virginia), 1992.
  216.  
  217.  
  218.   [3] S. Bhansali, "Architecture-driven reuse of code in kase," in Proceedings of the 5th Interna-
  219.       tional Conference on Software Engineering and Knowledge Engineering, (San Francisco Bay,
  220.       CA), 1993.
  221.  
  222.  
  223.   [4] P.  Garg  and  S.  Bhansali, "Process  programming  by  hindsight," in  Proceedings  of  the  14th
  224.       International conference on software engineering, (Melbourne, Australia), May 1992.
  225.  
  226.  
  227.   [5] D. R. Smith, "KIDS: a semiautomatic program developmentsystem," IEEE Transactions on
  228.       Software Engineering, vol. 16, pp.1024-1043, September 1990.
  229.  
  230.  
  231.   [6] J. Conklin and M. Begeman, "gibis: a tool for all reasons," Journal of the American Society
  232.       for Information Science, vol. 40, pp. 200-213,1989.
  233.  
  234.  
  235.   [7] H. Graves, "Lockheed environment for automatic programming," in 6th Annual Know ledge-
  236.       Based Software Engineering Conference, (Syracus, NY), pp. 78-89, 1991.
  237.  
  238.  
  239.   [8] M. Lubars, "The ROSE-2 Strategies for Supporting High-Level Software Design Reuse," Tech.
  240.       Rep. STP-303-90, Microelectronics and Computer Technology Corporation, 1990.
  241.  
  242.  
  243.   [9] M. Shaw, "Heterogenous design idioms forsoftware architecture," in Fifth International Work-
  244.       shop on Software Specification and Design, pp. 143-146, 1991.
  245.  
  246.  
  247. [10]  T. G. Lane, "A design space and design rules for user interface software architectures," Tech.
  248.       Rep. CMU-CS-90-176, Carnegie Mellon University, 1990.
  249.  
  250.  
  251.  
  252. 4      Biography
  253.  
  254.  
  255.  
  256. Sanjay Bhansali is a researchscientist in the computer science department at Stanford University.
  257. He  has  been  co-leading  the  Knowledge  Assisted  Software  Engineering  (KASE)  project  with  H.
  258. Penny Nii at the Knowledge Systems Laboratory at Stanford for the past 2 years. The goal of the
  259. KASE project is to build a knowledge-based software design tool that can canact as an assistant
  260. to a human designer. Sanjay obtained his PhD in Computer Science at the University of Illinois,
  261. Urbana-Champaign in 1991 and his Bachelor of Technology in Computer Science from the Indian
  262. Institute of Technology, Delhi in 1986.
  263.  
  264.  
  265.  
  266.                                                         Bhansali- 5
  267.