Способы применения UML

Основу роли XJML в разработке программного обеспечения составляют разнообразные способы использования языка, те различия, которые были перенесены из других языков графического моделирования. Эти отличия вызывают долгие и трудные дискуссии о том, как следует применять UML.

Чтобы разрешить эту сложную ситуацию, Стив Меллор (Steve Mellor) и я независимо пришли к определению трех режимов использования UML разработчиками: режим эскиза, режим проектирования и режим языка программирования. Безусловно, самый главный из трех, по крайней мере, на мой пристрастный взгляд, - это режим использова­ния UML для эскизирования. В этом режиме разработчики использу­ют UML для обмена информацией о различных аспектах системы. В режиме проектирования можно использовать эскизы при прямой и об­ратной разработке. При прямой разработке (forward-engineering) диа­граммы рисуются до написания кода, а при обратной разработке (re­verse-engineering) диаграммы строятся на основании исходного кода, чтобы лучше понять его.

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

При обратной разработке вы используете эскизы, чтобы объяснить, как работает некоторая часть системы. Вы показываете не все классы, а только те, которые представляют интерес и которые стоит обсудить перед тем, как погрузиться в код. Поскольку эскизирование носит не­формальный и динамичный характер и вам нужно делать это быстро и совместно, то наилучшим средством отображения является доска. Эскизы полезны также и в документации, при этом главную роль иг­рает процесс передачи информации, а не полнота. Инструментами эс­кизного моделирования служат облегченные средства рисования, и

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

Напротив, язык UML как средство проектирования нацелен на пол­ноту. В процессе прямой разработки идея состоит в том, что проект разрабатывается дизайнером, чья работа заключается в построении детальной модели для программиста, который будет выполнять коди­рование. Такая модель должна быть достаточно полной в части зало­женных проектных решений, а программист должен иметь возмож­ность следовать им прямо и не особо задумываясь. Дизайнером модели может быть тот же самый программист, но, как правило, в качестве дизайнера выступает старший программист, который разрабатывает модели для команды программистов. Причина такого подхода лежит в аналогии с другими видами инженерной деятельности, когда про­фессиональные инженеры создают чертежи, которые затем передают­ся строительным компаниям.

Проектирование может быть использовано для всех деталей системы либо дизайнер может нарисовать модель какой-то конкретной части. Общий подход состоит в том, чтобы дизайнер разработал модели про­ектного уровня в виде интерфейсов подсистем, а затем дал возмож­ность разработчикам поработать над реализацией подробностей.

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

При разработке моделей требуется более сложный инструментарий, чем при составлении эскизов, так как необходимо поддерживать деталь­ность, соответствующую требованиям поставленной задачи. Специали­зированные CASE-средства (computer-aided software engineering - авто­матизированная разработка программного обеспечения) попадают в эту категорию, хотя сам этот термин стал почти ругательным, и поставщи­ки стараются его избегать. Инструменты прямой разработки поддержи­вают рисование диаграмм и копирование их в репозиторий с целью со­хранения информации. Инструменты обратного проектирования чита­ют исходный код, записывают его интерпретацию в репозиторий и гене­рируют диаграммы. Инструменты, позволяющие выполнять как прямую, так и обратную разработку, называются двухсторонними (round-trip).

Некоторые средства используют исходный код в качестве репозито-рия, а диаграммы используют его для графического представления. Такие инструменты более тесно связаны с программированием и часто встраиваются прямо в средства редактирования исходного кода. Мне нравится называть их «тройными» инструментами

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

Чем дольше вы работаете с UML, а программирование становится все более механическим, тем очевиднее становится необходимость перехо­да к автоматизированному созданию программ. Действительно многие CASE-средства так или иначе генерируют код, что позволяет автома­тизировать построение значительной части системы. В конце концов, вы достигнете такой точки, когда сможете описать с помощью UML всю систему и перейдете в режим использования UML в качестве язы­ка программирования. В такой среде разработчики рисуют диаграм­мы, которые компилируются прямо в исполняемый код, a UML стано­вится исходным кодом. Очевидно, что такое применение UML требует особенно сложных инструментов. (Кроме того, нотации прямой и об­ратной разработки теряют всякий смысл, поскольку UML и исходный код становятся одним и тем же.)

Один из интересных вопросов, касающихся UML как языка програм­мирования, - это вопрос о моделировании логики поведения, UML 2 предлагает три способа моделирования поведения: диаграммы взаимо­действия, диаграммы состояний и диаграммы деятельности. Все они имеют своих сторонников в сфере программирования. Если UML добь­ется популярности как язык программирования, то будет интересно посмотреть, какой из этих способов будет иметь успех.

Другая точка зрения разработчиков на UML находится где-то м"ежду его применением для концептуального моделирования и его примене­нием для моделирования программного обеспечения. Большинство разработчиков используют UML для моделирования программного обеспечения. С точки зрения программного обеспечения элементы UML практически непосредственно отображаются в элементы программной системы. Как мы увидим впоследствии, отображение отнюдь не озна­чает следование инструкциям, но когда мы используем UML, мы гово­рим об элементах программного обеспечения.

С концептуальной точки зрения UML представляет описание концеп­ций предметной области. Здесь мы не столько говорим об элементах программного обеспечения, сколько занимаемся созданием словаря для обсуждения конкретной предметной области.

Нет строгих правил выбора точки зрения. Поскольку проблему можно рассматривать под разными углами зрения, то и способов применения существует довольно много. Некоторые инструменты автоматически преобразуют исходный код в диаграммы, трактуя UML как альтерна­тивный вид исходного кода. Это в большей степени программный ра­курс. Если же диаграммы UML применяются для того, чтобы проверить.