UML (Unified Modeling Language) – мова для візуалізації, специфікування, конструювання і документування артефактів програмних систем.

Артефакт – елемент інформації, що використовується або створюється в процесі розробки ПЗ.

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

Створені артефакти можуть модифікуватись, входити в класи, використовуватись як шаблони при проектуванні.

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

Візуалізація в UML грає першу роль як засіб порозуміння.

Специфікування означає побудову точних, однозначних і повних моделей.

UML дозволяє специфікувати всі головні рішення, які стосуються аналізу, проектування та реалізації, які обов’язкові в процесі розробки та впровадження системи ПЗ.

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

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

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

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

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

Моделі бувають:

• Матеріальні

• Нематеріальні

• Натуральні

(Застосовуються матеріали, які входять складовими в реальний проект)

• Штучні

(застосовуються матеріали - аналоги)

• Декоративні

(відображають лише частину властивостей та дають лише загальні характеристики)

• Математичні

(дослідження поведінки моделі шляхом застосування математичних методів)

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

Діаграма – графічне представлення деякої множини елементів.

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

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

Жодна окрема діаграма не є моделлю! (ууу, страшно?)

Діаграма – лише засіб візуалізації моделі; для найбільш повного представлення моделі необхідно використовувати велику кількість діаграм.

Цілі створення UML:

• Для моделювання системи в цілому, від концепції до фрагменту ПЗ;

• Для вирішення проблеми масштабованості для складових відповідальних систем;

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

Моделювання дозволяє вирішити наступні задачі:

• Візуалізувати роботу системи, або в поточному стані (як є), або в бажаному (як повинна бути).

• Визначити структуру або поведінку системи з точки зору заданих вимог, що відтворені в специфікаціях.

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

• Для обов’язкового порозуміння всіх учасників процесу створення ПЗ.

Основне призначення UML – служити засобом комунікації в команді розробників і при веденні переговорів з замовником.

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

Чотири види елементів нотації( аналоги синтаксису в мові програмування):

• фігури (пласкі; тривимірні)

• лінії (неперервні; пунктирні)

• значки (умовні позначки)

• надписи ( семантично зв’язані зі станом інших елементів)

В UML 1.5 визначені 12 типів діаграм:

• 4 типи для презентації статичної структури додатку

• 5 типів для пропису аспектів поведінки системи

• 3 типи для презентації фізичних об’єктів функціональної системи

Для побудови додатку визначають необхідну кількість діаграм. Головне – порозуміння між замовником та виконавцем.

Діаграма прецедентів:

Actor – сутність, з якою взаємодіє система в процесі своєї роботи. Може бути як людиною, так і зовнішньою системою. Можливе представлення актора як підсистеми модулів або класів; якщо актор – людина, то графічним зображенням його є «умовна людина».

Для відображення підсистеми, класу використовується графічний символ, який має ім’я та атрибути.

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

При з’єднанні прецедентів можна відтворити процес всього-всього. (всього-всього?!)

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

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

Цілі створення діаграм прецедентів:

• Визначення границі і контексту програмної області на перших етапах проектування

• Формування загальних вимог до поведінки системи

• Розробка концептуальної моделі системи

• Підготовка документації для взаємодії з замовником

Діаграма класів

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

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

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

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

Інформація з діаграм класу може бути віддзеркалена шляхом генерації в код.

На діаграмі класів відображається множина класів, інтерфейсів, кооперацій та відношень між ними.

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

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

Інтерфейс слугує засобом об’єднання об’єкта з іншими об’єктами.

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

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

Відношення – різні засоби взаємодії між класами.

• Відношення залежності (опис існуючих між класами відношень)

• Відношення узагальнення (відтворює зв'язок узагальнених класів з спеціалізованими)

• Відношення асоціації (відтворює структурні відношення між об’єктами)

Активний клас – клас, об’єкти якого приймають участь в одному або декількох процесах (threads) і можуть ініціювати управляючу дію.

Активний клас використовується на периферії з точки зору реалізації певного коду.