J.E.D.I
4.9 Mapping the Design Deliverables to the Requirements Traceability Matrix
Once the software components are finalized, we need to tie them up to the RTM of the project. This ensures that the model is related to a requirement. It also aids the
software engineer in tracking the progress of the development. Table 25 shows the recommended RTM elements that should be added to the matrix.
RTM Design Components
Description
Software Component ID
The name of the software component package that can be independently
implemented, eg.,
abl.athlete
software component that handles club membership application
Classes The name of the class that is
implemented which is part of the software
component, eg.,
abl.athlete.AthleteRecordUI
a JAVA class responsible for actor interface in
processing athlete record. Class Documentation
The Document Name of the class. It is a file that contains the specification of
the class.
Status The status of the class. Users can define
a set of status codes such as: • CLG – class design on going
• COG – coding on going • TOG – testing on going
• DONE
Table 25: RTM Design Model Elements
Software Engineering 198
J.E.D.I
4.10 Design Metrics
In object-oriented software engineering, the class is the fundamental unit. Measures and metrics for an individual class, the class hierarchy, and class collaboration is
important to the software engineer especially for the assessment on the design quality.
There are many sets of metrics for the object-oriented software but the widely used is the CK Metrics Suite proposed by Chidamber and Kemerer
6
. It consists of six class- based design metrics which are listed below.
1. Weighted Methods per Class WMC. This is computed as the summation of the complexity of all methods of a class. Assume that there are n methods
defined for the class. We compute for the complexity of each method and find the sum. There are many complexity metric that can be used but the
common one is the cyclomatic complexity. This is discussed in the chapter for Software Testing. The number of methods and their complexity indicates:
• the amount of effort required to implement and test a class • the larger the number of methods, the more complex is the inheritance
tree • as the number of methods grows within the class, the likely it will
become more complicated. 2. Depth of the Inheritance Tree DIT. It is defined as the maximum length
from the root superclass to the lowest subclass. Consider the class hierarchy in Figure 4.60, the DIT value is 5. As this number grows, it is likely that the
lower-level classes will inherit many methods. It can possibly lead to potential problems in predicting the behavior of the lower classes, and to greater design
complexity. On the other hand, a large value implies that many methods are reused.
3. Number of Children NOC. Children of a class are the immediate subordinate
of that class. Consider the class hierarchy in Figure 4.60, the NOC of Class4 is 2. As the number of children increases, reuse increases. However, care is
given such that the abstraction represented by the parent class is not diluted by its children which are not appropriately members of the parent class. Of
course, as the number of children increases, the number of testing the children of the parent class also increases.
4. Coupling Between Object Classes CBO. It is the number of collaboration that a class does with other object. As this number increases, the reusability
factor of the class decreases. It also complicates modifications and testing. It is for this reason that CBO is kept to a minimum.
5. Response for a class RFC. It is the number of methods that are executed in response to a message given to an object of the class. As this number
increases, the effort required to test also increases because it increases the possible test sequence.
6. Lack of Cohesion in Methods LCOM. It is the number of methods that access an attribute within the class. If this number is high, methods are coupled
together through this attribute. This increases the complexity of the class design. It is best to keep LCOM as low as possible.
6 Chidamber, S.R., and C.F. Kemerer, A Metrics Suite for Object-oriented Design, IEEE Trans. Software Engineering, vol SE-20, no. 6, June 1994,
pp. 476-493
Software Engineering 199
J.E.D.I
Software Engineering 200
Figure 4.60 Sample Class Hierarchy Class1
Class2 Class3
Class4 Class5
Class6 Class7
Class8 Class9
J.E.D.I
4.11 Exercises