День добрый. Я начинающий аналитик-проектировщик-студент. Сейчас работаю над учебным проектом "Помощник Юриста". В кратце: представляет собой программу-комбайн, в которой будет все необходимое для небольшой юридической фирмы. Имеется реальный заказчик 
Читаю сейчас много различной литературы по UML, но не хватает опыта

Публикую свою use case диаграмму.
Хотел попросить совета у коллег постарше и поопытнее, чтобы меня поправили (Здоровая критика приветствуется)



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

2. Не понимаю до конца, как правильно отразить взаимодействие актеров и прецедентов типа : web-browser, microsoft office и т.д (все что внизу)
Как правильно отображать, что с моей системой взаимодействуют внешние системы?

3.У актера-системный администратор имеется прецедент "Составить расписание". По моей задумке он означает, что администратор сам устанавливает расписание для обновления и резервного копирования. Правильно ли использована тут связь "обобщение"? или должно быть "extend"? ( необходимо ваше пояснение)

4.Правильно ли отражено, что с этими же прецедентами взаимодействует актер "Время"?

Буду очень признателен за помощь и советы.
Спасибо

Покажите артефакты бизнес-анализа:
1. Контекстную диаграмму
2. Модель процессов

В текущем виде модель способов применения анализировать практически невозможно.

Программа-комбайн предполагает исполнения множества функций различного назначения. Это означает, что комбайн можно рассматривать как систему систем. Первый способ борьбы со сложностью: декомпозиция и иерархия. Представьте свой комбайн как набор систем узкого назначения, тогда рассматривая такую систему, все остальное станет внешними актерами.

Однако спешить в этом вам не следует - не опытны еще для таких экспериментов, начните пока с малого, т.е. с декомпозиции и рассмотрения каждой части как независимой.

Прежде, чем рисовать диаграммки,
1. просто составьте таблицу: Актор - Юзкейс и лучше по-русски.
2. Web-browser - это не роль, но веб-браузер может играть некоторую роль. Например, клиента
3. Для каждого выделенного вами юзкейса задайте вопрос: Буду ли я использовать его независимо от других? Или он имеет смысл, если запущен, выполнен другой юзкейс? Если ответ положителен, удаляйте этот юзкейс - это всего лишь шаг или часть другого юзкейса. В вашем случае таких юзкейсов большинство.

4. Прислушайтесь к совету Дениса Бескова - он признанный авторитет в области системного анализа.

Большое спасибо за отмеченные минусы и недоделки.
Очень ценные советы!Буду продолжать-улучшать, уже с их учетом

Единственный вопрос для Galogen: я к сожалению не совсем понял вашей фразы

Или он имеет смысл, если запущен, выполнен другой юзкейс?

Не могли бы вы перефразировать?

Добрый день!

Что-то все по-новому. Давно не был.

По поводу диаграммы UC.

Если читать книжку Коберна "за смысл", можно заметить, что он выделяет <<primary>> Actors.
Т.е., даже, если c UC взаимодействуют множество Actors, есть только один, цель которого выполняет UC. Actor не должность, а роль!

С другой стороны, любая диаграмма предназначена не для того, чтобы показать все, что мы знаем о той или иной предметной области, а для того, чтобы проиллюстрировать какую-то идею, мысль, явление. Эргономисты считают, что если на диаграмме более 9 сущностей, она нечитаема, а значит рисовать ее нет смысла.

Как я поступаю для разрешения сложности.
Рисую диаграмму, содержащую основные UC и их первичных Actors. Это то, для чего нужна система (хотелось написать "функции системы", но меня Юра в очередной раз "прихватит").
Рисую контекстную диаграмму, если требуется, для UCs. Она содержит всех Actors, а также Extend и Includ UCs.

Но это примерно то, о чем писал Эдуард.

Честно говоря, я представленную диаграмму даже читать не стал. Тем более, у меня с языками проблема. Знаю всего три: командный, матерный и русский (со словарем).

P.S. Я, наконец, нашел работу!

1. На этой диаграмме подозрительно много ВИ. Эдуард Вам замечательно описал, как избавиться от лишних. Еще уберите вторичных актеров и диаграмма облегчится.

2.  Тот факт, что будет использоваться браузер или другие системы, не нужно показывать на диаграмме ВИ. Это не ее цель. Для этого можно использовать контекстную диаграмму, например. Только если внешняя система является первичным актером, ее нужно отразить на диаграмме. В вашем случае это может быть Консультант Гарант, если взаимодействие происходит независимо от пользователя. Но если обновление будет по расписанию, то тогда первичным актером будет Время и Консультант Гарант опять же можно не показывать.

3. "Составить расписание" и "Произвести резервное копирование" - независимые в контексте этой диаграммы ВИ. У них разные первичные актеры, Админ и Время, и между ними не нужно показывать связь совсем.

4. Ответ в п. 3.

Успехов.

Единственный вопрос для Galogen: я к сожалению не совсем понял вашей фразы Или он имеет смысл, если запущен, выполнен другой юзкейс? Не могли бы вы перефразировать?

Пусть имеется два ВИ: ВИ№1 и ВИ№2.
ВИ№2 не имеет смысла, если не выполнен (запущен) ВИ№1. Очевидно, что нельзя получить чек, не сделав покупку. У вас же на диаграмме это возможно. Потому следует обязательно проверить подобную связку. Т.е. имеет ли смысл получение чека само по себе? Т.е. я как актор обращаюсь к системе для того, чтобы получить чек. Или я все-таки обращаюсь к системе, чтобы совершить покупку, в ходе которой я ожидаю получить и чек?

P.S. Я, наконец, нашел работу!

Очень рад за Вас!

Galogen

Потому следует обязательно проверить подобную связку. Т.е. имеет ли смысл получение чека само по себе?

Благодарю за ваше пояснение.  Обязательное проанализирую диаграмму на данную связку

Alfia

У них разные первичные актеры, Админ и Время, и между ними не нужно показывать связь совсем.

Как вы думаете, правильным ли решением будет отдать данные прецеденты только одному актеру, например Время.
А для Админа тогда будут иные прецеденты?

For All
Как стоит отразить тот факт, что обновление и резервное копирование может проводиться как в ручную,так и по расписанию на данной диаграмме? Пока к сожалению, не могу понять, как это сделать

Как стоит отразить тот факт, что обновление и резервное копирование может проводиться как в ручную,так и по расписанию на данной диаграмме? Пока к сожалению, не могу понять, как это сделать

Диаграмма вариантов использования является лишь часть модели использования. Модель использования делает акцент на определении границ системы и отвественностей системы перед ее окружением.
Окружение делится на активные сущности - это те, которые активируют исполнение тех или иных ответственностей, и пассивные - которые сами не инициируют ВИ, но могу участовать в них для достижеия целей активных.
ДВИ не описывает принципы работы систем, она лишь определяет, что от системы требуется.

Теперь ближе к делу

обновление и резервное копирование может проводиться как вручную,так и по расписанию

1. кто производит обновление и резервное копирование?
2. зачем это ему нужно?
3. это аспект использования системы? какой?
4. это аспект поддержки и сопровождение работоспособности системы?
5. если запуск по расписанию -> автоматически, т.е. по событию времени, таким образом это будет актор Время или Таймер.

Тем не менее все изображать На ДВИ, даже то, что и иногда вполне возможно, не следует, для этого существуют масса иных возможностей. Следует понять, ДВИ - отражает схематично только часть требований.

Как вы думаете, правильным ли решением будет отдать данные прецеденты только одному актеру, например Время.
А для Админа тогда будут иные прецеденты?

ВИ "Создать расписание" не может выполняться по времени, поскольку именно в этом ВИ и будет создаваться набор задач для автоматического выполнения. Очевидно, это будет ВИ для Админа.
ВИ "Произвести резервное копирование" - может быть выполнено по расписанию (актер Время) и Админом. Но будет ли он при этом выполняться одинаково? Если да, то просто можно связать этот ВИ с обоими актерами. А если нет, то нужно два разных ВИ с разными названиями.

Я бы вам предложила немного сместить ваш фокус в отношении видов требований, которые вы хотите отразить на этой диаграмме. Функции такого рода, как резервное копирование, относятся в поддержке функционирования системы, а не к предметной области бизнеса. Я их называю системными требованиями. Поэтому, я бы рекомендовала забыть про них на некоторое время и сконцентрироваться на функциях для поддержки бизнеса. После того, как вы определитесь с требованиями бизнес уровня и уровня пользователей, приступайте к требованиям системного уровня.

Alfia спасибо
Думаю моей главной ошибкой является - смешение всего в одну кучу и излишнее нагромождение. Будем упрощать

For All
Коллеги, как вы думаете, возможно ли поступить таким образом:

Создать ряд диаграмм классов, на каждой из которых будет выражена какая-либа своя суть? (виды требований)
То есть ,например, у меня имеется документ с требованиями от заказчика. Я проанализировал этот документ, разбил его на совокупности (группы, блоки, части). И по каждой такой группе сделал диаграмму класса.

Или например, сделать ряд диаграмм классов, каждая из которых будет показывать систему с какой-либо стороны(взгляда)

Практикуется ли вообще, такой подход?

Практикуется ли вообще, такой подход?

Касательно документа - да.
Можно еще брать документ, ставить ему в соответствие класс и добавлять классу атрибуты, которые будут отражать структурные элементы исходного документа. Иногда я так делаю.

Добрый день!

Что-то все по-новому. Давно не был.

По поводу диаграммы UC.

Если читать книжку Коберна "за смысл", можно заметить, что он выделяет <<primary>> Actors.
Т.е., даже, если c UC взаимодействуют множество Actors, есть только один, цель которого выполняет UC. Actor не должность, а роль!

С другой стороны, любая диаграмма предназначена не для того, чтобы показать все, что мы знаем о той или иной предметной области, а для того, чтобы проиллюстрировать какую-то идею, мысль, явление. Эргономисты считают, что если на диаграмме более 9 сущностей, она нечитаема, а значит рисовать ее нет смысла.

Как я поступаю для разрешения сложности.
Рисую диаграмму, содержащую основные UC и их первичных Actors. Это то, для чего нужна система (хотелось написать "функции системы", но меня Юра в очередной раз "прихватит").
Рисую контекстную диаграмму, если требуется, для UCs. Она содержит всех Actors, а также Extend и Includ UCs.

Но это примерно то, о чем писал Эдуард.

Честно говоря, я представленную диаграмму даже читать не стал. Тем более, у меня с языками проблема. Знаю всего три: командный, матерный и русский (со словарем).

P.S. Я, наконец, нашел работу!

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

Практикуется ли вообще, такой подход?

Практикуется, конечно. Если диаграмма содержит слишком много элементов, ее даже рекомендуется разбить на несколько. Это относится к любому типу диаграмм (класса, ВИ, бизнес-процессов). Вопрос, сколько элементов считается много и по какому принципу разбивать.
Я считаю, "много" для разного типа диаграмм означает разное. Например, для диаграммы ВИ, больше 15 ВИ я считаю уже много. Для классов - до 50 классов вполне читабельно.

О принципах разбиения. Вы можете сами решить, какими принципами руководствоваться. Главное, чтобы за этим была какая-то понятная заказчику логика. При этом допускается повторять какие-то элементы на нескольких диаграммах. Вот примеры некоторых способов разбиения:
- по функциональным темам предметной области
- по модулям или компонентам системы
- по отношению к подразделениям организации-заказчика

Успехов.