diagrammy

UML
UML - це стандарт, який підтримується групою по об’єктному програмуванню OMG (це громадська організація, яка була заснована 11 провідними компаніями по розробці ПЗ «з метою створення ринку компонентного ПЗ шляхом прискорення ведення стандартних об’єктних рішень»).
Стандарт UML постійно переглядається та вдосконалюється
Переваги використання UML:
Діаграми однозначні та добре задокументовані
Зберігається інтелектуальна власність архітектури системи.
Новим співробітникам простіше приєднуватися до проекту.
Види діаграм:
Діаграма варіантів використання USE case d-m
Діаграма класів Class d-m
Діаграма поведінки Behavior d-m
Діаграма станів Statechart d-m
Діаграма діяльності Activity d-m
Діаграма взаємодії Interaction d-m
а) Діаграма послідовності Sequnce d-m
б) Діаграма кооперації Collaboration d-m
4) Діаграма реалізації Implementation d-m
4.1. Діаграма компонентів Component d-m
4.2. Діаграма розгортування Deployment d-m

У середині 90-х років були визначені наступні методи для розв’язання різних класів задач ООАПроектування:
Метод Буча Booch.
Метод Джеймса-Румбау ОМТ (Object Modeling Technique).
Метод Айвора Джекобса OOSE(Object Oriented Software Enginering).
З 1994 року починається створення єдиного стандарту і зявляється уніфікований метод, а потім UML.

Правила роботи з об’єктами UML
Явно вказується у тексті екземпляр деякого класу.
Використовуються лише ті значення слова, які написані у імені відповідно конструкції UML.
Існує 3 допустимі префікси.
Посилання на конструкцію UML записується звичайним шрифтом.
Імена класів це іменник і можливо прикметник; ім’я записується одним словом, кожна частина записується з великої літери.
Ім’я асоціації записується аналогічно до імені класів.
Ім’я інших елементів записується одним словом але починається з малої літери.
Імена атрибутів, які приймають логічні значення з префіксом is.
Перераховані типи закінчуються словом kind.
Посилання на класи, асоціації, атрибути завжди використовують точні імена, які вказані у моделі.
Імена стандартних позначень заключаються у рядки і починаються з маленької літери.
Графічні конструкції UML:
Значки або піктограми – графічні фігури фіксованого розміру і форми.
Графічні символи на площині – певні геометричні фігури різної висоти та ширини.
Шляхи – послідовність відрізків які поєднують певні графічні символи.
Рядки тексту – для представлення інформації в певній граматичній формі.





Діаграма варіантів використання (USE case diagram)
Мета розробки:
Визначити загальні межі та контекст предметної області, яка моделюється на початкових етапах проектуванні системи.
Сформувати загальні вимоги до функціонування поведінки ПС.
Розробити початкову концептуальну модель системи для подальшої її деталізації у формі логічних та фізичних моделей.
Підготувати початкову документацію для взаємодії розробників з замовниками та користувачами.
Система представляється у вигляді множини акторів, які взаємодіють з системою за допомогою варіантів використання.
Варіант використання – це послідовність дій, які повинні бути виконані системою при взаємодії з відповідним актором.
Позначається:



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





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




Інтерфейс з’єднується за допомогою:

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

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

Для включення в модель текстової інформації використовують примітки.
Позначається:



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





1: це кратність асоціації, вона вказує кількість екземплярів даного компоненту, які можуть приймати участь у асоціації.
Розширення – визначає зв'язок екземплярів одного варіантів використання з більш загальним.
“extend” Стрілка направлена до більш загального варіанту використання.

Узагальнення – вказує що варіант використання А може бути узагальненим до варіанту використання В; А – є спеціалізацією або нащадком, В- пращур.
А В

Включення – вказує що деяка поведінка варіанту використання являється складовою поведінки іншого варіанту використання.

“include” Стрілка направлена від базового елементу до менш загального.

Приклад:

















Діаграма класів (Class diagram)
Потрібна для представлення статичної структури моделі системи.
Клас – це множина об’єктів, які мають однакову структуру, поведінку та відношення з об’єктами з інших класів.
Позначається:





Обов’язковим являється Ім’я Класу; воно повинно бути унікальним, записується з великої літери та напівжирним шрифтом.
Клас називається абстрактним якщо не містить об’єктів; тоді його ім’я записується курсивом.
Кожному атрибути відповідає рядок тексту:
Квантор видимості_ІмяАтрибуту[кратність] : Тип=Початкове значення{рядок-властивість}
Квантор видимості приймає одне з 3 значень:
Символ + - загальнодоступний (Public) – атрибут доступний з будь-якого класу.
Символ # - захищений (Protected) – атрибут доступний лише підкласам даного класу.
Символ - закритий (Private) – атрибут недоступний жодному іншому класу.

Ім’я атрибута – являється обов’язковим.
Кратність – загальна кількість атрибутів даного типу що входять у склад даного класу. Якщо рядок атрибута підкреслений – це означає що атрибут приймає лише деяку множину значень, які вказані у рядку властивості.
Операція – це деякий сервіс, який надає екземпляр класу за певною вимогою.
Кожній операції відповідає рядок тексту:
Квантор видимості_ІмяОперації [список параметрів] : Вираз {рядок-властивість}
Рядок-властивість потрібна для визначення значень властивостей, які можуть бути застосовані до даного елемента.
Деякі операції можуть виконуватися одночасно, а деякі лише послідовно, для цього у рядку-властивості вказується:
concurrency = ім'я
sequential
concurrent
guarded.
Ім'я приймає одне з 3 значень:
Послідовна
Паралельна
Захищена – всі звершення до даної операції повинні бути впорядковані у часі.
Відношення на діаграмі класів:
1. Залежності стрілка направлена до класу джерела. Визначені спеціальні види залежності, задаються стереотипами:
а)“access –доступність відкритих атрибутів та операцій класу-джерела та класу-клієнтів;
б) “bind” - клас-клієнт може використовувати деякий шаблон;
в) “derive”–атрибути класу-клієнта можуть бути обчислені за атрибутами класу-джерела;
г) “import” – відкриті атрибути та операції класу-джерела являється частиною класу-клієнта, неначе вони об’явлені безпосередньо у ньому;
д) “refine” - клас-клієнт являється уточненням класу-джерела.
2. Асоціації:
а) бінарна


б) тернарна


в) що виключає

3. Агрегації – клас включає в себе як складові інші класи.
Позначається:

4. Композиції – являється частинами випадку відношенням агрегації при якій складові знаходяться в середині цілого.
Позначається:

5. Узагальнення направлена до класу джерела. Для відношення узагальнення визначені наступні відношення:
а) { complete } - для даного відношення визначені всі класи нащадків;
б) { disjoint } – класи нащадків не можуть містити об’єктів які одночасно являються екземплярами двох або більше класів;
в) { incomplete } – на діаграмі вказані не всі класи нащадків;
г) { overlapping } – екземпляри класів нащадків можуть належати одночасно декільком класам.
Інтерфейс позначається:
або



Шаблон або параметризований клас:








Приклади:




Діаграма станів (Statechart diagram)
Мета розробки: описати можливі послідовності станів та переходів, які у сукупності характеризують поведінку елемента моделі протягом його життєвого циклу.
Автомат – це деякий формалізм для моделювання елементів моделі та системи в цілому. Кожна діаграма станів це деякий автомат.
Обов’язкові умови автомату:
Незапам’ятовується історія переміщення з одного стану в інший.
Кожний момент часу автомат може знаходитися лише в одному із станів.
Час явно не входить в формалізм автомату.
Кількість станів кінцева.
Не міститься ізольованих станів та переходів.
Не міститься переходів з одного стану у два або більшу.
Стан – це деякий клас для моделювання ситуації протягом якої виконується деяка умова.
Позначається:




Ім'я записується з великої літери, зазвичай це дієслово з дієприкметником. В кожній дії ставиться для відповідності рядок тексту:
мітка/вираз дії;
Мітка вказує на умову при якій буде виконуватися дія. Зарезервовані мітки:
1) entry – дія виконується в момент входу у даний стан;
2) exit – момент виходу;
3) do – діяльність, яка виконується протягом усього часу доки об’єкт знаходиться у даному стані.
4) include – звернення до підавтомату, замість дії вказується назва діаграми станів.

Перехід між станами

Початковий стан

Кінцевий стан
Складний стан з прихованою внутрішньою структурою:
Складний стан з паралельними підстанами:







Складний стан з вкладеними послідовними підстанами:





Недавній історичний стан:

·Давній історичний стан:
Синхронізований стан:

В складних станах використовують наступні переходи:



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












Діаграма діяльності (Activity diagram)
Мета розробки: моделювання процесу виконання операції, являються частинним випадком діаграми станів.
Діяльність – це сукупність обчислень, що виконуються автоматом.
На діаграмі відображається послідовність переходу від одної діяльності до іншої, при цьому звертається увага на результат діяльності.
Позначається:
або
Перехід між діями

Початковий стан

Кінцевий стан

Якщо діяльність це складна дія, то позначається

Кожна діаграма діяльності має один початковий і один кінцевий стан

Для розподілу та злиття паралельних потоків керування використовують
[ Cкачайте файл, чтобы посмотреть картинку ]
Доріжки використовуються для моделювання бізнес-процесів, тобто для асоціювання дій з конкретними підрозділами компаній.
У загальному випадку дії на діаграмі виконуються над деякими об’єктами, об’єкти або ініціюють виконання дій або визначають деякий результат цих дій.

Об’єкти з’єднуються з діями за допомогою відношення залежності
Приклади:
[ Cкачайте файл, чтобы посмотреть картинку ] [ Cкачайте файл, чтобы посмотреть картинку ]

[ Cкачайте файл, чтобы посмотреть картинку ]




Діаграма послідовності (Sequence diagram)
Мета розробки: моделювання синхронних процесів у часі, які описують взаємодію об’єктів. На діаграмі зображуються лише ті об’єкти, які безпосередньо беруть участь у взаємодії.
Крайнім з ліва зображається об’єкт який являється ініціатором взаємодії, з права від нього об’єкт з яким він взаємодіє.
[ Cкачайте файл, чтобы посмотреть картинку ]
[ Cкачайте файл, чтобы посмотреть картинку ][ Cкачайте файл, чтобы посмотреть картинку ]
Лінія життя потрібна для позначення періоду часу протягом якого об’єкт існує в системі і може приймати участь у взаємодії.
Фокус керування показує, що в даний період часу об’єкт являється активним. Деякі об’єкти руйнуються для того, щоб звільнити ресурси які вони займають.
Різновиди повідомлень:
Виклик процедур, виконання операцій, позначення вкладених потоків керування.
Простий, не вкладений потік керування, являється асинхронним, тобто може виникати у довільні моменти часу.
Асинхронне повідомлення у деякій процедурній послідовності.
Повернення з виклику процедури.
Стереотипи повідомлень (зарезервовані слова, які пишуться над стрілками)
"call" – виклик операції або процедури.
"return" – повернення значення виконаної операції або процедури.
"create" – створення іншого об’єкту для виконання певних дій.
"destroy" – знищення об’єкту.
"send" – передача деякого сигналу.
Приклад:
[ Cкачайте файл, чтобы посмотреть картинку ]
















Діаграма кооперації (Collaboration diagram)
Мета розробки: призначена для визначення структурних аспектів взаємодії об’єктів. Послідовність дій та паралельних потоків визначається порядковими номерами.
Кооперація – це множина об’єктів, потрібна щоб визначити взаємодію ті особливості реалізації.
Кожна може бути представлена на 2 рівнях:
На рівні специфікації – вказуються ролі та класи.



На рівні прикладів – вказуються об’єкти та зв’язки.
звязок


Повний формат запису імені об’єкту:
Ім’я / Роль: Клас
Можливі варіанти запису рядка тексту у прямокутнику об’єкту:
: С анонімний об'єкт, що утворюється на основі класу С.
/ R анонімний об'єкт, що грає роль R.
/ R : С анонімний об'єкт, що утворюється на основі класу С і що грає роль R.
О / R об'єкт з ім'ям О, що грає роль R.
О : С об'єкт з ім'ям О, утворюваний на основі класу С.
О / R : С об'єкт з ім'ям О, утворюваний на основі класу С і що грає роль R.
О об'єкт з ім'ям О.
О : "об'єкт-сирота" з ім'ям О.
/ R роль з ім'ям R.
: С анонімна роль на базі класу С.
/ R : С роль з ім'ям R на основі класу С.
Мультиоб’єкт – це множина об’єктів, якій адресовані операції та символи.









Активний об’єкт – є ініціатором взаємодії.

Стереотипи зв’язків:
"association" асоціація (передбачається за умовчанням, можна не указувати).
"parameter" параметр методу. Відповідний об'єкт може бути тільки параметром деякого методу.
"local" локальна змінна методу. Її область видимості обмежена тільки сусіднім об'єктом.
"global" глобальна змінна. Її область видимості розповсюджується на всю діаграму кооперації.
"self" зв'язок рефлексії об'єкту з самим собою, яка допускає передачу об'єктом повідомлення самому собі.

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

Приклад:
[ Cкачайте файл, чтобы посмотреть картинку ]


Діаграма компонентів (Component diagram)
Мета розробки:
Візуалізація заг. Структури коду ПС.
Визначення виконуваного варіанту ПС.
Забезпечення багаторазового використання окремих фрагментів програмного коду.
Представлення концептуальної та фізичної схеми БД.
Компонент – використовується для представлення фізичних сутностей. Він реалізує деякий набір інтерфейсів і слугує для загального позначення елементів фізичного представлення моделі.

Є 3 види компонентів:
Розсортування – забезпечують безпосереднє виконання системою своїх функцій (DLL).
Робочі продукти – файли з текстами програм.
Виконання – виконувані модулі (ехе-шники).
Інший спосіб специфікації різних видів компонентів явна вказівка стереотипу компоненту перед його ім'ям. У мові UML для компонентів
визначені наступні стереотипи:
Бібліотека (library) визначає перший різновид компоненту, який представляється у формі динамічної або статичної бібліотеки.
Таблиця (table) також визначає перший різновид компоненту, який представляється у формі таблиці бази даних.
Файл (file) визначає другий різновид компоненту, який представляється у вигляді файлів з початковими текстами програм.
Документ (document) визначає другий різновид компоненту . який представляється у формі документа.
Здійснимий (executable) визначає третій вид компоненту, який може виконуватися у вузлі.


Інтерфейс позначається:





Інтерфейси з’єднуються:
відношення реалізації
відношення залежності.

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











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


Діаграма розгортування (Deployment diagram)
Мета розробки:
Визначити розподіл компонентів системи за їх фізичними вузлами.
Показати фізичні зв’язки між всіма вузлами реалізації системи на етапі її виконання.
Виявити вузькі місця системи та реконструювати її для досягнення необхідної продуктивності.
Вузол – це деякий елемент системи, який існує фізично та має деякий обчислювальний ресурс.
Позначається:





вузол рівня-типу вузол рівня-екземпляру
Якщо необхідно вказати компоненти на окремому вузлі, то це можна зробити 2 способами:

Вкладеними компонентами можуть бути тільки
виконувані




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










13PAGE 15


13PAGE 141315




Перелік
дій

Ім’я Актора

Ім’я Інтерфейсу

інф.

Ім’я Актора

інф.

1:

*

Ім’я Класу

Ім’я Класу

Атрибути

Ім’я Класу

Атрибути

Операції

ціле

частина

ціле

частина

Ім'я Об’єкту

Ім'я Об’єкту: Ім'я Класу

“interface”
Ім'я


Операції

Ім’я

Атрибути

Операції

Параметри

Ім'я Стану

Ім'я Стану

Список внут.
дій

Ім'я Стану

Ім'я Стану

Ім'я Стану

цифра

цифра

Підняти тел. трубку

№3 генерувати тон/сигнал

Набрати тел. номер

№3/ номер додати (N)

Вираз

Проста дія

[усл.1]

[усл.2]

дія

Ім’я Об’єкту

[характер]

Копер.

Клас

Ім’я

Мультиоб’єкт

Об’єкт

Об’єкт

{active}
Ім’я

Ім’я
{власт.}

“interface”
Ім’я

IName

Реалізує додаткову інформацію
Клас1
Клас2

Ім’я компоненту
{власт.}

Ім’я
{власт.}

Клас1

Клас2

: Ім’я
{власт.}

Ім’я
{власт.}

Ім’я


Ім’я

Комп.1
Комп.2







Use case d-mщо виключаєприклад Окно програмиприклад Геометрична фігура ` Ђ Ё
·
·°
·
·
·‚ °15

Приложенные файлы

  • doc 18241770
    Размер файла: 745 kB Загрузок: 0

Добавить комментарий