Mapping class diagrams to source code

Question

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?

Answer 1

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.

Answer 2

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!