How to design a software workflow chart? [closed]

Question

I have been working for a while now but because of my earlier habits i never worked systematically.

I have never created a workflow chart for my software as how the software will work and instead of that i started working directly which in turn leads to many problems later.


Below is a small situation i currently need help with:-

NOTE:I have already created a software which does the following and i don't need any code for it, i just want to know how a workflow chart is created for such a situation.

1) Party List : This is where i would like to store all of the information of my customer.

2) Sales : Here i will sell my products to the customer.

There are 2 cases here, whenever the customer arrives we have an option to

• either save it in the party list and select it from the list in the sales form

• or type it manually and then save it

Now comes the checking part:-

If an entry was saved in Sales when the checkbox was ticked and the user selected a party, lets say "Akhmed" has been saved AND the user tries to delete the record of "Akhmed" from the Party List form then the software shouldn't allow it to do so as the entry of "Akhmed" already exist in Sales.

Can anyone show me how a workflow chart is created for such a situation?

EDIT

Here is a sample workflow i have made after reading some articles, please point out any improvements that can be made to it or is it completely wrong or anything.

Answer 1

First of all, great question. I wish all software engineers thought first before jumping to writing a code. Especially when it's about anything more serious than a couple of lines for fun.

I think your software flow can be expressed as Activity diagram. An example of activity diagram is expressed on this picture: https://www.tutorialspoint.com/uml/images/uml_activity_diagram.jpg

Basically, activity diagram is a combination of steps and transitions (arrows) connecting them. Step can be just something that happens in the flow, or it can be a logical operator (decision) which branches the flow execution into different directions.

If you need to also emphasize who needs to execute the step, besides just showing what the steps are, you can add swimlanes (horizontal or vertical columns showing the actor names) to the activity diagram. That's where it turns into a Flow Chart diagram. e.g. on this image you can see horizontal swimplanes explaining who does the step execution http://static1.creately.com/blog/wp-content/uploads/2011/11/Support-Process-Flowchart-Template-1024x613.png

Note that terminology can differ from person to person, but these are the names for these 2 kinds of diagrams I have mostly heard and used myself.

There are other kinds of diagrams too, but I think your specific case will be covered with the ones mentioned above. Although... use case diagram can be something you may be interested in, but that does not depict steps. That only will mention actors and what kind of actions they can do with your system. e.g. https://sourcemaking.com/files/sm/images/uml/img_32.jpg

You didn't ask for tools, but I usually prefer to use tools that are rigor (rather than loose like Visio), so I would recommend to use WhiteStarUML. It's free and does a great job. But as I said, it's strictly UML-based, so will require some familiarity with UML.

Finally, about your attached picture: What you showed looks like an activity diagram with some illegal components on it (illegal from UML specification standpoint). Is it good or bad? - depends. If it's supposed to be a rigor UML diagram then it's bad. If it's just a sketch of an idea - not bad.

Your diagram mentions database sign (called "DB") and arrows connecting to it. That's illegal on an activity diagram UML. Instead, you can have a step which says "Data gets saved to Database", and remove the "DB". Also, you have a single step which says both "Party" and "Sales" on it - that's not a legal UML. I think you tried to express that there are 2 flows. In that case, just have 2 different activity diagrams instead of one.