Анализ прецедента обманчиво прост, но этот вопрос выдает некоторую внутреннюю сложность.
Каждый прецедент должен быть значимым для участвующих сторон, в том смысле, что он должен представлять собой четко определенное взаимодействие ссистема.Каждый актер и сценарий использования также должны иметь смысл, когда вы говорите о системе, даже используя повседневный язык.Если вы испытываете трудности с определением действующих лиц или вариантов использования, то, вероятно, системный контекст неясен, и поэтому может помочь модель предметной области.
Вариант использования должен представлять собой четко определенное взаимодействие, но не обязательно полный один.Отношение <<include>> можно использовать в ситуациях, когда имеет смысл видеть варианты использования как полного, так и частичного взаимодействия на одном уровне.Вы можете рассмотреть вариант использования buy stuff, включающий, например, browse products, add product to cart и check out <<xor>> cancel, каждый из которых имеет смысл для клиента.
(Я немного запутался в том,Ваша система предназначена для физических или онлайновых транзакций; наличие чеков и распечатанных квитанций, по-видимому, подразумевает первую, корзину для покупок как часть концепций, использованных при анализе последней. Выше подразумевается, что онлайн-система.)
В вашем случае, однако, вы говорите об актерах, которых можно считать частью самой системы.Обычно это означает, что вы пытаетесь определить систему и ее подсистемы одновременно, что часто встречается в ситуациях, когда у вас есть хорошее представление о (возможном) дизайне системы перед началом анализа.
Чтозатем вы хотите разделить анализ на два уровня.На верхнем (системном) уровне очень строго относитесь к системе в целом.В вашем случае вам, вероятно, понадобятся субъекты customer, payment partner, clerk (для системы с физическими транзакциями), accountant (и, возможно, administrator), а также сценарии использования, перечисленные выше, плюс update product catalogue, audit sales log и т. Д.
Затем вы разбиваете систему на подсистемы и делаете отдельный анализ для каждой из них.Здесь подсистемы могут быть действующими лицами в случаях использования друг друга.Print receipt, например, не является значимым вариантом использования на системном уровне, поскольку сам по себе он не является взаимодействием между системой в целом и субъектом системного уровня, но он имеет смысл как вариант использования для подсистемы принтера, с действующим в качестве действующего лица.
Вам не нужно завершать анализ на системном уровне перед тем, как начинать сбои подсистемы, на самом деле я думаю, что лучше, чтобы они оба были активны одновременно - хотя этопредъявляет более высокие требования к вам, чтобы аналитик / дизайнер мог быстро переключать контексты и быть дисциплинированным относительно того, в каком контексте вы работаете в любой момент времени.
Итак, после всего этого (фу!) я думаю, чтоОтветы на ваши вопросы:
- Оба, при условии, что каждый сценарий использования имеет смысл для его участников в качестве четко определенного (но не обязательно завершенного) взаимодействия с системой.
- Да,но не на том же уровне;с одной моделью для системы и отдельными моделями для каждой подсистемы вы можете использовать подсистемы в качестве участников в сценариях использования друг друга.