how to represent a workflow in software product [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

开发者_JS百科Closed 5 years ago.

Improve this question

I have a task to investigate a file loading process in a one of our company software, I have to represent main classes and methods and what kind of work is done in that and finally write a report about that with some kind of diagrams.

what is the best way to describe this workflow by writing text document or by using UML and if UML which kind of diagrams should I use?

---

Use UML Activity Diagram (http://www.agilemodeling.com/style/activityDiagram.htm) for the flow of the processes at a high level.

Then, use UML sequence diagram (http://www.agilemodeling.com/artifacts/sequenceDiagram.htm) for portions complex enough to warrant further detail.

---

The best format for any documentation depends not only on the information it carries but also on the intended audience. If your audience consists of software engineers, I would say UML is a good choice: it is standardized, which means you won't have to make up your own notation or explain it, and if you keep the diagrams reasonably simple the odds are good that your audience will be able to read them even if they aren't full-on UML experts.

You don't say what the documentation is for, but at a minimum I would suggest the following sections in your report:

Source View: class diagrams, possibly with a few package diagrams as well depending on the implementation language and the number and type of packages. (If the packages provide functional abstractions, like they can do in Java, consider describing them; otherwise it's not hugely important.)

Runtime View: sequence diagrams describing the flow of control for at least the key functions.

You may also consider adding one or more of these:

Overall Design: a component diagram describing the main parts of the software: for instance a DLL and an API being called by the user's code (I assume we're talking about some sort of library routine). This should not be concerned with specific method calls or implementation classes, but describe the software at a high level.

Conceptual View: this should describe key concepts, typically using very simple class diagrams. File is probably one such, and you should consider including a state chart describing the different states of a file (open, closed, eof...).

As always when using UML to document (rather than for instance generate code), be generous with notes in each diagram, and sparse with elements (classes etc). For diagrams intended for pasting into text documents, I try not to put more than a half dozen elements in each diagram.