2.1.Еволюція методологій розробки пз

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

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

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

2.2.Система як набір функціональних вимог

Як правило, будь-яка програмна система складається з декількох частин: основній (наочно-орієнтованою) і системній частині, які несуть в собі необхідну функціональність. Наприклад, ядро системи обробки кредитних карт призначене для роботи з платежами, тоді як функціональність системного рівня призначена для ведення журналу подій, цілісності транзакцій, авторизації, безпеки, продуктивності і т.д. Більшість подібних частин системи, відомі як крізна функціональність [2], зачіпають безліч основних наочно-орієнтованих модулів. Можна розглядати складну програмну систему як комбінацію модулів, кожен з яких включає окрім бизнес-логики частина крізної функціональності з набору вимог до системи. Малюнок 1 показує систему як набір таких вимог розбитих на різні модулі.

Малюнок 1. Система як набір функціональних модулів.

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

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

Малюнок 2. Декомпозиція вимог: виділення функціональності.

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

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

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

public class SomeBusinessClass {

// Бізнес-дані

// допоміжні дані

 public void performSomeOperation(OperationInformation info){

// перевірити рівень доступу даним

// перевірити відповідність вхідних даних контракту

// заборонити доступ даним іншим потокам виконання

// перевірити стан кеша даних

// занести в журнал відмітку про початок операції

// ==== Реалізація логіки даного класу ====

 // занести в журнал відмітку про кінець операції

 // вирішити доступ даним іншим потокам виконання

     }

}

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

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

Малюнок 3.

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

Малюнок 4.