- •Унифицированный язык моделирования uml
- •Эта версия страницы ожидает проверки и может отличаться от последней подтверждённой, проверенной 8 ноября 2010.
- •[Править] uml 1.X
- •[Править] Диаграмма классов
- •[Править] Критика
- •[Править] Ссылки
- •Глава 3 Основные компоненты языка uml
- •Примечание
- •Снабдить исходные понятия языка uml возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.
- •Описание языка uml должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных систем.
- •Описание языка uml должно включать в себя семантический базис для понимания общих особенностей ооап.
- •Интегрировать в себя новейшие и наилучшие достижения практики ооап.
- •Примечание
- •3.2. Общая структура языка uml
- •Примечание
- •Примечание
- •3.3. Пакеты в языке uml
- •Примечание
- •Примечание
- •3.4. Основные пакеты метамодели языка uml
- •Примечание
- •Примечание
- •Примечание
- •3.5. Специфика описания метамодели языка uml
- •Примечание
- •Примечание
- •Примечание
- •3.6. Особенности изображения диаграмм языка uml
- •Примечание
- •Примечание
- •Примечание
- •Примечание
[Править] Критика
Несмотря на то, что 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 в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
[править] См. также
Диаграмма связей
Инструменты UML-моделирования
SysML
IDEF
DFD
ДРАКОН
[править] Примечания
↑ UML Specification version 1.1 (OMG document ad/97-08-11) (англ.)
↑ 1 2 3 OMG Formally Released Versions of UML (англ.)
↑ Documents associated with UML Version 1.4 (англ.)
↑ Documents associated with UML Version 1.5 (англ.)
↑ Documents associated with UML Version 2.0 (англ.)
↑ Documents associated with UML Version 2.1.1 (англ.)
↑ Documents associated with UML Version 2.1.2 (англ.)
↑ Documents associated with UML Version 2.2 (англ.)
↑ Documents associated with UML Version 2.3 (англ.)
↑ Documents associated with UML Version 2.4 — Beta 2 (англ.)
↑ http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130 ACM
↑ Slashdot | The Code Is The Design
↑ Code as Design: Three Essays by Jack W. Reeves by Jack W. Reeves — developer.*, Developer Dot Star
[править] Литература
Крэг Ларман. Применение 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
