Diagramme de classes UML pour la connexion utilisateur

Question

Le diagramme ci-dessous est ma toute première tentative de création d'un diagramme de classes UML décrivant la connexion d'un utilisateur à un site Web.

Je suis sûr que son design pauvre et pleine de défauts, mais je suis l'espoir d'apprendre de vous les gars comment vous concevoir une connexion simple comme cela. Je suis particulièrement intéressé par votre utilisation des modèles de conception et quels modèles vous utiliseriez, comment vous l'implémenteriez dans la conception, et pourquoi.

Des conseils, des critiques, des commentaires et des suggestions seront vraiment appréciés. Merci d'avance.

Answer 1

Voici comment nous mettons en œuvre cette fonctionel

---

---

Comme vous pouvez le voir, nous avons beaucoup d'applications (ici, il se comporte comme votre site web). Modérateur, WebMaster et membre, comme indiqué dans votre mappage, ce serait mieux comme un rôle. Que se passe-t-il si vous devez ajouter un nouveau "rôle"? Peut-être que vous devez changer tout votre modèle.

Chaque UserApplication (UserWebsite) a ses dates de début et de fin. Et chaque application a son propre rôle. Un site Web de la Banque a besoin d'un rôle de gestionnaire. Un site de la Société d'assurance-maladie a besoin d'un rôle d'agent et ainsi de suite ...

MISE À JOUR

Je comprends la composition login/utilisateur (partie/ensemble) de la relation. Avant de continuer, voir ce answer sur la composition par rapport à l'agrégation.

Mais ce que je ne comprends pas le but des UserApplication et des classes d'application

Think d'application comme votre site Web. Je travaille pour une grande compagnie d'assurance maladie où nous avons beaucoup de modules (chaque module (application) a son propre site web). Mais certains utilisateurs, pas tous, peuvent utiliser chaque module. Cela explique pourquoi je définis UserApplication.

rôle de rôle dans ce processus de connexion

Aucun. Cela donne simplement un rôle UserApplication. Je peux utiliser le module financier, qui définit les rôles suivants: Manager, Customer et Other, où je peux jouer le rôle de Manager.Mais je peux vous attribuer un utilisateur temporaire (startDate et endDate) en tant que client pour utiliser le module financier.

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

Votre site ressemble

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

Comme vous pouvez le voir, WebMaster, modérateur et membres ne sont que des rôles définis par votre site Web. Rien d'autre.

Une bonne ressource sur UML et ORM est Java Persistence avec le livre Hibernate.

Answer 2

Je vois 2 endroits où je changerais:

1) Base de données ne sont pas une classe et ne doit pas être montré dans un diagramm de classe. Ceci est probablement réelle pour USER_ACCOUNT (comme je comprends que c'est une table à l'intérieur DB)

2) Lorsque 3 classes sont héritées de 1 superclasse (WebMaster, Modérateur, RegularMember de l'utilisateur), il est également indiqué que je dessinais ci-dessous:

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

Answer 3

Je vous ai conseillé d'utiliser le motif Grasp Design pour faire un bon design.Selon cette discipline, vous devez d'abord penser à qui est responsable de cette opération. Quelle classe est responsable ou quelle méthode. Pour résumer, vous verrez aussi que la racine du motif de Gof est Saisir. dans votre conception, je suis désolé, je regrette de dire que votre cas d'utilisation n'est pas bien défini et ce diagramme de classe devrait être votre modèle de domaine, car il reflète les concepts dans votre cas. Je suis opposé à faire un diagramme de classes avant de faire une séquence de système et un diagramme d'interaction à propos de ce que l'on appelle une usecase. dans votre modèle de domaine Membre régulier, web maître et modérateur est un utilisateur et nous pouvons dire utiliser compte d'utilisateur. en passant, ne faites pas l'héritage tant que vous ne devriez pas, car il augmente le couplage de votre classe, donc vous ne pouvez pas faire de refactoring. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

alt text http://ecx.images-amazon.com/images/I/51997V9J7QL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

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

Answer 4

i examiné la description de votre cas d'utilisation, il est faux, il peut être:.

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

Une fois que vous écrivez le votre cas d'utilisation, vous dessinez votre SSD comme ça.

alt text http://i43.tinypic.com/2yozeb9.jpg

et le diagramme d'interaction du SSD comme mentionné ci-dessus this.I vous utilisez le supposé ORM (comme Hibernate, LinqToSql, EntityFramework ... de sorte que vous ne avez pas besoin modèle de façade quand accesing vos données.) alt text http://i40.tinypic.com/dg6vma.jpg

et mec, vous ne décidez pas d'autres utilisateurs d'un usecase. Donc, Larman dit que ce groupe utilise un cas et a choisi un groupe pour la mise en œuvre. Ce groupe de cas d'utilisation reflète votre classe dans la version 1. Donc, un cas d'utilisation vous ne pouvez pas obtenir beaucoup de classe. Il suffit de lire livre Larmans et regarder cette présentation http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

si vous attribuez la responsabilité à l'implémentation des classes sera si facile. Peut-être que vous n'aimez pas lire mais parfois nous devrions lire quelques livres. Le livre de Larmans est un livre préféré des ingénieurs de logiciel. Toutes les universités utilisent ce livre pour leur analyse et conception orientées objet.