|« [BPM] New papers from Ashley McNeile||[Other] RESTafarians' dialogs »|
Ivar Jacobson and Steve Cook wrote a dull piece on the future of UML. They explain:
Clearly, UML could be leaner, more expressive, easier to learn, easier to integrate with other modeling and programming languages, and more relevant to today's technologies.
"Clearly"? "More relevant to today's technologies"? "easier to learn?" I am flabbergasted to see that in 2010, we, as an industry, do not have a common graphical or even textual System Definition Language, widely understood by the vast majority of actors involved in the construction and operation of such systems.
So what are they thinking?
For example, we would like to use parts of UML deeply integrated with a scripting environment to drive the interactive behavior of a mobile application. We'd like to use UML diagrams to automatically visualize the structure and dependencies within a massive distributed service-oriented application.
"Deeply integrated with a scripting environment"? "to drive interactive behavior of a mobile application?" No wonder that Steve Jobs is trying to stop any modeling effort around the iPhone. "visualize the structure and dependencies within a massive distributed SOA"? What? from OO constructs they want to visualize SO? I am stunned that people of that stature could engage in such shameless marketing brouhaha. But wait, they continue:
We'd like models to be deeply integrated with modern programming languages without any semantic conflicts. We'd like to use UML to model applications deployed in the cloud. In short, we like to make UML smarter and more agile.
"without semantic conflicts?", "model applications deployed in the Cloud?" Wow ! what are we waiting for?
I must admit that I am a tiny bit disappointed that they didn't find a connection between UML.next and REST. That's quite a faux-pas for such a grandiose initiative.
How do they plan to achieve these great objectives? They argue that UML has grown too complex and this is the core of the problem.
How do we reduce the complexity while increasing the flexibility?
We can and should create a very small kernel of no more than 20 elements such as objects, links, types and actions
I am in awe, all the semantics of all programming languages, SOA, mobile application UX, Cloud computing ... in 20 concepts (or less) that people can learn "in a few days". Yeap ! Why didn't we think of that before?
Wait, actually, not quite, all this happens above the kernel:
On top of the kernel we now add more useful concepts. The most essential UML use cases can be defined as extensions to the kernel.
Everything new is added with the new use case, since it supports the use case. This is the whole point. This is what is called an "aspect-oriented structure", where the kernel can be kept clean and simple without knowledge of how it will be extended.
When UML is structured as a simple kernel plus extensions, new domains can be addressed by crafting further extensions that can be seamlessly integrated with the existing structures.
Of course all these use cases can also be learned in a few days and will not contain more than 20 concepts?
The authors conclude:
During [the past 10 years] we have not adapted UML to the development that happened in the software world.
You bet ! Did you even realize that something was going on outside UML?
The amazing production of apps for the iPhone is a perfect example. Today, we have yet to find a place for UML in this context. That does not mean that such a place does not exist, just that we have not adapted UML to this context or made UML appetizing to use in these contexts.
So what to think of that effort? It will fail, the kernel will be useless and the aspects will take too long to develop and create an infinite number of diverging semantics. Not to mention the notation problem. The OMG is emotionally attached to the concepts of OO and its past work. It was great work for sure, but OO no longer exist. OO has become a massive hindrance for our industry and I am afraid this group will continue building this hindrance for the next 10 years.
This new venture will for sure create a nice little consulting and tools niche to help their followers to "deeply integrate" this new technology in their processes.
So allow me to provide some quote from Ivar and Steve's article in April 2020:
During the past 10 years, we have tried desperately to catch up with the industry's rapid pace of innovation. The rate at which new semantics, architectures and devices come to the market had been totally underestimated and none of the extensions mechanisms we had built in 2010 could prepare UML for that.
Today [in 2020], OO has all but disappeared overwhelmed by the semantics of Service, Process, Event and Resource orientation. We never understood that OO was just an aspect-oriented structure of a much broader foundation. It has been a tragic mistake to spend the last 25 years trying to articulate any semantic on top of the ones of Object Orientation. It has lead to massive inefficiencies across our industry and the development of a "tricks and tip" mentality that has brought a wide confusion and distrust in the software construction process.
The path forward? Simplification? not exactly, what is needed is two things:
Call it UML.next or whatever you want, people need today far better tools to communicate (BPMN is a great example of that, can UML.next do Business Process?)
People also need to be able to construct systems in a technology and architecture independent way. They need a true MDE foundation, such as MOP.
These two things are critically missing from Ivar and Steve's vision. I somehow feel very sorry that so much effort is going to be wasted for nothing.