аналіз спільності та розбіжностей у створених досі системах;

 зіставлення вимог до нової системи з можливостями створених;

 прогнозування можливих змін у вимогах (до тих систем, що аналізуються) та виникнення потреб у нових системах;

 пошук компонент – кандидатів для повторного використання.

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

Готова система постає перед тим, хто має зрозуміти й проаналізувати її як послідовність формалізованих моделей у відповідних нотаціях, властивих тому чи іншому методу (як-от подані у розділах 3 - 5 діаграми UML, І. Джекобсона чи С. Шлеєр та С. Меллора), а також як неформальні описи, коментарі до моделей та рекомендацій із застосування для користувачів.

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

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

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

Можна назвати властивості проекту, для яких доцільно зафіксувати варіантність сценарію та акторів [8]. Це такі властивості.

Варіантність інтерфейсів для категорій користувачів або для програмних систем. Приклади:

а) керівники різних рівнів потребують різнорівневих подробиць для видачі показників;

б) прикладні застосування відрізняються тим, що використовують різні СУБД;

в) різні інсталяції потрібні для окремих підрозділів організації, котрі працюють на різних конфігураціях устаткування.

Робота з кількома взаємозамінними типами об'єктів-сутностей. Приклади:

а) різноманітні типи приладів, котрі можуть вимірювати або регулювати однакові показники на конкретному "борту" літака в різних системах вимірювання, як-от відстань у кілометрах чи милях, пальне у літрах чи галонах тощо;

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

Функції, виконання яких в окремих випадках необов'язкове. Приклади:

а) клієнт, відправивши поштою оплату покупки, може інколи обумовити зворотне повідомлення про надходження платні;

б) під час тестування можна видавати чи не видавати контрольні значення;

в) дані в процесі введення можна контролювати чи не контролювати.

Обмеження на застосування або на правила бізнесу. Приклади:

а) в Україні правила обчислення податків часто змінюються;

б) правила перевірки прав доступу клієнта до банківського рахунка постійно вдосконалюються;

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

Усунення помилок. Приклади:

а) коригування на основі гранично допустимих даних;

б) перехід до стану, що передував тому, в якому знайдено помилку функціонування.

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

7.4.2 Специфікація варіантності вимог

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

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

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

Приклад. На рис. 7.1 подано об'єкт "Банківський рахунок" для деякої банківської системи. Система ідентифікації рахунків банку в кожній країні має свої особливості - в Японії вона відрізняється від прийнятої в Швейцарії, в Польщі - свої особливості тощо.

Точка в прямокутнику класу - змінність його атрибутів або операцій тощо.

Точкою варіантності V 1 на рисунку позначено прийняту для даної прикладної системи стратегію перевірки правильності вказаного ідентифікатора розрахункового рахунка, варіант якої залежить від того, в якій країні використовується система. Об'єкт "Банківський рахунок" має дві точки варіантності - V1 і V2, друга з яких позначає ту обставину, що прийнята стратегія поведінки банку підлягає змінам, якщо клієнт, вичерпавши свій кредит, намагається зняти гроші з рахунка.

Рисунок 7.1 - Подання варіантів на елементах моделей

Для певних видів змінності широко застосовуються так звані патерни як штампи забезпечення локальності змін (див. підрозділ 7.3). Нагадаємо, що терміном “патерн” позначаються стандартні об'єктно-орієнтовані рішення для стандартних проблем, описані стандартним способом. Патерни фіксують переважно перевірені часом штампи взаємодії об'єктів. Відзначимо низку таких штампів із числа наведених у джерелі [5], які корисні для деталізації сценаріїв у побудові ПВК:

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

Рисунок 7.2 - Варіантність інтерфейсів

- варіантність використовуваних баз даних можна подати за допомогою патерну, названого мостом, за яким абстракція об'єкта (узагальнення доступу до баз даних) відокремлюється від своєї реалізації (звернення до конкретної СУБД);

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

Рисунок 7.3 - Варіантність функцій

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

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

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

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

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

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

Одна система компонент може мати кілька фасадів - якість фасаду визначає успіх ревикористання. Фасад має бути стабільним, а те, що в нього не ввійшло, може змінюватися (наприклад, використання конкретного сервера СУБД). Приклад фасаду подано на рис. 7.4 в нотації UML.

Рисунок 7.4 - Приклад фасаду

7.4.3 Конкретизація варіантності вимог

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

Будемо називати вирішенням варіантної точки ПВК механізм визначення конкретного варіанта використання ПВК та її адаптації до такого використання.

Можна навести типові механізми вирішення варіантної точки ПВК, тобто її адаптації або настроювання.

Механізм успадкування (inheritance). Окремі властивості поведінки суперкласу конкретизуються в підкласі. Точний зміст цього процесу значною мірою визначається конкретною об'єктно-орієнтованою мовою програмування. На рівні стадії аналізу вимог вирішення варіантності шляхом наслідування позначається на моделі сценаріїв відношеннями "розширює" та "використовує".

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

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

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

Механізм конфігурації. Механізм конфігурації застосовується тоді, коли точка варіантності позначає можливий вибір із сукупності передбачених наперед взаємозамінних компонент (у тому числі на рівні сценаріїв). Приклад вирішення варіантності шляхом конфігурації наведено на рис. 7.1, де показано об'єкт "Банківський рахунок" з двома варіантними точками, для кожної з яких передбачено вибір однієї з передбачених альтернативних можливостей, що зумовлено конкретними обставинами використання об'єкта.

Механізм конфігурації, як і успадкування, безпосередньо використовується у ПВК, що належать до категорії каркасів (див. п. 7.3.8.)

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

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

Серед них відзначимо такі:

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

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

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

г) параметром є неявна умова прийняття рішення або умова обмеження, тлумачення якої визначається станом бази знань. Настроюван-ня вимагає виведення явної умови на підставі бази знань і наступної підстановки як у випадку 3;

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

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

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

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

к) параметром є специфікація інтерфейсу. Настроювання здійснюється шляхом використання інструментальних засобів конструюван ня інтерфейсу;

л) параметрами є показники середовища виконання. Настроювання здійснюється шляхом виконання серверів інсталяції;

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

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

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

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

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

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

Рисунок 7.5 - Випадок використання системи компонент

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

Рисунок 7.6 - Варіанти конфігурації

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

Рисунок 7.7 ілюструє цю тезу. Видима частина - незаштрихована, біла.

Рисунок 7.7 – Варіанти конфігурацій

Приклад. Новий банківський консорціум, використовуючи можливості Internet, організовує "банк вдома" - тобто електронний банк, який обслуговує фінансування маркетингу, умови котрого швидко змінюються, тому реалізується не монолітна структура, а система як композиція компонент, що допускають адаптацію. Можлива розподілена архітектура клієнт-сервер або система рівноправних компонент. Клієнтські компоненти працюють на персональних машинах або через Internet. Малі оплати можуть здійснюватися через Internet. "Банки вдома" мають спілкуватися з іншими фінансовими об'єктами, можливо, програмне забезпечення для "банку вдома" може мати спільні ПВК з кредитними, страховими, телефонними та іншими компаніями.

Понятійна база для цього домену включає цілу низку понять, що відображають типово банківські операції ("зареєструвати", "вкласти", "зняти з рахунку", "перевести на інший рахунок") та об'єкти, з якими вони оперують (позичка, кредит, акції, вклад, закладна, накладна, страховка, вексель, портфель цінних паперів, гроші готівкою, електронні гроші, чек, відсотки тощо). Тоді рис. 7.7 може бути ілюстрацією до цього прикладу, якщо вважати:

- VI позначає елемент конфігурації, який здійснює блокування видачі, якщо рахунок вичерпано;

- V2 позначає елемент конфігурації, який здійснює підвищення відсоткової ставки, якщо кредит перевищує залишки рахунка;

- V3 позначає елемент конфігурації, який здійснює застосування гнучкої стратегії кредитування з урахуванням ризику;

- С1 позначає елемент конфігурації, який здійснює ідентифікацію рахунка клієнта;

- ТВ1 є варіантною точкою, яка визначає середовище клієнтських компонент;

- ТВ2 є варіантною точкою, яка визначає поведінку банку, якщо замовлена виплата перевищує залишки на рахунку;

- ТВЗ є варіантною точкою для ідентифікації особистого рахунка клієнта;

- С2 є модуль контролю ризику.

Незаштрихована частина рисунка відповідає видимій інформації.

7.4.4 Проектування ПВК

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

Домовимося, що суперпозиція акторів і сценаріїв складових суперсистеми є першим наближенням акторів та сценаріїв власне суперсистеми (рис. 7.8).

Рисунок 7.8 - Використання суперсистеми

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

Рисунок 7.9 - Приклад розташування сценаріїв у суперсистемі

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

У процесі побудови моделі проекту суперсистеми визначаються й уточнюються такі аспекти:

 взаємодія прикладних систем, охоплених суперсистемою;

 класи ПВК-проектування, типи підсистем, утворені з них системи компонент;

 фасади систем компонент та ті їхні властивості, які імпортуються за допомогою фасадів;

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

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

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

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

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

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

Прикладом може бути база даних великого обсягу, зібрана за допомогою застарілої СУБД, дані якої все ще потрібні.

Суперсистема, яка використовується як узагальнення спектра завдань домену, має враховувати і ті завдання, які поданоуспадкованими системами.

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

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

Рисунок 7.10 - Приклад використання успадкованої системи