Section 1.7. UML Rules of Thumb

1.7. UML Rules of Thumb

While UML provides a common language for capturing functionality and design information, it is deliberately open-ended to allow for the flexibility needed to model different domains. There are several rules of thumb to keep in mind when using UML:

Nearly everything in UML is optional

UML provides a language to capture information that varies greatly depending on the domain of the problem. In doing that, there are often parts of UML that either don't apply to your particular problem or may not lend anything to the particular view you are trying to convey. It is important to realize that you don't need to use every part of UML in every model you create. Possibly even more importantly, you don't need to use every allowable symbol for a diagram type in every diagram you create. Show only what helps clarify the message you are trying to convey, and leave off what you don't need. At times there is more than one way to convey the same information; use what is familiar to your audience.

UML models are rarely complete

As a consequence of everything being optional, it is common for a UML model to be missing some details about a system. The trick is to not miss key details that could impact your system design. Knowing what is a key detail versus extraneous information comes with experience; however, using an iterative process and revisiting your model helps to flesh out what needs to be there. As UML moves closer to tool automation with practices like MDA and Software Factories, the models often become more and more detailed and therefore complete. The difference is the tool support that helps vary the level of abstraction depending on your needs.

UML is designed to be open to interpretation

While the UML specification does a good job of laying down the groundwork for a modeling language, it is critical that within an organization or group of users you establish how and when to use a language feature. For example, some organizations use an aggregation relationship to indicate a C++ pointer and a composition relationship to indicate a C++ reference. There is nothing inherently wrong with this distinction, but it's something that isn't going to be immediately obvious to someone not familiar with that organization's modeling technique. It is a good practice to put together a document on modeling guidelines; it helps novice users get up to speed quicker and helps experienced users really think about how they represent something and consider a potentially better notation.

UML is intended to be extended

UML includes several mechanisms to allow customization and refinement of the language. Such mechanisms as adornments, constraints, and stereotypes provide ways to capture specific details that aren't easily expressed using classifiers and relationships. Typically these are grouped into what are known as UML profiles. For example, you can put together a Java 2 Enterprise Edition (J2EE) profile that includes stereotypes for sessionbean or javadataobject. If you are modeling a complex domain, consider putting together a UML profile that lets you easily identify elements as concepts in your domain, such as mutualfund or securitymonitor.