A Quality Model for Design Patterns


Download A Quality Model for Design Patterns


Preview text

A Quality Model for Design Patterns

Khashayar Khosravi

Yann-Ga¨el Gu´eh´eneuc

Summer 2004

Abstract
Design patterns are high level building blocks that are claimed to promote elegance in object-oriented programs by increasing flexibility, scalability, usability, reusability, and robustness. However, there is some evidence that design patterns do not intrinsically promote quality.
We believe that the problem of quality with design patterns comes both from the design patterns themselves and from their misuse. Unfortunately, little work has attempted so far to study the quality characteristics of design patterns rigorously. The objective of this technical report is to introduce a quality model and metrics that help in assessing the quality characteristics of design patterns and in concluding on design patterns quality.
We begin with a summary of definitions on quality and related concepts and by introducing the most common and standard quality models. Then, we define characteristics of the models in details and present the metrics used to measure programs. Some of the most common characteristics of quality models introduced are used to develop a quality model to assess and measure the quality characteristics that design patterns claim to possess.

Contents

1 Quality Models

3

1.1 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Quality Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Quality Model . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Quality Factor . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.3 Quality Sub-factor . . . . . . . . . . . . . . . . . . . . . . 5

1.2.4 Quality Criterion . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.5 Quality Metric . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.6 Internal Quality . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.7 External Quality . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.8 Quality in Use . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Quality Models

8

2.1 Hierarchical Models . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 McCall’s Model (1976-7) . . . . . . . . . . . . . . . . . . . 8

2.1.2 Boehm’s Model (1978) . . . . . . . . . . . . . . . . . . . . 9

2.1.3 FURPS Model (1987) . . . . . . . . . . . . . . . . . . . . 10

2.1.4 ISO/IEC 9126 (1991) . . . . . . . . . . . . . . . . . . . . 11

2.1.5 Dromey’s Model (1996) . . . . . . . . . . . . . . . . . . . 12

2.2 Non-hierarchical Models . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Bayesian Belief Networks . . . . . . . . . . . . . . . . . . 14

2.2.2 Star Model . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Quality Characteristics . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.3 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Quality Metrics

30

3.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Quality Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.2 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.3 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.4 Conciseness . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1

3.2.5 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.6 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.7 Expendability . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.8 Generality . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.9 Hardware independence . . . . . . . . . . . . . . . . . . . 38 3.2.10 Indicesability . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.11 Learnability . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.12 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.13 Maturity Index . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.14 Operability . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.15 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.16 Readability . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.17 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2.18 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2.19 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.20 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.21 Software independence . . . . . . . . . . . . . . . . . . . . 47 3.2.22 Structuredness . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.23 Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.2.24 Understandability . . . . . . . . . . . . . . . . . . . . . . 48 3.2.25 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3 Our Model in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . 52 3.4 Enhancing our Model . . . . . . . . . . . . . . . . . . . . . . . . 53

4 Design Patterns

56

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2 Why Design Patterns? . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Quality Characteristics related with Design Patterns . . . . . . . 56

4.4 Quality evaluation of Design Patterns . . . . . . . . . . . . . . . 57

4.4.1 Creational Design Patterns . . . . . . . . . . . . . . . . . 58

4.4.2 Structural Design Patterns . . . . . . . . . . . . . . . . . 63

4.4.3 Behavioral Design Patterns . . . . . . . . . . . . . . . . . 72

4.5 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5 Conclusions

87

2

Chapter 1
Quality Models
1.1 Quality
Everyone agrees that software quality is the most important element in software development because high quality could reduce the cost of maintenance, test and software reusing. But quality has very different meanings for customers, users, management, marketing, developers, testers, quality engineers, maintainers, and support personnel. Many institutes and organizations have their own definitions of quality and their own quality characteristics.
The software industry is going to grow up daily and “it is rather surprising that more serious and definitive work has not been done to date in the area of evaluating software quality” [9]. Moreover, Kitchenham (1989) notes that “quality is hard to define, impossible to measure, easy to recognize” [39, 54]. Also, Gilles states that quality is “transparent when presented, but easily recognized in its absence” [28, 54]. Furthermore, Kan (2000) explains that “Quality is not a single idea, but rather a multidimensional concept. The dimensions of quality include the entity of interest, the viewpoint on that entity, and quality attributes of that entity” [36].
Some organisations try to develop standard definitions for quality. We mow present some definitions of international and standard organisations [53]:
• ISO 9126: “Software quality characteristic is a set of attributes of a software product by which its quality is described and evaluated”.
• German Industry Standard DIN 55350 Part 11: “Quality comprises all characteristics and significant features of a product or an activity which relate to the satisfying of given requirements”.
• ANSI Standard (ANSI/ASQC A3/1978): “Quality is the totality of features and characteristics of a product or a service that bears on its ability to satisfy the given needs”.
• IEEE Standard (IEEE Std 729-1983):
3

– The totality of features and characteristics of a software product that bear on its ability to satisfy given needs: For example, conformance to specifications.
– The degree to which software possesses a desired combination of attributes.
– The degree to which a customer or a user perceives that a software meets her composite expectations.
– The composite characteristics of a software that determine the degree to which the software in use will meet the expectations of the customer.
Figure 1.1 is meta-model of the relationships among requirements models and quality models.
Figure 1.1: Relationships among requirements models and quality models All these definitions give separate views on quality. Thus, we need to organise, clarify, and standardise the large number of quality-related definitions to obtain the best definitions for quality.
1.2 Quality Evaluation
Evaluation of quality requires models to link measures of software artifacts with external, high-level, quality characteristics. First, we introduce the concept of quality model, then we present the different elements related to quality models.
1.2.1 Quality Model
ISO/IEC 9126-1 defines a quality model as a “framework which explains the relationship between different approaches to quality” [33]. Quality models decomposes in hierarchical elements. An approach to quality is to decompose quality in Factors, Sub-factors, and criteria. Evaluation of a program begins
4

with measuring each quality criteria with numerical value from metrics. Then, each quality sub-factors is assessed using their criteria. Finally, numerical value are assigned to quality characteristics from their quality sub-factors. Figure 1.2 presents a meta-model of the relationships among quality model elements.
Figure 1.2: Relationship among quality model elements
1.2.2 Quality Factor
The typical objective of a quality factor is to characterize an aspect of the quality of a work product or a process [24].
1.2.3 Quality Sub-factor
Some factors can not refer directly to their criteria, they require a extra intermediate level to be computed. Elements of this intermediate level are sub-factors. For example, in Boehm’s model (Figure 2.2), maintainability1 as factor refers to three sub-factors: Testability, understandability, and modifiability.
The typical objectives of a quality sub-factor are to [24]: • Characterize a part of a quality factor. • Further characterize an aspect of the quality of a work product or process. • Help in defining the term “quality” for an endeavor.
1.2.4 Quality Criterion
A quality criterion is the detailed description of the rationale for the existence of a factor or of a sub-factor. For example, in Boehm’s model, portability as a factor is described with two criteria: Device-independence and self confinedness.
1All the “-ility” are define in Section 2.3.
5

1.2.5 Quality Metric
We need to specify quality metrics to evaluate a given quality criteria. Each quality metric provides a numerical value that can be scaled to measure a quality factor. Metrics must be complete and detailed sufficiently to be the firm foundation of a quality model.
“There is a strange relationship between internal and external quality. External quality is quality as measured by the customer. Internal quality is quality as measured by the programmers [6]” [17].
1.2.6 Internal Quality
N. Bevan defined the internal quality as characteristic “which is measured by the static properties of the code, typically by inspection (such as path length)” [7].
1.2.7 External Quality
External quality is defined as characteristics “which is measured by the dynamic properties of the code when executed (such as response time)” [7].
1.2.8 Quality in Use
ISO/IEC 9126-1 defines the quality in use as “the user’s view of quality. Achieving quality in use is dependent on achieving the necessary external quality, which in turns is dependent on achieving the necessary internal quality” [33], “which is measured by the extent to which the software meets the needs of the user in the working environment (such as productivity)” [7].
Quality in use decomposes into four characteristics [33]:
• Effectiveness
• Productivity
• Safety
• Satisfaction
“Evaluation of software products in order to satisfy software quality needs is one of the process in the software development life-cycle. Software product quality can be evaluated by measuring internal attributes (typically static measure of intermediate products), or by measuring external attributes (typically by measuring the behavior of the code when executed), or by measuring quality in use attributes. The objective is for the product to have the required effect in a particular context of use” [33], see also Figure 1.3 .
Using these definitions of quality and quality models, we now present the most common quality models defined in the literature.
6

Figure 1.3: Quality in the life-cycle 7

Chapter 2
Quality Models
2.1 Hierarchical Models
Several quality models have been defined by different people and organizations. In the following, we summarize briefly some of the most standard and wellknown quality models.
2.1.1 McCall’s Model (1976-7)
McCall’s model for software quality (see Figure 2.1) combines eleven criteria around product operations, product revisions, and product transitions. The main idea behind McCall’s model is to assess the relationships amon external quality factors and product quality criteria.
“McCall’s Model is used in the United States for very large projects in the military, space, and public domain. It was developed in 1976-7 by the US Airforce Electronic System Decision (ESD), the Rome Air Development Center (RADC), and General Electric (GE), with the aim of improving the quality of software products” [53].
“One of the major contributions of the McCall model is the relationship created between quality characteristics and metrics, although there has been criticism that not all metrics are objective. One aspect not considered directly by this model was the functionality of the software product” [45].
The layers of quality model in McCall are defined as [11]:
• Factors; • Criteria; • Metrics.
8

Preparing to load PDF file. please wait...

0 of 0
100%
A Quality Model for Design Patterns