5.3. Средства uml
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:
В течение достаточно длительного периода времени, в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации (требований к системе);
диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
диаграммы поведения системы (behavior diagrams):
диаграммы взаимодействия (interaction diagrams):
диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
диаграммы реализации (implementation diagrams):
диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.
помогающие им лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые понятие ввел понятие варианта использования (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора - «сделать некоторый текст полужирным» и «создать индекс». Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.
Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования.
Действующие лица делятся на три основных типа - пользователи системы, другие системы, взаимодействующие с данной, и время.
Первый тип действующих лиц - это физические личности, или пользователи системы. Они наиболее типичны и имеются практически в каждой системе. Например, к этому типу относятся клиенты и обслуживающий персонал. Называя действующих лиц, используйте их ролевые имена, а не те, что соответствуют их должности. Конкретный человек может играть множество ролей. Ролевые, а не должностные имена позволяют получить более стабильную картину действующих лиц. Должности могут меняться время от времени, при этом роли и ответственности могут перемещаться от одной должности к другой. Используя роли для названия действующих лиц, вам не придется обновлять модель каждый раз при появлении новой должности или при изменении распределения обязанностей между ними.
Вторым типом действующих лиц является другая система. Допустим, что у банка имеется кредитная система, используемая для работы с информацией о кредитных счетах клиентов. Система банка должна иметь возможность взаимодействовать с кредитной системой, в таком случае последняя становится действующим лицом.
Сделав систему действующим лицом, мы предполагаем, что она не будет изменяться вообще. Действующие лица находятся вне сферы действия того, что мы разрабатываем и, таким образом, не подлежат контролю с нашей стороны. Если мы собираемся изменять или разрабатывать также и кредитную систему, она попадает при этом в наш проект и, таким образом, не может быть показана как действующее лицо.
Третий наиболее распространенный тип действующего лица - это время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Система, например, может каждую полночь выполнять какие-либо служебные процедуры по настройке и согласованию своей работы. Так как время не подлежит нашему контролю, оно является действующим лицом.
Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил использовать для их наглядного представления диаграммы вариантов использования. На рис. 5.1 показан пример такой диаграммы для банковского автомата (Automated Teller Machine, ATM)
Рис. 5.1. Пример диаграммы вариантов использования
На данной диаграмме человеческие фигурки обозначают действующих лиц, овалы - варианты использования, а линии и стрелки - различные связи между действующими лицами и вариантами использования.
На этой диаграмме показаны три действующих лица: клиент, банковский служащий и кредитная система. Существует также шесть основных действий, выполняемых моделируемой системой: перевести деньги, сделать вклад, снять деньги со счета, показать баланс, изменить идентификационный номер и осуществить оплату.
На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Данная диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами системы ATM. В сущности, диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере, клиент банка инициирует большое количество различных вариантов использования: Снять деньги со счета, Перевести деньги, Сделать вклад, Показать баланс и Изменить идентификационный номер. Некоторые из связей заслуживают более детального рассмотрения. Банковский служащий может также инициировать вариант использования "Изменить идентификационный номера". От варианта использования "Осуществить оплату" стрелка указывает на Кредитную систему. Действующими лицами могут быть внешние системы, и потому в данном случае Кредитная система показана именно как действующее лицо — она внешняя для системы ATM. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом. В данном случае вариант использования "Осуществить оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.
Все варианты использования так или иначе связаны с внешними требованиями к функциональности системы. Если кредитной системе требуется файл, то это требование должно быть удовлетворено. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Конкретная цель диаграмм вариантов использования - это документирование вариантов использования (всё, входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы вариантов использования, старайтесь придерживаться следующих правил:
Не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия систёмы. Это означает, что связи между ними также не относятся к ее компетенции.
Не соединяйте стрелкой два варианта использования непосредственно (кроме случаев связей использования и расширения, описанных ниже). Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельностей.
Каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Опять исключением являются рассматриваемые далее связи использования и расширения.
Думайте о базе данных как о слое, находящемся под диаграммой. С помощью одного варианта использования можно вводить данные в базу, а получать их — с помощью другого. Не надо для изображения потока информации рисовать стрелки от одного варианта использования к другому.
В начале проекта возникает естественный вопрос: как обнаружить варианты использования. Лучше всего для этого внимательно прочитать любую документацию заказчика. Часто помогает также рассмотрение области использования системы на высоком уровне и документов концептуального характера. Учтите также мнение каждого из заинтересованных лиц проекта. Спросите себя, чего они ожидают от готового продукта. Для каждого заинтересованного лица можно задать следующие вопросы:
Что он хочет делать с системой?
Нужно ли ему с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?
Нужно ли ему будет информировать систему о каких-либо внешних событиях?
Должна ли система, в свою очередь, информировать его о каких-либо изменениях или событиях?
Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящие во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает идентифицировать варианты использования.
Варианты использования - это не зависящее от реализации высокоуровневое представление о том, что пользователь ожидает от системы. Рассмотрим каждый фрагмент этого определения по отдельности.
Прежде всего, варианты использования не зависят от реализации. Представьте себе, что вы пишете руководство по работе с системой. Надо, чтобы ваши варианты использования можно было реализовать на языках Java, C++, Visual Basic или на бумаге. Варианты Использования заостряют внимание на том, что должна делать система, а не на том, как она должна будет делать это.
Далее, варианты использования — это высокоуровневое представление системы. Если, например, в модели содержится 3000 вариантов использования, вы потеряете преимущество простоты. Создаваемый набор вариантов использования должен дать пользователям возможность легко увидеть всю систему целиком на самом высоком уровне. Поэтому вариантов использования не должно быть слишком много, чтобы клиенту не пришлось долго блуждать по страницам документации, пытаясь понять, что будет делать система. В то же время, вариантов использования должно быть достаточно для того, чтобы полностью описать действия системы. Модель типичной системы обычно содержит от 20 до 50 вариантов использования. Для того, чтобы при необходимости разбить варианты использования на части, можно использовать связи различных типов; так называемые связи использования и расширения. Для лучшей организации системы можно также формировать группы вариантов, объединяя их в пакеты.
Наконец, варианты использования должны заострять внимание на том, что пользователи должны получить от системы. Каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой, представляющую для первого некоторую ценность. Названия вариантов использования должны быть деловыми, а не техническими терминами, имеющими значение для заказчика. В рассматриваемом нами примере ATM нельзя назвать вариант использования "Интерфейс с банковской системой, осуществляющий перевод денег с кредитной карточки и наоборот". Вместо этого лучше назвать вариант использования "Оплатить по карточке" — так будет понятнее для заказчика. Варианты использования обычно называют глаголами или глагольными фразами, описывая при этом, что пользователь видит как конечный результат процесса. Его не интересует, сколько других систем задействованы в варианты использования, какие конкретные шаги надо предпринять и сколько строчек кода надо написать, чтобы заплатить по счету карточкой Visa. Для него важно только, чтобы оплата была сделана. Еще раз повторим, что нужно заострить внимание на результате, который потребитель ожидает от системы, а не на действиях, которые надо предпринять для достижения этого результата.
Но как убедиться, что обнаружены все варианты использования? Для этого следует задать себе вопросы наподобие следующих:
Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражение в варианте использования, оно не будет реализовано.
Учли ли вы, как с системой будет работать каждое заинтересованное лицо?
Какую информацию каждое заинтересованное лицо будет передавать системе?
Какую информацию каждое заинтересованное лицо будет получать от системы?
Учли ли вы проблемы, связанные с эксплуатацией? Кто-то должен будет запускать готовую систему и выключать ее.
Учли ли вы все внешние системы, с которыми будет взаимодействовать данная?
Какой информацией каждая внешняя система будет обмениваться с данной?
Варианты использования начинают описывать, что должна будет делать система. Чтобы фактически разработать систему, однако, потребуются более конкретные детали. Эти детали описываются в документе, называемом "поток событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы, и что - сама система.
Хотя поток событий и описывается подробно, он также не должен зависеть от реализации. Цель – описать, что будет делать система, а не как она будет делать это. Обычно поток событий включает:
Краткое описание
Предусловия (pre-conditions)
Основной поток событий
Альтернативный поток событий
Постусловия (post-conditions)
Последовательно рассмотрим эти составные части.
Описание
Каждый вариант использования должен иметь связанное с ним короткое описание того, что он будет делать. Например, вариант использования "Перевести деньги" системы ATM может содержать следующее описание:
Вариант Использования "Перевести деньги" позволяет клиенту или служащему банка переводить деньги с одного счета до востребования или сберегательного счета на другой.
Описание должно быть коротким и "к месту", при этом оно должно определять типы пользователей, выполняющих вариант использования, и ожидаемый ими конечный результат. По мере работы над проектом (особенно, если это длинный проект) эти описания помогут команде разработчиков помнить, почему тот или иной вариант использования был включен в проект и что он должен делать. Четко документируя таким образом цели каждого варианта использования, можно уменьшить неразбериху, возникающую среди членов команды во время работы.
Предусловия
Предусловия варианта использования - это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска этого. Не у всех вариантов использования бывают предварительные условия.
Ранее упоминалось, что диаграммы вариантов использования не должны отражать порядок их выполнения. С помощью предусловий, однако, можно документировать и такую информацию. Например, предусловием одного варианта использования может быть то, что в это время должен выполняться другой.
Основной и альтернативный потоки событий
Конкретные детали вариантов использования описываются в основном и альтернативных потоках событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что будет делать система, а не как она будет делать это, причем описывает все это с точки зрения пользователя. Основной и альтернативный потоки событий включают следующее описание:
Каким образом запускается вариант использования;
Различные пути выполнения варианта использования; Нормальный, или основной, поток событий варианта использования;
Отклонения от основного потока событий (так называемые альтернативные потоки);
Потоки ошибок;
Каким образом завершается вариант использования.
Например, поток событий варианта использования "Снять деньги" может выглядеть следующим образом:
Основной поток
Вариант использования начинается, когда клиент вставляет свою карточку в ATM.
ATM выводит приветствие и предлагает клиенту ввести свой персональный идентификационный номер.
Клиент вводит номер.
ATM подтверждает введенный номер. Если номер не подтвержден, выполняется альтернативный поток событий А1.
ATM выводит список доступных действий:
- Положить деньги на счет
- Снять деньги со счета
- Перевести деньги
Клиент выбирает пункт "Снять деньги".
ATM запрашивает, сколько денег надо снять.
Клиент вводит требуемую сумму.
ATM определяет, имеется ли на счету достаточно денег. Если денег недостаточно, выполняется альтернативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется поток ошибок Е1.
ATM вычитает требуемую сумму из счета клиента.
ATM выдает клиенту требуемую сумму наличными.
ATM возвращает клиенту его карточку.
ATM печатает чек для клиента.
Вариант использования завершается.
Альтернативный поток А1. Ввод неправильного идентификационного номера.
ATM информирует клиента, что идентификационный номер введен неправильно.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Альтернативный вариант использования А2. Недостаточно денег на счету.
ATM информирует клиента, что денег на его счету недостаточно.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Поток ошибок Е1. Ошибка в подтверждении запрашиваемой суммы.
ATM сообщает пользователю, что при подтверждении запрашиваемой суммы произошла ошибка и дает ему номер телефона службы поддержки клиентов банка.
ATM заносит сведения об ошибке в журнал ошибок. Каждая запись содержит дату и время ошибки, имя клиента, номер его счета и код ошибки.
ATM возвращает клиенту его карточку.
Вариант использования завершается.
Документируя поток событий, можно использовать нумерованные списки (как это сделано в данном примере), ненумерованные списки, разбитый на параграфы текст и даже блок-схемы. Поток событий должен быть согласован с определенными ранее требованиями. Решая, как описывать поток, помните о тех, кто будет читать ваш документ. Заказчики будут изучать его, чтобы убедиться, что он соответствует их ожиданиям. Аналитики - что он соответствует требованиям к системе. Менеджер проекта просмотрит его, чтобы лучше понять, что будет создано, а также чтобы сделать или обновить оценки проекта.
Работая над потоком, избегайте детальных обсуждений того, как он будет реализован. Представьте себе, что вы записываете кулинарный рецепт. При этом вы пишете: добавить два яйца. Вы никогда не напишете: "Откройте холодильник. Возьмите два яйца с полочки на дверце. Зажмите в руке первое яйцо. Стукните им по краю чашки..." Аналогично, составляя поток событий, вы можете написать: "Проверить идентификационный номер пользователя", но вам не надо указывать, что для этого надо обратиться к какой-то специальной таблице в базе данных. Уделяйте внимание обмену информацией между пользователями и системой, но не подробному описанию ее реализации.
Постусловия
Постусловиями называются такие условия, которые всегда должны быть выполнены после завершения варианта использования. Например, в конце варианта использования можно пометить флажком какой-нибудь переключатель. Информация такого типа входит в состав постусловий. Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы. Если, например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются не у каждого варианта использования.
В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи коммуникации (communication), использования (uses), расширения (extends) и обобщения действующего лица (actor generalization). Связи коммуникации описывают связи между действующими лицами и вариантами использования. Связи использования и расширения отражают связи между вариантами использования, а связи обобщения действующего лица - между действующими лицами.
Связь коммуникации (communication relationship) — это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью обычной стрелки. Направление стрелки позволяет понять, кто инициирует коммуникацию. Например, действующее лицо Клиент инициирует коммуникацию с системой, чтобы запустить функцию Снятия денег. Вариант использования также может инициировать коммуникацию с действующим лицом Кредитная система. Когда выполняется вариант использования "Сделать выплату", система ATM инициирует коммуникацию с Кредитной системой, чтобы завершить транзакцию. Информация при этом движется в обоих направлениях, от системы ATM к Кредитной и обратно; стрелка показывает только, кто инициирует коммуникацию.
Связь использования (uses геlationship) позволяет одному варианту использования использовать функциональность другого. С помощью таких связей обычно моделируют многократно используемую функциональность, встречающуюся в двух или более вариантах использования. В примере ATM варианты использования "Снять деньги" и "Положить деньги на счет" должны опознать (аутентифицировать) клиента и его идентификационный номер перед тем, как допустить осуществление самой транзакции. Вместо того, чтобы подробно описывать процесс аутентификации для каждого из них, можно поместить эту функциональность в свой собственный вариант использования под названием "Аутентифицировать клиента". Когда какому-нибудь варианту использования потребуется выполнить эти действия, он может использовать функциональность созданного нами варианта использования "Аутентифицировать клиента".
Связь использования изображается в UML с помощью стрелок и слова «uses» (использование), как было показано на рисунке 5.2.
Рис. 5.2. Связи использования и расширения
В этом примере вариант использования "Снять деньги" использует функциональность варианта использования "Аутентифицировать клиента". Этот последний является абстрактным вариантом использования, то есть таким, который предоставляет другим вариантам использования свою функциональность через связи использования и расширения. Вариант использования "Снять деньги" - это конкретный вариант использования.
Связь использования предполагает, что один вариант использования всегда использует функциональные возможности другого. Не важно, как именно осуществляется вариант использования "Снять деньги", вариант использования "Аутентифицировать клиента" будет запущен в любом случае. Напротив, связи расширения (extends Геlationships) позволяют варианту_использования только при необходимости использовать функциональные возможности другого.
Связи расширения (extends relationships) позволяют варианту использования только при необходимости использовать функциональные возможности, предоставляемые другим вариантом использования. Они напоминают связи использования. В обоих типах отношений некоторая общая функциональность выделяется в отдельный вариант использования.
На языке UML связи расширения показывают в виде стрелки со словом «extends» (расширение), как на рис. 5.2.
В нашем примере вариант использования "Снять деньги" иногда использует функциональные возможности, предоставляемые вариантом использования "Выполнить ускоренное снятие денег". Это происходит тогда и только тогда, когда клиент выбирает пункт "Быстро снять 40$" во время работы варианта использования "Снять деньги".
Предоставляющий дополнительные возможности вариант использования "Выполнить ускоренное снятие денег" является абстрактным. Вариант использования "Снять деньги" — это конкретный вариант использования.
С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Это отношение можно моделировать с помощью нотации, показанной на рис. 5.3.
Рис. 5.3. Абстрактное действующее лицо
Например, у нас имеется два типа клиентов - индивидуальные и корпоративные. Это конкретные действующие лица. Они будут инстанцированы (наполнены) непосредственно. Действующее лицо Клиент - это абстрактное действующее лицо. Оно никогда не инстанцируется непосредственно. Оно нужно, только чтобы показать наличие двух типов клиентов.
При необходимости можно усиливать ветвление (если имеется два типа корпоративных клиентов - правительственные агентства и частные компании).
Нет необходимости всегда создавать связи этого типа. В общем случае, они нужны, если поведение действующего лица одного типа отличается от поведения другого постольку, поскольку это затрагивает систему. Если, например, корпоративные клиенты инициируют некоторые варианты использования, которые не могут запустить индивидуальные клиенты, вероятно, включить в диаграмму связи этого типа имеет смысл. Если клиенты обоих типов используют одни и те же варианты использования, показывать обобщение действующего лица не требуется. Если оба типа действующих лиц используют одни и те же варианты использования, но слегка по-разному, все-таки, не стоит включать их обобщение. Небольшие различия можно документировать в потоке событий варианта использования.
Еще раз повторим, что основным назначением этих диаграмм является коммуникация между участниками команды. Если обобщение действующих лиц предоставляет им некоторую полезную информацию, включайте ее в диаграмму. Если нет - не загромождайте диаграмму избыточной информацией. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования - это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
В заключение перечислим типичные ловушки, которых следует избегать при моделировании вариантов использования:
Границы системы четко не определены;
Варианты использования рассматриваются с точки зрения системы, а не действующих лиц;
Слишком много вариантов использования;
Многочисленные и запутанные связи между действующими лицами и вариантами использования;
Слишком объемные или нечеткие спецификации вариантов использования;
Варианты использования не соответствуют реальным функциям;
Пользователи плохо понимают варианты использования.