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

Question

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

Интерфейс пользователя

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

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

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

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

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

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

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

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

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

Можетпожалуйста, просмотрите следующую диаграмму?

Answer 1

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

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

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

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

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

• Manage contact details (# 1) - Я использовал Ma выделенный текст nage для сокращения Ввод или обновление -Открытый вопрос: может быть, два UC в конце концов: Manage Payer details + Manage payee details.
• Manage expenses for a day (# 2) - выбор даты является деталью пользовательского интерфейса, а не UC!
• 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, оно, как правило, с тем же графическим оформлением, что и все другие «ссылки», разделенное и только между двумя элементами, и обычно не в форме общего назначения (пример ).Обратите внимание, что названия ваших специализаций звучат как существительные, соответствующие объектам данных (например, Payer ), а не как поведения (например, Manage payers ).Также обратите внимание, что опечатка привела к тому, что Получатель был там дважды

Редактировать: подробнее об обобщении в UC

Есть некоторые противоречияИспользование наследования в UC, так как его практическое значение не так интуитивно, как другие виды отношений.

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

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

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

Answer 2

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

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

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