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/email 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 Model Process Action Diagrams

Object Matrices

Procedure Action Diagrams

Common Action Diagrams

Procedure Flow Diagrams

Window Design

Screen Design Data 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

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