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 / ning.ascii < prev    next >
Text File  |  1993-10-19  |  16KB  |  317 lines
  1.  
  2.  
  3.  
  4.  
  5. Module  Interface  Specification  and  Large-Grain  Software  Reuse
  6.  
  7.  
  8.  
  9.                                                   Jim Q. Ning
  10.  
  11.  
  12.  
  13.                                               100 S. Wacker Dr.
  14.  
  15.                                              Andersen Consulting
  16.  
  17.                                             Chicago Illinois 60606
  18.  
  19.                                                Tel: 312-507-4987
  20.  
  21.                                         Email: jning@andersen.com
  22.  
  23.                                               Fax:  312-507-3526
  24.  
  25.  
  26.  
  27.                                                      Abstract
  28.  
  29.  
  30.        This abstract reports a recent research project at Andersen Consulting's Center for Strategic
  31.    Technology Research (CSTaR). A central comp onent of this research is the design and devel-
  32.    opment of a module interface specification language called SLIM (a Specification Language for
  33.    Interconnecting Modules). This language can be used to specify module interface parameters as
  34.    well as pre and postconditions of module functions. The module specifications written in SLIM
  35.    can be used to statically analyze the "plug-compatibility" of modules. This research is a part of
  36.    a recent Andersen initiative to promote large-grain reuse and component-based software system
  37.    construction.
  38.  
  39.  
  40.    Keywords:  large-grain component reuse, formal specifications, modules, megaprogramming,
  41.    MILs
  42.  
  43.  
  44.    Workshop Goals: to gain a deeper understanding of the state of the research and practice of
  45.    reuse in other organizations, and to get feedback from external experts on our research
  46.  
  47.  
  48.    Working Groups: any group that addresses the technical aspects of reuse (e.g.,domain anal-
  49.    ysis, megaprogramming, reuse libraries, object-oriented methods, reusable component recovery,
  50.    etc.)
  51.  
  52.  
  53.  
  54.                                                       Ning- 1
  55.  
  56.  
  57. 1      Background
  58.  
  59.  
  60.  
  61. My Ph.D. research was in the area of Knowledge-Based Program Analysis.  During the last five
  62. years with Andesen Consulting, I mainly worked on Software Re-engineering and Reusable Com-
  63. ponent  Recovery.  I and  my  colleagues  develop ed  two  workbench  environments  (BAL/SRW  and
  64. COBOL/SRE) and published many journal articles and conference papers in these areas.  Since
  65. early this year, I am leading a research project in the area of Module Interface Specification and
  66. Analysis.  The  primary  objective  of  this  research  is  to  study  ways  to  make  large,  complex,  and
  67. possibly heterogeneous software modules more reusable.
  68.  
  69.  
  70.  
  71. 2      Position
  72.  
  73.  
  74.  
  75. Andersen Consulting specializes in constructing large customer application systemsfor many in-
  76. dustries such as utility, telecommunications, manufacturing, etc.  In the past, these systems were
  77. typically built by our engagement teamsat the customer sites.  Even for systems built within the
  78. same industry line, software reuse happens only in a very ad hoc fashion.
  79.  
  80.  
  81. In  order  to  promote  large-scale  reuse, we  now  believe  that  we  must  change  the way  that  our
  82. customer applications are produced and delivered.  There is a recent company-wide initiative to
  83. promote component-based software system construction.  Central to this initiative is the "software
  84. factory" concept.  We plan to build 15 to20 advanced software development centers worldwide,
  85. called  Solution  Engineering  Centers  (SECs).  In  the  future, a  large  percentage  of  the  customer
  86. software development is expected to be done at these SEC  sites. Our field teams will be mainly
  87. responsible for requirement acquisition, testing, tailoring, and maintenance tasks.  Through SECs,
  88. our experience and software assets accumulated inthe past will be greatly leveraged.
  89.  
  90.  
  91. CSTaR is a research-orientedorganization within Andersen Consulting.  Its Software Engineering
  92. Laboratory (SEL) is currently undertaking a research project (Module Interface Specification and
  93. Analysis)  as  part  of  the  company-wide  reuse  initiative.   We  are  developing  a  module  interface
  94. specification language called SLIM. This language will be used to encapsulate large, complex,and
  95. possibly heterogeneous software code modules to make them more reusable. We are also developing
  96. static analysis techniques to assist module interconnection.
  97.  
  98.  
  99. Many previous attempts on reuse were based on thereuse of small components such as data struc-
  100. tures, algorithms, object classes, procedures and functions.  There are many technical difficulties
  101. associated  with  small-component  reuse.  The  user  can  be  overwhelmed  by  the  number  of  small
  102. objects in a reuse library; it is difficult to locate desired components.  Besides,  a large number of
  103. interconnections will have to be established by the user in order to compose larger objects from
  104. smaller ones. In general, the payoff by small-scale reuse is low and there is little incentive for the
  105. user.
  106.  
  107.  
  108. Therefore,  in  our  research,  we  promote  large-grain  component  reuse.   Some  examples  of  large-
  109. grain components are account payable/receivable subsystems, database servers, and user interface
  110. packages.  In this position paper, we call these large objects "modules".  A module in this sense
  111. possesses the following characteristics:
  112.  
  113.  
  114.  
  115. it is large    - A  module mayconsist of a large number of objects and span several programs and
  116.        data files.
  117.  
  118.  
  119.  
  120.                                                           Ning- 2
  121.  
  122.  
  123. it is structurally independent               - A module should be loosely coupled with its outside world. A
  124.        totally independent module can run as a separate process and is normally called a "server".
  125.        A module that requires limited services from other modules is called a "client".
  126.  
  127. it is functionally cohesive            - A module provides a set of closely-related functional services in its
  128.        application domain.
  129.  
  130.  
  131.  
  132. In software design, what we call modules have also been referred to as "subsystems".
  133.  
  134.  
  135. Traditionally, large modules are rarely reusable because they are large and complex and therefore
  136. hard to understand by the user. Also, they might be written in different programming languages
  137. and  assume  different  execution  platforms.  A  specification  in  SLIM  can  be  seen  as  a  "wrapp er"
  138. around a module.  It hides the implementation details and explicates only the services provided
  139. and required by the module.  Using hardware analogy, we call a provided service a "server plug"
  140. and a required service a "client plug". Using SLIM, both the syntactic requirements and semantic
  141. behaviors of a plug can be specified. The syntactic requirements are specified in terms of interface
  142. parameter types (signatures) and the semantic behaviors in terms of pre and postconditions.
  143.  
  144.  
  145. The  client  plug  (C) of  a  module  attempts  to  reuse  the  server  plug  (S) of  another  module  by
  146. interconnecting C with S. A static analyzer will verify the "plug-compatibility" of the two plugs.
  147. The analyzer will check the type matching b etween the parameter specifications of C and S. In
  148. addition, it will also check whether their pre and postconditions match.  More specifically, it will
  149. attempt  to  verify  that  the  preconditions  of  C  implies the  preconditions  of  S  (so  that  S  can  be
  150. invoked normally) and the postconditions of Simplies the postconditions of C (so that C's service
  151. requirements are fully met by S).
  152.  
  153.  
  154. Recently, we have completed a proof-of-concept prototype that demonstrates the above ideas.
  155.  
  156.  
  157.  
  158. 3      Comparison
  159.  
  160.  
  161.  
  162. The survey by Prieto-Diaz and Neighbors appeared in 1986 [1] can be recognized as a "renaissance"
  163. work in module interconnection languages (MILs) as it sparked off several efforts on the subject.
  164. Prior to this paper, module interconnection languages received little attention. Even the objectives
  165. of these early efforts were modest.
  166.  
  167.  
  168. Module interconnection research was primarily motivated by the need for system integration and
  169. configuration management support in software development.  This line of research helped the for-
  170. mation  of  megaprogramming  concept.  According  to  Boehm  and  Scherlis  [2], megaprogramming
  171. refers to the practice of building and evolving computer software component by component.  In
  172. contrast to the traditional programming concepts,megaprogramming is based on the reuse of large
  173. components or modules rather than primitive programming statements and con-structs.
  174.  
  175.  
  176. In their paper on megaprogramming [3],  Wiederhold et al discussed a conceptual framework for
  177. megaprogramming.  What they call megamodules are large mo duleseach of which is possibly an
  178. entire system by itself.  They are programs that interconnect and enable communication among
  179. sub-modules.  Megaprograms  are  like  "glue"  for  module  composition  and  typically  involve  com-
  180. munication over networks for distributed systems.  Megaprogramming languages extend MILs by
  181. handling information transfer between heterogeneous modules, between dynamic queries and up-
  182. dates by users, between distributed network communication protocols, and by dynamically changing
  183. the specification of interfaces.
  184.  
  185.  
  186.  
  187.                                                           Ning- 3
  188.  
  189.  
  190. A unique aspect of Perry's work on the Inscape pro ject [4 ] is the practical use of formal specifications
  191. for describing module interfaces. Shallow consistency checking mechanisms can be used to process
  192. these specifications to catch certain kinds of errors. Changes to specifications can be automatically
  193. trickled  down  to  the  code  level.  If  some  part  of  the  specification  is  not  satisfied, warnings  are
  194. signaled.  The reverse direction of flow is also possible; changes to code can be propagated to the
  195. specification level and transmitted to related modules to determine effects and conflicts resulting
  196. from  the  change.  Perry  also  suggested  test  case  generation  from  specifications  and  integration
  197. testing to augment static analysis. Finally, these specifications can also be used for browsing and
  198. understanding the function of the associated modules and this feature is especially of interest in
  199. reuse  library  management.  The  extent  of  implementation  of  this  work  is  not  evident  from  the
  200. literature.
  201.  
  202.  
  203. Recently  there  has  been  a  trend  towards  Object-Oriented  Mo dule Interconnection  Languages
  204. (OOMILs). A specification of a module's semantics is essentially a model of the module's behavior.
  205. Object-oriented methods can be used naturally to model the application domain and functional ser-
  206. vices of modules. Besides, class inheritance feature assists the reuse of object-oriented specifications
  207. across module specifications.
  208.  
  209.  
  210. In Hall and Weedon's work [5], they claim that the main problem with most programming languages
  211. is the lack of ability to describe what are needed (as client modules) although they usually have
  212. constructs to state what are provided (as server mo dules).  They suggestconstructs for making
  213. requires part explicit in modules. Each module specification is an object. The requires and provides
  214. interfaces are objects too. Modules have in addition to requires and provides fields, a contains field
  215. that indicates objects contained in the module.
  216.  
  217.  
  218. POLYLITH [6, 7 ] is a system thathelps programmers interconnect mixed-language software com-
  219. ponents for execution in heterogeneous environments.   POLYLITH supports large-scale reuse:  a
  220. module in it must be able to run as an independent process. An interface must be specified if the
  221. module is to be used by other modules. In addition, a mo dule has to list all services it uses, and
  222. indicates an implementation and optionally a target machine.  An application is specified in terms
  223. of all bindings needed between different modules included inthe application.  POLYLITH uses this
  224. specification to guide application packaging (static interfacing activities such as stub generation,
  225. source program adaptation, compilation, and linking). A  central idea is the notion of a software
  226. toolbus, which integrates application modules and hides away heterogeneity in coding languages
  227. and execution architectures.
  228.  
  229.  
  230. According to the Object Management Group (OMG), the Common Object Request Broker Archi-
  231. tecture (CORBA, [8]) provides the mechanisms by which objects/modules may transparently make
  232. requests and receive responses. IDL (the Interface Definition Language)is the language in CORBA
  233. used to describe the interfaces that client objects call and object implementations provide.
  234.  
  235.  
  236. An Object Request Broker (ORB) acts as the object communication layer. When a client object
  237. needs  a  service  from  a  server  object, the  request  is  initiated  by  calling  stub  routines  that  are
  238. specific to the server object. Then,  theORB  layer intercepts the request, locates the appropriate
  239. implementation  code,  transmits  parameters,  and  transfers  control  to  the  object  implementation
  240. through an IDL skeleton. When the request is complete, control and output values are returned to
  241. the client through ORB layer.
  242.  
  243.  
  244. PARTS (Parts Assembly and Reuse Tool Set [9]) is a component-based visual programming envi-
  245. ronment for developing applications from a category of pre-fabricated components.  It has a very
  246. intuitive,  friendly,  ob ject-oriented user interface.  New applications can be quickly assembled by
  247.  
  248.  
  249.  
  250.                                                           Ning- 4
  251.  
  252.  
  253. simply selecting existing parts from the reuse category and creating event, argument, and result
  254. links among them using mouse clicks, context-sensitive menus, and dialog boxes. In situations when
  255. appropriate components can always be found in the reuse category, complete new applications can
  256. be built without traditional typing-style programming.
  257.  
  258.  
  259. PARTS also supp orts the integration of heterogenous (multi-language, mixed-application) compo-
  260. nents with the help of OS/2's DLL (Dynamic Link Library) andDDE (Dynamic Data Exchange)
  261. facilities.
  262.  
  263.  
  264.  
  265. References
  266.  
  267.  
  268.  
  269. [1]  R.  Prieto-Diaz  and  J.  M.  Neighbors,  "Module  Interconnection  Languages," The  Journal  of
  270.      Systems and Software, vol. 6, pp. 307-334, 1986.
  271.  
  272.  
  273. [2]  B. Boehm and B. Scherlis, "Megaprogramming," in Proceedings of the DARPA Software Tech-
  274.      nology Conference, 1992.
  275.  
  276.  
  277. [3]  G. Wiederhold, P. Wegner, and S. Ceri, "Toward Megaprogramming," Communications of the
  278.      ACM,vol. 35, pp. 89-99, November 1992.
  279.  
  280.  
  281. [4]  D. E. Perry, "The Inscape Environment," in Proceedings of the 11th International Conference
  282.      on Software Engineering, (Pittsburgh, PA), pp. 2-12, May 1989.
  283.  
  284.  
  285. [5]  P. Hall and R. Weedon, "Object-Oriented Module Interconnection Languages," in Proceedings
  286.      of the Second International Workshop on Software Reuse, (Lucca, Italy), March 1993.
  287.  
  288.  
  289. [6]  J. Purtilo, "The Polylith Software Bus," Tech. Rep. TR-2469, University of Maryland, 1991.
  290.  
  291.  
  292. [7]  C. Hofmeister,J. Atlee, and J. Purtilo, "Writing Distributed Programs in Polylith," Tech. Rep.
  293.      TR-2575, University of Maryland, 1991.
  294.  
  295.  
  296. [8]  "The  Common Ob ject  Request  Broker:  Architecture  and  Specification," Tech.  Rep.  91.12.1,
  297.      Object Management Group,1991.
  298.  
  299.  
  300. [9]  DIGITALK, PARTS Workbench User's Guide, February 1993.
  301.  
  302.  
  303.  
  304. 4      Biography
  305.  
  306.  
  307.  
  308. Jim Ning's Ph.D. research was in the area of Knowledge-Based Program Analysis. During the last
  309. five years with Andesen Consulting, he worked mainlyon Software Re-engineering and Reusable
  310. Component Recovery.  He and his colleagues developed two workb ench environments (BAL/SRW
  311. and COBOL/SRE) and published a number of journal articles and conference papers in these areas.
  312. He is currently leading a research project in the area of Module Interface Sp ecification and Analysis.
  313.  
  314.  
  315.  
  316.                                                           Ning- 5
  317.