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

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

19. Діаграма прецедентiв. Вiдношення розширення.

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

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

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

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

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

Приклад: При обранні... extend(“Надати квитанцію”).

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

20. Діаграма станiв.

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

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

Переходи мають мітки, які синтаксично складаються з трьох необов'язкових частин (див. рис. 11.7):

Рис. 11.7. Діаграма станів об'єкта «замовлення»

<
Подія> <[Умова]> </ Дія>.

На діаграмах також відображаються функції, які виконуються об'єктом в певному стані. Синтаксис мітки діяльності:

виконати / <діяльність>.
^

21. Діаграма дiяльностi.

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

Основними елементами діаграм діяльності є (рис. 11.8):

Рис. 11.8. Діаграма діяльності - обробка замовлення

• 
  овали, що зображують дії об'єкта;
• 
  лінійки синхронізації, що вказують на необхідність завершити або почати кілька дій (модель логічного умови «І»);

• 
  ромби, що відображають прийняття рішень щодо вибору одного з маршрутів виконання процесу (модель логічного умови «АБО»);
• 
  стрілки - відображають послідовність дій, можуть мати мітки умов.

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

Будь-яка діяльність може бути піддана подальшій декомпозиції і представлена ​​у вигляді окремої діаграми діяльності або специфікації (словесного опису).
^

22. Діаграма компонентів. Компонент. Графічне зображення компонента. Види компонентів.

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

Діаграма компонентів розробляється для наступних цілей:

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

- специфікації здійснимого варіанту програмної системи;

- забезпечення багатократного використання окремих фрагментів програмного коду;

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

У мові UML виділяють три види компонентів.

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

- компоненти-робітники продукти. як правило - це файли з початковими текстами програм, наприклад, з розширеннями h або срр для мови c++;

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

23. Діаграма компонентів. Інтерфейс. Графічне зображення інтерфейсів. Графічне зображення залежностей.

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

Діаграма компонентів розробляється для наступних цілей:

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

- специфікації здійснимого варіанту програмної системи;

- забезпечення багатократного використання окремих фрагментів програмного коду;

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

Рис. 64 Графічне зображення інтерфейсів на діаграмі компонентів

Рис. 65. Фрагмент діаграми компонентів з відношенням залежності

24. Діаграма компонентів. Елементи діаграми компонентів: вузол, з’єднання, відношення залежності.

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

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

Рис. 67 Графічне зображення вузла на діаграмі розгортання

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

Рис. 70 Фрагмент діаграми розгортання із з'єднаннями між вузлами

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

Рис. 71 Діаграма розгортання з відношенням залежності між вузлом і розгорнутими на ньому компонентами

25. Оглядова діаграма взаємодії.

Діаграма об'єктів — в UML, діаграма, що відображає об'єкти та їх зв'язки в певний момент часу.^[1] Діаграма об'єктів може розглядатись як окремий випадок діаграми класів, на якій можуть бути представлені як класи, так і екземпляри (об'єкти) класів. Схожою за змістом є діаграма взаємодії (англ. collaboration diagram).

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

Дата добавления: 2015-10-21