Using model-driven development for agile embedded apps: Part 4 - Enhancing agile design with modeling
Profiles
A UML Profile is a version of the UML specialized for some special purpose or domain. A profile is a coherent set of lightweight extensions to existing UML elements, inclusions and omissions from the UML standard, and additional elements. A profile must be consistent with the base definition of the UML. It is not allowed to extend the metamodel directly. It is considered an extension at the M1 level, although we find it more useful to consider at level M1.5. The extension mechanisms include:
- Stereotypes
- Tags
- Constraints
- Model libraries
A stereotype is a special “kind of” metaclass. Typically, it identifies an element that is used in a specific way, has additional associated metadata, or has additional rules for usage.
Stereotypes are normally identified by attaching the stereotype name in guillemets, but you are also allowed to add new notations. New notations can include both specialized graphics symbols for the stereotyped element as well as new diagrammatic types based on existing diagrams.
For example, Figure 2.14 shows a DoDAF Operational View-2 (OV-2) diagram, which is a stereotype of a class diagram. On it we see operational nodes and human operational nodes (stereotypes of instances) connected via needlines (stereotype of links). On the needlines, we see information exchanges (stereotypes of UML information flows). Underneath, the elements have valid UML specifications, but the stereotype allows you to cast the problem in the vocabulary of its domain.
Figure 2.14 DoDAF OV-2 diagram
Stereotypes often contain additional metadata, stored in tags. A tag is a name-value pair. Associating a set of tags with a stereotype means that any stereotyped element also contains those tags. For example, the same DoDAF profile has a stereotype constraint called a PerformanceParameter used for modeling different kinds of qualities of service. Performance parameters have tags as shown in Figure 2.15.
Other profiles have other tags. The UML Profile for Schedulability, Performance, and Time (SPT) has a large set of stereotypes with associated tags for capturing performance and schedulability metadata. Because the underlying model is UML, these can be exported in XMI to be used by performance analysis tools.
Constraints are a common way to assign values to tags. A constraint is a user-defined “well-formedness” rule—a rule that defines a criterion for a well-formed model element. Tags are often associated values in constraints. These constraints are usually declarative and can be validated only by testing the system, often on its ultimate target platform (PSM).
A model library is a set of predefined constructs, such as the SI definitions within the SysML profile that provide standard data types for typical measures of length, mass, time, current, temperature, and so on; these include units such as meters, kilograms, seconds, amperes, kelvins, and others.
Figure 2.15 Performance parameter tags
A profile is a coherent set of these extensions—stereotypes, tags, constraints, and model libraries—all tied to the underlying UML metamodel.
Common profiles in the real-time and embedded domain include:
- SysML—a profile of the UML intended to provide the modeling power of UML to systems engineers
- The UML Profile for SPT—a profile intended to provide standard ways of representing performance metadata for analysis
- Modeling and Analysis of Real-Time and Embedded Systems (MARTE)—a profile intended to replace and extend the SPT profile to cover other concerns of embedded systems beyond just performance (not yet released; currently in finalization)
- UML Profile for DoDAF and MoDAF (UPDM)—a profile intended to provide a standard means of representing DoDAF (U.S.) and Ministry of Defense Architecture Framework (UK) models in the UML (not yet released; currently in finalization)
- UML Testing Profile—a profile intended to provide ways of representing test vectors, test suites, and test fixtures to facilitate the testing of UML models and to bring the expressive power of UML to the testing domain.
Loading comments... Write a comment