2.3.Наскрізна функціональність в системі
Не дивлячись на те, що крізна функціональність може пронизувати велику кількість модулів, існуючі технології мають тенденцію реалізувати ці вимоги, використовуючи одновимірні підходи, направляючи всі зусилля по реалізації вимог уздовж одного вимірювання. Це єдине вимірювання якраз є реалізацією вимог що відносяться до модулів. Вимоги, що залишилися, лягають уздовж цього головного вимірювання. Іншими словами, весь простір вимог є n-мірним, тоді як простір реалізації представляється одновимірним простором. В результаті отримуємо важко підтримуване відображення вимог в реалізацію.
Ознаки.
Декілька ознак, які можуть указувати на проблемну реалізацію крізної функціональності при використанні існуючих підходів. Розіб'ємо ці ознаки на дві категорії:
Заплутаний код: У модулі може бути реалізовані декілька вимог. Наприклад, часто розробники одночасно вирішують проблеми пов'язані з бізнес логікою, продуктивністю, синхронізацією потоків і безпекою. В результаті безліч елементів з різних вимог присутня в модулі, що розробляється, що приводить до заплутаного коду.
Розосереджений код: Оскільки крізна функціональність за визначенням розповсюджується на безліч модулів, то виклики цієї функціональності будуть розосереджені по всій системі. Наприклад, якщо в системі використовується вимога по стеженню за продуктивністю роботи бази даних, то така крізна функціональність торкнеться всіх модулів, що працюють з базою даних.
Наслідки.
Наявність заплутаного і розосередженого коду впливають на проектування і реалізацію у багатьох відношеннях:
Погане дослідження призначення модуля: Одночасна реалізація декількох вимог в одній модульній одиниці робить неясною відповідність між окремою вимогою і його реалізацією, в результаті скрутного зрозуміти, що реалізує конкретний модуль.
Непридатність коду для повторного використання: У зв'язку з тим, що модуль може використовувати в собі деяку крізну функціональність з жорсткою прив'язкою до цієї функціональності, інші частини системи або інші проекти, де може потрібно вже написаний модуль (але з іншими вимогами до крізної функціональності) не можуть використовувати вже написаний модуль.
Велика вірогідність помилок: Заплутаність коду спричиняє за собою код з безліччю прихованих проблем. Більш того, реалізація декількох ортогональних вимог в одному модулі може привести до того що жодне з них не отримає достатньої уваги розробника.
Складність в супроводі: Поява додаткових вимог в майбутньому зажадає переробки поточної реалізації, і це може торкнутися більшості існуючих модулів. Модифікація кожної окремої підсистеми окремо під нові вимоги може привести до несумісності.
З тих пір, як складність програмних систем зросла і з'явилася крізна функціональність, що знаходиться на зрізі системи, не дивно, що з'явилися декілька підходів для вирішення цих проблем. Ці підходи включають класи-домішки (mix-in) [20], шаблони проектування [6] і специфічні доменні рішення.
При використанні класів-домішок реалізацію крізної функціональності можна помістити в них. Компоненти містять екземпляр класу mix-In і дозволяють іншим частинам системи встановлювати свій екземпляр.
Поведінкові шаблони проектування, такі як Visitor або Template Method дозволяють помістити крізну функціональність в головні класи, які як у разі mix-In класів обходитимуть компоненти, при цьому викликаючи логіку специфічну для відвідин даного компоненту або викликаючи специфічний шаблонний метод.
Специфічні доменні рішення, такі як, наприклад, каркаси (framework) і сервера застосувань, дозволяють розробникам виносити деякі крізні вимоги на рівень цих рішень. Наприклад, архітектура EJB дозволяє винести на рівень сервера застосування крізну функціональність наступного вигляду — безпека, адміністрування, аналіз продуктивності і управління поведінкою перманентних об'єктів, і сфокусуватися тільки на розробці компонентів рівня підприємства. Специфічні доменні рішення пропонують спеціалізований механізм для вирішення специфічних проблем, проте при зміні технології доводиться наново вивчати нові підходи для вирішення тих же проблем.
Перед системним архітектором при проектуванні системи виникає дилема по вибору технології при реалізації крізних вимог — або скористатися одним з рішень конкретної проблеми, що існують на даний момент, або скористатися новою технологією покликаною вирішувати подібні проблеми.