Контрольные вопросы по теме 1

1 2

ФГАОУ ВО Севастопольский государственный университет

ИНСТИТУТ ЯДЕРНОЙ ЭНЕРГИИ И ПРОМЫШЛЕННОСТИ

КАФЕДРА

ВОЗОБНОВЛЯЕМЫЕ ИСТОЧНИКИ ЭНЕРГИИ

И ЭЛЕКТРИЧЕСКИЕ СИСТЕМЫ И СЕТИ

Шайтор Н.М.

Информационно-коммуникационные технологии

В электроэнергетике

Литература:

1. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

2. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

3. Сейдаметова З.С., Аблялнмова Э.И., Меджитова Л.М., Сейтвелиева С.Н., Темненко В.А. Облачные технологии и образование: под общ. ред. З.С. Сейдаметовой. -Симферополь: «ДИАЙПИ», 2012. - 204 с.

Севастополь

2020

«Утверждаю»

Директор ИЯЭИП

В.А. Кирияченко

«»_____________20___г.

Лекция №10

Тема лекции: Технологии распределенных сервисов

Изучаемые вопросы:

1. Распределённые сетевые приложения

2. Системы обработки информации в масштабе предприятия

3. Основные уровни архитектуры распределенного приложения

4. Контрольные вопросы

Учебная цель:

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

Время: 2 часа

Литература:

4. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

5. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

6. Сейдаметова З.С., Аблялнмова Э.И., Меджитова Л.М., Сейтвелиева С.Н., Темненко В.А. Облачные технологии и образование: под общ. ред. З.С. Сейдаметовой. -Симферополь: «ДИАЙПИ», 2012. - 204 с.

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

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

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

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

Существует два типа сетевых приложений: чисто сетевые (pure) и обособленные (standalone). Чисто сетевые приложения разработаны для применения в сетях, их на отдельных компьютерах использовать не имеет смысла. Наоборот, обособленные приложения призваны работать на отдельном компьютере. Для расширения возможностей они перестроены для работы в сетях.

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

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

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

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

- экономия от масштабирования: новое серверное приложение не требуется для каждого пользователя.

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

Рис. 10.1. Схема взаимодействия централизованного приложения

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

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

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

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

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

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

Рис. 10.2. Схема взаимодействия распределенного приложения

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

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

- пространственное разделение (подразделения организации разнесены в пространстве и зачастую имеют слабо унифицированное программное обеспечение);

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

- ориентация на внешнюю информацию (работа с клиентами и их запросами).

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

Рис. 10.3. Схема распределения вычислений

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

Для развития распределенных вычислительных систем (РВС) нового поколения необходима платформа, удовлетворяющая трем условиям:

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

2) Объединение и интеграция. Вторым условием является наличие простых и удобных способов объединения и интеграции Web -служб.

3) Простота и удобство работы пользователя. Третье условие — это наличие простой и удобной рабочей среды для конечных пользователей и потребителей.

По мнению корпорации Microsoft, этим условиям удовлетворяет платформа.NET. Платформа.NET стимулирует развитие распределенных систем нового поколения и строится на признанных концепциях и стандартах. Платформу.NET образуют следующие компоненты: средства разработки; серверные системы; службы.NET Building Block Services — «строительные блоки»; программное обеспечение для устройств; специализированные рабочие среды (реализованы в виде приложений на платформе.NET). Она дает широкие возможности получения и использования деловой и технической информации и внедрения новых моделей интеллектуальных технических систем и бизнеса, позволяющих сочетать глобальный охват технических систем и рынка с персональным подходом к каждому клиенту.

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

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

- представление данных (пользовательский уровень): пользователи приложения могут просмотреть необходимые данные, отправить запрос на выполнение, ввести в систему новые данные или отредактировать их;

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

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

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

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

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

Рис. 10.4. Уровни архитектуры

Уровни архитектуры распределенного приложения:

- представление данных (пользовательский уровень);

- правила бизнес-логики (уровень обработки данных);

- управление данными (уровень управления данными);

- хранение данных (уровень хранения данных).

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

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

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

Контрольные вопросы

1. Что понимается под термином «распределенные приложения»?

2. Чем отличается схема взаимодействия централизованного и распределённого приложений?

3. Какой язык программирования преимущественно используется для создания сетевых приложений в сети Internet.

4. Достоинства языка программирования Java.

5. Какая платформа удовлетворяет распределенным системам нового поколения?

6. Достоинства платформы.NET?

7. Перечислите основные требования к системе обработки информации в масштабе предприятия.

8. Между какими объектами осуществляются связи в схеме распределения вычислений?

9. Перечислите базовые уровни архитектуры распределенного приложения.

Лекция рассмотрена и одобрена на заседании кафедры ВИЭ и ЭСС,

протокол №______ от______________

Лекцию разработал доцент кафедры ВИЭ и ЭСС

Н.М. Шайтор

«Утверждаю»

Директор ИЯЭИП

В.А. Кирияченко

«»_____________20___г.

Лекция №11

Тема лекции: Сервис-ориентированные архитектуры (SOA, СОА)

Изучаемые вопросы:

1. Элементы и характеристики SOA.

2. Сервис-ориентированный анализ и проектирование.

3. Концепция управления распределенными службами.

4. Контрольные вопросы.

Учебная цель:

Ознакомить студентов с интеллектуальными технологиями технико-экономических систем, сервис-ориентированными архитектурами.

Время: 2 часа

Литература:

1. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

2. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

1. Элементы и характеристики SOA. Архитектура, основанная на сервисах - это новый шаг в направлении комплексного решения проблемы создания распределенных приложений, выполняющихся на многих компьютерах. Она отличается от архитектуры, основанной на объектах (object oriented architecture), тем, что при необходимости выполнить какие-либо действия необходимо просто идентифицировать контракт, описать, как выглядят данные, и получить возможность динамически переключаться между сервисами, реализующими нужную пользователю функциональность, и выбирать сервис из нескольких доступных.

Service-Oriented Architecture (SOA) - это архитектура, обеспечивающая интеграцию и связность, и предназначенная для использования естественно возникающей гетерогенности систем и инфраструктур [4]. Существует много взглядов на концепцию SOA, она развивается, превращая Интернет в утилиту, доступную для всех способов обмена данными, коммерции и коммуникации.

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

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

- оценка имеющихся технологий;

- выбор пилотного энергетического бизнес-проекта и стороны бизнеса;

- распространение в масштабе предприятия;

- распространение в сети партнеров.

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

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

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

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

- домен инфраструктурных служб с субдоменами;

- бизнес-службы утилиты;

- автоматизация на уровне служб и оркестровка;

- виртуализация ресурсов;

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

- домен бизнес-служб;

- домен прикладных служб с субдоменами:

- субдомен модели прикладного программирования;

- субдомен готового коммерческого программного обеспечения;

- субдомен управления информацией.

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

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

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

Рис.11.1. Общая схема SOA

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

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

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

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

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

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

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

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

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

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

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

Таблица 11.1. Мероприятия по обеспечению сервис-ориентированного моделирования

Роль	Проводимые мероприятия
Потребитель	Идентифи-кация сервиса	Катего-ризация сервиса	Решения по раскрытию сервиса	Хореография или композция	Качество обслуживания
Поставщик	Идентифи-кация компонета	Спецификация компонента	Реализация сервиса	Управление сервисом	Реализация стандартов
	Привязка сервиса к компонентам	Разбиение SOA на уровни	Создание технического прототипа	Выбор продукта	Архитектурные решения

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

Мероприятия, описанные выше, можно отобразить в виде потоков в сервис-ориентированном моделировании и архитектурном методе, как это показано на рис. 11.2 [5].

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

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

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

Рис. 11.2. Метод сервис-ориентированного моделирования и архитектуры

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

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

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

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

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

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

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

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

Первая модель управления обычно выполняет сортировку событий, концентрируясь на приеме событий и направлении их в соответствующие группы сортировки для решения. Сортировочная модель управления может эволюционировать в следующий уровень - модель решения элементарных проблем за короткое время, еще до передачи сведений о событиях. Независимо от модели управления работа большинства центров управления IT направляется событиями, которые запускают выполнение действий. Это могут быть события Tivoli Event Console™ или новые уведомления об ошибках (trouble tickets), создаваемые функциями автоматизации-интеграции. Эти системы также могут устанавливать приоритет событий, определять временную последовательность, приоритет, влияние на бизнес и географию.

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

Более высокий уровень IT-управления - это операции, направляемые бизнес-службами. Главная проблема управления на этом уровне заключается в понимании бизнес-служб и их компонентов.

Основные области IT-управления в SOA показаны на рис. 11.3.

Рис. 11.3. Ключевые области управления SOA

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

Контрольные вопросы

1. Что включает в себя термин «сервис-ориентированная архитектура»?

2. Чем отличается архитектура SOА от архитектуры, основанной на объектах?

3. Перечислите основные архитектурные элементы SOA.

4. Какие основные элементы включены в схему взаимодействия SOA.

5. Из каких шагов состоит процесс сервис-ориентированного моделирования?

6. Что включает в себя процесс идентификации сервиса?

7. Что включает в себя мероприятие по спецификации компонента?

8. В чём заключается процесс размещения сервиса?

9. Что такое оркестровка инфраструктуры?

Лекция рассмотрена и одобрена на заседании кафедры ВИЭ и ЭСС,

протокол №______ от______________

Лекцию разработал доцент кафедры ВИЭ и ЭСС

Н.М. Шайтор

«Утверждаю»

Директор ИЯЭИП

В.А. Кирияченко

«»_____________20___г.

Лекция №12

Тема лекции: Облачные технологии

Изучаемые вопросы:

1. Основные характеристики облачных вычислений.

2. Модели расположений и облачных вычислений.

3. Модели развертывания и границы управляемости.

4. Контрольные вопросы.

Учебная цель:

Ознакомить студентов с интеллектуальными технологиями технико-экономических систем, облачными технологиями.

Время: 2 часа

Литература:

4. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

5. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

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

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

Облачная модель поддерживает высокую доступность сервисов и описывается пятью основными характеристиками (essential characteristics), тремя сервисными моделями/моделями предоставления услуг (service models) и четырьмя моделями развертывания (deployment models).

NIST были разработаны следующие обязательные характеристики
облачных вычислений (Essential Characteristics):

1. Самообслуживание по требованию (self service on demand) -

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

2. Свободный сетевой доступ (Broad network access) – запрашиваемые сервисы доступны по сети через стандартные механизмы, поддерживающие использование гетерогенных платформ вне зависимости от используемого терминального устройства (например, мобильных телефонов, ноутбуков, и т.д.).

3. Объединение ресурсов (Resource pooling) - вычислительные ресурсы провайдера организованы в единый пул для обслуживания различных потребителей в многопользовательской модели с возможностью динамического назначения и переназначения различных физических и виртуальных ресурсов в соответствии с требованиями потребителей.

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

4. Быстрая эластичность (Rapid elasticity) - вычислительные возможности могут быть предоставлены быстро и в ряде случаев автоматически для оперативного повышения масштабируемости и быстрого освобождения для оперативного повышения масштабируемости и быстрого освобождения для уменьшения масштабов потребления. Для потребителя эти ресурсы часто представляются как доступные в неограниченном объеме, и могут быть приобретены в любой момент времени в любом количестве.

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

2. Модели расположений и облачных вычислений. В настоящее время существует три основных модели расположения приложений: в инфраструктуре заказчика, у компании-хостера, в облаке.

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

Модель развертывания приложений «Расположение у компании-хостера (hosting)», называвшаяся ранее Application Services Prodiver (ASP), a затем - SaaS или просто «хостинг», получила свое развитие несколько лет назад и является одним из наиболее популярных способов снижения расходов на информационные технологии. Она основана на аренде аппаратной платформы, программного обеспечения, соответствующей инфраструктуры и персонала, выполняющего ее обслуживание. Такая модель отличается меньшим контролем за инфраструктурой, аппаратным и программным обеспечением и базируется на оплате фиксированного числа ресурсов, что обычно предполагает оплату даже в тех случаях, когда арендуемые ресурсы не используются.

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

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

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

Модель облачных вычислений состоит из внешней (front end) и внутренней (back end) частей. Эти два элемента соединены по сети, в большинстве случаев через Интернет. Посредством внешней части пользователь взаимодействует с системой; внутренняя часть - это собственно само облако. Внешняя часть состоит из клиентского компьютера или сети компьютеров предприятия и приложений, используемых для доступа к облаку.

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

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

Основа облака - уровень инфраструктуры. Он состоит из физических активов - серверов, сетевых устройств, дисков и т.д. Существуют поставщики инфраструктуры как сервиса (Infrastructure as a Service - IaaS), например IBM-Cloud.

Промежуточным уровнем является платформа. Она предоставляет инфраструктуру приложений. Платформа как сервис (Platform as a Service - PaaS) предоставляет доступ к операционным системам и соответствующим сервисам. Она дает способ развертывания приложении в облаке при помощи языков программирования и инструментальных средств, поддерживаемых поставщиком. Существуют поставщики PaaS, например Elastic Compute Cloud (ЕС2) от Amazon.

Рис.12.1. Уровни облачных вычислений

Верхний уровень - это уровень приложений, который обычно и изображают в виде облака. Приложения, выполняющиеся в нем, предоставляются пользователям по требованию. Существуют поставщики программного обеспечения как сервиса (Software as a Service - SaaS), например, Google Pack. Google Pack содержит доступные через Интернет приложения - Calendar, Gmail, Google Talk, Docs и многие другие.

На рис.12.2 представлены модели развертывания облака (Deploument Models).

Рис.12.2. Модели развертывания

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

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

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

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

Каждая из моделей частного облака и облака сообщества допускают два варианта сценария развертывания, которые должны рассматриваться по отдельности, по причине влияния на периметр безопасности: будет ли он собственный (on-site) или на аутсоурсинге (outsourced). Гибридная модель развертывания является комбинацией других моделей и, поэтому, гибридное развертывание может предполагать и влияние на периметр безопасности его элементов - "строительных блоков", и уникальные аспекты влияния, возникающие в результате объединения множества систем в комплексные интегрированные системы.

3. Модели развертывания и границы управляемости. Существуют различные модели представления сервисов, к основным моделям относятся:

- Application-as-a-Service ("приложение как сервис") или Software-as-a-Service ("SaaS - программное обеспечение как сервис") - позиционируется как

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

- Platform-as-a-Service ("PaaS - платформа как сервис") - данный сервис предоставляет пользователю компьютерную платформу с установленной операционной системой и некоторым программным обеспечением.

- Infrastructure-as-a-Service ("IaaS - инфраструктура как сервис") – пользователю предоставляется компьютерная инфраструктура, обычно виртуальные платформы (компьютеры), связанные в сеть, которые он самостоятельно настраивает под собственные цели.

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

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

Рис.12.3. Границы управляемости

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

Облачные потребители подразделяются на три группы, основанные на их приложениях/различных сценариях использования (табл. 12.1).

Таблица 12.1. Деятельность облачного пользователя

Тип потребителя	Основная деятельность	Примеры пользователей
SaaS	Использует приложения/сервисы для автоматизации бизнес-процессов	Бизнес-пользователи, администраторы приложений
PaaS	Разрабатывает, тестирует, развертывает и управляет приложениями, развернутыми в облачном окружении	Разработчики приложений, тестировщики, администраторы
IaaS	Создает/устанавливает, управляет и мониторит сервисы для управления ИТ-инфраструктурой	Системные разработчики, администраторы, ИТ-менеджеры

Облачные провайдеры выполняют различные задачи в различных сервисных моделях (табл. 12.2).

Таблица 12.2. Деятельность облачного провайдера

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

Контрольные вопросы

1. Что понимается под термином «облачные вычисления»?

2. Назовите обязательные характеристики облачных вычислений.

3. Из каких частей состоит модель облачных вычислений?

4. На каких уровнях основана концепция облака?

5. Назовите виды облачной инфраструктуры.

6. Перечислите основные модели представления сервисов.

7. В чём заключается основная деятельность облачного провайдера SaaS?

8. В чём заключается основная деятельность облачного провайдера PaaS?

9. В чём заключается основная деятельность облачного провайдера IaaS?

Лекция рассмотрена и одобрена на заседании кафедры ВИЭ и ЭСС,

протокол №______ от______________

Лекцию разработал доцент кафедры ВИЭ и ЭСС

Н.М. Шайтор

«Утверждаю»

Директор ИЯЭИП

В.А. Кирияченко

«»_____________20___г.

Лекция №13

Тема лекции: Агентные технологии

Изучаемые вопросы:

1. Понятие программного агента.

2. Мультиагентные системы и агентные платформы.

3. Безопасность в системах мобильных агентов.

4. Контрольные вопросы.

Учебная цель:

Ознакомить студентов с интеллектуальными технологиями технико-экономических систем, агентными технологиями.

Время: 2 часа

Литература:

7. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

8. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

9. Сейдаметова З.С., Аблялнмова Э.И., Меджитова Л.М., Сейтвелиева С.Н., Темненко В.А. Облачные технологии и образование: под общ. ред. З.С. Сейдаметовой. -Симферополь: «ДИАЙПИ», 2012. - 204 с.

1. Понятие программного агента. В соответствии с определением, данным Э. Таненбаумом, программный агент - это автономный процесс, способный реагировать на среду исполнения и вызывать изменения в среде исполнения, возможно, в кооперации с пользователями или другими агентами [2].

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

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

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

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

- мониторинг данных. Агент может осуществлять извещение пользователя об изменениях в различных источниках данных в реальном времени

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

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

С. Франклин и А. Грэссер в 1996 году предложили следующее обобщенное определение автономного агента [321:

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

Можно выделить следующие основные составляющие автономного программного агента (рис. 13.1):

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

- Актуаторы: блоки агента, обеспечивающие воздействие на окружающую среду.

При работе простой автономный агент руководствуется стандартным набором правил «Если-то» (рис. 13.2). Автономный агент должен обладать следующими свойствами:

- реактивность;

- автономность;

- целенаправленность;

- коммуникативность.

Рис. 13.1. Автономный агент

Разные авторы не совсем одинаково трактуют перечисленные свойства. Попытаемся объяснить их подробнее [1].

Рис. 13.2. Структура автономного агента

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

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

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

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

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

Одна из главнейших особенностей агента - это интеллектуальность. Ин-теллектуальный агент владеет определенными знаниями о себе и об окружающей среде, и на основе этих знаний он способен определять свое поведение (рис. 13.3). Интеллектуальные агенты являются основной сферой интересов агентной технологии. Важна также среда существования агента: это может быть как реальный мир, так и виртуальный, что становится важным в связи с широким распространением сети Интернет. От агентов требуется способность к обучению и даже самообучению [12].

Рис. 13.3. Структура интеллектуального агента

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

2. Мультиагентные системы и агентные платформы. Мультиагентная система (MAC, англ. Multi-agent system) — это система, образованная несколькими взаимодействующими агентами.

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

В мультиагентной системе, рис.13.4, необязательно все агенты взаимодействуют (общаются) между собой. В крайнем случае, общения нет вообще. Такие системы назовем дискретными мультиагентными системами. Второй крайний случай - каждый агент общается с каждым. Такую систему можно назвать полносвязной мультиагентной системой [1].

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

Агентная платформа - это промежуточное программное обеспечение, поддерживающее создание, интерпретацию, запуск, перемещение и уничтожение агентов. Как «воздух» для человека, агентная платформа обеспечивает агентам среду для жизни и работы.

Агентная система - это приложение, однозначно идентифи

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями: