During the last JAOO conference, a couple of speakers (Eric Evans and James R. Coplien) eventually dropped a quote about UML experts forgetting to use the UML Object Diagram. It might have been a coincidence, but since I sometimes teach UML classes (and I normally tend to get through the Object Diagram quite quickly) this triggered some reflection "Am I doing something wrong?"-style.
It turned out that my slides were right – they were saying something like "this diagram us useful for explanation purposes" – but during classes the pitch tended to switch towards a more documentation-oriented version of UML. Many of the audiences were programmers or designers, interested in reading UML or in using UML tools, so the approach made sense. Still the main message was missing.
UML is a powerful communication tool. By establishing a standard, the three amigos opened the way to standard CASE tools, and a common language between software professionals. But the real point is that UML is a communication tool, and was designed to be flexible, to be used in different contexts. Designing a system in a CASE, or provide a non-ambiguous documentation for the development team, or using UML to generate code from a diagram is just one side of the medal. To design a successful application, requirement gathering and analysis are more crucial. In this phase UML can come in handy, but only as long as the all stakeholders are able to actively participate in the discussion.
Downsizing UML
To be successful in this information crunching phase, it's often better to stick on the minimal amount of UML that can be understood by the participants. People involved in this phase need to be aware of what's happening, and – most of all – creatively contribute to the result. Surprisingly the Object Diagram is one of the easiest to be understood by non software people, while Class Diagram, even simplified, still looks sometimes suspect to some.
Domain Specific Notation
The main goal is sharing the information. Forcing people to learn a simplified version of our language is a type of white-man-between-natives attitude. UML is definitely not "the message" but just a tool. If there's already a language in place, it's probably better to learn this one instead of forcing all the business people to learn UML. If there is no language in place, but UML simply doesn't quite fit the job, we can also define our Domain Specific Notation, if this is more easily understood than UML, and use it for a defined purpose.
Defining to what extent this extra language should be used is heavily dependent on the project context: an offshore development team will probably still prefer UML, because is standard and could have a more formal meaning. An in-house team, meeting the business people on a regular basis could find more efficient to grasp the information from the source in the specific notation.
No comments:
Post a Comment