web-dev-qa-db-fra.com

Diagramme de classes UML pour la connexion utilisateur

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

rubbishlogindesign

Je suis sûr que c'est une mauvaise conception et pleine de défauts, mais j'espère apprendre de vous comment vous concevriez une connexion simple comme celle-ci. Je suis particulièrement intéressé par votre utilisation des modèles de conception et les modèles que vous utiliseriez, comment vous les implémenteriez dans la conception et pourquoi.

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

design-patternsoopclass-designuml
18
Anthony

Voici comment nous implémentons cette fonctionnalité

Class Diagram

Comme vous pouvez le voir, nous avons de nombreuses applications (ici, cela se comporte comme votre site Web).

Modérateur, WebMaster et Membre, comme indiqué dans votre mappage, ce serait mieux en tant que rôle. Que se passe-t-il si vous devez ajouter un nouveau "rôle". Vous devrez peut-être changer tout votre modèle.

Chaque UserApplication (UserWebsite) a sa date de début et de fin. Et chaque application a son propre rôle. Un site Web de banque a besoin d'un rôle de gestionnaire. Un site Web de compagnie d'assurance maladie a besoin d'un rôle d'agent et ainsi de suite ...

[~ # ~] mise à jour [~ # ~]

Je comprends la relation de composition login/utilisateur (partie/ensemble). Avant de continuer, consultez cette réponse sur la composition par rapport à l'agrégation.

Mais ce que je ne comprends pas, c'est le but des classes UserApplication et Application

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

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

Aucun. Il donne simplement un rôle à une application utilisateur. Je peux utiliser le module financier, qui définit les rôles suivants: Manager, Client et Autre, où je peux jouer le rôle de Manager. Mais je peux vous affecter 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 Web 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 Membre 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.

23
Arthur Ronald

j'ai examiné la description de votre cas d'utilisation., c'est faux, ça 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.”

Après avoir écrit votre cas d'utilisation, vous dessinez votre SSD comme ceci.

alt text

et le diagramme d'interaction du SSD susmentionné comme celui-ci.J'ai supposé que vous utilisez l'ORM (comme Hibernate, LinqToSql, EntityFramework ... afin que vous n'ayez pas besoin de motif de façade lors de l'accès à vos données.) alt text

et mec, vous ne décidez pas d'autres utilisateurs à partir d'un cas d'utilisation. Alors Larman dit que ce groupe utilise le cas d'utilisation 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 plusieurs classes. Il suffit de lire le livre de Larmans et de regarder ces présentations http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

si vous attribuez la responsabilité de la mise en œuvre des classes sera si facile. peut-être que vous n'aimez pas lire, mais parfois nous devrions lire certains livres. Le livre de Larmans est l'un des livres préférés des ingénieurs logiciels. De nombreuses universités utilisent ce livre pour leur analyse et conception orientées objet.

7
ibrahimyilmaz

je vous ai conseillé d'utiliser le modèle 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 également que la racine du motif Gof est Grasp. dans votre conception, je suis désolé de regretter de dire que votre cas d'utilisation n'est pas bien défini et ce diagramme de classes devrait être votre modèle de domaine car il reflète les concepts dans votre cas d'utilisation. Je suis opposé à faire un diagramme de classe avant de faire la séquence du système et le diagramme d'interaction sur le soi-disant cas d'utilisation. dans votre modèle de domaine Le membre régulier, le webmestre et le modérateur sont des utilisateurs et nous pouvons dire utiliser un compte utilisateur . Soit dit en passant, ne faites pas d'héritage aussi longtemps que vous ne le devriez pas, car cela augmente le couplage de votre classe, donc vous ne pouvez pas faire de refactoring lisible. http://en.wikipedia.org/wiki/GRASP_ (Object_Oriented_Design)

alt text

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

3
ibrahimyilmaz

Je vois 2 endroits que je changerais:

1) La base de données n'est pas une classe et ne doit pas apparaître dans un diagramme de classes. Ceci est probablement réel pour User_account (si je comprends bien, c'est une table à l'intérieur de DB)

2) Lorsque 3 classes sont héritées d'une 1 superclasse (WebMaster, Moderator, RegularMember from User), cela apparaît également comme je l'ai dessiné ci-dessous:

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