/
Текст
ПРИКЛАДНАЯ
ИНФОРМАТИКА
Сборник статей под редакцией
В.М. Савинкова
Выпуск 14
Издается с 1981 Г,
МОСКВА ’’ФИНАНСЫ И СТАТИСТИКА” 1988
ББК 32.973
П 75
Редакционная коллегия:
Ю. Е. Антипов; Г. Т. Артамонов; П. И. Братухин; В. М. Брябрин;
О. В. Голованов; И. Г. Дмитриева; К. Н. Евсюков; А. П. Ершов, акаде¬
мик; В. Н. Засыпкин, Ю. М. Каныгин; М. А. Королев; С. С. Лавров, чл,-
кор. АН СССР; В. Н. Лебедев (зам. отв. редактора); Г. П. Лопато, чл.-
кор. АН СССР; В. Л. Макаров, чл.-кор. АН СССР; И. И. Малашинин,
Б. Н. Наумов, академик; Л. Д. Райков; В. М. Савинков (отв. редактор);
Ю. М. Соломенцев; А. А. Стогний, чл.-кор. АН СССР; Г. К. Столяров
(зам. отв. редактора); Л. Н. Сумароков, чл.-кор. АН СССР; В. П. Тихо¬
миров; Э. X. Тыугу, чл.-кор. АН ЭССР; В. А. Ярба
П
2405000000—020
120—88
010(01)—88
© Издательство «Финансы и статистика», 1988
ПРЕДИСЛОВИЕ
Производство и применение средств вычислительной техники сложились
в 70-е годы в одну из важнейших народнохозяйственных отраслей, которая по
совокупности показателей может быть названа отраслью информационной тех¬
нологии и которая намного превосходит другие отрасли по темпам своего раз¬
вития, являясь ключевым фактором научно-технического прогресса. Только че¬
рез массовое внедрение средств вычислительной техники можно резко повысить
уровень автоматизации производственных процессов, производительность труда
во всех сферах народного хозяйства (в том числе в научной и конструкторской
деятельности), эффективность всех звеньев государственного аппарата и др.
Информационное обслуживание специалистов играет все большую роль в
ускорении научно-технического прогресса. Однако в 90-е годы информационные
ресурсы в развитых странах (США, Япония) уже будут представлены в основ¬
ном на машиночитаемых носителях и станут недоступными при традиционной
форме распространения информации через печатные издания. Концепции фор¬
мирования национальных информационных ресурсов на машиночитаемых носи¬
телях посвящена статья А. 17. Веревченко «Создание машиночитаемых инфор¬
мационных ресурсов — одно из условий интенсификации научно-технического
прогресса». Учитывая важность проблемы, редколлегия предполагает продол¬
жить ее обсуждение в последующих выпусках.
Инструментальные средства поддержки на ЭВМ процессов разработки про¬
граммного обеспечения (ПО) привлекают все большее внимание специалистов.
Редакторы, компиляторы, отладчики, средства машинной графики, СУБД, спе¬
цификаторы и др. составляют сегодня среду поддержки, обеспечивающую жиз¬
ненный цикл ПО. Несмотря на ускорение разработок ПО, обеспечиваемое инст¬
рументальными средствами, их внедрение еще уступает по массовости, напри¬
мер, СУБД. Это обусловлено трудностью разработки средств инструментальной
поддержки и отставанием системы образования, при которой необходима до¬
полнительная подготовка специалистов по использованию среды поддержки ПО.
Состояние дел со средствами машинной поддержки цикла жизни ПО за ру¬
бежом приводится в обзоре И. А. Мельникова и др.
За последние годы резко возросла потребность в графическом представле¬
нии информации. Средства машинной графики стали обязательными компонен¬
тами не только систем автоматизированного проектирования, но и ЭВМ: от
ЕС и СМ ЭВМ до профессиональных персональных ЭВМ. Отдавая должное
разнообразным пакетам прикладных программ, поддерживающим машинную
графику, редколлегия сборника предлагает читателям в этом выпуске статью
Равнина И. А. и Темова В. Л. «Техника битовых представлений и обработка
изображений». Авторам удалось объединить традиционный алгоритмический
подход (со стандартными типами — объектов алгоритмов) с нетрадиционным
представлением изображений, подлежащих обработке на ЭВМ. Используя прин¬
цип расширяемости языка Картран, построенного на базисе уже реализован¬
ного языка ИНФ-78 и некоторой надстройки над ним, авторы получили не
только новую среду битовых представлений, но и показали возможность ее
аппаратной реализации.
В обзорной статье Г. В. Сенина «Системы манипулирования базами дан¬
ных для персональных ЭВМ» персональные базы данных (ПБД) классифици¬
руются по трем основным аспектам: функциональным возможностям, степени
интегрированности и характеру интерфейса пользователя. Кроме необходимой
3
па начальной стадии работ на ПЭВМ классификации читателей сборника бу¬
дут интересовать и другие не менее важные вопросы: Какие конкретные за¬
дачи по обработке данных и ценой каких усилий можно выполнить с помощью
ПБД? Какова окупаемость трудозатрат применений ПБД? Эта проблема стоит
особенно остро в связи с тем, что после установки пакета для работы с ПБД
и обучения проходит иногда весьма длительное время, когда требуются боль¬
шие вложения трудозатрат без какой-либо полезной отдачи. Редколлегия пред¬
полагает публикацию серии статей на эту тему в последующих выпусках.
СМ ЭВМ играют все более важную роль в балансе средств вычислитель¬
ной техники и особенно программного обеспечения. Статья Н. Л. Прохорова
«Вычислительный комплекс СМ1700. Архитектура, программное обеспечение и
применение» открывает цикл публикаций по новому поколению СМ ЭВМ, об¬
ладающему рядом существенных преимуществ по сравнению с ЭВМ типа СМ-4,
СМ1420. Переход на 32-разрядные ЭВМ позволяет уже в этой пятилетке зна¬
чительно улучшить качество проектирования изделий машиностроительной про¬
дукции, перейти на более совершенные программные средства при создании ин¬
формационных систем, резко поднять общий уровень программирования.
Преимущественное положение ЕС ЭВМ в нашей стране привело к такому
состоянию, когда одновременно эксплуатируются различные модели этих машин
от «Ряда-1» до «Ряда-3».
Разнообразие применений, различие конфигураций моделей ЕС ЭВМ, раз¬
витие программных средств, смена поколений ЕС ЭВМ в эксплуатирующихся
системах — все это не могло не сказаться на развитии ОС ЕС и системного
программного обеспечения ЕС ЭВМ. Текущее состояние системного программно¬
го обеспечения ЕС ЭВМ рассматривается в статье О. Ю. Еремина и др.
В статье О. М. Вейнерова и др. «Инфологическая модель в системе авто¬
матизированного проектирования баз данных: концепции и реализация» приво¬
дится язык инфологического описания предметной области, используемый в
САПР БД «Омега». Результаты, опубликованные в этой и предыдущей статьях
(см.: Прикладная информатика. — 1987. — Вып. 2 (13)), позволяют принципи¬
ально по-новому специфицировать задачу проектирования БД.
В остальных статьях этого выпуска сборника освещаются вопросы, пред¬
ставляющие, по мнению редколлегии, значительный теоретический и практиче¬
ский интерес для специалистов в области вычислительной техники и инфор¬
матики.
1. СИСТЕМА ИНФОРМАТИКИ
УДК 002.5:681.5
А. П. ВЕРЕВЧЕНКО
СОЗДАНИЕ МАШИНОЧИТАЕМЫХ
ИНФОРМАЦИОННЫХ РЕСУРСОВ —
ОДНО ИЗ УСЛОВИЙ ИНТЕНСИФИКАЦИИ
НАУЧНО-ТЕХНИЧЕСКОГО ПРОГРЕССА
Реализация экономической стратегии партии предусматривает
интенсификацию производства и повышение его эффективности на
базе ускорения научно-технического прогресса. При этом осущест¬
вляется концентрация усилий и ресурсов по пяти приоритетным
направлениям: электронизация народного хозяйства, комплексная
автоматизация, атомная энергетика, новые материалы и техноло¬
гии их производства и обработки, биотехнология [1,2].
В результате реализации первоочередных задач, решаемых в
рамках указанных направлений, будут созданы:
суперЭВМ нового поколения для применения в решении особо
сложных научных задач в управлении экономикой и создании баз
знаний;
массовые средства вычислительной техники, персональные ЭВМ
с развитым программным обеспечением для широкого насыщения
отраслей народного хозяйства, научно-исследовательских и конст¬
рукторских организаций, компьютеризации сферы образования и
применения в быту;
системы автоматизированного проектирования и технологичес¬
кой подготовки производства, автоматизации и ускорения иссле¬
дований и экспериментов, автоматизированные системы управле¬
ния производством, технологическими процессами, интегрирован¬
ные системы управления и т. д.
Насыщение науки, техники, производства, управления и обра¬
зования высокопроизводительными ЭВМ всех классов и масшта¬
бы их применения будут возрастать высокими темпами. Однако
эффективное использование создаваемого вычислительного потен¬
циала станет возможным только в том случае, если своевременно
будут созданы необходимые объемы машиночитаемых информа¬
ционных ресурсов в тех проблемных областях, где намечается ин¬
тенсивное увеличение вычислительных мощностей.
Без накопления требуемых объемов достоверных и актуаль¬
ных машиночитаемых информационных ресурсов невозможно ши¬
рокое внедрение автоматизированных рабочих мест, автоматизи¬
рованных систем научных исследований и комплексных испытаний
5
образцов техники, а также создание систем оценки современного
и перспективного уровней техники. На необходимость формирова¬
ния информационных банков, объединяющих машиночитаемые ре¬
сурсы различных ведомств, и их эффективность при решении за¬
дач создания и обеспечения надежности крупных народнохозяйст¬
венных комплексов, в том числе в кризисных ситуациях, обращает
внимание академик Б. Е. Патон [3]. Поэтому особого внимания
заслуживает предложение, что в «силу особой важности такого
класса работ, их сложности и трудоемкости они должны войти в
народнохозяйственный план в качестве специальных, государствен¬
но приоритетных исследований с соответствующим правовым и
материально-техническим обеспечением» [4].
Перенос все большей части информационных ресурсов на ма¬
шиночитаемые носители приводит к существенным изменениям во
всех процессах, связанных с накоплением, обменом и обработкой
информации, а также процессов доступа к этим ресурсам. Это в
свою очередь ведет к преобразованию всей системы информации.
Особенности этого процесса могут быть проиллюстрированы
на примере структурных изменений документальных информацион-
Рис. 1. Динамика роста числа баз данных и объема фондов:
линии (—, ) построены по данным, имеющимся в ис¬
точнике, линии ( ) экстраполированы на основании дан¬
ных в этих источниках
6
ных ресурсов. Для этого проанализируем изменения следующих
параметров (рис. 1):
1) накопленный объем мирового, доступного специалистам на¬
родного хозяйства документального фонда. За его минимальную
величину в первом приближении может быть принят суммарный
объем фондов всесоюзных органов НТИ [5,6,7] (обозначен ли¬
нией 7);
2) количество коммерческих библиографических и небиблиог¬
рафических баз данных (БД):
всего в мире: линия 1 [9]; линия 5 [11]; линия 6 [12];
в Западной Европе:
всего (линия 2) [10];
библиографических (линия 3) [10];
небиблиографических (линия 4) [10];
3) количество библиографических записей, доступных через
коммерческие БД:
ГЦЛЦонт информационных ресурсов на машиночитаемых носителях
Рис. 2. Прогнозные оцен¬
ки переноса различных
видов информационных
ресурсов на машиночи¬
таемые носители
суммарное число библиографических записей: линия 8 [9,19];
в 400 наиболее доступных БД (точка 12) [20];
в том числе в режиме удаленного теледоступа: линия 10 [16];
БД системы Lockched DIALOG (линия 11) [16,21,22].
Кроме этого, следует учитывать прогнозные оценки числа из¬
даний, которые будут иметь только машиночитаемую форму пред¬
ставления от общего числа изданий того или иного вида (рис. 2):
патенты США (точка 1) [23];
патенты Японии (точка 2) [23];
технические отчеты, доклады, сообщения (точка 3) [15];
справочники (линия 4) [15];
7
периодические издания (по естественным, общественным и гу¬
манитарным наукам (точка 5) [15];
процент информационно-библиографических и реферативных
служб, использующих только электронные формы носителей [15]
(точка 6).
Приводимые на рис. 1 и 2 данные характеризуют нижнюю гра¬
ницу значений, принимаемых исследуемыми показателями, так
как они взяты из источников, имеющих ограничения по охвату БД,
информационных систем и сетей. Кроме этого, при описании кон¬
кретных объектов учета, приведенных в источниках, отсутствуют
значения некоторых показателей. Например, приведен суммарный
объем фонда, но отсутствуют данные о годовом приросте фонда и
(или) о части фонда, доступной в режиме удаленного теледосту¬
па, и т. п. Кроме того, в используемых источниках описываются
взаимопересекающиеся, но не совпадающие по объему множества
объектов учета. Это позволяет отнести анализируемые данные, ис¬
пользуя принятое в [5] определение, к 5-му классу точности, т. е.
таким данным, для которых отклонения в значениях могут дости¬
гать свыше 20—50%. Следовательно, приведенные на рис. 1 и 2
значения показателей могут быть использованы только для при-
кидочных, качественных оценок структурных изменений в доку¬
ментальных информационных ресурсах.
За исходную дату, начиная с которой в практику информаци¬
онного обслуживания стали внедряться первые библиографические
БД, принят 1962 год.
Процесс переноса библиографической информации на машино¬
читаемые носители осуществляется высокими темпами. Уже к
1974—1975 гг. число библиографических БД достигло 300—400 с
суммарным числом записей не менее 50 млн., а годовой прирост
составил около 4—8 млн. записей. К 1978—1980 гг. количество ка¬
талогизированных на машиночитаемых носителях документов ста¬
ло сопоставимым с суммарным объемом накопленных фондов на¬
учно-технических документов. В настоящее время БД (только по
науке, технике и медицине [12]) имеют фонды около 300 млн. за¬
писей на значительную ретроспективу (табл. 1).
Изложенное позволяет сделать вывод о том, что в 80-х годах
библиографическая информация стала первым информационным
ресурсом, полностью зафиксированным на машиночитаемых носи¬
телях.
Большая часть этого ресурса (около 60—70%) доступна в ре¬
жиме удаленного теледоступа, что позволило сосредоточить в не¬
которых системах значительную часть мировых библиографиче¬
ских ресурсов. Например, в 1980 г. через систему Lockched DIA¬
LOG было доступно более 100 БД с общим числом записей около
40 млн., через SDC ORBIT — более 50 БД с числом записей около
30 млн., а через BRC и IRC — в каждой около 30 БД и около
20 млн. записей [16]. В 1984 г. через систему Lockched DIALOG
было доступно уже более 180 БД, содержащих около 80 млн. за¬
писей [21], а в 1985 г. — чуть меньше 200 БД общим объемом
8
Таблица 1
Временной охват информации, включаемой в базы данных [12]
Ретроспектива
фонда до даты
Количество
баз данных
В том числе
по науке, технике,
медицине
1700
4
1
1763—1800
8
6
1820—1860
12
5
1890—1900
26
14
1902—1913
11
6
1919—1939
32
17
1940—1945
30
22
1946—1950
48
23
1951—1955
32
11
1956—1960
55
19
1961 — 1965
68
38
1966—1970
201
121
1971—1975
306
189
1976—1980
286
127
1981—1985
353
145
нет данных
1333
309
Всего
2 805
1053
90 млн. записей [22]. При этом (по данным на 1980 г. [16]) око¬
ло 10—30% библиографических БД, предоставляющих услуги в
режиме удаленного теледоступа, не имели традиционных «изда¬
тельских» версий указателей по своим массивам, а сохранившиеся
библиографические издания стали менее информативными по
сравнению с одноименными машиночитаемыми БД.
Во второй половине 70-х годов начался массовый перенос на ма¬
шиночитаемые носители и других видов документальных ресурсов:
справочных изданий о свойствах веществ и материалов; каталогов
(регистров) различных видов продукции, оборудования, техники;
технических отчетов и документации; терминологических словарей
и др.
В таких БД на машиночитаемых носителях сосредоточивается
наиболее актуальная управленческая и экономическая информация,
основная масса данных, получаемых в процессе научных исследо¬
ваний на автоматизированных рабочих местах, а также результа¬
ты издательской деятельности организаций, использующих авто¬
матизированные системы обработки текстов. Например, в практи¬
ку информационной деятельности начали внедряться «электрон¬
ные» издания, содержащие полные тексты документов, доступ к
которым возможен только с помощью ЭВМ:
ACS Journal Online (издание научной ассоциации ACS) вклю¬
чает полные тексты, доступно через сеть. Охватывает: 15 журна¬
лов— с 1980 г., 2 журнала — с 1982 г., 1—с 1976 г., общее коли¬
чество статей — 38 519.
9
Таблица 2
Временной охват документов, включаемых в базы данных
типа «электронных изданий»
Дата
ретроспективы
фонда
1961
1967
1974
1978
1980
1981
1982
1983
1984
Нет
дан¬
ных
Всего
Количество баз
данных
1
1
1
1
9
6
25
55
19
30
118
EMIS (Electronic Materials Information Service'—информаци¬
онная служба по электронным материалам) предназначена для
публикации работ, необходимых ученым и инженерам, занятым
разработкой или использованием твердотельных электронных ма¬
териалов и др.
Анализ выборки из 118 «электронных» изданий по естествен¬
ным наукам и технике [12] показывает, что в таких БД сосредо¬
точивается информация в основном начиная с 1982 г. (табл. 2).
Как видно из рис. 1, количество небиблиографических БД
с 1978 г. превысило количество библиографических БД. Особенно
быстро их число растет в таких областях, как экономика, право
(табл. 3), а также в метеорологии, сейсмологии, океанографии,
аэрокосмических исследованиях и в системах, обеспечивающих
пользователей справочными и стандартными данными по вещест¬
вам, материалам, физическим и химическим константам и спра¬
вочными данными по различным видам продукции и т. д. По оцен¬
ке [18] к 1985 г. библиографическая информация составляла лишь
около 10% общего объема данных, накопленных в БД.
Таблица 3
Структура БД по видам информации [17]
Область знаний
Базы данных
небиблиографические
библиогра¬
фические
числовые
справочные
полнотекстовые
Естественные науки и тех¬
ника
78
24
154
Общественные и гуманитар¬
ные науки
21
16
98
Бизнес, экономика и право
328
26
76
81
Междисциплинарные
—
41
—
—
Всего
427
107
76
331
в %
45,4
11,4
8,1
35,1
Следует обратить внимание на тот факт, что в одной БД стали
объединять различные виды информационных ресурсов (библио¬
графические, справочные, текстовые, числовые, текстово-числовые
и программные средства). Например, анализ выборки из 1629 БД,
взятых из справочника за 1986 г. [11] (табл. 4), показывает:
10
Таблица 4
Структура БД по видам информационных ресурсов
Тип БД
Количество
БД
Относительная
частота
Библиографические (Б)
412
0,2529
Справочные (С)
212
0,1301
Числовые (Ч)
382
0,2345
Текстово-числовые (ТЧ)
148
0,0909
Текстовые (Т)
255
0,1565
Программных средств (ПС)
—
—
Смешанные:
Б+С+Ч+ТЧ+Т
1
0,0006
с+ч+тч+т
1
0,0006
С+Ч + Т
2
0,0012
С
+ ТЧ + Т
1
0,0006
ч-ьтч+т
2
0,0012
Б + С
+тч
2
0,0012
Б
+ТЧ + Т
1
0,0006
Б + С
+т
4
0,0025
Б
+т
42
0,0258
Б
+ ТЧ
17
0,0104
Б + С
29
0,0178
С + Ч
1
0,0006
С
+ ТЧ
17
0,0104
С
+т
49
0,0301
ч+тч
8
0,0049
ч +т
16
0,0098
тч+т
16
0,0098
Б+С
+ Т+ПС
1
0,0006
С
+ Т+ПС
1
0,0006
С
+ ПС
3
0,0018
т+пс
6
0,0037
В с е г
о смешанных
220
0,1351
Всего
1629
1,0000
почти 75% БД содержит в своем составе небиблиографичес¬
кие информационные ресурсы, в том числе 220 БД (около 13%)
от 2 до 5 видов информационных ресурсов;
существенно (почти до 50%) возросло число БД, включающих
в свой состав тексты и текстово-числовые данные;
число БД, содержащих только библиографическую информа¬
цию, снизилось до 25%.
Следовательно, важнейшей тенденцией развития современных
информационных технологий является создание национальных ма¬
шиночитаемых ресурсов, что отражено и в прогнозных оценках
сроков переноса различных видов информации на машиночитае¬
мые носители (см. рис. 2).
Если учесть, что на машиночитаемые носители в первую оче¬
редь переносятся информационные ресурсы в приоритетных облас¬
тях науки и техники, то отсутствие доступа пользователей (от¬
дельных лиц, коллективов, ведомств, стран и групп стран) к кон¬
кретным машиночитаемым ресурсам приводит к существенному
11
снижению возможностей интенсификации научных, проектных и
производственных процессов. По этой причине уже сейчас значи¬
тельное число пользователей фактически исключено из полноцен¬
ного информационного обслуживания. Все это ведет к принципи¬
альным изменениям всей структуры информационной деятельнос¬
ти, так как администраторы баз данных могут осуществлять для
конкретных групп пользователей строго регламентированные стра¬
тегии информирования и дезинформирования. Такая ситуация при¬
ведет к тому, что в ближайшей перспективе (5—10 лет) резко воз¬
растет зависимость эффективности решения научных, технических
и народнохозяйственных задач от наличия национального маши¬
ночитаемого информационного ресурса и возможностей использо¬
вания машиночитаемых информационных ресурсов других стран.
Далее, опыт функционирования машиночитаемых информаци¬
онных ресурсов свидетельствует о том, что период их «жизненного
цикла» существенно превосходит периоды «жизненного цикла»
конкретного технического устройства, программного средства, по¬
коления ЭВМ (иллюстрацией этого положения являются данные
о ретроспективе фондов, приведенные в табл. 1). Изменение тех¬
нической и программной конфигурации автоматизированных ин¬
формационных систем порождает проблему непрерывного конвер¬
тирования информационных массивов, что по мере увеличения их
объема становится все более дорогостоящей процедурой, с другой
стороны, создает условия безвозвратной утраты тех или иных ре¬
сурсов в результате неадекватных процессов преобразования ин¬
формации и (или) утраты связей массивов с программной и тех¬
нической средой, обеспечивающих их целостность и обработку, и
(или) утраты массивов и (или) программных средств, обеспечи¬
вающих идентификацию и однозначное декодирование данных
и т. п.
Существенным фактором, снижающим эффективность исполь¬
зования машиночитаемых ресурсов при решении комплексных за¬
дач, является их несовместимость, вызываемая бессистемным и
нерегламентированным использованием для их создания избыточ¬
но разнородного комплекса технических и программных средств
(особенно зарубежных, которые порождают, как правило, лати¬
низированные суррогаты псевдорусских текстов). А само созда¬
ние таких массивов ведется при неоправданно высоких затратах
труда высококвалифицированных специалистов на дублирование
разработок однотипных программных средств и технической до¬
кументации, а также на последующее поддержание этих средств
в эксплуатационном режиме. В свою очередь разнобой в методах
представления информации на машиночитаемых носителях и, как
следствие, неоправданное многообразие программных и техниче¬
ских средств для работы с ними фактически исключают эффектив¬
ную организацию национального машиночитаемого информаци¬
онного ресурса, а также организацию его длительного депозитар¬
ного и архивного хранения.
В этих условиях необходима разработка концепции создания
12
национального информационного ресурса и создания нормативной
базы, обеспечивающей стандартизацию представления всех видов
информационных документов на машиночитаемых носителях
(прежде всего перспективных). В основу этой концепции целесо¬
образно включить следующие положения.
1. Абсолютная преемственность ранее накопленных массивов
машиночитаемых информационных ресурсов новыми моделями
технических средств и новыми версиями программных средств.
2. Основой формирования национальных информационных ре¬
сурсов должна стать система стандартных коммуникативных фор¬
матов, обеспечивающая единство представления всех видов инфор¬
мационных ресурсов на машиночитаемых носителях и стандартный
комплекс программных средств, обеспечивающих их формирова¬
ние и комплексную обработку.
3. Все вновь создаваемые технические средства должны фор¬
мировать и обеспечивать обработку информационных ресурсов,
представленных в коммуникативных форматах. В противном слу¬
чае их использование в информационных системах должно быть
запрещено.
4. Зарубежные технические средства, не обеспечивающие об¬
работку информационных ресурсов в отечественных коммуника¬
тивных форматах, должны быть запрещены для использования
в автоматизированных системах.
5. На депозитарное и архивное хранение машиночитаемые ин¬
формационные ресурсы должны поступать только в коммуника¬
тивных форматах с комплексом программных средств, обеспечи¬
вающих их обработку.
6. Создание, тиражирование, распределение, контроль за ис¬
пользованием, сохранностью и качеством (точностью, достовер¬
ностью и актуальностью) национальных информационных маши¬
ночитаемых ресурсов, а также управление их развитием должны
осуществляться в рамках единой организационной структуры, ох¬
ватывающей всю систему источников машиночитаемых информа¬
ционных ресурсов и пользователей.
7. Машиночитаемые информационные ресурсы в коммуникатив¬
ных форматах должны рассматриваться в качестве исходной стан¬
дартной структуры для всех разработок базового программного
обеспечения. Системы программного обеспечения, не способные
воспринимать и обрабатывать такие информационные ресурсы,
должны быть запрещены для использования.
Разработка стандартов, определяющих требования к машино¬
читаемым информационным ресурсам всех видов и программным
средствам по их обработке, должна вестись в рамках «Системы
стандартов по информации, библиотечному и издательскому де¬
лу» (СИБИД). При разработке стандартов, определяющих созда¬
ние национального машиночитаемого информационного ресурса,
следует избегать прямого заимствования международных стандар¬
тов, так как они не учитывают особенностей представления тек¬
стовой информации, принятых в нашей стране, что может привес¬
13
ти и уже приводит к существенным трудностям при их обработке.
А так как все большее количество различных видов информацион¬
ных ресурсов переносится на машиночитаемые носители, то требо¬
вания этих стандартов должны быть распространены на все виды
систем документации (УСД, ЕСКД, ЕСТД и т. д.) и «электрон¬
ных изданий». Контроль за созданием и сохранностью националь¬
ного машиночитаемого информационного ресурса должен быть
возложен, по нашему мнению, на Государственный комитет СССР
по вычислительной технике и информатике, Госкомиздат и Глав¬
ное архивное управление СССР.
Дальнейшее промедление с принятием концепции и программы
создания и сохранения национальных информационных ресурсов
может привести к невосполнимым утратам информационных ре¬
сурсов и не позволит осуществлять намеченные мероприятия по
ускорению научно-технического прогресса.
ЛИТЕРАТУРА
1. Материалы XXVII съезда Коммунистической партии Советского Союза.—
М.: Политиздат, 1986.— С. 121—187, 267—335.
2. Комплексная программа научно-технического прогресса стран — членов СЭВ
до 2000 года//Правда. — 1985. — 12 дек.
3. Патон Б. Безопасность прогресса//НТР, проблемы и решения.— 1986.—
№ 19 (34).
4. Каршунин М., Вчерашний Р. Информация о машинах, которых еще нет//
НТР, проблемы и решения.— 1986. — № 10 (25).
5. Органы научно-технической информации СССР.: Справочник. — Изд. 2-е. —
М.: ВИНИТИ, 1986. —С. 226.
6. Государственная ордена Ленина Библиотека СССР им. Ленина: Памятка
читателю. — М., 1985.'—55 с.
7. Каталог баз данных на магнитных лентах, распространяемых органами на¬
учно-технической информации в ГСНТИ. — Изд. 2-е. — М.: ВИНИТИ, 1983.
8. Эдельгацз Г. Е. Достоверность статистических показателей. — М.: Статисти¬
ка, 1977.
9. Горностаев Ю. М., Сосин Е. В., Сумароков Л. Н. Информационно-поиско¬
вые системы и межмашинный обмен информацией (анализ развития). — М.:
Информэлектро, 1975.
10. Aitchison Т. М. Ап analysis of the Present European situation Aslib Pro¬
ceedings, 32 (Suplement). — 1980, January.— P. 6—17.
11. Directory of online Databases. — 1986, January. — Vol. 7. — № 1. — Cuarda/
Elsevier, —ISSN 0193—6840.
12. Williams M. E. Computer Readable Databases.— Inc. 1985. — ISBN
0—444—87613—8,0—444—87614-4.
13. Экспресс-информация. — M.: ВНИТИ, 1980. — № 21. — С. 1—2.— (Сер. «Ин¬
форматика») .
14. Экспресс-информация. — M.: ВИНИТИ, 1979. — № 3. — С. 4—7.— (Сер.
«Информатика»).
15. Vickery В., Heseltine R. and Brown С. Interractive information networks and
UK libraries. — I. of Docum., 1984, III, 40. — № 1. —P. 36—49.
16. Online Bibliographic Database: An International Directory, Second Edition.—
Aslib, 1981. —213 p.
14
17. Экспресс-информация. — М.: ВИНИТИ, 1986. — № 27.— С. 8—11.— (Сер.
«Информатика»).
18. Экспресс-информация. — М.: ВИНИТИ, 1986. — № 10,— С. 9—12.— (Сер.
«Информатика»).
29. Williams М. Е. Database and online statistics for 1979. — Bull. ASIS, 1980.—
№ 1. — P. 27—29.
20. Экспресс-информация. — M.: ВИНИТИ, 1980. — № 1. — C. 7—15.— (Cep.
«Информатика»).
21. Экспресс-информация. — Мл ВИНИТИ, 1986. — № 42. — С. 5—7.— (Сер.
«Информатика»).
22. Рж. 59 «Информатика», 5И 329. —М.: ВИНИТИ, 1986.
23. Бабич Г. «Безбумажная» заявка и промышленный шпионаж//Изобретатель
и рационализатор. — 1986. — № 5. — С. 31.
2. ПРОГРАММНЫЕ СРЕДСТВА
И МАТЕМАТИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ
УДК 681.3.06.002
ИНСТРУМЕНТАРИИ МАШИННОЙ ПОДДЕРЖКИ
ЦИКЛА ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
(ОБЗОР ЗАПАДНЫХ СРЕДСТВ)
И. л. МЕЛЬНИКОВ, А. С. РААБЕ, Б. Г. ТАММ
Введение
В конце шестидесятых годов за рубежом появился новый тип
программного обеспечения (ПО), предназначенный для машинной
поддержки процессов разработки ПО. Сюда относились, напри¬
мер, системы TOPD, CADES и CASCADE [1], эксплуатацию ко¬
торых начали в начале семидесятых годов. Эти системы были ори¬
ентированы на структурную разработку ПО и позволили автома¬
тизировать с помощью ЭВМ этапы проектирования, конструиро¬
вания и отладки программ. В это же время появились и библио¬
теки поддержки проектов [1], которые автоматизировали сохра¬
нение и документирование проекта. К настоящему времени коли¬
чество аналогичных разработок резко возросло, и, например, в ба¬
зе данных национального бюро стандартов [2] США содержится
описание 362 различных средств.
Аналогичные тенденции развития ПО такого типа можно про¬
следить также в нашей стране и в странах — членах СЭВ; по со¬
стоянию и составу такого ПО имеется довольно много публика¬
ций [3—6].
В настоящей статье в центре внимания находятся западные
средства поддержки цикла жизни ПО. Большое разнообразие та¬
ких средств не позволяет привести здесь их исчерпывающий об¬
зор. Поэтому основное внимание мы уделим средствам машинной
поддержки общего назначения, имеющим широкую область при¬
менения.
Обзор и анализ средств машинной поддержки цикла жизни
ПО можно сделать с точки зрения пользователя или разработчи¬
ка. В центре внимания нашего обзора находятся вопросы функ¬
ционального состава, построения и реализации таких средств, т. е.
в основном учтены интересы разработчиков. Представляемый в
обзоре материал собран нами из научных источников информа¬
ции. Вследствие этого в обзор не попало множество средств, по¬
ставляемых на рынок ПО, но имеющих описания рекламного ха¬
рактера.
16
Большие трудности у нас возникали в связи с использованием
терминов при изложении материала и с классификацией средств
машинной поддержки ПО. Употребление того или иного термина
для описания средств поддержки сильно зависит от контекста. На¬
пример, для понятия «цикл жизни ПО» мы нашли 7 различных
истолкований, возможные понимания терминов «спецификация» и
«требования» обсуждаются в [8]. О различных подходах к клас¬
сификации средств поддержки цикла жизни ПО можно узнать из
обзорных статей [7—10]. Опираясь на данные в них рекомендации
и на идеи, излагаемые в [11]. мы будем использовать следующую
терминологию и классификацию.
Средой поддержки цикла жизни ПО называем совокупность
инструментов, имеющих технологию и организацию использования
и обеспечивающих достижение целей машинной поддержки для
различных фаз развития ПО. Целями поддержки могут быть ав¬
томатизация труда по созданию и эксплуатации ПО, повышение
продуктивности разработчиков и качества ПО, обеспечение его
живучести и развития. Цикл жизни ПО понимается нами как пе¬
риод времени, в течение которого выполняются работы, обеспечи¬
вающие достижение целей поддержки. Начало этого периода свя¬
зывается с постановкой задачи для создания ПО, а конец — с за¬
вершением эксплуатации ПО. Технология при этом является пред¬
писанием для организации использования знаний и инструментов
для обеспечения этих целей. Организация представляет собой си¬
стему распределения труда между людьми применительно к от¬
дельным фазам развития ПО и используемым инструментам, а
также планирования и контроля работ и управления ими. Под
инструментом мы будем понимать лингвистическое, графическое,
информационное или программное обеспечение, предназначенное
для исполнения конкретной работы поддержки на ЭВМ, а под
фазами развития — выделенные в технологии совокупности свя¬
занных между собой работ. Такие среды, которые обеспечивают
отдельные фазы развития цикла жизни, будут называться окру¬
жениями. Термин «окружение» при этом будет иметь дополнение,
характеризующее поддерживаемую фазу развития. По количеству
пользователей будем делить среды (и окружения) на производст¬
венные, лабораторные и персональные. Производственную среду
используют одно или несколько предприятий, в то время как ла¬
бораторная среда предназначена для одной или нескольких групп
пользователей, а персональная — для одного человека.
В следующих разделах работы будут рассмотрены отдельно
инструменты, окружения и среды, приведена их классификация,
проанализированы способы построения и применение средств.
Инструменты поддержки
Инструменты поддержки (ИП) предназначены для машинного
выполнения отдельных работ в цикле жизни ПО. Они могут быть
самостоятельными либо входить в состав окружения или среды
2 Заказ 5620
17
поддержки. Любой ИП характеризуется материалом, подлежащим
обработке с его помощью, программно реализуемыми функциями,
обеспечивающими выполнение работы, и продуктом, получающим¬
ся после обработки исходного материала. Как правило, инстру¬
менты используются в интерактивном режиме. Далее рассматрива¬
ются классы отдельных инструментов. Для определения каждого
из этих классов мы старались подобрать слова, указывающие на
назначение рассматриваемого инструмента.
Редакторы предназначены для обработки текстового материа¬
ла. Продуктом их работы является обработанный с учетом поже¬
ланий пользователя текст. Редакторы позволяют разделять текст
на части, соединять части текста в одно целое, заменять части
текста другим текстом, производить поиск текста по известным
признакам, а также передвижение по структурированным частям
текста. Редакторы разделяются на строковые, синтаксически- и
знание-ориентированные.
Строковые редакторы [12] позволяют обрабатывать любые
последовательности символов в виде строк.
Синтаксически-ориентированные редакторы [13] обрабатывают
тексты на основе анализа их синтаксической структуры. В зависи¬
мости от своего построения эти редакторы могут обрабатывать
тексты только одного конкретного языка или нескольких языков.
Во втором случае комплект синтаксических правил может быть за¬
меняемым или же редактор имеет возможность генерировать но¬
вый редактор на базе описания синтаксиса. Синтаксически-ориен¬
тированные редакторы часто реализуются с помощью систем по¬
строения трансляторов, которые приспособлены для получения ре¬
дакторов. Кроме уже названных операций обработки текстов, син¬
таксически-ориентированные редакторы позволяют проверять со¬
ответствие текстового материала синтаксису языка. Эти редакто¬
ры различаются по способам хранения текстов. Одни сохраняют
тексты в виде строк, другие как синтаксические деревья, получен¬
ные после синтаксического разбора. Последние редакторы имеют
дополнительные функции обработки этих деревьев. Существуют
редакторы, позволяющие по желанию пользователя перейти от
одной формы представления текста к другой.
В знание-ориентированных редакторах [14], кроме синтакси¬
ческих правил, представляются знания о программах, например,
в виде планов и клише, описывающих общую алгоритмическую
структуру программы. При этом клише (внешняя форма представ¬
ления знаний) и планы (внутренняя форма представления зна¬
ний) во многом похожи на фреймы. Клише содержит описание тех
частей программы, которые могут варьироваться, а также прави¬
ла объединения программы. Редактор позволяет автоматически
комбинировать различные клише для получения более сложных
программ. Он имеет блок генерации, позволяющий генерировать
на основе скомбинированных клише конкретную программу на
языке программирования. Редакторы этого типа пока известны
как научно-экспериментальные и находятся в стадии развития, но
18
представляют собой одно из перспективных направлений создания
редакторов будущего.
Оценивая количество редакторов среди других инструментов,
можно заметить их значительный удельный вес. Это объясняется,
по-видимому, большой трудоемкостью обработки текстов, а также
долговременным опытом создания этих средств.
Компиляторы являются одними из старейших инструментов
программирования и применяются для трансляции языков про¬
граммирования. Чаще всего используются традиционные компиля¬
торы, входящие в состав операционных систем. В некоторых слу¬
чаях применяются компиляторы, позволяющие произвести сепа¬
ратную или инкрементальную компиляцию. При сепаратной ком¬
пиляции [15] программные единицы могут транслироваться от¬
дельно. При инкрементальной компиляции [16] появляется воз¬
можность слить уже скомпилированную программную единицу с
некомпилированной. Использование этих видов компиляции по¬
зволяет сократить время компиляции, организовать гибкую техно¬
логию создания ПО и также получить значительный эффект при
реализации ПО большого объема.
Анализаторы предназначены для анализа ПО и связанных с
ним текстов. В результате своей работы они выдают отчеты, ко¬
торые могут иметь заранее фиксированный формат или генериро¬
ваться по запросу пользователя. По таким отчетам легче нахо¬
дить ошибки и контролировать качество ПО. Анализаторы можно
разделить на два типа. Одни предназначены для анализа стати¬
ческих, а другие — динамических характеристик.
Анализаторы статики (АС) [17] позволяют определить харак¬
теристики текстов, связанных с ПО (тексты программ, проектов,
требований и спецификаций ПО). С помощью этих анализаторов
можно, например, обнаружить противоречия при использовании
данных (использование неопределенных данных, несогласован¬
ность передачи данных, потери данных) и структур управления
(участки программ, не получившие управления, тупиковые ситу¬
ации, бесконечные циклы), а также вывести характеристики струк¬
туры (граф управления и его различные ветви, граф передачи
данных, таблицы перекрестных ссылок, отчет составных частей
структуры). АС измеряют различные количественные показатели,
используя, например, метрики по Холстеду или Макабе.
Анализаторы динамики (АД) [18] применяются для выявле¬
ния характеристик ПО в процессе выполнения программ. Они про¬
изводят трассировку изменения данных и передачи управления,
измеряют различные частотные характеристики и степень исполь¬
зуемости частей Г1О в ходе выполнения. При этом пользователь
может управлять квантом времени, через который производятся
измерения. Для реализации АД используют два способа. При пер¬
вом способе создается специальный интерпретатор, под контролем
которого выполняются программы и собираются характеристики
ПО. По второму способу текст, соответствующий Г1О, изменяется
таким образом, чтобы включить датчики, выдающие характеристи¬
2*
19
ки ПО. Средство исполнения текста при этом остается неизмен¬
ным.
Верификаторы предназначены для определения правильности
ПО и связанных с ним текстов. Если ранее под понятием верифи¬
кации подразумевали только методы формального доказательства
правильности ПО, то теперь многие авторы этим термином охва¬
тывают и неформальные методы установления правильности. Мы
уделили основное внимание верификаторам, использующим фор¬
мальные методы проверки. Объектом верификации могут быть
требования и спецификации, на которых основываются разработ¬
чики ПО, структуры данных и структуры управления, тексты го¬
тового ПО. Правильность этих объектов определяется по двум
критериям. Во-первых, нужно установить пригодность ПО для
решения задач, применительно к которым оно разработано. Это
делается, как правило, неформальными методами и в основном с
использованием анализаторов. Во-вторых, нужно установить, со¬
ответствует ли объект, подлежащий верификации, желаемому.
Имея в виду этот критерий, верификаторы можно разделить на
две группы.
Одну составляют верификаторы [19], которые проверяют про¬
цесс разработки ПО. Как правило, они работают в интерактивном
режиме и используют в процессе создания объектов трансформа¬
ционные методы. При этом достаточно только один раз верифици¬
ровать правильность трансформирующего правила, а потом мож¬
но использовать его многократно для описания различных объ¬
ектов. Таким образом сокращается объем работ при верифи¬
кации.
В другую группу входят верификаторы [20], проверяющие
правильность готового объекта. В этом случае пользователь дол¬
жен снабдить верифицируемый объект спецификациями, которые
описывают пожелания создателя объекта. На основе этой допол¬
нительной информации и описания готового объекта верификатор
может установить соответствие полученного объекта желаемому.
Как правило, за основу при реализации этих верификаторов при¬
нимается один из ранее описанных формальных методов верифи¬
кации [21]. При этом для верификации структур данных приме¬
няются алгебраические, а для алгоритмов — аксиоматические ме¬
тоды верификации. К этой группе верификаторов можно отнести
и так называемые генераторы условий, которые составляют логи¬
ческие выражения, инвариантные поведению объектов. Если та¬
кое логическое описание объекта существует, то доказательство
утверждений является уже «делом техники» и может быть найдено
самим пользователем генератора или с помощью специально со¬
зданной для этой цели программы.
Корректоры [22] предназначены для автоматического исправ¬
ления ошибок человека при записи текстов программ. Корректор
исправляет опечатки, уменьшает объем программы за счет ненуж¬
ных ее частей, устраняет противоречия в программе (исправляет
имена переменных, нарушение правил передачи данных и т. д.).
20
Пользователь корректора может вводить исправления в програм¬
му временно, что облегчает процесс отладки.
Обучатели предназначены для автоматизации процесса усвое¬
ния ПО и обучения пользованию им. Их можно разделить натри
группы. К первой относятся обучатели [23], имитирующие про¬
цесс лекционного обучения. В памяти такого обучателя содержат¬
ся лекционный материал, описания контрольных задач и план обу¬
чения. Пользователь должен согласно плану обучения познако¬
миться с учебным материалом, а затем ответить на контрольные
вопросы или решить задачи. На основе ответов пользователя обу-
чатель выставляет оценки. Эти обучатели имеют средства для за¬
писи новых курсов, анализирования ответов и выставления оценки.
Вторую группу составляют обучатели [24], где поддерживается
процесс самообучения (тренировки) пользователя. После того как
пользователь усвоил минимальные знания о языке программиро¬
вания, он может составить программу и с помощью обучателя ис¬
следовать ее для лучшего усвоения семантики языка программи¬
рования.
Третья группа — это обучатели [25], построенные на основе
знаний об изучаемом материале и пользователе. В базе знаний
сохраняется модель, описывающая пользовательские знания. Обу¬
чение ведется адаптивно, с учетом результатов работы пользова¬
теля. При этом обучаемый решает свои задачи без вмешательства
обучателя до тех пор, пока результаты перестанут удовлетворять
обучателя. Тогда он представляет материал, позволяющий обучае¬
мому расширить свои знания или выполнить заданную работу бо¬
лее качественно. Эта группа только начинает развиваться, и из¬
вестный нам обучатель такого типа применяется для обучения спо¬
собам редактирования текстов.
Информаторы предназначены для обмена информацией между
членами организации, и по способу передачи информации их мож¬
но разделить на две группы.
Первую группу составляют информаторы [26], где поток и со¬
держание передаваемой информации со стороны информатора не
ограничиваются. В этих информаторах имитируется почтовая служ¬
ба. Каждый член организации имеет свой почтовый ящик, куда
другие члены могут направлять свои сообщения.
Во вторую группу входят информаторы [27], которые распо¬
лагают специальной базой данных, способной отражать структуру
организации, работающей в среде. Там содержатся, например, ка¬
лендарные планы, описания и указания по выполнению работ в
соответствии с их исполнителями. К этой базе данных можно об¬
ращаться с запросами для получения информации или же исходя
из содержащейся в ней информации членам организации автома¬
тически передаются сообщения, например, о сроках выполнения
работ согласно календарному плану. Аналогичная база данных
может быть организована как имитация записной книжки, где
члены организации могут оставлять свои заметки (с соблюдением
определенного формата), что обеспечивает общение членов орга¬
21
низации. В виде таких заметок можно оформить также протоко¬
лы совещаний членов организации.
Интерпретаторы предназначены для выполнения программ и
могут быть разделены на три группы. Первую группу [28] состав¬
ляют традиционные интерпретаторы, производящие трансляцию
и выполнение текстов на языке программирования. Некоторые ин¬
терпретаторы этой группы способны запоминать историю интер¬
претации, аннулировать события в этой истории и начинать новое
выполнение программы, а также визуализировать процесс интер¬
претации. Интерпретаторы второй группы [29] позволяют интер¬
претировать ПО, представленное в специальной форме, например,
схемами. С помощью третьей группы интерпретаторов [30] можно
тексты на языках программирования выполнять в символьном
виде.
Генераторы служат для генерации ПО по описаниям процесса
генерации и могут быть универсальными [31] или специализиро¬
ванными. Универсальные генераторы не имеют ограничений на
тип ПО, а специализированные генерируют ПО одного типа. К спе¬
циализированным относятся, например, генераторы редакторов
[32], спецификаторов [33], интерпретаторов [34] или интерфей¬
сов [35]. При описании процесса генерации используются макро¬
сы или специальные, зависящие от генераторов, трансформирую¬
щие правила.
Синтезаторы на основе математического анализа формальных
утверждений о выполняемых функциях программы выводят ее
текст на языке программирования. Исходя из применяемых мето¬
дов синтеза их можно разделить на три класса. Для дедуктивных
синтезаторов [36] требуется формальное описание предметной об¬
ласти, на основе которого после доказательства теоремы о сущест¬
вовании алгоритма решения задачи генерируется текст соответст¬
вующей программы. Индуктивные синтезаторы [37] строят текст
программы по примерам решения конкретных задач. Трансформа¬
тивные синтезаторы [38] на базе трансформирующих правил пре¬
образуют спецификацию функции программы в примитивные
функции, имеющие эквивалент на языке программирования. Часто
при этом используется алгебраическая спецификация программы,
построение которой базируется на абстрактных типах данных.
Интерфейсы предназначены для реализации общения между
пользователем и ПО. Каждый интерфейс характеризуется спосо¬
бом ведения диалога и возможностями управления им. Интерфейс
может реализовать диалог на базе языка, меню, форм, окон или
машинной графики. Во многих случаях эти способы используются
смешанно. Как правило, в интерфейс входит манипулятор, позво¬
ляющий управлять ходом диалога, протоколировать, запоминать и
проверять измененные сеансы связи. Ход диалога может быть за¬
дан специальной диаграммой состояний диалога. Интерфейсы бы¬
вают встроенные [39] или универсальные [40], т. е. используемые
самостоятельно. Встроенные относятся к конкретной среде или
окружению, а с помощью универсальных можно обеспечивать
22
связь между различными компонентами ПО. Универсальность мо¬
жет достигаться путем генерирования нового интерфейса по пра¬
вилам, задаваемым разработчиком, или использования определен¬
ного стандарта протокола.
Если в интерфейсе для общения используется язык, то обычно
это командный язык. Известны, правда, попытки применить под¬
множества естественного языка.
Интерфейсы, построенные на «меню», могут быть статически¬
ми или динамическими. Динамика изменения «меню» отражает,
например, допустимые или недопустимые действия, время и место
появления «меню» в ходе диалога. Меню могут быть многоуровне¬
выми. В таком случае манипулятор «меню» позволяет перейти
с одного уровня на другой.
Форма как интерфейс представляет собой жесткий формат
экрана, состоящий из полей для ввода-вывода данных и для по¬
ясняющей информации. Формы создаются с помощью генератора,
а их применение обеспечивает специальный манипулятор.
Окно представляет собой для пользователя виртуальный экран,
который на физическом экране может перекрываться. Окна могут
быть организованы многоуровневыми структурами. В этом случае
при переходе от одного окна к другому на экране помечаются не¬
активные окна. Специальный манипулятор позволяет управлять
местонахождением окон на физическом экране и связывать окна
с программным обеспечением.
Машинная графика используется для визуализации функцио¬
нальной структуры ПО, процессов его выполнения, протоколов
сеанса работы. Функциональная структура описывается, напри¬
мер, схемами Джексона или Насси — Шнейдермана. При визуали¬
зации процессов выполнения показываются координаты исполняе¬
мой части схемы, а после прохождения этой части она перекра¬
шивается в другой цвет. Машинная графика используется также
для визуализации текстовых описаний ПО и его проектов (напри¬
мер, в виде SADT — диаграмм или структурных схем).
Системы управления базами данных (СУБД) используются в
основном для хранения проектов создания ПО, управления и кон¬
троля за версиями и конфигурациями ПО, для реализации инфор¬
мационной связи между отдельными инструментами, входящими
в состав среды или окружения. Используемые СУБД можно раз¬
делить на три группы.
К первой группе отнесем универсальные СУБД, созданные для
реализации систем обработки данных и доступные на рынке ПО.
Спектр этих СУБД довольно широкий, прежде всего это системы,
базирующиеся на известных моделях данных: реляционной,
КОДАСИЛ и иерархической. Из реляционных СУБД наиболее
популярна INGRES, а из СУБД типа КОДАСИЛ — соответствую¬
щий компонент из ISDOS [18].
Во вторую группу [41] можно объединить специальные над¬
стройки над файлами операционных систем, имеющие аналогии-
23
ные с СУБД функции и применяющиеся для реализации управле¬
ния и контроля за версиями и конфигурацией ПО.
Третья группа — это самодельные СУБД [19], ориентированные
на структуру и функции среды или окружения, в состав которых
данная СУБД входит. Как правило, эти СУБД не являются само¬
стоятельными инструментами и могут применяться только внутри
среды или окружения.
Менеджеры [18,39,42] предназначены для управления дея¬
тельностью организации, ее контроля и планирования. Эти инст¬
рументы существуют только в производственных средах. Менед¬
жеры позволяют составлять планы распределения рабочей силы
и ресурсов, производить финансовые вычисления, использовать
для управления и контроля отчеты о состоянии проекта. При со¬
ставлении планов учитываются время и стоимость работ. С по¬
мощью менеджера можно регулировать процесс проектирования,
т. е. вводить изменения в планы и анализировать влияние этих
изменений.
Документаторы предназначены для выдачи документации ПО.
В роли документатора могут выступать также некоторые другие
инструменты (например, анализаторы, информаторы, специфика¬
торы), которые оформляют отчеты как документы. Состав выда¬
ваемой документации зависит от ее стандарта, и поэтому обычно
он разный для различных документаторов. Документаторы мо-;
гут быть текстовыми или графическими.
Первые выдают документ в виде текста [39]. По способу полу¬
чения документа их можно разделить на три группы. Одну группу
составляют документаторы, в которых о каждом объекте для
оформления на него документа сообщается дополнительная ин¬
формация. Документатор может собрать такую информацию для
многих объектов и выдать составной документ. Такой способ на¬
зывается самодокументированием. Вторую группу образуют доку¬
ментаторы [42], которые генерируют документы автоматически из
исходного текста (например, из текстов программ). Как указыва¬
ется в [43], этот способ не удовлетворяет пользователей, посколь¬
ку такие документы плохо читаемы. В документаторах третьей
группы [44] используется специальный язык, на котором описы¬
вается формат и содержание документа.
Графические документаторы [45]- выдают документы в виде
различных изображений, оформленных, например, как структур¬
ные схемы (схемы Джексона, Насси — Шнейдермана, блок-схемы
программ и т. д.) графиков, диаграмм.
Спецификаторы предназначены для описания ПО в виде де¬
клараций, которые бывают двух типов: требования и специфика¬
ции. Требование — это декларация, описывающая свойство ПО,
требуемое для решения проблемы или достижения цели. Специ¬
фикацией является декларация на формальном языке, описываю¬
щая внешние характеристики поведения ПО. Спецификаторы при¬
водят описания ПО в форму, которая подходит для сохранения в
24
базе данных и допускает дальнейшую обработку верификаторами,
анализаторами или синтезаторами.
Спецификаторы по способу описания требований можно разде¬
лить на две группы: одни используют для задания неформальный
[18], а другие — формальный язык спецификации [19]. В обоих
случаях текст на языке описания требований должен допускать
машинный анализ и обработку. При формальном описании ис¬
пользуется, например, формализм, похожий на сети Петри, или
задаются параметры и компоненты абстрактной структурной мо¬
дели ПО. При неформальном определении требований использу¬
ется ограниченный естественный язык. Для достижения машинной
обрабатываемости в этом случае вводятся, например, ограничения
на структуру и компонентный состав предложения или ключевые
слова, смысл которых заранее фиксирован.
Спецификации, описывающие поведение создаваемого ПО,
можно разделить на системные и программные. При этом систем¬
ные спецификации задают полную систему ПО, а программные —
только компоненты этой системы: модули, типы данных, алгорит¬
мы. Обычно системные спецификации разрабатываются после оп¬
ределения требований. Каждая спецификация должна быть понят¬
ной, тестируемой и легко изменяемой. В зависимости от исполь¬
зуемого языка спецификаторы можно разделить на три группы.
Первую составляют спецификаторы [46], использующие специ¬
ально созданные языки высокого уровня, позволяющие описывать,
например, типы данных, абстрактные действия и функциональную
структуру компонентов ПО, предикаты для выражения условий
и т. д. Такие языки могут создаваться с помощью специального
генератора, для которого описывается синтаксис и семантика язы¬
ка спецификации. Вторую группу [47] образуют спецификаторы,
ориентированные на некоторый формальный способ задания спе¬
цификации. Как правило, для задания системных спецификаций
часто используются методы, базирующиеся на сети переходов си¬
стемы из одного состояния в другое. Существуют спецификаторы,
которые позволяют специфицировать систему ПО в терминах не¬
которой ее абстрактной модели. Для ведения программных специ¬
фикаций используются аксиоматические или алгебраические мето¬
ды, базирующиеся на теории абстрактных типов данных или фор¬
мальной семантике языков программирования. В третью группу
входят спецификаторы [18], использующие известные языки про¬
граммирования, например, ADA и PROLOG.
Отладчики предназначены для локализации ошибок ПО, вы¬
явления их причин и помогают принять решения для их устране¬
ния. Для достижения этих целей отладчики позволяют получать
информацию о процессе выполнения программы (управление
трассировкой значений переменных и операторов), изменять зна¬
чения переменных, последовательность или состав операторов,
Прерывать процесс выполнения ПО, указывая точки или условия
Прерывания. Отладчики принадлежат к наиболее ранним из рас¬
смотренных инструментов.
25
Окружения поддержки
Окружения поддержки дают машинную поддержку для выпол¬
нения работ во время одной фазы развития ПО. Каждое окруже¬
ние состоит из нескольких инструментов, позволяющих автомати¬
зировать работы определенной фазы. Среди окружений можно
выделить окружения для: спецификации, проектирования, прог¬
раммирования, тестирования, сопровождения и макетирования.
Если первые отладчики работали на машинном уровне, то на
сегодняшний день их можно использовать на уровне одного или
нескольких языков программирования. Для реализации отладки
на уровне языка программирования используются в основном два
способа. Согласно первому отладчик реализуется как интерпре¬
татор исходного языка [48], расширенный функциями отладки.
Второй способ [49]- состоит в совместном использовании текста
на исходном языке программы, выданных компилятором таблиц
символов и текста программы на уровне ее выполнения. При та¬
ком способе на ЭВМ предусматриваются специальные система
прерывания и команды. Для подключения отладчиков к отлажи¬
ваемому ПО используются два подхода. Первый состоит в том,
что ПО полностью подчиняется отладчику, для достижения чего
оно соответственно изменяется перед отладкой или в процессе
отладки. При втором подходе отладчик и отлаживаемое ПО рабо¬
тают параллельно, и отпадает необходимость вводить специаль¬
ные изменения в отлаживаемое ПО. Для реализации независимой
отладки требуется ее поддержка со стороны аппаратуры ЭВМ
и со стороны ее операционной системы. Независимость особенно
важна, если отладка ПО должна вестись параллельно в реальном
масштабе времени.
Окружения спецификации [21] предназначены для автомати¬
зации этапа постановки задачи и описания структуры системы ПО,
т. е. для задания требований и спецификации создаваемого ПО.
Как правило, сюда входят спецификаторы, редакторы, анализато¬
ры, верификаторы, документаторы и СУБД. Требования и специ¬
фикации описываются на специальном языке. Тексты на этом язы¬
ке сохраняются в базе данных и могут обрабатываться анализа¬
торами и верификаторами. Исключение составляет окружение
PASILA [33], которое представляет собой своеобразный инстру¬
ментарий для создания окружения спецификаций. В него входят
специализированная система создания трансляторов языков спе¬
цификации, которые преобразуют текст на языке в специальные
типы данных соответствующей базы данных. Эти данные затем
могут анализироваться для установления пригодности специфици¬
рованного ПО. В будущем сюда добавится еще документатор, ко¬
торый позволит выдавать спецификации, например, в виде SADT-
диаграммы. Основная часть окружений этого типа предназначена
для спецификации ПО управления процессами.
Окружения проектирования [50] оказывают машинную под¬
держку на этапе проектирования. Они являются дальнейшим раз¬
26
витием идей проектных библиотек. Центральной частью этих ок¬
ружений служит специальная база данных со своей СУБД и со¬
держащая материалы, связанные с проектом. Этот тип окружения
содержит еще редактор для введения изменений в проект и доку¬
ментатор для оформления результатов проектирования. В окру¬
жениях, где реализуются большие проекты, используется еще ме¬
неджер, позволяющий управлять организацией проектирования.
В этой группе окружений особо отметим TRIAD [51], который по¬
зволяет реализовать различные проектные окружения.
Окружения программирования [48] оказались самым «популяр¬
ным» типом окружений, как правило, они дают поддержку для со¬
здания ПО на каком-то конкретном языке программирования. При
этом персональные окружения состоят из минимального набора
инструментов, куда обязательно входят редактор, компилятор (или
интерпретатор) и отладчик (или анализатор). Для лабораторных
или производственных окружений этого типа добавляются еще
спецификаторы и верификаторы, позволяющие проверять правиль¬
ность текстов на языке программирования, и база данных для их
хранения. Для облегчения получения программ в некоторые окру¬
жения программирования включен генератор, который выдает
тексты программ по описанию процесса генерации. Инструменты
таких окружений во многих случаях сравнимы с аналогичными
инструментами операционных систем. Они только разработаны бо¬
лее систематично (учтено комплексное применение инструментов)
и больше ориентированы на пользователя (хорошо отработан ди¬
алог с инструментами). Здесь нужно особо отметить окружение
SmallTalk [52]-» где используется объектно-ориентированный язык
программирования, и построение всего окружения учтено при ре¬
ализации компонентов вычислительной системы. Особую группу
среди окружений программирования составляют инструменты
PWB/UNIX [53], которые объединяет не общий язык программи¬
рования, а единый способ хранения информации (файлы UNIX).
Окружения тестирования [54] предназначены для машинной
поддержки этапа тестирования ПО. Они состоят из специальной
управляемой базы данных, сохраняющей тестируемый материал и
результаты тестирования. Из инструментов используются компи¬
ляторы или интерпретаторы совместно с анализаторами и докумен¬
таторами, позволяющими оформить результаты проведенных тес¬
тов. В некоторых окружениях анализатор и документатор замене¬
ны отладчиком.
Окружения сопровождения [31] должны обеспечивать работо¬
способность и развитие готового ПО. Центральной частью этих
окружений является база данных, где сохраняются различные
конфигурации и версии ПО. В окружение входит спецификатор
-Для определения конфигурации ПО, генератор для создания го¬
тового (рабочего) ПО соответствующей спецификациям конфигу¬
рации, а также редактор для внесения изменений. Особое внима¬
ние при построении базы данных таких окружений уделяется уп¬
равлению версиями ПО. В эти окружения может быть включен
27
менеджер для управления работами по перегенерации или введе¬
нию изменений.
Окружения макетирования [30] предназначены для быстрого
создания прототипа ПО. Прототип представляет собой работаю¬
щий макет ПО, создаваемый для выявления соответствия между
реализуемым ПО и требованиями пользователя к нему. При ма¬
кетировании, как правило, ПО реализуется постепенно, путем рас¬
ширения и изменения существующего прототипа. Такой способ
позволяет реализовать ПО не в полном объеме. Это сокращает
сроки разработки прототипа, а также позволяет использовать и
изучать ПО на ранней стадии его изготовления. Отказ от тради¬
ционной разработки программ, где предусмотрены этапы опреде¬
ления требований, спецификации проектирования, программирова¬
ния и тестирования ПО, позволяет сократить сроки изготовления
прототипа до 3—6 месяцев. Построение окружения зависит от спо¬
соба ускорения разработки ПО. По этому признаку окружения ма¬
кетирования можно разбить на три группы. Первую группу со¬
ставляют окружения, использующие трансформационный метод
синтеза программ. Вторая группа — это окружения макетирования,
базирующиеся на определенной заготовке, — модели работы ПО
(например, сеть абстрактных автоматов). В таком окружении име¬
ется интерпретатор, который может выполнять действия, задан¬
ные компонентами модели, или генератор, выдающий по содержа¬
щемуся в модели описанию процесса генерации текст на языке
программирования. В третьей группе окружений ускорение про¬
цесса создания ПО достигается за счет сужения предметной об¬
ласти.
Среды поддержки
Среды поддержки объединяют средства автоматизации всех
основных работ, обеспечивающих цикл жизни ПО. Исключение в
этом смысле составляют средства управления, контроля и плани¬
рования работ (аналогичный инструмент в данной работе назы¬
вается менеджером), которые входят в состав немногих сред.
Наибольшее количество сред строится на основе понятия цик¬
ла жизни ПО. При этом цикл жизни понимается их создателями
как последовательность технологических этапов для создания,
эксплуатации и развития ПО. Содержание этапов и их названия
для различных сред этой группы варьируются, но все среды раз¬
работаны на основе немашинного выполнения работ разработки
и эксплуатации ПО. Автор статьи [20] такое понятие цикла жиз¬
ни ПО называет историческим и перечисляет следующие типичные
технологические этапы: определение требований, спецификация,
интеграция, тестирование, развертывание, сопровождение. Нужно
отметить, что основные усилия при построении этих сред направ¬
лены на автоматизацию этапа создания ПО.
Типичным представителем этой группы является среда ARGUS
28
[18], состоящая из пяти наборов инструментов, проектной базы
данных, а также системы управления конфигурацией и версиями
ПО. Применяя ARGUS, можно получить следующие продукты:
документацию проекта (определение концепции, план управления
проектом, спецификацию ПО, план тестирования, пользователь¬
скую документацию), исходные тексты программ, данные и ре¬
зультаты тестирования. Наборы инструментов группируются от¬
носительно различных профессий, входящих в штатный состав
проектной организации. Набор инструментов менеджера позволя¬
ет управлять проектом и организацией, производить экономичес¬
кие расчеты и организовывать обмен информацией между члена¬
ми проектной организации. Набор инструментов для проектиров¬
щика дает поддержку для проектирования, конструирования ПО
и документирования проекта на основе формальных методов соз¬
дания.
Для разработки ПО используют структурное программирова¬
ние. Проектировщик должен специфицировать диаграммы потока
данных, правила декомпозиции процессов обработки данных, за¬
давать описание данных и управление процессами. Работу проек¬
тировщика сопровождает база проектов, для реализации которой
использована реляционная база данных. База проектов основы¬
вается на абстрактной модели ПО, состоящей из элементов процес¬
са и из элементов данных. С каждым элементом процесса связы¬
вается алгоритм. Сам алгоритм составляется на специальном язы¬
ке путем постепенного уточнения. Каждый элемент данных созда¬
ется на основе диаграммы потока данных, в которой заданы его
входные-выходные структуры данных. Все элементы данных вхо¬
дят в словарь данных, в котором задаются связи элементов дан¬
ных с элементами процесса и между собой. Для спецификации и
документации применяется машинная графика, благодаря которой
вся информация, поступающая от проектировщика или выдаваемая
ему, представляется в виде диаграмм, обрабатываемых специаль¬
ным редактором. Проектные документы генерируются автоматиче¬
ски на основе базы проектов. Набор инструментов программиста
состоит из редактора, который настраивается на конкретные про¬
ект, и языков программирования. Сюда входят также компилято¬
ры и отладчик. Набор инструментов для верификации состоит из
статического и динамического анализаторов, позволяющих оце¬
нить качество и надежность ПО. Набор утилит позволяет произ¬
вести специальный графический вывод информации, документиро¬
вать ее, а также связать сателлитные машины, используемые со¬
трудниками проектной организации, с центральной ЭВМ. Такое
построение среды предусматривает следующий постоянный состав
специалистов, работающих над проектом: менеджер, технический
редактор, секретарь, два аналитика высокой квалификации, два
аналитика-проектировщика, один системный аналитик, четыре
старших программиста, один программист. ARGUS используется
Для поддержки ПО, применяемого в авиации.
Вторая группа сред базируется на идее создания специального
29
языка высокого уровня, позволяющего описывать различные ра¬
боты при создании, эксплуатации и развитии ПО.
Одним из интереснейших представителей этой группы является
среда USE.IT [20]. Авторы среды — опытные спецалисты по со¬
зданию ПО. Они входили, например, в состав руководящих раз¬
работчиков проекта APOLLO. На основе этого опыта создана тео¬
рия высокоуровневого программного обеспечения, согласно кото¬
рой любой системе ПО соответствует некая функция, а ее под¬
функции образуют( в смысле управления их работой) древовидную
структуру. Любая из подфункций в составе этого дерева должна
удовлетворять шести аксиомам, устанавливающим следующие тре¬
бования и ограничения по отношению к дереву; любая функция
дерева должна управлять входом и выходом непосредственно под¬
чиненных ей подфункций; иметь выходные данные и проверять со¬
гласованность типов данных. Все составные подфункции дерева
упорядочиваются по их местонахождению в дереве, по приоритету
и времени выполнения, несмотря на то, что выполнение функций
в дереве может происходить асинхронно и параллельно. Любая
функция реализуется в виде контроллера и модуля.
Контроллер представляет собой управляющую структуру, а
модуль реализует вычисления, определяемые функцией. Для ма¬
шинной поддержки этой теории создана среда USE.IT, базирую¬
щаяся на языке спецификации AXES и состоящая из ряда инстру¬
ментов, применение которых позволяет автоматизировать процесс
получения ПО. На базе названной теории авторы USE.IT дали оп¬
ределение функциональной модели цикла жизни ПО.
Функциональная модель цикла жизни ПО представляет собой
формальную модель, состоящую из функций и связей между ни¬
ми, необходимых для создания ПО. Для USE.IT эта модель со¬
стоит из шести функций, реализующих определение, анализ, рас¬
пределение ресурсов, выполнение, документирование и управле¬
ние ПО.
Разработка ПО в рамках USE.IT начинается с формирования
требований для создания ПО на языке AXES. В этом языке ис¬
пользуются три базовых механизма для задания требований ПО:
типы данных, функции и структуры управления. Все эти механиз¬
мы строятся из примитивных механизмов, входящих в язык AXES
или библиотеку AXES. Любой определенный на этом языке меха¬
низм может быть записан в библиотеку AXES и использоваться
для определения других механизмов. Функциональная модель цик¬
ла жизни USE.IT, тоже описанная на AXES, находится в его биб¬
лиотеке и доступна для использования при определении других
систем ПО. Задание требований на языке AXES производится ин¬
терактивно с устранением возможных противоречий в процессе
формулировки.
Следующим этапом построения ПО является анализ требова¬
ний. Для этого в USE.IT существует анализатор, который позво¬
ляет устанавливать полноту и логическую корректность требова¬
ний, а также находить отсутствующие функции или типы данных,
зо
анализировать конфликты управления и интегрировать модули
системы.
После анализа выполняется синтез программ на языке про¬
граммирования, соответствующий проанализированному тексту на
языке AXES. Для этой цели в USE.IT существует синтезатор RATJ
Этап, соответствующий синтезу программ в модели функциональ¬
ного цикла жизни ПО, назван распределением ресурсов. За син¬
тезом программ следует этап выполнения программ на конкрет¬
ной конфигурации вычислительной системы. В USE.IT использу¬
ется самодокументация, т. е. каждый инструмент выдает автома¬
тически документацию, описывающую ПО. Управление ПО, раз¬
работанным с помощью USE.IT, производится автоматически, так
как структуры управления в качестве контроллера включены в
состав любой функции. Среда USE.IT отличается от других сред
тем, что на базе функциональной модели цикла жизни можно опи¬
сать не только системы ПО, но и другие системы (например, ор¬
ганизации людей или системы вычислительной техники), которые
могут задаваться функциональным определением. Средствами
USE.IT реализованы довольно большие прикладные системы ПО.
Третья группа сред построена с учетом функциональных воз¬
можностей и области применения какого-то конкретного языка
программирования. Такая, среда предлагает инструменты и техно¬
логию их использования для создания ПО на этом языке. Наибо¬
лее апробированным и полным представителем этой группы явля¬
ется среда для INTERLISP [22]. Этот язык в основном применя¬
ется для решения задач искусственного интеллекта, вследствие
чего многие инструменты, входящие в состав среды INTERLISP,
построены с использованием достижений в этой области. Инстру¬
менты INTERLISP можно разделить на два класса: общего назна¬
чения и специализированные. Инструменты общего назначения ис¬
пользуются при создании любого типа ПО, и в их состав входят
корректор DWIM, ассистент программиста РА (выполняющий роль
интерфейса), два анализатора статики (MASTERSCOPE, INTER¬
SCOPE), отладчик, почта, итеративное выражение (24 способа
описания циклов). DWIM моделирует работу специалиста-коррек¬
тора и исправляет обнаруженные ошибки в исходной программе.
РА позволяет пользователю управлять диалогом с INTERLISP.
Все интеракции пронумерованы. На основе этих номеров можно из¬
менить, уничтожить или повторить события из истории диалога.
Анализаторы статики имеют базу данных, куда записываются ре¬
зультаты анализа. При этом MASTERSCOPE анализирует только
одну программу, a INTERSCOPE — несколько. Специализирован¬
ные инструменты дают поддержку созданию программ определен¬
ного типа. В INTERLISP такие инструменты называются пакета¬
ми. Каждый пакет представляет собой набор функций INTERLISP.
Существуют пакеты для манипулирования файлами и деревьями,
Для реализации и обработки структурированной записи, для рас¬
познавания образов и т. д. Среду INTERLISP от других аналогич¬
ных сред отличает применяемая технология, называемая исследо-
31
вательским программированием. Так как язык INTERLISP при¬
меняется для решения задач искусственного интеллекта, то часто
возникает ситуация, когда постановка задачи, алгоритм или струк¬
тура обрабатываемой информации неясны. Тогда программа раз¬
рабатывается на основе исследования свойств некоторой програм¬
мы, полученной, например, путем поиска по методу проб и ошибок,
или макетирования. Таким образом, после поэтапного создания
и исследования изготовляется программа, а конечные цели при¬
менения выясняются только в конце ее разработки. INTERLISP
является персональной средой, в проекте участвует не более
2—3-х человек. С помощью среды INTERLISP реализовано, на¬
пример, окружение программирования DICE для языка PASCAL.
Четвертую группу сред объединяет идея использования мето¬
дов и средств искусственного интеллекта. В качестве языков в
этих средах программирования используются типичные языки ис¬
кусственного интеллекта (PROLOG, LISP), и их построение осно¬
вывается на базах знаний и экспертных системах. В центре вни¬
мания при составлении этих сред оказывается процесс создания
программ. Поскольку языки спецификаций в них являются вы¬
сокоуровневыми (например, английский или специальный графи¬
ческий язык) и сопровождаются синтезаторами программ, то мож¬
но эти среды использовать для быстрого макетирования.
Более чем десятилетнюю историю в этой группе сред имеет
PSI [36]. PSI представляет собой множество экспертных систем,
совместное применение которых обеспечивает автоматизированное
получение программ на языке LISP или PASCAL. Для описания
создаваемых программ пользователь может применять либо пред¬
ложения на английском языке, либо конструкции языка специфи¬
кации очень высокого уровня, либо примеры получения выходных
данных из входных данных. Каждое из таких описаний обрабаты¬
вается соответствующими экспертными системами, в результате
работы которых синтезируется программная сеть из конструкций
языка спецификаций очень высокого уровня. В базы знаний этих
экспертных систем заложены общие знания о процессе програм¬
мирования, а также знания о предметной области, которые помо¬
гают пользователю при составлении программы.
Сама программная сеть представляет собой специальную
структуру данных, содержащую непроцедурное описание алгорит¬
ма и данных программы. Из программной сети с помощью конст¬
руктора программ собирается модель программы, являющаяся
процедурным описанием программы на специальном высокоуров¬
невом языке программирования. Этот язык имеет интерпретатор,
позволяющий смоделировать программу на базе символьных вы¬
числений и следить за процессом ее выполнения. Модель програм¬
мы с помощью кодировщика может быть транслирована на языки
LISP и PASCAL. Полученный текст на этих языках обрабатывает¬
ся дальше специальной экспертной системой, которая преобразу¬
ет полученную программу так, чтобы повысилась ее эффективность.
На базе этой экспертной системы обеспечивается эффективная ре-
32
алпзация последовательных и циклических программ, обрабатыва¬
ющих данные в виде списков, массивов и хэш-таблпц. До сих пор
среда PSI не нашла производственного применения. С ее помощью
создан комплект маленьких программ для классификации ситуа¬
ций, заданных в текстовом виде.
Характеристики средств поддержки
Данный обзор составлен на основе 212 источников информации,
содержащих описание 120 различных средств, в состав которых
входят 375 инструментов, 41 окружение и 19 сред поддержки. Бо¬
лее подробные характеристики данных средств приводятся в [55].
Поэтому здесь мы ограничиваемся лишь статистическим описа¬
нием рассмотренных средств. Эту статистику нельзя воспринимать
как общую для характеристики состояния и состава западных
средств, так как обзор составлен на базе научной литературы, и
в нем не анализировались средства, продаваемые на рынке ПО.
В качестве базовой вычислительной техники для реализации
средств поддержки было использовано всего 78 разных вычисли¬
тельных систем (сведения об используемой вычислительной тех¬
нике отсутствуют у авторов для 42-х средств). При этом 54 средст¬
ва были реализованы на ЭВМ фирмы DEC, 18 — на ЭВМ фирмы
IBM и 8 — на ЭВМ фирмы Siemens. Рассмотренные средства ра¬
ботают на базе 43-х различных операционных систем (ОС) (для
54-х средств такие данные отсутствуют); из них 37 применений —
ОС UNIX, 8 — ОС TOPS 10/20, 6 — ОС VMS. Реализация средств
производилась в основном путем применения языков программиро¬
вания высокого уровня. Доля средств, которые созданы на базе спе¬
циального инструментария, незначительна. Семейство языков Lisp
применялось для этой цели для 11, Pascal — для 10 и язык С —
для 5 различных средств. Всего были использованы 32 различных
языка и инструмента реализации. Сведения такого типа отсутст¬
вуют для 74-х средств. Интересной является статистика примене¬
ния языков программирования для реализации как средств, так и
машинно-поддерживаемого ПО; семейство языка Pascal — 35 при¬
менений, семейство языка Lisp — 19 применений и семейство FOR¬
TRAN— 16 применений. При этом было применено 103 различных
языка программирования. Разработчиками средств являются в
56 случаях подразделения университетов и в 38 случаях — фирмы
и другие организации. Самыми активными разработчиками явля¬
ются подразделения Carnegie-Mellon University (Pittsburgh, USA)
с пятью средствами и фирма IBM. с четырьмя средствами.
В табл. 1 приведены данные о количестве проанализирован¬
ных инструментов согласно классификации данной статьи. В этой
таблице отсутствуют данные о компиляторе, так как он был ис¬
пользован практически в составе любого окружения или среды.
Как видно из этой таблицы, самостоятельные инструменты
составляют только одну шестую часть от общего количества. Э :от
факт указывает на то, что в основном делаются попытки ком-
3 Заказ 5620
Таблица 1
Инструменты поддержки
Название инструмента
Инструмент
самосто'ятельный
входит в среду
или окружение
всего
Редакторы:
16
40
56
синтаксически-ори-
ентированный
11
36
47
строковый
3
4
7
знание-ориентиро-
ванпый
2
2
Интерфейсы
4
40
44
Анализаторы:
3
38
41
статики
3
32
35
динамики
—
6
6
СУБД
1
39
40
Генератор
6
31
37
Спецификатор
3
32
35
Интерпретатор
4
26
30
Отладчик
9
17
26
Документаторы:
7
16
23
текстовый
2
10
12
графический
5
6
11
Верификатор
1
9
10
Информатор
—
8
8
Синтезатор
—
7
7
Обучатель
5
1
6
Менеджер
—
4
4
Корректировщик
—
2
2
Всего
59
316
375
плексного решения задач поддержки цикла жизни ПО, а также
на то, что существуют инструменты (например, редакторы, отлад¬
чики, документаторы, обучатели), которые с успехом можно реа¬
лизовать независимо от среды или окружения. Отладчики как тра¬
диционные инструменты применяются довольно редко, но в то же
время взамен появились сравнительно «новые» инструменты: спе¬
цификаторы, анализаторы, верификаторы, синтезаторы, генерато¬
ры. Это говорит о том, что ПО пытаются корректно реализовать
на уровне требований и спецификаций, а программный уровень
достигается путем генерации текстов программ на их основе. Важ¬
ным считается также существование хорошего интерфейса и хра¬
нение обрабатываемого инструментами материала с помощью
СУБД. Появление комплексного подхода привело за собой новые
типы инструментов (информаторы, менеджеры), направленные на
организацию людей, занимающихся поддержкой.
Из табл. 2 видно, что при поддержке различных фаз до сих пор
в центре внимания остается программирование. Существование
других типов окружений свидетельствует о появлении некоторой
34
Таблица 2
Окружение поддержки
Название окружения
Окружение
производ¬
ственное
лабора¬
торное
персо¬
нальное
всего
Спецификация
3
2
2
7
Проектирование
3
—
—
3
Программирование
4
4
8
16
Тестирование
2
3
—
5
Сопровождение
1
1
—
2
Макетирование
1
2
4
7
Всего
14
12
14
40
системы распределения труда с соответствующими профессиями,
а также о возможной декомпозиции процессов машинной поддерж¬
ки цикла жизни. Появление окружения макетирования указывает
на актуальность нахождения принципиальных алгоритмов реше¬
ния каких-то задач применения ЭВМ и на то, что при этом с ус¬
пехом можно применять малую рабочую силу.
Таблица 3 иллюстрирует рассмотренные нами среды поддерж¬
ки. Отсюда видно, что для производственных сред наиболее под¬
ходящим считается построение их на основе понятия цикла жизни.
При этом такие новые идеи, как применение искусственного ин¬
теллекта, пока используются только в маленьких организациях.
Среды, построенные вокруг языка программирования, не достигли
уровня производственной эксплуатации и в основном применяются
также в маленьких организациях.
Таблица 3
Среды поддержки
Основная идея
построения
Окружение
производ¬
ственное
лабора¬
торное
персо¬
нальное
всего
Цикл-жизни ПО
6
1
7
Специальный язык
2
1
—
3
Язык программиро¬
вания
1
4
—
5
Методы и средства
ИИ
—
3
1
4
Всего
9
9
1
19
Таблицы 4 и 5 показывают распределение инструментов среди
различных видов окружений и сред. Наиболее равномерное рас¬
пределение имеют анализаторы и СУБД. Поэтому эти инструмен-
3*
35
Таблица 4
Распределение инструментария в окружениях поддержки
Инструмент
Окружение
специфи¬
кации
проекти¬
рования
програм¬
мирования
тестиро¬
вания
сопровож¬
дения
макети¬
рования
Редактор
1
14
1
4
Анализатор
6
2
3
4
—
3
Верификатор
3
—
1
—
—
1
Корректор
—
—
—
—
—
—
Информатор
—
—
—
—
1
—
Интерпретатор
1
—
11
1 '
—
5
Генератор
1
—
3
—
1
3
Синтезатор
—
—
—
—
—
3
Интерфейс
3
1
10
—
1
3
СУБД
4
3
6
3
2
5
Менеджер
—
1
1
—
2
1
Документатор
—
2
—
1
—
1
Спецификатор
7
—
1
—
1
3
Отладчик
—
—
9
1
—
—
Обучатель
—
—
1
—
—
—
Таблица 5
Распределение инструментария в средах поддержки
Инструмент
Основа
цикл-жизни
ПО
специальный
язык
язык програм¬
мирования
методы и сред¬
ства ЙИ
Редактор
3
2
5
2
Анализатор
5
2
4
3
Верификатор
1
—
—
—
Корректор
—
—
2
—
Информатор
2
—
2
—
Интерпретатор
—
1
4
2
Генератор
3
1
3
2
Синтезатор
—
1
—
1
Интерфейс
3
1
4
3
СУБД
6
3
3
4
Менеджер
3
1
1
—
Документатор
3
3
3
2
Спецификатор
5
1 1
1
1
Отладчик
4
i 1
5
—
Обучатель
1
—
—
ты можно реализовать самостоятельно, и они могли бы включать¬
ся в состав операционной системы наравне с такими же инстру¬
ментами, как компиляторы. Существование в большом количестве
редакторов, интерпретаторов и отладчиков в окружениях програм¬
мирования и в средах, построенных на базе одного языка про¬
граммирования, свидетельствует о том, что это обязательные инст¬
рументы, когда ПО в своем цикле жизни достигло уровня текстов
языков программирования. Таким образом, для каждого языка
программирования целесообразно иметь по меньшей мере редак¬
тор, интерпретатор, отладчик и компилятор.
36
Заключение
Создание средств поддержки цикла жизни ПО следует считать
актуальным, имея в виду количество и географию разработок это¬
го вида за рубежом. Нужно отметить, что картина в этой области
представляется довольно пестрой. Трудно выделить какие-либо
доминирующие средства, а технология поддержки цикла жизни
ПО полностью еще не создана. Из-за этого на рынке ПО отсутст¬
вуют средства поддержки, которые по степени внедрения можно
сравнить с другими типами ПО (например, операционными си¬
стемами или СУБД). Причина здесь, вероятно, в том, что при ис¬
пользовании таких средств намного повышается продуктивность
разработчиков ПО и надежность самого ПО. Поэтому фирма, вла¬
деющая хорошим средством поддержки, не хочет продавать его на
рынке, так как это снизило бы ее конкурентоспособность. На при¬
мере опыта использования среды USE.IT можно сказать [20],что
при разработке ПО особой сложности продуктивность повышается
в сотни (даже тысячи) раз, сроки разработки уменьшаются в де¬
сятки (даже сотни) раз.
Оценивая количество средств поддержки на различных фазах
развития ПО, можно заметить, что основная их часть использует¬
ся на этапе разработки ПО. Здесь проявляется некоторая диспро¬
порция, поскольку приблизительно 70% материальных и времен¬
ных затрат приходится на период сопровождения ПО. Причина
этого, видимо, в том, что накоплен значительный опыт разработки
ПО, на основе которого создан ряд технологий. Относительно пе¬
риода сопровождения в целом этого сказать нельзя. Специальны¬
ми инструментами сопровождения можно назвать только специа¬
лизированные СУБД, используемые для управления версиями и
конфигурациями ПО. Все остальные инструментальные средства
используются лишь постольку, поскольку совпадают работы на
этапах создания и сопровождения.
Если рассматривать пробивную силу сред поддержки для чу¬
жого использования, то складывается мнение, что наиболее по¬
пулярны среды, реализованные как аморфные разработки, разви¬
тие которых производится не по строгим планомерным проектам,
а по мере различных надобностей их применения. Хорошими при¬
мерами в подтверждение этого мнения служат PWB/UNIX
и INTERLISP. Эти среды являются открыто-завершенными, и каж¬
дый пользователь может их развивать в нужную ему сторону.
Основные трудности при создании средств поддержки заклю¬
чаются в большом объеме работ. В работе [56] приводятся дан¬
ные о хронологии создания SREM, UNIX и SmallTalk, откуда вид¬
но, что для построения и реализации таких средств требуется бо¬
лее 10 лет. При этом самыми трудоемкими этапами оказываются
разработка концепции (приблизительно 5 лет), а также макетная
реализация и опытная эксплуатация (7—14 лет). Подготовка для
продажи на рынке требует приблизительно 3 года. Другой труд¬
ностью применения сред являются их освоение и обучение исполь¬
37
зованию. Как правило, в основу их построения заложены новые
идеи или теоретические достижения, не попавшие в поле зрения
системы образования. Это в свою очередь приводит к ситуации,
когда специалист, закончивший учебное заведение, не может сразу
активно подключиться к использованию среды, а должен получить
дополнительную подготовку для работы.
В развитии описанных средств не заметно тенденций к появле¬
нию новых формализованных методов, специально создаваемых
для машинной поддержки, и в основном используются технологии
и методы, разработанные в первой половине 70-х годов. Наиболее
перспективными направлениями развития мы считаем использо¬
вание методов искусственного интеллекта, создание специальных,
очень высокоуровневых языков, применение средств машинной
графики и совершенствование технологии применения развитых
СУБД. В области искусственного интеллекта можно выделить два
направления. Одно связано с применением экспертных систем,
оснащенных развитыми базами знаний, а другое — с синтезом про¬
грамм. Тенденция разработки и использования специализирован¬
ных, очень высокоуровневых языков, вероятно, получила свои исто¬
ки от технологии построения систем обработки данных на базе
так называемых языков четвертого поколения и СУБД общего на¬
значения. В обоих случаях ПО дается в виде спецификаций, из ко¬
торых автоматически генерируются желаемые программы. Неожи¬
данные результаты может дать добавление к средствам поддерж¬
ки возможностей визуализации объектов и процессов ПО с по¬
мощью средств машинной графики, так как человек особенно хо¬
рошо воспринимает визуальную информацию. На процессе разви¬
тия могут сказаться и многие проблемы, решение которых пока не
охвачено машинными инструментами. Сюда относятся, например,
автоматизированное получение достоверной информации для обу¬
чения использованию ПО, создание методов и средств сопровож¬
дения, тесно связанных с этапом разработки.
ЛИТЕРАТУРА
1. Structured Programming. Practice and Experience. Vol. 2: Structured Program¬
ming Methodologies and Tecniques//Infotech International Survey, 1978.—
P. 46—48.
2. Houghton R. C., Jr. Computer Science and Technology: Software Development
Tools//NBS Special Pub. — 500—88. — P. 193.
3. Вычислительная техника социалистических стран: Сборник статей. — Вып.
18/Под ред. И. А. Данильченко. — М.: Финансы и статистика, 1985.
4. Международная научно-техническая конференция «Программное обеспече¬
ние ЭВМ»: Секция 2 «Технология разработки программного обеспечения»:
Тезисы докладов, 1984, июль. — Калинин, 1984.
5. II Всесоюзная конференция «Технология программирования»: Тезисы докла¬
дов в 2-х частях. — Киев, 1986.
6. III Всесоюзная конференция «Автоматизация производства систем програм¬
мирования»: Тезисы докладов. — Таллин, 1986.
7. Aho А. V. Translator Writing Svstems: Where do thov now stand?//Compu-
ter. — 1980. — Vol. 13. — № 8. — P. 9—14.
38
8. Abbott R. J., Moorhead D. K. Software Requirements and Specifications: A Sur¬
vey of Needs and Languages//The Journal of Systems and Software.— 1981.—
Vol. 2. —№ 4 —P. 297—316.
9. Wassermann A. I. Software Engineering Environments: Tech. Rep.— № 61.—
July, 1982//Advances in Computers/Ed. by M. Yovits. — Academie Press,
1982. —Vol. 22.
10. Lyon G. Structural Dimensions of Small Programming Environments, Soft¬
ware— Practice and Experience. — Jan. 1985.— Vol. 15. — № 1.
11. Miillerburg M. A. F. The Role of Debugging within Software Engineering En-
vironments//ACM SEN. —Aug, 1983.— Vol. 8. — № 4. — P. 81—90.
12. Gabriel R. P., Frost M. E. A Programming Environment for a Timeshared Sys-
tem//ACM SEN. — 1984. — Vol. 9. — № 3. — P. 185—192.
13. Jesshope C. R., Crawley M. J., Lovegrove G. L. An Intelligent Pascal Editor
for a Graphical Oriented Workstation//Softw. — Pract. and Exp. — Vol. 15.—
№ 11. —P. 1103—1119.
14. Waters R. C. The Programmer's apprentice: A Session with KBEmacs//IEEE
TSE. —Nov. 1985. —Vol. SE-11. —№ 11. —P. 1296—1320.
15. Dausmann M., Persch G., Drossopoulou S., Winterstein 'G. A Separate Com¬
pilation System for Ada//Werkzeuge der programmier-technik, GI — Arbeitsta-
gung, Karlsruhe, Marz 1981, Proc., Herausgegeben von G. Goos, Springer —
Verlag, — New York, Berlin: Heidelberg, 1981. — P. 197—213.
16. Berthand M., Griffits M. Incremental compilation and conversational interpre-
tation//Annual Review in Automatic Programming.— 1973. — Vol. 7.
17. Wilso- C., Osterweil L. J. Omega — A Data Flow Analysis Tool for the C Pro¬
gramming Language//IEEE TSE. — Sep. 1985. — Vol. SE-11. — N 9.—
P. 832—838.
18. Stucki L. G. What about CAD/CAM for Software? The ARGUS Concept: A
Conf, on Softw. Dev. Tools, Techn. and Alternatives: Arlington, VA, 25—28
July, 1983//Proc. Silver Spring. — P. 129—144.
19. Yuasa T., Nakajima R. IOTA: A Modular Programming System//IEEE TSE.—
Feb. 1985. —Vol. SE-11. —N 2. — P. 179—187.
20. Hamilton M., Zeldin S. The Functional Life Cycle Model and its Automation:
USE. IT//The Journ. of Syst. and Softw.— 1983. — Vol. 3. — № 1. — P. 25—62.
21. Silverberg B. A. An Overview of the SRI International Development Metho-
dology//Software Engineering Environments. Proc, of the Symp. in Lahnstein,
Fed. Rep. of Germany, June 16—20, 1980. New York: ed. by H. Hiinke, 1981.—
P. 253—266.
22. Teitelman W. A Display Oriented Programmer's Assistant, Int. J. Man-Machine
Studies. 1979, 11. —P. 157—187.
23. Shattan A., Hecker J. Documenting UNIX: Beyond Man Pages, USENIX Asso-
ciation//Summer Conference Proc., Portland 1985, June 11 —14.— 1985.—
Oregon, USA. — P. 437—454.
24. Tomek I., Muldner T. A CAI Implementation of Pascal//SIGPLAN Notices,
Apr. 1985. — Vol. 20. — № 4. — P. 88—95.
25. Matthews M. M., Nolan T. LEVI: A Prototype Active Assistance Interface.
USENIX Ass., Summer Conf. Proc., Portland 1985, June 11 —14.— 1985.—
Oregon, USA. —P. 325—331.
26. Teitelman W. A Tour Through Cedar//IEEE TSE. — March. 1985. — Vol.
SE-11.—№ 3. — P. 285—301.
27. Campbell R. H., Kirslis P. A. The SAGA Project: A Svstem for Software De-
velopment//ACM SEN. — 1984. — VoL 9. — № 3. — P. 73—80.
28. Reiss S. P. PECAN: Program Development Systems that Support Multiple
Views,//IEEE TSE. —March. 1985. —Vol. SE-11. —N 3. — P. 276—284.
29. Giacalone A., Rinard M. C„ Doeppner T. W., Jr. IDEOSY. An Ideographic and
interactive Program Description System//ACM SEN. — 1984. — Vol. 9.—
№ 3. —P. 15—20.
30. Cohen D., Swartout W., Blazer R. Using Symbolic Execution to Characterize
Behavior//ACM SIGSOFT SEN. — Dec. 1982. —Vol. 7. — № 5. — P. 25—32.
31. Leblang D. B., Chase R. P., Jr. Computer-Aided Software Engineering in a
Distributed Workstation Environment//ACM SEN.— 1984. — Vol. 9 —№ 3 —
P. 104—112.
39
32. Bottos В. A., Kinta I a С. M. R. Generation of Syntax-Directed Editors with
Text — Oriented Features//The Bell System Technical Journal. — Dec. 1983.—
Vol. 62. — № 10. —P. 3205—3224.
33. Christ J., Balzert H. PASILA — ein Computerunterstuetztes Werkzeug zur
Definition und Implementation von Anforderungssprachen//Werkzeuge der Pro-
grammiertcchnik, GI — Arbeitstagung, Karlsruhe. — 1981, Marz. — Proc.,
N-Y., — 1981. —P. 57—74.
34. Reps T., Teitelbaum T. The Synthesizer Generator//ACM SEN.— 1984. — Vol.
9. — N 3. — P. 42—48.
35. Olsen D. R., Jr., Dempsey E. P. Syntax Directed Graphical Interaction,
SIGPLAN’83 Symp. on Prog. Lang. Issues in Softw. Systems, San — Francisco,
June 83, Proc.//SIGPLAN Notices. — June. 1983. — Vol. 18. — N 6.—
P. 112—117.
36. Barstow D. R. Knowledge — Based Program Construction. North-Holland, New
York: 1979.
37. DeTreville J. Phoan; An Intelligent System for Distributed Control Synthesis//
ACM SEN. — 1984. — Vol. 9. — N 3. — P. 96—103.
38. Goguen J., Meseguer J. .Rapid Prototvping in the OBJ Executable Specification
Language//ACM SIGSOFT SEN. — Dec. 1982.— Vol. 7. — N 5. — P. 75—84.
39. EPOS Primer, ed. by R. Lauber, Univ, of Stuttgart, July 1984.
40. Bird M„ Schofield N. A Practical approach to software engineering by using
an interaction handler and skeleton code generator. Computer — Aided De¬
sign.—Oct. 1985. —Vol. 17.— N 8. — P. 374—378.
41. Tichy W. F. RCS — A System for Version Control, Softw. — Pract. and
Exp.—July, 1985.—Vol. 15. — N 7. —P. 637—654.
42. Sneed H. M. Softing Software Engineering System, The Journ. of Systems and
Software.— 1983. —Vol. 3. — N 1. —P. 63—76.
43. Harala S., Kuusela J., Lahdelma R. Ohjelmoinnin apuvalineiden kehittaminen
MACLISP — p.ohja'isille jarjestejmi-lle fj STeP — 84 Sympsoium Papers / Ed.
by E. Hyvonen, J. Seppanen, M. Syrjanen. — P. 90—94.
44. Schollenbergen K., Truol K., Viebeg U. DIPROTOR, Ein Softwarewerkzeug
zur Erstellung von Diagrammen und Programmrahmen fiir die datenstruk-
turorientierte Methode des Programmentwurfts, Werkzeuge der Program-
miertechnik, GI — Arbeitstagung. — Karlsruhe: Marz. 1981. Proc., N.-Y.,
1981. —P. 154—168.
45. Buhr R. J. A., Karam G. M. An Informal Overview of CADA; A Design Envi¬
ronment for Ada//ACM SIGSOFT SEN.—Apr. 1985. — Vol. 10. — N 2.—
P. 84—88.
46. Hollowich M. E. et al. Software Design and Verification System (SDVS) //
Tech. Rep. AFAL — TP — 76—200.—1977, May.
47. Queille J. P., Sifakis J. Specification and Verification of Concurrent Systems
in CESAR. —P. 337—351.
48. Delisle N. M., Menicosy D. E., Schwartz M. D. Viewing a Programming
Environment as a Single Tool//ACM SEN. — 1984. — Vol. 9. — N 3.—
P. 49—56.
49. Beander B. VAX DEBUG: An Interactive, Symbolic, Multilingual Debug¬
ger//ACM SEN. — 1983, Aug.—Vol. 8. — N 4. — P. 173—179.
50. Willis R. R. AIDES; Computer Aided Design of Software Systems-II // Sof¬
tware Engineering Environments. Proc, of the Symp. in Lahnstein. Fed. Rep.
of Germany. — 1980. June 16—20, — ed. by H. Hunke. — New York: 1981.—
P. 27—48.
51. Ramanathan J., Soni D. Design and Implementation of an Adaptable Soft¬
ware Environment// Comp. Lang. — 1983. — Vol. 8. — № 3/4. — P. 139—159.
52. Goldberg A. SmallTalk-80. The Interactive Programming Environment, 1982.
53. Ritchie D. M., Thompson K- The UNIX Time-Sharing System//The Bell Syst.
Tech. J.— 1978. July-Aug. — Vol. 57. — N 6. — Part 2. — P. 1905—1930.
54. Roussopoulos N., Yeh R. T. SEES — A Software testing Environment Sup¬
port System//IEEE TSE. — Apr. 1985. — Vol. SE-U. — N 4. — P. 335—366.
55. Мельников И. А., Раабе А. С., Тамм Б. Г. Зарубежные средства машин¬
ной поддержки цикла жизни программного обеспечения (обзор и анализ^ —
Таллин, 1987.— (Препринт/ИК АН ЭССР).
40
56. Riddle W. E. The Magic Number Eighteen Plus or Minus Three; A Study of
Software Technology Maturation //ACM SIGSQFT SEN. — Apr. — 1984. —
Vol. 9. — N 2. —P. 21—37.
УДК 512.8.001.57:57.087
И. А. РАВКИН, В. Л. TEMOB
ТЕХНИКА БИТОВЫХ ПРЕДСТАВЛЕНИЙ
И ОБРАБОТКА ИЗОБРАЖЕНИЙ
Введение
Техника битового представления информации, казалось бы,
столь естественная для ЭВМ, работающих в двоичной системе,
имеет очень мало применений в сложных задачах. Причины этого
заключаются в следующем:
стандартный формат машинного слова, в который приходится
вкладывать параметры задачи, и высокая стоимость доступа к би¬
ту в традиционных системах команд (затраты на обработку ячей¬
ки обычно меньше затрат на обработку одного бита ячейки);
традиционные алгоритмы описываются в терминах операций
над элементарными значениями, а не над крупными, содержатель¬
но интерпретируемыми единицами данных.
В настоящей работе доказывается (в том числе на примерах)
возможность систематически применять технику битовых представ¬
лений данных, получая часто значительный выигрыш в объеме па¬
мяти и очень большой в скорости выполнения алгоритмов (на 1 —
2 порядка для многих типичных современных ЭВМ).
В основе этих методов лежит базис, оперирующий с битовыми
массивами, причем одна и та же операция применяется однородно
(а в мультипроцессорных системах, если возможно, и параллель¬
но) ко всем элементам массива. Эти методы могут эффективно
применяться к тем классам задач, для которых удается найти ал¬
горитмы решения, выражаемые преимущественно в терминах мас¬
совой обработки однородных единиц информации.
В первой части статьи описываются операционный базис, ос¬
новные методы и их использование в различных задачах. Во вто¬
рой части подробно рассматривается обработка черно-белых и по¬
лутоновых изображений при помощи битовой техники.
Большинство идей и алгоритмов в этой части не являются ори¬
гинальными. Такие операции, как, например, «скелетирование»,
рассматриваются в большом количестве работ. Реализация алго¬
ритмов известна самая разная: от целочисленных массивов, пред¬
ставляющих битовые изображения на Фортране [11,16] до специ¬
альной аппаратуры [1,12,13,14,15,17,21]. Наиболее полный и
Последовательный подход к обработке изображений в морфологи¬
41
ческом стиле развит в Центре математической морфологии Па¬
рижской школы геологических наук в Фонтенбло [8,11,20].
Мы предлагаем обратить внимание на следующие идеи и ре¬
зультаты:
набор операций над битовыми массивами, позволяющий ре¬
шать разнообразные задачи, в том числе по обработке изображе¬
ний;
использование трехмерных битовых матриц (слоек) с перемен¬
ным количеством слоев для представления полутоновых изображе¬
ний; набор арифметических, логических и морфологических опе¬
раций над слойками;
использование слоек для параллельного обнаружения областей
с заданными свойствами на битовых изображениях;
использование функций затухания для произвольных монотон¬
ных процессов преобразования изображений и построение на их
основе параллельных фильтров;
срезы по площади и по толщине;
текстурный анализ на основе гранулярности и периодичности
изображений;
утолщения и утоньшения полутоновых изображений на основе
описания вертикальной окрестности;
язык для обработки изображений Картран и его реализация.
В настоящее время существует несколько десятков типов экспе¬
риментальных и серийно выпускаемых специализированных про¬
цессоров для обработки изображений, для которых можно пол¬
ностью или частично использовать рассматриваемые в этой рабо¬
те понятия и методы [2,4,5,6,8,10,12,14,17,19,21]. Роль этих ме¬
тодов будет возрастать по мере распространения и удешевления
мультипроцессорных систем на основе микропроцессоров.
Создание процессора специально под описываемую ниже тех¬
нику работы с битовыми массивами в ближайшем будущем впол¬
не реально. Сегодня использование соответствующей программной
системы для ЕС ЭВМ. позволяет начать х^етодическую отработку и
регулярную эксплуатацию некоторых задач.
Представление и базовые средства обработки
битовой информации
Операции над битовой информацией, предоставляемые систе¬
мами команд ЭВМ.. Как уже упоминалось, в большинстве систем
команд современных ЭВМ обработка изолированного бита обхо¬
дится довольно дорого, требуя для доступа к произвольному биту
10—15 команд (индексация, выделение бита, выделение фона,
сдвиги и т. п.). В то же время одна операция с машинным словом
позволяет обработать несколько десятков бит. Кроме того, во мно¬
гих ЭВМ существует возможность выполнить одной командой не¬
сложную обработку значительных массивов информации (в ЕС
42
ЭВМ — до 256 байт) либо возможность зацикливать команду для
обработки на повышенной скорости полей памяти произвольного
объема.
На основе перечисленных возможностей могут быть построены
подпрограммы или макросы, выполняющие с относительно высокой
скоростью поэлементные булевы операции над битовыми массива¬
ми, пересылки битовых массивов со сдвигом позиции битов в ма¬
шинном слове, сравнение битовых массивов, поиск ближайшего
к заданному биту нуля или единицы.
Организация работы с битовой информацией в системе МА¬
СОН. Система программирования МАСОН [3]-, реализованная на
ЕС ЭВМ, представляет собой объединение некоторой операционной
среды и инструментальных средств, позволяющих расширять эту
среду. Основным средством разработки прикладных систем явля¬
ется реализованный в рамках МАСОНа язык программирования
ИНФ78, в который встроены средства работы с битовыми масси¬
вами.
Эти средства реализованы оптимальным образом с учетом воз¬
можностей системы команд. При этом неизбежно оказывается, что
скорости выполнения различных операций значительно отличают¬
ся, что должно влиять на стиль программирования и предпочтения
программиста.
Ниже приведены операции над битовыми массивами и скорос¬
ти их выполнения, замеренные для ЕС1022 со средним быстро¬
действием порядка 100 000 по Гибсону. Для этой ЭВМ средний
цикл, в котором обрабатывается, например, вещественное число,
проходит 20 000—30 000 раз в секунду.
Операции над битовыми массивами и их частями
Операция
Скорость (бит/с)
Пересылка без сдвига позиции битов в машинном слове
Поэлементная булева операция над двумя аргументами (в
языке реализованы все 16)
Пересылка со сдвигом позиции битов в машинном слове
Поиск ближайшего нуля (единицы) начиная с заданного бита
Подсчет количества единиц в битовом массиве
Пересылка «плотного» битового массива в «редкий» и об¬
ратная операция — пересылка «редкого» массива в «плот¬
ный»
Сравнение битовых массивов
5 '000 000
2 000 000
800 000
800 000
150 000
12 000
3 000 000
Далее приводится синтаксис соответствующих операторов в
языке ИНФ78. Под массивами здесь подразумеваются массивы
бит.
43
1. Переслать
(массив или часть) в (массив или часть);
2. Бул. оп. (номер булевой операции),
(массив аргумент 1) /массив аргумент 2),
(массив результат);
Номер операции, рассматриваемый как двоичное число, задает
таблицу истинности для этой операции:
Номер операции
111111
01 2 3-156789012345
Операнды
РЕЗУЛЬТАТ
первый
второй
0
0
0000000011111111
0
1
00001 1! 1100001111
1
0
0011001100110011
1
1
0101010101010101
Например, конъюнкция — это операция номер 1, дизъюнкция — операция
номер 7 и т. д. Ограничение: длины массивов должны быть равны и кратны 8.
3. Так же, как и в п. 1, но хотя бы один из аргументов является частью неко¬
торого битового массива, причем сдвиг не кратен 8.
4. ИскатьО(Искать!)
(номер элемента, с которого начинается поиск),
(массив),
(номер найденного элемента или 0, если не нашли);
5. UNITS (массив);
Функция, выдающая количество единиц битового массива.
6. Пл. род. (Род. пл.)(массив редкий),(массив плотный),
(пропуск), (шаг), (длина),
Следующая схема иллюстрирует это преобразование:
РЕДКИЙ
(ПРОПУСК)(ШАГ.)(ШАГ.)(ШАГ.)(ШАГ.) (ШАГ.)(ШАГ.)(ШАГ.)(ШАГ.)
011001110110011000110111100010110010100010111101000111101000101
I 'р I I I I tj
ПЛОТНЫЙ
101000110
(ДЛИНА)
7. Равны ((массив 1), (массив 2>)
Функция, выдающая «1», если содержания массивов совпадают,
и «0», если не совпадают.
Использование приведенного набора операций для задач ана¬
лиза изображений, логических задач (например, раскраски гра¬
фов и поиска путей в лабиринтах, анализа нуклеотидных после¬
довательностей, анализа электрофизиологических сигналов) поз¬
воляет считать, что этот набор является полным и минимальным.
Это утверждение нужно понимать в том смысле, что отсутствие
любой из операций привело бы к необходимости программировать
44
соответствующую потребность обычными средствами и, следова¬
тельно, к замедлению алгоритмов.
Например, забегая вперед, скажем, что без поиска единицы
(нуля), начиная с заданного места, нельзя выделять связные об¬
ласти на изображениях. Без преобразования из плотной формы в
редкую нельзя реализовать сдвиги изображения.
При написании программ обработки битовых массивов очень
важны и некоторые другие возможности языка ИНФ78.
1. Динамическое распределение памяти. Массив с одним и тем
же именем можно объявить и переобъявить любое количество раз
(при сохранении типа). При каждом объявлении содержание мас¬
сива становится нулевым. Эта возможность удобна при последо¬
вательной работе с массивами разного размера. Кроме того, мож¬
но расширить массив на положительное или отрицательное число
элементов. При этом старое содержание остается. Например, та¬
ким образом можно добавить к 3-мерной битовой матрице еще не¬
сколько слоев, если это нужно по ходу алгоритма, или убрать их,
чтобы освободившаяся память впоследствии могла быть исполь¬
зована для других целей.
2. Разные объекты с одним содержанием. Объект является со¬
вокупностью паспорта и содержания. Паспорт описывает органи¬
зацию объекта — его тип, размерность, формат элемента, границы
индексов. В ИНФ78 есть возможность определять разные объекты
по одному содержанию. Это дает доступ к каждому биту в пред¬
ставлении числа и возможность определить число по сформирован¬
ному битовому массиву. Часто используется определение по од¬
ному содержанию битового и байтового массивов.
3. Кроме перечисленных, в языке ИНФ78 есть следующие груп¬
пы средств: арифметические и матричные выражения; встроенные
математические функции; циклы и другие виды управления; упо¬
минание элементов массивов; ссылки на связные части массивов;
паспортные функции; работа с текстами в коде МАСОНа; архив¬
ная система; форматная печать; передача параметров и вариар-
гументность; массивы имен и внешние объекты; связь с другими
языками системы МАСОН; библиотека программ; контроль син¬
таксических и динамических ошибок; операционное окружение
языка ИНФ78.
Обработка изображений
Классы изображений и виды обработки. С учетом используе¬
мых математических и программных средств изображения, кото¬
рые обрабатываются на ЭВМ, можно разделить на два класса:
1) графические изображения, составленные из просто описы¬
ваемых элементов, таких, как точки, отрезки прямых, дуги окруж¬
ностей и эллипсов и т. п. Такие изображения встречаются в ма¬
шинной графике, в задачах управления станками, на этапе интер¬
претации изображений в задачах управления роботами и в дру¬
гих областях. Для этого класса изображений в основном харак¬
терны задачи синтеза изображения по описанию;
45
2) точечные или растровые изображения, возникающие при
оцифровке реальных изображений внешнего мира, регистрируе¬
мых приборами. Это могут быть оптические, инфракрасные, ульт¬
рафиолетовые, ультразвуковые, термографические, рентгеновские,
радиоизотопные и другие по физической природе изображения.
Для этого класса изображений характерны задачи предваритель¬
ной обработки для визуализации изображений и их последующего
анализа человеком — оператором и задачи автоматического ана¬
лиза изображений и составления их структурных описаний.
Методы обработки изображений, рассматриваемые в этой
статье, ориентированы на изображения второго класса. Мы будем
рассматривать только обработку двумерных (плоских) изображе¬
ний, но предлагаемые методы могут быть обобщены и на трех¬
мерный случаи.
Стиль работы с изображениями. Предлагаемый стиль работы
с изображениями характеризуется: инструментальностью, парал¬
лельностью, локальностью и полнотой.
1. Инструментальность. Все предлагаемые методы вытекают
не из какой-либо математической теории, а полностью определя¬
ются имеющимися инструментальными средствами; разрабатыва¬
ются только те методы и только для тех задач, которые хорошо
укладываются в технику битовых операций и возможности систе¬
мы МАСОН. Например, совсем не рассматриваются повороты или
искажения масштаба, зато широко используется возможность ра¬
боты с переменным количеством битов на точку изображения.
2. Параллельность. Все операции над изображениями являются
параллельными. Программист работает в терминах картинок, а
не точек. Это свойство важно по двум причинам:
облегчается разработка алгоритмов, так как они описываются
в более адекватных терминах;
появляется потенциальная возможность реализовать все эти
алгоритмы на специальной, параллельно работающей аппаратуре,
что даст быстродействие, достаточное для многих важных задач.
3. Локальность. Известно большое количество преобразований,
в которых результат зависит от некоторой локальной окрестности.
Используются окрестности со стороной от трех до нескольких де¬
сятков элементов. Предлагаемый стиль состоит в том, что в одном
преобразовании используется только минимальная окрестность.
Учет дальнего окружения или всей картинки в целом возможен
только за счет последовательности преобразований.
Пусть нужно сделать преобразование, радиус влияния которого
равен Т. В общем случае для этого нужно выполнить количество
операций, пропорциональное Т**2. В нашем случае преобразова¬
ние на радиус Т является произведением Т-преобразований радиу¬
са 1. Для его выполнения необходимо количество операций, про¬
порциональное Т. Таким образом экономится время и повышается
наглядность, так как операции радиуса 1 обычно имеют ясную со¬
держательную интерпретацию.
4. Полнота. Это свойство состоит в том, что предлагается не
46
какой-то один метод или группа методов обработки изображений,
а система понятий и ее адекватное языковое оформление, которые
допускают саморазвитие языка и самой системы понятий.
Понятиями базиса являются: битовые массивы и операции над
ними, объявления, пересылки и т. п. Это соответствует уровню
языка ИНФ78. Понятиями надстройки являются: битовые и полу¬
тоновые картинки (слойки), сдвиги, утолщения, утоньшения, сре¬
зы, описания окрестностей и т. п. Это соответствует уровню языка
Картран. Понятия базиса фиксированы, понятия надстройки мо¬
гут расширяться, а соответствующие им операции программиро¬
ваться на ИНФ78 и включаться в Картран в качестве команд.
Язык Картран расширяем. Каждая программа- на нем после
трансляции становится его командой.
В процессе функционирования, как это часто бывает, над¬
стройка получает относительную независимость от базиса. Можно
писать программы обработки изображений, ничего не зная о ба¬
зовых инструментальных средствах. Программы на Картране не
зависят от способа реализации базовых средств и от того, выпол¬
няются ли они на универсальной ЭВМ или на спецпроцессоре.
Набор понятий Картрана (надстройка) адекватен содержа¬
тельной области и дает возможность работы в ней. Набор понятий
ИНФ78 (базис) детерминирован исключительно инструменталь¬
ными соображениями и не адекватен рассматриваемой содержа¬
тельной области. Это удачный пример развития инструменталь¬
ного подхода. Могут быть неудачные примеры, но очевидно, что
подход, противоречащий инструментальным возможностям, не мо¬
жет быть эффективно реализован, как бы ни была красива соот¬
ветствующая теория.
Содержательная интерпретация базового набора операций. Бу¬
дем рассматривать только двухградационные (черно-белые) изо¬
бражения и представлять их в виде двумерных битовых массивов.
Области единиц будем называть объектами, а области нулей —
фоном.
Введенный выше базовый набор операций допускает естест¬
венную интерпретацию. Пользуясь булевыми операциями над мат¬
рицами, можно получить объединение и пересечение изображений,
области несовпадения, вычесть из одного изображения другое,
инвертировать изображение.
Операции поиска нуля и единицы позволяют найти первую
точку объекта или фона, начиная с заданного места. Операция
подсчета единиц дает площадь объектов, представленных на кар¬
тинке. Преобразование битовых массивов из редкой формы в плот¬
ную и обратно позволяет транспонировать изображение.
Приведенные содержательные возможности очень бедны. По-
настоящему широкие возможности возникают при комбинирова¬
нии их со сдвигами изображения. В общем случае нужно сдви¬
нуть изображение на М строк и N столбцов (рис. 1). Это достига¬
ется пересылкой части А1 в часть А2 и обнулением частей В и С.
47
++++++
Рис. 1. Сдвиг изображения на М-3 строк вверх и N-4
столбцов вправо
Комбинируя сдвиги и булевы операции, можно находить наи¬
лучшее совмещение изображений, вырезать произвольные прямо¬
угольные фрагменты, находить контуры и многое другое. Одна¬
ко для содержательной работы с изображениями описанные опе¬
рации оказываются слишком мелкими. Алгоритмы, записанные
через булевы операции и сдвиги, громоздки и ненаглядны. Ниже
будет рассмотрена система понятий, позволяющая построить бо¬
лее удобный набор операций для обработки изображений.
Соседство и способы описания окрестности. Пространственное
квантование изображения состоит в том, что значения интенсив¬
ности изображения измеряются в узлах некоторой дискретной сет¬
ки. Естественно потребовать, чтобы структура сетки была регу¬
лярной и все ее ячейки были одинаковыми правильными много¬
угольниками. Такому условию удовлетворяют квадратные, тре¬
угольные и шестиугольные сетки.
В шестиугольной сетке точка имеет 6 соседей, в квадратной —
4 или 8. Множество соседей называется окрестностью точки.
Если задано соседство, то можно определить связность. Мно¬
жество точек называется связным, если из любой его точки мож¬
но попасть в любую по цепочке соседей. На стандартных ЭВМ
удобно реализуются операции с дискретными изображениями на
квадратной сетке, однако квадратная сетка имеет следующий не¬
достаток: для того чтобы результаты были непротиворечивы и
соответствовали геометрической интуиции, для объектов прихо¬
дится определять 4-связность, а для фона — 8-связиость или на¬
оборот.
Различные шаблоны соседства приводят к различным дискрет¬
ным аппроксимациям круга. Так, для шаблона 4 кругом являет¬
ся ромб, для шаблона 8 — квадрат, а для шаблона 6 — шести¬
угольник.
Треугольные и шестиугольные сетки можно реализовать на
стандартных структурах памяти, рассматривая по-разному чет¬
ные и нечетные строки. Следующее изложение относится к любой
структуре сетки. Окрестность некоторой точки (опорной) пол¬
ностью задается указанием значений в точках, соседних с опор¬
ной. Иногда в описание окрестности удобно включать и значение
в опорной точке.
48
Часто желательно описать компактным образом множество
окрестностей. Рассмотрим два способа такого описания, которые
допускают эффективную реализацию.
1. Пусть точки окрестности принимают не два значения: 0 и 1,
а три: 0, 1 и 2, причем 2 обозначает безразличное значение. Опи¬
сание окрестности, содержащее К безразличных элементов, со¬
ответствует множеству из 2**К конфигураций окрестности [9,
20].
2. Множество окрестностей можно описать, задавая такие ха¬
рактеристики окрестности, как смежность и контраст <[13]. Смеж¬
ностью называется количество единичных соседей в окрестности.
Контрастом называется количество переходов с.единичных сосе¬
дей на нулевые и обратно при обходе окрестности. Можно зада¬
вать не фиксированные значения, а диапазоны для этих харак¬
теристик.
Первый способ описания зависит от поворота окрестности во¬
круг опорной точки, второй — не зависит.
Преобразования изображений и последовательности преобра
зований. Имея базовый набор операций над битовыми матрица¬
ми, можно реализовать процедуру выделения на изображении
точек, удовлетворяющих заданному описанию окрестности. Рас¬
смотрим пока только первый способ описания. Пусть ИСХ — ис¬
ходное изображение, РЕЗ — результат.
Бул. оп. 15, РЕЗ, РЕЗ, РЕЗ;
Цикл по небезразличным точкам окрестности:
Сдвиг ИСХ—>ПРОМ;
Если сосед =1 то
Бул. on. 1, ПРОМ, РЕЗ, РЕЗ;
Иначе
Бул. оп. 4, ПРОМ, РЕЗ, РЕЗ;
Конец цикла
Нахождение точек, окрестности которых удовлетворяют по
смежности и контрасту, будет описано ниже.
Преобразование изображения состоит в том, что изменяются
значения изображения в найденных точках. Преобразования, в
которых возможно изменение значений только с 0 на 1, называют¬
ся утолщениями, только с 1 на 0 — утоньшениями. Возможны и
другие типы преобразований, как, например, в игре «Жизнь», где
на одном шаге возможны изменения значений как с 0 на 1, так
и с 1 на 0. Такие преобразования позволяют получать очень кра¬
сивые картинки, но не позволяют для произвольного изображе¬
ния что-либо сказать о поведении последовательности преобразо¬
ваний.
В дальнейшем будем рассматривать только утолщения и утонь-
шения. Последовательность любых утолщений или утоньшений схо¬
дится к пределу. В частности, пределом может быть полное или
пустое изображения. Хотя рассмотренные преобразования учиты¬
вают только минимальную окрестность каждой точки, последо¬
4 Заказ 5620
49
вательности таких преобразований выявляют и нелокальные свой¬
ства, такие, как связность, выпуклость, длина, толщина и т. п.
Важным частным случаем утолщения и утоньшения является
расширение и сжатие. Расширение изображения получается, если
заменить на 1 все нулевые точки, имеющие хотя бы одного еди¬
ничного соседа. Сжатие получается, если заменить на 0 все еди¬
ничные точки, имеющие хотя бы одного нулевого соседа.
Последовательности преобразований, полезные при анализе
битовых изображений. Преобразования на основе расширения и
сжатия. Поскольку мы ограничиваемся рассмотрением только
утолщений и утоньшений, все последовательности преобразований
будут конечными. Количество повторений некоторого преобразо¬
вания может управляться несколькими способами: 1—явное за¬
дание количества повторений, 2 — повторение до установления,
т. е. пока картина не перестанет изменяться (в частном случае
она может стать полностью единичной или нулевой), 3 — повто¬
рение по связным областям, т. е. на очередном повторении рас¬
сматривается картинка, содержащая одну связную область исход¬
ной картинки.
В этом разделе появятся примеры простых алгоритмов. Они
написаны на смеси русского языка и языка анализа изображений,
описанного ниже. В этих примерах знаки +, *, — использованы
для обозначения теоретико-множественных операций объедине¬
ния, пересечения и дополнения и соответствуют булевым опера¬
циям 7, 1 и 2.
Обработку изображений, основанную только на операциях рас¬
ширения и сжатия, удобно рассмотреть отдельно.
1. Реконструкция и выделение связных множеств. Реконструк¬
цией изображения А по изображению Б называется изображе¬
ние Ц, получаемое в результате применения следующего алго¬
ритма:
А*Б->Ц;
Цикл до установления Ц:
Расширение Ц->Ц;
Ц*Б->-Ц;
Конец цикла
Другими словами, реконструкция — это расширение А по мас¬
ке Б до установления. Если некоторое связное множество из Б
содержало хотя бы одну единицу на соответствующем месте в
А, то в Ц это связное множество реконструируется, если на соот¬
ветствующих местах в А нули, то это множество не реконструиру¬
ется.
Операции поиска единицы и реконструкции позволяют выде¬
лять все связные множества изображения. Для этого ищется пер¬
вая единица и реконструируется соответствующее связное мно¬
жество. Затем оно вычитается из исходного изображения и та¬
ким же образом ищется следующее связное множество.
2. Нахождение контуров. Если дано изображение, то наруж¬
ный контур есть разность между расширенным изображением и
50
исходным, а внутренний контур — разность между исходным и
сжатым.
3. Открытие и закрытие. Если изображение сжать Т раз, а
затем расширить Т раз, то полученное изображение называется
Т-открытым. Если изображение сначала расширить Т раз, а по¬
том сжать Т раз, то полученное изображение называется Т-закры-
тым. Открытое изображение содержится в исходном, закрытое
содержит исходное. Повторное применение операции открытия и
закрытия с тем же или меньшим порядком не изменяет резуль¬
тата. Открытие изображения есть закрытие фона и наоборот.
Использование этих операций разнообразно. Открытие при
увеличивающихся порядках дает все более сглаженные внутрен¬
ние области фигур, позволяет разделить области, соединение уз¬
кими перемычками.
Зависимость количества точек, исчезающих при открытиях с
увеличивающимся порядком, от порядка открытия называется
распределением по размерам и позволяет получить обобщенную
характеристику пористости или гранулярности изображения ,[20].
Это распределение показывает, какая доля площади приходится
на данную толщину.
Закрытие, наоборот, сливает близко лежащие области, дает
сглаженную оболочку исходных областей, позволяет из отдель¬
ных точек формировать кластеры.
4. Анализ связности. Операций расширения и сжатия доста¬
точно, чтобы различать множества точек, обладающие различ¬
ной связностью. Можно выделять связные множества без дыр,
связные множества с одной или несколькими дырами, связ¬
ные множества с дырами, в которых есть другие множества, и т. д.
Практически важным является заполнение дыр в связных мно¬
жествах.
5. Фильтрация по толщине. Толщиной связного множества на¬
зывается количество сжатий, за которое это множество исчезает.
Одной и той же толщине соответствуют различные формы: от
круга до ленты с отростками. Для круга толщина примерно со¬
ответствует радиусу с точностью до одной точки. Диаметрам 1
и 2 соответствует толщина 1, диаметрам 3— и 4 — толщина 2 и
т. д. Толщина представляет собой наиболее легко вычислимую
характеристику размера фигуры.
Использование этой характеристики удобно производить при
помощи фильтра толщины. Фильтрацией по толщине называется
процедура, которая сохраняет на изображении связные множества
в заданном диапазоне толщины и уничтожает все другие. При¬
веденный ниже алгоритм отфильтровывает множества в диапа¬
зоне толщины Т1—Т2.
Сжатие ИСХ (Т1 —1) раз+РЕЗ-^ПРОМ;
Реконструкция РЕЗ по ИСХ->РЕЗ;
Сжатие ПРОМ (Т2 — Т1-|-1) раз->ПРОМ;
Реконструкция ПРОМ по ИСХ->ПРОМ;
РЕЗ —ПРОМ+РЕЗ;
4*
51
Рис. 2. Фильтрация связных множеств по толщине. Отрост¬
ки и впадины. Множества, имеющие разную толщину, изоб¬
ражены разными символами. Отростки единичной толщины
показаны большими точками, а впадины единичной толщи¬
ны — маленькими точками
ZZZZZZZZZZZZZZZZZZZZZZZXZZZZ
ZZZZZZZZZZZZZ
zzzzzzzzzz
ZZZ/Z
zzzzzz
ZZZZZZ
zzzzzz
/zzzzzzzzzz
/✓✓zzzzzzzzzz
/✓ZZZZZZZZZZ
Рис. 3. Выпуклые оболочки и зоны влияния. Исходные мно¬
жества черны-?. Выпуклые оболочки- показаны наклонными
линиями. Границы областей влияния показаны треугольни¬
ками
52
Рис. 4. Скелеты множеств при разных описаниях окрестнос¬
ти. Черным показан скелет, получившийся при описании:
0 1 1 1 1 2 0 0; треугольниками показаны участки скелета при
описании: 0 2 1 1 1 1 0 0, не совпадающие с первым скелетом;
наклонными чертами показаны участки скелета при смеж¬
ности от 4 до 5 и контрасте 2, не совпадающие с первыми
двумя; полоса шириной 3 вокруг скелетов — белая, фон —
серый
Пример фильтрации по толщине дай на рис. 2.
Последовательности преобразований, полезные при анализе би¬
товых изображений. Преобразования на основе описания окрест¬
ности. Утолщение и утоньшение на основе двух рассмотренных
выше способов описания окрестности позволяют выявлять более
тонкие свойства изображений, чем расширение и сжатие.
Например, утоньшение до установления при смежности от 1
до 2 и контрасте 2 ликвидирует отростки единичной толщины, а
утолщение до установления при смежности от 6 до 7 и контрас¬
те 2 заполняет впадины единичной толщины (рис. 2). Однократ¬
ное применение этих преобразований выявляет концевые точки
отростков и впадин.
Утолщение до установления при смежности от 4 до 8 (для
8-точечной окрестности) и контрасте от 0 до 2 дает выпуклую обо¬
лочку (рис. 3), которая для этой окрестности будет восьмиуголь¬
ником. При этом поскольку задай контраст не больше 2, выпук¬
лые оболочки близлежащих множеств не сольются (правда, тогда
они могут не быть выпуклыми в этих местах). При соответствую¬
щих описаниях для 4-точечной и 6-точечной окрестностей выпук¬
лые оболочки будут четырех- и шестиугольниками.
Если в предыдущем описании разрешить утолщения, начиная
со смежности 3, то получатся зоны влияния исходных множеств.
53
Утоыыиение до установления при смежности от 4 до 5 и конт¬
расте 2 дает скелет изображения (рис. 4).
В приведенных примерах использовано описание окрестности
при помощи смежности и контраста. Это удобно, поскольку тре¬
бовалось выполнить изотропные преобразования, т. е. преобразо¬
вания, не зависящие от направления. Почти такие же результа¬
ты можно получить, используя описание окрестности при помощи
нулей, единиц и безразличных элементов, если на каждом шаге
преобразования использовать все повороты описания окрестности.
Области влияния можно получить при утолщении до установления
с таким описанием 8-точечной окрестности: 02 1 1 1 20 0 (рис. 3).
Скелет можно получить при утоньшении до установления с опи¬
саниями 0 1 1 1 1 200 или 02 1 1 1 1 00 (рис. 4). Использование
этого способа описания окрестности позволяет, кроме того, выяв¬
лять свойства, зависящие от направления.
Каждый способ описания окрестности имеет свои преимущест¬
ва и недостатки. Явное задание элементов окрестности позволяет
выявлять свойства, зависящие от направления, но для выявления
изотропных характеристик требует повторного применения для
каждого поворота на каждом шаге, и, естественно, результат за¬
висит от порядка поворотов, т. е. от начального описания и на¬
правления поворота. Кроме того, не всегда одним описанием
можно задать требуемую ситуацию, например, нельзя таким об¬
разом задать окрестность со смежностью от 3 до 6 при контрас¬
те 2.
Задание окрестности при помощи смежности и контраста на¬
глядно, симметрично и изотропно, но оно более сложно реализу¬
ется и требует большого времени вычисления. Главное то, что при
таком описании нельзя на одном шаге делать изменения в сосед¬
них точках. Это иногда приводит к тому, что требуется большее
количество шагов до установления (например, при вычислении
скелетов и областей влияния), а результат зависит от способа,
которым реализован этот запрет.
Представление полутоновых изображений. 1. Слойки. Рельефы.
Будем называть полутоновым изображение, в котором для пред¬
ставления каждой точки требуется больше одного бита. Реальные
изображения внешнего мира обычно полутоновые. Наиболее рас¬
пространенный способ представления полутоновых изображений
состоит в том, что биты, соответствующие одной точке, расположе¬
ны компактно, причем их количество зависит как от требуемой
точности представления изображения, так и от характеристик ма¬
шины — разрядности байта и слова, имеющихся команд для их
обработки.
Нами принят другой способ представления полутоновых изоб¬
ражений. Изображение представлено трехмерной битовой матри¬
цей, в которой первый слой соответствует младшим битам двоич¬
ного представления яркости всех точек изображения и т. д., а
последний слой соответствует старшим битам этого представле¬
54
ния. Другими словами, слой трехмерной битовой матрицы — это
разрядная плоскость изображения.
При таком представлении плотно расположены точки изобра¬
жения, а не коды яркостей в этих точках. При нехватке памяти в
первом случае изображение разбивают на зоны, а во втором — на
разряды, что намного удобнее при операциях, связанных с сосед¬
ством.
Трехмерные битовые матрицы, в которых слои соответствуют
разрядным плоскостям изображения, будем называть слойками.
Важное преимущество послойных представлений состоит в
том, что они вовсе не обязаны быть изображениями внешнего
мира с известной точностью представления. Ниже будет дано
несколько примеров, когда слойками моделируются некоторые
функции исходных изображений, причем в процессе работы ко¬
личество битов на точку может меняться в широких пределах. При
послойном представлении при условии динамического распреде¬
ления памяти добавление и исключение разрядных плоскостей дос¬
тигается просто и не затрагивает уже сформированных плоскос¬
тей.
Для привлечения геометрической интуиции двумерные изо¬
бражения с переменной яркостью удобно представлять себе как
рельефы, в которых третья координата соответствует яркости. Та¬
кое представление позволяет использовать геометрические и топо¬
графические соображения при проектировании алгоритмов.
2. Функции или множества. Функцию от двух переменных мож¬
но рассматривать как множество в трехмерном пространстве. Пе¬
реход от функций к множествам осуществляется с использованием
понятия тени. На рис. 5 показаны график функции и ее тень.
Если максимальное значение функции равно Н (целое), то
для представления в машине множества, соответствующего тени
функции, требуется Н слоев, а не LogH, как для представления
слойкой. Рассмотрим преимущества и недостатки обоих представ¬
лений.
Множества. Преимуществом является то, что для обработ¬
ки трехмерных множеств в принципе достаточно тех же или ана¬
логичных средств, которые были рассмотрены выше для двумер¬
ных изображений. Недостатки такого представления следующие:
а) слишком большой по сегодняшним меркам расход памяти;
::::;ш:
... *шшш*
.шшшшшшшшшшшшш.
.. * *
....... . .шшшшшшшшшшшшшшшш....
..шшшшшшшшшшшшшшшшшшшш....
Рис. 5. График функции и ее тень
55
б) поскольку требуется по-разному рассматривать две пространст¬
венные и одну яркостную координату, полной однородности до¬
биться не удается; в) тяжеловесное описание окрестности в трех¬
мерном пространстве.
Функции. Преимущества: а) экономное представление;
б) возможность одинакового описания окрестности для булевых
и полутоновых изображений и, как следствие этого, две серии опе¬
раций над булевыми и полутоновыми изображениями. Недоста¬
ток—нетривиальное расширение базового набора операций на
слойки.
В дальнейшем будем пользоваться терминами «полутоновое
изображение», «рельеф», «слойка» как синонимами в зависимости
от того, какой аспект нужно подчеркнуть: визуальное восприятие,
топографические характеристики или машинное представление.
Операции со слойками рассмотрим в три этапа: 1—операции, в
которых участвует одна слойка и одна булева матрица; 2 — опе¬
рации над двумя слойками — аргументами с получением в качест¬
ве результата слойки или булевой матрицы; 3 — обобщение опера¬
ций утолщения и утопыиения на слойки.
Операции с одной слойкой
1. След и маскировка. Простейшими операциями со слойкой
являются след и маскировка. Следом называется битовая матри¬
ца, содержащая единицы в точках, где слойка больше 0 и нули в
точках, где слойка равна 0. След можно получить дизъюнкцией
всех слоев. Маскировкой называется операция, обнуляющая все
точки слойки, где значение битовой маски равно 0, и оставляющая
неизменными остальные точки. Маскировка получается конъюнк¬
цией каждого слоя с маской.
2. Арифметическое сложение слойки и булевой матрицы. Эта
операция представляет собой арифметическое сложение кода яр¬
кости изображения с битовой переменной в каждой точке изобра¬
жения. Алгоритм этой операции здесь приводить не будем, так
как в дальнейшем будут рассмотрены более общие алгоритмы
арифметических операций над слойками.
3. Срез по уровню. Срезом слойки по уровню Т называется
булева матрица, содержащая единицы в точках, где значение
слойки > = Т и нули в остальных точках. Срез по уровню реали¬
зуется следующим алгоритмом.
Пусть Т —битовый массив, содержащий двоичное представ¬
ление уровня среза; ИСХ — исходная слойка; РЕЗ — искомый ре¬
зультат: ПРОМ, БОЛ, МЕН —битовые матрицы для промежуточ¬
ных результатов. Матрица БОЛ содержит нули везде, где уже
известно, что слойка > уровня Т, и единицы в остальных точках.
Матрица МЕН содержит нули везде, где уже известно, что слой¬
ка < Т, и единицы в остальных точках. Идея алгоритма состоит
56
в постепенном уменьшении неопределенности по мере рассмотре¬
ния слоев и двоичного представления уровня среза от старших
разрядов к младшим.
«1»->БОЛ^МЕН;
Цикл по слоям от старших к младшим:
Тек. слой ИСХ->ПРОМ;
Если очередной бит Т=0 то
ПРОМ*БОЛ->ПРОМ;
ПРОМ*МЕН->ПРОМ;
БОЛ — ПРОМ-+БОЛ;
Иначе
БОЛ — ПРОМ->ПРОМ;
ПРОМ*МЕН->ПРОМ;
МЕН — ПРОМ->МЕН;
Конец если
Конец цикла
МЕН->РЕЗ;
4. Другие срезы. В таком же стиле реализуются и другие сре¬
зы, например срез по площади. Срезом по площади называется
срез по наибольшему возможному уровню, дающему в результи¬
рующей битовой матрице не менее заданного количества единиц.
Комбинируя два среза по разным уровням, можно получить дву¬
сторонний срез.
Может представить интерес также нахождение абсолютных
максимума и минимума в слойке.
Важно отметить, что все рассматриваемые алгоритмы дают ре¬
зультат, относящийся к уровню, но при этом рассматривают толь¬
ко разрядные плоскости. Все эти алгоритмы содержат цикл по
слоям (их количество равно двоичному логарифму от максималь¬
ного количества уровней и обычно < = 8), в котором выполняет¬
ся несколько операций базового набора для битовых матриц.
5. Вычисление смежности и контраста. Теперь у нас достаточ¬
но средств, чтобы описать нахождение точек, удовлетворяющих за¬
данным условиям для смежности и контраста.
Рассмотрим сначала вычисление количества единичных сосе¬
дей. Для принятых шаблонов соседства каждая точка может
иметь не более 8 единичных соседей. Сформируем слойку, в ко¬
торой будет представлено количество единичных соседей для каж¬
дой точки. Ясно, что в этой слойке достаточно иметь 4 слоя. Вна¬
чале слойка нулевая. В цикле по всем соседям будем сдвигать
исходную матрицу и добавлять ее к слойке. К полученной слойке
применим срез по уровню (или уровням), задающий допустимый
диапазон для количества единичных соседей. Полученная бито¬
вая матрица содержит единицы в точках, обладающих смеж¬
ностью в заданном диапазоне.
Для вычисления контраста достаточно иметь слойку из трех
слоев, так как можно учитывать переходы только с 0 па 1 (об¬
ратных переходов столько же, максимум 4). При вычислении конт¬
раста обязательно обходить окрестность по часовой стрелке или
против часовой стрелки (для смежности — можно в любом поряд¬
57
ке). На каждом шаге к формируемой слойке добавляется матри¬
ца, полученная из двух предыдущих сдвигов и содержащая еди¬
ницы в местах перехода с 0 на 1. Когда слойка получена, к ней
аналогичным образом применяются срезы.
Конъюнкция двух полученных масок дает точки, подходящие
по смежности и контрасту. Обе указанные слойки формируют¬
ся в одном цикле обхода окрестности.
В этом примере интересно, что для решения «чисто булевой»
задачи использован аппарат слоек. Кроме того, понятие слойки,
которое было введено для представления изображений, использо¬
вано здесь для представления некоторых функций от элементов
изображения, не связанных с визуальным восприятием. Такие при¬
меры встретятся и в дальнейшем.
Операции с двумя слойками Г
1. Арифметика. Наиболее употребительными арифметическими
операциями со слойками являются сложение, вычитание и умно¬
жение на константу. Слойка позволяет закодировать только це¬
лые положительные числа, но количество разрядов (слоев) можно
считать переменным — таким, какое нужно в данный момент. Это
накладывает определенную специфику на арифметические опе¬
рации. Для примера рассмотрим алгоритм вычитания слоек.
Пусть даны слойки УМЕНЬШАЕМОЕ и ВЫЧИТАЕМОЕ. Тре¬
буется найти слойку РЕЗУЛЬТАТ по формуле
(УМЕНЬШАЕМОЕ — ВЫЧИТАЕМОЕ)шах 0.
Потребуются булевы матрицы ПЕРЕНОС, РАЗНОСТЬ, А1
и А2 соответствующего размера.
Знаком * будем обозначать операцию сложения по модулю 2,
т. е. булеву операцию номер 6. Знаки +, —, *, используемые с
аргументами-слойками, означают обычные арифметические опе¬
рации, а используемые с булевыми матрицами — означают теоре¬
тико-множественные операции,
! Вычисление разности;
«0»->ПЕРЕНОС;
Цикл по слоям от младших к старшим:
Тек. слой УМЕНЫИАЕМОЕ->А1;
Тек. слой ВЫЧИТАЕМОЕ+А2;
А1#А2+РАЗНОСТЬ;
(РАЗНОСТЬ#ПЕРЕНОС)->РАЗНОСТЬ->Тек. слой РЕЗУЛЬТАТ;
(А2 — А1) + (РАЗНОСТЬ*ПЕРЕНОС)->ПЕРЕНОС;
Конец цикла
1 Обнуление точек, где УМЕНЬШАЕМОЕ< ВЫЧИТАЕМОЕ, т. е.
где ПЕРЕНОС не равен 0;
Цикл по слоям результата:
Тек. слой РЕЗУЛЬТАТ — ПЕРЕНОС->Тек. слой РЕЗУЛЬТАТ;
Конец цикла
1 Если нужна нормализация, то отбросить старшие нулевые слои, если они есть;
58
Этот алгоритм легко распространить на случай, когда аргу¬
менты имеют разное количество слоев и когда один из аргумен¬
тов— число. Тогда, вычитая из константы (2**кол. слоев— 1) дан¬
ную слойку, получим ее инверсию.
Наша ближайшая задача — обобщить введенные выше для бу¬
левых матриц операции пересечения, объединения, утолщения,
утоньшения, расширения и сжатия на слойки и выяснить, какие
операции допускают естественное обобщение, а какие требуют ис¬
пользования специальных приемов. Способы обобщения будут рас¬
смотрены далее, а пока, чтобы не нарушать структуру изложения,
введем несколько операций над слойками, которые потребуются в
дальнейшем.
2. Сравнение и слияние слоек по маске. Пусть даны две слой¬
ки. Операция сравнения дает две булевы матрицы: первая содер¬
жит единицы в точках, где первая слойка < = второй, а вторая —
где первая слойка > = второй.
Пусть даны две слойки и булева матрица (маска). Операция
слияния по маске дает слойку, в которой значения взяты из пер¬
вой или второй слойки в зависимости от значения маски в со¬
ответствующей точке (если маска = 1, то из первой, если мас¬
ка = 0, то из второй).
3. Минимум и максимум. Используя операции сравнения и
слияния, можно реализовать операции поэлементных максимума
и минимума. Пусть даны две слойки. Операция максимума (мини¬
мума) дает слойку, содержащую в каждой точке значение, равное
максимуму (минимуму) из значений данных слоек в соответст¬
вующей точке.
Заметим еще раз, что все эти операции реализуются алгорит¬
мами, содержащими цикл по разрядным слоям, а не по всему
диапазону значений в слойках.
4. Обобщение операций над булевыми матрицами. Обозначим
через С(Т,А) срез слойки А по уровню Т. Обобщение операций над
булевыми матрицами на слойки мы понимаем следующим обра¬
зом. Пусть F — операция над несколькими булевыми матрицами.
Операция Ф над таким же количеством слоек называется обоб¬
щением операции F, если для любого уровня Т:
С (Т, Ф (А1 Ак) ) =F (С ( Т,А1) , , С(Т, Ак) )
Другими словами, в этом случае, работая со слойкой, т. е. с
разрядными плоскостями, можно получить тот же результат, что
и при выполнении операции на каждом уровневом срезе. Ясно, что
если удается обобщить таким образом какую-то операцию, то это
дает заметный выигрыш в скорости.
Обобщение логических операций на слойки. Докажем, что мак¬
симум есть обобщение операции объединения, а минимум — обоб¬
щение операции пересечения. Пусть: А1 и А2 — слойки, Т — произ¬
вольный уровень, по которому производится срез:
59
1) А1
<Т
<т
>=т
>=т
2) А2
<Т
>=т
<т
>=т
3) Al Max А2
<т
>=т
>=т
>=т
4) С (T,AI Max А2)
0
1
1
1
5) С (Т,А1)
0
0
1
1
6) С (Т,А2)
0
1
0
1
7) С(Т,А1) +С(Т,А2)
0
1
1
1
Совпадение строк
4 и
7 в приведенной таблице истинности до-
называет сформулированное положение. Аналогичное доказатель¬
ство можно провести и для минимума.
Хуже обстоит дело с инверсией, так как не существует такой
операции со слойкой, чтобы в результате на каждом уровне полу¬
чить инверсии соответствующих булевых матриц. Для иллюст¬
рации этого обратимся к геометрическому представлению. Слой¬
кой представлена функция или (что то же самое) множество, яв¬
ляющееся ее тенью. Инверсия каждого уровня есть дополнение
этого множества, но оно уже не является тенью, следовательно,
не может быть представлено слойкой.
Таким образом, ясно, что строго обобщить на слойки можно
только те операции с булевыми матрицами, где не используется
инверсия.
Морфологические операции со слойками, основанные на рас¬
ширении и сжатии. Для булевых матриц расширение (сжатие)
есть объединение (пересечение) матрицы и всех ее сдвигов, сле¬
довательно, для слоек расширение (сжатие) есть максимум (ми¬
нимум) из слойки и всех ее сдвигов.
Действие расширения и сжатия на рельеф аналогично дейст¬
вию на битовые картинки. Сжатие убирает мелкие детали, как
бы снимает шелуху с поверхности рельефа, при этом его высота
уменьшается везде, кроме плоских участков и локальных мини¬
мумов, где она не изменяется. Расширение, напротив, замазывает
рельеф, при этом его высота увеличивается везде, кроме плоских
участков и локальных максимумов, в которых она не изменяется
(рис. 6).
1. Открытие и закрытие. Гранулярный спектр. Использование
открытий и закрытий позволяет определить интересную метриче¬
скую характеристику рельефов.
Так же, как и для битовых изображений, отрытый рельеф со¬
держится в исходном, а закрытый рельеф содержит исходный.
Рис. 6 Разрезы рельефов: исходного, расширенного 2 раза
и сжатого 2 раза
60
Объемом рельефа называется сумма значений яркостей по всем
точкам изображения. При одном и том же объеме рельефы мо¬
гут иметь совершенно разный вид: это может быть одна большая
гора (одно яркое пятно) или множество мелких пиков (много свет¬
лых точек), или более сложные формы.
Гранулярным спектром называется функция от Т (Т > = 1):
Ф(Т) = (объем Т—1 открытого рельефа — объем Т открытого рельефа)/
объем рельефа
Эта функция введена в работе ,[20] и так же, как и для бито¬
вых изображений, называется распределением по размерам. Наше
название представляется более адекватным и будет использовать¬
ся в дальнейшем.
Таким образом, гранулярный спектр — это доля объема, прихо¬
дящаяся на данный характеристический размер, точнее, на данную
толщину.
Определенный таким образом гранулярный спектр ничего не
говорит о форме пиков и характере их расположения на рельефе.
О характере расположения пиков дает информацию аналогичная
функция, использующая не открытие, а закрытие или (что то же
самое) открытие инверсного изображения. Эту функцию можно
интерпретировать как гранулярный спектр впадин рельефа.
Для оценки формы только операций расширения и сжатия
рельефа недостаточно.
Используя гранулярный спектр, естественно ввести понятие
эквивалентного рельефа как наиболее «простого» рельефа, имею¬
щего данный гранулярный спектр. Рельеф, имеющий ненулевое
значение спектра только при одной толщине, — это цилиндр (на
дискретной сетке — ромб, квадрат или шестиугольник в зависи¬
мости от вида соседства), имеющий данную толщину. Тогда экви¬
валентный рельеф можно изобразить, как показано на рис. 7. Гра¬
нулярный спектр может быть представлен в двух формах: как
спектр объемов и как спектр высот.
2. Реконструкция. Как и для битовых изображений, реконст¬
рукцией рельефа А по рельефу Б называется расширение А по
маске Б до установления. Алгоритм, приведенный на с. 50,
пригоден для рельефов.
Результаты реконструкции битовых и полутоновых изображе¬
ний приведены на рис. 8.
Битовые изображения восстанавливаются полностью и неза¬
висимо от начального состояния или не восстанавливаются вооб¬
ще. Для рельефов результат реконструкции зависит от началь¬
ного состояния, в частности, восстановленный рельеф не может
быть выше максимальной точки исходного.
В зависимости от типа исходного рельефа операция реконст¬
рукции может иметь различные интерпретации, которые будут
Рассмотрены ниже.
61
3. Срез по толщине. Срезом по толщине Т рельефа П назы¬
вается битовая матрица С, получающаяся в результате следую¬
щего алгоритма:
Сжатие П (Т раз) —> Ж;
Реконструкция Ж и П >Р;
П-Р > Д;
След Д > С;
Иллюстрация работы этого алгоритма дана на рис. 9.
Очевидно, что в результирующей битовой матрице содержатся
множества, чья толщина не больше, чем Т. Приведенный алго¬
ритм как бы срезает горбушки с рельефа, но так; что толщина их
и
и
и
и
и
и
и
11
11
ВЕРТИКАЛЬНЫЕ РАЗРЕЗЫ
11
11
РЕЛЬЕФОВ
11
11
11
11
11
2222
11
2222
11
2222
11
2222
11
333333
И
333333
2222
333333
2222
333333
2222
44444444
2222
44444444
333333
44444444
333333
о
Б
Ъ
Е
М
СПЕКТРЫ СБЬЕМОВ
В
ы
с
о
т
А
222 333 444
222 333 444
222 333 444
111 222 333 444
ТОЛЩИНА
111 222 333 444
111 222 333 444
111 222 333 444
111 222 333 444
СПЕКТРЫ ВЫСОТ
111
111
111 222 333 444
111
111
111
111
111
111
111
111
111
111
111 222
111 222 333 444
111 222
111 222 333 444
111 222 333
111 222 333 444
ТОЛЩИНА
111 222 333 444
Рис. 7. Примеры двух рельефов п соответствующих
им спектров объемов и высот
62
...шшшшшшш
...шшшшшшш
..шшшшш..
.. жжж
.шшшшшш. .
жжжжжж.. . .
,шшшшшшш
. .жжжжжж.. .
,.шшшшшш.
...шшшшш.
. ztVT\/TVT\/T\ . . . .
....шшш. . .
i /Tvm/iVTx/ix. . .
Ill
жжж.
Б
шшшшшшш
шшшшшшш
. .1.. шшшшш
шшшшшш
шшшшшшш
шшшшшш
шшшшш
шшш
ш ... .
ц
А
1
..шшш .
... шшш
...шш
... 1..
• пп . .
..шшшш .
... шшш .
.шшшш
.. . 1 ..
пппп
..шшшш. ,
.. шшшш . .
. шшшш
... 1..
пппп.
.. шшшш .
. шшшш .
.шшшш
... 1..
пппп.
..шшшш ,
. . ШШШШ : .
шшшшш
.. 1...
...1..
ПППП..ППППП
.шшшшш .
.. шшшшш
.шшшшш
.. 1...
... 1..
ППППП ППППП
.шшшшш ,
.. шшшшш
. шшшшш
.. 1...
... 1..
ППППП ППППП
.шшшшш ,
.. шшшшш
.шшшшш
.. 1...
... 1..
■ ППППП. ППППП
шшшшшш
.. шшшшш
.шшшшш
.. 1...
...1..
ППППП.ППППП
1шишшшшшшшшшшшшшшшшш .111...
.. 1...
... 1..
ППППППППППППППППППЛ
Б
ц
Рис. 8. Реконструкция битовых и полутоновых изображений: изображе¬
ние А реконструируется по изображению Б, результатом является
изображение Ц (рельеф представлен вертикальным разрезом)
п.
ппп
ППППП . . .
ППППППП..
. п
ППППППППП .
ППП
ППППППППППП
....ППППП
ПППППППППППП
...ППППППП. .
. .ППППППППППППП
..ППППППППП . .
. . .ПППППППППППППП
.ППППППППППП.
. ППППППППППППППП
лппппппппплпппппппппппппппппп
.. ж. . .
жжж. .
V/\l/
t , , Л\/Тл/Т\Л\л\ •
.. .жжжжжжж
ж жжжжжжжж
жжж жжжжжжжжж
.... жжжжж жжжжжжжжжж
...жжжжжжжжжжжжжжжжжжжжжжжж
ррррррр..
ррррррррр.
'.. ррррррррррр
рррррррррррр
... ррррррр ррррррррррррр
.. ррррррррр... .рррррррррррррр
. ррррррррррр. .ррррррррррррррр
ррррррррррррррррррррррррррррр
д д
ддд ДДД ■ • •.
.... ДДДДД ДДДДД ...
....ссссс
ссссс. ..
Рис. 9. Иллюстрациия к алгоритму среза по толщине (Т = 3)
63
проекций не больше заданной. Отсюда и название этой опера¬
ции— срез по толщине. При этом безразлично, па какой высоте
находится горбушка.
В алгоритмах обработки изображений можно использовать не
только результирующее битовое изображение, ио и полутоновое
изображение Д, которое является специфической мерой контрас¬
та. Можно также использовать битовые изображения, в которых
есть только следы от горбушек, чья высота не меньше заданной.
В срезе по толщине могут оказаться множества и меньшей
толщины, чем Т. На рис. 10 показаны рельеф и таблица резуль¬
тирующих толщин полученных множеств в зависимости от задан¬
ной толщины среза:
Рельеф Заданная толщина Полученная толщина
....111111....
....111111....
....НИИ....
1, 2
3, 4, 5
Пусто
3
.111111111111.
.111111111111.
> = 6
6
Рис. 10. Рельеф и таблица толщины срезов
Срез по толщине находит применение при сегментации изобра¬
жений.
4. Заполнение впадин. Эта операция аналогична заполнению
дыр для битовых изображений. Ее можно представить себе так:
пусть на рельеф сверху падает дождь. Вода заполнит все впади¬
ны и дальше будет переливаться через края. Заполнение впадин
на рельефе Л (рис. 11) реализует следующий алгоритм:
Инверсия А ->Б;
Рамка >Р;
Реконструкции Р по Б >Ц;
Инверсия Ц ^Д;
..аа. . .
. .база .;.
. ..аза.. .
■ .ааааа ..
. . .еааа. .
. .аваааа^..
. .азгааа.
♦аааааааа.
.аааааааа
.аааааааааааааааааа
. агаааааазааазааааа
.аааааааааааааааааа
aaaaaaaaasaaaaaaaaa
б. ..
б. ..
б. .1
б.. „
бб..
:. .бббб...
,.. .6
бб..
. .бббббб.,
.. .бб
бб..
.ббббббб.,
, .ббб
ббб
.бббббббббббббб
ббббббббббббббббббб
р
.р
р
р
р
р
р
,р
р
р
р .,,...
р
р
р
р
р
р
р
р
р
ц
ц.... ■
ц.. . ,
цц...
Ц
цц.. •
ЦЦ
ЦЦ. . .
ЦЦЦ;
ццц..
цццццццццццццц;
ЦЦЦЩ
.|Щ?Ц!!ЦЦЦЦЦЦЦЦЦЦ
...дд
..дддддддддддддд . . .
..ддддддддддддддд ..
..дддддддддддддддд.
.дддддддддддддддддд
.дддддддддддддддддд
. .оддддддддддддддддд
. ДДДДДДДДДДДДДДДДДД
ДД.Д ДДДДДДДДДДДДДДДД
Рис. 11. Иллюстрация к алгоритму заполнения впадин
64
(Рамка — это рельеф, у которого на границе максимальное зна¬
чение, а во внутренних точках — нули).
В этом параграфе приведены некоторые морфологические опе¬
рации со слойками, основанные только на расширении и сжатии.
Они являются обобщением соответствующих операций над буле¬
выми матрицами. Если произведена некоторая операция над рель¬
ефом, т. е. над К-разрядными плоскостями, то эта же операция
выполнилась и для любого уровня (которых 2**К). Например,
если на рельефе заполнены впадины, то ни на одном уровне не
будет множеств с дырками.
Однако важность перехода от операций с битовыми матрица¬
ми к операциям с рельефами не только в увеличении скорости.
При этом привлекается к работе богатая геометрическая интуи¬
ция, которая помогает проектировать алгоритмы. Возникают но¬
вые понятия, которые было бы трудно сформулировать в «чисто
битовых» терминах и которые не были бы наглядны, например,
срез по толщине.
Общий случай утолщения и утоныиения на слойках. Утолще¬
нием называется операция, при которой значение слойки в каж¬
дой точке не уменьшается, а утоньшением называется операция,
при которой значение слойки в каждой точке не увеличивается.
В случае битовых изображений значение или не изменялось, или
изменялось только с 0 на 1 при утолщении, или только с 1 на
О — при утоньшении. В случае полутоновых изображений изме¬
нение значения может происходить не единственным образом.
Кроме того, в битовом случае были однозначно определены еди¬
ничный и нулевой соседи (хотя способы описания окрестности
могут быть разные).
Для полутоновых изображений можно придумать большое
количество способов изменения значения в зависимости от значе¬
ний в соседних точках. Для упорядочения этих способов обра¬
тимся к представлению полутонового изображения как множест¬
ва точек в трехмерном пространстве (тень).
Через каждую точку рельефа можно провести три взаимно
перпендикулярные плоскости, параллельные координатным. Раз¬
рез рельефа каждой из этих плоскостей дает битовую матрицу.
Сведение анализа окрестности на рельефе к анализу одной или
нескольких из этих битовых матриц делает эту задачу обозри¬
мой. Наиболее важные результаты получаются при анализе раз¬
реза, параллельного основанию рельефа. Почти все дальнейшее
изложение посвящено этому случаю. Если не оговорено особо, то
утоньшение и утолщение рельефа определяются исходя из гори¬
зонтального разреза.
Сосед данной (опорной) точки называется единичным, если в
нем значение рельефа больше, чем в опорной точке. Сосед на¬
зывается нулевым, если в нем значение рельефа меньше, чем в
опорной точке. Если значение рельефа в соседней точке равно
значению в опорной, то для утолщения сосед считается нулевым,
а для утоньшения — единичным.
5 Заказ 5620
65
Рис. 12. Рельеф, образованный из наклонной плоскости и конусов,
направленных вверх и вниз
/\ /11\
/114 /11114
/11114 /1111114
/111111S/11111111\ /1 .
/111111111111111111S /1111
/111111111111111111114=/111111
/11
/111
/11114 /1111
1111114 /11111
11111114 Д /111111
11111114 /114/1111111
111111114/111111111111
/11111111111111111111111111111 .11111111111111111111111
11111111111111111111111111111111 .11111111111111111111111
Рис. 13. Разрез рельефа, показанного на рис. 12. Горизон¬
тальная линия показывает вид рельефа после заполнения
впадин
Изменение значений слойки происходит следующим образом:
при утолщении значение заменяется на минимум из единичных
соседей, а при утоньшении — на максимум из нулевых ,[20].
Как и для битовых изображений, окрестность можно задать
при помощи нулевых, единичных и безразличных элементов или
при помощи смежности и контраста. При задании смежности и
контраста нельзя на одном шаге производить изменения в сосед¬
них точках, если значения в них были одинаковыми.
Нахождение топографических характеристик рельефов. Харак¬
терные точки, линии и области земной поверхности, такие, как
пики, впадины, хребты, овраги, озера, кратеры, холмы, водораз¬
делы, седловины, каналы и т. п., — издавна применяются для то¬
пографической характеристики рельефов. Они хороши тем, что
дают очень компактное и наглядное описание рельефа, намного
более полезное в прикладных дисциплинах, чем, например, анали¬
тическое задание высоты как функции двух координат. Причина
63
этого в том, что содержательно наиболее важную информацию
дают места нарушения непрерывности свойств.
Рассмотрим рельеф, представленный на рис. 12. Он составлен
из наклонной плоскости и конусов, направленных вверх и вниз.
На рис. 13 показан разрез этого рельефа вдоль диагонали, иду¬
щей из левого нижнего угла в правый верхний.
Для нахождения холмов и впадин использована процедура за¬
полнения впадин, описанная на с. 64—65. Она применена к ис¬
ходному (рис. 13) и инвертированному (рис. 14) рельефам. На
рис. 15 дано топографическое описание этого рельефа. Овраги и
хребты здесь получены как границы между впадинами и холма¬
ми. Пики и стоки получены при помощи среза по толщине 1. За¬
метим, что этот результат получен при использовании операций,
основанных только на расширении и сжатии.
Для нахождения таких характеристик рельефов, как раздели¬
тельные линии областей влияния, водоразделы, седловые точки,
2\
22 \
222\
2222 \
22222\ А
222222\ /22\
2222222S /2222S
22222222S/222222S
Z=S
/2222\
—Z222222S.
/2222222 . 2\
/2222222 . 2222S
А
/22S—А
/2222\/22S
/2222222222S
/222222222222S
/22222222 . 222222\=/22222222222222S
22222222222222222S/2222222222 . 22222222222222222222222222
Рис. 14. Разрез инвертированного рельефа и заполнение
впадин
Рис. 15. Топографическое описание рельефа, показанного на
рис. 12. Холмы показаны наклонными линиями, идущими из
левого верхнего угла в правый нижний. Впадины показа¬
ны линиями, идущими из левого нижнего угла в правый
верхний. Пики — черные точки, стоки — белые. Впадина в
холме показана квадратиками, холм во впадине — крестика¬
ми. Хребты и овраги выглядят как черные контуры.
5*
67
П П П * ***#*»♦*»«<•** ***********
Г1ППППП 1 .... 2. .3. . *
ППППППППП 11 ... 2. .3 . *
ПППППППППППП 11 . . 2.3 . *
********************п
. ... 3 ... 2 ... 1 ППП
...3...2..11....ППППП
.:.3..2.11...•ППППППП
..3..2 1....ППППППППП
..3.2.1...ппппппппппп
.3/211..ППППППППППППП
.321..ППППППППППППППП
ППППППППППППППП....11.2.3*
ПППППППППППППППППП. ..1123*
ППППППППППППППППППППП..12* *32 1. ппппппппппппппппп
ПППППППППППППППППППППППП1* ППППППППППППППППППППП
ПППППППППППППППППППППППППП ППППППППППППППППППППППП
ПППППППППППППППППППППППППП ППППППППППППППППППППППП
Рис. 16. Утолщение до установления при смежности от 3 до 8
и контрасте 2
нужно использовать общие процедуры утолщения и утоньшения,
как это описано выше.
Рассмотрим подробно нахождение разделительных линий об¬
ластей влияния (они соответствуют водоразделам инвертирован¬
ного изображения). Ранее было описано получение областей влия¬
ния для битовых изображений. Аналогичная процедура утолщения
до установления со смежностью от 3 до 8 и контрастом 2 приво¬
дит к изменению рельефа, как показано на рис. 16.
Выпуклости рельефа расширяются до такой степени, что.меж¬
ду ними остается провал толщиной в 1 элемент. Его можно запол¬
нить при помощи закрытия порядка 1. Вычтя теперь рельеф на
рис. 16 и взяв след, получим битовую картинку с разделительны¬
ми линиями областей влияния.
На нижней части рис. 17 а приведен рельеф, состоящий из
призм и конусов. На рис. 17 6 даны разделительные линии облас¬
тей влияния и водоразделы этого рельефа. Точки пересечения
этих линий являются седловыми.
Функция затухания. Большинство рассмотренных до сих пор
полутоновых изображений были заданы исходно или были эта¬
пами преобразования исходных изображений. Кроме того, коли¬
чество слоев в процессе обработки не изменялось. Рассмотрим
использование слоек как промежуточной структуры данных при
обработке битовых изображений. Пример такого использования
уже был рассмотрен при вычислении смежности и контраста.
Функция затухания для процессов расширения и сжатия рассмат¬
ривается в ,[20].
Пусть задан некоторый процесс утоньшения битового изобра¬
жения (аналогичные рассуждения можно провести и для процес¬
са утолщения). Любой такой процесс доходит до установления
за конечное количество шагов. Пусть также имеется нулевая
слойка такого же размера. На каждом шаге процесса утоньшения
будем арифметически прибавлять текущее битовое изображение
к слойке. В результате каждая точка в слойке кодирует номер
шага, на котором исчезла соответствующая единица в исходном
68
изображении. Такую слойку будем называть функцией затуха¬
ния. С полученной слойкой можно делать все те операции, которые
описаны выше. Использование функций затухания рассмотрим на
примере фильтра длины. Пусть на изображении есть связные мно¬
жества без дырок. Получим скелет изображения, как описано ра¬
нее.
5
рис. 17. В верхней части показан рельеф, состоящий из призм, конусов и
Наклонной плоскости. В нижней части—топографическое описание этого
Рельефа. Хребты показаны черными линиями, овраги — белыми, фон — серый.
Седловые точки находятся на пересечениях хребтов и оврагов
69
Длиной связного множества без дырок назовем количество ша¬
гов подавления концевых точек скелета, после которого скелет
исчезает. Определенная таким образом длина приблизительно со¬
ответствует радиусу описанной окружности.
Если рассматривать связные множества по одному, то можно
фильтровать их прямо по описанной процедуре. Наша задача сос¬
тоит в том, чтобы сделать фильтрацию параллельно, т. е., рабо¬
тая только с полным изображением, оставить на нем те связные
множества, длина которых находится в заданном диапазоне.
Пусть А — исходное битовое изображение, Ф — слойка, в ко¬
торой будет формироваться функция затухания. Требуется по¬
лучить битовую матрицу, в которой есть только множества, име¬
ющие длину в диапазоне .[Д1, Д2]:
«О» —> Ф;
Скелет А —>С;
Цикл до исчерпания С:
Подавить концевые точки С —> С;
С + Ф —>Ф;
Конец цикла
Срез Ф по уровню Д1 —»-ПРОМ1;
Реконструкция ПРОМ1 по А —>ПРОМ1;
Срез Ф по уровню (Д24-1) —ПРОМ2;
Реконструкция ПРОМ2 по А —> ПРОМ2;
ПРОМ1 — ПРОМ2 —> РЕЗУЛЬТАТ;
Максимальное количество слоев, которое может появиться в
слойке Ф, равно двоичному логарифму от максимальной длины
множеств в исходном изображении. На рис. 18 изображены функ¬
ции затухания для описанного процесса.
Для выявления некоторых свойств можно использовать не¬
сколько функций затухания. Рассмотрим, как можно фильтровать
множества по отношению длины к толщине.
Во-первых, нужно построить две функции затухания: для про¬
цесса сжатия — Ф1 и для процесса подавления концевых точек
скелета — Ф2. Затем каждую из этих слоек нужно расширять до
установления по маске исходного битового изображения. Это нуж¬
но сделать для того, чтобы значения функции затухания были
одинаковы на площади каждого связного множества и равны ее
1
124321 -1
.. 5 234567 1 . .
. . . 6 89ABCD 5432...
. . . 7 EFG . .
. . 12345678987654321 —1- Н6543-.
. . . 4 2— 1 —21
3 3 J—.
— 2 -4- : MNONMLK ..
, . -1— -5-... HIJKL
-6 FG
—789АВС
Рис. 18. Примеры слоек, кодирующих функции затухания
для алгоритма фильтрации по длине
70
максимальному значению на данном множестве. Теперь слойку
Ф1 нужно умножить на заданный коэффициент отношения длины
к толщине.
Если требуется выделить множества, для которых Длина
<; = К**Толщина, то результатом является след разности Ф1—Ф2.
В этом примере наиболее важным является то, что с функцией
затухания можно поступать так же, как с обычными изображения¬
ми (например, расширять по маске).
Таким образом, функция затухания дает способ использова¬
ния слоек для параллельного обнаружения объектов с заданны¬
ми свойствами на битовых изображениях.
Текстурный анализ. При анализе изображений можно интере¬
соваться отдельными объектами, их характеристиками и взаимо¬
отношением, а можно интересоваться областями, характеризую¬
щимися определенной регулярностью. Изображения одних и тех
же областей можно анализировать в обоих аспектах в зависимос¬
ти от задачи исследования и частоты квантования изображения.
Например, изображения биологических тканей можно изучать на
клеточном или тканевом уровнях, изображения земной поверхности
можно анализировать с точностью до каждого холма или дерева,
а можно интересоваться холмистыми или лесистыми областями.
Поэтому мы будем говорить о текстурном анализе, а не о тек¬
стурных изображениях.
Под текстурным анализом будем понимать методы описания и
выделения областей, характеризующихся определенной связью
или организацией элементарных компонентов (компоненты — то,
чьи индивидуальные свойства нас не интересуют).
Организацию объектов тоже можно понимать по-разному. На¬
ми разработаны методы выделения областей с различным харак¬
тером гранулярности и различным характером периодичности.
Эти методы будут рассмотрены ниже.
Наибольшие трудности вызывает задача выделения текстур¬
ных областей, т. е. достаточно больших связных частей изобра¬
жения, внутренние характеристики которых относительно ста¬
бильны, но заметно меняются при переходе через границу в со¬
седнюю область.
Сложность состоит в том, что для получения внутренних ха¬
рактеристик области необходимо знать ее границы (чтобы не
включать в анализ соседние области), а определение границ об¬
ластей требует знания их внутренних характеристик. Рассматри¬
ваемые методы сводятся к получению набора битовых матриц,
изображающих области, обладающие некоторым простым внут¬
ренним свойством; далее из пересечений и объединений этих об¬
ластей выбираются наиболее «интересные» по некоторой совокуп¬
ности критериев.
1. Гранулярность изображений. При анализе гранулярности
Принимаются во внимание только размерные характеристики объ¬
ектов, образующих текстурные области. Для описания тексту¬
ры здесь используется только гранулярный спектр. Напомним, что
71
W W' *W ;МИ>> ***№■■ MP::W-B»S9:WV:*-'-*90*au:,=waaF'11 UBUV**u'-uaV,oscsssaV*a**'-*oaemu-.
Ли- Ли_К; .;:?*:’Г1Я;и?’Г?Г?5» . »Г»:-гя»-.и1Е-лПииж:!Рк:ия-.-.яг.и.,?ап-.г.-Ли1«и-.-лаЬв-.-.- аглГваа- Mlrffcr-
Рис. 19. Изображение, составленное из четырех однородных текс¬
турных областей. Каждая область состоит из регулярно располо¬
женных гранул определенного размера. На изображение наложен
равномерно распределенный шум
гранулярный спектр показывает, какие доли объема рельефа при¬
ходятся на разные толщины.
Предположим, что для описания объектов (будем называть их
гранулами) достаточно одного параметра, и этот параметр есть
толщина. Назовем однородной текстурной областью такую об¬
ласть изображения, в которой имеются гранулы только в задан¬
ном диапазоне толщины. Будем считать такие области различ¬
ными, если их диапазоны толщины не пересекаются. Кроме того,
потребуем, чтобы размеры области были достаточно большими по
сравнению с размером гранул. Таким образом, однородная тек¬
стурная область описывается всего двумя числами — диапазоном
толщины гранул.
Пример изображения, состоящего из нескольких различных
однородных текстурных областей, дан на рис. 19. В этом изобра¬
жении присутствует белый шум, введенный для демонстрации на¬
дежности метода.
При анализе гранулярности нас не интересуют подробно изоб¬
ражения гранул, нужно только знать их толщину. Поэтому пер¬
вая задача — перейти от полутонового изображения к такому би¬
товому, которое позволило бы найти толщины гранул. Для этого
наиболее надежным является нахождение областей влияния на
изображении (см. с. 68). На рис. 20 показаны разделительные
линии областей влияния для рассматриваемого изображения.
Выделение однородных текстурных областей состоит в следую¬
щем: при помощи фильтра толщины выделяются области влия¬
72
ния гранул, находящиеся в заданном диапазоне толщины. Грану¬
лы данного диапазона толщины могут располагаться на изобра¬
жении по отдельности или группами. Нас интересуют только
группы гранул, образующие достаточно большие области. Одно¬
кратное закрытие изображения сливает области влияния сосед¬
них гранул, поскольку они разделены линиями единичной тол¬
щины. Теперь нужно отфильтровать области исходя из минималь¬
ной толщины областей.
Эта процедура повторяется для каждого диапазона толщи¬
ны гранул. В рассматриваемом примере это толщины 2, 3, 4 и 5.
Результат применения описанного метода приведен на рис. 21, где
различные однородные текстурные области показаны разной за-
черненностью.
Теперь рассмотрим, как можно перейти к неоднородным об¬
ластям. Неоднородность гранулярного изображения может быть
самой различной, например, щели между большими гранулами
могут быть заполнены малыми гранулами или большие и малые
гранулы могут быть расположены перемежающимися пластами
и т. п.
Это, однако, не те примеры, на которых хотелось бы остано¬
виться. Рассмотрим рельеф холмистой местности, поросшей лесом.
Такой рельеф можно представить суммой двух рельефов — хол¬
мистого и лесистого. Каждый из них можно считать однородной
текстурной областью, а все изображение — суммой двух текстур.
Для описания такого изображения нужно 4 числа — по 2 на диа¬
пазоны толщины для каждой текстуры. Это описание представ¬
ляет собой несколько затрубленный гранулярный спектр и пока-
Рис. 20. Разделительные линии областей влияния для изображения
на рис. 19
73
Рис. 21. Результат выделения однородных текстурных областей
на рис. 19. Разные области показаны разной зачсрпепностью
зывает, есть ли гранулы в данном диапазоне толщины или нет,
но не показывает, какова их доля в объеме рельефа. Назовем та¬
кое описание изображения гранулярным кодом.
Выше было показано, как выделять однородные текстурные
области. Следующая задача — найти способ выделять области с
различным гранулярным кодом. Разделим ось толщины на К, воз¬
можно, неодинаковых диапазонов. Потребуется К булевых матриц.
Сначала найдем текстурные области для гранул из каждого диа¬
пазона при помощи следующего алгоритма:
Цикл по диапазонам:
Открыть рельеф так, чтобы исчезли гранулы,
толщина которых меньше левой границы
текущего диапазона
Однородные текстурные области —>
в И-ю булеву матрицу
Конец цикла
Если задано К диапазонов, то возможно 2**К значений гра¬
нулярного кода и соответствующих им изображений, получаемых
конъюнкцией К битовых матриц или их отрицаний.
В реальных задачах большинство этих изображений будет пус¬
тым или содержащим «грязь». Изображения можно закрыть,
сгладить или отфильтровать по толщине, чтобы оставить только
достаточно большие области. Таким образом получим изображе¬
ния, содержащие области с различным гранулярным кодом. При¬
мер использования описанной методики дан на рис. 22 а, б, в.
Для этого метода важно правильно задать границы диапазо¬
нов. Если из содержательных соображений нужно, чтобы одно¬
родной текстурной областью была область, содержащая гранулы
толщиной Т и Т+1, и они перемешаны в этой области, то, задав
диапазоны <=Т и > =Т-}-1, можно вообще не получить области
ни для одного из этих диапазонов.
Описанная ситуация, когда есть К битовых матриц, таких, что
И-я матрица содержит единицы в точках, обладающих И-м при¬
знаком, а требуется получить области с разной комбинацией этих
признаков, встречается часто при работе с битовыми массивами,
а не только при обработке изображений.
2. Периодичность изображений. Рассмотрим анализ периодич¬
ности в применении к двухградационным изображениям. Примера¬
ми могут служить вспаханное поле, рисунок ткани или территория
с регулярной застройкой. В этих случаях существует набор век¬
торов, таких, что при соответствующем сдвиге изображения оно
приближенно совмещается с исходным. Алгорим анализа анало¬
гичен гранулярному:
Цикл по всем сдвиговым векторам
с заданным ограничением на длину:
Получить области совпадения сдвинутого на текущий вектор
изображения с исходным
Заполнить мелкие дыры путем закрытия
Убрать мелкие отростки путем открытия
Оставить только большие связные области при помощи фильтра
толщины
Если площадь оставшихся областей не меньше заданной границы,
то переслать это изображение в И-ю битовую матрицу
Конец цикла
Результаты, даваемые алгоритмами гранулярного анализа и
анализа периодичности, имеют тождественную форму и могут ис¬
пользоваться совместно для выделения текстурных областей.
Представление и обработка векторных функций от изображений.
Технику битового представления изображений удобно использо¬
вать для вычисления и обработки векторных функций от изобра¬
жений. Для представления векторной функции используются две
слойки: одна кодирует модуль вектора, вторая — направление.
Рассмотрим вычисление градиента. Градиентом исходного
изображения назовем пару изображений: модуль, равный в каж¬
дой точке максимуму модуля разности между значениями изобра¬
жения в точках, соседних с опорной, и значением в опорной точке,
и направление, содержащее в каждой точке номер соседа, на кото¬
ром достигнут указанный максимум. Причем если значение мо¬
дуля равно нулю, то направление не определено.
Будем рассматривать 8-точечную окрестность. Введем нуме¬
рацию направлений: 0 — не определено, 1—левый верхний угол,
Двигаться против часовой стрелки. Для кодировки направления
потребуется слойка из 4-х слоев.
Пусть задано изображение ИСХ. Результат обозначим МОД
и НАПР. Потребуются еще слойки НОМЕР, СДВИНУТАЯ, РАЗ-
75
а
&
НОСТЬ и булева матрица соответствующего размера МАСКА.
Следующий алгоритм вычисляет градиент:
«о» _^мод — -И-1АПР;
Цикл по соседям:
Сдвиг ИСХ —>СДВИНУТАЯ;
ABS (СДВИНУТАЯ — ИСХ) —> РАЗНОСТЬ;
[РАЗНОСТЬ > МОД] —> МАСКА;
«Номер соседа» —> НОМЕР;
76
Рис. 22. Выделение неоднородных текстурных областей:
а — изображения, полученные путем наложения трех однородных текстурных
областей. Левая полоса состоит из гранул толщиной 6, средняя полоса состо¬
ит из гранул толщиной 2, правая полоса состоит из гранул толщиной 4. Сред¬
няя полоса частично накладывается на левую и правую;
б — разделительные линии областей влияния, полученные для исходного изоб¬
ражения и его открытия. Самые светлые линии соответствуют исходному изо¬
бражению. Более темные линии соответствуют открытию порядка 2. Черные
линии соответствуют открытию порядка 4;
в — результат выделения неоднородных текстурных областей. Если смотреть
слева направо, то первая полоса содержит гранулы толщиной 6, вторая полоса
содержит гранулы толщиной 6 и 2, третья полоса содержит гранулы толщиной
4 и 2, четвертая полоса содержит гранулы толщиной 4. Между второй и треть¬
ей полосами должна была бы находиться полоса, содержащая только гранулы
толщиной 2, но ее выделить не удалось
Слияние (РАЗНОСТЬ, МОД, МАСКА) —>МОД;
Слияние (НОМЕР, НАПР, МАСКА) —>НАПР;
Конец цикла
На рис. 23 представлено изображение, составленное из восьми
призм и конуса. Для этого изображения была вычислена слойка
направлений. В местах изменения направлений было много шумо¬
вых точек.
К изображению направлений можно применить всю технику,
которая была описана выше. Можно, например, выделить бито¬
вые матрицы, соответствующие разным направлениям, и убрать
из них шум, а затем снова скомпоновать их в слойку. Результат
такого преобразования показан на рис. 24.
Утолщение и утоныиение для вертикальной окрестности. Ранее
мы условились свести анализ трехмерной окрестности к анализу
77
Рис. 24. Направления градиента для изображения на рисунке. Раз¬
ные направления показаны разной плотностью
ее горизонтального и вертикальных разрезов. Все предыдущее
изложение относилось к горизонтальному разрезу окрестности и
к способу изменения значений — на максимум из нулевых или ми¬
нимум из единичных соседей. Это наиболее важный случай. Однако
существуют ситуации, когда невозможно сделать требуемое пре¬
образование исходя из этого определения. Рассмотрим пример.
Пусть имеется полутоновое изображение, в котором яркость
принимает всего два значения, как, например, на рис. 25 а. При ис-
78
Мйазййш«да«Ш!пЬ‘П‘й±8₽ЬЙ.’’ь}:
tLu u: wr-w имуеияв!
(Z
5
нс. 2o. Преооразоваиие изображения на основе вертикальной окрестности
й полутоновое изображение с двумя значениями интенсивности; б — преобра¬
зование изображения на основе вертикальной окрестности
79
пользовании старого способа изменения значений можно изменить
значения в некоторых точках, но они все равно будут одними из
двух исходно заданных. Промежуточных значений яркости полу¬
чить не удастся.
Иногда возникает потребность получить рельеф без резких
перепадов. Это важно при использовании среза по толщине. На
рис. 10 представлен рельеф и таблица заданных и получившихся
толщин срезов для него. Из этой таблицы видно, что результиру¬
ющая толщина есть ступенчатая функция от заданной толщины.
Ошибка в задании очень неравномерным образом сказывается на
ошибке результата. В практических задачах желательно, чтобы
ошибка результата среза плавно зависела от ошибки задания.
Для этого нужно, чтобы высота в рельефе изменялась настолько
плавно, насколько это позволяет дискретность. На рис. 25 6 пред¬
ставлен результат такого преобразования.
Рассмотрим теперь способ преобразования рельефов на осно¬
ве анализа вертикальных окрестностей. Поскольку рассматрива¬
ются не любые множества в трехмерном пространстве, а только
тени функций, для задания вертикальной окрестности достаточ¬
но трех чисел: значения функции в опорной точке и значений в
левой и правой соседних точках.
Множество окрестностей можно задать так: уровень опорной
точки считать нулевым и относительно него задать диапазоны зна¬
чений для левого и правого соседа, как показано на рис. 26. Из¬
менение значения в опорной точке можно задать приращением от¬
носительно ее старого значения. Такое определение допускает
эффективное вычисление этого преобразования.
Через каждую точку можно провести две вертикальные окрест¬
ности, параллельные координатным плоскостям. Однако нам удоб¬
нее считать, что вертикальная окрестность проходит через опор¬
ную точку и двух противоположных ее соседей. Тогда возможно
три варианта для 4-, 8- и 6-точечного шаблона соседства.
На рис. 25 показано преобразование при следующем задании:
ЛЕВАЯ ВЕРХНЯЯ ГРАНИЦА
! ПРИРАЩЕНИЕ
!
В ОПОРНОЙ
ТОЧКЕ
4
ПРАВАЯ ВЕРХНЯЯ ГРАНИЦА
1
1 ЛЛЛЛ
1
'1
!
1 ЛЛЛЛ
1
!
! ЛЛЛЛ
!
! ЛЛЛЛ
0000 -0
—УРСЗЕ
НЬ !
ЛЕВАЯ НИЖНЯЯ ГРАНИЦА ЛЛЛЛ
ОСЛО
!
ЛЛЛЛ
OOGO
!
ЛЛЛЛ
0000
ППП.П
!
ЛЛЛЛ
0000
ПППП
I
ЛЛЛЛ
□ООО
пппп
ПРАВАЯ НИЖНЯЯ ГРАНИЦА
ЛЛЛЛ
0000
ПППП
ЛЛЛЛ
0000
ПППП
ЛЛЛЛ
0000
ПППП
Рис. 26. Схема задания множества вертикальных окрестностей
80
Левая нижняя граница =— 1
Левая верхняя граница =0
Правая нижняя граница =2
Правая верхняя граница =10
Приращение = 1
Шаблон = 4
Скорости операций обработки изображений. Для оценки вре¬
мени решения реальных задач критичными являются операции,
которые повторяются большое, возможно, заранее не определен¬
ное количество раз. Такими являются операции, зависящие от
окрестности. В таблице приведено время выполнения морфологи¬
ческих операций для изображений размером 256*256 точек, за¬
меренные на ЭВМ ЕС1022. Прочерки в таблице означают, что со¬
ответствующие операции не реализованы.
Время выполнения морфологических операций
для изображений 256X256 точек на ЭВМ ЕС1022, с
Операции
Расширение
и
сжатие
Общий случай утолщения
и утоньшения
описание окрест¬
ности через смеж¬
ность и контраст
описание окрест¬
ности через
нулевые, еди¬
ничные и без¬
различные э е-
менты
Количество соседей
в окрестности
4
8 или 6
4
8 или 6
4
8 или 6
Битовые изображения
1.4
2.8
10
18
—
Й:
20
Полутоновые изобра¬
жения (слойки из
8 слоев)
33
66
69
115
*
980
* Преобразование происходит для заданного описания окрестности и всех его поворотов
вокруг опорной точки.
Возможность создания и границы специализированного языка
для обработки изображений. Возможность создания специализи¬
рованного языка для обработки изображений не является очевид¬
ной. Используя ЭВМ, мы всегда работаем с некоторой системой
программирования. Ясно, что любую задачу из некоторой пред¬
метной области можно выразить на базовом языке программиро¬
вания. Возможность описать ту же задачу на специальном проб¬
лемно-ориентированном языке означает, что проблемную область
Удалось хорошо структурировать, т. с. в выработанной системе по¬
нятий удается описывать и решать достаточное количество содер¬
жательных задач.
6 Заказ 5620
81
В случае изображений существенно не то, что битовые матри¬
цы мы называем изображениями, а то, что выявлено небольшое
количество объектов: битовые матрицы, слойки, описания окрест¬
ности; небольшое количество основных операций: утолщения,
утоньшения, срезы и прочее; небольшое количество структур уп¬
равления: циклы до установления, по архиву, по связным облас¬
тям, вызов программ. Эти средства позволяют записывать слож¬
ные алгоритмы обработки без обращения к базовому языку.
Проектируя специализированный язык, мы исходим из того,
что постоянно будут возникать потребности, не выразимые на
языке и требующие обращения к базовому языку программиро¬
вания. Поэтому, во-первых, следует говорить о специализирован
ном языке не изолированно, а в данном операционном окруже¬
нии.
Во-вторых, не нужно стараться втиснуть в язык как можно
больше. Какие средства потребуются и будут использоваться, а
какие нет — не теоретическое заключение, а опытный факт. Нужно
обеспечить работоспособный минимум и стандарт расширения.
Интенсивная эволюция языка неизбежна при экспериментальной
работе.
Таким образом, мы выдвигаем следующие требования к спе¬
циализированному языку для обработки изображений:
полнота системы понятий предметной области, отраженных в
языке;
крупные операции, экономящие мышление;
расширяемость за счет программирования на самом специали¬
зированном языке и за счет введения в него новых средств, за¬
программированных на базовом языке.
Команды языка Картран. В этом параграфе приведен сокра¬
щенный список команд, непосредственно интерпретируемых про¬
цессором языка Картран.
Обозначения:
<бул>— идентификатор булевой картинки
<сл> — идентификатор полутоновой картинки (слойки)
<бул/сл> — идентификатор картинки любого типа
/. Задание окрестности
Шаблон [4/8/6]
Смежность <число от 0 до 8> [? <Счисло от 0 до 8>]
Контраст “ “
Окрестность [4 или 6 или 8 чисел [0/ 1/2]]
2. Описания картинок
Булевы [! < идентификатор>]
Слойки “
Как <бул/'сл> [!< идентификатору
Описание картинки такого же типа, как формальный
параметр, но статически неизвестного
Серия.бул [!<бул>]
Серия, сл [!<сл>]
3. Обмены и служебные
Читать <архивное имя> в <бул/сл>
Записать <бул/сл> под именем <архивное имя>
Печать <бул/сл>
Печ. серия, бул <слово>
82
4. Операции над изображениями
Переслать (бул/сл) в (бул/сл)
Сдвиги (по-горизонтали) (по-вертикали)
Бул. оп (номер операции) (бул) (бул) (бул)
+ <сл> (сл) (сл)
—(сл) (сл) (сл)
М i п “
Мах “
* (множитель) (сл)
Инверсия (бул/сл) (бул/сл)
Обнуление (бул/сл)
Плюсбул (бул) (сл)
Слияние (сл) (сл) (бул) (сл)
Сравнение (сл) (сл) (бул) (бул)
Сжатие (число сжатий) (бул/сл) (бул/сл)
Расширение “
Утолщение (число повторений) ,(бул/сл) (бул/сл)
Утоньшение “
Утолщение, уст (бул/сл) (бул/сл)
Утоньшение. уст “
Срез по [уровню/площади/толщине] (число) (сл) (бул)
Маскировка (сл) (бул)
След (сл) (бул)
Реконструкция (бул/сл) по((бул/сл)
Фильтр [толщииы/длины] (от) (до) (бул) (бул)
Заполнение, дыр (бул/сл) (бул/сл)
Граница [0/1] (ширина границы) (бул) (бул)
Градиент (сл-исходная) (сл-модуль) (сл-направление)
5. Циклы
[(переменная цикла) от (число) до (число) шаг (число):
’—до—установления (бул/сл) (бул/сл):
’—до—исчерпания (бул/сл):
’—по—связным (бул) (бул):
’—по—архиву (тек.имя) (префикс) (начало):
6. Статистика
Параметры, связных (бул)
(параметры связных областей булевой картинки для одной или нескольких
слоек)
Параметры, зон (число зон) (сл)
(параметры зон — горизонтальных полос — для
одной или нескольких битовых масок)
Трансляция. Расширяемость языка за счет программ, напи¬
санных на нем самом, достигается тем, что синтаксически обра¬
щение к программе не отличается от команды. Вызов программы
будем иногда называть макрокомандой.
Трансляция управляется синтаксическими таблицами, которые
находятся в архиве. Одна из них описывает синтаксис команд.
Ее пополнение производится вручную; параллельно необходимо
соответствующим образом расширить интерпретатор. Вторая со¬
держит описания макрокоманд и пополняется (корректируется)
автоматически при успешной трансляции программы. При транс¬
ляции эти таблицы сливаются в одну, и трансляция идет одинако¬
во для команд и макрокоманд.
Параметрами команды могут быть идентификаторы булевых
Или слоек, или картинок любого типа, числа и слова. Между па¬
6*
83
раметрами могут употребляться комментарии. Произвольное ко¬
личество параметров от конца может отсутствовать, тогда они
заменяются на значения по умолчанию. Для последнего в описа¬
нии команды типа возможно произвольное количество фактиче¬
ских параметров (если это указано в описании).
Для макрокоманд ограничением является отсутствие умолча¬
ний и неограниченного повторения параметров. Описания макро¬
команд берутся из заголовков программ при трансляции.
Передача параметров в программу происходит следующим
образом: для параметров типа «бул», «сл» и «бул/сл» передают¬
ся ссылки на них, для параметров типа «слово» и «число» произ¬
водится текстовая подстановка, возможно, с вычислением ариф¬
метических выражений.
При трансляции происходит проверка соответствия команд
или макрокоманд их описаниям, в том числе проверка соответствия
типов параметров, а для чисел, кроме того, попадание в задан¬
ный диапазон. Производится проверка правильности вложеннос¬
ти циклов.
Возможно создание диалектов, так как при достаточно дли¬
тельной работе у пользователя возникает индивидуальный набор
часто употребляемых новых операций. Кроме того, для всех слу¬
жебных слов допустимы синонимы. Таблица синонимов хранится
в архиве и может изменяться пользователем.
Результатами трансляции являются:
1—транслированная программа на внутреннем представлении
языка. Если не было ошибок, она записывается в архив;
2 — описание макрокоманды в синтаксической таблице (если
не было ошибок);
3 — листинг программы, возможно, с сообщениями об ошибках.
Проблема документации в значительной мере решена тем, что
синтаксические таблицы можно распечатать в наглядной форме, и
они являются документом для читающего их человека. Эти таб¬
лицы вместе с листингами программ являются полным отражением
текущего состояния языка и предназначены для пользователя.
Системному программисту предоставляются исходные тексты
транслятора и интерпретатора на метаязыке МАСОНа и ИНФ78,
снабженные комментариями.
Интерпретация. Интерпретация начинается диалогом с опе¬
ратором. Для каждой команды производится (если нужно) сле¬
дующее:
подстановка текущих значений переменных циклов;
вычисление и подстановка значений арифметических выраже¬
ний на место параметров типа «число»;
выполнение команды.
Выполнение команды состоит в следующем.
Для непосредственно выполняемых команд происходит обра¬
щение к соответствующей программе обработки.
Для макрокоманд:
84
а
5
Рис. 27. Стереопара изображений: а — исходное
изображение; б — изображение со сдвинутым окном
в центре
чтение программы из архива и текстовая подстановка для па¬
раметров типа «слово» и «число»;
формирование списка параметров для типов «бул», «сл» и
«бул/сл» для передачи их вызываемой программе;
передача управления вызываемой программе.
Здесь диалог с оператором прекращается и происходит интер¬
претация вызванной программы и всех программ, которые она,
может быть, вызывает. Вложенность не ограничивается. Когда
этот шаг заканчивается, интерпретатор вновь выходит на диалог.
Интерпретатор имеет регулярную структуру. Когда требуется
внести в язык новое средство, запрограммированное на базовом
языке ИНФ78, нужно добавить в интерпретатор группу операто¬
ров, организующих вызов соответствующей обрабатывающей про¬
граммы. Это делается аналогично уже имеющимся в интерпрета¬
торе обращениям к программам и трудностей не вызывает.
Пример. Сопоставление стереопар изображений. На стереопа¬
рах изображений объекты, находящиеся на разных расстояниях
°т наблюдателя, по-разному сдвинуты друг относительно друга.
Сдвиг тем больше, чем больше расстояние между объектами по
Шубине. Зная относительные сдвиги различных частей стереопа-
85
а
»ЛгЛ«ДпНкЕр::гтл:1г5:*>
t п шк| uuai n кгшы ratttmn r
rttrramnntt MiJuutnnwttt w
B/i u шя фгф 11хф и гфуф t * V*'*Ul n l*
5
1шсНЕ:л:
К-KL^k»
«SuF.<!:$£:
5“Н1ЙЕ»Ч
Гишёцшма&Нжжк
.tl«nn::m::in:n::ntiu
.wuwauuuuwttiatutti
Рис. 28. Области совпадений имеют большую плотность, чем области несовпа¬
дений: о — без сдвига; б — со сдвигом на 10 позиций; в — со сдвигом на неко¬
торое другое число позиций
ры изображений, можно найти расстояния от наблюдателя до объ¬
ектов, представленных на изображении.
Наиболее сложной задачей является нахождение соответст¬
вующих частей в стереопаре. В нашем примере в качестве изобра¬
жений используются битовые картинки из случайных точек, пред¬
ложенные Б. Юлешем .[7].
Первое изображение получается путем уровневого среза по¬
лутонового изображения, содержащего равномерно распределен¬
ие
я
Рис. 29. Там, где плотность точек исходно больше,
ее удается увеличить еще больше, оставив без из¬
менений там. где она исходно меньше: а—без сдви¬
га; б — сдвиг на 10 позиций
ные псевдослучайные числа. Уровень среза регулирует плотность
точек. Стереопара к нему конструируется следующим образом; в
центре изображения вырезается окно, сдвигается на несколько
позиций по горизонтали и вставляется обратно. Оставшаяся по¬
лоска заполняется случайными точками. Стереопара изображе¬
ний показана на рис. 27 а, б.
Идея алгоритма состоит в том, чтобы, последовательно сдви¬
гая одно изображение относительно другого, находить области
совпадения. Для полей из случайных точек область совпадения
содержит все исходные точки, а область несовпадения — только
часть исходных точек (см. рис. 28а, б, в). На первый взгляд ка¬
жется, что область несовпадений вообще не должна содержать то¬
чек, но поскольку точки расположены случайно, то при любом
сдвиге есть и случайно совпадающие. Поэтому выделение облас¬
тей совпадения сводится к выделению областей с большей плот¬
ностью точек.
Для этого путем серии утолщений при различных описаниях
окрестности удается еще больше увеличить плотность точек там,
87
где она исходно больше, оставив ее без изменений там, где она
исходно меньше (см. рис. 29 а,б). Затем путем серии расширений,
сжатий и фильтрации по толщине получаем области на рис. 30 а, б.
Окончательный результат дан на рис. 31. Для сдвигов, не соот¬
ветствующих реальному сдвигу исходного изображения, получа¬
ются изображения с низкой плотностью точек, и описанный алго¬
ритм не выделяет на них никаких областей. Заметим, что этот ал¬
горитм можно использовать и в случае, если сдвиг происходит
одновременно по двум направлениям.
Замечания об инструментальном подходе. Описанная здесь ме¬
тодика обработки изображений является примером инструмен¬
тального подхода к автоматизации конкретной прикладной облас¬
ти. Основные этапы работы в области программирования:
1) разработка базовых средств нижнего уровня преимущест¬
венно по критерию возможности эффективной реализации;
2) погружение этих средств в достаточно развитый базовый
язык, способный к развитию;
3) конструирование в рамках базового языка специализиро¬
ванных средств следующего уровня, имеющих ясную проблемную
интерпретацию и одновременно достаточно эффективно реализу¬
емых (так как они строятся из средств п. 1);
4) оформление полученного набора в виде специализированно¬
го расширяемого языка, основные понятия и концепции которого
проблемно ориентированы;
а.
Рис. 30. Выделенные области совпадений показа¬
ны черным: а — без сдвига, б — сдвиг на 10 позиций
5
88
Рис. 31. Окончательный результат сопоставления
стереопары изображений
5) развитие системы (преимущественно в рамках пп. 3 и 4) в
процессе решения конкретных прикладных задач; при этом про¬
исходит накопление опыта, выражающееся в новых средствах
специализированного языка.
Инструментальный подход приводит к постепенному выявле¬
нию ограничений на класс решаемых в его рамках задач; полез¬
ным свойством подхода является возможность проследить проис¬
хождение этих ограничений до их истоков. Если причины ограни¬
чений кроются в естественном человеческом недомыслии, то их
можно преодолеть в процессе усовершенствования системы. Если
же причины ограничений неустранимы на уровне доступных тех¬
нических средств, стимулируется выработка требований к сле¬
дующим их поколениям.
Происхождение содержательных понятий специализированно¬
го языка от эффективно реализуемых средств нижнего уровня для
конечного пользователя неочевидно (и он может об этом не
знать). Совокупность этих понятий в большой степени формиру¬
ет стиль мышления пользователя и его подход к отбору и реше¬
нию конкретных задач. При смене техники инструментальный
подход ведет к необходимости пересмотра набора средств нижне¬
го уровня; тем не менее содержательные понятия проблемно-ори¬
ентированного языка могут сохраниться, если они выразимы в но¬
вом наборе средств.
ЛИТЕРАТУРА
1. Денисов В. М., Матвеев Ю. Н., Очин Е. Ф. Принципы организации систем
обработки изображений на базе клеточной логики // Зарубежная радио¬
электроника. — 1984. — № 1. — С. 3—25.
2. Морфологический процессор / В. П. Косых, А. И. Пустовских, Е. В. Тара¬
сов, Н. С. Яковенко//АВТОМЕТРИЯ.— 1984. — № 4. — С. 102—109.
3. Темов В. Л. Метаалгоритмическая система общего назначения (МАСОН)//
Труды Всес. симп. по методам реализации новых алгоритмических языков.
Ч. 2. — Новосибирск, 1975. — С. 8—24.
4. Batcher К. Е. Design of a massively parallel processor//IEEE Trans, on
Computers. — 1980. — V. 29. — № 9. — P. 836—840.
89
5. A. Cellular logic array for image processing / M. J. B. Duff, D. M. Watson,
T. J. Fountain and G. K. Shaw//PATTERN RECOGNITION. — 1973. —
V. 5. — P. 229—247.
6. Fallon J., Pycock D., Taylor С. T. Quantitative cytophotometry and image
analysis with the MAGISCAN//J. of HISTOCHEMISTRY and CYTOCHEMI¬
STRY. — 1979. — V. 27. — № 10.— P. 1382—1383.
7. Julez B. Global stereopsys: cooperative phenomena in stereoscopic depth
perception //HANDBOOK OF SENSORY PHYSIOLOGY / R. Held, H. W.
Leibovitz and H.-L. Teuber — Eds.— 1978. — V. 8.
8. Klein J. C:, Serra J. The texture analyser J. of MICROSCOPY. — 1972.—
V. 85. —P. 349 — 356.
9. Golay M. J. E. Hexagonal parallel pattern transforms//IEEE Trans, on
Computers. — 1969. —V. C-19. —№ 8. — P. 733—740.
10. Granlund G. H. GOP: A fast and flexible processor for image analysis//
LANGUAGES AND ARCHITECTURES FOR IMAGE PROCESSING/M. J. B.
Duff and S. Levialdi —Eds. —ACADEMIC PRESS, 1981. —P. 179— 188.
11. Lay B., Lantuejoul C. MORPHOLOG: a software package of guantitative
image analvsis //CENTRE DE MORPHOLOGIE MATHEMATIQUE, ECOLE
DES MINES DE PARIS, 1983.
12. A real time picture processor for use in biologic cell identification. I. System
design. II. Hardware implementation/P. Lemkin, G. Carmar, L. Lipkin &
al.//J. of HISTOCHEMISTRY AND CYTOCHEMISTRY. — 1974. — V. 22.—
№ 7. — P. 725—731, 732—740.
13. Basis of cellular logic with some applications in medical image processing/
K. Preston, M. J. B. Duff, S. Levialdi & al.//Proc. IEEE. — 1979. — V. 67. —
№ 5. — P. 826—856.
14. Preston K. Computer hardware for biomedical pattern recognition//BIOME-
DICAL PATTERN RECOGNITION AND IMAGE PROCESSING/K. S. Fu
and T. Pavlidis. — Eds. — Berlin: Dahlem Konferenzen: 1979. — P. 213—232.
15. Preston K. Gray level image processing by cellular logic transforms//IEEE
Trans, on Pattern analysis and machine intelligence. — 1983. — V. PAMI-5.—
№ 1. —P. 55—58.
16. Reeves A. P. An array processing system with a FORTRAN — based realisa-
tion//COMPUTER GRAPHICS AND IMAGE PROCESSING. — 1979. — V. 9.—
P. 267—281.
17. Reeves A. P. A systematically designed binary array processor//IEEE Trans,
on Computers. — 1980. — V. C-29. — № 4. — P. 278—287.
18. Roux P„ Richalet I. Biomedical parallel image processing on PROPAL
2//LECTURE NOTES IN MEDICAL INFORMATICS. — 1982. — V. 17.—
P. 320—329.
19. Schwarz H. Neue Anwendungsmoglichkeiten der Bildanalyse in Forschung
und Routine//GIT. — 1984.—V. 28. — № 12.— P. 1128—1136.
20. Serra J. Image analysis and mathematical morphology. — ACADEMIC
PRESS, 1982.
21. Sternberg S. R. Cellular computers and biomedical image processing//
LECTURE NOTES IN MEDICAL INFORMATICS. — 1982. — V. 17.—
P. 294—319.
УДК 681.3.06
Г. В. СЕНИН
СИСТЕМЫ МАНИПУЛИРОВАНИЯ ДАННЫМИ
НА ПЕРСОНАЛЬНЫХ ЭВМ
1. ЧТО НАЗЫВАТЬ ПЕРСОНАЛЬНОЙ
БАЗОЙ ДАННЫХ
Программное обеспечение персональных ЭВМ (ПЭВМ) вклю¬
чает как наиболее доступные системы программирования, напри¬
мер Бейсик, так и (в основном) широкий круг программ, позво¬
ляющих эффективно решать разнообразные прикладные задачи,
не вникая в детали программирования.
Среди прикладных систем, получивших распространение на
ПЭВМ, важное место занимают так называемые «системы мани¬
пулирования данными» (data managers), коротко именуемые в
статье персональными базами данных (ПБД). Понятие базы
данных (более точно — системы управления базами данных) бы¬
ло «унаследовано» персональными ЭВМ от своих предшествен¬
ников, больших и средних ЭВМ, однако за 5—6 лет развитие
ПЭВМ претерпело некоторые изменения и получило новые, до¬
полнительные оттенки.
В узком смысле термин «персональная база данных» приме¬
ним к системам управления базами данных реляционного типа или
близким к ним, а также более простым однофайловым системам.
В данной статье затрагиваются также области обработки текстов
и электронных таблиц, что объясняется прежде всего пересече¬
нием классов задач, решаемых с помощью этих программных
средств.
Развитые СУБД являются мощными средствами как с точки
зрения потребляемых ресурсов, так и с точки зрения легкости ос¬
воения и использования. Более простые программы, например
электронные таблицы, имитирующие БД, но не предоставляющие
некоторые характерные для баз данных функции, могут быть тем
не менее вполне приемлемы для решения некоторых задач. По¬
рой пользователя интересуют специальные функции, не представ¬
ленные во многих БД, такие, как автоматическое порождение поч¬
товых адресов из базы данных адресатов (MailMerge), что пред¬
полагает существование средств текстовой обработки. Часто
предъявляются также особые требования к средствам подготовки
печатных сводок.
Некоторые задачи могут решаться без использования мощных
БД программами других классов:
с помощью систем обработки текстов — задачи, в которых не
требуются сортировка и извлечение информации по сложным
критериям, особенно если структура данных проста, но имеются
текстовые поля переменной длины (например, ведение библиогра¬
фического каталога);
91
с помощью электронных таблиц — задачи, где существенны
легкость ввода и доступа к информации, быстрый пересчет за¬
висимостей между данными и возможности графического отобра¬
жения, а также скорость обработки, но не столь важны контроль
типов данных и ограничений, подготовка сложных печатных сводок
и не велик общий объем информации;
на основе программ, получивших название интегрированных
систем, предоставляющих обычно функции БД в неполном ви¬
де, но обладающих всеми преимуществами интеграции и обеспе¬
чивающих решение задач, для которых характерно совместное
использование текстовой, табличной, графической информации.
Ориентация на самые широкие круги пользователей-непро¬
граммистов существенно влияет на средства взаимодей¬
ствия человека с программой: классические языки директив,
языки управления данными уступают место «интуитивным» фор¬
мам взаимодействия.
Для пользователя не имеет существенного значения и внут¬
ренняя классификация программ—будь то база данных, тексто¬
вый процессор или новая суперпрограмма. В конечном счете от
программы ему требуется функциональная полнота, т. е.
способность завершить решение задачи в целом.
Развитие интерфейса с пользователем и интегральность функ¬
ций— явные тенденций в нынешнем программном оснащении
ПЭВМ и в сфере ПБД в частности. Одним из следствий этого яв¬
ляются четкие различия между двумя сторонами коммерческих
программ, каковыми являются ПБД: программой как продуктом
творческой мысли программиста и как предметом потребления.
Математический аппарат, стоящий за той или иной программой,
равно как и иные ее теоретические или чисто программистские ас¬
пекты, остается вне поля зрения пользователя. Применительно к
базам данных такими аспектами являются вопросы полноты, не¬
зависимости, целостности данных.
Персональная обработка данных выполняется программами
разных классов, различия между которыми не всегда отчетливы.
Так, на границе БД и традиционной текстовой обработки возник¬
ли текстовые БД и «процессоры перечней». Электронные таблицы
появились как новый, самостоятельный вид программ, но очень
быстро возникли гибриды, обладающие также свойствами тради¬
ционных БД.
Интегрированным системам свойственно сопряжение функций
в едином программном продукте. Основными компонентами этих
систем являются текстовая обработка, табличная обработка, функ¬
ции базы данных, а также другие, подчиненные функции: графи¬
ка, коммуникации.
Сверхзадачей разработчиков новых пакетов ПБД являются
совмещение, сопряжение, увязывание функций для удовлетворе¬
ния информационных нужд пользователя на основе глубоких ар¬
хитектурных и технических концепций, способных обеспечить
вместе с возрастающими аппаратно-вычислительными мощностиг
92
ПБД
I
n
Универсальные
l
I Электронные таблицы
' I
Специализированные
* Symphony —
* Framework —
- 1-2-3
— Multiplan
- VisiCalc IV
— SuperCalc 3
Текстовые БД
Address—Telephone Books —
T i me M anagement —
Business Analysis —
— Javelin
- OZ
— Encore!
DayFlo -
ZOG -
Традиционные
■ |
1- файловые
— pfs:f ile/pfs:report
— NutSnell
— PC File'N Report
j- PC File III
j- Q& A
Тяжелые
(категория 4)
dBASE III -
R: Base 4000/5000-
Paradox —
KnowledgeMan —
Revelation —
Текстовые картотеки •
— CardBox
— DataFax
— FreeForm
Процессоры перечней (Outliners)
- ThinkTank/MaxThink
- FreeStyle
- ♦ Framework
Многофайловые
1 I
| Другие
Реляционные
—I Средние
(категории 2 и 3)
dBASE II -
TIM IV -
Power: Base —
PC/rOCUS -
ASAP Five/Six —
— Reflex
— Cornerstone
— DataEase
— Infoscope
— VersaForm XL
Рис. 1. Функциональная классификация ПБД
ми ПЭВМ поддержку развитого «интуитивного» взаимодействия
пользователя с программой (простое управление, легкое переклю¬
чение между функциями) при условии эффективного решения
задачи (быстрый доступ к информации).
Классификация существующих ПБД будет проводиться по сле¬
дующим признакам:
функциональной направленности;
степени интегрированности, или сопряжения функций;
уровню и типу пользовательского интерфейса;
степени переносимости между различными типами ПЭВМ.
Основное внимание будет уделено функциональной направ¬
ленности ПБД.
2. ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ
На рис. 1. ПБД располагаются в соответствии с набором функ¬
ций, которые они предлагают своим пользователям.
2.1. ПБД ТРАДИЦИОННОГО ТИПА
Классификация. СУБД на больших и средних ЭВМ сформиро¬
вались как универсальные средства обработки данных и как одно
93
из основных приложений ЭВМ, в основе которого лежит теория
баз данных с понятиями модели данных, схемы БД, с основными
типами БД: иерархическим, сетевым, реляционным.
ПБД продолжили эту традицию СУБД и во многом опирались
на нее, однако с выдвижением на первый план программы как
продукта из поля зрения потребителя исчезли теоретические ос¬
новы и терминология теории баз данных.
Ранее других, еще в эпоху 8-разрядных ПЭВМ невысокой про¬
изводительности, возникли так называемые однофайловые систе¬
мы— программы с ограниченными возможностями. Однофайло¬
вые ПБД рассчитаны на работу с независимыми файлами, т. е.
не способны поддерживать одновременную работу с различными
типами записей. Эта категория совпадает с категорией 1 по
классификации журнала PC Magazine ,[ 1].
Одним из лучших представителей этого класса систем счита¬
ется программа Pfs:file фирмы Software Publishing, ставшая в
своем классе фактическим стандартом для ПЭВМ ИБМ (извест¬
ная также под названием IBM Filing Assistant) [2, с. 178—181].
Основное достоинство системы — простота использования. Она
обеспечивает минимальные функции БД: определение данных, их
ввод через экранную форму и ассоциативный поиск записей. От¬
дельный модуль подготовки сводок* (Pfs:report) позволяет хра¬
нить и использовать ранее заготовленные форматы сводок с воз¬
можностью переименования полей, сортировки по нескольким по¬
лям, арифметических и логических операций над значениями по¬
лей. Несмотря на отсутствие многих функций развитых БД (за¬
дание типов полей, контроль диапазона значений, импорт и эк¬
спорт данных, реструктурирование данных) и довольно медлен¬
ный поиск, эта программа одна из наиболее популярных среди
ПБД, что указывает на наличие широкого круга пользователей,
не предъявляющих высоких требований к функциональным воз¬
можностям ПБД, но ценящих прежде всего простоту использова¬
ния.
К новым программам этого класса относится Q&A [3], даю¬
щая некоторые улучшения по сравнению с Pfs: средства разметки
экрана, макросы клавиш, форматы полей записи.
К категориям 2, 3 и 4 по той же классификации относятся
ПБД в подавляющем большинстве реляционного типа или близ¬
кие к ним. Такая программа должна быть многофайловой, т. е.
осуществлять поддержку зависимости между записями различных
типов, в частности согласование значений полей при вводе запи¬
сей и ассоциативный поиск записей в разных файлах, имеющих
общее поле.
В той или иной форме ПБД этих категорий опираются на тео¬
рию реляционных баз данных и на реляционные операции. Далеко
не все из них последовательно используют эти операции и предо¬
* По мнению автора, термин «сводка» более точно передает смысл англий¬
ского слова «report», чем буквальный перевод «отчет».
94
ставляют полный их набор пользователю. Ко многим ПБД тер¬
мин «реляционный» можно отнести лишь с известной натяжкой.
По своим возможностям эти программы образуют широкий,
почти непрерывный спектр. Их внутренняя градация основана на
наличии следующих дополнительных черт:
в категорию 2 входят ПБД, обеспечивающие минимальные
«реляционные» возможности (работа как минимум с двумя ти¬
пами записей при вводе данных, поиске, подготовке сводок);
категорию 3 составляют ПБД с дополнительными возможностя¬
ми программирования на специальном внутреннем языке, ориенти¬
рованном на задачи обработки данных. Этот язык, как правило,
включает основные реляционные операции. Другой признак ПБД
этой категории — возможность определения пользователем соб¬
ственных меню, или сценариев взаимодействия с системой. Бла¬
годаря средствам программирования ПБД этой категории могут
рассматриваться как генераторы прикладных систем, рассчитан¬
ные на более искушенного пользователя, нежели программы кате¬
горий 1 и 2 (известны примеры, когда коммерческие системы пи¬
шутся на языке других ПБД, например Friday! ,[4, с. 220, 246] —
на языке системы dBASE II);
ПБД категории 4 должны помимо прочего обладать наиболее
развитыми функциями манипулирования данными (например, гиб¬
кие средствач структурирования и реструктурирования данных),
удобством и легкостью доступа к ним и т. п. В эту категорию вхо¬
дят наиболее мощные ПБД.
О моделях данных. Чем объяснить столь высокую популярность
реляционной модели данных по сравнению с другими известны¬
ми моделями: иерархической и сетевой?
Наиболее часто как основное преимущество реляционной мо¬
дели подчеркивают возможность динамического связывания дан¬
ных в разных типах записей. Результат такого связывания — от¬
ношение, полученное виртуально, «на лету», что обеспечивает ло¬
гический взгляд на данные независимо от ранее определенного
физического способа их хранения. Поскольку не предполагается
наличие иерархии или любой другой жесткой, заранее заданной
структуры данных, связывание данных производится по содер¬
жимому поля, общего для двух отношений.
Известную роль, конечно, играет наглядность табличного фор¬
мата, в который, естественно, отображаются реляционные струк¬
туры, отсюда его доступность для непрофессионального пользо¬
вателя.
Реляционному подходу свойственны и определенные недостат¬
ки в сравнении с сетевым. Прежде всего это необходимость спе¬
циальных операций для связывания данных, тогда как сетевое
Представление само по себе указывает на упорядоченность струк¬
туры и наличие связей. Связывание по содержимому общего поля
означает фактическую зависимость данных, не находящую ес¬
тественного отражения в модели. Это вынуждает заботиться о
согласованном вводе значений в одинаковые поля различных от-
95
ношений, иначе говоря, при вводе значений верифицировать их,
просматривая записи другого типа. В реляционных ПБД эта чер-
та названа просмотром файла (Look up).
Недостатки реляционных систем должны проявляться резче
с ростом числа отношений, т. е. типов объектов (свыше 30—40),
н числа полей в каждом отношении (несколько сотен)'.
Не случайно поэтому ряд практических ПБД (например, Po¬
wer-base ,[5, с. 223—224], ASAP Six, развивающая ASAP Five
[6, с. 198—202]) предлагают различные надстройки сетевого ха¬
рактера над реляционным уровнем. Программировать такую над¬
стройку можно с помощью языка реляционных процедур. Здесь
налицо попытка сочетать реляционный и сетевой подходы на сле¬
дующих двух уровнях:
нижнем, инструментальном, который отводится реляционной
модели и процедурному языку;
верхнем, концептуальном, отвечающем структуре приложе¬
ния— сетевой модели (вспомним семантические сети).
Таким образом, развитая ПБД может опираться на смешан¬
ные реляционно-сетевые представления.
Интересный подход предлагается в экспериментальной про¬
грамме RABBIT [7]. Формулировка запроса происходит в терми¬
нах семантической сети, отражающей пользовательский взгляд
на данные. Фактическое исполнение запроса производится в ре¬
ляционной форме после соответствующего преобразования. Струк¬
тура семантической сети гораздо ближе структурам мышления и
заведомо сложнее, чем реляционные структуры хранения. При ис¬
пользовании сложной базы данных такой концептуальный уро¬
вень может оказаться незаменимым.
В обзорах журнала PC Magazine еще в 1984 г. [2,4—6,8]
приводится описание нескольких десятков ПБД. Здесь целесооб¬
разно дать лишь общий перечень возможностей, предоставляемых
«средней» реляционной ПБД.
Функции и характеристики типичной реляционной ПБД
Типичная реляционная ПБД обладает следующими функцио¬
нальными возможностями (см., например, [9, 10]):
задание состава полей отношений и спецификация полей (схе¬
ма БД);
ввод, модификация и удаление данных;
реляционные операции, в том числе поиск и выборка записей;
сортировка записей по значениям полей;
индексирование по ключевому полю;
защита базы данных, отдельных файлов или полей от несанк¬
ционированного доступа;
подготовка печатных сводок (Report Generation);
импорт и экспорт данных в файлы различных форматов.
Спецификация поля при проектировании БД включает ряд
следующих характеристик:
96
наименование поля;
длина поля (в байтах). Обычно поля переменной длины не
допускаются;
тип поля. Перечень допустимых типов почти всегда включа¬
ет: строковый (алфавитно-цифровой), целый, вещественный. Во
многих системах допускаются типы: логический (да/нет), кален¬
дарная дата, денежная единица, перечисление значений;
диапазон допустимых значений — обычно для числовых полей;
текстовый шаблон — для строковых полей;
значение по умолчанию;
указание на то, что поле является производным. Его значения
вычисляются по другим данным. Сюда относятся формулы, вы¬
числяющие значение поля как функцию других полей отношения;
подстановки значения поля из другого отношения («просмотр
файла»); автоматически возрастающие значения: в данное поле
заносится значение из предыдущей записи, увеличенное на 1 (ког¬
да записи должны использоваться упорядоченно);
текст подсказки и (или) сообщения об ошибке, который дол¬
жен выдаваться при вводе данных в поле записи и контроле пра¬
вильности введенных данных;
флаги, указывающие на необходимость заполнения поля, ин-
дексируемость (ключевое поле), уникальность (поле, идентифи¬
цирующее запись). Часто имеется возможность задать автомати¬
ческое преобразование в верхний регистр, что удобно для после¬
дующих операций текстового сопоставления;
флаги защиты поля: защищенное от изменения; защищенное от
просмотра.
Особенности процедур ввода и модификации рассматриваются
в разделе, посвященном взаимодействию с пользователем (п. 3.2).
Реляционные операции включают в себя:
JOIN — соединение. Связывание двух отношений через общее
поле (домен). Соединение может быть физическим (с образова¬
нием нового файла) или виртуальным. Эта операция является
ключевой при квалификации ПБД как реляционной (катего¬
рии 2—4).
PROJECT — проекция. Проецирование отношения на некото¬
рое подмножество доменов — усечение несущественных полей.
UNION — объединение кортежей двух отношений — слияние
2-х файлов одного формата.
SELECT — выборка записей, удовлетворяющих ограничениям
(критериям поиска). В развитых системах выборка позволяет соз¬
давать «подмножества данных» — наборы записей, удовлетворя¬
ющих критериям, с которыми затем можно работать независимо.
Типичные виды ограничений, помимо проверки на полное сов¬
падение,— числовой диапазон (для числовых полей), текстовый
Шаблон (для строковых). Стандартной считается возможность ис¬
пользования логических связок AND, OR, NOT для задания слож¬
ных ограничений.
7 Заказ 5620
97
В каком виде эти операции доступны пользователю, опреде¬
ляется типом интерфейса в системе (см. п. 3.2).
Помимо операции соединения обычно обеспечивается работа
с несколькими отношениями в операциях сортировки и поиска, а
также при подготовке печатных сводок.
Сортировка, индексирование. Для быстрого ассоциативного
доступа к записям применяется индексирование записей в файле
по значениям выбранных полей — ключей. Как правило, при этом
создается особый индексный файл со специальной организацией
(В-деревья, хэширование, индексно-последовательный доступ).
Поле может быть объявлено индексным при определении, в
этом случае индексный файл автоматически поддерживается при
пополнении БД. Существуют системы, допускающие динамиче¬
ское индексирование на уже созданной базе данных.
Индексные файлы позволяют производить быструю сортировку
по полям-ключам — типичную для сложной БД операцию. Может
быть задано несколько ключей (основной, вторичный и т. д.). Ко¬
личество ключей определяет мощность процедуры сортировки.
Сортировка может быть физической (с записью отсортированно¬
го отношения в файл) или виртуальной (временной).
В системах с языком директив возможности сортировки вклю¬
чаются в язык.
Количественные характеристики. В табл. 1 приведены некото¬
рые характеристики различных реляционных ПБД.
Таблица 1
ПБД
Коли¬
чество
запи¬
сей в
файле
Коли¬
чество
полей
записи
Макси¬
мальная
длина
записи
Макси¬
мальный
размер
поля
Коли¬
чество
типов
данных
Требу¬
емая
ОЗУ,
Кбайт
Стои¬
мость,
дол.
dBASE III
Неогра¬
128
4 000
4 000
4
256
695
ниченное
. .. ■?,
KnowledgeMan
65 535
255
65 535
65 535
5
192
500
Revelation
Неогра¬
Неогра¬
65 530
65 530
6
320
950
ниченное
ниченное
Power:Base
65 534
64
1600
80
6
230
420
DataFlex
65 536
255
4 000
255
7
100
995
MetaFile
32 000
250
1000
235
4
128
995
DataEase
65 535
255
8 000
255
8
192
600
Paradox
65 535
255
4 к
256
4
512
645
R:Base 5000
Неогра¬
400
5
256
70
ниченное
Cornerstone
32 000
158
5
495
VisiFile
32 000
104
25 400
254
3
256
300
dBASE II
65 000
32
999
999
1
256
Подготовка печатных сводок. Это очень важный компонент, не¬
изменно представленный в ПБД. Информация, извлеченная из
базы данных, поступает во внешний мир для использования в ви¬
де так называемой твердой копии. Мощность генератора сводок
98
определяется гибкостью выходного формата, в котором представ¬
ляется произвольное подмножество данных.
Основные преобразования, которым подвергается исходная ин¬
формация из БД, следующие:
выборка записей, удовлетворяющих некоторому критерию
(«сотрудники с зарплатой не выше чем...»);
соединение данных из разных отношений в выходную табли¬
цу, выдаваемую на печать;
усечение — подавление выдачи ненужных полей;
вычисления: а) введение производных полей, отсутствующих
в исходном отношении, вычисляемых по заданной формуле;
б) суммарные показатели (количество, сумма и частные суммы,
среднее, минимум, максимум), вычисляемые по выбранному под¬
множеству данных;
упорядочение и группирование — записи сортируются по зна¬
чениям одного или нескольких ключевых полей («список сотруд¬
ников в алфавитном порядке», «сгруппировать по должностям и
дополнительно расставить по размеру зарплаты»);
размещение информации, отражающее фактическое расположе¬
ние на листе бумаги и между отдельными страницами сводки (вы¬
бор формата в виде таблицы или отдельными записями, регули¬
рование ширины и порядка следования полей, возможность их
переименования), а также добавление различной текстовой ин¬
формации (заголовки, примечания, дата составления сводки и
т. д.).
Как правило, имеется утилита Quick Report («сырая сводка»),
выдающая данные в одном-двух стандартных форматах, которая
позволяет вчерне, но быстро получить твердую копию.
Импорт и экспорт данных. Поддерживается вывод информа¬
ции во внешние файлы в нескольких различных форматах для
сопряжения с другими системами. Имеется несколько текстовых
(ASCII) форматов с различными разделителями между элемен¬
тами данных (например, формат, в котором значения полей од¬
ной записи разделяются запятыми, а между собой записи разде¬
ляются концами строк). Наиболее распространенные форматы:
DIF (Data Intechange Format)—табличный формат системы
VisiCalc, SYLK (системы Multiplan), формат системы 1—2—3
и др.
2.2. ЭЛЕКТРОННЫЕ ТАБЛИЦЫ
Эта категория программ, возникших независимо от баз данных
и по старым критериям к ним не относящихся, тем не менее за¬
служивает анализа в данном обзоре. Во-первых, многие электрон¬
ные таблицы (ЭТ) реализуют функции, сходные с функциями
БД (среди них такие важные, как поиск, сортировка, глобаль¬
ное редактирование записей); во-вторых, ЭТ интересны с точки
зрения «табличной» формы взаимодействия с программой.
Созданные для применений в сфере бизнеса и делопроизвод¬
стве, ЭТ получили невиданную популярность благодаря, прежде
7*
99
всего, наглядности табличного представления данных. Очень
быстро обнаружилось сходство такого представления с реляцион¬
ным, в своей основе тоже табличным, и производители программ
ЭТ не замедлили этим воспользоваться. Диапазоны ячеек таблицы
стали служить для хранения описателя отношения (набор доме¬
нов) и кортежей данных. Некоторые развитые программы
(Symphony, Framework) способны даже превращать часть ЭТ в
трафарет (form) со свободным расположением полей на экране,
что характерно для традиционных ПБД (см. п. 3.2).
История ЭТ насчитывает уже несколько поколений программ
,[11]. Первое поколение, выдвинувшее саму идею электронной
таблицы, связано, безусловно, с программой VisiCalc (1979 г.) и
ее подражаниями. Для них характерны ограничения на память
(значит, на размер таблицы) и небольшие возможности для рас¬
четов.
Второе поколение ЭТ превзошло предшественников по допус¬
тимому размеру таблиц — стала использоваться вся оперативная
память машины. Центральное место заняла концепция модели¬
рования «что, если...» со сравнением нескольких моделей. Появи¬
лись элементарные графические возможности. Наиболее извест¬
ной программой этого периода (1983 г.), до сих пор пользующейся
популярностью, была программа Multiplan фирмы Microsoft ,[12].
Третье поколение ознаменовано созданием программы 1—2—3
(фирма Lotus), за которой последовали SuperCalc 3 и VisiCalc IV.
Более высокое быстродействие, широкий набор команд с досту¬
пом через меню, некоторые функции развитых БД, а также улуч¬
шенные графические возможности составляют их основные харак¬
теристики. Объединение нескольких функций в одном програм¬
мном продукте — интегрированность — начинает наиболее четко
проявляться именно с появлением программы 1—2—3.
Среди преимуществ, которые дает обработка данных на ЭТ,
можно выделить:
быстродействие (за счет хранения всего содержимого табли¬
цы в оперативной памяти);
удобный интерфейс с пользователем;
развитые средства вычисления (задание формул в ячейках
таблицы), возможность быстрого расчета простых вычислитель¬
ных моделей (анализ типа «что, если...»);
хорошее, как правило, сопряжение с другими функциями (осо¬
бенно графическими).
Недостатками электронных таблиц как базы данных являются:
ограничения на объем одновременно обрабатываемых данных:
объем ограничен размером ОЗУ; это оборотная сторона быстродей¬
ствия;
отсутствие типов данных и контроля типов: ячейки ЭТ по своей
природе однородны;
отсутствие операции соединения таблиц по общему столбцу;
различные типы записей должны быть в одной таблице, иначе
невозможны взаимные ссылки между ними (впрочем, неко¬
100
торые ЭТ, в частности, в системе Framework допускают такие
усылки).
Строго говоря, ЭТ только имитируют базы данных, маскируя
сВое основное качество: наличие большой однородной таблицы без
какой-либо структуры. Очевидно, однако, что ЭТ может служить
для эффективного ведения «малых» баз данных, особенно в за¬
дачах, где более существенны обозримость информации, удобство
навигации по данным, а также графические возможности и ме¬
нее важны вопросы структурированности и типизации данных.
2.3. ТЕКСТОВЫЕ БАЗЫ ДАННЫХ
Этот класс программ является промежуточным между тради¬
ционными СУБД и системами текстовой обработки.
Жесткий формат полей в обычных БД является, если иметь в
виду задачи обработки текста, определенным недостатком. В тек¬
стовых базах данных (ТБД) требования к формату ослаблены
(отсюда другое название ТБД — «база данных со свободным фор¬
матом»), но они все еще сохраняют некоторую структурирован¬
ность данных. Всякая запись свободного формата рассматривает¬
ся как потенциально уникальная по структуре, и понятие схемы
БД, планируемой заранее, исключается.
В сравнении с традиционной текстовой обработкой, при ко¬
торой текст рассматривается как один большой файл, разбитый
на строки, ТБД дают, во-первых, возможность выделения тексто¬
вых фрагментов, с которыми можно манипулировать как с запи¬
сями или полями записи; во-вторых, возможность структурной
организации и реорганизации текста в виде дерева или графа.
Простейшими ТБД являются электронные картотеки (Card-
File systems), предназначенные для хранения слабо структуриро¬
ванной текстовой информации. Содержимое картотеки — тексто¬
вые заметки небольшого объема, снабжаемые ключами. Для вво¬
да содержимого карточек имеются возможности текстового редак¬
тирования (обычно довольно скромные). Выборка по ключевым
словам — основная операция в картотеке. Примерами электрон¬
ных картотек являются программы CardBox, DataFax, Free-
Form .[13].
Программы, позволяющие представить текстовой документ в
виде дерева, получили название процессоров перечней или процес¬
соров идей (outline processors, idea processors) .[14]. Древовид¬
ная структура документа соответствует его разбиению на главы,
Разделы, пункты и т. п., обеспечивается навигация вдоль этой
структуры. Облегчен просмотр документа на разной «глубине»,
т- е. в виде оглавлений разной степени подробности. Перестанов¬
ка частей текста сводится просто к перевешиванию узлов дерева;
возможна и более сложная перестройка структуры (формирова¬
ние подуровней перечня; сглаживание структуры — выравнива¬
ние уровней; слияние пунктов). Древовидная структура является
101
основной формой существования текста; линеаризация — лищь
заключительный этап работы с ним.
Наиболее известная программа этого класса MaxThink (более
ранняя ее версия называлась ThinkTank) ,[15] поддерживает и бо.
лее специфические формы работы с текстом: категоризацию эле.
ментов перечня, их упорядочение по важности и по содержимому,
перемешивание перечня. Предлагаемые средства, направленные на
содержательную, а не формальную обработку текста, дают созда-
телям программ известные основания объявлять свои программы
«процессорами идей».
Ведение перечней становится составной.частью интегрирован,
ных систем и, следовательно, начинает рассматриваться как важ¬
ная функция. Так, процессор перечней имеется в системе Frame-
work .[16].
Интересной программой на границе между базами данных и
текстовой обработкой является система ZOG [17]. Единообразие
структур данных в системе достигнуто благодаря концепции
фрейма. Фрейм может рассматриваться в нескольких аспектах:
а) как запись свободного формата — в этом случае его гнезда
играют роль полей записи; б) как перечень или текстовый фраг¬
мент, где гнезда — пункты перечня; в) как состояние диалога
(меню), где гнезда — пункты меню. Фреймы связываются в сете¬
вую структуру взаимными ссылками. Основная операция на та¬
кой структуре — навигация с возможностью редактирования фрей¬
мов.
Фреймовая структура ZOG может использоваться как база дан¬
ных с сетевой моделью (в этом случае ее наиболее слабым мес¬
том является отсутствие языка запросов), а также — с упором на
текстовое содержимое данных — для ведения проектов и докумен¬
тации вообще, включая разработку программ, рассматриваемых
как структурированные тексты. Несмотря на то, что ZOG, строго
говоря, не является персональной базой данных (по замыслу она
ориентирована на коллективное использование БД в локальной
сети), реализованные в ней идеи способны обогатить область
ПБД и повлиять на развитие текстовых БД.
Полная текстовая база данных [18] должна включать оба
компонента: картотеку или текстовые записи с возможностью ре¬
дактирования и ассоциативной выборки; перечни, позволяющие
собирать и структурировать текстовый документ. Примером ТБД
совмещающей эти функции, является DayFlo [19].
2.4. СПЕЦИАЛИЗИРОВАННЫЕ СИСТЕМЫ
ОБРАБОТКИ ДАННЫХ
Растущие потребности пользователей и вызванный этим спрос
на ПБД закономерно породили расслоение поступающего на рынок
персонального программного обеспечения. В результате удовлет
воряются более частные или более специальные запросы потреби'
телей, для чего универсальные БД могут оказаться слишком
102
сложными, громоздкими и дорогими. Наиболее популярные у
пользователя функции выделяются в специализированные систе¬
мы, в которых сужение возможностей вполне компенсируется бо-
лее полной и отточенной реализацией имеющихся. Можно пере¬
числить следующие частные приложения: личная записная книж¬
ка, адресно-телефонный справочник, сетевое планирование (Project
Management), финансовый (коммерческий) анализ, бухгалтерия
и ДР-
Трудно, разумеется, охватить все громадное количество создан¬
ных в этой области программ. Тем не менее полезно уяснить, чем
отличается специализированная программа от более универсаль¬
ной. Хорошей иллюстрацией этому является программа Javelin
[20]. Программа возникла как сознательная альтернатива ,[21]
сложившейся практике использования электронных таблиц. Авто¬
ры Javelin считают основным слабым местом ЭТ то, что таблица
навязывает исходный взгляд на информацию как на однородный
массив ячеек. Вследствие этого:
фактически исключается возможность взгляда на информацию
с содержательной точки зрения;
основная работа происходит рутинным способом «ячейка за
ячейкой»;
среди множества ячеек, взаимосвязанных формулами, поль¬
зователю легко «заблудиться»: его работа становится менее ос¬
мысленной.
Эти минусы, очевидно, — оборотная сторона универсальнос¬
ти ЭТ. Избежать или уменьшить их отрицательное воздействие
можно путем специализации данных. В Javelin данные автомати¬
чески снабжаются временным параметром. Это позволяет считать
исходной точкой не внешний вид данных (таблицу), а их содержа¬
ние— центральную информационную базу (ИБ), основу которой
составляют переменные, зависящие от времени. В Javelin пред¬
лагается десять различных «точек зрения» на ИБ. Плюсы спе¬
циализации данных следующие:
всякий взгляд на данные (в том числе диапазон ячеек) под¬
дается содержательному истолкованию;
благодаря временному фактору содержательными становятся
формулы, и удается лучше контролировать их правильность;
в программу встраиваются специфические временные форму¬
лы (нарастающий итог, Year-to-Date и т. п.);
облегчен ввод данных; временной период изменения перемен¬
яй позволяет автоматически переходить к следующей времен¬
ам точке или выстраивать набор значений по коэффициенту при¬
ращения;
различные переменные могут во многом вести себя аналогич-
Я> что дает новую возможность автоматизации (например, вы¬
кроить диапазон значений другой переменной по тому же перио¬
ду и пр.).
. Таким образом, сужая область применения, программа типа
Javelin дает взамен более удобные, гибкие средства ввода, анали-
103
ПБД
интегрированные
независимые
— 1—файловые
- чисто реляционные
сильно
интегрированные
вокруг БД
— Pfs:f i le Pfs fami ly
— InfoStar -> DataStar
— KeepIT ITSeries
— Perfect family
— ExecuFILE *■ Ser iesOneP ius
вокруг ОТ
-Т/Maker III
— Jack2
вокруг ЭТ
- Symphony
— OpenAccess
- KnowledgeMan
-MetaFILE
Рис. 2. Классификация ПБД по сопряжениям
за, отображения, преобразования данных. С развитием персо¬
нального программного оснащения такие программы должны по¬
лучить интенсивное развитие в наиболее значимых областях при¬
менения. Тем самым возникнут новые классы программного обес¬
печения ПЭВМ.
3. ДРУГИЕ ХАРАКТЕРИСТИКИ ПБД
3.1. СОПРЯЖЕНИЯ
По степени сопряжения (интегрированности) основных функ¬
ций базы данных с другими можно различать следующие типы
ПБД (рис. 2):
автономные — программы, сосредоточенные на основной функ¬
ции БД — хранении и обработке форматированных данных;
слабо интегрированные — компоненты многофункциональных
пакетов;
интегрированные.
Автономная разработка была характерна для ранних реляцИ'
онных систем, первоначально созданных на 8-разрядных ПЭВМ
под операционной системой СР/М-80, а затем перенесенных на 16'
разрядные ПЭВМ и, в частности, ПЭВМ ИБМ. В этой связи
прежде всего стоит упомянуть системы dBASE II и Condor [22]*
К этой группе принадлежат многие программы категории 1
(п. 2.1), а также большинство реляционных ПБД, среди который
высокопроизводительные — dBASE III, Revelation, R:Base 4000
и R:Base 5000, Paradox, средние— 10 Base, PowerBase, CornerStO'
ne, Infoscope, ASAP-Six, Reflex и др.
104
Программы этого типа либо очень компактны и дешевы (при
ограниченных функциях) .[23], либо сосредоточены на наиболее
полной реализации реляционных возможностей (многие такие
программы, например, используют в качестве языка запросов из¬
вестный язык SQL/SEQUEL).
Сопряжение автономных программ с другими системами ос¬
новано на импорте и экспорте данных через файлы нескольких
наиболее распространенных форматов: различные ASCII-форма¬
ты, DIF, SYLK, dBASE II и dBASE III и др.
Слабая (функциональная) интеграция начинается с появле¬
ния «семейств» — нескольких взаимодополняющих функциональ¬
ных модулей, которые могут использоваться как независимые
программы, обменивающиеся данными через файлы. Но помимо
этого функциональные модули, во-первых, обладают некоторыми
«фамильными» чертами, выраженными главным образом общи¬
ми элементами в интерфейсе с пользователем (стиль взаимодей¬
ствия, значения клавиш и т. п.). Во-вторых, обеспечивают более
тесные функциональные сопряжения на стыках между модуля¬
ми, обычно невозможные для независимо разработанных про¬
грамм (программы орфографического контроля — spelling
checkers — при текстовых процессорах; генераторы стандартных
писем или почтовых ярлыков по трафаретам и адресам — на сты¬
ке «обработка текста — база данных»).
Сформировались опорные точки интеграции: обработка тек¬
стов, табличная обработка, традиционные функции БД, среди ко¬
торых подготовка печатных сводок иногда образует отдельный
модуль, деловая графика, средства коммуникации и др. Именно
эти функции несут в себе отдельные модули в целой группе
программных продуктов, сохраняющие внутреннюю связь и пре¬
емственность.
Такая группа обычно формируется на основе центрального,
исторически более раннего, наиболее развитого модуля с целью
наращивания возможностей и поддержания более полной и жела¬
тельно замкнутой технологии обработки данных.
Так, программа Pfszfile (однофайловая БД) дополнена моду¬
лем Pfs:report (подготовка печатных сводок), который рассмат¬
ривается как тандем тесно связанных программ ,[2, с. 178—181] и,
кроме того, программами Pfs’.write (текстовая обработка),
Pfs:graph (графика), Pfs:access (коммуникации).
«Семейство» ITSeries сложилось на основе базы данных
KeepIT ,[6, с. 208—209, 24] и включило модули подготовки сводок,
текстовой обработки и др. Известны «семейства» Perfect, Super-,
Visi- и др.
Широко известный текстовый процессор WordStar возглавляет
семейство InfoStar, членами которого являются также DataStar
(база данных), Reportstar (подготовка сводок), CalcStar (элект¬
ронные таблицы), StarBurst (система построения меню), PlanStar
(Деловое планирование). Некоторые характеристики главы семей¬
105
ства (тип меню, справочной системы) унаследованы всеми его
членами ,[6, с. 170—171].
В сильно интегрированных системах различные функции связа*
ны в единый, целостный программный продукт, так что стыки
между отдельными компонентами незаметны для пользователя,
Такая система в идеале предоставляет пользователю собствен,
ную операционную среду, позволяющую ему решать свои задачи,
не прибегая напрямую к услугам операционной системы.
Для достижения более высоких операционных характерис-
тик (в частности, быстрого отклика) отдельные подсистемы ин.
тегрированного пакета обычно одновременно загружены в память
ПЭВМ (динамическая подкачка не должна быть слишком час-
той). Это накладывает общее ограничение на объем системы, ц
поэтому каждый ее компонент в отдельности, как правило, функ¬
ционально несколько слабее, чем соответствующая независимая
(специализированная) программа или «член семейства». Мастер,
ство разработчиков состоит в том, чтобы в данный объем кода
вместить максимальное число функций (или данные функции в
минимальный объем). В лучших системах, таких, как Framework,
это достигается благодаря общей технологии разработки, концеп¬
туальному единству компонентов системы. В то же время набор
практических задач, по всей видимости, таков, что не может быть
решен одним пакетом, даже использующим самые .передовые
концепции.
В интегрированных системах также обычно имеется «центр
тяготения» — самый сильный компонент, вокруг которого наращи¬
ваются дополнительные функции, относительно более слабые, под¬
чиненные.
Известная интегрированная система Symphony .[25] продол¬
жает линию, обозначенную программой-бестселлером 1—2—3, и
тяготеет к ЭТ. Но если в 1—2—3 и текстовая информация, и за¬
писи БД трактуются в конце концов как элементы таблицы (ячей¬
ки, диапазоны ячеек), то в Symphony все внутренние пружины
спрятаны от пользователя. Трафарет базы данных (см. п. 3.2),
текст, таблица, гистограмма представляют собой лишь различные
точки зрения потребителя на информацию, которые предоставляет
ему система.
Еще более сбалансированной является программа Framework
[16, 26], в которой имеется развитый текстовый компонент (полно¬
весный редактор плюс процессор перечней). Перечни во Frame¬
work составляют ядро, на основе которого пользователю предла¬
гается иерархически организовывать свои данные. Собственная
база данных Framework реализована средствами ЭТ со всеми
вытекающими отсюда последствиями (п. 2.2). Однако возможно
и другое соотношение между интегрированной системой и базой
данных как таковой, которое иллюстрируется парой Framework-;
dBASE III — программами одной фирмы (Ashton-Tate). В ново!1
версии Framework ([27] система может играть роль операциоН'
ной оболочки для прикладных программ, вызываемых из Frame'
106
^огк, в качестве одной из которых может выступать dBASE III
[5, с. 275—278]. Совместимость по данным между обеими про¬
граммами существенно повышает эффективность их использова¬
ния в такой конфигурации (хотя это и предъявляет высокие тре¬
бования к объему оперативной памяти ПЭВМ).
Примеры пакетов, тяготеющих к текстовой обработке,—
T/Maker III ,[28] и Jack2 [29]. Оба они рассчитаны на подготов¬
ку документов, которые могут включать как текст, так и другие,
нетекстовые компоненты: таблицы и графики. Работа с таблицами
н графикой носит подчиненный характер и поэтому не обладает
всеми возможностями ЭТ и графических пакетов.
Так, электронные таблицы, включаемые в текст, в пакете
T/Maker ограничены 25 столбцами, небольшим набором арифмети¬
ческих формул и не выполняют автоматического пересчета. Опе¬
рации БД (перестановка, сортировка, поиск, выборка и др.) про¬
изводятся над столбцами ЭТ. Графические возможности еще сла¬
бее вследствие того, что пакет был первоначально создан для 8-
разрядных ПЭВМ и плохо использует графические возможности
более мощных машин.
Jack2 интегрирует различные компоненты на основе понятия
формы, которая может содержать любую смесь текстовой, графи¬
ческой, табличной информации. В текст можно вставить данные
в виде нескольких строк или столбцов. Запись БД может быть
скопирована в документ, содержащий ссылки на ее поля, что по¬
зволяет вкраплять в различные места документа значения полей
записи. График, изображающий некоторый ряд табличных дан¬
ных, может быть вставлен внутрь текста и изображен одновре¬
менно с текстом на экране.
Сетевые возможности
С увеличением объема информации в базе данных встает проб¬
лема ведения и поддержки этой информации. Традиционно этот
вопрос решался подключением ЭВМ пользователя к главной ЭВМ
(mainframe) и организацией обмена данными с ней.
При работе с ПЭВМ аналогичным средством являются локаль¬
ные сети и телекоммуникации. Использование локальной сети при¬
водит к определенной деперсонализации базы данных, ибо су¬
щественным становится то, что общая информация одновременно
служит многим потребителям.
Тенденция обеспечить сопряжение с главной базой данных толь¬
ко набирает силу, и пока немногие ПБД снабжены соответствую¬
щими средствами. В качестве примеров можно привести PC/FO-
CUS [5, с. 255—256], MetaFile [30], Revelation [5, с. 246—248],
ReQuest [3], KnowledgeMan ,[31]. Некоторые другие известные
™БД также, по всей видимости, будут снабжены этой возмож¬
ностью (dBASE III, RrBase 5000, DataEase, Power-base, Pfs:iile)
13]. Многие же ПБД остаются чисто персональными и не рассчи¬
107
таны на применение в локальной сети даже юридически (лицеи,
зионное право использования одной копии программы только на
одной вычислительной установке).
3.2. ИНТЕРФЕЙС С ПОЛЬЗОВАТЕЛЕМ
Взаимодействие с пользователем в ПБД включает следующие
аспекты:
общий тип интерфейса (командного типа, типа меню и др.);
способы организации ввода и контроля данных;
способы навигации по данным;
организация запросов к БД;
наличие языка программирования;
средства пакетной обработки;
возможность определения пользовательских сценариев диалога
(пользовательских меню);
интерактивная справочная и (или) обучающая система (on-line
help/tutorial);
графические средства отображения.
Общий тип интерфейса. Основных типов пользовательского ин¬
терфейса— два: на основе меню и на основе языка команд (ди¬
ректив). Иногда они противопоставляются как режим «See and
Point» — «смотри и выбирай» и режим «Think and Туре» — «вспо¬
минай и набирай».
Первый способ ведет свое происхождение от традиционных
средств общения, близких к программированию (командные язы¬
ки в операционных системах, системах разработки программ и
многих прикладных системах). Поскольку текст каждой дирек¬
тивы перед исполнением должен быть набран на клавиатуре, то
основная трудность для пользователя при таком взаимодейст¬
вии — вспомнить наименование нужной команды и ее синтаксис:
количество и порядок аргументов. Плюсы командного языка в
его гибкости; он более удобен, когда пользователь уже освоил
язык. Таким образом, язык рассчитан не на новичка, а скорее на
опытного пользователя (имеющего программистскую подготовку,
привычного к такому типу общения либо уже достигшего нуж¬
ного уровня знания языка в процессе работы с программой).
Интерфейс типа меню облегчает взаимодействие, снимая с
пользователя необходимость заранее изучать язык общения с сис¬
темой и разгружая его память. На каждом шаге диалога все воз¬
можные в данный момент команды предъявляются ему в виде
списка (набора пунктов меню), из которого можно выбрать нуЖ'
ную достаточно простым образом: обычно указанием номера пунк¬
та или перемещением в него курсора с последующим нажагиеМ
особой клавиши. Необходимые параметры команд дополнительно
запрашиваются программой с пояснительным текстом. Для нович¬
ка такой наглядный способ общения гораздо предпочтительнее^
108
практически не требуется предварительного обучения. Однако
при более близком знакомстве с программой пользователь начи¬
нает испытывать неудобства противоположного свойства, нежели в
предыдущем случае. Для полной наглядности меню должны быть
организованы в древовидную структуру с небольшим числом ре¬
бер, исходящих из каждой вершины, что ведет к увеличению чис¬
ла уровней. Подобное взаимодействие для опытного пользовате¬
ля часто становится утомительным и избыточным.
Как и следовало ожидать, первыми появились системы с ко¬
мандным интерфейсом. Меню-системы пришли им на смену как
больше отвечающие фактору персональное™. Типичным являет¬
ся различие по типу интерфейса между более ранними и более
поздними ПБД при сходстве функциональных возможностей. По
этому признаку, например, в [22] противопоставляются реляци¬
онные ПБД Condor и dBASE II, с одной стороны, как «старомод¬
ные», и DataEase, с другой,— как современная.
Следует заметить, что в программах с сетевым представлени¬
ем «навигация» по структуре базы данных выливается в форму
меню: в текущем узле сети исходящие дуги рассматриваются как
пункты меню, переход к очередному узлу — как переход к ново¬
му меню и т. д. Наиболее характерно это для ТБД, таких, как
ZOG [17] и процессоры перечней ,[14].
В наиболее известных системах 1—2—3 и Symphony был пред¬
ложен особый вид меню, который оказался весьма удачным и был
подхвачен во многих других программах (например, Jack2 [29],
Reflex [3]). Располагаемые горизонтально в верхней строке экра¬
на названия пунктов текущего меню могут быть выбраны двоя¬
ким образом: нажатием первой буквы названия пункта или же
перемещением курсора на нужный пункт и нажатием клавиши
ввода. Первый способ прямой и потому наиболее быстрый (одно
нажатие). Второй способ требует нескольких нажатий для экви¬
валентного выбора, однако его преимущество в том, что выбор
растянут во времени — он складывается из указания пункта ме¬
ню и его исполнения. В промежутке между ними пользователь
снабжается дополнительной информацией о текущем пункте —
текстовой расшифровкой, которая подсказывает пользователю на¬
значение пунктов.
Для более поздних систем характерно также интенсивное ис¬
пользование функциональной клавиатуры и специальных комби¬
наций клавиш. Тем самым обеспечиваются дополнительные раз¬
мерности в функциональном пространстве системы, что облегча¬
ет ориентировку пользователя. В качестве метрики в этом про¬
странстве часто принимается число нажатий на клавиши, необхо¬
димое для выполнения той или иной функции. В меню-системах
эта характеристика существенно ниже, чем в системах с команд¬
ным языком. Использование дополнительных клавиш и комбина¬
ций с предписанной семантикой еще более улучшает ее.
Хорошей иллюстрацией сказанного служит система Frame¬
work. Функциональная клавиатура нагружена часто используемы¬
109
ми функциями, в основном связанными с положением информа¬
ции на экране: Help (справка), Drag (переместить), Сору (ко¬
пировать), Size (изменить размеры), Zoom (укрупнить) и др.
Основное меню в верхней строке экрана доступно через комбина¬
цию клавиши Ctrl с первой буквой пункта меню. За каждым
пунктом основного меню кроется целая связка команд — это до¬
полнительное меню, которое «ниспадает» (pull down) с выбран¬
ного пункта. Пункты «ниспадающего» меню выбираются пере¬
движением курсора (с подсказкой для каждого пункта) и нажа¬
тием клавиши ввода (такие связки меню были впервые предло¬
жены в операционной среде Smalltalk [32]). Определенные
вспомогательные клавиши выполняют частные операции погруже¬
ния во фрейм-окно и выхода из него. Таким образом, обширная
группа операций — более 50 — находится от пользователя сис¬
темы «на расстоянии» нескольких (как правило, 1—3 и не более
6) нажатий на клавиши с минимальной возможностью ошибочно¬
го выбора.
Поскольку меню и командные языки в известной мере допол¬
няют друг друга, в интерфейсе многих систем присутствуют оба
этих средства. Примерами могут служить программы MetaFile
[30], R : Base 5000 .[1], Infoscope [33] и др. При отсутствии аль¬
тернативы командного языка система меню становится чересчур
жесткой и начинают сказываться ее минусы [8, с. 184—185].
Авторы программы Infoscope [34] исходили из интересной тео¬
ретической предпосылки о том, что кроме двух основных типов
диалога (командный язык и меню) и соответствующих им катего¬
рий пользователей существует множество промежуточных вариан¬
тов взаимодействия и типов пользователей. Каждый пользова¬
тель овладевает программой постепенно, начиная хорошо разби¬
раться в одних вопросах, одновременно оставаясь новичком в
других. Решать проблему взаимодействия только в два уровня
сложно, если эти уровни никак не связаны между собой.
Отсюда возникает идея непрерывного, «плавного» интерфейса:
«пользователь переходит в экспертный режим, просто практи¬
куясь в качестве новичка» [34, с. 28]. Infoscope предлагает шесть
основных внутренне преемственных режимов работы: 1) меню
с расшифровкой и двумя способами выбора (в стиле программы
1—2—3); 2) команда-имя (имя команды набирается полностью,
ее параметры — через меню); 3) команда-предложение (в виде
обычной английской фразы); 4) команда-аббревиатура (преды¬
дущее с сокращениями слов); 5) синонимы (определяемые поль¬
зователем подстановки в виде синонимов или функциональных
клавиш); 6) командные файлы (группирование простейших дей¬
ствий в более сложные, имеющие единый смысл для искушенного
пользователя). На верхнем уровне все команды Infoscope орга¬
низованы в семь связок меню по 7—8 команд в каждом (в сти¬
ле Framework).
В [35] критикуются жесткие меню-системы, которым противо¬
поставляются программы с «человеческими инстинктами» типа
110
Infoscope: «Легкость в пользовании не сводится к числу нажа¬
тий на клавиши. Более важно время решения задачи и количест¬
во предпринятых при этом осмысленных шагов, а не подсчет опе¬
раций, имеющих какую-то значимость лишь для компьютера...».
Примером служит команда выборки FOCUS, которая допускает
последовательное применение критериев поиска, в том числе та¬
ких, как сходство по звучанию.
Необходимо отметить, что противопоставление командных язы¬
ков и меню относится скорее к характеру манипулирования с дан¬
ными. Что же касается содержимого данных, то, как правило, ис¬
пользуется режим прямого (экранного) редактирования, без до¬
полнительных команд, лишних нажатий клавиш — процесс, очень
похожий на работу в системе подготовки текстов.
Ввод и навигация по данным. Ввод данных может произво¬
диться двумя отличными друг от друга способами. Один, называ¬
емый разметкой экрана (Screen Painting), позволяет пользова¬
телю имитировать привычные бумажные формы; экран разме¬
чается с помощью движения курсора и задания имен и типов по¬
лей записи, после чего через созданный трафарет вводится содер¬
жимое записей (иногда трафарет может распространяться на не¬
сколько физических экранов ПЭВМ). Большинство систем позво¬
ляют определять несколько различных трафаретов для одного
типа записи, именовать и при необходимости быстро активизи¬
ровать.
Взгляд на запись через трафарет позволяет подробно рас¬
сматривать ее в той форме, в которой удобно пользователю.
Однако он не дает возможности одновременно наблюдать содер¬
жимое нескольких записей на экране.
Другой способ связан с табличным представлением информа¬
ции, заимствованным из электронных таблиц. Его основными до¬
стоинствами являются: естественное перемещение курсора, боль¬
шая обозримость информации (за счет, может быть, неполного
изображения), возможность перемещения текущего «окна про¬
смотра» по данным (scroll).
В наиболее развитых системах одновременно существуют и до¬
полняют друг друга оба способа. Это относится и к собственно
ПБД (Paradox и др.), и к интегрированным системам на базеЭТ
(Symphony).
Во многих системах среди атрибутов полей имеются характе¬
ристики, описывающие взаимодействие с пользователем: подсказ¬
ка, сообщение об ошибке и маска (шаблон ввода). Первая ис¬
пользуется в качестве расшифровки (уточнения) имени поля за¬
писи; второе выдается пользователю при несоответствии типа вво¬
димого значения с заданным типом поля; третья облегчает ввод
форматных значений с фиксированным текстовым наполнением
(например, телефонные номера).
Организация запросов к БД. В фундаментальном обзоре [36],
опубликованном еще до появления современных ПБД, были пред¬
ставлены экспериментальные результаты сравнительного изучения
111
известных языков запросов — IQF (Interactive Query Facility),
SQUARE, SEQUEL/SQL, QBE (Query by Example), TABLET:
необходимая продолжительность обучения, правильность форму¬
лирования запросов, время составления запроса, уверенность
пользователя в правильности запроса и др.
Все рассмотренные языки разработаны для запросов к реля¬
ционным базам данных. Ниже следуют примеры записи на раз¬
личных языках запроса «Выдать имена сотрудников старше 28
лет с зарплатой до 12 000 долларов, которыми руководит Уайт»:
IQF:
1. FROM employee FILE
2. FOR age 28 or more
3. AND FOR salary 12000 or less
4. AND FOR White manager
5. LIST name
SQUARE:
Emp «'12000',>'28','WHITE')
Name Sal, Age, Mgr
SEQUEL/SQL:
SELECT Name
From Emp
WHERE Sal <'12000'
AND WHERE Age >'28'
AND WHERE Mgr = 'WHITE'
QBE:
Emp Name Salary Age Manager
p. <12000 >28 WHITE
Более ранний язык IQF обнаружил и более слабые характе¬
ристики: продолжительность обучения в 3—4 раза дольше, пра¬
вильность в 2 раза ниже, составление запроса в 4—5 раз дольше
по сравнению с QBE. Из двух логических эквивалентных (и реля¬
ционно полных) языков SQUARE и SEQUEL первый — более
формален, второй же использует в качестве вспомогательных
обычные английские слова. Это облегчает его изучение и повы¬
шает процент правильно составляемых запросов. Язык TABLET,
также эквивалентный SEQUEL, отличается от него лишь тем, что
является процедурным. Это не влияет на правильность формули¬
рования запросов, но несколько увеличивает время обучения и
время формулирования.
В период интенсивного развития ПБД в 1983—1985 гг. язык
SEQUEL и его подмножества стали основой для языков запро¬
сов нескольких программ, в первую очередь реляционных ПБД
3-й и 4-й категорий (см. п. 2.1), среди которых KnowledgeMan
(SQL/DS) [5, с. 269—275], 10 Base {6, с. 204—205], R : Base
4000/5000 [6, с. 176—178]. Подобные по мощности и близкие по
синтаксису языки использованы во многих других программах.
Язык QBE характерен тем, что пользователю предлагается го¬
товая таблица, разграфленная по атрибутам, в которую нужно
лишь вписать ограничения запроса. Даже по сравнению с
SEQUEL, лучшим из остальных языков, он имеет более высокие
показатели по указанным параметрам, что видно из данных, при¬
веденных в {36, с. 186—187].
112
Язык QBE удовлетворяет рекомендациям, полученным на ос¬
нове экспериментальных исследований: «Пусть пользователь вы¬
бирает, а не набирает» и «Пусть пользователь вписывает запрос
прямо в формат, отражающий внутреннюю организацию данных»
,[36, с. 189]. Как видно из табл. 2, он дает довольно заметное по¬
вышение производительности и надежности работы пользовате¬
ля. Не случайно поэтому QBE был использован в такой высоко¬
производительной ПБД, как Paradox [37]. К языкам типа
SEQUEL он находится примерно в таком же отношении, как ме¬
ню — к командным языкам.
Таблица 2
Язык
Характеристика
время обу¬
чения, ч. мин.
количество
правильных
запросов, %
время состав¬
ления зап¬
роса, мин.
коэффициент
уверенности
Алгебраический
2,05
67,7
3,0
1,9
SEQUEL
1,40
72,8
2,5
1,9
QBE
1,35
75,2
0,9
1,6
Еще одно свойство, которое рекомендуется учитывать при раз¬
работке языков запросов, состоит в том, чтобы использовать и
исправлять предшествующий запрос, а также сохранять и извле¬
кать часто используемые виды запросов — свойство, достаточно
широко реализованное во многих ПБД. Формат запроса может
храниться в базе данных наряду с самими данными аналогично
формату печатной сводки или формату ввода записей.
В [7] на идее переформулирования запроса строится весь ин¬
терфейс с пользователем, которому дается возможность «крити¬
ковать» обнаруженные в базе данных записи. Пользователь ви¬
доизменяет запрос, имея хорошее представление как о структуре
данных, так и о конкретных значениях. Для сравнения: в QBE
пользователь может выбирать поле записи, но значение поля он
по-прежнему должен набирать.
Говоря о языках запросов, следует остановиться и на систе¬
мах с естественным языком (ЕЯ). В 70-е годы интерес к постро¬
ению БД с ЕЯ-интерфейсом был очень высок и в этом направле¬
нии велись интенсивные разработки. Достаточно вспомнить ра¬
боту Кодда [38]. Затем в рядах исследователей наступило изве¬
стное разочарование.
Появление ПЭВМ с развитыми средствами взаимодействия
нового типа (прямое редактирование в окнах, «ниспадающие» ме¬
ню, манипулятор «мышь»), казалось, снимает необходимость об¬
щения на ЕЯ и все прежние проблемы. Тем примечательнее воз¬
врат к естественно-языковым средствам общения, по крайней ме¬
ре в трех случаях.
Система CLOUT является ЕЯ-интерфейсом к ПБД R: Base
4000 [6, с. 176—178] и дает возможность формулировать запрос
Последовательным выбором подходящих английских слов. Хра¬
8 Заказ 5620
113
нимый в системе словарь позволяет контролировать правильность
формулирования. Программа SALVO ,[5, с. 225—228] из запро¬
са, сформулированного на ЕЯ, порождает программу на формаль¬
ном языке, по которому и выполняется запрос. Помимо прочего
это служит для пользователя способом изучения языка запро¬
сов SALVO. Наконец, в системе Q&A ,[10] также поддерживается
обработка запросов на языке, близком к естественному англий¬
скому.
Другие вопросы взаимодействия. Наличие внутреннего языка
программирования, как было сказано выше, отличает развитые
ПБД категорий 3 и 4. Это свойство ориентирует их в первую оче¬
редь на опытного пользователя.
Язык программирования практически всегда включает в ка¬
честве подмножества язык запросов, так что может рассматри¬
ваться как расширение последнего. Наиболее мощные програм¬
мы со средствами программирования представлены в качестве
высокопроизводительных реляционных ПБД на рис. 1.
Другим отличительным свойством развитых ПБД является
наличие средств определения пользователем собственных меню —
сценариев взаимодействия с системой, что, конечно, повышает гиб¬
кость системы по сравнению с жестким, заранее определенным
способом взаимодействия. В мощной ПБД R : Base 5000 такое
средство выступает в роли генератора приложений, позволяю¬
щего быстро создать специфическую схему диалога, не прибегая
к языку программирования: код программы будет порожден ав¬
томатически.
Среди средств пакетной обработки выделим два основных.
Определение макроклавиши — это способ связать последователь¬
ность клавиш с одной, выделенной. Нажатие макроклавиши вы¬
зывает те же действия, что и целая последовательность нажатий,
и позволяет заметно экономить время и усилия при работе с сис¬
темой. Макроклавиши нагружаются наиболее часто повторяемы¬
ми действиями на клавиатуре, например выполнением сложных
перемещений по дереву функций. Это макросредство повышает
скорость работы и в то же время избавляет от утомительного
выбора — одного из недостатков чистой меню-системы (п. 3.2).
Той же цели группирования и краткого вызова часто повто¬
ряющихся действий служат командные файлы, хранящие после¬
довательности команд. Эта возможность — средство простейше¬
го программирования.
Интерактивные справочные и обучающие средства — принад¬
лежность наиболее развитых систем. Они позволяют весь процесс
от первого знакомства с программой до полного овладения ею
проводить за компьютером, перемежая фактическую работу вы¬
дачей справок и практическими занятиями. Широко применяется
контекстная справка, которая содержит только информацию,
связанную с текущим состоянием диалога пользователя с про¬
граммой. Образцом интерактивного обучения являются системы
Symphony и Framework. Пользователь может не только прочи-
114
тать текст на экране, но и увидеть примеры практического вы¬
полнения функций системы, что невозможно при пользовании
традиционным справочным руководством.
Средства графического отображения в ПБД как таковых от¬
сутствуют, однако там, где есть тенденция к интеграции, графи¬
ка занимает свое законное место. Графические средства хорошо
развиты в Symphony и Framework. В KnowledgeMan графика
входит в виде дополнительного пакета (K-Graph). Ожидаются гра¬
фические возможности в новых версиях dBASE III. Интересные
графические средства имеются в специализированной системе
Javelin и экспериментальной программе RABBIT.
3.3. ПЕРЕНОСИМОСТЬ
Что касается переносимости программ, то здесь резкое влия¬
ние оказывает усиливающееся господство на рынке ПЭВМ ком¬
пьютеров фирмы ИБМ — IBM PC/XT (самая ходовая модель
ПЭВМ) и IBM PC/AT (усовершенствованная, более мощная и
дорогая модель). В последние годы все больше и активнее раз¬
рабатываются системы для конкретных ПЭВМ и конкретных опе¬
рационных систем, главным образом фирмы ИБМ. Такие разра¬
ботки отличаются большей эффективностью, лучшим использова¬
нием специфики машины (функциональная клавиатура, цвет, гра¬
фика, сопряжение с ОС и т. п.). Тем не менее некоторые системы,
например Dataplex [5, с. 253—255], поддерживаются на ПЭВМ
с различными микропроцессорами и различными ОС.
Наиболее популярная ОС PC DOS, основная ОС ПЭВМ серии
ИБМ. Так, по данным обзора журнала PC User [10], 45 упомя¬
нутых пакетов ориентированы на следующие ОС: 37—PC DOS,
16—СР/М-86, 6—UCSD. По данным журнала BYTE [9], из 47 па¬
кетов 38 ориентированы на PC DOS, 15 — на СР/М-86, 3 — на
UCSD (часть программ используется в нескольких ОС). За про¬
шедшее время эти цифры еще сильнее изменились в пользу
PC DOS. Так, перестала быть популярной переносимая ОС UCSD,
основанная на едином псевдокоде, но слабая по операционным
характеристикам, что определило участь и ориентированных на
нее ПБД.
Несколько ПБД работают в уникальных операционных сис¬
темах. Среди них — SAVVY PC [5, с. 220—222] и Revelation {5,
с. 246—248]. Первая насчитывает два десятилетия разработки, и
неудивительна ее приверженность к собственной операционной
среде. Вторая разработана для оригинальной ОС PICK, рассчи¬
танной на поддержку виртуальной памяти и специально ориенти¬
рованной на эффективную реализацию базы данных.
4. О ТЕНДЕНЦИЯХ РАЗВИТИЯ ПБД
В начальную пору возникновения рынка ПБД преобладал чисто
Коммерческий подход к их созданию. Появилось множество чрез-
8*
115
вычайно неравноценных по своим достоинствам программ, однако
оценить их непрофессиональный пользователь мог только в ходе
эксплуатации конкретной программы, судьба которой решалась,
таким образом, в конкурентной борьбе на рынке сбыта.
По данным, приводимым журналом PC Magazine [1], в 1984г.
на всех ПЭВМ, имеющихся в распоряжении пользователей в
США, эксплуатировалось около 2 млн. копий ПБД (в узком
смысле, т. е. собственно баз данных). Рыночная стоимость приоб¬
ретенных в 1984 году ПБД исчислялась в 240 млн. дол.
Предлагаемые пользователю пакеты весьма-неравноценны. По
тем же данным, только пятая часть из них реально конкурирует
на рынке, остальные почти не пользуются спросом. Два пакета
из каждых пяти, согласно статистике, в течение 5 лет заменяются
новыми.
В 1983—1984 г., когда кривая производства ПБД резко шла
вверх, сбыту программ отчасти помогала невысокая компетент¬
ность покупателя. Три четверти программ, продаваемых пользо¬
вателям, попадали в руки новичков. В последующие годы рынок
стабилизировался, выдвигались программы'-лидеры, более гра¬
мотным и разборчивым становился потребитель.
Среди прикладного программного обеспечения ПЭВМ. ПБД,
не включая ЭТ и интегрированные пакеты, составляют около
одной пятой (20% на американском рынке [3] и 18% —на евро¬
пейском [11] в 1984 г.). По прогнозам эта цифра в ближайшие
годы будет постепенно снижаться (согласно [3] до 14% в 1990 г.)
за счет роста продажи коммуникационных пакетов и специализи¬
рованных программ.
В ежегодном обзоре журнала PC World [3] дается прогноз
объема продажи ПБД в ближайшие 5 лет, согласно которому
рост за пятилетие составит около 50% по стоимости и более 80%
по количеству экземпляров. По другим данным такой рост может
быть меньше — до 15%.
В работе [39], вышедшей еще на раннем этапе развития ПБД,
была сделана попытка предсказать, какими свойствами должна
обладать полная система обработки информации. Еще до появле¬
ния интегрированных пакетов Framework и Symphony, в ней от¬
мечалось, что четыре компонента — база данных, электронная
таблица, графическая подсистема, текстовый процессор — обяза¬
тельны для достижения функциональной полноты. Среди этих
составляющих БД должна, по мнению автора, играть централь¬
ную роль: в нее поступает вся новая информация, которая в даль¬
нейшем может использоваться в различных целях: для анализа с
помощью ЭТ, генерации печатных сводок, наглядного отображе¬
ния в графическом виде на экране или бумаге и т. д.
Частичное осуществление и дальнейшее развитие этих идей
можно проследить в программе Javelin, с ее центральной инфор¬
мационной базой и возможностью разнообразных «точек зрения».
Другие предсказания, например, касающиеся простоты интерфей¬
116
са и учета уровня пользователя, были воплощены в таких про¬
граммах, как Infoscope.
Как было сказано и проиллюстрировано на примерах, глав¬
ные тенденции в развитии ПБД (и, пожалуй, программного обес¬
печения ПЭВМ в целом) проявляются в повышении уровня об¬
щения с пользователем и стремлении к функциональной полноте
или функциональной замкнутости программ. Последнее, впрочем,
таит в себе известное противоречие, поскольку полная независи¬
мость программы от окружения недостижима, да и полнота
функций всегда относительна. Поэтому действуют и другие тен¬
денции.
Одна из них — специализация программ, позволяющая, кста¬
ти говоря, обеспечить и более высокий во многих отношениях
уровень пользовательского интерфейса (примером снова может
служить Javelin). Другая — усиление роли средств электронной
связи (локальные сети, телекоммуникации), дающее возможность
преодолеть информационную изоляцию и получить доступ к дан¬
ным, которые могут поступить в индивидуальное распоряжение
любого пользователя ПЭВМ. Обе тенденции находятся в полном
соответствии с прогнозами по изменению структуры (пропорций)
производства программного обеспечения ПЭВМ.
ЛИТЕРАТУРА
1. Poor A. The Latest on Databases//PC Magazine.— 1985. — V. 4. — N 14.—
P. 139— 156.
2. Project DATA BASE: Part 3//PC Magazine. — 1984. — V. 3. — N 13.—
P. 147—192.
3. Whyte Ch. A Sense of Balance//PC World. Annual Review. — December
1985. —P. 286—295.
4.
Project
P. 213—
DATA BASE:
-269.
Part
2//PC
Magazine. —
1984. —V.
3. — N
12.—
5.
Project
DATA
BASE:
Part
7 // PC
Magazine. —
1984. —V.
3. — N
17.—
P. 218—
-279.
6.
Project
DATA
BASE:
Part
4//PC
Magazine. —
- 1984. —V.
3. — N
14.—
P. 169-
-211.
7.
Williams M. D.
What Makes
RABBIT
Run // Man-Machine Studies. — 1984. —
V. 21.-
-N 4.—
P. 333-
-352.
8. Project
DATA
BASE:
Part
5//PC
Magazine. —
1984. —V.
3. — N
15.—
p |59 212
9. A Data Base Catalog//BYTE. — 1984. — V. 9. — N 11. —P. 227—238.
10. Taylor M. All the Data on Databases//PC User. — August 1984. — P. 59—67.
11. Puuronen S. A. Survey of Some PC Programs//Personal Computers and their
Applications. — Tallin. Valgus, 1986. — P. 61—62.
12. Taylor J. The Bottom Line on Spreadsheets// PC Magazine.— 1985. — V. 4.—
N 12. —P. 150—155.
13. Rosenthal S. PC Filing: It’s in the Cards//PC Magazine.— 1984. — V. 3.—
N 7. — P. 349—350.
14. Spezzario Ch. Unconventional Outliners//PC World. — March 1986. — P. 168—
175.
15. Hershey W. MaxThink//BYTE. — 1985. — V. 10. —N 7. — P. 279—284.
16. Jadrnicek R., Markoff J., Shapiro E. Framework//BYTE.— 1984. — V. 9.—
N 8. —P. 121 — 123, 370—384.
17. McCraken D. L., Akscyn R. M. Experience with the ZOG Human-Computer
Interface System // Man-Machine Studies.— 1984. — V. 21. — N 4. — P. 293—
310.
18. Shapiro E. Text Databases//BYTE.— 1984. — V. 9. — N 11. — P. 147—150.
19. Atkins R. W., Mazur W. L. The DayFlo Architecture//BYTE. — 1984. — V. 9. —
N 11. —P. 155—162.
20. Urshel W. Javelin: Beyond Rows and Columns//PC World. — March 1986.—
P. 156—167.
21. Launching Javelin//PC World.— March 1986. — P. 144—149.
22. Jacobson B. DataBase Versus Condor and dBASE II//BYTE.— 1984.—
V. 9. —N 11. —P. 289—302.
23. Poor A. Cost-Effective Database Management//PC Magazine.— 1985.—
V. 4. —N 21. —P. 132—137.
24. Hart G. A. Touching Base with Database Managers//PC Magazine.— 1984.—
V. 3. —N 7. —P. 152—156.
25. Baras E. Symphony: A Community of Information//PC Magazine.— 1984.—
V. 3. — N 15.— P. 128—135.
26. Layman D. Framework: An Outline for Thought//PC Magazine.— 1984.—
V. 3. —N 15. —P. 118—125.
27. Crider B. Reinforced Framework//PC World. — March 1986. — P. 186—194.
28. Derfler F. J., jr. Prepare to Meet Your Т/Maker III//Magazine.— 1984.—
V. 3. —N 7. —P. 207—211.
29. Baras E. Jack2 Sprints to the Fore//Pc Magazine. — 1984.—V. 3. — N 14.—
P. 139—146.
30. Hughes G. D., jr. The Metaphysics of METAFILE//PC Magazine. — 1984.—
V. 3. — N 7. —P. 196—201.
31. Aarons R. Wising Up With KnowledgeMan//PC Magazine. — 1984. — V. 3.—
N 4. —P. 147—156.
32. Tester L. The Smalltalk Environment//BYTE. — 1981. — V. 6. — N 8. — P. 90—
147.
33. Derfler F. J., jr. A Scope for Your Micro//PC Magazine. — 1984. — V. 3.—
N 14. —P. 243—250.
34. Badre A. N. Designing Transitionality into the User-Computer Interface//
Human-Computer Interaction. — Amsterdam: Elsevier Science Publishers B.
V. — 1984. —P. 27—34.
35. Garber J. Infoscope’s Human Instincts//PC Magazine.— 1984.—V. 3.—
N 14. —P. 249.
36. Thomas J. C. Psychological Issues in the Design of Database Query Langu¬
ages//Designing for human-computer communication.—London: Academic
Press. — P. 173—206.
37. Baran N. M. A Most Ingenious: Paradox//PC World. — March 1986. — P. 176—
185.
38. Codd E. F. Seven steps to rendez-vous with casual user//IBM Research Re¬
port RJ 1333. — 1974. —21 p.
39. Brown M. J. The Complete Information Management System // BYTE. —
1983. —V. 8. — N 12. —P. 199—207.
УДК 681.3.06
О. Ю. ЕРЕМИН, Н. С. МАКСИМОВ, В. В. НАУМОВ, Г. В. ПЕЛЕДОВ
СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЕС ЭВМ
Общая информация. Программное обеспечение ЕС ЭВМ не¬
прерывно развивается в соответствии с внешними и внутренними
причинами, из которых можно выделить следующие основные:
повышение эффективности путем снижения системных затрат
на управление;
118
использование новых возможностей, предоставляемых техни¬
ческими средствами;
предоставление пользователям новых и расширение сущест¬
вующих функциональных возможностей;
учет мирового опыта;
повышение надежности программного обеспечения;
обеспечение преемственности в развитии программного обес¬
печения.
Последнее требование является обязательным и осуществля¬
ется обеспечением программной совместимости в процессе разви¬
тия отдельных компонентов. Таким образом обеспечивается пре¬
емственность «программного хозяйства», накопленного у пользо¬
вателей. В результате создаются предпосылки для эволюционного
характера развития программного обеспечения, в процессе кото¬
рого оно не только функционально развивается и совершенству¬
ется, но и повышается эффективность функционирования его ком¬
понентов. Более высокая эффективность достигается путем сни¬
жения временных затрат благодаря более эффективным алгорит¬
мам и улучшению характеристик технических средств. Так,
стремительное увеличение размеров памяти всех уровней, наблю¬
даемое в последнее время, позволяет реализовывать более эф¬
фективные алгоритмы управления. При этом расширение абсо¬
лютных размеров памяти для управляющей программы, как пра¬
вило, сочетается с уменьшением ее доли в общем объеме памяти.
Учет требований пользователей и мирового опыта требует
иногда отхода от эволюционного метода развития путем введе¬
ния новых компонентов, операционных и языковых сред. Так бы¬
ла введена среда системы виртуальных машин, среда типа UNIX,
вводятся новые языки и системы программирования. При таких
скачкообразных переходах отдельные «старые» компоненты мо¬
гут быть удалены. Однако даже при таких нововведениях при
проектировании по возможности предусматриваются средства,
облегчающие переход в новую среду, или наоборот.
В последние годы в составе ЕС ЭВМ появились новые сред¬
ства, сформировалось новое важное направление — персональные
и терминальные ЭВМ, оказавшие влияние на развитие программ¬
ного обеспечения ЕС ЭВМ.
Рассмотрим состав системных программных средств ЕС ЭВМ,
к которым относят обычно операционные системы, системы про¬
граммирования, а также системные пакеты программ, расширя¬
ющие возможности операционных систем.
До настоящего времени поставляется с моделями ЕС ЭВМ опе¬
рационная система ОС 6.1 ЕС исполнения 01. Развитие этой опе¬
рационной системы завершено. В последних модификациях уст¬
ранены ошибки и обеспечены новые технические средства. Эта
операционная система имеет три режима управляющей програм¬
мы (с фиксированным и переменным числом задач и режим вир¬
туальной памяти с одним виртуальным пространством). Диало¬
говые режимы обеспечиваются системами, включающими режимы
119
разделения времени (РРВ и СОЖ), а также диалоговый удален¬
ный ввод заданий (ДУВЗ). ОС 6.1 ЕС включает также старые
версии систем программирования для распространенных языков
программирования: ассемблер, Фортран, Кобол, ПЛ/1.
Уже несколько лет функционирует операционная система
СВМ ЕС (система виртуальных машин). СВМ ЕС вводит новую
операционную среду — среду виртуальных машин, являющихся
функциональными эквивалентами реальных ЭВМ с принципами
работы ЕС. Такая среда позволяет по-новому организовать вы¬
числительную систему. Так, на одной установке ЕС ЭВМ может
функционировать несколько операционных систем разных вер¬
сий в собственных виртуальных машинах, разделяя различными
способами реальные ресурсы. Кроме того, в состав СВМ ЕС вхо¬
дит ряд подсистем: подсистема диалоговой обработки (ПДО),
ориентированная на обслуживание одного пользователя в одной
виртуальной машине; подсистема дистанционной передачи файлов
(ПДП) и подсистема диалогового анализа дампов (ПАД). СВМ
ЕС позволяет использовать новые системы программирования,
поставляемые как отдельные изделия, для языков ассемблер,
Фортран (в том числе Фортран-77), Кобол, ПЛ/1, Паскаль.
Новая операционная система ОС 7 ЕС проектировалась с
целью решения ряда проблем, выявленных при использовании
ОС 6.1 ЕС:
повышение эффективности пакетного и диалогового режимов
в 1,5—2 раза;
упрощение использования и сопровождения системы;
обеспечение множества виртуальных пространств до 16 Мбайт
каждое (на основе концепции виртуальной машины);
обеспечение сетевой телеобработки данных.
В основу ОС 7 ЕС положена концепция виртуальной машины,
позволившая структурно упростить систему и решить упомяну¬
тые проблемы. Структура и особенности ОС 7 ЕС рассматрива¬
ются ниже. Отметим лишь, что операционная система содержит
в своем составе СВМ ЕС.
Завершена разработка мобильной операционной системы для
ЕС ЭВМ (МОС ЕС). Эта операционная система вводит новую
операционную среду типа UNIX, широко распространенную на
ЭВМ различного типа, в том числе и на СМ ЭВМ. МОС ЕС мо¬
жет функционировать непосредственно на ЭВМ ЕС, а также в
отдельной виртуальной машине, разделяя ресурсы с другими вир¬
туальными машинами (в среде СВМ ЕС или ОС 7 ЕС). В рам¬
ках МОС ЕС могут быть использованы системы программирова¬
ния для языков СИ, Фортран-77, Паскаль и ряд других компо¬
нентов, таких, как синтаксический анализатор для СИ, препро¬
цессор для Фортрана-77, генераторы синтаксических и лексичес¬
ких анализаторов, универсальный макрогенератор и т. д.
Терминальная ЭВМ ЕС 1007 является малой ЭВМ с принципа¬
ми работы ЕС ЭВМ «Ряд-3», реализованными в полном объеме.
120
Предназначена для работы в сетях ЭВМ, но может быть исполь¬
зована и самостоятельно. В качестве стандартного программного
обеспечения ЕС 1007, входящего в комплект поставки, выступает
СВМ ЕС, дополненная сетевыми функциями. СВМ ЕС дает воз¬
можность использовать ЕС 1007 в качестве малой универсальной
ЭВМ.
Персональная профессиональная ЭВМ ЕС1840 является пер¬
вой ЭВМ такого класса в Единой системе и может быть исполь¬
зована в автономном режиме, в локальных и глобальных сетях.
Программное обеспечение ЕС 1840 включает операционную систе¬
му М86, сервисные программы, систему программирования Бэйсик
М86 (интерпретатор языка), дополненную средствами графики,
пакет Абак для обработки информации в табличном виде. Обес¬
печивается возможность использования прикладных программ,
созданных для СР/М-86.
При работе с ЕС ЭВМ используются следующие языки про¬
граммирования:
ассемблер (две версии, в том числе универсальный макроге¬
нератор);
Фортран (три компилятора для ОС ЕС и СВМ ЕС);
Фортран-77 (три компилятора для ОС ЕС, СВМ ЕС и МОС
ЕС);
Бэйсик (М86);
ПЛ/1 (два компилятора для ОС ЕС и СВМ ЕС);
Кобол (два компилятора для ОС ЕС и СВМ ЕС);
РПГ-2 (для ОС ЕС);
Алгол-68 (для ОС ЕС);
Алгамс (для ОС ЕС);
Паскаль (для ОС ЕС и СВМ ЕС);
ЛИСП (для ОС ЕС и СВМ ЕС);
СИ (для МОС ЕС, разрабатывается для ОС ЕС);
Ада (разрабатывается для ОС ЕС, СВМ ЕС);
ПЛ/С (разрабатывается для ОС ЕС);
Фортран /С (разрабатывается для ОС ЕС);
Модула-2 (разрабатывается для ОС ЕС).
Более детально рассматриваются основная операционная сис¬
тема ОС 7 ЕС и системы обработки данных «Ока-ВС» и «Ка¬
ма-ВС».
Основные предпосылки и концепции разработки операционной
системы ОС 7 ЕС. С момента появления операционной системы
ОС ЕС происходили ее непрерывное развитие и модификация,
вызванные изменением номенклатуры технических средств
ЕС ЭВМ, расширением области применения ЕС ЭВМ и необхо¬
димостью в связи с этим обеспечивать в операционной системе
новые функциональные возможности и режимы работы. Долгое
время это развитие происходило без изменения основных, базо¬
вых концепций и принципов, заложенных в архитектуру и логику
работы ОС ЕС. Это привело к резкому увеличению ее объема и
сложности, что в свою очередь не могло не сказаться на произ¬
121
водительности и надежности работы всей вычислительной сис¬
темы.
С другой стороны, стремительный прогресс в технологии раз¬
работки аппаратуры привел к такому улучшению качественных и
количественных характеристик технических средств ЕС ЭВМ, ко¬
торое позволяло отказаться от ряда концепций и принципов, об¬
условленных малым объемом оперативной и внешней памяти, а
также низким быстродействием аппаратуры.
Однако отход от существующей операционной системы и раз¬
работка новой системы на базе новых возможностей и идей были
невозможны в силу следующих причин:
у пользователей накоплен большой программный задел, ко¬
торый требует сохранения старой операционной среды;
разработка новой системы связана с большими затратами и
не может быть выполнена в приемлемые сроки без снижения на
первых этапах ее эксплуатации надежности работы и объема ус¬
луг, предоставляемых пользователю, по сравнению с существую¬
щей.
Возможным способом преодоления этого противоречия пред¬
ставлялось использование концепции виртуальной машины, реа¬
лизуемой монитором виртуальных машин (МВМ) операционной
системы СВМ ЕС, в качестве основы для дальнейшего развития
всего программного обеспечения ЕС ЭВМ. Суть данного подхода
заключается в том, что все программное обеспечение, включая и
операционную систему, делится на специализированные, функцио¬
нально ориентированные подсистемы, функционирующие в своих
виртуальных машинах и имеющие достаточно простой, унифици¬
рованный интерфейс друг с другом. По сравнению с традицион¬
ным методом развития данный метод, основывающийся на функ¬
циональной декомпозиции программного обеспечения, имеет та¬
кие преимущества, как полная преемственность программного
обеспечения и возможность независимого развития отдельных
компонентов программного обеспечения с минимальным воздей¬
ствием изменений в одном из компонентов на все остальные.
В результате повышается гибкость системы и степень ее адапти¬
руемости к различным областям применения и новым техническим
средствам.
Другой особенностью системы, построенной по принципу функ¬
циональной декомпозиции, является то, что функциональные под¬
системы, реализуемые в отдельных виртуальных машинах и име¬
ющие с остальной системой интерфейсы, аналогичные интерфей¬
сам между техническими средствами, могут служить прообраза¬
ми, моделями специализированных аппаратурных компонентов,
реализующих те или иные функции программного обеспечения.
Практическое применение этого метода требовало решения до¬
статочно сложных задач. Первой из них была разработка опера¬
ционной системы, которая обеспечивала бы выполнение в вирту¬
альной машине всех программ, которые могли выполняться под
управлением ОС ЕС на реальной ЭВМ без снижения производи¬
122
тельности. Поэтому первым шагом в разработке ОС 7 ЕС была
разработка операционной системы, получившей название базовая
операционная система (БОС). Являясь подсистемой ЕС 7 ЕС,
БОС функционирует в отдельной виртуальной машине и обеспе¬
чивает традиционную операционную среду ОС ЕС.
Базовая операционная система ОС 7 ЕС. В качестве исходной
версии для разработки БОС был взят режим СВС операционной
системы ОС 6.1 ЕС. Однако, как показали эксперименты, при ра¬
боте этой операционной системы в виртуальной машине проис¬
ходило резкое снижение производительности вычислительной сис¬
темы за счет накладных расходов, которые складывались в ос¬
новном из затрат на анализ и моделирование в виртуальной ма¬
шине привилегированных команд и прерываний и из затрат на
двойное управление системными ресурсами. Например, двойное
листание виртуальной памяти и двойная буферизация для уст¬
ройств единичных записей на внешней памяти.
Для сокращения этих накладных расходов были сделаны сле¬
дующие изменения.
1. Исключен механизм поддержки виртуальной памяти.
2. Управляющая программа переведена на работу в базовом
режиме управления (ВС) вместо расширенного (ЕС).
3. Так как объемы реальной оперативной памяти современ¬
ных моделей ЕС ЭВМ достаточны для того, чтобы монитор вир¬
туальных машин мог обеспечить эффективную работу виртуаль¬
ной машины с виртуальной основной памятью объемом в
16 Мбайт, управляющая программа ОС ЕС была настроена на
работу с такой памятью. Эта настройка включала в себя:
удаление динамических связей между модулями основных
компонентов управляющей программы путем размещения моду¬
лей в ядре операционной системы. Это позволило значительно
снизить число SVC-прерываний и привилегированных команд, ко¬
торые были вызваны необходимостью подкачки нерезидентных
модулей операционной системы из внешней памяти в оператив¬
ную;
увеличение размеров блоков и количества буферов при выпол¬
нении операций ввода-вывода; это позволило уменьшить число
команд ввода-вывода, используемых в виртуальной машине, и
число прерываний, отображаемых в нее;
введение статического распределения памяти вместо динами¬
ческого под рабочие области управляющей программы, что поз¬
волило значительно снизить число наиболее часто используемых
команд обращения к супервизору памяти (SVC10).
Исключены программы и коды, обеспечивающие другие режи¬
мы работы ОС ЕС (MVT/MFT и др.) и функциональные возмож¬
ности, которые либо устарели, либо обеспечиваются другими
средствами (удаленный ввод заданий, режим разделения времени
и др.). Это позволило значительно сократить объем БОС, упрос¬
тить структуру управляющей программы и генерацию конкрет¬
ного варианта БОС. Генерация выполняется на основе некоторого
123
стандартного варианта БОС, являющегося основой дистрибутив-
ной системы, поставляемой пользователю.
Базовая операционная система функционирует в виртуальной
машине, создаваемой системой виртуальных машин (СВМ ЕС)
в вычислительных системах на базе технических средств ЕС ЭВМ
«Ряд-2» и «Ряд-3».
В состав вычислительной системы, предназначенной для функ¬
ционирования БОС, должен входить следующий минимальный
набор технических средств:
центральный процессор с оперативной памятью не менее
1 Мбайта;
байт-мультиплексный канал ввода-вывода;
блок-мультиплексный или селекторный канал ввода-вывода;
шесть накопителей на магнитных дисках емкостью 29 Мбайт
или четыре НМД емкостью от 100 Мбайт и выше;
четыре накопителя на магнитных лентах;
пульт управления ЭВМ;
одно печатающее устройство;
одно устройство ввода с перфокарт.
Виртуальная машина, в которой работает БОС, должна
включать:
виртуальную память размером от 3 до 2048 Мбайт;
виртуальный пульт управления;
один виртуальный НМД, на котором установлен резидентный
том БОС.
Кроме того, в состав виртуальной машины должны входить
реальные и виртуальные ресурсы, необходимые для выполнения
заданий пользователей.
Экспериментальные исследования, проведенные Мячи-
ным В. Н., дали результаты, которые иллюстрируют достигнутые
показатели эффективности и снижения системных затрат. Экспе¬
римент проводился путем выполнения одного и того же пакета
типичных заданий под управлением ОС 6.1 ЕС (МВТ, СВС) и
ОС 7 ЕС (БОС). Измеряемые параметры и результаты измере¬
ний приведены в таблице:
Измеряемые параметры
Версия ОС
ОС 6.1 ЕС
МВТ
ОС 6.1 ЕС
СВС
ОС 7 ЕС
БОС
Число SVC-прерываний:
во время работы системы
12 034
9 027
3 263
во время работы задачи пользова¬
теля
1971
1887
728
Всего SVC-прерываний
14 005
10 914
3 991
Число прерываний ввода-вывода
5 591
1 842
36
Время выполнения пакета заданий, с
117,42
80,14
12,67
Время центрального процессора, с
12,39
17,86
11,46
Следует отметить, что измерения проводились в ранней вер¬
сии ОС 7 ЕС; в текущей версии достигнуто еще большее сниже-
124
ние системных накладных расходов, особенно времени централь¬
ного процессора.
Основные функционально ориентированные подсистемы, вхо¬
дящие в ОС 7 ЕС. В настоящее время в состав ОС 7 ЕС входят
традиционные компоненты СВМ ЕС и новые, разработанные в
рамках ОС 7 ЕС. К последним относятся:
базовая операционная система (БОС);
подсистема сетевой телеобработки данных (ПСТ), которая
обеспечивает все функции сетевой и системной телеобработки дан¬
ных, имеющиеся в общем телекоммуникационном методе досту¬
па. При этом ПСТ позволяет распределить обработку в приклад¬
ных программах по разным виртуальным машинам, в которых
работают БОС или ПДО;
подсистема управления консолями позволяет иметь до 32-х
консолей оператора БОС, в качестве которых используются пуль¬
ты виртуальных машин.
В настоящее время в стадии завершения находится ряд функ¬
циональных подсистем, значительно расширяющих возможности
ОС 7 ЕС и повышающих надежность ее функционирования. При¬
мерами таких подсистем могут служить подсистема передачи за¬
даний через сеть и подсистема управления работой вычислитель¬
ного комплекса, состоящего из нескольких реальных ЭВМ.
Перспективы развития ОС 7 ЕС. В настоящее время работы
по развитию операционной системы ОС 7 ЕС ведутся в направ¬
лении решения традиционных задач, стоящих перед разработчи¬
ками операционных систем:
повышение надежности работы вычислительной системы, что
включает в себя решение задачи эффективного восстановления
вычислительного процесса при сбоях аппаратуры, а также реше¬
ние задачи повышения надежности программного обеспечения,
выявление и исправление ошибок в нем;
повышение производительности работы вычислительной систе¬
мы за счет уменьшения затрат на работу операционной системы и
повышения эффективности алгоритмов управления системными
ресурсами;
расширение функциональных возможностей операционной сис¬
темы и объема услуг, предоставляемых пользователям.
Для операционной системы ОС 7 ЕС характерно комплекс¬
ное решение этих задач. Как правило, каждое направление раз¬
вития ОС 7 ЕС в той или иной мере способствует решению всех
основных задач. Особо следует выделить задачу повышения на¬
дежности функционирования вычислительной системы, как имею¬
щую первостепенное значение.
Одно из наиболее важных направлений развития ОС 7 ЕС
связано с понятием внутреннего псевдодиска. Особенно большое
значение это направление имеет для решения задачи повышения
надежности.
Традиционным методом восстановления вычислений, прерван¬
ных в результате аппаратурного или программного сбоя, явля¬
125
ется создание контрольных точек, с которых после сбоя возобнов¬
ляется вычислительный процесс. Однако в силу большого много¬
образия программ и данных, участвующих в вычислительном про¬
цессе, и необходимости синхронизовать их состояние в момент соз¬
дания контрольной точки эта процедура требует значительных
затрат вычислительных ресурсов и не может выполняться очень
часто. А это приводит к потере значительных объемов работы,
выполненной от момента создания контрольной точки до момента
сбоя. Кроме того, немалые усилия и ресурсы необходимы для
возобновления вычислительного процесса с контрольной точки.
Использование внутренних псевдодисков для размещения дан¬
ных и программ сводит это многообразие к одному объекту —
виртуальной памяти, что значительно упрощает процедуру созда¬
ния контрольной точки и позволяет выполнять ее автоматически
средствами монитора виртуальных машин. Для построения конт¬
рольной точки монитору достаточно сохранить во внешней памя¬
ти все изменения, которые произошли в виртуальной памяти к мо¬
менту получения контрольной точки, регистры и слово состояния
программы виртуальной машины в данный момент. В случае пре¬
кращения работы СВМ или виртуальной машины работа этой
виртуальной машины может быть продолжена с момента послед¬
него обновления ее состояния во внешней памяти. Как показали
исследования и эксперименты, использование такого режима уп¬
равления виртуальной памятью не приводит к снижению произво¬
дительности БОС и всей вычислительной системы, а в ряде слу¬
чаев и повышает ее. Использование внутренних псевдодисков и
режима обновления для управления виртуальной памятью поз¬
воляет восстанавливать выполнение вычислительного процесса с
минимальными потерями и за максимально короткое время.
Сказанное, однако, не означает, что задача восстановления
вычислительного процесса в ОС 7 ЕС решена полностью. Вычис¬
лительный процесс очень часто включает в себя компоненты, ра¬
ботающие асинхронно по отношению к виртуальной машине, в
которой этот процесс выполняется (например, реальные устрой¬
ства ввода-вывода, удаленные пульты и т. д.). Поэтому в настоя¬
щее время в ОС 7 ЕС ведутся работы по обеспечению синхрони¬
зации состояния виртуальной машины и всех внешних по отноше¬
нию к ней компонентов, участвующих в вычислительном процес¬
се, на момент обновления состояния ВМ и в момент возобновле¬
ния процесса с точки последнего обновления.
Другим важным направлением работ является обеспечение
эффективных средств взаимодействия виртуальных машин. В на¬
стоящее время этот вопрос приобретает все большее значение, так
как его успешное решение во многом определяет и дальнейшую
возможность развития ОС 7 ЕС в направлении функциональной
декомпозиции программного обеспечения.
Как уже говорилось ранее, в СВМ ЕС имеются стандартные
средства организации взаимодействия между виртуальными ма¬
шинами. Например, адаптер канал — канал (реальный или вир¬
126
туальный) используется для связи БОС с подсистемой обеспече¬
ния консолей, спул-файлы — для связи подсистемы РОС с вирту¬
альными машинами, работающими на той же реальной ЭВМ. Для
связи БОС с подсистемой сетевой телеобработки (ПСТ) исполь¬
зуется интерфейс память-память. Однако применение этих средств
связи ограничивается достаточно большими накладными расхода¬
ми на их реализацию, а также трудностями по синхронизации со¬
стояния виртуальных машин при работе в режиме повышенной
надежности.
Поэтому в ОС 7 ЕС разрабатываются средства связи, основан¬
ные на механизме разделенных сегментов. Ожидается, что они бу¬
дут лишены недостатков традиционных средств связи и позволят
организовать эффективное взаимодействие подсистем.
Системные пакеты «Ока-ВС» и «Кама-ВС». В программном
обеспечении ЕС ЭВМ «Ряда-3» по-прежнему важную роль про¬
должают играть системные пакеты программ, расширяющие воз¬
можности операционой системы. Число таких пакетов продол¬
жает увеличиваться. Одной из основных задач, решаемых с по¬
мощью системных пакетов программ, является обеспечение
средств организации систем обработки данных. К таким пакетам
относятся системы управления базами данных и системы телеуп¬
равления данными. В состав этих пакетов включены система уп¬
равления базами данных «Ока-ВС» и система телеуправления
данными «Кама-ВС», прошедшие совместные испытания в 1986 г.
Эти системы представляют собой развитие известных систем
«Ока» и «Кама» [1,2] в направлении повышения эффективности
применения в больших системах обработки данных, улучшения
надежностных характеристик и развития функциональных воз¬
можностей.
Наряду с улучшением характеристик, определяющих пропуск¬
ную способность систем обработки данных и число одновремен¬
но обслуживаемых абонентских пунктов, в системах «Ока-ВС» и
«Кама-ВС» обеспечен ряд новых функциональных возможнос¬
тей, отличающих их от предшествующих пакетов.
Система «Ока-ВС» относится к классу систем управления ба¬
зами данных, имеющих собственные средства теледоступа. Кроме
того, теледоступ к системе «Ока-ВС» может быть обеспечен с по¬
мощью системы телеуправления данными «Кама-ВС». Средства
управления базами данных системы «Ока-ВС» обеспечивают опи¬
сание структуры баз данных, создание, обслуживание, реоргани¬
зацию и доступ к ним, восстановление данных. Введена новая
функциональная возможность ведения контрольных точек для ре¬
жима «база данных». Система содержит ряд сервисных программ,
с помощью которых обеспечивается описание и ведение баз дан¬
ных. В систему введена универсальная сервисная программа UCF,
Позволяющая выполнять большинство из функций сервисных про¬
грамм в одном пункте задания. Средства «контрольной точки —
Повторного старта» универсальной сервисной программы позво-
127
ляют прерывать ее выполнение с последующим продолжением
с последней контрольной точки.
По сравнению с системой «Ока» система «Ока-ВС» предостав¬
ляет пользователю ЭВМ ряд новых возможностей, основанных
на использовании технических и программных средств ЕС ЭВМ
«Ряда-2». В системе «Ока-ВС» для ведения баз данных и до¬
ступа к ним может использоваться виртуальный метод доступа
ОС ЕС. Его применение для баз данных позволяет за счет ис¬
пользования механизма разделения ресурсов (буферов и управ¬
ляющих блоков) сократить требования системы к памяти ЭВМ.
Для таких баз данных обеспечивается вторичное- индексирование,
возможность работы с сегментами переменной длины. Возмож¬
ность ведения сегментов переменной длины лучшим образом удов¬
летворяет требованиям пользователя ЭВМ при обработке и хра¬
нении данных переменной длины.
В системе «Ока-ВС» прикладным программам предоставляет¬
ся возможность работы с наборами данных операционной сис¬
темы BSAM и VSAM ESDS как с базами данных. Для этого в
систему «Ока-ВС» введен общий последовательный метод досту¬
па GSAM. Такой подход позволяет упростить процессы загрузки
баз данных прикладными программами.
Система «Ока-ВС» предназначена для управления большими
базами данных на средних и больших ЭВМ. Для более эффек¬
тивной настройки, выявления «узких мест», проектирования. баз
данных и прикладных программ, распределения ресурсов в ней
предусмотрен монитор трассировки, позволяющий регистриро¬
вать внутренние события в управляющем и в зависимых разделах
системы, формировать и выводить в отредактированном виде со¬
ответствующий отчет. В системе реализована возможность парал¬
лельного планирования одной и той же программы для одновре¬
менной обработки в нескольких разделах. Для повышения надеж¬
ности восстановления баз данных в системе предусмотрен режим
дублирования системного журнала.
В системе «Ока-ВС» также расширены возможности средства
передачи данных. Для управления передачей данных используют¬
ся методы доступа ГМД и БТМД операционной системы ОС ЕС
и обеспечивается функционирование дисплейных комплексов
ЕС7906, ЕС7920-01, ЕС7920-11 и устройств, совместимых с ними.
Средства передачи данных обеспечивают передачу сообщений, их
форматирование, защиту ресурсов, страничный вывод на дисплей¬
ные абонентские пункты, аппарат контрольной точки — повторно¬
го старта, диалоговый режим взаимодействия с прикладной про¬
граммой, выполнение команд управления системой.
Система «Кама-ВС» является телекоммуникационно-управля¬
емым интерфейсом между прикладными программами пользова¬
теля и операционной системой ОС ЕС. Система «Кама-ВС» ори¬
ентирована на применение на моделях ЕС ЭВМ, использующих
виртуальную память, с большим числом абонентских пунктов,.
В ней сняты многие ограничения на размер загрузочных модулей
128
прикладных программ (с 32 до 256 Кбайт), что позволяет расши¬
рить область применения системы в качестве телемонитора для
ряда систем управления базами данных.
В систему введены средства восстановления для обеспечения
работы большого числа пользователей. Для регистрации событий
в системе «Кама-ВС» ведется системный журнал. Кроме этого,
пользователи системы могут использовать собственные журналы.
В случае аварийного завершения транзакции системой преду¬
сматривается откат данных и возможность повторного запуска
транзакции.
В системе «Кама-ВС» обеспечена возможность работы при¬
кладных программ с наборами данных расширенного виртуаль¬
ного метода доступа. В этом случае обеспечивается доступ к дан¬
ным в прямом и обратном направлениях, альтернативное индек¬
сирование, работа с записями переменной длины. Виртуальный
метод доступа ОС ЕС используется системой для организации
транзитных данных. В систему «Кама-ВС» введены средства про¬
граммирования на уровне команд, что позволяет повысить произ¬
водительность труда прикладных программистов, упростить струк¬
туру прикладной программы. При разработке прикладных про¬
грамм обеспечена возможность использования языков програм¬
мирования ассемблер, Кобол, ПЛ/1 операционных систем ОС ЕС
изданий 6.1 и 7. В систему включены средства трассировки, уп¬
равления и редактирования дампов транзакций. Система «Кама-
ВС» содержит интерфейсные средства для работы прикладных
программ с СУБД «Ока-ВС».
Обе системы ориентированы на работу в интерактивном режи¬
ме, и их использование позволяет расширить функциональные воз¬
можности операционных систем ЕС ЭВМ при построении систем
обработки данных.
ЛИТЕРАТУРА
1. Системы управления базами данных для ЕС ЭВМ. Справ, изд. / Под ред.
В. М. Савинкова. — М.: Финансы и статистика, 1985. — 224 с.
2. Прикладное программирование в системе КАМА / В. А. Кувыкпн, И. Г. Ко¬
валь, М. И. Кувыкина и др. — М.: Финансы и статистика, 1983. — 271 с.
УДК. 681.3
О. М. ВЕННЕРОВ, В. М. САВИНКОВ, Н. В. ЖАДАН, М. С. НАЗАРОВ
МИФОЛОГИЧЕСКАЯ МОДЕЛЬ В СИСТЕМЕ
АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ
БАЗ ДАННЫХ: КОНЦЕПЦИИ И РЕАЛИЗАЦИЯ
Мифологическая модель в САПР БД «Омега». Настоящая
Статья является продолжением [1]. В ней рассматривается ин¬
фологическая модель (ИЛМ), поддерживаемая системой авто¬
9 Заказ 5620
129
матизированного проектирования баз данных (САПР БД) «Оме¬
га» и построенная в соответствии с концепциями ,[1]. Особеннос¬
ти предлагаемой вниманию читателя версии ИЛМ. определяются
выбранным подмножеством целевых даталогических моделей дан¬
ных (модели данных, поддерживаемые СУБД ОКА и СЕТЬ).
Кроме того, средства спецификации запросов ограничиваются вто¬
рым из охарактеризованных в [1] типом (приближенное проце-
дуральное- описание).
Основным режимом взаимодействия проектировщика БД с
системой «Омега» является режим диалога. В силу этого процесс
создания конкретного инфологического описания поддерживает¬
ся техникой «меню», «подсказки», управляемой пользователем
подстановки «стандартных» элементов спецификационных конст¬
рукций. Пользователь располагает достаточно гибкими средства¬
ми произвольного доступа к фрагментам описания и параллель¬
ного их просмотра, редактирования описания и т. п. Такая тех¬
нология оказала существенное влияние на ряд принципов пост¬
роения языка инфологической спецификации и нашла свое отра¬
жение, в частности, в форме широкого использования конструк¬
ций естественного языка (без трансформации передаваемого ими
смысла) и отказа от традиционной лаконичности в пользу нагляд¬
ности и простоты интерпретации. Характеризуемые ниже языко¬
вые средства составляют совокупность, достаточную для представ¬
ления результатов синтеза инфологического описания в отчетах,
отображаемых на экране дисплея или выводимых на устройство
формирования твердой копии. В то же время представляемая
версия ИЛМ является неизбыточной, так как она содержит толь¬
ко такие компоненты, которые имеют интерпретацию хотя бы в
одной из целевых даталогических моделей (по причинам, ука¬
занным в .[1], интерпретация может быть неполной). Полагаясь
на профессиональную интуицию читателя, мы не приводим
здесь малополезную (исходя из преследуемых данной статьей
целей) формальную нотацию базовых конструкций и опускаем
для упрощения некоторые непринципиальные детали синтаксиса,
а порой несколько трансформируем их.
Структура инфологического описания предметной области
Мифологическое описание предметной области состоит из
статей следующих типов:
статьи идентификации (модели) области;
статьи идентификации (модели) подобласти (фрагмента пред¬
метной области);
статьи класса объектов;
статьи отношений между классами;
статьи спецификации запроса;
статьи заголовка композиции фрагментов.
Конкретное инфологическое описание содержит только один
экземпляр статьи идентификации модели, которым начинается
глобальное описание.
130
Описание каждого фрагмента предметной области начинается
экземпляром статьи идентификации фрагмента и продолжается
до следующего экземпляра такого же типа. Тело описания состо¬
ит из произвольного числа экземпляров статьи класса объектов
(обязательная статья), статьи отношений между классами (не¬
обязательная статья), статьи спецификации запроса (необяза¬
тельная статья). Статьи перечисляются в порядке следования в
описании фрагмента.
Описание предметной области завершается, описанием ком¬
позиции фрагментов. Начальной статьей здесь является статья —
заголовок композиции. Далее следуют экземпляры статьи клас¬
сов объектов (необязательная статья), статьи отношений между
классами объектов, статьи спецификации запроса (необязатель¬
ная статья). Заметим, что в данном случае объекты, о которых
идет речь в статье отношений между классами, — это объекты, спе¬
цифицируемые в различных фрагментах; объекты, упоминаемые в
статье классов объектов, — это объекты, «достраиваемые» в це¬
лях композиции фрагментов, а запросы — это запросы, которые
реализуются на интегрированном представлении совокупности
объектов предметной области.
В описании конструкций языка используем традиционные при¬
емы представления синтаксиса. Так, заключение конструкций в
квадратные скобки означает необязательность ее употребления,
в фигурные — альтернативность, обрамление конструкций двой¬
ными прямыми скобками означает возможность употребления их
комбинаций. Многоточие означает возможность повторения пред¬
шествующей конструкции, которая должна быть заключена в
квадратные, фигурные или прямые скобки.
Статья идентификации модели предметной области
Формат статьи:
МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ <идентифнкатор-модели>
ВЕРСИЯ <идентификатор-версии>
ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ <произвольный-текст>
Текст, приводимый в последней фразе статьи, не контролиру¬
ется. Рекомендуется, однако, чтобы этот текст содержал краткое
семантическое описание предметной области, полезное для вери¬
фикации и контроля формальных спецификаций модели.
Аналогичные функции связываются с употреблением произ¬
вольного текста и далее.
Статья идентификации фрагмента модели
Формат статьи:
ФРАГМЕНТ МОДЕЛИ <идснтификатор-фрагмента>
ИСТОЧНИК (произвольный текст-указатель-источника>
ХАРАКТЕРИСТИКА ПОДОБЛАСТИ <произвольпый-текст>
9*
131
Статья класса объектов
Экземпляры статьи класса объектов следуют непосредствен¬
но за статьей идентификации фрагмента (до статьи отношений
между объектами) и определяют типы объектов, принадлежащих
данной подобласти.
Статья состоит из следующих подстатей: подстатьи идентифи¬
кации класса; подстатьи определения атрибута; подстатьи иден¬
тификации объекта; подстатьи внутренних семантических свойств
объекта; подстатьи категории объекта и подстатьи квантитатив¬
ных характеристик.
Подстатья идентификации класса
Формат подстатьи:
КЛАСС ОБЪЕКТОВ <имя-класса>
ХАРАКТЕРИСТИКА КЛАССА <произвольный-текст>
Подстатья определения атрибута
Формат подстатьи:
АТРИБУТ <имя-атрибута>
ХАРАКТЕРИСТИКА АТРИБУТА <произвольный-текст>
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ <имя-класса>
[ЗНАЧЕНИЕ [НЕ] {деЖИТ В* ДИАПАЗОНЕ ОТ <литерал> ДО <литерал> } ' • J
[ОДНОЗНАЧНЫЙ )
МНОГОЗНАЧНЫЙ, СРЕДНЕЕ ЧИСЛО ПОВТОРЕНИЙ — <целое-без-
знака)
Предложение «ЗНАЧЕНИЕ...» употребляется только в случае
атрибута, определенного на одном из классов, «встроенных» в
модель. Таковыми являются строковые и числовые классы различ¬
ных типов. Во всех других случаях ограничение области опре¬
деления атрибута осуществляется посредством выделения соответ¬
ствующего подкласса. Применительно же к встроенному классу
определение такого подкласса, который в соответствии с уста¬
навливаемыми ИЛМ правилами моделирования должен быть
объявлен автономным классом, малоестественно: сам по себе он,
как правило, слабосемантичен и приобретает семантическую окрас¬
ку только в контексте другого класса.
Спецификация отношений агрегации, которая осуществляется
этой статьей, имеет два следствия:
1. Полное удаление объекта из класса, на котором опреде¬
лен атрибут, приводит к тому, что соответствующее значение ат-
рибута заменяется на значение НЕ ОПРЕДЕЛЕНО.
2. Если не оговорено, что добавление в класс, на котором оп¬
ределен атрибут объекта, производится только с учетом контек¬
ста атрибута объекта (т. е. новый экземпляр класса должен по¬
132
явиться как значение атрибута, определенного на этом классе,
см. далее), то атрибут может принимать только значение, соот¬
ветствующее уже существующему экземпляру класса.
Экземпляры данной подстатьи, следующие после экземпляра
подстатьи идентификации класса, определяют атрибуты объекта
конкретного типа.
Подстатья идентификации объекта
Формат подстатьи:
ОБЪЕКТ ИДЕНТИФИЦИРУЕТСЯ АТРИБУТАМИ <имя-атрибута [, имя-ат-
рибута-1] ...у [ИЛИ АТРИБУТАМИ (имя-атрибута-2 [, имя-атрибута-3] ...>]...
Подстатья не является обязательной. Иными словами, допус¬
кается наличие объектов, значения всех атрибутов которых сов¬
падают.
Подстатья внутренних семантических свойств объекта
Формат подстатьи:
АТРИБУТЫ (имя-атрибута [,имя-атрибута-1 ]. . .) ВЗАИМОСВЯЗАНЫ (Т) >
[(имя-атрибута-2 [,имя-атрибута-3]. . .) [ОДНОЗНАЧНО [
[МНОГОЗНАЧНО]
ОПРЕДЕЛЯЕТ (имя-атрибута-4 [,имя-атрибута-5]. . .) ] @
[ЕСЛИ ЗНАЧЕНИЕ АТРИБУТА (имя-атрибута [,имя-атрибута-1 ]. . .)
СТАНОВИТСЯ НЕОПРЕДЕЛЕННЫМ, ТО И ЗНАЧЕНИЕ АТРИБУТА (имя-
атрибута-2 [,имя-атрибута-3]. . .) СТАНОВИТСЯ НЕОПРЕДЕЛЕННЫМ]. . .(3) ►
[ЗНАЧЕНИЕ АТРИБУТА (имя-атрибута [,имя-атрибута-1 ]. . .)
МОЖЕТ БЫТЬ ОПРЕДЕЛЕННЫМ ТОЛЬКО, ЕСЛИ ЗНАЧЕНИЕ АТРИБУТА
(имя-атрибута-2 [,имя-атрибута-3]. . .) БЫЛО ИЛИ ОДНОВРЕМЕННО
СТАНОВИТСЯ ОПРЕДЕЛЕННЫМ] ... ®
[ПРИНИМАЮТ II ОПРЕДЕЛЕННОЕ II ЗНАЧЕНИЕ ТОЛЬКО СОВМЕСТНО]@
НнеопределенноеИ - ■
[АТРИБУТЫ (имя-атрибута [,имя-атрибута-1 ]. . .) ВСЕГДА ОПРЕДЕЛЕННЫ] ®.
[АТРИБУТЫ (имя-атрибута [,имя-атрибута-1 ]. . .) НЕПОСРЕДСТВЕННО (7)
НЕМОДИФИЦИРУЕМЫ]. . .
[АТРИБУТАМ < имя-атрибута [,имя-атрибута-1 ]. . .) НЕ МОЖЕТ
БЫТЬ НЕПОСРЕДСТВЕННО ПРИСВОЕНО ОПРЕДЕЛЕННОЕ ЗНАЧЕНИЕ] . . . (8)
[АТРИБУТАМ (имя-атрибута [,имя-атрибута-1 ]. . .) НЕ МОЖЕТ
БЫТЬ НЕПОСРЕДСТВЕННО ПРИСВОЕНО НЕОПРЕДЕЛЕННОЕ ЗНАЧЕНИЕ] . Ут
[АТРИБУТ (имя-атрибута) ЯВЛЯЕТСЯ ПРОИЗВОДНЫМ ОТ ИСХОДНОГО _
АТРИБУТА (имя-атрибута-1) [И АТРИБУТА < имя-атрибута-2) ]...].. . Q0’
[КОМПОНЕНТ < квалифицированное-имя [,квалифицированное-имя-1 ]. . .)
ЕСТЬ СИНОНИМ КОМПОНЕНТА < квалифицированное-имя-2 [,квали-
фицированное-имя-3]...)]...
Данная подстатья определяет явно специфицируемые семан¬
тические свойства объекта, являющиеся прототипами соответст¬
вующих даталогических ограничений целостности. Наряду с та¬
кого рода ограничениями в модели поддерживаются так называе¬
мые неявно задаваемые подразумеваемые семантические свойства.
Эти свойства — следствие спецификаций некоторых других
свойств. Характерной особенностью последних является двойст-
133
венпость прагматики использования ассоциированных с ними по¬
нятий: в модели они рассматриваются исключительно как носи¬
тели информации об ограничениях целостности, в то время как
пользователь может выдвигать на первый план функциональные
аспекты, связанные с удовлетворением информационных потреб¬
ностей. Подразумеваемые свойства обычно ассоциируются с меж¬
классными отношениями, специфицируемыми в подстатье опреде¬
ления атрибута (отношение «атрибут — класс объектов, на котором
определен атрибут»), в подстатье категории объекта (отношение
объекта-«связи» с объектами-«сущностями»), а также в статьях
отношений между классами и композиции фрагментов. К подра¬
зумеваемым свойствам в определенной мере можно отнести так¬
же свойства, формально выражаемые подструктурами функцио¬
нальных и многозначных зависимостей, которые задаются при
описании идентификатора объекта (пользователя прежде всего
интересует функция выделения объекта среди других объектов,
которую выполняет идентификатор).
Поскольку ограничения целостности определяют не только
статические, но и динамические свойства объектов и атрибутов,
охарактеризуем некоторые ассоциируемые с манипулированием
данными понятия, которые используются в модели.
1. В общем случае имеется два «логических» пути доступа
к объекту:
доступ вне контекста;
доступ в контексте другого объекта, атрибутОлМ которого явля¬
ется первый объект.
2. Существуют следующие виды операций исключения объекта:
операция полного исключения;
операция исключения внеконтекстной доступности; после вы¬
полнения этой операции объект остается доступным только в
контексте других объектов;
операция исключения объекта из контекста некоторого друго¬
го объекта; эта операция выглядит как замена определенного
значения соответствующего атрибута на неопределенное. Отдель¬
ный вариант этой операции обеспечивает такую замену некото¬
рого значения атрибута на неопределенное во всех экземплярах
объектов данного класса. Эта операция, которую мы будем назы¬
вать операцией полного исключения из контекста, вводится как
прототип свойств возможных аналогов объектов в иерархичес-
ских и сетевых БД — сегментов, записей, где удаление сегмента
или записи — это всегда его удаление из всех цепочек, которыми
он связан с другими сегментами или записями.
3. Созданием объекта считается появление нового экземпля¬
ра (в случае объекта, имеющего идентификатор, появление эк¬
земпляра с несуществовавшим ранее значением идентификатора),
которое имеет место либо вследствие операции включения, либо
вследствие модификации идентификатора.
4. Манипулирование значениями «определено», «не определе¬
но» (ОПР, НЕОПР):
134
ситуация принятия атрибутом определенного значения имеет
место либо при создании объекта с соответствующим определен¬
ным значением, либо при замене неопределенного значения атри¬
бута в существующем объекте на определенное;
ситуацией принятия атрибутом неопределенного значения счи¬
тается либо удаление объекта, в котором этот атрибут имел оп¬
ределенное значение, либо замена определенного значения атри¬
бута на неопределенное, либо удаление (полное удаление, полное
контекстное удаление) соответствующего данному значению эк¬
земпляра объекта, на котором определен атрибут;
если атрибут объявлен «всегда определенным», то результа¬
том операции замены значения этого атрибута на неопределен¬
ное является удаление объекта, включающего этот атрибут.
5. Существует операция модификации группы атрибутов объ¬
екта.
6. Используется понятие текущих экземпляров объектов. Су¬
ществуют операции параллельной модификации групп атрибутов
в текущих экземплярах объектов.
Охарактеризуем специфицируемые в данной подстатье явно
выраженные семантические свойства.
Фраза 1 с продолжением 2 служит для спецификации струк¬
тур функциональных и многозначных зависимостей (ФЗ и М3),
отличных от тех, которые задаются спецификацией идентификато¬
ра объекта. Фраза 1 может употребляться без продолжения. В
этом случае она указывает на то, что произвольная комбинато¬
рика взаимосвязанных значений атрибутов недопустима, причем
основная функция фразы состоит в определении кластера правой
части М3. Из указания на то, что атрибут принимает множест¬
во значений (см. подстатью определения атрибута), в общем слу¬
чае не следует, что он составляет кластер.
Фраза 1 с продолжением 3 задает прототип даталогического
ограничения целостности, соответствующего обязательному член¬
ству (КОДАСИЛ). Фраза 1 с продолжением 4 задает прототип
даталогического ограничения целостности, соответствующего ав¬
томатическому членству (КОДАСИЛ), а продолжение 5 исполь¬
зуется как элемент прототипа свойств логических связей в модели
данных СУБД ОКА (соответствие композиций этих элементов
и их даталогических аналогов будет далее проиллюстрировано
нами на примерах).
Предложение 6 задает прототип соответствующего даталогиче¬
ского ограничения (см., например, обязательную определенность
значения ключа).
Предложение 7 задает прототип ограничения, соответствую¬
щего фиксированному членству (КОДАСИЛ), и означает, что
одно определенное значение атрибута не может быть заменено
на другое определенное.
Функции предложения 8 аналогичны функциям предложения 5.
Предложение 9 указывает на невозможность автономного иск¬
лючения значения атрибута из одного частного контекста (из од¬
135
ного экземпляра объекта, включающего этот атрибут). В этом
случае неопределенное значение присваивается атрибуту либо
в результате удаления объекта, на котором он определен (пол¬
ного удаления или полного исключения из контекста), либо кос¬
венно как следствие операции над другими атрибутами.
Производный атрибут, упоминаемый в предложении 10, дол¬
жен быть атомарным.
Понятие КОМПОНЕНТ (предложение 11) обобщает понятие
атрибута (группы атрибутов) и составляющей (группы состав¬
ляющих) атрибута, который может иметь сложную внутреннюю
структуру, т. е. атрибут атрибута, и т. д. Соответственно этому
«квалифицированное имя» — это либо имя атрибута специфици¬
руемого объекта, либо имя составляющей атрибута, уточненное
именами «охватывающих» конструкций вплоть до имени самого
атрибута.
Что касается синонимии, то в данном случае ее признаком яв¬
ляется идентичность значений компонентов в каждом экземпля¬
ре объекта. Далее будет рассмотрено более общее и более сложное
определенное понятие синонимии.
Подстатья категории объекта
Формат подстатьи:
ОБЪЕКТ ЕСТЬ
СУЩНОСТЬ
СВЯЗЬ ОБЪЕКТОВ, ВЫСТУПАЮЩИХ В РОЛЯХ <имя-ат-
рибута [,имя-атрибута-1] .. .>
ХАРАКТЕРИСТИКА
Класс объектов-сущностей полностью независим от других
классов по включению и удалению экземпляров объектов. Объек¬
ты этого класса доступны вне контекста связей с другими объ¬
ектами.
Если объект объявлен связью других объектов, обязательным
условием его существования является существование всех свя¬
зываемых объектов.
Если объект объявлен характеристикой, то любой доступ к
объекту возможен только в контексте других объектов, компонен¬
том которых он является. Если экземпляр объекта не выступает
как значение атрибута других объектов, объект не может сущест¬
вовать (исключается). С другой стороны, исключение экземпля¬
ра объекта всегда есть исключение из контекста (замена соответ¬
ствующего значения атрибута на неопределенное). Включение
нового экземпляра объекта-характеристики есть результат появле¬
ния нового значения соответствующего атрибута.
Свойства, присущие объектам-характеристикам, имеют оче¬
видную семантическую интерпретацию; вместе с тем возможные
даталогические аналоги объектов — группы данных, как прави¬
ло, обладают схожими свойствами: их включение-исключение из
БД не может производиться вне контекста их связей с другими
группами данных.
Подстатья не является обязательной.
136
Подстатья квантитативных характеристик
Формат подстатьи:
КОЛИЧЕСТВО ОБЪЕКТОВ В КЛАССЕ: СРЕДНЕЕ = <целое-без-знака>
[.МАКСИМАЛЬНОЕ = <целое-без-знака>]
Подстатья специфицирует объемные характеристики, исполь¬
зуемые при физическом проектировании.
Статья отношений между классами
Формат статьи приведен на с. 138.
Предложение 1 специфицирует отношение синонимии. Счита¬
ется, что суждение о синонимии выносится с учетом контекста
описания предметной области в целом. Синонимия предполагает
обязательное совпадение структуры (синтаксиса) и семантики си¬
нонимов. Синонимия означает следующее:
множества значений синонимов в любом состоянии базы дан¬
ных совпадают;
синонимы или по крайней мере их атрибуты должны быть оп¬
ределены на одних и тех же классах объектов или на пересекаю¬
щихся подклассах;
все представляющие интерес отношения синонимов с други¬
ми элементами предметной области, отображаемыми в ее моде¬
ли, в первую очередь отображаемые в модели отношения, долж¬
ны быть идентичными; последнее, в частности, означает отсутст¬
вие отношений между синонимами (за исключением, естествен¬
но, отношения синонимии).
Синонимия компонентов не является достаточным основанием
для соединения объектов по этим компонентам — в силу возмож¬
ных ловушек соединения. В случае невозможности синтаксиче¬
ского соединения поддержание такого свойства синонимов, как
совпадение множеств их значений, возлагается на приложение.
Это, в частности, определяет необходимость включения в модель
понятия текущих экземпляров классов объектов и операции вклю-
чения-удаления-модификации, выполняемой синхронно над объек¬
тами различных классов.
Неполная синонимия означает, что при сохранении всех прочих
условий синонимии множество значений А, объявленное непол¬
ным синонимом В, является подмножеством множества значе¬
ний В; идентичности «семантических» отношений А и В с други¬
ми классами не предполагается. Любое добавляемое значение А
должно (на момент добавления) уже принадлежать множеству
значений В. При модификации некоторого значения (экземпля¬
ра) А это значение может заменяться только на одно из значе¬
ний В. Исключение некоторого значения А не влечет за собой
исключения соответствующего значения В.
Спецификация идентичности ролей при сохранении прочих
условий синонимии не накладывает никаких ограничений на соот¬
ношение множеств значений; идентичность «семантических» отно¬
шений не предполагается.
137
| ГIКЛАСС ОБЪЕКТОВ <имя-класса-1 >
| [1 КОМПОНЕНТ < квалифицированное-имя [,квалифицированное-имя-1 ]. . .)
! (ОБЪЕКТА КЛАССА (имя-класса)
ЕСТЬ [НЕПОЛНЫЙ] СИНОНИМ
1СОДЕРЖИТ ЭКЗЕМПЛЯРЫ, ВЫСТУПАЮЩИЕ В ТОЙ ЖЕ РОЛИ, ЧТО И ЭКЗЕМ-^
ПЛЯРЫ {КЛАССА ОБЪЕКТОВ (имя-класса) 1
[КОМПОНЕНТА ( квалифицированное-имя-2 [,квалифицирован-S
ное-имя-3]. . .) J J (Т
[ОБЪЕКТЫ КЛАССА (имя-класса) ЕСТЬ РАЗНОВИДНОСТЬ ОБЪЕКТОВ
' КЛАССА (имя-класса-1) [, ГДЕ АТРИБУТЫ < имя-атрибута-1 [,имя-
I атрибута-2]. . .) СООТВЕТСТВУЮТ АТРИБУТАМ <имя-атрибута-3 [,имя-
i атрибута-4]. . .) ] (2)
! [ВИД ВЫДЕЛЯЕТСЯ СОГЛАСНО УСЛОВИЮ (выражение-селекции) ] ].®
[КЛАСС < имя-класса) ПЕРЕСЕКАЕТСЯ С < имя-класса-1)
[,МОЩНОСТЬ ПЕРЕСЕЧЕНИЯ (целое число процентов)] ]. . .
[РОДОВОЙ КЛАСС (имя-класса) ИСЧЕРПЫВАЕТСЯ ВИДОВЫМИ КЛАССАМИ
(имя-класса-1 [,имя-класса-2]...)]... (Т
ШпОЛНоГиСКЛЮЧЕНИЕ II ОБЪЕКТОВ КЛАССА < имя-класса) ТОЛЬКО В КОНТЕКСТЕ
!! ОБЪЕКТОВ КЛАССА <имя-класса-1 [,имя-класса-2]...)].. .
|-атрибута-1].. . >|
ОБЪЕКТА КЛАССА (имя-класса) МОЖЕТ ЗАМЕНЯТЬСЯ ТОЛЬКО НА ЗНА-
исиИг {АТРИБУТА (имя-атрибута-2) I исиптпрлгл
[ЧАСТИ (имя-атрибута-2 [,имя-атрибута-3]. . .)]
ОБЪЕКТА КЛАССА < имя-класса-1 > ]. . . @
[ОБЪЕКТ КЛАССА (имя-класса) АВТОМАТИЧЕСКИ УДАЛЯЕТСЯ
ПРИ УТРАТЕ СВЯЗИ С КАКИМ-ЛИБО ОБЪЕКТОМ КЛАССА
(имя-класса-1) В КОНТЕКСТЕ ОБЪЕКТОВ КЛАССОВ <имя-класса-2
[,имя-класса-3]...)]... (7)
[ЗНАЧЕНИЕ АТРИБУТА < имя-атрибута) ОБЪЕКТА КЛАССА (имя-класса)
МОЖЕТ ЗАМЕНЯТЬСЯ НА НЕОПРЕДЕЛЕННОЕ ТОЛЬКО, ЕСЛИ КЛАСС ОБЪЕКТОВ
(имя-класса-1) НЕ СОДЕРЖИТ ЭКЗЕМПЛЯРА, ТОЖДЕСТВЕННОГО ЗАМЕНЯ¬
ЕМОМУ ЗНАЧЕНИЮ]. . . (8)
[ПРИ ЗАМЕНЕ НЕОПРЕДЕЛЕННОГО ЗНАЧЕНИЯ АТРИБУТА < имя-атрибута)
ОБЪЕКТА КЛАССА (имя-класса) НА ОПРЕДЕЛЕННОЕ, КОПИЯ ОБЪЕКТА
ВКЛЮЧАЕТСЯ В КЛАСС ОБЪЕКТОВ (имя-класса-1), ГДЕ <имя-атри-
бута-1 [,имя-атрибута-2].. .) СООТВЕТСТВУЕТ (имя-атрибута-3
[,имя-атрибута-4]...)].. . (9)
[АТРИБУТ (имя-атрибута) ОБЪЕКТА КЛАССА (имя-класса)
ЯВЛЯЕТСЯ ПРОИЗВОДНЫМ ОТ ИСХОДНОГО АТРИБУТА (имя-атрибута-1)
ОБЪЕКТА КЛАССА (имя-класса-1) [И АТРИБУТА <имя-атрибута-3) ОБЪЕКТА
КЛАССА < имя-класса-2) ]. . .
[ПРИ МОДИФИКАЦИИ ИСХОДНЫХ ОБЪЕКТ, СОДЕРЖАЩИЙ СООТВЕТСТВУЮЩИЙ
ПРОИЗВОДНЫЙ, ОТЫСКИВАЕТСЯ ПО УСЛОВИЮ (критерии-селекции) ] ]. . . ®
[АТРИБУТЫ (имя-атрибута [,имя-атрибута-1 ]. . .) ОБЪЕКТА КЛАССА (имя-
класса) [И АТРИБУТЫ (имя-атрибута-2 [,имя-атрибута-3]. . .)
ОБЪЕКТА КЛАССА <имя-класса-1 > [Ж?ЗНАЧНО^ | 0ПРЕдЕЛяюТ АТРИБУТЫ
138
Соответствие между атрибутами синонимов (неполных сино¬
нимов, выступающих в идентичных ролях) определяется поряд¬
ком их перечисления в предложении 1.
Фраза 2 специфицирует родовидовые отношения.
Родовое (общевидовое) представление объекта может вовсе
не иметь атрибутов, однако, если это не так, атрибуты, аналогич¬
ные атрибутам родового объекта, в общем случае должны быть
специфицированы и в видовом представлении (соответствие имен
атрибутов задается фразой «ГДЕ...»). Включение объекта в ви¬
довой класс приводит также к включению в родовой.
Непосредственное включение в родовой класс невозможно, ес¬
ли этот класс упоминается в предложении 4, и, следовательно,
все родовые объекты принадлежат к одной из упоминаемых в
этой же фразе разновидностей.
Исключение объекта из видового класса влечет за собой иск¬
лючение из родового класса, если последний упоминается в пред¬
ложении 4 и видовой класс не пересекается с другими видовыми
классами. В случае, когда первое условие выполняется, а вто¬
рое— нет, удаление объекта из родового класса происходит вслед¬
ствие его удаления из всех видов. Если не выполняется лишь пер¬
вое условие, удаление объекта из родового класса возможно толь¬
ко в результате применения операции исключения непосредствен¬
но к этому классу. При этом объект исключается и из всех ви¬
довых классов, из которых он к этому моменту не был еще иск¬
лючен.
В частном случае видовой класс объектов может выделяться
из родового в соответствии с условием фразы 3, которое пред¬
ставляет собой булево выражение, построенное на традиционных
двуместных предикатах, причем предикатные переменные опре¬
деляются на компонентах объекта родового класса, а также на
классах, «встроенных» в модель (литералы и т. п.). В этом част¬
ном случае объекты видового класса могут не иметь некоторых
атрибутов родового (если в соответствии с условием 3 эти атри¬
буты принимают постоянное значение или значение, которое вы¬
водится по значениям других атрибутов).
Предложение 5, которое применимо к классам объектов, не
относящимся к категории характеристик, указывает, что включе¬
ние (исключение) экземпляра объекта возможно только в кон¬
тексте другого объекта, по отношению к которому первый объект
выступает как область определения атрибута. В случае, когда в
предложении упоминается операция включения, новый экземп¬
ляр одного объекта появляется в результате включения нового
экземпляра этого другого объекта или модификации его атрибу¬
та; непосредственное включение экземпляра первого объекта не
допускается.
В случае, когда предложение 5 накладывает ограничения на
исключение, употребление операции полного исключения не до¬
пускается: в то же время операция полного исключения из кон¬
текста приводит к полному исключению. Заметим, что в случае,
139
когда включение (исключение) объекта контролируется несколь¬
кими другими объектами, должны использоваться текущие опе¬
рации и операции синхронного включения, о необходимости введе¬
ния которых в модель уже говорилось выше.
Мотивировка введения предложения 5 близка к мотивировке
введения в модель категории объектов-характеристик.
Предложения 6, 7, 8, 9 задают элементы прототипов свойств
логических связей в моделях данных СУБД ОКА.
Семантика предложения 10 и ограничения на свойства произ¬
водного атрибута аналогичны охарактеризованным в описании
предложения 10 подртатьи внутренних семантических свойств
объекта. Выражение селекции, упоминаемое в данном предложе¬
нии, строится по правилам, аналогичным правилам построения
соответствующего выражения во фразе 3.
Предложение 11 служит спецификации межобъектных функ¬
циональных и многозначных зависимостей. Эти спецификации бу¬
дут использованы при проектировании БД только, если возможно
синтаксическое соединение объектов.
Статья спецификации запроса
Статья включает следующие подстатьи: подстатью идентифи¬
кации запроса, подстатью селекции, подстатью действия и под¬
статью квантитативных характеристик.
Подстатья идентификации запроса
Формат подстатьи:
ЗАПРОС <идентификатор-запроса>
ХАРАКТЕРИСТИКА <произвольный-текст>
Подстатья селекции
Формат под статьи:
(ПОСЛЕДОВАТЕЛЬНОСТЬ СЕЛЕКЦИИ} ГДЕ (выражение-
(НАЙТИ (ВСЕ] ОБЪЕКТЫ КЛАССА < имя-клзсса) [[ пОИСк” ПРИЗНАКИ
(квалифицированное-имя [,квалифицированное-имя-1 ]. . .),
СРЕДНЕЕ ЧИСЛО ОБЪЕКТОВ, УДОВЛЕТВОРЯЮЩИХ ЗАПРОСУ=<целое-без-Я
знака) ИСКОМЫЕ ДАННЫЕ < квалифицированное-имя-2 [,квалифи- Н
цированное-имя-3]. . .)
[КОМПОНЕНТЫ < квалифицированное-имя-4 [,квалифицированмое-имя-
5]. . •> СООТВЕТСТВУЮТ КОМПОНЕНТАМ (квалифицированное-имя-б
[,квалифицированное-имя-7]. ..) ОБЪЕКТА КЛАССА <имя-класса-1> ]} . .
[КОНЕЦ ПОСЛЕДОВАТЕЛЬНОСТИ} . ..
Если слово ВСЕ опущено, результатом селекции является лю¬
бой экземпляр объекта, удовлетворяющий критерию селекции.
Подстатья специфицирует тип запроса, поэтому значения пра¬
вых частей двухместных предикатов, на которых строится выра¬
жение селекции, неопределенны.
140
Фраза «НАЙТИ...» в рамках спецификации запроса может
употребляться однократно или повторяться, определяя некото¬
рую последовательность селекции. В этом случае может исполь¬
зоваться необязательная фраза «...СООТВЕТСТВУЕТ...», зада¬
ющая соответствие поисковых признаков очередного шага поис¬
ка результатам выполнения предыдущего шага.
Подстатья действия
Формат подстатьи:
( ЧИТАТЬ
ЗАМЕНИТЬ
ПОЛНОСТЬЮ ИСКЛЮЧИТЬ ОБЪЕКТ
ИСКЛЮЧИТЬ НЕПОСРЕДСТВЕННЫЙ ДОСТУП К ОБЪЕКТУ
ПОЛНОСТЬЮ ИСКЛЮЧИТЬ ИЗ КОНТЕКСТА ОБЪЕКТ
[.СООТВЕТСТВУЮЩИЙ
АТРИБУТУ <имя-атрибута>] 1
ВКЛЮЧИТЬ ОБЪЕКТ <имя-объекта> j . . .
Семантика разновидностей операции исключения объекта бы¬
ла охарактеризована выше (см. подстатью внутренних семанти¬
ческих свойств объекта).
Необязательное продолжение предложения 1 используется в
случае, когда исключаемый объект определяется контекстом дру¬
гого объекта, упоминаемого в подстатье селекции.
Экземпляр подстатьи действия следует за экземпляром под¬
статьи селекции, к результатам которой применяется действие.
В случае, когда экземпляр подстатьи селекции используется для
установки текущего, экземпляр подстатьи действия может быть
опущен. Напротив, в случае операции включения объекта может
быть опущен предшествующий экземпляр подстатьи селекции.
Подстатья квантитативных характеристик
Формат подстатьи:
( ОПЕРАТИВНЫЙ Ьдпрпс
I НЕОПЕРАТИВНЫЙ
ИНТЕНСИВНОСТЬ РЕАЛИЗАЦИИ; СРЕДНЯЯ: ЧИСЛО ЗАПРОСОВ <це;
лое-без-знака> ИНТЕРВАЛ <величина-времснп6го-интсрвала>
[.МАКСИМАЛЬНАЯ: ЧИСЛО ЗАПРОСОВ <целое-без-знака> ИНТЕРВАЛ <ве-
личина-временного-интервала>]
Статья-заголовок композиции фрагментов
Формат статьи:
ОТНОШЕНИЕ КОМПОЗИЦИИ ФРАГМЕНТОВ МОДЕЛИ
ХАРАКТЕРИСТИКА КОМПОЗИЦИИ <произвольный-текст>
141
Следом за этой статьей следуют статьи, специфицирующие
классы объектов, отношения между классами, а также статьи
спецификации запросов. Синтаксис этих статей соответствует вы¬
шеприведенному, за исключением того, что имена объектов уточ¬
няются именами фрагментов. Следует, однако, отметить специфи¬
ку использования упомянутых категорий при решении проблемы
интеграции фрагментов. Так, например, спецификация класса
объектов может преследовать цели получения интегрального пред¬
ставления объекта на основе представлений отдельных его час¬
тей, специфицированных в конкретных фрагментах. Такое решение
должно приниматься в условиях четкого понимания того факта,
что интеграция подобного рода требует в общем случае привле¬
чения к актуализации модели предметной области дополнитель¬
ного источника информации о связи частей объекта, наличие кото¬
рого не предполагалось при моделировании подобластей. В то
же время соединение объектов будет автоматически осуществ¬
ляться при обработке инфологического описания даже в отсутст¬
вии явной спецификации соответствующих композиционных отно¬
шений, но при наличии сведений, свидетельствующих о допусти¬
мости синтаксического соединения.
Проиллюстрируем некоторые основные возможности модели на
примерах описания фрагментов предметных областей (подоб¬
ластей), сопоставляя им возможные варианты целевых схем, со¬
ответствующих известным моделям данных, поддерживаемым
СУБД ОКА и СЕТЬ. В частности, показано наличие инфологиче-
ских прототипов, эквивалентных по своим свойствам даталогиче-
ским ограничениям целостности.
При рассмотрении примеров необходимо учитывать следую¬
щие обстоятельства:
спецификации, приводимые в примерах, фрагментарны; не
представляющие непосредственного интереса детали опущены;
ряд элементов спецификаций дается в сокращенной записи
в соответствии с табл. 1;
Таблица ]
Статья, подстатья,
предложение, фраза
Сокращенная запись
Примечание
Статья класса объектов
Подстатья внутренних
семантических свойств
Фраза 1, продолжение 2
А^В
Функциональная зависи¬
мость
А->->В
Многозначная зависимость;
А и В — имена атрибутов
142
Продолжение
Статья, подстатья,
предложение, фраза
Сокращенная запись
Примечание
Фраза 1, продолжение 3
а=>НЕОПР ВЛЕЧЕТ
(Ь, с,. ..)=>НЕОПР
Строчными латинскими
буквами здесь и далее
обозначены значения ат¬
рибутной переменной;
переменная принимает
значения, соответствую¬
щие значениям атрибу¬
тов,- именованных соот¬
ветствующими заглавпьь
ми буквами
Фраза 1, продолжение 4
а=>ОПР ТОЛЬКО
ПРИ (Ь, с, ...)^ОПР
Фраза 1, продолжение 5
(а, Ь,.. .)=>
11ОПР II только
ЦНЕОПР II
СИНХРОННО
Предложение 6
(а, Ь)=ОПР
Значения а, Ь, ... соотно¬
сятся с одним и тем же
экземпляром объекта
Предложение 7
ЗАПРЕТ
НЕПОСР МОДИФ
(а, Ь, ...)
Предложение 8
ЗАПРЕТ НЕПОСР
(а, Ь, . ,.)=>ОПР
Предложение 9
ЗАПРЕТ НЕПОСР
(а, Ь, ...)=>НЕОПР
Статья отношений меж¬
ду классами, статья
композиции фрагмен¬
тов
Предложение 6
При (ab ...) =>ОПР
ОПР^ЗНое
ab... — переменная, прини¬
мающая значение на мно¬
жестве кортежей проекции
объекта, атрибуты которого
именованы соответствующи¬
ми заглавными буквами
ЗНбе — множество корте¬
жей проекции объекта с
атрибутами D, Е ...
Предложение 7
оА=> не СУЩ
ПРИ УТРАТЕ СВЯЗИ
С КАКИМИ-ЛИБО ов
В КОНТЕКСТЕ Ос и Od
од, ов — экземпляры объек¬
тов классов А, В
Ос, Od — классы объектов
С и D
Предложение 8
а=^НЕОПР ТОЛЬКО
ПРИ ов(Ь = а)^Ов
b — «объектная» перемен¬
ная, принимающая значение
на множестве кортежей-
объектов
Предложение 9
При а=>ОПР
ов (а) ВКЛЮЧ. в Ос
ов(а)—экземпляр объекта
класса Ов, которому соот¬
ветствует модиф ицируе-
мое а
143
сделаны дополнительные упрощения спецификаций, не огово¬
ренные в табл. 1, поскольку существо таких упрощений очевид¬
но; читателю, уже ознакомившемуся с развернутой формой спе¬
цификаций, эти упрощения не должны служить ггрепятствием к
пониманию примеров;
имена классов объектов и атрибутов абсолютно уникальны.
Пример 1
МОДЕЛЬ ПРЕДМЕТНОЙ
ОБЛАСТИ Ml
КЛАСС ОБЪЕКТОВ О
АТРИБУТ* А
ОДНОЗНАЧНЫЙ
Атрибут в
однозначный’
АТРИБУТ* Е*
ОДНОЗНАЧНЫЙ*
АТРИБУТ *F*
ОДНОЗНАЧНЫЙ*
А—ИДЕНТИФИКАТОР
(Е, F) ВЗАИМОСВЯЗАНЫ, E-^F
*Е = ОПР
*В=^ОПР ТОЛЬКО ПРИ А=>ОПР
СХЕМА БД (модель КОДАСИЛ)
Е
F
МА
А
В
МА — обязательное автоматическое
членство
Данный пример демонстрирует возможный вариант задания
прототипа автоматического обязательного варианта членства в
целевой схеме БД, соответствующей модели данных КОДАСИЛ.
(Фрагменты таких схем здесь и далее даются в традиционной ма¬
нере графического изображения: записи изображаются прямо¬
угольниками, наборы — прямыми линиями, связывающими пря¬
моугольники; ключевые поля выделяются подчеркиванием.) Од¬
нако, как это демонстрируют примеры 2, 3, этот вариант не яв¬
ляется единственным; в противном случае инфологическая мо¬
дель не обладала бы гибкостью, согласующейся с естественными
для реального мира возможностями выражать множеством спо¬
собов одни и те же понятия.
Пример 2
МОДЕЛЬ ПРЕДМЕТНОЙ
ОБЛАСТИ Ml
ФРАГМЕНТ МОДЕЛИ* Ф*1
СХЕМА БД
(модель КОДАСИЛ)
144
П родолжение
КЛАСС ОБЪЕКТОВ 01
АТРИБУТ А
АТРИБУТ'В ’
АТРИБУТ Е1
А — ИДЕНТИФИКАТОР ’
(А, Е1)=0ПР
ФРАГМЕНТ МОДЕЛИ Ф2
КЛАСС ОБЪЕКТОВ 02
АТРИБУТ ’Е
ОДНОЗНАЧНЫЙ
АТРИБУТ F
Е —ИДЕНТИФИКАТОР ’
Е = ОПР
El’ECTb НЕПОЛНЫЙ
СИНОНИМ Е
Пример 3
МОДЕЛЬ ПРЕДМЕТНОЙ
ОБЛАСТИ Ml
ФРАГМЕНТ МОДЕЛИ Ф1
КЛАСС’объектов’о’
АТРИБУТ А
АТРИБУТ’в’
АТРИБУТ Е ’
АТРИБУТ F ’
А — ИДЕНТИФИКАТОР ’
(E‘f‘) ВЗАИМОСВЯЗАНЫ, E+F
Е = ОПР
В ОПР 'только ПРИ А => ОПР
ФРАГМЕНТ МОДЕЛИ’ Ф*2
КЛАСС ОБЪЕКТОВ 03
атрибута!
атрибут В1
Е
Г
МА
А
В |
1
СХЕМА БД
(модель КОДАСИЛ)
Е
F
А
В
Ю Заказ 5620
145
П родолжение
Al — ИДЕНТИФИКАТОР
Ai’^orip’
(Al Bl) ЕСТЬ СИНОНИМ (AB)
ВКЛЮЧЕНИЕ И
ИСКЛЮЧЕНИЕ ОЗ
ТОЛЬКО В КОНТЕКСТЕ 01
Приведем еще один пример
ветствующсго сетевой схеме БД:
Пример 4
МОДЕЛЬ ПРЕДМЕТНОЙ
ОБЛАСТИ М2
ФРАГМЕНТ МОДЕЛИ ф’1
КЛАСС ОБЪЕКТОВ 01
АТРИБУТ А
АТРИБУТ В
АТРИБУТ Е
АТРИБУТ F
А — ИДЕНТИФИКАТОР
(E,'f) ВЗАИМОСВЯЗАНЫ, E-*F
Е = ОПР
В => ОПР только ПРИ А => ОПР
ФРАГМЕНТ МОДЕЛИ Ф2
КЛАСС ОБЪЕКТОВ 02
АТРИБУТ К
АТРИБУТ L
АТРИБУТ Р
АТРИБУТ Q
К — ИДЕНТИФИКАТОР
(Р,’ Q) ВЗАИМОСВЯЗАНЫ,' P^Q
Р = ОПР
Ь=>ОПР ТОЛЬКО ПРИ к=>ОПР
инфологического описания, соот-
СХЕМА БД
(модель КОДАСИЛ)
(АВ) ЕСТЬ СИНОНИМ (KL)
Следующий пример иллюстрирует влияние спецификации си¬
нонимии на целевую схему БД:
146
Пример 5
модель ПРЕДМЕТНОЙ
ОБЛАСТИ М3
ФРАГМЕНТ МОДЕЛИ Ф1
КЛАСС ОБЪЕКТОВ 01
АТРИБУТ А
АТРИБУТ В
А — ИДЕНТИФИКАТОР
А = ОПР
КЛАСС ОБЪЕКТОВ 02
АТРИБУТ С
АТРИБУТ D
С — ИДЕНТИФИКАТОР
С = ОПР
СХЕМА БД
(модель КОДАСИЛ)
а) фраза в скобках опущена
А В
С D
б) фраза в скобках не опущена
КЛАСС ОБЪЕКТОВ 03
АТРИБУТ Е
ОПРЕДЕЛЕН НА 01
АТРИБУТ F
ОПРЕДЕЛЕН НА 02
F — ИДЕНТИФИКАТОР
ФРАГМЕНТ МОДЕЛИ Ф2
КЛАСС ОБЪЕКТОВ 04
КЛАСС ОБЪЕКТОВ 05
КЛАСС ’ ОБЪЕКТОВ ‘ 06
АТРИБУТ Р*
ОПРЕДЕЛЕН НА 04
АТРИБУТ Q
ОПРЕДЕЛЕН НА 05
Q — ИДЕНТИФИКАТОР
01 ЕСТЬ СИНОНИМ 04
02 ЕСТЬ СИНОНИМ 05
(03 ЕСТЬ СИНОНИМ 06)
10’
147
Пример 6
МОДЕЛЬ ПРЕДМЕТНОЙ
ОБЛАСТИ М4
ФРАГМЕНТ МОДЕЛИ Ml
КЛАСС ОБЪЕКТОВ 01
АТРИБУТ А
АТРИБУТ В
А — ИДЕНТИФИКАТОР
А = ОПР
КЛАСС ’ ОБЪЕКТОВ* 03
АТРИБУТ Е
АТРИБУТ F ’
Е — ИДЕНТИФИКАТОР
Е = ОПР
КЛАСС* объектов’ 01'
КЛАСС ’ ОБЪЕКТОВ 01"
КЛАСС’ОБЪЕКТОВ’ 03'
КЛАСС ’ ОБЪЕ КТОВ ’ 03"
КЛАСС ОБЪЕКТОВ 04 *
АТРИБУТ К
ОПРЕДЕЛЕН НА 01'
атрибут!
АТРЙБУт’м’
ОПРЕДЕЛЕН НА 03
КМ — ИДЕНТИФИКАТОР
(К, L) ВЗАИМОСВЯЗАНЫ
Ь=^ОПР ТОЛЬКО ПРИ К=ОПР
К=>НЕОПР ВЛЕЧЕТ Ь=>НЕОПР
СХЕМА БД
(модель ОКА)
Правила актуализации
для ЛИ: включение — Р
удаление — V
для ЛП: включение — Р
удаление — V
(L, М) ВЗАИМОСВЯЗАНЫ
(L, М)=>0ПР НЕОПР ТОЛЬКО СИНХРОННО
Ь=>НЕОПР ВЛЕЧЕТ М=>НЕОПР
ЗАПРЕТ НЕПОСР К =>НЕОПР
КЛАСС'ОБЪЕКТОВ’ 05
АТРИБУТ Р
148
Продолжение
ОПРЕДЕЛЕН НА 01"
АТРИБУТ Q
АТРИБУТ S
ОПРЕДЕЛЕН НА 03"
PS — ИДЕНТИФИКАТОР
(Р,‘ Q) ВЗАИМОСВЯЗАНЫ
(Р, Q) НЕОПР ТОЛЬКО СИНХРОННО
0=>НЕОПР ВЛЕЧЕТ Р=>НЕОПР
*(Q^ S) ВЗАИМОСВЯЗАНЫ ’
S=>HEOnP ВЛЕЧЕТ Q=>НЕОПР
ЗАПРЕТ НЕПОСР (Р, Q)=>0rip'
ЗАПРЕТ НЕПОСР S=>HEOhP
01' ЕСТЬ ПОДКЛАСС 61; ПЕРЕСЕКАЕТСЯ С 01"
01" ЕСТЬ ПОДКЛАСС 01
03' ЕСТЬ ПОДКЛАСС 03; ПЕРЕСЕКАЕТСЯ С 03"
03" ЕСТЬ ПОДКЛАСС 03
ПРИ т=>0ПР, ОПРеЗЩ
ПРИ т=>0ПР, оо4 ВКЛЮЧ В 05
оо3 НЕ СУЩ ПРИ УТРАТЕ СВЯЗИ С КАКИМ-ЛИБО оО1 В КОНТЕКСТЕ
04 и 05
Рассмотрим пример описания предметной области средствами
ИЛМ ОМЕГА. Описание строится на основе интеграции трех
фрагментов.
Первый фрагмент специфицирует три класса объектов: ЗА¬
ВОД, ПРОИЗВОДСТВО И ИЗДЕЛИЕ. Для приложения, свя¬
занного с этим фрагментом, в конечном итоге важен факт произ¬
водства определенных изделий заводами. Рассматриваются толь¬
ко изделия, которые имеют определенного производителя, причем
каждое изделие производится только одним заводом. Что каса¬
ется заводов, то для приложения важны не только те из них,
которые фактически производят изделия, но и те, которые рас¬
сматриваются как потенциальные производители.
Во втором фрагменте специфицированы классы объектов ЗА¬
ВОД, ДЕТАЛЬ, ПРОИЗВОДСТВО И ПОСТАВКА КОМПЛЕК¬
ТУЮЩИХ. Класс ЗАВОД тождествен одноименному классу пер¬
вого фрагмента. Класс ДЕТАЛЬ содержит часть из тех изделий,
которые рассматриваются в первом фрагменте, а также те изде¬
лия, которые выступают как комплектующие других изделий.
Объект ПРОИЗВОДСТВО и ПОСТАВКА КОМПЛЕКТУЮ-
Щих связывает заводы — потребители комплектующих (та часть
заводов — производителей фрагмента 1, которая потребляет комп¬
лектующие) с заводами-поставщиками и производимыми ими де¬
талями (часть заводов — производителей фрагмента 1, выпускаю¬
щих комплектующие, и те производимые ими детали, которые
Используются как комплектующие). Предполагается, что завод-
Поставщик связан только с одним определенным заводом-потре¬
бителем.
149
В третьем фрагменте представлены классы объектов ПРО¬
ЕКТ, КОМПОНЕНТ И ОБЕСПЕЧЕНИЕ. Класс КОМПОНЕНТ
содержит изделия из числа производимых заводами (см. фраг¬
мент 1), которые используются при реализации одного или не¬
скольких конкретных проектов. Объект класса ОБЕСПЕЧЕНИЕ
связывает компоненты с определенными использующими их про¬
ектами.
В описание включен также запрос, цель которого получить ин¬
формацию о всех поставщиках, ведущих поставки для конкрет¬
ного проекта.
МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ Производство-поставки
ВЕРСИЯ 01
ФРАГМЕНТ МОДЕЛИ Производство изделий
ИСТОЧНИК Отдел планирования и контроля производства основных
изделий
КЛАСС ОБЪЕКТОВ
Завод
КЛАСС ОБЪЕКТОВ
Изделие
КЛАСС ОБЪЕКТОВ
Производство
АТРИБУТ Производитель
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Завод
ОДНОЗНАЧНЫЙ
АТРИБУТ Изделие
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Изделие
МНОГОЗНАЧНЫЙ
■ОБЪЕКТ ИДЕНТИФИЦИРУЕТСЯ АТРИБУТАМИ Производитель
АТРИБУТЫ Изделие Производитель ВЗАИМОСВЯЗАНЫ,
Изделие ОДНОЗНАЧНО ОПРЕДЕЛЯЕТ Производитель
ВКЛЮЧЕНИЕ,’ ИСКЛЮЧЕНИЕ ОБЪЕКТОВ’ КЛАССА ’ 'Изделие ’ ТОЛЬКО
В КОНТЕКСТЕ ОБЪЕКТА КЛАССА Производство
ФРАГМЕНТ МОДЕЛИ Поставка комплектующих
ИСТОЧНИК Отдел планирования и контроля поставки деталей комплектующих
КЛАСС ОБЪЕКТОВ ’ ’ ’ 'Завод
КЛАСС'ОБЪЕКТОВ ’ ’ ’ ’ Деталь
КЛАСС ОБЪЕКТОВ Производство и поставка комплектующих
АТРИБУТ Потребитель
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Завод
ОДНОЗНАЧНЫЙ
АТРИБУТ
Поставщик
150
П родолжение
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Завод
МНОГОЗНАЧНЫЙ
АТРИБУТ Деталь
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Деталь
МНОГОЗНАЧНЫЙ
ОБЪЕКТ ИДЕНТИФИЦИРУЕТСЯ АТРИБУТАМИ ’ ’ ’ 'Потребитель
АТРИБУТЫ Деталь, Поставщик, ВЗАИМОСВЯЗАНЫ,
Деталь ОДНОЗНАЧНО ОПРЕДЕЛЯЕТ Поставщик
АТРИБУТЫ Поставщик, Потребитель ВЗАИМОСВЯЗАНЫ,
Поставщик ОДНОЗНАЧНО ОПРЕДЕЛЯЕТ Потребитель
ФРАГМЕНТ МОДЕЛИ Комплектация проектов
ИСТОЧНИК Отдел комплектации проектов
КЛАСС ОБЪЕКТОВ Проект
КЛАСС ОБЪЕКТОВ Компонент
КЛАСС ОБЪЕКТОВ Обеспечение
АТРИБУТ Проект
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Проект
ОДНОЗНАЧНЫЙ
АТРИБУТ Компонент
ОПРЕДЕЛЕН НА КЛАССЕ ОБЪЕКТОВ Компонент
МНОГОЗНАЧНЫЙ
ОБЪЕКТ ИДЕНТИФИЦИРУЕТСЯ АТРИБУТАМИ Проект
ВКЛЮЧЕНИЕ, ИСКЛЮЧЕНИЕ ОБЪЕКТОВ КЛАССА Компонент
ТОЛЬКО В КОНТЕКСТЕ ОБЪЕКТА КЛАССА Обеспечение
ОТНОШЕНИЕ КОМПОЗИЦИИ ФРАГМЕНТОВ МОДЕЛИ
КЛАСС ОБЪЕКТОВ 'Производство изделий' Завод ЕСТЬ СИНОНИМ КЛАССА
ОБЪЕКТОВ Поставка комплектующих. Завод
КОМПОНЕНТ Поставщик Деталь ОБЪЕКТА КЛАССА Поставка комплектую¬
щих. Производство и поставка комплектующих
ЕСТЬ НЕПОЛНЫЙ СИНОНИМ
КЛАССА ОБЪЕКТОВ Производство изделий. Производство
КОМПОНЕНТ Потребитель ОБЪЕКТА КЛАССА Поставка комплектующих.
Производство и поставка комплектующих ЕСТЬ НЕПОЛНЫЙ СИНОНИМ
КОМПОНЕНТА Производитель ОБЪЕКТА КЛАССА
Производство изделий. Производство
ОБЪЕКТЫ КЛАССА Поставка комплектующих. Деталь
ЕСТЬ РАЗНОВИДНОСТЬ ОБЪЕКТОВ КЛАССА Производство изделий. Изделие
ОБЪЕКТЫ КЛАССА Комплектация проектов. Компонент
ЕСТЬ РАЗНОВИДНОСТЬ ОБЪЕКТОВ КЛАССА Производство изделий. Изделие
КОМПОНЕНТ Компонент ОБЪЕКТА КЛАССА Комплектация проектов.
Обеспечение ЕСТЬ НЕПОЛНЫЙ СИНОНИМ КОМПОНЕНТА Изделие
ОБЪЕКТА КЛАССА Производство изделий. Производство
ЗАПРОС Определение поставщиков
Последовательность селекции
НАЙТИ ВСЕ ОБЪЕКТЫ КЛАССА Комплектация проектов. Обеспечение
151
Продолжение
ПОИСКОВЫЕ ПРИЗНАКИ Проект
ИСКОМЫЕ ДАННЫЕ Компонент
КОМПОНЕНТЫ Компонент
СООТВЕТСТВУЮТ КОМПОНЕНТАМ Изделие
ОБЪЕКТА КЛАССА Производство изделий. Производство
НАЙТИ ВСЕ ОБЪЕКТЫ КЛАССА Производство изделий. Производство
ПОИСКОВЫЕ ПРИЗНАКИ Изделие
ИСКОМЫЕ ДАННЫЕ Производитель
КОНЕЦ ПОСЛЕДОВАТЕЛЬНОСТИ
ЧИТАТЬ
Средства мифологического моделирования, охарактеризован¬
ные в настоящей статье, были использованы при проектировании
баз данных для АИС (АСУ), ориентированных на различные пред¬
метные области, в том числе для АСУ ГКНТ СССР, АСУ транс¬
порта газа и Единой системы планирования капитального строи¬
тельства.
Полученный опыт подтвердил корректность и эффективность
концепций, положенных в основу построения ИЛМ.
ЛИТЕРАТУРА
1. Вейнеров О. М., Савинков В. М., Жадан Н. В., Казаров М. С. Мифологиче¬
ская модель в системе автоматизированного проектирования баз данных; кон¬
цепции построения и реализация. Прикладная информатика.— М.: Финансы
и статистика, 1987. — Вып. 2(13). — С. 59—75.
УДК 519.688
М. И. МЕЛЬНИКОВ, Г. В. ПОНОМАРЕВ, В. А. ЗЕЛЕНИН, Э. П. ЩЕДРИН
УНИФИЦИРОВАННАЯ СИСТЕМА ПРИЕМА,
ОБРАБОТКИ И ВЫДАЧИ ИНФОРМАЦИИ (УСОИ)
Введение
Вряд ли можно представить себе современное производство
без движения разнообразной информации между различными
уровнями управления. Сбор, контроль, хранение, анализ и ото¬
бражение отчетной информации в совокупности представляют со¬
бой самостоятельный процесс, обеспечение которого требует зна¬
чительных трудовых и материальных ресурсов. Требования по¬
вышения производительности труда и интенсификации произвол'
ства затрагивают и эту область деятельности, тем более что оиа
непосредственно связана с вопросами совершенствования форм»
методов и стиля управления народным хозяйством.
152
Наиболее перспективным направлением применения возмож¬
ностей вычислительной техники в сфере управления является
создание автоматизированных систем приема, обработки, хране¬
ния и выдачи информации. Разработка и внедрение таких систем
является длительным и трудоемким процессом. Непрекращаю-
щийся рост доли затрат на математическое обеспечение по от¬
ношению к стоимости самой вычислительной техники делает не¬
целесообразной разработку узкоспециализированных комплексов.
Повышение эффективности разработки программно-математиче¬
ского обеспечения может быть достигнуто только за счет созда¬
ния и использования унифицированных систем, обладающих боль¬
шими функциональными возможностями. Тиражирование и рас¬
пространение таких систем резко повышает эффективность ис¬
пользования математического обеспечения, позволяя избежать
дублирования разработок, типизировать и унифицировать про¬
ектные решения и технологию обработки информации.
Интерпретирующие многофункциональные комплексы, ориен¬
тированные на пользователей-непрограммистов, являются наибо¬
лее перспективными направлениями развития прикладного про¬
граммного обеспечения. Представляя собой инструментальный ап¬
парат, они дают возможность настраиваться на решение конкрет¬
ных задач, минуя этапы написания и отладки программ. Естест¬
венно, что описание задач в этом случае должно производиться
на языке высокого уровня, доступном для технологического пер¬
сонала.
Область применения, характеристики и состав УСОИ
УСОИ представляет собой диалоговую систему управления
данными, предназначенную для использования в министерствах,
главках, производственных объединениях с целью автоматизации
сбора, контроля и обработки отчетной оперативной информации
о деятельности подчиненных предприятий и организаций и со¬
ставления итоговых аналитических отчетов. Опираясь на совре¬
менные технические и математические средства, УСОИ способна
удовлетворить потребности управленческого аппарата, включая
динамическое составление разнообразных справок и графическое
представление информации.
УСОИ прежде всего ориентирована на работу с информацией,
поступающей через строго регламентированные промежутки вре¬
мени (сутки, декаду, месяц и т. п.), и нормативно-справочными
данными. Понятие информации в данном случае включает в себя,
кроме числовых, еще и текстовые показатели, часто используемые
для объяснения причин каких-либо отклонений от плановых за¬
даний. УСОИ обеспечивает полный цикл обработки информации,
т. е. ее сбор, контроль на корректность и полноту, хранение, про¬
ведение необходимых расчетов, предоставление пользователям
справок и отчетных документов различной степени сложности.
Кроме того, УСОИ оснащена средствами слежения за соблюде¬
153
нием регламента поступления информации и накопления стати¬
стических данных о его нарушителях.
УСОИ обеспечивает автоматизацию процесса разработки ин¬
формационных задач на основании их формализованных описа¬
ний и единую технологию эксплуатации этих задач. Она реали¬
зована как замкнутая система с развитыми языковыми средст¬
вами, что обеспечивает выполнение всех стадий внедрения задач
от их проектирования до эксплуатации (а также развития и мо¬
дификации задач в процессе их эксплуатации) силами техноло¬
гического церсонала без участия программистов,. Выполнение
ряда функций по управлению УСОИ может быть переложено на
плечи среднего технического персонала.
УСОИ предполагает наличие двух групп пользователей: спе¬
циальной службы сопровождения задач и конечных пользовате¬
лей. В обязанности сотрудников группы сопровождения входит
выполнение всех работ по поддержанию информационного обес¬
печения системы и обеспечению сбора данных. Кроме того, они
должны поддерживать тесный контакт с конечными пользовате¬
лями, который необходим для более полного выяснения и удов¬
летворения потребностей последних. Учитывая большую нагрузку
на службу сопровождения, особое внимание при разработке УСОИ
уделялось созданию простых и гибких средств, обеспечивающих
оперативное выполнение всех требуемых функций.
Под конечным пользователем мы понимаем сотрудника аппа¬
рата управления, основная производственная деятельность кото¬
рого не связана с ЭВМ, но которому требуется оперативный до¬
ступ к отчетной информации, обрабатываемой в рамках УСОИ.
Понимая особую требовательность этой группы пользователей к
общению с ЭВМ, в рамках УСОИ разработаны специальные сред¬
ства ввода и выборки информации, отвлеченные от внутренних
идентификационных атрибутов (каких-либо кодов, шифров и т. п.).
Одной из важных характеристик этих средств является настрой¬
ка не только содержания, но и формы представления информа¬
ции под требования конкретного пользователя.
УСОИ состоит из базы данных, ядра, обеспечивающего син¬
хронизацию ввода информации в базу, и программного окруже¬
ния, которое подразделяется на следующие подсистемы: созда¬
ния приложений; ввода и контроля информации; сопровождения
информации; генерации выходных документов; расчета и форми¬
рования выходных документов; сервиса конечного пользователя
(рис. 1). Система оснащена средствами парольной защиты задач.
Являясь системой реального времени, УСОИ позволяет парал¬
лельную и независимую работу многих пользователей в режиме
ввода, корректировки, расчета и выдачи информации. При этом
введенные данные немедленно становятся доступными тем поль¬
зователям, которым это позволено системой защиты, а также на¬
ходят отражение в выпускаемых документах.
Нормальное состояние УСОИ характеризуется постоянной го¬
товностью к приему и выдаче информации, при этом в режиме
154
ожидания она не потребляет ресурсы ЭВМ. Производительность
системы практически не зависит от количества и объемности за¬
груженных приложений и от количества пользователей.
Современная структура управления носит ярко выраженный
иерархический характер. Использование однотипного математи¬
ческого обеспечения на разных уровнях управления способствует
повышению эффективности обработки информации и, как след¬
ствие, самой системы управления. Для реализации этой возмож-
Рис. 1. Схема функциональ¬
ного построения УСОИ
ности в УСОИ встроены средства выборки информации и орга¬
низации ее в виде, пригодном для ввода в УСОИ другого уровня.
Задача переноса данных из УСОИ в какую-нибудь другую систе¬
му решается с помощью подсистем генерации и формирования
выходных документов, позволяющих создать файл с необходимой
справочной и фактической информацией.
Версия УСОИ 4.01 реализована для ЕС ЭВМ, совместимых по
набору команд с IBM/370, и операционной среды типа VM/SP3
или ее аналогов. Генерация системы управления данными УСОИ
не требует участия разработчиков и может быть произведена
любым системным программистом.
Подсистема создания приложений
Подсистема создания приложений обеспечивает достаточно
быструю разработку и внедрение информационных задач. Под
приложением (видом деятельности) в рамках УСОИ понимается
информационно-независимая область деятельности, обладающая
своим набором входных данных (входные формы, показатели) и
своим набором технологических точек (объектов информации),
деятельность которых характеризуется этими данными. Описание
155
видов деятельности производится с помощью легких для освоения
языковых средств, приближенных к естественному языку. Для
правильной постановки и внедрения задачи пользователю необ¬
ходимо только понимание задачи в деталях и трех-четырехднев-
ное обучение языковым средствам. По опыту работы в ГИВЦ
Миннефтепрома, на проведение организационных работ, связан¬
ных с подготовкой и рассылкой писем, обеспечением сбора необ¬
ходимой информации и т. д., требуется в 5—10 раз больше вре¬
мени, чем непосредственно на разработку самой задачи.
Средства создания приложений УСОИ обеспечивают построе¬
ние информационных структур базы данных УСОИ, которые
включают в себя:
списки объектов информации, представляющие собой перечень
структурных подразделений предприятия, отдельные этапы ка¬
кого-либо производственного процесса и т. д., деятельность ко¬
торых призвана отражать данная задача;
перечень входных показателей, объединенных во входные фор¬
мы, которые отражают различные стороны деятельности пере¬
численных выше объектов информации. Входные формы могут
иметь линейную или табличную структуру. Местоположение и
количество текстовых показателей в форме не регламентировано
и выбирается самим сопровождающим;
регламент поступления входной информации и регламент ее
хранения в базе данных УСОИ;
алгоритмы контроля входной информации, обеспечивающие
ее достоверность при поступлении;
перечень расчетных операций с сохранением результатов в
базе данных.
Подсистема создания приложений выполняет следующие функ¬
ции:
представление условно-постоянной части информации задачи
в виде формализованных описаний;
трансляцию описаний и создание информационных структур
базы данных УСОИ;
обнаружение и диагностирование ошибок в процессе транс¬
ляции;
поддержку и сохранение целостности информационного обес¬
печения задачи при модификации исходных описаний;
каталогизацию информационных структур в базе данных
УСОИ;
удаление информационных структур из базы данных УСОИ.
Построенные на этапе начальной эксплуатации данной задачи
информационные структуры не являются жесткими. В процессе
эксплуатации возможны любые расширения и модификации всех
составляющих компонентов информационных структур.
Формализованное описание информационных структур прило¬
жения реализуется средствами языка описаний видов деятельно¬
сти (ЯОВД). ЯОВД представляет собой язык высокого уровня
простой в освоении и ориентированный на средний технический
156
персонал. Простота и естественность синтаксических конструкций
языка не требуют специальных знаний из области вычислитель¬
ной техники и позволяют полностью сконцентрировать внимание
разработчика на содержательной части задачи.
Процесс трансляции исходных описаний обеспечивает созда¬
ние информационных структур базы данных УСОИ, которые реа¬
лизованы на файлах прямого доступа. Информационные струк¬
туры представляют собой набор управляющих таблиц и подпро¬
грамм во внутренних кодах УСОИ, которые регламентируют про¬
цесс обработки информации по соответствующим видам деятель¬
ности во всех подсистемах УСОИ и управляют им.
База данных УСОИ построена таким образом, что информа¬
ционные структуры разных видов деятельности хранятся обособ¬
ленно и не влияют друг на друга. Это проектное решение создало
необходимые предпосылки для реализации принципа субоптими¬
зации. Иначе говоря, эффективность работы всех подсистем УСОИ
не зависит от количества видов деятельности, загруженных в си¬
стему. Кроме того, принцип информационной независимости соз¬
даваемых приложений обеспечивает достаточную гибкость и про¬
стоту работы службы эксплуатации. Каждый сотрудник, работая
по единой технологической схеме, поддерживает информационное
обеспечение своих задач (видов деятельности) независимо от ра¬
боты других сотрудников.
Однако следует отметить, что информационная независимость
приложений не означает невозможность формирования справок
и таблиц выходных документов, использующих данные разных
видов деятельности.
В системе нет жестких ограничений на то, что считать видом
деятельности. Постановщик задачи из службы сопровождения
сам определяет это понятие в каждом конкретном случае исходя
из удобства эксплуатации. В практике ГИВЦ Миннефтепрома есть
случаи объединения различных по информационному содер-
Рис. 2. Схема работы подсистемы создания приложений
157
КВД;
015 "ОПЕРАТИВНАЯ СВОДКА" БАНК "МАРС";
Л КОИ;
15:- "ПРЕДПРИЯТИЕ А";
15 : 13 "ЦЕХ 13";
15 : 15 "ЦЕХ 15";
15:21 "ЦЕХ 21";
И Т.П. . . .
2 : - "ПРЕДПРИЯТИЕ Б";
2:1 "ЦЕХ 1";
2:7 "ЦЕХ 7";
2 : 19 "ЦЕХ 19";
И Т.П. ...
И ФОРМЫ;
ПМЕС "МЕСЯЧНЫЙ ПЛАН ПО ВЫПУСКУ ПРОДУКЦИИ" МЕС » 24 =
ПП1 "ПЛАН ПРОИЗВОДСТВА ПРОДУКЦИИ",
ПЭК "ПЛАН ЭКОНОМИИ МЕТАЛЛА",
ПРП"ПЛАН РЕАЛИЗАЦИИ ПРОДУКЦИИ";
ФСУТ "ФАКТ ВЫПУСКА ПРОДУКЦИИ ЗА СУТКИ" СУТ * 62 =
ФС1 "ФАКТ ПРОИЗВОДСТВА ЗА СУТКИ",
ФСН1 "ФАКТ ПРОИЗВОДСТВА С НАЧ. МЕСЯЦА",
ФС2 "ОБ'ЕМ БРАКА",
ФСЗ "ОБ'ЕМ ЭКОНОМИИ МЕТАЛЛА",
ФС4 "РЕАЛИЗОВАНО ЗА СУТКИ";
И КОНТРОЛЬ;
"КНТ1" ФСН1 = @2 (XSM-1, ФСН1) + ФС1;
"KHT2" ФС1 < = ФС2 + ФС4;
~ СТОП;
Рис. 3. Пример описания вида деятельности
жанию комплексов в один вид деятельности и разделения
одного целостного информационного комплекса на ряд видов
деятельности.
Общий порядок выполнения полного цикла работ представ¬
лен на рис. 2.
Согласно представленной схеме пользователь видит только
те этапы работы, которые связаны с созданием и корректировкой
на основе протокола ошибок трансляции файла исходных описа¬
ний. Эти работы выполняются в диалоговом режиме с экрана
дисплея. Остальные этапы работ скрыты от пользователя и вы¬
полняются автоматически.
На рис. 3 приводится пример использования ЯОВД для опи¬
сания простейшего вида деятельности.
Как видно из примера, описание состоит из ряда параграфов.
Первый из них КВД (код вида деятельности) содержит код зада¬
чи, ее наименование, тип хранения и пароль на доступ. Далее в
параграфе КОИ (коды объектов информации) представлен пере¬
чень предприятий с делением на цехи с указанием кодов и на¬
званий. Коды объектов в дальнейшем используются для иденти¬
фикации конкретного подразделения при вводе информации, опи¬
сании выходных документов и т. д. Параграф ФОРМЫ, как вид¬
но из его названия, содержит описания входных форм, состоящие
из шифра, периодичности поступления, срока хранения и перечня
158
показателей в виде идентификационных шифров. Коды и шифры
в пределах одного вида деятельности должны быть уникальны.
Следует отметить, что коды объектов информации, шифры по¬
казателей, входных форм являются необходимыми атрибутами
информационных систем. С другой стороны, их использование для
идентификации информации вызывает затруднения у конечных
пользователей (работников аппарата управления). УСОИ имеет
удобные средства работы конечного пользователя, в которых шиф¬
ры и коды замаскированы, а на экран дисплея выдаются соот¬
ветствующие текстовые эквиваленты. Наименования элементов
задачи задаются в виде произвольных текстов, заключенных в
кавычки.
В параграфе КОНТРОЛЬ представляется перечень формул
контроля, которые призваны обеспечить достоверность входной
информации. Формулы контроля задаются в виде логических со^
отношений (равно, неравно, больше, меньше и т. д.) между ариф¬
метическими выражениями. В качестве операндов выступают
шифры показателей, числовые константы, временные функции
(номер текущего дня, месяца, квартала и т. д.) и так называе¬
мые альфа-функции ( ©-функции), которые позволяют выбирать
значение показателя за любой временной период. Так, в формуле
контроля КНТ1 конструкция© 2(XSM-1, ФСН1) возвратит значе¬
ние показателя ФСН1 за предыдущие сутки (временная функция
XSM выдает номер дня с начала месяца).
Возможны и более сложные конструкции формул контроля с
использованием альтернативного выбора, формула контроля мо¬
жет включать в себя показатели из разных входных форм (меж¬
форменный контроль). Алгоритмы контроля реализуются непо¬
средственно в процессе ввода информации, и результаты контро¬
ля возвращаются источнику.
Подсистема ввода и контроля информации
Подсистема ввода и контроля информации обеспечивает син¬
таксический разбор входных сообщений и проведение логического
контроля по алгоритмам, заданным в описаниях видов деятель¬
ности. Совмещение логического контроля со стадией ввода ин¬
формации позволяет немедленно оповестить поставщиков инфор¬
мации о допущенных ошибках, что, с одной стороны, оказывает
дисциплинирующее воздействие, а с другой — предоставляет ему
возможность оперативно исправить эти ошибки. Наличие логи¬
ческих ошибок не является препятствием для занесения инфор¬
мации в базу данных, поэтому все сведения об ошибках зано¬
сятся в специальные журналы логических ошибок. Полноту по¬
ступления отчетной информации отражают журналы поступления.
Журналы используются подсистемой сопровождения для инфор¬
мирования работника службы сопровождения об актуальном со¬
стоянии базы данных.
159
Подсистема ввода обеспечивает параллельную обработку ин¬
формации как в пакетном режиме, так и в режиме диалога от
всех имеющихся устройств ввода (межмашинные каналы связи,
локальные и удаленные терминалы, перфокарты, перфоленты,
магнитные ленты, телетайпы). Блок опроса периферийных уст¬
ройств ввода, так же как и ядро УСОИ, инициализируется при
старте операционной системы. Этим обеспечивается постоянная
готовность системы к приему и обработке информации. Комплекс
программ ввода работает в автоматическом режиме и не требует
вмешательства оператора.
Подсистема сопровождения информации
Подсистема сопровождения информации представляет собой
основной инструмент, которым работники группы сопровождения
пользуются в своей повседневной деятельности. Основная задача
подсистемы — помочь сопровождающему своевременно собрать
полную и корректную информацию о работе подотчетных подраз¬
делений.
Как отмечалось ранее, УСОИ является диалоговой системой,
т. е. все контакты человека с системой осуществляются через
дисплей. Пульт этого терминального устройства является рабочим
местом сопровождающего. Наряду с широтой выполняемых функ¬
ций к подсистеме предъявляются требования быстрой реакции и
лаконичности в общении. Поэтому для диалога с подсистемой со¬
провождения разработчиками использован специальный язык за¬
просов. Он состоит из списка сокращенных наименований запро¬
сов и набора ключей, по которым производится выборка инфор¬
мации. В качестве ключей поиска используются: дата и время
поступления сообщений, код вида деятельности, наличие синтак¬
сических ошибок, код отчетного абонента и некоторые другие.
Функциональные возможности подсистемы сопровождения в ряде
случаев перекрывают друг друга для более полного соответствия
потребностям конкретного сопровождающего. Ниже перечисля¬
ются функции, выполняемые подсистемой сопровождения инфор¬
мации.
1. Поиск сообщений по различным критериям. Поступающие
в систему УСОИ входные сообщения накапливаются в архивном
файле базы данных УСОИ, и время от времени возникает необ¬
ходимость выбрать ряд сообщений, агрегированных по каким-либо
критериям или их совокупности (например, найти все синтакси¬
чески неверные сообщения по задаче 15, пришедшие первого ап¬
реля после 11 часов утра).
2. Ввод информации с экрана дисплея. Небольшие объемы ин¬
формации сопровождающий вводит в интерактивном режиме в
свободном формате входного языка или с использованием средств
конечного пользователя. При этом вся диагностика подсистемы
ввода и контроля направляется непосредственно на экран поль¬
зователя.
160
3. Корректировка информации. Пользуясь различными крите¬
риями поиска, сопровождающий может вызвать то или иное со¬
общение из архивного файла на экран дисплея и скорректировать
любую его часть. Существует возможность достать информацию,
скомпонованную и оформленную по правилам входного языка,
непосредственно из базы данных. Средства ввода конечного поль¬
зователя тоже дают возможность вызова информации из базы
данных и корректировки ее в форматном режиме.
4. Ввод информации в пакетном режиме. При вводе больших
объемов информации (например, плановых показателей на пред¬
стоящий период) удобнее заранее подготовить файл с сообще¬
ниями, обработать его целиком, а потом уже проверить описан¬
ными выше средствами или визуально по протоколу корректность
ввода.
5. Получение протоколов поступления входных форм. Количе¬
ство объектов информации в одном виде деятельности может ис¬
числяться сотнями, и поэтому слежение за поступлением от них
данных требует особого аппарата. Последний позволяет полу¬
чить протоколы поступления форм в виде документа с указанием
даты прихода формы и адреса сообщения с этой формой в ар¬
хивно^ файле. Получить этот протокол можно как на экране, так
и в твердой копии.
6. Получение протоколов логических ошибок. Протокол обна¬
руженных логических ошибок представляется в виде числовой
реализации алгоритмов контроля, сгруппированных по входным
формам и объектам информации. Зная показатели, входящие в
конкретный алгоритм, сопровождающий легко обнаруживает ис¬
точник возникновения ошибки.
7. Повторный ввод информации. В случаях потери информа¬
ции из-за сбоя на магнитных дисках или по каким-то иным при¬
чинам в системе УСОИ существует возможность восстановления
базы данных по архивному файлу. При этом из файла выбира¬
ются и обрабатываются сообщения, удовлетворяющие указанным
сопровождающим критериям (например, все сообщения, пришед¬
шие по виду деятельности 15, начиная с 12 марта).
8. Накопление статистики и контроль за соблюдением регла¬
мента прихода входных форм. Сопровождающий имеет возмож¬
ность получить поабонентные справки о нарушениях регламента
передачи и количестве логических ошибок в переданной инфор¬
мации. Доводя эту информацию до руководителей отчитываю¬
щихся предприятий, можно добиться снижения количества оши¬
бок и более строгого соблюдения регламентных сроков передачи
данных.
Подсистема генерации выходных документов
Разработка выходных документов является неотъемлемой ча¬
стью любой информационной системы. Обычно решение этой за¬
дачи требует больших трудозатрат, особенно в том случае, если
11 Заказ 5620
161
она реализуется традиционным способом, т. е. написанием от¬
дельных программ на одном из универсальных алгоритмических
языков.
УСОИ изначально проектировалась как инструмент решения
задач оперативного управления, характерной особенностью кото¬
рых является постоянная изменчивость состава входной инфор¬
мации и формы представления выходных данных. В связи с этим
разработчикам были предъявлены жесткие требования по обес¬
печению гибкости средств формирования выходных документов,
технологичности и простоте их эксплуатации. Естественным ре¬
шением этой проблемы оказалось использование универсального
генератора отчетов. В отечественной и зарубежной литературе во¬
просу генерации отчетов уделяется достаточно много внимания.
Основным принципом, по которому работает ряд генераторов, яв¬
ляется принцип автоматизированного конструирования программ
на одном из универсальных алгоритмических языков с последую¬
щей их компиляцией. Схема работы такого генератора отраже¬
на на рис. 4.
Исходные описания выходных документов обычно составляют¬
ся либо с помощью параметрических определений, либо средст¬
вами проблемно-ориентированных языков высокого уровня.
Этот подход является наиболее общим, поскольку предостав¬
ляет практически неограниченные возможности формирования
любого документа. Отсутствие или недостаточная выразительность
каких-либо средств в языке исходных описаний обычно компен¬
сируется возможностью внесения соответствующих изменений в
сгенерированную программу перед ее компиляцией.
Но именно последний довод является наиболее веским аргу¬
ментом против использования данного подхода. Опыт эксплуата¬
ции подобных генераторов отчетов показывает, что более или
менее развитые информационные системы не могут существовать
без постоянного участия профессиональных программистов в про¬
цессе эксплуатации. Использование средств операционной систе¬
мы (компилятор, редактор связей) предполагает появление ДИ-
Рис. 4. Схема работы традиционного генератора отчетов
Г62^
Рис. 5. Технологическая схема работы подсистемы
генерации и формирования выходных документов
УСОИ
агностики, разобраться в которой невозможно без участия ква¬
лифицированных специалистов, что не может не вызвать небла¬
гоприятной реакции со стороны службы эксплуатации. В процес¬
се развития информационных комплексов число программных мо¬
дулей растет практически неограниченно, что приводит к услож¬
нению процесса эксплуатации. Все это нарушает основное усло¬
вие, поставленное перед УСОИ,— поддержка системы исключи¬
тельно силами технологического персонала. В качестве альтерна¬
тивного варианта в УСОИ принята схема, приведенная на рис. 5.
Подсистема генерации выходных документов, реализованная
в рамках УСОИ, представляет собой мощное средство создания
разнообразных таблиц отчетов различной степени сложности.
Исходные описания выходных документов создаются средствами
языка описаний документов (ЯД) УСОИ.
ЯД представляет собой проблемно-ориентированный язык вы¬
сокого уровня, рассчитанный на средний технический персонал.
В ЯД реализованы возможности представления графики доку¬
мента и чисто языковых конструкций, определяющих порядок и
правила формирования содержательной части документа. ЯД
прост в освоении и, несмотря на наличие конструкций, присущих
языкам программирования (таких, как циклы, альтернативный
выбор и т. д.), не требует при использовании квалификации про¬
фессиональных программистов. Описания выходных документов
целиком базируются на терминах, используемых при описании
приложений. Система не накладывает никаких количественных
или качественных ограничений на выборку информации из раз¬
личных приложений. В зависимости от того, как в дальнейшем
будут использоваться описания документов, последние готовятся
подсистемой в одном из трех видов:
для массового формирования документов и печати их на цент¬
ральном печатающем устройстве;
для выборки информации из базы данных и обеспечения ин¬
терфейса с другой системой управления данными УСОИ;
И* 163
для динамического формирования справок иа экран дисплея.
Различия в подготовке этих описаний незначительны и не на¬
рушают общей технологии обработки информации.
Для более предметного разговора на рис. 6 приведен пример
описания документа на ЯД, а на рис. 7 — документ, полученный
по этому описанию. Цифры, приведенные в сводке, условные.
# ФОРМА = ПРИМ1 СУТ;
МАКЕТ
1 : "С В О Д К А",
2 : "О ВЫПОЛНЕНИИ СУТОЧНОГО ПЛАНА ПРОИЗВОДСТВА ПРОДУКЦИИ",
3 : "ДСП ЭКЗ №...",
4 : "ПЛАН", 5 : "ФАКТ", 6 : "НА МЕСЯЦ (ТЫС. Т ) •
7 : "НА СУТКИ (Т ) ", 8 : "С НАЧАЛА МЕСЯЦА’",
9 : "% ВЫПОЛНЕНИЯ МЕСЯЧНОГО ПЛАНА", 10 : - ЗА СУТКИ";
БОК
1) ITOG # 10
2) # 10 SUBS (15 : *)
1) ITOG [%7 < 0] # 10
"ВСЕГО ПО ПРЕДПРИЯТИЮ А"’.;
— — NAMAB! LF [%2 = 0];
"ИТОГО НЕ ВЫПОЛНИВШИЕ ПЛАН"!;
МАТРИЦА
D I =!=!=!= I %4 * ЮО/%2 ! = !;
2) ! ПП1 I ПП1 * 1000/XSML ! ФСН1/1000 I
ФС1 ! %4 * ЮО/%2 ! %5 - %2 !;
Рис. 6. Пример исходного описания выходного документа
ГИВЦ МИННЕФТЕПРОМА 02/04/86 7:44 "ПРИМ1"
СВОДКА
О ВЫПОЛНЕНИИ СУТОЧНОГО ПЛАНА ПРОИЗВОДСТВА ПРОДУКЦИИ’
ДСП ЭКЗ №
ЗА 01 АПРЕЛЯ 1986 ГОДА ,
ПЛАН!
ФАКТ-
% ВЫ-
ПОЛНЕ-
НИЯ
МЕС.
ПЛАНА
+ - ЗА
СУТКИ
НА
МЕСЯЦ
(ТЫС.Т )
! НА ;
СУТКИ
: (ТГ :
С НАЧАЛА
МЕСЯЦА
НА
СУТКИ
(Т);
ВСЕГО ПО ПРЕДПРИЯТИЮ А
2780.54 ;
98407
98.52
' 98521
3.5
114
ЦЕХ 13
513.25 :
17108
17105
17050
3.3
-58
ЦЕХ 15
83.40!
2780
2.80
2795
3.4
16
ЦЕХ 21
111.00:
3700
3.70
3700
3.3
0
ИТОГО НЕ ВЫПОЛНИВШИЕ ПЛАН
618.48 •
20616
20.54
20540
3.3
-76
Рис. 7. Внешний вид выходного документа
J 64
Описание выходного документа составлено на основании вида
деятельности, описание которого отражено на рис. 3. Предпола¬
гается сформировать документ, таблица которого содержит в бо¬
ковине перечень подразделений предприятия А. Конструкция
«SUBS (15 :#)» указывает, что требуется выбрать подмножест¬
во объектов информации с фиксированным первым ключом, т. е.
все цехи предприятия А. Причем требуется подавить печать тех
строк, значение показателя «План на месяц» в которых (колон¬
ка 2) равно нулю. Это обеспечивается указанием функции «LF
(условие)». Первая строка представляет деятельность всего пред¬
приятия и является по сути итоговой строкой. Функция «ITOG#
10» указывает, что надо просуммировать содержимое всех строк
с меткой #10. Колонки, по которым осуществляется суммирова¬
ние, помечаются в описании раздела «МАТРИЦА» символом
« = ». Последняя строка документа подводит итог только по тем
подразделениям предприятия А, которые не выполнили суточный
план производства продукции. Это реализуется указанием усло¬
вия «[%7<0]» в функции «ITOG».
Особого внимания заслуживают следующие возможности ЯД:
выполнение любых арифметических операций на стадии выда¬
чи при формировании каждой клетки таблицы документа;
реализация операций с колонками и строками;
альтернативный выбор, подобный «IF THEN ELSE» и «SE¬
LECT» в языках программирования;
условные функции подавления печати и перехода на следую¬
щую страницу, обеспечивающие динамичность структуры доку¬
мента в зависимости от значений фактической и условно-постоян¬
ной информации в базе данных УСОИ;
использование повторяющихся фрагментов ранее описанных
документов, позволяющих сократить трудоемкость работ по опи¬
санию новых документов;
наличие встроенных функций, позволяющих выбирать инфор¬
мацию за любой интервал времени, что обеспечивает построение
сравнительных и хронологических таблиц;
внедрение текстов и дат в содержательную часть документа.
Даже этот далеко не полный список возможностей ЯД позво¬
ляет создавать документы достаточно сложной структуры. Прак¬
тическое использование ЯД не предполагает знание всех воз¬
можностей, что обеспечивает его поэтапное освоение и быстрое
внедрение.
Описания, составленные на ЯД, служат входными данными
Для транслятора выходных документов. Основными функциями
транслятора являются: проведение лексического анализа, иден¬
тификация условно-постоянной информации в базе данных УСОИ,
проведение синтаксического разбора конструкций и выражений
языка и построение программы формирования документа. Про¬
грамма представляет собой последовательность команд, интерпре¬
тация которых на стадии обработки и выдачи документов при¬
165
водит к требуемому результату. Программы формирования вы¬
ходных документов могут быть объединены в тематические сбор¬
ники.
Подсистема расчета и формирования выходных документов
Подсистема расчета и формирования выходных документов
предназначена для проведения всех расчетных и редакционных
операций, необходимых для получения конечного результата. На
этом этапе реализуются алгоритмы, подготовленные подсистемой
создания приложений и подсистемой генерации выходных доку¬
ментов. Описываемая подсистема по сути является програм¬
мной моделью процессора, призванного исполнять подаваемую
ему на вход последовательность команд с получением результата
в виде таблиц документов или расчетных показателей. Фактиче¬
ская информация, требуемая для проведения вычислений и фор¬
мирования документов, выбирается из базы данных УСОИ в мо¬
мент процессирования.
Работа пользователя с подсистемой расчета и формирования
выходных документов предельно проста и сводится к указанию
имен документов и дат, за которые эти документы требуется
получить. Дополнительно реализованы развитые средства иден¬
тификации и поиска требуемых программ выдачи. Обеспечива¬
ются режимы селективной выдачи отдельных документов и мас¬
совой выдачи по определенной заданной тематике. Высокая ско¬
рость работы процессора обработки документов, наличие простых
средств поиска и выборки программ по заданной тематике по¬
зволяют обеспечить процесс выдачи документов силами пользо¬
вателей с возможностями визуального их просмотра на экране
дисплея и получения твердой копии на АЦПУ.
Подсистема сервиса конечного пользователя
Подсистема сервиса конечного пользователя обеспечивает до¬
ступ к информации, необходимой для ежедневной работы сотруд¬
ника аппарата управления. Имеющиеся средства позволяют на¬
страивать работу программ исходя из требований каждого поль¬
зователя.
Подсистема предоставляет пользователю возможность выбор¬
ки из базы данных УСОИ значений отдельных показателей и их
производных и возможность представления результата в таблич¬
ном и графическом виде на экране дисплея. При наличии ло¬
кального печатающего устройства пользователь может оператив¬
но получить твердую копию документа.
Для обеспечения максимальной простоты диалога с пользова¬
телем и облегчения уровня специальной подготовки пользователя
в основу запросов на предоставление информации положен прин¬
цип «меню». Состав таблиц «меню» отражает перечень наимено¬
ваний показателей и их вариаций, значения которых можно вы¬
166
брать из базы данных УСОИ и представить на экране в виде таб¬
лиц или графиков.
В принципе можно поместить на одну таблицу полный пере¬
чень наименований показателей, загруженных в систему. Однако
следует учесть, что состав базы данных УСОИ, как правило, вклю¬
чает в себя несколько тысяч наименований показателей и их ва¬
риаций, которые имеют следующие особенности:
характеризуют различные (порядка 20—30) направления дея¬
тельности;
имеют различную периодичность отчетности;
характеризуют деятельность различного состава предприятий
и их подразделений (объединение, предприятие, цех и т. п.).
Трудно представить себе не только отдельного человека, ио
даже отдельную службу, оперативные интересы которой охваты¬
вали бы одновременно абсолютно весь перечень поступающей в
УСОИ информации. Наиболее реальной представляется ситуация,
в которой пользователю или группе пользователей требуется не¬
которое подмножество из общего состава информации, тематиче¬
ски обособленное и определяемое самим пользователем. Такое
подмножество в дальнейшем будем называть «Профиль интере¬
сов пользователя».
Разделение всей информации на профили интересов повышает
технологичность работы по выборке требуемой информации, так
как позволяет сотруднику работать только с тем объемом инфор¬
мации, который нужен ему, а не всем пользователям. Профилей
интересов может быть как один, так и несколько, причем неко¬
торые из них должны являться рабочим инструментом только од¬
ного работника, в то время как другие могут обслуживать мно¬
гих пользователей одновременно.
Подсистема сервиса конечного пользователя делится на две
функциональные части: просмотр и ввод данных в форматном
режиме (DIALOG) и динамическое формирование сводок на эк¬
ране (ZAPROS).
Программный комплекс DIALOG
Программный комплекс DIALOG — это интерфейс конечного
пользователя и базы данных. Он предоставляет информацию в
полном соответствии со структурами, разработанными при описа¬
нии вида деятельности (см. рис. 3), но в форматном виде и с
упором на названия атрибутов (форм, показателей и т. д.). Комп¬
лекс обеспечивает следующие возможности пользователя:
ввод новой информации непосредственно с экрана дисплея;
просмотр и корректировку информации;
отслеживание поступления информации;
отслеживание логических ошибок во введенной информации.
Комплекс построен по принципу «меню» с широким использо¬
ванием функциональных ключей (PF-ключей) для перехода с
одного уровня на другой. Для сокращения итераций применяется
167
ВВЕДИТЕ ПРОФИЛЬ ВАШИХ ИНТЕРЕСОВ
ПАРОЛЬ НА ДОСТУП К ИНФОРМАЦИИ
PF12-КОНЕЦ РАБОТЫ
Рис. 8. Определение профиля интересов конечного пользователя
незначительное число командных конструкций, осуществляющих
настройку на конкретную дату, установку текущей строки, поиск
заданной комбинации символов и некоторые другие функции.
Выводимые на экран таблицы снабжены необходимыми коммен¬
тариями. Всего существует четыре уровня (типа таблиц):
определения профиля интересов (КВД);
выбора входных форм;
выбора абонентов;
анализа и ввода показателей.
Ниже разбирается работа комплекса на примере ранее опи¬
санного вида деятельности.
/. Уровень определения профиля интересов. Информация в
базе данных агрегирована по задачам, поэтому перед началом
ввода данных необходимо указать код вида деятельности и его
пароль (рис. 8). В ряде случаев бывает удобно работать не с
полной структурой вида деятельности, а с некоторым ее подмно¬
жеством. Например, чрезмерно большой список входных форм
загромождает экран и затрудняет поиск нужной информации.
Роль ограничителя списков играет профиль интересов, подготав¬
ливаемый заранее службой сопровождения.
2. Уровень выбора форм. После определения профиля интере¬
сов пользователю предоставляется на экране список форм, опре¬
деленных на данном виде деятельности (с учетом ограничений
из профиля интересов). Таблица, представленная на рис. 9, со¬
держит:
наименование вида деятельности, с которым идет работа;
наименование входной формы;
шифр формы;
периодичность поступления формы;
количество показателей в форме (для табличных форм —
«ТБЛ»).
Для работы с большими списками, не помещающимися на од¬
ном экране дисплея, предусмотрены следующие возможности:
168
ОПЕРАТИВНАЯ СВОДКА
МЕСЯЧНЫЙ ПЛАН ПО ВЫПУСКУ ПРОДУКЦИИ ПМЕС486 МЕС 3
ФАКТ ВЫПУСКА ПРОДУКЦИИ ЗА СУТКИ ФСУТ СУТ 5
PF : 2 - ВПЕРЕД, 1 - НАЗАД, 3 - ВЫБОР ПРОФ. ИНТ., 4 - ВЕРХ.
Рис. 9. Список входных форм
листание списка вперед и назад (ключи PF1 и PF2);
установка помеченной символом «/» строки в верхней строчке
экрана;
поиск строки по комбинации символов;
возврат на начало списка (ключ PF4).
Для возврата на предыдущий уровень (в данном случае уро¬
вень выбора профиля интересов) задействован ключ PF3, а для
окончания работы — ключ PF12. Подобный механизм использу¬
ется и на всех других уровнях.
Для выбора формы достаточно в командную строку, распола¬
гающуюся непосредственно за шифром формы, ввести дату, за
которую требуется информация.
3. Уровень выбора абонентов. Каждая форма определена на
конкретном списке объектов информации, который представляет¬
ся на этом уровне. На экран выводится следующая информация
(рис. 10):
наименование вида деятельности;
наименование формы;
шифр формы;
дата, за которую представляется информация;
наименование абонента;
шифр абонента;
информация о поступлении;
информация о наличии логических ошибок.
ОПЕРАТИВНАЯ СВОДКА
486
МЕСЯЧНЫЙ ПЛАН ПО ВЫПУСКУ ПРОДУКЦИИ
ПРЕДПРИЯТИЕ А
15 : -
ПМЕС
#
ЦЕХ 13
15 : 13
+ Л
ЦЕХ 15
15 : 15
+
ЦЕХ 21
15 : 21
#
+
PF : 2 - ВПЕРЕД, 1 - НАЗАД, 3 - ВЫБОР ФОРМЫ, 4
- ВЕРХ,
Рис. 10. Список объектов информации по входной форме «ПМЕС»
169
ОПЕРАТИВНАЯ СВОДКА 485
МЕСЯЧНЫЙ ПЛАН ПО ВЫПУСКУ ПРОДУКЦИИ
ПМЕС
ПРЕДПРИЯТИЕ А
15 : -
ПЛАН ПРОИЗВОДСТВА ПРОДУКЦИИ
1.
2770.14
-
ПЛАН ЭКОНОМИИ МЕТАЛЛА
2.
4.621
—
ПЛАН РЕАЛИЗАЦИИ ПРОДУКЦИИ
3.
2685.43
-
ЦЕХ 13
15 : 13
ПЛАН ПРОИЗВОДСТВА ПРОДУКЦИИ
1.
512.00
513.25
ПЛАН ЭКОНОМИИ МЕТАЛЛА
2.
1.429
1.429
ПЛАН РЕАЛИЗАЦИИ ПРОДУКЦИИ
3.
500.00
-
ЦЕХ 15
15 : 15
ПЛАН ПРОИЗВОДСТВА ПРОДУКЦИИ
1.
82.14
83.40
ПЛАН ЭКОНОМИИ МЕТАЛЛА
2.
0.156
0.156
ПЛАН РЕАЛИЗАЦИИ ПРОДУКЦИИ
3.
75.3
84.95
ЦЕХ 21
15 : 21
ПЛАН ПРОИЗВОДСТВА ПРОДУКЦИИ
1.
110.00
111.00
ПЛАН ЭКОНОМИИ МЕТАЛЛА
2.
0.201
0.201
ПЛАН РЕАЛИЗАЦИИ ПРОДУКЦИИ
3.
100.3
105.08
ДЛЯ ОБРАБОТКИ ПОШЛИТЕ ЛЮБОЙ СИМВОЛ _
PF: 2-ВПЕРЕД, 1 - НАЗАД, 3 — ВЫБОР АБОНЕНТА, 4 - ВЕРХ.
Рис. 11. Таблица просмотра и корректировки показателей
Информация о поступлении расшифровывается следующим об¬
разом:
« + » — информация поступила;
«—» — информация не поступила;
«Н» — абонент, не отчитывающийся по данной форме (т. е. ин¬
формация по нему не поступает).
Наличие логических ошибок по конкретному абоненту поме¬
чается символом «Л». Для просмотра логических ошибок по дан¬
ной форме достаточно ввести символ «Л» в командном поле.
Для выбора абонентов в командном поле помещается сим¬
вол «#».
4. Уровень анализа и ввода показателей. Входные показатели
группируются по форме и отобранным абонентам (рис. 11). Для ра¬
боты с формами, имеющими более 20 показателей, используется
ранее описанный механизм «листания» экранов. Значениям пока¬
зателей (правая колонка чисел) сопутствуют наименования: вида
деятельности, формы, абонента и самих показателей, порядковые
номера показателей в форме и их значения за предыдущий пе¬
риод. Символ «—» означает отсутствие значения показателя.
Пользователь имеет право изменить любое значение показа¬
теля или ввести число вместо символа «—». Для занесения ин¬
формации в базу данных достаточно поставить любой символ в
поле «Обработать». Значения показателей за прошлый период
выводятся только для сравнения и изменению не подлежат.
Если во введенной информации присутствуют логические
ошибки, то они будут направлены на экран с необходимой сопро¬
водительной информацией.
170
Программный комплекс ZAP ROS
Программный комплекс ZAPROS обеспечивает пользователю
возможность увидеть на экране дисплея информацию из базы
данных системы УСОИ в удобном обозримом виде по «избран¬
ным» показателям, их вариациям и абонентам.
Под вариациями мы понимаем набор некоторых производных
фактического показателя. Например, для показателя «Факт вы¬
пуска продукции» возможны следующие вариации:
за сутки;
за сутки Н— к плановому заданию;
за сутки Н— к предыдущим суткам;
% к плановому заданию;
за месяц;
нарастающий с начала месяца.
Комплекс построен по принципу «меню», позволяющему на
каждом уровне выбирать одну из предложенных возможностей.
Выводимые на дисплей таблицы снабжены комментариями.
Работа с комплексом ZAPROS разбита на четыре уровня:
1) уровень определения профиля интересов;
2) уровень выбора показателей;
3) уровень представления значений показателей;
4) уровень хронологической развертки показателей.
На каждом уровне при помощи функционального ключа PF6
можно получить на экран исчерпывающую информацию о спосо¬
бах продолжения работы, что придает системе самообучающие
свойства. Для окончания работы с комплексом ZAPROS исполь¬
зуется ключ PF12, а для возврата на предыдущий уровень — PF3.
Подробнее работа с комплексом рассматривается ниже на
примере профиля интересов, аналогичном приведенному на рис. 6
описанию выходного документа.
1. Уровень определения профиля интересов. Каждому пользо¬
вателю может быть доступно несколько профилей интересов, и на
этом уровне ему позволяется пометить один из них. На рис. 12
представлен случай, когда пользователю доступны три различ¬
ных профиля интересов и отобран первый из них.
2. Уровень выбора показателей. После определения профиля
интересов пользователю предоставляется на экран список пока-
LVL 0
-- ФАЙЛЫ
ВВОД
ПРОФИЛИ FILE 1 OF 3
PROF
PRIM
А1
tF
ВЫПУСК ПРОДУКЦИИ ПО ПРЕДПРИЯТИЯМ
PROF
PRIM1
А1
ПОСТАВКА ПРОДУКЦИИ НА ЭКСПОРТ
PROF
PRIM2
А1
ИМПОРТ ПРОДУКЦИИ НА СЫРЬЕ
PF1 - ВВОД, PF6 - HELP, PF12 = СТОП
Рис. 12. Список профилей интересов
171
ДАТА: 860401 ППМ ФПП ФНМ ФС +-П
ПРОИЗВОДСТВО ПРОДУКЦИИ 1 з 2
РЕАЛИЗАЦИЯ ПРОДУКЦИИ
ЭКОНОМИЯ МЕТАЛЛА
ОБ'ЕМ БРАКА
PF : 2 - ВП, 1 - НАЗ, 3 - ПРОФ. ИНТ., 4 - ВРХ, 5 - ПОДС, 6 - HELP.
Рис. 13. Список доступных показателей и их вариаций
зателей и их вариации. На таблице (рис. 13) присутствуют: дата,
наименования показателей и символические обозначения вариа¬
ций этих показателей.
Список показателей предоставляет пользователю возможность
пометить интересующие его показатели для последующей рабо¬
ты с ними. Вариации, определенные для данного показателя, по¬
мечаются символом «.». Для выбора вариаций пользователю до¬
статочно поставить против имени показателя в соответствующей
колонке любой символ, отличный от «.». Пользователь может
пронумеровать отбираемые им вариации, и тогда колонки в справ¬
ке будут подобраны в заданной последовательности. Так как раз¬
меры экрана ограничены, то комплекс анализирует возможность
представления на экран отобранных показателей. Если это не¬
возможно, пользователь будет предупрежден, и от него потребу¬
ется повторить выбор.
Полные наименования вариаций приводятся при нажатии клю¬
ча PF5. В случае любых затруднений следует использовать ключ
PF6, и на экране появится описание всех возможных на данном
уровне действий. На рис. 14 приведен пример такой инструкции,
относящейся к уровню выбора показателей.
3. Уровень представления значений показателей. Значения
отобранных вариаций показателей компонуются в виде справки
по всем абонентам и представляются на экран (рис. 15). При ра¬
боте с такого рода справками порой возникает необходимость от¬
сортировать (отобрать) строки по некоторому критерию. Напри¬
мер, сравнив с некоторой константой значения одного из показа¬
телей, критерий вводится под тем показателем, по которому осу¬
ществляется отбор строк. Так, после ввода комбинации «>0»
под второй колонкой на экране останутся только те строки, в
которых значения показателя «Н— к плану» больше нуля (ис¬
чезнут абоненты «Цех 13», «Цех 25», «Цех 26»). По ключу PF7
будет распечатана справка по всему списку абонентов на мест¬
ном (расположенном рядом с дисплеем) АЦПУ.
172
ИНСТРУКЦИЯ
ВЫ НАХОДИТЕСЬ НА УРОВНЕ ВЫБОРА ПОКАЗАТЕЛЕЙ.
ВАМ ПРЕДОСТАВЛЯЕТСЯ НА ЭКРАН ТАБЛИЦА, ПРОСТАВЛЯЯ В НЕЙ ЛЮБЫЕ
СИМВОЛЫ, ВЫ ФОРМИРУЕТЕ СВОЮ СПРАВКУ.
ДЛЯ ПЕРЕСТАНОВКИ СТОЛБЦОВ ИТОГОВОЙ СПРАВКИ МОЖНО НУМЕРОВАТЬ
ОТБИРАЕМЫЕ СОЧЕТАНИЯ, В ДОКУМЕНТЕ КОЛОНКИ БУДУТ РАСПОЛОЖЕНЫ
В ЗАДАННОЙ ПОСЛЕДОВАТЕЛЬНОСТИ.
ЕСЛИ НЕОБХОДИМО ПОЛУЧИТЬ ИНФОРМАЦИЮ ЗА ДАТУ, ОТЛИЧНУЮ ОТ
ПРЕДСТАВЛЕННОЙ В ЛЕВОМ ВЕРХНЕМ УГЛУ ЭКРАНА,
ТО ВЫ МОЖЕТЕ ИЗМЕНИТЬ ЭТУ ДАТУ НА ЭКРАНЕ.
В СЛУЧАЕ ЗАТРУДНЕНИЙ С НАЗВАНИЯМИ ВАРИАЦИЙ СЛЕДУЕТ
ИСПОЛЬЗОВАТЬ ФУНКЦИОНАЛЬНЫЙ КЛЮЧ PF5, И НА ЭКРАНЕ БУДЕТ
ПРЕДСТАВЛЕН СПИСОК ВАРИАЦИЙ С ПОЛНЫМИ ИМЕНАМИ.
НАЗНАЧЕНИЕ КЛЮЧЕЙ:
PF1 - ЛИСТАНИЕ СПИСКА НАЗАД.
PF2 - ЛИСТАНИЕ СПИСКА ВПЕРЕД.
PF3 - ВОЗВРАЩЕНИЕ НА ПРЕДЫДУЩИЙ УРОВЕНЬ.
PF4 - УСТАНОВКА НА НАЧАЛО СПИСКА.
PF5 - ДЛЯ ПОЯСНЕНИЯ ПОЛНЫХ НАЗВАНИЙ ВАРИАЦИЙ
PF6 - ВЫЗОВ НА ЭКРАН ДАННОЙ ИНСТРУКЦИИ.
PF12 - ОКОНЧАНИЕ ПРОГРАММЫ НА ВСЕХ УРОВНЯХ
«оо**#**#**** ДЛЯ ВЫХОДА НАЖМИТЕ <ENTER>
Рис. 14. Пример инструкции на уровне выбора показателей
Командные поля на этой таблице расположены перед наиме¬
нованиями абонентов и под значениями вариаций. Они предна¬
значены для выбора тех и других и перехода на следующий уро¬
вень хронологической развертки показателей. Возможны два ва¬
рианта выбора: хронология нескольких показателей по одному
абоненту и хронология одного показателя по нескольким або¬
нентам.
На рис. 15 представлен вариант запроса динамики трех ва¬
риаций по абоненту «Цех 21» (помечены символом «#»).
4. Уровень хронологической развертки показателей. Хроноло¬
гическая таблица изменения показателей абонента «Цех 21»
представлена на рис. 16. Если бы пользователь запросил инфор-
860401
ВЫПУСК
ВЫПУСК
ВЫПУСК
ПРОДУКЦИИ
ПРОДУКЦИИ ПРОДУКЦИИ
ПЛАН С
+ -К
НАРАСТ.
(Т)
ПЛАНУ
(ТЫС.Т)
ПРЕДПРИЯТИЕ А
98407
114
98.52
ЦЕХ 13
17108
-58
17.05
ЦЕХ 15
2780
15
2.80
# ЦЕХ 21
3700
0
3.70
#
#
PF: 2 - ВП,-1 - НАЗД,
3 - ВЫБР АБ-ТА,
4- ВЕРХ, 5
-ШАПКА, 6-HELP.
Рис. 15. Пример представления справки на экран пользователя
173
ЦЕХ 21
ДАТА
ВЫПУСК
ВЫПУСК
ВЫПУСК
ПРОДУКЦИИ
ПРОДУКЦИИ
ПРОДУКЦИИ
ПЛАН
+ — К
НАРАСТ.
(Т )
ПЛАНУ
(ТЫС. Т)
12 МАРТА
1986 г.
0
125.53
13 МАРТА
1986 г.
17108
0.5
127.25
14 МАРТА
1986 г.
17108
0.5
127.25
15 МАРТА
1986 г.
17108
0.5
127.25
16 МАРТА
1986 г.
17108
0.5
127.25
17 МАРТА
1986 г.
17108
0.5
127.25
18 МАРТА
1986 г.
17108
0.5
127.25
19 МАРТА
1986 г.
17108
0.5
127.25
20 МАРТА
1986 г.
17108
0.5
127.25
21 МАРТА
1986 г.
17108
0.5
127.25
22 МАРТА
1386 г.
17108
0.5
127.25
23 МАРТА
1986 г.
17108
0.5
127.25
24 МАРТА
1986 г.
17108
0.5
127.25
25 МАРТА
1986 г.
17108
—
427.24
26 МАРТА
1986 г.
17108
0.5
127.25
27 МАРТА
1986 г.
17108
0.5
127.25
28 МАРТА
1986 г.
17108
0.5
127.25
29 МАРТА
1986 г.
17108
0.5
127.25
30 МАРТА
1936 г.
17108
0.5
127.25
31 МАРТА
1986 г.
17108
0.5
127.25
1 АПРЕЛЯ
1986 г.
17108
-58.0
17.05
PF: 2- ВП,
1 - НАЗД,
3 - ВЫБР. АБ-
ТА, 4- ВЕРХ, 5
- ШАПКА, 6 - Н
Рис. 16. Хронологическая таблица значений показателя
мацию по нескольким абонентам и одному показателю, то наиме¬
нование вариации показателя было бы помещено на первой стро¬
ке таблицы, а в «Шапке» справки разместились бы наименования
абонентов.
Информация по одному или двум показателям (абонентам)
может быть представлена в виде графика. Для этого показатели
должны быть помечены в командном поле под колонками. Внеш¬
ний вид графиков показан на рис. 17. Картинку с графиками
тоже можно распечатать, при этом масштаб осей будет изменен
применительно к листу бумаги.
База данных УСОИ
База данных УСОИ представляет собой набор файлов, имею¬
щих принятую в среде VM/SP организацию с прямым доступом
к записям. Несмотря на дополнительные трудозатраты при раз¬
работке УСОИ, этот метод доступа выбран для обеспечения необ¬
ходимого быстродействия системы во всех режимах работы. Два
общесистемных файла (SSYST и AMBAR) создаются автомати¬
чески при первоначальном старте УСОИ. Файл SSYST хранит
список всех загруженных в базу данных приложений и их основ¬
ные характеристики, такие, как наименования, пароли на доступ
и некоторые другие. Файл AMBAR представляет собой подроб-
174
ЦЕХ 21
25
20
15
10
5 *
850228 850531 850831 851130 860131 860331
* - ВЫПУСК ПРОДУКЦИИ,ПЛАН (Т )
• -ВЫПУСК ПРОДУКЦИИ + - К ПЛАНУ
Рис. 17. Пример графического представления динамики показателей
ный протокол ввода информации в базу данных. Каждое вход¬
ное сообщение снабжается паспортом, который содержит инфор¬
мацию о времени прихода и последней корректировке сообще¬
ния, о том, кто его прислал и кто корректировал, какие обнару¬
жены в нем ошибки и т. д. Паспортные данные являются ключе¬
вой информацией для поиска сообщений подсистемой сопровож¬
дения.
Каждое вновь создаваемое приложение порождает пару не¬
разрывно связанных друг с другом файлов SPRAV и BANK. Пер¬
вый из них содержит всю справочную информацию о задаче, ад¬
ресные ссылки для доступа к данным, журналы поступления и
логических ошибок. Второй отведен под хранилище фактических
и расчетных данных.
База данных УСОИ включает в себя еще два самостоятель¬
ных семейства файлов FORMS и PROF. Каждый файл семейства
FORMS представляет собой совокупность алгоритмов формиро¬
вания документов, объединенных в один сборник. Файлы семей¬
ства PROF состоят из алгоритмов формирования профилей ин¬
тересов конечных пользователей.
Кроме перечисленных выше файлов существует еще один, ко¬
торый описывает конфигурацию самой системы. Этот файл носит
имя USOI PROFILE и служит паспортом системы. При началь-
175
ной генерации УСОИ в нем указываются: имена виртуальных ма¬
шин массового ввода и приемник протоколов обработки входной
информации; имя ядра УСОИ; адрес базы данных и наименова¬
ние организации, эксплуатирующей систему.
Основные информационные потоки и технология работы УСОИ
Попытаемся нарисовать общую картину эксплуатации УСОИ
от ее старта до работы конечного пользователя, а также отразить
информационные связи между пользователями, подсистемами и
базой данных. На рис. 18 представлена принципиальная схема
функционирования УСОИ. Полужирными линиями на ней обозна¬
чено движение информации, модифицирующей базу данных. Тон*
кими линиями показан путь информации, наполняющей базу дан*
ных. Пунктир указывает путь информации к ее потребителям.
Файлы USOI PROFILE и FILE SSYST используются в каждом
режиме системы в служебных целях (для настройки работы), и
поэтому выборка информации из них на схеме не показана.
Для первоначального старта УСОИ системному программисту
необходимо определить виртуальные машины массового сбора ин*
формации, ядра и пользователей системы, распределить диско¬
вое пространство между ними, обеспечить доступ к программно¬
му обеспечению и т. п. После этого средствами системного ре¬
дактора текстов в файле USOI PROFILE отмечается конкретная
конфигурация УСОИ. Этим и ограничиваются обязанности си¬
стемного программиста. УСОИ готова к работе и передается в
руки группы сопровождения.
На основании заранее подготовленной информации (списка
показателей и их характеристик, набора отчетных точек и т. п.)
сопровождающий готовит с экрана дисплея описание вида дея¬
тельности, присваивает ему уникальный номер и передает на
обработку подсистеме создания приложений. Полученные резуль¬
таты отображаются в файлах SSYST, SPRAV и BANK, которые
автоматически через ядро УСОИ заносятся в базу данных. Файл
описания приложения сохраняется на диске сопровождающего
для последующей модификации. Какого-либо специального режи*
ма модификации в системе не существует, что избавляет сопро¬
вождающего от излишней нагрузки. Все изменения вносятся в
тот же файл описаний и отправляются на обработку. Подсистема
сама проверяет соответствие внутренних структур, налаживает
новые информационные связи и заботится о сохранности ранее
принятых данных.
Подготовка выходных документов и профилей интересов ко¬
нечного пользователя в основном идет по той же технологической
схеме. Основное отличие заключается в том, что сборники вы¬
ходных документов и профили интересов не обязательно должны
храниться в общей базе данных. Каждый вновь созданный или из¬
мененный документ подвергается тщательной проверке на факти-
176
I
О
ш
—1
О
>
сс
LL
X
О
ОС
zf
со
О.
о.
>•
о
со
X
■а
Z)
X
о
f—
н
со
>
со
со
ш
—1
LL
Заголовки видов |
1 деятельности J
s
о
о
>>
об
о
s
Он
12 Заказ 5620
177
ческом материале и только после этого передается в общее поль¬
зование (копируется на диск базы данных).
Входная информация со всех периферийных устройств (тер¬
минальных ЭВМ, телетайпов, дисплеев группы сопровождения и
конечных пользователей и т. д.) поступает в подсистему ввода и
контроля. Каждое сообщение снабжается паспортом и сохраня¬
ется в архивном файле AMBAR. Определив, какому виду дея¬
тельности адресовано конкретное сообщение, подсистема прово¬
дит его полную обработку. Показатели заносятся в один из фай¬
лов семейства BANK, а в журналах поступления и логических
ошибок, хранящихся в соответствующем файле SPRAV, простав¬
ляются необходимые отметки. Устройства, обладающие средства¬
ми обратной связи, получают немедленный отклик о результатах
обработки. Параллельно служба сопровождения получает подроб¬
ные протоколы ввода.
Если подсистема ввода и контроля работает автоматически и
не требует никакого вмешательства, то подсистема сопровожде¬
ния специально создана для вмешательства человека в процесс
обработки информации. Она активно работает с файлом AMBAR,
выбирая из него все ошибочные сообщения и предоставляя их
для исправления сопровождающему. Подсистема снабжает сопро¬
вождающего всеми данными, необходимыми для предъявления
претензий поставщикам информации и для разрешения возможных
конфликтов. Конечной целью сопровождения на данном этапе
является обеспечение полноты и корректности отчетной информа¬
ции. Для оперативного решения возникающих вопросов исполь¬
зуются средства межмашинной связи и телефон. При необходи¬
мости сопровождающий сам корректирует или вводит новые со¬
общения с экрана дисплея. Ввод плановых показателей также
осуществляется службой сопровождения.
Средства предоставления информации пользователям черпают
информацию о форме и правилах отображения данных из файлов
FORMS и PROF. Содержательная часть информации берется из
файлов BANK. При необходимости документы и справки перено¬
сятся на бумагу с использованием центрального и индивидуаль¬
ных печатающих устройств.
Опыт использования УСОИ
в подразделениях Миннефтепрома
УСОИ эксплуатируется в ГИВЦ Миннефтепрома (ГИВЦ
МНП) свыше 10 лет. За это время она убедительно показала свои
достоинства в эксплуатации, гибкость и надежность, высокое ка¬
чество программного обеспечения. В описанной редакции она
существует с 1984 г.
ГИВЦ МНП получает информацию более чем от 50 произ¬
водственных объединений и управлений преимущественно по або¬
178
нируемым каналам связи. Часть информации приходит по теле¬
тайпу, а при неисправности каналов собирается по телефону.
Предусмотрен прямой межмашинный обмен и прием от удален¬
ных терминалов. В последнем случае в качестве процессора пе¬
редачи данных используется ЭВМ ЕС 1011. Сеансы связи прово¬
дятся преимущественно ночью. Обработка информации проводит¬
ся на ЕС1055М.
Служба сопровождения ГИВЦ МНП состоит из 17 человек,
из них 16 имеют высшее образование. Выделена группа опера¬
тивного сопровождения информации из 6 человек, обеспечиваю¬
щая круглосуточное дежурство и выпуск суточной документации.
Сотрудники отдела самостоятельно создали и поддерживают в
актуальном состоянии более 3000 типов выходных документов
для различных служб министерства. Отдел сопровождения обес¬
печивает Министерство нефтяной промышленности СССР всей
отчетной оперативной информацией, принимая и контролируя в
среднем за сутки более 20 тысяч показателей.
Управленческому аппарату выдается в среднем за сутки более
30 типов выходных документов, не считая ответов на запросы, по¬
лучаемые в диалоговом режиме, на экран дисплея. Одновременно
с УСОИ работают 10—12 пользователей, и число их постепенно
растет.
Из подотчетных предприятий УСОИ эксплуатируется в кусто¬
вом ИВЦ Главтюменнефтегаза (КИВЦ ГТНГ). Сотрудникам
КИВЦ ГТНГ в середине 1984 г. на магнитной ленте были пере¬
даны математическое обеспечение и инструкции, никакого обу¬
чения не производилось. Разработчики были откомандированы в
Тюмень только в марте 1986 г. для смены версии УСОИ и обме¬
на опытом. К этому времени там уже функционировал и постав¬
лял в Москву информацию обширный комплекс задач, а УСОИ
была применена для решения даже более широкого круга задач,
чем у разработчиков. Служба сопровождения в КИВЦ ГТНГ
примерно вдвое больше, чем в ГИВЦ МНП, но около половины
ее персонала имеют среднетехническое образование.
Дальнейшее распространение УСОИ в отрасли сдерживается
отсутствием необходимых технических средств и местными про¬
граммными наработками.
Производительность подсистемы ввода и контроля информа¬
ции зависит от ряда факторов. В частности, она уменьшается
при увеличении количества формул контроля, особенно если для
проведения контроля недостаточно информации, содержащейся в
самом сообщении, и за ней необходимо обращаться к базе дан¬
ных. Так, например, пакет из 1000 сообщений на 18 000 показа¬
телей с проведением контроля по 3000 формулам обрабатывается
на ЕС1055М 980 с, а при отключенном логическом контроле —
350 с. Под показателем мы в данном случае понимаем одно чис¬
ло, а время — процессорное. К тому же для диалоговых систе^м
скорость обработки не является критичным фактором, поскольку
информация вводится, как правило, небольшими порциями.
12*
179
УДК 681.142.2:518.5
В. А. непомнящий, о. м. рякин
верификация программ обработки
ДАННЫХ С ИСПОЛЬЗОВАНИЕМ АВТОМАТНОЙ
МОДЕЛИ ФАЙЛОВ
Верификация свойств корректности программ путем доказа¬
тельств— одно из перспективных направлений в решении проб¬
лемы надежности программного обеспечения. В последнее время
достигнуты успехи в разработке прикладных методов верифика¬
ции программ из различных областей на базе аксиоматического
подхода [1]. Эти методы могут составить основу автоматизиро¬
ванной верификации программ в будущих системах программи¬
рования с элементами искусственного интеллекта.
Однако верификация программ в такой важной области, как
обработка данных, еще недостаточно разработана. Аксиоматика
файла Паскаля, описанная в [2], является незавершенной для
практического использования. Некоторые ее недостатки преодо¬
лены в [3].
Ряд языков высокого уровня (ПЛ/1, Ада и др.) имеют более
развитые средства оперирования с файлами, на которые непо¬
средственно непереносимы семантические правила для файлов
Паскаля. Правила вывода некоторых операторов ввода-вывода
Кобола, учитывающие свойства на уровне атрибутов файла, пред¬
ложены в [4].
В данной статье рассматривается дальнейшее развитие аксио¬
матического подхода к описанию семантики последовательного
файла на основе новой более общей модели, названной автомат¬
ной моделью файла. Показывается, что такая модель позволяет
построить аксиоматическую семантику последовательного файла
с более мощными средствами оперирования, чем классические
операторы над файлом Паскаля [2]. Файл Паскаля при этом
является частным случаем предлагаемой модели: он соответствует
автомату без памяти (с одним состоянием) .
Предлагаемая модель рассматривается применительно к под¬
множеству ПЛ/1, удовлетворяющему концепции структурного
(дисциплинирующего) программирования в свете подхода, ука¬
занного в [6], хотя описываемые принципы применимы и к дру¬
гим языкам высокого уровня, имеющим аналогичные средства
оперирования с последовательными файлами.
Для последовательного файла ПЛ/1 автоматная модель с тре¬
мя состояниями описывает достаточно представительный набор
операторов записеориентированного режима, включая оператор
обновления записей REWRITE, не имеющей аналогов в концеп¬
ции файла Паскаля.
Ниже описывается разработанная аксиоматическая семантика
указанного подмножества операторов над последовательным фай¬
180
лом ПЛ/1, которая применяется к верификации программ с фай¬
лами, развивающей подход, описанный в [3]. Метод иллюстриру¬
ется примером верификации программы чистки последовательно¬
го файла, находящей применение в автоматизированных инфор¬
мационных системах справочного типа.
Автоматная модель последовательного файла ПЛ/1. В языке
ПЛ/1 концепция последовательного файла основывается на вве¬
дении трех режимов работы: чтения (INPUT), обновления
(UPDATE) и записи (OUTPUT). Режимы разделены таким об¬
разом, что каждому из них соответствует свой допустимый на¬
бор операторов над файлом. Переход из одного режима в другой
возможен только путем закрытия файла и его последующего от¬
крытия для соответствующего режима. Это существенно отличает
последовательный файл ПЛ/1 от файла языка Паскаль, в кото¬
ром совмещены режимы чтения и записи так, что переход в ре¬
жим записи осуществляется автоматически при достижении конца
файла.
Операцию начальной установки файла в ПЛ/1 выполняет опе¬
ратор OPEN, обобщающий функции оператора reset Паскаля.
Другим существенным отличием файла ПЛ/1 является иной
механизм обнаружения конца файла оператором ON ENDFILE
вместо стандартного предиката eof в Паскале.
Рассматриваемый нами набор операторов над последователь¬
ным файлом ПЛ/1 включает операторы открытия файлов
(OPEN), закрытия файлов (CLOSE), чтения записей (READ),
обновления (REWRITE), записи (WRITE). Для этих операторов
мы в дальнейшем используем следующие сокращенные обозна¬
чения:
OPEN(F, IN)—OPEN FILE(F) UPDATE;
OPEN(F,OUT)-OPEN FILE(F) OUTPUT;
CLOSE (F) - CLOSE FILE (F);
WRITE(F)-WRITE FILE(F) FROM(X);
READ (F,X) — READ FILE(F) INTO(X);
REWRITE(F,E)-REWRITE FILE(F) FROM(E).
Файл F будем характеризовать кортежем из четырех ком¬
понентов:
FA<left(F), right(F), Ff, st(F)> (1)
где left (F) — файл левой части (от начала до текущей записи);
right (F) — файл правой части (от текущей записи до конца);
Ft — значение буферной переменной (содержимое буфера);
st (F) — состояние файла F : st (F) е {nil, rd, wr};
nil — начальное состояние, rd — состояние чтения или обновления,
wr — состояние записи (в конце файла).
Функции left(F) и right (F) дают результатом файлы, a Ff —
значение, совпадающее по типу с записью файла F.
Файлы left(F) и right(F) в совокупности определяют как со¬
держимое F, так и положение доступной записи файла F (рис. 1а).
181
left (F)
right (F)
r v A
Рис. 1. Автоматная мо¬
дель последовательного
файла ПЛ/lj а — сос¬
F ~< left (F), right (F), Ft, st (F) >.
St (F) G (nil, rd, wr }.
тавные части последо¬
вательного файла; б —
граф переходов состоя¬
ний файла
Значение Ff может быть и неопределенным в результате выпол¬
нения некоторых операторов над файлом (например, чтения по¬
следней записи в файле): Fj = co.
Введение состояния файла st(F) позволяет различать два
обобщенных рабочих режима файла: режим чтения-обновления
(rd) и режим записи (wr), устанавливаемые операторами
OPEN (F, IN) и OPEN (F, OUT) соответственно. Начальное со¬
стояние nil является состоянием хранения файла.
Граф переходов состояний для автоматной модели файла
ПЛ/1 показан на рис. 16. Отметим, что объединение режимов
INPUT и UPDATE в одно обобщенное состояние rd имеет целью
упрощение семантики файла. С этой же целью мы ограничиваем
применение операторов OPEN только к закрытым файлам (в со¬
стоянии nil). Указанные упрощения не носят принципиального
характера и при необходимости могут быть сняты соответствую¬
щим усложнением графа переходов рис. 16.
Действия операторов над последовательным файлом ПЛ/1 в
рамках введенной автоматной модели файла состоят в следующем.
Операторы OPEN (F, IN) и OPEN (F, OUT) применимы к фай¬
лу, находящемуся в состоянии nil, и производят установку файла
соответственно на первую запись или на конец файла, не изменяя
содержимое файла, но изменяя состояние на rd или wr.
182
Оператор READ (F, X) применим только к файлу в состоя¬
нии rd и не изменяет этого состояния. Оператор переписывает
содержимое буфера в переменную X, после чего перемещает го¬
ловку на следующую запись файла, делая ее текущей записью
и помещая содержимое текущей записи в буфер.
Применение оператора READ (F, X) в ситуации «конец фай¬
ла» вызывает прерывание по концу файла оператором ON
ENDFILE (F).
Оператор REWRITE (F, E) не изменяет допустимого для него
состояния файла rd. Этот оператор используется для обновления
последней прочитанной записи оператором READ (F, X). Про¬
изводимое им действие состоит в замене значения последней про¬
читанной записи файла на значение выражения F. При этом по¬
ложение головки, а следовательно, текущей записи, не изме¬
няется.
Оператор WRITE (F, X) применим лишь в состоянии wr, он
не изменяет этого состояния, а производимое им действие заклю¬
чается в добавлении в конец файла записи, содержащей значе¬
ние X. После выполнения операции головка находится в конце
файла, поддерживая, таким образом, в состоянии wr ситуацию
«конец файла».
Оператор CLOSE (F) применим в состояниях rd и wr, и его
действие состоит в переводе файла в состояние nil, при этом со¬
храняется прежнее содержимое записей файла. В состоянии nil
доступны только операторы открытия файла.
Аксиоматическая семантика операторов над последовательным
файлом. Введенная выше автоматная модель файла позволяет
получить аксиоматическую семантику указанного подмножества
операторов над последовательным файлом ПЛ/1. Для этой цели
используем модифицированную аксиоматическую систему [5],
обладающую определенными преимуществами при верификации.
Для упрощения модифицированных правил вывода и дости¬
жения их единообразия удобно операторы над файлом интерпре¬
тировать как эквивалентные им присваивания вида
F: =<p(F),
где ср — некоторая функция языка спецификации, определяемая аксиоматиче¬
ски и отражающая действие оператора над файлом F.
Например, оператору OPEN (F, IN) сопоставляется F: = in (F).
Особый случай составляет оператор READ (F, X), интерпре¬
тируемый более сложным образом из-за необходимости учета
ситуации «конец файла», распознаваемой через оператор ON
ENDFILE. В рассматриваемом нами подмножестве операторов
над файлами ПЛ/1 ограничимся использованием ON ENDFILE
следующим образом:
1. Для каждого файла F в режиме INPUT или UPDATE (т. е.
состоянии rd) должен присутствовать в программе оператор ON
ENDFILE (F) GOTO LF.
183
2. Оператор, помеченный меткой LF, должен располагаться
ниже операторов чтения файла F и не входить в циклы, содер¬
жащие операторы чтения файла F.
При этих ограничениях, предложенных в Корнелльском под¬
множестве ПЛ/1 [6], оператор READ (F, X) можно интерпрети¬
ровать как
READ(F,X)~if]eof(F)thenX : =F|; F : =read(F)else go to Lf.
Соответствующее правило вывода для READ (F, X) будет иметь
характер правила, допустимого при истинности предпосылки
onef (F, Lp), где onef (F, Lp)—предикат соблюдёния ограниче¬
ний 1 и 2 на оператор ON ENDFILE.
Построенная в соответствии с этими особенностями аксиома¬
тическая система в виде модифицированных правил вывода при¬
ведена в табл. 1.
Таблица 1
Модифицированные правила вывода
для подмножества операторов над последовательным файлом ПЛ/1
Обозначение
правила
Содержание правила
R. INOP
R. OUTOP
R. READ
R. REWRT
R. WRITE
R. CLOSE
{P}A{Q(F-«-in(F))} Н{Р}А; OPEN(F.IN) {Q};
{P}A{Q(F«-out(F))}i-{P}A; OPEN(F, OUT) {Q};
onef(F, Lf)||—({P}A{eof(F)=>Lf : INV}, {P)A{|— eof(F)=>
Q(F-<-read(F), X-<-Ff)} H {P}A; READ(F, X) (Q});
{P}A{Q(F-<-rewrt(F, X))} ь {P}A; REWRITE(F.X) {Q};
{P}A{Q (F^write(F, X))} f- {P}A; WRITE (F, X) {Q};
{P}A{Q(F-*-close(F))}i-{P}A; CLOSE(F) {Q}.
В модифицированных правилах {Р} A {Q} обозначает тройку
Хоара, в которой Р и Q — формулы логического языка специфи¬
кации (предусловие и постусловие оператора А), А — оператор
языка ПЛ/1.
Тройка Хоара представляет утверждение: если Р — истинно
перед выполнением оператора А и выполнение А завершается, то
Q — истинное после завершения А.
Q (Х-<—Е) — подстановка Е вместо всех свободных вхожде¬
ний X в Q.
Q (Х-<-Е, Y-<—С)—последовательная подстановка Е и С вме¬
сто X и Y; =>, И—логические операции импликации и отрицания.
Другие логические операции будем обозначать: Д— конъюнкция,
V — дизъюнкция, =—эквивалентность, V — квантор всеобщности.
В правиле R.READ обозначение LF: INV использовано для
инварианта точки, непосредственно следующей за меткой LF, т. е.
предусловия оператора, отмеченного меткой LF. При указанных
выше ограничениях на LF этот инвариант может быть определен
автоматически при последовательном применении правил вывода.
184
Функции in, out, read, rewrt, write, close и предикат eof, ис¬
пользованные в правилах вывода табл. 1, являются проблемно-
ориентированными понятиями языка спецификации. Их формаль¬
ное определение через базовые понятия — пустой файл 0, бу¬
фер Ff, функции left, right, con, file, st дается системой аксиом,
приведенной ниже (табл. 2).
Таблица 2
Аксиомы основных понятий языка спецификации
последовательных файлов
Обозначение
аксиомы
Содержание аксиомы
А. 0
st(0) = пПД0| = со;
F¥=0Ast(F) =nil=>st(in(F)) = rdA]eof (in (F)) Д
left (in (F)) = 0Aright (in (F)) = con (left (F), right (F));
A. IN
A. OUT
st(F) = nil=>st(out(F)) =wrAout(F) t = <oAleft(out(F)) =
= con (left (F), right (F)) Aright (out (F)) = 0;
A. READ
1 eof (F) Ast (F) = relist (read (F)) =rdAeof (read (F)) =>
read(F)f = coAleft(read(F)) =con(left(F), file (Ff)) Д
right (F) = con (file (Ff), right (read (F));
A. REWRT
st(rewrt(read(F), E)) =rdArewrt(read(F), E)f = read(F) jA
left (rewrt (read (F), E)) = con (left (F), file (E)) Д
right (rewrt (read (F), E)) = right (read (F));
A. WRITE
st(F) =wr=>st(write(F, X)) =wrAwrite(F, X) f = соД
left (write (F, X)) = con (left (F), file (X)) Aright (write (F, X)) = 0;
A. CLOSE
st(F) =rd vwr = st(F) => st (close (F)) =nilAclose(F) f =
= FfAleft (close (F)) = left (F) Aright (close (F)) = right (F);
A. LFT
eof (left (F)) A left (F) f = w Ast (left (F)) = ш1Д;
A. RGT
eof (right (F)) Aright (F) f = co Ast (right (F)) = nil;
A. FILE
eof (file(X)) Ain(file(X)) t =XAst(file(X)) =nil;
A. CON
st(Fi)=st(F2)=st(F3)=nilAeof(F1)Aeof(F2)Aeof(F3)=>
st(con(Fb F2)) = nil st(con(F2, F3) Acon(Fb 0) =con(0, F:) =
= FiAcon(con(Fb F2, F3) = con (Fi con(F2, F3))A
con(Fb F2)f =con(F2, F3)t = coAeof(con(Fb F2)Aeof(con(F2, F3))
Каждая из определяемых функций языка спецификации ха¬
рактеризуется аксиомами, задающими явно или неявно четыре
компонента результирующего файла в соответствии с (1). Пре¬
дикат eof(F) есть сокращенное обозначение для right(F)=0. Ра¬
венство файлов Fi=F2 понимается в интенсиональном смысле:
файлы равны, если равны результаты применения к ним любых
допустимых операций или предикатов языка спецификации. Ра¬
венство файлов задает некоторое отношение эквивалентности с
обычными для него свойствами рефлексивности, симметричности
и транзитивности.
Методика верификации программ обработки данных. Вери¬
фикация программы состоит в доказательстве ее корректности
непосредственно по тексту программы (без его выполнения на
ЭВМ) и формальным спецификациям, определяющим функцию,
вычисляемую программой. Свойство корректности программы
обычно принято разделять на частичную корректность и завер¬
шение.
185
Программа Prgm называется частично корректной относитель¬
но входного условия Р и выходного условия Q, если истинна трой¬
ка Хоара {Р} Prgm {Q}. Для доказательства частичной коррект¬
ности могут использоваться метод индуктивных утверждений или
его модификации, сводящие задачу к оценке истинности системы
формул на логическом языке спецификации программы.
Основные этапы верификации программы по методу индуктив¬
ных утверждений состоят в следующем:
1) спецификация программы, т. е. запись инвариантов про¬
граммы (входного, выходного условий и инвариантов циклов)
на логическом языке спецификации;
2) получение условий корректности по тексту программы и
спецификациям (по тексту аннотированной программы);
3) доказательство условий корректности на основе аксиом,
определяющих понятия, используемые в спецификации программы.
Для задач обработки файлов ПЛ/1 основу логического языка
спецификации составляют рассмотренные выше понятия аксиома¬
тической семантики последовательного файла ПЛ/1, формали¬
зующие файл ПЛ/1 как тип данных.
К числу проблемных понятий задач обработки файлов можно
отнести такие понятия, как длина файла X(<F), i-я запись файла,
множество или мультимножество записей файла [3] и другие
понятия. Аксиоматическое определение функций длины файла
X(F) и i-й записи файла имеет, например, следующий вид:
/ Х(0) =0Ak(write(F, х)) =X(F) 4-1;
I A,(F) =X(left(F))+X(right(F)); (2)
( rec(F,Z(left(read(F))))=Ff; (3)
rec(op(F), i) =rec(F, i); op ^{read, in, out, close}
( rec(upd(F, E)), %(left(upd(F, E))) =E;
I i=/=X(left(upd(F, E)))) =>rec(upd (F, E), i) =rec(F, i); (4)
где upd (F, E)Arewrt (read (F), E).
Функция rec (F, i) определена только для непустого файла при
l^i^X(F). Из аксиом для rec (F, i) можно вывести и другие
свойства функции гес, например, из (4) следует:
rec(F, i) =rec(upd(F, Е), i) Vrec(upd(F, Е), i) =Е (5)
К числу специальных понятий рассматриваемой ниже задачи
чистки файла относится понятие clean (F, i, j) —предикат, озна¬
чающий, что записи файла от 1 до (i—1) не содержат дублика¬
та j-й записи этого файла. Предикат clean может быть определен
следующей формулой:
clean (F, i, j) AVk : ((I ^k<i)Arec(F, j) #=c=>rec(F, j) #=rec(F, k)) (6)
Условия корректности — совокупность формул на логическом
языке спецификации, из истинности которых следует свойство
частичной корректности программы.
Условия корректности могут быть получены автоматически
последовательным применением к заданной аннотированной про¬
186
грамме модифицированных правил вывода для соответствующих
операторов языков программирования. Для основных управляю¬
щих структур языка ПЛ/1 система модифицированных правил
вывода имеет вид:
R.PL.NL. P=^Qh{P} NULL {Q};
R. PL. ASG. {P}A{Q((Xh .., Xk)^E)} н {P}A; Xb ..., Xk = E{Q};
R.PL.IFO. {P}A{a=>Q}H{P}A; {a—if} {Q};
R.PL.IF1. {P}A{a—if}Ai {Q}, {P}A{] a—if}A2{Q}-
{P}A; IF(a) THENAr, ELSEA2 {Q};
R.PL.WHL. {P}A{INV}> {INVA«}B{INV},INVA Ha=>Q H
{P}A{INV} DO WHILE (a); B; END {Q};
R.PL.TOBY. {P}A{INV(X^-E1)}, INV A(0<X-E2^E3) =>Q,
{INVA(Ei^X^E2)}B{INV(X^X + E3} r-
{P}A; {INV} DO X = Ei TO E2 BY E3; B; END {Q} (7)
где NULL — пустой оператор
Приведенная аксиоматическая система (7) предполагает отсут¬
ствие автоматических преобразований типов данных в выраже¬
ниях и операторах присваиваний, а также побочных эффектов в
функциях. Эти ограничения приняты в Кориелльском подмноже¬
стве ПЛ/1 и соответствуют основным идеям дисциплинирующего
программирования.
При получении условий корректности целесообразно выделить
два подэтапа: получение схем условий корректности и получение
интерпретированных условий корректности, а также их упроще¬
ние на основе эквивалентных преобразований.
Схема условий корректности — формула в расширении логи¬
ческого языка спецификации, определяющая структуру условий
корректности в зависимости от структуры программы и не зави¬
сящая от интерпретации инвариантов программы. Расширение
состоит во введении обозначений для подстановок в формулах.
Инварианты программы, а также проблемные понятия модифи¬
цированных правил вывода входят в схемы условий корректности
в виде некоторых стандартизированных имен. Схемы условий кор¬
ректности могут быть получены только по тексту программы и за¬
тем использованы для порождения конкретных условий коррект¬
ности путем интерпретации инвариантов программы на логиче¬
ском языке спецификации и выполнения правил подстановки.
Кроме того, в схемах условий корректности могут быть приме¬
нены эквивалентные преобразования, не зависимые от интерпре¬
тации понятий, с целью упрощения и, в частности, исключения
лишних условий корректности.
Таким образом, введение схем условий корректности придает
процессу генерации условий корректности необходимую гибкость.
Последний этап верификации программ сводится к доказа¬
тельству истинности полученных условий корректности путем вы¬
вода этих условий из аксиом понятий проблемной области за¬
дачи, т. е. в аксиоматической системе проблемной области.
187
Пример верификации программы обработки данных на ПЛ/1.
В качестве примера описанной выше методики рассмотрим вери¬
фикацию программы CLEAN чистки последовательного файла.
В очищенном файле должно оставаться по одному экземпляру
каждой непустой записи исходного файла. Записи-дубли заменя¬
ются в процессе чистки пустыми записями, так что общее число
записей файла, включая пустые записи, не изменяется. В при¬
кладном плане задача чистки файла характерна для информаци¬
онных систем справочного типа, особенно при наличии несколь¬
ких независимых источников ввода данных в общий файл.
Вариант программы CLEAN на языке ПЛ/1 (без описаний
данных) имеет следующий вид:
{Р} ON ENDFILE (F) GOTOL;
OPEN FILE (F) UPDATE; N = 0;
{INV1} DO WHILE (ТВ);
READ FILE(F) INTO(X);
N = N+1;
CLOSE FILE(F);
OPEN FILE(F) UPDATE;
{INV2} DO K=1 TO N;
READ FILE(F) INTO(Y);
IF(X = Y)&(I«N) THEN;
REWRITE FILE(F) FROM(C);
END;
END L ;; {Q}
1. Спецификация программы CLEAN. К основным проблем¬
ным понятиям языка спецификации файлов относятся: длина
файла — число записей файла F: Z(F), i-я запись файла F:
rec (F, i), множество непустых записей файла F: set(F), началь¬
ный отрезок файла F длиной L^X(F): beg(F, L). Специальными
понятиями языка спецификации, связанными непосредственно с
задачей чистки файла, являются: предикат очистки первых (гл—1)
записей F от j-й записи: clean (F, m, j), предикат очистки фай¬
ла F от дублей: cleano (F).
С учетом вводимых понятий инварианты программы CLEAN
имеют следующий вид:
Р: (F.x¥=0)A(F=FBX)Ast(F)=nil;
Q : cleano(F) Aset(F) = set(FBX) Ast(F) = rd;
INV1 -N=X(left(F))AQ(F^-left(F), FBX«-left(FBX));
INV2 cleano (beg (F, N—1)) Aset (beg (F, N)) = set (beg (FBX, N)) A
clean (beg (F, N), K, N)AK (= X(left (F)) +1) A
X=rec(F,N)Ast(beg(F,N)) =rd.
Аксиоматическое определение проблемных понятий Z(F) и
rec(F, i) было приведено выше в (2), (3), (4). Аксиомы понятий
set(F) и beg(F, N) имеют вид:
A. SЕТ. Eeset (F) => (ЕУ= СА Эi ((1 i%(F)) Arec (F, i) = Е);
А. В G. Л (beg (F, N)) = NA Vj ((1 j N) => rec (F, j) = rec (beg (F, N) ,j).
188
Полезными теоремами для проблемных понятий, выводимыми
из приведенных аксиом, являются:
Т. SET. Si, j (rec(F, i) =rec(F, j) ^C=>set(F) =set(F) (rec(F, i)^-C) (8)
TA. X(left(upd(F, C))) =A(left(F)) + l (9)
Определение предиката clean (jF, i, j) было дано в (6), а предикат
cleano определяется через предикат clean следующим образом:
cleano (F)AVj ((1 ^A(F)) =>clean(F, j, j)
2. Условия корректности программы CLEAN. Применяя моди¬
фицированные правила вывода табл. 1 и (7) к программе CLEAN,
получаем следующие схемы условий корректности после элемен¬
тарных упрощений:
Cl. P^INVl(F^-in(F),Nk-O);
С2. INV2A(N<K^N+1)->INV1;
СЗ. INVl->(eof(F)->Q);
С4. INVl-^Oeof(F)->INV2(K«-l, F^-in(F), F^close(F), N^-N+l,
F^-read(F), X-^Ff);
C5. INV2A(l^K^N)->(eof(F)->Q);
C6. INV2A(l^K^N)->(_ieof(F)->(X = Ff)A(K<N)->INV2(K^-K+l,
F4-rewrt(F,C),F^-read(F), Y^-Ff);
C7. INV2A(l^K^N)->(Tleof(F)->(Xy=Ft)V(K^N)->
INV2(K*-K+1, F^-read(F) Y+-Ff).
Условия корректности программы CLEAN получаются интерпре¬
тацией схем Cl—С7 с учетом приведенного выше представления
инвариантов Р, Q, INV1, INV2 и выполнения подстановок.
3. Доказательство условий корректности. В качестве примера
докажем истинность одного из наиболее сложных условий кор¬
ректности С6. Остальные условия доказываются аналогично.
Интерпретация схемы условия С6 с учетом формул для INV2 и
последующего выполнения указанных в схеме С6 подстановок при¬
водит к следующему условию корректности С6:
С6. set (beg (F, N)) =set (beg (FBX, N)) Acleano (beg (F, N—1)) A
clean (beg (F, N) K,N) Л (K = % (left (F)) +1) AX = rec (F, N) Ast (beg (F, N)) =
= rd^neof(F)=HX = Ft)A(K<N)=>st(beg(upd(F,C),N))=rdA
set(beg(upd(F, C), N=set(beg(FBX), N) Acleano (beg (upd (F, C), N—1) A
clean (beg (upd (F, C), N), K+l, N)A(K=X(left(upd(F, C)))A(X=
»=rec(upd (F, C), N)
Доказательство истинности C6 сводится к доказательству ис¬
тинности каждого из конъюнктивных членов заключения С6.
Истинность конъюнктивного члена set (beg (upd (F, С), N) =
= set(beg(FBX> N)) следует из посылок set (beg (F, N))=set(beg
(FBX, N)), X = Ff, X = rec(F, N), а также свойства, описываемого
теоремой (8), поскольку из X = Ff и X = rec(F, N) вытекает по
(3): rec(F, N)=rec(F, К).
189
Истинность cleano (beg(upd(F, С), N—1) непосредствен¬
но следует из посылки cleano (beg (F, N—1)) и свойства
cleano (F)=>clean (upd(F, С)).
Для доказательства истинности clean (beg (upd (F, C), N),
K+l, N) следует воспользоваться посылкой clean (beg (F, N),
К, N), а также учесть, что в силу определения upd (F, С) и К=
= Z(left(F)) +1 имеем rec (upd (F, С), К)=С, откуда с уче¬
том (6) получаем rec (upd (F, С), K)=/=C=>rec (upd (F, С), К) =
= rec (upd (F, С), N)^true,
Истинность K = X(left (upd (F, С)) следует из-посылки К =
= %(left (F)) + l и свойства функции X(F), определенного (9).
Истинность X = rec (upd (F, С), N) следует из посылки Х =
= гес (F, N) и K=A(left (F)) + l, а также свойства (4).
Истинность st(beg (upd (F, С), N))=rd непосредственно сле¬
дует из аксиомы A.PL.RWRT табл. 2.
ЛИТЕРАТУРА
1. Непомнящий В. А. Практические методы верификации программ//Киберне-
тика. 1984. — № 2. — С. 21—29.
2. Hoar С. A. R., Wirth N. An Axiomatic Definition of the Programming Langua¬
ge Pascal//Acta Informatica. — 1973. — V. 2.—№ 4.
3. Непомнящий В. А. Верификация программ обработки файлов на языке
Паскаль//Программирование.— 1981.—№ 2. — С. 34—43.
4. Касаткина И. В., Петрушин В. А. Дедуктивная семантика операторов обра¬
ботки файлов и ее применение для верификации Кобол-программ//Програм-
мирование. — 1982. — № 6. — С. 39—47.
5. Igaraschi S., London R. L.t Luckham D. C. Automatic Program Verification:
A Logical Basis and Its Implementation//Acta Informatica.— 1975. — V. 4.—
№ 2.
6. Conway R. A Primer on disciplined programming//Winthrop. Publ. Inc. —
1978.—420 p.
УДК 681.3
В. H. АГАФОНОВ
СИСТЕМА ПТО
ДЛЯ ПОДДЕРЖКИ СПЕЦИФИКАЦИИ ПРОГРАММ
И МАТЕМАТИЧЕСКОГО ОБЕСПЕЧЕНИЯ
ПРОГРАММИСТОВ
1. Что такое система ПТО1.
ПТО (Практическая1 2 Теория Определений)—это специализи¬
рованная информационная система, или база знаний по специ¬
фикации программ. Своеобразная предметная область, на кото¬
1 Подробное описание системы ПТО имеется в [1] и [2].
2 А также Прикладная или Программистская (читатель может предложить
и другие вариации на букву «П»).
190
рую ПТО ориентирована и которую она некоторым образом мо¬
делирует,— это «мир определений (описаний, спецификаций)» с
теми внутренними и внешними связями, которые играют сущест¬
венную роль при работе со спецификациями. Модель данных ПТО
отражает особенности этой области. Статическую часть модели
(язык описания данных) образуют типы объектов, связи между
объектами, классы объектов и семейства классов. Динамическую
часть модели (язык манипулирования данными) образуют коман¬
ды, позволяющие работать с объектами и находить нужную ин¬
формацию в ПТО. Команда вводится с терминала, и результатом
ее выполнения является ответ системы в виде текстов и рисун¬
ков на экране терминала или на бумаге.
1.1. Типы объектов. В ПТО имеются следующие типы объектов:
понятия, термины, определения, примеры, формы записи, статьи,
рисунки, библиографические задней, языки, системы, области
приложений, лица, учреждения, классы, семейства, связи. Здесь
тип — это именованное множество объектов, в описании которого
указывается, как устроены входящие в него объекты и какие
функции они могут выполнять. Типы как множества могут пере¬
секаться.
Объект может иметь компоненты, которые сами являются объ¬
ектами и на которые можно ссылаться, используя имя объекта и
имя или номер компоненты*. Описывая тип такого объекта, мы
будем говорить: «А состоит из В, С,...» вместо «Объект типа А
имеет компоненты В, С,.. .». Конкретные объекты, имеющиеся в
данный момент в базе данных системы, вместе с конкретными
связями между ними образуют текущее состояние базы данных
системы.
Д^ля перечисленных типов объектов объясним теперь, как они
устроены и каковы их содержательный смысл и роль.
Понятие состоит из имени, определения, примера и формы
записи. Содержательно понятие — это описание математического
объекта, включающее в себя его имя (название, принятое у спе¬
циалистов), определение, примеры и, возможно, формы записи
(письменного изображения, внешнего синтаксического представ¬
ления). Понятие может иметь несколько имен, примеров и форм
записи, т. е. состояниями этих компонент могут быть множества.
Имя понятия является термином.
Термин — это короткий текст. В качестве терминов выступа¬
ют принятые специалистами названия и сокращенные обозначе¬
ния понятий, языков, систем и т. д.
Определения, примеры и формы записи являются статьями.
Статья состоит из имени, редакции и произвольного числа дру¬
гих компонент, которые могут быть текстами, статьями или ри¬
сунками. Редакция состоит из даты и автора. Редакций может
быть несколько. Они сообщают, кто и когда составлял статью и
вносил в нее изменения.
1 Имя объекта является его компонентой. Каждый объект имеет также
системное имя.
19!
Содержательно определение — это текст (возможно, с рисун¬
ками), описывающий математический смысл, семантику понятия.
Форма записи — это статья, описывающая некоторое внешнее
представление («нотацию») понятия. Обычно это описание син¬
таксиса понятия. Пример — это конкретный образец, наглядный
представитель понятия, определение которого обычно описывает
некоторое множество математических объектов, каждый из кото¬
рых может служить примером. Бывают случаи, когда трудно дать
точное общее определение понятия, но легко привести примеры.
В таком случае смысл понятия может быть представлен только
примерами.
Определения, примеры и формы записи отличаются от других
статей своим статусом и ролями в системе (в связях, командах
и т. д.). Другие статьи выступают в роли рекомендаций, замеча¬
ний, утверждений, а также описаний свойств и связей, не имею¬
щих статуса определений.
Рисунок состоит из имени и фигуры («картинки»), построен¬
ной из линий и надписей (коротких текстов). Обычно рисунок
изображает помеченный ориентированный граф (диаграмму), вер¬
шины которого могут изображаться точками, кружками, прямо¬
угольниками и т. д., дуги — стрелками, а метки — короткими тек¬
стами.
Библиографическая запись представляет собой обычное биб¬
лиографическое описание статьи, книги, отчета и т. д., компонен¬
тами которого являются авторы, название (заглавие), год и ме¬
сто издания и т. д.
Язык и система состоят из имени (названия языка специфи¬
кации, проектирования и т. д. или соответственно системы под¬
держки, проектирования программ и т. д.) автора, учреждения
(где разработаны и (или) сопровождаются язык или система)
и источника (библиографической записи о публикации, содержа¬
щей описание языка или системы).
Область приложений состоит из имени (названия), пояснения
(статьи, кратко характеризующей область) и, возможно, рубрик
каких-нибудь известных классификаций (например, реферативно¬
го журнала ВИНИТИ).
Лицо и учреждение состоят из имени (фамилии с инициала¬
ми или соответственно названия) и, возможно, сведений для уста¬
новления контакта (адрес и т. п.).
Класс состоит из имени, типа (имени типа, подмножеством
которого должен быть данный класс) и описания (статьи, пояс¬
няющей принцип, по которому объекты включаются в данный
класс). С каждым классом в текущем состоянии базы данных
ассоциируется множество объектов заданного типа. Описанные
выше типы объектов, а также описываемый далее тип связи яв¬
ляются классами. Другие классы перечисляются в п. 1.2 и могут
создаваться пользователями. Объект может принадлежать раз¬
ным классам, т. е. классы могут пересекаться.
192
Семейство определяется так же, как класс, только элемента¬
ми ассоциированного с ним множества являются классы.
Связь состоит из имени связи, имен аргументов («мест») свя¬
зи с именами их типов или классов, статуса связи (автоматиче¬
ская или неавтоматическая) и описания (статьи, поясняющей
принцип, по которому объекты связываются этой связью).
В текущем состоянии базы данных со связью ассоциируется
конечное отношение. Имена связи, аргументов и типов аргумен¬
тов задают тип отношения или тип связи. Само отношение с п
аргументами (n-местное отношение) математически может быть
задано как конечное множество /г-элементных кортежей объектов,
«связываемых» этим отношением (7-й элемент кортежа представ¬
ляет f-й аргумент отношения). Однако вместо кортежа мы пред¬
почитаем говорить о связке, в которой элементы не упорядочены,
но для каждого элемента указано (с помощью имени аргумента),
какой аргумент отношения он представляет. Таким образом, со
связью ассоциируется конечное множество связок, которое назы¬
вается состоянием связи и образует часть состояния базы данных.
Для автоматической связи возможен «переход по связи» и
изменение ее состояния с помощью соответствующих команд си¬
стемы (см. п. 1.3), а для неавтоматической — нет (она содержит
мало связок, и все они перечисляются в описании связи).
1.2. Классы, семейства, связи. Классы объектов (не являю¬
щихся классами) и семейства таких классов служат в ПТО для
выражения «близости» или «родства» объектов (или классов),
которые интуитивно отчетливо осознаются и полезны на прак¬
тике. Описание класса или семейства дает мотивировку этой бли¬
зости. Роль классов и семейств аналогична роли связей («бли¬
зость» тоже своего рода связь).
В ПТО заданы три семейства классов понятий. Первое семей¬
ство содержит следующие классы концептуально однородных по¬
нятий, обладающих внутренним единством математического ха¬
рактера: 1) таблицы, 2) равенства и подстановки, 3) логические
средства, 4) графовые средства (графы, сети, диаграммы), 5) опе¬
рации и выражения, 6) процедурные средства, 7) средства моду¬
ляризации, типизации и структуризации (типы, схемы, модули,
фреймы, математические структуры), 8) средства именования.
Во втором семействе понятия сгруппированы в классы по сло¬
жившимся в программировании крупным областям: 1) средства
описания управления и взаимодействия процессов, ориентирован¬
ные на описание асинхронных, параллельных систем и систем
реального времени; 2) средства описания задач обработки дан¬
ных, ориентированные на структуру обрабатываемых данных;
3) средства описания моделей данных, используемых в базах дан¬
ных и знаний; 4) средства спецификации трансляторов1.
1 Средства, включаемые в классы этого и предыдущего семейства, доволЬ’
но подробно описаны в [2,3].
13 Заказ 5620
193
Третье семейство содержит классы средств, используемых для
описания основных классов общематематических объектов:
1) функций, 2) отношений, 3) множеств.
Кроме определений, примеров и форм записи в ПТО имеются
классы статей, объединенные в следующее семейство так назы¬
ваемых прагматических рекомендаций: 1) требования логической
и математической дисциплины, которую надо соблюдать при по¬
строении определений; 2) рекомендации, как доходчиво писать
и разъяснять описание; 3) систематизированные результаты пси¬
хологических экспериментов и эмпирические наблюдения, проли¬
вающие свет на то, как люди понимают определения, построен¬
ные теми или иными средствами, какие испытывают трудности,
какие и как часто делают ошибки1.
Администрация или пользователи ПТО могут образовать клас¬
сы и из объектов других типов, например, классы связей. В част¬
ности, имеется важный класс связей «представления», в который
входят разные виды представлений (например, представление
функций таблицами или равенствами, одних объектов другими,
одних типов данных другими и т. д.).
Группировка связей в классы имеет практический смысл, по¬
тому что связей в ПТО много, и они будут добавляться в ходе
эксплуатации системы. Каждое представляющее интерес утверж¬
дение о связях, ставшее известным администрации системы (экви¬
валентность, преобразование, представление и т. д.), рассматри¬
вается как кандидат на включение в систему. Мы перечислим
здесь только основные бинарные связи, т. е. с двумя аргумента¬
ми X и Y.
1. Понятие X используется в определении понятия Y (X опре¬
деляется непосредственно через Y).
2. Понятие X шире (не уже) понятия Y. Эта связь определяет¬
ся для понятий X и Y, задающих некоторые классы математиче¬
ских объектов К(Х) и K(Y), и означает, что K(X)^K(Y).
3. Понятие X равнообъемно понятию Y, т. е. K(X)^K(Y).
Кроме равнообъемности понятий в системе есть несколько дру¬
гих отношений эквивалентности, смысл которых явно определяет¬
ся в соответствующих описаниях связей: эквивалентность автома¬
тов, грамматик, разных способов задания функций, множеств и
т. д. Все такие связи образуют класс «эквивалентности».
4. Понятие X представляет понятие Y (X служит представле¬
нием для Y). Это значит, что в классе «представления» имеется
связь R, такая, что XRY.
5. Понятие X является вариантом (отличается второстепенны¬
ми деталями) понятия Y.
6. Класс (семейство) X включает в себя класс (семейство) Y,
т. е. X=?Y.
7. Объект X использует или может использовать объект Y
1 См. гл. 9 книги [2].
194
(например, в языке X используется понятие Y или в области при¬
ложений X может использоваться понятие Y).
8. Объект X содержит полезную информацию или может пред¬
ставлять интерес для того, кто интересуется объектом Y (X и Y
могут быть объектами любых типов).
9. Термин X встречается в статье (тексте) Y.
10. Термин X — синоним термина Y.
С помощью связей и классов в ПТО моделируется только часть
«теории определений», понимаемой как совокупность истинных
утверждений о свойствах и взаимоотношениях понятий. Некоторые
полезные утверждения такого рода представлены в ПТО в виде
класса статей «утверждения».
1.3. Команды ПТО. Команды ПТО ориентированы на некото¬
рую модель поведения человека при поиске информации, или
стратегию поиска, которая состоит примерно в следующем. На
начальном этапе поиска человек хочет получить общую ориента¬
цию в средствах системы, организации данных и прикинуть, где
приблизительно может находиться нужный материал. Наметив
одну или несколько «исходных точек» и запомнив их, человек
приступает к просмотру содержащейся в них информации. Если
он не найдет сразу нужные сведения, то либо кардинально изме¬
нит исходную точку (попал явно «не туда»), либо перейдет к
просмотру «ближайших окрестностей» (они представлены в ПТО
связками и классами, содержащими данное «место»).
Все это похоже на то, как мы просматриваем книгу в поисках
нужного материала, когда не собираемся читать ее подряд. С
помощью оглавления и указателей выбираем места (страницы),
где скорее всего встречается интересующий нас материал. Озна¬
комившись с этими местами, мы далее просматриваем ближайшие
страницы или те места, на которые даются ссылки или которые
связаны с данным по смыслу. Попутно мы делаем пометки, поз¬
воляющие вернуться в нужное место или, наоборот, не повторять
ошибок.
Кроме поддержки такой стратегии поиска ПТО обеспечивает
ведение «персональной базы данных» пользователя, позволяющей
отобрать и организовать нужные ему средства так, как он хочет.
Команды ПТО естественно разбить на следующие четыре
группы:
1) средства ориентации и начального этапа поиска;
2) команды перехода по связям и классам, просмотра и выда¬
чи объектов, запоминания промежуточных данных;
3) команды создания, включения, исключения и изменения
объектов;
4) средства ведения персональной базы данных пользователя.
К первой группе относятся команды, выполняющие следующие
функции:
1) начало работы. Дается краткая информация о системе, а
также имена и описания команд, позволяющих начать работу с
системой (см. п. 2—5);
195
2) обращение к гиду. Вызывается процедура, называемая ги¬
дом, которая, опрашивая пользователя, предлагает ему дерево
вариантов общения с системой, помогающее быстрее освоить те
части системы и ее базы данных, которые представляют для него
наибольший интерес;
3) перечень команд. Выдаются имена и краткие описания
команд;
4) справка о команде. По имени команды выдается полное ее
описание;
5) справка о типе, классе, семействе. По имени типа (класса,
семейства) выдается его описание и количество содержащихся в
нем объектов;
6) обращение к указателю. По имени указателя выдается он
сам.
Указатель представляет собой перечень его элементов, которые
являются терминами или именами объектов, классов и т. д. Кроме
перечня элементов в нем указывается количество элементов, ко¬
личество синонимов элемента (если они есть) и, возможно, неко¬
торая дополнительная информация. В ПТО имеются следующие
указатели: 1) указатель указателей; 2) указатель типов (кроме
имени типа указывается структура объектов этого типа); 3) для
каждого типа, класса и семейства указатель объектов этого типа,
класса, семейства (указатели терминов, понятий, лиц, языков,
классов и т. д.).
Просматривая указатель, пользователь может сразу сохранить
интересующий его элемент в рабочей памяти, играющей роль «за¬
писной книжки», или сделать его текущим (см. команды второй
группы).
Во вторую группу входят команды, выполняющие следующие
функции:
1) установку текущего объекта. Объект с заданным именем
становится текущим. Так задается исходное или текущее «место»
поиска;
2) использование рабочей памяти (РП). Текущий объект или
его компонента, или текст, напечатанный на экране, запоминается
в РП и может быть получен из РП на экран;
3) переход по автоматической связи. Задается имя связи и
позиция в связи, занимаемая текущим объектом, т. е. имя или
номер аргумента связи. Для бинарной связи система дает пере¬
чень имен возможных типов (классов) другого аргумента и для
каждого типа (класса) дает количество объектов этого типа
(класса), связанных данной связью с текущим объектом. Выбрав
один из типов (классов), можно сделать доступными все объекты
этого типа (класса), связанные с текущим данной связью.
Для небинарной связи система выдает всевозможные комби¬
нации типов (классов) других аргументов вместе с информацией
о количестве связок, соответствующих комбинации. Далее можно
выбрать некоторую комбинацию и сделать доступными соответ¬
ствующие объекты.
196
Когда пользователь выбирает класс, в котором собирается
проводить поиск, он может задать его не только именем класса,
но и выражением, составленным из имен классов и операций
пересечения, объединения и вычитания классов. Это замечание
относится и к следующей команде;
4) переход внутри класса (типа). Задав класс (тип), содер¬
жащий текущий объект, можно перейти к объекту, следующему
в этом классе (типе) за текущим, т. е. он становится текущим;
5) просмотр текущего объекта. Текущий объект или его ком¬
понента (тексты, рисунки) выдается на экран терминала;
6) печать текущего объекта или содержимого рабочей памяти.
Информация выдается на печатающее устройство;
7) проверка принадлежности классам (типам). Система сооб¬
щает, каким классам (типам) принадлежит текущий объект;
8) проверка принадлежности связям. Система сообщает, каким
связям принадлежит текущий объект, т. е. в каких связях суще¬
ствуют связки, содержащие текущий объект (указывается и со¬
ответствующий аргумент связи);
9) проверка связи. Проверяется, принадлежит ли данная связ¬
ка данной связи;
10) выдача системного имени. Для текущего объекта выдается
его системное имя.
Третью группу образуют команды, выполняющие следующие
функции:
1) создание объекта. Создается новый объект одного из пере¬
численных в п. 1.2. типов: вводятся все его обязательные компо¬
ненты, система присваивает ему системное имя, и он включается
в множество, которое является текущим состоянием заданного
типа. Напомним, что создаваемым объектом могут быть, в част¬
ности, класс, семейство и связь;
2) включение в класс (семейство). Текущий объект включается
в текущее состояние заданного класса (семейства);
3) включение в связь. Заданная связка включается в заданную
связь, т. е. в множество связок, которое является текущим состо¬
янием связи;
4) исключение из класса (семейства). Текущий объект исклю¬
чается из заданного класса (семейства);
5) исключение из связи. Заданная связка исключается из
заданной связи;
6) изменение объекта. В текущий объект вносятся изменения
(редактируется текст и т. д.);
7) уничтожение объекта. Текущий объект перестает существо¬
вать в базе данных (соответственно уничтожаются связки, в ко¬
торые он входит, и изменяются состояния классов, которым он
принадлежит).
Команды третьей группы могут применяться к базе данных
ПТО только администрацией системы. Другие пользователи могут
применять их только к классам, семействам и связям, создавае¬
мым самим пользователем в персональной базе данных (ПБД).
197
Для работы с ПБД используется четвертая группа команд:
1) создание, открытие, закрытие и уничтожение ПБД. Задает¬
ся имя ПБД и выполняется одно из перечисленных действий: пре¬
доставляются или аннулируются ресурсы, открывается или закры¬
вается доступ к ПБД;
2) игнорирование и переименование компонент, типов и клас¬
сов. Для каждого из типов, перечисленных в п. 1.2 (кроме клас¬
сов, семейств и связей), можно проигнорировать (объявить лиш¬
ними) компоненты, не интересующие пользователя, или тип цели¬
ком. Можно также дать новые имена типам и их компонентам,
классам и семействам, заданным в ПТО. Но эти .имена действи¬
тельны только при работе с той ПБД, в которой они введены.
Кроме этих команд, в ПБД применимы все команды первой и
второй групп. Команды третьей группы могут использоваться толь¬
ко для создания и уничтожения собственных классов, семейств
и связей (п. 1 и 7), включения в них объектов и исключения
(пункты 2—5).
2. Для чего, кем и как ПТО может использоваться.
Основное назначение ПТО — служить инструментом для созда¬
ния и использования спецификаций программ, а основная катего¬
рия пользователей — спецификаторы, т. е. разработчики специфи¬
каций. Спецификация программы — это исходное или промежуточ¬
ное (на пути к программе) описание задачи, которую должна
решать проектируемая программа1. Создание спецификаций тоже
называется спецификацией, так что спецификация — это и вид
деятельности.
Понятие спецификации относительно, в нем отражается не
только природа задачи, но и обстановка, в которой создается и
используется спецификация (это обсуждается в [2] и [3]). Отно¬
сительно и понятие задачи. Задача может быть «большой» (на¬
пример, сложная функция, транслятор, СУБД, язык или модель
предметной области) или «малой» (например, по заданному аргу¬
менту функции найти соответствующее значение или по значениям
одних переменных уравнения найти значения других переменных).
В [4] спецификацией называется описание «малой» задачи, а
«большая» общая обстановка, в которой такая задача возникает,
называется моделью предметной области. Большая задача может,
естественно, включать в себя подзадачи. С другой стороны, поня¬
тие задачи относительно в смысле «расстояния» от машины. Кро¬
ме исходной задачи и спецификации самого высокого уровня мо¬
гут быть промежуточные задачи и спецификации более низкого
уровня.
Спецификация должна быть точным описанием задачи с по¬
мощью понятий, адекватных, задач, соответствующих ее природе,
естественных для нее. Использование таких понятий делает спе¬
1 Термин «спецификация программы» (program specification) неудачен,
правильнее было бы говорить «спецификация задачи, решаемой программой».
Но этот термин уже закрепился в литературе.
198
цификацию в принципе более понятным описанием, чем прог¬
рамма, которая тоже является точным описанием задачи. В этОхМ
заключается преимущество спецификации перед программой и ее
роль в разработке и сопровождении программы1.
Работа с понятиями — главное в построении и использовании
спецификаций. Понятия, из которых строятся и состоят специфи¬
кации, а также понятия, с помощью которых они создаются, мы
называем понятийными средствами спецификации программ в
отличие от технологических средств, к которым относятся средст¬
ва хранения и обработки спецификаций.
ПТО — это способ организации понятийных средств, обеспечи¬
вающий доступ к богатству понятий, выявляющий полезные связи
между ними, формами их представления, языками,' прикладными
областями и т. д., делающий накопленный опыт работы со спе¬
цификациями общим достоянием. ПТО можно рассматривать как
базу знаний или экспертную систему в области спецификации
программ., как существенную часть «базы знаний современного
программирования» [5].
Перечислим некоторые возможные варианты или «режимы»
использования системы ПТО.
Выбор средств описания конкретной задачи или класса, типич¬
ных в какой-то ситуации задач. Последнее фактически означает
выбор средств для соответствующего языка спецификации или
модели предметной области (см. п. 3). С помощью команд ориен¬
тации и перехода по связям и классам пользователь ищет в ПТО
подходящие понятия и отбирает в свою ПБД. Они образуют по¬
нятийную основу описания задачи или класса задач.
Поиск готового языка спецификации или прототипа языка,
который удовлетворял бы пользователя. Используя связи и ука¬
затели ПТО, пользователь ищет подходящие объекты типа «языки».
Поиск подходящей системы поддержки разработки специфи¬
каций или ее прототипа. Это аналогично поиску языка, но исполь¬
зуется тип «системы».
Сравнение средств описания, выявление связей и сопоставле¬
ние точек зрения. Чтобы понимать спецификации и языки специ¬
фикации, чтобы подбирать средства, адекватные задачам, нужно
осваивать незнакомые идеи, ориентироваться в понятийных сред¬
ствах и системах понятий, используемых в спецификации, в языке
или применяемых определенным человеком или группой едино¬
мышленников, нужно уметь понимать чужую точку зрения. При
этом надо иметь в виду, что одни и те же понятия разные люди
могут называть по-разному или, наоборот, могут вкладывать раз¬
ные смыслы в один и тот же термин. Иногда это могут быть ва¬
рианты одного понятия. Надо опознавать разные, но эквивалент¬
ные понятия, описывающие один й тот же предмет, а-• также
представление понятия другими средствами или в другой синтак¬
сической форме..
Е Подробное ’ обсуждение свойств спецификации "и их роли в ’жизненном
цикле программ см. в [2] и [3]. " • "
199
Предоставляемый ПТО способ организации понятийных
средств позволяет выявлять связи между понятиями, их представ¬
ления, эквивалентность, близость или различия, синонимию и
омонимию терминов и т. д. Тем самым облегчается взаимопонима¬
ние между людьми, причастными к спецификациям. Объекты ПТО
могут служить эталонами, на которые можно ссылаться и исполь¬
зовать их для сопоставления, обсуждения, критики и т. д.
Получение рекомендаций относительно принципов и дисципли¬
ны разработки спецификаций или эффективности используемых
средств. Здесь речь идет об использовании упомянутого в п. 1.2
семейства классов статей «прагматические рекомендации».
Поиск литературных источников по спецификации программ.
Объекты типа «библиографические записи» связаны с другими
объектами ПТО, что позволяет находить литературу, относящую¬
ся % тому или иному понятию, языку, прикладной области и т. д.
Поиск контактов со знающими людьми в области спецификации
программ. Объекты типа «лица» (содержащие информацию для
установления контакта) тоже связаны с другими объектами ПТО,
что можно использовать для поиска нужных лиц.
Кроме поддержки спецификации программы более широкая
цель ПТО — служить инструментом математического обеспечения
людей), связанных с программированием. Имеется в виду обеспе¬
чение людей математическими понятиями, относящимися к специ¬
фикации программ и программированию, помощь в математиче¬
ски точном оформлении замыслов, обучение математической
дисциплине и вообще повышение математической культуры.
При этом надо учесть, что круг математических понятий, исполь¬
зуемых в спецификациях (см. [2] и [3]), гораздо шире того, что
используется в программах. Огромный опыт и культура работы
с точными понятиями, накопленные в математике, применимы в
области спецификации программ в большей мере, чем в собствен¬
но программировании.
Потенциальные пользователи ПТО — это прежде всего специ¬
фикаторы (разработчики спецификаций). В роли спецификатора
может оказаться программист, математик и специалист в любой
области, связанной с применением вычислительных машин (инже¬
нер, биолог и т. д.). Деятельность спецификатора следует рас¬
сматривать как новую профессию, которая соединяет в себе неко¬
торые черты профессий прикладного математика и программиста
(точнее, специалиста по методологии программирования), а также
лектора, писателя и прикладного психолога. Кроме выбора средств
наиболее естественного и прямого описания задач спецификатор
должен уметь вести диалог с заказчиками и разработчиками прог¬
рамм, добиваясь согласованного и однозначного понимания (и
обладать рядом других качеств, которые обсуждаются в [2]).
1 Термин образован по аналогии с «математическим обеспечением вычис¬
лительных машин и систем» (обеспечивать математикой людей не менее есте¬
ственно, чем машины и системы).
200
Спецификаторы могут выступать в роли создателей средств спе¬
цификации и языков спецификации. На них же естественно возло¬
жить математическое обеспечение программистов и лиц, связанных
со спецификациями.
Случайным или постоянным пользователем ПТО может стать
любой человек (студент, программист или другой специалист),
которому от случая к случаю или постоянно нужны знания из
области, покрываемой информационной базой ПТО. При этом
предварительных знаний в сущности не требуется. В ПТО все
определено почти что «с самого начала», с понятий множества,
кортежа, функции и т. п. (предполагаются только самые элемен¬
тарные школьные познания). Гид ПТО, указатели и переходы по
связи «X определяется через У» помогут восполнить пробелы в
знаниях.
3. Сопоставление ПТО с языками спецификации
и другими системами поддержки
Сопоставим ПТО с традиционными инструментами специфи¬
кации программ — языками спецификации и технологическими
системами для хранения, редактирования и других видов обра¬
ботки спецификаций. Грубо говоря, язык спецификации — это на¬
бор непрагматических понятийных средств спецификации с фик¬
сированным синтаксисом и семантикой. Когда хотят кратко оха¬
рактеризовать язык программирования, то перечисляют, «что в
нем есть»: такие-то типы данных, операции, операторы, процедуры,
способы именования и т. д. То же относится к языку специфика¬
ции. Конечно, язык — это не просто набор средств, а некоторая
система или структура, в которой средства связаны друг с дру¬
гом, подобраны и организованы для определенной цели. Как
способ организации понятийных средств на начальных этапах
разработки программ языки спецификации появились и стали ис¬
пользоваться под влиянием, по традиции и по инерции от языков
программирования. Но основное назначение языка программиро¬
вания— передавать идеи от человека машине, а язык специфика¬
ции должен передавать идеи от человека человеку. В области
спецификации программ очень важна функция языка как средст¬
ва обмена идеями и достижения взаимопонимания между людьми.
Для людей характерно многообразие точек зрения на один и
тот же предмет, разнообразие представлений даже по существу
одного и того же понятия. Чтобы понимать друг друга, надо ви¬
деть или уметь показать связи между разными точками зрения и
разными представлениями. Такая цель перед языками специфи¬
кации не ставится вообще. А она очень существенна, так как нас
интересует понятность и коммуникативная сторона специфика¬
ций.
Для получения естественных, адекватных задачам описаний
могут понадобиться разнообразные и разнородные средства, а
набор средств, включаемых в язык спецификации, всегда сущест¬
201
венно ограничен, даже в языках, претендующих на универсаль¬
ность (таких, как VDM [6] или CIP-L [7]), не говоря уже о спе¬
циализированных языках (см. [2] и [3]). Развитие языка специ¬
фикации (например, SDL [8] и тех же VDM и CIP-L) обычно
происходит путем расширения его средствами, в которых ощуща¬
ется нехватка при реальном использовании языка.
Система ПТО является попыткой преодолеть ограниченность
языков спецификации и более полно удовлетворить потребности
людей, создающих и использующих спецификации. Для этого в
нее включены:
гораздо больший ассортимент средств, чем в любом языке спе¬
цификации;
разные, фактически используемые специалистами названия и
формы записи (синтаксические формы) одного и того же поня¬
тия;
разные, фактически используемые семантики одной и той же
синтаксической формы (например, денотационная и операционная
семантики равенства вида f(x)=E, где Е— выражение);
разнообразные связи между понятиями и их группировка в
классы и семейства, отражающие те или иные аспекты и точки
зрения;
прагматические рекомендации и другие вспомогательные сред¬
ства.
Система ПТО принципиально отличается от известных систем
поддержки спецификации и проектирования программ, которые
основываются на фиксированном языке спецификации и позво¬
ляют хранить спецификации, написанные на этом языке, и вообще
вести базу данных проекта, редактировать спецификации, подвер¬
гать их синтаксическому контролю и, возможно, некоторым фор¬
мам семантического контроля (таковы, например, системы
PSL/PSA [9] и RSL/REVS [10]). В ПТО хранятся не сами спе¬
цификации и не документация проекта, а понятийные материалы
и инструменты для создания и использования спецификаций. Ана¬
логом ПТО в традиционной системе поддержки был бы справочник
по используемому в ней языку спецификации.
Более развитая система проектирования программ с фикси¬
рованным в ней полностью формализованным языком специфи¬
кации может включать в себя средства выполнения и тестирова¬
ния спецификаций, написанных на этом языке (интерпретатор
И т. д.) [8]. Это позволяет быстро изготавливать прототипы
(макеты) программ. ПТО дает только материал для создания
такого языка — понятия и их синтаксические формы.
Информационная база ПТО (объекты, текущие состояния ти¬
пов, семейств, классов, связей) создается главной администрацией
ПТО в виде базового файла — набора текстовых файлов, соответ¬
ствующих типам объектов (его структура и форматы описываются
в рабочих материалах по системе ПТО, выпускаемых главной
администрацией). Создаваемые фрагменты базового файла пере¬
даются администрациям локальных систем ПТО, которые реали¬
202
зуют команды ПТО в своем программно-аппаратном окружении
и вводят полученные фрагменты в базу данных локальной систе-
мы ПТО с помощью своего конвертора1.
ЛИТЕРАТУРА
1. Агафонов В. Н. Информационная система ПТО для поддержки специфика¬
ции программ и математического обеспечения программистов. — Новоси¬
бирск, 1985.— (Препринт 85—1/ГПНТБ СО АН СССР).
2. Агафонов В. Н. Спецификация программ: понятийные средства и их орга¬
низация. — Новосибирск: Наука, 1987.
3. Агафонов В. Н. Языки и средства спецификации программ (обзор)//Требо¬
вания и спецификации в разработке программ. — М.: Мир, 1984. — С. 285—
344.
4. Лавров С. С. Использование вычислительной техники, программирование и
искусственный интеллект (перспективы развития)//Микропроцессорные сред¬
ства и системы. — 1984. — № 3. — С. 3—9.
5. Ершов А. П. Опыт интегрального подхода к проблематике программного
обеспечения//Кибернетика. — 1984. — № 3. — С. 11—23.
6. Bjorner D., Jones С. В. Formal specification and software development. —
Englewood Cliffs: Prentice-Hall Jnt., 1982.
7. Бауэр Ф. Л., Брой M. и др. На пути к языку широкого спектра для под¬
держки спецификации и разработки программ//Требования и спецификации
в разработке программ. — М.: Мир, 1984. — С. 28—46.
8. Барздинь Я. М. и др. Язык спецификации SDL/PLUS и методика его ис¬
пользования.— Рига: ВЦ ЛГУ, 1986.
9. Тейчроу Д., Херши Э. PSL/PSA: автоматизированная методика структури¬
рованного документирования и анализа систем обработки информации//
Требования и спецификации в разработке программ. — М.: Мир, 1984.—
С. 7—27.
10. Белл Т. и др. Расширяемая система автоматизированной разработки требо¬
ваний к программному обеспечению//Требования и спецификации в разра¬
ботке программ. — М.: Мир, 1984.— С. 47—76.
1 Изменения и развитие системы ПТО после сдачи статьи в редакцию отра¬
жены в работе: В. Н. Агафонов «Рабочие материалы по системе ПТО, № 1—3.
Препринт Новосибирского филиала ИТМиВТ АН СССР. — М., 1987. — 35 с.
3. ТЕХНИЧЕСКИЕ СРЕДСТВА
И ТЕХНОЛОГИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ
УДК 681.322.042
Н. Л. ПРОХОРОВ
ВЫЧИСЛИТЕЛЬНЫЙ КОМПЛЕКС СМ1700.
АРХИТЕКТУРА, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
И ПРИМЕНЕНИЕ
Главным итогом более чем десятилетней работы по созданию
системы малых ЭВМ (СМ ЭВМ) является разработка семейства
мини- и микроЭВМ с широким набором технических и программ¬
ных средств, удовлетворяющих требованиям применения в боль¬
шинстве отраслей промышленности и в непромышленной сфере.
Расширение сфер применения ЭВМ, непрерывный рост требо¬
ваний к производительности, объему оперативной памяти и надеж¬
ности привели к необходимости разработки семейства новых
высокопроизводительных 32-разрядных ЭВМ. На базе первой мо¬
дели этого семейства построен вычислительный комплекс
В К СМ 1700.
Архитектура ВК СМ1700
При разработке ВК СМ1700 была поставлена цель добиться
повышения производительности за счет увеличения разрядности
представления данных, объема ОЗУ и мощности системы команд.
В целях сохранения преемственности с разработанными ранее и
серийно выпускаемыми в настоящее время 16-разрядными моде¬
лями СМ ЭВМ (типа СМ-4) в ВК СМ1700 введен режим совме¬
стимости и сохранен системный интерфейс «Общая шина». Исполь¬
зуемая в СМ1700 операционная система МОС ВП поддерживает
режим совместимости с операционной системой ОС РВ для ЭВМ
типа СМ-4, а разработанные к этим ЭВМ внешние устройства мо¬
гут быть подключены к СМ1700.
В отличие от шестнадцатиразрядных моделей СМ ЭВМ в
ВК СМ1700 используется переменный формат команды. Машин¬
ная команда состоит из кода операции, за которым следуют специ¬
фикаторы операндов. Количество операндов находится в прямой
зависимости от кода операции и может изменяться от 0 до 6. Для
наиболее часто используемых команд код операции занимает один
байт, в некоторых командах — два байта. Для спецификации опе¬
ранда используется от 1 до 10 байт. Первые один или два байта
являются собственно спецификатором, за которым может следо¬
вать до 8 байт расширения. Расширение может представлять собой
абсолютный адрес, непосредственный операнд, адресное смещение
204
и т. п. В спецификаторе операнда младшие четыре разряда отво¬
дятся для адресации одного из регистров общего назначения.
Имеются 16 32-разрядных общих регистров (R0H-R15), кото¬
рые используются как для целочисленных операндов с фиксиро¬
ванной точкой, так и для вещественных операндов с плавающей
точкой, в отличие от ЭВМ типа СМ-4, где были отдельные наборы
регистров для арифметики с фиксированной и плавающей точкой.
Использование общих регистров является предпочтительнее, по¬
скольку упрощает программирование. Четыре из этих общих реги¬
стров имеют специальное назначение: R15 — счетчик программы
(PC) содержит адрес очередного байта в последовательности
команд; R14 — указатель стека (SP) содержит адрес вершины
стека, используемого для связи с процедурами и обработки пре¬
рываний; R13 — указатель кадра (FP) указывает на адрес струк¬
туры данных в стеке, называемой кадром вызова, которая созда¬
ется аппаратными средствами при вызове процедуры; R12 — указа¬
тель аргумента (АР) указывает на адрес структуры данных, назы¬
ваемой списком аргументов, которая создается при вызове про¬
цедуры.
Младшие четыре разряда спецификатора отводятся под режим
адресации. Имеются пять режимов, полностью аналогичных со¬
ответствующим режимам в СМ-4: регистровый, косвенно-регист¬
ровый, с автоуменьшением, с автоувеличением, косвенный с авто¬
увеличением. В СМ-4 для относительного и косвенно-относитель¬
ного режима используется жестко определенное смещение длиной
в слово (16 разрядов). В СМ1700 аналогичные режимы имеют три
модификации с различной длиной смещения — байт, слово, двой¬
ное слово. Это позволяет оптимально использовать память при
различных смещениях между командой и адресуемой ею ячейкой
памяти. Косвенный режим с автоуменьшением в СМ1700 не ис¬
пользуется, но зато имеются два принципиально новых режима:
режим короткого литерала и индексный режим. Режим короткого
литерала позволяет непосредственно в спецификаторе задавать
константы размером не более 6 разрядов. В индексном режиме
содержимое выбранного регистра умножается на размер операнда
(1—байт, 2 — слово, 4 — двойное слово). Полученное произведе¬
ние складывается с базовым адресом, определяемым вторым спе¬
цификатором, который должен следовать непосредственно за спе¬
цификатором индексного режима. Такой способ обеспечивает
эффективную и удобную для программиста обработку массивов.
Команды ВК СМ1700 предназначены для обработки большого
количества типов данных. Для целых чисел основными из них
являются: байт, слово, двойное слово. Некоторые команды пред¬
назначены для обработки целых чисел длиной 64 и 128 разрядов.
Для чисел с плавающей точкой имеется пять форматов данных, с
помощью которых обеспечивается различная точность отображе¬
ния. Основные арифметические команды (сложение, вычитание,
умножение, деление) могут работать со всеми перечисленными
типами данных (кроме целых чисел длиной 64 и 128 разрядов).
205
Команды, реализующие двухоперандные операции (такие, как
сложение, умножение, логическое сложение и умножение, сложе¬
ние по модулю 2 и т. п.), как правило, имеют два типа: двух¬
адресный (как и в СМ-4) и трехадресный. При выполнении двух¬
адресных команд результат засылается по адресу второго операн¬
да. При выполнении трехадресных команд оба исходных операнда
сохраняются, а результат засылается по адресу третьего операнда.
В СМ1700 имеются также команды для работы со специаль¬
ными типами данных: битовыми полями переменной длины, сим¬
вольными и десятичными строками.
Аппаратная и микропрограммная реализация. Структурная
схема центральной части ВК СМ1700 показана на рис. 1. Она
включает центральный процессор, от одного до пяти модулей
ОЗУ, процессор плавающей запятой, контроллер диска, много¬
функциональный контроллер связи.
Центральный процессор состоит из арифметико-логического
процессора, консольно-диагностического процессора и контролле¬
ра ОЗУ. Каждый блок выполнен на печатной плате размером
411X220 мм и представляет собой функционально законченный
узел.
Консольный процессор используется как основное средство
связи между оператором и ВК СМ1700. Он выполняет действия
по управлению, задаваемые с помощью команд оператора, осуще¬
ствляет контроль параметров напряжения сети и вторичных источ¬
ников питания; применяется при диагностике и наладке машины.
Консольный терминал подключается к консольному процессору
через интерфейс С2. Одновременно через С2 реализуется подклю¬
чение модульной линии, которая может использоваться для рабо¬
ты с удаленным терминалом в центре диагностического обслужи¬
вания. Скорость работы терминалов лежит в диапазоне от 300
до 9600 бод. Через С2 к консольному процессору подключается
одно или два устройства внешней памяти на кассетной магнитной
ленте или гибком магнитном диске. Консольный процессор содер¬
жит таймер, обеспечивающий отсчет реального времени с разре¬
шающей способностью 10 мс и выдачу различных программируе¬
мых задержек и прерываний. Консольный процессор используется
для начальной загрузки диагностических программ и операцион¬
ной системы.
Арифметико-логический процессор (АЛП) представляет собой
фактически микроЭВМ со своей системой команд (точнее микро¬
команд), памятью микрокоманд (ПМК) объемом 20К 24-разряд-
ных слов и памятью данных объемом 256 32-разрядных слов.
Основные функции выполняет 32-разрядное АЛУ, реализованное
на восьми 4-разрядных микропроцессорных секциях К1804ВС-1.
Система микрокоманд имеет семь основных форматов и выпол¬
няет базовые арифметико-логические операции и функции дешиф¬
рации команд. В АЛП имеется буфер предвыборки команд дли¬
ной 4 байта, что позволяет совместить операции выборки и выпол¬
нения команды. Вертикальная микропрограммная структура,
206
х
Шина связи
tt.
С
Q-
Ш
X
г>
Е
а
о
Рис. 1. Структура центральной части СМ 1700
207
большой объем ПЛАК и гибкое микропрограммное управление
позволили собрать АЛП на одной плате.
Контроллер ОЗУ реализует управление памятью емкостью
до 5 Мбайт; поддерживает страничную организацию памяти, обес¬
печивает работу процессора без блокировки при обращении к па¬
мяти по каналу прямого доступа; выполняет трансляцию вирту¬
альных адресов (32-разрядных, поступающих от процессора, и
18-разрядных, поступающих от устройств интерфейса «общая ши¬
на») в физические 24-разрядные адреса; осуществляет работу
канала прямого доступа согласно требованиям интерфейса «общая
шина»; обеспечивает защиту от несанкционированных обращений
к ОЗУ. Управление функциями контроллера выполнено на основе
микропрограммного обеспечения контроллера. Цикл выполнения
микрокоманд контроллера — 90 нс; разрядность микрокоманд —
72 бита; объем постоянного запоминающего устройства микро¬
команд— 512 слов. Контроллер способен обращаться к РЗУ по
виртуальным и непосредственно по физическим адресам. При
обменах между ОЗУ и процессором разрядность пересылаемой
информации — 32 бита, а при обменах с устройствами интерфейса
«общая шина»—16 бит. В информации, считанной из ОЗУ, конт¬
роллер обеспечивает коррекцию одиночных и обнаружение двой¬
ных ошибок.
ЛАодуль памяти применяется в качестве накопителя наращи¬
ваемой оперативной памяти и имеет емкость 1 Мбайт. Максималь¬
ный объем оперативной памяти в СМ1700 равен 5 Мбайт, при
этом устанавливается 5 модулей ОЗУ. Цикл обращения к памяти
не превышает 450 нс. Обмен данными происходит словами по 39
разрядов, из которых 32 информационные и 7 контрольные. Конт¬
рольные разряды обеспечивают обнаружение и исправление всех
одиночных ошибок при чтении из модуля. Двойные ошибки обна¬
руживаются, но не исправляются. Схема обнаружения и коррек¬
ции ошибок является частью логики контроллера памяти.
Процессор с плавающей точкой предназначен для ускоренного
выполнения команд, обрабатывающих числа с плавающей точ¬
кой, команд умножения и деления 32-разрядных целых чисел (или
чисел с фиксированной точкой), команд преобразования целых
чисел в числа с плавающей точкой и наоборот, команд вычисле¬
ния полиномов.
Форматы обрабатываемых данных
Целые числа 32 бита
Числа с плавающей точкой (Разрядность^
= мантисса + порядок), бит:
одинарной точности 32 = 24 + 8
двойной точности 64 = 56 + 8
с расширенным порядком 64 = 53+11
учетверенной точности с расширенным по¬
рядком 128=113+15
208
Процессор плавающей точкой выполняет 90 команд. Функ¬
ционально процессор плавающей точкой является расширением
арифметико-логического процессора. Получая от последнего коман¬
ды и операнды, он выполняет их под своим микропрограммным
управлением. Формат микрокоманды — 48 разрядов.
Программы, написанные на языке Фортран, выполняются на
ВК СМ1700 с процессором плавающей точкой примерно на по¬
рядок быстрее, чем на ВК СМ1420.
Контроллер диска используется для подключения к внутренне¬
му интерфейсу СМ.1700 одного или двух накопителей на магнит¬
ных дисках типа «винчестер» СМ5504 емкостью 120 Мбайт каж¬
дый.
Контроллер обеспечивает одновременный обмен данными толь¬
ко с одним из накопителей, при этом скорость обмена состав¬
ляет 1—2 Мбайт/с. Обмен данными между контроллерами и про¬
цессором осуществляется под управлением процессора. Контрол¬
лер обеспечивает буферизацию всех записываемых или считывае¬
мых данных. Он содержит 2 буфера по 512 байт каждый.
Многофункциональный контроллер связи предназначен для уп¬
равления различными устройствами ввода-вывода через системный
интерфейс «общая шина» и поддерживает восемь асинхронных
линий, одну синхронную и один параллельный порт ввода-вывода.
Контроллер связи подключается к системному интерфейсу «общая
шина» и имеет возможность прямого доступа к ОЗУ.
Характерной особенностью описанных функциональных блоков
является то, что каждый из них обладает собственной микропро¬
граммной структурой и соответственно собственной памятью мик¬
ропрограмм. Это привело к необходимости разработки системы
программных средств для автоматизации разработки микропрог¬
раммных структур. Эти средства универсальны, обладают возмож¬
ностью настройки на конкретную структуру и обеспечивают:
ввод, редактирование и трансляцию описания микропрограмм¬
ной структуры;
ввод, редактирование и ассемблирование текстов микропрог¬
рамм для различных структур;
управление загрузкой и отладкой микропрограмм при исполь¬
зовании перезаписываемой памяти микрокоманд.
Для ассемблирования текстов микропрограмм используется
транслятор, функционально состоящий из двух основных частей:
компилятора языка высокого уровня, предназначенного для опи¬
сания микропрограммной структуры, и ассемблера, предназначен¬
ного для кодирования символьного текста собственно микропрог¬
раммы, который настраивается на микропрограммную структуру
в соответствии с результатами компиляции описания структуры,
полученными на первом этапе.
Язык высокого уровня обеспечивает выполнение следующих
основных функций: описание форматов микрокоманд (в том числе
с переменным форматом); описание полей микрокоманд произ¬
вольной длины; символьное задание имен и значений полей; зада-
14 Заказ 5620 2 09
ние значений полей по умолчанию; формирование макро- и микро¬
команд и др.
Основой элементной базы, использованной при реализации ВК
СМ1700, являются быстродействующие элементы серии К531, а
также постоянные запоминающие устройства различных типов и
элементы программируемой матричной логик'и (ПМЛ). ПМЛ
является дальнейшим развитием известного элемента К556РТ1
(программируемая логическая матрица), и отличается от него
тем, что на выходе имеется регистр и возможны обратные связи.
Элементы ПМЛ позволяют реализовать практически произвольный
автомат с памятью при весьма незначительных аппаратных за¬
тратах. Так же, как и для элемента К556РТ1, входная информация
задается в виде логических уравнений, которые вводятся в микро¬
схему путем «прожига» внутренних перемычек в исходной универ¬
сальной матрице соединений. Ручной перевод уравнений в коорди¬
наты прожигаемых перемычек при большом объеме типов ПМЛ
(в одном только процессоре используется 26 типов ПМЛ с раз¬
личными вариантами уравнений) практически невозможен. Поэто¬
му была создана автоматизированная система программирования
интегральной логики (АСПИЛ), работающая на машинах типа
СМ-4 со специальным устройством для прожига — «программа¬
тором». Кроме ПМЛ, система обеспечивает также автоматизацию
прожига ПЗУ и ПЛМ.
Особенности архитектуры СМ1700. К особенностям архитекту¬
ры ВК СМ1700 необходимо прежде всего отнести технические
решения, направленные на достижения эффективности и рацио¬
нальности построения программного обеспечения.
Наборы инструкций СМ1700 позволяют эффективно реализо¬
вать основные программные процедуры операционной системы. К
этим инструкциям следует отнести инструкции для работы с би¬
товыми полями переменной длины и с очередями. Особо следует
отметить инструкции, обеспечивающие блокировку памяти от
параллельного доступа, что позволяет удобно реализовать синхро¬
низацию работы нескольких процессоров с общей памятью.
Процессор СМ1700 обеспечивает четыре режима работы с ис¬
пользованием в каждом из них своего стека. Это позволяет реа¬
лизовать операционную систему в виде многоуровневой (слоис¬
той) структуры с аппаратной защитой от доступа менее привиле¬
гированных уровней к более привилегированным. При этом основ¬
ные функции операционной системы распределяются по различным
уровням в соответствии с режимами доступа.
Аппаратная реализация процедуры переключения аппаратного
контекста позволяет эффективно управлять процессами, которые
являются единицей планируемой работы в операционной системе.
Аппаратный контекст процесса включает значения универсальных
и внутренних регистров процессора, указатели стеков процесса,
слово состояния процессора.
Аппаратные средства управления памятью предоставляют про¬
цессам пользователей практически неограниченный объем вирту-
210
альной памяти. Виртуальное адресное пространство, определяемое
32-разрядным адресом, представляется для процессов непрерывным
пространством объемом в 232 байта. Аппаратура обеспечивает
отображение виртуального адресного пространства процессов в
физическую память, распределение физической /памяти между
процессами и контроль возможного доступа к памяти.
Наличие пятнадцати уровней программно генерируемых пре¬
рываний позволяет значительно упростить в операционной системе
взаимодействие и синхронизацию процессов и процедур.
Аппаратная реализация механизма генерации программного
прерывания второго уровня при переходе процессора в указанный
пользователем режим.
Система программной диагностики ВК СМ1700
Характерная особенность современных ЭВМ состоит в том, что
их системы диагностирования представляют собой по существу
системы самодиагностирования. Причиной этому является стрем¬
ление использовать значительные «интеллектуальные» возможно¬
сти вычислительных машин для организации самопроверки. Это
же в полной мере относится и к разработке СМ1700.
Опыт создания программных средств диагностирования настоя¬
тельно показывает, что они должны разрабатываться во взаимной
связи с созданием всего комплекса программно-аппаратных
средств ЭВМ. Только в этом случае можно добиться удовлетво¬
рительного решения указанных проблем и создать эффективную
систему программного диагностирования.
Разработка диагностического программного обеспечения
СМ1700 проводилась одновременно с разработкой технических
средств комплекса, начиная с самых ранних этапов проектирова¬
ния. Это позволило при относительно небольшом объеме допол¬
нительной аппаратуры обеспечить высокую программную диагнос-
тируемость.
Многоуровневая система программного диагностирования
(МСПД) является комплексом программных средств, предназна¬
ченных для организации программного диагностирования вычис¬
лительного комплекса СМ1700. В состав МСПД входят: диагнос¬
тический супервизор (ДС) и управляющие программы, обеспечи¬
вающие организацию процесса диагностирования СМ1700 в раз¬
личных режимах; инструментальные /средства для разработки
диагностических программ; справочно-информационное обеспече¬
ние, позволяющее пользователю получить в интерактивном режиме
справочную информацию о системе, ее отдельных компонентах и
внешних устройствах; диагностические программы для проверки
работоспособности технических средств СМ1700 и обнаружения
неисправностей.
МСПД обеспечивает выполнение следующих функций: загруз¬
ку диагностических программ с магнитных носителей различного
типа; задание, корректировку и модификацию в интерактивном
14*
211
режиме описания конфигурации проверяемого оборудования в
соответствии с составом вычислительного комплекса; управление
выполнением диагностических программ по секциям, тестам и
подтестам с однократным их повторением; зацикливание и останов
по ошибке диагностических программ; выполнение трассировки и
получение оперативной информации о процессе выполнения про¬
верки; организацию различных режимов проверки технических
средств; отладку и корректировку загрузочных модулей диагнос¬
тических программ в различных программно-аппаратных средах,
связанных с уровнями диагностических программ; выполнение
процедуры диагностирования по упрощенному диалогу.
Система программного диагностирования СМ1700 имеет иерар¬
хическую структуру, где каждый более высокий уровень системы
диагностирования требует для своего запуска и выполнения боль¬
шего аппаратного ядра. Самый низкий уровень (уровень 5) пред¬
ставлен системой микродиагностических программ, выполняемых
под управлением микродиагностического монитора. На этом уров¬
не решаются две важнейшие задачи диагностирования СМ1700.
С одной стороны, минимизируется аппаратное ядро, необходимое
для организации процесса самодиагностирования, а с другой —
достигается необходимая для ремонта аппаратуры центрального
процессора разрешающая способность с точностью до сменного
блока.
Диагностические программы уровня 4 выполняются автономно
без ДС. На этом уровне обеспечиваются только самые простые
средства загрузки и управления. Поэтому, несмотря на то, что
режим работы четвертого уровня предоставляет широкие возмож¬
ности для обнаружения неисправностей аппаратуры, диагности¬
ческие программы этого уровня используются только для получе¬
ния такой информации, которую нельзя получить при диагности¬
ровании на других уровнях. Программы уровня 4 выполняют
проверку ЭВМ, обеспечивающую возможность запуска ДС.
Диагностические программы уровня 3 выполняются под управ¬
лением ДС. Эти программы завершают проверку технических
средств комплекса и совместно с диагностическими программами
уровня 2 подготавливают работу среды системы. Возможен доступ
к периферийным устройствам на уровне регистров, что обеспе¬
чивает высокую разрешающую способность при диагностировании,
необходимую для ремонта отказавшего оборудования.
Диагностические программы уровня 2 выполняются как с ис¬
пользованием ресурсов операционной системы, так и без них, под
управлением автономно работающего ДС. Первый режим работы
предоставляет возможность выполнять процедуру диагностирова¬
ния как пользовательскую задачу, не останавливая работу маши¬
ны. Второй режим предусмотрен на случай, если возникшие
неисправности не позволяют запустить операционную систему. В
первом случае при выполнении диагностических программ исполь¬
зуются системные драйверы, а во втором — драйверы DC (диагнос¬
тические драйверы).
212
Диагностические программы уровня 2 проверяют правильность
работы периферийных устройств по приему и передаче массивов
данных с учетом различных форматов их представления, они
завершают диагностирование среды системы и совместно с прог¬
раммами уровня 1 подготавливают работу среды пользователя.
Диагностические программы уровня 1 предназначены для
проверки сложных мультипрограммных режимов работы внешних
устройств, а также правильности передачи данных с учетом раз¬
личных сетевых протоколов, которые поддерживаются в системе.
Важной характеристикой уровня 1 является возможность
выполнения диагностирования с помощью программ данного уров¬
ня наряду с другими пользовательскими задачами. Это позволяет
не останавливать работу ЭВМ на время профилактических осмот¬
ров и поиска отдельных неисправностей, не нарушающих работо¬
способности вычислительной системы в целом. Выполнение провер¬
ки уровня 1 на завершающих этапах диагностирования СМ1700
обеспечивает работоспособность технических средств среды поль¬
зователя.
Кроме указанных средств диагностирования, входящих в сос¬
тав МСПД, пользователям предоставляется возможность провер¬
ки работоспособности комплекса с помощью широкого набора
программных средств, входящих в состав операционной системы
мос вп.
Программное обеспечение ВК С Ml 700
Программное обеспечение ВК СМ1700 включает в себя: опе¬
рационные системы; программное обеспечение для организации
и управления базами данных; программные средства телеобработ¬
ки данных; программные средства машинной графики и САПР.
Операционные системы представлены многофункциональной
операционной системой, поддерживающей виртуальную память
(МОС ВП) диалоговой единой мобильной операционной системой
(ДЕМОС-32).
МОС вп является базовой операционной системой, обеспечи¬
вает эффективную систему управления памятью, основанную иа
концепции страничного распределения виртуальной и физической
памяти между процессами. Процессы являются планируемыми еди¬
ницами работы в системе, для них распределяются вычислительные
ресурсы. Планирование осуществляется на основе 32 уровней при¬
оритетов, которые разделяются между обычными процессами и
процессами реального времени. Система обеспечивает выполнение
процессов в интерактивном и пакетном режимах, а также в режи¬
ме реального времени.
Распределение ресурсов системы и комплекса базируется на
значениях лимитов, квот и привилегий процессов, которые выпол¬
няются в различных режимах: ядра, управления, супервизора и
пользователя. Ввод-вывод поддерживается на уровне физических
устройств и на логическом уровне.
213
Система управления данными (СУД-32) реализует верхний,
или логический, уровень ввода-вывода, на котором выполняются
операции, не зависимые от конкретного внешнего устройства. За¬
прос на непосредственное выполнение операции ввода-вывода на
устройстве осуществляется через процедуру системного обслужи¬
вания (QIO).
СУД-32 может быть использована при работе с любыми устрой¬
ствами, включая терминалы и устройства печати, однако в первую
очередь она предназначена для реализации программного интер¬
фейса с устройствами с файловой структурой, такими, как маг¬
нитные диски и ленты. При этом СУД-32 поддерживает последо¬
вательную, относительную и индексно-последовательную организа¬
цию файлов, различные формы записей и способы доступа к за¬
писям в файлах.
Процедура QIO реализует нижний, доступный пользователю,
физический уровень ввода-вывода. Она может быть вызвана
программой пользователя явно или неявно из системы управления
данными. Обработка системой запроса QIO заканчивается вызо¬
вом драйвера устройства, т. е. программы, непосредственно выпол¬
няющей операцию ввода-вывода на устройстве.
МОС ВП позволяет использовать различные методы информа¬
ционной связи между процессами: на основе разделяемой области
данных и разделяемых файлов и с использованием механизма
«почтового ящика» (виртуального устройства), с которым процес¬
сы могут обмениваться данными (читать и писать). Связь между
оператором и системой поддерживается с помощью диалогового
командного языка. Кроме того, пользователю предоставляются
средства для включения дополнительных команд оператора и
создания собственных интерпретаторов командных языков.
МОС ВП поддерживает многопользовательскую защиту дан¬
ных на уровне файлов, групп файлов и томов, предоставляет
пользователю различные инструментальные средства: набор биб¬
лиотек стандартных процедур и функций, средства подготовки
текстовых файлов, отладочные средства, программы форматиро¬
вания текстовых документов, программу сортировки записей
файлов и др. Широкий набор системных обслуживающих программ
позволяет эффективно выполнять вспомогательные функции в
системе.
В целях сохранения преемственности ранее разработанного
программного обеспечения МОС ВП обеспечивает информацион¬
ную и программную совместимость с самой распространенной
операционной системой 16-разрядной линии СМ ЭВМ — ОСРВ,
что позволяет использовать разработанное в ОСРВ прикладное
программное обеспечение на комплексе СМ1700.
В режиме совместимости с операционной системой ОСРВ сис¬
тема МОС ВП предоставляет следующие возможности: выполне¬
ние непривилегированных задач, подготовленных в ОСРВ; под¬
держку томов с файловой структурой ОСРВ; выполнение непри¬
вилегированных команд программы связи с оператором ОСРВ.
214
Интерфейс пользователя с операционной системой в режиме
совместимости осуществляется посредством эмуляции среды
ОСРВ (эмуляция является не полной, например, не допускается
выполнение привилегированных задач, а также задач, использую¬
щих директивы управления памятью или непосредственно обра^
щающихся к внешней странице памяти).
Помимо программных средств эмуляции среды ОСРВ опера¬
ционная система МОС ВП включает программные компоненты
ОСРВ, обеспечивающие разработку пользовательских программ,
работающих в режиме совместимости: текстовый редактор, прог¬
рамму работы с файлами, транслятор с языка макроассемблер,
построитель и др.
МОС ВП поддерживает следующие системы программирова¬
ния: макроассемблер, Фортран, Кобол, Паскаль, СИ, Блисс-32,
Бейсик, ПЛ/1, Модула, Корал, Диамс.
Операционная система ДЕМОС-32 разработана в рамках про¬
екта по созданию Единой операционной среды (ЕОС) ДЕМОС ЕС
ЭВМ и СМ ЭВМ. Основной задачей проекта ЕОС является обес¬
печение единого интерфейса пользователя и программиста для
ЭВМ различных архитектур. При этом ставится условие обеспе¬
чения совместимости указанного интерфейса с интерфейсом широ¬
ко распространенной за рубежом операционной системы UNIX.
По своему назначению операционная система ДЕМОС является
системой разделения времени с возможностью выполнения пакет¬
ных заданий. Средства обеспечения режима реального времени в
основной состав системы не входят.
Система ДЕМОС имеет следующие основные особенности, об¬
щие для всех реализаций:
иерархическую древовидную схему управления процессами, в
которой каждый процесс имеет свое адресное пространство, кото¬
рое может быть использовано любым доступным образом (отсут¬
ствуют зарезервированные области для системных данных в виде
таблиц, буферов) ;
отсутствие встроенного интерпретатора команд пользователя
(практически любая программа может быть интерпретатором
команд, причем для каждого пользователя своя);
иерархическую древовидную файловую систему неограничен¬
ной глубины;
унифицированное представление файлов и периферийных
устройств, что позволяет использовать одни и те же программы
для обычных файлов в файловой системе и для периферийных
файлов (устройств);
отсутствие ограничений на представление данных в файлах
(отсутствуют блоки записи, при этом любой файл рассматривает¬
ся как пронумерованная последовательность байтов, что обеспе¬
чивает эффективную работу с файлами);
согласованное представление входных и выходных данных для
программ, что позволяет создавать «поточные линии» по обработке
данных без использования промежуточных временных файлов;
215
полный комплект программных средств для создания и обра¬
ботки текстов, таблиц с большими и маленькими русскими и ла¬
тинскими буквами;
наличие специальных средств описания терминалов, позволя¬
ющее ликвидировать зависимость программных средств (экран¬
ных редакторов и т. д.) от конкретных возможностей оборудова¬
ния.
По функциональным характеристикам ДЕМОС-32 является
расширением системы ДЕМОС, разработанной для ЭВМ СМ-4,
СМ1420, СМ1600, СМ1300.01, что обусловлено в первую очередь
архитектурой СМ 1700 и набором ее внешних устройств. К отли¬
чительным особенностям системы ДЕМОС следует отнести:
механизм страничного управления виртуальной памятью, что
позволяет увеличить количество активных процессов в системе и
уменьшить объем подкачки процессов;
32-разрядная архитектура позволила снять ряд ограничений
на размер ядра системы, что в свою очередь позволило улучшить
функциональные характеристики, снизить затраты на работу
самой системы, расширить функции ядра;
расширение адресного пространства позволило улучшить каче¬
ственные и количественные характеристики программных компо¬
нентов системы (например, максимальный размер обрабатываемых
файлов, программ и т. д.);
новая организация файлов системы (при сохранении ее логи¬
ческой структуры) на внешних носителях позволила на порядок
поднять пропускную способность файловой системы, что является
немаловажным фактором при обработке больших массивов дан¬
ных, существенно поднять надежность хранения информации на
внешних носителях.
Текущая версия ДЕМОС-32 предназначена в основном для
создания инструментальных систем по разработке больших прог¬
раммных проектов. На ее основе могут быть созданы информаци¬
онные, обучающие системы, системы подготовки высококачествен¬
ной документации, системы распределенной обработки информации.
В последующих версиях системы ДЕМОС-32 планируется рас¬
ширить поддержку внешних устройств, новых моделей 32-разряд-
ных СМ ЭВМ. Будет достигнута совместимость с фактическим
мировым стандартом UNIX SYSTEMV. В состав системы будут
включены: реляционная СУБД, графические средства на базе
ГКС, поддержка сетей, новые системы программирования ЛИСП
и ПРОЛОГ.
Программное обеспечение для организации и управления ба¬
зами данных включает многофункциональную информационную
систему (МИС СМ) и комплексную автоматизированную реляци¬
онную систему (КАРС).
МИС СМ — программное обеспечение для централизованного
управления базами данных, интерактивной и пакетной обработки
данных на ЭВМ СМ1700 под управлением операционной системы
МОС ВП. Пользовательские данные хранятся в виде либо файлов
216
операционной системы МОС ВП, либо базы данных сетевой
структуры, управляемой системой Сеть-32. Доступ к данным воз¬
можен либо из программ на языках программирования (Макро,
Кобол, Бейсик, Фортран, Паскаль, ПЛ/1, Си и др.), либо через
интерактивную систему запросов.
МИС СМ состоит из четырех программных компонентов, ко¬
торые могут использоваться отдельно или совместно: система
управления словарями (Словарь-32); система управления базами
данных (Сеть-32); система управления формулярами (СУФ-32);
интерактивная система запросов (Фобрин-32).
Система Словарь-32 предназначена для организации и ведения
централизованного словаря данных. Все описания данных (мета¬
данные) компонентов МИС СМ, а также описания файлов хранят¬
ся в словаре данных. В словаре хранятся следующие типы мета¬
данных:
описания структуры файлов. Описание записи может быть ско¬
пировано в программу на любом из языков программирования
(Кобол, Бейсик, Фортран, Паскаль, ПЛ/1, Си) с целью обработки
одних и тех же файлов программами на нескольких языках;
описания записей, доменов, таблиц и процедур системы Фоб-
рин-32;
описания схем, подсхем, схем управления доступом и схем хра¬
нения СУБД Сеть-32.
Словарь организован в виде иерархической структуры катало¬
гов и объектов. Объекты находятся на самом нижнем уровне
иерархии и содержат метаданные.
Авторизация метаданных осуществляется с помощью таблиц
управления доступом. Обслуживающие программы словаря вы¬
полняют необходимые функции по поддержке целостности мета¬
данных (защита и восстановление, проверка структуры, сбор ста¬
тистической информации об изменении объектов).
СУБД Сеть-32 полностью реализует предложения комитета
КОДАСИЛ по базам данных. Языки описания данных (ЯОД)
Сеть-32 позволяют эффективно реализовать сложные логические
взаимосвязи данных пользователей, обеспечивают высокую реак¬
тивность прикладных программ, совместный доступ многих поль¬
зователей к базам данных, высокую степень защиты данных от
разрушения и неавторизованного доступа.
Сеть-32 поддерживает одновременную работу 60 пользователей
на одной ЭВМ с различными базами данных. Целостность данных
обеспечивается средствами полного и частичного копирования баз
данных, ведения журналов изменений и механизма захватов.
Прикладные программы могут обращаться к базам данных при
программировании на любом включающем языке, причем язык
Кобол включает операторы языка манипулирования данными
(ЯМД) Сеть-32, а для Фотрана имеется прекомпилятор ЯМД.
Для остальных языков (Макро, Паскаль, Си, Бейсик, ПЛ/1)
доступ к БД осуществляется через CALL-интерфейс. Для отладки
программ, а также интерактивного взаимодействия с базами дан¬
217
ных в состав Сеть-32 входит интерактивная подсистема запросов
DBQ. Особенностью DBQ является возможность автоматического
отображения структуры используемой подсхемы на видеотермина¬
ле в виде диаграмм Бахмана. Доступ к базам данных Сеть-32
возможен и через интерактивную систему запросов Фобрин-32.
СУФ-32 представляет собой набор программных средств для
создания, хранения и использования в прикладных программах
экранных формуляров (видеоформ), имеющих вид, максимально
приближенный к виду документов (анкеты, бланки и т. п.). Видео¬
форма состоит из постоянной информации (заголовки, рамки
и т. д.) и полей для ввода-отображения данных.
СУФ-32 позволяет задавать контроль данных, вводимых поль¬
зователем с терминала в поле, видеоатрибуты полей (реверс,
яркость, мерцание), использовать символы двойной высоты и
ширины, наложение видеоформ друг на друга.
Видеоформы СУФ-32 могут быть использованы в программах
на всех языках программирования, а также при работе с данными
через интерактивную систему запросов Фобрин-32.
Фобрин-32 -г интерактивный процесс запросов, позволяющий
формировать запросы к данным на специальном языке высокого
уровня, ориентированном как на программистов, так и на непрог¬
раммистов. Универсальность Фобрин-32 заключается прежде всего
в том, что он позволяет обрабатывать данные, хранящиеся как в
базах данных СУБД Сеть-32, так и в файлах СУД последователь¬
ной, относительной и индексной организации, используя при этом
унифицированный язык запросов.
Описания данных для Фобрин-32 могут быть написаны либо
на собственном ЯОД системы, либо на ЯОД системы Словарь-32
(SLVL). Эти описания, а также процедуры для обработки данных
хранятся в централизованном словаре, обслуживаемом системой
Словарь-32.
Фобрин-32 имеет в своем составе генератор отчетов, позволя¬
ющий формировать сложные форматированные отчеты. Для на¬
чинающих пользователей предусмотрены специальный режим со¬
провождения и средство генерации описаний, которые с помощью
подсказок и меню позволяют быстро освоить ЯОД и ЯМД Фоб¬
рин-32.
При обработке данных (модификация, поиск) могут использо¬
ваться экранные формы, подготовленные с помощью системы
СУФ-32. CALL-интерфейс Фобрин-32 позволяет разрабатывать
прикладные программы на языках (Фортран, Кобол, Бейсик, Пас¬
каль и Др.), расширяющих возможности Фобрин-32 по обработке
данных.
МПС СМ функционирует на ЭВМ СМ1700 с объемом оператив¬
ной памяти не менее 2 Мбайт (если не используется СУБД
Сеть-32, то 1 Мбайт). Программная часть системы занимает около
8 Мбайт на системном диске (на период генерации Сеть-32 тре¬
буется дополнительно 6 Мбайт на системном диске).
218
Комплексная автоматизированная реляционная система
(КАРС) обеспечивает хранение и выборку алфавитно-цифровой
информации для обработки в различных областях применения.
КАРС поддерживает реляционную структуру данных: представ¬
ление в виде отношений (таблиц), состоящих из строк и столбцов.
В системе реализован язык SQL (структурированный язык запро¬
сов) , который является наиболее мощным из языков, используе¬
мых в реляционных СУБД. Помимо ядра системы, интерпретиру¬
ющего команды SQL, КАРС включает: системный интерактивный
интерфейс (СИН), позволяющий выполнять команды SQL в ин¬
терактивном режиме и управлять форматированием выходной ин¬
формации; систему интерактивных приложений (СИП), обеспечи¬
вающую обработку данных через экранные формы; ориентирован¬
ную на конечного пользователя; генератор отчетов, выполняющий
форматирование и вывод информации из базы данных с включе¬
нием вспомогательного текста; программы, обслуживающие за¬
грузку, реорганизацию и восстановление базы данных; интерфейсы
с языками программирования высокого уровня.
КАРС обеспечивает мультидоступ к данным с защитой данных
от одновременного обновления, от неавторизованного доступа. Все
изменения данных заносятся в файл изменений, что обеспечивает
восстановления базы данных после аппаратных сбоев.
Физическая структура базы данных обеспечивает эффективное
хранение данных и вместе с тем возможность быстрого поиска.
Для этого используются индексирование и кластеризация таблиц.
База данных КАРС может размещаться в нескольких файлах,
что позволяет более гибко использовать физическое пространство
внешних запоминающих устройств.
Простота взаимодействия с системой КАРС, наличие компо¬
нентов, ориентированных на конечного пользователя, позволяют
существенно сократить сроки освоения системы и ускорить созда¬
ние на ее основе информационных систем.
В состав программных средств телеобработки СМ1700 в на¬
стоящее время входят:
система программного обеспечения распределенных сетей
(ТРАЛ);
система программного обеспечения локальных сетей
(МАГИСТР);
система программного обеспечения для организации распреде¬
ленных многомашинных комплексов на базе СМ1700 и ЕС ЭВМ
(ЭМУЛЯТОР);
система программного обеспечения для сетей СМ ЭВМ с ма¬
лыми ресурсами (СЕТЬ МИНИ);
однородная операционная среда ОС ДЕМОС для сети ЭВМ
различных типов (ДЕМОН);
система программного обеспечения локальных сетей кольцевого
типа (КОЛОС).
Система программного обеспечения (СПО) ТРАЛ является
219
базовым сетевым программным обеспечением для создания мно¬
гомашинных систем и сетей ЭВМ на базе СМ1700.
СПО ТРАЛ позволяет создавать однородные распределенные
сети ЭВМ СМ1700 любой топологии и размерностью до 1024 узлов.
Использование пакета программ для создания однородных сетей
СМ ЭВМ (ПП СЕТЬ СМ) обеспечивает включение ЭВМ типа
СМ1420 (СМ-4, СМ1300, СМ1600 и программно совместимых с
ними) в качестве узлов в создаваемую распределенную сеть. СПО
ТРАЛ работает под управлением операционной системы МОС ВП.
В создаваемой на основе СПО ТРАЛ вычислительной сети
реализуются следующие основные функции:
взаимодействие пользовательских программ, выполняемых в
различных узлах сети;
транспортировка сообщений от программы-источника к прог¬
рамме-адресату в сети с количеством узлов до 1023;
доступ из программ и с терминалов к файлам в удаленных
узлах;
обмен файлами между различными узлами сети;
запуск удаленных программ в режиме диалога и дистанцион¬
ная пакетная обработка;
обмен сообщениями между терминалами различных узлов сети;
адаптивное управление потоками данных и функционированием
сети в целом;
использование терминалов, подсоединенных к различным узлам,
как сетевых, т. е. допускающих логическую связь с другими узлами;
отображение информации о функционировании любого элемен¬
та сети;
тестирование сетевого оборудования и программного обеспе¬
чения.
Связь между узлами обеспечивается асинхронным и синхрон¬
ным телекоммуникационным оборудованием из номенклатуры СМ
ЭВМ.
Благодаря протоколу управления информационным каналом
достигается безошибочность передачи информации между узлами
сети, оптимизация процесса передачи, проверка каналов связи,
сбор статистики и т. д.
СПО МАГИСТР является базовым сетевым программным обес¬
печением для создания на базе ЭВМ СМ1700 локальных сетей
магистрального типа с множественным доступом, с обнаружением
несущей и наложений.
Телекоммуникационное оборудование, используемое для соз¬
дания локальной сети (контроллеры локальной сети магистраль¬
ного типа, коаксиальные кабели с устройствами преобразования
сигналов), позволяет осуществлять передачу со скоростью
до 10 Мбит/с.
Информационно и функционально СПО МАГИСТР совместима
с СПО ТРАЛ и допускает их объединение. Новым фактором, рас¬
ширяющим возможности системы, является использование быст¬
родействующей магистрали для организации информационной
220
связи и создания локальной сети. Высокая скорость передачи
обеспечивает качественно новый уровень взаимодействия ЭВМ.
СПО ЭМУЛЯТОР предназначена для организации распреде¬
ленных многомашинных комплексов на базе ЕС ЭВМ и СМ1700.
При этом операционная система МОС ВП расширяется программ¬
ными средствами, обеспечивающими обмен информацией между
СМ1700 и ЕС ЭВМ.
Путем эмуляции терминальной системы ЕС7920 в СПО ЭМУ¬
ЛЯТОР реализуются следующие основные функции:
функционирование СМ1700 в качестве удаленных абонентских
пунктов ЕС ЭВМ;
обмен данными между программами, функционирующими в
СМ и ЕС ЭВМ.
СПО СЕТЬ МИНИ предназначена для организации сетевого
взаимодействия разнотипных СМ ЭВМ, функционирующих под
управлением различных ОС. Комплекс программ, составляющих
СПО СЕТЬ МИНИ, функционирует на СМ1700 под управлением
МОС ВП, на СМ1420 (СМ-4, СМ1300) под управлением ОСРВ и
РАФОС, на СМ1800—ОС1800, на СМ1810 и ЕС1840—МДОС.
Система программного обеспечения СЕТЬ МИНИ для орга¬
низации взаимодействия ЭВМ использует терминальные линии
связи и обеспечивает:
эмуляцию терминала удаленной ЭВМ, т. е. установление логи¬
ческой связи терминалов одной ЭВМ с другими узлами сети;
передачу символьных и двоичных файлов между узлами сети
по командам оператора.
СПО СЕТЬ МИНИ обладает следующими достоинствами:
надежностью (достоверностью передачи информации);
возможностью объединения в сеть различных типов ЭВМ с
различными ОС и с соответствующим преобразованием формата
символьной информации;
простотой аппаратной стыковки различных ЭВМ, вследствие
чего СПО является дешевым и технически простым способом орга¬
низации сетевого взаимодействия;
возможностью передавать 8-битные данные через 7-битные ка¬
налы связи;
передачей последовательности повторяющихся символов в
сокращенной (уплотненной) форме.
Однородная операционная среда ДЕМОН предназначена для
использования в качестве базовой сетевой среды при создании
сетей СМ ЭВМ (СМ1700 и СМ1420), работающих под управлением
ОС ДЕМОС. В этой операционной среде обеспечивается реализа¬
ция таких функций, как пересылка файлов между узлами сети и
терминальный доступ к удаленным узлам, т. е. организация логи¬
ческой связи терминала с удаленной сетевой СМ ЭВМ.
СПО КОЛОС предназначена для использования в качестве
базового сетевого программного обеспечения при создании локаль¬
ных сетей кольцевого типа из разнотипных СМ ЭВМ и оконечного
оборудования (терминалы, печатающие устройства). ЭВМ и око¬
221
нечное оборудование включаются через станции локальной сети
кольцевого типа (СЛК-СМ) в кольцевую локальную сеть. Объеди¬
няемые в сеть СМ ЭВМ могут иметь различное прикладное и
функциональное назначение, а также работать под управлением
различных ОС. При этом обеспечивается реализация следующих
основных функций:
межмашинное взаимодействие до 125 ЭВМ со скоростью пере¬
дачи по кольцу 500 000 бит/с, а между СЛК-СМ и присоединенным
оборудованием — до 19 200 бит/с;
пересылка файлов между узлами локальной сети по командам
оператора;
терминальный доступ к удаленным узлам, т. е. организация
логической связи терминала одной СМ ЭВМ с другой сетевой
СМ ЭВМ;
сетевой терминальный доступ, т. е. организация логической свя¬
зи сетевой СМ ЭВМ с терминалом, подключенным непосредствен¬
но к СЛК-СМ.
Базовое программное обеспечение автоматизированных рабо¬
чих мест на базе СМ1700 (БПО АРМ СМ1700) предназначено для
использования на графических комплексах на базе ЭВМ СМ1700.
БПО АРМ СМ1700 предназначено для широкого применения
в системах автоматизированного проектирования (САПР) и долж¬
но обеспечивать работу пользователей в режиме реального вре¬
мени, разделения времени, в пакетном режиме. БПО АРМ СМ1700
включает базовые средства машинной графики, средства поддерж¬
ки проблемно-ориентированных графических пакетов, один из
графических проблемно-ориентированных пакетов и драйверы
графических устройств, входящих в состав комплекса АРМ СМ 1700.
БПО АРМ СМ1700 ориентировано на работу в операционной
среде МОС ВП и включает следующие функциональные компо¬
ненты: драйверы графических устройств, программные средства
машинной графики на основе ГКС и пакеты программ машинной
графики.
БПО АРМ СМ1700 обеспечивает возможность включения ши¬
рокого класса проблемно-ориентированных пакетов прикладных
программ, включающих пакеты и программные средства, предназ¬
наченные для проектирования изделий радиоэлектроники, маши¬
ностроения, БИС и др.
Базовые программные средства машинной графики (БПС МГ)
на основе графической корневой системы (ГКС) предназначены
для поддержки средств графического ввода-вывода, функциониру¬
ющих в составе комплекса СМ1700.
Область применения БПС МГ обусловлена необходимостью
представления входной и выходной информации, используемой в
проблемно-ориентированных задачах, в графической форме.
БПС МГ могут использоваться как вспомогательные (инстру¬
ментальные) средства для разработки прикладных программ в та¬
ких системах, как:
222
системы автоматического проектирования в электронике, ма¬
шиностроении, строительстве и др;
системы автоматизации научных исследований;
автоматизированные системы управления технологическими и
производственными процессами;
системы отображения информации в медицине, метрологии,
геофизике, картографии и т. д.
БПС МГ допускает возможность подключения силами пользо¬
вателя программных модулей, обеспечивающих функционирование
различных графических устройств.
Отличительной особенностью БПО АРМ СМ1700 будет его
проблемная ориентация путем включения в состав БПО одного из
проблемно-ориентированных пакетов программ, предназначенных
для сквозного автоматизированного проектирования.
В настоящее время ведется разработка следующих проблемно-
ориентированных пакетов программ:
автоматизированного проектирования БИС, который предназ¬
начен для использования в- проблемно-ориентированных комплек¬
сах АРМ СМ1700 для автоматизированного проектирования и
моделирования БИС, со средствами диалога и получения твердых
копий результатов проектирования заказных и полузаказных БИС;
автоматизированного проектирования изделий машиностроения,
включающих диалоговую графическую систему, трехмерную гра¬
фику, системы вычерчивания чертежей, разработку и выдачу
управляющих программ для станков с ЧПУ;
автоматизированного проектирования сложных поверхностей,
включающих программы проектирования изделий для авиа-, авто-
и судостроения с выдачей результатов проектирования на станки
с ЧПУ;
автоматизированного архитектурно-строительного проектиро¬
вания (в двух- и трехмерном изображении) архитектурных и
строительных конструкций, зданий, сооружений и др.;
прочностных расчетов методами конечных элементов, включаю¬
щих программы прочностных расчетов в интерактивном режиме с
графическим отображением конструкций;
автоматизированного проектирования печатных плат, включаю¬
щих программы автоматизированного проектирования (размеще¬
ние компонентов, трассировку соединений и контроль) сложных,
многослойных печатных плат для широкого класса пользователей.
ВК СМ1700 благодаря своим архитектурным особенностям и
широкому набору внешних устройств и программного обеспечения
ориентирован прежде всего на применение в системах автомати¬
зации проектирования, на верхних уровнях систем управления
технологическими процессами и системах управления научным
экспериментом.
Примером обобщенной структуры .Применения ВК СМ1700
является двухуровневый комплекс для САПР, приведенный
на рис. 2. Через контроллер локальной сети (КЛС) к этому комп¬
лексу могут подключаться однопультовые АРМы нижнего уровня.
223
Планшет
Ф.АО, А1
Рис. 2. Двухуровневый комплекс для САПР СМ 1700
Вместе с этим через КЛС обеспечивается возможность включе¬
ния данного комплекса в комплексную систему управления слож¬
ным объектом.
ВК СМ.1700 является первой моделью семейства высокопроиз¬
водительных 32-разрядных мини-ЭВМ. Дальнейшее развитие се¬
мейства должно происходить в сторону увеличения производитель¬
ности или уменьшения стоимости и габаритов при сохранении всех
архитектурных возможностей. При реализации младших моделей
в целях существенного удешевления и минимизации аппаратуры
может быть допущена программная эмуляция ряда архитектур¬
ных свойств.
Конкретные реализации процессоров семейства могут отличать¬
224
ся структурным исполнением таких аппаратных средств, как бу¬
фер предвыборки, память микрокоманд, процессор плавающей
точкой, кэш-память, адаптер интерфейса «общая шина» и др.,
что в конечном итоге влияет на производительность и стоимость
вычислительной системы. Должен быть широко использован
принцип динамического микропрограммирования, который позво¬
ляет реализовать возможности ориентации архитектуры как на
универсальные задачи (например, языковые процессоры), так и
на конкретные задачи пользователя, что увеличивает общую
производительность вычислительных комплексов в несколько раз.
При условии использования новейшей технологии и методов
автоматизации проектирования заказных СБИС должна появиться
возможность добиться существенного увеличения производитель¬
ности при одновременном снижении стоимости и уменьшении га¬
баритов.
15 Заказ 5620
РЕФЕРАТЫ СТАТЕЙ
УДК 002.5:681.5
Создание машиночитаемых информационных ресурсов — одно из условий
интенсификации научно-технического прогресса! А. П. Веревченко//Прикладная
информатика. — М.: Финансы и статистика, 1988. — Вып. 14. — С. 5—15.
Рассматриваются тенденции переноса информационных ресурсов на маши¬
ночитаемые носители и основные требования к концепции формирования наци¬
ональных информационных ресурсов на машиночитаемых носителях.
УДК 681.3.06.002
Инструментарии машинной поддержки цикла жизни программного обеспе¬
чения (обзор западных средств)/ И. А. Мельников, А. С. Раабе, Б. Г. Тамм//При-
кладная информатика.—М.: Финансы и статистика, 1988. — Вып. 14. — С. 16—41.
Даны обзор и анализ современного состояния и классификация средств
машинной поддержки цикла жизни программного обеспечения, описанных в
научной литературе. Приводятся характеристики, функции и структуры инстру¬
ментов, позволяющих выполнять основные работы машинной поддержки; рас¬
сматривается их комплексное применение в рамках окружения и сред под¬
держки.
УДК 512.8.001.57:57.087
Техника битовых представлений и обработка изображений/ И. А. Равкин,
В. Л. Темов//Прикладная информатика. — М.: Финансы и статистика, 1988.—
Вып. 14. —С. 41—90.
Описывается подход к обработке черно-белых и полутоновых изображений,
основанный на их представлении в виде двумерных и трехмерных битовых
массивов и базисном наборе операций над этими массивами. Операции введены
в состав языка ИНФ-78, реализованного в рамках системы МАСОН для ЕС
ЭВМ.
На этом базисе построен следующий уровень, включающий операции преи¬
мущественно топологического характера: расширение, сжатие, утолщение, утонь-
шение, которые определены для черно-белых и полутоновых изображений. На
базе этих уровней построен расширяемый язык Картран.
УДК 681.3.06
Системы манипулирования данными на персональных ЭВМ/ Г. В. Сенин//
Прикладная информатика. — М.: Финансы и статистика, 1988. — Вып. 14.—
С. 91—118.
Обзор посвящен одной из новых областей развития программного обес¬
печения—'Системам манипулирования данными на персональных ЭВМ, или
«персональным базам данных» (ПБД). Наряду с программами, близкими к
традиционным СУБД, рассматриваются и некоторые новые классы программ
(электронные таблицы, «процессоры перечней», интегрированные системы). При¬
водится классификация ПБД по различным аспектам (функциональные возмож¬
ности, степень «интегрированности», уровень и тип пользовательского интер¬
фейса), выделяются некоторые тенденции развития ПБД.
УДК 681.3.06
Системное программное обеспечение ЕС ЭВМ/ О. Ю. Еремин, Н. С. Мак¬
симов, В. В. Наумов, Г. В. Пеледов//Прикладная информатика. — М.: Финансы
и статистика, 1988. — Вып. 14. — С. 118—129.
_226
Рассматривается текущее состояние системного программного обеспечения
ЕС ЭВМ, включающего основные операционные системы и прикладные прог¬
раммы, расширяющие их возможности. Особое внимание уделяется основной
операционной системе ОС 7 ЕС и системам обработки данных. Приводится
описание основных целей проектирования, способов достижения поставленных
целей, новых функциональных возможностей.
УДК 681.3
Мифологическая модель в системе автоматизированного проектирования баз
данных: концепции и реализация/ О. М. Вейнеров, В. М. Савинков, Н. В. Жадан,
М. С. Казаров//Прикладная информатика.—М.: Финансы и статистика, 1988.—
Вып. 14. — С. 129—152.
Рассматривается инфологическая модель, поддерживаемая системой авто¬
матизированного проектирования «Омега».
Приводятся спецификации языка инфологического описания предметных
областей и примеры его использования при проектировании БД.
УДК 519.688
Унифицированная система приема, обработки и выдачи информации (УСОИ)/
М. Н. Мельников, Г. В. Пономарев, В. А. Зеленин, Э. П. Щедрин//Прикладная
информатика.—М.: Финансы и статистика, 1988. — Вып. 14. — С. 152—179.
Описывается интегрированная программная система, обеспечивающая пол¬
ный цикл обработки отчетной информации. Рассматриваются вопросы создания
информационных структур, генерации описаний выходных документов, сбора
информации от удаленных источников, ее обработки и представления потреби¬
телю. Система предназначена для информационного обслуживания аппарата
управления объединений, главков, министерств. Статья рассчитана на работни¬
ков аппарата управления и специалистов, занимающихся автоматизацией обра¬
ботки информации.
УДК 681.142.2:518.5
Верификация программ обработки данных с использованием автоматной
модели файлов/ В. А. Непомнящий, О. М. Рякин//Прикладная информатика. —
М.: Финансы и статистика, 1988. — Вып. 14. — С. 180—190.
Описывается практическая методика верификации программ обработки фай¬
лов на подмножестве ПЛ/1, основанная на новой модели последовательного
файла и разработанной на ее базе аксиоматической семантике подмножества
операторов записеориентированного режима работы с последовательными фай¬
лами ПЛ/1.
Методика имеет приложения к верификации программ автоматизированного
управления и иллюстрируется примером верификации программы чистки после¬
довательного файла.
УДК 681.3
Система ПТО для поддержки спецификации программ и математического-
обеспечения программистов/ В. Н. Агафонов//Прикладная информатика. — М.:
Финансы и статистика, 1988. — Вып. 14. — С. 190—203.
Описывается новый инструмент проектирования и сопровождения программ—
информационная система (база знаний) ПТО, предназначенная для поддержки
спецификации программ и математического обеспечения программистов. Обсуж¬
дается назначение системы, и она сопоставляется как способ организации поня¬
тийных средств спецификации программ с языками спецификации и традици¬
онными системами поддержки.
15:
227
УДК 681.322.042
Вычислительный комплекс СМ1700. Архитектура, программное обеспечение
и применение/ Н. Л. Прохоров//Прикладная информатика. — М.: Финансы и ста¬
тистика, 1988. — Вып. 14.— С. 204—225.
Приводятся сведения о первой модели семейства новых высокопроизводи¬
тельных 32-разрядных ЭВМ в вычислительном комплексе, построенном на ее
базе. Описаны архитектура ВК СМ1700, аппаратная и микропрограммная реали¬
зация, структурная схема, назначение каждого модуля, форматы обрабатывае¬
мых данных. Дается представление о системе диагностики ВК СМ1700, описаны
операционные системы, СУБД, языки программирования, программные средства,
поддерживающие сетевые структуры СМ ЭВМ, базовое ПО, обеспечивающее
возможность подключения средств машинной графики.
НАШИ АВТОРЫ.
Агафонов Валерий Николаевич, к. ф.-м. н., в. н. с., Новосибирский филиал
Института точной механики вычислительной техники СО АН СССР (г. Новоси¬
бирск)
Вейнеров Олег Маркович, к. т. н., ВНИПИАСУгазпром (г. Москва)
Веревченко Александр Петрович, к. т. н., ст. н. с., Московский технологический
институт пищевой промышленности (г. Москва)
Еремин Олег Юрьевич, к. т. н. (г. Москва)
Жадан Наталья Викторовна, инженер, ВНПО «Союзгазавтоматика» (г. Мо¬
сква)
Зеленин Владимир Анатольевич, инженер, ГИВЦ Миннефтепрома СССР
(г. Москва)
Назаров Малхаз Суренович, к. т. н. (г. Москва)
Максимов Николай Сергеевич, к. т. н., ст. н. с., (г. Москва)
Мельников Имре Аргурович, к. т. н., Институт кибернетики АН ЭССР
(г. Таллин)
Мельников Михаил Николаевич, инженер, СПНУ «Информоргавтоматика»
(г. Москва)
Наумов Вячеслав Владимирович, к. т. н. (г. Москва)
Пеледов Геннадий Васильевич, к. т. н. (г. Москва)
Пономарев Геннадий Владимирович, инженер, ГИВЦ Миннефтепрома СССР
(г. Москва)
Прохоров Николай Леонидович, к. т. н., ст. н. с., Институт электронных управ¬
ляющих машин ИНЭУМ (г. Москва)
Раабе Алар Свен, инженер, Институт кибернетики АН СССР (г. Таллин)
Равкин Илья Анатольевич, к. т. н., 1-й Ленинградский медицинский институт
им. И. П. Павлова (г. Ленинград)
Сенин Григорий Васильевич, к. ф.-м. н., ВЦ АН СССР (г. Москва)
Тамм Борис Георгиевич, д. т. н., проф., Таллинский политехнический институт
(г. Таллин)
Темов Владимир Львович, к. ф.-м. н., ЛНПО «Электронмаш» (г. Ленинград)
Щедрин Эжен Петрович, инженер, ГИВЦ Миннефтепрома СССР (г. Москва)
СОДЕРЖАНИЕ
Предисловие ... 3
1. СИСТЕМА ИНФОРМАТИКИ
Веревченко А. П. Создание машиночитаемых информационных ресур¬
сов — одно из условий интенсификации научно-технического прогресса . 5
2. ПРОГРАММНЫЕ СРЕДСТВА И МАТЕМАТИЧЕСКИЕ ОСНОВЫ
ИНФОРМАТИКИ
Мельников И. А., Раабе А. С., Тамм Б. Г. Инструментарии машинной
поддержки цикла жизни программного обеспечения (обзор западных
средств) г:... 16
Равкин И. А., Темов В. Л. Техника битовых представлений и обра¬
ботка изображений * ; 41
Сенин Г. В. Системы манипулирования данными на персональных ЭВМ 91
Еремин О. Ю., Максимов Н. С., Наумов В. В., Пеледов Г. В. Сис¬
темное программное обеспечение ЕС ЭВМ 118
Вейнеров О. М., Савинков В. М., Жадан Н. В., Казаров М. С. Инфо-
логическая модель в системе автоматизированного проектирования баз
данных: концепции и реализация 129
Мельников М. Н., Пономарев Г. В., Зеленин В, А., Щедрин Э. П.
Унифицированная система приема, обработки и выдачи информации (УСОИ) 152
Непомнящий В, А., Рякин О. М. Верификация программ обработки
данных с использованием автоматной модели файлов ........ 180
Агафонов В. Н. Система ПТО для поддержки спецификации программ
и математического обеспечения программистов 190
3. ТЕХНИЧЕСКИЕ СРЕДСТВА И ТЕХНОЛОГИЧЕСКИЕ ОСНОВЫ
ИНФОРМАТИКИ
Прохоров Н. Л. Вычислительный комплекс СМ 1700. Архитектура,
программное обеспечение и применение 204
Научное издание
ПРИКЛАДНАЯ ИНФОРМАТИКА
Сборник статей
Под редакцией В. М. Савинкова
Выпуск 14
Зав. редакцией И. Г. Дмитриева
Редакторы Л. Д. Григорьева, Л. В. Речицкая
Мл. редактор А. А. Емельянова
Худож. редактор С. Л. Витте
Техн, редактор Е. Д. Кузнецова
Корректоры Т. М. Колпакова, М. А. Синяговская
ИБ № 2134
Сдано в набор 17.08.87. Подписано в печать 7.01.88. АН 108. Формат 60Х90*/1б- Бум. тип.
№ 2. Гарнитура «Литературная». Печать высокая. Усл. п. л. 14,5. Усл. кр.-отт. 14,5. Уч.-изд.
л. 15,97. Тираж 10 000 экз. Заказ 5620. Цена 1 р. 30 к.
Издательство «Финансы и статистика», 101000, Москва, ул. Чернышевского, 7,
Областная типография управления издательств, полиграфии и книжной торговли Иванов¬
ского облисполкома, 153628, г. Иваново, ул. Типографская, 6.
ВНИМАНИЮ ЧИТАТЕЛЕЙ!
Международный научно-исследовательский ин¬
ститут проблем управления и научно-производст¬
венное объединение «Центрпрограммсистем» на¬
чинают с 1988 г. выпуск приложения к междуна¬
родному журналу «Проблемы теории и практики
управления».
Приложение «Программные продукты и систе¬
мы» (индекс по каталогу «Союзпечати» 70754) рас¬
пространяется по подписке, а также поступает в
розничную продажу. Подписка — с любого квар¬
тала года. Стоимость одного номера — 2 рубля.
Периодичность выпуска — 4 раза в год. Приложе¬
ние рассчитано на широкий круг читателей и осве¬
щает практические вопросы использования прог¬
рамм в самых различных областях деятельности.
ИФ<Й!ж<£«“;