Timothy D. Korson tim@korson-consulting

1. Model Driven Development:A New Symbiotic Relationship Between Developers and Testers Timothy D. Korson tim@korson-consulting.com

2. MDD Premise • Generate systems from models

3. Blueprints to Buildings • It is like having a team of Robots that could automatically construct a building from a detailed set of blueprints

4. Blueprints to Buildings OMG Vendors

5. Poll #1 • What background do you have with MDD?

6. Natural Progression • 00110111000011100 • Assembler • FORTRAN • Ada • Java • Middleware • Components • … • MDA A Major Goal of UML 2.0 was to Enable MDD

7. State of Software Development • Lots of advances, but programmers still spend and inordinate amount of time on details that could be automated • Distribution mechanisms • GUI layout • Database structure and access mechanisms • And there is still a huge disconnect between requirements, architecture and code

8. Corporate Architecture • multiple industry standards-CORBA, EJB/J2EE, .NET, XML/SOAP, • These become “MDA compiler options” instead of “Bet the Company” decisions

9. MDA: OMG’s Current Brainchild Scope makes MDA Unique

10. Family of OMG Standards • MDA is an umbrella over a growing family of standards that now includes the UML V2.0, the Meta Object Facility (MOF), the Common Warehousing Model, and the Software Process Engineering Metamodel (SPEM), among others. • Model Driven Development is a more generic term that includes approaches that do not adhere to the MDA standards

11. Current Problems in Software Development • Portability/new technologies • Rapid pace of change • Interoperability • Maintenance and documentation • Lack of documentation • Any documentation one does have is out of date • Too much overhead

12. MDA Process Business Analysis • Use Cases • ComputationIndependent Model Systems Definition • Platform Independent Model Design Transformation • PlatformSpecific Model Code Transformation • code Deployment • executables Business Analysis Transformation Tool PSM CIM Systems Definition Transformation Tool Code PIM

13. MDA Benefits • Productivity • Automated transformation tools • Portability • Multiple PSMs for a given PIM • Interoperability • PSM bridges • Maintenance and Documentation • Maintenance is done directly on the models so the models cannot get out of sync with the code. • The models are no longer overhead

14. MDA Advantages 1. The business logic for PIMs can be developed, and validated, by business analysts with little or no technical background. Some MDA tools even let you “run” a PIM on a virtual machine to test it. 2. There is full traceability from PIM through PSM and the ultimate deployed software. This provides a great deal of quality assurance. 3. Subsequent changes in either the business model or the technology platform can be gracefully accommodated. Changes in the technology don’t require changes to the PIM. Changes to the PIM can be traced to determine their likely impact on the PSM and ultimate deployed implementation.

15. Not Your Father’s UML • Most UML modeling tools generate code • One UML class – one Java class • MDA tools are model-driven, pattern-based • One UML class – many code artifacts MDA tools intelligently generate infrastructure from models

16. From a Customer Class in UML • A good MDA tool can generate (for example): • The appropriate Data definition language to create, delete, and init the RDBMS table. • A Data Access Object or Enterprise JavaBeans data access layer • A SessionFacade to access the bean • A ServiceLocator to find the bean • A set of Data Transfer Objects to pass to the web tier • A Struts-based framework to perform CRUD operations on a "Customer" • All the security, logging, exception and other hooks that one would expect to use

17. Focus • Changes from Coding to Modeling • Business analysts will not need IT skills in order to stay involved in systems development from beginning to end • Geeks will focus on building the MDA transformation tools • Business applications will be build by analysts and architects skilled in modeling

18. Agile MDA • Incremental techniques work well with MDA • Most XP practices such as “pair programming” extend naturally to MDA • The PIM replaces what “code” is to agile development teams

19. Increased importance • Inspections • CIM • PIM

20. System testing still needed • With MDA software developers can generate far more code than with traditional techniques • Testers are already faced with more work than they can handle • How will testers keep up with MDA developers???

21. If You Can’t Beat Them, Join Them • An automated test suite is a software system • So use MDA • UML testing profile(U2TP) • The models that developers use to generate the application are useful to the testers This will have a major impact on the skillsrequired of testers and thetest process itself.

22. Generated Code Should be Bug Free • Focus can be on testing business logic rather than the middleware and other system code and interactions. • We assume the C compiler doesn’t introduce translation bugs into the assembly code • Community at largefinds these errors

23. MDA for Prototyping Repeat Model Generate prototype using MDA Evaluate prototype Until stakeholders are happy with prototype Build system using traditional techniques

24. MDA Hype versus Reality

25. MDA Compliant • Vendors make MDA claims whenever their tool implements one of the many standards in the MDA family of standards • This is misleading • An MDA environment should be able to turn a PIM into a running system

26. Current Tools • There are only a handful of vendors that produce full fledged MDA tools. If you see a long list anywhere – it just isn’t correct

27. Current Tools Don’t Always Generate All the Code

28. PIM Transformation Tool PSM Transformation Tool Code They Do Generate the Messy Error Prone Code Generated • Middleware • Business objects • Data Base stuff • Objects and method stubs • Default GUI Typically Not Generated • Customization to the GUI • Method Bodies for the Business algorithms

29. PIM Transformation Tool PSM Transformation Tool Code Two step Process Most of the development Certain architectural configurationand GUI customization Custom business logic

30. Controlled Study

31. Case Study Conclusions • 35% gain in development productivity • Up to 70% gains in maintenance productivity

32. Poll #2 • Will you consider using full code generation from a modeling tool which includes method bodies, for your project?

33. Crystal Ball • MDA is not the only game in town. • Neither the problems that plague the software industry, nor the principles of good software engineering are secrets known only to the MDA elite. • All the tool vendors out there are searching to find solutions that will win in the marketplace. • At the same time that MDA environments are starting to mature, IDEs are becoming more and more powerful and multi-use components more widespread. • My personal opinion is that both the IDE style programming approach and the MDA style modeling approach will exist side by side during the next decade. • MDA will not take over the application development space, but it will play an important role there. • Two of the biggest risks to the future of MDA are: • Will the development community be patient with MDA while the MDA tools mature, and • Will the OMG find the “right” way to specify business logic at the PIM level in a timely manner.

34. Conclusions • MDA is a natural step in raising the level of abstraction at which we develop systems. • MDA embodies the basic engineering concept of separation of concerns. • It is clear both intuitively and anecdotally that MDA can lead to important gains in productivity, portability, and the ability to focus on business functionality as opposed to technology details. • Most importantly, MDA is not a proprietary vendor initiative, but is a technology enabled by a family of standards developed by the OMG consortia of computing users and vendors. • The implications to testers of a move to MDA style development are especially significant.

35. Thank you for attending • Please feel free to contact me with any follow up questions or comments Timothy Korson tim@korson-consulting.com www.korson-consulting.com