UML Notation
Note: The Microsoft UDDI SDK is not supported by or included in Microsoft Windows versions after Microsoft Windows Server 7. The Microsoft UDDI V3 SDK is included with Microsoft BizTalk Server. For more information about the Microsoft UDDI V3 SDK, see Microsoft BizTalk Server documentation
The Unified Modeling Language (UML) is a standard modeling language for describing objects. Its class diagram notation conveys ideas that can originate from several perspectives, ranging from conceptual to implementation. When the perspective is conceptual, the ideas represent an abstraction of real-world objects and their relationships appropriate for analysis and design. When the perspective is implementation, the ideas represent the actual objects assembled to realize a concrete goal.
The Registry Content section starts with a conceptual perspective and moves to an implementation perspective of the UDDI schema. This topic summarizes the features of the UML class diagram to help you understand it from both a conceptual and an implementation perspective. For more information about UML, see Other Resources about UDDI.
Classes, Class Attributes, Relationships
The UML notation represents each of the five primary information types, as discussed in Overall UDDI Model as a class. A box represents each class, and the name of the class appears in a pane at the top of the box. For example, the Business Entity type has the class name businessEntity, which is how the schema refers to it.
Class attributes appear in a box in a separate pane below the name of the class. For example, the businessEntity class has class attributes including businessKey, operator, and authorizedName. Each instance of a class has values (which are optional in some cases) for each of the class attributes.
Lines drawn between the boxes represent the relationships between classes. Two types of relationships occur in UDDI: composition and association.
A composition relationship occurs when a class (the whole) contains another class (a part) and the existence of the part depends on the existence of the whole. A solid diamond occurs in the diagram at the containing-class end of the composition relationship.
An association relationship occurs when there is a reference from one class to another. An arrowhead occurs in the diagram at the referenced-class end of the association relationship. For example, the businessService class can contain a bindingTemplate class (a composition), and the bindingTemplate class references a tModel class (an association).
Relationships between classes can have a multiplicity at each end of the relationship. The multiplicity designates how many instances of a class participate in the relationship. The following table gives the most common symbols for multiplicity.
Symbol | Meaning |
---|---|
0..1 |
Optional (zero or one) |
1 |
Required (one and only one) |
0..* |
Zero or more |
1..* |
One or more |
For example, a businessEntity optionally contains zero or more businessServices.
Schema Attributes, Schema Elements, and Schema Types
When a UML class diagram represents the UDDI schema, the class represents the basic XML schema object, which is an XML element. For UDDI, the XML schema element has class attributes that can be either additional XML schema elements or, alternatively, XML schema attributes. To signify this difference, an at sign (@) prefixes the name of an XML schema attribute. For example, the businessEntity element contains a schema attribute called operator (shown as @operator) and an element called name (shown as name).
To provide additional information about the schema, each entry for a schema attribute or schema element includes the multiplicity and the type of the attribute or element. The symbols for the multiplicity are the same as for relationship multiplicities.
The type of an attribute or element appears after a colon symbol and is usually a string, or one of the simple types such as name, description, or others. For example, the businessEntity element contains an optional, string, schema attribute named operator (shown as @operator[0..1]:string) and one or more name elements of the simple type name (shown as name[1..*]:name). When an element is a string, its type, enclosed in chevrons (<< >>), may occur above the name of the element in the class box.