Title of Invention

A METHOD TO EXTEND AOP WITH MODELS

Abstract

A method to extend AOP with models by weaving aspects into specified points in a program known as Join Points, Extending the capabilities of the existing point-cut languages, which allow point-cuts to be defined only in terms of programming language constructs, to enable querying over the entire range of UML models, Equating class models extracted from the program to the corresponding UML class models, Establishing correspondence between program classes and UML classes through name equivalence and Creating an abstraction called building block to specify aspects.

Full Text

FORM-2 THE PATENTS ACT, 1970 (39 of 1970) COMPLETE SPECIFICATION (Section 10, rule 13) "A method to extend AOP with models." Tata Research Development and Design Center a division of Tata Consultancy Services Limited, with our Corporate office at 11th Floor, Air India Building, Nariman Point, Mumbai 400 021, an Indian Company registered under the provisions of the Companies Act, 1956. The following specification particularly describes the nature of the invention and the manner in which it is to be performed: - Dated this 28th June, 2005 F r Tata Consultancy Services Limited J^ &r A. Kumaresan (Vice President: Legal & Secretarial) The present invention relates to developing large complex business applications by providing a set of modeling notations for capturing views of interest which are then translated into an implementation. More particularly, the present invention relates to Aspect-oriented programming (hereinafter AOP) by providing an abstraction for specifying cross-cutting concerns in a modular manner and extending the capabilities of the existing point-cut languages to enable querying over the entire range of UML models. Still particularly, it relates to AOP, based on separation of concerns idea, to address scattering and entanglement due to cross-cutting concerns. Industrial practice has traditionally used a combination of non-formal notations and methods for developing large complex business applications resulting in expensive and error-prone process that necessitates large teams with broad-ranging expertise. Model driven development approach addresses this problem by providing a set of modeling notations for capturing views of interest which are then translated into an implementation. However, these benefits are not fully realized as large parts of application are still specified in general purpose programming languages having no support to address the issue of separation of concerns. Aspect-oriented programming languages address the problems of scattering and entanglement by providing an abstraction for specifying cross-cutting concerns in a modular manner. However, the point-cut languages of existing aspect-oriented programming languages allow specification of program points for aspect weaving in terms of the programming language constructs only. Many situations in practice need a richer weaving context, for example, only the class methods participating in a regulatory process need to be audited in a different manner. As the processes change more frequently than core business computations, one would not like to hardcode the process context in the point-cut specification as is the case with aspect-oriented programming at present. Modern business systems need to cater to rapidly evolving business requirements in an ever-shrinking window of opportunity. Modern business systems also need to keep pace with rapid advances in technology. For developing large and complex applications, industrial practice has traditionally used a combination of non-formal notations and methods. These notations are used to arrive at an implementation, using a general purpose programming language and technology platforms of interest, through the steps of a development process. However, there are a few drawbacks to such a development process based on general purpose programming language and technology platforms of interest: 1. The development process relies heavily on manual verification to ensure the implementation is consistent with the intent captured in these notations. 2. This is an expensive and error-prone process demanding large teams with broad-ranging expertise in business domain, architecture and technology platforms. 3. Also, lack of support for modularization of cross-cutting concerns in general purpose programming languages exacerbates the development and maintenance problems. Model-driven development approach advocates a more formal development process wherein a set of modeling notations are provided for specifying different layers of a system which are then transformed into platform-specific implementations by a set of code generators. This approach delivers improved productivity, better quality and platform independence especially in developing large enterprise applications. However, such a Model-driven development process has a few drawbacks: 1. Small and medium sized development projects find this approach too heavy and the associated development process too constrictive. 2. Also, developers find models too cumbersome to specify the systems completely. 3. As a result, a large part of the system implementation is still specified using general purpose programming languages. Thus, though a Model-driven development seems a more natural fit for separation of concerns as different modelling notations can be used to specify different aspects, the benefits due to separation of concerns cannot be completely realized since a large part of the system is specified outside the models in general purpose programming languages. Summary of the Invention Aspect oriented programming is a promising approach, based on separation of concerns idea, to address scattering and entanglement due to cross-cutting concerns. Aspect-oriented programming languages enrich general purpose programming languages by providing the abstraction of aspect for modularizing cross-cutting concerns. Aspects are then woven into specified points in a program known as join points. These join points are specified in terms of the constructs of the programming language. This composition technique is adequate to support a large number of cross-cutting concerns such as logging, trace etc. However, join points at programming language construct level are not always adequate to capture the context within which an aspect may need to be woven. For example, one may want to audit only the class operations taking part in a certain business process. At present, this can only be achieved by explicit enumeration of the appropriate methods in point-cut specification. Any change in the business process will require a corresponding manual change in the weaving specification. Recent approaches that marry metadata with aspect-oriented programming provide an enhanced application context for aspect weaving but do not yet fully exploit models [6]. This invention provides an approach to extend aspect oriented programming with models to address this problem. We also describe an implementation of the proposed approach. Therefore, we propose a hybrid approach that extends the power of aspects as supported in the present aspect-oriented programming languages. Essentially, we extend the capabilities of the existing point-cut languages to enable querying over the entire range of UML models. This provides a richer context for aspect weaving. Existing point-cut languages are defined over a restricted subset of UML [7] class models (e.g. no associations). In this invention the point-cuts can be specified over class models and other kinds of models such as use-case models, process models, and activity models etc. that are related through the class model elements. In our approach, we start with the class models taken from the program, equate them to the corresponding UML class models, and from there navigate to other related UML models. The correspondence between program classes and UML classes is established through name equivalence. The proposed approach can be implemented by extending standard aspect-oriented languages whose weavers can consume UML models in, say, XMI [10] format as shown in figure 1. However, in our implementation, we use our own language for aspect specification and a custom weaver to weave the aspects into a standard Java program. We chose this approach in order to get the woven code in Java rather than byte code. Aspect-orientation advocates specification of a system as a (de)composition of concerns along several dimensions of interest leading to clear traceability across different levels of system specification namely requirements, design and code. Model driven development advocates decomposition of a system into multiple models each capturing a viewpoint of a stakeholder. A viewpoint can be seen as a dimension of concern as advocated in aspect-orientation. Organization of system specifications as a set of concerns / viewpoints enables concurrent development, ease of change management and evolution through additive changes. Specification of a typical business system caters to functional and several non-functional requirements like concurrency management, performance, security etc. In traditional AOP parlance, functional requirements can be viewed as components and non-functional requirements as aspects. In aspect oriented model driven development approach, the component and the aspects are specified as independent models, typically, in their own modeling languages specified as meta models. Figure 1 shows the models for component and two aspects as instances of the related meta models CM, AMI and AM2 respectively. The weaving of an aspect into the component can be seen as transformation of the component model as shown in figure 1. The transformation is specified at meta model level. The model transformer takes the component model and the aspect model as input to produce a transformed component model. The transformation is specified using a standard language such as QVT [5]. In practice, however, large business systems are never completely specified as models alone. Typically, models are used only in analysis and high-level design phases to capture user interactions, process flows and information structure. Subsequent phases then detail out an implementation in a general purpose programming language using skeletal code generated from these models as a starting point. Since a large part of the system is implemented using a general purpose programming language, it is necessary to support separation of concerns at code level also. Aspect oriented programming Aspect oriented programming provides an abstraction called aspect to specify a cross-cutting concern in a modular manner. An aspect specifies a code fragment known as advice to be woven at identified program points {join-points) specified as a point-cut. A point-cut is a means to select a subset of the join-points of a given program for an aspect. For example, the following aspect, in Aspect! [1], specifies a Java code fragment for auditing and the program points where it needs to be woven. The intent of Process Audit aspect is to log a process trace for audit purposes. A process trace is logged in terms of the input and output parameters of the operations participating in the process. As seen in the example above, the participating operations are explicitly enumerated as point-cut specification. Typically, processes are liable to frequent changes. Every such change in the process requires a corresponding manual change in the point-cut specification of the aspect. In a model driven development approach, processes would be already available in the model form from which it should be possible to automatically derive the required point-cut information. However, since current aspect oriented programming languages allow point-cuts to be specified only in terms of the syntactic constructs of the underlying programming language, the process model information cannot be accessed by the point-cuts. Extending AOP with models Point-cut specifications in standard AOP languages such as AspectJ are essentially expressions over class models supported by the underlying programming language such as Java. These class models are typically a subset of an application's UML class model. Therefore it is possible to relate classes specified, say, in a Java program to the classes specified in a UML model using name equivalence. It is then possible to navigate to other UML models from UML class model. To provide a richer context for aspect weaving, we extend point-cut specification languages of standard AOP languages with query expressions over UML models. Query expressions are specified in OCL syntax. These queries can select context-specific join points using the information available in other related UML models. Figure 2 gives a pictorial view of this approach. Execution of the point-cut query selects only method 1 as the join point for weaving as it participates in a regulatory process. Our implementation We have used this approach in our model based code generation framework for developing business applications. The framework allows the developer to specify business logic in Java, to specify non-functional characteristics of the application as aspects, and weaves the code fragments corresponding to the aspects at specified program points in the business logic. Weaving of some of these aspects requires context not available in the business logic but captured in other UML models like use-case models, process models etc. We use our own weaver as the requirement was to have the woven code in a human readable Java syntax and not in byte code. We have an abstraction called building block to specify aspects. A building block has two parts - a weaving specification and an unparsing specification. The weaving specification is equivalent to the extended point-cut specification described earlier. The unparsing part is specified using a template language and is equivalent to the advice in AOP. Our template language is more expressive than AOP advice as it is capable of navigating the UML models. Our weaver takes as input a Java program, aspect specifications in terms of building blocks and UML models in XMI format, and produces the woven Java program as output. An operational overview of our implementation is shown in figure 4. The present invention has been illustrated with the help of drawings: There are total of 4 figures. Fig.l : Aspect weaving as model transformation Fig 2: Extending AOP with models. Fig 3: A sample process model. Fig 4: Operational view of our implementation. Advantages of the invention Completely model-centric development approaches do not yet scale up to the needs of the industry due to lack of mature tool support. Aspect oriented programming on the other hand cannot exploit the rich content available in the models. More recent approaches marrying metadata attributes with aspect-oriented programming provide for specification of enhanced application context for aspect weaving but do not yet exploit the models fully. Our approach extends aspect oriented programming with models to provide a richer context for weaving of cross-cutting concerns. Since point-cut specifications can query models directly, there is no need to replicate the model information in point-cut specification thus ensuring consistency between aspects and models. The approach combines the benefits of modelling such as ability to use different kinds of models to capture different aspects, with the flexibility of code centric development offered by aspect-oriented programming. Hence, it can cater to a wide class of application development scenarios spanning from predominantly model-centric to predominantly code-centric. We Claim: 1. A method to extend AOP with models comprising the steps of: Weaving aspects into specified points in a program known as Join Points, Extending the capabilities of the existing point-cut languages, which allow point-cuts to be defined only in terms of programming language constructs, to enable querying over the entire range of UML models, Equating class models extracted from the program to the corresponding UML class models, Establishing correspondence between program classes and UML classes through name equivalence and Creating an abstraction called building block to specify aspects. 2. The system recited in claim 1, wherein the point cuts can be specified over class models and other kinds of models such as use-case models, process models, activity models. 3. The system recited in claim 1, wherein the point cut specification language of standard AOP languages is extended with query expressions over UML models. 4. The system recited in claim 3, wherein the Query expressions are specified in OCL syntax, which can select context-specific join points using the information available in other related UML models. 5. The system recited in claim 1, wherein the said method comprises of a model based code generation framework for developing business applications. 6. The system recited in claim 5, wherein the said framework allows the developer to specify business logic in Java, to specify non-functional characteristics of the application as aspects, and weaves the code fragments corresponding to the aspects at specified program points in the business logic. 7. The system recited in claim 6, wherein the said weaving of some of these aspects requires context captured in other UML models like use-case models or process models. 8. The system recited in claim 1, wherein the said abstraction comprises of a weaving specification and an unparsing specification. 9. The system recited in claim 8, wherein the said weaving is equivalent to the extended point-cut specification described earlier. 10. The system recited in claim 9, wherein the said unparsing part is specified using a template language and is equivalent to the advice in AOP. Dated this 28th June, 2005 A. Kumaresan (Vice President: Legal & Secretarial) For Tate Consultancy Service Limited ABSTRACT A method to extend AOP with models by weaving aspects into specified points in a program known as Join Points, Extending the capabilities of the existing point-cut languages, which allow point-cuts to be defined only in terms of programming language constructs, to enable querying over the entire range of UML models, Equating class models extracted from the program to the corresponding UML class models, Establishing correspondence between program classes and UML classes through name equivalence and Creating an abstraction called building block to specify aspects.

Documents:

851-mum-2005-abstract(14-9-2007).pdf

851-mum-2005-abstract-(14-9-2007).doc

851-mum-2005-abstract.doc

851-mum-2005-cancelled pages(14-7-2005).pdf

851-mum-2005-claims(granted)-(14-9-2007).pdf

851-mum-2005-correspondance-received.pdf

851-mum-2005-correspondence(14-9-2007).pdf

851-mum-2005-correspondence(ipo)-(3-1-2007).pdf

851-mum-2005-drawing(14-9-2007).pdf

851-mum-2005-form 1(14-7-2005).pdf

851-mum-2005-form 18(8-6-2006).pdf

851-mum-2005-form 2(granted)-(14-9-2007).doc

851-mum-2005-form 2(granted)-(14-9-2007).pdf

851-mum-2005-form 26(14-7-2005).pdf

851-mum-2005-form 3(28-6-2005).pdf

851-mum-2005-form 9(8-6-2006).pdf

851-mum-2005-form-1.pdf

851-mum-2005-form-18.pdf

851-mum-2005-form-2.doc

851-mum-2005-form-2.pdf

851-mum-2005-form-26.pdf

851-mum-2005-form-3.pdf

851-mum-2005-form-9.pdf

851-mum-2005-form-abstract-1.jpg

851-mum-2005-form-abstract.pdf

851-mum-2005-form-claims.pdf

851-mum-2005-form-description (complete).pdf

851-mum-2005-form-drawings.pdf

851-mum-2005-granted.pdf

851-mum-2005-we claims(granted)-(14-9-2007).doc