Suppose you have your system "S" that receives an event Ev1() and an operational contract called OP1(). During the architectural phase, you decide to fulfill the requirements with two blocks, B1 and B2. B1 receives Ev1(), but B2 is allocated the operational contract OP1(). Now between B1 and B2, a message is needed. I assume this is Ev1() again, it is just forwarded. However, I need them to be different, because it might be the case, that B1 performs some tasks on the parameters of Ev1() and then forwards the filtered data to B2. How would you model this? Do I need to invent a new message for this? I have seen in the examples in the paper from H. P. Hoffmann and the Harmony deskbook that the messages are just duplicated. I suppose Ev1() in the above example is duplicated but now has a different TYPE for its parameter. Afterall, the fact that I drew Ev1() from B1 to B2 has already created a new event on B2, so yes, they are different.
For the example in Hoffmanns' paper see figure 10, the operational contract is reqCalcCmdrLosCmd, which is shown several times between LRUs:
http://static1.1.sqspcdn.com/static/f/702523/9277834/1288929233000/200511-Hoffmann.pdf?token=F%2FmLJpHRBLG3JpdFzxeJcZZyB1I%3D
During the allocation of requirements and their model-based representations (events, event receptions, actions, and whatnot), many - if not most - cannot be directly allocated. They must be decomposed and the decomposed parts are then allocated. In general, an event EV1 in a use case might be realized the architecture as a collection of events and operations in many subsystems; That's the "interesting" part of allocation.
I give a detailed example in the Harmony aMBSE Deskbook (available in the Resource > Papers page on this website) in Chapter 9. In addition to decomposing the events into multiples, you typically also have to identify (derived) subsystem requirements and decomposed operations.
So in general, the EV1 event you references, which might come from an external actor, will show up as an input to some subsystem in the architecture. Rather than just perform operation OP1(), it might do OP1_step1() and then send message ev1_step2 off to subsystem 2 to perform OP1_step2, ev1_step3 to subsystem 3 to perform operations OP1_step3 and then OP1_step4, and so one.
For example: imagine an event evPedalDepress(position) which causes the cause to ApplyBraking() operation. Inside the system, the Pedal Assembly receives evPedalPress event, and it has internal operations to determinePosition(), determineForce(), determineSpeed() related to the pedal event. It then passes this information over the the BrakingController as applyBraking(position, speed, force) event and internally performs operation (determineBrakingForce(wheel1, wheel2, wheel3, wheel4); the BrakingController then sends an event ApplyBrakingForce(wheelID, force) to each of the WheelAssembly subsystems. ALL of this is derived from 1) the intial use case and 2) the system architecture.
Few systems are so simple that you can easily just allocate messages and serviced identified in the use case model directly and uniquely to subsystems.
I hope this helps.
- b