2.3. Архитектурное проектирование программного средства

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

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

2. Унификация используемых интерфейсов взаимодействия. Это позволяет использовать создаваемые файлы в различных операционных системах и средствах разработки.

3. Разделение функций создания и использования математических процедур.

С учетом этих принципов и технического задания создаваемое программное средство будет состоять из следующих подсистем:

1. Подсистема создания математических процедур.

2. Подсистема конвертирования созданных процедур в необходимый формат.

3. Подсистема идентификации и хранения математических процедур.

4. Подсистема верификации математических процедур.

5. Подсистема использования (доступа) математических процедур.

6. Подсистема пользовательского интерфейса.

Схема взаимодействия данных подсистем приведена на рисунке 2.3. При этом в названия блоков соответствуют действиям, проводимым по отношению к математическим процедурам.

Рисунок 2.3 - Схема взаимодействия подсистем программного средства.

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

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

• при обнаружении ошибки в математических процедурах на этапе верификации, необходимо повторить весь предыдущий путь.

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

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

1. Конвертер моделей Симулинк (далее - КМС), который будет реализовывать подсистемы конвертирования.

2. Программу тестирования моделей Симулинк (далее - ТМС), которая будет реализовывать подсистемы идентификации и верификации.

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

При этом следует учесть, что подсистема создания математических процедур будет реализована на основе пакета Simulink, путем построения правил и процедур создания моделей для данного пакета.

Для дальнейшей разработки программного средства необходимо на основе выбранной архитектуры системы произвести модульную декомпозицию. Модульная декомпозиция, проведенная для каждой из входящих в программное средство программ, приведена на рисунках 2.4 – 2.6. Далее подробно рассмотрим декомпозицию каждой программы.

Рисунок 2.4 - Модульная декомпозиция программы КМС

Программа КСМ представлена на рисунке 2.4 и содержит следующие модули:

1. «Загрузка данных». Модуль предназначен для получения файлов, сгенерированных RTW и содержащих алгоритм математической процедуры. В процессе загрузки выделяются данные о характеристиках входных и выходных данных математической процедуры. Если все данные имеют формат скаляр, то настройка модели не требуется, в противном случае пользователь должен настроить модель.

2. «Настройка конвертирования». Модуль предназначен для получения данных о характеристиках входов и выходов модели – их формате, типе и размерности (описаны в приложении В). В этом модуле также реализована функция подключения к создаваемой Dll графического файла, поясняющего реализуемый алгоритм.

3. «Обработка данных». Модуль предназначен для выделения из кода на языке СИ (созданного с помощью программы RTW) алгоритма математической процедуры, ее характеристик, условий компиляции. Далее анализируются связи между логическими блоками алгоритма.

4. «Компоновка». Модуль предназначен для создания набора текстовых файлов, содержащих алгоритм реализуемой математической процедуры, в виде, пригодном для создания результирующей Dll. Для этого создается абстрактный класс, содержащий COM-интерфейс. В структуры этого класса встраивается выделенный ранее алгоритм и его характеристики. После этого происходит «обвязка» полученного кода, для поддержки спецификации Dll и создание временных файлов, содержащих созданный код.

5. «Компиляция». Модуль предназначен для создания папки с временными файлами, компиляции этих файлов с помощью компилятора среды Visual C++ и удаления всех временных файлов.

Рисунок 2.5 - Модульная декомпозиция программы ТМС

Программа ТМС представлена на рисунке 2.5 и содержит следующие модули и подсистемы:

1. «Идентификация». Подсистема предназначена для загрузки найденных Dll, находящихся в папке с программой ТСМ. После этого происходит вычитывание параметров Dll и анализ полученных характеристик.

2. «Представление». Модуль предназначен для отображения различных данных анализируемой Dll и содержащейся в ней математической процедуре: название и описание математической процедуры; характеристики входов и выходов – их количества, формата, типа данных, размерности; графического изображения математической процедуры.

3. «Верификация». Подсистема предназначена для определения тождественности математической процедуры, реализуемой в загруженной Dll и эталонной моделью, созданной в Simulink. Для этого получают входные и выходные эталонные значения, полученные путем моделирования математической процедуры в Simulink, и записывают их в текстовые файлы (с расширением *.kcm). Затем входные эталонные значения подают на вход Dll и сравнивают реальные и эталонные значения на каждом шаге итерации.

Рисунок 2.6 - Модульная декомпозиция программы МОПИ

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