A simple class model example

File structure

The overall file structure is as follows:

metadata (optional) – Title, author, version, etc
subsystem - Just a header with the subsystem name
classes - Class names, attributes, methods
relationships

Let’s take a look at these in a simple example.

Here is a ‘hello world’ example so we can see how all the pieces fit together. A possible diagram layout for this example could look like this:

We aren’t going to encode any layout, style or notational information in the model markup file. This layout is just to give you a visual reference from which we’ll extract the and script the semantic model content.

Metadata

Before we start scripting the model itself, we might want to supply some metadata about the modeled subsystem. For this example we’ll just put in a few data items:

/// Hello world aircraft class model example
metadata
    Title : Hello World Example
    Author : Leon Starr
    Organization : Model Integration, LLC

We start off our file with a comment. They are optional and you can sprinkle those in anywhere. Just preface your comment with three slashes. Yeah, I know, why not two? The problem is that we will eventually include action language in our model file and comments beginning with two slashes will be embedded in that. And we can’t use the # sign because the action language makes use of that symbol. So three forward slashes it is.

The metadata section begins with the unindented metadata keyword. After that we just have a list with the pattern:

<field_name> : <text>

Where the field name is alphanumeric and may have spaces in it, so Creation date : 04/11/2021 would be perfectly legit.

You need to indent four spaces (exactly four) for each metadata field specification.

You may invent any field name you like. You aren’t restricted to any subset. But when you go to build your layout sheet, you will need to specify a frame that has a field with the same name if you want to see the data displayed in a generated diagram. See the model layout sheet documentation for more about that.

Subsystem

The subsystem keyword is required. It follows the optional metadata section, if you’ve provided one, otherwise it is at the top of the file.

subsystem Test

This is a one-liner with the unindented subsystem keyword followed by a single space and then the name of your subsystem. The subsystem name must start with an alpha character and may have spaces in it. So Aircraft Test 1 would work as a subsystem name.

Classes

This next section is also required and it is where we will specify the data for each class.

class Aircraft, AC
attributes
    Tail number : ACAO {I}
    Altitude : Altitude MSL
    Airspeed : Knots
    Heading : Compass
--
class Pilot
attributes
    ID : Pilot ID {I}
    Hours flown : Hours
    Aircraft {R1}
--

Here we have our two classes. Each class subsection specifies a required name and optional alias after the unindented class keyword. The alias for Aircraft is AC. The Pilot class does not have an alias specified.

The next line after the class name is the unindented attributes keyword. In Executable UML a class must have at least one identifier and an identifier consists of at least one attribute. Consequently, every class must specify at least one attribute.

Currently, the attribute text indented below the keyword is opaque to the parser. Since our current objective is just to use the model data to generate a class diagram, the attribute content doesn’t yet matter. You just need to ensure that each line is indented by four spaces.

You need to end each attribute subsection with two unindented dashes --

We don’t have any in this example, but you may provide a methods subsection after the attribute subsection. It is structured similarly.

Relationships

The final section is optional since it is perfectly legal, albeit rare, in Executable UML to define a model with unrelated classes. In our simple model there is only one relationship to specify.

relationships
    R1
    is flying, 1 Aircraft
    is flown by, 1 Pilot
--

The relationships keyword is unindented and is then followed by one or more relationship specifications. The one we specify above starts with the relationship name, R1 indented on a line by itself. The next two lines specify each side of a binary association with the syntax:

<indent><phrase>, <multiplicity> <class_name>

Each is indented and begins with the descriptive verb phrase terminated by a comma. This is followed by a single space, the multiplicity of the association a single space and then the class name. Be sure to use only a class name that is specified in the class subsection.

Putting it all together, the entire file content is:

/// Hello world aircraft class model example
metadata
    Title : Hello World Example
    Author : Leon Starr
    Organization : Model Integration, LLC
subsystem Test
class Aircraft, AC
attributes
    Tail number : ACAO {I}
    Altitude : Altitude MSL
    Airspeed : Knots
    Heading : Compass
--
class Pilot
attributes
    ID : Pilot ID {I}
    Hours flown : Hours
    Aircraft {R1}
--
relationships
    R1
    is flying, 1 Aircraft
    is flown by, 1 Pilot
--

As more Flatland features are added, the model markup language will be extended to include an entire Executable Model with all state, activities, domain operations, external entities and so forth. (In fact, it already does, but hasn’t been tested yet in conjunction with the Flatland layout engine). So for a short while it’s just the class model information.

A simple class model example - modelint/flatland-model-diagram-editor GitHub Wiki

File structure