Architectural Design Metrics
19.4.1 Architectural Design Metrics
Architectural design metrics focus on characteristics of the program architecture (Chapter 14) with an emphasis on the architectural structure and the effectiveness of modules. These metrics are black box in the sense that they do not require any knowl- edge of the inner workings of a particular software component.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
Card and Glass [CAR90] define three software design complexity measures: struc- tural complexity, data complexity, and system complexity. Structural complexity of a module i is defined in the following manner:
S(i) = f 2 out (i)
(19-1)
where f out (i) is the fan-out 7 of module i.
Data complexity provides an indication of the complexity in the internal interface Metrics can provide
for a module i and is defined as insight into structural,
data and system D(i) = v(i)/[ f out (i) +1] (19-2) complexity associated with the architectural
where v(i) is the number of input and output variables that are passed to and from design.
module i. Finally, system complexity is defined as the sum of structural and data complexity, specified as
C(i) = S(i) + D(i) (19-3) As each of these complexity values increases, the overall architectural complexity of
the system also increases. This leads to a greater likelihood that integration and test- ing effort will also increase.
? An earlier high-level architectural design metric proposed by Henry and Kafura
Is there a
way to
[HEN81] also makes use the fan-in and fan-out. The authors define a complexity met-
assess the
ric (applicable to call and return architectures) of the form
complexity of certain
in (i) + f out (i)] 2 architectural (19-4) models?
where length(i) is the number of programming language statements in a module i and f in (i) is the fan-in of a module i. Henry and Kafura extend the definitions of fan- in and fan-out presented in this book to include not only the number of module con- trol connections (module calls) but also the number of data structures from which a module i retrieves (fan-in) or updates (fan-out) data. To compute HKM during design, the procedural design may be used to estimate the number of programming language statements for module i. Like the Card and Glass metrics noted previously, an increase in the Henry-Kafura metric leads to a greater likelihood that integration and testing effort will also increase for a module.
Fenton [FEN91] suggests a number of simple morphology (i.e., shape) metrics that enable different program architectures to be compared using a set of straightforward dimensions. Referring to Figure 19.5, the following metrics can be defined:
size = n + a
7 Recalling the discussion presented in Chapter 13, fan-out indicates the number of modules imme- diately subordinate to module i; that is, the number of modules that are directly invoked by mod- ule i.
F I G U R E 19.5 Morphology metrics
where n is the number of nodes and a is the number of arcs. For the architecture shown in Figure 19.5,
size = 17 + 18 = 35 depth = the longest path from the root (top) node to a leaf node. For the archi-
tecture shown in Figure 19.5, depth = 4. width = maximum number of nodes at any one level of the architecture. For the
architecture shown in Figure 19.5, width = 6. arc-to-node ratio, r = a/n, which measures the connectivity density of the architecture and may provide a sim-
ple indication of the coupling of the architecture. For the architecture shown in Fig- ure 19.5, r = 18/17 = 1.06.
The U.S. Air Force Systems Command [USA87] has developed a number of soft- ware quality indicators that are based on measurable design characteristics of a com- puter program. Using concepts similar to those proposed in IEEE Std. 982.1-1988 [IEE94], the Air Force uses information obtained from data and architectural design to derive a design structure quality index (DSQI) that ranges from 0 to 1. The follow- ing values must be ascertained to compute the DSQI [CHA89]:
S 1 = the total number of modules defined in the program architecture. S 2 = the number of modules whose correct function depends on the source of
data input or that produce data to be used elsewhere (in general, control modules, among others, would not be counted as part of S 2 ).
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
S 3 = the number of modules whose correct function depends on prior processing. S 4 = the number of database items (includes data objects and all attributes that
define objects). S 5 = the total number of unique database items. S 6 = the number of database segments (different records or individual objects). S 7 = the number of modules with a single entry and exit (exception processing
is not considered to be a multiple exit).
“Measurement can
be seen as a detour. Once values S 1 through S 7 are determined for a computer program, the following This detour is
intermediate values can be computed: necessary because
humans mostly are Program structure: D 1 , where D 1 is defined as follows: If the architectural not able to make
design was developed using a distinct method (e.g., data flow-oriented clear and objective
design or object-oriented design), then D decisions [without
1 = 1, otherwise D 1 = 0. quantitative
Module independence: D 2 2 /S 1 )
support].” Modules not dependent on prior processing: D 3 3 /S 1 )
Horst Zuse
Database size: D 4 5 /S 4 ) Database compartmentalization: D 5 6 /S 4 )
Module entrance/exit characteristic: D 6 7 /S 1 ) With these intermediate values determined, the DSQI is computed in the following
manner:
(19-5) where i = 1 to 6, w i is the relative weighting of the importance of each of the inter-
i = 1 (if all D i are weighted equally, then w i = 0.167). The value of DSQI for past designs can be determined and compared to a design
that is currently under development. If the DSQI is significantly lower than aver- age, further design work and review are indicated. Similarly, if major changes are to be made to an existing design, the effect of those changes on DSQI can be calculated.
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