When modeling an architecture (system of systems or across subsystems), we often create an Activity with swimlanes.

This is fine, until we get fancy and want to use events and use the ports to flow the events between the parts. Unfortunatly the send signal works, but the accept signal never arrives at its destination. Here is an example:

Why don't accept events work in a swimlane? The core reason is that the accept event is actually owned by the owning activity, not the context of the swimlane. 

There are several reasons for this behavior:

1. The execution rules are defined by the OMG via the FUML specification
2. The OMG specifications for execution (FUML and others) does not address execution of swimlanes
3. We did not implement this notion of events in swimlanes
4. Some of what was done because of (1) works, just not accept events which are a lot harder to create a solution that would work for most customers. Worse, if swimlanes are used, you are already creating a mess for a truly executable design.

Simply, swimlanes were created in the old days of UML, but when we decided to create simulations, the swimlanes are treated as what they are for, to show how the system should work, not necessarily how it is implemented. In other words, once you create an implementation that is executable, you should stop using swimlanes as they are not compatible with creating an unambiguous behavior. 

The behavior should be in one place. If we had a behavior in the block and in a swimlane for a block, there are thus two places that the behavior is modeled. As stated, once you are doing this with the intent of an executable model, we need to avoid this ambiguity and put the behavior in the correct location. There are other reasons, like reuse and good object-oriented design, but the appropriate allocation of the behavior wins in this case because the tool won't work.

Simply we should never use swimlanes once we start to create executable models. We can get away with a slight hack. In the following we display the Activity owned by the block of the swimlane in that context. This will work, but as stated, this is a bit of a hack and the first swimlane creates an ambiguous model where behavior could be in the block 'and' wherever there is a swimlane showing the block. 

If you have any questions. Let me knowswimlanesexecutionAcceptEventActionSysML