I've used UML modeling a few times in the about a decade ago and I am getting myself reacquainted with it. I found it clarifies an application's design which results in a faster and easier implementation. I found UML then to be straightforward and simple, but it has grown far more complex, covering more types of modelling along with a bigger vocabulary than when I last used it.

Although I am still getting my head around it, it appears the new additions to UML are merely different ways of capturing the same design. They also seem to go from a high level down to a low level modeling, blurring the lines between design and implementation.

Assuming you're designing a fairly complex application like Adobe Illustrator for instance, how much of the different modeling types should your design exercise? Are they al la carte where you pick what makes sense for your design, or is it a full 7 course meal where your design best benefits by using all of it? If it is al la carte, how do you determine which types of modeling covers what you need?

  • 1
    The Unified Modeling Language (UML) defines the industry standard notation and semantics for properly applying that notation for software built using object-oriented (OO) or component-based technology. Uml have large set of modelling. uml is depend upon your application and team and usage.
    – AjayGohil
    Commented Aug 24, 2020 at 11:13

2 Answers 2


UML covers indeed a very large set of modelling needs, from the most elementary designs, to almost visual coding, especially if considering neighbour standards such as OCL. If all these things were taken on board, I guess it's not for fun, but because committee members representing their company's interest worked hard on it because there's a real need.

So there is no single answer of how much UML is the right level:

  • I guess that if you're designing software for a nuclear powerplant or a new fighting jet, it is certainly a level of complexity that requires a lot of design, a lot of model verification, and perhaps even automated verification of preconditions, postconditions and invariants documented in the constraints.
  • If you're working on a large software product involving several agile teams, you may not be interested in up-front validation and extreme documentation at all. But maybe some component diagrams to discuss or understand the bigger picture can help the teams to cooperate. Maybe in a smaller scale, some class diagrams and sequence diagrams can help to discuss the structure and dynamics of what your're about to code in the current release.
  • Maybe some diagram can help you to express very nicely come things which looked quite wicked in your mind, such as for example a state diagram. Maybe also some mixture of UML with new practices, such as use-case 2.0 can help you work in an iterative and incremental way on requirements, working agile but nevertheless giving you some simple use-case diagrams as a by-product that could help to keep track of related features and facilitate later-on non)regression tests and maintenance work.

The answer, as Erik pointed out are to be found on your side, based on your real needs. Nevertheless, a couple of recommendations can be made to guide you:

  • It is not a good idea to use UML as a visual programming language. That was never the intent. Code is best expressed in code. Diagrams are more for the general ideas that lead to that code.
  • The more detailed your diagrams, the more time-consuming and difficult will they be to maintain. For class diagrams, I tend for example to show only classes, and some key features; never all the details. These key features that make the design rarely change. But all the remaining attributes and operations very often evolve very quickly, especially in early stages, making all detailed diagrams instantly obsolete.
  • Detailed diagrams make sense only if you have a tool to generate UML automatically from the code.
  • The more advance UML features you use, the more design details will be misunderstood (or not understood at all) by the fellow developers: not everybody can spend sufficiently time to understand all its subtle semantics, and since UML is not compilable nor executable, there is no way to verify that you understood correctly what UML 2.5.1 specs said.
  • The previous remark is reinforced by the fact that some UML founders are sometimes dreaming of a simplified "Essential" edition that would limit itself to the core concepts needed in 80% of the cases (you just need to follow Ivar Jacobson and Graddy Booch long enough on Twitter to capture here and there some of such thoughts).
  • Finally, for modelling the architecture, UML, althoug it's very complete, proved to be way to complex to use: since the language is very precise, you need to work out many more details of your architecture before you can model it correctly in UML, separating the code structure, from the run-time deployment. This is why alternative modelling techniques gain traction (e.g. C4 model, which allow with very few graphical symbols, to work out quickly on a paperboard a high level architecture, and postpone the refinements and details to when they are needed (and in UML if it helps)).
  • 1
    Great answer! As a solo developer, UML modeling greatly helps me think through the more complex aspects of a system while also documenting it--even for small projects. I find class diagramming alone does an extremely good job of exercising the behavior and structure of your application. Adding a behavioral model such as an activity or state diagram, is also useful for exercising the more critical or complex operations. The rest of UML are superfluous for small projects or small teams.
    – user148298
    Commented Aug 24, 2020 at 13:41
  • I must say that while the creators of UML discourage using it as a visual programming language, they don't emphasize it and even appear to contradict it with OCL and some of the modeling aspects like state machines. I suspect there's a bit of marketing and sales going on too. UML's leading proponents tend to be project managers and team leads who have to answer to higher ups. Any opportunity to demonstrate the complexity of the project greatly helps quell management anxieties about the duration and costs of the project.
    – user148298
    Commented Aug 24, 2020 at 13:57
  • @user148298 when I mentioned th founders, I was referring to Jacobson, Booch and Rumbaugh, who each had developed their own modelling techiques, and who worked in common to invent UML. Of course, once it is given to a standardization organisation such as the OMG, you suddenly have a multitude of stakeholders, toolmakers, but also users who all want changes and specializations, which leads is where we are now. A similar thing happened for example to BPMN , that was first a simple notation aiming at facilitating communication with process owners but also finished as a very abstract standard.
    – Christophe
    Commented Aug 24, 2020 at 15:10
  • @user148298 Fortunately, it’s not because almost everything is in UML that you should use it all ;-)
    – Christophe
    Commented Aug 24, 2020 at 15:14

First you have to work out why you are creating a design document of whatever kind. Key reasons for me are:

  1. Break down the problem into manageable chunks
  2. Communicate the design ideas to others
  3. Thought experiments about different designs

Once you have clear goals you can start to answer the more detailed questions you ask, like how much detail is too much, is UML suitable, which set of shapes am i going to use etc.

I think you'll find that you need more than one type of diagram for different parts of the system and for different audiences. Make sure you choose nice colours and make it look good on slides!

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.