Readability and writeability
A development language should be designed for convenient reading and writing by the developers that will be using that language. A general audience may have an easier time understanding an xUML model expressing requirements than, say, a C implementation of those same requirements. Still, we keep the focus of usability on the actual users of the language. The point being that we aren’t striving to please the general public. That is a fool’s errand which risks compromising the power of a language.
That said, the whole purpose of xUML is to express requirements, not implement them. So this amplifies the need for clarity of expression. We model the required processing with an absolute minimum of language artifact. Like the other xUML model facets (domain, class, state) we want the statement of requirements to shine through for critical evaluation without noisy language artifact stealing the spotlight.
Historically, development languages have taken two approaches to readability. One is to introduce a lot of verbiage into the text. Relatively chatty languages like COBOL, AppleScript and the BridgePoint Object Action Language (OAL) introduce lengthy keyword phrases in an attempt to be readable. The opposite approach is to be ultra-concise employing cryptic keyboard symbols. Old-timers are quick to raise the example of IBM’s APL language.
Scrall threads a fine line between these two approaches.
Chatty keywords that you must read and type repeatedly (such as OAL’s
select many <> from instances of <> where… are either kept short or represented by keyboard symbols. When possible, the symbols are chosen based on visual mnemonics. The Scrall
#= symbol, for example, assigns a table value.
Whereas verbosity imposed by the language itself is proscribed, verbal expression by the developer is encouraged. Scrall permits space delimiters in model element and variable names. So a variable might be named the max altitude, for example. Not only that, but class and attribute names can be referenced without having to insert underscores or using camelcase. Camelcase is discouraged since it is a compromise favoring writeability over readability. The use of an underscore trades off in the opposite direction. But spaces are the perfect read/write balance which is why we use them in everyday text.
The obvious problem with allowing spaces in names is that it leaves the language vulnerable to ambiguity with regard to keywords. For each word look ahead in a name we must classify it as either part of a name or a keyword. Thus, Scrall strives to minimize the number of keywords, favoring symbols instead. But we believe that the best readability doesn’t come from keyword verbiage. It comes from expressive names.
For example, instead of saying in OAL:
select many aircraftToLand from instances of AIRCRAFT where selected.Altitude < landingAltitude and selected.ReadyToLand;
We could say in Scrall:
aircraft to land ..= Aircraft( Altitude < landing altitude and Ready to land )
The OAL keywords
many are replaced by the Scrall multiple instance assignment operator
..=. The OAL keywords
from instances of is implicit in the assignment and
where selected is replaced by the
() selection predicate.
In fact, the only Scrall keyword in this example is
and. So, you know, don’t use
not in a name. That shouldn’t be asking too much of the modeler or anyone who has written a line of code in their life.
Scrall encourages natural reading model element names. Compare the code like names
AirTrafficController to the more natural
Air Traffic Controller.
The parsing issue can be simplified somewhat with a two-pass solution. A first pass through the action language text can shrink-wrap all of the names, by say inserting underscores or camel-casing prior to feeding the result into a more conventional parser.
It’s a little more complicated than that since you still need to follow grammar rules to ensure that names are correctly isolated. But, if we can pull it off, the reward of a highly readable and writeable language should be worth the effort.