Текст
                    Издательско-торговая корпорация «Дашков и К0»
К. В. Балдин, В. Б. Уткин
ИНФОРМАЦИОННЫЕ
СИСТЕМЫ В ЭКОНОМИКЕ
Учебник
Пятое издание
Рекомендовано УМО по образованию
в области прикладной информатики
в качестве учебника для студентов высших учебных
заведений, обучающихся по специальности 351400
“Прикладная информатика (по областям)” и другим
междисциплинарным специальностям
Москва, 2008

УДК 334 ББК 65.29 Б20 Рецензенты: Кафедра проектирования вычислительных комплексов “МАТИ” — РГТУ им. К. Э. Циолковского (завкафедрой д. ф.-м. н., профессор В. А. Зотов); В. И. Бусов — д. э. н., профессор. Б20 Балдин К. В, Уткин В. Б. Информационные системы в экономике: Учебник. — 5-е изд. — М.: Издательско-торго- вая корпорация «Дашков и К0», 2008. — 395 с. ISBN 978-5-91131-658-7 Учебник содержит систематизированное изложение теоретических основ современных информационных технологий в области экономики. Ма- териалы учебника подготовлены авторами на основе текстов лекций, про- читанных ими в течение ряда лет студентам различных форм обучения по дисциплинам: “Проектирование информационных систем”, “Базы данных”, “Имитационное моделирование экономических систем”, “Интеллектуаль- ные информационные системы”, “Информационные технологии” и “Ин- формационная безопасность”. В учебнике основное внимание уделено методологическим основам применения средств автоматизации профессиональной деятельности, тео- рии и практике моделирования экономических информационных систем, а также основам построения и использования систем искусственного интел- лекта. Для студентов высших учебных заведений РФ, обучающихся по спе- циальности “Прикладная информатика в экономике”, а также аспирантов, молодых преподавателей и научных сотрудников, занимающихся решени- ем перечисленных проблем. Книга написана по материалам открытой отечественной и зарубеж- ной печати. ISBN 978-5-91131-658-7 © К. В. Балдин, В. Б. Уткин, 2007
СОДЕРЖАНИЕ СПИСОК СОКРАЩЕНИЙ..................................7 ВВЕДЕНИЕ...........................................9 1. МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ И ПРИМЕНЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ.....................................12 1.1. Автоматизированные экономические информационные системы и их элементы..........................12 1.1.1. Основные понятия и определения.......12 1.1.2. Классификация автоматизированных информационных систем........................15 1.1.3. Место информационных и расчетных задач в составе программного обеспечения ЭВМ.......25 1.1.4. Классификация информационных и расчетных задач ...........................33 1.2. Основы проектирования элементов программного обеспечения информационных систем..............36 1.2.1. Основные требования к информационным, расчетным задачам и их комплексам............36 1.2.2. Принципы разработки информационных, расчетных задач и их комплексов..............41 1.2.3. Содержание работ на этапах создания информационных, расчетных задач и их комплексов...............................47 1.2.4. Порядок внедрения информационных, расчетных задач и их комплексов...............52 1.2.5. Порядок использования информационных, расчетных задач и их комплексов в практике работы органа управления......................56 1.3. Информационное обследование профессиональной деятельности................................. 57 3
1.3.1. Объекты автоматизации в системе организаций..58 1.3.2. Характеристика подходов к автоматизации управленческой деятельности.....................63 1.3.3. Порядок проведения информационного обследования управленческой деятельности........67 1.3.4. Информационные модели объектов автоматизации ... 70 1.4. Оперативная постановка задачи......................73 1.4.1; Оперативная постановка математической модели.74 1.4.2. Особенности оперативных постановок информационных, вычислительных задач и их комплексов................................81 1.4.3. Оперативное описание информационных и расчетных задач..............................84 1.5. Информационная безопасность экономических систем...85 1.5.1. Сравнительный анализ стандартов информационной безопасности....................86 1.5.2. Исследование причин нарушений безопасности.105 1.5.3. Способы и средства защиты информации.......110 1.5.4. Формальные модели безопасности.............117 1.5.5. Шифрование — специфический способ защиты информации.............................122 1.5.6. Защита информации от компьютерных вирусов..131 1.6. CASE-технологии проектирования автоматизированных информационных систем.............................147 1.6.1. Жизненный цикл программного обеспечения информационной системы..........................150 1.6.2. RAD-технологии прототипного создания приложений.............................154 1.6.3. Структурный метод разработки программного обеспечения...................................159 1.6.4. Методологии проектирования программного обеспечения.................176 2. БАЗЫ ДАННЫХ..........................................197 2.1. Принципы построения и этапы проектирования базы данных.......................................197 2.1.1. Основные понятия и определения............ 197 2.1.2. Описательная модель предметной области.....205 2.1.3. Концептуальные модели данных...............215 4
2.1.4. Реляционная модель данных..............226 2.1.5. Операции реляционной алгебры...........230 2.2. Нормализация файлов базы данных..............239 2.2.1. Полная декомпозиция файла..............239 2.2.2. Проблема дублирования информации.......241 2.2.3. Проблема присоединенных записей........244 2.2.4. Функциональная зависимость полей файла.247 2.2.5. Нормальные формы файла.................250 3. ТЕХНОЛОГИЯ МОДЕЛИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ...............................254 3.1. Методы моделирования систем..................254 3.1.1. Математическая модель системы..........256 3.1.2. Классификация математических моделей...258 3.2. Имитационные модели экономических информационных систем............................264 3.2.1. Методологические основы применения метода имитационного моделирования..............264 3.2.2. Классификация имитационных моделей.....271 3.2.3. Структура типовой имитационной модели с календарем событий..........................281 3.3. Технология моделирования случайных факторов..287 3.3.1. Генерация псевдослучайных чисел........287 3.3.2. Моделирование случайных событий........296 3.3.3. Моделирование случайных величин........302 3.3.4. Моделирование случайных векторов.......311 3.4. Основы организации имитационного моделирования.318 3.4.1. Этапы имитационного моделирования......318 3.4.2. Языки моделирования.................. 325 4. ОСНОВЫ ПОСТРОЕНИЯ И ИСПОЛЬЗОВАНИЯ ИНТЕЛЛЕКТУАЛЬНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ...............................330 4.1. Методологические основы теории искусственного интеллекта.......................................330 4.1.1. Краткая историческая справка...........330 4.1.2. Основные понятия и определения теории интеллектуальных информационных систем........333 4.1.3. Классификация интеллектуальных информационных систем.........................339 4.2. Методы представления знаний..................345 5
4.2.1. Знания и их свойства......................345 4.2.2. Классификация методов представления знаний.350 4.3. Этапы проектирования экспертных систем.........360 4.3.1. Структура и назначение экспертных систем...360 4.3.2. Классификация, этапы и средства разработки экспертных систем.............................. 367 4.4. Основы построения и использования механизмов логического вывода...................................373 4.4.1. Механизм логического вывода в продукционных системах..........................374 4.4.2. Понятие о механизме логического вывода в сетевых системах................................378 4.4.3. Понятие о механизме логического вывода во фреймовых системах............................380 4.4.4. Механизм логического вывода в диагностических системах байесовского типа.......................384 ЛИТЕРАТУРА.............................................390
СПИСОК СОКРАЩЕНИИ АИВС — автоматизированные информационно- вычислительные системы АИС — автоматизированная информационная система АИСС — автоматизированная информационно-справочная система АСО — автоматизированная система обучения АСУ — автоматизированная система управления БД — база данных БЗН — база знаний БНД — банк данных БТМ — банки типовых моделей дев — дискретные случайные величины ДСЧ — датчик случайных чисел ИИ — искусственный интеллект ИРЗ и К — информационные, расчетные задачи и их комплексы ИРС — информационно-расчетная система ММ — математическая модель мпо — математическое и программное обучение нсв — непрерывная случайная величина нсд — несанкционированный доступ опо — общее программное обеспечение оппо — общее прикладное программное обеспечение ОС — операционная система оспо — общее системное программное обеспечение поис — проблемно-ориентированные имитационные системы ппп — пакеты прикладных программ печ — псевдослучайные числа РБД — релякционная база данных РПС — разрушающие программные средства 7
САПР — системы автоматизации, проектирования СВ — случайная величина СВТ — средства вычислительной техники сппо — специальное прикладное программное обеспечение СПО — специальное программное обеспечение СППР — система поддержки принятия решения сспо — специальное системное программное обеспечение СУБД — система управления базами данных тз — техническое задание тп — техническое проектирование тсв — телевизионная система видеоконтроля УЗ — уязвимость защиты УМ — управляющий модуль эвт — электронно-вычислительная техника эис — экономическая информационная система эс — экспертная система яим — язык имитационного моделирования яон — язык общего назначения
ВВЕДЕНИЕ Современный этап развития человеческой цивилизации характеризуется переходом к так называемому информаци- онному обществу, в котором в результате процессов инфор- матизации и компьютеризации информационные технологии во всех сферах деятельности играют более важную роль, нежели индустриальные, аграрные и др. Как отмечал акаде- мик А. П. Ершов, информатизация — всеобщий неизбежный период развития цивилизации, период освоения информаци- онной картины мира, осознания единства законов функцио- нирования информации в природе и обществе, практическо- го их применения, создания индустрии производства и обра- ботки информации. В связи с этим решение проблем рационального исполь- зования современных и перспективных методов и средств об- работки информации в практической (профессиональной) де- ятельности людей приобретает первостепенное значение. Это обусловлено рядом причин. Во-первых, таковы актуальные потребности общества, связанные с необходимостью реше- ния все более усложняющихся политических, экономичес- ких, военных и других проблем различного масштаба (гло- бальных, региональных, государственных, национальных и т. п.). Во-вторых, это единственный путь значительного (а в ряде случаев — кардинального) повышения эффективности профессиональной деятельности человека. В-третьих, широ- кое распространение получили технические и программные средства, позволяющие реализовать новые технологии при приемлемом расходовании ресурсов. Наконец, пользователя- ми этих технологий становится все большее число людей (по 9
некоторым оценкам, к пользователям компьютерных техно- логий во многих странах может быть отнесено все трудоспо- собное население). Естественно, что такой сложный и многообразный про- цесс, как информатизация, нуждается в методологическом обосновании, являющемся результатом исследований в рам- ках научно-технического направления и науки, получивших название “информатика”. В широком смысле под информатикой понимается науч- но-техническое направление, охватывающее все аспекты раз- работки, проектирования, создания и функционирования си- стем обработки информации на базе ЭВМ, их применения и воздействия на различные области социальной практики. Под информатикой в узком смысле понимается научная дисциплина, изучающая цели, способы и средства автомати- зации человеческой деятельности на базе современных средств ЭВТ и связи при решении практических задач, связанных с накоплением, передачей, обработкой и представлением ин- формации. Предметом изучения информатики являются информаци- онные технологии, которые реализуются на практике в авто- матизированных информационных системах (АИС) различно- го назначения, выступающих в качестве объекта информати- ки. Таким образом, АИС позволяют автоматизировать ту или иную сферу профессиональной деятельности людей за счет использования компьютерных средств и технологий. Иными словами, в качестве основных средств (инструмента) автома- тизации профессиональной деятельности людей сегодня выс- тупают средства электронно-вычислительной техники и связи. В учебнике рассматриваются вопросы автоматизации та- ких важных видов профессиональной деятельности экономи- ста, как управленческая и научно-исследовательская. Возмож- ность и необходимость применения именно в этих областях совершенных технических и программных средств, реализу- ющих современные и перспективные математические мето- ды, в том числе с использованием достижений теории искус- ственного интеллекта, позволяет в ряде случаев говорить об 10
интеллектуализации профессиональной деятельности как важ- нейшем этапе ее автоматизации. Содержание учебника составляют четыре главы. В пер- вой главе изложены методологические основы создания и применения современных компьютерных систем и техноло- гий в экономической практике: основные определения, клас- сификация АИС, требования к специальному программному обеспечению и принципы его разработки, методика проведе- ния информационного обследования объекта автоматизации, основы информационной безопасности экономических систем, современные технологии разработки АИС (в частности, CASE- технологии). Вторая глава посвящена вопросам автоматизации инфор- мационного обеспечения деятельности должностных лиц и со- держит методические основы проектирования и использования баз (банков) данных и современных компьютерных сетей, а так- же организации процессов обработки данных в базе данных. В третьей главе изложены вопросы, связанные с теори- ей и практикой моделирования сложных экономических сис- тем. Особое внимание уделено имитационным моделям эко- номических информационных систем и методам учета раз- личных случайных факторов при исследовании эффективно- сти экономических операций. Четвертая глава посвящена методическим основам пост- роения и использования в деятельности Специалистов систем искусственного интеллекта, прежде всего экспертных сис- тем с различными методами представления знаний. Подробно рассмотрены механизмы логического вывода в продукцион- ных экспертных системах и диагностических экспертных си- стемах байесовского типа. Авторы исключительно признательны своим многолетним коллегам по научной и педагогической деятельности В. Ю. Мди- нарадзе и А. Н. Сазановичу, с которыми на различных этапах обсуждались материалы учебника, и своему учителю — вице- президенту, главному ученому секретарю Международной инженерной академии, доктору технических наук, профес- сору А. И. Яковлеву. 11
1. МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ И ПРИМЕНЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ 1.1. Автоматизированные экономические информационные системы и их элементы 1.1.1. Основные понятия и определения Будучи достаточно сложным процессом, автоматизация любой деятельности человека при решении практических за- дач должна иметь научное — прежде всего методологичес- кое — обеспечение. Как уже было отмечено во введении, наукой, изучающей наиболее общие закономерности внедре- ния средств автоматизации (компьютеризации) во все сферы жизни общества и последствия этого, является информатика. В рамках этой научной дисциплины автоматизация профес- сиональной деятельности определяется как процесс создания, внедрения и использования технических, программных средств и математических методов, освобождающих человека от не- посредственного участия в получении, преобразовании и пе- редаче энергии, материалов и (или) информации в професси- ональной деятельности. Основные виды автоматизируемой профессиональной деятельности: производственные процес- сы, проектирование, обучение, научные исследования, уп- равление. Основу автоматизации профессиональной деятель- ности в современных условиях составляют средства элект- ронно-вычислительной техники (ЭВТ) и связи. 12
Весьма важными и особенно интересными для широкого круга специалистов в области организационного управления представляются особенности автоматизации управленческой деятельности как процесса создания, внедрения и использо- вания технических, программных средств и математических методов, предназначенных для автоматизированного сбора, хранения, поиска, переработки и передачи информации, ис- пользуемой при управлении эргатическими системами, в ходе реализации новых информационных технологий управления. Целью автоматизации управленческой деятельности являет- ся повышение эффективности управления (качества управ- ленческих решений, оперативности, производительности уп- равленческого труда и т. д.). Информатика является одной из отраслей общей (теоре- тической) информатики и изучает цели, способы и средства автоматизации деятельности должностных лиц на базе ЭВТ при управлении персоналом, разработке новых систем ору- жия, совершенствовании видов, форм и способов боевых дей- ствий, обучении личного состава. Как и всякая другая научная дисциплина, информатика имеет свой объект и предмет. В качестве объекта информатики выступает автомати- зированная информационная система, представляющая собой совокупность технических программных средств и организа- ционных мероприятий, предназначенных для автоматизации информационных процессов в профессиональной деятельнос- ти. Основным техническим средством АИС является ЭВМ. Объектом информатики является АИС, предназначен- ная для автоматизации военно-профессиональной деятельно- сти должностных лиц и органов управления. Используя термин “информация”, мы, как правило, не задумываемся о том, что такое информация. Надо отметить, что вопрос этот является достаточно сложным (он будет под- робнее рассмотрен в подразд. 2.1). До настоящего времени в науке не выработано строгого определения понятия инфор- мации. Говоря об информационных процессах в АИС, мы пока 13
будем понимать под информацией некоторую совокупность данных (текстовых, числовых, графических) и связей между ними. Под переработкой информации понимаются все возмож- ные информационные процессы, сопровождающие професси- ональную деятельность: сбор информации, хранение инфор- мации, поиск информации, представление информации на определенном носителе в определенном виде (визуальном, гра- фическом, текстовом, звуковом), получение новой информа- ции (например, в результате проведения расчетов), передача информации по каналам связи различным адресатам и др. Автоматизированная информационная система должна рассматриваться как инструмент в руках должностных лиц, реализующих переработку информации в процессе профес- сиональной деятельности. Можно сказать, что наличие это- го инструмента фактически определяет новую технологию осуществления профессиональной деятельности. Понятие “технология” означает комплекс знаний о спо- собах, приемах труда, наборах материально-технических фак- торов, способах их соединения для создания какого-либо про- дукта или услуги. Применительно к промышленному произ- водству используется понятие “производственная индустри- альная технология”. Применение понятия “технология” к информационным процессам привело к возникновению понятия “информаци- онная технология” — совокупность знаний о способах авто- матизированной переработки информации с использованием ЭВМ для автоматизации управленческой деятельности. Создание новых информационных технологий и внедре- ние их в профессиональную деятельность является одной из основных задач информатики. Именно поэтому в качестве предмета информатики целесообразно рассматривать ин- формационные технологии, определяющие рациональные способы разработки и применения АИС. Каждая АИС обеспечивает реализацию некоторой инфор- мационной технологии переработки информации в процессе 14
профессиональной деятельности. Таким образом, в качестве задач информатики можно рассматривать создание новых информационных технологий и реализующих их АИС или перенесение известных информационных технологий из од- ной области человеческой деятельности в другую. 1.1.2. Классификация автоматизированных информационных систем В качестве основного классификационного признака АИС целесообразно рассматривать особенности автоматизируемой профессиональной деятельности — процесса переработки вход- ной информации для получения требуемой выходной инфор- мации, в котором АИС выступает в качестве инструмента должностного лица или группы должностных лиц, участвую- щих в управлении организационной системой. В соответствии с предложенным классификационным признаком можно выделить следующие АИС (рис. 1.1.1): ♦ автоматизированные системы управления (АСУ); ♦ системы поддержки принятия решения (СППР); ♦ автоматизированные информационно-вычислительные системы (АИВС); ♦ автоматизированные системы обучения (АСО); ♦ автоматизированные информационно-справочные сис- темы (АИСС). Рассмотрим особенности каждого класса АИС и характе- ристики возможных видов АИС в составе каждого класса. Автоматизированная система управления представ- ляет собой автоматизированную систему, предназначенную для автоматизации всех или большинства задач управления, решаемых коллективным органом управления (министерством, дирекцией, правлением, службой, группой управления и т. д.). В зависимости от объекта управления различают АСУ персо- налом (АСУП) и АСУ техническими средствами (АСУТС). АСУ является организационной и технической основой реализации рациональной технологии коллективного решения управле- 15
ния в различных условиях обстановки. В этой связи разработ- ка рациональной технологии организационного управления является определяющим этапом создания любой АСУ. АИС АСУ СППР АИВС АИСС АСО АСУП СППР Р ИРС АСД АСПО АСУТС СППР О САПР АА АСОДИ СППР д МЦ АСВЭКМ Т и ТК СППР Оп ПОИС АС(К) Рис. 1.1.1. Классификация АИС Автоматическая система управления персоналом обеспе- чивает автоматизированную переработку информации, необ- ходимой для управления организацией в повседневной дея- тельности, а также при подготовке и реализации программ развития. Автоматические системы управления техническими сред- ствами предназначены для реализации соответствующих тех- нологических процессов. Они являются по сути передаточ- ным звеном между должностными лицами, осуществляющи- ми управление техническими системами, и самими техни- ческими системами. В настоящее время АСУТС нашли широ- кое распространение во всех развитых государствах. Объяс- няется это тем, что управление существующими новейшими технологическими процессами без применения АСУТС стано- вится практически невозможным. Что касается АСУП, то в настоящее время такие системы широко используются в стра- нах Запада, и непрерывно ведутся работы по созданию но- 16
вых систем, в том числе на базе достижений в области ис- кусственного интеллекта. Системы поддержки принятия решений являются достаточно новым классом АИС, теория создания которых в настоящее время интенсивно развивается. СППР называется АИС, предназначенная для автоматизации деятельности кон- кретных должностных лиц при выполнении ими своих долж- ностных (функциональных) обязанностей в процессе управ- ления персоналом и (или) техническими средствами. Выделяются четыре категории должностных лиц, деятель- ность которых отличается различной спецификой переработки информации: руководитель, должностное лицо органа управ- ления, оперативный дежурный, оператор. В соответствии с четырьмя категориями должностных лиц различают и четыре вида СППР: СППР руководителя (СППР Р), СППР должност- ного лица органа управления (СППР О), СППР оперативного дежурного (СППР Д) и СППР оператора (СППР Оп). Рассмотрим специфику деятельности должностных лиц, относящихся к каждой выделенной категории. К категории “руководитель” относятся должностные лица, на которых возложено управление подчиненными должност- ными лицами (подразделениями) и принятие решений в про- цессе руководства. Основная форма деятельности команди- ра — деловое общение. Деятельность должностных лиц, относящихся к катего- рии “руководитель”, характеризуется следующими особен- ностями: ♦ при централизации принятия решений резко возраста- ют объемы информации, уменьшается время на обду- мывание и анализ, растут сложности комплексного учета всех факторов; ♦ велика доля текущих задач, не позволяющих сосредо- точиться на стратегических целях; ♦ в процессе деятельности преобладают приемы, обус- ловленные привычками, опытом, традициями и дру- гими неформализируемыми обстоятельствами; 17
♦ при принятии решения руководитель не всегда в состо- янии описать и даже представить достаточно полную умозрительную модель ситуации, а вынужден исполь- зовать лишь некоторое представление о ней; ♦ деятельность руководителя в значительной мере зави- сит от темперамента и стиля деятельности, от степени знаний причин и следствий, ясности представления вза- имосвязей, объема имеющейся информации. Перечисленные особенности деятельности должностных лиц категории “руководитель” обуславливают крайнюю слож- ность автоматизации их деятельности, которая содержит боль- шое количество неформальных элементов, прежде всего таких, как оперативное и стратегическое управление, а так- же принятие решений. Исходя из особенностей деятельности руководителя, можно сформулировать следующие основные требования, предъявляемые к СППР Р: 1) наличие широкой информационной базы с возможнос- тью оперативного поиска требуемой информации; 2) наглядность представления информации в форме, адап- тированной к запросам конкретного должностного лица (тек- ста, таблиц, графиков, диаграмм и т. д.); 3) обеспечение оперативной связи с другими источника- ми информации в системе управления и особенно с непос- редственными помощниками; 4) наличие диалоговых программных средств обеспече- ния принятия решений на основе формальных (математичес- ких) методов; 5) простота работы при повышенной надежности техни- ческих и программных средств; 6) обеспечение возможности накопления в памяти ЭВМ опыта и знаний (в рамках интеллектуальных СППР). Необходимо отметить, что требования 2, 3 и 5 являются универсальными и относятся ко всем видам СППР. В настоящее время требования 1, 2, 3 и 5 могут быть полностью удовлетворены с использованием известных ин- формационных технологий. Что касается требований 4 и 6 18
(наличия программных средств обеспечения решений и на- копления в памяти ЭВМ опыта и знаний), то их удовлетворе- ние составляет основную теоретическую проблему, возника- ющую при создании СППР Р, К категории “должностное лицо органа управления” от- носятся специалисты, занимающиеся аналитической работой по подготовке решений руководителя и их документальным оформлением. Основу деятельности должностных лиц органа управления составляет оценка различных вариантов реше- ния (проведение оценочных расчетов) и разработка проектов различных документов. Эффективность функционирования органа управления во многом определяется продуктивностью деятельности специа- листов, особенно в вопросах создания новой информации. Доля творческого труда в их работе достаточно высока. Именно эти специалисты обеспечивают практически всю информаци- онную подготовку для принятия решения руководителем. Они являются основными исполнителями документов, определяя их качество. СППР О должна прежде всего создать должнос- тным лицам условия для плодотворного ведения аналитичес- кой работы и сведения к минимуму доли рутинных работ (по- иск информации, оформление документов, проведение опе- ративных расчетов и т. д.). Особенности деятельности должностных лиц органа уп- равления определяют следующие основные требования к СППР О: ♦ обеспечение оперативного поиска и отображения всей информации, необходимой для подготовки решений и формирования проектов документов в пределах его ком- петентности; ♦ обеспечение возможности ведения оперативных расче- тов и моделирования для оценки ситуации и подготов- ки вариантов решений; ♦ обеспечение возможности автоматизированной подго- товки проектов документов (текстов, графиков, диаг- рамм и т. п.). 19
К основным элементам СППР О следует отнести сред- ства ведения оперативных расчетов и моделирования, посколь- ку именно эти средства в наибольшей степени обеспечивают повышение эффективности и качества управления. К категории “оперативный дежурный” относятся долж- ностные лица, выполняющие обязанности по оперативному руководству организационной системой во время дежурства на соответствующих пунктах управления в течение опреде- ленного времени. Основными особенностями деятельности оперативных дежурных являются: ♦ относительно узкий круг решаемых задач; ♦ жесткая регламентация деятельности в большинстве вариантов складывающейся обстановки; ♦ жесткий лимит времени на принятие решений и вы- полнение различных операций. Перечисленные особенности деятельности оперативных дежурных определяют в качестве основных требований к СППР Д обеспечение оперативного предоставления инфор- мации, необходимой оперативному дежурному в заранее оп- ределенных ситуациях, а также обеспечение оперативного анализа складывающейся ситуации. Последнее требование может быть обеспечено с использованием технологии эксперт- ных систем. К категории “оператор” могут быть отнесены должност- ные лица, выполняющие техническую работу по заранее определенному алгоритму. Основная особенность деятельнос- ти оператора — отсутствие необходимости принимать слож- ные решения в процессе своей деятельности. СППР Оп дол- жна обеспечивать возможность работы должностного лица со справочной информацией и возможность автоматизированной подготовки текстов документов. Автоматизированные информационно-вычислительные системы предназначены для решения сложных в математи- ческом отношении задач, требующих больших объемов самой разнообразной информации. Таким образом, видом деятель- 20
ности, автоматизируемом АИВС, является проведение раз- личных (сложных и “объемных”) расчетов. Эти системы ис- пользуются для обеспечения научных исследований и разра- боток, а также как подсистемы АСУ и СППР в тех случаях, когда выработка управленческих решений должна опираться на сложные вычисления. В зависимости от специфики области деятельности, в которой используются АИВС, различают следующие виды этих систем. Информационно-расчетная система (ИРС) — это авто- матизированная система, предназначенная для обеспечения оперативных расчетов и автоматизации обмена информацией между рабочими местами в пределах некоторой организации или системы организаций. ИРС обычно сопрягается с АСУ и в рамках последней может рассматриваться как ее подсистема. Технической базой ИРС являются, как правило, сети больших, малых и микроЭВМ. ИРС имеют сетевую структу- ру и могут охватывать несколько десятков и даже сотен ра- бочих мест различных уровней иерархии. Основной сложнос- тью при создании ИРС является обеспечение высокой опера- тивности расчетов и обмена информации в системе при стро- гом разграничении доступа должностных лиц к служебной ин- формации. Система автоматизации проектирования (САПР) — это автоматизированная информационная система, предназначен- ная для автоматизации деятельности подразделений проект- ной организации или коллектива специалистов в процессе разработки проектов изделий на основе применения единой информационной базы, математических и графических моде- лей, автоматизированных проектных и конструкторских про- цедур. САПР является одной из систем интегральной автома- тизации производства, обеспечивающих реализацию автома- тизированного цикла создания нового изделия от предпроект- ных научных исследований до выпуска серийного образца. В области экономики САПР могут использоваться при проектировании экономических информационных систем и их элементов. Кроме того, технология САПР может обеспечить 21
создание автоматизированной системы отображения обста- новки на экране в процессе ведения экономических операций или в ходе деловых игр различных типов. Проблемно-ориентированные имитационные системы (ПОИС) предназначены для автоматизации разработки ими- тационных моделей в некоторой предметной области [39]. На- пример, если в качестве предметной области взять развитие автомобилестроения, то любая модель, создаваемая в этой предметной области, может включать стандартные блоки, моделирующие деятельность предприятий, поставляющих комплектующие; собственно сборочные производства; сбыт, обслуживание и ремонт автомобилей; рекламу и др. Эти стан- дартные блоки могут строиться с различной детализацией моделируемых процессов и различной оперативностью расче- тов. Пользователь, работая с ПОИС, сообщает ей, какая мо- дель ему нужна (т. е. что необходимо учесть при моделирова- нии и с какой степенью точности), а ПОИС автоматически формирует имитационную модель, необходимую пользовате- лю. В состав программного обеспечения ПОИС входят банки типовых моделей (БТМ) предметных областей, планировщик моделей, базы данных предметных областей, а также сред- ства диалогового общения пользователя с ПОИС. Проблемно-ориентированная система является достаточ- но сложной АИС, реализуемой, как правило, с использова- нием технологии искусственного интеллекта на высокопроиз- водительных ЭВМ. Моделирующие центры (МЦ) — автоматизированные информационные системы, представляющие собой комплекс готовых к использованию моделей, объединенных единой пред- метной областью, информационной базой и языком общения с пользователями [39]. МЦ, так же как ПОИС, предназначе- ны для обеспечения проведения исследований на различных моделях. Но, в отличие от ПОИС, они не обеспечивают авто- матизацию создания имитационных моделей, а предоставля- ют пользователю возможность комфортной работы с готовы- 22
ми моделями. МЦ могут являться системами как коллектив- ного, так и индивидуального использования и в принципе не требуют для своей реализации мощных ЭВМ. Автоматизированные системы обучения (АСО). Тра- диционные методы обучения специалистов в различных об- ластях профессиональной деятельности складывались многи- ми десятилетиями, в течение которых накоплен большой опыт. Однако, как свидетельствуют многочисленные исследо- вания, традиционные методы обучения обладают рядом не- достатков. К таким недостаткам следует отнести пассивный характер устного изложения, трудность организации актив- ной работы студентов, невозможность учета в полной мере индивидуальных особенностей отдельных обучаемых и т. д. Одним из возможных путей преодоления этих трудно- стей является создание АСО — автоматизированных инфор- мационных систем, предназначенных для автоматизации под- готовки специалистов с участием или без участия преподава- теля и обеспечивающих обучение, подготовку учебных кур- сов, управление процессом обучения и оценку его результа- тов. Основными видами АСО являются автоматизированные системы программного обучения (АСПО), системы обеспече- ния деловых игр (АСОДИ), тренажеры и тренажерные ком- плексы (ТиТК). Автоматизированные системы программного обучения ориентированы на обучение в основном по теоретическим разделам курсов и дисциплин. В рамках АСПО реализуются заранее подготовленные квалифицированными преподавате- лями “компьютерные курсы”. При этом учебный материал разделяется на порции (дозы) и для каждой порции материа- ла указывается возможная реакция обучаемого. В зависимос- ти от действий обучаемого и его ответов на поставленные вопросы АСПО формирует очередную дозу представляемой информации. Наибольшую сложность при создании АСПО составляет разработка “компьютерного курса” для конкретной дисципли- ны. Именно поэтому в настоящее время наибольшее распрос- 23
транение получили “компьютерные курсы” по традиционным, отработанным в методическом плане дисциплинам (физике, элементарной математике, программированию и т. д.). Автоматизированная система обеспечения деловых игр предназначена для подготовки и проведения деловых игр, сущность которых заключается в имитации принятия долж- ностными лицами индивидуальных и групповых решений в различных проблемных ситуациях путем игры по заданным правилам. В ходе деловой игры на АСОДИ возлагаются следующие задачи: ♦ хранение и предоставление обучаемым и руководите- лям игры текущей информации о проблемной среде в процессе деловой игры в соответствии с их компетен- цией; ♦ формирование по заданным правилам реакции проблем- ной среды на действия обучаемых; ♦ обмен информацией между участниками игры (обучае- мыми и руководителями игры); ♦ контроль и обобщение действий обучаемых в процессе деловой игры; ♦ предоставление руководителям игры возможности вме- шательства в ход игры, например, для смены обста- новки. Технической базой АСОДИ являются высокопроизводи- тельные ЭВМ или локальные вычислительные сети. Методо- логической базой АСОДИ, как правило, является имитаци- онное моделирование на ЭВМ. Тренажеры и тренажерные комплексы предназначены для обучения практическим навыкам работы на конкретных рабо- чих местах (боевых постах). Они являются средствами инди- видуального (тренажеры) и группового (тренажерные комп- лексы) обучения. ТиТК являются достаточно дорогостоящи- ми средствами обучения, а их создание требует больших зат- рат времени. Однако их чрезвычайно высокая эффективность при обучении таких специалистов, как летчики, водители, 24
операторы систем управления и т. д. позволяет считать их достаточно перспективными видами АСО. Автоматизированные информационно-справочные системы (АИСС) — это автоматизированные информаци- онные системы, предназначенные для сбора, хранения, по- иска и выдачи в требуемом виде потребителям информации справочного характера. В зависимости от характера работы с информацией раз- личают следующие виды АИСС: ♦ автоматизированные архивы (АА); ♦ автоматизированные системы делопроизводства (АСД); ♦ автоматизированные справочники (АС) и картотеки (АК); ♦ автоматизированные системы ведения электронных карт местности (АСВЭКМ) и др. В настоящее время разработано большое количество раз- новидностей АИСС и их количество продолжает увеличивать- ся. АИСС создаются с использованием технологии баз данных, достаточно хорошо разработанной и получившей широкое распространение. Для создания АИСС, как правило, не требу- ется высокопроизводительная вычислительная техника. Простота создания АИСС и высокий положительный эф- фект от их использования определили их активное примене- ние во всех сферах профессиональной (в том числе и управ- ленческой) деятельности. 1.1.3. Место информационных и расчетных задач в составе программного обеспечения ЭВМ Согласно определению, данному в п. 1.1.1, АИС представ- ляет собой совокупность трех взаимосвязанных компонент: технических средств, программных средств и организацион- ных мероприятий. Под техническими средствами понимаются ЭВМ, устройства ввода и вывода информации (дисплеи, пе- чатающие устройства, графопостроители, сканеры, плотте- ры, мониторы и т. д.), устройства долговременного хранения информации (накопители на магнитной ленте или магнитном 25
диске), сетевое оборудование и каналы связи. Технические средства АИС сами по себе не в состоянии решить какой- либо задачи. Для того чтобы АИС начала функционировать, в ЭВМ необходимо ввести программу, описывающую алго- ритм работы технических средств по переработке информа- ции в интересах решения конкретной практической задачи. Совокупность математических методов, алгоритмических языков и алгоритмов, характеризующих логические и мате- матические возможности ЭВМ, называется математическим обеспечением ЭВМ. Алгоритмы, входящие в математическое обеспечение, реализуются в ЭВМ или аппаратно, или про- граммно. Аппаратная реализация алгоритмов предполагает наличие в составе ЭВМ технических устройств, преобразую- щих входные сигналы в выходные по жесткому, неизменяе- мому алгоритму. Комплекс программ, описаний и инструкций, обеспечи- вающих создание и отладку программ и решение задач на ЭВМ, называется программным обеспечением ЭВМ. По су- ществу, программное обеспечение — это записанное на вход- ном языке ЭВМ математическое обеспечение ЭВМ. Одно и то же математическое обеспечение может быть реализовано для различных типов ЭВМ различным программным обеспе- чением. Поскольку математические методы и алгоритмы нераз- рывно связаны с программами, их реализующими, на прак- тике вместо терминов “математическое обеспечение” и “про- граммное обеспечение” часто используется термин “матема- тическое и программное обеспечение” (МПО). При анализе состава МПО ЭВМ будем вести речь о про- граммном обеспечении (ПО), имея в виду, что аналогичный состав имеет и соответствующее математическое обеспечение. Вариант типовой структуры программного обеспечения ЭВМ представлен на рис. 1.1.2 [53, 54]. Программное обеспечение ЭВМ состоит из двух частей: общего программного обеспечения (ОПО) и специального про- граммного обеспечения (СПО). 26
Рис. 1.1.2. Структура программного обеспечения ЭВМ (АИС) Общее программное обеспечение представляет собой ком- плекс программ, предназначенных для обеспечения работы ЭВМ в различных режимах и снижения трудоемкости созда- ния и отладки программ пользователей. Основные функции ОПО сводятся к следующим: ♦ автоматическое управление вычислительным процес- сом в различных режимах работы ЭВМ при минималь- ном вмешательстве оператора, программиста, конеч- ного пользователя в этот процесс; ♦ обеспечение возможности подготовки программ к ре- шению на ЭВМ с помощью средств автоматизации про- граммирования; ♦ рациональное распределение ресурсов ЭВМ при одно- временном решении нескольких задач, что значитель- но повышает эффективность использования ЭВМ; ♦ разграничение доступа различных пользователей к дан- ным, хранимым и обрабатываемым в ЭВМ и обеспече- ние защиты данных; ♦ контроль, диагностика и локализация неисправностей ЭВМ и т. д. По назначению и функциональным особенностям ОПО делится на две взаимосвязанные части: общее системное программное обеспечение (ОСПО) и общее прикладное про- граммное обеспечение (ОППО). 27
В состав ОСПО входят операционная система (ОС), сис- темы программирования (СП) и программы контроля и диаг- ностики состояния ЭВМ, Операционной системой называется комплекс программ, осуществляющих управление вычислительным процессом, обеспечивающих связь пользователя с ЭВМ на этапах запус- ка задач и реализующих наиболее общие алгоритмы обра- ботки информации на данной ЭВМ. Главная функция ОС — обеспечение эффективной работы ЭВМ и всех внешних уст- ройств (дисплеев, устройств ввода, вывода и т. д.) в различ- ных режимах работы. Под режимом работы понимается способ организации выполнения в ЭВМ задания или нескольких заданий одновре- менно. Основными режимами работы являются: монопольный, многопрограммный (мультипрограммный) и режим разделе- ния времени. В монопольном режиме все устройства ЭВМ заняты вы- полнением только одного задания, являющегося основной единицей работы ЭВМ. Задание может включать несколько пунктов, выполняемых ОС последовательно. Например, за- дание может включать: ♦ трансляцию программы; ♦ компоновку оттранслированной программы; ♦ запуск программы на счет. При монопольном режиме все ресурсы ЭВМ использу- ются по мере надобности для отработки очередного пункта задания. С точки зрения загрузки ЭВМ этот режим наименее эффективен, так как в процессе обработки одного задания различные устройства ЭВМ работают с неодинаковой нагруз- кой или вообще простаивают значительную часть времени. Однако этот режим наиболее удобен для пользователя, так как время решения задачи при этом минимально. В настоя- щее время монопольный режим наиболее широко использу- ется в микроЭВМ (прежде всего персональных ЭВМ). Для увеличения производительности и эффективности использования ЭВМ за счет организации параллельной рабо- 28
ты основных устройств ЭВМ применяется мультипрограмм- ный режим работы. В этом режиме ОС принимает к исполнению сразу не- сколько заданий. При достаточно большом количестве одно- временно находящихся в памяти ЭВМ заданий этот режим обеспечивает практически полную загрузку всех устройств ЭВМ. Мультипрограммный режим является основным в работе ЭВМ серий ЕС и СМ (такие ЭВМ по-прежнему используются весьма широко). Кроме того, он находит частичное примене- ние и в персональных ЭВМ высокой производительности, что позволяет пользователю одновременно ввести в ЭВМ несколь- ко заданий. Применение мультипрограммного режима на “боль- ших” ЭВМ позволило обеспечить пакетную обработку задач, при которой пользователи передавали задание оператору, опе- ратор формировал пакеты этих заданий, пропускал их через ЭВМ и затем возвращал пользователям результаты решения сразу по всем заданиям, составляющим очередной пакет. Пакетная обработка заданий позволяет существенно по- высить эффективность работы ЭВМ, но крайне неудобна для пользователя, поскольку он связан с ЭВМ не непосредствен- но, а через оператора. Наличие этого промежуточного звена приводит к существенному увеличению суммарного времени решения задачи на ЭВМ. Для приближения пользователя к ЭВМ и устранения опе- ратора как промежуточного звена между пользователем и ЭВМ были созданы ОС, реализующие особый вид мультипрограмм- ного режима — режима разделения времени. Основным сред- ством связи пользователей с ЭВМ стали дисплеи. Реализация режима разделения времени приводит к тому, что пользова- тели получают связь с ЭВМ поочередно на небольшой проме- жуток времени. Если этот промежуток времени невелик и не- велико количество одновременно работающих пользователей, то каждый работающий пользователь не будет ощущать пре- рывистой связи с ЭВМ. Таким образом, создается впечатле- ние, что пользователь работает один на некоторой вообража- емой ЭВМ. 29
Недостатком режима разделения времени является умень- шение скорости вычислений пропорционально числу одно- временно работающих пользователей. Однако, несмотря на этот недостаток, режим разделения времени является основ- ным режимом работы всех современных ЭВМ, обслуживаю- щих несколько пользователей. Основными элементами ОС являются процессор языка управления, супервизор и файловая система. Процессор языка управления представляет собой програм- му, предназначенную для распознавания и преобразования команд пользователя и оператора ЭВМ в машинное представ- ление с целью их последующей обработки. Основными функциями супервизора являются следующие: контроль загруженности различных устройств ЭВМ задания- ми, распределение оперативной памяти между заданиями, защита одновременно решаемых заданий (задач) друг относи- тельно друга, запуск операций ввода-вывода и т. д. По своему месту в программном обеспечении ЭВМ супервизор занимает положение посредника между аппаратным обеспечением ЭВМ и всем другим программным обеспечением машины. Файловая система образуется программами, которые поддерживают ведение всей совокупности файлов (наборов данных) в ЭВМ. Основными функциями этой системы явля- ются: поиск требуемых файлов, модификация информации в файлах, перемещение файлов, копирование файлов, удале- ние файлов. Системы программирования предназначены для обеспе- чения создания и отладки программ пользователей, написан- ных на каком-либо языке программирования (ПАСКАЛЬ, С, C++, ФОРТРАН и т. д.). В настоящее время для этих целей широко используются так называемые среды программиро- вания (разработки программ) — например, продукты фирмы Borland DELPHI или Builder C++, позволяющие быстро со- здавать качественные приложения. Программы контроля и диагностики состояния ЭВМ предназначены для осуществления непрерывного контроля 30
работы основных устройств ЭВМ, а также поиска неисправ- ных блоков и узлов ЭВМ в случае обнаружения отказов или устойчивых сбоев. Общее прикладное программное обеспечение включает: пакеты прикладных программ, системы управления базами данных, интеграторы и другие (подобные) прикладные про- граммные системы. Особенностью объектов ОППО является то, что эти средства не требуют от пользователей при реше- нии ими конкретных практических задач на ЭВМ проведения операций, связанных с программированием. Под пакетами прикладных программ (ППП) понимается совокупность готовых к решению программ, объединяемых в пакет по единому содержательному признаку с помощью до- полнительной управляющей программы. Данная программа автоматизирует и упрощает стандартную схему использова- ния готовых программ на ЭВМ. Основными функциями управ- ляющей программы являются следующие: поддержание диа- логовой (дружественной) формы получения информации от пользователя (обычно это режим меню), вызов соответству- ющих программ из пакета с целью решения ими содержа- тельных задач, поставленных пользователем, выдача пользо- вателю выходных данных по решенным задачам в удобной форме. В настоящее время ППП наряду с системами управления базами данных являются самой распространенной формой прикладного программного продукта для массового пользо- вателя. Среди ППП выделяются пакеты трех типов: проблем- но-ориентированные, интегрированные и инструментальные. ППП первого типа структурно являются наиболее про- стыми. Они состоят из программ, которые нацелены на реше- ние фиксированного числа задач из относительно узкой пред- метной области. При этом каждой частной задаче соответ- ствует вполне определенная программа ее решения. В функ- ции управляющей программы входит распознавание в запро- се пользователя имени и атрибутов той задачи, которую он выбирает для решения, и запуск соответствующей програм- мы на исполнение. 31
Интегрированные пакеты программ являются расшире- нием ППП первого типа путем их наращивания такими про- граммами, которые автоматизируют все (или большинство) сопутствующие операции, выполняемые лицом, пользующим- ся пакетом. К числу указанных программ чаще всего отно- сятся текстовый редактор, система управления базами дан- ных, графический редактор, реже — электронная таблица и другие. В отличие от самостоятельных версий этих программ данные версии названных программ носят упрощенный ха- рактер, достаточный лишь для решения задач из соответ- ствующей предметной области. Инструментальные пакеты программ отличаются от рас- смотренных выше двух типов ППП отсутствием в них про- грамм, строго ориентированных на решение конкретных прак- тических задач. Данные пакеты состоят из программ, каждая из которых может рассматриваться как необходимый элемент решения задач из некоторой предметной области. Таким об- разом, при использовании данных ППП пользователь в своем запросе указывает структуру элементов, которая реализует прикладную задачу. Управляющая программа пакета на осно- ве заданной структуры элементов создает соответствующую рабочую программу решения требуемой прикладной задачи и затем передает ей управление. В последнее время появились так называемые интеллектуальные ППП, которые будут рассмотрены в четвертой главе настоящего учебника. Объекты ОПО, как правило, поставляются промышлен- ностью совместно с ЭВМ. Оно носит универсальный харак- тер в том смысле, что позволяет создать любую программу, совместимую с аппаратными и вычислительными возможнос- тями конкретной ЭВМ, и провести на ней расчеты. ОПО по существу является инструментом создания СПО — комплек- са программ, предназначенных для решения конкретных уп- равленческих, исследовательских или производственных за- дач. Конкретное содержание СПО полностью определяет вид конкретной АИС ВН и, конечно, зависит от ее типа. Специальное программное обеспечение, так же как и ОПО, как правило, состоит из двух частей: специального системно- 32
го программного обеспечения (ССПО) и специального приклад- ного программного обеспечения (СППО). ССПО выполняет в АИС ВН функции, аналогичные функциям ОС в ОПО. Необходимость ССПО в вычислительных комплексах во- енного назначения обусловливается двумя причинами: обес- печением требования поддержки особых (специальных) ре- жимов проведения вычислительных работ в этих комплек- сах; необходимостью управления функционированием специ- альных устройств. Специальное прикладное программное обеспечение пред- ставляет собой комплекс программ, каждая из которых реа- лизует тот или иной алгоритм переработки информации. Дан- ные программы принято называть задачами и, хотя это на- звание нельзя признать удачным, оно в настоящее время является общепринятым. Задачи являются основными элемен- тами АИС, в том числе и экономического назначения, по- скольку они определяют ее возможности как средства авто- матизации деятельности должностных лиц при управлении персоналом. В дальнейшем в учебнике будут более подробно рассмот- рены вопросы создания и использования СППО как основного элемента АИС. 1.1.4. Классификация информационных и расчетных задач Все задачи, входящие в СППО, можно классифициро- вать по нескольким признакам: ♦ характеру переработки информации; ♦ назначению; ♦ уровню применения. Необходимость приведенной ниже классификации опре- деляется различием требований, предъявляемых к задачам каждого класса. Основным классификационным признаком, по которому все задачи, входящие в СППО, подразделяются на два раз- 33
личных класса, является характер переработки информа- ции. В зависимости от характера переработки информации задачи бывают информационные и расчетные. Информационной задачей называется элемент специаль- ного прикладного программного обеспечения ЭВМ (програм- ма на ЭВМ), алгоритм переработки информации которого не приводит к созданию новой информации, отличной от ис- ходной. Примером информационных задач могут служить за- дачи: поиска информации, хранящейся в памяти ЭВМ, офор- мления (печати) бухгалтерских и управленческих докумен- тов, нанесения обстановки на карту и т. д. Таким образом, информационные задачи осуществляют процессы сбора, хра- нения, поиска информации и преобразования ее из одного вида в другой без изменения существа этой информации и без создания новой информации. Информационные задачи являются в настоящее время одними из самых простых, имеющими хорошо развитые сред- ства создания, и достаточно эффективными элементами СППО при автоматизации деятельности должностных лиц. Они по- зволяют полностью исключить или значительно упростить прежде всего рутинные процедуры в деятельности должнос- тных лиц (хранение, поиск, сортировка информации, состав- ление документов и их тиражирование и т. д.) и тем самым сократить необходимое количество персонала, занятого в основном технической деятельностью (машинистки, делопро- изводители, работники библиотек, архивов и т. д.). Расчетной задачей называется элемент специального прикладного программного обеспечения ЭВМ (программа на ЭВМ), алгоритм переработки информации которого приво- дит к созданию новой информации, непосредственно не со- держащейся в исходной. К расчетным задачам относятся за- дачи: анализ итогов хозяйственной деятельности, расчета показателей эффективности экономической операции, расче- та заработной платы сотрудников и т. д. В свою очередь, расчетные задачи подразделяются на вычислительные задачи и математические модели. 34
Вычислительной задачей называется расчетная задача, алгоритм переработки информации которой построен без ис- пользования методов математического моделирования. Обыч- но алгоритмы вычислительных задач известны до начала их разработки и, как правило, нормативно закреплены в при- казах, наставлениях, справочниках, государственных стан- дартах т. п. Примерами вычислительных задач являются за- дачи: расчета подоходного налога, расчета показателей фи- нансовой отчетности, расчета нормативного расхода средств, подведения итогов работы фирмы и т. д. Математической моделью (ММ) называется расчетная задача, алгоритм переработки информации которой основан на использовании тех или иных методов математического моделирования. Классификацию элементов СППО по назна- чению и уровню применения приведем для тех задач, кото- рые используются в целях автоматизации управленческой деятельности (остальные будут рассматриваться ниже). По назначению информационные и расчетные задачи подразделяются на штатные и исследовательские. Штатной называют информационную или расчетную задачу, официально включенную в типовой цикл управления организацией и используемую должностными лицами орга- нов управления в процессе служебной деятельности. Штатные информационные и расчетные задачи (ИРЗ) бывают одноуровневые (используемые в звеньях управления одного уровня, например — задачи предприятия) и много- уровневые (используемые в звеньях управления нескольких уровней, например — на предприятии, объединении и в ми- нистерстве). Основными особенностями штатных ИРЗ, непосред- ственно следующими из их назначения, являются высокая достоверность результатов расчетов и оперативность их получения. Кроме того, штатные задачи должны обеспечи- вать простоту и удобство общения с пользователем в про- цессе его работы на ЭВМ. Исследовательской называется информационная или рас- четная задача, используемая должностными лицами при 35
проведении научно-исследовательских работ, обосновании перспективных программ развития, прогнозирования эконо- мических ситуаций и т. п. Как правило, исследования прово- дятся с использованием математических моделей. Исследовательские модели не имеют жестких требо- ваний по оперативности работы, поэтому они позволяют обеспечить широкий учет различных факторов при модели- ровании. Кроме того, исследовательские задачи должны обес- печивать легкость изменения (при необходимости) алгорит- ма своей работы в ходе исследований. При этом трудно обес- печить простоту и удобство работы с задачей. Исследова- тельские задачи в ряде случаев могут рассматриваться в ка- честве прототипов штатных задач, хотя это возможно далеко не всегда (подробнее об этом будет сказано ниже — в подразд. 1.3). 1.2. Основы проектирования элементов программного обеспечения информационных систем 1.2.1. Основные требования к информационным, расчетным задачам и их комплексам Информационные, расчетные задачи и их комплексы (ИРЗ и К) составляют основу любой АИС, определяют ее возможности по автоматизации профессиональной деятель- ности. Ввиду особой важности и значимости этих элементов специального программного обеспечения их разработка орга- низуется в соответствии с требованиями федеральных ука- зов, законов, циркуляров, директив, государственных стан- дартов и других руководящих документов [13, 14]. Перечис- лим эти требования, а затем рассмотрим каждое из них под- робнее: ♦ достоверность результатов использования ИРЗ и К; 36
♦ оперативность получения результатов; ♦ соответствие ИРЗ и К уровню руководства; ♦ системный подход к созданию и применению СПО; ♦ обеспечение безопасности обрабатываемой информации. Достоверность результатов Под достоверностью результатов использования ИРЗ (рас- чета, моделирования) будем понимать соответствие значений параметров, получаемых в результате решения задачи, их требуемым (“истинным”) значениям. Возможными причинами недостоверности получаемых в процессе расчетов результатов являются: ♦ неадекватность применяемой математической модели операции (процесса, явления); ♦ низкая точность вычислений; ♦ ошибки в алгоритме переработки информации, в соот- ветствии с которым работает задача; ♦ ошибки пользователя при проведении расчетов; ♦ ошибки (сбои) в работе ЭВМ. Под адекватностью в теории систем понимается степень соответствия используемой математической модели реально- му процессу (системе, объекту). Следовательно, для оценки адекватности математической модели необходимо провести реальную операцию, осуществить математическое модели- рование этой же операции в тех же условиях и сравнить реальные результаты операции с результатами моделирова- ния, используя некоторый показатель, например, показатель эффективности операции. Если результаты реальной опера- ции будут хорошо согласовываться с результатами модели- рования, то это означает, что используемая математическая модель в данных условиях проведения операции является адекватной реальному процессу (системе, объекту). Важно отметить, что в этом случае можно количественно оценить адекватность модели в рамках суждений типа “результаты моделирования расходятся с реальными не более чем на 10%”. 37
Формально оценить адекватность модели не всегда уда- ется, поскольку не всегда возможно проведение реальной операции для сравнения с результатами моделирования (на- пример, для моделей операций, предусматривающих приме- нение ядерного оружия, или крупномасштабных экономичес- ких моделей). В таких условиях под адекватностью принято понимать степень доверия должностного лица к результатам моделирования, используемым для принятия решений. При этом невозможно ввести показатель, объективно характери- зующий степень адекватности модели. Модель может быть или адекватной, или неадекватной. Должностное лицо должно сделать вывод об адекватности модели на основании анализа существа модели и полноты учета в модели всех факторов, влияющих на проведение операции в конкретных условиях. Низкая точность вычислений также может стать при- чиной недостоверности получаемых результатов расчета. Су- ществуют две возможные причины возникновения ошибок вычислений: методические ошибки и ошибки округления. Методические ошибки связаны с использованием приближен- ных численных методов (например, при использовании мето- да численного интегрирования или дифференцирования фун- кций). Ошибки округлений связаны с тем, что числа в ЭВМ представляются всегда с некоторой точностью, определяемой количеством значащих цифр в записи числа (для современ- ных ЭВМ такие ошибки практически всегда связаны с невер- ными действиями пользователей, в частности — при программ- ной реализации ИРЗ). Ошибки в алгоритме переработки информации, в соот- ветствии с которым работает ЭВМ, являются достаточно ред- ким источником недостоверности результатов расчетов и, как правило, бывают связаны с неучетом в алгоритме задачи всех возможных вариантов исходных данных. При некоторых ва- риантах исходных данных могут возникнуть ситуации, когда алгоритм задачи работает с ошибками. Поэтому при создании алгоритма задачи необходимо тщательно проанализировать возможные значения исходных данных и определить их до- 38
пустимые значения. Выявление ошибок в алгоритме перера- ботки информации является одной из важнейших целей при проведении контрольных расчетов на этапе приемки ИРЗ. Ошибки пользователя при проведении расчетов являют- ся, на первый взгляд, ошибками, которые невозможно ис- ключить за счет создания специальных алгоритмических и программных средств. Тем не менее существуют способы уменьшения возможностей для появления таких ошибок (ко- нечно, имеются в виду непреднамеренные, “случайные” ошиб- ки). Речь идет о программном контроле вводимой пользовате- лем информации. Эта информация может включать значения параметров или команды. Как правило, при вводе парамет- ров можно программно проконтролировать допустимость зна- чения вводимого параметра, причем ограничения на значе- ния параметра могут быть как постоянными, так и изменять- ся в зависимости от значений других параметров. Например, в задаче планирования транспортной операции по доставке потребителям какой-либо продукции допустимые значения скорости движения зависят от типов транспортных средств, участвующих в операции, и состояния дорог на маршрутах движения. Что касается контроля команд, вводимых пользователем, то он может включать проверку допустимости данной коман- ды на конкретном этапе работы с задачей (например, провер- ка наличия всех необходимых исходных данных перед выпол- нением команды начала расчета), а также выдачу на экран монитора запроса для подтверждения пользователем намере- ния выполнить какую-либо важную команду (например, при уничтожении каких-либо данных на экран монитора выводит- ся вопрос типа: “Вы действительно хотите уничтожить эти данные?”, и требуется утвердительный ответ пользователя для выполнения команды). Кроме того, особо ответственные ко- манды могут предусматривать запрос на подтверждение пол- номочий на их проведение (например, ввод пароля). Ошибки (сбои) в работе ЭВМ могут повлиять на досто- верность результатов расчетов, если они не селектируются 39
техническими средствами и операционной системой. Единствен- ным средством исключения неселектируемых ошибок (сбоев) в работе ЭВМ является повторное решение задачи. Поэтому наиболее ответственные расчеты должны дублироваться на другой ЭВМ и (или) с использованием другой задачи, имею- щей аналогичный алгоритм. Оперативность результатов Под оперативностью получения результатов расчетов на ИРЗ понимается возможность практического использования результатов их решения (расчетов, моделирования) либо в реальном ритме работы, либо за заданное время. Задача об- ладает требуемой оперативностью решения, если время ра- боты пользователя с ней обеспечивает своевременное приме- нение получаемых результатов в профессиональной деятель- ности. Время работы с задачей включает время на настройку (при необходимости) программного обеспечения (а иногда и технических средств), подготовку исходных данных, ввод их в ЭВМ, проведение расчетов и выдачу результатов в виде, удобном для дальнейшего использования. Таким образом, оперативность получения результатов расчетов является интегральной характеристикой, которая включает в себя не только скорость вычислений по алгорит- му задачи, но и скорость ввода исходных данных, а также получение результатов в виде, не требующем какой-либо дополнительной обработки (переписывания, перепечатывания и т. д.). Поэтому при создании ИРЗ необходимо предусматри- вать минимально необходимый объем исходных данных, вво- димый пользователем при использовании задачи, а также удобство их ввода. Соответствие уровню руководства Под требованием соответствия ИРЗ и К уровню руковод- ства понимается: ♦ использование в них информации с детализацией и точ- ностью, которыми располагает данное должностное лицо (должностные лица), работающее с задачей; 40
♦ представление результатов в наглядном (привычном для пользователя) виде, соответствующем форме и содер- жанию реальных документов; ♦ применение показателей, имеющих для конкретного должностного лица ясный технический, оперативный и физический смысл (так называемых транспарентных показателей). Системный подход Требование системного подхода означает, что все созда- ваемые ИРЗ и К должны быть составными элементами общей системы задач и моделей, т. е. они должны быть согласованы между собой по цели и назначению, составу учитываемых факторов и ограничений, содержанию и формам входных и выходных документов, показателей, критериев эффективнос- ти и нормативов, структуре и содержанию информационной базы, принципам защиты обрабатываемой информации. Обеспечение безопасности информации Требование обеспечения безопасности обрабатываемой информации заключается в исключении возможности унич- тожения или искажения информации, обрабатываемой на ЭВМ, а также возможности несанкционированного получе- ния этой информации не допущенными к ней лицами. Выпол- нение данного требования достигается осуществлением ком- плекса организационных мероприятий и технических мер, подробно рассматриваемых в подразд. 1.5. 1.2.2. Принципы разработки информационных, расчетных задач и их комплексов Помимо основных требований к создаваемым ИРЗ и К, руководящими (нормативными) документами определены и основные принципы разработки и поддержания в работоспо- собном состоянии элементов СПО. Руководство данными прин- ципами является обязательным и позволяет создавать и приме- нять ИРЗ и К, отвечающие приведенным в п. 1.2.1 требовани- 41
ям. Сформулируем эти принципы применительно к средствам автоматизации наиболее сложной области профессиональной деятельности — управлению сложными человекомашинными системами экономического назначения: ♦ централизованная разработка по единому плану и за- мыслу на общих информационных и математических основах; ♦ конкретность предназначения создаваемых задач и их комплексов; ♦ непосредственное руководство и участие в создании задач предприятий и фирм (организаций), в интересах которых они создаются; ♦ обеспечение возможности перестройки задач в процес- се их эксплуатации применительно к конкретной об- становке; ♦ непрерывное сопровождение разработанных ИРЗ и их комплексов представителями заказчика и разработчика. Централизованность разработки Принцип централизованной разработки по единому пла- ну и замыслу на общих информационных и математических основах используется при создании ИРЗ и К в рамках единой АСУ. Этот принцип должен неукоснительно соблюдаться при создании задач, результаты решения которых используются во всех или нескольких звеньях АСУ (например, задач, ис- пользуемых для автоматизации управления отраслью эконо- мики в министерстве). Для обеспечения централизованной разработки ИРЗ в вышестоящих организациях формируется и утверждается перспективный план создания элементов СПО. В перспектив- ном плане указываются: название ИРЗ, ее заказчик и раз- работчик, а также срок создания задачи. Перспективный план, как правило, разрабатывается сроком на пять лет. На основа- нии перспективных планов разрабатываются годовые планы создания ИРЗ. 1 Принцип централизованной разработки ИРЗ может не учитываться организациями и фирмами, создающими одно- 42
уровневые задачи, предназначенные для применения в рам- ках данной организации и использующих автономные ЭВМ (например, персональные ЭВМ, не входящие в АСУ). При этом организации выступают в роли заказчика специального математического и программного обеспечения и осуществля- ют разработку (совершенствование) ИРЗ на основании своих перспективных планов. Отметим, что с насыщением органов управления современной ЭВТ следовать этому принципу ста- новится все труднее и на первое место при его реализации выдвигаются организационные мероприятия. Конкретность предназначения Принцип конкретности предназначения создаваемых за- дач и их комплексов предполагает необходимость разработки элементов СПО, специально предназначенных для автомати- зации решения конкретных задач управления. На практике достаточно часто встречаются ситуации, когда создается задача для проведения научных исследова- ний или в учебных целях, а затем предпринимаются попытки внедрения этой задачи (как правило, с некоторыми доработ- ками) в той или иной организации. Однако, поскольку исследовательские и учебные задачи создаются в целях проведения научных исследований или обучения, они не могут эффективно использоваться, а зача- стую являются просто непригодными для автоматизации уп- равления предприятиями и фирмами. Исследовательские за- дачи, обладая обычно высокими показателями достоверности результатов, имеют плохую оперативность расчетов и сла- бую эргономичность (не отвечают требованиям удобства и простоты работы должностных лиц с задачей). Учебные зада- чи имеют высокую оперативность расчетов и эргономичность, но достоверность получаемых результатов, как правило, яв- ляется недостаточной для использования при автоматизации управления на практике. Таким образом, исследовательские и учебные задачи нуждаются в существенной переработке перед их внедрени- 43
ем в промышленность. Такая переработка является достаточ- но трудоемкой, причем затраты на доработку задачи соизме- римы с затратами на создание новой задачи. Поэтому более правильным является путь, когда ИРЗ создается специально для автоматизации деятельности руко- водителя, должностных лиц предприятия или фирмы при решении конкретной задачи управления войсками. При этом, конечно, необходимо использовать отдельные математичес- кие алгоритмы, фрагменты программ, а также опыт созда- ния и использования исследовательских и учебных задач, являющихся прототипами разрабатываемых ИРЗ. Непосредственное руководство заинтересованных предприятий и фирм (организаций) Принцип непосредственного руководства и участия в со- здании ИРЗ и К предприятий и фирм (организаций), в инте- ресах которых они создаются, является важнейшим принци- пом, лежащим в основе всей технологии создания СПО и обес- печивающим создание качественных задач для автоматиза- ции управления персоналом фирм. Разработчики задачи, как правило, плохо представляют себе специфику управления персоналом, а также роль со- здаваемой задачи в процессе управления и требования, предъявляемые к ней. Учет этой специфики и соответствую- щих требований к задаче должен проводиться в процессе разработки ее оперативной постановки, являющейся совмест- ным документом заказчика и разработчика. Непрерывный контроль со стороны заказчика на всех этапах создания ИРЗ позволяет избежать неправильного тол- кования разработчиком положений и требований оператив- ной постановки задачи, своевременно устранять недостатки и тем самым ускорить создание и улучшить качество созда- ваемых задач. Кроме того, участие в разработке оперативной поста- новки и контроля результатов отдельных этапов создания ИРЗ 44
позволит должностным лицам, для которых создается зада- ча, глубже понять механизмы переработки информации в задаче. Понимание должностными лицами этих механизмов обеспечит грамотное и эффективное применение задач в про- цессе решения задач управления. Возможность перестройки Принцип обеспечения возможности перестройки задач в процессе их эксплуатации применительно к конкретной об- становке предполагает, что при создании ИРЗ необходимо более полно учесть возможные изменения обстановки, вне- шних условий, а также изменения характеристик и условий применения создаваемой продукции, которые вызовут необ- ходимость корректировки алгоритмов и программ ИРЗ. Конечно, заранее предусмотреть и оговорить какие-либо конкретные изменения (кроме плановых — например, мо- дернизации продукции или договорных ограничений) невоз- можно. Тем не менее при разработке задач необходимо учи- тывать возможные направления изменения тех или иных па- раметров, и создавать такие задачи, которые позволили бы с минимумом затрат проводить их корректировку. Непрерывное сопровождение СПО заказчиком и разработчиком Непрерывное сопровождение разработанных ИРЗ и К представителями заказчика и разработчика является основ- ным условием, обеспечивающим поддержание задач и их ком- плексов в готовности к применению. В функцию представите- лей заказчика при сопровождении ИРЗ и К входит обеспече- ние работоспособности используемых задач, а также анализ процесса их эксплуатации и выработка предложений по их совершенствованию. Представители разработчика при сопро- вождении ИРЗ устраняют недостатки, выявляемые в про- цессе эксплуатации, и проводят совершенствование задач в плане повышения их эксплуатационных характеристик. 45
Перечисленные выше основные принципы и основные требования являются нормативной базой при разработке и применении СПО в АИС (см. рис. 1.2.1). Централизо- ванность разработки Перспективное централизованное планирование Достоверность Конкретность предназначения Организация сопровождения ПО Оперативность Участие заказчика на всех этапах разработки Применение современных технологий программирования Соответствие уровню руководства Возможность перестройки СПО Разработка полной документации \ 1 Системный подход Непрерывность сопровождения СПО заказчиком и разработчиком Применение современных методов моделирования Обеспечение безопасности информации ПРИНЦИПЫ РАЗРАБОТКИ И ИСПОЛЬЗО- ВАНИЯ СПО ОРГАНИЗА- ЦИОННЫЕ МЕРОПРИЯТИЯ ТРЕБОВАНИЯ К СПО СПЕЦИАЛЬНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (СПО) Рис. 1.2.1. Требования к СПО и принципы его разработки Конечно, уровни обеспечения этих требований существенно зависят от класса задачи, ее назначения и особенностей при- менения. В зависимости от существа и особенностей примене- ния создаваемых задач перечень требований к ним может рас- ширяться или сужаться. Формирование конкретных требова- ний к создаваемым задачам осуществляется совместными уси- лиями представителей заказчика и разработчика на этапе раз- работки технического задания и утверждается заказчиком. 46
1.2.3. Содержание работ на этапах создания информационных, расчетных задач и их комплексов Порядок создания информационных, расчетных задач и их комплексов (ИРЗ и К) определен федеральными законами Российской Федерации, а также государственными стандар- тами. В создании задач и их комплексов участвуют две сторо- ны: заказчик и разработчик. Если разработчиков несколько, то среди них определяется головной разработчик и соиспол- нители. Возможно также существование нескольких заказ- чиков. Тогда среди них выделяется головной заказчик, а ос- тальные заказчики называются созаказчиками. Процесс создания ИРЗ и К в принципе одинаков и вклю- чает следующие этапы: ♦ этап разработки технического задания; ♦ этап эскизного проектирования; ♦ этап технического проектирования; ♦ этап рабочего проектирования. По решению заказчика, сформированному в техничес- ком задании (ТЗ), допускается объединение отдельных эта- пов разработки, изменение их содержания или введение дру- гих этапов. Продолжительность этапов, а также уровень, с которого начинается разработка задач и их комплексов, оп- ределяется в каждом конкретном случае, исходя из имеюще- гося научно-методического задела по данной проблеме. Каж- дый этап завершается в порядке, установленном ТЗ. В час- тности, итоги каждого этапа рассматриваются заказчиком. Для повышения оперативности взаимодействия заказчи- ка и разработчика, непрерывного контроля за деятельностью разработчика желательно из состава заказывающей органи- зации выделить сотрудника, которому поручается научно- техническое и организационное сопровождение всех видов работ по созданию ИРЗ и К. Этот сотрудник называется со- трудником сопровождения. 47
Этап разработки технического задания Техническое задание является исходным документом, устанавливающим основное назначение, технические харак- теристики и требования, предъявляемые к создаваемым задачам и их комплексам, а также порядок работ на всех этапах и сроки их проведения. ТЗ формируется заказчиком совместно с разработчиком. Для проведения работ на этом этапе заказчик может со- здавать рабочие группы из своих представителей, предста- вителей разработчика и других специалистов (экспертов) в зависимости от характера создаваемых задач и моделей. При разработке ТЗ осуществляется: ♦ проведение информационного обследования объекта автоматизации и уточнение функций и задач управле- ния, подлежащих автоматизации; ♦ определение необходимого состава комплекса ИРЗ; ♦ разработка оперативных постановок задач; ♦ формирование задания (определение разработчиков, сроков и порядка создания задач и их комплексов) и исходных данных. Проведение информационного обследования объекта ав- томатизации (подробно рассмотренное в подразд. 1.3) и уточ- нение функций и задач управления, подлежащих автоматиза- ции, являются необходимым элементом этапа разработки ТЗ. При информационном обследовании анализируется процесс функционирования объекта автоматизации по переработке ин- формации и определяются те элементы этого процесса, кото- рые могут или должны быть возложены на ЭВМ. Одним из результатов информационного обследования является состав комплекса задач, которые должны быть разработаны. Основным документом, содержащим всю информацию о создаваемой задаче (или комплексе задач), ее назначении и требованиях к ней, является оперативная постановка зада- чи (или комплекса задач), которая оформляется как обяза- тельное приложение к ТЗ. Содержание оперативных поста- новок задач и их комплексов рассмотрены в подразд. 1.4. 48
Техническое задание в целом и оперативные постановки задач подписываются головным разработчиком, согласовы- ваются с организациями-соисполнителями, органом управ- ления, на котором будет внедряться задача, и утверждают- ся заказчиком. Проведение разработки задач и их комплек- сов без утвержденного ТЗ не допускается. В процессе даль- нейших работ по созданию АИС или ее элементов при невоз- можности выполнения требований оперативной постановки она может корректироваться с разрешения заказчика на любом этапе создания и внедрения ИРЗ и их комплексов. Этапы эскизного и технического проектирования После утверждения заказчиком ТЗ разработчик присту- пает к этапу эскизного проектирования (ЭП), который часто объединяют с этапом технического проектирования (ТП). На этапах эскизного и технического проектирования осуществ- ляются следующие действия: ♦ определение принципов построения, состава и струк- туры технических и программных средств ИРЗ и К (этап ЭП); ♦ определение обобщенного алгоритма функционирова- ния, назначения и порядка работы элементов задач и их комплексов (этап ЭП); ♦ определение содержания и общих характеристик информационных связей между элементами задач (ком- плексов задач) (этап ЭП); ♦ определение состава необходимого программного обес- печения для создания задач и их комплексов (этап ЭП); ♦ выбор используемых математических методов и ма- тематическое описание моделей экономических опера- ций (этап ЭП); ♦ оценка возможности выполнения основных требова- ний оперативной постановки задачи (этап ЭП); ♦ разработка детальных алгоритмов задач и комплек- сов, их информационного и лингвистического обеспе- чения (этап ТП); 49
♦ проектирование и разработка необходимых баз дан- ных (этап ТП). Алгоритмы ИРЗ и К разрабатываются в строгом соответ- ствии с утвержденным ТЗ и оперативными постановками за- дач и являются определяющими документами для последую- щего написания программ. Схемы алгоритмов и программ выполняются в соответствии с нормативными требованиями. Этап рабочего проектирования На этапе рабочего проектирования в соответствии с раз- работанными ранее алгоритмами осуществляется разработка программ, их отладка и экспериментальная проверка (испы- тания) на ЭВМ и оформление документации по разработан- ной задаче (или комплексу задач). Перед сдачей отлаженных программ заказчику разработ- чик проводит их испытания с целью проверки соответствия программного продукта требованиям ТЗ. В процессе испыта- ний проверяются: ♦ достоверность результатов расчетов в различных ва- риантах исходных данных и, в частности, адекватность математических моделей операций; ♦ характер влияния различных исходных данных на ре- зультаты расчета (моделирования); ♦ надежность применяемых технических и программных средств защиты данных; ♦ оперативность полученных результатов расчетов; ♦ удобство работы с ЭВМ в процессе расчета или моде- лирования; ♦ качество разработанных алгоритмов и программ и т. д. Проверка достоверности результатов проводится на ва- риантах исходных данных с реальной или учебной информа- цией, обеспечивающих проведение всесторонней оценки по- лучаемых результатов путем сравнения с результатами про- веденных экономических операций. Для окончательной оцен- ки достоверности результатов расчетов (моделирования) мо- гут привлекаться компетентные эксперты. 50
Все работы по проверке готовности программного про- дукта проводятся на технической базе разработчика. В ра- боте по проверке (испытанию) ИРЗ и К участвуют сотруд- ник сопровождения. Обобщенные результаты эксперименталь- ной проверки разработанных задач и комплексов представля- ются заказчику вместе с отчетными материалами по про- граммному изделию, подготовленному к сдаче. На каждую ИРЗ и в целом комплекс задач оформляется отчетная документация в четырех частях: Часть 1. Оперативная постановка задачи. Часть 2. Алгоритмы задачи. Часть 3. Описание программы. Инструкция оператору- программисту по ее применению. Программы на магнитных носителях и их распечатки (тексты программ). Часть 4. Инструкция должностному лицу по использова- нию задачи (комплекса задач). Каждая часть документации оформляется отдельной кни- гой (или несколькими книгами). Части 1, 2, 4 используются специалистами органа управления при изучении сущности задачи и порядка работы с ней. В вычислительный центр (ВЦ) документация передается в полном объеме. Помимо указанной отчетной документации, после завер- шения каждого этапа разработки задачи (комплекса) разра- ботчиком выпускается и представляется заказчику отчет. Этим обеспечивается объективный контроль за ходом создания за- дач. Порядок, сроки выпуска и содержание таких отчетов оговариваются в ТЗ. Анализ отчетов и выдача заключений по результатам каждого этапа работ производится, как прави- ло, при активном участии сотрудника сопровождения. Приведенная выше этапность создания задач (комплек- сов задач) и отчетность в процессе их создания не является строго обязательной (кроме документации по готовым зада- чам и комплексам задач) и зависит от объема и сложности создаваемой задачи (комплекса задач). В любом случае обя- зательным документом является ТЗ, в котором оговаривает- ся как содержание этапов создания задач, так и состав до- кументов, разрабатываемых на каждом этапе. 51
1.2.4. Порядок внедрения информационных, расчетных задач и их комплексов Прием в эксплуатацию разработанных ИРЗ и К осуще- ствляется по приказу или директиве заказчика. Этим прика- зом заказчик назначает комиссию по приемке готового про- граммного продукта, определяет ее состав и задачи, а так- же сроки и порядок ее работы. В задачи комиссии входит: ♦ изучить документацию по задаче (комплексу задач), представленную разработчиком, определить ее каче- ство, соответствие требованиям ТЗ и другим норма- тивным документам; ♦ установить соответствие алгоритмов и программ требованиям ТЗ и оперативной постановке задачи; ♦ проверить достаточность мер по обеспечению безо- пасности обработки информации и ее выдачи на,авто- матизированные рабочие места должностных лиц; ♦ провести контрольные расчеты на внедряемой зада- че с целью проверки: работоспособности программ, достоверности, полноты и качества получаемых резуль- татов в широком диапазоне исходных данных; прак- тической пригодности и эффективности использова- ния задачи в деятельности командира и штаба по уп- равлению войсками; технологичности, трудоемкости и временных характеристик основных этапов подго- товки и ввода исходных данных, проведения расчетов и выдачи результатов; ♦ подготовить предложения о внесении изменений в ме- тодику работы должностных лиц с использованием ре- зультатов применения задачи; ♦ при необходимости определить перечень работ и про- должительность этапа опытной эксплуатации зада- чи (комплекса), а также составить план-задание на ее проведение. Приведенный выше перечень задач комиссии по реше- нию заказчика может быть расширен. 52
При приемке задачи (комплекса) головной разработчик обязан: ♦ не позднее чем за два месяца до начала работы комис- сии представить заказчику и организациям, определен- ным заказчиком, по одному экземпляру документации в согласованном с заказчиком объеме; ♦ представить эталонные программы с контрольными вариантами решений на машинных носителях в ВЦ, на котором планируется внедрение задачи (комплек- са); ♦ выполнить контрольные расчеты по указанию заказ- чика и принять участие в анализе полученных резуль- татов; ♦ устранить недостатки, выявленные в процессе при- емки задачи (комплекса). По указанию заказчика в приемке задачи (комплекса) могут принять участие заинтересованные фирмы, где пла- нируется использование внедряемых задач и их комплексов. В этом случае заинтересованные организации обязаны: ♦ принять участие в подготовке контрольных вариан- тов решений; ♦ оценить возможности задачи, обеспечить проверку ее работоспособности в условиях, соответствующих осо- бенностям работы данного предприятия; ♦ представить заказчику в установленные им сроки пред- ложения и замечания о результатах проверки задачи (комплекса). Вычислительный центр, на котором планируется внедре- ние задачи, предоставляет технические средства, участву- ет в контрольных решениях и проверяет эксплуатацион- но-технические характеристики задачи (комплекса). По результатам работы комиссия представляет заказчи- ку акт по приемке задачи (комплекса). Копия акта комиссии высылается в адрес головного разработчика и является зак- лючением заказчика на выполненное ТЗ. 53
Информационные и расчетные задачи (или их комплекс) допускаются к штатной эксплуатации, если они отвечают тре- бованиям ТЗ и являются работоспособными в реальных усло- виях профессиональной деятельности. ИРЗ (или их комплекс) принимается в опытную эксплуатацию, если в ходе приемки выявлена необходимость в их доработках, не оказывающих существенного влияния на достоверность результатов расче- тов. Схема порядка внедрения ИРЗ и их комплексов пред- ставлена на рис. 1.2.2. Для организации опытной эксплуатации заказчиком ут- верждается план-задание, в котором указываются: ♦ сроки опытной эксплуатации; ♦ содержание и порядок работы; ♦ меры по обеспечению безопасности обработки инфор- мации; ♦ способы оценки эффективности применения данной за- дачи (комплекса) в практической работе предприятия. В ходе опытной эксплуатации организуется обучение персонала фирмы порядку работы с задачей (комплексом), изучение ее возможностей и проведение оценки эффективно- сти ее применения. В практике должностных лиц в реальных условиях эксплуатации оценивается надежность средств и методов защиты информации, проводятся все необходимые доработки задачи. Головной разработчик обязан участвовать на всех этапах опытной эксплуатации и устранять недостатки, выявленные как в процессе приемки задачи, так и в процессе опытной эксплуатации. Опытная эксплуатация ИРЗ и их комплексов заверша- ется актом, разрабатываемым фирмой, в котором должна использоваться задача. Акт подписывается всеми участника- ми опытной эксплуатации и представляется заказчику. Прием задачи (комплекса) осуществляется по директиве (приказу) заказчика. Директивой (приказом) устанавливается порядок применения задачи (комплекса) соответствующими должностными лицами. 54
Приказ (директива) Заказчика о приеме ИРЗ и К Подготовка к приему ИРЗ и К Заказчик j______ Разработчик создает комиссию по при- ему ИРЗ и К; привлекает заинтересованные фирмы (при необходимости) представляет документа- цию; представляет эталон- ные программы; представ- ляет результаты конт- рольных расчетов Прием ИРЗ и К в эксплуатацию анализ полноты и качества документации по задаче; установление соответствия алгоритмов и программ требованиям техни- ческого задания; проверка достаточности мер по обеспечению безопасности информации; проверка работоспособности программ в широком диапазоне исходных данных, достоверности, полноты и качества получаемых результатов; проверка технологичности, оперативности и трудоемкости работы с за- дачей; подготовка предложений о внесении изменений в порядок работы долж- ностных лиц с использованием задачи; разработка плана задания на опытную эксплуатацию задачи (при необ- ходимости) Оформление результатов приема ИРЗ и К подготовка акта комиссии о приеме задачи (комплекса задач); подготовка директивы Заказчика о приеме задачи (комплекса задач) в эксплуатацию (или об организации опытной эксплуатации) Рис. 1.2.2. Порядок внедрения ИРЗ и К 55
1.2.5. Порядок использования информационных, расчетных задач и их комплексов в практике работы органа управления Применение ИРЗ и К организуется и осуществляется на основании указаний руководителя предприятия, распо- ряжений вышестоящих организаций и руководящих доку- ментов. Документы, регламентирующие применение ИРЗ и К, должны включать: ♦ цели и сроки применения каждой задачи; ♦ порядок проведения расчетов (моделирования) в раз- личных условиях обстановки, подготовки исходных данных, анализа промежуточных и конечных резуль- татов, выдачи их в соответствующие органы управле- ния и использования результатов решения в процессе управления; ♦ порядок обобщения опыта применения задач и их ком- плексов, разработки и реализации предложений по со- вершенствованию методов работы с использованием результатов расчетов; ♦ список сотрудников, выделенных для оперативного со- провождения задач и их комплексов; ♦ перечень мероприятий по исключению утечки инфор- мации в процессе производства расчетов и анализа их результатов; ♦ порядок подготовки и допуска персонала фирмы к ра- боте с задачей и с использованием результатов расче- тов, а также порядок проведения необходимых перио- дических тренировок с лицами, допущенными к рабо- те с задачей; ♦ перечень мероприятий по поддержанию в работоспо- собном состоянии средств программного, техничес- кого и других видов обеспечения. Ответственность за внедрение, освоение оперативным составом, применение, совершенствование задач и их комп- 56
лексов, а также обеспечение безопасности информации в про- цессе ее обработки возлагается на руководителя соответ- ствующего предприятия. Ответственность за поддержа- ние задач и их комплексов в работоспособном состоянии воз- лагается на начальника ВЦ. Оперативное сопровождение задач и их комплексов осу- ществляется выделенными для этой цели сотрудниками фир- мы и включает: ♦ поддержание программ и средств их информационного обеспечения в работоспособном состоянии; ♦ подготовку предложений по совершенствованию опе- ративных постановок, алгоритмов и инструкций по ис- пользованию задач и их комплексов в связи с измене- нием взглядов на проведение экономического анализа, появлением новых технических автоматизированных средств, новой организационной структуры предприя- тия, отрасли и т. д.; ♦ подготовку рекомендаций по совершенствованию ме- тодики работы фирмы с использованием разработан- ных ИРЗ и К. В процессе эксплуатации задач и их комплексов разра- ботчик осуществляет научно-техническое сопровождение (авторский надзор), которое включает совершенствование математических методов, алгоритмов, программ и инфор- мационного обеспечения в целях повышения оперативно-тех- нических характеристик задач и их комплексов. 1.3. Информационное обследование профессиональной деятельности В настоящее время вопросам изучения и развития авто- матизации профессиональной деятельности придается боль- шое значение в нашей стране и за рубежом. Причин здесь несколько. Прежде всего — это низкие темпы роста произ- водительности труда людей, занимающихся переработкой 57
информации (в том числе и управлением) по сравнению с производительностью труда в производстве. В развитых стра- нах около 50% трудоспособного населения занято в сфере переработки информации и, конечно, низкая производитель- ность их труда является существенным фактором, сдержи- вающим общественный прогресс. Следующей важной причиной является постоянное ус- ложнение информационных процессов с одновременным по- вышением требований к оперативности выработки решений различного уровня. И, наконец, появление и широкое распространение в последнее время новых программных, технических средств и информационных технологий требуют разработки новых ме- тодов их использования и вообще новых методов организации управления профессиональной деятельностью. Таким образом, вопросы автоматизации профессиональ- ной деятельности являются в настоящее время достаточно актуальными и не до конца проработанными. В данном пунк- те эти вопросы будут рассмотрены применительно к пробле- ме автоматизации управленческой деятельности как наибо- лее сложной для любого специалиста в области экономики, т. е. описаны типы объектов автоматизации в системе управ- ления персоналом, а также характеристики известных под- ходов к автоматизации управленческой деятельности и поря- док проведения информационного обследования управленчес- кой деятельности. 1.3.1. Объекты автоматизации в системе организаций Рассматривая вопросы автоматизации систем управления, прежде всего необходимо четко определить, что мы собира- емся автоматизировать, т. е. определить объекты автоматиза- ции [54]. Для определения объектов автоматизации в системе уп- равления персоналом необходимо проанализировать процесс 58
ее функционирования, ее состав и решаемые задачи. В ре- зультате анализа должно быть получено описание процесса переработки информации в системе управления, определены элементы этого процесса и связи между ними. Под системой управления персоналом понимается сово- купность функционально связанных органов управления, пун- ктов управления, систем связи, систем и средств автомати- зации управления войсками, а также специальных систем, обеспечивающих сбор, обработку и передачу информации. Основу системы управления составляют органы управле- ния, которые вырабатывают управляющие воздействия на войска (приказы, директивы) и тем самым осуществляют уп- равление. В состав органов управления включаются: правле- ние, дирекция, администрация, управления, отделы и дру- гие органы. Органы управления размещаются на пунктах управления и, используя системы связи, системы и средства автоматизации управления, а также специальные системы, выполняют свои функции. В процессе выполнения своих функций органы управле- ния осуществляют управленческую деятельность, которую можно рассматривать как процесс переработки информации. Действительно, орган управления получает входную инфор- мацию по различным каналам (приказы, директивы выше- стоящих органов управления, донесения нижестоящих орга- нов управления, а также другую информацию), анализирует полученную информацию, определенным образом преобразу- ет ее и создает новую информацию, которую по каналам связи передает в подчиненные и вышестоящие органы управления (приказы, распоряжения подчиненным войскам, донесения вышестоящим органам управления). Управленческая деятельность может быть представлена как совокупность определенным образом связанных задач управления. Количество, сложность задач управления, ре- шаемых в процессе управленческой деятельности, а также требования по оперативности их решения могут быть раз- личными в различных условиях обстановки. Однако перечень 59
и содержание задач управления, как правило, являются ста- бильными — неизменяемыми или слабо изменяемыми — в процессе жизнедеятельности организации на достаточно боль- шом интервале времени. Результатами решения задачи уп- равления являются управляющие воздействия на подчинен- ных и предоставление требуемой информации вышестоящим органам управления, которые оформляются в виде докумен- тов (приказов, директив, распоряжений, а также донесений, отчетов и справок). Задачи управления решаются должностными лицами ор- ганов управления и так же, как управленческая деятельность, представляют собой процесс переработки информации. Анализ процесса переработки информации при решении какой-либо задачи управления позволяет выделить в нем три типа взаимосвязанных информационных процедур, заключа- ющихся в реализации того или иного механизма переработки входной информации в конкретный результат и индивиду- ально выполняемых должностными лицами. 1. Полностью формализуемые информационные процеду- ры, при выполнении которых алгоритм переработки информа- ции остается неизменным и полностью определен. К таким про- цедурам относятся поиск, учет, хранение, передача информа- ции, печать документов, расчет заработной платы, подведе- ние итогов деятельности предприятий и фирм, расчет на мо- дели показателей эффективности деятельности предприятий и фирм и т. д. Полностью формализуемые процедуры лучше всего поддаются автоматизации с применением ЭВМ. Они мо- гут выполняться без участия или с минимальным участием человека и не требуют высокого уровня его подготовки. 2. Неформализуемые информационные процедуры, при выполнении которых создается новая уникальная информа- ция, причем алгоритм переработки исходной информации неизвестен. Принципиально существуют две процедуры та- кого типа: формирование множества альтернатив выбора (на- пример, вариантов выбора инвестиционных проектов) и соб- ственно выбор одного варианта из данного множества. Как 60
правило, такие процедуры реализуются должностными ли- цами с использованием результатов выполнения информаци- онных процедур первого типа. Требования по знанию про- цессов функционирования предприятий и фирм к лицам, вы- полняющим неформализуемые информационные процедуры, очень высоки. 3. Плохо формализуемые информационные процедуры, при выполнении которых алгоритм переработки информации мо- жет изменяться и полностью не определен. К плохо форма- лизуемым процедурам относятся задачи планирования, оце- нивания эффективности вариантов построения финансовой политики фирмы и т. д. Плохо формализуемые процедуры не могут выполняться без участия человека. К человеку, выпол- няющему плохо формализуемые информационные процеду- ры, предъявляются высокие требования по знанию процес- сов функционирования экономических систем и алгоритмов переработки информации. Они выполняются одним должнос- тным лицом и включают, как правило, несколько полностью формализуемых и неформализуемых процедур, порядок про- ведения которых определяет должностное лицо, исходя из особенностей решаемой задачи управления в каждом конк- ретном случае. Таким образом, основными типами информационных про- цедур, индивидуально выполняемых должностными лицами, являются полностью формализуемые и неформализуемые про- цедуры. Введение понятия плохо формализуемой процедуры удобно как промежуточное описание процессов переработки информации, а также для выделения в этих процессах доста- точно цельных элементов, выполняемых одним или несколь- кими должностными лицами (например, оценка эффективнос- ти проводимой финансовой операции, разработка варианта плана вывода фирмы из кризисного состояния и т. д.). Необходимо отметить, что деление процесса переработ- ки информации на отдельные информационные процедуры не является абсолютным, раз и навсегда определенным. Это деление соответствует степени изученности объекта управ- 61
ления и системы управления. По мере изучения объекта уп- равления и получения новой информации о нем неформали- зуемые информационные процедуры могут быть сначала за- менены плохо формализуемыми, а в дальнейшем — и полно- стью формализуемыми информационными процедурами. Имен- но такая последовательная замена информационных проце- дур, выполняемых в процессе разработки управленческих решений, лежит в основе одного из подходов к автоматиза- ции управленческой деятельности, о чем будет сказано ниже. Таким образом, основу функционирования системы уп- равления предприятиями и фирмами составляет управлен- ческая деятельность органов управления, которая осуществ- ляется должностными лицами и включает решение связан- ных между собой задач управления. Отдельные задачи уп- равления и управленческая деятельность в целом представ- ляют собой процесс переработки информации. Переработку информации осуществляют должностные лица органов уп- равления путем выполнения информационных процедур. Уп- равленческую деятельность органов управления и должнос- тных лиц, задачи управления, а также информационные процедуры в дальнейшем мы будем называть элементами управленческой деятельности, осуществляемой системой управления. Проведенный выше анализ функционирования системы управления персоналом позволяет выделить иерархически связанные объекты автоматизации как элементы управлен- ческой деятельности, осуществляемой системой управления. 1. Управленческая деятельность органов управления и должностных лиц. 2. Задачи управления персоналом, решаемые руковод- ством фирмы в целом или должностными лицами (должност- ным лицом) в процессе управленческой деятельности. 3. Полностью и плохо формализуемые информационные процедуры, индивидуально выполняемые должностными ли- цами (возможно, с использованием различных технических устройств) при решении различных задач управления. 62
Уровень автоматизации управленческой деятельности, задач управления и информационных процедур может быть различным. Он зависит от возможностей по разработке про- граммного обеспечения, имеющихся технических средств, а также от других причин, в том числе и чисто психологичес- ких, связанных с готовностью и желанием должностных лиц использовать в своей работе ЭВМ. Однако каждому объекту автоматизации можно поставить в соответствие типовое программное средство, которое целесообразно применять при автоматизации конкретного элемента процесса переработки информации. Так, средством автоматизации информационных проце- дур первого типа являются ИРЗ. Средством автоматизации информационных процедур третьего типа и задач управле- ния могут стать комплексы ИРЗ, а также АИС класса ИВС (ИРС, САПР, ПОИС, МЦ). Средством автоматизации управ- ленческой деятельности должностных лиц является СППР. Автоматизация управленческой деятельности органа управ- ления должна осуществляться в рамках АСУП. 1.3.2. Характеристика подходов к автоматизации управленческой деятельности Информационное обследование, как правило, проводит- ся в ситуации, когда существуют какие-либо недостатки в процессе управления (например, плохое качество управле- ния или плохая оперативность принятия решений), и руко- водство хочет определить возможность устранения этих недостатков за счет использования средств автоматизации управления. Решать эту задачу необходимо путем анализа процесса управления с целью выделения в нем возможных объектов автоматизации, определения информационных связей между ними и установления необходимого уровня автоматизации информационной деятельности, способного обеспечить реше- ние возникшей проблемы. 63
В такой постановке задача автоматизации управления ставилась и решалась в нашей стране и за рубежом с начала 70-х гг. XX в., причем в качестве объекта автоматизации вы- биралась, как правило, управленческая деятельность какого- либо органа (органов) управления. Именно с этого времени стали появляться проекты “больших” АСУ, таких как АСУ предприятия, АСУ отрасли и т. п. Анализ практики создания АСУ позволяет выделить сло- жившиеся и используемые в настоящее время подходы к проектированию систем автоматизации управления [54]. Первый подход базируется на принципе построения АСУ “от фотографии”, т. е. по принципу “автоматизировать то, что есть”. Такие АСУ принято называть фотографически- ми. Согласно этому принципу анализируется уже существу- ющая система управления и строится модель реализуемой ею управленческой деятельности без изменения структур и за- дач элементов существующей системы управления. Этот подход является наиболее простым и обеспечивает создание эффективной АСУ при автоматизации управленчес- кой деятельности, которая хорошо изучена и поддается фор- мальному описанию. Примером органа управления, осуществ- ляющего хорошо формализуемую деятельность, является, например, бухгалтерия, деятельность которой в целом, а так- же деятельность ее отдельных должностных лиц, хорошо изучена и практически полностью регламентирована общими правилами и соответствующими документами. Проблемы в таких органах управления связаны, как правило, с большой долей рутинных работ, которые хорошо автоматизируются. Если же предполагается автоматизировать управление сложным, плохо изученным объектом, управление которым осуществляется в условиях неполной и неточной исходной информации, применение фотографической АСУ может ока- заться малоэффективным. Проблемы в таких органах управ- ления могут быть связаны с неправильным определением це- лей и задач управления и, как следствие, нерациональной его организацией. Поэтому применение фотографической АСУ 64
в “неправильной” системе управления, естественно, не даст желаемого эффекта. Кроме того, необходимо учесть, что применение средств автоматизации требует, как правило, изменения состава и структуры системы управления. Иначе АСУ может оказаться неэффективной. Попыткой устранения недостатков, присущих первому подходу к автоматизации организационного управления, яви- лась разработка второго подхода, базирующегося на принци- пе построения АСУ “от модели”, т. е. по принципу “делать так, как должно быть”. Такие АСУ будем называть модель- ными. Согласно этому принципу проводится анализ объекта управления, а также существующей системы управления и строится модель деятельности новой системы управления, способной решить возникшие проблемы управления объек- том. Таким образом, при этом подходе предполагается авто- матизировать управление с одновременным изменением (при необходимости) существующей структуры системы управле- ния, а также целей и задач управления. Построение модельных АСУ несомненно улучшает каче- ство управления, однако создание адекватной модели дея- тельности оптимальной системы управления сложным объек- том на начальном этапе автоматизации в большинстве случа- ев является практически неразрешимой задачей. Практика показала, что в лучших разработках создание АСУ осуществлялось на основе третьего подхода — много- шагового, основанного на принципе “от потребностей прак- тики”. Согласно этому принципу на начальном этапе автома- тизируется деятельность конкретных должностных лиц пос- ледовательно, начиная с автоматизации простейших инфор- мационных процедур путем разработки отдельных И и РЗ. Созданные И и РЗ по мере их накопления, оценки эффек- тивности их использования и корректировки объединяются в АИС, автоматизирующие решение задач управления и уп- равленческой деятельности в целом. При такой автоматиза- ции управленческой деятельности уточнение целей и задач 65
управления, а также изменение состава и структуры систе- мы управления происходит постепенно, а автоматизация вы- полнения информационных процедур проходит всестороннюю проверку еще в процессе создания АСУ. Кроме того, долж- ностные лица постепенно обучаются работе с ЭВМ, и в их сознании укрепляется уверенность в необходимости исполь- зования ЭВМ в практической работе. Все сказанное выше обеспечивает успех автоматизации управленческой деятель- ности. Принцип создания АСУ “от потребностей практики” базируется на трех основных (отчасти противоречивых) тре- бованиях, предъявляемых к процессу создания средств авто- матизации управленческой деятельности: ♦ внедрение средств автоматизации должно быть поэтап- ным (от простого к сложному), но при этом уже на начальных этапах в упрощенном виде необходимо ви- деть и учитывать конечные цели автоматизации; ♦ необходимо учитывать готовность организационной структуры и должностных лиц к использованию средств автоматизации в своей работе и стараться в первую очередь планировать автоматизацию тех эле- ментов управленческой деятельности, где эта автома- тизация даст максимальный эффект либо по про- стоте и оперативности решения практических задач, либо по качеству их решения; ♦ требуется свести к минимуму на первых этапах авто- матизации попытку полного учета организационной ин- фраструктуры органа управления, и сосредоточить уси- лия на автоматизации деятельности конкретных дол- жностных лиц. Каждый из перечисленных выше подходов может быть применен при создании конкретной АСУ. Если цели и задачи системы управления точно определены и управленческая де- ятельность хорошо формализуется, целесообразно строить АСУ по принципу “от фотографии”. Если есть возможность разработать модель оптимальной системы управления, целе- сообразно строить АСУ по принципу “от модели”. Если ав- 66
томатизация управления находится на начальном этапе, в лю- бом случае целесообразно создавать АСУ в соответствии с принципом “от потребностей практики”, и, по мере на- копления И и РЗ, автоматизирующих отдельные информа- ционные процедуры, приступать к созданию фотографичес- ких или модельных АСУ. 1.3.3. Порядок проведения информационного обследования управленческой деятельности Информационное обследование профессиональной (управ- ленческой) является творческим процессом и не имеет жест- кого алгоритма его проведения. Можно указать только ос- новные этапы работ и их целесообразную последовательность. В информационном обследовании участвуют должност- ные лица, деятельность которых автоматизируется, и специалисты по автоматизации управленческой деятельно- сти, которых мы в дальнейшем будем называть исследовате- лями. Основными приемами при информационном обследова- нии являются изучение исследователем документации, рег- ламентирующей деятельность органа управления или долж- ностного лица, а также проведение экспертного опроса кон- кретных должностных лиц. Опрос должностных лиц чаще всего осуществляется в форме интервью. Вопросы интервью могут быть самыми раз- личными и зависят от уяснения исследователем особенностей автоматизируемой управленческой деятельности. В процессе информационного обследования опросы долж- ностных лиц могут повторяться (чередуясь по мере необхо- димости с изучением документации) до полного уяснения автоматизируемой управленческой деятельности и составле- ния ее информационной модели. Конечными целями информационного обследования яв- ляются: ♦ выявление (уточнение) объектов автоматизации в системе управления; 67
♦ построение их информационных моделей; ♦ составление перечня программных средств и баз дан- ных, необходимых для автоматизации управленческой деятельности; ♦ определение порядка работы должностных лиц с ис- пользованием средств автоматизации; ♦ проведение предварительной оценки повышения про- изводительности и качества управленческой деятель- ности должностных лиц с использованием предлагае- мых средств автоматизации; ♦ оценка предполагаемых затрат различных ресурсов, включая необходимый состав технических средств. Важнейшей целью информационного обследования явля- ется разработка информационных моделей управленческой деятельности и отдельных ее элементов (объектов автомати- зации). Информационная модель управленческой деятельности (объекта автоматизации) представляет собой описание инфор- мационных потоков, определяющих основное содержание дея- тельности органа управления и (или) должностных лиц. Кон- кретный вид информационной модели определяется типом объекта автоматизации: при автоматизации деятельности органа управления или должностного лица — это перечень взаимосвязанных задач управления; при автоматизации зада- чи управления — перечень взаимосвязанных информационных процедур; при автоматизации информационной процедуры — это описание трех взаимосвязанных элементов: ♦ входной информации, которая может (или должна) ис- пользоваться в процессе реализации данной процедуры; ♦ выходной информации, которая должна получаться в результате выполнения процедуры; ♦ механизмов переработки входной информации в выход- ную. Информационные модели элементов управленческой де- ятельности, как правило, являются достаточно обобщенны- ми, не содержащими детализации описаниями информаци- онных связей между объектами автоматизации и механизмов переработки информации. Детализация описания информаци- 68
онных связей между объектами автоматизации до конкрет- ных параметров и документов, а также конкретных механиз- мов переработки информации осуществляется в процессе со- здания ИРЗ и К на этапе разработки технического задания и, что особенно важно, оперативных постановок задач. Содержание информационной модели, помимо типа объекта автоматизации, зависит от принятого подхода к ав- томатизации управленческой деятельности и может описы- вать как существующий, так и требуемый (улучшенный) со- став входной и выходной информации, а также механизм переработки информации. Окончательный вывод об адекват- ности информационной модели объекту автоматизации долж- ны делать должностные лица органа управления, деятель- ность которого автоматизируется. Они знакомятся с инфор- мационной моделью и вносят, при необходимости, свои кор- рективы. Построение информационной модели начинается с оп- ределения информации, которая должна получаться в резуль- тате управленческой деятельности в рамках рассматривае- мого объекта автоматизации (выходной информации объекта автоматизации). Как правило, информация, которая должна получаться в результате управленческой деятельности, хорошо известна должностным лицам для любого типа объекта автоматиза- ции, и ее получение не вызывает осложнений. Она составля- ет основу разрабатываемых в органе управления документов и поэтому в принципе может быть детализирована до конк- ретных параметров. После того как четко определена выходная информация, следует переходить к определению исходных данных (вход- ной информации) для решения задачи, а затем — к наиболее сложной части информационной модели — описанию меха- низмов переработки входной информации в выходную. С учетом приведенного выше порядка построения ин- формационной модели рассмотрим подробно содержание и порядок создания информационных моделей различных объек- тов автоматизации. 69
1.3.4. Информационные модели объектов автоматизации Как было отмечено выше, информационные модели де- ятельности руководителей фирм и должностных лиц включа- ют перечень задач управления, решаемых в процессе этой деятельности, а также выходную и входную информацию, необходимую для решения соответствующей задачи. Кроме того, необходимо указание на подчиненность и относитель- ную важность задач, входящих в информационную модель. Относительная важность задач определяется из суще- ства и целей управленческой деятельности. Подчиненность задач проявляется в том, что отдельные результаты реше- ния одних задач могут являться исходными данными для ре- шения других. Дальнейшая детализация информационных моделей дея- тельности должностных лиц и органов управления осуществ- ляется путем построения информационных моделей входя- щих в них задач управления. Информационные модели задач управления формулиру- ются как совокупности информационных процедур и связей между ними. Информационные модели задач управления, как правило, включают плохо формализуемые процедуры, ко- торые в дальнейшем должны исследоваться с целью постро- ения их информационных моделей. Методика построения ин- формационных моделей задач управления включает следую- щие упорядоченные этапы работ. Этап 1. Определение выходных данных. Выходные дан- ные должны быть конкретизированы до параметров, кото- рые целесообразно объединить в группы. Каждая группа со- держит параметры, тесно связанные между собой и опреде- ляемые совместно. Группы выходных параметров, как пра- вило, определяются последовательно, поэтому необходимо указать последовательность формирования групп этих пара- метров. Группы параметров должны быть объединены в доку- менты, которые вырабатываются в процессе управления. 70
Последовательность определения перечня выходных дан- ных может быть различной: сначала формируется перечень выходных документов, а затем — перечень определяющих их параметров (групп параметров), или наоборот. Этап 2. Определение информационных процедур, резуль- татом которых являются выделенные группы выходных па- раметров объекта автоматизации. Группы выходных параметров могут определяться всеми типами информационных процедур — полностью формали- зуемых, плохо формализуемых и неформализуемых. При от- сутствии автоматизации группы выходных параметров опре- деляются, как правило, с использованием неформализуемых и простейших формализуемых процедур (расчетов). В про- цессе информационного обследования неформализуемые про- цедуры могут заменяться на плохо формализуемые, что при- водит к существенному изменению деятельности должност- ных лиц в процессе управления. Например, в задаче планирования финансовой деятель- ности предприятия одним из выходных документов является план хозяйственно-финансовой деятельности, содержащий группы параметров, определяющих: ♦ анализ объема производства и реализации продукции; ♦ анализ оборотного капитала; ♦ факторный анализ прибыли и т. д. Разработка указанного плана начинается с анализа из- менений в составе и структуре активов и пассивов предпри- ятия, далее анализируется объем и структура выпускаемой продукции, производится анализ себестоимости продукции и издержек обращения и т. д. Наиболее простой информационной моделью является модель полностью формализуемой информационной проце- дуры, включающей входные и выходные данные, а также алгоритм (механизм) переработки информации. Поскольку по определению известен алгоритм переработки информации в рамках такой процедуры, при построении ее информацион- ной модели принципиальных трудностей не возникает. Ин- 71
формационная модель полностью формализуемой процедуры не обязательно должна включать детальный алгоритм пере- работки информации. Достаточным является его словесное описание (например, указание на необходимость использо- вания известных прикладных математических методов), из которого можно сделать вывод о возможности построения такого алгоритма. Информационная модель неформализуемой информаци- онной процедуры включает выходные параметры (то, что должно получаться в результате интеллектуальной деятель- ности должностных лиц), тип решаемой задачи (формирова- ние множества вариантов или выбор), а также необходимые исходные данные для решения задачи. Основная сложность создания модели неформализуемой информационной процедуры состоит в определении необхо- димых для ее выполнения исходных данных. Окончательное решение о составе необходимых исходных данных принима- ет должностное лицо, деятельность которого автоматизиру- ется. В задачу исследователя входит выяснение у должност- ного лица перечня необходимых для проведения неформали- зуемой процедуры исходных данных. Кроме того, по результатам анализа процесса управле- ния исследователь может предложить должностному лицу дополнительные данные, которые могут быть получены пу- тем выполнения полностью или плохо формализуемых про- цедур и которые могут оказаться полезными при выполне- нии неформализуемой процедуры. Если должностное лицо согласится с полезностью предложенной дополнительной ин- формации, в информационную модель задачи управления включается плохо формализуемая информационная проце- дура вместо рассматриваемой первоначально неформализу- емой информационной процедуры. Построение информационной модели плохо формализу- емой информационной процедуры означает практически адек- ватную замену данной процедуры совокупностью полностью формализуемых и неформализуемых информационных про- цедур. Поскольку плохо формализуемая информационная 72
процедура при автоматизации деятельности должностных лиц рассматривается как альтернатива существующей неформа- лизуемой процедуры (чаще всего — процедуры формирова- ния вариантов решения поставленных задач), построение ее информационной модели может вызвать существенные труд- ности. Трудности эти обусловлены необходимостью детально- го изучения процесса боевых действий и управления ими. В заключение отметим, что в настоящее время получи- ли достаточно широкое распространение (в том числе и в России) так называемые CASE-методологии и технологии, позволяющие системно подойти к разработке программного обеспечения АИС различного назначения на всех этапах его жизненного цикла. 1.4. Оперативная постановка задачи Одним из важнейших элементов этапа формирования тех- нического задания является разработка оперативных поста- новок задач и их комплексов. Оперативная постановка задачи (комплекса задач) является основным документом, которым должен руководствоваться разработчик задачи при ее созда- нии. Поэтому качество создаваемого программного обеспече- ния, его полезность в деятельности должностных лиц орга- нов управления фирмы существенно зависит от продуманно- сти, полноты и корректности материалов, содержащихся в оперативной постановке [54]. Оперативная постановка разрабатывается совместно пред- ставителями заказчика и разработчика на основании исход- ных данных, определяемых заказчиком. По сути она пред- ставляет собой соглашение между заказчиком и разработчи- ком о том, каким должно быть разрабатываемое программ- ное обеспечение. При этом заказчик должен быть уверен, что разработчик правильно уяснил его требования, а разработ- чик должен быть уверен, что он сможет выполнить требова- ния заказчика. 73
Объем, содержание и форма представления материалов оперативных постановок, как правило, определяются норма- тивными документами [13, 14]. В некоторых случаях содер- жание оперативной постановки задачи может отличаться от общепринятого (тогда оно дополнительно согласуется между заказчиком и разработчиком). Однако можно указать основ- ные элементы, которые обязательно должны содержаться в оперативной постановке математической модели, информа- ционной или вычислительной задачи. 1.4.1. Оперативная постановка математической модели Оперативная постановка математической модели должна отражать восемь типовых вопросов. 1. Наименование модели. 2. Место и роль модели при автоматизации управления предприятием. Описание места модели при управлении фирмой долж- но включать перечень органов управления и (или) должност- ных лиц, для которых разрабатывается модель, и вычисли- тельных центров, на которых планируется ее внедрение, а также ситуации в процессе управления, при которых необ- ходимо использовать модель. Короче говоря, в данном пунк- те необходимо указать, кто, где и в каких условиях будет работать с моделью. Описание роли модели при автоматизации управления персоналом фирмы должно включать указание характерис- тик процесса управления, которые должны быть улучшены с использованием создаваемой модели (например, повыше- ние качества решений руководителя, повышение оператив- ности планирования операции, снижение трудоемкости под- готовки документов и т. д.). 3. Целевая направленность модели. При раскрытии этого пункта необходимо указать прак- тические вопросы управления фирмой, которые должны ре- шаться с использованием результатов моделирования. 74
4. Вербальная модель операции. Вербальная модель операции представляет собой вербаль- ное (словесное) описание моделируемой операции и разрабаты- вается в основном усилиями представителей заказчика. Она необходима разработчику для создания математической моде- ли операции. В вербальной модели должны быть описаны су- щество моделируемой операции и ее основные особенности. Для обеспечения полноты описания моделируемой опера- ции вербальная модель включает следующие элементы. А. Цель (цели) операции — желаемый результат проведе- ния операции моделируемой системой, а также возможная цель (цели) конкурента в операции. Б. Состав элементов системы, участвующей в операции, и конкурирующей системы с детализацией, которая необхо- дима при моделировании. Необходимый уровень детализации описания состава элементов системы определяется предста- вителями заказчика, исходя из их мнения о степени влияния тех или иных элементов системы на результат операции. В отдельных случаях, когда влияние того или иного эле- мента системы на результат операции неизвестно, необходи- мо проведение специального исследования по оценке этого влияния. В. Динамика развития операции в пространстве и вре- мени, основные этапы операции. При описании динамики развития операции необходимо прежде всего указать исходное состояние моделируемой си- стемы и конкурента (возможные варианты исходного состоя- ния). Далее должна быть описана последовательность действий (или варианты последовательностей этих действий), участву- ющих в операции сторон, обеспечивающих достижение сво- их целей. В зависимости от существа операции в процессе ее про- ведения целесообразно выделять этапы операции. Г. Подцели моделируемой системы и конкурента на каж- дом этапе операции. Возможно также указание влияния ре- зультатов отдельных этапов операции на результат операции в целом. 75
Выделение этапов и подцелей операции позволит разра- ботчику модели глубже уяснить существо операции, предло- жить обоснованную структуру модели и систему допущений. Например, в операции по внедрению на рынок нового образца продукции можно выделить этап маркетинга и этап разработки, производства и поставки в торговые организа- ции необходимых объемов продукции. Очевидно, что для каж- дого из этих этапов можно выделить собственные цели, и каждый из них по-разному влияет на результат (успех) опе- рации в целом. Д. Возможные стратегии поведения моделируемой сис- темы и конкурента в операции и на отдельных ее этапах. Стратегии поведения моделируемой системы и конкурента являются определяющими для моделирования управления системой в операции и поведения конкурента. Например, в задаче моделирования конкурентной борь- бы следует учесть такие стратегии конкурента, как сниже- ние цены на свою аналогичную продукцию, проведение нео- жиданной рекламной акции и т. п.' Е. Факторы, влияющие на исход операции с детализаци- ей до конкретных параметров. Выделение факторов, влияющих на исход операции, яв- ляется наиболее ответственным и трудоемким этапом созда- ния вербальной модели операции. Наибольшую сложность представляет не перечисление факторов, а их конкретиза- ция до параметров, имеющих конкретный физический и ма- тематический смысл. В рассмотренном выше примере не вы- зывает сомнения необходимость учета в модели уровня изу- ченности конкурентами спроса на продукцию или услугу. Од- нако весьма непросто ввести конкретный параметр (систему параметров), описывающий этот уровень. Все факторы, влияющие на исход операции, можно раз- делить на две группы: ♦ неуправляемые факторы, под которыми понимаются характеристики элементов моделируемой системы, кон- курента и природные факторы, которые не могут быть 76
изменены моделируемой системой или конкурентом при проведении операции (например, характеристики тех- ники, характеристики условий, в которых проводится операция и т. д.); ♦ управляемые факторы, под которыми понимаются ре- сурсы, имеющиеся у моделируемой системы и конку- рента для проведения операции (например, возможные маршруты транспортировки продукции, варианты биз- нес-плана и т. д.). Необходимо отметить, что причисление тех или иных факторов к управляемым или неуправляемым является не- формальной процедурой и зависит от назначения создавае- мой математической модели, а также требований по ее адек- ватности. Один и тот же фактор в одной модели может быть определен как управляемый, а в другой — как неуправляе- мый. Конкретизированные до параметра факторы состав- ляют исходные данные, необходимые для проведения расче- тов на создаваемой математической модели. При этом пара- метры, описывающие неуправляемые факторы, либо посто- янно хранятся в модели (например, характеристики опреде- ленных типов техники), либо вводятся заблаговременно и в дальнейшем не изменяются (например, характеристики до- рожной сети региона). Параметры, описывающие управляе- мые факторы, должны определяться при каждом обращении к модели. Поскольку параметры, описывающие неуправляемые факторы, должны вводиться в модель до начала моделирова- ния, заказчик должен указать источники получения этих параметров. В некоторых случаях для определения значений отдельных параметров необходимо проведение дополнитель- ных исследований или экспериментов. Перечень таких пара- метров и необходимых исследований должен быть приведен в оперативной постановке модели. Поскольку учет большого количества факторов может серьезно усложнить математическую модель, необходимо 77
проранжировать перечисленные факторы по степени их вли- яния на исход операции и оценить возможность исключения малозначимых факторов. Если оценить степень влияния какого-либо фактора на исход операции не представляется возможным, йеобходимо либо обязательно учитывать этот фактор в модели, либо провести дополнительные исследования по анализу степени влияния данного фактора на исход операции. Необходимость такого подхода диктуется тем, что неучет фактора, суще- ственно влияющего на исход операции, может привести к потере адекватности модели и, в конечном счете, к получе- нию недостоверных результатов моделирования. Окончательный выбор учитываемых факторов должен проводиться совместно представителями заказчика и раз- работчика модели с учетом увязки противоречивых требова- ний по адекватности модели, с одной стороны, и простоте модели, а также обеспечению требуемой оперативности рас- четов — с другой. Необходимо отметить, что в зависимости от существа моделируемой операции те или иные элементы вербальной модели операции могут отсутствовать (этапы операции, под- цели моделируемой системы и конкурента в операции, воз- можные стратегии сторон, участвующих в операции, а так- же допущения, принимаемые в модели операции). 5. Критерии и показатели эффективности операции. Выходные характеристики модели. Выбор критериев и показателей эффективности опера- ции — важный и ответственный элемент оперативной поста- новки, который должен осуществляться в соответствии с це- левой направленностью математической модели (см. п. 3 опе- ративной постановки). При формировании критериев и показателей эффектив- ности представители заказчика должны оценить возможность получения на их основе ответов на вопросы, стоящие перед моделью. Представители разработчика должны оценить воз- можность создания математической модели, способной рас- 78
считывать предлагаемые показатели эффективности и реа- лизовывать выбранный критерий (критерии) эффективности с учетом требований по оперативности и достоверности рас- четов. Выходными характеристиками модели являются рассчи- танные показатели эффективности, а также параметры моделируемой системы и конкурента, определенные в ре- зультате решения оптимизационных задач или задач выбора в соответствии с принятыми критериями эффективности. Помимо показателей эффективности, в процессе функ- ционирования модели, как правило, определяются промежу- точные параметры, характеризующие ход и исход модели- руемой операции, которые целесообразно использовать при анализе результатов моделирования и принятии практичес- ких управленческих решений (например, сетки вероятностей, функции или плотности распределения параметров, характе- ризующих результаты операции и т. д.). Эти промежуточные характеристики совместно с показателями эффективности операции и другими выходными параметрами могут быть ука- заны в качестве выходных характеристик модели. Определение состава выходных характеристик модели должно проводиться с учетом того, что на основании этих характеристик необходимо обеспечить реализацию целевой направленности модели и возможность использования выход- ных характеристик в практике управления. 6. Допущения и ограничения, принимаемые в математи- ческой модели. Под допущениями, принимаемыми в модели операции, понимается замена фактических элементов системы или про- цессов их приближенным представлением. При этом появля- ется возможность достаточно строго описать эти элементы или процессы уже известными и проверенными математи- ческими понятиями, схемами и моделями. Например, при прогнозировании значений характеристик экономического развития фирмы можно (обоснованно) принять допущение о принадлежности некоторых случайных факторов определен- 79
ным (известным) законам распределения, что позволит при- менить хорошо проработанный аппарат теории вероятностей и математической статистики. Систему допущений, принимаемых в модели операции, формулирует разработчик на основании анализа вербаль- ной модели и с учетом известных способов математического описания объектов и явлений. Принимаемая система допущений оказывает существен- ное влияние на адекватность разрабатываемой модели бое- вых действий. Поэтому она должна быть согласована с пред- ставителями заказчика. Ограничения, принимаемые в математической модели, определяются путем задания возможных диапазонов изме- нения исходных данных и результатов моделирования, ко- торые определяются заказчиком, исходя из практических за- дач, решаемых с использованием данной модели. 7. Варианты работы модели определяются в соответствии с ее местом, ролью и целевой направленностью (см. п.п. 2 и 3 оперативной постановки). По существу в данном пункте дол- жен быть описан сценарий применения модели при решении различных задач управления. Для каждого варианта работы модели должно быть указано допустимое время моделиро- вания. Если предполагается наличие нескольких вариантов ра- боты модели, должно быть указано допустимое время моде- лирования для каждого варианта. 8. Требования по обеспечению достоверности результа- тов счета и защиты входной и выходной информации. В данном пункте прежде всего должны быть определе- ны мероприятия (методы, приемы) по обеспечению досто- верности результатов счета (например, контроль вводимых исходных данных, проведение контрольных расчетов на уп- рощенной модели и т. д.). Что касается требований по защите информации, то они должны включать перечень должностных лиц, которые 80
могут работать с моделью, информацию, к которой они дол- жны иметь непосредственный доступ, а также другие указа- ния по обеспечению защиты входной и выходной информа- ции. Более подробно эти вопросы будут рассмотрены в п. 1.5. Перечисленные выше пункты оперативной постановки математической модели по согласованию между разработчи- ком и заказчиком могут дополняться или сокращаться. В частности, дополнительно может быть включен пункт по оп- ределению порядка ввода и вывода информации, а также форм представления входных и выходных документов. 1.4.2. Особенности оперативных постановок информационных, вычислительных задач и их комплексов Информационные задачи должны обеспечивать автома- тизированный сбор, хранение, поиск и выдачу на рабочие места должностных лиц информации, необходимой им в процессе управления предприятиями. Задачи этого типа яв- ляются достаточно простыми с точки зрения их создания и вместе с тем достаточно эффективными средствами автома- тизации деятельности должностных лиц органов управления. Применение ИЗ позволяет существенно сократить затраты времени на решение различных задач учета, контроля и под- готовки документов. Информация, которую перерабатывает ИЗ, может по- ступать по каналам связи либо храниться в базах данных (БД). База данных может содержать как постоянную инфор- мацию (характеристики операции, кадровый состав сотруд- ников и т. д.), так и переменную (оперативную) информацию (текущие данные о персонале фирмы, состоянии средств связи и ЭВТ и т. д.). Для создания БД и работы с ними создается или выби- рается из существующих комплекс специальных программ, называемый системой управления базами данных (СУБД) и входящий в состав общего программного обеспечения АИС. 81
Создание ИЗ осуществляется, как правило, с использовани- ем программных элементов СУБД. Основными сложностями, которые могут возникнуть при разработке оперативной постановки информационной зада- чи, являются: ♦ отсутствие либо самой БД, либо требуемой информа- ции в БД (тогда может возникнуть необходимость сна- чала создать БД, а затем обеспечить внесение в нее нужной информации); ♦ невозможность обеспечения средствами существующей СУБД поиска и выдачи требуемой информации с при- емлемой оперативностью (это осложнение возникает крайне редко, но в случае его возникновения трудно- сти создания информационной задачи становятся прак- тически непреодолимыми, так как возникает потреб- ность либо модификации стандартной, либо разработ- ки новой СУБД). Оперативная постановка ИЗ должна включать шесть основных элементов. Перечислим их, указывая лишь специ- фические (по сравнению с оперативной постановкой модели боевых действий) особенности. 1. Название ИЗ. 2. Место и роль задачи в процессе управления сотрудни- ками фирмы. 3. Состав, формы представления, а также порядок вво- да и вывода информации на различные технические устрой- ства (дисплеи, печатающие устройства и т. д.). 4. Состав, структура информации, необходимой для работы задачи, с указанием источников получения этой ин- формации. В данном пункте указываются БД или результа- ты работы других ИЗ, которые должны использоваться в ИЗ. Если создаваемая ИЗ использует для своей работы информа- цию, поступающую по каналам связи, необходимо указать состав и структуру этой информации. 5. Режимы работы и допустимое время работы ИЗ в каждом режиме. 82
6. Требования по обеспечению достоверности и защите входной и выходной информации. Вычислительные задачи предназначены для обеспечения оперативных или специальных расчетов числовых значений искомых показателей, необходимых руководителям предпри- ятий при выработке решений по управлению войсками. ВЗ создаются, как правило, на основе сравнительно простых и известных алгоритмов с использованием информации из нор- мативных документов (источников). Примерами ВЗ являются: расчет времени движения ав- томобильного транспорта, составление графика боевого де- журства, расчет графика ведения ремонтно-восстановитель- ных работ и т. д. Использование ВЗ в процессе управления персоналом наиболее целесообразно на этапе постановки задачи, а так- же на этапе определения сил, средств и способов выполне- ния поставленных задач. Оперативная постановка ВЗ должна включать семь эле- ментов. 1. Название ВЗ. 2. Место и роль ВЗ в процессе управления персоналом предприятия. 3. Состав, формы представления, а также порядок вво- да и вывода информации на различные технические устрой- ства. 4. Состав, структура информации, необходимой для работы задачи, с указанием источников получения этой ин- формации. 5. Перечень приказов, директив и других нормативных документов (или сведений из них), которыми должен руко- водствоваться разработчик при создании ВЗ. В некоторых слу- чаях может быть непосредственно приведен алгоритм пере- работки информации, который должен быть реализован в ВЗ. 6. Режимы работы и допустимое время работы ВЗ в каж- дом режиме. 7. Требования по обеспечению достоверности и защите входной и выходной информации. 83
Создаваемые ИРЗ как элементы специального приклад- ного программного обеспечения АИС ВН объединяются в ком- плексы. Оперативная постановка такого комплекса задач должна отражать четыре вопроса. 1. Название комплекса задач. 2. Место и роль комплекса задач в процессе управления персоналом и в АИС. 3. Перечень ИРЗ, входящих в комплекс, и структура информационных связей между ними. 4. Меры по обеспечению информационной совместимос- ти между задачами комплекса и другими комплексами. Следует особо отметить, что в качестве обязательного приложения к оперативной постановке комплекса задач вы- ступают оперативные постановки входящих в него задач. 1.4.3. Оперативное описание информационных и расчетных задач Оперативное описание является необязательным при- ложением к оперативной постановке И или РЗ. Оно созда- ется по согласованию между заказчиком и разработчиком и содержит детализацию основных положений и требований оперативной постановки. Объем и содержание оперативного описания может быть самым различным. Как правило, в оперативное описание мо- гут входить следующие элементы: ♦ структура И или РЗ — блоки, из которых состоит задача, а также связи между ними; ♦ определение шагов моделирования или расчета (под шагом моделирования или расчета понимается часть процесса работы задачи, на которой вычисляются про- межуточные результаты); ♦ гриф секретности задачи (при необходимости может отдельно указываться гриф секретности программы, ис- ходных данных и результатов счета); 84
♦ условные знаки и символы, используемые при вводе и выводе информации; ♦ типы устройств, используемых при вводе и выводе информации и т. д. Особо отметим важность указания второго из названных пунктов. Действительно, в ряде случаев определение шагов моделирования позволяет при необходимости организовать визуальный контроль пользователем процесса расчета пу- тем анализа промежуточных результатов. Введение шагов моделирования бывает необходимым, когда в процессе рас- чета задача запрашивает дополнительные исходные данные. Кроме того, определение шагов моделирования позволяет задавать так называемые контрольные точки задачи. Контрольная точка — это место в программе, в котором вся информация по задаче записывается в долговременную память ЭВМ. Если в процессе работы задачи между двумя контрольными точками произошел сбой в работе ЭВМ, то пос- ле устранения причин сбоя вычисления могут быть продолже- ны, начиная с последней контрольной точки. Весьма полезным оказывается этот прием и при работе с математическими мо- делями, требующими для проведения численных эксперимен- тов значительных затрат машинного времени. 1.5. Информационная безопасность экономических систем Опыт эксплуатации существующих компьютерных сис- тем обработки информации показывает, что проблема обес- печения безопасности еще далека от своего решения, а пред- лагаемые производителями различных систем средства за- щиты сильно различаются как по решаемым задачам и ис- пользуемым методам, так и по достигнутым результатам. Это определяет актуальность проблемы построения защищенных систем обработки информации, решение которой следует начать с анализа причин сложившейся ситуации. 85
Проблема защиты машинной информации на современ- ном уровне развития информатизации общества столь важна и многогранна, что заслуживает более подробного рассмот- рения, чем другие аспекты автоматизации профессиональ- ной деятельности. Данный пункт содержит материал по не- скольким направлениям, представляющим, по мнению авто- ров, наибольший интерес. Более подробные сведения заин- тересованный читатель может найти в других источниках (на- пример, [14, 19, 20, 31, 33]). 1.5.1. Сравнительный анализ стандартов информационной безопасности Для того чтобы объединить усилия всех специалистов в направлении конструктивной работы над созданием защищен- ных систем, необходимо определить, что является целью исследований, что мы хотим получить в результате и чего в состоянии достичь. Для ответа на эти вопросы и согласования всех точек зрения на проблему создания защищенных систем разработаны и продолжают разрабатываться стандарты ин- формационной безопасности. Это документы, регламентиру- ющие .основные понятия и концепции информационной безо- пасности на государственном или межгосударственном уров- не, определяющие понятие “защищенная система” посред- ством стандартизации требований и критериев безопасности, образующих шкалу оценки степени защищенности ВС. В со- ответствии с этими документами защищенная система обра- ботки информации представляет собой систему, отвечающую тому или иному стандарту информационной безопасности. Этот факт позволяет сопоставлять степени защищенности различ- ных систем относительно установленного стандарта. Основные понятия и определения Политика безопасности — совокупность норм и правил, обеспечивающих эффективную защиту системы обработки информации от заданного множества угроз. 86
Модель безопасности — формальное представление по- литики безопасности. Дискреционное, или произвольное, управление доступом — управление доступом, основанное на совокупности правил предоставления доступа, определенных на множестве атри- бутов безопасности субъектов и объектов, например, в зави- симости от грифа секретности информации и уровня допуска пользователя. Ядро безопасности (ТСВ) — совокупность аппаратных, программных и специальных компонент ВС, реализующих функции защиты и обеспечения безопасности. Идентификация — процесс распознавания сущностей путем присвоения им уникальных меток (идентификаторов). Аутентификация — проверка подлинности идентифи- каторов сущностей с помощью различных (преимущественно криптографических) методов. Адекватность — показатель реально обеспечиваемого уровня безопасности, отражающий степень эффективности и надежности реализованных средств защиты и их соответствия поставленным задачам (в большинстве случаев это задача реализации политики безопасности). Квалификационный анализ, квалификация уровня безо- пасности — анализ ВС с целью определения уровня ее за- щищенности и соответствия требованиям безопасности на ос- нове критериев стандарта безопасности. Таксономия — наука о систематизации и классифика- ции сложноорганизованных объектов и явлений, имеющих иерархическое строение. Таксономия основана на декомпози- ции явлений и поэтапном уточнении свойств объектов (иерар- хия строится сверху вниз). Прямое взаимодействие — принцип организации инфор- мационного взаимодействия (как правило, между пользова- телем и системой), гарантирующий, что передаваемая ин- формация не подвергается перехвату или искажению. 87
Защищенная система обработки информации для опре- деленных условий эксплуатации обеспечивает безопасность (доступность, конфиденциальность и целостность) обрабаты- ваемой информации и поддерживает свою работоспособность в условиях воздействия на нее заданного множества угроз. Под защищенной системой обработки информации пред- лагается понимать систему, которая обладает следующими свойствами: ♦ осуществляет автоматизацию некоторого процесса об- работки конфиденциальной информации, включая все аспекты этого процесса, связанные с обеспечением безопасности обрабатываемой информации; ♦ успешно противостоит угрозам безопасности, действу- ющим в определенной среде; ♦ соответствует требованиям и критериям стандартов информационной безопасности. Отсюда вытекают следующие задачи, которые необхо- димо и достаточно решить, для того чтобы создать защи- щенную систему обработки информации, а именно: ♦ в ходе автоматизации процесса обработки конфиден- циальной информации реализовать все аспекты этого процесса, связанные с обеспечением безопасности об- рабатываемой информации; ♦ обеспечить противодействие угрозам безопасности, дей- ствующим в среде эксплуатации защищенной системы; ♦ реализовать необходимые требования соответствующих стандартов информационной безопасности. Угрозы безопасности компьютерных систем Под угрозой безопасности вычислительной системы по- нимаются воздействия на систему, которые прямо или кос- венно могут нанести ущерб ее безопасности. Приведем наиболее общую классификацию возможных угроз безопасности. Все угрозы можно разделить по их ис- точнику и характеру проявления на следующие классы (см. рис. 1.5.1). 88
Характер угрозы Случайные Преднамеренные Источник Природные Технические ---- Созданные людьми угрозы Рис. 1.5.1. Общая классификация возможных угроз безопасности Случайные угрозы возникают независимо от воли и же- лания людей. Данный тип угроз связан прежде всего с пря- мым физическим воздействием на элементы компьютерной системы (чаще всего, природного характера) и ведет к нару- шению работы этой системы и/или физическому уничтоже- нию носителей информации, средств обработки и передачи данных, физических линий связи. Причиной возникновения технических угроз случайного характера могут быть как сбои вследствие ошибок персонала (порожденные людьми), так и случайные нарушения в рабо- те оборудования системы (например, вследствие поломки какого-либо узла или устройства, сбоя в работе программно- го обеспечения или элементарное “короткое замыкание”). Последствиями подобных событий могут быть отказы и сбои аппаратуры, искажение или уничтожение информации, на- рушение линий связи, ошибки и физический вред персоналу. Примером реализации случайной угрозы, созданной людь- ми, может быть физическое нарушение проводных линий связи из-за проведения строительных работ. Другими слова- ми, угрозы данного типа возникают вследствие каких-либо действий людей, целью которых не является нанесение фи- зического вреда и нарушение функционирования работы ком- пьютерной системы и/или отдельных ее сегментов и ресур- сов, однако побочный эффект данных действий приводит к нарушениям и сбоям в работе системы. Преднамеренные угрозы, в отличие от случайных, могут быть созданы только людьми и направлены именно на дезор- ганизацию компьютерной системы. Примером реализации та- кой угрозы может быть как физическое уничтожение аппа- 89
ратуры и сетевых коммуникации системы, так и нарушение ее целостности и доступности, а также конфиденциальности обрабатываемой и хранимой ею информации с применением средств и ресурсов самой системы, а также с использовани- ем дополнительного оборудования. В табл. 1.5.1. приведена более подробная классификация угроз информационной безопасности в зависимости от их ис- точника. Таблица 1.5.1 1. Природные угрозы 2. Угрозы техногенного характера 3. Угрозы, созданные людьми 1.1. Стихийные бедствия 1.2. Магнитные бури 1.3. Радиоактивное излучение и осадки 1.4. Другие угрозы 2.1. Отключения нли колебания электропитания и сбои в работе других средств обеспечения функционирования системы 2.2. Отказы и сбои в работе аппаратно- программных средств компьютерной системы 2.3. Электромагнитные излучения и наводки 2.4. Утечки через каналы связи: оптические, электрические, звуковые 2.5. Другие угрозы 3.1. Непреднамеренные действия: 3.1.1. Обслуживающего персонала 3.1.2. Управленческого персонала 3.1.3. Программистов 3.1.4. Пользователей 3.1.5. Архивной службы 3.1.6. Службы безопасности 3.2. Преднамеренные действия: 3.2.1. Обслуживающего персонала 3.2.2. Управленческого персонала 3.2.3. Программистов 3.2.4. Пользователей 3.2.5. Архивной службы 3.2.6. Службы безопасности 3.2.7. Хакерские атаки Относительно природных угроз добавить к сказанному ранее практически нечего. Угрозы техногенного характера связаны с надежностью работы аппаратно-программных средств компьютерной сис- темы. При этом угрозы подгруппы 2.1 связаны с внезапным 90
временным прекращением работы системы и ведут к потерям информации и управления объектами системы. Угрозы под- группы 2.2 связаны с надежностью работы аппаратно-про- граммных средств и ведут к искажению и потерям информа- ции, нарушениям в управлении объектами. Угрозы подгруп- пы 2.3 связаны с наличием электромагнитных излучений, за счет которых может происходить несанкционированный пе- ренос информации за пределы защищаемой системы. Угрозы подгруппы 2.4 связаны с утечкой информации через легаль- ные каналы связи за счет использования специального обо- рудования. Угрозы следующей группы связаны с людьми, непосред- ственно работающими с компьютерной системой. Непредна- меренные угрозы связаны со случайными действиями пользо- вателей, ошибками операторов, программистов, управленчес- кого персонала, сотрудников архивной службы и службы бе- зопасности и ведут к искажению или уничтожению информа- ции, нарушению функционирования, управления и безопас- ности системы, а также к ошибкам и сбоям в работе про- граммно-аппаратных средств. Угрозы, “носителями” которых являются хакерские ата- ки, связаны с преднамеренными действиями людей, направ- ленными на нанесение ущерба системе с использованием средств и возможностей штатного оборудования системы и любых других возможностей, которые могут быть получены с применением всех имеющихся на данный момент времени информационных технологий. Данная группа угроз является наиболее многочисленной. Необходимо особо отметить такой вид угроз, как вне- дрение компьютерных “вирусов”, программ-“троянских ко- ней”, логических бомб и т. д. Данный вид угроз может отно- ситься как к группе 3.1, так и к группе 3.2 в связи с тем, что программы такого типа могут быть специально разработан- ными “боевыми вирусами” или специально внедренными про- граммными закладками для выведения из строя объектов си- 91
стемы, однако схожими по возможным последствиям могут быть и результаты проявления так называемых недокумен- тированных возможностей вполне “мирного” программного обеспечения (например, сетевой операционной системы), яв- ляющиеся следствием непреднамеренных ошибок, допущен- ных создателями программно-аппаратных средств. Самым яр- ким примером проявления недокументированных возможнос- тей является инцидент с “червем” Морриса, первым сетевым компьютерным вирусом. Изначально данная программа пред- назначалась для удаленного тестирования UNIX-машин, од- нако после запуска 2 ноября 1988 г. программа вышла из-под контроля автора и начала быстро перемещаться по сети Ин- тернет, загружая операционные системы хостов сети своими копиями и вызывая отказы в обслуживании. Формально дан- ное программное средство не наносило ущерба информации на “зараженных” им хостах, однако вызывало необходимость проведения комплекса профилактических работ по восста- новлению работоспособности данных хостов. Общие потери от описанного выше инцидента составили почти 100 млн. долл. США. Таким образом, перед защитой систем обработки инфор- мации стоит довольно сложная задача — противодействие бурно развивающимся угрозам безопасности. Следовательно, безопасная или защищенная система — это система, облада- ющая средствами защиты, которые успешно и эффективно противостоят угрозам безопасности. Главная задача стандартов информационной безопаснос- ти — создать основу для взаимодействия между производи- телями, потребителями и экспертами по квалификации про- дуктов информационных технологий. Каждая из этих групп имеет свои интересы и свои взгляды на проблему информа- ционной безопасности. Таким образом, перед стандартами информационной безопасности стоит непростая задача — при- мирить взгляды этих сторон и создать эффективный меха- низм взаимодействия между ними. 92
Критерии безопасности компьютерных систем Министерства обороны США (Оранжевая книга) “Критерии безопасности компьютерных систем” (Оран- жевая книга) были разработаны Министерством обороны США в 1983 г. с целью определения требований безопасности, предъявляемых к аппаратному, программному и специально- му обеспечению компьютерных систем и выработки соответ- ствующей методологии и технологии анализа степени поддер- жки политики безопасности в компьютерных системах воен- ного назначения. Согласно Оранжевой книге безопасная компьютерная система — это система, поддерживающая управление дос- тупом к обрабатываемой в ней информации так, что только соответствующим образом авторизованные пользователи или процессы, действующее от их имени, получают возможность читать, писать, создавать и удалять информацию. В Оранжевой книге предложены три категории требова- ний безопасности — политика безопасности, аудит и коррек- тность, в рамках которых сформулированы шесть базовых требований безопасности. Требование 1. Политика безопасности. Система должна поддерживать точно определенную политику безопасности. Требование 2. Метки. С объектами должны быть ассоци- ированы метки безопасности, используемые в качестве ат- рибутов контроля доступа. Требование 3. Идентификация и аутентификация. Все субъекты должны иметь уникальные идентификаторы. Требование 4. Регистрация и учет. Для определения сте- пени ответственности пользователей за действия в системе, все происходящие в ней события, имеющие значение с точ- ки зрения безопасности, должны отслеживаться и регистри- роваться в защищенном протоколе. Требование 5. Контроль корректности функциониро- вания средств защиты. Средства защиты должны содержать независимые аппаратные и/или программные компоненты, обеспечивающие работоспособность функций защиты. 93
Требование 6. Непрерывность защиты. Все средства защиты (в том числе и реализующие данное требование) дол- жны быть защищены от несанкционированного вмешатель- ства и/или отключения, причем эта защита должна быть по- стоянной и непрерывной в любом режиме функционирования системы защиты и компьютерной системы в целом. Приведенные выше базовые требования к безопасности служат основой для критериев, образующих единую шкалу оценки безопасности компьютерных систем, определяющую семь классов безопасности. Оранжевая книга предусматривает четыре группы кри- териев, которые соответствуют различной степени защищен- ности: от минимальной (группа D) до формально доказанной (группа А). Уровень безопасности возрастает при движении от группы D к группе А, а внутри группы — с возрастанием номера класса. Группа D. Минимальная защита. Класс D. Минимальная защита. К этому классу относятся все системы, которые не удовлетворяют требованиям дру- гих классов. Группа С. Дискреционная защита. Класс С1. Дискреционная защита. Системы этого класса удовлетворяют требованиям обеспечения разделения пользо- вателей и информации и включают средства контроля и уп- равления доступом, позволяющие задавать ограничения для индивидуальных пользователей, что дает им возможность защищать свою приватную информацию от других пользова- телей. Класс С 2. Управление доступом. Системы этого класса осуществляют более избирательное управление доступом, чем системы класса С1, с помощью применения средств индиви- дуального контроля за действиями пользователей, регистра- цией, учетом событий и выделением ресурсов. Группа В. Мандатная защита. Класс В1. Защита с применением меток безопасности. 94
Класс В2. Структурированная защита. Телевизионная си- стема видеоконтроля (ТСВ) должна поддерживать формаль- но определенную и четко документированную модель безо- пасности, предусматривающую произвольное нормативное управление доступом, которое распространяется по сравне- нию с системами класса В1 на все субъекты. Класс ВЗ. Домены безопасности. ТСВ должна поддержи- вать монитор взаимодействий, контролирующий все типы доступа субъектов к объектам, который невозможно обойти. Кроме того, ТСВ должна быть структурирована с целью ис- ключения из нее подсистем, не отвечающих за реализацию функций защиты, и быть достаточно компактной для эффек- тивного тестирования и анализа. Группа А. Верифицированная защита. Класс А1. Формальная верификация. Системы класса А1 функционально эквивалентны системам класса ВЗ, и к ним не предъявляется никаких дополнительных функциональных требований. В отличие от систем класса ВЗ в ходе разработ- ки должны применяться формальные методы верификации, что позволяет с высокой уверенностью получить корректную реализацию функций защиты. Приведенные классы безопасности надолго определили основные концепции безопасности и ход развития средств защиты. Для того чтобы исключить возникшую в связи с измене- нием аппаратной платформы некорректность некоторых по- ложений Оранжевой книги, адаптировать их к современным условиям и сделать адекватными нуждам разработчиков и пользователей программного обеспечения, и была проделана огромная работа по интерпретации и развитию положений этого стандарта. В результате возник целый ряд сопутствую- щих Оранжевой книге документов, многие из которых стали ее неотъемлемой частью. К наиболее часто упоминаемым от- носятся: ♦ Руководство по произвольному управлению доступом в безопасных системах. ♦ Руководство по управлению паролями. 95
♦ Руководство по применению критериев безопасности компьютерных систем в специфических средах. В 1995 г. Национальным центром компьютерной безопас- ности США был опубликован документ под названием “Ин- терпретация критериев безопасности компьютерных систем”, объединяющий все дополнения и разъяснения. Европейские критерии безопасности информационных технологий Для того чтобы удовлетворить требованиям конфиденци- альности, целостности и работоспособности, в Европейских критериях впервые вводится понятие адекватности средств защиты. Адекватность включает в себя: ♦ эффективность, отражающую соответствие средств безопасности решаемым задачам; ♦ корректность, характеризующую процесс их разработ- ки и функционирования. Общая оценка уровня безопасности системы складывает- ся из функциональной мощности средств защиты и уровня адекватности их реализации. Набор функций безопасности может специфицировать- ся с использованием ссылок на заранее определенные клас- сы-шаблоны. В Европейских критериях таких классов десять. Пять из них (F-Cl, F-C2, F-Bl, F-B2, F-B3) соответствуют классам безопасности Оранжевой книги с аналогичными обо- значениями. Рассмотрим другие пять классов, так как их тре- бования отражают точку зрения разработчиков стандарта на проблему безопасности. Класс F-IN предназначен для систем с высокими потреб- ностями в обеспечении целостности, что типично для систем управления базами данных. Класс F-AV характеризуется повышенными требования- ми к обеспечению работоспособности. Класс F-DI ориентирован на распределенные системы обработки информации. 96
Класс F-DC уделяет особое внимание требованиям к кон- фиденциальности передаваемой информации. Класс F-DX предъявляет повышенные требования и к целостности, и к конфиденциальности информации. Европейские критерии определяют семь уровней адек- ватности — от ЕО до Е6 (в порядке возрастания). Уровень ЕО обозначает минимальную адекватность (аналог уровня D Оран- жевой книги). При проверке адекватности анализируется весь жизненный цикл системы — от начальной фазы проектиро- вания до эксплуатации и сопровождения. Уровни адекватнос- ти от Е1 до Е6 выстроены по нарастанию требований тща- тельности контроля. Так, на уровне Е1 анализируется общая архитектура системы, а адекватность средств защиты под- тверждается функциональным тестированием. На уровне ЕЗ — к анализу привлекаются исходные тексты программ и схемы аппаратного обеспечения. На уровне Е6 требуется формаль- ное описание функций безопасности, общей архитектуры, а также политики безопасности. Руководящие документы Гостехкомиссии России В 1992 г. Гостехкомиссия (ГТК) при Президенте РФ опуб- ликовала пять руководящих документов, посвященных воп- росам защиты от несанкционированного доступа (НСД) к ин- формации. Рассмотрим важнейшие из них: ♦ “Концепция защиты средств вычислительной техники от НСД к информации”. ♦ “Средства вычислительной техники. Защита от НСД к информации. Показатели защищенности от НСД к ин- формации”. ♦ “Автоматизированные системы. Защита от НСД к ин- формации. Классификация автоматизированных систем и требования по защите информации”. Идейной основой этих документов является “Концепция защиты средств вычислительной техники от НСД к информа- ции”, содержащая систему взглядов ГТК на проблему ин- формационной безопасности и основные принципы защиты компьютерных систем. 97
Основная, и едва ли не единственная, задача средств безопасности в этих документах — это обеспечение защиты от НСД к информации. Если средствам контроля и обеспече- ния целостности еще уделяется некоторое внимание, то под- держка работоспособности систем обработки информации во- обще не упоминается. Все это объясняется тем, что эти до- кументы были разработаны в расчете на применение в ин- формационных системах Министерства обороны и спецслужб РФ, а также недостаточно высоким уровнем информацион- ных технологий этих систем по сравнению с современным. Руководящие документы ГТК предлагают две группы критериев безопасности: ♦ показатели защищенности средств вычислительной тех- ники (СВТ) от НСД; ♦ критерии защищенности автоматизированных систем (АС) обработки данных. Данный руководящий документ устанавливает классифи- кацию СВТ по уровню защищенности от НСД к информации на базе перечня показателей защищенности и совокупности, описывающих их требования. Данные показатели содержат требования защищенности СВТ от НСД к информации и применяются к общесистемным программным средствам и операционным системам. Конкрет- ные перечни показателей определяют классы защищенности СВТ и описываются совокупностью требований. Установлено семь классов защищенности СВТ от НСД к информации. Самый низкий класс — седьмой, самый высо- кий — первый. В отличие от остальных стандартов отсутствует раздел, содержащий требования по обеспечению работоспособности системы, зато присутствует раздел, посвященный крипто- графическим средствам. Требования к средствам защиты АС от НСД включают следующие подсистемы: 1. Подсистема управления доступом. 2. Подсистема регистрации и учета. 98
3. Криптографическая подсистема. 4. Подсистема обеспечения целостности. Документы ГТК устанавливают девять классов защищен- ности АС от НСД, каждый из которых характеризуется оп- ределенной совокупностью требований к средствам защиты. Классы подразделяются на три группы, отличающиеся спе- цификой обработки информации в АС. Группа АС определя- ется на основании следующих признаков: ♦ Наличие в АС информации различного уровня конфи- денциальности. ♦ Уровень полномочий пользователей АС на доступ к кон- фиденциальной информации. ♦ Режим обработки данных в АС (коллективный или ин- дивидуальный). Федеральные критерии безопасности информационных технологий Федеральные критерии безопасности информационных технологий — первый стандарт информационной безопаснос- ти, в котором определяются три независимые группы требо- ваний: функциональные требования к средствам защиты, требования к технологии разработки и к процессу квалифи- кационного анализа. Авторами этого стандарта впервые пред- ложена концепция Профиля защиты — документа, содержа- щего описание всех требований безопасности как к самому продукту информационных технологий (ИТ-продукту), так и к процессу его проектирования, разработки, тестирования и квалификационного анализа. Функциональные требования безопасности хорошо струк- турированы и описывают все аспекты функционирования ТСВ. Требования к технологии разработки, впервые появившиеся в этом документе, побуждают производителей использовать современные технологии программирования как основу для подтверждения безопасности своего продукта. Разработчики федеральных критериев отказались от ис- пользуемого в Оранжевой книге подхода к оценке уровня 99
безопасности ИТ-продукта на основании обобщенной универ- сальной шкалы классов безопасности. Вместо этого предлага- ется независимое ранжирование требований каждой группы, т. е. вместо единой шкалы используется множество частных шкал критериев, характеризующих обеспечиваемый уровень безопасности. Данный подход позволяет разработчикам и пользователям ИТ-продукта выбрать наиболее приемлемое решение и точно определить необходимый и достаточный набор требований для каждого конкретного ИТ-продукта и среды его эксплуатации. Этот стандарт рассматривает устранение недостатков существующих средств безопасности как одну из задач за- щиты наряду с противодействием угрозам безопасности и ре- ализацией модели безопасности. Единые критерии безопасности информационных технологий Единые критерии безопасности информационных техно- логий представляют собой результат обобщения всех дости- жений последних лет в области информационной безопаснос- ти. Впервые документ такого уровня содержит разделы, ад- ресованные потребителям, производителям и экспертам по квалификации ИТ-продуктов. Предложенные Едиными критериями механизмы Профи- ля защиты и Проекта защиты позволяют потребителям и про- изводителям в полной мере выразить свой взгляд на требова- ния безопасности и задачи защиты, а с другой стороны, дают возможность экспертам по квалификации проанализировать взаимное соответствие между требованиями, нуждами по- требителей, задачами защиты и средствами защиты ИТ-про- дукта. В отличие от Профиля защиты Федеральных критери- ев, который ориентирован исключительно на среду примене- ния ИТ-продукта, Профиль защиты Единых критериев пред- назначен непосредственно для удовлетворения запросов по- требителей. 100
Разработчики Единых критериев отказались (как и раз- работчики Федеральных критериев) от единой шкалы безо- пасности и усилили гибкость предложенных в них решений путем введения частично упорядоченных шкал, благодаря чему потребители и производители получили дополнитель- ные возможности по выбору требований и их адаптации к своим прикладным задачам. Особое внимание этот стандарт уделяет адекватности реализации функциональных требований, которая обеспечи- вается как независимым тестированием и анализом ИТ-про- дукта, так и применением соответствующих технологий на всех этапах его проектирования и реализации. Таким образом, требования Единых критериев охваты- вают практически все аспекты безопасности ИТ-продуктов и технологии их создания, а также содержат все исходные материалы, необходимые потребителям и разработчикам для формирования Профилей и Проектов защиты. Кроме того, требования Единых критериев являются практически всеобъемлющей энциклопедией информационной безопасности, поэтому их можно использовать в качестве справочника безопасности информационных технологий. Анализ стандартов информационной безопасности Главная задача стандартов информационной безопаснос- ти — согласовать позиции и цели производителей, потреби- телей и аналитиков-классификаторов в процессе создания и эксплуатации продуктов информационных технологий. Каж- дая из перечисленных категорий специалистов оценивает стан- дарты и содержащиеся в них требования и критерии по сво- им собственным параметрам. В качестве обобщенных показателей, характеризующих стандарты информационной безопасности и имеющих значе- ние для всех трех сторон, предлагается использовать уни- версальность, гибкость, гарантированность, реализуемость и актуальность. 101
Универсальность. Оранжевая книга: предназначалась для систем военного времени, ее адаптация для распределенных систем и баз дан- ных потребовала разработки дополнительных документов. Европейские критерии: в этот стандарт вошли распреде- ленные системы, сети, системы телекоммуникаций и СУБД, но в нем по-прежнему явным образом оговаривается архи- тектура и назначение систем, к которым он может быть при- менен, и никак не регламентируется среда их эксплуатации. Документы Гостехкомиссии: имеют довольно ограничен- ную сферу применения — это персональные и многопользо- вательские системы, причем ориентация системы на обслу- живание конечных пользователей является обязательным условием. Федеральные критерии: подняли область применения стандартов на новый уровень, начав рассматривать в каче- стве объекта их применения любые продукты информаци- онных технологий, независимо от их назначения, проводя различие только между характеристиками среды их эксп- луатации. Канадские критерии: рассматривают в качестве области своего применения все типы компьютерных систем. Единые критерии: предложили такую технологию созда- ния ИТ-продуктов, при которой использование данного стан- дарта является неотъемлемым компонентом. Гибкость. Оранжевая книга: требования этого стандарта оказались слишком абстрактными для непосредственного применения во многих случаях, что потребовало их дополнения. Европейские критерии: предусмотрели специальные уровни и требования, рассчитанные на типовые системы (СУБД, телекоммуникации и т. д.). Документы Гостехкомиссии: подробно регламентирует реализацию функций защиты (например, это единственный 102
стандарт, который в ультимативной форме требует примене- ния криптографии), что значительно снижает удобство их использования — в конкретных ситуациях многие требова- ния часто оказываются избыточными и ненужными. Федеральные критерии: впервые предложили механизм Профилей защиты, с помощью которых можно создавать спе- циальные наборы требований, соответствующие запросам потребителей конкретного продукта и угрозам среды его эк- сплуатации. Канадские критерии: не рассматривают Профиль защи- ты в качестве обязательного элемента безопасности инфор- мационных технологий, а также обладают определенной спе- цификой в своем подходе к основным понятиям безопаснос- ти, поэтому их гибкость можно оценить только как достаточ- ную. Единые критерии: обладают практически совершенной гибкостью, так как позволяют потребителям выразить свои требования с помощью механизма Профилей защиты, в фор- ме инвариантной к механизмам реализации, а производите- лям — продемонстрировать с помощью Проекта защиты, как эти требования преобразуются в задачи и реализуются на практике. Гарантированность. Оранжевая книга: предусматривала обязательное приме- нение формальных методов верификации только при созда- нии систем высшего класса защищенности (класс А). Европейские критерии: появляется специальный раздел требований — требования адекватности, которые регламен- тируют технологию и инструментарий разработки, а также контроль за процессами проектирования и разработки. Документы Гостехкомиссии: практически полностью проигнорировали этот ключевой аспект безопасности инфор- мационных технологий, и обходят данный вопрос молчанием. Федеральные критерии: содержат два специальных раз- дела требований, посвященных этому аспекту безопасности, 103
содержащие требования к технологии разработки и к процес- су квалификационного анализа. Канадские критерии: включают раздел требований адек- ватности, количественно и качественно ни в чем не уступа- ющий разделу функциональных требований. Единые критерии: рассматривают гарантированность реализации защиты как самый важный компонент информа- ционной безопасности и предусматривают многоэтапный кон- троль на каждой стадии разработки ИТ-продукта, позволяю- щий подтвердить соответствие полученных результатов по- ставленным целям путем доказательства адекватности задач защиты требованиям потребителей, адекватности Проекта защиты Единым критериям и адекватности ИТ-продукта Про- екту защиты. Реализуемость. Плохие показатели реализуемости говорят о практичес- кой бесполезности стандарта, поэтому все документы отве- чают этому показателю в достаточной или высокой степени. Единые критерии и здесь оказались на практически не- досягаемой для остальных стандартов высоте за счет потря- сающей степени подробности функциональных требований (135 требований), практически служащих исчерпывающим руко- водством по разработке защищенных систем. Отметим, что это единственный показатель, по которо- му документы ГТК не отстают от остальных стандартов ин- формационной безопасности. Актуальность. Оранжевая книга: содержит требования, в основном на- правленные на противодействие угрозам конфиденциальнос- ти, что объясняется ее ориентированностью на системы во- енного назначения. Европейские критерии: находятся примерно на том же уровне, хотя и уделяют угрозам целостности гораздо больше внимания. 104
Документы Гостехкомиссии: с точки зрения этого по- казателя выглядят наиболее отсталыми — уже в самом их названии определена единственная рассматриваемая в них угроза — НСД. Федеральные критерии: рассматривают все виды угроз достаточно подробно и предлагают механизм Профилей за- щиты для описания угроз безопасности, присущих среде эк- сплуатации конкретного ИТ-продукта, что позволяет учи- тывать специфичные виды угроз. Канадские критерии: ограничиваются типовым набором угроз безопасности, достаточным для большинства примене- ний. Единые критерии: ставят во главу угла удовлетворение нужд пользователей и предлагают для этого соответствую- щие механизмы (Профиль и Проект защиты), что дает воз- можность выстроить на их основе динамичную и постоянно адаптирующуюся к новым задачам технологию создания бе- зопасных информационных систем. 1.5.2. Исследование причин нарушений безопасности Проведение анализа успешно реализовавшихся угроз безопасности (атак) позволяет при разработке и создании за- щищенных систем сконцентрировать основные усилия имен- но на устранении этих причин путем исправления в механиз- мах защиты выявленных недостатков, что позволяет эффек- тивно противостоять угрозам безопасности. Наибольший интерес представляет одно из новейших направлений исследований в данной области, предложенное в работе “Таксономия нарушений безопасности программно- го обеспечения, с примерами”. Данный пункт опирается на результаты этого исследования. Уязвимость защиты (УЗ) — совокупность причин, ус- ловий и обстоятельств, наличие которых в конечном итоге может привести к нарушению нормального функционирова- 105
ния вычислительных систем и нарушению безопасности (НСД, ознакомление, уничтожение или искажение данных). В 70-х гг. XX в. были предприняты попытки формального описания и систематизации информации о УЗ. Исследования проводились по проектам RISOS (Исследование безопасности защищенных операционных систем) и РА (Анализ защиты). Предлагаемые методики поиска ошибок безопасности в операционных системах достаточно ограничены в практичес- ком применении. Это можно объяснить предпринятой попыт- кой обеспечить универсальность методик, что отрицательно сказалось на возможности их развития и адаптации для но- вых ОС. С другой стороны, усилия исследователей слишком рано были перенаправлены от изучения УЗ в сторону разра- ботки универсальной технологии создания защищенных опе- рационных систем, свободных от подобных ошибок. С точки зрения технологии создания защищенных сис- тем наибольшее значение имеют следующие вопросы, на которые должна дать ответ таксономия УЗ: 1. Каким образом ошибки, приводящие к появлению УЗ, вносятся в систему защиты? 2. Когда, на каком этапе они вносятся? 3. Где, в каких компонентах системы защиты (или ВС в целом) они возникают и проявляются? Ошибки в системах защиты, служащие источником по- явления УЗ, могут быть следующие. I. Преднамеренные: 1) с наличием деструктивных функций (активные): а) разрушающие программные средства (РПС): ♦ несамовоспроизводящиеся РПС (“троянские кони”); ♦ самовоспроизводящиеся РПС (вирусы); б) черные ходы, люки, скрытые возможности проникно- вения в систему; 2) без деструктивных функций (пассивные): а) скрытые каналы утечки информации: ♦ с использованием памяти. Для кодирования передавае- мой информации в этом случае используется либо об- 106
ласть памяти, не имеющая важного значения (напри- мер, установление характеристик признаков в имени и атрибутах файла), либо вообще неиспользуемая об- ласть (например, зарезервированные поля в заголовке сетевого пакета); ♦ с использованием времени. В этом случае информация кодируется определенной последовательностью и дли- тельностью событий, происходящих в системе (напри- мер, с помощью модуляции интервалов обращения к устройствам, введения задержек между приемом и посылкой сетевых пакетов и т. д.); б) другие. К их появлению обычно приводят расхождения между требованиями безопасности и требованиями к функ- циональным возможностям ВС. II. Непреднамеренные: ♦ ошибки контроля допустимых значений параметров; ♦ ошибки определения областей (доменов); ♦ ошибки последовательностей действий и использова- ния нескольких имен для одного объекта (в том числе TOCTTOU); ♦ ошибки идентификации/аутентификации; ♦ ошибки проверки границ объектов; ♦ другие ошибки в логике санкционирования. Этап внедрения ошибки и возникновения УЗ может про- исходить: ♦ на стадии разработки (ошибки при проектировании, при написании программ); ♦ на стадии настройки систем; ♦ на стадии сопровождения; ♦ на стадии эксплуатации. Классификация УЗ по размещению в системе. I. Программное обеспечение: 1) операционная система: ♦ инициализация (загрузка); ♦ управление выделением памяти; 107
♦ управление процессами; ♦ управление устройствами; ♦ управление файловой системой; ♦ средства идентификации и аутентификации; ♦ другие; 2) сервисные программы и утилиты: ♦ привилегированные утилиты; ♦ непривилегированные утилиты; 3) прикладные программы. II. Аппаратное размещение. Таксономия причин возникновения УЗ должна дать от- вет на имеющий ключевое значение с практической точки зрения вопрос: что явилось причиной успешного осуществ- ления нарушения безопасности в том или ином случае? Для ответа на этот вопрос необходимо выявить те свой- ства и особенности архитектуры ВС, которые привели к воз- можности успешного осуществления соответствующих атак. Только знание природы этих причин позволит оценить спо- собность системы противостоять атакам на ее безопасность, а также понять природу недостатков, присущих существую- щим средствам обеспечения безопасности, которые привели к соответствующим нарушениям, и построить защищенную систему, лишенную этих недостатков. К причинам нарушения безопасности ВС относятся: 1) причины, предопределенные на стадии разработки требований выбора модели безопасности, не соответствую- щей назначению или архитектуре ВС; 2) причины, обусловленные принципами организации си- стемы обеспечения безопасности: ♦ неправильное внедрение модели безопасности; ♦ отсутствие идентификации и/или аутентификации субъектов и объектов; ♦ отсутствие контроля целостности средств обеспечения безопасности; 3) причины, обусловленные реализацией: 108
♦ ошибок, допущенных в ходе программной реализации средств обеспечения безопасности; ♦ наличием средств отладки и тестирования в конечных продуктах; 4) ошибки администрирования. Предложенный подход к классификации причин наруше- ния безопасности, в отличие от существующих подходов, позволяет определить полное множество независимых пер- вопричин нарушений безопасности, не сводимых одна к дру- гой и образующих ортогональное пространство факторов, определяющих реальную степень безопасности системы. Сопоставление таксономии причин нарушений безопас- ности и классификации источников появления УЗ демонстри- рует тот факт, что источником появления наибольшего ко- личества категорий УЗ является неправильное внедрение мо- дели безопасности и ошибки в ходе программной реализации. Это означает, что эти причины являются более значимыми и должны быть устранены в первую очередь. А сопоставление между причинами нарушений безопас- ности и классификацией УЗ по этапу внесения показывает, что появление основных причин нарушения безопасности зак- ладывается на этапе разработки, причем в основном на ста- дии задания спецификаций. Это вполне ожидаемый резуль- тат, так как именно этап составления спецификаций являет- ся одним из самых трудоемких, а последствия ошибок в спе- цификациях сказываются на всех последующих этапах раз- работки и распространяются на все взаимосвязанные компо- ненты системы. Перекрестный анализ таксономии причин нарушений бе- зопасности и классификации УЗ по источнику появления и этапу внесения показывает, что наиболее значимые причи- ны (неправильное внедрение модели безопасности и ошибки программной реализации) действуют в ходе процесса разра- ботки и реализации. Следовательно, именно на этих этапах должны быть сосредоточены основные усилия при создании защищенных систем. 109
1.5.3. Способы и средства защиты информации Необходимость обеспечения скрытности (секретности) отдельных замыслов, действий, сообщений и т. п. возникла в глубокой древности, практически вместе с началом осмыс- ленной человеческой деятельности. Иными словами, органи- зация защиты, части информации от нежелательного (не- санкционированного) доступа к ней — проблема столь же древняя, как и само понятие информации. На современном этапе предпосылками сложившейся кри- зисной ситуации с обеспечением безопасности информацион- ных систем являются следующие: ♦ Современные компьютеры за последние годы приобре- ли большую вычислительную мощность, но одновре- менно с этим (что на первый взгляд парадоксально) стали гораздо проще в эксплуатации. ♦ Прогресс в области аппаратных средств сочетается с еще более бурным развитием программного обеспече- ния. ♦ Развитие гибких и мобильных технологий обработки информации привело к тому, что практически исчеза- ет грань между обрабатываемыми данными и исполня- емыми программами за счет появления и широкого рас- пространения виртуальных машин и интерпретаторов. ♦ Несоответствие бурного развития средств обработки информации и медленной проработки теории информа- ционной безопасности привело к появлению существен- ного разрыва между теоретическими моделями безо- пасности, оперирующими абстрактными понятиями типа объект, субъект и т. д., и реальными категориями со- временных информационных технологий. ♦ Необходимость создания глобального информационно- го пространства и обеспечение безопасности протека- ющих в нем процессов потребовала разработки между- народных стандартов, следование которым может обес- печить необходимый уровень гарантии обеспечения за- щиты. 110
Вследствие совокупного действия всех перечисленных факторов перед разработчиками современных информацион- ных систем, предназначенных для обработки конфиденциаль- ной информации, стоят следующие задачи, требующие не- медленного и эффективного решения: ♦ Обеспечение безопасности новых типов информацион- ных ресурсов. ♦ Организация доверенного взаимодействия сторон (вза- имной идентификации/аутентификации) в информаци- онном пространстве. ♦ Защита от автоматических средств нападения. ♦ Интеграция защиты информации в процессе автомати- зации ее обработки в качестве обязательного элемента. В настоящее время с ростом объемов обработки инфор- мации в компьютерных сетях, расширением круга ее потре- бителей, распространением многопрограммных режимов ра- боты ЭВМ, внедрением перспективных информационных тех- нологий данная проблема приобрела новый аспект в связи с возрастанием роли программно-технического посредника меж- ду человеком-пользователем и информационными объектами, что, в свою очередь, вызвало создание дополнительных спо- собов закрытия информации. Понятно, что проблема защиты информации приобрета- ет особое значение в экономической области, характеризую- щейся повышенными требованиями одновременно к скрыт- ности и оперативности обработки информации. Учитывая наибольшую сложность обеспечения защиты информации, обрабатываемой и передаваемой в компьютер- ных сетях различных типов, в дальнейшем рассмотрим преж- де всего эту часть общей проблемы (если иное не будет ого- ворено специально). Анализ уязвимости машинной информации позволяет выделить две группы возможных причин ее искажения или уничтожения: ♦ непреднамеренные действия (сбой технических средств, ошибки обслуживающего персонала и пользователей, аварии и т. п.); 111
♦ несанкционированные действия, к которым относятся непланируемый (несанкционированный) доступ и озна- комление субъектов с информацией; прямое хищение информации в электронном виде непосредственно на носителях; снятие слепков с носителей информации или копирование информации на другие носители; запре- щенная передача информации в линии связи или на терминалы; перехват электромагнитных излучений и информации по различным каналам связи и т. п. Понятно, что такое большое число причин искажения (уничтожения) информации определяет необходимость исполь- зования и значительного числа способов и средств ее защи- ты, причем эти способы и средства только тогда эффектив- ны, когда они применяются комплексно. Названные обстоя- тельства обуславливают содержание понятия “защита элект- ронной информации”. Под защитой информации в компьютерных системах принято понимать создание и поддержание организованной совокупности средств, способов, методов и мероприятий, предназначенных для предупреждения искажения, уничто- жения и несанкционированного использования информации, хранимой и обрабатываемой в электронном виде [54]. Наряду с определением понятия “защита информации” важным вопросом является классификация имеющихся спо- собов и средств защиты, которые позволяют воспрепятство- вать запрещенному (незаконному) ее использованию. На рис. 1.5.2 приведены наиболее часто используемые способы защиты информации в компьютерных сетях и средства, ко- торыми они могут быть реализованы (на рисунке эти возмож- ности изображены стрелками от способа к средствам). Рассмотрим краткое содержание каждого из способов. Препятствия предусматривают создание преград, физически не допускающих к информации. Управление доступом — спо- соб защиты информации за счет регулирования использова- ния всех ресурсов системы (технических, программных, вре- менных и др.). Маскировка информации, как правило, осуще- 112
ствляется путем ее криптографического закрытия. Регламен- тация заключается в реализации системы организационных мероприятий, определяющих все стороны обработки инфор- мации. Принуждение заставляет соблюдать определенные правила работы с информацией под угрозой материальной, административной или уголовной ответственности. Наконец, побуждение основано на использовании действенности мораль- но-этических категорий (например, авторитета или коллек- тивной ответственности). Рис. 1.5.2. Способы и средства защиты информации Средства защиты информации, хранимой и обрабаты- ваемой в электронном виде, разделяют на три самостоятель- ные группы: технические, программные и социально-право- вые. В свою очередь, среди технических средств защиты выделяют физические и аппаратные. 113
К физическим средствам защиты относятся: ♦ механические преграды, турникеты (заграждения); ♦ специальное остекление; ♦ сейфы, шкафы; ♦ механические и электромеханические замки, в том числе с дистанционным управлением; ♦ замки с кодовым набором; ♦ датчики различного типа; ♦ теле- и фотосистемы наблюдения и регистрации; ♦ СВЧ, ультразвуковые, радиолокационные, лазерные, акустические и т. п. системы; ♦ устройства маркировки; ♦ устройства с идентификационными картами; ♦ устройства идентификации по физическим признакам; ♦ устройства пространственного заземления; ♦ системы физического контроля доступа; ♦ системы охранного телевидения и охранной сигнализа- ции; ♦ системы пожаротушения и оповещения о пожаре и др. Под аппаратными средствами защиты понимают тех- нические устройства, встраиваемые непосредственно в сис- темы (аппаратуру) обработки информации. Наиболее час- то используют: ♦ регистры хранения реквизитов защиты (паролей, гри- фов секретности и т. п.); ♦ устройства для измерения индивидуальных характе- ристик человека (например, цвета и строения радуж- ной оболочки глаз, овала лица и т. п.); ♦ схемы контроля границ адреса имен для определения законности обращения к соответствующим полям (об- ластям) памяти и отдельным программам; ♦ схемы прерывания передачи информации в линии свя- зи с целью периодического контроля адресов выдачи данных; ♦ экранирование ЭВМ; ♦ установка генераторов помех и др. 114
Программные средства защиты данных в настоящее вре- мя получили значительное развитие. По целевому назначе- нию их можно разделить на несколько больших классов (групп): ♦ программы идентификации пользователей; ♦ программы определения прав (полномочий) пользова- телей (технических устройств); ♦ программы регистрации работы технических средств и пользователей (ведение так называемого системного журнала); ♦ программы уничтожения (затирания) информации пос- ле решения соответствующих задач или при наруше- нии пользователем определенных правил обработки информации; ♦ криптографические программы (программы шифрова- ния данных). Программные средства защиты информации часто под- разделяются на средства, реализуемые в стандартных опе- рационных системах и средства защиты в специализирован- ных информационных системах. К первым следует отнести: ♦ динамическое распределение ресурсов и запрещение задачам пользователей работать с ’’чужими” ресурса- ми; ♦ разграничение доступа пользователей к ресурсам по паролям; ♦ разграничение доступа к информации по ключам за- щиты; ♦ защита таблицы паролей с помощью главного пароля и ДР- Средства защиты в экономических информационных си- стемах, в том числе банковских системах, позволяют реали- зовать следующие функции защиты данных: ♦ опознавание по идентифицирующей информации пользователей и элементов информационной системы, разрешение на этой основе работы с информацией на определенном уровне; 115
♦ ведение многоразмерных таблиц профилей доступа пользователей к данным; ♦ управление доступом по профилям полномочий; ♦ уничтожение временно фиксируемых областей инфор- мации при завершении ее обработки; ♦ формирование протоколов обращений к защищаемым данным с идентификацией данных о пользователе и временных характеристик; ♦ программная поддержка работы терминала лица, отве- чающего за безопасность информации; ♦ подача сигналов при нарушении правил работы с сис- темой или правил обработки информации; ♦ физическая или программная блокировка возможности работы пользователя при нарушении им определенной последовательности правил или совершении определен- ных действий; ♦ подготовка отчетов о работе с различными данными — ведение подробных протоколов работы и др. Криптографические программы основаны на использо- вании методов шифрования (кодирования) информации. Дан- ные методы остаются достаточно надежными средствами ее защиты и более подробно будут рассмотрены ниже. В перспективе можно ожидать развития программных средств защиты по двум основным направлениям: ♦ создание централизованного ядра безопасности, управ- ляющего всеми средствами защиты информации в ЭВМ (на первом этапе — в составе ОС, затем — вне ее); ♦ децентрализация защиты информации вплоть до со- здания отдельных средств, управляемых непосредствен- но только пользователем. В рамках этого направления находят широкое применение методы “эстафетной па- лочки” и “паспорта”, основанные на предварительном расчете специальных контрольных кодов (по участкам контролируемых программ) и их сравнении с кодами, получаемыми в ходе решения задачи. Социально-правовые средства защиты информации можно подразделить на две группы. 116
Организационные и законодательные средства защиты информации предусматривают создание системы норматив- но-правовых документов, регламентирующих порядок раз- работки, внедрения и эксплуатации информации, а также ответственность должностных и юридических лиц за нару- шение установленных правил, законов, приказов, стандар- тов и т. п. Морально-этические средства защиты информации ос- нованы на использовании моральных и этических норм, гос- подствующих в обществе, и требуют от руководителей всех рангов особой заботы о создании в коллективах здоровой нрав- ственной атмосферы. 1.5.4. Формальные модели безопасности Наибольшее развитие получили два подхода, каждый из которых основан на своем видении проблемы безопасности и нацелен на решение определенных задач — это формальное моделирование политики безопасности и криптография. При- чем эти различные по происхождению и решаемым задачам подходы дополняют друг друга: криптография может предло- жить конкретные методы защиты информации в виде алго- ритмов идентификации, аутентификации, шифрования и кон- троля целостности, а формальные модели безопасности предо- ставляют разработчикам защищенных систем основополагаю- щие принципы, которые лежат в основе архитектуры защи- щенной системы и определяют концепцию ее построения. Модель политики безопасности — формальное выраже- ние политики безопасности. Формальные модели используются достаточно широко, потому что только с их помощью можно доказать безопас- ность системы, опираясь при этом на объективные и неопро- вержимые постулаты математической теории. Основная цель создания политики безопасности инфор- мационной системы и описания ее в виде формальной моде- ли — это определение условий, которым должно подчинять- ся поведение системы, выработка критерия безопасности и 117
проведение формального доказательства соответствия сис- темы этому критерию при соблюдении установленных правил и ограничений. На практике это означает, что только соот- ветствующим образом уполномоченные пользователя полу- чат доступ к информации, и смогут осуществлять с ней толь- ко санкционированные действия. Среди моделей политик безопасности можно выделить два основных класса: дискреционные (произвольные) и ман- датные (нормативные). В данном разделе в качестве примера изложены основные положения наиболее распространенных политик безопасности, основанных на контроле доступа субъектов к объектам. Дискреционная модель Харрисона-Руззо-Ульмана Модель безопасности Харрисона-Руззо-Ульмана, являю- щаяся классической дискреционной моделью, реализует про- извольное управление доступом субъектов к объектам и кон- троль за распространением прав доступа. В рамках этой модели система обработки информации представляется в виде совокупности активных сущностей — субъектов (множество S), которые осуществляют доступ к информации, пассивных сущностей — объектов (множество О), содержащих защищаемую информацию, и конечного мно- жества прав доступа R={r1,...,rn}, означающих полномочия на выполнение соответствующих действий (например, чтение, запись, выполнение). Причем для того, чтобы включить в область действия модели и отношения между субъектами, принято считать, что все субъекты одновременно являются и объектами. По- ведение системы моделируется с помощью понятия состоя- ния. Пространство состояний системы образуется декартовым произведением множеств составляющих ее объектов, субъек- тов и прав — OxSxR. Текущее состояние системы Q в этом пространстве определяется тройкой, состоящей из множе- ства субъектов, множества объектов и матрицы М прав дос- тупа, описывающей текущие права доступа субъектов к объек- там: Q = (S, О, М). Строки матрицы соответствуют субъек- 118
там, а столбцы — объектам. Поскольку множество объектов включает в себя множество субъектов, матрица имеет вид прямоугольника. Любая ячейка матрицы M[s,o] содержит на- бор прав субъекта s к объекту о, принадлежащих множеству прав доступа R. Поведение системы во времени моделирует- ся переходами между различными состояниями. Переход осу- ществляется путем внесения изменений в матрицу М с помо- щью команд следующего вида: Command a(xv..xm) If Tj in M[xSi, xOi] and (условия выполнения команды) r2 in M[xS2, xO2] and rm in M[xSm, xoJ then opi, op2...opm (операции, составляющие команду), где а — имя команды; X; — параметры команды, являющиеся идентификатора- ми субъектов и объектов; Sj — индексы субъектов; О; — индексы объектов; opj — элементарные операции. Элементарные операции, составляющие команду, выпол- няются только в том случае, если все условия, означающие присутствие указанных прав доступа в ячейках матрицы М, являются истинными. В классической модели допустимы толь- ко следующие элементарные операции: enter г into M[s,o] delete r from M[s,o] create subject s create object о destroy subject s destroy object о (добавление субъекту s права г для объекта о); (удаление у субъекта s права г для объекта о); (создание нового субъекта s); (создание нового объекта о); (удаление существующего субъекта s); (удаление существующего объекта о). 119
Критерий безопасности модели Харрисона-Руззо-Ульма- на формулируется следующим образом. Для заданной системы начальное состояние Qo = (So, Q0) Мо) является безопасным относительно права г0, если не су- ществует применимой к Qo последовательности команд, в ре- зультате которой право г0 будет занесено в ячейку матрицы М, в которой оно отсутствовало в состоянии Qo. Нужно отметить, что все дискреционные модели уязви- мы по отношению к атаке с помощью “троянского коня”, поскольку в них контролируются только операции доступа субъектов к объектам, а не потоки информации между ними. Поэтому, когда “троянская” программа, которую нарушитель подсунул некоторому пользователю, переносит информацию из доступного этому объекта в объект, доступный нарушите- лю, то формально никакое правило дискреционной полити- ки безопасности не нарушается, но утечка информации про- исходит. Таким образом, дискреционная модель Харрисона-Руз- зо-Ульмана в своей общей постановке не дает гарантий безо- пасности системы, однако именно она послужила основой для целого класса моделей политик безопасности, которые ис- пользуются для управления доступом и контроля за распре- делением прав во всех современных системах. Типизованная матрица доступа Другая дискреционная модель, получившая название “Типизованная матрица доступа” (Type Access Matrix — да- лее ТАМ), представляет собой развитие модели Харрисона- Руззо-Ульмана, дополненной концепцией типов, что позво- ляет несколько смягчить те условия, для которых возможно доказательство безопасности системы. Состояние системы описывается четверкой Q = (S, О, t, М), где S, О, и М обозначают соответственно множество субъектов, объектов и матрицу доступа, a t:O—>Т — функция, ставящая в соответствие каждому объекту некоторый тип. Состояние системы изменяется с помощью команд из множества С. Команды ТАМ имеют тот же формат, что и в 120
модели Харрисона-Руззо-Ульмана, но всем параметрам при- писывается определенный тип: Command a(x1:t1,...,xm:tm) If гj in M[xs , xo ] and (условия выполнения команды) r2 in M[xS2, Xq^] and rm in M[XSm, xOm] then opp op2,...,opm (операции, составляющие команду). Перед выполнением команды происходит проверка типов фактических параметров, и, если они не совпадают с ука- занными в определении, команда не выполняется. Фактичес- ки, введение контроля типов для параметров команд приво- дит к неявному введению дополнительных условий, так как команды могут быть выполнены только при совпадении типов параметров. В модели используются следующие шесть эле- ментарных операций, отличающихся от аналогичных опера- ций модели Харрисона-Руззо-Ульмана только использовани- ем типизованных параметров: enter г into M[s,o] create subject s of type t • Монотонные операции create object о of type t delete r from M[s,o] destroy subject s destroy object о • Немонотонные операции Смысл элементарных операций совпадает со смыслом аналогичных операций их классической модели Харрисона- Руззо-Ульмана с точностью до использования типов. Таким образом, ТАМ является обобщением модели Хар- рисона-Руззо-Ульмана, которую можно рассматривать как частный случай ТАМ с одним единственным типом, к которо- му относятся все объекты и субъекты. Появление в каждой 121
команде дополнительных неявных условий, ограничивающих область применения команды только сущностями соответству- ющих типов, позволяет несколько смягчить жесткие усло- вия классической модели, при которых критерий безопаснос- ти является разрешимым. Несмотря на различающиеся подходы, суть всех моде- лей безопасности одинакова, поскольку они предназначены для решения одних и тех же задач. Целью построения моде- ли является получение формального доказательства безопас- ности системы, а также определения достаточного критерия безопасности. Безопасность системы определяется в равной степени тремя факторами: свойствами самой модели, ее адекватностью угро- зам, воздействующим на систему, и тем, насколько коррект- но она реализована. Поскольку при существующем разнообра- зии теоретических наработок в области теории информацион- ной безопасности выбор модели, адекватной заданным угро- зам, не является проблемой, последнее, решающее, слово остается за ее реализацией в защищенной системе. 1.5.5. Шифрование — специфический способ защиты информации Шифрование информации, хранимой и обрабатываемой в электронном виде, — это нестандартная кодировка дан- ных, исключающая или серьезно затрудняющая возможность их прочтения (получения в открытом виде) без соответ- ствующего программного или аппаратного обеспечения и, как правило, требующая для открытия данных предъявле- ния строго определенного ключа (пароля, карты, отпечат- ка и т. д.). Шифрование условно объединяет четыре аспекта защиты информации: управление доступом, регистрацию и учет, криптографическую защиту, обеспечение целостнос- ти информации. Оно включает в себя непосредственное шиф- рование информации, электронную подпись и контроль дос- тупа к информации. Шифрование направлено на достижение четырех основных целей. 122
1. Статическая защита информации, хранящейся на же- стком диске компьютера или дискетах (шифрование файлов, фрагментов файлов или всего дискового пространства), ис- ключает или серьезно затрудняет доступ к информации ли- цам, не владеющим паролем (ключом), т. е. защищает данные от постороннего доступа в отсутствие владельца информа- ции. Статическое шифрование применяется в целях инфор- мационной безопасности на случай похищения файлов, дис- кет или компьютеров целиком (жестких дисков компьютеров) и исключения возможности прочтения данных любыми по- сторонними (не владеющими паролем) лицами. Наиболее продвинутой формой статической защиты ин- формации является прозрачное шифрование (рис. 1.5.3), при котором данные, попадающие на защищенный диск, автома- тически шифруются (кодируются) вне зависимости от приро- ды операции записи, а при считывании с диска в оператив- ную память автоматически дешифрируются, так что пользователь вообще не ощущает, что находится под неусып- ной защитой невидимого стража информации. - 2. Разделение прав и контроль доступа к данным. Пользо- ватель может владеть своими личными данными (разными компьютерами, физическими или логическими дисками од- ного компьютера, просто разными директориями и файла- ми), недоступными другим пользователям. 3. Защита отправляемых (передаваемых) данных через третьи лица, в том числе по электронной почте или в рам- ках локальной сети. 4. Идентификация подлинности (аутентификация) и кон- троль целостности переданных через третьи лица докумен- тов. Шифровальные методы подразделяются на два принци- пиальных направления: ♦ симметричные классические методы с секретным клю- чом, в которых для зашифровки и дешифрации требу- ется предъявление одного и того же ключа (пароля); ♦ асимметричные методы с открытым ключом, в ко- торых для зашифровки и дешифрации требуется 123
предъявление двух различных ключей, один из кото- рых объявляется секретным (приватным), а второй — открытым (публичным), причем пара ключей всегда такова, что по публичному невозможно восстановить приватный, и ни один из них не подходит для решения обратной задачи. ---->- Шифрование ----Расшифровка ---Передача без изменений Рис. 1.5.3. Общая схема прозрачной дисковой защиты Как правило, шифрование производится путем выполне- ния некоторой математической (или логической) операции (се- рии операций) над каждым блоком битов исходных данных (так называемая криптографическая обработка). Применяются так- же методы рассеивания информации, например, обыкновен- ное разделение данных на нетривиально собираемые части, или стеганография, при которой исходные открытые данные размещаются определенным алгоритмом в массиве случайных данных, как бы растворяясь в нем. От произвольной трансфор- мации данных шифрование отличается тем, что выполняемое им преобразование всегда обратимо при наличии симмет- ричного или асимметричного ключа дешифрации. Идентификация подлинности и контроль целостности основываются на том, что дешифрация данных с определен- ным ключом возможна только в случае, если они были за- шифрованы с соответствующим (тем же или парным) ключом и не подверглись изменению в зашифрованном виде. Таким 124
образом, если в случае симметричного метода обеспечена секретность (уникальность) двух копий одного ключа, а в слу- чае асимметричного метода секретность (уникальность) од- ного из пары ключей, успех операции дешифрации данных гарантирует их подлинность и целостность (разумеется, при условии надежности используемого метода и чистоты его программной или аппаратной реализации). Шифрование — наиболее общий и надежный, при доста- точном качестве программной или аппаратной системы, спо- соб защиты информации, обеспечивающий практически все его аспекты, включая разграничение прав доступа и иденти- фикацию подлинности (“электронную подпись”). Однако су- ществуют два обстоятельства, которые необходимо учиты- вать при использовании программных средств, реализующих данное направление. Во-первых, любое зашифрованное сооб- щение в принципе всегда может быть расшифровано (хотя время, затрачиваемое на это, подчас делает результат рас- шифровки практически бесполезным). Во-вторых, перед не- посредственной обработкой информации и выдачей ее пользо- вателю производится расшифровка — при этом информа- ция становится открытой для перехвата. С точки зрения качества защиты информации шифрова- ние можно условно разделить на “сильное”, или”абсолют- ное”, практически не вскрываемое без знания пароля, и “сла- бое”, затрудняющее доступ к данным, но практически (при использовании современных ЭВМ) вскрываемое тем или иным способом за реальное время без знания исходного пароля. Способы вскрытия информации в современных компьютер- ных сетях включают: ♦ подбор пароля или рабочего ключа шифрования пере- бором (brute-force attack); ♦ угадывание пароля (key-guessing attack); ♦ подбор или угадывание пароля при известной части пароля; ♦ взлом собственно алгоритма шифрования. Вне зависимости от метода шифрования любой шифр является слабым (т. е. вскрываемым за реальное время), если 125
длина пароля недостаточно велика. Приводимые в табл. 1.5.2 данные показывают время, требуемое на подбор пароля на ЭВМ класса Pentium/200 МГц в зависимости от длины паро- ля и допустимых при его формировании знаков при вскры- тии информации. В зависимости от сложности применяемого алгоритма ука- занные времена могут быть увеличены в фиксированное число раз (в среднем в 10—1000). Микропроцессор Pentium 11/450 МГц или даже Pentium III превосходит Pentium/200 МГц по про- изводительности не более чем в 10 раз, использование супе- рЭВМ (например, “Эльбрус”) позволяет сократить время пе- ребора не более чем в 10 000 раз, что, учитывая порядок приведенных в таблице чисел, абсолютно непринципиально. Таким образом, если пароль включает только латинс- кие буквы без различения регистра, то любой шифр явля- ется слабым при длине пароля менее 10 знаков (очень сла- бым — при длине пароля менее 8 знаков); если пароль вклю- чает только латинские буквы с различением регистра и циф- ры, то шифр является слабым при длине пароля менее 8 знаков (очень слабым — при длине пароля менее 6 зна- ков); если же допускается использование всех возможных 256 знаков, то шифр является слабым при длине пароля менее 6 знаков. Однако длинный пароль сам по себе еще не означает высокую степень защиты, поскольку защищает данные от взлома подбором пароля, но не угадыванием. Угадывание пароля основано на специально разработанных таблицах ассоциации, построенных на статистических и лингво-психо- логических свойствах словообразования, словосочетаний и буквосочетаний того или иного языка, и способно на поряд- ки сократить пространство полного перебора. Так, если для подбора пароля “Мама мыла раму” полным перебором требу- ются миллиарды лет на сверхмощных ЭВМ, то угадывание этого же пароля по таблицам ассоциации займет считанные дни или даже часы. 126
Таблица 1.5.2 Время на подбор пароля на ЭВМ Pentium/200 МГц в зависимости от его длины и допустимых при его формировании знаков Число знаков пароля 4 5 6 7 8 9 10 Состав пароля Только цифры Ос 0,01 с 0,08 с 0,83 с 8 с 4 мни 14 мин Латинские бук- вы без учета регистра 0,04 с 0,9 с 25 с 12 мин 4,9 ч 5,2 дня 0,4 года Латинские бук- вы без учета регистра и цифры 0,14 с 5,5 с 3 мин 1,8 ч 2,7 дня 0,27 года 9,7 года Латинские бук- вы с учетом регистра и цифры 1,2 с 1,3 мин 1,3 ч 3,4 дня 0,58 года 35,7 года 2220 лет Все возможные символы 6 мин 1,06 дня 0,74 года 190 лет 48,7 тыс. лет 12 млн лет 3,2 млрд лет Подбор или угадывание пароля при известной части пароля также существенно упрощает взлом. Например, зная особенности работы человека за компьютером или видя (или даже слыша) издали, как он набирает пароль, можно уста- новить точное число знаков пароля и приблизительные зоны клавиатуры, в которых нажимаются клавиши. Такие наблю- дения также могут сократить время подбора с миллиардов лет до нескольких часов. Даже если примененный пароль и рабочий ключ доста- точно сложны, возможность взлома алгоритма шифрования поистине не знает границ. Из наиболее известных подходов можно выделить: ♦ математическое обращение применяемого метода; ♦ взлом шифра по известным парам открытых и соответ- ствующих закрытых данных (метод plaintext attack); ♦ поиск особых точек метода (метод singularity attack) — дублирующих ключей (различных ключей, порождаю- щих одинаковые вспомогательные информационные 127
массивы при шифровании различных исходных дан- ных), вырожденных ключей (порождающих тривиаль- ные или периодические фрагменты вспомогательных информационных массивов при шифровании различных исходных данных), а также вырожденных исходных данных; ♦ статистический, в частности дифференциальный, ана- лиз — изучение закономерностей зашифрованных тек- стов и пар открытых/зашифрованных текстов. Наиболее привычным и доступным каждому пользова- телю средством шифрования информации, хранимой и обра- батываемой в электронном виде, являются программы-архи- ваторы, как правило, содержащие встроенные средства шифрования. Согласно проведенным исследованиям [6, 21] максималь- ный рейтинг по степени сжатия и скорости имеет архиватор RAR, незначительно отстает от него программа архиватор PKZIP (при несколько худшей компрессии при выдающейся скорости). Защита данных с помощью электронной подписи Электронная — подпись вставка в данные (добавление) фрагмента инородной зашифрованной информации — приме- няется для идентификации подлинности переданных через третьи лица документов и произвольных данных. Сама пере- даваемая информация при этом никак не защищается, т. е. остается открытой и доступной для ознакомления тем лицам, через которых она передается (например, администраторам сети и инспекторам почтовых узлов электронной связи). Как правило, электронная подпись включает в себя спе- циальным образом вычисляемую контрольную сумму от дан- ных, с которыми она соотносится, за счет чего обеспечивает- ся контроль целостности данных. В электронных подписях может использоваться симмет- ричное шифрование, однако по сложившейся традиции по- чти все системы электронных подписей базируются на шиф- 128
ровании с открытым ключом. В этом случае для зашифрова- ния контрольной суммы от данных применяется секретный ключ пользователя, публичный ключ дешифрации может быть до- бавлен непосредственно к подписи, так что вся информация, необходимая для аутентификации и контроля целостности дан- ных, может находиться в одном (передаваемом) “конверте”. Достоверность собственно электронной подписи цели- ком и полностью определяется качеством шифрующей сис- темы. Однако на самом деле с электронной подписью все не так просто, и число ее уязвимых точек, базирующихся на шифровании с открытым ключом, также велико. С точки зре- ния решения задачи идентификации подлинности и контроля целостности полностью зашифрованный, файл и открытый файл с добавочной зашифрованной информацией, включаю- щей контрольную сумму данных (“электронной подписью”), абсолютно эквивалентны. Шифрование для обеспечения контроля прав доступа Контроль права доступа — простейшее средство за- щиты данных и ограничения (разграничения) использования компьютерных ресурсов, предназначенное для ограждения па- ролем определенной информации и системных ресурсов ЭВМ от лиц, не имеющих к ним отношения и не имеющих специ- ального умысла получить к ним доступ или не обладающих достаточной для этого квалификацией. Сами данные хранят- ся на дисках в открытом (незащищенном) виде и всегда могут быть востребованы (похищены) в обход системы контроля, сколь бы изощренной она ни была. Примерами систем, осу- ществляющих парольный контроль доступа, являются систе- мы Norton’s partition security system, Stacker, Fastback, Quicken, Microsoft Money, системы парольного контроля до- ступа при загрузке BIOS и т. д. Слабые шифры, реализуе- мые в известных программах Norton’s Diskreet, PKZIP, Unix crypt, Novell Netware, MS Excel, MS Word и др., для кото- рых известны эффективные способы взлома, также можно отнести к системам контроля доступа. 129
Несмотря на богатый научный потенциал России в облас- ти криптографии и особенно бурное ее развитие в начале 90-х гг. XX в., на настоящий момент единственным лицензиро- ванным ФАПСИ шифром является шифр по ГОСТ 28147-89, самому же ФАПСИ и принадлежащий. Все остальные систе- мы шифрования, предлагаемые зарубежными и отечествен- ными фирмами (системы Symantec, RSA Data Security, AT&T, PGP, ЛАН Крипто, Аладдин, Novex, Элиас, Анкад и многие др.) в виде законченных продуктов или библиотек, начиная с устоявшихся зарубежных стандартов (алгоритмов шифрова- ния DES, FEAL, IDEA) и кончая оригинальными новейшими разработками, являются в равной степени незаконными и приводят наиболее активных инициаторов их разработки и использования на грань уголовной ответственности. Право на хождение на территории России имеет только указанный ГОСТ, причем только в исполнении организации, обладаю- щей сертификатом ФАПСИ. Что же касается непосредственно надежности шифро- вания, то практически все используемые коммерческие и индивидуально разработанные алгоритмы шифрования яв- ляются слабыми. Кроме того, существуют коммерческие и некоммерческие версии дешифраторов для всех известных архиваторов (pkzip, arj и др.). Зарубежные”стандарты” шиф- рования (с учетом многообразия предлагаемых модификаций), экспортируемые некоторыми технологически развитыми стра- нами (в частности, США — алгоритм DES, Япония — алго- ритм FEAL), на самом деле являются стандартами соот- ветствующих разведслужб, предлагаемыми и внедряемыми на территориях дружеских государств. Исключением в спис- ке заведомо ненадежных систем шифрования, потенциаль- но доступных для пользователя, являются лишь некоторые — две или три — оригинальные российские разработки. Разделение систем шифрозащиты на сильные и слабые (как по длине используемого пароля, так и по надежности самой системы) имеет принципиальное значение, обуславли- вающее возможность реального применения как слабых, так 130
и сильных шифров в условиях их юридического запрета. Дело в том, что если используется заведомо слабая шифрозащита (например, программа pkzip с паролем), для которой суще- ствует эффективный взлом, то невозможно наверняка ут- верждать, что выбранное средство является криптосисте- мой. Скорее, речь идет о шифрообразном ограничении и кон- троле прав доступа. С другой стороны, любая программа шиф- рования может потенциально рассматриваться как слабый шифр, т. е. шифрообразный контроль доступа к данным. На- конец, каким бы шифром вы ни пользовались, применение коротких паролей безусловно переводит шифры в разряд слабых, не обеспечивающих должный уровень защиты ин- формации. 1.5.6. Защита информации от компьютерных вирусов Рассмотренные в предыдущих пунктах способы и сред- ства защиты информации являются в значительной мере уни- версальными и могут быть использованы в компьютерных се- тях с любой машинной базой и для любой операционной плат- формы. Вместе с тем в последние годы появилась необходи- мость разработки совершенно новых средств защиты инфор- мации, предназначенных для противодействия так называ- емым компьютерным вирусам, способным уничтожать или искажать информацию, обрабатываемую на персональных ЭВМ (ПЭВМ). Важность и значимость таких методов опреде- ляется несколькими основными факторам. Во-первых, ПЭВМ получили весьма широкое распрост- ранение во всех отраслях человеческой деятельности, и в том числе в военной, причем круг непосредственных пользовате- лей машин постоянно расширяется и в скором времени, оче- видно, охватит практически все трудоспособное население. Во-вторых, к настоящему времени разработаны разно- образные программные средства, существенно облегчающие использование новых информационных технологий, и расши- 131
риласъ область их сбыта и применения, что в ряде случаев способствует распространению “зараженных” программных продуктов. В-третьих, появилось значительное число программис- тов, способных самостоятельно создавать достаточно слож- ные версии компьютерных вирусов и по различным причи- нам делающих это (в качестве причин могут выступать и весь- ма необычные — от желания испытать свои силы, просла- виться, сделать рекламу своей квалификации и т. п. до со- знательных попыток сорвать работу тех или иных информа- ционных систем). Следует отметить, что проблема борьбы с компьютер- ными вирусами возникла тогда, когда программисты стали создавать и использовать свои программы в некоторой сис- темной среде, т. е. стали в определенном смысле по отноше- нию друг к другу обезличенными. И еще одно замечание: раз- работка компьютерных вирусов (и, соответственно, способов и средств борьбы с ними) не является вопросом науки, а име- ет чисто инженерный (“программистский”) уровень. “История” компьютерных вирусов ведет начало с 1984 г., когда Фред Коэн (США) написал программу, которая автома- тически активизировалась и проводила деструктивные изме- нения информации при незаконном обращении к другим про- граммам автора. После этого было создано большое количе- ство программ, предназначенных для вызова тех или иных “вредных” действий, и постепенно сформировалось самосто- ятельное инженерное направление по борьбе с ними. Компьютерные вирусы были и остаются одной из наи- более распространенных причин потери информации. Дан- ное положение особенно важно для локальных и глобальных компьютерных сетей, объединяющих работу сотен и милли- онов пользователей. Известны случаи, когда вирусы блокиро- вали работу организаций и предприятий. Более того, несколько лет назад был зафиксирован случай, когда компьютерный вирус стал причиной гибели человека — в одном из госпита- лей Нидерландов пациент получил летальную дозу морфия 132
по той причине, что компьютер был заражен вирусом и вы- давал неверную информацию. Несмотря на огромные усилия конкурирующих между собой антивирусных фирм (разрабатывающих программы про- тив вирусов), убытки, приносимые компьютерными вируса- ми, не падают и достигают астрономических величин, изме- ряемых сотнями миллионов долларов ежегодно. Особенно эти потери актуальны в больших компьютерных сетях. Так, на- пример, в апреле 1999 г. только по причине деструктивного действия одного компьютерного вируса под названием Win95.CIH во Франции было поражено более 100 тыс. бан- ковских компьютеров с общим ущербом более 300 млн. долл. Надо полагать, что эти оценки явно занижены, поскольку известно становится лишь о части подобных инцидентов. При этом следует иметь в виду, что используемые анти- вирусные программы и аппаратная часть не дают полной га- рантии защиты от вирусов. Примерно так же плохо обстоят дела на другой стороне тандема “человек—компьютер”. Как прикладные пользователи, так и профессионалы-программи- сты часто не имеют даже навыков “самообороны” от виру- сов, а их представления о проблеме порой весьма и весьма поверхностны. Что же представляет собой компьютерный вирус? Ком- пьютерный вирус — это специально написанная, как прави- ло, на языке программирования низкого уровня, небольшая по размерам программа, которая может”приписывать” себя к другим программам и выполнять различные нежелатель- ные для пользователя действия на компьютере. Жизненный цикл вируса включает четыре основных этапа [53]: ♦ внедрение', ♦ инкубационный период (прежде всего для скрытия ис- точника проникновения); ♦ репродуцирование (саморазмножение); ♦ деструкция (искажение и/или уничтожение инфор- мации). 133
Заметим, что использование медицинской (вирусологи- ческой) терминологии связано с тем, что по характеру жиз- недеятельности и проявлениям программы-вирусы сходны с настоящими (“живыми”) вирусами. В этой связи естествен- ным является применение той же терминологии и для спосо- бов и средств борьбы с компьютерными вирусами: “антиви- рус”, “карантин”, “вакцина”, “фаг” и т. п., о чем более под- робно будет сказано далее. Для реализации каждого из этапов цикла жизни вируса в его структуру включают несколько взаимосвязанных эле- ментов: ♦ часть вируса, ответственная за внедрение и инкубаци- онный период; ♦ часть вируса, осуществляющая его копирование и до- бавление к другим файлам (программам); ♦ часть вируса, в которой реализуется проверка условия активизации его деятельности; ♦ часть вируса, содержащая алгоритм деструктивных действий; ♦ часть вируса, реализующая алгоритм саморазрушения. Следует помнить, что часто названные части вируса хранятся отдельно друг от друга, что затрудняет борьбу с ними. Объекты воздействия компьютерных вирусов можно ус- ловно разделить на две группы: ♦ с целью продления своего существования вирусы пора- жают другие программы, причем не все, а те, кото- рые наиболее часто используются и/или имеют высо- кий приоритет в вычислительной системе (заметим, что сами программы, в которых находятся вирусы, с точки зрения реализуемых ими функций, как правило, не портятся); ♦ деструктивными целями вирусы воздействуют чаще всего на данные, реже — на программы. Назовем наиболее широко распространившиеся деструк- тивные функции вирусов: 134
♦ изменение данных в соответствующих файлах; ♦ изменение назначенного магнитного диска, когда за- пись информации осуществляется на неизвестный пользователю диск; ♦ уничтожение информации путем форматирования дис- ка или отдельных треков (дорожек) на нем; ♦ уничтожение каталога файлов или отдельных файлов на диске; ♦ уничтожение (выключение) программ, постоянно на- ходящихся в операционной системе; ♦ нарушение работоспособности ОС, что требует ее пе- риодической перезагрузки; ♦ уничтожение специальных файлов ОС и др. Классифицировать компьютерные вирусы можно по раз- личным признакам. Укажем четыре из них [53]: ♦ среда обитания; ♦ операционная система; ♦ особенности алгоритма работы; ♦ деструктивные возможности. По среде обитания вирусы можно разделить на типы: ♦ файловые; ♦ загрузочные; ♦ макровирусы; ♦ сетевые. Файловые вирусы либо различными способами внедря- ются в выполняемые файлы (наиболее распространенный тип вирусов), либо создают файлы-двойники (компаньон-вирусы), либо используют особенности организации файловой систе- мы (link-вирусы). Загрузочные вирусы записывают себя либо в загрузоч- ный сектор диска (boot-сектор), либо в сектор, содержащий системный загрузчик винчестера (Master Boot Record), либо меняют указатель на активный boot-сектор. Макровирусы заражают файлы-документы, электронные таблицы и презентации ряда популярных редакторов. 135
Сетевые вирусы используют для своего распростране- ния протоколы или команды компьютерных сетей и элект- ронной почты. Существует большое количество сочетаний — напри- мер, файлово-загрузочные вирусы, заражающие как фай- лы, так и загрузочные сектора дисков. Такие вирусы, как правило, имеют довольно сложный алгоритм работы, часто применяют оригинальные методы проникновения в операци- онную систему, используют стеле- и полиморфик-техноло- гии. Другой пример такого сочетания — сетевой макровирус, который не только заражает редактируемые документы, но и рассылает свои копии по электронной почте (например, “I love you” или “Анна Курникова”). Заражаемая операционная система (вернее, ОС, объек- ты которой подвержены заражению) является вторым уров- нем деления вирусов на классы. Каждый файловый или сете- вой вирус заражает файлы какой-либо одной или нескольких ОС: DOS, Win95/98/NT, OS/2 и т. д. Макровирусы заражают файлы форматов Word, Excel, Power Point, Office 97. За- грузочные вирусы также ориентированы на конкретные фор- маты расположения системных данных в загрузочных секто- рах дисков. Среди особенностей алгоритма работы вирусов выде- ляются следующие: ♦ резидентность; ♦ использование стелс-алгоритмов; ♦ самошифрование и полиморфичность; ♦ использование нестандартных приемов. Резидентный вирус при инфицировании компьютера ос- тавляет в оперативной памяти свою резидентную часть, ко- торая затем перехватывает обращения операционной систе- мы к объектам заражения и внедряется в них. Резидентные вирусы находятся в памяти и являются активными вплоть до выключения компьютера или перезагрузки операционной си- стемы. Нерезидентные вирусы не заражают память компью- тера и сохраняют активность ограниченное время. Некото- 136
рые вирусы оставляют в оперативной памяти небольшие ре- зидентные программы или функции, которые не распрост- раняют вирус. Такие вирусы считаются нерезидентными. Резидентными можно считать макровирусы, поскольку они постоянно присутствуют в памяти компьютера на все время работы зараженного редактора. При этом роль опера- ционной системы берет на себя редактор, а понятие “пере- загрузка операционной системы” трактуется как выход из редактора. В многозадачных операционных системах время “жизни” резидентного DOS-вируса также может быть ограничено мо- ментом закрытия зараженного DOS-окна, а активность за- грузочных вирусов в некоторых операционных системах ог- раничивается моментом инсталляции дисковых драйверов ОС. Использование стеле-алгоритмов позволяет вирусам полностью или частично скрыть себя в системе. Наиболее распространенным стелс-алгоритмом является перехват зап- росов ОС на чтение/запись зараженных объектов. Стелс-ви- русы при этом либо временно лечат их, либо “подставляют” вместо себя незараженные участки информации. В случае макровирусов наиболее популярный способ — запрет вызо- вов меню просмотра макросов. Один из первых файловых стелс- вирусов — вирус “Frodo”, первый загрузочный стелс-вирус — “Brain”. Самошифрование и полиморфичностъ используются прак- тически всеми типами вирусов для того, чтобы максимально усложнить процедуру детектирования вируса. Полиморфик- вирусы — это достаточно труднообнаружимые вирусы, не имеющие сигнатур, т. е. не содержащие ни одного постоян- ного участка кода. В большинстве случаев два образца одно- го и того же полиморфик-вируса не будут иметь ни одного совпадения. Это достигается шифрованием основного тела вируса и модификациями программы-расшифровщика. Различные нестандартные приемы часто используют- ся в вирусах для того, чтобы как можно глубже спрятать себя в ядре ОС (как это делает вирус “Зараза”), защитить от 137
обнаружения свою резидентную копию (вирусы “TPVO”, “Trout2”), затруднить лечение от вируса (например, помес- тив свою копию в Flash-BIOS) и т. д. По деструктивным возможностям вирусы можно раз- делить на следующие: ♦ безвредные, т. е. никак не влияющие на работу компью- тера (кроме уменьшения свободной памяти на диске в результате своего распространения); ♦ неопасные, влияние которых ограничивается уменьше- нием свободной памяти на диске и графическими, зву- ковыми и т. п. эффектами; ♦ опасные вирусы, которые могут привести к серьезным сбоям в работе компьютера; ♦ очень опасные, в алгоритм работы которых заведомо заложены процедуры, которые могут привести к поте- ре программ, уничтожить данные, стереть необходи- мую для работы компьютера информацию, записанную в системных областях памяти, и даже, как гласит одна из непроверенных компьютерных легенд, способство- вать быстрому износу движущихся частей механиз- мов — вводить в резонанс и разрушать головки некото- рых типов винчестеров. На сегодняшний день сложились установившиеся назва- ния для некоторых типов вирусов. Так, “ловушками” называ- ют вирусы, использующие имеющиеся неточности в действу- ющих программах или их несовершенство (например, изме- няющие адрес входа из программы в подпрограммы и обрат- но). “Логические бомбы”, или “бомбы замедленного действия”, осуществляют длительную и разнообразную подготовку к про- ведению деструктивных действий и затем срабатывают при выполнении определенного комплекса условий (например, выполнении определенного этапа работ, наступлении задан- ного времени, обращении к программе определенного пользо- вателя и т. п.). Эти вирусы особенно опасны в силу длительно- сти периода времени, при котором они себя практически не обнаруживают, хотя уже ведут разрушительную работу. Факт 138
проявления этих вирусов сопряжен с такой степенью порчи данных, что в установленной версии ОС оказываются нера- ботоспособными практически все программы (или их боль- шинство). Таким образом, машина становится полностью не- работоспособной. Вирусы-“черви” вызывают неуправляемое функционирование, например, сетевых или периферийных устройств (бесконечный “прогон” бумаги в принтере, посто- янную перезагрузку операционной системы и т. п.). “Троянс- кими конями” называют вирусы, распространяемые вместе с программным обеспечением специального назначения, при- чем для пользователя оказываются крайне неожиданными их деструктивные действия (например, таким вирусом могут быть заражены сами антивирусные программы). Внешне “троян- цы” могут даже выполнять некие полезные функции (фик- тивно оптимизировать распределение памяти на компьюте- ре, проводить уплотнение информации на диске и т. п.), но на самом деле либо разрушают систему (например, форма- тируют ваш винчестер на низком уровне или операцией мно- гократного и оперативного считывания записи информации способствуют механическому выведению из строя дисковода вашего компьютера), либо отдают контроль в руки другого человека. Пород “троянцев” множество: некоторые из них вообще не выполняют полезных функций, а просто скрытно “живут” на диске ЭВМ и совершают различные деструктив- ные действия, а некоторые, наоборот, совершенно не скры- ваются от пользователя, при этом производя некоторые ма- нипуляции, о которых никто не подозревает (или не должен подозревать). Пример вируса первого типа — известный ви- рус Back Orifice, дающий ’’врагу” почти полный контроль над вашим компьютером в компьютерной сети и для вас невиди- мый. Пример вируса второго типа — подделки под браузер MS Internet Explorer, который при соединении с сайтом фирмы Майкрософт развивает небывалую активность по пересылке данных с компьютера на сервер Майкрософт, объем которых явно превосходит простой запрос скачиваемого HTML доку- мента (Web-страницы с Интернет). 139
Для того чтобы применить тот или иной способ борьбы с конкретным вирусом, нужно сначала осуществить его диаг- ностику (хотя следует признать, что все современные ме- тоды диагностики вирусов являются несовершенными). На- званной цели служат программы трех типов: ♦ программы для выявления наличия вируса; ♦ программы для обнаружения и удаления вируса; ♦ программы защиты от вирусов (препятствующие про- никновению новых вирусов). Борьба с вирусами ведется путем применения программ- антивирусов. Антивирус — программа, осуществляющая обнаружение или обнаружение и удаление вируса. Самыми популярными и эффективными антивирусными программами являются [25] антивирусные сканеры (другие названия: фаги, полифаги). Следом за ними по эффективности и популярнос- ти следуют CRC-сканеры (также: ревизоры, checksumer, integrity checker). Часто оба приведенных метода объединя- ются в одну универсальную антивирусную программу, что значительно повышает ее мощность. Применяются также различного типа блокировщики и иммунизаторы. Проблема защиты от макровирусов Поскольку проблема макровирусов в последнее время перекрывает все остальные проблемы, связанные с прочими вирусами, на ней следует остановиться подробнее. Существует несколько приемов и встроенных в Word/ Excel и другие программы функций, направленных на пре- дотвращение запуска вируса. Наиболее действенной из них является защита от вирусов, встроенная в Word и Excel (на- чиная с версий 7.0). Эта защита при открытии файла, содер- жащего любой макрос, сообщает о его присутствии и пред- лагает запретить этот макрос. В результате макрос не только не выполняется, но и не виден средствами Word/Excel. Такая защита является достаточно надежной, однако абсолютно бесполезна, если пользователь работает с макро- сами (любыми): она не отличает макросы вируса от не-вируса 140
и выводит предупреждающее сообщение при открытии прак- тически любого файла. По этой причине защита в большин- стве случаев оказывается отключенной, что дает возмож- ность вирусу проникнуть в систему. К тому же включение защиты от вирусов в уже зараженной системе не во всех случаях помогает — некоторые вирусы, однажды получив управление, при каждом запуске отключают защиту от ви- русов и таким образом полностью блокируют ее. Существуют другие методы противодействия вирусам, например функция DisableAutoMacros, однако она не запре- щает выполнение прочих макросов и блокирует только те вирусы, которые для своего распространения используют один из автомакросов. Запуск редактора Word с опцией /М (или с нажатой кла- вишей Shift) не является локацией от всех бед, а только от- ключает один макрос AutoExec и таким образом также не может служить надежной защитой от вируса. Сетевые вирусы Среди множества известных вирусов особое место зани- мают сетевые вирусы, как правило, они считаются и наибо- лее опасными [24]. Возможность инфицирования компьютерными вирусами корпоративных компьютерных сетей становится все более серьезной проблемой. Опасность действия вирусов определя- ется возможностью частичной или полной потери ценной ин- формации, а также потерей времени и средств, направлен- ных на восстановление нормального функционирования ин- формационных систем. Обычная корпоративная компьютерная сеть включает в себя сотни рабочих станций, десятки серверов и, как прави- ло, имеет очень сложную структуру. Стоимость обслужива- ния такой сети растет вместе с ростом числа подключенных рабочих станций. При этом расходы на антивирусную защиту являются не последним пунктом в списке общих расходов. Основной возможностью их снижения является централиза- ция управления работой антивирусной системы, установ- 141
ленной в корпоративной компьютерной сети. Администратор должен иметь возможность с одного рабочего места вести мониторинг всех точек проникновения вирусов и управлять всеми антивирусными продуктами, перекрывающими эти точки. Компьютерные вирусы проникают в сеть вместе с фай- лами. Основные пути, которыми файлы, зараженные виру- сами, попадают в корпоративную сеть: ♦ копирование инфицированных файлов или при запуске программ и других файлов с переносимых источников (гибких дисков, оптических дисков, Zip, Jazz, Floptical и т. д.); ♦ программное обеспечение, полученное через Web или FTR и сохраненное на локальных рабочих станциях; ♦ файлы, получаемые удаленными пользователями, ко- торые соединяются с корпоративной сетью по модему; ♦ файлы, получаемые при соединении удаленного сервера с сетью для обмена с файловым сервером, сервером приложений или сервером баз данных; ♦ электронная почта, содержащая приложенные зара- женные файлы. Глобальная компьютерная сеть Интернет на сегодняш- ний день также является основным источником вирусов. Наи- большее число заражений вирусом происходит при обмене письмами в форматах Word/Office. Пользователь зараженно- го макровирусом редактора, сам того не подозревая, рассы- лает зараженные письма адресатам, которые, в свою оче- редь, отправляют новые зараженные письма и т. д. К сете- вым относятся вирусы, которые для своего распространения активно используют протоколы и возможности локальных и глобальных сетей. Основным принципом работы сетевого ви- руса является возможность самостоятельно передать свой код на удаленный сервер или рабочую станцию. “Полноценные” сетевые вирусы при этом обладают еще и возможностью за- пустить на выполнение свой код на удаленном компьютере или, по крайней мере, “подтолкнуть” пользователя к запус- ку зараженного файла. 142
Бытует ошибочное мнение, что сетевым является любой вирус, распространяющийся в компьютерной сети. Но в та- ком случае практически все вирусы были бы сетевыми, даже наиболее примитивные из них: ведь самый обычный нерези- дентный вирус при заражении файлов не разбирается — се- тевой (удаленный) это диск или локальный. В результате та- кой вирус способен заражать файлы в пределах сети, но от- нести его к сетевым вирусам нельзя. Наибольшую известность приобрели сетевые вирусы кон- ца 1980-х гг., их также называют сетевыми червями (worms). К ним относятся вирус Морриса, вирусы “Cristmas Tree” “Wank Worm&”. Для своего распространения они использо- вали ошибки и недокументированные функции глобальных сетей того времени — вирусы передавали свои копии с сер- вера на сервер и запускали их на выполнение. В случае с вирусом Морриса эпидемия захватила даже несколько гло- бальных сетей в США. После некоторого затишья проблема сетевых вирусов вновь обострилась в начале 1997 г. с появлением вирусов “Macro.Word-ShareFun” и “Win.Homer”. Первый из них исполь- зует возможности электронной почты Microsoft Mail — он со- здает новое письмо, содержащее зараженный файл-документ (“ShareFun” является макровирусом), затем выбирает из спис- ка адресов службы MS-Mail (из вашей компьютерной запис- ной книги) три случайных адреса и рассылает по ним зара- женное письмо. Поскольку многие пользователи устанавли- вают параметры MS-Mail таким образом, что при получении письма автоматически запускается MS Word, то вирус “ав- томатически” внедряется в компьютер адресата зараженно- го письма. Этот вирус иллюстрирует первый тип современных сете- вых вирусов, которые объединяют возможности встроенного в Word/Excel языка Basic, протоколы и особенности элект- ронной почты, а также функции автозапуска, необходимые для распространения вируса. 143
Второй вирус (“Homer”) использует для своего распрост- ранения протокол FTP (File Transfer Protocol) и передает свою копию на удаленный ftp-cepeep в каталог incoming. По- скольку сетевой протокол FTP исключает возможность запуска файла на удаленном сервере, этот вирус можно охарактери- зовать как “полусетевой”, однако это реальный пример воз- можностей вирусов по использованию современных сетевых протоколов и поражению глобальных сетей. Какие же основные правила защиты от компьютерных вирусов? Приведем некоторые из них [19]. Правило первое. Крайне осторожно относитесь к программам и докумен- там, изготовленным с помощью пакета Microsoft Office (с по- мощью приложений Word/Excel/Power Point/Access), кото- рые вы получаете из глобальных сетей. Перед тем, как запу- стить файл на выполнение или открыть документ/таблицу/ презентацию/базу данных, обязательно проверьте их на на- личие вирусов. Используйте специализированные антивиру- сы — для проверки всех файлов, приходящих по электрон- ной почте (из локальных и глобальных сетей в целом). К со- жалению, на сегодняшний день пока нельзя однозначно на- звать хотя бы один антивирус, который достаточно надежно ловил бы вирусы в проходящих из Интернета файлах, но не исключено, что такие антивирусы появятся в ближайшем будущем. Правило второе, касающееся защиты локальных сетей. Для уменьшения риска заразить файл на сервере адми- нистраторам сетей следует активно использовать стандарт- ные возможности защиты сетей: ограничение прав пользо- вателей; установку атрибутов “только на чтение” или даже “только на запуск” для всех выполняемых файлов (к сожале- нию, это не всегда оказывается возможным); скрытие (зак- рытие) важных разделов диска и директорий и т. д. Используйте специализированные антивирусы, проверя- ющие все файлы, к которым идет обращение. Если это по какой-либо причине невозможно, регулярно проверяйте сер- 144
вер обычными антивирусными программами. Значительно уменьшается риск заражения компьютерной сети при исполь- зовании бездисковых рабочих станций. Желательно также перед тем, как запустить новое программное обеспечение, проверить его на тестовом компьютере, не подключенном к общей сети. Правило третье. Лучше приобретать дистрибутивные копии программ- ного обеспечения у официальных продавцов, чем бесплатно или почти бесплатно копировать их из других источников или покупать нелицензионные “пиратские” копии. При этом зна- чительно снижается вероятность заражения. Как следствие из этого правила вытекает необходимость хранения дистрибутивных копий программного обеспечения (в том числе копий операционной системы), причем копии желательно хранить на защищенных от записи дискетах (дисках). Пользуйтесь только хорошо зарекомендовавшими себя источниками программ и прочих файлов, хотя это не всегда спасает (например, на WWW-сервере Microsoft довольно дол- гое время находился документ, зараженный макровирусом “Wazzu”). По-видимому, единственными надежными с точки зрения защиты от вирусов являются BBS/ftp/WWW антиви- русных фирм-разработчиков. Правило четвертое. Старайтесь не запускать непроверенные файлы, в том числе полученные из компьютерной сети. Желательно ис- пользовать только программы, полученные из надежных ис- точников. Перед запуском новых программ обязательно про- верьте их одним или несколькими антивирусами. Если даже ни один антивирус не среагировал на файл, который был снят с BBS или электронной конференции — не торопитесь его запускать. Подождите неделю, если этот файл вдруг окажет- ся заражен новым неизвестным вирусом, то, скорее всего, кто-либо потерпит неудобства раньше вас и своевременно сообщит об этом. 145
Желательно также, чтобы при работе с новым программ- ным обеспечением в памяти резидентно находился какой-либо антивирусный монитор. Если запускаемая программа зара- жена вирусом, то такой монитор поможет обнаружить вирус и остановить его распространение. Все рекомендации приводят к необходимости ограниче- ния круга лиц, допущенных к работе на конкретном компью- тере. Как правило, наиболее часто подвержены заражению “многопользовательские” персональные компьютеры. Правило пятое. Пользуйтесь утилитами проверки целостности инфор- мации. Такие утилиты сохраняют в специальных базах дан- ных информацию о системных областях дисков (или целиком системные области) и информацию о файлах (контрольные суммы, размеры, атрибуты, даты последней модификации файлов и т. д.). Периодически сравнивайте информацию, хра- нящуюся в подобной базе данных, с реальным содержимым винчестера, так как практически любое несоответствие Мо- жет служить сигналом о появлении вируса или “троянской” программы. Правило шестое. Периодически сохраняйте на внешнем носителе файлы, с которыми ведется работа. Такие резервные копии носят название Ъаскир-копий. Затраты на копирование файлов, со- держащих исходные тексты программ, базы данных, доку- ментацию, значительно меньше затрат на восстановление этих файлов при проявлении вирусов агрессивных свойств или при сбое компьютера. При наличии стримера или какого-либо другого внешне- го носителя большого объема имеет смысл делать backup- копии всего содержимого винчестера. Но поскольку времени на создание подобной копии требуется значительно больше, чем на сохранение только рабочих файлов, такие копии де- лаются гораздо реже. В качестве вывода отметим, что проблему защиты от вирусов целесообразно рассматривать в общем контексте 146
проблемы защиты информации от несанкционированного до- ступа. Основной принцип, который должен быть положен в основу разработки технологии от вирусов, состоит в создании многоуровневой распределенной системы защиты, включа- ющей регламентацию доступа к ЭВМ, проводимых операций на ЭВМ, применение специальных программных и аппарат- ных средств и т. п. В заключение подчеркнем три важнейших обстоятель- ства: во-первых, защита информации от несанкционирован- ных действий эффективна только тогда, когда комплексно (системно) применяются все известные способы и средства; во-вторых, защита должна осуществляться непрерывно; и в-третьих, на защиту информации не нужно жалеть зат- рат денежных, материальных, временных и других ресур- сов, ибо они многократно окупятся сохранением целостности информации. 1.6. CASE-технологии проектирования автоматизированных информационных систем За последнее десятилетие сформировалось новое направ- ление в программотехнике — CASE (Computer-Aided Software/System Engineering) — в дословном переводе — разработка программного обеспечения информационных сис- тем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, тер- мин CASE используется в весьма широком смысле. Первона- чальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обес- печения, в настоящее время приобрело новый смысл, охва- тывающий процесс разработки сложных автоматизированных информационных систем в целом. Теперь под термином CASE- средства понимаются программные средства, поддерживаю- щие процессы создания и сопровождения ИС, включая ана- 147
лиз и формулировку требований, проектирование приклад- ного ПО (приложений) и баз данных, генерацию кода, тести- рование, документирование, обеспечение качества, конфи- гурационное управление и управление проектом, а также другие процессы [23, 24]. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду раз- работки АИС. CASE-средства позволяют не только создавать “правиль- ные” продукты, но и обеспечить “правильный” процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих эта- пов разработки, а также скрыть от разработчиков все дета- ли среды разработки и функционирования ПО. При использо- вании CASE-технологий изменяются все этапы жизненного цикла программного обеспечения (подробнее об этом будет сказано ниже) информационной системы, при этом наиболь- шие изменения касаются этапов анализа и проектирования. Большинство существующих CASE-средств основано на ме- тодологиях структурного (в основном) или объектно-ориенти- рованного анализа и проектирования, использующих специ- фикации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики по- ведения системы и архитектуры программных средств. Такие методологии обеспечивают строгое и наглядное описание про- ектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую струк- туру со все большим числом уровней. CASE-технологии ус- пешно применяются для построения практически всех типов систем ПО, однако устойчивое положение они занимают в следующих областях: ♦ обеспечение разработки делового и коммерческого ПО, широкое применение CASE-технологий обусловлены массовостью этой прикладной области, в которой CASE применяется не только для разработки ПО, но и для создания моделей систем, помогающих решать задачи стратегического планирования, управления финанса- 148
ми, определения политики фирм, обучения персонала и др. (это направление получило свое собственное на- звание — бизнес-анализ); ♦ разработка системного и управляющего ПО. Активное применение CASE-технологий связано с большой слож- ностью данной проблематики и со стремлением повы- сить эффективность работ. CASE — не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальными или технологически- ми. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурных методологий проектирования 60—70-х гг. XX в. (сложности понимания, большой трудоемкости и стоимости использова- ния, трудности внесения изменений в проектные специфика- ции и т. д.) за счет их автоматизации и интеграции поддержи- вающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными методологиями, они только раз- вивают структурные методологии и делают более эффектив- ным их применение за счет автоматизации. Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE-средства обла- дают следующими основными достоинствами: ♦ улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего контроля про- екта); ♦ позволяют за короткое время создавать прототип буду- щей системы, что позволяет на ранних этапах оценить ожидаемый результат; ♦ ускоряют процесс проектирования и разработки; ♦ освобождают разработчика от рутинной работы, позво- ляя ему целиком сосредоточиться на творческой части разработки; ♦ поддерживают развитие и сопровождение разработки; ♦ поддерживают технологии повторного использования компонента разработки. 149
Появлению CASE-технологии и CASE-средств предше- ствовали исследования в области методологии программиро- вания. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, мето- дов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и не- формальных языков описаний системных требований и спе- цификаций и т. д. В 70—80-х гг. стала на практике применять- ся структурная методология, предоставляющая в распоря- жение разработчиков строгие формализованные методы опи- сания АИС и принимаемых-технических решений. Она осно- вана на наглядной графической технике: для описания раз- личного рода моделей АИС используются схемы и диаграм- мы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке контактных АИС встречалось достаточно редко, поскольку при неавто- матизированной (ручной) разработке это практически невоз- можно. Это и способствовало появлению программно-техни- ческих средств особого класса — CASE-средств, реализую- щих CASE-технологию создания и сопровождения АИС. Необходимо понимать, что успешное применение CASE- средств невозможно без понимания базовой технологии, на которой эти средства основаны. Сами по себе программные CASE-средства являются средствами автоматизации процес- сов проектирования и сопровождения информационных сис- тем. Без понимания методологии проектирования ИС невоз- можно применение CASE-средств. 1.6.1. Жизненный цикл программного обеспечения информационной системы Одним из базовых понятий методологии проектирования АИС является понятие жизненного цикла ее программного 150
обеспечения (ЖЦ ПО). ЖЦ ПО — это непрерывный процесс, который начинается с момента принятия решения о необхо- димости его создания и заканчивается в момент его полного изъятия из эксплуатации [6]. Структура ЖЦ ПО базируется на трех группах процес- сов: ♦ основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); ♦ вспомогательные процессы, обеспечивающие выпол- нение основных процессов (документирование, управ- ление конфигурацией, обеспечение качества, верифи- кация, аттестация, оценка, аудит, решение проблем); ♦ организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оцен- ка и улучшение самого ЖЦ, обучение). Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требования- ми, включая оформление проектной и эксплуатационной до- кументации, подготовку материалов, необходимых для про- верки работоспособности и соответствующего качества про- граммных продуктов, материалов, необходимых для органи- зации обучения персонала и т. д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование). Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигуриро- вание базы данных и рабочих мест пользователей, обеспече- ние эксплуатационной документацией, проведение обучения персонала и т. д. и непосредственно эксплуатацию, в том чис- ле локализацию проблем и устранение причин их возникно- вения, модификацию ПО в рамках установленного регламен- та, подготовку предложений по совершенствованию, разви- тию и модернизации системы. Управление проектом связано с вопросами планирова- ния и организации работ, создания коллективов разработчи- ков и контроля за сроками и качеством выполняемых работ. 151
Техническое и организационное обеспечение проекта вклю- чает выбор методов и инструментальных средств для реали- зации проекта, определение методов описания промежуточ- ных состояний разработки, разработку методов и средств ис- пытаний ПО, обучение персонала и т. п. Обеспечение каче- ства проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация — это процесс определе- ния того, отвечает ли текущее состояние разработки, дос- тигнутое на данном этапе, требованиям этого этапа. Провер- ка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с те- стированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оцен- кой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают воп- росы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом. Управление конфигурацией является одним из вспомо- гательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, со- стоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигу- рацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО от- ражены в проекте стандарта ISO 12207-2. Каждый процесс характеризуется определенными зада- чами и методами их решения, исходными данными, получен- ными на предыдущем этапе, результатами. Результатами ана- лиза, в частности, являются функциональные модели, ин- формационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного 152
этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. Существующие модели ЖЦ определяют порядок испол- нения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распрос- транение получили три следующие модели ЖЦ: ♦ каскадная модель (1970—1980 гг.) — предлагает пере- ход на следующий этап после полного окончания работ по предыдущему этапу; ♦ поэтапная модель с промежуточным контролем (1980—1985 гг.) — итерационная модель разработки ПО с циклами обратной связи между этапами. Преимуще- ство такой модели заключается в том, что межэтап- ные корректировки обеспечивают меньшую трудоем- кость по сравнению с каскадной моделью, однако вре- мя жизни каждого из этапов растягивается на весь пе- риод разработки; ♦ спиральная модель (1986—1990 гг.) — делает упор на начальные этапы ЖЦ: анализ требований, проектиро- вание спецификаций, предварительное и детальное про- ектирование. На этих этапах проверяется и обосновыва- ется реализуемость технических решений путем созда- ния прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии про- граммного изделия, на нем уточняются цели и характе- ристики проекта, определяется его качество, планиру- ются работы следующего витка спирали. Таким обра- зом, углубляются и последовательно конкретизируют- ся детали проекта и в результате выбирается обосно- ванный вариант, который доводится до реализации. Специалистами отмечаются следующие преимущества спиральной модели: ♦ накопление и повторное использование программных средств, моделей и прототипов; ♦ ориентация на развитие и модификацию ПО в процес- се его проектирования; ♦ анализ риска и издержек в процессе проектирования. 153
Главная особенность индустрии создания ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проек- тирования, порождают на последующих этапах трудные, ча- сто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. 1.6.2. RAD-технологии прототипного создания приложений Одним из возможных подходов к разработке ПО в рам- ках спиральной модели ЖЦ является получившая в после- днее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента: ♦ небольшую команду программистов (от 2 до 10 чело- век); ♦ короткий, но тщательно проработанный производствен- ный график (от 2 до 6 мес.); ♦ повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, по- лученные через взаимодействия с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE- средств. Члены коллектива должны также иметь трансфор- мировать в рабочие прототипы предложения конечных пользо- вателей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: ♦ фазы анализа и планирования требований', ♦ фазы проектирования; 154
♦ фазы построения; ♦ фазы внедрения. На фазе анализа и планирования требований пользова- тели системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, тре- бующие проработки в первую очередь, описывают информа- ционные потребности. Определение требований выполняется в основном силами пользователей под руководством специа- листов-разработчиков. Ограничивается масштаб проекта, оп- ределяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т. п. Результатом данной фазы должны быть список и приоритетность функций буду- щей АИС, предварительные функциональные и информаци- онные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руко- водством специалистов-разработчиков. CASE-средства исполь- зуются для быстрого получения работающих прототипов при- ложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рас- сматриваются процессы системы. Анализируется и при необ- ходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный про- тотип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оцени- вается количество функциональных элементов разрабатыва- емой системы и принимается решение о разделении АИС на подсистемы, поддающиеся реализации одной командой раз- работчиков за приемлемое для RAD-проектов время — при- 155
мерно 60—90 дней. С использованием CASE-средств проект распределяется между различными командами (делится фун- кциональная модель). Результатом данной фазы должны быть: ♦ общая информационная модель системы; ♦ функциональные модели системы в целом и подсис- тем, реализуемых отдельными командами разработчи- ков; ♦ точно определенные с помощью CASE-средства интер- фейсы между автономно разрабатываемыми подсисте- мами; ♦ построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с при- менением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче ин- формации о проекте с этапа на этап может произойти фак- тически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором ис- пользовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким обра- зом, на следующую фазу передается более полная и полез- ная информация. На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработ- чики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генера- торов, получающих информацию непосредственно из репо- зитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если 156
в процессе разработки система перестает удовлетворять оп- ределенным ранее требованиям. Тестирование системы осу- ществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды раз- работчиков производится постепенная интеграция данной ча- сти системы с остальными, формируется полный программ- ный код, выполняется тестирование совместной работы дан- ной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы: ♦ определяется необходимость распределения данных; ♦ производится анализ использования данных; ♦ производится физическое проектирование базы дан- ных; ♦ определяются требования к аппаратным ресурсам; ♦ определяются способы увеличения производительности; ♦ завершается разработка документации проекта. Результатом фазы является готовая система, удовлетво- ряющая всем согласованным требованиям. На фазе внедрения производится обучение пользовате- лей, организационные изменения, и параллельно с внедре- нием новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза постро- ения достаточно непродолжительна, планирование и подго- товка к внедрению должны начинаться заранее, как прави- ло, на этапе проектирования системы. Приведенная схема разработки АИС не является абсо- лютной. Возможны различные варианты, зависящие, напри- мер, от начальных условий, в которых ведется разработка: разрабатывается ли совершенно новая система; было ли про- ведено информационное обследование организации и суще- ствует ли модель ее деятельности; существует ли в органи- зации некоторая АИС, которая может быть использована в качестве начального прототипа или должна быть интегриро- вана с разрабатываемой и т. п. 157
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс ти- повых компонент, централизованно сопровождаемых, адап- тируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с суще- ствующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разра- ботки. Для таких проектов необходимы высокий уровень пла- нирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфей- сам, что снижает скорость разработки. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требу- ющих написания большого объема (сотни тысяч строк) уни- кального кода. Не подходят для разработки по методологии RAD при- ложения, в которых отсутствует ярко выраженная интер- фейсная часть, наглядно определяющая логику работы сис- темы (например, приложения реального временил), и прило- жения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Основные принципы методоло- гии RAD: ♦ разработка приложений итерациями; ♦ необязательность полного завершения работ на каж- дом из этапов жизненного цикла; ♦ обязательное вовлечение пользователей в процесс раз- работки АИС; 158
♦ необходимое применение CASE-средств, обеспечива- ющих целостность проекта; ♦ применение средств управления конфигурацией, об- легчающих внесение изменений в проект и сопровож- дение готовой системы; ♦ необходимое использование генераторов кода; ♦ использование прототипирования, позволяющего пол- нее выяснить и удовлетворить потребности конечного пользователя; ♦ тестирование и развитие проекта, осуществляемые одновременно с разработкой; ♦ ведение разработки немногочисленной хорошо управ- ляемой командой профессионалов; ♦ грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. 1.6.3. Структурный метод разработки программного обеспечения Сущность структурного подхода к разработке АИС зак- лючается в ее декомпозиции (разбиении) на автоматизируе- мые функции: система разбивается на функциональные под- системы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом ав- томатизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы “снизу вверх”, от отдельных задач ко всей системе, целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть исполь- зуется при выработке рекомендаций по организации работ [6]. В качестве двух базовых принципов используются следую- щие: принцип “разделяй и властвуй” и принцип иерархичес- 159
кого упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество мень- ших независимых задач, более легких для понимания и ре- шения. Второй принцип декларирует, что устройство этих частей также существенно для понимания. Уровень уяснения проблемы резко повышается при представлении ее частей в виде древовидных иерархических структур, т. е. система мо- жет быть понята и построена по уровням, каждый из кото- рых добавляет новые детали. Выделение двух базовых принципов инженерии программ- ного обеспечения не означает, что остальные принципы яв- ляются второстепенными, игнорирование любого из них мо- жет привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких прин- ципов. 1. Принцип абстрагирования — заключается в выделе- нии существенных с некоторых позиций аспектов системы и отвлечении от несущественных с целью представления про- блемы в простом общем виде. 2. Принцип формализации — заключается в необходимо- сти строгого методического подхода к решению проблемы. 3. Принцип “упрятывания” — заключается в упрятыва- нии несущественной на конкретном этапе информации: каж- дая часть “знает” только необходимую ей информацию. 4. Принцип концептуальной общности — заключается в следовании единой философии на всех этапах ЖЦ (структур- ный анализ — структурное проектирование — структурное программирование — структурное тестирование). 5. Принцип полноты — заключается в контроле присут- ствия лишних элементов. 6. Принцип непротиворечивости — заключается в обо- снованности и согласованности элементов. 7. Принцип логической независимости — заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования. 160
8. Принцип независимости данных — заключается в том, что модели данных должны быть проанализированы и спро- ектированы независимо от процессов их логической обработ- ки, а также от их физической структуры и распределения. 9. Принцип структурирования данных — заключается в том, что данные должны быть структурированы и иерар- хически организованы. 10. Принцип доступа конечного пользователя — заклю- чается в том, что пользователь должен иметь средства дос- тупа к базе данных, которые он может использовать непос- редственно (без программирования). Соблюдение указанных принципов необходимо при орга- низации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых при этом методологий. Руководствуясь всеми принципами в комплексе, можно на более ранних стадиях разработки понять, что будет пред- ставлять собой создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на после- дующих этапах ЖЦ и понизит стоимость разработки. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаг- рамм), наиболее распространенными среди которых являют- ся следующие: ♦ SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграм- мы; ♦ DFD (Data Flow Diagrams) — диаграммы потоков дан- ных; ♦ ERD (Entity-Relationship Diagrams) — диаграммы”сущ- ность—связь”; ♦ STD (State Trasition Diagrams) — диаграммы переходов состояний. На стадии проектирования ИС модели расширяются, уточ- няются и дополняются диаграммами, отражающими струк- 161
туру программного обеспечения: архитектуру ПО, структур- ные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное опи- сание АИС независимо от того, является ли она существую- щей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описа- ния системы. Методология SADT Методология SADT разработана Дугласом Россом, на ее основе разработана, в частности, известная методология IDEFO (Icam Definition), которая является основной частью программы Icam (Интеграция компьютерных и промышлен- ных технологий), проводимой по инициативе США. Методо- логия SADT представляет собой совокупность методов, пра- вил и процедур, предназначенных для построения функцио- нальной модели объекта какой-либо предметной области. Фун- кциональная модель SADT отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Основные элементы этой методо- логии основываются на следующих концепциях: ♦ графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих “ограничения”, которые, в свою очередь, определяют, когда и каким образом функции выполня- ются и управляются; ♦ строгость и точность. Выполнение правил SADT требу- ет достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия ана- литика. Правила SADT включают: ♦ ограничение количества блоков на каждом уровне де- композиции (правило 3—6 блоков); 162
♦ связность диаграмм (номера блоков); ♦ уникальность меток и наименований (отсутствие по- вторяющихся имен); ♦ синтаксические правила для графики (блоков и дуг); ♦ разделение входов и управлений (правило определе- ния роли данных); ♦ отделение организации от функции, т. е. исключение влияния организационной структуры на функциональ- ную модель. Методология SADT может использоваться для моделиро- вания широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлет- воряет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для ука- зания механизмов, посредством которых они осуществляются. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — глав- ные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информа- ция входит в блок сверху, в то время как информация, кото- рая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуще- ствляет операцию, представляется дугой, входящей в блок снизу (рис. 1.6.1). Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты — одного блока и дуг, изображающих интерфейсы с функциями вне систе- мы. Поскольку единственный блок представляет всю систему 163
как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг — они также представ- ляют полный набор внешних интерфейсов системы в целом. Управление Входы -----------► Функция ----------► Выходы Механизм Рис. 1.6.1. Функциональный блок и интерфейсные дуги Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с по- мощью нескольких блоков, соединенных интерфейсными ду- гами. Эти блоки представляют основные подфункции исход- ной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, гра- ницы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элемен- ты, т. е., как уже отмечалось, так называемый родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Модель SADT представляет собой серию диаграмм с со- проводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы (рис. 1.6.2 и 1.6.3). 164
Дуги, входящие в блок и выходящие из него на диаг- рамме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выхо- дящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обо- ими концами, у других же один конец остается неприсоеди- ненным. Неприсоединенные дуги соответствуют входам, уп- равлениям и выходам родительского блока. Источник или по- лучатель этих пограничных дуг может быть обнаружен толь- ко на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской ди- аграмме, чтобы она была полной и непротиворечивой. На SADT-диаграммах не указаны явно ни последователь- ность, ни время. Обратные связи, итерации, продолжающие- ся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выс- тупать в виде комментариев, замечаний, исправлений и т. д. Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, ком- пьютером или любым другим устройством, которое помогает выполнять данную функцию. Каждый блок на диаграмме имеет свой номер. Блок лю- бой диаграммы может быть далее описан диаграммой нижне- го уровня, которая, в свою очередь, может быть далее дета- лизирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично А2 детализирует блок 2 на диаг- рамме АО, которая является самой верхней диаграммой мо- дели. 165
Рис. 1.6.2. Структура SADT-модели (декомпозиция диаграмм) 166
Детальная диаграмма Эта управляющая дуга переносится с родительской диаграммы с родительской диаграммы Эта дуга продолжается А12 на родительской диаграмме Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания; Тип связи Относительная значимость Случайная 0 Логическая 1 Временная 2 Процедурная 3 Коммуникационная 4 Последовательная 5 Функциональная 6 167
Ниже каждый тип связи кратко определен и проиллюс- трирован с помощью типичного примера из SADT (табл. 1.6.1). Таблица 1.6.1 Значи- мость Тип связности Для функций Для данных 0 Случайная Случайная Случайная 1 Логическая Функции одного и того же множества или типа (напри- мер, “редактировать все входы”) Данные одного и того же множестваили типа 2 Временная Функции одного и того же периода времени (например, “операции инициализации) Данные, используемые в каком-либо временном интервале 3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, “первый проход компилятора”) Данные, используемые во время одной и той же фазы или итерации 4 Коммуника- ционная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность 5 Последовательная Функции, выполняющие последовательные преобра- зования одних и тех же данных Данные, преобразуемые последовательными функциями 6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией (0) — Тип случайной связности: наименее желательный. Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаг- рамме имеют малую связь друг с другом. (1) — Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вме- сте вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отноше- ний между ними не обнаруживается. (2) — Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют 168
функции, связанные во времени, когда данные используют- ся одновременно или функции включаются параллельно, а не последовательно. (3) — Тип процедурной связности. Процедурно-связан- ные элементы появляются сгруппированными вместе вслед- ствие того, что они выполняются в течение одной и той же части цикла или процесса. (4) — Тип коммуникационной связности. Диаграммы де- монстрируют коммуникационные связи, когда блоки группи- руются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные. (5) — Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку модели- руются причинно-следственные зависимости. (6) — Тип функциональной связности. Диаграмма отра- жает полную функциональную связность при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более сла- бому типу связности. Одним из способов определения функ- ционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги. Моделирование потоков данных (процессов) Основным средством моделирования функциональных требований АИС являются диаграммы потоков данных (DFD;— Data Flow Diagrams). С их помощью эти требования разбива- ются на функциональные компоненты (процессы) и представ- ляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также вы- явить отношения между этими процессами. 169
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна Сарсона (Gane- Sarson) — рис. 1.6.4. Рис. 1.6.4. Представление нотаций Йодана и Гейна-Сарсона В соответствии с методологией модель системы опреде- ляется как иерархия диаграмм потоков данных (ДПД, или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграм- мы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при по- мощи диаграмм нижнего уровня. Такая декомпозиция про- должается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпози- ции, на котором процессы становятся элементарными и дета- лизировать их далее невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие ин- формацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, кото- рые переносят информацию к другим процессам или подсис- 170
темам, накопителям данных или внешним сущностям — по- требителям информации. Таким образом, основными компо- нентами диаграмм потоков данных являются: ♦ внешние сущности; ♦ системы/подсистемы; ♦ процессы; ♦ накопители данных; ♦ потоки данных. Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой ис- точник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение неко- торого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ ана- лизируемой АИС. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован раз- личными способами: это может быть подразделение органи- зации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное ло- гическое устройство и т. д. В различных нотациях процесс может изображаться на диаграммах по-разному. Номер про- цесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным не- двусмысленным глаголом в неопределенной форме (вычис- лить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном паде- же, например: ♦ “Ввести сведения о клиентах”; ♦ “Выдать информацию о текущих расходах”; ♦ “Проверить кредитоспособность клиента”. Использование таких глаголов, как “обработать”,’’модер- низировать” или “отредактировать” означает, как правило, недостаточно глубокое понимание данного процесса и требу- ет дальнейшего анализа. 171
В последнее время принято использовать еще и поле физической реализации, информация в котором показывает, какое подразделение организации, программа или аппарат- ное устройство выполняет данный процесс. Хранилище (накопитель данных) представляет собой аб- страктное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через неко- торое время извлечь, причем способы помещения и извлече- ния могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оператив- ной памяти, файла на магнитном носителе и т. д. Накопитель данных идентифицируется буквой “D” и произвольным чис- лом. Имя накопителя выбирается из соображения наиболь- шей информативности для проектировщика. Накопитель данных в общем случае является прообра- зом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по по- чте письмами, магнитными лентами или дискетами, перено- симыми с одного компьютера на другой и т. д. Поток данных на диаграмме изображается линией, окан- чивающейся стрелкой, которая показывает направление. Каж- дый поток данных имеет имя, отражающее его содержание. Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проецирова- нии относительно простых АИС строится единственная кон- текстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соеди- ненный с приемниками и источниками информации, посред- ством которых с системой взаимодействуют пользователи и другие внешние системы. Для сложных АИС строится иерар- хия контекстных диаграмм. При этом контекстная диаграмма 172
верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекст- ные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодей- ствие основных функциональных подсистем проектируемой АИС как между собой, так и с внешними входными и выход- ными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует АИС. Разработка контекстных диаграмм решает проблему стро- гого определения функциональной структуры АИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке кото- рых участвуют разные организации и коллективы разработ- чиков. После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый про- цесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации долж- ны выполняться следующие правила: ♦ правило балансировки — означает, что при детализа- ции подсистемы или процесса детализирующая диаг- рамма в качестве внешних источников/приемников данных может иметь только те компоненты (подсисте- мы, процессы, внешние сущности, накопители дан- ных), с которыми имеет информационную связь дета- лизируемая подсистема или процесс на родительской диаграмме; ♦ правило нумерации — означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т. д. 173
Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проек- та, смог выполнить их или разработать соответствующую программу. Миниспецификация является конечной вершиной иерар- хии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком, исходя из следующих критериев: ♦ наличия у процесса относительно небольшого количе- ства входных и выходных потоков данных (2—3 пото- ка); ♦ возможности описания преобразования данных процес- сом в виде последовательного алгоритма; ♦ выполнения процессом единственной логической функ- ции преобразования входной информации в выходную; ♦ возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20— 30 строк). При построении иерархии DFD переходить к детализа- ции процессов следует только после определения содержа- ния всех потоков и накопителей данных, которое описывает- ся при помощи структур данных. Структуры данных конст- руируются из элементов данных и могут содержать альтер- нативы, условные вхождения и итерации. Условное вхожде- ние означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означа- ет вхождение любого числа элементов в указанном диапазо- не. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значений, точность представления и форма физи- ческого кодирования. Для дискретных данных может указы- ваться таблица допустимых значений. 174
После построения законченной модели системы ее необ- ходимо верифицировать (проверить на полноту и согласован- ность). В полной модели все ее объекты (подсистемы, процес- сы, потоки данных) должны быть подробно описаны и детали- зированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработ- ки. В согласованной модели для всех потоков данных и накопи- телей данных должно выполняться правило сохранения ин- формации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. Моделирование данных Цель моделирования данных состоит в обеспечении раз- работчика АИС концептуальной схемой базы данных в фор- ме одной модели или нескольких локальных моделей, кото- рые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы “сущность—связь” (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для про- ектирования реляционных баз данных (см. подразд. 2.2). Нотация ERD была впервые введена П. Ченом (Р. Chen) и получила дальнейшее развитие в работах Баркера. Методология IDEF1 Метод IDEF1, разработанный Т. Рэмеем (Т. Ramey), так- же основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нор- мальной форме. В настоящее время на основе совершенство- вания методологии IDEF1 создана ее новая версия — методо- логия IDEF1X. IDEF1X разработана с учетом таких требова- ний, как простота изучения и возможность автоматизации. IDEFIX-диаграммы используются рядом распространенных CASE-средств (в частности, ERWin, Design/IDEF). 175
1.6.4. Методологии проектирования программного обеспечения Современные методологии и реализующие их техноло- гии поставляются в электронном виде вместе с CASE-сред- ствами и включают библиотеки процессов, шаблонов, мето- дов, моделей и других компонент, предназначенных для по- строения ПО того класса систем, на который ориентирована методология. Электронные методологии включают также сред- ства, которые должны обеспечивать их адаптацию для конк- ретных пользователей и развитие методологии по результа- там выполнения конкретных проектов. Процесс адаптации заключается в удалении ненужных процессов, действий ЖЦ и других компонентов методологии, в изменении неподходящих или в добавлении собственных процессов и действий, а также методов, моделей, стандар- тов и руководств. Настройка методологии может осуществ- ляться также по следующим аспектам: этапы и операции ЖЦ, участники проекта, используемые модели ЖЦ, поддержива- емые концепции и др. Электронные методологии и технологии (и поддержива- ющие их CASE-средства) составляют ядро комплекса согла- сованных инструментальных средств среды разработки АИС. Методология DATARUN Одной из наиболее распространенных в мире электрон- ных методологий является методология DATARUN. В соот- ветствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию, помимо ее результатов, должен завершать план работ на следующую стадию. Стадия формирования требований и планирования вклю- чает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требова- ния и экономическое обоснование для разработки АИС, 176
функциональные модели (модели бизнес-процессов органи- зации) и исходная концептуальная модель данных, которые дают основу для оценки технической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исходные модели процессов и дан- ных организации), требования к системе, включая требова- ния по сопряжению с существующими АИС, исходный биз- нес-план. Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концеп- туальной модели данных, после чего проектируется архи- тектура системы. Архитектура включает в себя разделение концептуальной модели на обозримые подмодели. Оценивает- ся возможность использования существующих АИС и выби- рается соответствующий метод их преобразования. После по- строения проекта уточняется исходный бизнес-план. Выход- ными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточненный бизнес-план. На стадии спецификации приложений продолжается про- цесс создания и детализации проекта. Концептуальная модель данных преобразуется в реляционную модель данных. Опре- деляется структура приложения, необходимые интерфейсы приложения в виде экранов, отчетов и пакетных процессов вместе с логикой их вызова. Модель данных уточняется биз- нес-правилами и методами для каждой таблицы. В конце этой стадии принимается окончательное решение о способе реа- лизации приложений. По результатам стадии должен быть построен проект АИС, включающий модели архитектуры АИС, данных, функций, интерфейсов (с внешними система- ми и с пользователями), требований к разрабатываемым при- ложениям (модели данных, интерфейсов и функций), требо- ваний к доработкам существующих АИС, требований к ин- теграции приложений, а также сформирован окончательный план создания АИС. 177
На стадии разработки, интеграции и тестирования должна быть создана тестовая база данных, частные и комп- лексные тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с про- ектом. Отлаживаются интерфейсы с существующими систе- мами. Описывается конфигурация текущей версии ПО. На ос- нове результатов тестирования проводится оптимизация базы данных и приложений. Приложения интегрируются в систе- му, проводится тестирование приложений в составе системы и испытания системы. Основными результатами стадии явля- ются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия систе- мы и эксплуатационная документация на систему. Стадия внедрения включает в себя действия по установке и внедрению баз данных и приложений. Основными результа- тами стадии должны быть готовая к эксплуатации и перене- сенная на программно-аппаратную платформу заказчика вер- сия системы, документация сопровождения и акт приемочных испытаний по результатам опытной эксплуатации. Стадии сопровождения и развития включают процессы и операции, связанные с регистрацией, диагностикой и лока- лизацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространени- ем новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием сис- темы. Стадия развития фактически является повторной ите- рацией стадии разработки. Методология DAT ARUN опирается на две модели или на два представления: ♦ модель организации; ♦ модель АИС. Методология DAT ARUN базируется на системном подхо- де к описанию деятельности организации. Построение моде- лей начинается с описания процессов, из которых затем из- влекаются первичные данные (стабильное подмножество 178
данных, которые организация должна использовать для сво- ей деятельности). Первичные данные описывают продукты или услуги организации, выполняемые операции (транзак- ции) и потребляемые ресурсы. К первичным относятся дан- ные, которые описывают внешние и внутренние сущности, такие как служащие, клиенты или агентства, а также дан- ные, полученные в результате принятия решений, как на- пример, графики работ, цены на продукты. Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организова- ны в модель данных, становятся основой для проектирования архитектуры АИС. Архитектура АИС будет более стабиль- ной, если она основана на первичных данных, тесно связан- ных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной мо- дели. Любая АИС представляет собой набор модулей, испол- няемых процессорами и взаимодействующих с базами дан- ных. Базы данных и процессоры могут располагаться центра- лизованно или быть распределенными. События в системе могут инициироваться внешними сущностями. Все транзак- ции осуществляются через объекты или модули интерфейса, которые взаимодействуют с одной или более базами данных. Подход DATARUN преследует две цели: ♦ определить стабильную структуру, на основе кото- рой будет строиться АИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы органи- зации; ♦ спроектировать АИС на основании модели данных. Объекты, формируемые на основании модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса, опре- деленные в архитектуре компьютерной системы, обычно размещаются на клиентской части. Модель данных, являю- щаяся основой для спецификации совместно используемых 179
объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость АИС. В процессе разработки АИС создается ряд моделей: BPM (Business Process Model) — модель процессов (биз- нес-процессов); PDS (Primary Data Structure) — структура первичных данных; CDM (Conceptual Data Model) — концептуальная модель данных; SPM (System Process Model) — модель процессов систе- мы; ISA (Information System Architecture) — архитектура информационной системы; ADM (Application Data Model) — модель данных прило- жения; IPM (Interface Presentation Model) — модель представле- ния интерфейса; ISM (Interface Specification Model) — модель специфика- ции интерфейса. CASE-средство Silverrun обеспечивает автоматизацию проведения проектных работ в соответствии с методологией DAT ARUN и обеспечивает создание этих моделей. Предостав- ляемая этими средствами среда проектирования дает возмож- ность руководителю проекта контролировать проведение ра- бот, отслеживать выполнение работ, вовремя замечать откло- нения от графика. Каждый участник проекта, подключившись к этой среде, может выяснить содержание и сроки выполне- ния порученной ему работы, детально изучить технику ее выполнения в гипертексте по технологиям и вызвать инстру- мент (модуль Silverrun) для реального выполнения работы. Информационная система создается последовательным построением ряда моделей, начиная с модели бизнес-процес- сов и заканчивая моделью программы, автоматизирующей эти процессы. Создаваемая АИС должна основываться на функциях, выполняемых организацией. Поэтому первая создаваемая мо- 180
дель — это модель бизнес-процессов, построение которой осуществляется в модуле Silverrun BPM. Для этой модели используется специальная нотация ВРМ. В процессе анализа и спецификации бизнес-функций выявляются основные ин- формационные объекты, которые документируются как структуры данных, связанные с потоками и хранилищами модели. Источниками для создания структур являются ис- пользуемые в организации документы, должностные инст- рукции, описания производственных операций. Эти данные вводятся в том виде, как они существуют в деятельности орга- низации. Нормализация и удаление избыточности произво- дится позже при построении концептуальной модели данных в модуле Silverrun ERX. После создания модели бизнес-про- цессов информация сохраняется в репозитории проекта. В процессе обследования работы организации выявляют- ся и документируются структуры первичных данных. Эти структуры заносятся в репозитории модуля ВРМ при описа- нии циркулирующих в организации документов, сообщений, данных. В модели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации. На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель от- личается удалением избыточности, стандартизацией наиме- нований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной сис- темы. Цель концептуальной модели данных — описать исполь- зуемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализо- ванном виде. На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура АИС. Определя- ются входящие в систему приложения, для каждого прило- жения специфицируются используемые данные и реализуе- мые функции. Архитектура АИС создается в модуле Silverrun ВРМ с использованием специальной нотации ISA. Основное 181
содержание этой модели — структурные компоненты систе- мы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям. Перед разработкой приложений должна быть спроекти- рована структура корпоративной базы данных. DATARUN предполагает использование базы данных, основанной на ре- ляционной модели. Концептуальная модель данных после нор- мализации переносится в модуль реляционного моделирова- ния Silverrun RDM с помощью специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM про- исходит автоматически без вмешательства пользователя. После преобразования форматов получается модель реляционной базы данных. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений целостно- сти). Правила обработки данных можно задавать как непос- редственно на языке программирования СУБД, так и в дек- ларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларатив- ные правила на язык требуемой системы, что снижает тру- доемкость программирования процедур сервера базы данных, а также позволяет из одной спецификации генерировать при- ложения для разных СУБД. С помощью модели системных процессов детально доку- ментируется поведение каждого приложения. В модуле ВРМ создается модель системных процессов, определяющая, ка- ким образом реализуются бизнес-процессы. Эта модель со- здается отдельно для каждого приложения и тесно связана с моделью данных приложения. Приложение состоит из интерфейсных объектов (экран- ных форм, отчетов, процедур обработки данных). Каждый интерфейс системы (экранная форма, отчет, процедура об- работки данных) имеет дело с подмножеством базы данных. В модели данных приложения (созданной в модуле RDM) со- здается подсхема базы данных для каждого интерфейса это- 182
го приложения. Уточняются также правила обработки дан- ных, специфичные для каждого интерфейса. Модель представления интерфейса — это описание внеш- него вида интерфейса с точки зрения конечного пользовате- ля системы. Это может быть документ, показывающий вне- шний вид экрана или структуру отчета, или экран (отчет), созданный с помощью одного из средств визуальной разра- ботки приложений — так называемых языков четвертого по- коления (4GL — Fourth Generation Languages). Так как боль- шинство языков 4GL позволяет быстро создавать работаю- щие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования. После создания подсхем реляционной модели для прило- жений проектируется детальная структура каждого прило- жения в виде схемы навигации экранов, отчетов, процедур пакетной обработки. На данном шаге эта структура детализи- руется до указания конкретных столбцов и таблиц базы дан- ных, правил их обработки, вида экранных форм и отчетов. Полученная модель детально документирует приложение и непосредственно используется для программирования специ- фицированных интерфейсов. Далее, с помощью средств разработки приложений про- исходит физическое создание системы: приложения програм- мируются и интегрируются в информационную систему. Характеристика современных CASE-cpedcme Современные CASE-средства охватывают обширную об- ласть поддержки многочисленных технологий проектирова- ния ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО [14]. Наиболее трудоемкими этапами разработки ИС являют- ся этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых техни- ческих решений и подготовку проектной документации. При 183
этом большую роль играют методы визуального представле- ния информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использо- вание многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирова- ния предметной области позволяют разработчикам в нагляд- ном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися огра- ничениями. В разряд CASE-средств попадают как относительно де- шевые системы для персональных компьютеров с весьма ог- раниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операцион- ных сред. Так, современный рынок программных средств на- считывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практичес- ки всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность про- цессов жизненного цикла ПО и обладающее следующими ос- новными характерными особенностями: ♦ мощными графическими средствами для описания и документирования АИС, обеспечивающими удобный ин- терфейс с разработчиком и развивающими его твор- ческие возможности; ♦ интеграцией отдельных компонент CASE-средств, обес- печивающей управляемость процессом разработки АИС; ♦ использованием специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие ком- поненты: ♦ репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при группо- 184
вой разработке, контроль метаданных на полноту и непротиворечивость; ♦ графические средства анализа и проектирования, обес- печивающие создание и редактирование иерархичес- ки связанных диаграмм (DFD, ERD и др.), образующих модели ИС; ♦ средства разработки приложений, включая языки 4GL и генераторы кодов; ♦ средства конфигурационного управления; ♦ средства документирования; ♦ средства тестирования; ♦ средства управления проектом; ♦ средства реинжиниринга. Все современные CASE-средства могут быть классифи- цированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE- средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выпол- няемым функциям и включает отдельные локальные сред- ства, решающие небольшие автономные задачи (tools), на- бор частично интегрированных средств, охватывающих боль- шинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-сред- ства можно классифицировать по следующим признакам: ♦ применяемым методологиям и моделям систем и БД; ♦ степени интегрированности с СУБД; ♦ доступным платформам. Классификация по типам в основном совпадает с компо- нентным составом CASE-средств и включает следующие ос- новные типы (после названия средства в скобках указана фирма-разработчик): ♦ средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPWin (Logic Works)); 185
♦ средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методо- логии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналитик (Макро- Проджект)). Выходом таких средств являются специ- фикации компонентов и интерфейсов системы, архи- тектуры системы, алгоритмов и структур данных; ♦ средства проектирования баз данных, обеспечиваю- щие моделирование данных и генерацию схем баз дан- ных (как правило, на языке SQL) для наиболее рас- пространенных СУБД. К ним относятся ERwin (Logic Works). S-Designor (SDP) и DataBase Designer (Oracle). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; ♦ средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun; ♦ средства реинжиниринга, обеспечивающие анализ про- граммных кодов и схем баз данных и формирование на их основе различных моделей и проектных специфи- каций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В облас- ти анализа программных кодов наибольшее распрост- ранение получают объектно-ориентированные CASE- средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают: ♦ средства планирования и управления проектом (SE Companion, Microsoft Project и др.); 186
♦ средства конфигурационного управления (PVCS (Intersolv)); ♦ средства тестирования (Quality Works (Segue Software)); ♦ средства документирования (SoDA (Rational Software)). На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами: ♦ Silverrun; ♦ Designer/2000; ♦ Vantage Team Builder (Westmount I-CASE); ♦ ERwin+BPwin; ♦ S-Designor; ♦ CASE-Аналитик. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE/ 4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечислен- ных систем. Охарактеризуем основные возможности CASE-средств на примере имеющей широкое распространение системы Silverrun. CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и про- ектирования АИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для под- держки любой методологии, основанной на раздельном пост- роении функциональной и информационной моделей (диаг- рамм потоков данных и диаграмм “сущность—связь”). Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе име- ются готовые настройки для наиболее распространенных ме- тодологий: DATARUN (основная методология, поддерживае- мая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления 187
собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости. Silverrun имеет модульную структуру и состоит из четы- рех модулей, каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без свя- зи с остальными модулями. Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ — Business Process Modeler) позволяет моделировать функционирование обследуемой орга- низации или создаваемой АИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автома- тическая перенумерация, работа с деревом процессов (вклю- чая визуальное перетаскивание ветвей), отсоединение и при- соединение частей модели для коллективной разработки. Ди- аграммы могут изображаться в нескольких предопределен- ных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме деск- рипторов определенные пользователем поля. Модуль концептуального моделирования данных (ERX — Entity-Relationship eXpert) обеспечивает построение моделей данных “сущность—связь”, не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную сис- тему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные воп- росы о взаимосвязи данных. Возможно автоматическое пост- роение модели данных из описаний структур данных. Ана- лиз функциональных зависимостей атрибутов дает возмож- ность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверен- ная модель передается в модуль RDM. Модуль реляционного моделирования (RDM— Relational Data Modeler) позволяет создавать детализированные модели “сущность—связь”, предназначенные для реализации в ре- ляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индек- 188
сы, триггеры, хранимые процедуры и т. д. Гибкая изменяе- мая нотация и расширяемость репозитория позволяют рабо- тать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы рас- пределенной обработки, так и пользовательские представле- ния. Этот модуль обеспечивает проектирование и полное до- кументирование реляционных баз данных. Менеджер репозитория рабочей группы (WRM — Workgroup Repository Manager) применяется как словарь дан- ных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования. Платой за высокую гибкость и разнообразие изобрази- тельных средств построения моделей является такой недо- статок Silverrun, как отсутствие жесткого взаимного конт- роля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, од- нако, отметить, что этот недостаток может иметь существен- ное значение только в случае использования каскадной мо- дели ЖЦ ПО. Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки прило- жений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволя- ют загрузить в Silverrun RDM информацию из каталогов со- ответствующих СУБД или языков 4GL. Это позволяет доку- ментировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun рас- ширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внут- 189
ренний каталог среды разработки или использует при генера- ции кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех воз- можностей конкретной СУБД: триггеров, хранимых проце- дур, ограничений ссылочной целостности. При создании при- ложения на языке 4GL данные, перенесенные из репозито- рия Silverrun, используются либо для автоматической гене- рации интерфейсных объектов, либо для быстрого их созда- ния вручную. Для обмена данными с другими средствами автоматиза- ции проектирования, создания специализированных проце- дур анализа и проверки проектных спецификаций, составле- ния специализированных отчетов в соответствии с различны- ми стандартами в системе Silverrun имеются три способа выдачи проектной информации во внешние файлы: ♦ система отчетов. Можно, определив содержимое отче- та по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редак- тор или включить в другой отчет; ♦ система экспорта/импорта. Для более полного контро- ля над структурой файлов в системе экспорта/импор- та имеется возможность определять не только содер- жимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не толь- ко формировать, но и загружать в репозиторий. Это дает возможность обмениваться данными с различны- ми системами: другими CASE-средствами, СУБД, тек- стовыми редакторами и электронными таблицами; ♦ хранение репозитория во внешних файлах через ODBC- драйверы. Для доступа к данным репозитория из наи- более распространенных систем управления базами данных обеспечена возможность хранить всю проект- ную информацию непосредственно в формате этих СУБД. 190
Групповая работа поддерживается в системе Silverrun двумя способами: ♦ в стандартной однопользовательской версии имеется механизм контролируемого разделения и слияния мо- делей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработ- ки модели объединяются в единые спецификации; ♦ сетевая версия Silverrun позволяет осуществлять одно- временную групповую работу с моделями, хранящи- мися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчи- ков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели. Имеются реализации Silverrun трех платформ — MS Windows, Macintosh и OS/2 Presentation Manager — с воз- можностью обмена проектными данными между ними. Помимо системы Silverrun, укажем назначение и дру- гих популярных CASE-средств и их групп. Vantage Team Builder представляет собой интегрирован- ный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО. Uniface 6.1 — продукт фирмы Compuware (США) — пред- ставляет собой среду разработки крупномасштабных прило- жений в архитектуре “клиент—сервер”. CASE-средство Designer/2000 2.0 фирмы Oracle являет- ся интегрированным CASE-средством, обеспечивающим в со- вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ПО для систем, использующих СУБД Oracle. Пакет CASE/4/0 (microTOOL GmbH), включающий струк- турные средства системного анализа, проектирования и про- граммирования, обеспечивает поддержку всего жизненного цикла разработки (вплоть до сопровождения), на основе сете- вого репозитория, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналитиков, проектировщиков, программистов). 191
Локальные средства Пакет ERWin (Logic Works) используется при моделиро- вании и создании баз данных произвольной сложности на ос- нове диаграмм “сущность—связь”. В настоящее время ERWin является наиболее популярным пакетом моделирования дан- ных благодаря поддержке широкого спектра СУБД самых различных классов — SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdbn др.) и “настольных” СУБД типа xBase (Clipper, dBase, FoxPro, MS Access, Paradox и др.). BPWin — средство функционального моделирования, реализующее методологию IDEFO. Модель в BPWin представ- ляет собой совокупность SADT-диаграмм, каждая из кото- рых описывает отдельный процесс, разбивая его на шаги и подпроцессы. S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных баз дан- ных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERWin, отличаясь внешне ис- пользуемой на диаграммах нотацией. S-Designer реализует стандартную методологию моделирования данных и генери- рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server и др. CASE-Аналитик 1.1 (Эйтекс) является практически един- ственным в настоящее время конкурентоспособным отече- ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответ- ствии с описанной ранее методологией. Объектно-ориентированные CASE-cpedcmea Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации эта- пов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документа- ции. Rational Rose использует синтез-методологию объектно- ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, 192
Рамбо и Джекобсона. Разработанная ими универсальная но- тация для моделирования объектов (язык UML — Unified Modeling Language) является в настоящее время и, очевид- но, останется в будущем общепринятым стандартом в облас- ти объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной ва- риант — Rational Rose/C++ — позволяет разрабатывать про- ектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных ком- понент в новых проектах. Средства конфигурационного управления Цель конфигурационного управления (КУ) — обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достовер- ная информация о состоянии ПО и его компонент в каждый момент времени, а также о всех предполагаемых и выпол- ненных изменениях. Для решения задач КУ применяются методы и средства, обеспечивающие идентификацию состояния компонент, учет номенклатуры всех компонент и модификаций системы в це- лом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координирован- ное управление развитием функций и улучшением характе- ристик системы. Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоя- тельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify. Средства документирования Для создания документации в процессе разработки АИС используются разнообразные средства формирования отче- 193
тов, а также компоненты издательских систем. Обычно сред- ства документирования встроены в конкретные CASE-сред- ства. Исключением являются некоторые пакеты, предостав- ляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation). Продукт SoDA предназначен для автоматизации разра- ботки проектной документации на всех фазах ЖЦ ПО. Он по- зволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и вклю- чать ее в выходные документы. При этом контролируется соответствие документации проекту, взаимосвязь докумен- тов, обеспечивается их своевременное обновление. Результи- рующая документация автоматически формируется из мно- жества источников, число которых не ограничено. Пакет включает в себя графический редактор для подго- товки шаблонов документов. Он позволяет задавать необходи- мый стиль, фон, шрифт, определять расположение заголов- ков, резервировать места, где будет размещаться извлекае- мая из разнообразных источников информация. Изменения автоматически вносятся только в те части документации, на которые они повлияли в программе. Это сокращает время подготовки документации за счет отказа от перегенерации всей документации. SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по ре- дактированию и верстке выпускаемой документации. Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого до- кумента (или его части) возможен из системы SoDA. Среда функционирования SoDA — ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800. 194
Средства тестирования Под тестированием понимается процесс исполнения про- граммы с целью обнаружения ошибок. Регрессионное тести- рование — это тестирование, проводимое после усовершен- ствования функций программы или внесения в нее измене- ний. Одно из наиболее развитых средств тестирования QA (новое название — Quality Works) представляет собой интег- рированную, многоплатформенную среду для разработки ав- томатизированных тестов любого уровня, включая тесты рег- рессии для приложений с графическим интерфейсом пользо- вателя. QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отобра- жать изменения в приложении и повторно использовать тес- ты для более чем 25 различных платформ. В заключение приведем пример комплекса CASE-средств, обеспечивающего поддержку полного ЖЦ ПО. Нецелесооб- разно сравнивать отдельно взятые CASE-средства, посколь- ку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методоло- гически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со сто- роны фирм-поставщиков (отметим, что рациональное комп- лексирование инструментальных средств разработки ПО ИС является важнейшим условием обеспечения качества этого ПО, причем это замечание справедливо для всех предмет- ных областей). На сегодняшний день наиболее развитым из всех поставляемых в Россию комплексов такого рода являет- ся комплекс технологий и инструментальных средств созда- ния ИС, основанный на методологии и технологии DATARUN. 195
В состав комплекса входят следующие инструментальные средства: ♦ CASE-средство Silverrun; ♦ средство разработки приложений JAM; ♦ мост Silverrun-RDM <-> JAM; ♦ комплекс средств тестирования QA; ♦ менеджер транзакций Tuxedo; ♦ комплекс средств планирования и управления проек- том SE Companion; ♦ комплекс средств конфигурационного управления PVCS; ♦ объектно-ориентированное CASE-средство Rational Rose; ♦ средство документирования SoDA.
2. БАЗЫ ДАННЫХ 2.1. Принципы построения и этапы проектирования базы данных Автоматизированные информационно-справочные систе- мы в настоящее время получили весьма широкое распрост- ранение, что связано прежде всего со сравнительной про- стотой их создания и исключительно высоким эффектом от внедрения. Методологической основой информационных тех- нологий, реализуемых в АИСС, являются концепции центра- лизованной (в рамках разработки баз и банков данных) и рас- пределенной (в рамках создания информационных сетей) об- работки информации. 2 .1.1. Основные понятия и определения В науке одним из наиболее сложных для строгого опре- деления является понятие “информация”. Согласно киберне- тическому подходу [15] “информация — первоначальное со- общение данных, сведений, осведомление и т. п. Кибернети- ка вывела понятие информации за пределы человеческой речи и других форм коммуникации между людьми, связала его с целенаправленными системами любой природы. Информация выступает в трех формах: ♦ биологической (биотоки; связи в генетических механиз- мах); ♦ машинной (сигналы в электрических цепях); ♦ социальной (движение знаний в общественных систе- мах)”. 197
Иными словами, “информация — связь в любых целе- направленных системах, определяющая их целостность, ус- тойчивость, уровень функционирования” [49]. Содержание и особенности информации раскрываются указанием действий, в которых она участвует: ♦ хранение (на некотором носителе информации); ♦ преобразование (в соответствии с некоторым алгорит- мом)', ♦ передача (с помощью передатчика л приемника по не- которой линии связи). В соответствии с этим же подходом "данные — факты и идеи, представленные в формализованном виде, позволяющем передавать или обрабатывать их при помощи некоторого про- цесса и соответствующих технических устройств” [15]. Толковый словарь по информатике [49, 53] определяет понятия “информация” и “данные” несколько иначе: “информация — 1) совокупность знаний о фактических данных и связях между ними; 2) в вычислительной техни- ке — содержание, присваиваемое данным посредством согла- шений, распространяющихся на эти данные; данные, подле- жащие вводу в ЭВМ, хранимые в ее памяти, обрабатывае- мые на ЭВМ и выдаваемые пользователям”; “данные — информация, представленная в виде, пригод- ном для обработки автоматическими средствами при воз- можном участии человека”. Как легко заметить, приведенные определения вынуж- денно используют такие сложно определяемые понятия, как “факты”, “идеи” и, особенно, “знания”. В дальнейшем под информацией будем понимать любые сведения о процессах и явлениях, которые в той или иной форме передаются между объектами материального мира (людьми; животными; растениями; автоматами и др.). Если рассмотреть некоторый объект материального мира, информация о котором представляет интерес, и наблюдате- ля (в роли которого и выступают АИС), способного фиксиро- вать эту информацию в определенной, понятной другим фор- 198
ме, то говорят, что в памяти (“сознании”) наблюдателя на- ходятся данные, описывающие состояние объекта. Таким об- разом, данными будем называть формализованную инфор- мацию, пригодную для последующей обработки, хранения и передачи средствами автоматизации профессиональной де- ятельности. Информацию в ЭВМ можно хранить в виде различных данных (числовых; текстовых; визуальных и т. п.). Более того, для описания одной и той же информации можно предло- жить различные варианты их состава и структуры. Иными словами, правомерно говорить о моделировании в АИС ин- формации о некотором множестве объектов материального мира совокупностью взаимосвязанных данных. Информационное обеспечение (information support) АИС — совокупность единой системы классификации и кодирования информации; унифицированных систем документации и ис- пользуемых массивов информации [53, 54]. В дальнейшем нас будет интересовать именно последний аспект данного опре- деления. В этой связи в качестве главных задач создания инфор- мационного обеспечения АИС можно выделить: ♦ во-первых, определение состава и структуры дан- ных, достаточно “хорошо” описывающих требуемую информацию; ♦ во-вторых, обоснование способов хранения и перера- ботки данных с использованием ЭВМ. Процесс создания информационного обеспечения вклю- чает несколько этапов, рассмотрению которых посвящен п. 2.1.2. В данном пункте остановимся на понятиях и опреде- лениях, связанных с технологией банков данных. Прежде чем определить понятие “банк данных”, необ- ходимо остановиться на другом ключевом понятии — “пред- метная область”. Под предметной областью будем понимать информацию об объектах, процессах и явлениях окружающего мира, ко- торая, с точки зрения потенциальных пользователей, бол- 199
жна храниться и обрабатываться в информационной сис- теме. В этом определении особое внимание следует уделить важности роли потенциальных потребителей информацион- ных ресурсов АИС. Именно этот аспект обусловливает и струк- туру, и основные задачи, и вообще целесообразность созда- ния того или иного банка. Банк данных (БнД) — информационная система, вклю- чающая в свой состав комплекс специальных методов и средств для поддержания динамической информационной модели с целью обеспечения информационных потребностей пользователей [15, 39]. Очевидно, что БнД может рассматри- ваться как специальная обеспечивающая подсистема в соста- ве старшей по иерархии АИС. Поддержание динамической модели ПО предусматривает не только хранение информации о ней и своевременное вне- сение изменений в соответствии с реальным состоянием объек- тов, но и обеспечение возможности учета изменений состава этих объектов (в том числе появление новых) и связей между ними (т. е. изменений самой структуры хранимой информа- ции). Обеспечение информационных потребностей (запросов) пользователей имеет два аспекта [45]: ♦ определение границ конкретной ПО и разработка опи- сания соответствующей информационной модели', ♦ разработка БнД, ориентированного на эффективное обслуживание запросов различных категорий пользо- вателей. С точки зрения целевой направленности профессиональ- ной деятельности принято выделять пять основных катего- рий пользователей [45]: ♦ аналитики; ♦ системные программисты; ♦ прикладные программисты; ♦ администраторы; ♦ конечные пользователи. 200
Кроме того, различают пользователей постоянных и ра- зовых; пользователей-людей и пользователей-задач; пользо- вателей с различным уровнем компетентности (приорите- том) и др., причем каждый класс пользователей предъявляет собственные специфические требования к своему обслужива- нию (прежде всего — с точки зрения организации диалога “зап- рос—ответ”). Так, например, постоянные пользователи, как правило, обращаются в БнД с фиксированными по форме (ти- повыми) запросами; пользователи-задачи должны иметь воз- можность получать информацию из БнД в согласованной фор- ме в указанные области памяти; пользователи с низким при- оритетом могут получать ограниченную часть информации и т. д. Наличие столь разнообразного состава потребителей ин- формации потребовало включения в БнД специального эле- мента — словаря данных, о чем будет сказано ниже. Уровень сложности и важности задач информационного обеспечения АИС в рамках рассматриваемой технологии оп- ределяет ряд основных требований к БнД [53]: ♦ адекватность информации состоянию предметной об- ласти; ♦ быстродействие и производительность; ♦ простота и удобство использования; ♦ массовость использования; ♦ защита информации; ♦ возможность расширения круга решаемых задач. (Отметим, что все названные требования можно предъя- вить и к любому финансовому банку.) По сравнению с традиционным обеспечением монополь- ными файлами каждого приложения централизованное уп- равление данными в БнД имеет ряд важных преимуществ: ♦ сокращение избыточности хранимых данных; ♦ устранение противоречивости хранимых данных; ♦ многоаспектное использование данных (при однократ- ном вводе); ♦ комплексная оптимизация (с точки зрения удовлетво- рения разнообразных, в том числе и противоречивых, требований “в целом”); 201
♦ обеспечение возможности стандартизации', ♦ обеспечение возможности санкционированного доступа к данным и др. Все названные преимущества по существу связаны с такими основополагающими принципами концепции БнД, как интеграция данных, централизация управления ими и обес- печение независимости прикладных программ обработки дан- ных и самих данных. Структура типового БнД, удовлетворяющего предъяв- ляемым требованиям, приведена на рис. 2.1.1, где представ- лены: ♦ ВС — вычислительная система, включающая техни- ческие средства (ТС) и общее программное обеспече- ние (ОНО); ♦ БД — базы данных; ♦ СУБД — система управления БД; ♦ АБД — администратор баз данных, а также обслужи- вающий персонал и словарь данных. Подробнее остановимся на составляющих БнД, представ- ляющих наибольший интерес. БД — совокупность специаль- ным образом организованных (структурированных) данных и связей между ними. Иными словами, БД — это так называ- емое датологическое (от англ, data — данные) представление информации о предметной области. Если в состав БнД вхо- дит одна БД, банк принято называть локальным', если БД несколько — интегрированным. СУБД — специальный комплекс программ и языков, по- средством которого организуется централизованное управ- ление базами данных и обеспечивается доступ к ним. В состав любой СУБД входят языки двух типов: ♦ язык описания данных (с его помощью описываются типы данных, их структура и связи); ♦ язык манипулирования данными (его часто называют язык запросов к БД), предназначенный для организа- ции работы с данными в интересах всех типов пользо- вателей. 202
Рис. 2.1.1. Основные компоненты БнД Словарь данных предназначен для хранения единообраз- ной и централизованной информации обо всех ресурсах дан- ных конкретного банка: ♦ об объектах, их свойствах и отношениях для данной ПО; ♦ о данных, хранимых в БД (наименование; смысловое описание; структура; связи и т. п.); ♦ о возможных значениях и форматах представления данных; ♦ об источниках возникновения данных; ♦ о кодах защиты и разграничении доступа пользова- телей к данным и т. п. Администратор баз данных — это лицо (группа лиц), реализующее управление БД. В этой связи сам БнД можно рассматривать как автоматизированную систему управле- ния базами данных. Функции АБД являются долгосрочными; он координирует все виды работ на этапах создания и приме- нения БнД. На стадии проектирования АБД выступает как идеолог и главный конструктор системы; на стадии эксплуа- тации он отвечает за нормальное функционирование БнД, управляет режимом его работы и обеспечивает безопасность данных (последнее особенно важно при современном уровне развития средств коммуникации — см. подразд. 1.5). 203
Основные функции АБД [15, 54]: ♦ решать вопросы организации данных об объектах ПО и установления связей между этими данными с целью объединения информации о различных объектах; со- гласовывать представления пользователей; ♦ координировать все действия по проектированию, ре- ализации и ведению БД; учитывать текущие и перс- пективные требования пользователей; следить, чтобы БД удовлетворяли актуальным потребностям; ♦ решать вопросы, связанные с расширением БД в связи с изменением границ ПО; ♦ разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секрет- ности определенной части данных и разграничению доступа к ним; ♦ выполнять работы по ведению словаря данных; конт- ролировать избыточность и противоречивость данных, их достоверность; ♦ следить за тем, чтобы БнД отвечал заданным требова- ниям по производительности, т. е. чтобы обработка зап- росов выполнялась за приемлемое время; ♦ выполнять при необходимости изменения методов хра- нения данных, путей доступа к ним, связей между дан- ными, их форматов; определять степень влияния из- менений в данных на всю БД; ♦ координировать вопросы технического обеспечения си- стемы аппаратными средствами, исходя из требований, предъявляемых БД к оборудованию; ♦ координировать работы системных программистов, раз- рабатывающих дополнительное программное обеспече- ние для улучшения эксплуатационных характеристик системы; ♦ координировать работы прикладных программистов, разрабатывающих новые прикладные программы, и вы- полнять их проверку и включение в состав ПО систе- мы и т. п. 204
На рис. 2.1.2 представлен типовой состав группы АБД, отражающий основные направления деятельности специали- стов. Рис. 2.1.2. Типовой состав группы АБД 2.1.2. Описательная модель предметной области Процесс проектирования БД является весьма сложным. По сути, он заключается в определении перечня данных, хранимых на физических носителях (магнитных дисках и лен- тах), которые достаточно полно отражают информационные потребности потенциальных пользователей в конкретной ПО. Проектирование БД начинается с анализа предметной облас- ти и возможных запросов пользователей. В результате этого анализа определяется перечень данных и связей между ними, которые адекватно — с точки зрения будущих потребите- лей — отражают ПО. Завершается проектирование БД опре- делением форм и способов хранения необходимых данных на физическом уровне. Весь процесс проектирования БД можно разбить на ряд взаимосвязанных этапов, каждый из которых обладает свои- ми особенностями и методами проведения. На рис. 2.1.3 пред- ставлены типовые этапы. На этапе инфологического (информационно-логическо- го) проектирования осуществляется построение семантичес- 205
.Рис. 2.1.3. Этапы проектирования БД кой модели, описывающей сведения из предметной области, которые могут заинтересовать пользователей БД. Семанти- ческая модель (semantic model) — представление совокуп- ности о ПО понятий... в виде графа, в вершинах которого расположены понятия, в терминальных вершинах — эле- ментарные понятия, а дуги представляют отношения меж- ду понятиями. Сначала из объективной реальности выделяется ПО, т. е. очерчиваются ее границы. Логический анализ выделенной ПО и потенциальных запросов пользователей завершается пост- роением инфологической модели ПО — перечня сведений об объектах ПО, которые необходимо хранить в БД и связях между ними. Анализ информационных потребностей потенциальных пользователей имеет два аспекта: ♦ определение собственно сведений об объектах ПО', ♦ анализ возможных запросов к БД и требований по опе- ративности их выполнения. 206
Анализ возможных запросов к БД позволяет уточнить связи между сведениями, которые необходимо хранить. Пусть, например, в БД по учебному процессу института хра- нятся сведения об учебных группах, читаемых курсах и ка- федрах, а также связи “учебные группы—читаемые курсы” и “читаемые курсы—кафедры”. Тогда запрос о том, прово- дит ли некоторая кафедра занятия в конкретной учебной груп- пе может быть выполнен только путем перебора всех читае- мых в данной группе курсов. Хранение большого числа связей усложняет БД и при- водит к увеличению потребной памяти ЭВМ, но часто суще- ственно ускоряет поиск нужной информации. Поэтому разра- ботчику БД (АБД) приходится принимать компромиссное ре- шение, причем процесс определения перечня хранимых свя- зей, как правило, имеет итерационный характер. Датологическое проектирование подразделяется на ло- гическое (построение концептуальной модели данных) и фи- зическое (построение физической модели) проектирование. Главной задачей логического проектирования (ЛП) БД является представление выделенных на предыдущем этапе сведений в виде данных в форматах, поддерживаемых выб- ранной СУБД. Задача физического проектирования (ФП) — выбор спо- соба хранения данных на физических носителях и методов доступа к ним с использованием возможностей, предоставля- емых СУБД. Мифологическая модель “сущность—связь” (entity — relationship model; ER-model) П. Чена (Р. Chen) представляет собой описательную (неформальную) модель ПО, семанти- чески определяющую в ней сущности и связи [44]. Относительная простота и наглядность описания ПО по- зволяет использовать ее в процессе диалога с потенциальны- ми пользователями с самого начала инфологического проек- тирования. Построение инфо логической модели П. Чена, как и любой другой модели, является творческим процессом, по- 207
этому единой методики ее создания нет. Однако при любом подходе к построению модели используют три основных кон- структивных элемента: ♦ сущность; ♦ атрибут; ♦ связь. Сущность — это собирательное понятие некоторого по- вторяющегося объекта, процесса или явления окружающего мира, о котором необходимо хранить информацию в системе. Сущность может определять как материальные (например, ’’студент”, “грузовой автомобиль” и т. п.), так и нематериаль- ные объекты (например, “экзамен”, “проверка” и т. п.). Глав- ной особенностью сущности является то, что вокруг нее со- средоточен сбор информации в конкретной ПО. Тип сущности определяет набор однородных объектов, а экземпляр сущно- сти — конкретный объект в наборе. Каждая сущность в модели Чена именуется. Для идентификации конкретного эк- земпляра сущности и его описания используется один или несколько атрибутов. Атрибут — это поименованная характеристика сущно- сти, которая принимает значения из некоторого множества значений [46]. Например, у сущности “студент” могут быть атрибуты “фамилия”, “имя”, “отчество”, “дата рождения”, “средний балл за время обучения” и т. п. Связи в инфо логической модели выступают в качестве средства, с помощью которого представляются отношения между сущностями, имеющими место в ПО. При анализе связей между сущностями могут встречаться бинарные (между двумя сущностями) и, в общем случае, n-арные (между п сущностями) связи. Например, сущности “отец”, “мать” и “ребенок” могут находиться в трехарном отношении “семья” (“является членом семьи”). Связи должны быть поименованы; между двумя типами сущностей могут существовать несколько связей. 208
Наиболее распространены бинарные связи. Учитывая, что любую n-арную связь можно представить в виде нескольких бинарных, подробнее остановимся именно на таких связях между двумя типами сущностей, устанавливающими соот- ветствие между множествами экземпляров сущностей. Различают четыре типа связей: ♦ связь один к одному (1:1); ♦ связь один ко многим (1:М); ♦ связь многие к одному (М:1); ♦ связь многие ко многим (M:N). Связь один к одному определяет такой тип связи между типами сущностей А и В, при которой каждому экземпляру сущности А соответствует один и только один экземпляр сущ- ности В, и наоборот. Таким образом, имея некоторый экземп- ляр сущности А, можно однозначно идентифицировать со- ответствующий ему экземпляр сущности В, а по экземпляру сущности В — экземпляр сущности А. Например, связь типа 1:1 “имеет” может быть определена между сущностями “ав- томобиль” и “двигатель”, так как на конкретном автомобиле может быть установлен только один двигатель, и этот двига- тель, естественно, нельзя установить сразу на несколько ав- томобилей. Связь один ко многим определяет такой тип связи между типами сущностей А и В, для которой одному экземпляру сущности А может соответствовать 0, 1 или несколько экзем- пляров сущности В, но каждому экземпляру сущности В со- ответствует один экземпляр сущности А. При этом однознач- но идентифицировать можно только экземпляр сущности А по экземпляру сущности В. Примером связи типа 1:М явля- ется связь “учится” между сущностями “учебная группа” и “студент”. Для такой связи, зная конкретного студента, можно однозначно идентифицировать учебную группу, в которой он учится, или, зная учебную группу, можно определить всех обучающихся в ней студентов. 209
Связь многие к одному по сути эквивалентна связи один ко многим. Различие заключается лишь в том, с точки зре- ния какой сущности (А или В) данная связь рассматривается. Связь многие ко многим определяет такой тип связи меж- ду типами сущностей А и В, при котором каждому экземп- ляру сущности А может соответствовать 0, 1 или несколько экземпляров сущности В, и наоборот. При такой связи, зная экземпляр одной сущности, можно указать все экземпля- ры другой сущности, относящиеся к исходному, т. е. иден- тификация сущностей не уникальна в обоих направлениях. В качестве примера такой связи можно рассмотреть связь “изучает” между сущностями “учебная дисциплина” и “учеб- ная группа”. Реально все связи являются двунаправленными, т. е., зная экземпляр одной из сущностей, можно идентифицировать (однозначно или многозначно) экземпляр (экземпляры) дру- гой сущности. В некоторых случаях целесообразно рассмат- ривать лишь однонаправленные связи между сущностями в целях экономии ресурсов ЭВМ. Возможность введения таких связей полностью определяется информационными потребно- стями пользователей. Различают простую и многозначную однонаправленные связи, которые являются аналогами свя- зей типа 1:1 и 1:М с учетом направления идентификации. Так, для простой однонаправленной связи “староста” (“является старостой”) между сущностями “учебная группа” и “студент” можно, зная учебную группу, однозначно определить ее ста- росту, но, зная конкретного студента, нельзя сказать, явля- ется ли он старостой учебной группы. Примером многознач- ной однонаправленной связи служит связь между сущностя- ми “пациент” и “болезнь”, для которой можно для каждого пациента указать его болезни, но нельзя выявить всех обла- дателей конкретного заболевания. Введение однонаправленных связей означает, что в ре- зультате анализа потенциальных запросов потребителей ус- тановлено, что потребности в информации, аналогичной при- веденной в двух последних примерах, у пользователей не 210
будет (и они не будут формулировать соответствующие зап- росы к БД). Графически типы сущностей, атрибуты и связи принято изображать прямоугольниками, овалами и ромбами соответ- ственно. На рис. 2.1.4 представлены примеры связей различ- ных типов; на рис. 2.1.5 и 2.1.6 — фрагменты инфологических моделей “военнослужащие” (без указания атрибутов) и “учеб- ный процесс факультета”. Несмотря на то, что построение инфологической модели есть процесс творческий, можно указать два основополагаю- щих правила, которыми следует пользоваться всем проекти- ровщикам БД [15,44]: ♦ при построении модели должны использоваться толь- ко три типа конструктивных элементов: сущность, атрибут, связь; ♦ каждый компонент информации должен моделировать- ся только одним из приведенных выше конструктив- ных элементов для исключения избыточности и про- тиворечивости описания. Двунаправленные связи Пациент Рис. 2.1.4. Примеры связей между сущностями Заболевание Однонаправленная связь 211
Моделирование ПО начинают с выбора сущностей, не- обходимых для ее описания. Каждая сущность должна соот- ветствовать некоторому объекту (или группе объектов) ПО, о котором в системе будет накапливаться информация. Су- ществует проблема выбора конструктивного элемента для мо- делирования той или иной “порции” информации, что суще- ственно затрудняет процесс построения модели. Так, информация о том, что некоторый студент входит в состав учебной группы (УГ) можно в модели представить: ♦ как связь “входит в состав” для сущностей “студент” и “УГ”; ♦ как атрибут “имеет в составе “студента” сущности “УГ”; ♦ как сущность “состав УГ”. В этих случаях приходится рассматривать несколько ва- риантов и с учетом информационных потребностей пользова- телей разбивать ПО на такие фрагменты, которые с их точ- ки зрения представляют самостоятельный интерес. Рис. 2.1.5. Фрагмент ER-модели “Военнослужащие” При моделировании ПО следует обращать внимание на существующий в ней документооборот. Именно документы, циркулирующие в ПО, должны являться основой для форму- лирования сущностей. Это связано с двумя обстоятельствами: ♦ эти документы, как правило, достаточно полно отра- жают информацию, которую необходимо хранить в БД, причем в виде конкретных данных; 212
♦ создаваемая информационная система должна предос- тавлять пользователям привычную для них информа- цию в привычном виде, что в последующем существен- но облегчит ввод БД в эксплуатацию. Рис. 2.1.6. Фрагмент ER-модели “Учебный процесс факультета” При описании атрибутов сущности необходимо выбрать ряд атрибутов, позволяющих однозначно идентифицировать экземпляр сущности. Совокупность идентифицирующих ат- рибутов называют ключом. Помимо идентифицирующих используются и описатель- ные атрибуты, предназначенные для более полного опре- деления сущностей. Число атрибутов (их тип) определяется единственным образом — на основе анализа возможных зап- росов пользователей. Существует ряд рекомендаций по “ра- 213
боте с атрибутами” [15, 44], например, по исключению по- вторяющихся групп атрибутов (см. рис. 2.1.7). Все они направ- лены на улучшение качества инфологической модели. При определении связей между сущностями следует из- бегать связей типа M:N, так как они приводят к существен- ным затратам ресурсов ЭВМ. Устранение таких связей пре- дусматривает введение других (дополнительных) элементов — сущностей и связей. На рис. 2.1.8 приведен пример исключе- ния связи многие ко многим. Рис. 2.1.7. Пример исключения повторяющейся группы атрибутов В заключение приведем типовую последовательность ра- бот (действий) по построению инфологической модели: ♦ выделение в ПО сущностей', ♦ введение множества атрибутов для каждой сущности и выделение из них ключевых; ♦ исключение множества повторяющихся атрибутов (при необходимости); ♦ формирование связей между сущностями; ♦ исключение связей типа M:N (при необходимости); ♦ преобразование связей в однонаправленные (по возмож- ности). 214
Помимо модели Чена существуют и другие инфологи- ческие модели. Все они представляют собой описательные (неформальные) модели, использующие различные конструк- тивные элементы и соглашения по их использованию для представления в БД информации о ПО. Иными словами, пер- вый этап построения БД всегда связан с моделированием пред- метной области. Переход Рис. 2.1.8. Пример исключения связи типа M:N 2.1.3. Концептуальные модели данных В отличие от инфологической модели ПО, описывающей по некоторым правилам сведения об объектах материального мира и связи между ними, которые следует иметь в БД, кон- цептуальная модель описывает хранимые в ЭВМ данные и связи. В силу этого каждая модель данных неразрывно связа- на с языком описания данных конкретной СУБД (см. рис. 2.1.3). По существу модель данных — это совокупность трех составляющих [15, 44]: ♦ типов (структур) данных; ♦ операций над данными; ♦ ограничений целостности. 215
Другими словами, модель данных представляет собой некоторое интеллектуальное средство проектировщика, по- зволяющее реализовать интерпритацию сведений о ПО в виде формализованных данных в соответствии с определенными требованиями, т. е. средство абстракции, которое дает воз- можность увидеть “лес” (информационное содержание дан- ных), а не отдельные “деревья” (конкретные значения дан- ных). Типы структур данных Среди широкого множества определений, обозначающих типы структур данных, наиболее распространена термино- логия КОДАСИЛ (Conference of DAta SYstems Language) — международной ассоциации по языкам систем обработки дан- ных, созданной в 1959 г. В соответствии с этой терминологией используют пять типовых структур (в порядке усложнения): ♦ элемент данных-, ♦ агрегат данных-, ♦ запись; ♦ набор-, ♦ база данных. Дадим краткие определения этих структур [15, 44, 45]. Элемент данных — наименьшая поименованная единица данных, к которой СУБД может адресоваться непосредственно и с помощью которой выполняется построение всех осталь- ных структур данных. Агрегат данных — поименованная совокупность элемен- тов данных, которую можно рассматривать как единое це- лое. Агрегат может быть простым или составным (если он вклю- чает в себя другие агрегаты). Запись — поименованная совокупность элементов дан- ных и (или) агрегатов. Таким образом, запись — это агрегат, не входящий в другие агрегаты. Запись может иметь слож- ную иерархическую структуру, поскольку допускает много- кратное применение агрегации. 216
Набор — поименованная совокупность записей, образую- щих двухуровневую иерархическую структуру. Каждый тип набора представляет собой связь между двумя типами запи- сей. Набор определяется путем объявления одного типа за- писи “записью-владельцем”, а других типов записей — “за- писями-членами”. При этом каждый экземпляр набора дол- жен содержать один экземпляр “записи-владельца” и любое количество “записей-членов”. Если запись представляет в модели данных сущность, то набор — связь между сущнос- тями. Например, если рассматривать связь “учится” между сущностями “учебная группа” и “студент”, то первая из сущ- ностей объявляется “записью-владельцем” (она в экземпляре набора одна), а вторая — “записью-членом” (их в экземпля- ре набора может быть несколько). База данных — поименованная совокупность экземпля- ров записей различного типа, содержащая ссылки между записями, представленные экземплярами наборов. Отметим, что структуры БД строятся на основании сле- дующих основных композиционных правил [15, 44]: ♦ БД может содержать любое количество типов записей и типов наборов; ♦ между двумя типами записей может быть определено любое количество наборов; ♦ тип записи может быть владельцем и одновременно чле- ном нескольких типов наборов. Следование данным правилам позволяет моделировать данные о сколь угодно сложной ПО с требуемым уровнем полноты и детализации. Рассмотренные типы структур данных могут быть пред- ставлены в различной форме — графовой; табличной; в виде исходного текста языка описания данных конкретной СУБД. Операции над данными Операции, реализуемые СУБД, включают селекцию (по- иск) данных; действия над данными. Селекция данных выполняется с помощью критерия, осно- ванного на использовании либо логической позиции данного 217
(элемента; агрегата; записи), либо значения данного, либо связей между данными [46]. Селекция на основе логической позиции данного базиру- ется на упорядоченности данных в памяти системы. При этом критерии поиска могут формулироваться следующим образом: ♦ найти следующее данное (запись); ♦ найти предыдущее данное; ♦ найти n-ое данное; ♦ найти первое (последнее) данное. Этот тип селекции называют селекцией посредством текущей, в качестве которой используется индикатор текущего состояния, автоматически поддерживаемый СУБД и, как прави- ло, указывающий на некоторый экземпляр записи БД. Критерий селекции по значениям данных формируется из простых или булевых условий отбора. Примерами простых условий поиска являются: ♦ БУС = 200100; ♦ ВОЗРАСТ > 20; ♦ ДАТА < 19.04.2002 и т. п. Булево условие отбора формируется путем объединения простых условий с применением логических операций, на- пример: ♦ (ДАТА_РОЖДЕНИЯ < 28.12.1963) И (СТАЖ> 10); ♦ (УЧЕНОЕ_ЗВАНИЕ=ДОЦЕНТ:) ИЛИ (УЧЕНОЕ ЗВАНИЕ=ПРОФЕССОР) и т. п. Если модель данных, поддерживаемая некоторой СУБД, позволяет выполнить селекцию данных по связям, то можно найти данные, связанные с текущим значением какого-либо данного [46]. Например, если в модели данных реализована двунаправленная связь “учится” между сущностями “студент” и “учебная группа”, можно выявить учебные группы, в ко- торых учатся юноши (если в составе описания студента вхо- дит атрибут “пол”). Как правило, большинство современных СУБД позволя- ет осуществлять различные комбинации описанных выше видов селекции данных. 218
Ограничения целостности Ограничения целостности — логические ограничения на данные — используются для обеспечения непротиворечивос- ти данных некоторым заранее заданным условиям при вы- полнении операций над ними. По сути ограничения целостно- сти — это набор правил, используемых при создании конк- ретной модели данных на базе выбранной СУБД. Различают внутренние и явные ограничения. Ограничения, обусловленные возможностями конкрет- ной СУБД, называют внутренними ограничениями целост- ности. Эти ограничения касаются типов хранимых данных (например, “текстовый элемент данных может состоять не более чем из 256 символов” или “запись может содержать не более 100 полей”) и допустимых типов связей (например, СУБД может поддерживать только так называемые функци- ональные связи, т. е. связи типа 1:1, 1:М или М:1). Большин- ство существующих СУБД поддерживают прежде всего имен- но внутренние ограничения целостности [46], нарушения ко- торых приводят к некорректности данных и достаточно лег- ко контролируются. Ограничения, обусловленные особенностями хранимых данных о конкретной ПО, называют явными ограничениями целостности. Эти ограничения также поддерживаются сред- ствами выбранной СУБД, но они формируются обязательно с участием разработчика БД путем определения (программи- рования) специальных процедур, обеспечивающих непроти- воречивость данных. Например, если элемент данных “зачет- ная книжка” в записи “студент” определен как ключ, он дол- жен быть уникальным, т. е. в БД не должно быть двух запи- сей с одинаковыми значениями ключа. Другой пример: пусть в той же записи предусмотрен элемент “военно-учетная спе- циальность” и для него отведено 6 десятичных цифр. Тогда другие представления этого элемента данных в БД невоз- можны. С помощью явных ограничений целостности можно организовать как “простой” контроль вводимых данных (преж- де всего, на предмет принадлежности элементов данных фик- 219
сированному и заранее заданному множеству значений: на- пример, элемент “ученое звание” не должен принимать зна- чение “почетный доцент”, если речь идет о российских уче- ных), так и более сложные процедуры (например, введение значения “профессор” элемента данных “ученое звание” в запись о преподавателе, имеющем возраст 25 лет, должно требовать, по крайней мере, дополнительного подтвержде- ния). Элементарная единица данных может быть реализована множеством способов, что, в частности, привело к многооб- разию известных моделей данных. Модель данных определя- ет правила, в соответствии с которыми структурируются дан- ные. Обычно операции над данными соотносятся с их струк- турой. Разнообразие существующих моделей данных соответ- ствует разнообразию областей применения и предпочтений пользователей. В специальной литературе встречается описание довольно большого количества различных моделей данных. Хотя наи- большее распространение получили иерархическая, сетевая и, бесспорно, реляционная модели, вместе с ними следует упомянуть и некоторые другие. Используя в качестве классификационного признака осо- бенности логической организации данных, можно привести следующий перечень известных моделей данных: ♦ иерархическая; ♦ сетевая; ♦ реляционная; ♦ бинарная; ♦ семантическая сеть. Рассмотрим основные особенности перечисленных моде- лей. Иерархическая модель данных Наиболее давно используемой (можно сказать класси- ческой) является модель данных, в основе которой лежит 220
иерархическая структура типа дерева. Дерево — орграф, в каждую вершину которого, кроме первой (корневой), входит только одна дуга, а из любой вершины (кроме конечных) может исходить произвольное число дуг. В иерархической структуре подчиненный элемент данных всегда связан толь- ко с одним исходным. На рис. 2.1.9 показан фрагмент объектной записи в иерар- хической модели данных. Часто используется также “упоря- доченное дерево”, в котором значим относительный порядок поддеревьев. Достоинства такой модели несомненны: простота пред- ставления предметной области, наглядность, удобство ана- лиза структур и простота их описания. К недостаткам сле- дует отнести сложность добавления новых и удаления суще- ствующих типов записей, невозможность отображения отно- шений, отличающихся от иерархических, громоздкость опи- сания и информационную избыточность. Характерные примеры реализации иерархических струк- тур — язык Кобол и СУБД семейства IMS (создана в рамках проекта высадки на Луну — “Аполлон”) и System 2000 (S2K). Рис. 2.1.9. Фрагмент иерархической модели данных 221
Сетевая модель данных В системе баз данных, предложенных CODASYL, за ос- нову была взята сетевая структура. Существенное влияние на разработку этой модели оказали ранние сетевые систе- мы — IDS и Ассоциативный ПЛ/1. Необходимость в процессе получения одного отчета обрабатывать несколько файлов обус- ловила целесообразность установления перекрестных ссылок между файлами, что в конце концов и привело к сетевым структурам [54]. Сетевая модель данных основана на представлении инфор- мации в виде орграфа, в котором в каждую вершину может входить произвольное число дуг. Вершинам графа сопоставле- ны типы записей, дугам — связи между ними. На рис. 2.1.10 представлен пример структуры сетевой модели данных. По сравнению с иерархическими сетевые модели обла- дают рядом существенных преимуществ: возможность ото- бражения практически всего многообразия взаимоотношений объектов предметной области, непосредственный доступ к Рис. 2.1.10. Фрагмент сетевой модели данных любой вершине сети (без указания других вершин), малая информационная избыточность. Вместе с тем в сетевой моде- ли невозможно достичь полной независимости данных [54] — 222
с ростом объема информации сетевая структура становится весьма сложной для описания и анализа. Известно [62], что применение на практике иерархи- ческих и сетевых моделей данных в некоторых случаях тре- бует разработки и сопровождения значительного объема кода приложения, что иногда может стать для информационной системы непосильным бременем. Реляционная модель данных В основе реляционной модели данных (см. п. 2.1.4) лежат не графические, а табличные методы и средства представ- ления данных и манипулирования ими (рис. 2.1.11). В реляци- онной модели для отображения информации о предметной области используется таблица, называемая “отношением”. Строка такой таблицы называется кортежем, столбец — ат- рибутом. Каждый атрибут может принимать некоторое под- множество значений из определенной области — домена [42]. Рис. 2.1.11. Фрагмент реляционной модели данных 223
Таблица организации БД позволяет реализовать ее важ- нейшее преимущество перед другими моделями данных, а именно — возможность использования точных математичес- ких методов манипулирования данными, и прежде всего — аппарата реляционной алгебры и исчисления отношений [54]. К другим достоинствам реляционной модели можно отнести наглядность, простоту изменения данных и организации раз- граничения доступа к ним. Основным недостатком реляционной модели данных яв- ляется информационная избыточность, что ведет к перерас- ходу ресурсов вычислительных систем (отметим, что суще- ствует ряд приемов, позволяющих в значительной степени избавиться от этого недостатка — см. подразд. 2.2). Однако именно реляционная модель данных находит все более ши- рокое применение в практике автоматизации информацион- ного обеспечения профессиональной деятельности. Подавляющее большинство СУБД, ориентированных на персональные ЭВМ, являются системами, построенными на основе реляционной модели данных — реляционными СУБД. Бинарная модель данных Бинарная модель данных — это графовая модель, в ко- торой вершины являются представлениями простых одно- значных атрибутов, а дуги — представлениями бинарных связей между атрибутами (см. рис. 2.1.12). Рис. 2.1.12. Пример бинарного отношения Бинарная модель не получила особо широкого распрост- ранения, но в ряде случаев находит практическое примене- ние. Так, в области искусственного интеллекта уже давно ведутся исследования с целью представления информации в 224
виде бинарных отношений. Рассмотрим триаду (тройку) “объект—атрибут—значение” (более подробно об этом будет сказано в подразд. 4.2). Триада “Кузнецов—возраст—20” оз- начает, что возраст некоего Кузнецова равен 20 годам. Эта же информация может быть выражена, например, бинар- ным отношением ВОЗРАСТ. Понятие бинарного отношения положено в основу таких моделей данных, как, например, Data Semantics (автор Абриал) и DIAM II (автор Сенко). Бинарные модели данных обладают возможностью пред- ставления связки любой сложности (и это их несомненное преимущество), но вместе с тем их ориентация на пользова- теля недостаточна [53]. Семантическая сеть Семантические сети как модели данных были предложе- ны исследователями, работавшими над различными пробле- мами искусственного интеллекта (см. разд. 4). Так же, как в сетевой и бинарной моделях, базовые структуры семанти- ческой сети могут быть представлены графом, множество вершин и дуг которого образует сеть. Однако семантические сети предназначены для представления и систематизации знаний самого общего характера [53]. Таким образом, семантической сетью можно считать любую графовую модель (например — помеченный бинарный граф) если изначально четко определено, что обозначают вершины и дуги и как они используются. Семантические сети являются богатыми источниками идей моделирования данных, чрезвычайно полезных в плане ре- шения проблемы представления сложных ситуаций. Они мо- гут быть использованы независимо или совместно с идеями, положенными в основу других моделей данных. Их интерес- ной особенностью является то, что расстояние, измеренное на сети (семантическое расстояние или метрика), играет важ- ную роль, определяя близость взаимосвязанных понятий. При этом предусмотрена возможность в явной форме подчеркнуть, что семантическое расстояние велико. Как показано на рис. 2.1.13, СПЕЦИАЛЬНОСТЬ соотносится с личностью ПРЕ- 225
ПОДАВАТЕЛЬ, и в то же время ПРЕПОДАВАТЕЛЮ при- сущ РОСТ. Взаимосвязь личности со специальностью очевид- на, однако из этого не обязательно следует взаимосвязь СПЕ- ЦИАЛЬНОСТИ и РОСТА. Следует сказать, что моделям данных типа семантичес- кой сети при всем присущем им богатстве возможностей при моделировании сложных ситуаций присуща усложненность и некоторая неэкономичность в концептуальном плане [53]. ПРЕПОДАВАТЕЛЬ СПЕЦИАЛЬНОСТЬ нерелевантно ►РОСТ Рис. 2.1.13. Соотношение понятий в семантической сети 2.1.4. Реляционная модель данных Как было отмечено в п. 2.1.3, в основе реляционной моде- ли данных лежат их представления в виде таблиц, что в зна- чительной степени облегчает работу проектировщика БД и — в последующем — пользователя в силу привычности и распро- страненности такого варианта использования информации. Дан- ная модель была предложена Э. Ф. Коддом (Е. F. Codd) в начале 70-х гг. XX в., и вместе с иерархической и сетевой моделями составляет множество так называемых великих моделей. Можно сказать, что сегодня именно эта модель используется во всех наиболее распространенных СУБД. Определение любой модели данных требует описания трех элементов: ♦ типов (структур) данных', ♦ операций над данными; ♦ ограничений целостности. Сначала рассмотрим структуры данных и ограничения целостности, а затем более подробно остановимся на опера- циях реляционной алгебры. 226
Типы структур данных Рассмотрение этого вопроса требует введения определе- ний нескольких основных понятий. Множество возможных значений некоторой характе- ристики объекта называется доменом (domain): ^mJ- Например, в качестве домена можно рассматривать та- кие характеристики студента, как его фамилия, курс, рост и т. п. DKypc = {2, 3, 4, 5,}; ^фамилия = {Иванов, Петров, Сидоров,...}; = {160, 161, 162,..,190}. Очевидно, что можно сопоставить понятия “атрибут” инфологической и “домен” реляционной моделей данных. Воз- можные значения характеристик объектов могут принимать числовые или текстовые значения, а их множества могут быть как конечными, так и бесконечными. Отметим, что в случае конечности домена можно организовать проверку явных ог- раничений целостности: в нашем примере домен Dp^ опреде- ляет, что все студенты должны иметь рост от 160 до 190 см, а номер курса не может превышать 5. Вектор размерности к, включающий в себя по одному из возможных значений к доменов, называется кортежем (tuple). Для приведенного выше примера кортежами являются: (1, Иванов, 172); (3, Сидоров, 181); (5, Уткин, 184). Если в кортеж входят значения всех характеристик объек- та ПО (т. е. атрибутов сущности инфологической модели), ему можно сопоставить такую типовую структуру данных, как запись (объектная запись). 227
Декартовым произведением к доменов называется мно- жество всех возможных значений кортежей: D - DjX D2 х...х Dk. Пусть для того же примера определены три домена: D - {1, 4}; D2 = {Иванов, Петров}; D3 = {168, 181}. Тогда их декартовым произведением будет множество D, состоящее из восьми записей: D = D, х D2 х D3 = * (1, Иванов, 168) ' (1, Иванов, 181) (1, Петров, 168) (1, Петров, 181) (4, Иванов, 168) (4, Иванов, 181) (4, Петров, 168) (4, Петров, 181) t При увеличении размерности любого из доменов увели- чивается и размерность их декартова произведения. Так, если в первом домене определены три элемента Dj = {1, 4, 5}, декартово произведение имеет вид: D - Dj х D2 х D3 = (1, Иванов, 168) (1, Иванов, 181) (1, Петров, 168) (1, Петров, 181) (4, Иванов, 168) (4, Иванов, 181) (4, Петров, 168) (4, Петров, 181) (5, Иванов, 168) (5, Иванов, 181) (5, Петров, 168) (5, Петров, 181) 228
Иными словами, декартово произведение — множество всех возможных комбинаций элементов исходных доменов. Наконец, важнейшее определение: отношением (relation) R, определенным на множествах доменов Dlf D2,...,Dk, назы- вают подмножество их декартова произведения: R с Dj х D2 х...х Dk. Элементами отношения являются кортежи. Отношение может моделировать множество однотипных объектов (сущ- ностей), причем экземпляр сущности может интерпретиро- ваться как кортеж. С помощью отношения можно моделиро- вать и связи, в которых находятся объекты ПО (сущности в ее инфологической модели). При этом кортеж такого отноше- ния состоит из идентифицирующих атрибутов связываемых сущностей. Таким образом, понятие отношения позволяет модели- ровать данные и связи между ними. В силу этого можно оп- ределить реляционную базу данных (РБД) как совокупность экземпляров конечных отношений. Если учесть, что результат обработки любого запроса к РБД также можно интерпретировать как отношение (воз- можно, не содержащее ни одного кортежа), то возникает возможность построения информационной системы, основным инструментом которой будет алгебра отношений (реляцион- ная алгебра). Любой запрос в такой системе может быть пред- ставлен в виде формулы, состоящей из отношений, объеди- ненных операциями реляционной алгебры. Создав СУБД, обес- печивающую выполнение этих операций, можно разрабаты- вать информационные системы, в которых любой запрос по- требителя программируется формулой. Ограничения целостности Отношение может быть представлено таблицей, облада- ющей определенными свойствами (которые, по сути, и опре- деляют внутренние ограничения целостности данных) [54]: ♦ каждая строка таблицы — кортеж; 229
♦ порядок строк может быть любым; ♦ повторение строк не допускается; ♦ порядок столбцов в отношении фиксирован. Понятие “отношение” весьма схоже с понятием “файл данных”. Поэтому в дальнейшем будем использовать следую- щую терминологию: отношение — файл; кортеж — запись; домен — поле. Идентификация конкретной записи файла осу- ществляется по ключу (набору полей, по значению которого можно однозначно идентифицировать запись). В файле мож- но определить несколько ключей. Один из них, включающий минимально возможное для идентификации записи число по- лей, называется первичным ключом. Применительно к понятию “файл данных” внутренние ограничения целостности формулируются следующим обра- зом: ♦ количество полей и их порядок в файле должны быть фиксированными (т. е. записи файла должны иметь оди- наковые длину и формат); ♦ каждое поле должно моделировать элемент данных (неделимую единицу данных фиксированного форма- та, к которому СУБД может адресоваться непосред- ственно); ♦ в файле не должно быть повторяющихся записей. Системы управления базами данных, основанные на РБД, поддерживают и явные ограничения целостности. На практи- ке они определяются зависимостями между атрибутами (см. п. 2.1.2). 2.1.5. Операции реляционной алгебры Операции реляционной алгебры лежат в основе языка манипулирования данными СУБД, основанных на РБД. Эти операции выполняются над файлами и результатом их вы- полнения также является файл, который в общем случае может оказаться и пустым. 230
При описании операций реляционной алгебры будем ис- пользовать обозначения: ♦ ИФ (ИФ1; ИФ2) — имя исходного (первого исходного; второго исходного) файла; ♦ ФР — имя файла результата. Некоторые операции накладывают на исходные файлы ограничения, которые в определенном смысле можно рас- сматривать как внутренние ограничения целостности. Проектирование Формальная запись: ФР = proj [список имен полей] (ИФ). Операция не накладывает ограничений на исходный файл. Операция предусматривает следующие действия: ♦ из ИФ исключаются все поля, имена которых отсут- ствуют в списке имен полей; ♦ из полученного файла удаляются повторяющиеся за- писи. Пример. Пусть ИФ (КАДРЫ) содержит 4 поля: КАДРЫ НОМЕР ДОЛЖНОСТЬ ФАМИЛИЯ П/Я 01 инженер Петров 34170 02 инженер Горни 11280 03 старший инженер Сидоров 34170 04 начальник цеха Фомин 27220 05 начальник цеха Николаев 11280 и требуется выполнить операцию ФР = proj [П/Я] (КАДРЫ). Тогда после выполнения операции получим результат ФР П/Я 34170 11280 27220 231
Заметим, что с помощью приведенной операции можно выявить, в каких почтовых ящиках работают сотрудники, информация о которых содержится в данном файле. Селекция (выбор) Формальная запись: ФР = sei [условие] (ИФ). Эта операция также не накладывает ограничений на ИФ. В файл результата заносятся те записи из ИФ, которые удов- летворяют условию поиска. Условие представляет собой ло- гическое выражение, связывающее значения полей ИФ. Пример. Пусть для приведенного выше ИФ КАДРЫ тре- буется выявить сотрудников П/Я 34170, имеющих должность “ст. инженер”. Для отработки такого запроса достаточно вы- полнить операцию: ФР = sei [ДОЛЖНОСТЬ = “ст. инженер” И П/Я = “34170”] (КАДРЫ). ФР НОМЕР ДОЛЖНОСТЬ ФАМИЛИЯ П/Я 03 старший инженер Сидоров 34170 Отметим, что данная операция не изменяет структуру ИФ. Кроме того, при такой формальной записи операции пред- полагается, что СУБД поддерживает отработку сложных (со- ставных) запросов, в противном случае пришлось бы состав- ное условие поиска отрабатывать последовательно — снача- ла выявить сотрудников, имеющих должность “ст. инженер”, а затем — из них выделить тех, кто служит в П/Я 34170 (или наоборот}. Иногда такой (последовательный) порядок поиска имеет определенные преимущества — прежде всего в тех случаях, когда на сложный запрос дан отрицательный ответ и непонятно, что послужило причиной этого (в нашем при- мере — или нет сотрудников должности “ст. инженер”, или никто из них не “работает” в указанном П/Я, или такого предприятия вообще “нет” в БД). 232
Соединение Формальная запись: ФР = ИФ1 ► ◄ ИФ2. (список полей) В реляционной алгебре определено несколько операций соединения. Мы рассмотрим так называемое естественное соединение. Условием выполнения данной операции является нали- чие в соединяемых файлах одного или нескольких однотип- ных полей, по которым и осуществляется соединение (эти поля указываются в списке; если список пуст, соединение осуществляется по всем однотипным полям). В файл результата заносятся записи, являющиеся так называемыми конкатенациями (англ, concatenate — сцеплять, связывать) записей исходных файлов. Иными словами, в ФР попадают записи ИФ1 и ИФ2 с совпадающими значениями полей, по которым осуществляется соединение (“сцепка”). Пример 1. Пусть помимо файла КАДРЫ имеется файл ЦЕХ, в котором указаны порядковый НОМЕР сотрудника (как и в первом файле) и НОМЕР_ЦЕХА — номер цеха, в котором данный сотрудник работает. ЦЕХ НОМЕР НОМЕР_ЦЕХА 01 Ш 02 Ц2 03 Ц1 04 Ц2 05 Ц1 Тогда после выполнения операции ФР = КАДРЫ ► ◄ ЦЕХ получим 233
ФР НОМЕР ДОЛЖНОСТЬ ФАМИЛИЯ П/Я НОМЕР ЦЕХА 01 инженер Петров 34170 Ш 02 инженер Горин 11280 Ц2 03 старший инженер Сидоров 34170 Ц1 04 начальник цеха Фомин 27220 Ц2 05 начальник цеха Николаев 11280 ш Следует обратить внимание, что в формате команды не указаны поля соединения. Следовательно, оно осуществляет- ся по единственному однотипному полю (НОМЕР). Пример 2. Пусть требуется выяснить, в каком цехе п/я 34170 работает ст. инженер Сидоров. Для этого требуется выполнить операции: ФР1 = sei [ДОЛЖНОСТЬ = “ст. инженер” И П/Я = “34170” И ФАМИЛИЯ = “Сидоров”] (КАДРЫ); ФР2 = ФР1 ► ◄ ЦЕХ; ФР = proj [ДОЛЖНОСТЬ, ФАМИЛИЯ, П/Я, НОМЕР_ ЦЕХА]ФР2 (ДОЛЖНОСТЬ). В результате получим: ФР ДОЛЖНОСТЬ ФАМИЛИЯ П/Я НОМЕР ЦЕХА старший инженер Сидоров 34170 Ш Объединение Формальная запись: ФР = ИФ1УИФ2. Условием выполнения операции является однотипность (одинаковая структура) исходных файлов. В файл результата заносятся неповторяющиеся записи исходных файлов. Пример. Пусть в БД имеются два файла: УЧ_Д_КАФЕД- РЫ_1 и УЧ_Д_КАФЕДРЫ_2, в которых содержатся данные о читаемых кафедрами № 1 и № 2 учебных дисциплинах: 234
УЧ _Д_КАФЕДРЫ1 НОМЕР ДИСЦИПЛИНЫ УЧЕБНАЯ ГРУППА 2011-12 99/ЭВ. 3-02 5300-43 96/ЭИ. 6-01 5140-11 98/ЭВ. 4-03 УЧ_Д_КАФЕДРЫ2 НОМЕР ДИСЦИПЛИНЫ УЧЕБНАЯ ГРУППА 5110-15 97/ЭИ. 5-02 5413-23 98/ЭВ. 4-01 2010-19 01/ЭИ. 1-03 5300-43 96/ЭИ. 6-01 Тогда после выполнения операции объединения ФР = УЧ_Д_КАФЕДРЫ1 Y УЧ_Д_КАФЕДРЫ2 получим данные об учебных дисциплинах, читаемых обеими кафедрами: ФР НОМЕР ДИСЦИПЛИНЫ УЧЕБНАЯ ГРУППА 5110-15 97/ЭИ. 5-02 5413-23 98/ЭВ. 4-01 2010-19 01/ЭИ. 1-03 5300-43 96/ЭИ. 6-01 2011-12 99/ЭВ. 3-02 5140-11 98/ЭВ. 4-03 Напомним, что последовательность записей в файлах БД роли не играет. Разность (вычитание) Формальная запись: ФР = ИФ1—ИФ2. Условием выполнения операции является однотипность (одинаковая структура) исходных файлов. В файл результата заносятся записи первого исходного файла, которых нет во втором. 235
Пример. В условиях предыдущего примера выполним операцию ФР = УЧ_Д_КАФЕДРЫ1 — УЧ_Д_КАФЕДРЫ2. Получим данные об учебных дисциплинах, читаемых кафедрой № 1 без участия кафедры № 2. ФР НОМЕР ДИСЦИПЛИНЫ УЧЕБНАЯ ГРУППА 2011-12 99/ЭВ. 3-02 5140-11 98/ЭВ. 4-03 Пересечение Формальная запись: ФР = ИФ1-ИФ2. Условием выполнения операции является однотипность (одинаковая структура) исходных файлов. В результирующий файл заносятся записи, присутству- ющие в обоих исходных файлах. Пример. Для уже известных файлов УЧ_Д_КАФЕДРЫ1 и УЧ_Д_КАФЕДРЫ2 выполним операцию пересечения ФР = УЧ_Д_КАФЕДРЫ1 — УЧ_Л_КАФЕДРЫ2. Получим данные о совместно читаемых обеими кафед- рами дисциплинах: ФР НОМЕР ДИСЦИПЛИНЫ УЧЕБНАЯ ГРУППА 5300-43 533 Деление Формальная запись: ФР = ИФ1+ИФ2. Для выполнимости операции деления необходимо, чтобы в первом исходном файле было больше полей, чем во втором, и для каждого поля второго исходного файла существовало однотипное ему поле в первом исходном файле. 236
В файл результата, состоящий из полей первого исход- ного файла, не входящих во второй, заносятся те записи, которые согласуются со всеми записями второго исходного файла. Пример. Пусть в БД хранятся два файла, содержащие данные об учебной литературе, выпущенной некоторой ка- федрой. Авторы АВТОР НАЗВАНИЕ ГОД ИЗДАНИЯ Иванов Теория вероятностей 1997 Петров Методы оптимизации 1998 Петров Теория вероятностей 1997 Иванов Методы оптимизации 1998 Сидоров Методы оптимизации 1998 Петров Концепции естествознания 1996 Сидоров Исследование операций 1999 Издания НАЗВАНИЕ ГОД ИЗДАНИЯ Теория вероятностей 1997 Методы оптимизации 1998 После выполнения операции деления первого файла на второй (а она возможна, так как в файле АВТОРЫ имеются все поля файла ИЗДАНИЯ) получим данные об авторах (со- авторах), которые приняли участие в написании всех книг, информация о которых хранится во втором файле: ФР АВТОР ___________Иванов_________ Петров Умножение Формальная запись: ФР = ИФ1ХИФ2. Условием выполнения операции умножения является от- сутствие в исходных файлах полей с одинаковыми именами. 237
В файл результата, содержащий поля обоих исходных файлов, заносятся все возможные комбинации записей ИФ1 и ИФ2. Пример. Пусть в БД хранятся данные об инженерах и старших инженерах (в файлах СТАРШИЕИНЖЕНЕРЫ и ИНЖЕНЕРЫ соответственно). СТАРШИЕ_ИНЖЕНЕРЫ ДОЛЖНОСТЬ ФАМИЛИЯ старший инженер Ц1 Иванов старший инженер Ц2 Петров Инженеры ДОЛЖНОСТЬ ФАМИЛИЯ инженер Щ Сидоров инженер Ц1 Леонидов инженер ЦЗ Дмитриев Требуется получить данные о возможных вариантах ком- плектования дежурных смен управления предприятием в со- ставе одного старшего инженера и одного инженера. Поскольку имена полей в ИФ1 и ИФ2 совпадают, необхо- димо в одном из них (например, в ИФ2) поля переименовать (например, вместо ДОЛЖНОСТЬ — ДОЛЖНОСТЬ!; вместо ФАМИЛИЯ — ФАМИЛИЯ!). Тогда после выполнения опера- ции ФР = СТАРШИЕ ИНЖЕНЕРЫ х ИНЖЕНЕРЫ получим: ФР ДОЛЖНОСТЬ ФАМИЛИЯ ДОЛЖНОСТЬ! ФАМИЛИЯ! Старший инженер Ц1 Иванов инженер Ц1 Сидоров Старший инженер Ц1 Иванов инженер Ц1 Леонидов Старший инженер Ц1 Иванов инженер ЦЗ Дмитриев Старший инженер Ц2 Петров инженер Ц1 Сидоров Старший инженер Ц2 Петров инженер Ц1 Леонидов Старший инженер Ц2 Петров инженер ЦЗ Дмитриев С помощью приведенных выше восьми операций реляци- онной алгебры можно найти ответ на любой запрос к БД, 238
если, конечно, интересующие пользователя данные в ней хранятся. Типовые запросы могут быть запрограммированы заранее и отрабатываться как процедуры (транзакции). Обра- ботка уникальных (нетиповых) запросов должна предусмат- ривать оперативную разработку последовательности необ- ходимых операций и последующую ее реализацию. 2.2. Нормализация файлов базы данных Выше файлы рассматривались как своеобразные храни- лища данных и связей между ними, причем было показано, что при соблюдении определенных правил эти файлы можно считать отношениями и применять к ним операции реляцион- ной алгебры. Открытым пока остался вопрос о том, какие файлы хранить в БД и какие в них должны быть поля, чтобы иметь модель предметной области с определенными положи- тельными свойствами. 2.2.1. Полная декомпозиция файла Рассмотрим простой пример. Пусть имеется исходный файл, в котором хранятся данные о сотрудниках, осуществ- лявших управление непрерывным производственным циклом предприятия в качестве оперативного дежурного (ОД) или его помощника (ПОД) и имеющих номера рабочих телефо- нов, указанные в поле ТЕЛЕФОН: ИФ ДЕЖУРСТВО СОТРУДНИК ТЕЛЕФОН под Иванов 3-12 од Сидоров 3-12 од Фомин 8-44 под Семин 8-44 Найдем две проекции ИФ: ПФ1 = pro) (ДЕЖУРСТВО, ОФИЦЕР] (ИФ); ПФ2 = proj [ОФИЦЕР, ТЕЛЕФОН] (ИФ). 239
ПФ1 ДЕЖУРСТВО СОТРУДНИК ПОД Иванов од Сидоров од Фомин под Семин ПФ2 СОТРУДНИК ТЕЛЕФОН Иванов 3-12 Сидоров 3-12 Фомин 8-44 Семин 8-44 Нетрудно убедиться, что соединение этих двух проек- ций образует исходный файл: ПФ1 ► ◄ ПФ2 = ИФ. Полной декомпозицией файла называется совокупность произвольного числа его проекций, соединение которых иден- тично исходному файлу. Говоря о полной декомпозиции файла, следует иметь в виду два обстоятельства: ♦ у одного и того же файла может быть несколько пол- ных декомпозиций; ♦ не всякая совокупность проекций файла образует его полную декомпозицию. Для последнего примера найдем другую проекцию ИФ: ПФЗ = proj [ДЕЖУРСТВО, ТЕЛЕФОН] (ИФ). ПФЗ ДЕЖУРСТВО ТЕЛЕФОН ПОД 3-12 ОД 3-12 од 8-44 ПОД 8-44 В результате соединения ПФ2 и ПФЗ получим файл ре- зультата ПФ2 ► ◄ ПФЗ = ФР * ИФ: 240
ФР ДЕЖУРСТВО ТЕЛЕФОН СОТРУДНИК под 3-12 Иванов ПОД 3-12 Сидоров ОД 3-12 Иванов од 3-12 Сидоров од 8-44 Фомин ОД 8-44 Семин ПОД 8-44 Фомин под 8-44 Семин В ФР курсивом выделены записи, которых не было в исходном файле. Методы анализа, позволяющие определить, образует ли данная совокупность проекций файла его полную декомпози- цию, будут рассмотрены в п. 2.2.4. Возможность нахождения полной декомпозиции файла ставит вопросы о том, в каком виде хранить данные в БД? Дает ли декомпозиция файла какие-либо преимущества? В каких условиях эти преимущества проявляются и т. п. 2.2.2. Проблема дублирования информации В некоторых случаях замена исходного файла его пол- ной декомпозицией позволяет избежать дублирования ин- формации. Рассмотрим пример. Пусть в исходном файле (как и в примере в п. 2.2.1) хранятся данные о сотрудниках, дежу- ривших в составе оперативной группы управления предпри- ятием (ДАТА — дата дежурства; ТЕЛЕФОН — рабочий теле- фон сотрудника). ИФ ДАТА СОТРУДНИК ТЕЛЕФОН 11.01 Иванов 3-12 15.01 Сидоров 4-21 24.01 Сидоров 4-21 30.01 Сидоров 4-21 1.02 Иванов 3-12 241
Рассмотрим две проекции файла: ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ); ПФ2 = proj [СОТРУДНИК, ТЕЛЕФОН] (ИФ). ПФ1 Дата СОТРУДНИК 11.01 Иванов 15.01 Сидоров 24.01 Сидоров 30.01 Сидоров 1.02 Иванов ПФ2 СОТРУДНИК ТЕЛЕФОН Иванов 3-12 Сидоров 4-21 Данные проекции образуют полную декомпозицию исход- ного файла. В ПФ2 номер рабочего телефона каждого со- трудника упоминается однократно, тогда как в ИФ — столько раз, сколько этот сотрудник заступал на дежурство. Очевид- но, что для нашего примера разбиение ИФ на проекции по- зволяет избежать дублирования информации. Устранение дублирования информации важно по двум причинам: ♦ устранив дублирование, можно добиться существен- ной экономии памяти', ♦ если некоторое значение поля повторяется несколько раз, то при корректировке данных необходимо ме- нять содержимое всех этих полей, в противном слу- чае нарушится целостность данных. Для того чтобы найти критерий, позволяющий объективно судить о целесообразности использования полной декомпози- ции файла с точки зрения исключения дублирования инфор- мации, воспользуемся понятием первичного ключа. Напомним, что первичным ключом называют минималь- ный набор полей файла, по значениям которых можно одно- 242
значно идентифицировать запись. Если значение первично- го ключа Не определено, то запись не может быть помещена в файл БД. Можно показать, что для нашего примера проекции ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ); ПФ2 = proj [ДАТА, ТЕЛЕФОН] (ИФ) образуют полную декомпозицию ИФ, однако они не ис- ключают дублирования информации. Причина этого заключается в том, что обе приведенные проекции содержат первичный ключ исходного файла (тако- вым в рассмотренном примере является поле ДАТА, если, конечно, сотрудник не может одновременно находиться в двух и более оперативных группах). Можно доказать, что дублирование информации неиз- бежно, если проекции, порождающие полную декомпозицию, содержат общий первичный ключ исходного файла. Рассмотрим исходный файл: ИФ FX FY FZ X У Z Xх 1 Z две его проекции: ПФ1 FX FY X У х' : I ПФ2 FY FZ 1 Z Для того чтобы вторая запись ИФ отличалась от первой (в противном случае имели бы в файле БД две одинаковые 243
записи, что недопустимо), она формально должна быть пред- ставлена одним из семи вариантов: (х’, у, z); (х, у’, z); (х, у, z’); (х’, у’, z); (х, y’,z’); (х’, у’, z’); (х’, у, z’). Пусть FY — первичный ключ. Для того, чтобы дублиро- вания информации не было, вторая запись ИФ должна быть или (х’, у, z), или (х, у, z’), но это противоречит тому, что FY — первичный ключ. Следовательно, для того чтобы дуб- лирования информации не было, необходимо исключить на- личие первичного ключа исходного файла в проекциях, об- разующих его полную декомпозицию. Другими словами, если существует такая полная ком- позиция файла, которая образована проекциями, не имею- щими первичного ключа исходного файла, то замена исход- ного файла этой декомпозицией исключает дублирование ин- формации. Если же полная декомпозиция файла содержит проекции, имеющие общий первичный ключ исходного фай- ла, то замена его полной декомпозицией не исключает дуб- лирования информации. 2.2.3. Проблема присоединенных записей Рассмотрим уже использованный п. 2.2.2 пример. Пусть в исходном файле хранятся данные о сотрудниках, дежурив- ших в составе оперативной группы предприятия (ДАТА — дата дежурства; ТЕЛЕФОН — рабочий телефон офицера). ИФ ДАТА СОТРУДНИК ТЕЛЕФОН 11.01 Иванов 3-12 15.01 Сидоров 4-21 24.01 Сидоров 4-21 30.01 Сидоров 4-21 1.02 Иванов 3-12 Рассмотрим две проекции файла: ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ); ПФ2 = proj [СОТРУДНИК, ТЕЛЕФОН] (ИФ). 244
ПФ1 дата СОТРУДНИК 11.01 Иванов 15.01 Сидоров 24.01 Сидоров 30.01 Сидоров 1.02 Иванов ПФ2 СОТРУДНИК ТЕЛЕФОН Иванов 3-12 Сидоров 4-21 В ИФ поле ДАТА является ключом и не может быть пу- стым. Как поступить, если нужно запомнить фамилию и но- мер рабочего телефона нового сотрудника, который еще не дежурил (например, Смирнов с номером телефона 7-35)? Записать эти данные в ИФ. нельзя (первичный ключ не мо- жет быть пустым), но можно поместить эти сведения в про- екцию ПФ2. При этом ПФ2 формально перестает быть проек- цией ИФ, хотя соединение ПФ1 и ПФ2 дает исходный файл (без сведений о Смирнове). Записи, вносимые в отдельные проекции исходного фай- ла, называются присоединенными. Представление файла в виде его полной декомпозиции может позволить решить про- блему присоединенных записей, но важно помнить, что со- единение проекций ИФ может привести к их потере. Целесообразность представления ИФ в виде полной де- композиции с точки зрения решения проблемы присоединен- ных записей, как и проблемы дублирования информации, полностью определяется наличием или отсутствием в про- екциях ИФ общего первичного ключа. Пусть в ИФ БД хранятся данные о сотрудниках, испол- няющих обязанности в дежурном расчете (НОМЕР_Р — но- мер в составе дежурного расчета; ТЕЛЕФОН — номер ра- бочего телефона). 245
ИФ НОМЕР СОТРУДНИК ТЕЛЕФОН 1 Иванов 3-12 2 Сидоров 4-21 3 Фомин 8-61 Если считать, что один и тот же сотрудник не может исполнять обязанности нескольких номеров дежурного рас- чета, то в качестве первичного ключа можно использовать НОМЕР Р. Полную декомпозицию исходного файла состав- ляют проекции: ПФ1 НОМЕР_Р СОТРУДНИК 1 Иванов 2 Сидоров 3 Фомин ПФ2 НОМЕР_Р ТЕЛЕФОН 1 3-12 2 4-20 3 8-61 В качестве присоединенных записей можно рассматри- вать либо добавление нового номера дежурного расчета и фамилии сотрудника, либо нового номера расчета и телефо- на без указания фамилии сотрудника, однако эту информа- цию можно внести и в ИФ путем формирования записей типа НОМЕР_Р СОТРУДНИК ТЕЛЕФОН 4 Семин или НОМЕР_Р СОТРУДНИК ТЕЛЕФОН 4 Семин 9-18 246
Таким образом, представление ИФ в виде проекций, содержащих общий первичный ключ исходного файла, не дает преимуществ с точки зрения решения проблемы присо- единенных записей. Обобщая сказанное, можно сформулировать общее тре- бование к файлу, представление которого в виде полной де- композиции не имеет смысла. Говорят, что файл находится в пятой нормальной форме (5 НФ), если у него или нет ни одной полной декомпозиции, или нет ни одной полной декомпозиции, в которую входили бы проекции, не имеющие общего первичного ключа исходно- го файла. Если файл не находится в 5 НФ, имеется возможность избежать дублирования информации и потерю присоединен- ных записей, переходя от исходного файла к такой его пол- ной декомпозиции, которая образована проекциями, не со- держащими первичный ключ. Если полученные таким обра- зом файлы проекций не находятся в 5 НФ, то каждую из них можно заменить полной декомпозицией и т. д. Процесс последовательного перехода к полным декомпо- зициям файлов БД называется нормализацией файлов БД, главная цель которой — исключение дублирования информа- ции и потери присоединенных записей. 2.2.4. Функциональная зависимость полей файла При обсуждении в предыдущих пунктах полной деком- позиции файла остался открытым вопрос о том, при каких же условиях некоторые проекции исходного файла образу- ют его полную декомпозицию. Естественно, существует воз- можность взять конкретный файл, заполненный данными, и непосредственно проверить, образуют ли те или иные его проекции при соединении исходный файл. Однако такой путь не является конструктивным, так как, во-первых, может оказаться достаточно много вариантов разбиения исходного 247
файла, и, во-вторых, что более важно, нет гарантии, что при добавлении записей в исходный файл его проекции будут по-прежнему составлять полную декомпозицию. Очевидно, необходимо сформулировать критерий, позво- ляющий даже для незаполненного файла, исходя из возмож- ных значений его полей, судить о возможности получения полной декомпозиции файла из тех или иных его проекций. Такой критерий строится на понятии функциональной за- висимости полей файла [34]. Пусть XuY — некоторые непересекающиеся совокупно- сти полей файла. Говорят, что Y находится в функциональ- ной зависимости от X тогда и только тогда, когда с каж- дым значением X связано не более одного значения Y. Любые две записи файла, содержащие одинаковые зна- чения X, должны содержать одинаковые значения Y, при- чем это ограничение действует не только на текущие значе- ния записей файла, но и на все возможные значения, кото- рые могут появиться в файле. Вместе с тем одинаковым зна- чениям Y могут соответствовать различные значения X. Рассмотрим уже знакомый пример. Пусть в ИФ имеются поля: | ДЕЖУРСТВО | ДОЛЖНОСТЬ | ФАМИЛИЯ | ТЕЛЕФОН | Поле ТЕЛЕФОН находится в функциональной зависимо- сти от полей ДОЛЖНОСТЬ и ФАМИЛИЯ (считаем, что в данном файле не будет храниться информация о сотрудни- ках-однофамильцах, имеющих одинаковые должности). По- нятно, что один и тот же номер рабочего телефона могут иметь несколько сотрудников, т. е. по значению поля ТЕЛЕ- ФОН нельзя однозначно определить должность и фамилию сотрудника. Пусть X состоит из нескольких полей. Говорят, что Y находится в полной функциональной зависимости от X, если Y функционально зависит от X и функционально не зависит от любого подмножества X' не совпадающего с X (Х'сХ) [54]. 248
В условиях предыдущего примера поле ТЕЛЕФОН на- ходится в полной функциональной зависимости от совокупно- сти полей ДОЛЖНОСТЬ и ФАМИЛИЯ, поскольку оно не зависит функционально ни от поля ДОЛЖНОСТЬ, ни от поля ФАМИЛИЯ по отдельности. Теперь можно сформулировать критерий (правило), по которому следует исходный файл разбивать на проекции для получения его полной декомпозиции (это утверждение на- зывают теоремой Хита). Пусть имеются три непересекающиеся совокупности по- лей исходного файла: Н, J, К. Если К фунционально зависит от J, то проекции proj [Н, J] (ИФ) и proj [J, К] (ИФ) образу- ют полную декомпозицию исходного файла. Докажем это утверждение. Введем вспомогательный файл ИФ1 = proj [Н, J] (ИФ) ► ◄ proj [J, К] (ИФ). Покажем, что каждая запись ИФ присутствует в ИФ1, и наоборот. А. Возьмем произвольную запись исходного файла: (h, j, к). Очевидно, что ее часть (h, j) принадлежит первой проек- ции, (j, к) — второй проекции ИФ. По определению операции соединения можно утверждать, что запись (h, j, к) должна присутствовать в файле ИФ1. Б. Возьмем произвольную запись вспомогательного фай- ла: (h', j', к'). Согласно определению файла ИФ1 можно за- писать: proj [Н, J] (ИФ1) = proj [Н, J] (ИФ). Следовательно, в файле ИФ должна находиться хотя бы одна запись типа (h', j', к'), где к' пока не определено. По аналогии можно запи- сать: proj [J, К] (ИФ1) = proj [J, К] (ИФ). Следовательно, в файле ИФ должна находиться хотя бы одна запись типа (h", j', к'), где h" пока не определено. Таким образом, в исходном файле ИФ должны содер- жаться записи (h', j', к") и (h", j', k'). Но поскольку К функ- ционально зависит от J, можно заключить, что к" = к' и, следовательно, в ИФ имеется запись (h', j', к'), которую мы определили как произвольную запись ИФ1. Доказательство закончено. 249
Вернемся к примеру. Пусть в ИФ имеются поля: | ДЕЖУРСТВО | ДОЛЖНОСТЬ | ФАМИЛИЯ I ТЕЛЕФОН | Так как поле ТЕЛЕФОН находится в функциональной зависимости от полей ДОЛЖНОСТЬ и ФАМИЛИЯ, можно заключить, что полную декомпозицию ИФ следует искать в виде проекций: ПФ1 = proj [ДЕЖУРСТВО, ДОЛЖНОСТЬ, ФАМИЛИЯ] (ИФ); ПФ2 = proj [ДОЛЖНОСТЬ, ФАМИЛИЯ, ТЕЛЕФОН] (ИФ). Для этого примера можно обозначить: Н = [ДЕЖУРСТВО]; J = [ДОЛЖНОСТЬ, ФАМИЛИЯ]; К = [ТЕЛЕФОН]. Таким образом, с помощью понятия функциональной за- висимости полей файла можно получать его полные деком- позиции без анализа хранящихся в файле данных еще на этапе проектирования БД, что весьма важно на практике. 2.2.5. Нормальные формы файла Как было показано в п. 2.2.3 и 2.2.4, при некоторых усло- виях замена файла его полной декомпозицией позволяет ис- ключить дублирование информации и решить проблему при- соединенных записей. Таким условием является отсутствие в проекциях, образующих полную декомпозицию файла, об- щего первичного ключа исходного файла. Теорема Хита со- здает основу для построения различных полных декомпози- ций и поэтому может служить основным инструментом в про- цессе нормализации файлов БД. При проведении нормализации на каждом шаге проверя- ется принадлежность файла некоторой нормальной форме. Если он принадлежит этой нормальной форме,' проверяется, нахо- дится ли он в следующей, и т. д. до 5 НФ. Принадлежность файла некоторой форме задает необходимые, но недоста- точные условия для нахождения в следующей по старшин- ству форме. 250
Еще раз подчеркнем основное достоинство механизма нормализации файлов с помощью исследования функциональ- ной зависимости полей файла: возможность проведения этой операции на этапе проектирования БД. Перечислим основные нормальные формы файлов в со- ответствии с [54]. Первая нормальная форма (1 НФ) Файл находится в 1 НФ, если каждое его поле является атомарным (т. е. не содержит более одного значения), и ни одно из ключевых полей не является пустым. По существу принадлежность файла 1 НФ означает, что он соответствует понятию отношения и его ключевые поля заполнены. Пример. Принципиально существует возможность хра- нить информацию о профессорско-преподавательском соста- ве кафедры в следующем виде: ДОЛЖНОСТЬ ФАМИЛИЯ Заведующий Иванов Профессор Петров, Сидоров Доцеит Фомин Преподаватель Семин, Савин, Федоров Однако такой файл не находится в 1 НФ (так как поле ФАМИЛИЯ не является атомарным). Вторая нормальная форма (2 НФ) Файл находится во 2 НФ, если он находится в 1 НФ и все его поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Третья нормальная форма (3 НФ) Файл находится в 3 НФ, если он находится во 2 НФ и ни одно из его неключевых полей не зависит функционально от любого другого неключевого поля. Нормальная форма Бойса—Кодда (усиленная 3 НФ) Файл находится в НФ Бойса—Кодда, если любая функ- циональная зависимость между его полями сводится к пол- ной функциональной зависимости от первичного ключа. 251
Можно показать [54], что рассмотренные НФ подчиня- ются правилу вложенности по возрастанию номеров, т. е. если файл находится в 4 НФ, он находится и в 3 НФ, 2 НФ, 1 НФ, и наоборот (см. рис. 2.2.1). Помимо описанных выше нормальных форм использует- ся четвертая НФ, основанная на понятии обобщенной фун- кциональной зависимости [46]. На практике, приведя все фай- лы к нормальной форме Бойса—Кодда, можно с большой до- лей уверенности утверждать, что они находятся и в 5 НФ, т. е. что нормализация файлов БД завершена. Файл в 1 НФ Файл во 2 НФ Файл в 3 НФ Файл в усиленной 3 НФ Файл в 5 НФ Рис. 2.2.1. Соотношение нормальных форм файлов Отметим, что существующие СУБД (например, широко распространенная СУБД Access из пакета MS Office) содер- жат средства для автоматического выполнения операций нор- мализации (подобные мастеру по анализу таблиц), хотя ка- чество этого анализа зачастую требует последующего вме- шательства разработчика БД [16, 59]. Необходимость нормализации файлов БД (кроме реше- ния уже рассмотренных проблем исключения дублирования и потери присоединенных записей) определяется еще по край- ней мере двумя обстоятельствами [43]: во-первых, разум- ным желанием группировать данные по их содержимому, 252
что позволяет упростить многие процедуры в БД — от орга- низации разграничения доступа до повышения оперативнос- ти поиска данных; во-вторых, стремлением разработать БД в виде множества унифицированных блоков, что может об- легчить модернизацию отдельных частей базы, а также ис- пользовать таблицы одной БД в других. Важным направлением совершенствования СУБД явля- ется их интеллектуализация (см., например, 27), что под- робнее будет рассмотрено в разд. 4 учебника.
3. ТЕХНОЛОГИЯ МОДЕЛИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ 3.1. Методы моделирования систем Понятие модели является ключевым в общей теории си- стем. Моделирование как мощный — а часто и единствен- ный — метод исследования подразумевает замещение реаль- ного объекта другим — материальным или идеальным. Важнейшими требованиями к любой модели являются ее адекватность изучаемому объекту в рамках конкретной задачи и реализуемость имеющимися средствами. В теории эффективности и информатике моделью объек- та (системы, операции) называется материальная или иде- альная (мысленно представимая) система, создаваемая и/или используемая при решении конкретной задачи с целью полу- чения новых знаний об объекте-оригинале, адекватная ему с точки зрения изучаемых свойств и более простая, чем ори- гинал, в остальных аспектах [5, 6]. Классификация основных методов моделирования (и со- ответствующих им моделей) представлена на рис. 3.1.1. При исследовании экономических информационных сис- тем (ЭИС) находят применение все методы моделирования, однако в этом разделе основное внимание будет уделено семиотическим (знаковым) методам. Напомним, что семиотикой (от греч. semeion — знак, признак) называют науку об общих свойствах знаковых сис- тем, т. е. систем конкретных или абстрактных объектов (зна- ков), с каждым из которых сопоставлено некоторое значе- ние [35]. Примерами таких систем являются любые языки 254
Рис. 3.1.1. Классификация методов моделирования (естественные или искусственные, например, языки описа- ния данных или моделирования), системы сигнализации в обществе и животном мире и т. п. Семиотика включает три раздела: ♦ синтактика; ♦ семантика; ♦ прагматика. Синтактика исследует синтаксис знаковых систем бе- зотносительно к каким-либо интерпретациям и проблемам, связанным с восприятием знаковых систем как средств обще- ния и сообщения. Семантика изучает интерпретацию высказываний зна- ковой системы и с точки зрения моделирования объектов за- нимает в семиотике главное место. Прагматика исследует отношение использующего зна- ковую систему к самой знаковой системе, в частности — восприятие осмысленных выражений знаковой системы. 255
Из множества семиотических моделей в силу наибольше- го распространения, особенно в условиях информатизации современного общества и внедрения формальных методов во все сферы человеческой деятельности, выделим математи- ческие, которые отображают реальные системы с помощью математических символов. При этом, учитывая то обстоя- тельство, что мы рассматриваем методы моделирования при- менительно к исследованию систем в различных операциях, будем использовать общеизвестную методологию системного анализа, теории эффективности и принятия решений. 3.1.1. Математическая модель системы Задача построения математической модели ЭИС может быть поставлена следующим образом [5, 53]: для конкретной цели моделируемой операции с учетом имеющихся ресурсов построить операторы моделирования исхода операции и оце- нивания показателя ее эффективности. Формальная запись этой задачи имеет вид: <А0, 6 Н, Т >, где обозначения соответствуют приведенному выше перечис- лению. Перед рассмотрением каждого из названных операторов приведем два важных определения. Оператором в математике называют закон (правило), согласно которому каждому элементу х множества X ста- вится в соответствие определенный элемент у множества Y. При этом множества X и Y могут иметь самую различную природу (если они представляют, например, множества дей- ствительных или комплексных чисел, понятие оператор со- впадает с понятием функции). Множество Z упорядоченных пар (х, у), где х е X, у е Y, называется прямым произведением множеств X и Y и обо- значается ХхУ.Аналогично, множество Z упорядоченных ко- 256
нечных последовательностей (xJt х2,..., хп), где хк е Хк, назы- вается прямым произведением множеств Xt, X2,...,XN и обозна- чается Z = X1xX2x...xXN [5, 12]. Оператором моделирования исхода операции называется оператор Н, устанавливающий соответствие между множе- ством Л учитываемых в модели факторов, множеством U возможных стратегий управления системой (операцией) и множеством Y значений выходных характеристик модели H:AxU >Y, где 0М, Rs — ресурсы на этапе моделирования исходов опе- рации и учитываемые свойства моделируемой системы соот- ветственно. Оператором оценивания показателя эффективности си- стемы (операции) называется оператор Т, ставящий в соот- ветствие множеству Y значений выходных характеристик модели множество W значений показателя эффективности системы хр. у Ao-a3.Rs где 0Э — ресурсы исследователя на этапе оценивания эф- фективности системы. Особо отметим, что построение приведенных операто- ров всегда осуществляется с учетом главного системного прин- ципа — принципа цели. Кроме того, важным является влия- ние объема имеющихся в распоряжении исследователя ре- сурсов на вид оператора моделирования исхода Н и. состав множества U стратегий управления системой (операцией). Чем больше выделенные ресурсы, тем детальнее (подроб- нее) может быть модель и тем большее число стратегий уп- равления может быть рассмотрено (из теории принятия ре- шений известно, что первоначально множество возможных альтернатив должно включать как можно больше стратегий, иначе можно упустить наилучшую). В самом общем виде математической моделью систе- мы (операции) называется множество М = < U, Л, Н, Y, Т, W >, 257
элементами которого являются рассмотренные выше множе- ства и операторы. Способы задания оператора Т и подходы к выбору пока- зателя эффективности W рассматриваются в теории эффек- тивности; методы формирования множества возможных аль- тернатив — в теории принятия решений. Для двух классов задач показатель эффективности в яв- ном виде не вычисляется [27]: ♦ для задач так называемой прямой оценки, в которых в качестве показателей эффективности используются зна- чения одной или нескольких выходных характеристик модели; ♦ для демонстрационных задач, в ходе решения кото- рых для изучения поведения системы используются лишь значения ее выходных характеристик и внутрен- них переменных. В таких случаях используют термин "математическое описание системы”, представляемое множеством М' = < U, Л, Н, Y >. 3.1.2. Классификация математических моделей В качестве основного классификационного признака для математических моделей целесообразно использовать свой- ства операторов моделирования исхода операции и оценива- ния показателя ее эффективности [12, 35]. Оператор моделирования исхода Н может быть функци- ональным (заданным системой аналитических функций) или алгоритмическим (содержать математические, логические и логико-лингвистические операции, не приводимые к после- довательности аналитических функций). Кроме того, он мо- жет быть детерминированным (когда каждому элементу мно- жества UxA соответствует детерминированное подмножество значений выходных характеристик модели YcY) или стоха- стическим (когда каждому значению множества UxA соответ- ствует случайное подмножество YcY). 258
Оператор оценивания показателя эффективности Т мо- жет задавать либо точечно-точечное преобразование (когда каждой точке множества выходных характеристик Y ста- вится в соответствие единственное значение показателя эффективности W), либо множественно-точечное преобра- зование (когда показатель эффективности задается на всем множестве полученных в результате моделирования значе- ний выходных характеристик модели). В зависимости от свойств названных операторов все мате- матические модели подразделяются на три основных класса: ♦ аналитические; ♦ статистические; ♦ имитационные. Для аналитических моделей характерна детерминиро- ванная функциональная связь между элементами множеств U, Л, Y, а значение показателя эффективности W определя- ется с помощью точечно-точечного отображения. Аналити- ческие модели имеют весьма широкое распространение. Они хорошо описывают качественный характер (основные тен- денции) поведения исследуемых систем. В силу простоты их реализации на ЭВМ и высокой оперативности получения ре- зультатов такие модели часто применяются при решении задач синтеза систем, а также при оптимизации вариантов применения в различных операциях. К статистическим относят математические модели си- стем, у которых связь между элементами множеств U, Л, Y задается функциональным оператором Н, а оператор Т яв- ляется множественно-точечным отображением, содержащим алгоритмы статистической обработки. Такие модели при- меняются в тех случаях, когда результат операции является случайным, а конечные функциональные зависимости, свя- зывающие статистические характеристики учитываемых в модели случайных факторов с характеристиками исхода опе- рации, отсутствуют. Причинами случайности исхода опера- ции могут быть случайные внешние воздействия; случайные характеристики внутренних процессов; случайный характер 259
реализации стратегий управления. В статистических моделях сначала формируется представительная выборка значений выходных характеристик модели, а затем производится ее статистическая обработка с целью получения значения ска- лярного или векторного показателя эффективности. Имитационными называются математические модели си- стем, у которых оператор моделирования исхода операции задается алгоритмически. Когда этот оператор является сто- хастическим, а оператор оценивания эффективности зада- ется множественно-точечным отображением, имеем клас- сическую имитационную модель, которую более подробно рассмотрим в подразд. 3.2. Если оператор Н является детер- минированным, а оператор Т задает точечно-точечное ото- бражение, можно говорить об определенным образом вырож- денной имитационной модели. На рис. 3.1.2 представлена классификация наиболее час- то встречающихся математических моделей по рассмотрен- ному признаку. Важно отметить, что при создании аналитических и ста- тистических моделей широко используются их гомоморфные свойства (способность одних и тех же математических мо- делей описывать различные по физической природе процес- Вид ОСНОВНЫХ операторов Н функциональный алгоритмический детер- мин. стоха- стич. детер- мин. стоха- стич. ¥ Множественно- точечное отображение ——— Статисти- ческие —— Имита- ционные Точечно-точечное отображение Аналити- ческие —— Имита- ционные " — Рис. 3.1.2. Основная классификация математических моделей 260
сы и явления). Для имитационных моделей в наибольшей сте- пени характерен изоморфизм процессов и структур, т. е. взаимно-однозначное соответствие элементов структур и процессов реальной системы элементам ее математическо- го описания и, соответственно, модели. Согласно [53], изоморфизм — соответствие (отношение) между объектами, выражающее тождество их структуры (строения). Именно таким образом организовано большее чис- ло классических имитационных моделей. Названное свойство имитационных моделей проиллюстрировано рис. 3.1.3, содер- жащим пример из [53]. На рисунке обозначены: Sj — система-оригинал; S2 — изоморфное отображение оригинала; S3 — гомоморфное отображение оригинала. Рис. 3.1.3. Пример изоморфного и гомоморфного отображений Имитационные модели являются наиболее общими ма- тематическими моделями. В силу этого иногда все модели называют имитационными [55]: 261
♦ аналитические модели, “имитирующие” только физи- ческие законы, на которых основано санкционирова- ние реальной системы, можно рассматривать как ими- тационные модели I уровня-, ♦ статистические модели, в которых, кроме того, “ими- тируются” случайные факторы, можно называть ими- тационными моделями И уровня-, ♦ собственно имитационные модели, в которых еще ими- тируется и функционирование системы во времени, называют имитационными моделями III уровня. Классификацию математических моделей можно провес- ти и по другим признакам [53]. На рис. 3.1.4 представлена классификация моделей (преж- де всего аналитических и статистических) по зависимости переменных и параметров от времени. Динамические моде- ли, в которых учитывается изменение времени, подразделя- ются на стационарные (в которых от времени зависят только входные и выходные характеристики) и нестационарные (в которых от времени могут зависеть либо параметры модели, либо ее структура, либо и то и другое). На рис. 3.1.5 показана классификация математических моделей еще по трем основаниям: по характеру изменения Рис. 3.1.4. Классификация математических моделей по зависимости переменных и параметров от времени 262
переменных', по особенностям используемого математичес- кого аппарата', по способу учета проявления случайностей. Названия типов (видов) моделей в каждом классе доста- точно понятны. Укажем лишь, что в сигнально-стохастичес- ких моделях случайными являются только внешние воздей- ствия на систему. Имитационные модели, как правило, можно отнести к следующим типам: ♦ по характеру изменения переменных — к дискретно- непрерывным моделям', ♦ по математическому аппарату — к моделям смешанно- го типа; ♦ по способу учета случайности — к стохастическим моделям общего вида. Рис. 3.1.5. Классификация математических моделей 263
3.2. Имитационные модели экономических информационных систем 3.2.1. Методологические основы применения метода имитационного моделирования Выше было дано формальное определение имитацион- ной модели с точки зрения свойств двух ее важнейших опе- раторов: оператора моделирования исхода и оператора оце- нивания показателя эффективности. Приведем классичес- кое вербальное определение имитационного моделирования и проведем его краткий анализ. По Р. Шеннону (Robert Е. Shannon — профессор универ- ситета в Хантсвилле, штат Алабама, США) “имитационное моделирование — есть процесс конструирования на ЭВМ мо- дели сложной реальной системы, функционирующей во вре- мени, и постановки экспериментов на этой модели с целью либо понять поведение системы, либо оценить различные стратегии, обеспечивающие функционирование данной сис- темы” [6]. Выделим в этом определении ряд важнейших обстоя- тельств, учитывая особенности применения метода для ис- следования экономических информационных систем (ЭИС). Во-первых, имитационное моделирование предполагает два этапа: конструирование модели на ЭВМ и проведение экспериментов с этой моделью. Каждый из этих этапов пре- дусматривает использование собственных методов. Так, на первом этапе весьма важно грамотно провести информаци- онное обследование, разработку всех видов документации и их реализацию. Второй этап должен предполагать использо- вание методов планирования эксперимента с учетом особен- ностей машинной имитации. Во-вторых, в полном соответствии с системными прин- ципами четко выделены две возможные цели имитационных экспериментов: ♦ либо понять поведение исследуемой системы (о кото- рой по каким-либо причинам было “мало” информа- 264
ции) — потребность в этом часто возникает, напри- мер, при создании принципиально новых образцов про- дукции; ♦ либо оценить возможные стратегии управления сис- темой, что также очень характерно для решения ши- рокого круга экономико-прикладных задач. В-третьих, с помощью имитационного моделирования исследуют сложные системы. Понятие “сложность” являет- ся субъективным и по сути выражает отношение исследова- теля к объекту моделирования. Укажем пять признаков “слож- ности” системы, по которым можно судить о ее принад- лежности к такому классу систем: ♦ наличие большого количества взаимосвязанных и вза- имодействующих элементов; ♦ сложность функции (функций), выполняемой системой; ♦ возможность разбиения системы на подсистемы (де- композиции); ♦ наличие управления (часто имеющего иерархическую структуру), разветвленной информационной сети и ин- тенсивных потоков информации; ♦ наличие взаимодействия с внешней средой и функцио- нирование в условиях воздействия случайных (неопре- деленных) факторов. Очевидно, что некоторые приведенные признаки сами предполагают субъективные суждения. Вместе с тем стано- вится понятным, почему значительное число ЭИС относят к сложным системам и, следовательно, применяют метод ими- тационного моделирования. Отметим, что последний признак определяет потребность развития методов учета случайных факторов (см. подразд. 3.3), т. е. проведения так называемой стохастической имитации. В-четвертых, методом имитационного моделирования ис- следуют системы, функционирующие во времени, что опре- деляет необходимость создания и использования специальных методов (механизмов) управления системным временем. 265
Наконец, в-пятых, в определении прямо указывается на необходимость использования ЭВМ для реализации имита- ционных моделей, т. е. проведения машинного эксперимента (машинной имитации), причем в подавляющем большинстве случаев применяются цифровые машины. Даже столь краткий анализ позволяет сформулировать вывод о целесообразности (а следовательно, и необходимос- ти) использования метода имитационного моделирования для исследования сложных человекомашинных (эргатических) систем экономического назначения. Особо выделим наиболее характерные обстоятельства применения имитационных мо- делей [60]: ♦ если идет процесс познания объекта моделирования; ♦ если аналитические методы исследования имеются, но составляющие их математические процедуры очень сложны и трудоемки; ♦ если необходимо осуществить наблюдение за поведе- нием компонент системы в течение определенного времени; ♦ если необходимо контролировать протекание процес- сов в системе путем замедления или ускорения явле- ний в ходе имитации; ♦ если особое значение имеет последовательность собы- тий в проектируемых системах и модель использу- ется для предсказания так называемых “узких” мест; ♦ при подготовке специалистов для приобретения необ- ходимых навыков в эксплуатации новой техники; ♦ и, конечно, если имитационное моделирование оказы- вается единственным способом исследований из-за не- возможности проведения реальных экспериментов. До настоящего момента особое внимание в толковании термина “имитационное моделирование системы” было уде- лено первому слову. Однако не следует упускать из вида, что создание любой (в том числе и имитационной) модели предполагает, что она будет отражать лишь наиболее суще- 266
ственные с точки зрения конкретной решаемой задачи свой- ства объекта-оригинала. Английский аналог этого термина — systems simulation — при дословном переводе непосредственно указывает на необ- ходимость воспроизводства (симуляции) лишь основных черт реального явления (ср. с термином “симуляция симптомов болезни” из медицинской практики). Важно отметить еще один аспект: создание любой (в том числе и имитационной модели) есть процесс творческий (не случайно Р. Шеннон назвал свою книгу “Имитационное моделирование систем — искусство и наука”), и, вообще говоря, каждый автор имеет право на собственную версию модели реальной системы. Однако за достаточно длительное время применения метода накоплены определенный опыт и признанные разумными рекомендации, которыми целесообразно руководствоваться при организации имитационных экспериментов. Укажем ряд основных достоинств и недостатков мето- да имитационного моделирования [6, 60]. Основные достоинства: ♦ имитационная модель позволяет, в принципе, описать моделируемый процесс с большей адекватностью, чем другие; ♦ имитационная модель обладает известной гибкостью варьирования структуры, алгоритмов и параметров системы; ♦ применение ЭВМ существенно сокращает продолжи- тельность испытаний по сравнению с натурным экс- периментом (если он возможен), а также их стоимость. Основные недостатки: ♦ решение, полученное на имитационной модели, всегда носит частный характер, так как оно соответствует фиксированным элементам структуры, алгоритмам по- ведения и значениям параметров системы; ♦ большие трудозатраты на создание модели и прове- дение экспериментов, а также обработку их результа- тов; 267
♦ если использование системы предполагает участие людей при проведении машинного эксперимента, на ре- зультаты может оказать влияние так называемых ха- уторнский эффект (заключающийся в том, что люди, зная (чувствуя), что за ними наблюдают, могут изме- нить свое обычное поведение). Итак, само использование термина “имитационное мо- делирование” предполагает работу с такими математически- ми моделями, с помощью которых результат исследуемой операции нельзя заранее вычислить или предсказать, поэтому необходим эксперимент (имитация) на модели при задан- ных исходных данных. В свою очередь, сущность машинной имитации заключается в реализации численного метода про- ведения на ЭВМ экспериментов с математическими моде- лями, описывающими поведение сложной системы в течение заданного или формируемого периода времени [5]. Каждая имитационная модель представляет собой ком- бинацию шести основных составляющих [5, 53]: ♦ компонентов; ♦ переменных', ♦ параметров; ♦ функциональных зависимостей; ♦ ограничений; ♦ целевых функций. Под компонентами понимают составные части, кото- рые при соответствующем объединении образуют систему. Компоненты называют также элементами системы или ее подсистемами. Например, в модели рынка ценных бумаг ком- понентами могут выступать отделы коммерческого банка (кре- дитный, операционный и т. д.), ценные бумаги и их виды, доходы, котировка и т. п. Параметры — это величины, которые исследователь (пользователь модели) может выбирать произвольно, т. е. управлять ими. В отличие от них переменные могут принимать только значения, определяемые видом данной функции. Так, в вы- 268
ражении для плотности вероятности нормально распределен- ной случайной величины X (х~тх)2 f(x) = -12=-e 2°* где х — переменная; тх, Ох — параметры (математическое ожидание и стан- дартное отклонение соответственно); п, е — константы. Различают экзогенные (являющиеся для модели входны- ми и порождаемые вне системы) и эндогенные (возникаю- щие в системе в результате воздействия внутренних при- чин) переменные. Эндогенные переменные иногда называют переменными состояния. Функциональные зависимости описывают поведение па- раметров и переменных в пределах компонента или же вы- ражают соотношения между компонентами системы. Эти соотношения могут быть либо детерминированными, либо стохастическими. Ограничения — устанавливаемые пределы изменения значений переменных или ограничивающие условия их изме- нения. Они могут вводиться разработчиком (и тогда их назы- вают искусственными) или определяться самой системой вследствие присущих ей свойств (так называемые естествен- ные ограничения). Целевая функция предназначена для измерения степени достижения системой желаемой (требуемой) цели и вынесе- ния оценочного суждения по результатам моделирования. Эту функцию также называют функцией критерия. По сути, весь машинный эксперимент с имитационной моделью заключает- ся в поиске таких стратегий управления системой, которые удовлетворяли бы одной из трех концепций ее рационально- го поведения: оптимизации, пригодности или адаптивиза- ции [26]. Если показатель эффективности системы является скалярным, проблем с формированием критерия не возника- ет и, как правило, решается оптимизационная задача — по- 269
иска стратегии, соответствующей максимуму или минимуму показателя. Сложнее дело обстоит, если приходится исполь- зовать векторный показатель. В этом случае для вынесения оценочного суждения используются методы принятия реше- ний по векторному показателю в условиях определенности (когда в модели учитываются только детерминированные факторы) или неопределенности (в противном случае). При реализации имитационной модели, как правило, рас- сматриваются не все реально осуществляемые функциональ- ные действия (ФД) системы, а только те из них, которые являются наиболее существенными для исследуемой опера- ции. Кроме того, реальные ФД аппроксимируются упрощен- ными действиями ФД' причем степень этих упрощений оп- ределяется уровнем детализации учитываемых в модели фак- торов. Названные обстоятельства порождают ошибки имита- ции процесса функционирования реальной системы, что, в свою очередь, обусловливает адекватность модели объекту- оригиналу и достоверность получаемых в ходе моделирова- ния результатов. На рис. 3.2.1 схематично представлен пример выполне- ния некоторых ФД в в г-м компоненте реальной системы и ФД' в г-м компоненте ее модели. В г-м компоненте реальной системы последовательно выполняются ФД(|, ФД/2, ФД,3,... за времена Т;, Т<2, Т,3..., со- Рис. 3.2.1. Схема моделирования функциональных действий в г-м компоненте системы 270
ответственно. На рисунке эти действия условно изображены пунктирными (“непрямыми”) стрелками. В результате ФД наступают соответствующие события: Ц,С,-2,С^,.... В модели последовательность имитации иная: выполняется ФД^ при неизменном времени, наступает модельное событие а, после чего время сдвигается на величину ^.инициируя наступле- ние события и т. д. Иными словами, модельной реализации упрощенных ФД (ФД') соответствует ломаная (0, а, Ц Ъ, С(2,С,С,3,...). Отметим, что в принципе возможен и другой по- рядок моделирования: сначала сдвигать время, а затем ини- циировать наступление соответствующего события. Очевидно, что в реальной системе в различных ее ком- понентах могут одновременно (параллельно) производиться функциональные действия и, соответственно, наступать со- бытия. В большинстве же современных ЭВМ в каждый из моментов времени можно отрабатывать лишь один алгоритм какого-либо ФД. Возникает вопрос: каким образом учесть па- раллельность протекания процессов в реальной системе без потери существенной информации о ней? Для обеспечения имитации наступления параллельных событий в реальной системе вводят специальную глобаль- ную переменную t0, которую называют модельным (систем- ным) временем. Именно с помощью этой переменной органи- зуется синхронизация наступления всех событий в модели ЭИС и выполнение алгоритмов функционирования ее компо- нент. Принцип такой организации моделирования называ- ется принципом квазипараллелизма [5]. Таким образом, при реализации имитационных моделей используют три представления времени: ♦ t — реальное время системы; ♦ t0— модельное (системное) время; ♦ tM — машинное время имитации. 3.2.2. Классификация имитационных моделей Имитационные модели принято классифицировать по четырем наиболее распространенным признакам: 271
♦ типу используемой ЭВМ; ♦ способу взаимодействия с пользователем; ♦ способу управления системным временем (механизму системного времени); ♦ способу организации квазипараллелизма (схеме форма- лизации моделируемой системы). Первые два признака позволяют разделить имитацион- ные модели на совершенно понятные (очевидные) классы, поэтому их рассмотрение не займет много места. По типу используемой ЭВМ различают аналоговые, циф- ровые и гибридные имитационные модели. Достоинства и не- достатки моделей каждого класса общеизвестны [27]. В даль- нейшем будем рассматривать только цифровые модели. По способу взаимодействия с пользователем имитацион- ные модели могут быть автоматическими (не требующими вмешательства исследователя после определения режима моделирования и задания исходных данных) и интерактив- ными (предусматривающими диалог с пользователем в том или ином режиме в соответствии со сценарием моделирова- ния). Отметим, что моделирование сложных систем, относя- щихся, как уже отмечалось, к классу эргатических систем, как правило, требует