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

Введение.

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

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

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

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

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

4) Структура данных SBTable.

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

Система и окружение 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.

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

    GUIимеет иерархическую структуру. Базовым элементам считается фон элемента. Производным считается изображение, текст или элемент управления, которые накладываются на базовый. В свою очередь производные элементы считаются базовыми для элементов, которые накладываются поверх них.

Разметка вывода осуществляется за счет вычисления смещения относительных позиций элементов GUI относительно позиций более базовых элементов.

Основное содержимое экрана вывода всегда выравнивается по середине. По высоте выравнивание относительно логотипа - 4/5 высоты окна.

Изображение макета экрана вывода(3-й экран):

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

Принципиальная схема устройства системы:

Программа представляет из себя несколько сменяющих друг друга экранов. Каждый из них предлагает пользователю с чем-либо ознакомиться или что ни будь ввести. За смену экранов в окне отвечает переменная состояния (на схеме - SWITCH _ KEY), она жеState_id state. Значение state меняется при наступлении ключевых событий. Для каждого экрана есть свои события, определяющие переход к другим экранам. В основном это просто кнопки перехода.

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

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

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

 

Общая схема классов программы:

За основу структуры вывода взяты паттерны «State» и «Abstractfactory». Под состоянием программы, здесь понимаю то, какой экран вывода обрабатывается в этот момент времени. Состояния вывода реализуются системой SBGUIState, которая рассматривается далее. Каждое состояние имеет свой статически определенный индекс состояния, по которому осуществляется доступ к состоянию в системе SBGUIState.

 

Программа принципиально делится на три функциональных участка:

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

 

2) класс с длинным названием SBQXMLStreamReader, является оберткой для библиотечного класса QXmlStreamReader. Все вместе, они обрабатывают загружаемый файл базы данных и формируют внутреннее представление данных в программе, в структуре данных SBTable, рассмотренной ранее.

 

3) система SBGUIState, которая подготавливает объекты состояний кработе, обрабатывает пользовательский ввод, формирует и выводит конечную графику.

 

Введение.

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

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

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

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

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

4) Структура данных SBTable.