5.1.2. Об'єкт но-орієнтоване програмування

Розглянемо аспекти об'єктно-орієнтованого програмування систем, а саме, операції над об'єктами та процеси ЖЦ для побудови прикладних об'єктно-орієнтованих ПС [4, 5].

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

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

Операції над об'єктами. Це такі операції:

- введення, збереження, видалення об'єктів тощо, тобто операції життєвого циклу об'єктів;

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

Інтерфейс називається вхідним, якщо об'єкт за його допомогою одержує пев­ний сервіс, і вихідним, якщо об'єкт через нього надає цей сервіс.

Кожна операція має ім'я, список вхідних параметрів і вихідних результатів, якщо вони є.

Загальна форма опису операції має вигляд

Operation_name (param₁, ..., param_n)

returns (res₁, ..., res_m)

param_i ::= parameter_name : parameter_type

res_i ::= result_name : result_type

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

w: (x₁:s₁, x₂:s₂, ..., x_n:s_n ) -> (у₁:r₁, y₂:r₂, …, y_m:r_m)

де w - ім'я операції;

x₁, x₂, ..., x_n - вхідні параметри, a x₁ - керуючий оператор;

s₁, s₂, ..., s_n - типи вхідних параметрів;

у₁, у₂, ..., у_m - вихідні параметри;

r₁, r₂, ..., r_m - типи вихідних параметрів.

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

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

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

Об'єктно-орієнтована модель програмної системи створюється на таких ета­пах ЖЦ (рис. 5.3):

Рис. 5.3. ЖЦ розробки моделі системи у середовищі ООП

Етапам відповідають такі процеси:

- аналіз - створення ОМ ПрО, у якій об'єкти відбивають її реальні сутності і операції над ними;

- проектування - уточнення ОМ з урахуванням опису вимог для реалізації конкретних задач системи;

- програмування - реалізація ОМ засобами мов програмування С++, Java та ін.

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

- модифікація ПС в процесі її супроводження шляхом додавання нових фун­кціональних можливостей, інтерфейсів і операцій.

Наведені процеси можуть виконуватися ітераційно один за.одним і з повер­ненням до попереднього процесу. На кожному процесі може застосовуватися та та сама система нотацій.

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

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

Існує два типи моделей системної архітектури:

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

- динамічна модель для опису динамічної структури системи і взаємодії між об’єктами (але не класами об'єктів) під час роботи системи.

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

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

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

5.1.3. UML - метод моделювання

Загальна характеристика UML (Unified Modeling Language), як підхід до проектування різних систем, була дана у п. 4.2.1. Тут UML розглядається детальніше, як мова візуального моделювання систем, шляхом подання у вигляді діаграм їхніх статичних і динамічних моделей на всіх процесах ЖЦ [6, 7].

В основу методу покладено парадигму об'єктного підходу, при якій концеп­туальне моделювання проблеми полягає у побудові:

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

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

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

Проектування в UML починається з побудови сукупності діаграм, які візуалізують основні елементи структури системи.

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

Діаграма класів (Class diagram) відображає онтологію домену, за змістом еквівалентна структурі інформаційної моделі методу С. Шлеєра і С. Мелора, визначає склад класів об'єктів і їх зв'язків. Діаграма задасться зображенням, на якому класи позначаються поділеними на три часті прямокутниками, а зв'язки — лініями, що з'єднують прямокутники. Це відповідає візуальному зображенню понять і зв'язків між ними. Верхня частина прямокутника — обов'язкова, в ній записується ім'я класу. Друга і третя частини прямокутника визначають відповідно список операцій і атрибутів класу, що можуть мати такі специфікатори доступу:

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

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

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

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

Класи можна перебудувати в наступних відношеннях або зв'язках.

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

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

Екземпляризація - залежність між параметризованим абстрактним класом-шаблоном (template) і реальним класом, який ініціює параметри шаблону (наприклад, контейнерні класи мови C++).

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

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

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

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

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

Діаграма реалізації — це діаграма компонентів і розміщення. Діаграма компонентів слугує відображенню структури системи як композиції компонентів і зв'язків між ними.

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

Побудова ПС методом UML здійснюється у наступні етапи ЖЦ (рис 5. 4.).

Рис.5.4. Схема моделювання і проектування ПС в UML

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

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

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