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

Оглавление Лекция №1-2 3 Информационные системы и их функции 3 Понятие информационной системы 3 Библиографический список 10 Лекция №3-4 11 Функции информационных систем 11 Библиографический список 20 Лекция №5-6 21 Классификация информационных систем 21 Классификации ИС 21 Проектирование ИС 25 Библиографический список 27 Лекция №7-10 28 Модель клиент-сервер 28 Клиенты и серверы 28 Разделение приложений по уровням 32 Варианты архитектуры клиент-сервер 35 Библиографический список 38 Лекция №11-12 39 Связь 39 Уровни протоколов 39 Удаленный вызов процедур 42 Обращение к удаленным объектам 42 Библиографический список 47 Лекция №13-14 48 Связь посредством сообщений 48 Связь на основе потоков данных 53 Библиографический список 57 Лекция №15-16 58 Оценка технических параметров ИС и ее компонент 58 Общая постановка задачи 58 Стандарты управления качеством промышленной продукции 61 Библиографический список 63 Лекция №17-18 64 Отказоустойчивость 64 Основные концепции 64 Модели отказов 66 Маскирование ошибок при помощи избыточности 69 Библиографический список 71 Лекция №19-20 72 Жизненный цикл информационных систем 72 Каскадная и спиральная модели 73 CALS 75 Стандарты CALS 76 Эксплуатация информационных систем 78 Эффективность реализации CALS 79 Лекция №21-22 80 Общая стоимость владения информационной инфраструктурой 80 Краткий экскурс в историю 82 Модели IT-затрат 83 Роль TCO для предприятия 85 Два подхода к вопросу управления IТ-затратами 86 Планирование TCO 86 Лекция №23-24 89 Защита информации 89 Угрозы, правила и механизмы 89 Библиографический список 94 Лекция №25-26 95 Вопросы разработки 95 Библиографический список 100 Лекция №27-28 101 Криптография 101 Библиографический список 108 Лекция №1-2 Информационные системы и их функции Создание современных электронных вычислительных машин позволи­ло автоматизировать обработку данных во многих сферах человеческой деятельности. Без современных систем обработки данных трудно пред­ставить сегодня передовые производственные технологии, управление экономикой на всех ее уровнях, научные исследования, образование, издательское дело, функционирование средств массовой информации, проведение крупных спортивных состязаний. Значительно расширило сферу применения систем обработки данных появление персональных компьютеров. Одним из наиболее распространенных классов систем обработки дан­ных являются информационные системы. Хотя на уровне здравого смысла назначение таких систем понятно каждому, для серьезного об­суждения технологий современных информационных систем необходи­мо более четко определить, в чем заключаются их специфические осо­бенности, чем они отличаются от других систем обработки данных, какие функции они могут выполнять, какими ресурсами они располагают. Понятие информационной системы Для обсуждения возможностей современных информационных систем, состояния и перспектив используемых в них информационных техноло­гий необходимо прежде всего понять, что такое информационная сис­тема. Применение информационных систем Любой разумный вид де­ятельности основывается на информации о свойствах состояния и пове­дения той части реального мира, с которой связана эта деятельность. Для получения такой информации во многих случаях необходимо регулярно через некоторые интервалы времени проводить натурные измерения (или наблюдения), позволяющие определять характеристики состояния сущностей реального мира и протекающих процессов, соответствующие моментам времени, когда эти измерения производятся. В других случаях удается воспользоваться «материализованной» ин­формацией, содержащейся в различного рода бумажных документах, от­четах или публикациях, которые также выступают как часть реальности. Требуемую информацию можно извлечь из них путем своего рода «на­блюдения». Однако некоторые натурные измерения или наблюдения могут ока­заться неосуществимыми в отведенное для них время в связи с большой трудоемкостью, высокой стоимостью, недоступностью объекта измере­ния (наблюдения) и по другим причинам. Значительно сократить объем необходимых натурных измерений поз­воляет компьютерное моделирование реальности. Если компьютер­ная модель адекватно (относительно информационных потребностей пользователей) отражает состояние и динамику реальности, то многие необходимые сведения можно получать с помощью такой модели, избе­гая тем самым натурных измерений, с существенно меньшими затратами времени, а возможно, и при более низкой стоимости. Именно для подде­ржки таких моделей служит специальный класс систем обработки дан­ных — автоматизированные информационные системы. Заметим, что в ряде публикаций их называют более привычным для современного читателя термином — компьютерные информационные системы. Определение понятия «информационная система» Автоматизи­рованной информационной системой называется комплекс, включа­ющий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динами­ческой информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей. Часть реального мира, которая моделируется информационной систе­мой, называется ее предметной областью. Под динамической моделью здесь понимается изменяемость моде­ли во времени. Это «живая», действующая модель, в которой отобра­жаются изменения, происходящие в предметной области. Такая система должна обладать памятью, позволяющей ей сохранять не только сведе­ния о текущем состоянии предметной области, но и в некоторых случа­ях предысторию. Поскольку модель предметной области, поддерживаемая информа­ционной системой, материализуется в форме организованных необходи­мым образом информационных ресурсов, она называется информаци­онной моделью. Автоматизированная информационная система не всегда функциониру­ет самостоятельно. Она может входить в качестве компонента (подсисте­мы) в более сложную систему, такую, например, как система управления торговой компанией, САПР или система управления производством. Информационные системы уже многие десятки и даже сотни лет су­ществуют и используются на практике в форме различного рода карто­тек и/или коллекций бумажных документов. Однако в таких системах от­сутствует какая-либо автоматизация обработки данных. Они позволяют лишь регистрировать и поддерживать в систематизированной форме на бумажных носителях результаты произведенных натурных измерений. Поскольку здесь и далее обсуждаются только автоматизирован­ные информационные системы, то есть системы, основанные на исполь­зовании средств вычислительной техники и программного обеспечения, бу­дем далее опускать для краткости прилагательное «автоматизированная». Приведенное выше определение охватывает информационные сис­темы всех видов, в частности фактографические системы, которые ос­нованы на технологиях баз данных и оперируют структурированными данными, системы текстового поиска, оперирующие документами на ес­тественных языках, глобальную гипермедийную информационную систе­му Web и др. По этой причине в определении используется обобщенный термин информационные ресурсы. Частными его случаями являются данные для систем баз данных, документы для систем текстового по­иска, HTML-страницы или XML-документы для Web и т. д. Нужно, однако, заметить, что на более низких уровнях представле­ния (в памяти компьютеров, при передаче по каналам связи и т.д.) ин­формационные ресурсы независимо от их природы и формы представле­ния рассматриваются как хранимые или передаваемые данные. Термин «данные» часто используется по отношению к информационным ресур­сам любого рода. Отсутствие общепринятого определения Важный факт состоит в том, что единого устоявшегося и общепринятого определения понятия «инфор­мационная система» в настоящее время не существует, да и вряд ли оно может существовать. Дело в том, что в зависимости от необходимости в разных случаях используются разные точки зрения на такой сложный продукт высоких технологий, каким являются современные информаци­онные системы. Так, специалисты по системному проектированию трак­туют понятие информационная система более широко, чем комплекс, о котором идет речь в нашем определении. При этом в состав информа­ционной системы включаются, например, организационно-методические и технологические документы. Проблемы, связанные с нечеткостью определения понятия «информационная система», вовсе не являются настолько безобидными, как это могло бы показаться. Например, в области системного проектирования и стандартов, касающихся этого вида деятельности, вопрос о четком определении понятия информационной системы является особенно злободневным. От ответа на него зависит, в частности, что же следует считать результатом проектирования. Приведем определение информационной системы, заимствованное в одном из наиболее авторитетных международных научных журналов в рассматриваемой области — «Information Systems», выпускаемом с 1975 года крупным английским издательством Pergamon Press. Редакционная коллегия журнала определяет информационные системы как «аппаратно-программные системы, которые поддерживают приложения с интенсивной обработкой данных (Data-Intensive Applications)». В этом определении акцентируется внимание на весьма важном, но лишь единственном аспекте информационных систем. Заметим, что приложение информационной системы понимается здесь как надстройка над информационной системой, обеспечивающая решение некоторого комплекса задач в интересах какой-либо сферы деятельности. Большинство опубликованных определений информационной системы трактует это понятие с функциональной точки зрения, а именно как «систему, предназначенную для сбора, передачи обработки, хранения и выдачи информации потребителям и состоящую из следующих основных компонентов: программное обеспечение, информационное обеспечение, технические средства, обслуживающий персонал». При этом остается в стороне направленность этих функций — цель, для достижения которой они осуществляются. В отличие от многих других публикаций, в приведенном определении делается акцент на главном назначении информационных систем, а не на их функциях и ресурсах, которые они не используют. Поддержка динамической информационной модели предметной области — это то общее, что свойственно любой информационной системе независимо от характера информационных ресурсов, которыми она оперирует, и, следовательно, от информационных технологий, на которых она основана. Именно такой подход является наиболее продуктивным в данной работе, поскольку хотелось бы с единых позиций рассмотреть здесь базовые направления технологий современных информационных систем — технологии баз данных, систем текстового поиска, технологии Web. Следствия общности определения В силу того, что широкораспространенные определения информационной системы формулируются излишне общо или недостаточно полно, к категории информацион­ных систем часто относят многие системы обработки данных, кото­рые не только поддерживают информационную модель предметной области, но и позволяют решать на ее основе некоторые классы за­дач управленческого, исследовательского, конструкторского или иного характера. По сути дела, такая система представляет собой уже не инфор­мационную систему, а информационную систему вместе с приложением. В эту категорию попадают, например, так называемые корпоративные информационные системы, которые более естественно было бы назы­вать системами управления корпорациями, или системы планирования ресурсов предприятия ERP (Enterprise Resources Planning Systems). Четкую границу между такими системами и информационной системой в определенном здесь смысле провести практически невозможно. Ситуация усугубляется еще и тем, что специалисты в разных облас­тях, не являясь профессионалами в области информационных систем, часто полагаются на кажущийся интуитивно ясным смысл понятия «ин­формационная система» и в результате весьма вольно с ним обращают­ся, как и с другими «заезженными» терминами. Так обстоит дело, на­пример, с термином база данных. Часто базой данных называют любую совокупность данных, независимо от того, идет ли разговор в контексте технологий баз данных. Граница между системой базы данных и приложением Частным слу­чаем указанной выше терминологической проблемы является вопрос о границе между системой базы данных и ее приложением. Традиционно система базы данных понимается как СУБД с уп­равляемой ею базой данных, возможно, уже наполненной. В неко­торых не очень частых случаях система базы данных бывает само­достаточной. Функциональные возможности пользовательских интерфейсов СУБД способны полностью удовлетворять информаци­онные потребности пользователей. Однако во многих случаях дело обстоит совсем не так, и необходи­мо создавать приложение. Приложение системы базы данных, в соот­ветствии с приведенным выше определением приложения информацион­ной системы, это надстройка над системой базы данных, представляющая собой комплекс средств прикладного программного обеспечения, кото­рый служит для решения каких-либо задач на основе этой системы. Приложение с помощью интерфейсов прикладного программирования (Application Programming Interface, API) СУБД получает доступ к базе данных и использует содержащиеся в ней данные для решения необходи­мых пользователям задач. Таким образом, прикладная система, основанная на технологиях баз данных, представляет собой совокупность системы базы данных и прило­жения. Граница между ними четко определена — это интерфейсы при­кладного программирования СУБД. Но ситуация изменилась во второй половине 90-х годов, когда SQL-серверы баз данных стали обеспечивать некоторые возможности интеграции приложения и системы базы данных с помощью триг­геров, хранимых процедур и внешних программ. Появилась, таким об­разом, возможность встраивать различные процедурные элементы при­ложения в систему базы данных. Соответствующие дополнения были приняты к стандарту языка SQL. Но в ситуации, когда приложение включает такие интегрированные компоненты, четкой границы между ним и системой базы данных уже не существует. Ресурсы информационных систем Информационные системы ис­пользуют ресурсы нескольких категорий — средства вычислитель­ной техники, системное и прикладное программное обеспечение, ин­формационные, лингвистические и человеческие ресурсы. Кроме того, хотя об этом не говорится в известных определениях автоматизирован­ных информационных систем, но подразумевается как само собой разу­меющееся, для функционирования системы необходимы и другие ресур­сы — помещения, их техническое оснащение, всевозможная оргтехника, электроснабжение и т.д. В этой книге они не рассматриваются, поскольку не имеют непосредственного отношения к информационным технологиям. Информационные системы могут базироваться на различных аппа­ратных платформах — персональных компьютерах, мейнфреймах, суперкомпьютерах и других вычислительных системах. Они могут ис­пользовать отдельные компьютеры или вычислительные системы либо вычислительные сети различного масштаба — от локальной до глобаль­ной сети. В информационных системах могут использоваться наряду с универсальными также и специализированные компьютеры, например, так называемые машины баз данных, аппаратным путем реализующие некоторые функции реляционной алгебры. Коммуникационное оборудование в информационных системах обеспечивает взаимодействие компонентов распределенных систем, на­пример, обмен данными между компьютерами сети, а также удаленный доступ пользователей к ресурсам системы. К числу коммуникационных ресурсов относятся выделенные или коммутируемые проводные и бес­проводные каналы связи, различное сетевое оборудование, а также устройства приема-передачи информации, например, телефонные или радиомодемы, антенные устройства. Системное программное обеспечение включает операционные сис­темы для используемых аппаратных платформ, различные операцион­ные оболочки, повышающие уровень пользовательского интерфейса, системы программирования, разнообразные системные тесты, служеб­ные программы для поддержки деятельности системного администрато­ра и для других целей, сетевое программное обеспечение. Информационные системы используют также разнообразное при­кладное программное обеспечение, типовое и специализированное. Типовое прикладное программное обеспечение ориентировано на классы задач. Оно может настраиваться на конкретный случай использова­ния. Чаще всего в качестве таких средств используются коммерческие про­граммные продукты: СУБД общего назначения, Web-серверы, системы текс­тового поиска (их по традиции часто называют информационно-поисковыми системами), системы управления документами, текстовые процессоры, кон­верторы данных, программы распознавания текста и речи, системы элект­ронных таблиц, генераторы отчетов для систем баз данных и др. Специализированное прикладное программное обеспечение со­здается для конкретной информационной системы или для класса сис­тем, имеющих некоторое узкое назначение. Например, в корпоративной информационной системе это могут быть программы, предназначенные для поддержки каких-либо конкретных бизнес-процессов. Прикладное программное обеспечение информационных систем мо­жет относиться к стадии разработки или к стадии исполнения. Оно может быть общего назначения или ориентированным на конкретную предмет­ную область. Наконец, программное обеспечение может быть ориенти­рованным на конкретную аппаратную платформу или мобильным. Лингвистические ресурсы информационных систем служат для: - представления информационных ресурсов в системе; - описания их свойств и свойств окружающей среды, позволяющего системе адекватно интерпретировать поддерживаемые информацион­ные ресурсы; - обеспечения взаимодействия пользователей с системой. В общем случае к числу лингвистических ресурсов относятся те или иные естественные или искусственные языки, а также средства их лин­гвистической поддержки — словари лексики естественных языков, те­заурусы предметной области, переводные словари и др. Следует отметить, что тезаурусы играют в информационных систе­мах двоякую роль. С одной стороны, это средство лингвистической подде­ржки используемого в системе естественного языка. Поэтому он должен быть отнесен к категории лингвистических ресурсов. Вместе с тем теза­урус используется как контекст для интерпретации семантики поддержи­ваемых в системе документов, представленных на естественном языке. В связи с этим правомерно также считать тезаурус информационным ре­сурсом системы. Используемый в конкретных случаях набор лингвистических ресурсов системы зависит от требований, предъявляемых к ней. Информационные ресурсы системы составляют главный компонент модели предметной области, которую система поддерживает. Они явля­ются вместе с тем «сырьем» и «конечным продуктом» работы информа­ционной системы. Конкретный вид информационных ресурсов зависит от характера системы. В системах, основанных на технологиях баз данных, поддержива­ются структурированные данные, организованные в виде таблиц или каких-либо иных структур данных. К информационным ресурсам систем баз данных относятся также и схемы баз данных. В текстовых системах информационные ресурсы включают коллекции документов, представленных на естественных языках. Это информаци­онные ресурсы для конечных пользователей. Кроме того, поддерживают­ся тезаурусы, спецификации онтологий и т. п., которые являются информационными ресурсами, используе­мыми самой системой. Пользовательские информационные ресурсы в Web — это страницы Web-сайтов, ресурсы «скрытого» Web — базы данных, а также различ­ные доступные пользователям Web-документы, представленные в форма­тах, отличных от HTML. В Web нового поколения к инфор­мационным ресурсам, кроме того, относятся не только представленные на Web-сайтах XML-документы, но и данные, описыва­ющие схемы XML-документов, их семантику, онтологии. Пользователи информационной системы Важно уточнить, как трак­туется понятие пользователь. В контексте рассмотрения технологий информационных систем целесообразно несколько расши­рить трактовку понятия «пользователь». Прежде всего, к числу пользователей информационных систем отно­сятся специалисты в предметной области системы, для удовлетворения информационных потребностей которых система создается. Пользовате­лей этой категории называют конечными пользователями. Будем считать, что пользователями системы являются не только конеч­ные пользователи, но и программные средства приложений, применяю­щие информационные ресурсы данной информационной системы для ре­шения собственных задач. В некоторых информационных системах контингент пользователей не зафиксирован. Информационные ресурсы таких систем свободно пре­доставляются любому пользователю. В других системах для того, чтобы стать пользователем, необходимо получить от системного администрато­ра требуемые полномочия доступа к системе, а иногда и к некоторым ее информационным ресурсам. Специализированные информационные системы Завершая раз­говор о терминологии, нужно обратить внимание еще на один момент. Во многих публикациях употребляется словосочетание специализирован­ная информационная система. Из нашего определения информацион­ной системы следует, что универсальных информационных систем не бы­вает. Каждая из них существует в единственном числе, ее тиражирование бессмысленно, поскольку такая система моделирует конкретную пред­метную область, поддерживает характеризующие ее свойства информа­ционные ресурсы, которые ассоциированы с конкретными моментами или периодами времени. Поэтому специализированной является каждая информационная система. Что же касается термина «специализирован­ная информационная система», то он не просто бесполезен, он дезори­ентирует, наводя на мысль о существовании универсальных информаци­онных систем, что не соответствует действительности. Библиографический список 1. Когаловский, М. Р. Перспективные технологии информационных систем / М. Р. Когаловский. — М.: ДМК Пресс; М.: Компания АйТи, 2003. — 288 с. Лекция №3-4 Функции информационных систем Рассмотрим теперь функции, которые должны выполнять информаци­онные системы для решения стоящих перед ними задач, связанных с поддержкой динамической информационной модели предметной области и с удовлетворением информационных потребностей ее поль­зователей. К числу этих функций относятся сбор и регистрация информационных ресурсов, их хранение, обработка, актуализация, обеспечивающая акту­ализацию поддерживаемой информационной модели предметной области (для простоты здесь рассматривается только статическая часть модели), а также обработка запросов пользователей. Сбор и регистрация информационных ресурсов Эти функции обеспечивают «фотографирование» предметной области, формирова­ние и поддержку на этой основе модели предметной области экстенси­онального уровня. Для выполнения этих функций проводятся работы как вне програм­мно-аппаратного комплекса системы, так и непосредственно в его среде. Способы реализации указанных функций зависят от характера используе­мых источников информации, в качестве которых могут служить: сущности и процессы в предметной области системы, различного рода автоматизиро­ванные технические системы, другие информационные системы, всевозмож­ные данные на бумажных или электронных носителях и т. п. Функции сбора и регистрации информационных ресурсов могут сов­мещаться во времени или выполняться последовательно. Возможны раз­личные варианты их осуществления, например: - путем измерений (наблюдений) фактов в реальном мире и ввода дан­ных в систему вручную с помощью клавиатуры и/или каких-либо ма­нипуляторов; - полуавтоматически путем ввода в компьютер с некоторых носи­телей и в случае необходимости их оцифровки (например, при ис­пользовании текстов на бумажных носителях или аналоговых ау­диозаписей); - автоматически с помощью различного рода датчиков или обмена данными с другими автоматизированными системами. С этими функциями механизмов информационных систем и их персо­нала связана необходимость решения ряда сопутствующих задач, таких как очистка, верификация, сжатие данных, конвертирование их из одно­го формата в другой и т. д. Очистка данных — необходимая стадия предварительной обработки данных и подготовки их к загрузке в систему, особенно в случаях, когда используется несколько источников данных. Обычно она включает про­цедуры фильтрации данных, верификации, обеспечения логической це­лостности, устранения несогласованности, избыточности и различных ошибок, восполнения пропусков, а также другие процедуры, направ­ленные на улучшение качества данных. Задачи перечисленных проце­дур в некоторой мере пересекаются. В результате фильтрации производится отбор нужных данных из множества имеющихся в распоряжении. Верификация данных обеспе­чивает достоверность и логическую целостность данных. Проверка до­стоверности данных — это содержательная процедура, которая поз­воляет установить, адекватно ли характеризуют состояние предметной области собранные для ввода в информационную систему информаци­онные ресурсы. Эта процедура, к сожалению, не может быть в полной мере формализована. Поэтому она в значительной мере возлагается на системный персонал и привлекаемых к этой работе экспертов. В систе­мах баз данных за достоверность данных ответственен администратор данных. Проверка логической целостности данных может осущест­вляться на стадии предварительной их обработки, а также непосредс­твенно при вводе в систему. Для этих целей в системах баз данных могут, в частности, использоваться механизмы СУБД, специально предназна­ченные для проверки ограничений целостности, которые были объявле­ны в схеме базы данных. Такая проверка осуществляется при обновлении состояния базы данных. Проверку целостности XML-документов может выполнять Web-браузер при условии, если для этого документа задано описание типа документов (DTD). Выбор конкретных ме­тодов обеспечения верификации данных зависит от характера их источ­ников, качества данных, видов ограничений целостности и т. п. В некоторых информационных системах информационные ресурсы хранятся в сжатом виде. Сжатие данных осуществляется с целью ми­нимизации ресурсов памяти, необходимых для их хранения, а также для снижения затрат на передачу данных по коммуникационным каналам. Та­кой подход часто используется в различных репозиториях информацион­ных ресурсов с файловой организацией среды хранения. Механизмы сре­ды хранения данных некоторых СУБД включают встроенные средства, обеспечивающие сжатие отдельных значений данных, кортежей, доме­нов значений атрибутов и т. д., сжатие индексных файлов, резервных ко­пий базы данных. Для рационального использования ресурсов памяти в некоторых классах систем, например в системах управления докумен­тами, документы подразделяются на активные и архивные. Хранение ар­хивных документов осуществляется в сжатых форматах. Конвертирование данных при вводе в систему используется для преобразования данных из одного формата в другой, допускающий автоматизированный импорт их в информационную систему. Конвертирова­ние данных часто необходимо в случаях, когда источником данных явля­ется некоторая другая система. Хранение информационных ресурсов Эта функция информацион­ных систем связана с необходимостью управления двумя видами ресур­сов — ресурсами хранимых данных и ресурсами памяти. Требования к этим функциям различаются в разных классах информационных сис­тем. Рассмотрим, каким же образом организованы хранение информа­ционных ресурсов и доступ к ним в наиболее распространенных классах информационных систем. В системах текстового поиска каждый документ хранится обычно в от­дельном файле. Доступ к документам осуществляется с помощью струк­тур данных, называемых индексами. Индексы в системах текстового по­иска позволяют определять адрес размещения нужного файла по, так называемым, индексирующим свойствам хранящегося в нем докумен­та — по значениям каких-либо атрибутов, ассоциированных с докумен­том, по содержащимся в нем словам или словосочетаниям и т. п. При этом единицей доступа является полный документ. Управление памятью осуществляется в таких системах средствами компонента операционной системы компьютера, называемого файловой системой или системой управления файлами. Индексы документов в системах текстового по­иска организуются в виде так называемых инвертированных списков. Для каждого значения индексирующего свойства документов в таких индек­сах поддерживаются адреса или идентификаторы файлов, их содержащих. Файловая организация хранения информационных ресурсов исполь­зуется также в действующей версии Web, основанной на технологиях HTML. Здесь каждая HTML-страница представлена в общем случае в виде совокупности файлов. Главный из них — это основной структу­рообразующий файл данной страницы. Он имеет формат HTML. Кро­ме того, в отдельных файлах представлены встроенные изображения и другие компоненты страницы, на которые имеются ссылки в ее глав­ном файле. Доступ к страницам Web осуществляется непосредственно по их уникальным «адресам» в Web, называемым URL (Universal Resource Locator), либо с использованием навигации по гиперссылкам. Еди­ницей доступа здесь является полная страница Web, хотя при навигации очередная гиперссылка может указывать только на фрагмент страницы. Функции управления ресурсами памяти, служащими для хранения ре­сурсов Web, возлагаются на операционные системы тех компьютеров сети, которые содержат используемые страницы. Нужно заметить, что в связи с интенсивным ростом объемов инфор­мационных ресурсов Web навигационный доступ к требуемым ресур­сам стал неэффективным. Пользователям Web обычно известно лишь ограниченное количество URL интересующих их страниц Web. Поэто­му он в сравнительно небольшом числе случаев может воспользоваться прямым доступом к информационным ресурсам Web. Вот почему стали создаваться приложения Web, называемые поиско­выми машинами. Поисковая машина с некоторой периодичностью про­сматривает страницы закрепленной за ней группы Web-сайтов и строит либо актуализирует полнотекстовые индексы для этих страниц. На этой основе осуществляется обработка пользовательских запросов так, как это делается в системах текстового поиска. Более тонкую организацию имеют механизмы управления хранением данных и пространством памяти в информационных системах, основан­ных на технологиях баз данных. Причины заключаются в том, что в сис­темах баз данных используются более сложные структуры данных, тре­буется значительно более мелкая гранулярность доступа к ресурсам, более динамичный характер имеют хранимые данные. Управление хранимыми данными в системах баз данных включает поддержку структуры хранимых данных, их размещение в пространстве памяти, поддержку физической целостности и обеспечение эффективно­го доступа к ним. Чаще всего используются прямой и последовательный доступ к единицам информационных ресурсов в каком-либо определен­ном порядке. Прямой доступ осуществляется по известным значениям некоторых свойств (ключей) единиц информационных ресурсов. Для этой цели ис­пользуются вспомогательные хранимые структуры данных, обеспечива­ющие отображение ключей в адреса размещения соответствующих еди­ниц информационных ресурсов, например строк таблиц в реляционных базах данных. Чаще всего в качестве таких вспомогательных структур используются эффективно организованные индексы и хеш-таблицы. Индексные структуры, организованные в виде деревьев специаль­ных видов, обеспечивают быстрый поиск с помощью навигации в этих деревьях по коротким цепочкам указателей и, возможно, ограниченного перебора. Существует большое многообразие способов построения ин­дексов. Хеш-таблицы, в отличие от индексов, обеспечивают определение ад­реса размещения искомой (или размещаемой) единицы информацион­ных ресурсов не путем навигации в индексной структуре, а с помощью вычисления некоторой функции отображения ключа в адрес. Значе­ния этой функции представляют собой случайные числа, равномерно распределенные в заданном интервале, которые используются как номера участков во внешней памяти или строк таблицы хеширования, содержащих соответствующие единицы информационных ресурсов или их адреса. Индексные структуры поддерживают доступ к хранимым единицам ин­формационных ресурсов в порядке соответствующих им ключей. Про­стая техника хеширования таких возможностей не предоставляет. Для этих целей применяют усовершенствованные методы хеширования. Последовательный доступ к хранимым единицам информационных ре­сурсов осуществляется в порядке их физического размещения либо по зна­чениям некоторых содержащихся в них или ассоциированных с ними иден­тификаторов (ключей). В последнем случае для поддержки необходимой упорядоченности обычно используют индексы по заданным ключам. Нужно заметить, что в унаследованных СУБД, основанных на гра­фовых моделях данных, использовался также и навигационный доступ к хранимым данным. Управление ресурсами памяти в СУБД включает такие опера­ции, как учет свободного пространства памяти, выделение пространс­тва для размещения новых вводимых в систему информационных ресур­сов, так называемая сборка мусора — возвращение освободившегося пространства памяти в пул свободного пространства для повторного его использования. Нужно назвать здесь также операцию реорганизации среды хранения базы данных. В результате выполнения этой операции изменяется размещение хранимых данных в пространстве памяти систе­мы таким образом, чтобы стало возможным более эффективное исполь­зование ресурсов свободной памяти, а также чтобы сократить время до­ступа к часто используемым хранимым данным и т. п. Важно заметить, что способы размещения информационных ресурсов в пространстве памяти системы и способы доступа к ним тесно связаны. Среда хранения в системах баз данных также базируется на файловой организации. Однако над файловой системой надстраиваются механиз­мы, обеспечивающие более тонкие методы управления данными в тер­минах элементов содержания файлов. Единицей доступа здесь является, как уже отмечалось, не файл или порция файла, предусмотренная в фай­ловой системе, а порции информационных ресурсов с гораздо более мел­кой гранулярностью. Актуализация информационных ресурсов В соответствии с приве­денным выше определением назначение информационной системы состоит в поддержке динамической информационной модели ее предмет­ной области. Для того чтобы эта модель была практически полезной, необходимо своевременно и адекватно отображать в ней изменения состояния предметной области. Требуется актуализировать модель. Для этой цели нужно актуализировать информационные ресурсы системы. Актуализация информационных ресурсов системы заключается в приве­дении их в соответствие текущему состоянию предметной области системы. В реляционных системах баз данных эта задача сводится к включению и/или удалению строк в таблицах базы данных, обновлению значений столбцов в некоторых строках. В случаях, когда изменяется структура предметной области системы, актуализация информационных ресурсов заключается в изменении схемы базы данных — добавлении или удале­нии столбцов таблиц, существующих в базе данных, к созданию новых и/или удалению существующих таблиц и т.д. В системах текстового поиска актуализация информационных ресур­сов чаще всего осуществляется путем ввода в систему новых или (реже) удаления существующих документов. При актуализации Web-сайта в состав его ресурсов включаются но­вые или удаляются существующие страницы, модифицируются гипер­ссылки, связывающие страницы данного сайта и, возможно, страницы других сайтов, редактируется содержание существующих страниц. Из приведенных примеров нетрудно видеть, что характер изменений, происходящих в предметной области и моделируемых в информацион­ной системе, может быть различным. В одних случаях изменяются зна­чения свойств принадлежащих ей сущностей и связей. В более сложных случаях изменяются структура предметной области и/или ее поведенчес­кие свойства. Соответственно, разную природу имеют и процессы актуа­лизации информационных ресурсов. Так, в системах баз данных в случаях первого рода изменяются значения данных, а при изменениях структуры предметной области изменяется схема базы данных. Используя ранее введенные термины, можно сказать, что актуализа­ция модели предметной области, поддерживаемой информационной сис­темой, может касаться как интенсионального, так и экстенсионального представления предметной области в системе. Актуализация информационных ресурсов в информационных систе­мах производится дискретно, через определенные интервалы времени. Поэтому адекватность состояния модели предметной области и ее состо­яния в реальности обеспечивается с временным лагом, величина кото­рого равна продолжительности указанных интервалов. Величина лага может изменяться для разных систем в довольно широком диапазоне времени и зависит от назначения системы и особенностей ее предмет­ной области. В информационных системах, входящих в состав систем управления сложными техническими объектами, например в системе управления космическими полетами, лаг измеряется в миллисекундах. В корпоративных информационных системах он может составлять ми­нуты и часы. В некоторых исследовательских экономических системах возможен лаг, составляющий дни, месяцы, кварталы и годы. Для того чтобы информационная система соответствовала своему на­значению, важно соблюдать установленный для нее регламент актуали­зации информационных ресурсов. Обработка информационных ресурсов Некоторые информационные системы способны предоставлять пользователям только информационные ре­сурсы, ранее введенные в систему и хранящиеся в ней без какой-либо трансформации. Такая ситуация чаще всего встречается в системах текс­тового поиска, которые выдают пользователю документы, удовлетворя­ющие условиям запроса. В то же время системы баз данных способ­ны продуцировать данные, производные от ранее введенных в систему и хранимых в базе данных. Достаточно упомянуть весьма развитое средс­тво, предусмотренное для этих целей в реляционных СУБД, — механизм поддержки представлений данных (View). Продуцирование производных данных обеспечивается также в Web-сайтах с динамической генерацией страниц. Существуют текстовые информационные системы, позволяю­щие генерировать для хранимых документов их рефераты. Возможность обработки информационных ресурсов, поддерживаемых в информационных системах, предусмотрена в приведенном ранее опре­делении информационной системы. Она предусматривается и в отечес­твенном стандарте терминологии по автоматизированным системам. При этом характер и содержание обеспечиваемой информационными системами обработки представленных в них информационных ресурсов не уточняется и не регламентируется для того, чтобы определение име­ло достаточно общий характер и позволяло бы охватить представитель­ное множество систем. Однако побочным эффектом такой общности определения является отнесение к этой категории многочисленных систем обработки данных, обладающих «памятью» и имеющих некоторое достаточно четко выра­женное прикладное функциональное назначение, выходящее за рамки непосредственного назначения информационных систем. Существуют информационные системы, не только самостоятельно функционирую­щие, но и входящие в качестве функционального компонента в различ­ные более сложные системы. Примерами могут служить системы управ­ления крупными компаниями, которые решают большие комплексы задач, связанных с обеспечением жизнедеятельности компаний. Такие системы используют информационную систему как составную часть. Но вместе с тем они включают и крупные функциональные компоненты, использу­ющие информационные ресурсы информационной системы для решения специфических задач системы — бухгалтерский учет, обработка заказов, управление запасами, планирование производства и т. п. Квалификация этих систем, как корпоративных информационных систем представляется неубедительной. Фактически мы имеем здесь дело с объединением инфор­мационной системы и ее приложения. Такую объединенную систему за ру­бежом принято называть Management Information System (MIS) — управ­ленческой информационной системой. Нужно заметить, что обработка информационных ресурсов в инфор­мационных системах не сводится лишь к продуцированию производной информации. Обработка осуществляется и для выполнения ряда систем­ных функций, например для проверки ограничений целостности, для по­иска в индексах, словарях и т. п. Предоставление информационных ресурсов пользователям Поддержка в информационной системе информационных ресурсов, позволяющих моде­лировать состояние и поведение предметной области, конечно же, не яв­ляется самоцелью. Это делается для удовлетворения информационных потребностей пользователей. Предоставление информационных ресурсов пользователям информа­ционной системы может осуществляться с помощью pull-технологий и/или push-технологий. В первом случае предполагается, что инициатором предоставления информационных ресурсов является пользователь, а во втором — сама система, в соответствии с определенным регламентом и для определен­ного круга пользователей. Для предоставления информационных ресурсов по инициативе поль­зователя в информационной системе предусматриваются пользователь­ские интерфейсы — средства взаимодействия пользователей с системой. Характер пользовательских интерфейсов и их функции зависят от категории пользователей системы. Пользовательский интерфейс в общем случае включает интерфейс­ные технические средства, язык или языки интерфейса, программные средства, поддерживающие функционирование интерфейсного оборудо­вания и языков интерфейса. Как уже указывалось выше, предполагается, что сущест­вует две категории пользователей информационных систем: - конечные пользователи — специалисты в предметной области системы, обычно осуществляющие доступ к ее информационным ресур­сам в интерактивном режиме; - прикладные программы, использующие информационные ресурсы данной системы и являющиеся компонентами какого-либо ее приложения. Технические средства интерфейса конечного пользователя могут включать периферийное оборудование ввода-вывода компьютера (клавиатура мышь или другие манипуляторы, средства виртуальной реальности), монитор и другие средства воспроизведения информации, а также иные устройства. Программы, обеспечивающие их функционирование, входят в состав операционной системы или разрабатываются специально поставщиком соответствующего оборудования. Это могут быть, например, драйверы для устройств такого рода. Технические средства интерфейса пользователей — компонентов при­кладного программного обеспечения — могут включать коммуникацион­ные ресурсы данной информационной системы, обеспечивающие телекоммуникационный доступ к ней. В простейшем случае информационные потребности конечных поль­зователей регламентированы, известен их перечень. Иногда они зависят от каких-либо параметров, например даты, названия продукта, фамилии покупателя. Таких пользователей способен удовлетворить так называе­мый «кнопочный» интерфейс. Каждому виду запросов в таком интер­фейсе соответствует некоторая клавиша клавиатуры или альтернати­ва показываемого на экране меню. Нажатие соответствующей клавиши или выбор нужной альтернативы в меню приводит к выдаче пользовате­лю интересующих его информационных ресурсов. В большинстве случаев, однако, информационные потребности конечных пользователей имеют нерегламентированный характер. По­этому интерфейс конечного пользователя в системе с такими возмож­ностями должен включать какой-либо язык запросов. Для взаимодействия конечных пользователей с информационной системой с помощью языков запросов служат два вида пользовательских интерфейсов: - интерфейсы командной строки; - интерфейсы, основанные на языках четвертого поколения (4GL, 4th Generation Language). В первом случае для ввода сообщений и команд в систему служит язык запросов, имеющий свой алфавит и синтаксические правила для конструирования из его символов правильных команд или операторов. В ка­честве языков запросов используются естественные и искусственные языки. Естественные языки запросов обычно используются в системах текстового поиска и в поисковых машинах действующей версии Web. Некоторые такие системы имеют мультиязыковой интерфейс — за­просы могут формулироваться на одном из естественных языков из за­данного набора. Искусственные языки запросов применяются в системах, основан­ных на технологиях баз данных, а также в Web нового поколения и его приложениях. В настоящее время, как правило, используются непроце­дурные декларативные языки запросов. Языки четвертого поколения не являются языками в привыч­ном смысле. Это пользовательские интерфейсы, которые обеспечивают ввод в систему сообщений с помощью выбора подходящих альтернатив в меню, ввода параметров через окна экранных форм, применения раз­личных возможностей графического пользовательского интерфейса. Тер­мин «язык четвертого поколения» был предложен американским спе­циалистом по системам обработки данных Джеймсом Мартином (James Martin). Пользователи системы — компоненты прикладного программного обеспечения — осуществляют доступ к ресурсам данной системы с помо­щью интерфейсов прикладного программирования (API, Application Programming Interface). Средства таких интерфейсов можно применять только в программах, создаваемых с помощью систем программирова­ния, на которые эти интерфейсы рассчитаны. Доступ пользователей к ресурсам системы возможен только в преде­лах предоставленных им полномочий, которые обычно проверяются сис­темными механизмами при попытках доступа. Наделение пользователей необходимыми полномочиями — функция системного администра­тора. Некоторые системы предоставляют свободный доступ к опреде­ленным ресурсам. Так, например, обстоит дело со многими Web-сайтами. Рассмотрим теперь случай использования push-технологии для предоставления информационных ресурсов пользователям. Такая техноло­гия широко применяется в последние годы для распространения раз­личного рода информации среди пользователей Internet. С этой целью стандартное сообщение рассылается по списку рассылки всем пользова­телям, в нем зарегистрированным. По этому принципу функционируют многочисленные телеконференции в Internet. Таким же образом органи­зовано информирование пользователей некоторых электронных библи­отек о поступлении новых документов в библиотеку. Однако, к сожале­нию, регистрация в списке рассылки осуществляется не всегда с учетом согласия пользователя. Одним из прибыльных сфер бизнеса в Internet стало коллекционирование действующих адресов пользователей сети. Базы данных, содержащие миллионы адресов, поставляются всем жела­ющим за скромную плату. Такие базы данных охотно приобретаются не­добросовестными рекламными службами коммерческих компаний, кото­рые используют их для бездумной рассылки своей рекламы. Это привело к огромному росту трафика в Internet, к резкому снижению удельного веса полезной информации в потоках передаваемых в Internet сообщений. Другие функции Выше были рассмотрены основные функции ин­формационной системы, видимые пользователю. Однако они не ис­черпывают всех существенных ее функций. Ряд из них возлагается на персонал системы и на ее программное обеспечение. К ним, в част­ности, относятся: - управление распределенными информационными ресурсами, напри­мер фрагментация баз данных, тиражирование данных, синхрониза­ция копий; - защита физической целостности информационных ресурсов и их восстановление при разрушениях; - обеспечение информационной безопасности в системе; - управление метаданными; - администрирование информационными ресурсами; - обеспечение адаптации системы к изменениям требований к ней и к из­менениям в предметной области. Библиографический список 1. Когаловский, М. Р. Перспективные технологии информационных систем / М. Р. Когаловский. — М.: ДМК Пресс; М.: Компания АйТи, 2003. — 288 с. Лекция №5-6 Классификация информационных систем Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации. Классификации ИС Информационные системы можно классифицировать по целому ряду различных признаков. В основу рассматриваемой классификации положены наиболее существенные признаки, определяющие функциональные возможности и особенности построения современных систем. В зависимости от объема решаемых задач, используемых технических средств, организации функционирования, информационные системы делятся на ряд групп (классов) (рис. 1.1). Рис. 1.1. Классификация информационных систем 1. По типу хранимых данных ИС делятся на фактографические и документальные. - Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции. - В документальных системах информация представлена в виде документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится. 2. Основываясь на степени автоматизации информационных процессов в системе управления фирмой, информационные системы делятся на ручные, автоматические и автоматизированные. - Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком. - В автоматических ИС все операции по переработке информации выполняются без участия человека. - Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятия «информационная система». 3. В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие. - Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. (Например, ИС библиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр.) - Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие. Результирующая информация управляющих ИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИС планирования производства или заказов, бухгалтерского учета.) Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных. (Например, экспертные системы.) 4. В зависимости от сферы применения различают следующие классы ИС. - Информационные системы организационного управления предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр.). Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи. - ИС управления технологическими процессами (ТП) служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (температуры, давления, химического состава и т.п.), процедур контроля допустимости значений параметров и регулирования технологических процессов. - ИС автоматизированного проектирования (САПР) предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов. Таблица 1.1. Функциональное назначение модулей корпоративной ИС. Подсистема маркетинга Производственные подсистемы Финансовые и учетные подсистемы Подсистема кадров (человеческих ресурсов) Прочие подсистемы (например, ИС руководства) Исследование рынка и прогнозирование продаж Планирование объемов работ и разработка календарных планов Управление портфелем заказов Анализ и прогнозирование потребности в трудовых ресурсах Контроль за деятельностью фирмы Управление продажами Оперативный контроль и управление производством Управление кредитной политикой Ведение архивов записей о персонале Выявление оперативных проблем Рекомендации по производству новой продукции Анализ работы оборудования Разработка финансового плана Анализ и планирование подготовки кадров Анализ управленческих и стратегических ситуаций Анализ и установление цены Участие в формировании заказов поставщикам Финансовый анализ и прогнозирование Обеспечение процесса выработки стратегических решений Учет заказов Управление запасами Контроль бюджета, бухгалтерский учет и расчет зарплаты - Интегрированные (корпоративные) ИС используются для автоматизации всех функций фирмы и охватывают весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности. Типовые задачи, решаемые модулями корпоративной системы, приведены в таблице 1.1. Анализ современного состояния рынка ИС показывает устойчивую тенденцию роста спроса на информационные системы организационного управления. Причем спрос продолжает расти именно на интегрированные системы управления. Автоматизация отдельной функции, например, бухгалтерского учета или сбыта готовой продукции, считается уже пройденным этапом для многих предприятий. В таблице 1.2 приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов. Таблица 1.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) 5. Существует классификация ИС в зависимости от уровня управления, на котором система используется. - Информационная система оперативного уровня поддерживает исполнителей, обрабатывая данные о сделках и событиях (счета, накладные, зарплата, кредиты, поток сырья и материалов). Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой. Задачи, цели, источники информации и алгоритмы обработки на оперативном уровне заранее определены и в высокой степени структурированы. - Информационные системы специалистов поддерживают работу с данными и знаниями, повышают продуктивность и производительность работы инженеров и проектировщиков. Задача подобных информационных систем — интеграция новых сведений в организацию и помощь в обработке бумажных документов. - Информационные системы уровня менеджмента используются работниками среднего управленческого звена для мониторинга, контроля, принятия решений и администрирования. Основные функции этих информационных систем: • сравнение текущих показателей с прошлыми; • составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне; • обеспечение доступа к архивной информации и т.д. - Стратегическая информационная система — компьютерная информационная система, обеспечивающая поддержку принятия решений по реализации стратегических перспективных целей развития организации. Информационные системы стратегического уровня помогают высшему звену управленцев решать неструктурированные задачи, осуществлять долгосрочное планирование. Основная задача — сравнение происходящих во внешнем окружении изменений с существующим потенциалом фирмы. Они призваны создать общую среду компьютерной телекоммуникационной поддержки решений в неожиданно возникающих ситуациях. Используя самые совершенные программы, эти системы способны в любой момент предоставить информацию из многих источников. Некоторые стратегические системы обладают ограниченными аналитическими возможностями. 6. С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС. - Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. - Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). - Следующая разновидность архитектуры информационной системы основывается на концепции «хранилища данных» (DataWarehouse) — интегрированной информационной среды, включающей разнородные информационные ресурсы. - И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода. Проектирование ИС Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х – 1960-х годах и к концу века приобрела вполне законченные формы. На первом этапе основным подходом в проектировании ИС был метод «снизу-вверх», когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках «лоскутной автоматизации» достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему. Создавая свои отделы и управления автоматизации, предприятия пытались «обустроиться» своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие — и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы. Следующий этап связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться «сверху-вниз», т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей. Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели. Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета. В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности. Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем. Цель такой методологии заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решению которых должна способствовать методология проектирования корпоративных ИС, являются следующие: • обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика; • гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта; • поддерживать удобную дисциплину сопровождения, модификации и наращивания системы; • обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий). Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС — от замысла до реализации. Библиографический список 1. Грекул В.И., Денищенко Г.Н. Проектирование информационных систем. М.: Интернет-Университет Информационных технологий, 2008. Лекция №7-10 Модель клиент-сервер До этого момента мы вряд ли сказали что-то о действительной организации рас­пределенных систем, более интересуясь тем, как в этих системах организованы процессы. Несмотря на то, что достичь согласия по вопросам, связанным с распре­деленными системами, было нелегко, по одному из вопросов исследователи и раз­работчики все же договорились. Они пришли к выводу о том, что мышление в понятиях клиентов, запрашивающих службы с серверов, помогает понять слож­ность распределенных систем и управляться с ней. В этом разделе мы кратко рас­смотрим модель клиент-сервер. Клиенты и серверы В базовой модели клиент-сервер все процессы в распределенных системах делят­ся на две возможно перекрывающиеся группы. Процессы, реализующие некото­рую службу, например службу файловой системы или базы данных, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посыл­ки запроса и последующего ожидания ответа от сервера, называются клиентами (clients). Взаимодействие клиента и сервера, известное также под названием ре­жим работы запрос-ответ (request-reply behavior), иллюстрирует рис. 1.18. Рис. 1.18. Обобщенное взаимодействие между клиентом и сервером Если базовая сеть так же надежна, как локальные сети, взаимодействие меж­ду клиентом и сервером может быть реализовано посредством простого протоко­ла, не требующего установления соединения. В этом случае клиент, запрашивая службу, облекает свой запрос в форму сообщения с указанием в нем службы, ко­торой он желает воспользоваться, и необходимых для этого исходных данных. Затем сообщение посылается серверу. Последний, в свою очередь, постоянно ожидает входящего сообщения, получив его, обрабатывает, упаковывает резуль­тат обработки в ответное сообщение и отправляет его клиенту. Использование не требующего соединения протокола дает существенный вы­игрыш в эффективности. До тех пор пока сообщения не начнут пропадать или повреждаться, можно вполне успешно применять протокол типа запрос-ответ. К сожалению, создать протокол, устойчивый к случайным сбоям связи, — нетри­виальная задача. Все, что мы можем сделать, — это дать клиенту возможность повторно послать запрос, на который не был получен ответ. Проблема, однако, состоит в том, что клиент не может определить, действительно ли первоначаль­ное сообщение с запросом было потеряно или ошибка произошла при передаче ответа. Если потерялся ответ, повторная посылка запроса может привести к по­вторному выполнению операции. Если операция представляла собой что-то вроде «снять 10000 долларов с моего банковского счета», понятно, что было бы гораз­до лучше, если бы вместо повторного выполнения операции вас просто уведоми­ли о произошедшей ошибке. С другой стороны, если операция была «сообщите мне, сколько денег у меня осталось», запрос прекрасно можно было бы послать повторно. Нетрудно заметить, что у этой проблемы нет единого решения. В качестве альтернативы во многих системах клиент-сервер используется на­дежный протокол с установкой соединения. Хотя это решение в связи с его отно­сительно низкой производительностью не слишком хорошо подходит для ло­кальных сетей, оно великолепно работает в глобальных системах, для которых ненадежность является «врожденным» свойством соединений. Так, практически все прикладные протоколы Интернета основаны на надежных соединениях по протоколу TCP/IP. В этих случаях всякий раз, когда клиент запрашивает служ­бу, до посылки запроса серверу он должен установить с ним соединение. Сервер обычно использует для посылки ответного сообщения то же самое соединение, после чего оно разрывается. Проблема состоит в том, что установка и разрыв со­единения в смысле затрачиваемого времени и ресурсов относительно дороги, особенно если сообщения с запросом и ответом невелики. Примеры клиента и сервера Чтобы внести большую ясность в то, как работают клиент и сервер, в этом пункте мы рассмотрим описание клиента и файлового сервера на языке Pascal. И клиент, и сервер должны совместно использовать некоторые определения, которые мы соберем вместе в файл под названием header.pas, текст которого приведен в лис­тинге 1.3. Эти определения затем включаются в тексты программ клиента и сер­вера следующей строкой: uses header.pas; Листинг 1.3. Файл header.pas, используемый клиентом и сервером /* Определения, необходимые и клиентам, и серверам */ Const /* Максимальная длина имени файла */ МАХ_РАТН = 255; /* Максимальное количество данных, передаваемое за один раз */ BUF_SIZE = 1024; /* Сетевой адрес файлового сервера */ FILE_SERVER = 243; /* Определения разрешенных операций */ /* создать новый файл */ OP_CREATE = 1; /* считать данные из файла и вернуть их */ OP_READ = 2; /* записать данные в файл */ OP_WRITE = 3; /* удалить существующий файл */ OP_DELETE = 4; /* Коды ошибок */ /* операция прошла успешно */ OK = 0; /* запрос неизвестной операции */ E_BAD_OPER = -1; /* ошибка в параметре */ E_BAD_PARAM = -2; /* ошибка диска или другая ошибка чтения-записи */ E_IO = –3; /* Определение формата сообщения */ type TMessage = record source: longint; /* идентификатор источника */ dest: longint; /* идентификатор приемника */ opcode: longint; /* запрашиваемая операция */ count: longint; /* число передаваемых байт */ offset: longint; /* позиция в файле, с которой начинается ввод-вывод */ result: longint; /* результат операции */ name: string[MAX_PATH]; /* имя файла, с которым производятся операции */ data: string [BUF_SIZE]; /* данные, которые будут считаны или записаны */ end; Итак, перед нами текст файла header.pas. Он начинается с определения двух констант, МАХ_РАТН и BUF_SIZE, которые определяют размер двух массивов, исполь­зуемых в сообщении. Первая задает число символов, которое может содержаться в имени файла (то есть в строке с путем типа /usr/ast/books/opsys/chapter1.t). Вторая задает размер блока данных, который может быть прочитан или записан за одну операцию путем установки размера буфера. Следующая константа, FILE_ SERVER, задает сетевой адрес файлового сервера, на который клиенты могут посы­лать сообщения. Вторая группа констант задает номера операций. Они необходимы для того, чтобы и клиент, и сервер знали, какой код представляет чтение, какой код — за­пись и т. д. Мы приводим здесь только четыре константы, в реальных системах их обычно больше. Каждый ответ содержит код результата. Если операция завершена успешно, код результата обычно содержит полезную информацию (например, реальное число считанных байтов). Если нет необходимости возвращать значение (напри­мер, при создании файла), используется значение ОК. Если операция по каким-либо причинам окончилась неудачей, код результата (E_BAD_OPER, E_BAD_PARAM и др.) сообщает нам, почему это произошло. Наконец, мы добрались до наиболее важной части файла header.pas — определе­ния формата сообщения. В нашем примере это структура с 8 полями. Этот фор­мат используется во всех запросах клиентов к серверу и ответах сервера. В ре­альных системах, вероятно, фиксированного формата у сообщений не будет (по­скольку не во всех случаях нужны все поля), но здесь это упростит объяснение. Поля source и dest определяют, соответственно, отправителя и получателя. Поле opcode — это одна из ранее определенных операций, то есть create, read, write или delete. Поля count и offset требуются для передачи параметров. Поле result в за­просах от клиента к серверу не используется, а при ответах сервера клиенту со­держит значение результата. В конце структуры имеются два массива. Первый из них, name, содержит имя файла, к которому мы хотим получить доступ. Во вто­ром, data, находятся возвращаемые сервером при чтении или передаваемые на сервер при записи данные. Давайте теперь рассмотрим код в листингах 1.4 и 1.5. Листинг 1.4 — это про­грамма сервера, листинг 1.5 — программа клиента. Программа сервера достаточно элементарна. Основной цикл начинается вызовом receive в ответ на сообщение с запросом. Первый параметр определяет отправителя запроса, поскольку в нем указан его адрес, а второй указывает на буфер сообщений, идентифицируя, где должно быть сохранено пришедшее сообщение. Процедура receive блокирует сервер, пока не будет получено сообщение. Когда оно наконец приходит, сервер продолжает свою работу и определяет тип кода операции. Для каждого кода опе­рации вызывается своя процедура. Входящее сообщение и буфер для исходящих сообщений заданы в параметрах. Процедура проверяет входящее сообщение в параметре m1 и строит исходящее в параметре m2. Она также возвращает значе­ние функции, которое передается через поле result. После посылки ответа сер­вер возвращается к началу цикла, выполняет вызов receive и ожидает следующе­го сообщения. В листинге 1.5 находится процедура, копирующая файлы с использованием сервера. Тело процедуры содержит цикл чтения блока из исходного файла и за­писи его в файл-приемник. Цикл повторяется до тех пор, пока исходный файл не будет полностью скопирован, что определяется по коду возврата операции чте­ния — должен быть ноль или отрицательное число. Первая часть цикла состоит из создания сообщения для операции чтения и пе­ресылки его на сервер. После получения ответа запускается вторая часть цикла, в ходе выполнения которой полученные данные посылаются обратно на сервер для записи в файл-приемник. Программы из листингов 1.4 и 1.5 — это только на­бросок кода. В них опущено множество деталей. Так, например, не приводятся процедуры do_xxx (которые на самом деле выполняют работу), отсутствует также обработка ошибок. Однако общая идея взаимодействия клиента и сервера вполне понятна. В следующих пунктах мы ближе рассмотрим некоторые дополнитель­ные аспекты модели клиент-сервер. Листинг 1.4. Пример сервера uses header.pas; var m1, m2: TMessage; /* входящее и исходящее сообщения */ r: integer; /* код результата */ begin while(TRUE) do /* сервер работает непрерывно */ begin receive(FILE_SERVER, m1); /* блок ожидания сообщения */ case m1.opcode of /* в зависимости от типа запроса */ OP_CREATE: r := do_create(m1, m2); OP_READ: r := do_read(m1, m2); OP_WRITE: r := do_write(m1, m2); OP_DELETE: r := do_delete(m1, m2); else r := E_BAD_OPER; end; m2.result := r; /* вернуть результат клиенту */ send(m1.source, m2): /* послать ответ */ end end. Листинг 1.5. Клиент, использующий сервер из листинга 1.4 для копирования файла uses header.pas; /* процедура копирования файла через сервер */ function copy(src: string, dst: string): integer; var m1: TMessage; /* буфер сообщения */ position: longint; /* текущая позиция в файле */ client: longint = 110; /* адрес клиента */ begin initialize(); /* подготовиться к выполнению */ position := 0; repeat m1.opcode := OP_READ; /* операция чтения */ m1.offset := position; /* текущая позиция в файле */ m1.count := BUF_SIZE; /* сколько байт прочитать */ m1.name := src; /* скопировать имя читаемого файла*/ send(FILESERVER, m1); /* послать сообщение на файловый сервер*/ receive(client, m1); /* блок ожидания ответа */ /* Записать полученные данные в файл-приемник. */ m1.opcode := OP_WRITE; /* операция: запись */ m1.offset := position; /* текущая позиция в файле */ m1.count := m1.result; /* сколько байт записать */ ml.name := dst); /* скопировать имя записываемого файла*/ send(FILE_SERVER, m1); /* послать сообщение на файловый сервер */ receive(client, m1); /* блок ожидания ответа */ position := position + m1.result; /* в m1.result содержится количество записанных байтов */ until( m1.result <= 0 ); /* повторять до окончания */ /* вернуть ОК или код ошибки */ if(m1.result >= 0 then result := OK else result := m1.result); end; Разделение приложений по уровням Модель клиент-сервер была предметом множества дебатов и споров. Один из главных вопросов состоял в том, как точно разделить клиента и сервера. Понят­но, что обычно четкого различия нет. Например, сервер распределенной базы данных может постоянно выступать клиентом, передающим запросы на различ­ные файловые серверы, отвечающие за реализацию таблиц этой базы данных. В этом случае сервер баз данных сам по себе не делает ничего, кроме обработки запросов. Однако рассматривая множество приложений типа клиент-сервер, предна­значенных для организации доступа пользователей к базам данных, многие ре­комендовали разделять их на три уровня. - уровень пользовательского интерфейса; - уровень обработки; - уровень данных. Уровень пользовательского интерфейса содержит все необходимое для непо­средственного общения с пользователем, например, для управление дисплеем. Уровень обработки обычно содержит приложения, а уровень данных — собст­венно данные, с которыми происходит работа. В следующих пунктах мы обсу­дим каждый из этих уровней. Уровень пользовательского интерфейса Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот уровень содержит программы, посредством которых пользователь может взаимо­действовать с приложением. Сложность программ, входящих в пользовательский интерфейс, весьма различна. Простейший вариант программы пользовательского интерфейса не содержит ничего, кроме символьного (не графического) дисплея. Такие интерфейсы обыч­но используются при работе с мэйнфреймами. В том случае, когда мэйнфрейм контролирует все взаимодействия, включая работу с клавиатурой и монитором, мы вряд ли можем говорить о модели клиент-сервер. Однако во многих случаях терминалы пользователей производят некоторую локальную обработку, осуще­ствляя, например, эхо-печать вводимых строк или предоставляя интерфейс форм, в котором можно отредактировать введенные данные до их пересылки на главный компьютер. В наше время даже в среде мэйнфреймов наблюдаются более совершенные пользовательские интерфейсы. Обычно на клиентских машинах имеется как ми­нимум графический дисплей, на котором можно задействовать всплывающие или выпадающие меню и множество управляющих элементов, доступных для мыши или клавиатуры. Типичные примеры таких интерфейсов — надстройка X-Windows, используемая во многих UNIX-системах, и более ранние интерфейсы, раз­работанные для персональных компьютеров, работающих под управлением MS-DOS и Apple Macintosh. Современные пользовательские интерфейсы значительно более функцио­нальны. Они поддерживают совместную работу приложений через единст­венное графическое окно и в ходе действий пользователя обеспечивают через это окно обмен данными. Например, для удаления файла часто достаточно перенести значок, соответствующий этому файлу, на значок мусорной кор­зины. Аналогичным образом многие текстовые процессоры позволяют поль­зователю перемещать текст документа в другое место, пользуясь только мы­шью. Уровень обработки Многие приложения модели клиент-сервер построены как бы из трех различных частей: части, которая занимается взаимодействием с пользователем, части, кото­рая отвечает за работу с базой данных или файловой системой, и средней части, реализующей основную функциональность приложения. Эта средняя часть логи­чески располагается на уровне обработки. В противоположность пользователь­ским интерфейсам или базам данных на уровне обработки трудно выделить об­щие закономерности. Однако мы приведем несколько примеров для разъяснения вопросов, связанных с этим уровнем. В качестве первого примера рассмотрим поисковую машину в Интернете. Если отбросить все анимированные баннеры, картинки и прочие оконные укра­шательства, пользовательский интерфейс поисковой машины очень прост: поль­зователь вводит строку, состоящую из ключевых слов, и получает список заго­ловков web-страниц. Результат формируется из гигантской базы просмотренных и проиндексированных web-страниц. Ядром поисковой машины является про­грамма, трансформирующая введенную пользователем строку в один или не­сколько запросов к базе данных. Затем она помещает результаты запроса в спи­сок и преобразует этот список в набор HTML-страниц. В рамках модели клиент-сервер часть, которая отвечает за выборку информации, обычно находится на уровне обработки. Эта структура показана на рис. 1.19. Рис. 1.19. Обобщенная организация трехуровневой поисковой машины для Интернета В качестве второго примера рассмотрим систему поддержки принятия реше­ний для фондового рынка. Так же как и в поисковой машине, эту систему можно разделить на внешний интерфейс, реализующий работу с пользователем, внут­реннюю часть, отвечающую за доступ к базе с финансовой информацией, и проме­жуточную программу анализа. Анализ финансовых данных может потребовать замысловатых методик и технологий на основе статистических методов и искус­ственного интеллекта. В некоторых случаях для того, чтобы обеспечить требуе­мые производительность и время отклика, ядро системы поддержки финансовых решений должно выполняться на высокопроизводительных компьютерах. Нашим последним примером будет типичный офисный пакет, состоящий из текстового процессора, приложения для работы с электронными таблицами, ком­муникационных утилит и т. д. Подобные офисные пакеты обычно поддерживают обобщенный пользовательский интерфейс, возможность создания составных до­кументов и работу с файлами в домашнем каталоге пользователя. В этом случае уровень обработки будет включать в себя относительно большой набор про­грамм, каждая из которых призвана поддерживать какую-то из функций обра­ботки. Уровень данных Уровень данных в модели клиент-сервер содержит программы, которые предо­ставляют данные обрабатывающим их приложениям. Специфическим свойством этого уровня является требование сохранности (persistence). Это означает, что когда приложение не работает, данные должны сохраняться в определенном мес­те в расчете на дальнейшее использование. В простейшем варианте уровень дан­ных реализуется файловой системой, но чаще для его реализации задействуется полномасштабная база данных. В модели клиент-сервер уровень данных обычно находится на стороне сервера. Кроме простого хранения информации уровень данных обычно также отвеча­ет за поддержание целостности данных для различных приложений. Для базы данных поддержание целостности означает, что метаданные, такие как описания таблиц, ограничения и специфические метаданные приложений, также хранятся на этом уровне. Например, в приложении для банка мы можем пожелать сформи­ровать уведомление, если долг клиента по кредитной карте достигнет определен­ного значения. Это может быть сделано при помощи триггера базы данных, кото­рый в нужный момент активизирует процедуру, связанную с этим триггером. Обычно в деловой среде уровень данных организуется в форме реляционной базы данных. Ключевым здесь является независимость данных. Данные органи­зуются независимо от приложений так, чтобы изменения в организации данных не влияли на приложения, а приложения не оказывали влияния на организацию данных. Использование реляционных баз данных в модели клиент-сервер помо­гает нам отделить уровень обработки от уровня данных, рассматривая обработку и данные независимо друг от друга. Однако существует обширный класс приложений, для которых реляционные базы данных не являются наилучшим выбором. Характерной чертой таких при­ложений является работа со сложными типами данных, которые проще модели­ровать в понятиях объектов, а не отношений. Примеры таких типов данных — от простых наборов прямоугольников и окружностей до проекта самолета в случае систем автоматизированного проектирования. Также и мультимедийным систе­мам значительно проще работать с видео- и аудиопотоками, используя специ­фичные для них операции, чем с моделями этих потоков в виде реляционных таблиц. В тех случаях, когда операции с данными значительно проще выразить в по­нятиях работы с объектами, имеет смысл реализовать уровень данных средства­ми объектно-ориентированных баз данных. Подобные базы данных не только поддерживают организацию сложных данных в форме объектов, но и хранят реа­лизации операций над этими объектами. Таким образом, часть функционально­сти, приходившейся на уровень обработки, мигрирует в этом случае на уровень данных. Варианты архитектуры клиент-сервер Разделение на три логических уровня, обсуждавшееся в предыдущем пункте, на­водит на мысль о множестве вариантов физического распределения по отдель­ным компьютерам приложений в модели клиент-сервер. Простейшая организа­ция предполагает наличие всего двух типов машин. ♦ Клиентские машины, на которых имеются программы, реализующие толь­ко пользовательский интерфейс или его часть. ♦ Серверы, реализующие все остальное, то есть уровни обработки и данных. Проблема подобной организации состоит в том, что на самом деле система не является распределенной: все происходит на сервере, а клиент представляет со­бой не что иное, как простой терминал. Существует также множество других возможностей, наиболее употребительные из них мы сейчас рассмотрим. Многозвенные архитектуры Один из подходов к организации клиентов и серверов — это распределение про­грамм, находящихся на уровне приложений, описанном в предыдущем пункте, по различным машинам, как показано на рис. 1.20. В качестве первого ша­га мы рассмотрим разделение на два типа машин: на клиенты и на серверы, что приведет нас к физически двухзвенной архитектуре (physically two-tiered archi­tecture). Один из возможных вариантов организации — поместить на клиентскую сторону только терминальную часть пользовательского интерфейса, как показано на рис. 1.20, а, позволив приложению удаленно контролировать представление данных. Альтернативой этому подходу будет передача клиенту всей работы с поль­зовательским интерфейсом (рис. 1.20, б). В обоих случаях мы отделяем от при­ложения графический внешний интерфейс, связанный с остальной частью при­ложения (находящейся на сервере) посредством специфичного для данного приложения протокола. В подобной модели внешний интерфейс делает только то, что необходимо для предоставления интерфейса приложения. Рис. 1.20. Альтернативные формы организации архитектуры клиент-сервер Продолжим линию наших рассуждений. Мы можем перенести во внешний интерфейс часть нашего приложения, как показано на рис. 1.20, в. Примером мо­жет быть вариант, когда приложение создает форму непосредственно перед ее заполнением. Внешний интерфейс затем проверяет правильность и полноту за­полнения формы и при необходимости взаимодействует с пользователем. Дру­гим примером организации системы по образцу, представленному на рис. 1.20, в, может служить текстовый процессор, в котором базовые функции редактирова­ния осуществляются на стороне клиента с локально каптируемыми или находя­щимися в памяти данными, а специальная обработка, такая как проверка орфо­графии или грамматики, выполняется на стороне сервера. Во многих системах клиент-сервер популярна организация, представленная на рис. 1.20, г и д. Эти типы организации применяются в том случае, когда кли­ентская машина — персональный компьютер или рабочая станция — соединена сетью с распределенной файловой системой или базой данных. Большая часть приложения работает на клиентской машине, а все операции с файлами или ба­зой данных передаются на сервер. Рисунок 1.20, д отражает ситуацию, когда часть данных содержится на локальном диске клиента. Так, например, при рабо­те в Интернете клиент может постепенно создать на локальном диске огромный кэш наиболее часто посещаемых web-страниц. Рассматривая только клиенты и серверы, мы упускаем тот момент, что серве­ру иногда может понадобиться работать в качестве клиента. Такая ситуация, от­раженная на рис. 1.21, приводит нас к физически трехзвенной архитектуре (phy­sically three-tiered architecture). В подобной архитектуре программы, составляющие часть уровня обработки, выносятся на отдельный сервер, но дополнительно могут частично находиться и на машинах клиентов и серверов. Типичный пример трехзвенной архитекту­ры — обработка транзакций. В этом случае отдельный процесс — монитор тран­закций — координирует все транзакции, возможно, на нескольких серверах дан­ных. Рис. 1.21. Пример сервера, действующего как клиент Современные варианты архитектуры Многозвенные архитектуры клиент-сервер являются прямым продолжением разделения приложений на уровни пользовательского интерфейса, компонентов обработки и данных. Различные звенья взаимодействуют в соответствии с логи­ческой организацией приложения. Во множестве бизнес-приложений распределен­ная обработка эквивалентна организации многозвенной архитектуры приложе­ний клиент-сервер. Мы будем называть такой тип распределения вертикальным распределением (vertical distribution). Характеристической особенностью вертикаль­ного распределения является то, что оно достигается размещением логически различных компонентов на разных машинах. Это понятие связано с концепцией вертикального разбиения (vertical fragmentation), используемой в распределенных реляционных базах данных, где под этим термином понимается разбиение по столбцам таблиц для их хранения на различных машинах. Однако вертикальное распределение — это лишь один из возможных спосо­бов организации приложений клиент-сервер, причем во многих случаях наименее интересный. В современных архитектурах распределение на клиенты и серверы происходит способом, известным как горизонтальное распределение (horizontal distribution). При таком типе распределения клиент или сервер может содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо. Это делается для выравни­вания загрузки. В качестве распространенного примера горизонтального распределения рас­смотрим web-сервер, реплицированный на несколько машин локальной сети, как показано на рис. 1.22. На каждом из серверов содержится один и тот же набор web-страниц, и всякий раз, когда одна из web-страниц обновляется, ее копии не­замедлительно рассылаются на все серверы. Сервер, которому будет передан приходящий запрос, выбирается по правилу «карусели» (round-robin). Эта фор­ма горизонтального распределения весьма успешно используется для выравни­вания нагрузки на серверы популярных web-сайтов. Таким же образом, хотя и менее очевидно, могут быть распределены и клиен­ты. Для несложного приложения, предназначенного для коллективной работы, мы можем не иметь сервера вообще. В этом случае мы обычно говорим об одно­ранговом распределении (peer-to-peer distribution). Подобное происходит, напри­мер, если пользователь хочет связаться с другим пользователем. Оба они долж­ны запустить одно и то же приложение, чтобы начать сеанс. Третий клиент может общаться с одним из них или обоими, для чего ему нужно запустить то же самое приложение. Рис. 1.22. Пример горизонтального распределения web-службы Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №11-12 Связь Уровни протоколов В условиях отсутствия совместно используемой памяти вся связь в распределенных системах основана на обмене (низкоуровневыми) сообщениями. Если процесс A хочет пообщаться с процессом B, он должен сначала построить сообщение в своем собственном адресном пространстве. Затем он выполняет системный вызов, который пересылает сообщение по сети процессу В. Хотя основная идея выглядит несложной, во избежание хаоса А и В должны договориться о смысле пересылаемых нулей и единиц. Если А посылает потрясающий новый роман, написанный по-французски, в кодировке IBM EBCDIC, а В ожидает результаты переучета в супермаркете, на английском языке и в кодировке ASCII, их взаимодействие будет не слишком успешным. Необходимо множество различных договоренностей. Сколько вольт следует использовать для передачи нуля, а сколько для передачи единицы? Как получатель узнает, что этот бит сообщения — последний? Как ему определить, что сообщение было повреждено или утеряно, и что ему делать в этом случае? Какую длину имеют числа, строки и другие элементы данных и как они отображаются? Короче говоря, необходимы соглашения различного уровня, от низкоуровневых подробностей передачи битов до высокоуровневых деталей отображения информации. Чтобы упростить работу с множеством уровней и понятий, используемых в передаче данных. Международная организация по стандартам (International Standards Organization, ISO) разработала эталонную модель, которая ясно определяет различные уровни, дает им стандартные имена и указывает, какой уровень за что отвечает. Эта модель получила название Эталонной модели взаимодействия открытых систем (Open Systems Interconnection Reference Model). Это название обычно заменяется сокращением модель ISO OSI, или просто модель OSI. Следует заметить, что протоколы, которые должны были реализовывать части модели OSI, никогда не получали широкого распространения. Однако сама по себе базовая модель оказалась вполне пригодной для исследования компьютерных сетей. Несмотря на то что мы не собираемся приводить здесь полное описание этой модели и всех ее дополнений, небольшое введение в нее будет нам полезно. Модель OSI разрабатывалась для того, чтобы предоставить открытым системам возможность взаимодействовать друг с другом. Открытая система — это система, которая способна взаимодействовать с любой другой открытой системой по стандартным правилам, определяющим формат, содержимое и смысл отправляемых и принимаемых сообщений. Эти правила зафиксированы в том, что называется протоколами (protocols). Для того чтобы группа компьютеров могла поддерживать связь по сети, они должны договориться об используемых протоколах. Все протоколы делятся на два основных типа. В протоколах с установлением соединения (connection-oriented) перед началом обмена данными отправитель и получатель должны установить соединение и, возможно, договориться о том, какой протокол они будут использовать. После завершения обмена они должны разорвать соединение. Системой с установлением соединения является, например, телефон. В случае протоколов без установления соединения (connectionless) никакой подготовки не нужно. Отправитель посылает первое сообщение, как только он готов это сделать. Письмо, опущенное в почтовый ящик, — пример связи без установления соединения. В компьютерных технологиях широко применяется как связь с установлением соединения, так и связь без установления соединения. В модели OSI взаимодействие подразделяется на семь уровней, как показано на рис. 2.1. Каждый уровень отвечает за один специфический аспект взаимодействия. Таким образом, проблема может быть разделена на поддающиеся решению части, каждая из которых может разбираться независимо от других. Каждый из уровней предоставляет интерфейс для работы с вышестоящим уровнем. Интерфейс состоит из набора операций, которые совместно определяют интерфейс, предоставляемый уровнем тем, кто им пользуется. Рис. 2.1. Уровни, интерфейсы и протоколы модели OSI Когда процесс А на машине 1 хочет пообщаться с процессом B на машине 2, он строит сообщение и посылает его прикладному уровню своей машины. Этот уровень может представлять собой, например, библиотечную процедуру или реализовываться как-то иначе (например, внутри операционной системы или внешнего сетевого процессора). Программное обеспечение прикладного уровня добавляет в начало сообщения свой заголовок (header) и передает получившееся сообщение через интерфейс с уровня 7 на уровень 6, уровень представления. Уровень представления, в свою очередь, добавляет в начало сообщения свой заголовок и передает результат вниз, на сеансовый уровень и т. д. Некоторые уровни добавляют не только заголовок в начало, но и завершение в конец. Когда сообщение дойдет до физического уровня, он осуществит его реальную передачу, как это показано на рис. 2.2. Рис. 2.2. Передача по сети типового сообщения Когда сообщение приходит на машину 2, оно передается наверх, при этом на каждом уровне считывается и проверяется соответствующий заголовок. В конце концов сообщение достигает получателя, процесса B, который может ответить на него, при этом вся история повторяется в обратном направлении. Информация из заголовка уровня п используется протоколом уровня п. В качестве примера важности многоуровневых протоколов рассмотрим обмен информацией между двумя компаниями, авиакомпанией Zippy Airlines и поставщиком продуктов Mushy Meals, Inc. Каждый месяц начальник отдела обслуживания пассажиров Zippy просит свою секретаршу связаться с секретаршей менеджера по продажам Mushy и заказать 100 000 коробок «резиновых» цыплят. Обычно заказы пересылались почтой. Однако из-за постепенного ухудшения качества почтовых услуг в один прекрасный момент секретарши решают больше не писать друг другу письма, а связываться по факсу. Они могут делать это, не беспокоя своих боссов, поскольку протокол касается физической передачи заказов, а не их содержания. Точно так же начальник отдела обслуживания пассажиров может решить отказаться от цыплят и перейти на новый деликатес от Mushy, превосходные козьи ребра, это решение никак не скажется на работе секретарш. Это происходит потому, что у нас есть два уровня — боссы и их секретарши. Каждый уровень имеет свой собственный протокол (темы для обсуждения и технологию), который можно изменить независимо от другого. Эта независимость делает многоуровневые протоколы привлекательными. Каждый уровень при появлении новых технологий может быть изменен независимо от других. В модели OSI, как было показано на рис. 2.1, не два уровня, а семь. Набор протоколов, используемых в конкретной системе, называется комплектом, или стеком протоколов. Важно отличать эталонную модель от реальных протоколов. Как мы отмечали, протоколы OSI никогда не были популярны. В противоположность им протоколы, разрабатывавшиеся для Интернета, такие как TCP и IP, используются повсеместно. Удаленный вызов процедур Основой множества распределенных систем является явный обмен сообщениями между процессами. Однако процедуры send и receive не скрывают взаимодействия, что необходимо для обеспечения прозрачности доступа. Эта проблема была известна давно, но по ней мало что было сделано до появления в 1980 году статьи, в которой предлагался абсолютно новый способ взаимодействия. Хотя идея была совершенно простой (естественно, после того как кто-то все придумал), ее реализация часто оказывается весьма хитроумной. В этом разделе мы рассмотрим саму концепцию, ее реализацию, сильные и слабые стороны. Если не вдаваться в подробности, в упомянутой статье было предложено позволить программам вызывать процедуры, находящиеся на других машинах. Когда процесс, запущенный на машине A, вызывает процедуру с машины B, вызывающий процесс на машине A приостанавливается, а выполнение вызванной процедуры происходит на машине B. Информация может быть передана от вызывающего процесса к вызываемой процедуре через параметры и возвращена процессу в виде результата выполнения процедуры. Программист абсолютно ничего не заметит. Этот метод известен под названием удаленный вызов процедур (Remote Procedure Call, RPC). Базовая идея проста и элегантна, сложности возникают при реализации. Для начала, поскольку вызывающий процесс и вызываемая процедура находятся на разных машинах, они выполняются в различных адресных пространствах, что тут же рождает проблемы. Параметры и результаты также передаются от машины к машине, что может вызвать свои затруднения, особенно если машины не одинаковы. Наконец, обе машины могут сбоить, и любой возможный сбой вызовет разнообразные сложности. Однако с большинством из этих проблем можно справиться, и RPC является широко распространенной технологией, на которой базируются многие распределенные системы. Обращение к удаленным объектам Объектно-ориентированная технология показала свое значение при разработке нераспределенных приложений. Одним из наиболее важных свойств объекта является то, что он скрывает свое внутреннее строение от внешнего мира посредством строго определенного интерфейса. Такой подход позволяет легко заменять или изменять объекты, оставляя интерфейс неизменным. По мере того как механизм RPC постепенно становился фактическим стандартом осуществления взаимодействия в распределенных системах, люди начали понимать, что принципы RPC могут быть равно применены и к объектам. В этом разделе мы распространим идею RPC на обращения к удаленным объектам и рассмотрим, как подобный подход может повысить прозрачность распределения по сравнению с вызовами RPC. Мы сосредоточимся на относительно простых удаленных объектах. Примером объектных распределенных систем служат CORBA и DCOM, каждая из которых поддерживает более серьезную, совершенную объектную модель, чем та, которую мы будем рассматривать сейчас. Распределенные объекты Ключевая особенность объекта состоит в том, что он инкапсулирует данные, называемые состоянием (state), и операции над этими данными, называемые методами (methods). Доступ к методам можно получить через интерфейс. Важно понять, что единственно правильным способом доступа или манипулирования состоянием объекта является использование методов, доступ к которым осуществляется через интерфейс этого объекта. Объект может реализовывать множество интерфейсов. Точно так же для данного описания интерфейса может существовать несколько объектов, предоставляющих его реализацию. Это подразделение на интерфейсы и объекты, реализующие их, очень важно для распределенных систем. Четкое разделение позволяет нам помещать интерфейс на одну машину при том, что сам объект находится на другой. Структура, показанная на рис. 2.16, обычно и называется распределенным объектом (distributed object). Рис. 2.16. Обобщенная организация удаленных объектов с использованием заместителя клиента Когда клиент выполняет привязку к распределенному объекту, в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy). Заместитель клиента аналогичен клиентской заглушке в системах RPC. Единственное, что он делает, — выполняет маршалинг параметров в сообщениях при обращении к методам и демаршалинг данных из ответных сообщений, содержащих результаты обращения к методам, передавая их клиенту. Сами объекты находятся на сервере и предоставляют необходимые клиентской машине интерфейсы. Входящий запрос на обращение к методу сначала попадает на серверную заглушку, часто именуемую скелетоном (skeleton). Скелетон преобразует его в правильное обращение к методу через интерфейс объекта, находящегося на сервере. Серверная заглушка также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента. Характерной, но немного противоречащей интуитивному представлению особенностью большинства распределенных объектов является то, что их состояние (данные) не распределяется — оно локализовано на одной машине. С других машин доступны только интерфейсы, реализованные в объекте. Такие объекты еще называют удаленными (remote object). Тем не менее, при работе с распределенными объектами, их состояние может быть физически распределено по нескольким машинам, но это распределение также скрывается от клиентов за интерфейсами объектов. Объекты времени компиляции против объектов времени выполнения Объекты в распределенных системах существуют в различных формах. В наиболее распространенном варианте они соответствуют объектам выбранного языка программирования, например Java, C++ или другого объектно-ориентированного языка, и представляют собой объекты времени компиляции. В этих случаях объект является экземпляром класса. Класс — это описание абстрактного типа в виде модуля, содержащего элементы данных и операций над этими данными. Использование объектов времени компиляции в распределенных системах обычно значительно упрощает создание распределенных приложений. Так, в языке Java объект может быть полностью описан в рамках своего класса и интерфейсов, которые этот класс реализует. Компиляция определения класса порождает код, позволяющий создавать экземпляры объектов языка Java. Интерфейсы можно скомпилировать в клиентские и серверные заглушки, позволяющие обращаться к объектам Java с удаленных машин. Разработчик программы на Java чаще всего может не беспокоиться по поводу распределения объектов: он занимается только текстом программы на языке Java. Очевидная оборотная сторона использования объектов времени компиляции состоит в зависимости от конкретного языка программирования. Существует и альтернативный способ создания распределенных объектов — непосредственно во время выполнения. Такой подход характерен для множества объектных распределенных систем, поскольку распределенные приложения, созданные в соответствии с ним, не зависят от конкретного языка программирования. В частности, приложение может быть создано из объектов, написанных на различных языках программирования. При работе с объектами времени исполнения тот способ, которым они будут реализованы, обычно остается открытым. Так, например, разработчик может решить написать на С библиотеку, содержащую набор функций, которые смогут работать с общим файлом данных. Главный вопрос состоит в том, как превратить эту реализацию в объект, методы которого будут доступны с удаленной машины. Традиционный способ состоит в том, чтобы использовать адаптер объектов (object adapter), который послужит оболочкой (wrapper) реализации с единственной задачей — придать реализации видимость объекта. Сам термин «адаптер» взят из шаблона проектирования, который предоставляет интерфейс, преобразуемый в то, что ожидает клиент. Примером адаптера объектов может быть некая сущность, динамически привязываемая к описанной ранее библиотеке на C и открывающая файл данных, соответствующий текущему состоянию объекта. Адаптеры объектов играют важную роль в объектных распределенных системах. Чтобы сделать оболочку как можно проще, объекты определяются исключительно в понятиях интерфейсов, которые они реализуют. Реализация интерфейса регистрируется в адаптере, который, в свою очередь, создает интерфейс для удаленных обращений. Адаптер будет принимать приходящие обращения и создавать для клиентов образ удаленного объекта. Сохранные и нерезидентные объекты Помимо деления на объекты, зависящие от языка программирования, и объекты времени выполнения существует также деление на сохранные и нерезидентные объекты. Сохранный объект (persistent object) — это объект, который продолжает существовать, даже не находясь постоянно в адресном пространстве серверного процесса. Другими словами, сохранный объект не зависит от своего текущего сервера. На практике это означает, что сервер, обычно управляющий таким объектом, может сохранить состояние объекта во вспомогательном запоминающем устройстве и завершить свою работу. Позже вновь запущенный сервер может считать состояние объекта из запоминающего устройства в свое адресное пространство и обработать запрос на обращение к объекту. В противоположность ему, нерезидентный объект (transient object) — это объект, который существует, только пока сервер управляет им. Когда сервер завершает работу, этот объект прекращает существовать. Использовать сохранные объекты или нет — это спорный вопрос. Некоторые полагают, что нерезидентных объектов вполне достаточно. Статическое и динамическое удаленное обращение к методам После того как клиент свяжется с объектом, он может через заместителя обратиться к методам объекта. Подобное удаленное обращение к методам (Remote Method Invocation, RMI) в части маршалинга и передачи параметров очень напоминает RPC. Основное различие между RMI и RPC состоит в том, что RMI, как говорилось ранее, в основном поддерживает внутрисистемные ссылки на объекты. Кроме того, отпадает необходимость в клиентских и серверных заглушках общего назначения. Вместо них мы можем использовать значительно более удобные в работе и специфические для объектов заглушки, которые мы также обсуждали. Стандартный способ поддержки RMI — описать интерфейсы объектов на языке определения интерфейсов, так же как в RPC. Однако с тем же успехом мы можем использовать объектный язык, например Java, который обеспечивает автоматическую генерацию заглушек. Такой подход к применению предопределенных определений интерфейсов часто называют статическим обращением (static invocation). Статическое обращение требует, чтобы интерфейсы объекта при разработке клиентского приложения были известны. Также оно предполагает, что при изменении интерфейса клиентское приложение перед использованием новых интерфейсов будет перекомпилировано. В качестве альтернативы обращение к методам может осуществляться более динамичным образом. В частности, иногда удобнее собрать параметры обращения к методу во время исполнения. Этот процесс известен под названием динамического обращения (dynamic invocation). Основное его отличие от статического обращения состоит в том, что во время выполнения приложение выбирает, какой метод удаленного объекта будет вызван. Динамическое обращение обычно выглядит следующим образом: invoke(object, method, input_parameters, output_parameters); Здесь object идентифицирует распределенный объект; method — параметр, точно задающий вызываемый метод; input_parameters — структура данных, в которой содержатся значения входных параметров метода; output_parameters — структура данных, в которой хранятся возвращаемые значения. В качестве примера рассмотрим добавление целого числа int к объекту fobject файла. Для этого действия объект предоставляет метод append. В этом случае статическое обращение будет иметь вид: fobject.append(int); Динамическое обращение будет выглядеть так: invoke(fobject, id(append), int); Здесь операция id(append) возвращает идентификатор метода append. Для иллюстрации динамического обращения рассмотрим браузер объектов, используемый для просмотра наборов объектов. Предположим, что этот браузер поддерживает удаленное обращение к объектам. Это будет означать, что браузер в состоянии выполнить привязку к распределенному объекту и предоставить пользователю интерфейс с объектом. Пользователю после этого может быть предложено выбрать метод и ввести значения его параметров, после чего браузер сможет произвести действительное обращение. Обычно подобные браузеры объектов разрабатываются так, чтобы они поддерживали любые возможные интерфейсы. Такой подход требует исследования интерфейсов во время выполнения и динамического создания обращений к методам. Другая область применения динамических обращений — службы пакетной обработки, для которых запросы на обращение могут обрабатываться в течение всего того времени, пока обращение ожидает выполнения. Служба может быть реализована в виде очереди запросов на обращение, упорядоченных по времени поступления. Основной цикл службы просто ожидает назначения очередного запроса, удаляет его из очереди и, как это было показано ранее, вызывает процедуру invoke. Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №13-14 Связь посредством сообщений Вызовы удаленных процедур и обращения к удаленным объектам способствуют сокрытию взаимодействия в распределенных системах, то есть повышают прозрачность доступа. К сожалению, ни один из этих механизмов не идеален. В частности, в условиях, когда нет уверенности в том, что принимающая сторона в момент выполнения запроса работает, приходится искать альтернативные пути обмена. Кроме того, синхронную по определению природу RPC и RMI, при которой на время осуществления операции необходимо блокировать клиента, временами тоже хочется заменить чем-то другим. Это «что-то другое» — обмен сообщениями. В этом разделе мы сосредоточимся на использовании в распределенных системах взаимодействия на основе сообщений. Сохранность и синхронность во взаимодействиях Чтобы разобраться во множестве альтернатив в коммуникационных системах, работающих на основе сообщений, предположим, что система организована по принципу компьютерной сети, как показано на рис. 2.19. Приложения всегда выполняются на хостах, а каждый хост предоставляет интерфейс с коммуникационной системой, через который сообщения могут передаваться. Хосты соединены сетью коммуникационных серверов, которые отвечают за передачу (или маршрутизацию) сообщения между хостами. Без потери общности можно предположить, что каждый из хостов связан только с одним коммуникационным сервером. Обычно предполагают, что буферы могут быть размещены исключительно на хостах. Для более общего варианта нам следует рассмотреть варианты с размещением буферов и на коммуникационных серверах базовой сети. Рис. 2.19. Обобщенная организация коммуникационной системы, хосты которой соединяются через сеть В качестве примера рассмотрим разработанную в подобном стиле систему электронной почты. Хосты работают как пользовательские агенты — это пользовательские приложения, которые могут создавать, посылать, принимать и читать сообщения. Каждый хост соединяется только с одним почтовым сервером, который является по отношению к нему коммуникационным сервером. Интерфейс пользовательского хоста разрешает пользовательскому агенту посылать сообщения по конкретным адресам. Когда пользовательский агент представляет сообщение для передачи на хост, хост обычно пересылает это сообщение на свой локальный почтовый сервер, в выходном буфере которого оно хранится до поры до времени. Почтовый сервер удаляет сообщение из своего выходного буфера и ищет, куда его нужно доставить. Поиски места назначения приводят к получению адреса (транспортного уровня) почтового сервера, для которого предназначено сообщение. Затем почтовый сервер устанавливает соединение и передает сообщение на другой, выбранный почтовый сервер. Последний сохраняет сообщение во входящем буфере намеченного получателя, также называемом почтовым ящиком получателя. Если искомый почтовый ящик временно недоступен, например, отключен, то хранить сообщение продолжает локальный почтовый сервер. Интерфейс принимающего хоста предоставляет пользовательским агентам службы, при помощи которых они могут регулярно проверять наличие пришедшей почты. Пользовательский агент может работать напрямую с почтовым ящиком пользователя на локальном почтовом сервере или копировать новые сообщения в локальный буфер своего хоста. Таким образом, сообщения обычно хранятся на коммуникационных серверах, но иногда и на принимающем хосте. Система электронной почты — это типичный пример сохранной связи (persistent communication). При сохранной связи сообщение, предназначенное для отсылки, хранится в коммуникационной системе до тех пор, пока его не удастся передать получателю. Если отталкиваться от рисунка, можно сказать, сообщение сохраняется на коммуникационном сервере до тех пор, пока его не удастся передать на следующий коммуникационный сервер. Поэтому у отправляющего сообщение приложения нет необходимости после отправки сообщения продолжать работу. Аналогично, у приложения, принимающего сообщения, также нет необходимости находиться в рабочем состоянии во время отправки сообщения. Система сохранной связи сравнима по принципу работы с почтовой системой Pony Express (рис. 2.20). Отправка письма начинается с доставки его в местное почтовое отделение. Почтовое отделение отвечает за сортировку почты в зависимости от того, в какое следующее почтовое отделение на пути к конечному пункту доставки ее нужно отправить. В нем также хранят соответствующие сумки с почтой, отсортированной по месту назначения, и ждут появления лошади со своим всадником. В пункте назначения письма вновь сортируются в зависимости от того, заберут ли их адресаты прямо здесь или нужно передать эти письма следующему почтальону. Отметим, что письма никогда не теряются и не пропадают. Несмотря на то что средства доставки, так же как и средства сортировки писем, за прошедшую сотню лет изменились, принципы сортировки, хранения и пересылки почты остались неизменными. Рис. 2.20. Сохранная связь — доставка писем во времена Pony Express В противоположность сохранной связи при нерезидентной связи (transient communication) сообщение хранится в системе только в течение времени работы приложений, которые отправляют и принимают это сообщение. Точнее говоря (если опять отталкиваться от рис. 2.20), мы имеем дело с такой ситуацией, когда коммуникационный сервер, не имея возможности передать сообщение следующему серверу или получателю, просто уничтожает его. Обычно все коммуникационные службы транспортного уровня поддерживают только нерезидентную связь. В этом случае коммуникационный сервер соответствует традиционному маршрутизатору «получил — передал». Если маршрутизатор не в состоянии переслать сообщение следующему маршрутизатору или принимающему хосту, сообщение просто теряется. Помимо сохранной и нерезидентной связи существует деление на синхронную и асинхронную связь. Характерной чертой асинхронной связи (asynchronous communication) является немедленное после отправки письма продолжение работы отправителя. Это означает, что письмо сохраняется в локальном буфере передающего хоста или на ближайшем коммуникационном сервере. В случае синхронной связи (synchronous communication) отправитель блокируется до того момента, пока его сообщение не будет сохранено в локальном буфере принимающего хоста или доставлено реальному получателю. Наиболее жесткая форма синхронного взаимодействия предполагает, что отправитель остается блокированным и на время обработки его сообщения получателем. На практике применяются различные комбинации этих типов взаимодействия. В случае сохранной асинхронной связи сообщение сохраняется в буфере либо локального хоста, либо первого коммуникационного сервера. Этот вид связи обычно используется в системах электронной почты. В случае сохранной синхронной связи сообщения хранятся только на принимающем хосте. Отправитель блокируется до момента сохранения сообщения в буфере получателя. Отметим, что приложение, принявшее сообщение, не обязано сохранять его на своем локальном хосте. «Усеченный» вариант сохранной синхронной связи состоит в том, что отправитель блокируется до момента сохранения сообщения на коммуникационном сервере, соединенном с принимающим хостом. Нерезидентная асинхронная связь характерна для служб дейтаграмм транспортного уровня, таких как UDP. Когда приложение отправляет сообщение, оно временно сохраняется в локальном буфере передающего хоста, после чего отправитель немедленно продолжает работу. Параллельно коммуникационная система направляет сообщение в точку, из которой, как ожидается, оно сможет достигнуть места назначения, возможно, с сохранением в локальном буфере. Если получатель в момент прихода сообщения на принимающий хост этого получателя неактивен, передача обрывается. Другой пример нерезидентной асинхронной связи — асинхронный вызов RPC. Нерезидентная синхронная связь существует в различных вариантах. В наиболее слабой форме, основанной на подтверждениях приема сообщений, отправитель блокируется до тех пор, пока сообщение не окажется в локальном буфере принимающего хоста. После получения подтверждения отправитель продолжает свою работу. В ориентированной на доставку нерезидентной синхронной связи отправитель блокируется до тех пор, пока сообщение не будет доставлено получателю для дальнейшей обработки. Мы рассматривали эту форму синхронного поведения при обсуждении асинхронных вызовов RPC. При асинхронных вызовах RPC клиент синхронизируется с сервером, ожидая, пока его запрос будет принят на дальнейшую обработку. Наиболее жесткая форма — ориентированная на ответ нерезидентная синхронная связь — предполагает блокировку отправителя до получения ответного сообщения с другой стороны, как в поведении запрос-ответ при взаимодействии клиент-сервер. Эта схема характерна также для механизмов RPC и RMI. Все сочетания сохранности и синхронности при взаимодействиях показаны на рис. 2.21. До недавнего времени множество распределенных систем поддерживали только ориентированную на ответ нерезидентную синхронную связь, реализованную через вызов удаленных процедур или через обращения к удаленным объектам. После того как стало ясно, что этот вид связи не всегда самый подходящий, были созданы средства для менее жестких форм нерезидентной синхронной связи, таких как асинхронные вызовы RPC или отложенные синхронные операции. В корне отличный подход применен в системах передачи сообщений, использующих как отправную точку нерезидентную асинхронную связь и в качестве дополнительной возможности содержащих средства синхронной связи. Однако во всех вариантах передачи сообщений взаимодействия также предполагаются прозрачными. Другими словами, задействуются только те средства связи, которые подходят для синхронных процессов. Ограничиваться исключительно этими средствами во многих случаях нереально, особенно если принять во внимание географическую масштабируемость. Рис. 2.21. Шесть видов связи: сохранная асинхронная связь (а), сохранная синхронная связь (б), нерезидентная асинхронная связь (в), нерезидентная синхронная связь с синхронизацией по приему (г), нерезидентная синхронная связь с синхронизацией по доставке (д) и нерезидентная синхронная связь с синхронизацией по ответу (е) Необходимость в службах сохранной связи стала очевидной, когда разработчикам программного обеспечения промежуточного уровня потребовалось интегрировать приложения в крупные и сильно разветвленные взаимосвязанные сети. Подобные сети часто разбросаны по различным подразделениям и административным зонам, части которых не всегда могут быть доступны немедленно. Например, доступ может быть ограничен по причине сбоев в сети или процессах. Для решения подобных проблем были разработаны частные решения на базе сохранной связи, но подобные решения, как легко понять, не вполне удовлетворяли требованиям переносимости и работоспособности в разных условиях. Другим недостатком нерезидентной связи можно считать тот факт, что в случае возникновения ошибки необходимо немедленно замаскировать ее и запустить процедуру восстановления. Невозможность отложить восстановление в данном случае означает нарушение прозрачности по отказам. В случае же сохранной связи приложение разрабатывается в расчете на длительные задержки между посылкой сообщения и получением ответа на него. Соответственно, мы можем прибегнуть к несложным, хотя возможно и медленным способам маскировки ошибок и восстановления. Должно быть понятно, что выбор исключительно между нерезидентным и сохранным типами связи во многих случаях неприемлем. Аналогично, только синхронный и асинхронный типы связи — это еще не все. В зависимости от задач распределенной системы ей могут потребоваться все возможные типы связи. Ранее мы говорили в основном о нерезидентной синхронной связи — RPC и RMI. Другие формы взаимодействия, как правило, представлены системами, работающими на основе передачи сообщений. Связь на основе потоков данных Модели взаимодействия, обсуждавшиеся выше, касались обмена более или менее независимыми, законченными порциями информации. Примерами таковых являются запросы и обращения к процедурам, ответы на подобные запросы и обмен сообщениями между приложениями в системах очередей сообщений. Характерной чертой подобного взаимодействия является его индифферентность к тому, в какой конкретно момент времени оно происходит. Несмотря на то, работает система очень быстро или очень медленно, это никак не сказывается на корректности ее работы. Однако существуют формы взаимодействия, в которых временные характеристики имеют решающее значение. Рассмотрим, например, поток аудиоданных, состоящий из последовательности 16-битных выборок, каждая из которых представляет собой амплитуду звуковой волны в импульсно-кодовой модуляции. Предположим также, что поток аудиоданных имеет качество компакт-дисков, а это значит, что исходный звук был оцифрован с частотой 44 100 Гц. Для воспроизведения звука необходимо, чтобы выборки аудиопотока проигрывались в том же порядке, в котором они представлены в потоке данных, и с интервалами, ровно по 1/44100 с. Воспроизведение с другой скоростью создаст неверное представление об исходном звуке. В этом разделе мы рассмотрим вопрос о том, какие средства могут предложить нам распределенные системы для работы с информацией, критичной к временным характеристикам передачи, такой как видео- и аудиопотоки. Поддержка непрерывных сред Поддержка обмена критичной к временным характеристикам передачи информации часто сводится к поддержке непрерывных сред. Под средой понимается то, что несет информацию. Сюда могут входить среды передачи и хранения, среда представления, например монитор, и т. д. Важнейшая характеристика среды — способ представления информации. Другими словами, как информация кодируется в компьютерной системе? Для различных типов информации используются различные представления. Так, текст обычно кодируется символами ASCII или Unicode. Изображения могут быть представлены в различных форматах, например GIF или JPEG. Аудиопотоки в компьютерных системах могут кодироваться, например, с помощью 16-битных выборок, использующих импульсно-кодовую модуляцию. В непрерывной среде представления (continuous representation media) временные соотношения между различными элементами данных лежат в основе корректной интерпретации смысла данных. Мы уже давали пример получения звука при воспроизведении аудиопотока. В качестве другого примера рассмотрим представление движения. Движение может быть представлено в виде серии картинок, причем последовательно идущие картинки должны воспроизводиться в течение одинакового срока T, обычно составляющего 30–40 мс на картинку. Правильное воспроизведение требует не только показа картинок в нужной последовательности, но и поддержания постоянной частоты показа — 1/T картинок в секунду. В отличие от непрерывной среды дискретная среда представления (discrete representation media), характеризуется тем, что временные соотношения между элементами данных не играют фундаментальной роли в правильной интерпретации данных. Типичными примерами дискретной среды являются представления текста и статических изображений, а также объектный код и исполняемые файлы. Поток данных Для обмена критичной ко времени передачи информацией распределенные системы обычно предоставляют поддержку потоков данных (data streams, или просто streams). Поток данных есть не что иное, как последовательность элементов данных. Потоки данных применимы как для дискретной, так и для непрерывной среды представления. Так, каналы UNIX или соединения TCP/IP представляют собой типичные примеры дискретных потоков данных (байт-ориентированных). Воспроизведение звукового файла обычно требует непрерывного потока данных между файлом и устройством воспроизведения. Временные характеристики важны для непрерывных потоков данных. Для поддержания временных характеристик часто приходится выбирать между различными режимами передачи. В асинхронном режиме передачи (asynchronous transmission mode) элементы данных передаются в поток один за другим, но на их дальнейшую передачу никаких ограничений в части временных характеристик не вводится. Это традиционный вариант для дискретных потоков данных. Так, файл можно преобразовать в поток данных, но выяснять точный момент окончания передачи каждого элемента данных чаще всего бессмысленно. В синхронном режиме передачи (synchronous transmission mode) для каждого элемента в потоке данных определяется максимальная задержка сквозной передачи. Если элемент данных был передан значительно быстрее максимально допустимой задержки, это не важно. Так, например, датчик может с определенной частотой измерять температуру и пересылать эти измерения по сети оператору. В этом случае временные характеристики могут вызвать наш интерес, если время сквозного прохождения сигнала по сети гарантированно ниже, чем интервал между измерениями, но никому не повредит, если измерения будут передаваться значительно быстрее, чем это действительно необходимо. И, наконец, при изохронном режиме передачи (isochronous transmission mode) необходимо, чтобы все элементы данных передавались вовремя. Это означает, что передача данных ограничена максимально, а также минимально допустимыми задержками, также известными под названием предельного дрожания. Изохронный режим передачи, в частности, представляет интерес для распределенных систем мультимедиа, поскольку играет значительную роль в воспроизведении аудио- и видеоинформации. Далее мы коснемся только непрерывных потоков данных. Рис. 2.29. Передача потока данных по сети между двумя процессами (а), между двумя устройствами (б) Потоки данных могут быть простыми или комплексными. Простой поток данных (simple stream) содержит только одну последовательность данных. Комплексный поток данных (complex stream) состоит из нескольких связанных простых потоков, именуемых вложенными потоками данных (substreams). Взаимодействие между вложенными потоками в комплексном потоке часто также зависит от времени. Так, например, стереозвук может передаваться посредством комплексного потока, содержащего два вложенных потока, каждый из которых используется для одного аудиоканала. Важно отметить, что эти два вложенных потока постоянно синхронизированы. Другими словами, элементы данных каждого из потоков должны передаваться попарно для получения стереоэффекта. Другим примером комплексного потока данных может быть поток данных для фильма. Такой поток мог бы состоять из одного видеопотока и двух аудиопотоков для передачи стереофонической звуковой дорожки к фильму. Четвертый поток мог бы содержать субтитры для глухих или синхронный перевод на другой, нежели в звуковой дорожке, язык. И вновь необходима синхронизация вложенных потоков. При нарушениях синхронизации нарушается нормальное воспроизведение фильма. Поток данных нередко может рассматриваться в виде виртуального соединения между источником и приемником. Источник или приемник может быть процессом или устройством. Например, при передаче данных через сеть процесс-источник может читать данные из аудиофайла и пересылать их, байт за байтом, по сети. Приемник может быть процессом, по мере поступления выбирающим байты и передающим их на локальное устройство звуковоспроизведения. Такую ситуацию иллюстрирует рис. 2.29, а, С другой стороны, в распределенных мультимедийных системах можно реализовать прямое соединение между источником и приемником. Так, видеопоток, создаваемый камерой, может напрямую передаваться на дисплей, как показано на рис. 2.29, б. Другая ситуация имеет место в зависР1мости от того, имеется у нас всего один источник или приемник или мы можем организовать многостороннюю связь. Наиболее частая ситуация при многосторонней связи — присоединение к потоку данных нескольких приемников. Другими словами, осуществляется групповая рассылка потока данных нескольким получателям, как показано на рис. 2.30. Рис. 2.30. Пример групповой рассылки потока данных нескольким получателям Главной проблемой групповой рассылки потоков данных являются разные требования разных приемников к качеству потока. Рассмотрим, например, источник передачи высококачественного кино со стереозвуком. Он может потребовать комплексного потока данных, содержащего вложенный поток для видео, по которому с частотой 50 Гц передается картинка, и два вложенных потока для аудио с качеством на уровне компакт-дисков. Даже при использовании современных технологий сжатия комплексный поток может потребовать скорости передачи порядка 30×106 бит/с. Не всякий приемник в состоянии обработать такой объем данных. Поэтому поток должен быть настроен на фильтрацию, которая приводит в соответствие качество входящего потока и отличное от него качество исходящего потока, как показано на рис. 2.30. Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №15-16 Оценка технических параметров ИС и ее компонент Общая постановка задачи Качество ИС связано с дефектами, заложенными на этапе проектирования и проявляющимися в процессе эксплуатации. Свойства ИС, в том числе и дефектологические, могут проявляться лишь во взаимодействии с внешней средой, включающей технические средства, персонал, информационное и программное окружение. В зависимости от целей исследования и этапов жизненного цикла ИС дефектологические свойства разделяют на дефектогенность, дефектабельность и дефектоскопичность. Дефектогенность определяется влиянием следующих факторов: - численностью разработчиков ИС, их профессиональными психофизиологическими характеристиками; - условиями и организацией процесса разработки ИС; - характеристиками инструментальных средств и комплексов ИС; - сложностью задач, решаемых ИС; - степенью агрессивности внешней среды (потенциальной возможностью внешней среды вносить преднамеренные дефекты, например, воздействие вирусов). Дефектабельность характеризует наличие дефектов ИС и определяется их количеством и местонахождением. Другими факторами, влияющими на дефектабельность, являются: - структурно-конструктивные особенности ИС; - интенсивность и характеристики ошибок, приводящих к дефектам. Дефектоскопичность характеризует возможность проявления дефектов в виде отказов и сбоев в процессе отладки, испытаний или эксплуатации. На дефектоскопичность влияют: - количество, типы и характер распределения дефектов; - устойчивость ИС к проявлению дефектов; - характеристики средств контроля и диагностики дефектов; - квалификация обслуживающего персонала. Оценка качества ИС — задача крайне сложная из-за многообразия интересов пользователей. Поэтому невозможно предложить одну универсальную меру качества и приходится использовать ряд характеристик, охватывающих весь спектр предъявляемых требований. Наиболее близки к задачам оценки качества ИС модели качества программного обеспечения, являющегося одним из важных составных частей ИС. В настоящее время используется несколько абстрактных моделей качества программного обеспечения, основанных на определениях характеристики качества, показателя качества, критерия и метрики. Критерий может быть определен как независимый атрибут ИС или процесса ее создания. С помощью такого критерия может быть измерена характеристика качества ИС на основе той или иной метрики. Совокупность нескольких критериев определяет показатель качества, формируемый исходя из требований, предъявляемых к ИС. В настоящее время наибольшее распространение получила иерархическая модель взаимосвязи компонентов качества ИС. Вначале определяются характеристики качества, в числе которых могут быть, например: - общая полезность; - исходная полезность; - удобство эксплуатации. Далее формируются показатели, к числу которых могут быть отнесены: - практичность; - целостность; - корректность; - удобство обслуживания; - оцениваемость; - гибкость; - адаптируемость; - мобильность; - возможность взаимодействия. Каждому показателю качества ставится в соответствие группа критериев. Для указанных показателей приведем возможные критерии. Надо отметить, что один и тот же критерий может характеризовать несколько показателей: - практичность — работоспособность, возможность обучения, коммуникативность, объем ввода, скорость ввода-вывода; - целостность — регулирование доступа, контроль доступа; - эффективность — эффективность использования памяти, эффективность функционирования; - корректность — трассируемость, завершенность, согласованность; - надежность — точность, устойчивость к ошибкам, согласованность, простоту; - удобство обслуживания — согласованность, простоту, краткость, информативность, модульность; - оцениваемость — простоту, наличие измерительных средств, информативность, модульность; - гибкость — распространяемость, общность, информативность, модульность; - адаптируемость — общность, информативность, модульность, аппаратную независимость, программную независимость; - мобильность — информативность, модульность, аппаратную независимость, программную независимость; - возможность взаимодействия — модульность, унифицируемость процедур связи, унифицируемость данных. С помощью метрик можно дать количественную или качественную оценку качества ИС. Различают следующие виды метрических шкал для измерения критериев. Первый тип — метрики, которые используют интервальную шкалу, характеризуемую относительными величинами реально измеряемых физических показателей, например, временем наработки на отказ, вероятностью ошибки, объемом информации и других. Второй тип — метрики, которым соответствует порядковая шкала, позволяющая ранжировать характеристики путем сравнения с опорными значениями. Третий тип — метрики, которым соответствуют номинальная, или категорированная шкала, определяющая наличие рассматриваемого свойства или признака у рассматриваемого объекта без учета градаций по этому признаку. Развитием иерархического подхода является представленная на рис. 12.1 модель классификации критериев качества информационных систем. С помощью функциональных критериев оценивается степень выполнения ИС основных целей или задач. Конструктивные критерии предназначены для оценки компонент ИС, не зависящих от целевого назначения. Рис. 12.1. Модель классификации критериев качества информационных систем Одним из путей обеспечения качества ИС является сертификация. В США Радиотехническая комиссия по аэронавтике в своем руководящем документе определяет процесс сертификации следующим образом: «Сертификация — процесс официально выполняемой функции системы ... путем удостоверения, что функция ... удовлетворяет требованиям заказчика, а также государственным нормативным документам». В настоящее время не существует стандартов, полностью удовлетворяющих оценке качества ИС. В западноевропейских странах имеется ряд стандартов, определяющих основы сертификации программных систем. Стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран-членов НАТО (AQAP1). Существующая в нашей стране система нормативно-технических документов относит программное обеспечение к «продукции производственно-технического назначения», которая рассматривается как материальный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (например, ГОСТ 28195-89 «Оценка качества программных средств. Общие положения») явно устарели и являются неполными. Стандарты управления качеством промышленной продукции Международные стандарты серии ISO 9000 разработаны для управления качеством продукции, их дополняют стандарты серии ISO 14000, отражающие экологические требования к производству промышленной продукции. Хотя эти стандарты непосредственно не связаны с CALS-стандартами, их цели — совершенствование промышленного производства, повышение его эффективности — совпадают. Очевидно, что управление качеством тесно связано с его контролем. Контроль качества традиционно основан на измерении показателей качества продукции на специальных технологических операциях контроля и выбраковке негодных изделий. Однако есть и другой подход к управлению качеством, который основан на контроле качественных показателей не самих изделий, а проектных процедур и технологических процессов, используемых при создании этих изделий. Такой подход во многих случаях более эффективен. Он требует меньше затрат, поскольку позволяет обойтись без стопроцентного контроля продукции и благодаря предупреждению появления брака снижает производственные издержки. Именно этот подход положен в основу стандартов ISO 9000, принятых ISO в 1987 г. и проходящих корректировку приблизительно каждые пять лет. Таким образом, методической основой для управления качеством являются международные стандарты серии ISO 9000. Они определяют и регламентируют инвариантные вопросы создания, развития, применения и сертификации систем качества в промышленности. В них устанавливается форма требований к системе качества в целях демонстрации поставщиком своих возможностей и оценки этих возможностей внешними сторонами. Основной причиной появления стандартов ISO 9000 была потребность в общем для всех участников международного рынка базисе для контроля и управления качеством товаров. Американское общество контроля качества определило цели ISO 9000 как помощь в развитии международного обмена товарами и услугами и кооперации в сфере интеллектуальной, научной, технологической и деловой активности. В стандартах ISO 9000 используется определение качества из стандарта ISO 8402: «Качество — совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности». Аналогичное определение содержится в ГОСТ 15467-79: «Качество продукции — это совокупность свойств продукции, обусловливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением». В ISO 9000 вводится понятие системы качества (QS — Quality System), под которой понимают документальную систему с руководствами и описаниями процедур достижения качества. Другими словами, система качества есть совокупность организационной структуры, ответственности, процедур, процессов и ресурсов, обеспечивающая осуществление общего руководства качеством. Система качества обычно представляет собой совокупность трех слоев документов: - описание политики управления для каждого системного элемента; - описание процедур управления качеством (что, где, кем и когда должно быть сделано); - тесты, планы, инструкции и т. п. Сертификация предприятий по стандартам ISO 9001–9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества — одно из важных условий для успеха коммерческой деятельности предприятий. Вторичные стандарты включают в себя: - ISO 9000 — основные понятия, руководство по применению ISO 9001; - ISO 9004 — элементы систем управления качеством. Поддерживающие стандарты предназначены для развития и установки систем качества: - ISO 10011 — аудит, критерии для аудита систем качества ; - ISO 10012 — требования для измерительного оборудования; - ISO 10013 — пособие для развития руководств по управлению качеством. Часть этих стандартов утверждена как государственные стандарты Российской Федерации. В частности, к ним относятся: ГОСТ Р ИСО 9001-96 «Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании»; ГОСТ Р ИСО 9002-96 «Системы качества. Модель обеспечения качества при производстве, монтаже и обслуживании»; ГОСТ Р ИСО 9003-96 «Системы качества. Модель обеспечения качества при окончательном контроле и испытаниях». В настоящее время разработана новая версия стандартов серии ISO 9000 под названием ISO 9000:2000 Quality management systems (системы управления качеством), в которую включены следующие документы: ISO 9000:2000 Fundamentals and vocabulary (основы и терминология); ISO 9001:2000 Requirements (требования); ISO 9004:2000 Guidelines for performance improvement (руководство по развитию). Главное отличие новой версии от предыдущей состоит в том, что она обусловлена стремлением упростить практическое использование стандартов, направлена на их лучшую гармонизацию и заключаются в следующем. В стандарте ISO 9001 минимизируется объем требований к системе качества. Стандарты ISO 9002–9003 из новой версии исключаются. Расширяется круг контролируемых ресурсов, в их число включены такие элементы, как информация, коммуникации, инфраструктура. Введенные в стандарте ISO 9004 двадцать элементов качества сворачиваются в четыре группы: - распределение ответственности (management responsibility); - управление ресурсами (resource management); - реализация продукции и услуг (product and/or service realization); - измерения и анализ (measurement, analysis, and improvement). Сертификация предприятий по стандартам ISO 9001–9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества — одно из важных условий для успеха коммерческой деятельности предприятий. Стандарты ISO 14000 являются также системой управления влиянием на окружающую среду; они, как и ISO 9000, реализуются в процессе сертификации предприятий, задают процедуры управления и контроль документации, аудит, подразумевают соответствующее обучение и сбор статистики. Кроме требований заказчиков и покупателей, в них воплощаются внутренние требования организации. Библиографический список 1. М. В. Головицына Методология автоматизации работ технологической подготовки производства http://www.intuit.ru/department/hardware/autpri/ Лекция №17-18 Отказоустойчивость Характерной чертой распределенных систем, которая отличает их от единичных машин, является возможность частичного отказа. Частичный отказ происходит при сбое в одном из компонентов распределенной системы. Этот отказ может нарушить нормальную работу некоторых компонентов, в то время как другие компоненты это никак не затронет. В противоположность отказу в распределенной системе отказ в нераспределенной системе всегда является глобальным, в том смысле, что он затрагивает все ее компоненты и легко может привести к неработоспособности всего приложения. При создании распределенной системы очень важно добиться, чтобы она могла автоматически восстанавливаться после частичных отказов, незначительно снижая при этом общую производительность. В частности, когда бы ни случился отказ, распределенная система в процессе восстановления должна продолжать работать приемлемым образом, то есть быть устойчивой к отказам, сохраняя в случае отказов определенную степень функциональности. Далее мы познакомимся со способами обеспечения отказоустойчивости распределенной системы, ограничившись изложением определенных базовых сведений об отказоустойчивости. Под отказоустойчивостью процессов мы понимаем методы, при помощи которых отказ одного или более процессов проходит для остальной части системы почти незаметно. С этим вопросом связана проблема надежной групповой рассылки, при которой передача сообщений набору процессов производится с гарантией доставки. Надежная групповая рассылка часто необходима для поддержания синхронности процессов. Атомарность — это свойство, важное для многих приложений. Так, например, в распределенных транзакциях необходимо гарантировать, что все операции, входящие в транзакцию, либо происходят, либо нет. Фундаментальным для атомарности в распределенных системах является понятие распределенных протоколов подтверждения. И, наконец, важным вопросом является то, как восстанавливать систему после отказов. В частности, когда и как следует сохранять состояние распределенной системы на тот случай, если позже это состояние потребуется восстанавливать. Исследованию отказоустойчивости посвящено большое количество трудов. Этот раздел мы посвятим рассмотрению базовых концепций обработки отказов, а далее обсудим модели отказов. Основа всех методик ликвидации последствий отказов — избыточность, о ней мы тоже поговорим. Основные концепции Чтобы понять роль отказоустойчивости в распределенных системах, сначала необходимо выяснить, что для распределенных систем означает «быть отказоустойчивыми». Отказоустойчивость тесно связана с понятием надежных систем (dependable systems). Надежность — это термин, охватывающий множество важных требований к распределенным системам, включая: - доступность (availability); - безотказность (reliability); - безопасность (safety); - ремонтопригодность (maintainability). Доступность — это свойство системы находиться в состоянии готовности к работе. Обычно доступность показывает вероятность того, что система в данный момент времени будет правильно работать и окажется в состоянии выполнить свои функции, если пользователи того потребуют. Другими словами, система с высокой степенью доступности — это такая система, которая в произвольный момент времени, скорее всего, находится в работоспособном состоянии. Под безотказностью имеется в виду свойство системы работать без отказов в течение продолжительного времени. В противоположность доступности безотказность определяется в понятиях временного интервала, а не момента времени. Система с высокой безотказностью — это система, которая, скорее всего, будет непрерывно работать в течение относительно долгого времени. Между безотказностью и доступностью имеется небольшая, но существенная разница. Если система отказывает на одну миллисекунду каждый час, она имеет доступность порядка 99,9999 %, но крайне низкую безотказность. С другой стороны, система, которая никогда не отказывает, но каждый август отключается на две недели, имеет высокую безотказность, но ее доступность составляет всего 96 %. Эти две характеристики — не одно и то же. Безопасность определяет, насколько катастрофична ситуация временной неспособности системы должным образом выполнять свою работу. Так, многие системы управления процессами, используемые, например, на атомных электростанциях или космических кораблях, должны обладать высокой степенью безопасности. Если эти управляющие системы даже временно, на короткий срок, перестанут работать, результат может быть ужасен. Множество примеров происходивших в прошлом событий показывают, как тяжело построить безопасную систему (и может быть еще больше таких примеров ожидают нас в будущем). И, наконец, ремонтопригодность определяет, насколько сложно исправить неполадки в описываемой системе. Системы с высокой ремонтопригодностью могут также обладать высокой степенью доступности, особенно при наличии средств автоматического обнаружения и исправления неполадок. Однако, как мы увидим позже, говорить об автоматическом исправлении неполадок гораздо проще, чем создавать способные на это системы. Часто надежные системы требуют также повышенного уровня защиты, особенно когда дело доходит до такого вопроса, как непротиворечивость. Мы поговорим о защите в следующей главе. Говорят, что система отказывает (fail), если она не в состоянии выполнять свою работу. В частности, если распределенная система создавалась для предоставления пользователям некоторых услуг, то система будет считаться находящейся в состоянии отказа в том случае, если она не сможет предоставлять все или некоторые услуги. Ошибкой (error) называется такое состояние системы, которое может привести к ее неработоспособности. Так, например, при передаче пакетов по сети может случиться, что некоторые пакеты, пришедшие к получателю, окажутся поврежденными. Повреждения в данном случае будут означать, что получатель может неверно прочесть значения битов (например, 1 вместо 0) или оказаться не в состоянии определить сам факт прихода пакета. Причиной ошибки является отказ (fault). Понятно, что найти причину ошибки очень важно. Так, например, вызвать повреждение пакетов вполне может неисправная или некачественная среда передачи. В этом случае устранить отказ относительно легко. Однако ошибки передачи в беспроводных сетях могут быть вызваны, например, плохой погодой. Изменение погоды с целью предупредить возникновение ошибок нам пока не под силу. Построение надежных систем тесно связано с управлением отказами. Управление в данном случае означает нечто среднее между предотвращением, исправлением и предсказанием отказов. Для нашей цели наиболее важным вопросом является отказоустойчивость (fault tolerance), под которой мы будем понимать способность системы предоставлять услуги даже при наличии отказов. Отказы обычно подразделяются на проходные, перемежающиеся и постоянные. Проходные отказы (transient faults) происходят однократно и больше не повторяются. Если повторить операцию, они не возникают. Птица, пролетевшая через луч микроволнового передатчика, в некоторых сетях может привести к потере битов. Если передатчик, выждав положенную паузу, повторит отправку, то по всей вероятности передача пройдет как положено. Перемежающиеся отказы (intermittent faults) появляются и пропадают, «когда захотят», а потом появляются снова и т. д. Перемежающиеся отказы нередко бывают вызваны потерей контакта в разъеме. Из-за трудностей в диагностике перемежающиеся отказы часто вызывают сильное раздражение. Обычно когда приходит ремонтник, система работает просто прекрасно. Постоянные отказы (permanent faults) — это отказы, которые продолжают свое существование до тех пор, пока отказавший компонент не будет заменен. Примерами постоянных отказов могут быть сгоревшие микросхемы, ошибки в программном обеспечении или сместившиеся головки дисков. Модели отказов Отказавшая система не в состоянии корректно выполнять ту работу, для которой она была создана. Если рассматривать распределенную систему как набор серверов, взаимодействующих друг с другом и с клиентами, то некорректное выполнение работы будет означать, что серверы или коммуникационные каналы, а возможно и оба этих компонента, не в состоянии делать то, для чего они, как предполагалось, предназначены. Однако сами по себе нефункционирующие серверы не всегда приводят к отказу системы, как мы его понимаем. Если сервер для корректной работы нуждается в услугах других серверов, причину ошибки, может быть, следует искать в другом месте. Таких зависимостей в распределенных системах великое множество. Отказавший диск осложняет работу файлового сервера, который разрабатывался для реализации файловой системы с высокой степенью доступности. Если этот файловый сервер является частью распределенной базы данных, под угрозой находится работа всей базы, поскольку доступной оказывается только часть данных. Чтобы лучше понимать, насколько серьезен на самом деле конкретный отказ, были разработаны различные схемы классификации. Одна из таких схем, приведена в табл. 7.1. Таблица 7.1. Различные типы отказов Тип отказа Описание Поломка Пропуск данных Пропуск приема Пропуск передачи Ошибка синхронизации Ошибка отклика Ошибка значения Ошибка передачи состояния Произвольная ошибка Сервер перестал работать, хотя до момента отказа работал правильно Сервер неправильно реагирует на входящие запросы Сервер неправильно принимает входящие запросы Сервер неправильно отправляет сообщения Реакция сервера происходит не в определенный интервал времени Отклик сервера неверен Сервер возвращает неправильное значение Сервер отклоняется от верного потока управления Сервер отправляет случайные сообщения в случайные моменты времени Поломка (crash failure) имеет место при внезапной остановке сервера, при этом до момента остановки он работает нормально. Важная особенность поломки состоит в том, что после остановки сервера никаких признаков его работы не наблюдается. Типичный пример поломки — полное зависание операционной системы, когда единственным решением проблемы является перезагрузка. Многие операционные системы персональных компьютеров претерпевают поломки настолько часто, что люди уже начинают полагать, что для них это обычное дело. В этом смысле перенос кнопки Reset с задней части корпуса компьютера на переднюю панель был, несомненно, оправдан. Пропуск данных (omission failure) возникает в том случае, когда сервер неправильно реагирует на запросы. Эту ошибку могут вызывать различные причины. В случае пропуска приема (receive omission) сервер может, например, не получать запросов. Отметим, что такая ошибка может произойти, в частности, и в том случае, когда соединение между клиентом и сервером установлено совершенно правильным образом, но на сервере не запущен процесс для приема приходящих запросов. Пропуск приема обычно не влияет на текущее состояние сервера, но сервер остается в неведении о посланных ему сообщениях. Похожая ошибка — пропуск передачи (send omission) — происходит, когда сервер выполняет свою работу, но по каким-либо причинам не в состоянии послать ответ. Подобная ошибка может произойти, например, при переполнении буфера передачи, если сервер не готов к подобной ситуации. Отметим, что в противоположность пропуску приема в данном случае сервер может перейти в состояние, соответствующее полному выполнению услуги для клиента. Впоследствии, если обнаружится, что имел место пропуск передачи, сервер, вероятно, должен быть готов к тому, что клиент повторно пошлет свой последний запрос. Другие типы пропусков не имеют отношения к взаимодействию и могут быть вызваны ошибками в программе, такими как бесконечные циклы или некорректная работа с памятью, которые способны «подвесить» сервер. Следующий класс ошибок связан с синхронизацией. Ошибки синхронизации (timing failures) возникают при ожидании ответа дольше определенного временного интервала. Как мы говорили во время обсуждения изохронных потоков данных, слишком раннее предоставление данных легко может вызвать у принимающей стороны проблемы, связанные с отсутствием места в буфере для хранения получаемых данных. Чаще, однако, сервер отвечает слишком поздно, в этом случае говорят, что произошла ошибка производительности (performance failure). Еще один важный тип ошибок — ошибки отклика (response failures), при которых ответы сервера просто неверны. Существует два типа ошибок отклика. В случае ошибки значения (value failure) сервер дает неверный ответ на запрос. Так, например, эту ошибку демонстрирует поисковая машина, систематически возвращающая адреса web-страниц, не связанных с запросом пользователя. Другой тип ошибок отклика — ошибки передачи состояния (state transition failures). Этот тип ошибок характеризуется реакцией на запрос, не соответствующей ожиданиям. Так, например, если сервер получает сообщение, которое он не в состоянии распознать, и никаких мер по обработке подобных сообщений не предусмотрено, возникает ошибка передачи состояния. В частности, сервер может неправомерно осуществить по умолчанию некие действия, производить которые в данном случае не следовало бы. Весьма серьезны произвольные ошибки (arbitrary failures), известные также под названием византийских ошибок (Byzantine failures). Когда случается произвольная ошибка, клиент должен приготовиться к самому худшему. Например, может оказаться, что сервер генерирует сообщения, которые он в принципе не должен генерировать, но система не опознает их как некорректные. Хуже того, неправильно функционирующий сервер может, участвуя в работе группы серверов, приводить к появлению заведомо неверных ответов. Эта ситуация показывает, почему для надежных систем очень важна защита. Термин «византийские» восходит к Византийской империи (Балканы и современная Турция) времен 330-1453 годов, когда бесконечные заговоры, интриги и ложь считались в правящих кругах обычным делом. Ниже мы вернемся к разговору об ошибках такого рода. Произвольные ошибки похожи на поломки. Поломка — наиболее распространенная причина остановки сервера. Поломки известны также под названием ошибок аварийной остановки (fail-stop failures). В действительности аварийно остановленный сервер просто прекращает генерировать исходящие сообщения. По этому признаку его остановка обнаруживается другими процессами. Например, по настоящему дружественный сервер может предупредить нас о том, что находится на грани поломки. Разумеется, в реальной жизни серверы, останавливаясь по причине пропуска данных или поломок, не настолько дружественны, чтобы оповестить нас о надвигающейся остановке. Другие процессы должны сами обнаружить «безвременную кончину» сервера. Однако в подобных системах остановки без уведомления (fail-silent systems) другие процессы могут сделать неверный вывод об остановке сервера. Сервер может просто медленно работать, то есть может иметь место ошибка производительности. И, наконец, возможно, что сервер производит случайные сообщения, которые другие процессы считают абсолютным мусором. В этом случае мы имеем дело с наиболее простым случаем произвольной ошибки. Подобные ошибки называют безопасными (fail-safe). Маскирование ошибок при помощи избыточности Если система считается отказоустойчивой, она должна пытаться маскировать факты ошибок от других процессов. Основной метод маскирования ошибок — использование избыточности (redundancy). Возможно применение трех типов избыточности — информационной избыточности, временной избыточности и физической избыточности. В случае информационной избыточности к сообщению добавляются дополнительные биты, по которым можно произвести исправление сбойных битов. Так, например, можно добавить к передаваемым данным код Хемминга для восстановления сигнала в случае зашумленного канала передачи. При временной избыточности уже выполненное действие при необходимости осуществляется еще раз. В качестве примера к этому способу рассмотрим транзакции. Если транзакция была прервана, ее можно без каких-либо опасений повторить. Временная избыточность особенно полезна, если мы имеем дело с проходным или перемежающимся отказом. В случае физической избыточности мы добавляем в систему дополнительное оборудование или процессы, которые делают возможной работу системы при утрате или неработоспособности некоторых компонентов. Физическая избыточность, таким образом, может быть как аппаратной, так и программной. Так, например, можно добавить к системе дополнительные процессы, так что при крахе некоторых из них система продолжит функционировать правильно. Другими словами, посредством репликации достигается высокая степень отказоустойчивости. Ниже мы вернемся к этому типу программной избыточности. Физическая избыточность — это широко распространенный способ добиться отказоустойчивости. Она используется в биологии (млекопитающие имеют по два глаза, по два уха, по два легких и т. д.), самолетостроении (у Боинга-747 четыре двигателя, но он может лететь и на трех) и спорте (несколько судей на тот случай, если один чего-нибудь не заметит). Она также много лет используется для обеспечения отказоустойчивости в радиосхемах. Рассмотрим, например, схему, показанную на рис. 7.1, а. На ней сигнал проходит последовательно через устройства А, В и С. Если одно из них неисправно, результат, вероятно, будет неверен. Рис. 7 . 1 . Тройное модульное резервирование На рис. 7.1, б каждое из устройств присутствует в трех экземплярах. Переход к следующему участку схемы определяется тройным голосованием. Устройство голосования — это схема с тремя входами и одним выходом. Если два или три входных сигнала совпадают, выходной сигнал равен входному. Если все три входных сигнала различны, выходной сигнал не определен. Такая схема известна под названием тройного модульного резервирования (Triple Modular Redundancy, TMR). Допустим, элемент А2 отказал. Каждое из устройств голосования, V1, V2 и V3, получает два правильных (идентичных) входных сигнала и один неправильный, и каждое из них передает на второй участок цепи правильное значение. В результате эффект отказа А2 оказывается полностью замаскированным, а значит, входные сигналы элементов В1, В2 и В3 абсолютно такие же, как если бы никакого отказа не было. Рассмотрим теперь, что будет, если в придачу к А2 откажут также элементы В3 и С1. Эффект их отказа также будет замаскирован, и все три выходных сигнала окажутся правильными. Прежде всего, непонятно, зачем на каждом этапе нужно использовать три устройства голосования. Вообще-то определить и донести до нас мнение большинства может и одно устройство голосования. Однако устройство голосования — это тоже компонент, который тоже может отказать. Рассмотрим, например, отказ V1 Входящий сигнал В1 в этом случае будет неверным, но до тех пор, пока все остальное работает, В2 и ВЗ будут давать одинаковые выходные сигналы, и устройства V4, V5 и V6 образуют правильный результат для третьего этапа. Отказ V1 практически ничем не будет отличаться от отказа В1. В обоих случаях выходной сигнал от В1 будет неверным, и в любом случае при голосовании он окажется в меньшинстве. Хотя не все отказоустойчивые распределенные системы используют TMR, эта технология является очень распространенной и помогает яснее понять, что такое отказоустойчивая система и чем она отличается от системы, составленной из высоконадежных компонентов, но не обладающей отказоустойчивой структурой. Разумеется, TMR можно применять и рекурсивно. Например, можно повышать надежность микросхем, встраивая в них механизмы TMR. Для разработчиков, использующих микросхемы, это останется неизвестным. Библиографический список 2. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №19-20 Жизненный цикл информационных систем Под жизненным циклом системы обычно понимается непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент ее полного изъятия из эксплуатации. Современные сети разрабатываются на основе стандартов, что позволяет обеспечить, во-первых, их высокую эффективность и, во-вторых, возможность их взаимодействия между собой. Вообще говоря, все стандарты на информационные системы (как и на любые системы вообще) можно разбить на следующие два основных класса: - Функциональные стандарты, определяющие порядок функционирования системы в интересах достижения цели, поставленной перед нею ее создателями. - Стандарты жизненного цикла, определяющие то, как создается, развертывается, применяется и ликвидируется система. Модели, определяемые стандартами этих двух классов, конечно же взаимосвязаны, однако решают совершенно разные задачи и характеризуются принципиально различными подходами к их построению. Поясним это на примере. Наиболее полной функциональной моделью системы является сама система, однако «биография» самой системы ни в коем случае не может рассматриваться в качестве модели ее жизненного цикла. Куда ближе к модели жизненного цикла информационной системы является описание жизни живого существа, начиная с момента зачатия. Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее создания, сопровождения и развития:  предпроектный анализ (включая формирование функциональной и информационной моделей объекта, для которого предназначена информационная система);  проектирование системы (включая разработку технического задания, эскизного и технического проектов);  разработку системы (в том числе программирование и тестирование прикладных программ на основании проектных спецификаций подсистем, выделенных на стадии проектирования);  интеграцию и сборку системы, проведение ее испытаний;  эксплуатацию системы и ее сопровождение;  развитие системы. Продолжительность жизненного цикла современных информационных систем составляет около 10 лет, что значительно превышает сроки морального и физического старения технических и системных программных средств, используемых при построении системы. Поэтому в течение жизненного цикла системы проводится модернизация ее технико-программной базы. При этом прикладное программное обеспечение системы должно быть сохранено и перенесено на обновляемые аппаратно-программные платформы. Эти проблемы привели к тому, что подавляющее большинство проектов информационных систем внедряется с нарушениями качества, сроков или сметы. Почти треть проектов информационных систем прекращают свое существование, оставшись незавершенными. По данным, публикуемым Standish Group, в 1996 году 84% проектов информационных систем не были завершены в установленные сроки, в 1998 году сократилась до 74%, однако и в 2000-м общий объем «хронической незавершенки» не опустился ниже 50%. Главной причиной такого положения является то, что уровень технологии анализа и проектирования систем, методов и средств управления проектами не соответствует сложности создаваемых систем, которая постоянно возрастает в связи с усложнением и быстрыми изменениями бизнеса. Из мировой практики известно, что затраты на сопровождение прикладного программного обеспечения информационных систем составляют не менее 70% его совокупной стоимости на протяжении жизненного цикла. Поэтому крайне важно еще на проектной стадии предусмотреть необходимые методы и средства сопровождения прикладного программного обеспечения, включая методы конфигурационного управления. В России создание и испытания автоматизированных систем, к которым относятся и информационные системы, регламентированы рядом ГОСТов, прежде всего серии 34. Однако отдельные положения этих ГОСТов уже устарели, а ряд этапов жизненного цикла информационных систем предоставлены недостаточно полно. Поэтому более целесообразно рассматривать в качестве определяющего документа международный стандарт ISO/IEC 12207. Данный стандарт определяет структуру жизненного цикла, содержащую процессы, которые должны быть выполнены во время создания программного обеспечения информационной системы. Эти процессы подразделяются на три группы: основные (приобретение, поставка, разработка, эксплуатация и сопровождение), вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит и решение проблем) и организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение). Каскадная и спиральная модели Однако стандарт ISO/IEC 12207 не предлагает конкретной модели жизненного цикла и методов разработки, его рекомендации являются общими для любых моделей жизненного цикла. Под моделью обычно понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Из существующих в настоящее время моделей наиболее распространены две: каскадная и спиральная. Они принципиально различаются самим подходом к информационной системе и ее программному обеспечению. Суть различий в том, что в каскадной модели информационная система является однородной и ее программное обеспечение определяется как единое (с ней) целое. Данный подход характерен для более ранних информационных систем (каскадный метод применяется с 1970 года), а также для систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. При выполнении этих условий каскадный метод позволяет достичь хороших результатов. Суть каскадного метода (рис. 1) заключается в разбиении всей разработки на этапы, причем переход от предыдущего этапа к последующему осуществляется только после полного завершения работ предыдущего этапа. Соответственно на каждом этапе формируется законченный набор проектной документации, достаточной для того, чтобы разработка могла быть продолжена другой группой разработчиков. Другим положительным моментом каскадной модели является возможность планирования сроков завершения работ и затрат на их выполнение. Однако у каскадной модели есть один существенный недостаток — очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему и поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. Результатом такого конфликта стало появление модели с промежуточным контролем (рис. 2), которую представляют или как самостоятельную модель, или как вариант каскадной модели. Эта модель характеризуется межэтапными корректировками, удлиняющими период разработки изделия, но повышающими надежность. Однако и каскадная модель, и модель с промежуточным контролем обладают серьезным недостатком — запаздыванием с получением результатов. Данное обстоятельство объясняется тем, что согласование результатов возможно только после завершения каждого этапа работ. На время же проведения каждого этапа требования жестко задаются в виде технического задания. Так что существует опасность, что из-за неточного изложения требований или их изменения за длительное время создания программного обеспечения конечный продукт окажется невостребованным. Для преодоления этого недостатка и была создана спиральная модель, ориентированная на активную работу с пользователями и представляющая разрабатываемую информационную систему как постоянно корректируемую во время разработки. В спиральной модели (рис. 3) основной упор делается на этапы анализа и проектирования, на которых реализуемость технических решений проверяется путем создания прототипов. Спиральная модель позволяет начинать работу над следующим этапом, не дожидаясь завершения предыдущего. Спиральная модель имеет целью как можно раньше ознакомить пользователей с работоспособным продуктом, корректируя при необходимости требования к разрабатываемому продукту и каждый «виток» спирали означает создание фрагмента или версии. Основная проблема спирального цикла — определение момента перехода на следующий этап, и возможным ее решением является принудительное ограничение по времени для каждого из этапа жизненного цикла. Наиболее полно достоинства такой модели проявляются при обслуживании программных средств. Сравнивая эти модели, можно сказать, что каскадная модель более универсальна, т. е. она применима к производству разных изделий, будь то отбойный молоток или графический редактор. Для разных изделий просто будут изменяться количество и название этапов модели. Спиральная же модель более ориентирована именно на информационные системы, особенно на программные продукты, поэтому при разработке информационных систем и их программного обеспечения она предпочтительнее каскадной. Следующим шагом в вопросе поддержания жизненного цикла информационной системы, как, впрочем, и любого другого изделия, является его автоматизация. Однако автоматизация различных процессов, связанных с разработкой, производством и эксплуатацией как изделий промышленности, так и информационных систем наиболее эффективна в том случае, когда она охватывает все этапы жизненного цикла изделия. При этом необходимо преодоление следующих проблем: наличие множества различных систем, ориентированных на решение конкретных задач, относящихся к разным этапам жизненного цикла, приводит к трудностям обмена данными между смежными системами; участие в поддержке жизненного цикла изделия нескольких предприятий требует эффективного обмена информацией об изделии между партнерами; сложность изделия, наличие множества его модификаций, заимствование, стандартизация, унификация, требуют поддержки многоуровневых многовариантных сборочных моделей. Эти проблемы могут быть преодолены путем реализации концепции CALS. CALS Аббревиатура CALS расшифровывается как Continuous Acquisition and Life cycle Support — непрерывная информационная поддержка жизненного цикла продукта. Встречается также другой перевод, менее схожий с исходным названием, но более близкий по смыслу: обеспечение неразрывной связи между производством и прочими этапами жизненного цикла изделия. Данная технология, разработанная в 80-х годах в Министерстве обороны США, распространилась по всему миру и охватила практически все сферы мировой экономики. Она предназначена для повышения эффективности и качества бизнес-процессов, выполняемых на протяжении всего жизненного цикла продукта, за счет применения безбумажных технологий. Началом создания системы CALS-технологий явилась разработка системы стандартов описания процессов на всех этапах жизненного цикла продукции. В международных стандартах серии ISO 9004 (управление качеством продукции) введено понятие «жизненный цикл изделия». Данное понятие включает в себя следующие этапы жизненного цикла изделия: маркетинг, поиск и изучение рынка; проектирование и/или разработка технических требований к создаваемой продукции; материально-техническое снабжение; подготовка и разработка технологических процессов; производство; контроль, проведение испытаний и обследований; упаковка и хранение; реализация и/или распределение продукции; монтаж, эксплуатация; техническая помощь в обслуживании; утилизация после завершения использования продукции. Для развития методологии CALS в США были созданы Управляющая промышленная группа по вопросам CALS (ISG) и ее исполнительный консультативный комитет. В настоящий момент в мире действует более 25 национальных организаций (комитетов или советов по развитию CALS), в том числе в США, Японии, Канаде, Великобритании, Германии, Швеции, Норвегии, Австралии и других странах, а также в НАТО. Основные усилия этих и подобных организаций были направлены на создание разного уровня нормативной документации. За последние несколько лет разработаны следующие документы: ISO 10303 (Industrial automation systems and integration — Product data representation and exchange), ISO 13584 (Part Library), Def Stan 00-60 (Integrated Logistic Support), MIL-STD-2549 (Configuration Management. Data Interface), MIL-HDBK-61 (Configuration Management. Guidance), AECMA Specification 2000M (International Specification for Materiel Management Integrated Data Processing for Military Equipment), AECMA Specification 1000D (International Specification for Technical Data Publications, Utilising a Common Source Data Base) и т. д. Стандарты CALS Стандарты, разработанные ISO для CALS-технологий, можно разбить на три группы: представление информации о продукте, представление текстовой и графической информации и общего назначения. К первой группе относятся: ISO/IEC 10303 Standard for the Exchange of Product Model Data (STEP) и ISO 13584 Industrial Automation — Parts Library. Во вторую группу входят: ISO 8879 Information Processing — Text and Office System — Standard Generalized Markup Language (SGML); ISO/IEC 10179 Document Style Semantics and Specification Language (DSSSL); ISO/IEC IS 10744 Information Technology — Hypermedia/Time Based Document Structuring Language (HyTime); ISO/IEC 8632 Information Processing Systems — Computer Graphics — Metafile; ISO/IEC 10918 Coding of Digital Continuous Tone Still Picture Images (JPEG); ISO 11172 MPEG2 Motion Picture Experts Group (MPEG); Coding of Motion Pictures and associated Audio for Digital Storage Media и ISO/IECS 13522 Information Technology — Coding of Multimedia and Hypermedia Information (MHEG). Третья группа: ISO 11179 Information Technology — Basic Data Element Attributes; ISO 3166 Information Processing — Country Name Representations; ISO 31 Information Processing Representation of Quantities and Units; ISO 4217 Information Processing — Currencies and Funds; ISO 639 Information Processing Coded Representation of Names of Languages и ISO 8601 Information Processing — Date/Time Representations. Кроме международных стандартов, разработанных ISO, стандарты CALS широко представлены стандартами с индексами MIL и FIPS, которые лишний раз подчеркивают приоритетность разработки технологии CALS Соединенными Штатами и их военным ведомством изначально (самая многочисленная группа стандартов CALS имеет индекс MIL — стандартный индекс для документов, разработанных в МО США). Аббревиатура FIPS означает федеральный стандарт обработки информации (Federal Information Processing Standard). Стандарты CALS военного ведомства США, имеющие индекс MIL, также можно разбить на три группы: общих принципов электронного обмена и управления данными; представления текстовой и графической информации; электронных технических руководств. Стандарты FIPS не так многочисленны, как ISO и MIL, и делятся всего на две группы: описания процессов и безопасности информации. Госстандарт РФ готовит набор ГОСТов, отражающих, в частности, требования CALS-ориентированных стандартов серии ISO 10303 (Системы автоматизации производства и их интеграция; представление данных об изделии и обмен этими данными). Однако внедрение CALS-подхода в России имеет специфические сложности: часто для использования CALS-решений требуется предварительное проведение реинжиниринга бизнес-процессов; невысок уровень компьютеризации предприятий; отсутствует нормативная база; не хватает специалистов; нет рынка CALS-продуктов и услуг; нет денег на внедрение CALS технологий. Понятно, что первоочередной задачей для развития CALS-технологий в России является создание соответствующей нормативной базы. Поэтому Госстандартом России и Минэкономики России было принято решение о совместном финансировании разработки ряда первоочередных стандартов, которые открывают путь к внедрению CALS-технологий в отечественной промышленности. В настоящее время уже утверждены первые стандарты в области CALS. Создан и уже действует Технический комитет №431 при Госстандарте России, организованный на базе научно-исследовательского центра CALS, основная задача которого — разработка стандартов в области CALS. К настоящему времени приняты следующие стандарты серии «Системы автоматизации производства и их интеграция»: ГОСТ Р ИСО 10303-1-99. Методы описания. Общий обзор и основополагающие принципы; ГОСТ Р ИСО 10303-21-99. Представление и обмен данными об изделии. Методы реализации. Текстовый обменный файл; ГОСТ Р ИСО 10303-41-99. Представление и обмен данными об изделии. Интегрированные родовые ресурсы. Принципы описания продукта. Перспективность внедрения технологии CALS не вызывает сомнений. Другое дело, что на пути ее внедрения приходится преодолевать различные трудности. И если в странах «развитого капитализма» данные проблемы часто ограничиваются неверным восприятием обывателями самой технологии (живучим оказался стереотип о принадлежности CALS военному ведомству), то препятствия к продвижению этой перспективной технологии на российских просторах значительно более серьезны. Тем более обидно, что теоретические положения по описанию жизненного цикла изделий в отечественной науке разработаны достаточно давно. Процесс внедрения технологий в России не стоит на месте. Так, 24 октября 2000 года Министерство промышленности, науки и технологий России и научно-исследовательский центр CALS-технологий «Прикладная логистика», при содействии и участии Госстандарта России и государственной компании «Росвооружение», провело II научно-техническую конференцию «CALS-технологии — ключ к обеспечению успеха предприятий на внутреннем и внешнем рынках». На конференции присутствовало более 300 участников, представлявших 125 предприятий и организаций из 35 регионов России. Эксплуатация информационных систем Модели жизненного цикла информационных систем предназначены для использования прежде всего создателями, разработчиками таких систем. Поэтому нужно понять, в какой мере эти модели могут быть полезны для тех, кто реально занят эксплуатацией информационных систем. Тут встает вопрос — а в качестве кого по отношению к информационной системе (например, корпоративной сети предприятия) выступают те, кто работает на предприятии и занят ее эксплуатацией — системные администраторы, менеджеры, пользователи и т. д.? В развитой современной корпорации специалисты по информационным технологиям принимают самое непосредственное участие в формировании сетевого решения — выборе архитектуры, оптимизации топологии, настройке сетевого программного обеспечения и конечно же модернизации сети. Другими словами, сотрудники предприятия по отношению к сети выступают в качестве одних из ее создателей. Следовательно, модель жизненного цикла информационной системы, хотят они этого или нет, становится их рабочим инструментом. Предпочтительной моделью жизненного цикла для корпоративной сети является спиральная модель. В данном конкретном случае она интерпретируется следующим образом: специалисты, занятые эксплуатацией сети, постоянно разрабатывают новую версию своей сети, проходя в такой работе на каждом витке спирали стандартные этапы и не дожидаясь, когда эффективность системы опустится ниже заданного порога или система не сможет удовлетворять постоянно растущим требованиям предприятия. Применение же при этом CALS-технологий оказывается особенно полезным для сетей средних и крупных корпораций как эффективного и автоматизированного средства реализации выбранной модели жизненного цикла. Использование международных стандартов жизненного цикла в этой работе позволяет значительно сэкономить усилия, время и материальные ресурсы. И в этом главное достоинство использования таких моделей жизненного цикла, апробированных многократно и повсеместно. Эффективность реализации CALS Основная задача, решаемая путем применения CALS-технологий, — экономия времени и средств при одновременном повышении качества. Так, в США применение CALS-технологий сопровождается следующими типовыми показателями.  В процессах проектирования и инженерных расчетах: сокращение времени проектирования на 50%; снижение затрат на изучение выполнимости проектов на 15-40%.  В процессах организации поставок: уменьшение количества ошибок при передаче данных на 98%; сокращение времени поиска и извлечения данных на 40%; сокращение времени планирования на 70%; сокращение стоимости информации на 15-60%.  В производственных процессах: сокращение производственных затрат на 15-60%; повышение показателей качества на 80%;  в процессах эксплуатационной поддержки изделий: сокращение времени на изменения технической документации на 30%; сокращение времени планирования поддержки на 70%; снижение стоимости технической документации на 10-50%. Лекция №21-22 Общая стоимость владения информационной инфраструктурой Технология сейчас играет стратегически важную роль, и среди всех инструментов, которые используют организации, ключевое место занимают компьютерные приложения. Организации, которые могут обеспечить доступ всем своим пользователям к важнейшим для ведения бизнеса приложениям вне зависимости от того, где и когда находятся эти пользователи и какими клиентскими устройствами они располагают, получают важное стратегическое преимущество в современной сетевой экономике. Для обеспечения высокой производительности организации быстрый доступ к приложениям необходим всем пользователям — сотрудникам, поставщикам, продавцам и потребителям. Для коммерческих организаций используемые приложения играют ключевую роль в приобретении и сохранении конкурентных преимуществ. Но обеспечение доступа к приложениям в современной сложной и динамичной среде современного бизнеса требует все больших и больших затрат. Сегодня без использования информационных технологий невозможно эффективно управлять работой предприятия, добиваться значительных конкурентных преимуществ. Однако применение ИТ в бизнесе современного предприятия обходится весьма недешево. Общая стоимость ИС зависит от множества различных факторов, начиная от выбора аппаратного и программного обеспечения, и заканчивая структурой отделов автоматизации предприятия и конечной производительностью каждого сотрудника. Значительную долю в общей стоимости информационной системы (ИС) составляют затраты на ее обслуживание, поддержку в рабочем состоянии и т. д. Когда компания решает вопрос о выборе информационной системы, выводы о затратах на обслуживание сделать гораздо сложнее. Поставщики обычно заявляют, что их система после установки работает в полностью автономном режиме. Но на практике поддержка в работоспособном состоянии информационной системы в любом случае будет требовать вложений, так как правила игры в бизнесе постоянно изменяются, и любая компания должна к ним приспосабливаться. Основными причинами этого являются: • изменения в законодательстве; • изменение оргструктуры компании; • появление новых технологий (например, распространение Интернета перевернуло все представления о бизнесе). Обычно нужно оценить расходы, связанные с владением покупкой на протяжении нескольких лет. Методы такой оценки существуют и известны под названием TCO — total cost of ownership, или совокупная стоимость владения, которая помогает оценить затраты, связанные с использованием всех составляющих элементов ИС за период их жизненного цикла. В принципе модель ТСО призвана помочь руководителям ИТ-отделов распределить средства таким образом, чтобы добиться максимальной отдачи от инвестиций в ИТ и при этом уложиться в бюджет, выделенный на внедрение. ТСО нередко оказывается решающим фактором при выборе и внедрении (или при отказе от внедрения) какого-либо информационного продукта. Однако большинство экспертов считает, что получение точной оценки стоимости владения затруднено, особенно в масштабах большого предприятия. Не менее важным является вопрос о том как снизить ТСО. По экспертным оценкам, при правильном подходе к снижению непродуктивных затрат, реальная экономия может составить до трети общих расходов на ИТ. Основными направлениями снижения ТСО можно назвать: - внедрение аутсорсинга; - максимальную централизацию обработки и хранения информации; - уменьшение числа специализированных элементов (прежде всего компьютеров с прикладным ПО); - перенос прикладного ПО на серверы приложений; - обеспечение возможности входа в систему с любой точки; - обеспечение единообразного доступа, как по внутренней, так и по внешней телекоммуникационным сетям. Также, по мнению экспертов, для сокращения совокупной стоимости владения ИС имеет смысл соблюдать следующие рекомендации при подборе активного сетевого оборудования: • должна быть обеспечена возможность легкой интеграции существующей инфраструктуры сети и новейших сетевых технологий; • системы, построенные на выбранном сетевом оборудовании, должны обеспечивать наименьшее время отклика и наибольшую производительность; • должна быть обеспечена возможность наращивания производительности ИС в соответствии с конкретными требованиями пользователей; • должен быть обеспечен необходимый уровень защиты информации. Необходимо учитывать, что эффективность информационной системы закладывается на этапе ее создания, и управляющими параметрами здесь являются решения по архитектуре, стандартам, платформе, технологиям. Нередко высокая совокупная стоимость владения информационной системой — дефект, закладываемый при ее разработке. При этом надо учитывать, что совокупная стоимость владения ИС во многом определяется их эксплуатационными характеристиками, поэтому не совсем верно при разработке информационных систем делать основной упор исключительно на функциональность, а эксплуатационным характеристикам не уделять должного внимания. Конечный смысл оценки TCO в том, чтобы заранее определить узкие места и минимизировать затраты, заранее предвидеть все сложности и сообщить о них клиенту, а главное, попытаться предупредить эти проблемы еще на этапе внедрения. В 1997 году маркетинговая фирма Gartner Group опубликовала сенсационные данные; за три года совокупные расходы на покупку и содержание тогдашнего стандартного персонального компьютера составляли 30000 долларов США. Именно тогда вошла в обиход понятие ТСО (Total Cost Ownership) — Общая стоимость владения (ОСВ). В настоящее время концепция ТСО разработана для большинства информационных систем (ИС), технологий и платформ, она является общепризнанной для оценки эффективности ИТ. ТСО является ключевым количественным показателем ИТ и ИС, так как позволяет оценивать совокупные затраты на ИТ, анализировать их и соотвественно управлять ИТ-затратами (ИТ-бюджетом) для достижения наилучшей отдачи от ИТ. Оценка ТСО применяется как для «наведения порядка», так и для рассмотрения проектов. ТСО является одним из важнейших критериев при выборе лучшего проекта. Однако при принятии проекта необходимо учитывать также и другие качественные и количественные показатели: технические, технологические, управленческие, кадровые, финансовые. Не всегда наименьшее ТСО идет на пользу проекту. Ключевым моментом является сравнение ТСО данного IT-проекта (например, ТСО в пересчете на одного пользователя системы) с ТСО других компаний аналогичного профиля. Сравнение происходит как правило со средними показателями по отрасли (аналогичным компаниям) и с «лучшими в группе». Средние и лучшие показатели рассчитываются и отслеживаются экспертами Gartner Group по многим предприятиям различных отраслей. Определение ТСО важно при определении стоимости контрактов (особенно долгосрочных) аутсорсинга, лизинга и сервиса, при обосновании затрат на существующие ИТ или будущие проекты, в борьбе за ИТ-бюджет, при доказательстве эффективности работы ИТ-подразделений, для обоснования сокращения расходов на имеющиеся ИТ. На ТСО оказывает влияние качество подготовки, опыт и знания персонала, как пользователей, так и разработчиков. Постоянное отслеживание ТСО стало текущей работой в большинстве крупных компаний, которые используют ИТ-технологии. Реализуются целевые корпоративные программы по оптимизации ТСО. Краткий экскурс в историю Первой использовала термин TCO компания Gartner Group, которая в конце 80-х годов стала широко применять его в своих исследованиях и в 1987 г. выдвинула концепцию ТСО (первоначально она представляла лишь средство расчета стоимости владения компьютером на Wintel-платформе). Благодаря фирме Interpose, образованной в 1994 г., методика переросла в принципиально новую модель анализа финансовой стороны использования информационных технологий. С целью совершенствования самой модели Gartner Consulting (подразделение Gartner Group) проводила достаточно трудоемкие исследования рынка, и в результате сотрудничества двух компаний предложенная ими методика оценки затрат на информационные системы стала распространенным инструментом подсчета TCO. На протяжении последних лет многими компаниями также велись работы по изучению проблемы определения IT-затрат, вследствие чего появились схожие по сути, но разные по названию методики и подходы: истинная стоимость владения (Real Cost of Ownership -- RCO), совокупная стоимость владения приложениями (Total Cost of Application Ownership -- TCA) и др. На сегодняшний день все известные разработчики и производители программного и аппаратного обеспечения целенаправленно ведут исследования по снижению совокупной стоимости владения IT-решениями, использующимися при создании ИС предприятий. Модели IT-затрат Создание корпоративной информационной системы обходится предприятию недешево, а ее функционирование предполагает наличие постоянных и переменных затрат. Все эти затраты можно представить с помощью различных моделей TCO. Модель TCO компании Microsoft совместно с Interpose Первым примером может служить модель TCO, разработанная компанией Microsoft совместно с Interpose. IT-затраты в ней разбиваются на две категории: прямые (бюджетные) и косвенные. Прямые затраты — те, которые обычно учитываются при бюджетном планировании. У многих украинских предприятий нет возможности управлять своим IТ-бюджетом, поскольку зачастую система бюджетного управления отсутствует как таковая. Прямые затраты, как правило, предусматриваются в бюджетах центрального IT-департамента, а также рабочих или проектных групп по поддержке и внедрению информационных технологий внутри производственных и административных подразделений. К ним относятся затраты: • на аппаратное и программное обеспечение (покупка или аренда, новая установка или обновление и т. д.); • на управление (сетевое и системное администрирование, проектирование); • на поддержку (служба технической поддержки, обучение, контракты на поддержку и сопровождение); • на разработку (постановка задачи и разработка приложений, документации, тестирование и сопровождение); • на телекоммуникации (каналы связи и их обслуживание). Косвенные затраты — те, которые не поддаются планированию и часто даже не учитываются. Согласно исследованиям Interpose, они составляют свыше 50% средних расходов организаций на информационные технологии (см. диаграмму). К ним можно отнести: • пользовательские затраты (персональная поддержка, неформальное обучение, ошибки и просчеты); • простои (потеря производительности из-за выхода из строя оборудования или профилактические плановые остановки работы). Модель TCO компании Gartner Group В качестве второго примера рассмотрим модель TCO, основой для которой является концепция, предложенная Gartner Group. В этой модели учитываются следующие IT-затраты: фиксированные, или, как их еще называют, капитальные вложения, и текущие. Их условно разносят по временной шкале: капитальные вложения осуществляются на этапе построения ИС, текущие затраты — на этапе функционирования. По методике Gartner Group к фиксированным следует относить следующие затраты: • стоимость разработки и внедрения проекта; • привлечение внешних консультантов; • первоначальные закупки основного ПО; • первоначальные закупки дополнительного ПО; • первоначальные закупки аппаратного обеспечения. Фиксированными эти затраты называются потому, что делаются, как правило, один раз, на начальных этапах создания ИС. При этом выбор той или иной стратегии, аппаратной и программной платформ весьма существенно влияет на последующие текущие затраты. В свою очередь, текущие затраты состоят из трех статей: • стоимость обновления и модернизации системы; • затраты на управление системой в целом; • затраты, вызванные активностью пользователей ИС («активность пользователя»). Под "затратами на управление системой" подразумеваются расходы, связанные с управлением и администрированием компонентов ИС. В этой статье затрат можно выделить некоторые подкатегории: • обучение административного персонала и конечных пользователей; • заработная плата; • привлечение внешних консультантов; • аутсорсинг; • учебные курсы и сертификация; • техническое и организационное администрирование и сервис. Стоимость обеспечения работы пользователя отражена в понятии «активность пользователя». Эта статья затрат, по данным Gartner Group, имеет наиболее значимый вес в совокупной стоимости ИС. В ней выделяют следующие подстатьи затрат: • прямая помощь и дополнительные настройки; • формальное обучение; • разработка приложений; • работа с данными; • неформальное обучение; • futz-фактор (параметр, определяющий объем затрат, связанных с последствиями некомпетентных действий пользователя). Эти затраты связаны, например, с участием администратора в настройке рабочей станции, с оказанием помощи пользователю или с консультациями. По данным аналитических компаний, основные факторы, влияющие на итоговую стоимость владения информационными технологиями, на 75% обусловлены проблемами конечного пользователя. Описание этих двух моделей TCO не претендует на полноту, а показывает только общую картину IT-затрат компании и позволяет выработать процедуры, снижающие TCO. Применение указанных методик на конкретном предприятии, естественно, имеет свою специфику. Роль TCO для предприятия Основной проблемой при управлении IT-затратами является определение количественных значений составляющих TCO и отнесение их к конкретной статье затрат. Строго говоря, существуют расхождения в вопросах деления затрат на те или иные категории и статьи расходов. Но что не вызывает сомнений, так это их распределение на прямые (первоначальные затраты) и косвенные (затраты в процессе эксплуатации и использования). Здесь, кстати, очень наглядна аналогия с айсбергом. На первых порах кажется, что IT-затраты не так уж велики, но в конечном итоге предприятие может постигнуть судьба «Титаника», когда оно натолкнется на скрытые поначалу затраты, которые в совокупности выливаются в очень значительную денежную сумму. В связи с резким повышением сложности информационных систем зачастую происходит непрогнозируемый рост дополнительных затрат. Кроме того, существенно возрастает и роль человеческого фактора. Сегодня на предприятиях Украины нужно инициировать миграцию от существующей простой, но бесперспективной модели общей стоимости компьютерной и программной собственности к сложной и трудоемкой, но прогрессивной методике детального анализа всех составляющих расходов на информационные технологии. Это позволит управлять IT-затратами, тем самым увеличивая выгоду от использования информационных технологий на предприятии. Кроме выявления избыточных статей затрат, целью подсчета совокупной стоимости владения является оценка возможности возврата вложенных в IT средств — анализ привлекательности информационных технологий как объекта для инвестиций. Кроме того, подсчитав показатели TCO, IT-менеджер сможет составить реальный, обоснованный IT-бюджет, который будет базироваться на количественных показателях. И наконец, TCO может (и должна) использоваться в качестве одной из составляющих для финансовой оценки корпоративных затрат. Однако следует отметить, что подсчет TCO показывает только расходную, но никак не доходную часть. Если на предприятии уже функционирует информационная система, основанная на современных технологиях, или ее создание запланировано, то IT-менеджер должен быть «готов» сам и «подготовить» руководство к затратам, связанным с владением информационной системой. IT-затраты будут — и никто не в силах это изменить. Повлиять можно только на их структуру, избавившись от нецелесообразных и избыточных статей расходов. Данная задача должна ложиться именно на IT-менеджеров, которые обязаны реализовывать целевые корпоративные программы по оптимизации совокупной стоимости владения и постоянно вести работы по снижению IT-затрат. Достичь оптимизации TCO можно лишь за счет непрерывного управления IT-затратами. На данный момент в Украине очень немногие предприятия имеют ИС управления, отвечающую всем требованиям современного бизнеса. Большинство же компаний производят модернизацию существующих систем или начинают проекты по построению новых. И этот факт говорит о важности такого инструмента управления IT-затратами, как планирование совокупной стоимости владения. Два подхода к вопросу управления IТ-затратами Руководители предприятий и IT-менеджеры могут по-разному относиться к вопросу управления IT-затратами. Их подходы к решению данной проблемы условно можно разделить на два варианта. На отечественных предприятиях, как правило, вопрос о TCO либо старательно замалчивается, либо не возникает совсем. Между тем построение/модернизация, а также использование ИС без тщательной оценки ее TCO приводят к тому, что предприятие сталкивается с проблемой больших затрат на стадии функционирования системы. Только тогда руководство осознает актуальность проблемы, и IT-департамент начинает проводить мероприятия по снижению затрат. Однако эти работы чреваты новыми расходами и очень редко приводят хотя бы к балансу доходов и затрат, связанных с информационными технологиями, не говоря уже о перевесе доходов. Правильный подход — это управление IT-затратами еще до создания/внедрения ИС, т. е. их планирование. Он присущ западным и некоторым отечественным компаниям, занимающимся планированием затрат в рамках корпоративного управления. В этом случае использование информационных технологий возможно с минимизированной TCO и требует вести только текущую (малозатратную) работу по снижению затрат. Планирование TCO Итак, планирование IT-затрат (другими словами, планирование TCO) предполагает следующие этапы. 1. Определение прямых и косвенных затрат. Если комплексно подходить к принятию решения о применении IT в компании, то обязательно должны учитываться все прямые и косвенные затраты. Прямые затраты на аппаратное и программное обеспечение, как правило, не превышают 30% TCO (данные Interpose), но нельзя забывать о расходах на персонал и управление системой. 2. Определение возможных косвенных затрат. В частности, к косвенным относятся затраты, вызванные неработоспособностью ИС. Как оценить потери компании от простоя, который произошел вследствие «падения» системы? Если у предприятия большой дневной оборот (что характерно для торговых розничных и мелкооптовых фирм), то стоимость отказа ИС будет очень высока. При этом важно правильно оценить размер косвенных затрат, а также степень риска возникновения ситуаций, приводящих к расходам данного типа. 3. Распределение затрат по статьям. Вы можете распределить затраты согласно имеющимся классическим моделям или классифицировать их по собственной методике, разработанной соответственно специфике конкретной информационной системы и ее инфраструктуры. 4. Расчет показателей TCO. Самая сложная задача. Для ее решения существует специальное ПО (TCO Analyst, TCO Manager, TCO Snapshot Tool и др.), но оно довольно дорогостоящее. Поэтому для наших условий, возможно, более приемлемо решение, когда IT-менеджер совместно с финансовым работником самостоятельно подсчитают большинство затрат с помощью электронных таблиц. 5. Выделение наиболее существенных статей расходов и оценка возможности снижения затрат на ИС. Очевидно, что всякая экономия имеет свои пределы, и некоторые даже очень большие затраты могут быть объективными и целесообразными. Но все же действия по снижению ТСО должны быть направлены, в первую очередь, именно на крупные расходы и издержки. 6. Рассмотрение инструментов по снижению TCO. Инструменты для снижения TCO условно разделяются на технологические и процедурные. Процедурные инструменты — меры, которые можно принять с административной стороны, — могут применяться как на этапах построения, так и на этапах функционирования ИС. Технологические же, как правило, применяются уже на этапе эксплуатации системы, но их использование следует прогнозировать заранее. К технологическим инструментам относятся: • приобретение ПО, которое обладает технологическими свойствами, позволяющими существенно снизить объем затрат на его внедрение и последующее использование; • ориентация на определенные сетевые технологии и архитектуры; • использование стандартных баз данных; • применение средств удаленного управления рабочими местами; • оснащение рабочих мест только необходимыми программными и техническими средствами; • использование специально адаптированных для конкретной системы компонентов ПО, не нарушающих целостности архитектуры системы; • применение технологий, снижающих время простоя (источники бесперебойного питания, системы сетевой установки ПО и пр.); • использование решений для автоматизированного резервного копирования и восстановления и т. д. Среди процедурных инструментов можно выделить: • создание на начальных стадиях IT-проекта рабочей группы, которая должна пройти максимально полное обучение и в дальнейшем выполнять значительную часть работ по внедрению системы, обучению пользователей и последующему сопровождению; • проведение конкурсов при приобретении IT-решений; • использование референтных моделей, заложенных в интегрированном ПО; • использование международных и внутренних стандартов по IT, а также методик внедрения ведущих компаний; • внедрение корпоративной политики стандартизации программного и аппаратного обеспечения; • создание централизованной службы помощи, располагающей базой знаний по возможным проблемам; • разработка плана действий в экстренных ситуациях (например, в случае сбоя, хакерской или вирусной атак). Влияние технологических и процедурных инструментов на сокращение TCO всей информационной системы и отдельных ее компонентов доказывают исследования Gartner Group. 7. Выбор эффективных инструментов по снижению TCO. При выборе инструментов нужно тщательно проанализировать целесообразность их применения, поскольку расходы компании при этом могут быть выше, чем затраты, которые планируется снизить. 8. Применение инструментов по снижению TCO. Если все предыдущие шаги будут выполнены качественно и полноценно, то само применение станет заключительным этапом на пути оптимизации TCO. Предложенные выше этапы — это лишь условный схематический путь. Но если предприятие действительно заинтересовано в том, чтобы информационные технологии помогали бизнесу, а не «душили» его внезапными затратами, то нужно не только считать IT-затраты, но и управлять TCO. Лекция №23-24 Защита информации Угрозы, правила и механизмы Защита в компьютерных системах жестко связана с понятием надежности (dependability). Говоря неформально, надежной компьютерной системой считается система, службам которой мы оправданно доверяем. Как мы говорили ранее, надежность подразумевает доступность, безотказность, безопасность и ремонтопригодность. Однако, если мы собираемся доверять компьютерной системе, следует также принимать во внимание конфиденциальность и целостность. Под конфиденциальностью (confidentiality) мы понимаем свойство компьютерной системы, благодаря которому доступ к информации в ней ограничен кругом доверенных лиц. Целостность (integrity) — это характеристика, указывающая на то, что изменения могут быть внесены в систему только авторизованными лицами или процессами. Другими словами, незаконные изменения в защищенной компьютерной системе должны обнаруживаться и исправляться. Основные части компьютерной системы — это аппаратура, программы и данные. Другой способ взглянуть на защиту в компьютерных системах — считать, что мы стараемся защитить службы и данные от угроз защите (security threats). Мы выделяем четыре типа угроз защите: - перехват (interception); - прерывание (interruption); - модификация (modification); - подделка (fabrication). Перехватом мы называем такую ситуацию, когда неавторизованный агент получает доступ к службам или данным. Типичный пример перехвата — когда связь между двумя агентами подслушивает кто-то третий. Примером прерывания может служить повреждение или потеря файла. Обычно прерывание связывают с такой ситуацией, когда службы или данные становятся недоступными, уничтожаются, их невозможно использовать и т. п. В этом смысле атаки типа «отказ в обслуживании» (denial of service), при которых кто-то злонамеренно старается сделать определенную службу недоступной для других, — это угроза защите, классифицируемая как прерывание. Модификации включают в себя неавторизованные изменения данных или фальсификацию служб с тем, чтобы они не соответствовали своему оригинальному предназначению. Примеры модификации включают перехват сообщений с последующим изменением передаваемых данных, фальсификацию входов в базы данных и изменение программ с тем, чтобы скрытно отслеживать деятельность пользователей. Подделке соответствует ситуация, когда создаются дополнительные данные или осуществляется деятельность, невозможная в нормальных условиях. Так, например, злоумышленник может попытаться добавить записи в файл паролей или базу данных. Кроме того, иногда удается войти в систему, воспроизведя отправку ранее посланного сообщения. Мы рассмотрим подобные примеры чуть позже. Отметим, что прерывание, модификация и подделка могут рассматриваться как формы фальсификации данных. Просто констатировать, что система должна быть в состоянии противостоять всевозможным угрозам защите — это не метод построения защищенных систем. Прежде всего, следует описать требования к защите, то есть правила защиты. Правила защиты (security policy) точно описывают разрешенные и запрещенные действия для системных сущностей. В понятие «системные сущности» входят пользователи, службы, данные, машины и т. п. После составления правил защиты можно сосредоточиться на механизмах защиты (security mechanisms), посредством которых реализуются эти правила. Наиболее важные из них: - шифрование (encryption); - аутентификация (authentication); - авторизация (authorization); - аудит (auditing). Шифрование — фундамент компьютерной защиты. Шифрование трансформирует данные в нечто, чего злоумышленник не в состоянии понять. Другими словами, шифрование — это средство реализации конфиденциальности. Кроме того, шифрование позволяет нам проверить, не изменялись ли данные, давая возможность контролировать целостность данных. Аутентификация используется для проверки заявленного имени пользователя, клиента, сервера и пр. В случае с клиентом основная идея заключается в том, что до начала работы службы с клиентом служба должна определить подлинность клиента. Обычно пользователи аутентифицируют себя при помощи пароля, однако существуют и другие способы аутентификации клиента. После того как клиент аутентифицирован, необходимо проверить, имеет ли он право на проведение запрашиваемых действий. Типичным примером является доступ к базе данных с медицинской информацией. В зависимости от того, кто работает с базой, ему может быть разрешено читать записи, модифицировать определенные поля записей или добавлять и удалять записи. Средства аудита используются для контроля за тем, что делает клиент и как он это делает. Хотя средства аудита не защищают от угроз защите, журналы аудита постоянно используются для анализа «дыр» в системах защиты с последующим принятием мер против нарушителей. Поэтому нарушители всеми силами стараются не оставлять каких-либо следов, которые в конце концов могут привести к их раскрытию. До известной степени именно благодаря протоколированию доступа хакерство является весьма рискованным занятием. Архитектура защиты Globus Понятие о правилах защиты и роли, которую механизмы защиты играют в соблюдении этих правил, часто лучше объяснять на конкретном примере. Рассмотрим правила защиты, определенные в глобальной системе Globus. Globus — это система поддержки распределенных вычислений, в которой для производства вычислений одновременно используется множество хостов, файлов и других ресурсов. Такие системы часто называют вычислительными сетями. Ресурсы в таких сетях нередко расположены в различных административных доменах, которые могут находиться в разных частях света. Поскольку пользователи и ресурсы велики числом и рассеяны по множеству административных доменов, важность защиты резко возрастает. Чтобы разработать и правильно использовать механизмы защиты, необходимо понять, что на самом деле нужно защищать и какие допущения по этому поводу можно сделать. Опуская некоторые подробности, мы можем сказать, что правила защиты в Globus вытекают из следующих восьми умозаключений. - Среда состоит из множества административных доменов. - Локальные операции (то есть операции, протекающие в пределах одного домена) обеспечиваются исключительно локальными мерами защиты. - Глобальные операции (то есть операции, в которые включается несколько доменов) требуют инициатора, известного во всех вовлеченных в операцию доменах. - Для операций между сущностями в различных доменах необходима обоюдная идентификация. - Глобальная аутентификация стоит выше локальной. - Контроль доступа к ресурсам относится к компетенции локальной идентификации. - Пользователи могут делегировать свои права процессам. - Группа процессов в одном домене может использовать свои идентификаторы совместно. В системе Globus предполагается, что среда включает в себя множество административных доменов, каждый из которых имеет свои локальные правила защиты. Предполагается, что локальные правила не изменятся только из-за того, что система входит в Globus. Глобальные правила Globus, кроме того, не изменяют действия локальных правил защиты. Соответственно, глобальная защита в Globus ограничена лишь операциями, в которые вовлечены несколько доменов. В соответствии с этим моментом в Globus считается, что операции, целиком происходящие внутри одного домена, подчиняются только локальным правилам защиты этого домена. Другими словами, если операция инициирована и происходит в пределах одного домена, все действия производятся с использованием только локальных мер защиты. Globus не предпринимает на этот счет никаких дополнительных действий. Правила защиты Globus определяют, что запросы на операцию должны инициироваться — глобально или локально. Инициатор, которым является пользователь или процесс, работающий от имени пользователя, должен быть известен во всех доменах, участвующих в операции. Так, например, пользователь может задействовать глобальное имя, которое отображается в локальные имена в конкретных доменах. Как именно осуществляется это отображение, зависит от домена. Один из важных принципов состоит в том, что операции между сущностями в разных доменах требуют обоюдной аутентификации. Это означает, например, что если пользователь из одного домена захочет воспользоваться службой, расположенной в другом домене, домену, в котором находится служба, необходимо провести аутентификацию пользователя. Не менее важно, чтобы пользователь был уверен в том, что он использует именно тот сервер, который собирался использовать. Мы более подробно обсудим вопросы аутентификации чуть позже. Эти два правила комбинируются в следующее требование защиты. Если личность пользователя подтверждена и пользователь локально известен в данном домене, то в этом домене он может считаться прошедшим аутентификацию. То есть Globus полагает, что при получении доступа к ресурсам удаленного домена общесистемным средствам аутентификации достаточно установить тот факт, что пользователь уже аутентифицирован в этом удаленном домене (если он там известен). Дополнительная аутентификация в этом удаленном домене уже не нужна. Как только пользователь (или процесс, работающий по его заданию) аутентифицирован, ему необходимо подтвердить соответствующие права на доступ к ресурсам. Так, например, пользователь, желающий изменить файл, должен сначала пройти аутентификацию, после чего следует проверить, действительно ли этот пользователь имеет право изменять этот файл. Правила защиты Globus предполагают, что контроль доступа осуществляется исключительно локально, внутри домена, в котором находятся используемые ресурсы. Чтобы разобраться в правиле, согласно которому пользователи могут делегировать свои права процессам, рассмотрим мобильного агента системы Globus, который выполняет свою задачу, инициируя одну за другой некоторые операции в различных доменах. Подобному агенту для выполнения своей работы может потребоваться длительный срок. Чтобы существовала возможность поддерживать связь между агентом и пользователем, по заданию которого работает этот агент. Globus требует, чтобы пользователи могли делегировать часть своих прав процессам. Соответственно, при аутентификации агента с последующей проверкой его прав система Globus должна иметь возможность разрешить агенту инициировать операции, не связываясь с владельцем агента. В качестве последнего правила Globus требует, чтобы группы процессов, выполняемые в одном домене и работающие по заданию одного пользователя, могли совместно использовать один набор полномочий. Как мы покажем далее, наборы полномочий необходимы для аутентификации. Это утверждение, в сущности, открывает дорогу масштабируемым решениям аутентификации за счет отказа от поддержки каждым из процессов своего собственного уникального набора полномочий. Правила защиты Globus позволяют ее разработчикам сосредоточиться на решении общих проблем защиты. Предполагая, что каждый домен поддерживает собственные правила защиты, разработчики Globus сосредоточивают свои усилия только на угрозах защите на междоменном уровне. В частности, правила защиты показывают, что важными вопросами построения считаются представление пользователя в удаленных доменах и выделение ресурсов удаленного домена пользователю или его представителю. В первую очередь Globus нуждается в механизмах междоменной аутентификации и объявления пользователя в удаленных доменах. Для этой цели вводятся два типа представителей. Заместитель пользователя (user proxy) представляет собой процесс, которому дано право действовать от лица пользователя в течение ограниченного времени. Ресурсы представляются в виде заместителей ресурсов. Заместитель ресурса (resource proxy) — это процесс, работающий в определенном домене и используемый для трансляции глобальных операций с ресурсами в локальные операции, удовлетворяющие требованиям локальных правил защиты. Так, например, заместитель пользователя обычно применяется для связи с заместителем ресурса в процессе доступа к необходимым ресурсам. Архитектура защиты системы Globus в основном состоит из различных сущностей, таких как пользователи, заместители пользователей, заместители ресурсов и процессы общего назначения. Эти сущности размещены в доменах и взаимодействуют друг с другом. В частности, архитектура защиты определяет четыре различных протокола взаимодействия, показанных на рис. 8.1. Рис. 8 . 1 . Архитектура защиты Globus Первый протокол детально описывает создание пользователем своего заместителя и делегирование этому заместителю своих прав. В частности, чтобы позволить заместителю действовать по заданию пользователя, этот пользователь передает ему соответствующий набор полномочий. Второй протокол определяет, как заместитель пользователя может запросить ресурсы в удаленном домене. Коротко говоря, протокол указывает, что заместитель ресурса создает процесс в удаленном домене после проведения обоюдной аутентификации. Этот процесс представляет пользователя (как это ранее делал заместитель пользователя), но работает в том же домене, что и запрошенные ресурсы. Процесс имеет доступ к ресурсам и подчиняется правилам контроля доступа, принятым в этом домене. Процесс, созданный в удаленном домене, может инициировать дополнительные вычисления в других доменах. Соответственно, необходим протокол выделения ресурсов в удаленных доменах, которое инициируется процессом, не являющимся заместителем. В Globus такое выделение ресурсов производится через заместителя пользователя. Процессу просто разрешается иметь собственного заместителя пользователя, который может запрашивать выделение ресурсов в соответствии со вторым протоколом. Четвертый и последний протокол в архитектуре защиты Globus — это способ, посредством которого пользователь может объявить о себе в удаленном домене. Если считать, что пользователь имеет учетную запись в конкретном домене, нам необходимо, чтобы системный набор прав, представленный заместителем пользователя, автоматически конвертировался в права для этого домена. Протокол предписывает, как зарегистрировать отображение глобальных прав пользователя в локальные права в локальной таблице отображений домена. Самый важный момент во всем этом заключается в том, что архитектура защиты Globus соответствует описанным ранее правилам защиты. Механизмы реализации этой архитектуры, в частности, рассмотренные здесь протоколы, едины для многих распределенных систем и будут обсуждаться далее в этой главе. Трудность разработки защищенных распределенных систем связана не столько с механизмами защиты, сколько с тем, как использовать эти механизмы для обеспечения защиты. Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №25-26 Вопросы разработки В распределенную систему, да впрочем, и в любую компьютерную систему, должны быть встроены механизмы защиты, при помощи которых можно будет реализовать различные правила защиты. При реализации служб защиты общего назначения следует учитывать несколько моментов. Ниже мы рассмотрим три таких важных момента: фокус управления, многоуровневую организацию механизмов защиты и простоту. Фокус управления Организуя защиту приложений (в том числе и распределенных), можно использовать три основных подхода, которые иллюстрирует рис. 8.2. Первый вариант — это защита непосредственно ассоциированных с приложением данных. Под «непосредственно» мы имеем в виду, что независимо от того, какие операции могут производиться с элементами данных, основная задача этого типа защиты — сохранение целостности данных. Обычно такая защита используется в системах баз данных, в этом случае заранее определяются различные ограничения целостности, автоматически проверяемые затем при каждой модификации элемента данных. Рис. 8.2. Три подхода к противодействию угрозам защите. Защита от неверных операций (а). Защита от неавторизованных обращений (б). Защита от неавторизованных пользователей (в) Второй вариант — это защита путем точного указания того, кто и как может использовать операции доступа к данным или ресурсам. В этом случае фокус управления тесно связан с механизмами контроля доступа, о которых мы поговорим подробнее чуть позже. Так, например, в системе, построенной на основе объектов, для каждого из методов, доступ к которым мы открываем клиентам, можно указать, какой именно клиент имеет право к нему обратиться. С другой стороны, методы контроля доступа могут применяться к интерфейсу, предоставляемому объектом, или собственно объекту. Этот подход также используется с целью детализации управления доступом. Третий вариант — сосредоточить внимание непосредственно на пользователе, приняв меры, чтобы доступ к приложению имели только определенные люди, независимо от операций, которые они собираются производить. Так, например, банковская база данных может быть защищена путем закрытия доступа к ней всем, кроме высшего управленческого персонала. Другой пример: во многих университетах доступ к определенным данным и приложениям разрешен лишь преподавателям и персоналу, студентам же доступ к ним закрыт. В действительности управление сведено к определению ролей (roles) пользователей. После подтверждения соответствующей роли ей предоставляется или запрещается доступ к соответствующим ресурсам. Процесс разработки системы защиты состоит, в частности, в том, чтобы определить роли, которые могут потребоваться пользователям, и предоставить механизмы управления доступом на основе списков ролей. Многоуровневая организация механизмов защиты Важным моментом при разработке систем защиты является решение о том, сколько уровней должны иметь механизмы защиты. Уровень в данном контексте соответствует логической организации системы. Так, например, компьютерные сети часто построены из нескольких уровней, в соответствии с некоторой эталонной моделью. Также можно организовать и структуру распределенных систем, в которой имеются отдельные уровни для приложений, задач промежуточного уровня, служб и ядра операционной системы. Комбинируя многоуровневые структуры компьютерных сетей и распределенных систем, мы получаем схему, представленную на рис. 8.3. Рис. 8.3. Логическая многоуровневая организация распределенных систем В сущности, на рисунке службы общего назначения отделены от коммуникационных служб. Это разделение очень важно для понимания распределения по уровням механизмов защиты распределенных систем и, в частности, для представления о доверии. Разница между доверием и защитой очень важна. Система может быть или не быть защищенной, особенно принимая во внимание различные случайности, но мнение клиента о том, что система защищена — это вопрос доверия. Уровень, на котором размещается механизм защиты, зависит от доверия клиента к защите служб этого уровня. В качестве примера рассмотрим организацию, расположенную в нескольких географически удаленных друг от друга местах, которые соединены коммуникационной службой, такой как коммутируемая мультимегабитная служба данных (Switched Multi-megabit Data Service, SMDS). Сеть SMDS можно рассматривать как базовую сеть канального уровня, соединяющую локальные сети, в том числе и разнесенные в пространстве, как это показано на рис. 8.4. Защиту можно обеспечить путем установки шифрующего устройства на каждом маршрутизаторе SMDS, как показано на рисунке. Эти устройства автоматически зашифровывают и расшифровывают пересылаемые пакеты, но не предоставляют никаких средств для организации безопасной связи в пределах одной локальной сети. Если Алиса из сети А посылает сообщение Бобу в сеть Б и беспокоится о том, что это письмо кто-нибудь перехватит, она должна быть уверена по крайней мере в том, что шифрование трафика с удаленными сетями работает успешно. Это означает, например, что она должна доверять системным администраторам обеих локальных сетей и полагать, что они принимают меры против вмешательства в работу шифрующих устройств. Рис. 8.4. Несколько сайтов, связанных глобальной службой магистрали Допустим теперь, что Алиса не доверяет защите трафика с удаленными сетями. Она может предпринять собственные меры, например, использовать службу защиты транспортного уровня, такую как служба SSL (Secure Socket Layer — уровень защищенных сокетов), которая служит, в частности, для защищенной пересылки почты по соединениям TCP. Важно отметить, что SSL позволит Алисе установить защищенное соединение с Бобом. Все сообщения транспортного уровня будут зашифрованы — и на уровне SMSD тоже, но Алисе это не важно. В данном случае Алиса доверяет своей службе SSL. Другими словами, она верит, что SSL ее защитит. В распределенных системах механизмы защиты часто размещаются на промежуточном уровне. Если Алиса не доверяет SSL, она может пожелать использовать локальную службу защиты RPC. И опять-таки она должна доверять этой службе, полагая, что та работает корректно, а в данном случае не допускает утечек информации и верно идентифицирует клиенты и серверы. Службам защиты, размещаемым на промежуточном уровне распределенных систем, можно доверять только в том случае, если те службы, на которые они полагаются, также защищены. Так, например, если служба защиты RPC реализована частично на основе SSL, доверие к службе RPC зависит от того, насколько вы доверяете SSL. Если вы не доверяете защите SSL, то не можете доверять и уровню защиты, предоставляемому службой RPC. Распределение механизмов защиты Зависимости между службами, требующими доверия, приводят к понятию доверенной вычислительной базы (Trusted Computing Base, TSB). TSB — это набор всех механизмов защиты (распределенной) компьютерной системы, необходимых для осуществления правил защиты. Чем меньше TSB, тем лучше. Если распределенная система построена на базе промежуточного уровня (надстройки над существующей сетевой операционной системой), ее защита может зависеть от защиты базовых локальных операционных систем. Другими словами, TSB в распределенной системе может включать в себя локальные операционные системы различных хостов. Рассмотрим файловый сервер в распределенной файловой системе. Этот сервер может быть завязан на многие механизмы защиты, предоставляемые локальной операционной системой. В перечень этих механизмов входят не только средства защиты файлов от доступа к ним посторонних процессов, не относящихся к файловому серверу, но и механизмы защиты сервера от злонамеренного повреждения. Распределенные системы, привязанные к промежуточному уровню, требуют поэтому доверия к локальной операционной системе, под управлением которой они работают. Если такого доверия нет, часть функциональности локальной операционной системы должна быть встроена в саму распределенную систему. Рассмотрим операционную систему с микроядром, в которой большинство служб операционной системы выполняется в виде обычных пользовательских процессов. В этом случае, например, стандартная файловая система может быть полностью заменена другой файловой системой, особо приспособленной к специфическим нуждам распределенной системы, в том числе и по части различных механизмов защиты. Этому подходу будет соответствовать отделение служб защиты от прочих видов служб путем распределения этих служб по различным машинам в соответствии с той степенью защиты, которая им необходима. Так, например, для защищенной распределенной файловой системы можно отделить файловый сервер от клиентов путем установки сервера на машину с доверенной операционной системой, на которой, возможно, установлена также отдельная защищенная файловая система. Клиенты и их приложения могут быть размещены на машинах, не вызывающих доверия. Рис. 8.5. Применение принципов RISSC к защищенным распределенным системам Подобное разделение эффективно уменьшает размер ТСВ до относительно небольшого числа аппаратных и программных компонентов. В ходе последующей защиты этих машин от внешних атак общее доверие к защите распределенной системы может быть еще увеличено. Предотвращение прямого доступа клиентов и их приложений к критически важным службам производится путем предоставления ограниченного интерфейса к защищенным системным компонентам (Reduced Interfaces for Secure System Components, RISSC). Согласно этому подходу, любой критичный к уровню защиты сервер помещается на отдельную машину, изолированную от систем конечных пользователей, и использует низкоуровневые защищенные сетевые интерфейсы, как показано на рис. 8.5. Клиенты и их приложения работают на различных машинах и могут взаимодействовать с защищенным сервером только через эти сетевые интерфейсы. Простота Другой важный момент проектирования, касающийся уровня, на котором следует разместить механизмы защиты, — это простота. Разработка защищенных компьютерных систем обычно считается сложным делом. Соответственно, самой лучшей будет система, использующая небольшое количество простых механизмов, в которых легко разобраться и правильную работу которых легко гарантировать. К сожалению, простых механизмов для реализации правил защиты часто недостаточно. Рассмотрим снова эпизод, когда Алиса посылает письмо Бобу. Мы обсуждали его чуть раньше. Шифрование на канальном уровне — это простой и легко понятный механизм защиты от перехвата глобального трафика. Однако если Алиса хочет, чтобы ее письма мог получить только Боб, ей необходимо кое-что еще. Она нуждается в службах аутентификации пользовательского уровня, кроме того, чтобы доверять им, Алисе может потребоваться знать о том, как они работают. Поэтому аутентификация пользовательского уровня может потребовать как минимум представления о криптографических ключах и знания определенных механизмов, таких как сертификация, даже несмотря на то, что многие службы защиты полностью автоматизированы и прозрачны для пользователя. В других случаях само приложение может быть достаточно сложным, а введение защиты дополнительно усложняет его. Примером приложений, в которые включаются сложные протоколы защиты, являются цифровые платежные системы. Сложность цифровых платежей часто связана с тем, что для совершения платежа необходимо взаимодействие нескольких действующих лиц. В этих случаях важно, чтобы базовые механизмы, используемые для реализации протоколов, были относительно простыми и легко понятными. Простота будет способствовать доверию пользователей, работающих с приложением, и что более важно, сможет убедить разработчиков в отсутствии «прорех» в системе защиты. Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с. Лекция №27-28 Криптография В защите распределенных систем очень важную роль играют приемы криптографии. Основная идея этих приемов проста. Рассмотрим отправителя S, который хочет переслать сообщение т получателю R. Чтобы обезопасить сообщение от угроз защите, отправитель сначала шифрует его, превращая в непонятное сообщение т', после чего посылает это т' получателю R. R, в свою очередь, должен расшифровать полученное сообщение и получить оригинал, то есть сообщение т. Шифрование и расшифровка осуществляются путем применения криптографических методов с использованием ключей, как показано на рис. 8.6. Исходная форма посылаемого сообщения, называемая простым текстом (plaintext), обозначена на рисунке как Р, его зашифрованный вариант, известный как шифрованный текст (ciphertext), обозначен как С. Чтобы описать различные протоколы, используемые для построения служб защиты распределенных систем, полезно будет ввести обозначения для обычного текста, шифрованного текста и ключей. В соответствии с общими соглашениями мы будем использовать выражение С = ЕK(Р) для описания того факта, что шифрованный текст С был получен путем шифрования простого текста Р с использованием ключа K, Точно так же Р = DK(C) обозначает операцию расшифровки шифрованного текста С с использованием ключа K, приводящую к получению простого текста Р. Рис. 8.6. Проникновение и подслушивание при взаимодействии Возвращаясь к нашему примеру, при передаче сообщения в виде шифрованного текста С мы должны защищаться от трех различных типов атак, и в этом нам прекрасно помогает шифрование. Во-первых, злоумышленник может перехватить сообщение так, что об этом не узнают ни отправитель, ни получатель. Разумеется, если передаваемое сообщение зашифровано таким образом, что его невозможно расшифровать, не имея соответствующего ключа, перехват бесполезен: злоумышленник сможет увидеть только непонятные данные. (Кстати говоря, самого факта передачи сообщений может иногда быть достаточно для злоумышленника, чтобы сделать определенные выводы. Так, например, если в ходе мирового кризиса объем входящего трафика Белого дома внезапно падает почти до нуля, а объем трафика определенной точки в Скалистых горах, штат Колорадо, соответственно вырастает, это может оказаться очень полезной информацией.) Второй тип атак, который нам следует рассмотреть, это изменение сообщений. Изменить простой текст очень легко, изменить грамотно зашифрованный текст гораздо сложнее, поскольку для внесения в него осмысленных изменений злоумышленник должен сначала расшифровать сообщение. Кроме того, он должен быть в состоянии корректно зашифровать его, в противном случае получатель может заметить, что сообщение подделано. Третий тип атак — добавление злоумышленником шифрованного сообщения в систему коммуникации с попыткой заставить R поверить, что это сообщение пришло от S. И снова, как мы увидим далее в этой главе, шифрование может помочь нам защититься от подобных атак. Отметим, что если злоумышленник в состоянии изменить сообщения, он может и добавлять в систему собственные сообщения. Существует фундаментальное разделение криптографических систем на системы с одинаковыми и различными ключами шифрования и дешифровки. В случае симметричной криптосистемы (symmetric cryptosystem) для шифрования и расшифровки сообщения используется один и тот же ключ. Иными словами: P = DK(EK(P)). Симметричные криптосистемы также именуются системами с секретным, или общим, ключом, поскольку отправитель и получатель должны совместно использовать один и тот же ключ, и, чтобы гарантировать защиту, этот общий ключ должен быть секретным. Никто другой этот ключ видеть не должен. Мы будем использовать для такого ключа, разделяемого A и В, обозначение KА,В. В асимметричной криптосистеме (asymmetric cryptosystem) ключи шифрования и расшифровки различны, но вместе образуют уникальную пару. Другими словами, существует отдельный ключ шифрования KЕ. И отдельный ключ расшифровки, KD, так что: . Один из ключей асимметричной криптосистемы является закрытым, другой — открытым. По этой причине асимметричные криптосистемы также называют системами с открытым ключом (public-key systems). Поэтому мы будем использовать обозначение для обозначения открытого ключа, принадлежащего A, а — для соответствующего ему закрытого ключа. Предваряя подробное обсуждение протоколов защиты, скажем, что какой из ключей (шифрующий или дешифрующий) будет сделан открытым, зависит от того, как эти ключи используются. Например, если Алиса хочет послать Бобу конфиденциальное сообщение, она будет использовать для шифрования сообщения открытый ключ Боба. Поскольку Боб — единственный, кто обладает закрытым ключом расшифровки, он будет также единственным, кто сможет расшифровать сообщение. С другой стороны, предположим, что Боб хочет быть уверен, что сообщение, которое он только что получил, действительно отправлено Алисой. В этом случае Алиса может использовать для шифрования сообщения свой закрытый ключ. Если Боб в состоянии успешно расшифровать сообщение, используя открытый ключ Алисы (и расшифрованный текст сообщения содержит достаточно информации, чтобы убедить Боба), он знает, что сообщение было послано Алисой, поскольку ключ расшифровки однозначно связан с ключом шифрования. Далее мы рассмотрим этот алгоритм подробнее. Еще одно применение криптографии в распределенных системах — это хэш-функции (hash functions). Хэш-функция H принимает на входе сообщение т произвольной длины и создает строку битов h фиксированной длины: h = Н(т). Хэш h можно сравнить с дополнительными битами, добавляемыми к сообщению в коммуникационной системе для обнаружения ошибок, например, при циклическом избыточном кодировании (CRC). Хэш-функции, используемые в криптографических системах, имеют определенные свойства. Во-первых, это односторонние функции (one-way functions). То есть вычисление входного сообщения т по известному результату их работы h невозможно. С другой стороны, вычислить h по т достаточно несложно. Во-вторых, они обладают свойством слабой устойчивости к коллизиям (weak collision resistance), означающим, что если заданы исходное сообщение т и соответствующий ему результат h = Н(т), невозможно вычислить другое сообщение т', такое, что Н(т) = Н(т'). И наконец, криптографическая хэш-функция также обладает свойством сильной устойчивости к коллизиям (strong collision resistance). Это значит, что если дана только хэш-функция Н, невозможно вычислить любые два различных входных значения т и т' такие что Н(т) = Н(т'). Подобные свойства приложимы к любой функции шифрования Е и используемым ключам. Кроме того, для любой функции шифрования Е не должно быть возможности вычислить используемый ключ K, имея простой текст Р и соответствующий ему шифрованный текст С = EK(Р). Также аналогично устойчивости к коллизиям, при наличии простого текста Р и ключа K невозможно вычислить другой подходящий ключ K' такой, что . Искусство и наука разработки алгоритмов для криптографических систем имеют длинную историю, и построение защищенных систем часто оказывается неожиданно трудной или даже невозможной задачей. В наши задачи не входит детальное рассмотрение подобных алгоритмов. Однако для того, чтобы дать определенное представление о криптографии в компьютерных системах, мы кратко представим три показательных криптографических алгоритма. Перед тем как мы погрузимся в детали различных протоколов, обобщим используемую нотацию и аббревиатуры (табл. 8.1). Таблица 8 . 1 . Нотация, используемая в этой главе Нотация Описание KA,B Секретный ключ, совместно используемый А и В Открытый ключ А Закрытый ключ А Рис. 8.7. Алгоритм DES (а). Схема одного цикла шифрования (б) Симметричные криптосистемы — DES Нашим первым примером криптографического алгоритма будет стандарт шифрования данных (Data Encryption Standard, DES), который используется в симметричных криптосистемах. Алгоритм DES создавался для работы с 64-битовыми блоками данных. Блок преобразуется в зашифрованный (64-битный) блок за 16 шагов, на каждом из которых используется собственный 48-битный ключ шифрования. Каждый из этих 16 ключей порождается из 56-битного главного ключа, как показано на рис. 8.7, а. Перед тем как над исходным блоком начнут выполняться его 16 циклов шифрования, проводится его первичное преобразование, а после шифрования производится преобразование, обратное первичному. Результатом является зашифрованный блок. Каждый цикл шифрования i берет в качестве исходных данных 64-битный блок с предыдущего цикла шифрования i – 1, как показано на рис. 8.7, б. 64 бита разбиваются на левую часть Li–1 и правую часть Ri–1 по 32 бита каждая. Правая часть в следующем цикле используется в качестве левой, и наоборот. Главная работа выполняется в искажающей функции f. Эта функция принимает в качестве исходных данных 32-битный блок Ri–1 и 48-битный ключ Ki, а затем генерирует 32-битный блок, который подвергается операции «исключающее ИЛИ» (XOR) с блоком Li–1, порождая Ri. Искажающая функция сначала расширяет Ri–1 до 48 бит, а затем проводит над ним операцию «исключающее ИЛИ» с ключом Ki, Результат делится на восемь частей по шесть бит. Каждая часть протягивается затем через различные S-боксы (S-boxes), которые представляют собой операции замены каждой из возможных 64 6-битных комбинаций на одну из 16 возможных 4-битных комбинаций. Восемь получившихся кусков по 4 бита объединяются в одно 32-битовое значение и преобразуются далее. Рис. 8.8. Техника циклической генерации ключа в алгоритме DES 48-битный ключ Ki порождается из 56-битного главного ключа следующим образом. Сначала главный ключ преобразуется и делится на две 28-битных половины. На каждом цикле первая половина сдвигается на один или два бита влево, после чего из нее выделяются 24 бита. Вместе с 24 битами из второй сдвинутой половины они образуют 48-битный ключ. Детально один цикл шифрования иллюстрирует рис. 8.8. Алгоритм DES достаточно прост, но его нелегко взломать с использованием аналитических методов. «Грубая сила» (простой подбор ключа) значительно проще. В настоящее время надежно защищает от взлома «тройное» использование алгоритма DES в специальном режиме шифрование — расшифровка — шифрование с разными ключами. Аналитические атаки на DES сильно усложняет тот факт, что структура этого алгоритма никогда не была полностью описана в открытой документации. Так, например, можно показать, что применение нестандартных S-боксов значительно упрощает взлом алгоритма. Рекомендации по структуре и использованию S-боксов были опубликованы только после новых «моделей» атак, разработанных в девяностых годах. Алгоритм DES доказал свою устойчивость к этим атакам, и его разработчики открыли, что они знали об этих «новых» моделях еще в 1974 году, когда разрабатывали DES. DES уже много лет используется в качестве стандартной технологии шифрования, но в настоящее время происходит процесс его замены алгоритмом Риндаля (Rijndael) с блоками длиной 128 бит. Также имеются варианты с большими ключами и более длинными блоками. Разработанный алгоритм достаточно быстр, чтобы его можно было реализовать даже в смарт-картах. Важность этой области применения криптографии растет с каждым днем. Криптосистемы с открытым ключом — RSA В качестве второго примера криптографического алгоритма рассмотрим широко используемую систему с открытым ключом — RSA, названную в честь ее изобретателей — Ривеста (Rivest), Шамира (Shamir) и Альдемана (Aldeman). Защита RSA вытекает из того факта, что в настоящее время не существует эффективного метода нахождения простых множителей больших чисел. Можно показать, что любое целое число можно записать в виде произведения простых чисел. Так, например, 2100 может быть записано как: 2100 = 2 × 2 × 3 × 5 × 5 × 7. Таким образом, 2, 3, 5 и 7 являются простыми множителями числа 2100. В RSA открытый и закрытый ключи создаются из очень больших простых чисел (содержащих сотни десятичных цифр). Взлом RSA эквивалентен обнаружению этих чисел. В настоящее время подобная задача неразрешима, несмотря на то, что математики работают над ней уже несколько столетий. Создание открытых и закрытых ключей происходит в четыре этапа. 1. Выбираются два больших простых числа, р и q. 2. Вычисляется их произведение n = p×q и z = (p – 1)×(q – 1). 3. Выбирается число d, взаимно простое с z. 4. Вычисляется число е, такое, что e×d = 1 mod z. Одно из чисел, например d, может впоследствии использоваться для расшифровки, а е — для шифрования. Только одно из этих двух чисел будет открытым, какое именно — зависит от используемого алгоритма. Рассмотрим вариант, когда Алиса хочет, чтобы сообщение, которое она посылает Бобу, было конфиденциально. Другими словами, она хочет быть уверена в том, что никто кроме Боба не сможет перехватить и прочитать ее сообщение. RSA рассматривает любое сообщение т как строку битов. Каждое сообщение сначала разбивается на блоки фиксированной длины, и каждый очередной блок mi представляется в виде числа в двоичном виде, лежащего в интервале 0 ≤ mi < п. Для шифрования сообщения т отправитель вычисляет для каждого блока mi значение ci = mei(mod п), которое и отправляется получателю. Расшифровка на стороне получателя производится путем вычисления mi = cdi(mod п). Отметим, что для шифрования необходимы e и n, в то время как для расшифровки — d и n. Сравним RSA с симметричными криптосистемами, такими как DES. Для RSA характерен недостаток — сложность вычислений, которая приводит к тому, что расшифровка сообщений, зашифрованных по алгоритму RSA, занимает в 100–1000 раз больше времени, чем расшифровка сообщений, зашифрованных по алгоритму DES. Точный показатель зависит от реализации. В результате многие криптографические системы используют RSA только для безопасного обмена общими секретными ключами, избегая применять этот способ для шифрования «обычных» данных. Хэш-функции — MD5 В качестве последнего примера широко используемого криптографического алгоритма мы рассмотрим MD5. MD5 — это хэш-функция для вычисления 128-битных дайджестов сообщений (message digests) фиксированной длины из двоичных исходных строк произвольной длины. Сначала исходная строка дополняется до общей длины в 448 бит (по модулю 512), после чего к ней добавляется длина исходной строки в виде 64-битового целого числа. В результате исходные данные преобразуются в набор 512-битных блоков. Структура алгоритма приведена на рис. 8.9. Начиная с определенного постоянного 128-битового значения, алгоритм включает в себя k фаз, где k — число 512-битных блоков, получившихся из дополненного согласно алгоритму сообщения. В ходе каждой из фаз из 512-битного блока данных и 128-битного дайджеста, вычисленного на предыдущей фазе, вычисляется новый 128-битный дайджест. Фаза алгоритма MD5 состоит из четырех циклов вычислений, на каждом из которых используется одна из следующих четырех функций: F(x, y, z) = (х AND у) OR ((NOT х) AND z), G(x, y, z) = (х AND z) OR (у AND (NOT z)), H(x, y, z) = x XOR у XOR z, I(x, y, z) = y XOR (x OR (NOT z)). Каждая из этих функций работает с 32-битными переменными x, y и z. Чтобы проиллюстрировать, как используются эти функции, рассмотрим 512-битный блок b дополненного сообщения на фазе k. Блок b разделяется на 16 32-битных подблоков b0, b1, …, b15. Как показано на рис. 8.10, в ходе первого цикла для изменения четырех переменных (назовем их p, q, r и s соответственно) в ходе 16 итераций используется функция F. Эти переменные переносятся на очередной цикл, а после окончания этой фазы передаются на следующую. Всего существует 64 заранее определенных констант Ci. Для указания циклического сдвига влево используется запись х <<< п: биты в х сдвигаются на п позиций, причем биты, ушедшие за левую границу числа, добавляются справа. Рис. 8.10. 16 итераций первого цикла MD5 Во втором цикле подобным же образом используется функция G, а H и I — соответственно в третьем и четвертом циклах. Каждый шаг, таким образом, включает в себя 64 итерации, и в очередной фазе используются вычисленные на предыдущей фазе значения р, q, r и s. Библиографический список 1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с.