Adaptive Database Application Modeling API

Document Sample
Adaptive Database Application Modeling API Powered By Docstoc
					Adaptive Database Application Modeling API

                               Project Report

                Sourena Nasiriamini

                                   Dr. Sun
                                  CS 491B

The purpose of this project is to provide an approach to application design and
development to enable applications to be model and metadata driven. Awareness of
the existence of such models allows applications to detect, be prepared for, and
adapt to changes done to them at the fundamental, structural, and/or Semantic level.
In such systems, the application component or module creation is done dynamically
as the result of the interpretation of the model at runtime which can be changed with
immediate (but controlled) effects on the system interpreting it, or adapted to suit
other similar purposes related the usage domain of the original system. This work
complements the work done in the area of design and development of Model Driven
Architecture (MDA) based applications which emphasize flexibility and runtime
configuration. We call our approach “Adaptive Database Application Modeling” to
reflect the emphasis we put on this application design and development


As it stands today, it is a general practice of businesses to often use databases to
store and organize their data. This approach works well if the goal is to simply store
and maintain data; but once it comes time to add interactivity to this system to
accomplish business and/or application specific tasks, software cannot adequately
and accurately generalize and simulate the practices and processes that need to be
performed, thus creating a shortage and a need to develop custom solutions that fit a
particular business. In this case, once the processes and practices (strategies) need
to be changed, it is hard to adapt to those changes without needing considerable
additional design and development to overhaul and recondition it (if at all possible). I
believe this has roots in the inherent architectural design of such applications as
evidenced by the following architectural design pattern that is in widespread use
today. To mitigate the limitations of the 3 tier model, the 4-tier architecture was
designed. A tier is a high-level, functionally separated software component that
performs a specific function. The 4-tier application architecture provides
improved maintainability, configurability, and reusability.

       Because each tier can be managed or scaled independently, flexibility is
increased in the target system that employs it. Communication between tiers is
accomplished through mapped collections. All functional components, such as
persistent storage (database), component manager, and the marshalling of data
to/from components are separated. This componentization is key, with each
component ascribed to a tier, providing an abstraction for presentation,
management, data, and model. As a result, individual components can scale and
be reused relatively easily.

Current 3 Tier Architectures

 Business          Business and Process Objects
   Tier                                                            Data Tier

                  Domain Specific GUI Component               Database Containing
                                                              Domain Specific Data
                   Final Presentation Component

   My goal is to introduce facilities in the software to have an application be dynamic
and flexible so it can detect the changes made to it at the structural level. Many
businesses have databases that they use to store their data to help them better
organize. This is how businesses mainly conceptualize their business: in the way
they organize and categorize their data which is specific to their business and vital to
their correct operation. As part of my approach towards achieving better adaptability
and configurability of the applications that use such databases, I have made
approaches towards developing facilities in the system to make it aware of the
existence of the data model (database schema in this case) to help increase
reusability and configurability. In my opinion, the availability of this extra information
and the ability to have them available to the application at runtime provides me with
the kind of information I need to achieve my goal of increased adaptability and
flexibility of the target applications that I produce. It also helps accelerate the process
of software development as well since I can reuse parts of the already developed
components in new projects.

   For the implementation, I chose one of the already available and widely used
database systems facilities known as metadata to provide a conceptual and abstract
view of the data it contains to act as a “model” for me to be able to base the
reference implementation on.

   With this approach, the structure of the application would be dependant and
adaptable to changes done to the data model. Database Metadata is used and
exploited to help determine the purpose of, and justify the need for a specific
application component that operates on, and/or displays the data at runtime. In order
to make it easier to understand, perhaps this figure could help:

Conventional methods:
    Database  Data  Static software Components

Our approach:
    Database  Metadata  Data  Dynamic software Components
    Flexible, Adaptable
    As can be seen from the above classification, static software components are the
type of software whose functionality and procedures have been pre-determined and
are permanently made part of the application (also known as “Hard Coding”).
Although for many purposes, this produces the desired effect, for businesses whose
nature is to change and evolve over time, it becomes a limiting factor as far as how
their software system can cope with such changes. This is where the dynamic
software comes into the picture. By making a software component dynamic, the
creation of objects and thus, determination of their purpose can be delayed until
runtime, or when that component is going to be used. This effect is exactly the kind of
effect needed to introduce flexibility to the system since the components do not have
to be predetermined and the system can look at the model, analyze it, and determine
which components to use and which ones not to use, thus giving the power to either
use pre-determined patterns (which simulates the static software component
behavior), or have someone, or another component make that decision and thus
provide the flexibility that is desired.

    There are also benefits of producing software in this manner to the developers.
As it stands today, there is a big gap between those who provide the technology for
use by developers (computer scientists), and those who implement it (developers).
This is the main reason why the costs of developing solutions have become costly
and time consuming. The utilization of this technology helps bridge that gap by
providing a middle ground (model) from which both sides can use to collaborate
more efficiently. This effort ultimately benefits target audiences including, but not
limited to database Designers Who design conceptual data models and organize
data according to their established pattern, application developers who develop
specific application components, and system administrators who will have the benefit
to make reasonable changes to the system without the need to modify the
application drastically or stop it from functioning as a result of such changes.

    With such an approach, part of the development effort is only done once and
work does not need to be multiplied from project to project and can be reused in
many cases. The reusability and the benefits that result from this approach makes
this a more desirable solution compared to conventional design and development
methodologies that aim to accomplish the same goals. As a matter of fact, this type
of approach to designing and developing software would be good for those looking to
reduce costs while at the same time increase productivity. Using this design and
development methodology enables faster design and development from project to
project which result in the creation of more flexible, extendable, and cross platform
applications that not only adhere to latest software development standards, they also
extend and complement them as well.


   Looking at how applications were being designed and developed, I saw tasks that
that were commonly performed in many implementations, and yet had not been
made general enough so many applications could take advantage of and benefit
from without having to reinvent them. As a result of such practices, applications often
did not contain reusable elements, had become hard to maintain, and had too many
static components that were hard to change.

   Such concerns compelled me to think about developing applications that had
more dynamic, adaptable and flexible components so I could reuse the work I had
already done, save overall development time, be able to better maintain current
applications, and more easily customize or change applications depending on the
established requirements set forth by clients at any given level of software lifecycle.


   From the beginning, the goal of producing dynamic, adaptive, reconfigurable, and
flexible applications had been in my mind and my efforts have been focused on
achieving these goals. While these objectives in general seem to be useful in every
project, there are issues that need to be considered to determine if such solutions
contribute realistically to a target system and whether or not it would be beneficial to
implement them. For this reason, in this section, information is provided about the
scope of impact of this approach and target audiences to whom such goals are
important. Additionally, some pros and cons associated with using this approach as
opposed to a current design and development methodologies are discussed.

Impact Scope

Design Level

With this approach, designers need to use a different design methodology in
describing the business entities and relationships. They would have to model a more
abstract view of the data to help act as the application model. They also need to be
careful of what kinds of names they choose because such information gets directly
used in the application (such as table names or column names). Aside from these
added requirements, they need to think about, and come up with a model that
encompasses more use cases so it can be used for similar applications related to the
domain of current applications to help increase the reusability of the model.
Development Level

       Developers would get to develop applications based on the model and not
data specifically. More importantly, they will have another layer of abstraction to deal
with, namely the model layer. In this layer, they would get the information they need
to figure out what kind of components are in each application and what those
components need to do. More specifically, they would retrieve and route particular
data needed for the use of each component from this layer to the next. In the next
Layer, the metadata is used for runtime use determination of presentation
components. Suited presentation components would get populated with appropriate
data and made ready for final presentation. One important distinction to note here is
the fact that all this processing takes pace at runtime and only guidelines on what to
use in what situations should be provided to the system.
Administration and support Level

       Better and more flexible software solutions result from such realtime and
model driven application construction. Moreover, introducing change would become
a more streamlined and straightforward practice and one that needs less
programming than previously needed (for reasonable changes related to the domain
of course).

Target Audience

Based on the scope of the impact that we provided in the previous section, the
following classifications of professionals would get the most benefits from this
   1. Application Designers:
              a. Who need to design while adhering to certain guidelines
              b. Who need to organize data according to an established pattern
   2. Application Developers:
              a. Who Develop Specific application components relevant and dependant
                 to the organization of the data and not data specifically.
   3. System Administrators:
              a. Who need to make changes to the data model without modifying a
                 large subset of the application as a result of such changes.
              b. Who do not want to have developers make changes to the system.
              c. Who want software to be more flexible and robust so it would be able
                 to function with similar interchangeable components.

Pros and Cons

Aside from the benefits that were mentioned earlier, there are some complexities and
extra development overhead that need to be taken into account. Fist of all, designers
have to figure out how to store and represent the model in the database. They also
need to think about how to best present the domain element to the user. In many
cases, they need an interface or a tool to hide the complexities from the user and
makes business rule and data change easy and straightforward. Also, they have to
specify rules on how to maintain the model. Since mapping of metadata to collections
takes place, they need to know how objects are saved and proper semantics for
describing business rules. Editors and programming tools that assist users need to
be developed, as well as black box tools and frameworks to aid in describing and
maintaining business rules. In the presentation side, generic GUI components need
to be designed and developed that take advantage of the mapping provided to them
which is more difficult since there are higher level abstractions.

It should be noted that there are certainly tradeoffs that have been made in order for
the desired outcomes to be realized and they should be carefully examined to
determine if they are worth making for the project.


       This approach has its own strengths and weaknesses and is most useful in its
own area of application. However, in order to show the flexibility of the system, it was
decided to provide a reference implement based on this approach and leave the final
determination of usefulness to the potential users of the system.


The approach towards component development is to make them generic, model
aware, and runtime configurable. Towards achieving such a design goal, the Factory
pattern is employed to make them more generic, as well as runtime configurable,
since the information about where or how these components are going to be used is
not available at compile time, they need to get such information through configuration
documents. To make these components generate from modular descriptions, a layer
has been put over the architecture to oversee such constructions and runtime
configuration. This is where the defined interfaces come into the picture. They help
facilitate the use of polymorphism to add such functionality to the target components.


4 Tier Architecture of ADAM

After careful examination of the problem and contemplating ways to solve it, it was
decided that since the problem has inherent architectural roots, a better architectural
style that accommodates and complements the use of such metadata in application
construction had to be introduced and used.

In this approach, I considered the database schema as my application template or
model, and designed the facilities to automatically retrieve data and construct the
application objects and components based on the model.

                         ERD of the business Model


                       Business and Process Objects

Business                                                     Model
                          Generic GUI Component


                      Domain Specific GUI Component

                     Presentation                                         Data

                       Final Presentation Component

I wanted to totally separate the application model from the code by describing
application components and other modular information outside the code. But during
the course of development, it became evident that at some point in development, the
requirement for more power and flexibility come into the picture. The ability to
automatically generate application components is related to how well those
components can be described in the database schema and how well their
relationship can be preserved therein. Consequently, in cases where components
and their relationships can be described easily using relational modeling, it would be
plausible and justified to use this method to achieve the desired outcome. But in
cases where complexity makes modeling hard, the solution needs to be customized.

                          Extended 4 Tier Architecture


                                       Model                         Tier

                                                           Runtime Configuration Info
             Data Tier            Data/Application Model


   There are numerous ways to describe what metadata is, but a simple definition,
at least in this context, is "information about data and how it is organized”. Simply put,
metadata is data that describes other data. In this case, it describes the structure and
characteristics of a relational database management system (DBMS). For example,
XML files are a form of metadata that you probably use every day.
   Metadata can be defined as a set of assertions about things in our domain of
discourse. Metadata is a component of data, which describes the data. It is "data
about data". Often there is more than that, involving information about data as it is
stored or managed, and revealing partial semantics such as intended use (i.e.,
application) of data. This information can be of broad variety, meeting if not
surpassing the variety in the data themselves. They may describe, or be a summary
of the information content of the individual databases in an intentional manner.[1]
Java Pro comments: Most programmers understand the importance of writing code
that is reusable, but it's often difficult to do so, particularly with code that accesses a
relational database. Such code frequently contains many statements that are specific
to the application and will rarely, if ever, be useful in another application. While some
application-specific code may be unavoidable, you can improve reuse when it comes
to database programming. In particular, the metadata already provided by databases
can be helpful in this area.[2]

API Design

Component Management

In this approach, components are dynamic and each component is populated with
data extracted from the mapped data structure that it receives from the modeler or in
this case, the database class that acts as the active modeler for the application. On
the Viewer side, component placement and management within the graphical user
interface is handled by the main frame of the application that keeps track of what
components need to be active at any one time during the execution of the
Data and Metadata Mapping

       Database                       API                         Application

       Table Name                                                 ArrayList (Generic)

      Column Type                                                 ArrayList Type
      Column Name                                                  ArrayList Name
       Column Size                                                 ArrayList Size

          Data                                                     ArrayList Instance

                                             ADAM API
         Business Manager
                                              Send()         Save()

                          Set()                                           GUI Manager
                                             Interpreter                       (Viewer)
                           Get()               (Modeler)                       (Factory)

                                                                        Runtime Configuration Info
             DataBase                        Application Model

        Viewer                     Mapper                           Modeler
       Interface                  Interface                        Interface
         Load                      Process                       Send


         Save                                                Receive

   There are 2 Methods provided to use the API which provide the maximum
amount of flexibility to anyone who chooses to use the API.
   1. Inheritance (Extension of any class thereof): Extending the Tiers would
      maximize control over the API for anyone who wishes to customize it and add
      features or optimize the code (when solving complex problems).

   2. Implement the appropriate interfaces: Implementing an interface would make
      development easier and leaves the handling of the components entirely to the
      API. It also hides the implementation details from developers and allows them
      to focus on implementing higher-level functionality related to the problem they
      are trying to solve.

API Implementation


   The bulk of the functionality of this API resides on three classes which interpret
modular information about the application, carry safely and efficiently data and
metadata to and from the database, and oversee such processing with appropriate
interfaces to manage them:
                                Modeler Package Contents

               Database Class       Database Connection         Model

              SQL Statements                                  Interpreter:
            Prepared Statements                             XML Processing
             Exception Handlers
             Interface Methods:                           Component Discovery
                  Get & Set                                Database Discovery
                                     Exception Handlers
              Send & Receive

   Handles additional required operations on raw data received from the database.

                          Mapper Package (Processor)

                                   Collection Classes
                                 (Component Specific)

                     Access to the Database Class for information

                     Collection of choice due to its generic nature.

                    Handles additional required operations on raw
                    data received from the database to the viewer.


At this point, the GUI components are whown according to how the collection was
constructed at runtime by the Database (Modeler) and Processor (Mapper).
Conclusion and Future Work

        The implementation of this architecture contributes to many areas of software
design and development, as well as target audiences such as those who maintain
those software systems and applications. Utilizing this approach, results in
applications that are better, more flexible, maintainable, and reusable. The use of this
technology impacts all those who are involved at the design level by giving them a
different design methodology to work with, those at the development Level which
benefit from abstraction of data from the data container, manipulator, and viewer, and
last but certainly not least, those involved in the maintenance and support level who
will be provided with a better and more flexible software solution.


[1] Kaarthik Sivashanmugam, Amit Sheth, John Miller, Kunal Verma, Rohit Aggarwal, Preeda Rajasekaran,
Datenbanken und Informationssysteme, Festschrift zum 60. Geburtstag von Gunter Schlageter (Publication
Hagen, 2003).

[2] Java Pro (

      First Application                                        Second Application