7-9 minutes<\/p>\n
The UML is a general-purpose, tool-supported, and standardized modeling language that is used in order to specify, visualize, construct and document all the elements of a wide range of system intensive processes. It promotes a use case driven, architecture-centric, iterative and incremental process, which is object-oriented and component-based. The UML is broadly applicable to different types of systems, domains, methods and processes, which is why it is such a popular and broadly used language.<\/p>\n
However, even though the UML is very well-defined, there might be situations in which you might find yourself wanting to bend or extend the language in some controlled way to tailor it to your specific problem domain in order to simplify the communication of your objective. This is where the UML extension mechanisms come in.<\/p>\n
The UML provides a standard language for writing software blueprints, but it is not possible for one closed language to ever be sufficient to express all possible nuances of all models across all domains across all time. For this reason, the UML is opened-ended, making it possible for you to extend the language in controlled ways.<\/p>\n
UML defines three extensibility mechanisms to allow modelers to add extensions without having to modify the underlying modeling language. These three mechanisms are:<\/p>\n
Stereotypes<\/p>\n
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building<\/p>\n
blocks that are derived from existing ones but that are specific to your problem. They are used for classifying or marking the UML building blocks in order to introduce newbuilding blocks that speak the language of your domain and that look like primitive, or basic, model elements.<\/p>\n
For example, if you are working in a programming language, such as Java or C++, you will often want to model exceptions. In these languages, exceptions are just classes, although they are treated in very special ways. Typically, you only want to allow them to be thrown and caught, nothing else. You can make exceptions first-class citizens in your models, meaning that they are treated like basic building blocks, by marking them with an appropriate stereotype, as for the class Overflow as shown in the Figure below:<\/p>\n
Another Example, an enumeration types, such as Coloroolean and Status, can be modeled as enumerations, with their individual values provided as attributes:<\/p>\n
A dependency can have a name, although names are rarely needed unless you want to use stereotypes to distinguish different flavors of dependencies. For example:<\/p>\n
A tagged value extends the properties of a UML building block, allowing you to create new information in that element\u2019s specification. They are properties for specifying keyword-value pairs of model elements, where the keywords are attributes. They allow you to extend the properties of a UML building block so that you create new information in the specification of that element. Tagged Values can be defined for existing model elements, or for individual stereotypes so that everything with that stereotype has that tagged value. It is important to mention that a tagged value is not equal to a class attribute. Instead, you can regard a tagged value as being metadata, since its value applies to the element itself and not to its instances.<\/p>\n
Graphically, a tagged value is rendered as a string enclosed by brackets, which is placed below the name of another model element. The string consists of a name (the tag), a separator (the symbol =), and a value (of the tag) as shown in the Figure below:<\/p>\n","protected":false},"excerpt":{"rendered":"