It is imperative that the modeling tool provide the guidance necessary, making the conforming path the easiest to travel. Using a tool as generic as UML does not inherently provide that assistance. Fortunately, the architects of UML provided a means to extend UML so that it can fit specific needs. These extensions are stereotypes and tagged values which can be organized into UML profiles.
Stereotypes
Stereotypes provide a mechanism to refine the meaning or context of a given model element. They are notated by putting guillemets around the name of the stereotype, e.g. «entity». UML defines three analysis stereotypes that help provide additional meaning to classes. A class with an «entity» stereotype is something that is concerned more about data and the control of that data than it is about process. A class stereotyped as «control» is more concerned about process. A «boundary» class represents something at the edge of the system being modeled, which interacts with things external to the system.
Stereotypes can also be created by the designer. The concept of a control mentioned above is pretty general. To refine it for an open distributed processing environment using an n-tier approach, the following stereotypes can be introduced to indicate the type of interaction provided by the control object:
«Service» - a control that maintains the state of an interaction only within the context of a single invocation.
«Session» - a control that maintains the state of an interaction through multiple invocations with the initiation and termination of the session controlled by the client.
To place a control into the proper tier in a platform independent context, the previous stereotypes can be further refined to:
«Presentation Session» - a «Session» that controls the interaction with the user.
«Work Session» - a «Session» that controls the sequencing of actions required to perform the work of use case realization. A Work Session can interact with «Presentation Sessions», «Business Services», «IT Services», and other addressable components within its deployment space.
«Business Service» - a «Service» that provides access to and control over reusable data and processes by interacting with enterprise resources such as databases and back end applications as well as extended enterprise resources, e.g. connections to trading partners.
«IT Service» - a «Service» that provides aspect functionality such as logging, security, service discovery, transaction control, etc.
Now, instead of simply seeing a class with a name, you can get the full context of what type of processing the class should do as well as its location within the distribution tiers. Furthermore, you can decide what interactions among the stereotyped classes will be permitted. You may not want a «Presentation Session» to directly invoke a «Business Service» but rather have the «Work Session» make that call. Ultimately, these platform independent stereotypes can be mapped to components stereotyped for the platform specific model to be created. A particular «Work Session» may be mapped to a «JSP» for one platform or to a «ASP» on another. Pattern generated transformations can automate this process to a large degree. In fact, there are a number of UML profiles that are available for different domains, e.g. for EJBs, for business process modeling, etc.
Stereotypes can be used for model elements other than classes. For example, you can add a stereotype to a dependency connection. In the Application Architecture - Functional view, we have application components interacting with each other. These interactions demonstrate dependencies between the application components. We further refine the interactions (the dependencies) based on the conceptual type of interaction, namely «Data Flow», «Shared DB», «Sync Request», or «Async Request». These too can be transformed into the underlying technology structures of a platform specific model.
The following diagram shows the functional view of the Player Rating Application from the reference architecture model in . You can see the various stereotypes discussed above within the diagram.
Tagged Values
Tagged values allow you to capture information about a model element that UML does not provide. For example, you may want to know the beginning and termination service dates for a given «Application». You may want to capture the various service level requirements for a «Business Service», e.g. average and maximum execution times. Tagged values come in a name/value pair. You provide the name of the tag and then the value.
. You can see the various stereotypes discussed above within the diagram.