Модуль №1 "Методологічні основи розробки інформаційних систем" (стр. 7 )

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

Приклад діаграми станів для технічного пристрою типу комп'ютер

Основні поняття:

·  стан (деякий інтервал часу);

·  перехід (тривалість прагне до 0).

Вершина графа - стан; дуги - перехід. Виділяють сукупність двох станів: початкове й кінцеве.

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

Список внутрішніх дій: кожне з дій записується у вигляді рядка й має формат: < мітка-дії '/' вираження-дії>.

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

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

exit - вихідна дія;

do - специфицирует діяльність (активність), що виконується протягом усього часу, поки об'єкт перебуває в даному стані;

Приклад станів із секцією внутрішніх дій

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

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

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

Кінцевий стан також не містить ніяких внутрішніх дій. У цьому стані буде перебувати об'єкт після завершення роботи.

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

<сигнатура події>'['<сторожова умова>']' <вираження дії>.

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

Сторожова умова завжди записується в [] послу події тригера і являє собою деяке буллевое вираження. У дужках може випливати список параметрів через кому.

Діаграма станів поштової програми-клієнта

Вираження дій виконується в тому випадку, якщо перехід закінчується (спрацьовує).

Приклад діаграми станів дозвон до абонента

Заключні рекомендації з побудови діаграм станів

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

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

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

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

Лекція 13

Діаграма діяльності (activity diagram)

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

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

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

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

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

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

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

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

Різні варіанти розгалужень на діаграмі діяльності

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

Доріжки в діаграмах діяльності

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

Діаграми діяльності торговельної компанії з об'єктом-замовленням

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

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

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

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

Лекція 14

Діаграма компонентів (component diagram)

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

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

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

Діаграма фізичного подання системи = діаграма реалізації.

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

Компоненти

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

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

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

Графічне зображення компонента в мові UML

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