Monday, October 09, 2006

Agile Model Driven Development (AMDD)


AMDD is the agile version of Model Driven Development (MDD). The MDD approach to software development is where extensive models are created before any coding happens. The difference with AMDD is instead of creating extensive models before coding, you instead create agile models which are just barely good enough.

Initial Modelling

The initial modelling effort is typically performed during the first week of a project. This task may vary from a few hours to a couple of weeks depending on the size of your project
For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release. The goal is to get a good feel of what the project is all about.

For your initial requirements model you will need some form of:

Usage model
As the name implies usage models enable you to explore how users will work with your system. This may be a collection of essential use cases on a Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project.

Initial domain model
A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model. This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities. Your model doesn’t need to be complete. It just needs to cover enough information to make you comfortable with the primary domain concepts.

User interface model
For user interface intensive projects you should consider developing some screen sketches or even a user interface prototype.

The goal of the initial architecture modelling effort is to try to identify an architecture that has a good chance of working. On the architecture side of things it is recommend to create:

Free-form diagrams
I’ve found that 99% of the time we simply need to create some free-form diagrams on a whiteboard to explore how we think we’ll build the system. It’s important to remember that you will still need to prove that the architecture works through code.

Change cases
An optional, and very interesting technique, at this point is to identify change cases which are potential architecture-level requirements which your system may need to support. Change cases allow you to test the long-term viability of your architecture without requiring you to overbuild your system because you can think through the impact of likely changes to ensure yourself that your system will still work.

Model Storming

The vast majority of modelling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These sessions are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (it’s rare to model storm for more than thirty minutes). The people get together, gather around a shared modelling tool and explore the issue until they're satisfied that they understand it.

Model storming is just in time (JIT) modelling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before.

You will model storm to analyse requirements. For example, a user may tell you that the system you’re building must display a chart representing the bonus schedule for sales people. Together you create a sketch of what the screen will look like, drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this are inclusive models because you’re using simple tools and modelling techniques, this enabling the Agile Modelling (AM) practice of Active Stakeholder Participation.


Implementation is where your team will spend the majority of its time. During development it is quite common to model storm for several minutes and then code, following common coding practices such as Test-Driven Development (TDD) or refactoring (which is a part of TDD), for several hours and even several days at a time. Why does this work? Because your model storming efforts enable you to think through larger, cross-entity issues whereas with TDD you think through very focused issues typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to ensure that your work remains of high quality.

How is AMDD Different?

From a design point of view the AMDD approach is very different than traditional development approaches where you create a design model first then code from it. With AMDD you do a little bit of modelling and then a lot of coding, iterating back when you need to. Your design efforts are now spread out between your modelling and coding activities, with the majority of design being done as part of your implementation efforts.

Why Does This Work?

AMDD works for several reasons:

You can still meet your "project planning needs"
By identifying the high-level requirements early, and by identifying a potential architecture early, you have enough information to produce an initial cost estimate and schedule.

You manage technical risk
Your initial architecture modelling efforts enable you to identify the major areas of technical risk early in the project without taking on the risk of over modelling your system.

You minimize wastage
A JIT approach to modelling enables you to focus on just the aspects of the system that you're actually going to build.

You ask better questions
The longer you wait to model storm a requirement, the more knowledge you'll have regarding the domain and therefore you'll be able to ask more intelligent questions.

Stakeholders give better answers
Similarly, your stakeholders will have a better understanding of the system that you're building because you'll have delivered working software on a regular basis and thereby provided them with concrete feedback.

Approaches to AMDD

There are three basic approaches to applying AMDD on a project:

Simple tools, such as whiteboards and paper, and inclusive models are used for modelling.

Design Tool
Inclusive models are used to explore requirements with stakeholders, and to analyse those requirements. Developers then use sophisticated modelling tool for detailed design, (re)generating source code from the models.

Agile MDA
Very sophisticated, MDA-based modelling tools used to create extensive models from which working software is generated.


Post a Comment

<< Home