Способы использования языка

Назначение языка

UML - унифицированный язык моделирования. Из этих трех слов главным является слово " язык ". Что же такое язык? Не будем изобретать велосипед, а лучше заглянем в глоссарий, благо в Интернете их величайшее множество. Сделав это, мы скорее всего обнаружим определение, подобное приведенному ниже.

Язык - система знаков, служащая:

· средством человеческого общения и мыслительной деятельности;

· способом выражения самосознания личности;

· средством хранения и передачи информации.

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

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

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

1. синтаксис, то есть определение правил построения конструкций языка;

2. семантика, то есть определение правил, в соответствии с которыми конструкции языка приобретают смысловое значение;

3. прагматика, то есть определение правил использования конструкций языка для достижения нужных нам целей.

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

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

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

Подводя итоги, кратко можно сказать, что UML - искусственный язык, который имеет некоторые черты естественного языка, иформальный язык, который имеет черты неформального. Это звучит не очень понятно, но это действительно так!

Историческая справка

Откуда взялся The UML? Если говорить коротко, то UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других.

В не такие уж и далекие 80-е годы было множество различных методологий моделирования. Каждая из них имела свои достоинства и недостатки, а также свою нотацию. То смутное время получило название "войны методов". Проблема в том, что разные люди использовали разные нотации, и для того чтобы понять, что описывает та или иная диаграмма, зачастую требовался "переводчик". Один и тот же символ мог означать в разных нотациях абсолютно разные вещи! На рисунке ниже можно увидеть лишь малую часть многообразия методов, которые существовали в то время и в какой-то мере повлияли на UML (рис. 1.1).

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

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

К 1994-му существовало 72 метода, или частные методики. Многие из них "перекрывались", т. е. использовали похожие идеи, нотации и т. д. Как уже говорилось выше, чувствовалась острая потребность, "социальный заказ" - закончить "войну методов" и объединить в одном унифицированном средстве все лучшее, что было создано в области моделирования.

А что сейчас? The UML живет и развивается. Сейчас мы имеем UML 2.0 и десятки CASE-средств, поддерживающих UML, о многих из которых будет рассказано в "Обзор CASE-средств для построения диаграмм UML" . Вопреки популярному мнению, в наши дни Rational не владеет UML, но продолжает работать над ним. UML же принадлежит OMG, а сама Rational ныне является одним из подразделений IBM и фигурирует во всех документах как IBM Rational. UML же получил множество пакетов расширений, называемыхпрофайлами и позволяющих использовать его для моделирования систем из специфических предметных областей.

Способы использования языка

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

Начать хотелось бы с демонстрации известной картинки, которая уже более двух десятилетий "живет" в Интернете, но источник ее никому не известен (если кто-то из читателей сможет пролить свет на ее происхождение, автор будет очень благодарен за информацию). Эта картинка прекрасно иллюстрирует типичный процесс создания продукта, или "решения" (поскольку продукт решает проблему заказчика), как любят говорить в Microsoft (рис. 1.2).

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

Итак, UML в первую очередь - это спецификации. Заглянем снова в глоссарий и обнаружим, что

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

· словесные спецификации на естественном языке;

· модельные спецификации;

· формальные спецификации.

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

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

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

Так вот, такие картинки с подписями наглядны и интуитивно понятны, причем почти однозначно понимаются любыми заинтересованными лицами, так что могут использоваться в качестве средства общения между людьми. UML позволяет создавать такие простые и понятные картинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т. е. служит средством коммуникации в команде. Посмотрите на рисунок ниже (рис. 1.3).

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

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

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

Теперь о том, для чего UML использовать нельзя, вернее, чем он не является. Во-первых, UML не является языком программирования, хотя существуют средства выполнения UML-моделей как интерпретируемого кода (Unimod, FLORA и др.) и возможна, как уже говорилось выше, кодогенерация. Несмотря на это, UML - средство не программирования, а моделирования, т. е. создания не программ, а моделей любого уровня абстракции для систем из любой предметной области. Во-вторых, UML не является и спецификацией какого бы то ни было инструмента моделирования, хотя такие инструменты (и в больших количествах) имеются. Например, TAU G2 (с помощью которого создано большинство диаграмм в этом курсе), Borland Together, Poseidon, EnterpriseArchitect, IBM Rational Rose, Dia, Visio и др. Каким образом то или иное CASE-средство реализует UML-моделирование, никак не регламентируется и определяется самими разработчиками этих инструментов. И, наконец, в-третьих, UML не является и моделью какого-либо процесса разработки, даже Rational Unified Process (RUP), который был описан именно с помощью UML (а точнее, с помощью SPEM - профайла UML). UML можно использовать независимо от того, какую методологию разработки ПО вы используете, и даже если вы вообще не пользуетесь никакой методологией!