Adaptive Database Application Modeling API

Final Project Report

SOURENA NASIRIAMINICS 491

6/2/2005

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

MOTIVATION

• Looking at how applications were being designed and developed, many tasks are repeated for every application

• Such practices often result in applications that– Often do not contain reusable elements– Are hard to maintain and configure– Have static components that are hard to change

• Such concerns compelled me to think about applications that were– Fully Dynamic– Adaptable– Flexible

MOTIVATION CONT…

• So I could

– Reuse the work I had already done

– Save development time

– Better maintain current applications

– Easily customize/change applications

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

OBJECTIVES

• Design API:

– To help reuse components

– To take advantage of metadata

– Use Metadata to generate components dynamically

– Automatically populate components with appropriate data

OBJECTIVES

• Implementation based on API– E-Commerce Application

•The reference implementation to showcase the API functionality

•To show the benefits of using the API

– Class Registration Application•Showcase the reusability benefits•Time saved using Dynamic components •Benefits resulting from data

independence•Application adaptability

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

ARCHITECTURE

• 3 Tier Model

Domain Specific GUI Component

Final Presentation Component

Business and Process Objects

Database ContainingDomain Specific Data

BusinessTier

PresentationTier

Data Tier

ARCHITECTURE

• Problem:

– Focus on Data (Data Centered)

– Data •Raw•Domain Specific•Cannot be generalized in a useful way

•Does not contain information about its intended use

ARCHITECTURE

• Solution:– Extend the Architecture

– Change focus from data to metadata (model)

– Place model at the center of the architecture

– Use the Model Driven Architecture (MDA)•Allows for dynamic component

generation•Automatic Data Retrieval•Collaboration Benefits (OMG)

ARCHITECTURE

• 4 Tier Architecture

Metadata

Business and Process Objects

Domain Specific GUI Component

Final Presentation Component

Generic GUI Component

Data Tier

ModelTier

PresentationTier

BusinessTier

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

API DESIGN

• Breakdown of Tasks

Dynamic Interpreter

ADAM Designer

ERD of the business Model

Generic GUI Component

Domain Specific GUI Component

Final Presentation Component

Business and Process Objects

Domain Specific Data

ADAM Designer

ADAMAPI

ADAMAPI

ControllerCode

ViewImplementation

Specific

API DESIGN

• In Java 2 platform

– Classes and Interfaces allow the necessary abstractions to separate tasks that needs to be done.

– Intermediate or “Glue” methods pass collections to/from each tier or class implementing an interface (see Implementation)

API DESIGN

• Organization

Modeler Interface

DataBase

Get

Set

Send

Receive

ProcessLoad

Save

Mapper Interface

Viewer Interface

API DESIGN

• Organization– 2 Ways to use the API

1.Extend Each Tier (Any class thereof)

– Maximum control

2.Implement the appropriate interfaces:

– Minimum Complexity

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

API IMPLEMENTATION

• Progress so far:

Modeler

Business and Process Objects

Domain Specific GUI Component

Final Presentation Component

Generic GUI Component

Domain Specific Data

ADAMAPI

ControllerCode

ViewImplementation

Specific

ADAMAPI

API IMPLEMENTATION

• A more detailed view

GUI Manager(Viewer)(Factory)

Interpreter(Modeler)

(Database)

Business Manager(Mapper)

(Processor)

ADAM API

Load()

Send()

Receive()

Save()

Get()

Set()

API IMPLEMENTATION

• Metadata in Java

– In general, applications do not need the name of the columns associated with a ResultSet

– So JDBC designers did not include this in the core ResultSet functionality.

– But in order to develop dynamic data access components, access to this information – the metadata – is essential.

METADATA IN JAVA

• The use of ResultSetMetaData– A call to getMetaData() tells the application about

the structure and organization of the returned results (metadata).

• Examples: – The number of columns in a table. – The label to use for a column header.– The source table for a column.– The data type of a column.

API IMPLEMENTATION

Modeler

Collection (Generic)

Collection Type

Collection Name

Collection Size

Collection Type Instance

APIDatabase Application

Table Name

Column Type

Column Name

Column Size

Data

•Mapping Scheme

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

OUTILINE

• Introduction– Motivation– Objectives

• Approach– Architecture– API Design– API Implementation

• Implementation– First Application (Demo)– Second Application (Demo)

• Conclusion and Future Work

PROJECT TIMELINE (SUMMARY)

Week1

Week2

Week3

Week4

Week5

Week6

Week7

Week 8

Week9

Week10

First Application

Second Application

API Design and Implementation

Final Project Presentation

CONCLUSION

• Using the API

– Dynamic

– Reusable

– Flexible

• Helping to

– Save time

– Increase Quality

Questions and Answers

• Q/A

• Thank you!