Today in UML class our teacher told us that it is very important to create uml diagram of our java code and use design pattern before starting to program any application.

I find that weird because usually I just start write programs directly I don't design uml for my code because I don't know what I will use in it.It can be new library so I don't know full dependencies I will use.

  • See agilemodeling.com for some examples of using UML before writing code
    – xmojmr
    Jun 1 '17 at 6:25
  • 1
    It can be an iterative process. And ultimately, it's a "do what works for you" process. Everybody thinks at least a little differently. Try it your teacher's way, if only because he's giving you your grade:) But if that doesn't work for you, go back to your preferred development style (after the course is over:). Jun 1 '17 at 6:45
  • I'd second @JohnForkosh's advice re your teacher. If they are telling you to draw UML disagrams first, do so for them as you'll get higher marks. However, after that, UML might be of use to you on occasions for communicating ideas, but it is not a good design method and can normally be ignored when designing through your code.
    – David Arno
    Jun 1 '17 at 11:27

Where I work, diagramming is done before, during, and after we build the product.


Diagrams created before are used to discuss possible dependencies with other teams (which need to be coordinated as early as possible), the high-level systems we need to build (UI, Service, API, etc), and the user features each component fulfills.

These are built so that the team is on the same page, and can talk with other teams about what will be built, at a high level.


During development, we'll build diagrams when we need to discuss how lower level components interact, how over time components will talk to each other, and different contracts that exist (between UI, service, database, etc).

These are usually built so that the team can understand and talk amongst themselves how the system is evolving, and notice changes from the original design. They are made AS-NEEDED, when the team needs to discuss a complex problem or novel system.


These are usually the least useful. These diagrams are done for documentation purposes and help future teams understand how the system works as it stands today. They are not as valuable because, at this point, the team already has built the system. Even in the face of a major refactoring, the code will be more detailed and nuanced than most diagrams.

The diagrams built as you are developing the system will always be the most valuable because that is where you will see flaws, potential improvements, and have real discussions on what the system should look like.

That being said, it is completely possible in languages like Java to do almost all of your object-oriented design up front. Class diagrams lend themselves to this, and building diagrams first can help you practice talking about your system, before you build them out (something very common in whiteboard interviews).

NB. Design patterns should not be "used", they are emergent. When you notice something you are doing looks like a design pattern (more often than not in a diagram) you can start talking about concerns that are associated with them. Pre-emptively introducing a design pattern is a recipe for bad design.

  • 2
    Also, it is very rare that you will see strict UML used in the industry. While practicing the syntax can be useful, it is more valuable to know WHAT the diagram is trying to convey, rather than knowing what the difference between a filled and unfilled arrow mean.
    – JRJurman
    Jun 1 '17 at 7:41

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