5.2. Інженерні проблеми проектування складних систем

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

Джон Д. К. Літтл. Цитується за Р.Шенноном [14]

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

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

Мабуть, найоб’єктивніше до цього питання пасує так зване імітаційне моделювання в його авторській постановці [14]. Із цієї монографії зі всією очевидністю витікає, що автор, хоч і не використовує термінологію рівнів складності зрештою, неявно постулював, що в основу імітаційного моделювання покладено припущення про не існування скінченої кібернетичної моделі (або скінченої множини моделей) складного об’єкта.

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

У викладеному нижче матеріалі нас цікавитиме постановка задач і пошук можливостей додаток формально коректних методів і підходів у прикладній теорії ІСУ для моделювання систем високих рівнів складності або навіть організації безпосередньої роботи із ними, виключаючи модель як обов’язковий атрибут сприйняття системи, що як ми вже згадували, не суперечить ЗТС за фон Берталанфі.

Декілька екскурсів у різні розділи програмування і суміжні галузі також є “власністю” прикладної теорії ІСУ. У них нас цікавитиме існування підходів, що дозволяють будувати в комп’ютері або вбудовувати комп’ютер у системи, що не подаються кібернетичними моделями.

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

Нагадаємо основні (далеко не всі) вимоги до систем управління такого роду:

• оперативність видачі довідок про наявність, кількість, рух і властивості матеріалів і що комплектують;

• простота використання системи (необхідно обходитися без спеціально навчених операторів);

• універсальність системи (система повинна бути єдиною і такою, що пов’язує для всіх її користувачів у всіх аспектах вжиток інформації, що міститься в ній);

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

Вказані вимоги виглядають зовсім не надмірними, навіть скоріше мінімально необхідними, але якими засобами можливо їх реалізувати?

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

Таким чином, бази даних і знань повинні практично перманентно перебувати в стані оновлення, інакше не вдасться виконати вказані вище вимоги. Зрозуміло, що варіабельність систем типу резервування квитків незрівнянно нижча.

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

І при всьому цьому оперативність поповнення довідкових фондів залишає бажати кращого навіть на підприємствах провідних галузей. Впровадження класифікатора ЄСКД в скільки-небудь широких масштабах не вдалося саме з цієї причини.

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

Можна, нарешті, зажадати, щоб система сама проявила достатній рівень інтелекту, тобто припинити спроби роботи на кібернетичному рівні і перейти до використання, а в необхідних випадках – розвитку прикладної теорії ІСУ.

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

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

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

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

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

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

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

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

Приклад із довідником демонструє, на наскільки низькому, за прийнятими поняттями, рівні виявляється проблема, пов’язана з необхідністю створення інтелектуальних систем. Тут вона проявилася як проблема переходу розгляду системи з третього рівня на рівень “суспільного інституту” навіть при, здавалося б, досить скромних вимогах до її можливостей.

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

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

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