Agile UML
Agile development and UML-based development: an apparent
contradiction between lightweight and flexible development
vs. document- and architecture-centric development. We explain how
these may be reconciled using Ideogramic UML™.
Agile Development
Ever since Frederick Brooks' seminal work on software development
methods in "The Mythical Man-Month", developers, managers, and
customers have bemoaned that software projects slip schedule, get
cancelled, or don't deliver the product needed by customers.
Too little focus on customer involvement and inability to handle
complex and changing requirements are major sources of project
failure. The agile development movement tries to address just this for
small to medium size projects. At the forefront of this movement, the
"Agile Alliance" [1] states as its guiding
principles:
- Individuals and interactions over processes and tools. The
focus is on developers and customers and their collaboration. Process
and tools should support actual work: getting software produced and
develivered with the maximum possible combined speed and quality.
- Working software over comprehensive documentation. Software
is the means to and the end of development: to produce and deliver,
writing software is the essential activity. Even though documentation,
or at least documenting ongoing development, is necessary, it should
not be in focus.
- Customer collaboration over contract negotiation. Working
closely with customers is better than specifications or strict
requirements resulting from lengthy negotiations: designs and
implementations can be constantly steered and corrected if, or when,
necessary.
- Responding to change over following a plan. Strict planning
is often impossible in complex system development projects. The first
way to answer to this is to plan even more and stricter in the face of
change. The second, and better, way to answer to this is to accept
change and develop according to this.
So how can you follow this manifesto? The following table gives an
overview of a set of important methods related to agile development:
| Method |
Summary |
Ref. |
Extreme Programming (XP) |
Based on a set of four values -- communication, simplicity,
feedback, and courage -- Extreme Programming defines a set of
practices to be followed strictly throughout development. The focus
is, as the name betrays, on programming but the customer of the
developed product is central in that she is an integral part of the
development team at all times.
|
[2] |
Crystal |
Since every development project is unique and thus need a unique
method, Crystal collects a family of methods that can be parametrized
according to this uniqueness. Communication and frequent releases are
stressed to create qualitive work products without the need for
extensive intermediate products. Recently merged with the "Adaptive
Software Development" method.
|
[3] |
Dynamic System Development Method (DSDM) |
As a pioneering Rapid Application Development (RAD) process,
DSDM fixes resources and time in a development project and varies
functionality according to the current context of the project. Team
empowerment, frequent develivery, and active customer involvement are
keywords of DSDM.
|
[4] |
Agile Modeling |
Agile Modeling stresses modeling throughout the development
process by focussing on effective and lightweight modeling
techniques. It should be seen as a supplement to other development
process rather than as a fullfledged development process itself.
|
[5] |
UML Modeling
The Unified Modeling Language (UML) is the industry standard for representing
object-oriented designs graphically. Class diagrams can be used to
documents designs of object, classes, and their
relationships. Statechart diagrams can document the state changes of
an object. Sequence diagrams can document the interaction between
several objects. Use case diagrams can express use cases graphically:
|
|
|
A class diagram
|
A statechart diagram
|
|
|
|
A sequence diagram
|
A usecase diagram
|
And there's more: nine diagram types all in all adds to the
complexity of the UML. Also, behind the scenes, the UML "metamodel" [6] that defines the UML formally, contains more than
100 classes.
The UML is inherently process-independent: it only defines a way to
actually represent the designs use come up with. But that is the
theory anyway: if you want to use the UML it prescribes the use of a
certain level of formality defined by the standard: classes need to be
on a class diagram, have certain diagrammatic characteristics, and to
fulfill a number of "well-formedness" requirements described in the
UML standard. Moreover, it necessarily mandates the use of UML itself
somewhere in the process...
So how does this compare to the principles of agile development?
Not very well, it would seem:
- Individuals and interactions over processes and tools? In
the sense that the UML defines a way of communicating designs between
developers without misunderstanding and without dictating how you do
it, the UML agrees with this principle. But as argued, the UML is only
process-free in theory, and to get the full benefit of the complexity
of the UML, you will need a powerful tool -- or so it seems.
- Working software over comprehensive documentation? The UML
and working software are separate worlds: a UML diagram will work
equally well even if it doesn't describe a working system. Many of the
constructs in the UML don't have a corresponding construct in
programming languages either -- and vice versa.
- Customer collaboration over contract negotiation? Customer
collaboration tends to be inhibited by using the UML because of its
sheer volume and it high complexity. Moreover, it is tightly bound to
object-oriented programming language constructs, few of which are
readily understandable by neither customers in specific nor
non-development stakeholders in general.
- Responding to change over following a plan? UML documents
may add a level of overhead to running software by demanding constants
synchronization if one of the two changes. On the other hand, having a
well-documented and well-designed running system may enhance the
chances of being able to rapidly responding to change.
Ideogramic UML™: Agile Development and UML Revisited
So how compatible is Ideogramic UML™'s
gesture-based modeling with agile development?
- Individuals and interactions over processes and tools?
Ideogramic focusses on supporting the actual work practices of
object-oriented software developers as they are through
Ideogramic UML™: the starting point is the observation that developers
collaborate and that they collaborate pervasively using desktop
computers, paper, and whiteboards. The gesture-recognition technology
and intuitive design of Ideogramic UML™ enables developers to focus on
their work instead of the technology in the situations they like.
- Working software over comprehensive documentation?
Ideogramic UML™ focusses on providing the right tools for the job:
intuitive modeling, powerful reverse engineering, and extensive tool
integration. Combined, these enable the developer to focus on working
software while having the ability to create comprehensive
documentation.
- Customer collaboration over contract negotiation?
Ideogramic UML™ combines the formal UML with both more flexible
constructs and even freeform constructs to allow collaboration between
experienced UML developers, inexperienced developers, non-developers,
and more.
- Responding to change over following a plan? Ideogramic UML™
is ready-at-hand at the place you need it and when you need
it. Creating the UML designs that can respond to change is up to the
developer!
All in all, Ideogramic UML™ is quite compatible with agile
development and UML-based development.
Online Resources
[1] The Agile
Alliance. Signed by a number of prominent members of the agile
community, the Agile Alliance homepage contains a manifesto dedicated
to agile software development.
[2] Extreme Programming: A
Gentle Introduction. In its own word "a gentle introduction" to
XP. Start here and find more information on this comprehensive
site.
[3] Crystal Main Foyer. The
portal for all things Crystal., Now also with material from the
Adaptive Software Development method.
[4] DSDM
Consortium. The consortium offers information on DSDM, training,
and for members an extensive source of documentation for system
development.
[5] The Agile
Modeling Homepage. Scott W. Ambler's site offers a number of
valuable principles and practices originally adapted from XP.
[6] OMG UML 1.4
Specification. For UML theorist and tool implementers the
specification is a must. But only necessary to read if you want to
really understand the UML in depth!
|
|
Agile
"having a quick, resourceful, and adaptable character"
Ideogramic supports:
|
