News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Tools That Work Against You




February 15, 2005 — 
The tools you use control the way you work, but some tools work against you. A bad tool encourages you to work counterproductively. Unfortunately, every OO-Design/UML-case tool that I’ve ever used falls into the you’re-better-off-without-it category.

This thought was triggered by the newly released MagicDraw 9.0 from No Magic. MagicDraw actually compares favorably to most of the competition. Nonetheless, none of these tools—including MagicDraw—help with the OO process enough to justify their cost. My comments apply to all the OO CASE tools I’ve looked at, not just MagicDraw.

Let’s start with the features. Many CASE-tool features are so poorly conceived that you wonder whether anyone at the company actually does OO Design. Consider the “design-pattern library,” which lets you paste the static structure of one of the examples in the Gang-of-Four (GoF) book into your diagram.

Patterns don’t work that way, however. The static structure of a given pattern varies considerably from program to program. The example in the GoF is just one possibility. Moreover, a single class can simultaneously participate in half a dozen (or more) patterns; you can’t “paste” a pattern structure in isolation because some of that structure may already exist.

“Round-trip engineering” is another flawed mechanism. It’s useful to import an existing piece of legacy code into a CASE tool so that you can see its structure. The resulting picture is not a design, though. In round-trip engineering, the tool generates some small percentage of the code for you. You then hack up this generated code, and at some future date, reimport it into the tool, which reconstructs some (though not all) of the diagrams that constitute the design. What you’ve really done is thrown away your design and replaced it with a picture of hacked-up code.

The reverse-engineering process also fails miserably with the dynamic model. UML “interaction diagrams” show you how a set of objects interact at runtime when modeling some scenario of some use case. The messages on a diagram are limited to those messages that are relevant to that scenario. MagicDraw imports the entire method into the diagram, so the use cases are all jumbled together into a single diagram. The resulting picture is nothing but a UML version of a flow chart.

A good tool must also transparently reflect your workflow. Most experienced designers understand that the dynamic model (the objects and messages they send) tends to drive the design process. Most of the class diagram, for example, can be inferred from the interaction diagrams.

If one object sends a message to another, there’s a relationship between the associated classes and an operation in the receiving class. If a message isn’t used in the dynamic model, it has no business on the class diagram. A good tool should automatically add operations to classes when you add the message to an interaction diagram, and the process should be automatic. No dialog boxes, no dragging and dropping—the new message should just appear in the class box.

Similarly, a good tool should do the equivalent of compiler syntax checking, flagging unused messages as errors, for example. Working from the dynamic model in MagicDraw, however, is like having a root canal. It takes two dialog boxes and way too many mouse clicks to get a new message to appear in the static model. Some tools do a better job of keeping the static and dynamic models in sync, but no tool that I know of checks the design for internal consistency. By making this process difficult, the tool is subtly forcing me to work in an incorrect static-model-drives-the-process way.

The final (and fatal) flaw in these tools is exactly the dialog-box hell I just described. A UML diagram is first and foremost a diagram. Any tool that’s harder to use than a pencil and paper is seriously flawed. I want to add a label to the end of a line by putting the cursor where I want it, clicking and typing the label. I want to type “role:class” in a sequence diagram and the tool should figure out that this is an object named “role,” which is an instance of the specified class.

I never want to obscure the diagram with complicated dialog boxes, full or drop-down menus and abstruse icons that force me to manually tell the tool something that it should be able to infer. Any inexpensive drawing program does a better job than the megabuck CASE tools in this department.

So, for now, I’m back to pencil, paper and a simple drawing program. I still want these tools to work for me, but I won’t be happy until I can use a tool to put a design together in less time than it would take to do the same thing on a whiteboard.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28426
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading