To Appear, ACM Transactions on Software Engr. and Methodology, October 1992.The Design and Implementation of HierarchicalSoftware Systems With Reusable Components†Don Batory and Sean O’MalleyDepartment of Computer SciencesThe University of TexasAustin, Texas 78712AbstractWe present a domain-independent model of hierarchical software system designand construction that is based on interchangeable software components and large-scale reuse. The model unifies the conceptualizations of two independent projects,Genesis and Avoca, that are successful examples of softwarecomponent/building-block technologies and domain modeling. Building-blocktechnologies exploit large-scale reuse, rely on open architecture software, andelevate the granularity of programming to the subsystem level. Domain modelingformalizes the similarities and differences among systems of a domain. Webelieve our model is a blue-print for achieving software component technologiesin many domains.Keywords: software building-blocks, domain modeling, open system architec-tures, reuse, software design.†This research was supported in part by a grant from Texas Instruments.-2-1. IntroductionMature engineering disciplines rely heavily on well-understood technologies that havebeen standardized. By purchasing off-the-shelf components, engineers can create custom-ized systems economically by building only the parts that are application-specific. Unneces-sary reinvention of technology is thereby avoided.Contemporary software systems have been simple enough for massive technology rein-vention to be economically feasible. However, as software system complexity increases,technology reinvention becomes unaffordable. There are many domains today that are tech-nologically stable and ripe for standardization. Certainly there will be more in the future.Many domains will concern hierarchical systems, where a progression of increasingly moresophisticated software technologies are layered upon each other.A classical, but largely unrealized, goal of software engineering is software component(building-block) technologies. Such technologies are envisioned to exploit large-scale reuse,leverage off of open-architecture designs, and elevate the granularity of programming to thesub-system level [SEI90]. It is believed that software component technologies can beachieved through domain analysis, an effort to formalize the similarities and differencesamong systems of a mature and well-understood domain [Pri91].Our interest in component technologies and domain analysis has arisen from ourinvolvement in two independent projects: Genesis and Avoca. Genesis is the first building-blocks technology for database management systems [Bat85-91a]. Using a graphical layouteditor, a customized DBMS can be specified by composing prefabricated software com-ponents. A university-quality (e.g., University Ingres) DBMS - over 70,000 lines of C - canbe produced and running within twenty minutes. Avoca is a system for constructing efficientand modular network software suites using a combination of pre-existing and newly createdcommunication protocols [OMa89-90c]. Protocol suites are expressed as a graph of prefabri-cated protocol components. The graph is loaded into a communications kernel (the xkernel[Hut91]) and executed. Genesis and Avoca are successful examples of both software com-ponent technologies and domain modeling.When we compared Genesis and Avoca, we were amazed at the similarities in theirconceptual design, organization, and implementation. We concluded that the similaritieswere not accidental, but were intrinsic to building-block technologies.This paper reports our efforts to unify the conceptualizations of Genesis and Avoca.We present a domain-independent model of hierarchical software system design and con-struction that is based on interchangeable software components and large-scale reuse. A keyfeature of this model, and our most novel contribution, is recognition of the fundamental roleof symmetric components in large scale reuse; these components have the unusual propertythat they can be composed in virtually arbitrary ways. We demonstrate the practicality ofour model by using it to describe accurately the systems that we have built.Our model is actually a meta-model of large scale system construction, which webelieve can be used to define models of open architectures for many different domains. Wedo not present a methodology for modeling a domain in terms of the meta-model; that is farbeyond the scope of this paper and is the subject of ongoing work [Bat91b].Our work affirms and extends basic insights of many pioneers in software engineering:the software families and abstract interface concepts of Parnas [Par79], parameterized types-3-of Goguen [Gog84], hierarchical system designs of Habermann [Hab76], object-orientationof Goldberg [Gol84], and the frameworks concept of Deutsch [Deu89].We begin by explaining the superstructure of large scale systems and its relationship tothe design of open-architecture software.-4-2. The Structure of Large Scale Software SystemsThe structure of large scale software systems can be modeled by an elementary notationthat reflects the obvious fact that systems are designed as assemblies of components and thatcomponents fit together in very specific ways. The model postulates that components areinstances of types and components themselves may be parameterized. The ways in whichcomponents fit together to form systems is captured elegantly through the use of typedparameters and typed expressions. We start with a presentation of the model framework andits notation. We then demonstrate the model’s generality by reviewing the domain models ofGenesis and Avoca, and give some insights into the problems of contemporary software sys-tems.2.1 The Model Framework and NotationBasics. A type is a set of values. An abstract data type (ADT) is a type plus operationson the values of the type. A class is an ADT that belongs to an inheritance lattice [Car85].A component is a closely-knit cluster of classes that act as a unit [Teo86].Normally, the values of a type are simple (e.g., numbers, strings, etc). When valuesbecome complex entities, different names (other than ‘type’) are generally used. For exam-ple, a set of types is called a meta-type. A set of ADTs is called a type class [Wad89] and aset of classes is a theory [Gog84, Gra91]. We will call a set of components a realm. Notethat meta-types, type classes, theories, and
View Full Document
Unlocking...