Section 2.9. Variations on Class Diagrams

2.9. Variations on Class Diagrams

Because class diagrams model structures well, they can be used to capture well-defined, hierarchical information. Class diagrams have been used to capture XML and database schemas with some degree of success. In the interest of full disclosure, people who deal with XML and database schemas extensively have reservations about using class diagrams to capture the information, specifically because class diagrams are so generic. Each domain has its own notation that may be better suited to capturing complex relationships or domain-specific information. However, UML has the benefit of being a common language that is understood by those outside the XML and database domains.

2.9.1. XML Schemas

The structural design of an XML document can be captured in an XML schema. XML schemas are to XML documents as classes are to objects; XML documents are instances of a schema. Therefore, it's not a giant leap to realize that class diagrams can be used to model XML schemas. XML schemas are described using the XML Structure Definition Language (XSDL). XSDL is a text language (as opposed to the graphical nature of UML) and can be verbose; mapping XSDL to UML can make it much easier to digest a schema document.

The fundamental elements of XSDL are XML elements, which are connected in sequences, choices, and complex structures. Each element may have extra information attached to it using (conveniently enough) attributes. Modelers typically represent XML elements as classes and XSDL attributes as UML attributes. Each element is linked to the next using composition arrows. Multiplicity specifications on the relationships show how many times one element appears within another. Example 2-1 is a sample XML document that describes a piece of equipment.

Example 2-1. A sample XML document

 <?xml version="1.0" encoding="UTF-8"?> <equipmentlist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xsi:noNamespaceSchemaLocation="equipment.xsd">     <equipment equipment>         <shortname>             <langstring lang="en">Hammer</langstring>         </shortname>         <technicalcontact>             <contact>                 <name>Ron</name>                 <telephone>555-1212</telephone>             </contact>         </technicalcontact>         <trainingcontact>             <contact>                 <name>Joe</name>                 <email>[e-mail]</email>             </contact>         </trainingcontact>     </equipment> </equipmentlist> 

Example 2-2 is the XSDL that describes the XML document.

Example 2-2. XML schema describing Example 2-1

 <?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"     elementFormDefault="qualified">      <!-- ~Class: contact ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="contact" type="contact"/>    <xs:complexType name="contact">       <xs:sequence>         <xs:element name="name" type="xs:string"/>         <xs:choice>           <xs:element name="telephone" type="xs:string"/>           <xs:element name="email" type="xs:string"/>         </xs:choice>       </xs:sequence>    </xs:complexType>      <!-- ~Class: equipment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="equipment" type="equipment"/>    <xs:complexType name="equipment">       <xs:sequence>          <xs:element ref="shortname"/>          <xs:element name="technicalcontact" type="technicalcontact"/>          <xs:element name="trainingcontact" type="trainingcontact"/>       </xs:sequence>       <xs:attribute name="equipmentid" type="xs:string" use="required"/>    </xs:complexType>      <!-- ~Class: equipmentlist ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="equipmentlist" type="equipmentlist"/>    <xs:complexType name="equipmentlist">       <xs:sequence>          <xs:element ref="equipment" minOccurs="1" maxOccurs="unbounded"/>       </xs:sequence>    </xs:complexType>      <!-- ~Class: <<XSDtopLevelAttribute>> lang~~~~~~~~~~~~ -->    <xs:attribute name="lang" type="xs:language"/>      <!-- ~Class: langstring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="langstring" type="langstring"/>    <xs:complexType name="langstring">       <xs:simpleContent>          <xs:extension base="xs:string">             <xs:attribute name="lang" use="required">                <xs:simpleType>                   <xs:restriction base="xs:NMTOKEN">                      <xs:enumeration value="en"/>                      <xs:enumeration value="fr"/>                   </xs:restriction>                </xs:simpleType>             </xs:attribute>          </xs:extension>       </xs:simpleContent>    </xs:complexType>      <!-- ~Class: shortname ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="shortname" type="shortname"/>    <xs:complexType name="shortname">       <xs:sequence>          <xs:element ref="langstring" minOccurs="1" maxOccurs="unbounded"/>       </xs:sequence>    </xs:complexType>      <!-- ~Class: technicalcontact ~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="technicalcontact" type="technicalcontact"/>    <xs:complexType name="technicalcontact">       <xs:sequence>          <xs:element ref="contact" minOccurs="1" maxOccurs="unbounded"/>       </xs:sequence>    </xs:complexType>      <!-- ~Class: trainingcontact ~~~~~~~~~~~~~~~~~~~~~~~~~ -->    <xs:element name="trainingcontact" type="trainingcontact"/>    <xs:complexType name="trainingcontact">       <xs:sequence>          <xs:element ref="contact" minOccurs="1" maxOccurs="unbounded"/>       </xs:sequence>    </xs:complexType>    </xs:schema> 

Figure 2-38 is a UML representation of the schema. Elements are represented as classes, with one exception: the contact definition includes a choice option. Figure 2-38 represents this using another class stereotyped as XSDchoice, and the options are represented as attributes of the class.

So, while UML simplifies a schema by representing the information graphically, details such as sequencing and type information can be lost without using a UML extension mechanism such as constraints or stereotypes.

2.9.2. Database Schemas

By mapping database tables to classes and table rows to attributes, you can capture a database schema fairly well using UML. Additional information such as primary keys, foreign keys, and constraints can be captured using UML constraints or stereotypes. You can show relationships between tables using associations between classes (usually composition relationships, but that is just by convention). Figure 2-39 shows a sample database schema represented using a UML class diagram.

As with XML schemas, few professional database administrators model databases using class diagrams. UML class diagrams are useful for conveying schema information in a common language, but they lack the expressive (and custom) capabilities of the more standard database notation, Entity Relation Diagrams (ERDs).

Figure 2-38. A class diagram representation of Example 2-2

Figure 2-39. An example database schema using a class diagram