Схема классов UML для входа пользователя

Вот как мы реализуем эту функцию

Как видите, у нас много приложений (здесь они ведут себя как ваш сайт).

Модератор, веб-мастер и член, как показано в вашем сопоставлении, было бы лучше в качестве роли. Что произойдет, если вам нужно добавить новую «Роль». Может вам придется поменять всю вашу модель.

Каждое UserApplication (UserWebsite) имеет дату начала и окончания. И у каждого приложения своя роль. Веб-сайту банка нужна роль менеджера. Веб-сайту медицинской страховой компании нужна роль агента и так далее ...

ОБНОВЛЕНИЕ

Я понимаю взаимоотношения между логином и пользователем (частично / полностью). Прежде чем продолжить, просмотрите этот ответ о композиции по сравнению с агрегированием.

Но чего я не понимаю, так это назначения классов UserApplication и Application.

Думайте о приложении как о своем веб-сайте. Я работаю в большой компании по страхованию здоровья, где у нас много модулей (каждый модуль (приложение) имеет свой веб-сайт). Но некоторые Пользователи, а не все, могут использовать каждый модуль. Это объясняет, почему я определяю UserApplication.

роль роли в этом процессе входа в систему

Никто. Это просто дает UserApplication роль. Я могу использовать финансовый модуль, который определяет следующие роли: менеджер, клиент и другие, где я могу играть роль менеджера. Но я могу назначить вам временного пользователя (startDate и endDate) в качестве клиента для использования финансового модуля.

Application financialModule = new Application();

financialModule.addRole(new Role("Manager"));
financialModule.addRole(new Role("Customer"));
financialModule.addRole(new Role("Other"));

User arthur = new User(new Login("#####", "#####"));
arthur.setFirstName("Arthur");
arthur.setLastName("Ronald");
arthur.setEnabled(true);

UserApplication financialModuleUser = new UserApplication(new Period(new Date(), null));
financialModuleUser.setUser(arthur);
financialModuleUser.addRole(financialModule.getRoleByDescription("Manager"));

financialModule.addUserApplication(financialModuleUser);

Ваш сайт выглядит как

Website myWebsite = new Website();
myWebsite.addRole(new Role("Member"));
myWebsite.addRole(new Role("WebMaster"));
myWebsite.addRole(new Role("Moderator"));

User you = new User(new Login("#####", "#####"));
you.setFirstName("FirstName");
you.setLastName("LastName");
you.setEnabled(true);

UserApplication myWebsiteUser = new UserApplication(new Period(new Date(), null));
myWebsiteUser.setUser(you);
myWebsiteUser.addRole(myWebsite.getRoleByDescription("WebMaster"));

myWebsite.addUserApplication(myWebsiteUser);

Как видите, веб-мастер, модератор и участник - это просто роли, определенные вашим веб-сайтом. Ничего больше.

Хорошим ресурсом по UML и ORM является книга «Java Persistence with Hibernate».

я изучил описание вашего варианта использования., это неверно, это может быть:

Use Case: Login The System
Scope: Your Project Name.
Primary Actor: User
StakeHolders and Interests:
User: want to sign-in the system without any mistake or error.
Preconditions: User should be the system user
Success Guarantee: User entered the system
Main Success Scenario:
1.  User enters login page.
2.  System builds login page. Fields such as username and password  are observed on the screen.
3.  Users enters required informations.
4.  Users sends information with a view to entering the system.
5.  System approves information, open the session of user and returns message ”Login process is successfull”.
Alternate flows:
      3a.User does not enter all required field.
              1.System wait that user enter so-called required field.
       4a.The information of user such as username or password is wrong
              1.System send message ”Your send wrong user parameters.”

После того, как вы напишете свой вариант использования, вы рисуете свой SSD следующим образом.

и диаграмма взаимодействия вышеупомянутого SSD, как это. Я предполагал, что вы используете ORM (например, Hibernate, LinqToSql, EntityFramework ... поэтому вам не нужен шаблон фасада при доступе к вашим данным.)

и чувак, вы не выбираете других пользователей из одного варианта использования. Итак, Ларман говорит, что групповой вариант использования ur, и выбрал одну группу для реализации. Эта группа вариантов использования отражает ваш класс в версии 1., поэтому для одного варианта использования вы не можете получить несколько классов. Просто прочтите книгу Лармана и посмотрите эту презентацию http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

если возложить ответственность на классы, реализация будет такой простой. может быть, вы не любите читать, но иногда нам стоит прочитать несколько книг. Книга Лармана - одна из любимых книг инженеров программного обеспечения. Многие университеты используют эту книгу для своего объектно-ориентированного анализа и проектирования.

Я посоветовал вам использовать шаблон Grasp Design для создания хорошего дизайна. Согласно этой дисциплине, в первую очередь вы должны подумать, кто несет ответственность за выполнение этой операции. Какой класс отвечает за это и какой метод. Подводя итог, вы также увидите, что корнем шаблона Gof является Grasp. в вашем дизайне, извините, я с сожалением вынужден сказать, что ваш вариант использования не определен должным образом, и эта диаграмма классов должна быть вашей моделью предметной области, поскольку она отражает концепции вашего варианта использования. Я против создания диаграммы классов до создания диаграммы последовательности и взаимодействия системы для так называемого варианта использования. в вашей модели домена Обычный член, веб-мастер и модератор является пользователем, и мы можем сказать, что он использует учетную запись пользователя. кстати, не делайте наследование до тех пор, пока вы этого не сделаете, потому что это увеличивает сцепление вашего класса, поэтому вы не можете быстро провести рефакторинг. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

https://rads.stackoverflow.com/amzn/click/com/0130925691

Я вижу 2 места, которые я бы изменил:

1) База данных не является классом и не должна отображаться на диаграмме классов. Вероятно, это актуально для User_account (насколько я понимаю, это таблица внутри БД)

2) Когда 3 класса наследуются от 1 суперкласса (WebMaster, Moderator, RegularMember от пользователя), это также показано, как я нарисовал ниже:

                 1     uses>   1..*
          User <>--------------->UserAccount
           /|\
            |
            |
     _______|________
     |      |       |
     |      |       |
   Mod     WebM   RegularM