Well... yes... there is a degree of creativity involved in solving many system problems, but this is overstated. The majority of creativity and adaptive problem solving is to solve the problems of the systems own making. To attempt to bend unyielding frameworks to serve the task at hand.
As a design language it is important to understand the way that UML - Unified Modelling Language - is used. It is used in several ways :
The problem is that object design should be fundamentally an incremental and iterative process. The accepted UML methodology tends to add far too much inertia to this process, the more detailed a UML specification, the greater the maintenance issues with any modification, whilst less detailed specifications are not considered to provide the required level of documentation.
"Professional" designers accept this burden as a badge of honour.
In practise many designers will admit to updating the UML after the system has been implemented. This is not necessarily a bad approach. The UML is used as the initial guide to implementation and then later on it is updated as a document to reflect how things really are - but this is not how it is supposed to work.
The Object Representation Model has been incrementally defined to provide support for the required generatable patterns - in other words those code fragments that on calm reflection it was felt possible to generate.
There is no other intellectual justification for the "completeness" of this system.
Checkout the whitepaper on the Northwind implementation for more information.