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

2. Copyright © 2006 Korson-Consulting 2 of 35 MDD Premise Generate systems from models

3. Copyright © 2006 Korson-Consulting 3 of 35 Blueprints to Buildings It is like having a team of Robots that could automatically construct a building from a detailed set of blueprints

4. Copyright © 2006 Korson-Consulting 4 of 35 Blueprints to Buildings Vendors OMG

5. Copyright © 2006 Korson-Consulting 5 of 35 Poll #1 What background do you have with MDD?

6. Copyright © 2006 Korson-Consulting 6 of 35 Natural Progression 00110111000011100 Assembler FORTRAN Ada Java Middleware Components … MDA

7. Copyright © 2006 Korson-Consulting 7 of 35 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. Copyright © 2006 Korson-Consulting 8 of 35 Corporate Architecture multiple industry standards-CORBA, EJB/J2EE,.NET, XML/SOAP, These become “MDA compiler options” instead of “Bet the Company” decisions

9. Copyright © 2006 Korson-Consulting 9 of 35 MDA: OMG’s Current Brainchild Scope makes MDA Unique

10. Copyright © 2006 Korson-Consulting 10 of 35 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. Copyright © 2006 Korson-Consulting 11 of 35 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. Copyright © 2006 Korson-Consulting 12 of 35 MDA Process Business Analysis Use Cases Computation Independent Model Systems Definition Platform Independent Model Design Transformation Platform Specific Model Code Transformation code Deployment executables Transformation Tool Transformation Tool Business Analysis Systems Definition

13. Copyright © 2006 Korson-Consulting 13 of 35 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. Copyright © 2006 Korson-Consulting 14 of 35 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. Copyright © 2006 Korson-Consulting 15 of 35 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. Copyright © 2006 Korson-Consulting 16 of 35 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. Copyright © 2006 Korson-Consulting 17 of 35 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. Copyright © 2006 Korson-Consulting 18 of 35 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. Copyright © 2006 Korson-Consulting 19 of 35 Increased importance Inspections CIM PIM

20. Copyright © 2006 Korson-Consulting 20 of 35 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. Copyright © 2006 Korson-Consulting 21 of 35 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 skills required of testers and the test process itself.

22. Copyright © 2006 Korson-Consulting 22 of 35 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 large finds these errors

23. Copyright © 2006 Korson-Consulting 23 of 35 MDA for Prototyping Repeat Model Generate prototype using MDA Evaluate prototype Until stakeholders are happy with prototype Build system using traditional techniques

24. 24 MDA Hype versus Reality

25. Copyright © 2006 Korson-Consulting 25 of 35 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. Copyright © 2006 Korson-Consulting 26 of 35 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. Copyright © 2006 Korson-Consulting 27 of 35 Current Tools Don’t Always Generate All the Code

28. Copyright © 2006 Korson-Consulting 28 of 35 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 Transformation Tool Transformation Tool

29. Copyright © 2006 Korson-Consulting 29 of 35 Two step Process Transformation Tool Transformation Tool Most of the development Certain architectural configuration and GUI customization Custom business logic

30. Copyright © 2006 Korson-Consulting 30 of 35 Controlled Study

31. Copyright © 2006 Korson-Consulting 31 of 35 Case Study Conclusions 35% gain in development productivity Up to 70% gains in maintenance productivity

32. Copyright © 2006 Korson-Consulting 32 of 35 Poll #2 Will you consider using full code generation from a modeling tool which includes method bodies, for your project?

33. Copyright © 2006 Korson-Consulting 33 of 35 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. Copyright © 2006 Korson-Consulting 34 of 35 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. Copyright © 2006 Korson-Consulting 35 of 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

36. Copyright © 2006 Korson-Consulting 36 of 35