Data Model driven applications using CASE Data Models as the nucleus of software development in a Computer Aided Software Engineering environment

Why do this presentation? Attended DAMA Orlando and discovered that: –Nothing much has changed in years!!! –COBOL replaced by Visual GUI development tools –Hierarchical DBs replaced by RDBMS –Paper/ documentation continues to be the main means of communication for software development –Little automation of software development functions –Information Engineering (IE) is a dirty word Most significant improvements: –Data and Process Modeling introduced in the 80’s –ERD and DFD enable document creation and Data Definition Language (DDL) generation –Context Sensitive Editors and Wizards

Data Model as the catalyst for software development in a traditional environment Is the primary working document where business objects and rules are documented Evolves into a “common” language between IS people and the business area owners (users) Provides the basis for the physical design of the RDBMS BUT… Once construction starts it’s seldom used for software development Becomes a fixture in the “project documentation” shelf May be added to a meta-data repository for research Becomes obsolete with new releases (lack of updates) Seldom used by developers after release 1.0 (low awareness)

Data Model as the nucleus for software development in a CASE environment Is also the Catalyst BUT… It becomes the nucleus of the application Without it, there cannot be any processes Without processes, there cannot be an application Developers are DATA MODEL AWARE Never becomes obsolete It is always maintained up to date

CASE and the Encyclopedia. Diagrams use objects from the encyclopedia Application is modeled entirely as diagrams Code is generated from the diagrams Encyclopedia (Metadata) Data ModelProcess Action Diagrams Object Matrices Procedure Action Diagrams Common Action Diagrams Procedure Flow Diagrams Window Design Screen DesignData Structure Design Business System Definition Process Hierarchy Target Environment Application Packaging

Data Model Diagram

Entity Type Properties Processing considerations are captured in the ERD Extensions provided for Component Based Modeling

Process Decomposition Functions and Processes Process Normalization Provides the initial tie between a process and an entity

Action Diagrams Ties the business process with data model elements Implement business policy Specifies ENTITY ACTIONS--CRUD and ADT ( (associate, disassociate, and transfer)

Data Modeling in a CASE environment Requires a different approach than Entity-Relationship tool modeling –Includes physical constraints Denormalization, entity merging, reference entities –Captures implementation properties Volume, TD names, encapsulation, % relationship participation Requires a practical approach –Not as expressive as a pure conceptual model –Implementation constraints introduced –Simplifies the specific vs. generic choice Implementation decisions must be made early in order to: –Save processes, objects, and space –Enhance performance (reduce table joints)

Logical to Physical transformation Straight forward process in a CASE environment Provides the code generator with a physical world view of the data Changes can be re-generated as needed Physical considerations captured in the data model are put to work as a “technical design” for the targeted RDBMS and code generator –Tables –Columns –Indices –Database specific variables specified –Referential Integrity rules (by DBMS or by CASE)

Impact analysis for change management Encyclopedia query tools assess instantly the impact a change to the data model would cause to processes and procedures

Denormalization case

Initial implementation made late in ‘95 Additional READ actions needed to get Provider, Diagnosis, and Modifier data for each charge created performance problems. Solution de-normalized 11 attributes into Charge. Referential Integrity not a problem. All 3 entities never get deleted. “Views” of the new Charge attributes replaced the views of the three associative entities in the affected diagrams Done in ’99 as part of normal release activities. Simplified the diagrams affected.

Traditional Applications Traditional Applications. What are they? –Any application coded in native language (3GL/4GL) –Any application coded to perform in a specific platform –Business rules and knowledge are “embedded” in the application –Non portable and costly to modify and maintain Software development is viewed as an expense. Applications deployed using “old” and “new” languages. New applications become “legacy” when they hit production Inherit the same challenges faced by “old legacy” apps. OO languages have steeper learning curves for IT staff. Trend is to do it “cheaper” and “faster”

Model Driven Development By definition, is not “traditional” because models: –Are not hard coded –Are portable –Can be deployed to multiple platforms –Can be shared and reused –Are technology independent –Are an INVESTMENT because they: Capture data and business rules Capture the processes that deploy the business rules Capture the interfaces that implement the processes Are abstract and language independent Can be modified/redeployed across multiple languages and platforms with minimal labor expense Trend is to do it “efficiently” and “defect free”

Closing Points Information Engineering (IE) provides a “data centric” approach to software development CASE provides the tool environment for IE to become feasible Data and process integration is a result of IE in a CASE environment Models are an investment Models are re-deployable across target languages and RDBMS’s IE and CASE makes the software life cycle sustainable because DATA and PROCESSES are integrated IT staff learns how to build models in IE IT staff does not learn to build code in a variety of languages