So how do you select CASE tools in an agile manner? You could fall back on the principles and practices of Agile Modeling (AM). The principle "Develop With a Purpose" tells you that you should know why you are creating an artifact. Knowing the purpose for an artifact indicates the extent of the work that you need to perform to complete your model: You stop as soon as your model fulfills its purpose, which, in turn, provides insight into what you require of your tools. By knowing your actual requirements you can determine whether a given tool will actually provide the most value for your situation. My experience is that a "gut-feel" approach to choosing your tools is often the most effective approach, albeit one that senior management may not trust. The principle "Know Your Tools" tells you that you should know the features of the tools that you are using, and the practice "Simple Tools" (See Simple modeling tools) tells you to select the most simple tool (even if it's a CASE tool) that will do the job.

Consider some examples:

1. You are modeling simply to explore the potential structure of several Java classes
   You clearly need a tool that supports class diagramming and perhaps the generation of Java code. My two best options would likely be a whiteboard (I would sketch the classes then proceed to write code) or Together/J (I would use the tool to diagram the classes then generate the code from the diagram). My deciding factor would be how well I know Together/J and how likely it is that I would need to work with the tool in the future. If I know the tool well or if I am likely to be doing enough Java development in the future to warrant my learning the tool, then Together/J would be a good choice for me: One of Together/J's primary strengths is its support for Java developers.
2. You are developing the table structure for a database
   Yes, you could choose to sketch the schema on a whiteboard and then start coding the data definition language (DDL) code to create those tables and the procedural code for any triggers, but that's a lot of work. Several CASE tools exist -- Computer Associate's ERWin is one -- that support the ability to generate the DDL and triggers automatically from a data model. Once again, the deciding factors are skill with the tool and whether it is worth the investment to learn the tool.
3. Your organization has won a bid to identify and document the requirements for a system, with the hope that you will win the next stage of the project (the development itself)
   Ignoring the dysfunctional aspects of the serial nature of this project, the reality is that many projects -- particularly those for the U.S. Federal Government -- work this way. In this situation I would be tempted to use a variety of tools -- a word processor for textual information, a tool that supports creation of use case diagrams (Visio, PowerPoint, Rational Rose), and perhaps even a tool to manage the requirements (Requisite Pro or DOORS).

Next week we will turn our attention to evaluating another type of development tool -- the EJB application server.

Resources

• Agile Modeling (AM) Home Page.
  
  
• The Object Primer 2nd Edition , by Ambler, S.W. New York: Cambridge University Press, (2001).
  
  
• CETUS Links OOA&D Tool Links.
  
  
• CASE modeling tool vendors
  • Together/J
  • Rational Rose
  • ERWin
  • Microsoft Visio
  
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments