Устройство форматирования графического вывода .

Система и окружение SBGraphicFormat.

Устройство разметки GUI.

Общее архитектурное решение.

Устройство системы SBGUIState.

Я постарался писать так, чтобы темы перетекали одна в другую. Термины описываются в несколько подходов и раскрываются в совокупности друг с другом. Поэтому рекомендуется последовательное чтение.

Определение проблемы, Выработка требований.

Файлы формата Xml хоть и имеют достаточно наглядную форму хранения данных, тем не менее недостаточно удобны в работе.

Основная цель этого проекта сделать, по крайней мере, просмотр файлаболее наглядным, удобным и быстрым. Создать систему графического представления данных, задействуя инструментарий фреймворка Qt. Так же необходимо реализоватьспособы фильтрации вывода данных по основным параметрам. Примеры фильтров: «больше значения», «меньше значения», «в диапазоне».

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

Программа должна работать на базе ОС Windows 7+. Должна быть быстрой в работе – переключение экранов должно происходить менее, чем за 0.3 секунды. И при запуске – должна запускаться менее, чем за 0,4 секунды, незамедлительно предоставляя возможность для пользовательского ввода.

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

Ошибки, допущенные в работе.

SearchBugMarkI.

1) Проект изначально не предусматривал наличие графического интерфейса пользователя. Его включение привело к многократным переработкам требований и архитектуры всей программы.

 

2) План проекта изначально не предусматривался, следовательно, не был проработан. Из-за чего, в ходе проектирования и конструирования системы, приходилось делать длительные задержки и переработки значимых участков.

 

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

 

Ошибки, допущенные в работе.

SearchBugMarkII.

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

 

5) Сейчас я думаю, что все, связанные с этим проектом, дела (схемы, чертежи, поиски, многократное переделывание схем и переписывание кода), выглядят неумело, но так или иначе принесли пользу. Теперь, вооружившись полученным опытом и добытыми знаниями, я вполне уверен, что с проектом, аналогичным по сложности и объему, я справлюсь в одиночку за два месяца не особо напряженной работы, при том, что буду полностью занят проектом и, конечно же, если будут в наличии материалы для GUI.

 

6) Попытки сделать что-то идеально не являются чем-то необходимым, однако позволяют лучше понять, какие именно стороны проекта требуют большего внимания, а на какие можно обращать меньше внимания. Это значит, что имеет смысл, в рамках учебы, делать идеальные работы, тратя избыточное количество времени, чтобы потом упрощать похожие проекты, оставляя лишь самое важное на должном уровне исполнения, и сводя затраты по времени и труду к минимуму.

 

Ошибки, допущенные в работе.

SearchBugMarkIII.

7) В третьей попытке я сразу же приступил к реализации функционального модуля SBXMLStreamReader. На тот момент, фактически, я не имел полного представления о системе. Не смотря на то, что это позволило сосредоточиться непосредственно на конкретной задаче, я упустил из виду многие моменты, связанные со взаимодействием этого модуля с остальными частями программы. Это повлекло за собой трудности, связанные с техническим определением взаимодействий. Пришлось работать уже с тем, что есть «по факту».

 

Сейчас я понимаю, что такой подход не годится для разработки многомодульной системы. Не смотря на всю очевидность идеи предопределения интерфейсов совмещаемых модулей перед началом работы. Это не так просто, как может показаться на первый взгляд. При проектировании двух взаимосвязанных модулей с нуля, их конечный набор типов данных и интерфейс – не известны. Приходится действовать «наощупь». Методом проб и ошибок притирать эти сущности друг к другу.

 

Здесь может помочь жесткое ограничение функционала модулей, в том числе и строгое, и даже избыточно строгое, сокрытие элементов. Даже, если приходится их дублировать в нескольких модулях. Повторение кода в этом случае не обязательно, однако количество общих зацепок: статические константы, общие данные – все это должно быть сведено к минимуму. Гораздо лучше иметь б о льшие по объему модули, содержащие свои собственные статические константы. Нежели терпеть трудности, связанные с тестированием, отладкой и рефакторингом усложненных лишним связыванием участков системы.

 

Стоит отметить, что сторонние функции, выражающие какую-либо идею, не связанную с конкретизированным типом данных (шаблонные функции, например), имеет смысл всё-таки вынести «за скобки» пространства модулей в отдельный компилируемый модуль программы.

 

И самый главный вывод, который я хочу здесь отметить – проектирование хорошей программы необходимо начинать с наиболее верхнего уровня абстракции и приступать к более низкому уровню только тогда, когда значительная часть верхнего уровня завершена.

 

Входные данные

    В программе предусмотрен класс SBXMLStreamReader. Этот класс является обёрткой для класса чтения xml-файлов, предоставляемого модулем QtXml библиотеки Qt (версия Qt 5.10).

Фактически программа читает файл формата xml посредством объекта QXmlStreamReader. В процессе чтения, этот модуль выборочно извлекает данные, которые подходят к установленному фильтру. Извлеченные данные сохраняются в структуре данных, реализуемых классом SBTable.

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

SBTable – этокласс, который определяет поведение множества таблиц юнитов и предоставляет методы для работы с ними.

 

Структура данных SBTable

    Структура данных предоставлена в виде дерева, которое состоит из трех оформленных уровней:

1. SBTable =>2. SBSubTable =>3. SBGraphicElement

SBTable – класс, предоставляет только два метода: addи draw. Которые позволяют работать со структурой данных на самом верхнем уровне, то есть добавлять таблицы юнитов и отрисовывать содержимое структуры данных на некотором контексте (виджете, файле изображении, буфере), с помощью методов нижних уровней структуры.

SBSubTable – класс, более нижнего уровня, чем SBTable. Он описывает объекты таблиц юнитов. Имеет дополнительные методы для присваивания и перемещения.

SBGraphicElement – это класс который непосредственно хранит информацию, полученную из входных данных (текст тега поля, текст содержания тега поля), а так же объект класса SBGraphicFormat, который предоставляет конкретные данные и параметры, необходимые для отображения на экране.

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

В этом проекте методы графического вывода встроены в структуру данных. Такое решение имеет как положительные стороны, так и отрицательные. С одной стороны, положительной, структура данных самодостаточна и не требует внесения в программу дополнительной вереницы классов, специально предназначенных для графического вывода. Сейчас эта функция реализуется парой методов перебора элементов таблицы и их отрисовки(::draw()) и классом SBGraphicFormat, являющимся интерфейсом для калибровки каждого формата вывода. Таким образом получившаяся совокупность, структуры данных и инструментов настройки, реализует виртуальный графический движок. С другой же стороны, отрицательной, решение объединить такие элементы проекта ограничивает возможности для добавления функций без существенных переработок кода. Как бы то ни было, сейчас я принимаю решение встроить метода отрисовки в структуру SBTable.