Skip to content

Codebase Modularization & Architecture: Overriding Core Rules

In an enterprise environment like Norwegian or Lufthansa, you do not write all your Rave code in a single file. An airline's rule set is massive, and maintaining it requires strict separation of concerns.

Furthermore, Jeppesen provides a "Core" set of standard aviation rules. Airlines take this core and use modular language composition (referencing, extension, and embedding) to adapt it to their specific Collective Bargaining Agreements (CBAs) without making invasive modifications to the base language.


1. Separation of Concerns (Viewpoints)

A domain is typically composed of different concerns, and a good DSL architecture separates these into different viewpoints or modules.

For example, European Flight Time Limitations (EASA FTL) apply to every European airline. However, Norwegian's specific union pay rules only apply to Norwegian.

  • Best Practice: Keep EASA rules in a fll_easa.rave module and union pay rules in a cba_norwegian.rave module.
  • This allows different stakeholders (regulatory compliance officers vs. payroll analysts) to manage their respective concerns independently.
graph TD
    Core[Jeppesen Core Framework<br>Basic hierarchy and traversers]
    EASA[EASA FTL Module<br>Strict Legal Constraints]
    CBA_Pilot[Norwegian Pilot CBA<br>Union Pay Rules]
    CBA_Cabin[Norwegian Cabin Crew CBA<br>Union Pay Rules]

    Core --> EASA
    EASA --> CBA_Pilot
    EASA --> CBA_Cabin

2. Modularity via Import and Extension

Rave allows you to compose languages and rule sets using import statements. A module can extend another module to add new abstractions or override existing ones.

// MODULE: cba_norwegian_pilots.rave
import fll_easa;
import standard_costs;

// Here we extend the base environment with our specific constants
CONSTANTS:
  %pilot_hourly_rate% = 120.00;
ENDCONSTANTS

3. Overriding Rules (The "Adapter" Pattern)

Sometimes, the base EASA rule allows a 13-hour duty, but your pilot union agreement strictly caps it at 12 hours. Instead of invasively modifying the core EASA file (which breaks future software updates), you create an adapter or override in your airline-specific module.

// Overriding an inherited property or rule
OVERRIDE rule max_duty_flight_time =
  // We use the stricter union limit instead of the EASA limit
  sum(leg(duty), %leg_duration%) <= 12:00;
end
By utilizing incremental language extension, developers can fall back to the base language rules while adding higher-level, airline-specific abstractions. This avoids the "DSL Hell" of duplicating thousands of lines of code.