Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Lightweight MDD Process Applied in Small Projects


Published on

Presentation about model driven development for small-mid sized companies

Published in: Software
  • Be the first to comment

  • Be the first to like this

A Lightweight MDD Process Applied in Small Projects

  1. 1. A Lightweight MDD Process Applied in Small Projects Gabor Guta, PhD
  2. 2. Contents Introduction to MDD1 The Process2 Conclusion3
  3. 3. 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. 4. 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. 5. What is MDD? (cont'd)
  6. 6. What is MDD? (cont'd)  The artifacts generating transformations are often called templates  Domain & intermediate models can be described with meta-models
  7. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. The Process  Roles  Artifacts  Activities  Workflow
  14. 14. The Workflow (overview)
  15. 15. 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. 16. 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. 17. 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. 18. 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. 19. Activities (cont'd)  Integration  In: generated artifacts, hand-crafted software  Out: released software  Development  Requirements Refinement  Architectural prototyping  Design  Development
  20. 20. The Workflow (part 1)
  21. 21. The Workflow (part 2)
  22. 22. 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. 23. 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. 24. 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