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

Ответ 1

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

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

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

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

UPDATE

Я понимаю взаимоотношения композиций login/user (part/whole). Прежде чем продолжить, см. Этот ответ о композиции и агрегации.

Но то, что я не понимаю, является целью классов 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 с книгой Hibernate.

Ответ 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

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

Ответ 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

Ответ 4

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

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

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

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