чем the uml не является
Что такое The UML
Структура определения языка
Это, наверное, самая короткая часть лекции. Здесь нам хотелось бы рассказать о том, как описан UML его авторами. Но прежде нужно поговорить о способах описания искусственных языков вообще (например, языков программирования).
Конечно, вы уже читали книги, в которых описывались языки программирования, и не могли не заметить, как авторы этих книг все время самоотверженно балансируют между точностью и понятностью описания. Велик соблазн описать язык формально точно, но такое описание своей сложностью может отпугнуть потенциального пользователя новой технологии. С другой стороны, «понятное», неформальное описание языка может получиться очень длинным и неполным и просто запутать читателя.
Терминология и нотация
Вообще же, в UML используется четыре вида элементов нотации:
Кстати об инструментах рисования. Мы уже упоминали, что такое ПО существует, и далее мы рассмотрим этот вопрос более подробно (проведя сравнительные исследования), пока же скажем лишь о нескольких наиболее заметных программах этого класса. К таким пакетам можно отнести:
Наиболее известными из этой пятерки являются Rational Rose и Together. Это действительно средства для проектирования, а не рисования, как Visio. Долгое время автор этих строк использовал Poseidon, благо имеется бесплатная Community edition-версия этого продукта. Так было до тех пор, пока на одной из конференций по программной инженерии он не увидел TAU G2 от Telelogic. О TAU все слышали, но никто его не видел. Это легендарное средство моделирования, которое сочетает в себе мощь и простоту использования, предоставляя уникальную возможность начальной верификации моделей. И хотя интерфейс TAU выглядит несколько аскетично, его возможности и удобство работы просто потрясают. Все диаграммы в этом курсе созданы именно с использованием TAU, любезно предоставленным фирмой Telelogic (см. http://www.telelogic.com/).
Чем the uml не является
UML предназначен для моделирования. Сами авторы UML определяют свое детище следующим образом.
Мы полностью согласны с этим определением, и не только одобряем выбор ключевых слов, но придаем большое значение порядку, в котором они перечислены.
1.2.1. Спецификация
В типичных случаях в процессе разработки приложений участвуют по меньше мере два действующих лица: заказчик (конкретный человек или группа лиц, или организация) и разработчик (это может быть программист-одиночка, временная команда проекта или целая организация, специализирующаяся на разработке программного обеспечения). Из-за того, что действующих лиц двое, очень многое зависит от степени их взаимопонимания.
Одним из ключевых этапов разработки приложения является определение того, каким требованиям должно удовлетворять разрабатываемое приложение. В результате этого этапа появляется формальный или неформальный документ (артефакт), который называют по-разному, имея в виду примерно одно и то же: постановка задачи, требования, техническое задание, внешние спецификации и др.
Аналогичные по назначению, но, может быть, отличные по форме и содержанию артефакты появляются и на других этапах разработки, особенно если в разработку включено много действующих лиц. Для них также используются различные названия: функциональные спецификации, архитектура приложения и др. Мы будем все такие артефакты называть спецификациями.
Спецификация ‒ это декларативное описание того, как нечто устроено или работает.
Необходимо принимать во внимание три толкования спецификаций.
Эти три трактовки спецификаций могут не совпадать, и, к сожалению, как показывает практика, сплошь и рядом не совпадают, причем значительно. Заказчик может не осознавать своих объективных потребностей, или неверно их интерпретировать, или заблуждаться относительно природы своих затруднений, пытаясь с помощью заказного офисного приложения лечить симптомы, а не причину болезни своего бизнеса. Разработчик может не разбираться в предметной области заказчика и интерпретировать формулировки спецификаций совершенно превратным образом. Если же в формулировке спецификаций участвует разработчик, то злоупотребление технической терминологией может совершенно дезориентировать заказчика.
Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное, и, с третьей стороны, достаточно универсальное средство, позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций.
1.2.2. Визуализация
Рис. Жизненный цикл работника на предприятии
Разве что-нибудь непонятно?
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми. Разумеется, наглядность визуализации моделей UML имеет значение, только если они должны составляться или восприниматься человеком ‒ это назначение UML не имеет отношения к компьютерам.
Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.
1.2.3. Проектирование
В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином «проектирование». Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код. Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения.
По-английски автоматическое построение модели по коду готового приложения называется reverse engineering и обычно переводится на русский как «обратное проектирование». Нам этот перевод категорически не нравится: какое же это проектирование и почему оно обратное? Есть неплохой альтернативный вариант: «инженерный анализ программ», но он не получил пока распространения.
Сказанное в предыдущем абзаце требует оговорок «до некоторой степени», «в известной мере» буквально после каждого утверждения. Самое досадное, что в данный момент точно указать «степень» и «меру» не представляется возможным. Причина не в том, что никто не удосужился этим заняться, а в том, что это очень трудная задача, но не безнадежная. Инструменты, поддерживающие UML, все время совершенствуются, так что в перспективе третье предназначение UML может выйти и на первое место.
Некоторым уставшим от бесконечной отладки разработчикам может показаться, что стоит изучить UML, и все проблемы программирования будут решены. К сожалению, это не так.
1.2.4. Документирование
XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.
Поясним последнюю фразу предыдущего абзаца. Стандарт требует, чтобы во внутреннем представлении модели для каждого элемента моделирования было отведено место, где можно хранить неформальное текстовое описание этого элемента. Большинство инструментов это требование выполняют: буквально для каждой линии или фигуры на диаграмме можно ввести текст, который поясняет смысл и назначение именно этой линии или фигуры. Более того, многие инструменты умеют из этих текстовых описаний собирать цельные, вполне осмысленные и хорошо отформатированные текстовые документы, которые можно использовать именно как привычные текстовые описания моделируемой системы. К сожалению, это замечательная возможность на практике используется меньше, чем она того заслуживает. Дело в том, что так же, как программисты не любят и ленятся писать осмысленные комментарии к программному коду, так и архитекторы не любят и ленятся писать текстовые пояснения к своим диаграммам.
1.2.5. Чем НЕ является UML
Не следует думать, что UML ‒ это панацея от всех детских ∇ болезней программирования. Для ясного понимания назначения и области применения UML полезно сопоставить UML с другими родственными явлениями.
∇ Информационным технологиям от силы полвека ‒ это еще младенческий возраст для новой области человеческой деятельности.
Во-первых, UML не является языком программирования (хотя генерация кода не возбраняется, см. параграф 1.2.3). Дело не в том, что UML язык графический, а подавляющее большинство практических языков программирования являются текстовыми языками. Гораздо важнее то, что для моделей UML не определена операционная семантика, то есть, не определен способ выполнения моделей на компьютере. Это сделано вполне сознательно, в противном случае UML оказался бы зависимым от некоторой модели вычислимости, уровень абстрактности его концепций пришлось бы существенно снизить, и он не отвечал бы своему основному назначению: служить средством спецификации приложений и других систем на любом уровне абстракции и в различных предметных областях.
Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Magic Draw, Rational Rose Enterprise, Visual Paradigm, Enterprise Architect, StarUML и др.). Сам язык никоим образом не навязывает то, как его нужно поддерживать инструментальными средствами. Решение всех вопросов, связанных с реализацией UML на компьютере полностью отдано на откуп разработчикам инструментов.
В-третьих, UML не является моделью процесса разработки приложений (хотя модель процесса разработки необходима и имеется множество различных моделей, предложенных разными авторами). Конечно, у авторов UML есть собственная модель процесса ‒ Rational Unified Process (RUP), которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без оной.
У авторов этой книги тоже есть собственное мнение о взаимосвязи UML с моделью процесса разработки программного обеспечения (см. раздел 5.2), которое не может не сказываться на описании прагматики языка, но везде, где такое влияние замечено, сделаны соответствующие оговорки.
1.2.6. Способы использования UML
Из сказанного выше видно, что UML предназначен для решения различных задач, соответственно он может быть использован и практически используется по-разному. Далее мы перечисляем различные способы использования UML.
Рисование картинок. Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.
Обмен информацией. Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других «с полувзгляда».
Спецификация систем. Это важнейший способ использования UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, мы надеемся, что по мере развития языка все меньше будет оставаться таких исключений, где UML неприменим.
Повторное использование архитектурных решений. Повторное использование ранее разработанных решений ‒ ключ к повышению эффективности. Наше мнение по этому поводу изложено в разделе 5.2. К сожалению, модели UML пока что повторно используются в весьма ограниченных масштабах.
Генерация кода. В параграфе 1.2.3 данный вопрос достаточно освещен. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать.
Имитационное моделирование. Возможности построения моделей UML, из которых путем вычислительных экспериментов можно было бы извлекать информацию о моделируемом объекте, пока что уступают возможностям специализированных систем, сконструированных для этих целей.
Верификация моделей. Было бы замечательно, если бы по модели можно было бы делать формальные заключения об ее свойствах: модель непротиворечива, согласована, эффективна и т.п. Кое-что UML позволяет проверить, но, конечно, очень мало. Здесь уместно привести аналогию с традиционными системами программирования: они позволяют быстро и надежно избавиться от синтаксических ошибок, но с логическими ошибками дело обстоит гораздо хуже. Может быть, в будущем.
1.2.7. Инструментальная поддержка
Рассмотрим, как соотносится сегодняшняя практика использования UML с декларированным выше назначением языка.
Проводя в жизнь принцип обучения на примерах, для иллюстрации вышесказанного обратимся к одной из диаграмм UML ‒ диаграмме использования (подробное описание данного типа диаграмм приведено в разделе 2.2).
По мнению авторов, можно выделить три основных варианта использования UML.
Рис. Инструментальная поддержка
Вариант использования drawing («Рисование диаграмм») подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.
Вариант использования development («Разработка приложений») подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.
Современные инструменты поддерживают указанные варианты использования далеко не в равной степени. Все инструменты умеют (плохо или хорошо) визуализировать все типы диаграмм UML, некоторые инструменты позволяют построить модель, допускающую какое-то дальнейшее использование, но только немногие инструменты могут генерировать исполняемый код и то, отнюдь, не для всех диаграмм. Имеется множество практических и организационных причин, по которым указанные выше варианты использования неравноправны и в разной степени поддержаны в современных инструментах. Некоторые из этих причин мы рассматриваем в последующих главах.
Что такое The UML
Структура определения языка
Это, наверное, самая короткая часть лекции. Здесь нам хотелось бы рассказать о том, как описан UML его авторами. Но прежде нужно поговорить о способах описания искусственных языков вообще (например, языков программирования).
Конечно, вы уже читали книги, в которых описывались языки программирования, и не могли не заметить, как авторы этих книг все время самоотверженно балансируют между точностью и понятностью описания. Велик соблазн описать язык формально точно, но такое описание своей сложностью может отпугнуть потенциального пользователя новой технологии. С другой стороны, «понятное», неформальное описание языка может получиться очень длинным и неполным и просто запутать читателя.
Терминология и нотация
Вообще же, в UML используется четыре вида элементов нотации:
Кстати об инструментах рисования. Мы уже упоминали, что такое ПО существует, и далее мы рассмотрим этот вопрос более подробно (проведя сравнительные исследования), пока же скажем лишь о нескольких наиболее заметных программах этого класса. К таким пакетам можно отнести:
Наиболее известными из этой пятерки являются Rational Rose и Together. Это действительно средства для проектирования, а не рисования, как Visio. Долгое время автор этих строк использовал Poseidon, благо имеется бесплатная Community edition-версия этого продукта. Так было до тех пор, пока на одной из конференций по программной инженерии он не увидел TAU G2 от Telelogic. О TAU все слышали, но никто его не видел. Это легендарное средство моделирования, которое сочетает в себе мощь и простоту использования, предоставляя уникальную возможность начальной верификации моделей. И хотя интерфейс TAU выглядит несколько аскетично, его возможности и удобство работы просто потрясают. Все диаграммы в этом курсе созданы именно с использованием TAU, любезно предоставленным фирмой Telelogic (см. http://www.telelogic.com/).
Что такое The UML
Способы использования языка
Начать хотелось бы с демонстрации известной картинки, которая уже более двух десятилетий «живет» в Интернете, но источник ее никому не известен (если кто-то из читателей сможет пролить свет на ее происхождение, автор будет очень благодарен за информацию). Эта картинка прекрасно иллюстрирует типичный процесс создания продукта, или «решения» (поскольку продукт решает проблему заказчика), как любят говорить в Microsoft (рис. 1.2).
Как уже говорилось выше, различают спецификации трех видов. Словесные спецификации на естественном языке как раз и вызывают массу проблем, поскольку создаются разными специалистами на «их языке». Другим видом спецификаций являются формальные спецификации. Действительно, описание спецификации с помощью строгого математического языка было бы чудесным решением всех проблем, т. к. сам способ записи исключал бы малейшие неоднозначности. Да, в математике есть, например, алгебра высказываний, с помощью которой можно пытаться создавать технические задания на разработку некоторых приложений. Проблема кроется в слове «некоторых». Понятно, что формальная спецификация является, по сути, математической моделью задачи и потому для вычислительных задач все выглядит достаточно просто. Формализация же задач из других областей знаний может оказаться более сложной и трудоемкой проблемой, чем разработка самого приложения ввиду отсутствия четкой математической модели. Один из принципов прикладной «мерфологии» гласит, что лучшей спецификацией программы является ее текст. Так же, как и большинство остальных законов Мерфи, это утверждение просто поражает своей правдивостью.
Так вот, такие картинки с подписями наглядны и интуитивно понятны, причем почти однозначно понимаются любыми заинтересованными лицами, так что могут использоваться в качестве средства общения между людьми. UML позволяет создавать такие простые и понятные картинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т. е. служит средством коммуникации в команде. Посмотрите на рисунок ниже (рис. 1.3). Все ведь понятно, правда?
Что такое The UML
Способы использования языка
Начать хотелось бы с демонстрации известной картинки, которая уже более двух десятилетий «живет» в Интернете, но источник ее никому не известен (если кто-то из читателей сможет пролить свет на ее происхождение, автор будет очень благодарен за информацию). Эта картинка прекрасно иллюстрирует типичный процесс создания продукта, или «решения» (поскольку продукт решает проблему заказчика), как любят говорить в Microsoft (рис. 1.2).
Как уже говорилось выше, различают спецификации трех видов. Словесные спецификации на естественном языке как раз и вызывают массу проблем, поскольку создаются разными специалистами на «их языке». Другим видом спецификаций являются формальные спецификации. Действительно, описание спецификации с помощью строгого математического языка было бы чудесным решением всех проблем, т. к. сам способ записи исключал бы малейшие неоднозначности. Да, в математике есть, например, алгебра высказываний, с помощью которой можно пытаться создавать технические задания на разработку некоторых приложений. Проблема кроется в слове «некоторых». Понятно, что формальная спецификация является, по сути, математической моделью задачи и потому для вычислительных задач все выглядит достаточно просто. Формализация же задач из других областей знаний может оказаться более сложной и трудоемкой проблемой, чем разработка самого приложения ввиду отсутствия четкой математической модели. Один из принципов прикладной «мерфологии» гласит, что лучшей спецификацией программы является ее текст. Так же, как и большинство остальных законов Мерфи, это утверждение просто поражает своей правдивостью.
Так вот, такие картинки с подписями наглядны и интуитивно понятны, причем почти однозначно понимаются любыми заинтересованными лицами, так что могут использоваться в качестве средства общения между людьми. UML позволяет создавать такие простые и понятные картинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т. е. служит средством коммуникации в команде. Посмотрите на рисунок ниже (рис. 1.3). Все ведь понятно, правда?