Проектирование системы (подробности под катом)?
=================================================

 Доброго времени суток!  
  

Я сейчас пишу достаточно большой для себя проект и у меня не получается должным образом формализовать одно требование из технического задания, поэтому обращаюсь за помощью.  
  
  

Итак, что мне нужно сделать — небольшое введение. У меня есть приложение, которое отвечает за мониторинг определенного технического объекта. Другими словами, приложение отображает состояние диагностируемого объекта в графической форме на экране компьютера. Контрольно-измерительная аппаратура на объекте отправляет данные в виде UDP-пакетов, мое приложение обрабатывает эти пакеты. К приложению подключаются специальные модули, которые определяют какой-нибудь элемент на объекте — датчик давления, температуры, высоты. В этом модуле хранится следующая информация:  
  

1. Как датчик должен выглядеть на экране (т.е. набор графических примитивов);  
  

1а. Как датчик должен выглядеть в случае, если измеряемый параметр корректен;  
  

1б. Как датчик должен выглядеть в случае, если измеряемый параметр некорректен;  
  

1в. Как датчик должен выглядеть в случае, если нет сигнала с контрольно-измерительной аппаратуры.  
  
  

Небольшой пример, рассмотрим самый примитивный элемент — датчик давления.  
  

Аппаратура на объекте отправляет для датчика давления число 0, на экране отображается белый квадрат с черным контуром. Число 1 — белый квадрат с зеленым контуром, число 2 — зеленый квадрат с зеленым контуром, 3 — зеленый квадрат с зеленым контуром и буквой «К» в центре, и.т.д. — всего 16 вариантов.   
![d447d5797e6af6fd6fa96e30acc20c25.png](http://habrastorage.org/storage2/d44/7d5/797/d447d5797e6af6fd6fa96e30acc20c25.png)  
  
  

Проблема в том, что вся информация о цветах, фигурах должна храниться в модулях. А датчики могут быть не только квадратные, но и вращающиеся, просто заполняющиеся (по типу Progress Bar) и просто цифровые. И это все нужно унифицировать.  
  
  

Я сейчас пришел к следующей схеме: у меня есть набор графических примитивов, из которых строится графическое представление элемента. В случае с датчиком давления — контур, заливка, и текст. И есть еще объек, который ставит в соответствии с каждым значением от аппаратуры — соответствующую фигуру и соответствующие цвета. Получается приведенный пример можно представить следующим образом:  

```
Запись №1. Значение от сервера - 0. Фигура 1 (контур) - черный тонкий контур. Фигура 2 (заливка) - белая.
Запись №2. Значение от сервера - 1. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - белая.
Запись №4. Значение от сервера - 3. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - зеленая. Фигура 3 (текст) - черный, фиксированный текст.
```
  
  

Приведенная схема хоть и объемная, но работает. Но вот как добавлять еще и анимацию вроде вращения или заполнения (progress bar) — вообще непонятно.  
  
  

Ну вот и получается следующий вопрос — на правильном ли я пути, или делаю свой велосипед? Может быть есть какой способ попроще представить подобный модуль? Или кто-то занимался подобными проектами и поделится опытом? 

 Что такое модуль, в вашем контексте? dll что-ли?  

Если термин модуля еще детально не формализован, могу предложить формализовать его как файл метаданных.  

В этом файл, в каком либо формате, хранится вся нужная информация о типе отображения.  

Подсистема отображения (программа ?) реализовывает все возможные типы отображения (набор графических приметивов, их анимации и модификаторы отображения).  

Таким образом, новый модуль описывается максимально просто.  

  

Если нужно иметь неограниченный набор возможных отображений, то бишь возможность задавать анимацию и примитивы, которые не предполагались на этапе разработки — в файл метаданных можно включить возможность подгрузки скриптового языка, таблицы стилей, что очень просто с Qt.  

  

P. S. прошу уточнить что не ясно, и дать детальный комментарий по поводу моего ответа. Надеюсь я правильно понял вопрос. 

 Все конечно от платформы зависит, но по моему представление в виде XML гораздо проще и понятнее было бы. Да и возможности для расширения имелись бы. А там и пол шага до XAML-template с созданием resource-объектов из файлов в runtime (если это win, допустим .net и т.д.). 

 Чем описывать внешний вид фигур в конфиге, не проще сделать библиотеку с функциями вроде renderProgressBar(location, values, frameNumber)?   

  

О! Хотя есть же способ. Храните описания в формате SVG (это векторный формат графики). Только учтите, что рендеринг SVG очень медленный, в реалтайме не факт что у вас все будет обновляться, и возможно, этот момент, надо как-то оптимизировать (кешировать битмапы, кешировать скмпилированное дерево объектов и т.д.). Или придумать свой аналогичный формат.  

  

Для SVG есть анимация, но работать это будет с черепашьей скокростью… я бы все же сделал свой собственный оптимизированный формат. 

`Запись №1. Значение от сервера - 0. Фигура 1 (контур) - черный тонкий контур. Фигура 2 (заливка) - белая. Переход - вращение по часовой.  

Запись №2. Значение от сервера - 1. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - белая. Переход - вращение против часовой.  

Запись №4. Значение от сервера - 3. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - зеленая. Фигура 3 (текст) - черный, фиксированный текст. Переход - градиентная заливка.`  

Может плохо понимаю, но если вы тут храните фигуры и цвета — то почему нельзя хранить аниматоры? Оо в чем проблема-то.