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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

психология программный информационный система

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

⇐ Предыдущая12345

Поделиться: