A Framework for Automated Software Design Optimisation

Transcription

1 A Framework for Automated Software Design Optimisation Lucian Gabor, John Murphy Performance Engineering Laboratory, School of Electronic Engineering Dublin City University, Dublin 9, Ireland {gaborl, A majority of software systems are not designed with performance as a primary consideration. Even if profiling and monitoring tools that can detect various problems are used, these tools don't provide a solution. It takes a very experienced designer or developer to deal with such problems efficiently. A recent development in design practice is the use of design patterns, refactorings and antipatterns. This paper presents a framework that provides a way to automatically correct design problems preserving the functionality of the system and improving its performance. The approach is to provide a system of patterns, antipatterns and refactorings that will produce an optimised system. 1 Introduction Component-based software systems are typically complex and frequently dynamically changing. A large portion of the design effort for such a system is geared toward ensuring the correct functionality of the system, with performance issues taking a back seat in the design procedure. Often, because of the size and dynamic nature of these systems, performance problems are extremely difficult to detect at the design stage. Even when performance problems are detected, their solution is not always clear. The use of patterns has been suggested as good design practice for large-scale software systems [1], [2], [3], [4]. Patterns may be though of as formal descriptions of problems and their solutions. As such, a designer need only match their current situation to existing patterns, and employ the solutions suggested by those patterns. Much research has been done in showing the effectiveness of using patterns to solve functionality problems for large software systems. We propose that patterns may also be used to solve a class of performance problems for large software systems. In this work, we propose to explore the use of patterns, and the closely related concepts of antipatterns and refactoring, to the problem of performance optimisation for large component-based software systems. In Section 2, we will define the major concepts associated with patterns, antipatterns, and refactoring. In Section 3, we will present a framework for using patterns, antipatterns, and refactoring to optimise performance for a system while preserving functionality. In Sections 4 and 5, we will present conclusions and future work.

2 2 Patterns The motivation for using patterns in software systems is that software patterns are smart, generic, well proved, simple and reusable. [1] A pattern is a three-part rule which expresses a relation between a certain context, a problem and a solution. Even the schema that underlies every pattern (context, problem, solution) leads to the idea of pattern automation. Ideally, if a problem and its context are identified then, a pattern that addresses that problem can be applied to obtain a solution. Over time some important characteristics of software patterns have been pointed out. 1. They are observed through experience. A pattern is in fact a recurring solution to a problem that often appears within a specific context [2]. 2. Patterns exist at different level of abstraction. Some patterns deals with structuring software systems into subsystems or refine subsystems or components or the relations between them. These patterns don't have a strong connection to any specific platform or programming language. Other patterns are just opposite. They provide a specific solution to a design aspect for a specific platform or programming language. [3] 3. Patterns can be used together to form a larger solution. A pattern solves a particular problem, but its application may raise new problems. Some of them might be solved by other patterns. One pattern may be integrated into larger one to form together a solution. [3] There is the problem of how to apply patterns in combination to form a larger solution. [2]. Defining clear and homogeneous pattern systems addresses this problem. A pattern system ties its constituent patterns together. It describes how the patterns are connected and how they complement each other. One important characteristic of a pattern system is that it's constituent patterns are divided into different categories. Choosing the right categories for a pattern system is an important task. These criteria for categorisation are a constituent part of the system and guide the process of deciding on the use of a pattern. One general categorisation criterion is the abstraction level that a pattern resides at. There are three major categories of patterns reflecting different levels of abstraction: architectural patterns, design patterns, and idioms. [3] An architectural pattern refers to the practice of organising software into subsystems with specific responsibilities and methods of interaction [4] A design pattern provides a scheme for refining individual components of a software system or the communication channel between components. It solves a general design problem within a particular context. [3] An idiom is a low-level pattern specific to a programming language. It solves a specific problem using the features of the given language. [3] In the case of a more platform specific pattern system one or more abstraction levels might be missing. An example of this is EJB technology and the Core J2EE pattern system [2] known as SJC (Sun Java Center) patterns. The EJB technology is build with respect to Broker architectural pattern [3]. The SJC pattern system uses other architectural patterns such as Model-View-Controller [3] and Pipes and Filters [3]. They don't present idioms since the platform itself is java centric. Instead, for each pattern there is associated a set of strategies that guide the implementation. This is an example of the tight relationship between a technology and a pattern system that address it. In addition to categorisation, based on level of abstraction, patterns may be categorised according to tiers representing their application level. Three tiers are commonly defined - presentation, business and integration. The boundaries of these tiers are well demarcated.

3 Antipatterns are similar to patterns [8]. They document recurring solutions to common design problems. The difference is that their result is negative -- antipatterns tell what to avoid. They also give a solution to fix the problem. For this paper the term patterns will be used to include the concept of antipatterns. The concept of patterns leads to the suggestion that problematic software should be modified to conform to solutions presented in patterns. Refactoring refers to behaviourpreserving program transformations that automate design evolution in object-oriented applications [7]. Clearly, refactoring is a desirable step in the automation of any patternbased design system. 3 Framework We propose a framework that uses patterns as the basis for an expert system to detect performance problems and use refactoring to solve these problems in the system. Ultimately, it would be desirable to have a system that would automatically refactor software based on the patterns detected. For the moment we propose a tool that will discover the patterns associated with a given software system. The input to this tool is a UML representation of the system, possibly annotated with known problems. The output is a set of patterns associated with the software, indicating what improvements can be made. 3.1 Pattern System The base of the correcting mechanism will be a system of patterns and antipatterns. This architecture has two ways to use patterns. There are patterns that are used to understand the system and patterns that can be applied to improve the system. Being included into one of the category does not exclude the possibility that a pattern can belong to the other category as well. 3.2 Non-intrusive Approach An important feature is that the corrected system will maintain the functionality of the original system. In order that this goal is achieved all patterns should be applied nonintrusively with respect to the functionality of the system. Each pattern will have associated strategies to apply them and these strategies will be based on refactoring. In this way each transformation will be "mathematical", refactoring being a very well defined code-level transformation. Another useful technology for the non-intrusive approach of this framework is aspectoriented programming. By defining new ways to apply a pattern using aspect-oriented concepts the original code will remain untouched. This code will be the black box containing the functionality while aspects and concerns will model the business logic. An example would be the Flyweight [4] pattern. The effect of this pattern is that an object is not instantiated until there is an actual need to do so (first invocation on it). In this case one aspect is that before each method invocation the object must be initialised. 3.3 Expert System The tool that accomplishes these tasks will be an expert system. Its knowledge base will be a pattern system that addresses a particular technology. The underlying structure of the knowledge base will follow the meta-model of the UML/MOF [5] [6] specifications. In this way it will address uniformly any object oriented technology. Version 2.0 of UML and MOF defines all UML concepts, relations and semantics using a metamodeling language.

4 Following those definitions in the design of the knowledge base will propagate its precision and correctness. 3.4 Workflow The basic actions that are taken are illustrated as a business model in Figure 1. The input will be the UML model of the target software system. It will have associated audit data that pinpoints problems that need to be solved (if such data is available). The output will be a collection of patterns associated with the system which may be used to refactor the system. 1. The first step will be to understand the model namely, determining what patterns were used in the design of the system. Detected architectural patterns will split the main system into subsystems. Design patterns will refine them and will provide useful information about other patterns that might complement them. Antipatterns will become problems that have to be solved. 2. The second step is to find similarities between the new system and previously processed systems. This will lead to possible new problems that might have eluded the designers. 3. Knowing where a problem resides in the model, its surroundings will be compared with the contexts that are associated with patterns. Detecting a common context between a problem and a pattern provides a solution. 4. Finally the processed model will be stored into the knowledge base, preserving all the problems and patterns that involve it. From this point each identified problem can be corrected by applying the patterns that share its context. This procedure must then be repeated to ensure that new patterns have not generated new side effects. A possible extension is to use simulation and performance prediction tools to test the provided model and to improve it. input model input model Client Interface OrganizingEngin store model determine patterns ModelKnowledgeBas find similar models Pattern find used patterns / antipatterns MatchingEngin find contexts for problems Contex Figure 1

5 3.5 Problem Domain Classes The problem domain is constructed from the following classes (see Figure 2): 1. Model - the UML model of the tested application. 2. Audit Data - profiling and monitoring information linked to elements of the model. 3. The Context forms the connection between patterns and models. Patterns are either directly associated with the context or through platform dependent strategies. 4. Pattern, Context and Strategy form the base of the system. The Pattern domain constitute the underling layer of the knowledge base, dictating it's architecture. ModelKnowledgeBase, Pattern and Context domain classes together form a knowledge base. This knowledge base will contain the patterns that form the pattern system, the models that have been processed and the context that ties the problem from the model to a pattern. Patterns will be separated by their categories. The knowledge base will contain all the relations between patterns and other patterns and between patterns and their context. Models are stored in this knowledge base to reuse the experience acquired when their problems are solved. Also, detected patterns in a model can be associated with previously undefined context. 5. The knowledge base is managed by an organising engine, which has the task of creating all the relations between patterns, models and contexts. 6. The similarities that define these relations are detected by a matching engine, which provides a weighted solution when comparing elements. interface Model include ModelKnowledgeBase organise OrganizingEngine AuditData access use include MatchingEngine refers include Context interface Pattern Strategy Figure 2

6 4 Conclusions It is important to have a well-defined system of patterns that addresses performance issues. This system of patterns must include other patterns that help refine the solution and antipatterns to be able to avoid and correct them. The quality of the pattern system determines the degree of design improvements. Also a very important issue is the definition and representation of the context of a pattern. The automation process depends on it. The fact that it will take a non-intrusive approach will extend the applicability of the correction mechanism. Another important issue is the use of aspect-oriented techniques as they offer new solutions that are highly scalable. 5 Future Work The impact of profiling mechanism as defined in UML 2.0 specifications will be analysed. The idea is to determine how the definition and use of a UML profile for design patterns would improve the precision of pattern/context definition, detection and matching. Another possible impact would be on the structure of the knowledge base. 6 Acknowledgment This research was supported by Enterprise Ireland s Informatics Research Initiative. 7 References [1] H.E. Eriksson, M. Penker: UML Toolkit, John Wiley & Sons, 1997 [2] D. Alur, J. Crupi, D. Malks: Core J2EE Patterns - Best Practices and Design Strategies, Sun Microsystems Press, 2001 [3] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture - a System of Patterns, John Wiley & Sons, 1996 [4] E. Gramma, R. Helm, R. Johnson, J. Vlissides: Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995 [5] C. U. Smith, L. G. Williams: Software Performance Antipatterns, 2nd International Workshop on Software and Performance Proceedings, Sept [6] L. Tokuda, D. Batory: Evolving Object-Oriented Designs with Refactorings, Kluwer Academic Publishers, 2001 [7] [8] [9]