Может кто-нибудь сказать мне, пытался ли я использовать вариант использования диаграммы правильно для этого сценария?

Question

У меня есть сценарий, для которого мне нужно спроектировать диаграмму прецедентов, диаграмму деятельности и диаграмму классов:

«Я управляю небольшой консалтинговой фирмой с несколькими сотрудниками. Наряду с основной информацией о сотрудниках (имя, DoB, контактные данные и т. д.) Мне нужно иметь возможность отслеживать, какой тип роль, которую они выполняют, такие как техник оборудования, программист и Установщик программного обеспечения. Один сотрудник может выполнять несколько ролей, и Каждая роль связана с почасовой оплатой. Мне нужно сохранить имя и контактные данные всех клиентов, которые заключили с нами договор. клиент может иметь несколько контрактов одновременно, но каждый Контракт связан только с одним клиентом. Каждый контракт имеет имя, описание, дата создания и тип работы - например, система Разработка, обновление программного обеспечения. Никаких подробностей типов работ не требуется захвачен кроме их имени. Каждый контракт также имеет один сотрудник назначен руководителем проекта. Один сотрудник может быть руководитель проекта по нескольким контрактам ».

Я попытался нарисовать диаграмму вариантов использования, и я хочу знать, правильно ли я ее нарисовал, и есть ли какие-либо ошибки или какие-либо улучшения, которые следует сделать:

Answer 1

Давайте проанализируем ваши требования, чтобы определить варианты использования:

• Управление сотрудником

  I Управлять небольшой компьютерной консалтинговой фирмой сряд сотрудников.Наряду с базовой информацией о сотрудниках (имя, DoB, контактные данные и т. Д.) Мне нужно иметь возможность отслеживать , какую роль они выполняют, например, специалист по аппаратному обеспечению, программист и программное обеспечение.Установщик.Один сотрудник может выполнять несколько ролей, и с каждой ролью связана почасовая оплата.

• Управление данными клиента (может быть включено в управление контрактами)

  Мне нужно сохранить имя и контактные данные всех клиентов , которые имеют с нами контракт .

• Управление контрактами

  Клиент может иметь несколько контрактов одновременно, но каждый контракт связан только с одним клиентом.Каждый контракт имеет имя, описание, дату создания и тип задания - например, «Разработка системы», «Обновление программного обеспечения».Никаких подробностей о типах заданий не требуется, кроме их имени.

• Назначение руководителей проектов (может быть включено в управление контрактами)

  В каждом контракте также есть один сотрудник, назначенный руководителем проекта.Один сотрудник может быть руководителем проекта по нескольким контрактам ».

Теперь за этим предложением можно скрыть больше вариантов использования, которые можно вывести.Тем не менее, давайте посмотрим критически, если дополнительные, которые вы определили, подходят.

На первый взгляд, все выглядит нормально:

• Заключить контракт (точнее, чем управлять контрактом . С другой стороны, чтос изменением и расторжением договора?)
• Укажите контактные данные (номинал Управление контрактом )
• Сохранить данные клиента (похоже на управление данными клиента ) но кто будет владельцем?
• Назначение руководителя проекта (см. Выше)
• Назначение других участников (отлично: явно не указано, но если сотрудники назначены на роли ипочасовая оплата, это определенно потому, что важно назначить их для проектов)
• Назначить сотрудников для проекта (см. предыдущие пункты)

Следующие варианты использования сомнительны:

• Принять контракт : действительно ли владелец контракта (кто это: клиент? Лидер? SO еще?) Действительно примет его в СИСТЕМЕ?
• Выполнить роль : подразумевается ли здесь, что сотрудники будут использовать систему для выполнения своей роли?Или они просто зарегистрируют время для проектов?Или они вообще не будут взаимодействовать с системой?
• почасовая оплата (тот же вопрос)
• Руководство проектом : будет ли руководитель проекта взаимодействовать с системой, чтобы вести проект?или он / она только что зарегистрирован в качестве руководителя с целью административной ответственности?

Наконец, некоторые из этих требований выходят за пределы (ориентированного на цель) варианта использования и описывают модель классов.Не попадайтесь в ловушку: сценарий использования должен фокусироваться на взаимодействии субъекта с системой.