arXiv:cs/0204036v1 [cs.SE] 15 Apr 2002 rmigLanguages— gramming to.Js eas w components sit two idealized because an is Just of this portion Unfortunately, ation. existin refactored small software. or reused some of are pieces only rest the design, “custom”; are a them for com of needed set of the ponents of use theory, the In architectures. necessitates component-based systems software complex Building ABSTRACT [ ooy h otat htbn ope ytm together systems complex bind tech- just that implicitly not contracts is The together components nology. holds that “glue” The .. [ D.1.0 Descriptors Subject and Categories system. theoretical resulting ini the an of discusses implementation and tial problem the describes of paper characterization This formal codified. been or not characterized have rigorously semantics conce system-wide because these contracts fulfill tual to time systems of duct-taping amounts technologically inordinate spend developers and Designers more. contractual and and gations, legal represe semantics, data action systems, interface type tation, models, object e.g., semantics: contracts ceptual [ osntma htthey that mean not does esr] .. [ F.3.1 cessors]; .. [ F.4.3 bu Programs about Programs— of ings aia oi n omlLanguages— Formal and Logic matical CESI ’02 GCSE/SAIG Languages— Formal Software Software hoyo Computation of Theory Software en oeta hi xlcttp.Tee“ These type. explicit their than more define :Sfwr niern;D31[ D.3.1 Engineering; Software ]: :PormigLanguages— Programming ]: 02Ptsug,P,USA PA, Pittsburgh, 2002 hoyo Computation of Theory .. [ F.4.1 ; :PormigTechniques— Programming ]: ecieesnilapcso extra-system of aspects essential describe ” pcfigadVrfigadReasoning and Verifying and Specifying omlLanguages Formal omlDfiiin n Theory and Definitions Formal will hoyo Computation of Theory eatcCmoetComposition Component Semantic oktogether. work :Mteaia oi and Logic Mathematical ]: should ahmtclLogic Mathematical Processors :Lgc n Mean- and Logics ]: Software eateto optrScience Computer of Department aionaIsiueo Technology of Institute California oktogether work General :Mathe- ]: aaea A91125 CA Pasadena, [prepro- oehR Kiniry R. Joseph [email protected] :Pro- ]: altp256-80 Mailstop D.3.4 ; D.2 ; obli- con- u- p- n- g a - - ; fi u eifta fsc rdc eewdl available widely were product a such if that belief our is “meaning-mismatc this If solve this help can address problems, to related designed and specifically theory, semantic new A as well components. as between composition collaborators complicates between communication muddles “information-impedan This mean, “meaning-mismatch”. they a what is say there not can cod documentation) of of chunks paragraphs (like or constructs reusable of developers Since with Components Semantic 1.1 pressures. business and motivation managerial and and education developer companies, developers; among and so- Not- trust teams, of the the issues by technology: syndrome; information compounded Invented-Here in further rampant envi- is problems working situation cial difficult The very a ronment. for make across and communication/knowledge teams/companies, of design, lack and system, assurance, qual insur ity of and often testing lack about are ignorance widespread documentation, that component The issues non-technological the mountable. is dau it are challenges ing, technological these while worse, is What competitors. their than better and cheaper, faster, be ae,hv itiue n ocretsubsystems, concurrent so and and distributed have hardware to ware), (both deal have architectures models, different projects several and with Most languages programming systems. multiple complex support inherent of- such is problems building engineer technological in software the modern with the overwhelmed tricks, ten of ev bag of But this use tools. with and the practices necessitates engineering software systems excellent complex reliable Building rises, complexity suffers. reliability As no system that and drops comprehend. systems quality have partially code you even and can code, one legacy incredi of and amounts architectures, ble complex technologies, new Com bine complicated. increasingly are systems software INTRODUCTION Modern 1. languages domain-spe programming, automatic reus generation, theory, glue-code kind methods, formal languages, specification Terms General ocpulContracts Conceptual and must ft- en e, cific nt- e - - ; ce” h”. - - 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 library science where researchers have Composition is a constructive operation—its result is a new developed several classification schemas for books: e.g., the thing that has some of the properties of its constituent pieces. Library of Congress and the Dewey Decimal Systems. The semantics of the specific composition operation used dictates the properties of the new construct. We define a Some forms of subtyping and inheritance in modern for- generic semantics to which all composition operations must malisms and programminglanguages are sometimes also kinds at least adhere. The symbols we use for composition are ◦, of inheritance (they are not when they have nothing to do ⊗, and ⊕. We read M ◦ N as M composed with N. with semantic conformance). Any constructive operation is composition. A father putting together the parts of a bicycle on Christmas Eve is perform- 3.2.2 Inclusion ing a type of composition; the composition of bicycle parts Inclusion is a relation that holds between two constructs, the to make a bike. The cat command in UNIX systems is an- whole and the part. A part is a portion of the whole. We other example of composition; this time, of two byte streams. use the term has-a to connote inclusion. The basic symbols that we use for inclusion are ⊂p and ⊃ to connote structural containment. 3.2.5 Realization As mentioned earlier, an instance I realizes a kind K. Re- Consider this document. We can hierarchically decompose alization is the process of stating that a specific thing is an its entire physical structure in a variety of differentways. For instance of a specific kind. If I is an instance of a kind K, example, syntactically, letters make up words, words make we say I realizes K, or I is an instance of K, or even I is up sentences, sentences make up paragraphs, etc. Thus, para- of kind K. We use the symbol : for realization. The choice graphs have sentences and, specifically, a given paragraph of symbol comes from the colon character’s use in program- has-a particular sentence. ming languages and type theory.

Inclusion is also a reflexive, transitive, asymmetric opera- Realization is the kind theory peer to typing. When one tion. states “let Z be a variable of type integer”, a type is be- ing assigned to the symbol Z. Likewise, when we state Z INTEGER we are kinding the symbol Z as having the 3.2.3 Equivalence : kind INTEGER. Equivalence is a relation that holds between constructs that are the “same” in some context. Two constructs are equiv- alent if they are similar for one or more reasons. The basic 3.2.6 Interpretation Interpretation is the process of evaluatinga constructin some context, translating it from one form to another. The sym- Table 1: Relevant Rules. bols that we use for interpretation are ֒→ and ❀. We read A (*K ֒→ L as the partial interpretation kind from kind K to (Parent Interp C Γ,L ❀ K, K ֒→ L ⊢ Φ Γ ⊢ K

3.2.7 Canonicality 3.4 Semantics Associated with every kind K is a full interpretation function Semantics are specified in an autoepistemic fashion using [], read as“canonical”. Given a kind (instance) it returns the what are called truth structures. Truth structures come in canonical form of that kind (instance). The canonical form two forms: claims and beliefs. of a canonical form is itself. Claims are stronger than beliefs. A mathematically proven If we have a term of the form [k] = l we call the asset l statement that is widely accepted is a claim. This phrasing the canonical kind of k. Likewise, for instances, we use the is used because, for example, there are theorems that have a term canonical instance. When we do not distinguish kind preliminary proof but are not yet widely recognized as being or instance, we say canonical realization or canonical asset. true.

Canonicality preserves all structure of its domain and, since A statement that is universally accepted, but not necessarily the codomain is generative (it is constructed entirely by the mathematically proven, is also a claim. Claims are not nec- canonicality operation), then it can have no new structure. essarily mathematical formulas. The statement “the sun will This means that it is possible to define a full interpretation rise tomorrow” is considered by the vast majority of listeners between any two canonically equivalent assets, but not nec- a true and valid statement, and thus is classified as a claim essary that such interpretations exist. rather than as a belief.

Thus, canonicality induces an equivalence relation; interpre- Beliefs, on the other hand, range in surety from completely tations do not. unsure to absolutely convinced. No specific metric is defined for the degree of conviction, the only requirement placed on 3.3 Rules the associated belief logic is that the belief degree form a partial order. The most importantrules of kind theory in the contextof this paper are summarized in Table 1. The gamma in these rules is an explicit context of sequents (kind theory sentences). Φ 4. SEMANTIC PROPERTIES Semantic properties are domain-independentdocumentation the Java virtual machine through the use of a monitor object constructs with intuitive formal semantics that are mapped attached to the Debug class. into the semantic domain of their application. We use the term “semantic properties” because they are properties (as Existing tools already use these properties. Some translate in property-value pairs) which have formal semantics. specifications, primarily in the form of contracts, into run- time test code. Reto Kramer’s iContract [18], the University Semantic properties are used as if they were normal semi- of Oldenburg’s Semantic Group’s Jass tool, Findler and Fel- structured documentation. But, rather than being ignored by liason’s contract soundness checking tool [10], and Kiniry compilers and development environments as comments typ- and Cheong’s JPP [17] are four such tools. Other tools trans- ically are, they have the attention of augmented versions of late specifications into structured documentation. Javadoc such tools. Semantic properties embed a tremendous amount and its relatives are examples of such tools. of concise information wherever they are used without im- posing the overhead inherent in the introduction of new lan- 4.2 Kinding with Semantic Properties guages and formalisms for similar purposes. Semantic properties are used in kinding an instance (e.g., a Our current set of semantic properties are listed in Table 2 in method, a class, a type) in the following fashion. We do the appendix of this article, and are specified in full detail in not have the space to fully detail the related theory and al- Kiniry’s dissertation [15]. To explain their use, we will focus gorithm, but a detailed example should suffice is getting the on particular enabling aspects of kind theory and provide a idea across. We’ll focus exclusively on kinding the above few examples of their use. Java method to this end.

When used in a particular language, semantic properties are The kind of this method contains much more information realized using appropriate domain-specific extensions. We than its type. First, the kind contains everything we have al- have integrated their use into the Java and Eiffel program- ready discussed with respect to the method’s signature. Ad- ming languages, as well as in the BON specification lan- ditionally, a semantic interpretation of all of the documen- guage [21, 25], through a process that we call semantic em- tation attached to the method is included. And, as a final bedding. element, a more complete representation of its type is also incorporated.

4.1 Java In more detail: Semantic properties are embeddedin Java code using Javadoc- style comments. This makes for a simple, parseable syntax. To give some flavor to semantic embedding, we’ll present a 1. All the information that is inherent in the explicit spec- small example of Java code using semantic properties. Here ification of the method’s signature and type are first is an example of such use, taken directly from one of our composed. projects that uses semantic properties [12]. We will call this particular instance Debug.isOff. With respect to classification, this construct is a Java method. /** This is encoded as * Returns a boolean indicating whether any debugging * facilities are turned off for a particular thread. AVA ETHOD * Debug.isOff : J M * @concurrency GUARDED * @require (thread != null) Parameters must be valid. * @modifies QUERY We interpret the method’s signature as follows: * @param thread we are checking the debugging condition * of this thread. Debug.isOff.ParameterSet ⊂p Debug.isOff * @return a boolean indicating whether any debugging ⊂ * facilities are turned off for the specified thread. Debug.isOff.ReturnType p Debug.isOff * @review kiniry - Are the isOff() methods necessary at all? **/

public synchronized boolean isOff(Thread thread) where { return (!isOn(thread)); Debug.isOff.ParameterSet : JAVAPARAMETERSET } Debug.isOff.Parameter0 ⊂p Debug.isOff.ParameterSet Debug.isOff.Parameter0 : JAVAPARAMETER The method isOff has a base specification, that of its Java Debug.isOff.Parameter0Type ⊂ Debug.isOff.Parameter0 type signature. It takes a reference to an object of type p ⊂ Thread and returns a value of base type boolean. But Debug.isOff.Parameter0Name p Debug.isOff.Parameter0 more than just its type signature is used by the Java compiler Debug.isOff.Parameter0Type : JAVATYPE and runtime. Additionally, it is a public method, thus any Debug.isOff.Parameter0Type ≡ java.lang.Thread client can invoke it, and it is synchronized, thus only a Debug.isOff.Parameter0Name : JAVAIDENTIFIER single thread of control can enter it, or any other synchro- nized method in the same containing class (called Debug), Debug.isOff.Parameter0Name ≡ thread at once. This computational access control is managed by ... etc ... Effectively, we reflectively encode all of the type and A SEMANTICCOMPONENT is akind thatcontainsboth PROVIDES signature information for the method in a kind theo- anda REQUIRES kinds. Each of these enclosed kinds speci- retic context. fies a set of kind which the component exposes, or on which The structureof the related kinds like JAVAPARAMETER it depends, respectively. This two substructures are a gener- encode the necessary structure that must be provided alization of the common exports and imports clauses of ar- by the interpretation, a type and a name in this case. chitecture description and componentspecification languages. Thus, this part of the process is no different than the parsing and typing that goes along with compiling the If we wish to determine the semantic compatibility of two method. instances we use the following formal definition. 2. All the supplementary information embedded via the use of the semantic properties and extra-type informa- DEFINITION 1 (SEMANTIC COMPATIBILITY). Let I and tion is also interpreted into a kind theoretic context. J be two semantic components. That is, For example, the fact that the method is declared as Γ, I : SEMANTICCOMPONENT,J : SEMANTICCOMPONENT ⊢⋄ having GUARDED concurrency semantics is encoded with the concurrent kind: Furthermore, I is part of the provisions of an enclosing se- ConcurrencySemantics0 ⊂p Debug.isOff mantic component CP , and J is part of the requirements of ConcurrencySemantics0 : JAVACONCURRENCYSEMANTICSan enclosing semantic component CR, ConcurrencySemantics0 ≡ GuardedSemantics Γ ⊢, I ⊂p P, P : PROVIDES, P ⊂p CP , J ⊂ R, R : REQUIRES, R ⊂ C ⊢⋄ Likewise, the method’s visibility, signature concurrency p p R (use of the synchronized keyword), side-effects (modifies), precondition, parameter and return value We say that P and R are semantically compatible if an inter- documentation, and meta-information (review) are also pretation exists that will “convert” R into the ontology of P , interpreted. that is if there is a R ❀ P in, or derivable from, the context Γ. 3. Finally, we interpret a more complete representation of the method’s type by taking advantage of the domain I and J are semantically equivalent if I ≖ J, of course. semantics of refinement. In this example, we attach stronger refinement semantics via the use of the speci- fied, explicit, classical contract. We can test for the existence of such an interpretation by The existence of the precondition means that, after we checking to see if the canonical forms of P and R struc- interpretsuch, we can: (a) Check that overriddenmeth- turally contain each other. ods properly weaken the precondition for behavioral subsumption. (b) Interpret such specification into run- THEOREM 1 (SEMANTIC COMPATIBILITY CHECK). time test code—here that entails just a literal insertion of the code snippet into the proper place(s) in a rewrit- Γ, [R] ⊂p [P ] ⊢ R ❀ P ten version of the method. (c) Use this behavioral spec- ification as a guard in semantic composition (see be- The proof of this theorem is straightforward. If R ⊂ P low). [ ] p [ ] then [P ] ⊃ [R] (by definition of these operators), and thus by the rule (Partial Equiv*), P ⋖ R. By the definition of The kind of this method is our formal “best-effort” at the partial equivalence, when P ⋖ R, a full interpretation exists specification of its semantics. Now, the rules of kind and that takes P to R; that is, P ❀ R. This full interpretation is instance composition come into play with respect to defining exactly the “conversion” operator that we are looking for to semantic compatibility. guarantee semantic compatibility. 5. COMPONENT KIND Finally, we say that I and J can be semantically composed Two instances (e.g, objects) are compatible if they can inter- if: (a) they are semantically compatible, and (b) their com- operate in some fashion correctly and in a soundmanner. For position is realizable within their instance domain. example, the two objects can perform their intended roles in an interactive manner and the composition of the two objects This realization within their instance domain is the “glue” is as correct as the two objects when analyzed individually. code on which we depend for composition. We call this con- struct a semantic bridge. Put another way, a semantic bridge An object O is a realization of a semantic component, that is a chain of equivalencesbetween two instances that ensures is, O : SEMANTICCOMPONENT, if it provides sufficient in- their contextual base equivalency. formation via semantic properties that a kind system can in- terpret its structure into a predefined kind. That is to say, 6. EXAMPLES this “parsing” step is an interpretation to some K which is a All the examples below are defined independently of source semantic component. object language and ignore the subtle problems of class and type versioning that are solved in the full system and are not These maps, when used in composition, define a simple re- described here. These are only illustrative, not prescriptive, naming (sort of an alpha-renamingfor instances) for the classes. examples. We can realize such a renaming either by directly manipu- lating the source text (if this is permissible in the current Finally, the “tight” coupling demonstrated below is theo- context), or by generating a simple wrapper class automati- retically equivalent to the more dynamic coupling found in cally. Thus, an adapter which maps calls from writeDate loosely typed systems. The same rules and implications hold to setDate and from readDate to getDate will allow in such an architecture. the composition of these two classes to perform correctly. Some of the following examples will use the following type: 6.2 Extended Object Semantic Compatibility The above example is based on a simple syntactic difference Type DateType between two classes. Here is a more complex example. method setDate(day: Integer; month: Integer; year: Integer); Consider the following two classes. method getDate(); EndType Class ISODate -- requires: year > 1970 method setDate(year: Integer; Before examining these examples, take note that if two classes month: Integer; are class or type compatible, they are obviously semantically day: Integer); compatible. method getDate(): ISODate; EndClass 6.1 Standard Object Semantic Compatibility Class SetDate Class Date -- requires: year > 0 method setDate(day: Integer; callmethod setDate(day: Integer; month: Integer; month: Integer; year: Integer); year: Integer); method getDate(); EndClass end; Class SetDate To compose an instance of SetDate with an instance of callmethod writeDate(day: Integer; ISODate, we have to (a) negotiate the reordering of the month: Integer; setDate year: Integer); parameters of the method, and (b) check the be- callmethod readDate(); havioral conformance of the composition. end; This reordering is just another simple form of the above alpha-renaming because the structural operators in kind the- The methods tagged with the callmethod keyword are ory (⊂p and ⊃) are order-independent. The behavioral con- ⇒ part of the REQUIRES of the class; those tagged with the formance is verified because year > 1970 year > 0. method keyword are part of the PROVIDES part. Thus, we can again automatically generate the appropriate These classes are not type compatible since their outbound code to guarantee semantic compositionality. and inbound interfaces are of two different types (Date- Type and some newtype; lets callit AnotherDateType). 6.3 Ontological Semantic Compatibility Our final example is an example of a solution that would If the only difference between the methods setDate and rely more strongly upon ontology-based semantic informa- writeDate is exactly their syntax, then these classes are tion encoded in kind theory. semantically compatible. Consider the following classes. This mapping exists because both of these classes realize the same kind, that of DATE. We know this fact because at some point a developer defined this ontology by virtue of a Class ISODate claim or a belief on the classes. Such a truth structure could method setDate(year: Integer; month: Integer; have been defined explicitly through the specification of a day: Integer); semantic property (realizes) on the classes, via manipulation method getDate(): ISODate; in the development environment, or by direct input with the EndClass kind system. Class OffsetDate method setDate(days_since_jan1_1970: Now, because Date : DATE, then a mapping exists from each Integer); of its parts (e.g., the setDate method) to each of the parts method getDate(): OffsetDate; of the kind (the canonical SETDATE kind feature). EndClass Assume that the parameter days since jan1 1970 was cation with an existing specification as a testing ground for annotated with a reference to a kind that described days - automatic generation of glue code for a variety of interface since jan1 1970 meant. The context of such a descrip- modalities. In the end, we would like to be able to use se- tion would necessarily have to have a ground— a common, mantic components as a kind of “Uber-IDL”,¨ and generate base understanding that is universal. glue code that utilizes a large variety of equivalent commu- nication substrates, both at compile and run-time. In this case, the ground element is the notion of a day. The relationship between the parameter days since jan1 - Abstracting that component-based architecture, particularly 1970 and the day ground element need be established. with a view toward component quality-of-service, has al- ready been finished. The result of which is what we call This relationship might be constructed any of a number of the Connector Architecture, inspired by Allen and Garlan’s correct, equivalent manners. For example, a direct inter- similar work [1], and will be described in a forthcoming pa- pretation from the triple year/month/day to days since - per. jan1 1970 would suffice. 8. CONCLUSION Or perhaps a more complicated, multistage interpretation We have shown that, using kind theory, we can use the same would be all that is available. For example, the composi- formalism to describe software components, reason about tion of interpretations from year to month, then month to their composition, and generate verifiable “glue” code for day, then day to days since jan1 1970, would provide their composition. These specifications come in the form of enough information for the generation of a semantic bridge. simple domain-independent annotations to typical program code, and such annotations are also used for documentation This composition of interpretations is automatically discov- and testing purposes. ered and verified using the semantic compatibility theorem via the rewriting logic-based component search algorithm of kind theory. 9. ACKNOWLEDGMENTS This work was supported under ONR grant JJH1.MURI- 7. IMPLEMENTATIONS 1-CORNELL.MURI (via Cornell University) “Digital Li- The earliest implementation of this research was done by braries: Building Interactive Digital Libraries of Formal Al- a student (Roman Ginis) working with the author in 1998. gorithmic Knowledge” and AFOSR grant JCD.61404-1-AFOSR.- We used the Boyer-Moore theorem prover (Nqthm) to hand- 614040 “High-Confidence Reconfigurable Distributed Con- specify the above examples (and more) and prove semantic trol”. compositionality. Glue code was also written by hand to see what steps were necessary, in typical structured languages, 10. REFERENCES for realizing the resulting interpretations. [1] R. Allen and D. Garlan. Beyond definition use—architectural interconnection. ACM SIGPLAN We have now developed the theoretical infrastructureto com- Notices, 29(8):35–44, 1994. pletely describe the semantic components and reason about [2] Robert Allen and David Garlan. A formal basis for their composition. We also have a realization of the theory architectural connection. ACM Transactions on in a kind system implemented in SRI’s Maude logical frame- Software Engineering and Methodology, work [6]. Currently, the realization of renaming, reordering, 6(3):213–249, July 1997. and simple interpretations is direct: it is snippets of Java pro- gram code that are explicit realizations of the corresponding [3] D.R. Barstow. An experiment in knowledge-based interpretation. automatic programming. Artificial Intelligence, 12(2):73–119, 1979. Our next step is to “lift” these examples into a general con- text, automatically generating code in a variety of contexts, [4] D.R. Barstow. Domain-specific automatic rather than just using pre-written, parameterized glue code. programming. IEEE Transactions on Software Engineering, 11(11):1321–1336, November 1985. To this end, we have developed a distributed component- based web architecture called the Jiki [13] for use as a test- [5] S. Castano and V. De Antonellis. A constructive bed of semantic compositionality. The Jiki’s components approach to reuse of conceptual components. In are distributed JavaBeans, and they interact via a number of Proceedings of the Second International Workshop on technologies including local and remote method calls, mes- Software Reusability, pages 19–28, 1993. sage passing via HTTP and other protocols, and a tuple- [6] Manuel Clavel, Steven Eker, Patrick Lincoln, and Jos´e based coordination mechanism based upon Jini’s JavaSpaces. Meseguer. Principles of maude. In In Proc. 1st Intl. Workshop on Rewriting Logic and its Applications, These components have already been specified with both the Electronic Notes in Theoretical Computer Science. Extended BON [14] specification language as well as our Elsevier Science, Inc., 1996. semantic properties in their program code. [7] J.C. Cleaveland. Building application generators. Thus, our next step is to use this example, complex appli- IEEE Software, 5(4):25–33, July 1988. [8] Liesbeth Dusink and Jan van Katwijk. Reuse [22] H. Partsch and R. Steinbruggen. Program dimensions. In Proceedings of SSR ’95, Seattle, WA, transformation systems. ACM Computing Surveys, 1995. 15(3):199–236, September 1983. [9] J.L. Fiadeiro and T. Maibaum. A mathematical [23] Dewayne E. Perry. Software evolution and ‘light’ toolbox for the software architect. In Proceedings of semantics. In Proceedings of ICSE ’99, Los Angeles, The Eighth International Workshop on Software CA, 1999. Specification and Design (IWSSD8 - ’96), 1996. [24] C. Rich and R.C. Waters. Automatic programming: [10] R. Findler and M. Felleisen. Contract soundness for Myths and prospects. IEEE Computer, 21(8):40–51, object-oriented languages. In Proceedings of Sixteenth August 1988. International Conference Object-Oriented Programming, Systems, Languages, and Applications, [25] Kim Wald´en and Jean-Marc Nerson. Seamless 2001. Object-Oriented Software Architecture - Analysis and Design of Reliable Systems. Prentice-Hall, Inc., 1994. [11] David Garlan, R. Allen, and John Ockerbloom. Architectural mismatch, or, why it’s hard to build [26] Guijun Wang, Liz Ungar, and Dan Klawitter. systems out of existing parts. In International Component assembly for oo distributed systems. IEEE Conference on Software Engineering. IEEE Computer Computer, 32(7):71–78, July 1999. Society, IEEE Computer Society, May 1995. [27] Daniel M. Yellin and Robert E. Strom. Interfaces, [12] Joseph R. Kiniry. IDebug: An advanced debugging protocols, and the semi-automatic construction of framework for Java. Technical Report CS-TR-98-16, software adaptors. In Proceedings of OOPSLA ’94, Department of Computer Science,California Institute October 1994. of Technology, November 1998. [28] D.M. Yellin and R.E. Strom. Protocol specifications [13] Joseph R. Kiniry. The Jiki: A distributed and component adaptors. ACM Transactions on component-based Java Wiki. Available via Programming Languages and Systems, 19(2), 1997. http://www.jiki.org/, 1998. APPENDIX [14] Joseph R. Kiniry. The Extended BON tool suite. A. SEMANTIC PROPERTIES SUMMARY http://ebon.sourceforge.net/, 2001. Table 2: The Full Set of Semantic Properties [15] Joseph R. Kiniry. Formalizing Open, Collaborative Reuse with Kind Theory. PhD thesis, California Meta-Information: Contracts Versioning Institute of Technology, 2002. author ensure version [16] Joseph R. Kiniry. Semantic properties for lightweight bon generate deprecated specification in knowledgeable development bug invariant since environments. Submitted for publication, 2002. copyright modifies Documentation description require design [17] Joseph R. Kiniry and Elaine Cheong. JPP: A Java history Concurrency equivalent pre-processor. Technical Report CS-TR-98-15, license concurrency example Department of Computer Science,California Institute title Usage see of Technology, November 1998. Dependencies param Miscellaneous references return guard [18] Reto Kramer. iContract–the Java design by contract use exception values tool. In Proceedings of the Twenty-Fourth Conference Inheritance Pending Work time-complexity on the Technology of Object-Oriented Languages hides idea space-complexity (TOOLS 24), volume 26 of TOOLS Conference Series. overrides review IEEE Computer Society, 1998. realizes todo [19] J.M. Molina-Bravo and E. Pimentel. Composing programs in a rewriting logic for declarative programming. Technical Report LO/0203006v1, Dpto. Lenguajes y Ciencias de la Computaci´on, University of M´alaga, March 2002. [20] Patrick A. Muckelbauer. Structural Subtyping in a Distributed Object System. PhD thesis, Purdue University, 1996. [21] Jean-Marc Nerson. Applying object-oriented analysis and design. Communications of the ACM, 35(9):63–74, September 1992.