Обнаружил вот такое интересное мнение. А что Вы думаете по этому поводу?

Use Cases Can Not Have Preconditions or Postconditions

Данный вопрос был также в статье Как показать последовательность выполнения вариантов использования?

Вариант 1. В виде пред- и постусловий в текстовых спецификациях ВИ. При этом важно, чтобы условия были выполнимыми и проверяемыми. (Одна из обязательных характеристик требования – оно должно быть проверяемым; в противном случае его не следует фиксировать.) Обращаем ваше внимание, что пред- и постусловия являются отступлениями от стандарта UML, согласно которому вариант использования является поведенцеским классификатором (BehavioredClassifier, контейнером поведений), но не поведением (Behavior), и потому не может  иметь пред- и постусловий. Каждое поведение, которым обаладает вариант использования, может содержать пред- и постусловия, но сам ВИ – не может.

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

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

+1.
Я ранее предлагал создать либо RSS-поток блоггеров-аналитиков, либо хотя бы twitter-ленту, код которой можно легко встроить в страницу сайта.

Обнаружил вот такое интересное мнение. А что Вы думаете по этому поводу?
Use Cases Can Not Have Preconditions or Postconditions

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

Ребята!
Какая нам, аналитикам, разница, к "кому" относится предусловие, к UC или к его описанию? Все равно, UC можно выполнять только при соблюдении предусловий!

Ну, нужно было автору показаться умным! Только практического значения это не имеет!

+1.
Я ранее предлагал создать либо RSS-поток блоггеров-аналитиков, либо хотя бы twitter-ленту, код которой можно легко встроить в страницу сайта.

Павел, займетесь?

Ну, нужно было автору показаться умным! Только практического значения это не имеет!

Автор не только кажется умным, но и строит на этом свою полемику с оппонентами. Записывайтесь в Use Case Professionals.

Автор некто Brain C.

его ответ на вопрос

How to properly reflect sequence of use cases in UML?

Hello to everyone.
 My question is basically the following:

 Use Case diagrams typically do not reflect sequential order of use cases in native UML. In my work I often need to provide development team with the high-level order of use cases reflected in the main set of use case diagrams.

 Example: let's imagine that we have 5 CRUD Use Cases - 'View List Of Objects', 'View Object's Details', 'Delete Object', 'Create Object', 'Edit Object'. From the standpoint of sequence (and thus from the standpoint of navigation within the application) first comes 'View List Of'; after the list is displayed User is able to 'Create New', 'View Details' and 'Delete'; after performing 'View Details' User is able to 'Edit'.

 There are some ways to do it which I'm aware of however I do not consider them as proper options:
 1. Create a 'Sequencer Use Case' which includes all these Use Cases (e.g. 'Manage Objects'). But this will flood the diagram with UC's of different level of abstraction.
 2. Use additional relationships such as ''Precedes' or 'Invokes'. But this will also flood the diagram heavily.
 3. Use sequence and activities diagrams. However these diagrams are ususally used to reflect flow of a single use case and not the flow between use cases.
 How do you solve this issue?

I think part of the answer is in how we frame the question. Rather than use the CRUD use case example that rarely has direct value to a user, let's consider a business suite like Microsoft Office with use cases Manage Document, Manage Spreadsheet, etc. These use cases each has a goal that matter to a user to use an artifact with paths to view, create, edit and delete it along with other connected use cases. Some, like delete, could be used by all manage use cases; others can only be used by a few because they are more narrow.

 In real world usage, users create Word documents, then copy part to a PowerPoint and then change the wording, and then copy it back to the Word document, and then ... There are innumerable scenarios.

 If you view use cases to be services, you do not have to worry about documenting them all. Sufficient sample scenarios that cover the services would be sufficient.

 Sometimes there truly are overriding business reasons for specific order that are *always* true. In that case, I suggest that the whole scenario that delivers the business goal should be its own use case that describes all the steps in order - including other use cases, that can provide value outside this scenario, as appropriate.

 Unfortunately, all too often, today's "always" is tomorrow's "what if we?" Preconditions then become a documentation, coding and testing problem. I have found it better for project sanity to treat use cases as services whenever possible.

 In spite of common usage, use cases cannot have preconditions and be UML compliant. Please see http://www.building-requirements-consensus.com/preconditions.html for a detailed discussion.

Ну, что же. Я не Brain C

Но, как раз вчера вечером я выложил статью, которая предлагает другой вариант решения проблемы:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_05/6-1-0-30
И этот вариант, в принципе, не противоречит тому, что процитировал Эдуард.

Автор предлагает то же самое, что уже описано в RUPе: Если UseCase выполняются в определенной последовательности, то этот общий процесс можно определить как Use Case более высокого уровня, описать его как деятельность, действия которой - Use Case включения и расширения.

И на Use Case Diagram неправильно показывать последовательности их выполнения, она не для того предназначена.
Этим еще Коберн возмутился несколько лет назад.

А связано это с тем, что некоторые аналитики дальше Use Case Diagram UML не изучают!

Но причем тут пред- и постусловия? Не надо людей пугать!

Ну, что же. Я не Brain C
Но, как раз вчера вечером я выложил статью, которая предлагает другой вариант решения проблемы:

Отличная статья, Спасибо.
Меня как специалиста тяготеющему к задачам БА очень порадовало рекомендации по разделению "бизнес" и "системных" задач.

Если UseCase выполняются в определенной последовательности, то этот общий процесс можно определить как Use Case более высокого уровня, описать его как деятельность, действия которой - Use Case включения и расширения.

И на Use Case Diagram неправильно показывать последовательности их выполнения, она не для того предназначена.

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

То есть, смотрите. Есть UC. Описываем его шаги текстом (не ДП или ДД). Каждый шаг - это т.н. "поддеятельность". Эти шаги и описываем как расширения и включения. Верно?

Я описываю этот шаг (если Вам так больше нравится): "Выполение UC включения <Название>".

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

На крайний случай, можно скачать псевдокнижку "Ведение в RUP". Написана (не дописана, по некоторым причинам) она очень давно, но до сих пор гуляет на просторах интернета: http://www.bookshunt.ru/b10345_vvedenie_v_rational_unified_process.

Многим терминология не нравится. Но это писалось тогда, когда на русском языке вообще почти ничего по RUP не было!

Вообще, я очень советую каждому аналитику иметь на рабочем столе ссылку на RUP,

А ссылку ?!

Фигушки!

Советую скачать и инсталлировать с IBM ru триал RMC.
Он содержит RUPы и "практики" (в т.ч. на русском).
RMC за ненадобностью деинсталлировать (инструмент для настройки или написания своего процесса). RUPы и "практики" остаются навсегда.

Но я этого не говорил!

Если кому надо, могу выслать свой неофициальный перевод (много, но, естественно, не все) в ворде.