1. Agile MDA Stephen J. Mellor
The audience for this preso is people with an interest in UML who wish to learn more about it, but are sceptical. People who know UML inside out would be bored.
The goal is to convince them that there is a strong relationship between code and UML. That relationship may be direct (a one-to-one mapping) or not.
Expressing the mapping is the business of rules. We do not describe the syntax of the rule language.

2. A Brief History of MDD UML 1.1: Three Amigos 1997
UML 2.0: Cast of thousands 2004
Executable UML: Mellor and Balcer 2002
OO Design: Booch 1988
OMT: Rumbaugh et al 1992
Object Lifecycles: Shlaer and Mellor
OOA: Shlaer and Mellor 1988
Structured Design: Yourdon and Constantine 1979
Structured Analysis: De Marco 1981
Structured Devpt/RT: Ward and Mellor 1985

3. Model-Driven Architecture
An OMG initiative to develop standards based on the idea that modeling is a better foundation for developing and maintaining systems
A brand for standards and products that adhere to those standards
A set of technologies and techniques associated with those standards
® OMG

4. The Agile Critique Models are bad (they say), because models:
Don’t run.
Can’t be tested automatically.
Models are bad because they are “documentation” which:
Has no correspondence to the code
Is extra work to build…
…and maintain (or throw away)

5. Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it.
We value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.”

6. What problem is agility meant to solve?
Delayed feedback on requirements
Right solution to the wrong problem
Unsustainable pace
Poor customer relations
Long time-to-market
The Agile movement is a reaction to heavyweight methods that:
- build documents that cannot be tested with the user
- produce the specified solution six months down the road when the problem has changed
- produce poor estimates because cycle times are too long
- rely heroic efforts to produce a working product
- treat the customer as a contractual adversary

7. What solution does agility propose?
Immediate feedback by executing software
Frequent releases with consequent feedback
Timeboxed deliveries
Customer on Site (aka Whole Team on Site)
Incremental delivery of working code
Frequent releases can affect the perception of the problem and help to clarify requirements earlier in the cycle
Deliver fewer features, but do it more frequently.
Given choice between slipping the delivery date for an interim release and removing features, Agile processes favor removal of features.
Having access to the customer and the ability to show him frequent, incremental releases helps clarify requirements.
Delivering working software incrementally and frequently helps to ease customers’ and managers’ fear.
customer
developer

8. Signatories to the Agile Manifesto
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick
Robert C. Martin Stephen Mellor Ken Schwaber Jeff Sutherland Dave Thomas
Robert C. Martin Stephen Mellor Ken Schwaber Jeff Sutherland Dave Thomas
So, which one of these guys does not belong on this list? Steve went to the initial meeting as a spy more than anything else. While he was there he realized that many of the ideas proposed by these people are good ones and can be applied to modeling, and these approaches happened to reflect the way we have always encouraged our customers to build systems anyway.

9. Models, Models, Models
Models
Sketch
Blueprint
Executable

10. Sketches as Models Helpful to get an idea …across
Write code by referring (mentally) to the model
Throw-away/informal

11. Blueprints as Models Intended to direct implementation
Intended for planning
(“predictive”)
Assumption that construction is more costly than design

12. Executable Models Intended to be (a part of) implementation
Intended for verification (“adaptive”)
Assumption that construction is less costly than design

13. A Conversation You’re saying models are bad; code is good. Right!
Because models can’t execute and code can. Right?
Right!
If a model could execute, that would be good. Right?
Right!
But models can execute, so models are good. Right?
No. Models are bad. Code is good.

14. How can modeling be agile?
Immediate feedback by executing models*
Frequent releases with consequent feedback
Timeboxed deliveries
Customer on Site (aka Whole Team on Site)
Incremental delivery of working models
Doesn’t modeling imply heavyweight processes?
Definitely not.
If the models are executable and can be translated into software, then modeling can be agile too.
Why do we want to model, anyway…?
* The Agile Manifesto uses “software,” not “code.”

15. Thank you Questions?