An agile model (see also Agile Modeling ) is an abstraction that sufficiently describes one or more aspects of a problem, or a potential solution to a problem. An agile model could be something as simple as a sketch on a paper napkin or whiteboard, or something as complex as multilayered, multiviewed, highly documented model built using a CASE tool.

Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation. However, nonvisual artifacts such collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also considered to be models. But how do you know when a model is agile? Agile models are good enough when they exhibit the following traits:

• Agile models fulfil their purpose Sometimes you model to communicate -- perhaps you need to communicate the scope of your effort to senior management; and sometimes you model to understand -- perhaps you need to determine a design strategy to implement a collection of Java classes. For an agile model to be sufficient, it clearly must fulfill the purpose for which it is created.

• Agile models are understandable Agile models are understandable by their intended audience. A requirements model will be written in the language of the business that your users comprehend, whereas a technical-architecture model will likely use technical terms that developers are familiar with. The modeling notation that you use affects understandability: UML use case diagrams are of no value to your users if your users don't understand what the notation represents. In this case, you would either need to use another approach or you would need to educate them in the modeling technique. Style issues, such as avoiding crossing lines, will also affect understandability -- messy diagrams are harder to read than clean ones. The level of detail in your models (see below) can also affect understandability, since a highly detailed model is harder to comprehend than a less detailed one. Simplicity (also discussed below), is similarly a factor that affects understandability (see also Drawing clean UML diagrams ).

• Agile models are sufficiently accurate Models often do not need to be perfectly accurate, they just need to be accurate enough. For example, if a street map is missing a street, or it shows that a street is open but you discover it's closed for repairs, do you throw away your map and start driving wildly through the city? Likely not. You might decide to update your map -- you could pull out a pen and do it yourself. Or you might go to the local store and purchase the latest version (which still might be out of date), or you could simply accept that the map isn't perfect but still use it because it is good enough for your purposes. You can use it to get around because it does accurately model most of the other streets in your town. The reason why you don't jettison your street map the minute your find an inaccuracy is because you don't expect the map to be perfect, nor do you need it to be. Similarly, when you find a problem in your requirements model or in your data model, you would choose to either update the model at that point or accept it as it is -- good enough but not perfect.

The desire to get models perfect is one of the reasons why people fall into the "analysis paralysis" trap -- they're too afraid to move on from modeling because they want to get it right first. I also suspect this is why people invest a lot of time in documentation and maintenance of their models: When something changes they rush back and update that issue throughout the myriad of artifacts they've been maintaining. What I'm getting at is an aspect of eXtreme Programming (XP)'s practice of traveling light. You want to maintain a minimal amount of artifacts that are appropriate for your situation. For an XP project, that minimal amount of artifacts could be source code and your test cases; whereas on a Rational Unified Process (RUP) project it would include these things as well as other artifacts such as requirements and architecture models. At the same time, you want to invest the bare minimum effort in the artifacts that you do maintain. It doesn't make sense to do more work than you need to do, and that means you will update your artifacts within the tolerances of your project. Some project teams can tolerate inaccuracies whereas others can't: the nature of the project, the nature of the individual team members, and the nature of the organization will decide this. Sufficient accuracy depends both on the audience of the model as well as the issues that it's trying to address.

In the next tip in this series I will argue that agile models must also be sufficiently consistent, be sufficiently detailed, provide positive value, and be as simple as possible. In other words, agile models are just good enough to get the job done!

Resources

• Agile Modeling (AM) Home Page
  
  
• The Object Primer 2nd Edition , by Ambler, S.W. New York: Cambridge University Press, (2001).
  
  
• Extreme Programming Explained: Embrace Change , by Beck, K. Reading, MA: Addison Wesley Longman, Inc., (2000).
  
  
• Planning Extreme Programming , by Beck, K. and Fowler, M. Addison Wesley Longman, Inc., (2001).
  
  
• eXtreme Programming (XP) Home 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