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-ori­ent­ated 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.

Metamod­el­ing describes both in­di­vidu­al 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 behaviour. 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-ori­ent­ated 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­egor­ies according to their function: structure diagrams and be­ha­vi­our­al diagrams. The latter have a sub­cat­egory, called in­ter­ac­tion diagrams. These do not just model the general behaviuor of a system, but also focus on in­form­a­tion flows between objects over time in a process. These include, for example, sequence diagrams, which model the chro­no­lo­gic­al order of messages that flow in a detailed use case. Be­ha­vi­our­al diagrams visualise dynamic processes. An example is the activity diagram. This shows how in­di­vidu­al 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­pend­en­cies.

The class diagram assigns object instances to specific classes based on their prop­er­ties – there is a hier­arch­ic­al de­pend­ency. 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­res­ent­ing detailed software ar­chi­tec­tures. Concrete pro­gram­ming steps can be derived from this. Some software-based pro­gram­ming en­vir­on­ments convert these UML diagrams directly into code frames. Using team sharing, de­velopers com­mu­nic­ate 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­velopers then implement. IT pro­fes­sion­als can model, and ef­fect­ively modify diagrams without having to program larger en­vir­on­ments or processes in the planning phase.

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

• They describe types within a system. The graphic rep­res­ent­a­tion can be trans­ferred to different pro­gram­ming languages and en­vir­on­ments. It therefore exists in­de­pend­ently of the future ap­plic­a­tion.
• You model existing software ar­chi­tec­tures. If ad­di­tion­al com­pon­ents are to be in­teg­rated, they visualise suitable struc­tures on which new com­pon­ents 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­ity.
• For nested ap­plic­a­tions, doc­u­ment­a­tion and main­ten­ance 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 visualise its own notation.

The class is a model element in the class diagram, and is a spe­cial­isa­tion of the En­cap­su­lated­Clas­si­fi­er and the Be­ha­vi­oured­Clas­si­fi­er. It sum­mar­ises a set of instances. Object instances within a class have the same char­ac­ter­ist­ics (at­trib­utes) and be­ha­viours (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 behaviour 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 modelled, because this is where you specify the class name. You can also op­tion­ally label the other two par­ti­tions with at­trib­utes (middle) and op­er­a­tions (bottom). You assign different vis­ib­il­it­ies 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­utes (owned­At­trib­utes) are always roles. They are joined by con­nect­ors. If they have the property isCom­pos­ite=true, they are class parts.

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

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­ist­ic. Modifiers also specify how a char­ac­ter­ist­ic behaves:

• Ordered (Notation: isOrdered = true)
• Unique (Notation: isUnique = true)
• Not unique (Notation: isUnique = false)
• Read-only (The char­ac­ter­ist­ic can only be read, notation: is­ReadOnly = true)
• Sequence (The char­ac­ter­ist­ic 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­ist­ic lim­it­a­tion (a de­lim­it­a­tion that in­flu­ences the char­ac­ter­ist­ic, notation: property-con­straint)
• Re­defin­i­tion of a char­ac­ter­ist­ic (redefines an inherited, renamed char­ac­ter­ist­ic, notation: redefines [Char­ac­ter­ist­ic­name])
• Char­ac­ter­ist­ic subset (sym­bol­ises a char­ac­ter­ist­ic that is a subset of a named char­ac­ter­ist­ic, notation: subsets [Char­ac­ter­ist­ic­name])

Op­er­a­tions are be­ha­vi­our­al 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­de­fin­ing type or para­met­ers.

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 behaviour access call turns out if the pre­con­di­tions are not fulfilled. You also define sub­sequent 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­lated from their spe­cific­a­tions. This value should meet the post-con­di­tions. However, the operation can also raise an exception whilst it is being executed. Sub­sequently, 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­form­a­tion is mandatory. At the same time, UML allows you to suppress all standard spe­cific­a­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­res­pond­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­lated clas­si­fi­ers. They represent a point at which the clas­si­fi­er interacts with its en­vir­on­ment. Apart from the ports, the en­cap­su­lated clas­si­fi­er is a self-contained system. Since its internal structure and behaviour elements remain un­af­fected by the rest of the system, you can also define this clas­si­fi­er in­de­pend­ently. As long as a system meets the port re­stric­tions, you can reuse the en­cap­su­lated clas­si­fi­er in different en­vir­on­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­vir­on­ment and the services it needs. You dif­fer­en­ti­ate between different in­form­a­tion flows by identi­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­lated clas­si­fi­ers’ ex­tern­ally visible functions. With isService = false, the port is not one of the essential features and can sub­sequently 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 isCon­jug­ated 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 isCon­jug­ated is true, the provided interface is the right type.

When an en­cap­su­lated clas­si­fi­er generates an instance, cor­res­pond­ing instances are created for each of its ports. A port holds the instance in ac­cord­ance with its type and its mul­ti­pli­city (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­ha­vi­our­al functions directed to its ports.

When an en­cap­su­lated clas­si­fi­er generates an instance, cor­res­pond­ing instances are then created for each of its ports. A port holds the instance in ac­cord­ance with its type and mul­ti­pli­city (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­ha­vi­our­al functions directed to its ports.

Ports with property is­Be­ha­viour = true sends a request to the en­cap­su­lated clas­si­fi­er’s instance. The request adopts the instance’s specified behaviour. This means that the behaviour ports do not direct queries into your clas­si­fi­er’s interior. If no behaviour 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­ist­ics for the port, draw the interface without a port.

Con­nect­ors define con­nec­tions between two or more instances. The spe­cific­a­tion enables their com­mu­nic­a­tion. Unlike re­la­tion­ships like as­so­ci­ations, con­nect­ors do not connect just any instances, just instances that are defined as con­nec­tion parts. Con­nect­ors are modelled as edges with at least two ends. They represent the par­ti­cip­at­ing instances that assign a type to the linkable elements.

Another important factor is mul­ti­pli­city. This parameter specifies how many instances a struc­tured class can form. It also limits at­trib­utes 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­utes and op­er­a­tions. This section also includes the topology. Nodes (object instances) connect to topology networks through com­mu­nic­a­tion paths (Com­mu­nic­a­tion­Paths).

Mul­ti­pli­cit­ies are noted as follows:

<mul­ti­pli­city> : <mul­ti­pli­cityr­angeh> [<ordername> , <un­qie­iden­ti­fi­err>]

The mul­ti­pli­city 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­vidu­al sises as ordered/unordered or unique/not unique.

You note some re­stric­ted 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 amongst 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.

Ste­reo­types define metaclass ex­ten­sions. According to the UML spe­cific­a­tion, they belong to the profiles. If a ste­reo­type describes ad­di­tion­al prop­er­ties of several meta­classes, it can only describe one metaclass instance at a time during runtime. Amongst the meta­classes, ste­reo­types play a role, since they can never stand alone. Ste­reo­types are always modelled with the clas­si­fi­er it enhances. You link the metaclass to the ste­reo­type by modeling an extension. 

UML defines some class ste­reo­types that extend your UML class diagrams. Six ste­reo­types are standard. Three ste­reo­types are often used, but not stand­ard­ised, and you can use them to convert the pattern “Model Present­a­tion Control” (MVC) into UML. The three non-standard ste­reo­types are:

• The entity (notation: <<Entity>>): The ste­reo­type Entity defines a class or an object. The re­spect­ive instance rep­res­ents 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 ste­reo­type, but assigns it to component diagrams by default. The fre­quently used notation does not list the spe­cific­a­tion. They model the entity as a circle resting on a short line.
   
• The boundary (notation: <<Boundary>>): The boundary is a ste­reo­type for a class or object. It roughly cor­res­ponds 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­res­en­ted as a circle with a line on the left that meets a vertical line.
   
• The control element (notation: <<Control>>): The control element rep­res­ents the same elements as the con­trol­ler under MVC. Classes or objects with this ste­reo­type model elements that co­ordin­ate system behaviour or control flows. In the UML standard, the ste­reo­type <<Focus>> performs similar tasks. You draw a control instance as a circle with an open arrowhead on the line.

These three ste­reo­types can also be drawn as a simple class. Note the name of the ste­reo­type in the rectangle. Modellers 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 stand­ard­ised ste­reo­types are suitable for class diagrams:

• Focus (<<Focus>>)
• Helper (<<Auxiliary>>)
• Type (<<Type>>)
• Im­ple­ment­a­tion class (<<Im­ple­ment­a­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­pli­citly defines sup­port­ing classes by entering into a de­pend­ency re­la­tion­ship with them (see “The Directed Re­la­tion­ship” below). If it uses helper classes, it defines them ex­pli­citly. The UML standard re­com­mends this ste­reo­type es­pe­cially for the design phase when you represent control flows between com­pon­ents or define the basic business logic.

The helper class usually acts in com­bin­a­tion with the focus class. It generally supports classes of crucial im­port­ance to the system. To this end, it carries out secondary control flows and defines sub­si­di­ary logic. It the helper class supports a focus class, the defin­i­tion is explicit. You im­pli­citly define the supported class during a de­pend­ency re­la­tion­ship.

The type class defines an area for business objects. It also specifies the object operators. The type ste­reo­type can have at­trib­utes and as­so­ci­ations. 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­plic­a­tion class builds a bridge between these two worlds. This ste­reo­type limits the UML class. It de­term­ines that an instance below it can only realise one class. The ap­plic­a­tion class can implement several different types. To suc­cess­fully 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 behaviour defined. However, physical at­trib­utes and as­so­ci­ations do not have to match.

Since the forms of class and metaclass are not different, the metaclass label indicates that it is the ste­reo­type metaclass. The instances of this class are them­selves classes. With this ste­reo­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­utes and op­er­a­tions. These are always static. Static at­trib­utes 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­res­pond­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 visualise a de­pend­ency 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­circle. This sym­bol­ises the interface. Note the name of the interface for both rep­res­ent­at­ives under the (semi­circle).

If a class inherits an interface to a sub­or­din­ate class, model the interface con­nec­tion to the sub­or­din­ate class or instance. Show the hier­arch­ic­al re­la­tion­ship with a cir­cum­flex (^), e.g. ^Interface 1.

Use the rect­an­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­pon­ents. 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­ises 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 ho­ri­zont­al lines in de­part­ments.

As with other classes, the enu­mer­a­tion reserves the upper sections for at­trib­utes 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­pon­ents 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­pon­ents. Thus, this element has no separate notation. However, its char­ac­ter­ist­ics 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­ations thereof – like the arrow.

The UML defin­i­tion for re­la­tion­ship sub­classes and instances has changed drastic­ally from UML 1 to UML 2. Ori­gin­ally, for example, there were semantic, struc­tur­al, and dir­ec­tion­al re­la­tion­ships. UML assigned three concrete re­la­tion­ships (as­so­ci­ation, re­stric­tion, and de­pend­ence) to the semantic re­la­tion­ships. Under UML 2, re­stric­tions are now packable elements, as­so­ci­ations define some sources as struc­tur­al and semantic re­la­tion­ships. This de­pend­ency now runs under dir­ec­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­classes: the directed re­la­tion­ship and the as­so­ci­ation.

The subtype com­pos­i­tion (composite ag­greg­a­tion) describes the re­la­tion­ship between a com­pos­i­tion of parts and a single part thereof. If the system deletes the whole (the com­pos­i­tion), it also destroys the in­di­vidu­al 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­pos­i­tion side (in the example: the “tree” instance). This page is also called the end of ag­greg­a­tion.

The second subtype of ag­greg­a­tion is shared ag­greg­a­tion (or just ag­greg­a­tion for short). This asym­met­ric re­la­tion­ship exists between a property and an instance that rep­res­ents a set of instances. The con­nec­tion should be direct. Otherwise, a com­pos­i­tion instance could be in­ter­preted as part of itself. This can happen if you model the de­pend­ency re­la­tion­ship cyc­lic­ally. The shared property can belong to several com­pos­i­tions. At the same time, their instance can exist in­de­pend­ently of the com­pos­i­tion. If the system deletes a com­pos­i­tion (or all of them) in this case, the sub-instance can continue to exist. Therefore, this re­la­tion­ship is con­sidered weak in com­par­is­on to com­pos­i­tion.

The as­so­ci­ation also offers a special feature: the as­so­ci­ation class. It is both the class and the re­la­tion­ship. This allows you to assign at­trib­utes to the as­so­ci­ation 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­it­ance. In this example, the dahlia class shares the capitulum-shaped in­flor­es­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­ist­ics.

Im­pli­citly, UML allows a multiple in­her­it­ance. This allows you to model several sub­classes that have both common and different su­per­classes. Al­tern­at­ively, there are several levels of gen­er­al­isa­tion. You can either display these re­la­tion­ships with the arrow notation or you interlace the sub­classes within their su­per­classes. To do this, you model all as­so­ci­ated sub­classes in the su­per­classes’ body.

The Gen­er­al­isa­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­il­ar­it­ies and may change together. A package is namespace, not a class. However, you can associate the gen­er­al­isa­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­isa­tion edge like this: {[isCov­er­ing Property] , [is­Dis­joint Property]} : [Powertyps name]. The isCov­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­fi­ers 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­tern­at­ively, it shows different per­spect­ives. The named elements in this de­pend­ency 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­classes: real­isa­tion and mani­fest­a­tion.

We have already mentioned real­isa­tion with regard to in­ter­faces. In­ter­faceR­eal­isa­tion is a spe­cific­a­tion of the real­isa­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 real­isa­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­tially replace instances of the contract clas­si­fi­er. In contrast to spe­cial­isa­tion, there is no struc­tur­al sim­il­ar­ity between elements of sub­sti­tu­tion. You note the sub­sti­tu­tion as a de­pend­ency edge (dashed arrow with open tip) in the class diagram and add the keyword <<sub­sti­tute>> to the edge.

The spe­cific­a­tion describes a re­la­tion­ship between an artifact and one of more model elements. UML defines artifacts as clas­si­fi­ers. They symbolise concrete, physical instances like archive folders. The char­ac­ter­ist­ic value means that an artifact executes a connected element directly. Con­versely, it can symbolise that elements are involved in the artifact’s creation. The char­ac­ter­ist­ic 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 ste­reo­types. Ste­reo­types belong to the UML profiles. If you want to extend an existing metaclass for a project, you define a profile for it. The ste­reo­type class is always used together with the metaclass, since a profile only changes what already exists or adds a ter­min­o­logy. Since UML 2.4.1, UML notes ste­reo­types with capital letters at the beginning. The standard ste­reo­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­form­a­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 spe­cific­a­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­pend­ency at instance level. Al­tern­at­ively, 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­pend­ency 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­pend­ency as an instance. This de­pend­ence char­ac­ter­ises some concrete re­la­tion­ships:

• <<use>>: One element uses another element, but the exact re­la­tion­ship between par­ti­cipants 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­ha­vi­our­al 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­vir­on­ment of the source operation, including su­per­or­din­ate clas­si­fi­ers.
• <<send>>: An operation is the source, the client. Your target is a signal. The de­pend­ency 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­term­ines the services that a clas­si­fi­er needs to perform its functions for its client. The de­pend­ency exists between clas­si­fi­er and interface. Read more about this in the “In­ter­faces” section.

Template binding is the last dir­ec­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 para­met­ers. These para­met­ers belong in the template signature. The signature de­term­ines the ordered set of para­met­ers within the template. If you model classes that do not have to have in­di­vidu­al prop­er­ties, you work more ef­fi­ciently when you use templates. However, if you want a class to have fixed para­met­ers, 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 para­met­ers from the template with valuable para­met­ers.