FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention.
A SYSTEM AND METHOD FOR DEVELOPING CONFIGURABLE, EXTENSIBLE BUSINESS
APPLICATION PRODUCT LINES USING MODEL-DRIVEN TECHNIQUES
Applicant
TATA Consultancy Services Limited A company Incorporated in India under The Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION
The present invention relates to developing business application product lines and in more particularly relates to a system and method for developing configurable, extensible business application product lines using model-driven techniques.
PRIOR-ART REFERENCES
I) A Aho, R Sethi and J Ullman. Compilers: Principles, Techniques and Tools. Addison Wesley
Publishing Company 1986.
2} Alexander Nyben, Shmuel Tyszberowicz, Thomas Weiler. Are Aspects useful for Managing Variability in Software Product Lines? A Case Study. Early aspects workshop at SPLC 2005.
3) Alexandre Bergel, St'ephane Ducasse, and Oscar Nierstrasz. Classbox/J: Controlling the scope of change in Java. In Proceedings of Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'05), pages 177-189, New York, NY, USA, 2005. ACM Press.
4) A Goldberg, D Robson. Smalltalk-80: the language and its implementation. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, 1983.
5) Don Batory. Feature Models, Grammars, and Propositional Formulas. Software Productlines, Volume 3714 of LNCS, pages 7-20, Springer, 2005.
6) Feiix Bachmann, Michael Goedicke, Julio Leite, Robert Nord, Klaus Pohl, Balasubramaniam Ramesh and Alexander Vilbig. A Meta-model for Representing Variability in Product Family Development. Software Product Family Engineering, volume 3014 of LNCS, pages 66-80, Springer, 2004.
7) Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Longtier and John Irwin. Aspect oriented programming. ECOOP'97 LNCS 1241, pp 220-242. Springer-Verlag. June 1997.
8) Hasan Gomaa, Diana L Webber. Modeling Adaptive and Evolvable Software Product Lines Using the Variation Point Model. Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04) - Track 9 - Volume 9.Page: 90268.3
9) K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. Generative Programming and Component Engineering, Volume 3676 of LNCS, pages 422-437. Springer, 2005.
10) M ClauU, I Jena. Modeling variability with UML. GCSE 2001 Young Researchers Workshop,
2001.
II) Nathaniel Nystrom, Xin Qi, and Andrew C. Myers , J&. Software Composition with Nested
Intersection, OOPSLA2006, pp. 21-36

12) Oscar Nierstrasz, Marcus Denker, Tudor GTrba and Adrian Lienhard, "Analyzing, Capturing and Taming Software Change," Proceedings of the Workshop on Revival of Dynamic Languages (co-located with ECOOP'06), July 2006.
13) OSGi - The Dynamic Module System for Java, http://www.osai.org/
14) Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten, Betty H.C. Cheng, "Composing Adaptive Software," Computer, vol. 37, no. 7, pp. 56-64, July 2004
15) Robert Bruce Findler , Matthew Flatt, Modular object-oriented programming with units and mixins, Proceedings of the third ACM SIGPLAN international conference on Functional programming, p.94-104, September 26-29, 1998, Baltimore, Maryland, United States
16) T. Coupaye, J.-B. Stefani. Fractal Component-Based Software Engineering - Report on the Fractal workshop at ECOOP'06, 20th European Conference on Object-Oriented Programming (ECOOP 2006) Workshop Reader, LNCS 4379, 2007.
17) Vinay Kulkarni, R. Venkatesh and Sreedhar Reddy. Generating enterprise applications from models. OOIS'02, LNCS 2426, pp 270-279. 2002.
18) Vinay Kulkarni, Sreedhar Reddy, An abstraction for reusable MDD components: model-based generation of model-based code generators. GPCE 2008: 181-184
19) Vinay Kulkarni and Sreedhar Reddy, Separation of Concerns in Model-Driven Development. IEEE Software 20(5): 64-69 (2003)
BACKGROUND OF THE INVENTION
Business enterprises use IT systems as a mechanical advantage through automation of apriori well-defined repetitive operational tasks. With past dynamics of business being low, business applications were developed primarily to deliver certainty in a fixed operating environment. Advent of internet leading to increased connectivity within and amongst enterprises, and rapid evolution of technology platforms have contributed to significant increase in business dynamics in recent years. The increased dynamics puts new demands on businesses while opening up new opportunities that need to be addressed in an ever-shrinking time window. Stability and robustness seem to be giving way to agility and adaptiveness. This calls for a whole new perspective for designing (and implementing) IT systems so as to impart these critical properties.
Traditional business applications typically end up hard-coding the operating context in their implementation. As a result, adaptation to a change in its operating environment leads to opening up of application implementation. This adaptation process results in unacceptable responsiveness. It should be possible to configure a business application for the desired operating environment. New opportunities may put unconceived demands on business applications. It should be possible to quickly extend the existing implementation without breaking

parts unrelated to the desired extension. It should be possible to support such adaptations at different levels of latency i.e. application design-time, application installation-time and application run-time. Moreover, large enterprises may want to impose some discipline in introducing such adaptations through, say, roles-n-responsibility structure.
Database intensive enterprise applications are realized conforming to distributed architecture paradigm that requires diverse set of technology platforms to implement. Such applications can be seen to vary along five dimensions, namely, Functionality (F), Business process (P), Design decisions (D), Architecture (A) and Technology platform (T).
A purpose-specific implementation makes a set of choices along the above mentioned dimensions, and encodes these choices, typically, in a scattered and tangled manner as mentioned in reference number 7 of the prior-art references. This scattering and tangling is the principal obstacle in agiie adaptation of existing implementation for the desired change. Large size of enterprise application further exacerbates this problem. This is an expensive and error prone process demanding large teams with broad-ranging expertise in business domain, architecture and technology platforms. Model-driven development alleviates the problem somewhat by automatically deriving an implementation from its high-level specification as mentioned in reference number 17 of the prior-art references. Generation of model-based code generators from their high-level specifications further refines the solution as mentioned in reference number 18 of the prior-art references.
For identical business intent, different enterprises, even from the same business domain, may have different requirements along the above five dimensions - one can expect a significant overlap in their requirements and hence in specifications. Being ignorant of the similarities in such specifications would mean rework, and result in specification redundancy which will create maintenance and evolution problems later. Thus, it is important to capture commonality while highlighting the variability i.e. productive architecture as mentioned in reference number 9 of the prior-art references.
Specification-based development imparts adaptiveness, to a certain extent, especially with respect to technology platforms. The same business functionality can be delivered into a different set of choices of design decisions, architecture and technology platform through code generation - this is akin to retargetable code generation in compilers as mentioned in reference number 1 of the prior-art references.

However, imparting adaptation through code generation addresses the issue only in part as the 'adapted system' still needs to be compiled and deployed for execution. Thus, in specification-based development approaches, adaptiveness needs to be supported at various levels, namely, specification, code generation, code and depfoyment Model-driven development aided by a code-generator product line imparts adaptiveness and variability with respect to D, A and T dimensions as mentioned in reference number 19 of the prior-art references.
However, change requests along D, A and T dimensions are relatively infrequent as compared to those along F and P dimensions. Ongoing dynamic middleware related work by OSGi community as mentioned in reference numbers 13 and 14 of the prior-art references which are aimed at addressing adaptiveness at deployment level.
The (de)composition mechanisms such as aspects as mentioned in reference number 7 of the prior-art references, mixins as mentioned in reference number 15 of the prior-art references, fractals as mentioned in reference number 16 of the prior-art references etc; variability management mechanisms such as feature models, and change specification languages such as ChangeBox as mentioned in reference number 12 of the prior-art references, ClassBox as mentioned in reference number 3 of the prior-art references, Jx/J& as mentioned in reference number 11 of the prior-art references are aimed at addressing adaptiveness at code level.
Some of the inventions which deal in developing the business application product lines are:
US7152228 discloses a method for generating source code objects has steps of generating a translation file containing translation logic; inputting the translation file into a code generator; and generating translation source code as a function of the translation file. A system for accessing a database through a translation layer comprising a first database; a translation layer, defined by translation source code; and an application for accessing the first database through the translation layer. But it fails to disclose the developing the business application for two or more different enterprises from the same business domain from the common business application.
US20080133303 discloses a business object model, which reflects data that is used during a given business transaction, is utilized to generate interfaces. This business object model facilitates commercial transactions by providing consistent interfaces that are suitable for use across industries, across businesses, and across different departments within a business during a business transaction. But it fails to disclose the developing the business application for two or more different enterprises from the same business domain from the common business application.

Thus, the hitherto available methods and systems have not been able to satisfactorily address the said problems of art. The present invention, as outlined in this patent disclosure, is neither covered nor anticipated by teachings of prior art.
In order to solve the above mentioned problems in the art, this invention proposes a system and method for developing configurable, extensible business application product lines using model-driven techniques.
Other features and advantages of the present invention will be explained in the following description of the invention having reference to the appended drawings.
OBJECTIVES OF THE INVENTION
The principle object of the present invention is to provide a system and method for developing configurable, extensible business application product lines using model-driven techniques.
Another object of the invention is to provide a model-based solution to address extensibility and configurability of both structural and behavioral aspects in a functionality dimension of database intensive business application.
In another object of the invention is to provide a component abstraction and an algebra that aids in imparting structural and behavioral properties of database intensive business application, and the component abstraction and the algebra are used to support the various adaptation operators in database intensive business application.
In a further object of the invention is to support configuration process at three different stages of application development (i.e. design time, installation time and run time) of database intensive business application.
A still another object of the invention is to detect the errors in application development cycle of database intensive business application by using the modeling.
SUMMARY OF THE INVENTION
Before the present methods, systems, and hardware enablement are described, it is to be understood that this invention in not limited to the particular methodologies, and systems

described, as these may vary. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present invention which will be limited only by the appended claims.
The present invention provides a system and method for developing configurable, extensible business application product lines using model-driven techniques.
A system comprising at least one computer workstation having graphical user interface associated with the system for enabling user interaction and manipulation of system entities;
a server connected to workstation by the communication network for storing textual specifications necessary for describing application functionality;
at least one other server connected to workstation by the communication network having data repository for storing data particulars necessary for application development, wherein the system develops configurable, extensible business application product line using model driven technique, comprising the computer implemented steps of:
(a) Defining business application specification which is to be transformed into a concrete implementation on an application architecture, wherein the application architecture is layered, with each layer representing one view of the system, comprising Graphical User Interface (GUI) layer, application logic layer and database(Db) layer;
(b) Decomposing business application specification into three models comprising GUI layer model, Application layer model and Db layer model:
(c) Modeling the specification of business application for one or more abstract views, wherein each distinct abstract view defines a set of properties corresponding to the layer and its corresponding model;
(d) Creating three meta models, for each distinct abstract view, wherein the said meta models comprises GUI layer meta model, Application layer meta model and Db layer meta model;
(e) Integrating each model to form single Unified meta model, wherein the single unified meta model allows to specify integrity constraints to be satisfied by the instances of related model elements within and across different layers, which enables independent transformation of GUI layer model, Application layer model and DB layer model into their corresponding implementations GUI layer code, Application layer code and Db layer code into a consistent whole and
(f) Implementing each individual transformation of the corresponding specification and relationships with other specifications correctly, resulting in implementations that go

together resulting in a consistent implementation of the specification in the application architecture.
The invention enables a model-based solution to address extensibility and configurability of both structural and behavioral aspects in a functionality dimension of database intensive business application. And it also provides a component abstraction and an algebra that aids in imparting structural and behavioral properties of database intensive business application, and the component abstraction and the algebra are used to support the various adaptation operators in database intensive business application. The invention supports configuration process at three different stages of application development (i.e. design time, installation time and run time) of database intensive business application
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings example constructions of the invention; however, the invention is not limited to the specific methods and system disclosed. In the
drawings:
Figure 1 shows flow Chart for Application Development Process according to various embodiments of the invention.
Figure 2 illustrates model based development approach according to various embodiments of the invention.
Figure 3 illustrates meta models specific to each architectural layer as views of the unified meta model with the associations spanning across the architectural layer models highlighted according to various embodiments of the invention.
Figure 4 shows a meta model to address configurability and extensibility properties for user interface layer according to one embodiment of the invention.
Figure 5 depicts meta model for addressing configurability and extensibility properties for structural and behavioral aspects of class according to one embodiment of the invention.

Figure 6 shows a meta model to address configurability and extensibility properties for database layer according to one embodiment of the invention.
Figure 7 shows relevant subset of a meta model to capture traceability of a feature to its implementation artefacts according to one embodiment of the invention.
Figure 8 shows the core meta model for the component abstraction according to one embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
Some embodiments of this invention, illustrating all its features, will now be discussed in detail.
The words "comprising," "having," "containing," and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.
It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any methods, and systems similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, the preferred methods, and systems are now described.
The disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms.
Definitions:
Adaptiveness: When business application adapts to the application operating environment, wherein the adaptiveness subsumes configurability (i.e. selecting one of the many available variants) and extensibility (i.e. adding a new variant).
Variant: The different possibilities that exist to satisfy a variation point are called variants.
Variation Point: The variation point describes where differences exist in the final systems.

Variability dependencies: This is used as a basis to denote the different choices that are possible to fill a variation point. The dependency specification includes Cardinality options like 1-of-nt m-of-n etc. and constraints like mandatory variants, mutually exclusively variants etc.
Configurability and Extensibility: Configurability means quick switching from one known situation to another and Extensibility mean easy handling of as yet unseen situation.
The present invention provides a system and method for developing configurable, extensible business application product lines using model-driven techniques. By way of explanation and example, the present invention will be described in detail below using following system:
A system comprising at least one computer workstation having graphical user interface associated with the system for enabling user interaction and manipulation of system entities; a server connected to workstation by the communication network for storing textual specifications necessary for describing application functionality; at least one other server connected to workstation by the communication network having data repository for storing data particulars necessary for application development, wherein the system develops configurable, extensible business application product line using model driven technique.
The above said system further comprising at least one deployment framework for testing developed application wherein the deployment framework comprises: At least one computer workstation having graphic user interface for enabling a user interaction with system; At least one server with Application Server installed on the system for residing developed application and metadata; At least one server with Web Server installed on the system to route user requests to application server and One data repository to store application data.
Figure 1 shows flow Chart for Application Development Process (100) according to various embodiments of the invention. Initially, the system captures the requirements of the client from the servers and it analyzes the client's requirements. Based on analyzes, the system follows the below mentioned three ways to develop a new business application comprises New development, Extension, or Configuration, ff the system selects the new development of business application, then it does the functionality design, subsequently, it define the variation points then it does the functionality development, testing and finally deployment of the application. If the system selects extension, then it finds out whether pure extension or extension for variant. If it is pure extension then it leads to functionality designs, subsequently, it define the variation points then it does the functionality development, testing and finally deployment of the application. If it is extension for variant, then the system does the variant design, variant development, testing and finally

deployment of the application. If the system selects configuration, then it does configuration, testing and finally deployment of the application. Once the deployment of the application is done by the system, then it does the configuration of the deployment of the application in the end user's/client's system. Finally, the client can use the developed application in their system.
Figure 2 illustrates model based development approach (200) according to various embodiments of the invention. Model-driven develop a concrete implementation on application architecture as mentioned in reference number 17ment approach starts with definition of an abstract specification that is to be transformed into of the prior-art references. The application architecture is usually layered with each layer representing one view of the system e.g. Graphical User Interface (GUI) layer, application logic layer and database layer. The modeling approach constructs the application specification using one or more abstract views, wherein each distinct abstract view defines a set of properties corresponding to the layer it models. The system decomposes an application specification into three such models- GUI layer model, Application layer model and Db layer model as shown in Figure 2. The system creates three meta models, namely GUI layer meta model, Application layer meta mode! and Db layer meta model, for the each distinct abstract views of specifications. Each models integrate to form a single Unified meta model as depicted in Figure 2. Having a single meta model allows for specification of integrity constraints that need to be satisfied by the instances of related model elements within and across different layers. This enables independent transformation of GUI layer model, Application layer model and DB layer model into their corresponding implementations namely GUI layer code, Application layer code and Db layer code with assurance of integration of these code fragments into a consistent whole. These transformations can be performed either manually or using code generators. The transformations are specified at meta model level and hence are applicable for all model instances. If each individual transformation implements the corresponding specification and its relationships with other specifications correctly then the resulting implementations will go together giving a consistent implementation of the specification as depicted in Figure 2. Models can be kept independent of implementation technology, and the application specifications can be targeted to multiple technology platforms through code generation. Construction of application specification in terms of independent models helps divide and conquer, wherein the divide and conquer strategy is explained in the Figure 8. Modeling helps in early detection of errors in application development cycle. Associated with every model are a set of rules and constraints that define validity of its instances. These rules and constraints could include rules for type checking and for consistency between specifications of different layers. Automated code generation results in higher productivity and uniformly high code quality

Figure 3 illustrates meta models specific to each architectural layer as views of the unified meta model with the associations spanning across the architectural layer models (300) according to various embodiments of the invention. Business application is being implemented across three architecture layers - user interface, application functionality and database. A user interacts with an application through its user interface. The user feeds in information using forms and browses over available information using queries and reports. Forms, queries and reports are implemented in the application platform using standard graphical user interface primitives such as windows, controls and buttons. A window is a unit of interaction between the user and the system, and is composed of controls and buttons. A control accepts or presents data in a specific format. The user can perform a specific task by clicking on a button. Application layer implements the business functionality in terms of business logic, business rules and business process. The functionality is modeled using classes, attributes, methods and associations between classes. Business logic specifies the computations to be performed by the application in terms of methods. A higher level language for specifying business logic can free the application developer from low-level implementation concerns such as memory management, pointers, resource management etc and is retargettable to popular programming languages of choice. The database layer provides persistence for application objects using RDBMS tables, primary key and query based access to these tables, and an object oriented view of these accesses to the application layer.
According to various embodiments of the invention, the system addresses extensibility and configurability of both structural and behavioral aspects of database intensive business application. Meta models capture changes permissible to GUI model, application model and database model etc, and adaptation techniques effect the desired change into application implementation in a consistent manner.
Figure 4 shows a meta model to address configurability and extensibility properties for user interface layer (400) according to one embodiment of the invention. A GUI screen is one of the channels for users to interact with an application. In essence, a GUI screen enables user to provide input data for carrying out a logical unit of work. To serve the same business intent, a GUI screen can vary in terms of what (i.e. data user needs to enter and / or can view) and how (i.e. layout information and GUI controls used for display) leading to multiple situations. Configurability means quick switching from one known situation to another, and extensibility means easy handling of as yet unseen situation. This meta model is an extension of user interface meta model highlighted in Figure 3 as follows:
Classification of fields into fixed and free. The former needs to be displayed in all situations whereas the latter are specific to a situation.

Classification of buttons into fixed and free. The former needs to be displayed in all situations whereas the latter are specific to a situation.
- A field can be displayed using a different GUI control in different situations and can also conform to a different type.
- An event can be handled in different ways in different situations.
- A screen exists in multiple variants each an internally consistent composition of fields, buttons and event handlers.
- A situation helps select the desired variant of a screen from multiple alternatives.
Thus, the above meta model enables modeling of a family of screens wherein each member (of the screen family) serves the same intent in a specific situation. By making the above information available at application runtime, as metadata, a GUI implementation can switch from one known situation to another at application run-time. Addition of a new row in the metadata tables corresponds to ability of handling as yet unknown situation. Not all situational adaptations can be handled at application-runtime though, for instance, change in event handler code would need recompilation followed by redeployment. Similarly, definition of a new screen altogether, as an extension to existing functionality, cannot be handled at application run-time. But, the meta model enables a new situation to be addressed such that it adds to the existing set of configuration alternative.
Figure 5 depicts meta model for addressing configurability and extensibility properties for structural and behavioral aspects of class (500) according to one embodiment of the invention. Application layer specifies the business logic in terms of Class, Attribute and Operations. Being an encapsulation of both structural and behavioral aspects, Class is the natural choice for imparting configurability and extensibility at the finest level of abstraction. This meta model is an extension of the application layer meta model highlighted in Figure 3 as follows:
Classification of Attributes into fixed, free and delmod. A Class contains fixed attributes in ail situations whereas free attributes are specific to a situation. Attributes tagged delmod represent situation specific deletions and/or modifications. An Attribute can conform to different types.
Classification of Operations into Configurable and Concrete. The former have situation-specific behavior whereas the latter have constant behavior in all situations. Body of a Configurable operation is a Template with well-defined extension points (TxtnPoint) where different behaviors can be plugged in. An extension point is specified in the form of an interface invocation - a factory returns the appropriate object (Txtn) that implements the extension.

Extending existing behavior amounts to providing a new extension (Ov) for existing
extension points or defining a new template (Ox) for the operation being extended or
both.
Cv depicts situation-specific class definition.
- A situation helps select the desired variant of a class from multiple alternatives.
Thus, the above meta model enables modeling of a family of classes wherein each member (of the class family) serves the same intent in a specific situation. By making the above information available at application runtime, as metadata, application implementation can switch from one known situation to another at application run-time. Addition of a new row in the metadata tables corresponds to ability of handling as yet unknown situation. Not all situational adaptations can be handled at application-runtime though, for instance, addition of a new behavior extension (Ox or Ov) would need recompilation followed by redeployment. Similarly, definition of a new class altogether, as an extension to existing functionality, cannot be handled at application run-time. But, the meta model enables a new situation to be addressed such that it adds to the existing set of configuration alternative.
Figure 6 shows a meta model to address configurability and extensibility properties for database layer (600) according to one embodiment of the invention. Database layer provides persistency to the desired application objects. The system considers an object-relational database layer that provides an object facade to relational database tables for implementing persistence. As an application object can vary structurally from situation to situation, the database table onto which it maps also needs to cater to this variance. And the same holds for structural extension as well. This meta model is an extension of database layer meta model highlighted in Figure 3 as follows:
Classification of Columns into fixed and free. The former are associated with an Entity in all situations whereas the latter are specific to a situation. A Column can also conform to different types. Tv depicts situation-specific entity definition.
- A situation helps select the desired variant of an Entity from multiple alternatives.
Thus, the above meta model enables modeling of a family of entities wherein each member (of the entity family) serves the same intent in a specific situation. In essence, the above information makes the generic schema specific to a given situation. Database access methods such as primary key based Create, Update, Get and Delete, and complex data accesses like joins can encode interpretation of this information in their implementation. By making the above information available at application runtime, as metadata, application implementation can switch from one

known situation to another at application run-time. Addition of a new row in the metadata tables corresponds to the ability of handling as yet unknown situation. Not all situational adaptations can be handled at application runtime though, for instance, deletion of a column would need redefinition of the schema leading to recompilation of database access layer code followed by redeployment. But, the meta model enables a new situation to be addressed such that it adds to the existing set of configuration alternative.
Figure 7 shows relevant subset of a meta model to capture traceability of a feature to its implementation artefacts (700) according to one embodiment of the invention. Meta models described so far, in essence, help model a family at each architectural layer such that all members of a family share a common part and are distinguishable in terms of member-specific part. As described in Figure 2, the unified meta model enables specification of well-formedness constraints spanning across the architectural layers. Once a set of desired members, one from each architectural layer, is identified, it is possible to compose them into a well-formed specification that can be automatically transformed into a consistent and complete solution. The system uses feature modeling technique to enable selection of a family member pertaining to the desired criterion.
Figure 8 shows the core meta model for the component abstraction (800) according to one embodiment of the invention. In a divide and conquer strategy, application is modeled as a set of modular units which can be developed in parallel. The system considers such development unit as a component. Components share producer-consumer relationship amongst them. A component encapsulates data and computation, and exposes a set of services through its interfaces. Inter-relationship between components is a typical cause for tangled specifications that hamper independent development. The system addresses tangling through separate specification of provided and required interfaces which serve as a contract between component and its environment. A component will deliver provided interface as long as its required interface is met by the environment. These are well accepted notions for application run-time, the component abstraction is aimed to support them at application build-time. The system uses component abstraction to encapsulate business and database layers. A component specification comprises of interface specification as well as specification of its internal implementation. Essentially, internal implementation is specified in terms of classes, class associations, entities and specification of method-bodies of the classes. The component interface specification can be seen as a projection of its implementation specifications. Component, being a composition unit for applications, need to support the notions of configurability and extensibility. As shown in Figure 8, the system extends the component abstraction through extension point (xtnPoints) and variation point (varPoints). Extension points are of two types: Data Extension Point (DxtnPoint) and Behavioral extension point (PRxtnPoint). Variation points are of three types: variation related to

Entity (EvarPoint), variation related to Operation (OvarPoint) and variation related to Class (CvarPoint). Entity and Class extensions (Ex and Cx respectively) fit into DxtnPoint, and Operation and Class extensions (Ox and Cx respectively) can be plugged in at PRxtnPoint. Similarly, Entity and Class variations (Ev and Cv respectively) and Operation variations (Ov) can be plugged in at EvarPoint, CvarPoint and OvarPoint respectively.
The system formally defines a component (Comp) as a tuple < Own, P, R, EO, ER, X, V> Where, Own: Component implementation specification, typically, as instance of a meta model P: Set Operations that a component provides. R: Set of Operations the component requires (so as to honour P). EO: Set of entities that component owns
ER: Set of entities that component refers - owned by other components. X: Set of extensions for the component V: Set of variants of the component
Operations are further defined as a tuple where operName: Name of the operation In and Out are a set of typed parameters - type defined by a Class.
Extension (X) is formally defined as tuple < Cx, Ex, Ox>, where,
Cx identifies a set of extended classes as per a meta model pattern Cxp as mentioned in Figure 5
Ex identifies a set of extended entities as per a meta model pattern Exp as mentioned in Figure 6
- Ox identifies a set of extended operation as per a meta model pattern Oxp as mentioned
in Figure 5
Component variant (V) is defined as a tuple < Cv, Ev, Ov> where,
Cv identifies a set of configurable Class variants as per a meta model pattern Cvp as mentioned in Figure 5
Ev identifies a set of configurable Entity variants as per a meta model pattern Evp as mentioned in Figure 6
- Ov identifies a set of configurable Operation body variants as per a meta model pattern
Ovp as mentioned in Figure 5
A component is well-formed if,
- P.Operation are realized as Class.Operation in Own, i.e.
V o Є Comp.P satisfies below condition

o e { Comp.provided.interfacefOperation]}) ^ {3 Class c e Comp.Own | c.operation == o)
R.Operation are expected to be implemented by Class.Operation of other component, i.e. Voe Comp.R, satisfies below condition
o € { Comp.required.interface[Operation]}) ^ (3 Class c | c.operation == o and c g Comp.Own)
The desired changes of an application layer for a situation can be specified by instantiating class, entity, and operation meta models. Once the change is specified the next challenge is how to effect the changes in an application in a consistent manner. The system characterizes a change as adding new situation and/or switching situation from one to another. The new situation can be realized by extending an application, composing or integration different application components into a consistent whole, whereas switching situation can be realized by selecting a valid set of components variations. In order to realize the changes those are described using different meta models, The system proposes a set of operators to effect the change with increased assurance of consistency. These operators are as follows:
Extension operator extends an existing component in terms of classes, entities, and operations as per extension patterns defined in as mentioned in Figures 4, 5 & 6.
Given a component Comp = and a component extension X= , the resultant component CompR = Extend (Comp) is defined as CompR.Own = Comp.Own u X
CompR.X.CX = Comp.X.Cx un=1Extend (Class;) u Instantiate (Cxp) u Instantiate (Oxp) CompR.X.Ex = Comp.X.E,t unl=1Extend (Entityi) u Instantia CompR.X.Ox = Comp.X.Ox u"MExtend (Operation,te (Exp)) CompR.P.O = Comp.P.Operation u provided(CompR.X.Ox)
where provided (CompR.X.Ox) = { V c.operation e CompR.X.Ox | c e Comp.Own } CompR.R.O = Comp.R.Operation u required(CompR.X.O,()
where required (CompR.X.Ox) = { V c.Operation e CompR.X.Ox | c g Comp.Own } CompR.EO = Comp.EO u provided(CompR.X.Ex)
where provided (CompR.X.Ex) = { V e e CompR.X.Ex | e e Comp.Own } CompR.ER = Comp.ER u required(CompR.X.Ex)
where required (CompR.X.Ex) = { V e Є CompR.X.Ex | e g Comp.Own}

CompR.V = Comp.V
Variation operator adds a new variant for a component through addition of class, entity and/or operation variants. Given a component Comp and its existing variation V = < Cv, Ev, Ov>, addition of a new variation Vnew in Comp results into a component CompR, where CompR = Variation ( Comp, V
new/
Such that
CompR.V = Comp.V u V
new
where Vnew.Cv = Instantiate (Cvp) VneW.Ev = Instantiate (Tvp) Vnew Ov = Instantiate (0vp) CompR.D = Comp.D CompR.P = Comp.P CompR.R = Comp.R CompR.X = Comp.X
Well-formedness criteria for adding new variant in a component abstractionis:
V a&t e Cv.name, 3 c e Own.Class | c.free = a&t.attribute and c e Cv.CmetaData
- V c&t E Ev.name, 3 e e Own.Entity | e.free = c&t.column and e e Ev.metaData
- V op G Ov, 3 c e Own.Class | c.operation.override = op
Assembly operator assembles (composes) two or more components to result into a component
that can further be assembled with other components.
Given Components Comp1 = < Own, P, R, EO, ER , X, V > , Comp2 < Own, P, R, EO, ER, X, V
>,and P2R mapping relationship (a set of maps between provided and required interfaces and
entities)
Interface map°(Comp1.Operationi Comp2.Operation;) is defined as
((Operation s Comp1,P and Operation e Comp2.R) A Operation;.In c Operationj.ln A
Operation.Out c Operationj.Out)
OR
((Operation! e Corr^.R and Operation; e Comp2.P) A Operationj.ln c Operationj.ln A Operationj.Out c Operationj.Out)
Similarly entity mapE(Comp1.entityi - Comp2.entityl) is defined as

(entity: e Comp,.EO and entity, e Comp2.ER) OR (entity Є Comp1.ER and entity, e
Comp2.EO) Then
CompR = Assembly (Comp1, Comp2, P2R) is defined as
CompR.Own = Comp1.Own u Comp2.Own
CompR.P = Compt.P u Comp2.P
CompR.R = Comp-1.R u Comp2.R - Resolved (P2R)
CompR.EO = Comp1.EO.own u Comp2.EO
CompR.ER = Compi.ER u Comp2.ER - CompR.EO
CompR.X = Comp-i.X u Comp2.X
CompR.V = Comp1.VuComp2.V Where,
Resolved (P2R) = A set of operations, those satisfy the producer-consumer relationship
between Compi and Comp2, i.e. {V 0| Є Compi.R u Comp2.R | ((3o, e Comp1.P u Comp2.P)
A map°(O1, o1) e P2R A (0| and o, does not belongs to same component))}
According to various embodiments of the invention the system is capable of configuring the database intensive business application at stages comprising design, installation and run stage. A business application comprises of set of components each defined in terms of a set of classes, entities and operations. Therefore, variations of a business application can be seen along the meta objects component, class, entity and operation. Proposed meta models specify pre-defined variation points, possible variants, and constraints specifying consistent plugging-in of a variation point by of a variant. Configuration is a process of selecting appropriate variants so that all variation points are consistently plugged-in for an application. The system supports this configuration process at three different stages of application development: design time, installation time and run time. Design time configuration is supported through model transformation and model merge techniques. The installation time and run time configuration is supported by generating appropriate metadata for all possible variations - a configuration amounts to the metadata for the desired situation.
BEST MODE/EXAMPLE OF WORKING OF THE INVENTION
The invention is described in the example given below which is provided only to illustrate the invention and therefore should not be construed to limit the scope of the invention.
Different enterprises, from the same business domain for example banking sector, they want to open an account for financial transactions. They may have different requirements along with five

dimensions {Functionality (F), Business process (P), Design decisions (D), Architecture (A) and Technology platform (T)} in the database intensive business application, so one can expect a significant overlap in their requirements and hence in specifications. Being ignorant of this overlap would mean rework, and result in specification redundancy which will create maintenance and evolution problems later. The present invention provides for modeling of commonality and variability thus leading to a single specification.
Accordingly, the present invention provides for creation of a common business application with a set of pre-defined variants, selection of a suitable variant from the pre-defined set, and composition of the common application with the selected variant into a purpose-specific business application.
For example consider a scenario for developing a banking application with a core banking functionalities for different operating environments. We assume a banking application with core banking functionalities, e.g. opening account, deposit, withdraw, account transfer, need to be developed for different geographies, for example USA and India; and different sectors for each geography e.g. rural banks, public sector banks and private banks for Indian geography etc.
Though the application will appear the same to users in terms of functional content, its internal structure and behavior can differ from one operating environment to another, i.e. a large bank in USA, a private bank in India, and an Indian Rural bank. The invention refers to such differences as variability. Some scenarios and variability therein are listed below:
• Typically, US banks use Social Security Number (SSN) as primary identification for
customers whereas Permanent Account Number (PAN) is used for similar purpose by
Indian private banks. On the other hand, Indian rural banks may use a combination of
attributes e.g. customer name and mother's name as primary identification for a
customer.
This leads to some variations in class and entity model for USA banks, Indian private banks, and Indian rural banks.
• Layout of a screen to display customer details can be different for Indian private banks
and Indian Rural Banks as mother's name should be present for rural banks and hidden
for other banks.
This leads to different GUI model for Indian rural banks and other Indian banks.
• The functionality of transferring money from one account to another account may differ
for Indian rural bank, Indian private bank and USA bank as they follow different banking
regulations.

The invention presents a method for specifying the above structural and behavioral variations leading to specifying an application family comprising of several related members - specification of each of which can be derived from the application family specification. Family members share a common core and differ from each other in a pre-defined way as listed above. In addition, members can evolve independently as dictated by the needs of their specific environment, for example, Indian private bank may decide to capture customer's marriage anniversary date as additional information in case of married customers. The concept extensibility described in this invention enables to specify these kinds of extensions as a new variant. Moreover, the method specified in this invention enables selection of the appropriate member of the family through a process of configuration. For example, a new USA bank can be configured with SSN number as primary customer identification number and customer's marriage anniversary date, which is present in Indian private bank, as additional field of customer details using suitable configuration.
Also, the invention reduces the cost as well as time for creating new business applications, and leads to effective maintenance and smooth evolution.
The preceding description has been presented with reference to various embodiments of the invention. Persons skilled in the art and technology to which this invention pertains will appreciate that alterations and changes in the described structures and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope of this invention.

WE CLAIM
1) A system comprising at least one computer workstation having graphical user interface associated with the system for enabling user interaction and manipulation of system entities;
a server connected to workstation by the communication network for storing textual specifications necessary for describing application functionality,
at least one other server connected to workstation by the communication network having data repository for storing data particulars necessary for application development, wherein the system develops configurable, extensible business application product line using model driven technique, comprising the computer implemented steps of:
(a) Defining business application specification which is to be transformed into a concrete implementation on an application architecture, wherein the application architecture is layered, with each layer representing one view of the system, comprising Graphical User Interface layer, application logic layer and database layer;
(b) Decomposing business application specification into three models comprising GUI layer model, Application layer model and Db layer model;
(c) Modeling the specification of business application for one or more abstract views, wherein each distinct abstract view defines a set of properties corresponding to the layer and its corresponding model;
(d) Creating three meta models, for each distinct abstract view, wherein the said meta models comprises GUI layer meta model, Application layer meta mode! and Db layer meta model;
(e) Integrating each model to form single Unified meta model, wherein the single unified meta model allows to specify integrity constraints to be satisfied by the instances of related model elements within and across different layers, which enables independent transformation of GUI layer model, Application layer model and DB layer model into their corresponding implementations GUI layer code, Application layer code and Db layer code into a consistent whole and
(f) Implementing each individual transformation of the corresponding specification and relationships with other specifications correctly, resulting in implementations that go together resulting in a consistent implementation of the specification in the application architecture.
2) The system of claim 1 further comprising at least one deployment framework for testing developed application wherein the deployment framework comprises:
At least one computer workstation having graphic user interface for enabling a user interaction with system;

At least one server with Application Server installed on the system for residing developed application and metadata; At least one server with Web Server installed on the system to route user requests to application server and
One data repository to store application data
3) The system of claim 1, wherein the transformations can be performed either manually or using code generators.
4) The system of claim 3, wherein the transformations are specified at meta model level which is applicable for all model instances.
5) The system of claim 1, wherein models are independent of implementation technology and the business application specification can be targeted to multiple technology platforms using code generation.
6) The system of claim 1, wherein the set of rules and constraints are associated with every model for type checking and maintaining consistency between business application specifications of different architecture layers.
7) The system of claim 1, wherein meta models addresses extensibility and configurability of both structural and behavioral aspects of database intensive business application.
8) The system of claim 1, wherein meta models capture changes permissible to GUI model, application model or database model and effects the desired change into application implementation in a consistent manner.
9) The system of claim 1, wherein the meta model enables modeling of a family of screens, wherein each member of the screen family serves the same business intent in a specific situation in the GUI layer.
10) The system of claim 1, wherein the meta model enables modeling of a family of classes, wherein each member of the class family serves the same business intent in a specific situation in the application logic layer.

11) The system of claim 1, wherein the meta model enables modeling of a family of entities, wherein each member of the entity family serves the same business intent in a specific situation in database layer.
12} The system of claim 1, wherein the single unified meta model enables specification of well-formed constraints spanning across the architectural layers
13) The system of claim 1, wherein the system provides component abstraction and an algebra that aids in imparting structural and behavioral properties of database intensive business application.
14) The system of claim 1, wherein the system is capable of configuring the database intensive business application at stages comprising design, installation and run stage.
15) A system substantially as herein described with reference to and as illustrated by the accompanying drawings.