Next: 5 References
Up: The Convenience for a
Previous: 3.3 Non-Functional Requirements
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.
Xavier Franch