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.

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

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

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)

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

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

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

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. www.aanpo.org

Models, Models, Models Models Sketch Blueprint Executable

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

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

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

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.

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

Thank you Questions?