Zicomi Systems Logo
contact us  |  your privacy
Company
Services
Products
Support
Resources
  OMG Standards
OMG Logo
UML Element Description
Send Dependency
Send Dependency    
A send dependency is a type of usage dependency that exists between an operation in a classifier and a signal. It signifies that the operation (tail end) can send the signal. (arrowhead end).
Sending Signal
Sending Signal    
A sending signal is a representation of an action that sends a signal. The action has one incoming transition and one outgoing transition. The signal is always sent asynchronously; the object receiving the signal may be shown, with a dashed arrow drawn from the pentagon to the object. The signal signature is written inside the pentagon.
Sequence
Sequence    
A value of sequence specified for the property string of an association end indicates that the collection of instances are an ordered bag. This means that the collection is ordered but can contain duplicated instances. It does not specify the basis for the order.
Shallow History
Shallow History    
A shallow history is a kind of pseudostate that acts as marker or placeholder in a composite state. It represents the state or condition of the modeled element at the time it was last exited. It is not a state itself but a diagrammatic representation or marker for the "condition" of the composite state down to a single level, at the time it was last exited.
State
State    
A state is a condition or phase, in the lifetime of a classifier instance, during which it can be observed for a finite amount of time and has a particular condition.
State Invariant
State Invariant    
A state invariant is an interaction fragment that places a constraint on the state of the lifeline on which it is located. The lifeline represents a set of instances and the constraint applies to these instances. It is evaluated at runtime and if the state invariant evaluates to false the message is considered to be invalid.
Stop
Stop    
A stop is used to denote that a participant is destroyed during the lifetime represented by the diagram. The lifeline is ended indicating that the participant no longer exists; the dashed line ends in a small cross positioned at the end of the lifeline. A participant may stop itself.
Stream Expansion Region
Stream Expansion Region    
When the value of stream is specified for the mode of an expansion region, the region executes a single time. An expansion region is a type of activity group that contains one or more actions. These actions are executed multiple times depending on the number of elements in the input collection that arrive at one or more expansion nodes positioned on the edge of the region. The results of the actions may be placed in one or more expansion nodes acting as outputs.
Strict Sequencing (Combined Fragment)
Strict Sequencing (Combined Fragment)    
A strict sequencing interaction operator (signified by the value of strict) defines a combined fragment where the sequence of the event occurrences must occur in the order they are defined regardless of which lifeline is involved.
Subject (System) Boundary
Subject (System) Boundary    
A subject (system) boundary is a type of partition that represents the boundary between the thing you are representing with the use cases (inside the boundary) and the actors (outside the boundary). Its most typical usage is the boundary of an entire system. Use cases can be used to represent subsystems and classes and so the boundary may be more specific than an entire system. A package with a stereotype topLevel can be used as a boundary and name space within the use case model to denote the same thing as the use case boundary.
Submachine State
Submachine State    
A submachine state is semantically equivalent to a composite state but adds the mechanism for the submachine state to be reused in different contexts through the provision of entry and exit point connection references. Entry and exit to the submachine state is always through the connection point references which are part of the submachine state definition. A state is not permitted to have both regions and submachine states.
Subsets
Subsets    
A value of subsets specified for the property string of an association end indicates that the collection does not contain all the available instances defined by the named property. This is an application of the mathematical concept of subset, which means that every instance at the association end marked as subsets, must exist in the parent property.
Subsystem
Subsystem    
A subsystem is a grouping or package of model elements that has operations and interfaces. It has the characteristics of a package and a classifier. While a subsystem is a behavior element, it has no intrinsic behavior of it s own, the behavior is provided by the elements in the realization compartment of the subsystem.
Swimlanes
Swimlanes    
Swimlanes divide or partition activity diagrams into a number of "lanes", which typically organize the diagram into a number of regions of responsibility. Each lane may have a name, which signifies the responsibility or governance of the elements that lie within it.
Synchronous Message
Synchronous Message    
A synchronous message is a message that pauses the flow of execution within the calling instance. The instance waits until the message is returned.
Synchronous Message (State)
Synchronous Message (State)    
A synchronous message (state) is a visual synonym of a synchronous message. It adds no additional semantics; it is simply an example of the synchronous message adapted for use on a timing diagram. This usage of the synchronous message has the same form as a synchronous message used on other interaction diagrams: a solid line with a solid arrowhead directed from one lifeline to another (possibly reflexive). It is listed separately because the message ends give it a different appearance from other examples. The points on the execution occurrence, where the synchronous messages end, represent event occurrences and are important events in a lifeline. There is a single form of presentation in the three different types of interaction diagrams and the two different presentations of the timing diagram.
Synchronous Message (Value)
Synchronous Message (Value)    
A synchronous message (value) is a visual synonym of a synchronous message. It adds no additional semantics; it is simply an example of the synchronous message adapted for use on a timing diagram. This usage of the synchronous message has the same form as a synchronous message used on other interaction diagrams: a solid line with a solid arrowhead directed from one lifeline to another (possibly reflexive). It is listed separately because the message ends give it a different appearance from other examples. The points on the execution occurrence, where the synchronous messages end, represent event occurrences and are important events in a lifeline. There is a single form of presentation in the three different types of interaction diagrams and the two different presentations of the timing diagram.
Terminate
Terminate    
A terminate is a kind of pseudostate that stops the execution of the enclosing state machine. It can have one or more incoming flows but no outgoing flows. While a final state signifies that execution within the enclosing region is complete, a terminate ends the execution of the entire state machine including all regions contained within the machine.
Time Constraint
Time Constraint    
A time constraint is a type of interval constraint that specifies that one or more model elements must conform to a restriction specified by a time interval. A time constraint is not the time interval itself but a constraint, which associates the interval with one or more elements specifying how it restricts the elements, time semantics.
Timing Ruler
Timing Ruler    
A timing ruler is a graduated device for indicating the passage of time on a timing diagram. The graduations are called ticks and are typically placed on the lower edge of the diagram frame. Time runs from left to right. The scale and time units (ticks) depend upon what the diagram represents and may be sub-second units such as milliseconds or larger time divisions such as hours, days, months or even years.
Trace Dependency
Trace Dependency    
A trace dependency is an abstraction dependency between a supplier and a client that indicates that one or more elements in one model represent an analogous concept in another model. Its meaning depends on the relationship between the models.
Transition
Transition    
A transition is an element relating two vertices in a state machine that represents the movement of an instance in the source state changing or "transitioning" into the instance in the second state. The transition takes place when an event occurs and the guard condition evaluates to TRUE
Union
Union    
A value of union specified for the property string indicates that the association end is derived by the union of the subsets with the name specified. This mechanism allows the classifier at the association end marked with union to specify its instances based on the union of its subsets. This is an application of the mathematical concept of union of sets and subsets. This implies that the collection is a set and cannot be a bag since a union results in a set, which means it cannot have duplicate elements.
Unordered
Unordered    
The value unordered for the ordering property signifies that instances of the classifiers at the target end of the association are not ordered. This is the default value for this property and if a value for the property is not specified then the value by default is unordered. The multiplicity at the target end must be greater than one since a value of one or less would specify a set with one or less elements, for which ordering would be meaningless.
Usage
Usage    
A usage is a type of dependency and therefore a directed relationship between one or more clients (tail end) and one or more suppliers (arrowhead end). The elements at the tail end (clients) require the elements at the arrowhead end (supplier) in some way. This requirement may be that the elements need the other elements to be able to perform their function in a running system. It may also be an implementation dependency where only one set of elements exists in the running system and the other set were needed as part of the implementation. A usage can be used as an element in its own right, although it has a number of stereotypes that make its application more precise.
Use Case
Use Case    
A use case represents the behavior of the entity, describing the interaction between the actors and the use case in a series of actions, with possible variants. It describes the value the entity provides to the actor with which it communicates. The use case never describes "how" the value is achieved, just "what" the value is.
Use Case Generalization
Use Case Generalization    
Use case generalization is a relationship between two use cases indicating that the child (tail end) is more specific than the parent (arrow head end).
Use Case Generalization (tree)
Use Case Generalization (tree)    
Use case generalization can be represented in a single path (tree). When a number of generalization relationships exist and the children have the same parent the lines can be combined into a single path and drawn with a tree. This doesn't change the semantics of the individual relationships; it is simply a more compact and convenient style for representing the relationships. A tree that has three branches represents three discrete and separately defined generalization relationships.
Use Case Instance (Scenario)
Use Case Instance (Scenario)    
An use case instance is a specific instance of a use case. It represents the behavior of the subject, describing a particular instance of the interaction between the actors and the use case. A use case instance communicates with one or more instances of actors sending message instances to achieve the value represented by the use case instance. The use case instance never describes "how" the value is achieved, just "what" the value is.
Use Case Package
Use Case Package    
A use case package is a package that is used to partition or group, use cases, actors, relationships, diagrams or other use case packages.
Unified Modeling Language and UML are either registered

trademarks or trademarks of Object Management Group, Inc. in the

United States and/or other countries.