METRICS FOR THE OO DESIGN MODEL There is much about object-oriented design that is subjective—an experienced designer
24.3 METRICS FOR THE 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 cus- tomer requirements. 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 experi- enced designer (who gains additional insight) and the novice (who obtains an indi- cation of quality that would otherwise be unavailable).
In a detailed treatment of software metrics for OO systems, Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO design:
? Size. Size is defined in terms of four views: population, volume, length, and
What
characteristics
functionality. Population is measured by taking a static count of OO entities
can be measured when we assess
such as classes or operations. Volume measures are identical to population
an OO design?
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 indi- rect indication of the value delivered to the customer by an OO application.
CHAPTER 24
TECHNICAL METRICS FOR OBJECT-ORIENTED SYSTEMS
Complexity. Like size, there are many differing views of software complex- ity [ZUS97]. 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 mes- sages 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 prop- erties does this abstraction (class) need to possess to be useful to me?” [WHI97]. 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 mod-
“Many of the design eling—that is, that the abstraction (class) possesses the features required decisions for which I
of it. had to rely on
folklore and myth Completeness. The only difference between completeness and sufficiency can now be made
is “the feature set against which we compare the abstraction or design com- using quantitative
ponent [WHI97].” Sufficiency compares the abstraction from the point of view data.”
of the current application. Completeness considers multiple points of view,
Scott Whitmire
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 deter- mined by examining the degree to which “the set of properties it possesses is
WebRef
part of the problem or design domain” [WHI97].
A NASA technical report Primitiveness. A characteristic that is similar to simplicity, primitiveness addressing quality metrics
for OO systems can be (applied to both operations and classes) is the degree to which an operation downloaded from
is atomic—that is, the operation cannot be constructed out of a sequence of
satc.gsfc.nasa.gov/
other operations contained within a class. A class that exhibits a high degree
support/index.html
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.
Whitmire’s derivation of metrics for these design characteristics is beyond the scope of this book. Interested readers should see [WHI97] for more detail. 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.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more