Principles

Guiding principles

Throughout the design of Scrall, when deciding on one syntax formulation vs. another, we return to the same fundamental modeling principles that have guided the design of the xUML class and state modeling languages.

1. There should be one ideal way to solve a problem, not fifteen.
2. Actions should be easy to write.
3. Actions should be even easier to read.
4. Keep the language lean, when you read an activity you want to be thinking about the logic, not the language.
5. Express the subject matter clearly and do not tell the programmer how to write the code.
6. Use consistent model level semantics.

One way, not fifteen

Many years ago one of us (Leon Starr) proposed the ‘ham sandwich’ test for a good requirements modeling language. The idea is that if you lock up two modelers in separate rooms, give each a set of requirements and slide ham sandwiches under each door, eventually you should end up with two nearly identical models. If not, what accounts for the difference? If both solutions express identical behavior, yet are formulated with different combinations of modeling elements, this tells us that the language is not lean enough. Naturally, the modelers will choose different names, but that is not a fault in the modeling language. a^2 + b^2 = c^2 expresses the same idea as x^2 +y^2 = z^2 does not suggest that math is too bloated.

This would be a different story if we were expressing a design. Diverse designs could yield the same behavior, but with different performance characteristics. Requirements analysis, on the other hand, should converge on a single ideal solution since design tradeoffs are not considered.

Easy to write

The original Shlaer-Mellor symbols for class models and domain were designed for ease of drawing on a whiteboard. It consisted of simple arrows, ovals and rectangles. UML came along and provided a load of symbology that is near impossible to draw comfortably, folders and ..*s for example. The idea was to encourage us all to rely on expensive tools for model expression.

In an effort to support standardization, Shlaer-Mellor adopted the UML notation, but the original lean notation still makes for fast, readable whiteboard scrawl.

Scrall adhere’s to the original ease of writing principle for fast whiteboard/pen scribbling.

Readability

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. Compare:

// OAL select many highAircraft from instances of Aircraft where selected.Altitude > ceiling;

With OAL, keywords, model element names and the variable are mixed together.

// Scrall high aircraft = Aircraft(Altitude > ceiling)

In the Scrall example there are no keywords at all. The text is devoted to user specified names.

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 avoided, 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. 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;

(Seven keywords)

We could say in Scrall:

aircraft to land ..= Aircraft( Altitude < landing altitude and Ready to land )

(One keyword)

The OAL keywords select and 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 and or or or not in a name.

Scrall encourages natural reading model element names. Compare the code like names Air_Traffic_Controller or 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.

To speed development, we may find ourselves omitting this feature and living with underscores and camelcase for a while until we solve the parsing problem.

Express requirements

That said, the whole purpose of xUML is to express requirements, not prescribe an implementation. This purpose 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.

Use consistent model level semantics

Scrall operates on model level semantics. Period. There are no special blocks where you can insert C or Java code.

The primary reason for this is to ensure that a change in platform technology, such as choice of programming language, has no impact on the models, especially inside the activities.