Читаю в настоящее время книгу Дуга Розенберга и Мэта Стефенсона Use Case Driven Object Modeling with UML: Theory and Practice.

Книга написано просто, экономно и прагматично. В начале дается теория, которая подкрепляется практикой с моделями и диалогами, далее даются задания и производится разбор этих заданий.

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

В ходе чтения обнаружил, что Розенберг совершенно иначе трактует вопросы создания вариантов использования, причем явно идет в пику Коберну и другим гуру по UC.

Ради справедливости стоит заметить. Что первые 15 лет, Дуг зарабатывал на жизнь в качестве программиста, затем уже перешел в менеджеры проекта и даже основал собственную компанию. Мэт из Лондона - Java программист, лидер проекта, технический архитектор.

В чем же отличия?
1. Вариант использования должен описываться в стиле двух параграфов (абзацев) - один для основного потока, другой для альтернативных. стр.52 (англ издание)
2.Вариант использование описывается с использованием раскадровок, прототипов или экранных форм. Т.е. по сути ВИ должен содержать элементы интерфейса (возможно - это свзяано например с тем, что разработка систем с нуля, сейчас редко происходит, всегда изучается уже имеющиеся системы и их наработки)
3. вместо includes и extends следует использовать invokes и precedes. Активно избегать обобщения.
4 вариант использования описывается в сжатом формате. Если не удается описать в сжатом формате, ВИ следует разделить на несколько. (это как авторы потом объясняют проявляется при рисовании robustness diagram на которой нужно изобразить все потоки: основной и альтернативный, так же как sequence)
в частности автор комментируя шаблон Коберна в известной его книге пишет:

Here’s an example of a long and particularly ghastly (in our opinion) use case template
from renowned guru Alistair Cockburn’s book Writing Effective Use Cases:4

We regard this template as ghastly because, while it is theoretically elegant in that it
comprehensively covers everything you might possibly want to discuss in conjunction with
a use case, in practice, if you require your team to “fill out the long form” use case template,
they will rapidly discover that
1. They are wasting time.
2. Wasting time will turn them off to the entire modeling process.
3. They can mindlessly fill out the form without focusing on the important parts (basic
course and alternate courses) of the use case, and nobody will know the difference.
We’ve seen this happen in the real world on many occasions.
Consider the statements we just made as warnings about ways you might build up resistance
to doing use cases, which offers an excuse to ditch modeling altogether—and we all
know what happens then. (Hint: “The code’s written, so I guess we’re done!”)

Далее на странице 93 в конце идет объяснение того, почему не следует писать UC слишком абстрактно. Надо сказать довольно убедительно.

Many books about use cases, especially those that are focused strictly on use cases as a
requirements definition technique, preach writing use cases that are “abstract, essential,
technology-free, and implementation-independent.” Our approach is a bit different, as
you’ll see in the following review segment, since we both come from a programming background
(most programmers would call the aforementioned use cases “vague, ambiguous,
incomplete, and incorrect”).
далее идет диалог Аналитика и Читателя-эксперта, который проверяет варианты.

Читая книгу, я вижу практичность и убедительность доводов Розенберга, тем более они подкреплены примером. Правда пример Интернет-магазин.
Меня убеждают и слова Коберна и других гуру UC.

В результате меня заклинило Кто же прав: Коберн или Розенберг? Или по другому в каком контексте правы оба?

Обращаюсь к нашим аналитикам за помощью. Давайте разберем это по полочкам!
 

Ну Эд, опять о том, что каждому проекту своя методология. Т.к. ICONIX - это Агиле процесс, то авторы стараются упростить и выкинуть wasting time вещи. Действительно шаблон Коберна избыточный, действительно из шага сценария ВИ можно сделать ссылку на Интерфейс.
В общем и данное описание можно использовать, ничего особо противоречивого нет. Вообще апологеты Агиле описывают требования в виде Историй Пользователей или используют ВИ, но максимально их облегчают.
Там говориться о Видение??

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

Саша я не против этого. Да я понимаю, что варианты использования - это не теория решения дифуров или теория автоматов и т.п.

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

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

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

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

Он тоже утверждает, что не нужно описывать излишне детализировано работу с интерфейсом. Однако, если он пишет в шаге ВИ: Пользователь кликает по ссылке, Система загружает страницу Деталей книги, разве тут есть простор для творчества?

Дуг приводи ссылку на книгу Авара Якобсона Aspect-Oriented Software Development with Use Cases и говорит мой подход синергичен этому. А Якобсон кажется изобреталь вариантов?

Если мы говорим только о ВИ, то:

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

Я даже не хочу спорить о нюансах ВИ:
1. Как его детализировать. Как команда сочтет нужным, так и детализируй. На этапе обучения читай Коберна как правильно делать.
2. Включать Форму или нет. Как команда сочтет нужным, так и делай. На этапе обучения читай Коберна как правильно делать. ИМХО включать Формы - это очень полезно.
3. Писать - "нажать кнопку ОК" или писать - "Подтвердить операцию". Как команда сочтет нужным, так и пиши. На этапе обучения читай Коберна как правильно делать. ИМХО это вообще не принципиально.
4. Что еще?

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

Замечательно.

На нашем форуме кто-то публикует свой ВИ и просит его проанализировать. Правильно не правильно, корректно - некорректно.

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

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

Где критерий? Ты говоришь как захочет команда, как она посчитает нужным? А каковы тогда аргументы для анализа внешним экспертом?

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

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

Agility and Discipline Made Easy: Practices from OpenUP and RUP By Per Kroll, Bruce MacIsaac
When describing a use case, it is important to consider its two primary audiences: the stake-holders and the development
team. Stakeholders leverage use cases to understand what services the system will provide to the users of the system. Use cases should therefore use a language that stakeholders easily understand and avoid drilling down to a level of detail that makes it hard for them to see which key capabilities are provided. The other key audience is the development team: developers and testers doing storyboards, design, implementation, testing, and user documentation. Use cases need to provide sufficient specificity and level of detail to be meaningful to the development team. It is also important to assess whether further detail is best expressed as additional text in a use case or is better expressed in the form of storyboard, test cases, or directly in the code.

Цитата подтверждает мои слова.

вот пример из книги Унифицированный процесс разработки ПО Якобсона, Буча и Рамбо. Питер 2002

Оплатить Счет
Предусловие: покупатель получил заказанные товары или услуги и по крайней мере один счет. Теперь он планирует пометить счет(а) к оплате.

Поток событий.
1. Основной путь.
1. Покупатель запускает вариант использования, начиная просматривать счета, полученные от системы. Система проверяет, что содержимое счетов соответствует подтверждениям заказов, полученным ранее (как часть варианта
использования Подтвердить Заказ), и указывает на это покупателю. Подтверждение заказа описывает, что будет поставлено, когда, куда и по какой цене.
2. Покупатель решает пометить счет к оплате, и система генерирует запрос на платеж, чтобы банк мог перечислить деньги на счет продавца. Заметьте, что покупатель не может пометить один и тот же счет к оплате дважды.
3. Позже, а именно в намеченную дату, если на счете покупателя имеется достаточное количество денег, происходит оплата. При оплате деньги перечисляются со счета покупателя на счет продавца, как описано в абстрактном
варианте использования Совершить Перечисление (который используется в Оплатить Счет). Покупатель и продавец уведомляются о результате операции. Банк получает плату за перечисление, которая снимается системой
со счета покупателя.
4. Экземпляр варианта использования прекращает свое существование.

2. Альтернативные пути.
1. На шаге 2 покупатель может потребовать, чтобы система отослала продавцу сообщение о том, что счет отклонен.
2. На шаге 3, если на счете недостаточно денег, вариант использования отменит оплату и сообщит об этом покупателю.

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

Особое внимание обратите на 3 шаг основного потока

Цитата подтверждает мои слова.

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

Что я возьму для обучения Коберна или Розенберга, я думаю абсолютное не важно.
Я уже приводил в качестве примера к чему может привести выбор одного преподавателя.

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

Спасибо, Shur.

Итак принимаем в качестве отправной точки сам приницп use case - это не функция, остальное определяется методологией, контекстом использования.

Правда, этих если так много, что сложно преподавать А студенту понять как же...

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

Эд, не парься особо на тему кто из авторов методик прав. По поводу шаблонов Коберна, то не забываем что у него кроме fully dressed есть еще и casual вариант. Да и кто сказал что его шаблоны нельзя модифицировать под себя? Просто у Коберна юзкейсы достаточно удобные для практического использования. Мне НИЧТО не может помешать, если это добавляет ценности проекту, дополнить их макетами GUI. Но, ПЕРВИЧНЫМ будет таки UC с его целью пользователя и постоянным контекстом по достижению именно цели, а не концентрации на том, какую кнопку при этом нажать. Хотябы по тому, что как минимум название кнопки, да и сам дизайн GUI может еще 100 раз измениться в процессе проектирования и собственно разработки, и что, мне потом все в UC править, чтобы обеспечивать целостность? Да, у меня были проекты, когда UC будучи написаны выполняли свою роль на начальных этапах, и больше я их не поддерживал ... а разработка шла практически через прототипы, с очень короткими итерациями. И это тоже нормально. Саша правильно заметил -- каждому проекту своя методология. И если я вижу, что  в конкретном проекте UC не воспринимаются заказчиком и не добавляют ценности -- я от них отказываюсь в пользу других техник. Все зависит от проекта.

Спасибо, ребята, за ответы.

Дискуссия, думаю, вполне плодотворная.

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

Согласен - это нормально, инженерия - это не строго формализованная наука, инженерия - это искусство решать задачи в конкретных условиях максимально эффективным образом.

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

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

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

Я понимаю, что стили описания UC будут таковыми, какова стратегия проекта, конкретная ситуация, стиль работы.

Согласен с Юрой, что главное в ВИ - это сосредоточение на цели пользователя и продвижение к этой цели.

Shur, я полагаю, что РОзенберг акцентирует внимание не на бизнес контексте и бизнес уровене, а на системном уровне в первую очередь.

Возможно Розенберг выбрал не очень удачный пример (а может как раз удачный) для описания своей методологии. Либо его методология хорошо работает с наследуемыми системами, системами ориентированными на веб

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

Коберн предлагает сначала создать ВИ, потом спроектировать взаимодействие с системой и дизайн UI. Результаты каждого из шагов наверняка нужно обсуждать, защищать и пересматривать. Для этого PMу надо признать, что системный аналитик не способен идти дальше UC - по крайней мере, не останавливаясь для проверки и согласования.

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

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

Алекс, извини не понял какую мысль ты продвигаешь. В контексте данной темы, конечно. Розенберг - это танцующий медведь?