Aspect-driven design of Information Systems Karel Cemus and Tomas Cerny Department of Computer Science and Engineering, Czech Technical University, Charles square 13, 121 35 Prague 2, CZ
[email protected],
[email protected]
Abstract. Contemporary enterprise web applications deal with a large stack of different kinds of concerns involving business rules, security policies, cross-cutting configuration, etc. At the same time, increasing demands on user interface complexity make designers to consider the above concerns in the presentation. To locate a concern knowledge, we try to identify an appropriate system component with the concern definition. Unfortunately, this is not always possible, since there exist concerns cross-cutting multiple components. Thus to capture the entire knowledge we need to locate multiple components. In addition to it, often, we must restate the knowledge in the user interface because of technological incompatibility between the knowledge source and the user interface language. Such design suffers from tangled and hard to read code, due to the cross-cutting concerns and also from restated information and duplicated knowledge. This leads to a product that is hard to maintain, a small change becomes expensive, error-prone and tedious due to the necessity of manual changes in multiple locations. This paper introduces a novel approach based on independent, description of all orthogonal concerns in information systems and their dynamic automated weaving according to the current user’s context. Such approach avoids information restatement, speeds up development and simplifies maintenance efforts due to application of automated programming and runtime weaving of all concerns, and thus distributes the knowledge through the entire system. Keywords: Aspect-oriented design, Business logic, Model-driven development, Reduced maintenance and development efforts
1
Introduction
Contemporary design of information systems face multiple challenges caused by inability of present-day technologies to encapsulate business logic and implement self-maintainable user interfaces. It is a common practice [1] to capture business rules and security policy tangled through all layers of the application. This is mostly notable in the presentation layer, which results with its source code barely maintainable. Such design then exhibits issues with consistency. For example, a minor change to the application data model, e.g. a field type, or its constraint, requires manual change propagation into multiple other locations. This becomes
2
K. Cemus, T. Cerny
very tedious and error-prone especially for presentations built with languages without type safety. A model change then requires the developer to issue a text search for its references in the presentation and to adjust the code. In [10] authors discuss that information restatement in the presentation is the source of increased maintenance. Although, information restatement is not the only problem involved in extensive maintenance. Application design becomes hard to maintain when it exhibits cross-cutting concerns [2], such as business rules or security concerns. In this paper we introduce a novel aspect-driven approach to deal with the above mentioned issues. The fundamental idea of the concept lies in the separation of application business rules from the application code base. Instead an aspect-language is used to capture these rules, which allows us to encapsulate all application rules to a central location. Next, it allows us to automatically enforce application business rules or to generate context-aware user interfaces. As a consequence, a data model change directly propagates to the rest of the system which enforces its integrity. Such approach leads to efficient maintenance of the entire system business logic and application user interface (UI). The main benefit of the presented approach is prevented information restatement achieved by having a single location for definition of each system knowledge. Such knowledge can be automatically distributed to other parts of the system at runtime. This reduces system element coupling, supports reuse and rule enforcement at the same time. Furthermore, such separation of concerns allows us to reuse system elements and transform them to automated UIs presentation of data elements. This paper is organized as follows: In section 2 we provide the background of the contemporary approaches. The related work is discussed in section 3. Description of our approach is provided in section 4. Next, a case study and its evaluation in section 5. We end the paper with conclusion and future work.
2
Background
Existing development approaches often use the three-layered architecture model [5], which divides the functionality into three encapsulated components. The lowest layer is responsible for data persistence and accessing third-party services. The middle one encapsulates business logic, which exposes through public interfaces to the top, presentation layer. The top layer deals with UI, provides access to the functionality and different views on data, communicates to user and processes his responses. Despite clear definition of responsibilities for each layer, there exists a certain group of problems that cannot be simply encapsulated in any of these layers. Furthermore, it must be noted that contemporary development approaches such as Object-oriented design does not provide effective mechanisms to encapsulate these problems [11,14]. This group of problems is in literature called cross-cutting concerns [13] due to their characteristics - they cut across the whole application and have to be considered at multiple places in all these layers, we can look at
Aspect-driven design of Information Systems
3
them as on layers orthogonal to this linear architecture. For example, consider logging, exception management, security, etc. Business logic, also a cross-cutting concern [1], must be considered at multiple places such as in the UI (rendering and input validation phases), or as an input validation policy of business operations or as a data model integrity check [2]. Based on our research that involved inspection of a large information system ACM-ICPC, we found out that there exists three categories of highlevel rules: contextless, contextual and cross-cutting rules. The contextless rules are understood as validation rules, which have to be satisfied always and everywhere otherwise it would break data consistency or integrity. For example: ‘Username must be at least 6 characters long’. The second group consists of contextual rules. These rules are considered within given context, such as: Student’s GPA must be higher than 3.8, when he applies for a scholarship. The last group are rules that apply under given conditions nearly everywhere. These rules are often parametrized by application state or user’s profile. For example, consider a rule: ‘System is not locked for editing’. Such rule has a vast area of impact, because there may exist a deadline date after which no changes are allowed. Listing 1. Scenario: User registration preconditions : - username is not empty - password has at least 6 characters - email address is valid successful path : ...
Next, consider a business operation described as a single use-case or a user scenario. For example, consider the implementation in Listing 2, which is a common example of the contemporary approach in development. This operation defines multiple pre-conditions that determine position of the operation in an application domain. It means, the operation can only be performed when all the pre-conditions are satisfied. From another perspective this is nothing else than a few business rules. Thus we can look at it from the perspective of a business context of a given operation. The context then compounds multiple business rules. With clearly defined application contexts every operation can address one. Listing 2. Standard scenario implementation void // // if if if // }
register ( User user ) { Check for violation of any rule . The validation is vastly duplicated across whole application code . It can be reduced but not avoided . ( isEmpty ( user . username ) ) { ... } ( ! i s S t r on g P a s s w o r d ( user . password ) ) { ... } ( ! isEmail ( user . email ) ) { ... } user is valid , register him
The role of business rules in an application is complex, because there are many locations where they have to be considered. For example, every form in the UI has to include a proper validation that is determined by the field data type and business policy. During a page rendering phase, every UI element has to determine whether it should apply and if so then how, which bases on the user context, the application state, security policy and the business rules that are usually parametrized by user’s profile. Unfortunately, contemporary technolo-
4
K. Cemus, T. Cerny Dimensions 1-3 Data model presentation
Dimensions 4-6 Input validation
Localization
Security policy Layout for target device Linear Implementation space Security
Validation
etc. Data model presentation Layout Localization
Fig. 1. Facets considered in user interface
gies does not think of business rules as about a crucial part of the application, which requires a special support, so they do not implement mechanisms providing efficient business policy handling. In consequence, the only business policy implementation in Java EE available by now [4] builds on high information restatement and source code duplication, as is shown in Listing 2. User interface is the most difficult and complex part of every software application. Its quality decides about products attractiveness, usability and marketability, because even the best functionality without user friendly interface is nearly worthless. In conclusion, UI development is crucial and important part of software life-cycle. Its source code comprises up to 48% of total application code [10], thus any inefficiency in UI development can cause significant issues. Unfortunately, UI implementation is highly difficult task because there have to be considered multiple concerns. Final UI appearance is affected by the data model presentation, application state, current user’s profile, target device layout, security policy, input validation, localization, etc [2]. In deeper analysis we find out that all these concerns can be seen as mutually orthogonal domains, which have to be serialized into renderable linear source code, as is illustrated on Fig. 1. Such code involves for each field more than just a style of presentation and visibility status, but for example also the whole page must be structured into some layout derived from target device. Unfortunately, all these parameters depend on multiple variables from orthogonal domains. When we think about this background carefully, we realise that each of this mentioned concerns can be described completely in its own, nearly independent, way. For each facet can be defined e.g. set of layout templates, set of security rules, localization files, component templates, etc. so we can look at it as on building multidimensional space where each request gain multiple values from distinct domains. It is just like placing the single point into multidimensional space. The only thing connecting all these distinct planes is the current context, which parametrizes all of them and is brought by a request. In the light of this domain decomposition we can see that we face to the new problem: linearisation. We need to figure out how to seamlessly, automatically and efficiently integrate all these given heterogeneous descriptions of all distinct domains and construct the renderable linear source code parameterizable with the current user’s and application’s context.
Aspect-driven design of Information Systems
5
Contemporary technologies focus on performance, short syntax, powerful isolated components (e.g.: graphical components, caching, injection providers etc.) but only a few of them actually realise the importance of knowledge caught inside of application source code and such tools bring only partial solutions which cover only simple scenarios. In consequence, there are no tools nor ways how to efficiently deal with knowledge representation and integration which forces developers into manual linearisation of heterogeneous distinct domains as described above. Such output suffers from high information restatement and multiple different policies tangled together and through the whole application. In result, such code is difficult to maintain and any change means localization and modification of multiple places, which is tedious, expensive and error-prone.
3
Related Work
This paper addresses multiple issues related to business policy management, application design and source code generation to provide efficient way how to deal with knowledge representation without unnecessary information restatement. Importance and complexity of business rules discuss authors in [1]. Together with analysis of three-tiered information systems they introduce couple solutions how to reduce maintenance effort of business rules in the middle layer. The proposed solutions proceed from design patterns [5][7], but still their solution suffers from some code duplication. Standardized Java EE development [4] brings up usage of Chain of Responsibility [7] design pattern inserting external processors before business operation invocation. Such approach would allow e.g. input validation invocation before the operation calls, but due to detached connection to the method, it is not invoked during intra-class operation calls. Besides that, there is no good design support for target method inspection and invocation flow modification. In conclusion, this method is not suitable for application to the whole system, rather only to the business layer. Inconvenience of manual code duplication and information restatement is discussed in [12][3]. Model driven architecture (MDA) brings up the idea of system modelling in a graphical language, such as UML. Such model represents the knowledge and main source of information as well as a convenient input for tools generating source code. Although MDA generates source code, the whole process is run just once, because its output must be extended with another code snippets. That makes the model updates complicated as the modified code gets lost upon subsequent model to code transformations. Furthermore, the whole concept is derived form object oriented paradigm, which suffers from inability to reflect cross-cutting concerns, thus also this approach preserves code duplication and information restatement. A technique of automatic programming is also based on reality modelling and following source code generation, but with two significant differences. The first one is a language. While the MDA usually uses UML and OCL for model and knowledge representation, automatic programming uses domain specific lan-
6
K. Cemus, T. Cerny
guages [6], which are efficient in target domain description. For example, they involve templates and special mark-up derivatives. Another difference is in the way of code generation. While the MDA uses static generation, that runs usually once or only a few times, the automatic programming uses dynamic source code generation executed on each project compilation or even at runtime. Such improvement brings more dynamics into models, because on any change in the domain description the target source code can be automatically updated. With a smart and powerful generator and suitable domain description we are able to completely avoid manual code duplication and achieve simply and neatly modifiable application implementation. The whole concept is introduced in [9]. Object oriented paradigm (OOP) dominates to systems design and brings multiple efficient principles. But there is no silver bullet and it has limitations, such as dealing with the cross-cutting concerns. The OOP is unable to encapsulate it into single component [14], which results in vast code duplication and tangling, which is tedious, inefficient, error-prone and complicates the maintenance. The aspect oriented programming (AOP) introduced in [11] presents an alternative concept focused on realisation of cross-cutting concerns. This paradigm comes with a new terminology. It considers two types of components, besides the OOP (or general) components, there are also components that are understood as a single cross-cutting concern, called aspects. They comprises of pointcuts and advices. A pointcut is an expression addressing all locations in the OOP components where and when the aspect should apply. Such spots addressed by pointcuts are called join-points. In [14] authors differentiate between static joinpoints, characterised as locations in the program’s source code, and dynamic join-points, defined as points in the execution of a program that consider runtime context. When the aspect’s pointcut applies, it uses an advice, the extension of the functionality invoked when the execution-flow reaches the addressed joinpoints, or a composition rules [14]. In general, the goal of advising is modification, integration or an extension of the wrapped functionality. Aspects are weaved to the OOP components through a simple compiler or an integration tool called aspect weaver. Aspects are often described by domain specific languages and typical instances of them are security managers, cache providers and exception handlers. Both paradigms are usable together as a multiparadigmatic design. When we are looking for existing and verified solution efficiently dealing with business rules we have to look at rule-driven production systems [8], which represents target domain by huge set of business rules comprised of preconditions and actions. Each rule represents description of some situation or event and also contains a properly defined reaction to do when it occurs. Strong advantage of these systems is knowledge stored outside the compiled source code and usage of domain specific languages, which allows delegation of rules design and management to domain experts and frees developers. The comparison of knowledge represented inside of production systems to business policy of information systems must conclude that the business policy is light version, subset, of production systems. This awareness opens many possibilities like usage of production system engine and kind of knowledge representation in new context.
Aspect-driven design of Information Systems
4
7
Aspect Approach
Each software system consists of a static and a dynamic part. As the static part we perceive the data model, its fields and their types, which is immutable and stable concern. From the data model we derive the UI elements for data visualization. Set of business rules such as validation, integrity constrains, context verification policy etc. is also stable and usually immutable, so we involve it into the static part. Processing of this concerns can be done once, for example at the compile time. On the other hand, the output of each request differs in the exact composition of UI, in validation rules, presented data and available actions. All these dynamic aspects depend on a position of user’s context in a multidimensional space. Efficient and proper processing needs runtime evaluation and integration of all those concerns, including preprocessed the static ones. Considering the example from section 2 and conclusion from previous paragraph we are looking for a way allowing us to statically integrate business rules into the whole system and generate a proper UI structure based on the data model. In addition, all these parts must consider concerns such as target device, security, etc. and weave them together at runtime on each request. The AOP, which is designed to handle cross-cutting concerns and weave heterogeneous sources, together with a technique of automatic programming seems to be a convenient way to process all descriptions of distinct domains and weave them into a resulting source code. 4.1
Transformation into Terms of AOP
Application of AOP requires transformation of the domain into a new terminology. The AOP comes with multiple terms which we must define in examined domains: join-point, pointcut, advice, aspect language and finally aspect weaver. UI concerns involve both static and dynamic parts of the system. For example, we can think of a UI form/table as of data visualization. Such form must reflect the data structure and provide presentation for each its field, although we must consider also dynamic information such as security, selected layout, conditional rendering, etc., which may influence the resulting presentation. In the visualization we use a data structure as the base component used for AOP composition. To visualize the data in the UI we use its static structure as a source for static join-points. Among them we consider entity and field names, their data types, and field annotations with their parameters. Considered joinpoints also include dynamic join-points to integrate dynamic aspects. In order to keep our approach general it is possible to pass to the weaving context a runtime information such as user access rights, geo-location, local context for presentation, device screen size, etc. All dynamic join-points are used in the visualization. The goal of this process is composition similar to Hyper/J aspect oriented system. The first level aspect is field presentation, for this we use presentation rules. Its pointcuts can query the visualized data and context for given properties such as whether a given visualized field is a string with given length restriction or whether it is ‘Friday’ and the end user is ‘administrator’ with
8
K. Cemus, T. Cerny
small screen size. Pointcuts can address all join-points, logical combination and use arithmetical operations. The advice provides an integration template that uses the target presentation language and composition rules to integrate secondlevel aspects, such as validation, business rules, internationalization, etc. These aspects use pointcuts identical with the first-level and their advice define a composition rules. After all data fields are processed by first and second level aspects the result is decorated by a layout template providing a third-level aspect the layout. The aspect weaver is attached to the presentation language as a special component. Designer then uses this component to visualize data at the page and defines the aspect integration through the weaver configuration and the integration templates. Dynamic join-points can be passed to the weaver through the special component, or by a system context. The life-cycle then looks as follows. A page renderer processes the view code, once it reaches a special component it calls its custom handler that integrates the weaving. It takes the data instance passed to the component and gets its static join-points, it may pass the dynamic join-points to the weaver at this point. Next, the weaver walks through the data structure and for each field applies presentation rules. Based on field properties and the context it selects a composition template that defines the presentation and extends it with other aspects. The result of this transformation is decorated by layout. The generated target code is compiled and embedded to the page. Business rules as a unit must be considered on multiple types of locations, e.g. input validation in business operations, input validation in UI or access restriction to data and operations based on context and security policy. In all these locations it is necessary to apply these rules. In terminology of AOP, such places are join-points. Although business rules can be defined as a standalone unit describing single domain, in each context they apply a bit differently. For example, in business layer they are evaluated against given context and input values, but in the UI they must be decomposed and transformed into a client-side validation. In consequence, rule transformation must be handled in multiple ways based on target context. Each way then applies on a subset of join-points which is selected through the pointcut and the concrete rule transformation is performed by the advice extending target locations. Kind of transformation differs per target context, because for input validation in business layer we demand input and context evaluation against business policy, while for client-side validation in the UI we require rules decomposition and transformation into e.g. a scripting language. As mentioned earlier, verified solution for business rules representation are domain specific languages used in a core of rule-driven systems, which stand here for the aspect language. Finally, as an aspect weaver can be considered any processor enhancing target join-points with new functionality. In a single system can be recognized multiple weavers, because the UI is usually described by different language than the business layer, thus weavers must support composition into these output languages. While for executable code would be enough to automatically prepend invocation of input validation mechanism, for the UI described using a mark-up language must be the source code completely recreated and completed with new checkers, validators and converters.
Aspect-driven design of Information Systems
9
Appearance of the UI differs per request based on the current context, evaluation of business rules and many other disjunct concerns. Basically, the resulting UI becomes variable and dynamic, and the final product must be composed from components on each request. Applying component preparation and final integration using automated programming and complex aspect weavers for all the domains, we can achieve the desired appearance and behaviour because the runtime weaving relieves us from the duty of manual information restatement. 4.2
Implementation
Based on the informal specification we implemented an aspect oriented framework for automatic integration of business rules and dynamic constructing of context-aware user interfaces. Each independent concern is described in the most convenient, domain specific language to give us the best possible performance and effortless maintenance. Usage of a core of rule-driven system brings us an efficient way of business policy representation as is shown in Listing 3 and Listing 4. Furthermore, its engine is designed on high evaluation performance. Listing 3. Simple entity constraint rule " [ Team ] Standard validation " when Team ( ! isEmpty ( name ) , coach != null , members . size () == 3 , members not contains coach ) then end
Listing 4. Security check rule global Set < String > security rule " [ Security ] Admin " when eval ( security . contains ( SecurityRole . ADMIN ) ) Person () || ... || Contest () then end
One of significant issues we faced was operational context addressing. As is noted in section 2, each operation and action stands in its specific business context in an application domain. Three-layered system architecture recognizes multiple types of entry points, e.g. actions on controllers in the UI, web service actions and operations on services in the business layer. Each of these actions may stand in different context, so it is crucial to match them to contexts with this granularity. We decided for application of meta-instructions such as Java annotations. This construct opens efficient way to matching an operation to its context externally defined as a set of rules and groups of rules. Afterwards, inspection of method signatures allows extraction of their context address as is illustrated by Listing 5 and Listing 6. Efficient definition of business context opens the way to application of AOP to enhance chosen spots by application of additional instructions, such as input validation. Listing 5. Descriptive business context @Validate @ S t a n d a r d V a l i d a t i o n @Req uiredRu les ( " Password is strong " ) void register ( User user ) { // user is valid , register him }
Listing 6. External bussines context @Validate @ B u s i n e s s C o n t e x t ( " user / register " ) void register ( User user ) { // user is valid , register him }
The data visualization becomes trivial. Listing 7 presents a component that takes a data instance (an data object) as a parameter, in our case user, and visualizes it on the page. This produces an UI form or a table depending on
10
K. Cemus, T. Cerny
the component properties. The weaving process considers each data field and applies all three levels of aspects (presentation, field extension and layout). A presentation rule example with a pointcut and an advise is shown in Listing 9, it shows presentation of String-typed field and advices to composition templates. An example composition template with shorten version of the pointcut/advise is shown in Listing 8. This template shows the representation an extension of its properties by considered aspects and supplying the data context to the template. The layout integration through a layout template is shown in Listing 10. Listing 7. Aspect-driven UI
Listing 8. Composition template
< af:ui instance = " #{ user } " rende rPasswo rd = " false " layout = " #{ device . layout } " / > < h:button value = " Ban user " rendered = " #{ g:ctx ( bean , ’ ban ’ , user ) } " />
< x:inputText id = " #{ prefix }$ field $ " label = " #{ text [ ‘$ entity $.$ field $ ‘]} " edit = " #{ empty edit $ field $ ? edit : edit $ field $} " validate = " $ businessRules . toJS () $ " size = " $ size $ " req = " $ required $ " value = " #{ instance .$ field $} " ../ >
Listing 9. Presentation rules
Listing 10. Two column layout template
< type > String < default tag = " textTag . xhtml " / > < cond expr = " ${ email == true } " tag = " emailTag . xhtml " / > < cond expr = " ${ link == true } " tag = " linkTag . xhtml " / > < cond expr = " ${ maxLength >255} " tag = " textAreaTg . xhtml " / >
5
< table class = " two - column - layout " > < af:iteration - part > < tr > < td >$ af:next $ < td >$ af:next $
Case Study
Frameworks designed with respect to the informal specification described in previous section was applied in an experimental application. The goal is to receive preliminary statistics on efficiency in comparison to the common approach. In the measurement we focused on SLOC (Source Lines Of Code) and maintenance effort. Besides that we wanted to evaluate the amount of remaining restated information to lay down our future work. For the application domain we choose inspiration in the ACM-ICPC programming contest, for which we designed a light registration system. As an implementation platform was chosen Java EE with the support of Spring framework and JavaServer Faces for the presentation layer. The main goal of this designed system was handling of state-flow of team applications to local contests. To design a real application we considered four security roles: member, coach, manager and administrator; the system’s domain model is captured on Fig. 2. To illustrate the power of approach in automatic transformation we designed 32 business rules including all kinds of conditions, from simple constraints to complex time-conditioned cross-cutting rules, such as ‘Applications are opened’. To gain preliminary evaluation of this approach we manually developed the same system with the same coding standards and technologies, but without the application of proposed solution. The final comparison of SLOC is covered in Table 1. The results clearly point out reduction of the amount of source
Aspect-driven design of Information Systems
*
11
*
1 1 coach
belongsTo *
* member 0..1
*
1
registeredTo *
*
application
1
Fig. 2. Data model of registration system to programming contest
code in business and presentation layers, but in return of increased amount of meta-instructions. Such results were expected, because due to the automated programming there is dynamically generated significant amount of code at runtime, which comes out of the weaving of multiple disjunct domains, where some of them are connected via business rules addresses in meta-instructions. We must consider that our application is rather lite, thus the code statistics would become considerably better with the growing size of the project as the reuse of various aspects is supported. Table 1. Efficiency of compared approaches to system design SLOC \Approach Java model Java service Java annotation Java UI Java annotation UI XML
Common
Novel
201 203 13 490 48 912
217 147 36 414 116 574
Layer persistent business business presentation presentation presentation
As our implementations are in alpha versions, there is still some kind of information restatement. But, instead of knowledge restatement it is duplication of knowledge addresses e.g. due to weak support of addressing of external context. Nevertheless, there is no knowledge restatement. Each piece of information such as layout, condition and security is captured only once in the source code and referenced from multiple places. That significantly reduces maintenance efforts, because every change of any aspect requires only a single place modification.
6
Conclusion
In this paper we introduced a novel aspect-oriented approach to deal with information system development, while avoiding information restatement, code duplication and problems related to cross-cutting concerns. The fundamental idea is to divide system concerns, describe them separately and let them compose together through an aspect weaver. Our focus in this approach considered application business logic domain and user interface data visualization, which both represent cross-cutting concerns. For both approaches we designed and implemented an aspect weaver and evaluated our approach in a case study. Our
12
K. Cemus, T. Cerny
approach reduces development and maintenance efforts, it supports component reuse and improves system readability, since each system concern gathers its knowledge at a single location. Furthermore, our approach reduces manual mistakes and inconsistencies among system layers, it enforces change propagation to all coupled components and eliminated tedious work related change propagation. In future work we aim to improve our framework and minimize remaining code duplication then conduct a study on a production level system. Next, we plan to evaluate performance and apply this approach to the domain of adaptive UIs. Besides that we plan to integrate our solution into web services and to persistence layer to prevent knowledge duplication in database queries.
7
Acknowledgments
This research was supported by the Grant Agency of the Czech Technical University in Prague, grant No. SGS12/147/OHK3/2T/13.
References 1. Cerny, T., Donahoo, M.J.: How to reduce costs of business logic maintenance. In: Computer Science and Automation Engineering (CSAE), 2011 IEEE International Conference on. Volume 1., IEEE (2011) 77–82 2. Cerny, T., Donahoo, M.J., Song, E.: Towards effective adaptive user interfaces design. In: Proceedings of the 2013 Research in Applied Computation Symposium (RACS 2013). (October 2013) 3. Cerny, T., Song, E.: Model-driven rich form generation. International Information Institute(Tokyo). Information 15(7) (2012) 2695–2714 4. Chinnici, R., Shannon, B.: JSR 316: JavaTM Platform, Enterprise Edition (Java EE) Specification, v6 (2009) 5. Fowler, M.: Patterns of enterprise application architecture. Addison-Wesley Longman Publishing Co., Inc. (2002) 6. Fowler, M.: Domain-specific languages. Pearson Education (2010) 7. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: Abstraction and reuse of object-oriented design. Springer (2001) 8. Hayes-Roth, F.: Rule-based systems. Communications of the ACM 28(9) (1985) 921–932 9. Kelly, S., Tolvanen, J.P.: Domain-specific modeling: enabling full code generation. Wiley. com (2008) 10. Kennard, R., Steele, R.: Application of software mining to automatic user interface generation (2008) 11. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. Springer (1997) 12. Kleppe, A.G., Warmer, J.B., Bast, W.: MDA explained, the model driven architecture: Practice and promise. Addison-Wesley Professional (2003) 13. Laddad, R.: Aspectj in action: enterprise AOP with spring applications. Manning Publications Co. (2009) 14. Stoerzer, M., Hanenberg, S.: A classification of pointcut language constructs. In: Workshop on Software-engineering Properties of Languages and Aspect Technologies (SPLAT) held in conjunction with AOSD. (2005)
