Diagrama de clase UML para inicio de sesión de usuario

Question

El siguiente diagrama es mi primer intento de crear un diagrama de clase UML que describa el inicio de sesión de un usuario en un sitio web.

estoy seguro de que es un diseño pobre y lleno de defectos, pero espero aprender de ustedes cómo se diseñe un inicio de sesión simple como esto. Estoy particularmente interesado en su uso de patrones de diseño y qué patrones usaría, cómo lo implementaría en el diseño y por qué.

Cualquier consejo, críticas, comentarios y sugerencias serán realmente apreciados. Gracias por adelantado.

Answer 1

Aquí es cómo ponemos en práctica este funcionallity

---

---

Como puede ver, tenemos muchas aplicaciones (aquí se comporta como su sitio web).

Moderador, WebMaster y miembro, como se muestra en su mapeo, sería mejor como un rol. Qué sucede si necesita agregar un nuevo "Rol". Tal vez tienes que cambiar todo tu modelo.

Cada UserApplication (UserWebsite) tiene su fecha de inicio y finalización. Y cada aplicación tiene su propio rol. Un sitio web del Banco necesita un rol de Gerente. Un sitio web Health Insurance Company necesita un papel de agente y así sucesivamente ...

ACTUALIZACIÓN

entiendo el usuario/usuario (parte/todo) relación de composición. Antes de continuar, consulte este answer sobre Composición versus Agregación.

Pero lo que no entiendo es el propósito de las clases y de aplicación UserApplication

pensar en la solicitud como su sitio web. Trabajo para una gran compañía de seguros de salud donde tenemos muchos módulos (cada módulo (aplicación) tiene su propio sitio web). Pero algunos usuarios, no todos, pueden usar cada módulo. Explica por qué defino UserApplication. papel

de papel en este proceso de inicio de sesión

Ninguno. Simplemente le da a UserApplication un rol. Puedo usar el módulo financiero, que define los siguientes roles: Gerente, Cliente y Otro, donde puedo desempeñar el papel de Gerente.Pero puedo asignarle un usuario temporal (startDate y endDate) como cliente para usar el módulo financiero.

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

Su sitio web parece

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

Como se puede ver, webmaster, el moderador y miembro son sólo papeles definidos por su sitio web. Nada más.

Un buen recurso sobre UML y ORM es Java Persistence with Hibernate book.

Answer 2

veo 2 lugares que cambiaría:

1) de base de datos no es una clase y no debe ser mostrado en un Diagrama de clases. Esto es probablemente real para USER_ACCOUNT (como entiendo que es una mesa dentro DB)

2) Cuando 3 clases se heredan de 1 superclase (WebMaster, Moderador, RegularMember de Usuario) también está mostrado como dibujé a continuación:

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

Answer 3

le aconsejé que utilice el patrón de diseño de agarre para hacer un buen diseño. Según esta disciplina, primero debe pensar en quién es responsable de realizar esta operación. Qué clase es responsable o qué método. Para resumir, también verás que la raíz del patrón Gof es agarrar. en su diseño, lamento decir que su caso de uso no está bien definido y este diagrama de clases debe ser su modelo de dominio porque refleja conceptos en su uso. Me opongo a hacer un diagrama de clases antes de hacer una secuencia del sistema y un diagrama de interacción sobre el llamado uso de casos. en su modelo de dominio Miembro habitual, maestro web y moderador es un usuario de y podemos decir que use cuenta de usuario. por cierto, no hagas la herencia todo el tiempo que no debas, ya que aumenta el acoplamiento de tu clase, por lo que no puedes volver a la refactorización. 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

Examiné la descripción de su caso de uso, no es correcto, puede ser:.

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

Después de escribir el su caso de uso, se dibuja tu SSD así.

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

y el diagrama de interacción de SSD mencionado como this.I supone utiliza el ORM (como Hibernate, LinqToSql, ADO.NET Entity Framework ... por lo que no necesita patrón de fachada al acceder a sus datos.) alt text http://i40.tinypic.com/dg6vma.jpg

y amigo, no decides otros usuarios desde un solo uso. Entonces Larman dice que ese grupo usa su caso y eligió un grupo para la implementación. Este grupo de casos de uso refleja su clase en la versión 1. por lo que en un caso de uso no puede obtener muchas clases. Solo lea el libro de Larmans y mire estas presentaciones http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

si asigna la responsabilidad a la implementación de las clases será tan fácil. tal vez no le guste leer, pero a veces deberíamos leer algunos libros. El libro de Larmans es uno de los libros favoritos de Sofware Engineers. Cualquier universidad utiliza este libro su Análisis y Diseño Orientado a Objetos.