UML — различия между версиями

м
 
(не показано 12 промежуточных версий этого же участника)
Строка 1: Строка 1:
'''UML''' (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
+
'''UML''' (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного [[моделирование|моделирования]] в области разработки [[программное обеспечение|программного обеспечения]], моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
  
 +
UML обеспечивает три представления модели системы:
 +
# Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования);
 +
# Статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов)
 +
# Представление динамического поведения (взаимодействие объектов и изменения внутреннего состояния объектов, включая диаграммы последовательностей, деятельностей и состояний)
  
 
== Назначение ==
 
== Назначение ==
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
+
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, [[программная система|программных систем]]. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
  
 
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.
 
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.
 
  
 
== Диаграммы ==
 
== Диаграммы ==
UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
+
Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:
* Структурные диаграммы:
+
[[Файл:UML.png|center]]
** Диаграмма классов
+
 
** Диаграмма компонентов
+
=== Структурные диаграммы ===
** Диаграмма композитной/составной структуры
+
* Диаграмма классов
** Диаграмма кооперации (UML2.0)
+
*: [[Файл:class_association.png|400px]]
** Диаграмма развёртывания
+
* Диаграмма компонентов
** Диаграмма объектов
+
* Диаграмма композитной/составной структуры
** Диаграмма пакетов
+
* Диаграмма кооперации (UML2.0)
** Диаграмма профилей (UML2.2)
+
* Диаграмма развёртывания
* Диаграммы поведения:
+
* Диаграмма объектов
** Диаграмма деятельности
+
* Диаграмма пакетов
** Диаграмма состояний
+
* Диаграмма профилей (UML2.2)
** Диаграмма вариантов использования
+
 
** Диаграммы взаимодействия:
+
=== Диаграммы поведения ===
*** Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
+
* Диаграмма деятельности
*** Диаграмма обзора взаимодействия (UML2.0)
+
*: [[Файл:activity_diagram.png|400px]]
*** Диаграмма последовательности
+
* Диаграмма состояний
*** Диаграмма синхронизации (UML2.0)
+
* Диаграмма вариантов использования
 +
*: [[Файл:usecase_diagram.png|400px]]
 +
* '''Диаграммы взаимодействия''':
 +
** Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
 +
** Диаграмма обзора взаимодействия (UML2.0)
 +
** Диаграмма последовательности
 +
**: [[Файл:sequence_diagram.png|400px]]
 +
** Диаграмма синхронизации (UML2.0)
 +
 
 +
== Преимущества ==
 +
* '''UML объектно-ориентирован''', в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
 +
* '''UML позволяет описать систему практически со всех возможных точек зрения''' и разные аспекты поведения системы;
 +
* '''Диаграммы UML сравнительно просты для чтения''' после достаточно быстрого ознакомления с его синтаксисом;
 +
* '''UML расширяет и позволяет вводить собственные текстовые и графические стереотипы''', что способствует его применению не только в сфере программной инженерии;
 +
* '''UML получил широкое распространение''' и динамично развивается.
 +
 
 +
== Недостатки ==
 +
* '''Избыточность языка'''. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов.
 +
* '''Неточная семантика'''. Так как UML определён комбинацией себя (абстрактный синтаксис), [[OCL]] (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
 +
* '''Проблемы при изучении и внедрении'''. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
 +
* '''Только код отражает код'''. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
 +
* '''Кумулятивная нагрузка/Рассогласование нагрузки''' (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
 +
* '''Пытается быть всем для всех'''. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
 +
 
 +
== Инструменты ==
 +
* Sparx Enterprise Architect
 +
* IBM Rational Rose
 +
* ArgoUML
 +
* BOUML
 +
* Dia
 +
* Enterprise Architect
 +
* MagicDraw UML
 +
* Modelio
 +
* PowerDesigner
 +
* Rational Rhapsody
 +
* Rational Software Architect
 +
* StarUML
 +
* Umbrello
 +
* Eclipse
 +
* NetBeans
 +
 
 +
== См. также ==
 +
*[[MBSE]]
 +
*[[SysML]]
 +
*[[OMG]]
 +
*[[MOF]]
 +
*[[CWM]]
 +
*[[XMI]]
 +
 
 +
== Литература ==
 +
* Мартин Фаулер «UML, основы: краткое руководство по стандартному языку объектного моделирования» (Addison-Wesley Professional, ISBN-10: 0321193687, ISBN-13: 978-0321193681; Символ-Плюс, ISBN 5-93286-060-X)
  
[[Файл:UML.png]]
+
== Ссылки ==
 +
* [http://book.uml3.ru/ Интернет-книга "Моделирование на UML"]
  
[[Категория:Языки]]
+
[[Категория:Языки моделирования]]

Текущая версия на 17:47, 7 декабря 2017

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML обеспечивает три представления модели системы:

  1. Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования);
  2. Статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов)
  3. Представление динамического поведения (взаимодействие объектов и изменения внутреннего состояния объектов, включая диаграммы последовательностей, деятельностей и состояний)

Назначение

UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

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

Диаграммы

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

UML.png

Структурные диаграммы

  • Диаграмма классов
    Class association.png
  • Диаграмма компонентов
  • Диаграмма композитной/составной структуры
  • Диаграмма кооперации (UML2.0)
  • Диаграмма развёртывания
  • Диаграмма объектов
  • Диаграмма пакетов
  • Диаграмма профилей (UML2.2)

Диаграммы поведения

  • Диаграмма деятельности
    Activity diagram.png
  • Диаграмма состояний
  • Диаграмма вариантов использования
    Usecase diagram.png
  • Диаграммы взаимодействия:
    • Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
    • Диаграмма обзора взаимодействия (UML2.0)
    • Диаграмма последовательности
      Sequence diagram.png
    • Диаграмма синхронизации (UML2.0)

Преимущества

  • UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
  • UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
  • Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
  • UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
  • UML получил широкое распространение и динамично развивается.

Недостатки

  • Избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов.
  • Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
  • Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
  • Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
  • Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
  • Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

Инструменты

  • Sparx Enterprise Architect
  • IBM Rational Rose
  • ArgoUML
  • BOUML
  • Dia
  • Enterprise Architect
  • MagicDraw UML
  • Modelio
  • PowerDesigner
  • Rational Rhapsody
  • Rational Software Architect
  • StarUML
  • Umbrello
  • Eclipse
  • NetBeans

См. также

Литература

  • Мартин Фаулер «UML, основы: краткое руководство по стандартному языку объектного моделирования» (Addison-Wesley Professional, ISBN-10: 0321193687, ISBN-13: 978-0321193681; Символ-Плюс, ISBN 5-93286-060-X)

Ссылки