Defining the Same Thing Twice






Defining the Same Thing Twice

The users you talk to have their own language and UML diagrams help you understand that language. But as you carefully build class diagrams that define the terminology of your users, the unthinkable happens (in fact, rather frequently): Two users use different words to mean the same thing. For example, in the insurance world hazard and peril can mean the same thing. We asked one user the meaning of hazard and were told, “When a hazard occurs, we must pay an insurance claim if the policy handles that hazard.” Another user told me, “A peril is a description of an incident for which we write coverage.” We used UML to model the meaning of hazard, peril, insurance policy, claim, and coverage. As this model matured, The Hazard and Peril classes had almost identical attributes, operations, and associations with the Policy and Coverage classes. After we discussed the meaning of hazard and peril with both users, they agreed the two words meant the same thing.

 Tip   Look through your diagrams to find classes with similar attributes, operations, and associations. If you find a couple of similar classes, question your users and the other developers. Ask for examples of these similar classes from your users. If they turn out to be the same, you should choose a single name for the class and stick with it. (You might use the other name for some other purpose—say, as a role name on an association or the name of a common superclass.)



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows