design-patterns - method - factory pattern
Diagrama de clase UML para inicio de sesión de usuario (4)
Así es como implementamos esta funcionalidad.
Como puede ver, tenemos muchas aplicaciones (aquí, se comporta como su sitio web).
Moderador, WebMaster y Miembro, como se muestra en su asignación, sería mejor como un rol. ¿Qué sucede si necesita agregar un nuevo "Rol"? Tal vez tengas que cambiar todo tu modelo.
Cada aplicación de usuario (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. El sitio web de una compañía de seguros de salud necesita un rol de agente y así sucesivamente ...
ACTUALIZAR
Entiendo la relación de inicio de sesión / usuario (parte / totalidad) de la composición. Antes de continuar, vea esta answer sobre Composición versus Agregación.
Pero lo que no entiendo es el propósito de las clases de Aplicación de Usuario y Aplicación
Piense en la aplicación 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.
rol del rol en este proceso de inicio de sesión
Ninguna. Solo le da un rol a una aplicación de usuario. Puedo usar el módulo financiero, que define los siguientes roles: Gerente, Cliente y Otro, donde puedo desempeñar el rol de Gerente. Pero puedo asignarle un Usuario Temporal (fecha de inicio y fecha de finalización) 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 se ve como
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 puede ver, WebMaster, Moderator y Member son solo roles definidos por su sitio web. Nada más.
Un buen recurso sobre UML y ORM es Persistencia de Java con el libro de Hibernate.
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 fallas, pero espero aprender de ustedes cómo diseñarían un inicio de sesión simple como este. Estoy particularmente interesado en su uso de patrones de diseño y en los patrones que usaría, cómo lo implementaría en el diseño y por qué.
Cualquier consejo, crítica, comentario y sugerencia serán realmente apreciados. Gracias por adelantado.
Examiné la descripción de su caso de uso. Está mal, 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 caso de uso, dibuja su SSD de esta manera.
texto alt http://i43.tinypic.com/2yozeb9.jpg
y el diagrama de interacción del SSD mencionado anteriormente. Supongo que utilizas el ORM (como Hibernate, LinqToSql, EntityFramework ... así que no necesitas un patrón de fachada al acceder a tus Datos). alt text http://i40.tinypic.com/dg6vma .jpg
y amigo, no decides a otros usuarios de un solo caso. Así que Larman dice que el grupo usa su caso de uso 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 un caso de uso no puede obtener muchas clases. Solo lea el libro de Larmans y vea estas presentaciones en http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm
Si asignas responsabilidades a la implementación de las clases será muy fácil. tal vez no te guste leer, pero a veces deberíamos leer algunos libros. El libro de los Estados Unidos es uno de los libros favoritos de los ingenieros de software. Muchas universidades utilizan este libro en su Análisis y Diseño Orientado a Objetos.
Le aconsejé utilizar el patrón de diseño de agarre para hacer un buen diseño. Según esta disciplina, primero debe pensar quién es el responsable de realizar esta operación. ¿De qué clase es responsable o qué método? Para resumir, también verá que la raíz de Gof pattern es Grasp. en su diseño, lo siento, lamento decir que su caso de uso no está bien definido y este diagrama de clase debe ser su modelo de dominio porque refleja conceptos en su caso de uso. Me opongo a hacer un diagrama de clase antes de hacer la secuencia del sistema y el diagrama de interacción sobre el llamado caso de uso. en su modelo de dominio Miembro regular, web master y moderador es un usuario y podemos decir usar la cuenta de usuario . por cierto, no hagas herencia siempre que no debas hacerlo, porque aumenta el acoplamiento de tu clase, por lo que no puedes hacer una refactorización rápida. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
Veo 2 lugares que cambiaría:
1) La base de datos no es una clase y no debe mostrarse en un diagrama de clase. Esto es probablemente real para User_account (como entiendo que es una tabla dentro de DB)
2) Cuando 3 clases se heredan de 1 superclase (WebMaster, Moderador, Miembro Regular del Usuario) también se muestra como dibujé a continuación:
1 uses> 1..*
User <>--------------->UserAccount
/|/
|
|
_______|________
| | |
| | |
Mod WebM RegularM