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

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

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


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

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

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

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

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


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

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


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


Я сейчас пришел к следующей схеме: у меня есть набор графических примитивов, из которых строится графическое представление элемента. В случае с датчиком давления — контур, заливка, и текст. И есть еще объек, который ставит в соответствии с каждым значением от аппаратуры — соответствующую фигуру и соответствующие цвета. Получается приведенный пример можно представить следующим образом:
Запись №1. Значение от сервера - 0. Фигура 1 (контур) - черный тонкий контур. Фигура 2 (заливка) - белая.
Запись №2. Значение от сервера - 1. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - белая.
Запись №4. Значение от сервера - 3. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - зеленая. Фигура 3 (текст) - черный, фиксированный текст.


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


Ну вот и получается следующий вопрос — на правильном ли я пути, или делаю свой велосипед? Может быть есть какой способ попроще представить подобный модуль? Или кто-то занимался подобными проектами и поделится опытом?
  • Вопрос задан
  • 3048 просмотров
Решения вопроса 1
TheHorse
@TheHorse
Что такое модуль, в вашем контексте? dll что-ли?
Если термин модуля еще детально не формализован, могу предложить формализовать его как файл метаданных.
В этом файл, в каком либо формате, хранится вся нужная информация о типе отображения.
Подсистема отображения (программа ?) реализовывает все возможные типы отображения (набор графических приметивов, их анимации и модификаторы отображения).
Таким образом, новый модуль описывается максимально просто.

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

P. S. прошу уточнить что не ясно, и дать детальный комментарий по поводу моего ответа. Надеюсь я правильно понял вопрос.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@d7k
Все конечно от платформы зависит, но по моему представление в виде XML гораздо проще и понятнее было бы. Да и возможности для расширения имелись бы. А там и пол шага до XAML-template с созданием resource-объектов из файлов в runtime (если это win, допустим .net и т.д.).
Ответ написан
@egorinsk
Чем описывать внешний вид фигур в конфиге, не проще сделать библиотеку с функциями вроде renderProgressBar(location, values, frameNumber)?

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

Для SVG есть анимация, но работать это будет с черепашьей скокростью… я бы все же сделал свой собственный оптимизированный формат.
Ответ написан
@Vampiro
Запись №1. Значение от сервера - 0. Фигура 1 (контур) - черный тонкий контур. Фигура 2 (заливка) - белая. Переход - вращение по часовой.
Запись №2. Значение от сервера - 1. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - белая. Переход - вращение против часовой.
Запись №4. Значение от сервера - 3. Фигура 1 (контур) - зеленый толстый контур. Фигура 2 (заливка) - зеленая. Фигура 3 (текст) - черный, фиксированный текст. Переход - градиентная заливка.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы