Описание модуля. 
Разработка модуля обработки данных физического эксперимента

Структура модуля

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

Функциональные модули системы логически распределены по программным уровням абстракции системы, что делает архитектуру системы слоистой, каждый слой содержит соответствующие функциональные модули, необходимые для осуществления его функционирования. Таким образом, архитектура системы разработана в соответствии со стандартной Трехуровневой архитектурой программного обеспечения, состоящей из следующих логических программных уровней: «Уровень представления», «Уровень бизнес-логики», «Уровень данных». Такой подход к организации программной архитектуры делает разработанную систему:

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

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

Рисунок 9 — диаграмма компонентов модуля.

Стоит, однако, отметить невозможность реализации классического решения MVC в приложениях Windows Forms. Классическое представление указывает разработчикам, что представление изолированно от знаний о контроллере, в то время как контроллер производит управление представлением и моделью. Однако если речь заходит о приложениях WF, то необходимо осознавать, что внедрение в них подобной архитектуры не закладывалось изначально. Речь стоит скорее вести о событийно-ориентированном программировании, когда большую часть времени система ожидает отклика от пользователя. И обрабатывает отклик внутри графической оболочки, которое мы принимаем с этой оговоркой как «представление». Именно такая архитектура подразумевается в этой работе как «MVC». Решение этой проблемы может лежать в плоскости использования сторонних продуктов.

В соответствии с разработанной архитектурой система состоит из следующих уровней:

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