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 / griss.ascii < prev    next >
Text File  |  1993-10-19  |  16KB  |  403 lines
  1.  
  2.  
  3.  
  4.  
  5. Towards  tools  and  languages  for  hybrid  domain-sp ecific  kits
  6.  
  7.  
  8.  
  9.                                              Martin L. Griss
  10.  
  11.  
  12.  
  13.              Software Reuse Department, Software Technology Laboratory
  14.  
  15.                                    Hewlett-Packard Laboratories
  16.  
  17.                                           1501 Page Mill Road
  18.  
  19.                                           Palo Alto, CA94301
  20.  
  21.                                            Tel:  (415) 857-8715
  22.  
  23.                                        Email: griss@hpl.hp.com
  24.  
  25.  
  26.  
  27.                                                   Abstract
  28.  
  29.  
  30.     As part of HP Laboratories research into a systematic process for domain-specific reuse, we
  31. are exploring the notion of Domain-Specific Kits.  Kits are comprised of compatible, domain-
  32. specific components, frameworks and glue languages, supported bya variety of technologies and
  33. tools, such as domain-specific languages, builders, generators and domain-tailored environments.
  34. We are particularly interested in hybrid kits, which combine both generative and compositional
  35. reuse, and domain-specific language tools to support the generative part. This paper describes
  36. our initial thinking and investigations.
  37.  
  38.  
  39. Keywords: Reuse, kits, builders, generators, domain-specific languages, hybrid reuse.
  40.  
  41.  
  42. Workshop Goals: Learn more about domain analysis/engineering and generative reuse meth-
  43. ods; share and discuss information on our research program.
  44.  
  45.  
  46. Working Groups: Kits, generative reuse, domain engineering
  47.  
  48.  
  49.  
  50.                                                    Griss- 1
  51.  
  52.  
  53. 1      Background
  54.  
  55.  
  56.  
  57. I have been involved with HPsoftware engineering products and processes since 1985, and with
  58. HP reuse  efforts  since  1989.  In  position  papers  at  WISR'92  (Palo  Alto)  and  IWSR'93  (Lucca),
  59. I described our multi-disciplinary reuse research program started at HP Laboratories in 1992[1].
  60. This program complements HP's Corporate Reuse Program, described at IWSR'91, WISR'92 and
  61. IWSR'93. Key to our research program is an integrated approach to technology, method, process
  62. and  organization  issues.  Our  program  has  two  major  themes:  domain-specific-kits  and  flexible
  63. software factories.  The domain-specific kit researchfo cuses onthe technologies and methods for
  64. the production, use and support of kits, while the flexible software factory work concentrates on
  65. the processes, organization design, and software engineeringand communication infrastructures for
  66. kit-based software development.
  67.  
  68.  
  69. At WISR'92, the Domain Analysis Working Group[2 ] explored the different styles of domain anal-
  70. ysis  appropriate  to  either  generative  or  compositional  reuse.  Purely  generative  approaches  (e.g.
  71. Draco[3]) were deemed too complex for most cases, even though the payoff is high.  Instead, one
  72. should try hybrid reuse, combining both generative and comp ositional approaches.  However,  cur-
  73. rent DA methods do not facilitate systematic design for hybrid reuse, or tradeoffs as to which route
  74. to take for which part of a complete application family.
  75.  
  76.  
  77. At IWSR'93, the tutorial by Frakes, Batory and Devanbu on application generators did not re-
  78. ally address these issues, nor how to design appropriate domain-specific languages for the level of
  79. generator technology chosen. Instead, it focused primarily on a few commercially available imple-
  80. mentation techniques and tools. There were some useful experience reports, but no guidelines for
  81. hybrid reuse tradeoffs[4, 5 ].
  82.  
  83.  
  84.  
  85. 2      Position
  86.  
  87.  
  88.  
  89. It  is  my  belief  that  there  are  several  important  issues  involved  here,  and  that  they  should  be
  90. addressed systematically. We need:
  91.  
  92.  
  93.  
  94.     fflmethods and supporting technology to design and implement hybrid kits
  95.  
  96.  
  97.     fflguidelines and examples of a variety of simple and more complex ways of using domain-specific
  98.        languages and generators within hybrid kits
  99.  
  100.  
  101.     ffltechniques and mechanisms to ensure openness and extensibility of the kit, and to smooth
  102.        the boundary between generative and compositional parts
  103.  
  104.  
  105.     fflmethods and common mechanisms to produce frameworks which will ensure that indepen-
  106.        dently developed can interoperate.
  107.  
  108.  
  109.  
  110. This position paper will summarize some of our work on kits, hybrid reuse, domain-specific lan-
  111. guages and related issues.
  112.  
  113.  
  114.  
  115.                                                           Griss- 2
  116.  
  117.  
  118. 3      Domain-Specific Kits
  119.  
  120.  
  121.  
  122. Our  goal  is  to  develop  for  HP divisions  the  methods  and  technologies  to  dramatically  improve
  123. application construction tasks using reuse.  Most HP reuse situations involve the construction of
  124. families  of  closely  related  applications.  To  encourage  the  coherent  design,  implementation  and
  125. packaging of a variety of comaptible domain-specific workproducts, we first identify and structure
  126. the  domain  ("domain  engineering")  and  then  use  new  methods  ("kit  engineering")  to  build  a
  127. "domain-specific kit" consisting of domain-specific components,supp orting infrastructure and tools.
  128. The kit is then used to build one or more applications.
  129.  
  130.  
  131. A typical "hybrid domain-specific kit" will contain (most of ):
  132.  
  133.  
  134.  
  135.     fflA  set  of  components,  which  are  well  documented,  tested  and packaged  sets  of  compatible
  136.        software workproducts:  C functions, C++ objects, generator templates,test-files, software-
  137.        bus connected mega-components, etc.
  138.  
  139.  
  140.     fflA  framework  within  which  compatible  components  can  be  combined  with  hand-written  or
  141.        generated glue-language, and the addition of non-kit workproducts. The framework provides
  142.        common services, key mechanisms and core functionality, ensures appropriate interoperability
  143.        and customizability, and establishes conventions and mechanisms to add new compoents.
  144.  
  145.  
  146.     fflA glue language to combine components and add needed functionality.  This could be general
  147.        purpose, a flexible scripting language, or highly domain-specific.
  148.  
  149.  
  150.     fflExemplary generic applications are pre-packaged, ready-to-run, standard applications built
  151.        with  the  kit,  with  interconnected  framework,  components  and  glue.  A complete  applica-
  152.        tion is evolved or customized using built-in customization methods and adding or replacing
  153.        components, supporting a prototyping development cycle[6, 7 ].
  154.  
  155.  
  156.     fflA construction environment provides tools such as component browser, glue language editor,
  157.        application builder and generator. Debugging, testing, and construction step recording tools
  158.        aid in quick assembly and modification.  Using a combination of techniques, one can start
  159.        from components, generic applications or from previously built user applications.
  160.  
  161.  
  162.     fflAn execution environment provides support for customizing and running the application, with
  163.        debugger, interpreter, graphical display and monitoring, etc.
  164.  
  165.  
  166.  
  167. 4      Theory  and  Practice  of Domain-Sp ecific Kits
  168.  
  169.  
  170.  
  171. We  are  trying  to  produce  a  theory  and  practice  of  domain-specific  kits,  abstracting  ideas  from
  172. division studies and experiences in developing and using several domain-specific kits.  A complete
  173. methodology should include:
  174.  
  175.  
  176.  
  177.     fflA  philosophy  of  how  and  when  to  use  domain-specific  kits, and  guidelines  on  how  to  bal-
  178.        ance the cost and benefits between the development of frameworks, reusable domain-sp ecific
  179.        components and languages, and the use of traditional programming.
  180.  
  181.  
  182.     fflA  taxonomy  or  catalog  of  kit  models,  styles,  and  implementation  techniques.  For  exam-
  183.        ple, kits may be "closed and complete", or "open and extensible", providing a some needed
  184.  
  185.  
  186.                                                           Griss- 3
  187.  
  188.  
  189.        workproducts, and instructions and mechanisms to create, declare and register new compo-
  190.        nents.
  191.  
  192.  
  193.     fflProcesses and methods to be used by kit developers and users, workproduct supporters and
  194.        managers, such as "domain engineering," "kit engineering,""framework design," "component
  195.        management," "generator design and implementation,"  "using a kit,"  "augmenting a kit,"
  196.        etc.
  197.  
  198.  
  199.     fflA set of (customizable) tools and core technology that can be used to define and develop kits,
  200.        such as domain analysis tools, language and generator kits, library and browsing tools, glue
  201.        language interpreters and compilers, software-bus services, user-programming and customiz-
  202.        ing language kits, etc.
  203.  
  204.  
  205.     fflA set of case studies which illustrate the principles, the practice and the tradeoffs. It would
  206.        be useful to know language sizes, number of components, implementation costs, pro ductivity
  207.        and quality benefits, etc.
  208.  
  209.  
  210.  
  211. 4.1     Domain-specific languages for hybrid kits
  212.  
  213.  
  214.  
  215. Language  technology  can  be  used  in  several  ways  to  include  domain-specificity  into  a  hybrid
  216. kit for different audiences and situation. There are several opportunies for domain-specific"little
  217. languages"[8], such as:
  218.  
  219.  
  220.  
  221.     fflComponent development and generation (from templates or rules)
  222.  
  223.  
  224.     fflParameter generation for parameterized components
  225.  
  226.  
  227.     fflGlue/config language for component interconnection
  228.  
  229.  
  230.     fflData file/table creation
  231.  
  232.  
  233.     fflLoader/builder scripts
  234.  
  235.  
  236.     fflTemplates/declarations for registering new components in an open kit
  237.  
  238.  
  239.     fflEnd-user programming/customization
  240.  
  241.  
  242.  
  243. The following list illustrates some implementationchoices:
  244.  
  245.  
  246.  
  247.     fflConventional language + domain-specific library of code
  248.  
  249.        Using Basic or C, the domain-specificity is offered as a library of parts.
  250.  
  251.  
  252.     fflOb ject-oriented language + domain-specific class library
  253.  
  254.        C++ and Smalltalk make it easier to create frameworks and API's that shape components
  255.        by inheritance and polymorphism.
  256.  
  257.  
  258.     fflExtensible language or preprocessor + domain-specific library
  259.  
  260.        Using  macros  or  syntax  extension  capabilities  in  LISP  and  TCL,  or  using  CPP,  AWK  or
  261.        PERL, Yacc, or STAGE[9] as preprocessor one adds concise, domain-oriented expressions to
  262.        a standard language.  These simplify parameter generation, consistent use of procedures and
  263.        data, and creating data files, symbol-tables and other workproducts.
  264.  
  265.  
  266.                                                           Griss- 4
  267.  
  268.  
  269.     fflCustom full domain-specific language and environment, with domain-specific library.
  270.  
  271.        Yacc and Lex, LISP-based meta-compilers, and C-based Tree-Meta have been used in HP to
  272.        produce a variety of instrument system programming languages. These configure and select
  273.        parts of an instrument, create front-panel display and remote-port drivers, declare bindings
  274.        to measurement routines, establish interfaces to higher-level analysis routines, and fill in data
  275.        tables.
  276.  
  277.  
  278.  
  279. Within HP, practical systems combine several of these techniques at the same time, leading to some
  280. issues of consistency and interoperability.  One way to ensure that several languages be consistent
  281. or interoperate, is to implement them using the same language kit, which can be embedded with the
  282. development and delivery environments.  In addition to Lex and Yacc, small embedded interpreters
  283. (Xlisp, TCL, PERL) and simple-meta compilers (Tree-Meta, Pmeta) are quite attractive for this
  284. purpose.
  285.  
  286.  
  287.  
  288. 5      Next  Steps  and  Summary
  289.  
  290.  
  291.  
  292. We are defining and prototyping a series of small domain-specific kits to help drive the development
  293. of our kit design and implementation methodology and tools.
  294.  
  295.  
  296. Our first kit is in the domain of task/dolist managers, using our software bus[10 ] for component
  297. integration. Following a minimal domain analysis and kit design, components were written in several
  298. languages (LISP, C++, TCL/TK) for item display, definition, time management, and dolist item
  299. storage  managment.  Alternative  components  and  options  are  selected, and  data-structures  are
  300. defined, using a simple (LISP-based) configuration language, from which a complete application is
  301. generated. A conversational rule-based tool uses data derived from our domain analysis to present
  302. decisions and consequences to the application builder to help generate the kit configuration file.
  303.  
  304.  
  305. In our next cycle, we will refine our DA method, and be more systematic about the design of the kit
  306. architecture and style. We will use hypertext tools (Kiosk[11 ]) to browse and display domain and
  307. kit workproducts, issues and decisions and as an interface tothe kit components and documents.
  308.  
  309.  
  310. We are surveying the use ofhybrid kits in HP, looking at language and generator style and support-
  311. ing technologies, and to better understand divisional constraints and practices.  We are collecting
  312. information on available language, builder and generator technologies,  and willdo some analysis
  313. and prototyping to understand several of these.
  314.  
  315.  
  316.  
  317. 6      Acknowledgments
  318.  
  319.  
  320.  
  321. I had several useful discussions with Joachim Laubsch as I prepared this position paper. Dennis
  322. Freeze,  Jon  Gustafson,  Joe  Mohan  and  Kevin Wentzel  gave  useful  comments  on  drafts  of  this
  323. position paper.
  324.  
  325.  
  326.  
  327. References
  328.  
  329.  
  330.  
  331.   [1] M. L. Griss, "A multi-disciplinary software reuse research program," in Proceedings of the 5th
  332.  
  333.  
  334.  
  335.                                                           Griss- 5
  336.  
  337.  
  338.       Annual Workshop on Software Reuse (M. Griss and L. Latour, eds.), pp. Griss-1:8, Department
  339.       of Computer Science, University of Maine, Nov. 1992.
  340.  
  341.  
  342.   [2] M. Griss and W. Tracz, "Workshop on software reuse," Software Engineering Notes, vol. 18,
  343.       pp. 74-85, Apr. 1993.
  344.  
  345.  
  346.   [3] J. M. Neighbors, "The draco approach to constructing software from reusable components,"
  347.       IEEE Transactions on Software Engineering, vol. SE-10, pp. 564-574, Sept. 1984. Presented at
  348.       the ITT Workshop on Reusability inProgramming, Newport, RI, September 1983, published
  349.       by UCI as report RTP019.
  350.  
  351.  
  352.   [4] B. Frakes, "Application generators." Lecture note slides, June 1993. (Private communciation).
  353.  
  354.  
  355.   [5] D. S. Batory, "The genesis database system compiler:  Large scale software reuse from domain
  356.       modeling," in  Proceedings  of  the  4th  Annual  Workshop  on  Software  Reuse (L. Latour, ed.),
  357.       (Department of Computer Science, 222 Neville Hall, Orono, Maine 04469), pp. 1-6, University
  358.       of Maine, University of Maine, Nov. 1991.
  359.  
  360.  
  361.   [6] G. Fischer, "Cognitive view of reuse and redesign,"  IEEE Software,  vol. 4,  pp. 60-72,  July
  362.       1987.
  363.  
  364.  
  365.   [7] J. A. Johnson, B. A. Nardi, C. L. Zarmer, and J. R. Miller, "Ace: Building interactive graphical
  366.       applications," Communications of the ACM, vol. 36, pp. 40-55, Apr. 1993.
  367.  
  368.  
  369.   [8] J. Bentley, "Little languages," Communications of the ACM, vol. 29, pp. 711-721, Aug. 1986.
  370.  
  371.  
  372.   [9] J. C. Cleaveland, "Building application generators," IEEE  Software, vol. 4, pp. 25-33, July
  373.       1988.
  374.  
  375.  
  376. [10]  B.  W.  Beach,  M.  L.  Griss,  and  K.  D.  Wentzel,  "Bus-based  kits  for  reusable  software,"  in
  377.       Proceedings of ISS'92, UCI, Irvine, March 6, pp. 19-28, Mar. 1992.
  378.  
  379.  
  380. [11]  M. Creech, D. Freeze, and M. L. Griss, "Using hypertext in selecting reusable software com-
  381.       ponents," in Proceedings of Hypertext'91, (Palo Alto, CA), pp. 25-38, Software and Systems
  382.       Laboratory, Dec. 1991.
  383.  
  384.  
  385.  
  386. 7      Biography
  387.  
  388.  
  389.  
  390. Martin  L.  Griss is Principal Laboratory Scientist for Software Engineering at Hewlett-Packard
  391. Laboratories, Palo  Alto.   As  manager  of  the Software  Reuse  Department, he  leads  research  on
  392. software  reuse, domain-specific  kits  and  flexible  software  factories.  He  works  closely  with  HP
  393. Corporate Engineering to systematically introduce software reuse into HP's software development
  394. processes. He was previously Director of HP's Software Technology Laboratory, researching expert
  395. systems,  object-oriented  databases,  programming  technology,  human-computer  interaction,  and
  396. distributed  computing.  Before  that, he  was  an  Associate  Professor  of  Computer  Science  at  the
  397. University of Utah, working oncomputer algebra and portable LISP systems (PSL). He received a
  398. Ph.D. in Physics from the University ofIllinois in 1971.
  399.  
  400.  
  401.  
  402.                                                           Griss- 6
  403.