Customizing UML for Fun and Profit

Software Development

Although UML's designers intended it to be a general-purpose modeling language, they also realized that modelers have diverse needs for different domains and platforms. For example, a financial modeler who specifies commodities and trades might have different requirements than an aerospace modeler who must define both hardware and software elements. Similarly, a vendor whose tool generates Java and EJB from UML models probably has different needs than another vendor whose tool generates C# and COM+. So, from its inception UML has provided several extension mechanisms that allow modelers to customize it in a limited way.

UML has three built-in extension mechanisms: stereotypes, tag definitions and constraints. Stereotypes are sometimes referred to as "lightweight extensions" and may be considered a restricted form of a metaclass (a class that specifies another class). Although both a metaclass and a stereotype can define a new type of model element, a metaclass can have both attributes and associations, but a stereotype can have neither. For example, one might define Transaction (notated as <<transaction>>) as a stereotype that customizes the metaclass Class, and then define <<transaction>> BillPayment as a particular type of transaction. Tag definitions define the properties of model elements, including stereotypes, as name-value pairs (for example, session: Session Kind for the <<transaction>> stereotype), in which the name is referred to as the tag. Constraints specify semantic conditions or various other restrictions, such as "A customer can have only one billing address" or customer.billing Address → size ≤ 1.

A Sample Use of the Entity Stereotype [click for larger image] The keyword <<entity>> is used to highlight the database gateways. We could have another keyword for the shopping cart's session- specific nature, but for the moment we'll just focus on the database gateway. The keyword <<entity>> indicates that the marked classes are stereotype customizations of the base class Class, the metaclass that defines the semantics for all UML classes.

These built-in extension mechanisms allow you to add your own constructs to UML in a properly controlled manner. The most recent minor revision of the language, UML 1.4, refines the notation and semantics for extensions and also lets you organize them into profiles, a topic that we will explore further.

Why Customize?
Consider a simple modification that helps with a perennial problem. Often, applications use persistent objects that map very closely to relational database tables, following a pattern that Martin (www.martinfowler.com/isa) calls a database gateway. In addition, Web applications frequently involve transactional objects (such as shopping carts) that aren't saved in tables. Let's look at a sample class diagram that shows how to specify persistent objects (see "A Sample Use of the Entity Stereotype").

Here, the keyword <<entity>> highlights the database gateways. (Entity is a common—and pleasantly short—synonym that honors the database tradition.) We could have another keyword for the shopping cart's session-specific nature, but for the moment let's just focus on the database gateway. The keyword <<entity>> indicates that the marked classes are stereotype customizations of the base class Class, the metaclass that defines the semantics for all UML classes. However, it isn't clear from the example how the semantics of this stereotype vary from those of ordinary classes.

When you use a stereotype in this manner, you must explain it, either informally or formally. Informally, you can say that the <<entity>> stereotype represents a business object or component that's a direct mapping of a database table using the database gateway pattern. An example like this one is also a good way to explain your motivation and describe how the stereotype works.

While this informality might be acceptable for some, others must provide a more rigorous definition. More formally, you can define a stereotype using UML graphic or tabular notation. The graphic notation for specifying the <<entity>> stereotype is shown in "Entity Stereotype Specification". This example clearly indicates that <<entity>> is a stereotype of the base class Class, and that it includes two tag definitions for specifying the table and DB (database) properties required for persistent storage. It also includes a constraint to ensure that the length of the table name does not exceed 32 characters.

Entity Stereotype Specification [click for larger image] <<entity>> is a stereotype of the base class Class, including two tag definitions for specifying the table and DB (database) properties required for persistent storage. It also includes a constraint to ensure that the length of the table name does not exceed 32 characters.

Stereotypes can be further refined by generalizing other stereotypes. For example, we might want to further refine the stereotype <<entity>> for an Enterprise JavaBean (EJB) implementation. The specification for an <<EJBEntity>> stereotype is shown in "EJBEntity Stereotype Specification," right. This stereotype is a specialization of the <<EJB>> stereotype, which is based on the Component metaclass. (The Component metaclass defines the semantics for all UML components.) Like the <<entity>> stereotype, the <<EJBEntity>> stereotype includes tag definitions for table and DB, but it also contains new tag definitions for persistenceMgr and reentrant properties. In addition, it includes constraints related to persistence and transaction management. The tabular form of the <<EJBEntity>> stereotype, which tends to be more compact for large numbers of extensions, is illustrated in the tables "Specifying EJBEntity Stereotypes with Tabular Notation" and "Specifying EJBEntity Tags with Tabular Notation."

You can see how <<EJBEntity>> stereotypes are applied along with stereotypes for EJB transactions (<<EJBSession>> stereotypes) in the diagram, "Sample Use of EJBEntity and EJBSession Stereotypes." Note that each of the EJB components in the example offers two interfaces: one for factory operations (such as create and find) and the other for business operations specific to the component (such as getItems and setTotal). In the case of EJBs, the names for interfaces that group factory operations include a "Home" suffix, such as AccountHome.

Defining Profiles
Sometimes developers model a particular domain or problem space that needs a large number of extensions. Although in the past, modelers might informally define and organize these extensions, previous UML specifications weren't clear about managing large numbers of them. One of the most significant improvements to UML 1.4 is the ability to define a group of extensions as a profile. In a metacircular twist, profiles are themselves defined as a UML extension: A <<profile>> is a stereotyped Package that contains model elements that have been customized for a particular domain or purpose using the extension mechanisms described above.

Profiles make it easier for people to define and share common sets of extensions both inside and outside the OMG UML standards process. If a small group of companies wants to collaborate in order to define extensions for Web services, they can just meet and agree on a profile for this purpose without having to deal with the official UML standards process. The process is likely to be much quicker than the normal standards body process, creating an advantage for the collaborating companies. In an additional advantage for the entire UML user community, these extensions won't be added to the already corpulent UML. For example, the Java Community Process recently released a UML profile for Enterprise JavaBeans (EJBs) that specifies a standard representation for EJB architecture elements in a UML model (see www.jcp.org/jsr/detail/26.jsp).

EJBEntity Stereotype Specification [click for larger image] This stereotype is a specialization of the <<EJB>> stereotype, which is based on the Component metaclass. "Also," as it is used here, means that "{If Component contains tags for a persistent entity, it cannot also contain tags for transactions.}"

Typically, a profile's core content comprises a list of new stereotypes. Each stereotype needs a definition, preferably a formal one. If the stereotypes introduce new graphic notations, these must also be added. Be wary about adding a lot of new notation—it's tricky to design new notation that's both consistent with old notation and mnemonic. Introduce new notation sparingly, and, when in doubt, stick with the default practice of adding keywords (for example, <<entity>>) to the existing notation of the constructs that you're stereotyping.

As you should expect, the stereotypes defined in the profile are commonly refined by tag definitions and constraints. The constraints are sometimes referred to as well-formedness rules, since they define the rules to which the new profile must conform to be properly formed. So, if you've defined a new stereotype of Class called <<boundary>>, you may want to include a rule that states that a boundary class may only inherit from other boundary classes. The UML metamodel specification uses well-formedness rules to delineate the nature of a correct UML model. In the case of UML specification, the well-formedness rules are defined using both the Object Constraint Language (OCL) and precise English. When you define well-formedness rules for a profile, you may also use OCL, English, Japanese, Java pseudocode or any other constraint language that you consider appropriate.

Making UML More Agile
One of the most common complaints about UML (and one that we share) is that the language is too large and complex, making it difficult for people to learn and challenging for vendors to implement. As a result, most people and vendors use only a small subset of UML.

How small is this subset of UML? It has yet to be precisely measured, but that doesn't stop people saying that the 80-20 rule applies to UML usage. We'll refer to that elusive 20 percent as the UML kernel.

Why is this UML kernel elusive? Although most agree that there is a small common subset, there is no industry consensus about either what should be included in the kernel or the way it should be defined.

The next major revision, UML 2.0, will provide an excellent opportunity to identify the kernel. Once it's well defined, the rest of the language can be added modularly via profiles. (We're assuming here that UML 2.0 profiles will include metaclasses in addition to the extension mechanisms previously discussed.) For example, we could define a UML kernel that comprises only the basic constructs for specifying class diagrams, sequence diagrams and use cases. This kernel could then be extended with profiles for additional diagrams (say, statecharts and activity graphs) and advanced constructs (such as n-ary associations and qualifiers), in which each profile defines a separate language-compliance point.

Sample Use of EJBEntity and EJBSession Stereotypes [click for larger image] Note that each of the EJB components offers two interfaces, one for factory operations (such as create and find), and the other for business operations specific to the component (such as getItems and setTotal). In the case of EJBs, the names for interfaces that group factory operations include a "Home" suffix, such as AccountHome.

The increased modularity of this kernel-based language architecture would allow methodologists and practitioners to customize UML to meet their unique needs. For example, practitioners of Extreme Programming, Scrum, Crystal and other agile methods might use informal customizations of the kernel language. In contrast, practitioners of Unified Process, Catalysis and other formal methods could pick from predefined profiles or cobble together their own profiles as they see fit. This architecture would also allow modelers to flexibly replace one profile with another. For example, one development team might want to replace the standard activity graphs profile with a proprietary business process workflow profile, while another development team might want to swap the standard component modeling profile with one that's customized for EJB components.

This kind of architectural restructuring will not only make UML smaller and more flexible, it will also make it more robust and adaptable. The increased modularity will make it easier for the OMG standard process to delegate the responsibilities for individual profiles to specialized workgroups that can refine and maintain them.

There is, of course, a good chance that all these profiles will get all the more confusing. ("Oh, you're using the inverted epsilon EJB profile with a cinnamon stick!") But at least that confusion will be nudged to the edges of UML, leaving the more common material in a clearer and more stable state. We expect that methodologists, companies and consortia will propose complementary and competitive profiles, and hope that much natural selection will occur. Over time, profiles that are used extensively should thrive, whereas those that are underutilized should wither—which is a much more agile way of thinking about the future of UML. The result should be a modeling language that is a better blend of precision, conciseness and pragmatism than anything designed by a committee of methodologists.