Support path expressions to specify derived associations.

When developing a single application with just a few targets, having a single directory to maintain all the code is fine. But once one needs to develop more than one application and share code among them, it is necessary to separate the common code. Also, some applications cover different domains, and it may be beneficial to separate the code for each domain.

In order to allow that, CML supports modules. Each module is a directory containing three sub-directories:

• source: where the CML resides.
• templates: optional directory containing templates for code generation.
• targets: created by the compiler to contain the each target sub-directory, which in turn contains the code generated for a given target.

Under the CML source directory, the module will be defined by a module block. If a module needs to reference source in other modules, then an import statement should define the name of the other modules. The compiler will then compile the imported modules before compiling the current module.

In order for the compiler to find the other modules, they must be in a directory with the module's name under the same directory where the current module is located.

CML modules have no versions as they are maintained in the same code repository with the other modules they import. However, one can package a module as a library, which will have a version and the same name as the module. This library in turn can be published into a public (or company-wide) CML library site in order to be shared with other developers.

A module can also import a library, but its version must be specified along with its name. If a import statemement does not specify a version, it is assumed it is a module located in the same code repository; not a published library.

Acceptance criteria:

• Targets have a name (used to determine which target to generate) and a type (used to determine which templates to use for code generation).
• Calling the cml command compiles the module in the current dir. Only argument is the target name.
• A module declaration defines which modules to import. All top-level declarations (except for modules themselves) are elements of the module whose source directory they reside in.
• The imported modules are also loaded into the model.
• A concept may specialize concepts of another module.
• A type declaration may reference a type from another module.
  -- [ ] Transitive dependencies for concepts are necessary.
• Errors are reported for:
  -- module name not matching the module's directory name.
  -- ancestor not defined in current module, or in imported modules.
  -- concept in type declaration not defined in current module, or in imported modules.
• Move the base templates into a base module.
• A task can use a constructor from an imported module.
  -- [ ] An error is reported if two imported modules have constructors with the same name.
  -- [ ] Transitive dependency is not allowed for constructors.
• A module may use a task declared in an imported module.
• A template can import templates from another module by specifying the module's name in the import statement.
  -- An error is reported if the module declaration does not have the module in the import path of the template. (That means there is no transitive dependencies for template imports.)
• A constructor may choose whether the concepts of imported modules should be generated as well.
• A module may use concepts defined in the base module.

When one wants to share a module with other developers, the module can be packaged as a library and published into a public (or organization-wide) library repository.

A CML library is just a packaged, read-only module with a version. Any CML module can import a library by specifying the module name and a version.

A version has the format: revision[.accretion][.fix]

Where:

• revision is the number of a library release incompatible with any previous releases with a lower revision number.
• accretion is the number of a library revision compatible with any previous accretion number of the same revision.
• fix is the number of a library accretion that fixes an issue in a previous library accretion.

Compatible versions do not break the library's interfaces but only add new features. Fixes cannot change the library's interfaces at all. The rules should be enforced by the compiler when packaging and publishing (that is, releasing) new versions of a library.

Support arithmetic for primitive types to define the initial values of attributes.

Properties are a simple way to define one-directional associations. However, sometimes it is necessary to specify that two one-directional associations should be bound into a single bi-directional association, so that changes in one are reflected in the other.

Acceptance Criteria:

• Code generated in Java that implements the semantics of a bi-directional association.
• Same for code generated in Python.
• Required for CMLC target only.
• NTH: the POJ target.