Абельсеитова С.К. Совершенствование методов расчета устойчивости карьерных откосов в анизотропном массиве

Подождите немного. Документ загружается.

изменений. Части этого механизма, расположенного в объектах задачи уже

были описаны ранее. Здесь приводится весь механизм. Обсуждение будет

вестись на примере GUI-элемента управления Tedit, реализующего ввод тек-

стовой (числовой) информации.

Все изменения сделанные с помощью GUI-элемента Tedit обрабатыва-

ются в момент, когда пользователь выполнил команду смены фокуса - пере-

мещения активности с этого объекта на любой другой. В этом случае эле-

мент Tedit генерирует стандартное событие OnExit. По событию OnExit дан-

ные считываются из буфера Tedit и инициируется вызов метода фиксации

этого изменения в экземпляре объекта TtaskData. Если при фиксации измене-

ния происходит реальное изменение данных этого объекта инициируется це-

почка вызовов приводящая в конечном результате к уведомлению GUI-

компонент об изменении состояния экземпляра задачи TtaskData. Далее вы-

полняется считывание зафиксированного изменения в буфер объекта Tedit.

Последняя операция выполняется по той причине, что данные в TtaskData

имеют ряд свойств регулирующий, к примеру, правила округления данных.

По этой причине, скажем фиксация изменения градуса наклона откоса с зна-

чением 30,967 градусов вызовет реальное изменение наклона на значение

градусов. Именно это значение и должно появится на мониторе пользовате-

ля.

В случае, если фиксация изменения привела к исключительной ситуа-

ции, система подает сигнал, выводит диагностическое сообщение в

строку состояния программы и выделяет цветом GUI-элемент управления с

некорректными данными.

Также следует отметить, что успешная фиксация изменения задачи при-

водит к появлению не только уведомления об изменении, но может также

привести к появлению других уведомлений, к примеру, уведомления об из-

менении состоянии задачи или уведомлению об изменении свойства изме-

няемости задачи.

Полный цикл событий и вызовов приведен ниже на рисунке 8 и демон-

стрирует процесс редактирования азимута откоса.

Сложность и каскадность схемы на указанном рисунке не является свой-

ством присущим механизму, а есть лишь отображение реальной вложенности

понятий проблемной области.

Преимущества приведенной схемы многочисленны, наиболее важными

из них являются:

• Прозрачное взаимодействие с компонентами на любом уровне. Если

нам необходимо изменить объект, мы инициируем изменения этого объекта,

а не вводим искусственные методы на высшем уровне иерархии;

• Гибкость - мы можем регистрировать и обрабатывать события на лю-

бом уровне;

• Отсутствие жесткой иерархии - в данную схему мы можем включить

объекты любых типов. Требования жесткого наследования от какого-либо

единого объекта отсутствуют;

131

• Логическая асинхронность - процесс, инициирующий изменение ни-

как логически не связан с процессом регистрирующим изменение.

TTask

TTaskSfopeA

RegisterChangeData

Data

RegisterLockData

задачи

TEdit

Exit

Регистратор события изменения

Регистратор изменения состояния

Регистратор изменения изменяемости

Рисунок - Общая схема работы задачи.

А.4.2 Редактор свойств откоса

Редактор свойств откоса расположен в левой части редактора задачи.

Внешний вид редактора приведен на рисунке А.9. В редактор свойств откоса

входит шесть полей:

• Азимут простирания откоса (градусы);

• Угол наклона откоса (градусы);

• Высота откоса (метры);

• Сцепление породы

• Внутреннее трение в массиве (градусы);

• Плотность породы т/м ;

132

П равка Данные Вид П омощь

Свойства откоса Трещин

простирания:

Угол наклона:

Высота откоса: *

Сцепление породы: Точки

трение; 20 Пря

породы:

Рисунок А.9 - Внешний вид редактора свойств откоса.

Редактор свойств откоса и его компоненты описаны в модуле fmMain.

А.4.3 Редактор нарушений

Редактор нарушений является намного более сложной компонентой, чем

редактор свойств откоса. Это прежде всего связанно более сложной внутрен-

ней структурой понятия нарушение откоса. Редактор нарушений включает в

себя редактор точек слоев.

Редактор нарушений реализован в виде отдельных страниц, каждая из

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

че имеется два вида нарушений, на экране пользователь видит два сорта

страниц - страницы с описанием трещин и страницы с описанием пликатив-

ных слоев. Редактор нарушений распложен в правой части редактора данных.

Внешний вид редактора представлен на рисунке АЛО.

При редактировании нарушений, пользователю доступны команды с по-

мощью которых он может:

• Добавить нарушение-трещину;

• Добавить слой;

• Удалить активный нарушение;

Переход и редактирование необходимого нарушения осуществляется с

помощью соответствующей закладки в верхней части редактора

133

пликативного

Точки слоя —

координаты

Точки

5,00 10,00

зди{

трение

Г Полярные координаты

Угол Длина

90,00

26,57

Рисунок АЛО - Внешний вид редактора нарушений.

В силу относительной сложности редактора нарушений, его реализация

вынесена в отдельный модуль - Наиболее значимые объекты

этого модуля перечислены ниже.

отвечает за конструирование и поведение страницы

слоя. Объект читает информацию из задачи, - экземпляра объ-

екта и помещает ее в GUI-элементы управления для ее визуализа-

ции и редактирования. Изменение информации в элементах управления, в

конечном счете, приводит к тому, что объект записывает ее обратно в соот-

ветствующие компоненты экземпляра

В состав объекта входит редактор точек пликативного слоя, который бу-

дет описан ниже.

Объект TguiCrack отвечает за конструирование и поведение страницы

трещины. Объект читает информацию из задачи, - экземпляра объекта Task-

Data, и помещает ее в GUI-элементы управления для ее визуализации и ре-

дактирования. Изменение информации в элементах управления, в конечном

счете, приводит к тому, что объект записывает ее обратно в соответствующие

компоненты экземпляра TtaskData.

Объект отвечает за поведение всего редактора

нарушениеов и содержит в виде своих свойств списки экземпляров объектов

TguiCrack и TguiLayer. Редактор задачи взаимодействует с редактором нару-

шений с помощью методов, реализованных в этом объекте. Наиболее важные

методы перечислены ниже:

• CreateCrack - создание нарушения-трещины. Высокоуровневая коман-

да, которая вызывает создание трещины на уровне задачи, вызывая соответ-

134

метод в экземпляре объекта и в случае успешного соз-

дания, конструирует GUI-страницу для редактирования созданной трещины.

Данный метод является единственной (правильной) точкой для интерактив-

ного создания нарушения типа трещина;

• CreateLayer - создание нарушения-пликативного слоя. Высокоуровне-

вая команда, которая вызывает создание пликативного слоя на уровне

вызывая соответствующий метод в экземпляре объекта TtaskData и в случае

успешного создания, конструирует GUI-страницу для редактирования соз-

данного пликативного слоя. Данный метод является единственной (правиль-

ной) точкой для интерактивного создания нарушения типа пликативнй слой;

DeleteActiveDefect - удаление нарушения, активного в редакторе на-

рушений. Высокоуровневая команда, которая удаляет нарушение на уровне

задачи , вызывая соответствующий метод в экземпляре объекта TtaskData и в

случае успешного удаления удаляет связанные с нарушения GUI-объекты.

Данный метод является единственной (правильной) точкой для интерактив-

ного удаления нарушения в задаче.

• - добавление точки в описание кривой пликативного

слоя. Высокоуровневая команда, которая вызывает создание точки в описа-

нии кривой пликативного слоя на уровне задачи и в случае успешного за-

вершения делает изменения в состоянии соответствующего GUI-объекта.

• - удаление точки из описания кривой пликатив-

ного слоя. Высокоуровневая команда, которая вызывает удаление точки в

описании кривой пликативного слоя на уровне задачи и в случае успешного

завершения делает изменения в состоянии соответствующего GUI-объекта.

• ReloadDefects - синхронизация GUI-объектов редактора нарушений с

объектами задачи. Вызывается в случае, если данные о нарушениях или их

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

рушений. Такие ситуации возможны, к примеру, при создании новой или за-

грузки ранее созданной задачи;

• UpdateGuiLock - синхронизация GUI-объектов с текущим состоянием

изменчивости задачи. Метод вызывается в случае, если пользователь изме-

нил общее свойство изменяемости в редакторе свойств задачи.

А.4.4 Редактор точек пликативного слоя

Редактор точек пликативного слоя встраивается на страницу редактиро-

вания пликативного слоя и служит для интерактивного изменения описания

кривой пликативного слоя. Редактор реализован в виде расширения стан-

дартной компоненты TstringGrid и является единственным примером прямо-

го наследования и изменения поведения стандартного компонента среды

Delphi. Такое решение связано с отсутствием механизмы оповещения в слу-

чае, когда при редактировании элемента сетки фокус перемещается на другой

элемент сетки или вообще покидает компонент. Объекты редактора точек

135

расположены в модуле unGuiPointsEditor. Приложение взаимодействует с

экземплярами этих объектов только с помощью методов редактора наруше-

ний.

А.4.5 Редактор общих свойств задачи

Редактор общих свойств задачи вызывается для редактирования данных

не связанных напрямую с понятием откоса или его компонент. Все данные

такого рода сгруппированы в объект TtaskProps описанный ранее. Внешний

вид редактора приведен ниже на рисунке А.

(20

[20

Свешана

Наименование

8-Е

Коэффициент запаса изменения

Б локировать изменения

Отменить

[г

рени

10,00

Рисунок АЛ 1 - Внешний вид редактора общих свойств задачи.

А.5 Журнал расчета

В ходе оценки параметров устойчивости откоса ведется текстовый жур-

нал, содержащий подробную информацию о ходе расчета и полученных ре-

зультатах см. рисунок 12.

Для реализации журнала расчета спроектировано три объекта -

TlogData. Все объекты реализуют стандартные

методы по сохранению и зафузке своего состояния и являются наследника-

ми объекта TparsistObject.

136

Журнал

трещин

Падение

Трещина 1

продольный

Слой Наклон Падение

Слой 1 75

анность

согласный

На]

Д1

П1

П2

ПЗ

П4

Дефекты

применимости

матрица применимости

расчета

матрица применимости

Скема Дефекты Высота

Д2 Тр: 1 ???

-9.12

Откос потенциально не дополнительный

Рисунок А. 12 - Внешний вид журнала расчета.

Журнал расчета сохраняется вместе с задачей и обновляется всякий раз,

при новом расчете устойчивости.

реализует понятие абзаца в журнале расчета. Ос-

новные методы объекта и AddFmt. Первый метод добавляет новое

предложение в параграф, второй добавляет предложение с возможностью

форматирования.

С помощью объекта TlogSection моделируется понятие раздела в журна-

ле. Раздел выделяется с помощью заголовка и содержит несколько абзацев.

Свойства объекта перечислены в таблице А.9.

Таблица А.9 - Свойства объекта.

Свойство

Title

Paras

Level

Описание

Заголовок раздела

Список абзацев, входящих в журнал

Уровень детализации

раздела

Высокоуровневый объект TlogData реализующий понятие «Журнал рас-

чета». Объект включает в себя список разделов и содержит следующие мето-

ды:

• AddSection - добавить новый раздел;

137

• - выполнить конвертацию внутреннего представ-

ления журнала в переносимый формат RichEdit;

А.6 Интерактивный анализ результата

После завершения расчета пользователь может либо работать с тексто-

вой информацией, представленной в журнале расчета, либо с интерактивной

формой представления этого результата рисунок 13.

1 расчета

I данные

- Откос

- :

Д1

- Потенциально

схемы

_ Д1

Д2

- Д4

Дефекты

- Трещины

/ 1

/ Трещина 2

Слой 1

Отклоненные данные

Расчетные

Д1

дз

Высота

Д1

Д2

Д4

0.65

1.23

???

Рисунок 13 - Интерактивная форма анализа результата.

Результат представлен тремя компонентами - навигатором, списком

свойств и трехмерными Навигатор находится слева в окне

результата и служит для навигации по различным компонентам результата.

Для удобства навигация выполняется с помощью иерархии - дерева.

Список свойств находится справа вверху и содержит свойства выбран-

ного объекта в навигаторе. Свойства динамически изменяются в зависимости

от типа выбранного объекта.

138

Трехмерный находится под списком свойств и строит ви-

зуальную модель выбранного в навигаторе объекта.

Для подачи результате в описанном виде были спроектированы сле-

дующие объекты: TdataDrawer, а также около

30 объектов для моделирования различных компонент в навигаторе.

Корневой объект TresuItNodeData для последующих объектов навигато-

ра см.таблицу А.

Таблица АЛО - Свойства объекта.

Свойство

NodeCaption

Описание

Заголовок, указываемый в навигаторе

Номер пиктограммы, отображаемый в навигаторе

Основными методами объекта являются:

• Select - виртуальный метод, вызываемый при выборе экземпляра объ-

екта в навигаторе;

• CreateNode - виртуальный метод, ответственный за создание структур,

ответственных за визуализацию экземпляра объекта в навигаторе;

• виртуальный метод, создающий подчиненные

компоненты в навигаторе;

• FillListViewColumns - виртуальный метод, конструирующий список

свойств в окне свойств данного объекта;

• FillListViewItems - виртуальный метод, заполняющий список свойств в

окне свойств данного объекта.

• DrawPaintBox - виртуальный метод, вызываемый для трехмерной ви-

зуализации данного объекта;

Объект TresultHelper это высокоуровневый координирующий

поведение всех трех визуальных представлений - навигатора, окна свойств и

трехмерного в соответствии с событиями, генерируемыми

пользователем.

Назначением объекта TdataDrawer является трехмерная визуализация

выбранного в навигаторе блока. Несмотря на простоту интерфейса объекта,

он использует сложные алгоритмы, связанные с трехмерным представлением

невыпуклых тел.

А.7 Модель обработки команд пользователя

Для ввода команд пользователя в программе предусмотрено несколько

возможностей:

• Выбор команды из главного меню программы;

• Выбор команды из контекстного меню;

• Выбор команды в палитре панели инструментов;

• Нажатие комбинации клавиш;

139

Все эти возможности введены для облегчения работы с программой.

Однако такое многообразие приводит к тому, что одно и тоже действие мо-

жет быть сделано четырьмя разными способами. Это в свою очередь может

привести к избыточности ветвей программы, отвечающих за реакцию на

пользовательские события и увеличению кода по поддержке контекста дос-

тупных команд. В связи с изложенными проблемами в программе использу-

ется компонент для централизованного ведения и управления пользователь-

скими командами.

Схемы работы этого компонента приведена на рисунке А. 14.

Основным достоинством такой архитектуры является тот факт, что из-

менение визуальных свойств логической команды ведется централизовано на

уровне списка команд. Изменение визуальных свойств при этом автоматиче-

ски распространяется на все графические элементы связанные с этой коман-

дой. Все команды любого графического элемента также обрабатываются

централизовано где происходит определение с какой командой связан дан-

ный графический элемент, после чего происходит передача управление обра-

ботчику команды на уровне программы, связанному с этой командой.

меню

Главное меню

Элемент меню

Менеджер команд

Визуальные

Программа

Обработчик

команды

Рисунок 14 - Схема работы с командами пользователя.

А.8 Визуализация результатов расчета

Для трехмерной визуализации результатов расчета используется объект

класса реализованный в модуле Данный объект

140