I introduced myself in my previous entry, so now the focus shifts to my latest hobby, a new executable UML action language, which I am calling ‘Scrall’.
Scrall stands for ‘Starr’s Concise Relational Action Language’ with an extra l to encourage the desired pronunciation and without the CAPS LOCK key stuck. And I will just apologize right now for putting my name in the title. I spent about half an hour with the dictionary trying to find a better word and after discarding: ’schematic, syllogistic, sexy, surreal, synergistic and surreptitious’ I gave up. ’sexy’ was pretty tempting, but ultimately, false advertising.
When I say ‘Executable UML’, I mean…
Scrall does not support just any Executable UML. Scrall is targeted toward those executable UMLs on the Shlaer-Mellor evolutionary branch. These include xtUML and especially miUML.
If you are already familiar with Shlaer-Mellor, you may want to skip ahead to (or wait for) my next blog entry. For everyone else, I need to set a little context before you start throwing tomatoes at my new language.
What is Shlaer-Mellor Executable UML?
Shlaer-Mellor is a modeling methodology designed by Sally Shlaer and Stephen Mellor based on class, state and activity models that significantly predates1 UML. With the standardization of UML in 1997, Shlaer-Mellor adopted the notation and took on the xUML, iUML and xtUML and Executable UML monikers. (I will call them sm UMLs from here on). Despite a new name and notation, the sm UMLs retained their unique executable semantics and mathematical foundation, including an informal early action language.
Shlaer-Mellor’s focus on things that mattered: detail, logical constraints, subject matter separation (domains), executability, platform independence and efficient code generation and lesser concentration on graphical notation and vague terms like ‘high-level’ (both of which were all the rage at the time) drew me to Shlaer-Mellor and has kept me using it all these years.
UML Action Semantics
The initial UML standard included activity diagrams, but without executable action semantics you can’t run activities (in the code sense) and you can’t systematically map them to code elements. Shlaer-Mellor already had that piece, so there was no way for it to conform to the UML standard without discarding that and defeating the whole point of the methodology. This is what led Steve Mellor to approach the OMG and propose the definition and inclusion of action semantics in the UML standard. Ed Seidewitz explains how that transpired in his excellent post as well as how UML action semantics ultimately led to FUML and Alf.
Shlaer-Mellor compatible Action Languages
Alf looks like an excellent general purpose executable UML language. I say ‘looks like’ because my only experience with Alf involves printing out all 500 or so pages of the spec and skimming through it. For more years than I want to admit I have been using OAL (Object Action Language) which is part of xtUML. This is because it specifically supports Shlaer-Mellor and, more importantly, is integrated into a tool (BridgePoint) that does the same, not because I’ve ever liked it all that much. That said, both Alf and OAL are well defined and actually work, which is a lot more than I can say for Scrall at the moment.
I’ve always considered OAL to be a nice start but, sadly, it never evolved much. I would have loved to have used SMALL (Shlaer-Mellor Action Language) on a real project, but it was never integrated into any tools, as far as I know. SMALL has been a huge inspiration for Scrall, however. Now, whether Scrall will become real, just be another ‘prototype’ language, or even get a cool logo or animal mascot is unclear. Nonetheless, if you want something done right…
How Scrall could make life better for modelers and model reviewers
I have a number of goals driving the syntax and capabilities of Scrall. Here are a few of them. Please recognize that I when I use the term ‘action language’ I am thinking OAL, which I know pretty well, and not Alf which I don’t. The principles should still hold, but to varying degrees.
Describe the application behavior, not the model mechanics
I have seen a lot of action language concerned with the tedium of hopping across relationships and needlessly iterating which gets especially bad on reflexive associations (association to and from the same class). It should be much easier to say things like: ‘get that thing related to me’, or look up a,b in my spec or ‘get the first task in my list that is has no agent unassigned to it’. And when you read the actions, what is being done should be more obvious than how it is being done.
Unlock the full power of Shlaer-Mellor relational semantics
As I’ve stated, Shlaer-Mellor is built on strong relational, mathematical foundations. Scrall provides seamless integration of objects, relations and types with all of the relevant operators. It has been argued that things like relations, identifiers and referential attributes are too intimidating for engineers with an object oriented programming background. Well, %&*# that.
1) We’re modeling application subject matter, not writing Java.
2) A lot of programmers shouldn’t be building models in the first place. Analysis and modeling are distinct jobs at a different level of abstraction. If you love writing C++, then go write C++.
3) A book entitled ‘Action Language for Dummies’ is a fine idea. But you don’t design a language based on the needs of its least experienced users.
4) Software engineers are smart people. Provide mathematically consistent building blocks and, no matter how strange they may be at first, model developers will figure them out and put them to good use2.
Say more with less
One reason we build models instead of writing code directly is to expose the underlying logic of a subject matter and keep it exposed. This makes it easier to maintain a large, complex system over multiple years. So readability is more important than writability. But, only just.
Productivity is also critical, and it should be painless to write a bunch of readable action language quickly. It is important, then, to avoid introducing hard-to-type (or spell) keywords, excess verbosity and bizarre APLish symbols.
In comparison to equivalent OAL activities, you should realize anywhere from a 2:1 to 10:1 reduction in the amount of action language you need to write. An ongoing re-write of my Elevator Case Study and other models is, so far, encouraging in this regard. And yes, I will be posting before-after examples.
Your mileage may vary.
A language not afraid to say ‘No’.
You cannot design a language that polices itself against bad behavior. Anyone can subvert the principles and idioms of a language to do questionable things. And sometimes you need to color outside the lines a little to get the job done. THAT SAID, certain practices that might be common in a programming language are bad news in a platform independent model. A language can be designed to make such practices so painfully awkward that they are no longer tempting and easily flagged when they do occur.
And, yes, I do have something specific in mind, but I’ll have to save that for an upcoming post. In the meantime, you are invited to guess.
All natural with no artificial sequencers!
As Ed Seidewitz points out, the modeler should specify sequence only when the subject matter demands that it be enforced on all platforms. All other sequencing decisions are up to the model compiler and model execution architecture.
Great Leon, where’s the code?
Yeah, yeah, I know. Rest assured, I have plenty to show, but I wanted to get this preamble out of the way first.
I am known to preambulate.
No worries! All the fun starts in NEXT WEEK’s blog entry where I will begin introducing the language elements with many colorful examples. Get your tomatoes ready.
I help agile software teams succeed with requirements analysis, domain definition, platform independent, executable modeling and high quality code generation. Other websites: executableuml.org, modelstocode.com