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 / singhal2.ascii < prev    next >
Text File  |  1993-10-19  |  19KB  |  421 lines
  1.  
  2.  
  3.  
  4.  
  5. P++:  A  Language  for  Large-Scale  Reusable  Software  Components
  6.  
  7.  
  8.  
  9.                                          Vivek Singhal and DonBatory
  10.  
  11.  
  12.  
  13.                                       Department of Computer Sciences
  14.  
  15.                                       The University of Texas at Austin
  16.  
  17.                                                 Austin, Texas 78712
  18.  
  19.                                              Tel:  (512) 471-9711/9713
  20.  
  21.                                    Email:  fsinghal,batoryg@cs.utexas.edu
  22.  
  23.  
  24.  
  25.                                                         Abstract
  26.  
  27.  
  28.           P++ is a programming language that supports the GenVoca model [1], a particular style of
  29.       software design that is intended for building software system generators.  P++ is an enhanced
  30.       version of C++:  it offers linguistic extensions for component encapsulation, abstraction, pa-
  31.       rameterization, and inheritance, where a component is a subsystem, i.e., a suite of interrelated
  32.       classes and functions.
  33.  
  34.  
  35.       Keywords: op en architectures, program families, large-scale reuse, software system synthesis,
  36.       GenVoca, software system generators.
  37.  
  38.  
  39.       Workshop Goals: feedback on our research; exposure to other work in software reuse.
  40.  
  41.  
  42.       Working Groups:  reuse process models; domain analysis/engineering; design guidelines for
  43.       reuse; reuse and object-oriented methods; tools and environments.
  44.  
  45.  
  46.  
  47.                                                         Singhal-1
  48.  
  49.  
  50. 1      Background
  51.  
  52.  
  53.  
  54. Almost two decades ago,Parnas observed that software design was incorrectly taught as atechnique
  55. which sought a unique program/solution, because, over its lifetime, the program inevitably would
  56. evolve into a family of similar programs [2 ]. When programs are not designed for extensibility,the
  57. effort and expense needed to modify them is often out of proportion to the changes themselves.  A
  58. different approach, one that achieves economies of scale, was needed. He argued that since program
  59. families are inevitable, designing program familiesfrom the beginning is the most cost-effective way
  60. to proceed.
  61.  
  62.  
  63. Recent work on domain-specific softwarearchitectures [3 , 4] has shown that software system gener-
  64. ators offer a promising means of economically building families of large, complex software systems.
  65. These generators are domain-specific; they implement models (called domain models) which show
  66. how to construct a family of similar software systems by composing reusable, prefabricated compo-
  67. nents. The essential themes that Parnas espoused are present in contemp orary software generators;
  68. generators formalize the design of software families as op enarchitectures, where software system
  69. synthesis and evolution can be quick and inexpensive.
  70.  
  71.  
  72. Some examples of generators include Genesis (database systems) [5], Avoca (network protocols)
  73. [6 ], Ficus (file systems) [7 ], Brale (host-at-sea buoy systems) [8 ], and Predator (data structures)
  74. [9].  Although each of these generators was developed independently and targeted for a different
  75. problem  domain, all  were  organized  in  basically  the  same  way.  The  GenVoca  model  captures
  76. their common design strategy [1]:  it defines a particular style of designing and organizing reusable
  77. components that enables families of software systems to b e defined through component composition.
  78. An implementation of a GenVoca model is a software system generator for a particular domain.
  79.  
  80.  
  81. Some of the important features of GenVoca are: (1) Components are thebuilding blocks of hierar-
  82. chical software systems (a component isa subsystem or module).  (2) Components must import and
  83. export standardized interfaces. (3) Component composition and customization should be achieved
  84. through parameterization.
  85.  
  86.  
  87. It is well-known that language support for a design paradigmcan tremendously simplify the ap-
  88. plication  of  that  paradigm; ob ject-oriented  languages,  for  example,  have  been  instrumental  in
  89. popularizing and realizing object-oriented designs. For the same reason, languagesupp ort for Gen-
  90. Voca is important. In the next section, we briefly describe the P++ programming language, which
  91. codifies  the  GenVoca  model.  P++  offers  several  linguistic  extensions  to  C++  to  supp ort  com-
  92. ponent encapsulation, abstraction, parameterization, and inheritance. From our experiences with
  93. the Genesis and Predator projects, we believe that P++ would have considerably simplified the
  94. implementations of these generators.
  95.  
  96.  
  97.  
  98. 2      The  P++  Language
  99.  
  100.  
  101.  
  102. 2.1     Encapsulation and Abstraction
  103.  
  104.  
  105.  
  106. Encapsulation and abstraction are two program design techniques often used to manage the com-
  107. plexity of large software systems. Encapulation is the technique of consolidating related code and
  108. data fragments into atomic units of program construction.  The GenVoca mo del has demonstrated
  109. that the scales of encapsulation currently provided by programming languages, namely functions
  110.  
  111.  
  112.  
  113.                                                          Singhal-2
  114.  
  115.                              realm collection<class T>
  116.                              -
  117.                                class container
  118.                                -
  119.                                   container ();                 // container
  120.                                ";
  121.                                class cursor
  122.                                -
  123.                                   cursor (container *);       // constructor
  124.                                   void first ();                //container traversal
  125.                                   void next ();                 // container traversal
  126.                                   int eoc ();                   // beyond end of container?
  127.                                   void insert (T);             // add item
  128.                                   void remove ();              // delete item
  129.                                   T& get_value ();             // get item
  130.                                ";
  131.                              ";
  132.  
  133.                              component linked_list : collection<class T>
  134.                              -
  135.                                class element
  136.                                -
  137.                                   element (T);                  // constructor
  138.                                   T data;                        // thevalue of this node
  139.                                   element *next, *prev;       // adjacent nodes on list
  140.                                ";
  141.                                class container
  142.                                -
  143.                                   element *head;                //first node of list
  144.                                ";
  145.                                class cursor
  146.                                -
  147.                                   element *current_pos;       // current position
  148.                                   container *cont;             // container iterated upon
  149.                                ";
  150.                              ";
  151.  
  152.  
  153.  
  154.                              Figure 1: Sample realm and component declarations.
  155.  
  156.  
  157.  
  158. and classes, are inappropriate for building large systems. Instead, GenVoca advocates the use of
  159. components, which correspond to subsystems or modules. In P++, a component consists ofa suite
  160. of interrelated data members, functions, and classes.
  161.  
  162.  
  163. Abstraction is a design technique which separates the interface of a component from its implementa-
  164. tion. In P++, the realm construct specifies the interface of a component: it declares the functions
  165. and classes which comprise a component's interface, without revealing the implementation of those
  166. functions and classes.
  167.  
  168.  
  169. Figure 1 lists an example from the domain of data structures. First shown is the declaration of the
  170. collection realm: this is a standardized abstract interface for interacting with data structures that
  171. store collections of objects. collection declares two classes, container (which actually stores the
  172. objects) and cursor (which provides methods for manipulating objects inside a container). Notice
  173. that  the  realm  reveals  no  implementation  details  ab out  its  classes,  thus  maintaining  the  proper
  174. separation between a component's abstract interface and concrete implementation.
  175.  
  176.  
  177. The next declaration in Figure 1 is that of linked_list, a component from the collection realm.
  178. Because linked_list belongs to collection, it is obligated to implement (export) the methods
  179. listed in collection's declaration. The body of linked_list's declaration introduces a new class
  180. called element, along with new data members for the container and cursor classes. This class
  181. and these data members are part of linked_list's private implementation; they are not visible to
  182.  
  183.  
  184.  
  185.                                                          Singhal-3
  186.  
  187.                    component linked_list <collection<element> next_layer> : collection<class T>
  188.                    -
  189.                       class element - ... ";
  190.                       class container - ... ";
  191.                       class cursor - ... ";
  192.                    ";
  193.  
  194.                    component binary_tree <collection<element> next_layer> : collection<class T>
  195.                    -
  196.                       class element - ... ";
  197.                       class container - ... ";
  198.                       class cursor - ... ";
  199.                    ";
  200.  
  201.                    component array : collection<class T>
  202.                    -
  203.                       class element - ... ";
  204.                       class container - ... ";
  205.                       class cursor - ... ";
  206.                    ";
  207.  
  208.  
  209.  
  210.                               Figure 2:  A parameterized component declaration.
  211.  
  212.  
  213.  
  214. other components or programs.
  215.  
  216.  
  217. A fundamental feature ofcomp onent encapsulation is evident in this example: a component consists
  218. of  several  data  members,  functions,  and/or  classes  that  are  intimately  intertwined.  Because  of
  219. their  interrelated  algorithms,  the  element,  cursor,  and container  classes  cannot  be  designed,
  220. implemented, or reused in isolation. P++ provides the programming language support to maintain
  221. their cohesion as an atomic unit of system construction.
  222.  
  223.  
  224.  
  225. 2.2     Parameterization
  226.  
  227.  
  228.  
  229. The use of components almost always entails some customization.  Direct sourceco de modification
  230. may be appropriate for functions or classes because of their (typically)small co de volume; however,
  231. this  customization  technique  is  rarely  effective  for  components.   Component  parameterization,
  232. which permits an easy and controlled form of modification,is widely believed to be the prescription
  233. for successful component customization [10 ].
  234.  
  235.  
  236. Contemporary programming languages already offer constant andtype parameterization of classes;
  237. P++ extends these capabilities to components and realms. In addition,  P++ uses the mo del of
  238. parameterization to perform component composition: a component C may be parameterized by a
  239. realm R, which means that C may be combined with any component that belongs to realm R.
  240.  
  241.  
  242. The  collection  declaration  of  Figure  1  shows  an  example  of  type  parameters.   collection  is
  243. defined in terms of the type parameter T; this parameter determines thekind of ob jects stored by
  244. the data structure. Furthermore, because the component linked_list is defined to be a member
  245. of the collection realm, linked_list is also implicitly parameterized by thetype T (notice that
  246. the definition of element depends on the value of T).
  247.  
  248.  
  249. Figure  2  shows  three  components  of  the  collection  realm,  namely  array,  binary_tree,  and
  250. linked_list. Note that the declaration of linked_list has been revised so that it is now param-
  251. eterized in terms of the collection realm.  This means that linked _list imp orts theinterface
  252. defined by collection.  Any component belonging to this realm would be a legal value for this
  253.  
  254.  
  255.  
  256.                                                          Singhal-4
  257.  
  258.  
  259. parameter (e.g. array, binary_tree, or even linked_list). Although not obvious, parameterizing
  260. collection components by realms forms the basis for generating a vast family of data structures
  261. [9].
  262.  
  263.  
  264. P++'s  realm  parameterization  facility  is  a  powerful  language  feature  for  designing  and  reusing
  265. software components:
  266.  
  267.  
  268.  
  269.     fflIt  encourages  the  development  of  components  with  standardized  abstract  interfaces.   Such
  270.        components are more likely to be reused because they can be easily interchanged with other
  271.        components of the same realm [9 ].
  272.  
  273.  
  274.     fflWhen interchangeable components are available, it is easy to tune the p erformance of a sys-
  275.        tem:  different components can be quickly substituted for one another, thus greatly facilitating
  276.        the process of finding improved implementations for a system [9].
  277.  
  278.  
  279.     fflP++ integrates component definition and combination features in a single language. Other re-
  280.        searchers have used module interconnection languages to combine components [11 ].  However,
  281.        such languages typically are different from the language in which components are written.
  282.  
  283.  
  284.  
  285. 2.3     Inheritance
  286.  
  287.  
  288.  
  289. Programming  languages  use  inheritance  to  implement  two  kinds  of  hierarchies:  implementation
  290. hierarchies  and  type  hierarchies  [12 ].  Current  object-oriented  languages  usually  supp ort  imple-
  291. mentation hierarchies, where a subclass inherits both the interface and the implementation of the
  292. superclass, unless explicitly overridden (overloaded) by the subclass.  Incontrast, when a language
  293. implements type hierarchies, inheritance is being used to support data abstraction. In this context,
  294. a subtype inherits only the interface of its supertype, but not its implementation.
  295.  
  296.  
  297. To  support  type  hierarchies, P++  allows  new  realm  declarations  to inherit  from  existing  realm
  298. declarations. For example, suppose realms R and S were defined as follows:
  299.  
  300.  
  301.  
  302.             realm  R  -  ...  ";
  303.             realm  S  :  realm  R  -  ...  ";
  304.  
  305.  
  306.  
  307. These declarations indicate that S inherits the interface of R; that is, the interface of S includes not
  308. only its own functions and classes, but also those of R. Therefore, S's interface is a superset of R's,
  309. which means that all components belonging to realm Salso b elong to realm R. Realm inheritance is
  310. important because it provides a structured technique for evolving component interfaces. Since realm
  311. inheritance is an instance of type hierarchies, this form of inheritance ensures interchangeability, a
  312. property which enhances the likelihood of reuse.
  313.  
  314.  
  315.  
  316. 3      Conclusions
  317.  
  318.  
  319.  
  320. There is growing recognition that existing software system design techniques are inadequate; they
  321. are  aimed  at  producing  one-of-a-kind  systems  that  are  difficult  to  modify  and  evolve.  Software
  322. system evolution is a critical requirement of future systems, to satisfy the ever-increasing demands
  323. of new applications. Concomitantly, the need for software generators that can manufacture families
  324.  
  325.  
  326.                                                          Singhal-5
  327.  
  328.  
  329. of related systems by composing reusable components is becoming progressively more important,
  330. to meet the challenge of economical software system evolution.
  331.  
  332.  
  333. Research in domain analysis and program families has identified the system organization concepts
  334. needed by software system generators. The scale of these programming concepts (i.e.  components)
  335. transcend  those  found  in  conventional  programming  languages  (functions,  classes).  The  P++
  336. programming language extends the encapsulation, abstraction, parameterization, and  inheritance
  337. capabilities of C++ to components; webelieve P++ is a prototype of future languages that support
  338. the construction of families of systems and software system generators.
  339.  
  340.  
  341.  
  342. References
  343.  
  344.  
  345.  
  346.   [1] D. Batory and S. O'Malley, "The design and implementation of hierarchical software systems
  347.       with  reusable  components," ACM  Transactions  on  Software  Engineering  and  Methodology,
  348.       vol. 1, pp. 355-398, October 1992.
  349.  
  350.  
  351.   [2] D.  Parnas, "On  the  design  and  development  of  program  families," IEEE  Transactions  on
  352.       Software Engineering, vol. SE-2, pp. 1-9, March 1976.
  353.  
  354.  
  355.   [3] L.  Coglianese  and  R.  Szymanski, "DSSA-ADAGE:  An  environment  for  architecture-based
  356.       avionics development," in Proceedings of AGARD, 1993.
  357.  
  358.  
  359.   [4] Software  Engineering  Institute, Proceedings  of  the  Workshop  on  Domain-Specific Software
  360.       Architectures, (Hidden-Valley, Pennsylvania), 1990.
  361.  
  362.  
  363.   [5] D. Batory, "Concepts for a DBMSsynthesizer," in Proceedings of ACM Principles of Database
  364.       Systems Conference, 1988.
  365.  
  366.  
  367.   [6] S. O'Malley and L. Peterson, "A dynamic network architecture," ACM Transactions on Com-
  368.       puter Systems, vol. 10, pp. 110-143, May 1992.
  369.  
  370.  
  371.   [7] J.  Heidemann  and  G.  Popek, "File  system  development  with  stackable layers,"  Tech.  Rep.
  372.       CSD-930019,  Department  of  Computer  Science,  University  of  California,  Los  Angeles,  July
  373.       1993.
  374.  
  375.  
  376.   [8] D. M. Weiss,  "Synthesis operational scenarios,"  Tech. Rep. 90038-N, Software Productivity
  377.       Consortium, Herndon, Virginia, August 1990.
  378.  
  379.  
  380.   [9] D. Batory, V. Singhal, M. Sirkin, and J. Thomas, "Scalable software libraries," in Proceedings
  381.       of ACM SIGSOFT '93: Symposium on the Foundationsof Software Engineering, (Los Angeles,
  382.       California), December 1993.
  383.  
  384.  
  385. [10]  R. Prieto-Diaz and W. Frakes, eds., Advances in Software Reuse: Second International Work-
  386.       shop on Software Reuse, IEEE ComputerSo ciety Press, 1993.
  387.  
  388.  
  389. [11]  R. Prieto-Diaz and J. Neighbors, "Module interconnection languages," Journal of Systems and
  390.       Software, vol. 6, pp. 307-334, November 1986.
  391.  
  392.  
  393. [12]  B. Liskov, "Data abstraction and hierarchy,"  in Addendum  to  the  OOPSLA  '87  Conference
  394.       Proceedings, pp. 17-34, October 1987.
  395.  
  396.  
  397.  
  398.                                                          Singhal-6
  399.  
  400.  
  401. 4      Biography
  402.  
  403.  
  404.  
  405. Vivek Singhal is a doctoral candidate in the Department of Computer Sciences at the The Uni-
  406. versity of Texas, Austin. He received his S.B. from the Massachusetts Institute of Technology in
  407. 1990. His research interests include reuse systems, domain modeling, and object-oriented database
  408. management systems.
  409.  
  410.  
  411. Don Batory is an Associate Professor in the Department of Computer Sciences at The University
  412. of Texas, Austin. He received his Ph.D. from the University of Toronto in 1980, he was Associate
  413. Editor of the IEEE Database Engineering Newsletter from 1981-84 and was Associate Editor of
  414. ACM Transactions on Database Systems from 1986-1991.  He is currently a member of the ACM
  415. Software Systems Award Committee,and his research interests are in extensible and object-oriented
  416. database management systems and large-scale reuse.
  417.  
  418.  
  419.  
  420.                                                          Singhal-7
  421.