UML has a jungle of Diagrams.
Profile Diagrams, Class Diagrams, Package Diagrams...
However, (IMH-and-not-too-experienced-O) I quite see that doing each and every diagram is overkill.
Therefore, which UML Diagrams are more suitable in a web context, more expecificly a blog (we want to build it from scratchs).
I understand that just because I used UML Diagrams does not imply that our code would be great and brilliant... but, it certainly would be better than just unplanified code...
As a general guideline:
Some diagram types (e.g. timing diagram) have rather specialized uses, others tend towards a level of detail where actual code does a better job (e.g. sequence diagrams), and others yet seem to be intended for gigantic projects but have questionable utility even there (package diagrams? Any IDE can show you your packages).
The diagram is less important than the conversations you have when communicating concepts between the various stakeholders in a project. After years of developing software, I've found myself trying to capture information diagrammatically even less in recent years than I used to when I was just starting out. Nowadays, I might draw up a few simple use-cases on a whiteboard when discussing concepts, and I'll often resort to a simple but classic flowchart if I am trying to gain some understanding about how a customer wants a system to work. If I am particularly concerned, I'll use the camera on my phone to capture the image on the whiteboard to help me remember specific things.
Heavily documented up-front design isn't very lean. It discourages change and fixates your thinking around a single plan of attack that might end up totally wrong for the project overall. You want to be able to defer as much of your design as you can to the last minute in order to reduce the chances that a big change will mess up your designs and schedules later on. This is not to say that UML shouldn't be used, but rather that it should be used sparingly, as a means to improve the communication of concepts, and not as a means to define the systems you are intending to build.
UML was designed as a communication language among involved people. (programmers-programmers, programmers-business people, business people-users) People express their mental models in a simple, unified language everybody understands.
You need to ask yourself how much of that communication you need.
A rule of thumb is to do the high level diagrams to give you overview and spend time on complicated or not so common stuff. Writing/drawing down your mental model in UML forces you to fully understand it and solve many bugs before writing a single line of code.
Apart from a few big-picture diagrams that will be used to communicate the overall architecture of your application in terms of servers, layers or big modules, I don't think you can predict which diagrams you'll need beforehand.
Wait until the last responsible moment. You'll see when you need them. Usually, it's either
Anyway, your models will probably become obsolete as soon as you've written a few lines of code or gotten a first customer feedback, so don't bother planning everything in advance or polishing your diagrams that much.
You need as many as required to understand and communicate the system. For blogging software, I wouldn't think you need many. Model as much as you need to understand the system. Stop modelling when it stops adding you your understanding.
If you are new to UML you may want do a few diagrams in detail to increase your understanding of the diagrams. Once you understand a diagram type well enough you can do it in your mind, the need for actual diagrams becomes less.
If you date your diagram versions, it will help you judge whether they are likely to be current. Comparing the current design to older diagrams can be useful in determining which areas of the project varied significantly from the original design.
Unless you are using tools which generate the code from diagrams or embed the diagram specification in code the are likely to fall out of sync with the code. Detailed diagrams will tend to become significantly more incorrect over time. than overview diagram. Overview diagrams will also be require less maintenance to keep them current.
You may find it useful to generate diagrams that:
Generate diagrams which are useful in planning the project. If a diagram is not necessary to understand and/or communicate something about the project, don't waste time on it. Feel free to use a non-UML diagram if it aids understanding. UML may not be the best way to model the database.
I would say that you need to adapt UML diagrams to the modeling level of all stakeholders and the time you have to complete the project.
If the team doesn't know UML and have no time then only class diagram coming from reversed code is possible. Each member can add his/her comments in the class diagram which is already a good solution for documentation. In this case the model is only a graphical view of the code. This would cover almost 90% of modeling needs if done carefully and will not add any extra time to the project.
If you have advanced stakeholders knowledge then all diagrams could bring real value to the project in order to cover full modeling project needs. This could add significant time to project delivery but the delivery quality is expected to be better.
UML is cool, brilliant and canbe adapted to any project if use with moderation. Don't drink and drive for example at the same time :-)
