# BOY Architecture

Table of content

Back to Top

### BOY Framework

BOY is not only an application but also a framework that can be extended with widgets and data sources. The framework provided implementations for all the common functionalities, such as XML file reader and writer, PV connection handling, abstract widgets, properties, OPI Runtime and OPI Editor. The framework can be extended using the extension points provided by the framework.

### BOY plugins

BOY Plugins are listed as below:

Core plugins:

- `org.csstudio.opibuilder`: the core plugin
- `org.csstudio.opibuilder.rcp`: the RCP fragment of org.csstudio.opibuilder. Not needed for WebOPI.
- `org.csstudio.opibuilder.widgets`: the core widgets plugin
- `org.csstudio.opibuilder.editor`: the editor plugin. Not needed for WebOPI or OPI runtime only product.
- `org.csstudio.opibuilder.widgets.rcp`: the RCP fragment of org.csstudio.opibuilder.widgets. Not needed for WebOPI.

Extra plugins:

- `org.csstudio.opibuilder.widgets.symbol`: symbol widgets provided by ITER
- `org.csstudio.opibuilder.widgets.extra`: Extra widgets provided by BNL
- `org.csstudio.opibuilder.examples`: BOY Examples
- `org.csstudio.opibuilder.imagelib`: Image library that can be used for BOY OPI.
- `org.csstudio.opibuilder.test`: test fragment for org.csstudio.opibuilder. Not needed for building final product.
- `org.csstudio.opibuilder.performanceTest`: Performance test resources. Not needed for building final product.
- `org.csstudio.opibuilder.converter`: EDM to BOY converter
- `org.csstudio.opibuilder.adl2boy`: MEDM to BOY converter

Feature: `org.csstudio.opibuilder.feature`

### Extension Points

The extension points provided by BOY are listed as below:

- `org.csstudio.opibuilder.widget`: Widgets can be added to BOY using this extension point
- `org.csstudio.opibuilder.graphicalFeedbackFactory`: Customized graphical feedback can be added to a specific widget using this extension point. For example, a gauge widget should always keep the same width and height.
- `org.csstudio.simplepv.pvfactory`: provides different PV implementations by using this extension point. Currently it provides utility_pv and pv_manager implementations. Both Utility PV and PV Manager have their own extension points to allow different data sources. Utility PV has been deprecated, but it is still useful to switch back to it if there is a bug in PV Manager that has not been resolved.

### Architecture

The internal structure of BOY is described by class diagrams as below. In these diagrams, unnecessary classes or relationships have been removed so it only show the important relationships.

#### Widgets

All BOY widgets should follow Model-View-Controller (MVC) pattern. In BOY, the "View" is an instance of draw2D IFigure. The figure can be totally independent with BOY. For example, some of BOY widgets' figure such as gauge, knob and XY Graph have been contributed to Eclipse Nebula Visualization project. The "Controller" is an instance of `AbsctractBaseEditPart`. Each widget must have a Model, EditPart and Figure class as shown in the widgets class diagram below.

#### PV Data Flow

The below picture describes how data from your control system flow to the widget. PV Manager is the library that talks to your control system. Simple PV Layer is a layer that provides a simpler and abstract interface to talk to PV Manager. BOY only needs to talk the Simple PV interface.

#### PV Handling

BOY has the general PV handling code in `PVWidgetEditpartDelegate` and `ConnectionHandler`. For example, it will set the pv_value property of the widget when PV's value changed, then the specific widget implementation will listen on pv_value property to update the widget. The general PV handling code also changes widget figure's border and enable state when pv's connection, alarm or write permission states changed.

#### Widget Properties

All widget properties must subclass `AbstractWidgetProperty`. Each property should define how it should be persisted to XML and read from XML. If the property should be editable in property sheet, it should also define its corresponding `PropertyDescriptor`. All the basic properties defined in BOY framework are shown as below. User may define his own property type by subclassing `AbstractWidgetProperty`.

#### Widget Actions

Widget Actions are the actions available on Widget's Actions property. All Widget Actions should subclass `AbstractWidgetAction` and be created from `WidgetActionFactory`.

#### Scripts and Rules

Scripts and Rules can be attached to every widget, so the attaching is handled in `AbstractBaseEditPart`. It provides an `AbstractScriptStore`, so it allows to be extended to any JVM scripting languages. Currently it provides Jython support (`JythonScriptStore`) and JavaScript support (`RhinoScriptStore`). Rules will be translated to JavaScript text and use the same scripting mechanism to execute it.

#### OPI Runtime

OPI runtime can be created on any SWT composite. Currently, it provides an Editor implementation (OPIRunner) and a View implementation (OPIView). Most of OPI Runtime functions are implemented in `OPIRuntimeDelegate`, so a new OPI Runtime can be easily created by using this delegate.

OPIRuntimeDelegate hooks up all OPI Runtime related features such as context menus, toolbar, XML reading, Display navigation, macros management etc. Some context menu actions are added using `objectContribution` extension point, so they are not shown here.

#### OPI Editor

`OPIEditor` hooks up all OPI Editor related features such as Actions, Context Menus, Toolbar, Outline pages, context help etc. Some context menu actions are added using `objectContribution` extension point, so they are not shown here.