Кей юзер что это
key user
Смотреть что такое «key user» в других словарях:
Key-User — Der Begriff Key User wird im Zuge der Einführung betriebswirtschaftlicher Software (z. B. ERP Systeme) genutzt. Der Key User selbst ist ein Mitarbeiter des Unternehmens, welches die betriebswirtschaftliche Software einführt. Der Key User… … Deutsch Wikipedia
Key exchange — is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If Alice and Bob wish to exchange encrypted messages, each must be equipped to decrypt received messages and to… … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia
KEY-Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
KEY Resource Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
User environment management — (also abbreviated to UEM) is a computing term used to describe the management of a users experience within their desktop environment.The user environmentIn a modern workplace an organisation grants each user access to an operating system and the… … Wikipedia
Key Sounds Label — Key ist ein japanischer Spieleentwickler unter dem Publisher Visual Art’s und bekannt für seine dramatischen und handlungsgorientierten Ren’ai Adventures. Keys Debütwerk Kanon kombinierte eine komplexe Handlung mit moderner Anime Grafik und… … Deutsch Wikipedia
Key performance indicator — Key Performance Indicators (KPI) are financial and non financial metrics used to help an organization define and measure progress toward organizational goals [ [http://management.about.com/cs/generalmanagement/a/keyperfindic.htm Key Performance… … Wikipedia
User Datagram Protocol — (UDP) is one of the core protocols of the Internet Protocol Suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal… … Wikipedia
key user
Смотреть что такое «key user» в других словарях:
Key-User — Der Begriff Key User wird im Zuge der Einführung betriebswirtschaftlicher Software (z. B. ERP Systeme) genutzt. Der Key User selbst ist ein Mitarbeiter des Unternehmens, welches die betriebswirtschaftliche Software einführt. Der Key User… … Deutsch Wikipedia
Key exchange — is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If Alice and Bob wish to exchange encrypted messages, each must be equipped to decrypt received messages and to… … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia
KEY-Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
KEY Resource Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
User environment management — (also abbreviated to UEM) is a computing term used to describe the management of a users experience within their desktop environment.The user environmentIn a modern workplace an organisation grants each user access to an operating system and the… … Wikipedia
Key Sounds Label — Key ist ein japanischer Spieleentwickler unter dem Publisher Visual Art’s und bekannt für seine dramatischen und handlungsgorientierten Ren’ai Adventures. Keys Debütwerk Kanon kombinierte eine komplexe Handlung mit moderner Anime Grafik und… … Deutsch Wikipedia
Key performance indicator — Key Performance Indicators (KPI) are financial and non financial metrics used to help an organization define and measure progress toward organizational goals [ [http://management.about.com/cs/generalmanagement/a/keyperfindic.htm Key Performance… … Wikipedia
User Datagram Protocol — (UDP) is one of the core protocols of the Internet Protocol Suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal… … Wikipedia
Все ли вы знаете о React key?
Я время от времени провожу собеседования, и когда вопрос касается React key, чаще всего я вижу недоумевающий взгляд, намекающий “Да, там и спрашивать вроде нечего?”. Если Вам кажется React key понятным и простым, тогда давайте проведем мини собеседование (данная статья является расшифровкой видео).
Задачка разминка
Постановка задачи
Представьте, что у нас есть массив из трех пользователей. Структура пользователя максимально примитивная, всего 2 поля, это id — уникальный идентификатор и второе поле name — собственно имя пользователя.
Попробуем отрисовать этих пользователей, для этого используем следующий код:
Давайте рассмотрим, что из себя представляем компонент User.
Я написал этот компонент на классах, для лучшей наглядности жизненного цикла. И еще один момент на который хотелось бы обратить внимание это — PureComponent. Это значит, что компонент обновится, только в случае изменения свойств (props).
В итоге в браузере мы увидим примерно следующую картину:
Мы видим список из трех имен, а в консоли видим три записи, а именно DID MOUNT для каждого пользователя. Пока все логично и предсказуемо.
Интрига задачи и Вопрос
А теперь перейдем собственно к интриге задачи. Допустим у первого пользователя изменилось имя, у второго пользователя как бы это странно не звучало изменилось id, а у третьего ничего не изменилось.
Внимание вопрос!
Какие новые логи вы увидите в консоли?
Даем минутку подумать, можете поставить на паузу и попробовать ответить самостоятельно.
Осторожно Ответ!
Ну что, давайте сравнивать ответы. В браузере мы видим следующую картину:
На самой страничке мы видим, что Alexander изменился на Maxim, а Dmitriy и Anton, остались на первый взгляд без изменений. А в консоли мы видим следующие логи:
Напишите в комментарии, правильно ли вы ответили? И если нет, в чем была ошибка
Разбор ответа
Давайте разберемся, почему мы получили именно такие результаты
В случае пользователя Anton, key и name до перерисовки, совпадают с key и name после перерисовки, а я напоминаю что сам компонент User это PureComponent. Соответственно никаких перерисовок компонента не произошло и следственно записей в консоли не появилось.
Пользователь Alexander изменил свойство name на Maxim, а при изменении props компонент перерисовывается и логично, что вызывается componentDidUpdate. Соответственно мы и увидели запись в консоли, о том что компонент обновился.
И самый непонятный пользователь Dmitriy, не смотря на то что компонент User это PureComponent и мы не меняли name, с компонентом все равно что-то происходило. А именно прошлый пользователь Dmitriy уничтожился и новый клон Dmitriy создался заново. О чем свидетельствуют записи в консоли WILL UNMOUN и DID MOUNT.
В этом и состоит суть React key. Если ДО обновлений, key существовал, а ПОСЛЕ обновлений key исчез, то не важно, чему был присвоен key, этот компонент в любом случае будет уничтожен. И наоборот, если ДО обновлений key не существовал, а ПОСЛЕ обновлений key появился, тогда этот компонент в любом случае будет создан с нуля. Хотя со стороны пользователя в данном примере вы не увидите никаких изменений, как был Dmitriy так он и остался, разница может быть видна только в более сложных компонентах, или при их большом количестве
Задачка посложнее
Идею я думаю вы уловили, но любую теорию нужно закрепить более сложными примерами!
Предыстория
Как вы знаете в React сообществе бытует один спор. Это стоит ли использовать index в качестве ключа. С одной стороны люди говорят, ни в коем случае и написали даже eslint правило, которое запрещает использовать index внутри key. С другой стороны ребята используют и особых проблем по этому поводу не испытывают.
Чтобы разобраться в этой проблеме, я бы для начала заглянул, что об этом говорит React документация:
А как именно негативно, рассмотрим в следующем примере.
Постановка задачи
Возьмем все тех же пользователей, только теперь их будет 5 для лучшей наглядности.
Для key будем использовать вместо id — index
А компонент User остался без изменений.
В итоге в браузере мы увидим 5 пользователей и в консоли по одной записи DID MOUNT для каждого пользователя. Далее происходит следующее, второго пользователя Dmitriy удалили из списка.
Вопрос
И тут возникает вопрос, какие логи появятся в консоли после обновлений?
Ставьте на паузу и подумайте над ответом.
Осторожно Ответ!
И так результат будет следующим
Первый лог и самый спорный это WILL UNMOUNT Andrey, спорный он потому что, мы удаляли Dmitriy, а удалился Andrey. Следующие 3 лога уже немного поясняют, то что произошло на самом деле. Мы видим DID UPDATE для трех пользователей.
Разбор ответа
Давайте еще раз разберемся, что именно произошло. Было 5 пользователей. И мы начинаем мыслить как пользователь, т.е. мы нажали кнопку удалить второго пользователя Dmitriy. Соответственно и ожидаем, что именно компонент второго пользователя будет удален, а остальные компоненты останутся без изменений.
А теперь давайте рассмотрим, как это видит React. До обновлений было 5 компонентов, каждому из них присвоили key. После обновлений стало 4 компонента. Каждому так же присвоен key. И react, с помощью одинакового key, соотносит компонент до рендера, с компонентом после рендера.
А теперь давайте посмотрим какие имена соответствуют этим ключам.
И тут начинаешь понимать, почему логи были именно такими. В компоненте, котором находился Dmitriy, теперь передали просто новый props name со значением Anton. Соответственно мы и увидели лог DID UPDATE. Тоже самое произошло и со следующими двумя компонентами, поэтому мы и увидели в консоли 3 раза DID UPDATE. А key равный 5, перестал существовать, собственно поэтому мы и увидели WILL UNMOUNT Andrey, а не WILL UNMOUNT Dmitriy.
Подведем итог задаче
Если бы мы использовали id, а не index в качестве значения для key. Все было бы совсем по другому, и у нас действительно удалился бы только один компонент который содержал пользователя Dmitriy, а остальные остались бы без изменений. Именно про такие негативные последствия и предупреждали нас в React документации. И удаление элемента как вы понимаете, это не единственный случай, когда у нас могут быть лишние рендеры, так же при drag and drop, добавлении нового элемента в середину списка и даже более специфические ситуации.
Домашка
Например представьте что у пользователей появились роли, обычный пользователь и администратор:
И в зависимости от роли рисуется, если это обычный пользователь, компонент User, а если это администратор, то компонент Admin. Для key мы по прежнему используем index.
И тут снова удалили пользователя Dmitriy.
Как думаете в этом случае какие логи будут в консоли?
Ответ я не буду раскрывать, оставлю это уже для самостоятельного изучения…
Заключение
Особенного итога в данной статье нет. Надеюсь Вам было просто интересно и любопытно выполнять мои задачки и возможно вы открыли для себя, что то новое, а если Вам настолько понравилось и Вы хотите еще, ловите ссылку.
Начало работы
Создание сервисного пользователя и настройка доступа
Для работы с S3 в Облачном хранилище в панели управления:
Для работы в конфигурационном файле используйте логин и пароль созданного пользователя:
Администратор по умолчанию имеет доступ на чтение и запись к любому бакету. Доступ администратора через S3 API возможен только если отмечено «Использовать эти данные для доступа по протоколу S3» в панели управления в разделе Пользователи.
Бакет (bucket) — это логическая сущность, которая помогает организовать хранение объектов.
URL для доступа (endpoint_url):
Аутентификация
Мы поддерживаем как AWS Signature V4, так и AWS Signature V2 для совместимости с более старыми версиями клиентов.
Все описанное ниже относится только к AWS Signature V4.
Для подтверждения личности запрашивающего все запросы должны иметь подпись, которую можно создать с помощью Access Key и Secret Key.
Вычисление подписи
Вычисление подписи состоит из трех шагов:
Получение ключа для подписи (SigningKey)
Для получения подписывающего ключа понадобится Access Key и Secret Key. Подробнее о том, где их найти в разделе Создание сервисного пользователя и настройка доступа.
Для получения подписывающего ключа закодируйте с помощью алгоритма HMAC-SHA256 следующие данные:
Получение строки для подписи
Получение строки для подписи зависит от используемого метода аутентификации и описано в соответствующем разделе.
Мы поддерживаем три метода подписи запросов:
Подпись строки с помощью ключа
Для создания подписи закодируйте строку подписи полученным ранее ключом и переведите результат в шестнадцатеричное представление.
Через HTTP-заголовок Authorization
Использование заголовка Authorization является наиболее частным методом аутентификации пользователя. Общий вид запроса:
Описание параметров запроса
Канонический запрос (Canonical Request)
Для того, чтобы получить строку для подписи необходимо сделать канонический запрос следующего вида:
)). В случае, если тела запроса нет, хэш необходимо посчитать от пустой строки Hex(SHA256Hash(“”)).
Получение строки для подписи
Строка для подписи представляет собой конкатенацию следующих строк:
Подробнее о способе аутентификации через Authorization заголовок читайте в официальной документации Amazon S3 API.
Используя query-параметры
Аутентификация через query-параметры используется как правило тогда, когда вы хотите указать все параметры запроса непосредственно в URL. Этот метод так же обозначается как подписанный URL (Presigned URL).
Пример подписанной URL:
Описание параметров запроса
Получение строки для подписи
Получение строки для подписи аналогично получению в строки для подписи в [методе аутентификации через HTTP-заголовок Authorization](), за исключением процесса создания Канонического запроса:
Подробнее о способе авторизации через query-параметры читайте в официальной документации Amazon S3 API.
Используя HTML-форму
Использование данного метода предполагает:
Создание HTML-формы
Общий вид html формы:
Для объявления формата HTML формы необходимо указать следующие атрибуты:
Например для бакета examplebucket:
Можно указать дополнительные параметры загрузки с помощью специальных полей в форме. Описание этих полей в официальной документации Amazon S3 API.
Создание POST политики
С помощью политик можно более детально разграничить доступ и условия загружаемых объектов. В зависимости от разработки документа политики, можно контролировать гранулярность доступа для каждой загрузки, для каждого пользователя, для всех загрузок или в соответствии с той архитектурой доступа, которая соответствует вашим потребностям.
Пример POST политики:
Политика POST обязательно должна содержать следующие элементы:
Двадцать лет с юзкейсами: выжимаем практический опыт
У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.
Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.
Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.
Мои отношения с юзкейсами начались в 1996 году и складывались поначалу не очень хорошо. Я тогда работал на предприятии связи, и у меня был халявный интернет. По дайлапу, через телефонный модем на 9600 бод я бороздил просторы тогдашнего интернета в поисках методики, которая помогла бы мне описать функциональность комплексной информационной системы предприятия.
Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».
Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.
Проблему биллинга в конце концов решили — купили у стороннего вендора, потом несколько лет внедряли. Но я к тому времени уже был далеко. Юзкейсы писать тогда так и не научился и, в общем, не ощущал особого дискомфорта.
В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.
Что такое юзкейс?
Есть разные определения, они на первый взгляд сильно различаются. Самое невнятное встречается у Коберна, он определяет юзкейс как «соглашение о поведении рассматриваемой системы». Правда, у Коберна была целая книжка чтобы раскрыть и уточнить свое определение.
А вот определение из глоссария UML (перевод мой).
Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.
Какое определение я сам стараюсь держать в голове, когда пишу юзкейс? Оно должно мне подсказывать, что я должен сделать, о чем мне надо не забыть написать:
Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.
Оно короткое, и это хорошо. Но в нем есть несколько неявных умолчаний. О которых я тоже помню, разрабатывая юзкейс. Вот полный вариант:
Юзкейс — это текст,
описывающий сценарий (возможно, не один)
взаимодействия (кого или чего?) с системой,
приводящий (возможно, не приводящий)
к значимому (для кого?) результату.
Такое определение говорит мне, что из описания юзкейса должны быть понятны:
Установка курсов для пользователей QIWI Кошелька
Что не нужно в юзкейсе
Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:
Разрабатывая юзкейс, вы не должны накладывать преждевременных ограничений на дизайн. Взгляните на юзкейс выше. В нем нет деталей экранных форм и управляющих элементов интерфейса. Пользователь будет выбирать вариант из выпадающего списка, выбором опции или нажатием кнопки? Это сейчас не имеет значения, решения такого уровня следует отложить на потом. Не делайте работу дизайнера, он сделает ее лучше вас.
Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.
Вообще, при выборе информации для включения в юзкейс главным критерием должна быть легкость восприятия. Ради нее можно пожертвовать правилами, подробностью, иногда даже точностью. Главное — чтобы юзкейс был понятен с ходу. Если его трудно понять с ходу — это плохой юзкейс.
Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.
Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.
Условные конструкции
Одно из основных требований Коберна — отсутствие ветвлений в сценарии. Если есть альтернативный вариант развития событий, его полагается описать отдельно. Любую, сколь угодно сложную блок-схему с ветвлениями и циклами можно представить в виде набора линейных участков.
Я не всегда следую этому правилу. Признаюсь, я подправил свой юзкейс перед тем, как выложить его сюда в качестве примера. А в оригинале он выглядел вот так. Отличия начинаются с п.3.
Сценарий установки курсов
Бизнес-правила
Как сочетать лаконичность юзкейса с множеством деталей, которые обычно нужны, чтобы спроектировать пользовательский интерфейс и разработать код? Для этого я сопровождаю юзкейс списком бизнес-правил, которые должны учитываться при реализации сценариев.
Вот какие бизнес-правила были приложены к юзкейсу из примера.
Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.
Когда систем несколько
Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.
Этот подход можно назвать «одноклеточным». Мы сосредотачиваемся на том, что происходит в клеточной мембране, и игнорируем до поры до времени всё остальное.
Но в реальности мы живем в многоклеточном организме. У компании много систем, они взаимодействуют между собой и совместно реализуют множество функций бизнеса. Почти в каждом проекте мы должны удовлетворить очередную потребность компании через внесение изменений, по возможности минимальных, в несколько систем.
У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.
Я предпочитаю в своих юзкейсах не делать различий между системами, к которым мы ставим требования, и внешними акторами. Каждая из систем, которые мы модифицируем, считается таким же участником взаимодействия, как и все остальные. С точки зрения классической методики так нельзя: система — то что внутри, акторы — то что снаружи.
Зато мой подход позволяет извлечь набор функциональных требований к каждой системе по отдельности. Берем все шаги юзкейсов, в которых участвует данная система. Смотрим, существующая ли это функциональность или новая, или существующая, но с какими-то изменениями. Шаги, в которых нет изменений, выкидываем. То, что остается — передаем команде разработчиков системы для детальной технической проработки. Повторяем для каждой из систем, участвующих в юзкейсах проекта.
Сказуемое без подлежащего
Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.
Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров».
Пробежав глазами начальные слова шагов, легко собрать список участников. Я предпочитаю не выписывать отдельно список участников в начале юзкейса, это тормозит читателя и мешает ему скорее перейти к чтению сценария.
Неуспешные сценарии
Иногда в проектах забывают предусмотреть случаи, когда что-то происходит не так. К примеру, клиент совершил покупку, а потом захотел ее вернуть. Если об этом не подумали заранее, то приходится срочно допиливать код после запуска. А в тяжелых случаях — выбросить всё и организовать взаимодействие систем в другом порядке.
Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.
Если в проекте описаны только основные сценарии юзкейсов, то велик риск, что забыли что-то важное.
Модель предметной области
Юзкейсы должны опираться на модель предметной области, которую все участники проекта понимают одинаково. Вспомним первый шаг нашего примера: «Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки)». В одном пункте употреблено пять понятий. Некоторые из них новые, возникли только в этом проекте.
Самый известный инструмент введения в предметную область — глоссарий. Следует включать в глоссарий только те слова, которые кому-то могут быть непонятны. Если начать объяснять всё, то после первых трех пунктов читателю станет скучно и он закроет глоссарий, не добравшись до важного.
Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:
Имеется список поддерживаемых валют. Этот список делится на две части:
Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».
(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).
Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.
В одном недавнем проекте я на таких картинках по часу в день, в течение двух недель, излагал команде разработки модель предметной области. В результате у всех разработчиков была единая картина понятий, что нам очень помогло в ходе проекта.
Перечень юзкейсов
Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.
Перед вами перечень юзкейсов из другого проекта, он тоже про конвертацию валют. Платежная система обращается в банк чтобы обменять валюту на такую сумму, которой хватит держателям валютных кошельков и получателям платежей.
Здесь информации больше: мы видим участников взаимодействия и в каких юзкейсах они участвуют. Вопреки Коберну, в качестве участников показаны системы, к которым мы ставим требования (расчетная система, АБС), а также внешние неизменяемые системы (биржевой терминал, система бухучета) и пользователи.
Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.
Заключение
Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN.
Тем не менее юзкейсы и сейчас остаются хорошим инструментом анализа, особенно для систем, поддерживающих бизнес-процессы. Любой аналитик или проектный менеджер должен знать методику юзкейсов и уметь ее использовать. Об этом, собственно, и мой пост.