What is Agile Modeling? - UML

Experienced analysts and modelers know the secret of modelinlg:

the purpose of modeling (sketching UML, ...) is primarily to understand, not to document.

That is, the very act of modeling can and should provide a way to better understand the problem or solution space. From this viewpoint, the purpose of "doing UML" (which should really mean "doing OOA / D") is not for a designer to create many detailed UML diagrams that are handed off to a programmer (which is a very un - agile and waterfall - oriented mindset), but rather to quickly explore (more quickly than with code) alternatives and the path to a good 00 design.

This view, consistent with agile methods, has been called agile modeling in the book (amazingly called) Agile Modeling [Ambler 02]. It implies a number of practices and values, including:

  • Adopting an agile method does not mean avoiding any modeling; that's a misunderstanding. Many agile methods, such as Feature - Driven Development, DSDM, and Scrum, normally include significant modeling sessions. Even the XP founders, from perhaps the most well - known agile method with the least emphasis on modeling, endorsed agile modeling as described by Ambler - and practiced by many modelers over the years.

  • The purpose of modeling and models is primarily to support understanding and communication, not documentation.

  • Don't model or apply the UML to all or most of the software design. Defer simple or straightforward design problems until programming - solve them while programming and testing. Model and apply the UML for the smaller percentage of unusual, difficult, tricky parts of the design space.

  • Use the simplest tool possible. Prefer "low energy" creativity - enhancing simple tools that support rapid input and change. Also, choose tools that support large visual spaces. For example, prefer sketching UML on whiteboards, and capturing the diagrams with a digital camera.

    1. This doesn't mean UML CASE tools or word processors can't be used or have no value, but especially for the creative work of discovery, sketching on whiteboards supports quick creative flow and change. The key rule is ease and agility, whatever the technology.

  • Don't model alone, model in pairs (or triads) at the whiteboard, in the awareness that the purpose of modeling is to discover, understand, and share that understanding. Rotate the pen sketching across the members so that all participate.

  • Create models in parallel. For example, on one whiteboard start sketching a dynamic - view UML interaction diagram, and on another whiteboard, start sketching the complementary static - view UML class diagram. Develop the two models (two views) together, switching back and forth.

  • Use "good enough" simple notation while sketching with a pen on whiteboards. Exact UML details aren't important, as long as the modelers understand each other. Stick to simple, frequently used UML elements.

  • Know that all models will be inaccurate, and the final code or design different sometimes dramatically different than the model. Only tested code demonstrates the true design; all prior diagrams are incomplete hints, best treated lightly as throw - away explorations.

  • Developers themselves should do the 00 design modeling, for themselves, not to create diagrams that are given to other programmers to implement an example of un - agile waterfall - oriented practices.

Agile Modeling in this Book: Why the Snapshots of UML Sketches?

UML - sketch modeling on whiteboards is a practice I and many developers have enthusiastically coached and practiced for years. Yet most of the UML diagrams in this book give the impression I don't work that way, because they've been drawn neatly with a tool, for readability. To balance that impression the book occasionally includes digital snapshot pictures of whiteboard UML sketches. It sacrifices legibility but reminds that agile modeling is useful and is the actual practice behind the case studies.

For example, Figure is an unedited UML sketch created on a project I was coaching. It took about 20 minutes to draw, with four developers standing around. We needed to understand the inter - system collaboration. The act of drawing it together provided a context to contribute unique insights and reach shared understanding. This captures the feel of how agile modelers apply the UML.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics