CC BY
136
И.О. Мелымко
ПРОБЛЕМЫ ПОСТРОЕНИЯ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ И ЕЁ ИНТЕГРАЦИИ С ДРУГИМИ МОДЕЛЯМИ
Изложены проблемы построения функциональной модели системы поддержки принятия решений. Разработана функциональная модель системы с использованием методологии IDEF0.
Ключевые слова: функциональная модель, мосты, транспорт, ЮЕРО, система поддержки принятия решений.
Одной из основных проблем, которые приходиться решать при создании любых более или менее крупных систем, является проблема сложности. Наиболее эффективным подходом в такой ситуации является рассмотрение сложной системы в виде небольшого количества крупных частей, каждая из которых в свою очередь разбивается на несколько частей меньшего размера. Разбиение идет до тех пор, пока каждую часть не станет возможно реализовать с помощью имеющихся инструментов. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. Такой подход к разработке системы называется структурным. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.[1]
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
• Принцип «разделяй и властвуй» - принцип решения сложных проблем путем разбиения на множество меньших независимых задач, легких для понимания и решения;
• Принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне [1].
Рассмотрим построение функциональной модели для системы поддержки принятия решений при анализе движения транспортного потока по мосту. Система поддержки принятия решений является важнейшим элементом системы автоматизированного проектирования мостов, одной из основных задач которой является моделирование движения транспорта по мосту. Эта система будет использовать имитационное и геометрическое моделирование. Имитационное моделирование позволит управлять системой как единым целым, настраивать различные параметры. А геометрическое моделирование в свою очередь предоставит возможность визуализации движения транспортного потока по мосту. Это поможет ЛПР (лица принимающие решения) сделать необходимые выводы и принять правильное решение [2].
На первом этапе проектирование необходимо определить требования к разрабатываемой системе, а так же функции которые она будет выполнять:
1. Обеспечивать графический ввод транспортной сети, инженерных сооружений и объектов окружения, а так же интерактивное изменение их параметров;
2. Осуществлять имитационное моделирование движения транспортных средств, с возможностью настройки различных параметров транспортного потока;
3. Осуществлять трехмерную визуализацию дорожного движения, транспортной сети и объектов окружения;
4. Использовать единую базу данных, как хранилище параметров моделирования дорожного движения и геометрии объектов;
5. Обладать интуитивно понятным интерфейсом.
После того как определены требования к системе, следующим шагом является создание функциональной модели системы. Для создания функциональной модели будем использовать методологию IDEF0 (Integration definition for function modeling), в основе которой лежит методология SADT (Structured Analysis and Design Technique). Построенная с помощью методологии IDEF0 модель, отображает функциональную структуру системы, т.е. показывает выполняемые системой действия и связи между ними. Идея IDEF0 состоит в том, что процессы, происходящие в системе, представляются как некие преобразования входного потока в выходной под контролем (управлением) управляющего потока с использованием для преобразования механизма. С помощью наглядного графиче-
ского языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций.
В концепции IDEF0 реализованы три базовых принципа моделирования процессов: принцип функциональной декомпозиции; принцип ограничения сложности, принцип контекста:
1. Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции.
2. Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобство читаемости. Суть этого принципа состоит в том, что количество блоков на диаграмме должно быть не менее трех и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
3. Принцип контекстной диаграммы. Моделирование делового процесса начинается с построение контекстной диаграммы. На этой диаграмме отображается только один блок - главная функция моделируемой системы. При определении главной функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Контекстная диаграмма играет еще одну роль в функциональной модели. Она «фиксирует» границы моделируемой системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг соединенных с блоком, представляющим главную функцию [1].
Методология IDEF0 включает в себя построение моделей двух типов:
1. «AS-IS» - модель, отражающая существующее на момент обследования положение дел и позволяющая понять каким образом функционирует данная система, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
2. «TO-BE» - модель системы, отражающая представление о новых процессах и технологиях работы системы.
Как правило, модель «TO-BE» создается на основе модели «AS-IS», с устранением недостатков в существующей организации процессов, а так же с их совершенствованием и оптимизацией. Это
достигается за счет устранения выявленных на базе анализа модели «AS-IS» узких мест.
На рис. 1 представлена диаграмма «AS-IS» системы. Она представляет систему на текущий момент, т.е. до внедрения автоматизации компонентов.
Переход от модели «AS-IS» к модели «TO-BE» может выполняться двумя способами:
- Совершенствование существующих технологий на основе оценки их эффективности;
- Радикальное изменение технологий и перепроектирование (реинжиниринг) процессов.
До автоматизации (рис. 1) работы по моделированию и подготовке графических моделей проходили в два этапа:
^ расчёты на основе технических данных об автомобильных дорогах и данных о движении по этим дорогам. Расчёты производились вручную либо с помощью математических пакетов. На основе полученных расчётных данных находилась средняя скорость движения - основная величина для графического моделирования;
^ зная скорость движения, с помощью графического редактора строилась геометрическая модель, представляющая собой либо транспортный узел (например, перекрёсток или мост) либо проезд через определённый участок. Поскольку в этом случае на выходе получали видеоролик, то изменение параметров движения (например, с учётом времени суток) было невозможно.
В целом все работы выполнялись одним или несколькими людьми (обозначенными на диаграмме как «Инженер») в большей степени вручную.
Следующим этапом проектирования системы является выявление блоков автоматизации и построение модели «TO-BE». Как правило, данная модель создается на основе модели «AS-IS», с устранением недостатков в существующей организации процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа модели «AS-IS» узких мест. После автоматизации данные для моделирования и построения трехмерной визуальной модели
Геометрия дорога -
Факторы транспортного -потока
Информация об окружении -
Руководство по оценке интенсивности дорожного движения
Правила дорожного движения
Моделировать движение транспортного потока по мостуад
Инженер ПО
^Результаты расчёта движения
I» Визуальная 30 модель движения
а
ПО Инженер
Б
Рис. 1. Диаграммы модели «AS-IS»: а - контекстный уровень, б - первый уровень декомпозиции
движения будут подготавливаться автоматически на основе введенных пользователем начальных данных.
Рис. 2. Диаграмма модели «TO-BE.» первого уровня декомпозиции
На рис. 2 представлена диаграмма «TO-BE» системы. Она представляет систему после проведения автоматизации некоторых процессов.
Рассматривая диаграмму, изображенную на рис.2, видно, что для построения визуальной модели необходимо подготовить данные для моделирования. Подготовка данных для построения визуальной модели сводится к расчету координат и угла поворота транспортного средства. В свою очередь координаты и угол поворота транспортного средства зависят от полосы, по которой движется транспортное средство и от мгновенной скорости транспортного средства.
Процесс построения визуальной трехмерной модели дорожного движения разделяется на несколько частей: построение трехмерной модели окружения, моста и транспортного средства, установка ракурса камеры и общая прорисовка модели.
После построения модели «TO-BE» определены все функции, которые выполняет система, а также взаимодействие между ними. Использование сформулированных функциональных требований облегчает дальнейшую разработку системы. Созданная функциональная модель является основой для построения модели данных системы, a так же для разработки математического обеспечения системы и ее графической части.
---------------------------------------- СПИСОК ЛИТЕРАТУРЫ
1. Карпович Е.Е., Федоров Н.В. Автоматизированное проектирование информационных систем на основе современных CASE-технологий. Часть 1. Структурный подход к проектированию информационных систем. Учебное пособие. -М.: МГГУ, 2007 - 157 с.
2. Федоров Н.В., Мелымко И.О., Матвеев В.В. Система поддержки принятия решений при анализе движения транспортного потока по мосту // Научный вестник МГГУ. - 2010. - № 6. - С. 47-50. шгд=1
КОРОТКО ОБ АВТОРЕ ----------------------
Мелымко Иван Олегович - студент, phenixx33@gmail.com) Московский государственный горный университет, Moscow State Mining University, Russia, ud@msmu.ru
