Разработка программного обеспечения для комплексной оценки мультипликативного эффекта реализации крупных инфраструктурных проектов (на примере транспортных)
Введение
Работа была выполнена в Институте Экономики и организации
промышленного производства СО РАН в рамках исследований по оценке
пространственных трансформаций экономической системы в связи с реализацией
разных вариантов развития транспортной системы Азиатской части России.
Разработка программного обеспечения для автоматизации оценки
мультипликативного эффекта реализации крупных инфраструктурных проектов
является необходимым элементом анализа и оценки варианта транспортной
стратегии. Необходимость автоматизации следует из особенностей экономических
прогнозов на базе модельного аппарата, используемого в ИЭОПП СО РАН при
разработке вариантов транспортной стратегии. В числе этих особенностей:
· большая размерность экономико-математических задач;
· вероятностный и неопределенностный характер
информации.
Целью проекта явилась разработка инструментария для оценки
мультипликативного эффекта, возникающего в результате реализации некоторого
варианта транспортной стратегии, порождаемого оперативными сценарными расчетами
по системе используемых моделей.
В процессе работы над проектом мной проделана следующая
работа:
ü Произведен обзор предметной области;
ü Изучены методы экономико-математического
моделирования, которые используются в ИЭОПП СО РАН при постановке, решении и
анализе транспортных задач при разработке среднесрочных и долгосрочных
прогнозов развития страны, подготовке стратегии развития Сибири и др.;
ü Проанализированы основные типы
экономических задач, при решении которых встают вопросы прогнозирования работы
транспортной системы, а также способы решения этих задач;
ü Систематизированы основные требования,
которые предъявляют экономические задачи к инструментарию, и рассмотрены
возможности их выполнения;
ü На основании анализа требований были
выбраны средства разработки;
ü Спроектирована структурная модель решения;
ü Разработана система обработки данных для
извлечения информации, необходимой для анализа вариантов транспортной
стратегии;
ü Разработан пользовательский интерфейс;
ü Осуществлена программная реализация;
ü Разработана система тестов и проведена
отладка программы;
ü Разработано руководство пользователя;
ü Проведен анализ полученных результатов и
направления дальнейшего развития проекта.
Результатом работы стал программный продукт, представляющий
собой инструментарий для анализа вариантов транспортной стратегии и оценки
мультипликативного эффекта их реализации.
1.
Постановка задачи
.1
Предметная область
мультипликативный программа транспортный
Для обеспечения высоких темпов экономического роста России
жизненно необходима реализация крупных системообразующих проектов, многие из
них сконцентрированы сегодня в сфере транспорта. Транспортные проекты являются
важнейшим катализатором развития, особенно для малоосвоенных регионов страны.
Это связано с тем, что транспортная инфраструктура имеет ярко выраженный
системообразующий характер.
Реализация крупных транспортных проектов позволяет не только
«войти» в неосвоенные регионы, богатые ресурсами, но и инициировать
экономическое развитие этих регионов, создав новые точки роста. Так
строительство Транссиба принципиально изменило пространственную структуру
хозяйства России: менее чем за полвека в Азиатской части России сформировались
крупные экономические центры. Эти центры положили начало формированию Южного широтного
пояса экономического развития.
В конце XX - начале XXI в. в стране возникла
потребность в формировании новой широтной транспортной магистрали -
Северо-Российской Евразийской.
Северо-Российская Евразийская магистраль (Баренцкомур – Севсиб –
БАМ) может стать организующим стержнем оформления нового будущего широтного
транспортного коридора России. На западе вместе с Белкомуром она свяжет
дальневосточные российские порты Японского моря (Ванино, Совгавань, Находка и
др.), японские порты, северо-корейские и южно-корейские экономические районы,
Северо-Восточный регион Китая (территориальные районы провинций Ляонин,
Цзилинь, Хэйлунцзян) и восточную часть административного района Внутренняя
Монголия с портами Баренцева моря (Индига), Белого (Архангельск, Мурманск) и
Балтийского (Санкт-Петербург, Усть-Луга, Приморск, Высоцк и др.) морей с
последующим выходом в Карелию, к финским портам на побережье Финского и
Ботнического заливов, в северные районы стран Скандинавии. На востоке
Северо-Российская Евразийская магистраль через Транссиб даст выход грузам из
регионов европейской части России, Белоруссии к южным тихоокеанским портам
и в страны Восточной и Юго-Восточной Азии.
Как и большинство транспортных проектов, этот проект имеет
ярко выраженный системообразующий характер. В связи с реализацией этого
транспортного проекта прогнозируется:
· формирование нового Северного широтного
пояса экономического развития всей страны. По оценкам экспертов это может
начаться уже в первой четверти XXI в.
В отличие от Южного широтного коридора, экономическое
развитие в Северном будет идти не через формирование отдельных узко
специализированных очагов развития, а посредством создания интегрированных
производственно-транспортных зон (ИПТЗ).;
· укрепление единого экономического пространства
страны, опираясь не только на сырьевые ресурсы Азиатской части России, но и на
транспортно-логистические возможности, открывающиеся при обслуживании
международных транспортных коридоров;
· ускорение экономического развития в
европейской части России. По оценке экспертов, формирование нового широтного
пояса экономического развития нужно не столько Азиатской России, сколько России
в целом. И далеко не очевидно, кому больше грозит отсталость Азиатской России -
макрорегиону или стране. Это вопрос стратегической национальной безопасности
страны;
· повышение конкурентоспособности
национальных производителей за счет совершенствования опорной транспортной сети
страны, обеспечивающее более активное участие России в процессах международной
экономической интеграции.
Однако, в третьем тысячелетии в мировой (не столько
российской) научной и деловой общественностью обсуждались и обсуждаются
несколько крупных проектов освоения новых межконтинентальных маршрутов для всех
видов транспорта, проходящих по территории нашей страны, а не только
Северо-Российская магистраль. Например,
· Полярная железная дорога.
· Проект международной трансконтинентальной
Стратегической магистрали - шестидесятая параллель (Золотой Пояс).
· Трансевроазиатская высокоширотная
магистраль - СЕВСУХПУТЬ (Северный Сухопутный Путь)
· и др.
Подавляющая часть этих проектов относится к категории
глобальных проектов ХХI столетия, а степень проработки и определённости их
реализации различна.
Для того чтобы корректно сравнивать предлагаемые
альтернативные транспортные проекты нужно уметь оперативно оценивать
долгосрочные и комплексные последствия этих проектов с позиции
социально-экономического развития страны, ее регионов и населения.
Это и обусловило необходимость постановки проблемы оценки мультипликативного
эффекта, «создаваемого» транспортом. С позиции реализации транспортных
проектов, имеет смысл выделить и попытаться оценить глобальные и локальные
составляющие мультипликативного эффекта.
Рассматривая экономическое и политическое положение России в
мире можно ожидать следующих результатов в контексте глобальной
составляющей:
· Усиление влияния России на мировых рынках разной
специализации;
· Формирование новых рынков сбыта
национальной продукции;
· Выход на мировой рынок реализации
транспортных услуг;
· Укрепление СНГ в результате реализации
проектов и программ в рамках содружества.
Локальная составляющая эффекта выражена следующими
аспектами:
· Массовый и долгосрочный заказ отраслям
промышленности и транспорту;
· Выход на новые, в том числе энерго- и
ресурсосберегающие технологии;
· Формирование подходов к перспективным
месторождениям полезных ископаемых и лесным ресурсам;
· Промышленное и демографическое освоение
обширных территорий;
· Социально-экономическое развитие
вовлеченных регионов;
· Развитие туристического бизнеса на
территории страны и формирование подходов к новым привлекательным с этой точки
зрения местам.
1.2
Актуальность
Растущая экономика России, происходящие в ней не только
количественные, но и качественные изменения требуют своевременной «настройки»
транспортной системы, прогнозирования и замены слабых звеньев, для того чтобы
избежать кризисов и системных сбоев.
Результаты оценки потенциальных транзитных грузовых потоков
позволят, в частности, сформулировать конкретные предложения федеральным и
региональным органам государственного управления транспортом, предпринять
скоординированные шаги по развитию существующих и созданию новых транспортных
коридоров.
При разработке вариантов транспортной стратегии в ИЭОПП СО
РАН используется комплекс экономико-математических моделей: межотраслевая
межрегиональная модель (ОМММ), оптимизационные, имитационные, поведенческие
модели. Экономические прогнозы на базе модельного аппарата имеют ряд
особенностей, среди которых:
· большая размерность экономико-математических
задач. В
частности, разрабатываемая сейчас в секторе ТПК - имитационная модель
конкурентоспособности российских транспортных коридоров в МХС - уже имеет
размерность 6400 переменных (способов производства) и содержит 1204
ограничения. При этом речь идет об отлаженной версия модели по 2
продуктам и 50 транспортным узлам. Всего же в «конечном» варианте
модели будет 6 продуктов (грузов) и 70 - 80 транспортных узлов. В
то же время результат решения даже по столь «усеченной» модели - 2 продуктам - 4845
информационных строк.
· вероятностный и неопределенностный
характер информации, что предопределяет проведение сценарных расчетов.
Учитывая перечисленные особенности, встает острая
необходимость автоматизации обработка и анализа полученных данных. Следовательно,
разработка программного обеспечения для автоматизации оценки мультипликативного
эффекта реализации крупных инфраструктурных проектов является необходимым
элементом анализа и оценки варианта транспортной стратегии.
1.3
Формулировка задачи
В соответствии с целью всего исследовательского проекта (а не
только дипломного) можно предложить следующие задачи:
· Проведение анализа существующих способов оценки
мультипликативных эффектов развития экономических систем.
· Разработка алгоритма оценки мультипликативных
эффектов того или иного варианта формирования транспортной сети, отвечающего
конкретному (полученному) варианту транспортной стратегии. В рамках данной
работы вариант транспортной стратегии задается результатом решения согласно
имитационной модели.
· Разработка алгоритмов и ПО конвертирования
выходных данных пакета LP_VC, используемого для решения задач
имитационного моделирования в соответствии с требованиями алгоритмов оценки
мультипликативного эффекта.
· Разработка ПО для оценки
мультипликативного эффекта.
· Разработка алгоритмов и ПО визуализации
пространственных трансформации, отвечающих разным вариантам транспортной
стратегии.
Часть перечисленных задач была включена в представляемый
дипломный проект. Эти задачи выделены полужирным шрифтом.
Выбор задач для реализации в данном дипломном проекте
определяется приоритетностью данных работ для сектора ТПК ИЭОПП СО РАН.
Общие требования можно к решению возникшей задачи
сформулировать в следующем виде. Необходимы:
ª первоначальный анализ результатов решений -
формирование контура транспортной сети (с расчетными характеристиками);
ª проведение сводного анализа информации по запросам,
определяемым исследователями - экономистами;
ª получение предварительных оценок
мультипликативного эффекта;
ª возможность получения некоторых
дополнительных аналитических оценок транспортной системы.
2.
Требования
2.1
Требования к ПО c точки зрения пользователя
Учитывая квалификацию пользователя, его принадлежность к
кругу исследователей-экономистов, владение экономико-математическими знаниями,
требования, предъявляемые к разрабатываемому программному продукту, имеют
следующий вид.
ª поддержку проектной организации работы с
сохранением результатов;
ª возможность настройки на условия
конкретной задачи (правила кодирования данных);
ª наличие предопределенных типовых запросов,
позволяющих получить предварительную оценку стратегии;
ª возможность самостоятельно формировать
произвольные запросы к исходным данным;
ª наглядное отображение результатов (возможны
табличная, графическая и другие формы представления).
2.2
Требования к реализации
Исходя из сформулированных требований пользовательской
функциональности продукта, определяются требования к реализации заявленных
возможностей:
ª конвертирование выходных данных пакета
LP_VC во внутреннее представление;
ª оптимизированная структура данных,
хранящихся в БД;
ª эффективная система запросов;
ª конструктор запросов с понятным
пользовательским интерфейсом;
ª взаимодействие со средствами визуализации
результатов.
3.
Разработка
программного продукта
3.1
Выбор средств разработки
После анализа требований к программному продукту в качестве
средства разработки программного обеспечения был выбран пакет Microsoft Visual Studio 2005. Основной язык
программирования для реализации - C#. Выбор объясняется тем, что данная среда
разработки позволяет легко и эффективно реализовать ожидаемые от продукта
возможности и выполнить предъявляемые требования, а именно:
· функционирование в среде Microsoft Windows;
· удобный пользовательский интерфейс и
широкие возможности по наглядному отображению результатов;
· использование БД в качестве хранилища
информации.
Кроме того, данный пакет является современным средством
разработки программ и предоставляет разработчику мощные инструменты для
создания пользовательского интерфейса и требуемых связей с данными, а
платформа.NET, лежащая в его основе позволяет легко объединять программные
модули, написанные на разных языках.
Последнее свойство важно, например, при работе с картографией
в библиотеке MapX, основным языком для работы с которой является все же не C#, а Visual Basic.
В качестве хранилища внутреннего представления данных
пользователю предлагается на выбор два решения:
1. Microsoft SQL Server 2005.
2. Microsoft Access Database.
Первое из них нацелено на использование при решении
действительно больших задача, где критично быстродействие, но требует установки
на компьютер пользователя соответствующего программного обеспечения для
функционирования SQL-сервера. Для второго же SQL-сервер не требуется, его использование проще, но
скорость работы значительно ниже.
.2
Описание данных
Входные
данные
1. Файл проекта.
2. Выходной файл пакета LP_VC.
3. Хранилище информации - таблицы в БД (тип БД
определяется свойствами проекта).
. Прочие данные предопределяются свойствами проекта и
могут содержать:
· Входной файл пакета LP_VC, на основании которого был
сформирован результирующий выходной файл;
· Файл с указанием правил трансляции имен
строк и столбцов исходной таблицы.
· Файл сохраненных запросов.
Выходные
данные
1. Модифицированный файл проекта, содержащий внесенные
пользователем в проект изменения;
2. Хранилище информации - таблицы в БД;
. Прочие измененные файлы проекта.
3.3
Общая модель решения
На рис. 1 представлена общая схема работы разрабатываемого
программного обеспечения для оценки мультипликативного эффекта.
Основными входными данными является выходной файл пакета LP_VC, используемого при
решении задач линейного программирования. Ввиду особенностей этого пакета, его
входная информация должна быть подготовлена определенным образом. Для этого по
установленной пользователем LP_VC схеме кодируются переменные и условия решаемой
задачи. В выходном файле пакета кодирование данных сохраняется. Важным и трудоемким
этапом работы разрабатываемого программного обеспечения является раскодирование
и интерпретация этих данных для организации структуры внутреннего
представления, необходимой для эффективной работы.
После раскодирования и организации структуры хранения данных
информация должна быть внесена в созданные таблицы БД.
Затем, при помощи SQL-запросов выполняется извлечение требуемых сведение и
отображение результатов.
3.4
Структурная модель программного обеспечения
На рис. 2 представлена структура
разрабатываемого программного обеспечения, полученная после проведения анализа
требований и определения цели - реализуемой функциональности. В результате
декомпозиция по объектно-ориентированному принципу выделено пять модулей
программы:
1. Модуль работы с проектом;
2. Модуль интерпретации и трансляции входных данных;
. Модуль работы с базой данных;
. Модуль управления запросами;
. Модуль отображения результатов.
Дальнейшее разбиение выявляет функциональность каждого из
модулей, которую необходимо реализовать. Данный уровень декомпозиции достаточен
для определения содержания работ по разработке программы.
Ниже подробно описан каждый из узлов схемы.
.5
Описание модулей программы
Модуль
работы с проектом
В терминологии создаваемого программного продукта проект -
это файл определенного формата, содержащий ссылки на файлы, используемые
программой (например, файл входных данных, файл с правилами кодирования
информации, файл, хранящий тексты запросов и т.д.), а также настройки,
определенные пользователем.
Проектная организация работы позволяет, единожды настроив
программное обеспечение на анализируемые данные (определив связи с файлами,
правила кодирования, хранилище информации), немедленно вернуться к их обработке
в следующий раз, а также быстро переключаться между различными данными с
различными настройками. Кроме того, проект поддерживает централизованное
хранение индивидуальных настроек работы пользователя и сконструированных
запросов.
Требуемая функциональность:
1. Создание проекта, определение настроек. Создается файл проекта,
затем пользователь определяет связи с используемыми файлами и хранилище данных
проекта: строка доступа к SQL-серверу или файл MS Access.
2. Открытие существующего проекта. Восстанавливается работа
с проектом: устанавливается соединение с базой данных, загружаются сохраненные
пользовательские запросы и настройки.
. Инициализация других модулей. Инициализируется модуль
интерпретации и трансляции входных данных для определения правил
кодирования входных данных, модуль работы с базой данных для организации
соединения с указанным хранилищем информации и создания структуры таблиц БД, а
также модуль управления запросами для включения в проект
предопределенных типовых запросов.
4. Сохранение результатов работы во внешние
файлы. Сохраняются
созданные пользователем запросы, вспомогательная информация в виде
комментариев, а также измененные настройки.
Модуль
интерпретации и трансляции входных данных
Основной задачей разработки программного обеспечения стало
конвертирование исходных данных в формат, позволяющий производить их обработку
и анализ. Постановка транспортной задачи содержит множество переменных и
ограничений, смысл и параметры которых кодируется в одном лишь имени, в результате
чего имя представляет собой сложную структуру являющуюся ключом к интерпретации
полученного результата.
Таким образом, реализация данного модуля является наиболее
трудоемким процессом в реализации программного продукта.
Требуемая функциональность:
1. Чтение данных из файла. Построчное чтение
исходных данных, представленных в табличной форме, из выходного файла пакета LP_VC и выделение из строки
значений столбцов таблицы.
2. Определение правил кодирования. Для интерпретации имен
переменных и ограничений в исходном файле, пользователю необходимо определить:
· структуру имен;
· используемые при построении имен
параметры.
Для описания структуры имен пользователь должен задать шаблоны
построения для различных типов переменных и условий, а для параметров - еще и
их возможные значения. Так, например, для переменных, описывающих мощности
транспортных узлов параметрами являются имя узла, вид транспорта
и вид мощности, а значениями параметра «вид мощности» - «погрузо-разгрузочные
работы» и «пропуск транзита».
Кроме того, для исключения некорректной или же не полной
интерпретации входных данных, необходимо предоставлять пользователю список еще
не интерпретированных переменных, считанных из входного файла.
3. Интерпретирование данных на основе
построенных шаблонов. На основе заданных пользователем правил кодирования входной
информации имена всех считанных переменных и условий сравнивается на
соответствие одному из описанных шаблонов и интерпретируется их значение.
Например, определяется для какого именно вида транспорта задается мощность в
узле.
4. Трансляция данных в формат внутреннего
представления. После интерпретации имени переменной из столбцов строки таблицы
выделяются необходимые сведения и подготавливаются для заполнения таблиц БД.
Модуль
работы с базой данных
База данных используется для хранения информации, полученной
из входного файла, для ее обработки и анализа. На абстрактном уровне смысл
разрабатываемого программного продукта состоит именно в обработке данных, а
значит, организация их эффективного хранения и доступа является фундаментом, на
котором будет построена дальнейшая реализация продукта.
Модуль работы с базой данных должен быть способен обеспечить
необходимую скорость работы с большими объемами информации для анализа крупных
транспортных задач. В то же время нужно учесть и возможность работы с
небольшими задачами и для такого типа задач предоставлять предельно простой
способ организации хранилища информации. Именно с этой целью в модуле должна
быть реализована возможность хранения данных как в таблицах базы данных на
основе SQL-сервера, так и на основе более простого в использовании MS Access.
Требуемая функциональность модуля:
1. Создание структуры таблиц базы данных. Создаются таблицы для
хранения считанных данных, определяются связи между таблицами.
2. Заполнение таблиц исходными данными. Данные, полученные в
результате трансляции в формат внутреннего представления, заносятся в
соответствующие таблицы базы данных.
. Выполнение запросов к данным и передача
результатов для отображения. SQL-запросы, подготовленные модулем управления
запросами выполняются, а полученные в результате данные подготавливаются
для передачи модулю отображения результатов.
Модуль
управления запросами
Для извлечения требуемых сведений из базы данных используется
механизм запросов на языке SQL и данный модуль несет функциональную нагрузку по
организации работы с ними. SQL-запросы являются очень мощным инструментом
обработки данных, представленных в форме реляционных таблиц, но для раскрытия
их потенциала необходимо реализовать эффективные средства работы с настоящим
механизмом.
Требуемая функциональность модуля:
1. Хранение текстов запросов. Текст запросов на языке SQL извлекается при открытии
проекта из соответствующего файла, затем сохраняется во внутренние структуры,
которые могут быть дополнены в процессе пользовательской работы, и может быть
незамедлительно использован в случае необходимости извлечения описываемых им
данных.
. Конструирование произвольных запросов. Пользователь должен иметь
возможность самостоятельно сформировать запрос к данным для извлечения
необходимой ему информации.
Модуль
отображения результатов
Наглядное отображение результатов работы является одним из
основных требований к программному продукту. Данный модуль реализует различные
виды интерпретации результатов выполнения запросов к хранимой информации, а
именно, табличный и графический. К тому же возможно расширение способов
отображения, например, за счет реализации картографической формы изображения.
Требуемая функциональность модуля:
1. Отображение результатов в табличной форме. Базовым способом
представления результатов запроса к базе данных является табличная форма.
2. Отображение результатов в графической
форме. На
основе полученных в результате выполнения запросов табличных данных строятся
графики определенного вида. Графический способ представления повышает
воспринимаемость полученной информации.
3.6 Реализация решения
На основе описанных модулей модели программного обеспечения с
использованием упомянутых инструментов разработки были реализованы все
заявленные функциональные возможности продукта.
Далее приводится описание работы созданного программного
обеспечения.
.7
Описание работы программного обеспечения
Работа
с проектом
Основным файлом, содержащим информацию о связанных с проектом
файлах и прочие настройки, является файл с расширением *.pme.
Создание проекта
При создании проекта пользователь определяет:
· Свойства (такие, как имя проекта и комментарий
создателя).
· Директорию хранения файлов проекта, связи
с файлами: входных данных, правил кодирования и сохраненных запросов. В
качестве двух последних можно использовать файлы уже созданные в рамках другого
проекта, что значительно упрощает работу и экономит массу времени.
· Правила кодирования - описать с нуля, либо
отредактировать имеющиеся.
· Хранилище информации - базу данных на
основе любо SQL-сервера, либо MS Access. Для первого варианта необходимо
указать строку доступа к таблицам на сервере, для второго - расположение файла
*.mdb.
После подтверждения пользователем введенных данных в
выбранной директории создается файл проекта *.pme, а также другие необходимые
файлы. Если файл сохраненных запросов создается с нуля (не открывается ранее
созданный), то в него автоматически вносятся тексты предопределенных типовых
запросов.
Вслед за созданием файлов модулем работы с БД
формируется структура таблиц в базе данных и, затем, таблицы заполняются
сведениями из входного файла, считанными модулем интерпретации и трансляции
входных данных.
После завершения операций по созданию проекта отображается
интерфейс управления запросами, открывается окно типовых запросов.
Открытие проекта
Для открытия ранее сохраненного проекта пользователь в
интерфейсе управления проектом выбирает открываемый проект, после чего
происходит открытие необходимых файлов, загрузка информации о проекте и
запросах и устанавливается соединение с хранилищем данных проекта. Фактически,
файл, являющийся входным при создании проекта, и файл правил кодирования не
требуются при открытии существующего проекта, поскольку вся необходимая для
работы информация уже имеется в базе данных.
После восстановления всех связей с данными отображается
интерфейс управления запросами.
Сохранение проекта
Для того чтобы иметь возможность вернуться к работе над
проектом, минуя первоначальную настройку приложения, занимающую достаточно
много времени, необходимо по окончанию работы сохранить проект, записав
измененные в процессе пользования настройки и созданные запросы. Созданные в
базе данных таблицы и введенные данные также будут сохранены. Сохранение
предусмотрено интерфейсом работы с проектом.
Удаление проекта
Возможность удаления проекта присутствует в интерфейсе и
доступна пользователю. Предлагаются разные варианты удаления - выбор файлов,
которые необходимы для других проектов, а значит должны быть сохранены, и
уничтожения / оставления информации в базе данных.
Интерпретация,
трансляция входных данных
Чтение данных из файла
Чтение информации из входного файла реализовано стандартными
средствами языка программирования C#. Данные читаются построчно ввиду табличного
представления файла.
Определение правил кодирования
Пользователю необходимо определить правила кодирования
входной информации на этапе определения настроек проекта, и эта работа является
самой трудоемкой в процессе его создания.
Описание правил кодирования состоит из двух этапов:
1. Определение параметров, используемых при построении
имен и возможных значений этих параметров.
Описание шаблонов, задающих структуру имен переменных и
условий.
Список параметров фиксирован условиями решаемой задачи - в
нем представлены свойства транспортной сети. Пользователь заполняет список
возможных значений для каждого из параметров, определяя обозначение,
используемое непосредственно в имени, и его представление произвольным текстом
для лучшей воспринимаемости информации (Рис. 4). Например, для параметра «Тип
груза» возможно значение с обозначением «КЯ» означающее «Контейнеры
с Японии». Вводимые пользователем данные вносятся в соответствующие таблицы
базы данных.
Шаблоны, задающие структуру имен переменных и ограничений,
описываются в следующем виде:
[<имя переменной>] [<имя переменной>]
[<имя переменной>]… [<имя переменной>], где <имя
переменной> - имя параметра, определенного на первом этапе, в том виде,
в котором оно задано в списке параметров.
Интерфейс описания шаблонов предусматривает отображение в
нижней части окна считанных из входного файла имен переменных и ограничений, не
совпадающих ни с одним из введенных пользователем шаблонов (Рис. 5). Данная
возможность позволяет корректно и полно покрыть все множество имен множеством шаблонов.
Интерпретация данных на основе построенных
шаблонов
После определения пользователем правил кодирования для
каждого из построенных шаблонов генерируются регулярные выражения, покрывающие
все множество значений которым соответствует шаблон. Например, для шаблона «Мощности
транспортных узлов» со строкой значения [Имя узла] [Вид транспорта] [Вид
мощности] на основе ранее введенных возможных значений перечисленных
параметров будет сгенерировано следующее регулярное выражение: (БО|СУ|ТЕ)
(М|Ж|А) (ПР|ПТ).
Далее, при помощи встроенных функций работы с регулярными
выражениями в.NET, каждое имя переменной (либо ограничения) проверяется на
соответствие шаблону и классифицируются, как имя переменной (или ограничения)
соответствующего типа (например, «Мощности транспортных узлов»). После
классификации определяется значение каждого из параметров, использованных при
построении имени.
Трансляция данных во внутреннее представление
Из считанной стоки файла, содержащей имя классифицированной
переменной, извлекаются необходимые для заполнения таблиц данные (такие, как
значение ограничения, либо переменной), подготавливается структура для передачи
сведений модулю работы с БД, который заносит информацию в строки
соответствующей таблицы.
Сохранение правил кодирования в файл
Поскольку описание правил кодирование - очень трудоемкий
процесс, реализована возможность сохранения созданных правил в XML-файл и последующего их
использования в других проектах.
Работа
с базой данных
Платформа.NET Framework предоставляет
программисту богатый выбор объектов, позволяющих обращаться к базам данных.
Совокупность классов этих объектов носит имя ADO.NET. На рис. 6
изображена принципиальная схема работы ADO.NET. Для доступа к
информации в ADO.NET используются объекты, называемые управляемыми
провайдерам. Управляемый провайдер - это шлюз к хранилищу данных (например,
на сервере баз данных), при помощи которого можно произвести загрузку данных из
этого внешнего хранилища в созданные в программе объекты. Один из подобных
провайдеров - провайдер OLE DB, позволяет программно
обращаться к данным, расположенным в любом хранилище, к которому можно
подключиться по протоколу OLE DB. Таким образом, появляется возможность
использовать в ADO.NET управляемый провайдер OLE DB для доступа,
например, к базам данных SQL Server, MS Access и Oracle. Это позволяет легко
выполнить требование гибкой настройки приложения на различные типы хранилища
информации в зависимости от условий решаемой задачи.
Итак, в разработанном программном продукте реализована
возможность настройки на два типа баз данных: SQL Server и MS Access. В зависимости от
выбора, пользователю необходимо указать либо строку связи с сервером, либо
расположение файла *.mdb.
Создание структуры базы данных
Структура таблиц базы данных предопределена условиями
решаемой задачи анализа параметров транспортной сети и неизменна для всех
рассматриваемых вариантов.
На рисунке 7 представлена схема данных. Таблицы содержат
следующую информацию:
· Node - описание узла сети;
· Transport - описание видов
транспорта;
· Cargo - описание видов груза;
· Node_service - работы, выполняемы в узле
сети;
· Node_power - мощности узла сети;
· Node_resources - обеспеченность узла
ресурсами;
· Cargo_origination - зарождение и погашение
грузопотоков в узле;
· Section - пропускная способность
участка сети.
При создании проекта, структура базы данных копируется с
эталонной, сохраненной в файле, поставляемом с программным продуктом.
Заполнение таблиц исходными данными
В процессе создания проекта модулем работы с проектом,
когда определены правила кодирования и создана структура таблиц базы данных,
происходит заполнение сформированных таблиц информацией, подготовленной при
трансляции строк входного файла. Заполнение реализовано средствами ADO.NET.
Выполнение запросов к данным и передача
результатов
Корректное завершение работы с базой данных
При закрытии проекта данный модуль корректно завершает все
соединения, установленные хранилищем информации с сохранением внесенных в
таблицы изменений и подтверждением транзакций (commit()) или же с откатом (rollback()) и игнорированием
редактирования.
При удалении проекта у пользователя есть возможность удалить
созданный в процессе работы набор таблиц, либо сохранить их для использования в
другом проекте.
Работа
с запросами
Для извлечения необходимой информации из базы данных проекта
используется механизм SQL-запросов.
Хранение текстов запросов
В рамках работы с проектом реализована возможность сохранения
текстов запросов и их дальнейшего использования для оперативного получения
информации о рассматриваемой задаче. Тексты запросов сохраняются в файл
определенного формата и могут быть использованы при работе с другими проектами.
Использование предопределенных типовых запросов
Для первоначального анализа сформированного контура
транспортной сети данный программный продукт предусматривает наличие
предопределенных типовых запросов, позволяющих оперативно провести расчет
характеристик узлов и участков сети. Запросы были разработаны совместно с
экономистами-исследователями с учетом особенностей предметной области.
Запросы делятся на две группы по выбираемой ими информации:
1. О грузообразующих центрах.
О транспортных коридорах.
В рамках анализа грузообразующих центров, которые
присутствуют в оптимальном решении, формируются следующие сведения:
· Функционирующие транспортные системы
(автомобильные, железнодорожные, авиа, река-море).
· Суммарные объема погрузки, разгрузки.
· Объемы перегрузки с одного вида транспорта
на другой.
В рамках анализа коридоров сети формируются запросы:
· Загрузка участка (в процентах и в натуральных
показателях).
· Незагруженные участки.
· Основные центры грузообразования в
пределах коридора.
· Перегруженные / незагруженные участки.
· Виды транспортных систем.
Кроме того, присутствует режим анализ транспортных
магистралей (выделенных участков сети с рассмотрением функционирования одного
вида транспорта):
· Загрузка по всем участкам магистрали.
· Принадлежность магистрали действующему
коридору.
При создании проекта типовые запросы автоматически включаются
в число сохраненных и готовы к выполнению.
Интерфейс работы с предопределенными запросами по умолчанию
является начальным при работе с проектом, окно сохраненных запросов появляется
сразу после завершения процесса его создания, либо открытия.
Конструирование произвольных запросов
Помимо базовой информации, предоставляемой предопределенными
запросами, реализована возможность извлечения произвольных данных из таблиц при
помощи генерации нетиповых SQL-запросов. Дополнительно возможно использования
простейших арифметических функций, операторов обработки и компоновки
информации.
Интерфейсом пользователя для формирования запроса служит визуальный
построитель запросов. Построитель позволяет, не имея знаний языка SQL, создавать сложные
запросы, удовлетворяющие потребностям в извлечении информации из таблиц базы
данных. Эргономичный визуальный пользовательский интерфейс значительно упрощает
процесс разработки запроса (Рис. 9).
В качестве визуального построителя запросов использован
свободно распространяемый программный компонент SQLdesigner версии 1.2, созданный
фирмой Digitwash (#"656639.files/image017.gif">
Помимо простоты реализации, применение такого подхода
оправдано еще и тем, что пользователю становятся доступны богатые возможности Excel по дальнейшему
редактированию и настройке отображения полученных результатов. Кроме того,
большинство пользователей уже имеют навыки обращения c пакетом Microsoft Office.
.8
Системные требования
· Операционная система Windows 2000/XP/Server 2003.
· Установленный пакет Microsoft Office 2003.
· Опционально: SQL-сервер.
Требования к оборудованию дополнительно не обозначены,
поскольку конфигурация, функционирующая под управлением указанных операционных
систем, достаточно производительна для работы данного программного продукта.
Библиотеки, необходимые при развертывании и дальнейшего
функционирования, поставляются вместе с описанной программой.
3.9
Характеристики программного продукта
Объем кода: 3000 строк.
Степень отладки: 80%.
Заключение
В процессе разработки программного продукта были преодолены
следующие этапы:
1. Формулировка комплекса задач исследования.
2. Определение требований к программе.
. Построение концептуальной модели решения и
разработка проекта создания программного обеспечения.
. Разработка алгоритмов осуществления проектных
решений.
. Программная реализация решения.
. Тестирование и отладка программы.
Указанные этапы включают следующие выполненные работы:
ü Произведен обзор предметной области;
ü Изучены методы экономико-математического
моделирования, которые используются в ИЭОПП СО РАН при постановке, решении и
анализе транспортных задач при разработке среднесрочных и долгосрочных
прогнозов развития страны, подготовке стратегии развития Сибири и др.;
ü Проанализированы основные типы
экономических задач, при решении которых встают вопросы прогнозирования работы
транспортной системы, а также способы решения этих задач;
ü Систематизированы основные требования,
которые предъявляют экономические задачи к инструментарию, и рассмотрены
возможности их выполнения;
ü На основании анализа требований были
выбраны средства разработки;
ü Спроектирована структурная модель решения;
ü Разработана система обработки данных для
извлечения информации, необходимой для анализа вариантов транспортной
стратегии;
ü Разработан пользовательский интерфейс;
ü Осуществлена программная реализация;
ü Разработана система тестов и проведена
отладка программы;
ü Разработано руководство пользователя;
ü Проведен анализ полученных результатов и
направления дальнейшего развития проекта.
В результате работы над проектом был создан инструментарий
для анализа вариантов транспортной стратегии и оценки мультипликативного
эффекта их реализации.
Разработанное программное обеспечение позволяет провести первоначальный
анализ транспортной сети, получить предварительные оценки мультипликативного
эффекта, а также извлечь дополнительные сведения о параметрах рассматриваемой
конфигурации.
Результаты исследований, проведенных с помощью данного
инструментария, служат основой для более детального изучения вариантов
транспортной стратегии, предварительные оценки которых удовлетворяют
предъявляемым требованиям.
Направление дальнейшего развития продукта определятся целями
того исследовательского проекта, в рамках которого выполнялась данная дипломная
работа. В первую очередь, это расширение функциональности по оценке
мультипликативного эффекта - реализация разработанных
экономистами-исследователями методов. Последующая, значительно более крупная
задача, - это разработка алгоритмов и программного обеспечения визуализации
пространственных трансформаций, отвечающих разным вариантам транспортной
стратегии.
В рамках усовершенствования уже разработанного приложения
возможна реализация картографической формы отображения результатов, а также
разработка системы запросов для проведения более содержательного анализа
транспортной сети, например, оценки вероятных конкурентных вариантов стратегии
развития и последствий их осуществления.
2. Воробьева В.В., Есикова Т.Н., Ионова
В.Д., Малов В.Ю. Пространственный аспект стратегии развития Азиатской части
России: формирование Северного широтного пояса экономического развития страны.
- Новосибирск: ИЭОПП, 2004. - 48 с.
. Воробьева В.В., Есикова Т.Н., Ионова
В.Д., Малов В.Ю. Прогнозирование изменений пространственной структуры
макрорегионов России на базе транспортно-экономических балансов. - Новосибирск:
ИЭОПП, 2005. -114 с.
. Проблемные регионы ресурсного типа:
Азиатская часть России/ Под ред. В.А. Ламина и В.Ю. Малова. - Новосибирск:
Изд-во СО РАН, 2005. - 386 с.
. Транспорт и экономический рост. Доклад
заместителя Министра транспорта Российской Федерации А.С. Мишарина на 9-м
международном экономическом форуме в Санкт-Петербурге, 2005 г.
. Джесс Либерти. Создание.NET приложений.
Программирование на C#. 2-е издание. Изд-во «Символ-Плюс» - 690 с.
. Троелсен. Э. С# и платформа.NET.
Библиотека программиста. - СПб.: Питер, 2004. -796 с.
8. MSDN Library for Visual Studio
2005.
9. Управление проектом. Основы проектного
управления: учебник / кол. авт.; под ред. проф. М.Л. Разу. - М.: КНОРУС, 2006.
- 768 с.