A Metric for Measuring the Abstraction Level of Design Patterns Atsuto Kubo Hironori Washizaki Yoshiaki Fukazawa Waseda University Waseda University Waseda University Japan Japan Japan [email protected]. [email protected] [email protected] waseda.ac.jp ABSTRACT abstraction level, and is independent from details in design The abstraction level of the problem treated by a design and implementation. Near the end of development, the com- pattern has wide variety, from architecture to near imple- ponents have lower abstraction level, and depend on a con- mentation. There is no objective metric indicating the ab- crete language and environment. There are software pat- straction level of the problems addressed by patterns. Thus, terns addressing problems for each phase. The pattern to it is di±cult to understand the abstraction level of each pat- use for development must have an abstraction level matches tern and to position a new pattern. In this paper, a metric the appropriate level in system development. is proposed. It indicates the relative abstraction level of Developers should select patterns according to the devel- a pattern's problem. We propose a metric obtained from opment phase because a pattern that doesn't matched the inter-pattern relationships. We also propose a visualization system's abstraction level is not e®ective. Therefore, devel- method for the metric. Using such metrics, we aim to help opers need to know the abstraction levels of patterns. In the developers easily understand the abstraction level of each basic design phase, developers should not be aware of idioms, pattern and, therefore, to better decide about its usefulness and in the implementation phase, developers should not be for the problem at hand. aware of architectural patterns. The patterns mismatching current development phase may make developers confused. However, abstraction levels of patterns are di®erent even if Categories and Subject Descriptors they belong to the same pattern catalog. Developers can- D.2.11 [Software Engineering]: Software Architectures| not clearly classify some patterns into architectural patterns, Patterns design patterns, or idioms. For example, let's consider Gang of Four (GoF)'s object- General Terms oriented design patterns [3] and PoSA's patterns [1]. The GoF's design patterns deal with the problems at the granu- Design larity of class design, and PoSA's patterns deal problem at the granularity of system architecture design. However, for Keywords example, GoF's Interpreter pattern is near an architec- Patterns, Interpattern Relationships tural pattern because it uses many other patterns directly and/or indirectly in its solution. It can be thought that the Model-View-Controller (MVC) pattern [4] [1] is near a de- 1. INTRODUCTION sign pattern because it treats individual applications. As A software pattern is a proven solution to a recurring in the above situations, it can be di±cult for developers to problem that appears in the context of software development select patterns ¯tting into considering level of abstraction. [1]. Describing the knowledge of experienced developers pro- If there is a metric that position the Interpreter pattern motes sharing and reusing their knowledge. Many authors near architectural patterns, developers can discuss whether have published many patterns, and most of the patterns to use it or not. However, actually, there is no objective have relationships to other patterns. A pattern collection is metric capable to indicate that. a set of patterns that may or may not be related to each In this paper, we propose a metric that indicates the rel- other. ative abstraction level of each pattern in a set of patterns. In the design phase, developers break the system down The proposed metric is based on the partially-ordered rela- gradually into components. Initially, the system has a higher tionships between two patterns, and aims to assist in: under- standing of the pattern's abstraction level, classifying pat- Preliminary versions of these papers were workshopped at Pattern Lan• terns, and selecting patterns to solve faced problems. guages of Programming (PLoP)’07 September 5•8, 2007, Monticello, IL, USA. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are 2. A METRIC MEASURING THE ABSTRAC• not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to TION LEVEL OF DESIGN PATTERNS republish, to post on servers or to redistribute to lists, requires prior specific There is a wide variation in software design abstraction permission. Copyright is held by the authors. ISBN: 978•1•60558•411•9. PLoP ’07, September 5•8, 2007, Monticello, IL, USA level from architecture to detailed design to implementation. Copyright 2008 is held by the author(s). ACM 978•1•60558•411•9. Developers focus on dividing a system into subsystems at Table 1: A list of inter-pattern relationships Kind of relationship Description Partially-ordered Similar to [8, 6] Pattern X is similar to Pattern Y. No Uses[8, 6, 7] Pattern X uses another pattern Y in its Yes solution. Re¯nes [1, 6], Speci¯c [7] Pattern Y provides a more speci¯c solu- Yes tion than pattern X. Combinable [1] Pattern X and Pattern Y can be com- No bined. Variation [1] Pattern Y is pattern X with some No changes to Y's solution. Provides context [7] Pattern X and Pattern Y can be applied Yes sequentially. ¯rst. Next, they focus on the design of each subsystem, from other patterns. The metric score of a pattern is a dif- modules, and implementation. There can be software pat- ference between the reference count and the backward refer- terns in each abstraction level of software design. ence count of the pattern. In the example shown in Figure 1, Most patterns have one or more inter-pattern relation- the metric score of MVC pattern is six, and of the Composite ships. Authors of patterns often describe these relationships pattern is one. Therefore, developers can see that the MVC in the Related Patterns sections. Table 1 lists some examples pattern is more suitable for architectural design. of inter-pattern relationships. The Partially-ordered column shows whether each relationship is partially-ordered or not. 2.2 Formal definition of the proposed metric For example, the structure of the Interpreter pattern's The reference count of a pattern is the total number of syntax tree can be designed using the Composite pattern. patterns that the pattern can reference transitively on the That is a Uses relationship. Some inter-pattern relation- graph. The graph is composed of patterns (vertices) and ships exist across di®erent pattern catalogs. As another ex- inter-pattern relationships (edges). The backward reference ample, the MVC pattern uses the Observer pattern. count of a pattern is the total number of patterns that ref- In this metric, we use only Uses, Re¯nes, and Provides erences the pattern transitively on the graph. context relationships, i.e., the partially-ordered relationships P is the set of N patterns for which we want to calculate shown on Table 1. The proposed metric has two principles the metric score. below: P = fp1; p2; : : : png; n 2 N: ² Patterns that use other patterns, patterns which are more generalized, and patterns that are applied before The partially-ordered relationship between a pattern p1 and 2 h i other patterns have higher abstraction level. another pattern p2, p1; p2 P , is represented as p1; p2 . Therefore, the set of the relationships R is represented as ² Patterns used by other patterns, patterns that are R ½ P £ P: more speci¯c, and patterns that are applied after other patterns have lower abstraction level. (P; R) is a directed graph. R+ is a transitive closure on R. R+ is de¯ned as below: We will present an intuitive explanation and a formal de¯- nition. R1 ± R2 = fhp1; p3ij9p2 2 P (hp1; p2i 2 R1 ^ hp2; p3i 2 R2)g: Only the partially-ordered relationships a®ect the abstrac- R1 = R: tion level. For instance, the Similar to relationship repre- Rn+1 = Rn ± R: sents the existence of common properties between two pat- 1 terns. Therefore, we use only the partially-ordered relation- + i R = [ R : ships to calculate the abstraction levels of patterns. i=1 2.1 Intuitive explanation of the proposed met• In addition, the set of patterns that can be retrieved tran- ric sitively from a certain pattern p is a descendant of p, repre- The reference count of a pattern is the total number of sented as D(p). The set of patterns that a certain pattern p patterns that the pattern refers transitively. The backward can be retrieved transitively are ancesters of p, represented reference count of a pattern is the total number of patterns as A(p). that refers the pattern transitively. In Figure 1, ellipses + D(p) = fp jp; p 2 P ^ hp; p i 2 R g ½ P: indicate patterns, arrows indicate partially-ordered inter- 0 0 0 f j 2 ^ h i 2 +g ½ pattern relationships. For example, the MVC pattern tran- A(p) = p0 p0; p P p0; p R P: sitively refers six patterns, so the reference count of the MVC A pattern with many ancestors tends to be a part of other patterns is six, and the backward reference count of the MVC patterns. A pattern that has many descendants tends to pattern is zero because no pattern refers the MVC pattern. In use other patterns. Where jD(p)j denotes the number of the same way, the reference count of Composite pattern is patterns included in D(p), and jA(p)j denotes same of A(p), two, and backward reference count is one.