What diagrams are needed to fully document a software project?

Question

Software design

Good afternoon!
Documenting a software product from UI to database.
At the moment I use:
1) Use Case diagram,
2) business object
diagram 3) database diagram
But I feel that something is wrong. I didn’t find any universal approach either on the Internet or in Martin Fowler’s UML Basics, so I want to try your ideas on how you work with diagrams?
Interested in
what diagrams and how you use them
- in what environment you work
- how you connect with each other

Answer 1

Good afternoon!
It so happened that I graduated as a business analyst and have some experience in this area (but at the moment I am engaged in development).
Now a little thesis on your information:
1) A diagram is a way to present information, any diagram can be described in words.
2) Diagram - a tool for revealing new information about the system.
3) For the first time I hear about a business object diagram: maybe it is something extremely rare (extremely specialized), but with a high degree of probability, you will not need it.
4) UML is a language, not a guideline for software documentation, but in books with the abbreviation UML you will not find a normal documentation guide.
The conclusion from this is the following: the diagram is used as a reinforcement for documentation, as a software design tool (to identify dependencies and new entities). In both cases, the set of notations will depend on the requirements for such documents.
If you are interested in software documentation, then google: technical documentation, terms of reference, GOST 34, GOST 19, SRS, a good article on Habré about it .
If you are interested in a full description of the project, then google: software development methodologies, project management, pmi, pmbok, agile.
Now let's go through the diagrams depending on the purpose. I can now highlight several areas (without claiming to be complete):
1) business level (any parts of the system that are outside the software per se)
2) software level (system modules, system components already implemented at the software level)
3) data level (data structure, description of data types, etc.)
4 ) hardware level (for example, network topology)
At the business level, business processes (idf0, idf3, aris, bpmn, dfd), workflows, user cases, mindmaps, and so on are usually described. - it all goes here. At this level, the main processes performed by actors external to the system are identified, the points of their interaction with the system are identified. Based on this, the main modules of the system, the functions they perform and their interaction are designed. Interaction of the system with the external environment.
At the software level, algorithms, pseudocode, entity-relationship, class diagrams, flowcharts, mindmaps, state diagrams, and all this is abstract. As you understand, all the entities described at this level have already been identified at the business level, and here they are refined and implementation features are described. By entities, I mean here both global system modules and subsystems, and abstract entities within the system, such as "product", "post", "user", etc.
At the data level, a database schema is usually made. Actually, the database schema is built on the basis of the described entity data from the previous level.
Personally, I rarely considered the hardware level, but it is built on the basis of business requirements, software requirements, data processing and storage requirements.
Unfortunately, I cannot fit in one post all the knowledge I have gained over the years of study and practice, but I hope that this will point you in the right direction.
ps on small and medium-sized projects, I try to use one of the business process notations if something needs to be automated (idf or bpmn), use cases to identify user interactions with the application; to prepare for writing software - entity-relationship, sometimes algorithms.

Answer 2

For an existing software product, it is more efficient to write structured comments in the code (such as PHPdoc) and the database and export them from there to a separate document. Separately, in the text, a user description by roles or somehow combined and additional models necessary to understand the operation of the system.