Сообщений в теме: 44

[Oleg_V]

Давайте я приведу ещё парочку определений, помимо того, которое уже было....

Первое опрделение - каноническая спецификация Use Case в рамках UML 1.1. Надо было мне его сразу посмотреть - все вопросы отпали бы сами собой.

Получается, что лучший русский эквивалент - последовательность действий (sequences of actions). При этом оговаривается, что есть многовариантные последовательности (Скажем, кнопку Submit можно кликнуть мышкой или нажать ввод на клавиатуре) и последовадельности, ведущие к ошибке (например, пользователь удаляет часть параметров, передаваемых в URL).

Вот все и встало на свои места.

А вторая цитата - это уже трактовка, потому как перевод. И согласиться с ним не могу по трем соображениям:

1. Термин задан сразу, а дальше только объясняется его значение. То есть выражение имеет вид постулата.
2. Такое опрделеление сужает пространство пользовательских систем до множества компьютерных систем. Выходит, что для посудомоечной машины, радио, пельменницы и проч. этот термин непригоден :)
3. Определение говорит лишь об одном пользователе, исключая тем самым все ситуации, когда в действиях участвует группа пользователей, например, покупатель-продавец при совершении сделки.

[barancev]

Получается, что лучший русский эквивалент - последовательность действий (sequences of actions). При этом оговаривается, что есть многовариантные последовательности (Скажем, кнопку Submit можно кликнуть мышкой или нажать ввод на клавиатуре) и последовадельности, ведущие к ошибке (например, пользователь удаляет часть параметров, передаваемых в URL).

Если бы это было действительно лучшим, то именно термин "sequences of actions" и использовался бы вместо "use case".

На самом деле, причина появления нового термина в том, что "use case" должен был включать в себя естественным образом нечто внешнее по отношению к системе -- действующие лица (actor). Цель преследовалась -- предоставить нотацию, в которой можно было бы выразить взгляд на систему извне. Однако, данное в спецификации UML определение получилось таким, что оно не удовлетворяет заданной цели и даёт излишне system-centered взгляд. За что его и критикуют многие. Якобсон попытался исправить положение и в последующих работах добавлял, что это не любая последовательносить, а "дающая определённому действующуму лицу значимый для него, ощутимый и измеримый результат".

Основное возражение против того, чтобы использовать термин "пользовательский сценарий" (user scenario или use scenario) состоит в том, что (вопреки определению в UML Reference Manual) вариант использования НЕ ОБЯЗАН описываться в форме сценария, описание может быть любым, какое только пожелает аналитик. Определение, данное в книге USDP, которое я цитировал в самом начале, не страдает этой "сценарностью", которая навязывает определённый стиль описания вариантов использования. Посмотрите упомянутую книгу Кокбурна -- там есть примеры других способов описания вариантов использования.

А вторая цитата - это уже трактовка, потому как перевод.

Давайте я для чистоты приведу оригинал, уверяю Вас, перевод достаточно точный, иначе я бы сразу обратился к оригиналу: A use case is a typical interaction between a user and a computer system … [that] captures some user-visible function … [and] achieves a discrete goal for the user.

И согласиться с ним не могу по трем соображениям:

Не соглашаться -- это Ваше право :)
Да, это определение тоже неоднократно подвергалось критике, но Фаулер отмазался тем, что, дескать, для книги типа "UML для чайников" именно такое определение и нужно, а не заумное и точное до последней детали.

[barancev]

Я более удачлив, мне встречалось вполне приличное определение понятия use case.

Берём уже упомянутую книжку Якобсона, Буча и Рембо Унифицированный процесс разработки программного обеспечения и читаем:
"Вариант использования -- это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата."

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

Не частью системы, а частью функциональности системы.
Или Вы считаете, что функциональность является частью системы? :)

[Viktor]

Я более удачлив, мне встречалось вполне приличное определение понятия use case.

Берём уже упомянутую книжку Якобсона, Буча и Рембо Унифицированный процесс разработки программного обеспечения и читаем:
"Вариант использования -- это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата."

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

Не частью системы, а частью функциональности системы.
Или Вы считаете, что функциональность является частью системы? :)

Прошу меня извинить, Алексей, но я пока не отвечу на этот вопрос :)
А поясню подробнее, почему мне не нравится то определение.
Вот в рупе определение: Use Case - A description of system behavior, in terms of sequences of actions.
И мы понимаем что, если есть любое (А) description of system behavior, in terms of sequences of actions, то, возможно, это Use Case. Конечно, можно различать плохой или хороший use case, но смысл понятен.
То определение, которые Вы привели и за которое я пока зацепился, не удовлетворяет критерию "обратности", а следовательно - полноты.
Т.е. даже если мы вычленили некоторую часть функциональности отсюда не следует, что это use case, отсюда можно точно сказать, что это некоторая функция системы
Рассматривать use case как описание, как модель, как спецификацию - я готов. Как часть системы или ее функциональности - нет.
Более того, аргументы 2,3 Олега применимы и к этому определению, но только в отношении системы.
Откуда взялась система? Почему система в единственном лице?

[barancev]

Или Вы считаете, что функциональность является частью системы? :)

Прошу меня извинить, Алексей, но я пока не отвечу на этот вопрос :)

Тогда я сам отвечу. Функциональность системы -- это не её часть, а её характеристика. Абстракция. То есть своего рода модель. И Якобсон предлагает считать вариант использования частью этой модели.

А поясню подробнее, почему мне не нравится то определение.

Ну и мне тоже не очень нравится. Я даже написал почему.

То определение, которые Вы привели и за которое я пока зацепился, не удовлетворяет критерию "обратности", а следовательно - полноты.
Т.е. даже если мы вычленили некоторую часть функциональности отсюда не следует, что это use case, отсюда можно точно сказать, что это некоторая функция системы

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

Рассматривать use case как описание, как модель, как спецификацию - я готов. Как часть системы или ее функциональности - нет.

Ваше право. Не хотите -- не рассматривайте. Якобсон готов рассматривать как часть функциональности системы. Это тоже его право.

Более того, аргументы 2,3 Олега применимы и к этому определению, но только в отношении системы.
Откуда взялась система? Почему система в единственном лице?

Ну, это уже какие-то несерьёзные придирки, а не аргументы. Если Вы не знаете, откуда взялась система, то и варианты использования (использования чего?) рассматривать бессмысленно. :)

[Viktor]

Более того, аргументы 2,3 Олега применимы и к этому определению, но только в отношении системы.
Откуда взялась система? Почему система в единственном лице?

Ну, это уже какие-то несерьёзные придирки, а не аргументы. Если Вы не знаете, откуда взялась система, то и варианты использования (использования чего?) рассматривать бессмысленно. :)

Зачем уж так-то? Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

[barancev]

Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

А я не курю и не вожу автомобиль. Поэтому у меня нет вообще никаких угроз для жизни :)

[Viktor]

Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

А я не курю и не вожу автомобиль. Поэтому у меня нет вообще никаких угроз для жизни :)

Я не себя имел в виду :)

[barancev]

Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

А я не курю и не вожу автомобиль. Поэтому у меня нет вообще никаких угроз для жизни :)

Я не себя имел в виду :)

Вот чёрт! :)
Кажется, Вы не в Москве? Это хорошо-о-о...

[Viktor]

Вот чёрт! :)
Кажется, Вы не в Москве? Это хорошо-о-о...

Да нет, я имел в виду, что если едешь в автомобиле, неважно сам за рулем или нет, к этому надо относиться серьезно.
Если проснулся, а кто-то курит рядом - это тоже опасно. :)

[barancev]

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

[barancev]

Я решил окончательно запутать ситуацию. Поэтому вот ещё одно определение:

[Constantine, Structure and Style in Use Cases for User Interface Design, 2001]
An essential use case is a single, discrete, complete, meaningful, and well-defined task of interest to an external user in some specific role or roles in relationship to a system, comprising the user intentions and system responsibilities in the course of accomplishing that task, described in abstract, technology-free, implementationindependent terms using the language of the application domain and of external users in role.

[barancev]

А вот ещё. Правда, это не определение, а объяснение, причём довольно длинное:

[Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000]

What is a Use Case (more or less)?

A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.

Use cases are fundamentally a text form, although they can be written using flow charts, sequence charts, Petri nets, or programming languages. Under normal circumstances, they serve to communicate from one person to another, often to people with no special training. Simple text is, therefore, usually the best choice.

The use case, as a form of writing, can be put into service to stimulate discussion within a team about an upcoming system. They might later use that the use case form to document the actual requirements. Another team might later document the final design with the same use case form. They might do this for a system as large as an entire company, or as small as a piece of a software application program. What is interesting is that the same basic rules of writing apply to all these different situations, even though the people will write with different amounts of rigor, at different levels of technical detail.

When the use cases document an organization’s business processes, the system under discussion is the organization itself. The stakeholders are the company shareholders, customers, vendors, and government regulatory agencies. The primary actors will include the company’s customers and perhaps their suppliers.

When the use cases record behavioral requirements for a piece of software, the system under discussion is the computer program. The stakeholders are the people who use the program, the company owning it, government regulatory agencies, and other computer programs. The primary actor will be the user sitting at the computer screen or another computer system.

[barancev]

Что такое "use case по стандарту UML" -- понятно. Кто хочет -- тот пользуется. В том числе и для тестирования.

Однако большинство авторов, включая Якобсона, "отца" use case'ов, признают это определение слишком конкретным и непригодным для той самой практики, о которой Анатолий упоминает, потому что практика оказалась настолько разнообразной, что никто не мог предсказать, сколь широким окажется использование use case'ов. Вот эта самая практика и изложена, например, в книге Кокбурна (откуда я приводил длинную цитату на малопонятном языке), там все примеры -- из реальных проектов! Это вам не наукообразная интерпретация, это сама жизнь во всей её полноте и сложности!

[barancev]

Я решил окончательно запутать ситуацию.

А может быть всё-таки, Алексей, лучше распутать ситуацию? Хотя бы для «чайников» (фраза Ваша).
Для этого всего- то необходимо сказать, что на практике в большинстве случаев Use case – это типовая пользовательская процедура/сценарий/последовательность, хотя иногда этот термин используется в болеее широком смысле так-то и так- то, например, там-то и там-то. И всё станет на своё место.

Так я примерно так и сказал. Разве нет? Но Вы сочли это "наукообразными интерпретациями" :)

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

[Viktor]

Предлагаю здесь остановиться по следующей причине:
Русский язык гораздно богаче английского. Что там можно назвать одним термином use case, у нас не получится, потому что мы всегда говорим с разных позиций.
Действительно: если мы смотрим на систему - вариант (ее) использования, на пользователя - типовой пользовательский сценарий (процедура), на поведение actors - случай (прецедент) использования. Получается, что у нас каждый термин имеет право существовать. Каждый частный случай имеет свое название, общий - нет (в русском языке). Называя вещи, мы теряем их суть. Слишком много для одного термина - суть уже практически не видна. Пора прекращать.