10

UML has a jungle of Diagrams.
Profile Diagrams, Class Diagrams, Package Diagrams... enter image description here

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...

3

6 Answers 6

13

As a general guideline:

  • One deployment diagram for an overview of the architecture (good for any system)
  • One use case diagram for an overview of what users will do with the system (dito)
  • One class diagram for the data model
  • Activity diagrams for the flow of individual use cases if they are complex
  • Perhaps a state machine diagram if you have a create/review/publish workflow for blog entries

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).

3
  • Agreed, except 1 class diagram for large systems is pointless (I've seen huuuuuuge class diagrams, completely unreadable) - I prefer class diagrams for functional areas (eg. the login story may have a class diagram showing LoginPage, LoginViewModel, SecurityController, SecurityService etc.)
    – David_001
    Jun 15, 2012 at 13:51
  • @David_001: note that I mention the class diagram only for the data model. I don't think they're all that useful for other parts of the code. Jun 15, 2012 at 14:01
  • okay fair point, I have seen data models get quite big too though
    – David_001
    Jun 15, 2012 at 14:08
7

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.

4

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.

  • Is it an internal software or product you want to sell along with documentation?
  • How long will you maintain the software? Will you hire a programmer to maintain it?
  • How much agile do you want to be? You might waste time by too detailed planning.
  • How strange things do you want to do? You usually don't need to document common patterns like detailed use case of registration or overall architecture of a blog.

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.

2

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

  • during a conversation with the customer/domain expert/analyst, to clarify a use case
  • or just before starting to code, to flesh out a first version of your design.

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.

1

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:

  • Outline the actors and how they use the system.
  • Outline the structure of packages within the system. Note which packages contain reusable components.
  • Model the database structure.
  • Sequence diagrams are useful to design standard components. If you have many similar components, model one and use it as a pattern for the others. Consider code reuse in cases like this.

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.

1

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 :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.