arXiv:cs/0204035v1 [cs.SE] 15 Apr 2002 rmigLanguages— gramming FSE-10 documen- reuse, reuse specification tation theory, kind methods, formal langua specification properties, semantic documentation, Terms General Languages Formal putation Languages— figadVrfigadRaoigaotPrograms about Reasoning [ and Verifying and ifying Languages— Computation [ .. [ D.1.0 Descriptors Subject and Categories reuse for method formal new a theory. with kind code called specified program is in tools, realization its via and use between property’s as well semantic relation- as levels, refinement specification The these between domain. ships fo problem and the language, natural within precise mally specified with loosely themselves levels: are two properties at Semantic transfor- source-code tools. and mation documentation of maintenan use and the system through testing, in of implementation, advantage design, taken se- analysis, are richer properties with language These existing mantics. an augment con- to specification used structs domain-specific are properties Semantic ABSTRACT cations [ hoyo Computation of Theory Software Software 02Calso,SuhCrln,USA Carolina, South Charleston, 2002 Software eatcPoete o ihwih pcfiainin Specification Lightweight for Properties Semantic dsg agae] .. [ D.3.4 languages]; [design :Mteaia oi n omlLanguages— Formal and Logic Mathematical ]: :Sfwr niern;D31[ D.3.1 Engineering; Software ]: :PormigLanguages— Programming ]: ahmtclLogic Mathematical Processors :Lgc n ennso Programs— of Meanings and Logics ]: nwegal eeomn Environments Development Knowledgeable :PormigTechniques— Programming ]: omlDfiiin n Theory and Definitions Formal percsos;F31[ F.3.1 [preprocessors]; :Mteaia oi n Formal and Logic Mathematical ]: .. [ F.4.3 ; Software agaeClassifi- Language hoyo Com- of Theory Software :Programming ]: eateto optrScience Computer of Department aionaIsiueo Technology of Institute California General hoyof Theory aaea A91125 CA Pasadena, oehR Kiniry R. Joseph [email protected] :Pro- ]: F.4.1 ; altp256-80 Mailstop Spec- D.3.2 ; D.2 ; ges, ce r- a is,te r ayt er,snete eestt nya only necessitate they since learn, in to change easy small are they First, features. key simple two more share they significantly CWEB, are original Knuth’s systems than these of most While overlap. some with thirty-five, another reports i rjcswt Jvdc ntepoetsmay FreshMe summary. project the in “Javadoc” SourceForge with projects six Doxy- HeaderDoc. Apple’s Alexandria, and Jakarta’s gen, including volume in Other followed have interest tool. tools Javadoc primed the code-to-documentationtransformation Java similar via use of comment popularity semi-structured and in flourishing. adoption is rapid comments The semi-structured of ecology an tradition 18], programming literate the in tools lightwei documentation of popularization and adoption the with Recently, than worse all. is at comment comment incorrect no an mantra: common focu the the for are They out-of-date. extra- become other efforts, development or doc- process, by rigorous maintained specialists, well umentation unless comments, these rot time, “bit Over exhibit rapidly comments program such Invariably, lan- natural specification. that unstructured formal into and completely guage fall between usually region comments and gray These developers system maintainers. other future to ex- convey knowledge to programmer is annotations tra these programming of of purpose to invention The used the languages. been since have code conventions program local annotate and constructs hoc INTRODUCTION Ad 1. eti tl sol teghndb h xiiins nat exhibitionist the by documentation- strengthened This only is format. automatically-generate style page centric attractive web the a in of the documentation enjoy use programmers and Sun, like creation vendors of example Prompted the engendered. by is documentation of culture a Second, tools these use, or to tool, barrier complex actually significant language, other new some a imposing learn to programmer the 2 1 http://www.freshmeat.net/ http://www.sf.net/ reward convention h rgamrfrdcmnighrcode. her documenting for programmer the and process ahrta forcing than Rather . 1 eot thirty- reports mile since ure [17, ght ”. d s at 2 of the Web. Having the most complete documentation is 2.1 Documentation Semantics now a point of pride in some Open Source projects; a state Recently, Sun has started to extend the semantics of these of affairs we would not have guessed at a decade ago. basic properties with respect to language semantics, particu- larly with regards to inheritance. If a class C inherits from a The primary problem with these systems, and the documen- parent class P , and P ’s method m has some documentation, tation and code written using them, is that even semi-structured but C’s overridden or effective (in the case where P and/or comments have no semantics. Programmers are attempting m is abstract) version of m does not, then Javadoc inherits to state (sometimes quite complex) knowledge but are not C.m’s documentation for P.m, generating the appropriate given the language and tools with which to communicate comments in Javadoc’s output. this knowledge. And since the vast majority of developers are unwilling to learn a new, especially formal, language This change in behavior of the tools is an implicit change in with which to convey such information, we must look for the semantics of the documentation. While straightforward a happy-medium of informal formality. and useful in this example, the meaning of such inheritance is undocumented and often unclear. That compromise, the delicate balance between informality and formality, and the lightest-weight aspect of our Knowl- The situation in Eiffel is less confusing. The semantics of edgeable Software Engineering program, is what we call se- properties, as realized by indexing clauses and formal pro- mantic properties. gram annotation via contracts, are defined in the language standard [23]. Semantic properties are domain-independent documentation constructs with intuitive formal semantics that are mapped Even so, no mechanism exists in either system for extending into the semantic domain of their application. Semantic prop- these semi-structured comments with new semantics beyond erties are used as if they were normal semi-structured docu- simple plug-ins for documentation (e.g., doclets in Java and mentation. But, rather than being ignored by compilers and translators in EiffelStudio). development environments as comments typically are, they have the attention of augmented versions of such tools. Se- Also, the semantics of current annotations are entirely spec- mantic properties embed a tremendous amount of concise ified within a particular language or formalism. No gen- information wherever they are used without imposing the of- eral purpose formalism has been used to express their extra- ten insurmountable overhead seen in the introduction of new model semantics. languages and formalisms for similar purposes. 2.2 Semantics of Semantic Properties We specify the semantics of semantic properties in a new 2. SEMANTIC PROPERTIES formalism called kind theory. Kind theory is a logic used to The original inspiration for semantic properties came from describe, reason about, and discover reusable assets of arbi- three sources: the use of tags, (e.g., @author and @param), trary sorts. Kind theory is an higher-order, autoepistemic4, in the Javadoc system, the use of annotations and pragmas paraconsistent5, categorical logic with a type theoretic and in languages like Java and C for code transformation and algebraic model, and is described in full detail in Kiniry’s guided compilation, and indexing clauses in Eiffel. All of dissertation [15]. these systems have a built-in property-value mechanism, one at the documentation level and one within the language syn- 2.2.1 A Brief Overview of Kind Theory tax itself, that is used to specify semi-structured information. Kind are classifiers used to describe reusable assets like pro- gram code, components, documentation, specifications, etc. In Java, tags are the basic realization of our semantic proper- Instances are realizations of kind—actual embodiments of ties. They are used for documentation and formal specifica- these classifiers. For example, the paperback “The Portrait tion, as we will discuss in more detail in Section 3.1.1. Tags of the Artist as a Young Man” by James Joyce is an in- are not part of the language specification. In fact, they are stance of kinds PAPERBACKBOOK, ENGLISHDOCUMENT, entirely ignored by all Java compilers. and others. Annotations and pragmas come in the form of formal tags 3 In the context of semantic properties, our kinds are the se- used for some Design by Contract tools like Jass which mantic properties as well as the programming language con- happen to be realized in Eiffel with first-class keywords like structs to which the properties are bound. Our instances are require, ensure, and invariant. the specific realizations of these kinds within a particular in- put structure, typically a programming or specification lan- Eiffel provides first-class support for properties via indexing guage. clauses. An Eiffel file can contain arbitrary property-value pairs inside of indexing blocks. This information is used Kinds are described structurally using our logic in a num- by a variety of tools for source code search, organization, ber of ways. Classification is covered with the inheritance and documentation. 4Auto-epistemic: “representing or discussing self-knowledge”. 5Paraconsistent: “explicitly representing and reasoning with poten- 3http://semantik.informatik.uni-oldenburg.de/ jass/ tial and transitory logic inconsistency”. operators < and

These kinds of inheritance come in two basic forms: re- We have started work on such environment. By extending placement and augmentation. powerful emacs modes and tools that are part of our ini- tial development environment (e.g., XEmacs coupled with The replacement form of inheritance means that the parent the object-oriented browser, hyperbole, JDE, semantic, and property is completely replaced by the child property. An speedbar) with a kind system, we hope to raise the bar on example of such semantics are feature overriding in Java and development environments. the associated documentation semantics thereof. 2.7.1 Current Work on KDEs We have used semantic extensions in two programming lan- The first two features that we plan to implement are docu- guages: Java and Eiffel. mentation inheritance and perspective. 3.1.1 Java Eiffel development environments contain tools that provide Semantic properties are embeddedin Java code using Javadoc- what are called the flat, short, and contract views of a class. style comments. This makes for a simple, parseable syn- Flat forms show the flattened version of a class—all inher- tax, and the kind composition of semantic properties to con- ited features are flattened into a single viewpoint. The short structs is simply realized by textual concatenation. form eliminates the implementation of all methods so that the developer can focus on a class’s interface. The contract Here is an example of such use, taken directly from one of form is like the short form except the contracts of the class our projects that uses semantic properties [12]. (feature preconditions and postcondition, and class invari- ants) are shown. These forms can be combined, thus flat short or flat contract forms have the obvious meanings. /** * Returns a boolean indicating whether any debugging * facilities are turned off for a particular thread. Knowledgeable documentation inheritance is an extended * version of such views. Rather than manually program the * @concurrency GUARDED semantics of the “flattening” operation, our formal specifica- * @require (thread != null) Parameters must be valid. * @modify QUERY tion in kind theory automatically interprets the appropriate * @param thread we are checking the debugging condition instances into a new form for rendering within the knowl- * of this thread. * @return a boolean indicating whether any debugging edgeable development environment. And because such in- * facilities are turned off for the specified thread. terpretations are often fully reversible, the flattened forms * @review kiniry Are the isOff() methods necessary at all? can be edited and the changes will properly “percolate” to **/ their original source locations. public synchronized boolean isOff(Thread thread) { Perspectives enable the user to specify which role(s) she is in return (!isOn(thread)); while interacting with the kind-enabled system. Since kind } theory is autoepistemic, the specification of a role (repre- sented by an agent within the theory) permits automatic “fil- Existing tools already use these properties for translating tering” of information according to, for example, visibility specifications, primarily in the form of contracts, into run- rules as discussed in Section 2.5. This user-centric filtering time test code. Reto Kramer’s iContract [19], the Univer- of information, much like narrowing modes within Emacs, sity of Oldenburg’s Semantic Group’s Jass tool, Findler and helps the user focus on the problem at hand, ignoring all in- Felliason’s contract soundness checking tool [5], and Kiniry formation that she either is not interested in, concerned with, and Cheong’s JPP [16] are three such tools. or should not see.

These are only two of our ideas for how to expose the user- 3.1.2 Eiffel centric aspects of kind theory via developmentenvironments, In Eiffel, as mentioned earlier, we use indexing clauses as incorporating the use of semantic properties throughout. well as regularly structured comments to denote semantic properties. Using comments as well as indexing clauses is 3. EMBEDDING SEMANTIC PROPERTIES necessary because the syntax of Eiffel dictates that indexing clauses only appear at the top of a source file. The syntax When a semantic property is bound to a particular instance, of comments that use semantic properties is identical to that for example, an @author tag is used in some Java source of indexing clauses, thus the same parser code can be used code, what does this formally mean beyond questions of in both instances. An example of such use is as follows, structural conformance? How do these semantic properties directly from one of our Eiffel-based projects that uses se- help guide the development process and exercise the system mantic properties [14]. during testing? How do new tools take advantage of these properties? indexing First, we have to embed the semantic properties into the lan- description: "The Extended BON scanner." project: "The Extended BON Tool Suite" guage in which we are working. Second, we need to de- author: "Joseph R. Kiniry " fine domain-specific semantics using kind interpretations. copyright: "Copyright (C) 2001 Joseph R. Kiniry" Lastly, we use kind theory’s belief truth structures to guide version: "$Revision: 1.10 $" program development. license: "Eiffel Forum Freeware License v1"

We will first look at syntactic embedding for two program- 3.2 Specification Languages ming and one specification language. In the latter parts of We have also used semantic properties to extend the BON this next section we will address the other two points. specification language.

3.1 Programming Languages 3.2.1 BON BON stands for the Business Object Notation. BON is de- But its primary use is design model checking for Eiffel and scribed in whole in Walden and Nerson’s Seamless Object- Java code. Oriented Software Architecture [31], extended from an ear- lier paper by Nerson [25]. BON is extended with our set of semantic properties by (a) extending the BON language (adding new keywords and ex- 3.2.1.1 Primary Aspects pressions), (b) using structured comments, and (c) using in- dexing clauses like those in Eiffel. More information on BON is an unusual specification language in that it is seam- these specific extensions is available at the EBON web site [14]. less, reversible, and focuses on contracting. BON also has both a textual and a graphical form. 3.2.2.1 Domain-Specific Semantics BON is seamless because it is designed to be used during all Translations from BON to a source language and vice-versa phases of program development. Multiple refinement levels are to be represented by kind theory interpretations. This (high-level design with charts, detailed design with types, means that changes to either side of the translation can not and dynamism with scenarios and events), coupled with ex- only be translated, but can be checked for validity accord- plicit refinement relationships between those levels, means ing to its (dual) model. This specification-code conformance that BON can be used all the way from domain analysis to (validity) checking is what we call design model checking. unit and system testing and code maintenance. We use this terminology because the specification is the the- Reversibility summarizes the weak but invertible nature of ory and the program code is the model, when viewed from BON’s semantics. By virtue of its design, every construct the logical perspective. described in BON is fully realizable in program code. One A change in the source code that is part of a EBON inter- can specify system structure, types, contracts, events, sce- pretation image will automatically trigger a corresponding narios, and more. Each of these constructs can not only be change in the EBON specification. Likewise, any change in interpreted into program code, but program code can be in- the EBON specification will automatically trigger a corre- terpreted into BON. As far as we are aware, this makes BON sponding change in the source code. unique insofar as, with proper tool support, a system speci- fication need not become out-of-date if it is written in BON. Some of these translations entail more than just a transfer of information from a specification to a comment in the source Finally, BON focuses on software contracts as a primary code. For example, an invariant semantic tag is inter- means of expressing system semantics. These contracts have preted not only as documentation, but also as run-time test exactly the same semantics as discussed earlier with regards code. We do not have the space in this paper to detail this in- to object-orientedmodels, because BON is an object-oriented terpretation. It follows the same lines as related tools that specification language. support contract-based assertions in Java and Eiffel men- BON’s semantics were originally specified informally using tioned elsewhere in this paper. Eiffel [22, 31]. Paige and Ostroff recently provided an anal- ysis of BON with an eye toward a refinement-centric formal 3.2.2.2 Belief-Driven Development semantics [26, 27]. Some BON extensions are non-reversible because they rep- resent system aspects that are either very difficult or impos- 3.2.1.2 BON Technologies sible to derive. For example, the time-complexity se- BON has been, and is being, used within several commercial mantic property specifies the computational complexity of and Open Source tools: Interactive Software Engineering’s a feature. It is (rarely) possible to extract such information EiffelCase and EiffelStudio9 tools; Ehrke’s BonBon CASE from an algorithm with automated tools. But the fact is, the tool; Steve Thompson and Roy Phillips’s BONBAZ/Envision algorithm author often knows her algorithm’s complexity. project; Kaminskaya’s BON static diagram tool [11]; Paige, Thus, stating the complexity as part of the algorithm specifi- Lancaric, and Ostroff’sBON CASE tool; and Kiniry’s EBON cation with a semantic property is easy and straightforward tool suite [14]. task.

The last three are particularly exciting projects because they Now the question arises: How do we know such specifica- are currently active and have wide applicability. Kamin- tions that are not automatically checkableremain valid? This skaya’s and Lancaric’s tools generate textual BON, JML, is where the earlier-mentioned belief truth structures of kind Eiffel, and Java source code from a graphical BON speci- theory come into play. fication. When the programmerwrites the original time-complexity 3.2.2 Extended BON semantic property for a feature, she is stating a belief about Kiniry’s EBON tool suite has a different aim. Its secondary that feature. Beliefs in kind theory are autoepistemic (the purpose is similar to other previously mentioned tools, namely representation of the programmer is part of the logical sen- the generation of documentation from BON specifications. tence encoding the belief), have an associated “strength” or “surety” metric (recall Section 2.2.1), and include a set of 9http://www.eiffel.com/products/studio51/ evidence supporting the belief. We use a number of techniques to ensure that old or out-of- exists for formalizing the semantics of semi-structured doc- date beliefs are rechecked. With regards to this example, we umentation. Some work in formal concept analysis and re- define a continued validity condition as part of the evidence, lated formalisms [29, 34] has started down this path, but with which is machine checkable. Currently, if the program code extremely loose semantics and little to no tool support. or documentation to which the complexity metric belief is boundradically changesin size, or if the feature has a change Recent work by Wendorff [32, 33] bears resemblance to this in type, author, or other potentially complexity-impacting work both in its nature (that of concept formation and reso- specification (e.g., concurrency, space-complexity, etc.), then lution) and theoretic infrastructure (that of category theory). the validity condition is tripped and the developer is chal- Our work is differentiated by its broader scope, its more ex- lenged to re-check and validate the belief, restarting the pro- pressive formalism, and its realization in tools. Additionally, cess. the user-centric nature of kind theory (not discussed in this article) makes for exposing the formalism to the typical soft- 4. EXPERIENCES ware engineer a straightforward practice. We have used semantic properties within our research group, Our next steps are on two fronts. First, we are interested in in the classroom, and in two corporate settings. embedding our semantic properties in the Java-centric spec- ification language JML. Second, we are continuing to de- The Compositional Computing Group at Caltech has used semantic properties in our complex, distributed and concur- velop new tools and technologies to realize knowledgeable rent architectures, written in Java and Eiffel, over the past development environments that use kind theory as a formal foundation. five years. We have witnessed their utility by first-hand ex- perience primarily during the introduction of our complex technologies to new students and collaborators is particu- 5.1 JML larly facilitated by semantic properties. JML is the Java Modeling Language [20]. JML is a Java- and model-centric language in the same tradition as Larch Students grumble at first when they are told that their com- and VDM. JML is used to specify detailed semantic aspects ments now have a precise syntax and a semantics. The stu- of Java code and some tool support exists for type-checking dents initially think of this as being “just more work” on their and translating these specifications into documentation and part—yet another reason to hand in a late assignment. But, run-time test code [2, 7, 28]. The formal semantics of JML as the term goes by, the students incorporate the precise doc- have been partially specified via a logic as part of the LOOP umentation with semantic properties and related tools into project [10]. their development process. After a few weeks of indoctrina- tion, they not only stop complaining, but start praising the Extending JML with semantic properties would follow the process and tools. We generally see higher quality systems same course that we have used for BON. Because we already and the students report spending less time on their home- have integrated semantic properties with Java, and given the work than when they started the course. They have learned existing tool support for JML, we should be able to real- how to work smarter, not harder. ize inter-domain interpretations that preserve a vast amount of information about JML-specified Java systems using kind These languages, process, and tools were also used in a cor- theory. porate setting to develop a enormously complex, distributed, concurrent architecture. When showing the system to poten- 5.2 Social Implications tial funders and collaborators, being able to present the sys- We expect that knowledgeable development environments tem architecture and code with this level of specification and will have social implications for software development. documentation invariably increased our value proposition. Uniformly, investors were not only shocked that a startup First, this challenging, interactive style imposed by knowl- would actually design their system, but to think that we used edgeable development environmentsis not typical—we have lightweight formal methods to design, build, test, and docu- to make sure that we are not introducing some kind of for- ment the system was absolutely unheard of. mal methods “paper clip”. Thus, the environment needs to “tune” itself to the interactive style and development process We have incorporated feedback from these three domains of the user. We look forward to theoretically representing into our work. Our set of semantic properties is still evolv- such styles in kind theory so that tuning is simply part of the ing, albeit at a rapidly decreasing rate. Our tools see re- logical context. finement for incorporation into new development processes, better error handling, and more complete and correct func- Second, in our extensive experiencein the research lab, class- tionality. This user feedback is essential to understanding room, and corporate office, we have witnessed the fact that how these technologies and theory can be exposed in aca- most developersare very uncomfortable starting from scratch, demic and industrial settings. especially with regards to system documentation and infor- mal and formal specifications. If some existing documenta- 5. CONCLUSION tion or specification exists, developers are much more likely Documentation reuse is most often discussed in the literate to continue in that trend because they feel that they are con- programming [3] and hypertext domains [6]. Little research tributing rather than creating. Because the EBON tool suite will automatically generate [5] R. Findler and M. Felleisen. Contract soundness for a base specification from program code, and because the object-oriented languages. In Proceedings of Sixteenth specification-code validity conformanceis automatically main- International Conference Object-Oriented tained, we have a primer as well as a positive feedback cycle Programming, Systems, Languages, and Applications, for lightweight specification with semantic properties. Only 2001. time and experience will tell whether this is a sufficient fire to light the correct software fuse. [6] G. Fischer, R. McCall, and A. Morch. JANUS: Integrating hypertext with a knowledge-based design 5.3 Knowledgeable Environments environment. SIGCHI Bulletin, pages 105–117, 1989. As mentioned previously, our work on KDEs continues. [7] Anand Ganapathy. Design and implementation of a JML type checker. Master’s thesis, Iowa State We wish to augment our already powerful development en- University, 1999. vironment in two ways. Our first step entails integrating an interactive front-end like XEmacs with our kind system [8] T. Gruber. Towards principles for the design of realized in Maude. The availability of Emacs-centric tools 10 ontologies used for knowledge sharing. In N. Guarino for proof system like the excellent Proof General make and R. Poli, editors, Formal Ontology in Conceptual this a relatively straightforward exercise. The most time- Analysis and Knowledge Representation. Kluwer consuming aspect is writing interpretation engines that trans- Academic Publishing, 2000. In prepartation. late annotated source code to and from a kind representation format. Several such tools are being prototyped now [14, [9] R. Herzig and M. Gogolla. Transforming conceptual 16]. data models into an object model. Lecture Notes in Computer Science, 645:280–298, 1992. We also plan on integrating these environments with our reusable knowledge repository known as the Jiki [13]. The [10] Bart Jacobs and Erik Poll. A logic for the Java Jiki is a read/write web architecture realized as a distributed modeling language JML. Technical Report component-based Java Wiki. All documents stored in the CSI-R0018, Computing Science Institute, University Jiki are represented as instances of kind. Manipulating Jiki of Nijmegen, November 2000. assets, including adding or deleting information or searching for reusable assets, is realized through a forms-based web in- [11] Liliya Kaminskaya. Combining tools for terface as well as through a Java component-based API. object-oriented software development: An integration of BON and JML. Master’s thesis, Department of 6. ACKNOWLEDGMENTS Computer Science, York University, 2001. This work was supported under ONR grant JJH1.MURI- 1-CORNELL.MURI (via Cornell University) “Digital Li- [12] Joseph R. Kiniry. IDebug: An advanced debugging braries: Building Interactive Digital Libraries of Formal Al- framework for Java. Technical Report CS-TR-98-16, gorithmic Knowledge” and AFOSR grant JCD.61404-1-AFOSR.- Department of Computer Science,California Institute 614040 “High-Confidence Reconfigurable Distributed Con- of Technology, November 1998. trol”. [13] Joseph R. Kiniry. The Jiki: A distributed component-based Java Wiki. Available via 7. REFERENCES http://www.jiki.org/, 1998. [1] T. Bench-Capon and G. Malcolm. Formalising Ontologies and Their Relations, volume 1677 of [14] Joseph R. Kiniry. The Extended BON tool suite. Lecture Notes in Computer Science, pages 250–259. http://ebon.sourceforge.net/, 2001. Springer–Verlag, 1999. [15] Joseph R. Kiniry. Formalizing Open, Collaborative [2] Abhay Bhorkar. A run-time assertion checker for Java Reuse with Kind Theory. PhD thesis, California using JML. Technical Report 00-08, Department of Institute of Technology, 2002. Computer Science, Iowa State University, May 2000. [16] Joseph R. Kiniry and Elaine Cheong. JPP: A Java [3] Bart Childs and Johannes Sametinger. Literate pre-processor. Technical Report CS-TR-98-15, programming and documentation reuse. In Department of Computer Science,California Institute Proceedings of the Fourth International Conference of Technology, November 1998. on Software Reuse, pages 205–214, 1996. [4] Manuel Clavel, Francisco Dur´an, Steven Eker, Jos´e [17] Donald E. Knuth. Literate Programming. Number 27 Meseguer, and Mark-Oliver Stehr. Maude as a formal in CSLI Lecture Notes. Center for the Study of meta-tool. In Proceedings of the World Congress on Language and Information, 1992. Formal Methods in the Development of Computing [18] Donald E. Knuth and Silvio Levy. The CWEB System Systems, 1999. of Structured Documentation. Addison-Wesley 10http://zermelo.dcs.ed.ac.uk/∼proofgen/ Publishing Company, third edition, 2001. [19] Reto Kramer. iContract–the Java design by contract [32] P. Wendorff. Linking concepts to identifiers in tool. In Proceedings of the Twenty-Fourth Conference information systems engineering. In S. Sarkar and on the Technology of Object-Oriented Languages S. Narasimhan, editors, Proceedings of the Ninth (TOOLS 24), volume 26 of TOOLS Conference Series. Annual Workshop on Information Technologies and IEEE Computer Society, 1998. Systems, pages 51–56, 1999. [20] Gary T. Leavens, Albert L. Baker, and Clyde Ruby. [33] P. Wendorff. A formal approach to the assessment and Behavioral Specifications of Business and Systems, improvement of terminological models used in chapter JML: A Notation for Detailed Design, pages information systems engineering. In Proceedings of 175–188. Kluwer Academic Publishing, 1999. the Joint Eighth European Software Engineering Conference (ESEC) and Ninth ACM SIGSOFT [21] Barbara Liskov and Jeannette M. Wing. Specifications Symposium on the Foundations of Software and their use in defining subtypes. In ACM Conference Engineering (FSE-9), volume 26 of Software on Object-Oriented Programming Systems, Engineering Notes, pages 83–87, 2001. Languages, and Applications, pages 16–28. ACM SIGPLAN: Programming Languages, ACM Press and [34] R. Wille. Concept lattices and conceptual knowledge Addison-Wesley Publishing Company, 1993. systems. Computers and Mathematics with Applications, 23(6-9):493–515, 1992. [22] Bertrand Meyer. Object-Oriented Software Construction. Prentice-Hall, Inc., second edition, [35] R. Wille. Conceptual graphs and formal concept 1988. analysis. Conceptual Structures: Fulfilling Peirce’s Dream, 1257:290–303, 1997. [23] Bertrand Meyer. Eiffel the Language. Prentice-Hall, Inc., third edition, 1990. APPENDIX A. SEMANTIC PROPERTIES SUMMARY [24] Bertrand Meyer. Applying design by contract. IEEE Computer, October 1992. Table 1: The Full Set of Semantic Properties

[25] Jean-Marc Nerson. Applying object-oriented analysis Meta-Information: Contracts Versioning and design. Communications of the ACM, author ensure version 35(9):63–74, September 1992. bon generate deprecated bug invariant since [26] Richard Paige and Jonathan S. Ostroff. ERC - An copyright modifies Documentation object-oriented refinement calculus for Eiffel. description require design Technical Report CS-2001-05, Department of history Concurrency equivalent Computer Science, York University, August 2001. license concurrency example title Usage see [27] Richard F. Paige and Jonathan Ostroff. Metamodelling Dependencies param Miscellaneous and conformance checking with PVS. In Proceedings references return guard of Fundamental Aspects of Software Engineering, use exception values volume 2029 of Lecture Notes in Computer Science. Inheritance Pending Work time-complexity Springer–Verlag, April 2001. Also available via hides idea space-complexity http://www.cs.yorku.ca/techreports/2000/CS-2000-03.html. overrides review [28] Arun D. Raghavan. Design of a JML documentation todo generator. Technical Report 00-12, Department of Computer Science, Iowa State University, March 2000. [29] M. Simos and J. Anthony. Weaving the model web: A multi-modeling approach to concepts and features in domain engineering. In Proceedings of the Fifth International Conference on Software Reuse, Victoria, BC, Canada, 1998. [30] P.E. van der Vet and N.J.I. Mars. Bottom-up construction of ontologies. IEEE Transactions on Knowledge and Data Engineering, 10(4):513–526, 1998. [31] Kim Wald´en and Jean-Marc Nerson. Seamless Object-Oriented Software Architecture - Analysis and Design of Reliable Systems. Prentice-Hall, Inc., 1994.