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.

Model Driven Prototyping


Published on

Shows a model-driven approach for building prototypes focused on domain models.

Presented at the Vancouver Island Java User Group in September 2009.

Published in: Technology
  • Login to see the comments

Model Driven Prototyping

  1. 1. Model-driven prototyping Rafael Chaves
  2. 2. Sample application: Business Expense Reporting Tracking and reporting of business-related expenses incurred by employees An employee records expenses and submits them for approval Expense processing dept approves and reimburses the employee, or returns for review (with a comment)
  3. 3. Sample application: Business Expense Reporting Expenses are classified by one and only one category (food, transportation, lodging, etc) Must be able to filter expenses by period Must be able to filter expenses by category
  4. 4. Proposed design
  5. 5. Check-point Does this design satisfy the requirements? Do we understand all the requirements? Does the customer ? How can we be confident about that?
  6. 6. How to validate? Traditional options: peer review stakeholders review what else? Not everybody can read UML (or ERD), let alone validate Often those who can read models don't understand the requirements, and vice versa
  7. 7. What if we still miss something? Gaps in requirements are costly to address (design < construction < testing << acceptance <<< production) Study: 60% of errors from requirements phase, 15% of errors caught in that phase Longer specification documents or more diagrams won't help. Is there a better way of doing this?
  8. 8. Prototype it! We must be able to play with the design . And so should all stakeholders. A prototype shows a design taking life All stakeholders can understand it
  9. 9. Throw it away or start from it? Throwaway prototypes are for gathering requirements / feedback Evolutionary prototypes allow completing parts of the system incrementally Different goals: refining requirements vs. strategy for construction Throwaway prototypes typically do not prove something is viable/practical
  10. 10. Effective prototyping Not only cheaper, a prototype must be orders of magnitude cheaper than the real thing Prototypes must be quick to build Focus on what we need feedback now, ignore the rest. What should we focus on? Typically, that would be...
  11. 11. The domain model is king Most bang for the buck: mistakes in the domain model percolate throughout the application Only true for rich domain models - anemic domain models are worth very little Covers most functional requirements in a typical application How can users play with the domain model without a UI?
  12. 12. Model-driven prototyping UI automatically generated from the domain model (cheap/quick) Allows validating structural and behavioural aspects Domain models for MDP are quick and cheap to build (can ignore all other concerns) Not for validation of the UI.
  13. 13. Helps with the solution too Forces you to conceive the domain model upfront Leads to a rich domain model Results in a solid map for construction Brings design close to requirement analysis Greatly reduces gaps encountered beyond design
  14. 14. Some tools for Model-driven Prototyping Naked Objects (domain-driven prototyping ) Scaffolding (Rails/Grails) and...
  15. 15.
  16. 16. Model-driven prototyping Rafael Chaves