Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сборник научных трудов кафедры информационных систем и технологий управления в строительстве. Выпуск 1.pdf
X
- •ПРОЕКТИРОВАНИЕ НА ОСНОВЕ МЕТАСИСТЕМНОГО АНАЛИЗА
- •МЕТАСИСТЕМНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
- •«ИНТЕЛЛЕКТУАЛЬНЫХ ЗДАНИЙ»
- •А.В. СЕДОВ, П.Д. ЧЕЛЫШКОВ, И.В. РЕДИН
- •С.В. ШИЛКИНА, Е.А. ШИЛКИНА
- •НЕКОТОРЫЕ ВОПРОСЫ КВАНТОВОЙ ГЕОМЕТРИИ
- •И.П. БЕЛЯЕВ, В.М. КАПУСТЯН
- •Рис. 1
- •НА СТРОИТЕЛЬНЫХ ОБЪЕКТАХ
- •В СТРОИТЕЛЬНЫХ ОРГАНИЗАЦИЯХ
- •НЕСКОЛЬКО СЛОВ ОБ ОПТИМИЗАЦИИ ЗАПРОСОВ
- •ORACLE С ПОМОЩЬЮ ИНДЕКСОВ
- •О СУЩНОСТИ ИНТЕЛЛЕКТУАЛЬНОГО ЗДАНИЯ
- •СОВРЕМЕННЫЕ ПРОБЛЕМЫ ЖКХ
- •ЕГО ПОТЕНЦИАЛА

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
Т а б л и ц а 1
Основные программные модули подсистемы GROUND
Обозначение Обозначение Функциональное назначение
1 2 3
Стационарная
задача
Нестационар-
ная задача
Нелинейная
задача
Принцип
перераспреде-
ления в кон-
тактной зада-
че
Принцип раз-
рывности
в контактной
задаче
STAZA
ASTAZA
STAZAM
HESTA
AHESTA
HESTAM
HEZA
AHEZA
HEZAM
GES
GEMOS
REZ
GESP
GEMOSP
REZP
– модуль определения стационарного поля
влажности в расчетной области;
– модуль определения стационарного поля
влажности с учетом анизотропности
проводимости;
– модуль определения стационарного поля
влажности с учетом распределенных источников;
– модуль прогноза нестационарного поля
влажности в расчетной области;
– модуль прогноза нестационарного поля
влажности с учетом анизотропности
проводимости;
– модуль прогноза нестационарного поля
влажности с учетом распределенных источников;.
– модуль прогноза нелинейного нестационарного поля влажности в расчетной области;
– модуль прогноза нелинейного нестационар-
ного поля влажности с учетом анизотропности
влагопереноса;
– модуль прогноза нелинейного нестационарного поля влажности с учетом распределенных
источников;
– модуль определения коэффициентов
канонических уравнений с учетом принципа
перераспределения;
– модуль определения реактивного давления и
перемещений контактной поверхности с учетом принципа перераспределения;
– модуль расчета суммарных изгибающих
моментов и вектора реактивных усилий;
– модуль определения функции реактивного
давления с учетом принципов разрывности;
– модуль определения коэффициентов
канонических уравнений с учетом принципа
разрывности;
– модуль расчета суммарных изгибающих
моментов и суммарного вектора реактивных
усилий;
41

СБОРНИК НАУЧНЫХ ТРУДОВ
Обозначение Обозначение Функциональное назначение
– модуль определения коэффициентов
канонических уравнений с учетом
внутреннего принципа контактности;
– модуль распределения реактивного давления
и перемещений контактной поверхности с учетом внутреннего принципа;
– модуль расчета суммарного изгибающего
момента и суммарного вектора реактивных
усилий;
– модуль определения коэффициентов
канонических уравнений для составных
конструкций;
– модуль определения функции реактивного
давления составных конструкций;
– модуль расчета суммарного изгибающего
момента и суммарного вектора реактивных
усилий;
– модуль определения полей перемещений в
просадочной среде грунтового основания;
– модуль определения полей деформаций и
напряжений в просадочной среде основания;
– модуль расчета полей перемещений в грунтовом основании (упругая задача);
– модуль расчета полей деформации и напряжений в грунтовом основании (упругая задача);
– модуль определения полей перемещений в
набухающем основании;
– модуль определения полей деформации и
напряжений в набухающем основании.
– управляющая программа
Внутренний
принцип в
контактной
задаче
Принцип со-
ставности в
контактной
задаче
Определение
НДС осадоч-
ной среды
Определение
НДС упругой
среды
Определение
НДС набу-
хающей среды
Управление
вычислитель-
ными процес-
сами в под-
системе
GESV
GEMOSV
REZV
GESS
GEMOSS
REZS
HEODP
HDSP
HEOD
HDS
HEODH
HDSH
DRIVE
Среди компонентов подсистемы GROUND особое место занимает
программное обеспечение, поскольку в нем нашли отражение все идеи и
методы, заложенные в структуру системы.
Основным блоком подсистемы является управляющая программа
(DRIVE), которая обеспечивает необходимую последовательность выполнения этапов обработки и координацию информационного обмена между
операционной памятью, внешними носителями и устройствами вводавывода.
Модульностью подсистемы обеспечивается работа с библиотекой
моделей, представляющимися программными модулями, реализующими
42

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
математические описания модели, и наборами внутренних параметров.
Программные и информационные части моделей составляют базу данных,
входящую в банк данных (БнД) подсистемы. Настройка программы проектирования на работу с конкретной моделью заключается в установлении
связей по управлению и информации между модулями проектирования,
программным модулем модели и набором внутренних параметров.
Системный принцип организации программ проектирования определил необходимость использования единой информационной базы данных
(БД), которая обеспечивает возможность автоматической передачи информации между различными задачами. Информационная совместимость
достигается использованием всеми модулями проектирования стандартных величин предметной области пакета и реализации информационных
связей между модулями проектирования. Информационное обеспечение
модулей проектирования, а тем самым и программы проектирования, является функцией управляющей программы.
Необходимые исходные данные для выполнения устанавливаемых
заданий, корректировки массивов базы данных, контроля и корректировки
выполнения заданий со стороны проектировщика (пользователя) осуществляется с помощью периферийных средств связи с ЭВМ.
Все программные модули и процедуры подсистемы GROUND составлены с учетом возможности их самостоятельного использования при
решении отдельных задач оценки взаимодействия зданий и сооружений с
грунтовым основанием в процессе проектирования грунтовых сооружений.
В целом программное обеспечение подсистемы GROUND разделяется на два уровня: обеспечивающее и функциональное. Обеспечивающее
программное обеспечение отвечает за работу основных базовых функций
программной системы: организацию ввода-вывода, взаимодействия с
пользователем, управления работой подсистем. Функциональное программное обеспечение состоит из подсистем решения всех задач расчета и
анализа полей влажности при решении различных задач проектирования
грунтовых сооружений. Информационное обеспечение подсистемы
GROUND составляет банк данных (БнД), состоящий из баз данных (БД)
функциональных подсистем, базы данных метаинформации и базы данных управляющей программы.
Общая структура программной подсистемы представлена на рис. 2.
Вместе с тем, выделяются некоторые особенности разрабатываемой
подсистемы: большое количество информационных массивов исходной и
результатной информации; зависимость подсистем по исходным и результатным данным требует наличия общей информационной базы системы;
расширяемость функционала системы при условии возможности использования общего банка данных.
43

СБОРНИК НАУЧНЫХ ТРУДОВ
Программный комплекс GROUND
Информационное
обеспечение
Банк данных
Базы данных:
- база данных
управляющей
подсистемы;
- базы данных
функциональных
подсистем;
- база
метаинформации
;
- СУБД.
Обеспечивающее (общесистемное)
программное обеспечение
Подсистема
организации
диалога
с пользователем
Интерфейсы:
- ввода-вывода
данных;
- экспорта
данных;
- поиска;
- формирования
отчетов;
- диагностики БД;
и др.
Программное обеспечение
Управляющая
подсистема
Подсистемы:
- обеспечения
взаимодействия
подсистем;
- отслеживания
состояния
объектов учета.
Функциональное
программное
обеспечение
Подсистема №1
.
.
.
Подсистема №M
Рис 2. Общая структура подсистемы GROUND
Анализ связанности отдельных программных модулей и процедур
подсистемы GROUND позволил сделать вывод об относительной их автономности: их разработка может проводиться раздельно друг от друга
при условии организации доступа к общему банку данных системы. Эта
особенность учитывалась при создании архитектуры системы и проектировании банка данных (БнД) для нее.
Анализ существующих подходов к разработке сложных программных систем показал возможность реализации программного комплекса в
виде отдельных самостоятельных программных систем с единой системой
управления, с общим единым для всех функциональных подсистем интерфейсом взаимодействия с пользователем и базой данных, но различным функционалом (децентрализованная архитектура). Предложенный
вариант архитектуры программной системы предполагает абсолютную автономность функциональных подсистем и решаемых ими задач. Каждая
функциональная подсистема должна представлять отдельный программный комплекс со своим функциональным программным обеспечением и
базой данных. Обеспечивающее программное обеспечение (интерфейс
взаимодействия с пользователем и базой данных) является одинаковым
для всех подсистем. При этом основная задача управляющей программы
44

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
состоит в объединении информационных ресурсов подсистем в единый
банк данных, создающий единое информационное пространство для работы подсистем функционального программного обеспечения.
Обеспечивающее программное обеспечение (ПО) управляющей подсистемы DRIVE вызывает необходимую функциональную подсистему
для решения конкретной задачи. Обеспечивающее ПО функциональной
подсистемы организует процесс решения задачи: диалог с пользователем,
ввод и вывод данных, запуск ПО функциональной подсистемы. Исходные
данные и результаты работы ПО функциональной подсистемы сохраняются в БД подсистемы.
После окончания работы функциональной подсистемы результаты ее
работы, а также данные, введенные пользователем, реплицируются в банк
данных (БнД) подсистемы GROUND для использования управляющей
подсистемой DRIVE и другими функциональными подсистемами. Из центрального банка данных посредством репликации отдельные данные переходят в базу данных той функциональной подсистемы, где они требуются. Если в какой-то подсистеме меняются общие для всех данные, то
эти изменения отражаются на работе всех функциональных подсистем
вследствие единого адресного пространства. Это позволяет говорить, что
такая архитектура будет работать как единый программный комплекс для
решения поставленных задач.
Все функциональные подсистемы должны иметь одинаковую архитектуру. Архитектура подсистемы представлена на рис. 3.
0.00 0.10 0.20 0.30 0.40
0.00
W %
5.00
10.00
15.00
1
2
3
20.00
25.00
30.00
H c m
4
12.00
10.00
8.00
6.00
4.00
2.00
0.00
0.00 2.00 4.00 6.00 8.00 10.00 12.00 14.00
Рис. 3. Логика работы подсистемы GROUND
45

СБОРНИК НАУЧНЫХ ТРУДОВ
Разделение программной логики функциональной подсистемы на
уровни является результатом функциональной декомпозиции задач подсистемы, при которой группы функций сгруппированы в четыре большие
группы:
1) функции представления данных и организации диалога с пользо-
вателем;
2) функции взаимодействия системы с базой данных;
3) функции обработки данных в системе;
4) функции управления работой подсистемы.
Каждая группа функций предполагает реализацию в виде совокупности функций и процедур (программной логики), взаимосвязанных между собой для решения своей области задач.
Логика представления данных и организации диалога, логика взаимодействия с базой данных, логика управления подсистемой представляет
собой часть обеспечивающего программного обеспечения единого для
всех функциональных подсистем.
Логика взаимодействия системы с базой данных организована на основе архитектуры универсального доступа к данным (Microsoft Universal
Data Access architecture).
Учитывая, что используемый при этом интерфейс OLE DB является
низкоуровневым, а его использование в прикладном программном обеспечении может сильно усложнить программную логику, что увеличит время
отладки и тестирования, более оптимальным является использование технологии ADO. Архитектура организации доступа к данным в подсистеме
GROUND представлена на рис. 4.
Рис 4. Архитектура доступа к данным в системе GROUND
46

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
Взаимодействие функциональной подсистемы с базой данных производится с помощью программной логики взаимодействия с базой данных, реализованной во всех подсистемах по единым правилам посредством стандартизованного в рамках всей системы интерфейса доступа к данным.
При инициализации подсистемы программный интерфейс организации доступа к данным посредством стандартных библиотек ADO обращается к таблицам метаинформации базы данных подсистемы за получением информации об информационных элементах, к которым необходимо
организовать доступ: справочники, оперативные массивы, хранимые процедуры. На основе полученных метаданных генерируются объекты доступа к данным. Такая организация взаимодействия с базой данных дает существенные преимущества при динамичной и меняющейся структуре базы данных: в этом случае нет необходимости проводить повторную отладку подсистемы в связи с тем, что все необходимые изменения делаются динамически на основе метаинформации о системе.
Независимость уровней программной логики друг от друга позволяет повысить эффективность разработки программного обеспечения за счет
снижения количества изменений одного уровня при изменении другого:
при изменении методов доступа к данным совершенно не изменится логика их представления пользователю, что предполагает устойчивости разрабатываемой системы к изменениям в составе используемых технологий;
изменение логики проведения расчета не вызовет изменений в интерфейсе
и методах доступа к данным, следовательно не потребуется их повторная
отладка и тестирование.
Разработанная архитектура, взятая за основу при разработке
GROUND, учитывалась при разработке банка данных и пользовательского интерфейса ее функциональных подсистем. Управление работой полсистемы GROUND осуществляется программным модулем DRIVE по
двухуровневому принципу. В соответствии с этим нижний уровень представляет собой набор программ, предназначенных для управления решением отдельных задач, определяемых значением вводимого пользователем кода.
На основе общей архитектуры системы, поставленной для информационного обеспечения задач и анализа существующих подходов, была
разработана архитектура информационного обеспечения (рис. 5), включающая следующие элементы: база данных управляющей подсистемы; база данных функциональных подсистем; система управления базами данных (СУБД).
47

СБОРНИК НАУЧНЫХ ТРУДОВ
База данных управляющей программы представляет собой хранилище общей для всех подсистем и общесистемной информации, используемой для управления работой как GROUND в целом, так и отдельных ее
подсистем. Банк данных включает в себя систему управления базами данных, базу данных метаинформации и базу данных управляющей подсистемы.
Рис 5. Архитектура информационного обеспечения
В качестве системы управления базами данных для общего банка
данных и баз данных подсистем была выбрана СУБД Access 2002, что
обусловлено наличием необходимого инструментария и классом разрабатываемой системы (систему планировалось использовать как на отдельных рабочих станциях, так и на серверах сети).
База данных метаинформации предназначена для хранения информации об объектах системы, их свойствах и настройках для использования
при динамической генерации пользовательских интерфейсов вводавывода и обслуживания для структур данных системы.
База данных управляющей подсистемы используется для хранения
информации о состоянии объектов системы, полученных результатах расчетов, сформированных отчетах и другой информации, используемой
управляющей подсистемой для организации работы подсистем и информационного обмена между ними.
Базы данных функциональных подсистем представляют собой самостоятельные базы данных, предназначенные для организации накопления
информации, необходимой для решения задач подсистемы, и состоит из
48

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ В СТРОИТЕЛЬСТВЕ
следующих элементов: общие таблицы, справочники, оперативные массивы, таблицы результатов и таблицы метаинформации.
В качестве СУБД по рассмотренным выше причинам была выбрана
настольная СУБД Access 2002.
Разработанная архитектура является более эффективной по сравнению с организацией банка данных в виде единого информационного хранилища в связи с возможностью проведения изолированных друг от друга
процессов разработки отдельных функциональных подсистем и более эффективного информационного обмена.
На этапе проектирования отдельных программных модулей подсистемы GROUND был апробирован подход с использованием статической
структуры информационной базы. Проведенный анализ показал, что ее
масштаб и структура данных не противоречат требования к многофункциональности и расширяемости системы и не снижают эффективность такого подхода, а также функциональность системы и область ее применения. Однако при проектировании САПР грунтовых сооружений использование жесткой структуры базы данных как подход может оказаться неприемлемым в условиях ее расширяемости и обеспечения возможности
использования в ее рамках различных программных комплексов, требующих использования подходов динамического формирования системных и
пользовательских интерфейсов при работе с динамической информационной базой системы. Сущность такой базы состоит в возможности динамического изменения как ее структуры (добавление и удаление полей, изменение иерархической принадлежности элементов), так и содержания (редактирование, добавление и удаление элементов информационной базы).
При этом, динамические изменения структуры информационной базы
влияют на все информационные процедуры, интегрированные в систему,
и, как результат, на состояние системы в целом.
Такой подход позволяет повысить гибкость и надежность системы в
условиях возможных изменений как в алгоритмическом обеспечении подсистем, так и в структуре и составе информационной базы. Кроме того, по
сравнению с традиционным подходом, это значительно снижает дополнительные затраты при изменении функциональности или расширении системы.
Учитывая большое количество различных по структуре и содержанию наборов данных в информационной базе (справочники, оперативные
массивы, дополнительные данные и др.), при создании подсистемы
GROUND был принят единый подход к формированию их внешнего
представления в принятой форме (пользовательского интерфейса), отражающей все особенности структуры. Реализация данного подхода пред-
49

СБОРНИК НАУЧНЫХ ТРУДОВ
полагает предварительный анализ и разделение полей всех наборов данных информационной базы на следующие группы: адресная часть (первичный ключ), уникальный индекс элемента, информационная часть.
Таким образом, в составе любого набора данных выделяются три
соответствующих группы полей данных. Эта процедура производится на
этапе создания структуры набора (при формировании задания на программирование) с использованием процедуры именования элементов информационной базы.
Г.Г. АРУНЯНЦ, Т.Р. ТЕДЕЕВ
К ВОПРОСУ О ПОВЫШЕНИИ ЭФФЕКТИВНОСТИ
ВЗАИМОДЕЙСТВИЯ СРЕДСТВ САПР ГРУНТОВЫХ СООРУЖЕНИЙ
В УСЛОВИЯХ ЕЕ ЭВОЛЮЦИОННОГО РАЗВИТИЯ
Прогресс науки и техники, потребности развивающегося общества в
новых строительных объектах, обусловливают необходимость выполнения проектных работ большого объема. Рассматривая грунтовые сооружения как объект проектирования, необходимо иметь в виду, что стремительный научно-технический прогресс приводит к увеличению стоимости
научных исследований при их создании, особенно на начальных стадиях,
когда ошибочные решения влекут за собой тяжкие и трудно исправимые
последствия.
Многообразие учитываемых при проектировании связей и ограничений, большое количество вариантов технических решений определяет
трудности задачи оптимального проектирования, преодоление которых
возможно лишь путем создания систем автоматизированного проектирования (САПР), объединяющих творческие усилия человека и большие возможности ЭВМ в выполнении трудоемких операций.
Можно сказать, что в настоящее время автоматизация проектирования
грунтовых сооружений связывается с новым этапом развития – созданием
специализированных подсистем САПР, предназначенных в основном для
решения задач научно-исследовательского и технического проектирования.
Общим для всех САПР является то, что они могут сами рассматриваться как автоматизированная система управления с обратной связью.
Другими словами, САПР – это человеко-машинная или автоматизированная система управления технологическим процессом (АСУ ТП) производства технической документации, необходимой для создания проектируемого объекта.
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
