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

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

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

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

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

Я посоветовал вам использовать шаблон 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

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

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

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

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