I have drawn the following diagram and I want to know how correct is that?
This is a sample CLI program which receives a command, checks if it is correct[or exists in command definition file] (its parser), and then executes it, else it will throw an error to the user. On the course of execution, if anything happens that would terminate the execution, is reported as a failure to the user. All of these events must be logged, too. My concern is the horizontal bars (known as merge-fork):
I draw activity diagram by your description. After activity starts execution, it waits for event "Command Received". When command received it can be executed if condition "in definition file" is true. Otherwise exception is thrown. Exception is command object. (in this example. But you can change it). After command is executed, or error logged, activity waits for next command. If more than one command need to be received concurrently, just remove flows to "Command Received" event.
See diagram below:
First I think the diagram is not very clear. You should be more expressive in the description of your elements. For instance: What does "command" mean? I guess from the context it means "command received".
Another thing that is unclear to me is what you mean with the signals at the start: You first receive the signal "command", then make some unclear decision and then, if the decision goes one way, send the signal "failed". As the command does not get executed I guess its not valid in this path. Please say that your decision. (You could tag your branches [valid command] and [invalid command]).
As for the merge-bars I agree with the comment that you should not use them this way. But my favorite source says you should not point the arrows directly to the actions (But it also says that in practise you often do that :) ). Instead you should use a diamond, just like in a decision, but with multiple ingoing arrows and one outgoing arrow.
A little opinion afterwards: I find that UML can often be distracting. I have sat in more than one meeting where we should have discussed the design of our software but instead discussed UML. The important part is that UML helps you communicate effectively, not that every notch and twitch is according to the standard. Except, of course, if you want to generate code/stuff out of it.
