quenio / cml-old Goto Github PK

This section presents an overview of the conceptual modeling language. The concrete syntax will be presented using examples. An appendix is available with a formal description of the concrete syntax. The abstract syntax will be presented in subsections; each one focusing on a key concept of the language's metamodel.

Before exploring the abstract syntax, a concrete example is displayed and commented below:

[example]

[Describe the example and the also mention it was brought from the OOADIS book.]

The model specified by the example above will be parsed and instantiated by the CML compiler into the following abstract syntax tree:

[AST of the example]

The model above can also be represented as the following ER model:

[ER model]

The model can also be shown as the following UML class diagram:

[UML Class Diagram]

Thus, the focus of this language is to enable the specification of conceptual models, such as those specified by ER [reference] models and UML [reference] class diagrams. In [article], [Author] shows how UML models, augmented by OCL constrains, can be used to specify conceptual models by mapping their metamodel to the ER metamodel. In order to present the CML concepts in the following subsections, a similar approach will be used by mapping the CML metamodel to the UML/OCL metamodels.

Subsection: CML Abstract Syntax (Metamodel)

Below, you can see an overview of the CML metamodel in a UML class diagram (footnote: now used to model the CML metamodel, as opposed to modeling an instance of a CML source file --- a CML model), where each class represents a CML concept:

[diagram]

[Describe the relationships between the concepts in the diagram]

[Subsection for each key concept in the CML metamodel.]

Enumerate the relevant scientific papers and dissertations from periodics and events. Make sure only references actually cited are included.

Single cardinality.

Abstract concepts are only inherited and they are never instantiated directly. They may also contain derived attributes whose definition is deferred to the sub-classes.

In CML, a concept may be defined as abstract by using the "abstract" keyword before the "concept" keyword.

During code generation, no code needs to be generated to allow their direct instantiation of abstract concepts by clients.

Acceptance criteria:

• The "abstract" keyword can be used in CML before the "concept" keyword to define a concept as abstract.
• In the CMLC target, the abstract concepts will have create methods and constructors that accept the instances representing the inherited classes as parameters. Concrete concepts will instead instantiate the base classes in the constructor.
• In the POJ target, the abstract concepts will be declared as abstract. The ancestors will be just inherited.

A CML target type that generates gRPC .protobuf files.

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.

Specify a module structure.

Describe the related papers and dissertations from relevant publications and events. Make it clear how the references have informed this work and how this work is expanding on them. Make sure the review also covers recent work. Do not include unrelated work. Focus on key concepts.

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 into different domains.

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 the module's 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, the must be in a directory with the module's name in the same directory where the current module is placed.

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.

Specify CML's primitive types based on C# ones.

The CML specification needs an example of a full system defined in CML as an appendix. Excerpts of this full example will also be used throughout the specification as examples of individual language constructs.

The Livir system described on the OOADIS book will be used as the full system example. That will allow determine the completeness of the example and consequently the language.

The abstract should:

• present the problem;
• justify the choice of the hypothesis;
• describe the results and/or contributions.

Complete language-agnostic templates that generate Java and Python code.

Acceptance Criteria:

• The Java clients are executing with the Java-generated code.
• The Python clients are executing with the Python-generate code.
• For each language, there is one client using the POJ target type, and one client using the CMLC target.

On top of CML itself, use CML to specify CML's type system.

Describe:

• the problem solved;
• the objectives achieved;
• the method used to resolve the problem and achieve the objectives;
• how the results have been validated in order to assert the objectives have been achieved.

Review the TCC proposal before writing the Introduction.

Problem:

• UML / OCL Conceptual Model -> Java Model
• UML / OCL Conceptual Model -> Python Model
• Java Model != Python Model
• Conceptual Model Changes -> Java / Python Models MUST change
• Java Model !!!!= Python Model

Specify the lexical tokens.

In order to verify the CML compiler's ability to generate multiple types of targets, a target type named "pojs" will be implemented to generate a JavaScript module. The generated pojs target will be - as much as possible - a one-to-one implementation of the CML concepts and interfaces found in the CML source file.

In order to verify the generated target, a simple TODO JavaScript web application will make use of it.

Specify bi-directional association declarations.

require, ensure, for, given, let, ...

Specify property declarations.

Describe the results of each specific objective achieved. Make sure the results are tied to each objective presented in the Introduction.

Specify the CML's well-formedness rules as invariants of the CML model concepts.

Proposes a textual programming language that enables conceptual modeling similarly to UML classes/associations and OCL constraints, and a compiler that allows code generation to any target language or technology via extensible textual templates. Together, the language and the compiler make it feasible to specify in a single high-level language the information of ever-changing, increasingly distributed software systems. The automated code generation from this single source keeps the implementations - across the different platforms and technologies - consistent with the specification. Also, as the technology landscape evolves, these textual models allow the recurring use of the investment made on their specification. Unlike other approaches, such as MDA, the textual nature of this programming language, and its built-in tooling support, can be integrated to the workflow of software developers, which is expected to facilitate its adoption.

A set of very small examples, each demonstrating a single construct provided by CML.

The examples should evolve incrementally from previous ones, but should be trimmed as much as possible in order to keep them simple.

If needed, new incremental flow may be started in order to keep the examples as simple as possible.

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.

The CML compiler will receive three arguments:

• The path to the source directory, which contains the source files.
• The path to the target directory, which will contain the generated files.
• The type of target to be generated.

In the source directory, the compiler will look for the CML source file named: main.cml

The CML source file will be compiled and the target will be generated in the target directory according to its target type.

The target type is used to find the directory containing the StringTemplate files that will generate the target. It is also used to find the target properties in the CML source file.

The target properties file will provide some properties to be used during the code generation. These properties define names for the generated files. They also define other information required by generation that are not available in the conceptual model provided by the CML source file. Each target type requires a different set of properties based on the needs of its StringTemplate files.

Initially, only a single target type will be available: poj (meaning: plain-old-java)

A poj target will be - as much as possible - a one-to-one Java implementation of the CML concepts and interfaces defined in the source CML file. The generated poj target can then be used as a library in any Java application. The intent is to initially have a simple target type in order to advance the design of the language, and to put in place the code generation infrastructure. So that the poj target can be verified, it will be used to generate the source of the CML compiler's AST.

Acceptance Criteria:

• Given a main.cml file containing only concept names and the poj target properties, invoking the compiler with the poj target type will generate corresponding Java empty classes.
• Invoke the compiler with a source directory that does not contain the main.cml file will display an error message saying the main.cml file was not found under the source directory.
• Invoking the compiler with a target type that does not have a corresponding StringTemplate directory will display an error message saying the target type is unknown.
• If the specified target directory does not exist yet, it will be created before generating the target files.
• If the target directory does exist, its contents will be wiped out and new files will be generated.

In the CMLC target, a concept with properties of primitive types is a single java file composed of:

• an interface with the concept's name;
• an implementation class with the concept's name, plus the suffix "Impl".
• the interface has a getter for each property, and a single static method named "create()", which contains all the properties as parameters, and instantiates the implementation class with the passed arguments.

No setters are provided, which makes the instantes immutable.

Acceptance Criteria:

• a single java file is generated according to the description above for each concept in the model.

Specify target declarations.

Specify the CML grammar on BNF, ANTLR or some similar language.

Specify type declarations.

This CML target type will generate a Spring Boot REST application.

Describe the notation used on the CML language specification.

Describe how the results claimed in the Conclusion have been implemented and tested, and how they have helped achieve the objetives described in the Introduction. Make sure that each claim is backed by experimentation and validation of its results.

Specify the CML's AST as a conceptual model in CML itself.

Specify class declarations.

In order to be able to implement the CML compiler in CML itself, a target is needed that will generate the code according to the design patterns used by compiler.

Acceptance Criteria:

• Running the CML compiler with the "cmlc" target type and the CML spec source, should generate the CML AST according to the design patterns used by the compiler.

Implement target type that generates a Python module out of a .cml file.

This module will be used from the Python REPL to interactively test the system interfaces and validate the scenarios they support.