на главную поиск по сайту карта сайта
+7 (495) 646-0612info@informicus.ru

Оформить заказ

Оказываем полный спектр услуг в сфере информационных технологий. Разработка, внедрение и сопровождение программного обеспечения. Анализ, оценка эффективности и консультирование в сфере использования информационных систем. А также собственные программные решения для оптимизации вашего бизнеса.
Разработка программ, разработка ПО на заказ, торговые роботы    
ГЛАВНАЯ О КОМПАНИИ РЕШЕНИЯ УСЛУГИ СТАТЬИ

СТАТЬИ

СТАТЬИ

К оглавлению.

Диаграммы вариантов использования

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

Целями анализа и моделирования требований являются:

  • достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;
  • достижение лучшего понимания разработчиками поведения ПС;
  • ограничение системной функциональности;
  • создание базиса для планирования разработки проекта;
  • определение пользовательского интерфейса.

Для достижения этих целей используются диаграммы вариантов использования UML (Use case diagrams).

Общие сведения о диаграммах вариантов использования

На диаграммах вариантов использования (ВИ) изображаются актеры и варианты использования, между которыми существуют отношения. Здесь можно показывать и другие элементы UML (например, классы могут показывать, какие сущности порождаются или используются в конкретных ВИ – см. рис.1).


Рис.1. Диаграмма вариантов использования

Актеры

Актером будем называть внешнюю по отношению к ПС сущность, которая может взаимодействовать с системой. Актерами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актер – это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Например, в качестве актера «Бухгалтер» может выступать весь наличный штат бухгалтерии. В то же время один конкретный человек может играть несколько ролей по отношению к системе. Главный бухгалтер может выступать как актер с таким же именем, но может использовать систему так же, как актер «бухгалтер» (то есть, выполнять работу обычного бухгалтера). В то же время актеры – не обязательно люди. Если ПС должна выполнять какие-либо действия в определенные моменты времени, то в качестве актера, инициирующего выполнение этих действий, может быть указан системный таймер.

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

Варианты использования

При взаимодействии актера с системой последняя выполняет ряд работ, которые образуют вариант использования системы (use case). Каждый актер может использовать систему по разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе (которое может быть разбито на несколько более мелких). ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент.

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

Лучший путь к нахождению ВИ – рассмотреть, что требует каждый актер от системы. Следует помнить, что система существует только для пользователей и должна строиться, исходя из их потребностей.

Каждый ВИ должен иметь название, отвечающее его назначению. Название должно отражать, что достигается при взаимодействии с актерами. На диаграммах ВИ изображается в виде овала.

Отношения

Ассоциация – единственно возможная связь между актером и ВИ. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. На рис.2а оператор инициирует начало выполнения ВИ открытия нового счета.

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

Если два или более ВИ имеют сходство в структуре и поведении, то целесообразно выделить общий фрагмент и построить новый, родительский ВИ. Исходные ВИ будут являться дочерними по отношению к родительскому. Дочерний ВИ наследует все поведение, описанное в родительском варианте. Отношение обобщения между двумя ВИ означает, что когда осуществляется дочерний ВИ, необходимо исполнение и родительского. В общем случае для того, чтобы создание родительского ВИ имело смысл, необходимо, чтобы у него было бы хотя бы два дочерних. Единственное исключение – это, когда имеются два ВИ и один из них является детализацией другого, но оба могут осуществляться независимо. На диаграммах показывается в виде отношения обобщения (см. рис.2б).

Отношение включения, помечаемое стереотипом <>, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но не включаемый. Включение показывается пунктирной стрелкой, направленной от базового ВИ к включаемому (см. рис.2б).

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


Рис. 2а. Пример диаграммы ВИ
Актер «Оператор» активизирует выполнение ВИ «Открыть счет». В соответствии с заданным оператором типом счета выполняется либо ВИ «Открыть счет физического лица» либо «Открыть счет юридического лица», являющиеся расширениями первого. Открытие счета включает его контроль и при обнаружении ошибки – выдачу сообщения Оператору.
Рис. 2б. Пример диаграммы ВИ
Аналог рис. 2а. У актера «Оператор» есть два режима работы. Он активизирует «Открыть счет физического лица» либо «Открыть счет юридического лица». Открытие каждого счета включает выполнение работ, предусматриваемых в ВИ «Открыть счет», содержащим общее поведение для двух исходных ВИ.

Назначение диаграмм вариантов использования

Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. При этом иерархическая организация требований представляется с помощью пакетов use cases.

««НазадДалее»»

90
Проектное управление
Проектное управление
Подробнее
89
Аспекты проектного управления
Аспекты проектного управления
Подробнее
82
Что такое Rational Unified Process (RUP)
Что такое Rational Unified Process (RUP)
Подробнее
73
Цикл статей по моделированию программных систем
Цикл статей по моделированию программных систем
Подробнее
1234

телефон/факс: +7 (495) 646-0612/687-9964

105120, г. Москва, ул. Нижняя Сыромятническая,д. 5/7

info@informicus.ru

COPYRIGHT INFORMICUS, 2006 - 2020

Главная | О компании | Решения |
Услуги | Статьи | Карта сайта