I'm not sure about your level of expertise or how exactly your question was meant, so feel free to yell at me if I'm talking to you like you're 5.
I write mostly C# and C++, I haven't worked with Java in years, but a very general guidelines when writing software can be applied to any language.
First, I don't use any tools for organization other than my IDE (Visual Studio and Visual Studio Code, both professionally and for my hobby projects), though I hardly use any of its features either (again, in terms of organization). I just group things into modules/packages/assemblies/whateveryouwannacallit. The most important part is simply to differentiate parts of the code that do a specific task, and limit that code to
only do that task. This alone obsoletes most tooling needed to keep code organized.
I'll just give a very general example, as I don't know your particular use-case. Say you want to make a game. Games need controls (let's not talk about VNs for now). Obviously whatever engine you're using is probably providing the core mechanics of that, but you'll still want to map the controls to your world and how your character moves in it. But it has nothing to do with other game logic, it's just an interface between the human and the game. As such I would make a separate module/package/assembly/whatever for it. This will isolate it from your other code which already helps with code organization and teaches you how to keep things that don't belong together separate.
Second, and this will likely garner some hate, don't overuse software patterns. My quality of life increased by an order of magnitude once I learned that software patterns hinder as much as they help and are easily replaced by a few core guidelines. They introduce so much boilerplate, with little to no benefit. They make your code very inflexible and changing a little bit always requires lots of work. They also introduce "code" that does nothing but abstract away implementations that needs not to be abstracted away, for some perceived benefits that rarely apply. Code simply evolves faster than patterns can keep up with.
Third, and this will also not be very popular and already clashes with the previous poster (sorry Elvishious, no offense!), don't use spreadsheets and graphs.
Either you use them
before writing your code. That way they lock you into a specific design which, when you get around to finally implementing it, you may I realize doesn't work. That's because theory doesn't always pan out, you tend to not always consider everything. And even if it does pan out, once you introduce a slight change your design may not fit anymore, and you need to redo the graphs.
Or, you do them
after you write your code, not to dictate your project, but to document it. That I can see a reason for, especially if you need to communicate it to people external to the project, like if you have a client who needs to consume your API. Those cases are few but they exist. If you only use it to document it to
yourself though, it's normally a sign that your code isn't organized very well internally, and instead of writing graphs to document it for you, I always found it better to rethink the design and make the code speak for itself. Ideally few public facing methods that communicate exactly what they're doing, and as little redundancy as possible.
Now, these are all very high-level and generic ideas, but your question was a bit vague
Generally the more people you get the more different and conflicting advice you'll get about things like UML graphs. The thing that helped me most was experience. After a few years actively doing it you simply get a better feel for what does and doesn't work for you.
