Архітектурне проектування полягає у визначенні головних структурних особливостей системи, яку будують, а саме: складу компонент, способів їхньої композиції, обмежень на їхні з’єднання.
Сучасні програмні системи - це досить складні композиції різних функцій, яким відповідають програмні модулі. Водночас є тисячі готових програмних продуктів, котрі можна включити в будь-яку програмну систему для виконання чітко визначених функцій, при цьому примітивні функції можуть складати композиції, які виконують певні узагальнені функції, ті, в свою чергу, можуть пов’язуватися в нові композиції тощо. Для того, щоб сукупність готових до використання засобів можна було переглянути й зрозуміти, введено певну пошарову їхню структуризацію (рисунок 4.2).
Рисунок 4.2 - Пошарова архітектура напрацювань у програмній інженерії
До першого, нижчого шару відносять системні компоненти, котрі здійснюють організацію взаємодії з так званими периферійними пристроями комп’ютерів (принтери, клавіатура, сканери, маніпулятори тощо). Вони здебільшого використовуються при побудові операційних систем і не потрапляють у поле зору розробників прикладних застосувань.
До другого шару відносять так звані загальносистемні компоненти або посередники, котрі забезпечують взаємодію прикладних застосувань з універсальними сервісними системами, з такими, як операційні системи, системи баз даних та знань, системи керування мережами тощо. Компоненти цього шару використовуються в багатьох прикладних застосуваннях як складові компонент прикладних програмних систем.
До третього шару відносять специфічні для певної проблемної галузі й залежні від неї компоненти, які може бути використано як складові для спектра програмних систем, призначених для розв’язання задач означеної галузі (так званої сім’ї програмних систем).
Нарешті, до четвертого шару відносять програмні системи, побудовані для вирішення конкретних задач конкретних груп споживачів інформації, заради яких, власне, і створено компоненти всіх інших шарів.
Компоненти кожного з поданих шарів використовуються, зазвичай, тільки в своєму шарі та в наступному (вищому шарі). Для кожного шару на сьогодні визначено відповідний набір професійних знань, умінь та навичок для створення й використання його компонент, що, певною мірою, визначає відповідне розшарування професіоналів у програмній інженерії.
Ведучи мову про архітектурне проектування програмних систем, ми будемо розглядати переважно бачення програмної системи як композиції компонентів третього шару, тоді як використання компонентів другого шару є предметом розгляду технічного й детального проектування (див. нижче).
Ми отримали продукт етапу інженерії вимог як сукупність об’єктів, котрі належать до певного сценарію і взаємодія яких реалізує потрібні функції цього сценарію. Спробуємо з’ясувати, чи можна вважати об’єднання сукупностей об’єктів для всіх визначених сценаріїв системи складовими архітектури цільової системи? Інакше кажучи, чи можемо ми вважати, що такі об’єкти належать то третього шару компонент і їхня композиція є наочним представленням архітектури системи.
Відповідь на ці запитання негативна з таких міркувань: для складних систем кількість виділених об’єктів може налічувати сотні, і їхня композиція не буде мати виразного та зрозумілого подання, навіть з урахуванням тієї обставини, що об’єкти, багатьох сценаріїв можуть збігатися, тому буде потрібний додатковий аналіз для ототожнення їх.
Згадаємо основні принципи, напрацьовані як рекомендації для декомпозиції складної системи на компоненти або модулі:
- для компоненти має бути чітко визначена мета, щоб можна було перевірити, чи вона її виконує;
- для компоненти має бути чітко визначено всі її входи та виходи;
- компоненти мають утворювати ієрархію, кожний рівень якої відповідає рівню абстракції розгляду системи і дозволяє приховувати певні деталі, які буде відпрацьовано на наступних рівнях. Така покрокова деталізація прийняття рішень не стільки розподіляє вирішення складного завдання на кілька вирішень простіших завдань, скільки дозволяє відкласти детальні розв’язання проблем, щоб зосередитися на розв’язанні загальних рішень;
- робота над компонентами може вестися окремими членами команди із застосуванням кількох інструментальних засобів для кількох компонент, що суттєво впливає на ефективність роботи; але при цьому інтерфейси між компонентами мають бути прозорими й узгодженими, щоб інтеграція компонент в єдину структуру була можливою і базувалася на спільному розумінні проблеми. При цьому ключова якість об’єктного підходу - інкапсуляція внутрішніх дій і приховування всіх подробиць, які не стосуються правил використання компоненти - має діяти і для підсистеми як композиції об’єктів.
Враховуючи зазначене вище, можна прийти до висновку, що отримані нами сукупності об’єктів доцільно об’єднувати в підсистеми. При цьому необхідно керуватися такими міркуваннями:
а) кожна створювана підсистема має асоціюватися з певними елементами продукту інженерії вимог (як, наприклад, актор, сценарій, об’єкт тощо);
б) доцільно необов’язкові функції або часто змінювані функції виділяти як підсистеми, при цьому бажано кожну функцію, для якої прогнозуються зміни вимог, виділяти як окрему підсистему, пов’язану з одним актором (бо зміни найчастіше викликаються актором). Те саме можна рекомендувати і для функцій, використання яких у системі необов’язкове (довільне) і його може не бути залежно від обставин використання системи;
в) інтерфейс підсистеми тим більше прозорий і зрозумілий, чим менше вона має взаємозв’язків з іншими підсистемами. Бажано, щоб кожна підсистема виконувала мінімум зрозуміло визначених послуг або функцій (в ідеалі - тільки одну) та мала фіксовану множину чітко визначених параметрів інтерфейсу.
Можна перелічити типи зв’язків, характерних для об’єктів:
зв’язок за внесенням змін, коли зміна одного об’єкта потребує перегляду другого або обидва об’єкти залежать від зміни третього (наприклад, об’єкт-сутність та об’єкт управління залежать від об’єкта- інтерфейсу);
зв’язок за управлінням, коли керований об’єкт не може виконувати свої функції без повідомлень керуючого або один об’єкт стимулює виконання операцій другого;
зв’язок за даними, коли дані (атрибути) одного об’єкта використовуються другим. При цьому можуть передаватися тільки значення даних або, поряд зі значеннями даних, передається метаінформація щодо організації їх, необхідна для правильної інтерпретації даних.
Відокремивши змінювані й довільні підсистеми, проведемо аналіз зв’язків та залежностей, які є між об’єктами, що залишилися, з метою утворення підсистем з тісними внутрішніми зв’язками між об’єктами та прозорими зовнішніми інтерфейсами.
Способи об’єднання об’єктів у підсистему можна кваліфікувати так:
- зернисте поєднання - в підсистему об’єднуються об’єкти, які нічим не пов’язані між собою (відповідну підсистему створено для простого укрупнення компонент архітектури);
- логічне поєднання - в підсистему об’єднуються об’єкти, які є функціонально незалежними, але мають якусь спільну властивість, або для яких можна встановити певне логічне відношення (наприклад, ту саму функцію реалізовано для багатьох середовищ, як-от введення даних для дисків та портів мережі або різних типів даних, як, наприклад, цілого або комплексного);
- об’єднання за часом - у підсистему об’єднуються незалежні об’єкти, які активізуються в спільний проміжок часу;
- комунікативне об’єднання - в підсистему об’єднуються об’єкти, які мають спільне джерело даних;
- процедурне об’єднання - в підсистему об’єднуються об’єкти, які послідовно передають одне одному керування;
- функціональне об’єднання - коли кожний з об’єктів, що входить у підсистему, виконує частину робіт для здійснення загальної функції, яку виконує підсистема, тобто всі об’єкти виконують спільне завдання.
Ми неодноразово підкреслювали, що розробляючи систему, слід постійно пам’ятати тезу: "Всяка зроблена система з часом потребує змін". Якщо проаналізувати наведені вище способи поєднання об’єктів у підсистеми з погляду стійкості до змін, коли кожна зміна вимоги потребує відповідної корекції мінімальної кількості архітектурних компонентів, то можна зробити висновок, що всі способи 1-5 не сприяють полегшенню модифікації вимог. Що ж до функціонального поєднання, то якщо ціль, яку реалізує таке поєднання, відповідає певним вимогам у моделі вимог, трасування вимог у моделі проекту можна вважати досягнутим.
Якщо в новостворюваній системі передбачається використання готових систем (так званих успадкованих систем), їх доцільно вважати підсистемами новостворюваної системи.
Використання готових компонент або спільних компонент для підсистем потребує спеціального розгляду, який буде подано у розділі 7.
Архітектурне проектування може потребувати перегляду моделі аналізу вимог. Наприклад, якщо поведінка певного об’єкта частково використовується в кількох підсистемах, таку частину доцільно виділити в окремий об’єкт або навіть у підсистему.
Виділення підсистем для дуже великих проектів є досить складною роботою і може вестися з урахуванням дещо інших критеріїв. Наприклад, якщо розроблення ведуть декілька груп різних рівнів компетентності або різних рівнів забезпеченості ресурсами, або роз’єднаних географічно, розподілення на підсистеми може вестися з пріоритетним урахуванням обставин, згаданих вище. Аналогічно при наявності розподіленого устаткування кожний логічний вузол може бути асоційовано з підсистемою.
Нотації для архітектурного проектування розглядаються в п. 5.10.
Вінницький національний технічний університет