All backends have a physical definition in the deployment and component diagrams. In the deployment diagram, the technical information for each backend like host name, protocol, etc. is defined. This is advantageous, because the information is hidden from the activity diagrams. Access to backends within activity diagrams can be established by using aliases. An alias links the physical definition of the backend in the deployment diagram with the logical definition of the backend adapter in the activity diagram. In the activity diagram, the alias is defined by specifying the tagged value alias on an action state, which is stereotyped as backend adapter. The alias is also specified on dependencies in deployment and component diagrams to establish the link to the activity diagram. For more details, please refer to chapter Aliases.

In cases where you need to reference information, which is located in the deployment diagram and is needed in activity diagrams, the strict separation of the logical view and the physical view needs to be softened. Suppose you want to access a Web Server to request a specific Web page. Protocol, host, and method are static information that is defined in the deployment diagram. The URL, which is composed of protocol, host name, and path may contain an id as a dynamic parameter that is known only at runtime. To build such a Service, you would define the static information in the deployment diagram. This information can be accessed from the activity diagram, and can be concatenated with the runtime value of the id.

In activity diagrams, data that reside in deployment diagrams can be accessed with deployment macros. The deployment macros are used within action scripts of activity diagrams. Aliases help to specify, which data of which backend has to be retrieved. The tagged value alias needs to be defined on the action state that contains the deployment macros. In this case, the action state needs not to be stereotyped as backend adapter necessarily.