Basta ya de buscar por todo internet porque llegaste al espacio perfecto, tenemos la solución que buscas y sin problema.
Solución:
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 mapa, sería mejor como Rol. ¿Qué sucede si necesita agregar un nuevo “rol”? Quizás tengas que cambiar todo tu modelo.
Cada UserApplication (UserWebsite) tiene su fecha de inicio y finalización. Y cada aplicación tiene su propio rol. El sitio web de un banco necesita un rol de administrador. 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 composición de inicio de sesión / usuario (parte / todo). Antes de continuar, vea esta respuesta sobre Composición versus agregación.
Pero lo que no entiendo es el propósito de las clases UserApplication y Application.
Piense en la aplicación como su sitio web. Trabajo para una gran compañía de seguros médicos donde tenemos muchos módulos (cada módulo (aplicación) tiene su propio sitio web). Pero algunos usuarios, no todos, pueden utilizar cada módulo. Explica por qué defino UserApplication.
rol del rol en este proceso de inicio de sesión
Ninguno. Simplemente le da un rol a una UserApplication. Puedo utilizar el módulo financiero, que define los siguientes roles: Gerente, Cliente y Otros, donde puedo desempeñar el rol 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 se parece a
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, Moderador y Miembro son solo roles definido por su sitio web. Nada más.
Un buen recurso sobre UML y ORM es el libro Persistencia de Java con Hibernate.
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 su caso de uso, dibuja su SSD así.
y el diagrama de interacción del SSD mencionado anteriormente como este. Supuse que usa el ORM (como Hibernate, LinqToSql, EntityFramework … por lo que no necesita un patrón de fachada al acceder a sus datos).
y amigo, no decides a otros usuarios de un caso de uso. Entonces Larman dice que agrupe 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. Simplemente lea el libro de Larman y mire estas presentaciones http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm
si asigna responsabilidad a las clases, la implementación será tan fácil. tal vez no te guste leer, pero a veces deberíamos leer algunos libros. El libro de Larmans es uno de los libros favoritos de los ingenieros de software. Muchas universidades utilizan este libro en Análisis y diseño orientados a objetos.
Te aconsejé que uses el patrón Grasp Design para hacer un buen diseño. De acuerdo con esta disciplina, primero debes pensar quién es el responsable de realizar esta operación, qué clase es responsable o qué método. En resumen, también verá que la raíz del patrón Gof es Grasp. en su diseño, lo siento, lamento decir que su caso de uso no está bien definido y este diagrama de clases debería ser su modelo de dominio porque refleja conceptos en su caso de uso. Me opongo a hacer un diagrama de clases antes de hacer un diagrama de interacción y secuencia del sistema sobre el llamado caso de uso. en su modelo de dominio Miembro regular, web master y moderador es un usuario y podemos decir uso cuenta de usuario. por cierto, no hagas herencia mientras no debas, porque aumenta el acoplamiento de tu clase, por lo que no puedes hacer una refactorización fácil. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
Sección de Reseñas y Valoraciones
Eres capaz de asentar nuestra investigación ejecutando un comentario o valorándolo te estamos eternamente agradecidos.