Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

UML



План:


Введення

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


1. Використання

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

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


2. Історія

Історія об'єктно-орієнтованих методів і нотації.

2.1. До UML 1.x

В 1994 Граді Буч і Джеймс Рамбо, що працювали в компанії Rational Software, об'єднали свої зусилля для створення нової мови об'єктно-орієнтованого моделювання. За основу мови вони взяли методи моделювання, розроблені Бучем і Рамбо (Object-Modeling Technique, OMT). OMT був орієнтований на аналіз, а Booch - на проектування програмних систем. У жовтні 1995 була випущена попередня версія 0.8 уніфікованого методу ( англ. Unified Method ). Восени 1995 року до компанії приєднався Rational Івар Якобсон, автор методу Object-Oriented Software Engineering - OOSE. OOSE забезпечував чудові можливості для специфікації бізнес-процесів та аналізу вимог за допомогою сценаріїв використання. OOSE був також інтегрований в уніфікований метод.

На цьому етапі основна роль в організації процесу розробки UML перейшла до консорціуму OMG (Object Management Group). Група розробників в OMG, в яку також входили Буч, Рамбо і Якобсон, випустила специфікації UML версій 0.9 і 0.91 в червні та жовтні 1996.


2.2. UML 1.x

Версія Дата прийняття
1.1 Листопад 1997 [1]
1.3 Березень 2000 [2]
1.4 Вересень 2001 [3]
1.4.2. Липень 2004 [2]
1.5 Березень 2003 [4]
2.0 Липень 2005 [5]
2.1 формально не була прийнята [2]
2.1.1 Серпень 2007 [6]
2.1.2 Листопад 2007 [7]
2.2 Лютий 2009 [8]
2.3 Травень 2010 [9]
2.4 beta 2 Березень 2011 [10]

На хвилі зростаючого інтересу до UML до розробки нових версій мови в рамках консорціуму UML Partners приєдналися такі компанії, як Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments і Unisys. Результатом спільної роботи стала специфікація UML 1.0, що вийшла в січні 1997. У листопаді того ж року за нею пішла версія 1.1, що містила поліпшення нотації, а також деякі розширення семантики.

Наступні релізи UML включали версії 1.3, 1.4 і 1.5, опубліковані, відповідно в червні 1999, вересні 2001 і березні 2003.


2.3. UML 2.x

Формальна специфікація останньої версії UML 2.0 опублікована в серпні 2005. Семантика мови була значно уточнена й розширена для підтримки методології Model Driven Development - MDD (Англ.) . Остання версія UML 2.3 опублікована в травні 2010.

UML 1.4.2 прийнятий в якості міжнародного стандарту ISO / IEC 19501:2005.


3. Діаграми

В UML використовуються наступні види діаграм (для виключення неоднозначності приведені також позначення англійською мовою):

Structure Diagrams:

Behavior Diagrams:

Структурні діаграми:

Діаграми поведінки:

Структуру діаграм UML 2.3 можна представити на діаграмі класів UML:

Uml diagram2.png

3.1. Діаграма класів

Діаграма класів (Class diagram) - статична структурна діаграма, що описує структуру системи, вона демонструє класи системи, їх атрибути, методи і залежності між класами.

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

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

    3.2. Діаграма компонентів

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

    3.3. Діаграма композитної / складовою структури

    Шаблон проектування Декоратор на діаграмі кооперації

    Діаграма композитної / складовою структури (Composite structure diagram) - статична структурна діаграма, демонструє внутрішню структуру класів і, по можливості, взаємодія елементів (частин) внутрішньої структури класу.

    Підвидом діаграм композитної структури є діаграми кооперації (Collaboration diagram, введені в UML 2.0), які показують роль і взаємодія класів у рамках кооперації. Кооперації зручні при моделюванні шаблонів проектування.

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


    3.4. Діаграма розгортання

    Діаграма розгортання (Deployment diagram) - служить для моделювання працюють вузлів (апаратних засобів, англ. node ) І артефактів, розгорнутих на них. В UML 2 на вузлах розгортаються артефакти ( англ. artifact ), У той час як в UML 1 на вузлах розгорталися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, встановлюється залежність маніфестації.


    3.5. Діаграма об'єктів

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

    3.6. Діаграма пакетів

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


    3.7. Діаграма діяльності

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

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

    Аналогом діаграм діяльності є схеми алгоритмів по ГОСТ 19.701-90.


    3.8. Діаграма автомата

    Діаграма автомата (State Machine diagram, діаграма кінцевого автомата, діаграма станів) - діаграма, на якій представлений кінцевий автомат з простими станами, переходами і композитними станами.

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


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

    Діаграма варіантів використання (Use case diagram) - діаграма, на якій відображені відносини, що існують між акторами і варіантами використання.

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


    3.10. Діаграми комунікації та послідовності

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

    Діаграма комунікації (Communication diagram, в UML 1.x - діаграма кооперації, collaboration diagram) - діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

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

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

    Через те, що діаграми Sequence і Collaboration є різними поглядами на одні й ті ж процеси, Rational Rose дозволяє створювати з Sequence діаграми діаграму Collaboration і навпаки, а також проводить автоматичну синхронізацію цих діаграм.


    3.11. Діаграма огляду взаємодії

    Діаграма огляду взаємодії (Interaction overview diagram) - різновид діаграми діяльності, що включає фрагменти діаграми послідовності та конструкції потоку керування.

    Цей тип діаграм включає в себе діаграми Sequence diagram (діаграми послідовностей дій) і Collaboration diagram (діаграми співробітництва). Ці діаграми дозволяють з різних точок зору розглянути взаємодія об'єктів в створюваній системі.

    3.12. Діаграма синхронізації

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


    4. Переваги UML

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

    5. Критика

    Незважаючи на те, що UML досить широко поширений і використовуваний стандарт, його часто критикують через наступних недоліків:

    • Надмірність мови. UML часто критикується, як невиправдано великий і складний. Він включає багато надлишкових або практично невикористовуваних діаграм і конструкцій. Найчастіше це можна почути щодо UML 2.0, ніж UML 1.0, так як більш нові ревізії включають більше "розроблених-комітетом" компромісів.
    • Неточна семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений - формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
    • Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков. [11]
    • Только код отражает код. Ещё одно мнение - что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, "The code is the design" ("Код и есть проект"). [12] [13] В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
    • Кумулятивна навантаження / Неузгодженість навантаження (Cumulative Impedance / Impedance mismatch). Неузгодженість навантаження - термін з теорії системного аналізу для позначення нездатності входу системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко й ефективно, ніж інші. Таким чином, розробник схиляється до рішень, які більш комфортно підходять до переплетення сильних сторін UML і мов програмування. Проблема стає більш очевидною, якщо мова розробки не дотримується принципів ортодоксальної об'єктно-орієнтованої доктрини (не намагається відповідати традиційним принципам ООП).
    • Намагається бути всім для всіх. UML - це мова моделювання загального призначення, який намагається досягти сумісності з усіма можливими мовами розробки. У контексті конкретного проекту, для досягнення командою проектувальників певної мети, повинні бути вибрані застосовні можливості UML. Крім того, шляхи обмеження сфери застосування UML в конкретній області проходять через формалізм, який не повністю сформульований, і який сам є об'єктом критики.

    Примітки

    1. UML Specification version 1.1 (OMG document ad/97-08-11) - www.omg.org/cgi-bin/doc?ad/97-08-11 (Англ.)
    2. 1 2 3 OMG Formally Released Versions of UML - www.omg.org/spec/UML/ (Англ.)
    3. Documents associated with UML Version 1.4 - www.omg.org/spec/UML/1.4/ (Англ.)
    4. Documents associated with UML Version 1.5 - www.omg.org/spec/UML/1.5/ (Англ.)
    5. Documents associated with UML Version 2.0 - www.omg.org/spec/UML/2.0/ (Англ.)
    6. Documents associated with UML Version 2.1.1 - www.omg.org/spec/UML/2.1.1/ (Англ.)
    7. Documents associated with UML Version 2.1.2 - www.omg.org/spec/UML/2.1.2/ (Англ.)
    8. Documents associated with UML Version 2.2 - www.omg.org/spec/UML/2.2/ (Англ.)
    9. Documents associated with UML Version 2.3 - www.omg.org/spec/UML/2.3/ (Англ.)
    10. Documents associated with UML Version 2.4 - Beta 2 - www.omg.org/spec/UML/2.4/ (Англ.)
    11. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130 - www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130 ACM
    12. Slashdot | The Code Is The Design - developers.slashdot.org / article.pl? sid = 05/03/01/2112257
    13. Code as Design: Three Essays by Jack W. Reeves by Jack W. Reeves - developer .*, Developer Dot Star - www.developerdotstar.com / mag / articles / reeves_design_main.html

    Література

    • Крег Ларман. Застосування UML 2.0 і шаблонів проектування = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development - 3-е изд. - М .: Вільямс, 2006. - 736 с. - ISBN 0-13-148906-2.
    • Джозеф Шмуллер. Освой самостійно UML 2 за 24 години. Практичний посібник = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit - М .: Вільямс, 2005. - 416 с. - ISBN 0-672-32640-X.
    • Грейді Буч, Джеймс Рамбо, Айвар Джекобсон. Мова UML. Керівництво користувача = The Unified Modeling Language user guide - 2-е вид. - М ., СПб. : ДМК Пресс, Пітер, 2004. - 432 с. - ISBN 5-94074-260-2.
    • Буч Г., Якобсон А., Рамбо Дж. UML. Класика CS. 2-е вид. / Пер. з англ.; Під загальною редакцією проф. С. Орлова - СПб. : Питер, 2006. - 736 с. ISBN 5-469-00599-2

    Цей текст може містити помилки.

    Схожі роботи | скачати
    © Усі права захищені
    написати до нас