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 / devanbu.ascii < prev    next >
Text File  |  1993-10-19  |  15KB  |  288 lines
  1.  
  2.  
  3.  
  4.  
  5.                Research  Issues  with  Application  Generators
  6.  
  7.  
  8.  
  9.                                        Premkumar T. Devanbu
  10.  
  11.                           Software and Systems Research Laboratory,
  12.  
  13.                                        AT&T Bell Laboratories
  14.  
  15.                       2b417, 600 Mountain Ave, Murray Hill, NJ 07974
  16.  
  17.                                            Tel:  (908) 582-2062
  18.  
  19.                                    Email: prem@research.att.com
  20.  
  21.  
  22.  
  23.                                                   Abstract
  24.  
  25.  
  26.     Application generators, which generate domain-specific systems from specifications formu-
  27. lated in a special-purpose high-level formal language, can achieve very high levels of software
  28. reuse and impressive gains in productivity. Several tools available in the market have greatly
  29. simplified the construction of application generators. There still are, however, significant diffi-
  30. culties in the practical use of application generators. I'm particularly interested in the pursuit
  31. of methodological and technical solutions to the following problems: designing domain-tailored
  32. specification languages, re-engineering domain specific frameworks out of existing systems, and
  33. assistance for debugging specifications.
  34.  
  35.  
  36. Keywords: domain analysis, application generators, reverse engineering
  37.  
  38.  
  39. Workshop Goals: Keep in touch with the state of the art in reuse.
  40.  
  41.  
  42. Working Groups:  Domain analysis/engineering, Design guidelines for reuse - general, Ada,
  43. and/or C++, Reuse and OO methods, Reuse and formal methods, Useful and collectible metrics
  44.  
  45.  
  46.  
  47.                                                  Devanbu- 1
  48.  
  49.  
  50. 1      Background
  51.  
  52.  
  53.  
  54. An application generator (AG) produces applications from high level specifications (See Figure 1.)
  55. The specification is written in a language that is likely to have powerful, compact, domain-specific
  56. constructs; the  application  generator  will  lex  and  parse  this  specification  into  an  internal  parse
  57. tree representation; this parse tree will then be checked for semantic correctness, consistency etc;
  58. from this validated parse tree representation of the specification, code is generated; this code can
  59. be  linked  up  with  an  architecture, library  and/or  run  time  environment  (which we  collectively
  60. call  a  domain  specific  framework  (DSF))  to  implement  the  application.   Application  generators
  61. have become increasingly popular in industry, particularly with the development of tools to build
  62. application generators such as MetaTo ol [1 ],  centaur [2 ].  Commercially available tools such as
  63. MetaTool provide facilities for generating parsers, built-in data structures that can represent parse
  64. trees, and various traversal operators for traversing the parse tree. MetaTool provides a "template
  65. driven" approach to code generation that is particularly useful for co de generation.  Newer tools
  66. such as centaur provide (in addition to parser generators) semantic checkers that are drivenby
  67. formal specifications.
  68.  
  69.  
  70. Application  generators  improve  productivity  in several  ways.   First, because  of  the  power  of  a
  71. well-designed  specification  language, the  size  of  a  high-level  specification  to  implement  a  given
  72. application is likely to much shorter than a corresponding implementation in a conventional pro-
  73. gramming language.  Secondly,  a high level of reuse can be achieved, more or less automatically;
  74. the applications re-use all of the domain-specific framework. In a recent survey paper [3], Bigger-
  75. staff cites some impressive gains in software productivity achieved through the use of application
  76. generators.
  77.  
  78.  
  79. There are hower, some significant technical issues with application generators, which form the main
  80. concern of my research and this position paper.
  81.  
  82.  
  83.  
  84.                                    Figure 1:  A Typical Application Generator
  85.  
  86.  
  87.  
  88. 2      Position
  89.  
  90.  
  91.  
  92. There are several issues that arise in the practical deployment of AG technology:
  93.  
  94.  
  95.  
  96.                                                         Devanbu- 2
  97.  
  98.  
  99.     fflDomain-Tailored Specification Languages How does one design a specification language for a
  100.        given application domain ?
  101.  
  102.  
  103.     fflScavenging the Domain Specific framework Can an existing application, system or library be
  104.        adapted to serve as the framework for the application generator ?
  105.  
  106.  
  107.     fflDeveloping/Maintaining  Specifications  How  does  one  ensure  that  a  specification  is  correct
  108.        and/or consistent ? If there are errors/bugs in the application, how can they be identified in
  109.        terms of the specification language ?
  110.  
  111.  
  112.  
  113. 2.1     Specification Languages
  114.  
  115.  
  116.  
  117. The  most  important  and  difficult  part  of  creating  an  AG  is  the  design  of  a  suitable  high level
  118. specification language. Little or nothing is known about how to go about creating such a language.
  119.  
  120.  
  121. Clearly, most applications in an application domain have a lot in common; this common part is
  122. of little concern to the application creator; thus the specification language doesn't need elements
  123. to  describe  this  part.  The  purpose  of  the  specification  of  an  application  is  to  describe  what  is
  124. different  and  special  about  a  particular  application.  The  design  of  the  language  should  include
  125. features necessary to characterize the variation in the domain.  Consider the case of LALR parser
  126. generators,  the  function,  or  algorithm  is  the  same  for  all  applications  (parsers);  the  difference
  127. between applications is solely the grammar that is being parsed;  hence the specification language
  128. for yacc [4] looks a lot like a context free grammar specification. Thus, the type of variation in the
  129. domain should drive the design of the specification language.
  130.  
  131.  
  132. I am interested in developing an methodologicalapproach to designing a specification language; a
  133. first step, we are examining numerous examples of successful application generators to determine
  134. broad classes of specification languages, and the linguistic features particular to each class.  We
  135. hope to develop a characterization of the relationship between the type of variation in the domain
  136. of application, and the type of the applicable specification language and its features.  With this
  137. characterization, we hope to develop a prescriptive methodology that would enable a domain analyst
  138. to use a more systematic approach to design a specification language fora given application domain.
  139.  
  140.  
  141.  
  142. 2.2     Creating a domain specific framework
  143.  
  144.  
  145.  
  146. Tools such as MetaTool, centaur, etc, have simplified parsing, semantic analysis and even code
  147. generation. However, one element of the application generator, the domain specific framework,must
  148. still be built the old fashioned way.  This framework must capture all the most general aspects of
  149. the domain in a library and/or architecture.
  150.  
  151.  
  152. This framework must contain much of the domain software functionality required by the applications
  153. that the AG produces.  For example,  in a process control domain the domain specific framework
  154. must  contain  all  the  necessary  drivers  for  the  various  sensors,  actuators,  etc; also,  the  scientific
  155. subroutine libraries for the necessary physical/chemical computations.  genoa [5] is an application
  156. generator that produces source code analyzers. Source code analyzers created by genoa can extract
  157. useful information from source code. For this system, we needed a framework that lexes, parsed,
  158. and semantically analyzed source program code and builds an annotated parse tree, which can be
  159. traversed and analyzed.
  160.  
  161.  
  162.  
  163.                                                         Devanbu- 3
  164.  
  165.  
  166. Generally speaking, a framework for an application generator would have to be implemented from
  167. scratch.  However,  an existing  application  may  contain  within  it  the  seeds  of  a  domain  specific
  168. framework. For example, an existing control system for a thermostat may contain driver software
  169. for  various  types  of  sensors  and  actuators, day/night  timing  event  generators  etc.   Likewise,  in
  170. the language tool domain (relevant to genoa) an existing compiler may contain a lexer, parser,
  171. semantic analyzer etc. In such cases, it may be possible to scavenge the domain specific framework
  172. out of the existing system for more general use.
  173.  
  174.  
  175. We  have  used  this  approach  successfully  in  the  genoa  system.   genoa  is  a  portable  analyzer
  176. generator, that  can  be  attached  to  any  existing  lexer/parser/analyzer  for  a  given  programming
  177. language; this attachment is performed by writing a formal specification in a companion system,
  178. called genii. A genii specification describes the linguistic elements of the language to be analyzed
  179. (Expressions, Declarations, Statements etc) and their implementation in the specific front end (data
  180. structures, operations, etc). Using this specification, genii basically places a standard "wrapper"
  181. around the existing implementation. This "wrapped" implementation, and associated (generated)
  182. tables are used by genoa as the domain specific framework for generated application.  In this way,
  183. we have created an analyzer generator for C++, called gen++, based on the Cfront compiler. Thus
  184. in the case of genoa, the "framework scavenging" process has been formalized and automated to
  185. some  extent.  Because  of  the  complexity  of  the  C++  language, and  the  attendent  difficulty  of
  186. parsing it, this approach is particularly advantageous.  In fact, we believe that gen++ is the first
  187. and only available1 tool of this kind for C++.
  188.  
  189.  
  190. We believe that this approach to extracting a domain specific framework out of an existing ap-
  191. plication could be viable if the existing application is implemented ina mo dularfashion,  and the
  192. "generic elements" within it are of high quality, and if the cost of implementing a DSF from scratch
  193. are quite high.  If a well understood, formal (algebraic) model of the domain specific framework
  194. is  available, this  can  be  used  to  automate  the  frame  work  scavenging  process,  as  in  the  case  of
  195. genoa/genii.
  196.  
  197.  
  198.  
  199. 2.3     Debugging High Level Specifications
  200.  
  201.  
  202.  
  203. A specification for an application is a program like any other, and is consequently subject to various
  204. types of error.  Some of these could perhaps be identified and corrected by inspection.  However,
  205. particularly  when  specifications  get  large, a  debugger  of  some  sort  would  be  needed.  However,
  206. application generators typically don't come with any debugging support.
  207.  
  208.  
  209. The  current  approach  to  debugging  specifications  written  in  domain-specific  languages  is  quite
  210. unpleasant:  the  code  generated  by  the  AG (often  in  a  language  such  as  C) forms  the  basis  of
  211. the  debugging  efforts.  A conventional  symbolic  debugger  such  as  sdb  or  gdb  is used  to  debug
  212. the generated application; the user has to manually perform the mapping between thegenerated
  213. C source code displayed by the symbolic debugger and the original specification.  This certainly
  214. involves mapping from a particular linein the generated source code to a particular line (or part
  215. there of) in the original specification.  In addition, the data models for the specification language
  216. and C are probably quite different; the specification language may provide dataabstractions and
  217. operations that are suitable for the application domain, but are quitedifferent the data types of C.
  218. The user debugging at the C level has to learn how the AG implements these data abstractions in
  219. C. To complicate matters, AG may also "mangle" the identifiers used in the specification language
  220. in  various  ways  to  avoid  name  conflicts  and/or  encode  different  types  of  information; this  is  an
  221. ___________________________________________________1
  222.      Abeta version is available free of charge for academic/non profit use. Contactthe author for more information.
  223.  
  224.  
  225.  
  226.                                                         Devanbu- 4
  227.  
  228.  
  229. additional burden.  The drudgery of this type of debugging represents an important challenge for
  230. AG technology.
  231.  
  232.  
  233. One solution to this problem is to implement a customized domain-sp ecific debugger, from scratch,
  234. specifically designed for the particular specification language; such a debugger would be congnizant
  235. of  the  syntax  and  semantics  of  the  specification  language.   The  user  would  be  able  to debug  a
  236. specification with the application in terms of its particular execution and data mo del. The cost
  237. of building just a debugger, however, makes this approach suitable only for AG's that have wide
  238. market penetration, and are used to build very large and complex applications.
  239.  
  240.  
  241. I am interested in developing systematic methods of adapting existingsymbolic debuggers such as
  242. gdb  to  create  domain-specific  debuggers.  Tools  such  as  gdb  have embedded  in  them  many  of
  243. the basic functionality of debugging: user interface,  readingsymbol tables from object files and
  244. executables, operating in a "master/slave" configuration with another process, reading/modifying/-
  245. displaying  data, setting  up  various  types  of  breakpoints  etc.  The  research  challenge  here  is  to
  246. develop tools and techniques for the systematic adaptation ofexisting symbolic debuggers to create
  247. debuggers for particular domain specification languages.
  248.  
  249.  
  250.  
  251. References
  252.  
  253.  
  254.  
  255. [1]  J. C. Cleaveland and R. Tatem, "metatool specification driven tool, System Overview," Tech.
  256.      Rep. 193010-211, AT&T Bell Laboratories, North Andover, MA, 1990.
  257.  
  258.  
  259. [2]  P. Borras, D. Clement, T. Despeyroux, J. Incerpi, G. Kahn, B. Lang, and V. Pasual, "centaur:
  260.      TheSystem," in  Proceedings of the SIGSOFT/SIGPLAN Software EngineeringSymposium on
  261.      Practical Software Development Environments, 1988.
  262.  
  263.  
  264. [3]  T. Biggerstaff,  "An Assessment and Analysis of Software Reuse," in Advances in Computers,
  265.      Vol 34, Academic Press, 1992.
  266.  
  267.  
  268. [4]  A. Aho, R. Sethi, and J. Ullman, Principles of Compiler Design. Addison-Wesley, 1991.
  269.  
  270.  
  271. [5]  P.  Devanbu,  "genoa/genii  -  a  customizable,  language-  and  front-end-  independentcode  an-
  272.      alyzer," in Proceedings  of  the  Fourteenth  International  Conference  on  Software  Engineering,
  273.      1992.
  274.  
  275.  
  276.  
  277. 3      Biography
  278.  
  279.  
  280.  
  281. Premkumar  T.  Devanbu  is  a  member  of  the  Software  and  Systems  Research  Laboratory  at
  282. AT&T Bell Laboratories in Murray Hill, New Jersey. His research interests include software devel-
  283. opment tools and methodologies, application generators, formal methods, and metrics.
  284.  
  285.  
  286.  
  287.                                                         Devanbu- 5
  288.