Software Developer Revolt!
As the size and complexity of the software-intensive systems that we need to develop increase, a corresponding rise in the level of abstraction of the programming languages used to build them has understandably increased. From routines to functions, to objects, to namespaces, the progression in abstract text-based language encapsulation mechanisms is depicted in the figure below. Will the transition from text-based languages to graphics-based languages infiltrate the mainstream soon? Isn’t it inevitable that graphical languages, and the tools that enable their use, will push the art of hand-coding via text languages into the dust bin of irrelevance?
In his book Real-Time Agility: The Harmony/ESW Method For Real-Time And Embedded Systems Development, Bruce Powel Douglass unabashedly says “YES!”. His agile methodology (yes, yet another “agile” methodology is foisted upon us) doesn’t even require a “coding” phase/activity.
The figure below attempts to contrast the mainstream CDD (Code Driven Development) approach of today with an MDD (Model Driven Development) approach like Mr. Douglass’s. Will the transition from one dimensional text-based languages to more abstract, two dimensional graphics-based languages be too much of a leap for today’s programmers? Compared with text-to-text language transitions, a text-to-graphics language jump is more akin to a disruptive quantum leap. Will software developers ironically morph into Luddites, fighting this technological change tooth and nail? Is the UML today’s graphical incarnation of the text-based assembler language of yesterday? Will tools like IBM’s Rhapsody and Artisan’s Studio supplant the myriad of compiler-linker toolchains of today? What say you?
Leave a reply to Ray Cancel reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
I have been in the software development business for almost 30 years and the graphics based development has been the holy grail most of that time. From the CASE tools in the 80’s and early 90’s to the MDD version today. The problem is the last step – auto-generation (ag) of the code. It hasn’t worked and the feed should include a test of the ag code. If it doesn’t work what is wrong the design or the code. How is it debugged? Is there a mathematical mode that proves that the code generation was right. Does this development model scale? How do multiple people work on it.
The ag code comes so late in the cycle that it has to be right. I have seen projects use graphic development then devolve into marathon code generating exercise.
Hello there…now, I am not an expert by your means, but I do know, that SysML and it´s export format XMI (supported by MagicDraw e.g.) do allow, and there are also prototypes that actually work, an export of a internal model as a kiond of a metamodel (i.e. it has to comply with the simulation tools xmi-standards and syntax), which can be parsed and then be the basis for an autogeneration of a Simulation code! … Check an example project at the Technical University of Dresden, Germany, where exactly that has been achieved, i.e. autogeneration of a code on the basis of a sysml meta model (structural and behavioural), which allows for simulation.
BTW: For me as a beginner, having a hard time with my diploma thesis on sysml modelling for discrete manufacturing processes and simulative analysis, this website is among others a great help and read. Thanks for this, I will recommend you! Cheers from Germany,
Sanji
Glad to be of help to you Sanji.
Hi Ray,
The auto-generation of code would be no different than how a text compiler does it. Are there math models that prove text language compiler output? If there are, then there will be for graphics language compilers too.
I think it’s just a matter of time before the advancement of technology answers all your questions. Do you think in 10-20 years that all will be the same as it is now; everybody coding exclusively in text?
When movies became popular there were people who said books were a thing of the past. But a movie even though it tell a story, it can’t tell it with the same precision as the written word.
This is the same with graphical design of software. It has to get down to the precision of the written word. The current use of dialog boxes and other methods to the properties and view them will limit the over all view of the code. The use of a framework being dropped out the ag code method is being used currently. The details are filled in by hand.
Your first two sentences are “arguable”. One could argue that since movies contain *both* recorded words and pictures, it tells a more precise, 2D version of the story.
Yes, the details have to be specified by hand. That’s why the UML is rigorously defined: so that it can be”executed”. Of course, not many refine their models *today* to the level of detail required for execution, but if the tool technology keeps getting better, they might.
Sorry, but in model driven development, you can not write complex sentences, such as casting sentences. I’m thinking for example on C++ cast operators, combined with method calls, for example:
obj1->method1(dynamic_cast(&obj2))
Also, formal reductions can not be represented on model driven development, such as transforming:
((true_expr1_result && !false_expr2_result) || (!false_expr1_result && true_expr2_result))
to:
((bool)(expr1_result ^ expr2_result))
Also, other kind of reductions, like:
(val1 != 0 && val2 != 0 && val3 != 0 && val4 != 0)
Are not possible to transform into:
((val1 & val2 & val3 & val4) != 0)
And really, I don’t know a compiler powerful enough to think about those reductions for you…
Hi Dan,
Maybe the blarticle is a little misleading. I don’t think that text will totally be eliminated from programming, but it will be relegated to the background as a filler. The UML and SysML currently support OCL as a supporting text language. They also (I understand) support ways of integrating other text-based math and logic languages with their graphics.
Thanks for your interest and feedback.
It’s been 10 years… has anything really changed?
No 🙂