Хочу поднять теоритическую тему "что есть use case".
Кратко представлюсь: занимаюсь внедрением АС на платформе 1С:Предприятие 8. UML использую для описания БП и моделирования.
USE CASE диаграммы я использую следующим образом:
1. составляю описание БП с помощью UML по известному методическому пособию.
2. от БП переходим к ВИ. ВИ я использовал для описания "цепочек документов". Т.е. ВИ, описывающий именно вариант в котором система может использоваться. ВИ в моем случае практически готовый тест-кейс.
Примеры диаграмм я привел.
Хотелось бы услышать мнение сообщества о правильности такого примения ВИ с точки зрения RUP. Правильно ли я понимаю суть ВИ?
1. Я бы не стал описывать activity диаграмму в таком виде, как это сделано у вас (видимо по пособию Золотухиной). Т.к. семантика activity диаграмм позволяет использовать те же swimlane более эффективно, показывая в них подразделения организации или тех же экторов. Кроме этого можно со спокойной совестью использовать object flows в activity диаграммах, и не заниматься самодеятельностью с "Выходной информацией" в отдельном swimlane. У object flow есть даже одно преимущество - в них после определенной activity можно указать в каком состоянии находится наш объект (или бизнес-сущность).
2. Очень рекомендую начинать использование юзкейсов не как диаграмм, а именно как текстовых описаний. Причем читать не столько Буча по этой теме (все-таки Буч больше программер, нежели аналитик) а либо Якобсона, а еще лучше - Коберна.
3. У вас не верно, со всех точек зрения именованы юзкейсы ... они у вас отражают некую функцию, а не цель пользователя по отношению к системе. А юзкейсы как известно не есть функции системы. Кроме этого - не понятно кто есть primary actor у ваших юзкейсов. Из диаграммы это никак не следует. Если вы хотите сказать, что данный юзкейс это цель пользователя для обеих экторов, то семантически более правильно ввести абстрактного эктора, объединяющего Кассира и Менеджера, и к нему уже пристыковывать юзкейс.
4. Отвечая на ваш вопрос относительно правильности с т.з. RUP - то RUP это процессный фреймворк, а не стандарт описания юзкейсов или UML диаграмм. Другой вопрос, что он дает некие общие рекомендации, как это делать, но не более того! Кроме этого, интерпретация RUP-а Золотухиной является ее авторской разработкой, отличающейся определенной, э-э ... своеобразностью что ли. Я бы не стал опираться только на ее интерпретацию.
Просмотр сообщений
зп аналитика за месяц медленно стремится к нулю (запланированные задачи не сделаны), хотя все как всегда при деле....