Разработка вычислительного ядра

ВВЕДЕНИЕ

Геофизики в своей работе имеют дело с большими объемами данных. Для удобной работы с этими данными необходимо строить модели геологических сред. Важным является адекватное представление геометрии и физических параметров этой среды. Модель геологической среды должна поддерживать ограничения на элементы, взаимосвязь этих элементов и правила работы с ними. Для этих целей разрабатывается система ModelBuilder.

Частью автора в этой системе является разработка вычислительного ядра.

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

1. Постановка задачи Необходимо а) Разработать схему работы программного продукта. Данных пункт включает в себя: создания каркаса проектного решения, выделение основных модулей и создание основных классов в них.

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

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

г) Создание вспомогательных функций и библиотек, например API для разработки модулей трехмерной визуализации.

Стоит отметить, что разделение задачи на эти пункты весьма условно, фактически все они тесно переплетены и нераздельны.

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

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

2.1.1 Старая архитектура Для того чтобы понять для чего понадобился столь трудоемкий процесс переработки архитектуры, необходимо немного знать об истории создания проекта. Изначально архитектура проекта была следующей: ядро хранения и обработки модели, написанное на Unmanaged C++ и используемое Winforms приложением (платформа .NET).

Ядро представляло собой Win32 DLL (DLL — динамически подключаемая библиотека), имеющую ряд функций для работы с моделью (создание модели, валидация, редактирование). (Валидация — механизм, поддерживающий модель в корректном состоянии). UI приложение работало с моделью посредствам маршалинга (этот механизм в .NET Framework отвечает за работу с неуправляемым кодом и структурами данных). Изначально такая сложная схема была призвана увеличить производительность системы (исходя из того, что неуправляемый код работает быстрее управляемого).

Почти сразу почувствовались недостатки такого подхода:

а) Сложно отлаживать ядро. Не удалось задействовать отладчик Visual Studio для неуправляемого кода в проекте.

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

Кроме того, в проекте были другие сложности. Решению не хватало целостности. Проект изобиловал трудночитаемыми длинными функциями, длинной иногда в 100 — 300 строк (Оптимальным считается метод, текст которого не выходит за пределы видимой программистом области — обычно 10 — 15 строк). Во многих местах код дублировался, что крайне негативно сказывалось на скорости выявления, а главное — исправления ошибок и скорости внесения изменений в целом.

Для загрузки и сохранения модели в различные форматы был предложен и реализован механизм плагинов (Plug-In — динамически подключаемый модуль). Позже механизм изменялся другими участниками проекта, но также не выходил за рамки блока загрузки/сохранения модели. Из-за сложностей поддержки неуправляемого ядра, написанного на C++, было принято решение о его переводе на язык C#, при этом слой взаимодействия с пользовательским интерфейсом было решено временно оставить в неизменном виде. Таким образом, схема работы любой функции ядра стала следующей: обработать запрос, конвертировать результаты в неуправляемые типы данных при помощи маршалинга, после чего на уровне пользовательского интерфейса эти типы данных конвертировались обратно в управляемые типы данных. В результате большое количество времени тратилось на конвертирование данных в неуправляемые структуры и обратно в управляемые.

Рис. 1. Схема старой архитектуры системы.

2.2.2 Новая архитектура Из-за описанных выше проблем, было принято решение о разработке новой архитектуры, к которой предъявлялись требования гибкости (расширяемости), надежности и локализации отдельных аспектов системы (таких как транзакционность и логирование).

2.1.2.1 Общая архитектура взаимодействия с моделью За основу новой архитектуры была взята часть старой. А именно адаптация паттерна MVC (модель — представление — контроллер).

Модель: Часть, ранее называемая ядром, в терминах MVC является моделью, если удалить из ядра непосредственно бизнес-логику (в частности валидацию модели).

Представление: подсистема пользовательского интерфейса была полностью переработана, введены новые правила создания элементов управления и организации структуры интерфейса.

Контроллер: бизнес-логику работы с моделью, рассредоточенную ранее по всему проекту, сконцентрировали в виде набора классов-контроллеров.

Была создана следующая схема архитектурного решения:

Модель (проект DataModel): Модель данных среды — иерархическая структура объектов, хранящая информацию о среде. Бизнес логики классы модели не содержат, они используются только как хранилища.

Представление (проект UI): Интерфейс взаимодействия с пользователем, не содержит бизнес логики. В отличие от классического MVC данная реализация представления не взаимодействует напрямую с классами модели.

Контроллер (проект ModelController): Логика работы с моделью. Также классы контроллера инкапсулируют такие аспекты приложения как транзакционность и логирование.

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

Сейчас преимущественно используется следующий подход для создания элементов управления: элемент умеет отображать некоторую удобную для него структуру данных (т.е. он не зависит даже от контроллера), эта структура (View model или модель представления) оптимизирована для работы с конкретным элементом управления и может быть не привязана к функциональности и терминологии модели данных или контроллера. А для связи контроллера и элемента управления есть некий адаптер — прослойка конвертирующая обращения к модели представления в вызовы функций контроллера.

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

2.1.2.2 Механизм плагинов Выше упоминался механизм плагинов. В новой архитектуре этот механизм закладывался изначально как основное средство модификации системы сторонними разработчиками. Применение данного подхода не ограничивается загрузкой и сохранением данных в различные форматы, можно разработать любой плагин, который поможет облегчить работу с моделью среды. Также плагины в системе ModelBuilder способны изменять пользовательский интерфейс и даже правила обработки модели.

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

Для создания собственного плагина, достаточно создать новый проект (тип — C# class library) и добавить в него ссылку на MbApi. dll, после чего реализовать интерфейс IMbPlugIn в одном или нескольких публичных классах. Эти классы и будут новыми плагинами.

Однако, когда зашла речь о том, что плагины должны быть универсальным инструментом расширения функциональности системы, возникла трудность: как быть с загрузкой и сохранением? Дело в том, что, если разные форматы реализуются различными плагинами, то они не должны друг о друге ничего знать. В общем случае это означало, что каждый плагин загрузки/сохранения будет воздействовать на главное меню. В итоге, в меню файл может появиться 10 пунктов «Сохранить как…» и 10 пунктов «загрузить».

Для того, чтобы избежать такой ситуации, был предложен подход зависимостей для плагинов. Каждый плагин может быть зависим от некоторого количества других, при этом он будет загружен только тогда, когда будут загружены все его зависимости. Таким образом, для загрузки и сохранения сейчас используется следующая схема: есть плагин IoParentPlugin с пустым списком зависимостей, он добавляет в меню файл пункты «открыть», «сохранить' и «сохранить как». Существует интерфейс IMbIoPlugIn, в IoParentPlugin существует коллекция элементов типа IMbIoPlugIn. Для того, чтобы реализовать работу с некоторым форматом файлов, необходимо создать плагин, реализующий IMbIoPlugIn, а в список зависимостей добавить IMbIoParent (он реализуется классом IoParentPlugin). При инициализации плагина, он должен добавить себя в список объектов ввода/вывода экземпляра IoParentPlugin (экземпляр класса плагина можно получить из API по типу интерфейса).

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

Рис. 2. Схема новой архитектуры системы.

2.1.2.3. Подход для работы с двухмерной графикой При переходе на новую архитектуру встал вопрос: стоит ли продолжать использовать библиотеку Winforms или же перейти на более новую технологию WPF (Windows Presentation Foundation). Разумеется, подавляющее большинство всех «за» и «против» склоняли на сторону WPF, однако, WPF — технология новая и требовала много времени на изучение. И предпочтение было отдано Winforms.

Основываясь на изначальном варианте системы, автор работы выяснил, что необходимо реализовать некий общий подход к работе с двухмерной графикой при разработке нестандартных элементов управления. Был взят подход, применяемый в WPF, но в сильно упрощенном виде: логика элементов управления разбивается на небольшие фрагменты, каждый из которых может себя отрисовать и/или неким образом отреагировать на действия пользователя. Все эти фрагменты должны лишь реализовывать интерфейс IVisual (проект Controls2D). Использование такого интерфейса дает возможность использовать такие мощные инструменты, как паттерны проектирования цепь (chain) и прокси. Кроме того, различные базовые часто используемые операции могут быть реализованы в виде отдельного visual (легковесный компонент управления) и использованы многократно (например TransformedVisual — изменяет текущую матрицу отображения, и визуализирует свой внутренний элемент, после чего возвращает матрицу в исходное положение, кроме того производит реверс координат мыши). Во многих элементах управления (например, редактор разреза и редактор физических параметров границы) необходима навигация по сцене (перемещение, увеличение), для этого были также разработаны специализированные компоненты и отдельный элемент управления. Данный механизм можно использовать в плагинах, добавив ссылку на Controls2D.dll.

Пример дерева компонентов управления для элемента управления BoundParamsEditor:

Отцентровка сцены [proxy]

Приближение [proxy]

Движение[proxy]

Редактор физических параметров [proxy]

Коллекция компонентов [chain]

Заливка фоном Разметка (линейка) Элемент отрисовки и редактирования В более сложных случаях «Элемент отрисовки и редактирования» также представляет собой некоторое дерево.

2.1.2.4. Интерфейс пользователя Наконец, еще одним немаловажным нововведением стал измененный UI дизайн (Дизайн пользовательского интерфейса). Для современных многооконных систем стандартом «де-факто» считается докинг окон (технология, обеспечивающая эффект «примагничивания» дочерних окон к границам родительского). В различных программных продуктах он реализован по-разному, это зависит, как от желаний авторов, так и от специфики программного средства. Как наиболее удобный был принят докинг, реализованный в Visual Studio 2005/2008 и принято решение задействовать подобный в системе ModelBuilder. Была найдена бесплатная библиотека, реализующая как раз то, что нужно. Библиотека позволяет создавать комфортный для работы интерфейс, почти для любого разрешения экрана. Однако, как и многое другое бесплатное ПО, библиотека не лишена недостатков и потребовала улучшений и исправления ошибок.

Рис. 3. Интерфейс пользователя Рис. 4. Перетаскивание окон

2.2. Матрица физических параметров Одной из подзадач автора работы было в построении подсистемы восстановления физических параметров и геометрии в области по заданной равномерной сетке. Данная подсистема обозначена в продукте как «Матрица физических параметров». Существует прямая и обратная задачи, решаемые данной подсистемой.

2.2.1 Прямая задача Существует разрез, на нем N границ, существует функция, вычисляющая значение физического параметра на границе. Необходимо построить функцию, вычисляющую значение физического параметра в произвольной точке разреза P (x, y), при этом в каждой области (между двумя границами) руководствоваться правилами, заданными в нижней границе (константный параметр по вертикале, либо линейная интерполяция), на основе этой функции заполнить матрицу физических параметров, значение ячейки указать равным значению физического параметра в точке, соответствующей центру ячейки.

Для понимания вышесказанного, стоит обратиться к формализации модели среды.

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

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

Дано:

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

Размерность матрицы и размеры разреза (задает пользователь в диалоговом окне, либо загружаются из сопроводительного файла) Решение:

а) Для каждого столбца матрицы определить точки изменения частной производной (приращение значения, так как функция задана на узлах сетки) dP (x, y)/dy.

б) Центр ячейки, в которой произошло изменение — координаты точки, принадлежащей границе, а значение ячейки — значение физического параметра для этой точки.

в) Сгруппировать точки в границе.

г) В границах оставить только опорные точки (однозначно определяющие функцию границы). Опорными будем считать точки, где происходит изменение хотя бы одной из производных: dy/dx либо dP (x, y)/dx.

Есть трудность с поиском так называемых пузырьков.

Под пузырьком понимается ситуация, когда граница начинается не от левого края разреза (левого края модели) и/или заканчивается не в правом краю разреза (правом краю модели).

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

Проблемы:

Необходимо учитывать максимальную степень многочлена при нахождении точек границ и опорных точек.

Для dP (x, y)/dy и dP (x, y)/dx — первая степень (так как интерполяция физических параметров либо константная, либо линейная, т. е. многочлен степени не выше единицы) Для dy/dx — третья степень, так как используется кубический сплайн.

На данный момент вышеуказанный подход реализован в виде дополнительного API, которое позволило решить задачу загрузки/сохранения в формате SEG-Y.

Рис. 5. Окно матрицы физических параметров.

Рис. 6. Слой, восстановленный по матрице физических параметров.

2.3. Блок трехмерной визуализации Для трехмерной визуализации модели был разработан подход, аналогичный вышеописанному подходу легковесных элементов управления для двухмерной визуализации. Добавлено 3D-API — это своеобразный фасад (термин паттернов ООД) над библиотекой DirectX. Задачи этого фасада следующие:

а) Скрывать сложности работы с Managed DirectX, позволив сосредоточиться непосредственно на логики приложения.

б) Облегчить в случае необходимости переход с Direct X на OpenGL.

в) Упростить повторное использование логики, отвечающей за такие часто встречающиеся задачи, как масштабирование, выделение трехмерного объекта мышкой, и т. д.

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

2.3.1 ModelBuilder 3D API

Разработан API для создания компонентов 3D визуализации, имеющий большую гибкость. Существует интерфейс IVisual3D, который может быть отрисован и может обрабатывать события мыши.

public interface IVisual3D

{

void Draw (IOwner owner, IDrawer3D drawer);

void OnMouseMove (IOwner owner, IMouseInfo mouseInfo)

}

Для рисования используется обьект, реализующий интерфейс IDrawer3D — это простой 3D аналог класса Graphics для работы с GDI. Интерфейс со временем может расшириться, и измениться. В частности, тип Microsoft.DirectX.Matrix может быть заменен на что-либо. Так как использование такого типа данных жестко привязывает нас к использованию DirectX для реализации этого интерфейса, тогда как остальные функции являются инвариантными к реализации и бесперпятственно могут работать через OpenGL.

public interface IDrawer3D

{

void DrawTriangle (Point3dInfo p1, Point3dInfo p2, Point3dInfo p3);

void DrawLine (Point3dInfo p1, Point3dInfo p2);

Microsoft.DirectX.Matrix WorldMatrix { get; set; }

}

2.3.2 Визуализация модели в 3D

На базе вышеописанного API, а также специально разработанной модели представления был разработан новый блок трехмерной визуализации модели, командой добавлена поддержка сплайнов и так называемых пузырьков. Добавлена также раскраска модели в 3D, подобно аналогичной для двухмерного блока визуализации. Также добавлены различные режимы отображения, для наиболее удобного просмотра пользователем (раздвижение слоев, режим отрисовки границ и т. д.).

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

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

Для реализации данной задачи был применен подход зависимых плагинов (также как и для реализации загрузки/сохранения). Реализация включает в себя:

а) PrimitiveParentPlugin — проект базового плагина, управляющего всеми остальными плагинами примитивов, но не имеющего собственной функциональности вставки какой-либо конкретной фигуры. Данный плагин отвечает за добавления пункта меню «Примитивы» в главное меню приложения, а также обеспечивает взаимодействие компонентов вставки с ядром приложения.

б) MbPrimitivesApi — API для реализации собственных компонентов вставки, содержит интерфейсы взаимодействия с PrimitiveParentPlugin, а также набор вспомогательных функций, значительно облегчающих реализацию собственного компонента вставки.

в) MbCylinderPrimitivePlugin. В качестве примера работы механизма вставки примитива, была реализована вставка цилиндра. Данный плагин позволяет добавлять цилиндрические области значений физических параметров в модель.

Рис. 9. Вставка примитива «Цилиндр»

На рисунке 9 показан диалог вставки цилиндра, после нажатия кнопки «Вставить», система передает управление обработчику создания примитива и в модель добавляются дополнительные точки (рис 10), на которых задаются значения физических параметров, в соответствие со значениями, указанными пользователем на диалоговом окне.

Рис. 10. Точки, добавленные функцией «Вставка цилиндра»

Используя раскраску слоя можно наглядно показать работу функции вставки. На каждом из слоев виден поперечный срез вставленного цилиндра (рисунок 11)

Рис. 11. Раскраска слоя после вставки цилиндра Использовав трехмерную визуализацию, можно увидеть, как цилиндр выглядит в целом (рис 12).

Рис. 12. Трехмерная визуализация модели после вставки цилиндра

2.4.1 Алгоритм вставки цилиндра в модель Рассмотрим алгоритм вставки цилиндра в модель.

Пусть дана некоторая модель с несколькими слоями. Необходимо вставить цилиндр с координатами центра: (x = x1; z = z1) и радиусом r = r1. Каждый из слоев модели может пересекать цилиндр, не пересекать, либо касаться его. На рисунке 13 (слева) слои 1 и 6 не пересекают цилиндр, слои 2−4 пересекают, а слой 5 касается цилиндра.

Для каждого слоя модели находим значение координаты x линий пересечения его с цилиндром (если таковые имеются) по теореме Пифагора (рис 13 справа). Найденные линии пересечения образуют прямоугольные области, в которых должны быть заданы физические параметры. Значения по краям каждой области принимаются равными значениям, указанным пользователем в пункте «значение на границе», а значение в центре — линейно интерполируется между значением на границе и значением в центре цилиндра.

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

Рис. 13. Алгоритм вставки цилиндра в модель

2.5 Другие виды работ Проведена работа по исправлению ошибок. Внесены значительные улучшения в интерфейс пользователя. Исправлены найденные ошибки в сторонней библиотеке докинга, улучшена поддержка различных типов интерполяции как геометрии, так и физических параметров. Добавлены различные вспомогательные функции, которые задействованы уже и будут использоваться в дальнейшем. Добавлен логгер для получения отчетов об ошибках от конечных пользователей. Также проект заработал под операционной системой Windows 7.

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

3. Средства и методы разработки

3.1. Элементы промышленной разработки В процессе разработки применялись средства и методы, присущие промышленной разработки программного обеспечения в команде. Для поддержки эволюционного подхода использовалась система контроля версий. Большая часть кода содержит комментарии, что значительно ускоряет разбор кода. Для повышения качества продукта, использовались техники тестирования черного ящика (ручное тестирование пользовательского интерфейса), белого ящика (автоматизированное модульное тестирование — Unit Testing), методология Pear-Review.

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

3.2 Использованные средства разработки а) Среда разработки Visual Studio 2008. Высокоуровневая среда разработки от Microsoft.

б) Microsoft .NET Framework 3.5. Предпоследняя версия популярной платформы разработки. Содержит богатый инструментарий, позволяющий быстро решать часто встречающиеся задачи.

в) Библиотека WinForms. Технология создания оконных приложений предпоследнего поколения для .NET Framework.

г) C# 3.0. Третья редакция популярного мощного языка высокого уровня.

д) DirectX. Технология создания компьютерной графики.

е) Библиотека для докинга WeifenLuo. Сторонняя бесплатная библиотека организации пользовательского интерфейса.

ж) SVN. Зарекомендовавшая себя бесплатная система контроля версий.

4. Перспективы Разработанная архитектура и набор библиотечных классов позволяет легко вносить необходимые изменения в продукт. В частности пользователи заявляют о необходимости добавления некоторых новых возможностей. Структура проекта позволит легко встроить эти новые возможности. К таким возможностям относятся:

а) Управление сценой посредством команд (язык сценариев). Большие программные пакеты (Например, 3D Studio Max) обычно дают возможность пользователям описывать действия на простом языке сценариев.

б) Расширение возможностей трехмерного редактора. Возможность просмотра произвольных непараллельных срезов и т. д.

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

Заключение

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

Полученные результаты работы:

а) Разработана архитектура приложения, созданы основные компоненты проектного решения и основные классы этих компонентов.

б) Спроектирован и реализован подход легковесных компонентов для создания нестандартных элементов управления.

в) Создана система подключения плагинов. Разработан принцип зависимостей плагинов и применен в компоненте загрузки/сохранения данных в файл.

г) Разработан MB 3D API и применен для трехмерной визуализации модели.

д) Создан компонент логирования изменений модели на основе паттерна ООП «Прокси».

е) Добавлена возможность вставки примитивов в модель. В качестве примера реализована вставка цилиндра.

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

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

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

1. J. Bishop C# 3 0 Design Patterns.pdf. O’REILY 2008 — 315c.

2. Э.Эйнджел. Интерактивная компьютерная графика, Москва, Издательский дом «Вильямс», 2001

3. Н. Н. Пузырёв. Методы и объекты сейсмических исследований. Новосибирск, Издательство СО РАН, НИЦ ОИГГМ, 1997

4. Шилдт Герберт. Полный справочник по С#. М.: Издательский дом «Вильямс», 2004. — 752 с.

5. C. Макконел. Совершенный код. второе издание. Питер 2005 — 867с.

6. Эндрю Троелсен. Язык программирования C# 2005 и платформа .NET framework v2.0. М. И. Д. Вильямс, 2007 — 1168с.