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 / wisr4 / proceedings / detex / latour.detex < prev    next >
Text File  |  1992-04-05  |  14KB  |  362 lines

  1.  [12pt] article  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.   Scaling Up the 3Cs Model 
  12. A Schema for Extensible Generic Architectures 
  13.  
  14.   Larry Latour and Curtis Meadow 
  15.     University of Maine 
  16.     Orono, Maine, 04469   
  17.     larry@gandalf.umcs.maine.edu 
  18.  
  19.    
  20.  
  21.  
  22.  
  23.   
  24. The 3C model was first developed in   and reviewed at last
  25. year's workshop  .  This position paper responds to 
  26. that review, and in doing so outlines a framework for thinking about
  27. 3C aspects of    an architecture  of components.  Such components
  28. can be said to be    normalized  in that they capture one concern
  29. of the architecture in their content.  
  30.  
  31.   0.3in 
  32.  
  33.    Keywords:  3C model, generic architectures, normalized components.
  34.  
  35.  
  36.  
  37.  
  38.   Introduction 
  39.  
  40. The 3C model was presented and reviewed at our previous workshop,
  41.    The Third Annual Workshop: Methods and Tools for Reuse  
  42.  .  Will Tracz summarized his perspective on the
  43. discussion:
  44.  
  45.   
  46. The 3C model was accepted in part by most of the attendees.  The most 
  47. critical critisism focused on the granularity of the modules.  I
  48. believe people were trying to scale up the model to apply to larger
  49. subsystems and were having difficulty in expressing the semantics.
  50. Another area that needed further clarification is the process of
  51. differentiating the roles of importation (``with'' clause in Ada)
  52. and parameterization (genericity in Ada) with regard to interface
  53. design.
  54.  
  55.  
  56. Partly in response to this need to ``scale up'' the 3C model, and
  57. partly to explore related issues such as the differing (actually
  58. complementary) roles of importation and parameterization, we at
  59. the University of Maine have been exploring how the model can be
  60. used to design and craft:
  61.  
  62.   
  63.  
  64. integrated component libraries, and
  65.  
  66. generic software architectures
  67.  
  68.  
  69. By an integrated component library we mean a library (1) whose interface,
  70. or    concept , is defined by an organized collection of module
  71. abstractions, and (2) whose implementation, or    content , is defined
  72. by a collection of ``normalized'' subcomponents, each of which 
  73. encapsulates a single design concern and derives its    context 
  74. from both the environment in which the library is used and from other
  75. library subcomponents.  Such subcomponents are mixed and matched to
  76. realize the library interface abstractions.
  77.  
  78. Such an integrated library has many of the same properties as a generic
  79. architecture.  That is, it provides not only a collection of components
  80. but an integrated framework for the construction of a family of 
  81. systems from such components.
  82.  
  83. We have proposed a schema for thinking about such integrated frameworks,
  84. called the    layered generic architecture schema , or LGA schema.
  85. In it we attempt to deal with issues related to integrated collections
  86. of components (concept organization, separation of concerns, 
  87. contextual dependencies between components, etc.).  We present an
  88. overview of the schema and discuss issues relating to it in the
  89. following sections.
  90.  
  91.  
  92.  
  93.   The 3C Model and ``Normalized'' Components 
  94.  
  95. As a starting point to building such frameworks, the 3C model provides
  96. us with a way to think about the various aspects of a single
  97. component.  As such, it forms the basis for constructing
  98. ``normalized'' components within a framework.  We take the term
  99.    normalization  from the relational database world, since:
  100.  
  101.   
  102.  
  103.    intuitively  
  104. we would like to think of a normalized component in the same sense
  105. that we think of a normalized relation.  That is, just as a normalized
  106. relation captures the essence of a single entity with no embedded
  107. subentities, so does a normalized component capture the essence of a
  108. single concept and implementation concern, with context factored out and
  109. either imported or provided through parameterization.
  110.  
  111.    formally 
  112. we would like to be able to provide rules for discovering and factoring
  113. out context in the same way in which we have formulated rules for
  114. normalizing relations, i.e., by looking for various forms of
  115. structural replication and factoring them out.  An interesting
  116. avenue of exploration, and one in which we have just begun to 
  117. think about, is the formalization of such rules.
  118.  
  119.  
  120.  
  121.   Related Work 
  122.  
  123. A good deal of work has recently been done on the design and construction
  124. of integrated libraries/generic architectures.  The CAMP (Common
  125. Ada Missile Packages) 
  126.   effort provided one of the first such collections, 
  127. approximately 200
  128. normalized parts organized into a number of subsystem architectures
  129. along with tools for instantiating such architectures. Stepanov and Musser
  130.   have had an ongoing project constructing integrated
  131. component libraries consisting of normalized subcomponents and a
  132. framework for instantiating them. Their initial Ada work was in
  133. the basic data structures domain, with a library of parts and a
  134. textbook   describing them.  Uhl and Schmid  
  135. have developed a systematic catalogue of reusable abstract data
  136. types, in which they have similarly explored these issues.
  137. Bassett   has developed a collection of code frames used
  138. to construct a wide variety of EDP systems.  Batory  
  139. has constructed a collection of normalized database components 
  140. with tools for composing them into a number of database
  141. management system variants.
  142.  
  143. Along with the above efforts specifically designed to provide 
  144. integrated software libraries/architectures, we have looked at a
  145. number of efforts that have similar characteristics.  The UNIX
  146. environment, for example, can be viewed as a multi-level
  147. collection (system calls, library facilities, composition tools) of
  148. normalized components along with rules and tools for composing
  149. and tailoring them for a particular domain.  Similarly, the
  150. X windows system  is a multi-level collection of
  151. components (Xlib components, Widgets, Intrinsics, Resource files)
  152. along with rules and tools for their composition.  In fact, the
  153. philosophy of the X effort, to provide a collection of ``look and
  154. feel'' independent services, is similar to our approach, i.e., to provide
  155. an extensible, adaptable collection of building blocks and rules
  156. for composing them into flexible, evolving library interfaces/systems.
  157.  
  158. From these studies and our own experiments using Booch component
  159.   implementations and Stepanov and Musser's generic components,
  160. we derived a schema for such architectures, allowing us to isolate
  161. and deal with a number of orthogonal architectural issues.  Such a
  162. schema is built on and is complementary to the 3C ``schema'' for
  163. dealing with single component issues.
  164.  
  165.  
  166.   The LGA Schema 
  167.  
  168. As a starting point in the development of our schema, 
  169. we draw on the 3C model of component
  170. structure.  We observe that the separation of concepts from their
  171. content has been relatively well explored and widely practiced, but
  172. that the isolation of contextual dependencies has not been as well
  173. explored, nor has it been subjected to a formal analysis.
  174.  
  175. It seems reasonable to assume 
  176. that careful isolation of contextual dependencies 
  177. in the modular structure of an integrated library/generic
  178. architecture can produce a framework that is not only capable of being
  179. instantiated to a large number of actual components/systems, but that
  180. can be easily extended and adapted by ``plugging in'' newly
  181. constructed modules embodying different contextual information.
  182. As we mentioned earlier, this approach has to an extent been explored in the 
  183. CAMP and Stepanov and Musser work.
  184.  
  185. Our schema divides the modules in an LGA into several classes, similar to 
  186. the abstraction classes defined by Stepanov and Musser.  These classes are
  187. contextual abstractions, abstract algorithms, auxiliary abstractions,
  188. base abstractions, and view abstractions.
  189.  
  190.    Contextual abstractions  encapsulate various contextual design
  191. decisions such as data representation, storage management, concurrency
  192. control, device handling, persistence, and communication.  They
  193. typically are characterized by hard coded design decisions with
  194. ``invariant context'' provided by with statements, but they can be
  195. services provided by an entirely different ``lower-level'' architecture,
  196. such as a database management system or network architecture.
  197.  
  198.    Abstract algorithms  incorporate the algorithmic content of the
  199. architecture.  They are parameterized by a collection of theories,
  200. each describing a class of abstract data types.  They typically
  201. fall into two categories:
  202.  
  203.   
  204.  
  205.    Horizontal extensions : such algorithms provide additional 
  206. functionality to theories in the same way that 
  207. operations are added to extend object classes in an object oriented
  208. environment.
  209.  
  210.    Vertical extensions : such algorithms combine theories to form
  211. structures that can be used together with an abstraction function
  212. to build base and auxiliary abstractions.  They are vertical extensions
  213. in the sense that they provide the glue to perform vertical 
  214. composition, i.e., the glue to map a representation onto an
  215. abstraction.
  216.  
  217.  
  218.    Base abstractions  are the canonical abstractions of the domain
  219. (the concepts of the domain), while    View abstractions 
  220. are derived from
  221. the base abstractions by mapping one language onto another. 
  222. The terms    view  and    base  were again taken from the
  223. dbms domain, as they capture a similar mapping notion.  Code in a
  224. View ``implementation'' is typically concerned with renaming 
  225. procedures and types, redistributing procedure functionality, and
  226. tailoring a concept to a particular protocol of use.  Such code
  227. has little ``algorithmic content'' in the sense that algorithms have
  228. simple complexity and little local resource utilization.
  229.  
  230.    Auxiliary abstractions  are structures that are convenient to 
  231. build in order to provide concepts to algorithm theories not 
  232. provided by existing contextual abstractions.  Both base and
  233. auxiliary abstractions are constructed by composing a representation
  234. from auxiliary and contextual abstractions, defining an
  235. abstraction function, and then choosing
  236. a collection of generic algorithms that realize the abstraction function.
  237.  
  238.  
  239. Note that a generic architecture embodies two types of content:
  240. algorithmic and structural.  The development of algorithmic content is
  241. a    programming in the small  issue.  It is concerned with the
  242. implementation of a single algorithm or family of algorithms, organized
  243. according to the structural and behavioral properties of the algorithms.
  244. Structural content is a    programming in the large  issue.  It refers to
  245. the ``scaffolding'' or framework of the architecture, and is 
  246. implemented by a particular modular decomposition.  Generic architectures
  247. incorporate the structural content of a domain in the structure of
  248. the architecture, and isolate the algorithmic content of the
  249. domain in abstract algorithms.
  250.  
  251.   Importation vs. Parameterization 
  252.  
  253. Parameterization provides us with a way to build normalized components
  254. in a manner completely independent of any contextual dependencies.  We
  255. only need be concerned with defining the theories that form the underlying
  256. representation (along with the abstract machine of the language) on 
  257. which the component content is specified.  The binding of actual
  258. concepts to these theories is then done at a later, system build, time.
  259. We have noticed though, that part of the process of limiting the domain 
  260. of a generic architecture includes the early binding of context by using
  261. Ada    with  statements rather than generic parameters.  This seems to
  262. be a similar issue to that of establishing the boundary between
  263. context and content.  That is, it is a design decision driven 
  264. by domain scoping concerns rather than by representation
  265. concerns.
  266.  
  267.  
  268.   Conclusions 
  269.  
  270. We have attempted both to fit prior efforts into our framework and to 
  271. develop a number of examples on our own in order to verify the schema
  272. structure.  In doing so we have found, as others have before us, that Ada is
  273. not the ideal design language for describing such generic architectures.
  274. We are therefore exploring language formalisms in this regard, 
  275. including efforts such as Goguen's module interconnect language work
  276.  , Tracz's LILEANNA work  , and modular extensions
  277. to ML  .  
  278.  
  279.  
  280.  
  281.    bass87 
  282.  
  283.  
  284. Bassett, P.G. [1987] Frame-Based Software Development.
  285.    IEEE Software .
  286.  
  287.  
  288.  
  289. Batory, D., and O'Malley, S., ``Genvoca: Reuse in Layered Domains'',
  290.    Proceedings of the First International Workshop
  291. on Software Reusability , Dortmund, Germany, July, 1991.
  292.  
  293.  
  294.  
  295. Booch, G. [1987]    Software Components with Ada . Benjamin/Cummings
  296. Publishing Co.
  297.  
  298.  
  299. CAMP [1985].    Common Ada Missile Packages , McDonnell
  300. Douglas Astronautics Company, St. Louis, MO, 3 Volumes.
  301.  
  302.  
  303.  
  304. Goguen, J.A. [1983]. LIL - A Library Interconnect Language.
  305.    Report on Program Libraries Workshop , SRI International.
  306.  
  307.  
  308.  
  309. Harper, R., Milner, R., and Tofte, M. [1988] The definition of Standard
  310. ML, Version 2. ECS-LFCS-88-62, Laboratory for Foundations
  311. of Computer Science, University of Edinburgh.
  312.  
  313.  
  314.  
  315. Musser, D.R., and Stepanov, A.A. [1988]. Generic
  316. Programming, Proceedings of ISSAC-88 and AAEC-6, Rome, Italy.
  317.  
  318.  
  319.    Proceedings of the Third Annual Workshop: Methods and Tools for
  320. Reuse , CASE Center, Syracuse University, June, 1990.
  321.  
  322.  
  323. Tracz, W.J., and Edwards, S. [1989]. Implementation Working Group
  324. Report.     Reuse In Practice Workshop , Software Engineering Institute,
  325. Pitt, Pa.
  326.  
  327.  
  328.  
  329. Tracz, W.J. [1990]    Formal Specification of Parameterized Programs
  330. in LILEANNA . Ph.D. Dissertation, Stanford University (to appear, 1992).
  331.  
  332.  
  333.  
  334. Uhl, J., and Schmid, H.A. [1990]    A Systematic Catalogue of
  335. Reusable Abstract Data Types , Lecture Notes in Computer Science ( 460),
  336. Springer-Verlag.
  337.  
  338.  
  339.  
  340.   About the Authors 
  341.  
  342. Larry Latour received his Ph.D. degree in Computer Science from Stevens 
  343. Institue of Technology in 1985.  He is an Associate Professor of Computer
  344. Science at the University of Maine, Orono, Me.  His research interests
  345. include database transaction systems, software engineering environments,
  346. and software reuse.  He developed a hypertext-based system, SEER, for
  347. describing the many views of a software component (usage,
  348. specification, and implementation), and he is currently
  349. interested in implementation architectures and their relation to
  350. the output of domain analyses.
  351.  
  352. Curtis Meadow received his M.S. degree in Computer Science from the
  353. University of Maine in 1990, and is currently a lecturer in the
  354. Computer Science Department at Maine.  His research interests include
  355. object oriented software development, programming languages
  356. and compilers, and software reuse.  His thesis examined aspects of 
  357. layered generic architectures discussed in this position paper.
  358.  
  359.  
  360.  
  361.  
  362.