Только что разбирали с программистами задачу.

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

Последовательность выполнения такая (пока грубо, это не usecase).
- клиент передаёт свою карту кассиру
- кассир проверяет карту по определённой процедуре (сверяет с паспортом, удостоверением или смотрит фотографию на карте)
- кассир начинает операцию оплаты на кассовом терминале, вводит сумму
- кассир вставляет карту в ПИН пад
...
дальше начинается самое интересное. При выполнении EMV операции карта может потребовать взаимодействия с её владельцем, при этом кассир должен отдать ПИН пад клиенту
...
- клиент выбирает приложение на карте или подтверждает выбор единственного приложения (в зависимости от карты, этот шаг может и не выполняться)
- клиент вводит ПИН, возможно, делая при этом несколько попыток
...
на этом взаимодействие клиента с картой заканчивается, и клиент должен вернуть ПИН пад со вставленной картой кассиру
...
- кассовый терминал связывается с хостом для получения авторизации
- ... и так далее, до завершения операции.

Особенность операции в том, что на определённом этапе ход выполнения транзакции распараллеливается, и в ней участвуют два человека, каждый со своим экраном (экран кассового терминала и экран ПИН пада) и устройством ввода (кассир должен видеть, что происходит с ПИН падом, и может прервать операцию в любой момент со своего терминала). При этом ПИН пад выполняет мастер-приложение, управляющее и экраном ПИН пада, и экраном кассы, но не имеющее доступа к клавиатуре терминала.


Собственно вопрос в том, описываются ли такие ситуации с помощью usecase и если да, то каким образом?

То есть я могу себе представить разбиение на более мелкие варианты, например, выделение ПИН пада и терминала в виде отдельных акторов и описывать взаимодействие всех четырёх участников (на самом деле, тут есть ещё и хост) независимо, но при этом теряется целостность восприятия всей транзакции. Кроме того, получается, что два или больше варианта использования протекают параллельно и зависят друг от друга.

Простой, вроде бы, пример, но при попытке представить его в виде usecase транзакция разваливается на части, которые потом будет трудно интегрировать.

Очень занимательный случай. И думаю его стоит разобрать по косточкам. После чего сказать - теория не верна, или виват теория!

Насколько я понял из текста работа с ПИН падом опциональна. Т.е. мы имеем ответвление основного потока и рождение нового сценария, в котором
а/ клиент управляет приложением
б/кассир наблюдает и может прервать действия клиента.

Что касается пункта б/ то тут я вижу в тексте противоречие:

(кассир должен видеть, что происходит с ПИН падом, и может прервать операцию в любой момент со своего терминала).

и

При этом ПИН пад выполняет мастер-приложение, управляющее и экраном ПИН пада, и экраном кассы, но не имеющее доступа к клавиатуре терминала.

Что означает приложение не имеет доступ к клавиатуре?

Если кассир может прервать транзакцию в любой момент времени - ну и чудно, к какому моменту мы возвращаемся в данном случае.

В чем заключается деятельность клиента во время работы с ПИН падом?

Далее несложно увидеть, что тут явно есть первая часть - это авторизация карты клиента и дальше идет уже типичная оплата.

В целом оплата включается в себя некоторую визуальную верификацию карты и определения суммы оплаты.
Далее аутентификацию платежеспособности карты в целом.
Завершение процедуры опалты...

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

Необходимость выбора приложения и ввода ПИНа определяется, в общем случае, самой картой. Может быть так, что отдавать ПИН пад клиенту и не потребуется.

Я, на самом деле, смутно понимаю свою проблему: мысль о usecase пришла мне в голову, можно сказать, на этапе финального проектирования, но воспарить до уровня определения "чистых" требований я не могу из-за следующих ограничений:

- нужно "прикрутить" поддержку чиповых карт к уже существующему функционалу работы с магнитыми картами. То есть взять и перепроектировать всю архитектуру заново не представляется возможным;

- мы не контролируем разработку приложения кассового терминала, и изменений в нём не будет. Всё, что мы можем делать - посылать ему сообщения "отобрази окно с такой-то информацией";

- для работы с чиповыми картами мы обязаны использовать специальную библиотеку в виде "чёрного ящика" - хитровывернутую, но сертифицированную.

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

Но это всё трудности программистов (ну и мои тоже, конечно). Просто мне нужно получить подтверждение от заказчика на реализуемую схему, и я попытался изложить эту схему в удобоваримом виде. А в качестве "удобоваримого" вида решил попробовать (можно сказать, впервые) usecase и немножечко UML. И, в общем, пока не вижу никаких преимуществ перед простым текстовым описанием.

Хотя с программистами некоторые полезные диаграммки мы нарисовали. Получился некий гибрид диаграммы состояний с диаграммой видов деятельности - "плавательные дорожки" с экранными формами и событиями. Всё это, разумеется, ручкой на бумаге, с пометками.

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

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

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

Необходимость подтверждения выбора приложения или ввода ПИН не зависит от платёжной системы, а определяется данными, считанными непосредственно с карты. Способ проверки определяет банк-эмитент. Мы же должны поддерживать в одном приложении все варианты, заявленные в нашем сертификате EMV.

С точки зрения создания юзкейса общая логика остается прежней -- нужно определить а) что есть условие ветвления, б) сколько у нас возможных веток, в) где точка сходимости этих веток. Исходя из этого принимать решение -- писать альтернативные сценарии или использовать слот "Вариации технологий и данных". Никто не мешает делать ВИ типа subfunction, если кол-во возможных альтернативных сценариев достаточно большое и\или мы должны потом еще добавлять другие платежные системы (потом). Тогда мы просто делаем в альтернативных сценариях перечень условий, возникших в результате считанных данных с карты и отсылаем на соответствующий subfunction юзкейс, но при этом должны указать куда мы возвращаемся из них, тут же в альтернативном сценарии.