UML UML - унифицированный язык моделирования. Язык включает в себя: - набор знаков (словарь) и - правила их употребления и интерпретации (грамматику).

Языки бывают естественные и искусственные, формальные и неформальные. UML - язык формальный и искусственный, Искусственный - потому, что у него имеются авторы (в то же время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками). Формальный – потому, что имеются правила его употребления (но описание UML содержит и явно неформальные элементы). Еще: UML - язык графический

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

UML - язык моделирования (ОО моделирования). Это слово это многозначно. В английском языке есть два слова - modeling и simulation, которые оба переводятся как "моделирование", хотя означают разные понятия. Modeling - создание модели, лишь описывающей объект, а simulation предполагает получение с помощью созданной модели некоторой дополнительной информации об объекте. UML в первую очередь - язык моделирования именно в первом смысле, то есть средство построения описательных моделей. Как средство симулирования его тоже можно использовать, но для этой роли он подходит не так хорошо.

«Унифицированный» - можно понимать тоже неоднозначно. В литературе можно встретить описание эры "до UML" как "войны методов" моделирования, ни один из которых "не дотягивал" до уровня индустриального стандарта. UML и стал таким единым универсальным стандартом для ОО моделирования, которое во времена его создания как раз "вошло в моду". "Единым" языком моделирования UML можно назвать и потому, что в его создании объединились усилия авторов трех наиболее популярных методов моделирования (и не только их).

Итоги: UML - искусственный язык, который имеет некоторые черты естественного языка, и формальный язык, который имеет черты неформального.

Историческая справка UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и других. В 80-е годы было множество различных методологий моделирования. Каждая имела свои достоинства и недостатки, свою нотацию. То смутное время называют "войной методов". Проблема: разные люди использовали разные нотации, и чтобы понять, что описывает та или иная диаграмма, часто требовался "переводчик". Один и тот же символ мог означать в разных нотациях абсолютно разные вещи! Малая часть многообразия методов, которые существовали в то время и в какой-то мере повлияли на UML (рис.).

В это же время (начало 80-х) стартовала «ОО эра". Все началось с появлением семейства ЯП SmallTalk, которые применяли некоторые понятия языка Simula- 67(60-е гг). Появление ОО подхода было обусловлено увеличением сложности задач. ОО подход внес радикальные изменения в сами принципы создания и функционирования программ, но, в то же время, позволил существенно повысить производительность труда программистов, по-иному взглянуть на проблемы и методы их решения, сделать программы более компактными и легко расширяемыми. Как результат, языки, первоначально ориентированные на традиционный подход к программированию, получили ряд ОО расширений. Одной из первых, в середине 80-х, была фирма Apple со своим проектом Object Pascal. ОО подход породил мощную волну и абсолютно новых программных технологий - общепризнанные сегодня платформы, как Microsoft.NET Framework и Sun Java.

Появление ООП требовало удобного инструмента для моделирования, единой нотации для описания сложных программных систем. И вот "три амиго" решили объединить свои разработки. В 1991-м каждый написал книгу, где изложил свой метод ООАП. Каждая методология была по-своему хороша, но имела и недостатки. Метод Буча был хорош в проектировании, но слабоват в анализе. OMT Румбаха был, наоборот, отличным средством анализа, но плох в проектировании. Objectory Якобсона был хорош с точки зрения user experience, на который ни метод Буча, ни OMT не обращали особого внимания. Основная идея Objectory - анализ должен начинаться с прецедентов, а не с диаграммы классов, которые должны быть производными от них. К 1994 г существовало 72 метода, или частные методики. Многие из них "перекрывались", использовали похожие идеи, нотации. Чувствовалась острая потребность, "социальный заказ" - закончить "войну методов" и объединить в одном унифицированном средстве все лучшее, что было создано в области моделирования.

Румбах присоединился к Бучу в Rational Inc. Они создали первую версию UML. В 1995 году на конференции OOPSLA они представили его как Unified Method, который потом и получил название UML. К ним присоединился Якобсон, он добавил элементы Objectory и начал работу над Rational Unified Process (RUP). В 1997 году UML был отправлен в Object Management Group (OMG) для стандартизации. Кроме трех нотаций UML вобрал в себя элементы многих других методологий. Сейчас The UML живет и развивается. Имеются десятки CASE-средств, поддерживающих UML. UML получил множество пакетов расширений– профайлов, позволяющих использовать его для моделирования систем из специфических предметных областей.

Известная картинка, которая более 20 лет "живет" в Интернете, но источник ее никому не известен. Она иллюстрирует типичный процесс создания продукта, или "решения" (поскольку продукт решает проблему заказчика). Здесь видны все проблемы программной инженерии, в частности проблемы с коммуникацией и пониманием, вызванные отсутствием четкой спецификации создаваемого продукта. Авторы UML определяют его как графический язык моделирования общего назначения (его можно применять для проектирования чего угодно - от простой качели до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.

UML в первую очередь - это спецификации. Спецификация - подробное описание системы, которое полностью определяет ее цель и функциональные возможности. Различают: - словесные спецификации на естественном языке; - модельные спецификации; - формальные спецификации. Заказчик и разработчик имеют разное понимание смысла этого артефакта. А есть еще аналитики, менеджеры, бизнес- консультанты... Каждый называет спецификации по-своему: постановка задачи, требования пользователя, ТЗ, функциональная спецификация, архитектура системы... Они, являясь специалистами в разных предметных областях, говорят каждый на своем языке и часто не понимают друг друга. Вот и возникает проблема (на рисунке), которую может решить только наличие единого, унифицированного средства создания спецификаций, простого и понятного для всех заинтересованных лиц.

Словесные спецификации на естественном языке вызывают массу проблем, т.к. создаются разными специалистами на "их языке". Формальные спецификации. Описание спецификации с помощью строгого математического языка было бы решением всех проблем, т.к. сам способ записи исключал бы неоднозначности. В математике есть алгебра высказываний, с помощью которой можно создавать ТЗ на разработку некоторых приложений. Проблема - в слове "некоторых". Формальная спецификация является, по сути, математической моделью задачи и для вычислительных задач все выглядит просто. Формализация задач из других областей знаний может оказаться более сложной проблемой, чем разработка самого приложения ввиду отсутствия четкой математической модели. Один из принципов прикладной "морфологии" гласит, что лучшей спецификацией программы является ее текст. Так же, как и большинство остальных законов Мерфи, это утверждение просто поражает своей правдивостью...

UML - это средство визуализации, имеем в виду модельные спецификации. Изучение чего-то нового идет проще, если документ содержит не только текст, а еще и иллюстрации к нему. А если руководство или учебник выглядят как картинки с подписями (майкрософтовские учебники, руководства пользователя мобильных телефонов), то усвоение нового материала происходит еще проще и эффективнее. Картинки с подписями наглядны и интуитивно понятны, почти однозначно понимаются любыми лицами и могут использоваться в качестве средства общения между людьми. UML позволяет создавать простые и понятные картинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т.е. служит средством коммуникации в команде. Рисунок. Все ведь понятно, правда?

Проектирование. UML позволяет строить модели программных систем (ЛЮБЫХ систем). По этим моделям потом может производиться генерация каркасного кода проектируемых приложений. Возможен процесс (реверс-инжиниринг) - создание UML-модели из существующего кода приложения. Качество получающегося кода или моделей при реверс-инжиниринге не идеально, но технологии и инструменты совершенствуются, когда-нибудь сможем создавать приложения визуально, не прибегая к ЯП, а пользуясь лишь UML...

Документирование. UML-модели сами по себе уже являются документами (понятными, даже для неспециалиста, кроме этого, модели UML являются XML- документами). Любой элемент на любой диаграмме может быть снабжен текстовым комментарием. Т. е. построение набора диаграмм уже является процессом документирования будущей системы. Большинство инструментов UML-проектирования умеют извлекать текстовую информацию из моделей и генерировать относительно удобочитаемые тексты. Итоги: UML можно использовать для рисования картинок, которые можно использовать для коммуникаций внутри команды и в ходе взаимодействия с заказчиком, т.е. он может служить средством обмена информацией. UML – отличное средство спецификации систем, причем спецификации в процессе разработки. Разработанные архитектурные решения, задокументированные с помощью UML, могут быть использованы повторно. О генерации кода, симуляции и верификации моделей, пока серьезно говорить не приходится, но будет и это...

Для чего UML использовать нельзя, чем он не является. - UML не является ЯП, хотя существуют средства выполнения UML-моделей как интерпретируемого кода (Unimod, FLORA и др.) и возможна кодогенерация. Но UML - средство не программирования, а моделирования, т. е. создания не программ, а моделей любого уровня абстракции для систем из любой предметной области. - UML не является и спецификацией какого бы то ни было инструмента моделирования, хотя такие инструменты имеются: TAU G2, Borland Together, Poseidon, Enterprise Architect, IBM Rational Rose, Dia, Visio и др. Каким образом то или иное CASE- средство реализует UML-моделирование, никак не регламентируется и определяется самими разработчиками этих инструментов. - UML не является и моделью какого-либо процесса разработки. UML можно использовать независимо от того, какую методологию разработки ПО вы используете, и даже если вы вообще не пользуетесь никакой методологией!