Построить график матлаб. Построение контурных графиков функций двух переменных
Для единого представления данных в сетях с неоднородными устройствами и программным обеспечением международная организация по стандартам ISO (International Standardization Organization) разработала базовую модель связи открытых систем OSI (Open System Interconnection) . Эта модель описывает правила и процедуры передачи данных в различных сетевых средах при организации сеанса связи. Основными элементами модели являются уровни, прикладные процессы и физические средства соединения. На рис. 1.10 представлена структура базовой модели.
Каждый уровень модели OSI выполняет определенную задачу в процессе передачи данных по сети. Базовая модель является основой для разработки сетевых протоколов. OSI разделяет коммуникационные функции в сети на семь уровней, каждый из которых обслуживает различные части процесса области взаимодействия открытых систем.
Модель OSI описывает только системные средства взаимодействия, не касаясь приложений конечных пользователей. Приложения реализуют свои собственные протоколы взаимодействия, обращаясь к системным средствам.
Рис. 1.10. Модель OSI
Если приложение может взять на себя функции некоторых верхних уровней модели OSI, то для обмена данными оно обращается напрямую к системным средствам, выполняющим функции оставшихся нижних уровней модели OSI.
Взаимодействие уровней модели OSI
Модель OSI можно разделить на две различных модели, как показано на рис. 1.11:
Горизонтальную модель на базе протоколов, обеспечивающую механизм взаимодействия программ и процессов на различных машинах;
Вертикальную модель на основе услуг, обеспечиваемых соседними уровнями друг другу на одной машине.
Каждый уровень компьютера-отправителя взаимодействует с таким же уровнем компьютера-получателя, как будто он связан напрямую. Такая связь называется логической или виртуальной связью. В действительности взаимодействие осуществляется между смежными уровнями одного компьютера.
Итак, информация на компьютере-отправителе должна пройти через все уровни. Затем она передается по физической среде до компьютера-получателя и опять проходит сквозь все слои, пока не доходит до того же уровня, с которого она была послана на компьютере-отправителе.
В горизонтальной модели двум программам требуется общий протокол для обмена данными. В вертикальной модели соседние уровни обмениваются данными с использованием интерфейсов прикладных программ API (Application Programming Interface).
Рис. 1.11. Схема взаимодействия компьютеров в базовой эталонной модели OSI
Перед подачей в сеть данные разбиваются на пакеты. Пакет (packet) – это единица информации, передаваемая между станциями сети.
При отправке данных пакет проходит последовательно через все уровни программного обеспечения. На каждом уровне к пакету добавляется управляющая информация данного уровня (заголовок), которая необходима для успешной передачи данных по сети, как это показано на рис. 1.12, где Заг – заголовок пакета, Кон – конец пакета.
На принимающей стороне пакет проходит через все уровни в обратном порядке. На каждом уровне протокол этого уровня читает информацию пакета, затем удаляет информацию, добавленную к пакету на этом же уровне отправляющей стороной, и передает пакет следующему уровню. Когда пакет дойдет до Прикладного уровня, вся управляющая информация будет удалена из пакета, и данные примут свой первоначальный вид.
Рис. 1.12. Формирование пакета каждого уровня семиуровневой модели
Каждый уровень модели выполняет свою функцию. Чем выше уровень, тем более сложную задачу он решает.
Отдельные уровни модели OSI удобно рассматривать как группы программ, предназначенных для выполнения конкретных функций. Один уровень, к примеру, отвечает за обеспечение преобразования данных из ASCII в EBCDIC и содержит программы, необходимые для выполнения этой задачи.
Каждый уровень обеспечивает сервис для вышестоящего уровня, запрашивая в свою очередь сервис у нижестоящего уровня. Верхние уровни запрашивают сервис почти одинаково: как правило, это требование маршрутизации каких-то данных из одной сети в другую. Практическая реализация принципов адресации данных возложена на нижние уровни. На рис. 1.13 приведено краткое описание функций всех уровней.
Рис. 1.13. Функции уровней модели OSI
Рассматриваемая модель определяет взаимодействие открытых систем разных производителей в одной сети. Поэтому она выполняет для них координирующие действия по:
Взаимодействию прикладных процессов;
Формам представления данных;
Единообразному хранению данных;
Управлению сетевыми ресурсами;
Безопасности данных и защите информации;
Диагностике программ и технических средств.
Прикладной уровень (Application layer)
Прикладной уровень обеспечивает прикладным процессам средства доступа к области взаимодействия, является верхним (седьмым) уровнем и непосредственно примыкает к прикладным процессам.
В действительности прикладной уровень – это набор разнообразных протоколов, с помощью которых пользователи сети получают доступ к разделяемым ресурсам, таким как файлы, принтеры или гипертекстовые Web-страницы, а также организуют свою совместную работу, например с помощью протокола электронной почты. Специальные элементы прикладного сервиса обеспечивают сервис для конкретных прикладных программ, таких как программы пересылки файлов и эмуляции терминалов. Если, например программе необходимо переслать файлы, то обязательно будет использован протокол передачи, доступа и управления файлами FTAM (File Transfer, Access, and Management). В модели OSI прикладная программа, которой нужно выполнить конкретную задачу (например, обновить базу данных на компьютере), посылает конкретные данные в виде Дейтаграммы на прикладной уровень. Одна из основных задач этого уровня – определить, как следует обрабатывать запрос прикладной программы, другими словами, какой вид должен принять данный запрос.
Единица данных, которой оперирует прикладной уровень, обычно называется сообщением (message).
Прикладной уровень выполняет следующие функции:
1. Выполнение различных видов работ.
Передача файлов;
Управление заданиями;
Управление системой и т. д;
2. Идентификация пользователей по их паролям, адресам, электронным подписям;
3. Определение функционирующих абонентов и возможности доступа к новым прикладным процессам;
4. Определение достаточности имеющихся ресурсов;
5. Организация запросов на соединение с другими прикладными процессами;
6. Передача заявок представительскому уровню на необходимые методы описания информации;
7. Выбор процедур планируемого диалога процессов;
8. Управление данными, которыми обмениваются прикладные процессы и синхронизация взаимодействия прикладных процессов;
9. Определение качества обслуживания (время доставки блоков данных, допустимой частоты ошибок);
10. Соглашение об исправлении ошибок и определении достоверности данных;
11. Согласование ограничений, накладываемых на синтаксис (наборы символов, структура данных).
Указанные функции определяют виды сервиса, которые прикладной уровень предоставляет прикладным процессам. Кроме этого, прикладной уровень передает прикладным процессам сервис, предоставляемый физическим, канальным, сетевым, транспортным, сеансовым и представительским уровнями.
На прикладном уровне необходимо предоставить в распоряжение пользователей уже переработанную информацию. С этим может справиться системное и пользовательское программное обеспечение.
Прикладной уровень отвечает за доступ приложений в сеть. Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью.
К числу наиболее распространенных протоколов верхних трех уровней относятся:
FTP (File Transfer Protocol) протокол передачи файлов;
TFTP (Trivial File Transfer Protocol) простейший протокол пересылки файлов;
X.400 электронная почта;
Telnet работа с удаленным терминалом;
SMTP (Simple Mail Transfer Protocol) простой протокол почтового обмена;
CMIP (Common Management Information Protocol) общий протокол управления информацией;
SLIP (Serial Line IP) IP для последовательных линий. Протокол последовательной посимвольной передачи данных;
SNMP (Simple Network Management Protocol) простой протокол сетевого управления;
FTAM (File Transfer, Access, and Management) протокол передачи, доступа и управления файлами.
Уровень представления данных (Presentation layer)
Функции данного уровня – представление данных, передаваемых между прикладными процессами, в нужной форме.
Этот уровень обеспечивает то, что информация, передаваемая прикладным уровнем, будет понятна прикладному уровню в другой системе. В случаях необходимости уровень представления в момент передачи информации выполняет преобразование форматов данных в некоторый общий формат представления, а в момент приема, соответственно, выполняет обратное преобразование. Таким образом, прикладные уровни могут преодолеть, например, синтаксические различия в представлении данных. Такая ситуация может возникнуть в ЛВС с неоднотипными компьютерами (IBM PC и Macintosh), которым необходимо обмениваться данными. Так, в полях баз данных информация должна быть представлена в виде букв и цифр, а зачастую и в виде графического изображения. Обрабатывать же эти данные нужно, например, как числа с плавающей запятой.
В основу общего представления данных положена единая для всех уровней модели система ASN.1. Эта система служит для описания структуры файлов, а также позволяет решить проблему шифрования данных. На этом уровне может выполняться шифрование и дешифрование данных, благодаря которым секретность обмена данными обеспечивается сразу для всех прикладных сервисов. Примером такого протокола является протокол Secure Socket Layer (SSL), который обеспечивает секретный обмен сообщениями для протоколов прикладного уровня стека TCP/IP. Этот уровень обеспечивает преобразование данных (кодирование, компрессия и т.п.) прикладного уровня в поток информации для транспортного уровня.
Представительный уровень выполняет следующие основные функции:
1. Генерация запросов на установление сеансов взаимодействия прикладных процессов.
2. Согласование представления данных между прикладными процессами.
3. Реализация форм представления данных.
4. Представление графического материала (чертежей, рисунков, схем).
5. Засекречивание данных.
6. Передача запросов на прекращение сеансов.
Протоколы уровня представления данных обычно являются составной частью протоколов трех верхних уровней модели.
Сеансовый уровень (Session layer)
Сеансовый уровень – это уровень, определяющий процедуру проведения сеансов между пользователями или прикладными процессами.
Сеансовый уровень обеспечивает управление диалогом для того, чтобы фиксировать, какая из сторон является активной в настоящий момент, а также предоставляет средства синхронизации. Последние позволяют вставлять контрольные точки в длинные передачи, чтобы в случае отказа можно было вернуться назад к последней контрольной точке, вместо того чтобы начинать все сначала. На практике немногие приложения используют сеансовый уровень, и он редко реализуется.
Сеансовый уровень управляет передачей информации между прикладными процессами, координирует прием, передачу и выдачу одного сеанса связи. Кроме того, сеансовый уровень содержит дополнительно функции управления паролями, управления диалогом, синхронизации и отмены связи в сеансе передачи после сбоя вследствие ошибок в нижерасположенных уровнях. Функции этого уровня состоят в координации связи между двумя прикладными программами, работающими на разных рабочих станциях. Это происходит в виде хорошо структурированного диалога. В число этих функций входит создание сеанса, управление передачей и приемом пакетов сообщений во время сеанса и завершение сеанса.
На сеансовом уровне определяется, какой будет передача между двумя прикладными процессами:
Полудуплексной (процессы будут передавать и принимать данные по очереди);
Дуплексной (процессы будут передавать данные, и принимать их одновременно).
В полудуплексном режиме сеансовый уровень выдает тому процессу, который начинает передачу, маркер данных. Когда второму процессу приходит время отвечать, маркер данных передается ему. Сеансовый уровень разрешает передачу только той стороне, которая обладает маркером данных.
Сеансовый уровень обеспечивает выполнение следующих функций:
1. Установление и завершение на сеансовом уровне соединения между взаимодействующими системами.
2. Выполнение нормального и срочного обмена данными между прикладными процессами.
3. Управление взаимодействием прикладных процессов.
4. Синхронизация сеансовых соединений.
5. Извещение прикладных процессов об исключительных ситуациях.
6. Установление в прикладном процессе меток, позволяющих после отказа либо ошибки восстановить его выполнение от ближайшей метки.
7. Прерывание в нужных случаях прикладного процесса и его корректное возобновление.
8. Прекращение сеанса без потери данных.
9. Передача особых сообщений о ходе проведения сеанса.
Сеансовый уровень отвечает за организацию сеансов обмена данными между оконечными машинами. Протоколы сеансового уровня обычно являются составной частью протоколов трех верхних уровней модели.
Транспортный уровень (Transport Layer)
Транспортный уровень предназначен для передачи пакетов через коммуникационную сеть. На транспортном уровне пакеты разбиваются на блоки.
На пути от отправителя к получателю пакеты могут быть искажены или утеряны. Хотя некоторые приложения имеют собственные средства обработки ошибок, существуют и такие, которые предпочитают сразу иметь дело с надежным соединением. Работа транспортного уровня заключается в том, чтобы обеспечить приложениям или верхним уровням модели (прикладному и сеансовому) передачу данных с той степенью надежности, которая им требуется. Модель OSI определяет пять классов сервиса, предоставляемых транспортным уровнем. Эти виды сервиса отличаются качеством предоставляемых услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными прикладными протоколами через общий транспортный протокол, а главное способностью к обнаружению и исправлению ошибок передачи, таких как искажение, потеря и дублирование пакетов.
Транспортный уровень определяет адресацию физических устройств (систем, их частей) в сети. Этот уровень гарантирует доставку блоков информации адресатам и управляет этой доставкой. Его главной задачей является обеспечение эффективных, удобных и надежных форм передачи информации между системами. Когда в процессе обработки находится более одного пакета, транспортный уровень контролирует очередность прохождения пакетов. Если проходит дубликат принятого ранее сообщения, то данный уровень опознает это и игнорирует сообщение.
В функции транспортного уровня входят:
1. Управление передачей по сети и обеспечение целостности блоков данных.
2. Обнаружение ошибок, частичная их ликвидация и сообщение о неисправленных ошибках.
3. Восстановление передачи после отказов и неисправностей.
4. Укрупнение или разделение блоков данных.
5. Предоставление приоритетов при передаче блоков (нормальная или срочная).
6. Подтверждение передачи.
7. Ликвидация блоков при тупиковых ситуациях в сети.
Начиная с транспортного уровня, все вышележащие протоколы реализуются программными средствами, обычно включаемыми в состав сетевой операционной системы.
Наиболее распространенные протоколы транспортного уровня включают в себя:
TCP (Transmission Control Protocol) протокол управления передачей стека TCP/IP;
UDP (User Datagram Protocol) пользовательский протокол дейтаграмм стека TCP/IP;
NCP (NetWare Core Protocol) базовый протокол сетей NetWare;
SPX (Sequenced Packet eXchange) упорядоченный обмен пакетами стека Novell;
TP4 (Transmission Protocol) – протокол передачи класса 4.
Сетевой уровень (Network Layer)
Сетевой уровень обеспечивает прокладку каналов, соединяющих абонентские и административные системы через коммуникационную сеть, выбор маршрута наиболее быстрого и надежного пути.
Сетевой уровень устанавливает связь в вычислительной сети между двумя системами и обеспечивает прокладку виртуальных каналов между ними. Виртуальный или логический канал – это такое функционирование компонентов сети, которое создает взаимодействующим компонентам иллюзию прокладки между ними нужного тракта. Кроме этого, сетевой уровень сообщает транспортному уровню о появляющихся ошибках. Сообщения сетевого уровня принято называть пакетами (packet). В них помещаются фрагменты данных. Сетевой уровень отвечает за их адресацию и доставку.
Прокладка наилучшего пути для передачи данных называется маршрутизацией, и ее решение является главной задачей сетевого уровня. Эта проблема осложняется тем, что самый короткий путь не всегда самый лучший. Часто критерием при выборе маршрута является время передачи данных по этому маршруту; оно зависит от пропускной способности каналов связи и интенсивности трафика, которая может изменяться с течением времени. Некоторые алгоритмы маршрутизации пытаются приспособиться к изменению нагрузки, в то время как другие принимают решения на основе средних показателей за длительное время. Выбор маршрута может осуществляться и по другим критериям, например, надежности передачи.
Протокол канального уровня обеспечивает доставку данных между любыми узлами только в сети с соответствующей типовой топологией. Это очень жесткое ограничение, которое не позволяет строить сети с развитой структурой, например, сети, объединяющие несколько сетей предприятия в единую сеть, или высоконадежные сети, в которых существуют избыточные связи между узлами.
Таким образом, внутри сети доставка данных регулируется канальным уровнем, а вот доставкой данных между сетями занимается сетевой уровень. При организации доставки пакетов на сетевом уровне используется понятие номер сети. В этом случае адрес получателя состоит из номера сети и номера компьютера в этой сети.
Сети соединяются между собой специальными устройствами, называемыми маршрутизаторами. Маршрутизатор – это устройство, которое собирает информацию о топологии межсетевых соединений и на ее основании пересылает пакеты сетевого уровня в сеть назначения. Для того чтобы передать сообщение от отправителя, находящегося в одной сети, получателю, находящемуся в другой сети, нужно совершить некоторое количество транзитных передач (hops) между сетями, каждый раз, выбирая подходящий маршрут. Таким образом, маршрут представляет собой последовательность маршрутизаторов, по которым проходит пакет.
Сетевой уровень отвечает за деление пользователей на группы и маршрутизацию пакетов на основе преобразования MAC-адресов в сетевые адреса. Сетевой уровень обеспечивает также прозрачную передачу пакетов на транспортный уровень.
Сетевой уровень выполняет функции:
1. Создание сетевых соединений и идентификация их портов.
2. Обнаружение и исправление ошибок, возникающих при передаче через коммуникационную сеть.
3. Управление потоками пакетов.
4. Организация (упорядочение) последовательностей пакетов.
5. Маршрутизация и коммутация.
6. Сегментирование и объединение пакетов.
На сетевом уровне определяется два вида протоколов. Первый вид относится к определению правил передачи пакетов с данными конечных узлов от узла к маршрутизатору и между маршрутизаторами. Именно эти протоколы обычно имеют в виду, когда говорят о протоколах сетевого уровня. Однако часто к сетевому уровню относят и другой вид протоколов, называемых протоколами обмена маршрутной информацией. С помощью этих протоколов маршрутизаторы собирают информацию о топологии межсетевых соединений.
Протоколы сетевого уровня реализуются программными модулями операционной системы, а также программными и аппаратными средствами маршрутизаторов.
Наиболее часто на сетевом уровне используются протоколы:
IP (Internet Protocol) протокол Internet, сетевой протокол стека TCP/IP, который предоставляет адресную и маршрутную информацию;
IPX (Internetwork Packet Exchange) протокол межсетевого обмена пакетами, предназначенный для адресации и маршрутизации пакетов в сетях Novell;
X.25 международный стандарт для глобальных коммуникаций с коммутацией пакетов (частично этот протокол реализован на уровне 2);
CLNP (Connection Less Network Protocol) сетевой протокол без организации соединений.
Канальный уровень (Data Link)
Единицей информации канального уровня являются кадры (frame). Кадры – это логически организованная структура, в которую можно помещать данные. Задача канального уровня – передавать кадры от сетевого уровня к физическому уровню.
На физическом уровне просто пересылаются биты. При этом не учитывается, что в некоторых сетях, в которых линии связи используются попеременно несколькими парами взаимодействующих компьютеров, физическая среда передачи может быть занята. Поэтому одной из задач канального уровня является проверка доступности среды передачи. Другой задачей канального уровня является реализация механизмов обнаружения и коррекции ошибок.
Канальный уровень обеспечивает корректность передачи каждого кадра, помещая специальную последовательность бит, в начало и конец каждого кадра, чтобы отметить его, а также вычисляет контрольную сумму, суммируя все байты кадра определенным способом и добавляя контрольную сумму к кадру. Когда кадр приходит, получатель снова вычисляет контрольную сумму полученных данных и сравнивает результат с контрольной суммой из кадра. Если они совпадают, кадр считается правильным и принимается. Если же контрольные суммы не совпадают, то фиксируется ошибка.
Задача канального уровня – брать пакеты, поступающие с сетевого уровня и готовить их к передаче, укладывая в кадр соответствующего размера. Этот уровень обязан определить, где начинается и где заканчивается блок, а также обнаруживать ошибки передачи.
На этом же уровне определяются правила использования физического уровня узлами сети. Электрическое представление данных в ЛВС (биты данных, методы кодирования данных и маркеры) распознаются на этом и только на этом уровне. Здесь обнаруживаются и исправляются (путем требований повторной передачи данных) ошибки.
Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.Х делят канальный уровень на два подуровня:
LLC (Logical Link Control) управление логическим каналом осуществляет логический контроль связи. Подуровень LLC обеспечивает обслуживание сетевого уровня и связан с передачей и приемом пользовательских сообщений.
MAC (Media Assess Control) контроль доступа к среде. Подуровень MAC регулирует доступ к разделяемой физической среде (передача маркера или обнаружение коллизий или столкновений) и управляет доступом к каналу связи. Подуровень LLC находится выше подуровня МАC.
Канальный уровень определяет доступ к среде и управление передачей посредством процедуры передачи данных по каналу.
При больших размерах передаваемых блоков данных канальный уровень делит их на кадры и передает кадры в виде последовательностей.
При получении кадров уровень формирует из них переданные блоки данных. Размер блока данных зависит от способа передачи, качества канала, по которому он передается.
В локальных сетях протоколы канального уровня используются компьютерами, мостами, коммутаторами и маршрутизаторами. В компьютерах функции канального уровня реализуются совместными усилиями сетевых адаптеров и их драйверов.
Канальный уровень может выполнять следующие виды функций:
1. Организация (установление, управление, расторжение) канальных соединений и идентификация их портов.
2. Организация и передача кадров.
3. Обнаружение и исправление ошибок.
4. Управление потоками данных.
5. Обеспечение прозрачности логических каналов (передачи по ним данных, закодированных любым способом).
Наиболее часто используемые протоколы на канальном уровне включают:
HDLC (High Level Data Link Control) протокол управления каналом передачи данных высокого уровня, для последовательных соединений;
IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x;
Ethernet сетевая технология по стандарту IEEE 802.3 для сетей, использующая шинную топологию и коллективный доступ с прослушиванием несущей частоты и обнаружением конфликтов;
Token ring сетевая технология по стандарту IEEE 802.5, использующая кольцевую топологию и метод доступа к кольцу с передачей маркера;
FDDI (Fiber Distributed Date Interface Station) сетевая технология по стандарту IEEE 802.6, использующая оптоволоконный носитель;
X.25 международный стандарт для глобальных коммуникаций с коммутацией пакетов;
Frame relay сеть, организованная из технологий Х25 и ISDN.
Физический уровень (Physical Layer)
Физический уровень предназначен для сопряжения с физическими средствами соединения. Физические средства соединения – это совокупность физической среды, аппаратных и программных средств, обеспечивающая передачу сигналов между системами.
Физическая среда – это материальная субстанция, через которую осуществляется передача сигналов. Физическая среда является основой, на которой строятся физические средства соединения. В качестве физической среды широко используются эфир, металлы, оптическое стекло и кварц.
Физический уровень состоит из Подуровня стыковки со средой и Подуровня преобразования передачи.
Первый из них обеспечивает сопряжение потока данных с используемым физическим каналом связи. Второй осуществляет преобразования, связанные с применяемыми протоколами. Физический уровень обеспечивает физический интерфейс с каналом передачи данных, а также описывает процедуры передачи сигналов в канал и получения их из канала. На этом уровне определяются электрические, механические, функциональные и процедурные параметры для физической связи в системах. Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включают:
Тип кабелей и разъемов;
Разводку контактов в разъемах;
Схему кодирования сигналов для значений 0 и 1.
Физический уровень выполняет следующие функции:
1. Установление и разъединение физических соединений.
2. Передача сигналов в последовательном коде и прием.
3. Прослушивание, в нужных случаях, каналов.
4. Идентификация каналов.
5. Оповещение о появлении неисправностей и отказов.
Оповещение о появлении неисправностей и отказов связано с тем, что на физическом уровне происходит обнаружение определенного класса событий, мешающих нормальной работе сети (столкновение кадров, посланных сразу несколькими системами, обрыв канала, отключение питания, потеря механического контакта и т.д.). Виды сервиса, предоставляемого канальному уровню, определяются протоколами физического уровня. Прослушивание канала необходимо в тех случаях, когда к одному каналу подключается группа систем, но одновременно передавать сигналы разрешается только одной из них. Поэтому прослушивание канала позволяет определить, свободен ли он для передачи. В ряде случаев для более четкого определения структуры физический уровень разбивается на несколько подуровней. Например, физический уровень беспроводной сети делится на три подуровня (рис. 1.14).
Рис. 1.14. Физический уровень беспроводной локальной сети
Функции физического уровня реализуются во всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером. Повторители являются единственным типом оборудования, которое работает только на физическом уровне.
Физический уровень может обеспечивать как асинхронную (последовательную) так и синхронную (параллельную) передачу, которая применяется для некоторых мэйнфреймов и мини-компьютеров. На Физическом уровне должна быть определена схема кодирования для представления двоичных значений с целью их передачи по каналу связи. Во многих локальных сетях используется манчестерское кодирование.
Примером протокола физического уровня может служить спецификация 10Base-T технологии Ethernet, которая определяет в качестве используемого кабеля неэкранированную витую пару категории 3 с волновым сопротивлением 100 Ом, разъем RJ-45, максимальную длину физического сегмента 100 метров, манчестерский код для представления данных и другие характеристики среды и электрических сигналов.
К числу наиболее распространенных спецификаций физического уровня относятся:
EIA-RS-232-C, CCITT V.24/V.28 – механические/электрические характеристики несбалансированного последовательного интерфейса;
EIA-RS-422/449, CCITT V.10 – механические, электрические и оптические характеристики сбалансированного последовательного интерфейса;
Ethernet – сетевая технология по стандарту IEEE 802.3 для сетей, использующая шинную топологию и коллективный доступ с прослушиванием несущей и обнаружением конфликтов;
Token ring – сетевая технология по стандарту IEEE 802.5, использующая кольцевую топологию и метод доступа к кольцу с передачей маркера.
В сети производится множество операций, обеспечивающих передачу данных от компьютера к компьютеру. Пользователя не интересует, как именно это происходит, ему необходим доступ к приложению или компьютерному ресурсу, расположенному в другой компьютерной сети. В действительности же вся передаваемая информация проходит много этапов обработки.
Прежде всего, она разбивается на блоки, каждый из которых снабжается управляющей информацией. Полученные блоки оформляются в виде сетевых пакетов, потом эти пакеты кодируются, передаются с помощью электрических или световых сигналов по сети в соответствии с выбранным методом доступа, затем из принятых пакетов вновь восстанавливаются заключенные в них блоки данных, блоки соединяются в данные, которые и становятся доступны другому приложению. Это, конечно, упрощенное описание происходящих процессов.
Часть из указанных процедур реализуется только программно, другая часть – аппаратно, а какие-то операции могут выполняться как программами, так и аппаратурой.
Упорядочить все выполняемые процедуры, разделить их на уровни и подуровни, взаимодействующие между собой, как раз и призваны модели сетей. Эти модели позволяют правильно организовать взаимодействие как абонентам внутри одной сети, так и самым разным сетям на различных уровнях . В настоящее время наибольшее распространение получила так называемая эталонная модель обмена информацией открытой системы OSI ( Open System Interconnection ). Под термином " открытая система " понимается не замкнутая в себе система, имеющая возможность взаимодействия с какими-то другими системами (в отличие от закрытой системы).
Эталонная модель OSI
Модель OSI была предложена Международной организацией стандартов ISO ( International Standards Organization) в 1984 году. С тех пор ее используют (более или менее строго) все производители сетевых продуктов. Как и любая универсальная модель, OSI довольно громоздка, избыточна, и не слишком гибка. Поэтому реальные сетевые средства, предлагаемые различными фирмами, не обязательно придерживаются принятого разделения функций. Однако знакомство с моделью OSI позволяет лучше понять, что же происходит в сети.
Все сетевые функции в модели разделены на 7 уровней ( рис. 5.1). При этом вышестоящие уровни выполняют более сложные, глобальные задачи, для чего используют в своих целях нижестоящие уровни , а также управляют ими. Цель нижестоящего уровня – предоставление услуг вышестоящему уровню , причем вышестоящему уровню не важны детали выполнения этих услуг. Нижестоящие уровни выполняют более простые и конкретные функции. В идеале каждый уровень взаимодействует только с теми, которые находятся рядом с ним (выше и ниже него). Верхний уровень соответствует прикладной задаче, работающему в данный момент приложению, нижний – непосредственной передаче сигналов по каналу связи.
Рис.
5.1.
Модель OSI относится не только к локальным сетям, но и к любым сетям связи между компьютерами или другими абонентами. В частности, функции сети Интернет также можно поделить на уровни в соответствии с моделью OSI . Принципиальные отличия локальных сетей от глобальных, с точки зрения модели OSI , наблюдаются только на нижних уровнях модели.
Функции, входящие в показанные на рис. 5.1 уровни , реализуются каждым абонентом сети. При этом каждый уровень на одном абоненте работает так, как будто он имеет прямую связь с соответствующим уровнем другого абонента. Между одноименными уровнями абонентов сети существует виртуальная (логическая) связь , например, между прикладными уровнями взаимодействующих по сети абонентов. Реальную же, физическую связь ( кабель , радиоканал ) абоненты одной сети имеют только на самом нижнем, первом, физическом уровне . В передающем абоненте информация проходит все уровни , начиная с верхнего и заканчивая нижним. В принимающем абоненте полученная информация совершает обратный путь : от нижнего уровня к верхнему ( рис. 5.2).
Рис. 5.2.
Данные, которые необходимо передать по сети, на пути от верхнего (седьмого) уровня до нижнего (первого) проходят процесс инкапсуляции ( рис. 4.6). Каждый нижеследующий уровень не только производит обработку данных, приходящих с более высокого уровня , но и снабжает их своим заголовком, а также служебной информацией. Такой процесс обрастания служебной информацией продолжается до последнего (физического) уровня . На физическом
Знаете ли Вы,
что такое мысленный эксперимент, gedanken experiment?
Это несуществующая практика, потусторонний опыт, воображение того, чего нет на самом деле. Мысленные эксперименты подобны снам наяву. Они рождают чудовищ. В отличие от физического эксперимента, который является опытной проверкой гипотез, "мысленный эксперимент" фокуснически подменяет экспериментальную проверку желаемыми, не проверенными на практике выводами, манипулируя логикообразными построениями, реально нарушающими саму логику путем использования недоказанных посылок в качестве доказанных, то есть путем подмены. Таким образом, основной задачей заявителей "мысленных экспериментов" является обман слушателя или читателя путем замены настоящего физического эксперимента его "куклой" - фиктивными рассуждениями под честное слово без самой физической проверки.
Заполнение физики воображаемыми, "мысленными экспериментами" привело к возникновению абсурдной сюрреалистической, спутанно-запутанной картины мира. Настоящий исследователь должен отличать такие "фантики" от настоящих ценностей.
Релятивисты и позитивисты утверждают, что "мысленный эксперимент" весьма полезный интрумент для проверки теорий (также возникающих в нашем уме) на непротиворечивость. В этом они обманывают людей, так как любая проверка может осуществляться только независимым от объекта проверки источником. Сам заявитель гипотезы не может быть проверкой своего же заявления, так как причина самого этого заявления есть отсутствие видимых для заявителя противоречий в заявлении.
Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").
Максимально, на что может претендовать "мысленный эксперимент" - это только на внутреннюю непротиворечивость гипотезы в рамках собственной, часто отнюдь не истинной логики заявителя. Соответсвие практике это не проверяет. Настоящая проверка может состояться только в действительном физическом эксперименте.
Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.
Предлагаемая эталонная модель BPM (Business Process Management) основывается на цепочке следующих предпосылок:
Повышение производительности предприятия как сложной системы требует ее рационального построения, а процессное управление является наиболее современной концепцией для такого построения;
BPM (как дисциплина) предлагает системный подход к реализации процессного управления;
На каждом процессно-управляемом предприятии есть своя BPM-система - портфолио всех бизнес-процессов, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио;
Гибкость BPM-системы предприятия является основным фактором ее успеха;
Специализированная программная платформа (BPM suite) для реализации BPM-системы предприятия необходима, но недостаточна, так как BPM занимает особое место в архитектуре предприятия.
Цель: повышение производительности предприятия
Для управления своей производительностью большинство предприятий используют принцип обратной связи (рис. 1), позволяющий адаптироваться к внешней бизнес-экосистеме путем выполнения определенной последовательности действий:
Измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или индикаторов, например, процент возвращающихся клиентов);
Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);
Определение стратегии развития бизнеса предприятия;
Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).
В соответствии с классической рекомендацией Эдварда Деминга, автора многочисленных работ в области управления качеством, в том числе известной книги «Выход из кризиса», все усовершенствования должны проводиться циклично, непрерывно и с проверкой на каждом цикле. Степень и частота этих усовершенствований зависят от конкретной ситуации, но рекомендуется делать такие циклы достаточно компактными. Различные усовершенствования могут затрагивать различные аспекты работы предприятия. Вопрос в том, как предприятие может достигнуть наилучших результатов в каждом конкретном случае? Существуют две объективные предпосылки для оптимизации деятельности предприятия как единого целого:
Обеспечение руководства надлежащей информацией и инструментами для принятия решения;
Гарантия того, что бизнес-система предприятия способна к осуществлению необходимых изменений в необходимом темпе.
Наиболее современная концепция организации работы предприятия - процессное управление, при котором процессы и службы становятся явными.
Процессное управление
Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, и др.), что службы и процессы - это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, как портфолио бизнес-процессов и методов управления ими.
Процессное управление, как управленческая концепция, постулирует целесообразность координации деятельности отдельных служб предприятия с целью получения определенного результата при помощи явно и формально определенных бизнес-процессов. При этом службы - это операционно независимые функциональные единицы; у предприятия может быть много элементарных нанослужб, которые организованы в мегаслужбу (собственно предприятие).
Использование явного определения координации позволяет формализовать взаимозависимости между службами. Наличие такой формализации дает возможность использовать различные методы (моделирование, автоматизированная проверка, контроль за версиями, автоматизированное выполнение и т.д.) для улучшения понимания бизнеса (для принятия более правильных решений) и повышения скорости развития бизнес-систем (для более быстрой реализации изменений).
Кроме процессов и служб, бизнес-системы предприятий работают с событиями, правилами, данными, индикаторами работы, ролями, документами и т.д.
Для реализации процессного управления предприятия используют три популярные дисциплины постоянного усовершенствования бизнес-процессов: ISO 9000, Six Sigma и «бережливое», или «экономное», производство (Lean production). Они воздействуют на различные области бизнес-системы предприятия, однако всегда предусматривается сбор данных о фактически проделанной работе и использование некой модели бизнес-процессов для принятия решений (хотя иногда эта модель находится только в чьей-то голове). В то же самое время они предлагают различные и взаимодополняющие методы для того, чтобы определить, какие именно изменения необходимы для улучшения функционирования бизнес-системы предприятия.
Что моделируете, то и выполняете
На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.
В чем основная трудность оптимизации деятельности такого предприятия? Различные части бизнес-системы используют разные описания одного и того же бизнес-процесса. Обычно эти описания существуют отдельно и разработаны разными людьми, обновляются различными темпами, не обмениваются информацией, а некоторых из них просто нет в явном виде. Наличие единого описания бизнес-процессов предприятия позволяет устранить этот недостаток. Это описание должно быть явно и формально определено, чтобы одновременно служить моделью для моделирования, исполняемой программой и документацией, легко понимаемой всеми вовлеченными в бизнес-процесс сотрудниками.
Такое описание - основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).
На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation , графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language , формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.
Ситуация усугубляется тем, что за различными форматами стоят различные производители и каждый старается «протолкнуть» на рынок свое решение. Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание - сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML , успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов. Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик - более подробную и т.п.).
Все это не означает, что BPEL или XPDL станут ненужными - их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.
Дисциплина BPM в культуре предприятия
Кроме процессов и служб, бизнес-системы предприятия работают с такими дополнительными артефактами, как:
события (events) - явления, происшедшие в пределах и вне границ предприятия, на которые возможна некая реакция бизнес-системы, например, при получении заказа от клиента необходимо начать бизнес-процесс обслуживания;
объекты (data and documents objects) - формальные информационные описания реальных вещей и людей, образующих бизнес; это информация на входе и выходе бизнес-процесса, например, бизнес-процесс обслуживания заказа получает на входе собственно формуляр заказа и информацию о клиенте, а на выходе формирует отчет о выполнении заказа;
деятельности (activities) - мелкие работы, преобразующие объекты, например автоматические деятельности типа проверки кредитной карты клиента или деятельности, осуществляемые человеком, такие как визирование документа руководством;
правила (rules) - ограничения и условия, при которых функционирует предприятие, например, выдача кредита на определенную сумму должна утверждаться генеральным директором банка;
роли (roles) - понятия, представляющие соответствующие навыки или обязанности, требуемые для выполнения определенных действий, например, только менеджер высшего звена может подписать конкретный документ;
аудиторские следы (audit trails) - информация о выполнении конкретного бизнес-процесса, например, кто сделал, что и с каким результатом;
основные индикаторы производительности (Key Performance Indicator, KPI) - ограниченное число показателей, измеряющих степень достижения поставленных целей.
Рис. 4 иллюстрирует распределение артефактов между различными частями бизнес-системы предприятия. Выражение «процессы (как шаблоны)» означает абстрактные описания (модели или планы) процессов;
выражение «процессы (как экземпляры)» означает фактические результаты выполнения этих шаблонов. Обычно шаблон используется для создания многих экземпляров (подобно незаполненному бланку, который многократно копируется для заполнения разными людьми). Выражение «службы (как интерфейсы)» означает формальные описания служб, которые доступны для их потребителей; выражение «службы (как программы)» означает средства выполнения служб - такие средства обеспечиваются поставщиками служб.
Для успешной работы со всей сложной совокупностью взаимозависимых артефактов у любого процессно-управляемого предприятия есть своя собственная BPM-система - это портфолио всех бизнес-процессов предприятия, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио. Другими словами, BPM-система предприятия ответственна за синергетическое функционирование различных частей бизнес-системы предприятия.
BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы.
Улучшение BPM-системы предприятия, помимо чисто технических аспектов, должно учитывать социо-технические вопросы. У BPM-системы предприятия есть много заинтересованных лиц, каждое из которых решает свои задачи, воспринимает BPM-дисциплину своим образом и работает со своими артефактами. Для успешного развития BPM-системы предприятия необходимо обратить особое внимание на проблемы всех заинтересованных лиц и заранее объяснить им, как улучшение BPM-системы предприятия изменит их работу к лучшему. Крайне важно достигнуть единого понимания всех артефактов среди всех заинтересованных лиц.
Специализированное ПО для реализации BPM-систем
Растущая популярность и большой потенциал BPM вызвали появление нового класса корпоративного ПО - BPM suite, или BPMS, содержащего следующие типичные компоненты (рис. 5):
Инструмент моделирования (Process modelling tool) - графическая программа для манипулирования такими артефактами, как события, правила, процессы, активности, службы и т.д.;
Инструмент тестирования (Process testing tool) - среда функционального тестирования, которое позволяет «исполнять» процесс по различным сценариям;
Хранилище шаблонов (Process template repository) - база данных шаблонов бизнес-процессов с поддержкой различных версий одного и того же шаблона;
Исполнитель процессов (Process execution engine);
Хранилище экземпляров (Process instance repository) - база данных для выполняемых и уже выполненных экземпляров бизнес-процессов;
Список работ (Work list) - интерфейс между BPM suite и пользователем, выполняющим некоторые активности в рамках одного или нескольких бизнес-процессов;
Приборная панель (Dashboard) - интерфейс оперативного контроля за исполнением бизнес-процессов;
Инструмент анализа (Process analysis tool) - среда для изучения тенденции исполнения бизнес-процессов;
Инструмент имитационного моделирования (Process simulation tool) - среда для тестирования производительности бизнес-процессов.
Необходимость взаимодействия между BPM suite и корпоративным ПО, которое поддерживает другие артефакты, вызвала появление нового класса корпоративного ПО - Business Process Platform (BPP). Типичные технологии BPP (рис. 6):
Business Event Management (BEM) - анализ бизнес-событий в режиме реального времени и запуск соответствующих бизнес-процессов (BEM связан с Complex Event Processing (CEP) и Event Driven Architecture (EDA));
Business Rules Management (BRM) - явное и формальное кодирование бизнес-правил, которые могут модифицироваться пользователями;
Master Data Management (MDM) - упрощение работы со структурированными данными за счет устранения хаоса при использовании одних и тех же данных;
Enterprise Content Management (ECM) - управление корпоративной информацией, предназначенной для человека (обобщение понятия документ);
Configuration Management Data Base (CMDB) - централизованное описание всей информационно-вычислительной среды предприятия, используемое для привязки BPM к информационно-вычислительным ресурсам предприятия;
Role-Based Access Control (RBAC) - управления доступом к информации с целью эффективного разделения контрольных и исполнительских полномочий (separation of duty);
Business Activity Monitoring (BAM) - оперативный контроль функционирования предприятия;
Business Intelligence (BI) - анализ характеристик и тенденций работы предприятия;
Service-Oriented Architecture (SOA) - архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб, который используется для реализации, выполнения и управления службами;
Enterprise Service Bus (ESB) - среда коммуникаций между службами в рамках SOA.
Таким образом, дисциплина BPM способна обеспечить единое, формальное и выполнимое описание бизнес-процессов, которое может использоваться в различных инструментах BPM suite, причем реальные данные собираются во время выполнения бизнес-процессов. Вместе с тем высокая гибкость BPM-системы предприятия не гарантируется автоматически после покупки BPM suite или BPP - способность конкретной BPM-системы развиться в необходимом темпе должна проектироваться, реализовываться и постоянно контролироваться. Как и здоровье человека, все это нельзя купить.
BPM в архитектуре предприятия
Необходимость вовлечения практически всего корпоративного ПО в единую логику улучшения BPM-системы предприятия поднимает вопрос о роли и месте BPM в архитектуре предприятия (Enterprise Architecture, EA). EA является на сегодня устоявшейся практикой ИТ-департаментов по упорядочению информационно-вычислительной среды предприятия. В основе EA лежат следующие правила:
Текущая ситуация с информационно-вычислительной средой предприятия тщательно документируется как исходная точка as-is;
Желаемая ситуация документируется как конечная точка to-be;
Строится и исполняется долгосрочный план по переводу информационно-вычислительной среды предприятия из одной точки в другую.
Все это, казалась бы, вполне разумно, но сразу видна разница с подходом, предусматривающим небольшие улучшения, который лежит в основе процессного управления. Как совместить эти два противоположных подхода?
Дисциплина BPM может решить основную проблему EA - дать объективную оценку производственно-хозяйственных возможностей (а не только информационно-вычислительных) того, что будет в точке to-be. Несмотря на то что EA описывает полную номенклатуру артефактов предприятия (его генотип), она не может достоверно сказать, какие изменения в этом генотипе влияют на конкретные производственно-хозяйственные характеристики предприятия, то есть на фенотип предприятия (cовокупность характеристик, присущих индивиду на определенной стадии развития).
Со своей стороны, дисциплина BPM структурирует взаимозависимости между артефактами в виде явных и исполняемых моделей (бизнес-процесс - это пример взаимозависимости между такими артефактами, как события, роли, правила и т.п.). Наличие таких исполняемых моделей позволяет с некоторой степенью достоверности оценить производственно-хозяйственные характеристики предприятия при изменении генотипа предприятия.
Естественно, чем больше взаимозависимостей между артефактами смоделировано и чем достовернее эти модели, тем точнее такие оценки. Потенциально симбиоз номенклатуры артефактов предприятия и формально определенных взаимозависимостей между ними дает исполняемую модель предприятия на конкретный момент времени. Если строить такие исполняемые модели на единых принципах (например, krislawrence.com), то появляется возможность для сравнения эффекта от применения различных стратегий развития предприятия и появления более систематических и предсказуемых технологий по преобразованию одних исполняемых моделей в другие.
В некотором смысле комбинация EA+BPM может стать своего рода навигатором, который обеспечивает руководство и практическую помощь в развитии бизнеса и ИТ при реализации генеральной линии предприятия.
Не секрет, что сегодня производители ПО определяют и развивают BPM по-разному. Однако, более перспективный путь развития BPM - это BPM, ориентированный на нужды конечных потребителей, и эталонная модель BPM - первый шаг по созданию единого понимания BPM среди всех заинтересованных лиц.
Предлагаемая в статье эталонная модель основана на практическом опыте автора по проектированию, разработке и сопровождению различных корпоративных решений. В частности, эта модель использовалась для автоматизации ежегодного производства более 3 тыс. сложных электронных продуктов со средним временем подготовки продукта в несколько лет. В результате обслуживание и развитие этой производственной системы потребовали в несколько раз меньше ресурсов, чем при традиционном подходе. n
Александр Самарин ([email protected]) - корпоративный архитектор ИТ-департамента правительства кантона Женева (Швейцария).
Process Frameworks для BPM
Подход к реализации технологий управления бизнес-процессами, упрощающий внедрение BPM-систем, подразумевает четкое определение бизнес-задачи и соответствующих ей бизнес-процессов; реализацию этих процессов за срок не более трех месяцев с целью демонстрации ценности данного подхода; дальнейшее расширение реализации на основные бизнес-задачи. Однако главная трудность на этом пути - недопонимание и отсутствие согласованности между бизнес- и ИТ-подразделениями. Значительно упростить проект внедрения и сократить затраты позволяют специализированные референсные модели (Process Frameworks).
Референсная модель - пакет аналитических и программных ресурсов, состоящий из описания и рекомендаций по организации высокоуровневой структуры бизнес-процесса, набора атрибутов и метрик оценки эффективности выполнения, а также программных модулей, созданных для быстрого построения прототипа бизнес-процесса для последующей его адаптации под специфику конкретной компании.
Референсные модели помогают в определении и установке требований и позволяют наладить бизнес-процессы, они основаны на отраслевых стандартах и включают в себя отраслевой опыт. Для типовых процессов референсные модели способны помочь при выборе и моделировании основных последовательностей работы, определении ключевых показателей эффективности (КPI) и параметров, позволяющих оценить результативность в ключевых областях, а также при управлении деятельностью и решением задач, анализе исходных причин и обработке исключительных случаев.
В структуру типичной референсной модели входят: рекомендации и описание предметной области; элементы композитных пользовательский интерфейсов (экранные формы и логически связные в цепочки портлеты); оболочки сервисов для быстрой реализации доступа к бизнес данным; примеры типовых бизнес-правил; ключевые показатели эффективности и элементы для их анализа; исполняемые модели процессов; модели данных и атрибуты процесса; адаптации к законодательной базе и специфике бизнеса в конкретной стране; рекомендации по этапам развертывания и реализации процессов. Такой набор ресурсов позволят быстрее адаптироваться к реализации процессного подхода в рамках конкретной системы управления бизнес-процессами, сократить время итераций цикла разработки, тестового исполнения и анализа процессов. При этом достигается максимальное соответствие технической реализации и существующей бизнес-задачи.
Однако, как отмечают аналитики AMR Research, «технологии и методы сами по себе не способны обеспечить каких-либо преимуществ - «больше» не всегда значит «лучше». Некоторые компании применяют множество различных решений, однако эффективность от этого только падает. Важна грамотность применения таких технологий». В референсных моделях в качестве основы используются принятые в отрасли стандарты и опыт компании Software AG по созданию эталонной модели для определения требований клиентов. На практике эта модель становится отправной точкой, с помощью которой клиенты могут создать нужную модель.
Process Framework, например, для бизнес-процесса обработки заказов, включает в себя базовую модель процесса со схемами действий для различных пользователей и ролей, избранные KPI из модели SCOR (The Supply-Chain Operations Reference-model) для процесса в целом и отдельных этапов, правила поддержки разных последовательностей обработки, например с учетом сегмента клиентов, целевые показатели для различных сегментов клиентов, типов продукции и регионов, а также панели индикации, помогающие контролировать особые ситуации.
Process Framework позволяет акцентировать внимание на необходимости и возможности коррекции KPI для конкретных групп клиентов и их конфигурирования с учетом появления новых товаров, выхода на новые регионы или сегменты рынка. Подобная информация позволит руководителям, отвечающим за цепочки поставок, торговые операции, логистику и производство, улучшить контроль над конкретной деятельностью, а руководителям ИТ-отделов быстро оценить реальную работоспособность ИТ-систем, поддерживающих обработку заказов.
Владимир Аленцев ([email protected]) - консультант по BPM и SOA , представительство Software AG в России и СНГ (Москва).
Эталонная модель ISO/OSI
В результате анализа существования протоколов передачи данных, международная организация по стандартизации (ISO) разработала эталонную модель стека протокола.
В модели используют принцип открытости системы (OSI), который предполагает, что любая фирма может разрабатывать аппаратные и программные средства в соответствии с установленными этой моделью правилами. В соответствии с моделью стека протоколов выделяются 7 уровней протоколов (рис. 1)
При передаче информации каждый уровень принимает информацию от вышестоящего уровня, дополняет её своей служебной информацией и передаёт нижестоящему уровню. Средства физического уровня передают информацию другому узлу сети. При приёме каждый уровень принимает информацию от нижестоящего, разбирает служебную информацию своего уровня, удаляет его и передаёт данные вышестоящему уровню.
Протоколы физического уровня – определяют стандарты кабелей, разъёмов для подключения сети характеристики сигналов передаваемых по линиям связи.
Протоколы канального уровня – определяют правила доступа к среде передачи данных, а также способы проверки правильности передачи данных. Протоколы канального уровня реализуются сетевыми платами адаптерами. Существует несколько протоколов канального уровня: Ethernet, FDDI, Token Ring.
Протоколы сетевого уровня – обеспечивают передачу информации между узлами сети и фрагментами сети. Сетевые протоколы, в частности, обеспечивают согласование разных видов сетей и определяют маршрут передачи сообщения.
Протоколы транспортного уровня обеспечивают надёжность доставки по сети информации и распределяет информацию между приложениями.Существует два популярных протокола транспортного уровня:
· TCP – обладает очень высокой надёжностью, но передаёт много служебной информации.
· UDP – менее надёжен, чем TCP, но меньше загружает сеть.
Сеансовый уровень управляет диалогами между узлами сети. В реально работающих стеках протоколов этот уровень обычно объединяется с вышестоящими.Представительный уровень или уровень представления – определяет способ кодирования информации.Прикладной уровень – отвечает за интерпретацию данных прикладными программами.
Протокольная модель описывает работу сети на уровне правил взаимодействия рассредоточенных объектов и функциональных модулей. Полный набор протоколов, обеспечивающий взаимодействие приложений двух оконечных систем информационной сети, довольно велик, поскольку при этом активизируется огромное количество сетевых функций (объектов). При построении протокольной модели удобно все протоколы разбить на группы, соответствующие объединению объектов в функциональные модули, каждый из которых решает определенный круг тесно связанных задач. Такая группа протоколов называется протокольным уровнем илипротокольным блоком . Их принято располагать в иерархическом порядке, соответствующем иерархии задач, выполняемых функциональными модулями (рис. 3).
