• next
• back
• up

5.7 Transaction choice ratios

Figure 5.6 shows that the Business Traveler has a choice at each of its input and output ports. For example, it may buy 5 Train trips and 5 meals from Railway company 1. However, the logic of the choices allows three other transactions, not all of which are intended.

For example, the business Traveler may buy Train trips from Railway company 1 and food from Railway company 2. This is not intended but the diagram allows it. To rule it out, we need a transaction table.

In a transaction table , we indicate which transactions are intended and in which ratio they occur. The table is part of the e³value model. For example, table 5.1 shows which transactions are intended in figure 5.6 and in which ratio. The table shows that the intended transactions occur an equal number of times.

The numbers in a transaction table are ratios. Transaction txi is chosen

times. In figure 5.6, transaction 2 is chosen 50% of the time, so the boundary elements in Company 2 are executed 125 times.

Figure 5.6 contains a transaction merge at the interface of Railway company 1. At a transaction merge, the numbers of the merged transactions are added, so the interface of Railway company 1 is triggered 126 times. These numbers are computed by the e³value analysis software and are shown as comments in figure 5.6.

Transaction tables specify the cardinality of transactions, and hence of transfers, which then override any cardinality specified at a port. For example, the company offers single Train trips to student Travelers, and indicates this with an explicitly specified port cardinality. This is the cardinality used in transactions with the student. In transaction with the business Traveler, the ratios specified for the transactions with the business Traveler are used.

The e³value tool contains a transaction analyzer, which in case of an ambiguous diagram like that in figure 5.6, generates a table of possible transactions and allows the user to select the ones that he or she intends. We explain this in detail in the next section.

5.7.1 Transaction dependency

In figure 5.7, A4 performs transaction tx2 = {t3, t4, t5, t6}with A1 and A2. However, A1 and A2 each can make a choice between tx2 and another transaction. This creates a transaction dependency between the choices of A1 and A2. Table 5.2 clarifies the situation.

For the sake of the example, in table 5.2 A1 chooses between transactions tx1 and tx2 in an 8:2 ratio and A2 chooses between transactions tx2 and tx3 in a 3:4 ratio. The dependency between A1 and A2 is that A1 must choose tx2 in the contract period exactly the same number of times as A2 chooses tx2 in the same period.

Suppose A1 has 60 need occurrences. Then it executes tx1 48 times and tx2 12 times. Due to the transaction dependency, this means that A2 executes tx2 12 times too. Together with the choice ratio of A2 this implies that A2 has 28 need occurrences, split in absolute numbers over 12 times tx2 and 16 times tx3.

The single interface of A4 thus implies the transaction dependency that

where r_i is the ratio of transaction tx_i and N_j is the number of needs of Aj.

• next
• back
• up