4.5.2. Парадигми проєктування: функціональна декомпозиція згори вниз, архітектура, орієнтована на дані, об'єктно-орієнтований аналіз та проєктування, подієво-керована архітектура
Декомпозиція — науковий метод, що використовує структуру завдання і дозволяє замінити вирішення одного великого завдання рішенням серії менших завдань, нехай і взаємопов'язаних, але більш простих. Декомпозиція, як процес розділення, дозволяє розглядати будь-яку досліджувану систему як складну, що складається з окремих взаємопов'язаних підсистем, які, в свою чергу, також можуть бути розділеними на частини. Як системи можуть виступати не тільки матеріальні об'єкти, а й процеси, явища і поняття. Функціональна декомпозиція (англ. Functional decomposition), також функціональне розбиття (англ. Functional breakdown structure) — процес розбиття системи на складові частини-модулі, цей процес є важливим інструментом системної інженерії.[
Функціональна декомпозиція (Functional Decomposition) допомагає управляти складністю та зменшити невизначеність, розбиваючи процеси, системи, функціональні області або результати на простіші складові частини і дозволяючи аналізувати кожну частину незалежно.
Функціональна декомпозиція (Functional Decomposition) підходить до аналізу складних систем і концепцій, розглядаючи їх як набір взаємодіючих або пов'язаних функцій, ефектів і компонентів. Така ізоляція допомагає зменшити складність аналізу.
Розбиття великих компонентів на підкомпоненти дозволяє масштабувати, відстежувати і вимірювати робочі зусилля для кожного з них. Це також полегшує оцінку успішності кожного підкомпонента в порівнянні з іншими більшими або меншими компонентами.
Глибина декомпозиції може варіюватися залежно від природи компонентів і цілей. Функціональна декомпозиція (Functional Decomposition) передбачає, що підкомпоненти можуть повністю описувати і описують свої батьківські компоненти. При розробці функціональної ієрархії будь-який підкомпонент може мати лише один батьківський компонент.
Окрім вибору підходу до побудови ІСР, необхідно вирішити напрям декомпозиції робіт проекту – методом "зверху вниз" чи "знизу вверх". У першому випадку Ієрархічна структура робіт створюється, починаючи з самого високорівневого елемента розбиттям його на природні елементи проекту. Тут же визначаються загальні завдання, на основі яких здійснюється деталізація кожного елемента. В другому випадку – визначаються окремі задачі, а потім відбувається їх узагальнення.
Архітектура програмного забезпечення (англ. software architecture) — спосіб структурування програмної або обчислювальної системи, абстракція елементів системи на певній фазі її роботи. Система може складатись з кількох рівнів абстракції і мати багато фаз роботи, кожна з яких може мати окрему архітектуру.
Дослідження архітектури програмного забезпечення намагається визначити як найкраще розбити систему на частини, як ці частини визначають та взаємодіють одна з одною, як між ними передається інформація, як ці частини розвиваються поодинці і як все вищеописане найкраще записати використовуючи формальну чи неформальну нотацію.
Архітектура повинна будуватись щоб найкраще відповідати вимогам до системи що створюється, згідно принципу "форма відповідає функції[en]".
Згідно Perry та Wolf архітектурою є набір елементів що мають певну форму (властивості і обмеження що накладаються на елементи), і їх обґрунтування[en] (англ. rationale). Обґрунтування фіксує мотиви вибору певного архітектурного стилю, елементів і обмежень. Рой Філдінг вважає що обґрунтування необхідне на етапі створення архітектури, і корисне надалі але не є невід'ємним її елементом. Тому що архітектура має набір властивостей що дозволяють їй задовольняти вимоги, і незнання цих вимог може призвести до змін що порушують архітектуру, але до архітектури входять властивості а не вимоги. Наприклад можна не знати що в "архітектуру" стола закладену вимогу стійкості, і тому він повинен мати більше двох ніжок. Не знаючи про цю вимогу, ми можемо відпиляти забагато ніжок і стіл впаде. Але це тому що ми порушили архітектурне обмеження "мати три чи більше ніжок".
Терміном "Архітектура" також називають документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими особами, дозволяє зафіксувати прийняті на ранніх етапах проєктування рішення про високорівневий дизайн системи і дозволяє використовувати компоненти цього дизайну і шаблони проєктування повторно в інших проєктах.
Важливо усвідомити, що архітектура складних систем складається як з компонентів, так і з ієрархічних відношень між цими компонентами. Всі системи мають підсистеми, і всі системи є частинами крупніших систем... Особливості системи обумовлені відношеннями між її частинами, а не частинами як такими.
Переклад далі. Архитектура, ориентированная на данные, (data-oriented architecture, DOA) была впервые описана Радживом Джоши в отчете RTI 2007 года, а затем в 2017 году Кристианом Ворхемом и Эрихом Шикутой из Венского университета в статье iiWAS. DOA — это инверсия традиционной дихотомии между монолитным кодом и хранилищем данных (монолитная архитектура) с одной стороны, и небольшими распределенными независимыми компонентами с собственными хранилищами (микросервисы и сервис-ориентированная архитектура) с другой. В архитектуре, ориентированной на данные, монолитное хранилище данных является единственным источником состояния в системе, на которое воздействуют слабосвязанные микросервисы без состояния. В архитектуре, ориентированной на данные (DOA), системы по-прежнему организованы вокруг небольших, слабосвязанных компонентов, как в микросервисах SOA. Но DOA отходит от микросервисов двумя ключевыми способами:
Компоненты всегда не имеют состояния. Вместо того, чтобы разбивать хранилища данных для каждого соответствующего компонента, DOA предписывает описывать данные или уровень состояния в терминах централизованно управляемой глобальной схемы.
Межкомпонентное взаимодействие сведено к минимуму, вместо этого предпочтение отдается взаимодействию через уровень данных.
В нашей торговой системе компонент, получающий цены на различные ценные бумаги, просто публикует цены в канонической форме в нашем хранилище данных. Система может использовать эти цены, запрашивая цены на уровне данных, а не у определенного сервиса (или набора сервисов) через конкретный API.
Здесь стоимость интеграции линейна. Изменение схемы DAO означает, что в обновлении нуждаются до N компонентов, а не до N2 связей между ними.
Такой поход действительно проявляет себя, когда отдельные высокоуровневые типы данных заполняются разными провайдерами. Если мы заменим один сервис одной таблицей, то мы не сильно упростим ситуацию. Преимущество есть, когда существует несколько источников одного и того же общего типа данных. Если торговая система подключается к нескольким торговым площадкам, каждая из которых публикует запросы клиентов в RFQ таблицу, то последующие системы могут запрашивать эту таблицу и не беспокоиться о том, откуда поступает запрос клиента.
Примеры использования архитектуры, ориентированной на данные
Одна из причин, по которой я продолжаю упоминать торговое/финансовое ПО в качестве примера, заключается в том, что финансы часто требуют большой площади интеграции. Типичная торговая фирма, позволяющая мелким клиентам торговать, часто интегрируется со многими торговыми площадками для взаимодействия с клиентами, а также со многими поставщиками ликвидности для получения цен и размещения заказов. Бизнес-логика, которая должна происходить между поступлением запроса на рынок и получением ответа от клиента, представляет собой сложный, многоступенчатый процесс.
В проблемном пространстве с высокой степенью интеграции отдельным сервисам может потребоваться знать о множестве других сервисов. Чтобы избежать сложности O(N2) в интеграции и сложных отдельных сервисов с высоким коэффициентом разветвления, перестройка системы вокруг производителей и потребителей данных позволяет упростить интеграцию. Если появится новая интеграция, вместо того, чтобы редактировать N новых систем или одну систему, которая имеет сложное разветвление для N других систем, процесс интеграции может включать написание одного адаптера, который создает данные в общей схеме DOA, принимает окончательный результат и отображает его в правильном проводном формате.
Неявно в интеграции возникает новый вид сложности: размышление о схеме. Любая новая интеграция должна быть естественной для вашей системы, а вашу схему нужно расширять без добавления прокладок, хаков и особых случаев. Это само по себе трудное задание. Однако когда количество интеграций достаточно велико, сложность амортизируется и часто окупается.
Если вы создаете прототип или тестируете что-то вручную, надеюсь, вы это делаете вне продакшена. Тем не менее то, как устроены некоторые SOA-экосистемы, часто говорит, что нелегко понять, в какой среде находится сервис, или является ли конкретная среда вообще автономной.
На данный момент существует множество распространенных примеров, приближенных к архитектуре, ориентированной на данные. Монолит данных, в котором все (или большинство) данных хранятся в одном большом хранилище, часто говорит, что архитектура системы приближена к DOA.
Knowledge Graphs, например, представляют собой обобщенный монолит данных. Тем не менее они часто недостаточно универсальны; при этом многие состояния, связанные с бизнес-логикой, потенциально отсутствуют.
GraphQL часто используется в качестве нормализованного слоя хранилища данных, такого как монолит данных. Степень, в которой GraphQL можно успешно сделать серверной частью системы DOA, в большей степени зависит от дизайна схемы: например, можно выбрать обобщенную схему и таблицы, связанные с концепциями бизнес-логики, а не схемы и таблицы, специфичные для конкретного источника этих данных.
ПЕРЕКЛАД: Архітектура, орієнтована на дані, (data-oriented architecture, DOA) була вперше описана Радживом Джоші у звіті RTI 2007 року, а потім у 2017 році Крістіаном Ворхемом та Еріхом Шикутою з Віденського університету у статті iiWAS. DOA — це інверсія традиційної дихотомії між монолітним кодом та сховищем даних (монолітна архітектура) з одного боку, та невеликими розподіленими незалежними компонентами з власними сховищами (мікросервіси та сервіс-орієнтована архітектура) з іншого. В архітектурі, яка орієнтована на дані, монолітне сховище даних є єдиним джерелом стану в системі, на яке впливають слабопов'язані мікросервіси без стану. В архітектурі, орієнтованій на дані (DOA), системи, як і раніше, організовані навколо невеликих, слабко пов'язаних компонентів, як у мікросервісах SOA. Але DOA відходить від мікросервісів двома ключовими способами:
1. Компоненти не мають стану. Замість того, щоб розбивати сховища даних для кожного відповідного компонента, DOA пропонує описувати дані або рівень стану в термінах централізовано керованої глобальної схеми.
2. Міжкомпонентна взаємодія зведена до мінімуму, натомість перевага надається взаємодії через рівень даних.
У нашій торговій системі компонент, який одержує ціни на різні цінні папери, просто публікує ціни в канонічній формі в нашому сховищі даних. Система може використовувати ці ціни, запитуючи ціни лише на рівні даних, а чи не в певного сервісу (чи набору сервісів) через конкретний API.
Тут вартість інтеграції є лінійною. Зміна схеми DAO означає, що оновлення потребують N компонентів, а не N2 зв'язків між ними.
Такий похід справді поводиться, коли окремі високорівневі типи даних заповнюються різними провайдерами. Якщо ми замінимо один сервіс однією таблицею, ми не дуже спростимо ситуацію. Перевага є, коли є кілька джерел однієї й тієї ж загального типу даних. Якщо торгова система підключається до кількох торгових майданчиків, кожен із яких публікує запити клієнтів у RFQ таблицю, наступні системи можуть запитувати цю таблицю і турбуватися у тому, звідки надходить запит клієнта.
Приклади використання архітектури, орієнтованої на дані
Одна з причин, через яку я продовжую згадувати торгове/фінансове ПЗ як приклад, полягає в тому, що фінанси часто вимагають великої площі інтеграції. Типова торгова фірма, що дозволяє дрібним клієнтам торгувати, часто інтегрується з багатьма торговими майданчиками для взаємодії з клієнтами, а також з багатьма постачальниками ліквідності для одержання цін та розміщення замовлень. Бізнес-логіка, яка повинна відбуватися між надходженням запиту на ринок та отриманням відповіді від клієнта, є складним, багатоступеневим процесом.
У проблемному просторі з високим ступенем інтеграції окремим сервісам може знадобитися безліч інших сервісів. Щоб уникнути складності O(N2) в інтеграції та складних окремих сервісів із високим коефіцієнтом розгалуження, перебудова системи навколо виробників та споживачів даних дозволяє спростити інтеграцію. Якщо з'явиться нова інтеграція, замість того, щоб редагувати N нових систем або одну систему, яка має складне розгалуження для N інших систем, процес інтеграції може включати написання одного адаптера, який створює дані у загальній схемі DOA, приймає остаточний результат та відображає його у правильному провідному форматі.
Неявно в інтеграції виникає новий вид складності: міркування про схему. Будь-яка нова інтеграція має бути природною для вашої системи, а вашу схему потрібно розширювати без додавання прокладок, хаків та особливих випадків. Це саме собою важке завдання. Однак, коли кількість інтеграцій досить велика, складність амортизується і часто окупається.
Якщо ви створюєте прототип або тестуєте щось вручну, сподіваюся, ви це робите поза продакшеном. Проте те, як влаштовані деякі SOA-екосистеми, часто каже, що нелегко зрозуміти, в якому середовищі знаходиться сервіс, чи конкретне середовище взагалі автономне.
На даний момент існує безліч поширених прикладів, наближених до архітектури, орієнтованої на дані. Моноліт даних, у якому всі (або більшість) даних зберігаються в одному великому сховищі, часто каже, що архітектура системи наближена до DOA.
Knowledge Graphs, наприклад, є узагальнений моноліт даних. Проте вони часто недостатньо універсальні; при цьому багато статків, пов'язаних з бізнес-логікою, потенційно відсутні.
GraphQL часто використовується як нормалізований шар сховища даних, такого як моноліт даних. Ступінь, у якій GraphQL можна успішно зробити серверною частиною системи DOA, більшою мірою залежить від дизайну схеми: наприклад, можна вибрати узагальнену схему та таблиці, пов'язані з концепціями бізнес-логіки, а не схеми та таблиці, специфічні для конкретного джерела цих даних.
Межі між стадіями аналізу й проектування розмиті, але розв'язувані ними задачі визначаються досить чітко. У процесі аналізу ми моделюємо проблему, виявляючи класи й об'єкти, які становлять словник предметної області. При об’єктно-орієнтовному проектуванні ми винаходимо абстракції й механізми, що забезпечують необхідну поведінку.
Розглянемо перевірені практикою підходи до аналізу об’єктно-орієнтовних систем.
Класичні підходи. Різні вчені знаходять різні джерела класів і об'єктів, які необхідні згідно вимог предметної області. Ми називаємо ці підходи класичними, оскільки вони спираються на класичну категоризацію.
Існують такі кандидати для класів й об'єктів:
На вищому рівні абстракції Коад вводить поняття предметної області, яка є логічно зв'язаною групою класів, які відносяться до високорівневих функцій системи.
Аналіз поведінки. У той час як класичні підходи зосереджують увагу на реальних елементах предметної області, інша школа думки об’єктно-орієнтовного аналізу зосереджує увагу на динамічній поведінці як на першоджерелі об'єктів і класів. Це нагадує концептуальну кластеризацію, розглянуту вище: ми формуємо класи, ґрунтуючись на групах об'єктів, що демонструють подібну поведінку.
Відповідальності об'єкта - його знання й вміння. Відповідальність - це спосіб виразити мету об'єкта і його місце в системі. Відповідальність об'єкта є сукупністю всіх послуг, які він може надавати за всіма його контрактами. Тобто, ми з’єднюємо разом ті об'єкти, які мають подібні відповідальності й будуємо ієрархію класів, в якій кожний підклас, виконуючи зобов'язання суперкласу, привносить свої додаткові послуги.
Можна ідентифікувати класи й об'єкти, аналізуючи функціонування системи. Співставляється форма поведінки із частинами системи й намагаємося зрозуміти, яка частина ініціює поведінку і які частини в ній беруть участь... Ініціатори й учасники, які відіграють істотні ролі, розпізнаються як об'єкти й стають відповідальними за ці ролі.
Функція визначається як окрема бізнес-дія кінцевого користувача, тобто: введення/виведення, запит, файл або інтерфейс. Очевидно, що ця концепція походить із області інформаційних систем. Однак, вона може бути застосована до будь-якої автоматизованої системи. По суті, функція - це будь-яка видима ззовні й маюча відношення до справи поведінка системи.
Аналіз предметної області. Дотепер ми неявно мали на увазі розроблення єдиної ІС. Але іноді в пошуках корисних і таких, що вже довели свою працездатність ідей корисно звернутися відразу до всіх систем, що функціонують у рамках цієї предметної області, як, наприклад, ведення історій хвороби пацієнтів, торгівля цінними паперами, розроблення компіляторів або системи керування ракетами. Якщо ви перебуваєте в середині розроблення й застрягли, аналіз якої-небудь вузької предметної області може допомогти, вказавши вам на ключові абстракції, які є корисними в подібних системах. Аналіз предметної області працює дуже добре, за виключенням спеціальних ситуацій, однак такі унікальні програмні системи зустрічаються вкрай рідко.
Ідею аналізу ПО вперше запропонував Нейборс. Ми визначимо такий аналіз як спробу виділити ті об'єкти, операції й зв'язки, які експерти цієї області вважають найважливішими. Існують такі етапи аналізу ПО:
Побудова скелетної моделі предметної області під час консультацій з експертами цієї області.
Вивчення існуючих у цій області систем і подання результатів у стандартному вигляді.
Визначення подібності й відмінностей між системами за участю експертів.
Уточнення загальної моделі для пристосування до потреб конкретної системи.
Аналіз області можна вести щодо аналогічних інформаційних систем (вертикально) або щодо аналогічних частин цієї самої інформаційної системи (горизонтально). Наприклад, починаючи проектувати систему обліку пацієнтів, є сенс розглянути вже наявні подібні системи, щоб зрозуміти, які ключові абстракції й механізми, використані в них, будуть вам корисні, а які ні. Аналогічно система бухгалтерського обліку повинна представляти різні види звітів. Якщо вважати звіти якоюсь предметною областю, її аналіз може привести розробника до розуміння ключових абстракцій і механізмів, які обслуговують всі види звітів. Отримані в такий спосіб класи й об'єкти являють собою множину ключових абстракцій і механізмів, відібраних з врахуванням мети вихідної задачі: створення системи звітів. Тому остаточний проект буде простіший.
Визначимо тепер, хто такий експерт? В ролі експерта часто виступає просто користувач системи, наприклад, інженер або диспетчер. Він не обов'язково повинен бути програмістом, але повинен бути близько знайомим з досліджуваною проблемою й розмовляти мовою цієї проблеми.
Менеджери проектів зацікавлені в безпосередній співпраці користувачів і розробників системи. Але для дуже складних систем прикладний аналіз є формальним процесом, для якого потрібне велике число експертів і розробників на тривалий період часу. На практиці такий формальний аналіз зрідка потрібний. Зазвичай для початкового з'ясування проблеми досить короткої зустрічі експертів і розробників. Дивно, як мало інформації потрібно для продуктивної роботи розробника. Однак ми вважаємо надзвичайно корисними такі зустрічі протягом всього процесу розроблення ІС. Аналіз ПО найкраще вести крок за кроком - трохи проаналізувати, потім спроектувати і т.д.
Аналіз варіантів. Окремо класичний підхід, поведінковий підхід і вивчення предметної області, розглянуті вище, сильно залежать від індивідуальних здібностей і досвіду аналітика. Для більшості реальних проектів одночасне застосування всіх трьох підходів неприйнятне, тому що процес аналізу стає недетермінованим і непередбаченим.
Аналіз варіантів - це підхід, який можна успішно об’єднати з першими трьома, роблячи їх застосування більше впорядкованим. Варіант застосування – це приватний приклад або зразок використання, сценарій, що починається з того, що користувач системи ініціює операцію або послідовність взаємозалежних подій.
Коротко кажучи, цей вид аналізу можна починати разом з аналізом вимог. У цей момент користувачі, експерти й розробники перераховують сценарії, найсуттэвыші для роботи системи (поки не заглиблюючись у деталі). Потім вони ретельно проробляють сценарії, розкладаючи їх за кадрами, як роблять телевізійники й кінематографісти. При цьому вони встановлюють, які об'єкти беруть участь у сценарії, які обов'язки кожного об'єкта і як вони взаємодіють у термінах операцій. Тим самим група розроблювачів змушена чітко розподілити області впливу абстракцій. Далі набір сценаріїв розширюється, щоб врахувати виняткові ситуації й вторинну поведінку. У результаті з'являються нові або уточнюються існуючі абстракції.
CRC-картки. CRC позначає Class – Responsibilities - Collaborators (Клас / Відповідальності/ Учасники). Це простий і чудово ефективний спосіб аналізу сценаріїв. Карти CRC вперше запропонували Бек і Каннінгхем для навчання об’єктно-орієнтовному програмуванню, але такі картки виявилися чудовим інструментом для мозкових атак і спілкування розроблювачів між собою.
Це звичайні бібліографічні картки 3х5 дюйми. На картках пишіть (обов'язково олівцем) зверху - назвуа класу, знизу в лівій половині - за що він відповідає, а в правій половині - з ким він співпрацює. Проходячи сценаріями, заводите картки на кожний виявлений клас і дописуєте в неї нові пункти. При цьому щораз обмірковуйте, що із цього виходить, і "виділяйте надлишок відповідальності" у новий клас або, що трапляється найчастіше, перенесіть відповідальності з одного великого класу на детальніші класи, або, можливо, передайте частину обов'язків іншому класу.
Картки можна розкладати так, щоб представити форми співпраці об'єктів. З погляду динаміки сценарію, їх розташування може показати потік повідомлень між об'єктами, з погляду структури вони представляють ієрархію класів.
Неформальний опис. Радикальна альтернатива класичному аналізу була запропонована в надзвичайно простому методі Аббота. Відповідно до цього методу треба описати завдання або її частину на природній мові, а потім підкреслити іменники й дієслова. Іменники - кандидати на роль класів, а дієслова можуть стати іменами операцій. Метод можна автоматизувати, і така система була побудована в Токійському технологічному інституті.
Підхід Аббота корисний, тому що він простий і змушує розроблювача займатися словником предметної області. Однак він досить приблизний і непридатний для складних проблем. Природня мова - неточний засіб вираження, тому список об'єктів і операцій залежить від вміння розроблювача записувати свої думки. Тим більше, що для багатьох іменників можна знайти відповідну дієслівну форму й навпаки.
Структурний аналіз. Інша альтернатива класичній техніці об’єктно-орієнтовного аналізу використовує структурний аналіз як основу для об’єктно-орієнтовного проектування. Такий підхід привабливий тому, що багато аналітиків застосовують цей підхід і є велика кількість програмних CASE-засобів, що підтримують автоматизацію цих методів. Нам особисто не подобається використовувати структурний аналіз як основу для об’єктно-орієнтовного проектування, але для деяких організацій такий прагматичний підхід не має альтернативи.
Після проведення структурного аналізу ми вже маємо модель системи, описану діаграмами потоків даних і іншими продуктами структурного аналізу. Ці діаграми дають нам формальну модель проблеми. Виходячи з моделі, ми можемо приступити до визначення осмислених класів і об'єктів трьома різними способами.
Насамперед необхідно приступити до формування словника даних, а потім до аналізу контекстних діаграм моделі. Розглядаючи список основних структур даних, варто подумати, про що в них йдеться говорять або що вони описують. Наприклад, якщо вони прикметники, то які іменники вони описують? Відповіді на такі питання можуть поповнити ваш список об'єктів. Ці кандидати в об'єкти походять із навколишнього середовища, з істотних вхідних і вихідних даних, а також продуктів, послуг і інших ресурсів, якими вона керує.
Наступні два способи базуються на аналізі окремих діаграм потоків даних. Якщо взяти яку-небудь діаграму потоків, то кандидатами в об'єкти є:
зовнішні сутності;
сховища даних;
сховища керуючих сутностей;
керуючі перетворення.
Кандидати в класи:
потоки даних;
потоки керування.
Залишається перетворення даних, яке ми можемо розглядати як операції над існуючими об'єктами або як поведінка деякого об'єкта, який ми створили спеціально для виконання потрібного перетворення.
Існує ще один метод, який називається аналізом абстракцій. Цей метод базується на ідентифікації основних сутностей, які за своєю природою аналогічні основним перетворенням у структурному проектуванні. У структурному аналізі вхідні й вихідні дані вивчаються доти, поки не досягнуть вищого рівня абстракції. Процес перетворення вхідних даних у вихідні є основним перетворенням. В абстрактному аналізі розроблювач робить теж саме, а також вивчає основне перетворення для того, щоб визначити, які процеси й стани представляють найкращу абстрактну модель системи. Після визначення основної сутності в діаграмі потоків даних аналітик приступає до вивчення всієї інфраструктури, простежуючи вхідні й вихідні потоки даних із центру, групуючи процеси й стани, що зустрічаються на шляху. Для практичного використання аналіз абстракцій занадто складний і як альтернативу пропонують ООА.
Необхідно відзначити, що принципи структурного проектування, яке слідує за структурним аналізом, повністю ортогональні принципам об’єктно-орієнтованого проектування ООП. Наш досвід показує, що використання структурного аналізу в процесі ООП часто приводить до повного провалу. Інша дуже серйозна небезпека полягає в тому, що багато аналітиків люблять рисувати діаграми потоків даних, які є скоріше описом проекту, ніж модель системи. Дуже складно побудувати об’єктно-орієнтовну систему, якщо модель настільки очевидно орієнтована на алгоритмічну декомпозицію. Тому ми віддаємо перевагу об'єктно-орієнтованому аналізу й аналізу предметної області як підготовчий етап об'єктно-орієнтованого проектування. При цьому зменшується ризик засмітити проект елементами алгоритмічного аналізу.
Об'єктно-орієнтоване проектування - це методологія проектування, що поєднує процес об'єктної декомпозиції і прийоми подання логічної і фізичної, а також статичної і динамічної моделей проектованої системи.
Використання об'єктно-орієнтованої методології зараз нерозривно пов'язано з використанням мови UML (Unified Modeling Language - уніфікована мова моделювання), що “являє собою систему позначень, що базується на діаграмах і призначена для моделювання систем на основі об'єктно-орієнтованого підходу”.
Найбільш важним моментом об’єктно-орієнтованого аналізу і проектування є кваліфіковане розподілення обов’язків між компонентами програмної системи.
До розподілення обов’язків по степені важності більш всього примикають виділення об’єктів або абстракцій. Важливе місце займають обидва аспекти, але розподіленню обов’язків відводиться перше місце.
Основна ідея об’єктно-орієнтованого аналізу і проектування полягає в тому, що предметна область і логічний розв’язок задачі розглядається розглядаються з точки зору об’єктів (понять або сутностей).
В процесі ООА основна увага приділяється визначенню та опису об’єктів (понять) в термінах предметної області. В процесі ОО проектування визначаються програмні об’єкти, які будуть реалізовані засобами об’єктноорієнтованої мови програмування.
В процесі конструювання або ОО програмування забезпечується реалізація розроблених компонентів, таких як класи певною мовою програмування.
При цьому основна увага приділяється розподіленню обов’язків. Розподілення обов’язків означає виділення задач і обов’язків різних програмних об’єктів в застосуванні подібно до розподілення функціональних обов’язків між співробітниками. Програмні об’єкти, як і люди, в процесі виконання своїх функцій зазвичай взаємодіють між собою. Обов’язки об’єктів та їх взаємодію відображають за допомогою діаграми класів і діаграми взаємодії. На цих діаграмах відображаються класи та потоки повідомлень між програмними об’єктами.
Подійно-орієнтована архітектура (англ. Event-driven architecture; надалі EDA) — шаблон архітектури програмного забезпечення, який призначений для створення подій, їх виявлення, споживання і реагування на них.
Подія може бути визначена як значна зміна стану. Наприклад, коли споживач купує автомобіль, стан автомобіля змінюється з «на продаж» до «продано». Архітектура системи дилера автомобілів може трактувати цю зміну стану як подію, поява якої може стати відомою іншим застосункам даної архітектури.
З формальної точки зору, те, що виробляється, публікується, поширюється, виявляється і споживається (як правило, асинхронно) є повідомленням, яке називають сповіщенням про подію (або нотифікацією), а не самою подією, яка є зміною стану, що викликає появу повідомлення.
Події не подорожують, вони просто відбуваються. Проте термін подія часто використовується метонімічно для позначення самого нотифікаційного повідомлення, що може призвести до певної плутанини.
Цей архітектурний шаблон може застосовуватися при проектуванні і реалізації застосунків і систем, які передають події між слабкозв'язаними компонентами програмного забезпечення і сервісами (службами).
Подійно-орієнтована система як правило складається з емітерів подій (або агентів) і споживачів подій (або стоків). Стоки несуть відповідальність за здійснення реагування на появу події. Реакція не завжди може бути повністю забезпечена самим стоком. Наприклад, стік, може бути відповідальним лише за фільтрацію, трансформацію і відправку події до іншого компонента або він може забезпечити повністю самостійну реакцію на таку подію. Перша категорія стоків може бути заснована на традиційних компонентах, таких як проміжне програмне забезпечення, орієнтоване на обробку повідомлень (англ. message oriented middleware, MOM), в той час, як друга категорія стоків (самостійна реакція в режимі онлайн) може вимагати більш придатної платформи (фреймворку) для виконання транзакцій.
Розробка застосунків і систем в подійно-орієнтованій архітектурі дозволяє їм бути сконструйованими способом, який більш відповідає вимогам до їх створення, оскільки такі системи в більшій мірі пристосовуються до непередбачуваних і асинхронних середовищ.
Подійно-орієнтована архітектура (EDA) може доповнювати сервісно-орієнтовану архітектуру (SOA), оскільки сервіси (служби) можуть бути активовані тригерами, які ініціюються при настанні подій.
Ця парадигма особливо корисна, коли стік не забезпечує власного виконання будь-яких дій.
Обчислювальна техніка та сенсорні пристрої (сенсори, датчики, контролери) можуть виявляти зміни стану об'єктів або умов і створювати події, які потім можуть бути оброблені сервісом (службою) або системою.
Структура події. Подія може складатися з двох частин: заголовка події та тіла події. Заголовок події може включати в себе інформацію таку як, наприклад, назва події, часова мітка події і тип події. Тіло події — це частина, яка описує факт, що стався в дійсності. Тіло події не слід плутати з шаблоном або логікою, яка може бути застосована як реакція на саму події.
Рівні потоку подій. Архітектура, керована подіями, складається з чотирьох логічних рівнів (шарів). Вона починається з виявлення факту, його технічного подання у формі події і закінчується непустою множиною реакцій на цю подію.
Першим логічним шаром є генератор подій, який виявляє факт і представляє цей факт подією. Оскільки фактом може бути практично все, що може бути сприйнято, то ним може бути і генератор подій. Наприклад, генератором може бути клієнт електронної пошти, система електронної комерції або певний тип датчика. Перетворення різних даних, отриманих від датчиків, в єдину стандартизовану форму даних, які можуть бути оцінені, є основною проблемою при розробці та реалізації цього шару.[4] Однак, враховуючи, що подія є строго декларативною, можна легко застосовувати будь-які операції трансформації, тим самим усуваючи необхідність забезпечення високого рівня стандартизації.
Канал подій — це механізм, через який інформація від генератора подій передається до обробника подій (event engine)[4] або стоку. Це може бути з'єднання TCP/IP або вхідний файл будь-якого типу (простий текст, формат XML, e-mail тощо). В один і той же час може бути відкрито кілька каналів подій. Як правило, оскільки обробник подій повинен працювати в режимі, наближеному до реального часу, канали подій зчитуються асинхронно. Події зберігаються в черзі, очікуючи наступної обробки механізмом обробки подій.
Механізм обробки подій (event processing engine) є місцем, де подія ідентифікується і вибирається відповідна реакція на нього, яка потім виконується. Це також може призвести до породження ряду тверджень. Якщо подія, яка надійшла до механізму обробки подій, є наприклад такою «Запаси продукту ID досягли нижнього допустимого рівня», це може ініціювати, наприклад, такі реакції як «Замовити продукт ID» і «Сповістити персонал».
Наступна подійно-орієнтована дія (післядія). Щодо того, як можуть проявлятися наслідки події, слід відмітити, що вони можуть проявитись багатьма різними способами і у різноманітних формах (наприклад, повідомлення електронної пошти, надіслане комусь, або застосунок, що виводить деяке попередження на екран). Залежно від рівня автоматизації, який забезпечується стоком (механізмом обробки подій), ці дії можуть виявитись зайвими.
Є три основні стилі обробки подій: простий, потоковий і складний. Часто ці три стилі використовуються спільно у розвинутій подійно-орієнтованій архітектурі.
Проста обробка подій стосується подій, які безпосередньо належать до специфічних вимірних змін умов. У випадку простої обробки подій, мають справу з появою відомих подій, що ініціюють післядію (післядії). Проста обробка подій зазвичай використовується для управління потоком робіт в реальному часі, скорочуючи тим самим час затримки і вартість робіт.
Наприклад, прості події можуть створюватись (породжуватись) датчиком, що виявляє зміну тиску в шині або температуру навколишнього середовища.
При обробці потоку подій (ESP — англ. event stream processing) відбуваються як звичайні, так і відомі події. Звичайні події (заявки, передачі RFID) перевіряються на те, чи є вони відомими, і передаються інформаційним передплатникам. Обробка потоку подій зазвичай використовується для управління потоком інформації в реальному часі і на рівні підприємства, що дозволяє своєчасно приймати рішення.
Обробка складних подій (Complex event processing (CEP)[en]) дозволяє за шаблонами простих і звичайних подій проводити аналіз того, чи сталася складна подія. Обробка складних подій полягає в оцінюванні взаємного впливу подій і в наступному виконанні дій. При цьому, типи подій (відомих або звичайних) можуть перетинатись, а події можуть виникати протягом тривалого періоду часу.
Кореляція подій може бути причинною, тимчасовою або просторовою. CEP вимагає використання складних інтерпретаторів подій, визначення і підбору шаблонів подій, а також відповідних кореляційних методів. Обробка складних подій зазвичай використовується для виявлення і реагування на аномальну поведінку, загрози і можливості у бізнесі.[4]
Екстремальне слабке зв'язування і добра розподіленість. Подійно-орієнтована архітектура є екстремально слабко зв'язаною і добре розподіленою. Найкраща розподіленість цієї архітектури обумовлена тим, що подією може бути майже все, що завгодно, і подія може існувати майже скрізь, де завгодно.
Архітектура є екстремально слабко зв'язаною, оскільки подія сама по собі не знає про наслідки свого виникнення, тобто якщо у нас є охоронна система, що записує інформацію при відкритті зовнішніх дверей, то двері самі по собі не знають, що охоронна система додасть інформацію про відкриття дверей відразу, як тільки вони будуть відчинені.
Подійно-орієнтовані архітектури мають слабкий зв'язок у просторі, часі і синхронізації, чим забезпечують масштабовану інфраструктуру для обміну інформацією і розподілених потоків робіт (workflow). В той самий час, подійні архітектури є тісно зв'язаними через підписку на події і шаблони подій з семантикою базової схеми подій і їх значень.
Високий рівень семантичної неоднорідності подій у масштабних і відкритих проектах, таких як «розумні міста» або сенсорні мережі типу «sensor web», що застосовуються для моніторингу навколишнього середовища, ускладнює розвиток і підтримку подійно-орієнтованих систем. Усунення цих проблем є активною областю досліджень в галузі застосування методів наближеного семантичного зіставлення подій.