Apply Modeling Standards. This practice is renamed from XP's
Coding Standards, the basic idea is
that developers should agree to and follow a common set of modeling standards on a software
initiative. Just like there is value in following common coding conventions, clean code that follows
your chosen coding guidelines is easier to understand and evolve than code that doesn't, there is
similar value in following common modeling conventions. There is a wide variety of common modeling
standards available to you, including the Object Management Group's
Unified Modeling Language (UML) which
defines the notation and semantics for common object-oriented models. The UML provides a good start
but it isn't sufficient -- as you can see in
Be Realistic About The UML not all
possible modeling artifacts are encompassed by the UML. Furthermore, it says nothing about
modeling style guidelines to create clean-looking
diagrams. What is the difference between a style guideline and a standards. WRT to source code, a
standard would be to name attributes in the format attributeName whereas a style guideline is
to indent the code within a control structure (an if statement, a loop, ...) by one unit. WRT to
models, a standard would be to use a square rectangle to model a class on a class diagram and a
style guideline would be to have subclasses placed on diagrams to the south of their superclasses.
Apply Patterns Gently. Effective modelers learn and then appropriately apply common
architectural, design and analysis patterns in their models. However, as Martin Fowler points out in
Is Design Dead? developers
should consider easing into the application of a pattern, to apply it gently. This reflects the
value of simplicity. In other words, if you SUSPECT that a pattern applies you should model it in
such a way as to implement the minimal amount you need today but that makes it easy to refactor it
later when it is clear that applying the full-fledged pattern is in fact the simplest approach
possible. In other words, don't over model. For example, you may recognize a good spot in your
design to apply the GoF's
Strategy pattern, but at the current moment you only have two algorithms to implement. The
simplest approach might be to encapsulate each strategy in its own class and build an operation that
chooses them appropriately and passes them the appropriate input. This is a partial implementation
Strategy that leaves you in a position to refactor your design if more algorithms need to be
implemented, yet does not require you to build all the scaffolding that
Strategy requires -- an approach that enables you to ease into application of the pattern.
Discard Temporary Models. The vast majority of the models that you create are
temporary/working models -- design sketches, low fidelity prototypes, index cards, potential
architecture/design alternatives, and so on -- models that have fulfilled their purpose but no
longer add value now that they have done so. Models quickly become out of sync with the code, and
there is nothing wrong with that. You must then make the decision to synchronize the models if doing
so adds value to your team or to simply discard them because the investment to update the models
won't be recouped by the value of having done so (there's negative payback). This practice is
particularly important for
Formalize Contract Models.
Contract models are often
required when an external group controls an information resource that your system requires, such as
a database, legacy application or information service. A contract model is something that both
parties should mutually agree to and mutually change over time if required. Examples of contract
models include the detailed documentation of an application programming interface (API), a file
layout description, an XML DTD or a physical data model describing a shared database. As with a
legal contract, a contract model often requires you to invest significant resources to develop and
maintain the contract to ensure that it's accurate and sufficiently detailed. Your goal is to
minimize the number of contract models for your system to conform to the XP principle of traveling
light. Note that you will almost always use an electronic tool to develop a contract model because
the model must be maintained over time.
Update Only When It Hurts. You should update a model only when you absolutely need to, when
not having the model updated is more painful than the effort of updating it. With this approach you
discover that you update a smaller number of models than you would have in the past because the
reality is that your models don't have to be perfect to provide value. The street map that I have to
my town is over five years old, I know this because my own street doesn't appear on it and it's been
in place for a little over five years, yet the map is still useful to me. Yes, I could purchase an
updated map, one comes out every year, but why bother? Missing a few streets isn't painful enough to
warrant this investment, it simply doesn't make sense to spend the money to purchase a new map every
year when the one that I have is good enough. Too much time and money is wasted trying to keep
models and documents in sync with source code, an impossible task to begin with, time and money that
could be better spent developing new software. This practice is particularly important for
The following practices are complementary to AM but are not explicitly included as a part of it:
To simplify AM, I chose to remove several practices in January of 2005. Although these are still valid ideas
which are not going away, they won't be considered "first order practices" anymore. I found over the years that
as I training and mentored people in
AMDD that I didn't need to discuss them very much for people to understand the approach. The practices which
I removed are:
||Reason for Removal
||When you are modeling you should be constantly asking yourself "How are we going to test this?" because
if you can't test the software that you are building you shouldn't be building it. Modern software processes
include testing and quality assurance activities throughout the entire lifecycle, and some even
promote the concept of writing tests first before writing software (this is an XP practice).
||Although this is a great idea but when you're taking a TDD approach, which most agilists do, along with
an AMDD approach you find that this practice becomes moot.
|Model To Communicate
||One reason to model is to communicate with people external to your team or to create a contract model.
Because the customers for some models are outside your team, you may need to invest the time to make your
model(s) look "pretty" by using electronic tools such as word processors, drawing packages or even
sophisticated CASE tools.
||This is a great motivator for modeling, but not really a practice, therefore I deprecated it.
|Model To Understand
||The most important application of modeling is to explore the problem space, to identify and analyze the
requirements for the system, or to compare and contrast potential design alternatives to identify the
potentially most simple solution that meets the requirements. Following this practice you often develop
small, simple diagrams that focuses on one aspect of your software, such as the lifecycle of a class or the
flow between screens, diagrams that you often throwaway once you are finished with them.
||I removed this for the same reasons that I removed modeling to communicate.
Reuse Existing Resources
||There is a wealth of information that agile modelers can take advantage from. For example, perhaps some
analysis or design patterns are appropriate for you to apply gently to your system. Or perhaps you can take
advantage of an existing enterprise requirements model, business process models, physical data models or
even models of how systems are currently deployed within your user community. It's true that these models
either don't exist or are out of date in many organizations, although you're often likely to uncover
reasonably accurate models with a bit of research.
||This is a great idea which all developers should practice, but it's a general concept which goes beyond
modeling and documentation.