Обзор диаграммы вариантов использования UML для инструмента отслеживания расходов

Question

Мне нужно создать инструмент отслеживания расходов. Этот инструмент позволит отдельному пользователю вести учет своих расходов, а также прогнозировать финансовое состояние на определенную дату.

Пользовательский интерфейс

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

Интерфейс должен иметь как минимум следующие представления:

1. Просмотр контактов для ввода и обновления информации о контактах (плательщики или получатели).
2. Представление ввода расходов для ввода и обновления сведений о расходах за определенный день.
3. Представление финансового отчета - отображение всех расходов за выбранный диапазон дат.
4. Представление, позволяющее пользователю увидеть свое прогнозируемое финансовое состояние на определенную дату.

Для дополнительного кредита:

5. Представление для ввода событий: встречи и задачи.
6. Еженедельный просмотр с отображением ежедневных событий и расходов.

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

Постоянное хранение данных времени выполнения

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

Моя UML диаграмма

Можете ли вы рассмотреть следующую диаграмму?

Answer 1

Подходят ли варианты использования для требований пользовательского интерфейса?

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

Если вам нужно спроектировать пользовательский интерфейс (как, по-видимому, требуется описательная часть вашего упражнения), вам может потребоваться не UC, а каркасные схемы для создания эскиза UI.

Каковы UC в ваших требованиях?

Имея это в виду, я бы выделил в ваших требованиях следующий UC:

• Manage contact details (# 1) - Я использовал выделенный Матекстовый nage, чтобы сократить Enter или обновить. - Открытый вопрос: может быть, два UC после всех: Manage Payer details + Manage payee details,
• Manage expenses for a day (#2) - выбор даты - это деталь интерфейса, а не ОК!
• Report expenses (# 3) - выбор диапазона дат является деталью пользовательского интерфейса, а не UC!
• Forecast financial situation (# 4)
• Enter (maintain?) events (# 5)
• Report weekly situation (# 6)

Что можно улучшить в вашей диаграмме?

Теперь обзор вашей собственной диаграммы UC:

• Select data range может быть включением для Add transation а также Generate reports (Осторожно: опечатка), так как это часть поведения и включенный UC неполон без включенного UC. Обратите внимание, что наличие отдельного UC кажется мне искусственно детализированным и не рекомендуется.
• Select data range в принципе не должно быть продолжением Add transationпотому что расширение не является обязательным, и расширенный UC должен быть завершен без расширения. И здесь нет смысла Add a transaction не зная даты.
• Я бы предложил изменить имя UC с активного поведения: выбор / выбор диапазона данных, еженедельное представление создания / отчета
• В настоящее время вы используете обобщение в вашем случае использования. Хотя это не самая распространенная практика, это совершенно законно: UC является классификатором, и классификаторы можно обобщать. Тем не менее, когда обобщение используется в UC, оно, как правило, имеет тот же графический вид, что и все другие "ссылки", отдельные и между только двумя элементами, и обычно не в форме совместно используемой цели ( пример). Обратите внимание, что наименования ваших специализаций напоминают существительные, соответствующие объектам данных (например, " Плательщик"), а не поведению (например, " Управление плательщиками"). Также обратите внимание, что опечатка привела к тому, что получатель был там дважды

Edit: больше об обобщении в UC

Существует некоторая полемика по поводу использования наследования в UC, поскольку его практическое значение не столь интуитивно, как у других видов отношений.

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

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

• Он не использовал наследование в своем UC до того, как они были включены в UML.
• Он также не использует его в своей последней работе над Use Case 2.0, где он продвигает использование срезов прецедентов, чтобы справиться с вариантами.

Answer 2

Используйте глагол, чтобы назвать свои UC, доход, расходы, получателя, диапазон данных и еженедельный просмотр не UC, но они в основном соответствуют данным.

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

Я не знаю, что такое правильный UC для Data Range, так сложно проверить ваш экстенд / включение, но, как Томас Килиан, я сомневаюсь в них