SOFTWARE PARA PAGOS DE SUELDOS Patrones de Diseño

1. SOFTWARE PARA PAGOS DE SUELDOSPatrones de Diseño Integrantes: José Luis Rocha V. Claudia Martínez S. Ricardo Ferré M.

2. SOFTWARE PARA PAGOS DE SUELDOS • Justificación del proyecto • EL problema que tiene la empresa Café Amboró referente al pago de sueldos es la inconsistencia de información puesto que la realización de su planilla la hace a través de una hoja de Excel, lo que hace que el almacenamiento de la información no sea confiable. Para lo cual el desarrollo de este software pretende dar solución a los problemas de la empresa, tratando de cumplir con todos sus requerimientos.

3. Propósito de los patrones • Fundamentos de diseño. • Clasificación de Patrones • Creación. • Factory Method • Singleton • Abstract Factory • Estructurales • Adapter • Facade • Composite • Comportamiento • Command • State • Observer

4. Propósito de los patrones • ¿Qué es un patrón de diseño? • ¿Por qué usarlos? • Categorización • Problema - Patrón

5. ¿Qué es un patrón de diseño? • Ante un problema reiterado ofrece una solución contrastada que lo resuelve. • Describe el problema en forma sencilla. • Describe el contexto en que ocurre. • Describe los pasos a seguir.

6. ¿Por qué usarlos? • Mejora en la comunicación y documentación • Facilita la documentación interna del proyecto. • Mejora la ingeniería de software. • Eleva el nivel del grupo de desarrollo. • Previene “reinventar la rueda” en diseño • Son soluciones ya probadas. • Mejora la calidad y estructura • “¿Cuan grande debe ser una clase?”

7. Categorización • Fundamentales • Se usan en otros patrones mas grandes • Creación • Problemas del proceso de creación de un objeto. • Estructura • Problemas relativos a la composición de objetos • Comportamiento • Relativo a la interacción entre objetos

8. Problema – Patrón • Alto acoplamiento • Façade • Mediator • Observer • Imposibilidad de cambiar la clases convenientemente • Adapter • Decorator • Visitor

9. Patrones de creación • Propósito: • Crear un objeto es una toma de decisión. • Separar los procesos de creación de objeto y de uso de un objeto. • Cuales veremos? • Singleton

10. Singleton • Problema: • No se puede tener mas de una instancia de una clase. • Se necesita controlar el acceso a una clase.

11. Singleton • Hago que la clase no pueda ser heredada. • Agrego una variable estática del mismo tipo de la clase donde esta contenida. (instancia) • Agrego un método estático que retorne la variable estática. (GetInstance) • Agrego el código necesario para no crear dos instancias en distintos thread.

12. Usuario Id_usuario Id_emple Nom_usua login asignarContraseña( ) ingresar( ) Ejemplo de proyecto • Patrón Singleton • Problema: Control de Acceso de Usuarios • Patrón: Singleton (Patrón de creación) • Solución: Controla el acceso a una clase, no se puede tener mas de una instancia de una clase. Agrega una variable estática del mismo tipo de clase donde esta contenida

13. Patrones de estructura Propósito: • Desacoplar el sistema. • Obtener una estructura flexible. • Organizar. • Cuales veremos? • Facade

14. Facade • Problemas: • El cliente hace muchos viajes al servidor. • Separe por capas, pero tengo muchas clases públicas en el servidor para que puedan ser creadas desde el cliente. • Necesito estructurar las llamadas desde el cliente.

15. Facade Form Cliente Cliente Form Pedidos Form Ctas Corrientes Presentación Lógica

16. Ejemplo de Proyecto • Patrón Business Facade • Problema: Obtención de datos para generar planilla de sueldos • Patrón: Business Facade(Patrón de estructura) • Solución: Tiene la característica de “hablarse” con los diferentes componentes de las capas de esta arquitectura.

17. BF_Planilla RegistroDescuento( ) RegistroIngresos( ) RegistroPrestamo( ) CalcularSalario( ) Descuento RegistroDescuento( ) obtiene Ingresos RegistroIngresos( ) obtiene obtiene Prestamo RegistroPrestamo( ) Ejemplo de proyecto • Patrón Business Facade

18. Patrones de Comportamiento Propósito: • Asignación de responsabilidad = Distribuir el comportamiento. • Comunicación entre instancias. • Se usa mas la composición que la herencia. • Cuales veremos? • Observer • Data Access Object

19. Observer • Intención: Denir una dependencia entre un objeto y un conjunto de ellos, de modo que los cambios en el primero se vean reflejados en los otros. • Problema: • Mantener distintos objetos relacionados, generalmente son relaciones 1 – N. • Mantener las dependencias entre objetos, sin necesidad de conocer al otro objeto.

20. Ejemplo de Proyecto • Patrón Observer • Problema: Modificación de la Gestión • Patrón: Observer(Patrón de comportamiento) • Solución: Este patrón utiliza un objeto que cuando este cambia todos los objetos que los observan cambian en consecuencia.

21. Anticipo Prestamos Gestión Ingresos Descuentos Aguinaldo Notifica modificación Responde a Notificación Ejemplo de Proyecto • Patrón Observer

22. Patrón Data Access Object • Patrón Data Access Object • Problema: Seguridad en la obtención de información de la base de datos • Patrón: Data Access Object (Patrón de comportamiento) • Solución: Propone la utilización de un objeto de acceso a datos para abstraer y encapsular todos los accesos a fuentes de datos. El DAO maneja y controla la conexión con la fuente de datos para obtener y guardar información solicitada.

23. DataAccess Object Planilla BDSueldos Repositorio Encapsular Uses Muestra Ejemplo de Proyecto • Patrón Data Access Object