How to achieve greater productivity and quality by using MDD on Agile projects.

1. Model-Driven Development for Agile Projects

2. Objectives
• Drive down development time and costs and increase product
quality
• Proactively head off technical debt and ensure architectural
integrity
• Jump start development projects with proven conventions
• Attain solution space knowledge continuity
• Drive down maintenance costs
• Enable platform-level refactoring

3. Balance Concerns
Architectura Rapid
l Integrity Delivery

4. Why Model?
• Models provide a representation of problem and solution
space knowledge that is portable and persistent
• Common lexicon for communicating concepts and building
understanding across all developers
• Picture is worth 1000 words
• Basis for conversation about the relationships of key
abstractions in a system

5. Software is Executable Knowledge*
• Books and similar media contain static knowledge
• Software encapsulates knowledge about how to solve a
problem in such a way that the application of that knowledge
can be automated
• Model-driven development allows us to use software to
automate our knowledge about how to implement software
systems
* Of Zeppelins and Jet Planes; Phil Armour

6. Model-Driven Architecture Theory
• A methodology wherein system functionality is defined as a
platform-independent model, using an appropriate
specification language and then translated to one or more
platform-specific models for the actual implementation
• The executable software is an output of a system which takes a
technology-independent description of the solution as an input

7. Not Just Code Generation
• A way to continuously encapsulate new development
knowledge in ways that can automate development
• Retain key business knowledge across heterogeneous
technologies
• Allow developers to focus their creativity on parts of
the system that matter the most to users
• Not just point-in-time activity

8. Types of Models
• Platform-Independent Model (PIM)
– Describes the business concerns of an application in a technology-agnostic
way
– Bridges between problem and solution spaces
– Holds true regardless of what technology is used to implement the system
• Platform-Specific Model (PSM)
– Describes how the PIM will be realized using a specific set of implementation
technologies (e.g. Java, .NET, Ruby, Objective-C, etc.)
– Describes the implementation mechanisms of a system
– PIM can be implemented using any number of PSMs

9. Keep Models Simple
• Pick a terse domain-specific language for the PIM
• The more complex the modeling language and
conventions, the less effective it will be in
communicating the essential information
• Don’t try to model everything
• “Advances” like UML 2.0 actually went the other
direction
– Made modeling less accessible
– Irony is the goal was to better enable MDA

10. Example DSL For Software Systems
• Entities
– Things that have state
• Controls
– Things that orchestrate interaction between entities to realize
some functionality
• Boundaries
– Sit between external actors and the system
• Enumerations
– A fixed list of values
• Primitives
– Simple, atomic types

11. Example Model

12. Codify Implementation Patterns
• Implementation patterns are platform-specific
• Architectural mechanisms
• Where do patterns come from?
– Previous development projects
– Prototypes
– Other peoples’ projects
• Encapsulate pattern knowledge into transformation
templates
• Defines the development conventions

13. Keep the Transformation Language Simple
• Minimum specification needed to access model
elements
• Minimum utilities needed to handle string functions
like capitalization
• Simple decision structures

14. Example Transformation Template

15. PIM + Transformations = Source Code

16. Benefits of MDD
• Improve developer productivity
– Automate development of “plumbing” code
• Increase the value of each manually developed line
of code
• Improve code quality and maintainability
– Convention-based approach limits entry points for manual
development
– Code generation drives up code consistency

17. Benefits of MDD
• Spend more time understanding user needs!
• Rapidly adapt to changing needs
– Refactor the templates to use new conventions or even
new programming languages
– Preserve platform-independent aspects of design
• Build systems that are self-documenting
• Spend less time starting new projects
• Decrease time to onboard new developers

18. Blending MDD and Agile
• Treat models as development artifacts not
documentation artifacts
• Keep it simple
• Model and generate code continuously
• Make implementation knowledge executable to
continually increase velocity

19. Minimize Waste & Keep it Simple
• Only model parts of system needed to implement current
iteration’s stories
• Don’t try to model everything
– Focus on key abstractions
– Too much detail leads to models that are overly complex and
difficult to maintain
• Don’t try to generate all the code
– Doing so can lead to technical debt in the transformation
templates
– Only generate code for architectural mechanisms you actually
need
– If figuring out how to generate something seems tortured
maybe it shouldn’t be generated!

20. Continuous Model Transformation
• Integrate model transformation into every build
• Ensures code and model are always in sync
• One-time or infrequent model transformations
– Same negative effects as not doing CI with source code
– Undermines value proposition of MDD altogether

21. CMT Implementation Strategy
• Put boilerplate code in
immutable base classes
– Re-generate immutable code
every build
• Put hooks for manual
development in leaf nodes
– One-time generation of
modifiable code, don’t re-
generate

22. Balance Rigidity Against Flexibility
Rigidity Flexibility

23. Putting It Together
Structural key abstraction changes
PIM Non-Modifiable Code
Value added behavioral and
Architecturally significant changes user experience changes
TT
T
Transformations
Modifiable Code

24. MDD + Testing
• Enable test developers to focus on test logic
development
• Use MDD to generate test helper components
– User interface element finders
– Access server components
• Do not generate verification logic

25. Atlas MDD Toolkit
• Open source (http://atlas-mda.org)
• Specifies a very simple DSL for describing systems
• Supports any modeling tool whose model representation
can be adapted to the Atlas DSL
• Model transformations developed using Velocity open
source template language
• Simple configuration of transformation target attributes
– E.g. output path, overwrite, etc
• Easily pluggable into common build environments
– Maven, Visual Studio, command line, etc

26. Support for PSM Guidance
• Platform-specific guidance when all the information
needed to generate code doesn’t exist in the PIM

27. Simple Configuration

28. Atlas Maven Configuration
• Plugs into the generate sources target

29. Case Study 1 – Failed Project Rescue
• Previous vendor:
– Took 3 years to deliver base functionality with unsustainable
technical debt
– Cost tens of millions of dollars
• Using MDD, our team:
– Re-implemented base functionality and established new
conventions and templates in 4 months
– Added several new high-value features
– Attained a 70/30 generated/hand-coded ratio
– Cost less than one million dollars
– Left the client with a model that described the system and a
development platform to add new features

30. Case Study 2 – Bootstrap Development Team
• Initial agile seed team formulated conventions and
architectural mechanisms during development of initial
stories
– Majority of technical complexity driven out
• Less experienced developers added to multiply
development throughput
– Conventions and plumbing already established
– Most development was “between the braces”
– New developers immediately productive
• Seed team detached and left less expensive, self-
sufficient team in place
• Led to multi-million dollar follow-on award to add
incremental functionality on product base