<$BlogRSDUrl$>

Tuesday, April 27, 2004

UML/OOAD - Fokus
Saya merasakan jawapan Craig Larman dlm thread di javalobby adalah cukup baik utk dipostkan semula kat blog saya. Harapnya tak de masalah dgn ini. Secara umumnya, apa yg dia perkatakan adalah sama spt apa yg ex-mentor OO saya perkatakan lebih 5 tahun lepas dan ia juga seiring dgn apa yg saya sendiri lalui.

Diambil dpd javalobby, jawapan dpd Craig Larman / Taken from javalobby, written by Craig Larman:
...

My answer may surprise you, because, to give a little background, i've had the good fortune that one of my books, "Applying UML and Patterns: An Intro to OOA/D," has been the most popular OOA/D + UML book worldwide since '97, and I've been able to practice or coach developers in OOA/D and visual modeling with Booch or OMT or Fusion or UML notation for almost 20 years.

You may enjoy parts of my recent article "What the UML Is and Isn't" at JavaPro mag:

http://www.ftponline.com/javapro/2004_03/magazine/features/clarman/default_pf.aspx

And the recent article "Death by UML Fever:"

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130

There’s some other related resources at www.craiglarman.com

Martin Fowler and Scott Ambler’s works on this subject are also useful, and in the same spirit as i encourage.

First, the UML is relatively trivial and unimportant.

It is simply a standard diagramming notation of boxes and lines. That doesn't mean that a diagramming language (the UML or any other) is without value—some visual modeling can have great value--BUT, the important thing is knowing how to think and design with objects, not draw in a standardized notation. It's like the difference between the knowledge of how to be an electronics engineer and design/evaluate circuits, vs. the knowledge of how to draw the standard digital elements in a circuit diagram.

UML/MDA tool vendors and purchasers entranced with the unending "silver bullet" desire continue to believe claims of fantastic improvements if we use some UML tool. The essence of Brook's classic "No Silver Bullet" paper is that there is no tool or practice that will create an order of magnitude improvement.

Tools don't compensate for (OO design) ignorance, nor does the UML.

Design education + short iterations + collaboration + good communication practices does.

One of the easiest ways for an organization to waste money is to get the idea "Let's become advanced and 'do UML' now." And then, to buy a set of UML tool licenses, somehow thinking this will make the dramatic difference on their development efforts. Ultimately it leads to the most consistent pattern of "shelfware" i've seen when i visit development groups, and most who go down this road discover that the return on time investment isn't there, and the tools are too weak or fussy (e.g., compared to what you can just do with Eclipse + Xdoclet + Ant ...).

So, what do I suggest?

First is appreciating that the important thing is not UML or 'doing UML' but 'doing OOA/D.' And so focus on education and mentoring related to that: OO design principles and patterns, and how to apply them.

Second is to prefer and emphasize the Agile Modeling (www.agilemodeling.com ) spirit of doing visual modeling with the UML; Scott Ambler has well-captured something fowler, i, and others have been trying to promote for years. For example, (and this is the essence of how i’ve effectively applied uml with teams for many years) do UML sketching with marker pens on giant whiteboard spaces, with every inch of a large common project room covered with whiteboards or whiteboard paint, or Avery Cling-On Write Sheet, no furniture against the walls. Use a digital camera to capture sketches worth preserving for awhile. This is meant to be *visual modeling* the purpose of which is to exploit our human-brain advantages of working in diagramming languages; that should mean vast drawing spaces and real ease of use, so that our “tools” (e.g., a pen) supports creative flow rather than inhibits it (such as working in a tiny computer screen struggling over drawing boxes).

Some other useful related agile modeling practices are to model in pairs (or triplets) at the whiteboard at, and to create 2 models in parallel on different walls (e.g., dynamic interaction diagrams on 1 wall, and complimentary static class diagrams on wall 2, back and forth). Also, drawing uml only needs to be a “good enough” approximation during whiteboard sketches so that the modelers understand each other. Knowing fine details and many obscure uml notational points isn’t important.

Third, avoid the waterfall or “big-modeling” attitudes. For example, do no more than one day of uml-ish and related modeling at the start of each 2 or 3-week timeboxed iteration. Don’t view these models are accurate or complete designs, but creative explorations for the difficult, non-obvious parts of the design. Don’t attempt or believe we can create a “complete” or correct model; do just enough to add some value for the current short iteration, bounding the modeling work to the few requirements under design for this iteration.

Fourth, related to the third, view these uml-ish sketches as rough drafts and created for understanding, exploration, and communication with your design partner, NOT as documentation or an accurate spec.

Fifth, don’t encourage that some “expert” create detailed uml diagrams then hand them off to another developer for implementation. That’s a very waterfall-ish and un-agile approach to modeling. Effective uml-ish/visual modeling is done by programmers, for themselves.

Sixth, UML tools can have some value, but most find, in the long run, that the consistent value is for reverse-engineering existing code into diagrams, to get a quick big picture visual view onto the code base. When i coached a dev team through an iteration, we try to rev eng the code to UML, and then print out the interesting diagrams in large on plotter paper, and hang on the walls, before the 1-day modeling session that starts an iteration. Then, we can look at and sketch on top of the plotter drawings as we explore. From this practice, a team needs only one copy of a tool per team. And pick a rev-eng tool that can rev-eng code to sequence diagrams (not just the static class diagrams); that’s a very useful learning aid to quickly see call-flow structures in the code, but very few can do it.

Related to the above, i find more value in code generation using the code-oriented tools, rather than a uml tool for forward engineering (generating code from diagrams). Eclipse + xdoclet + Ant + … will take you very far, are free, and many developers know and can maintain with these tools.

Note that one key disadvantage with uml sw tools isn’t inherently the tool, but that today’s display technology is not suitable for visual modeling, which is much better done (given human physiology) in massive 2-meter by 30-meter areas with very easy I/O methods, to support real creative flow. Today that means whiteboards and pens and cameras, but someday equal ease and value is sure to come from new computer technologies (e.g., VR uml-ish sketching areas).

I have many years of good memories of creative, valuable and fun collaboration at the whiteboards, uml/booch/… quickly sketching and discussing various design strategies for OO software projects, and know that this agile visual modeling approach, as a short step before programming each iteration, can yield great value when we’re comfortable with the language and practice. But neither i, nor most of the colleagues and clients I know, have such long and positive memories when using a CASE tool – uml oriented or otherwise. i’m sure that will change someday, and i’m also sure that there are exceptions to my observations; that there are _some_ people who derive great benefit from the tools, when it fits on a particular kind of project. My comments are general-trend observations; I’m sure someone on this forum will tell a story of great benefits using tool X.

Although a tool vendor won’t say this, IMHO the real value proposition of applying the UML isn’t using a UML tool, it is the advantage of visual modeling – quickly sketching in pictures rather than just text, as this plays to a strength of humans to comprehend relationships quickly. It supports better collaborative design and alternative explorations. It’s a shame when that simple advantage and practice is lost in the forest of details and awkwardness of computer drawing tools, or low-level uml notation pedantry.

Was that any help? best wishes with modeling; please email me with any questions.

regards, craig

# posted by Hamdi @ 10:09 PM
Comments: Post a Comment

This page is powered by Blogger. Isn't yours?