Rules

• Name: The value can be anything.

  The name of the item.

• Keywords: The value can be anything.

  A keyword is a lightweight variant of a stereotype to extend the semantics of a model element. As opposite of stereotypes, keywords does not have do be defined in a profile.

  If several keywords are given, they should be separated by commas.

• Stereotypes: The value can be anything.

  A stereotype defines how a model element may be extended, and enables the use of platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass.

  Stereotypes should be given in the format 'profile::stererotype'. Stereotypes should be separated by commas.

• Documentation: The value can be anything.

  A textual description of the element.

• Visibility: The value shall be a valid literal from the enumeration Visibility Kind.

  Determines where the item appears within different Namespaces within the overall model, and its accessibility.

• Abstract: The value shall be non-empty.

  If true, then the behavioral feature does not have an implementation, and one must be supplied by a more specific element.

  If false, the behavioral feature must have an implementation in the classifier or one must be inherited from a more general element.

• Leaf: The value shall be non-empty.

  Indicates whether it is possible to further specialize an item. If the value is true, then it is not possible to further specialize the item.

• Static: The value can be anything.

  Specifies whether this feature characterizes individual instances classified by the classifier (false) or the classifier itself (true).

• Concurrency: The value shall be a valid literal from the enumeration Call Concurrency Kind.

  Specifies the semantics of concurrent calls to the same passive instance (i.e., an instance originating from a class with isActive being false).

  Active instances control access to their own behavioral features.

• Signal: The value can be anything.

  The signal that this reception handles.

An element of one of the following kinds:

• Activity (Activity)

  An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions.

• Class (Class)

  A class describes a set of objects that share the same specifications of features, constraints, and semantics.

  A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).

  A class may also specify which signals the instances of this class handle. A class has the capability to have an internal structure and ports. Class has derived association that indicates how it may be extended through one or more stereotypes. Stereotype is the only kind of metaclass that cannot be extended by stereotypes.

• Component (Component)

  A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

  In the namespace of a component, all model elements that are involved in or related to its definition are either owned or imported explicitly. This may include, for example, use cases and dependencies (e.g. mappings), packages, components, and artifacts.

• Device (Device)

  A device is a physical computational resource with processing capability upon which artifacts may be deployed for execution.

  Devices may be complex (i.e., they may consist of other devices).

• Execution Environment (Execution Environment)

  An execution environment is a node that offers an execution environment for specific types of components that are deployed on it in the form of executable artifacts.

• Interaction (Interaction)

  An interaction is a unit of behavior that focuses on the observable exchange of information between connectable elements.

• Interface (Interface)

  An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations.

  An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract.

  The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and post-conditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

  Interfaces may include receptions (in addition to operations). Since an interface specifies conformance characteristics, it does not own detailed behavior specifications. Instead, interfaces may own a protocol state machine that specifies event sequences and pre/post conditions for the operations and receptions described by the interface.

• Node (Node)

  A node is computational resource upon which artifacts may be deployed for execution. Nodes can be interconnected through communication paths to define network structures.

• Opaque Behavior (Opaque Behavior)

  An behavior with implementation-specific semantics.

• Protocol State Machine (Protocol State Machine)

  A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called in which state and under which condition, thus specifying the allowed call sequences on the classifier's operations.

  A protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations which carry the transitions. In this manner, an instance lifecycle can be created for a classifier, by specifying the order in which the operations can be activated and the states through which an instance progresses during its existence.

• State Machine (State Machine)

  State machines can be used to express the behavior of part of a system.

  Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine.

• Stereotype (Stereotype)

  A stereotype defines how an existing metaclass may be extended, and enables the use of platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass.

Rules

• Arbitrary number of elements of the following kinds:
  • Constraint (Constraint)

    A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.

  • Parameter (Parameter)

    A parameter is a specification of an argument used to pass information into or out of an invocation of a behavioral feature. Parameters are allowed to be treated as connectable elements. Parameters have support for streaming, exceptions, and parameter sets.

Rules

• Arbitrary number of elements of the following kinds:
  • Activity (Activity)
  • Actor (Actor)
  • Artifact (Artifact)
  • Association (Association)
  • Class (Class)
  • Collaboration (Collaboration)
  • Communication Path (Communication Path)
  • Component (Component)
  • Data Type (Data Type)
  • Deployment Specification (Deployment Specification)
  • Device (Device)
  • Enumeration (Enumeration)
  • Execution Environment (Execution Environment)
  • Extension (Extension)
  • Information Item (Information Item)
  • Interaction (Interaction)
  • Interface (Interface)
  • Node (Node)
  • Opaque Behavior (Opaque Behavior)
  • Primitive Type (Primitive Type)
  • Protocol (Protocol)
  • Protocol State Machine (Protocol State Machine)
  • Signal (Signal)
  • State Machine (State Machine)
  • Stereotype (Stereotype)
  • Use Case (Use Case)

Rules

• Arbitrary number of elements of the following kinds:
  • Abstraction (Abstraction)

    An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints.

  • Dependency (Dependency)

    A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.

    This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).

  • Element Import (Element Import)

    An element import identifies an element in another package, and allows the element to be referenced using its name without a qualifier.

  • Information Flow (Information Flow)

    An information flow specifies that one or more information items circulates from its sources to its targets.

    Informationflows require some kind of information channel for transmitting information items from the source to the destination. An information channel is represented in various ways depending on the nature of its sources and targets. It may berepresented by connectors, links, associations, or even dependencies.

    For example, if the source and destination are partsin some composite structure such as a collaboration, then the information channel is likely to be represented by aconnector between them. Or, if the source and target are objects (which are a kind of instance specification), they may berepresented by a link that joins the two, and so on.

  • Package Import (Package Import)

    A package import is a relationship that allows the use of unqualified names to refer to package members from other namespaces.

  • Realization (Realization)

    Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

  • Substitution (Substitution)

    A substitution is a relationship between two classifiers signifies that the substituting classifier complies with the contract specified by the contract classifier. This implies that instances of the substituting classifier are runtime substitutable where instances of the contract classifier are expected.

  • Usage (Usage)

    A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. A usage is a dependency in which the client requires the presence of the supplier.

• Can be the Target of elements of the following kinds:
  • Abstraction (Abstraction)
  • Dependency (Dependency)
  • Information Flow (Information Flow)
  • Realization (Realization)
  • Substitution (Substitution)
  • Usage (Usage)