I'm attending a software engineering class at my university, and my final consists of a fully-documented desktop application to be built in a four people team.
While designing and coding this software, there's a question that always pops in my head, since my professor keeps repeating that everything that happens in code has to be first designed in a UML sequence diagram, and every class written in Java and every method of every class has to be designed first in a class diagram.
Now, I'm new to software engineering and designing in general, but isn't it too much of a UML-obsession here? Is a software engineer really required to foresee every requirement, every problem, every framework compatibility without seeing a line of code?
We tried to design every tiny bit of interaction, but while coding problems and sceneries keep appearing and need to be solved, but we can't because solutions aren't documented there.
So my question is: is there really a 1:1 mapping from UML to code? Is it possible that adaptations, solutions, refactorings will not be documented in my future work-projects? Or are we just doing bad design?

  • 3
    A particular piece of UML can be written moments before the code it refers to is. If your professor is insisting you lock the design before cutting any code then they aren't teaching design as used by most of industry.
    – Caleth
    Jan 11 at 10:18
  • Yes, this is a UML-obsession and is not how anyone actually writes real software.
    – user253751
    Jan 11 at 10:25
  • 2
    @user253751: Nitpick: it is not how anyone successfully writes real software. There's plenty of high-profile failures of this approach. (FBI Virtual Case File, anyone?) Jan 11 at 11:01
  • @JörgWMittag well, since it was a failure, the software was never real :)
    – user253751
    Jan 11 at 11:02
  • 2
    "keeps repeating that everything that happens in code has to be first designed in a UML sequence diagram" - cough, your professor is clearly a pure theoretician who never ever had to write any real software. What's worse, in the last two decades, even most theoreticians should have noted that this is nonsense. I would recommend he/she should visit some advanced trainings in modern software engineeringby people with experience outside his/her ivory tower. Unfortunately, you are probably not in a good position to give him/her this advice ;-)
    – Doc Brown
    Jan 11 at 13:51

2 Answers 2


The notion that software is fully specified and designed prior to implementation is indicative of a highly sequential approach to software development. Although there may be organizations that work this way, the software engineering community has found more effective ways to manage software development activities. Even in cases where you may be able to specify the system requirements in detail up-front, requirements allocated to software are more likely to change to accommodate uncertainty because it's easier to change software design than hardware design. This is why iterative and incremental methods, such as the various Agile methods, are commonly used.

The thinking that models - whether they are UML or some other notation - contain all the details is closer to using UML in a mode more consistent with blueprints or as a programming language rather than a way to sketch or take notes about a design to help communicate to other engineers. Agile modeling techniques provide ways to use tools like UML within the context of iterative and incremental development methods and focus on just-in-time and barely good enough modeling.

Getting to code early is often good practice. However, moving to code early is not the same as neglecting some level of up-front architecture and design to make important decisions that will be difficult to change as the system evolves. Understanding that requirements will emerge as software is integrated into a larger system and used is fundamental to success, so the ability to anticipate every requirement or problem is not possible.


It's a good question, I myself had the same question when I was studying. My professor explained it like this: It's never going to be possible to forsee every interaction within a given system while designing it. We design UML diagrams for two reasons.

  1. UML is a language with no speech barrier, wether you are speaking the same language as your co-worker or not, you can both understand a UML diagram. Thereby you get the same understanding of how the different pieces of code are supposed to interact with eachother.
  2. UML is also a way to prevent the occurence of common problems in your code. As you mentioned, you can't foresee every problem, but the ones you can foresee can save you hours of work in the long run. In a work environment time really is money.

Looking at a more realistic picture... You're probably not gonna spend a lot of time drawing UML diagrams. You're probably gonna stand at a whiteboard with your coworkers, and draw some UML until everybody has a core understanding of the system. After that you're gonna start coding, and forget all about documentation until after you finish the whole project. The reason for that is again... Time is money, and your future boss will never prioritize spending money on documentation if there is a deadline to make.

Hope this shed some light on the matter. Good luck with your exams!

  • 3
    all the UML function names, class names and variable names are written in a language, and the diagram is useless without understanding them. There isn't no language barrier.
    – user253751
    Jan 11 at 11:02
  • I consider UML like sketching an image before you paint it for real. Spending a couple of minutes to hours drawing a quick outline of your software can sometimes help you to spot things that won't work, before you spend weeks trying to make them work.
    – user253751
    Jan 11 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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