Design Pattern Detection Using Source Code of Before Applying Design Patterns Kazuhiro Fukaya†, Atsuto Kubo†, Hironori Washizaki‡, Yoshiaki Fukazawa† †Waseda University, {hiro220, a.kubo, fukazawa}@fuka.info.waseda.ac.jp ‡National Institute of Infomatics,
[email protected] Abstract We propose an approach of design pattern detection using source-code of before the application of the design pattern. Our approach is able to distinguish different design patterns with similar structures, and help maintainers understand the design of the program more accurately. Moreover, our technique reveals when and where the target pattern has been applied. It is useful to assess what kinds of patterns increase what kinds of quality characteristics.
1. Introduction Detecting design patterns [1] from object-oriented program source-code can help maintainers understand the design of the program. Most of the conventional approaches use static analysis [4, 5]. Since these approaches are based on structural aspects, it is impossible to distinguish different design patterns with the same structure, such as the State design pattern (Figure 1) and the Strategy design pattern (Figure 2). To solve this problem, Wendehals et al. combined static and dynamic analysis [6]. However, the result of dynamic analysis depends on the representativeness of the execution sequences. Moreover, dynamic analysis techniques require runnable programs beforehand. As an another approach, Hahsler has detected design patterns by using comments stored in version archives[2]; however such approach might overlook design pattern applications that are not intended by committers. This paper proposes a design pattern detection technique based on static analysis using source-code of before the application of the design pattern. Our approach is able to distinguish different design patterns with similar structures. This helps maintainers understand the design of the program more accurately. Context
State
request()
handle()
ConcreteStateA
ConcreteStateB
handle()
handle()
Figure 1. State design pattern
Context
Strategy
request()
algorithm()
ConcreteStrategyA
ConcreteStrategyB
algorithm()
algorithm()
Figure 2. Strategy design pattern
2. Our approach Source-code sometimes has parts to where design patterns can be applied, and we use these parts to detect design patterns. We define characteristics and limitations that are commonly found in those parts as ”conditions of smells”. Usually, the conditions of smells can be derived by seeing the following sections of each pattern document: Motivation, Context, Problem, Forces, Solution and Examples. It is not guaranteed that design patterns can be applied to any program that satisfies the conditions of smells. We use the conditions of smells and the conditions used in conventional works (we call them ”conditions of pattern specifications”) together for design pattern detection. Moreover we assume that design patterns are tend to be applied in design improvement phase1 and not applied from the beginning.
2.1
Detection procedure
Maintainers check the source-code which is target for the conditions of smells and pattern specifications whether satisfies the conditions. They examine the relationship between the source-code, such as role of the class in the design pattern. If and only if the relationship is proper, the maintainers judge that the design pattern has been applied. We give two detection procedures: ”forward method” and ”backward method”. Backward method is useful when the design pattern to be distinguished is obvious. Forward method enables maintainers to notice a possibility that the design pattern might have been applied, which conventional approaches failed to detect. Forward method: Maintainers check whether the sourcecode satisfies the conditions of smells from the oldest to the newest version, and suppose that the version did not satisfy the conditions was Ver.K. They checks whether the sourcecode in Ver.K-1 and Ver.K satisfies the conditions of pattern 1 Such
usage is sometimes recommended, such as in [3].
specifications. If and only if both of the source-code do not satisfy the conditions, they check the source-code in Ver.K manually whether the design pattern has been applied. Backward method: Maintainers check whether the sourcecode satisfies the conditions of pattern specifications from the newest to the oldest version, and suppose that the version did not satisfy the conditions was Ver.L. They checks whether the source-code in Ver.L and Ver.L+1 satisfies the conditions of smells. If and only if the source-code in Ver.L satisfies the conditions, they examine relationship between the versions.
2.2
Example
We show an example of detecting design patterns from Java source-code in [3]. Conventional techniques based on static analysis judge that in the source-code with structure like figure 3, State or Strategy has been applied, but cannot distinguish them [4, 5]. First, we define the conditions of smells of State as follows: 1. A method in the Context class has multipart conditional statements that depend on a field. 2. The field’s value is substituted (when changing its state). 3. The field is represented by one or more constants. Similary, we define that of Strategy as follows: 1. A method in the Context class has multipart conditional statements that depend on a field. 2. The field’s value is not changed by Context itself. Second, we check whether the source-code of before applying the design pattern (figure 4) satisfies the conditions of smells of State and Strategy. This step is currently automated using JavaML and XPath for program analysis. PermissionState - name : String + REQUESTED : PermissionState - permissionState + CLAIMED : PermissionState + claimedBy(...) : void + UNIX_REQUESTED : PermissionState + deniedBy(...) : void + UNIX_CLAIMED : PermissionState + grantedBy(...) : void ~ PermissionState(name : String)
SystemPermission
PermissionRequested
PermissionClaimed
+ claimedBy(...) : void
+ deniedBy(...) : void + grantedBy(...) : void
2. state’s value is substituted in the statement. 3. state is represented as constants (CLAIMED, REQUESTED, UNIX REQUESTED, UNIX CLAIMED). Consequently, the program of figure 4 satisfies the conditions of smells of State but not that of Strategy. Thus, we judge that State has been applied in the source-code.
3. Discussion Our technique reveals when and where the design pattern has been applied, which is useful to assess what kinds of design patterns increase what kinds of quality characteristics. Table 1 shows measurement results of applying design metrics (mainly related to maintainability) on the source-code of before and after applying State in [3]. In the result, Lack of Cohesion in Methods (LCOM) got better, Weighted Methods per Class (WMC) and McCabe Cyclomatic Complexity (MCC) decreased. These results suggest that our technique has a capability of identifying designs before applying design patterns as poor ones from the viewpoint of quality. Table 1. Effects on quality measures metric Lack of Cohesion in Methods Weighted methods per Class McCabe Cyclomatic Complexity
before 0.372 8.75 1.667
after 0.143 4.182 1.15
4. Conclusion This paper proposed a technique of desing pattern detection using source-code of before applying the design pattern. Our approach is able to distinguish different design patterns with similar structures, and help maintainers understand the design of the program more accurately. Moreover, our technique reveals when and where the design pattern has been applied, which is useful to assess what kinds of design patterns increase what kinds of quality characteristics.
References ...
Figure 3. Example of applied State public class SystemPermission・ ・ ・ public void claimedBy(SystemAdmin admin) { ・ ・ ・ if (state == REQUESTED) state = CLAIMED; else if (state == UNIX_REQUESTED) state = UNIX_CLAIMED;
Figure 4. Predecessor of Figure 3 1. claimedBy in SystemPermission has multipart conditional statements that depend on state. According to figure 3, SystemPermission is the Context in the State pattern.
[1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [2] M. Hahsler. A quantitative study of the adoption of design patterns by open source software developers. In Free/Open Source Software Development. Idea Group, 2005. [3] J. Kerievsky. Refactoring to Patterns. Addison-Wesley, 2004. [4] J. Niere, W. Schafer, J. Wadsack, L. Wendehals, and J. Welsh. Towards pattern-based design recovery. In Proc. 24th International Conference on Software Engineering, 2002. [5] N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, and S. Halkidis. Design pattern detection using similarity scoring. IEEE Transactions on Software Engineering, 32(11), 2006. [6] L. Wendehals and A. Orso. Recognizing behavioral patterns at runtime using finite automata. In Proc. ICSE Workshop on Dynamic Analysis, 2006.
