Blending design patterns with aspects: A quantitative study

Design patterns often need to be blended (or composed) when they are instantiated in a software system. The composition of design patterns consists of assigning multiple pattern elements into overlapping sets of classes in a software system. Whenever the modularity of each design pattern is not preserved in the source code, their implementation becomes tangled with each other and with the classes’ core responsibilities. As a consequence, the change or removal of each design pattern will be costly or prohibitive as the software system evolves. In fact, composing design patterns is much harder than instantiating them in an isolated manner. Previous studies have found design pattern implementations are naturally crosscutting in object-oriented systems, thereby making it difficult to modularly compose them. Therefore, aspect-oriented programming (AOP) has been pointed out as a natural alternative for modularizing and blending design patterns. However, there is little empirical knowledge on how AOP models influence the composability of widely used design patterns. This paper investigates the influence of using AOP models for composing the Gang-of-Four design patterns. Our study categorizes different forms of pattern composition and studies the benefits and drawbacks of AOP in these contexts. We performed assessments of several pair-wise compositions taken from 3 medium-sized systems implemented in Java and two AOP models, namely, AspectJ and Compose*. We also considered complex situations where more than two patterns involved in each composition, and the patterns were interacting with other aspects implementing other crosscutting concerns of the system. In general, we observed two dominant factors impacting the pattern composability with AOP: (i) the category of the pattern composition, and (ii) the AspectJ idioms used to implement the design patterns taking part in the composition.     

A framework for early design and prototyping of service-oriented applications with design patterns

Service-oriented computing is playing an important role in several domains. Today the biggest shift in mainstream design and programming is toward service-oriented applications. However, the service paradigm raises a bundle of problems that did not exist in traditional component-based development where abstraction, encapsulation, and modularity were the only main concerns. Due to their distributed, dynamic, and heterogeneous nature, service-oriented software applications require us to discover, document, and share new design patterns at the service- and architecture-level. Moreover, service-oriented applications are hard to design and validate, and demand for new foundational theories, modeling notations and analysis techniques.In line to such a vision, this article presents a framework, called SCA-PatternBox, to design and prototype service-oriented applications with design patterns. The framework relies on the OASIS standard Service Component Architecture (SCA) and on SCA component implementation types, such as SCA-Java, for supporting an “implementation-oriented” approach to service-oriented architecture modeling and to the definition and instantiation of design patterns. Moreover, in order to provide formally verified design patterns, SCA-PatternBox allows the formal specification and analysis of the functional behavioral aspects of a design pattern using a formal service specification language called SCA-ASM (Service Component Architecture-Abstract State Machine). As major evaluation of the framework, two case studies and lessons learned are presented. A final comparison of existing design pattern languages is also reported.     

Distribution and persistence as aspects

This paper reports our experience using AspectJ, a general‐purpose aspect‐oriented extension to Java, to implement distribution and persistence concerns in a Web‐based information system. This system was originally implemented in Java and restructured with AspectJ. Our main contribution is to show that AspectJ is useful for implementing several persistence and distribution concerns in the considered application, but also in similar applications. We have also identified interferences between the implemented aspects and a few drawbacks in the language, so we suggest some minor language modifications that could significantly improve similar implementations. Despite those problems, we argue that the AspectJ implementation is superior to the pure Java implementation. Some of the aspects implemented in our experiment are abstract and constitute a simple aspect framework. The other aspects are application specific but we suggest that different implementations might follow the same aspect patterns. The framework and the patterns allow us to propose architecture‐specific guidelines that provide practical advice for both restructuring and implementing certain kinds of persistent and distributed applications with AspectJ. Copyright © 2006 John Wiley & Sons, Ltd.     

基于AOP技术的Composite模式的改进

Composite模式是解决部分与整体关系时常用的设计模式,但基于面向对象设计(OOP)所实现的Composite模式中存在的问题很难利用OOP解决。该文应用面向方面编程(AOP)改变类的行为,利用AspectJ实现Composite模式,通过与以OOP技术实现的Composite模式比较,得出应用AOP方法能够较好地实现责任分离,具有较高的可扩展性,模块结构更清晰。     

An exploratory study on cooccurrence of design patterns and bad smells using software metrics

A design pattern is a general reusable solution to commonly recurring problems in software projects. Bad smells are symptoms existing in the source code that possibly indicate the presence of a structural problem that requires code refactoring. Although design pattern and bad smells be different concepts, literature has shown that they may be related and cooccur during the evolution of a software system. This paper presents an empirical study that investigates cooccurrences of design patterns and bad smells as well as identifies the main factors that contribute to the emergence of the relationship between them. We carried out a case study with five Java systems to: (1) investigate if the use of design pattern reduces bad smell occurrence, (2) identify cooccurrences of design patterns and bad smells, and (3) identify situations that contribute for the cooccurrence emergence. As the main result, we found that the application of design pattern not necessarily avoid bad smell occurrences. The results also show that some design patterns such as composite, factory method, and singleton, are intrinsically modular and might be useful in creating high-quality systems. However, other design patterns such as adapter-command, proxy, and state-strategy, have presented high cooccurrence frequency with bad smells; therefore, they require attention in their implementation. Finally, via manual inspection in the components with cooccurrence, we found that the identified cooccurrences appeared due to poor planning and inadequate application of design patterns.     

Remoting patterns: design reuse of distributed object middleware solutions

Patterns and pattern languages offer a practical means for distributed system developers to both gain a deeper understanding of the middleware they use and to convey their knowledge about it The proposed Remoting pattern language offers a systematic way to reuse software models, designs, and implementations to extend, integrate, customize, or build distributed object middleware solutions. This pattern language has rich dependencies with other patterns and pattern languages from related domains, including networking, concurrency, and resource management.     

Utilizing patterns and pattern languages in education

This paper presents work that has been done in bringing patterns and pattern languages into undergraduate and postgraduate curricula in software engineering. Patterns are masterful designs that solve a real problem; they provide students with real, concrete examples of best practises and masterful software solutions they can utilize and emulate. A pattern language is a modular and adaptive methodology; it is appropriate for the dynamic discipline of software engineering. The paper outlines aspects of a curriculum used at the Royal Melbourne Institute of Technology; it also provides student and staff feedback.     

Design dysphasia and the pattern maintenance cycle

Software developers utilize design methods that enable them to manipulate conceptual structures that correlate to programming language features. However, programming languages and the programming paradigms they embody co-evolve over time. Within industrial and academic circles, for example, object-oriented programming has evolved and effectively replaced imperative programming. More recently, many object-oriented languages have assimilated features from other programming paradigms, evolving into multiparadigm languages we refer to as ‘object-oriented plus–plus’ or OO++. This language evolution may weaken the interface between design and implementation, introducing what we call ‘design dysphasia’—a partial disability in the use of a programming language because of incongruous design methods. Software design patterns capture elements of reusable design within a specific context. When the programming languages that are part of pattern context evolve, patterns must adapt to the language change or they may reinforce design dysphasia in the practitioner. We assert that the current ‘capture/recapture’ pattern maintenance model is suboptimal for adapting patterns to language evolution and propose a new ‘capture/modify/recapture’ maintenance cycle as a more effective approach. We then suggest a concrete ‘modify’ phase for current patterns to be adapted to object-oriented based multiparadigm language trends. We present an OO++ Iterator pattern as an example throughout.     

A constraint-weaving approach to points-to analysis for AspectJ

Points-to analysis is a static code analysis technique that establishes the relationships between variables of references and allocated objects. A number of points-to analysis algorithms have been proposed for procedural and object-oriented languages like C and Java, while few of them can be used for AspectJ as we know so far. One main reason is that AspectJ is an aspect-oriented language which implements the separation of crosscutting concerns by advices, pointcuts, and inter-type declarations, while a points-to analysis of AspectJ programs may be imprecise because any aspect woven into the base code may change the points-to relations in the program and thus a conservative analysis has to be taken in order to handle the aspects. In this paper, we propose a context-sensitive points-to analysis technique called AJPoints for AspectJ. Similar to the weaving mechanism for AspectJ, AJPoints obtains the constraints and templates on the points-to relations for the base code and the aspects, respectively, but weaves and solves them in an iterative manner in order to cross the boundary between the base code and the aspects. We have implemented AJPoints on abc AspectJ compiler and evaluated it by using twelve AspectJ benchmark programs. The experimental results show that our technique can achieve a high precision about points-to relations in AspectJ programs.     

Regular patterns, regular languages and context-free languages

In this paper we consider two questions. First we consider whether every pattern language which is regular can be generated by a regular pattern. We show that this is indeed the case for extended (erasing) pattern languages if alphabet size is at least four. In all other cases, we show that there are patterns generating a regular language which cannot be generated by a regular pattern. Next we consider whether there are pattern languages which are context-free but not regular. We show that, for alphabet size 2 and 3, there are both erasing and non-erasing pattern languages which are context-free but not regular. On the other hand, for alphabet size at least 4, every erasing pattern language which is context-free is also regular. It is open at present whether there exist non-erasing pattern languages which are context-free but not regular for alphabet size at least 4.     

Study of advanced separation of concerns approaches using the GoF design patterns: A quantitative and qualitative comparison

ContextSince the emergence of the aspect oriented paradigm, several studies have been conducted to test the contribution of this new paradigm compared to the object paradigm. However, in addition to this type of studies, we need also comparative studies that assess the aspect approaches mutually. The motivations of the latter include the enhancement of each aspect approach, devising hybrid approaches or merely helping developers choosing the suitable approach according to their needs. Comparing advanced separation of concerns approaches is the context of our work.ObjectiveWe aim at making an assessment of how the aspect approaches deal with crosscutting concerns. This assessment is based on quantitative attributes such as coupling and cohesion that evaluate the modularity as well as on qualitative observations.MethodWe selected three of well-known aspect approaches: AspectJ, JBoss AOP and CaesarJ, all the three based on Java. We conducted then, a comparative study using the GoF design patterns. In order to be fair we asked a group of Master students to achieve the implementation of all patterns with the three approaches. The use of these implementations as hypothetical benchmarks allowed us to achieve two kinds of comparison: a quantitative one based on structural and performance metrics, and qualitative one based on observations collected during the implementation phase.ResultsThe quantitative comparison shows some advantages like the using of fewer components with AspectJ and the strong cohesion with CaesarJ and weaknesses, as the high internal coupling caused by the inner classes of CaesarJ. The qualitative comparison gives comments about the approach understandability and others qualitative concepts.ConclusionThis comparison highlighted strengths and weaknesses of each approach, and provided a referential work that can help choosing the right approach during software development, enhancing aspect approaches or devising hybrid approaches that combine best features.     

Execution levels for aspect-oriented programming: Design,semantics, implementations and applications

In aspect-oriented programming (AOP) languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression, and gives advanced programmers the means to override this default using level-shifting operators. We then study execution levels both in practice and in theory. First, we study the relevance of the issues addressed by execution levels in existing aspect-oriented programs. We then formalize the semantics of execution levels and prove that the default semantics is indeed free of a certain form of infinite regression, which we call aspect loops. Finally, we report on existing implementations of execution levels for aspect-oriented extensions of Scheme, JavaScript and Java, discussing their implementation techniques and current applications.     

A UML-based pattern specification technique

Informally described design patterns are useful for communicating proven solutions for recurring design problems to developers, but they cannot be used as compliance points against which solutions that claim to conform to the patterns are checked. Pattern specification languages that utilize mathematical notation provide the needed formality, but often at the expense of usability. We present a rigorous and practical technique for specifying pattern solutions expressed in the unified modeling language (UML). The specification technique paves the way for the development of tools that support rigorous application of design patterns to UML design models. The technique has been used to create specifications of solutions for several popular design patterns. We illustrate the use of the technique by specifying observer and visitor pattern solutions.     

Systematic pattern selection using pattern language grammars and design space analysis

Software patterns provide reusable solutions to recurring design problems in a particular context. The software architect or designer must find the relevant patterns and pattern languages that need to be considered, and select the appropriate patterns, as well as the best order to apply them. If the patterns and pattern languages are written by multiple pattern authors, it might be necessary to identify interdependencies and overlaps between these patterns and pattern languages first. Out of the possible multitude of patterns and pattern combinations that might provide a solution to a particular design problem, one fitting solution must be selected. This can only be mastered with a sufficient expertise for both the relevant patterns and the domain in which they are applied. To remedy these issues we provide an approach to support the selection of patterns based on desired quality attributes and systematic design decisions based on patterns. We propose to formalize the pattern relationships in a pattern language grammar and to annotate the grammar with effects on quality goals. In a second step, complex design decisions are analyzed further using the design spaces covered by a set of related software patterns. This approach helps to systematically find and categorize the appropriate software patterns—possibly even from different sources. As a case study of our approach, we analyze patterns from a pattern language for distributed object middleware. Copyright © 2006 John Wiley & Sons, Ltd.     

基于SDL模式的通信协议开发

研究了设计模式和形式化描述语言SDL相结合的SDL模式技术,分析了通信协议开发中存在的两类SDL模式:结构模式和行为模式,提出了一种基于SDL模式开发通信协议软件的方法,并通过PPP协议的开发实践验证了该方法的可行性.该方法可以有效的重用已有成功的软件开发成果,减少通信协议软件开发难度,缩短系统开发周期,提高软件质量.     

Excessively duplicating patterns represent non-regular languages

A constrained term pattern s:φ$s:\phi$ represents the language of all instances of the term s satisfying the constraint φ. For each variable in s, this constraint specifies the language of its allowed substitutions. Regularity of languages represented by sets of patterns has been studied for a long time. This problem is known to be co-NP-complete when the constraints allow each variable to be replaced by any term over a fixed signature, and EXPTIME-complete when the constraints restrict each variable to a regular set. In both cases, duplication of variables in the terms of the patterns is a necessary condition for non-regularity. This is because duplications force the recognizer to test equality between subterms. Hence, for the specific classes of constraints mentioned above, if all patterns are linear, then the represented language is necessarily regular. In this paper we focus on the opposite case, that is when there are patterns with “excessively duplicating” variables. We prove that when each pattern of a non-empty set has a duplicated variable constrained to an infinite language, then the language represented by the set is necessarily non-regular. We prove this result independently of the kind of constraints used, just assuming that they are mappings from variables to arbitrary languages. Our result provides an efficient procedure for detecting, in some cases, non-regularity of images of regular languages under tree homomorphisms.     

Automated verification of design patterns: A case study

Representing design decisions for complex software systems, tracing them to code, and enforcing them throughout the lifecycle are pressing concerns for software architects and developers. To be of practical use, specification and modeling languages for software design need to combine rigor with abstraction and simplicity, and be supported by automated design verification tools that require minimal human intervention. This paper examines closely the use of the visual language of Codecharts for representing design decisions and demonstrate the process of verifying the conformance of a program to the chart. We explicate the abstract semantics of segments of the Java package java.awt as a finite structures, specify the Composite design pattern as a Codechart and unpack it as a set of formulas, and prove that the structure representing the program satisfies the formulas. We also describe a set of tools for modeling design patterns with Codecharts and for verifying the conformance of native (plain) Java programs to the charts.