CAP4-TEORIA EVALUACION DE CAUDALES - HIDROGRAMAS.pdf
Taller patrones de diseño
1. PATRONES DE DISEÑO
ARBEY TOVAR ÁLVAREZ
CORPORACIÓN UNIFICADA NACIONAL
FACULTAD DE INGENIERÍA SISTEMAS
INGENIERÍA DEL SOFTWARE III
BOGOTÁ
2016
2. PATRONES DE DISEÑO
ARBEY TOVAR ÁLVAREZ
TALLER
NÉSTOR ALEJANDRO PINZÓN LÓPEZ
INGENIERO Y AUDITOR DE SISTEMAS
CORPORACIÓN UNIFICADA NACIONAL
FACULTAD DE INGENIERÍA SISTEMAS
INGENIERÍA SOFTWARE III
BOGOTÁ
2016
3. INTRODUCCIÓN
El presente taller tiene como finalidad repasar un elemento fundamental en el diseño de Software
el pertinente a Patrones de Diseño, en cuanto a su concepto, los tipos de diseño, entre otros
conceptos, se complementara con unos ejemplos en relación al proyecto sistema experto de
información para el diagnóstico del estrabismo en niños de 3 a 5 años.
5. PATRONES DE DISEÑO
1. ¿Que es un Patrón de Diseño?
Cada patrón describe la esencia para un problema que ocurre una y otra vez determinada situación,
descrito por la comunicación de entre las clases y objetos, permitiendo tener muchos puntos de
vista, con un diseño diferente cada contexto en particular.
Su finalidad es guardar la experiencia en diseños de programas orientados a objetos y proporcionan
ayuda a la hora de crear objetos desde el punto de vista de proporcionar un apoyo en la toma de
decisiones, incluso cuando esta toma de decisiones sea de forma dinámica.
Gracias a ello, ayudan a estructurar y encapsular estas decisiones. Hay ocasiones en la que nos
encontraremos con que sólo existe un patrón adecuado; otras en las que varios podrán ayudarnos;
y otras en que se pueden combinar múltiples patrones convenientemente.
Un patrón de creación asociado a clases usa la herencia para variar la clase que se instancia,
mientras que un patrón de diseño software de creación asociado a objetos delegará la instanciación
a otro objeto.
2. Cuáles son los tipos de patrón de diseño
Los patrones Singleton
6. El Problema.
Se solicita generar un historial de los eventos ejecutados por 3 usuarios del sistema, estos eventos
se generan cada vez que alguno de los usuarios presiona un botón determinado de un panel de
opciones, este historial debe contener la fecha y hora de ejecución del evento, además del usuario
y opción presionada.
La Solución.
Como nos piden que se genere un historial de los eventos ejecutados por los usuarios utilizaremos
el patrón Singleton, ya que este historial es general para todos los usuarios del sistema, así
crearemos un punto global para la aplicación que permita ir almacenando cada evento generado
independientemente de quien lo ejecute.
Visto en código Java, sería algo como esto:
public class ClaseLogSingleton {
private String contenido;
/**objeto Singleton*/
private static ClaseLogSingleton miLogSingleton= new ClaseLogSingleton();
private ClaseLogSingleton(){
setContenido("Eventos de Usuarionn") ;
}
/**
* @return the miLogSingleton
*/
public static ClaseLogSingleton getMiLogSingleton() {
return miLogSingleton;
}
/**
* @return the contenido
*/
public String getContenido() {
7. return contenido;
}
/**
* @param contenido the contenido to set
*/
public void setContenido(String contenido) {
this.contenido = contenido;
}
}
Los patrones Singleton
Complementado con la lectura de las diapositivas en el proyecto en curso, lo usaríamos para
realizar una copia de la foto tomada y pueda tomar dos rutas a la vez, bien sea local o una copia
de la foto para subir al sistema.
8. 3. Crear un ejemplo de tres de los patrones de diseño
Según la experiencia de personas que trabajan en el campo, entre los patrones se pelean las
funcionalidades, pero para el caso y el ejemplo según lo visto de los que más me llamo la atención
fue el de Abstract Factory que consiste en:
Nos encontramos frente a un problema en el que debemos crear diferentes objetos, todos
pertenecientes a la misma familia, como puede ser el sistema de librerías necesarias para crear
interfaces gráficas. Visto esto podríamos decir que lo que intenta solucionar el patrón de diseño
software de creación Abstract Factory es crear diferentes familias de objetos. El patrón Abstract
Factory, por tanto, se recomienda cuando se atisba la inclusión de nuevas familias de productos en
un futuro, pero resultaría contraproducente sí que necesita añadir nuevos productos o modificar
los existentes, ya que tendría repercusión en todas las familias creadas.
9. Según esto, podemos decir que los componentes típicos del patrón Abstract Factory es la siguiente,
aplicado al proyecto del estrabismo, claro está con correcciones dentro del diseño.
Cliente: Usuario que llamara a un módulo Diagnostico y adecuado para iniciar la prueba y que a
su vez necesita crear uno de los objetos que provee dicha factoría, es decir, intentará obtener una
instancia de alguno de los productos que entren en juego (Fotografía 1= ProductoA, Fotografia 2=
ProductoB).
AbstractFactory: Definición de la interfaz que usarán las diferentes factorías. Como mínimo, debe
ofrecer un método para la obtención de cada objeto que se pueda crear. ("crearProductoA()" y
"crearProductoB()")
Concrete Factories: Aquí se representarán las diferentes familias de productos. Provee la instancia
concreta del objeto que se encarga de crear.
Abstract Product: Definirá las interfaces para la familia de Fotografias. En el diagrama son
Fotografia 1 "ProductoA" y factoría 2 "ProductoB". El cliente trabajará directamente sobre esta
interfaz, que será implementada por los diferentes módulos concretos.
Concrete Product: Se encargará de la implementación específica de los diferentes Modulos.