Diagramme de classe UML pour L'ouverture de session de L'utilisateur
le diagramme ci-dessous est ma toute première tentative de créer un diagramme de classe UML décrivant l'ouverture de session d'un utilisateur dans un site web.
je suis sûr que c'est une mauvaise conception et pleine de défauts, mais j'espère apprendre de vous les gars comment vous pourriez concevoir une connexion simple comme ça. Je suis particulièrement intéressé par votre utilisation de modèles de conception et les modèles que vous utiliseriez, comment vous l'appliqueriez dans la conception, et pourquoi.
tous les conseils, critiques, les commentaires et les suggestions seront vraiment appréciés. Merci à l'avance.
4 réponses
Voici comment nous implémentons cette funcionallity
modérateur, WebMaster et Membre, comme indiqué dans votre mapping, ce serait mieux en tant que rôle. Qu'advient-il si vous avez besoin d'ajouter un nouveau "Rôle". Peut-être que tu dois changer tout ton modèle.
chaque application utilisateur (UserWebsite) a sa date de début et de fin. Et chaque Application a son propre rôle. Un site Web de la banque doit jouer un rôle de gestionnaire. Un site web d'une compagnie d'assurance maladie a besoin d'un rôle D'Agent et ainsi de suite...
UPDATE
je comprends l'utilisateur (partie/tout) composition de la relation. Avant de continuer, voir ceci réponse à propos de la Composition par rapport à L'agrégation.
mais ce que je ne comprends pas c'est le but de L'application et de L'application UserApplication les classes
pensez à L'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. Cela explique pourquoi je définis UserApplication.
rôle du rôle dans ce processus de connexion
Aucun. Ça donne juste un rôle à L'application de L'utilisateur. Je peux utiliser le module financier, qui définit les éléments suivants rôles: Gestionnaire, client et autre, où je peux jouer le rôle de gestionnaire. Mais je peux vous assigner un utilisateur temporaire (startDate et endDate) comme 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);
une bonne ressource sur UML et ORM est Java Persistence with Hibernate book.
j'ai examiné la description de votre cas d'utilisation.il est mauvais,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.”
après avoir écrit le cas de votre utilisation, vous dessinez votre SSD comme ceci.
texte alternatif http://i43.tinypic.com/2yozeb9.jpg
et diagramme d'interaction du SSD susmentionné comme celui-ci.J'ai supposé que vous utilisiez L'ORM(comme Hibernate,LinqToSql,Entitefram Framework... si vous n'avez pas besoin de façade modèle lors de l'accès aux Données.) texte alternatif http://i40.tinypic.com/dg6vma.jpg
et mec , vous ne vous décidez d'autres utilisateurs à partir d'un cas d'utilisation. Ainsi Larman dit que le cas d'utilisation de groupe ur et a choisi un groupe pour la mise en œuvre. Ce groupe d'utilisation reflète votre classe dans la version 1. si un cas d'utilisation, vous ne pouvez pas obtenir beaucoup de classe. Il suffit de lire larmans livre et regarder cette présentation http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm
si vous assignez la responsabilité à la l'implémentation des classes sera si facile. peut-être que tu n'aimes pas lire, mais parfois on devrait lire des livres.Larmans book est l'un des livres préférés des ingénieurs de logiciels. Beaucoup d'universités utilisent ce livre leur analyse orientée objet et la conception.
je me conseillé vous de faire usage de Saisir modèle de Conception pour la fabrication de bonne conception.Selon cette discipline, vous devriez 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 de GOF pattern est Grasp. 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 parce qu'il reflète des concepts dans votre usecase. Je m'oppose à faire le diagramme de classe avant réalisation de la séquence du système et du diagramme d'interaction sur la soi-disant usecase. dans votre modèle de domaine membre régulier, web master et modérateur est un utilisateur et on peut dire utiliser compte d'utilisateur. d'ailleurs ne faites pas l'héritage aussi longtemps que vous ne devriez pas,parce qu'il augmente le couplage de votre classe , de sorte que vous ne pouvez pas faire readly refactoring. http://en.wikipedia.org/wiki/GRASP_ (conception orientée vers L'objectif))
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
je vois 2 endroits que je changerais:
1) La base de données n'est pas une classe et ne doit pas être affichée dans un diagramme de classe. Ceci est probablement réel pour User_account (comme je comprends que c'est une table à L'intérieur de DB)
2) Quand 3 classes sont héritées de 1 superclasse (WebMaster, modérateur, RegularMember de L'utilisateur) c'est aussi montré comme j'ai dessiné ci-dessous:
1 uses> 1..*
User <>--------------->UserAccount
/|\
|
|
_______|________
| | |
| | |
Mod WebM RegularM