Доброго времени суток!

В рамках дипломной работы появилась необходимость описать сценарий работы BI-приложения. Сценарий очень простенький. Однако возникли трудности с выбором нотации. Я работала в одной крупной компании в отделе, которая непосредственно занималась разработкой подобных приложений. Сценарий они описывали в ARIS. Однако каким-то очень корявым способом, потому что использование графических элементов не попадало не под одну известную мне модель. Я решила перенять инструмент моделирования, но сделать описание корректно, а не как в голову взбредет. Долго думала и выбрала eEPC. Но все еще сомневаюсь подходит ли она для описания сценария. Собственно, вопрос следующий: какую нотацию корректнее всего использовать для описания сценария работы BI-приложения? Можно ли использовать eEPC или следует взглянуть в сторону UML?
UML не изучала, поэтому не уверена в его пригодности для описания такого незначительного приложения бизнес-аналитики.
Во вложении прикладываю сценарий, описанный в eEPC.

Добрый день.

А почему сомневаетесь?

Сомневаюсь, потому что в рамках университета не приходилось описывать сценарии работы приложения. Только бизнес-процессы. Мозг уже заточен под то, что нотации используются для описания БП. Однако сейчас почитала немного про UML и насколько я успела понять, он используется для описания объектно-ориентированный приложений. А BI приложения очень простенькие.
Хотелось бы совета от опытных людей в данном вопросе.

Сомневаюсь, потому что в рамках университета не приходилось описывать сценарии работы приложения. Только бизнес-процессы. Мозг уже заточен под то, что нотации используются для описания БП. Однако сейчас почитала немного про UML и насколько я успела понять, он используется для описания объектно-ориентированный приложений. А BI приложения очень простенькие.
Хотелось бы совета от опытных людей в данном вопросе.

Что означает описать сценарий программы? Тут следует уточнить понятия.

Сценарий  - это определенная последовательность действий.
Сценарий может быть описан разными способами и зависит от общепринятых правил и общего контекста.

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

Однако я не вижу проблем в описании сценария в вашем случае,  сам по себе сценарий крайне прост, но тут зависит от того на какую аудиторию вы рассчитываете представляя этот сценарий в виде eEPC схемы.

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

Если между состояниями возможны другие пути перехода, то имеет смысл сделать из них отдельную диаграмму состояний.

А ещё создаётся впечатление, что это приложение всегда работает с одними и теми же данными: после запуска читает их из одних и тех же источников, строит из них одни и те же графические модели, и только после этого появляется человек, которому предоставляется единственная возможность: настроить фильтры и посмотреть, что получится.
Если не получилось то, что нужно, - запускай приложение по новой, считывай данные, строй модели, и так по кругу.


А вообще, ваш случай прекрасно ложится на область применения VISIC
Сценарий взаимодействия можно изобразить схемой "бассейн", состояния и переходы - схемой "гирлянда".

состояния и переходы - схемой "гирлянда".

А зачем тебе состояние Не подтвержден, да еще с принудительным событием Закрыть ? Есть вероятность передумать? Тогда почему переход исключительно в закрыт?

А зачем тебе состояние Не подтвержден, да еще с принудительным событием Закрыть ? Ест вероятность передумать? Тогда почем переход исключительно в закрыт?

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