світ складають об’єкти, які взаємодіють між собою;

 кожний об’єкт має певний набір властивостей або атрибутів (аналог суттєвих ознак поняття);

 атрибут визначається своїм іменем та значеннями, які він може приймати;

 об’єкти можуть бути у відношеннях одне з одним;

 значення атрибутів та відношення можуть із часом змінюватись;

 сукупність значень атрибутів конкретного об’єкта в певний момент часу визначає його стан;

 сукупність станів об’єктів визначає стан світу;

 світ та його об’єкти можуть перебувати в різних станах;

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

 події можуть спричиняти інші події або зміни станів;

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

 дії, які можуть виконувати об’єкти, називають операціями об’єктів (як синоніми використовують також терміни методи об’єкта та функції об’єкта);

 можливі сукупності дій об’єкта називають його поведінкою;

 об’єкти взаємодіють шляхом обміну повідомленнями;

 об’єкти можуть складатися із частин.

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

 користувача позбавлено необхідності знати зайве, тобто непотрібне;

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

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

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

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

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

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

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

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

За парадигмою об’єктно-орієнтованого підходу концептуальне моделювання проблеми (дивись п. 3.2) відбувається в термінах взаємодії об’єктів:

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

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

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

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

Метод С. Шлеєр та С. Меллора (див. п. 3.2.2) ми обрали переважно тому, що читач може з вітчизняної публікації [2] отримати досить повне уявлення про його можливості, які є, певною мірою, типовими.

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

Метод UML (Unified Modelling Language) є узагальненням цих двох методів та кількох інших і тепер претендує на те, щоб стати міжнародним стандартом методу аналізу вимог та проектування програмних систем.