1 / 18

Models in design

Models in design. Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India. Context. Certain kinds of software built w idely by people all over the world Eg. 3 tier business applications GUI front end Middle-layer: business logic Back end: database

artan
Download Presentation

Models in design

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. Models in design Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India

  2. Context • Certain kinds of software built widely by people all over the world • Eg. 3 tier business applications • GUI front end • Middle-layer: business logic • Back end: database • Several instances share commonality • Similar design decisions repeated • Similar tradeoffs repeated • Similar implementation repeated

  3. Wisdom • The sum of learning through the ages; knowledge: “In those homely sayings was couched the collective wisdom of generations” (Maya Angelou) • Wise teachings of the ancient sages

  4. Manifestations of Wisdom • Patterns • Frameworks

  5. Patterns • Design artifacts from accumulated design experience • Named, classified and cataloged • “Each Pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice” • Informality part of the “culture” • To “formalize patterns” is tantamount to restricting them, and hence restricting their creativity

  6. Frameworks (1) • One person’s view on how to factor the commonality in “widely repeated” software construction • Fancy term for this is: MDD (Model Driven Development) • Features • Diagrammatic specification at a high level of abstraction as “models” • Automatic code generation • Employs certain commonly used patterns, but they are pre-chosen and pre-wired according to the tastes of the framework author • Semantics is given in terms of the generated code: • Only the framework-author knows how to use the framework best

  7. Frameworks (2) • Advantages • Improved productivity • Disadvantages • Have to “buy in” to the framework-author’s opinions • Stepping “outside” the framework is hard • Requires modifying generated code (consistency between code and model is now broken) • Requires modifying the framework itself!

  8. Frameworks everywhere • Inside Microsoft • Presentation Foundation (Avalon) • XAML based declarative data-driven UI • Workflow Foundation • XOML based declarative workflow specifications • Connection Foundation (Indigo) • Will become more declarative • Microsoft Business Solutions • Several products (CRM, ERP, Axapta) are based on models • “Whitehorse” and Software Factories projects in Visual Studio • In India • Indian SIs have been doing model driven development for some time • Mastercraft from TCS

  9. Mastercraft from TCS • TCS = Tata Consultancy Services, a “big” consulting company based in India • Model driven development framework for Enterprise Business Applications • Built from consulting experience building such applications repeatedly over several years

  10. Impressions about frameworks • Can be used best by people who have built them • Semantics are in terms of “generated code” • Understanding the semantics of the application is not easy • Mastercraft people agree that this is a problem. A quote from one of their papers: • “Model-driven development has resulted in improved productivity, better quality and platform independence [Mastercraft]. However, it has not been very successful in supporting reuse and system evolution due to inadequate modeling support for clear separation of concerns and their composition”

  11. State-of-the-art • Semantics is in terms of “generated code” • Understanding the semantics of the application is not easy • Consequence: Tools need a lot of support and “hand holding”

  12. Research Opportunities • Can modeling become a “true” programming abstraction? • What kind of programming tools are needed here? • How useful are these high-level programming abstractions? • Opportunity to work with Indian SIs (Infosys, TCS, etc) • Understand usability and give feedback • How far can modeling go? • Can device drivers be generated from higher level models? • Can some of the newer API efforts (eg. adapters) benefit from declarative modeling? • How does one design a correct “model compiler”? • Recall: it took several decades to understand traditional compiler correctness

More Related