1. Adaptive Database Application Modeling API Final Project Report SOURENA NASIRIAMINI CS 491 6/2/2005

2. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

3. 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

4. MOTIVATION CONT… So I could –Reuse the work I had already done –Save development time –Better maintain current applications –Easily customize/change applications

5. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

6. OBJECTIVES Design API: –To help reuse components –To take advantage of metadata –Use Metadata to generate components dynamically –Automatically populate components with appropriate data

7. 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

8. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

9. ARCHITECTURE 3 Tier Model

10. 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

11. 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)

12. ARCHITECTURE 4 Tier Architecture

13. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

14. API DESIGN Breakdown of Tasks

15. 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)

16. API DESIGN Organization

17. 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

18. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

19. API IMPLEMENTATION Progress so far:

20. API IMPLEMENTATION A more detailed view

21. 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.

22. 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.

23. API IMPLEMENTATION Mapping Scheme

24. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

25. OUTILINE Introduction –Motivation –Objectives Approach –Architecture –API Design –API Implementation Implementation –First Application (Demo) –Second Application (Demo) Conclusion and Future Work

26. PROJECT TIMELINE (SUMMARY) Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 First Application Second Application API Design and Implementation Final Project Presentation

27. CONCLUSION Using the API –Dynamic –Reusable –Flexible Helping to –Save time –Increase Quality

28. Questions and Answers Q/A Thank you!