
- •1 Поняття і методи програмної інженерії, моделі процесу створення програмного забезпечення
- •2 Системотехніка обчислювальних систем: інтеграційні властивості систем, система та її оточення
- •3 Системотехніка обчислювальних систем: моделювання систем, процес створення систем
- •4 Ітераційні моделі розробки програмного забезпечення
- •5 Процес створення програмного забезпечення: специфікація програмного забезпечення, проектування і реалізація програмного забезпечення
- •6 Процес створення програмного забезпечення: атестація програмних систем і їх еволюція
- •7 Управління проектами: процеси управління, графік робіт, часові і мережні діаграми.
- •8 Управління ризиками
- •9 Класифікація вимог до програмного забезпечення: функціональні і нефункціональні вимоги, користувацькі і системні вимоги
- •10 Розробка вимог: аналіз здійсненності, формування і аналіз вимог
- •11 Розробка вимог: атестація, керування
- •12 Моделі системного оточення. Моделі поведінки
- •13 Моделі даних. Об'єктні моделі.
- •14 Прототипування в процесі розробки програмного забезпечення
- •15 Швидке прототипування і прототипи користувацьких інтерфейсів
- •Формальні специфікації програмного забезпечення
- •Архітектурне проектування: поняття, підходи, моделі, проблемно-залежні архітектури
- •Архітектура клієнт-сервер
- •Архітектура розподілених об’єктів. Багатопроцесорна архітектура
- •Об’єктно-орієнтоване проектування: об’єкти і класи об’єктів
- •Принципи і етапи процесу об’єктно-орієнтованого проектування
- •Проектування систем реального часу: поняття класифікація систем реального часу
- •Метод покомпонентної розробки з повторним використанням компонентів
- •Проектування інтерфейсу користувача: принципи, взаємодія з користувачем, представлення інформації
- •Проектування інтерфейсу користувача: засоби підтримки користувача, оцінювання інтерфейсу
- •45. Мова uml. Призначення діаграм моделювання
- •50. Складні переходи
50. Складні переходи
Розглянуте вище поняття переходу є цілком достатнім для більшості типових розрахунково-обчислювальних завдань. Однак сучасні програмні системи можуть реалізовувати дуже складну логіку поведінки окремих своїх компонентів. Може виявитися, що для адекватного представлення процесу зміни станів семантика звичайного переходу для них недостатня. З цією метою в мові UML специфіковані додаткові позначення і властивості, якими можуть володіти окремі переходи на діаграмі станів.
Переходи між паралельними станами
В окремих випадках перехід може мати кілька станів-джерел і кілька цільових станів. Такий перехід отримав назву паралельний перехід.
Графічно такий перехід зображується вертикальною рискою. Якщо паралельний перехід має дві і більше входять дуги, його називають з'єднанням (Join). Якщо ж він має дві або більше вихідні дуги, то його називають розгалуженням (вилка). Текстовий рядок специфікації паралельного переходу записується поряд з рискою і відноситься до всіх вхідними або вихідними дуг.
Спрацювання паралельного переходу відбувається наступним чином. Перехід-з'єднання виконується, якщо має місце подія-тригер для всіх вихідних станів цього переходу, і виконано, якщо таке є, сторожове умова. При спрацьовуванні переходу-з'єднання одночасно покидаются всі вихідні стану переходу і відбувається перехід в цільовий стан. При цьому кожне з вихідних станів переходу має належати окремому підавтомат, що входить до складу автомата.
У разі розгалуження відбувається поділ автомата на два підавтомат, що утворюють паралельні гілки вкладених підстанів. Після спрацьовування переходу модельований об'єкт одночасно перебуватиме у всіх цільових станах цього переходу. Далі процес зміни станів протікатиме згідно з правилами для складених станів.
Переходи між складовими станами
Перехід, стрілка якого з'єднана з кордоном деякого складеного стану, позначає перехід до складеного стан. Такий перехід еквівалентний переходу в початковий стан кожного з підавтомат, що входять до складу даного суперсостоянія. Перехід, що виходить з складеного стану, відноситься до кожного з вкладених підстанів. Це означає, що об'єкт може покинути складене суперсостояніе, перебуваючи в будь-якому з його підстанів. Для цього цілком достатньо виконання події та сторожового умови.
Іноді бажано реалізувати ситуацію, коли вихід з окремого вкладеного стану відповідав би виходу і з складеного стану теж. У цьому випадку зображують перехід, який безпосередньо виходить з вкладеного підстани за кордон суперсостоянія. Аналогічно, допускається зображення переходів, що входять ззовні складового стану в окреме вкладене стан.
Синхронізуючі стану
Як вже було зазначено, поведінка паралельних підавтомат незалежно один від одного, що дозволяє реалізувати багатозадачність в програмних системах. Однак, в окремих випадках може виникнути необхідність врахувати в моделі синхронізацію настання окремих подій. Для цієї мети в мові UML є спеціальне псевдосостояніе, яке називається синхронізуючим станом.
Синхронізуючий стан (стан синхронізації) позначається слабкий окружністю, всередині якої поміщений символ зірочки «*». Воно використовується спільно з переходом-з'єднанням або переходом-розгалуженням для того, щоб явно вказати події в інших підавтомат, які надають безпосередній вплив на поведінку даного підавтомат.
52. Діаграма діяльності - це окремий випадок діаграми станів. На діаграмі діяльності представлені переходи потоку керування від однієї діяльності до іншої всередині системи. Цей вид діаграм зазвичай використовується для опису поведінки, що включає в себе безліч паралельних процесів.Основними елементами діаграм діяльності є:
овалы, изображающие действия объекта
лінійки синхронізації, що вказують на необхідність завершити або почати декілька дій (модель логічного умови «І»);
ромби, що відображають прийняття рішень з вибору одного з маршрутів виконання процесу (модель логічного умови «АБО»);
стрілки - відображають послідовність дій, можуть мати мітки умов.
На діаграмі діяльності можуть бути представлені дії, відповідні кількома варіантами використання. На таких діаграмах з'являється безліч початкових точок, оскільки вони відображають тепер реакцію системи на безліч зовнішніх подій. Таким чином, діаграми діяльності дозволяють отримати повну картину поведінки системи і легко оцінювати вплив змін в окремих варіантах використання на кінцеве поведінку системи.Будь-яка діяльність може бути піддана подальшій декомпозиції і представлена у вигляді окремої діаграми діяльності або специфікації (словесного опису).
53. Цей вид діаграм використовується для точного визначення логіки сценарію виконання прецеденту. Діаграми послідовностей відображають типи об'єктів, взаємодіючих при виконанні прецедентів, повідомлення, які вони посилають один одному, і будь-які повертаються значення, асоційовані з цими повідомленнями. Прямокутники на вертикальних лініях показують «час життя» об'єкта. Лінії зі стрілками і написами назв методів означають виклик методу в об'єкта.
Діаграма послідовності обробки замовлення:
вводяться рядка замовлення;
по кожному рядку перевіряється наявність товару;
якщо запас достатній - ініціюється поставка;
якщо запас недостатній - ініціюється дозамовлення (повторне замовлення).
54-55. На кооперативних діаграмах об'єкти (або класи) показуються у вигляді прямокутників, а стрілками позначаються повідомлення, якими вони обмінюються в рамках одного варіанту використання. Тимчасова послідовність повідомлень відбивається їх нумерацією.
57. Діаграми компонентів дозволяють зобразити модель системи на фізичному рівні.
Елементами діаграми є компоненти - фізичні заміщаються модулі системи. Кожен компонент є повністю незалежним елементом системи. Різновидом компонентів є вузли. Вузол - це елемент реальної (фізичної) системи, який існує під час функціонування програмного комплексу і являє собою обчислювальний ресурс, зазвичай володіє як мінімум деяким об'ємом пам'яті, а часто ще й здатністю обробки. Вузли поділяються на два типи:
пристрою - вузли системи, в яких дані не обробляються.
процесори - вузли системи, що здійснюють обробку даних.
Для різних типів компонентів передбачені відповідні стереотипи в мові UML.
Компонентом може бути будь-який досить великий модульний об'єкт, такий як таблиця або екстент бази даних, підсистема, бінарний виконуваний файл, готова до використання система або додаток. Таким чином, діаграму компонентів можна розглядати як діаграму класів в більш великому (менш детальному) масштабі. Компонент, як правило, являє собою фізичну упаковку логічних елементів, таких як класи, інтерфейси і кооперації.
Основне призначення діаграм компонентів - поділ системи на елементи, які мають стабільний інтерфейс і утворюють єдине ціле. Це дозволяє створити ядро системи, яке не змінюватиметься у відповідь на зміни, що відбуваються на рівні підсистем.
Кожен компонент діаграми при необхідності документується за допомогою більш детальної діаграми компонентів, діаграми сценаріїв або діаграми класів.
58. Діаграма розгортання (англ. deployment diagram) — діаграма в UML, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах. Компоненти відповідають представленню робочих екземплярів одиниць коду. Компоненти, що не мають представлення під час роботи програми на таких діаграмах не відображаються; натомість, їх можна відобразити на діаграмах компонент. Діаграма розгортання відображає робочі екземпляри компонент, а діаграма компонент, натомість, відображає зв'язки між типами компонент.