This series of articles is not just about revisiting the UML basics. It also will discuss best practices. (Go to “Useful UML Modeling: The Goldilocks Conundrum” to read part 1 and see our editor’s note about the series.) And where there are best practices there are also worst practices. In the software development industry, when bad practices become a common pattern of behavior they can attain “anti-pattern” status. In this article, I’d like to introduce you to the “I Did It My Way” anti-pattern (with all due deference to Frank Sinatra). [login]A recent online discussion inspired me to name this anti-pattern, because I have seen this anti-pattern repeatedly over the years. In this discussion, a contributor was showing how she used a certain UML element. Unfortunately, because of the semantics of the element, her use would not really mean what she thought it would mean. A couple of people pointed out that the meaning would be incorrect (even pointing to the specifics in the UML specification). The lady dismissed that problem and still defended doing things “her way.” This even inspired another person to say that he didn’t really care about the semantics because he focused on analysis and was not worried about any implications later in the development lifecycle. Both people were just fine with using UML symbols that have a standard meaning (the UML is a standard of the Object Management Group) and redefining them “their way.”This reminded me of when I was called in to do a post mortem on a project that had experienced many problems during development. The models I reviewed were replete with errors. When I spoke with the project manager he explained that I just didn’t understand. He said that he had “refined” the modeling notation. And just like in the recent online discussion, he changed the meaning of the symbols. When I asked why he did that, his answer was he liked it better “his way.” Unfortunately, when I interviewed the other team members who had to consume these models, they were tremendously frustrated with what the PM had done and could not understand the models. How could they be expected to implement correctly models that they could not understand?The creators of the UML understood that the UML could not be all things to all people. In anticipation of this, the UML was designed with mechanisms to adapt the UML to suit your project’s needs. You can create “stereotypes” (stereotypes allow you to extend a UML element). A typical example would be where you create a new stereotype named Sensor based on a standard UML class. You then define a Sensor by specifying that all Sensors have two default attributes: UpperLimit and LowerLimit. Therefore, whenever you use a Sensor in your models, you will always get those two attributes also. In this way, you have created an extended class (Sensor) that has additional attributes, but it is still a class. You have not changed the meaning of class.You can even package such changes into a “profile” (profiles are packaging constructs for UML extensions) to make it easier to share such customizations with your team members. Profiles can be used to define company standard modeling elements for your particular business domain, projects, or for specific development platforms. These are the mechanisms to extend the UML for your needs while still keeping your new elements valid within the UML.When people take a short cut by committing the I Did It My Way anti-pattern and casually change the meaning of the UML, they are not being “effective”. It simply causes confusion. As an electrical engineer if I draw a schematic diagram and change the meaning of a resistor symbol to that of a capacitor, not only would the circuit be fabricated incorrectly by the person who builds it, but the circuit would likely fail, possibly catastrophically. As a musician, if I write a song, but change the meaning of the musical notes, the result would likely be unpleasant when the song was played by others. Figure 1. One example of what can happen when you don’t clearly communicate. The most important benefit we get by using the UML is the ability to clearly communicate with a standard language. The ability to collaborate, to exchange designs, to clearly understand what is needed by the stakeholders, and what the intended solution is requires the ability to communicate. Many studies of why software projects fail cite reasons that often center on poor communication and lack of understanding: the analyst misinterprets the customer’s needs, the project manager misunderstands the architect, the test team is confused by the developers. At best, this results in waste and rework; at worst excessive defects and project failure.Using a common language is about facilitating the team. What drives people to do it “My Way”? Lack of understanding? Ego? Short-cutting to supposedly save time? Some or all of the above? Hard to say. But I am a pragmatist, not a UML theorist. I know the UML has it weaknesses. But that is not sufficient justification for rewriting its meaning arbitrarily. If you have a special need, use the extension capabilities that were created for that purpose. In that way, it is more likely you will create something that others will understand. And that’s what it’s really all about — creating understanding, not creating the next Tower of Babel.