Архитектура программы

Рейтинг: 1Ответов: 1Опубликовано: 16.12.2014

Здравствуйте.

Поставили задачу написать программу - систему учета сведения о пользователях некоторой информационной системы. Использовать можно только Swing для интерфейса и стандартную Java. Также необходимо реализовать изменение статуса пользователей и учет активности пользователей. Я никак не могу придумать устройство программы. Пока что:

  1. Есть классы User (абстрактный), и далее его расширяют SimpleUser, администратор, модератор и т.д. Но не знаю, как реализовать различные права.
  2. Есть класс Engine, управляющий UI, обрабатывающий запросы от пользователей.
  3. Класс UI. Можно заходить в определённого пользователя (без логина-пароля) и взаимодействовать с системой.

Как реализовать различные права? Где хранить пользователей? Как вести учёт активности, к примеру? Как сделать "вход" в пользователя?
Заранее спасибо за помощь!

архитектура java swing
Источник: Stack Overflow на русском

Ответы

▲ 2

Как-то странно. Иерархия User->SimpleUser,Admin... не понятна. У вас при перещелкивании какой-то галки объекты пересоздаются? Т.е. был простой юзер, стал админ, вы объект юзера пересоздали?

На самом деле права реализуются через группы. Юзер входит в группу, значит что-то может. Если у вас группы предполагаются зашитыми жестко, значит надо создавать иерархию групп (хотя на самом деле там не иерархия, а множество), а не юзеров. В общем случае группа - это фактически совокупность прав для юзеров, входящих в группу. Права - это глобальный список возможных действий, возможных видов отображения интерфейса и т.д. Если юзер входит в несколько групп, права складываются бинарно через дизъюнкцию (or).

Например.

Вася входит в группу "SimpleUsers" и в группу "Admins".
Группа "SimpleUsers" содержит права на вход в UI без пароля.
Группа "Admins" содержит права на вход в админку по паролю. А также в UI отображается кнопка "Admin section".

ЗЫ Бывают варианты с приоритетом, когда сложение выполняется сложнее (через конъюнкцию или через отрицание). Типа модератор не может портить раздел, в котором он не хозяин. В БД это может быть реализовано через RLS (row level security).