Mapping the Design Deliverables to the Requirements Traceability Matrix Design Metrics

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