Моделювання управління (Control) в процесі розробки IDEF0 функціональних моделей, CASE-засоби (моделювання), Програмування, статті





© Дубейковскій В.І., аналітик відділу впровадження та консалтингу компанії “Інтерфейс”

Одним з категоричних вимог федерального стандарту США IDEF0 є вимога мати для кожної, без винятку, Activity (функції) будь функціональної моделі (ФМ) – не менше однієї стрілки Control (Не менше одного каналу управління).


Крім труднощів, які, в зв’язку з цим, постійно відчувають вітчизняні системні аналітики в болісних пошуках суб’єктів управління, технічна сутність цього управління є предметом нескінченних суперечок між ними. Одним з найбільш популярних предметів для цих спорів є питання про те, чи є креслення деталі інформаційним входом або він є управлінням? Адже з одного боку – креслення інформаційний вхід, так як він містить інформацію про пристрій виготовляється деталі, з іншого боку, він – і управління, так як робітник-верстатник, керуючи верстатом, вчиняє дії, зумовлені цим кресленням …


IDEF0 так визначає сутність стрілки Control:


“…2.17 Control Arrow: The class of arrows that express IDEF0 Control, i.e., conditions required  to produce correct output.  Data or objects modeled as controls may be transformed by the function, creating output.  Control arrows are associated with the top side of an IDEF0 box…”.


2.17 Стрілка управління: Клас стрілок, які виражають управління IDEF0, тобто необхідні умови, щоб зробити коректний вихід[1]. Дані або об’єкти, модельований як управління, можуть бути перетворені функцією, що створює вихід. Стрілка управління пов’язана з верхньою стороною боксу IDEF0.


На рис. 1 представлена ​​гранично проста, але коректна по IDEF0 діаграма ФМ. Всі її Controls – застосовані у значенні наведеного визначення. Але їх сутність залишається не дуже ясною. Справа в тому, що управління є функціонально неоднозвенним процесом. Поширений погляд на управління як на процес, що складається з чотирьох взаємопов’язаних функцій: Plan – Do – Check – Act (PDCA) так званий “Цикл Деммінга”[2].


Цикл Деммінга може бути представлений в графічному IDEF0 форматі – як на рис. 2. Для цього його функції повинні бути поповнені стрілками – зв’язками. Тому “Процес 1” (відповідає Do в циклі Деммінга) на малюнку поповнено входом “Plan 1”, що є виходом з “Генерація Plan 1” (Pl an), інформаційним виходом “Інф (ормація) про проц 1”, управлінням “Керуючий вплив 1”, що робить зайвим “Control 1 “.” Керуючий вплив “є виходом з” Здійснюючи Act 1 “(Act), ініційованим виходом” Рішення про управління 1 “з функції” Здійснюючи. Check 1 “(Check), що є для нього управлінням. Рішення про управління є результатом зіставлення входів функції “Здійснюючи. Check 1” – “Plan 1” і “Інф. про проц. 1”. Тобто це наслідок перевірки поточного стану виконання Plan 1.


Тут керуючий вплив, на відміну від Control, є реальним впливом на процес, спрямованим на відновлення відповідності процесу – плану (Do – Plan).


В результаті цих побудов отримуємо замкнутий контур управління Процесом 1 – КУ 1.


У такому поданні управління стає ясною і однозначною роль креслення в ФМ. Це тільки інформаційний вхід. А управлінням є реальний вплив на здійснюваний процес – в разі розбіжності результатів обробки з інформацією креслення. Наприклад – переміщення супорта токарного верстата в положення, при якому верстат буде забезпечувати в обробці її розміри – відповідно з кресленням.


Продовжуючи коректне облаштування діаграми, аналогічно повинен бути забезпечений зв’язками “Процес 2” – див рис. 3. Створюється контур управління КУ 2: генерація Plan 2 – Процес 2 – Здійснення Check 2 – Здійснення Acct 2.


В результаті цього виникає, також, Activity “Координація Plan 1 – Plan 2”.


Подальше аналогічне облаштування “Процес 3” тут не розглядаємо.


Як тільки ми визнаємо наведену доктрину комплексного відображення управління в ФМ, ми отримуємо подальші додаткові труднощі моделювання. Ці труднощі полягають у тому, що, крім згаданих КУ 1 і КУ 2 (також, далі, і КУ 3) виникає необхідність подібного ж облаштування ВСІХ Activities ВСІХ КУ.


На рис. 4 – для прикладу – приведена відповідна картина облаштування тільки Activity “Здійснення Check 2” (з КУ 2). Ця функція вбудовується в контур управління: “Plan Check 2” – (“Здійснення Check 2 “) -” Check – Check 2 “-” Act Check 2 “. Позначимо цей контур управління – як КУ 3.


Контури управління, подібні КУ3, можуть бути визнані управлінням наступного ієрархічно рівня. Так, якщо КУ 2 – контур управління Процесом 2, наприклад, керування токарним верстатом, то КУ 3 управляє контролем КУ2. Це може бути вже система управління групою верстатів і відноситься до управління цехового рівня.


І так далі.


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


На додаток до різкого розширення числа Activity – функцій в ФМ ми повинні врахувати, що всі ці функції повинні бути підтримані інфраструктурно, тоесть отримати виконавця (Mechanism – для IDEF0) для кожної з них.


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


З іншого боку функціональні моделі, розроблені з поданням управління в них – як на рис. 1 в дійсності ігнорують процедури управління. Це моделі з неформалізовані управлінням. Це випливає і з визначення призначення стрілки Control в IDEF0 – “2.17 … стрілки, які ВИСЛОВЛЮЮТЬ управління IDEF0 … “А не здійснюють його. Так що самі дії управління можуть знаходитися поза ФМ.


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


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


Найчастіше багаторівневе управління розробляється для процедур планування. У міру розвитку таких систем, широта формалізованого управління збільшується. Це можна бачити на прикладі історії комп’ютерної підтримки управління у виробничих системах. Ці складні системи, інтенсивно розвиваються в даний час, переживають створення четвертого покоління – MRP – MRP11 – ERP – CSRP з розширенням комп’ютерної підтримки охоплення управління від підтримки планування потреб в матеріалах (MRP – Material Requirements Planning [3]) до планування ресурсів, синхронізованого з покупцем – CSRP [4] (Customer Synchronized Resources Planning).


Справедливості заради треба зауважити, що в деяких випадках подолати труднощі комплексної розробки управління технічними системами все ж вдається. Одним із прикладів можуть служити системи числового програмного управління (ЧПУ) верстатами. Особливо виразно управління так званими “обробними центрами”, не тільки здійснюють без людини власне обробку машинобудівних деталей, але також базують і закріплюють на верстаті заготовку, періодично вибирають інструмент з автоматичної магазину і закріплюють його в шпинделі, що вимірюють оброблювану і оброблену деталь, контролюючих коректність роботи верстата і ін


Компенсуючи некомплектність моделювання системи, ми повинні уважно опрацьовувати Mechanisms її Activities, не мають розроблених КУ, щоб забезпечити ручне керування ними. Єдине, що ми даємо при цьому персоналу в нашій моделі – це інформація про “…необхідних умов, щоб зробити коректний вихід … “. “Індульгенцію” на такі рішення ми отримали, фактично, від IDEF0.



Рис. 1. Діаграма ФМ з трьома Activities, облаштованими зв’язками відповідно до регламентацією IDEF0
 

Рис. 2. Моделювання комплексного управління Процесом 1
 

Рис. 3. Моделювання комплексного управління Процесами 1 і 2
 

Рис. 4. Діаграма ФМ з контурами управління Процесами 1 і 2, і з КУ для функції “Здійснення Check 2”

У статті не наводиться інформація про власне функціональному моделюванні, так як у вітчизняній практиці є достатньо матеріалів з цього приводу. У тому числі – див., наприклад, [1].


У цьому розраховуємо на підготовленого читача, передаючи йому додаткову інформацію по одній із частковостей практики функціонального моделювання при підтримці ППП AllFusion Process Modeler.


Література:


1. Дубейковскій В. І. Ефективне моделювання з AllFusion Process Modeler 4.1.4 і AllFusion PM. Вид. ДІАЛОГ-МИФИ, 2007 р. 


[1] Виділення наше


[2] Див на рис. 2 деталізуючий текст з посиланням на ГОСТ Р ІСО 9001 – 2001, розділ “Процесний підхід” – як на джерело цієї цитати.


[3] Див www.info-system.ru/kis/common_inf/what_is_erp_mrp_com_inf.html


[4] Див, наприклад, www.interface.ru/fset.asp?Url=/mrp/csrp.htm – Катерина Де Роза (Компанія SYMIX) Еволюція розвитку інформаційних систем. Методологія CSRP.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*