Next: 3.1 Non-Functional Attributes
Up: The Convenience for a
Previous: 2.3 Design Principles
In this section, we present the main issues of a notation called NoFun following the design principles
enumerated in the last section. We classify non-functional information into three kinds:
- Non-functional attribute (short, NF-attribute ): any characteristic of software which serves as
a means to describe it and, possibly, to evaluate it. Among the most widely accepted
[IEEE92, ISO91] we mention: time and space efficiency, reusability, maintainability,
reliability and usability.
In our approach, we let arbitrary attributes to appear; so, software components are studied
with respect to a particular set of NF-attributes; we say then that the component is
characterised by this set.
- Non-functional behaviour of a component implementation (short, NF-behaviour ): any
assignment of values to the NF-attributes that characterise the implemented component.
- Non-functional requirement on a software component (short, NF-requirement ): any
constraint referred to a subset of the NF-attributes that characterise the implemented component.
The set of NF-attributes that characterise a component, together with their relationships (stated as
NF-requirements), are declared in a NF-specification module , which is bound to the component
specification. The NF-behaviour of an implementation is stated in a NF-behaviour module , bound to
the implementation. Also, NF-behaviour modules will usually include NF-requirements for the
software components imported by the implementation. Keeping non-functional information in
separate modules gives full independence from the particular specification and programming
languages used in the system.
Next: 3.1 Non-Functional Attributes
Up: The Convenience for a
Previous: 2.3 Design Principles
Xavier Franch
Sept. 2, 1997