Нарисуйте диаграммы последовательности для приложения Java Swing
У меня есть простая система банкоматов, реализованная на Java с использованием Swing (я знаю, что Swing больше не используется, но я хотел, чтобы он был простым). То, как я это реализовал, выглядит следующим образом:
- У меня есть класс
Customer, который содержит информацию о клиенте и имеет методlogin() - У меня есть класс
Account, который содержит информацию об учетной записи и имеет методы для снятия, внесения и перевода денег. - У меня есть класс
Transaction, который содержит информацию о транзакции, и методgenerateReceipt(), который создает и экспортирует PDF-файл с информацией о транзакции. - У меня есть класс
ATM, который содержит зарегистрированную учетную запись и соответствующего клиента и имеет статические методы для получения транзакций, таких как транзакции текущей учетной записи. - Наконец, у меня есть класс
Adminс именем пользователя и паролем в качестве атрибутов и методов для получения всех клиентов и учетных записей, добавления клиента или создания учетной записи и удаления клиента или учетной записи.
Мое приложение использует базу данных MySQL для хранения информации и внесения обновлений. Кроме того, клиенты могут иметь несколько учетных записей, и войти в систему можно с помощью номера учетной записи и PIN-кода.
Я нарисовал диаграммы вариантов использования и диаграмму классов, не учитывая мой пользовательский интерфейс в диаграмме классов.
Мне трудно создавать диаграммы последовательности для этого приложения, так как все мои классы и объекты используются в классах, созданных с помощью Swing. Мой вопрос: как мне структурировать диаграммы последовательности, учитывая тот факт, что это приложение Swing? Должен ли я добавить классы пользовательского интерфейса или сделать его более концептуальным и описывать только процесс и отношения между моими другими 5 классами? Любая помощь высоко ценится!
Я попытался отделить как можно больше логики от фактического пользовательского интерфейса, но я все еще не могу понять, как должны выглядеть мои диаграммы последовательности, когда клиент и администратор взаимодействуют с фреймами Swing.
Допустим, я хочу нарисовать диаграмму последовательности процесса входа клиента в систему. Учитывая структуру моих классов, какой объект должен отправить субъект клиента сообщение «введите номер счета и PIN-код»? Мой ответ будет заключаться в том, что ему нужно отправить сообщение объекту банкомата. Однако в моем случае входные данные поступают в класс CustomerLogin, который представляет Swing-форму входа в систему, поэтому он представляет пользовательский интерфейс. В CustomerLogin я создаю объект Customer, для которого вызываю метод login().
Ответы 1
Диаграмма классов без какой-либо внутренней части приложения является «моделью предметной области». Его цель не в том, чтобы задокументировать все возможные классы, используемые в ваших приложениях, а в том, чтобы сосредоточиться на знании предметной области, независимо от того, как приложение реализовано. Диаграмма осталась бы прежней, если бы у вас был настоящий банкомат, если бы вы реализовали веб-службу или использовали бы любую другую структуру пользовательского интерфейса.
Итак, вы сделали четкий выбор того, что вы хотите показать на диаграмме. Вы могли бы выбрать чудовищную диаграмму классов, включающую в себя классы, необходимые для бизнес-логики, для взаимодействия с базой данных и для пользовательского интерфейса (например, используя знаменитый шаблон Entity Boundary Control). Тогда диаграмма будет больше зависеть от вашего выбора реализации.
Для диаграммы последовательности это то же самое. Нет лучшего способа составить эту диаграмму. Вопрос только в том, на чем вы хотите сосредоточить внимание на этой диаграмме: хотите ли вы смоделировать логику предметной области? В этом случае вы должны использовать свои доменные классы и показать, как они взаимодействуют. Или вы хотите смоделировать подробный дизайн приложения, и в этом случае вы можете предусмотреть также добавление классов пользовательского интерфейса. Но тогда диаграммы быстро станут очень сложными, и вам лучше разбить их на несколько более простых SD, каждая из которых будет посвящена некоторым частям вашего подробного технического проекта.
Я вижу, лучшего пути нет. Таким образом, было бы хорошо добавить только актера Customer, фрейм пользовательского интерфейса Swing для входа в систему, из которого отображаются сообщения JOptionPane относительно процесса входа в систему, клиента, банкомата и базы данных?
@AdrianFloroiu Верно. Используйте столько SD, сколько вам нужно. Вероятно, по одному на сотрудничество (более вероятно, несколько, поскольку у каждого сотрудничества много сценариев).
Последовательность должна быть независимой от реализации, то есть последовательность может быть реализована в текстовом, веб-, настольном или мобильном интерфейсе, это не имеет значения. Если ваши классы моделей тесно связаны с вашим пользовательским интерфейсом, у вас есть проблема. Ваши классы моделей должны делать именно это, моделировать данные, а затем пользовательский интерфейс будет взаимодействовать с ними в соответствии с тем, что описывает диаграмма последовательности. Мое предложение — рассмотреть UI на диаграмме, «как» использование взаимодействует с потоком, не должно волновать.