Примеры вариантов использования (Usecase)

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

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

Примечание. Особенно неприятная ситуация с дубликатами происходит, при слиянии данных из разных систем. Это может быть и создание централизованного хранилища справочников  (Master Data Management) для программных комплексов различного назначения, и слияние локальных баз филиалов в центральную.

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

Ситуация 2. В бактрекере часто встречаются записи описывающие одну и ту же проблему. Такая ситуация приводит к отвлечению программистов. Кроме того, может сложиться ситуация, при которой одну и ту же ошибку будут править несколько программистов. Необходимо очистить базу от дубликатов, но при этом по возможности сохранить скриншоты и описания.
В качестве примера многократного дублирования записей об ошибке, читатели могут рассмотреть JRA-1330 из открытого источника.

Рассмотрим несколько вариантов использования (юзкейсов) направленных на очистку данных.

Примечание. Далее по тексту объект, который будет помечен как дубликат, будет обозначаться термином «донор». Объект, на который будут перенесены ссылки с донора, будет называться реципиент. Для реципиента широко распространен термин «Золотая запись».

Вариант А. Пометить дефект как дубликат.
Цель: очистка данных для  уменьшении трудозатрат программистов.
Основное Действующее Лицо (ОДЛ): Тестменеджер
Предусловие: выбран дефект-донор

Основной сценарий:
1.  ОДЛ отдает команду «Пометить как дубликат»
2.  SuD предлагает указать реципиента
3.  ОДЛ указывает реципиента
4.  SuD подтверждает, что дефект-реципиент не находится в состоянии «Дубликат»
5.  SuD переводит дефект-донор в состояние «дубликат»
6.  SuD изменяет ссылки с дефекта-донора на дефект-реципиент (переносит аттачи на дефект остающийся активным)
7.  SuD уведомляет ОДЛ об успешном завершении операции
Альтернативный сценарий:
4.а дефект-реципиент находится в состоянии «Дубликат»
4.а.1 SuD уведомляет ОДЛ о невозможности  успешного завершении операции

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

Примечание. Инженеры Яндекса упоминали об автоматической проверке на дублирование записей, но подробности мне неизвестны.

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

Вариант Б. Сделать неактивными все дублирующиеся объекты, кроме «золотой записи».
Основное Действующее Лицо (ОДЛ): Администратор данных
Предусловие: выбрана группа предположительно дублирующихся объектов

Основной сценарий:
1.  ОДЛ отдает команду на просмотр списка объектов группы
2.  SuD показывает список и предлагает указать реципиента и объекты не являющиеся дубликатами (При автоматическом поиске возможны ложные срабатывания. Так колхозов «Рассвет» в РФ довольно много)
3.  ОДЛ указывает реципиента
4.  ОДЛ указывает объекты, не являющиеся дубликатами
5.  ОДЛ отдает команду «продолжить»
6.  SuD подтверждает, что объект-реципиент не находится в состоянии «Дубликат»
7.  SuD подтверждает, что объект-реципиент в группе единственный
8.  SuD переводит объекты-доноры в состояние «дубликат»
9.  SuD изменяет ссылки с объектов-доноров на объект-реципиент (переносит договора, акты выполненных работ, счета-фактуры и прочие документы на «золотую запись»)
10.  SuD уведомляет ОДЛ об успешном завершении операции

Это другой юзкейс, описывающий по сути туже функциональность, но по другому реализующий взаимодействие пользователя с системой. Возможны и более сложные юзкейсы. На моем тренинге инженеры обычно для одной и той же функциональности предлагают несколько вариантов юзкейсов. Это нормально. Выбор конечного варианта использования проводится на этапе согласования требований.

Некоторые пояснения по нотации:
•  SuD (system under discusion) –рассматриваемая система. Иногда пишут просто «система», но термин «SuD» более точен.
•  ОДЛ – описание, кто именно является основным действующим лицом, выносится в заголовок. Это позволяет сделать описания юзкейсов устойчивым к изменениям.

PS. Данная статья является одной из цикла вводных статей для моего тренинга “Основы  разработки Use Case’ов“ 

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.