Салют!
В этом посте я очерчу главное, что нужно знать IT-аналитику для применения такой техники БА, как варианты использования (ВИ). Постараюсь сделать это лаконично и без воды. Совсем уж кратко не выйдет, но это всяко лучше, чем штудировать литературные труды по этой теме (например, этот, который считается одним из основополагающих) — достаточно осознать ключевые принципы, чтобы начать применять технику в работе. Только важно понимать: взглядов на ВИ много, причем зачастую они друг другу сильно противоречат. Я поделюсь тем, что после изучения множества источников и спустя годы активного применения сам считаю полезным и чему обучаю других. В общем, поехали.
Что вообще такое ВИ? Варианты использования aka use cases aka юз кейсы aka прецеденты (последний вариант перевода встречается, но не рекомендую использовать — пацаны не поймут) — это техника БА, т. е. некий метод/средство, которое аналитик может применять в работе для выполнения определенных задач. Повторюсь: это не задача сама по себе, не советую ставить «описать набор ВИ для системы» как самоцель. Это инструмент для выполнения задачи, которую, в свою очередь, вы должны сформулировать и пользу от выполнения которой в контексте БА и проекта вы должны явно осознать. Эту тему мы также затронем.
Вариант использования, Use case (вдумайтесь в эти слова — способ использования чего-либо) — это то, как вашу систему (ту, к которой вы прорабатываете требования) или решение, если более обобщенно и в ногу с BABOK (да-да, даже что-то неайтишное), могут использовать внешние по отношению к ней субъекты или объекты (в терминологии ВИ они зовутся актерами). В первую очередь, актеры — это человеки-пользователи решения, но могут быть также и сторонние программные или аппаратные системы, если речь идет про IT-решение.
ВИ отвечают на вопрос «Что полезного может сделать X с нашей системой?» Проверить орфографию в документе (для MS Word). Добавить ресурс в Избранное (для веб-браузера). Создать пользователя (для CRM-системы). Заказать пиццу (для сайта по заказу пиццы).
Соответственно, набор юз кейсов (список) — это все единички полезных взаимодействий с решением, которые внешние по отношению к решению актеры могут осуществить.
Есть два простых правила формулировки ВИ:
1) Это единичное взаимодействие с системой. Пришел – сделал – ушел. Проверить орфографию. В плане сценария для пользователя это означает открыть Word —> открыть документ —> запустить проверку орфографии —> получить удовлетворение от результата —> закрыть документ.
Антипримеры (не формулируйте ВИ так): проверять орфографию, орфография, управление пользователями, информация о компании. Ни в одном из этих примеров я не пойму, что я как пользователь смогу выполнить в виде конкретной единичной операции.
Далее у нас встретятся исключения из этого правила, но на данном этапе лучше считать это обязательным условием.
2) Юз кейс должен обязательно нести пользу для актера. Можно дополнить предыдущий сценарий: подошел к системе – выполнил юз кейс – получил счастье/пользу – ушел. «Проверить орфографию» несет явную пользу как операция, т. е. я могу представить себе сценарий, описанный в предыдущем пункте, как нечто, несущее пользу для того, кто его выполняет. А вот, к примеру, «Указать язык проверки» — это не что-то полезное, чем я удовлетворюсь в плане взаимодействия с решением. Открыл документ —> указал язык проверки —> закрыл документ. И? Ценность получил? Указать язык проверки — это всего лишь шаг в рамках чего-то более завершенного и полезного, конкретно в рамках ВИ «Проверить орфографию».
Давайте также рассмотрим неайтишный пример. Возьмем банкомат — яркий пример, который любят разбирать на собеседованиях. Вот я подошел к типовому банкомату. Что я как актер могу с ним сделать (помним при этом о полезности и «единичности»)? Снять наличку, посмотреть баланс, осуществить платеж. Осуществив каждую из этих операций, я могу уйти, образно говоря, с полными штанами счастья. А если актер не я, а человек, который обслуживает банкомат? Пополнить запас купюр, плюс все иное, что с ним делают подобные специалисты (в душе не знаю, что именно они с ним делают).
Что не будет ВИ, а будет всего лишь шагами в рамках каких-то ВИ? Ввести ПИН-код, указать язык взаимодействия, распечатать чек, указать сумму и прочие бесполезные сами по себе шаги. Повторюсь, далее мы рассмотрим ситуации, когда подобные действия будут исключением и будут нами выделяться как ВИ, но не на этапе, когда нам нужно понять, что пользователи смогут полезного сделать с нашей системой.
Теперь, когда мы представляем, что такое ВИ в целом, давайте поговорим о том, для чего они нужны — какие задачи решает бизнес-аналитик, выделяя ВИ для системы, над требованиями к которой он работает. При это важно пометить: если вы активно используете в работе такую технику, как user stories, то, скорее всего, всё, что будет перечислено ниже, вы уже так или иначе покрываете. Да, это разные техники, и да, они во многом похожи в плане применимости, но различия в сути и сценариях использования есть (сравнение техник и анализ подобных нюансов — это точно out-of-scope для этого очерка, но вы можете глянуть толковый обзор тут). Итак, юз кейсы юз кейсов:
1) Главное: идентификация юз кейсов позволяет аналитику и прочим заинтересованных лицам (ЗЛ) взглянуть на решение с точки зрения пользователей и того, какую пользу они получат от решения. Встать на сторону конечного пользователя — это критически важный взгляд на решение на этапах проработки его наполнения и работы с требованиями ЗЛ. Многие аналитики по инерции, проектируя наполнение системы, работают только с фичами: «Дорогой заказчик, что у нас там будет в нашей CRM-системе? Работа с заявками, статистика, управление пользователями и правами доступа, поиск дубликатов. Верно перечислили?». Это взгляд на систему со стороны фич (единиц, кусков системы), и зачастую он первым приходит на ум. Такой подход к наполнению решения, если применяется в одиночку, опасен тем, что вы не эмпатируете пользователям. Вы исходите не из их задач, а из того, что на ваш взгляд или на взгляд заказчика должно присутствовать в системе. Именно юз кейсы помогают сфокусировать взгляд правильным образом.
Вывод: если вам не хватает подобного взгляда в ваших проектах, и вы постоянно «пляшете» от «что у нас в системе должно быть», проработайте набор (список) ВИ для системы — вполне вероятно, вы словите кучу инсайтов о нехватающей, неверно задуманной или даже избыточной функциональности.
2) С помощью ВИ вы можете представить и донести до тех, кому это нужно, скоуп (границы) решения, а также управлять им впоследствии:
- Вы как аналитик можете планировать и организовывать свою работу юз кейс за юз кейсом. Идентифицировали набор ВИ, расставили приоритеты вместе с ЗЛ — и в путь: прорабатывайте их итеративно в порядке приоритета. Так вы будете уверены в том, что с каждой новой итерацией вашей деятельности вы добавляете в плане требований нечто законченно полезное для пользователей. Ну и не стоит забывать о том, что для не-технических ЗЛ юз кейсы как единичка обсуждения более понятны, чем фичи или случайные функциональные требования (сравните «давайте обсудим заказ пиццы в системе» с «давайте обсудим содержимое страницы «Корзина»).
- Ваш ПМ и девелоперы также возьмут юз кейсы на вооружение в качестве единиц для планирования релизов и управления процессом разработки. В ближайший релиз — юз кейс X, в следующий за ним — Y и Z. И, как и с пунктом выше, каждый релиз системы будет содержать не обрывки функциональности (например, страница «Заказ пиццы» как фича), а полноценный полезный сценарий взаимодействия с системой (полный процесс заказа пиццы с достижением ценного для определенного актера результата).
- От кого вы точно получите кучу «спасибок», так это от тестировщиков. У них свои инструменты: сценарии, тест кейсы и пр. И юз кейсы — это прямо-таки идеальная база для их проработки. Тестировщик в рамках некоторой проверяемой единицы будет выполнять определенное действие, смотреть на результат и сравнивать с тем, что заложен в требования. И далее вы увидите, что детализация ВИ в плане наполнения отражает именно такой сценарный подход.
Учтите, правда, что не всегда подобный подход сработает идеально. Есть ряд нюансов, с которыми вы столкнетесь на практике и на разбор которых в рамках обзорной статьи точно не стоит тратить место. Например, нередки ситуации, когда систему можно разбить на 5/10/20 фич, но при этом юз кейсов у подобной системы будет всего два. Скоуп из двух единичек — это точно не что-то репрезентативное, что удобно доносить ЗЛ под грифом «вот, что у нас за система в плане наполнения» со всеми вытекающими. С ограничениями пытаются сразиться в относительно новом подходе Use-Case 2.0, но нельзя сказать, что эта практика стала популярной — лучше посмотрите в сторону фич или user stories в контексте этой задачи (либо вместо, либо в дополнение к ВИ).
Вывод: если у вас нет выработанной и проверенной на практике техники для декомпозиции скоупа решения, попробуйте взять ВИ и проверьте, насколько это сработает в условиях вашего проекта в контексте деятельности всех проектных ролей.
3) Юз кейсы — это отличная увязка задач пользователей и иных актеров (то бишь части требований ЗЛ к решению) с соответствующим им наполнением решения (то бишь требованиями к решению — функциональными и нефункциональными). Далее мы рассмотрим детализацию ВИ и то, как отразить требования к решению в рамках них. Соответственно, ВИ с детализацией — это фактически один из способов документирования требований к решению, которые скомпонованы в рамках родительских требований ЗЛ. Вполне себе спецификация требований получается, из которой а) понятно, для чего в плане задач применима система, б) какие требования необходимо в ней реализовать, дабы позволить актерам выполнить эти задачи.
Вывод: если у вас не выработан подход к документированию требований, попробуйте начать со списка ВИ + их рубашек + диаграммы ВИ (об этом ниже). Это будет отличной отправной точкой, на которой вы можете либо остановиться, либо дополнить недостающими аспектами требований. Удачным такой вариант будет не всегда и не везде, но это уже более сложные и объемные материи.
С чего начать проработку ВИ для решения?
Эту тему я затрону вкратце. Алгоритм по своей сути довольно прост:
1) Идентифицируйте все категории внешних по отношению к решению агентов. Хорошей стартовой точкой может послужить контекстная диаграмма. Соответственно, объекты/субъекты, которые напрямую (есть еще непрямые пользователи, т. е. те, кто пользуется результатами системы опосредованно, не взаимодействуя с системой, но в контексте ВИ они нас не интересуют) взаимодействуют с решением, — это ваши актеры. Но не все они нужны вам на данном этапе. Актеры, как мы далее увидим, тоже могут быть разными. Сейчас нас интересуют именно те актеры, которые получают ценность от взаимодействий с решением.
2) Изучите потребности актеров: что полезное им необходимо получать от взаимодействия с решением.
3) На базе потребностей сформулируйте операции актеров над решением и представьте их в виде ВИ по правилам, которые приведены в начале статьи.
Процесс может показаться весьма кэпским, но по факту это не просто «сесть и подумать», хоть и с подобного стоит начать. Если ударяться в детали и покрывать эти шаги качественно, то речь будет идти уже не о применении ВИ как техники БА, а о процессе проработки требований ЗЛ для БА — а это уже самостоятельная крупная тема, включающая различные техники и подходы к извлечению и анализу требований данного уровня.
Чем дополнить проработку ВИ?
Визуально ВИ можно представить в виде диаграммы вариантов использования (Use Case Diagram из нотации UML). С одной стороны, это инструмент для визуализации списка ВИ, а мы знаем, что графические штуки частенько работают гораздо лучше текста. С другой стороны, этот инструмент добавляет ряд новых аспектов в ВИ в плане связей между ними, что позволяет отразить ряд дополнительных полезняшек.
Вот как может выглядеть диаграмма ВИ для сильно упрощенного новостного портала:
В этом посте я очерчу главное, что нужно знать IT-аналитику для применения такой техники БА, как варианты использования (ВИ). Постараюсь сделать это лаконично и без воды. Совсем уж кратко не выйдет, но это всяко лучше, чем штудировать литературные труды по этой теме (например, этот, который считается одним из основополагающих) — достаточно осознать ключевые принципы, чтобы начать применять технику в работе. Только важно понимать: взглядов на ВИ много, причем зачастую они друг другу сильно противоречат. Я поделюсь тем, что после изучения множества источников и спустя годы активного применения сам считаю полезным и чему обучаю других. В общем, поехали.
Что вообще такое ВИ? Варианты использования aka use cases aka юз кейсы aka прецеденты (последний вариант перевода встречается, но не рекомендую использовать — пацаны не поймут) — это техника БА, т. е. некий метод/средство, которое аналитик может применять в работе для выполнения определенных задач. Повторюсь: это не задача сама по себе, не советую ставить «описать набор ВИ для системы» как самоцель. Это инструмент для выполнения задачи, которую, в свою очередь, вы должны сформулировать и пользу от выполнения которой в контексте БА и проекта вы должны явно осознать. Эту тему мы также затронем.
Вариант использования, Use case (вдумайтесь в эти слова — способ использования чего-либо) — это то, как вашу систему (ту, к которой вы прорабатываете требования) или решение, если более обобщенно и в ногу с BABOK (да-да, даже что-то неайтишное), могут использовать внешние по отношению к ней субъекты или объекты (в терминологии ВИ они зовутся актерами). В первую очередь, актеры — это человеки-пользователи решения, но могут быть также и сторонние программные или аппаратные системы, если речь идет про IT-решение.
ВИ отвечают на вопрос «Что полезного может сделать X с нашей системой?» Проверить орфографию в документе (для MS Word). Добавить ресурс в Избранное (для веб-браузера). Создать пользователя (для CRM-системы). Заказать пиццу (для сайта по заказу пиццы).
Соответственно, набор юз кейсов (список) — это все единички полезных взаимодействий с решением, которые внешние по отношению к решению актеры могут осуществить.
Есть два простых правила формулировки ВИ:
1) Это единичное взаимодействие с системой. Пришел – сделал – ушел. Проверить орфографию. В плане сценария для пользователя это означает открыть Word —> открыть документ —> запустить проверку орфографии —> получить удовлетворение от результата —> закрыть документ.
Антипримеры (не формулируйте ВИ так): проверять орфографию, орфография, управление пользователями, информация о компании. Ни в одном из этих примеров я не пойму, что я как пользователь смогу выполнить в виде конкретной единичной операции.
Далее у нас встретятся исключения из этого правила, но на данном этапе лучше считать это обязательным условием.
2) Юз кейс должен обязательно нести пользу для актера. Можно дополнить предыдущий сценарий: подошел к системе – выполнил юз кейс – получил счастье/пользу – ушел. «Проверить орфографию» несет явную пользу как операция, т. е. я могу представить себе сценарий, описанный в предыдущем пункте, как нечто, несущее пользу для того, кто его выполняет. А вот, к примеру, «Указать язык проверки» — это не что-то полезное, чем я удовлетворюсь в плане взаимодействия с решением. Открыл документ —> указал язык проверки —> закрыл документ. И? Ценность получил? Указать язык проверки — это всего лишь шаг в рамках чего-то более завершенного и полезного, конкретно в рамках ВИ «Проверить орфографию».
Давайте также рассмотрим неайтишный пример. Возьмем банкомат — яркий пример, который любят разбирать на собеседованиях. Вот я подошел к типовому банкомату. Что я как актер могу с ним сделать (помним при этом о полезности и «единичности»)? Снять наличку, посмотреть баланс, осуществить платеж. Осуществив каждую из этих операций, я могу уйти, образно говоря, с полными штанами счастья. А если актер не я, а человек, который обслуживает банкомат? Пополнить запас купюр, плюс все иное, что с ним делают подобные специалисты (в душе не знаю, что именно они с ним делают).
Что не будет ВИ, а будет всего лишь шагами в рамках каких-то ВИ? Ввести ПИН-код, указать язык взаимодействия, распечатать чек, указать сумму и прочие бесполезные сами по себе шаги. Повторюсь, далее мы рассмотрим ситуации, когда подобные действия будут исключением и будут нами выделяться как ВИ, но не на этапе, когда нам нужно понять, что пользователи смогут полезного сделать с нашей системой.
Теперь, когда мы представляем, что такое ВИ в целом, давайте поговорим о том, для чего они нужны — какие задачи решает бизнес-аналитик, выделяя ВИ для системы, над требованиями к которой он работает. При это важно пометить: если вы активно используете в работе такую технику, как user stories, то, скорее всего, всё, что будет перечислено ниже, вы уже так или иначе покрываете. Да, это разные техники, и да, они во многом похожи в плане применимости, но различия в сути и сценариях использования есть (сравнение техник и анализ подобных нюансов — это точно out-of-scope для этого очерка, но вы можете глянуть толковый обзор тут). Итак, юз кейсы юз кейсов:
1) Главное: идентификация юз кейсов позволяет аналитику и прочим заинтересованных лицам (ЗЛ) взглянуть на решение с точки зрения пользователей и того, какую пользу они получат от решения. Встать на сторону конечного пользователя — это критически важный взгляд на решение на этапах проработки его наполнения и работы с требованиями ЗЛ. Многие аналитики по инерции, проектируя наполнение системы, работают только с фичами: «Дорогой заказчик, что у нас там будет в нашей CRM-системе? Работа с заявками, статистика, управление пользователями и правами доступа, поиск дубликатов. Верно перечислили?». Это взгляд на систему со стороны фич (единиц, кусков системы), и зачастую он первым приходит на ум. Такой подход к наполнению решения, если применяется в одиночку, опасен тем, что вы не эмпатируете пользователям. Вы исходите не из их задач, а из того, что на ваш взгляд или на взгляд заказчика должно присутствовать в системе. Именно юз кейсы помогают сфокусировать взгляд правильным образом.
Вывод: если вам не хватает подобного взгляда в ваших проектах, и вы постоянно «пляшете» от «что у нас в системе должно быть», проработайте набор (список) ВИ для системы — вполне вероятно, вы словите кучу инсайтов о нехватающей, неверно задуманной или даже избыточной функциональности.
2) С помощью ВИ вы можете представить и донести до тех, кому это нужно, скоуп (границы) решения, а также управлять им впоследствии:
- Вы как аналитик можете планировать и организовывать свою работу юз кейс за юз кейсом. Идентифицировали набор ВИ, расставили приоритеты вместе с ЗЛ — и в путь: прорабатывайте их итеративно в порядке приоритета. Так вы будете уверены в том, что с каждой новой итерацией вашей деятельности вы добавляете в плане требований нечто законченно полезное для пользователей. Ну и не стоит забывать о том, что для не-технических ЗЛ юз кейсы как единичка обсуждения более понятны, чем фичи или случайные функциональные требования (сравните «давайте обсудим заказ пиццы в системе» с «давайте обсудим содержимое страницы «Корзина»).
- Ваш ПМ и девелоперы также возьмут юз кейсы на вооружение в качестве единиц для планирования релизов и управления процессом разработки. В ближайший релиз — юз кейс X, в следующий за ним — Y и Z. И, как и с пунктом выше, каждый релиз системы будет содержать не обрывки функциональности (например, страница «Заказ пиццы» как фича), а полноценный полезный сценарий взаимодействия с системой (полный процесс заказа пиццы с достижением ценного для определенного актера результата).
- От кого вы точно получите кучу «спасибок», так это от тестировщиков. У них свои инструменты: сценарии, тест кейсы и пр. И юз кейсы — это прямо-таки идеальная база для их проработки. Тестировщик в рамках некоторой проверяемой единицы будет выполнять определенное действие, смотреть на результат и сравнивать с тем, что заложен в требования. И далее вы увидите, что детализация ВИ в плане наполнения отражает именно такой сценарный подход.
Учтите, правда, что не всегда подобный подход сработает идеально. Есть ряд нюансов, с которыми вы столкнетесь на практике и на разбор которых в рамках обзорной статьи точно не стоит тратить место. Например, нередки ситуации, когда систему можно разбить на 5/10/20 фич, но при этом юз кейсов у подобной системы будет всего два. Скоуп из двух единичек — это точно не что-то репрезентативное, что удобно доносить ЗЛ под грифом «вот, что у нас за система в плане наполнения» со всеми вытекающими. С ограничениями пытаются сразиться в относительно новом подходе Use-Case 2.0, но нельзя сказать, что эта практика стала популярной — лучше посмотрите в сторону фич или user stories в контексте этой задачи (либо вместо, либо в дополнение к ВИ).
Вывод: если у вас нет выработанной и проверенной на практике техники для декомпозиции скоупа решения, попробуйте взять ВИ и проверьте, насколько это сработает в условиях вашего проекта в контексте деятельности всех проектных ролей.
3) Юз кейсы — это отличная увязка задач пользователей и иных актеров (то бишь части требований ЗЛ к решению) с соответствующим им наполнением решения (то бишь требованиями к решению — функциональными и нефункциональными). Далее мы рассмотрим детализацию ВИ и то, как отразить требования к решению в рамках них. Соответственно, ВИ с детализацией — это фактически один из способов документирования требований к решению, которые скомпонованы в рамках родительских требований ЗЛ. Вполне себе спецификация требований получается, из которой а) понятно, для чего в плане задач применима система, б) какие требования необходимо в ней реализовать, дабы позволить актерам выполнить эти задачи.
Вывод: если у вас не выработан подход к документированию требований, попробуйте начать со списка ВИ + их рубашек + диаграммы ВИ (об этом ниже). Это будет отличной отправной точкой, на которой вы можете либо остановиться, либо дополнить недостающими аспектами требований. Удачным такой вариант будет не всегда и не везде, но это уже более сложные и объемные материи.
С чего начать проработку ВИ для решения?
Эту тему я затрону вкратце. Алгоритм по своей сути довольно прост:
1) Идентифицируйте все категории внешних по отношению к решению агентов. Хорошей стартовой точкой может послужить контекстная диаграмма. Соответственно, объекты/субъекты, которые напрямую (есть еще непрямые пользователи, т. е. те, кто пользуется результатами системы опосредованно, не взаимодействуя с системой, но в контексте ВИ они нас не интересуют) взаимодействуют с решением, — это ваши актеры. Но не все они нужны вам на данном этапе. Актеры, как мы далее увидим, тоже могут быть разными. Сейчас нас интересуют именно те актеры, которые получают ценность от взаимодействий с решением.
2) Изучите потребности актеров: что полезное им необходимо получать от взаимодействия с решением.
3) На базе потребностей сформулируйте операции актеров над решением и представьте их в виде ВИ по правилам, которые приведены в начале статьи.
Процесс может показаться весьма кэпским, но по факту это не просто «сесть и подумать», хоть и с подобного стоит начать. Если ударяться в детали и покрывать эти шаги качественно, то речь будет идти уже не о применении ВИ как техники БА, а о процессе проработки требований ЗЛ для БА — а это уже самостоятельная крупная тема, включающая различные техники и подходы к извлечению и анализу требований данного уровня.
Чем дополнить проработку ВИ?
Визуально ВИ можно представить в виде диаграммы вариантов использования (Use Case Diagram из нотации UML). С одной стороны, это инструмент для визуализации списка ВИ, а мы знаем, что графические штуки частенько работают гораздо лучше текста. С другой стороны, этот инструмент добавляет ряд новых аспектов в ВИ в плане связей между ними, что позволяет отразить ряд дополнительных полезняшек.
Вот как может выглядеть диаграмма ВИ для сильно упрощенного новостного портала:
Диаграмма сознательно усложнена, чтобы показать как можно больше фишек, которые UML позволяет отразить, поэтому не стоит ее оценивать как средство упрощения коммуникации.
Давайте разберем диаграмму:
1. Несложно догадаться, что овалы — это юз кейсы, а человечки — актеры (помните при этом, что они могут представлять собой не только человеческих пользователей, но и внешние интерфейсы для IT-решения — программные или аппаратные системы).
2. Стрелочки — это связи, показывающие, кто из актеров какой вариант использования может выполнять, кто является побочным участником ВИ, плюс как некоторые из ВИ или актеров между собой связаны.
3. Можно еще показать границы системы с помощью прямоугольника (элемент boundary в UML), но в большинстве случаев это избыточно.
Теперь детальнее:
Ключевой актер портала — Пользователь. Это любой пользователь системы. Он может быть как аутентифицированным (вошедшим в систему с использованием логина/пароля), так и нет. Это отражено при помощи связи обобщения/наследования. Это такая связь между двумя элементами, которая показывает, что наследник — это дальнейшее уточнение родителя, т. е. элемента, от которого идет наследование. Иными словами, наследник — это то же самое, что и родитель, но со своими спецификами. Аутентифицированный пользователь — это Пользователь, но мы добавили уточняющий параметр: вошел этот человек в систему или нет. По аналогии: Аутентифицированный пользователь может иметь права Администратора (а может не иметь и быть рядовым юзером), что отражено с помощью еще одного наследования.
Пользователь может выполнять ВИ Просмотреть новость, что отражено в виде связи ассоциации между актером и ВИ. Считается, что в наследовании объект-наследник перенимает все свойства объекта-родителя (но при этом, как правило, добавляет что-то свое, потому он и наследник), поэтому по данной концепции все наследники Пользователя по цепочке также могут выполнять данный ВИ: Аутентифицированный пользователь, Неаутентифицированный пользователь, Администратор. И это логично, т. к. новость могут просмотреть все, вне зависимости от статуса в системе. Зачем вообще мы нагрузили диаграмму наследованиями между актерами? Например, а) для того, чтобы общие для всех ВИ ассоциировать с актером-родителем и тем самым не плодить много ассоциаций и не перегружать диаграмму, б) чтобы показать иерархическую структуру актеров, если мы хотим отразить это на диаграмме.
Реже, но все же встречается применение связи наследования для вариантов использования. Если два варианта использования связаны обобщением, это означает что потомок — это то же самое по своей сути, что и родитель, но с уточнениями. Например, мы отразили, что «Войти в систему» может представлять собой три разных полезных действия: войти в систему с помощью VK, Facebook или Google-аккаунта. При этом «Войти в систему» у нас написан курсивом, т. к. это обозначает то, что родитель — абстрактный (если по-научному), или не должен выполняться сам по себе — выполняются только его наследники (если по-простому): нет реального исполнения абстрактного входа в систему; есть вход через одну из трех опций.
Давайте теперь посмотрим на сам ВИ «Войти в систему». Пытливый аналитик возопит: как же так, это же не самостоятельно полезный юз кейс!? Какой смысл идти в систему, чтобы только в нее войти? Да, все верно, это нарушение одного из ключевых правил. Но плох тот специалист, который бездумно следует правилам ради самого этого факта — иногда для благой цели стоит и пожертвовать ими. Чего мы добились, сделав это тут? Во-первых, мы сделали скоуп полнее и нагляднее (без входа в систему никто и не узнал бы, что у нас будет функциональность логина в системе). Во-вторых, мы показали, что логин может быть трех видов, и отразили это, выделив подобный «некорректный» ВИ. В-третьих, мы показали, что у неаутентифицированного чувака тоже есть свои специфичные действия в системе — он не просто так висит для красоты на диаграмме.
Теперь о том, почему некоторые ассоциации имеют направление, а некоторые — нет. Дело в том, что актеры для ВИ могут быть первичными или вторичными. Первичный актер — это актер в ранее изученном нами понимании: тот, кто получает ключевую пользу от выполнения ВИ (и, как следствие, обычно инициирует его выполнение, но это не в 100% случаев так); он для ВИ должен быть указан обязательно. Вторичный актер – это тот, кто участвует неким иным образом в выполнении варианта использования; таких актеров у ВИ вполне себе может и не быть. Например, в случае с банкоматом у ВИ «Снять наличные» или «Просмотреть баланс на карте» первичным актером будет Пользователь банкомата. В качестве вторичного актера можно указать некий процессинговый центр — это некий опять-таки внешний по отношению к системе Банкомат субъект, который вовлекается на определенном шаге сценария ВИ: в процессинговый центр банкомат будет отправлять запрос либо на корректировку суммы на счете Пользователя, либо на получение размера этой суммы в принципе (самостоятельно банкомат не сумеет понять, сколько у вас на счете денежек). В нашем новостном портале у ВИ логина с помощью разных опций вторичными актерами будут являться те программные системы (внешние программные интерфейсы), с помощью которых новостной портал будет, собственно, аутентифицировать пользователей.
Так вот, в плане визуального отображения, если на диаграмме у вас нет такого явления, как вторичные актеры, ассоциации можно делать ненаправленными (т. е. не рисовать стрелочку на конце таких связей). Если же вторичные актеры есть, то для того, чтобы понять, кто из человечков на диаграмме каким типом актера является по отношению к каждому юз кейсу, нужно обязательно рисовать стрелочки на конце. Причем стрелочки не показывают направления потоков данных или нечто подобное — все просто: связь должна идти от первичного актера к ВИ и от ВИ — ко вторичному актеру.
И напоследок расскажу о двух типах связей, которые позволяют показать дополнительные отношения между ВИ — extend (расширение) и include (включение). Связи схожи и обладают похожими свойствами. Во-первых, обе они, как правило, усложняют диаграмму, т. к. вносят в нее дополнительный смысл, а потому многие не рекомендуют именно из-за перегрузки диаграмм их использовать. Во-вторых, разные люди по-разному понимают значение этих связей. Самими авторами нотации эти связи признаны двусмысленными, а потому они рекомендуют относиться к ним осторожно (неоднозначные вещи могут по-разному быть трактованы читателями, а потому может потеряться смысл использования нотации моделирования в принципе). В-третьих, при использовании этих связей допускается, чтобы включаемый и расширяющий элементы не были самостоятельно полезными ВИ. Далее увидим это на примерах.
Что такое include (включение)? Включение — это отношение между вариантами использования, показывающее, что с позиции сценариев и прочих параметров (см. детализацию ВИ ниже в статье) один юз кейс полностью включает в себя другой юз кейс. Если как Администратор я добавляю новость на сайт, я обязательно должен при этом внести текст этой новости. Направление связи, при этом, идет по чтению названия связи. А include Б. C помощью подобной связи можно показать процесс и его подпроцессы. Соответственно, Б («Внести текст новости» в нашем случае) может и не быть полезным, ведь не всякий ВИ можно разбить на ряд детальных и все еще самостоятельно полезных ВИ (т. е. тех ВИ, которые можно выполнять и вне родительского включающего ВИ).
Что такое расширение (extend)? Расширение — это отношение между вариантами использования, показывающее, что с позиции сценариев и прочих параметров один юз кейс может расширять собой поведение другого, т. е. может (тут не обязательность, как в случае с include) быть дополнением к расширяемому юз кейсу. Направление идет также по чтению связи, но в сравнении со включением этот порядок иной: если Б extend А, то это означает, что в процессе выполнения юз кейса А («Просмотреть новость») при определенных условиях или по желанию актер может выполнить также юз кейс Б («Откомментировать новость»). Соответственно, Б, при этом, может и не быть полезным, а быть только несамостоятельным дополнением-расширением к ВИ А. «Откомментировать новость», не просмотрев ее, нельзя. Заметьте, акцент в ВИ ставится не на действиях пользователя, над которым у нас нет контроля (а-ля просмотр новости глазами), а на операциях в решении (открытие новости для просмотра и отображение ее на экране).
В общем, обе эти связи полезны, когда вам хочется показать читателю, что «в процессе выполнения ВИ X актер обязательно должен выполнить еще вот такой подпроцесс Y» или «в процессе выполнения ВИ X актер может, если захочет или если фишка ляжет, выполнить еще и вот такой ВИ Y». Не стоит злоупотреблять такими связями — мы уже говорили, чем они опасны. Однако подчеркнуть наиболее яркие моменты такого плана вполне можно.
По итогу, идентифицировав набор ВИ для системы, плюс визуализировав их на диаграмме, мы закрыли первые две задачи БА из списка в начале статьи: встать на место пользователя и подумать, что полезного он сможет сделать с решением, и декомпозировать скоуп решения на некие единички. Давайте теперь поговорим о том, как закрыть третью задачу (проработать и увязать в рамках документации требования к решению в контексте ВИ).
Давайте разберем диаграмму:
1. Несложно догадаться, что овалы — это юз кейсы, а человечки — актеры (помните при этом, что они могут представлять собой не только человеческих пользователей, но и внешние интерфейсы для IT-решения — программные или аппаратные системы).
2. Стрелочки — это связи, показывающие, кто из актеров какой вариант использования может выполнять, кто является побочным участником ВИ, плюс как некоторые из ВИ или актеров между собой связаны.
3. Можно еще показать границы системы с помощью прямоугольника (элемент boundary в UML), но в большинстве случаев это избыточно.
Теперь детальнее:
Ключевой актер портала — Пользователь. Это любой пользователь системы. Он может быть как аутентифицированным (вошедшим в систему с использованием логина/пароля), так и нет. Это отражено при помощи связи обобщения/наследования. Это такая связь между двумя элементами, которая показывает, что наследник — это дальнейшее уточнение родителя, т. е. элемента, от которого идет наследование. Иными словами, наследник — это то же самое, что и родитель, но со своими спецификами. Аутентифицированный пользователь — это Пользователь, но мы добавили уточняющий параметр: вошел этот человек в систему или нет. По аналогии: Аутентифицированный пользователь может иметь права Администратора (а может не иметь и быть рядовым юзером), что отражено с помощью еще одного наследования.
Пользователь может выполнять ВИ Просмотреть новость, что отражено в виде связи ассоциации между актером и ВИ. Считается, что в наследовании объект-наследник перенимает все свойства объекта-родителя (но при этом, как правило, добавляет что-то свое, потому он и наследник), поэтому по данной концепции все наследники Пользователя по цепочке также могут выполнять данный ВИ: Аутентифицированный пользователь, Неаутентифицированный пользователь, Администратор. И это логично, т. к. новость могут просмотреть все, вне зависимости от статуса в системе. Зачем вообще мы нагрузили диаграмму наследованиями между актерами? Например, а) для того, чтобы общие для всех ВИ ассоциировать с актером-родителем и тем самым не плодить много ассоциаций и не перегружать диаграмму, б) чтобы показать иерархическую структуру актеров, если мы хотим отразить это на диаграмме.
Реже, но все же встречается применение связи наследования для вариантов использования. Если два варианта использования связаны обобщением, это означает что потомок — это то же самое по своей сути, что и родитель, но с уточнениями. Например, мы отразили, что «Войти в систему» может представлять собой три разных полезных действия: войти в систему с помощью VK, Facebook или Google-аккаунта. При этом «Войти в систему» у нас написан курсивом, т. к. это обозначает то, что родитель — абстрактный (если по-научному), или не должен выполняться сам по себе — выполняются только его наследники (если по-простому): нет реального исполнения абстрактного входа в систему; есть вход через одну из трех опций.
Давайте теперь посмотрим на сам ВИ «Войти в систему». Пытливый аналитик возопит: как же так, это же не самостоятельно полезный юз кейс!? Какой смысл идти в систему, чтобы только в нее войти? Да, все верно, это нарушение одного из ключевых правил. Но плох тот специалист, который бездумно следует правилам ради самого этого факта — иногда для благой цели стоит и пожертвовать ими. Чего мы добились, сделав это тут? Во-первых, мы сделали скоуп полнее и нагляднее (без входа в систему никто и не узнал бы, что у нас будет функциональность логина в системе). Во-вторых, мы показали, что логин может быть трех видов, и отразили это, выделив подобный «некорректный» ВИ. В-третьих, мы показали, что у неаутентифицированного чувака тоже есть свои специфичные действия в системе — он не просто так висит для красоты на диаграмме.
Теперь о том, почему некоторые ассоциации имеют направление, а некоторые — нет. Дело в том, что актеры для ВИ могут быть первичными или вторичными. Первичный актер — это актер в ранее изученном нами понимании: тот, кто получает ключевую пользу от выполнения ВИ (и, как следствие, обычно инициирует его выполнение, но это не в 100% случаев так); он для ВИ должен быть указан обязательно. Вторичный актер – это тот, кто участвует неким иным образом в выполнении варианта использования; таких актеров у ВИ вполне себе может и не быть. Например, в случае с банкоматом у ВИ «Снять наличные» или «Просмотреть баланс на карте» первичным актером будет Пользователь банкомата. В качестве вторичного актера можно указать некий процессинговый центр — это некий опять-таки внешний по отношению к системе Банкомат субъект, который вовлекается на определенном шаге сценария ВИ: в процессинговый центр банкомат будет отправлять запрос либо на корректировку суммы на счете Пользователя, либо на получение размера этой суммы в принципе (самостоятельно банкомат не сумеет понять, сколько у вас на счете денежек). В нашем новостном портале у ВИ логина с помощью разных опций вторичными актерами будут являться те программные системы (внешние программные интерфейсы), с помощью которых новостной портал будет, собственно, аутентифицировать пользователей.
Так вот, в плане визуального отображения, если на диаграмме у вас нет такого явления, как вторичные актеры, ассоциации можно делать ненаправленными (т. е. не рисовать стрелочку на конце таких связей). Если же вторичные актеры есть, то для того, чтобы понять, кто из человечков на диаграмме каким типом актера является по отношению к каждому юз кейсу, нужно обязательно рисовать стрелочки на конце. Причем стрелочки не показывают направления потоков данных или нечто подобное — все просто: связь должна идти от первичного актера к ВИ и от ВИ — ко вторичному актеру.
И напоследок расскажу о двух типах связей, которые позволяют показать дополнительные отношения между ВИ — extend (расширение) и include (включение). Связи схожи и обладают похожими свойствами. Во-первых, обе они, как правило, усложняют диаграмму, т. к. вносят в нее дополнительный смысл, а потому многие не рекомендуют именно из-за перегрузки диаграмм их использовать. Во-вторых, разные люди по-разному понимают значение этих связей. Самими авторами нотации эти связи признаны двусмысленными, а потому они рекомендуют относиться к ним осторожно (неоднозначные вещи могут по-разному быть трактованы читателями, а потому может потеряться смысл использования нотации моделирования в принципе). В-третьих, при использовании этих связей допускается, чтобы включаемый и расширяющий элементы не были самостоятельно полезными ВИ. Далее увидим это на примерах.
Что такое include (включение)? Включение — это отношение между вариантами использования, показывающее, что с позиции сценариев и прочих параметров (см. детализацию ВИ ниже в статье) один юз кейс полностью включает в себя другой юз кейс. Если как Администратор я добавляю новость на сайт, я обязательно должен при этом внести текст этой новости. Направление связи, при этом, идет по чтению названия связи. А include Б. C помощью подобной связи можно показать процесс и его подпроцессы. Соответственно, Б («Внести текст новости» в нашем случае) может и не быть полезным, ведь не всякий ВИ можно разбить на ряд детальных и все еще самостоятельно полезных ВИ (т. е. тех ВИ, которые можно выполнять и вне родительского включающего ВИ).
Что такое расширение (extend)? Расширение — это отношение между вариантами использования, показывающее, что с позиции сценариев и прочих параметров один юз кейс может расширять собой поведение другого, т. е. может (тут не обязательность, как в случае с include) быть дополнением к расширяемому юз кейсу. Направление идет также по чтению связи, но в сравнении со включением этот порядок иной: если Б extend А, то это означает, что в процессе выполнения юз кейса А («Просмотреть новость») при определенных условиях или по желанию актер может выполнить также юз кейс Б («Откомментировать новость»). Соответственно, Б, при этом, может и не быть полезным, а быть только несамостоятельным дополнением-расширением к ВИ А. «Откомментировать новость», не просмотрев ее, нельзя. Заметьте, акцент в ВИ ставится не на действиях пользователя, над которым у нас нет контроля (а-ля просмотр новости глазами), а на операциях в решении (открытие новости для просмотра и отображение ее на экране).
В общем, обе эти связи полезны, когда вам хочется показать читателю, что «в процессе выполнения ВИ X актер обязательно должен выполнить еще вот такой подпроцесс Y» или «в процессе выполнения ВИ X актер может, если захочет или если фишка ляжет, выполнить еще и вот такой ВИ Y». Не стоит злоупотреблять такими связями — мы уже говорили, чем они опасны. Однако подчеркнуть наиболее яркие моменты такого плана вполне можно.
По итогу, идентифицировав набор ВИ для системы, плюс визуализировав их на диаграмме, мы закрыли первые две задачи БА из списка в начале статьи: встать на место пользователя и подумать, что полезного он сможет сделать с решением, и декомпозировать скоуп решения на некие единички. Давайте теперь поговорим о том, как закрыть третью задачу (проработать и увязать в рамках документации требования к решению в контексте ВИ).
