Побудувати графік матлаб. Побудова контурних графіків функцій двох змінних
Для єдиного представлення даних у мережах з неоднорідними пристроями та програмним забезпеченням міжнародна організація стандартів 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 описує повну номенклатуру артефактів підприємства (його генотип), вона не може достовірно сказати, які зміни в цьому генотипі впливають на конкретні виробничо-господарські характеристики підприємства, тобто на фенотип підприємства (сукупність характеристик, властивих індивіду на певній стадії розвитку ).
Зі свого боку, дисципліна 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).
