We’re here to help you

Menu

Simplest Usable Dezyne System Model

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.

  • The LEDSwitchSystem we defined above can also serve as a component if it is outfitted with at least one provides or requires interface to communicate with its environment. Any higher-level component can instance and use any other component as long as 1) no name-space conflicts result and 2) all verifications succeed, which means in particular that there is no recursion.

  • The order in which instances “led” and “switch” appear in the system block does not matter, nor do the order in which mapping instances appear in the same block.

  • Dezyne uses the term “port” to mean an instance of an interface, but “port” is not a keyword in the language. In each port binding, by convention you probably should map requires on the left to provides on the right, though Dezyne accepts either order. The last line of the system block above binds the switch’s required port to the LED’s provided port, establishing the link between the caller and the called function.

  • This tutorial by convention uses the same user-defined port local name for the provided interface as for the required interface in another component, as a simple visual consistency check when binding at the system level. You do not have to use this convention.

  • When you verify, the choices of what can be verified have not changed from having added the Switch component or the LEDSwitchSystem component. Only the LED component and its ILED interface can be verified. Also, systems-level components cannot be verified or simulated, only interfaces and components that have explicit behaviour can be. Future versions of Dezyne will support system verification and simulation.

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.

If you have questions that weren’t answered by this Guide,
let our support team help you out.

Enjoy this article? Don't forget to share.
google-site-verification:google656c7703ab521151.html