4. Побудова функціональної моделі системи (моделі ГОЕЕО)

Перед визначенням і описом порядку побудови моделі слід зро­бити декілька зауважень:

1. Всяка 8АЕ)Т модель вимагає точного визначення границь сис­теми, цілей моделювання, точки зору, контексту розгляду системи.

2. 8ЛБТ моделі вимагають, щоб система розглядалась весь час з однієї точки зору, оскільки зміна точки зору може зробити модель неа­декватною. Точка зору диктує підбір потрібної інформації та спосіб її подачі.

3. 8ЛОТ моделі будуються з верхнього рівня "з голови". У них діаграми нижчого рівня є деталізованими діаграмами верхнього рівня. Кінцевий результат це ієрархічна структура діаграм.

На початку побудови функціональної моделі необхідно чітко ви­значити:

- границі системи,

- ціль моделювання,

- контекст розгляду системи

- точку зору,

тобто відповісти на запитання, які є вихідними усякого системно­го аналізу.

Ціль є напрямком діяльності і критерієм закінченості моделі. Ви­значаючи ціль, слід розрізняти:

- ціль системи, для якої будують функціональну модель і

- ціль моделювання.

Ціль системи визначає зміст моделі її конкретне наповнення. Всяку модель ми будуємо відповідно до її цілі, до завдань, які виконує система.

Ціллю моделювання може бути виконання певного завдання, ви­вчення системи, розробка та удосконалення системи і т.п. Ця ціль ви­значає обсяг роботи, потрібний ступінь деталізації системи, розміри моделі в глибину і ширину.

Точка зору визначається тим, з погляду якої особи ми розглядає­мо модель, точка зору якої особи найбільш повно відповідає цілі моде­лювання.

Усяка модель повинна бути цілісною і розглядатися з однієї точ­ки зору. Різні точки зору приводять до різних моделей, а зміна точки зору в ході моделювання не допускається, оскільки може призвести до невірного опису системи, до неадекватної моделі. Наприклад, система "Тролейбусне депо". Модель системи виглядатиме по-різному, якщо розглядати з різних точок зору. Для директора головними елементами є робочий колектив, підрозділи депо, виконання ними своїх функцій, оде­ржання прибутку та оплата праці. Для головного інженера в основі зна­ходяться технологічні процеси роботи депо, їх технічне забезпечення, технічний рівень виконання операцій, використання наукових досяг­нень, технічний стан обладнання. Для економіста найбільш важливою є економічна ефективність роботи підрозділів, наявність фінансових ре­сурсів, одержання прибутку від діяльності. Для начальника служби охо­рони праці найбільш важливими є умови праці кожного робітника, об­ладнання робочих місць засобами захисту, організація профілактичної роботи по дотриманню правил охорони праці і т. п. Отже, всяка система виглядає по-іншому з різних точок зору. Модель системи повинна вико­нуватися з однієї точки зору. Зміна точки зору в ході моделювання при­водить до змішування і створення еклектичної моделі, яка не може дати відповіді на жодне запитання. Для повного опису системи інколи вини­кає потреба розглядати її з різних точок зору, але в такому разі необхід­но будувати декілька моделей. У кожній моделі система розглядається тільки з однієї точки зору.

Слід зауважити, що під час побудови моделі при переході від од­ного рівня декомпозиції до іншого виникає потреба розглядати систему з точки зору виконавців конкретних функцій чи робіт. Така зміна точки зору є потрібною і корисною. Вона дозволяю одержати найбільш інфо­рмативну й корисну модель. Для забезпечення цілісності моделі тут по­трібно на кожному етапі декомпозиції контролювати, як функції елеме­нтів відповідають загальній точці зору на модель, чи не змінюється ця точка зору. На кожному етапі моделювання загальна точка зору повинна залишатися незмінною, а змінюється тільки рівень деталізації.

Контекст розгляду системи визначає оточення, в якому ми розг­лядаємо систему. В попередніх розділах опису найпростіших типів мо­делей було розглянуто характеристики зовнішнього середовища. Кон­текст розгляду системи якраз і включає зовнішнє середовище з його характеристиками.

На початкових етапах побудови функціональної моделі необхідно зібрати якомога більше інформації про систему, виконати всі попередні етапи системного аналізу, а саме: опис на вербальному рівні, історич­ний, морфологічний та функціональний аналіз і побудувати найпростіші моделі. Попередньо побудовані моделі "Чорний ящик", "Склад систе­ми", "Структура системи" і "Структурна схема" значно полегшують побудову функціональної моделі.

Побудова функціональної моделі полягає у функціональній де-композиції системи. Виконуючи декомпозицію, окремі функції системи розбивають на підфункції і зображують у вигляді ієрархічної структури. Під час аналізу систем, які існують, а не проектуються, найбільш часто функціональну декомпозицію виконують на основі реальної структур­ної схеми системи. У першу чергу визначають функції окремих підсис­тем і ставлять їм у відповідність функціональні блоки. Функціональні блоки не обов' язково повинні відповідати структурним одиницям сис­теми, оскільки кожна структурна одиниця може виконувати декількафункцій або одну функцію можуть здійснювати декілька підсистем. До­пускається виконувати функціональну декомпозицію незалежно від структурної схеми системи, а орієнтуватись тільки на функції, які по­винна виконувати кожна підсистема. Це часто роблять з ціллю реінже-нірингу систем, тобто з ціллю перебудови і удосконалення роботи сис­теми. Для систем, які проектуються, функціональну декомпозицію ви­конують раніше розробки структурної схеми, а структурну схему роз­робляють вже на основі функціональної моделі.

Як правило, орієнтовну декомпозицію системи бажано видавати під час підготовки до моделювання. Виділеним функціональним блокам системи слід присвоїти імена відповідно до їх функцій. Імена функціо­нальних блоків повинні відображати функцію дієсловом, дієслівним зворотом або віддієслівним іменником. Присвоєння інших імен вважа­ється помилкою. Результати функціональної декомпозиції, виконаної на початку побудови моделі, бажано зобразити на папері у вигляді дерева вузлів.

Наступним кроком підготовки до побудови функціональної мо­делі є визначення всіх вхідних і вихідних величин функціональних бло­ків - робіт (згідно з прийнятою термінологією, анг. - activity). Тут треба розглянути величини, що поступають у кожний блок та виходять з ньо­го. А саме: які величини є вхідними, які результатами діяльності, які забезпечують умови виконання функцій кожним блоком. Слід мати на увазі, що крім технологічних операцій, вказаних у найменуванні функ­ціонального блоку, повинні відображуватися і операції інформаційного характеру, керуючі дії, тобто кожен блок повинен мати вхід по керуван­ню. Після цього приступають до побудови функціональної моделі.

Функціональна модель являє собою ряд діаграм, а саме контекст­ну діаграму, діаграми декомпозиції та деяких інших документів. Елеме­нти контекстної діаграми і діаграм декомпозиції є такими:

• функціональні блоки (роботи) - activity;

• інтерфейсні дуги (стрілки) - arrow.

Функціональні блоки діаграм - роботи (activity) зображаються прямокутниками. Сторони прямокутника мають таке призначення:

• вхід (input);

• керування (control);

• вихід (output);

• механізм (mechanism).

Ліва сторона є входом. Вхідні величини відповідають об'єктам, що поступають (входять) у блок і перетворюються в ньому у вихідні величини.

Верхня сторона відповідає входам по керуванню. Ними, як пра­вило, повинні бути конкретні керуючі дії, документи, правила, стандар­ти, обмеження, що зумовлюють виконання функцій блоком.

Права сторона є виходом блоку. Вихідним величинам відповіда­ють результати діяльності функціонального блоку, те, у що перетворю­ються вхідні величини.

Нижня сторона відповідає механізмам. Механізмами є те, що в даній системі забезпечує виконання функцій, наприклад, обладнання, спеціалісти, а також потрібні ресурси.

Таке призначення сторін блоків відповідає системним принци­пам, а саме: усяка робота виконується над деякими об' єктами, що є вхі­дними. Вона перетворює вхідні об' єкти у вихідні. Керування регламен­тує виконання роботи, а механізм забезпечує всі необхідні умови для її виконання.

Під час визначення вхідних величин інколи важко визначити, ку­ди віднести дану величину: безпосередньо до входу чи до керування. Тут треба користуватися таким правилом: якщо дана величина у блоці перетворюється в одну чи декілька вихідних величин, то її вважають вхідною, якщо вона використовується, але безпосередньо не перетворю­ється в жодну з вихідних величин і не змінюється, то її відносять до входу по керуванню (інколи до механізму).

Кожен блок повинен мати принаймні одну керуючу і одну вихід­ну величини. Зрозуміло, що блок, який не має вихідної величини, на діаграмі не повинен бути (це робота, яка не дає ніякого результату). Ві­дсутність вказаних дуг при синтаксичному аналізі діаграми буде вважа­тися помилкою.

Інтерфейсні дуги (стрілки) - arrow на діаграмах декомпозиції встановлюють зв' язки між окремими функціональними блоками (робо­там). Слово "інтерфейс" означає зв' язок, англійською мовою - це те, що стоїть між обличчями. Тобто дуги зв' язують роботи між собою. Вони відповідають тим об' єктам, які циркулюють між блоками, передаються від блоку до блоку при функціонуванні системи.

Усі дуги повинні мати імена. Під час присвоєння імені дузі вка­зують опис об' єктів, яким вона відповідає. Імена дугам присвоюють у місцях встановлених міток. Мітки на дугах слід розставляти відповідно до таких правил:

• Кожна дуга повинна мати ім'я.

• Після розгалуження дузі можна присвоювати нове ім'я або не присвоювати.

• Якщо після розгалуження дузі не присвоєно нове ім' я, то вона містить всі об' єкти, які містила до розгалуження.

• Якщо після розгалуження дуга містить частину об'єктів, то вона має бути пойменована і повинен бути вказаний (чи зрозумілий з назви) перелік об' єктів, яким вона відповідає.

• Після злиття дуга обов'язково повинна бути пойменована.

На діаграмах декомпозиції допускається тунелювання дуг. Туне-лювання - це умовне позначення дуг без безпосереднього нанесення їх на діаграму. Тунелювання має на меті спростити зображення діаграм і облегшити їх читання. Дійсно, якщо діаграма декомпозиції має, напри­клад, 6 функціональних блоків і кожен блок має по декілька дуг з різних сторін, то ці дуги можуть так переплітатись, що читати діаграму буде важко. Тунелювання дозволяється виконувати тільки для другорядних дуг. Дуги, що виходять з батьківської діаграми і відносяться до усіх блоків дочірньої діаграми, можуть не зображатися. Закінчення такої дуги біля виходу з батьківської діаграми береться в дужки (тунелюєть-ся) і в подальших діаграмах не вказується. Таке позначення називають "не в дочірній діаграмі". Тунелювання може бути і таке, що дуга не вка­зується у батьківській діаграмі, а з' являється в дочірній. Така дуга поз­начається дужками біля входу у блок, що означає "не на батьківській діаграмі".

Розглянемо порядок побудови функціональної моделі. Викорис­товуючи вказані правила, функціональну модель можна побудувати як безпосередньо на папері за допомогою олівця, так і за допомогою комп'ютера з використанням пакету програм ВР\уіп. Побудова діаграм на папері порівняльно легка, коли вся модель має один, два рівні деком-позиції. Якщо таких рівнів більше, то виникають труднощі, які доволі важко перебороти. Тому функціональну модель рекомендується будува­ти за допомогою комп' ютера. Правила роботи з комп' ютером і введення моделі вказані у [45] і тут їх детально розглядати не будемо, а тільки відзначимо головні моменти побудови. Зауважимо, що перед початком роботи треба забезпечити на носії інформації, а саме на вінчестері комп' ютера місце для розміщення моделі, тобто створити папку і в по­дальшому розміщувати всі результати роботи саме в цій папці.

Після завантаження програмного пакету ВР\уіп необхідно:

• відкрити новий документ;

• вибрати тип моделі ГОЕРО;

• присвоїти їй власне ім' я;

• вказати відомості про автора розробки;

• зберегти файл моделі у попередньо створеній папці.

Після цього приступають до введення інформації за створюваною моделлю. Ця інформація повинна містити:

• визначення функцій системи;

• цілі моделювання;

• контекст розгляду системи;

• точку зору, з якої розглядується система;

• відомості про авторів розробки;

• перелік джерел інформації.

Всі ці дані заносять у відповідні розділи моделі на початку її по­будови.

Побудову функціональної моделі починають з контекстної діаг­рами. Контекстна діаграма - це початкова діаграма моделі, що характе­ризує функції системи взагалі (без деталізації) і зв'язки системи з на­вколишнім середовищем. Бланк контекстної діаграми містить тільки один функціональний блок. У ньому вказують функцію системи взагалі (її ціль, основне призначення). При цьому дотримуються вимог запов­нення функціональних блоків (блоків робіт - activity), а саме: назва бло­ку повинна бути подана дієсловом, дієслівним зворотом чи придієслів­ним іменником. Інші назви блоків розглядаються як помилка. При необ­хідності вводять пояснення до назви блоку в розділі definition, який має кожен блок.

До функціонального блоку діаграми підводять вхідні й вихідні величини системи у вигляді стрілок (дуг - arrow), які характеризують зв' язки системи з навколишнім середовищем. Для всіх вхідних величин (дуг) дають пояснення. Ці пояснення записують у словник за допомо­гою діалогових вікон. У словнику бажано вказати не тільки саме ім' я, а також пояснення до нього і джерело інформації. Пояснення імені дуги потрібне, оскільки ім' я, як правило, буває коротким і не відображає усіх об' єктів, що відповідають дузі. Джерела інформації особливо потрібні для дуг керування. Це можуть бути певні документи, стандарти, розпо­рядження, для яких необхідно вказати вихідні величини, а саме номер, дату створення, місце публікації тощо. У подальшому введені відомості можна використати при розробці словника термінів по моделі, переліку джерел інформації та ін.

Після побудови контекстної діаграми переходять до побудови на­ступних діаграм моделі. Ці діаграми є діаграмами декомпозиції. Діагра­му декомпозиції будують у такому порядку. Вибравши значок декомпо-зиції, в діалоговому вікні вказують тип діаграми, яка буде побудована. (Пакет BPwin дозволяє будувати складні моделі з різними типами діаг­рам.) Треба вказати діаграму IDEF0 і кількість блоків декомпозиції. Ді­алогове вікно вибору кількості блоків декомпозиції за типом діаграми декомпозиції показане на рис. 28.

Кількість блоків декомпозиції рекомендується вибирати в грани­цях від 2 до 6. Обмеження зумовлені тим, що не має сенсу декомпозиції, яка замінює один блок іншим, а число 6 рекомендоване тому , що діаг­рама, в якій більше 6 блоків і зв'язків між ними, стає складною і читати її важко (в пакеті ВР\уіп допускається вводити до 8 блоків). Після вибо­ру типу діаграм та кількості блоків робіт з' являється бланк діаграми декомпозиції на зразок, показаний на рис. 29.

Бланк діаграми декомпозиції містить блоки робіт, розміщені зве­рху - вниз, зліва - направо. Використовуючи цей зразок, дамо пояснен­ня змісту діаграм декомпозиції та правил їх побудови. Розміщення фун­кціональних блоків зверху - вниз, зліва - направо називають домінант­ним. У верхньому лівому куті розміщується блок роботи, яку вважають найбільш пріоритетною, нижче і правіше знаходяться блоки менш пріо­ритетних функцій, або у випадку, коли діаграма зображує поопераційне виконання певних робіт, то домінантність блоків визначає порядок ви­конання робіт, яким ці блоки відповідають. Блоки функціональної діаг­рами мають порядковий номер і закреслений лінією верхній кут. Нуме­рація блоків відповідає їх пріоритетності й служить для встановлення єдиного порядку блоків у всій моделі. Закреслений лінією лівий верхній кут блоку є ознакою, що даний блок ще не піддавався операції декомпо-зиції. Якщо у подальшому виконати декомпозицію цього блоку, то по­мітка буде знята, якщо не виконувати, то вона залишиться на діаграмі.

С2

Навчальний       І   С1 Накази   1 С2

план

і   С1 Накази X

W ректора Т

V

Студент

L

Спеціаліст 01

7

 

 

4

Викладачі

^ ^    Обчислювальний центр

M1 M2

Рис. 29 - Зразок бланку декомпозиції

2

I1

з

По краях діаграми розміщуються незв'язані граничні дуги, які мі­грують з блоку контекстної діаграми. Розміщення граничних дуг відпо­відає призначенню сторін функціонального блоку. Дуги мають позна­чення відповідно до ICOM кодами. ICOM - це скорочення англійських позначень: I - Input (вхід), C - Command (керування), O - Output (вихід), M - Mechanism (механізм). Позначення дуг містять літеру і порядковий номер. Позначення дуг ICOMС кодами та цифрами є додатковим поз­наченням і служить для полегшення використання діаграми. (Дуги та­кож мають власне ім'я, яке їм присвоєне у попередній, в даному випад­ку контекстній діаграмі). Позначення дуг ICOMС кодами важливе при ручній побудові діаграм безпосередньо на папері, оскільки воно дозво­ляє уникати можливих помилок. При побудові моделі на комп' ютері ICOMС коди не відіграють такої ролі, оскільки програмний пакет забез­печує автоматичне перенесення дуг на діаграмах декомпозиції та конт­роль за їх використанням. Тому позначення ICOMС кодів може бути відключене.

Заповнення діаграми декомпозиції розпочинають з присвоєння імен функціональним блокам. Всі блоки повинні бути пойменовані від­повідно до вказаних раніше правил відносно назви блоку, тобто блок повинен мати назвою дієслово, дієслівний зворот чи придієслівний іменник. Введені імена блоків при необхідності супроводжують пояс­ненням та іншою потрібною інформацією. Ця інформація записується у словник моделі.

Наступним кроком є рознесення незв'язаних граничних дуг. Всі граничні дуги повинні бути проведені до тих блоків, до яких вони від­носяться. У разі потреби конкретна дуга може бути розгалужена і підве­дена до декількох блоків.

Після рознесення граничних дуг будують внутрішні дуги, які пов' язують блоки робіт між собою відповідно з логікою функціонуван­ня системи. Внутрішні дуги повинні встановлювати зв' язки між блока­ми. Існує, як було відмічено вище, 5 типів таких зв'язків. Відповідно до них і логіки функціонування системи внутрішні дуги можуть з' єднувати різні сторони блоків робіт, зливатися і розгалужуватися. Крім відміче­них п' яти типів зв' язків інші не можуть бути виконані і пакет програм цього не допустить. У випадку побудови моделі олівцем на папері дуги, які не відповідають вказаним типам зв' язків, можуть бути зображені, що є синтаксичною помилкою діаграми.

За ходом побудови діаграми кількість функціональних блоків може бути змінена, можна ввести додаткові блоки або вилучити блоки, які вважаються непотрібними. Можна також поміняти блоки місцями відповідно до їх домінантності в діаграмі. При зміні місць блоків нуме­рація їх також змінюється. Ці можливості забезпечують зручність побу­дови діаграм, виправлення помилок, допущених на одному з етапів по­будови моделі.

Побудову діаграми декомпозиції необхідно закінчити перевіркою її на наявність синтаксичних помилок. Це здійснюється за допомогою спеціальної підпрограми, яка викликається за допомогою меню пакету і виводить звіт про наявність помилок у діаграмі. Виправлену, без синта­ксичних помилок, діаграму роздруковують і піддають експертизі на адекватність відображення системи. Порядок проведення експертизи розглядається дещо нижче.

Після побудови діаграми декомпозиції першого рівня приступа­ють до декомпозиції її функціональних блоків. Декомпозицію викону­ють аналогічно декомпозиції контекстної діаграми з тією різницею, що перед декомпозицією потрібно вказати, який саме блок діаграми підда­ється декомпозиції. Виконавши декомпозицію діаграми першого рівня, необхідно виконати аналіз моделі на наявність синтаксичних помилок, виконати експертизу на адекватність моделі, а потім приступити до де-композиції діаграм другого рівня. Аналогічно поступають і після деко-мпозиції діаграм другого і наступних рівнів. Закінчення декомпозиції визначають за вимогами цілі моделювання, та за тією ознакою, що бло­ки декомпозиції є елементарними роботами. Декомпозиції можна підда­вати не всі роботи, а тільки ті, які, виходячи з цілей моделювання, вима­гають виконання декомпозиції. По завершенні декомпозиції моделі оде­ржується цілий ряд діаграм на зразок, показаний на рис. 30.

Контекстна діаграма

Більш детальне уявлення

 

Кожна діаграма функціональної моделі системи має позначення. Система позначення є такою. Контекстна діаграма позначається А - О. Декомпозиція контекстної діаграми (діаграма першого рівня декомпо-зиції) - АО, декомпозиція функціональних блоків діаграми першого рів­ня - А1, А2, АЗ, декомпозиція блоків діаграми А1 - двома цифрами АН, А12, А1З,     блоків діаграми А2 - двома цифрами А21, А22, А2З,

.... Наступні діаграми декомпозиції позначаються літерою А з трьома

цифрами, подальші (якщо вони є) з чотирма цифрами і т. д. Проте біль­шість моделей обмежується діаграмами З - 4 рівня, оскільки дерево де-композиції стає великим у глибину і модель є складною. Для великих організаційних систем модель може включати сотні, або тисячі аркушів. у разі необхідності працювати з моделями, що мають багато діаграм на різних рівнях декомпозиції, їх розбивають на ряд менш складних моде­лей і розглядають самостійно. Таке розбиття і з' єднання декількох мо­делей в одну передбачене пакетом BРwin. Воно застосовується, коли виникає необхідність колективу аналітиків працювати з великими сис­темами. Це дозволяє кожному виконувати свою роботу незалежно від інших, а потім об' єднувати результати роботи.

Приклад функціональної моделі для нескладної системи "Токар­на дільниця" наведено на рис. 31, 32.

 

На рис. 31, 32 показаний приклад побудови функціональної мо­делі системи "Токарна дільниця". Модель складається з двох діаграм: контекстної і діаграми декомпозиції.

Обточка петапі

О грн

Деталь

Перевірка

дегат

О грн_2

Токарі

Аналіз браку

О грн_3

Причини браку

Деталі

Контролери

Рис. 32 - Діаграми декомпозиції системи "Токарна дільниця"

Контекстна діаграма являє собою один блок, в якому вказана го­ловна функція системи, а саме "Виготовлення деталей". Вхідною вели­чиною є заготовка деталі. Вона показана дугою "Заготовка" і підходить до лівої грані блоку контекстної діаграми. Входом по керуванню, тобто обмеженнями, що накладаються на виготовлення деталей, є "Креслен­ня". У виготовленні деталі беруть участь "Токарі" і "Контролери". Ви­готовлення ведуть за допомогою "Верстатів". "Токарі", "Контролери" і "Верстати" показані як механізм, тобто підходять до блоку з нижньої сторони. Вихідними величинами є "Деталь" і "Брак". Контекстну діаг­раму можна читати таким чином: Токарі з участю контролерів за допо­могою верстатів виготовляють із заготовок відповідно до креслення деталі. Результатом їх роботи є готова деталь або брак.

Діаграма декомпозиції має у своєму складі три роботи, а саме: "Обточка деталі", "Перевірка якості деталі" та "Аналіз браку". Пріори­тетною і першою за чергою є робота "Обточка деталі". Токарі відповід­но до креслень обточують на верстатах заготовки і одержують деталь. Виготовлені деталі передають на перевірку якості. Перевірка здійсню­ється контролерами відповідно до креслень. Перевірені деталі, залежно від результату перевірки, передають в інші системи (є вихідними вели­чинами), або бракуються і передаються для аналізу причин браку. Після аналізу причин браку, який здійснюють контролери, деякі деталі знову надходять на обточку, а інші бракуються повністю і виходять із системи як невиправний брак. Після аналізу причин браку інформація про ре­зультати аналізу передається токарям, які обточують деталі. Ця інфор­мація служить для них керуючою інформацією і призначена для покра­щання роботи.