|
|
|
содержание .. 33 34 35 36 ..
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
0#/
,
что
должно
гарантировать
целостность
(
сериализуемость
)
БД
.
Наиболее
широко
используются
алгоритмы
управления
,
основанные
на
механизме
блокировки
.
При
этом
24#%’"#(%#;
называют
ситу
-
ацию
,
при
которой
некоторая
транзакция
объявила
о
желании
получить
полномочия
на
доступ
к
стра
-
нице
памяти
и
,
следовательно
,
другие
транзакции
не
имеют
права
занимать
этот
ресурс
.
Одним
из
способов
управления
является
централизованное
блокирование
,
при
котором
на
одном
из
узлов
поддерживается
единая
таблица
блокировок
.
Такой
узел
устанавливает
очередность
выпол
-
нения
транзакций
,
что
исключает
конфликты
.
Однако
при
централизованном
управлении
невысока
надежность
и
требуется
мощный
сервер
.
В
РСУБД
с
репликацией
нет
проблемы
согласования
при
записи
действий
многих
узлов
.
Собст
-
венно
тиражирование
чаще
всего
выполняется
по
правилу
полной
эквивалентности
—
обновленные
данные
сразу
же
после
изменившей
их
транзакции
рассылаются
по
всем
локальным
БД
.
Чтение
же
выполняется
из
БД
одного
конкретного
узла
,
наиболее
близкого
к
пользователю
в
функциональном
или
географическом
смысле
.
Сложнее
решать
проблемы
распределенного
управления
,
что
требуется
в
РСУБД
без
тиражиро
-
вания
.
Одним
из
распространенных
протоколов
распределенного
управления
является
протокол
двух
-
фазной
фиксации
транзакций
(2
РС
).
На
первой
фазе
инициатор
транзакции
(
координатор
)
рассылает
участникам
выполнения
транзакции
оповещения
о
блокировке
.
В
ответ
узлы
сообщают
о
своей
готов
-
ности
или
неготовности
.
На
второй
фазе
координатор
сообщает
либо
о
“
глобальной
фиксации
”,
т
.
е
.
о
выполнении
транзакции
,
либо
об
откате
транзакции
.
Неприятности
возможны
при
сбоях
,
которые
мо
-
гут
оставить
некоторый
узел
в
заблокированном
состоянии
:
он
не
может
ни
выполнять
транзакцию
,
ни
отменять
ее
в
одностороннем
порядке
.
"84@8://01.
,8.
5,-9:
<38:9
D.0+>
384.7-+84
9:0+./
9
*
C
"%
.
В
зависимости
от
степени
ав
-
томатизации
управляющих
функций
можно
выделить
несколько
уровней
управления
проектированием
:
1
)
компонентный
;
на
этом
уровне
пользователь
должен
знать
специфические
особенности
каж
-
дой
конкретной
программы
,
используемой
в
маршруте
проектирования
;
при
организации
маршрута
он
должен
позаботиться
об
информационных
интерфейсах
используемых
программ
;
другими
слова
-
ми
,
системная
среда
лишь
предоставляет
сведения
о
имеющихся
программах
и
их
интерфейсах
;
2)
ресурсный
;
пользователь
по
-
прежнему
оперирует
программами
при
компиляции
маршрута
проектирования
,
но
системная
среда
позволяет
скрыть
специфику
каждой
программы
,
так
как
обще
-
ние
унифицировано
;
3)
задачный
;
пользователь
составляет
маршрут
проектирования
не
из
отдельных
программ
,
а
из
отдельных
проектных
процедур
;
покрытие
маршрута
программами
выполняет
системная
среда
;
4)
проблемный
;
пользователь
формулирует
задания
в
форме
“
что
нужно
сделать
”,
а
не
“
как
это
сделать
”,
т
.
е
.
не
определяет
маршрут
проектирования
,
а
ставит
проектную
проблему
.
В
системных
средах
САПР
70")(4$*’$
0"#$%&’"#()*’$/
возлагается
на
подсистему
CAPE,
в
не
-
которых
системах
обозначаемую
как
DesPM (Design Process Manager). DesPM
должна
включать
в
се
-
бя
компоненты
:
комплексы
базовых
знаний
по
тем
предметным
областям
,
которые
определяются
объ
-
ектом
проектирования
,
а
также
знаний
о
языках
представления
характеристик
и
ограничений
;
средст
-
ва
для
генерации
плана
(
маршрута
проектирования
),
определения
наличия
средств
и
ресурсов
для
ре
-
ализации
плана
;
средства
выполнения
плана
;
средства
оценки
результатов
. DesPM
позволяет
выби
-
рать
объекты
проектирования
,
производить
декомпозицию
моделей
,
для
каждого
компонента
выби
-
рать
проектные
процедуры
из
имеющегося
набора
.
По
каждому
объекту
DesPM
выдает
сообщения
,
примерами
которых
могут
быть
: “
объект
проек
-
тируется
другим
разработчиком
”, “
проектирование
преждевременно
,
не
выполнены
предшествующие
процедуры
”, “
не
подготовлены
исходные
данные
”.
Одной
из
важнейших
функций
DesPM
является
по
-
мощь
в
реализации
параллельного
проектирования
.
Желательно
в
DesPM
предусмотреть
возможнос
-
ти
создания
“
суперпроцедур
” —
командных
файлов
для
выполнения
часто
повторяющихся
фрагмен
-
тов
маршрутов
проектирования
.
Расширение
возможностей
управления
проектированием
и
адаптация
системной
среды
к
кон
-
кретным
САПР
связано
с
применением
языков
расширения
.
\6.%
")+>’"$*’9
—
это
язык
програм
-
мирования
,
позволяющий
адаптировать
и
настраивать
системную
среду
САПР
на
выполнение
новых
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
139
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
проектов
.
Язык
расширения
должен
обеспечивать
доступ
к
различным
компонентам
системной
сре
-
ды
,
объединять
возможности
базового
языка
программирования
и
командного
языка
,
включать
сред
-
ства
процедурного
программирования
.
Для
большинства
языков
расширения
базовыми
являются
ЛИСП
или
С
.
Так
,
язык
Skill
из
Design Framework-2
фирмы
Cadence
или
язык
СС
L (CASE Comment Language)
фирмы
Matra
Datavision
являются
ЛИСП
-
подобными
,
а
язык
AMPLE
из
Falcon Framework
фирмы
Mentor Graphics
базируется
на
языках
:
и
ПАСКАЛЬ
.
Управление
процессом
проектирования
включает
в
себя
большое
число
действий
и
условий
,
поддерживающих
параллельную
работу
многих
пользователей
над
общим
проектом
.
Управление
вы
-
полняется
на
основе
моделей
вычислительных
процессов
.
Используются
спецификации
моделей
,
принятые
в
CASE-
системах
,
например
,
диаграммы
потоков
данных
,
ориентированные
графы
.
Снача
-
ла
модели
составляют
для
задачного
уровня
,
а
затем
система
осуществляет
их
покрытие
.
Применяют
также
описания
на
языках
расширения
или
4GL.
В
системной
среде
Ulyses
спецификации
даны
в
ви
-
де
набора
модулей
с
указанием
условий
их
активизации
,
что
близко
к
представлению
моделей
в
сис
-
темах
,
управляемых
знаниями
.
Так
,
каждый
проектирующий
программный
модуль
может
быть
акти
-
визирован
только
в
том
случае
,
если
входные
данные
готовы
.
Для
этого
специальная
0"#8")//)
70
-
")(4$*’9
/#-749/’
системной
среды
отслеживает
соблюдение
отношений
следования
между
проект
-
ными
операциями
и
процедурами
,
заданными
в
маршруте
проектирования
.
На
эту
же
программу
воз
-
лагаются
функции
регулирования
прав
доступа
к
модулям
,
сбор
статистики
(
протоколирование
)
по
обращениям
к
модулям
и
некоторые
другие
.
Необходимо
обеспечение
синхронизации
изменения
данных
,
разделяемых
многими
пользовате
-
лями
.
Для
этого
,
во
-
первых
,
пользователи
подразделяются
на
классы
(
администрация
системы
,
руко
-
водство
проектом
и
частями
проекта
,
группы
исполнителей
-
проектировщиков
)
и
для
каждого
класса
вводят
определенные
ограничения
,
связанные
с
доступом
к
разделяемым
данным
;
во
-
вторых
,
обеспе
-
чивают
средства
ведения
многих
версий
проекта
;
в
-
третьих
,
для
выполнения
работ
в
отдельных
вет
-
вях
параллельного
процесса
пользователям
выделяют
свои
рабочие
области
памяти
.
Данным
могут
присваиваться
различные
значения
статуса
,
например
, “
правильно
”, “
необходимо
перевычисление
”,
“
утверждено
в
качестве
окончательного
решения
”
и
т
.
п
.
Собственно
синхронизация
выполняется
с
по
-
мощью
механизмов
типа
рандеву
или
семафоров
,
рассматриваемых
в
пособиях
по
параллельным
вы
-
числениям
.
Примером
подсистемы
управления
проектированием
в
САПР
СБИС
может
служить
Minerva,
разработанная
специ
-
алистами
университета
Карнеги
-
Меллона
(
США
).
В
ней
реализуется
нисходящее
проектирование
на
основе
модели
в
ви
-
де
И
-
ИЛИ
-
дерева
.
Дерево
может
быть
не
полностью
определено
к
началу
проектирования
и
его
отдельные
кусты
дораба
-
тываются
в
процессе
проектирования
.
На
каждом
ярусе
дерева
происходит
выбор
альтернатив
,
формирование
ТЗ
для
сле
-
дующего
иерархического
уровня
,
возможны
возвраты
.
В
средствах
пользовательского
интерфейса
предусмотрено
высве
-
чивание
на
экране
фрагментов
дерева
,
по
каждой
ветви
дерева
сообщается
о
ее
готовности
к
проработке
,
занимается
ли
ею
кто
-
то
другой
из
разработчиков
и
т
.
п
.
В
общем
случае
полная
формализация
управления
проектированием
не
может
быть
достигнута
,
поэтому
полезную
роль
играют
+’+&$/.
0#--$"@%’
"$>$*’;
,
принимаемых
людьми
, DSS (Decision
Support Systems).
В
качестве
таких
систем
часто
используют
хранилища
данных
и
OLAP-
средства
(On-Line Analytical Processing).
Использование
хранилищ
данных
имеет
ряд
преимуществ
в
управлении
большими
объемами
данных
:
имеется
единое
ядро
,
что
исключает
чрезмерно
разветвленные
и
длительные
транзакции
,
лег
-
че
синхронизировать
внесение
изменений
,
поддерживать
единство
форматов
данных
,
хранить
преды
-
дущие
версии
и
т
.
п
.
OLAP-
средства
должны
обеспечивать
оперативный
доступ
к
данным
,
на
основе
которого
выяв
-
ляются
зависимости
между
параметрами
(
измерениями
в
многомерной
модели
приложения
).
В
OLAP-
системах
на
реляционных
СУБД
аналитическая
обработка
,
или
,
другими
словами
,
многомер
-
ный
динамический
анализ
данных
требует
просмотра
большого
числа
записей
из
разных
таблиц
.
По
-
этому
производительность
оказывается
невысокой
.
В
специализированных
OLAP-
системах
,
обеспе
-
чивающих
более
быстрый
многомерный
анализ
,
но
с
более
существенными
ограничениями
на
объем
БД
,
данные
хранятся
в
виде
гиперкубов
или
поликубов
—
многомерных
таблиц
с
постоянным
или
пе
-
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
140
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
ременным
числом
ячеек
соответственно
.
Пример
OLAP
системы
— Oracle Express,
помогающей
ме
-
неджерам
и
аналитикам
получать
данные
в
виде
разрезов
таких
многомерных
таблиц
,
готовить
отче
-
ты
,
обосновывать
решения
.
В
|