UML Class Diagram for User Login

Here is how we implement this funcionallity

---

---

As you can see, we have many Application (Here, it behaves like your website).

Moderator, WebMaster and Member, as shown in your mapping, it would be better as a Role. What happens whether you need to add a new "Role". Maybe you have to change all of your model.

Each UserApplication (UserWebsite) has its start and end date. And each Application has its own Role. A Bank website needs a Manager role. A Health Insurance Company website needs a Agent role and so on...

UPDATE

I understand the login/user (part/whole) composition relationship. Before going on, see this answer about Composition versus Aggregation.

But what I do not understand is the purpose of the UserApplication and Application classes

Think of Application as your website. I work for a big Health Insurance Company where we have many modules (Each module (Application) has its own website). But some Users, not all, can use each module. It explains why i define UserApplication.

role's role in this login process

None. It just gives an UserApplication a role. I can use the financial module, which defines the following roles: Manager, Customer and Other, where i can play the role of Manager. But i can assign you a Temporary User (startDate and endDate) as Customer to use the financial module.

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);

Your website looks like

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);

As you can see, WebMaster, Moderator and Member are just roles defined by your website. Nothing else.

A good resource about UML and ORM is Java Persistence with Hibernate book.

i examined the description of your use case.,it is wrong,it can be :

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.”

After you write the your use case,you draw your SSD like this.

and interaction diagram of aforementioned SSD like this.I assumed you use the ORM(like Hibernate,LinqToSql,EntityFramework... so you dont need facade pattern when accesing your Data.)

and dude , you dont decide other users from one usecase. So Larman says that group ur use case and chose one group for implementation. This use case group reflect your class in version 1. so one use case you cant obtain many class. Just Read Larmans book and look these presentation http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

if you assign responsibility to the classes implementation will be so easy. maybe you dont like reading but sometimes we should read some books.Larmans book is one favourite book of Sofware Engineers. Any many university use this book their Object Oriented Analysing and Design.

I see 2 places I would change:

1) Database is not a class and should not be shown in a class diagramm. This is probably actual for User_account (as I understand it's a table inside DB)

2) When 3 classes are inherited from 1 superclass (WebMaster, Moderator, RegularMember from User) it's also shown as I drew below:

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

i adviced you to use Grasp Design pattern for making good design.According to this discipline ,firsty you should think who responsible for making this operation.Which class is responsible or which method. To sum up you will also see that Gof pattern's root is Grasp. in your design,i m sorry i regret to say your use case is not well defined and this class diagram should be your domain model because it reflects concepts in your usecase. I m opposed to make class diagram prior to making system sequence and interaction diagram about the so-called usecase. in your domain model Regular member, web master and moderator is a user and we can say use user account. by the way dont make inheritance as long as you should not,because it increase coupling of your class , so u cant make readly refactoring. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

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