диаграмма прецедентов использования, как сделать это лучше
привет, мой первый вопрос, как я могу поместить дела в лучшей читаемости? Я хочу, чтобы эта диаграмма соответствовала бумаге формата А4. Но я знаю, что эта диаграмма может быть плохо сделана, поэтому я прошу вас советоваться, может быть, я должен поделиться с меньшей частью?
Я не понимаю ваш язык (в вашем use-cases). Обычно в большинстве случаев у нас есть общая функция, поэтому вы можете использовать наследование в диаграмме UML. Например, если у вас есть различные виды студентов (или Актеры), которые имеют некоторые общие функции вы можете сделать что-то вроде ниже изображения:
Если ваш актер уже студент, зачем он хочет зарегистрироваться? Это не имеет смысла. – observer
Вам нужно подключить случай использования только его основного актера , Поэтому в конечном итоге вам нужно создать общую роль, в которой UC используется этой общей ролью актера. Тогда ваши конкретные участники наследуют этот общий. Как и в примере Амира, Международный Студент наследует от Студента.
Я бы просто проголосовал за последний пример, но у него есть <<include>>/<<extend>>, что не выгодно с синтезом использования. Более того, он использует обобщение, которое является очень плохой практикой с UC, поскольку UC представляет собой отдельное добавленное значение, а наследование от добавленной стоимости не имеет смысла (в отличие от контекста класса).
Я думаю, что слишком много прецедентов. У меня такая же проблема. Попробуйте использовать CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Кроме того, вы можете разделить диаграмму на несколько диаграмм использования для каждого актера. Или поставить всех участников с одной стороны диаграммы и использовать дела на другом. Надеюсь это поможет.
UML для чайников хорош для UML и чистого синтаксиса. Но для случаев использования вы должны прочитать Bittner/Spence. Они касаются семантики прецедентов. –
Я полностью согласен с данными предложениями (CRUD, наследование и ответственность по ролям), и я также рекомендую не пытаться создать обзор всей вселенной. Вместо этого попробуйте разделить ваши варианты использования на группы, основываясь на сходствах, различиях и т. Д. И объясните свое моделирование на меньших частях.
Избегайте слишком сложных структур и взаимных/циклических зависимостей - они почти всегда являются признаком плохого дизайна. Помните, что вам необходимо реализовать и проверить каждые подключение на вашей диаграмме. Меньше соединений, меньше усилий, меньше ошибок.
Публикация чего-либо на польском языке делает его маловероятным для получения содержательного ответа. Особенно для UCs нужно знать, что они назвали. Как правило: если ваш UC начинает напоминать паутинные сети, у вас, вероятно, неправильный дизайн. –
жаль польского языка. в img. моей главной проблемой является «podgląd zgłoszenia», «lista zgłoszeń» и «dodanie odpowiedzi w zgłoszeniu», потому что с этими случаями связаны 3 актера. – thenewgai