Appendix F. UML Class Diagram primer

The Unified Modeling Language (UML) is a graphical language for expressing the design of software and software systems. UML was originally born out of the object-oriented (OO) software design movement to fulfill the need for software engineers to share their design ideas in a standardized graphical fashion.

UML describes several types of diagrams for modeling software design and interaction. The one primarily used in this book is the Class Diagram. The Class Diagram is used to show classes, objects (instantiations of classes), and the relationships between these. The most important of these relationships are inheritance ("is a type of") and aggregation ("is part of"). This book uses the UML Class Diagram chiefly to represent the relationships between XML elements in VoiceXML.

While UML was originally intended to be a modeling language for object-oriented software systems, many of its concepts carry over to XML in a straightforward fashion. An XML schema, represented either using the DTD notation or the XSD notation, correlates to a set of class definitions in an object-oriented system. XML entities grouping element types correlate to abstract classes and/or interfaces in an object-oriented system. A declaration of an element type that is included in an XML entity declaration is analogous to a class extending an abstract class (inheritance) or a class implementing an interface. An example of this relationship is shown in Figure F-1.

Here we see form.item at the top, with block, field, initial, object, record, transfer, and dialog all inheriting from it. This is to say that each of these element types (block, field, etc.) is a type of form.item.

Notice that form.item is shown in italics. This is used to indicate that form.item is an abstract class or, in the context of XML, an entity. This means that you cannot instantiate form.item directly. Instead, you can only create an instance of something that inherits from form.item.

An XML document conforming to a DTD or an XML Schema correlates to a set of instantiated objects in an object-oriented software system. An element that contains other elements is analogous to an object aggregating other objects. An example of this relationship is shown in Figure F-2.

This figure focuses on the filled element. It shows that record, subdialog, transfer, field, form, and object may all contain instances of filled. Likewise, filled may contain instances of elements that are a type of executable.content.

Notice how the filled class is split into two sections, a top section with the class name, and a bottom section with a list of attributes. If this were a Java class, there would be yet a third section showing the methods (functions) supported by this class. Since there really isn't such a concept in XML, we've abbreviated our diagrams by omitting this section. We could have alternatively left this section empty, as is also common.

UML describes attributes using a consistent form: attribute-name : attribute-type [ = default-value ]. In Figure F-2 we see this form used to define two attributes, mode and namelist. The mode attribute can contain one of the two literal values, any or all. If nothing is specified, it defaults to all. The namelist attribute can contain any value of type field.names.

UML can be used as rigorously or as casually as the situation requires. It is, first and foremost, a language for expressing ideas. In writing this book, we have taken a more casual approach to UML: We abbreviated much of the notation to provide an uncluttered view of the concepts we were trying to convey. However, software development tools, such as Rational Rose, actually use UML to generate source code, which requires a much more rigorous approach. For those readers who find this sort of rigorous UML intriguing, we refer you to The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, and James Rumbaugh.