Visualizing Paths

Overview

The Model Visualizer allow the user to define a custom visualization using Paths.

Demonstration

Watch the Video

Defining Paths

Paths are defined using the following property on a Visualization:

RhapsodyPowerPack.Attribute.Path

There are several ways the helper tries to obtain the Visualization or Visualization Instance, in order of priority:

· If the helper is launched from a Visualization or Visualization Instance then that Visualization is used.

· If the starting model element has an incoming <<visualizes>> dependency from a Visualization or Visualization Instance, then that Visualization is used.

· If the starting model element is a new term then that stereotype is checked for an incoming <<visualizesType>> dependency from a Visualization or Visualization Instance and if found, that Visualization is used.

If multiple Visualizations have been connected (and the helper is not being launched directly from one of them) then a dialog is presented allowing the selection of the Visualization to use:

These options allow flexibility without the need to define potentially multiple Visualizations / multiple <<visualizes>> when you want to visualize the same thing on multiple elements. For example, you can define the path once and associate it with a new term stereotype, then you can launch the path visualizer from any element of that type.

Visualization Templates

Visualization Templates are an automation concept and only used to allow other tools to automate the creation of Visualizations. Visualization Templates may only be added to Visualization Libraries. Visualization Templates allow the user to define a Visualization without defining the elements to which it applies. In addition to the Path, Node Labels and Plugin Properties that a Visualization has, Visualization Templates have one additional property: AutoCreateForTypes. This is a comma-separated list of user defined metaclasses (e.g. Port, ProxyPort, Block).

This is then used by other tools (such as the Compare Models tool which only looks for templates in Visualization Libraries that are in Profiles) to generate Visualizations and add <<visualizes>> dependencies to elements of those types. See Compare Models

Path Language

Paths are defined using a subset and superset of the Context Pattern language. Supported concepts are described below. The Visualization defines the starting point for the Path and should not be included in the pattern, for example if the starting point is a Package, then the pattern does not need to start with Package unless you want to capture child packages.

Paths may be written manually or using the Path Editor.

Tokens

Just as in context patterns, the language is made up of comma-separated tokens. Each token can return a set of model elements. The default relationship between token sets is ownership. For example:

Block,Operation

Token types may be base UML terms or new terms. An OR condition may be specified using a pipe:

Block|InterfaceBlock,Operation

Strict Matching

By default, tokens match either their metaclass or user defined metaclass (that is new terms) so for example the following pattern:

Class

would also match Blocks, Interface Blocks and every other new term based on Class. Adding an exclamation mark to the end makes that match strict so for example:

Class!

Would only match Classes.

Relationship Keywords

Relationship keywords all end with a colon, this is to distinguish between a keyword and a possible model element token since model element types in Rhapsody cannot have colons in their names. For example, you could have a new term stereotype called type, but you cannot have a new term stereotype called type:

Provided / Required Interfaces

These keywords may be used to obtain the interfaces provided / required by a ‘standard’ UML port.

Block,Port,requiredInterface:

Block,Port,providedInterface:

In addition a special keyword will obtain both (there is no way to distinguish between them on the visualization but identifying both paths may be useful in some circumstances such as impact analysis)

Block,Port,providedOrRequiredInterface:

Type

The keyword type: may be used as a token to get the type* of the previous token:

Block,ProxyPort,type:

*If the previous token was an event reception then the event is returned.

Owner

The keyword owner: captures the owning model element of the previous token:

Operation,owner:

Tag Values

The keyword value: may be used as a token to get the model elements from the previous token (if that token was a tag typed by model element)

Block,Tag.name(owners),value:

References

The keyword references: captures references of the previous token.

Block,Operation,references:

Adding a metaclass constraint (see below) allows the capture to be filtered by the type of the reference element:

Block,Operation,references:.metaclass(Allocation)

Block,Operation,references:.metaclass(Comment|Allocation)

Block,Operation,references:.metaclass(Allocation).owner(UseCase)

Dependency Targets

There are two ways to specify the target of a dependency:

Dependency:

Means: get the target of the dependency instead of the dependency (if you only want the element at the end of the dependency). Dependency may also be a new term based on dependency.

to:

Means: get the target of the previous token if that token was a Dependency (allows capturing both the Dependency and its target.

The type of dependent element may be filtered by adding a type-list after the colon

Dependency:UseCase

Note that the keyword colon to detect a target is exclusive to Dependencies, for flows instead use:

Flow,to:

Note also that not all model elements may own Flows, for example if you draw a Flow from a port to another element then the owner of the Flow is the owning Class/Block which means that Port,Flow,to: will not work (the Flow is not owned by the Port). In such cases you can use references: filtered by metaclass or (more robust) write your own plugin to reliably obtain the flows.

Examples:

UseCase,Refinement

UseCase,Refinement,to:

Dependency/flow Sources

The keyword from: captures to source of a dependency/flow so for example:

Block,Operation,references.metaclass(Allocation),from:

Dependents

The keyword dependent: may be used to get elements that have (any) dependency to the previous token.

Block,Operation,dependent:

Constraints may be applied to the dependent element:

Block,Operation,dependent:.metaclass(Comment|UseCase)

Hiding Tokens

The keyword {hide} at the start of a token will traverse that path in the model but the elements captured by the token will be hidden from the graph, allowing you to ‘skip’ a step:

Block,{hide}ProxyPort,type:

Negating Tokens

Adding an exclamation mark ! character before a token type-list means “invert that filter”. For example:

Block,!Operation|ValueProperty

Means: all nested elements except Operations or Value Properties

Negation does not apply to relationship tokens, for example: !references: (‘not references’) just doesn’t mean anything.

Constraints may also be negated (see below)

Constraint Keywords

Constraints start with a period character. Constraints may be inverted by adding an exclamation mark ! before the parenthesis

Name Constraint

The suffix .name([name_pattern]) may be used to filter where [name_pattern] is a regular expression:

Block,Tag.name(priority) : get tags named priority

Block,Tag.name(priority|owners) : get tags named priority or owners

Block,Tag.name!(prority) : get all tags not named priority

Block,Tag.name!(prority|owners) : get all tags not named priority or owners

Block,Tag.name(^tag.*),value: get all tags whose name starts with ‘tag’

Block,Tag.name!(^tag.*),value: get all tags whose name does not start with ‘tag’

Alternatively negative look ahead regular expression may be used, for example:

Block,Tag.name(^(?!(?:priority|owners)).*),value: get all tags not named priority or related

Owner Constraint

The suffix .owner([pattern]) may be used to filter where [pattern] is a regular expression:

Block,Operation,references:.owner(Comment) : get all references owned by a Use Case

Block,Operation,references:.owner!(Comment) : get all references owned by a Use Case

Stereotype Constraint

The suffix .stereotype([name_pattern]) may be used to filter elements that have a named stereotype where [name_pattern] is a regular expression:

Block,Operation.stereotype(directedFeature) : get Operations that are stereotyped <<directedFeature>>

Block,Operation.stereotype!(directedFeature) : get Operations that are not stereotyped <<directedFeature>>

Multiple Constraints

Multiple constraints may be used in any order:

Block,Operation,references:.owner!(UseCase).stereotype!(extend) : get references not owned by Use Cases that have the stereotype <<extend>>

Block,Operation,references:.owner!(UseCase).stereotype!(extend) : get references not owned by Use Cases that do not have the stereotype <<extend>>

Plugins

User-supplied java code may be used as a token. See Visualizations for details of how to define these methods and make them available to the Path. See Path Editor for details on how to specify these as model elements if that editor is being used to edit Paths.

Plugin Tokens

The syntax for plugin tokens is:

pluginMethod:methodName

For example:

Class,pluginMethod:nested,Dependency:

Optionally the name of the JAR file may be used as an additional qualifier (without it the Model Visualizer checks all plugins loaded through Visualizations for such a method instead of just that JAR).

pluginMethod:JARName:methodName

For example:

Class,pluginMethod:NestedElementsPlugin:nested,Dependency

Path Inheritance

Visualizations may inherit a path from other Visualizations allowing re-use. In the simple example below if the Visualizer was launched in path mode from TypesOfFeatures then the path used would be:

Class,Attribute|Operation,type: