Призначення діаграм UML. UML-діаграма

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

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

        UML надає виразні засоби для створення візуальних моделей, які:

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

        Уніфікована Мова Моделювання (UML):

• не залежить від об'єктно-орієнтованих (ГО) мов програмування;
• не залежить від методології розробки проекту, що використовується;
• може підтримувати будь-яку мову програмування.

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

Діаграми UML

        У розпорядження проектувальника системи Rational Rose надає наступні типи діаграм, послідовне створення яких дозволяє отримати повне уявлення про всю проектовану систему та про окремі її компоненти:

• Use case diagram (діаграми прецедентів);
• Deployment diagram (діаграми топології);
• Statechart diagram (діаграми станів);
• Interaction diagram (діаграми взаємодії); Activity diagram (діаграми активності);
• Sequence diagram (діаграми послідовностей дій);
• Collaboration diagram (діаграми співробітництва);
• Class diagram (діаграми класів);
• Component diagram (діаграми компонент);
• Behavior diagrams (діаграми поведінки);
• Activity diagram (діаграма діяльності);
• Implementation diagrams(діаграми реалізації);

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

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

        Для діаграм мови UML існують три типи візуальних позначень, які важливі з точки зору інформації, що міститься в них:

• зв'язкуякі представляються різними лініями на площині;
• текст, Що міститься всередині кордонів окремих геометричних фігур;
• графічні символи, що зображуються поблизу візуальних елементів діаграм.

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

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

Сутності в UML

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

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

        Поведінкові сутностіє динамічними компонентами моделі UML. Це дієслова, які описують поведінку моделі у часі та у просторі. Існує два основних типи поведінкових сутностей:

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

        Групуючі сутностіє частинами, що організують, моделі UML. Це блоки, куди можна розкласти модель. Така первинна сутність є у єдиному екземплярі - це пакет.

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

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

Відносини в UML

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

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

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

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

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

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

Загальні механізми UML

        Для точного опису системи в UML використовуються так звані загальні механізми:

• специфікації (specifications);
• доповнення (adornments);
• поділу (common divisions);
• розширення (extensibility mechanisms).

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

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

        При моделюванні об'єктно-орієнтованих систем існує певне поділпредставлених сутностей.

По-перше, існує розподіл на класи та об'єкти. Клас – це абстракція, а об'єкт – конкретне втілення цієї абстракції. У зв'язку з цим практично всі конструкції мови характеризуються двоїстістю "клас/об'єкт". Так, є прецеденти та екземпляри прецедентів, компоненти та екземпляри компонентів, вузли та екземпляри вузлів. У графічному поданні для об'єкта прийнято використовувати той самий символ, що й класу, а назву підкреслювати.

По-друге, існує розподіл на інтерфейс та його реалізацію. Інтерфейс декларує зобов'язання, а реалізація представляє конкретне здійснення цих зобов'язань та забезпечує точне дотримання оголошеної семантики. У зв'язку з цим, майже всі конструкції UML характеризуються подвійністю "інтерфейс/реалізація". Наприклад, прецеденти реалізуються коопераціями, а операції – методами.

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

        Механізми розширення UML містять:

• стереотипи (stereotype) - розширюють словник UML, дозволяючи з урахуванням існуючих елементів мови створювати нові, орієнтовані вирішення конкретної проблеми;
• позначені значення (tagged value) - розширюють властивості основних конструкцій UML, дозволяючи включати додаткову інформацію специфікацію елемента;
• обмеження (constraints) – розширюють семантику конструкцій UML, дозволяючи створювати нові та скасовувати існуючі правила.

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

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

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

Малюнок – 1. Діаграма варіантів використання

        Діаграми варіантів використання описують функціональне призначення системи або те, що система має робити. Розробка діаграми має такі цілі:

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

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

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

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

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

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

Діаграма класів (class diagram)

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

Малюнок – 2. Діаграма класів

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

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

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

Діаграма станів (statechart diagram)

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

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

Малюнок – 2. Діаграма станів

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

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

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

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

        Для автомата повинні виконуватися такі обов'язкові умови:

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

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

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

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

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

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

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

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

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

        У контексті мови UML діяльність (activity)являє собою сукупність окремих обчислень, що виконуються автоматом, що призводять до деякого результату чи дії (action). На діаграмі діяльності відображається логіка та послідовність переходів від однієї діяльності до іншої, а увага аналітика фокусується на результатах. Результат діяльності може призвести до зміни стану системи або повернення певного значення.

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

Діаграма послідовності (sequence diagram)

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

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

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

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

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

Діаграма кооперації (collaboration diagram)

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

Малюнок – 3. Діаграма кооперації

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

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

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

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

        Кооперація може бути представлена ​​на двох рівнях:

• рівні специфікації - показує ролі класифікаторів та ролі асоціацій у аналізованому взаємодії;
• рівні прикладів - вказує екземпляри та зв'язки, що утворюють окремі ролі в кооперації.

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

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

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

Діаграма компонентів (Component Diagram)

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

Малюнок – 4. Діаграма компонентів

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

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

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

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

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

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

Діаграма розгортання (deployment diagram)

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

Малюнок – 5. Діаграма розгортання

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

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

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

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

        Під час розробки діаграми розгортання переслідують такі цілі:

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

        Діаграми розгортання розробляються спільно системними аналітиками, мережевими інженерами та системотехніками.

Особливості робочого інтерфейсу Rational Rose

        У CASE-засобі Rational Rose реалізовані загальноприйняті стандарти на робочий інтерфейс програми, подібно до відомих середовищ візуального програмування. Після встановлення Rational Rose на комп'ютер користувача, що практично не викликає труднощів навіть у початківців, запуск цієї програми в середовищі MS Windows 95/98 призводить до появи на екрані робочого інтерфейсу (рис. 6).

Малюнок – 6.Загальний вигляд робочого інтерфейсу програми Rational Rose

        Робочий інтерфейс Rational Rose складається з різних елементів, основними з яких є:

• Головне меню програми
• Вікно діаграми
• Вікно документації
• Вікно браузера
• Вікно журналу

Розглянемо коротко призначення та основні функції кожного з цих елементів.

Головне меню програми

Головне меню програми виконано у загальноприйнятому стандарті та має такий вигляд (рис. 7).

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

Малюнок – 7. Зовнішній виглядголовного меню програми

Стандартна панель інструментів

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

Малюнок – 8.Зовнішній вигляд стандартної панелі інструментів

Користувач може налаштувати зовнішній вигляд цієї панелі на власний розсуд. Для цього необхідно вибрати пункт меню Tools -> Options (Інструменти -> Параметри) та відкрити вкладку Toolbars (Панелі інструментів). В такий спосіб можна показати або приховати різні кнопки інструментів, а також змінити їх розмір.

Вікно браузера

Вікно браузера за умовчанням розташовується у лівій частині робочого інтерфейсу під стандартною панеллю інструментів (рис. 9).

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

Малюнок – 9.Зовнішній вигляд браузера

Спеціальна панель інструментів

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

Малюнок – 10.Зовнішній вигляд спеціальної панелі інструментів для класових діаграм

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

Вікно діаграми

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

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

Малюнок – 11.Зовнішній вигляд вікна діаграм із різними видами уявлень моделі

Вікно документації

Вікно документації за замовчуванням може не відображатися на екрані. У цьому випадку воно може бути активізовано через пункт меню View -> Documentation (Вид->Документація), після чого з'явиться нижче за браузер (рис. 12).

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

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

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

Малюнок – 12.Зовнішній вигляд вікна документації

Вікно журналу

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

Вікно журналу завжди присутнє на робочому інтерфейсі в області діаграми (рис. 13). Однак, воно може бути закрите іншими вікнами з діаграмами або бути згорнутим. Активізувати вікно журналу можна за допомогою меню Window->Log (Вікно->Журнал). У цьому випадку воно зображується поверх інших вікон у правій ділянці робочого інтерфейсу. Цілком видалити це вікно не можна, його можна тільки мінімізувати.

Малюнок – 13.Зовнішній вигляд вікна журналу

Висновок

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

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

У цій статті розповідається про нову епоху розробки ПЗ, її вплив на нові вимоги, що висуваються до мови UML, і про оптимальні методи їх виконання.
  7. "Моделювання даних у Rational Rose" Сергій Трофімов Описується моделювання фізичного представлення даних з використанням Rational Rose
8. Мова UML . Загальне уявлення про мову UML: структури, графічні елементи та діаграми мови.
9. Практичний UML . Цей документ є перекладом документа "Practical UML. A Hands-On Introduction for Developers". Практичний вступ для розробників
10. "Стандартна мова об'єктно-орієнтованого моделювання UML" Вендров Олександр Михайлович . Історія створення UML
  11. UML – уніфікована мова моделювання. Даний матеріал містить початкові відомості про методи опису програмних систем та нотації, що використовуються в UML
12. Мова UML. Інструкція користувача. Автори: Грейді Буч, Джеймс Рамбо, Айвар Джекобсон
  13. "UML діаграми в Rational Rose" Сергій Трофімов
  14. "Аналіз та проектування. Візуальне моделювання (UML) Rational Rose" Костянтин Домолего
15. Бібліотека Геннадія Вернікова. Повні описистандартів проектування та моделювання.
16. "Приклад опису предметної області з використанням UML при розробці програмних систем" О.Б. Золотухіна, Р.В. Алфімов. У статті на конкретному прикладідемонструється можливий підхід до моделювання предметної області, що ґрунтується на застосуванні Уніфікованого Мова Моделювання (Unified Modeling Language) (UML)

       

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

Коротка історія UML

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

За запитом Object Management Group (OMG) – організації, відповідальної за прийняття стандартів у галузі об'єктних технологій та баз даних, назрілу проблему уніфікації та стандартизації було вирішено авторами трьох найбільш популярних ГО методів – Г.Бучем, Д.Рамбо та А.Джекобсоном, які об'єднані зусиллями створили версію UML 1.1, затверджену OMG у 1997 році як стандарт.

UML – це мова

Будь-яка мова складається зі словника та правил комбінування слів для отримання осмислених конструкцій. Так, зокрема, влаштовані мови програмування, такою є UML. Відмінною його особливістю є те, що словник утворюють графічні елементи. Кожному графічному символу відповідає конкретна семантика, тому модель, створена одним розробником, може бути однозначно зрозуміла іншим, а також програмним засобом, інтерпретуючим UML Звідси, зокрема, випливає, що модель ПС, представлена ​​на UML, може автоматично бути переведена на ГО мову програмування (такі як Java, C++, VisualBasic), тобто, за наявності гарного інструментального засобу візуального моделювання, що підтримує UML, побудувавши модель , ми отримаємо і заготівлю програмного коду, що відповідає цій моделі.

Слід наголосити, що UML – це саме мова, а не метод. Він пояснює, з яких елементів створювати моделі та як їх читати, але нічого не говорить про те, які моделі та в яких випадках слід розробляти. Щоб створити метод з урахуванням UML, треба доповнити його описом процесу розробки ПС. Прикладом такого процесу є Rational Unified Process, який розглядатиметься у наступних статтях.

Словник UML

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

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

Відносинипоказують різні зв'язки між сутностями. У UML визначено такі типи відносин:

• Залежністьпоказує такий зв'язок між двома сутностями, коли зміна однієї з них – незалежної – може вплинути на семантику іншою – залежною. Залежність зображується пунктирною стрілкою, спрямованої від залежної сутності незалежної.
• Асоціація- Це структурне відношення, що показує, що об'єкти однієї сутності пов'язані з об'єктами іншої. Графічно асоціація показується у вигляді лінії, що з'єднує сутності, що зв'язуються. Асоціації служать для навігації між об'єктами. Наприклад, асоціація між класами «Замовлення» та «Товар» може бути використана для знаходження всіх товарів, зазначених у конкретному замовленні – з одного боку, або для знаходження всіх замовлень, у яких є даний товар, – з іншого. Зрозуміло, що у відповідних програмах має бути реалізований механізм, що забезпечує таку навігацію. Якщо потрібна навігація лише в одному напрямку, воно показується стрілкою наприкінці асоціації. Приватним випадком асоціації є агрегування – ставлення до виду «ціле» – «частина». Графічно воно виділяється за допомогою ромбіка на кінці біля сутності цілого.
• Узагальнення- Це відношення між сутністю-батьком і сутністю-нащадком. Фактично, це ставлення відбиває властивість успадкування для класів, і об'єктів. Узагальнення показується у вигляді лінії, що закінчується трикутником, спрямованим до батьківської сутності. Нащадок успадковує структуру (атрибути) і поведінку (методи) батька, але водночас може мати нові елементи структури і нові методи. UML допускає множинне успадкування, коли сутність пов'язана з більш ніж однією батьківською сутністю.
• Реалізація- Відношення між сутністю, що визначає специфікацію поведінки (інтерфейс) з сутністю, що визначає реалізацію цієї поведінки (клас, компонент). Це ставлення зазвичай використовується при моделюванні компонентів і буде докладніше описано в наступних статтях.

діаграми.У UML передбачені такі діаграми:

• Діаграми, що описують поведінку системи:
• Діаграми станів (State diagrams),
• Діаграми діяльності (Activity diagrams),
• Діаграми об'єктів (Object diagrams),
• Діаграми послідовностей (Sequence diagrams),
• Діаграми взаємодії (Collaboration diagrams);
• Діаграми, що описують фізичну реалізацію системи:
• Діаграми компонентів (Component diagrams);
• Діаграми розгортання (Deployment diagrams).

Подання керування моделлю. Пакети.

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

Що забезпечує UML.

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

І останнє…

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

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

Що таке UML?

Якщо подивитися картинки в пошукових системах, то стане зрозуміло, що UML– це щось про схеми, стрілочки та квадратики. Що важливо, що UML перекладається як Unified Modeling Language. Важливе слово Unified. Тобто наші картинки зрозуміємо не лише ми, а й інші, хто знає UML. Виходить це така міжнародна мова малювання схем.

Як говорить Вікіпедія

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

Найцікавіше, що не всі замислюються чи здогадуються, UML має специфікації. І навіть є специфікація UML2. Докладніше зі специфікацією можна ознайомитись на сайті Object Management Group. Власне, ця група займається розробкою специфікацій UML. Цікаво, що UML не обмежується описом структури класів. Існує багато типів UML діаграм. Короткий опис типів UML діаграм можна побачити в тій же Вікіпедії: UML - діаграми або відео Тимура Батиршинова Огляд UML діаграм. UML також широко застосовується при описі різних процесів, наприклад тут: Єдиний вхід з використанням JWT . Повертаючись до використання UML діаграм класів, варто відзначити книгу Head First: Паттерни проектування, в якій патерни ілюструються тими самими UML діаграмами. Виходить, що UML справді використовується. І виходить, що знання та розуміння його застосування досить корисна навичка.

Застосування

Розберемо, як із цим UML можна працювати з IDE. Як IDE візьмемо IntelliJ Idea . Якщо використовувати IntelliJ Idea Ultimate, то у нас "з коробки" буде встановлений плагін " UML SupportВін дозволяє автоматично генерувати красиві діаграми класів. Наприклад, через Ctrl+N або пункт меню "Navigate" -> "Class" перейдемо в клас ArrayList. Тепер, через контекстне менюна ім'я класу виберемо "Diagram" -> "Show diagram popup". В результаті ми отримаємо гарну діаграму:

Але що якщо хочеться самому намалювати, та ще й немає Ultimate версії Idea? Якщо ми використовуємо IntelliJ Idea Community Edition, то ми не маємо іншого вибору. Для цього потрібно зрозуміти, як така схема UML влаштована. Для початку нам знадобиться встановити Graphviz. Це набір утиліт для візуалізації графів. Його використовує плагін, який ми будемо застосовувати. Після встановлення необхідно додати каталог binз каталогу встановленого Graphvizу змінну середовища оточення PATH. Після цього IntelliJ Idea в меню вибрати File -> Settings. У вікні "Settings" вибрати категорію "Plugins", натиснути кнопку "Browse repositories" та встановити плагін PlantUML integration. Чим такий гарний цей PlantUML? Він використовує для опису UML мову опису графів під назвою " dot" і це дозволяє бути більш універсальним, т.к. дана мовавикористовується не лише PlantUML. Більш того, все що ми зробимо нижче ми можемо виконати не тільки в IDE, але і в онлайн сервісі planttext.com. Після встановлення плагіна PlantUML у нас з'явиться можливість через "File" -> "New" створювати UML діаграми. Давайте виконаємо створення діаграми типу "UML class". У результаті автоматично генерується шаблон з прикладом. Видалимо його вміст і створимо свій, озброївшись статтею з Хабра: Відносини класів - від UML до коду. А щоб зрозуміти, як це зобразити в тексті, візьмемо мануал PlantUML: plantuml class-diagram . У ньому на самому початку представлена ​​табличка про те, як потрібно описувати зв'язки:

Про самі зв'язки можемо ще підглядати сюди: "Відносини між класами в UML. Приклади ". На основі цих матеріалів приступимо до створення нашої UML діаграми. Додамо наступний вміст, що описує два класи: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Щоб побачити результат в Idea, виберемо "View" -> " Tool WindowsМи отримаємо просто два квадрати, що позначають класи. Як ми знаємо, обидва ці класи реалізують інтерфейс List. Дане відношеннякласів так і називають – реалізація (realization). Для зображення такого зв'язку використовують стрілку з пунктирною лінією. Зобразимо її: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package privateмасив елементів: ~ Object elementData Тепер ми хочемо показати, що ArrayList містить якісь об'єкти. В даному випадку буде тип зв'язку - агрегація(Aggregation). Агрегатом у разі є ArrayList , т.к. він містить інші об'єкти. Агрегацію ми вибираємо тому, що об'єкти у списку можуть жити без списку: вони не є його невід'ємними частинами. Їхній час життя не прив'язаний до часу життя списку. Агрегат з латинського перекладається як "зібраний", тобто щось складене з чогось. Наприклад, у житті є насосний агрегат, який складається з насоса та двигуна. Сам агрегат можна розібрати, залишивши щось із його складових частин. Наприклад, щоб продати чи поставити в інший агрегат. Так і у списку. І це виражається у вигляді порожнього ромбика біля агрегату і безперервної лінії. Зобразимо це так: class Object ( ) ArrayList o- Object Тепер ми хочемо показати, що на відміну від ArrayList , клас LinkedList містить у собі Node - контейнери, що посилаються на дані, що зберігаються. В даному випадку Node є частиною самого LinkedList і не можуть жити окремо. Node не є безпосередньо збереженим вмістом, а лише містить посилання на нього. Наприклад, коли ми додаємо до LinkedList якийсь рядок, ми додаємо новий Node , який містить посилання на цей рядок, а також посилання на попередній і наступний Node . Такий тип зв'язку називається композицією(Composition). Для відображення у композита (того, хто складається з частин) малюється забарвлений робмик, до нього веде безперервна лінія. Запишемо тепер це у вигляді текстового відображення зв'язку: class Node ( ) LinkedList * -- Node І тепер необхідно навчитися відображати ще один важливий тип зв'язку - залежність(dependency relationship). Він використовується тоді, коли один клас використовує інший, при цьому клас не містить клас, що використовується, і не є його спадкоємцем. Наприклад, LinkedList і ArrayList вміють створювати ListIterator. Відобразимо це у вигляді стрілок з пунктирною лінією: ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Деталізувати можна настільки, наскільки це потрібно. Всі позначення вказані тут: "PlantUML - діаграма класів". Крім того, у малюванні такої схеми немає нічого надприродного, і під час роботи над своїми завданнями її можна швидко малювати від руки. Це дозволить розвинути навички продумування архітектури програми та допоможе виявити недоліки структури класів на ранньому етапі, а не коли ви вже витратите день на реалізацію неправильної моделі. Мені здається, це непогана причина для того, щоб спробувати?

Автоматизація

Є різні способи автоматичної генерації PlantUML діаграм. Наприклад, в Ideaє плагін SketchIT, але малює він їх не зовсім правильно. Скажімо, неправильно малюється імплементація інтерфейсів (відображається як спадкування). Також в інтернеті є приклади того, як це вбудувати у життєвий цикл складання вашого проекту. Допустимо, для Mavenє приклад використання uml-java-docklet. Для того, щоб показати як це, скористаємося Maven Archetype для швидкого створення Maven проекту. Виконаємо команду: mvn archetype:generate На питанні вибору фільтра ( Choose a number or apply filter) залишаємо default, просто натиснувши Enter. Це завжди буде maven-archetype-quickstartДалі відповідаємо на запитання і завершуємо створення проекту:

Оскільки Maven не є метою цієї статті, відповіді на свої запитання щодо Maven можна знайти в Maven Users Centre . У створеному проекті відкриємо на редагування файл опису проекту, pom.xml. У нього скопіюємо вміст із опису uml-java-docklet installing. Артефакт, що використовується в описі, не вдалося знайти в репозиторії Maven Central. Але у мене запрацювало з цим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Тобто треба в тому описі просто замінити groupIdз " info.leadinglight"на" com.chfourie" і поставити версію " 1.0.0 Після цього можемо виконати в каталозі, де знаходиться файл pom.xmlці команди: mvn clean install та mvn javadoc:javadoc . Тепер, якщо відкрити згенеровану документацію (explorer targetsiteapidocsindex.html), ми побачимо UML схеми. До речі, імплементація тут вже відображається правильно)

Висновок

Як видно, UML дозволяє візуалізувати структуру вашої програми. Крім того, UML не обмежується лише цим. За допомогою UML можна описувати різні процеси всередині вашої компанії або описувати бізнес-процес, в рамках якого працює функція, яку ви пишете. Наскільки UML корисний особисто для вас - вирішувати вам, але знайти час і ознайомитися докладніше буде в будь-якому випадку корисно. #Viacheslav English version of this post: UML diagram Java на CodeGym

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

Комерційні продукти

Microsoft Visio

Тип: комерційне ПЗ

Популярний програмний продуктвід компанії Microsoft, яка дозволяє малювати багаті діаграми, у тому числі UML:

Починаючи з 2010 версії з'явилася можливість публікувати діаграми в Інтернеті (SharePoint + Visio Services):

Visio Viewer- безкоштовна програмаяка дозволяє переглядати створені раніше Visio діаграми. Завантажити можна по %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/ru-ua/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Можливості:

• Use case diagram (діаграми прецедентів);
• Deployment diagram (діаграми топології);
• Statechart diagram (діаграми станів);
• Activity diagram (діаграми активності);
• Interaction diagram (діаграми взаємодії);
• Sequence diagram (діаграми послідовностей дій);
• Collaboration diagram (діаграми співробітництва);
• Class diagram (діаграми класів);
• Component diagram (діаграми компонент).

Скріншоти:

Open source програми

StarUML

Можливості:

• підтримка UML 2.0
• MDA (Model Driven Architecture)
• Plug-in Architecture (писати можна на COM сумісних мовах: C++, Delphi, C#, VB, ...)

StarUML написана в основному на Delphi, але дописувати компоненти можна і іншими мовами, наприклад C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C #, VB.NET. Нижче показано кілька скріншотів.

Діаграма класів:

Use case діаграма:

ArgoUML

Підтримувані діаграми:

• Class
• State
• Use case
• Activity
• Collaboration
• Deployment
• Sequence

Можливості:

• Підтримка дев'яти UML 1.4 діаграм
• Платформонезалежна (Java 5+)
• Стандартна метамодель UML 1.4
• Підтримка XMI
• Експорт в GIF, PNG, PS, EPS, PGML та SVG
• Мови: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Підтримка OCL
• Forward, Reverse Engineering

Скріншот:

10.4. ДІАГРАМИ UML

10.4.1. Типи візуальних діаграм UML

UML дозволяє створювати кілька типів візуальних діаграм:

діаграми варіантів використання;

Діаграми послідовності;

Кооперативні діаграми;

діаграми класів;

діаграми станів;

діаграми компонент;

Діаграма розміщення.

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

10.4.2. Діаграми варіантів використання

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

Мал. 10.1.Діаграма варіантів використання

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

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

10.4.3. Діаграми послідовності

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

10.2.Діаграма послідовності зняття клієнтом Джо $20 з рахунку

У верхній частині діаграми показані всі дійові особи та об'єкти, необхідні системі для виконання варіанта використання "Зняти гроші". Стрілки відповідають повідомленням, що передаються між дійовою особою та об'єктом або між об'єктами для виконання потрібних функцій. Слід зазначити також, що у діаграмі послідовності показані саме об'єкти, а чи не класи. Класи є типами об'єктів. Об'єкти є конкретними; замість класу КлієнтНа діаграмі послідовності представлений конкретний клієнт Джо.

Варіант використання починається, коли клієнт вставляє свою картку в пристрій для читання – цей об'єкт показаний у прямокутнику у верхній частині діаграми. Він зчитує номер картки, відкриває об'єкт "рахунок Джо" та ініціалізує екран ATM. Екран запитує Джо його реєстраційний номер. Клієнт вводить число 1234. Екран перевіряє номер об'єкта "рахунок Джо" і виявляє, що він правильний. Потім екран надає Джо меню для вибору і той вибирає пункт "Зняти гроші". Екран запитує скільки він хоче зняти, і Джо вказує $20. Екран знімає гроші з рахунку. При цьому він ініціює серію процесів, які виконує об'єкт "рахунок Джо". У той самий час здійснюється перевірка, що у цьому рахунку лежать, по крайнього заходу, $20 і з рахунку віднімається необхідна сума. Потім касовий апарат отримує інструкцію "видати чек і $20 готівкою". Нарешті, той самий об'єкт " рахунок Джо " дає пристрою для читання карток інструкцію повернути картку.

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

10.4.4. Кооперативні діаграми

Кооперативні діаграми відображають ту саму інформацію, що і діаграми послідовності. Однак справи, ють вони це по-іншому та з іншими цілями. Показана на рис. 10.2 діаграма послідовності представлена ​​на рис. 10.3 як кооперативної діаграми.

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

Мал. 10.3.Кооперативна діаграма, що описує процес зняття грошей з рахунку

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

10.4.5. Діаграми класів

Діаграми класів відбивають взаємодію між класами системи. Наприклад, "рахунок Джо" - це об'єкт. Типом такого об'єкта вважатимуться рахунок взагалі, т. е. " Рахунок " - це клас. Класи містять дані та поведінку (дії), що впливає на ці дані. Так, клас Рахунок містить ідентифікаційний номер клієнта та дії, що перевіряють. На діаграмі класів клас створюється для кожного типу об'єктів із діаграм послідовності або кооперативних діаграм. Діаграма класів для варіанта використання "Зняти гроші" показано на рис. 10.4.

На діаграмі показані зв'язки між класами, що реалізують варіант використання Зняти гроші. У цьому процесі задіяні чотири класи: Card Reader(пристрій для читання карток), Account (рахунок), ATM (екран ATM) та Cash Dispenser (касовий апарат). Кожен клас на діаграмі класів зображується у вигляді прямокутника, розділеного на три частини. У першій частині вказується ім'я класу, у другій – його атрибути.Атрибут – це деяка інформація, що характеризує клас. Наприклад, клас Account (рахунок) має три атрибути: Account Number (номер рахунку), PIN (ідентифікаційний номер) та Balance (баланс). В останній частині містяться операції класу, що відбивають його поведінка(Дії, що виконуються класом). Сполучні класи лінії показують взаємодію між класами.

Мал. 10.4.Діаграма класів

Розробники використовують діаграми класів для створення класів. Такі інструменти, як Rose, генерують основу коду класів, яку програмісти заповнюють деталями обраною ними мовою. За допомогою цих діаграм аналітики можуть показати деталі системи, а архітектори – зрозуміти її проект. Якщо, наприклад, якийсь клас несе надто велике функціональне навантаження, це буде видно на діаграмі класів, і архітектор зможе перерозподілити її між іншими класами. За допомогою діаграми можна виявити випадки, коли між сполученими класами не визначено жодних зв'язків. p align="justify"> Діаграми класів слід створювати, щоб показати взаємодіючі класи в кожному варіанті використання. Можна будувати також більше загальні діаграми, що охоплюють усі системи чи підсистеми.

10.4.6. Діаграми станів

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

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

Мал. 10.5.Діаграма станів для класу Account

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

Коли клієнт знімає гроші з відкритого рахунку, рахунок може перейти у стан "Перевищення кредиту". Це відбувається, тільки якщо баланс по рахунку менший за нуль, що відображено умовою [негативний баланс] на нашій діаграмі. Укладене у квадратні дужки умовавизначає, коли може або не може статися перехід із одного стану в інший.

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

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

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

Діаграми станів необхідні в основному для документування.

10.4.7. Діаграми компонент

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

На рис. 10.6 зображено одну з діаграм компонент для системи ATM. На цій діаграмі показано компоненти клієнта системи ATM. У разі команда розробників вирішила будувати систему з допомогою мови C++. Кожен клас має свій власний заголовковий файл і файл з розширенням. СРР, так що кожен клас перетворюється на власні компоненти на діаграмі. Виділена темна компонента називається специфікацією пакетуі відповідає файлу тіла класу ATM мовою C++ (файл із розширенням. СРР). Невиділена компонента також називається специфікацією пакета, але відповідає заголовному файлу класу мови C++ (файл з розширенням. Н). Компоненти АТМ. ехе є специфікацією завдання та представляє потік обробки інформації. У разі потік обробки - це виконувана програма.

Компоненти з'єднані штриховою лінією, що відображає залежність між ними. Система може мати кілька діаграм компонентів залежно від кількості підсистем або виконуваних файлів. p align="justify"> Кожна підсистема є пакетом компонент.

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

Мал. 10.6.Діаграма компонент

10.4.8. Діаграми розміщення

Діаграми розміщення показують фізичне розташування різних компонентів системи в мережі. У прикладі система ATM складається з великої кількості підсистем, виконуваних на окремих фізичних пристроях чи вузлах. Діаграма розміщення системи ATM представлена ​​на рис. 10.7.

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

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

10.7. Діаграма розміщення

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

Із книги Microsoft Office автора Леонтьєв Віталій Петрович

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

З книги Комп'ютер на 100. Починаємо з Windows Vista автора Зозуля Юрій

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

З книги Ефективне діловодство автора Пташинський Володимир Сергійович

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

З книги Excel. Мультимедійний курс автора Медінов Олег

Розділ 8 Діаграми Часто програму Excelвикористовують для створення документів, що становлять різні статистичні та аналітичні звіти. Це можуть бути звіти про продаж, таблиці вимірів температури повітря, дані соціологічних опитувань тощо. Цифри не завжди

З книги Word 2007. Популярний самовчитель автора Країнський І

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

З книги Самовчитель роботи на комп'ютері автора Колісниченко Денис Миколайович

6.6. Діаграми Крім графічних файлів, в документи Word можна вставляти діаграми. За допомогою діаграм можна наочно уявити числові дані, наприклад, простежити, як змінюються дані, побачити розвиток того чи іншого проекту в динаміці. Діаграми перетворюють схожі

З книги Об'єктно-орієнтований аналіз та проектування з прикладами додатків на С++ автора Буч Граді

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

З книги Технології програмування автора Камаєв В А

5.2. Діаграми класів Істотне: класи та відносини між ними Діаграма класів показує класи та їх стосунки, тим самим представляючи логічний аспект проекту. Окрема діаграма класів представляє певний ракурс структури класів. На стадії аналізу ми

З книги Моделювання бізнес-процесів із BPwin 4.0 автора Маклаков Сергій Володимирович

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

З книги OrCAD PSpice. Аналіз електричних ланцюгів автора Кеоун Дж.

5.7. Діаграми процесів. Істотне: процесори, пристрої та з'єднання Діаграми процесів використовуються, щоб показати розподіл процесів за процесорами у фізичному проекті системи. Окрема діаграма процесів показує один ракурс структури процесів

З книги VBA для чайників автора Каммінгс Стів

10.4. ДІАГРАМИ UML 10.4.1. Типи візуальних діаграм UMLUML дозволяє створювати кілька типів візуальних діаграм: діаграми варіантів використання; діаграми послідовності; кооперативні діаграми; діаграми класів; діаграми станів; діаграми

З книги Самовчитель роботи на Macintosh автора Скрилина Софія

1.2.6. Каркас діаграми На рис. 1.2.26 показано типовий приклад діаграми декомпозиції з граничними рамками, які називаються каркасом діаграми. Мал. 1.2.26. Приклад діаграми декомпозиції з каркасом Каркас містить заголовок (верхня частина рамки) та підвал (нижня частина).

З книги автора

Тимчасові діаграми Щоб отримати часові діаграми вхідної та вихідної напруги, необхідно трохи змінити вхідний файл. Як і в попередньому прикладі, буде використано синусоїдальну вхідну напругу: Vi 1 0 sin (0 0. 5V 5kHz) Поряд з аналізом перехідних процесів

З книги автора

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

З книги автора

5.1.14. Діаграми Діаграм - графічне уявлення числових даних таблиці. Pages пропонує кілька видів діаграм: Column (Стовпцева), Stacked Column (Багатоярусні стовпці), Ваг (Гістограма), Stacked Ваг (Багатоярусна гістограма), Line (Лінійна), Area (Площа), Stacked Area (Багатоярусна)

З книги автора

5.2.8. Діаграми Діаграма - графічне представлення даних із вибраного діапазону. Для побудови діаграми дотримуйтесь наступного алгоритму1. Створити таблицю розрахункових значень.2. Виділити потрібний діапазон (він може складатися з не суміжних прямокутних