To start a generation operation, you can either right-click a diagram or a model element; then select one of two commands from the UPIA modeling menu:
The operational domain in an architecture model contains the concept of a connection between two logical operational nodes that represents information being passed or exchanged to accomplish their respective capabilities. In the operational domain, these connections are called information exchanges. Each exchange has one or more conveyed information elements. In addition, the direction of each exchange identifies the producer and consumer of the passed information. In the system domain, data elements that pass between systems are represented in the model by a data exchange. Both information exchanges and data exchanges are modeled by the UML information flow element and the "conveyed" property of an information flow identifies the information elements that are being passed.
A single needline association between two operational nodes can represent multiple information exchanges between those nodes. Likewise, a single system interface association between the same two systems can represent multiple data exchanges between those systems, and a resource flow association between two performers can represent multiple resource exchanges between those same two performers.
In integrated architecture modeling, a single exchange abstraction can be realized or refined by more specific UML constructs such as interaction messages or activity object flows. Both of these constructs can define information or data that passes from one domain element to another.
The generation tool in UPIA can scan a model for the UML constructs, such as messages and object flows, that define an exchange between operational nodes or between systems, and then create appropriate information or data exchange elements. Subsequently, you can run a generation operation to scan the model for exchange elements and create any appropriate needlines or system interface elements.
When you create a UPIA model, you have two basic options for how to proceed:
In a top-down modeling approach, you start by defining abstract constructs, such as needlines and information exchanges, to represent the communication needs in the logical model. As the refinement process continues, you can create sequence diagrams and activity diagrams to provide concrete examples of the abstract exchanges.
When exchanges, resource flows, needlines, and system interfaces are created manually, the constraints in the UPIA profile require the user to define cross-references between these abstract elements and their realizing messages, which invoke tasks, and object flows, which represent operation or system information. The generation tool for UPIA models ensures that these cross-references are set if a new element is created or if an existing element is found. In the top-down approach, the generation tool locates the concrete realizations and updates the cross-references in the existing abstract exchange elements. The generation tool can also notify you if a new exchange is generated, which indicates that the top-level model might not have been complete before the refinement process. Likewise, the generation updates resource flows, needlines, and system interfaces after finding exchanges, and can create new elements if they are missing.
In a bottom-up modeling approach, you create activity diagrams and sequence diagrams to elaborate on the use cases that were identified for the architecture that you model. You then abstract these specific communication needs into exchanges and then further abstract them into resource flows, needlines, and system interfaces. You do not have to manually create the exchanges, flows, needlines, or system interfaces. When you select the appropriate generation command, these items are created automatically, along with setting the required cross-references.
In an activity, an exchange is defined by a UML object flow that is stereotyped «Operational Information Flow» or «System Information Flow», where the corresponding actions are call operation actions for operational tasks and system tasks, respectively. The input and output pins on these call operation actions correspond to the task's parameter types, which should be information elements or data elements.
For example, suppose there are two operational nodes, OpNodeA and OpNodeB, where OpNodeB contains an operational task, called "doThis," with two parameters: one, an input parameter of type InfoElementX; and two, a return parameter of type InfoElementY. If an interaction exists, which represents an operational event trace, where its sequence diagram has two lifelines for OpNodeA and OpNodeB, repsectively, then a message, which represents an synchronous task invocation, from OpNodeA to OpNodeB is really defining two exchanges of information. One, InfoElementX is being passed from A to B; and two, InfoElementY is being returned from B to A. Therefore, this single interaction message can be used to generate two information exchanges.

Similarly, if OpNodeA had an operational task called "doThat," with an output parameter of type InfoElementX, then an operational activity diagram can also define an exchange of information. In this case, the activity diagram would contain two call operation actions: OpNodeA::doThat and OpNodeB::doThis. A UML object flow, which represents an operational information flow connector, from the InfoElementX output pin on the OpNodeA action to the corresponding input pin on the OpNodeB action, also defines an exchange of information between OpNodeA and OpNodeB.

The generation tool searches for messages, which represent task invocations, and activity object flows, which represent operational information flows, and generates the corresponding information exchanges.
When an information, data, or resource exchange is generated, various properties of the stereotyped UML element are set to identify what is being exchanged and the realizations of the exchange. Both information exchange and data exchange are specializations of resource exchange which defines several properties in common for all types of exchanges. Similarly, needline and system interface are specializations of resource flow.
The following table displays the exchange properties on the UML information flow element and the «Resource Exchange» stereotype properties that are modified when exchange generation is performed.
| Property | Description |
|---|---|
| Source | Contains the element that corresponds to the producer of the exchanged data |
| Target | Contains the element that corresponds to the consumer of the exchanged data |
| Conveyed | Contains a list of the information elements or data elements that were passed from the target element of the exchange to its source element |
| RealizingMessage | Set to all of the task invocation messages that correspond to this exchange |
| RealizingActivityEdge | Set to all of the operational or system information flows (UML object flows) that correspond to this exchange |
| Realization | Set to the resource flow, needline, or system interface association that represents this exchange and similar exchanges between the same two elements |
| ConsumingTask (Resource Exchange) | When an exchange is created from an interaction message or an activity object flow, the target operation is the consuming task for the exchange |
| ProducingTask (Resource Exchange) | When an exchange is created from an interaction message or an activity object flow, the source operation is the producing task for the exchange. For interaction messages, the source operation is determined from the execution block on the source lifeline that initiated the message. In some cases, this producing task cannot be determined |
When resource flow (association) generation is performed, the Exchanges property for each resource flow is set to the corresponding resource, information or data exchanges that caused the resource flow, needline, or system interface to be created. If the flow association already existed, the Exchanges property is updated accordingly.
Consider a UPIA model that contains two operational nodes (OpNodeA and OpNodeB), where OpNodeB contains an operational task, called "doThis," with two parameters: one, an input parameter of type InfoElementX and two, a return parameter of type InfoElementY. If an interaction, representing an operational event trace, exists where its sequence diagram has two lifelines for OpNodeA and OpNodeB, respectively, then a message, representing a synchronous task invocation, from OpNodeA to OpNodeB is really defining two exchanges of information: one, InfoElementX is being passed from A to B and two, InfoElementY is being returned from B to A.
If information exchanges are generated for this model, the sequence diagram would be scanned, resulting in the following summary output:
When the generation of exchanges occurs, the same exchange is used if the source and target elements are the same and if the list of conveyed elements is identical. In the example above, suppose OpNodeB has two operational tasks where one operation has an input parameter of type InfoElementX and the other has two input parameters; one of type InfoElementX and the other InfoElementY. If two tasks are invoked from OpNodeA to OpNodeB, where one call is made to each operational task on B, then two separate exchanges are created from A to B; one that passes InfoElementX and the other that passes InfoElementX and InfoElementY. These exchanges are different because, in one case, only a single piece of information is needed; but, in the other, two pieces of information are needed.
In addition to the generation of information exchanges in this example, the generation tool could also generate needlines based on the existing information exchanges. If this generation occurred, all the exchanges between the same two operational nodes are represented by a single needline association. If the exchanges are all in the same direction, then the needline is a directed association. If exchanges occur in both directions, the generated needline is a bidirectional association. In addition, if a connector with the stereotype «Needline» exists between operational node parts, a bidirectional needline association is created between the corresponding operational nodes.
Resource flows and system interfaces are always created as bidirectional associations.