2.3 Design Principles

Once we have advocated a notation for stating non-functional information in software components, we present here some design principles for such a notation.

• It should be complete. It should be possible to deal with non-functionality from different points of view; for instance, it is important to state non-functional properties of software components in specifications (e.g., ``reliability of the component must be medium or high", ``component must be portable from a PC platform to an UNIX system", etc.), but also to state non-functional characteristics of component implementations (e.g., ``the insert and delete operations of the component take constant time").
• It should be as open as possible. Provided that non-functionality means different things for different people, it should be possible for each of them to choose the particular attributes of interest and to reject others; even more, there should exist means to group attributes and to form then non-functional libraries. Also, it could be useful to have the opportunity to bind some attributes just to some particular components, or even to just some parts (typically, operations) of components.
• It should be concise, clear and easy to use. Writing non-functional information should not be a difficult task, because this would conflict with the main idea behind them: their usefulness in software development. So, non-functional properties should be written as usual expressions (e.g., ``reliability >= medium", ``works-on(PC-platform) => works-on(UNIX)", etc.), and the same with implementations (e.g., ``time(insert, delete) = O(1)").
• The notation must be a constituent part of software. This requirement highlights the role of non-functional issues in software development and it is achieved in many ways: non-functional information should be encapsulated in modules bound to software component definitions and implementations; the notation should be entirely formal, in the sense that its syntax and semantics are expected to be well-defined; and an algorithm should exist to verify that implementations fulfil non-functional specifications.
• It should fit to other software areas as much as possible. Although we are interested here in component programming, it would be nice to design a notation flexible enough to be used also in, say, information systems, knowledge-based systems, etc., with a few modifications. It should remain clear that a universal notation is impossible to get: for instance, in the component programming framework we can measure efficiency by the asymptotic behaviour of operations, while in information systems we are mainly interested in response time or throughput.
• It should be independent of the concrete specification and programming languages used to specify and code components. The only restriction we put on those languages is modularity: software components must be really encapsulated in modules. Also, we require for every software component to have a single specification (at least, declaration of its public symbols -type or class name; procedures, attributes, methods of functions with their interface; etc.-) and possibly many implementations, each of them in a separate module.
• It should be complemented with tools. For instance, we have already mentioned the need for a tool able to verify if an implementation satisfies the properties concerning non-functionality that were stated. Also, it would be nice to have an algorithm able to select the better implementation of a component in every context where it is used. The existence of this algorithm would allow the whole software system to adapt to changes in the environment in an automatic manner, once the non-functional information were modified conveniently. Also, it would help component reusability and it would improve quality of design.