Всё для Учёбы — студенческий файлообменник
2 монеты
doc

Лекции по Проектированию информационных систем (Иванько А. Ф.)

Министерство образования и науки Российской Федерации

Федеральное агентство по образованию

Государственное образовательное учреждение высшего

профессионального образования

Московский государственный университет печати

Кафедра информационных систем

Проектирование

информационных систем

Доцент Иванько А.Ф.

КОНСПЕКТ ЛЕКЦИЙ

Для студентов, обучающихся по специальности

230201-«Информационные системы в технике и технологиях»

Москва 2007

Содержание

Содержание 2

Раздел 1. Общая характеристика процесса проектирования. 7

Проектирование 7

Основные понятия технологии проектирования информационных систем 8

Классификация ИС 9

Основные этапы развития ИС 13

Этапы и стадии проектирования ИС 14

Жизненный цикл информационной системы 17

Каноническое проектирование ИС 25

Типовое проектирование ИС 36

Информационные системы в полиграфии 40

Электронная информация в издательском деле 40

Концепция сетевых издательств 42

Экономические выводы сетевых издательств 43

Раздел 2. Структура информационно-логической модели ИС. 45

Построение информационно-логической модели 45

Информационные объекты 45

Выделение информационных объектов предметной области 47

Информационный анализ и определение логической структуры информации 48

Связи информационных объектов 51

Тип связи информационных объектов 51

Определение связей между информационными объектами 52

Информационно-логическая модель предметной области 54

Математические модели процессов функционирования информационных систем 55

Методы построения математических моделей ИС на ЭВМ и их применение в ИС 55

Описание предлагаемого комплекса моделей 55

Модель процессов представления информации в условиях ненадежности программно-технических средств 56

Модель процессов массового обслуживания запросов на получение информации в системе 58

Модель процессов отражения в базе данных новых объектов учета предметной области 60

Модель процесса визуального контроля информации, вводимой в базу данных (БД) 62

Модель процесса возникновения и устранения случайных ошибок со стороны пользователей и обслуживающего персонала 65

Модель процессов сбора информации от источников 67

Сети Петри 69

Теория сетей Петри 70

Простые сети Петри 70

Цветные сети Петри 76

Раздел 3. Разработка функциональной модели. Исходные данные для проектирования. 82

Структурная модель предметной области 82

Объектная структура 84

Функциональная структура 84

Структура управления 85

Организационная структура 85

Техническая структура 86

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области 87

Функциональная методика IDEF0 87

Функциональная методика потоков данных 91

Объектно-ориентированная методика 93

Сравнение существующих методик 94

Синтетическая методика 95

Информационное обеспечение ИС 97

Внемашинное информационное обеспечение 98

Внутримашинное информационное обеспечение 107

Раздел 4. Разработка модели и защита данных. Пользовательский интерфейс. Проект распределенной обработки. 111

Устройства ввода-вывода информации 111

Устройства ввода данных 112

Устройства вывода информации 113

Требования к техническим средствам, поддерживающим ИС 115

Аппаратные средства сетей 116

Типовые структуры 117

Организации и их структуры 117

Типовые структуры организационных систем (ОС) 118

Сетевые структуры организационных систем (ОС) 118

Свойства типовых структур организационных систем (ОС) 119

Моделирование данных 121

Базовые понятия ERD 121

Метод IDEFI 122

Защита данных 124

Аудит информационной защиты компании 124

Создание системы защиты периметра локальной сети 127

Разработка пользовательского интерфейса 130

Разработка эффективных форм 130

Проектирование форм ввода данных 131

Работа с несколькими формами 131

Эффективные меню 131

Ощущение скорости 132

Организация распределенных ИС на основе вычислительных сетей 132

Раздел 5. Структура программных модулей. Разработка алгоритмов. 134

Лингвистическое обеспечение ИС 134

Языки программирования для создания информационных систем 134

Ассемблер 135

Delphi 135 С/С++ 136

Java 139

Программное обеспечение ИС 140

Разнородность информации 140

Методы представления графической информации 142

Текстовые данные в мультимедиа 143

Звуковая информация 145

Межпрограммный интерфейс 146

Распределенные базы данных 148

Определение Дэйта 148

Целостность данных 149

Архитектура "клиент-сервер" 149

Средства и методологии проектирования, разработки и сопровождения Intranet и Internet-приложений 151

Основные понятия Intranet 152

Языки и протоколы 152

Серверы Intranet 159

Возможные архитектуры Intranet-приложений 171

Раздел 6. Логический анализ структур ИС. Анализ и оценка производительности ИС. 173

Численные методы построения математических моделей 173

Вычислительный алгоритм 174

Требования к вычислительным методам 175

Структурный анализ 176

Диаграммы потоков данных 176

Описание потоков данных и процессов 177

Расширения для систем реального времени 178

Расширение возможностей управления 180

Методы анализа, ориентированные на структуры данных 181

Метод анализа Джексона 182

Методика Джексона 182

Шаг объект-действие 183

Шаг объект-структура 183

Шаг начального моделирования 185

Методы тестирования 187

Метод «Белого ящика» 188

Метод «Черного ящика» 189

Подходы к оценке систем 190

Раздел 7. Управление проектом ИС. Проектная документация. 193

Цифровое и аналоговое моделирование 193

Цифровое моделирование 193

Аналоговое моделирование 193

Полунатурное моделирование 194

Имитационное моделирование 196

Математическое обеспечение САПР 198

Требования к математическому обеспечению 198

Требования к математическим моделям 200

Классификация математических моделей 201

Математические модели на микро-, макро- и метауровнях 202

Методика получения математических моделей элементов и устройств автоматизации 206

Оценка точности модели 207

Современное прикладное программное обеспечение для решения задачи моделирования ИС 207

Раздел 8. Инструментальные средства проектирования ИС. Типизация проектных решений. 210

Инструментальные средства проектированя 210

Унифицированный язык визуального моделирования 210

Синтаксис и семантика основных объектов UML 211

Анализ и синтез систем управления 220

Частотный метод анализа и синтеза систем управления 220

Временной метод анализа, основанный на переходных характеристиках и интеграле Дюамеля 225

Корневой метод 234

Современное прикладное программное обеспечение для решения задач анализа и синтеза СУ 238

Раздел 9. Графические средства представления проектных решений. Эксплуатация ИС. 240

Графические средства представления проектных решений. Проектирование ИС с применением UML 240

Разработка модели прецедентов 241

Разработка модели объектов 244

Разработка концептуальной модели данных 245

Разработка требований к системе 246

Анализ требований и предварительное проектирование системы. 249

Разработка моделей базы данных и приложений 250

Проектирование физической реализации системы 253

Список литературы 255

Раздел 1. Общая характеристика процесса проектирования.

Структура раздела

Проектирование

Основные понятия технологии проектирования информационных систем

Классификация ИС

Основные этапы развития ИС

Этапы и стадии проектирования ИС

Жизненный цикл информационной системы

Каноническое проектирование ИС

Типовое проектирование ИС

Информационные системы в полиграфии

Электронная информация в издательском деле

Концепция сетевых издательств

Экономические выводы сетевых издательств

Проектирование

Проектирование (от лат. projectus, буквально - брошенный вперёд), процесс создания проекта - прототипа, прообраза предполагаемого или возможного объекта, состояния.

Различают этапы и стадии проектирования, характеризующиеся определённой спецификой. Предметная область проектирования постоянно расширяется.

Наряду с традиционными видами проектирования (архитектурно-строительным, машиностроительным, технологическим и др.) существуют самостоятельные направления проектирования информационных систем (решающих, познающих, эвристических, прогнозирующих, планирующих, управляющих и т.п.), трудовых процессов, организаций, экологическое, социальное, инженерно-психологическое, генетическое проектирование и др. Наряду с дифференциацией проектирования ид1ёт процесс его интеграции на основе выявления общих закономерностей и методов проектной деятельности.

Проектирование в строительстве, технике - разработка проектной, конструкторской и др. технической документации, предназначенной для осуществления капитального строительства (какого-либо объекта), создания новых видов и образцов продукции промышленности.

В процессе проектирования выполняются технические и экономические расчёты, схемы, графики, пояснительные записки, макеты, составляются спецификации, сметы, калькуляции и описания.

Проект - комплект указанной документации и материалов (определённого состава). Проект какого-либо объекта капитального строительства (предприятия, здания, сооружения) может быть индивидуальным или типовым. При разработке индивидуальных проектов широко применяются типовые проекты конструкций, архитектурных и монтажных деталей и типовые проектные решения.

Проектирование новых видов и образцов машин, оборудования, аппаратов, приборов и др. продукции всех отраслей промышленности, или конструирование, представляет собой разработку исходных данных (чертежей, спецификаций, технических условий по монтажу, наладке, уходу и др. конструкторской документации), необходимых для производства и последующей эксплуатации продукции. При этом широко используются нормализованные детали, унифицированные узлы, агрегаты.

Отраслевая проектная организация, разрабатывающая технологическую часть проекта, как правило, является генеральным проектировщиком, привлекающим в случае необходимости специализированные (субподрядные) проектные организации для выполнения отдельных частей проекта. Задание на проектирование, в котором указываются наименование объекта, место строительства, номенклатура продукции, мощность производства и др. данные и условия строительства, составляется заказчиком (министерством, ведомством, предприятием) с участием проектной организации. Для получения данных, необходимых для технически правильного и экономически целесообразного решения основных вопросов проектирования, строительства и эксплуатации объектов, осуществляется комплекс технических и экономических исследований. Проект может выполняться в две стадии - технический проект и рабочие чертежи или в одну стадию - техно-рабочий проект. На стадии технического проекта разрабатываются основные вопросы организации, технологии и экономики производства, составляется смета и определяются технико-экономическими показатели. При разработке рабочих чертежей производятся уточнения и детализация предусмотренных техническим проектом решений в той степени, в которой это необходимо для производства и монтажных работ. Порядок экспертизы и утверждения проектов зависит от сметной стоимости проектируемых объектов.

Стадии конструирования - проектное задание или эскизный проект, технический проект, рабочий проект. Стадийность разработки, а также состав конструкторской документации указываются в техническом задании, составляемом разработчиком (министерством, ведомством, предприятием и пр.) на основе достижений науки и техники, потребностей в этой продукции народного хозяйства, населения, экспорта. Техническое задание утверждается заказчиком (основным потребителем продукции). Чертежи и др. конструкторская документация на продукцию промышленности, включая строительные конструкции, как правило, выполняются проектно-конструкторскими организациями (бюро) предприятий-изготовителей. При разработке производятся научно-исследовательские и опытные работы, связанные с проверкой отдельных технических решений.

При проектировании целесообразно широко использовать средства оргтехники и ЭВМ, что позволяет сократить сроки и улучшить качество проректа, повысить производительность труда проектировщиков и конструкторов.

Основные понятия технологии проектирования информационных систем

Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности.

Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации.

Информационная система - по законодательству РФ - организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы.

Информационные системы предназначена для хранения, обработки, поиска, распространения, передачи и предоставления информации.

Классификация ИС

Информационные системы можно классифицировать по целому ряду различных признаков. В основу рассматриваемой классификации положены наиболее существенные признаки, определяющие функциональные возможности и особенности построения современных систем. В зависимости от объема решаемых задач, используемых технических средств, организации функционирования, информационные системы делятся на ряд групп (классов) (Рис 1).

Рис. 1. Класcификация информационных систем

По типу хранимых данных ИС делятся на фактографические и документальные. Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции. В документальных системах информация представлена в виде документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится.

Основываясь на степени автоматизации информационных процессов в системе управления фирмой, информационные системы делятся на ручные, автоматические и автоматизированные.

Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.

В автоматических ИС все операции по переработке информации выполняются без участия человека.

Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятия "информационная система".

В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие.

Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. (Например, ИС библиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр.)

Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие.

Результирующая информация управляющих ИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИС планирования производства или заказов, бухгалтерского учета.)

Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных. (Например, экспертные системы.)

В зависимости от сферы применения различают следующие классы ИС.

Информационные системы организационного управления - предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр.).

Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи.

ИС управления технологическими процессами (ТП) - служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (температуры, давления, химического состава и т.п.), процедур контроля допустимости значений параметров и регулирования технологических процессов.

ИС автоматизированного проектирования (САПР) - предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов.

Интегрированные (корпоративные) ИС - используются для автоматизации всех функций фирмы и охватывают весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности. Типовые задачи, решаемые модулями корпоративной системы, приведены в таблице 1.

Таблица 1. Функциональное назначение модулей корпоративной ИС.

Подсистема маркетинга Производственные подсистемы Финансовые и учетные подсистемы Подсистема кадров (человеческих ресурсов) Прочие подсистемы (например, ИС руководства)

Исследование рынка и прогнозирование продаж Планирование объемов работ и разработка календарных планов Управление портфелем заказов Анализ и прогнозирование потребности в трудовых ресурсах Контроль за деятельностью фирмы

Управление продажами Оперативный контроль и управление производством Управление кредитной политикой Ведение архивов записей о персонале Выявление оперативных проблем

Рекомендации по производству новой продукции Анализ работы оборудования Разработка финансового плана Анализ и планирование подготовки кадров Анализ управленческих и стратегических ситуаций

Анализ и установление цены Участие в формировании заказов поставщикам Финансовый анализ и прогнозирование Обеспечение процесса выработки стратегических решений

Учет заказов Управление запасами Контроль бюджета, бухгалтерский учет и расчет зарплаты

Анализ современного состояния рынка ИС показывает устойчивую тенденцию роста спроса на информационные системы организационного управления. Причем спрос продолжает расти именно на интегрированные системы управления. Автоматизация отдельной функции, например, бухгалтерского учета или сбыта готовой продукции, считается уже пройденным этапом для многих предприятий.

В таблице 2 приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов.

Таблица 2. Классификация рынка информационных систем

Локальные системы Малые интегрированные системы Средние интегрированные системы Крупные интегрированные системы (IC)

• БЭСТ • Инотек

• Инфософт

• Супер-Менеджер

• Турбо-Бухгалтер

• Инфо-Бухгалтер • Concorde XAL Exact

• NS-2000 Platinum PRO/MIS

• Scala SunSystems

• БЭСТ-ПРО

• 1C-Предприятие

• БОСС-Корпорация

• Галактика

• Парус • Ресурс

• Эталон • Microsoft-Business Solutions - Navision, Axapta

• J D Edwards (Robertson & Blums)

• MFG-Pro (QAD/BMS)

• SyteLine (COKAП/SYMIX) • SAP/R3 (SAP AG)

• Baan (Baan)

• BPCS (ITS/SSA)

• OEBS (Oracle E-Business Suite)

Существует классификация ИС в зависимости от уровня управления, на котором система используется.

Информационная система оперативного уровня - поддерживает исполнителей, обрабатывая данные о сделках и событиях (счета, накладные, зарплата, кредиты, поток сырья и материалов). Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой.

Задачи, цели, источники информации и алгоритмы обработки на оперативном уровне заранее определены и в высокой степени структурированы.

Информационные системы специалистов - поддерживают работу с данными и знаниями, повышают продуктивность и производительность работы инженеров и проектировщиков. Задача подобных информационных систем - интеграция новых сведений в организацию и помощь в обработке бумажных документов.

Информационные системы уровня менеджмента - используются работниками среднего управленческого звена для мониторинга, контроля, принятия решений и администрирования. Основные функции этих информационных систем:

• сравнение текущих показателей с прошлыми;

• составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

• обеспечение доступа к архивной информации и т.д.

Стратегическая информационная система - компьютерная информационная система, обеспечивающая поддержку принятия решений по реализации стратегических перспективных целей развития организации.

Информационные системы стратегического уровня помогают высшему звену управленцев решать неструктурированные задачи, осуществлять долгосрочное планирование. Основная задача - сравнение происходящих во внешнем окружении изменений с существующим потенциалом фирмы. Они призваны создать общую среду компьютерной телекоммуникационной поддержки решений в неожиданно возникающих ситуациях. Используя самые совершенные программы, эти системы способны в любой момент предоставить информацию из многих источников. Некоторые стратегические системы обладают ограниченными аналитическими возможностями.

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

Основные этапы развития ИС

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

На первом этапе основным подходом в проектировании ИС был метод "снизу-вверх", когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.

Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.

Следующий этап связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться "сверху-вниз", т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей.

Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.

Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем.

Цель такой методологии заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решению которых должна способствовать методология проектирования корпоративных ИС, являются следующие:

• обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;

• гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

• поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

• обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).

Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.

Этапы и стадии проектирования ИС

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:

• требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

• требуемой пропускной способности системы;

• требуемого времени реакции системы на запрос;

• безотказной работы системы;

• необходимого уровня безопасности;

• простоты эксплуатации и поддержки системы.

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

Процесс создания ИС делится на ряд этапов (стадий), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.

Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.

На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.

Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.

Конечными продуктами этапа проектирования являются:

• схема базы данных (на основании ER-модели, разработанной на этапе анализа);

• набор спецификаций модулей системы (они строятся на базе моделей функций).

Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:

• будет ли это архитектура "файл-сервер" или "клиент-сервер";

• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;

• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.

Этап тестирования обычно оказывается распределенным во времени.

После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

• обнаружение отказов модуля (жестких сбоев);

• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.

Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.

Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.

Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.

Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.

Жизненный цикл информационной системы

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

В настоящее время известны и используются следующие модели жизненного цикла:

• Каскадная модель (Рис.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

• Поэтапная модель с промежуточным контролем (Рис.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

• Спиральная модель (Рис.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

Рис.1. Каскадная модель ЖЦ ИС

Рис.2. Поэтапная модель с промежуточным контролем

Рис.3. Спиральная модель ЖЦ ИС

На практике наибольшее распространение получили две основные модели жизненного цикла:

• каскадная модель (характерна для периода 1970-1985 гг.);

• спиральная модель (характерна для периода после 1986.г.).

В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.

Можно выделить следующие положительные стороны применения каскадного подхода:

• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

• выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.

Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.

Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.

Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Несмотря на настойчивые рекомендации компаний - вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. Основные причины, по которым каскадная модель сохраняет свою популярность, следующие:

1. Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.

2. Иллюзия снижения рисков участников проекта (заказчика и исполнителя).Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.

3. Проблемы внедрения при использовании итерационной модели. В некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение информационной системы для бизнеса возможно, но сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а управление проектом требует настоящего искусства. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы "внедрять систему один раз".

Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.

Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.

Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

Среди наиболее известных стандартов можно выделить следующие:

• ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

• ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

• Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

• Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

• Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

• Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

o приобретение;

o поставка;

o разработка;

o эксплуатация;

o сопровождение.

2. Вспомогательные процессы:

o документирование;

o управление конфигурацией;

o обеспечение качества;

o разрешение проблем;

o аудит; o аттестация;

o совместная оценка;

o верификация.

3. Организационные процессы:

o создание инфраструктуры;

o управление;

o обучение;

o усовершенствование.

В таблице1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.

Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management).

Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Процесс (исполнитель процесса) Действия Вход Результат

Приобретение (заказчик) • Инициирование

• Подготовка заявочных предложений

• Подготовка договора

• Контроль деятельности поставщика

• Приемка ИС • Решение о начале работ по внедрению ИС

• Результаты обследования деятельности заказчика

• Результаты анализа рынка ИС/ тендера

• План поставки/ разработки

• Комплексный тест ИС • Технико-экономическое обоснование внедрения ИС

• Техническое задание на ИС

• Договор на поставку/ разработку

• Акты приемки этапов работы

• Акт приемно-сдаточных испытаний

Поставка (разработчик ИС) • Инициирование

• Ответ на заявочные предложения

• Подготовка договора

• Планирование исполнения

• Поставка ИС • Техническое задание на ИС

• Решение руководства об участии в разработке

• Результаты тендера

• Техническое задание на ИС

• План управления проектом

• Разработанная ИС и документация • Решение об участии в разработке

• Коммерческие предложения/ конкурсная заявка

• Договор на поставку/ разработку

• План управления проектом

• Реализация/ корректировка

• Акт приемно-сдаточных испытаний

Разработка (разработчик ИС) • Подготовка

• Анализ требований к ИС

• Проектирование архитектуры ИС

• Разработка требований к ПО

• Проектирование архитектуры ПО

• Детальное проектирование ПО

• Кодирование и тестирование ПО

• Интеграция ПО и квалификационное тестирование ПО

• Интеграция ИС и квалификационное тестирование ИС • Техническое задание на ИС

• Техническое задание на ИС, модель ЖЦ

• Техническое задание на ИС

• Подсистемы ИС

• Спецификации требования к компонентам ПО

• Архитектура ПО

• Материалы детального проектирования ПО

• План интеграции ПО, тесты

• Архитектура ИС, ПО, документация на ИС, тесты • Используемая модель ЖЦ, стандарты разработки

• План работ

• Состав подсистем, компоненты оборудования

• Спецификации требования к компонентам ПО

• Состав компонентов ПО, интерфейсы с БД, план интеграции ПО

• Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам

• Тексты модулей ПО, акты автономного тестирования

• Оценка соответствия комплекса ПО требованиям ТЗ

• Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

o приобретение (внутренние решения или решения внешнего поставщика);

o поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

o управление окружающей средой предприятия;

o инвестиционное управление;

o управление ЖЦ ИС;

o управление ресурсами;

o управление качеством.

3. Проектные процессы:

o планирование проекта;

o оценка проекта;

o контроль проекта;

o управление рисками;

o управление конфигурацией;

o управление информационными потоками;

o принятие решений.

4. Технические процессы:

o определение требований;

o анализ требований;

o разработка архитектуры;

o внедрение;

o интеграция;

o верификация;

o переход;

o аттестация;

o эксплуатация;

o сопровождение;

o утилизация.

5. Специальные процессы:

o определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 2.

Таблица 2.2. Стадии создания систем (ISO/IEC 15288)

№ п/п Стадия Описание

1 Формирование концепции Анализ потребностей, выбор концепции и проектных решений

2 Разработка Проектирование системы

3 Реализация Изготовление системы

4 Эксплуатация Ввод в эксплуатацию и использование системы

5 Поддержка Обеспечение функционирования системы

6 Снятие с эксплуатации Прекращение использования, демонтаж, архивирование системы

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

• обследование объекта и обоснование необходимости создания ИС;

• формирование требований пользователей к ИС;

• оформление отчета о выполненной работе и тактико-технического задания на разработку.

Стадия 2. Разработка концепции ИС.

• изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ;

• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

• оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

• разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

• разработка предварительных проектных решений по системе и ее частям;

• разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку комплектующих изделий;

• разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

• разработка рабочей документации на ИС и ее части;

• разработка и адаптация программ.

Стадия 7. Ввод в действие.

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

• выполнение работ в соответствии с гарантийными обязательствами;

• послегарантийное обслуживание.

Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:

• обоснования разработки и поэтапного внедрения систем;

• составления технического задания на разработку систем;

• разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.

По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения ).

Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).

Ориентировочное содержание этого документа:

• ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

• совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;

• сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;

• описание выполняемых системой функций;

• возможности развития системы;

• информационные объекты системы;

• интерфейсы и распределение функций между человеком и системой;

• требования к программным и информационным компонентам ПО, требования к СУБД;

• что не будет реализовано в рамках проекта.

На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:

• инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;

• возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции - информация о событиях и процессах, которые происходят в бизнесе;

• сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.

При изучении каждой функциональной задачи управления определяются:

• наименование задачи; сроки и периодичность ее решения;

• степень формализуемости задачи;

• источники информации, необходимые для решения задачи;

• показатели и их количественные характеристики;

• порядок корректировки информации;

• действующие алгоритмы расчета показателей и возможные методы контроля;

• действующие средства сбора, передачи и обработки информации;

• действующие средства связи;

• принятая точность решения задачи;

• трудоемкость решения задачи;

• действующие формы представления исходных данных и результатов их обработки в виде документов;

• потребители результатной информации по задаче.

Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:

• количество документов;

• место формирования показателей документа;

• взаимосвязь документов при их формировании;

• маршрут и длительность движения документа;

• место использования и хранения данного документа;

• внутренние и внешние информационные связи;

• объем документа в знаках.

По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.

На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW.

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.

Функции первой категории обеспечивают критичные для успешной работы системы возможности.

Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий.

Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.

Модели деятельности организации создаются в двух видах:

• модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;

• модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:

• получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;

• разработки плана работ по обеспечению надежности информационной системы и ее тестирования.

Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.

Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.

Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

При разработке технического задания необходимо решить следующие задачи:

• установить общую цель создания ИС, определить состав подсистем и функциональных задач;

• разработать и обосновать требования, предъявляемые к подсистемам;

• разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);

• установить общие требования к проектируемой системе;

• определить перечень задач создания системы и исполнителей;

• определить этапы создания системы и сроки их выполнения;

• провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

Типовые требования к составу и содержанию технического задания приведены в таблице 1.

Таблица 1. Состав и содержание технического задания (ГОСТ 34.602- 89)

№ п\п Раздел Содержание

1 Общие сведения • полное наименование системы и ее условное обозначение

• шифр темы или шифр (номер) договора;

• наименование предприятий разработчика и заказчика системы, их реквизиты

• перечень документов, на основании которых создается ИС

• плановые сроки начала и окончания работ

• сведения об источниках и порядке финансирования работ

• порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств

2 Назначение и цели создания (развития) системы • вид автоматизируемой деятельности

• перечень объектов, на которых предполагается использование системы

• наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС

3 Характеристика объектов автоматизации • краткие сведения об объекте автоматизации

• сведения об условиях эксплуатации и характеристиках окружающей среды

4 Требования к системе Требования к системе в целом:

• требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы развития системы)

• требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки)

• показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров)

• требования к надежности, безопасности, эргономике, транспортабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации

Требования к функциям (по подсистемам) :

• перечень подлежащих автоматизации задач

• временной регламент реализации каждой функции

• требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов

• перечень и критерии отказов

Требования к видам обеспечения:

• математическому (состав и область применения мат. моделей и методов, типовых и разрабатываемых алгоритмов)

• информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам)

• лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода- вывода)

• программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ)

• техническому

• метрологическому

• организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала)

• методическому (состав нормативно- технической документации

5 Состав и содержание работ по созданию системы • перечень стадий и этапов работ

• сроки исполнения

• состав организаций — исполнителей работ

• вид и порядок экспертизы технической документации

• программа обеспечения надежности

• программа метрологического обеспечения

6 Порядок контроля и приемки системы • виды, состав, объем и методы испытаний системы

• общие требования к приемке работ по стадиям

• статус приемной комиссии

7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие • преобразование входной информации к машиночитаемому виду

• изменения в объекте автоматизации

• сроки и порядок комплектования и обучения персонала

8 Требования к документированию • перечень подлежащих разработке документов

• перечень документов на машинных носителях

9 Источники разработки документы и информационные материалы, на основании которых разрабатывается ТЗ и система

Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.

Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

• функции ИС;

• функции подсистем, их цели и ожидаемый эффект от внедрения;

• состав комплексов задач и отдельных задач;

• концепция информационной базы и ее укрупненная структура;

• функции системы управления базой данных;

• состав вычислительной системы и других технических средств;

• функции и параметры основных программных средств.

По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы.

На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект системы - это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению.

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

Состав и содержание технического проекта приведены в таблице 2.

Таблица 2. Содержание технического проекта

№ п\п Раздел Содержание

1 Пояснительная записка • основания для разработки системы

• перечень организаций разработчиков

• краткая характеристика объекта с указанием основных технико-экономических показателей его функционирования и связей с другими объектами

• краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы

2 Функциональная и организационная структура системы • обоснование выделяемых подсистем, их перечень и назначение

• перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания

• схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы

3 Постановка задач и алгоритмы решения • организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими задачами, характер использования результатов решения, в которых они используются)

• экономико-математическая модель задачи (структурная и развернутая форма представления)

• входная оперативная информация ( характеристика показателей, диапазон изменения, формы представления)

• нормативно-справочная информация ( НСИ) (содержание и формы представления)

• информация, хранимая для связи с другими задачами

• информация, накапливаемая для последующих решений данной задачи

• информация по внесению изменений ( система внесения изменений и перечень информации, подвергающейся изменениям)

• алгоритм решения задачи ( последовательность этапов расчета, схема, расчетные формулы)

• контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета)

4 Организация информационной базы • источники поступления информации и способы ее передачи

• совокупность показателей, используемых в системе

• состав документов, сроки и периодичность их поступления

• основные проектные решения по организации фонда НСИ

• состав НСИ, включая перечень реквизитов, их определение, диапазон изменения и перечень документов НСИ

• перечень массивов НСИ, их объем, порядок и частота корректировки информации

• структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда

• методы хранения, поиска, внесения изменений и контроля

• определение объемов и потоков информации НСИ

• контрольный пример по внесению изменений в НСИ

• предложения по унификации документации

5 Альбом форм документов

6 Система математического обеспечения • обоснование структуры математического обеспечения

• обоснование выбора системы программирования

• перечень стандартных программ

7 Принцип построения комплекса технических средств • описание и обоснование схемы технологического процесса обработки данных

• обоснование и выбор структуры комплекса технических средств и его функциональных групп

• обоснование требований к разработке нестандартного оборудования

• комплекс мероприятий по обеспечению надежности функционирования технических средств

8 Расчет экономической эффективности системы • сводная смета затрат, связанных с эксплуатацией систем

• расчет годовой экономической эффективности, источниками которой являются оптимизация производственной структуры хозяйства (объединения), снижение себестоимости продукции за счет рационального использования производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений

9 Мероприятия по подготовке объекта к внедрению системы • перечень организационных мероприятий по совершенствованию бизнес-процессов

• перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц

10 Ведомость документов

В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.

На стадии "рабочая документация" осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.

Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.

В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

Предварительные испытания проводят для определения работоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления им соответствующих документов об их готовности к испытаниям, а также после ознакомления персонала ИС с эксплуатационной документацией.

Опытную эксплуатацию системы проводят с целью определения фактических значений количественных и качественных характеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффективности и корректировки, при необходимости, документации.

Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.

Типовое проектирование ИС

Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

• элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

• подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

• объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.

Основные особенности различных классов ТПР приведены в таблице 3.

Таблица 3. Достоинства и недостатки ТПР

Класс ТПР Реализация ТПР Достоинства Недостатки

Элементные ТПР Библиотеки методо-ориентированных программ • обеспечивается применение модульного подхода к проектированию и документированию ИС • большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости

• большие затраты времени на доработкуТПР отдельных элементов

Подсистемные ТПР Пакеты прикладных программ • достигается высокая степень интеграции элементов ИС

• позволяют осуществлять: модульное проектирование; параметрическую настройку программных компонентов на различные объекты управления

• обеспечивают: сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации • адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов

• возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения

Объектные ТПР Отраслевые проекты ИС • комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости

• открытость архитектуры — позволяет устанавливатьТПР на разных программно-технических платформах

• масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест

• конфигурируемость — позволяет выбирать необходимое подмножество компонентов • проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации

Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.

Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.

Критерии оценки ППП делятся на следующие группы:

• назначение и возможности пакета;

• отличительные признаки и свойства пакета;

• требования к техническим и программным средствам;

• документация пакета;

• факторы финансового порядка;

• особенности установки пакета;

• особенности эксплуатации пакета;

• помощь поставщика по внедрению и поддержанию пакета;

• оценка качества пакета и опыт его использования;

• перспективы развития пакета.

Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП.

Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.

Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.

Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.

Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.

Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов.

Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.

Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации. Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN).

Реализация типового проекта предусматривает выполнение следующих операций:

• установку глобальных параметров системы;

• задание структуры объекта автоматизации;

• определение структуры основных данных;

• задание перечня реализуемых функций и процессов;

• описание интерфейсов;

• описание отчетов;

• настройку авторизации доступа;

• настройку системы архивирования.

Информационные системы в полиграфии

В течение последних нескольких лет новая экономика генерировала большие изменения и активизацию в сфере издательской деятельности. Компании инвестировали миллиарды долларов в сетевые системы на базе Internet. Средства передачи электронной информации нанесли удар традиционным издательским технологиям, многие новые компании вторглись в новую для них сферу деятельности, вкладывая огромные деньги в производство электронной коммерческой издательской продукции. C прорывом Internet на коммуникационный рынок многие руководители издательских фирм начали задаваться вопросом, какие пути дальнейшего развития бизнеса становятся экономически перспективными.

В реальности, многие компании получили большие экономические выгоды от успешного подъема своего бизнеса в сфере информации через Internet. Например, фармацевтическая фирма Pfizer Inc. получила дополнительный доход в 142 млн долл. за четыре года за счет повышения скорости передачи информации о новых лекарствах, поставляемых ею на рынок. Причиной такого успеха стало создание электронных документов, которые дают возможность быстро и регулярно информировать потребителей о новых продуктах фирмы.

В 2000 г. крупнейшая издательская компания The Wall Street Journal получила новый источник доходов в 40 млн долл. cозданием в Internet для передачи сообщений о бизнес-новостях сайта WSJ.com, который насчитывает более 400 000 подписчиков. Фирма Сisco ежегодно экономит 320 млн долл, создав центр самообслуживания заказчиков, который дает им возможность получать в режиме on-line техническую поддержку по обслуживанию оборудования, без вызова по телефону представителей обычной сервисной технической службы.

Подъем и расширение электронной информации зависят от трех ее основных компонентов:содержание, процесс и персонал. Содержание — это необработанная информация; процесс предполагает технические средства и технологии, которые обеспечивают наполнение содержания, управление его обработкой и распространением; персонал — это квалифицированные специалисты, которые способны осуществлять процесс с максимальной экономической выгодой.

Эта статья посвящена процессам и технологиям, которые будут применяться в будущем для создания электронной информации, управления ее обработкой, распространения и организации доступа к цифровому содержанию. Все эти процессы относятся к издательской деятельности, они уже успешно используются многими медиа-фирмами и газетными предприятиями, передающими электронную информацию конечным пользователям, которые раньше имели ограниченный доступ к ней. Теперь все эти процессы в целом известны как «cетевое издательское дело». В будущем каждый сможет стать сетевым издателем, и издательская деятельность будет больше направлена на расширение информации, чем на ее «проталкивание» на потребительском рынке. Пользователи сетей будут иметь возможность получать информацию по интересам и иметь доступ к ней в любое время, в любом месте и на любом периферийном выводном устройстве.

Электронная информация в издательском деле

Термин «digital content» (цифровое содержание) трактуется как электронная информация. Примерами ее в издательском деле являются электронные документы, издания, формуляры, бланки, билеты, графические и тоновые изображения, договора, видео-, аудио- и e-mail информация. Для создания электронной информации могут применяться различные типы медиа: печатные, видео, аудио, Web и другие носители.

Сетевое издательское дело — это интегрированный процесс создания электронной информации с различными формами ее представления для конечных пользователей (в печатном, видео- и аудио). Сегодня сетевой издательской деятельностью занимаются большие и малые коммерческие предприятия, центры dot-coms, учебные институты, ведомственные предприятия и частные предприниматели.

В настоящее время наметился ряд ключевых тенденций по созданию издательств нового типа. Быстрое увеличение стандартных систем обработки данных и дешевых, удобных в пользовании средств по созданию электронной информации, например, Microsoft Word, придали новое значение издательским процессам. Издательские организации и частные лица теперь получили возможность передавать свою собственную информацию с использованием таких электронных средств, как e-mail и Web-сайты. В результате, значительно возросло количество издательств, которые в целом публикуют 85 млн лицензионных копий электронной информации с использованием программного обеспечения Microsoft Office, наиболее популярного в издательском мире сегодня.

Этот количественный рост издательств нового типа привел к взрывному повышению объемов и типов электронной информации. Прогнозируется, что количество Web-страниц, которое в 2000 г. составляло 5 млрд, возрастет в 2005 г. до 40 млн, т. е. на душу населения в среднем во всем мире будет приходиться 6,5 Web-страниц (рис. 1). Сеть Internet устранила преграды на пути распространения электронной информации, связав сотни миллионов издателей и пользователей сети друг с другом.

Другой ключевой тенденцией в области электронной информации является многообразие различных новых специализированных средств для доступа в Internet, которые предъявляют особые требования к обработке данных и передаче информации в сети. Эти средства включают мобильные телефоны, персональные средства поддержки данных (PDAs — personal data assistants) и абонентские пункты электронной почты e-mail. Многообразие технологических решений и отсутствие стандартов совместимости выводных средств от различных производителей создают трудности и замешательство издателей при выборе необходимой техники.

Эти тенденции создают ряд трудностей для расширения количества сетевых издательств. Ключевыми препятствиями на пути их развития являются cледующие:

• Несовместимость различных цифровых потоков с разными типами носителей, для устранения которой требуется увеличение сетевых затрат.

• Применение ручных и неэффективных процессов для компоновки содержания и объединения фрагментов информации, полученной из разных источников.

• Значительные ресурсы, требуемые для интеграции технологических решений при выполнении издательских процессов.

• Трудности в удовлетворении требований пользователей по персонализации информации и доступу к ней в любое время, в любом месте и на любом выводном устройстве.

Эти препятствия требуют некоторых уточнений.

Во-первых, стоимость издательских процессов значительна и постоянно растет. Она поглощает 12–15% типичных корпоративных доходов, большинство этих затрат требуется на электронную информацию. В дополнение к этому, Web-сайты становятся все более комплексными, и их поддержка требует все больших расходов, так как увеличивается рост Web-страниц и все большее число конечных пользователей требуют персонализированной информации, к которой они могут иметь доступ на множественных устройствах.

Во-вторых, издателям становится все труднее поддерживать растущие требования конечных пользователей по высококачественной визуализации информации, обеспечение ее новизны в реальном времени и обеспечение доступа к ней. Поскольку увеличивается доступ к информации через широкополосные и беспроводные сети, которые обеспечивают совместимость самых различных устройств и обмен данными между ними, количество пользователей Internet будет постоянно увеличиваться. Неспособность противостоять этому росту пользователей электронной информацией через Internet и удовлетворять их возросшие требования приведет издательства к потере заказчиков и доходов.

В-третьих, доходы многих издательств продолжают снижаться. Для некоторых из них это происходит из-за неспособности создавать рентабельную электронную информацию на базе конвертирования Web-потоков, cоответствующую платежеспособности заказчиков. Для других издательств сокращение доходов происходит из-за невозможности осуществлять постоянную поддержку пользовательских Web-сайтов, чтобы затраты заказчиков при работе с ними стали меньше, чем при пользовании телефонными станциями.

Несмотря на указанные трудности, электронная информация все больше cтановится интегрирующим фактором для взаимодействия организаций и индивидуальных заказчиков, а также благоприятного развития коммерции. Поскольку все больше возрастает потребность в централизованной информации, в будущем именно электронная информация станет тем ключевым стимулом, который даст возможность компаниям активно развивать и расширять коммерцию, создаст благоприятные условия для сотрудничества между организациями, для персонализации торговли и сервисного обслуживания, целевого распространения информации. В то время, как электронная информация станет важнейшим инструментом деловой активности фирм, очень многие из них поймут ценность электронной информации и необходимость активизации издательской сферы.

Сетевые издательства — это достойный выход из противостояния конкурентам, который поможет издателям реализовать выгоды новой информационой структуры и улучшить методы расширения электронной информации с использованием Internet.

Концепция сетевых издательств

Сетевые издательства — это уникальный комплекс процессов и техники, который будет задействован для создания электронной информации, управления ею и организации доступа к ней через Internet .

В будущем издательства смогут выполнять следующие процессы в сетевом режиме:

• Создавать электронную информацию и публиковать ее в любое время, в любом месте, на любом выводном устройстве.

• Интегрировать множественные данные цифровых рабочих потоков для их большей эффективности.

• Применять более простые, интегрированные, сквозные технологические решения.

• Легко компоновать и объединять данные от множественных источников информации.

• Выполнять в реальном времени корректировку информации, что обеспечит ее актуальность, точность и достоверность.

Эффективность и гибкость работы в сети позволят снизить себестоимость издательской продукции, приведут к большему удовлетворению нужд заказчиков и станут источником новых денежных вливаний в развитие издательского бизнеса.

Для конечных пользователей сетевые издательства принесут следующие выгоды:

• Возможность доступа к богатым информационным ресурсам в интерактивном режиме с высококачественной визуализацией и озвучиванием информации.

• Доступ к информационным ресурсам в любое время, в любом месте, на любом устройстве.

• Персонализированная оплата только ценной для пользователей конкретной информации и игнорирование той, которая им не нужна.

Поскольку информация становится все более востребованной обществом и синонимом именно электронной информации, сетевые издательства будут играть ключевую роль в общей трансформации нашей жизни. Они позволят представителям издательского бизнеса получать больше доходов и нерентабельным издательским организациям стать экономически более эффективными.

СЕТЕВАЯ ИЗДАТЕЛЬСКАЯ СИСТЕМА ECOSYSTEM

Эффективность сетевой издательской деятельности не определяется работой только одного отдельно взятого издательства. Создание сетевой структуры предполагает интегрированную систему, включающую издательства, технических провайдеров (поставщиков операционных и сервисных средств) и фирм, стимулирующих интеллектуальную и финансовую поддержку сети (catalysts — катализаторы). Такая кооперация обеспечивает создание сетевой издательской системы Ecosystem с максимальным использованием потенциала и эффективности электронной информации .

Ecosystem включает профессиональные издательства, графические дизайнерские бюро, бизнес-фирмы, ведомственные издательства и потребителей. Экономические выгоды от электронной информации — решающий фактор как для традиционных издательств, так и для крупных фирм и корпораций, для которых издательская деятельность не является основной. Например, крупнейшими издателями являются такие всемирно известные международные промышленные корпорации, как IBM и General Motors, наделенные собственными издательскими правами. Участие таких крупных промышленных магнатов, с их огромными капиталами и техническими возможностями, оказывает положительное влияние на развитие Ecosystem и эффективность электронной информации.

Технические провайдеры включают компании, которые поставляют необходимую сервисную технику, программные и аппаратные средства, различные устройства, вспомогательные сервисные и программные средства инфраструктуры, обеспечивающие сетевой комплексный процесс обработки электронной информации с использованием Internet.

Внешними стимуляторами эволюции и поддержки Ecosystem являются крупные интеллектуальные и финансовые организации и частные спонсоры.

Взаимодействие всех компонентов сетевой структуры и их усиление являются залогом расширения сетевых издательств и увеличения прибыли от выпуска электронной информации.

Экономические выводы сетевых издательств

По оценке аналитиков, инвестиции на повышение эффективности работы издательств во всем мире в 2001 г. составили около 750 млрд долл. При сборе данных, их анализе и коммуникации непродуктивные затраты времени в издательствах составляют от 15 до 25%. Эти же затраты сетевых издательств составляют всего 2–3%. Следовательно, даже сегодня очевидны значительные потенциальные экономические выгоды использования сетевых издательских средств и технологий.

Экономические выгоды будут различны для издательских сегментов. Например, профессиональные издательства будут иметь возможность получать доходы от таких новых видов деятельности, как издание электронных книг (e-books) и создание сервисных служб для продажи информации по запросам. Уже имеется опыт создания таких крупных сервисных служб, как Yahoo! и iSyndicate. Кроме того, эта группа издательств сможет увеличить количество своих заказчиков за счет расширения возможностей персонализации информации. Интегрированные цифровые рабочие потоки и эффективные новые технологии позволят профессиональным издательствам снизить расходы за счет возможности повторного использования информационных данных без необходимости создавать их заново. Графические дизайнеры также увеличат выгоды за счет кросс-медиа и более тесному сетевому взаимодействию с заказчиками.

Коммерческие издательства смогут получить дополнительные доходы благодаря более быстрой доставке своей продукции на рынок, более высокой производительности и большей маркетинговой активности. Эти издательства могут также увеличить возврат своих рыночных инвестиций через более эффективное целевое распределение продукции на рынках и активное участие в корпоративных маркетинговых программах. Более того, издательская сеть снижает затраты на организацию обслуживания заказчиков за счет свободного доступа к электронной информации и уменьшения времени на ее поиск по запросу конечного пользователя.

Ведомственные сетевые издательства также могут иметь определенные выгоды. Например, издательства университетов могут получать новые доходы за счет эффективного распределения ценной научной информации и умения правильно распорядиться интеллектуальным капиталом. Cетевые издательства способствуют улучшению продуктивности учебной работы факультетов, так как могут обеспечивать профессорско-преподавательский состав любой необходимой научной информацией в реальном времени. Факультеты могут и сами воспользоваться издательскими правами и продавать через Internet свой интеллектуальный капитал потребителям и коллегам во всем мире.

И наконец, свои выгоды может получить и потребитель за счет комфорта обслуживания, экономии времени и связи с другими партнерами. Потребители могут иметь быстрый доступ к персонализированной электронной информации в любое время и в любом месте. Это позволит им тратить меньше времени на просмотр информации и больше на ее практическое применение. Более того, потребители могут быстрее принимать практические решения, так как имеют возможность в реальном времени получать необходимые им сообщения. Например, индивидуальные инвесторы могут уменьшить траты инвестиций, получив доступ к релевантной информации в реальном времени и использовать ее для принятия собственных оптимальных инвестиционных решений.

Раздел 2. Структура информационно-логической модели ИС.

Структура раздела

Построение информационно-логической модели

Информационные объекты

Выделение информационных объектов предметной области

Информационный анализ и определение логической структуры информации

Связи информационных объектов

Тип связи информационных объектов

Определение связей между информационными объектами

Информационно-логическая модель предметной области

Математические модели процессов функционирования информационных систем

Методы построения математических моделей ИС на ЭВМ и их применение в ИС

Описание предлагаемого комплекса моделей

Модель процессов представления информации в условиях ненадежности программно-технических средств

Модель процессов массового обслуживания запросов на получение информации в системе

Модель процессов отражения в базе данных новых объектов учета предметной области

Модель процесса визуального контроля информации, вводимой в базу данных (БД)

Модель процесса возникновения и устранения случайных ошибок со стороны пользователей и обслуживающего персонала

Модель процессов сбора информации от источников

Сети Петри

Теория сетей Петри

Простые сети Петри

Цветные сети Петри

Построение информационно-логической модели

Информационно-логическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов (ИО) и связей между ними. Эта модель представляет данные, подлежащие хранению в базе данных. Каждый информационный объект в модели данных должен иметь уникальное имя.

Информационные объекты

Информационный объект — это информационное описание некоторой сущности предметной области; реального объекта, процесса, явления или события. Информационный объект является совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности. Примерами сущностей являются: товар, поставщик, заказчик, поставка, отгрузка, сотрудник, отдел, студент, преподаватель, кафедра и т.п.

Информационный объект имеет множество реализаций - экземпляров объекта. Например, каждый экземпляр информационного объекта товар содержит значения реквизитов по товару определенного наименования. Экземпляр объекта должен однозначно определяться среди всего множества экземпляров, т.е. идентифицироваться значением уникального (первичного) ключа информационного объекта. Уникальность ключа означает, что любое значение ключа не может повториться в каком-либо другом; экземпляре объекта. Простои ключ состоит из одного реквизита. Составной ключ — из нескольких реквизитов. Таким образом, реквизиты информационного объекта подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.

Информационные объекты могут быть выделены на основе описания предметной: области путем определения функциональных зависимостей между реквизитами предметной области. Функциональная зависимость реквизитов информационного объекта устанавливает соответствие значений ключевых (определяющих) и неключевых (определяемых) реквизитов.

Необходимость установления функциональных зависимостей связана с требованием баз данных по однозначной определяемости любых данных для их размещения и доступа к ним. Например, для однозначной и полной определяемости реквизита количество в поставке товара, нужно указать, что поставляется, т.е. товар (его идентификатор), нужно указать, кем поставляется, т.е. поставщика (его идентификатор). Если возможны поставки одного товара поставщиком в разные сроки, то нужно также указать, когда осуществляется поставка, т.е. принять срок поставки как определяющий поставщику. Если не будет выявлена полная функциональная зависимость, количество поставки останется не определенным однозначно.

Например, если в функциональных зависимостях количества поставки не определен срок поставки, то нельзя отличить друг от друга несколько поставок одного и того же товара одним и тем же поставщиком, но в разные сроки. В этом случае имеет место неполная идентификация поставки на этапе проектирования. После реализации проекта это приведет к возможности загрузки в базу данных сведений о количестве только по одной поставке (первой введенной), т.к. для одного товара и одного поставщика, может быть введено одно значение количества поставляемого. Наглядная иллюстрация этой ситуации, когда срок поставки не указан как ключевой (определяющий поставку), представлена в табл 1.

Таблица 1. Пример идентификации поставок товаров

Реквизит Код товара Код поставщика Срок поставки Количество поставки Результат в БД

Роль в функциональной зависимости ключевой ключевой зависимый

Идентификатор поставки

Поставка 1 Т1 П1 февраль 10 Введена

Поставка 2 Т1 П1 апрель 20 Не введена

При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества), поскольку устанавливается только функциональная зависимость, определяющая логические связи описательных и ключевых реквизитов.

При графическом изображении модели данных каждый информационный объект представляется прямоугольником с обозначением его имени и идентификатора — ключа. Пример такого изображения для информационных объектов ТОВАР и ПОСТАВКА показан на рис 1, Здесь, КОД_Т (код товара) — простой ключ объекта ТОВАР, а КОДТ + КПОСТ (код поставщика) + СРОКП (срок поставки) — составной ключ объекта ПОСТАВКА.

Рис. 1. Пример графического изображения информационных объектов с простым и составным ключами

Реквизиты каждого информационного объекта канонической модели данных должны отвечать требованиям, соответствующим третьей нормальной форме реляционной модели данных:

• информационный объект должен содержать уникальный идентификатор — ключ;

• все описательные реквизиты должны быть взаимонезависимы, т.е. между ними не должно быть функциональных зависимостей;

• все реквизиты, входящие в составной ключ, также должны быть взаимонезависимы;

• каждый описательный реквизит должен функционально, полно зависеть от ключа, т. е. каждому значению ключа должно соответствовать только одно значение описательного реквизита, а при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;

• каждый описательный реквизит должен зависеть от ключа нетранзитивно, т.е. не должен зависеть через другой промежуточный реквизит.

В случае транзитивной зависимости между реквизитами информационного объекта можно выполнить расщепление совокупности реквизитов с образованием двух информационных объектов вместо одного.

Выполнение требований нормализации обеспечивает построение канонической модели данных и создание та ее основе реляционной базы данных без дублирования описательных данных, а также возможность автоматического поддержания связной целостности данных средствами СУБД при обновлении базы данных — добавлении и удалении записей, изменении значений в ключевых полях.

Выделение информационных объектов предметной области

Процесс выделения информационных объектов предметной области, отвечающих требованиям нормализации, может производиться на основе интуитивного или формального (аналитического) подхода. При интуитивном подходе сразу легко могут быть установлены информационные объекты, соответствующие реальным объектам. Однако получаемая при этом информационно-логическая модель, как правило, требует дальнейших преобразований, в частности, преобразования много-многозначных связей между объектами. При отсутствии достаточного опыта использования такого подхода возможны существенные ошибки. Последующая проверка выполнения требований нормализации обычно показывает необходимость уточнения структуры информационных объектов.

Теоретические основы аналитического подхода были разработаны и полно изложены известным американским ученым Дж. Мартином в его монографиях по организации баз данных.

При аналитическом подходе в ходе исследования предметной области сначала необходимо выявить совокупность данных и различных сведений об объектах и процессах, характеризующих данную область, перечень документов, содержащих эти данные, а также комплекс задач и запросов, которые предполагается реализовать. Таким образом, определению структуры базы данных предшествует выявление информационных потребностей. Основным источником данных являются справочные, плановые и оперативно-учетные документы.

На основе исследования составляется описание предметной области и документов, данные из которых нужно разместить в базе.

Далее выполняется информационный анализ предметной области с целью формализации и моделирования данных. Такая формализация необходима для их организации и обработки данных во внутримашинной сфере. При этом должен быть произведен семантический анализ данных и на его основе выявлены информационные объекты и логические взаимосвязи. В результате данные будут структурированы.

Информационный анализ и определение логической структуры информации

Информационный анализ включает:

• структурирование информации предметной области;

• формализацию и моделирование данных.

Структура информации внемашинной сферы находит отражение в ее представлении отдельными структурными единицами — реквизитами, их группировке в документах-источниках и упорядочении по классификационным признакам.

Структурирование информации. Организационно-экономическая информация, которая, как правило, размещается в базах данных, имеет дискретный характер, и поэтому может быть структурирована, т.е. представлена как совокупность отдельных структурных единиц информации. Определим важнейшие виды структурных единиц информации:

реквизит — простейшая структурная единица информации, неделимая на смысловом уровне, отражающая количественную или качественную характеристику сущности (объекта, процесса и т.п.) предметной области.

Можно выделить реквизиты-признаки и реквизиты-основания:

• реквизит-признак позволяет выделить (идентифицировать) объект из (множества однотипных объектов (как правило, символьное представление);

• реквизит-основание содержит количественную характеристику объекта, процесса или другой сущности, определяющую, их состояние: (как правило, числовое значение).

Например, в плане поставок товаров реквизиты-признаки идентифицируют поставку, а реквизиты-основания определяют количество поставляемого товара, его стоимость;

Составная единица информации (СЕИ) — логически взаимосвязанная совокупность реквизитов.

Документ является примером составной единицы информации. Семантика и размещение реквизитов в форме документа определяют роль реквизитов в структуре информации, содержащейся в документе.

В процессе информационного семантического (смыслового) анализа нужно выявить функциональную зависимость реквизитов и определить реквизитный состав информационных объектов.

Для минимизации возможных ошибок целесообразно производить семантический анализ по каждой из форм документов в отдельности. Это. связано с тем, что форма внемашинного документа уже отображает структуру данных, т.к. любой документ объединяет логически взаимосвязанные реквизиты

Функциональную зависимость реквизитов можно изобразить графически в виде линий со стрелками, идущих от ключевого (определяющего) реквизита к описательному реквизиту (определяемому). Ключевой реквизит обычно отмечается особо. Функциональную зависимость удобно; отображать непосредственно в таблице, где представлен состав реквизитов каждого документа. Это показано на примере реквизитов документа "Справочник товаров" (рис 2), где каждый из описательных реквизитов однозначно определяется ключевым реквизитом Код товара.

Наименование реквизита Имя реквизита Функциональные зависимости

Код товара KODT

Наименование NAIM

Цена за единицу CENA

Единица измерения EI

Рис. 2. Функциональная зависимость реквизитов документа "Справочник товаров"

Правила выделения информационных объектов

На основе описания предметной области необходимо выявить документы-источники и их реквизиты, подлежащие хранению в базе данных. Затем надо перейти к информационному анализу этих документов для выявления информационных объектов.

Рассмотрим формальные правила, которые могут быть использованы для выделения информационных объектов, отвечающих указанным ранее требованиям нормализации.

Определяются функциональные зависимости между реквизитами документа.

Для этого анализируется роль реквизитов в структуре информации документа. Сначала целесообразно выявить реквизит (один или несколько), который выполняет роль общего идентификатора всей информации документа. Как правило, к таким реквизитам относятся номер документа, идентификатор подразделения (предприятия), выпускающего документ, период действия оформления документа и т.п. От такого идентификатора документа будут функционально полно зависимыми некоторые описательные» реквизиты в общей части документа (например, идентификатор предприятия, документа основания). Другие реквизиты-основания в табличной части документа (например, количество товара и стоимость) будут частично функционально зависимыми от него.

Все справочные реквизиты реальных объектов (товаров, предприятий, Подразделений и т.п.), как в общей, так и в табличной части функционально полно определяются идентификаторами этих объектов. В результате для каждого определяемого реквизита должны быть выявлены реквизиты (ключевые), которые в совокупности однозначно его определяют (одному значению ключа соответствует одно значение описательного реквизита).

Для графического отображения функциональной зависимости проводится линия связи со стрелкой к зависимому реквизиту от определяющего его реквизита.

В результате просмотра выявленных функциональных зависимостей выбираются все зависимые реквизиты и для каждого из них устанавливаются все его ключевые реквизиты, т.е. те (один или несколько), которые в совокупности определяют его однозначно.

Такое соответствие описательных и ключевых реквизитов удобно представить в таблице, форма которой с примером заполнения представлена в табл 2.

Таблица 2. Соответствие описательных и ключевых реквизитов

Описательные (зависисмые) реквизиты Ключевые реквизиты Признак ключа Имя ИО, включающего реквизиты

Количество поставки Код товара

Код поставщика

Срок поставки Уникальный составной ПОСТАВКА

Наименование товара Код товара Уникальный простой ТОВАР

Наименование поставщика Код поставщика Уникальный простой ПОКУПАТЕЛЬ

Группируются реквизиты, одинаково зависимые от ключевых реквизитов. Полученные группы зависимых реквизитов вместе с их ключевыми реквизитами образуют реквизитный состав соответствующих информационных объектов. Если в группе несколько ключевых реквизитов, то они являются составным ключом информационного объекта.

При использовании приведенных правил не требуется отдельно преобразовывать транзитивные зависимости реквизитов. При такой зависимости некоторые реквизиты являются одновременно зависимыми и ключевыми и соответственно будут представлены в группе зависимых и ключевых.

После выделения информационных объектов необходимо сформировать их окончательное описание. В таком описании кроме состава реквизитов и указания ключа может быть представлена также семантика информационных объектов — их смысловое определение.

Как правило, при использовании приведенных правил сразу оказываются выделенными объекты, выполняющие роль связки между объектами, находящимися в отношении многие-ко-многим (М:М). Соответственно, в модели можно ограничиться рассмотрением только одно-многозначных связей.

Совокупность выделенных информационных объектов после определения связей между объектами позволяет получить информационно-логическую модель, не требующую дальнейших преобразований для создания реляционной базы данных, отвечающей требованиям нормализации.

Выделение информационных объектов на примере предметной области "Поставка товаров"

Рассмотрим выделение информационных объектов на примере предметной области "Поставка товаров".

Связи информационных объектов

Следующим шагом проектирования после выявления информационных объектов является определение связей между ними. Связь устанавливается между двумя информационными объектами. Наличие связи, как правило, определяется природой реальных объектов, процессов или явлений, отображаемых этими информационными объектами. Связь между объектами существует, если логически взаимосвязаны экземпляры этих информационных объектов. Например, связи имеются между такими парами объектов, как поставщик — товар, склад — товар, кафедра — преподаватель, группа — студент и т.п.

Тип связи информационных объектов

Связи информационных объектов могут быть разного типа:

• одно-однозначные (1:1);

• одно-многозначные (1:М);

• много-многозначные (M:N).

Одно-однозначные связи имеют место, когда каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В), и наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А). Следует заметить, что такие объекты легко могут быть объединены в один, структура которого образуется объединением реквизитов обоих исходных объектов, а ключевым реквизитом может быть выбран любой из альтернативных ключей, т.е. ключей исходных объектов. Графическое изображение одно-однозначной связи приведено на рис.3. Примерами одно-однозначных связей являются пары вида: группа—староста, фирма — расчетный счет в банке и т.п.

Рис. 3. Графическое изображение одно-однозначных отношений объектов

Одно-многозначные связи (1:М) — это такие связи, когда каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может соответствовать только один экземпляр первого объекта (А). Графическое изображение одно-многозначной связи приведено на рис.4.

Рис.4. Графическое изображение одно-многозначных отношений объектов

В такой связи объект А является главным, а объект В — подчиненным, т.е. имеет место иерархическая подчиненность объекта В объекту А. Простейшими примерами одно-многозначных связей объектов являются пары вида: подразделения — сотрудники, кафедра — преподаватель, группа — студент и т.п.

Много-многозначные связи (M:N) — это такие связи, когда каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В), и наоборот, каждому экземпляру второго объекта (В) могут соответствовать несколько экземпляров первого объекта (А). Графическое изображение связи типа M:N показано на рис.5.

Рис. 5. Графическое изображение много-многозначных отношений объектов

Много-многозначные связи не могут непосредственно реализовываться в реляционной базе данных. Поэтому в том случае, когда будут выявлены, такие связи, может возникнуть необходимость их преобразования путем введения дополнительного объекта "связка". Исходные объекты будут, связаны с этим объектом одно-многозначными связями. Таким образом, объект-связка является подчиненным в одно-многозначных связях по отношению к каждому из исходных объектов (рис.6).

Рис. 6. Преобразование связи типа М:N с помощью объекта-связки

Объект-связка должен иметь идентификатор, образованный из идентификаторов исходных объектов Ка и Кb (см. рис. 6).

При рассмотренном подходе к выделению информационных объектов объект-связка, как правило, выявляется в результате анализа функциональных зависимостей реквизитов. Много-многозначные связи в этом случае не требуют специальной реализации, т.к. осуществляются через объект, выполняющий роль объекта-связки.

Примером много-многозначных связей является пара вида поставщики-товары, если один поставщик поставляет разные наименования товаров, а товар одного наименования может поставляться несколькими поставщиками.

Определение связей между информационными объектами

Определение связей между информационными объектами и типа отношений, которыми они характеризуются, рассмотрим на примере предметной области "Поставка товаров".

Связи между объектами ПОКУПАТЕЛЬ ДОГОВОР характеризуются одно-многозначными отношениями (1:М), т.к. с одним покупателем может быть заключено несколько договоров, а один договор всегда заключается с конкретным покупателем.

Поскольку накладные строго привязаны к конкретному договору, а по одному договору может быть оформлено несколько накладных, между объектами ДОГОВОР и НАКЛАДНАЯ имеет место связь типа 1:М.

Характерным случаем одно-многозначных связей являются связи объектов, образованные из документов с табличной частью (спецификацией). В рассматриваемой предметной области по документу "Договор" был выделен объект ДОГОВОР, соответствующий общей части документа, и объект ПОСТАВКА_ПЛАН, соответствующий строкам табличной части документа. Очевидна одно-многозначная связь между этими объектами ДОГОВОР → ПОСТАВКА_ПЛАН, поскольку в одном документе всегда содержится некоторое множество строк, а каждая строка принадлежит только одному документу.

По документу "Накладная" были выделены два объекта, между которыми также имеет место одно-многозначная связь НАКЛАДНАЯ→ ОТГРУЗКА.

Очевидно наличие связи между объектами ТОВАР → ПОСТАВКА_ПЛАН. Эту связь также определяют одно-многозначные отношения, поскольку каждый экземпляр поставки (одна из строк спецификации договора) — это данные по одному товару, а товар одного наименования может участвовать в разных плановых поставках товара (одного или разных договоров).

Аналогично устанавливается связь между объектами ТОВАР → ОТГРУЗКА, которые также находятся в одно-многозначных отношениях.

Связь между объектами СКЛАД→ НАКЛАДНАЯ может быть установлена как одно-многозначная, поскольку по условиям рассматриваемой предметной области на каждом складе выписывается некоторое множество накладных, но каждая накладная выписывается на конкретном складе.

Следует отметить, что объект ПОСТАВКА_ПЛАН фактически играет роль объекта-связки в много-многозначных отношениях объектов ДОГОВОР и ТОВАР, а объект ОТГРУЗКА играет роль объекта-связки в много-многозначных отношениях объектов НАКЛАДНАЯ и ТОВАР (рис. 7).

В табл. 2 перечислены все одно-многозначные связи между объектами и соответственно определены главные и подчиненные информационные объекты в этих связях.

Таблица 2. Связи информационных объектов

Главный объект Подчиненный объект Тип связи

ПОКУПАТЕЛЬ ДОГОВОР 1:М

ДОГОВОР ПОСТАВКА ПЛАН 1:М

НАКЛАДНАЯ ОТГРУЗКА 1:М

ТОВАР ПОСТАВКА ПЛАН 1:М

ТОВАР ОТГРУЗКА 1:М

СКЛАД НАКЛАДНАЯ 1:М

ДОГОВОР НАКЛАДНАЯ 1:М

Рис. 7. Примеры много-многозначных отношений информационных объектов

Информационно-логическая модель предметной области

На рис. 8 представлена информационно-логическая модель рассматриваемой предметной области, построенная в соответствии с выявленными информационными объектами и связями между ними.

Информационно-логическая модель приведена в каноническом виде, и объекты в ней размещены по уровням. На нулевом уровне размещаются объекты, не подчиненные никаким другим объектам. Уровень остальных объектов определяется наиболее длинным путем к объекту от нулевого уровня. Такое размещение объектов дает представление об их иерархической подчиненности, делает модель более наглядной и облегчает понимание одно-многозначных отношений между объектами.

Для определения уровня объектов на графе ИЛМ можно, условно удалив объекты нулевого уровня, найти объекты первого уровня. К объектам этого уровня следует отнести объекты, не подчиненные теперь никаким другим объектам. Аналогично определяются объекты каждого следующего уровня. При большом количестве объектов в ИЛМ аналогичные действия, выполняются на матрице смежности модели.

Рис. 8. Информационно-логическая модель предметной области "Поставка товаров"

Математические модели процессов функционирования информационных систем

Методы построения математических моделей ИС на ЭВМ и их применение в ИС

Обеспечение качества современных информационных систем (ИС) немыслимо без применения моделей, позволяющих оценивать и оптимизировать процессы сбора, хранения и обработки информации. Как правило, сегодня для каждой ИС разрабатываются свои модели, учитывающие целевое назначение и специфику функционирования системы. Существует множество аналитических моделей, позволяющих оценивать отдельные характеристики функционирования систем .

Однако, практически все ИС имеют одну общую цель – это удовлетворение потребностей пользователей в обеспечении надежного и своевременного представления полной, достоверной и конфиденциальной информации. Степень выполнения этих потребностей характеризует качество функционирования ИС с точки зрения конкретного пользователя информации. Наряду с этим, большинство ИС базируется на использовании довольно универсальных технологий сбора, хранения и обработки информации. Оба этих обстоятельства являются аргументами в пользу создания таких достаточно унифицированных моделей, которые позволяли бы по единым функциональным показателям достаточно адекватно оценивать качество функционирования ИС, сравнивать различные ИС, выявлять “узкие места” и оптимизировать процессы сбора, хранения и обработки информации.

Целью настоящей работы является создание именно таких математических моделей - достаточно адекватных, отражающих физическую суть процессов функционирования ИС, лишенных существенных аналитических ограничений и доступных в использовании широкому кругу исследователей.

Описание предлагаемого комплекса моделей

Для оценки качества и оптимизации процессов функционирования ИС предлагается комплекс математических моделей процессов сбора, хранения и обработки информации. Составными показателями качества, характеризующими потребительские свойства используемой информации в стационарном режиме функционирования ИС, являются:

• вероятность надежного представления информации при выполнении функциональной задачи (ФЗ);

• вероятность представления требуемой информации за заданное время;

• вероятность того, что в базе данных (БД) полностью отражены реальные объекты учета конкретного типа;

• вероятность отсутствия скрытых случайных ошибок в проверяемой информации;

• вероятность того, что до или за время выполнения ФЗ не возникнет скрытых случайных ошибок со стороны пользователей или обслуживающего персонала ИС;

• вероятность того, что до или за время выполнения ФЗ не произойдет скрытого вирусного воздействия и выполнение ФЗ не прервется антивирусной профилактикой;

• вероятность сохранения актуальности информации на момент ее использования;

• вероятность предотвращения несанкционированного доступа (НСД);

• вероятность сохранения конфиденциальности.

Структура комплекса предлагаемых моделей отражена на рис.1.

Основным условием математической корректности моделей является существование и независимость функций распределения (ФР), описывающих характеристики функционирования ИС. Построение моделей было основано на применении предельной теоремы для регенерирующих процессов , а также на использовании известных результатов теории массового обслуживания.

Модель процессов представления информации в условиях ненадежности программно-технических средств

Под надежностью представления запрашиваемой (выдаваемой принудительно) выходной информации понимается свойство ПТС при соблюдении эксплуатационных условий применения и технического обслуживания ИС сохранять во времени в установленных пределах значения параметров, характеризующих способность ПТС обеспечивать прием, автоматическую обработку запроса и представление (выдачу) выходной информации согласно реализованному алгоритму.

Для оценки надежности представления запрашиваемой (выдаваемой принудительно) выходной информации в ИС применяется следующая модель. В любой момент времени ПТС (с точки зрения получения информации пользователем) находятся в одном из двух чередующихся состояниях: работоспособном и неработоспособном. Среднее время пребывания ПТС в работоспособном состоянии равно средней наработке на отказ. Среднее время пребывания ПТС в неработоспособном состоянии равно среднему времени восстановления работоспособного состояния ИС.

В случайный момент времени пользователь направляет запрос на представление выходного документа (поступает команда на принудительную выдачу выходной информации). Возможны три варианта:

• запрос, поступивший в процессе сеанса в момент времени t функционирования ПТС, застает ИС в работоспособном состоянии и ИС находится в этом состоянии все время, необходимое для представления требуемого документа (обработки запроса);

• запрос, поступивший в процессе сеанса в момент времени t функционирования ПТС, застает ИС в работоспособном состоянии, но ИС находится в этом состоянии менее времени, необходимого для представления требуемого документа (обработки запроса);

• запрос, поступивший в процессе сеанса в момент времени t функционирования ПТС, застает ИС в неработоспособном состоянии.

В первом случае происходит надежное представление информации, а во втором и третьем случаях происходит непредставление запрошенной информации.

Полученные в ходе проведения испытаний оценки средней наработки на отказ, среднего времени восстановления и среднего времени представления документа (времени реакции системы на запрос), являются исходными данными для проведения расчетов надежности представления запрашиваемой в течении сеанса (выдаваемой принудительно) выходной информации в ИС. Вся запрашиваемая (выдаваемая принудительно) информация разбивается на типы. Тип информации определяется конкретной формой выходного документа, в которой он может быть представлен. Описание модели приведено на рис.2.

Модель процессов массового обслуживания запросов на получение информации в системе

Получение выходной информации в системе осуществляется по запросам, требующим для своей обработки определенное время. Обработка запроса заключается в выполнении функциональных задач (ФЗ). В результате конкуренции различных запросов за информационные и программные ресурсы ИС (от пользователей, во исполнение технологических операций или автоматического приема информации, поступающей по каналам связи и др.) могут возникать очереди. Запросы из очереди обслуживаются согласно принятой технологии обработки. Когда подходит очередь обработки запроса, подключается требуемая к выполнению функциональная задача. Моментом окончания обработки запроса является представление запрашиваемого (выдаваемого принудительно) выходного документа. При этом, под временем обработки запроса может пониматься не только время, необходимое для получения одного выходного документа, но и время, необходимое для получения по запросу совокупности нескольких выходных документов.

Для оценки своевременности представления запрашиваемой (выдаваемой принудительно) выходной информации в ИС широко используются модели массового обслуживания, иллюстративно представленные на рис.3. Процессы обработки запросов в ИС формируются как процессы массового обслуживания в приоритетной системе с бесконечным числом мест для ожидания и произвольной функцией распределения времени обработки запросов (M/G/1/? ).

При этом предположение о пуассоновости потоков заявок на обработку в систему может быть обосновано тем, что среди потоков типа Пальма пуассоновский поток ставит систему обслуживания в наиболее жесткие условия функционирования и для показателей времени ожидания запросов в очередях дает верхние оценки. Более того, потоки запросов одного типа представляют собой, как правило, сумму большого числа потоков от различных источников. Интенсивность каждого из слагаемых потоков мала по сравнению с интенсивностью суммарного потока - в такой ситуации действует предельная теорема В.Григолиониса о сходимости сумм ступенчатых процессов к пуассоновскому, согласно которой суммарный поток сходится к пуассоновскому. Все приведенные соображения, а также результаты статистических исследований, проводимые в ходе испытаний информационных систем, свидетельствуют о возможности использования допущения о пуассоновости потоков заявок на обслуживание.

Предположение о бесконечности числа мест для ожидания означает на практике выделение для хранения запросов, входной и выходной информации таких объемов памяти буферов и базы данных, которые при правильной эксплуатации гарантируют отсутствие информационных потерь в системе вследствие их возможного переполнения. Поскольку в последние годы прослеживается весьма устойчивая тенденция к существенному увеличению объемов оперативной и внешней памяти и ее удешевлению в современных средствах электронно-вычислительной техники, проблемы с недостатком памяти возникают все реже, и в ближайшем будущем, по-видимому, перестанут вызывать практические затруднения. С учетом изложенного введенное предположение о бесконечности числа мест для ожидания в системе представляется вполне обоснованным. Описание модели приведено на рис.3.

Модель процессов отражения в базе данных новых объектов учета предметной области

Под полнотой отражения в БД реально существующих объектов учета предметной области понимается свойство ИС отражать в процессе функционирования состояние всех объектов учета, предусматриваемых в запросе пользователя ИС на получение выходного документа. В процессе эксплуатации неполнота может возникнуть как результат временной задержки в отражении в БД новых (вновь появившихся объектов учета с момента их появления в реальности и до момента физической записи в БД).

Для проведения оценки используется следующая модель отражения в БД ИС объектов учета предметной области.

Поскольку БД является формальным отражением наличия и состояния реально существующих объектов учета предметной области, сопоставления входных и выходных форм документов позволяет выявить те объекты учета, которые являются ключевыми в выходных документах и информация о состоянии которых подлежит функциональному использованию в соответствии с целевым назначением ИС. Все множество таких объектов учета конечно, а их номенклатура либо задается классификаторами (продукции, услуг, и др.), либо определяется заказчиками или пользователями ИС в техническом задании и постановках функциональных задач.

Реальное наполнение БД записями о реально существующих объектах учета на момент испытаний может:

a) охватить все возможные объекты учета, существующие в реальности, и, как следствие, констатируется факт полного отражения объектов учета предметной области в БД ИС;

b) охватить лишь часть реально существующих объектов учета, а первоначальные записи об остальных объектах потенциально могут появляться в процессе дальнейшего функционирования ИС или в отдельные периоды функционирования ИС. В этом случае при появлении новых объектов учета до осуществления формальных записей о них в БД ИС будет иметь место неполнота отражения реально существующих объектов учета предметной области в БД, и, если таких объектов в оцениваемый период функционирования ИС достаточно много, а доведение информации о них от источников до БД занимает длительное время, то неполнота БД может привести к неучету ряда реальных факторов и, вследствие этого, к снижению качества функционирования ИС.

Степень полноты отражения в БД ИС объектов учета предметной области оценивается вероятностными показателями с использованием модели массового обслуживания. При этом реальный закон появления новых объектов учета аппроксимируется пуассоновским законом, что позволяет получать пессимистические оценки полноты отражения информации в БД ИС. Оценка осуществляется в приложении к конкретному периоду функционирования ИС и конкретным типам форм входных документов.

Описание приведено на рис.4.

Модель процесса визуального контроля информации, вводимой в базу данных (БД)

Типовая технология подготовки и контроля входной информации в ИС отражена на рис.6.

В процессе визуального контроля выделяется период сохранения концентрации внимания должностного лица (на протяжении которого полагаются выявленными все ошибки в проверенных данных) и период утомления, когда первая же наличествующая во входном документе ошибка оказывается пропущенной; последующие ошибки при утомлении также могут оказаться пропущенными. Предполагается, что все выявленные ошибки исправляются верным образом. Кроме того, могут быть заданы ограничения на допустимое время контроля документа, что свойственно для систем реального времени. В общем случае периоды сохранения концентрации внимания и утомления определяются квалификацией (физическое состояние должностного лица полагается нормальным). Должностное лицо, осуществляющее набор информации(т.е. отвечающее за ее синтаксический аспект), может выступать в качестве контролера и лица, готовящего или принимающего решение (т.е. отвечающего за семантический аспект информации).

Тип формализованных документов определяется их формой.

Рис.6. Типовая технология подготовки и контроля входной информации в ИС.

В качестве исходных параметров оцениваемой технологии выступают:

a) уровень квалификации должностных лиц ИС, характеризующийся скоростью подготовки информации (в т.ч. набора на клавиатуре символов) и частотой допускаемых при этом ошибок, скоростью просмотра информации при визуальном контроле;

b) время непрерывной работы должностных лиц при визуальном контроле в соответствии с проверяемой технологией и объемом информации, предназначенной для ввода в БД или ограничения на допустимое время контроля.

Описание предлагаемой модели отражено на рис.7.

Модель процесса возникновения и устранения случайных ошибок со стороны пользователей и обслуживающего персонала

В процессе работы пользователи и обслуживающий персонал ИС в силу ограниченности физических возможностей человека способны допускать ошибки, влияющие на доступность и целостность информационных и программных средств (ИПР). Эти ошибки могут быть явными и скрытыми.

Явные ошибки проявляются сразу после их допущения (например, это может проявляться в отказе программно-технических средств вследствие ошибки, в блокировке доступа к ИПР или в других событиях, нарушающих надежность и своевременность представления информации), и тут же подлежат устранению. Степень защищенности ИПР от явных ошибок должностных лиц может быть методически оценена с использованием предложенных в части 1 статьи модели процессов представления информации в условиях ненадежности программно-технических средств и модели процессов массового обслуживания запросов на получение информации в системе. Скрытые ошибки не выявляются сразу, они приводят к скрытому в течении некоторого времени нештатному режиму функционирования ИС и могут нарушать доступность и целостность ИПР. Предлагаемая ниже модель позволяет оценивать отсутствие именно скрытых ошибок в зависимости от ряда характеристик моделируемого процесса.

В любой момент времени ИПР (с точки зрения пользователя) находятся в одном из двух чередующихся состояний: “отсутствия скрытых искажений” или “наличия скрытых искажений”, допущенных пользователями или обслуживающим персоналом. Соответственно при соблюдении прочих условий штатного режима функционирования ИС первое состояние является условием безошибочного выполнения функциональных задач (ФЗ), а второе состояние приводит к возможному невыполнению или неверному результату выполнения ФЗ.

Возможны три варианта соотношения между моментами возникновения и обнаружения скрытой ошибки и времени обработки:

a) запрос пользователя, поступивший в момент t при отсутствии скрытых ошибок, застиг ИПР в состоянии “отсутствия скрытых искажений” и за время обработки запроса не произошло такого рода искажений. В этом случае информация представляется пользователю в неискаженном виде;

b) за время обработки запроса, заставшего в момент t ИПР в неискаженном виде, произошло скрытое искажение, в этом случае на момент завершения решения ФЗ и получения пользователем выходной информации состояние ИПР определяется состоянием “наличия скрытых искажений” и пользователю выдается искаженная информация или нарушается нормальный доступ к ИС (в зависимости от характера допущенной ошибки);

c) запрос в момент t застиг ИПР уже в искаженном состоянии и, соответственно, в ответ на запрос пользователь получает также искаженную информацию ил же не получает доступа к ИС.

Полагается, что сразу по выявлении скрытой ошибки все подозреваемые на наличие ошибок ИПР подвергаются технологическому контролю на целостность, после чего устраняются все выявленные ошибки.

В качестве исходных параметров проверяемой технологии обеспечения защищенности ИПР от случайных ошибок пользователей и обслуживающего персонала выступают:

a) способы и периодичность контроля состояния ИПР для обеспечения их доступности и целостности;

b) уровень квалификации пользователей и обслуживающего персонала, характеризующихся средним временем между совершением ими скрытых ошибок, а также средним временем до обнаружения нарушенного состояния доступности и целостности ИПР; среднее время выполнения задач пользователями.

Модель процессов сбора информации от источников

На источниках информации происходят изменения состояния объектов учета, которые должны отражаться в БД путем соответствующего изменения в ней характеристик состояния указанных объектов. В соответствии с принятой в ИС дисциплиной сбора входной информации обновляемые данные от источников заносятся в базу данных.

Возможны следующие дисциплины сбора информации:

• “по регламенту”, когда информация собирается от источников и заносится в БД через постоянный период времени, установленный для ИС регламентом;

• сразу “по изменении состояния объекта учета”, когда информация поставляется от источников сразу после значимого изменения состояния одного или нескольких отслеживаемых объектов учета;

• “независимо от состояния объектов учета”, если информация от источников собирается не “по регламенту” и не сразу “по изменении состояния объекта учета”.

В промежутке времени между изменением состояния объекта учета и занесением этих изменений в БД соответствующая выходная информация ИС считается недостаточно актуальной, если ее отличие от реальной превышает допустимые пределы, определяемые функциональным назначением этой выходной информации (т.е., если в реальности произошли значимые изменения, и они не отражены в БД). Неактуальная БД является угрозой целостности информации в ИС. Оценка степени актуальности выходной информации, сформированной на основе использования БД ИС должна осуществляться в приложении к конкретному периоду функционирования ИС и конкретным типам форм входных документов, на основании которых формируется БД.

Описание предлагаемой модели отражено на рис. 9

Примечание. В рис.2 части 1 данной статьи не по вине редакции в выражение для оценки надежности представления запрашиваемой информации Рнад. вкралась неточность. Следует читать: “Вероятность надежного представления информации при выполнении ФЗ:

где N(t) - ФР времени наработки ПТС на отказ, n - МОЖ;

W(t) - ФР времени восстановления ПТС, w - МОЖ;

V(t) - ФР времени выполнения рассматриваемой ФЗ, v - МОЖ;

* - знак свертки.

В частном случае, когда ФР N(t),W(t), V(t)- экспоненциальные:

Сети Петри

Сети Петри – инструмент исследования систем. В настоящее время сети Петри применяются в основном в моделировании. Во многих областях исследований явление изучается не непосредственно, а косвенно, через модель. Модель – это представление, как правило, в математических терминах того, что считается наиболее характерным в изучаемом объекте или системе. Манипулируя моделью системы, можно получить новые знания о ней, избегая опасности, дороговизну или неудобства анализа самой реальной системы. Обычно модели имеют математическую основу.

Развитие теории сетей Петри проводилось по двум направлениям. Формальная теория сетей Петри занимается разработкой основных средств, методов и понятий, необходимых для применения сетей Петри. Прикладная теория сетей Петри связана главным образом с применением сетей Петри к моделированию систем, их анализу и получающимся в результате этого глубоким проникновением в моделируемые системы.

Моделирование в сетях Петри осуществляется на событийном уровне. Определяются, какие действия происходят в системе, какие состояние предшествовали этим действиям и какие состояния примет система после выполнения действия. Выполнения событийной модели в сетях Петри описывает поведение системы. Анализ результатов выполнения может сказать о том, в каких состояниях пребывала или не пребывала система, какие состояния в принципе не достижимы. Однако, такой анализ не дает числовых характеристик, определяющих состояние системы. Развитие теории сетей Петри привело к появлению, так называемых, “цветных” сетей Петри. Понятие цветности в них тесно связано с понятиями переменных, типов данных, условий и других конструкций, более приближенных к языкам программирования. Несмотря на некоторые сходства между цветными сетями Петри и программами, они еще не применялись в качестве языка программирования.

Не смотря на описанные выше достоинства сетей Петри, неудобства применения сетей Петри в качестве языка программирования заключены в процессе их выполнения в вычислительной системе. В сетях Петри нет строго понятия процесса, который можно было бы выполнять на указанном процессоре. Нет также однозначной последовательности исполнения сети Петри, так как исходная теория представляет нам язык для описания параллельных процессов.

Наилучшими возможностями описания параллельных систем обладают сети Петри. Они не менее мощные, чем PVM, MPI, SDL и другие, но чтобы их выполнять на процессорах необходимо сделать из описания параллельного распределенное.

Сеть первого рода - это цветная сеть Петри, описанная на языке предписаний.

Сеть второго рода - это сеть, представленная в виде иерархической композиции объектов.

Теория сетей Петри

Теория сетей Петри является хорошо известным и популярным формализмом, предназначенным для работы с параллельными и асинхронными системами. Основанная в начале 60-х годов немецким математиком К.А.Петри, в настоящее время она содержит большое количество моделей, методов и средств анализа, имеющих обширное количество приложений практически во всех отраслях вычислительной техники и даже вне ее.

Данный раздел содержит систему понятий, определений и обозначений, которые непосредственно потребуются в последствии.

Простые сети Петри

Сеть Петри из трех элементов: множество мест , множество переходов и отношение инцидентности .

Определение: Простая сеть Петри

• • Простой сетью Петри называется набор , где

1. - множество мест;

2. - множество переходов таких, что .

3. - отношение инцидентности такое, что

(а) ; (б) Условия в пункте 3 говорят, что для каждого перехода существует единственный элемент , задающий для него входное мультимножество мест и выходное мультимножество . Дадим определение входному и выходному мультимножеству.

Определение: Входное и выходное мультимножества мест и переходов

• • Пусть задана сеть .

1. Если для некоторого перехода имеем , то будем обозначать ;

2. .

Будем говорить, что - входные, а - выходные места перехода . Таким образом, согласно определению, справедливо . Далее будем говорить, что место инцидентно переходу если или .

Расширим функции и на мультимножества переходов. Пусть есть мультимножество переходов такое, что . Тогда положим

. Сети Петри имеют удобную графическую форму представления в виде графа, в котором места изображаются кружками, а переходы прямоугольниками. Места и переходы, причем место соединяется с переходом если и соеднияется с если для некоторого натурального числа . Здесь число называется кратностью дуги, которое графически изображается рядом с дугой. Дуги, имеющие единичную кратность, будут обозначаться без приписывания единицы.

Пример. Пример сети

• • В качестве простого примера расссмотрим сеть , где

1. ; 2. ; 3.

В графической форме сеть представлена на Рис.1. Сеть имеет четыре места и три перехода. Отношение задает дуги сети. Так, например, элемент задает четыре дуги: из в и из в с кратностями 2, из в и из в с единичными кратностями. Для перехода справедливо и . Для места можно вычислить и .

Рис. 1: Пример графа сети Петри

Само по себе понятие сети имеет статическую природу. Для задания динамических характеристик используется понятие маркировки сети , т.е. функции , сопоставляющей каждому месту целое число. Графически маркировка изображается в виде точек, называемых метками (tokens), и располагающихся в кружках, соответствующих местам сети. Отсутствие меток в некотором месте говорит о нулевой маркировке этого места.

Определение: Маркированная сеть Петри

• • Маркированной сетью Петри называется набор , где

1. - сеть;

2. - начальная маркировка.

Пример. Пример маркированной сети.

• • На Рис.2 приведен пример маркированной сети. В начальной маркировке место имеет две метки (токена), место - одну метку, а места , - ни одной метки, т.е. .

Рис. 2: Пример маркированной сети Петри

Сети Петри были разработаны и используются для моделирования параллельных и асинхронных систем. При моделировании в сетях Петри места символизируют какое-либо состояние системы, а переход символизируют какие-то действия, происходящие в системе. Система, находясь в каком-то состоянии, может порождать определенные действия, и наоборот, выполнение какого-то действия переводит систему из одного состояния в другое.

Текущее состояние системы определяет маркировка сети Петри, т.е. расположение меток (токенов) в местах сети. Выполнение действия в системе, в сетях Петри определяется как срабатывание переходов. Срабатывание переходов порождает новую маркировку, т.е. порождает новое размещение меток (токенов) в сети. Определим функционирование маркированных сетей, основанное на срабатывании отдельных переходов.

Определение: Правило срабатывания переходов

Пусть маркированная сеть.

1. Переход считается возбужденным при маркировке , если ;

2. Переход , возбужденный при маркировке , может сработать, приведя к новой маркировке , которая вычисляется по правилу: . Срабатывание перехода обозначается как .

Иными словами, переход считается возбужденным при некоторой маркировке, если в каждом его входном месте имеется количество меток не менее кратности соответствующих дуг. Возбужденный переход может сработать, причем при срабатывании из каждого его входного места изымается, а в каждое входное добавляется некоторое количество меток, равное кратности соответствующих дуг. Если одновременно возбуждено несколько переходов, сработать может любой из них или любая их комбинация. Например, пусть в сети на рисунке 2 сработают переходы и . Получим сеть представленную на рисунке 3.

Рис. 3: Новая сеть с маркировкой .

Композициональный подход к построению сетей Петри предполагает возможность построения более сложных сетей из менее сложных составляющих. Для этого вводятся точки доступа, которые позволяют объединять простые сети путём синхронизации событий и состояний (переходов и мест).

Определение: Определение T-точки доступа.

Пусть задана сеть и некоторый алфавит . Т-точкой доступа называется набор , где

1. - имя (идентификатор) t-точки доступа;

2. - некоторый алфавит;

3. - пометочная функция, где . Запись обозначает множество всех конечных и непустых мультимножеств, определённых на множестве .

Определение: Определение S-точки доступа

Пусть задана сеть . Тогда s-точкой доступа сети N называется набор , где

1. - имя (идентификатор) s-точки доступа;

2. - множество такое, что .

Введённые понятия точек доступа предоставляют возможность ввести две основные операции над сетями Петри для построения композициональных сетей:

1. Операция слияния переходов - позволяет порождать и описывать синхронизацию параллельных процессов (tmerge);

2. Операция слияния мест - позволяет применять к сетям операции последовательной композиции, выбора, итерации и другие (smerge).

Рис. 4: Пример операции слияния переходов

Рис. 5: Пример операции слияния мест

Приведённые операции имеют следующий смысл:

При слиянии мест - определяется набор состояний в сети, которые идентифицируются, как состояние сети, определённое именем s-точки доступа. Слияние различных сетей производится так, что если в одной сети достигнуто описанное состояние, то в другой сети это состояние также получается достигнутым;

При слиянии переходов – определяется алфавит событий, видимых из t-точки доступа. Каждый переход в сети помечается либо невидимым событием, либо комбинацией событий из алфавита точки доступа. Слияние по переходам производится так, что если при срабатывании одной сети возникает некоторая комбинация событий, то эта же комбинация событий происходит во второй сети.

Цветные сети Петри

Расширение простых сетей в цветные заключается в добавлении информации к элементам сети, основываясь на которой, при определённых условиях, можно преобразовать цветные сети в простые ([8]).

1. Токены вместо простого обозначения содержимого места преобразуются в объект, который может содержать в себе один или более параметров, каждый из которых может принимать дискретный набор значений. В соответствии с этим токены различаются по типам параметров (переменных). Чтобы отличать токены различных типов их можно окрашивать в различные цвета (поэтому сети называют цветными)

2. К местам добавляется информация о типах токенов, которые могут находится в данном месте.

3. К дугам, исходящим из мест, добавляется информация о типах токенов, которые могут участвовать в возбуждении переходов, инцидентных этим дугам.

4. К переходам может быть добавлена информация с предикатом возбуждения перехода, в зависимости от переменных, содержащихся в токенах.

( and )

5. К дугам, исходящим из переходов, добавляется информация о типах токенов, исходящих из перехода и о преобразовании переменных.

6. К начальной маркировке сети добавляется информация о значении переменных, содержащихся в токенах.

В графическом представлении информацию, которую можно однозначно достроить из сопутствующей информации, можно пропускать. Приведем пример цветной сети Петри (Рис. 6)

Рис. 6: Пример цветной сети Петри (очередь)

На первый взгляд кажется, что представление цветной сети выглядит так, что каждая из дуг, выходящая из перехода, содержит некоторое действие. В действительности же, при преобразовании цветной сети в простую, все действия переходят в структуру сети. Это достигается разбиением мест и переходов на количество равное декартову произведению множества всех значений всех типов данных, соответствующих этим местам и переходам. При этом все переменные в сети получаются уже заданными и вместо дуг цветной сети рисуются дуги, соединяющие места и переходы, согласно своим “цветным” описаниям.

В описании цветных сетей нет принципиального ограничения на используемые переменные. Тем не менее, преобразование цветной сети в простую возможно только тогда, когда все переменные имеют дискретный спектр значений.

Точки доступа в цветной сети

S-точка доступа. Как видно из определения s-точки доступа, она задаётся множеством маркировок, которые считаются эквивалентными в смысле наступления состояний, определённых этими маркировками, в синхронизируемых по s-точке доступа сетях. При задании s-точки доступа в цветной сети, маркировки могут содержать в себе места, в которые могут поступать токены различных типов. Такие места при преобразовании в простую сеть разбиваются на множество мест, количество которых равно мощности множества значений токенов допустимых в этом месте. Согласно смыслу операции мы обязаны будем в синхронизированной сети раздробить эти места, чтобы удовлетворить множеству значений токенов во второй сети. Получается, что при синхронизации мест одинакового типа (с одинаковыми допустимыми типами токенов) значение параметров одной сети никак не влияет на значение параметров другой, то есть смысл операции в цветных и простых сетях может пониматься по-разному. Чтобы этого избежать, надо доопределить s-точку доступа:

Определение:

Пусть заданы: цветная сеть N и С – множество типов токенов в этой сети. Тогда s-точкой доступа сети N называется набор , где

1. - имя (идентификатор) s-точки доступа;

2. - некоторый алфавит;

3. - множество такое, что .

4. , где , причём если . - пометочная функция мест, ставящая в соответствие каждому типу токена в месте уникальное имя из алфавита.

В операции слияния цветных сетей по местам, необходимо убрать расщепление мест по токенам с определёнными именами. Фактически, это означает переопределение операции слияния по одной s-точке доступа в простых сетях в операцию слияния серии точек доступа цветных сетей, пронумерованных значениями параметров с именами. Можно показать, что изменённая таким образом операция не меняет своих свойст.

Рис. 7: Пример слияния цветных сетей Петри по S-точке доступа

T-точка доступа. При синхронизации по t-точке доступа используется информация о пометке переходов, участвующих в синхронизации. При преобразовании цветных сетей в простые, переходы расщепляются на количество, равное мощности множества значений принимаемых всеми токенами, поступающими в переход. В связи с этим возникает возможность параметризации пометки перехода выражениями, содержащими переменные поступающие в переход.

Рис. 8: Пример слияния цветных сетей по T-точке доступа

На приведённом ниже примере видно, как параметризованный переход, преобразуется в простые сети.

Рис. 9: T-Слияние простых сетей из рисунка 8.

Рис. 10: Представление композициональных сетей Петри на уровне взаимодействия сетей.

Раздел 3. Разработка функциональной модели. Исходные данные для проектирования.

Структура раздела

Структурная модель предметной области

Объектная структура

Функциональная структура

Структура управления

Организационная структура

Техническая структура

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области

Функциональная методика IDEF0

Функциональная методика потоков данных

Объектно-ориентированная методика

Сравнение существующих методик

Синтетическая методика

Информационное обеспечение ИС

Внемашинное информационное обеспечение

Внутримашинное информационное обеспечение

Структурная модель предметной области

В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.

Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области.

К моделям предметных областей предъявляются следующие требования:

• формализация, обеспечивающая однозначное описание структуры предметной области;

• понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

• реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

• обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.

Структурный аспект предполагает построение:

• объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

• функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

• структуры управления, отражающей события и правила, которые воздействуют на выполнение процессов;

• организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

• технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.

Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции.

С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения.

Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию.

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

• время решения задач;

• стоимостные затраты на обработку данных;

• надежность процессов;

• косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.

В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации.

Объектная структура

Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства.

На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.).

На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области.

Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах.

Функциональная структура

Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет процесс. Функция процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа "Заказ", который, в свою очередь, порождает документ "Накладная", сопровождающий партию отгруженного товара.

Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы, и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий.

На внешнем уровне моделирования определяется список основных функций или видов процессов.

На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций.

На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции.

Структура управления

В совокупности функций процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый процесс. Тогда последовательность событий составляет конкретную реализацию процесса.

Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций процессов.

На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.).

На концептуальном уровне устанавливаются правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов.

На внутреннем уровне выполняется формализация правил в виде триггеров или вызовов программных модулей.

Организационная структура

Организационная структура представляет собой совокупность организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или процессов. В функционально-ориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций, входящих в один тип процесса и относящихся к разным функциям управления.

На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений.

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.

Техническая структура

Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений.

На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям.

На концептуальном уровне определяется способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д.

На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети.

Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: "объекты-функции", "функции-события", "организационные единицы — функции", "организационные единицы — объекты", "организационные единицы — технические средства" и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий.

Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач.

Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – "разделяй и властвуй" и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых "черных ящиков") и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

Функция – совокупность операций, сгруппированных по определенному признаку.

Процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя.

Подпроцесс – это процесс, являющийся структурным элементом некоторого процесса и представляющий ценность для потребителя.

Модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия.

Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии.

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области

Процесс моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные).

Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.

Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

С точки зрения моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.

В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение "Управление" (Control);

• левая сторона имеет значение "Вход" (Input);

• правая сторона имеет значение "Выход" (Output);

• нижняя сторона имеет значение "Механизм" (Mechanism).

Рис.1. Функциональный блок

Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.

С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).

В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей".

Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.

Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности.

Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.

Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:

• Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

o Какие функции и в какой последовательности выполняются в рамках подразделения?

o Кто является ответственным за выполнение каждой из функций?

o Чем руководствуется исполнитель при выполнении каждой из функций?

o Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

• Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

• Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.

Функциональная методика потоков данных

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.

При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища).

Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.

Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по отгрузке продукции"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты.

Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.

Процесс построения DFD начинается с создания так называемой основной диаграммы типа "звезда", на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. В случае сложного основного процесса он сразу представляется в виде декомпозиции на ряд взаимодействующих процессов. Критериями сложности в данном случае являются: наличие большого числа внешних сущностей, многофункциональность системы, ее распределенный характер. Внешние сущности выделяются по отношению к основному процессу. Для их определения необходимо выделить поставщиков и потребителей основного процесса, т.е. все объекты, которые взаимодействуют с основным процессом. На этом этапе описание взаимодействия заключается в выборе глагола, дающего представление о том, как внешняя сущность использует основной процесс или используется им. Например, основной процесс – "учет обращений граждан", внешняя сущность – "граждане", описание взаимодействия – "подает заявления и получает ответы". Этот этап является принципиально важным, поскольку именно он определяет границы моделируемой системы.

Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы.

На следующем шаге происходит декомпозиция основного процесса на набор взаимосвязанных процессов, обменивающихся потоками данных. Сами потоки не конкретизируются, определяется лишь характер взаимодействия. Декомпозиция завершается, когда процесс становится простым, т.е.:

1. процесс имеет два-три входных и выходных потока;

2. процесс может быть описан в виде преобразования входных данных в выходные;

3. процесс может быть описан в виде последовательного алгоритма.

Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.

Миниспецификация удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные; спецификация ссылается на имеющиеся элементы, не вводя новые; спецификация по возможности использует стандартные подходы и операции.

После декомпозиции основного процесса для каждого подпроцесса строится аналогичная таблица внутренних событий.

Следующим шагом после определения полной таблицы событий выделяются потоки данных, которыми обмениваются процессы и внешние сущности. Простейший способ их выделения заключается в анализе таблиц событий. События преобразуются в потоки данных от инициатора события к запрашиваемому процессу, а реакции – в обратный поток событий. После построения входных и выходных потоков аналогичным образом строятся внутренние потоки. Для их выделения для каждого из внутренних процессов выделяются поставщики и потребители информации. Если поставщик или потребитель информации представляет процесс сохранения или запроса информации, то вводится хранилище данных, для которого данный процесс является интерфейсом.

После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены.

К преимуществам методики DFD относятся:

• возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

• возможность проектирования сверху вниз, что облегчает построение модели "как должно быть";

• наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы.

К недостаткам модели отнесем: необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных; отсутствие понятия времени, т.е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов).

Объектно-ориентированная методика

Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации функций.

Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:

• абстрагирование;

• инкапсуляция;

• модульность;

• иерархия;

• типизация;

• параллелизм;

• устойчивость.

Основными понятиями объектно-ориентированного подхода являются объект и класс.

Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.

Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования.

Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

Объектно-ориентированный подход обладает следующими преимуществам:

• Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей.

• Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем.

• Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.

К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны.

Сравнение существующих методик

В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов.

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.

При функциональном подходе объектные модели данных в виде ER-диаграмм "объект — свойство — связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.

Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться.

Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса.

Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).

В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше.

При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.

Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям.

При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области.

Синтетическая методика

Как можно видеть из представленного обзора, каждая из рассмотренных методик позволяет решить задачу построения формального описания рабочих процедур исследуемой системы. Все методики позволяют построить модель "как есть" и "как должно быть". С другой стороны, каждая из этих методик обладает существенными недостатками. Их можно суммировать следующим образом: недостатки применения отдельной методики лежат не в области описания реальных процессов, а в неполноте методического подхода.

Функциональные методики в целом лучше дают представление о существующих функциях в организации, о методах их реализации, причем чем выше степень детализации исследуемого процесса, тем лучше они позволяют описать систему. Под лучшим описанием в данном случае понимается наименьшая ошибка при попытке по полученной модели предсказать поведение реальной системы. На уровне отдельных рабочих процедур их описание практически однозначно совпадает с фактической реализацией в потоке работ.

На уровне общего описания системы функциональные методики допускают значительную степень произвола в выборе общих интерфейсов системы, ее механизмов и т.д., то есть в определении границ системы. Хорошо описать систему на этом уровне позволяет объектный подход, основанный на понятии сценария использования. Ключевым является понятие о сценарии использования как о сеансе взаимодействия действующего лица с системой, в результате которого действующее лицо получает нечто, имеющее для него ценность. Использование критерия ценности для пользователя дает возможность отбросить не имеющие значения детали потоков работ и сосредоточиться на тех функциях системы, которые оправдывают ее существование. Однако и в этом случае задача определения границ системы, выделения внешних пользователей является сложной.

Технология потоков данных, исторически возникшая первой, легко решает проблему границ системы, поскольку позволяет за счет анализа информационных потоков выделить внешние сущности и определить основной внутренний процесс. Однако отсутствие выделенных управляющих процессов, потоков и событийной ориентированности не позволяет предложить эту методику в качестве единственной.

Наилучшим способом преодоления недостатков рассмотренных методик является формирование синергетической методики, объединяющей различные этапы отдельных методик. При этом из каждой методики необходимо взять часть методологии, наиболее полно и формально изложенную, и обеспечить возможность обмена результатами на различных этапах применения синергетической методики. В бинес-моделировании неявным образом идет формирование подобной синергетической методики.

Идея синтетической методики заключается в последовательном применении функционального и объектного подхода с учетом возможности реинжиниринга существующей ситуации.

Рассмотрим применение синтетической методики на примере разработки административного регламента.

При построении административных регламентов выделяются следующие стадии:

1. Определение границ системы. На этой стадии при помощи анализа потоков данных выделяют внешние сущности и собственно моделируемую систему.

2. Выделение сценариев использования системы. На этой стадии при помощи критерия полезности строят для каждой внешней сущности набор сценариев использования системы.

3. Добавление системных сценариев использования. На этой стадии определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей.

4. Построение диаграммы активностей по сценариям использования. На этой стадии строят набор действий системы, приводящих к реализации сценариев использования;

5. Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0.

6. Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций).

Информационное обеспечение ИС

Информационное обеспечение ИС является средством для решения следующих задач:

• однозначного и экономичного представления информации в системе (на основе кодирования объектов);

• организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификации объектов);

• организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных);

• обеспечения эффективного использования информации в контуре управления деятельностью объекта автоматизации (на основе унифицированной системы документации).

Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы) и внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных).

К информационному обеспечению предъявляются следующие общие требования:

• информационное обеспечение должно быть достаточным для поддержания всех автоматизируемых функций объекта;

• для кодирования информации должны использоваться принятые у заказчика классификаторы;

• для кодирования входной и выходной информации, которая используется на высшем уровне управления, должны быть использованы классификаторы этого уровня;

• должна быть обеспечена совместимость с информационным обеспечением систем, взаимодействующих с разрабатываемой системой;

• формы документов должны отвечать требованиям корпоративных стандартов заказчика (или унифицированной системы документации);

• структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей;

• графики формирования и содержание информационных сообщений, а также используемые аббревиатуры должны быть общеприняты в этой предметной области и согласованы с заказчиком;

• в ИС должны быть предусмотрены средства контроля входной и результатной информации, обновления данных в информационных массивах, контроля целостности информационной базы, защиты от несанкционированного доступа.

Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации и информационной базы.

Внемашинное информационное обеспечение

Основные понятия классификации технико-экономической информации

Для того чтобы обеспечить эффективный поиск, обработку на ЭВМ и передачу по каналам связи технико-экономической информации, ее необходимо представить в цифровом виде. С этой целью ее нужно сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификатора.

Классификация – это разделение множества объектов на подмножества по их сходству или различию в соответствии с принятыми методами. Классификация фиксирует закономерные связи между классами объектов. Под объектом понимается любой предмет, процесс, явление материального или нематериального свойства. Система классификации позволяет сгруппировать объекты и выделить определенные классы, которые будут характеризоваться рядом общих свойств. Таким образом, совокупность правил распределения объектов множества на подмножества называется системой классификации.

Свойство или характеристика объекта классификации, которое позволяет установить его сходство или различие с другими объектами классификации, называется признаком классификации. Например, признак "роль предприятия-партнера в отношении деятельности объекта автоматизации" позволяет разделить все предприятия на две группы (на два подмножества): "поставщики" и "потребители". Множество или подмножество, объединяющее часть объектов классификации по одному или нескольким признакам, носит название классификационной группировки.

Классификатор — это документ, с помощью которого осуществляется формализованное описание информации в ИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения.

По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы.

Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества.

Общегосударственные (общесистемные) классификаторы, обязательны для организации процессов передачи и обработки информации между экономическими системами государственного уровня внутри страны.

Отраслевые классификаторы используют для выполнения процедур обработки информации и передачи ее между организациями внутри отрасли.

Локальные классификаторы используют в пределах отдельных предприятий.

Каждая система классификации характеризуется следующими свойствами:

• гибкостью системы;

• емкостью системы;

• степенью заполненности системы.

Гибкость системы — это способность допускать включение новых признаков, объектов без разрушения структуры классификатора. Необходимая гибкость определяется временем жизни системы.

Емкость системы — это наибольшее количество классификационных группировок, допускаемое в данной системе классификации.

Степень заполненности системы определяется как частное от деления фактического количества группировок на величину емкости системы.

В настоящее время чаще всего применяются два типа систем классификации: иерархическая и многоаспектная.

При использовании иерархического метода классификации происходит "последовательное разделение множества объектов на подчиненные, зависимые классификационные группировки". Получаемая на основе этого процесса классификационная схема имеет иерархическую структуру. В ней первоначальный объем классифицируемых объектов разбивается на подмножества по какому-либо признаку и детализируется на каждой следующей ступени классификации. Обобщенное изображение иерархической классификационной схемы представлено на рис. 1.

Рис. 1. Иерархическая классификационная схема

Характерными особенностями иерархической системы являются:

• возможность использования неограниченного количества признаков классификации;

• соподчиненность признаков классификации, что выражается разбиением каждой классификационной группировки, образованной по одному признаку, на множество классификационных группировок по нижестоящему (подчиненному) признаку.

Таким образом, классификационные схемы, построенные на основе иерархического принципа, имеют неограниченную емкость, величина которой зависит от глубины классификации (числа ступеней деления) и количества объектов классификации, которое можно расположить на каждой ступени. Количество же объектов на каждой ступени классификации определяется основанием кода, то есть числом знаков в выбранном алфавите кода. (Например, если алфавит – двузначные десятичные цифры, то можно на одном уровне разместить 100 объектов). Выбор необходимой глубины классификации и структуры кода зависит от характера объектов классификации и характера задач, для решения которых предназначен классификатор.

При построении иерархической системы классификации сначала выделяется некоторое множество объектов, подлежащее классифицированию, для которого определяются полное множество признаков классификации и их соподчиненность друг другу, затем производится разбиение исходного множества объектов на классификационные группировки на каждой ступени классификации.

К положительным сторонам данной системы следует отнести логичность, простоту ее построения и удобство логической и арифметической обработки.

Серьезным недостатком иерархического метода классификации является жесткость классификационной схемы. Она обусловлена заранее установленным выбором признаков классификации и порядком их использования по ступеням классификации. Это ведет к тому, что при изменении состава объектов классификации, их характеристик или характера решаемых при помощи классификатора задач требуется коренная переработка классификационной схемы. Гибкость этой системы обеспечивается только за счет ввода большой избыточности в ветвях, что приводит к слабой заполненности структуры классификатора. Поэтому при разработке классификаторов следует учитывать, что иерархический метод классификации более предпочтителен для объектов с относительно стабильными признаками и для решения стабильного комплекса задач.

Примеры применения иерархической классификации объектов в корпоративной ИС приведены на рис 2 и 3. Использование приведенных моделей позволяет выполнить кодирование информации о соответствующих объектах, а также использовать процедуры обобщения при обработке данных (при анализе затрат на заработную плату — по принадлежности работника к определенной службе, при анализе затрат на производство — по группам материалов: по металлу, по покупным комплектующим и пр.).

Рис. 2. Организационная структура подразделения предприятия-цеха отгрузки

Рис. 3. Классификатор материальных ресурсов для обеспечения производства

Недостатки, отмеченные в иерархической системе, отсутствуют в других системах, которые относятся к классу многоаспектных систем классификации.

Аспект — точка зрения на объект классификации, который характеризуется одним или несколькими признаками. Многоаспектная система — это система классификации, которая использует параллельно несколько независимых признаков (аспектов) в качестве основания классификации. Существуют два типа многоаспектных систем: фасетная и дескрипторная. Фасет — это аспект классификации, который используется для образования независимых классификационных группировок. Дескриптор — ключевое слово, определяющее некоторое понятие, которое формирует описание объекта и дает принадлежность этого объекта к классу, группе и т.д.

Под фасетным методом классификации понимается "параллельное разделение множества объектов на независимые классификационные группировки". При этом методе классификации заранее жесткой классификационной схемы и конечных группировок не создается. Разрабатывается лишь система таблиц признаков объектов классификации, называемых фасетами. При необходимости создания классификационной группировки для решения конкретной задачи осуществляется выборка необходимых признаков из фасетов и их объединение в определенной последовательности. Общий вид фасетной классификационной схемы представлен на рис 4.

Рис. 4. Схема признаков фасетной классификации

Внутри фасета значения признаков могут просто перечисляться по некоторому порядку или образовывать сложную иерархическую структуру, если существует соподчиненность выделенных признаков.

К преимуществам данной системы следует отнести большую емкость системы и высокую степень гибкости, поскольку при необходимости можно вводить дополнительные фасеты и изменять их место в формуле. При изменении характера задач или характеристик объектов классификации разрабатываются новые фасеты или дополняются новыми признаками уже существующие фасеты без коренной перестройки структуры всего классификатора.

К недостаткам, характерным для данной системы, можно отнести сложность структуры и низкую степень заполненности системы.

В современных классификационных схемах часто одновременно используются оба метода классификации. Это снижает влияние недостатков методов классификации и расширяет возможность использования классификаторов в информационном обеспечении управления.

В качестве примера использования комбинированных схем классификации в корпоративных ИС можно привести следующую модель описания продукции предприятия.

Правила классификации продукции

Принята классификация выпускаемой продукции по следующему ряду уровней (Иерархическая классификация):

• семейство продуктов;

• группа продуктов;

• серия продуктов.

Однако эта система классификации не обеспечивает идентификацию любого выпускаемого изделия. Для каждой единицы продукта должны указываться следующие атрибуты (Фасеты):

• код серии продукта;

• конфигурационные параметры;

• свойства.

Код серии продукта – алфавитно-цифровой код, однозначно идентифицирующий отдельный продукт. Конфигурационные параметры – свойства, значения которых могут быть различными в зависимости от потребностей пользователей. Свойства – предопределенные характеристики отдельных продуктов, которые не могут меняться для одного и того же продукта.

Признаки фасета "Конфигурационные параметры" для одного семейства продуктов приведены в таблице 1.

Рассмотренные выше системы классификации хорошо приспособлены для организации поиска с целью последующей логической и арифметической обработки информации на ЭВМ, но лишь частично решают проблему содержательного поиска информации при принятии управленческих решений.

Таблица 1. Признаки фасета "Конфигурационные параметры" для одного семейства продуктов

Продукты и модификации Характеристики

Общие для семейства Специальные для отдельных моделей

Датчики разности давлений • Искробезопасное исполнение

• Взрывозащищенное исполнение

• Исполнение по материалам

• Климатическое исполнение

• Предел допускаемой основной погрешности

• Верхний предел измерений

• Код выходного сигнала

• Состав комплекта монтажных частей • Предельно допустимое рабочее избыточное давление

Датчики абсолютного давления, избыточного давления, разрежения, давления-разрежения • Измеряемый параметр

Для поиска показателей и документов по набору содержательных признаков используется информационный язык дескрипторного типа, которой характеризуется совокупностью терминов (дескрипторов) и набором отношений между терминами.

Содержание документов или показателей можно достаточно полно и точно отразить с помощью списка ключевых слов — дескрипторов. Дескриптор — это термин естественного языка (слово или словосочетание), используемый при описании документов или показателей, который имеет самостоятельный смысл и неделим без изменения своего значения.

Для того чтобы обеспечить точность и однозначность поиска с помощью дескрипторного языка, необходимо предварительно определить все постоянные отношения между терминами: родовидовые, отношения синонимии, омонимии и полисемии, а также ассоциативные отношения.

Все выделенные отношения явно описываются в систематическом словаре понятий — тезаурусе, который разрабатывается с целью проведения индексирования документов, показателей и информационных запросов.

Кодирование технико-экономической информации

Для полной формализации информации недостаточно простой классификации, поэтому проводят следующую процедуру — кодирование. Кодирование — это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Система кодирования — это совокупность правил обозначения объектов и группировок с использованием кодов. Код — это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на определенном алфавите (некоторое множество знаков). Число знаков этого множества называется основанием кода. Различают следующие типы алфавитов: цифровой, буквенный и смешанный.

Код характеризуется следующими параметрами:

• длиной;

• основанием кодирования;

• структурой кода, под которой понимают распределение знаков по признакам и объектам классификации;

• степенью информативности, рассчитываемой как частное от деления общего количества признаков на длину кода;

• коэффициентом избыточности, который определяется как отношение максимального количества объектов к фактическому количеству объектов.

К методам кодирования предъявляются определенные требования:

• код должен осуществлять идентификацию объекта в пределах заданного множества объектов классификации;

• желательно предусматривать использование в качестве алфавита кода десятичных цифр и букв;

• необходимо обеспечивать по возможности минимальную длину кода и достаточный резерв незанятых позиций для кодирования новых объектов без нарушения структуры классификатора.

Методы кодирования могут носить самостоятельный характер – регистрационные методы кодирования, или быть основанными на предварительной классификации объектов – классификационные методы кодирования.

Регистрационные методы кодирования бывают двух видов: порядковый и серийно-порядковый. В первом случае кодами служат числа натурального ряда. Каждый из объектов классифицируемого множества кодируется путем присвоения ему текущего порядкового номера. Данный метод кодирования обеспечивает довольно большую долговечность классификатора при незначительной избыточности кода. Этот метод обладает наибольшей простотой, использует наиболее короткие коды и лучше обеспечивает однозначность каждого объекта классификации. Кроме того, он обеспечивает наиболее простое присвоение кодов новым объектам, появляющимся в процессе ведения классификатора. Существенным недостатком порядкового метода кодирования является отсутствие в коде какой-либо конкретной информации о свойствах объекта, а также сложность машинной обработки информации при получении итогов по группе объектов классификации с одинаковыми признаками.

В серийно-порядковом методе кодирования кодами служат числа натурального ряда с закреплением отдельных серий этих чисел (интервалов натурального ряда) за объектами классификации с одинаковыми признаками. В каждой серии, кроме кодов имеющихся объектов классификации, предусматривается определенное количество кодов для резерва.

Классификационные коды используют для отражения классификационных взаимосвязей объектов и группировок и применяются в основном для сложной логической обработки экономической информации. Группу классификационных систем кодирования можно разделить на две подгруппы в зависимости от того, какую систему классификации используют для упорядочения объектов: системы последовательного кодирования и параллельного кодирования.

Последовательные системы кодирования характеризуются тем, что они базируются на предварительной классификации по иерархической системе. Код объекта классификации образуется с использованием кодов последовательно расположенных подчиненных группировок, полученных при иерархическом методе кодирования. В этом случае код нижестоящей группировки образуется путем добавления соответствующего количества разрядов к коду вышестоящей группировки.

Параллельные системы кодирования характеризуются тем, что они строятся на основе использования фасетной системы классификации и коды группировок по фасетам формируются независимо друг от друга.

В параллельной системе кодирования возможны два варианта записи кодов объекта:

• Каждый фасет и признак внутри фасета имеют свои коды, которые включаются в состав кода объекта. Такой способ записи удобно применять тогда, когда объекты характеризуются неодинаковым набором признаков. При формировании кода какого-либо объекта берутся только необходимые признаки.

• Для определения групп объектов выделяется фиксированный набор признаков и устанавливается стабильный порядок их следования, то есть устанавливается фасетная формула. В этом случае не надо каждый раз указывать, значение какого из признаков приведено в определенных разрядах кода объекта.

Параллельный метод кодирования имеет ряд преимуществ. К достоинствам рассматриваемого метода следует отнести гибкость структуры кода, обусловленную независимостью признаков, из кодов которых строится код объекта классификации. Метод позволяет использовать при решении конкретных технико-экономических и социальных задач коды только тех признаков объектов, которые необходимы, что дает возможность работать в каждом отдельном случае с кодами небольшой длины. При этом методе кодирования можно осуществлять группировку объектов по любому сочетанию признаков. Параллельный метод кодирования хорошо приспособлен для машинной обработки информации. По конкретной кодовой комбинации легко узнать, набором каких характеристик обладает рассматриваемый объект. При этом из небольшого числа признаков можно образовать большое число кодовых комбинаций. Набор признаков при необходимости может легко пополняться присоединением кода нового признака. Это свойство параллельного метода кодирования особенно важно при решении технико-экономических задач, состав которых часто меняется.

Наиболее сложными вопросами, которые приходится решать при разработке классификатора, являются выбор методов классификации и кодирования и выбор системы признаков классификации. Основой классификатора должны быть наиболее существенные признаки классификации, соответствующие характеру решаемых с помощью классификатора задач. При этом данные признаки могут быть или соподчиненными, или несоподчиненными. При соподчиненных признаках классификации и стабильном комплексе задач, для решения которых предназначен классификатор, целесообразно использовать иерархический метод классификации, который представляет собой последовательное разделение множества объектов на подчиненные классификационные группировки. При несоподчиненных признаках классификации и при большой динамичности решаемых задач целесообразно использовать фасетный метод классификации.

Важным вопросом является также правильный выбор последовательности использования признаков классификации по ступеням классификации при иерархическом методе классификации. Критерием при этом является статистика запросов к классификатору. В соответствии с этим критерием на верхних ступенях классификации в классификаторе должны использоваться признаки, к которым будут наиболее частые запросы. По этой же причине на верхних ступенях классификации выбирают наименьшее основание кода.

Понятие унифицированной системы документации

Основной компонентой внемашинного информационного обеспечения ИС является система документации, применяемая в процессе управления экономическим объектом. Под документом понимается определенная совокупность сведений, используемая при решении технико-экономических задач, расположенная на материальном носителе в соответствии с установленной формой.

Система документации — это совокупность взаимосвязанных форм документов, регулярно используемых в процессе управления экономическим объектом. Отличительной особенностью системы экономической документации является большое разнообразие видов документов.

Существующие системы документации, характерные для неавтоматизированных ИС, отличаются большим количеством разных типов форм документов, большим объемом потоков документов и их запутанностью, дублированием информации в документах и работ по их обработке и, как следствие, низкой достоверностью получаемых результатов. Для того чтобы упростить систему документации, используют следующие два подхода:

• проведение унификации и стандартизации документов;

• введение безбумажной технологии, основанной на использовании электронных документов и новых информационных технологий их обработки.

Унификация документов выполняется путем введения единых форм документов. Таким образом, вводится единообразие в наименования показателей, единиц измерения и терминов, в результате чего получается унифицированная система документации.

Унифицированная система документации (УСД) — это рационально организованный комплекс взаимосвязанных документов, который отвечает единым правилам и требованиям и содержит информацию, необходимую для управления некоторым экономическим объектом. По уровням управления, они делятся на межотраслевые системы документации, отраслевые и системы документации локального уровня, т. е. обязательные для использования в рамках предприятий или организаций.

Любой тип УСД должен удовлетворять следующим требованиям:

• документы, входящие в состав УСД, должны разрабатываться с учетом их использования в системе взаимосвязанных ЭИС;

• УСД должна содержать полную информацию, необходимую для оптимального управления тем объектом, для которого разрабатывается эта система;

• УСД должна быть ориентирована на использование средств вычислительной техники для сбора, обработки и передачи информации;

• УСД должна обеспечить информационную совместимость ЭИС различных уровней;

• все документы, входящие в состав разрабатываемой УСД, и все реквизиты-признаки в них должны быть закодированы с использованием международных, общесистемных или локальных классификаторов.

Внутримашинное информационное обеспечение

Внутримашинное информационное обеспечение включает макеты (экранные формы) для ввода первичных данных в ЭВМ или вывода результатной информации, и структуры информационной базы: входных, выходных файлов, базы данных.

Проектирование экранных форм электронных документов

Под электронными формами документов понимается не изображение бумажного документа, а изначально электронная (безбумажная) технология работы; она предполагает появление бумажной формы только в качестве твердой копии документа.

Электронная форма документа (ЭД) — это страница с пустыми полями, оставленными для заполнения пользователем. Формы могут допускать различный тип входной информации и содержать командные кнопки, переключатели, выпадающие меню или списки для выбора.

Создание форм электронных документов требует использования специального программного обеспечения. На рис. 5 приведены основные типовые элементы электронного документа, использование которых предусмотрено в большинстве программ автоматизации проектирования электронных документов.

Рис. 5. Элементы электронного документа

К недостаткам электронных документов можно отнести неполную юридическую проработку процесса их утверждения или подписания.

Технология обработки электронных документов требует использования специализированного программного обеспечения — программ управления документооборотом, которые зачастую встраиваются в корпоративные ИС.

Проектирование форм электронных документов, т.е. создание шаблона формы с помощью программного обеспечения проектирования форм, обычно включает в себя выполнение следующих шагов:

• создание структуры ЭД — подготовка внешнего вида с помощью графических средств проектирования;

• определение содержания формы ЭД, т.е. выбор способов, которыми будут заполняться поля. Поля могут быть заполнены вручную или посредством выбора значений из какого-либо списка, меню, базы данных;

• определения перечня макетов экранных форм — по каждой задаче проектировщик анализирует "постановку" каждой задачи, в которой приводятся перечни используемых входных документов с оперативной и постоянной информацией и документов с результатной информацией;

• определение содержания макетов — выполняется на основе анализа состава реквизитов первичных документов с постоянной и оперативной информацией и результатных документов.

Работа заканчивается программированием разработанных макетов экранных форм и их апробацией.

Информационная база и способы ее организации

Основной частью внутримашннного информационного обеспечения является информационная база. Информационная база (ИБ) — это совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач.

Все файлы ИБ можно классифицировать по следующим признакам:

• по этапам обработки (входные, базовые, результатные);

• по типу носителя (на промежуточных носителях — гибких магнитных дисках и магнитных лентах и на основных носителях — жестких магнитных дисках, магнитооптических дисках и др.);

• по составу информации (файлы с оперативной информацией и файлы с постоянной информацией);

• по назначению (по типу функциональных подсистем);

• по типу логической организации (файлы с линейной и иерархической структурой записи, реляционные, табличные);

• по способу физической организации (файлы с последовательным, индексным и прямым способом доступа).

Входные файлы создаются с первичных документов для ввода данных или обновления базовых файлов.

Файлы с результатной информацией предназначаются для вывода ее на печать или передачи по каналам связи и не подлежат долговременному хранению.

К числу базовых файлов, хранящихся в информационной базе, относят основные, рабочие, промежуточные, служебные и архивные файлы.

Основные файлы должны иметь однородную структуру записей и могут содержать записи с оперативной и условно-постоянной информацией. Оперативные файлы могут создаваться на базе одного или нескольких входных файлов и отражать информацию одного или нескольких первичных документов. Файлы с условно-постоянной информацией могут содержать справочную, расценочную, табличную и другие виды информации, изменяющейся в течение года не более чем на 40%, а следовательно, имеющие коэффициент стабильности не менее 0,6.

Файлы со справочной информацией должны отражать все характеристики элементов материального производства (материалы, сырье, основные фонды, трудовые ресурсы и т.п.). Как правило, справочники содержат информацию классификаторов и дополнительные сведения об элементах Материальной сферы, например о ценах. Нормативно-расценочные файлы должны содержать данные о нормах расхода и расценках на выполнение операций и услуг. Табличные файлы содержат сведения об экономических показателях, считающихся постоянными в течение длительного времени (например, процент удержания, отчисления и пр.). Плановые файлы содержат плановые показатели, хранящиеся весь плановый период.

Рабочие файлы создаются для решения конкретных задач на базе основных файлов путем выборки части информации из нескольких основных файлов с целью сокращения времени обработки данных.

Промежуточные файлы отличаются от рабочих файлов тем, что они образуются в результате решения экономических задач, подвергаются хранению с целью дальнейшего использования для решения других задач. Эти файлы, так же как и рабочие файлы, при высокой частоте обращений могут быть также переведены в категорию основных файлов.

Служебные файлы предназначаются для ускорения поиска информации в основных файлах и включают в себя справочники, индексные файлы и каталоги.

Архивные файлы содержат ретроспективные данные из основных файлов, которые используются для решения аналитических, например прогнозных, задач. Архивные данные могут также использоваться для восстановления информационной базы при разрушениях.

Организация хранения файлов в информационной базе должна отвечать следующим требованиям:

• полнота хранимой информации для выполнения всех функций управления и решения экономических задач;

• целостность хранимой информации, т. е. обеспечение непротиворечивости данных при вводе информации в ИБ;

• своевременность и одновременность обновления данных во всех копиях данных;

• гибкость системы, т.е. адаптируемость ИБ к изменяющимся информационным потребностям;

• реализуемость системы, обеспечивающая требуемую степень сложности структуры ИБ;

• релевантность ИБ, под которой подразумевается способность системы осуществлять поиск и выдавать информацию, точно соответствующую запросам пользователей;

• удобство языкового интерфейса, позволяющее быстро формулировать запрос к ИБ;

• разграничение прав доступа, т.е. определение для каждого пользователя доступных типов записей, полей, файлов и видов операций над ними.

Существуют следующие способы организации ИБ: совокупность локальных файлов, поддерживаемых функциональными пакетами прикладных программ, и интегрированная база данных, основывающаяся на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, т.е. системы управления базами данных (СУБД).

Локальные файлы вследствие специализации структуры данных под задачи обеспечивают, как правило, более быстрое время обработки данных. Однако недостатки организации локальных файлов, связанные с большим дублированием данных в информационной системе и, как следствие, несогласованностью данных в разных приложениях, а также негибкостью доступа к информации, перекрывают указанные преимущества. Поэтому организация локальных файлов может применяться только в специализированных приложениях, требующих очень высокой скорости реакции при импорте необходимых данных.

Интегрированная ИБ, т.е. база данных (БД) — это совокупность взаимосвязанных, хранящихся вместе данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для множества приложений.

Централизация управления данными с помощью СУБД обеспечивает совместимость этих данных, уменьшение синтаксической и семантической избыточности, соответствие данных реальному состоянию объекта, разделение хранения данных между пользователями и возможность подключения новых пользователей. Но централизация управления и интеграция данных приводят к проблемам другого характера: необходимости усиления контроля вводимых данных, необходимости обеспечения соглашения между пользователями по поводу состава и структуры данных, разграничения доступа и секретности данных.

Основными способами организации БД являются создание централизованных и распределенных БД. Основным критерием выбора способа организации ИБ является достижение минимальных трудовых и стоимостных затрат на проектирование структуры ИБ, программного обеспечения системы ведения файлов, а также на перепроектирование ИБ при возникновении новых задач.

Раздел 4. Разработка модели и защита данных. Пользовательский интерфейс. Проект распределенной обработки.

Структура раздела

Устройства ввода-вывода информации

Устройства ввода данных

Устройства вывода информации

Требования к техническим средствам, поддерживающим ИС

Аппаратные средства сетей

Типовые структуры

Организации и их структуры

Типовые структуры организационных систем (ОС)

Сетевые структуры организационных систем (ОС)

Свойства типовых структур организационных систем (ОС)

Моделирование данных

Базовые понятия ERD

Метод IDEFI

Защита данных

Аудит информационной защиты компании

Создание системы защиты периметра локальной сети

Разработка пользовательского интерфейса

Разработка эффективных форм

Проектирование форм ввода данных

Работа с несколькими формами

Эффективные меню

Ощущение скорости

Организация распределенных ИС на основе вычислительных сетей

Устройства ввода-вывода информации

Человек взаимодействует с информационными системами главным образом через устройства ввода-вывода (input-output devices). Прогресс в области информационных технологий достигается не только благодаря возрастающей скорости процессоров и емкости запоминающих устройств, но также за счет совершенствования устройств ввода и вывода данных. Устройства ввода-вывода называются также периферийными устройствами (peripheral devices).

Устройства ввода данных

Клавиатура

Клавиатура (keyboard) – традиционное устройство ввода данных в компьютер. Клавиатурами оснащены как персональные компьютеры, так и терминалы мэйнфреймов. Клавиатура современного компьютера содержит обычно 101 или 102 клавиши, разделенные на 4 блока:

• алфавитно-цифровой блок – содержит клавиши латинского и национального алфавитов, а также клавиши цифр и специальных символов;

• блок управляющих клавиш;

• блок расширенной цифровой клавиатуры;

• блок навигации.

Компьютерная мышь

Мышь (mouse) была разработана довольно давно (в 60-х годах), но стала широко использоваться только с приходом в мир персональных компьютеров графического пользовательского интерфейса. Обычно мышь, как и клавиатура, подключается к компьютеру с помощью кабеля. Пользоваться мышью легко – вы передвигаете ее по столу, а на экране компьютера синхронно перемещается курсор. Чтобы активизировать некоторую опцию, нужно щелкнуть левой (left) клавишей мыши. С помощью мыши можно также "рисовать" на экране картинки.

Сенсорные экраны

Сенсорные экраны (touch screens) предназначены для тех, кто не может пользоваться обычной клавиатурой. Пользователь может ввести символ или команду прикосновением пальца к определенной области экрана. Сенсорные экраны используются в основном на сладах продукции, в ресторанах, супермаркетах. К примеру, в магазинах Muse Inc. (Бруклин), продающей компакт-диски, можно прослушать желаемую композицию, прикоснувшись пальцем к ее названию на экране компьютера. Слушая выбранную мелодию, вы можете одним прикосновением вызвать список других композиций исполнителя.

Устройства автоматизированного ввода информации

Устройства этого типа считывают информацию с носителя, где она уже имеется. Примерами таких систем могут служить кассовые терминалы, сканеры штрих-кодов и другие системы оптического распознавания символов. Одно из преимуществ устройств автоматизированного ввода данных состоит в том, что при их использовании исключаются некоторые ошибки, неизбежные при вводе информации с клавиатуры. Сканер штрих-кодов делает менее чем одну ошибку на 10000 операций, в то время как обученный наборщик ошибается один раз при вводе каждых 1000 строк.

Основные вида устройств автоматизированного ввода информации – системы распознавания магнитных знаков, системы оптического распознавания символов, системы ввода информации на базе светового пера, сканеры, системы распознавания речи, сенсорные датчики и устройства видеозахвата.

Системы распознавания магнитных знаков (Magnetic Inc Character Recognition, MICR) используются в основном в банковской сфере. В нижней части обычного банковского чека находится код, нанесенный специальными магнитными чернилами. В коде содержится номер банка, номер расчетного счета и номер чека. Система считывает информацию, преобразовывает ее в цифровую форму и передает в банк для обработки.

Системы оптического распознавания символов (Optical Character Recognition, OCR) преобразуют специальным образом нанесенную на носитель информацию в цифровую форму. Наиболее широко используемые устройства этого типа – сканеры штрих-кодов (bar-code scanners), которые применяются в кассовых терминалах магазинов. Эти системы используются также в больницах, библиотеках, на военных объектах, складах продукции и в компаниях по перевозке грузов. В дополнение к данным, идентифицирующим предмет, на который нанесен штрих-код, последний может содержать информацию о времени, дате и физическом положении предмета; таким образом, можно, например, отслеживать передвижение груза.

Ручные устройства распознавания информации, такие как перьевые планшеты, особенно полезны для людей, работающих в сферах сбыта продукции и сервиса – такие работники избегают "общения" с клавиатурой. Устройства перьевого ввода обычно содержат плоский экран и световое перо, похожее на шариковую ручку. Перьевые планшеты преобразуют буквы и цифры, написанные пользователем на экране, в цифровую форму, и передают эти данные в компьютер для обработки. Например, United Parcel Service (UPS), известнейшая в мире компания по доставке грузов, заменила обычные планшеты с листками бумаги, использовавшиеся водителями, на портативные перьевые планшеты. Эти устройства используются для подтверждения заказов, и передачи другой информации, необходимой для погрузки и доставки грузов. К недостаткам систем данного вида следует отнести недостаточную точность распознавания информации, написанной от руки.

Сканеры (scanners) преобразуют в цифровую форму графическую информацию (рисунки, чертежи и пр.) и большие объемы текстовой информации. Системы распознавания речи (voice input devices) преобразуют в цифровую форму произносимые пользователем слова. Существует два режима работы подобных устройств. В режиме управления (command mode) вы произносите команды (такие как "открыть документ", "запустить программу" и т.д.), которые выполняются компьютером. В режиме диктовки (dictation mode) можно надиктовывать компьютеру любой текст. К сожалению, точность распознавания речи таких систем оставляет желать лучшего. Человеческий голос имеет множество оттенков, на точность распознавания может повлиять интонация, громкость речь, окружающий шум, даже банальный насморк. Тем не менее, работа над совершенствованием этих устройств ввода информации продолжается и, несомненно, у них большое будущее. Некоторые отделения Почтовой службы США используют системы распознавания речи для повышения эффективности труда работников, занятых упаковкой и сортировкой почтовых грузов. Вместо того чтобы вводить ZIP-код, работник произносит его, в то время как его руки заняты упаковкой.

Сенсорные датчики (sensors) – это устройства для ввода в компьютер пространственной информации. Например, корпорация General Motors использует сенсоры в своих легковых автомобилях для передачи в бортовой компьютер машины данных об окружающем пространстве и маршруте. Сенсорные датчики также нашли применение в системах виртуальной реальности, игровых приставках и симуляторах.

Устройства видеозахвата (video capture devices) представляют собой небольшие цифровые видеокамеры, соединенные с компьютером. Устройства видеозахвата применяются в основном в системах видеоконференций, которые получают все большее распространение. Благодаря развитию локальных сетей и Интернет, появилась возможность организовывать видеоконференцсвязь, находясь в любой точке планеты.

Устройства вывода информации

Основные устройства вывода информации – мониторы и принтеры.

Мониторы

Мониторы (monitors) – наиболее популярные устройства отображения информации. Основа большинства современных мониторов – электронно-лучевая трубка, ЭЛТ (cathode ray tube, CRT). По принципу работы ЭЛТ напоминают кинескопы, используемые в обычных телевизорах – электронная пушка испускает пучок электронов, высвечивающих на экране картинку, состоящую из точек (pixels). Чем больше точек может вместить экран, тем выше разрешение (resolution) монитора. Большинство мониторов поддерживают режимы разрешения 800x600 и 1024x768 точек. Кроме разрешения, мониторы характеризуются следующими параметрами, определяющими качество изображения:

• размер зерна (dot size), дюйм (inch) – физический размер одной точки экрана монитора. Чем меньше размер зерна, тем выше качество изображения. Большинство мониторов бизнес-класса имеют размер зерна, равный 0.28 дюйма;

• размер ЭЛТ по диагонали (CRT size), дюйм (inch). Еще недавно стандартом был размер ЭЛТ 14 дюймов, но сейчас в сфере бизнеса применяют мониторы с размерами ЭЛТ 15, 17, 19 и 21 дюйм;

• частота развертки (refresh frequency), Гц (Hz) – частота смены кадров. Чем выше частота развертки, тем меньше устают глаза пользователя. Относительно безопасной является частота развертки от 85 Гц и выше.

Принтеры

Принтеры (printers) выполняют печать информации на бумаге или пленке (результат, получаемый при печати, называют твердой копией [hard copy]).

Принтеры бывают матричные (dot matrix), струйные (inkjet), лазерные (laser) и термографические (thermal transfer). К последним относятся сублимационные и твердочернильные. Большинство принтеров печатают от 2 до 8 страниц в минуту. Линейно-матричные принтеры могут печатать до 20000 строк в минуту.

Основные характеристики принтеров:

• разрешение (print resolution) – количество точек на один квадратный дюйм. Чем выше разрешение, тем качественнее печать. Матричные принтеры обеспечивают сравнительно низкое разрешение – от 80 до 200 точек на кв. дюйм; струйные – до 720, лазерные – до 1200, термографические – от 1200 до 5000 точек на кв. дюйм;

• скорость печати (print speed), страниц в минуту (ppm). Скорость печати варьируется от 2 ppm у матричных принтеров до 4-6 ppm у струйных и 4-8 ppm у лазерных. Мощные лазерные и термографические принтеры способны выводить на печать до 100 страниц в минуту;

• поддержка цветной печати (color print) – очень важное свойство для тех, кто занимается компьютерной графикой и дизайном. Также очень удобно пользоваться цветными принтерами при печати графиков и диаграмм. В качестве устройств цветной печати используются в основном струйные принтеры. Возможности цветной печати есть и у других типов принтеров. Однако, матричные цветные принтеры неудобны в управлении и не обеспечивают приемлемое качество печати. Лазерные и термографические принтеры способны обеспечить высочайшее качество изображения, но эти печатающие устройства пока слишком дороги для применения в бизнесе.

Другие устройства вывода информации

Высококачественные графические документы могут быть созданы при использовании графопостроителей (plotters). Графопостроители оснащаются набором перьев, в который входят рапидографы для рисования линий разной толщины и разного цвета. Плоттеры несколько медленнее принтеров, зато позволяют получать документы больших размеров – чертежи, карты, схемы.

Системы синтеза человеческого голоса (voice output devices) используются в современном программном обеспечении в основном для поддержки людей с ослабленным слухом или зрением. Такая система способна произносить содержимое экрана, преобразуя текстовую информацию в человеческую речь.

Требования к техническим средствам, поддерживающим ИС

Естественно, что требования к техническим средствам определяются требованиями к информационной системе в целом. Какие бы информационные возможности не требовались сотрудникам корпорации, окончательное решение всегда принимается ее руководством, которое корректирует требования к информационной системе и формирует окончательное представление об аппаратной среде. Существует три варианта.

Первый вариант Нужно выбрать самое дешевое решение, которое может быть реализовано максимально быстро. При такой позиции наиболее подходящим является некоторое закрытое и законченное техническое решение. Например, это может быть полностью сбалансированная локальная сеть Novell с выделенным файл-сервером и фиксированным числом рабочих станций. Жесткость решения затем закрепляется соответствующим программным обеспечением информационной системы. Возможности расширения системы отсутствуют, реинжиниринг требует практически полной переделки системы.

Второй вариант – при невысокой (около 20%) возможности дальнейшего развития ИС. В этом случае больше всего подходит закрытое решение, обладающее ограниченными возможностями расширения. Например, это может быть локальная сеть Novell, в которой пропускная способность превосходит потребности имеющихся рабочих станций, а файл-сервер может быть оснащен дополнительными магнитными дисками. Но в этом случае при необходимости модифицировать систему неизбежно появится потребность сложного реинжиниринга.

В третьем случае, при высокой вероятности модификации ИС, может быть сделана установка на использование только Intel-платформ в среде Microsoft или только Alpha-платформ с VAX/VMS. Однородность аппаратно-программной среды существенно облегчает ее администрирование.

При желании сохранить возможность использования различных аппаратных платформ. следует стимулировать построение открытой корпоративной информационной системы, которая может неограниченно наращиваться за счет подключения новых сегментов сети, включения новых серверов и рабочих станций. Этот подход подход, естественно, требует применения международных стандартов, что облегчает комплексирование аппаратного комплекса и обеспечивает реальное масштабирование информационной системы. Если начать построение системы с сети Ethernet с использованием стека протоколов TCP/IP, то это начало оптимального решения. В этом случае проблемы реинжиниринга практически отсутствуют (пока не сменятся стандарты).

Главный вывод этого раздела состоит в том, что выбор технических средств для построения информационной системы - это непростая задача, включающая технические, политические и эмоциональные аспекты. Ни в коем случае комплексирование аппаратуры нельзя пускать на самотек. Простой пример. Многие считают, что чем больше тактовая частота аппаратного сервера баз данных, то тем быстрее будет работать СУБД. Вообще говоря, это неправильно. Быстродействие любого сервера баз данных в основном определяется объемом основной памяти и/или числом процессоров. Другими словами, с одинаковой тщательностью нужно относиться и к выбору общей аппаратной архитектуры системы, и к выбору конфигурации каждого из ее компонентов.

Аппаратные средства сетей

Хост-компьютеры (серверы). Хост-компьютер имеет собственный уникальный адрес в сети и выполняет роль узловой машины, обслуживающей абонентов. В качестве хост-компьютеров используются разные типы машин: от мощных ПК до мини-ЭВМ и даже мэйнфреймов (больших ЭВМ). Основные требования — высокоскоростной процессор и большой объем дисковой памяти (десятки и сотни Гбайт). На хост-компьютерах в сети Internet используется операционная система Unix. Все сервер-программы, обслуживающие приложения, работают под управлением Unix.

Из того о чем уже говорилось выше, следует, что понятие «сервер» носит программно-аппаратный смысл. Например, хост-компьютер, на котором в данный момент работает сервер-программа электронной почты, выполняет роль почтового сервера. Если на этой же машине начинает работать сервер-программа WWW, то она становится Web-сервером. Часто функции серверов различных услуг разделены на узле сети между разными компьютерами.

Линии связи. Основные типы линий связи между компьютерами сети: телефонные линии, электрические кабели, оптоволоконный кабель и радиосвязь. Главными параметрами линий связи являются пропускная способность (максимальная скорость передачи информации), помехоустойчивость, стоимость. По параметру стоимости самыми дорогими являются оптоволоконные линии, самыми дешевыми — телефонные. Однако с уменьшением цены уменьшается и качество работы линии. В табл. 1 даны сравнительные характеристики линий по параметрам скорости и помехоустойчивости.

Таблица 1.Характеристики линий связи

Тип связи Скорость, Мбит/с Помехоустойчивость

Витая пара проводов 10-100 Низкая

Коаксиальный кабель До 10 Высокая

Телефонная линия 1-2 Низкая

Оптоволоконный кабель 10-200 Абсолютная

Чаще всего для связи между хост-компьютерами используются выделенные телефонные линии или радиосвязь. Если узлы сети расположены сравнительно недалеко друг от друга (в пределах города), то связь между ними может быть организована по ка-бельным линиям — электрическим или оптоволоконным. В последнее время в сети Internet активно используется спутниковая радиосвязь.

Обычно абоненты (клиенты) подключаются к узлу своего провайдера через телефонную линию. Все чаще для этих целей начинает применяться радиосвязь.

Для передачи информации по каналам связи необходимо преобразовывать ее из той формы, в которой она существует в компьютере, в сигналы, передаваемые по линиям связи. Такие преобразования осуществляют специальные устройства, которые называются сетевыми адаптерами. Существуют адаптеры для кабельной, для оптоволоконной связи. Адаптер вставляется в свободное гнездо материнской платы и соединяется кабелем с адаптером другого компьютера. Так обычно делается в локальных сетях.

В глобальных сетях, связанных по телефонным линиям, в качестве устройства сопряжения используются модемы. Назначение модема состоит в преобразовании информации из двоичного компьютерного кода в телефонный сигнал и обратно. Помимо этого, модем выполняет еще ряд функций. Например, модем клиента сети должен дозваниваться до узла, к которому он подключается. Основной характеристикой модема является предельная скорость передачи данных. В настоящее время она колеблется от 1200 бит/с до 112 000 бит/с. Однако реальная скорость зависит не только от модема, но и от качества телефонных линий. В российских городских сетях приемлемая скорость передачи невелика и составляет 2400—14400 бит/с. В будущем, когда произойдет полный переход телефонных линий на цифровую связь, потребность в использовании модемов исчезнет.

Типовые структуры

Организации и их структуры

В соответствии с определением, организация –

1. внутренняя упорядоченность, согласованность взаимодействия более или менее дифференцированных и автономных частей целого, обусловленная его строением;

2. совокупность процессов или действий, ведущих к образованию и совершенствованию взаимосвязей между частями целого;

3. объединение людей, совместно реализующих некоторую программу или цель и действующих на основе определенных процедур и правил, то есть механизмов функционирования. Мы будем использовать второе и третье определение, то есть рассматривать организацию как процесс или как организационную систему (ОС), элементами которой являются отдельные люди и их объединения (участники ОС).

Под структурой будем понимать совокупность устойчивых связей между элементами системы. Для ОС это могут быть информационные, управляющие и другие связи между участниками, включая отношения подчиненности и распределение прав принятия решений.

Под организационной структурой (оргструктурой) можно понимать либо структуру процесса организации (второе определение понятия «организация») как совокупность временных, причинно-следственных и др. связей между его этапами, либо структуру ОС (соответственно, третье определение понятия «организация»). Общепринятым является последнее определение, поэтому по умолчанию будем подразумевать под рганизационной структурой именно структуру ОС.

Типовые структуры организационных систем (ОС)

В качестве типовых структур ОС выделим следующие. Во-первых, это – вырожденная

структура (ВС), в которой отсутствуют какие-либо связи между участниками. Во вторых, это – линейная структура (ЛС), при которой подчиненность участников ОС имеет вид дерева, то есть каждый участник подчинен одному и только одному участнику следующего (более высокого) уровня иерархии (следует отметить, что в подавляющем большинстве работ, содержащих формальные модели управления организационными системами, рассматривались модели ОС, характеризуемые именно древовидными структурами). И, наконец, в третьих, это – матричная структура (МС), в

которой некоторые участники ОС могут быть подчинены одновременно нескольким участникам, находящимся либо на одном и том же (более высоком), либо на различных, уровнях иерархии (соответственно, так называемое двойное подчинение, межуровневое взаимодействие и распределенный контроль).

Возможны и другие (более или менее детальные классификации по таким основаниям декомпозиции как: цели, функции, территориальное расположение, продуктовая специализация и др.).

Например, обычно выделяются следующие основные виды организационных структур промышленных фирм: иерархическая (которая порождается декомпозицией высшей цели организации на цели, подцели и т.д.), функциональная (декомпозиция производится на основании функций (исследование, производство, маркетинг и т.д.)), дивизиональные (декомпозиция по относительно независимым отделениям, каждое из которых может иметь ту или иную структуру), матричная (наложение «горизонтальной» ответственности руководителей проектов на функциональную структуру). Существуют «переходные» структуры – например, дивизионально-региональная, дивизиональнотехнологическая, дивизионально-продуктовая и др. Тем не менее, любая из перечисленных структур

ОС может быть отнесена (используемые при этом критерии должны отражать специфику решаемой задачи) к одной из трех типовых – ВС, ЛС или МС.

Сетевые структуры организационных систем (ОС)

Если выделенные в предыдущем разделе типовые структуры отражают статические характеристики ОС, то для описания их изменений во времени целесообразно введение понятия сетевой структуры (СС), в которой потенциально существуют связи между всеми участниками, некоторые из которых актуализируются, порождая из ВС линейную или матричную, на время решения стоящей перед системой задачи, а затем разрушаются (возвращаясь к ВС) до момента появления новых задач.

То есть, СС – это такие структуры ОС, в которых могут возникать и двойное подчинение, и межуровневое взаимодействие, причем одни и те же субъекты могут выступать как в роли управляющих органов, так и в роли управляемых агентов, то есть вступать в сетевое взаимодействие. Образно говоря, сетевая структура – набор априори равноправных агентов, в котором могут возникать временные иерархические и другие структуры, определяемые решаемыми системой задачами. Кроме того, необходимо подчеркнуть, что используемый нами термин «сетевая структура» не имеет непосредственного отношения к Интернету.

Следует сделать следующее терминологическое замечание. Ранее было распространена интерпретация сетевых структур как таких, в которых нет явно выраженной иерархии, и между всеми (или большинством) ее элементов существуют постоянные связи. В последнее время все большее распространение приобретает интерпретация сетевой структуры (и мы будем придерживаться именно этой интерпретации) как набора агентов, между которыми не существует постоянных связей (то есть «конструктором» является ВС), а связи образуются между ними (например, в виде линейной или матричной структуры) на время решения стоящей перед системой задачи; затем связи исчезают до момента возникновения новой задачи и т.д. Упорядоченность взаимодействия и механизм управления (иерархия) возникает в сетевой структуре в результате необходимости специализации, позволяющей эффективно решать частные задачи. Например, в процессе многократного решения схожих задач ЛС возникает в СС как механизм снижения трансакционных издержек. Другими словами, разнообразие решаемых задач порождает в вырожденной структуре организационные системы как временные иерархии. Следовательно, тип структуры ОС, обнаруживаемый исследователем операций, зависит от времени наблюдения – на больших (по сравнениюс характерным временем изменения внешних условий) временных промежутках ОС может рассматриваться как сеть, на малых – как имеющая одну из типовых структур – ВС, ЛС или МС.

Свойства типовых структур организационных систем (ОС)

Условно можно считать, что типовые структуры ОС различаются степенью проявлений таких свойств как: иерархичность (противоположностью является распределенность) и число связей. С точки зрения иерархичности ЛС является полностью иерархичной, на другом полюсе находится ВС, в которой отсутствует иерархичность, а промежуточное место занимает МС, в которой имеют место, как наличие иерархии, так и распределенность. С точки зрения числа постоянных связей наименьшее их число имеет ВС, наибольшее – МС, а ЛС занимает промежуточное место (можно рассматри-

вать МС как наложение друг на друга нескольких ЛС).

В каких же случаях эффективными оказываются те или иные структуры, под влиянием каких факторов одна структура трансформируется в другую? Эффективность и трансформация структур обусловлена существующими и, соответственно, изменяющимися внешними и внутренними условиями функционирования. Внешними условиями (активными и/или пассивными) являются требования, предъявляемые к ОС внешней средой – нормы, нормативы, ограничения, ожидания, характеристики рынка, социальный заказ и т.д. Внутренние условия, в первую очередь, характеризуются

организационными издержками, зависящими от условий взаимодействия участников ОС (затраты на их взаимодействие, а также на организацию и координацию этого взаимодействия – число связей, информационная нагрузка и т.д. – в существующих условиях и практически без учета производственных издержек).

В общем случае задача управления структурой ОС формулируется как поиск структуры (или набора структур), которая минимизировала бы организационные издержки (или максимизировала некоторый функционал, который может отражать в агрегированном виде предпочтения участников ОС и/или других субъектов) при ограничении удовлетворениясистемой внешним требованиям.

Введем два предположения относительно сравнительной эффективности типовых структур.

Первое предположение упорядочивает три типовых структуры по «сложности», которая в первом приближении может определяться как число связей между элементами ОС. Будем считать, что наиболее «простой» является ВС, наиболее «сложной» – МС, а ЛС занимает промежуточное положение между ними. Второе предположение связывает сложность типовой структуры с ее организационными издержками и, следовательно, с эффективностью в зависимости от частоты изменения внешних условий. А именно, будем считать, что более простые структуры характеризуются меньшими организационными издержками и эффективны при большей частоте изменения внешних условий.

Из введенных предположений следует, что при появлении у организации новых задач, проектов и т.д. и/или при увеличении допустимых организационных издержек возникают новые иерархии, то есть, происходит усложнение структуры и осуществляется «сдвиг» от ВС к МС (см. рисунок 1а, на котором петля означает сохранение типа структуры). При сокращении числа задач, завершении проектов и т.д. и/или при уменьшении допустимых организационных издержек разрушается часть существующих иерархий, то есть происходит упрощение структуры и осуществляется «сдвиг» от МС к ВС (см. рисунок 1б). Аналогично, при увеличении частоты изменения внешних условий происходит упрощение структуры.

Закономерности усложнения и упрощения структуры ОС (трансформации СС)

Таким образом, МС оказываются эффективными при неизменных внешних условиях и высоких организационных издержках, ВС – при изменяющихся внешних условиях и низких организационных издержках, а ЛС занимают промежуточное положение (см. также рисунок 2).

Рассмотрим качественно возможные переходы между типовыми структурами и причины этих переходов. Как отмечалось выше, снижение эффективности некоторой структуры может быть обусловлено изменением внешних условий и/или изменением организационных издержек.

Процесс трансформации может описываться как появление или исчезновение новых иерархий (элементарных линейных структур). Из описанных закономерностей упрощения и усложнения структур следует, что непротиворечивыми с точки зрения введенных предположений являются закономерности трансформации типовых структур, приведенные на рисунке 2 (интересно отметить «универсальность» ЛС).

Рис. 2. Области эффективности типовых структур ОС и закономерности их трансформации

Следует признать, что введенные предположения и приведенные результаты на сегодняшний день могут быть обоснованы лишь содержательными рассуждениями и апеллируют к интуиции читателя. Формальное обоснование подобных результатов является перспективной задачей теории управления.

Моделирование данных

Одной из основных частей информационного обеспечения является информационная база. Как было определено выше (см. лекцию 8), информационная база (ИБ) представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

Базовые понятия ERD

Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:

• иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

• иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь;

• иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.

Каждая сущность может обладать любым количеством связей с другими сущностями модели.

Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.

Метод IDEFI

Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI.

Метод Баркера основан на нотации, предложенной автором, и используется в case-средстве Oracle Designer.

Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).

В методе IDEFIX сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 1, 2).

Рис. 1. Независимые от идентификации сущности

Рис. 2. Зависимые от идентификации сущности

Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEFIX могут быть выражены следующие мощности связей:

• каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;

• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рис. 3). Мощность связей может принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р — один или более. По умолчанию мощность связей принимается равной N.

Рис. 3. Графическое изображение мощности связи

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Пунктирная линия изображает неидентифицирующую связь (рис. 4). Сущность-потомок в неидентифицирующей связи будет не зависимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 4 ).

Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рис. 4).

Рис. 4. Неидентифицирующая связь

Защита данных

Аудит информационной защиты компании

Современный мир информационных технологий, объединяющий большое количество вычеслительных ресурсов в единую мировую сеть, представляет собой достаточно комфортную среду для распостранения вредоносных программ, действий злоумышленников, промышленного шпионажа или даже просто "шутников" с различной мотивацией. Лет 10-15 назад, для того, чтобы получить доступ к конфиденциальной информации, проникнуть в сеть или сделать недоступным определенный сервис необходимо было глубокое знание сетевых протоколов, сервисов и принципов взаимодействия компьютерных систем. Сейчас же любой человек может найти в Интернете массу всевозможных программ, с помощью которых он может осуществить свои коварные планы или просто "пошутить", вызвав сбой системы, заражение атакованной системы вирусами и троянскими программами.

В современных условиях, когда информационные технологии постоянно и стремительно развиваются, обнаруживается все большее количество опасных ошибок программном обеспечении. "Вирусописатели" ни на секунду не прекращают свою деятельность, которая, по прогнозам, может разрастись до того, что в к концу 2004 года выйдет на "проектную мощность" около 1000 принципиально новых вирусов в день.

Кроме внешних факторов, влияющих на безопасность компьютерных систем есть множество внутренних факторов - неправильный дизайн сети и и системы защиты, незнание персоналом необходимых правил поведения, неправильное управление процессом приема на работу сотрудника и его увольнения, непродуманное управление рисками и т.д.

Разумеется, каждый руководитель и системный администратор четко представляет себе систему, с которой ему приходиться работать, заранее может указать слабые места в фунционировании системы и ее защите. Но, как правило, человек не может полностью предусмотреть все. Для этого существуют компании-аудиторы, которые могут указать на те недостатки в комплексной системе защиты информации, компьютерной системе, упралении рисками т.д., которые специалисты и руководители могли и пропустить. Кроме того, специалисты компании-аудитора имеют, как правило высокую квалификацию, большой опыт работы и находяться в курсе всех новостей в области безопасности информационных систем. Как правило, после проведенного аудита специалитсы компании-аудитора составляют подробный отчет о недостатках и несоотвествиях в комплексной системы защиты информации. Все это позволяет достаточно уверенно говорить о степени защищенности информационных ресурсах компании.

В перечень работ по аудиту системы информационной защиты, обычно входят:

1. Аудит организационной части системы защиты информации.

• Исследование документальной части системы защиты информации:

o Аудит политики безопасности

o Аудит должностных инструкций, правил и нормативов

o Исследование степени знания персоналом нормативных документов

o Аудит плана восстановления работоспособности системы

o Аудит документов по обеспечению непрерывности информационных процессов

o Анализ документов, регламентирующих доступ к ресурсам

o Исследование правил уничтожения информации

o Аудит ведения журналов учета

o Анализ должностных обязанностей и зон ответственности, касательно защиты информации

o Анализ списка ресурсов, подлежащих защите

• Анализ структуры локальной сети

• Анализ структуры распределенной сети

• Аудит системы защиты периметра сети

• Анализ системы защиты электронной почты

• Анализ методов разграничения доступа к ресурсам

• Анализ антивирусной защиты

• Анализ системы мониторинга

• Анализ парольной политики

• Анализ резервного копирования и уничтожения резервных копий

• Аудит процедуры уничтожения документов и оборудования

2. Анализ структуры локальной вычислительной сети (ЛВС).

• Анализ схемы подключения, связей.

• Физический уровень подключения

• Логический уровень подключения

• Анализ канального уровня сети

• Анализ конфигурации активного сетевого оборудования

• Проверка версии ПО.

• Режим работы коммутаторов

• Конфигурация портов

• Конфигурация виртуальных сетей

• Адресация IP

• Конфигурация протоколов поддерживаемых коммутаторами (STP, GVRP, 802.1p, 802.1х,802.1ad, 802.1af,IGMP, XRRP)

• Конфигурация маршутизаторов

• Настройка портов

• Настройка подсетей

• Настройка переадресации (NAT, LSNAT)

• Настройка маршрутизации, протоколов маршрутизации (RIP, OSPF, BGP, IGMP, DVMPR, IGRP,EGRP, VRRP)

• Настройка служб контроля трафика и контроля доступа

• Настройка защиты периметра сети

3. Анализ серверного оборудования и северного программного обеспечения

• Перечень серверов и конфигурация серверов

• Детальная конфигурация каждого сервера (Процессор, память дисковая подсистема и ее конфигурация и т.д)

• Выполняемые задачи каждым сервером в логической структуре сети.

• Сетевые службы на серверах и их конфигурация

• Перечень приложений работающих на серверах и состояние работы этих приложений (с какими приложениями есть проблемы)

• Анализ приложений на Интернет-сервере

• Анализ конфигурации серверов на физическом уровне

• Анализ конфигурации серверов

• Настройка службы имен (DNS, WINS)

• Настройка службы динамической конфигурации хостов (DHCP)

• Настройка почтовой службы

• Настройка антивирусной службы и политика управления

• Настройка файловых служб

• Настройка служб контроля трафика и контроля доступа

• Настройка службы печати

• Настройка службы резервного копирования

4. Аудит системы защиты периметра сети.

• Структурная схема защиты периметра сети

• Основные информационные потоки

• Анализ дизайна защиты периметра сети

• Инвентаризация оборудования

• Сканирование портов из внешнего мира

• Анализ защищенности периметра сети при атаке из внешних сетей

• Анализ настроек серверного ПО

• Анализ настроек приложений

• Анализ защищенности периметра сети при атаке из локальной сети

5. Анализ конфигурации клиентских рабочих мест

• Перечень оборудования и конфигурация клиентских рабочих мест

• Детальная конфигурация каждого рабочего места (Процессор, память дисковая подсистема и ее конфигурация и т.д)

• Перечень прикладного программного обеспечения, которое используется на клиентских рабочих местах

• Минимальный перечень ПО который необходим на каждом из рабочих мест

• Выборочный анализ конфигурации рабочих станций

• Анализ конфигурации сетевых настроек рабочих станций

6. Анализ состояния эксплуатационной документации

• ведомость эксплуатационных документов;

• схема адресации;

• журнал регистрации настроек сетевого оборудования (включая перечень VLAN и их настроек);

• журнал регистрации настроек серверов;

• кабельный журнал;

• схемы коммутации кабелей на патч-панелях коммутационных шкафов (или таблица кроссовых соединений портов активного сетевого оборудования);

• журнал характеристик кабельных соединений;

• журнал аутентификационных атрибутов пользователей (пароли, имена пользователей и др);

• журнал авторизационных атрибутов пользователей (временные ограничения, ограничения по доступу к ресурсам, ограничения по трафику и др.);

• журнал регистрации информационных ресурсов сети;

• журнал регистрации резервного копирования;

• журнал регистрации неисправностей;

• файлы конфигурации сетевых установок рабочих станций пользователей;

• справочник электронных адресов пользователей сети.

• Журнал регламентных работ

7. Тест на проникновение в систему.

• Проводиться проверка системы защиты информации на предмет реализации различных уязвимостей, приводящих к нарушению безопасности.

После проведенного аудита, составляют отчет о найденых уязвимостях и несоответствиях, методах их устранения. Составляют техническое задание на модернизацию системы информационной защиты, на основании которого можно составить проект.

Создание системы защиты периметра локальной сети

На сегодняшний день доступ к ресурсам всемирной сети Интернет является одним из необходимых инструментов для успешного ведения бизнеса. Достоинствами использования ресурсов сети Интернет, безусловно, является открытость информации, оперативность получения необходимых данных, отсутствие видимых границ и т.п.

Основным недостатком можно считать потенциальную угрозу нарушения нормального функционирования локальной сети. Основными причинами нарушений функционирования локальной сети, связанными с доступом к ресурсам Интернет можно назвать:

• Вирусы.

В последнее время существенно участились вирусные атаки, приходящие из Интернет. Компании теряют до десятков миллионов долларов на устранение последствий вирусных атак, хотя всем известно, что лучше предупредить болезнь, чем ее лечить. Ежедневно создается до 1000 новых вирусов, и специалисты предупреждают, что количество новых вирусов будет только расти.

• Проникновения в локальную сеть.

В незащищенную сеть злоумышленник может проникнуть множество способов, начиная от построения скрытых туннельных соединений с локальной рабочей станцией с помощью внедренных программ-троянцев и заканчивая подбором пароля администратора, с последующим полным контролем над сетью. Наиболее часто встречается использование уязвимостей в программном обеспечении общедоступных сервисов.

• Атаки на отказ в обслуживании.

Для незащищенной сети это может стать настоящим бедствием. Даже для защищенной сети выдержать атаку на отказ в обслуживании - большое испытание. Для сети, где нет грамотно настроенного межсетевого экрана, данный тип атаки может привести к полному краху всей системы, ответственной за доступ пользователей к ресурсам Интернет и за доступ внешних пользователей к ресурсам компании.

• Неконтролируемый трафик.

Достаточно часто сотрудники компании используют свое рабочее время и каналы доступа в Интернет не для выполнения своих служебных обязанностей. Часто сотрудники используют электронную почту для пересылки картинок, музыки и видеоклипов, что приводит к дополнительным затратам на оплату за каналы связи и доступ в Интернет.

Это только самые распространенные виды нарушений безопасности функционирования локальной сети, подключенной к сети Интернет. Самое опасное то, что уровень знаний злоумышленника постоянно снижается. Если раньше для того, чтобы взломать какой-либо ресурс, злоумышленнику необходимо было серьезно разбираться в технологиях, знать достаточно много о взламываемой системе, то сейчас ему достаточно зайти на один из специализированных сайтов и скачать программу, которая все сделает за него. Злоумышленнику достаточно будет указать только некоторые параметры, а зачастую и только адрес атакуемой системы.

Межсетевой экран

Одно из самых распространенных решений, является классическая схема трехуровневого межсетевого экрана. Данная схема обеспечивает надежное экранирование оперативных зон с различным уровнем доверия. В общем случае, выделяется три оперативные зоны:

• Зона внешних подключений, по которой проходит граница взаимодействия с провайдером. Уровень доверия к соединениям в этой зоне минимальный.

• Демилитаризованная зона (ДМЗ). В этой зоне располагаются серверы компании, к которым необходим доступ из внешних сетей и из локальной сети. Это может быть WEB-сервер, почтовый сервер, FTP-сервер, прокси-сервер и т.п. Уровень доверия к соединениям в данной зоне - средний.

• Зона подключения к локальной сети. Как правило, это интерфейс, по которому проходит соединение межсетевого экрана с локальной сетью. Уровень доверия к соединениям в данной зоне - максимальный.

Сам межсетевой экран (МЭ) настраивается таким образом, что соединения возможны от локальной сети к ДМЗ и от ДМЗ к внешним сетям. Из внешних сетей возможны соединения только к известным сервисам в ДМЗ. Из ДМЗ разрешены соединения, инициированные из локальной сети. Все остальные соединения блокируются. Собственно, схема Рис.1

Рис.1

При необходимости можно настроить VPN-шлюз, для организации работы удаленных пользователей с корпоративними ресурсами.

Система обнаружения атак

Для защиты периметра сети и серверов, располагающихся в ДМЗ, от основных видов атак используют системы обнаружения вторжений. Как правило, это программно-аппаратный комплекс, с постоянно обновляющейся базой атак, который позволяет в режиме реального времени отслеживать и сообщать администратору о большинстве видов проводимых атак. Администратор системы может блокировать нежелательные соединения вручную, либо создать правило, на основе которого данный трафик будет блокироваться автоматически. Возможно использование одного и того же детектора атак для анализа внешнего трафика и трафика в ДМЗ. Для защиты непосредственно серверов устанавливается специальный детектор атак, предназначенный именно для данной операционной системы. Это позволяет учитывать нюансы различных операционных систем.

Почтовая система

Для защиты почтовой системы от проникновения вирусов используют программные продукты ведущих мировых производителей - Symantec, TrendMicro, Dr.Web. Продукты данных производителей хорошо зарекомендовали себя в рабочих условиях. У всех продуктов этих компаний хорошая совместимость и интегрируемость с большинством ПО для передачи почтовых сообщений.

Защита почтовой системы позволяет предотвратить:

• передачу "опасных" вложений в сообщениях электронной почты (вирусов, вредоносного мобильного кода);

• утечку конфиденциальной информации из компании по каналам электронной почты;

• ошибочное направление писем;

• возможность организации скрытого канала передачи информации;

• циркуляцию в сети запрещенных и компрометирующих компанию материалов;

• передачу неприемлемых вложений;

• снижение производительности работы компании из-за несвязанного с ее деятельностью использования электронной почты.

Антивирусное ПО

В качестве антивирусного ПО, максимально удовлетворяющего требования заказчика можно использовать продукты компании Symantec, TrendMicro, Dr.Web. К примеру, продукт компании TrendMicro - VirusWall позволяет сканировать весь http-трафик (посещение пользователей WEB-ресурсов Интернет) и весь почтовый трафик. Удобный интерфейс администрирования делают данный продукт удобным в настройке и использовании.

Серверы, расположенные в ДМЗ

Для обеспечения надежности, безопасности и стабильности работы серверов, расположенных в демилитаризованной зоне, можно провести настройку операционных систем и необходимых сервисов.

Для предоставления пользователям локальной сети полноценного доступа к ресурсам Интернет необходимо настроить:

• Сервис синхронизации времени. Данный сервис позволяет синхронизировать системное время серверов и рабочих станций с эталонным мировым временем.

• Сервис кэширования WEB-страниц (прокси-сервис). Данный сервис позволяет сохранять локально наиболее часто посещаемые страницы, тем самым существенно экономя пропускную способность канала. При грамотно настроенном сервисе возможна экономия до 30% загрузки внешнего канала.

• Система разграничения доступа к нежелательным материалам. На базе прокси-сервера осуществляется настройка системы фильтрации нежелательной информации. К такой информации может относиться все, что не является обязательным для обеспечения бизнес-задач компании.

• WEB-сервер компании.

• FTP-сервер компании.

• Система мониторинга и удаленного управления.

Разработка пользовательского интерфейса

Интерфейс пользователя - эта та часть программы, которая находится у всех на виду. Некоторые программисты склонны оставлять дизайн интерфейса пользователя на потом, считая, что реальное достоинство приложения - его программный код, который и требует большего внимания. Однако часто возникает недовольство пользователей из-за неудачно подобранных шрифтов, непонятного содержимого экрана и скорости его прорисовывания, поэтому работу над интерфейсом также нужно воспринимать серьезно. Пользователь не видит программного кода, зато интерфейс (хороший или плохой) всегда перед ним.

Разработка эффективных форм

Формы - это строительные блоки интерфейса пользователя. Хороший дизайн форм включает нечто большее, чем просто добавление элементов управления и программирование процедур обработки событии. Чтобы создать хорошо спроектированную форму, нужно уяснить ее назначение, способ и время использования, а также ее связи с другими элементами программы. Кроме того в приложении может находиться несколько форм, каждая из которых будет отображаться по мере необходимости. Одни пользователи широко используют многозадачность Windows, другие предпочитают работать только с одним приложением. Необходимо помнить об этом во время разработки интерфейса пользователя (UI) Следует максимально реализовать все возможности Windows, чтобы пользователи с любыми навыками работы могли эффективно применять созданное вами приложение.

Проектирование форм ввода данных

Особый вид форм - формы, предназначенные для ввода данных. Они позволяют пользователю идти в нужном ему темпе, не оглядываясь на программиста. Общий смысл и основное правы: если пользователь собирается ввести в базу данных 10000 записей, вероятно, он не хочет подтверждать ввод каждой записи. В форме ввода данных необходимо максимально использовать свободное пространство, поскольку открытие и закрытие дополнительных форм существенно замедляет работу. При разработке форм ввода данных основное внимание следует уделить скорости их работы. Чтобы максимально ускорить процесс ввода данных, следуйте приведенным ниже основным правилам.

Для каждой команды должны быть назначены клавиатурные эквиваленты; не требуйте обязательного использования мыши. (Кстати, этот совет хорош для всех форм программы, а не только для форм ввода данных.) Расположение элементов должно быть согласовано с задачами пользователя. Другими словами, не заставляйте пользователя перепрыгивать из раздела в раздел; при вводе информации это совсем не обязательно. Не заставляйте пользователя выполнять лишнюю работу. Другими словами, если информация, содержащаяся в полях со 2-го по 10-е, необходима только, когда первое поле имеет определенное значение, не нужно заставлять пользователя заполнять все поля подряд. В то же время, не ставьте работу формы в зависимость от содержимого отдельных полей. В противном случае это может существенно замедлить работу пользователя. Используйте заметную, но ненавязчивую обратную связь с пользователем. Хороший пример - работа редактора программного кода Visual Basic, который проверяет правильной написания переменных и констант.

Если возможно, выполняйте добавление и редактирование записей в одной и той же форме, тогда пользователю не придется осваивать несколько методов доступа к одним и тем же данным.

Работа с несколькими формами

Если интерфейс пользователя должен содержать несколько форм, вам предстоит принять самое важное решение: какой использовать вид интерфейса - однодокументный (SDI) или многодокументный (MDI). В SDl-приложениях окна форм появляются совершенно независимо друг от друга. Однако не имеет значения какой тип интерфейса SDI или MD1 выбран; взаимодействие пользователя с формами происходит одинаково -посредством обработки событий, поступающих от элементов управления формы. Поэтому если в вашем приложении предусмотрено несколько форм, программу необходимо написать так, чтобы у пользователей не было возможности нарушить предписанные ход ее выполнения (например, у пользователя не должно быть средств вывести форму, для которой еще не готова информация).

Эффективные меню

Еще одна важная часть разработки форм - создание содержательных и эффективных меню. Приведем некоторые важные рекомендации: · Следуйте стандартным соглашениям о расположении пунктов меню принятым в Windows File, Edit, View, и т.д. · Группируйте пункты меню в логическом порядке и по содержанию. · Для группировки пунктов в раскрывающихся меню используйте разделительные линии· Избегайте избыточных меню. Избегайте пунктов меню верхнего уровня, не содержащих раскрывающихся меню· Не забывайте использовать символ троеточия для обозначения пунктов меню, активизирующих диалоговые окна. · Обязательно используйте клавиатурные эквиваленты команд и "горячие" клавиши. · Помещайте на панель инструментов часто используемые команды меню.

Ощущение скорости

Ощущение - это реальность. Простой пример - скорость работы приложения. У вас может быть самый быстродействующий программный код, но это ничего не значит, если с точки зрения пользователя он работает медленно. Когда пользователи жалуется на скорость, программисты защищаются, утверждая, что "пользователь не знает, что делает программа". Однако, если воспользоваться некоторыми уловками, то можно сделать так, что будет казаться: программа работает быстрее. Пользователь гораздо более расположен к ожиданию, если считает, что компьютер работает с максимальной скоростью. Хороший пример - загрузка Windows, которая обычно требует достаточно много времени. Однако вывод графики, сопровождающие звуки, шум жесткого диска отвлекают настолько, что пользователь не ощущает ожидания. Описанная ниже техника поможет в создании "более быстрых" приложений.

Информирование пользователя о ходе процесса

Когда есть видимость работы приложения, пользователи более легко переносят длительное ожидание в работе программы. Один из способов информирования пользователя о ходе выполнения работы - использовать в форме индикатор процесса. Если обновляются записи базы данных, можно использовать такой индикатор для отображения числа записей, над которыми операция уже произведена. Для этого добавьте пару строк кода обновляющих показания индикатора по мере перехода к следующим записям.

Выводы по проектированию пользовательского интерфейса

Хотя ни одно ухищрение не гарантирует создания удачного интерфейса пользователя, плохой интерфейс гарантирует отсутствие пользователей вашей программы. Однако при стремительном появлении новшеств, в сфере пользовательских интерфейсов понятие "хорошего" интерфейса очень быстро изменяется. Возьмем, например, процесс настройки часов видеомагнитофона. Раньше часы программировали "вслепую" кнопками и переключателями, потом стали применяться дисплеи, для которых использовался экран телевизора, а теперь в некоторых моделях этот процесс выполняется автоматически по радиосигналу. Так и интерфейс пользователя программ будет "эволюционировать" по мере того, как индустрия будет устанавливать новые стандарты, и вы, в свою очередь, должны быть всегда в курсе, как в наибольшей степени удовлетворить ожидания пользователя.

Организация распределенных ИС на основе вычислительных сетей

В современных условиях главным требованием времени к информационным технологиям является доступная стоимость внедрения и владения. Идет процесс поиска сокращения расходов и повышения эффективности своих процессов и систем, а это, собственно, и обещают технологии сетей распределенных вычислений. Такой подход повышает эффективность ресурсов и предлагает способ консолидации уже имеющегося оборудования – чтобы исключить «белые пятна» компьютеров, ресурсы которых задействованы пока не полностью. Можно создавать централизованные пулы вычислительных ресурсов и распределять их в соответствии с приоритетами организации. Главная идея сети распределенных вычислений состоит в предоставлении вычислений как коммунальных услуг. Пользователям не придется заботиться о том, где находятся актуальные данные или к каким вычислительным процессам они обращаются. Пользователей интересует возможность запрашивать информацию или вычисления и получать их в нужном объеме и в нужное время. Именно так действует электрическая сеть – в том смысле, что людям не обязательно знать, где расположены генераторы и как проложены линии электропередачи. Поэтому цель можно сформулировать так: превратить вычисления в коммунальную услугу, доступную всегда и везде. Отсюда и термин – «сеть распределенных вычислений».

Конечно, подход к вычислениям как к коммунальной услуге соответствует взгляду со стороны клиента. Со стороны же сервера, то есть изнутри, сеть распределенных вычислений – это выделение ресурсов, распределение информации и обеспечение высокой степени готовности. Выделение ресурсов означает, что все, кто нуждается в ресурсах или запрашивает их, получат то, что им нужно. При наличии свободных ресурсов запросы не могут оставаться неудовлетворенными. Распределение информации означает, что информация, необходимая пользователям и приложениям, доставляется туда и тогда, где и когда она требуется. Высокая степень готовности означает, что все данные и вычисления доступны постоянно – точно так же, как энергетическая компания обеспечивает бесперебойную подачу электроэнергии.

Сеть распределенных вычислений в корне меняет способ использования предприятиями своих ресурсов – она их виртуализирует. Ресурсы становятся виртуальными, т.е. их можно распределять между серверами вычислительного центра, между вычислительными центрами предприятия и между самими предприятиями.

Раздел 5. Структура программных модулей. Разработка алгоритмов.

Структура раздела

Лингвистическое обеспечение ИС

Языки программирования для создания информационных систем

Ассемблер

Delphi

С/С++ Java Программное обеспечение ИС

Разнородность информации

Методы представления графической информации

Текстовые данные в мультимедиа

Звуковая информация

Межпрограммный интерфейс

Распределенные базы данных

Определение Дэйта

Целостность данных

Архитектура "клиент-сервер"

Средства и методологии проектирования, разработки и сопровождения Intranet и Internet-приложений

Основные понятия Intranet

Языки и протоколы

Серверы Intranet

Возможные архитектуры Intranet-приложений

Лингвистическое обеспечение ИС

Языки программирования для создания информационных систем

Компьютер может выполнять программу только в том случае, если содержащиеся в ней команды представлены в двоичном машинном коде, т.е. выражены на языке, алфавит которого состоит из логических единиц и нулей. Для первых компьютеров программы составлялись непосредственно в машинных кодах, что требовало высокой квалификации программистов и больших затрат труда, поэтому уже в 40-х годах началась разработка языков программирования, которые по своей лексике были бы максимально приближены к естественному языку человека. Такие языки программирования называются алгоритмическими.

Промежуточным шагом к разработке алгоритмических языков стал язык Ассемблер. В Ассемблере команды представляются не двоичными числами, а в виде сочетаний символов (мнемоническими кодами), по которым можно воспроизвести смысл команды, что значительно устраняет трудности и недостатки программирования на машинном языке. Однако Ассемблеру присущи и недостатки - это машинноориентированный язык, и для каждого компьютера создается свой язык Ассемблера. Программирование на Ассемблере требует от программиста хорошего знания архитектуры (устройства) компьютера и сопряжено со значительными трудозатратами, в то же время именно с помощью Ассемблера можно наилучшим образом использовать в программе ресурсы компьютера (память, быстродействие), поэтому Ассемблер по-прежнему широко распространен среди профессиональных программистов.

Первым алгоритмическим языком стал Fortran, созданный в 1957г. специалистами фирмы IBM под руководством Джона Бекуса. Сейчас существует большое множество алгоритмических языков: Pascal, C, Algol, PL1, Basic, Lisp, Prolog и многие другие.

Алгоритмические языки и ассемблеры относятся к языками символьного кодирования, т.е. к языкам, которые оперируют не машинными кодами, а условными символьными обозначениями, поэтому программы, составленные на этих языках, не могут быть непосредственно выполнены на компьютере. Чтобы такая программа заработала, ее текст нужно преобразовать в машинные коды. Для этого существуют специальные программы-переводчики (трансляторы). Различают 2 вида трансляторов- компилятор и интерпретатор. Компилятор транслирует программу сразу целиком, и лишь после этого возможно ее выполнение. Интерпретатор - это более простой транслятор, он последовательно транслирует операторы программы и так же по частям ее выполняет.

Проблемно-ориентированный язык программирования - язык программирования, управляющие структуры и/или структуры данных которого отражают особенности класса решаемых задач.

Для написания информационных систем подходят такие языки как Assembler, Delphi, C/C++, Java и другие.

Ассемблер

Ассе́мблер (от англ. assemble — собирать) — компилятор с языка ассемблера в команды машинного языка. Русифицированное название — мнемокод. Предназначен для представления в удобном (мнемоническом) виде машинные коды команд. Пример команд на мнемокоде: СЛЖ — сложить, ВЧТ — вычесть, ПРХ — переход и другие. Обеспечивает наиболее эффективное использование ресурсов системы (процессор, память, периферия). Используется в «узких» местах — требуется большое быстродействие, ограничение по размеру оперативной памяти и другие. Ассемблером также называют иногда саму систему команд центрального процессора.

Под каждую архитектуру процессора и под каждую ОС или семейство ОС существует свой Ассемблер. Существуют также так называемые «кросс-ассемблеры», позволяющие на машинах с одной архитектурой (или в среде одной ОС) ассемблировать программы для другой целевой архитектуры или другой ОС, и получать исполняемый код в формате, пригодном к исполнению на целевой архитектуре или в среде целевой ОС.

Delphi Delphi — результат развития языка Турбо Паскаль, который, в свою очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль начиная с версии 5.5 добавил в Паскаль обьектно-ориентированные свойства, а Delphi — объектно-ориентированный язык программирования с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией. Так как все классы наследуют функции базового класса TObject, то любой указатель на обьект можно преобразовать к нему, и воспользоваться методом ClassType и функцией TypeInfo, которые и обеспечат интроспекцию. Также отличительным свойством Дельфи от С++ является отсутствие возможности располагать обьекты в стеке (объекты, унаследованные из Турбо Паскаля, располагаться в стеке могут) — все обьекты попадают в динамически выделяемую область (кучу).

Де-факто Object Pascal, а затем и язык Delphi являются функциональными наращиваниями Turbo Pascal. Об этом говорят обозначения версий компилятора. Так, в Delphi 7 компилятор имеет номер версии 15.0 (Последняя версия Borland Pascal / Turbo Pascal обозначалась 7.0, в Delphi 1 компилятор имеет версию 8.0, в Delphi 2 — 9.0, и т. д. Номер версии 11.0 носит компилятор Pascal, входивший в состав среды C++Builder).

Delphi оказал огромное влияние на создание концепции языка C# для платформы .NET. Многие его элементы и концептуальные решения вошли в состав С#. Одной из причин называют переход Андерса Хейлсберга, одного из ведущих разработчиков Дельфи, из компании Borland Ltd. в Microsoft Corp.

• Версия 1 была предназначена для разработки под 16-ти разрядную платформу Win16;

• Версии со второй компилируют программы под 32-х разрядную платформу Win32;

• Вместе с 6-й версией Delphi вышла совместимая с ним по языку и библиотекам среда Kylix, предназначенная для компиляции программ под операционную систему Linux;

• Версия 8 способна генерировать байт-код исключительно для платформы .NET. Это первая среда, ориентированная на разработку мультиязычных приложений (лишь для платформы .NET);

• Последующие версии (обозначаемые годами выхода, а не порядковыми номерами, как это было ранее) могут создавать как приложения Win32, так и байт-код для платформы .NET.

С/С++

Исторически C неотделим от операционной системы Unix, которая в наши дни переживает свое второе рождение. 60-е годы были эпохой становления операционных систем и языков программирования высокого уровня. В тот период для каждого типа компьютеров независимо разрабатывались ОС и компиляторы, а нередко даже свои языки программирования (вспомним, например, PL/I). В то же время, общность возникающих при этом проблем уже стала очевидной. Ответом на осознание этой общности стала попытка создать универсальную мобильную операционную систему, а для этого понадобился не менее универсальный и мобильный язык программирования. Таким языком стал С, а Unix стала первой ОС, практически полностью написанной на языке высокого уровня.

Тесная связь с Unix дала языку С такой полигон для обкатки, какого не было в то время ни у одного другого языка. Задачи системного программирования по праву считались в то время самыми сложными в отрасли. В большинстве своем они были настолько машинно-зависимыми, что многие вообще не мыслили их решение иначе, чем на ассемблере. Языки высокого уровня предназначались для прикладного программирования и лишь очень ограниченно реализовывали функции, необходимые для системных работ, причем зачастую только для определенного типа машин.

Язык С с самого начала создавался так, чтобы на нем можно было писать системные задачи. Создатели С не стали разрабатывать абстрактную модель исполнителя языка, а просто реализовали в нем те возможности, в которых более всего нуждались в практике системного программирования. Это в первую очередь были средства непосредственной работы с памятью, структурные конструкции управления и модульная организация программы. И по сути больше ничего в язык включено не было. Все остальное было отнесено в библиотеку времени исполнения. Поэтому недоброжелатели иной раз отзываются о языке С как о структурном ассемблере. Но что бы они ни болтали, подход оказался очень удачным. Благодаря ему был достигнут новый уровень по соотношению простоты и возможностей языка.

Есть, впрочем, еще один фактор, определивший успех языка. Создатели очень умело разделили в нем машинно-зависимые и независимые свойства. Благодаря этому большинство программ удается писать универсально - их работоспособность не зависит от архитектуры процессора и памяти. Немногочисленные же аппаратно-зависимые части кода можно локализовать в отдельных модулях. А пользуясь препроцессором, можно создавать такие модули, которые при компиляции на разных платформах будут порождать соответствующий машинно-зависимый код.

Много споров вызывал синтаксис языка С. Примененные в нем приемы сокращения записи при неумеренном использовании могут сделать программу совершенно нечитаемой. Но, как говорил Дейкстра, - средства не виноваты в том, что их безграмотно используют. На самом же деле, предложенные в С сокращения синтаксиса соответствуют наиболее часто встречающимся на практике стереотипным ситуациям. Если считать сокращения идиомами для выразительного и компактного представления таких ситуаций, то польза от них становится безусловной и очевидной.

Итак, С возник как универсальный язык системного программирования. Но он не остался в этих рамках. К концу 80-х годов язык С, оттеснив Fortran с позиции лидера, завоевал массовую популярность среди программистов во всем мире и стал использоваться в самых различных прикладных задачах. Немалую роль здесь сыграло распространение Unix (а значит и С) в университетской среде, где проходило подготовку новое поколение программистов.

Как и все языки, С постепенно совершенствовался, но большинство усовершенствований не носило радикального характера. Наиболее существенным из них, пожалуй, следует считать введение строгой спецификации типов функций, которая значительно повысила надежность межмодульного взаимодействия на С. Все такие усовершенствования были в 1989 году закреплены в стандарте ANSI который и поныне определяет язык С.

Но если все так безоблачно, то почему же еще продолжают использоваться все остальные языки, что поддерживает их существование? Ахиллесовой пятой языка С стало то, что он оказался слишком низкоуровневым для тех задач, которые поставили на повестку дня 90-е годы. Причем у этой проблемы есть два аспекта. С одной стороны, в язык были встроены слишком низкоуровневые средства - прежде всего это работа с памятью и адресная арифметика. Недаром смена разрядности процессоров очень болезненно отражается на многих С-программах. С другой стороны, в С недостает средств высокоуровневых - абстрактных типов данных и объектов, полиморфизма, обработки исключений. Как следствие, в программах на С техника реализации задачи часто доминирует над ее содержательной стороной.

Первые попытки исправить эти недостатки стали предприниматься еще в начале 80-х годов. Уже тогда Бьерн Страуструп в AT&T Bell Labs стал разрабатывать расширение языка С под условным названием . Стиль ведения разработки вполне соответствовал духу, в котором создавался и сам язык С, - в него вводились те или иные возможности с целью сделать более удобной работу конкретных людей и групп. Первый коммерческий транслятор нового языка, получившего название C++ появился в 1983 году. Он представлял собой препроцессор, транслировавший программу в код на С. Однако фактическим рождением языка можно считать выход в 1985 году книги Страуструпа . Именно с этого момента C++ начинает набирать всемирную популярность.

Главное нововведение C++ - механизм классов, дающий возможность определять и использовать новые типы данных. Программист описывает внутреннее представление объекта класса и набор функций-методов для доступа к этому представлению. Одной из заветных целей при создании C++ было стремление увеличить процент повторного использования уже написанного кода. Концепция классов предлагала для этого механизм наследования. Наследование позволяет создавать новые (производные) классы с расширенным представлением и модифицированными методами, не затрагивая при этом скомпилированный код исходных (базовых) классов. Вместе с тем наследование обеспечивает один из механизмов реализации полиморфизма - базовой концепции объектно-ориентированного программирования, согласно которой, для выполнения однотипной обработки разных типов данных может использоваться один и тот же код. Собственно, полиморфизм - тоже один из методов обеспечения повторного использования кода.

Введение классов не исчерпывает всех новаций языка C++. В нем реализованы полноценный механизм структурной обработки исключений, отсутствие которого в С значительно затрудняло написание надежных программ, механизм шаблонов - изощренный механизм макрогенерации, глубоко встроенный в язык, открывающий еще один путь к повторной используемости кода, и многое другое.

Таким образом, генеральная линия развития языка была направлена на расширение его возможностей путем введения новых высокоуровневых конструкций при сохранении сколь возможно полной совместимости с ANSI С. Конечно, борьба за повышение уровня языка шла и на втором фронте - те же классы позволяют при грамотном подходе упрятывать низкоуровневые операции, так что программист фактически перестает непосредственно работать с памятью и системно-зависимыми сущностями. Однако язык не содержит механизмов, вынуждающих разработчика правильно структурировать программу, а авторы не выпустили никаких систематических рекомендаций по использованию его довольно изощренных конструкций. Не позаботились они своевременно и о создании стандартной библиотеки к лассов, реализующей наиболее часто встречающиеся структуры данных.

Все это привело к тому, что многие разработчики вынуждены были сами исследовать лабиринты языковой семантики и самостоятельно отыскивать успешно работающие идиомы. Так, например, на первом этапе развития языка многие создатели библиотек классов стремились построить единую иерархию классов с общим базовым классом Object. Эта идея была заимствована из Smalltalk - одного из наиболее известных объектно-ориентированных языков. Однако она оказалась совершенно нежизнеспособной в C++ - тщательно продуманные иерархии библиотек классов оказывались негибкими, а работа классов - неочевидной. Для того чтобы библиотеками классов можно было пользоваться, их приходилось поставлять в исходных текстах.

Появление темплетных классов и вовсе опровергло это направление развития. Наследованием стали пользоваться только в тех случаях, когда требовалось порождение специализированной версии имеющегося класса. Библиотеки стали составляться из отдельных классов и небольших несвязанных друг с другом иерархий. Однако на этом пути стало снижаться повторное использование кода, так как в C++ невозможно полиморфное использование классов из независимых иерархий. Повсеместное же применение темплетов ведет к недопустимому росту объема скомпилированного кода - не будем забывать, темплеты реализуются методами макрогенерации.

Один из тяжелейших недостатков C++, унаследованный им от синтаксиса С, состоит в доступности компилятору описания внутренней структуры всех использованных классов. Как следствие, изменение внутренней структуры представления какого-нибудь библиотечного класса приводит к необходимости перекомпиляции всех программ, где эта библиотека используется. Это сильно ограничивает разработчиков библиотек в части их модернизации, ведь, выпуская новую версию, они должны сохранять двоичную совместимость с предыдущей. Именно эта проблема заставляет многих специалистов считать, что C++ непригоден для ведения больших и сверхбольших проектов.

И все же, несмотря на перечисленные недостатки и даже на неготовность стандарта языка (это после пятнадцати с лишним лет использования!), C++ остается одним из наиболее популярных языков программирования. Его сила прежде всего в практически полной совместимости с языком С. Благодаря этому программистам C++ доступны все наработки, выполненные на С. При этом C++ даже без использования классов привносит в С ряд настолько важных дополнительных возможностей и удобств, что многие пользуются им просто как улучшенным С.

Что касается объектной модели C++, то пока ваша программа не стала очень большой (сотни тысяч строк), ею вполне можно пользоваться. Наметившаяся в последнее время тенденция перехода к компонентному программному обеспечению только усиливает позиции C++. При разработке отдельно взятых компонентов недостатки C++ еще не проявляются, а связывание компонентов в работающую систему производится уже не на уровне языка, а на уровне операционной системы.

В свете всего сказанного перспективы C++ не выглядят мрачными. Хотя и монополия на рынке языков программирования ему не светит. Пожалуй, с уверенностью можно утверждать только то, что еще одной модернизации-расширения этот язык не переживет. Недаром, когда появилась Java, на нее обратили столь пристальное внимание. Язык, близкий по синтаксису к C++, а значит, кажущийся знакомым многим программистам, был избавлен от наиболее вопиющих недостатков C++, унаследованных им из 70-х годов. Однако не похоже, чтобы Java справлялась с возлагаемой на нее некоторыми ролью “убийцы C++”.

Java

Java появился в 1992 г. Вначале он разрабатывался как язык управления электронно-бытовыми приборами. Но стал средством, позволяющим на основе технологии Java создавать прикладные программы, независимые от используемых в сети платформ. Поэтому рассматриваемый язык характеризуется переносимостью с одной платформы на другую, имеет развитые средства защиты информации и возможности работы в сети. В первую очередь это относится к сети Интернет и ее службе глобального соединения.

Язык Java обеспечивает:

• независимость от архитектуры информационной системы;

• переносимость с одной платформы на другую;

• надежность, безопасность, легкую расширяемость;

• распределенную обработку данных;

• ускорение разработки прикладных программ с помощью визуальных средств;

• создание программ средствами объектно-ориентированной архитектуры (работает с объектами, а не с функциями);

• защиту программ от компьютерных вирусов и несанкционированного доступа;

• поиск и исправление ошибок;

• использование эффективного компилятора;

• работу с библиотекой программ, предназначенных для поддержки протокола управления передачей/межсетевого протокола и "протокола передачи файлов" (FTP);

• доступ к распределенным базам данных.

Программное обеспечение ИС

Системное программное обеспечение — это набор программ, которые управляют компонентами вычислительной системы, такими как процессор, коммуникационные и периферийные устройства, а также которые предназначены для обеспечения функционирования и работоспособности всей системы.

Большинство из них отвечают непосредственно за контроль и объединение в единое целое различных компонентов аппаратного оборудования вычислительной системы.

Системное программное обеспечение противопоставляется прикладному программному обеспечению, которое напрямую решает проблемы пользователя.

Конкретные виды системного программного обеспечения включают загрузчики, операционные системы, драйверы устройств, инструментальные программные средства, компиляторы, ассемблеры, компоновщики, утилиты.

Прикладное программное обеспечение — программы, предназначенные для выполнения определенных пользовательских задач и рассчитанные на непосредственное взаимодействие с пользователем. В отличие от прикладного, системное программное обеспечение (операционная система) используется для обеспечения работы компьютера самого по себе и выполнения прикладных программ.

Если в качестве простой аналогии рассматривать операционную систему как корпус, мотор, шасси, колёса и другие компоненты автомобиля (те детали которые позволяют автомобилю ехать), то роль прикладных программ будут играть рулевое управление, сиденья, приборная панель, кондиционер и т. п., то есть те части которые позволяют нам использовать автомобиль в целях передвижения в нём и разнообразные дополнительные опции, повышающие удобство этого использования. Аналогично автомобилю, которым невозможно пользоваться без руля, разве что только для обогрева помещения, так и компьютер без прикладного ПО практически бесполезен, можно из него сделать разве что файл-сервер или принт-сервер.

В некоторых типах встроенных систем прикладное и системное программное обеспечение может быть практически неразделимо, как например в случае ПО для видеомагнитофонов или микроволновых печей.

Разнородность информации

Поскольку в настоящее время практически любая информационная система разрабатывается и поддерживается с использованием ЭВМ, то информация, которую система обрабатывает, должна быть представлена в электронном виде. Поэому далее речь пойдёт о мультимедийной информации.

Мультимедиа – это работа компьютера со многими видами информации, включая цветную графику высокого разрешения, динамические эффекты бегущего и переливающегося всеми цветами радуги текста, звучание голосов и звуки синтезированной музыки, «мультяшки» и, наконец, полноцветные видео-клипы и даже видеофильмы. Средства мультимедиа превращают обычный ПК в многофункциональное устройство, коренным образом изменяющее назначение ПК.

Под средствами мультимедиа (ММ) обычно понимают комплекс аппаратных и программных средств, позволяющих человеку общаться с компьютером, используя самые разные, естественные для себя среды: графику, гипертексты, звук, анимацию, видео. Сегодня ММ системы могут представлять обучаемому следующие виды информации: текст (в форматах: *.doc, *.txt, *.html); изображения (*.bmp, *.gif, *.jpeg,...); анимированные картинки (*.gif, *.flc, *.fli, *.swf); аудиокомментарии (*.wav, *.mp3, *.au, *.MIDI); цифровое видео (*.avi, *.mpeg) и другие. Но это лишь потенциальные возможности современных компьютерных технологий.

Зрительный канал по своим возможностям намного превосходит возможности всех других каналов восприятия информации человеком. В этой связи введение видеоинформация в комплекс учебно-методических материалов для восприятия учебного материала, его усвоения и запоминания имеет исключительное значение. Современные информационные технологии позволяют создавать средства обучения не только с использованием красочных иллюстраций, но и различные виды видеофильмов (анимацию, документальное и игровое кино).

Документальные видеофильмы (фрагменты "живого" видео) зарекомендовали себя как наиболее эффективное средство для первичного знакомства с предметом изучения. Они нашли широкое применение при показе технологических процессов, работы машин и т.п. Для объяснения же механизмов, лежащих в основе изучаемых процессов, особенно тех, что не могут быть воспроизведены в виде видеофильмов, наиболее подходящим инструментом является анимация (нарисовать можно что угодно). Для объяснения же теоретических построений очень перспективным направлением представляется так называемая анимационная графика - графическое развертывание изучаемых процессов, заданных, например, аналитически. Современные пакеты прикладных программ позволяют графически изображать весьма сложные двух- и трехмерные зависимости. Фиксация соответствующих слайдов, дополненных пояснительными текстами и графикой, позволит создать великолепные фрагменты учебных материалов в виде анимационных фрагментов.

Аудиокомпоненты средств мультимедиа могут дополнять и обогащать видео фрагменты. Однако они могут иметь и важное самостоятельное значение, например, как средство активизации внимания, акцентирования на отдельные моменты излагаемого материала. Еще больший эффект дает применение аудиосопровождения тестирующих фрагментов. Важным перспективным направлением применения мультимедийных технологий является разработка виртуальных миров и их предшественников - мультимедиа тренажеров. В частности, первые проекты по сетевому подключению обучающегося к виртуальным лабораториям показали перспективность таких технологий. При этом возможно проведение лабораторных работ и исследований тех процессов, которые в реальных условиях невозможно реализовать практически или даже в принципе.

Мультимедиа продукты аккумулировали в себе три основные принципа мультимедиа:

1. Представление информации с помощью комбинации множества воспринимаемых человеком сред (собственно термин происходит от англ. multi - много, и media - среда);

2. Наличие нескольких сюжетных линий в содержании продукта (в том числе и выстраиваемых самим пользователем на основе "свободного поиска" в рамках предложенной в содержании продукта информации);

3. Художественный дизайн интерфейса и средств навигации

Методы представления графической информации

Традиционно используются два метода представления графической информации – растровый и векторный. При представлении графической информации в растровом виде используется технология хранения информации о каждом пикселе (pixel- picture element); пиксел является неделимой единицей - точкой изображения, данные обычно хранятся последовательно в формате одномерного массива, а ширина и высота изображения в пикселах описываются в заголовке файла), сохраняются данные о цвете (в единицах 21=2 цвета, 28=256 цветов и т.д.; также сохраняется информация о палитре – текущей таблице соответствий представляемого цвета и его кода). При моделировании объемных (трехмерных) объектов используется воксел (voxel – volume picture element).

Историческим аналогом данного метода явилась, вероятно, давно отработанная технология передачи и приема телевизионных изображений (такая же технология применяется при сканировании изображений). Типичным представителем этой методики является входящий в штатное cистемное ПО фирмы MS пакет Microsoft Paint; в настоящее время практически все графические редакторы поддерживают растровую графику. Практически все современные системы сохранения движущихся изображений (movie) используют растровый способ представления графической информации.

Вторым методом представления графических изображений является векторный способ. При этом неделимой единицей является вектор – определяемая начальной и конечной координатами прямая линия; атрибутами являтся цвет (включая палитру), толщина, тип (сплошная, штрих-пунктирная и т.д.) линии. Вырождением линии (вектора) является точка (фактически растровый способ представления графической информации).

На основе векторов строятся и более сложные графические примитивы – дуги, овалы, гладкие линии произвольной формы и т.д. Данный метод является естественным для представления информации в виде чертежей, типичным представителем является пакет создания чертежной документации AutoCAD (соответствующие файлы формата DXF являются текстовыми и содержат описания графических примитивов в векторном виде); другим представителем пакетов векторной графики является CorelDraw (www.corel.com). Размеры файлов при векторном способе обычно значительно меньше, скорость же отрисовки изображений на устройствах вывода практически не отличается. Это объясняется почти 100% применением растровых дисплеев (применение векторных дисплеев в настоящее время ограничено), при этом изображение любых векторных примитивов сводится к (программной) конвертации в растровый формат; используется линейная или круговая интерполяция путем ‘засвечивания’ ближайших к вектору точек растра по методу Брезенхама (Bresenham).

Заметим, что векторные графопостроители в настоящее время широко распространены и хорошо согласуются (по форматам передаваемых данных) с технологией векторной графики.

Конвертация между двумя указанными видами представления графической информации тривиальна лишь при переходе от векторной к растровой графике (метод Брезенхама), обратный переход требует значительных ухищрений (известны, например, конверторы сканированных растровых

изображений в векторный формат AutoCAD’а; при этом особенная сложность заключается в распознавании участков растра в районе ‘стыковки’ векторов, что обычно требует вмешательства оператора).

Существенно различаются для векторной и растровой графики процедуры линейного масштабирования. Если объекты векторной графики масштабируются элементарно, масштабирование растровой графики существенно сложнее (примитивное масштабирование в этом случае приводит лишь к превращению пикселов в прямоугольные образования) – применяются специальные алгоритмы заполнения и сглаживания. Однако эти и более сложные (нелинейные преобразования) легко реализуются вычислительными возможностями ПЭВМ. Более сложные функции класса повышения резкости, оконтуривания, выделения градиентов и

областей с заданными свойствами и др. определены лишь для растровой графики; большой набор предопределенных фильтров для подобных преобразований доступен в пакете Adobe Photoshop (www.adobe.com), задаваемые пользователем фильтры удобноприменимы в пакете Paint Shop Pro (фирма Jasc, Inc).

Одна из простых операций такого рода – локальная цифровая фильтрация, осуществляемая путем взвешенного суммирования яркостей пикселов, находящихся в некоторой окрестности текущего пиксела.

Текстовые данные в мультимедиа

Текстовые данные (независимо от типа письма - иероглифического, алфавитного, смешанного) фактически являются частью представления информации в виде статических изображений (графики) и в целом описываются, обрабатываются и представляются теми же методами. Особенностью текста является его вторичность (по отношению к первичности речи, кодовым выражением которой текст формально и является), вследствие чего появляются дополнительные функции ММС: распознавания речи и обратная - речевого воспроизведения текста; эти функции становятся штатными даже для ОС (в частности, небызызвестного проекта Merlin фирмы IBM). К сходным проблемам относится и вопрос распознавания символов (технология OCR - Optical Character Recognition), в настоящее время удовлетворительно решенный даже в ‘карманных’ ПЭВМ и машинного перевода (в том числе перевода ‘на лету’ в сети InterNet - например, приложение Promt WebView. Фирма MS на сайте www.microsoft.com/downloads предлагает специализированную библиотеку разработчика систем распознавания речи Microsoft Speech API, системы распознавания и преобразования текста в речь Microsoft Speech Recognition и Microsoft Text-to-Speech; функциями речевого управления должен обладать пакет MS Office 10.

Символы внутримашинно представлены численным кодом (обычно 8-ю двоичными разрядами, перспективная кодировка UNICODE использует 16 бит и позволяет единообразно представить символы 216= 65536 языков мира); наличие оставшихся от первых лет компьютерной эпохи нескольких таблиц кодировок (‘кодовых страниц’ - например, Windows-1251, Koi8-R и др.) создает трудности при работе. Наиболее распространенным в среде Windows текстовым (с элементами графики) редактором (текстовым процессором) является MS Word (www.microsoft.com/rus), из популярных настольных издательских систем следует упомянуть Adobe PageMaker (www.adobe.com), Xerox VenturaPublisher (www.xerox.com) и Quark XPress (Quark, Inc., www.quark.com).

Действие OCR-систем заключается в сопоставлении печатным символам (обычно представляемым в виде сканированного изображения) кодовому набору алфавита, ‘понимаемому’ конкретным ПО обработки текстов (изображению символа ставится в соответствие его числовой код). Одной из распространенных OCR-систем является FineReader фирмы ABBYY Software. Последние версии продуктов этой фирмы (ABBYY FineReader Рукопись) позволяют распознавать формы (технология Document Capture - ‘захват документа’), например, бланки налоговых деклараций (с занесением информации из определенных полей бланка в поля базы данных).

Комплекс Cognitive Forms принадлежит к классу OCR/ICR/OMR (Optical Character Recognition / Intelligent Character Recognition / Optical Mark Recognition - оптическое распознавание печатных символов / распознание рукописных символов / оптическое распознание меток) и реализует трехуровневую технологию распознания. Для представления текстовой информации в приятной человеку форме используются шрифты. Шрифт (гарнитура) - набор символов, схожих по графическим особенностям. Начертание описывает характерные особенно сти шрифта (bold - жирный, italic - курсивный, normal - прямой). Кегль, или размер шрифта (size) определяется высотой прописной буквы, измеренной в пунктах (points); один пункт равен 1/72 дюйма (0,353 мм), в шрифте размером 12 пунктов прописные буквы имеют высоту 1/6 дюйма.

Эффекты предоставляют возможность применить к выбранному шрифту различные способы оформления - подчеркивание, зачеркивание, оконтури вание, капитель, закрашивание в различные цвета и т.п. Растровые шрифты имеют фиксированные форму и размеры (например, шрифт MS Sans Serif), причем при масштабировании (только целочисленном) форма символов искажается (возникает ‘ступенька’). Векторные (масштабируемые, контурные) шрифты (например, Modern) строятся ‘точка за точкой’ при помощи специального штатного для OC Windows ПО (GDI - Graphic Device Interface) и допускают масштабирование в любое число раз без искажений, однако для их отрисовки требуются значительные ресурсы. Именуемая TrueType разновидность векторных шрифтов (например, Arial) пригодна для вывода как на экран так и на принтер и допускает масштабирование на размер от 1 до 999 пунктов. Близкими к TrueType являются шрифты в формате PostScript (предложенный Adobe и ставший всеобщим стандартом язык описания макета страницы, PostScript обеспечивает высококачественный вывод изображений, графики и текста, поддерживая при этом повороты, увеличение и уменьшение символов, для вывода изображений используется интерпретатор PostScript в принтере или в ПЭВМ); для принтеров Hewlett-Packard LaserJet, DeskJet возможно использование технологии PCL (Printer Control Language), позволяющей осуществлять форматирование распечатываемой страницы в самом принтере.

Шрифты типа TrueType при отрисовке строятся на основе реперных точек, соединенных плавными кривыми (используются квадратичные B-сплайны); ОС Windows имеет штатный набор функций для работы с этими кривыми. Современное ПО создания новых шрифтов (Fontographer фирмы Macromedia, Inc., Font Lab фирмы Adobe и др.) позволяет разрабатывать формы символов в графическом диалоге с пользователем, задавая базовые точки и соединяя их кривыми. Деятельность разработчиков шрифтов координирует ежегодная конференция ATypI (Association Typographique Internationale).

Чисто технической сложностью является работа пользователя с текстовыми данными на фоне (растровой или векторной графики). В примитивных графических редакторах класса MS Paint после ввода текста его редактирование невозможно, так как он преобразуется в растр. В более мощных редакторах текст сохраняется как отдельный объект (с указанием аттрибутов - фонта, размера, цвета и др.) и при этом отображается в растровом или векторном виде; редактирование объекта позволяет легко изменять текст (и его аттрибуты).

Звуковая информация

Звук представляет собой колебания физической среды (обычно воздуха) частотой приблизительно 20 ÷20000 Гц, все современные системы обработки звука основаны на преобразовании этих колебаний в электрический сигнал, последующей его (аналоговой или цифровой) обработки и вывода вновь в виде колебаний физической среды. Эффект стереофонии достигается временной разницей колебаний, легко улавливаемой благодаря наличию приблизительно 20-сантиметровой базы между приемниками аудиоинформации – ушами (разница порядка 7×10-4 сек).

В самом начале своей истории компьютер фирмы IBM был оснащен примитивным динамиком, позволявшем (посредством драйвера SPEAKER.DRV) воспроизводить звуки (одновременно) одного тона без регулировки уровня звука; именно в это время были разработаны основные принципы преобразования звука для бытовых компьютеров.

Первый шаг к более серьезной работе со звуком был сделан в 1987 г., когда фирма Creative Labs (www.creative.ru) разработала Creative Music System (C/MS), представлявший собой 12-голосный стереомузыкальный синтезатор, начавший распространяться в 1989 г. под маркой Game Blaster. Огромный коммерческий успех этой карты привел в скором времени к появлению других подобных карт, наиболее известной из которых являетсякарта AdLib; в основе их функционирования лежит методё известный как нижеописанный ‘синтез путем частотной модуляции’ (FM Syntesis, см. ниже).

Запись произвольного звука осуществляется путем прямой оцифровки аналогового сигнала, представляющего собой электрическую копию звукового давления (преобразователем является датчик звукового давления микрофон). Частота оцифровки (частота преобразования) называется частотой выборки сигнала и по известной теореме Котельникова-Найквиста должна быть не ниже удвоенного значения максимальной частоты преобразуемого сигнала (например, если спецификация MPC Level 1 определяет частоту преобразования 11 kГц, то верхний предел записываемой частоты составляет около 5 kГц).

Преобразование аналогового сигнала в цифровую форму выполняет аналого-цифровой преобразователь (АЦП), служащий для дискретизации сигнала по времени (частота оцифровки) и квантования по уровню (собственно цифровое представление сигнала). Обычно в АЦП применяется технология преобразования с импульсно-кодовой модуляцией (PCM, Pulse Code Modulation). Временные промежутки между моментами преобразования сигнала называют интервалами выборки (Sampling Interval); эта величина обратно пропорциональна частоте выборки, или сэмплингом (Sampling Rate). Амплитуда аналогового сигнала (Sample Value) при каждом преобразовании делится (квантуется) по уровню и кодируется в соответствующий параллельный цифровой код (Digital Sample), время преобразования аналогового сигнала в цифровой код именуется временем выборки (Sampling Time), рис. 1.

Разрешающей способностью АЦП называется наименьшее значение аналогового сигнала, которое приводит к изменению цифрового кода. Например, если АЦП выдает 8-разрядный код, разрешающая способность равна 1/(28)=1/256 от максимальной амплитуды аналогового сигнала (около 0,4% в относительных единицах), 16-разрядный АЦП имеет точность представления сигнала не хуже 1/(216)=1/65536 (0,0015%).

Рис. 1. Характеристики процесса преобразования между аналоговым и цифровым сигналами

С увеличением разрядности АЦП растет его динамический диапазон (каждый дополнительный бит соответствует увеличению приблизительно на 6 дБ). 8-разрядное преобразование обеспечивает динамический диапазон 48 дБ (качество кассетного магнитофона), 12-разрядное – 72 дБ (качественный катушечный магнитофон), 16-разрядное – 96 дБ (качество аудиокомпакт-диска). Полученный с АЦП параллельный код разрядностью 8 ÷16 последовательно (побитно) записывается с частотой сэмплинга в аудиофайл (при необходимости используется буфферизация), при этом поток несжатых цифровых аудиоданных велик.

Межпрограммный интерфейс

Межпрограммный интерфейс взаимодействия CPI-C представляет собой программный интерфейс приложений, или API, который обеспечивает соединение (диалог) между программами в среде SNA . Интерфейс CPI-C обеспечивает возможность совместной работы прикладных программ, расположенных в географически удаленных узлах сети. Взаимодействуя друг с другом, такие программы могут решать различные общие задачи, например, осуществлять связь с удаленной базой данных, копировать удаленные файлы, обмениваться сообщениями электронной почты и т.д.

Для обеспечения такого взаимодействия в среде SNA необходимы различные элементы оборудования и программного обеспечения. На рис. 4 показаны эти элементы и связи между ними.

Рис. 4. Взаимодействие между программами

Каждая сетевая программа связана с логическим устройством LU, которое является для нее точкой доступа в сеть. С точки зрения прикладной программы LU выступает в качестве интерфейса, который она использует для установки связи с другой программой через сеть. Интерфейс CPI-C использует LU типа 6.2, которые поддерживают соединение между логическими устройствами. Прежде чем две программы смогут начать взаимодействие, их LU должны быть соединены между собой через сессию, которая является логической связью между двумя LU. Сессия устанавливается при включении особого режима, определяющего набор сетевых параметров, указывающих способ использования сессии. LU типа 6.2 могут обеспечить множественную сессию (две или более конкурирующих сессий с одним и тем же взаимодействующим LU).

Прикладные программы имеют доступ к интерфейсу CPI-C через вызовы CPI-C. Каждый вызов выполняет определенные действия, такие, как начало или завершение диалога, передача или прием данных, установка режимов и т.п. Программа, выполнившая вызов, рассматривается как локальная, другая программа считается удаленной. Вызовы CPI-C доступны для программ, написанных на различных языках программирования.

APPC (Advanced Program-to-Program Communications) - протокол, разработанный IBM и позволяющий приложениям работать на различных компьютерах и непосредственно обмениваться данными . Протокол APPC реализован как программное обеспечение, функционирующее в рамках различных операционных систем IBM и других типов. Он может являться или частью собственно ОС, или устанавливаться как отдельный программный пакет.

Протокол APPC выступает в качестве связующего звена между прикладными программами и сетью. Когда прикладная программа на локальной ЭВМ - источнике - передает информацию протоколу APPC, последний преобразует ее соответствующим образом и отправляет сетевому интерфейсу, например адаптеру локальной сети. Далее информация передается через сеть на ЭВМ - получатель, протокол APPC которой принимает ее от соответствующего сетевого адаптера. Далее протокол преобразует принятую информацию в исходный формат и передает соответствующему прикладному процессу. Очевидно, что связь между системами в этом случае выполняется на одном уровне (одноранговая связь). Для обращения к протоколу APPC из прикладных программ используются функции интерфейса прикладных программ (API) различного назначения. Примером таких API могут служить функции протокола передачи файлов APPC File Transfer Protocol (AFTP), обеспечивающие возможность обмена файлами между удаленными прикладными процессами. Для взаимодействия между прикладными процессами протокол APPC пользуется сессиями, установленными с помощью вызовов CPI-C, однако эти действия являются прозрачными для взаимодействующих процессов.

Распределенные базы данных

Под распределенной (Distributed DataBase - DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику. ("распределенность" базы данных невидима извне).

Определение Дэйта

Лучшее определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date). Он установил 12 свойств или качеств идеальной DDB:

• Локальная автономия (local autonomy)

• Независимость узлов (no reliance on central site)

• Непрерывные операции (continuous operation)

• Прозрачность расположения (location independence)

• Прозрачная фрагментация (fragmentation independence)

• Прозрачное тиражирование (replication independence)

• Обработка распределенных запросов (distributed query processing)

• Обработка распределенных транзакций (distributed transaction processing)

• Независимость от оборудования (hardware independence)

• Независимость от операционных систем (operationg system independence)

• Прозрачность сети (network independence)

• Независимость от баз данных (database independence)

Локальная автономия. Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы.

Независимость от центрального узла. В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа.

Непрерывные операции. Это качество можно трактовать как возможность непрерывного доступа к данным (известное "24 часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно".

Прозрачность расположения. Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.

Прозрачная фрагментация. Это свойство трактуется как возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам.

Целостность данных

В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB - достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции - СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.

Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.

Архитектура "клиент-сервер"

Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели "клиент-сервер" (подробно о них рассказано в):

• Модель доступа к удаленным данным (RDA-модель)

• Модель сервера базы данных (DBS-модель)

• Модель сервера приложений (AS-модель)

Первые две являются двухзвенными и не могут рассматриваться в качестве базовой модели распределенной системы (ниже будет показано, почему это так). Трехзвенная модель хороша тем, что в ней интерфейс с пользователем полностью независим от компонента обработки данных. Собственно, трехзвенной ее можно считать постольку, поскольку явно выделены:

• Компонент интерфейса с пользователем

• Компонент управления данными (и базами данных в том числе)

а между ними расположено программное обеспечение промежуточного слоя (middleware), выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и множество других. Middleware - это ГЛАВНЫЙ компонент распределенных систем и, в частности, DDB-систем. Главная ошибка, которую мы совершаем на нынешнем этапе - полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для реализации распределенных систем.

Существует фундаментальное различие между технологией "SQL-клиент - SQL-сервер" и технологией продуктов класса middleware (например, менеджера распределенных транзакций Tuxedo System). В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка- точка", для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle SQL*Net). Он строится двумя процессами: SQL/Net на компьютере - клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором CONNECT. Канал закрыт в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL- запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые, например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).

В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.

Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей открытых SQL-запросов и данных, исключающую возможность модификации и работающую только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие между ними многочисленными способами.

Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL (ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic, PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то для создания корпоративных распределенных информационных систем он абсолютно непригоден.

Для этих задач необходимо применение существенно более гибких систем класса middleware (Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности и базовый инструментарий при реализации больших проектов.

Сегодня можно считать, что распределенные базы данных - тема достаточно локальная и далеко не так актуальная, как архитектура распределенных систем. В DDB-технологии за последние 2-3 года не было каких-либо существенных новаций (за исключением, быть может, технологии тиражирования данных). Можно считать, что в этой сфере информатики все более или менее устоялось и каких-либо революционных шагов не предвидится. Более интересное направление (включающее DDB) - архитектура, проектирование и реализация распределенных информационных систем. "Горячие" темы в этом направлении - системы с трехзвенной архитектурой, продукты класса middleware, объектно-ориентированные средства разработки распределенных приложений в стандарте CORBA. Их активное применение будет доминировать в отечественной информатике в ближайшие 3-5 лет и станет технологической базой реальных интеграционных проектов.

Мне кажется, что революция произойдет в архитектуре корпоративных информационных систем. Технологический взрыв в Intertet, создание и супербурное развитие Всемирной паутины, технология Java, неизбежно отразятся на организации инфраструктуры корпораций. На мой взгляд, очевидные преимущества гипертекстовой организации данных (гибкость, открытость, простота развития и расширения) перед жесткими структурами реляционных баз данных, по своей природе плохо приспособленными для расширения, предопределяют использование HTML в качестве одного из основных средств создания информационного пространства компании. Подход, опирающийся на гипертексты, позволяет без особых проблем интегрировать уже существующие информационные массивы, хранящиеся в базах данных. То, что сейчас называют Intranet - это прообраз будущей корпоративной информационной системы.

Средства и методологии проектирования, разработки и сопровождения Intranet и Internet-приложений

Intranet-приложение - это корпоративная система, для организации которой используются механизмы Internet. Intranet-система может основываться на локальной сети компьютеров, собственной корпоративной глобальной сети или виртуальной корпоративной подсети Internet. Различают несколько типов Intranet-систем, для реализации каждого из которых, вообще говоря, применяются разные средства:

1. Коммуникационные Intranet-системы предназначены главным образом для связывания территориально разнесенных подразделений корпорации, уменьшая потребность в многочисленных выделенных линиях связи. При реализации систем этого типа следует обращать особое внимание на эффективность, соответствие стандартам и управляемость системы.

2. Интегрирующие Intranet-системы служат для интеграции разнородных существующих коммуникационных и обрабатывающих корпоративных подсистем. С этой точки зрения достоинством Intranet-системы является поддержка общего интерфейса доступа к "унаследованным" системам и установление связи между ними за счет понимаемого всеми гипертекстового представления информации.

3. Если от Intranet-системы требуется обеспечение широкого доступа к большим объемам информации, в частности, мультимедийной, то особое внимание требуется уделить выбору базового сервера баз данных. Нужно учитывать возможности сервера по части управления очень большими данными и поддержки сложных типов данных.

4. Intranet-системы с упрощенной для пользователей процедурой доступа обычно основываются на механизме электронной подписи. Такие системы должны быть особенно надежно защищены от внешнего мира.

Конечно, в общем случае информационная Intranet-система может включать свойства каждого из перечисленных типов, и в этом случае при ее разработке придется учитывать все требования.

Естественно, эта часть курса не может заменить развернутого изложения принципов построения, администрирования и сопровождения Intranet-систем. Эта тема очень широка, и мы только бегло рассмотрим некоторые ее аспекты.

Основные понятия Intranet

Поскольку для разработки Intranet-систем используются методы и средства Internet, и главным образом, технология WWW, то и понятия и термины Internet и Intranet совпадают. Приведем некоторые из них:

HTTP (HyperText Transfer Protocol) - протокол обмена гипертекстовой информацией;

URL (Universal Resource Locator) - универсальный локатор ресурсов. Используется в качестве универсальной схемы адресации ресурсов в сети.

HTML (HyperText Markup Language) - язык гипертекстовой разметки документов. Специальная форма подготовки документов для их опубликования в World Wide Web.

CGI (Common Gateway Interface) - спецификация на формат обмена данными между сервером протокола HTTP и прикладной программой.

API (Application Program Interface) - в данном контексте это спецификация, определяющая правила обмена данными между сервером и программным модулем, который должен быть включен в состав сервера.

VRML (Virtual Reality Modeling Language) - язык описания трехмерных сцен и взаимодействия трехмерных объектов.

Javaapplets - мобильные (независимые от архитектуры "железа") программные коды, написанные на языке программирования Java.

Java - объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems и используемый в качестве основного средства мобильного программирования.

MIME (Multipurpose Internet Mail Exchange) - формат почтового сообщения Internet. В данном контексте стандарт MIME используется для установления соответствия между типом информационного файла, именем этого файла и программой просмотра этого файла.

CCI (Common Client Interface) - спецификация обмена данными меду прикладной программой и браузером Mosaic. В случае применения программного обеспечения, выполненного согласно CCI, браузер превращается в сервер-посредник для программного обеспечения пользователя.

Языки и протоколы

Исходя из важности технологии WWW для построения корпоративных Intranet-систем, мы для начала коротко рассмотрим два базовых компонента этой технологии - язык гипертекстовой разметки документов HTML и протокол обмена гипертекстовой информацией HTTP.

HTTP HTTP - это протокол прикладного уровня, разработанный для обмена гипертекстовой информацией в сети Internet. Протокол используется одной из популярнейших систем Сети - Word Wide Web - с 1990 года.

Реальная информационная система требует гораздо большего количества функций, чем просто поиск. HTTP позволяет реализовать в рамках обмена данными набор методов доступа, базирующихся на спецификации универсального идентификатора ресурсов (Universal Resource Identifier), применяемого в форме универсального локатора ресурсов (Universe Resource Locator) или универсального имени ресурса (Universal Resource Name). Сообщения по сети при использовании протокола HTTP передаются в формате, схожим с форматом почтового сообщения Internet (RFC-822) или с форматом сообщений MIME (Multiperposal Internet Mail Exchange). HTTP используется для взаимодействия программ-клиентов с программами-шлюзами, разрешающими доступ к ресурсам электронной почты Internet (SMTP), спискам новостей (NNTP), файловым архивам (FTP), системам Gopher и WAIS. Протокол разработан для доступа к этим ресурсам посредством промежуточных программ-серверов (proxy), которые позволяют передавать информацию между различными информационными службами без потерь. Протокол реализует принцип "запрос/ответ". Запрашивающая программа - клиент - инициирует взаимодействие с отвечающей программой - сервером, и посылает запрос, включающий в себя метод доступа, адрес URI, версию протокола, похожее по форме на MIME-сообщение с модификаторами типа передаваемой информации, информацию клиента, и, возможно, тело сообщения клиента. Сервер отвечает строкой состояния, включающей версию протокола и код возврата, за которой следует сообщение в форме, похожей на MIME. Данное сообщение содержит информацию сервера, метаинформацию и тело сообщения. Понятно, что в принципе, одна и та же программа может выступать и в роли сервера и в роли клиента (так собственно и происходит при использовании proxy-серверов).

При работе в Internet для обслуживания HTTP-запросов используется 80 порт TCP/IP. Практика использования протокола такова, что клиент устанавливает соединение и ждет ответа сервера. После отправки ответа сервер инициирует разрыв соединения. Таким образом, при передаче сложных гипертекстовых страниц соединение может устанавливаться несколько раз. Остановимся более подробно на механизме взаимодействия и форме передаваемой информации.

Форма запроса клиента

Программа-клиент посылает после установления соединения запрос серверу. Этот запрос может быть в двух формах: в форме полного запроса и в форме простого запроса. Простой запрос содержит метод доступа и запрос ресурса. Например:

GET http://polyn.net.kiae.su/

В этой записи слово GET обозначает метод доступа GET, а http://polyn.net.kiae.su/ - это запрос ресурса. Клиенты, которые способны поддерживать версии протокола выше 0.9 должны пользоваться полной формой запроса. При использовании полной формы в запросе указываются строка запроса, несколько заголовков (заголовок запроса или общий заголовок) и, возможно, тело обозначения ресурса. В форме Бекуса-Наура общий вид полного запроса выглядит так:

:= ( )[]

Квадратные скобки здесь обозначают необязательные элементы заголовка. Строка запроса - это, практически, простой запрос ресурса. Отличие состоит в том, что в строке запроса можно указывать различные методы доступа и за запросом ресурса следует указывать версию протокола. Например, для вызова внешней программы можно использовать следующую строку запроса:

POST http://polyn.net.kiae.su/cgi-bin/test HTTP/1.0

В данном случае используется метод POST и протокол версии 1.0.

Методы доступа

В настоящее время в практике World Wide Web реально используются только три метода доступа: POST, GET, HEAD.

GET - метод, позволяющий получить данные, заданные в форме URI в запросе ресурса. Если ссылаются на программу, то возвращается результат выполнения этой программы, но не текст программы. Дополнительные данные, которые надо передать для обработки, кодируются в запрос ресурса. Имеется разновидность метода GET - условный GET. При использовании этого метода сервер ответит на запрос только в том случае, если будут выполнены условия передачи. Это позволяет разгрузить сеть, избавив ее от передачи ненужной информации. Условие указывается в поле "if-Modified-Since" заголовка запроса. При использовании метода GET в поле тела ресурса возвращается собственно затребованная информация (текст HTML-документа, например).

HEAD - метод, аналогичный GET, но не возвращает тела ресурса. Используется для получения информации о ресурсе. Условного HEAD не существует. Данный метод используется для тестирования гипертекстовых ссылок.

POST - этот метод разработан для передачи большого объема информации на сервер. Им пользуются для аннотирования существующих ресурсов, посылки почтовых сообщений, работы с формами интерфейсов к внешним базам данных и внешним исполняемым программам. В отличии от GET и HEAD, в POST передается тело ресурса, которое и является информацией из поля форм или других источников ввода. В первых версиях протокола были определены и другие методы доступа (DELETE, например), но они не нашли должного применения. Многие функции, которые возлагали на эти методы, можно успешно выполнять через POST.

Изменение числа методов доступа отражает практику использования HTTP. Однако, с исторической и методической точек зрения, первые версии протокола представляют несомненный интерес, особенно раздел, описывающий методы доступа. В версии 1993 года насчитывалось 13 различных методов доступа. Среди этих методов были такие, например, как:

CHECKOUT - защита от несанкционированного доступа;

PUT - замена содержания информационного ресурса;

DELETE - удаление ресурса;

LINK - создание гипертекстовой ссылки;

UNLINK - удаление гипертекстовой ссылки;

SPACEJUMP - переход по координатам;

SEARCH - поиск.

Из этого списка видно, что протокол был действительно максимально ориентирован на работу с гипертекстовыми распределенными системами, причем не только с точки зрения потребителя, но и с точки зрения разработчика подобных систем. Однако, во-первых, как показывал опыт, практически не использовались методы доступа, связанные с изменением информации. Это объясняется прежде всего соображениями безопасности. Ни один администратор не позволит неизвестно кому менять информацию на его сервере. Во-вторых, методы SPACEJUMP и SEARCH были с успехом заменены на функционально аналогичные CGI-скрипты. Из этого не следует, что их возрождение невозможно, например, в язык гипертекстовой разметки вернулись ссылки, общие для всего документа, но пока их реализация в протоколе отложена. В-третьих, не нашли практической реализации методы установления/удаления ссылок LINK и UNLINK. Но необходимость в них растет и связана она с реорганизацией сети. Многие информационные ресурсы меняют свои адреса, что вносит беспорядок в структуру сети, где и без этого начинающему пользователю трудно что-либо найти. Одним словом, вопрос о новых методах доступа все еще открыт, поэтому, видимо, спецификация HTTP еще не вышла на стадию RFC и остается в виде Internet Draft.

В обеих формах запроса важное место занимает форма запроса ресурса, которая кодируется в соответствии со спецификацией URI. Применительно к World Wide Web эта спецификация получила название URL. При обращении к серверу можно использовать как полную форму URL, так и упрощенную.

Полная форма содержит тип протокола доступа, адрес сервера ресурса, и адрес ресурса на сервере (рис 1).

Рис. 1. Полный адрес ресурса

Однако такой адрес реально нужен для работы через промежуточный сервер, так как тот может пересылать запросы. При обращении к первичному серверу клиент может опускать протокол и адрес, устанавливая взаимодействие с сервером по адресу, указанному в URL (в исходном документе), и порту 80, передавая только путь от корня сервера.

Здесь пока оставим обсуждение элементов запроса и обратимся к структуре ответа сервера. Дело в том, что элементы заголовков запроса и ответа одинаковые, и поэтому их имеет смысл обсудить после определения структуры ответа сервера.

Ответ сервера

Ответ сервера может быть, как и запрос, упрощенным или полным. При упрощенном ответе сервер возвращает только тело ресурса (например, текст HTML-документа). При полном ответе клиенту возвращается строка состояния (Status-Line), общий заголовок, заголовок ответа, заголовок ресурса и тело ресурса. В форме Бекуса-Наура полный ответ представляется следующим образом:

:= ( ) []

Строка состояния состоит из версии протокола, кода возврата и краткого описания этого кода. Например, она может выглядеть так:

"HTTP/1.0 200 Success".

Заголовок ответа сервера может состоять из адреса URI запрашиваемого ресурса, и/или наименования программы сервера, и/или кода идентификации для работы в защищенном режиме. Состав полей заголовка ресурса является общим и для запроса клиента и для ответа сервера, и состоит из разрешения на метод доступа, типа кодировки тела ресурса (содержания ресурса), длины тела ресурса, типа ресурса, время действия данной копии ресурса, времени последнего изменения ресурса и расширения заголовка.

Рассмотрим более подробно поля заголовка, обращая внимание на реальное применение каждого из них и возможность проявления ошибок при обработке этих полей разными программами (серверами и клиентами).

Если в заголовке ответа сервера указано предложение Location, то это значит, что требуемый ресурс находится по другому адресу и его надо запросить заново. Такая процедура называется перенаправлением. Перенаправление в заголовке будет выглядеть как:

Location: http://apollo.polyn.kiae.su/risk/riskform.html

Имя и версия сервера указываются в поле Server. При использовании сервера CERN данное поле будет выглядеть как:

Server: CERN/3.0 libwww/2.17

В заголовке может встречаться и поле контроля доступа WWW-Authenticate, которое определяет способ доступа к закрытым ресурсам. Например, это поле может выглядеть как:

WWW-Authenticate: Basic realm="WallyWorld"

Кроме рассмотренных выше полей, в заголовке могут встретиться и другие поля, которые определяют содержание тела передаваемого ресурса. Эти поля относятся к заголовку ресурса, но в ответе сервера они встречаются вперемешку с общими полями. Поле Allow определяет разрешенные методы доступа к ресурсу:

Allow: GET,HEAD Поле Сontent-Encoding определяет тип кодирования передаваемого ресурса:

Content-Encoding: x-gzip

В данном случае указывается, что ресурс является заархивированным файлом в формате zip. Обычно ресурсы хранятся в виде, указанном в данном поле, и при их получении клиент должен обеспечить их преобразование в приемлемый для отображения вид. Это своего рода предобработка данных, которая базируется обычно на MIME типах. В машинах, где недостаточно памяти на видео-адаптерах, используют предобработку для преобразования изображений в приемлемый для отображения вид. Так, например, для персональных компьютеров с 512 КБ памяти на видеоадаптере используют предобработку для преобразования 256-цветных картинок в 16-цветные. Если этого не делать, то можно наблюдать интересный эффект: в Unix-системах при работе с программами Chimera и Mosaic 256-цветные картинки удваиваются, т.е. вместо одной на экране отображаются последовательно две картинки. Это связано с тем, что для 256 цветов нужно ровно в два раза больше памяти, чем для 16. Для того, чтобы избежать двойного отображения встроенных в текст картинок, их следует преобразовать.

Другим полем, которое проявляет себя при работе в сети, порождая ошибки отображения ранними версиями программ просмотра или ранним версиями программ серверов, является поле Content-Length. Поле Content-Length указывает размер (количество байтов) передаваемого ресурса. Это поле указывается как клиентом при работе по методу POST, так и сервером при ответе на запросы клиентов. При этом в ранних версиях программ-серверов может порождаться ошибка, вызванная возможностью вставки сервером некоторой информации в текст ресурса. Например, сервер NCSA (1.3) позволяет вставлять в текст HTML-документов фрагменты текста из других файлов при помощи выражения типа:

В данном случае речь идет об общей заставке для всех документов некоторого раздела. На сервере в директории документов хранится файл одного размера, но после выполнения подстановки размер файла увеличивается, однако, сервер сообщает клиенту старый размер файла. Новые программы-клиенты (Netscape, Mosaic) неправильно обрабатывают такой ответ и информация не отображается.

Поле Content-Type определяет тип информации, передаваемой сервером. Наиболее часто используются типы text/play - простой тест и text/html - документ в формате HTML. Для сокращения трафика по сети существует несколько полей, связанных со временем передачи информации и периодичностью ее изменения на серверах. Поле Date определяет время отправки сообщения. Информация из данного поля сохраняется в файле статистики сервера и может быть использована для анализа доступа к ресурсам сервера из сети.

Поле Expires определяет время годности ресурса для использования. Если время использования вышло, то ресурс не должен передаваться. Точнее, его не следует передавать и принимать. О поле if-Modified-Sience уже упоминалось. Оно предназначено для того, чтобы не передавать имеющиеся у клиента копии ресурса, если не были произведены его изменения. Поле Pragma используется при передаче сообщений с сервера на сервер. Реально известно только одно значение данного поля: no-cache, которое запрещает запоминать в буфере данные для последующего использования.

Поле Referer используется для того, чтобы указать, из какого ресурса была осуществлена ссылка на ресурс. Данное поле - это мечта любого администратора базы данных сети. При помощи информации из этого поля можно определить, в каких WWW-страницах прописан конкретный сервер. От этого зависит количество обращений к серверу, "качество" пользователей, время отклика на информацию, размещаемую на сервере. При необходимости можно связаться с администратором этого сервера и уведомить его об изменениях на вашем сервере.

Защита сервера от несанкционированного доступа

Отдельное место при обсуждении протокола занимают вопросы, связанные с обеспечением защиты ресурсов сервера от несанкционированного доступа. Как было отмечено в предыдущих разделах, первоначально разработка защищенных способов обмена данными в системе World Wide Web не предполагалась. Однако быстрое развитие популярности системы привело к тому, что многие коммерческие организации стали устанавливать серверы HTTP на свои машины. Кроме этого, конфиденциальной информации много и в научно-исследовательских государственных организациях. Таким образом, возникла необходимость в разработке механизмов защиты информации для системы WWW.

Проблема защиты информации на Internet - это отдельная большая тема. В данном разделе мы рассмотрим только обеспечение безопасности при использовании серверов HTTP.

Первая связана с чтением защищенных текстовых файлов. Для решения этой задачи имеется достаточно много традиционных механизмов, встроенных в операционные системы. Проблема возникает, если администратор системы решит использовать для размещения WWW-файлов и FTP-архива одно и тоже дисковое пространство. В этом случае защищенные WWW-файлы окажутся доступными для "анонимного" FTP-доступа. Многие серверы разрешают создавать в дереве поддерживаемых ими документов "домашние" страницы пользователей с помощью методов POST и GET. Это значит, что пользователи могут изменять информацию на компьютере сервера. Данные, вводимые пользователем, передаются как тело ресурса при методе POST через стандартный ввод, а методе GET через переменные окружения. Естественно, что разрешение создания файлов на сервере протокола HTTP создает потенциальную опасность доступа к защищенной информации лиц, не имеющих права доступа к ней. Решается эта проблема путем создания специальных файлов прав пользователей сервера WWW.

Рис. 2. Схема управления ресурсов сервером HTTP

Вторая возможность проникновения в компьютерную систему через сервер WWW связана с CGI-скриптами. CGI-скрипт - это программа, которую сервер HTTP может запускать для реализации механизмов, не предусмотренных в протоколе. Многие достаточно мощные информационные механизмы WWW реализованы посредством CGI-скриптов. К ним относятся: программы поиска по ключевым словам, программы реализации графических гипертекстовых ссылок - imagemap, программы сопряжения с системами управления базами данных и т.п. Естественно, что при этом появляется возможность получить доступ к системным ресурсам. Обычно внешняя программа запускается с идентификатором пользователя, отличным от идентификатора сервера. Данный идентификатор указывается при конфигурировании сервера. Наиболее безопасным здесь является идентификатор пользователя nobody (65534). Основная опасность скриптов заключена в том, что данные в скрипт посылаются программой-клиентом. Для того, чтобы в качестве параметров не передавали "подозрительных" данных, многие серверы производят проверку параметров на наличие допустимых символов. Особенно опасны скрипты для тех, кто использует сервер на персональном компьютере с MS-Windows 3.1. В этом случае файловая система практически не защищена. Одной из характерных для скриптов проблем является размер входных данных. Многие "умные" серверы обрезают слишком большие входные потоки и тем самым защищают скрипты от "поломки". Кроме перечисленных выше опасностей, порождаемых природой сети и системы WWW, существует еще одна, связанная с такой экзотикой, как мобильные коды. Мобильный код - это программа, которая может передаваться по сети для выполнения ее клиентом. Код встраивается в WWW-страницу при помощи тага - application. Например, Sun выпустила WWW-клиента HotJava, который позволяет интерпретировать язык Java. Существуют клиенты и для других языков, Safe-Tcl для Tcl, например. Главное назначение таких средств - реализация мультимедийных страниц и реализация работы в rеal-time. Опасность применения такого сорта страниц очевидна, так как повторяет способ распространения различного сорта вирусов. Однако пока речи о защите от такого сорта "взломов" не идет, видимо в силу довольно ограниченного применения данной возможности в сети.

Практически любой сервер имеет механизм назначения паролей и прав доступа для различных пользователей, который базируется на схеме идентификации протокола HTTP 1.0. Данная схема предполагает, что программа-клиент посылает серверу идентификатор пользователя и пароль. Понятно, что такой механизм не обеспечивает защиты передаваемой по сети информации, и она может стать легкой добычей злоумышленников.

Для того, чтобы этого не происходило, в рамках WWW ведется разработка других схем защиты. Они строятся на двух широко известных принципах: контроль доступа по IP-адресам и шифрация. Первый принцип реализован в программе типа "стена" (Firewall). Сервер разрешает обращаться к себе только с определенных IP-адресов и выполнять только определенные операции. Слабое место такого подхода с точки зрения WWW заключается в том, что обратиться могут через сервер-посредник, которому разрешен доступ к ресурсам защищенного первичного сервера. Поэтому применяют шифрование паролей и идентификаторов по аналогии с системой "Керберос". На принципе шифрования построен новый протокол SHTTP, который реализован в серверах Netsite (последние версии), Apachie и в новых серверах CERN и NCSA. Однако реально широкого применения это программное обеспечение еще не нашло и находится в стадии развития, а потому содержит достаточно большое количество ошибок.

Завершая обсуждение протокола HTTP и способов его реализации, нужно отметить, что в качестве широко доступного информационного ресурса WWW уже состоялась, следующий шаг - серьезные коммерческие применения. Но для этого необходимо еще внедрить в практику защищенные протоколы обмена, базирующиеся на HTTP. В последнее время появилось много новых программ, реализующих протокол HTTP. Это серверы и клиенты, написанные как для новых компьютерных платформ, так и для возможностей SHTTP. Реальную возможность попробовать свои силы в разработке различных WWW-приложений имеют и отечественные программисты.

Серверы Intranet

В Intranet можно использовать все возможные сервисы Internet (например, электронную почту, возможности удаленного терминала и т.д.). Но мы остановимся на трех разновидностях серверов, которые наиболее активно используются в настоящее время.

FTP-серверы

FTP-архивы являются одним из основных информационных ресурсов Internet. Фактически, это распределенный депозитарий текстов, программ, фильмов, фотографий, аудио записей и прочей информации, хранящейся в виде файлов на различных компьютерах во всем мире.

Типы информационных ресурсов

Информация в FTP-архивах разделена на три категории:

1. Защищенная информация, режим доступа к которой определяется ее владельцами и разрешается по специальному соглашению с потребителем. К этому виду ресурсов относятся коммерческие архивы (например, коммерческие версии программ в архивах ftp.microsoft.com или ftp.bsdi.com), закрытые национальные и международные некоммерческие ресурсы (например, работы по международным проектам CES или IAEA), частная некоммерческая информация со специальными режимами доступа (частные благотворительные фонды, например).

2. Информационные ресурсы ограниченного использования, к которым относятся, например, программы класса shareware (Trumpet Winsock, Atis Mail, Netscape, и т.п.). В данный класс могут входить ресурсы ограниченного времени использования (текущая версия Netscape перестанет работать в июне если только кто-то не сломает защиту) или ограниченного времени действия, т.е. пользователь может использовать текущую версию на свой страх и риск, но никто не будет оказывать ему поддержку.

3. Свободно распространяемые информационные ресурсы или freeware, если речь идет о программном обеспечении. К этим ресурсам относится все, что можно свободно получить по сети без специальной регистрации. Это может быть документация, программы или что-либо еще. Наиболее известными свободно распространяемыми программами являются программы проекта GNU Free Software Foundation. Следует отметить, что свободно распространяемое программное обеспечение не имеет сертификата качества, но как правило, его разработчики открыты для обмена опытом.

Из выше перечисленных ресурсов наиболее интересными, по понятным причинам, являются две последних категории, которые, как правило, оформлены в виде FTP-архивов.

Технология FTP была разработана в рамках проекта ARPA и предназначена для обмена большими объемами информации между машинами с различной архитектурой. Главным в проекте было обеспечение надежной передачи и поэтому с современной точки зрения FTP кажется перегруженным излишними редко используемыми возможностями. Стержень технологии составляет FTP-протокол.

Протокол FTP

FTP (File Transfer Protocol или "Протокол Передачи Файлов") - один из старейших протоколов в Internet и входит в его стандарты. Обмен данными в FTP проходит по TCP-каналу. Построен обмен по технологии "клиент-сервер". На рис. 3 изображена модель протокола.

В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора пользователя средствами.

Рис. 3. Диаграмма протокола FTP

Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.

Сессия управления инициализирует канал передачи данных. При организации канала передачи данных последовательность действий другая, отличная от организации канала управления. В этом случае сервер инициирует обмен данными в соответствии с согласованными в сессии управления параметрами.

Канал данных устанавливается для того же host'а, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.

Возможна ситуация, когда данные могут передаваться на третью машину. В этом случае пользователь организует канал управления с двумя серверами и организует прямой канал данных между ними. Команды управления идут через пользователя, а данные напрямую между серверами (рис 4).

Рис. 4. Соединение с двумя разными серверами и передача данных между ними

Канал управления должен быть открыт при передаче данных между машинами. В случае его закрытия передача данных прекращается.

Режимы обмена данными

В протоколе большое внимание уделяется различным способам обмена данными между машинами различных архитектур. Действительно, чего только нет в Internet, от персоналок и Mac'ов до суперкомпьютеров. Все они имеют различную длину слова и многие различный порядок битов в слове. Кроме этого, различные файловые системы работают с разной организацией данных, которая выражается в понятии метода доступа.

В общем случае, с точки зрения FTP, обмен может быть поточный или блоковый, с кодировкой в промежуточные форматы или без нее, текстовый или двоичный. При текстовом обмене все данные преобразуются в ASCII и в этом виде передаются по сети. Исключение составляют только данные IBM mainframe, которые по умолчанию передаются в EBCDIC, если обе взаимодействующие машины IBM. Двоичные данные передаются последовательностью битов или подвергаются определенным в процессе сеанса управления преобразованиям. Обычно, при поточной передаче данных за одну сессию передается один файл данных, при блоковом способе за одну сессию можно передать несколько файлов.

Описав в общих чертах протокол обмена, можно перейти к описанию средств обмена по протоколу FTP. Практически для любой платформы и операционной cреды существуют как серверы, так и клиенты. Ниже описываются стандартные сервер и клиент Unix-подобных систем.

Сервер протокола - программа ftpd

Команда ftpd предназначена для обслуживания запросов на обмен информацией по протоколу FTP. Сервер обычно стартует в момент загрузки компьютера. Синтаксис запуска сервера следующий:

ftpd [-d] [-1] [-t timeout]

d - опция отладки;

1 - опция автоматической идентификации пользователя;

t - время пассивного ожидания команд пользователя.

Каждый сервер имеет свое описание команд, которое можно получить по команде help. Автоматическая идентификация пользователей осуществляется при помощи файла /etc/passwd. Пароль пользователя не должен быть пустым.

Существует специальный файл, в котором содержатся запрещенные пользователи, т.е. те, кому обслуживание по протоколу FTP запрещено. Возможен вход в архив по идентификатору пользователя anonymous или ftp. В этом случае сервер принимает меры по ограничению доступа к ресурсам компьютера для данного пользователя. Обычно для таких пользователей создается специальная директория ftp, в которой размещают каталоги bin, etc и pub. В каталоге bin размещаются команды, разрешенные для использования, а в каталоге pub собственно сами файлы. Каталог etc закрыт для просмотра пользователем и в нем размещены файлы идентификации пользователей.

В ряде случаев в директории pub создают каталог incoming. Этот каталог предназначен для того, чтобы пользователь мог записать в этот каталог свои программы или любые другие файлы. Однако, это довольно небезобидная, с точки зрения безопасности, операция.

В директорию bin обычно записывается только одна команда ls. Данная команда позволяет выполнять просмотр текущей директории. Согласно правилам, анонимный пользователь должен иметь возможность выполнять только те команды, которые размещены в этой директории. Однако, в большинстве систем анонимный пользователь выполняет гораздо больший набор команд, при этом эти команды берутся из стандартных директорий системы. Способность этого пользователя создавать директории, удалять файлы и т.п. будет зависеть от прав, которые установлены администратором для той ветви, файловой системы, в которой располагается файловый архив FTP. Так, например, в Windows NT можно так назначить права, что при входе пользователя с консоли он сможет получить доступ к системе, а при доступе к своему архиву FTP пользователь таких прав не получает, точнее пользователь нормально идентифицируется и проходит аутентификацию, но после этого получает сообщение, что не обладает нужными правами для доступа к своей домашней директории. При этом данная проблема в рамках программ настроек Internet Information Services не решается. Приходится использовать стандартные средства Windows, определяющие эти права.

Другую опасность для системы представляют ссылки. Многие администраторы полагают, что взлом системы - это ситуация, когда злоумышленник проник в систему, однако это не так. Например, в классификации CERT тяжелый взлом - это, в том числе и выявление структуры файловой системы. В этом случае атакующий получает информацию о предмете атаки и может сосредоточить свои усилия на каком-то отдельном фрагменте системы.

Если в директорию etc не скопировать файл passwd, то никто не сможет получить доступ к данным FTP-архива. Однако, часто копируют настоящий файл паролей. Этого делать не следует. Во всяком случае следует убедиться в том, что поле паролей в записях описания пользователей должно быть пустым. Клиент FTP только проверяет наличие пользователя и наличие у него пароля, а идентификация проводится стандартным для системы способом через программу login.

Ниже приведена структура корня FTP-архива (риc. 5).

Рис. 5. Структура ftp-архива

WWW-серверы

Как уже было сказано выше, сервер World Wide Web - это программа, обслуживающая запросы клиентов по протоколу HTTP. Иногда серверами WWW называют и другие программы, например, поисковые машины Wide Area Information Server. Но это слишком вольное толкование понятия WWW-сервера. Главной задачей сервера "паутины" является обеспечение доступа пользователей к базе данных HTML-документов. Однако, в настоящее время функциональные возможности серверов значительно расширились и вышли за пределы простой отсылки документов на запросы клиентов. Наиболее типичными для современных серверов являются следующие функции:

• ведение иерархической базы данных документов,

• контроль за доступом к информации со стороны программ-клиентов,

• предварительная обработка данных перед ответом на запрос,

• взаимодействие с внешними программами через Common Gateway Interface,

• реализация взаимодействия с клиентами и другими серверами в режиме посредника,

• реализация встроенных или взаимодействие с внешними поисковыми машинами.

Кроме того, такие серверы как NetSite (Netscape Communication) и Apachie реализуют шифрованные протоколы HTTP для обмена информацией с клиентами. Рассмотрение перечисленных свойств и функций WWW-серверов полезно провести на примерах, основанных на практике эксплуатации серверов NCSA httpd, CERN httpd, Winhttpd и WN, Apachie.

Структура базы данных сервера WWW

Итак первой основной задачей для любого сервера является ведение его базы данных. База данных сервера - это часть файловой системы, отведенная для размещения файлов HTML-документов. Большинство современных файловых систем - это иерархические деревья, следовательно, и база данных HTTP-сервера также является таким деревом. Для любой базы данных необходимо ввести понятие единицы хранения - минимальный объект, к которому можно обратиться извне или получить в качестве ответа на запрос. Стандартным объектом хранения в базе данных HTTP-сервера является HTML-документ, который является обычном текстовым файлом. Кроме такого стандартного объекта многие серверы поддерживают различные комбинированные объекты хранения, создаваемые в ряде случаев из нескольких файлов или генерируемые программами "на лету".

Если обратиться к терминологии, которая принята в системах World Wide Web, то можно выделить следующие основные объекты, с которыми оперирует сервер и программа-клиент:

Страница базы данных World Wide Web - это законченный информационный объект, который отображается пользователю при обращении к информационному ресурсу World Wide Web по универсальному идентификатору этого ресурса (URI, URL).

База данных World Wide Web или Website - набор страниц базы данных World Wide Web. При более подробном рассмотрении Website - это вся совокупность данных и программного обеспечения, обеспечивающая отображение страниц информационной базы данных World Wide Web.

Если страница Website представляет из себя обычный файл в стандарте HTML, то тогда говорят об элементарном или стандартном элементе хранения. В этом случае URL указывает непосредственно на этот файл и сервер просто отправляет его в ответ на запрос пользователя.

Многие страницы содержат внутри себя контейнеры-формы, которые служат для передачи информации от программы клиента программе-серверу. В рамках данного рассмотрения эти страницы выделены в особую группу страниц World Wide Web.

Страницей-формой будем называть в данном контексте файл в формате HTML, который содержит в себе HTML-форму.

После обращения к странице-форме, как правило, следует вызов либо API-модуля, встроенного в сервер, либо CGI-программы. В свою очередь такое действие вызывает генерацию этим модулем или программой виртуальной страницы.

Виртуальной страницей Website будем называть страницу, которая в виде файла в файловой системе сервера не существует. Данная страница появляется только в момент обращения клиента к серверу.

Один из способов генерации виртуальной страницы - это генерация при помощи API-модуля или CGI-программы. При этом весь текст страницы может порождаться программой, либо для генерации могут использоваться файлы-заготовки. Генерируют не только текстовые файлы, но и графику. Одним из наиболее популярных способов генерации документов является обращение к стекам гипертекстовых ссылок и системам управления универсальными базами данных (СУБД).

Второй способ генерации виртуальной страницы - это генерация такой страницы сервером. В данном случае в тело документа и файлы описания иерархии документов сервера включаются команды преобразования документов. Сервер может, в общем случае, производить условную генерацию документов на основе информации, полученной от программы-клиента.

Другим типом объекта, который хранится в Website, являются страницы в формате Virtual Reality Modeling Language(VRML).VRML-страница - это такой же объект, как и обычные страницы Website, только написанная на другом языке. К VRML-страницам можно применять те же механизмы генерации, что и к страницам HTML.

Java-applet - это мобильный код, сгенерированный компилятором applet'ов. Applet'ы составляют в базе данных Website отдельную директорию в файловой системе сервера. В страницы HTML встраиваются специальные контейнеры applet'ов, которые позволяют программе-клиенту распознавать наличие applet'а и подгружать его в качестве части страницы.

Рис. 6. Структура базы данных и программного обеспечения Website

Как видно из Рис. 6, кроме перечисленных выше компонентов, базу данных Website составляют еще и другие файлы. Главным образом, это файлы графических и мультимедийных форматов. Для просмотра этих файлов программа-клиент должна уметь запускать либо внешнюю программу, либо plug-ins, т.е. программу, которая отображает файл графического или мультимедийного формата внутрь рабочей области программы-клиента.

Совершенно очевидно, что для создания всего этого многообразия файлов и компонентов Website необходимо программное обеспечение, которое не входит в стандартный набор, представленный на Рис. 6. Самый минимальный набор инструментов, который необходим для поддержания страниц базы данных можно определить следующим образом:

• Редактор файлов формата HTML.

• Графический редактор, сохраняющий файлы в форматах GIF, в том числе и версии GIF89A, и JPEG.

• Редактор файлов формата MPEG.

• Редактор файлов VRML.

• Редактор аудиофайлов.

• Компилятор байткода Java.

• и др. Кроме прочего, для того, чтобы тестировать страницы, необходимо иметь версии клиентского программного обеспечения различных производителей и различных версий. Определить какие именно программы и их версии необходимы, можно по файлу статистики сервера.

Поисковые серверы

Такие имена информационных служб как Lycos, AltaVista, Yahoo, OpenText, InfoSeek и ряд других, хорошо известны пользователям Internet. Без пользования услугами этих систем практически нельзя найти что-либо полезное в море информационных ресурсов Сети. Но что они из себя представляют, как устроены, почему результат поиска в терабайтах информации выдается так быстро, как устроено ранжирование документов при выдаче, что из себя представляют информационные массивы этих систем - этим вопросам посвящен этот раздел.

Предварительные замечания

Информационно-поисковые системы появились на свет достаточно давно. Теории и практике построения таких систем посвящено довольно большое количество статей, основная масса которых приходится на конец 70-х - начало 80-х годов. Среди отечественных источников следует выделить научно-технический сборник "Научно-техническая информация. Серия 2. Информационные процессы и системы", который выходит до сих пор. На русском языке издана так же и "библия" по разработке этого рода систем - "Динамические библиотечно-информационные системы" Жерарда Солтона (Gerard Salton), в которой рассмотрены основные принципы построения информационно-поисковых систем и моделирования процессов их функционирования. Таким образом нельзя сказать, что с появлением Internet и бурным вхождением его в практику информационного обеспечения, появилось нечто принципиально новое, чего не было раньше. Если быть точным, то информационно-поисковые системы в Internet - это признание того, что ни иерархическая модель Gopher, ни гипертекстовая модель World Wide Web не решают проблему поиска информации в больших объемах разнородных документов. И на сегодняшний день нет другого способа быстрого поиска данных, кроме поиска по ключевым словам.

При использовании иерархической модели Gopher приходится довольно долго бродить по дереву каталогов, пока не встретишь нужную информацию. Эти каталоги должны кем-то поддерживаться и при этом их тематическое разбиение должно совпадать с информационными потребностями пользователя. Учитывая анархичность Internet и огромное количество всевозможных интересов у пользователей Сети, понятно, что кому-то может и не повезти, и в сети не будет каталога отражающего конкретную предметную область. Именно по этой причине для множества серверов Gopher, которое называется GopherSpace была разработана информационно-поисковая программа Veronica (Very Easy Rodent-Oriented Net-wide Index of Computerized Archives).

Аналогичное развитие событий мы видим и в World Wide Web. Собственно еще в 1988 году в специальном выпуске "Communication of the acm" среди прочих проблем разработки гипертекстовых систем и их использования Франк Халаз назвал проблему организации поиска информации в больших гипертекстовых сетях в качестве первоочередной задачи для следующего поколения систем этого типа. До сих пор многие идеи, высказанные в этом разделе, не нашли еще своей реализации. Естественно, что система, предложенная Бернерсом-Ли и получившая такое широкое распространение в Internet, должна была столкнуться с теми же проблемами, что и ее локальные предшественники. Реальное подтверждение этому было продемонстрировано на второй конференции по World Wide Web осенью 1994 года, на которой были представлены доклады о разработке информационно-поисковых систем для Web, а система World Wide Web Worm, разработанная Оливером МакБрайном из Университета Колорадо, получила приз как лучшее навигационное средство. Следует также отметить, что все-таки долгая жизнь суждена не хорошим программам талантливых одиночек, а средствам, которые являются результатом долгосрочного планирования последовательного движения к поставленной цели научных и производственных коллективов. Рано или поздно этап исследований заканчивается и наступает этап эксплуатации систем, а это уже совсем другой род деятельности. Именно такая судьба ожидала два других проекта, представленных на той же конференции: Lycos, поддерживаемый компанией Microsoft, и WebCrawler, ставший собственностью America On-line.

Разработка новых информационных систем для Web не завершена. Причем как на стадии написания коммерческих систем, так и на стадии исследований. За прошедшие два года снят только верхний слой возможных решений. Однако, многие проблемы, которые ставит перед разработчиками ИПС Internet не решены до сих пор. Именно этим обстоятельством и вызвано появление проектов типа AltaVista компании Digital, главной целью которого является разработка программных средств информационного поиска для Web и подбор архитектуры для информационного сервера Web.

Архитектура современных информационно-поисковых систем World Wide Web

Прежде чем описать проблемы построения информационно-поисковых систем Web и пути их решения, рассмотрим типовую схему такой системы (Рис.7). В различных публикациях, посвященных конкретным системам, приводятся схемы, которые отличаются друг от друга только применением конкретных программных решений, но не принципом организации различных компонентов системы.

Рис. 7. Структура ИПС для Internet(Budi Yuwono, Dik L.Lee. Search and Ranking Algorims for Locating Resources on the World Wide Web)

На этой схеме обозначены:

userclient - это программа просмотра конкретного информационного ресурса. В настоящее время наиболее популярны мультипротокольные программы типа Netscape Navigator. Такая программа обеспечивает просмотр документов World Wide Web, Gopher, Wais, FTP-архивов, почтовых списков рассылки и групп новостей Usenet. В свою очередь все эти информационные ресурсы являются объектом поиска информационно-поисковой системы.

userinterface - интерфейс пользователя - это не просто программа просмотра. В случае информационно-поисковой системы под этим словосочетанием понимают и способ общения пользователя с поисковым аппаратом системы, т.е. с системой формирования запросов и просмотров результатов поиска. Просмотр результатов поиска и информационных ресурсов сети - это совершенно разные вещи, на которых остановимся чуть позже.

searchengine - поисковая машина служит для трансляции запроса пользователя, который подготавливается на информационно-поисковом языке (ИПЯ), в формальный запрос системы, поиска ссылок на информационные ресурсы Сети и выдачи результатов этого поиска пользователю.

indexdatabase - индекс - это основной массив данных информационно-поисковой системы. Он служит для поиска адреса информационного ресурса. Архитектура индекса устроена таким образом, чтобы поиск происходил максимально быстро и при этом можно было бы оценить ценность каждого из найденных информационных ресурсов сети.

queries - запросы пользователя сохраняются в его личной базе данных. На отладку каждого запроса уходит достаточно много времени, и поэтому чрезвычайно важно хранить запросы, на которые система дает хорошие ответы.

indexrobot - робот-индексировщик служит для сканирования Internet и поддержки базы данных индекса в актуальном состоянии. Эта программа является основным источником информации о состоянии информационных ресурсов сети.

wwwsites - это весь Internet. А если говорить более точно, то это те информационные ресурсы, просмотр которых обеспечивается программами просмотра.

Рассмотрим теперь назначение и принцип построения каждой из этих компонент более подробно и определим, в чем отличие данной системы от традиционной информационно-поисковой системы локального типа.

Информационные ресурсы и их представление в информационно-поисковой системе

Как видно из схемы (Рис.7) документальным массивом ИПС Internet является все множество документов шести основных типов: WWW-страницы, Gopher-файлы, документы Wais, записи архивов FTP, новости Usenet, статьи почтовых списков рассылки. Все это довольно разнородная информация, которая представлена в виде различных, никак несогласованных друг с другом форматов данных. Здесь есть и текстовая информация, и графическая информация, и аудио информация и вообще все, что есть в указанных выше хранилищах. Естественно встает вопрос, как информационно-поисковая система должна со всем этим работать. В традиционных системах есть понятие поискового образа документа - ПОД'а. ПОД (Поисковый Образ Документа)- это нечто, что заменяет собой документ и используется при поиске вместо реального документа. Поисковый образ является результатом применения некоторой модели информационного массива документов к реальному массиву. Наиболее популярной моделью является векторная модель, в которой каждому документу приписывается список терминов, наиболее адекватно отражающих его смысл. Если быть более точным, то документу приписывается вектор, размерность которого равна числу терминов, которыми можно воспользоваться при поиске. При булевой векторной модели элемент вектора равен 1 или 0, в зависимости от наличия термина в ПОД'е документа или его отсутствия. В более сложных моделях термины взвешиваются, т.е. элемент вектора равен не 1 или 0, а некоторому числу, которое отражает соответствие данного термина документу. Именно последняя модель наиболее популярна в информационно-поисковых системах Internet. Вообще говоря, существуют и другие модели описания документов: вероятностная модель информационных потоков и поиска, и модель поиска в нечетких множествах. Анализ преимуществ и недостатков применения этих моделей при реализации информационно-поисковых систем в Internet - это тема специального исследования. Здесь имеет смысл обратить внимание читателя только на то, что пока именно линейная модель применяется в системах Lycos, WebCrawler, AltaVista, OpenText, AliWeb и ряде других. Исследования по применению других моделей также ведутся, например, в рамках проекта AltaVista или научными группами. Таким образом, первая задача, которою должна решить информационно-поисковая система - это приписывание списка ключевых слов документу или информационному ресурсу. Именно эта процедура и называется индексированием. Часто, однако, индексированием называют составление файла инвертированного списка, в котором каждому термину индексирования ставится в соответствие список документов, в которых он встречается. Такая процедура является только частным случаем, а точнее техническим аспектом создания поискового аппарата информационно-поисковой системы.

Проблема, связанная с индексированием, заключается в том, что приписывание поискового образа документу или информационному ресурсу опирается на представление о словаре, из которого эти термины выбираются, как о фиксированной совокупности терминов. В традиционных системах существовало разбиение на системы с контролируемым словарем и системы со свободным словарем. Контролируемый словарь предполагал ведение некоторой лексической базы данных, добавление терминов в которую производилось администратором системы. Таким образом, все новые документы могли быть заиндексированы только теми терминами, которые были в этой базе данных. Свободный словарь пополнялся автоматически по мере появления новых документов. Однако, на момент актуализации словарь также фиксировался. Актуализация предполагала полную перезагрузку базы данных. В момент этого обновления перегружались сами документы и обновлялся словарь, а после его обновления производилась переиндексация документов. Процедура актуализации занимала достаточно много времени и доступ к системе в момент ее актуализации закрывался.

Теперь представим себе возможность такой процедуры в анархичном Internet, где ресурсы появляются и исчезают ежедневно. При создании программы Veronica для GopherSpace предполагалось, что все серверы должны быть зарегистрированы и таким образом велся учет наличия или отсутствия ресурса. Veronica раз в месяц проверяла наличие документов Gopher и обновляла свою базу данных ПОД'ов документов Gopher. В World Wide Web ничего подобного нет. Для решения этой задачи используются программы сканирования сети или роботы-индексировщики. Разработка роботов - это довольно нетривиальная задача, т.к. существует опасность зацикливания робота или попадания на виртуальные страницы. Все системы имеют своего робота. Робот просматривает сеть, находит новые ресурсы, приписывает им термины и помещает в базу данных индекса. Главный вопрос заключается в том, какие термины приписывать документам, откуда их брать, ведь ряд ресурсов вообще не является текстом. В настоящее время различные роботы используют для индексирования следующие источники для пополнения своих виртуальных словарей: гипертекстовые ссылки, заголовки (title), заглавия (H1, H2 и т.п.), аннотации, списки ключевых слов и полные тексты документов, сообщения администраторов о своих Web-страницах. Для индексирования telnet, gopher, ftp, нетекстовой информации используются главным образом URL, для новостей Usenet и почтовых списков - поля Subject и Keywords. Наибольший простор для построения ПОД'ов дают HTML-документы. Однако не следует думать, что все термины из перечисленных выше элементов документов попадают в их поисковые образы. Очень активно используются списки запрещенных слов (stop-words), которые не могут быть использованы для индексирования, общих слов (предлоги, союзы и т.п.), а также часто производится нормализация лексики. Таким образом, даже то, что в OpenText, например, называется полнотекстовым индексированием реально является выбором слов из текста документа и сравнением с целым набором различных словарей, после которого термин попадает в поисковый образ документа, а потом и в индекс системы. Для того, чтобы не раздувать словарей и индексов, а индекс Lycos, например, равен 4TB, применяется такое понятие как "вес" термина. В документе обычно индексируется 40 - 100 наиболее "тяжелых" терминов.

После того, как ресурсы заиндексированы, т.е. система составила массив поисковых образов документов, начинается построение поискового аппарата системы. Совершенно очевидно, что лобовой просмотр файла или файлов ПОД'ов займет много времени, что абсолютно не приемлемо для интерактивной системы, которой является Web. Для того, чтобы можно было быстро находить информацию в базе данных ПОД'ов строится индекс. Индекс в большинстве систем - система связанных между собой файлов, которая нацелена на быстрый поиск данных по запросу пользователя. Структура и состав индексов различных систем могут отличаться друг от друга и зависят от многих факторов. К этим факторам можно отнести и размер массива поисковых образов, и информационно-поисковый язык системы, и размещения различных компонентов системы и т.п. Рассмотрим структуру индекса на примере системы. Этот проект выбран потому, что он позволяет реализовывать не только примитивный булевый поиск, но и контекстный поиск, взвешенный поиск и ряд других возможностей, которые отсутствуют во многих поисковых системах, например, Yahoo.

Индекс рассматриваемой системы состоит из таблицы идентификаторов страниц (page-ID), таблицы ключевых слов (Keyword-ID), таблицы модификации страниц, таблицы заголовков, таблицы гипертекстовых связей, инвертированного списка (IL) и прямого списка (FL).

Page-ID отображает идентификаторы станиц в URL этих страниц, Keyword-ID отображает каждое ключевое слово в уникальный идентификатор этого слова, таблица заголовков отображает идентификатор страницы в заголовок страницы, таблица гипертекстовых ссылок отображает идентификатор страниц в гипертекстовую ссылку на эту страницу. Инвертированный список ставит в соответствие каждому ключевому слову список пар (номер документа, идентификатор страницы, позиция слова в странице), а прямой список - это массив поисковых образов страниц. Все эти файлы так или иначе используются при поиске, но главным среди них, безусловно, является файл инвертированного списка. Результат поиска в этом файле - это объединение и/или пересечение списков идентификаторов страниц. Результирующий список, который преобразовывается в список заголовков, снабженных гипертекстовыми ссылками, возвращается пользователю в его программу просмотра Web. Для того, чтобы быстро искать записи инвертированного списка, над ним надстраивается еще несколько файлов, например, файл буквенных пар с указанием записей инвертированного списка, с этих пар начинающихся, а также применяется механизм прямого доступа к данным - хеширование.

Для обновления индекса применяется комбинация двух подходов. Первый можно назвать коррекцией индекса "на ходу". Для этого служит таблица модификации страниц. Суть такого решения довольно проста: старая запись индекса ссылается на новую, которая и используется при поиске. Когда число таких ссылок становится достаточным для того, чтобы ощутить это при поиске, то происходит полное обновление индекса, т.е. его перезагрузка.

Успех информационно-поисковой системы с точки зрения скорости поиска, определяется исключительно архитектурой индекса. Как правило, способ организации этих массивов является "секретом фирмы" и гордостью компании.

Язык программирования Java

Весь 1996 год прошел под знаком внедрения в World Wide Web технологии Java. Однако реальные проекты, выполненные в этой технологии появились только к концу года. При обсуждении Java-технологии, как правило речь идет о ее безопасности, мобильности, и, как следствие, уменьшении размеров программного кода, выполняемого на машинах-клиентах.

Не смотря на то, что этот раздел называется "Язык программирования Java", в нем приходится говорить о гораздо более обширном понятии, которое принято обозначать термином "Java-технология". Если обратиться к публикациям о новых концепциях разработки программного обеспечения, то Java-язык и Java-технологии ценятся не только и не столько за то, что они дали возможность "оживить" Web, как часто можно прочитать в рекламных проспектах, а за то, что давняя идея мобильного программирования для различных аппаратных платформ наконец-то стала реальностью.

При этом все прекрасно понимают, что сама по себе Java-технология еще чрезвычайно сыра и использовать ее в нынешнем виде для серьезных проектов могут только самые отчаянные смельчаки, тем не менее многие из свойств Java чрезвычайно интересны и полезны.

Возможные архитектуры Intranet-приложений

Технологии Internet обеспечивают широкий диапазон возможных архитектур Intranet-систем. Рассмотрим некоторые варианты.

Решения, ориентированные на клиентскую часть системы

Видимо, это наиболее тривиальная архитектура. Аналогично тому, как это было в файл-серверных решениях, вся прикладная часть системы находится в клиенте, который взаимодействует с разнообразными серверами Internet (электронной почты, ftp и т.д.) и серверами, управляющими файлами и/или базами данных. Клиент должен быть достаточно "толстым", чтобы быть в состоянии уметь работать с разными видами серверов (для каждого из них требуется индивидуальная клиентская часть) и одновременно выполнять прикладную обработку данных. Серверы могут быть разной толщины в зависимости от своей функциональной ориентированности (естественно, что сервер электронной почты нуждается в существенно меньшем числе ресурсов, чем мощный сервер баз данных) (Рис.9).

Рис. 9. "Толстый" клиент и серверы разной толщины в Intranet-системах, ориентированных на клиента

Трехзвенные архитектуры (Web-ориентированные)

Ориентация на использование Web-технологии позволяет одновременно добиться двух эффектов. Во-первых, за счет использования CGI или API можно перенести на сторону сервера часть логики приложения. Во-вторых, используя технику шлюзования Web-сервера (опять же применяя CGI-шлюзы или API) можно работать через Web-сервер (в стандартном интерфейсе) с другими серверами. Клиента можно сделать очень "тонким", Web-сервер будет достаточно "толстым", а уж остальные такими, как велит судьба (Рис. 10).

Рис. 10. "Тонкий" клиент, "толстый" Web-сервер и сравнительно "стройный" дополнительный сервер

Раздел 6. Логический анализ структур ИС. Анализ и оценка производительности ИС.

Структура раздела

Численные методы построения математических моделей

Вычислительный алгоритм

Требования к вычислительным методам

Структурный анализ

Диаграммы потоков данных

Описание потоков данных и процессов

Расширения для систем реального времени

Расширение возможностей управления

Методы анализа, ориентированные на структуры данных

Метод анализа Джексона

Методика Джексона

Шаг объект-действие

Шаг объект-структура

Шаг начального моделирования

Методы тестирования

Метод «Белого ящика»

Метод «Черного ящика»

Подходы к оценке систем

Численные методы построения математических моделей

При выборе физической и, следовательно, математической модели мы пренебрегаем факторами, не оказывающими существенного влияния на ход изучаемого процесса. Типичные математические модели, соответствующие физическим явлениям, формулируются в виде уравнений математической физики. Большинство реальных процессов описывается нелинейными уравнениями и лишь в первом приближении (при малых значениях параметров, малых отклонениях от равновесия и др.) эти уравнения можно заменить линейными.

После того как задача сформулирована в математической форме, необходимо найти ее решение. Но что значит решить математическую задачу? Только в исключительных случаях удается найти решение в явном виде, например в виде ряда. Иногда утверждение «задача решена» означает, что доказано существование и единственность решения. Ясно, что этого недостаточно для практических приложений. Необходимо еще изучить качественное поведение решения и найти те или иные количественные характеристики.

Именно на этом этапе требуется привлечение ЭВМ и, как следствие, развитие численных методов. Под численным методом здесь понимается такая интерпретация математической модели («дискретная модель»), которая доступна для реализации на ЭВМ. Например, если математическая модель представляет собой дифференциальное уравнение, то численным методом может быть аппроксимирующее его разностное уравнение совместно с алгоритмом, позволяющим отыскать решение этого разностного уравнения. Результатом реализации численного метода на ЭВМ является число или таблица чисел. Отметим, что в настоящее время помимо собственно численных методов имеются также методы, которые позволяют проводить на ЭВМ аналитические выкладки. Однако аналитические методы для ЭВМ не получили пока достаточно широкою распространения.

Чтобы реализовать численный метод, необходимо составить программу для ЭВМ или воспользоваться готовой программой. После отладки программы наступает этап проведения вычислений и анализа результатов. Полученные результаты изучаются с точки зрения их соответствия исследуемому явлению и при необходимости вносятся исправления в численный метод и уточняется математическая модель.

Такова в общих чертах схема вычислительного эксперимента. Его основу составляет триада: модель — метод (алгоритм) — программа. Опыт решения крупных задач показывает, что метод математического моделирования и вычислительный эксперимент соединяют в себе преимущества традиционных теоретических и экспериментальных методов исследования. Можно указать такие крупные области применения вычислительного эксперимента, как энергетика, аэрокосмическая техника, обработка данных натурного эксперимента, совершенствование технологических процессов.

Вычислительный алгоритм

Необходимо подчеркнуть, что процесс исследования исходного объекта методом математического моделирования и вычислительного эксперимента неизбежно носит приближенный характер, потому что на каждом этапе вносятся те или иные погрешности. Так, построение математической модели связано с упрощением исходного явления, недостаточно точным заданием коэффициентов уравнения и других входных данных. По отношению к численному методу, реализующему данную математическую модель, указанные погрешности являются неустранимыми, поскольку они неизбежны в рамках данной модели.

При переходе от математической модели к численному методу возникают погрешности, называемые погрешностями метода. Они связаны с тем, что всякий численный метод воспроизводит исходную математическую модель приближенно. Наиболее типичными погрешностями метода являются погрешность дискретизации и погрешность округления. Поясним причины возникновения таких погрешностей.

Обычно построение численного метода для заданной математической модели разбивается на два этапа: а) формулировка дискретной задачи, б) разработка вычислительного алгоритма, позволяющего отыскать решение дискретной задачи. Например, если исходная математическая задача сформулирована в виде системы дифференциальных уравнений, то для численного решения необходимо заменить ее системой конечного, может быть, очень большого числа линейных или разностных алгебраических уравнений. В этом случае говорят, что проведена дискретизация исходной математической задачи. Простейшим примером дискретизации является построение разностной схемы путем замены дифференциальных выражений конечно-разностными отношениями. В общем случае дискретную модель можно рассматривать как конечномерный аналог исходной математической задачи. Ясно, что решение дискретизированной задачи отличается от решения исходной задачи. Разность соответствующих решений и называется погрешностью дискретизации. Обычно дискретная модель зависит от некоторого параметра (или множества параметров) дискретизации, при стремлении которого к нулю должна стремиться к нулю и погрешность дискретизации. При этом число алгебраических уравнений, составляющих дискретную модель, неограниченно возрастает. В случае разностных методов таким параметром является шаг сетки.

Как уже отмечалось, дискретная модель представляет собой систему большого числа алгебраических уравнений. Невозможно найти решение такой системы точно и в явном виде. Поэтому приходится использовать тот или иной численный алгоритм решения системы алгебраических уравнений. Входные данные этой системы, а именно коэффициенты и правые части, задаются в ЭВМ не точно, а с округлением. В процессе работы алгоритма погрешности округления обычно накапливаются, и в результате решение, полученное на ЭВМ, будет отличаться от точного решения дискрети зированной задачи. Результирующая погрешность называется погрешностью округления (иногда ее называют вычислительной погрешностью). Величина этой погрешности определяется двумя факторами: точностью представления вещественных чисел в ЭВМ. и чувствительностью данного алгоритма к погрешностям округления.

Алгоритм называется устойчивым, если в процессе его работы вычислительные погрешности возрастают незначительно, и неустойчивым — в противоположном случае. При использовании неустойчивых вычислительных алгоритмов накопление погрешностей округления приводит в процессе счета к переполнению арифметического устройства ЭВМ.

Итак, следует различать погрешности модели, метода и вычислительную. Какая же из этих трех погрешностей является преобладающей? Ответ здесь неоднозначен. Видимо, типичной является ситуация, возникающая при решении задач математической физики, когда погрешность модели значительно превышает погрешность метода, а погрешностью округления в случае устойчивых алгоритмов можно пренебречь по сравнению с погрешностью метода. С другой стороны, при решении, например, систем обыкновенных дифференциальных уравнений возможно применение столь точных методов, что их погрешность будет сравнима с погрешностью округления. В общем случае нужно стремиться, чтобы все указанные погрешности имели один и тот же порядок. Например, нецелесообразно пользоваться разностными схемами, имеющими точность 10~6, если коэффициенты исходных уравнений задаются с точностью 10~2.

Требования к вычислительным методам

Одной и той же математической задаче можно поставить в соответствие множество различных дискретных моделей. Однако далеко не все из них пригодны для практической реализации. Вычислительные алгоритмы, предназначенные для быстродействующих ЭВМ, должны удовлетворять многообразным и зачастую противоречивым требованиям. Попытаемся здесь сформулировать основные из этих требований в общих чертах. Далее в частях II и III книги эти требования конкретизируются при рассмотрении алгоритмов численного решения типичных математических задач.

Можно выделить две группы требований к численным методам. Первая группа связана с адекватностью дискретной модели исходной математической задаче, и вторая группа — с реализуемостью численного метода на ЭВМ. К первой группе относятся такие требования, как сходимость численного метода, выполнение дискретных аналогов законов сохранения, качественно правильное поведение решения дискретной задачи.

Поясним эти требования. Предположим, что дискретная модель математической задачи представляет собой систему большого, но конечного числа алгебраических уравнений. Обычно, чем точнее мы хотим получить решение, тем больше уравнений приходится брать. Говорят, что численный метод сходится, если при неограни ченном увеличении числа уравнений решение дискретной задачи стремится к решению исходной задачи.

Поскольку реальная ЭВМ может оперировать лишь с конечным числом уравнений, на практике сходимость, как правило, не достигается. Поэтому важно уметь оценивать погрешность метода в зависимости от числа уравнений, составляющих дискретную модель. По этой же причине стараются строить дискретную модель таким образом, чтобы она правильно отражала качественное поведение решения исходной задачи даже при сравнительно небольшом числе уравнений.

Например, дискретной моделью задачи математической физики может быть разностная схема. Для ее построения область изменения независимых переменных заменяется дискретным множеством точек — сеткой, а входящие в исходное уравнение производные заменяются на сетке конечно-разностными отношениями. В результате получаем систему алгебраических уравнений относительно значений искомой функции в точках сетки. Число уравнений этой системы равно числу точек сетки. Известно, что дифференциальные уравнения математической физики являются следствиями интегральных законов сохранения. Поэтому естественно требовать, чтобы для разностной схемы выполнялись аналоги таких законов сохранения. Разностные схемы, удовлетворяющие этому требованию, называются консервативными. Оказалось, что при одном и том же числе точек сетки консервативные разностные схемы более правильно отражают поведение решения исходной задачи, чем неконсервативные схемы.

Сходимость численного метода тесно связана с его корректностью. Предположим, что исходная математическая задача поставлена корректно, т. е. ее решение существует, единственно и непрерывно зависит от входных данных. Тогда дискретная модель этой задачи должна быть построена таким образом, чтобы свойство корректности сохранилось. Таким образом, в понятие корректности численного метода включаются свойства однозначной разрешимости соответствующей системы уравнений и ее устойчивости по входным данным. Под устойчивостью понимается непрерывная зависимость решения от входных данных, равномерная относительно числа уравнений, составляющих дискретную модель.

Вторая группа требований, предъявляемых к численным методам, связана с возможностью реализации данной дискретной модели на данной ЭВМ, т. е. с возможностью получить на ЭВМ решение соответствующей системы алгебраических уравнений за приемлемое время. Основным препятствием для реализации корректно поставленного алгоритма является ограниченный объем оперативной памяти ЭВМ и ограниченные ресурсы времени счета. Реальные вычислительные алгоритмы должны учитывать эти обстоятельства, т. е. они должны быть экономичными как по числу арифметических действий, так и по требуемому объему памяти.

Структурный анализ

Структурный анализ — один из формализованных методов анализа требований к ПО. Автор этого метода — Том Де Марко (1979). В этом методе программное изделие рассматривается как преобразователь информационного потока данных. Основной элемент структурного анализа — диаграмма потоков данных.

Диаграммы потоков данных

Диаграмма потоков данных ПДД — графическое средство для изображения информационного потока и преобразований, которым подвергаются данные при движении от входа к выходу системы. Элементы диаграммы имеют вид, показанный на рис. 3.1. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции.

Пример системы взаимосвязанных диаграмм показан на рис. 1.

Диаграмма высшего (нулевого) уровня представляет систему как единый овал со стрелкой, ее называют основной или контекстной моделью. Контекстная модель используется для указания внешних связей программного изделия. Для детализации (уточнения системы) вводится диаграмма 1-го уровня. Каждый из преобразователей этой диаграммы — подфункция общей системы. Таким образом, речь идет о замене преобразователя F на целую систему преобразователей.

Дальнейшее уточнение (например, преобразователя F3) приводит к диаграмме 2-го уровня. Говорят, что ПДД1 разбивается на диаграммы 2-го уровня.

Рис. 1. Система взаимосвязанных диаграмм потоков данных

Важно сохранить непрерывность информационного потока и его согласованность. Это значит, что входы и выходы у каждого преобразователя на любом уровне должны оставаться прежними. В диаграмме отсутствуют точные указания на последовательность обработки. Точные указания откладываются до этапа проектирования.

Диаграмма потоков данных — это абстракция, граф. Для связи графа с проблемной областью (превращения в граф-модель) надо задать интерпретацию ее компонентов — дуг и вершин.

Описание потоков данных и процессов

Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Очевидно, что должны быть описаны стрелки — потоки данных — и преобразователи — процессы. Для этих целей используются словарь требований (данных) и спецификации процессов.

Словарь требований (данных) содержит описания потоков данных и хранилищ данных. Словарь требований является неотъемлемым элементом любой CASE-утилиты автоматизации анализа. Структура словаря зависит от особенностей конкретной CASE-утилиты. Тем не менее можно выделить базисную информацию типового словаря требований.

Большинство словарей содержит следующую информацию.

1. Имя (основное имя элемента данных, хранилища или внешнего объекта).

2. Прозвище (Alias) — другие имена того же объекта.

3. Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память).

4. Описание содержания — запись для представления содержания.

5. Дополнительная информация — дополнительные сведения о типах данных, допустимых значениях, ограничениях и т. д.

Спецификация процесса — это описание преобразователя. Спецификация поясняет: ввод данных в преобразователь, алгоритм обработки, характеристики производительности преобразователя, формируемые результаты.

Количество спецификаций равно количеству преобразователей диаграммы.

Расширения для систем реального времени

Как известно, программное изделие (ПИ) является дискретной моделью проблемной области, взаимодействующей с непрерывными процессами физического мира (рис. 2).

Рис. 2. Программное изделие как дискретная модель проблемной области

П. Вард и С. Меллор приспособили диаграммы потоков данных к следующим требованиям систем реального времени .

1. Информационный поток накапливается или формируется в непрерывном времени.

2. Фиксируется управляющая информация. Считается, что она проходит через систему и связывается с управляющей обработкой.

3. Допускается множественный запрос на одну и ту же обработку (из внешней среды).

Рис. 3.4. Расширения диаграмм для систем реального времени

Новые элементы имеют обозначения, показанные на рис. 3.

Приведем два примера использования новых элементов.

Пример 1. Использование потоков, непрерывных во времени.

На рис. 3.5 представлена модель анализа программного изделия для системы слежения за газовой турбиной.

Рис. 3. Модель ПО для системы слежения за газовой турбиной

Видим, что здесь наблюдаемая температура измеряется непрерывно до тех пор, пока не будет найдено дискретное значение в наборе эталонов температуры. Преобразователь формирует регулирующие воздействия как непрерывный во времени вывод. Чем полезна эта модель?

Во-первых, инженер делает вывод, что для приема-передачи квазинепрерывных значений нужно использовать аналого-цифровую и цифроаналоговую аппаратуру.

Во-вторых, необходимость организации высокоскоростного управления этой аппаратурой делает критичным требование к производительности системы.

Пример 2. Использование потоков управления.

Рассмотрим компьютерную систему, которая управляет роботом (рис. 4).

Рис. 4. Модель ПО для управления роботом

Установка в прибор деталей, собранных роботом, фиксируется установкой бита в буфере состояния деталей (он показывает присутствие или отсутствие каждой детали). Информация о событиях, запоминаемых в буфере, посылается в виде строки битов в преобразователь «Наблюдение за прибором». Преобразователь читает команды оператора только тогда, когда управляющая информация (битовая строка) показывает наличие всех деталей. Флаг события (Старт-Стоп) посылается в управляющий преобразователь «Начать движение», который руководит дальнейшей командной обработкой. Потоки данных посылаются в преобразователь команд роботу при наличии события «Процесс активен».

Расширение возможностей управления

Д. Хетли и И. Пирбхаи сосредоточили внимание на аспектах управления программным продуктом. Они выделили системные состояния и механизм перехода из одного состояния в другое. Д. Хетли и И. Пирбхаи предложили не вносить в ПДД элементы управления, такие как потоки управления и управляющие процессы. Вместо этого они ввели диаграммы управляющих потоков (УПД).

Диаграмма управляющих потоков содержит:

• обычные преобразователи (управляющие преобразователи исключены вообще);

• потоки управления и потоки событий (без потоков данных).

Вместо управляющих преобразователей в УПД используются указатели — ссылки на управляющую спецификацию УСПЕЦ. Как показано на рис. 5, ссылка изображается как косая пунктирная стрелка, указывающая на окно УСПЕЦ (вертикальную черту).

Рис. 5. Изображение ссылки на управляющую спецификацию

УСПЕЦ управляет преобразователями в ПДД на основе события, которое проходит в ее окно (по ссылке). Она предписывает включение конкретных преобразователей как результат конкретного события.

Иллюстрация модели программной системы, использующей описанные средства, приведена на рис. 6.

Рис. 6. Композиция модели обработки и управления

В модель обработки входит набор диаграмм потоков данных и набор спецификаций процессов. Модель управления образует набор диаграмм управляющих потоков и набор управляющих спецификаций. Модель обработки подключается к модели управления с помощью активаторов процессов. Активаторы включают в конкретной ПДД конкретные преобразователи. Обратная связь модели обработки с моделью управления осуществляется с помощью условий данных. Условия данных формируются в ПДД (когда входные данные преобразуются в события).

Методы анализа, ориентированные на структуры данных

Элементами проблемной области для любой системы являются потоки, процессы и структуры данных. При структурном анализе активно работают только с потоками данных и процессами.

Методы, ориентированные на структуры данных, обеспечивают:

1) определение ключевых информационных объектов и операций;

2) определение иерархической структуры данных;

3) компоновку структур данных из типовых конструкций — последовательности, выбора, повторения;

4) последовательность шагов для превращения иерархической структуры данных в структуру программы.

Наиболее известны два метода: метод Варнье-Орра и метод Джексона.

В методе Варнье-Орра для представления структур применяют диаграммы Варнье.

Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение (рис. 1).

Рис. 1. Базовые элементы в диаграммах Варнье

Как показано на рис. 2, с помощью этих элементов можно строить информационные структуры с любым количеством уровней иерархии.

Рис. 2. Структура газеты в виде диаграммы Варнье

Как видим, для представления структуры газеты здесь используются три уровня иерархии.

Метод анализа Джексона

Как и метод Варнье-Орра, метод Джексона появился в период революции структурного программирования. Фактически оба метода решали одинаковую задачу: распространить базовые структуры программирования (последовательность, выбор, повторение) на всю область конструирования сложных программных систем. Именно поэтому основные выразительные средства этих методов оказались так похожи друг на друга.

Методика Джексона

Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные — на этапе проектирования.

1. Объект-действие. Определяются объекты — источники или приемники информации и действия — события реального мира, воздействующие на объекты.

2. Объект-структура. Действия над объектами представляются диаграммами Джексона.

3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.

4. Доопределение функций. Выделяются и описываются сервисные функции.

5. Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов.

6. Реализация. Согласование с системной средой, разработка аппаратной платформы.

Шаг объект-действие

Начинается с определения проблемы на естественном языке.

Пример: Разработать компьютерную систему для обслуживания университетских перевозок. Университет размещается на двух территориях. Для перемещения студентов используется один транспорт. Он перемещается между двумя фиксированными остановками. На каждой остановке имеется кнопка вызова.

При нажатии кнопки:

• если транспорт на остановке, то студенты заходят в него и перемещаются на другую остановку;

• если транспорт в пути, то студенты ждут прибытия на другую остановку, приема студентов и возврата на текущую остановку;

• если транспорт на другой остановке, то он ее покидает, прибывает на текущую остановку и принимает студентов, нажавших кнопку.

Транспорт должен стоять на остановке до появления запроса на обслуживание.

Описание исследуется для выделения объектов. Производится грамматический разбор. Возможны следующие кандидаты в объекты: территория, студенты, транспорт, остановка, кнопка. У нас нет нужды прямо использовать территорию, студентов, остановку — все они лежат вне области модели и отвергаются как возможные объекты. Таким образом, мы выбираем объекты транспорт и кнопка.

Для выделения действий исследуются все глаголы описания.

Кандидатами действий являются: перемещаться, прибывает, нажимать, принимать, покидать. Мы отвергаем перемещаться, принимать потому, что они относятся к студентам, а студенты не выделены как объект. Мы выбираем действия: прибывает, нажимать, покидать.

Заметим, что при выделении объектов и действий возможны ошибки. Например, отвергнув студентов, мы лишились возможности исследовать загрузку транспорта. Впрочем, список объектов и действий может модифицироваться в ходе дальнейшего анализа.

Шаг объект-структура

Структура объектов описывает последовательность действий над объектами (в условном времени).

Для представления структуры объектов Джексон предложил 3 типа структурных диаграмм. Они показаны на рис. 3. В первой диаграмме к объектам применяется такое действие, как последовательность, во второй — выбор, в третьей — повторение.

Рассмотрим объектную структуру для транспорта (см. рис. 4). Условимся, что начало и конец истории транспорта — у первой остановки. Действиями, влияющими на объект, являются Покинуть и Прибыть.

Рис. 3. Три типа структурных диаграмм Джексона

Рис. 4. Объектная структура для транспорта

Диаграмма показывает, что транспорт начинает работу у остановки 1, тратит основное время на перемещение между остановками 1 и 2 и окончательно возвращается на остановку 1. Прибытие на остановку, следующее за отъездом с другой остановки, представляется как пара действий Прибыть(i) и Покинуть(i). Заметим, что диаграмму можно сопровождать комментариями, которые не могут прямо представляться средствами метода. Например, «значение г в двух последовательных остановках должно быть разным».

Структурная диаграмма для объекта Кнопка показывает (рис. 5), что к нему многократно применяется действие Нажать.

Рис. 5. Структурная диаграмма для объекта Кнопка

В заключение заметим, что структурная диаграмма — время-ориентированное описание действий, выполняемых над объектом. Она создается для каждого объекта модели.

Шаг начального моделирования

Начальное моделирование — это шаг к созданию описания системы как модели реального мира. Описание создается с помощью диаграммы системной спецификации.

Элементами диаграммы системной спецификации являются физические процессы (имеют суффикс 0) и их модели (имеют суффикс 1). Как показано на рис. 6, предусматриваются 2 вида соединений между физическими процессами и моделями.

Рис. 6. Соединения между физическими процессами и их моделями

Соединение потоком данных производится, когда физический процесс передает, а модель принимает информационный поток. Полагают, что поток передается через буфер неограниченной емкости типа FIFO (обозначается овалом).

Соединение по вектору состояний происходит, когда модель наблюдает вектор состояния физического процесса. Вектор состояния обозначается ромбиком.

Диаграмма системной спецификации для системы обслуживания перевозок приведена на рис. 7.

При нажатии кнопки формируется импульс, который может быть передан в модель как элемент данных, поэтому для кнопки выбрано соединение потоком данных.

Датчики, регистрирующие прибытие и убытие транспорта, не формируют импульса, они воздействуют на электронный переключатель. Состояние переключателя может быть оценено. Поэтому для транспорта выбрано соединение по вектору состояний

Рис. 7. Диаграмма системной спецификации для системы обслуживания перевозок

Для фиксации особенностей процессов-моделей Джексон предлагает специальное описание — структурный текст. Например, структурный текст для модели КНОПКА-1 имеет вид

КНОПКА-1

читать BD;

НАЖАТЬ цикл ПОКА BD

нажать; читать ВD;

конец НАЖАТЬ;

конец КНОПКА-1;

Структура модели КНОПКА-1 отличается от структуры физического процесса КНОПКА-0 добавлением оператора для чтения буфера ВD, который соединяет физический мир с моделью.

Прежде чем написать структурный текст для модели ТРАНСПОРТ-1, мы должны сделать ряд замечаний.

Во-первых, состояние транспорта будем отслеживать по переменным ПРИБЫЛ, УБЫЛ. Они отражают состояние электронного переключателя физического транспорта.

Во-вторых, для учета инерционности процессов в физическом транспорте в модель придется ввести дополнительные операции:

• ЖДАТЬ (ожидание в изменении состояния физического транспорта);

• ТРАНЗИТ (операция задержки в модели на перемещение транспорта между остановками).

С учетом замечаний структурная диаграмма модели примет вид, изображенный на рис. 8.

Соответственно, структурный текст модели записывается в форме

ТРАНСПОРТ-1

опрос TSV;

ЖДАТЬ цикл ПОКА ПРИБЫЛ(1)

опрос TSV;

конец ЖДАТЬ;

покинуть(1);

ТРАНЗИТ цикл ПОКА УБЫЛ(1)

опрос TSV;

конец ТРАНЗИТ;

ТРАНСПОРТ цикл

ОСТАНОВКА

прибыть(i);

ЖДАТЬ цикл ПОКА ПРИБЫЛ(i)

опрос TSV;

конец ЖДАТЬ;

покинуть(i);

ТРАНЗИТ цикл ПОКА УБЫЛ(i)

опрос TSV;

конец ТРАНЗИТ;

конец ОСТАНОВКА;

конец ТРАНСПОРТ;

прибыть(1);

конец ТРАНСПОРТ-1;

Рис. 8. Структурная диаграмма модели транспорта

Методы тестирования

В случае контроля качества методом «черного ящика» приложение (или какая-либо его законченная часть) анализируется как целое. Этот метод используется для проверки того, что приложение (его часть) отвечает предъявляемым требованиям. Контроль качества методом «белого (стеклянного) ящика»белого (стеклянного) ящика, методконтроль качества; метод белого (стеклянного) ящикамодульное тестирование;метод белого (стеклянного) ящикатестирование; модульное;метод белого (стеклянного) ящика осуществляется на уровне компонентов, из которых построено тестируемое приложение (его часть). Можно провести такую аналогию: если вы проверяете работу телевизора, просто включая и выключая его и переключая каналы, то вы применяете метод «черного ящика»черного ящика, методконтроль качества; метод черного ящикамодульное тестирование; метод черного ящикатестирование;модульное; метод черного ящика; если же вы тестируете телевизор, анализируя его работу на уровне взаимодействия микросхем, то есть компонентов, из которых телевизор собран, вы применяете метод «белого ящика». Промежуточным является метод «серого ящика»серого ящика, методконтроль качества;метод серого ящикамодульное тестирование;метод серого ящикатестирование;модульное;метод серого ящика (ситуация, когда вы проверяете основные компоненты телевизора). Заметим, что грань между «белым» и «серым» здесь зачастую расплывчата.

Рис. 1. Осуществление контроля качества

Чаще всего о методах «черного» и «белого ящика» говорят в контексте тестирования. Однако эти методы применимы и к другим способам контроля качества. Метод модульное тестирование;метод белого (стеклянного) ящикатестирование;модульное;метод белого (стеклянного) ящика«белого ящика» основан на рассмотрении анализируемого артефакта с точки зрения его структуры, формы и назначения; здесь применяются формальныеформальные методы проектированияметоды проектирования, формальные методы и рассматриваемое в следующем разделе инспектирование. Метод контроль качества;метод черного ящикамодульное тестирование;метод черного ящикатестирование;модульное;метод черного ящика«черного ящика» задается вопросом: «Обладает ли построенный объект требуемым поведением?»

Метод «Белого ящика»

Тестирование методом «белого ящика» предпологает обработку системы как «прозрачного объекта» и позволяет заглянуть внутрь, фокусируя внимание на использовании знаний о конкретном программном обеспечении для правильного подбора тестовых данных. Синонимами понятия метода «Белого ящика» являются: структурное тестирование, метод прозрачного ящика, метод стеклянного ящика. В отличие от метода «Черного ящика» данный метод основан на использовании определенных знаний программного кода, необходимых для контроля корректности данных на выходе. Тест является правильным только в том случае когда тестировщик знает что конкретно должна делать программа. Таким образом тестировщик может контролировать ожидаемый результат. Тестирование методом «Белого ящика» не обрабатывает случайные ошибки, но наряду с этим весь видимый код должен быть удобочитаемым.

Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними (рис. 2).

Рис. 2. Тестирование «белого ящика»

Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. Обычно анализируются управляющие связи элементов, реже — информационные связи. Тестирование по принципу «белого ящика» характеризуется степенью, в какой тесты выполняют или покрывают логику (исходный текст) программы. Исчерпывающее тестирование также затруднительно. Особенности этого принципа тестирования рассмотрим отдельно.

Особенности тестирования «белого ящика»

Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.

В этом случае формируются тестовые варианты, в которых:

• гарантируется проверка всех независимых маршрутов программы;

• проходятся ветви True, False для всех логических решений;

• выполняются все циклы (в пределах их границ и диапазонов);

• анализируется правильность внутренних структур данных.

Недостатки тестирования «белого ящика»:

1. Количество независимых маршрутов может быть очень велико. Например, если цикл в программе выполняется k раз, а внутри цикла имеется п ветвлений, то количество маршрутов вычисляется по формуле

. При п = 5 и k = 20 количество маршрутов т = 1014. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.

2. Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

3. В программе могут быть пропущены некоторые маршруты.

4. Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных (это ошибки, обусловленные выражениями типа if abs (a-b)

Показать полностью…
Похожие документы в приложении