STRUCTURAL ATTRIBUTES

2.5 STRUCTURAL ATTRIBUTES

Like business attributes, structural attributes are of interest to system custodians/ developers/maintainers/operators; but whereas business attributes deal with economic aspects of system management, structural attributes deal with their technical aspects. In other words, whereas business attributes are relevant to software managers, struc- tural attributes are of interest to engineers, designers and other technical personnel. We identify four structural attributes, which are as follows:

• Design Integrity: The quality of a design is easier to recognize than to define, which is in turn much easier than to quantify. Qualities of a good design include simplicity, orthogonality (the quality of a design that results from a set of independent decisions), economy of concept, cohesiveness of the design rationale, consistency of design rules, adherence to a simple design discipline, and so on.

• Modularity: Modularity can be defined in terms of a single design principle: information hiding. The main characteristic of a modular design is that each component of the system hides a design decision that other components need not know about (i.e., be influenced by). Hence one of the main features of a modular design is the separation between the specification of a module and its implementation. Modularity can be quantified by two attributes, which are as follows: ○ Cohesion: The cohesion of a component represents the volume of information

flow within the component, and can be quantified using information theory. ○ Coupling: The coupling between two components represents the bandwidth of information interchange that takes place between the components, and can be quantified by the entropy of the random variable that represents the flow of information interchange.

• Testability: The testability of a software product reflects the extent to which one can test the system or components thereof to an arbitrary level of thoroughness. Testability can be quantified by means of two attributes, which are as follows: ○ Controllability: The controllability of a component in a system is the band-

width (breadth) of input values we can submit (as test data) to the component by controlling system inputs. This can be quantified by the conditional entropy of the system’s input given an input value of the component.

○ Observability: The observability of a component is the extent to which we can infer the output produced by the component by observing the system output.

This can be quantified by the conditional entropy of the component’s output, given the system’s output.

2.7 EXERCISES

• Adaptability: The adaptability of a system is the ease with which it can be mod- ified to satisfy changing requirements. This attribute sounds similar to customiz- ability, in that they both deal with adjusting the software product to meet different sets of requirements. In fact they are different in two crucial ways, which are as follows: ○ Whereas customizability refers to changes carried out by the end user (hence

accessible to her/him, by design), adaptability refers to changes carried out by the software engineer.

○ Whereas customizability refers to changes that are planned for within the design of the system, adaptability refers to changes in the system requirements.

In many instances, we find that structural attributes support business attributes; for example, modularity supports maintainability. But we consider them as distinct, on the grounds that one is a business attribute while the other is a structural/technical attribute. Also, there is no one-to-one correspondence between them: modularity sup- ports not only maintainability but also development cost (which it reduces); also, maintainability is supported not only by modularity but also by testability.