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

Question

[Алексей Меньков]

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

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


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

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

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

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

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


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

Аппаратура на объекте отправляет для датчика давления число 0, на экране отображается белый квадрат с черным контуром. Число 1 — белый квадрат с зеленым контуром, число 2 — зеленый квадрат с зеленым контуром, 3 — зеленый квадрат с зеленым контуром и буквой «К» в центре, и.т.д. — всего 16 вариантов.



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


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

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

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


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

Answer 1

[TheHorse]

Что такое модуль, в вашем контексте? dll что-ли?
Если термин модуля еще детально не формализован, могу предложить формализовать его как файл метаданных.
В этом файл, в каком либо формате, хранится вся нужная информация о типе отображения.
Подсистема отображения (программа ?) реализовывает все возможные типы отображения (набор графических приметивов, их анимации и модификаторы отображения).
Таким образом, новый модуль описывается максимально просто.

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

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

Comments

[Алексей Меньков]

Сейчас модуль — это бинарный файл, в который по определенному формату записаны параметры цвета для всех состояний элемента.
Вариант с DLL был отвергнут из-за проблем с разными компиляторами, модули предполагается писать на BCC, основное приложение — GCC.

Иерархия модуля на данный момент следующая:
Модуль = вектор фигур, вектор записей;
Фигура = вектор точек;
Запись = состояние элемента (число), вектор идентификаторов фигур, двумерный вектор параметров цвета для фигур (кисть, карандаш).

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

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

Да, все почти так, как вы описали. За тем исключением, что для каждого нового типа анимации сейчас приходится менять процедуру прорисовки элемента. Сейчас у меня есть только вращение элемента, а не далее пятницы мне сообщили, что будет еще элемент вроде progress bar'a. И видится мне, что заказчику потребуется еще очень много различных анимаций, эффектов и прочих красивостей.

Получается, как вы и сказали, мне нужен неограниченный набор возможностей при отображении модулей. Но вот я не представляю, как описывать все это на скриптовом языке. Вот например, в одном модуле приходит одно число, в соответстии с этим числом рисуем примитивы (самый простой вариант). Второй вариант: приходит 2 числа, одно из которых — внешний вид фигуры, другое — значение. Значение может быть конкретной температурой и отображаться цифрой, а может и с помощью стрелки, как на аналоговых приборах. Или вообще, с помощью прогресс-бара. Как это все можно описать с помощью скриптового языка?

[TheHorse]

Я понял, за моей спиной 2 подобные системы, и в обеих случаях, на практике оказалось, что все сильно ограниченно. Все-же строго рекомендую сделать запрос на полный список… или реализовать все стандартные отображалки + модификаторы. а по мере будет понятно что с ним делать)).

со скриптовым языком я имел ввиду что-то следующие

onLoad() 
{
   view =  createLCDNumber();
   i = 0;
   view.acceptStyle("border: 1px solid black");
}

onNewValue(int val)
{
    if (val < 0) 
       view.acceptStyle("background-color: #ff00ff");
    view.setValue(val);
}

onTimer() 
{
   if (view.value > 100)
      view.acceptModificator(createXYRotator(0.1))
   else
      view.clearModificators();
}

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

P. S. то что вы называли векторами — массивы, двухмерный вектор что-то фантастическое…

[Алексей Меньков]

Спасибо за советы! Буду настаивать на получении полного списка модификаторов, думаю это наиболее рационально в данной ситуации.

Answer 2

[d7k]

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

Comments

[Алексей Меньков]

Другими словами, вы предлагаете описывать внешний вид объектов с помощью XML для графики, т.е. SVG? У меня были мысли насчет этого формата, но я так и не придумал, как с помощью него делать анимацию.
Получается, человек, который будет писать модуль к программе, должен описать не только все состояния датчика, но и сделать анимацию, в случае, если она требуется в каком-то из состояний?
PS: Пишу на Qt, ПО заточено по Win, но возможность работы под Linux не исключается.

Answer 3

[egorinsk]

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

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

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

Comments

[Алексей Меньков]

Попробовал использовать SVG в качестве языка для описания внешнего вида элемента. Ну что сказать, если грузить параметры (кисть, карандаш, координаты линий и.т.д.) из SVG в память — еще ничего, но тогда получается аналог моего велосипеда. А если же при перерисовке элемента выполнять рендеринг заново — начинаются жуткие тормоза.

Answer 4

[Vampiro]

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

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

Comments

[Алексей Меньков]

Основная проблема в том, что набор аниматоров заранее не определен. Тов. TheHorse выдвигает мысль о том, что стандартизировать все аниматоры не получится, и в любом случае список их будет фиксирован.