PROFILPELAJAR.COM

Класної дошка — шаблон проектування, що застосовується для вирішення задач, які потребують координації різних процесів або джерел знань.^[1] Містить набір акторів (джерел знань), структури даних класної дошки та контролера, що моніторить стан дошки і вирішує яких акторів пріоритизувати.^[1]

Приклади

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

Іншим прикладом може бути розробка програмного забезпечення, в якій багато розробників працюють над одним репозиторієм.^[2]

Архітектура класної дошки

Архітектура класної дошки — це стратегія вирішення складних системних задач із залученням різнорідних джерел знань, що взаємодіють між собою через спільне інформаційне поле. Класна дошка це центральна глобальна база даних, що містить дані та гіпотези (потенційні частини вирішення проблем), призначена для зв'язку незалежних асинхронних джерел знань. Кожне джерело знань отримує свої дані від «класної дошки», оброблює їх та повертає результати в «класну дошку» для їх подальшого використання іншими джерелами знань.

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

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

Вимоги до розв'язуваної проблеми

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

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

Історія

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

Зноски

↑ ^а ^б Blackboard Design Pattern. learn.microsoft.com (амер.). 17 січня 2024. Процитовано 13 липня 2024.
↑ Lilienthal та Schwentner, 2023, с. 271.

Література

John W. McManus. Design and analysis tools for concurrent blackboard systems
N. Carver, V. Lesser. The Evolution of Blackboard Control Architectures
Lilienthal, Carola; Schwentner, Henning (2023). Domain-Driven Transformation: Monolithen und Microservices zukunftsfähig machen (вид. 1. Auflage). Heidelberg: dpunkt.verlag. ISBN 9783864908842.