Model-driven prototyping
Rafael Chaves
rafael@abstratt.com

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)

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

Proposed design

Check-point
Does this design satisfy the requirements?
Do we understand all the requirements?
Does the customer ?
How can we be confident about that?

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

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?

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

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

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...

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?

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.

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

Some tools for Model-driven
Prototyping
Naked Objects (domain-driven prototyping )
Scaffolding (Rails/Grails)
and...

http://alphasimple.com

Model-driven prototyping
Rafael Chaves
rafael@abstratt.com