To add to the discussion above, you need to be clear whether you need a "merge" node or a "join" node.
Every path through the activity diagram follows a token flow.
if A and B are inputs and C is an output:
- Merge Node: every time an input appears on A or on B an output token will be generated on C. That is, neither input waits for the others.
- Join Node: when a token arrives on A, it waits until a token also arrives on B and then generates an output token in C.
If you are trying to model boolean logic...(you would probably be better off in SysML than UML...but that is not important here) the join node will probably be more realistic because the gate will make its decision on a clock edge. However, this is still not perfect because absence of an input will be taken as an input...not really a correct representation of the logic circuit.
Chewing further on "OR NODE" as representing a logic circuit....if this is what you are doing, I would recommend two things:
1) Use SysML rather than UML - SysML is built on top of UML and is less software-centric
2) Move up a layer of abstraction and think about functional and information flows. What information is moving from where to where?
Trying to model the wires and the transistors in either UML or SysML is counterproductive. The strength of model-based engineering techniques is NOT in replacing the low-level specialty design tools. The strength of the modeling tools is in getting a diagram on the screen in a conference room in which 2 hardware engineers, 1 software engineer, a customer support engineer, an accountant, and a lawyer can all have a sensible discussion about what the system is supposed to do.
Hope this helps!