https://wiki.welard.com/api.php?action=feedcontributions&feedformat=atom&user=Sergiy 2026-10-22T14:45:24Z Внесок користувача MediaWiki 1.34.1 https://wiki.welard.com/index.php?title=Iot-problems&diff=2717 2022-09-09T20:28:04Z

<p>Sergiy: </p> <hr /> <div>== '''Проблеми технологій Інтернету речей (Internet of things, IoT).''' ==<br /> <br /> <br /> Інтернет речей (англ. Internet of Things, IoT) – це мережа, що складається із взаємозв’язаних фізичних об’єктів або пристроїв, які мають вбудовані сенсори, а також програмне забезпечення, що дає змогу здійснювати передавання і обмін даними між фізичним світом і комп’ютерними системами за допомогою використання стандартних протоколів зв’язку. Крім сенсорів, мережа може мати виконавчі пристрої, вбудовані у фізичні об’єкти і пов’язані між собою через дротові й без дротові мережі. Ці взаємопов’язані об’єкти мають можливість зчитування та приведення в дію функції програмування та ідентифікації, а також дають змогу обійтись без участі людини за рахунок використання інтелектуальних інтерфейсів.<br /> <br /> <br /> Інтернет речей передбачає підключення до глобальної комп’ютерної мережі побутових предметів за допомогою вбудованих модулів зв’язку, завдяки чому вони отримують можливість взаємодіяти один з одним, із зовнішнім середовищем, обмінюватися даними і здійснювати операції без участі людини. Сенсори консолідують дані в режимі реального часу і мають можливість прямої інтеграції і з баз даних і сховищами даних та ERP-системами тощо. <br /> <br /> Всі ці впроваджені нововведення додають серйозних проблем, що пов'язані з '''інформаційною безпекою'''.<br /> <br /> <br /> '''Безпека IoT стала одним з найважливіших аспектів нових технологій'''. Можливо здасться, що не існує ризику для даних, що передаються і зберігаються такими системами, вони не є вразливими, але реальність така, що IoT пристрої, які не мають належного захисту, піддаються атакам, які вже інфіковані шкідливим кодом для створення ботнету.<br /> <br /> <br /> == '''Основні уразливості''' ==<br /> <br /> Порушення конфіденційності традиційних мереж зв'язку (повтори, підслуховування, спотворення інформації і т. д.). <br /> <br /> Велику загрозу несе керування пристроїв за допомогою міжмашинної взаємодії. Жодну написану людиною програму не можна вважати стовідсотково точною; для неї пишуться різні патчі для виправлення помилок. Така ж доля чекає датчики в інтернет-пристроях. Із посиленням ролі даних пристроїв в житті людей буде збільшуватися загроза безпеці всіх даних, навіть найнезначніших на перший погляд. Необхідно оцінювати будь-який витік інформації, так як резюмування її складових може представляти небезпеку для життя як фізичних, так і юридичних осіб (найбільших компаній).<br /> <br /> У такому разі ще виявляється важливим захищати критично важливу інфраструктуру, таку як мережа електропередачі. Необхідно підготувати базу для несподіваного аварійного випадку, а також вибрати правильне співвідношення для відкритості та вбудованої надмірності.<br /> <br /> Одним з '''найбільш небезпечних напрямків атаки''', на які варто звернути увагу, є '''DDoS-атака'''. Їх мета представляє з себе захоплення системних ресурсів і утруднення доступу до них інших користувачів. Так 21 жовтня 2016 року в США була здійснена серія DDoS-атак, яка призвела до глобального порушення інтернет-трафіку. Оскільки вона була спрямована на систему доменних імен (DNS), яка отримує інформацію про домени, повсякденні активності, такі як соціальні мережі або онлайн покупки, стали недоступні на деякий час. Основні інформаційні потоки зловмисників були спрямовані на сервери компанії Dyn, яка є головним постачальником DNS-послуг для таких найбільших компаній, як Twitter, Pinterest, Reddit, GitHub, Etsy, Tumblr, Spotify, PayPal і Verizon. Здійснення таких атак стало можливим завдяки підключенню до незахищених цифрових пристроїв: Маршрутизаторів і камер відеоспостереження. Хоч вони і не є потужними комп'ютерами, але здатні генерувати величезні обсяги паразитичної інформації для серверів, особливо при одночасному підключенні.<br /> <br /> <br /> Сучасна концепція Інтернету речей передбачає комунікацію об’єктів, які використовують технології для<br /> взаємодії між собою та з навколишнім середовищем. Частина мережних протоколів адаптовані для використання в<br /> IoT і їх можна описати як складову TCP/IP моделі. Тому вразливості цих протоколів можна використовувати і для<br /> зламу систем, які використовують Інтернет речей. Зловмисник може атакувати мережне обладнання, що<br /> використовується в системі. Серед компонентів розумного дому та охоронних систем значна частина має проблеми<br /> з безпекою, які характерні для цілого ряду пристроїв, а не просто для певної серії ненадійного виробника.<br /> Розглянемо масові грубі порушення принципів розробки: використання незмінних (hardcoded) та прихованих<br /> сервісних облікових записів; застосування однакових або легко передбачуваних паролів та ПІН-кодів; відсутність<br /> перевірки прав доступу при звернені до відомої сторінки налаштувань або прямого виклику зображень та<br /> відеопотоку IP-камер; некоректна обробка отримуваних даних, що викликає переповнення буферу. Як наслідок,<br /> можна отримати виконання довільного коду при отримані попередньо складеного TCP-пакету; примусове<br /> переключення серверу на використання старих версій протоколів за запитом клієнтського пристрою; та інші типові<br /> помилки, які спрощують конфігурування пристроїв неспеціалістами, що в свою чергу послаблює параметри<br /> безпеки в цілому (в тому числі – віддаленого та без належної авторизації). З прикладів використання вразливостей<br /> систем IoT можна навести DNS rebinding, DoS/DDoS-атаки, ботнети, концепція Man-in-The-Middle та інші.<br /> <br /> <br /> Уже сьогодні спеціалісти працюють над усуненням вразливостей в розумних пристроях. Для підвищення<br /> якості написання програмного забезпечення для даних пристроїв необхідно підняти питання сертифікації. За умов<br /> мінімальної бюрократії та надання користувачам гарантії, що продукт достатньо захищений від хакерських атак,<br /> рівень довіри до виробника значно зросте. Питанням сертифікації займаються приватні компанії. Зокрема компанія<br /> Online Trust Alliance (OTA) випустила IoT Trust Framework – ряд критеріїв для розробників, постачальників послуг,<br /> який направлений на покращення безпеки, конфіденційності та життєвого циклу їх IoT-продуктів<br /> <br /> <br /> Компанія Verizon запустила програму тестування безпеки та сертифікації IoT-пристроїв. Як стверджують її<br /> розробники, вона являється однією з перших в своєму роді, і тестує такі складові як сповіщення/протоколювання,<br /> криптографія, аутентифікації, зв’язок, фізична безпека та безпека платформи. Пристрої, що пройшли сертифікацію,<br /> будуть відмічені знаком схвалення ICSA Labs та буде вказувати, що вони були протестовані, а знайдені<br /> вразливості були усунені. Також пристроїв, що пройшли сертифікацію будуть знаходитись під наглядом і<br /> періодично тестуватись протягом їх життєвого циклу для збереження безпеки. Інтернет речей стала однією з<br /> перших сфер, в якій використовується блокчейн-технологія. Наприклад, управління аутентифікацією, перевірка<br /> роботоспроможності різних сервісів та ін. Ряд компаній, як Cisco, BNY Mellon, Bosch, Foxconn та ряд інших<br /> організували консорціум, який буде знаходити рішення з використання блокчейну для збільшення безпеки і<br /> покращення взаємодії IoT-продуктів.<br /> <br /> <br /> Отже, довіра користувачів до інтернету речей залежить від реалізації безпеки в ньому, тому саме питання її<br /> забезпечення має бути ключовим для виробників. Позитивним є об’єднання компаній заради створення стандартів<br /> та реалізації різних концепцій для підтримки цієї технології та її популяризації.<br /> <br /> [https://conf.ztu.edu.ua/wp-content/uploads/2019/02/115-1.pdf Джерело]<br /> <br /> <br /> == '''Статистичні дані''' ==<br /> <br /> <br /> У січні 2014 року в журналі '''Forbes''' кібержурналіст Джозеф Стейнберг (англ. Joseph Steinberg) '''опублікував список''' пов'язаних із '''Інтернетом приладів''', '''які «шпигують» за нами буквально в наших будинках'''. До них належать '''телевізори, кухонна техніка, камери'''. Дуже '''ненадійна комп'ютерна система автомобілів''', яка '''контролює гальма, двигун, замки, капот, вентиляцію і приладову панель'''; '''ці частини системи найбільш уразливі для зловмисників''' під час спроби отримання доступу до бортової мережі. Також '''атака може бути проведена віддалено по Інтернету'''. <br /> <br /> Хакерами була продемонстрована можливість дистанційного керування електрокардіостимуляторами. Пізніше вони навчилися отримувати доступ до інсулінових помп й імплантованих кардіо-дефібриляторам.<br /> <br /> <br /> Компанія Hewlett Packard провела масштабне дослідження в 2015 році, в якому повідомляється, що '''70 % пристроїв IoT мають вразливості своїх паролів''', існують '''проблеми з шифруванням даних та з дозволами для доступу''', і 50 % додатків для мобільних пристроїв не обмінюються даними.<br /> <br /> '''Лабораторія Касперського''' — компанія, що спеціалізується на виробництві програмного забезпечення для захисту інформації, '''провела випробування на об'єктах, підключених до IoT''', і виявила, що '''відеоняні можуть бути зламані для перехоплення відео''' та '''кавомашини''', які '''передають інформацію в незашифрованому вигляді''', можуть зберігати '''пароль мережі Wi-Fi''', до якої були приєднані.<br /> <br /> <br /> <br /> <br /> <br /> Так, на самому початку експлуатації<br /> користувачеві обов'язково потрібно замінити фабричний пароль, встановлений за<br /> замовчуванням, на свій особистий, оскільки фабричні паролі однакові на всіх пристроях і не<br /> відрізняються стійкістю. На жаль, роблять це далеко не всі. Оскільки не всі прилади мають<br /> вбудовані засоби ІБ-захисту, власникам також слід подбати про встановлення зовнішнього<br /> захисту, призначеної для домашнього використання, з тим щоб інтернет-пристрою не стали<br /> відкритими шлюзами в домашню мережу або прямими інструментами заподіяння шкоди.<br /> В ході проведеного HP дослідження виявлено, що приблизно в 70% проаналізованих<br /> пристроїв не шифрується бездротової трафік. Веб-інтрефейс 60% пристроїв експерти HP<br /> порахували небезпечним через небезпечну організацію доступу і високих ризиків<br /> міжсайтового скриптинга. У більшості пристроїв передбачені паролі недостатньою стійкості.<br /> Приблизно 90% пристроїв збирають ту чи іншу персональну інформацію про власника без<br /> його відома.<br /> Всього ж фахівці HP нарахували близько 25 різних вразливостей в кожному з<br /> досліджених пристроїв (телевізорів, дверних замків, побутових ваг, домашніх охоронних<br /> систем, електророзеток ...) і їх мобільних і хмарних компонентах.<br /> Висновок експертів HP невтішний: безпечної екосистеми IoT на сьогоднішній день не<br /> існує. Особливу небезпеку речі Інтернету таять в собі в контексті поширення цільових атак<br /> (APT). Варто тільки зловмисникам проявити інтерес до будь-кого з нас, і наші вірні<br /> помічники зі світу IoT перетворюються в зрадників, нарозхрист відкривають доступ в світ<br /> своїх власників.<br /> <br /> <br /> == '''Слабкі місця IoT:''' ==<br /> <br /> * перехід на IPv6;<br /> * живлення датчиків;<br /> * стандартизація архітектури і протоколів, сертифікація пристроїв.<br /> * інформаційна безпека;<br /> * стандартні облікові записи від виробника, слабка аутентифікація;<br /> * відсутність підтримки з боку виробника для усунення вразливостей<br /> * важко або неможливо оновити ПЗ і ОС;<br /> * використання текстових протоколів і непотрібних відкритих портів;<br /> * використовуючи слабкість одного гаджета, хакеру легко потрапити у всю мережу;<br /> * використання незахищених мобільних технологій;<br /> * використання незахищеною хмарної інфраструктури;<br /> * використання небезпечного ПЗ.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2679 2022-09-09T14:24:32Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0 - функціональні моделі, засновані на методі SADT;'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> '''IDEF1X - діаграми даних &quot;сутність-зв'язок&quot; (ERD);'''<br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3 - діаграми потоків робіт (Work Flow Diagrams);'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2676 2022-09-09T14:21:43Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> '''IDEF0 - функціональні моделі, засновані на методі SADT;'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> '''IDEF1X'''<br /> <br /> '''IDEF1X - діаграми даних &quot;сутність-зв'язок&quot; (ERD);'''<br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> '''IDEF3 - діаграми потоків робіт (Work Flow Diagrams);'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2674 2022-09-09T14:21:02Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> '''IDEF1X'''<br /> <br /> '''IDEF1X - діаграми даних &quot;сутність-зв'язок&quot; (ERD);'''<br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> '''IDEF3 - діаграми потоків робіт (Work Flow Diagrams);'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2672 2022-09-09T14:20:03Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> '''IDEF1X'''<br /> <br /> IDEF1X - діаграми даних &quot;сутність-зв'язок&quot; (ERD);<br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> '''IDEF1X (IDEF1 Extended)''' – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> IDEF3 - діаграми потоків робіт (Work Flow Diagrams);<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2671 2022-09-09T14:19:32Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> '''IDEF1X'''<br /> <br /> IDEF1X - діаграми даних &quot;сутність-зв'язок&quot; (ERD);<br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> '''IDEF1X (IDEF1 Extended)''' – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> IDEF3 - діаграми потоків робіт (Work Flow Diagrams);<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2670 2022-09-09T14:11:06Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2669 2022-09-09T14:10:43Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Завдання UML.''' ==<br /> <br /> Мова UML призначена для рішення наступних завдань:<br /> <br /> 1. надати в розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє розробляти осмислені моделі й обмінюватися ними;<br /> <br /> 2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;<br /> <br /> 3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;<br /> <br /> 4. забезпечити формальну основу для однозначної інтерпретації мови;<br /> <br /> 5. стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;<br /> <br /> 6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.<br /> <br /> У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.<br /> <br /> <br /> <br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2668 2022-09-09T14:00:45Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію '''IDEF1X'''. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF2'''<br /> <br /> Simulation Model Design – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Нині присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням «розфарбованих мереж Петрі» (CPN — Color Petri Nets);<br /> <br /> <br /> '''IDEF3'''<br /> <br /> Process Description Capture (Документування технологічних процесів) — методологія документування процесів, які у системі (наприклад, для підприємства), описує сценарій і послідовність операцій кожному за процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2667 2022-09-09T13:55:46Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> Information Modeling — методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки.<br /> <br /> IDEF1X (IDEF1 Extended) – Data Modeling – методологія моделювання баз даних на основі моделі «сутність-зв'язок». Застосовується для побудови інформаційної моделі, що представляє структуру інформації, необхідної підтримки функцій виробничої системи чи середовища. Метод IDEF1, розроблений Т. Реймі (T. Ramey) на основі підходів П. Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її нову версію — методологію IDEF1X. Вона розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF0''' - Нотація для документування процесів виробництва та відображення інформації про використання ресурсів на кожному з етапів проектування систем<br /> <br /> '''IDEF1''' - Нотація для документування інформації про виробниче оточення систем<br /> <br /> '''IDEF2''' - Нотація для документування поведінки системи в часі.<br /> <br /> '''IDEF3''' - Нотація спеціально для моделювання бізнес-процесів<br /> <br /> <br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2666 2022-09-09T13:45:07Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) '''для вирішення завдань моделювання складних систем''', що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> IDEF-методології створювалися у межах запропонованої ВПС США програми комп'ютеризації промисловості — ICAM, під час реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії виробничих (промислових) системах. <br /> Принциповою вимогою при розробці аналізованого сімейства методологій була '''можливість ефективного обміну інформацією між усіма фахівцями''' – учасниками програми ICAM (звідси назва: Icam DEFinition – IDEF; інший варіант – Integrated DEFinition). Після опублікування стандарту він був успішно застосований у різних галузях бізнесу, показавши себе ефективним засобом аналізу, конструювання та відображення бізнес-процесів. Понад те, що з широким застосуванням IDEF (і попередньої методології — SADT) пов'язано виникнення основних ідей популярного нині поняття BPR (бізнес-процес реінжиніринг).<br /> <br /> <br /> '''IDEF0'''<br /> <br /> Function Modeling (Моделювання бізнес-процесу) – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків — у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Technique);<br /> <br /> <br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF0''' - Нотація для документування процесів виробництва та відображення інформації про використання ресурсів на кожному з етапів проектування систем<br /> <br /> '''IDEF1''' - Нотація для документування інформації про виробниче оточення систем<br /> <br /> '''IDEF2''' - Нотація для документування поведінки системи в часі.<br /> <br /> '''IDEF3''' - Нотація спеціально для моделювання бізнес-процесів<br /> <br /> <br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2665 2022-09-09T13:35:43Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' ==<br /> <br /> <br /> '''IDEF (I-CAM DEFinition або Integrated DEFinition)''' — методологія сімейства ICAM (Integrated Computer-Aided Manufacturing) для вирішення завдань моделювання складних систем, що дозволяють відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF0''' - Нотація для документування процесів виробництва та відображення інформації про використання ресурсів на кожному з етапів проектування систем<br /> <br /> '''IDEF1''' - Нотація для документування інформації про виробниче оточення систем<br /> <br /> '''IDEF2''' - Нотація для документування поведінки системи в часі.<br /> <br /> '''IDEF3''' - Нотація спеціально для моделювання бізнес-процесів<br /> <br /> <br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2664 2022-09-09T13:25:14Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF0''' - Нотація для документування процесів виробництва та відображення інформації про використання ресурсів на кожному з етапів проектування систем<br /> <br /> '''IDEF1''' - Нотація для документування інформації про виробниче оточення систем<br /> <br /> '''IDEF2''' - Нотація для документування поведінки системи в часі.<br /> <br /> '''IDEF3''' - Нотація спеціально для моделювання бізнес-процесів<br /> <br /> <br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2663 2022-09-09T13:23:55Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1''' - Нотація для документування інформації про виробниче оточення систем<br /> <br /> '''IDEF2''' - Нотація для документування поведінки системи в часі.<br /> <br /> '''IDEF3''' - Нотація спеціально для моделювання бізнес-процесів<br /> <br /> <br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2662 2022-09-09T13:20:12Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> <br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2661 2022-09-09T13:20:00Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML - це мова, призначена для '''візуалізації''', '''спеціфікації''', '''конструювання''' й '''документування програмних систем'''. Слово «уніфікований» у назві мови означає, що UML може використовуватися для моделювання широкого кола додатків від вбудованих систем і систем реального часу до розподілених web-додатків. Виразні засоби мови дозволяють описати систему зі всіх точок зору, що мають відношення до розробки й розгортання.<br /> <br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2660 2022-09-09T13:07:28Z

<p>Sergiy: </p> <hr /> <div>== '''&lt;big&gt;Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).&lt;/big&gt;''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2659 2022-09-09T13:04:41Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> <br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> <br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> <br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> <br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2658 2022-09-09T13:00:06Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0''' — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> '''IDEF1Х''' — це техніка моделювання правил, даних.<br /> <br /> '''IDEF4''' — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2657 2022-09-09T12:58:38Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> '''Техніки моделювання IDEF (IDEF Modeling Techniques)''' — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.<br /> <br /> <br /> '''IDEF0'''<br /> <br /> IDEF0 — це техніка моделювання робіт. Методологія функціонального моделювання IDEF0 може бути використана не тільки для економічного моделювання, а й для формування вимог до складних технічних систем. Прикладом такого підходу став проєкт, започаткований TARDEC (США) щодо ідентифікації критичних вимог до основного бойового танку НАТО (Main Battle Tank, MBT).<br /> <br /> IDEF1Х — це техніка моделювання правил, даних.<br /> <br /> IDEF4 — мова моделювання об'єктно-орієнтованого проєктування клієнт-серверних систем, що базуються на компонентах.<br /> <br /> IDEF10 — IDEF14<br /> IDEF10 — Implementation Architecture Modeling — моделювання архітектури виконання;<br /> IDEF11 — Information Artifact Modeling - моделювання інформаційних артифактів;<br /> IDEF12 — Organization Modeling — організаційне моделювання;<br /> IDEF13 — Three Schema Mapping Design — трисхемне проєктування перетворення даних.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2656 2022-09-09T12:38:28Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.<br /> <br /> <br /> == '''IDEF''' ==<br /> <br /> <br /> Техніки моделювання IDEF (IDEF Modeling Techniques) — комбінація графічних і мовних символів та правил, розроблених для фіксації процесів і структури інформації в організації.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2655 2022-09-09T12:35:49Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''Діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2654 2022-09-09T12:34:12Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2653 2022-09-09T12:33:53Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> * Підвидом діаграм композитної структури є '''діаграми кооперації''' (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2652 2022-09-09T12:29:17Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> '''Діаграма композитної/складеної структури'''<br /> <br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> '''Діаграма розгортання'''<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> '''Діаграма об'єктів'''<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> '''Діаграма пакетів'''<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2651 2022-09-09T12:18:49Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2650 2022-09-09T12:18:34Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|400*400px|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> <br /> '''Діаграма компонентів'''<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2649 2022-09-09T12:17:21Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|400*400px|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2648 2022-09-09T12:16:59Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|400*400pix|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2647 2022-09-09T12:16:18Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg||центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2646 2022-09-09T12:16:06Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|серед|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2645 2022-09-09T12:15:43Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|мідл|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2644 2022-09-09T12:15:15Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100px*100px|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2643 2022-09-09T12:08:46Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|міні|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2642 2022-09-09T12:08:23Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100px*100px|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2641 2022-09-09T12:07:58Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100*100px|центр]]<br /> <br /> <br /> '''Структурні діаграми'''<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> '''Діаграма профілю'''<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> '''Діаграма класів'''<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2639 2022-09-09T12:02:01Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100*100px|центр]]<br /> <br /> <br /> Структурні діаграми<br /> Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.<br /> <br /> Діаграма профілю<br /> Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.<br /> <br /> Діаграма класів<br /> Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.<br /> <br /> Існують різні точки зору на побудову діаграм класів залежно від цілей їхнього застосування:<br /> <br /> концептуальна точка зору — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів;<br /> точка зору специфікації — діаграма класів застосовується при проектуванні інформаційних систем;<br /> точка зору реалізації — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування).<br /> Діаграма компонентів<br /> Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.<br /> <br /> Діаграма композитної/складеної структури<br /> Файл:Decorator template.png<br /> Decorator template<br /> Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.<br /> <br /> Підвидом діаграм композитної структури є діаграми кооперації (англ. Collaboration diagram, введені в UML 2.0), які показують ролі й взаємодію класів у рамках кооперації. Кооперації є зручними для моделювання шаблонів проектування.<br /> <br /> Діаграми композитної структури можуть використовуватися разом з діаграмами класів.<br /> <br /> Діаграма розгортання<br /> Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.<br /> <br /> Діаграма об'єктів<br /> Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єктів) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.<br /> <br /> Діаграма пакетів<br /> Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2638 2022-09-09T12:00:28Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100*100px|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2637 2022-09-09T12:00:10Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100*100px|право]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2636 2022-09-09T11:59:47Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|100*100px|ліво]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2635 2022-09-09T11:58:26Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|mini|ліво]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2634 2022-09-09T11:58:00Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|mini|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2633 2022-09-09T11:57:40Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|250*250px|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2632 2022-09-09T11:57:18Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|500*500px|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2631 2022-09-09T11:57:01Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|1000*750px|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2630 2022-09-09T11:55:51Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|1000*750|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2629 2022-09-09T11:55:16Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|центр|250*250]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2628 2022-09-09T11:54:51Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|250*250|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2627 2022-09-09T11:54:24Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|500*600|центр]]</div>

Sergiy https://wiki.welard.com/index.php?title=Uml-language&diff=2626 2022-09-09T11:53:10Z

<p>Sergiy: </p> <hr /> <div>== '''Уніфікована мова моделювання програмного забезпечення (UML-Unified Modeling Language) та нотації проектування IDEF (Integrated DEFinition) (IDEF0, IDEF1, IDEF2, IDEF3).''' ==<br /> <br /> <br /> UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування.<br /> UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.<br /> <br /> Перша версія (1.0) UML вийшла 13 січня 1997р., вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних.<br /> <br /> У вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG.<br /> <br /> Поточна версія — 2.0.<br /> <br /> <br /> == '''Застосування''' ==<br /> <br /> <br /> '''UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм.''' Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.<br /> <br /> Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.<br /> <br /> '''Основною причиною використання мови UML є спілкування розробників між собою.'''<br /> <br /> Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.<br /> <br /> UML чудово зарекомендувала себе в багатьох успішних програмних проєктах. '''Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об'єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки.'''<br /> <br /> Практично усі CASE-засоби (програми автоматизації процесу аналізу і проєктування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.<br /> <br /> Діаграми підвищують супроводжуваність проєкту і полегшують розробку документації.<br /> <br /> <br /> UML необхідний:<br /> <br /> * керівникам проєктів, які керують розподілом завдань і контролем за проєктом ;<br /> * проєктувальникам інформаційних систем які розробляють технічні завдання для програмістів;<br /> * бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;<br /> * програмістам які реалізують модулі інформаційної системи.<br /> <br /> При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.<br /> <br /> <br /> == '''Діаграми''' ==<br /> <br /> <br /> В '''UML використовується 14 видів діаграм''' (для уникнення непорозумінь, також наведено англомовні назви):<br /> <br /> <br /> {|<br /> |-<br /> ||<br /> '''Structure Diagrams:'''<br /> * Class diagram<br /> * Component diagram<br /> * Composite structure diagram<br /> ** Collaboration (UML2.0)<br /> * Deployment diagram<br /> * Object diagram<br /> * Package diagram<br /> '''Behavior Diagrams:'''<br /> * Activity diagram<br /> * State Machine diagram<br /> * Use case diagram<br /> * '''Interaction Diagrams:'''<br /> ** Collaboration (UML1.x) / &lt;br/&gt;Communication diagram (UML2.0)<br /> ** Interaction overview diagram (UML2.0)<br /> ** Sequence diagram<br /> ** UML Timing Diagram (UML2.0)<br /> ||<br /> '''Структурні діаграми:'''<br /> * Діаграма класів<br /> * Діаграма компонентів<br /> * Композитної/складеної структури<br /> ** Кооперації (UML2.0)<br /> * Діаграма розгортування<br /> * Діаграма об'єктів<br /> * Діаграма пакетів<br /> '''Діаграми поведінки:'''<br /> * Діаграма діяльності<br /> * Діаграма станів (UML)<br /> * Діаграма прецедентів<br /> '''Діаграми взаємодії:'''<br /> * Діаграма Кооперації (UML1.x) / &lt;br/&gt;Комунікації (UML2.0)<br /> * Огляду взаємодії (UML2.0)<br /> * Діаграма послідовності<br /> * Діаграма Синхронізації (UML2.0)<br /> |}<br /> <br /> [[Файл:UML-diagram.jpg|центр]]</div>

Sergiy