General UML Guidelines
Compartment Elements
Parameter (Parameter)
General UML Guidelines
Compartment Elements
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.
The name of the item.
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.
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.
A textual description of the element.
The type of the element.
Specifies a ValueSpecification that represents a value to be used when no argument is supplied for the Parameter.
Specifies the lower and upper bound of the multiplicity interval.
Determines where the item appears within different Namespaces within the overall model, and its accessibility.
Indicates whether a parameter is being sent into or out of a behavioral element.
Tells whether an output parameter may emit a value to the exclusion of the other outputs.
For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered.
Tells whether an input parameter may accept values while its behavior is executing, or whether an output parameter post values while the behavior is executing.
For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique.
Specifies the effect that the owner of the parameter has on values passed in or out of the parameter.
An element of one of the following kinds:
An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions.
An interaction is a unit of behavior that focuses on the observable exchange of information between connectable elements.
An behavior with implementation-specific semantics.
An operation is a behavioral feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behavior. An operation may invoke both the execution of method behaviors as well as other behavioral responses.
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.
A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response.
The details of handling a signal are specified by the behavior associated with the reception or the classifier itself.
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.
A template parameter exposes a parameterable element as a formal template parameter of a template.
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.
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).
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.
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.
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.
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.
Model Guidelines generated by ![]() ![]() | Tuesday, 14 February 2017 15:17 |