Пример использования анализ обманчиво прост, но этот вопрос предает некоторые из присущего сложности.
Каждый случай использования должен иметь смысл для вовлеченных участников в том смысле, что он должен представлять собой четко определенное взаимодействие с системой. Каждый актер и прецедент также должны иметь смысл, когда вы говорите о системе, даже используя обычный язык. Если вы сталкиваетесь с трудностями с определением участников или случаев использования, то, вероятно, системный контекст неясен, и поэтому может помочь модель домена.
Используемый кейс должен представлять четко определенное взаимодействие, но необязательно полный один. Отношение <<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, например, не является значимым вариантом использования на системном уровне, поскольку он сам по себе не является взаимодействием между системой в целом и субъектом системного уровня, но имеет смысл в качестве прецедента для подсистемы принтера с до, как актер.
Вам не нужно заполнять системный анализ, прежде чем начинать разбивку подсистемы, на самом деле я считаю, что лучше иметь их одновременно одновременно, хотя это предъявляет вам более высокие требования к аналитику/дизайнеру быть в состоянии быстро переключать контексты и быть дисциплинированным в отношении того, с каким контекстом вы работаете в любой момент времени.
Итак, после того, как все это (! Уф) Я думаю, что ответ на ваши вопросы:
- И, при условии, каждый случай использования имеет смысл своих актеров, как вполне определенный (но не обязательно полное) взаимодействие с системой.
- Да, но не на том же уровне; с одной моделью для системы и отдельными моделями для каждой подсистемы вы можете использовать подсистемы в качестве участников в случаях использования друг друга.
Я думаю, что вариант использования отдельно был бы лучшей идеей. И я не понимаю, что вы пытаетесь указать об актерах. –
Причина, по которой я хочу, чтобы база данных продаж, журнал продаж, корзина и т. Д. Были актерами, заключается в том, что становится очень легко определить роли, которые играют актеры, потому что я могу видеть актеров на диаграмме вариантов использования. его нелегко объяснить здесь, но связано с DCI - новой парадигмой: http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction –
Я не уверен, что это будет соответствовать Актеру в смысле использования , Не могли бы вы дать больше объяснений, почему им нужно быть Актерами? Я быстро просмотрел статью в Википедии, и кажется, что эти Роли связаны с объектами, и упоминание о модели домена делает ее похожей на объекты домена. Каталог, база данных продаж, журнал продаж, корзина и т. Д. Вполне могут быть смоделированы как классы в модели домена. На самом деле это будет стандартная практика в приложении типа n-уровня. –