Creating class diagrams with UML

Class diagrams are structure diagrams within the Unified Modeling Language, or UML for short. The modeling language UML is an ISO standard. It il­lus­trates systems of object-oriented pro­gram­ming. Business processes can also be recorded clearly with UML. Using visual means, UML shows system states and describes in­ter­ac­tions between system elements. The notation defines shapes and lines for 14 diagram types.

Meta­mod­el­ing describes both in­di­vid­ual elements of the modeling language and the language itself. It defines language units for different levels. For example, a unit of speech in this visual language is behavior. It describes both a metaclass and a generic term for all dynamic factors within a system. Another language unit is the object, the basic element of the object-oriented pro­gram­ming. UML class diagrams model objects in stances of classes. Therefore, the class diagram is one of the most important and commonly used diagram types in UML.

The diagram types are divided into two main cat­e­gories according to their function: structure diagrams and be­hav­ioral diagrams. The latter have a sub­cat­e­go­ry, called in­ter­ac­tion diagrams. These do not just model the general behavior of a system, but also focus on in­for­ma­tion flows between objects over time in a process. These include, for example, sequence diagrams, which model the chrono­log­i­cal order of messages that flow in a detailed use case. Be­hav­ioral diagrams visualize dynamic processes. An example is the activity diagram. This shows how in­di­vid­ual actions interact in a process flow. Struc­tur­al diagrams, on the other hand, show static states; they il­lus­trate the elements of a system and their in­ter­de­pen­den­cies.

The class diagram assigns object instances to specific classes based on their prop­er­ties – there is a hi­er­ar­chi­cal de­pen­den­cy. At the same time, re­la­tion­ships exist between different classes or between objects.

Class diagrams represent states with system elements. They show struc­tures down to the smallest instance. Therefore, they are suitable for rep­re­sent­ing detailed software ar­chi­tec­tures. Concrete pro­gram­ming steps can be derived from this. Some software-based pro­gram­ming en­vi­ron­ments convert these UML diagrams directly into code frames. Using team sharing, de­vel­op­ers com­mu­ni­cate with each other or with other decision-makers within a company. For outsiders, a UML diagram provides an overview of planned system struc­tures or process flows. It can also be used to formulate system re­quire­ments that the de­vel­op­ers then implement. IT pro­fes­sion­als can model, and ef­fec­tive­ly modify diagrams without having to program larger en­vi­ron­ments or processes in the planning phase.

These are the areas of ap­pli­ca­tion for a class diagram:

• They describe types within a system. The graphic rep­re­sen­ta­tion can be trans­ferred to different pro­gram­ming languages and en­vi­ron­ments. It therefore exists in­de­pen­dent­ly of the future ap­pli­ca­tion.
• You model existing software ar­chi­tec­tures. If ad­di­tion­al com­po­nents are to be in­te­grat­ed, they visualize suitable struc­tures on which new com­po­nents can be installed. For future system elements, class diagrams create a guide to the program code. Depending on re­quire­ments, this step can be sketchy or very detailed.
• They represent data models. They are suitable for systems of varying com­plex­i­ty.
• For nested ap­pli­ca­tions, doc­u­men­ta­tion and main­te­nance can become very complex. Class diagrams provide an overview of the scheme.
• They represent re­quire­ments for software. They can easily be forwarded as image files through internal business channels. They enable experts from different de­part­ments to exchange ideas about the ar­chi­tec­ture.
• The UML standard uses class diagrams to visualize its own notation.

The class is a model element in the class diagram, and is a spe­cial­iza­tion of the En­cap­su­lat­ed­Clas­si­fi­er and the Be­hav­iored­Clas­si­fi­er. It sum­ma­rizes a set of instances. Object instances within a class have the same char­ac­ter­is­tics (at­trib­ut­es) and behaviors (methods). They also have the same semantics, i.e. they use the same char­ac­ters with the same meaning. This makes the class a kind of pattern for its objects. It in­stan­ti­ates the objects and defines their behavior in the system.

These prop­er­ties are included in the notation when you create a class diagram. In UML, a class is displayed as a rectangle with a solid line. The body consists of three com­part­ments arranged one above the other. Only the upper most part needs to be modeled, because this is where you specify the class name. You can also op­tion­al­ly label the other two par­ti­tions with at­trib­ut­es (middle) and op­er­a­tions (bottom). You assign different vis­i­bil­i­ties to these elements by writing the following symbols in front of their names:

• + =public
• - = private
• # = protected
• / = derived
• ~ = packet
• * = haphazard

Prop­er­ties are connected elements. Class at­trib­ut­es (owne­dAt­trib­ut­es) are always roles. They are joined by con­nec­tors. If they have the property is­Com­pos­ite=true, they are class parts.

The UML property is a struc­tur­al feature that has various areas of ap­pli­ca­tion. In addition to its function as a class attribute, it can also display sent as­so­ci­a­tion.

The property type is derived from the clas­si­fi­er’s name. You can also define a default value for a char­ac­ter­is­tic. Modifiers also specify how a char­ac­ter­is­tic behaves:

• Ordered (Notation: isOrdered = true)
• Unique (Notation: isUnique = true)
• Not unique (Notation: isUnique = false)
• Read-only (The char­ac­ter­is­tic can only be read, notation: is­Read­On­ly = true)
• Sequence (The char­ac­ter­is­tic is an ordered col­lec­tion, notation: isUnique = false and isOrdered = true)
• Union (a derived subset union, notation: union)
• ID (Belongs to the clas­si­fi­er’s name, notation: id)
• Char­ac­ter­is­tic lim­i­ta­tion (a de­lim­i­ta­tion that in­flu­ences the char­ac­ter­is­tic, notation: property-con­straint)
• Re­de­f­i­n­i­tion of a char­ac­ter­is­tic (redefines an inherited, renamed char­ac­ter­is­tic, notation: redefines [Char­ac­ter­is­tic­name])
• Char­ac­ter­is­tic subset (sym­bol­izes a char­ac­ter­is­tic that is a subset of a named char­ac­ter­is­tic, notation: subsets [Char­ac­ter­is­tic­name])

Op­er­a­tions are be­hav­ioral functions. They occur in classes, but also in data types or in­ter­faces. You access a class instance directly. The operation defines the following aspects of an access call:

• Name
• Type
• Parameter
• Re­stric­tions

The operation belongs to its higher-level clas­si­fi­er. This may change them by re­defin­ing type or pa­ra­me­ters.

There are pre­con­di­tions for op­er­a­tions. These must be fulfilled before the operation can be executed. However, UML does not define how a behavior access call turns out if the pre­con­di­tions are not fulfilled. You also define sub­se­quent con­di­tions that must be fulfilled when the operation is completed. Body con­di­tions limit the output result to a value cal­cu­lat­ed from their spec­i­fi­ca­tions. This value should meet the post-con­di­tions. However, the operation can also raise an exception while it is being executed. Sub­se­quent­ly, it probably does not meet the post-con­di­tions.

The notation for the class diagram stip­u­lates that op­er­a­tions in a com­part­ment are noted in the class body. According to the UML standard, this in­for­ma­tion is mandatory. At the same time, UML allows you to suppress all standard spec­i­fi­ca­tions within a class. Only the name needs to be noted down.

A signal receiver indicates that a clas­si­fi­er is ready to accept a signal. It also defines which types of signals the instances of the class accept. The signal receiver is named like its signal. Write down the cor­re­spond­ing details in the class body, in a com­part­ment under the op­er­a­tions.

Ports are con­nec­tions for en­cap­su­lat­ed clas­si­fiers. They represent a point at which the clas­si­fi­er interacts with its en­vi­ron­ment. Apart from the ports, the en­cap­su­lat­ed clas­si­fi­er is a self-contained system. Since its internal structure and behavior elements remain un­af­fect­ed by the rest of the system, you can also define this clas­si­fi­er in­de­pen­dent­ly. As long as a system meets the port re­stric­tions, you can reuse the en­cap­su­lat­ed clas­si­fi­er in different en­vi­ron­ments.

UMI also allows multiple docking points per clas­si­fi­er. You can define separate rules for each port. The port is a property of the clas­si­fi­er, so you define its rules in the prop­er­ties area. These include the services that the clas­si­fi­er offers to its en­vi­ron­ment and the services it needs. You dif­fer­en­ti­ate between different in­for­ma­tion flows by iden­ti­fy­ing the port used for this.

Ports them­selves also have prop­er­ties. If the port executes published clas­si­fi­er functions, this indicates the isService property. If isService = true is given, the port is an in­dis­pens­able part of the en­cap­su­lat­ed clas­si­fiers’ ex­ter­nal­ly visible functions. With isService = false, the port is not one of the essential features and can sub­se­quent­ly be changed or deleted, like other internal functions.

Ports interact with in­ter­faces. There are provided and required in­ter­faces (see “In­ter­faces” below). The interface connected to the port specifies the in­ter­ac­tions that run over the port. Since the docking site is a property, it has a type. The value of is­Con­ju­gat­ed mediates between the type and the port’s interface. If the value is true, the required interface can be derived directly from the type of port or from the set of in­ter­faces that the port im­ple­ments. In this case, an interface provided is derived from the number of in­ter­faces. If is­Con­ju­gat­ed is true, the provided interface is the right type.

When an en­cap­su­lat­ed clas­si­fi­er generates an instance, cor­re­spond­ing instances are created for each of its ports. A port holds the instance in ac­cor­dance with its type and its mul­ti­plic­i­ty (see below). The instances are called UML in­ter­ac­tion points. Each instance has unique ref­er­ences that dis­tin­guish it from the different requests for be­hav­ioral functions directed to its ports.

When an en­cap­su­lat­ed clas­si­fi­er generates an instance, cor­re­spond­ing instances are then created for each of its ports. A port holds the instance in ac­cor­dance with its type and mul­ti­plic­i­ty (see below). The instances are called UML in­ter­ac­tion points. Each instance has unique ref­er­ences that dis­tin­guish it from the different requests for be­hav­ioral functions directed to its ports.

Ports with property is­Be­hav­ior = true sends a request to the en­cap­su­lat­ed clas­si­fi­er’s instance. The request adopts the instance’s specified behavior. This means that the behavior ports do not direct queries into your clas­si­fi­er’s interior. If no behavior is defined in the class diagram, messages on these ports will be lost.

You can model a port as a small square on the frame of the clas­si­fi­er it belongs to. Draw the required or provided interface to the port. If you do not specify any special char­ac­ter­is­tics for the port, draw the interface without a port.

Con­nec­tors define con­nec­tions between two or more instances. The spec­i­fi­ca­tion enables their com­mu­ni­ca­tion. Unlike re­la­tion­ships like as­so­ci­a­tions, con­nec­tors do not connect just any instances, just instances that are defined as con­nec­tion parts. Con­nec­tors are modelled as edges with at least two ends. They represent the par­tic­i­pat­ing instances that assign a type to the linkable elements.

Another important factor is mul­ti­plic­i­ty. This parameter specifies how many instances a struc­tured class can form. It also limits at­trib­ut­es and op­er­a­tions. It is a part of the inner structure – this is a mandatory element in the class body. You enter it behind the at­trib­ut­es and op­er­a­tions. This section also includes the topology. Nodes (object instances) connect to topology networks through com­mu­ni­ca­tion paths (Com­mu­ni­ca­tion­Paths).

Mul­ti­plic­i­ties are noted as follows:

<mul­ti­plic­i­ty> : <mul­ti­plic­i­tyrangeh> [<ordername> , <un­qiei­den­ti­fierr>]

The mul­ti­plic­i­ty range specifies a fixed value or a range:

• 0 = The class does not form instances (rarely occurs)
• 0..1 = Either no instance or an instance
• 1 or 1..1 = Exactly one instance
• 0..* or only * = No instance or more with open value
• 1..* = One instance or more with open value

The order and unique-ness can be expressed as a set or by single terms, separated by commas. Depending on whether the nodes are unique or ordered in the set, the set is given a type de­scrip­tion. In the notation, describe the in­di­vid­ual sizes as ordered/unordered or unique/not unique.

You note some re­strict­ed elements in UML as text, for example, an attribute of a class in the class diagram. Note the re­stric­tion behind the text element in braces. If the owner is an element that you represent as a symbol, place the re­stric­tion as close as possible to the symbol; it should be obvious that both elements have a semantic re­la­tion­ship. Make the con­nec­tion even clearer by writing the re­stric­tion in a notepad symbol and con­nect­ing it to its owner through a dashed line.

If the re­stric­tion affects two elements, connect the owners using a dashed line. Write the re­stric­tion in curly brackets. If you place an arrowhead at one end, this signals the position of the owner within a col­lec­tion of con­strained elements (con­strainedEle­ments). The arrow points away from the first position to the second. If more than two items have the con­straint, use the memo icon and link each item to the con­straint.

Edges are also among the elements that can be limited. Model more than two edges of the same type, drag the dashed con­straint line through all edges that represent the elements involved.

Stereo­types define metaclass ex­ten­sions. According to the UML spec­i­fi­ca­tion, they belong to the profiles. If a stereo­type describes ad­di­tion­al prop­er­ties of several meta­class­es, it can only describe one metaclass instance at a time during runtime. Among the meta­class­es, stereo­types play a role, since they can never stand alone. Stereo­types are always modeled with the clas­si­fi­er it enhances. You link the metaclass to the stereo­type by modeling an extension. 

UML defines some class stereo­types that extend your UML class diagrams. Six stereo­types are standard. Three stereo­types are often used, but not stan­dard­ized, and you can use them to convert the pattern “Model Pre­sen­ta­tion Control” (MVC) into UML. The three non-standard stereo­types are:

• The entity (notation: <<Entity>>): The stereo­type Entity defines a class or an object. The re­spec­tive instance rep­re­sents a col­lec­tion of data. It is often system data that needs to be stored over a longer time. The entity assumes the role of the model from the MVC pattern. UML knows this stereo­type, but assigns it to component diagrams by default. The fre­quent­ly used notation does not list the spec­i­fi­ca­tion. They model the entity as a circle resting on a short line.
   
• The boundary (notation: <<Boundary>>): The boundary is a stereo­type for a class or object. It roughly cor­re­sponds to the element view in the MVC pattern. The boundary models the boundary of your system, e.g. a user interface. Usually they are rep­re­sent­ed as a circle with a line on the left that meets a vertical line.
   
• The control element (notation: <<Control>>): The control element rep­re­sents the same elements as the con­troller under MVC. Classes or objects with this stereo­type model elements that co­or­di­nate system behavior or control flows. In the UML standard, the stereo­type <<Focus>> performs similar tasks. You draw a control instance as a circle with an open arrowhead on the line.

These three stereo­types can also be drawn as a simple class. Note the name of the stereo­type in the rectangle. Modelers mainly use these shapes in sequence diagrams. If you want to know more about entity boundary control diagrams, read our article about UML sequence diagrams.

These stan­dard­ized stereo­types are suitable for class diagrams:

• Focus (<<Focus>>)
• Helper (<<Auxiliary>>)
• Type (<<Type>>)
• Im­ple­men­ta­tion class (<<Im­ple­men­ta­tion­Class>>)
• Metaclass (<<Metaclass>>)
• Utility (<<Utility>>)

The focus class defines the basic business logic or control flow of helper classes. These support the focus class that binds one or more helpers. It im­plic­it­ly defines sup­port­ing classes by entering into a de­pen­den­cy re­la­tion­ship with them (see “The Directed Re­la­tion­ship” below). If it uses helper classes, it defines them ex­plic­it­ly. The UML standard rec­om­mends this stereo­type es­pe­cial­ly for the design phase when you represent control flows between com­po­nents or define the basic business logic.

The helper class usually acts in com­bi­na­tion with the focus class. It generally supports classes of crucial im­por­tance to the system. To this end, it carries out secondary control flows and defines sub­sidiary logic. It the helper class supports a focus class, the de­f­i­n­i­tion is explicit. You im­plic­it­ly define the supported class during a de­pen­den­cy re­la­tion­ship.

The type class defines an area for business objects. It also specifies the object operators. The type stereo­type can have at­trib­ut­es and as­so­ci­a­tions. However, it does not describe the physical execution of the object.

Some pro­gram­ming languages (e.g. Java or C++) only allow one class for each instance. However, you can use UML to assign an instance to several classes. The ap­pli­ca­tion class builds a bridge between these two worlds. This stereo­type limits the UML class. It de­ter­mines that an instance below it can only realize one class. The ap­pli­ca­tion class can implement several different types. To suc­cess­ful­ly execute a clas­si­fi­er assigned to it, it must fulfill two con­di­tions: it must provide all clas­si­fi­er op­er­a­tions and these must have clas­si­fi­er behavior defined. However, physical at­trib­ut­es and as­so­ci­a­tions do not have to match.

Since the forms of class and metaclass are not different, the metaclass label indicates that it is the stereo­type metaclass. The instances of this class are them­selves classes. With this stereo­type, you work at a higher level of ab­strac­tion.

The utility class has no instances. It merely iden­ti­fies a col­lec­tion of named at­trib­ut­es and op­er­a­tions. These are always static. Static at­trib­ut­es do not change when they are called. Static op­er­a­tions are used for col­lat­er­al entities or entity types. If you use the utility class, you first need to specify the cor­re­spond­ing values and op­er­a­tions right from the start, since these no longer change. Un­der­lin­ing indicates these elements.

There are also required in­ter­faces. You visualize a de­pen­den­cy re­la­tion­ship (see “Re­la­tion­ships” below). An element needs another element to perform the full scope of its own functions. In this case, a clas­si­fi­er (or one of its instances) requires an interface. The In­ter­faceUsage specifies the re­quire­ments for this interface. A solid line connects the clas­si­fi­er with an open semi­cir­cle. This sym­bol­izes the interface. Note the name of the interface for both rep­re­sen­ta­tives under the (semi­cir­cle).

If a class inherits an interface to a sub­or­di­nate class, model the interface con­nec­tion to the sub­or­di­nate class or instance. Show the hi­er­ar­chi­cal re­la­tion­ship with a cir­cum­flex (^), e.g. ^Interface 1.

Use the rec­tan­gu­lar interface notation, draw an edge between the two nodes. In the class diagram, edges model the re­la­tion­ships between classes, instances, or com­po­nents. UML pre­scribes different lines and arrows for different functions and re­la­tion­ships. In this case, you connect a class to the required interface using a dashed arrow with an open tip. Give the arrow the label <<use>>. You connect a provided interface to a class using a dotted arrow with a closed, unfilled tip. The arrow always points in the direction of the interface.

The enu­mer­a­tion is a data type. They represent the value of the enu­mer­a­tion as a so-called enu­mer­a­tion letter symbol. As you can see in the picture above, it is simply a name that sym­bol­izes a certain value. You choose this yourself. In the “Types of Roses” list, for example, the name “Tea Roses” stands for the number of tea roses in a florist’s as­sort­ment. In the class diagram, draw this clas­si­fi­er with the symbol for the class, a rectangle. The name and the label <<enu­mer­a­tion>> are in the header. They separate the head area from the body by hor­i­zon­tal lines in de­part­ments.

As with other classes, the enu­mer­a­tion reserves the upper sections for at­trib­ut­es and op­er­a­tions. If they remained empty, omit both sections from the diagram. In the bottom part, enter your bullet symbols. For example, the enu­mer­a­tion of rose species in a florist consists of the head with the title “Rose species” and the body with a list: tea roses, noisette roses, gallica roses, bourbon roses, cinnamon roses.

Class diagrams represent re­la­tion­ships between system elements. The viewer should see which com­po­nents the system needs and how they influence each other. The UML element re­la­tion­ship is an abstract class. It stands for the idea of a re­la­tion­ship between system com­po­nents. Thus, this element has no separate notation. However, its char­ac­ter­is­tics have specific details that dis­tin­guish them.

Re­la­tion­ships are un­der­stood in UML as edges between nodes. Therefore, you generally model re­la­tion­ships with a line or vari­a­tions thereof – like the arrow.

The UML de­f­i­n­i­tion for re­la­tion­ship sub­class­es and instances has changed dras­ti­cal­ly from UML 1 to UML 2. Orig­i­nal­ly, for example, there were semantic, struc­tur­al, and di­rec­tion­al re­la­tion­ships. UML assigned three concrete re­la­tion­ships (as­so­ci­a­tion, re­stric­tion, and de­pen­dence) to the semantic re­la­tion­ships. Under UML 2, re­stric­tions are now packable elements, as­so­ci­a­tions define some sources as struc­tur­al and semantic re­la­tion­ships. This de­pen­den­cy now runs under di­rec­tion­al re­la­tion­ships.

It remains to be seen how the standard will change in future versions. In the following, we continue to explain class diagrams according to UML 2.5, so the metaclass re­la­tion­ship has two sub­class­es: the directed re­la­tion­ship and the as­so­ci­a­tion.

The subtype com­po­si­tion (composite ag­gre­ga­tion) describes the re­la­tion­ship between a com­po­si­tion of parts and a single part thereof. If the system deletes the whole (the com­po­si­tion), it also destroys the in­di­vid­ual part. For example, if a tree is the whole then a leaf is part of it. If the tree falls victim to a forest fire, the fire also destroys the leaves. For example, if you create a class diagram and represent this re­la­tion­ship, draw a solid line between the instances. Model a black-filled rhombus on the com­po­si­tion side (in the example: the “tree” instance). This page is also called the end of ag­gre­ga­tion.

The second subtype of ag­gre­ga­tion is shared ag­gre­ga­tion (or just ag­gre­ga­tion for short). This asym­met­ric re­la­tion­ship exists between a property and an instance that rep­re­sents a set of instances. The con­nec­tion should be direct. Otherwise, a com­po­si­tion instance could be in­ter­pret­ed as part of itself. This can happen if you model the de­pen­den­cy re­la­tion­ship cycli­cal­ly. The shared property can belong to several com­po­si­tions. At the same time, their instance can exist in­de­pen­dent­ly of the com­po­si­tion. If the system deletes a com­po­si­tion (or all of them) in this case, the sub-instance can continue to exist. Therefore, this re­la­tion­ship is con­sid­ered weak in com­par­i­son to com­po­si­tion.

The as­so­ci­a­tion also offers a special feature: the as­so­ci­a­tion class. It is both the class and the re­la­tion­ship. This allows you to assign at­trib­ut­es to the as­so­ci­a­tion class in the class diagram.

The subclass specifies the general class. This also means that the subclass shares some prop­er­ties – in content and structure – with the su­per­class, usually the basic elements. This cir­cum­stance is called in­her­i­tance. In this example, the dahlia class shares the capitulum-shaped in­flo­res­cence with the su­per­class daisy. A specific feature of the genus dahlia are its eight pairs of chro­mo­somes – other plants usually have just two pairs of chro­mo­somes. The different dahlia species therefore form more diverse char­ac­ter­is­tics.

Im­plic­it­ly, UML allows a multiple in­her­i­tance. This allows you to model several sub­class­es that have both common and different su­per­class­es. Al­ter­na­tive­ly, there are several levels of gen­er­al­iza­tion. You can either display these re­la­tion­ships with the arrow notation or you interlace the sub­class­es within their su­per­class­es. To do this, you model all as­so­ci­at­ed sub­class­es in the su­per­class­es’ body.

The Gen­er­al­iza­tion Set helps you to keep track of the class diagram. The set is a packable element. Packages in UML are con­tain­ers for named elements that have semantic sim­i­lar­i­ties and may change together. A package is namespace, not a class. However, you can associate the gen­er­al­iza­tion set with a clas­si­fi­er. This one is called a power type.

You model the power type as a string a the gen­er­al­iza­tion edge like this: {[is­Cov­er­ing Property] , [is­Dis­joint Property]} : [Powertyps name]. The is­Cov­er­ing property describes whether the set is complete. The values are either complete or in­com­plete. The is­Dis­joint property indicates whether the clas­si­fiers share common instances. The values are either disjoint (no over­lap­ping) or over­lap­ping.

the right, the directed re­la­tion­ships.]

Ab­strac­tion connects elements on different levels. Al­ter­na­tive­ly, it shows different per­spec­tives. The named elements in this de­pen­den­cy re­la­tion­ship represent the same concept. The more specific element according to the UML standard is the client, which depends on the provider, the more abstract element. So the end of the arrow should be in the subclass and the top in the su­per­class. UML also allows an inverse notation. If you think it makes more sense for the abstract element to depend on its subclass, draw the arrowhead to the more specific element.

Ab­strac­tion has two sub­class­es: re­al­iza­tion and man­i­fes­ta­tion.

We have already mentioned re­al­iza­tion with regard to in­ter­faces. In­ter­fac­e­Re­al­iza­tion is a spec­i­fi­ca­tion of the re­al­iza­tion. It describes a re­la­tion­ship between clas­si­fi­er and interface. The clas­si­fi­er uses the interface to offer their client a service. The interface executes this service. To do this, the clas­si­fi­er must fulfill the contract that the interface specifies. The notation for provided and requires in­ter­faces can be found in the “In­ter­faces” section.

Sub­sti­tu­tion is another re­la­tion­ship that specifies the re­al­iza­tion. It consists of a sub­sti­tute clas­si­fi­er and a contract clas­si­fi­er. The sub­sti­tute clas­si­fi­er fulfils the contract of the other clas­si­fi­er. During runtime, instances of the re­place­ment clas­si­fi­er po­ten­tial­ly replace instances of the contract clas­si­fi­er. In contrast to spe­cial­iza­tion, there is no struc­tur­al sim­i­lar­i­ty between elements of sub­sti­tu­tion. You note the sub­sti­tu­tion as a de­pen­den­cy edge (dashed arrow with open tip) in the class diagram and add the keyword <<sub­sti­tute>> to the edge.

The spec­i­fi­ca­tion describes a re­la­tion­ship between an artifact and one of more model elements. UML defines artifacts as clas­si­fiers. They symbolize concrete, physical instances like archive folders. The char­ac­ter­is­tic value means that an artifact executes a connected element directly. Con­verse­ly, it can symbolize that elements are involved in the artifact’s creation. The char­ac­ter­is­tic value is an element of the staging diagram and is only mentioned here for the sake of com­plete­ness. They require the same notation as re­place­ments. The keyword is <<manifest>>.

Ab­strac­tion also defines some stereo­types. Stereo­types belong to the UML profiles. If you want to extend an existing metaclass for a project, you define a profile for it. The stereo­type class is always used together with the metaclass, since a profile only changes what already exists or adds a ter­mi­nol­o­gy. Since UML 2.4.1, UML notes stereo­types with capital letters at the beginning. The standard stereo­types for ab­strac­tion are:

• <<Derive>>: An element is derived from another element. Usually they are of the same type.
• <<Refine>>: An element gives more detailed in­for­ma­tion for a class that also exists in the other element. The elements are on different levels of ab­strac­tion. For example, an executive model refines its “Employees” class in relation to the “Employees” class at the design level.
• <<Trace>>: Different models express different aspects of a system. Mapping or tracing allows you to trace elements that represent the same concept in different models. You can use the trace to un­der­stand changes being made to elements and spec­i­fi­ca­tions.

De­ploy­ment shows the re­la­tion­ship between an artifact and its target. In the UML diagram, the de­ploy­ment target is indicated by the de­ploy­ment edge of one or more artifacts. The keyword for the edge is <<deploy>>. You can also apply this de­pen­den­cy at instance level. Al­ter­na­tive­ly, model the artifact into the target’s body. To do this, either record the artifact as a symbol or list the artifacts provided. This de­pen­den­cy is part of the notation for delivery diagrams.

Usage describes a re­la­tion­ship in which the client needs the provider to complete their tasks or perform op­er­a­tions. The usage therefore im­ple­ments the general de­pen­den­cy as an instance. This de­pen­dence char­ac­ter­izes some concrete re­la­tion­ships:

• <<use>>: One element uses another element, but the exact re­la­tion­ship between par­tic­i­pants and the exact benefits are not specified in detail.
• <<create>>: A client clas­si­fi­er is one of its struc­tur­al or be­hav­ioral elements creates one or more instances of the vendor clas­si­fi­er.
• <<call>>: One operation calls another operation. The target can be any operation in the en­vi­ron­ment of the source operation, including su­per­or­di­nate clas­si­fiers.
• <<send>>: An operation is the source, the client. Your target is a signal. The de­pen­den­cy models that the operation sends the target signal.
• (Required Interface ­­­-----C): Unlike the interface provided, the required interface does not exist in the clas­si­fi­er. It de­ter­mines the services that a clas­si­fi­er needs to perform its functions for its client. The de­pen­den­cy exists between clas­si­fi­er and interface. Read more about this in the “In­ter­faces” section.

Template binding is the last di­rec­tion­al re­la­tion­ship used in the class diagram. When you create a class diagram, it is often helpful to create templates for your classes. For classes, templates consist of template pa­ra­me­ters. These pa­ra­me­ters belong in the template signature. The signature de­ter­mines the ordered set of pa­ra­me­ters within the template. If you model classes that do not have to have in­di­vid­ual prop­er­ties, you work more ef­fi­cient­ly when you use templates. However, if you want a class to have fixed pa­ra­me­ters, use the template binding. The re­la­tion­ship exists between a bound element and the template signature in a target template.

The bound element is template capable, i.e. it can either become a template on its own or it can be bound to other templates. The element is bound because it has a link to a template. This link describes the structure of the element by replacing formal template pa­ra­me­ters from the template with valuable pa­ra­me­ters.