Software Engineering-Metrics for OO Design model


There is much about object-oriented design that is subjective—an experienced designer“knows” how to characterize an OO system so that it will effectively implement customerrequirements. But, as an OO design model grows in size and complexity, a more objective view of the characteristics of the design can benefit both the experienced designer (who gains additional insight) and the novice (who obtains an indication of quality that would otherwise be unavailable). 

In a detailed treatment of software metrics for OO systems, Whitmire  describes nine distinct and measurable characteristics of an OO design:

Size. Size is defined in terms of four views: population, volume, length, and functionality. Population is measured by taking a static count of OO entities such as classes or operations. Volume measures are identical to population measures but are collected dynamically—at a given instant of time. Length is a measure of a chain of interconnected design elements (e.g., the depth of an inheritance tree is a measure of length). Functionality metrics provide an indirect indication of the value delivered to the customer by an OO application.

In reality, technical metrics for OO systems can be applied not only to the design model, but also the analysis model. In the sections that follow, we explore metrics that provide an indication of quality at the OO class level and the operation level. In addition, metrics applicable for project management and testing are also explored.

Complexity. Like size, there are many differing views of software complexity . Whitmire views complexity in terms of structural characteristics by examining how classes of an OO design are interrelated to one another.

Coupling. The physical connections between elements of the OO design (e.g., the number of collaborations between classes or the number of messages passed between objects) represent coupling within an OO system.

Sufficiency. Whitmire defines sufficiency as “the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.” Stated another way, we ask: “What properties does this abstraction (class) need to possess to be useful to me?” . In essence, a design component (e.g., a class) is sufficient if it fully reflects all properties of the application domain object that it is modeling— that is, that the abstraction (class) possesses the features required of it.

Completeness. The only difference between completeness and sufficiency is “the feature set against which we compare the abstraction or design component.” Sufficiency compares the abstraction from the point of view of the current application. Completeness considers multiple points of view, asking the question: “What properties are required to fully represent the problem domain object?” Because the criterion for completeness considers different points of view, it has an indirect implication about the degree to which the abstraction or design component can be reused.

Cohesion. Like its counterpart in conventional software, an OO component should be designed in a manner that has all operations working together to achieve a single, well-defined purpose. The cohesiveness of a class is determined by examining the degree to which “the set of properties it possesses is part of the problem or design domain”.

Primitiveness. A characteristic that is similar to simplicity, primitiveness (applied to both operations and classes) is the degree to which an operation is atomic—that is, the operation cannot be constructed out of a sequence of other operations contained within a class. A class that exhibits a high degree of primitiveness encapsulates only primitive operations.

Similarity. The degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose is indicated by this measure.

Volatility. As we have seen earlier in this book, design changes can occur when requirements are modified or when modifications occur in other parts of an application, resulting in mandatory adaptation of the design component in question. Volatility of an OO design component measures the likelihood that a change will occur.

In reality, technical metrics for OO systems can be applied not only to the design model, but also the analysis model.
Share this article :
 
Copyright © 2012. Best Online Tutorials | Source codes | Programming Languages - All Rights Reserved