Table of Contents

C.1 StandardProfileL2

Name	Language Unit	Applies to	Description

«auxiliary»	Classes::Kernel	Class	A class that supports another more central or fundamental class, typically by implementing secondary logic or control flow. The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship. Auxiliary classes are typically used together with Focus classes, and are particularly useful for specifying the secondary business logic or control flow of components during design. See also: «focus».
«call»	Classes:: Dependencies	Usage	A usage dependency whose source is an operation and whose target is an operation. The relationship may also be subsumed to the class containing an operation, with the meaning that there exists an operation in the class to which the dependency applies. A call dependency specifies that the source operation or an operation in the source class invokes the target operation or an operation in the target class. A call dependency may connect a source operation to any target operation that is within scope including, but not limited to, operations of the enclosing classifier and operations of other visible classifiers.
«create»	Dependencies	Usage	A usage dependency denoting that the client classifier creates instances of the supplier classifier.
«create»	Classes::Kernel	BehavioralFeatur e	Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature.
«derive»	Classes:: Dependencies	Abstraction	Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type. A derived dependency specifies that the client may be computed from the supplier. The mapping specifies the computation. The client may be implemented for design reasons, such as efficiency, even though it is logically redundant.
«destroy»	Classes::Kernel	BehavioralFeatur e	Specifies that the designated feature destroys an instance of the classifier to which the feature is attached. May be promoted to the classifier containing the feature.
«document»	Deployments:: Artifacts	Artifact	A generic file that is not a «source» file or «executable». Subclass of «file».
«entity»	Components:: BasicComponents	Component	A persistent information component representing a business concept.
«executable»	Deployments:: Artifacts	Artifact	A program file that can be executed on a computer system. Subclass of «file».
«file»	Deployments:: Artifacts	Artifact	A physical file in the context of the system developed.


«focus»	Classes::Kernel	Class	A class that defines the core logic or control flow for one or more auxiliary classes that support it. Support classes may be defined explicitly using Auxiliary classes or implicitly by dependency relationships. Focus classes are typically used together with one or more Auxiliary classes, and are particularly useful for specifying the core business logic or control flow of components during design. See also: «auxiliary».
«framework»	Classes::Kernel	Package	A package that contains model elements that specify a reusable architecture for all or part of a system. Frameworks typically include classes, patterns, or templates. When frameworks are specialized for an application domain they are sometimes referred to as application frameworks.
«implement»	Components:: BasicComponents	Component	A component definition that is not intended to have a specification itself. Rather, it is an implementation for a separate «specification» to which it has a Dependency .
«implementation Class»	Classes::Kernel	Class	The implementation of a class in some programming language (e.g., C++, Smalltalk, Java) in which an instance may not have more than one class. This is in contrast to Class, for which an instance may have multiple classes at one time and may gain or lose classes over time, and an object (a child of instance) may dynamically have multiple classes. An Implementation class is said to realize a Classifier if it provides all of the operations defined for the Classifier with the same behavior as specified for the Classifier's operations. An Implementation Class may realize a number of different Types. Note that the physical attributes and associations of the Implementation class do not have to be the same as those of any Classifier it realizes and that the Implementation Class may provide methods for its operations in terms of its physical attributes and associations. See also: «type».
«instantiate»	Classes:: Dependencies	Usage	A usage dependency among classifiers indicating that operations on the client create instances of the supplier.
«library»	Deployments:: Artifacts	Artifact	A static or dynamic library file. Subclass of «file».
«metaclass»	Classes::Kernel	Class	A class whose instances are also classes.


«modelLibrary»	Classes::Kernel	Package	A package that contains model elements that are intended to be reused by other packages. Model libraries are frequently used in conjunction with applied profiles. This is expressed by defining a dependency between a profile and a model library package, or by defining a model library as contained in a profile package. The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is analogous to a class library in some programming languages. When a model library is defined as a part of a profile, it is imported or deleted with the application or removal of the profile. The profile is implicitly applied to its model library. In the other case, when the model library is defined as an external package imported by a profile, the profile requires that the model library be there in the model at the stage of the profile application. The application or the removal of the profile does not affect the presence of the model library elements.
«process»	Components:: BasicComponents	Component	A transaction based component.
«realization»	Classes::Kernel	Classifier	A classifier that specifies a domain of objects and that also defines the physical implementation of those objects. For example, a Component stereotyped by «realization» will only have realizing Classifiers that implement behavior specified by a separate «specification» Component. See «specification». This differs from «implementation class» because an «implementation class» is a realization of a Class that can have features such as attributes and methods that are useful to system designers.
«refine»	Classes:: Dependencies	Abstraction	Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design. The mapping specifies the relationship between the two elements or sets of elements. The mapping may or may not be computable, and it may be unidirectional or bidirectional. Refinement can be used to model transformations from analysis to design and other such changes.
«responsibility»	Classes::Kernel	Usage	A contract or an obligation of an element in its relationship to other elements.
«script»	Deployments:: Artifacts	Artifact	A script file that can be interpreted by a computer system. Subclass of «file».
«send»	Classes:: Dependencies	Usage	A usage dependency whose source is an operation and whose target is a signal, specifying that the source sends the target signal.
«service»	Components:: BascComponents	Component	A stateless, functional component (computes a value).
«source»	Deployments:: Artifacts	Artifact	A source file that can be compiled into an executable file. Subclass of «file».


«specification»	Classes::Kernel	Classifier	A classifier that specifies a domain of objects without defining the physical implementation of those objects. For example, a Component stereotyped by «specification» will only have provided and required interfaces, and is not intended to have any realizingClassifiers as part of its definition. This differs from «type» because a «type» can have features such as attributes and methods that are useful to analysts modeling systems. Also see: «realization»
«subsystem»	Components:: BasicComponents	Component	A unit of hierarchical decomposition for large systems. A subsystem is commonly instantiated indirectly. Definitions of subsystems vary widely among domains and methods, and it is expected that domain and method profiles will specialize this construct. A subsystem may be defined to have specification and realization elements. See also: «specification» and «realization».
«trace»	Classes:: Dependencies	Abstraction	Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. Since model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.
«type»	Classes::Kernel	Class	A class that specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects. However, it may have attributes and associations. Behavioral specifications for type operations may be expressed using, for example, activity diagrams. An object may have at most one implementation class, however it may conform to multiple different types. See also: «implementationClass».
«utility»	Classes::Kernel	Class	A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are classscoped.