Archive
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?
UML and SysML Behavior Modeling
Most interesting systems exhibit intentionally (and sometimes unintentionally) rich behavior. In order to capture complex behavior, both the UML and its SysML derivative provide a variety of diagrams to choose from. As the table below shows, the UML defines 7 behavior diagram types and the SysML provides a subset of 4 of those 7.
Activity diagrams are a richer, more expressive enhancement to the classic, stateless, flowchart. Use case diagrams capture a graphical view of high level, text-based functional requirements. State machine diagrams are used to model behaviors that are a function of current inputs and past history. Sequence diagrams highlight the role of “time” in the protocol interactions between SysML blocks or UML objects.
What’s intriguing to me is why the SysML didn’t include the Timing diagram in its behavioral set of diagrams. The timing diagram emphasizes the role of time in a different and more precise way than the sequence diagram. Although one can express precise, quantitative timing constraints on a sequence diagram, mixing timing precision with protocol rules can make the diagram much more complicated to readers than dividing the concerns between a sequence diagram and timing diagram pair. Exclusion of the timing diagram is even more mysterious to me because timing constraints are very important in the design of hard/soft real-time systems. Incorrect timing behavior in a system can cause at least as much financial or safety loss as the production of incorrect logical outputs. Maybe the OMG and INCOSE will reconsider their decision to exclude the timing diagramin their next SysML revision?
Bend It Like Fowler
Remember the popular soccer movie “Bend It Like Beckham“? Well, I like to “Bend it like Fowler”. Martin Fowler, that is. In his terrific book “UML Distilled“, Martin recommends bending the UML when you need to communicate some application-specific design information and you’re not a UML language lawyer. Rather than leaving an important snippet of information out of your model because you don’t know how to capture it via a language formality, do whatever it takes to record it. It’s the stuff that falls through the cracks which causes downstream schedule delays and rework.
As a survivor of the structured analysis CASE (Computer-Aided Software Engineering) tools fad of the 80s, I’m leery of the expensive automated UML and SysML tools on the market today (Telelogic‘s Rhapsody and Artisan Studio come to mind). I think that both the UML and SysML are great languages for communicating a shared understanding of analysis and design information across a diverse team, but unlike general vector-based drawing tools (e.g. Microsoft Visio), language-specific tools are “handcuffers“. They usually require you to be a language lawyer and they force you to be syntactically and semantically correct or else your model won’t “compile“. Being goaded by a piece of software into spending a ton of time looking up and learning some obscure and arcane language detail when you’re under schedule pressure to produce output is not kool. I think that’s the reason why the 80s CASE tool push failed, and it may be why the UML/SysML tools won’t take hold (without coercion) in the mainstream now.
Disclaimer: I’ve dabbled with, but haven’t actually used one of the big, formal UML/SysML tools on a “real” project, so I’m just pulling this stuff out of you-know-where. Thus, don’t believe a word I say 🙂 .
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 