Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сборник научных трудов кафедры информационных систем и технологий управления в строительстве. Выпуск 1.pdf
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
Таким образом, разрабатываемая в СКТМИ (ГТУ) САПР грунтовых
сооружений рассматривалась как модель проектируемой системы, в которой учитываются основные виды динамического и информационного
взаимодействия между ее частями, включая проектировщиков.
Разработка теории и методики автоматизированного проектирования
грунтовых сооружений представляет собой, несомненно, очень сложную
проблему. Прежде всего, это связано с трудностью формализации или математического описания и составления моделей процессов взаимодействия зданий и сооружений с грунтовым основанием. С первого взгляда, составление модели может показаться безнадежной задачей. Однако существует ряд факторов, облегчающих решение такой задачи, к основным из
которых относятся: накопленные знания физической и химической сущности процессов влагораспределения, опыт и интуиция, часто позволяющие уменьшить сложность формируемого математического описания.
Любой процесс проектирования представляет собой процесс управления, то есть получение, сбор, передачу, обработку и представление информации для принятия решений, направленных на устранение отклонений от цели проектирования, определяемой техническим заданием.
Исходя из принципов, положенных в основу при разработке функциональных подсистем решения задач проектирования в рамках САПР
грунтовых сооружений, основные усилия по разработке должны быть направлены на решение трех основных взаимосвязанных задач:
1) создание и объединение ресурсов проектирования;
2) разработка информационной базы системы;
3) разработка средств взаимообмена проектировщика с системой.
Под ресурсами проектирования здесь понимаются всевозможные
модули и подсистемы для анализа и синтеза задач проектирования.
Эволюционность САПР предполагает не столько логическую связь
между модулями, сколько причинно-следственные отношения меду явлениями. Установления взаимосвязей между подсистемами и модулями
осуществляется в результате структурного анализа и выявления определенной последовательности использования подсистем и модулей при выполнении поставленных задач.
Результаты проведенного анализа принципов построения САПР и
наработанная методология расчета и анализа полей влажности при решении различных задач проектирования грунтовых сооружений в рамках
традиционного проектирования с использованием средств ЭВМ для решения отдельных вычислительных задач позволили выявить обобщенную
структуру средств САПР грунтовых сооружений, основными компонентами которой являются (рис.1):
автоматизированный банк данных проектирования (БнД САПР);
программный комплекс, управляющий процессом проектирования;
51
СБОРНИК НАУЧНЫХ ТРУДОВ
ДБДБДБДБД
пакеты прикладных программ решения отдельных задач в рамках
единой архитектуры САПР;
внешние прикладные программ решения отельных задач общего и
специального назначения, не работающие в рамках единой архитектуры
САПР.
Среди компонентов САПР грунтовых сооружений особое место занимает программное обеспечение, состоящее из ряда подсистем, представляющих собой отдельные программные модули или самостоятельные программные комплексы решения отдельных задач проектирования.
БАНК ДАННЫХ
проектирования
Управляющая
программа САПР
Интерфейс
ввода-вывода
Интегрированные
Интегрированные
Интегрированные
ППП
ППП
ППП
Ввод исходных данных
и результатов в режиме
диалога
База данных
Б
СУБД
САПР
для решения задач проектирование
ВНЕШНИЕ ППП
Рис. 1. Укрупненная структура средств САПР грунтовых сооружений
Исходные данные для работы каждой прикладной программы должны находиться в банке данных системы и передаваться в прикладную программу с помощью специально разработанных программных средств.
Основным блоком системы является управляющий программный
комплекс, который обеспечивает необходимую последовательность выполнения этапов обработки и координации информационного обмена между компонентами САПР. Системный принцип организации программ
проектирования определяет необходимость использования единой информационной базы данных (банка данных) системы, что позволяет организовать автоматический обмен информацией между различными задачами.
Взаимодействие между отдельными подсистемами САПР грунтовых сооружений в процессе решения задач проектирования происходит на уровне параметров. В этих условиях наличие единого информационного хра-
52
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
нилища способно обеспечить функцию информационного обеспечения
САПР. Этим единым хранилищем является банк данных проектирования,
представляющий собой совокупность баз данных под управлением СУБД
и служебных программ для обслуживания банка данных.
Сам процесс проектирования, осуществляемый в рамках САПР, может
быть представлен в виде ориентированного графа, вершинами которого
являются отдельные задачи проектирования, а дугами – связь этих задач
по входным/выходным параметрам. Такой граф является отражением логики автоматизируемого с помощью САПР процесса проектирования.
Банк данных САПР (БнД) грунтовых сооружений представляет собой
хранилище всех необходимых для обеспечения процесса проектирования
данных, а также результатов самого процесса проектирования.
Прикладные программы (ПП) для включения в состав САПР должны
соответствовать следующим требованиям:
1. ПП должна быть реализована в виде стандартного исполняемого
файла для унификации процедур запуска прикладной программы.
2. ПП должна иметь два режима работы: диалоговый и пакетный, ус-
танавливаемые передачей параметров через командную строку.
Необходимость в применении диалогового режима при работе ПП определяется особенностями их использования в рамках САПР, так как в
процессе решения отдельных задач проектирования возможны прерывания, при которых осуществляется запрос на принятие проектировщиком
определенного решения, связанного с ходом выполнения процедур проектирования. При этом сам диалог в отдельных программах САПР может
быть различным в зависимости от алгоритмических особенностей и специфики отдельных задач проектирования.
Учитывая особенности структурной организации САПР грунтовых сооружений, создаваемой в концепции иерархических человеко-машинных
систем, при постановке задачи обеспечения диалога в рамках подсистем
САПР была принята многоуровневая архитектура, позволяющая обеспечить высокую эффективность использования системы диалогового режима взаимодействия человека с системой на всех уровнях при решении отдельных задач.
Известно, что пакетный режим расчетов по прикладной программе на
основе исходных данных, расположенных в файловых структурах установленной формы, связан с известными издержками информационного
обмена. Это делает его крайне неэффективным при использовании в рамках сложно структурированных САПР. В связи с этим, при постановке задачи разработки информационного и системного программного обеспечения для ключевой подсистемы САПР грунтовых сооружений – GROUND
автоматизированного расчета и анализа параметров взаимодействия зданий и сооружений – был принят принцип организации информационного
53
СБОРНИК НАУЧНЫХ ТРУДОВ
обмена между ее отдельными комплексами и модулями через специальный универсальный интерфейс ввода-вывода. Результаты работы программы в этом случае могут выводиться как в файловые структуры установленного формата, так и непосредственно в банк данных проектирования (системы) с помощью того же интерфейса.
При решении определенного комплекса задач зачастую возникает необходимость использования внешних прикладных программ, разработанных до создания конкретной САПР (ее подсистем) и с использованием
других средств и технологий. Это определяется тем, что такие программы
могут носить уникальный характер для решения поставленных задач. Эти
программы (программные комплексы), естественно, не рассчитаны на интеграцию в единое ПО конкретной САПР и могут быть использованы
только как самостоятельные (независимые) программные продукты. Однако их использование зачастую становится крайне необходимым в условиях отсутствия в рамках САПР соответствующих аналогов, особенно на
первых этапах создания САПР.
Результатная информация, полученная на различных этапах проектирования сохраняется в банке данных САПР. Источниками такой информации могут быть: проектировщики, внутренние прикладные программы,
внешние прикладные программы, сервисные подпрограммы.
Проектировщики – пользователь или группа пользователей, выполняющих решение задач проектирования с помощью САПР. При этом
пользователь имеет возможность вручную заполнять БнД необходимыми
исходными данными для решения поставленной задачи, выполнять ее решение вне системы известными ему способами (возможно с использованием внешних прикладных программ) с последующим вводом результатов
решения в БнД системы.
Внутренние программы – программные модули, интегрированные в
состав САПР, вызываемые управляющей программой для решения конкретной задачи. При этом передача параметров происходит автоматически
либо через файловые структуры, либо через специальные программные
интерфейсы, обеспечивающие стыковку управляющей программы САПР
и соответствующей прикладной программы.
Внешние прикладные программы – самостоятельные (независимые)
программы (программные комплексы), обладающие средствами решения
конкретной задачи проектирования в диалоговом режиме, но не интегрированные в САПР. Внешние программы не могут напрямую взаимодействовать с банком данных проектирования в силу того, что просто не рассчитаны на это. Взаимодействие с этим родом программ осуществляется
через проектировщика по процедуре, описанной выше.
Сервисные программы САПР – программные подсистемы САПР,
напрямую взаимодействующие с банком данных проектирования для ре-
54
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
шения задач обслуживания и предоставляющие управляющей программе
системы развитые программные интерфейсы для выполнения задач
управления процессом проектирования.
По мере развития САПР, новые подсистемы должны органично интегрироваться в единую систему проектирования. Они также должны взаимодействовать с единым БнД проектирования для получения исходных
данных и вывода результатов для дальнейшего использования другими
подсистемами. Учет всех этих требований является обязательным при
проектировании архитектуры САПР.
На первый взгляд, для функционирования САПР как единой системы
необходимо каждой подсистеме предоставить доступ к своей части БД в
СУБД. При этом каждая прикладная программа будет непосредственно
обращаться к БнД для считывания исходных данных и записи результатов
и работать только с внешним представлением данных этой подсистемы.
Однако при такой организации взаимодействия прикладных программ
с БнД САПР возникает необходимость каждый раз при вводе новой (или
модификации действующей) подсистемы создания новой структуры данных в БнД.
При достаточно большом числе подсистем, использующих свои внутренние средства для взаимодействия с БнД, затрудняется решение задачи
сохранения единства подходов к работе с информационным обеспечением
САПР. Кроме того, имеющая место в этом случае жесткость связи подсистемы с физическим местонахождением данных в БнД может привести к
нарушению работоспособности системы при любых изменениях структуры БнД САПР.
Необходимо также обратить внимание на то, что развитие основных и
вспомогательных подсистем САПР, как правило, сильно разнесено во
времени. Подсистема может быть реализована значительно позже основных средств САПР. В то же время реальна ситуация, когда развитие САПР
потребует изменения, как основных программных средств САПР, так и ее
информационного обеспечения. В этих условиях будет невероятно сложно
обеспечить целостность и работоспособность САПР в целом.
Еще одним негативным моментом является то, что разработчику ПП
технологически неудобно завязывать свой процесс разработки на некоторый уже существующий БнД проектирования, структура и состав которого находятся в постоянном развитии. Такое развитие определяется невозможностью заранее создать все структуры данных, необходимые для решения задач проектирования. Это вызывается необходимостью постоянного развития самого процесса проектирования: появление новых методов
решения отдельных задач, изменение подходов к их реализации, создание
новых программных продуктов и т.п. В то же время эффективность разработки прикладного ПО для САПР грунтовых сооружений в целом связана
55
СБОРНИК НАУЧНЫХ ТРУДОВ
с предоставлением проектировщику достаточной (если не полной) степени свободы при выборе им необходимых технологий и средств, что, естественно, исключает жесткую привязку к существующему хранилищу данных проектирования. Основным выводом из вышеизложенного является
очевидность нерациональности прямого взаимодействия прикладного ПО
САПР с единым банком данных проектирования (БнД).
В общем случае обеспечение требований переносимости и расширяемости подсистемы GROUND САПР грунтовых сооружений в условиях
эволюционного развития во многом связано с решением вопроса создания
единых четких правил взаимодействия всех ПП с БнД проектирования.
Программная реализация этих правил предусматривает создание единого
объектного интерфейса ввода-вывода, основной задачей которого становится предоставление ПП (подсистеме) доступа к той части БнД проектирования, в которой находятся исходные данные и конечные результаты
работы этой подсистемы.
Использование специального объектного интерфейса ввода/вывода
для взаимодействия подсистем с банком данных предполагает разработку
класса (компонента) для взаимодействия с БнД. Сам класс должен быть
выполнен на основе технологии DCOM (CORBA) и может быть оформлен
в виде исполняемого файла или динамической библиотеки.
Разработчик подсистемы САПР подключает модуль класса интерфейса ввода/вывода для взаимодействия с БнД САПР. С помощью стандартных методов он имеет возможность обращаться к банку данных проектирования за получением необходимой информации, а также для сохранения
результатов работы подсистемы в БнД, после чего они становятся доступными для других подсистем САПР, также работающих через единый
стандартизованный интерфейс.
Использование стандартизованного интерфейса позволяет:
облегчить модификацию системы (при расширении функциональности не нужно будет менять программный код подсистем в части взаимодействия с банком данных, необходимо только поменять исходный код
интерфейса).
максимально сократить время доступа к данным за счет почти
прямого обращения к СУБД банка данных проектирования.
Для удобства разработчика подсистемы интерфейс должен иметь
средства локальной разработки, т.е. пока подсистема разрабатывается, она
должна взаимодействовать с локальной базой данных подсистемы, которая в дальнейшем будет транслироваться в структуры данных БнД САПР.
После завершения отладки и тестирования средствами единого интерфейса должен быть сформирован DDL-скрипт, с помощью которого при интеграции подсистемы в БнД САПР будут создаваться структуры данных для
этой подсистемы. Соответственно работающая подсистема (интегриро-
56
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
ванная в САПР) будет взаимодействовать не с локальной БД подсистемы,
а с БнД проектирования. Возможность переключения подсистемы с локальной базы на аналогичные по форме структуры БнД САПР должны
быть реализованы в предоставляемом разработчику едином интерфейсе.
Переключение режима работы интерфейса на взаимодействие подсистемы
с БД САПР производится по завершении отладки и тестирования подсистемы. Интерфейс подсистемы может быть переведен в режим автономной
работы (отключение от БнД САПР и переключение на локальную БД) при
необходимости проведения ее отладки и тестирования.
Возникают следующие вопросы. Насколько реальным является реализация такого универсального интерфейса? Как возможно обеспечение процесса разработки приложения через данный интерфейс?
Ответ на этот вопрос просматривается при анализе особенностей реализации системы взаимодействия прикладных программ с БнД САПР через единый объектный интерфейс ввода/вывода.
БД подсистемы должна создаваться с помощью методов единого интерфейса и именно через этот же интерфейс ПП должна получать все данные из локальной БД. В общем, работа приложения должна быть инвариантна режимам работы интерфейса (работа с локальной БД, работа с БнД
САПР).
Для этого в едином интерфейсе необходимо реализовать стандартизованные процедуры (методы) доступа к данным, среди которых можно перечислить следующие:
1. Создание информационного массива указанной структуры;
2. Связывание информационных массивов по определенным прави-
лам;
3. Получение содержимого информационного массива в виде струк-
туры данных «массив записей» (здесь предполагается, что сначала будет
создана структура данных типа «запись», а затем – массив таких записей в
виде структур данных самой прикладной программы и виде внешних
структур данных (с помощью метода, используемого при реализации п.1).
4. Запись данных в определенный информационный массив.
Реализация доступа к данным через указанные методы (процедуры)
обеспечивается принципом физической независимости программ от данных. Подсистеме достаточно знать, что для получения необходимых ей
данных она должна обратиться к интерфейсу ввода-вывода с помощью
стандартных, известных ей операций, перечисленных выше. Все остальное должно быть скрыто внутри интерфейса (рис.2).
57
СБОРНИК НАУЧНЫХ ТРУДОВ
д
БнД
Интерфейс
а-вывода
вво
Закрытая часть
(свойства, методы):
Банк данных системы
Открытая часть
ЛБД
Локальная база данных
(свойства, методы):
Прикладные
Прикладные
Прикладные
программы
программы
программы
Рис. 2. Взаимодействие прикладных программ с БД и БнД САПР
грунтовых сооружений
В рамках принятой идеологии построения САПР грунтовых сооружений каждая прикладная программа создается самостоятельно с использованием тех средств и технологий, которые разработчик считает необходимым использовать для решения поставленной для прикладной программы задачи. Например, разработчик может создавать прикладное ПО
на различных языках программирования с использованием самых разных
инструментов.
После завершения отладки и тестирования разработанного программного обеспечения с помощью интерфейса необходимо создать в локальной БД структуры данных, аналогичные тем, которые использовал
разработчик для реализации своих алгоритмов. Так, любая прикладная
программа имеет массивы с исходной и результатной информацией. Следовательно, посредством стандартизованных процедур интерфейса можно
создать аналогичную структуру в локальной БД. Это необходимо для того, чтобы в дальнейшем легко интегрировать разработанную подсистему в
состав ПО САПР под управлением единой управляющей программы.
Возможно, для удобства разработчика при создании структур данных,
аналогичных внутренним структурам прикладной программы, возникнет
необходимость создания специальной диалоговой утилиты для интерфейса ввода-вывода, с целью автоматизации процесса репликации внутренних
структур данных прикладной программы во внешние структуры БД и БнД
САПР методами стандартного интерфейса.
Следующей стадией подготовки полученной прикладной программы
к включению (интеграции) в состав ПО САПР является увязка внешних
структур данных, созданных при помощи интерфейса ввода-вывода, с
внутренними структурами данных прикладной программы. Сама эта про-
58
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
цедура с технической точки зрения не представляется сложной, т.к. для
доступа к внешним структурам данных используются те же методы открытой части стандартного интерфейса. Для этого в процедуру инициализации прикладной программы встраивается программный код, который
перебрасывает исходные данные из внешних структур (локальная БД или
БнД САПР) во внутренние структуры данных прикладной программы, а в
процедуре деинициализации прикладной программы вводится программный код, осуществляющий вывод результатной информации из внутренних структур во внешние.
Разрабатываемая САПР грунтовых сооружений в целом, по характеру
своего функционирования является активной системой «человекмашина». Поэтому при создании ее подсистемы большое внимание должно уделяться обеспечению эффективной связи человека с ЭВМ и рациональному разделению функций между ними. Для создания благоприятных условий для решения этих проблем необходима организация эффективных диалоговых систем.
Рациональное распределение функций в САПР грунтовых сооружений должно базироваться на детальном изучении свойств и возможностей
инженеров- проектировщиков грунтовых сооружений, программных и
технических средств, применяемых при автоматизации процесса проектирования.
Все программные модули и процедуры подсистем САПР грунтовых
сооружений должны составляться с учетом возможности их самостоятельного использования при решении отдельных задач в процессе проектирования грунтовых сооружений. В целом программное обеспечение
подсистемы разделяется на два уровня: обеспечивающее и функциональное. Обеспечивающее программное обеспечение отвечает за работу основных базовых функций программной подсистемы: организацию вводавывода, взаимодействия с пользователем, управления работой подсистем.
Функциональное программное обеспечение состоит из подсистем решения всех задач расчета и анализа полей влажности при решении различных задач проектирования грунтовых сооружений.
Принятая при создании как подсистемы GROUND, так и САПР грунтовых сооружений в целом, концепция построения и организации взаимодействия прикладного программного обеспечения с банком данных проектирования (БнД САПР) через универсальный объектный интерфейс
ввода-вывода позволяет не только повысить эффективность САПР грунтовых сооружений за счет применения при создании ее специального программного обеспечения единых правил информационного обмена, но и
создать необходимые условия для ее развития в условиях изменяющихся
требований к составу задач и методам их решения.
59
СБОРНИК НАУЧНЫХ ТРУДОВ
И.В. БУЧАЦКИЙ
ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ ПРОЕКТНЫХ
ОРГАНИЗАЦИЙ
Проектно-изыскательские организации – организации, выполняющие
технико-экономическое обоснование (ТЭО), изыскательские работы, техническое и рабочее проектирование, а также осуществляющие авторский
контроль и надзор. Проектные работы являются необходимой составной
частью строительного цикла. Объемы проектных работ составляют относительно небольшую долю в общем объеме инвестиций в строительство,
обычно эта доля составляет 5 – 7, редко 10 –12%. Однако это очень ответственный этап инвестиционного цикла, требующий высокой квалификации исполнителей.
Структура проектных организаций имеет ряд своих особенностей, зависящих от специфики проектируемых объектов строительства. Для проектных организаций промышленного или транспортного профиля, т.е. организаций, проектирующих объекты, основной ролью которых является
некоторая технология, характерна структура функциональных отделов,
при которой каждый производственный отдел состоит из сотрудников одной или нескольких близких специальностей, например, электротехнический отдел, отдел охраны окружающей среды.
В организациях, которые проектируют преимущественно жилые и общественные здания, преобладает иная структура, которую можно назвать
структурой мастерских. В этом случае мастерская выполняет проектную
документацию одного или нескольких объектов полностью, от начала до
конца. В такой мастерской, которую возглавляет опытный архитектор, –
именно архитектурное решение является основным критерием качества
проекта жилого или общественного здания, - собраны специалисты разных специальностей, работающие над одним и тем же объектом.
Стоит заметить, что проектные организации, имеющие структуру мастерских в «чистом» виде, в жизни встретить можно довольно редко. Как
правило, некоторые специальности, например, сметчиков, электриков,
обычно предпочитают все же собрать в функциональные отделы – ради
экономии трудовых ресурсов и их более равномерной загрузки. В этом
случае мы имеем дело со смешанной структурой.
Организация процесса управления ходом проектирования является
сложным процессом, так как на всем его протяжении требуется координация работы большого количества специалистов и организаций, а также
применяется множество взаимосвязанных решений в контексте изменяю-
60