3.1 Non-Functional Attributes

NF-attributes in NoFun are characterised by:

• Their domain. It fixes the set of valid values and operations. We have currently defined: boolean (e.g., error recovery), integer (e.g., degree of testing), real (e.g., response time), by enumeration (e.g., kind of user interface), string (e.g., programmer name) and asymptotic (time and space efficiency).

  NF-attributes must be declared in order to be known in components, except for asymptotic NF-attributes, which existence is inferred from the corresponding software component definition. More precisely, there are two asymptotic implicit NF-attributes, time(op ) and space(op ), for every public operation op , and another one space(t ) for every public type t . Values of asymptotic NF-attributes are given in terms of some measurement units , which represent problem domain sizes and which must also appear in NF-specification modules.

• Their kind. NF-attributes can be basic or derived , depending on whether their value can be inferred from others or must be explicitly given in NF-behaviour modules. Derived NF-attributes are useful not only for avoiding redundant assignments, but also to provide a logical structure to the universe of NF-attributes.

  A derived NF-attribute P includes the following parts:

  • The list L of other NF-attributes that determine P 's value.
  • A list of n guarded formulae of the form C_i => P = E_i, 1 <= i <= n, C_i being a boolean expression and E_i an expression yielding a value in P 's domain; if n = 1, then C_i is optional. The meaning of a formula is: P equals E_i if the condition C_i holds. In order to have a well defined semantics, the union of the C_i must cover all possible cases and their pairwise conjunction must yield false.
• Their scope. We have mentioned that NF-attributes can be defined inside NF-specification modules; in this case, they are only know in the component associated with this specification. Also, non-functional attributes may be defined in what we call attribute modules , which introduce closely-related and widely-applicable NF-attributes (appearing in many NF-specification modules, even in different software systems). In fact, attribute modules allow users to define their own libraries of NF-attributes which can be imported freely in software systems (of course, an attribute module may import other attribute modules).

  Last, we have defined another kind of module, system modules , to introduce NF-attributes to be know in all the components of a whole software system. System modules may also import attribute ones, meaning that all the NF-attributes defined in these attribute modules are know in all the system. Attribute modules and system modules altogether make possible to define NF-attributes in a structured and easy manner.

We present next an example of definition of NF-attributes. An attribute module for the reliability attribute may include the definition of some auxiliary NF-attributes, some of them defined in the imported attribute modules: a boolean one error_recovery , and an integer one test with valid values from 0 to 5. NF-specifications may import this module in order to have this attribute as a measure of quality.

attribute module RELIABILITY

imports ERROR_RECOVERY, TEST

attributes

boolean fully_portable

enumerated ordered reliability (none, low, medium, high) derived

depends on error_recovery, fully_portable, test

defined as

not error_recovery and not fully_portable => reliability = none

not error_recovery and fully_portable => reliability = low

error_recovery and not fully_portable => reliability = low

error_recovery and fully_portable =>

test in (0..1) => reliability = low

test in (2..3) => reliability = medium

test in (4..5) => reliability = high

end RELIABILITY