Диаграмма классов UML для входа пользователя

Question

Диаграмма ниже - моя самая первая попытка создать диаграмму классов UML, описывающую логин пользователя на веб-сайте.

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

Буду благодарен за любые советы, критику, комментарии и предложения. Заранее спасибо.

Answer 1

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

---

---

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

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

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

UPDATE

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

Но что я не понимаю, так это назначение классов 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);

Как видите, WebMaster, Moderator и Member - это просто роли , определенные вашим сайтом. Больше ничего.

Хорошим ресурсом об UML и ORM является Java Persistence с книгой Hibernate.

Answer 2

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

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 ... так что вам не нужен шаблон фасада при доступе к вашим данным.)

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

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

Answer 3

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

http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691

Answer 4

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

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

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

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