Semantic component composition

Semantic Component Composition
Joseph R. Kiniry
Computing Science Department, University of Nijmegen Toernooiveld 1, 6525 ED Nijmegen The Netherlands kiniry@cs.kun.nl

Abstract. Building complex software systems necessitates the use of component-based architectures. In theory, of the set of components needed for a design, only some small portion of them are “custom”; the rest are reused orrefactored existing pieces of software. Unfortunately, this is an idealized situation. Just because two components should work together does not mean that they will work together. The “glue” that holds components together is not just technology. The contracts that bind complex systems together implicitly define more than their explicit type. These “conceptual contracts” describe essential aspectsof extra-system semantics: e.g., object models, type systems, data representation, interface action semantics, legal and contractual obligations, and more. Designers and developers spend inordinate amounts of time technologically duct-taping systems to fulfill these conceptual contracts because system-wide semantics have not been rigorously characterized or codified. This paper describes a formalcharacterization of the problem and discusses an initial implementation of the resulting theoretical system.

1 Introduction
Modern software systems are increasingly complicated. Combine new technologies, complex architectures, and incredible amounts of legacy code, and you have systems that no one can even partially comprehend. As complexity rises, code quality drops and system reliabilitysuffers. Building reliable complex systems necessitates the use of excellent software engineering practices and tools. But even with this bag of tricks, the modern software engineer is often overwhelmed with the technological problems inherent in building such complex systems. Most projects have to support multiple programming languages and models, deal with several different architectures (bothhardware and software), have distributed and concurrent subsystems, and must be faster, cheaper, and better than their competitors. What is worse, while these technological challenges are daunting, it is the non-technological issues that are often insurmountable. The widespread lack of system, design, and component documentation, ignorance about testing and quality assurance, and lack ofcommunication/knowledge across teams/companies, make for a very difficult working environment. The situation is further compounded by the social problems rampant in information technology: the Not-Invented-Here syndrome; issues of trust among companies, teams, and developers; developer education and motivation; and managerial and business pressures. 1.1 Semantic Components with Conceptual Contracts

Sincedevelopers of reusable constructs (like chunks of code or paragraphs of 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 and related problems, can help solve this “meaning-mismatch”. Itis our belief that if such a product were widely available and integrated into all aspects of system development, then our systems would be easier to build, better documented, and more robust. Put more plainly, our systems would be “more correct”. This paper aims to (1) provide a means by which components can be semantically (conceptually, formally) described, (2) present an algorithm whichautomatically determines when components can interoperate regardless of syntax or component model, and (3) describe the means by which the adapters necessary to compose such components can be automatically generated.

A component that is specified, manipulated, and reasoned about using this (or functionally similar) theory, tools, and techniques is what we call a semantic component. The theoretical...