Should I use an automated tool to generate UML diagrams of my code, or should I make it a habit to draw them manually as I code?
We may hire additional developers along the way so we'd like to make our code easy to understand quickly.
>>59684098
> needing to draw uml diagram
>>59684098
If you wanna do it right you design your software before programming, not while you're doing it or afterwards. I guess you can use some magical shit to generate stuff from the existing code, better then nothing.
I feel like some people on /g/ simply never heard about software engineering.
>>59684098
UML diagrams have two main functions:
First and more importantly: Make you think about what you are going to build see potential fuck-ups before they happen
But then you can ask "then why UML has all these rigid norms?" and the reason to that is the second function: Communicate the workings of your system to anyone who's not familiar with it.
If you think you are too good to waste time thinking about your software like >>59684174 (pro tip: you are not, software is complex), then generating diagrams from your code fills the second role.
But wait, before you go ahead and generate hundreds of diagrams, think about it for a while. If the objective is communication, you don't want to bury your reader in a document of hundreds of pages, so you have to choose the best diagrams for each aspect of your system.
I find the package diagram, the ER diagram and the domain diagram (it's like a class diagram without implementation details) most useful for static analysis. If you have a RESTful API, you should make a state diagram for each resource, and if you have some complex operation, make a sequence diagram for it.
I hope this answer helped raise even if a tiny bit the average quality of software in the world.
>>59684098
You should always do both.
You generate documentation with doxygen, it can generate UML for you as well.
But the main reason you do make UML is to make plans.
So draw your system in a way that makes sense to the project.
It is worth spending time on this.
Make a plan, go through it, see how to optimize the system, but at least make a plan that would work.
Then you start to implement it.
During this you might find that certain things require more information or something, which means you should split certain parts up or whatever.
Then you can go back to the drawings and see what your original plan was and if that should be improved.
Good UML makes the actual programming busywork you can easily ship away to someone else.
The idea is to get the base system running as fast as possible.
When you have the system running, you can improve on smaller parts rather than the entire system.
>>59685415
That's what the textbook tells you. In reality they are used for one thing. Making your boss and his marketing buddies think that they understand how things work. They should really stick to their own job.
>>59685501
I'm sorry your team works like that. Don't you do ANY kind of analysis and design?
Most books on software process are written by people who worked on hundreds of projects, you should at least try to adapt their experience to your needs.