A particular strength of modeling is that it reveals our assumptions. Without reading thousands of lines of code,
we can
- measure communication traffic,
- evaluate quality by assessing coupling and cohesion, and
- test our models before we write faulty code.
Modeling accomplishes these objectives by raising the level of abstraction. Back in the 1980's and 1990's we wrote Assembler code, just one level above machine language.
Then we moved to third-generation languages such as COBOL and PL/I (Programming Language One)
The assembly programmers of the time thought COBOL just couldn't do what Assembler could do and would eventually go away.
They insisted that to write applications, you had to know how the machine really works. How many of you (other than game programmers) write any
Assembler today, let alone develop systems with it?
Compare that with the hundreds of millions of lines of COBOL code are in production today and the problems it caused prior to Y2K.
The Assembler programmers were missing an essential fact in their machine code. That is, the only reason to write code is to solve a problem.
The machine and the languages are tools to solve a problem, not the end itself.
Still today, when our focus is forced onto the technology (Java versus C++, JSP versus ASP, NodeJS versus C#) and away from the
problem, we risk losing sight of our real purpose and the factors that define true success, and that is not whether the code is finished,
but does the application do what we need it to do and can it survive the inevitable changes?
UML is an attempt to express in precise, familiar, and consistent language everything needed to
generate complete, stable, maintainable systems. UML is a level of abstraction above the
current programming languages, just as PL/I was a level above Assembler.