Data Communications Models

From Serious Documentation
Jump to: navigation, search

There are two very different models for GUI-to-system data communications:

  • the tightly coupled model, in which the back-end embedded system code is in control of, and highly aware of the front end GUI -- the back-end directs which screens are displayed and much of the look-and-feel of the front-end GUI
  • the loosely coupled or decoupled model, where the front-end GUI works independently from the back-end, presenting and manipulating data exchanged with the back-end.

The SHIP environment is most useful and effective in the decoupled model, however the tightly coupled model can be also used. However the advantages of a loosely coupled/decoupled model are so overwhelming you should think twice (no, three and four times) before choosing a tightly coupled architecture.

Tightly Coupled

In the tightly coupled model the back-end (the connected system that controls your machine) must be completely aware of every GUI screen being displayed and how the GUI is functioning. In this model the back-end system directly commands the GUI to navigate to different screens, display specific information in specific places, etc. For example, the back-end might send a String over the wire along with xy coordinates and demand that the GUI engine place that text at that location. This is tightly coupled since at all time the GUI and back-end must remain in sync and the back-end has to be re-coded every time the GUI needs to change.

While many GUI systems employ this tightly coupled model in order to avoid the need for more sophisticated and powerful front-panel GUI development tools and software infrastructure, this is probably the worst and least effective model to develop and maintain your GUI for several reasons:

  1. It is very difficult to develop: the embedded development team on the back-end must be intimately aware of the front-end GUI development
  2. It is very difficult to change: every time you want to change the GUI it requires re-coding it in the back-end in C as well as adapting the front-end
  3. The expertise and aptitude to create an attractive, professional front-panel GUI display is very different than that required for embedded code development -- inevitably "back end coded" GUIs look awkward and unprofessional because the look-and-feel is being created by coders, not marketing people, user experience experts, and graphic artists
  4. It is very difficult to comprehend different front-panel sizes, displays, look-and-feel options (like a different brand in the same GUI), etc.
  5. It combines object-oriented GUI code in your embedded code which dramatically bloats and increases the complexity of your embedded control system

Loosely Coupled/Decoupled

This is a proven model in the industrial networking arena as well as a long-established best practice in client-server web page development. In web development development used to be tightly coupled with, for example, php code that issued database commands and created HTML for presentation in the same structure. This proved extremely unwieldy and resulted in "clunky" web pages that marketing always complained needed a makeover but changes required significant coding and engineering/marketing collaboration that is generally problematic. This persistent problem resulted in a dramatic change in Web development strategies to decoupled models, including front-end systems such as WordPress and Joomla as well as php systems such as the Zend framework for a loosely coupled Model View Controller loosely coupled architecture. All these systems are designed to decouple the presentation from the storage, ownership, and management of data.

The same philosophy should be applied to SHIP-based GUIs. Architecturally, the goal is to share data that completely abstracts the look-and-feel of your GUI from what is happening in the attached system. Just like WordPress separates the storage and underlying "embedded" elements of the content management and storage from the editing and creation of the presentation, SHIPTide and SHIPEngine on the SIM can present and manage your GUI independent from the details of the back-end system, working on the data in a highly decoupled fashion. Your GUI (i.e. the "front-end") will exchange data with your connected embedded control device (i.e. the "back-end"), leaving the GUI to be completely independent from the back-end as much as possible. Which GUI pages are displayed, which buttons are arranged where, etc., should be the primary job of the GUI. This has numerous advantages, including:

  1. it separates the object-oriented look-and-feel-focused GUI code from the back-end control embedded code, meaning your back-end system can remain mostly unchanged when adding a GUI front panel and not requiring a dramatic increase in CPU and memory resources on your system to add a GUI
  2. easy to develop the GUI separate from the back-end, allowing the right teams and skill-sets to be applied to each element
  3. easy to rearrange and change the GUI without any code changes to the back-end
  4. easy to create scalable and portable GUIs to other screen sizes, since the back-end has no awareness of the specifics of the front-end
  5. both the front and back-end systems can optionally be designed to operate in the temporary absence of the other end