-
Notifications
You must be signed in to change notification settings - Fork 0
Class name
After the domain and subsystem we specify any number of classes and their attributes with this grammar:
// Classes
class_set = class_block* // All classes in the subsystem
class_block = class_header attr_block block_end
class_header = "class" SP class_name class_alias? import? EOL*
class_name = icaps_name
class_alias = ',' SP+ acword
import = SP+ '<import:' icaps_name '>' // Import marker and name of origin subsystem
class_name = icaps_name
The full set of class definitions is the class_set term with
each individual class definition as a class_block term.
Here is an example class definition:
class Accessible Shaft Level, ASLEV
attributes
Floor : Level Name {I, R3}
Shaft : Shaft ID {I, R3}
Bank : Bank Name {R3c}
Stop requested : Boolean
--
You can see that it consists of a class name corresponding to the class_header term which
must be followed by exactly one attr_block. Here we'll focus on the line with the class name.
There is an unindented class keyword followed by the full class name. Each word in the class name should start with
an uppercase letter with the exception of interstitial minor words which can be all lower case.
After the name there are a couple of optional items.
Most classes don't need an alias, but it can be handy for a class with a long name such as we have in this
example. Note the ASLEV alias is specified. For a class, the alias is helpful when naming event sources
in the state model. They are also helpful when defining scenarios
and in keeping the model debugger session logs from getting too verbose.
The xcm file defines the content of only one subsystem, but a relationship may span across multiple subsystems within a domain. While the class or classes on the other end of a spanning relationship may be defined in some other subsystem, we can import the reference here for the sake of defining the relationship if it is in fact defined in the current subsystem.
The general idea, by the way, is that a model component is defined in exactly one subsystem, but may be referenced from other subsystems within the same domain.
For an import example we can take an excerpt from the Shlaer-Mellor metamodel itself (the modeling language is itself modeled in multiple subsystems and xcm files).
class Effective Event <import:Event>
Any alias should be omitted, but the source subsystem is named between the angled brackets after the import
keyword and a colon, no spaces. This tells us that the class named Effective Event is defined in the Event
subsystem xcm file defined in the same domain.
Copyright 2023-2026 © Leon Starr under MIT Open Source License