Unit Management

Since this implementation is not embedded in a UML tool, Alf units are managed as files. Units may refer to each other by name, and such references are then resolved to the corresponding files. Certain kinds of units (activity definitions and active class definitions) are then executable.

Unit Resolution

During the static semantic analysis of a unit, if an element of another unit is referenced, then that unit is parsed into memory on demand from the file corresponding to the unit in order to continue the checking of the original unit.

Each Alf unit is expected to be contained in a single file, and each such file must contain exactly one Alf unit. The files are contained in a directory structure based on the qualified names of the units.

The Model Directory

All user unit files corresponding to a single "user model" should be placed in a model directory structured as described above. By default, the model directory is the Models subdirectory of the installation directory, but this may be overridden using a command line option.

For example, with the default location for the model directory, a package with the qualified name

'Property Management'::'Data Model'::Properties

would be expected to be found in the file

Models/Property Management/Data Model/Properties.alf

Subunits of Properties are then found in the corresponding subdirectory

Models/Property Management/Data Model/Properties

The file Properties.alf contains the Alf definition for the Properties package, while the subdirectory Properties groups the files for subunits of that package (e.g., the class Properties::Property is found in the file Property.alf in the Properties directory.).

Note that all characters in an unrestricted name (but not the surrounding quote characters) are currently carried over to the file path without change. Thus, characters that cannot be supported in file names must be avoided in unit names.

All namespace declarations are currently expected to resolve to Alf units. Therefore, only units without namespace declarations are considered to be model units. The model scope for such units is all the model units within the same model directory (i.e., "in the same model"). Thus, one model unit may refer to another model unit located in the same model directory, without the need for explicitly importing the other unit. References to any other elements of another unit requires an import from the other unit (which is done implicitly for units from the Alf library). Note, however, that any elements imported into a unit are also available to all subunits without those subunits having to also import them.

The Library Directory

The library directory contains Alf source and compiled UML versions of Foundational Model Library and the Alf Standard Model Library. These files should not be moved from the library directory structure or changed. By default, the library directory is the Libraries subdirectory of the installation directory, but this may be changed using a command line option or by setting the ALF_LIB environment variable.

The alf subdirectory of the library directory contains the Alf source units for the Foundational Model Libraryand the Alf Standard Model Library. For example, with the default location for the library directory, the standard package Alf::Library::PrimitiveBehaviors is found in the file

Libraries/alf/Alf/Library/PrimitiveBehaviors.alf

Subunits of PrimitiveBehaviors are then found in the corresponding subdirectory

Libraries/alf/Alf/Library/PrimitiveBehaviors

The uml subdirectory of the library directory contains compiled versions of the fUML Foundational Model Library and Alf Standard Model Library implementations, as Eclipse UML2 files.

Finally, the resources subdirectory of the library directory contains additional resources required to support running the reference implementation. Currently, the only such resource is the error-messages.txt file that provides readable error messages for static-semantics constraint violations.

Unit Execution

To be executable, a unit must be the definition of either an activity with no parameters or a non-abstract active class with a classifier behavior. Execution of such a unit proceeds as follows (see also the Command Line Scripts used to initiate unit compilation and execution):

1. The specified unit is parsed into an abstract syntax representation. Any units imported by the specified unit are also, recursively, parsed. If there is a syntax error, this is reported and processing ends. (Note: Since units cannot be "pre-compiled" when using the fUML Reference Implementation, all library source units are parsed and loaded on each execution. When using the Eclipse implementation, the pre-compiled library models are used instead.)

2. All parsed units are checked for violations of the abstract syntax constraints defined in the Alf specification. If there are any constraint violations, they are reported and processing ends. Constraint violation messages are grouped by source file and, for each violation in a file, identify what the violation was and where it occurred.

   For example:

    /Models/Hello.alf:
   
      WriteLin("Hello World!");
      ^
    [2:3] Behavior or feature reference cannot be resolved. (behaviorInvocationExpressionReferentConstraint)
   

   This indicates a constraint violation in the file Hello.alf, on line 2 at column 3. The appropriate line of text from the source file is also shown, with a pointer to the column position. behaviorInvocationExpressionReferentConstraint is the name of the violated constraint, as given in the Alf specification. (Note: Some constraints have additional conditions implemented over what is currently given in the specification.)

   If the file name is shown with a suffix of the form <...>, this means that the constraint violation happened in an instantiation of the template contained in the indicated file. This should only happen if the error actually exists in the template being instantiated. (Note: No source text is shown when a constraint violation is reported from a template instantiation.)

3. All parsed units are mapped to fUML. If the fUML Reference Implementation is being used, this mapping is to an in-memory representation. If the Eclipse UML2 implementation is being used, the fUML output is written to an Eclipse UML2 file. (Note: If a mapping error occurs, processing ends. However, if there are no constrain violations, mapping should always succeed, so a mapping failure indicates a system implementation error.)

4. If the fUML Reference Implementation is being used, the unit is executed immediately after compilation. If the Eclipse UML2 implementation is being used, then the output Eclipse UML2 file can be executed after compilation. In either case, on execution, an execution environment is created at a fUML locus, and the unit mapping is executed in this environment. The console is used for standard input and output. Execution tracing is at the specified debug level, to the console and the file alf.log (unless this configuration is changed in log4j.properties). (Note: Execution tracing is currently only available for the fUML Reference Implementation.)