-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Scrall is an action language designed to fully leverage the powerful semantics of Executable UML (xUML). The semantics underlying most usages of UML have been loosely or tightly shaped by object oriented design and programming principles. xUML is distinct in that it is built primarily on mathematical foundations. These foundations are the relational model of data (sets, functions and predicate logic) for the class model, distributed networking theory for the state models and data/control flow semantics for activities.
Both requirements analysis and code generation goals benefit from a modeling language that does not seek to impose its own design assumptions. Mathematics provides a neutral ground upon which to specify such a language.
xUML was designed from the start to support real-time and embedded applications starved for computing resources where an object oriented implementation was not necessarily a preferred or workable solution. So great care was taken to remove any object oriented bias from the design and implementation while preserving those aspects of an object oriented perspective that were beneficial in analysis and system specification.
The xUML semantics do not presume an object oriented programming language on the target platform. Design concepts of namespaces, pointers, inheritance, constructors/destructors, etc. are absent from the xUML language. And yet there are no built-in impediments to using those same design concepts in any given implementation. Further, there is no bias in xUML toward any particular degree of implementation concurrency. Formulated properly, xUML models should specify the maximum possible concurrency (in other words they don’t introduce any unnecessary sequencing) in the system specification. Any subsequent design can introduce as much sequencing as is desired (running everything in a single main loop, for example).
Similarly, Scrall rejects any object oriented assumptions since it deals directly with the xUML semantics. It doesn’t support object pointers, for example, since there is no notion of “memory” in the relational world. Instead, functions are used for mapping elements. There is no support for null values since, in set theory, an element either exists or it doesn’t.
There is of course no problem with a given implementation built on such concepts, but they have no place in a platform independent system specification!
The key inspirations for Scrall are the Small (Shlaer-Mellor action language) proposal, C.J. Date’s writings on relational theory (see bibliography) and Andrew Mangogna’s [Rosea and Micca] model compilers. (If you write your actions in Scrall, the transformation into Rosea or Micca statements which generate C code is straightforward).
Additionally, years of frustration with the inherent limitations of BridgePoint’s ([xtUML]) Object Action Language (OAL) have been a driving force. That action language as well as its British cousin Action Specification Language (ASL) were a great first step, but neither evolved much beyond their original formulations. Each of these first generation action languages were a great step forward in their time. But they only scratched the surface and never unlocked the deeper semantics that Sally Shlaer and Stephen Mellor originally envisioned. Each of these languages was introduced with unnecessarily restrictive type systems and wriggled out of the restraints over time with hopelessly ad hoc type extensions.
Scrall takes C.J. Date’s approach where the type system is considered to be orthogonal to the relational system. Thus Scrall washes its hands entirely of providing a type definition language facility. Scrall does, however, provide a syntax that accommodates arbitrarily complex types and the operations supported on those types.
It stands for Starr’s Concise Relational Action Language with a gratuitous ‘l’ to guide the pronunciation (sounds like “awl” not “Al”). Many years of scrawling out pseudo-code actions on the whiteboard are the inspiration for the pronunciation.
It’s a simple language. If a chicken can scrawl, so can you!
Until now, the work on Scrall has been focused on developing a consistent and lean concept for expression, making the language practical for reading and writing and ensuring that the xUML semantics are fully supported.
The next step, in progress as of this 1.0 publication, is to specify a formal PEG grammar. This effort will no doubt lead to a number of syntax adjustments as points of potential ambiguity are uncovered.
That said, we encourage you to begin using Scrall as a pseudocode for writing xUML activities. Feel free to report your progress or any issues you encounter. You can use Scrall in the comments of your action language to clarify what you are trying to accomplish. We took this approach in our book Models to Code. You should be able to accomplish in just a few lines what may require numerous awkward lines in first generation xUML action languages. Hopefully, thinking in the set, relational and concurrency terms of Scrall will make it easier solve problems and build more powerful models.
Copyright 2020, 2021, 2022, 2023 © Leon Starr under MIT Open Source License
- Why they are problematic
- Instance attribute creation values
- Boolean values
- Special values
- Enumerated values
- Action block
- Statement
- Single line action
- Multiple dependent actions on a single line
- An action spread across multiple lines
- A conditional group of single line actions
- Comments
- Finding instances
- Attribute access
- Creation and deletion
- Subclass migration
- Creating a table from a class
- Creating a table with a definition
- Converting a table into a class
- Set operations on tables
- Set comparisons on tables
- Join
- Rename
- Extend
- Aggregation
- Rank
- Image
- Input values
- Signatures and name doubling
- Output values
- Execution order
- Sequential execution
- Conditional execution
- Signals
- Scrall has no for_each action
- Iteration