Semantic Component Composition
Total Page:16
File Type:pdf, Size:1020Kb
Semantic Component Composition Joseph R. Kiniry Department of Computer Science California Institute of Technology Mailstop 256-80 Pasadena, CA 91125 [email protected] ABSTRACT General Terms Building complex software systems necessitates the use of specification languages, formal methods, kind theory, reuse, component-based architectures. In theory, of the set of com- glue-code generation, automatic programming, domain-specific ponents needed for a design, only some small portion of languages them are “custom”; the rest are reused or refactored existing pieces of software. Unfortunately, this is an idealized situ- 1. INTRODUCTION ation. Just because two components should work together Modern software systems are increasingly complicated. Com- does not mean that they will work together. bine new technologies, complex architectures, and incredi- ble amounts of legacy code, and you have systems that no The “glue” that holds components together is not just tech- one can even partially comprehend. As complexity rises, nology. The contracts that bind complex systems together code quality drops and system reliability suffers. implicitly define more than their explicit type. These “con- ceptual contracts” describe essential aspects of extra-system Building reliable complex systems necessitates the use of semantics: e.g., object models, type systems, data represen- excellent software engineering practices and tools. But even tation, interface action semantics, legal and contractual obli- with this bag of tricks, the modern software engineer is of- gations, and more. ten overwhelmed with the technological problems inherent in building such complex systems. Most projects have to Designers and developers spend inordinate amounts of time support multiple programming languages and models, deal technologically duct-taping systems to fulfill these concep- with several different architectures (both hardware and soft- tual contracts because system-wide semantics have not been ware), have distributed and concurrent subsystems, and must rigorously characterized or codified. This paper describes a be faster, cheaper, and better than their competitors. formal characterization of the problem and discusses an ini- tial implementation of the resulting theoretical system. What is worse, while these technological challengesare daunt- ing, it is the non-technological issues that are often insur- mountable. The widespread lack of system, design, and Categories and Subject Descriptors componentdocumentation, ignorance about testing and qual- D.1.0 [Software]: Programming Techniques—General; D.2 ity assurance, and lack of communication/knowledge across [Software]: Software Engineering; D.3.1 [Software]: Pro- teams/companies, make for a very difficult working envi- gramming Languages—Formal Definitions and Theory; D.3.4 ronment. The situation is further compounded by the so- [Software]: Programming Languages—Processors [prepro- cial problems rampant in information technology: the Not- cessors]; F.3.1 [Theory of Computation]: Logicsand Mean- Invented-Here syndrome; issues of trust among companies, ings of Programs—Specifying and Verifying and Reasoning teams, and developers; developer education and motivation; about Programs; F.4.1 [Theory of Computation]: Mathe- and managerial and business pressures. arXiv:cs/0204036v1 [cs.SE] 15 Apr 2002 matical Logic and Formal Languages—Mathematical Logic; F.4.3 [Theory of Computation]: Mathematical Logic and 1.1 Semantic Components with Formal Languages—Formal Languages Conceptual Contracts Since developers of reusable constructs (like chunks of code or paragraphsof documentation)can not say what they mean, there is a “meaning-mismatch”. This “information-impedance” muddles communication between collaborators as well as complicates composition between components. A new semantic theory, specifically designed to address this GCSE/SAIG ’02 2002 Pittsburgh, PA, USA and related problems, can help solve this “meaning-mismatch”. If is our belief that if such a product were widely available and integrated into all aspects of system development, then languages, especially for component specification and re- our systems would be easier to build, better documented, and use [23]; the automatic programming community, e.g, early more robust. Put more plainly, our systems would be more work by Barstow [3, 4] and Cleveland [7]; conceptual reuse correct. such as Castano and De Antonellis [5]; and last but certainly not least, the software transformation systems community, This paper aims to (1) provide a means by which compo- including the voluminous works of Biggerstaff and Batory. nents can be semantically (conceptually, formally) described, (2) present an algorithm which automatically determines when Much of this work is reviewed nicely in [8, 22, 24]. components can inter-operate regardless of syntax or com- ponentmodel, and (3)describe the means by which the adapters The primary difference between all of these formalisms and necessary to compose such components can be automatically systems and ours is that our system has a broad, firm theo- generated. retic foundation. That foundation, kind theory, was specif- ically designed to reason about reusable assets in an open A component that is specified, manipulated, and reasoned collaborative context. Thus, our work is not tied to a spe- about using this (or functionally similar) theory, tools, and cific language or realization, integrates the domains of reuse, techniques is what we call a semantic component. knowledge representation, automatic programming, and pro- gram transformation, and does so in a theoretical and sys- The theoretical foundation for this work is a new logic for tematic framework that supports global collaboration among describing open collaborative reusable assets called kind the- many participants. ory, which is described in full in Kiniry’s Ph.D. disserta- tion [15]. 2. SEMANTIC COMPOSITION Our proposal is, on the surface, relatively simple. Instead of 1.2 Related Work having only a syntactic interface to a component, we provide Various pieces of research from several communities has a higher-level semantic specification. Additionally, provid- similarities to this work. At its most simple, straightforward ing this semantic specification does not entail the need for structural subtyping can be used as a theoretical framework a developer to learn any new heavyweight specification lan- for semantic composition, especially in strongly typed lan- guage, theory, or tools. guages; e.g., Muckelbauer’s work in distributed object-based systems [20]. The problem with this approach is that only The key to this new solution is the notion of semantic com- renaming and reordering operations are possible, and little patibility [16]. Components are described explicitly and im- theoretical infrastructure supports reasoning about the full plicitly with lightweight, inline, domain-specific documen- semantics of components. tation extensions called semantic properties. These proper- ties have a formal semantics that are specified in kind theory Stronger theoretical formalisms exists for specifying and rea- and are realized in specific programming languages and sys- soning about such compositional systems; for example, the tems. recent work of Molina-Bravo and Pimentel [19]. But such work is far from being practically applicable in the near fu- When used in tandem with a computational realization of ture as there is no strong connection with real programming kind theory (called a kind system), these semantic compo- languages, software engineering methods, and no tool sup- nents are composed automatically through the generation of port. “glue” code, and such compositions are formally validated. Other expressive formalisms for compositionality exist, pri- 3. A BRIEF OVERVIEW OF marily in the category theoretic domain [9]. This work is KIND THEORY starting to see real application as Fiadeiro has moved into a Kind are classifiers used to describe reusable assets like pro- more industrial role in promoting this technology. gram code, components, documentation, specifications, etc. Instances are realizations of kind—actual embodiments of Work at CMU by Yellin and Strom, inspired by the prob- these classifiers. For example, the paperback “The Portrait lems with the Aesop system [11], has covered this territory before in the context of object protocols and weak, non- of the Artist as a Young Man” by James Joyce is an instance of kinds PAPERBACKBOOK and ENGLISHDOCUMENT, (and formal semi-automatic adapter construction [27, 28]. The perhaps others). We write this as work has a very ad hoc feel, even after the development of a formal model for such architectures [2]. We plan on using this model as a motivating example for the evolution of our own design language, Extended BON [14]. Portrait : PAPERBACKBOOK ⊕ ENGLISHDOCUMENT In a Java context, Wang et al proposedan service-eventmodel with an ontology of ports and links, extending the JavaBeans We use kind theory to specify semantic properties because descriptor model [26]. it provides us with an excellent model-independent (i.e., it is not bound to some specific programming language) reuse- Other related work comes from the areas of: domain-specific centric formalism. 3.1 Structure symbols that we use for equivalence are ≡ and ≖, and the Kinds are described structurally using our logic in a number related ⋖. of ways using several core operators. Classification is cov- ered with the inheritance operators < and <p; structural re- Equivalence is a context-sensitive relation.