4.1: Чи можемо ми його побудувати?

При проектуванні масштабної системи до роботи над одним проектом приєднується безліч різних галузей експертизи. Таким чином, вся команда проекту ділиться на кілька підкоманд, кожна з яких працює над підпроектом. І ми рекурсуємо вниз: підпроект знову враховується на підпроекти, кожен зі своєю командою. Такий ієрархічний процес проектування можна назвати спільним дизайном або спільним дизайном. У цьому розділі ми обговорюємо математичну теорію спільного дизайну, завдяки Андреа Ченсі [Cen15].

Розглянемо лише один рівень цієї ієрархії: проект і набір команд, що працюють над ним. Кожна команда повинна надавати ресурси, які іноді називають «функціональними можливостями», для проекту, але команді також потрібні ресурси для цього. Різні проектні команди повинні мати можливість планувати та працювати незалежно один від одного, щоб досягти прогресу. Проте дизайнерські рішення, прийняті однією групою, впливають на дизайнерські рішення, які можуть приймати інші: якщо A хоче більше місця для того, щоб забезпечити кращий радіодинамік, то B повинен використовувати менше місця. Таким чином, ці команди - хоча і нібито працюють незалежно, все-таки залежать один від одного.

Поєднання залежності та незалежності має вирішальне значення для досягнення прогресу, але це може спричинити великі проблеми. Коли команді потрібно більше ресурсів, ніж спочатку очікувалося, або якщо вона не може надати ресурси, які вона спочатку стверджувала, що може надати, звичайна відповідь полягає в тому, щоб команда видала повідомлення про зміну дизайну. Але вони впливають на сусідні команди: якщо команда А зараз вимагає більше, ніж спочатку заявлено, команді B, можливо, доведеться змінити свій дизайн, що, в свою чергу, може вплинути на команду C. Таким чином, ці повідомлення про зміну дизайну можуть пульсувати через систему через петлі зворотного зв'язку і можуть призвести до невдачі цілих проектів [S+15].

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

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

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

(4.1) Позначені поля\(\Sigma\) відповідають підсумовуючим входам. Ці коробки не повинні бути розроблені, але пізніше ми побачимо, що вони легко вписуються в ті ж концептуальні рамки. Зверніть увагу також на ≤ на кожному дроті; вони вказують на те, що якщо коробка A вимагає ресурсу, який виробляє коробка B, то вимога А повинна бути меншою, ніж або дорівнює виробництву B. The

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

Загалом, ці попередні замовлення не повинні бути лінійними замовленнями, хоча у вищезазначених випадках кожен, швидше за все, буде відповідати лінійному порядку: $10 ≤ 20$, 5W ≤ 6W тощо.

Кожна з коробок у діаграмі спільного проектування відповідає тому, що ми називаємо співвідношенням доцільності. Співвідношення доцільності відповідає виробництву ресурсів вимогам. Для кожної пари (p, r)\(\in\) P × R, де P є попереднім порядком ресурсів, які потрібно виробляти, а R - попереднє замовлення ресурсів, які потрібно, у полі написано «true» або «false» - можливо або нездійсненно - для цієї пари. Іншими словами, «так, я можу надати р заданий r» або «ні, я не можу надати p заданий r».

Звідси співвідношення доцільності визначають функцію Φ: P × R → Bool. Для функції Φ: P × R → Bool має сенс як співвідношення доцільності, однак існують дві умови:

1. Якщо Φ (p, r) = істина і p ′ ≤ p, то Φ (p ′, r) = істина.
2. Якщо Φ (p, r) = істина і r ≤ r ′, то Φ (p, r ′) = істина.

Ці умови, які ми побачимо знову у Визначенні 4.2, кажуть, що якщо ви можете виробляти p заданих ресурсів r, ви можете (а) також виробляти менше p ′ ≤ p з тими ж ресурсами r, і (b) також виробляти p задано більше ресурсів r ′ ≥ р.

Ми побачимо, що ці дві умови формалізовані, вимагаючи Φ бути монотонною картою P\(^{op}\) × R → Bool.

Проблема спільного проектування, представлена діаграмою спільного проектування, просить нас знайти com- posite деяких відносин техніко-економічного обґрунтування. Він запитує, наприклад, враховуючи ці можливості шасі, двигунів та акумуляторних команд, чи можемо ми побудувати робота разом? Дійсно, діаграма спільного проектування перетворює проблему - наприклад, проектування робота - у міжконструйовані підзадачі, як у еквалайзері (4.1). Після того, як співвідношення доцільності розроблено для кожної з підзадач, тобто внутрішніх коробок на діаграмі, математика надає алгоритм, що створює співвідношення доцільності всієї зовнішньої коробки. Цей процес може бути рекурсований вниз, від найбільшої проблеми до крихітних підзадач.

У цьому розділі ми розберемося з проблемами ко-дизайну з точки зору збагачених про- функторів, зокрема Bool -profunctors. Bool -profunctor схожий на міст, що з'єднує одне попереднє замовлення з іншим. Ми покажемо, як структура спільного проектування породжує структуру, відому як компактна закрита категорія, і що будь-яка компактна закрита категорія може інтерпретувати види електричних схем, які ми бачимо в еквалайзері (4.1).