Пусть в ходе анализа 2 прецедента А и Б описаны в нотации UML, например, созданы по 1 эктивити дайаграм для каждого прецедента.
Имеются ли какие-либо формальные правила, по которым, глядя на эти их диаграммы, можно однозначно сказать в каких отношениях могут находиться прецеденты А и Б, а в каких не могут? Подскажите, пожалуйста, где это описано.

Например, если согласно этим диаграммам все сценарии прецедента А могут иметь место и в прецеденте Б, то значит ли это, что Б обощает А?
Или например, диаграммы А и Б отличаются только одним действием или деятельностью, которого нет у А, но которое выполняется в прецеденте Б в конце любого его сценария, то это значит, что Б использует А? А если это дополнительное действие происходит не в конце и не у любого сценария Б, то что тогда?
Или например, диаграммы различаются всего лишь путем одного объекта?
Или например, диаграммы А и Б отличаются только одним документом (объектом), который не присутствует на диаграмме А, но используется/возникает в резултате одной из деятельностей сценария Б?

Здравствуйте, Аноним, Вы писали:

А>Пусть в ходе анализа 2 прецедента А и Б описаны в нотации UML, например, созданы по 1 эктивити дайаграм для каждого прецедента.
А>Имеются ли какие-либо формальные правила, по которым, глядя на эти их диаграммы, можно однозначно сказать в каких отношениях могут находиться прецеденты А и Б, а в каких не могут? Подскажите, пожалуйста, где это описано.

А>Например, если согласно этим диаграммам все сценарии прецедента А могут иметь место и в прецеденте Б, то значит ли это, что Б обощает А?
А>Или например, диаграммы А и Б отличаются только одним действием или деятельностью, которого нет у А, но которое выполняется в прецеденте Б в конце любого его сценария, то это значит, что Б использует А? А если это дополнительное действие происходит не в конце и не у любого сценария Б, то что тогда?
А>Или например, диаграммы различаются всего лишь путем одного объекта?
А>Или например, диаграммы А и Б отличаются только одним документом (объектом), который не присутствует на диаграмме А, но используется/возникает в резултате одной из деятельностей сценария Б?


Больше похоже на то, что юзкейсы не правильно выявлены. Читаем A. Cockburn .

Здравствуйте, byur, Вы писали:

B>Больше похоже на то, что юзкейсы не правильно выявлены. Читаем A. Cockburn .

Спасибо. Буду искать. Нельзя ли ссылочку...

Имеется ввиду, что, если они выявлены правильно, то и не нужны такие признаки, т.к. все отношения будут очевидны "по смыслу"? А если как раз надо проверить, правильно ли они выявлены и правильно ли между ними установлены отношения?

Например, проводится обратное проектирование: сперва описаны сценарии системы, и теперь нужно из них выявить прецеденты.

Здравствуйте, Аноним, Вы писали:


B>>Больше похоже на то, что юзкейсы не правильно выявлены. Читаем A. Cockburn .

А>Спасибо. Буду искать. Нельзя ли ссылочку...

ссылочка -- его книга "Writting effective use cases". Есть перевод на русский -- не помню точно названия, но что-то про методы описания функциональных требований.

А>Имеется ввиду, что, если они выявлены правильно, то и не нужны такие признаки, т.к. все отношения будут очевидны "по смыслу"? А если как раз надо проверить, правильно ли они выявлены и правильно ли между ними установлены отношения?

А>Например, проводится обратное проектирование: сперва описаны сценарии системы, и теперь нужно из них выявить прецеденты.

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

Здравствуйте, byur, Вы писали:

B>ссылочка -- его книга "Writting effective use cases". Есть перевод на русский -- не помню точно названия, но что-то про методы описания функциональных требований.
Спасибо!

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

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

Здравствуйте, Аноним, Вы писали:

А>Пусть в ходе анализа 2 прецедента А и Б описаны в нотации UML, например, созданы по 1 эктивити дайаграм для каждого прецедента.
А>Имеются ли какие-либо формальные правила, по которым, глядя на эти их диаграммы, можно однозначно сказать в каких отношениях могут находиться прецеденты А и Б, а в каких не могут? Подскажите, пожалуйста, где это описано.

А>Например, если согласно этим диаграммам все сценарии прецедента А могут иметь место и в прецеденте Б, то значит ли это, что Б обощает А?
А>Или например, диаграммы А и Б отличаются только одним действием или деятельностью, которого нет у А, но которое выполняется в прецеденте Б в конце любого его сценария, то это значит, что Б использует А? А если это дополнительное действие происходит не в конце и не у любого сценария Б, то что тогда?
А>Или например, диаграммы различаются всего лишь путем одного объекта?
А>Или например, диаграммы А и Б отличаются только одним документом (объектом), который не присутствует на диаграмме А, но используется/возникает в резултате одной из деятельностей сценария Б?

Очень похоже на Индуктивные методы Миля:

Индуктивные методы используются не только при открытии и формулировании законов природы, но и при исследовании одного из фундаментальных отношений между являниями природы как отношение причинности.
1. Метод единственного сходства. Этот метод Милль формулирует в виде: «если два или более случая подлежащего исследованию явления имеют общим лишь одно обстоятельство, то это обстоятельство есть причина данного явления». Схема метода:
АВС => d
BMT => d
POB => d
________
B => d
Чтобы придти к выводу, что В есть причина d, необходимо быть уверенным, что это единственное обстоятельство, при котором d происходит.
2. Метод различия основывается на сопоставлении двух случаев, которые различаются между собой фактом присутствия и отсутствия исследуемого обстоятельства, но являющиеся сходными друг с другом во всех других отношениях. Схема метода:
ABCM => d
ABC => d
________
M => d
Соединённый метод сходства и различия состоит в двойном приложении метода сходства, но не обладает той силой, которая присуща методу различия. Милль так выражает содержание этого метода: «если два или более случая возникновения явления имеют общим лишь одно обстоятельство, и два или более случая невозникновения того же явления имеют общим отсутствие того же самого обстоятельства, то это обстоятельство есть или следствие, или причина, или необходимая часть причины этого явления».
3. Метод остатков представляет собой видоизменение метода различия. Схема метода.
ABC => xyz
A => x
B => y
________
C => z
По Миллю этот метод является наиболее важным орудием открытия и даёт больше всего неожиданных результатов. Ценность метода остатков заключается в том, что по этому методу можно сделать вывод о наличии такого обстоятельства, о существовании которого до этого не подозревали. Правило этого метода Милль сформулировал следующим образом: «если из явления вычесть ту его часть, которая, как известно из прежних индукций, есть следствие некоторых определённых предыдущих, то остаток данного явления должен быть следствием остальных предыдущих».
4. Метод сопутствующих изменений. Милль даёт следующую формулировку: «всякое явление изменяющееся определённым образом всякий раз, когда некоторым особым образом изменяется другое явление, есть либо причина, либо следствие этого явления, либо соединено с ним какою-либо причинною связью». Схема метода:
ABC1 => d1
ABC2 => d2
ABC3 => d3
________
C => d
Приложение метода сопутствующих изменений результативно в тех случаях, когда причина изменяется и это можно подвергнуть количественному измерению. Подобное изменение причины основывается на неявно принятом принципе сложения причин. Но такое бывает далеко не всегда, когда причины могут взаимодействовать друг с другом, и тогда этот метод неприменим.