Presentation about model driven development for small-mid sized companies

1. A Lightweight MDD
Process Applied in
Small Projects
Gabor Guta, PhD

2. info@axonmatics.com
Contents
Introduction to MDD1
The Process2
Conclusion3

3. info@axonmatics.com
Motivation
 Generative approaches become popular like
 model driven development (MDD),
 domain specific languages (DSL), etc.
 Several success stories about applying these
techniques in large
 Process frameworks and methods for full scale
application of them
 Lot of software developed by small teams using
Agile methods
There is no or little help of its application in small!

4. info@axonmatics.com
What is MDD?
 Generating software from a model
– Advantage: saving time/effort on implementing
repetitive tasks by working on model level
 The most well known approaches are the
followings:
 OMG's MDA
 Microsoft's Software Factories

5. info@axonmatics.com
What is MDD? (cont'd)

6. info@axonmatics.com
What is MDD? (cont'd)
 The artifacts generating transformations are often
called templates
 Domain & intermediate models can be described
with meta-models

7. info@axonmatics.com
Differences
 What is the domain model (real life /
implementation)?
 How can the domain meta-model be
represented?
 What kind of notation do we use to communicate
the domain model?
 How are the transformations defined?
 Do we allow to edit the intermediate models or
the generated artifacts?

8. info@axonmatics.com
Further differences
 How does MDD affect the development process?
 Are we able to reverse the transformation
(propagate changes of the generated artifacts
back to the original model)?
 How can intermediate models be merged if the
original generated model was modified and a
different one was generated after the domain
model was changed?
 What are the quality implications of the MDD?
 How does it modify the test and review procedures?
 What kind of additional problem can be expected?

9. info@axonmatics.com
Important Issues of the Lightweight MDD
 Most of the risks should be mitigated
 No immature technology allowed
 Fall back to the traditional development method
 The approach should not delay the schedule in
general
 It should have immediate business advantage
 The approach should be cost sensitive
 No high cost MDA tool set,
 No extensive training

10. info@axonmatics.com
Important Issues of the Lightweight MDD (cont'd)
 The domain-model should be kept as simple as
possible and the generated code should be
human-readable and modifiable.
 The results should be reusable in other projects.

11. info@axonmatics.com
Our Minimalistic Approach
 Creating the simplest solution
 Using the simplest tool-set
 Explicitly support the partial approach
 We just model and generate parts where it pays off
 Keeping track of which requirement applied in the
model is relatively cheap

12. info@axonmatics.com
Project Experience
 An enterprise web application for a specific
domain developed
 Microsoft’s ASP.NET technology and an MS-SQL
back-end were used (conforming to architectural
guidelines of the multi-layer enterprise ASP.NET
applications
 Readable source code and complete developer
documentation
 The project team experienced with traditional
iterative development method (containing
elements from current Agile methodologies)

13. info@axonmatics.com
The Process
 Roles
 Artifacts
 Activities
 Workflow

14. info@axonmatics.com
The Workflow (overview)

15. info@axonmatics.com
Teams
 The agile development team
 Members were: developers, a software architect
 Responsible for: hand crafted software
 The business analyst team
 Members were: managers
 Responsible for: requirements and the domain models
 The model driven development team
 Members were: an MDD expert, developers
 Responsible for: MDD environment, the templates

16. info@axonmatics.com
Artifacts
 An MDD vision
 A code generation tool
 A domain test model
 An MDD environment (domain metamodel, a
domain test model, and a code generation tool).
 Hand crafted software
 Released software
 A software requirement specification (or
requirements)

17. info@axonmatics.com
Activities
 Domain model extraction
 In: requirements
 Out: initial domain model, MDD vision
 The MDD environment setup
 In: MDD vision, initial domain model
 Out: code generation tool, initial version of the domain
meta-model, domain test model
 Domain modeling
 Refine: domain model
 The MDD environment development
 Refine: MDD environment

18. info@axonmatics.com
Activities (cont'd)
 Template development
 Refine: templates
 Steps:
 the required functionality is implemented in a software
prototype;
 the implementation is extracted and to edited into the
templates;
 finally, the they are tested with the help of the domain
test model.
 Code generation
 In: templates and domain model
 Out: generated artifacts

19. info@axonmatics.com
Activities (cont'd)
 Integration
 In: generated artifacts, hand-crafted software
 Out: released software
 Development
 Requirements Refinement
 Architectural prototyping
 Design
 Development

20. info@axonmatics.com
The Workflow (part 1)

21. info@axonmatics.com
The Workflow (part 2)

22. info@axonmatics.com
The Template Development Activity
 The most complex and critical activity of the
process
 It becomes dominant activity of the MDD team
after the MDD environment is stabilized
 During an iteration several features are
implemented iteratively in the frame of this activity

23. info@axonmatics.com
The Template Development Activity (cont'd)
 A feature is implemented as an extension of the
generated artifacts (designed, coded and tested)
 The implemented feature is extracted from the
source code and inserted into the templates
 The artifacts re-generated with the new templates
 Tested with the test-cases of original
implementation
 The first iteration is sightly different, because no
prior generated artifacts available at that time.

24. info@axonmatics.com
Conclusion
 Our model driven development method has been
applied successfully
 Our "experiment" has two results
 our process can be used successfully in an averages
small-mid sized project
 project can be realized with standard data format (XML,
JSON, or YAML) and template engines (XSLT, Jinja2,
etc.), i.e. no need for special MDA/DSL tool chain
 Our process can be also used as preparatory step
before the introduction of a heavyweight process