A Metric for Measuring the Abstraction Level of

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 difficult 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 effective. 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 different 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 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 difficult for developers to problem that appears in the context of software development select patterns fitting 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. Refines [1, 6], Specific [7] Pattern Y provides a more specific 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.

first. 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 . 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 different pattern catalogs. As another ex- inter-pattern relationships (edges). The backward reference ample, the MVC pattern uses the . count of a pattern is the total number of patterns that ref- In this metric, we use only Uses, Refines, 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 = {p1, p2, . . . pn}, n ∈ 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 ∈ 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 specific, 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 defined as below: We will present an intuitive explanation and a formal defi- nition. R1 ◦ R2 = {hp1, p3i|∃p2 ∈ P (hp1, p2i ∈ R1 ∧ hp2, p3i ∈ R2)}. Only the partially-ordered relationships affect 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- ∞ 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) = {p |p, p ∈ P ∧ hp, p i ∈ R } ⊂ P. indicate patterns, arrows indicate partially-ordered inter- 0 0 0 { | ∈ ∧ h i ∈ +} ⊂ 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 |D(p)| denotes the number of the same way, the reference count of Composite pattern is patterns included in D(p), and |A(p)| denotes same of A(p), two, and backward reference count is one. the abstraction level of a certain pattern p is defined as: Patterns often delegate details into other patterns. Con- versely, a pattern used by other patterns is delegated details a(p) = |D(p)| − |A(p)|. Figure 1: Inter-pattern relationships

Since the metric depends on the relationships between Patterns can be connected if there are relationships of at patterns, the user should recompute the metric when the least two patterns from each pattern catalog. set of patterns are changed. The abstraction level and its visualization cannot be ob- tained without the proposed metric. Moreover, the devel- 2.3 Visualization oper can apply the proposed metric to a set of patterns, Developers cannot understand intuitively abstraction lev- possibly from different catalogs, as we have illustrated. els only from numbers. In this section, we propose a visual- ization technique that uses the abstraction level. In this technique, patterns with larger values for a(p) 4. RELATED WORK should be positioned above patterns with smaller values for Buschmann et al. proposed a classification of patterns: a(p) should be positioned below. Only the vertical axis architectural patterns, design patterns, idioms [1]. This clas- makes sence. In Figure 2, proposed visualization technique sification is based on abstraction level, however, we think it positions GoF’s design patterns. Ellipses indicate patterns is too coarse-grained. Our metric can classify patterns into and arrows indicate partially-ordered inter-pattern relation- spectrum. ships. The abstraction level a(p) is used to position each Martin proposed two metrics on packages [5], such as Af- pattern. ferent Couplings (Ca) and Efferent Couplings (Ce). Our metric and Martin’s OO-metrics is similar in the abstract structure of patterns/packages, however, our metric is for 3. VISUAL DEMO OF THE METRIC software patterns. Though our metric is defined as a simple To experiment the metric and visualization techniques, we subtraction, Martin’s metrics use a more complex calcula- built a tool that calculates and displays the abstraction level tion. of each pattern. The results are shown in Figure 2 and 3. Cutumisu et al. have proposed four metrics for pattern In Figure 2, we used “Uses”, “Refines” and “Provides catalogs: usage, coverage, utility and precision [2]. Those context” relationships. The Interpreter and the Abstract metrics use the number of patterns in a pattern catalog and Factory have high abstraction levels. The Interpreter ref- the number of adapted/unadapted instances of patterns. In erences many other patterns, such as Visitor, Iterator contrast, our metric uses partially-ordered inter-pattern re- and Composite, directly or indirectly. In the opposite side lationships. of that, the figure also shows that and There are researches about inter-pattern relationships [8, have lower abstraction level. Actually, 6, 7, 1]. Noble has surveyed inter-pattern relationships and the Prototype and Singleton patterns are referred directly has roughly classified into three categories, such as Use, Re- or indirectly by many other patterns. Using this proposed fine, Conflict. The Use and Refine relationships are partially- visualization technique, shown in Figure 2, developers can ordered, but the Confrict relationship is unordered. Since easier understand that some patterns are close to architec- our metric is based on partially-ordered relationships, the tural patterns, and other some patterns are close to idioms. metric works on Use and Refine relationships. In Figure 3, we performed a similar analysis on GoF’s design patterns and PoSA’s patterns. Some architectural patterns, such as Layers and Pipes and Filters, are at the 5. CONCLUSION top of the figure. This means they have highest abstraction In this paper, we proposed a metric to measure the ab- level in shown patterns. Interestingly, Interpreter pattern straction level of a pattern, based on partially-ordered inter- (a kind of design pattern) is positioned above Broker pattern pattern relationships. The advantages and disadvantages of (a kind of ). In the middle of Figure the proposed metric are the following: 3, patterns belonging to each pattern catalog are mixed. Advantages: 8 Interpreter

5 Abstract Factory

3 Chain of Responsibility Builder Strategy

2 Mediator Decorator Visitor State Proxy

1 Iterator

0 Observer Facade Template Method Command Adapter

-1 Bridge

-2 Composite

-3 Flyweight

-4 Memento

-5 Factory Method

-6 Prototype

-12 Singleton

Figure 2: GoF design patterns where vertical position depends on the score a(p), the abstraction level

• The metric can be applied across pattern catalogs be- [6] J. Noble. Classifying relationships between object-oriented cause the method only uses inter-pattern relationships. design patterns. In Proceedings of 1998 Australian Software Engineering Conference (ASWEC’98). IEEE CS Press, • The metric scores can be used as a hint to position 1998. patterns in a pattern map. [7] M. Volter. Server-side components - a pattern language. In proceedings of EuroPLoP ’2000, 2000. Disadvantages: [8] W. Zimmer. Relationships between design patterns. In Pattern Languages of Program Design Vol.1, pages 345–364. • The metric score is a relative value, so it is not possible Addison-Wesley, 1995. to compare scores from different sets of patterns. Appendix • Before applying the metric, the user has to obtain × means the direct product of two sets. inter-pattern relationships on the targeted set of pat- terns. ∧ means “and”. ∈ means inclution of the left-side argument by the right-side We plan to perform experiments to validate that our met- arugument. ric makes the user experience involved. ∞ Si=1 means the union of the following sets. 6. REFERENCES |S| means the number of elements included in set S. [1] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern Oriented Software Architecture: A System of Patterns. Wiley, New York, 1996. [2] M. Cutumisu, C. Onuczko, D. Szafron, J. Schaeffer, M. McNaughton, T. Roy, J. Siegel, and M. Carbonaro. Evaluating pattern catalogs: the computer games experience. In Proceeding of the 28th international conference on Software engineering (ICSE2006), pages 132–141, 2006. [3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [4] E. Krasner and S. T. Pop. A cookbook for using the model-view-controller user interface paradigm in smalltalk-80. Journal of Object-Oriented Programming, 1(3):26–49, 1988. [5] R. Martin. OO design quality metrics, 1994. http://www. objectmentor.com/resources/articles/oodmetrc.pdf. iue3 o’ einpten n oApten.vria oiindpnso h score the on depends position vertical patterns. PoSA and patterns design GoF’s 3: Figure

Pipes and Filters 17

Microkernel Reflection Layers 13

Interpreter Composite Message 8

Broker 6

Abstract Factory 5

Whole-Part 4

Strategy Builder Chain of Responsibility 3

State Visitor Command Processor 2

Iterator 1

Template Method Proxy 0

Bridge Facade -1

Flyweight Composite Mediator MVC PAC -3

Decorator -4

Factory Method Forwarder-Receiver Client-Dispatcher-Server Observer -5

Command Connector Mini-Broker Acceptor View-Handler -6

Memento -10

Prototype -13

Singleton -19 a ( p )