UML Exercise ATM Диаграмма прецедентов

Question

У меня есть задание, в котором изложены следующие условия:

Краткое изложение цели: банкомат - это электронное устройство, предназначенное для автоматического выдачи денег.Пользователь может быстро и легко вывести деньги после авторизации.Пользователь взаимодействует с системой через кард-ридер и цифровую клавиатуру.Небольшой экран дисплея позволяет отображать сообщения и информацию для пользователя.Члены банка могут получить доступ к специальным функциям, таким как заказ выписки. Краткое описание требований: Требуется банкомат 1. Чтобы уполномоченные держатели карт могли совершать транзакции

1. Владельцы карт должны просматривать и / или распечатывать остатки на счетах
2. Владелец карты должен снять наличные
3. Владелец карты должен внести наличные или чековые депозиты
4. Владелец карты должен покинуть сессию

Чтобы позволить членам банкаполучить доступ к дополнительным, специальным услугам

1. Участник банка может заказать выписку
2. Участник банка может изменить данные безопасности (например, PIN-код)

Чтобы разрешить доступ к уполномоченному персоналу банка

1. Уполномоченный персонал может получить доступ для пополнения запаса аппарата

2. Уполномоченный персонал может выполнять плановое обслуживание иобслуживание

3. Чтобы отслеживать, сколько денег в нем содержится, и оповещать сотрудников банка, когда запасы становятся низкими

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

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

Я построил следующую диаграмму сценариев использования, но не понимаю, насколько подробным он должен быть, какими должны быть расширения / включения, а какие простобазовый случай.Любые отзывы приветствуются.

Должны ли члены банка и держатели карт быть отдельными или вместе?Технически, члены банка могут делать больше, чем владелец карты, например, обновлять информацию о безопасности или выписывать заказы, но не все ли владельцы карт участников банка?

Здесьдругая версия, которая у меня есть, за исключением того, что она не является прецедентом, есть ли другие факторы, которые неверны?

Answer 1

Вот пара наблюдений:

• Как прокомментировано, Quit не имеет смысла, так как не добавляет никакого значения актеру.Скорее, это выглядит как постусловие для других вариантов использования.
• Обобщение вариантов использования - плохая идея (хотя допускается для UML).Вариант использования показывает одну уникальную часть добавленной стоимости для актера, использующего рассматриваемую систему.В этом контексте группирование нескольких вариантов использования под заголовком «общего» варианта использования не помогает.Вместо этого соедините специализации непосредственно с актером и удалите это Transaction.
• Вместо дублирования ассоциаций Bank Members на Quit/Transaction вы можете сделать обобщение на Auth Card Holders.
• Лучше использовать единственное число для актера.Это общее имя роли, и само по себе оно охватывает любое количество реальных людей / машин.
• Частью требования / описания являются сценарии, которые входят в варианты использования.Распространенной ошибкой является попытка выставить их в функциональной декомпозиции в случаях использования.

Ваша попытка неплохая.Но создать сценарии использования из требований непросто и требует большого опыта.Поэтому (как всегда) я рекомендую прочитать Bittner / Spence о вариантах использования.(Не читайте спецификации UML, чтобы получить представление о синтезе UC. В лучшем случае они могут дать синтаксис, как использовать пузыри и придерживаться людей.)

---

Как прокомментировал www.admiraalit.nlтам «может быть» приложения для обобщения случаев использования и вы можете обсудить, что спорно.Я предпочитаю не использовать их, поскольку использовать их неправильно проще, чем правильно их использовать.То же самое касается экспорта / импорта.Избегайте этого, пока вы точно не знаете, для чего это нужно.Вы склонны начинать функциональную декомпозицию, а это не то, для чего нужны UC.