The Unified Modeling Language (UML) is a drawing notation standard, not a methodology. In terms of the standard methodology framework (roles, techniques, standards, milestones, etc.), it is one of the standards for one or two of the roles.
It is a component of a methodology, but not likely to be a very large factor in the project's outcome.The UML standard does not make prescriptions or even recommendations about when, where, and how much you draw.
With respect to the standard, you can draw out the entire design before starting to program, or you can "think a little, draw a little, code a little," a strategy long recommended by object technology experts and supported by Scott Ambler's (2002) book, Agile Modeling.
Discussion of drawing models quickly gets caught up in discussion of architecture and how much design to do when. You will not be surprised to learn that my view is that different people have different preferences and like to think about designs for different amounts of time before starting to program.
Having said that, it is also my view that a design is a "theory," which desperately needs a matching "experiment" to validate it, or, more importantly, reveal its weaknesses. Usually, the design doesn't survive its first encounter with real code. This means that the sooner the design gets tested in implementation, the sooner the designer learns where and how it needs improvement.
Some people have a very short thinking time horizon before they desperately feel the need for an experiment: on the order of five or ten minutes. Others have a medium time horizon, on the order of several hours or a day or two, during which they mentally explore all the pitfalls, weaknesses, and potential change requests they may have to adapt to. Others have quite long thinking time horizons, on the order of a week or two, during which they do the same.
My experience is that when designers spend more than a few weeks working out a (software) design, they usually have passed the optimal trade-off point, where it would have been useful to create an experiment with real code to get some real feedback.
Taking all those together, I feel that most architects take too long before they make their first experiment, but it is not necessary to adopt the view that design can be replaced just by refactoring and attention to XP's "once and only once" rule.
The subjects of UML, drawings, tools, architectural design, and thinking time horizons tend to get confused all together. If you can pull them apart, it frees you up to work in new combinations.
It is, for example, not the case that all drawings are UML drawings nor must architectures be described in UML, or even in drawings, nor must fancy software tools be used to capture either drawings or UML , nor does spending time thinking mean sitting at a tool. Finally, and especially, nor is it the case that sitting in front of a UML drawing tool means that any architectural thinking is going on.
The approach typical on a Agile project is to use the Walking Skeleton and Incremental Re-architecture strategies. An early architecture is sketched, programmed and tested in the first iteration, and completed, extended and evolved over subsequent iterations. UML might or might not be used to think through it and document the result.
References:
- Beck, K. , Extreme Programming Explained: Embrace Change, Addison-Wesley.
-Ambler, S. , Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, John Wiley & Sons.
-Cockburn, A. , Agile Software Development, Addison-Wesley.
No comments:
Post a Comment