Добрый день, форумчане!
Подскажите, насколько правильно составлена диаграмма ВИ? Где я накосячил и имеет ли смысл декомпозировать ВИ еще глубже?

Задача звучит примерно так.
Необходимо предоставить администратору системы возможность создавать и настраивать выборки без изменения исходного кода программы.
Результат выборки - подмножество объектов определенного типа с какими-то атрибутами.
Админ занимается только настройкой выборок. Его не сильно волнуют данные, которые предоставляет выборка, это головная боль рядового пользователя.

Админ должен иметь возможность:
1. Выбрать тип объекта, по которому будет строится выборка
2. Настроить фильтры
3. Выбрать поля объекта, которые будут выводиться в результат.

В выборке обязательно должен быть указан тип объекта. В одной выборке может быть указан только 1 тип.
В выборке должно быть добавлено хотя бы одно поле результата.
Добавлять фильтры не обязательно. Выборка без фильтров найдет все объекты указанного типа и выведет указанные поля.
Если фильтров больше 1, между ними необходимо указывать логические операции (and, or, not).
Должна быть возможность объединять фильтры в блоки и указывать между блоками логические операции  (and, or, not).

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

Например, если Найти выборку расширяет Посмотреть список выборок, то может быть Поиск неотъемлемая часть просмотра? Просто поиск по умолчанию -без критериев?

Создать выборку включает выбор типа объекта.
1 - а разве можно создать выборку без указания типа объекта?
2 - а где в схеме выбор типа объекта используется еще, раз это взаимодействие с системой было выделено в отдельный ВИ?

Цепочка Настроить фильтр - Указать логические операции - это плохой стиль. Почему бы тогда не продолжить Указать И, Указать ИЛИ и т.п.

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

Например, если Найти выборку расширяет Посмотреть список выборок, то может быть Поиск неотъемлемая часть просмотра? Просто поиск по умолчанию -без критериев?

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

Создать выборку включает выбор типа объекта.
1 - а разве можно создать выборку без указания типа объекта?
2 - а где в схеме выбор типа объекта используется еще, раз это взаимодействие с системой было выделено в отдельный ВИ?

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

Цепочка Настроить фильтр - Указать логические операции - это плохой стиль. Почему бы тогда не продолжить Указать И, Указать ИЛИ и т.п.

То есть слишком мельчу?!

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

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

Если диаграмма ВИ строится как перечень типов "целей пользователей", связанных с ними типов пользователей, то инклюды с экстендами лишние.
Если диаграмма ВИ строится, чтобы были инклюды с экстендами, то рационально сначала дать описания сценариев текстом, затем в текстовых описаниях увидеть общие (или вспомогательные) места, затем придумать как удобнее эти места оформить -- включаемыми ВИ, расширяющими ВИ, локальными подпотоками (в каждом случае можно применить каждый из 3-х способов).
Чтобы дать совет по приведённой  ДВИ, надо протелепатить из чужой головы сценарии. Мой телепатитель на ремонте.)

Добрый день, форумчане!
Подскажите, насколько правильно составлена диаграмма ВИ? Где я накосячил и имеет ли смысл декомпозировать ВИ еще глубже?

Не надо начинать с диаграммы ВИ. Начните с ВИ. Это две разные практически не пересекающиеся области. Проблема в том, что к "диаграмме ВИ" не прилагается список проверок, а вот к ВИ прилагается.

Поехали.
* Если бы вы были знакомы с CRUDL, то сразу обнаружили бы пропуск ВИ класса "Read"
* CRUDL Это, как правило, ВИ уровня моря. И вам как и кайтингистам нужно научиться не отрываться высоко от уровня моря, чтобы не разбиться потом о воду. Так и не проваливаться вниз. Вам нужно понимать, что такое уровень.

Ну и печаль, печаль. CRUDL устарел. Сейчас в моде что-то типа "CrClRUcUsUtUhDeDaLO". Но об этом вы материала не найдете. Юзайте пока  CRUDL

До кучи.

* Create
* Clone
* Read
* Update content
* Update Status
* Update Type
* Delete
* Deactivate

И т.д.

 

Это чеклист для позитивного тестирования каждого объекта. Простенько, но работает. Регулярно ловятся ошибки. То апдейт не работает, то он работает не как задумывалось. То дилит работает так, что лучше бы его вообще не было.  Например критический баг с удалением в Jira только в версии 6.2 поправили. Я тогда чуть от радости не прыгал. Дюжина лет продукту и вот наконец! Кто-то в Австралии додумался, что удаление задачи логгировать надо!

А причина в том, что в атлассиан не было аналитика, знакомого хотя бы с CRUDL. Или его не послушали.

Чтобы дать совет по приведённой  ДВИ, надо протелепатить из чужой головы сценарии. Мой телепатитель на ремонте.)

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

Сценарии я могу приложить, но думается что там еще 100500 ошибок, кто все это будет читать? Однако для меня только лучше, если кто-то, особенно с другой планеты, скажет где и что я делаю не так (:

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

Отлично, спасибо! Вроде идея капитанская, но только когда ее озвучили, а так была не очевидна.

Не надо начинать с диаграммы ВИ. Начните с ВИ. Это две разные практически не пересекающиеся области. Проблема в том, что к "диаграмме ВИ" не прилагается список проверок, а вот к ВИ прилагается.

Видимо про это же, но слегка по другому, и говорило НЛО

Поехали.
* Если бы вы были знакомы с CRUDL, то сразу обнаружили бы пропуск ВИ класса "Read"
* CRUDL Это, как правило, ВИ уровня моря. И вам как и кайтингистам нужно научиться не отрываться высоко от уровня моря, чтобы не разбиться потом о воду. Так и не проваливаться вниз. Вам нужно понимать, что такое уровень.

Ну и печаль, печаль. CRUDL устарел. Сейчас в моде что-то типа "CrClRUcUsUtUhDeDaLO". Но об этом вы материала не найдете. Юзайте пока  CRUDL

Я знаком с CRUDL от вас в общем-то и узнал
Не стал рассматривать Read по простой причине, планируется, что страница выборки сразу будет открываться в редакторе, то есть сценарий не должен отличаться от update.
А когда можно будет найти материал про "CrClRUcUsUtUhDeDaLO"? Откуда это пошло?

До кучи.
* Create
* Clone
* Read
* Update content
* Update Status
* Update Type
* Delete
* Deactivate

Спасибо! Обязательно поизучаю.

Видимо про это же, но слегка по другому, и говорило НЛО

Да, так и есть.

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

На это я отвечу трехминутным роликом: https://www.youtube.com/watch?v=wzuwv2lcNQA
Ролик к просмотру обязателен. Ну а фильм длинный, но очень хорош.

А когда можно будет найти материал про "CrClRUcUsUtUhDeDaLO"? Откуда это пошло?

Это моя наработка, основанная на изучении множества систем и хотелок заказчиков. В течении многих, многих лет. Узнать об этом можно будет или когда я буду проводить тренинг по ВИ (провожу с 2005), или когда напишу статью. Или когда сделаю доклад.
Насколько мне известно, более этого материала нигде нет.

PS. А если подумать - отличнейшая тема для ЛАФ...

Однако для меня только лучше, если кто-то, особенно с другой планеты, скажет где и что я делаю не так (:

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

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

SALar "развинчивает" Вашу диаграмму не с точки зрения нотации, а с аналитической, со смысловой. Скорее всего, для практических задач это важнее.

Galogen даёт советы, исходя из обоих точек зрения.

ИМХО ещё для определения состава и содержимого ВИ:

• Если фильтров больше 1, между ними необходимо указывать логические операции (and, or, not).
  Должна быть возможность объединять фильтры в блоки и указывать между блоками логические операции  (and, or, not).
  

это относится только к "and" и "or", а "not" имеет смысл именно для одного фильтра/блока

• надо бы детальнее разобраться, что такое "фильтр", что такое "блок":
  • если 2 выборки имеют абсолютно одинаковое условие (состав объектов всегда совпадает, только поля результата разные) - это будет всё равно 2 разных фильтра/блока (одинаковые по содержанию) или может быть один и тот же фильтр/блок, просто подключенный к обоим выборкам?
  • когда блок объединяет более 2 фильтров между каждой парой смежных фильтров может быть своя операция ("and" или "or") или операция задаётся целиком на блок? То есть блок это просто "скобки" для указания порядка операций или средство выделения смыслового фрагмента для повторного использования?

ИМХО ещё для определения состава и содержимого ВИ:

это относится только к "and" и "or", а "not" имеет смысл именно для одного фильтра/блока

• надо бы детальнее разобраться, что такое "фильтр", что такое "блок":
  • если 2 выборки имеют абсолютно одинаковое условие (состав объектов всегда совпадает, только поля результата разные) - это будет всё равно 2 разных фильтра/блока (одинаковые по содержанию) или может быть один и тот же фильтр/блок, просто подключенный к обоим выборкам?
  • когда блок объединяет более 2 фильтров между каждой парой смежных фильтров может быть своя операция ("and" или "or") или операция задаётся целиком на блок? То есть блок это просто "скобки" для указания порядка операций или средство выделения смыслового фрагмента для повторного использования?

Наверно, проще будет приложить макет.

Спасибо всем за комментарии, постараюсь извлечь побольше полезного.
Хотелось бы задать еще один вопрос.

Получается, что пользователь, может добавить фильтр.
Для этого фильтра указать:

• поле обьекта
• условие(<,>,= и т.д)
• значение по умолчанию (не обязательно)

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

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

3

Наверно, проще будет приложить макет.

На картинке изображена такая фильтрация:
[(Стоимость приобретения >= 200 000) И (Тип оборудования <> Автомобиль) И (Является средством измер... = Нет)]
ИЛИ
[(Стоимость приобретения >= 500 000) И (Тип оборудования = Автомобиль)]

Что здесь фильтр, что здесь блок?

Судя по:

Получается, что пользователь, может добавить фильтр.
Для этого фильтра указать:

• поле обьекта
• условие(<,>,= и т.д)
• значение по умолчанию (не обязательно)

имеется 5 фильтров и 2 блока?

значение по умолчанию (не обязательно)

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

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

Скорее не "возможность", а "необходимость".

И вот я не понимаю, как это можно описать в сценариях да и стоит ли?

Если кратко:
можно? - Можно
стоит? - Не стоит