Skip to content

Project Structure

Mike Klimek edited this page Mar 16, 2017 · 1 revision

The project contains among others the following files and folders (some are generated, e.g. after running the tests):

.
├── src       # Arden2ByteCode source code
├── test      # Implementation and specification test suites
├── dist      # Generated distributable .jar, .tar.gz and .zip files and start scripts
├── lib       # Runtime and test libraries
├── report    # Generated JUnit test reports
├── resource  # Examples (in git submodule), which are packed into the distributables
├── tools     # Build tools
├── build.xml # Apache Ant build script, for easy building, dependencies, tests etc.
├── run.bat   # Windows batch file to run arden2bytecode .class files from the bin folder
└── run.sh    # Unix/Linux bash script to run arden2bytecode .class files from the bin folder

Source folder

The src folder contains among others the following Java packages, .java and .scc files:

.
├── arden
    ├── codegenerator    # Classes to generate bytecode for java class files and methods
    ├── compiler         # Generated Parser + compiler logic
    ├── constants        # Generated Parser to evaluate simple Arden Syntax constants
    ├── engine           # Simple evoke engine implementation for scheduling events and triggers
    ├── runtime          # Runtime standard library with Arden Syntax datatypes and algorithms
    ├── EventServer.java # Simple server that can listen for external events
    └── MainClass.java   # Command line frontend
├── arden.scc            # SableCC grammar file for Arden Syntax
└── ardenConstants.scc   # SableCC grammar file for Arden Syntax constants

The codegenerator is entirely independent of Arden2ByteCode and can be used to generate bytecode for arbitrary Java classes according to the Java class File Format.

The compiler package contains the parser in the packages analysis, lexer, node and parser, which are generated by SableCC from the arden.scc file.

The constants package also contains a parser, which is generated from ardenConstants.scc. It allows parsing simple Arden Syntax constants like 5 weeks, "a string" or 1970-01-01. It is used in the StdIOExecutionContext to parse console input in response to data queries.

The engine package contains resuable engine parts to create a custom evoke engine (e.g. via cron jobs). See Scheduling for more information about Arden Syntax events and triggers.

The runtime package also contains ExecutionContext classes, which wrap all institution-specific logic, like database queries, finding Modules, writing messages, etc. See Custom Execution Context on how to create a customized execution context.

arden.compiler package

The compiler package contains among others the following .java files:

.
├── Compiler.java            # Entry point, calls other subcompilers
├── CodeGenerator.java       # Generates bytecode of a new MLM class, incl. fields, methods, etc.
├── MetadataCompiler.java    # Collects maintenance and library category metadata
├── DataCompiler.java        # Compiles the data slot as a constructor
├── EvokeCompiler.java       # Compiles the evoke slot to a Trigger[] field
├── LogicCompiler.java       # Compiles the logic slot to a logic() method
├── ActionCompiler.java      # Compiles the action slot to an action() method
└── ExpressionCompiler.java  # Used by other subcompilers for expressions

Theses subcompilers traverse the AST of a parsed MLM and emit bytecode to method stubs, that the CodeGenerator has created. Subclasses of Variable.java represent plain data variables (x := 1;), or special variables like events, MLMs or messages (msg := MESSAGE {my message};).

runtime.evoke package

This package contains multiple Trigger classes. These are necessary to evaluate at runtime, whether the conditions are met for an MLM to be triggered. Triggers are nested, e.g. the evoke statement EVERY 10 SECONDS FOR 1 HOUR STARTING 5 MINUTES AFTER TIME OF an_event; would generate this nested structure: CyclicTrigger(AfterTrigger(EventTrigger())).

MLM classes

There are multiple similar MLM classes, which can be quite confusing:

  • interface ArdenRunnable: Represents either an MLM or an Arden Syntax interface (curl := INTERFACE {curl};)
  • interface MedicalLogicModule extends ArdenRunnable: Represents an MLM.
  • class CompiledMlm implements MedicalLogicModule: Wraps the bytecode (byte[]) of a compiled MLM, allows creating instances of it via classloader and delegates calls to it.
  • abstract class MedicalLogicModuleImplementation: The compiler creates bytecode for subclasses of this class. This class is stateful and represents a running instance of an MLM. A new instance needs to be created everytime the MLM should be run, so values in variables are reset. Note that this class does not implement the MedicalLogicModule interface. It's bytecode needs to be wrapped and loaded by a CompiledMlm to be functional.