4 Comparisons

As far as we know, there is no proposal for a language with the constructs proposed here, although many researchers have advocated for it [Jaz95, Sha84, Win90]. There are many non-formalised proposals [Mat84, LG86] the results of which are subsumed in our work. Also, [Win89] presents a case study to deal with boolean NF-attributes in an object-oriented framework; no other kind of properties are dealt with in her approach. An interesting proposal appears in [CZ90], which provides a framework to evaluate the design of software systems, the measurement criterion being the adequacy of implementations with respect to some non-functional requirements stated over a set of attributes. The requirements are stated as an array of weights over the properties and every attribute has a weight too; then, the evaluation of implementations results in a number and comparison is possible. However, the notation proposed in this work is not as general as that presented here; also, the proposal is not integrated into the software itself losing some of the advantages we have mentioned in the introduction.

On the other hand, [CGN94], [Sit94] and [SY94] provide a language to state program efficiency. [CGN94] aims to code generation from some high-level language constructs manipulating a relation data type; in the general case, there are many ways to generate this code and so information about efficiency is used to select the optimal translation. [SY94] focuses on program transformation: algorithms are refined using a library of components with pre-post functional specifications; when there are many components whose pre-post specification allows its inclusion in the algorithm being refined, efficiency is used to break the tie. Concerning [Sit94], it is the proposal closest to ours due to its definition in the component programming framework and also to the existence of special modules collecting some kind of non-functional information (constraints on efficiency in this case), although he focuses on software reusability and verification, which are two fields we have not yet addressed. Efficiency in [Sit94] is slightly more difficult to handle than in our work, because it is ``tight" efficiency (an exact measurement of efficiency, more precise than the worst case we are considering here) and this often requires the definition of auxiliary models to express the time consumed by component operations. The proposal fits into a more exhaustive project, RESOLVE [Sit+94], which also includes a framework to allow switching of implementations of components [Sit92].

If we refer just to the notations used in the projects mentioned so far, none of them seem to be as powerful as NoFun, even considering just the subset of NoFun concerning efficiency. We would like to make sure of this fact in the workshop.