UML Class Diagram for User Login

Question

The diagram below is my very first attempt at creating a UML class diagram describing a user login into a website.

I'm sure its a poor design and full of flaws, but I'm hoping to learn from you guys how you would design a simple login like this. I'm particularly interested in your use of design patterns and which patterns you would use, how you would implement it in the design, and why.

Any advise, criticisms, comments and suggestions will be really appreciated. Thanks in advance.

Answer 1

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.

Answer 2

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

Answer 3

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