Language keywords: requires system

Operator: <=>

We first extend the LED model by adding a switch component that switches the LED on and off. The switch requires the ILED interface in order to call the LED component and change the light’s state. Again, commenting and whitespace in Dezyne work the same as in C/C++/C#/Java.

Step 1. Enter or copy-paste the new Switch component into the complete ILED-LED model, as shown in the below code sample. You can either import the ILED interface .dzn file or include the ILED code as here, but if you import then the import statement must precede all other statements.

component Switch {
  requires ILED iLed; // "requires" means calls ILED functions
}
interface ILED {
  in void turnOn();
  in void turnOff();

  behaviour {
    on turnOn: {}
    on turnOff: {}
  }
}
component LED {
  provides ILED iLed; /* "provides" means implements ILED functions */

  behaviour {
    on iLed.turnOn(): {}
    on iLed.turnOff(): {}
  }
}

You can declare components and interfaces in any order in a Dezyne model. In the above, the Switch component requires the ILED interface but the Switch component definition precedes the interface definition.

Step 2. Verify the above code. Notice that the Switch component does not show up in the list of verifiable items – because it defines no behaviour. Nothing has really changed in this Dezyne model; we’ve only added a hand-written Switch component that we intend to connect to the LED.

Step 3. “Wire” the two components into a system as shown in the below diagram and model code. A Dezyne “system” is a component that instances other components and connects their interfaces. Wiring amounts to binding each requires interface instance (port) to a corresponding provides instance (port) for the same interface, via the Dezyne <=> operator.

image

component LEDSwitchSystem {

  system {
    LED led;
    Switch switch;
    switch.iLed <=> led.iLed;
  }
}
component Switch {
  requires ILED iLed; // "requires" means calls ILED functions
}
interface ILED {
  in void turnOn();
  in void turnOff();

  behaviour {
    on turnOn: {}
    on turnOff: {}
  }
}
component LED {
  provides ILED iLed; /* "provides" means implements ILED functions */

  behaviour {
    on iLed.turnOn(): {}
    on iLed.turnOff(): {}
  }
}

Step 4. Study the following important points one by one. They are essential to your understanding.

Step 5. Bring up the System View (in Eclipse, menu Window / Show View / System View) to display the wired system as shown below. Clicking the top-left button next to the string “LEDSwitchSystem” displays or suppresses the system internal structure, as shown below. Clicking the “wire” between the Switch and LED highlights the line of model source code that binds these two ports together.

image

In Dezyne-generated system/subsystem diagrams like the above, the “wires” – i.e. the requires-provides connections – are drawn top down, as the blue/black arrowheads indicate. In this simple system, the LED provides the interface for the Switch to set the light state to on or off. Later we will build composite subsystems in which “wires” are actually “buses” in the electronics sense, carrying multiple connections going top-down, or equivalently outside-in, among system components. Ultimately every chain of arrows terminates in a leaf component that provides an interface.

Step 6. View the component’s State Chart, shown below (Window / Show View / State Chart View). Though you have not yet defined any state behaviour, Dezyne still tracks state as it perceives it. This component never leaves its initial state. The next section discusses state management.

image

Dezyne Diagrams and Traces Both Validate and Document a System

Consider the value of the system diagram, the sequence diagram and the event trace. Together they validate the core system as modeled. They can serve as specifications and documentation for whoever will integrate and test the Dezyne-generated source code in the whole hardware and software system.