2.2 Тезисы лекционных занятий I. Тема лекции: ВВЕДЕНИЕ В ДИСЦИПЛИНУ (2 часа). Конспект лекции: 1.1 Введение в дисциплину. Цели и задачи курса. В информационном обществе, материальной базой которого является информационная экономика, акцент значимости смещается на информационный ресурс, представляющий собой знания, накопленные людьми для социального использования в обществе. Эти знания зафиксированы и материализованы в виде документов, баз данных, баз знаний, алгоритмов, компьютерных программ, произведений литературы, науки, искусства. Информационные ресурсы рассматриваются как стратегические ресурсы страны, региона, организации. Для каждой страны переход в новую эпоху экономического развития, в основе которой лежит использование многообразных информационных ресурсов, определяется степенью информатизации ее экономики и общества в целом. Информатизация экономики предполагает не совершенствование технологии на отдельных участках экономической системы, а перевод экономики на принципиально иные основы информационной технологии. В Казахстане необходимо параллельно решать проблемы перехода к рыночной экономике и внедрения информационной технологии. Образно говоря, потребуется сразу пройти и через «ад» рыночной экономики, и через «чистилище» информационной экономики. Достижение высоких экономических и социальных результатов, повышение доли Казахстана в мировой экономической системе до полноправного партнерства в значительной степени зависят от масштабов и темпов информатизации общества, использования информационных технологий во всех сферах человеческой деятельности. Информатизацию можно рассматривать как процесс преобразования производственнохозяйственных, научных и социально-бытовых структур путем производства информации, необходимой для выработки и реализации решений, направленных на достижение качественно новых результатов деятельности человека, на базе внедрения и использования средств вычислительной техники, связи и информационных технологий. Несмотря на различие процессов информатизации в разных областях человеческой деятельности, в единую систему ее объединяют три составляющие: единство основных средств производства (средства вычислительной техники и информатики); единство сырья (данные, подлежащие анализу и обработке); единство выпускаемой продукции (информация, используемая для управления и совершенствования деятельности человека). Инфраструктура информатизации включает: - системы коммуникаций, вычислительных машин и сетей, программное обеспечение этих систем; - информационные средства; - систему подготовки кадров для эксплуатации аппаратного, программного и информационного обеспечения; - экономические и правовые механизмы, обеспечивающие и способствующие эффективному развитию процесса информатизации. Ключевая роль в современной инфраструктуре информатизации принадлежит системам коммуникаций и вычислительным сетям, в которых сосредоточены новейшие средства вычислительной техники, информатики, связи, а также самые прогрессивные информационные технологии. Именно они обеспечивают пользователям широкий набор информационно-вычислительных услуг с доступом к локальным и удаленным машинным ресурсам, технологиям и базам данных. Термин «система» происходит от греческого слова systema, что означает целое, составленное из частей или множества элементов, связанных друг с другом и образующих определенную целостность, единство. Под системой понимается совокупность связанных между собой и с внешней средой элементов или частей, функционирование которых направлено на получение конкретного полезного результата. Система - это любой объект, который рассматривается, с одной стороны, как единое целое, а с другой стороны, как множество связанных между собой и взаимодействующих составных частей. Систему определяют: - структура - множество элементов системы и их взаимосвязей. Математической моделью структуры является граф; - входы и выходы - материальные потоки или потоки сообщений, поступающие в систему и выводимые ею; - поведение системы, описываемое неким законом. Основные свойства системы: - сложность (зависит от входящих в нее компонентов, их структурного взаимодействия); - делимость (означает, что она состоит из ряда подсистем или элементов, выделенных по определенному признаку); - целостность (означает, что функционирование множества элементов системы подчинено одной цели); - многообразие элементов и различие их природы (связано с их функциональной специфичностью и автономностью); - структурированность (определяет наличие установленных связей и отношений между элементами внутри системы, распределение элементов по уровням иерархии). Система – это организованное множество, образующее целостное единство, направленное на достижение определенной цели. Другими словами, система есть совокупность элементов, взаимосвязанных друг с другом и, таким образом, образующих определенную целостность. Количество элементов, из которых состоит система, может быть любым, важно, чтобы они были между собой взаимосвязаны. Примеры систем – техническая, из узлов и деталей; живой организм, состоящий из клеток; коллектив людей; предприятие; государство и т.д. Лекционная аудитория с лектором и студентами – система; каждый студент - тоже система; оборудование аудитории – система; отдельный стол - тоже система. Для того чтобы в материальном мире происходили обмен информацией, ее преобразование и передача, должны быть носитель информации, передатчик, канал связи, приемник и получатель информации. Среда передачи объединяет источник и получателя информации в информационную систему (Рисунок 1) Источник информации Передатчик Канал связи Приемник Пользователь информации Рисунок 1. Информационная система На пути развития электронной вычислительной техники (начиная с середины 40-х годов) можно выделить четыре поколения больших ЭВМ, отличающихся элементной базой, функционально-логической организацией, конструктивно-технологическим исполнением, программным обеспечением, техническими и эксплуатационными характеристиками, степенью доступа к ЭВМ со стороны пользователей. Смене поколений сопутствовало изменение основных технико-эксплуатационных и технико-экономических показателей ЭВМ, и в первую очередь таких, как быстродействие, емкость памяти, надежность и стоимость. При этом одной из основных тенденций развития было и остается стремление уменьшить трудоемкость подготовки программ решаемых задач, облегчить связь операторов с машинами, повысить эффективность использования последних. Это диктовалось и диктуется постоянным ростом сложности и трудоемкости задач, решение которых возлагается на ЭВМ в различных сферах применения. Возможности улучшения технико-эксплуатационных показателей ЭВМ в значительной степени зависят от элементов, используемых для построения их электронных схем. Поэтому при рассмотрении этапов развития ЭВМ каждое поколение обычно в первую очередь характеризуется используемой элементной базой. Основным активным элементом ЭВМ первого поколения являлась электронная лампа, остальные компоненты электронной аппаратуры — это обычные резисторы, конденсаторы, трансформаторы. Для построения оперативной памяти ЭВМ уже с середины 50-х годов начали применяться специально разработанные для этой цели элементы — ферритовые сердечники с прямоугольной петлей гистерезиса. В качестве устройства ввода-вывода сначала использовалась стандартная телеграфная аппаратура (телетайпы, ленточные перфораторы, трансмиттеры, аппаратура счетно-перфорационных машин), а затем специально для ЭВМ были разработаны электромеханические запоминающие устройства на магнитных лентах, барабанах, дисках и быстродействующие печатающие устройства. Машины первого поколения имели внушительные размеры, потребляли большую мощность, имели сравнительно малое быстродействие, малую емкость оперативной памяти, невысокую надежность работы и недостаточно развитое программное обеспечение. В ЭВМ этого поколения были заложены основы логического построения машин и продемонстрированы возможности цифровой вычислительной техники. На смену лампам в машинах второго поколения (в конце 50-х годов) пришли транзисторы. В отличие от ламповых ЭВМ транзисторные машины обладали большими быстродействием, емкостью оперативной памяти и надежностью. Существенно уменьшились размеры, масса и потребляемая мощность. Значительным достижением явилось применение печатного монтажа. Повысилась надежность электромеханических устройств ввода-вывода, удельный вес которых увеличился. Машины второго поколения обладали большими вычислительными и логическими возможностями. Особенность машин второго поколения — их дифференциация по применению. Появились машины для решения научно-технических и экономических задач, для управления производственными процессами и различными объектами (управляющие машины). В период развития и совершенствования машин второго поколения наравне с однопрограммными появились многопрограммные (мультипрограммные) ЭВМ. В отличие от однопрограммных машин, в которых программы выполняются только поочередно, в многопрограммных ЭВМ возможна совместная реализация нескольких программ за счет организации параллельной работы основных устройств машины. Третье поколение ЭВМ (в конце 60-х — начале 70-х годов) характеризуется широким применением интегральных схем. Интегральная схема представляет собой законченный логический функциональный блок, соответствующий достаточно сложной транзисторной схеме. Благодаря использованию интегральных схем удалось существенно улучшить технические и эксплуатационные характеристики машин. Этому способствовало также применение многослойного печатного монтажа. Программное обеспечение машин третьего поколения получило дальнейшее развитие, особенно это касается операционных систем. Развитые операционные системы многопрограммных машин, снабженных периферийными устройствами ввода-вывода с автономными пультами абонентов, обеспечивают управление работой ЭВМ в различных режимах: пакетной обработки, разделения времени, запрос-ответ и др. В машинах третьего поколения существенно расширены возможности по обеспечению непосредственного доступа к ним со стороны абонентов, находящихся на различных, в том числе и значительных (десятки и сотни километров), расстояниях. Удобство общения абонента с машиной достигается за счет развитой сети абонентских пунктов, связанных с ЭВМ информационными каналами связи, и соответствующего программного обеспечения. При разработке машин третьего поколения применяются различные методы автоматизации проектирования. Основной объем документации, необходимой для монтажа, разрабатывается с помощью ЭВМ. Для машин четвертого поколения (конец 70-х годов) характерно применение больших интегральных схем (БИС). Высокая степень интеграции способствует увеличению плотности компоновки электронной аппаратуры, повышению ее надежности и быстродействия, снижению стоимости. Это, в свою очередь, оказывает существенное воздействие на логическую структуру ЭВМ и ее программное обеспечение. Более тесной становится связь структуры машины и ее программного обеспечения, особенно операционной системы. Кроме указанных выше больших ЭВМ, со второй половины 50-х годов начали развиваться мини-ЭВМ, отличающиеся меньшими функциональными возможностями главным образом из-за ограниченного набора команд и меньшей разрядности чисел, представляющих обрабатываемые данные. С появлением в США микропроцессоров (1971 г.) начал развиваться новый класс вычислительных машин — микроЭВМ. За короткое время микропроцессоры прошли большой путь развития: от первого поколения 4- и 8-разрядных микропроцессоров, выполненных по р-канальной МОП-технологии, до четвертого поколения 32- и 64-разрядных микропроцессоров. В настоящее время реализуется программа по разработке в ближайшие 8—10 лет новых типов компьютеров: - многопроцессорных компьютеров с высокой степенью параллелизма обработки информации; - компьютеров с нейронными сетями; - компьютеров, в которых для передачи информации используется свет. Появление персональных компьютеров — наиболее яркое событие в области вычислительной техники, это динамично развивающийся сектор отрасли. С внедрением компьютеров решение задач информатизации общества поставлено на реальную основу. Кроме того, потребовался новый подход к организации систем обработки данных, к созданию новых информационных технологий. Возникла необходимость перехода от систем централизованной обработки данных к системам распределенной обработки данных, т.е. к компьютерным (вычислительным) сетям различных уровней — от локальных до глобальных. Целью курса «Архитектура информационных систем» является изучение архитектур информационных систем (ИС), используемых на предприятиях, разработанных на основе новейших компьютерных технологий, вопросов выбора архитектуры ИС, дальнейшей реализации информационной системы на основе заданной архитектуры и подготовка их к эффективному использованию современных компьютерных систем в будущей профессиональной деятельности. Задачи изучения дисциплины. Основными задачами изучения дисциплины «Архитектура информационных систем», позволяющими реализовать поставленную цель являются знание современных архитектур информационных систем, программных компонентов, реализующих информационные системы различных архитектур, особенностей функционирования информационных систем, реализованных в различных информационно-коммуникационных технологиях. Изучив дисциплину, магистрант должен: - уметь выбирать архитектуру информационной системы; - проектировать программные компоненты информационной системы; - использовать современные технологии реализации ИС различной архитектуры; - иметь навыки комплексного практического проектирования ИС различной архитектуры, обеспечивающих эффективное функционирование ИС, с использованием современных технологий; - ориентироваться на частые изменения поколений компьютерных систем и информационных технологий. Иметь представление: о современных архитектурах информационных систем, программных компонентах, реализующих информационные системы различных архитектур, об особенностях функционирования информационных систем, реализованных в различных областях применения, о технологических решениях организации взаимодействия между компонентами информационных систем разных архитектур, о принципах функционирования и реализации информационных систем различной архитектуры. 1.2 Понятие архитектуры информационных систем Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС. Компоненты информационной системы по выполняемым функциям можно разделить на три слоя: слой представления, слой бизнес-логики и слой доступа к данным. Слой представления - все, что связано с взаимодействием с пользователем: нажатие кнопок, движение мыши, отрисовка изображения, вывод результатов поиска и т.д. Бизнес логика - правила, алгоритмы реакции приложения на действия пользователя или на внутренние события, правила обработки данных. Слой доступа к данным - хранение, выборка, модификация и удаление данных, связанных с решаемой приложением прикладной задачей Современные программные приложения и информационные системы достигли такого уровня развития, что термин "архитектура" в применении к ним уже давно не удивляет. Грамотно построить информационную систему, эффективно и надежно функционирующую не проще, чем сконструировать и возвести современное многофункциональное здание [1]. Когда речь заходит об "архитектуре информационной системы", обычно не возникает недостатка в определениях. Есть даже Web-сайты, которые собирают такие определения [2]. Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов ИС [4]. Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы [5]. Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними [7]. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы [9]. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания. Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некоторому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования. Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие. Рассмотрим классификацию программных систем по их архитектуре: Централизованная архитектура; Архитектура "файл-сервер"; Двухзвенная архитектура "клиент-сервер"; Многозвенная архитектура "клиент-сервер"; Архитектура распределенных систем; Архитектура Веб-приложений; Сервис-ориентированная архитектура. 1.3 Компоненты архитектуры информационных систем Компоненты: оборудование: Физические аспекты информационной системы. программное обеспечение: программы, которые используются для управления информационной системой, например, операционных систем или компьютерных программ. базы данных: Хранение данных, которые затем использовались программы для получения актуальной и достоверной информации. процедуры: политика, который управляет операциями информации. люди: каждый CBIS нуждается в людях, если он должен быть полезным, этот компонент является одним из самых выглядели более факторов при определении успеха или не информационной системы. телекоммуникации: связь между компьютерами, компьютер от человека к человеку. Основная: 1.Козлов В.А. Открытые информационные системы .-М.: Финансы и статистика,1999. 2.Петров В.Н. Информационные системыпб.Учебник.-Спб.:Питер,2002. 3.Дейт К.Введение в системы баз данных. -М.: Издательский дом «Вильямс»,2001. 4.Хомоненко А.Д.и др. Delphi7.Спб.:БХВ-Петербург,2003 5.Джеф Раскин, Интерфейс: новые направления в проектировании компьютерных систем.Пер.с анг.-Спб:Символ-Плюс,2003. Дополнительная: 1.Торрес Роберт Дж., Практическое руководство по проектированию и разработке пользовательского интерфейса.- Пер.с анг.- М.Издательский дом «Вильямс»,2002. 2.Джерол С. Секреты разработки WEB-приложений на Visual Basic 5-Спб:Питер,1998. 3.Ганаеев Р.М. Проектирование интерактивных WEB-приложений Учебное пособие.- М.: Горячая линия-Телеком,2001. 4.Косентино К.РНР. WEB-профессионалам:Пер.с анг.-К.:Издательская группа BHV,2001. 5.Будилов В.А.РНР5.Экспресс-курс.-Спб:БХВ-Петербург,2005. 6.Карпова Т.С. Базы данных:модели,разработка,реализация.-Спб.:Питер,2001. 7.Жумагалиев Б.И. Лабораторный практикум по интернет-технологиям. Учебное пособие Алматы: ААЭи С,2003. Основная литература: [1] – 1-638 c, [2] 1- 432 c. Дополнительная литература: [18] – c, [19] - c Контрольные вопросы: 1. II. Тема лекции: ИНФОРМАЦИОННЫЕ СИСТЕМЫ - МНОГОУРОВНЕВАЯ МНОГОКОМПОНЕНТНАЯ СТРУКТУРА Конспект лекции: ПЛАН: обоснование и выбор архитектуры ИС. Классификация ИС по областям применения, методам организации, масштабу реализации. 2.1 Обоснование и выбор архитектуры ИС. Информационная система - это совокупность программного обеспечения решающего определенную прикладную задачу Архитектура информационной системы - абстрактное понятие, определяющее из каких составных частей (элементов, компонент) состоит приложение и как эти части между собой взаимодействуют Под составными частями (элементами, компонентами) приложения обычно понимаются программы или программные модули выполняющие отдельные, относительно изолированные задачи Архитектура — это то, за что увольняют системного архитектора и руководителя проекта. (Кто-то может сказать, что проекты на самом деле проваливаются из-за неправильной организации процесса разработки. Не отрицая этого, скажу, что знаю существенно больше успешных систем, построенных в кривом процессе разработки, чем успешных систем с кривой архитектурой.) Между тем, слова “архитектура информационной системы” обычно довольно согласованно понимаются специалистами на уровне подсознания, и ровно столь же несогласованно определяются. Два основных класса определений архитектур — определения “конструктивные” и “идеологические”. Два основных идеологических определения архитектуры ИС таковы: Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой” Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес–технологии в рамках бизнес–видения” Оба эти определения согласованы в том смысле, что если ключевое решение приходится изменять при изменении бизнес–технологии в рамках бизнес–видения, то резко возрастает стоимость владения системой. Следствием этих определений является понимание важности принятия архитектуры системы как стандарта предприятия, ввиду значимости и стабильности архитектурных решений. Еще одно важное следствие первого определения — то, что архитектура системы на самом деле должна строиться на стадии технико–экономического обоснования системы. Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы: - что делает система; - как эти части взаимодействуют; - где эти части размещены; - на какие части она разделяется. Таким образом, архитектура ИС является логическим построением, или моделью. Как же она влияет на совокупную стоимость владения? Через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т.п. — т.е. через то, что мы называем инфраструктурой ИС. Еще раз подчеркну, что инфраструктура включает решения не только по программному обеспечению, но также и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [1]. Требования к методике выбора архитектуры ИС По всей видимости, число проектов, в которых архитектура системы сознательно выбирается, относительно невелико (в отличии от архитектуры программного обеспечения, которая, в соответствии с нашими определениями, является только частью архитектуры системы). Естественно, архитектура будет наличествовать в любом случае, другое дело, что она может не конструироваться и не выбираться сознательно. Я сознательно говорю именно о выборе, а не о разработке архитектуры. Разработка архитектуры – отдельный вопрос. В данном случае речь идет о выборе одной из архитектур-кандидатов. (То, что выбор делать надо, указывается, например, в RUP [2], но, к сожалению, там не объясняется, как это делать.) Более того, несмотря на то, что большинство методологий подчеркивают важность архитектуры (исключением является, пожалуй, XP), ни одна не дает внятной методики ее выбора. Причины этого таковы: Фирменные методики навязывают, с разной степенью настойчивости, фирменную же архитектуру и инфраструктуру (таковы, в частности, Oracle CDM и MSF); XP фактически отрицает осознание архитектуры, что оправданно для некрупных проектов, выполняемых небольшой командой (1-3 пары программистов). Вопросы разработки архитектуры довольно подробно рассматриваются в традиционных методиках. Проблемами этих подходов, на наш взгляд, являются: невозможность оценить качество разработанной архитектуры; ориентированность на архитектуру программной системы и дистанцирование от того факта, что система состоит не только из программных, но также и технических средств и людей; разделение процессов технико-экономического обоснования системы, разработки бизнес-процессов и разработки архитектуры системы; отсутствие привязки к бизнес-целям и целям использования системы. В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике выбора архитектуры. Методика должна: отражать связь архитектуры и совокупной стоимости владения; отражать итерационную природу разработки ИС; иметь своей целью выбор архитектуры системы в целом, а не только ее программной составляющей. связывать разработку архитектуры, бизнес-анализ и технико-экономическое обоснование в едином процессе; Естественным критерием выбора архитектуры и инфраструктуры ИС является минимизация совокупной стоимости владения системой. По крайней мере, такой критерий является естественным для коммерческих организаций, эффективность деятельности которых определяется по затратам и доходам. Интегральные затраты на систему могут быть полностью известны только после завершения проекта. В любой момент до завершения проекта интегральные затраты могут быть только оценены. Будем использовать характеристики и чисто технических ИТ-рисков. Для того, чтобы знать и правильно организовать описание всего набора возможных рисков, полезно опираться на некую общую модель архитектуры - как предприятия, так и его ИС. В качестве таких моделей могут применяться модели Захмана [3] или Зиндера [4]. Вопросы соответствия различных типов рисков ячейкам архтектурной модели [4] и их связям требуют дополнительной теоретической проработки. Однако и без нее знакомым с вышеуказанными моделями нетрудно будет соотнести определенные ячейки архитектуры (architecturalframework) с различными рисками и таким образом составить, назвать и описать актуальные для проекта/системы группы рисков. Мы же - в рамках данной статьи - выделим несколько наиболее значимых и принципиально различных типов рисков: проектные риски при создании системы; риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнесрисками. Каждый бизнес-риск принадлежит по крайней мере одному из вариантов бизнесиспользования системы. Например, для интернет-магазина бизнес-риски “Покупатель не может сделать заказ и уходит” и “Покупатель делает заказ, но уходит рассерженный функционированием системы” принадлежат вариантов бизнес-использования “Сделать заказ”. риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что а) бизнес-процессы надо изменять, а информационная система не готова к этому и потери связаны с неоптимальным функционированием бизнеса и б) оттого, что имеется стоимость модификации системы. Такие риски бизнес– потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу "варианты изменения" (change cases)). технические риски, состоящие в простоях, отказах, потере или искажении данных и т.п.; Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно прямолинейно. Динамические бизнес-риски количественно учесть невозможно и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными / застывшими / неустоявшимися). Наиболее интересной частью совокупной стоимости владения системой являются статические бизнес-риски и проектные риски. Каждый вариант бизнес-использования реализуется с помощью набора операций соответствующих бизнес-процессов. Соответственно, бизнес-риск возникает по причине неисполнения одной или нескольких операций бизнес-процесса — это мы называем операционными рисками. Таким образом, операционные риски являются источниками бизнес-рисков. Например, источниками риска “Покупатель не может сделать заказ и уходит” могут быть операционный риск “Информация о заказе не может быть передана для обработки в систему”. В свою очередь операционные риски для автоматизированных операций могут возникать по причине технических рисков. Например, операционный риск “Информация о заказе не может быть передана для обработки в систему” может возникнуть по причине реализации технического риска “Обрыв канала связи”. С другой стороны, бизнес-риск может быть парирован соответствующей организацией процесса и/или архитектурным решением. На основе вышесказанного получаем следующую методику выбора архитектуры ИС. Проводится описание бизнес-процессов в организации с ограниченным уровнем детальности (как правило, не пооперационно). Описание бизнес-процесса должно включать его целевые нефункциональные характеристики (частоту возникновения, продолжительность и т.п.). Результатом данного этапа может являться набор вариантов использования (Usecaseview) описания архитектуры системы в смысле RUP. На основе описания бизнес-процессов описываются бизнес-риски. Каждый бизнесриск оценивается в терминах бизнес-потерь. Это описание является параметрическим — бизнес-потери могут зависеть от продолжительности действия риска, частоты его возникновения и т.п. На основе описания бизнес-процессов описываются архитектурно-значимые функциональные модули системы. Разделение функциональности системы по функциональным модулям осуществляется исходя из инвариантности относительно деталей реализации и физического размещения отдельных модулей. Описание каждого модуля включает функции и данные, объединяемые в данный модуль. Результатом данного этапа может являться разбиение системы (Logical view) описания архитектуры системы в смысле RUP. Строятся архитектуры-кандидаты с учетом нефункциональных требований к системе и неопределенностей. Различные архитектуры-кандидаты реализуют один и тот же набор функций и функциональных модулей и отличаются только способами физического размещения и реализации этих модулей. Для каждой архитектуры-кандидата описываются: цели; основные характеристики; логическая структура (диаграмма развертывания); физическая структура (схема сети); взаимодействие модулей системы: компоненты и подсистемы ИС и их физическое расположение, синхронность/асинхронность общения между компонентами системы, выбор и определение характеристик каналов связи и т.п., выбор протоколов и программных интерфейсов, выбор типа ПО промежуточного слоя (middleware), выбор форматов документов, передаваемых в системе; Например, в проектах достаточно крупных и территориально распределенных систем рассматривается, по крайней мере, три архитектуры-кандидата: полностью централизованная система (напр., основанная на webтехнологиях); система, максимально адаптированная к офлайновой работе (основанная на сообщениях); система, максимально парирующая риски разработки (двухуровневая клиент-серверная). Выбираются необходимые для реализации архитектуры элементы инфраструктуры — аппаратные средства, операционная платформа, СУБД, инструментальные средства, прикладные комплексы. Для каждого элемента инфраструктуры рассматриваются варианты его реализации. Оценивается стоимость владения каждым элементом инфраструктуры архитектуры-кандидата в течение планового периода жизни системы. Оцениваются вероятности возникновения технических рисков в виде отказов элементов инфраструктуры архитектуры-кандидата. Например, характерными элементами архитектуры являются: центральный сервер; центральная БД; коммуникационный канал между центром и филиалом; сервер филиала; БД филиала; рабочие станции; ПО Message Oriented Middleware. Технические риски в данной архитектуре при этом относятся к одному из классов, приведенных в таблице 1. Таблица 1. Технические риски Название риска Описание Выход из строя Сбой в работе аппаратного или программного обеспечения сервера сервера. Измеряется в процентной доле времени штатного функционирования. Выход из Сбой в работе аппаратного или программного обеспечения строя рабочей рабочей станции. Измеряется в процентной доле времени штатного станции функционирования. Потеря Частичная потеря или искажение данных при передаче по или искажение каналам связи из-за сбоев в телекоммуникационном оборудовании, данных при с учетом корректирующих свойств коммуникационных протоколов. передаче Измеряется в доле потерянных либо искаженных данных. Потеря искажение данных хранении или Риск вызван возможностью сбоев в файловой системе диска или физическими ошибками на накопителях, с учетом способа при хранения данных в БД. Измеряется в среднем времени между отказами в часах (MeanTimeBetweenFailures, MTBF) Вероятности реализации каждого из технических рисков можно получить из соответствующей литературы, например, коэффициенты надежности серверов можно получить из исследований надежности соответствующих серверных платформ. Экспертные оценки тоже являются эффективным подходом определения коэффициентов надежности. На самом деле, экспертные оценки, которые мы сначала использовали, оказались весьма точны для одиночных серверов. Однако надежность кластерных решений при первоначальной экспертной оценке была нами завышена на несколько порядков. Строится матрица соответствия элементов архитектуры–кандидата и операций. На основе этой матрицы и матрицы соответствия статических бизнес-рисков и операционных рисков строится матрица соответствия технических рисков и бизнес-рисков8. Значения элементов этой матрицы получаются как количество реализаций бизнес-риска на одну реализацию технического риска. Для построения матрицы соответствия технических рисков и бизнес-рисков мы сначала строили матрицы соответствия бизнес-рисков и операционных рисков. Оказалось, что с ними невозможно работать из-за того, что операционных рисков может быть очень много — несколько сотен. Как выяснилось позднее, без этой матрицы можно обойтись. Если нашей целью является именно построенние архитектуры, то мы выводим из рассмотрения те бизнес-риски, которые во всех архитектурах-кандидатах реализуются совершенно одинаково. Мы установливаем соответствие оставшихся рисков и вариантов бизнес-использования. Поскольку указанные выше модули строились на основе агрегирования вариантов бизнес-использования в пакеты, то это одновременно дает соответствие бизнес-рисков и модулей. Логическая структура системы, устанавливающая соответствие между модулями и элементами инфраструктуры, дает соответствие бизнесрисков и элементов инфраструктуры. Технические же риски привязаны непосредственно к элементам инфраструктуры. Наконец, количественные значения элементов матрицы соответствия бизнесрисков и технических рисков получаются на основе тех же экономических моделей, которые разрабатывались для описания самих бизнес-рисков. На основе матрицы соответствия технических рисков и бизнес-рисков для каждой архитектуры-кандидата и каждого варианта инфраструктуры оценивается часть общей стоимости владения системой, ассоциированная с бизнес-рисками. Выбираются оптимальные для каждой архитектуры-кандидата элементы инфраструктуры В качестве архитектуры системы выбирается архитектура-кандидат с минимальной оценкой совокупной стоимости владения. Наш опыт показывает, что вышеприведенная методика является эффективным средством при выборе архитектуры информационной системы, а также может являться важным этапом технико-экономического обоснования системы. Требования к методике выбора архитектуры ИС По всей видимости, число проектов, в которых архитектура системы выбирается сознательно, относительно невелико (в отличие от архитектуры программного обеспечения, которая, в соответствии с нашими определениями, является только частью архитектуры системы). Естественно, архитектура будет наличествовать в любом случае, другое дело, что она может не конструироваться и не выбираться сознательно. (А то, что выбор делать надо, указывается, например, в RUP [2], но, к сожалению, там не объясняется, как это делать!) Более того, несмотря на то, что большинство методик разработки подчеркивают важность архитектуры (исключением является, пожалуй, XP), ни одна не дает внятной методики ее выбора. Причины такого положения кроются, как нам представляется, во-первых, в том, что фирменные методики навязывают с разной степенью настойчивости, фирменную же архитектуру и инфраструктуру (таковы, в частности, Oracle CDM и MSF), а XP фактически отрицает существование архитектуры, что может быть оправданно для некрупных проектов, выполняемых небольшой командой (1-3 пары программистов). А вовторых, традиционные методики: а) не позволяют оценить качество разработанной архитектуры; б) ориентированы на архитектуру программной системы и не учитывают того факта, что система состоит не только из программных, но также и из технических средств и людей; в) разделяют процессы технико-экономического обоснования системы, разработки бизнес-процессов и разработки архитектуры системы; г) не учитывают бизнес-цели и цели использования системы. В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике выбора архитектуры. Методика должна: отражать связь архитектуры и совокупной стоимости владения; связывать разработку архитектуры, бизнес-анализ и технико-экономическое обоснование в едином процессе; отражать итерационную природу разработки ИС; иметь своей целью выбор архитектуры системы в целом, а не только ее программной составляющей. Совокупная стоимость владения системой и риски Как мы уже говорили, основным критерием выбора архитектуры и инфраструктуры ИС является минимизация совокупной стоимости владения системой. По крайней мере, такой критерий кажется естественным для коммерческих организаций, эффективность деятельности которых определяется по затратам и доходам. К сожалению, интегральные затраты на систему могут быть полностью известны только после завершения проекта. До завершения проекта интегральные затраты могут быть только оценены (см. формульную оценку во врезке). Отметим, что в предложенном методе оценки затрат использована величина Рtоц— оценка потерь, связанных с бизнес-рисками в периоде t. Конечно, мы будем использовать характеристики и чисто технических ИТ-рисков. Для того чтобы знать и правильно организовать описание всего набора возможных рисков полезно опираться на некую общую модель архитектуры как предприятия, так и его ИС. В качестве таких моделей могут применяться модели Захмана [3] или Зиндера [4]. По всей видимости, с каждой из ячеек этих моделей связаны свои специфические риски. А связи этих ячеек, предусмотренные неявно в [3] или явно в [4], позволяют, например, хорошо определять связи между техническими, операционными и бизнес-рисками, которые будут разбираться далее. Кроме того, наличие временной оси в модели [4] позволяет работать не со статической «фотографией» проекта или жизни системы, но учитывать их существование во времени (имеется в виду то самое время, которое «работает» в формульных оценках затрат, приведенных на врезке). Кроме того, наличие этой оси времени позволяет вычленять бизнес-риски типа «неопределенность» (см. ниже) при рассмотрении проекта в бизнес-времени и проектные риски при рассмотрении проекта в проектном времени. Вопросы соответствия различных типов рисков ячейкам архитектурной модели [4] и их связям требуют дополнительной теоретической проработки. Однако и без нее тем, кто знаком с вышеуказанными моделями, нетрудно будет соотнести определенные ячейки архитектуры (architectural framework) с различными рисками и таким образом составить, назвать и описать актуальные для проекта/системы группы рисков. Мы же в рамках данной статьи выделим несколько наиболее значимых и принципиально различных типов рисков: проектные риски при создании системы; технические риски, состоящие в простоях, отказах, потере или искажении данных и т. п.; риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовембизнесрисками. Каждый бизнес-риск принадлежит, по крайней мере, одному из вариантов бизнес-использования (business use case) системы. Например, для интернет-магазина бизнесриски «Покупатель не может сделать заказ и уходит» и «Покупатель делает заказ, но уходит рассерженный функционированием системы» принадлежат вариантам бизнес-использования «Сделать заказ». риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что: а) бизнес-процессы надо изменять, а информационная система не готова к этому, и потери связаны с неоптимальным функционированием бизнеса; б) приходится платить за модификацию системы. Такие риски бизнес-потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу «варианты изменения», change cases). Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно стандартно. Динамические же бизнес-риски количественно учесть невозможно, и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными/застывшими/неустоявшимися). Наиболее интересная часть совокупной стоимости владения системой — статические бизнес-риски и риски разработки. Литература 1 Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504), М., Книга и бизнес, 2001 2 Rational Unified Process 2002a, Rational Software, 2002 3 J.F. Sowa, J.A. Zachman. Extending and Formalizing the Framework for Information System Architecture. IBM System Journal, vol. 31, no. 3, 1992 4 Е.З. Зиндер. "3D-предприятие" — модель трансформирующейся системы.//CWR Директору информационной службы, №4, 2000 5 Comparing Sun Solaris 8 and Microsoft Windows 2000 Server Technologies. White paper. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 09/2000 6 Total Cost of Ownership for Low-End and Mid-Range Server Clusters. A Detailed Analysis of the Total Cost of Ownership of Various RISC and Intel-Based Server Cluster Solutions. TechWise Research, 2001 7 OpenVMS: When Continuous Availability Really Matters. Harvard Research Group, 2001 8 Real-World System Availability Measurements for Compaq NonStop™ Integrity Systems. Compaq Inform №28, 1999 ЛЕКЦИЯ №3 ФУНКЦИОНАЛЬНЫЕ КОМПОНЕНТЫ ИНФОРМАЦИОННЫХ СИСТЕМ ПЛАН: понятия и определения, задачи компонент ИС различных архитектур. Содержательную основу ИС составляют ее функциональные компоненты – модели, методы и алгоритмы получения управляющей информации. Функциональная структура ИС - совокупность функциональных подсистем, комплексов задач и процедур обработки информации, реализующих функции системы управления. В системах управления крупных предприятий – корпораций, выделяются самостоятельные подсистемы (контуры) функционального и организационного уровня управления. Информационная система - это организованная человеком система сбора, хранения, обработки и выдачи информации, необходимой для эффективного функционирования субъектов и объектов управления. Данные системы являются средством удовлетворения потребностей управления в информации, которое заключается в том, чтобы в нужный момент из соответствующих источников получать информацию, которая должна быть предварительно систематизирована и определенным образом обработана. К компонентам информационной системы относятся: - информация, необходимая для выполнения одной или нескольких функций управления; - персонал, обеспечивающий функционирование информационной системы; - технические средства; - методы и процедуры сбора и переработки информации. Информационные системы делятся на три класса: - не производящие качественного изменения информации (учетные, следящие, прогнозирующие, справочные системы); - анализирующие информацию (аналитические, советующие, прогнозирующие, диагностические системы); - вырабатывающие решения (управляющие, планирующие системы). Информационные системы включают в себя функциональные компоненты, компоненты системы обработки данных, организационные компоненты. Функциональные компоненты представляют собой подсистемы обработки информационных ориентиров по определенному функциональному признаку. Например, бухгалтерский учет и отчетность; технико-экономическое планирование; бизнес-план и т.д. Компоненты системы обработки данных предназначены для сбора и переноса информации на машинные носители, ввода информации в ЭВМ и контроля ввода, создания и ведения внутримашинной информационной базы, обработки информации на ЭВМ (накопление, сортировка, корректировка, выборка, арифметическая и логическая обработка), вывода информации; управления вычислительными процессами в вычислительных сетях. Организационные компоненты информационной системы представляют собой совокупность методов и средств для совершенствования организации структурных объектов, штатного расписания, должностных инструкций персонала Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами. Автоматизированная информационная система имеет обеспечивающую и функциональную части, состоящие из подсистем (рисунок 1). Рисунок 1. Автоматизированная информационная система Подсистема – это часть системы, выделенная по какому-либо признаку. Функциональная часть информационной системы обеспечивает выполнение задач и назначение информационной системы. Фактически здесь содержится модель системы управления организацией. В рамках этой части происходит трансформация целей управления в функции, функций – в подсистемы информационной системы. Подсистемы реализуют задачи. Обычно в информационной системе функциональная часть разбивается на подсистемы по функциональным признакам: - уровень управления (высший, средний, низший); - вид управляемого ресурса (материальные, трудовые, финансовые и т.п.); - сфера применения (банковская, фондового рынка и т.п.); - функции управления и период управления. Например, информационная система управления технологическими процессами – компьютерная информационная система, обеспечивающая поддержку принятия решений по управлению технологическими процессами с заданной дискретностью и в рамках определенного периода управления. В таблице 1 указаны некоторые из возможных информационных систем, однако их достаточно для иллюстрации связи функций систем и функций управления. Таблица 1 Функции информационных систем Кадровые Финансовые и Информационная Производственные (человеческих учетные система информационные ресурсов) ининформационные маркетинга системы формационные системы системы Прочие системы, например информационная система руководства Таким образом, «функциональные компоненты» составляют содержательную основу ИС, базирующуюся на моделях, методах и алгоритмах получения управляющей информации. Функциональная структура ИС – совокупность функциональных подсистем, комплексов задач и процедур обработки информации, реализующих функции системы управления. В системе управления крупных предприятий-корпораций выделяются самостоятельные подсистемы (контуры) функционального и организационного уровня управления: 1. Стратегический анализ и управление. Это высший уровень управления, обеспечивает централизацию управления всего предприятия, ориентирован на высшее звено управления. 2. Управление персоналом. 3. Логистика – управление материальными потоками (заготовка материалов и комплектующих изделий), управление производством, управление сбытом готовой продукции. Все компоненты логистики тесно интегрированы с финансовой бухгалтерией и функционируют на единой информационной базе. 4. Управление производством. 5. Бухгалтерский учет. Информационно связан с управленческим учетом затрат в производстве, финансовым менеджментом, складским учетом. Развитые ERP-системы зарубежного производства имеют устоявшуюся структуру базовых компонентов системы управления предприятием: 1. Бухгалтерский учет и финансы. 2. Управление материалами (логистика). 3. Производственный менеджмент. 4. Обеспечение производства. 5. Управление перевозками, удаленными складами. 6. Управление персоналом. 7. Зарплата. 8. Моделирование бизнес-процессов. 9. Системы поддержки принятия решений (DSS). Обеспечивающая часть ИС состоит из информационного, математического, программного, методического, организационного, лингвистического обеспечения. В таблице 2 приведена структура и состав ИС. технического, правового и Таблица 2 Структура информационной системы. Состав информационной системы Функциональные Компоненты системы Организационные компоненты компоненты обработки данных Функциональные Информационное Новые организационные подсистемы обеспечение структуры формы Функциональные задачи Техническое обеспечение Персонал (штаты, инструкции) Модели и алгоритмы должности, Правовое обеспечение Программное обеспечение Лингвистическое обеспечение Под функциональными компонентами понимается система функций управления - полный набор (комплекс) взаимосвязанных во времени и пространстве работ по управлению необходимыми для достижения поставленных предприятием целей. Декомпозиция ИС по функциональному признаку включает в себя выделение её отдельных частей, называющихся функциональными подсистемами, реализующих систему функции управления. Функциональный признак определяет назначение подсистемы, то есть то, для какой области деятельности она предназначена, и какие основные цели, задачи и функции она выполняет. Функциональные подсистемы в существенной степени зависят от предметной области (сферы применения) ИС. При информатизации управленческой деятельности необходимо исходить из уровня решаемых задач. Для решения оперативных задач необходимо использовать информационные системы оперативного уровня, они отличаются легкой доступностью, являются постоянно действующими, предоставляющими точную информацию. К системам такого уровня можно отнести электронный журнал, базы данных по обучаемым и педагогическим работникам и другие. Информационные системы оперативного уровня являются связующим звеном между педагогической системой и внешней средой. Информационные системы тактического уровня (системы специалистов) выполняют функции интеграции новых сведений в педагогическую систему и помощь в обработке бумажных документов. К ним можно отнести систему автоматизированного составления расписания учебных занятий, библиотечный автоматизированный каталог, базы данных по педагогическим технологиям и педагогическим программным средствам и другие. Педагогическая система может обеспечить себе конкурентное преимущество, если будет учитывать внешние факторы (социальный заказ общества, региональные потребности и особенности, личностные интересы обучаемых и др.) и придерживаться следующих стратегий: создание взаимовыгодных связей с другими образовательными системами, научными институтами и предприятиями. Информационные системы такого уровня помогают решать неструктурированные задачи, они играют вспомогательную роль. К ним можно отнести информационнопоисковые системы в Internet, серверы образовательных учреждений и Министерства, серверы социальных институтов и предприятий и др. Принимая во внимание сложность процессов принятия человеком управленческих решений в педагогических системах, сформулируем возможности автоматизированных систем в данном виде деятельности. Операции приема и восприятия информации человеком зависят от функционирования органов чувств человека и могут быть автоматизированы частично. Операция принятия управленческих решений при наличии достаточной информации и заданной системы критериев может быть частично автоматизирована с помощью информационно-логических систем. Напротив, при недостатке (или избыточности) информации, отсутствии критериев и алгоритмов сравнения принятие решения полностью не может быть автоматизировано. Операции информационного характера: связанные с поиском и получением, вводом и передачей первичной информации, хранением, перекодированием информации, решением учетно-плановых задач могут быть переданы полностью автоматизированным системам. На современном этапе используются, как правило, отдельные программные средства для снятия рутинной нагрузки на управленческие структуры различного уровня. В школах, например, популярны: электронный журнал (при условии наличия школьной компьютерной сети), информационно-поисковые системы педагогической и управленческой информации (например, базы данных "Штатное расписание", "Педагогические программные средства", "Планирование", "Школьная библиотека" и др.), автоматизированные системы составления расписания, системы рейтинговой оценки деятельности преподавателей и др. Построение автоматизированных систем для автоматизации управления должна опираться, как показала практика, на следующие правила: - Использование единой информационной базы в ситуации обращения к однородной информации различными структурами учебного заведения; Правило функциональной специализации (использование локальных подсистем различного назначения и различной мощности, обусловленных специализацией); - Правило иерархического построения (необходимость создания многоуровневой структуры с предоставлением должностным лицам возможности использования информации любого уровня в пределах, предусматриваемых системой разграничения доступа); - Правило концентрации информации в базах данных (БД) в объемах, необходимых для конкретной управленческой структуры; - Правило распределенной обработки информации на автоматизированных рабочих местах (обработка данных, хранящихся в распределенных базах данных, и совместное использование ресурсов). Правило открытости, обеспечивающей дальнейшее развитие функциональных подсистем автоматизированной системы. Автоматизация управленческой деятельности осуществляется с помощью информационных систем (ИС), которые можно классифицировать следующим образом: - ИС исполнителя, - ИС руководителя структурного подразделения, - ИС вспомогательных служб, - ИС коллективного пользования, - ИС администратора сети. Выбор варианта информатизации педагогической системы может осуществляться двумя путями. Первый ориентируется на существующую структуру учебного заведения. Информатизация лишь модернизирует методы работы, приспосабливаясь к организационной структуре, при слабой коммуникации рационализируются лишь рабочие места специалистов. Недостаток - необходимость постоянного изменения формы представления информации, приспособленной к разнообразным конкретным технологическим методам. Оперативное решение «тормозится» на этапах реализации информационных технологий. Однако, минимизация затрат делают этот подход более привлекательным для большинства руководителей современных учебных заведений при выборе стратегии информатизации. Второй - ориентируется на изменение структуры учебного заведения в соответствии с деревом целей, предполагает развитие коммуникаций и разработку новых взаимосвязей. Возрастает "продуктивность" работы организационной структуры за счет рационального распределения информационных ресурсов и потоков. Основные недостатки данного подхода: существенные затраты на первом этапе, связанные с разработкой концепции и изменением структурных подразделений; психологическая напряженность, связанная с изменением структуры и штатного расписания. Достоинства: рационализация организационной структуры учебного заведения; максимальная занятость работников; интеграция профессиональных функций за счет использования компьютерных сетей. Результатами информатизации образовательного пространства целесообразно считать: уровень информатизации образовательного пространства учителя информатики, уровень образования и квалификации педагога, уровень общей информационной культуры педагога. Исходя из вышесказанного, считаем необходимым, привести обобщенную схему «Теоретико-прогностической модели информатизации образовательного пространства учителя информатики» Любая АИС функционирует в окружении внешней среды, являющейся для АИС источником входной и потребителем выходной информации. В пределах АИС, начиная со входа в систему и кончая выходом из нее, информационный поток проходит несколько этапов обработки. К основным, укрупненным этапам обработки информации относятся сбор, регистрация и первичная обработка; передача по каналу связи от источника к компьютеру; перенос на машинные носители; создание и поддержание информационных фондов; внутримашинная обработка и формирование выходных форм; передача по каналу связи от компьютера к пользователю; преобразование к виду, пригодному для восприятия пользователем. Рисунок 2. Типовая структура АИС Отдельные этапы обработки реализуются соответствующими подсистемами АИС, среди которых можно выделить следующие: сбора и первичной обработки входной информации; связи; ввода информации в компьютеры; хранения и обработки информации; выдачи информации и ее отображения (подсистема вывода). Типовая функциональная структура АИС изображена на рисунке 2. Подсистема сбора и первичной обработки выполняет ряд операций по предварительной обработке информации. В рамках этой подсистемы осуществляется сбор первичной информации об объектах, представленной в естественном для объекта виде, т.е. в словах и символах естественного языка, цифрах общепринятой системы счисления (например, содержание листа по учету кадров, результаты медицинского обследования больного, тексты статей, содержание товарно-транспортной накладной и т.п.). В результате специальной проверки осуществляется отбор тех сведений, которых еще нет в информационном фонде информационной системы. Этим предотвращается дублирование информации в системе. Элементы первичной информации, подлежащей в дальнейшем вводу в систему, подвергаются первичной обработке, т.е. приводятся к определенному виду и формату, принятым в системе: записываются на специальные бланки, заносятся в таблицы установленной формы, для документальной информации по определенным правилам составляют аннотации и библиографические описания, физические параметры приводятся к единой системе единиц. Информация, прошедшая первичную обработку и определенным образом формализованная, фиксируется на носителях, чаше всего бумажных. Информация, получаемая на выходе подсистемы сбора и первичной обработки, представлена в форме, непригодной для непосредственного ввода в компьютер. Функциями подсистемы ввода являются ввод ее в компьютер, а также контроль за правильностью переноса информации и устранение возникших ошибок. В современных компьютерах для ввода информации часто используются дисплеи и каналы связи, связанные с компьютерами через специальные сетевые средства. Информация, введенная в компьютер, размещается в машинной памяти, образуя информационный фонд информационной системы. Над элементами информационного фонда осуществляются различные операции обработки: логические и арифметические, операции сортировки и поиска, ведения и корректировки. В результате обеспечивается поддержание информационного фонда в актуальном состоянии, а также формируется выходная информация в соответствии с заданием на обработку. Формирование (структуризация) и поддержание информационных массивов, а также все операции обработки информации осуществляются под управлением комплекса программ, входящих в состав подсистемы хранения и обработки информации. Эта подсистема организует на устройствах внешней памяти размещение информации и обеспечивает доступ к ней. Подсистема хранения и обработки информации, технические средства, реализующие подсистему (в том числе и сам компьютер), а также информационные массивы объединяются в систему обработки и хранения информации (СОХИ). СОХИ включает в себя информационные массивы, способы, методы и алгоритмы их организации и обработки, соответствующий комплекс программных и технических средств. Поскольку связь СОХИ с внешней средой осуществляется с помощью средств ввода—вывода, то эти средства также необходимо учитывать при рассмотрении ряда задач, решаемых в пределах СОХИ. Подсистему обработки информации в литературе часто называют автоматизированной системой обработки данных (АСОД), считая понятие "данные" синонимичным понятию "информация". Понятие "информация" обычно используют в тех случаях, когда хотят подчеркнуть содержательный смысл сообщения. Однако компьютер, являющийся основой СОХИ, пока не способен воспринимать смысл обрабатываемых сообщений. Применительно к компьютерам чаще используют понятие "данные" и говорят, что компьютер оперирует с данными, представленными на машинных носителях. При этом данными является любой набор знаков, рассматриваемый безотносительно к его содержательному смыслу. Приписывая данным определенный смысл, их обработку воспринимают как обработку информации. Поэтому в дальнейшем изложении понятие "информация" будем преимущественно использовать в тех случаях, когда возникнет необходимость подчеркнуть важность смыслового содержания или когда оно входит в устоявшиеся словосочетания, широко используемые в отечественной литературе. Подсистема выдачи и отображения (подсистема вывода) обеспечивает выдачу ответа на запрос, представляя его в форме, удобной для восприятия пользователя. В состав подсистемы входят комплекс программ, обеспечивающих нужный вид выходного сообщения, и технические средства, на которых выходная информация фиксируется (отображается). Ответ на запрос может выводиться с помощью печатающего устройства, дисплея, графопостроителя, различных табло и индикаторов. Описание взаимосвязи подсистем производилось в предположении, что источники информации и пользователи территориально размещены вблизи центрального компьютера. В реальных ИС источники информации и (или) пользователи очень часто оказываются удаленными от центрального компьютера на расстояния от сотен метров до сотен километров. Контакт с центральным компьютером в этом случае реализуется подсистемой связи, в состав которой входят каналы передачи данных и удаленные терминалы, которые сегодня сами являются компьютерами. Для подключения удаленных терминалов – персональных компьютеров используются каналы связи, предоставляемые сетями телефонными сетями, сетями передачи данных общего пользования или специализированными сетями передачи данных. Канал должен обеспечивать обмен данными с нужной скоростью в заданном направлении. Каналы передачи данных подразделяются на симплексные, обеспечивающие передачу только в одном направлении; полудуплексные, обеспечивающие передачу в обоих направлениях, но в каждый момент времени — только в одном направлении; дуплексные, обеспечивающие одновременную передачу в обоих направлениях. Для связи источников с компьютерами можно использовать симплексные каналы. Связь пользователя с центральным компьютером или компьютерами должна осуществляться с помощью полудуплексного или дуплексного канала передачи данных, в противном случае диалог пользователя с центральным компьютером окажется невозможным. Удаленный терминал — это устройство ввода — вывода, удаленное от центрального компьютера на расстояние, исключающее возможность его непосредственного подключения. Соединение терминала с компьютером осуществляется с помощью канала передачи данных. Информация, получаемая с терминала, пригодна для непосредственного ввода в компьютер. В качестве удаленных терминалов используются персональные компьютеры, терминалы, телетайпы, специальные терминалы и абонентские пункты. Подсистема связи содержит также программу, обеспечивающую взаимную связь терминалов с центральным компьютером и позволяющую ему управлять дистанционным терминалом. ЛЕКЦИЯ №5 ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ПРИ СОЗДАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ ПЛАН: стандарты и методики разработки ИС различных архитектур. Стандарты на проектирование ИС Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов. Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнеспроцессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике. Стандартизация – технологическая основа для разработки открытых информационных систем Конкурентоспособность информационных систем, информационных технологий и отдельных программных продуктов, сложность создания и развития требуют их соответствия общепризнанным стандартам, ограничивающих фантазии и поле деятельности разработчиков. Стандартизация информационных технологий и систем повышает их прибыльность за счет снижения затрат на создание и особенно модификацию. Стандартизации подлежат: - базовые функции операционных систем; - функции управления базами данных и распределенная обработка; - функции пользовательского интерфейса; - функции взаимосвязи открытых систем; - структура данных и документов; - безопасность информационных систем и др. Стандарты разрабатываются многочисленными специализированными организациями. Существуют ассоциации и консорциумы, разрабатывающие рекомендации, полезные в деле автоматизации управленческих процессов. Стандарты в области информационных технологий можно классифицировать следующим образом: 1. По уровню утверждающей организации. Верхний уровень международные стандарты (ISP), признанные соответствующими международными комитетами. - Средний уровень - региональные стандарты, создаваемые для группы стран или континентов - Нижний уровень - национальные стандарты, действующие в рамках отдельных государств. 2. По предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла (ЖЦ) информационных систем. Объектами стандартизации являются: - процессы (Что делать?: ISO12207, ISO15288, IEEE1220); - практика (Как следует делать?: ISO15504); - источник (Какие данные использовать: ISO10303); - описание (IDEF, UML, IEEE 1471). Среди наиболее известных стандартов можно выделить следующие: - ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4]. ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5]. Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов. Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML [6]. Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений. Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. Методы структурного проектирования Структурный подход состоит в декомпозиции (разбиении) системы на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи, и т.д. Процесс разбиения продолжается вплоть до конкретных процедур. Все наиболее распространенные структурные методы базируются на следующих принципах: - принцип разбиения сложной проблемы на множество меньших независимых задач, легких для понимания и решения; - принцип организации составных частей в иерархические структуры. В рамках структурного подхода наиболее часто используемыми моделями являются: - SADT (Structured Analysis and Design Technique) – метод структурного анализа и проектирования – модели и соответствующие функциональные диаграммы, объединенные данным названием; - DFD (Data Flow Diagrams) – диаграммы потоков данных; - ERD (Entity-Relationship Diagrams) – диаграммы "сущность-связь". Интерпретация этих моделей зависит от стадии жизненного цикла разрабатываемого проекта. SADT-модели используются для моделирования бизнес-процессов на стадии формирования требований к проектируемой ИС и не предназначены для проектирования программного обеспечения. На этой стадии для отображения потоков данных обычно применяются DFD-диаграммы, а для описания данных на концептуальном уровне – ERDдиаграммы. На стадии анализа и проектирования DFD-диаграммы используются для описания структуры проектируемой системы, а ERD-диаграммы – для описания модели данных логического и физического уровней. Кроме перечисленных средств на этой стадии широко используются всевозможные структурные схемы (архитектура ИС, иерархия экранных форм, меню и т.п.). В начале 90-ых годов прошлого века в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 (http://www.idef.com). Этот стандарт принят в нескольких международных организациях, в том числе в НАТО и МВФ. С 2000г. Стандарт принят в РФ и является стандартом в области построения функциональных моделей при проектировании ИС (РД IDEF0-2000). Методы объектно-ориентированного проектирования В объектно-ориентированном проектировании используются четыре основных типа моделей: динамические, статические, логические и физические. В совокупности эти модели достаточно полны, чтобы служить технической основой для принятия решений по структуре проектируемой системы и реализации практически на любом объектноориентированном языке программирования. В объектно-ориентированном подходе рассматривается два типа иерархий: "целоечасть" и "род-вид". Этим иерархиям соответствуют такие понятия, как структура объектов и структура классов. В работах Г.Буча утверждается, что эти два типа структур представляют собой каноническую форму декомпозиции любой сложной системы. Пример взаимодействия CASE-средств На примере пакетов программ BPwin, Erwin, Rational Rose и Paradigm Plus рассмотрим возможности CASE-средств (рис. 1). CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния с PLATINUM technology они стали продаваться под новой торговой маркой. Позднее владельцем этих пакетов стала Computer Associates. BPwin – средство проектирования верхнего уровня, поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD). ERwin – средство проектирования баз данных, поддерживает стандарт IDEF1X. Paradigm Plus (Computer Associates) поддерживает язык объектно ориентированного моделирования UML. Rational Rose (фирма Rational Software) также реализует объектно-ориентированный подход на основе языка UML. Power Builder – среда разработки под СУБД Sybase. Model Mart – хранилище моделей, обеспечивает коллективный доступ и совместное моделирование, работает в архитектуре клиент-сервер; Silverrun (Silverrun technology) – Oracle Designer (Oracle) - Rational Rose (Rational Software). Комментарии к линиям связи: 1 – переход от функциональных моделей к моделям данных (автоматизирован частично); 2 – прямое проектирование базы данных под конкретную СУБД (физическое моделирование) и обратное проектирование (по имеющейся физической модели восстановление логической модели). Рис. 1 Взаимодействие CASE-средств 3 – автоматическая генерация кода приложения (клиентская часть) под наиболее популярные средства разработки (техника генерации кода различна для разных сред); 4 – сгенерированный программный код может быть выполнен в среде СУБД; 5 – связь с хранилищем моделей; 6 – прямая генерация программного кода и обратная генерация объектной модели по программному коду; 7 – прямое и обратное проектирование структуры базы данных по объектной модели. В современном движении к развитому обществу одним из необходимых условий является создание мощной инфраструктуры, в которой интегрированы вычислительные, информационные и коммуникационные ресурсы. Создание таких интегрированных систем, технологий и услуг порождает, естественно, проблему "нестыковки" технических и других средств, приводит к непроизводительным затратам, связанным, например, с проблемой переучивания персонала при освоении новых средств. Особенно это проявляется при расширении систем, необходимости включения новых компонентов, появлении новых поколений технических средств и программного обеспечения, их тиражировании и повторном использовании. Таким образом, возникла проблема поиска применения и внедрения методологии, минимизирующей эту "нестыковку", сокращающей затраты при развитии систем. Такая методология была предложена зарубежными специалистами, работающими в области информационных технологий (ИТ), - это методология открытых систем. Основным ее достоинством является сохранение вложенных ранее инвестиций при построении информационных систем (ИС) на различных аппаратных и программных платформах, обеспечение взаимосвязи систем, переносимости прикладного программного обеспечения и данных. Общие свойства открытых ИС можно определить следующим образом: расширяемость (или масштабируемость) - обеспечивается возможность добавления новых функций ИС или изменения некоторых уже имеющихся функций без изменения остальных функциональных частей ИС; - мобильность (или переносимость) - обеспечивается возможность переноса программ и данных при модернизации или замене аппаратных платформ ИС, а также возможность работы людей, пользующихся данной ИТ, без их переучивания при изменении ИС; - интероперабельность - обеспечивается способность к взаимодействию данной ИС с другими ИС; - дружественность к пользователю. По определению специалистов IEEE (The Institute of Electrical and Electronics Engineers): "Открытая система - исчерпывающий и согласованный набор международных стандартов ИТ и функциональных стандартов профилей, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала". Это определение подчеркивает аспект среды информационной системы, которую предоставляет открытая система для ее использования, а также вводит новое понятие "функциональный стандарт (профиль)", составляющий основу нового направления в стандартизации ИТ - "функциональная стандартизация", которая охватывает: - базовые стандарты, определяющие фундаментальные и общие процедуры. Они создают инфраструктуру, которая может быть использована различными приложениями, и каждое из них может выбирать собственные факультативные параметры из базовых стандартов; - профили, определяющие соответствующие подмножества или комбинации базовых стандартов, используемые для обеспечения конкретных факультативных параметров из базовых стандартов, и создающие основу для разработки унифицированных международно признанных и аттестационных тестов; механизмы регистрации, обеспечивающие средства спецификации детализированного набора параметров в рамках базовых стандартов и профилей. Обобщенная структура любой ИС представляется состоящей из двух взаимодействующих частей: функциональной части, включающей прикладные программы (приложения), реализующие функции ИС, и среды (системной части), обеспечивающей исполнение прикладных программ. Здесь можно выделить две группы стандартов: стандарты интерфейсов взаимодействия прикладных программ со средой ИС (Application Program Interface - API) и стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI). Важнейшим понятием методологии открытых систем служит профиль - набор согласованных между собой базовых стандартов для конкретного применения. Создание профиля является обязательным этапом при построении систем, отвечающих принципам открытости. Он служит эталоном при проверке (сертификации) системы и ее компонентов на соответствие требованиям открытости. Использование методологии открытых систем - сложная, многоплановая и комплексная проблема, имеющая фундаментальные, научно-методические и организационно-технические аспекты, в решении которых ключевое место занимает стандартизация и сертификация ИТ, являющихся целостным интегрированным механизмом и мощным средством управления процессами развития уровня информатизации практически во всех проблемно ориентированных областях деятельности. Вопросами методологии открытых систем в мире занимается ряд организаций, главные из которых: на мировом уровне - Совместный технический комитет ИСО и МЭК (ISO/IEC/JTC 1) - ИСО/МЭК/СТК 1 "Информационные технологии"; в Европе - Европейская рабочая группа по открытым системам (EWOS); в США - Национальный институт стандартов и технологии (NIST). Методология открытых систем поддерживается крупными компаниямиразработчиками и производителями средств вычислительной техники и средств телекоммуникаций (Digital, Hewlett-Packard, IBM, Sun Microsystems и др.), компаниями пользователями информационных систем и, естественно, компаниями-интеграторами, занимающимися созданием, развитием и поддержкой информационных систем. С целью развития и использования методологии открытых систем эти компании объединяются в различного рода консорциумы. Одним из наиболее известных объединений следует считать COS (Cooperation for Open System), в которое входят такие известные компании, как "Dupon", "Duglas", "General Electric", "General Motors", крупнейшие банки, нефтяные компании, NASA (National Aero-Space Agency) и др. Базовые стандарты для сложных объектов (взаимосвязь открытых систем (ВОС), машинная графика, текстовые и деловые системы, телекоммуникации и интерфейсы, носители данных, языки программирования и т.д.) по составу требований многовариантны и при конкретном использовании для реальных объектов ставят перед разработчиками и изготовителями определенную проблему выбора конкретного варианта применения НД в реальной системе. Подобный подход связан с наличием на рынке средств информатизации, различных по своим архитектурным, программным и техническим решениям. Проблема их взаимосвязи в системах и вызвала появление базовых НД. Для устранения определенного противоречия между мульвариантностью базовых стандартов и необходимостью выбора конкретного подмножества для реальных систем была разработана методология многоэтапной стандартизации. Эта методология, как было сказано выше, получила название "функциональной стандартизации". Данная методология включает в себя пять основных этапов. Этап 1.Разработка базовых стандартов. Базовые стандарты образуют массив, который может быть использован для выполнения широкого круга функций. Этап 2.Разработка функциональных стандартов. Основу функциональных стандартов образуют профили, представляющие собой подмножества базовых стандартов, ориентированных на работу в конкретных конфигурациях реальных объектов и конкретных применениях. Функциональные стандарты (ФС) представляют собой нормативные документы по стандартизации, каждый из которых содержит определение одного или нескольких профилей. Таким образом, обобщенно можно определить, что ФС является "справочником-путеводителем" по применимости базовых стандартов к конкретным приложениям и реальным системам. Одной из наиболее важных функций ФС является создание основы для построения комплектов аттестационных тестов, предназначенных для определения соответствия систем реальным стандартам. Этап 3.Формализованное описание протоколов, их тестирование. Данный этап связан с необходимостью тестирования (верификации) стандартов ввиду их сложности и возможности неоднозначной интерпретации. Результатом этого этапа является обратная связь с первым этапом для коррекции базовых стандартов. Этап 4.Реализация- это применение стандартов в конкретных технических и технологических решениях. Этап 5.Проверка реализации на соответствие стандартам. Этот этап включает в себя аттестационное тестирование, являющееся проверкой конкретных реализаций, позволяющее оценить правильность реализации требований стандартов. Следует констатировать, что реализация концепции функциональной стандартизации - новый вид деятельности в области стандартизации. Это не просто стандартизация технических требований к продукции, а стандартизация научных идей и технических методов. Процесс функциональной стандартизации, на примере практической деятельности и результатов работ в ИСО/МЭК/СТК 1, касается методологии определения профилей и их публикации в документах, называемых международными функциональными стандартами (МФС). Разработка профиля, предназначенного для обеспечения заданной функции или группы функций, заключается в выборе набора базовых стандартов и включении в профиль обязательных требований выбранных базовых стандартов и подмножеств их факультативных возможностей. От выбора состава обязательных требований и подмножеств факультативных возможностей базовых стандартов зависит совместимость компонентов, реализующих данные функции. Профили увязываются с базовыми стандартами, механизмами регистрации профилей и с аттестационными тестами систем, реализующих эти профили. Стандарты, определяющие процедуры и форматы отдельных элементов, описывают минимум обязательных функциональных возможностей и параметров, а также факультативные возможности сверх этого минимума. Для различных применений принимаются обязательные и выбираются допустимые факультативные возможности базовых стандартов, а также подходящие значения параметров, не конкретизированные в базовом стандарте. Профили не могут противоречить базовым стандартам, но могут использовать конкретные альтернативные выборы их комбинаций. Основные принципы открытых систем, средства и методы функциональной стандартизации могут быть применены в самых различных предметных проблемно ориентированных областях деятельности при создании сложных систем, технологий и услуг. Работы по развитию и применению методологии открытых систем могут и должны стать одними из приоритетных направлений при реализации важнейших целевых федеральных программ в конкретных проблемно ориентированных областях деятельности, создании сложных систем, технологий и услуг. При этом целесообразно пользоваться едиными общими научно-методическими и организационно-техническими подходами и практическими руководствами. ЛЕКЦИЯ №6 ПРИНЦИПЫ ФУНКЦИОНИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ РАЗЛИЧНОЙ АРХИТЕКТУРЫ ПЛАН: Файл-серверная, клиент-серверная, многоуровневая архитектура ИС. Принцип разделения функций в ИС различной архитектуры. Архитектура "файл-сервер" Файл-серверные приложения – приложения, схожие по своей структуре с локальными приложениями и использующие сетевой ресурс для хранения программы и данных [13]. Функции сервера: хранения данных и кода программы. Функции клиента: обработка данных происходит исключительно на стороне клиента. Классическое представление информационной системы в архитектуре "файлсервер" представлено на рис. 1. Рисунок 1. Классическое представление архитектуры "файл-сервер" Организация информационных систем на основе использования выделенных файлсерверов все еще является распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети [14]. Конечно, основным достоинством данной архитектуры является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows Server. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Достоинства такой архитектуры [12, 13, 14]: - многопользовательский режим работы с данными; - удобство централизованного управления доступом; - низкая стоимость разработки; - высокая скорость разработки; - невысокая стоимость обновления и изменения ПО. Недостатки [12, 13, 14]: - проблемы многопользовательской работы с данными: последовательный доступ, отсутствие гарантии целостности; - низкая производительность (зависит от производительности сети, сервера, клиента); - плохая возможность подключения новых клиентов; - ненадежность системы. Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро [14]. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными. Архитектура "клиент-сервер" Клиент-сервер (Client-server) – вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемых серверами, и заказчиками услуг, называемых клиентами [15]. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением. Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture). Под клиентсерверным приложением в этом случае понимается информационная система, основанная на использовании серверов баз данных. Схематически такую архитектуру можно представить, как показано на рис. 2 [16]. Рисунок 2. Классическое представление архитектуры "клиент-сервер" На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции. Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения. Заметим, что интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения. Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL. Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL. - Сервер производит компиляцию полученного оператора. - Далее (если компиляция завершилась успешно) происходит выполнение оператора. Разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента. Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных – упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей базы данных. Здесь возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень. Преимуществами данной архитектуры являются [12, 15]: - возможность, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети; - все данные хранятся на сервере, который, как правило, защищен гораздо лучше большинства клиентов, а также на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа; - поддержка многопользовательской работы; - гарантия целостности данных. Недостатки [12, 15]: - неработоспособность сервера может сделать неработоспособной всю вычислительную сеть; администрирование данной системы требует квалифицированного профессионала; - высокая стоимость оборудования; - бизнес логика приложений осталась в клиентском ПО. При проектировании информационной системы, основанной на архитектуре "клиент-сервер", большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике. Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. Также данный вид архитектуры называют архитектурой с "толстым" клиентом. Многоуровневый "клиент-сервер" Многоуровневая архитектура клиент-сервер (Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов [15]. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных [14, 17]. Схематически такую архитектуру можно представить, как показано на рис. 3. Рисунок 3. Представление многоуровневой архитектуры "клиент-сервер" Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал. Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры. Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных. В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов. В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы. Плюсами данной архитектуры являются [12, 14, 16, 17]: - клиентское ПО не нуждается в администрировании; - масштабируемость; - конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней; - высокая безопасность; - высокая надежность; - низкие требования к скорости канала (сети) между терминалами и сервером приложений; - низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Минусы [12, 14, 16, 17]: - растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание; - более высокая сложность создания приложений; - сложнее в разворачивании и администрировании; - высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования; - высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений. Некоторые авторы (например, Мартин Фаулер [18]) представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рис. 4): 1. Представление; 2. Уровень представления; 3. Уровень логики; 4. Уровень данных; 5. Данные. Рисунок 4. Пять уровней многозвенной архитектуры "клиент-сервер" К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения. Уровень представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте логики и данных. Уровень логики содержит основные функции системы, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации уровню данных. Уровень доступа к данным – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения. Данные системы обычно хранятся в базе данных. Архитектура распределенных систем Такой тип систем является более сложным с точки зрения организации системы. Суть распределенной системы заключается в том, чтобы хранить локальные копии важных данных [19]. Схематически такую архитектуру можно представить, как показано на рис. 5. Рисунок 5. Архитектура распределенных систем Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы [16]. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных. Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям. Еще одним из преимуществ такой схемы эксплуатации и архитектуры системы, является обеспечение возможности персональной ответственности за сохранность данных. Так как данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, при использовании средств шифрования и личных аппаратных ключей исключается доступ к данным посторонних, в том числе и IT администраторов. Такая архитектура системы также позволяет организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений, можно распределить между соседними АРМами благодаря тому, что они, как правило, обладают одной информацией в своих БД и, таким образом, добиться максимальной производительности системы. Распределенные системы с репликацией Данные между различными рабочими станциями и централизованным хранилищем данных, передаются репликацией [19] (рис. 6). При вводе информации на рабочих станциях – данные также записываются в локальную базу данных, а лишь затем синхронизируются. Рисунок 6. Архитектура распределенных систем с репликацией Распределенные системы с элементами удаленного исполнения Существуют определенные особенности, которые невозможно качественно реализовать на обычной распределенной системе репликативного типа. К этим особенностям можно отнести [19]: - использование данных из сущностей, которые хранятся на удаленном сервере (узле); - использование данных из сущностей, хранящихся на разных серверах (узлах) частично; - использование обособленного функционала, на выделенном сервере (узле). У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рис. 7). Рисунок 7. Архитектура распределенных систем с удаленным исполнением Контрольные вопросы: 1. Что Вы понимаете под файл-серверным приложением? 2. В чем заключаются достоинства и недостатки файл - серверной архитектуры ИС? 3. Что Вы понимаете под архитектурой клиент-сервер? 4. В чем заключаются достоинства и недостатки архитектуры клиент-сервер? 5. На чем основан интерфейс между клиентской частью приложения и клиентской частью сервера баз данных архитектуры клиент-сервер? 6. Что Вы понимаете под многоуровневой архитектурой ИС? 7. В чем заключаются преимущества и недостатки многоуровневой архитектурой ИС? 8. Какая архитектура распространена среди многоуровневой архитектуры клиентсервер? 9. На какие три уровни подразделена многоуровневая архитектура клиент-сервер? 10. Перечислите пять уровней многозвенной архитектуры "клиент-сервер"? 11. Что Вы понимаете под архитектурой распределенных систем? 12. В чем заключаются достоинства и недостатки архитектуры распределенных систем? 13. Что Вы понимаете под распределенной системой с репликацией? 14. Что такое репликации? 15. Что Вы понимаете под распределенными системами с элементами удаленного исполнения? ЛЕКЦИИ №7,8 ФУНКЦИОНИРОВАНИЕ ИС РАЗЛИЧНОЙ АРХИТЕКТУРЫ НА ОСНОВЕ WEB-ТЕХНОЛОГИЙ ПЛАН: 1. Обзор Web-серверов. 2. Принципы функционирования и структура Web-приложений. 3. Особенности Web-приложений, публикующих БД в сетях Интернет/интранет. 4. Характеристики популярных Web-серверов: Microsoft Internet Information Server, Apache, Netscape Enterprise. Обзор Web-серверов. В настоящий момент развитие технологий Интернета идет очень быстрыми темпами. Появляется много производителей программного обеспечения для Интернета, в том числе Web-серверов. Дадим краткую характеристику наиболее распространенным Web-серверам, используемым в корпоративных сетях и в "домашних" компьютерах, которые могут применяться для публикации информации из БД. Для начала определим само понятие Web-сервера. Web-сервер — это программное средство, установленное на Web-узле глобальной или корпоративной сети и позволяющее пользователям сети получать доступ к гипертекстовым документам, расположенным на этом Web-узле. Иногда под Webсервером понимают программное обеспечение Web-сервера вместе с его аппаратной частью, т. е. компьютером, на котором Web-сервер установлен. В общем случае программное обеспечение Web-сервера может устанавливаться на компьютеры общего назначения, предназначенные для решения различных задач, не обязательно связанных с технологиями Интернета. Поэтому более корректно использовать понятие Web-сервера для обозначения только программного обеспечения, а компьютер с операционной системой и сетевой структурой называть средой работы Webсервера, или платформой. Web-серверы используются для следующих целей: - создания корпоративных сетей интранет на основе принципов Интернета, многоуровневой архитектуры и клиент-серверных технологий; - подключения корпоративных сетей интранет к Интернету для доступа к пре доставляемым в нем услугам; - публикации информации из корпоративных сетей интранет, в том числе и содержимого БД из информационных систем, функционирующих в среде интранет; - распространения собственной информации, находящейся на домашнем компьютере, создания собственного сайта. В настоящее время в Интернете функционирует большое число типов серверов, используемых для обеспечения различных функций. Кроме того, существует многочисленные однотипные серверы, разработанные различными производителями. В Интернете поддерживается ряд сайтов с информацией о серверах, содержащих ежемесячные обзоры всего, что касается данной темы. Например, один из наиболее популярных источников информации о статистике использования Web-серверов находится на узле компании Netcraft по адресу http://www.netcraft.com /survey, который помимо самой свежей информации о серверах и платформах содержит также список адресов узлов, где можно найти сведения об основных Web-серверах. На выбор сервера большое влияние оказывает платформа, на которой работает Web-сервер. Анализ различных источников показывает, что в качестве узлов Web могут работать компьютеры любых типов, имеющие достаточные ресурсы и производительность. Активно используемых типов операционных систем намного меньше, чем типов компьютеров. Статистика показывает, что для высокопроизводительных объемных узлов наиболее часто используется операционная система UNIX (около 80% Web-серверов работают под ее управлением), а для средне- и низкопроизводительных узлов чаще всего используется Windows NT (менее 20% Webсерверов). Операционные системы Web-серверов. В сети Интернет в основном используется несколько ОС. Самыми распространенными среди Web-серверов являются UNIX-подобные ОС. Операционная система UNIX и ее клоны получили наибольшее распространение в среде Интернет по следующим причинам: - UNIX может работать на значительно большем количестве платформ по сравнению с другими ОС. Она распространяется в исходных кодах, поэтому легко может быть перекомпилирована для любой аппаратной платформы. - UNIX раньше других начала применяться в Интернете. - UNIX поддерживает большое количество услуг, ориентирована на работу с большим количеством процессоров, а также адресов IP. - UNIX устойчиво работает в условиях даже весьма загруженных сетей. Естественно, за все надо платить, и в результате система UNIX является самой сложной для изучения и конфигурирования из всех существующих операционных систем. Операционные системы Windows 2000 Server и Windows NT Server широко распространены, часто используются в качестве платформы Web-серверов и являются единственными реальными конкурентами для системы UNIX. Отметим, что Windows 2000 Server представляет собой доработанный вариант Windows NT Server, включающий в себя достоинства Windows 98. Основное преимущество Windows 2000/NT Server заключается в легкости настройки и освоения работы. Поэтому для начинающих пользователей лучше начать работу в Web с одной из этих ОС. Для Web-узла с малой или средней нагрузкой операционная система Windows 2000/NT Server фирмы Microsoft работает достаточно надежно. Об этом свидетельствует тенденция роста в процентном соотношении числа Web-серверов, использующих Windows 2000/NT Server. Отметим, что другие операционные системы Windows 9X фирмы Microsoft не зарекомендовали себя как надежные платформы для Web-узла. В Windows 2000 расширены средства поддержки ОС. Так, Windows 2000 позволяет организовывать взаимодействие с Windows NT Server 3.51 и 4.0, поддерживает клиентов с операционными системами Windows 95, Windows 98 и Windows NT Workstation 4.0, с большими и средними ЭВМ с помощью шлюзов транзакций и очередей. Файловый сервер для Macintosh позволяет клиентам Macintosh организовывать общий доступ к файлам и использовать общие ресурсы Windows 2000/NT Server. Тем не менее, операционная система Windows 2000/NT Server не обеспечивет требуемую гибкость при администрировании и расширении возможностей Web-узла. Отметим, что тенденция роста использования Windows 2000/NT будет сохраняться за счет вхождения в сеть Интернет большого количества пользователей Intelкомпьютеров. Windows-ориентированные серверы могут устанавливаться и настраиваться автоматизированно, в отличие от UNIX-ориентированных Web-серверов, которые настраиваются только вручную. Операционная система MacOS используется пользователями Macintosh, работающими в Web. В настоящее время эта ОС значительно уступает по популярности Windows NT и UNIX ввиду того, что имеет ограниченные возможности по взаимодействию с динамическими узлами и не приспособлена к режиму повышенной нагрузки. MacOS не является лучшим выбором операционной системы для Web-сервера, но остается популярной среди пользователей Macintosh. Принципы функционирования и структура Web-приложений. Развитие сетей Интернет/интранет привело к появлению новой категории программ — Web-приложений. К Web-приложениям относят набор Web-страниц, сценариев и других программных средств, расположенных на одном или нескольких компьютерах (клиентских и серверных) и объединенных для выполнения прикладной задачи. При этом Web-приложения, публикующие БД в Интернет, представляют собой отдельный класс Web-приложений. Современные ИС, построенные на основе Web-приложений, использующих БД, базируются на многоуровневой клиент-серверной архитектуре и принципах функционирования Интернета. С основами данной архитектуры мы познакомились ранее. Здесь мы еще раз кратко повторим, как осуществляется работа приложений в Интернете. Web-приложения выполняются на стороне Web-сервера, который находится на Web-узлах сети Интернет. Web-сервер обрабатывает запросы браузера на получение Webстраниц и отсылает ему требуемые данные в формате Web-документов. Обмен данными в сети Интернет осуществляется на основе коммуникационного протокола TCP/IP и протокола более высокого уровня (приложений) HTTP. Упрощенная схема функционирования Web-приложения приведена на рисунке 1. TCP/ IP Рисунок 1. Упрощенная схема функционирования Web-приложения Напомним, что под Web-документом (Web-страницей) понимаются используемые в Интернете документы, созданные в форматах HTML, XML, шаблоны в форматах ASP, HTX и т. д. Для доступа к Web-страницам используются специальные клиентские программы — Web-браузеры (обозреватели), находящиеся на компьютерах пользователей Интернета. Браузер формирует запрос на получение требуемой страницы или другого ресурса с помощью адреса URL. Функции браузера заключаются в отображении Web-страниц, сгенерированных сервером или модулями расширения, и отправке запросов пользователя Web-приложению, т. е. браузер является связующим звеном между пользователем и Webприложением. При этом Web-браузер устанавливает соединение с требуемым Web-узлом, используя различные протоколы передачи данных, в частности уже рассмотренный нами протокол HTTP. Web-приложения в сетях интранет Развитие технологий глобальной сети Интернет привело к появлению новых архитектурных и технологических решений для локальных корпоративных сетей, которые также называются сетями интранет. Сети интранет построены на том же аппаратнопрограммном обеспечении, принципах и протоколах, что и сеть Интернет. В общем случае под сетью интранет понимают выделенную часть сети Интернет, в которой выполняется Web-приложение (информационная система). Применение Интернет-технологий в корпоративных интранет-сетях позволяет повысить эффективность функционирования сетей и используемых в них информационных систем. Приложения, построенные на основе интернет-технологий, характеризуются надежностью и масштабируемостью, открытостью архитектуры, простотой освоения и использования. Надежность Web-приложений базируется на программно-аппаратных средствах сети Интернет, устойчивость к сбоям которых испытана в течение многих лет. Например, наиболее популярные Web-серверы способны осуществлять обработку более 50 миллионов обращений в день без возникновения каких-либо проблем. Масштабируемость Web-приложений обеспечивается их многоуровневой архитектурой, позволяющей одно и то же Web-приложение практически без переконфигурирования выполнять в сетях интранет различной конфигурации. Открытость интранет-приложений основывается на стандартизированных протоколах и форматах документов, доступных для модификации. Простота освоения и использования интранет-приложений обусловлена применением стандартного пользовательского интерфейса на основе Web-браузера. Достаточно освоить принципы работы одного браузера, чтобы можно было работать с любыми интранет-приложениями. Кроме того, использование сетей интранет характеризуется значительным снижением затрат на обслуживание, модернизацию и наращивание сети по сравнению с традиционными корпоративными сетями, построенными на клиент-серверных технологиях. Важным достоинством сетей интранет является возможность развертывания корпоративных локальных и глобальных сетей на уже существующей инфраструктуре. При использовании Web-приложений в сети интранет может использоваться архитектура, показанная на рисунке 2. Рисунок 2. Схема функционирования Web-приложения с модулями расширения Сеть интранет в общем случае имеет различную внутреннюю структуру, причем она может и не иметь выхода в Интернет. Сегменты интранет-сети могут иметь развитую структуру, обеспечивающую разграничение доступа и конфиденциальность информации. Такая структура реализуется с помощью маршрутизаторов (устройств-коммутаторов, используемых для поиска необходимого узла сети), распределенных в пределах группы клиентов сети, либо путем использования центрального маршрутизатора и многочисленных коммутаторов. В качестве клиентских приложений в этой архитектуре выступают Web-браузеры, которые обращаются с запросами к серверу БД или к серверу приложений через Webсервер. В зависимости от используемой конфигурации Web-сервер может находиться на сервере БД или на сервере приложений. В функции Web-сервера в сети интранет входит обработка запросов Web-браузеров на получение информации из разделяемых БД, преобразование этих запросов (может выполняться модулями расширения Web-сервера) в SQL-запросы или другие форматы, понятные для сервера БД или сервера приложений. Кроме того, интранет-приложение предоставляет следующие дополнительные возможности. Удаленный доступ и управление. Концепция удаленного доступа подразумевает возможность подключения к интранет-сети извне, т. е. из любого компьютера сети Интернет. Под удаленным управлением понимается подключение к локальной сети и выполнение функциональных операций по управлению ее ресурсами с удаленного компьютера. Для реализации дистанционного управления необходимо наличие специального сервера удаленного доступа и специального программного обеспечения на удаленном компьютере. Выход в Интернет клиентов сети. При этом становятся доступными услуги, предоставляемые глобальной Сетью: получение актуальной информации в различных сферах, электронная почта, обмен данными с внешними источниками, использование приложений, находящихся в Интернете, и т. д. Сеть интранет может быть построена на основе использования Web-сервера в локальной сети или на основе услуг, предоставляемых внешним (интернетовским) Webсервером. Такие услуги, как правило, предоставляет интернет-провайдер, обеспечивающий возможность использования функций своего Web-сервера. Многие компании используют совмещенную структуру Web-серверов, при которой сама локальная сеть строится с использованием собственного Web-сервера, а выход в глобальную сеть осуществляется через Web-сервер провайдера. В настоящее время выделяют следующие принципы построения сетей интранет: - Иерархическая архитектура интранет-приложений (информация размещается иерархически сверху вниз). Для этого создают узловые серверы, на которых размещаются наиболее важные данные, используемые совместно несколькими отделами или подсетями. Серверы могут также составлять иерархическую структуру: на верхнем уровне стоит сервер с информацией, необходимой для клиентов всей сети, а на нижних уровнях находятся специализированные серверы, содержащие информацию, используемую отдельными группами клиентов. Таким образом обеспечивается максимально быстрый доступ к любой внутрисетевой информации и снижаются затраты на ее обновление. - "Двусторонняя обратная связь" с клиентами сети для обработки их запросов. При этом процесс восстановления при сбоях или перерывах в работе происходит с использованием механизма транзакций. Интранет-приложения, построенные на такой основе, называют транзакционными Web-приложениями. Их целесообразно использовать, например, при создании интернет-магазинов на базе промышленных СУБД. - Использование группового способа общения. В этом случае члены определенной группы клиентов получают доступ к установленному разделу новостей с возможностью прямого обмена информацией между собой. Доступ к разделу со стороны пользователей, не входящих в группу, ограничивается. Применение архитектуры Интернет в сетях интранет имеет следующие преимущества по сравнению с традиционными архитектурами локальных сетей: - стандартизация пользовательского интерфейса — использование браузера в качестве универсальной клиентской программы позволяет упростить процесс обучения пользователей и обслуживания клиентских компьютеров; - более удобное администрирование и конфигурирование — в сети интранет вносимые в серверах приложений и серверах БД изменения не затрагивают клиентский уровень, т. е. при изменении конфигурации БД не надо вносить изменения в компьютеры пользователей (достаточно изменить текст сценария, хранящийся на Web-сервере); - удешевление установки и лицензирования клиентских компьютеров пользователей. Для расширения возможностей клиентской части (браузера) и серверной части разрабатывают модули расширения браузера и сервера, используемые для динамического управления интерфейсными объектами (компонентами) Web-документа. Двухуровневые Web-приложения При двухуровневой архитектуре Web-приложений источник БД хранится на том же компьютере, где находится Web-сервер. Для доступа к источнику БД используются модули расширения. В простейшем случае в архитектуру Web-приложений добавляется источник БД (рисунок 5). Функционирование Web-приложения при такой архитектуре заключается в следующем. Браузер для начала работы с Web-приложением отсылает URL-адрес главной страницы приложения Web-серверу. Последний, обработав запрос URL, высылает требуемую страницу в формате HTML обратно браузеру. Эта страница несет общую информацию о Web-приложении и позволяет пользователю выбрать из предоставляемых приложением нужную ему функцию. Далее возможно несколько вариантов работы Webприложения. TCP/ IP Рисунок 5. Архитектура Web-приложения, использующего БД Если пользователю нужна определенная информация из БД, то браузер по ссылке, находящейся в загруженной HTML-странице, формирует URL-запрос к модулю расширения сервера. Используемые при этом технологии различаются в зависимости от типа Web-сервера и других особенностей Web-приложения. Например, если на Web-узле установлен Web-сервер Microsoft Internet Information Server, то это может быть технология ASP- или IDC/HTX-страниц, интерфейсы CGI или ISAPI, а если установлен сервер Apache, то интерфейс CGI. Если необходимо сформировать параметризованный URL, то на уровне браузера могут использоваться сценарии JavaScript для проверки правильности ввода параметров запроса. После того как пользователь выбрал ссылку, браузер отсылает URL Web-серверу. Для обработки запроса сервер вызывает требуемый модуль расширения и передает ему параметры URL. Модуль расширения сервера формирует SQL-запрос к БД. Из модуля расширения сервера доступ к БД может осуществляться различными способами и на основе различных интерфейсов. Например, в случае использования технологии ASP-страниц применяется объектная модель ADO, объектный интерфейс OLE DB, интерфейс ODBC. Также возможен вариант непосредственного доступа к БД. Например, в случае модуля fSAPJ, разработанного в среде Delphi, для доступа к БД может использоваться один посредник - драйвер BDE (Borland DataBase Engine), входящий в состав программных средств модуля расширения сервера. Недостатки рассмотренной двухуровневой архитектуры состоят в следующем: - повышенная нагрузка на Web-сервер, связанная с тем, что вся работа по обработке URL-запросов, извлечению информации из БД и формированию HTML-страниц выполняется Web-сервером и модулями расширения Web-сервера; - низкий уровень безопасности из-за невозможности обеспечить требуемый уровень защиты информации в БД от сбоев во время обращения к базе данных из модуля расширения сервера или конфиденциальности информации БД от администратора Webузла. Для преодоления указанных недостатков применяются Web-приложения с большим числом уровней. Web-приложения на основе CORBA Архитектура современных интернет-приложений - это трехзвенная модель с использованием клиент-серверной архитектуры и интерфейса CGI. Однако использование CGI-интерфейса для объектно-ориентированных клиентов Java неэффективно из-за того, что этот интерфейс достаточно медленный и не обладает требуемой гибкостью. Поэтому попытки некоторых фирм-разработчиков программного обеспечения серверов оживить CGI, внедряя в него серверные API, скорее всего являются тупиковыми. В настоящее время одним из перспективных направлений развития интранет-сетей является использование технологии CORBA (Common Object Request Broker Architectur общая архитектура с брокером при запросе объекта) в сочетании с апплетами Java. CORBA представляет собой шину (интерфейс) распределенных объектов с открытыми стандартами, используемую в клиент-серверных системах. Эта технология явилась результатом работы консорциума OMG (Object Management Group - группы управления объектами). Единственной конкурентноспособной технологией, обладающей аналогичными возможностями, является технология DCOM (Distributed Component Object Model - распределенная модель компонентных объектов), разработанная фирмой Microsoft. Стандарт CORBA абсолютно не зависит от платформ и операционных систем. Поскольку технология CORBA хорошо интегрирована с Java, то мы можем получить преимущества от совместного использования в трехуровневой архитектуре продуктов Delphi и JBuilder (интегрированной среды разработки на языке Java фирмы Borland). Технология Java предполагает большую гибкость при разработке распределенных приложений, но в полной мере не поддерживает технологию клиент-сервер. Интерфейс CORBA позволяет обеспечить связь переносимых приложений Java и объектов CORBA. Технология объектов CORBA предназначена для использования в Web-приложениях вместо CGI-интерфейса. В результате объединения Java-апплетов и CORBA-интерфейса появилось новое понятие - объектная модель Web, означающая использование объектных моделей различных интерфейсов (модели CORBA, ADO и др.) при построении Web-приложений. Архитектура такого многоуровневого клиент-серверного Web-приложения, построенного на основе технологии CORBA и Java, приведена на рисунке 9. На первом уровне находится клиентское приложение - браузер. В нем выполняется клиентский Java-апплет, из которого может осуществляться обращение к объектам CORBA. На втором уровне стоит Web-сервер, обрабатывающий HTTP-запросы и CORBAвызовы клиентских приложений. Третий уровень - это уровень сервера приложений. В его роли могут выступать серверы ORB (Object Request Broker - посредник запросов объектов) или распределенные объекты CORBA, функционирующие как серверы приложений промежуточного звена и выполняющие прикладные функции и набор компонентных сервисов (услуг). Серверы ORB являются унифицированными фрагментами программы, используемыми в распределенных приложениях в качестве связующего звена между клиентскими приложениями и сервером. Рисунок 9. Архитектура многоуровневого Web-приложения на основе технологии CORBA Объекты CORBA взаимодействуют с серверами БД последнего уровня, используя, например, SQL в случае реляционных БД. Кроме того, объекты CORBA на сервере могут взаимодействовать и друг с другом. В основе механизма взаимодействия между объектами CORBA лежит протокол ПОР (Internet Inter-ORB Protocol - интернет-протокол взаимодействия ORB). Протокол ПОР основывается на протоколе TCP/IP с добавленными компонентами обмена сообщениями и функционирует как общий опорный протокол при организации взаимодействия серверов ORB и объектов CORBA. В дополнение к НОР в технологии CORBA используются ESIOP-протоколы (Environment-Specific Inter-ORB Protocols - зависящие от среды протоколы взаимодействия ORB), которые применяются в специализированных сетевых средах. Java-клиент может непосредственно взаимодействовать с объектом CORBA, используя Java ORB. При этом серверы CORBA замещают уровень HTTP-сервера и выступают в качестве программного обеспечения промежуточного уровня, обеспечивая взаимодействие между объектами (object-to-object). Интерфейс CORBA ПОР функционирует в сети Интернет так же, как и протокол HTTP. Протокол HTTP в этом случае используется для загрузки Web-документов, апплетов и графики, a CORBA - для организации с помощью Java-апплетов клиентсерверных приложений. Серверный компонент CORBA предоставляет "настраиваемый" интерфейс, который можно конфигурировать с помощью визуальных средств. Объект CORBA обладает определенными функциональными возможностями, реализует инкапсуляцию свойств и методов, генерируемых объектами событий. Можно создавать целые ансамбли объектов, "стыкуя" выходные события с входными методами. Разработка таких визуальных объектов поддерживается средствами быстрой разработки приложений (RAD). В частности, CORBA-объекты поддерживаются в Delphi. На последнем, четвертом, уровне размещается сервер баз данных или другой источник данных, т. е. практически любой источник информации, к которому CORBA может получить доступ. Сюда входят мониторы процедур транзакций (ТР Monitors), MOM (Message-Oriented Middleware — промежуточное программное обеспечение, ориентированное на обмен сообщениями), ODBMS (объектные СУБД), электронная почта и т. д. В настоящий момент интерфейсы CORBA/HTTP поддерживаются почти всеми серверными платформами, включая UNIX, NT, OS/2, NetWare, MacOS, OS/400. Рассмотрим механизм функционирования Web-приложения при использовании технологии Java-апплетов и объектов CORBA. Для начала работы с Web-приложением в Web-браузер загружается главная HTMLстраница, которая содержит встроенные апплеты Java. При этом при открытии HTMLстраницы Java-апплеты и используемые в апплете Java-классы подгружаются с Webсервера. Запрос Web-серверу на поиск апплета или требуемого класса формирует браузер. Web-сервер находит апплет и загружает его в браузер в форме байт-кода. Объединение технологий CORBA, Java и Интернета обеспечивает следующие достоинства: - Масштабируемость и устойчивость Web-приложения, заключающиеся в том, что серверы Web и ORB могут взаимодействовать с использованием CORBA. При этом объекты CORBA могут выполняться на нескольких серверах, чтобы обеспечить баланс нагрузки (load-balancing) серверов для входящих клиентских запросов. Брокер ORB может отправить запрос первому доступному объекту, а также при необходимости увеличить число доступных объектов. CORBA позволяет объектам сервера действовать последовательно, используя транзакции и связанные сервисы CORBA. В отличие от технологии CORBA, интерфейс CGI при большом количестве запросов не имеет возможности распределить нагрузку между несколькими процессами или процессорами. - Гибкость архитектуры CORBA позволяет клиентам непосредственно вызвать методы на сервере. Клиенты передают параметры напрямую или генерируют их во время выполнения апплета. - CORBA расширяет возможности Java по взаимодействию с распределенными объектами. Так, для Java-апплетов не существует простого способа вызвать метод на удаленном объекте. CORBA позволяет Java-апплетам взаимодействовать с другими объектами, написанными на различных языках, и обеспечивает для них богатый набор сервисов распределенных объектов (метаданные, транзакции, безопасность, именование, коллекции и т. д.). - CORBA расширяет объектную модель Java для распределенной среды и позволяет Java-апплетам вызывать широкий спектр операций на сервере. В противоположность этому, клиенты HTTP ограничены небольшим набором операций. Приложения серверной части — это обычные объекты CORBA и доступны в любой момент времени. Поэтому нет необходимости проходить через издержки обращения к CGI-сценариям для каждого вызова. - CORBA предоставляет средства для создания трехзвенной архитектуры клиентсервер. Кроме того, технология CORBA разгружает код Java-апплетов, определенные компоненты могут быть распределены в среде клиент-сервер. Клиентская часть апплета может оставаться маленькой, что сокращает время его загрузки. Кроме CORBA, для расширения возможностей применения Web могут использоваться и другие (конкурирующие) технологии: сокеты, DCOM с ActiveX и RMI (Remote Method Invocation — механизм вызова удаленных методов) и т. п. Тем не менее, пока технология CORBA остается лидером среди всех интерфейсов распределенных объектов благодаря хорошим архитектурным и функциональным возможностям, устойчивости в работе и легкости в настройке. В частности, технология CORBA по сравнению с ближайшим ее конкурентом технологией DCOM - обеспечивает следующие преимущества: - полная и корректная реализация поддержки различных ОС; - CORBA реализована целиком на Java, в связи с чем она хорошо интегрируется с Java; - легкость конфигурирования и настройки серверов и клиентов CORBA; d корректная реализация вызовов распределенных методов; - полнота функциональной реализации динамического исследования и поддержки метаданных; - более высокая (более чем на 20%) производительность приложений; - корректная реализация механизма транзакций; - корректная реализация долговременных, или сохраняемых, объектных ссылок; - поддержка CORBA-интерфейсом URL-имен; - открытый стандарт CORBA-интерфейса. Таким образом, CORBA обеспечивает инфраструктуру распределенных объектов, что позволяет приложениям распространяться через сети, языки, границы компонентов и операционные системы. В свою очередь, Java обеспечивает инфраструктуру переносимых объектов, которые работают на всех основных опeрационных системах. То есть CORBA дает независимость от сетей, a Java - независимость от реализации. В среде Delphi 6 для поддержки технологии CORBA на странице DataSnap Палитры компонентов имеется компонент corbaconnection. Создаваемый с его помощью объект типа TCorbaConnection устанавливает соединение CORBA-клиента с удаленным сервером приложения. Названный компонент позволяет: - устанавливать начальное соединение с удаленным сервером приложения; - получать интерфейс iAppServer для сервера приложения; - получать список провайдеров на сервере приложения; - разрывать соединение с сервером приложения. После установления соединения наборы данных приложения клиента используют интерфейс IAppServer компонента соединения CORBA для связи с провайдерами на сервере приложения или для вызова интерфейса модуля данных CORBA серверов приложения. Кроме того, для создания модуля данных CORBA, к которому смогут получать удаленный доступ CORBA-клиенты, можно использовать Мастер CORBA Data Module. Модуль данных CORBA находится на сервере приложения между клиентом и сервером в среде распределенной базы данных. Вызов Мастера модуля данных CORBA выполняется через выбор пункта CORBA Data Module на вкладке Multitier диалогового окна New Items, вызываемого командой File/ New/Other. Мастер CORBA Data Module позволяет создавать два варианта экземпляров модулей данных для клиентских соединений: разделяемые (Shared Instance) и индивидуальные (Instance-per-client). В первом случае модуль данных используется всеми клиентскими соединениями. Во втором случае один модуль данных создается на одно клиентское соединение. Для создаваемого модуля данных можно выбрать один из двух вариантов обработки: однопоточный (Single-threaded) - каждый экземпляр модуля данных в текущий момент может получить только один клиентский запрос, или многопоточный (Multithreaded) - каждое клиентское соединение имеет свой собственный поток. В первом случае удается избежать конфликта запросов, но требуется защита памяти. Во втором варианте модуль данных может получить несколько клиентских вызовов одновременно, по одному на отдельный поток. При этом глобальная память и экземпляр данных должны быть защищены от конфликтов потоков. Для создания сервера CORBA, к которому смогут получать удаленный доступ CORBA-клиенты, можно использовать Мастер CORBA Object, вызов которого выполняется путем выбора пункта CORBA Object на вкладке Multitier диалогового окна New Items, вызываемого командой File/New/Other. При создании сервера с помощью Мастера CORBA Object можно выбрать такие же варианты создания экземпляров (Shared Instance и Instance-per-client) и проведения обработки (Single-threaded и Multithreaded), как и при создании модулей данных с помощью Мастера CORBA Data Module. Для организации связи программных расширений Web-сервера с БД используются современные интерфейсы доступа к данным: OLE DB, ADO и ODBC. Эти интерфейсы являются промежуточным уровнем между источником данных и приложением, в качестве которого выступают программные расширения Web-сервера. Рассмотрим особенности архитектуры Web-приложений, использующих интерфейсы доступа к данным OLE DB, ADO и ODBC. Архитектура Веб-приложений Обычно Веб-приложения создаются как приложения в архитектуре "клиентсервер", но серверная часть имеет различные архитектурные решения. Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная. Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство. Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим. Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPIприложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects). Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра. Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Вебсервером и вместо которого пользователь получает результат выполнения этих фрагментов кода. Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер. Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений. В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Вебсерверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки (WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования). Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET. Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность. Отметим, что с ростом объема используемых данных и числа посетителей Вебсайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнесобъектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект). Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRMсистемами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов. Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" (B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Вебприложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" (B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки. Отметим, что, будучи составной частью подобного решения, Веб-сервер должен уметь не только выполнять приложения и взаимодействовать с сервером приложений, но и использовать сервисы интеграции, сервисы управления приложениями и данными, а также сервисы для разработчиков. Следующим шагом эволюции Веб-приложений, помимо доступа к корпоративным данным и данным партнеров, стало получение доступа к корпоративным приложениям. Для решения этой задачи интеграции Веб-приложений с внутренними информационными системами предприятий и с приложениями, обеспечивающими взаимодействие с клиентами и партнерами, используются специальные решения, называемые корпоративными порталами. Нередко частью портального решения являются средства управления информационным наполнением Веб-сайта – ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными "вручную" не представляется возможным. Обобщая вышесказанное можно выделить основные особенности веб-архитектуры: - отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах; - возможность подключения практически неограниченного количества клиентов; - благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных; - доступность при работоспособности сервера и каналов связи; - недоступность при отсутствии работоспособности сервера или каналов связи; - достаточно низкая скорость Веб сервера и каналов передачи данных; - относительно объема данных – архитектура Веб систем не имеет существенных ограничений. Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рисунке 11. Рисунок 11. Архитектура Веб-приложений ЛЕКЦИЯ № 9 ИНТЕРФЕЙСЫ ВЗАИМОДЕЙСТВИЯ ИНФОРМАЦИОННЫХ СИСТЕМ МЕЖДУ КОМПОНЕНТАМИ ПЛАН: понятия интерфейса ИС. Компоненты взаимодействия ИС. Интерфе́йс (англ. interface — сопряжение, поверхность раздела, перегородка) — совокупность возможностей взаимодействия двух систем, устройств или программ, определённая их характеристиками, характеристиками соединения, сигналов обмена и т. п. Совокупность унифицированных технических и программных средств и правил (описаний, соглашений, протоколов), обеспечивающих взаимодействие устройств и/или программ в вычислительной системе или сопряжение между системами.[1] В случае, если одна из взаимодействующих систем — человек, чаще говорят лишь о второй системе, то есть об интерфейсе той системы, с которой человек взаимодействует. Понятие интерфейса распространяется и на системы, не являющиеся вычислительными или информационными. Примеры: вожжи — главный элемент интерфейса между лошадью и кучером, или же, — интерфейс системы «лошадь — кучер»); руль, педали газа и тормоза, ручка КПП — интерфейс (управления) автомобиля или же интерфейс системы «водитель — автомобиль»; электрические вилка и розетка являются интерфейсом энергоснабжения большинства бытовых приборов; элементы электронного аппарата (автомагнитолы, часов и т. д.) — дисплей, набор кнопок и переключателей для настройки, плюс правила управления ими — интерфейс системы «человек — машина»; клавиатура и мышь — элементы сопряжения в системе человеко-машинного интерфейса (в свою очередь, сами клавиатура и мышь имеют свои интерфейсы соединения с компьютером). Интерфейсы информационных систем Интерфейсы информационных систем условно можно разделить на 3 группы: 1) текстовые (текст-ориентированные), 2) смешанные (псевдографические), 3) графические. В качестве примера текстовых (текст-ориентированных) интерфейсов, приведём интерфейс командной строки DOS или shell-интерпретатор UNIX. Пользователь взаимодействует с ВС с помощью клавиатуры, набирая специальные команды. Для задания различных опций служат параметры. Система как ответ на действия пользователя выдает сообщения, или результат выполнения введенной команды в текстовом виде. Курсор может иметь вид мигающего прямоугольника или черточки, обозначающей место ввода. В таком режиме можно одновременно взаимодействовать лишь с одной программой. Управлять взаимодействием программ можно только с командной строки, причём проверить результат - по окончании работы. В смешанных (псевдографических) интерфейсах различают понятия "оконный" и "графический" интерфейсы. Первый базируется на принципе разделения реального окна монитора (или виртуального desktop'а намного большего размера, чем физический дисплей) на прямоугольные области, внутри каждой из которых определенная программа направляет свой вывод и откуда получает команды. Термин "графический" означает использование оконного графического интерфейса (каждое окно отображает графический интерфейс); полноэкранного режима (выполняется только одна программа, осуществляющая вывод в графическом режиме). То есть: оконный не обязательно графический, а графический не всегда оконный. Псевдографическими обозначают интерфейсы, с графическими интерфейсными элементами, например кнопками, индикаторами процесса выполнения, реализуемыми с помощью псевдографики набора ANSI, например, оболочка FAR. Псевдографический интерфейс можно отнести к промежуточному между чисто командным интерфейсом и графическим. К графическим интерфейсам относят все оконные графические системы Windows, оболочки для UNIX - KDE, GNOM, CDE, X-Window, Photon из ОС QNX, Aqua из MacOS X. Графическими они называются потому, что все элементы пользовательского интерфейса, как и сами данные в окнах, отображаются в графическом режиме, с помощью 256, 16-битной или 32-битной глубины цветового буфера. Это позволяет сформировать привлекательные с точки зрения пользователя окна, кнопки, пиктограммы, ползунки, индикаторы. Понятие окна - общее для всех этих систем. Окно - прямоугольная область экрана, куда программа выводит свои данные и откуда получает команды. Интерфейсы АИС являются, своего рода, "проекцией" интерфейсов ОС пользователя. Интерфейс должен обеспечивать: наглядность отображения информации; приближенность к естественному языку, естественным знаковым системам; возможность отображения различной - как фактографической, так и документальной информации (т.е. текста и мультимедиа содержимого); возможность работы с максимально доступным множеством источников данных без потери гибкости, причём с условием регулярности элементов управления; независимость от архитектуры системы и организации сетевых ресурсов. Пользователи или потребители информации - это животный и растительный мир, люди и технические устройства. При этом конечный пользователь (англ. "End user") - это пользователь, не работающий непосредственно с системой, но применяющий результат её функционирования. Интерфейс пользователя - это совокупность правил, методов и программно-аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. Пользовательский интерфейс часто понимают только как внешний вид программы. В действительности интерфейс пользователя включает в себя все аспекты, оказывающие влияние на взаимодействие пользователя и системы. Экран. В настоящее время сформировались следующие основные режимы представления и управления информацией на экране, которым соответствуют определенные сценарии диалога человек-ЭВМ: режим командной строки; режим форматированного экрана; режим меню. ЛЕКЦИЯ №10 ОЦЕНКА ВОПРОСОВ НАДЕЖНОСТИ, МОДЕРНИЗАЦИИ И ЗАЩИТЫ ИНФОРМАЦИИ БЫСТРОДЕЙСТВИЯ, Содержание: понятия и принципы надежности, быстродействия, модернизации и защиты информации. Понятия и принципы надежности Защитить информацию – это значит: - обеспечить физическую целостность информации, т.е. не допустить искажений или уничтожения элементов информации; - не допустить подмены (модификации) элементов информации при сохранении ее целостности; - не допустить несанкционированного получения информации лицами или процессами, не имеющими на это соответствующих полномочий; - быть уверенным в том, что передаваемая (продаваемая) владельцем информации ресурсы будут использоваться только в соответствии с обговоренными сторонами условиями. В качестве объектов защиты информации в системах обработки данных можно выделить следующие: - терминалы пользователей (персональные компьютеры, рабочие станции сети); - терминал администратора сети или групповой абонентский узел; - узел связи; - средства отображения информации; - средства документирования информации; - машинный зал (компьютерный или дисплейный) и хранилище носителей информации; - внешние каналы связи и сетевое оборудование; - накопители и носители информации. В соответствии с приведенным выше определением в качестве элементов защиты выступают блоки (порции, массивы, потоки и др.) информации в объектах защиты, в частности: - данные и программы в основной памяти компьютера; - данные и программы на внешнем машинном носителе (гибком и жестком дисках); - данные, отображаемые на экране монитора; - данные, выводимые на принтер при автономном и сетевом использовании ПК; - пакеты данных, передаваемые по каналам связи; - данные, размножаемые (тиражируемые) с помощью копировально-множительного оборудования; - отходы обработки информации в виде бумажных и магнитных носителей; - журналы назначения паролей и приоритетов зарегистрированным пользователям; - служебные. Система защиты информации - это совокупность организационных (административных) и технологических мер, программно-технических средств, правовых и морально-этических норм, направленных на противодействие угрозам нарушителей с целью сведения до минимума возможного ущерба пользователям и владельцам системы. На практике при построении системы защиты информации сложились два подхода: фрагментарный и комплексный. В первом случае мероприятия по защите направляются на противодействие вполне определенным угрозам при строго определенных условиях, например, обязательная проверка носителей антивирусными программами, применение криптографических систем шифрования и т.д. При комплексном подходе различные меры противодействия угрозам объединяются, формируя так называемую архитектуру безопасности систем. Концепция такой комплексной защиты должна удовлетворять следующей совокупности требований. Во-первых, должны быть разработаны и доведены до уровня регулярного использования все необходимые механизмы гарантированного обеспечения требуемого уровня защищенности информации. Во-вторых, должны существовать механизмы практической реализации требуемого уровня защищенности информации. В-третьих, необходимо располагать средствами рациональной реализации всех необходимых мероприятий по защите информации на базе достигнутого уровня развития науки и техники. И, наконец, в-четвертых, должны быть разработаны способы оптимальной организации и обеспечения проведения всех мероприятий по защите в процессе обработки информации. С целью построения концепции, удовлетворяющей всей совокупности перечисленных требований, в последнее время рядом отечественных ученых активно разрабатывается теория защиты информации, которая предполагает систему концептуальных решений следующего состава: - введение понятия функции защиты и формирование полного множества функций; - введение понятия задачи защиты и формирование репрезентативного множества задач; - введение понятия средств защиты и обоснование возможностей создания достаточного арсенала таких средств; - введение понятия и обоснование методологии управления функционированием систем защиты информации. Средства защиты информации в автоматизированных системах Для решения любой задачи в АС должны быть предусмотрены адекватные по содержанию и достаточные по количеству средства. К настоящему времени разработан весьма представительный по номенклатуре арсенал различных средств защиты информации. Множество разнообразных возможных средств защиты определяется, прежде всего, способами воздействия на дестабилизирующие факторы или порождающие их причины. Принято выделять следующие классы средств защиты. Организационно-административные средства защиты информации сводятся к регламентации доступа к информационным и вычислительным ресурсам, функциональным процессам систем обработки данных, к регламентации деятельности персонала и др. Их цель - в наибольшей степени затруднить или исключить возможность реализации угроз безопасности. Наиболее типичные организационно-административные средства: - создание контрольно-пропускного режима на территории, где располагаются средства обработки информации; - изготовление и выдача специальных пропусков; - мероприятия по подбору персонала, связанного с обработкой данных; - допуск к обработке и передаче конфиденциальной информации только проверенных должностных лиц; - хранение магнитных и иных носителей информации, представляющих определенную тайну, а также регистрационных журналов в сейфах, не доступных для посторонних лиц; - организация защиты от установки прослушивающей аппаратуры в помещениях, связанных с обработкой информации; - организация учета использования и уничтожения документов (носителей) с конфиденциальной информацией; - разработка должностных инструкций и правил по работе с компьютерными средствами и информационными массивами; - разграничение доступа к информационным и вычислительным ресурсам должностных лиц в соответствии с их функциональными обязанностями. Технические средства защиты призваны создать некоторую физически замкнутую среду вокруг объекта и элементов защиты. В этом случае используются такие мероприятия: - установка средств физической преграды защитного контура помещений, где ведется обработка информации (кодовые замки; охранная сигнализация - звуковая, световая, визуальная без записи и с записью на видеопленку); - ограничение электромагнитного излучения путем экранирования помещений, где происходит обработка информации, листами из металла или специальной пластмассы; - осуществление электропитания оборудования, отрабатывающего ценную информацию, от автономного источника питания или от общей электросети через специальные сетевые фильтры; - применение, во избежание несанкционированного дистанционного съема информации, жидкокристаллических или плазменных дисплеев, струйных или лазерных принтеров соответственно с низким электромагнитным и акустическим излучением; - использование автономных средств защиты аппаратуры в виде кожухов, крышек, дверец, шторок с установкой средств контроля вскрытия аппаратуры. Программные средства и методы защиты активнее и шире других применяются для защиты информации в персональных компьютерах и компьютерных сетях, реализуя такие функции защиты, как разграничение и контроль доступа к ресурсам; регистрация и анализ протекающих процессов, событий, пользователей; предотвращение возможных разрушительных воздействий на ресурсы; криптографическая защита информации; идентификация и аутентификация пользователей и процессов и др. В настоящее время наибольший удельный вес в этой группе мер в системах обработки информации составляют специальные пакеты программ или отдельные программы, включаемые в состав программного обеспечения с целью реализации задач по защите информации. Технологические средства защиты информации - это комплекс мероприятий, органично встраиваемых в технологические процессы преобразования данных. Среди них: - создание архивных копий носителей; - ручное или автоматическое сохранение обрабатываемых файлов во внешней памяти компьютера; - регистрация пользователей компьютерных средств в журналах; - автоматическая регистрация доступа пользователей к тем или иным ресурсам; - разработка специальных инструкций по выполнению всех технологических процедур и др. К правовым и морально-этическим мерам и средствам защиты относятся действующие в стране законы, нормативные акты, регламентирующие правила обращения с информацией и ответственность за их нарушение; нормы поведения, соблюдение которых способствует защите информации. Для обеспечения безопасности информационных ресурсов, устранения возможности несанкционированного доступа, усиления контроля санкционированного доступа к конфиденциальной либо к подлежащей засекречиванию информации, внедряются различные системы опознавания, установления подлинности объекта (субъекта) и разграничения доступа. В основу построения таких систем закладывается принцип допуска и выполнения только таких обращений к информации, в которых присутствуют соответствующие признаки разрешенных полномочий. Ключевыми понятиями в этой системе являются "идентификация" и "аутентификация". Идентификация - это присвоение какому-либо объекту или субъекту уникального имени или образа. Аутентификация - это установление подлинности, т.е. проверка, является ли объект (субъект) действительно тем, за кого он себя выдает. Конечная цель процедур идентификации и аутентификации объекта (субъекта) допуск его к информации ограниченного пользования в случае положительной проверки либо отказ в допуске в случае отрицательного исхода проверки. Объектами идентификации и аутентификации могут быть: - люди (пользователи, операторы и др.); - технические средства (мониторы, рабочие станции, абонентские пункты); - документы (ручные, распечатки и др.); - магнитные носители информации; - информация на экране монитора, табло и др. Один из наиболее распространенных методов аутентификации - присвоение лицу или другому имени пароля и хранение его значения в вычислительной системе. Пароль - это совокупность символов, определяющая объект (субъект). При выборе пароля возникают вопросы о его размере, стойкости к несанкционированному подбору, способам его применения. Естественно, чем больше длина пароля, тем большую безопасность будет обеспечивать система, ибо потребуются большие усилия для его отгадывания. При этом выбор длины пароля в значительной степени определяется развитием технических средств, их элементной базой и быстродействием. Более широкое распространение нашли физические методы идентификации с использованием носителей кодов паролей. Такими носителями являются пропуска в контрольнопропускных системах; пластиковые карты с именем владельца, его кодом, подписью; пластиковые карточки с магнитной полосой, содержащей около 100 байт информации, которая считывается специальным считывающим устройством (используются как кредитные карточки, карточки для банкоматов и др.); пластиковые карты, содержащие встроенную микросхему (smart-card); карты оптической памяти и др. Одно из интенсивно разрабатываемых направлений по обеспечению безопасности информации - идентификация и установление подлинности документов на основе электронной цифровой подписи - ныне простирается от проведения финансовых и банковских операций до контроля за выполнением различных договоров. Естественно, при передаче документов по каналам связи применяется факсимильная аппаратура, но в этом случае к получателю приходит не подлинник, а лишь копия документа с копией подписи, которая в процессе передачи может быть подвергнута повторному копированию для использования ложного документа. Процессы по нарушению надежности информации можно классифицировать на случайные и злоумышленные (преднамеренные). В первом случае источниками разрушительных, искажающих и иных процессов являются непреднамеренные, ошибочные действия людей, технические сбои и др.; во втором случае – злоумышленные действия людей. К специфическим средствам защиты информации относятся криптографические методы. В АС криптографические методы защиты информации могут использоваться как для защиты обрабатываемой информации в компонентах системы, так и для защиты информации, передаваемой по каналам связи. Само преобразование информации может осуществляться аппаратными и программными средствами. Криптографическое преобразование - один из наиболее эффективных методов, резко повышающих безопасность: - передачи данных в компьютерных сетях; - данных, хранящихся в удаленных устройствах памяти; - информации при обмене между удаленными объектами. Криптография известна с древнейших времен, однако она всегда оставалась привилегией правительственных и военных учреждений. Изменение ситуации связывается с публикацией в 1949 г. книги К. Шеннона по теории информации и кибернетике, когда к криптографическим методам преобразования информации обратились многие ученые, банковские и коммерческие системы. Защита информации методом криптографического преобразования заключается в приведении ее к неявному виду путем преобразования составных частей информации (букв, цифр, слогов, слов) с помощью специальных алгоритмов либо аппаратных средств и кодов ключей. Ключ – изменяемая часть криптографической системы, хранящаяся в тайне и определяющая, какое шифрующее преобразование из возможных выполняется в данном случае. Основными методами криптографического преобразования считаются методы перестановки и замены. Суть первого метода заключается в разбиении исходного текста на блоки, а затем в записи этих блоков и чтении шифрованного текста по разным путям геометрической фигуры, например, запись исходного текста - по строкам матрицы, а чтение - по ее столбцам. Шифрование методом замены заключается в том, что символы исходного текста (блока), записанные в одном алфавите, заменяются символами другого алфавита в соответствии с принятым ключом преобразования. Комбинация этих методов породила так называемый производный шифр, обладающий сильными криптографическими возможностями. Этот комбинированный метод принят в США в качестве стандарта для шифрования. Таким образом, имеются все объективные предпосылки для разработки необходимого арсенала средств защиты. Управление информационной безопасностью Управление информационной безопасностью - это циклический процесс, включающий осознание степени необходимости защиты информации и постановку задачи: - сбор и анализ данных о состоянии информационной безопасности в организации; - оценку информационных рисков; - планирование мер по обработке рисков; - реализацию и внедрение соответствующих механизмов контроля, - распределение ролей и ответственности; - обучение и мотивацию персонала; - оперативную работу по осуществлению защитных мероприятий; - мониторинг функционирования механизмов контроля; - оценку их эффективности и соответствующие корректирующие воздействия. Система управления включает в себя: - организационную структуру, - политику, - планирование, - должностные обязанности, - практику, - процедуры, - процессы и ресурсы. Создание и эксплуатация СУИБ требует применения такого же подхода, как и любая другая система управления. Используемая в ISO 27001 для описания СУИБ процессная модель предусматривает непрерывный цикл мероприятий (Рисунок 1.2): планирование, реализация, проверка, действие (ПРПД). Процесс непрерывного совершенствования обычно требует первоначального инвестирования: документирование деятельности, формализация подхода к управлению рисками, определение методов анализа и выделение ресурсов. Эти меры используются для приведения цикла в действие. Они не обязательно должны быть завершены, прежде чем будут активизированы стадии пересмотра. На стадии планирования обеспечивается правильное задание контекста и масштаба СУИБ, оцениваются степени рисков информационной безопасности, предлагается соответствующий план обработки этих рисков. В свою очередь, на стадии реализации внедряются принятые решения, которые были определены на стадии планирования. На стадиях проверки и действия усиливают, исправляют и совершенствуют решения по безопасности, которые уже были определены и реализованы.] Планирование Требовани яи ожидаемы е результаты ИБ Требования и ожидаемые результаты ИБ Установи тьСУИБ Реализа ция Цикл разра ботки, Установка подде СУИБ ржки и улучш Проводить ения мониториг и анализ СУИБ Поддерж ивать и улучшать СУИБ Действ ие Проверка Требовани яи ожидаемы е результаты ИБ Протоколы ИБ Рисунок 1.2 - Применение модели ПРПД к процессам СУИБ Проверки могут проводиться в любое время и с любой периодичностью в зависимости от конкретной ситуации. В некоторых системах они должны быть встроены в автоматизированные процессы с целью обеспечения немедленного выполнения и реагирования. Для других процессов реагирование требуется только в случае инцидентов безопасности, когда в защищаемые информационные ресурсы были внесены изменения или дополнения, а также когда произошли изменения угроз и уязвимостей. Необходимы ежегодные или другой периодичности проверки или аудиты, чтобы гарантировать, что система Руководство организации выпускает политику безопасности, в которой вводится понятие СУИБ и провозглашаются ее основные цели: - управление непрерывностью бизнеса; - управление безопасностью. Работы по внедрению механизмов контроля включают в себя три основные составляющие: - подготовка сотрудников организации: обучение, тренинги, повышение осведомленности; - подготовка документации СУИБ: политики, стандарты, процедуры, регламенты, инструкции, планы; - подготовка свидетельств функционирования СУИБ: отчеты, протоколы, приказы, записи, журналы событий и т.п. На заключительном этапе осуществляется подготовка к сертификационному аудиту: - анализируется состояние СУИБ, - оценивается степень ее готовности к сертификации, - уточняется область и границы сертификации, - проводятся соответствующие переговоры с аудиторами органа по сертификации. и аварий информационных систем. Другие аспекты BCM выходят за рамки СУИБ. Управление доступом путем фильтрации информации Перейдем к рассмотрению мер программно-технического уровня, направленных на обеспечение информационной безопасности информационных систем предпринимательской информации. На первое место среди таких мер поставим межсетевые экраны - средство разграничения доступа, служащее для защиты от внешних угроз и от угроз со стороны пользователей других сегментов корпоративных сетей. Рисунок Отметим, что бороться с угрозами, присущими сетевой среде, средствами универсальных операционных систем не представляется возможным. Универсальная ОС это огромная программа, наверняка содержащая, помимо явных ошибок, некоторые особенности, которые могут быть использованы для получения нелегальных привилегий. Современная технология программирования не позволяет сделать столь большие программы безопасными. Кроме того, администратор, имеющий дело со сложной системой, далеко не всегда в состоянии учесть все последствия производимых изменений. Наконец, в универсальной многопользовательской системе бреши в безопасности постоянно создаются самими пользователями (слабые и/или редко изменяемые пароли, неудачно установленные права доступа, оставленный без присмотра терминал и т.п.). Единственный перспективный путь связан с разработкой специализированных защитных средств, которые в силу своей простоты допускают формальную или неформальную верификацию. Межсетевой экран как раз и является таким средством, допускающим дальнейшую декомпозицию, связанную с обслуживанием различных сетевых протоколов. Межсетевой экран - это полупроницаемая мембрана, которая располагается между защищаемой (внутренней) сетью и внешней средой (внешними сетями или другими сегментами корпоративной сети) и контролирует все информационные потоки во внутреннюю сеть и из нее. Контроль информационных потоков состоит в их фильтрации, то есть в выборочном пропускании через экран, возможно, с выполнением некоторых преобразований и извещением отправителя о том, что его данным в пропуске отказано. Фильтрация осуществляется на основе набора правил, предварительно загруженных в экран и являющихся выражением сетевых аспектов политики безопасности организации. Целесообразно разделить случаи, когда экран устанавливается на границе с внешней (обычно общедоступной) сетью или на границе между сегментами одной корпоративной сети. Соответственно, будем говорить о внешнем и внутреннем межсетевых экранах. Как правило, при общении с внешними сетями используется исключительно семейство протоколов TCP/IP. Поэтому внешний межсетевой экран должен учитывать специфику этих протоколов. Для внутренних экранов ситуация сложнее, здесь следует принимать во внимание помимо TCP/IP по крайней мере протоколы SPX/IPX, применяемые в сетях Novell NetWare. Иными словами, от внутренних экранов нередко требуется многопротокольность. Ситуация, когда корпоративная сеть содержит лишь один внешний канал, является, скорее, исключением, чем правилом. Напротив, типична ситуация, при которой корпоративная сеть состоит из нескольких территориально разнесенных сегментов, каждый из которых подключен к сети общего пользования. В этом случае каждое подключение должно защищаться своим экраном. Точнее говоря, можно считать, что корпоративный внешний межсетевой экран является составным, и требуется решать задачу согласованного администрирования (управления и аудита) всех компонентов. При рассмотрении любого вопроса, касающегося сетевых технологий, основой служит семиуровневая эталонная модель ISO/OSI. Межсетевые экраны также целесообразно классифицировать по тому, на каком уровне производится фильтрация: - канальном, - сетевом, - транспортном, - прикладном. Соответственно, можно говорить об экранирующих концентраторах (уровень 2), маршрутизаторах (уровень 3), о транспортном экранировании (уровень 4) и о прикладных экранах (уровень 7). Существуют также комплексные экраны, анализирующие информацию на нескольких уровнях. При принятии решения "пропустить - не пропустить", межсетевые экраны могут использовать не только информацию, содержащуюся в фильтруемых потоках, но и данные, полученные из окружения, например текущее время. Таким образом, возможности межсетевого экрана непосредственно определяются тем, какая информация может использоваться в правилах фильтрации и какова может быть мощность наборов правил. Вообще говоря, чем выше уровень в модели ISO/OSI, на котором функционирует экран, тем более содержательная информация ему доступна и, следовательно, тем тоньше и надежнее экран может быть сконфигурирован. В то же время фильтрация на каждом из перечисленных выше уровней обладает своими достоинствами, такими как дешевизна, высокая эффективность или прозрачность для пользователей. В силу этой, а также некоторых других причин, в большинстве случаев используются смешанные конфигурации, в которых объединены разнотипные экраны. Наиболее типичным является сочетание экранирующих маршрутизаторов и прикладного экрана. Такая конфигурация называется экранирующей подсетью. Как правило, сервисы, которые организация предоставляет для внешнего применения (например "представительский" Web-сервер), целесообразно выносить как раз в экранирующую подсеть. Помимо выразительных возможностей и допустимого количества правил качество межсетевого экрана определяется еще двумя очень важными характеристиками: - простотой применения; - собственной защищенностью. В плане простоты использования первостепенное значение имеют наглядный интерфейс при задании правил фильтрации и возможность централизованного администрирования составных конфигураций. В свою очередь, в последнем аспекте хотелось бы выделить средства централизованной загрузки правил фильтрации и проверки набора правил на непротиворечивость. Важен и централизованный сбор и анализ регистрационной информации, а также получение сигналов о попытках выполнения действий, запрещенных политикой безопасности. Собственная защищенность межсетевого экрана обеспечивается теми же средствами, что и защищенность универсальных систем. При выполнении централизованного администрирования следует еще позаботиться о защите информации от пассивного и активного прослушивания сети, то есть обеспечить ее (информации) целостность и конфиденциальность. Хотелось бы подчеркнуть, что природа экранирования (фильтрации), как механизма безопасности, очень глубока. Помимо блокирования потоков данных, нарушающих политику безопасности, межсетевой экран может скрывать информацию о защищаемой сети, тем самым, затрудняя действия потенциальных злоумышленников. Так, прикладной экран может осуществлять действия от имени субъектов внутренней сети, в результате чего из внешней сети кажется, что имеет место взаимодействие исключительно с межсетевым экраном. При таком подходе топология внутренней сети скрыта от внешних пользователей, поэтому задача злоумышленника существенно усложняется. Более общим методом сокрытия информации по топологии защищаемой сети является трансляция "внутренних" сетевых адресов, которая попутно решает проблему расширения адресного пространства, выделенного организации. Ограничивающий интерфейс также можно рассматривать как разновидность экранирования. На невидимый объект трудно нападать, особенно с помощью фиксированного набора средств. В этом смысле Web-интерфейс обладает естественной защитой, особенно в том случае, когда гипертекстовые документы формируются динамически. Каждый видит лишь то, что ему положено. Экранирующая роль Web-сервиса наглядно проявляется и тогда, когда этот сервис осуществляет посреднические (точнее, интегрирующие) функции при доступе к другим ресурсам, в частности таблицам базы данных. Здесь не только контролируются потоки запросов, но и скрывается реальная организация баз данных. ЛЕКЦИИ №11-12 ВЫБОР ТЕХНОЛОГИЙ РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ РАЗЛИЧНОЙ АРХИТЕКТУРЫ ПЛАН: Основные понятия и определения Характеристика информационной системы как объекта архитектуры. Информационные технологии являются не только объектом исследований и разработки, но и средством создания информационных систем в различных предметных областях. Несмотря на специфику конкретных объектов, удалось разработать методологию, модели, методы и средства прикладных информационных технологий, что позволяет снизить затраты и сократить сроки информатизации. Практическое использование информационных технологий тесно связано с вопросами маркетинга и менеджмента информационных ресурсов, технологий и услуг, методологией проектирования информационных систем, управления качеством и стандартизации информационных технологий. В настоящее время в целом сформировалась идеология и практика применения информационных технологий. Разнообразие задач, решаемых с помощью информационных систем (ИС), привело к появлению множества разнотипных систем, различающихся принципами построения и заложенными в них правилами обработки информации. Поэтому возникла необходимость организации информационных процессов и технологий с использованием системного подхода в основу которого положена архитектура информационных систем. Cовременные достижения в области проектирования информационных систем на основе архитектурных решений, что обеспечивает переход к промышленным методам и средствам работы с информацией в различных сферах человеческой деятельности. Это дает возможность расширения существующих методов и средств реализации информационных систем и перехода к принципиально новым, основанным на высоких технологиях. Основные понятия и определения Современные ИС и информационные технологии (ИТ) достигли такого уровня развития, когда на первый план выходит бизнес- оценка проектов, а не личные пристрастия разработчиков или заказчиков. В связи с этим большое внимание в настоящее время уделяется архитектуре информационных систем. Архитектура — структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части и условия сборки частей. Части, взаимодействующие через интерфейсы, включают классы, компоненты и подсистемы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания. Основным критерием выбора архитектуры и инфраструктуры ИС в условиях рыночной экономики является минимизация совокупной стоимости владения системой. Из этого следуют два основных тезиса. 1. В проектах построения информационных систем, для которых важен экономический эффект, необходимо выбирать архитектуру системы с минимальной совокупной стоимостью владения. 2. Совокупная стоимость владения ИС состоит из плановых затрат и стоимости рисков. Стоимость рисков определяется стоимостью бизнес- рисков, вероятностями технических рисков и матрицей соответствия между ними. Матрица соответствия определяется архитектурой ИС. Термин «архитектура информационной системы» обычно довольно согласованно понимается специалистами на уровне подсознания, но при этом и определения этого понятия неоднозначны. Имеются два основных класса определений архитектур — «идеологические» и «конструктивные». Основные идеологические определения архитектуры ИС таковы: 1. Архитектура ИС — набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой; 2. Архитектура ИС — набор ключевых решений, неизменных при изменении бизнес- технологии в рамках бизнес- видения. Эти определения объединяет то, что если ключевое решение приходится изменять при изменении бизнес- технологии в рамках бизнес- видения, то резко возрастает стоимость владения системой. Как следствие возникает понимание важности принятия архитектуры системы как стандарта предприятия ввиду значимости архитектурных решений и их устойчивости по отношению к изменениям бизнес-технологии. Важный вывод из первого определения — архитектура системы должна строиться еще на стадии технико- экономического обоснования системы. Выделим несколько наиболее значимых и принципиально различных типов рисков: • проектные риски при создании системы; • технические риски, состоящие в простоях, отказах, потере или искажении данных; • риски бизнес- потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из- за технических рисков). Такие риски бизнес- потерь назовем бизнесрисками. Каждый бизнес- риск принадлежит, по крайней мере, одному из вариантов бизнес- использования (business use case) системы. Например, для интернет- магазина бизнес- риски «Покупатель не может сделать заказ и уходит» и «Покупатель делает заказ, но уходит рассерженный функционированием системы» принадлежат вариантам бизнесиспользования «Сделать заказ»; • риски бизнес- потерь, связанные с вариативностью бизнес- процессов. При этом потери происходят оттого, что, во- первых, бизнес-процессы надо изменять, а ИС не готова к этому, и потери связаны с неоптимальным функционированием бизнеса; вовторых, приходится платить за модификацию системы. Такие риски бизнес- потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу «варианты изменения», change cases). Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно стандартно. Динамические бизнес-риски количественно учесть невозможно, и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес- процессы в организации являются определенными, застывшими или неустоявшимися). Наиболее интересная часть совокупной стоимости владения системой — статические бизнес- риски и риски разработки. Каждый вариант бизнес- использования реализуется с помощью набора операций соответствующих бизнес- процессов, а бизнес- риск возникает по причине неисполнения одной или нескольких операций. Такие риски мы называем операционными. Таким образом, операционные риски являются источниками бизнес- рисков. Например, источником риска «Покупатель не может сделать заказ и уходит» может быть операционный риск «Информация о заказе не может быть передана для обработки в систему». В свою очередь операционные риски для автоматизированных операций могут возникать по причине технических рисков. Например, операционный риск «Информация о заказе не может быть передана для обработки в систему» может возникнуть по причине реализации технического риска «Обрыв канала связи». Кроме того, бизнес- риск может быть парирован соответствующей организацией процесса и/или архитектурным решением. Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы: • что делает система?; • на какие части она разделяется?; • как эти части взаимодействуют?; • где эти части размещены? Таким образом, архитектура ИС является логическим построением, или моделью, и влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т. п. — т. е. через то, что мы называем инфраструктурой ИС. Еще раз подчеркнем, что инфраструктура включает решения не только по программному обеспечению, но и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [14]. Характеристика информационной системы как объекта архитектуры. В настоящее время не существует единого устоявшегося и общепринятого определения понятия «информационная система». Вызывает сомнение, что такое определение когда- нибудь появится. Дело в том, что информационные системы достаточно часто имеют сложную структуру и ее адекватное описание возможно только при использовании нескольких точек зрения. В качестве официального определения данного понятия можно рассматривать определение, «Информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств». Это достаточно общее определение, причем обращает на себя внимание тот факт, что во главу угла ставится понятие базы данных. Другие известные определения понятия «информационная система» часто носят еще более общий характер. Например, редакционная коллегия журнала «Information Systems», выпускаемом английским издательством Pergamon Press, определяет информационные системы как «аппаратно- программные системы, которые поддерживают приложения с интенсивной обработкой данных (Data- Intensive Applications)». Ряд авторов предлагает использовать два определения. В узком смысле ИС определяют как подмножество компонентов, включающее базы данных и приложения, т. е. ИС в узком смысле определяют как программно- аппаратную систему, предназначенную для автоматизации целенаправленной деятельности конечных пользователей и обеспечивающую, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации [8]. Еще более общую трактовку понятия ИС можно найти в [7], где дается следующее определение ИС: «информационной системой называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал, обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей». Последнее определение заслуживает отдельного внимания, поскольку в нем приведены практически все возможные точки зрения на ИС, хотя это не означает, что применительно к данной конкретной ИС действительно необходимо использовать все перечисленные точки зрения на ИС. В ИТ индустрии термин «архитектура» используется достаточно часто. Данный термин может относиться к организации, программно-аппаратному комплексу, программной системе или центральному процессору. Применительно к организации обычно используют понятие корпоративная архитектура (enterprise architecture), при этом выделяются следующие типы архитектур: бизнес- архитектура (Business architecture), ИТ- архитектура (Information Technology Architecture), архитектура данных (Data Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура (Hardware Architecture). Совокупность данных архитектур и является архитектурой ИС (рис. 1.1). Рис. 1.1. Архитектура информационной системы Бизнес- архитектура, или архитектура уровня бизнес- процессов, определяет бизнес- стратегии, управление, организацию, ключевые бизнес- процессы в масштабе предприятия, причем не все бизнес-процессы реализуются средствами ИТ- технологий. Бизнес- архитектура отображается на ИТ- архитектуру. ИТ- архитектура рассматривается в трех аспектах: • обеспечивает достижение бизнес- целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес- приложений; • среда, обеспечивающая реализацию бизнес- приложений; • совокупность программных и аппаратных средств, составляющая информационную систему организации и включающая, в частности, базы данных и промежуточное программное обеспечение. Архитектура данных организации включает логические и физические хранилища данных и средства управления данными. Архитектура данных должна быть поддержана ИТ- архитектурой. В современных ИТ- системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры — архитектуру знаний (Knowledge Architecture). Программная архитектура отображает совокупность программных приложений. Программное приложение — это компьютерная программа, ориентированная на решение задач конечного пользователя. Архитектура приложения — это описание отдельного приложения, работающего в составе ИТ- системы, включая его программные интерфейсы. Архитектура приложения базируется на ИТ- архитектуре и использует сервисы, предоставляемые ИТ- архитектурой. Техническая архитектура характеризует аппаратные средства и включает такие элементы, как процессор, память, жесткие диски, периферийные устройства, элементы для их соединения, а также сетевые средства. Часто нельзя провести четкой границы между ИТ- архитектурой и архитектурой отдельного приложения. В частности в том случае, когда некоторую функцию требуется реализовать в нескольких приложений, она может быть перенесена на уровень ИТархитектуры. Обычно приложения интегрируются средствами ИТ- архитектуры. Элементы архитектуры данных часто интегрируются в приложения. Ввиду многообразия ИС остановимся на их классификации. В последние годы все более широкое распространение получил доменный подход к описанию ИТ- архитектур. Под доменной архитектурой понимают эталонную модель, описывающую множество систем, которые реализуют похожую структуру, функциональность и поведение. Доменную архитектуру можно рассматривать как метамодель, описывающую множество решений. Схемы классификации архитектур ИС, основанные на доменном подходе, показанf на рис. 1.2. На верхнем уровне выделяются два типа доменов: домены задач (Problem domains) (см. рис. 1.2). Можно выделить следующие основные характеристики домена задач: • характер решаемых задач; • тип домена; • предметная область; • степень автоматизации; • масштаб применения. По характеру обработки данных ИС делятся следующим образом: • на системы, ориентированные на решение крупномасштабных задач преимущественно вычислительного характера; • информационно- справочные (информационно- поисковые) ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном для пользователя виде; • системы поддержки принятия решений; • коммуникационные системы; • ИС, ориентированные на предоставление услуг (сервисов), таких как доступ в Интернет, сервисы хранения данных, доступа к вычислительным ресурсам, доступа к данным и т. п. По принадлежности к базовому домену можно выделить следующие базовые домены задач [36]: информационно- управляющие системы — ИУС (Management Information Systems), управляющие системы — УС (Process Control Systems), системы мониторинга и управления ресурсами — СМУР (Resource Allocation and Tracking Systems), системы управления производством — СУП (Manufacturing Systems), системы управления доступом — СУД (Access Control Systems). • системы поддержки принятия решений; • коммуникационные системы; • ИС, ориентированные на предоставление услуг (сервисов), таких как доступ в Интернет, сервисы хранения данных, доступа к вычислительным ресурсам, доступа к данным и т. п. Рис. 1.2. Классификация архитектур ИС, основанная на домене задач Информационно- управляющие системы (ИУС). Это достаточно известная эталонная модель, которая интенсивно используется, по крайней мере, с середины 1970-х гг. Отличительной особенностью данного класса систем является то, что реализуется процесс сбора данных, поступающих из разных источников, в частности от датчиков. Затем данные обрабатываются и выдаются различным категориям пользователей (stakeholders) в форме отчета, данные из отчета учитываются при принятии решения. Подобные системы используются как в сфере административного управления, так и для управления техническими системами. Обобщенная структура ИУС показана на рис. 1.3 и включает следующие компоненты: • источники данных (ИД); • основную базу данных (ОБД); • базу данных для хранения промежуточных результатов (БДХПР); • подсистему обработки(ПО); • подсистему генерации отчетов (ГО); • набор человеко- машинных интерфейсов. Т а б л и ц а 1.1. Требования к различным типам ИС Основная база данных предназначена для накопления данных на протяжении достаточно длительного промежутка времени. Содержимое ОБД данных регулярно пополняется. Данные обычно не удаляются. ИД включают «сырые данные», с которыми работают транзакции; БДХПР предназначается преимущественно для работы с транзакциями, т. е. данная база хранит Рис. 1.3. Обобщенная структура ИУС данные, относящиеся к выполняемым транзакциям. БДХПР хранит записи, которые появляются как результат обработки данных, поступающих от источников. Если во входных данных обнаруживается ошибка, то информация об ошибке заносится в логфайл и формируется отчет о появлении ошибки. ОБД хранит исторические данные и различную информацию об организации. Информация обычно обобщается на нескольких уровнях. Обычно такие данные хорошо структурированы и могут использоваться в качестве источников данных для систем поддержки принятия решений и других приложений, например data mining. Набор человеко- машинных интерфейсов позволяет вводить и модифицировать данные, используемые транзакциями. Данные интерфейсы дают возможность пользователям получать доступ к отчетам, генерируемым системой по запросу пользователей, на регулярной основе, либо при возникновении исключительных ситуаций. В общем случае интерфейсы используются для реализации оперативного, тактического и стратегического управления. ПО предназначено для обеспечения работы с транзакциями, в частности для сравнения результатов выполнения транзакции с эталонными значениями, хранящимися в ОБД. Подсистема генерации отчетов (ГО) обеспечивает представление информации в удобном для пользователя виде. Данные в ИУС принято разделять на три основные группы: оперативные, тактически и стратегические. Оперативные данные формируются из поступающих от источников и используются при принятии решений, связанных с достижением краткосрочных целей. Тактические данные формируются из оперативных и используются при принятия решений, связанных с достижением среднесрочных целей. Стратегические данные являются обобщением данных тактического уровня. Стратегические данные, по существу, являются корпоративным знанием. Управляющие системы (УС). Их называют еще системами управления процессами. Они представляют собой широкий класс систем, назначением которых является измерение некоторых параметров системы и выдача управляющих воздействий. Следует заметить, что к системам управления процессами относят не только промышленные системы, но и любые другие системы, как реальные, так и виртуальные, в процессе функционирования которых реализуется мониторинг параметров и выдача управляющих воздействий. УС широко и успешно используются в течение многих лет. Одним из широко распространенных типов УС следует считать системы управления производственными процессами. Основными элементами типовой УС (рис. 1.5) являются основной процесс (ОП), датчики (Д), исполнительные механизмы (ИМ), контроллер (К). Типовая УС работает следующим образом. С помощью датчиков Д считывают некоторый набор параметров, характеризующий состояние ОП. Контроллер представляет собой аналоговое или цифровое устройство, реализующее требуемую функцию управления. В процессе работы на вход контроллера поступают также эталонные значения параметров. Контроллер выдает управляющие воздействия, которые поступают на вход ИМ. Системы мониторинга и управления ресурсами (СМУР). Системы данного класса широко используются для решения задач управления производством, финансами и других видов бизнеса. Отличительной особенностью данного класса систем является то, что требуется отслеживать состояние некоторой физической или логической сущности с момента ее поступления на вход системы до момента ее выхода из системы. В качестве такой сущности может выступать поток информации или физический объект. Под термином «мониторинг» в данном случае понимается выполнение действий, связанных с определением текущего состояния отслеживаемого объекта, в частности места нахождения. Под термином «управление» понимается возможность изменения текущего состояния объекта, например изменения его местонахождения. В качестве примеров СМУР можно привести следующие системы: • системы управления складами; • банковские системы; • системы управления документооборотом; • системы управления торговыми сетями; • системы управления транспортными потоками; • системы управления глобальными сетями. Основное назначение систем данного типа — это управление потоком работ. При этом реализуются такие типовые функции, как регистрация информации и отслеживание ее изменений, перемещение в реальном или виртуальном мире и уничтожение. Кроме того, обычно имеется возможность назначать исполнителей для реализации отдельных активностей. Системы управления доступом (СУД). К данному типу относятся системы, на которые возлагается решение задач, связанных с обеспечением доступа субъектов к объектам и ресурсам с использованием четко определенных политик и процедур. Многие реальные системы реализуют данную функцию, хотя обычно она является одной из многих функций, реализуемых системой. В качестве примеров систем управления доступом можно привести следующие системы: • банкоматы; • торговые автоматы; • системы безопасности. В основе функционирования систем управления доступом обычно используется хорошо известная эталонная модель управления доступом (Reference Monitor model), которая была разработана еще в 1960-х гг. и использовалась в качестве системы управления доступом как в мейнфреймах, так и мини- ЭВМ для обеспечения безопасности в режиме многопользовательского доступа к компьютерам. Несмотря на солидный возраст данная модель продолжает активно использоваться для построения систем безопасности, хотя основная сфера использования — это подсистемы безопасности, в которых она используется как вспомогательное приложение. Обобщенная структура эталонной модели доступа включает следующие основные элементы: субъекты, объекты, базу данных авторизаций (БДА), подсистему аудита безопасности (ПАБ) и движок. Субъект представляет собой некоторую активную сущность, которая запрашивает доступ к ресурсу от имени определенного пользователя. При входе в систему пользователь вводит свое имя и пароль. Пароль служит идентификатором, который известен только пользователю и системе. Система присваивает каждому пользователю уникальный идентификатор. Пользователи могут объединяться в группы. Каждый пользователь может участвовать в нескольких группах. Объекты представляют собой пассивные хранилища информации, которые требуется защитить от несанкционированного доступа. Можно назвать следующие типовые объекты: • файлы; • директории; • дисковые тома; • сетевые объекты; • почтовые ящики; • очереди сообщений. Система защищает объекты от несанкционированного доступа и предоставляет ряд механизмов, которые обеспечивают корректное совместное использование объектов несколькими пользователями. База данных авторизаций хранит информацию о правах доступа к объектам. Чаще всего при проверке прав доступа к объекту со стороны субъекта используется идентификатор пользователя. Права доступа могут быть определены, например, в терминах того, кто является владельцем объекта, в терминах разрешения доступа членам группы. Подсистема аудита безопасности отвечает за ведение журнала, в котором отмечаются успешные и неуспешные попытки входа в систему. После определенного числа безуспешных попыток входа в систему подсистема аудита может заблокировать дальнейшие попытки и выдать предупреждение администратору. Движок представляет собой программный процессор, который реализует процедуру авторизации. Можно сказать, что система управления доступом обеспечивает реализацию политики или политик доступа, основанных на правилах. К ней предъявляются следующие типовые требования: • система должна обеспечивать надежную защиту объектов от несанкционированного доступа; • система должна быть компактной и быстрой, поскольку все обращения к объектам проходят через данную систему. Эталонная модель может быть применена как для систем, работающих на одном компьютере, так и для распределенных систем. Применительно к распределенным системам можно выделить три типовых подхода к реализации механизма управления доступом: • прямое управление; • мандатное управление; • ролевое управление. При использовании прямого управления все субъекты и объекты определены так, как это было описано выше применительно к эталонной модели. При использовании прямого управления субъекты-владельцы объекта могут разрешать или запрещать доступ к этим другим субъектам. Принципиально объекты и субъекты могут меняться ролями. Данный подход используется наиболее часто, хотя и не обеспечивает высоких показателей безопасности. При использовании мандатного управления все объекты и субъекты относятся к определенному уровню. При использовании данного подхода субъекты не могут получить доступ к объектам, если им не разрешено работать на данном уровне. Идея ролевого управления состоит в том, что определяется набор ролей, которые могут соответствовать, например, служебным обязанностям сотрудника или функциям, реализуемым подсистемой. Права доступа определяются, в частности, ролями, закрепленными за субъектом. Ролевое управление доступом является наиболее гибким и простым с точки зрения администрирования. В рамках конкретных систем возможно совместное использование рассмотренных подходов. ЛЕКЦИЯ №13 ВЫБОР ПРОГРАММНО-АППАРАТНОЙ РЕАЛИЗАЦИИ ИС РАЗЛИЧНОЙ АРХИТЕКТУРЫ ПЛАТФОРМЫ ПЛАН: особенности и принципы реализации ИС различной архитектуры. Об архитектуре программных систем и интеграции. ДЛЯ Под архитектурой программных систем понимается совокупность решений относительно: организации программной системы; выбора структурных элементов, составляющих систему и их интерфейсов; поведения этих элементов во взаимодействии с другими элементами; объединение этих элементов в подсистемы; архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения. Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, возможность повторного применения, полноту, экономические и технологические ограничения, а также вопрос пользовательского интерфейса. По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом архитектуры. Для того, чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java - JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие. Об архитектуре программных и информационных систем. Современные программные приложения и информационные системы достигли такого уровня развития, что термин "архитектура" в применении к ним уже давно не удивляет. Грамотно построить информационную систему, эффективно и надежно функционирующую не проще, чем сконструировать и возвести современное многофункциональное здание. Технические характеристики аппаратных платформ. Процессоры. Основные архитектурные понятия Архитектура системы команд. Классификация процессоров (CISC и RISC) Термин "архитектура системы" часто употребляется как в узком, так и в широком смысле этого слова. В узком смысле под архитектурой понимается архитектура набора команд. Архитектура набора команд служит границей между аппаратурой и программным обеспечением и представляет ту часть системы, которая видна программисту или разработчику компиляторов. Следует отметить, что это наиболее частое употребление этого термина. В широком смысле архитектура охватывает понятие организации системы, включающее такие высокоуровневые аспекты разработки компьютера как систему памяти, структуру системной шины, организацию ввода/вывода и т.п. Двумя основными архитектурами набора команд, используемыми компьютерной промышленностью на современном этапе развития вычислительной техники являются архитектуры CISC и RISC. Основоположником CISC-архитектуры можно считать компанию IBM с ее базовой архитектурой /360, ядро которой используется с 1964 года и дошло до наших дней, например, в таких современных мейнфреймах как IBM ES/9000. Лидером в разработке микропроцессоров c полным набором команд (CISC Complete Instruction Set Computer) считается компания Intel со своей серией x86 и Pentium. Эта архитектура является практическим стандартом для рынка микрокомпьютеров. Для CISC-процессоров характерно: сравнительно небольшое число регистров общего назначения; большое количество машинных команд, некоторые из которых нагружены семантически аналогично операторам высокоуровневых языков программирования и выполняются за много тактов; большое количество методов адресации; большое количество форматов команд различной разрядности; преобладание двухадресного формата команд; наличие команд обработки типа регистр-память. Основой архитектуры современных рабочих станций и серверов является архитектура компьютера с сокращенным набором команд (RISC - Reduced Instruction Set Computer). Зачатки этой архитектуры уходят своими корнями к компьютерам CDC6600, разработчики которых (Торнтон, Крэй и др.) осознали важность упрощения набора команд для построения быстрых вычислительных машин. Эту традицию упрощения архитектуры С. Крэй с успехом применил при создании широко известной серии суперкомпьютеров компании Cray Research. Однако окончательно понятие RISC в современном его понимании сформировалось на базе трех исследовательских проектов компьютеров: процессора 801 компании IBM, процессора RISC университета Беркли и процессора MIPS Стенфордского университета. Разработка экспериментального проекта компании IBM началась еще в конце 70-х годов, но его результаты никогда не публиковались и компьютер на его основе в промышленных масштабах не изготавливался. В 1980 году Д.Паттерсон со своими коллегами из Беркли начали свой проект и изготовили две машины, которые получили названия RISC-I и RISC-II. Главными идеями этих машин было отделение медленной памяти от высокоскоростных регистров и использование регистровых окон. В 1981году Дж.Хеннесси со своими коллегами опубликовал описание стенфордской машины MIPS, основным аспектом разработки которой была эффективная реализация конвейерной обработки посредством тщательного планирования компилятором его загрузки. Эти три машины имели много общего. Все они придерживались архитектуры, отделяющей команды обработки от команд работы с памятью, и делали упор на эффективную конвейерную обработку. Система команд разрабатывалась таким образом, чтобы выполнение любой команды занимало небольшое количество машинных тактов (предпочтительно один машинный такт). Сама логика выполнения команд с целью повышения производительности ориентировалась на аппаратную, а не на микропрограммную реализацию. Чтобы упростить логику декодирования команд использовались команды фиксированной длины и фиксированного формата. Среди других особенностей RISC-архитектур следует отметить наличие достаточно большого регистрового файла (в типовых RISC-процессорах реализуются 32 или большее число регистров по сравнению с 8 - 16 регистрами в CISC-архитектурах), что позволяет большему объему данных храниться в регистрах на процессорном кристалле большее время и упрощает работу компилятора по распределению регистров под переменные. Для обработки, как правило, используются трехадресные команды, что помимо упрощения дешифрации дает возможность сохранять большее число переменных в регистрах без их последующей перезагрузки. Ко времени завершения университетских проектов (1983-1984 гг.) обозначился также прорыв в технологии изготовления сверхбольших интегральных схем. Простота архитектуры и ее эффективность, подтвержденная этими проектами, вызвали большой интерес в компьютерной индустрии и с 1986 года началась активная промышленная реализация архитектуры RISC. К настоящему времени эта архитектура прочно занимает лидирующие позиции на мировом компьютерном рынке рабочих станций и серверов. Развитие архитектуры RISC в значительной степени определялось прогрессом в области создания оптимизирующих компиляторов. Именно современная техника компиляции позволяет эффективно использовать преимущества большего регистрового файла, конвейерной организации и большей скорости выполнения команд. Современные компиляторы используют также преимущества другой оптимизационной техники для повышения производительности, обычно применяемой в процессорах RISC: реализацию задержанных переходов и суперскалярной обработки, позволяющей в один и тот же момент времени выдавать на выполнение несколько команд. Следует отметить, что в последних разработках компании Intel (имеется в виду Pentium P54C и процессор следующего поколения P6), а также ее последователейконкурентов (AMD R5, Cyrix M1, NexGen Nx586 и др.) широко используются идеи, реализованные в RISC-микропроцессорах, так что многие различия между CISC и RISC стираются. Однако сложность архитектуры и системы команд x86 остается и является главным фактором, ограничивающим производительность процессоров на ее основе. Методы адресации и типы данных Методы адресации В машинах к регистрами общего назначения метод (или режим) адресации объектов, с которыми манипулирует команда, может задавать константу, регистр или ячейку памяти. Для обращения к ячейке памяти процессор прежде всего должен вычислить действительный или эффективный адрес памяти, который определяется заданным в команде методом адресации. На рисунке 5.1 представлены все основные методы адресации операндов, которые реализованы в компьютерах, рассмотренных в настоящем обзоре. Адресация непосредственных данных и литеральных констант обычно рассматривается как один из методов адресации памяти (хотя значения данных, к которым в этом случае производятся обращения, являются частью самой команды и обрабатываются в общем потоке команд). Адресация регистров, как правило, рассматривается отдельно. В данном разделе методы адресации, связанные со счетчиком команд (адресация относительно счетчика команд) рассматриваются отдельно. Этот вид адресации используется главным образом для определения программных адресов в командах передачи управления. На рисунке 5.1 на примере команды сложения (Add) приведены наиболее употребительные названия методов адресации, хотя при описании архитектуры в документации разные производители используют разные названия для этих методов. На этом рисунке знак "(" используется для обозначения оператора присваивания, а буква М обозначает память (Memory). Таким образом, M[R1] обозначает содержимое ячейки памяти, адрес которой определяется содержимым регистра R1. Использование сложных методов адресации позволяет существенно сократить количество команд в программе, но при этом значительно увеличивается сложность аппаратуры. Возникает вопрос, а как часто эти методы адресации используются в реальных программах? На рисунке 5.2 представлены результаты измерений частоты использования различных методов адресации на примере трех популярных программ (компилятора с языка Си GCC, текстового редактора TeX и САПР Spice), выполненных на компьютере VAX. Из этого рисунка видно, что непосредственная адресация и базовая со смещением доминируют. Метод адресации Регистровая Непосредственная литеральная Базовая со смещением Косвенная регистровая Индексная или Пример команды Add R4,R3 R4<--R4+R5Требуемое значение в регистре Add R4,#3 R4<--R4+3 Для задания констант Смысл команды метода Использование R4<--R4+M[100+R1]Для обращения к локальным переменным R4<--R4+M[R1]Для обращения по Add R4,(R1) указателю или вычисленному адресу Add R3,(R1+R2) R3<--R3+M[R1+R2]Иногда полезна при Add R4,100(R1) Прямая абсолютная или Add R1,(1000) Косвенная Add R1,@(R3) Автоинкрементная Add R1,(R2)+ Автодекрементная Add R1,(R2)- Базовая индексная смещением масштабированием работе с массивами: R1 - база, R3 - индекс R1<--R1+M[1000]Иногда полезна для обращения к статическим данным R1<--R1+M[M[R3]]Если R3-адрес указателя p, то выбирается значение по этому указателю R1<--R1+M[R2] R2<--R2+dПолезна для прохода в цикле по массиву с шагом: R2 - начало массива В каждом цикле R2 получает приращение d R2<--R2-d R1<--R1+M[R2]Аналогична предыдущей Обе могут использоваться для реализации стека со Add R1<--R1+M[100]+R2+R3*dДля индексации и R1,100(R2)[R3] массивов Рис. 5.1. Методы адресации При этом основной вопрос, который возникает для метода базовой адресации со смещением, связан с длиной (разрядностью) смещения. Выбор длины смещения в конечном счете определяет длину команды. Результаты измерений показали, что в подавляющем большинстве случаев длина смещения не превышает 16 разрядов. Рис. 5.2. Частота использования различных методов адресации на программах TeX, Spice, GCC Этот же вопрос важен и для непосредственной адресации. Непосредственная адресация используется при выполнении арифметических операций, операций сравнения, а также для загрузки констант в регистры. Результаты анализа статистики показывают, что в подавляющем числе случаев 16 разрядов оказывается вполне достаточно (хотя для вычисления адресов намного реже используются и более длинные константы). Важным вопросом построения любой системы команд является оптимальное кодирование команд. Оно определяется количеством регистров и применяемых методов адресации, а также сложностью аппаратуры, необходимой для декодирования. Именно поэтому в современных RISC-архитектурах используются достаточно простые методы адресации, позволяющие резко упростить декодирование команд. Более сложные и редко встречающиеся в реальных программах методы адресации реализуются с помощью дополнительных команд, что вообще говоря приводит к увеличению размера программного кода. Однако такое увеличение длины программы с лихвой окупается возможностью простого увеличения тактовой частоты RISC-процессоров. Типы команд Команды традиционного машинного уровня можно разделить на несколько типов, которые показаны на рисунке 5.3. Тип операции Примеры Целочисленные арифметические и логические операции: Арифметически сложение, вычитание, логическое сложение, логическое е и логические умножение и т.д. Пересылки Операции загрузки/записи данных Управление Безусловные и условные переходы, вызовы процедур и потоком команд возвраты Системные Системные вызовы, команды управления виртуальной операции памятью и т.д. Операции с Операции сложения, вычитания, умножения и деления над плавающей вещественными числами точкой Десятичные Десятичное сложение, умножение, преобразование операции форматов и т.д. Операции над Пересылки, сравнения и поиск строк строками Рис. 5.3. Основные типы команд Команды управления потоком команд В английском языке для указания команд безусловного перехода, как правило, используется термин jump, а для команд условного перехода - термин branch, хотя разные поставщики необязательно придерживаются этой терминологии. Например компания Intel использует термин jump и для условных, и для безусловных переходов. Можно выделить четыре основных типа команд для управления потоком команд: условные переходы, безусловные переходы, вызовы процедур и возвраты из процедур. Частота использования этих команд по статистике примерно следующая. В программах доминируют команды условного перехода. Среди указанных команд управления на разных программах частота их использования колеблется от 66 до 78%. Следующие по частоте использования - команды безусловного перехода (от 12 до 18%). Частота переходов на выполнение процедур и возврата из них составляет от 10 до 16%. При этом примерно 90% команд безусловного перехода выполняются относительно счетчика команд. Для команд перехода адрес перехода должен быть всегда заранее известным. Это не относится к адресам возврата, которые не известны во время компиляции программы и должны определяться во время ее работы. Наиболее простой способ определения адреса перехода заключается в указании его положения относительно текущего значения счетчика команд (с помощью смещения в команде), и такие переходы называются переходами относительно счетчика команд. Преимуществом такого метода адресации является то, что адреса переходов, как правило, расположены недалеко от текущего адреса выполняемой команды и указание относительно текущего значения счетчика команд требует небольшого количества бит в смещении. Кроме того, использование адресации относительно счетчика команд позволяет программе выполняться в любом месте памяти, независимо от того, куда она была загружена. То есть этот метод адресации позволяет автоматически создавать перемещаемые программы. Реализация возвратов и переходов по косвенному адресу, в которых адрес не известен во время компиляции программы, требует методов адресации, отличных от адресации относительно счетчика команд. В этом случае адрес перехода должен определяться динамически во время работы программы. Наиболее простой способ заключается в указании регистра для хранения адреса возврата, либо для перехода может разрешаться любой метод адресации для вычисления адреса перехода. Одним из ключевых вопросов реализации команд перехода состоит в том, насколько далеко целевой адрес перехода находится от самой команды перехода? И на этот вопрос статистика использования команд дает ответ: в подавляющем большинстве случаев переход идет в пределах 3 - 7 команд относительно команды перехода, причем в 75% случаев выполняются переходы в направлении увеличения адреса, т.е. вперед по программе. Поскольку большинство команд управления потоком команд составляют команды условного перехода, важным вопросом реализации архитектуры является определение условий перехода. Для этого используются три различных подхода. При первом из них в архитектуре процессора предусматривается специальный регистр, разряды которого соответствуют определенным кодам условий. Команды условного перехода проверяют эти условия в процессе своего выполнения. Преимуществом такого подхода является то, что иногда установка кода условия и переход по нему могут быть выполнены без дополнительных потерь времени, что, впрочем, бывает достаточно редко. А недостатками такого подхода является то, что, во-первых, появляются новые состояния машины, за которыми необходимо следить (упрятывать при прерывании и восстанавливать при возврате из него). Во-вторых, и что очень важно для современных высокоскоростных конвейерных архитектур, коды условий ограничивают порядок выполнения команд в потоке, поскольку их основное назначение заключается в передаче кода условия команде условного перехода. Второй метод заключается в простом использовании произвольного регистра (возможно одного выделенного) общего назначения. В этом случае выполняется проверка состояния этого регистра, в который предварительно помещается результат операции сравнения. Недостатком этого подхода является необходимость выделения в программе для анализа кодов условий специального регистра. Третий метод предполагает объединение команды сравнения и перехода в одной команде. Недостатком такого подхода является то, что эта объединенная команда довольно сложна для реализации (в одной команде надо указать и тип условия, и константу для сравнения и адрес перехода). Поэтому в таких машинах часто используется компромиссный вариант, когда для некоторых кодов условий используются такие команды, например, для сравнения с нулем, а для более сложных условий используется регистр условий. Часто для анализа результатов команд сравнения для целочисленных операций и для операций с плавающей точкой используется разная техника, хотя это можно объяснить и тем, что в программах количество переходов по условиям выполнения операций с плавающей точкой значительно меньше общего количества переходов, определяемых результатами работы целочисленной арифметики. Одним из наиболее заметных свойств большинства программ является преобладание в них сравнений на условие равно/неравно и сравнений с нулем. Поэтому в ряде архитектур такие команды выделяются в отдельный поднабор, особенно при использовании команд типа "сравнить и перейти". Говорят, что переход выполняется, если истинным является условие, которое проверяет команда условного перехода. В этом случае выполняется переход на адрес, заданный командой перехода. Поэтому все команды безусловного перехода всегда выполняемые. По статистике оказывается, что переходы назад по программе в большинстве случаев используются для организации циклов, причем примерно 60% из них составляют выполняемые переходы. В общем случае поведение команд условного перехода зависит от конкретной прикладной программы, однако иногда сказывается и зависимость от компилятора. Такие зависимости от компилятора возникают вследствие изменений потока управления, выполняемого оптимизирующими компиляторами для ускорения выполнения циклов. Вызовы процедур и возвраты предполагают передачу управления и возможно сохранение некоторого состояния. Как минимум, необходимо уметь где-то сохранять адрес возврата. Некоторые архитектуры предлагают аппаратные механизмы для сохранения состояния регистров, в других случаях предполагается вставка в программу команд самим компилятором. Имеются два основных вида соглашений относительно сохранения состояния регистров. Сохранение вызывающей (caller saving) программой означает, что вызывающая процедура должна сохранять свои регистры, которые она хочет использовать после возврата в нее. Сохранение вызванной процедурой предполагает, что вызванная процедура должна сохранить регистры, которые она собирается использовать. Имеются случаи, когда должно использоваться сохранение вызывающей процедурой для обеспечения доступа к глобальным переменным, которые должны быть доступны для обеих процедур. Типы и размеры операндов Имеется два альтернативных метода определения типа операнда. В первом из них тип операнда может задаваться кодом операции в команде. Это наиболее употребительный способ задания типа операнда. Второй метод предполагает указание типа операнда с помощью тега, который хранится вместе с данными и интерпретируется аппаратурой во время выполнения операций над данными. Этот метод использовался, например, в машинах фирмы Burroughs, но в настоящее время он практически не применяется и все современные процессоры пользуются первым методом. Обычно тип операнда (например, целый, вещественный с одинарной точностью или символ) определяет и его размер. Однако часто процессоры работают с целыми числами длиною 8, 16, 32 или 64 бит. Как правило целые числа представляются в дополнительном коде. Для задания символов (1 байт = 8 бит) в машинах компании IBM используется код EBCDIC, но в машинах других производителей почти повсеместно применяется кодировка ASCII. Еще до сравнительно недавнего времени каждый производитель процессоров пользовался своим собственным представлением вещественных чисел (чисел с плавающей точкой). Однако за последние несколько лет ситуация изменилась. Большинство поставщиков процессоров в настоящее время для представления вещественных чисел с одинарной и двойной точностью придерживаются стандарта IEEE 754. В некоторых процессорах используются двоично кодированные десятичные числа, которые представляются в в упакованном и неупакованном форматах. Упакованный формат предполагает, что для кодирования цифр 0-9 используются 4 разряда и что две десятичные цифры упаковываются в каждый байт. В неупакованном формате байт содержит одну десятичную цифру, которая обычно изображается в символьном коде ASCII. В большинстве процессоров, кроме того, реализуются операции над цепочками (строками) бит, байт, слов и двойных слов. Архитектура вычислительных модулей потокового уровня позволяет использовать естественный параллелизм решаемой задачи вплоть до битового уровня, то есть уровня структуры обрабатываемых данных, а также позволяет строить конвейеры произвольной глубины. Потоковый уровень предоставляет возможность одновременной обработки множества независимых некогерентных потоков. Фактически, при решении конкретной функции или самостоятельной задачи, на вычислительных модулях потокового уровня путем ввода соответствующей программы организуется спецпроцессор, реализующий решаемую функцию или задачу с наибольшей эффективностью. На матрице модулей потокового уровня одновременно могут решаться несколько независимых задач и функций, причем механизм перезагрузки сегментов потокового уровня позволяет перезагружать часть матрицы без остановки выполнения еще незавершенных задач. Потоковый уровень обладает высокой гибкостью и перестраиваемостью, в частности, полной аппаратной и программной масштабируемостью, что позволяет строить на его основе вычислительные системы с большим быстродействием. Производительность матрицы модулей потокового уровня, теоретически, растет линейно с увеличением рабочей частоты поля и площади вычислительной матрицы. Вычислительные модули потокового уровня позволяют создавать системы с высоким уровнем надежности и отказоустойчивости, эффективно реализовывать нейросетевые алгоритмы. Предложенные архитектурные принципы позволяют эффективно реализовывать любые виды параллелизма. Архитектура является открытой и масштабируемой, то есть не накладывает жестких ограничений к программно-аппаратной платформе узлов кластера, топологии вычислительной сети, конфигурации и диапазону производительности суперкомпьютеров. Вычислительные системы, создаваемые на базе основополагающих концептуальных архитектурных принципов могут оптимально решать как классические вычислительные задачи математической физики и линейной алгебры, так и специализированные задачи обработки сигналов, моделирования виртуальной реальности, задачи управления сложными системами в реальном времени и другие приложения. ЛЕКЦИЯ №14 ЭТАПЫ РАЗРАБОТКИ ИС ПЛАН: последовательность этапов разработки ИС. Организация информационных потоков. Структура информационной системы. Состав информационной системы. ^ Функциональные компоненты. Функциональные подсистемы. Компоненты системы обработки данных. Информационное обеспечение. Организационные компоненты. Новые организационные структуры формы. Персонал Функциональные задачи Техническое обеспечение. (штаты, должности, инструкции) Модели и алгоритмы. Правовое обеспечение. Программное обеспечение. Лингвистическое обеспечение. Под функциональными компонентами понимается система функций управления - полный набор (комплекс) взаимосвязанных во времени и пространстве работ по управлению необходимыми для достижения поставленных предприятием целей. Декомпозиция ИС по функциональному признаку включает в себя выделение её отдельных частей, называющихся функциональными подсистемами, реализующих систему функции управления. Функциональный признак определяет назначение подсистемы, то есть то, для какой области деятельности она предназначена, и какие основные цели, задачи и функции она выполняет. Функциональные подсистемы в существенной степени зависят от предметной области (сферы применения) ИС. Функция управления – это специальная постоянная обязанность одного или нескольких лиц, выполнение которых приводит к достижению определенного делового результата. Весь процесс управления фирмой сводится либо к линейному (административному) руководству предприятием или его структурным подразделением, либо к функциональному руководству (материально техническое обеспечение, бух учет и т.п.). В современных системах автоматизации и проектирования ИС входят модели и алгоритмы, из которых в процессе разработки ИС выбирают наиболее эффективный для конкретного объекта управления. 3. Компоненты системы обработки данных. Организационные компоненты информационной системы. Любая ИС состоит из 3х основных компонентов: - функционального, - системы обработки данных, - организационного. Система обработки данных (СОД) предназначена для информационного обслуживания специалистов разных органов управления предприятиями, принимающих управленческие решения. Основная функция СОД – реализующая типовые операции обработки данных. Операции обработки данных: Сбор, регистрация и перенос информации на машинные носители. Передача информации в места её хранения и обработки. Ввод информации в ЭВМ, контроль ввода и её компоновка в памяти компьютера. Создание и ведение внутри-машинной информационной базы. Обработка информации на ЭВМ (наполнение, сортировка, корректировка, выборка, арифметическая и логическая обработка) для решения функциональных задач системы (подсистемы), управление объектом. Вывод информации в виде видео грамм, сигналов для прямого управления техническими процессами, информация для связи с другими системами. Организация, управление (администрирование) вычислительным процессом (планирование, учет, контроль, анализ, реализация кода вычислений) в локальных и глобальных вычислительных сетях. СОД могут работать в трех основных режимах: 1. Пакетном. 2. Интерактивном. 3. В реальном масштабе времени. Для пакетного режима характерно, что результаты обработки выдаются пользователям после выполнения так называемых пакетов заданий. В качестве примера систем, работающих в пакетном режиме, можно назвать системы статистической отчетности, налоговых инспекций, расчетных кассовых центрах. Недостатком такого режима является обособленность пользователя от процесса обработки информации, что снижает оперативность принятия решений. При интерактивном (диалоговом) режиме работы происходит обмен сообщениями между пользователем и системой. Пользователь обдумывает результаты запроса, и принятые решения вводит в систему для дальнейшей обработки. Типичными примерами диалоговых задач можно считать мгновенные задачи использования ресурсов (трудовых, материальных, финансовых). Режим реального времени используется для управления быстропротекающими процессами (передача и обработка банковской информации в глобальных международных сетях, для управления непрерывными технологическими процессами). СОД вкл. в себя информационное, программное, техническое, правовое и лингвистическое обеспечения. Информационное обеспечение – это совокупность методов и средств по размещению и организации информации, включающих в себя системы классификации и кодирования, унифицированные системы документации, рационализации документооборота и форм документов, методов создания внутримашинной информационной базы ИС. Программное обеспечение – совокупность программных средств для создания и эксплуатации СОД средствами вычислительной техники. В состав ПО входят базовые и прикладные программные продукты. Техническое обеспечение представляет собой комплекс технических средств, применяемых для функционирования системы обработки данных, и включает в себя устройства, реализующие типовые операции обработки данных как во вне ЭВМ (периферийные тех. средства сбора, регистрации – сканер, устройства передачи данных…), так и на ЭВМ различных классов. Правовое обеспечение представляет собой совокупность правовых норм, регламентирующих создание и функционирование ИС. Правовое обеспечение включает нормативные акты договорных взаимоотношений между заказчиком и разработчиком ИС, правовое регулирование отклонений. Правовое обеспечение функционирования СОД включает: Условия придания юридической силы документам, полученным с применением вычислительной техники. Права, обязанности и ответственность персонала, в том числе за своевременность и точность обработки информации. Правила пользования информацией и порядок разрешения споров по поводу её достоверности Лингвистическое обеспечение представляет собой совокупность языковых средств обработки данных, используемых на различных стадиях создания и эксплуатации СОД для повышения эффективности разработки и обеспечения общения человека и ЭВМ (трансляторы, яз. программирования…). Под организационными компонентами ИС понимается совокупность методов и средств, позволяющих - усовершенствовать организационную структуру объектов и управленческие функции, выпол-няемые структурными подразделениями; - определить штатное расписание и численный состав каждого структурного подразделения; - разработать должностные инструкции персоналу управления в условиях функционирования СОД. Выделение организационных компонентов связано с особой значимостью человеческого фактора (персонала) в успешном функционировании ИС. Для функционирования ИС нужны люди, поэтому набирается персонал, и изменяется штатное расписание. А чтобы персонал грамотно работал с ИС, создаются должностные инструкции. 4. Понятие жизненного цикла ИС. Этапы ЖЦ ИС. Понятие жизненного цикла ИС является одним из базовых программной инженерии. Жизненный цикл ИС определяется как период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент её полного изъятия из эксплуатации. Этапы ЖЦ ИС: Модели хранения данных: -иерархическая -сетевая -реляционная. При проектировании БД организацию данных принято рассматривать на 3х уровнях: -концептуальном, -логическом, -физическом. БД должна отображать текущие данные о ПО, накапливать, хранить информацию и предоставлять различным категориям пользователей быстрый доступ к данным. Для этого данные в БД должны быть структурированы в соответствии с некоторой моделью, отражающей основные объекты ПО, их свойства и связи между ними. Система управления базами данных (СУБД) – представляет собой совокупность языковых и программных средств, с помощью которых база данных создается и поддерживается в процессе эксплуатации. Основные функции СУБД 1. Определение данных - определить, какая именно информация будет храниться в БД, задать свойства данных, их тип (например, число цифр или символов), а также указать, как эти данные связаны между собой. В некоторых случаях есть возможность задавать форматы и критерии проверки данных. 2. Обработка данных - данные могут обрабатываться самыми различными способами. Можно выбирать любые поля, фильтровать и сортировать данные. Можно объединять данные с другой, связанной с ними, информацией и вычислять итоговые значения. 3. Управление данными - можно указать, кому разрешено знакомиться с данными, корректировать их или добавлять новую информацию. Можно также определять правила коллективного доступа. Модель данных – правила, которые определяют структуру данных, допустимые реализации данных и допустимые операции над данными. Концептуальная модель описывает ПО на содержательном уровне. На 1м этапе ее разработки осуществляется анализ ПО, решаемых задач, запросов пользователей и документов, отражающих события и процессы, протекающие в ПО. Результатом этого анализа являются списки объектов ПО, перечни их свойств (атрибутов), определение связи между объектами и описание структуры ПО в виде диаграммы. Логическая модель описывает объекты и связи ПО на формальном уровне. В процессе разработки осуществляется выбор типа модели данных и определяются ее элементы. Физическая модель данных определяет способ размещения данных непосредственно на машинном носителе, учитывает распределение данных, методы доступа и способы индексирования. Основными нормативными документами, регламентирующими состав процессов жизненного цикла, являются международный стандарт ISO/IEC 12207 (International Organization for Standardization/ International Electrotechnical Commission – международная комиссия по электротехнике) – определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС; и российский стандарт ГОСТ 34. Процессы жизненного цикла ИС В соответствии со стандартом ISO/IEC 12207 все процессы жизненного цикла разделены на 3 группы. Основные процессы Вспомогательные процессы Приобретение Документирование Поставка Управление конфигурацией Эксплуатация Разаботка Обеспечение качества Верификация Сопровождение Аттестация, совместная оценка Аудит Разрешение проблем Организационный процесс Управление Создание инфраструктуры Усовершенствование Обучение Основные: - Приобретение (действия и задачи заказчика, приобретающего ИС) - Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой) - Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.) - Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему) - Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям. Вспомогательные: - Документирование (формализованное описание информации, созданной в течение ЖЦ ИС) - Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями). - Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам) - Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями) - Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению) - Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами) - Аудит (определение соответствия требованиям, планам и условиям договора) - Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов) Организационные: - Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами) - Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО) - Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ) - Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала). ЛЕКЦИЯ №15 РЕАЛИЗАЦИЯ КЛИЕНТСКОЙ И СЕРВЕРНОЙ ЧАСТЕЙ ИС ПЛАН: Реализация механизмов между компонентами ИС. взаимодействия и передачи информации Эффективность функционирования ИС во многом зависит от ее архитектуры. Обработка данных с помощью мэйнфреймов (больших машин с несколькими терминалами), популярная в 70-е годы, имела свои преимущества, утраченные позже, в эпоху персональных компьютеров и настольных СУБД. Одним из таких преимуществ была централизация хранения и обработки данных, но недостаток: все задачи пользователей выполнялись на одном компьютере и замедляли работу друг друга. Однако повсеместное увлечение настольными СУБД и их сетевыми версиями, вызванное: доступностью, дешевизной как самого программного обеспечения, так и дешевизной его эксплуатации, заставило многих пользователей на долгие годы забыть о «мэйнфреймовой» модели вычислений. Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно большими. Это приводит к снижению производительности приложений, использующих такие СУБД. Наиболее популярные настольные СУБД: dBase, Paradox, FoxPro, Access. Информационные системы, написанные с использованием сетевых версий настольных СУБД, используют выделенные файл-сервера (т.е. реализованы с использованием архитектуры файл-сервера – исторически первая архитектура) Рис. Классическое представление информационной системы в архитектуре "файлсервер" В любом приложении выделяются следующие компоненты: прикладная часть приложения, часть управления данными, часть отвечающая за сетевой доступ. При опоре на файл-серверную архитектуру сохраняется автономность прикладного программного обеспечения, работающего на каждой PC сети. Компоненты информационной системы, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждой PC дублируются не только прикладные программы, но и средства управления базами данных. В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти. Рис. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре Поскольку в настольных СУБД вся реальная обработка данных осуществляется в клиентском приложении, то при выполнении запросов данные, на основании которых выполняется такой запрос, должны быть доставлены в адресное пространство клиентского приложения. Доставляться может одна или несколько таблиц целиком либо, в лучшем случае, один или несколько индексов и выбранные с их помощью части таблиц. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром существует большое количество утилит для <ремонта> испорченных файлов настольных СУБД. Известно много случаев, когда для решения подобных проблем: o закупалось дорогое сетевое оборудование с целью увеличения пропускной способности сети, o применялись иные <ухищрения> наподобие хранения наиболее часто используемых данных в клиентских приложениях или просто на локальных жестких дисках. Нередко также применялся подход, приводящий к децентрализации хранения данных. Типичный пример подобного подхода - создание нескольких однотипных локальных баз данных, например, для различных подразделений компании или для разных временных периодов (лет, кварталов, месяцев), что облегчало работу, связанную с вводом данных, но повышало стоимость их статистической обработки и анализа - в этом случае нужно было обрабатывать данные из разных источников. Однако все эти меры позволяли лишь отложить на время решение проблемы снижения производительности, но не устраняли главного недостатка информационных систем, основанных на настольных СУБД, - обработки данных в клиентском приложении. Радикальным решением проблемы сетевого трафика и иных проблем, возникающих при увеличении объема данных и числа пользователей, стал переход к архитектуре «клиент-сервер», позаимствовавшей многие достоинства старой «мэйнфреймовой» модели вычислений, в частности централизацию хранения и обработки данных. Сервер баз данных осуществляет целый комплекс действий по управлению данными. Основными его обязанностями являются: выполнение пользовательских запросов на выбор и модификацию данных, получаемых от клиентских приложений, функционирующих на персональных компьютерах локальной сети; хранение и резервное копирование данных; поддержка целостности данных согласно определенным в базе данных правилам; обеспечение авторизованного доступа к данным на основе проверки прав и привилегий пользователей; протоколирование операций и ведение журнала транзакций. В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды. В простейшем случае «клиент-серверная» информационная система состоит из двух основных компонентов: сервера баз данных, управляющего данными и выполняющего запросы клиентских приложений; клиентских приложений, предоставляющих интерфейс пользователя и посылающих запросы к серверу. Рис. Общее представление информационной системы в архитектуре "клиентсервер" Заметим, что интерфейс между клиентской частью частью сервера БД, основан на использовании языка SQL. сервера баз данных, используя средства сетевого доступа, данных, передавая ему текст оператора языка SQL. Как видно, в клиент-серверной организации клиенты "тонкими", а сервер должен быть "толстым" настолько, удовлетворить потребности всех клиентов. приложения и клиентской Наконец, клиентская часть обращается к серверу баз могут являться достаточно чтобы быть в состоянии Рис. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL: 1. Сервер производит компиляцию полученного оператора. 2. Если компиляция завершилась успешно, происходит выполнение оператора: Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированния (или тиражированния) баз данных. Отдельной проблемой является обеспечение согласованности кэша и общей базы данных. В этом случае, клиенты становятся более толстыми при том, что сервер тоньше не делается. Рис. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов Предварительные выводы. Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Но громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и способность к дальнейшему развитию. Увеличение масштабов информационной системы не порождает принципиальных проблем. Т.е. мы можем заменить аппаратуру сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных), не затрагивая прикладную часть информационной системы. Мы рассмотрели двухуровневую (двухзвенную) архитектуру клиент-сервер. В последнее время также наблюдается тенденция ко все большему использованию модели распределенного приложения. Характерной чертой таких приложений является логическое разделение приложения на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная архитектура клиент-сервер становится трехзвенной. Существуют и более сложные реализации архитектуры «клиент-сервер», например многозвенные информационные системы с использованием нескольких серверов приложений: "Клиент-серверная" архитектура: а - двухзвенная; б - многозвенная. Многосерверная архитектура сегодня представляется очень перспективной. Она позволяет заменить одну мощную центральную машину на несколько менее мощных и, следовательно, более дешевых, и еще больше распараллелить обработку данных. Кроме того, такая архитектура повышает надежность системы, поскольку при выходе из строя одного из серверов все приложения, работающие с данными других серверов, могут продолжать работу, хотя реализация такой архитектуры достаточно сложна. Информационные системы, основанные на архитектуре «клиент-сервер» являются приближением к распределенным системам БД. Очень часто возникает необходимость предоставить доступ к одним и тем же данным группам пользователей, территориально удаленным друг от друга. В качестве примера можно привести банк, имеющий несколько отделений. Эти отделения могут находиться в разных городах, странах или даже на разных континентах, тем не менее необходимо организовать обработку финансовых транзакций (перемещение денег по счетам) между отделениями. Результаты финансовых операций должны быть видны одновременно во всех отделениях. Для построения таких информационных систем используется технология распределенной БД. Такая база включает фрагменты данных, расположенные на различных узлах сети. Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных. С точки зрения пользователей она выглядит так, как будто все данные хранятся в одном месте. Естественно, такая схема предъявляет жесткие требования к производительности и надежности каналов связи. Преимущества архитектуры «клиент-сервер» Информационные системы, использующие архитектуру <клиент-сервер>, обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД: 1. Снижение сетевого трафика при выполнении запросов. Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. В клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит от числа записей в таблицах, к которым произведен запрос. 2. Возможность хранения бизнес-правил (например, правил ограничения целостности данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных может быть произведено только с учетом этих правил. 3. Для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) часто используют так называемые CASEсредства (Computer-Aided System Engineering). Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без программирования, а затем сгенерировать код соответствующих серверных объектов триггеров, хранимых процедур, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше <облегчить> клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это снижает стоимость информационной системы, даже при использовании дорогостоящих серверных СУБД и аппаратного обеспечения. Помимо перечисленных преимуществ, следует также отметить, что современные серверные СУБД обладают широкими возможностями: управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения об ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и соответственно определенные в этих ролях привилегии; резервного копирования и архивации данных, а также оптимизации выполнения запросов; параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных. Модернизация устаревших информационных систем Перед тем, как обсуждать наиболее популярные серверные СУБД, давайте обратим внимание на то, какими способами решается проблема модернизации устаревших информационных систем, с целью перехода к архитектуре <клиент-сервер>, и с какими проблемами можно при этом столкнуться. С проблемой модернизации устаревших информационных систем рано или поздно сталкивается почти каждый разработчик или IT-менеджер. Проблема модернизации информационных систем в России еще долго будет оставаться актуальной. В каждой организации, переживающей процесс модернизации информационной системы, возникают свои проблемы: o В одной пользователи требуют сохранить привычный пользовательский интерфейс; o в другой нужно суметь не просто перенести в новую базу унаследованные данные, но и изменить их в соответствии с вновь возникшими потребностями (например, исправить ошибки, допущенные много лет назад при проектировании данных, или объединить данные из нескольких разных источников); o в третьей организации сохранилось и используется большое количество отчетов, созданных с помощью старой настольной СУБД, и нужно обеспечить возможность их использования в новой информационной системе; o в четвертой процесс ввода новых данных происходит непрерывно, и это накладывает свои ограничения на то, как именно производить процесс замены СУБД и клиентских приложений. В целом варианты модернизации информационной системы можно условно разделить на следующие категории: 1. Замена: только СУБД . Сохранение: структуры базы данных, пользовательских приложений (или небольшой их модернизацией). 2. Замена: и СУБД, и пользовательских приложений. Сохранение: структуры базы данных. 3. Замена: СУБД, пользовательских приложений и одновременная модернизация структуры базы данных. На первый взгляд, первый вариант представляется наиболее безболезненным для пользователей и разработчиков, и он широко пропагандировался некоторое время. Если говорить о первом варианте модернизации, то больше всего повезло пользователям Microsoft Access - процесс замены базы данных Microsoft Access на Microsoft SQL Server происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как эти СУБД (Access, и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных содержатся в комплекте поставки различных серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server. Отметим, однако, что переход к архитектуре <клиент-сервер> отнюдь не исчерпывается переносом данных в новую СУБД. Чтобы воспользоваться всеми преимуществами этой архитектуры, следует также реализовать бизнес-правила, содержащиеся в клиентском приложении, в виде триггеров и хранимых процедур, а затем модифицировать код клиентского приложения, удалив реализацию бизнес-правил и заменив ее на обращения к соответствующим объектам базы данных. Второй вариант модернизации информационной системы представляет собой по существу создание нового проекта по готовой модели данных плюс только что рассмотренный перенос данных в новую СУБД. Что касается третьего варианта модернизации, его можно рассматривать как два самостоятельных проекта: Первый из них представляет собой создание информационной системы практически <с нуля>, второй - заполнение базы унаследованными данными. При этом, поскольку структуры баз данных различны, стандартными утилитами переноса данных (имеющимися в комплектах поставки многих средств разработки и серверных СУБД) здесь обычно обойтись не удается - как правило, в этом случае создаются <одноразовые> приложения, производящие нужные преобразования данных в процессе их переноса. Характерные черты современных серверных СУБД Выше мы обсудили преимущества архитектуры <клиент-сервер>, обусловленные ее базовыми принципами и не зависящие от того, какая конкретно СУБД выбрана. В условиях конкуренции между различными производителями СУБД каждый из них стремится к завоеванию как можно большей части рынка. Это приводит к тому, что они пытаются перегнать друг друга и предоставить потенциальному потребителю как можно больше сервисов различного назначения. Ниже перечислены наиболее характерные для сегодняшнего дня сервисы, предоставляемые серверными СУБД. 1. Реализация для нескольких платформ Почти все современные серверы баз данных существуют в нескольких версиях для различных платформ. Большинство производители серверных СУБД выпускают версии для Linux. Исключением из этого правила является Microsoft SQL Server (для этой СУБД это вполне оправданно, т.к. компания Microsoft сама производит серверные операционные системы). 2. Административные утилиты Администрирование сервера баз данных, конечно, - удел профессионалов. Однако и профессионал предпочтет удобные утилиты администрирования унылому окну с интерфейсом командной строки. Наличие удобных утилит администрирования, как ни странно, иногда оказывается одним из решающих факторов при выборе СУБД. Следует отметить, что производители СУБД, вовремя не заметившие эту тенденцию, оказались лишенными значительной части рынка или практически вытесненными с него. 3. Резервное копирование данных Резервное копирование данных и журналов транзакций поддерживается всеми без исключения коммерческими серверными СУБД. Различия между СУБД в поддержке резервного копирования заключаются в том, возможно ли производить резервное копирование в процессе работы пользователей, и если да, то какие пользовательские операции в это время нельзя выполнять. 4. Обслуживание репликаций Репликация по существу представляет собой гарантированное копирование информации из одной базы в несколько других. Репликации используются для разделения нагрузки между серверами в сети, для перемещения поднаборов данных на вспомогательные серверы, для синхронизации данных на нескольких серверах и многих других целей. В том или ином виде репликации поддерживаются всеми современными серверными СУБД. Различия могут быть лишь в поддержке тех или иных конкретных сценариев репликаций. Если вы планируете иметь несколько серверов баз данных с необходимостью синхронизации данных (например, у вашего предприятия существует несколько филиалов), стоит обратить внимание на то, какие сценарии репликаций поддерживаются в выбранной вами СУБД. 5. Параллельная обработка данных в многопроцессорных системах О возможностях повышения производительности с помощью параллельной обработки запросов в многопроцессорных системах начали говорить после появления первого продукта такого класса - Oracle Parallel Server. Серверы, поддерживающие параллельную обработку, разрешают нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций. В настоящее время подавляющее большинство производителей современных серверных СУБД поставляют на рынок версии, поддерживающие параллельную обработку данных. 6. Поддержка OLAP и создания хранилищ данных OLAP (On-Line Analytical Processing) представляет собой технологию построения многомерных хранилищ данных, как правило, агрегатных, то есть являющихся результатом обработки набора данных. Такие хранилища данных в последнее время широко используются в системах поддержки принятия решений. 7. Распределенные запросы и транзакции О распределенных транзакциях и запросах заговорили, когда наличие нескольких серверов баз данных в одной организации стало обычным явлением. Нужно отметить, что возможности выполнения распределенного запроса или распределенной транзакции поддерживаются сейчас почти всеми серверными СУБД. С этой целью используется механизм двухфазного завершения транзакций (two-phase commit), когда на первом этапе серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить, а на втором этапе происходит реальная фиксация изменений в базах данных. 8. Средства проектирования данных Многие производители серверных СУБД производят также средства анализа бизнес-процессов и проектирования данных, иногда универсальные, а порой ориентированные главным образом на конкретную СУБД (как в случае Oracle Designer/2000). Многие производители СУБД не имеют в своем арсенале собственных средств проектирования данных, ориентируясь на универсальные CASE-средства. Нередко производители СУБД встраивают в административные утилиты несложные средства проектирования данных, позволяющие визуально редактировать схемы данных, как это сделано, например, в Microsoft SQL Server. 9. Поддержка собственных и <чужих> средств разработки и генераторов отчетов Многие производители серверных СУБД выпускают также средства разработки и генераторы отчетов. Практически все производители серверных СУБД делают все возможное для того, чтобы клиентские приложения для их СУБД можно было создавать с помощью других средств разработки. Например, это сделано в клиентских частях Oracle, Microsoft SQL Server, Informix. Производители серверных СУБД, ориентирующиеся только на собственные средства разработки, как правило, оказываются вытесненными с рынка или теряют его часть. 10. Поддержка доступа к данным с помощью Internet Без поддержки публикации данных в Internet или получения данных от удаленных Internet-клиентов сегодня не обходится практически ни одна коммерческая СУБД. Чаще всего эта поддержка Web-технологий осуществляется с помощью Web-серверов собственного производства, либо посредством создания расширений для существующих Web-серверов, либо просто путем включения в комплект поставки утилит, генерирующих Web-страницы согласно определенному расписанию. Наиболее популярные серверные СУБД На сегодняшний день известно более двух десятков серверных СУБД, однако наиболее популярными, исходя из числа продаж и инсталляций, следует признать Oracle, Microsoft SQL Server, Informix, Sybase, DB2. Сведения о производителях перечисленных выше СУБД представлены в следующей таблице: СУБД Производитель Url Oracle Oracle Corp. http://www.oracle.com/ Microsoft SQL Server Microsoft http://www.microsoft.com/ Informix Informix http://www.informix.com/ Sybase Sybase http://www.sybase.com/ DB2 IBM http://www-4.ibm.com/ Самостоятельная работа магистранта под руководством преподавателя (СРМП) Самостоятельная работа магистранта под руководством преподавателя рассчитана на 30 часов работы. Основной целью является закрепление теоретического материала и получение навыков проектирования ИС различной архитектуры, обеспечивающих эффективное функционирование ИС, с использованием современных технологий. Сдача работы заключается в подготовке эссе и презентации. 1 2 № недели Курс Семестр Структурное содержание и объёмы занятий по самостоятельной работе магистранта под руководством преподавателя (СРМП) Таблица 2 3 1 2 1 2 3 Структурное содержание занятий по самостоятельной работе магистранта под руководством преподавателя (СРМП)по модулям дисциплины Литература 4 5 Модуль 1: «Архитектура информационных систем» Тема: «Архитектура ИС» Содержание: компоненты архитектуры /1,2, 3,5,6,7, ИС. 8,9,10,11/ Тема: «Архитектура ИС» Содержание: Обоснование и выбор /1,2, 3,5,6,7, архитектуры ИС. 8,9,10,11/ Тема: «ИС-многоуровневая многокомпонентная структура» /1,2, 3,5,6,7, Содержание: классификация ИС по 8,9,10,11/ Объем часов 6 2 2 2 1 1 1 областям применения, методам организации, масштабу реализации. Модуль 2: «Компоненты информационной системы» Тема: «Технологические решения взаимодействия между /1,2, 3,5,6,7, 3 4 организации компонентами ИС разных архитектур». 8,10,11/ Содержание: принципы и методы организации взаимодействия между компонентами ИС разных архитектур. 2 Тема: «Организационные процессы при /1,2, 3,5,6,7, 2 5 создании информационных систем» Содержание: стандарты и методики 8,10,11/ разработки ИС различных архитектур. Модуль 3: «Типы архитектур информационных систем» 6 Тема: «Принципы функционирования ИС различной архитектуры» /1,2, 3,5,6,7, Содержание: принцип разделения функций 8,9,10,11/ 2 в ИС различной архитектуры. Файлсерверная, клиент-серверная. 7 Тема: «Принципы функционирования ИС различной архитектуры» /1,2, 3,5,6,7, 2 Содержание: принцип разделения функций 8,9,10,11/ 2 в ИС различной архитектуры. Многоуровневая архитектура ИС. 8 Тема: «Функционирование ИС различной архитектуры на основе WEB-технологий» /1,2, 3,5,6,7, 2 Содержание: расширения серверной и 8,9,10,11/ клиентской части в ИС. 9 Тема: «Интерфейсы взаимодействия между компонентами ИС» /1,2, 3,5,6,7, 2 Содержание: понятия интерфейса ИС, 8,9,10,11/ компоненты взаимодействия ИС. Модуль 4: «Реализация информационных систем различной архитектуры» 10 Тема: «Выбор программно-аппаратной платформы для реализации /1,2, 3,4,5,6,7, 2 ИС различной архитектуры» 8,9,10,11/ Содержание: особенности и принципы реализации ИС различной архитектуры. 11 Тема: «Этапы разработки ИС» Содержание: последовательность этапов /1,2, 3,4,5,6,7, 2 разработки ИС. 8,9,10,11/ 2 12 Тема: «Организация информационных потоков». Содержание: понятия и определения. Принципы организации информационных потоков /1,2, 3,4,5,6,7, 8,9,10,11/ 2 Тема: «Реализация клиентской и серверной частей ИС» /1,2, 3,4,5,6,7, Содержание: Реализация механизмов 8,9,10,11/ взаимодействия и передачи информации между компонентами ИС. 14 Тема: «Выбор программно-аппаратной платформы для реализации /1,2, 3,5,6,7, ИС различной архитектуры» 8,9,10,11/ Содержание: особенности и принципы реализации ИС различной архитектуры. ИТОГО по самостоятельной работе магистранта под руководством преподавателя (СРМП) во 2-м семестре: ВСЕГО по самостоятельной работе магистранта под руководством преподавателя (СРМП) 13 1 2 3 4 5 6 3 30 30 Самостоятельная работа магистранта (СРМ) Тематическое содержание и объёмы самостоятельной работы магистранта (СРМ) (2-ой семестр) Таблица 3 Сро Объёмы к сдач Тема и содержание самостоятельной Литература и работы студента в в (№ часах %% неде ли) 2 3 7 8 9 Обзор архитектур информационных систем Файл-серверная, клиент-серверная, /1,2, многоуровневая архитектура 3,5,6,7,8,10, 10 15 3 информационной системы. 11/ Принципы функционирования /2, 3,5,6,7,8,10, информационных систем различной 12 10 6 11/ архитектуры на основе WEB-технологий. Понятиями расширений серверной и клиентской части информационных /2, 3,4,5,6,7,9, систем, с реализациями взаимодействия 11 15 9 8,10,11/ между компонентами информационных систем. Вопросы надежности, быстродействия, /2, 3,5,6,7,8,9, модернизации и защиты информации 12 15 11 10,11/ информационных систем. Разработка информационной системы многоуровневой архитектуры Выбор предметной области и /3,5,6,7,8, проектирование информационной 15 15 12 9,10,11/ системы многоуровневой архитектуры. Выбор программно-аппаратной /3,5,6,7,8,10, платформы, включая приложение, 15 15 14 11/ реализующее базу данных. № недели 1 2 Проектирование и реализация /2, 3,5,6,7,8,10, необходимых программных модулей 11/ пользовательского интерфейса ИТОГО по самостоятельной работе магистранта во 2-м семестре: ВСЕГО по самостоятельной работе магистранта дисциплины: 7 15 15 14 90 100 15 90 100 15
