Тобі прийшла крута ідея продукту, але ти не хочеш загрузнути в коді і втратити цілісну картинку через дрібні деталі? Ти ось-ось сядеш за те, що крекнув корпоративний сервер і тобі потрібно набити щось круте та айтішне? Цей цикл статей буде присвячений корисному, але часом вислизає від молодої порослі знання - діаграм UML. І почну я його з огляду існуючих діаграм, поговоримо трохи про історію та навіщо діаграм має бути так багато. UML є набором кращих інженерних практик, які довели свою ефективність у моделюванні великих і складних систем і є дуже важливою частиною розробки об'єктно-орієнтованого програмного забезпечення. UML використовує переважно графічні позначення, щоб висловити дизайн програмних проектів. Використання UML допомагає проектним групам спілкуватися, вивчати потенційні проекти та перевіряти архітектурний дизайн програмного забезпечення. Мета UML — надати стандартну нотацію, яка може використовуватись усіма об'єктно-орієнтованими методами, а також вибрати та інтегрувати найкращі елементи нотацій-попередників. UML був розроблений для широкого спектру програм.Отже, він надає конструкції для широкого спектру систем та видів діяльності (наприклад, розподілених систем, аналізу, проектування та розгортання систем). UML не з'явився на порожньому місці, йому передували кілька значних подій, особистостей та методологій. Наприклад: До 1995 року творець OOSE, Івар Якобсон, також приєднався до Rational, і його ідеї (зокрема, концепція «прецедентів») були включені до нового уніфікованого методу, який тепер називається Unified Modeling Language. На противагу всім відомій “Банді Чотирьох”, Команда Румбо, Буча та Якобсона відома як “Три Амігоси”. На UML також вплинули інші об'єктно-орієнтовані нотації: У міру того, як стратегічна цінність програмного забезпечення зростала для багатьох компаній, галузь шукала методи для автоматизації виробництва програмного забезпечення, а також для підвищення якості та скорочення витрат та часу виходу на ринок. Ці методи включають технологію компонентів, візуальне програмування, шаблони та структури. Компанії також шукають методи управління складністю систем зі збільшенням їх масштабу. Зокрема, вони визнають необхідність вирішення повторюваних архітектурних проблем, таких як фізичний розподіл, паралелізм, реплікація, безпека, балансування навантаження та відмовостійкість. Крім того, розробка під Web хоч і полегшує деякі речі, в цілому, вона посилює ці архітектурні проблеми. Уніфікована мова моделювання (UML) була розроблена для задоволення цих потреб. Основні цілі дизайну UML: Структурні діаграми показують статичну структуру системи та її частин на різних рівнях абстракції та реалізації, а також їхній взаємозв'язок.Елементи в структурній діаграмі представляють значні поняття системи і можуть включати абстрактні, реальні концепції і концепції реалізації. Існує сім типів структурних діаграм: Діаграма класів – це центральна методика моделювання, яка використовується практично у всіх об'єктно-орієнтованих методах. Ця діаграма описує типи об'єктів у системі та різні види статичних відносин, які існують між ними. Три найбільш важливі типи відносин у діаграмах класів (насправді їх більше), це: Асоціація, яка представляє відносини між екземплярами типів, наприклад, людина працює на компанію, компанія має кілька офісів. Спадкування, яке має безпосередню відповідність успадкування в Об'єктно-орієнтованому дизайні. Агрегація, яка представляє собою форму композиції об'єктів в об'єктно-орієнтованому дизайні. На мові уніфікованого моделювання діаграма компонентів показує, як компоненти з'єднуються разом для формування більших компонентів або програмних систем. Вона ілюструє архітектури компонентів програмного забезпечення та залежності між ними. Ці програмні компоненти включають компоненти часу виконання, виконувані компоненти, а також компоненти вихідного коду. Діаграма розгортання допомагає моделювати фізичний аспект об'єктно-орієнтованої програмної системи. Це структурна схема, яка показує архітектуру системи як розгортання (дистрибуції) програмних артефактів. Артефакти є конкретними елементами у фізичному світі, які є результатом процесу розробки. Діаграма моделює конфігурацію часу виконання у статичному поданні та візуалізує розподіл артефактів у додатку. Найчастіше це включає у собі моделювання конфігурацій устаткування разом із компонентами програмного забезпечення, де вони розміщені. Статична діаграма об'єктів є екземпляром діаграми класу; вона показує знімок докладного стану системи у певний час. Різниця в тому, що діаграма класів є абстрактною моделлю, що складається з класів та їх відносин. Тим не менш, діаграма об'єкта є екземпляром у конкретний момент, який має конкретний характер. Використання діаграм об'єктів досить обмежене, а саме — щоб показати приклади структури даних. Діаграма пакетів – це структурна схема UML, яка показує пакети та залежності між ними. Вона дозволяє відображати різні види системи, наприклад, легко змоделювати багаторівневу програму. p align="justify"> Діаграма складової структури аналогічна діаграмі класів і є свого роду діаграмою компонентів, що використовується в основному при моделюванні системи на мікрорівні, але вона зображує окремі частини замість цілих класів.Це тип статичної структурної діаграми, яка показує внутрішню структуру класу та взаємодії, які ця структура робить можливими. Ця діаграма може включати внутрішні частини, порти, через які частини взаємодіють один з одним або через які екземпляри класу взаємодіють з частинами та зовнішнім світом, і з'єднувачі між частинами або портами. Складова структура — це набір взаємозалежних елементів, які взаємодіють під час виконання задля досягнення будь-якої мети. Кожен елемент має певну роль у співпраці. Діаграма профілів дозволяє нам створювати специфічні для домену та платформи стереотипи та визначати відносини між ними. Ми можемо створювати стереотипи, малюючи форми стереотипів і пов'язуючи їх із композицією чи узагальненням через інтерфейс, орієнтований ресурси. Ми також можемо визначати та візуалізувати значення стереотипів. Діаграма прецедентів визначає функціональні вимоги системи з погляду прецедентів. По суті, це модель передбачуваної функціональності системи (прецедентів) та її середовища (акторів). Прецеденти дозволяють пов'язати те, що потрібно від системи про те, як система задовольняє ці потреби. Діаграми діяльності є графічне уявлення робочих процесів поетапних дій та дій з підтримкою вибору, ітерації та паралелізму. Діаграма станів — це тип діаграми, який використовується в UML для опису поведінки систем, що базується на концепції діаграм станів Девіда Харела. Діаграми станів відображають дозволені стани та переходи, а також події, що впливають на ці переходи. Вона допомагає візуалізувати весь життєвий цикл об'єктів і, таким чином, допомагає краще зрозуміти системи, що базуються на стані. Діаграма послідовності моделює взаємодію об'єктів на основі тимчасової послідовності. Вона показує, як одні об'єкти взаємодіють із іншими конкретному прецеденті. Як і діаграма послідовності, діаграма комунікації також використовують для моделювання динамічної поведінки прецеденту. Якщо порівнювати з діаграмою послідовності, діаграма комунікації більше сфокусована на показі взаємодії об'єктів, а не часової послідовності. Насправді діаграма комунікації та діаграма послідовності семантично еквівалентні і можуть перетікати одна в одну. Діаграма огляду взаємодій фокусується на огляді потоку керування взаємодіями. Це варіант Діаграми діяльності, де вузлами є взаємодії чи події взаємодії. Діаграма огляду взаємодій описує взаємодії, у яких повідомлення та лінії життя приховані. Ми можемо зв'язати «реальні» діаграми та досягти високого ступеня навігації між діаграмами всередині діаграми огляду взаємодії. Тимчасова діаграма показує поведінку об'єкта (ів) у період. По суті, це особлива форма діаграми послідовності і відмінності між ними полягають у тому, що осі змінюються місцями так, що час збільшується зліва направо, а лінії життя відображаються в окремих відсіках, розташованих вертикально. Причина цього полягає в тому, що можна поглянути на систему з різних точок зору, адже в розробці програмного забезпечення братимуть участь багато зацікавлених сторін, такі як: аналітики, конструктори, кодери, тестери, контроль якості, клієнти, технічні автори. Всі ці люди зацікавлені у різних аспектах системи, і кожен із них потребує різного рівня деталізації. Наприклад, кодер повинен розуміти проект системи та вміти перетворювати проект на код низького рівня. Навпаки, технічний письменник цікавиться поведінкою системи загалом і має розуміти, як функціонує продукт. UML намагається надати мову настільки виразним чином, що всі зацікавлені сторони можуть отримати вигоду як мінімум з однієї діаграми UML. Для тих, кому ліньки читати: Діаграма станів (State diagram) — це один із видів діаграм UML, які використовуються у розробці програмного забезпечення, щоб візуалізувати та моделювати поведінку об'єкта чи системи у різних станах. Вона дозволяє описати всі можливі стани об'єкта, і навіть переходи з-поміж них у відповідь певні події. Діаграма станів описує всі можливі стани, у яких може бути об'єкт чи система, і навіть переходи між цими станами.Вона дозволяє візуально уявити різні стани об'єкта чи системи та показати, як вони змінюються у відповідь на події чи зовнішні умови. Переходи позначають зміну стану та вказують, за яких умов відбувається перехід між станами. Події є зовнішніми сигналами чи діями, що викликають переходи між станами. На діаграмі станів UML стану зазвичай представляються як прямокутників з назвами, а переходи — стрілками. Додаткові інструкції можуть використовуватися для визначення умов переходів або дій, що виконуються в певних станах. Діаграма станів UML широко використовується при аналізі та проектуванні систем, де важливо моделювати поведінку об'єктів чи системи у різних сценаріях. Вони допомагають розробникам краще зрозуміти та визначити логіку станів та переходів, що сприяє більш ефективній реалізації та тестуванню програмного забезпечення. Початковий стан - Це стан, з якого починається виконання процесу. Воно позначається за допомогою символу заповненого кружка, звідки виходять стрілки, що представляють переходи до інших станів. Початковий стан вказує на точку входу в модель поведінки та визначає, з якого стану об'єкт чи система починає своє виконання або реагує на події. Коли діаграма станів запускається, вона відразу переходить з початкового стану в інший стан у відповідь певну подію чи дію. Приклад відображення початкового стану на state diagram Зазвичай початковий стан не містить жодної логіки або дій, він служить для позначення стартової точки.Однак воно може бути пов'язане з переходами, що визначають перший стан, до якого буде здійснено перехід після входу в систему або після виконання деяких початкових дій. Початковий стан може бути єдиним на діаграмі станів або використовувати кілька початкових станів, щоб вказати на можливість паралельного або невизначеного старту в різних станах системи. Кінцевий стан — це стан, у якому процес завершує виконання. Воно позначається зазвичай з допомогою символу закритого кружка. Кінцевий стан вказує на завершення об'єкта або системи і позначає, що подальше виконання або процес досягне свого завершення. Кінцевий стан може бути одним або множинним на діаграмі станів. Якщо на діаграмі є тільки один кінцевий стан, то він вказує на остаточне завершення об'єкта або системи. досягнуто залежно від певних умов чи подій. Позначення кінцевого стану на state diagram
Кінцевий стан немає вихідних переходів, після його досягнення об'єкт не перетворюється на інші стану. Стан у діаграмі станів UML є певний стан об'єкта або системи, який може змінюватися у відповідь на певні події, умови або дії. Воно визначає його поведінку та властивості у певний момент часу. У діаграмі станів UML стан зазвичай представляється прямокутником під назвою стану. Стани можуть бути позначені текстовими мітками, що описують їх зміст або функціональність. Наприклад, стан "очікування", "активний", "заблокований" і т.д. Позначення стану на state diagram
Стан об'єкта може бути довготривалим або миттєвим. Довготривалий стан означає, що об'єкт залишається в цьому стані протягом деякого часу, поки не станеться подія або умова, що викликає перехід в інший стан. Миттєвий стан, з іншого боку, є нетривалим моментом часу, коли об'єкт знаходиться в певному стані перед виконанням переходу. Складовий стан у діаграмі станів UML є стан, який містить внутрішні стани і переходи між ними. Воно дозволяє структурувати складніші стану та його поведінку всередині об'єкта чи системи. Складовий стан зазвичай представляється у вигляді прямокутника, всередині якого містяться інші стани та переходи. Внутрішні стани та переходи можуть бути представлені як окремі елементи всередині складеного стану або у вигляді вкладених діаграм станів. У складеному стані можна визначити ієрархію вкладених станів, яка відображає різні рівні деталізації поведінки об'єкта чи системи.Коли об'єкт перебуває у складовому стані, його поведінка може залежати від поточного внутрішнього стану і переходити між ними у відповідь певні події чи умови. Позначення складеного стану на діаграмі станів
Складові стану зазвичай використовуються для моделювання складних сценаріїв або поведінки системи, де об'єкт може перебувати в різних підходах і переходити між ними відповідно до певних правил або умов. Вони дозволяють більш структуровано і зрозуміло уявити складні потоки виконання та взаємодії об'єктів у системі. захисна умова є логічним виразом, який визначає умови, за яких може статися перехід з одного стану в інший. Воно є частиною переходу та допомагає керувати потоком виконання між станами. Захисна умова вказує на необхідність задоволення певної умови для здійснення переходу. Якщо умова є істинною (виконується), перехід може відбутися. Якщо умова хибна, перехід буде заблоковано, і об'єкт чи система залишиться у поточному стані. Захисні умови можуть бути виражені за допомогою логічних операторів та порівнянь для перевірки значень змінних, прапорів чи інших умов, що впливають на переходи між станами. Захисні умови дозволяють керувати переходами між станами на основі певних умов, що робить модель більш гнучкою та реалістичною. Вони дозволяють об'єкту приймати рішення про переходи, ґрунтуючись на поточних умовах та змінних оточення. Розділювач, також відомий як паралельний стан або стан з одночасним виконанням, представляє стан, в якому об'єкт або система може знаходитися одночасно в декількох станах, що взаємодіють. Це дозволяє моделювати паралельне виконання чи конкурентні аспекти поведінки об'єкта чи системи. Розділювач є горизонтальною лінією, що перетинає стани і переходи. Він вказує, що об'єкт може бути в різних станах одночасно і виконувати відповідні дії паралельно. Стани, розташовані вище та нижче роздільника, є паралельними і можуть виконуватися незалежно один від одного. Переходи, пов'язані з кожним паралельним станом, можуть працювати незалежно в залежності від умов або подій. Роздільник часто використовується для моделювання паралельних процесів або паралельних потоків виконання в системі. Він дозволяє уявити ситуації, коли об'єкт виконує кілька дій одночасно чи у системі відбувається взаємодія між різними компонентами, виконують різні завдання одночасно. Історичний стан представляє спеціальний стан, який зберігає інформацію про попередній стан об'єкта чи системи. Воно використовується для моделювання повернення до попереднього стану або збереження контексту стану. У діаграмі станів історичний стан зазвичай позначається символом H всередині стану. Історія може мати вхідні та вихідні переходи, які дозволяють об'єкту або системі відновити попередній стан або перейти до нового стану залежно від контексту. Історичний стан історичний стан зберігає лише сам стан, без збереження інформації про підстанні. У разі переходу через такий стан об'єкт повертається до попереднього стану без відновлення його внутрішніх станів. Позначення історичного стану на діаграмі станів
Використання історії станів дозволяє об'єкту повертатися до попереднього стану та продовжувати виконання відповідної поведінки. Це корисно в ситуаціях, коли після виконання певної дії чи події об'єкт повинен повернутися до стану, який він знаходив раніше та продовжуючи виконання з того місця, де його залишили. Глибокий історичний стан є особливою формою історії станів, яка зберігає інформацію про попередній стан об'єкта і всі його внутрішні стани. Воно позначається символом H* усередині стану. Воно має вхідні та вихідні переходи, що дозволяють об'єкту відновити попередній стан із усіма вкладеними станами. Використання глибоких історій корисне в ситуаціях, коли об'єкт має складну структуру станів із вкладеними підходами. При переході через глибоку історію об'єкт повертається до попереднього стану разом з його підходами. Перехід - Це елемент діаграми станів, який являє собою перехід об'єкта з одного стану в інший. Він визначає подію або умову, що викликає зміну стану, і вказує, який перехід має бути виконаний при настанні цієї події чи умови. Переходи зазвичай видаються стрілками, які з'єднують стани у діаграмі станів.Вони можуть мати мітку, яка вказує подію або умову, за якої перехід може бути виконаний. Переходи можуть бути спрямованими чи неспрямованими. Спрямований перехід вказує односпрямований потік виконання від одного стану до іншого. Ненаправлений перехід є перехід, який може бути виконаний в обох напрямках між станами. Позначення переходу на діаграмі станів При настанні події або задоволенні умови, пов'язаної з переходом, об'єкт або система переходить із поточного стану до цільового стану, що вказано на кінці переходу. Внаслідок виконання переходу можуть бути виконані дії або зміни внутрішнього стану об'єкта. Переходи дозволяють моделювати потоки виконання та зміни станів об'єкта, відображаючи його поведінку та реакцію на події чи умови. Вони допомагають створити більш детальну та зрозумілу модель об'єкта чи системи в рамках діаграми станів. При побудові діаграми станів UML рекомендується дотримуватися певних правил, щоб забезпечити зрозумілість та чіткість моделі. Ось деякі з основних правил побудови діаграми станів: Пам'ятайте, що діаграма станів служить візуалізації поведінки об'єкта, тому підтримуйте її ясність і зрозумілість. На цьому кроці необхідно визначити всі стани в яких може перебувати об'єкт, що моделюється. Визначимо стани на прикладі пристрою клімат-контролю.Припустимо, пристрій може знаходитися в станах «Режим очікування», «Охолодження», «Обігрів» та «Вентиляція». На цьому кроці необхідно визначити переходи між станами, події, що викликають переходи, та захисні умови. Припустимо, що ми маємо події «Включити», «Вимкнути», «Встановити режим охолодження», «Встановити режим обігріву» та «Встановити режим вентиляції». Додамо захисні умови контролю переходів. Тепер визначимо захисні умови, для події «Встановити режим охолодження» захисною умовою може бути «Температура вище за задану», для «Встановити режим обігріву» — «Температура нижче за задану» В результаті побудована діаграма станів виглядає наступним чином Приклад state diagram для кейсу «Керування температурою»
Як я зрозумів, діаграма діяльності, це окремий випадок діаграми станів, але подивившись кілька прикладів, жодної різниці щось не виявив. Пишу курсач, на тему моделювання деякої цікавої САУ мовою UML. У сабжі знаюся, але UML побачив уперше. Поясніть просто і двома словами, у чому основні відмінності. Літературою вже обклався, давати мені ще більше не треба, поясніть на пальцях, якщо це можливо. мануалами обклався, а читати їх не пробував? Що знаходиться між ідеєю та кодом? Огляд 14 діаграм UML
UML – це скорочення від Unified Modeling Language, і, як ми знаємо, він є стандартизованою мовою моделювання, що складається з інтегрованого набору діаграм, розроблених, щоб допомогти розробникам систем та програмного забезпечення у визначенні, візуалізації, конструюванні та документуванні артефактів програмних систем, а також , Наприклад, для бізнес-моделювання.Походження UML
Чому UML?
Діаграма класів
Діаграма компонентів
Діаграма розгортання
Діаграма об'єктів
Діаграма пакетів
Діаграма складової структури
Діаграма профілів
Діаграма прецедентів
Діаграма діяльності
Вони описують потік управління цільовою системою, такий як дослідження складних бізнес-правил та операцій, а також опис прецедентів та бізнес-процесів.
У UML діаграми діяльності призначені для моделювання як обчислювальних, і організаційних процесів.Діаграма станів
Діаграма послідовності
Діаграма комунікації
Діаграма огляду взаємодії
Тимчасова діаграма
Навіщо в UML стільки діаграм?
Діаграма станів UML. Правила та приклад моделювання.
Компоненти діаграми станів
Початковий стан (Start state)
Кінцевий стан (Final state)
Стан (State)
Складовий стан (Composite state)
Захисна умова (Guard Condition)
Розділювач (Concurrent state)
Історичний стан (Historical State)
Глибокий історичний стан (Deep Historical State)
Перехід (Transition)
Правила побудови діаграми станів
Як побудувати діаграму станів
Крок 1: Визначення станів
Крок 2: Визначення переходів
Крок 3: Додавання захисних умов
Гей, знавці мови UML! Чим відрізняється діаграма діяльності діаграми станів?
Діаграма станів - орієнтований граф для кінцевого автомата, в якому
вершини позначають стани
дуги показують переходи між двома станами
На практиці вершини зазвичай зображуються у вигляді кіл і, якщо потрібно, подвійних кіл. У нотації UML стану зображуються прямокутниками із закругленими кутами. - це з вікіпедії
Діаграма діяльності англ. activity diagram — діаграма, де показано розкладання певної діяльності її складові. Під діяльністю англ. activity розуміється специфікація виконуваного поведінки як координованого послідовного і паралельного виконання підлеглих елементів — вкладених видів діяльності та окремих дій англ. action, з'єднаних між собою потоками, що йдуть від виходів одного вузла до входів іншого. - з тієї ж вікіпедії