Коллеги, написал небольшую обзорную статейку про ВИ.
http://analitic-info.ru/index.php?option=com_content&task=view&id=20&Itemid=38

Если не затруднит вас - ознакомтесь и выскажитесь.
Жду жесточайшей критики.

Если не затруднит вас - ознакомтесь и выскажитесь.

Вот что приходит на ум:
1. Какие документы можно использовать для формализации пользоват. требований?
2. Что дальше? Когда можно остановиться на пользоват. требованиях, а когда надо продолжить
3. Не описан метод выявленения ВИ или хотя бы ссылки на документы. Будут все до функций декомпозировать ВИ
4. Не сказано, что требования - это все же что делает пользователь с системой, а не как, т.е. сценарий не первичен.
5. Нет методики выявления пользоват. требований: анкеты, методы и т.д.
6. Нет других представлений польз. тр. Не сказано, когда лучше/можно не создавать польз. тр.
7. Все же название статьи должно быть не "ВИ", а "Польз. тр." или "Представление польз. тр. в виде ВИ"

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

Если не затруднит вас - ознакомтесь и выскажитесь.

Статья в общем интересная. Всегда интересно творчество, а не простая компиляция чего-либо:-)

Тем не менее мне не совсем понятна разделение понятий сценарий, вариант использования и сущностный элемент варианта использования.

Перевод essential use case вярд ли назовешь многовариантным.
essential - необходимый, существенный, неотъемлемый, первичный. Я не читал оригинила, могу допустить совершенно иную трактовку прилагательного essential, однако мне думается тут врядли стоит говорить о сущностном элементе - не сосем понятный термин.

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

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

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

Сейчас будет жесточайшая

Почему статья в разделе по UML, а не в требованиях?

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

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

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

Скудно и неэффективно используются гиперссылки. Зачем отсылать на список литературы на отдельной странице, когда можно сослаться на статью, сайт, книгу автора высказывания в электронном магазине?

Более нормативным в английском языке является раздельное написание термина Use Case.

Кстати, издательство "Питер" название книги Локвуд и Константайна настолько жульнически перевело, что имхо его надо непрестанно сопровождать оригиналом.

С вашим с bas'ом и Эдуардовским определением прецедента как "неделимой последовательности..." не согласен категорически. Если в сценарии ясно различимы отдельные шаги, то термин "неделимый" здесь неуместен.

Разделение сценария на 2 дорожки по Вирфс-Брок я бы не стал называть "методологией". На диаграмме деятельности стоило эти 2 дорожки показать, если уж она идёт сразу после Вирфс-Брок.

Ничего не понял про "исходный вид вариантов использования". Исходный - это который?

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

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

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

Коллеги, спасибо за отзывы. До пятницы пусть повисит в исходном виде. На выходных займусь переработкой.

С вашим с bas'ом и Эдуардовским определением прецедента как "неделимой последовательности..." не согласен категорически. Если в сценарии ясно различимы отдельные шаги, то термин "неделимый" здесь неуместен.

Несогласных у нас вешают по вторникам после завтрака, на десерт:-))


Неделимость придумана не мною, а авторами вариантов использования. Читаем хотя бы книгу Максимчука и Нейбруга "Проектирование БД с помощью UML": вариант использования должен твечать правилу WAVE( what, actor, value, entire)

Код: [Выделить]

entire I [In'taIq] n
1. редк.
1) полнота, всеобъемлющий характер
the entire of the night - целая ночь
the entire of his property - всё его имущество
2) целое
the entire flawed by poor workmanship - плохое исполнение /плохая работа/ портит всё
2. с.-х. некастрированное животное, особ. жеребец
3. портер (пиво)

entire II [In'taIq] a
1. полный, целый, весь
the entire country - вся страна
the entire world - целый мир, весь свет
the entire medical profession - все медицинские работники
entire liberty of conscience - полная свобода совести
entire happiness - полное счастье
entire ignorance - а) полное невежество; б) полное неведение
his entire devotion to his family - его безраздельная преданность семье
2. целый, неповреждённый; нетронутый
the fortifications were entire - укрепления были целы (и невредимы)
3. цельный, из одного куска
the book is entire in mood - книга отличается целостностью настроения
his heart was entire - его сердце не было затронуто, он ещё не любил
4. чистый, беспримесный; однородный
5. некастрированный (о животном)
6. уст. чистый; непорочный


можно добавить

Код: [Выделить]

entire contract — неделимый договор  (see contract)

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

в словарной статье ничего про "неделимость" не вижу в упор. Целостность, полноту - да. См. слово "entirety". "Целостность, законченность, полнота"  - в смысле не нужно больше ничего добавлять, а не то, что нельзя делить на части. Нельзя делить на части - это элементарность.

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

1. Неделимость подразумевает невозможность декомпозиции без перехода на другой уровень детализации. Да, если юзкейс уровня "облака", то, в пределе, каждый его шаг может быть отдельным юзкейсом уровня "user goal", но это другой уровень (!) юзкейса.
2. По самому примеру юзкейса ... я бы на скорую руку написал так:
Главный успешный сценарий.
1.   Пользователь инициирует ввод нового автора.
2.   Система формирует диалоговое окно для ввода (коммент. – нужно отдавать отчет что это может быть ОГРАНИЧЕНИМ для разработчика … а вдруг лучше все прямо в гриде вводить)
3.   Пользователь вводит Информацию об авторе и подтверждает ввод (коммент. -- мы не знаем, может лучше чтобы кнопка называласть «Сохранить», а не «ОК»?).
4.   Система подтверждает отсутствие аналогичной записи об авторе в списке ранее сохраненных авторов и отображает введенную Пользователем информацию.
5.   Пользователь подтверждает правильность ввода <нажав что-то …>
6.   Система присваивает новому автору уникальный идентификатор и сохраняет его в списке.

Расширения.
4а. Такой автор имеется в списке.
4а1. Система информирует Пользователя ….
4а2. …..
5а. Пользователь принимает решение внести изменения ...
5а1. ….
6а. В процессе сохранения произошел сбой
6а1. ....


Дополнительная информация.
Информация об авторе = ФИО
+ Псевдоним
+ Дата рождения
+ …

(c) на правах примера мой ;-) ...

Против называния Найбурга и Максимчука "авторами UML" протестую.

А я их нигде и не называл авторами UML. Про авторов вариантов использования - согласен - получилось не хорошо, но я имел в виду Якобсона. Просто Нейбург подвернулся раньше.

Про делимость и неделимость,  я уже с тобой согласился, термин неудачный. Однако просто сказать целостная последовательность - получается глупость. Может Законченая последовательность? или Полная конечная последовательность, ладно суть не в этом.

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

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

Пример, ситуация. Есть сайт, человек регистриться через него на некое мероприятие, ну например конференцию, вносит свои данные и все такое, в ответ система отправляет письмо с подтверждением регистрации.
Пример функции системы -- "Отправка по e-mail уведомления о регистрации на мероприятие" .... если опустить юзкейсы уровня subfunction ... то где тут юзкейс уровня "user goal"? И как это может быть одно и то же?
Функция системы -- это то что делает СИСТЕМА, это взгляд со стороны системы ... а  юзкейс, это взгляд со стороны пользователя на взаимодействие с системой для получения значимого результата (если речь о "user goal" юзкейсах)

Хорошая статья. Однако в который раз тыкает носом в старую проблему "абстрактного" юзкейса: стоит ли писать "инициировать" вместо "нажать", или "Ок" вместо "подтверждения". Стоит ли ограничивать программиста? Можете кидать в меня помидоры, но я для себя избрал такой подход. Оно очень прост:  нужно всего лишь задать вопрос - кто будет читать сценарий и чего вы этим сценарием хотите добиться?

Пример 1. У вас команда программистов, про которых вы точно можете сказать - это не ГУЙ-дизайнеры. Попробуйте не написать спецификацию интерфейсов - и вы получите незабываемую картину. Девелоперы будут долго и мучительно ваять интерфейс (ведь выбор - он всегда сложен), а затем еще столько же исправлять его по вашим замечаниям. А если все же решили писать ГУИ спецификацию, то что уж лукавить - пишем сценарии, опирающиеся на элементы интерфейса.

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

Пример 3. У вас в команде замотивированный на работу гуру-дизайнер, которому достаточно сказать: "Леха, нужно чтобы...". Зачем ему мешать, навязывая гриды и окошки? Пишем сценарий в форме достаточной абстракции, и через разумное время получаем готовую систему.

Можно приводить примеры те только ГУИ, но и терминов архитектуры. Суть одна.

Теперь о статье. Разрабатывая требования мы в любом случае проектируем систему. Мы в любом случае архитекторы! Да, мы не выбираем что юзать - вебсферу или jboss. Но даже используя такой абстрактный шаг, как "сценарий ВИ" мы уже вносим СВОИ конструктивные ограничения. Волюнтаризм!
Другими словами - нет четких границ между "пользовательским сценарием", "вариантом использования" и "сущностными элементами". Есть лишь лавирование между двумя крайностями: бесполезная и всеохватывающая абстракция с одной стороны, и детали реализации вплодь до псевдокода и кода с другой. А нужную точку на этой прямой можно найти лишь поняв, кто это и как в конечном счете будет использовать. Может быть, есть смысл сделать выбор самому и вписать термин не "информационный объект" а "файл", если уверен что именно файловые объекты и будут использоваться, тем самым упростив многим жизнь.  А может быть стоит оставить выбор более грамотным людям. И решать нужно исходя из своих знаний и ситуации. IMHO.

1. Если писать юзкейсы как описание движения по пользовательскому интерфейсу, то очень скоро они станут а) сложными для восприятия б) их станет много и ими будет тяжело управлять в) вы замучаетесь вносить в них изменения на каждое пожелание заказчика видеть "тут зеленую кнопку, а тут шрифт должен быть 18 кеглем".  Подменяя спецификацию GUI юзкейсами, и пытаясь убить 2 зайцев одним выстрелом вы сами себя загоните в угол тем, что в конечном итоге работы только прибавиться и вы в конце концов плюнете на актуальность этих т.н. "GUI юзкейсов".
2. О la la!!! мотвация включения GUI в описания юзкейсов и в пределе описание движения по интерфейсу по причине того, что зкакзчик мыслит в терминах GUI стоит у меня на первом месте в коллекции причин! Я это слышу в каждой 3-й компании куда прихожу разбираться с практикой работы с требованиями. После того как войдешь в нормальные доверительные отношения со специалистами этой компании, выясняется, что ЭТО ТОЖЕ ТОЛКОМ НЕ ПОМОГАЕТ в решении проблемы "мыслящего в терминах GUI заказчика", т.е. не эффективно. Ибо все равно заказчик будет говорить о юзабилити больше, чем о том как это будет работать :-). И у этой проблемы есть свои очень простые, не требующие серьезных затрат методы решения, которые вполне работоспособны.
3. Да, бывает ситуация, когда нужно идти на некий компромисс ... например жесткие требования заказчика делать именно так -- не вопрос, за его деньги сделаем ему и с включением GUI, мы же прагматики, не так ли :-) ?
А манипулирование уровнем "абстракции" -- это тоже инструмент аналитика между прочим ..., особенно актуально если "в предметке не сечешь" :-) на первых шагах работы с требованиями. Так что не так плох абстракционизм, как его боятся.

1 Речь идет не о подмене спецификаций GUI сценариями. Речь идет о сценариях, опирающихся на элементы GUI.
Один из тезисов статьи, если я правильно понял,  "чем больше уровень абстракций, тем лучше". Вот с этим я не согласен. Я исхожу из того, что цель аналитика, как и любого другого в команде, быстро и качественно реализовать проект. Если для этого требуется отходить от Коберновских стандартов - это нужно делать.
А на счет поддержки таких требований - это опять же по обстоятельствам. Если в проекте три аналитика, то почему бы и нет. К тому же, большой вопрос на что потратишь больше времени: на поддержку детальных требований или на объяснение программистам, как это хотелось бы видеть.
Практика показывает, что если ты что-то не прописываешь, то это додумывают за тебя. И обычно это не совпадает с твоим видением.

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

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

Писать можно и так:
1) Пользователь активирует загрузку
2) Система копирует объекты, взаимодействуя с системой N
3) Система проверяет целостность объектов

Это скорее всего вызовет больше вопросов. Если знаешь, что здесь лучше использовать протокол ftp - пиши ftp. Используй термины вроде "загрузка", "логин", "пароль", "адрес сервера" и всем будет проще. Да, это твой выбор, и в этом есть некий риск неоптимального решения. Но, еще раз повторюсь, нечестно утверждать, что аналитик собирает "чистые" требования, не влияя на реализацию.

I)
Пишите как вам больше нравиться, если Вы понимаете технику описания ВИ, то от того что Вы напишет ОК или Подтверждение - ничего не измениться. Вопрос только в двух вещах:
1. С самого начала надо учить правильно, если человек будет зацикливаться на ГУИ, то он никогда правильно писать ВИ не будет
2. Если уж пишите кнопка ОК, то все аналитики в компании должны писать так, а то один напишет Ок, другой Подвредить, третий Да, вот Вы и получите три формы с тремя разными кнопками.

II)
Ну кто вам мешать создать спек по ГУИ?? Мы так и делаем - сначала пользовательские Требования в виде ВИ, потом спек на ГУИ. То и то подтверждается у заказчика.

Есть статья - авторы пытаются увязать диаграммы UML c interface-driven подходои к разработке.

В самом общем виде тезисы авторов:
1. Поскольку ВИ задает способ взаимодействия пользователя с системой, такой способ должен обеспечиваться адекватными интерфейсными средствами. Каждый пользователь ассоцирован как с ВИ, так и интерфейсными средствами для выполнения действий в рамках конкретного ВИ. Диаграмма ВИ используется для укзания какой интерфейс для какого ВИ применяется.
2. Поля интерфейсной формы используются для потроения модели данных (диаграммы классов).
3. Логика взаимодействия с интерфейсной формой может быть описана средствами диаграмм последовательности и взаимодействия.

Правда, в статье умалчивается, откуда и как получаются интерфейсные формы, так что данный подход, скорее, больше годится для reverse engineering.

Возможно, если удобно мыслить классы модели сразу в интерфейсном представлении, такой interfce driven подход к описанию системы может служить альтернативой data-driven подходу. Но при этом остается аналогичным data-driven подходу, данные берутся все равно "из жизни" и документов, просто модель сначала рисуется в виде набора интерфейсных формы, а не дигарммы классов.
 
Неясно, возможны  ли проекты, в которых можно (насколько удобно) увидеть процессную модель за интерфейсныи формами (т.е. выявить ключевые процессы и их взаимосвязь по интерфейсам до формализации модели данных)?