Agile models are sufficiently consistent
An agile model does not need to be perfectly consistent with itself or with other artifacts to be useful. If a use case clearly invokes another in one of its steps, then it should be included in the corresponding use-case diagram with an association between the two use cases that is tagged with the UML stereotype of <<Include>>. However, you look at the diagram and it doesn't! Oh no, the use case and the diagram are inconsistent! Danger Will Robinson, Danger! Red alert! Run for your lives!

Wait a minute. Your use-case model is clearly inconsistent, yet the world hasn't come to an end. Yes, in an ideal world all of your artifacts would be perfectly consistent. But it often doesn't work out that way.

When I'm building a simple business application, I can tolerate some inconsistencies. Granted, there are times I can't tolerate inconsistencies -- witness NASA's recent learning experience regarding the metric and imperial measuring systems when it accidentally slammed a space probe into Mars in 1999. The point to be made here is that an agile model is consistent enough and no more. Mars notwithstanding, models very often do not need to be perfect in order to be useful.

Regarding accuracy and consistency there is an entropy issue to consider as well. If you have an artifact that you wish to maintain, what I call a "keeper," then you will need to invest the resources to update it as time goes on. Otherwise it will quickly become out of date and effectively useless to you. For example, I can tolerate a map that is missing one or two streets, but I can't tolerate one that is missing three quarters of the streets in my town. There is a fine line between investing just enough effort to keep your artifacts accurate enough, investing so much effort that you are needlessly slowing your project efforts down, and not investing enough to keep your artifacts useful to you.

Agile models are sufficiently detailed
A roadmap doesn't indicate each individual house on each street -- that would be too much detail, and would make the map difficult to work with. However, when a street is being built I would imagine the builder has a detailed map of the street that shows each building, the sewers, electrical boxes, and so on, in enough detail that it makes the map useful to him. This map doesn't depict the individual patio stones that make up the walkway to each house -- once again, that would be too much detail. Sufficient detail depends on the audience and the purpose for which they are using a model: drivers need maps that show streets, builders need maps that show civil engineering details.

Consider an architecture model. Depending on the nature of your environment, a couple of diagrams drawn on a whiteboard that are updated as the project goes along may be sufficient. Or perhaps several diagrams drawn using a CASE tool are what you need. Or perhaps the same diagrams supported with detailed documentation are required -- different projects have different needs. In each of these examples, you are in fact developing and maintaining a sufficiently detailed architecture model -- it's just that "sufficiently detailed" depends on the situation.

Agile models provide positive value
A fundamental aspect of any project artifact is that it should add positive value. Does the benefit that an architecture model brings to your project outweigh the costs of developing and (optionally) maintaining it? An architecture model helps to solidify the vision towards which your project team is working; this clearly has value. But, if the costs of that model outweigh the benefits, then it no longer provides positive value. It is probably unwise to invest $100,000 developing a detailed and heavily documented architecture model when a $5,000 investment resulting in whiteboard diagrams would do the job.

Agile models are as simple as possible
You should strive to keep your models as simple as possible while still getting the job done. Simplicity is clearly affected by the level of detail in your models, but it also can be affected by the extent of the notation that you apply. For example, UML class diagrams can include a myriad of symbols, including Object Constraint Language (OCL) -- yet most diagrams can get by with just a portion of the notation. You often don't need to apply all the symbols available to you so limit yourself to a subset of the notation that still allows you to get the job done.

Resources

• Agile Modeling (AM) Home Page
  
  
• Agile Software Development Manifesto
  
  
• The Object Primer 2nd Edition , by Ambler, S.W. New York: Cambridge University Press, (2001).
  
  
• eXtreme Programming (XP) Home Page
  
  
• Process Patterns resource page
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments

Next steps from IBM

With Rational Software Modeler you can increase productivity by dragging and dropping your way to a visual interpretation of your UML design.

---

• Try: Download a free trial version of Rational Software Modeler, a UML 2.0-based visual modeling and design tool for architects, systems analysts, and designers.
• Article: Learn what UML limitations are and how you can overcome them with Rational Software Modeler.
• Tutorial: This tutoral provides a tour of Rational Software Modeler's Visual UML modeling tools.
• Demo: This demo guides you through the creation of a UML modeling with Rational Software Modeler.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers