Отправляет email-рассылки с помощью сервиса Sendsay

Блог программиста-туриста

  Все выпуски  

Основы UML - диаграммы использования (use-case)


Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML - слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту. Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process 1, а Розенберг - ICONIX 2). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования. Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе). На диаграмме использования изображаются:
  • акторы - группы лиц или систем, взаимодействующих с нашей системой;
  • варианты использования (прецеденты) - сервисы, которые наша система предоставляет акторам;
  • комментарии;
  • отношения между элементами диаграммы.
На мой взгляд, наиболее правильный порядок построения диаграммы следующий:
  1. выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
  2. идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может "продать товар" (это будет являться прецедентом), однако "ввод штрих-кода товара для получения цены" самостоятельным прецедентом не является;
  3. дополнить прецеденты словесным описанием (сценарием):
    • для каждого прецедента создать разделы: "главная последовательность" и "альтернативные последовательности";
    • при составлении сценария нужно упорно задавать заказчику вопросы "что происходит?", "что дальше?", "что еще может происходить?" и записывать ответы на них.
Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но на мой взгляд, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).

Полный текст статьи: Основы UML – диаграммы использования (use-case)

В избранное