e3value user guide
It often makes business sense to sell a bundle of non-money object occurrences of the same type at the same time. For example, the Railway company may offer a bundle of 3 meals in one sale. This makes no sense for money objects (the buyer will only pay once for an offering) but for non-money objects this is a common phenomenon.
We can specify this by placing a cardinality at a value port or at a value transfer of non-money value objects. We place the cardinality at the port if the bindling is defined by the seller or buyer. We place it at the transfer if it is the result of an agreement between seller and buyer.
A value port cardinality specifies how many instances of the value object are transferred through the port when the value interface is triggered. An occurrence of a value port is an event in which it accepts or provides a value object. The cardinality of a port indicates how many instances of the value object are transferred in each occurrence.
For example, in figure 5.3, the Railway company offers meals in a bundle of three.
If bundling were defined by the Travelers, and not by the Railway company, then we should have put it at the in-port of the customer. For example, in figure 5.4 the Travelers all buy a bundle of three meals from the Railway company even though the company offers them separately.
By default, a port cardinality is undefined, in which case the algorithm to count value transfers will ignore it. When the editor analyzes a model, it checks that port cardinalities are not set at both ends of a transfer.
If a port-cardinality is set, it must be connected to a transfer and it must be set at one side of the transfer only.
If provider and requester have agreed on a bundle, we put the cardinality in the transfer. The cardinality of a transfer indicates how many instances of a value object are transferred in one occurrence of the transfer. See figure 5.5.
By default a transfer cardinality is undefined. If it is defined, it overrides the cardinality of the ports to which it is connected.
We now have four ways to specify same-object bundling: As a cardinality jump, as a port cardinality (two sides), and as a value transfer cardinality. Specifying it as a cardinality jump expresses a property of the internal value activities of an actor. Specifying it as a port cardinality expresses customer-side or supplier-side bundling. Specifying it at a value transfer expresses an agreement between supplier and customer.