5.5.6.1 Python Native Libraries

SVM is completely implemented in the Python language [34] [35] [36]. It is possible to import libraries in the action code of a model. Those libraries can be Python standard modules [37] or user-defined libraries. For example, the following piece of code defines several functions in a library (saved in file lib.py):

def func1():
...
def func2(a, b, c):
...
import sys
def func3(x, y=0):
...

To import this library into an SVM model, include action import lib in its initializer, and make sure that lib.py is in the same path as the model or can be found in the PYTHONPATH environment variable. Hence, the functions defined in the library can be directly used in the action code.

Figure 5.8: The three parts of a system

The designers, if they implement part of the system with user-defined libraries, must decide what is to be implemented with the native libraries and what is to be modeled with the DCharts formalism. This usually raises a dilemma: implementation in the library is straightforward (for programmers) and efficient, while modeling explicitly with DCharts is formal and the benefits of modeling (model checking, analysis, transformation, simulation and code generation) are gained. As a general suggestion, a system is usually divided into three parts: user interface, control logic and hardware driver (Figure 5.8). The user interface is usually hard-coded in a library, since it contains the detail of the rendering of various widgets and their interaction with the users. The hardware driver is usually hard-coded in a library, too. This is because it deals with the detail of hardware control, threading, synchronization, interrupt, status polling, and so on. Only the control logic is explicitly modeled with DCharts. It is usually the most vulnerable part of a system. Tools should be used as much as possible to thoroughly test and simulate the control logic before it is considered stable.

Though the separation of the three parts is far from deterministic or unique, there are some rules to be followed:

• The user interface should never interact with the hardware driver directly. It only sends user events to the DCharts model, and the DCharts model consumes those events. (In SVM, to send an event to the DCharts model, the user interface library must call function eventhandler.event(ev, p), where ev is the event name and p is a parameter of any Python type.)

• The hardware driver should never interact with the user interface directly. It only generates hardware-specific events with the same eventhandler.event function. Those events are also consumed by the DCharts model.

• The API (Application Programming Interface) of the hardware driver should be generalized for various applications. The designer should not intentionally tune it in order to simplify a specific DCharts model.

• The designer is allowed to use yet another library to define functions that are considered primitive in the system. For example, sorting, management of data structures and well-know algorithms should be hard-coded in a library rather than being modeled explicitly. The latter approach only unnecessarily complicates the model and obscures the essence of the problem to be studied.