45. Мова uml. Призначення діаграм моделювання

UML (англ. Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення.

Діаграми підвищують супроводжуваність проекту і полегшують розробку документації

Діаграма варіантів використання. Діаграма варіантів використання є вихідним концептуальним уявленням або концептуальною моделлю системи в процесі її проектування і розробки. Головне призначення діаграми варіантів використання полягає у формалізації функціональних вимог до системи за допомогою понять відповідного пакету і можливості узгодження отриманої моделі із замовником на ранній стадії проектування. Будь-який з варіантів використання може бути підданий подальшій декомпозиції на безліч підваріантів використання окремих елементів, які утворюють вихідну сутність. Рекомендована загальна кількість акторів у моделі - не більше 20, а варіантів використання - не більше 50. В іншому випадку модель втрачає свою наочність і, можливо, замінює собою одну з деяких інших діаграм.

Дiаграма класiв – діаграма, що демонструє класи системи, їх атрибути, методи і взаємозв'язку між ними

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

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

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

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

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

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

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

46. Діаграма варіантів використання (use case diagram)

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

Розробка діаграми варіантів використання переслідує мети:

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

• Сформулювати загальні вимоги до функціонального поведінки проектованої системи.

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

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

Основні компоненти :

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

- Окремий сервіс який надається майбутньою системою на запис актора

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

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

47. Діагра́ма кла́сів — статичне представлення структури моделі. Відображає статичні елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм. Діаграма класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини.

Клас визначає атрибути і методи набору об’єктів. Всі об’єкти цього класу (екземпляри цього класу) мають спільну поведінку і однаковий набір атрибутів (кожен з об’єктів має свій власний набір значень). Іноді замість назви «клас» використовують назву “тип”, але, слід зауважити, що ці назви описують різні речі: тип є загальнішим визначенням.

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

Атрибути можуть бути такими, типи значень яких вважаються наперед визначеними в UML, як-от: розмір, площа, кут, видимість. Останній атрибут може мати такі значення:

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

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

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

Воднораз користувач може визначати специфічні для нього атрибути.

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

48. Відносини на діаграмі варіантів використання

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

В UML є декілька стандартних видів відносин між акторами і варіантами використання:

• Залежність (Dependency) – це семантичне відношення між двома сутностями, при якому зміна однієї з них, незалежної, може вплинути на семантику іншого, залежною.

• Асоціація (Association) – структурний ставлення, що описує сукупність смислових або логічних зв'язків між об'єктами.

• Узагальнення (Generalization) – це відношення, при якому об'єкт спеціалізованого елемента (нащадок) може бути підставлений замість об'єкта узагальненого елемента (предка). При цьому, відповідно до принципів об'єктно-орієнтованого програмування, нащадок (child) успадковує структуру і поведінку свого предка (parent).

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

• між інтерфейсами і реалізують їх класами чи компонентами;

• між прецедентами і реалізують їх кооперації.

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

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

Стан на діаграмі зображується прямокутником із закругленими вершинами. Прямокутник може бути розділений на дві секції горизонтальною лінією. Якщо вказана лише одна секція, то в ній записується тільки ім'я стану. За наявності двох секцій, в першій з них записується ім'я стану, а у другий список деяких внутрішніх дій або переходів в даному стані. Під дією в мові UML розуміють деяку атомарну операцію, виконання якої призводить до зміни стану або поверненню деякого значення (наприклад, «істина» або «брехня»).

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

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

<Мітка-дії '/' вираз-дії>

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

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

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

Вихід - ця мітка вказує на дію, специфіковану наступним за нею виразом дії, яке виконується в момент виходу з даного стану (вихідна дія);

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

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

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

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

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

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