1 / 17

Data Model driven applications using CASE

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

Télécharger la présentation

Data Model driven applications using CASE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

  6. Data Model Diagram

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

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

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

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

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

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

  13. Denormalization case

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

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

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

  17. 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 Thank You!

More Related