Tabla de contenido . Introducción Introducció n
1.1
Atributos de de Calidad
1.2
Atributos Atribut os de Calidad
1.2.1
Funcionalidad Funcio nalidad
1.2.2
Fiabilidad
1.2.3
Usabilidad Usabil idad
1.2.4
Eficiencia Eficien cia
1.2.5
Mantenibilidad
1.2.6
Portabilidad Portab ilidad
1.2.7
Patrones de diseño
1.3
Singleton Single ton
1.3.1
Facade Facad e
1.3.2
Observer
1.3.3
Str ategy ategy
1.3.4
Decorator
1.3.5
Experto en información
1.3.6
Creador
1.3.7
Controlador
1.3.8
Bajo acoplamiento
1.3.9
Alta Cohesión
1.3.10
Fabricación Pura
1.3.11
Polimorfismo
1.3.12
Indirección
1.3.13
Variaciones protegidas
1.3.14
Bibliografía
1.4
. 2
Tabla de contenido . Introducción Introducció n
1.1
Atributos de de Calidad
1.2
Atributos Atribut os de Calidad
1.2.1
Funcionalidad Funcio nalidad
1.2.2
Fiabilidad
1.2.3
Usabilidad Usabil idad
1.2.4
Eficiencia Eficien cia
1.2.5
Mantenibilidad
1.2.6
Portabilidad Portab ilidad
1.2.7
Patrones de diseño
1.3
Singleton Single ton
1.3.1
Facade Facad e
1.3.2
Observer
1.3.3
Str ategy ategy
1.3.4
Decorator
1.3.5
Experto en información
1.3.6
Creador
1.3.7
Controlador
1.3.8
Bajo acoplamiento
1.3.9
Alta Cohesión
1.3.10
Fabricación Pura
1.3.11
Polimorfismo
1.3.12
Indirección
1.3.13
Variaciones protegidas
1.3.14
Bibliografía
1.4
. 2
3
Introducción
INTRODUCCIÓN Atributos de calidad y patrones de diseño El presente documento pretende ser una guía para dar a conocer los conceptos básicos de atributos de calidad como la funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad y de algunos de los mas importantes patrones de diseño a tratarse en el curso de arquitectura de software. Trabajo realizado por los estudiantes:
Mauricio Alberto Pinzón Hernandez - Cristian CamiloPaz Eraso Gloria Riascos Delgado - Diana Rivadeneira Richard Alexander Vallejo Guerra - Eyder Ascuntar Rosales Jorge Rivera Rosero - Felipe Roa Narvaez Jhon Alexander Cardenas Campaña - Ray Johnathan Barcenas T. Albeiro N. Chamorro - Wilmer L. Mora Paz Cristian David Villota - Dario José Martinez Rodriguez marzo, 2017
4
Atributos de Calidad
5
Atributos de Calidad
Mauricio Alberto Pinzón Hernandez - Cristian CamiloPaz Eraso
ISO 9126 La norma ISO/IEC 9126 establece un modelo de calidad con un objetivo en general, lo que esta busca en si es describir características de calidad con ayuda de ejemplos para el buen entendimiento de los problemas que necesitan de una solución software. esta norma nació en el año 1992 y es muy usada para hacer una evaluación de calidad del software.
ISO 25000 Esta norma esta conformada por ISO/IEC 9126 (Software Product Quality) mencionada anteriormente y ISO/IEC 14598 (Software Product Evaluation). La norma ISO 25000-1, es una de las normativas ISO mas nuevas que relacionan al desarrollo de software de calidad. en esta normativa también se trata la calidad del proceso de desarrollo del software, esto debe ir en conjunto para que cualquier empresa y/o organización que tenga como objetivo llegar a tener estándares de calidad óptimos para el desarrollo de sus aplicativos software, a esta normativa se la ha denominado requisitos y evaluación de calidad de productos software.
Divisiones que conforman la norma ISO 25000 1. ISO/IEC 2500n División de la gestión de calidad: Aquí se trata de definir los modelos, terminología y los demas aspectos que son comunes para las otras normas que nacen a partir de la ISO 25000. esta división se encuentra formada por Guide to SQuaRE, que es una arquitectura basada en partes asociadas y ISO/IEC 250001 Planning and Management que es donde se maneja la parte de rquisitos software. 2. ISO/IEC 2501n División de modelo de calidad: En esta división trata la calidad interna y externa del software, esta división esta formada por ISO/IEC 25010 System and software quality models que hace la descripción del modelo de calidad del producto software y para el uso del mismo y ISO/IEC 25012 Data Quality model que es donde se define de forma general un modelo para la evaluación de los datos del sistema de información. 3. ISO/IEC 2502n División de medición de calidad: En esta división se trabaja la medición de calidad del producto en cuanto a interna,externa y en uso, ademas de eso se incluyen guías prácticas para su aplicación. esta división esta formada por ISO/IEC 25020 Measurement reference model and guide donde se muestra una explicación base y un modelo de referencia para la medición de calidad, ISO/IEC 25021 Quality measure elements que define una variedad de métricas base y derivadas las cuales son recomendadas para ser usadas durante el ciclo de vida del desarrollo software, ISO/IEC 25022 Measurement of quality la cual define las métricas para hacer las 6
Atributos de Calidad respectivas mediciones de calidad al momento de usar el producto, ISO/IEC 25023 Measurement of system and software product quality la cual define las métricas especificas para la respectiva medición de calidad de productos software, ISO/IEC 25024 Measurement of data quality la cual define las métricas para la medición de la calidad de los datos. 4. ISO/IEC 2503n División de Requisitos de Calidad: las normas de este apartado ayudan a especificar requisitos de calidad para el producto software esta se compone de ISO/IEC 25030 - Quality requirements que da recomendaciones para realizar la especificación de requisitos software. 5. ISO/IEC 2504n – División de Evaluación de Calidad: en este ultimo item se dan recomendaciones y las guías para llevar un buen proceso de evaluación del producto software a esta se relaciona las siguientes ISO/IEC 25040 - Evaluation reference model and guide aquí se consideran las entradas para el proceso de evaluación, ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent evaluators esta provee de recomendaciones para la implementación práctica de la evaluación del producto software como tal, ISO/IEC 25042 - Evaluation modules da a conocer lo que la norma considera que es el modulo de evaluación y documentación, ISO/IEC 25045 - Evaluation module for recoverability define el modulo para hacer la respectiva evaluación de una subcaracterística de recuperabilidad.
7
Funcionalidad
Author: Gloria Riascos Delgado - Diana Rivadeneira
FUNCIONALIDAD
Fuente: Guía Técnica para la evaluación del software. De acuerdo a la ISO/IEC 9126. La Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas. Ej. lo que hace el software para satisfacer las necesidades sin tener en cuenta de cómo lo hace y cuando. La funcionalidad se divide en 5 criterios:
Idoniedad: Habilidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario. Exactitud o Precisión: Habilidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada. Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos. Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados
8
Funcionalidad
Se puede caracterizar de la siguiente manera: No Repudio:
elementos de afirmación a que quienes hicieron algo no puedan
negarlo. Confidencialidad: Protección de datos o servicios de accesos no autorizados Integridad: Se ofrecen datos y servicios como fue acordado. Disponibilidad: Medio en el cual el sistema está disponible para su aplicac ión. Auditoria: Seguimiento de
tareas realizadas
(Ingeniería de Software II, s.f.)
Conformidad de la funcionalidad: La capacidad del software de cumplir los estándares referentes a la funcionalidad. (Largo Garcia & Marin Mazo, 2005)
TACTICAS DE SEGURIDAD: Las tácticas existentes para mejorar a seguridad de la arquitectura propuesta se pueden dividir en tres tipos diferentes:
Resistencia al ataque Se dedican a intentar impedir que un elemento no autorizado pueda entrar en el sistema. Las tácticas pertenecientes a este tipo son las siguientes: Autenticación de usuario: Asegura que un usuario es quien dice ser. un ejemplo de
esto son las contraseñas, firmas digitales, DNI electrónico... Autorización de usuario: Derechos de acceso y modificación de un usuario
autenticado. Para ello existen patrones de acceso. Confidencialidad de datos: Protección de accesos no autorizados. La criptografía es
una herramienta muy utilizada ya que cifrar datos es muy útil para acceder a ellos sólo por personal autorizado y con restricciones.
Mantenimiento de la integridad: Los datos no deben ser modificados y se deben poder recuperar cuando se quiera por parte del propietario. Limitación de recursos disponibles: Así se evita que un ataque pueda tener acceso a todo el sistema.
9
Funcionalidad Limitación de acceso: Los corta fuegos realizan esta operación. Se limita el acceso a
ciertos recursos. Hay mensajes que es posible limitarlos.
Detección de ataques Se basa en el estudio y comparación de patrones de tráfico por las líneas de comunicaciones. Así se puede reconocer si se está produciendo un ataque o no, y si es así, poder combatirlo. Los patrones están basados en ataques ya conocidos. Se filtran todos los paquetes de comunicaciones que llegan al sistema y se estudian los flags, direcciones del remitente y estinatario junto con el número de puerto. Cuando se detecta un ataque se actúa y se reporta al analista para que éste adopte las medidas necesarias si fuese requerido.
Recuperación tras un ataque Básicamente se centra en devolver al sistema al estado anterior de sufrir el ataque. Recuperar el estado correcto del sistema: Relacionado con las tácticas aplicables a
la disponibilidad. Referido al buen funcionamiento del sistema después de un estado inconsistente, que lo más seguro es que no diese correctamente un servicio, que no estuviera disponible. Identificar el atacante: Realizado gracias a un registro de auditoría que consiste en
grabar una copia de cada transacción realizada en el sistema y por quién. Esto debe permitir devolver al sistema a un estado consistente, identificando al atacante.
Gráfica Resumen de Tácticas de Seguridad
Fuente: (eTutorials.org, 2008-2017)
10
Funcionalidad Resistir a los ataques:
Autenticar a los usuarios. La autenticación es asegurar que un usuario o un equipo remoto es realmente quien dice ser. Contraseñas, contraseñas de una sola vez, certificados digitales, y las identificaciones biométricas proporcionan autenticación. Autorizar a los usuarios. La autorización es garantizar que un usuario autenticado tiene los derechos para acceder y modificar datos o servicios. Esto es generalmente administrado ofreciendo algunas pautas de control de acceso dentro de un sistema. Control de acceso puede ser por usuario o por clase de usuario. Clases de usuarios pueden ser definidos por grupos de usuarios, por los roles de usuario, o por listas de las personas. Mantener la confidencialidad de los datos. Los datos deben estar protegidos contra el acceso no autorizado. La confidencialidad se logra generalmente mediante la aplicación de algún tipo de encriptación de datos y enlaces de comunicación. El cifrado es la única protección para pasar datos a través de enlaces de comunicación de acceso público. El enlace puede ser implementado por una red privada virtual (VPN) o por una capa de sockets seguros (SSL) para un enlace basado en la Web. Cifrado puede ser simétrico (ambas partes utilizan la misma clave) o asimétrico (claves públicas y privadas). Mantener la integridad. Los datos deben ser entregados según lo previsto. Puede tener información redundante codificada en ella, como sumas o los resultados de hash, que pueden ser encriptados con o independientemente de los datos originales. Límite de exposición. Los ataques suelen depender de la explotación de una sola debilidad para atacar a todos los datos y servicios en un host. El arquitecto puede diseñar la asignación de servicios a los servidores para que los servicios disponibles estén limitados en cada host. Limitar el acceso. Los firewalls restringen el acceso basado en la fuente del mensaje o puerto de destino. Los mensajes de fuentes desconocidas puede ser una forma de ataque pero no se pueden limitar siempre. Un sitio web público, por ejemplo, puede obtener las solicitudes desde fuentes desconocidas. Una configuración que se utilizan en este caso es la llamada zona desmilitarizada (DMZ) cuando se debe proporcionar acceso a los servicios de Internet, pero no a una red privada. Se encuentra entre Internet y un firewall delante de la red interna. La DMZ contiene dispositivos de espera para recibir mensajes de fuentes arbitrarias tales como servicios Web, correo electrónico y los servicios de nombres de dominio (DNS).
11
Funcionalidad
12
Fiabilidad
Author: Richard Alexander Vallejo Guerra - Eyder Ascuntar Rosales FIABLIDAD Es la Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez en las siguientes :
Madurez: Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones normales. Disponibilidad: Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere. Tolerancia a Fallas: Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software. Recuperabilidad: Capacidad del producto software para recuperar los datos directamente afectados y reestablecer el estado deseado del sistema en caso de interrupción o fallo.
TACTICAS:
Fuente: http://www.ece.ubc.ca/~matei/EECE417/BASS/ch05lev1sec2.html
13
Fiabilidad
14
Usabilidad Todos los software que construimos en el natural desarrollo de nuestras actividades de construcción de software tienen como finalidad satisfacer las necesidades que el cliente plantea en la recolección de los requerimientos. En muchas ocasiones desarrollamos software que cumple perfectamente con la funcionalidad para la cual fue construido pero la complejidad para que el usuario pueda utilizarlo y solventar su necesidad puede llevar a que el software muera en una etapa temprana de su ciclo de vida en producción. La simplicidad con que el software le permite al usuario trabajar y solventar sus necesidades a través del mismo es el parámetro de calidad de la usabilidad, la cual consiste en el software además de cubrir los requerimientos funcionales para los cuales fue creado, también sea de fácil uso para el usuario. Con las nuevas tecnologías se evidencia que el software debe ser el mejor manual de uso para si mismo, es decir que no se requiera un manual de uso externo al software puesto que este mismo guía al usuario y permite la intuitividad de su uso. La usabilidad encierra características como:
Comprensibilidad: este atributo refleja que tan fácil es para el usuario comprender el sistema, que conocimientos previos requiere el usuario para poder trabajar con el software, entre menos conocimientos requiera el usuario para enfrentarse a trabajar con el software más comprensible es; esto dado a que el software se explica por sí mismo y el usuario con una simple impresión inicial puede determinar si el software satisface o no sus necesidades. Aprendibilidad: cuando hablamos de aprendibilidad también se hace referencia a comprensibilidad, puesto que estos dos atributos están estrechamente relacionados, la aprendibilidad evidencia el esfuerzo que el usuario debe hacer para sintetizar el uso del software, es decir que el usuario puede aprender fácilmente a usar dicho sistema software. Operabilidad: una de los objetivos que el desarrollador debe tener en mente en la construcción de un software es simplificar una tarea para el usuario, es decir que para el usuario el software no solo cumpla con cubrir su necesidad sino que también le ayude a que el proceso que debe cumplir para cumplir la misma sea rápido por lo tanto para el usuario operar cada funcionalidad del sistema software sea simple, el software no debe entorpecer el trabajo del usuario. Atractividad: un usuario busca estar a gusto mientras trabaja en un software por lo tanto la presentación de este debe estar acorde con las expectativas del usuario, además el aspecto físico del software influye directamente en el desempeño del usuario en el uso de este, y puede llegar a influir también en la estabilidad de la salud
15
Usabilidad del usuario puesto que muchas personas pueden pasar una cantidad de tiempo considerable operando el sistema software, por lo tanto debe acoplarse y brindar comodidad al usuario.
(Calero Muñoz, Piattini Velthuis, & María Ángeles , 2010) (Durango, 2015 )
16
Eficiencia
Author: Jhon Alexander Cardenas Campaña - Ray Johnathan Barcenas T. Comportamiento Temporal: Capacidad del software para proporcionar tiempos de proceso, respuesta y potencia apropiados, en condiciones dadas. (Beatriz Florian Garcia, 2013, p.20) Tiempo de respuesta que requiere un sistema software para responder a un evento o transacción, o bien es el número de eventos o transacciones procesadas en un intervalo de tiempo. El desempeño depende de la arquitectura si se habla de la comunicación entre los componentes y asignación de funcionalidades a los componentes, y no dependiente en cuanto a los algoritmos que implementan la funcionalidad y la codificación de estos algoritmos. Metricas: Tiempo de respuesta: es la medida de latencia que un sistema software muestra en una transacción o evento, también esta frecuentemente asociado con el tiempo que un sistema software toma en responder a una entrada. Requerimientos de tiempo de respuesta garantizado: cada una de las peticiones deben ser atendidas dentro de un límite de tiempo específico. Requerimientos de tiempo de respuesta promedio: se observa el tiempo promedio en el que el sistema software atiende un conjunto de peticiones, permitiendo la latencia más amplia para cuando el sistema esta ocupado, incluye tiempo límite para ser atendido. Rendimiento: es la cantidad de trabajo que un sistema software debe ejecutar por unidad de tiempo. lo mas común transacciones por segundo (tps) o mensajes procesados por segundo (mps). Plazos: un sistema software tiene una ventana limitada de tiempo para completar una transacción, por lo que tendrá un requerimiento de deadline de desempeño, estos requerimientos estas asociados comunmente a sistemas en lote (batch-systems). Análisis de Eficiencia: Es posible analizar la eficiencia en la arquitectura mediante el análisis de tasas de llegada, la distribución de los requerimientos de servicios, tiempos de procesamiento, tamaños de las colas y la latencia. Utilización de Recursos:
17
Eficiencia La meta de las tácticas de eficiencia es generar una respuesta a un evento que llega al sistema software dentro de una restricción de tiempo, dos aspectos a tener en cuenta el primero de ellos es el consumo de recursos que incluyen la CPU, almacenamiento de datos, ancho de banda de la red, memoria, los componentes definidos por el sistema software y el segundo el tiempo de bloqueo de los recursos. Cuando se habla de Eficiencia de un sistema Software, nos viene el siguiente cuestionamiento, y es preguntarnos como reaccionaria el sistema con 100, 1000, 10000 usuarios conectados al sistema al mismo tiempo? , sera que el sistema respondera las peticiones echas por estos usuarios? y si lo hace cuanto tiempo se demora y que recursos fueron los mas utilizados?. Para responder estas inquietudes tenemos las tacticas de eficiencia que nos orientan a como controlar la demanda de recursos y como gestionarlos.
18
Mantenibilidad
Author: Albeiro N. Chamorro - Wilmer L. Mora Paz Mantenibilidad: Este es un concepto esencial cuando hablamos de software, y que además es poco considerado en el momento de modelar un sistema de información, por lo cual es fácil encontrar sistemas a los que hacerles un cambio es algo demasiado traumático debido a la complejidad o inexistencia de documentación y/o los efectos secundarios que esto puede generar. Según el modelo de McCall, menciona dos aspectos a tener en cuenta: • Simplicidad • Concreción Estas dos palabras abarcan de una forma concreta lo que se busca en un sistema para que sea fácil de mantenerse en el tiempo. Pero estos son conceptos que son muy globales, por lo que es necesario ser un poco más específico, y esa claridad se la puede encontrar en la norma ISO 25000:2005, dicha norma contiene las siguiente definición: Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: • Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás. • Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos. • Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar. • Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño. • Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios. Extraido de: http://iso25000.com/index.php/normas-iso-25000/iso-25010/26-mantenibilidad
19
Mantenibilidad Fecha de consulta: 15/03/2017
Estrategias para garantizar la mantenibilidad:
20
Portabilidad
Author: Cristian David Villota - Dario José Martinez Rodriguez
PORTABILIDAD Uno de los primeros proyectos en utilizar la portabilidad como factor principal, fue el CP/M (Control Program for Microcomputer) surgió como un proyecto de sistema operativo de disco, para crear un entorno de desarrollo para microcomputadoras. Fue concebido en 1973, inicialmente, como un proyecto personal de Gary Kildall. Constantemente pensaba en su explotación comercial, creando la empresa Intergalactic Digital Research y justo en el año de 1975 el lanzamiento del Altair 8800, una de las primeras computadoras de la historia que, además, causó furor en los aficionados (se vendía en forma de kit para facilitar la distribución), era una computadora totalmente compatible con CP/M que dio paso a otras computadoras clónicas que utilizaban unidades de disco que requerían de un sistema operativo que pudiese gestionarlo; se extendió hasta el punto de estar presente en cualquier computadora que estuviese basada en el procesador Intel 8080 o en el Zi log Z80. CP/M. Lastimosamente la feroz competencia de Microsoft con la rápida expansión del DRDOS,en los años ochentas (80) barrio a este sistema.
Figura 1. En la actualidad, esta característica se crea en los componentes de software o hardware, en busca de eficiencia, eficacia y compatibilidad bajo cualquier entorno de trabajo, donde, según su especialidad, contendrá al menos una de las siguientes subcaracteristicas:
Adaptabilidad: Hace referencia a la capacidad que tiene el producto, de adecuarse a diferentes entornos, sin necesidad de cambiar la esencia para la cual fue desarrollado.
21
Portabilidad
Figura 2. Instalabilidad: Cualidad del software "Portable" que permite ser ejecutado bajo cualquier entorno de trabajo.
Figura 3. Coexistencia: Esta propiedad permite la ejecución de distintas rutinas u operaciones que, aun cuando comparten los mismos recursos, pueden ser ejecutadas simultáneamente, trabajando de forma segura e independiente, sin que afecte los resultados y funcionalidad del entorno.
Figura 4. Reemplazabilidad: Esta cualidad otorga al sistema libertad para emplear otras rutinas, con idénticas operaciones, sin que se la ejecucion de las nuevas operaciones afecte el entorno.
Figura 5. Bibliografia: 22
Portabilidad Figura 1: http://guiateoricadeinformatica.blogspot.com.co/ Figura 2: http://www.gotelgest.net/software-servicio-tecnico/ Figura 3: http://testeandosoftware.com/10-herramientas-para-pruebas-de-software-ii/ Figura 4: https://azure.microsoft.com/es-es/solutions/dev-test/ Figura 5: http://www.c3po.es/la-seguridad-fundamental-en-el-hardware-y-softwareempresarial/ https://hipertextual.com/archivo/2012/01/historia-del-software-cpm-bios/ Len Bass, Paul Clements y Rick Kazman, Arquitectura de Software en la Práctica, Tercera Edición, 2013. Capitulo 4: Comprensión de los atributos de calidad.
ISO 9126. Coral Calero Muñoz,Mario G. Piattini Velthuis,María Ángeles Moraga de la Rubia. Calidad del producto y proceso software. Pgns 82,187,189,264,301, 303,606, books.google.com.co
23
Patrones de diseño
PATRON OBSERVER Definición: El patrón Observer, denominado también como publicación-suscriptor, se utiliza para notificar a los objetos dependientes de él, los cambios de estado a los que tenga lugar un objeto, con el fin de que todos los objetos se actualicen automáticamente acorde a los cambios realizados. Motivación: Mantener la consistencia entre objetos relacionados, sin aumentar el acoplamiento entre clases. Ej: separación de la capa de presentación en una interfaz de usuario de los datos de aplicación subyacentes.
Figura 2: Separación de la capa de presentación en una interfaz Fuente: Patrones de diseño
Uso del Patrón Observer: Cuando una abstracción tiene dos aspectos, y uno depende del otro. Encapsular los aspectos en objetos distintos permite cambiarlos y reutilizarlos. Cuando cambiar un objeto implica cambiar otros, pero no sabemos exactamente cuántos hay que cambiar. Cuando un objeto debe ser capaz de notificar algo a otros sin hacer suposiciones sobre quiénes son dichos objetos. Esto es, cuando se quiere bajo acoplamiento.
Participantes 24
Patrones de diseño Subject: Conoce a sus observadores, que pueden ser un número arbitrario proporciona una interfaz para añadiry quitar objetos observadores. Observer: Define la interfaz de los objetos a los que se deben notificar cambios en un sujeto ConcreteSubject: Almacena el estado de interés para sus observadores envía notificaciones a sus observadores cuando su estado cambia. ConcreteSubject: Almacena el estado de interés para sus observadores envía notificaciones a sus observadores cuando su estado cambia ConcreteObserver: Mantiene una referencia a un ConcreteSubject almacena el estado del sujeto que le resulta de interés implementa la interfaz de Observer para mantener su estado consistente con el del sujeto.
Figura Diagrama de clases patron observer Fuente: Patrones de diseño.
Consecuencias • Permite modificar sujetos y observadores de manera independiente • Permite reutilizar un sujeto sin reutilizar sus observadores, y viceversa 25
Patrones de diseño • Permite añadir observadores sin tenerque cambiar el sujeto ni los demás observadores • Acoplamiento abstracto entre el sujeto y el observador. El sujeto no sabe la clase concreta de sus observadores (acoplamiento mínimo). • Soporte para broadcast. El sujeto envía la notificación a todos los observadores suscritos. Se pueden añadir/quitar observadores. • Actualizaciones inesperadas. Una operación en el sujeto puede desencadenar una cascada de cambios en sus observadores. El protocolo no ofrece detalles sobre lo que ha cambiado. (Sánchez, 2008).
Actores en la implementación del Patrón Objetos observables: Estos objetos implementan mecanismos para poder añadir y eliminar objetos observadores. Se establece las condiciones a través de la interfaz IObservable la cual posee un método “void notificar();” el cual avisa a los observadores sobre el cambio de estado. Figura 4: Objetos Observables Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/
Objetos observadores: Son objetos que implementan la interfaz IObserver los cuales poseen métodos que corresponden al cambio de estado. EJEMPLO
26
Patrones de diseño
Figura : Ejemplo Practico Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Vamos a suponer un ejemplo de una clase Tiempo(horas,minutos y segundos), tendrá un método de la interfaz IObservable para añadir y eliminar observadores.
27
Patrones de diseño
Figura : Interfaz IObservable para añadir y eliminar Observadores Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Se muestra un método toString() para convertir el objeto tiempo en cadena. Un método privado notificar(); para informar a los observadores sobre los cambios de estado, además un método Start() que inicie la ejecución del hilo con el bucle infinito.
Figura : Método ToString(); Método notificar(); Método Start();
28
Patrones de diseño Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ El hilo utiliza la interfaz Runnable para informar cada segundo sobre el cambio de estado a los IObserver. atreves de el método notificar()
Figura 9: Cambios de estado a los IObserver Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Al finalizar mostramos los Observadores, para mostrar la hora cada segundo por consola:
29
Patrones de diseño
Figura : Muestra de Observadores Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Figura 11: Presentación grafica del patrón Observer Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ En el método Main() muestra como los observadores son notificados cada segundo de los cambios de estado en el objeto Tiempo Observa Figura 12: Método Main() Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ (Hernandez, 2013)|
30
Singleton
Author: Mauricio Alberto Pinzón Hernandez - Cristian CamiloPaz Eraso
Singleton El patrón de diseño singleton se asegura de que una clase solo tenga una instancia y proporciona un punto de acceso global a ella. las variables singleton son parecidas a las variables globales con la diferencia de que las singleton son administradas por un metodo de la clase y así también se puede crear solo cuando sea necesaria. El objetivo de este patrón es conseguir instanciar una clase una sola vez, dando asi un unico punto de acceso a ella. esto suele ser de importancia en algunas clases, un ejemplo podria ser cuando se va hacer uso de una impresora, pues muchos aplicativos tienen acceso a ella como word, excel adobe pdf etc, pero esta solo puede ser usada por un aplicativo a la vez. Si queremos controlar a dicha clase para que solo pueda tener una instancia, la solución tendra que estar en la misma clase, esta debe proveer de herramientas para hacer dicho control
Como se utiliza: 1. Este patrón se debe utilizar cuando surja la necesidad de instanciar un objeto a partir de una clase, y ademas esta solo debera ser accesible a los usuarios por un unico punto de acceso. 2. Esta instancia debe poderse extender por las subclases y los usuarios podran tener la facilidad de utilizar una instancia extendida, dejando de lado la modificación del codigo.
Caracteristicas: 1. Instancia de la clase controlada, ya que la misma clase se encarga de hacer una instancia de si misma. 2. Esta evita el uso de variables globales que almacenan instancias unicas. 3. Esta clase puede ser extendida por medio de subclases.
Implementación en java: public class Ejemplomp {
31
Singleton
private static Ejemplomp mp = new Ejemplomp(); private Ejemplomp(){ } public static Ejemplomp getSigmp(){ return mp; }
}
32
Facade
Author: Mauricio Alberto Pinzón Hernandez - Cristian CamiloPaz Eraso El patrón de diseño Facade o fachada nos permite Poder definir una interfaz que de una manera simple, sencilla que nos permite interactuar con una interfaz más compleja. Así de esta forma el cliente solo se conectara con la interfaz sencilla mientras, mientras que la interfaz sencilla se conecta con otras interfaces más complejas. Lo que se hace con el facade es encapsular toda la complejidad para que la nueva clase permita interactuar con el subsistema con el que se desea interactuar.
Se debe utilizar cuando: • Se quiere proporcionar una interfaz sencilla a un subsistema complejo. • Se quiere desacoplar un subsistema del cliente o de otro subsistema haciéndolo más independiente. • Se quiere dividir los sistemas en niveles haciendo la fachada como el punto de entrada de cada nivel.
33
Observer
Author: Gloria Riascos Delgado - Diana Rivadeneira
PATRON OBSERVER Definición: Este patrón define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el Observador se encarga de notificar este cambio a resto de los objetos dependientes. El objetivo de este patrón es desacoplar la clase de los objetos clientes del objeto, aumentando la modularidad del lenguaje, así como evitar bucles de actualización. Motivación: Mantener la consistencia entre objetos relacionados, sin aumentar el acoplamiento entre clases. Ej: separación de la capa de presentación en una interfaz de usuario de los datos de aplicación subyacentes.
Figura 2: Separación de la capa de presentación en una interfaz Fuente: Patrones de diseño
Uso del Patrón Observer: Cuando una abstracción tiene dos aspectos, y uno depende del otro. Encapsular los aspectos en objetos distintos permite cambiarlos y reutilizarlos. Cuando cambiar un objeto implica cambiar otros, pero no sabemos exactamente cuántos hay que cambiar. Cuando un objeto debe ser capaz de notificar algo a otros sin hacer suposiciones sobre quiénes son dichos objetos. Esto es, cuando se quiere bajo acoplamiento.
34
Observer
Participantes Observador: Define la interfaz de los objetos a los que hay que notificar cambios del Sujeto. ObservadorConcreto: Mantiene una relación con un SujetoConcreto. Mantiene el estado del SujetoConcreto que le es de interes. Implementa Observador para mantener su estado coherente con el del Sujeto. Sujeto: Conoce a sus observadores. Tiene una interfaz para ir añadiendo y eliminando observadores. SujetoConcreto: Envía notificaciones a sus observadores cuando su estado cambia.
Figura: Diagrama de la Clase Observador Fuente: Patrones de diseño.
Consecuencias • Permite modificar sujetos y observadores de manera independiente • Permite reutilizar un sujeto sin reutilizar sus observadores, y viceversa
35
Observer • Permite añadir observadores sin tenerque cambiar el sujeto ni los demás observadores • Acoplamiento abstracto entre el sujeto y el observador. El sujeto no sabe la clase concreta de sus observadores (acoplamiento mínimo). • Soporte para broadcast. El sujeto envía la notificación a todos los observadores suscritos. Se pueden añadir/quitar observadores. • Actualizaciones inesperadas. Una operación en el sujeto puede desencadenar una cascada de cambios en sus observadores. El protocolo no ofrece detalles sobre lo que ha cambiado. (Sánchez, 2008).
EJEMPLO
Figura : Ejemplo Practico Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Vamos a suponer un ejemplo de una clase Tiempo(horas,minutos y segundos), tendrá un método de la interfaz IObservable para añadir y eliminar observadores. 36
Observer
Figura : Interfaz IObservable para añadir y eliminar Observadores Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ Se muestra un método toString() para convertir el objeto tiempo en cadena. Un método privado notificar(); para informar a los observadores sobre los cambios de estado, además un método Start() que inicie la ejecución del hilo con el bucle infinito.
37
Observer
Figura : Método ToString(); Método notificar(); Método Start(); Fuente: https://www.seas.es/blog/informatica/patrones-de-diseno-en-java-patron-observer/ El hilo utiliza la interfaz Runnable para informar cada segundo sobre el cambio de estado a los IObserver. atreves de el método notificar()
38
Observer
Figura : Cambios de estado a los IObserver Fuente: https://www https://www.seas.es/blog/informatica/pa .seas.es/blog/informatica/patrones-de-diseno-en trones-de-diseno-en-java-patron-observer/ -java-patron-observer/ Al finalizar mostramos los Observadores, Observadores, para mostrar la hora cada cada segundo por consola: consola:
39
Observer
Figura : Muestra de Observadores Fuente: https://www https://www.seas.es/blog/informatica/pa .seas.es/blog/informatica/patrones-de-diseno-en trones-de-diseno-en-java-patron-observer/ -java-patron-observer/ (Hernandez, 2013)|
40
Strategy
Author: Gloria Riascos Delgado - Diana Rivadeneira
PATRON STRATEGY Este patrón provee la implementación de diferentes estrategias o comportamientos concretos en clases hijas a través de una clase común. Su propósito propósito es definir una familia de algoritmos, encapsular cada uno de ellos e llos y hacerlos intercambiables. Permite la variación de un algoritmo, independienteme i ndependientemente nte de los clientes que lo usen.
Figura : Patrón Strategy Fuente: http://joaquin.medina.name/web2008/documen http://joaquin.medina.name /web2008/documentos/informatica/documenta tos/informatica/documentacion/logica/patrone cion/logica/patrone s/patronStrategy/PatronEstrategia01.jpg
Aplicabilidad • Muchas clases relacionadas difieren solo en su comportamiento. Las estrategias permiten configurar una clase con un determinado comportamiento entre muchos posibles. • Se necesitan distintas variantes de un algoritmo. • Un algoritmo usa datos que los clientes no deberían conocer. Se usa para evitar exponer estructuras de datos complejas y dependientes del algoritmo.
41
Strategy • Una clase define muchos comportamientos y estos se representan como múltiples sentencias condicionales en sus operaciones. En vez de tener muchos condicionales, podemos mover las ramas de estos a sus propias clases estrategia. Componentes de este patrón: • Interfaz Strategy: es la interfaz que define el nombre del método o métodos que conformarán la estrategia. • Clases Strategy concretas: todas aquellas clases que implementen la interfaz Strategy dando forma al algoritmo. • Contexto: elemento donde se desarrollará la estrategia.
Consecuencias • Familias de algoritmos relacionados: Las jerarquías de clases Estrategia definen una familia de algoritmos o comportamientos. • Una alternativa a la herencia: La herencia ofrece otra forma de permitir una variedad de algoritmos o comportamientos. Se puede heredar directamente de una clase contexto para proporcionar diferentes comportamientos. Pero esto liga el comportamiento al Contexto, mezclando la implementación del algoritmo con la del Contexto, lo que hace que éste sea más difícil de comprender, mantener y extender. Y no se puede modificar el algoritmo dinámicamente. Acabaremos teniendo muchas clases relacionadas cuya única diferencia es el algoritmo o comportamiento que utilizan. Encapsular el algoritmo en clases Estrategia separadas nos permite variar el algoritmo independientemente de su contexto, haciéndolo más fácil de cambiar, comprender y extender. • Las estrategias eliminan las sentencias condicionales: El patrón estrategia ofrece una alternativa a las sentencias condicionales para seleccionar el comportamiento deseado. Cuando se juntan muchos comportamientos en una clase es difícil no usar sentencias condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases estrategias separadas elimina estas sentencias condicionales, delegando la tarea en el objeto estrategia. • Los clientes deben conocer las diferentes estrategias: el patrón tiene el inconveniente potencial de que un cliente debe comprender como difieren las Estrategias antes de seleccionar la adecuada. Los clientes pueden estar expuestos a cuestiones de i implementación. Por lo tanto, el patrón estrategia debería usarse solo cuando la variación del comportamiento sea relevante a los clientes.
42
Strategy • Costes de comunicación entre Estrategia y Contexto: La interfaz de Estrategia es compartida por todas las clases Estrategia Concreta, ya sea el algoritmo que implementa trivial o completamente. Por lo tanto, es probable que algunos objetos Estrategia Completa no usen toda la información que reciben a través de dicha interfaz; las estrategias concretas simples pueden incluso no utilizar nada de dicha información. Esto significa que habrá veces en las que el contexto crea e inicializa parámetros que nunca e utilizan. Si esto puede ser un problema, necesitaremos un acoplamiento más fuerte entre Estrategia y Contexto. • Mayor número de objetos: Las estrategias aumentan el número de objetos de una aplicación. A veces se puede reducir este coste implementando estrategias como objetos sin estado que puedes ser compartida por el contexto. El contexto mantiene cualquier estado residual, pasándolo en cada petición de al objeto estrategia. Las estrategias compartidas no deberían mantener el estado entre invocaciones. (Serrano, 2013)
IMPLEMENTACION
Figura : Patrones de diseño patrón de estrategia Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html Vamos a crear una interfaz de Estrategia la cual define una acción. Paso 1:
43
Strategy
Figura : Strategy.java Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html Paso 2: Definimos clases concretas que se heredan de la Estrategia de interfaz para realizar las operaciones de suma, resta, multiplicación.
OperationAdd.java
Figura : OperationAdd.java Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html
OperationSubstract.java
Figura 17: OperationSubstract.java Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html
44
Strategy
OperationMultiply.java
Figura : OperationMultiply.java Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html Paso 3: Creamos una clase de contexto que es una clase una clase que utiliza una estrategia.
Figura : Creación clase Contexto Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html Paso 4: Usa el contexto para ver cambio en el comportamiento cuando cambia su estrategia.
StrategyPatternDemo: muestra clase de demostración, utilizará Contexto y estrategia de objeto para demostrar el cambio de comportamiento
45
Strategy
Figura : Clase StrategyPatternDemo Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html Paso 5: Verificar la salida.
Figura : Verificar Salida Fuente: http://www.w3ii.com/es/design_pattern/strategy_pattern.html
46
Decorator
Author: Richard Alexander Vallejo Guerra - Eyder Ascuntar Rosales DECORATOR ¿Que es? El patrón Decorador (Decorator) nos brinda la posibilidad de incorporar funciones a objetos de forma dinámica. ¿Cómo es esto posible? Mediante las relaciones que hace con otras clases lo cual le permite ampliar las funciones al anexar a las ya existentes aquellas que tienen las clases con las cuales se asoció.
Fuente:http://codejavu.blogspot.com/2013/07/ejemplo-patron-de-diseno-decorator.html
47
Experto en información
Author: Richard Alexander Vallejo Guerra - Eyder Ascuntar Rosales EXPERTO EN INFORMACION Este patrón forma parte del grupo de patrones generales de software denominados GRASP (Patrones Generales de Software para Asignación de Responsabilidades), los cuales son una guía para asignar de manera correcta las responsabilidades a los objetos de software. El Experto en Información propone que las responsabilidades se deben ser asignadas a los objetos que poseen la información para poder ejecutarlas, esto con el fin de preservar el encapsulamiento permitiendo tener una alta cohesión y un bajo acoplamiento lo cual es ideal en cualquier sistema de información que estemos desarrollando.
48
Creador
Author: Jorge Rivera Rosero - Felipe Roa Narvaez https://books.google.com.co/books? id=p7nD8_g77_MC&pg=PT82&dq=patron+de+d id=p7nD8_g77_MC&p g=PT82&dq=patron+de+diseño+creador&hl=es&sa= iseño+creador&hl=es&sa=X&ved=0ahUKE X&ved=0ahUKE wjyiLq-t9nSAhVpqVQKHT6QAu8Q6AEIHzAB#v=onepage&q&f=false Es normal en el desarrollo de un proyecto software utilizar una buena fracción de tiempo en el establecimiento de responsabilidades y relaciones entre las clases. Una de las responsabilidades más importantes de asignar es que clase debe crear una instancia de otra clase, es decir cuál va a ser la clase creador de otras clases. Cuando guiamos el proceso de desarrollo dándole gran importancia al establecimiento de dicha responsabilidad nos encontramos aplicando el patrón de diseño del creador, el cual tiene como consecuencia directa el establecimiento del encapsulamiento de las instancias, brindando así una de las características más importantes en un desarrollo que es el bajo acoplamiento, con el fin de que el mantenimiento del software se simplifique y todos los elementos que se construyan bajo este pratrón tengan un alto índice de reutilización. En un entorno practico se estable la aplicación del patrón del creador cuando damos solución al problema de establecer quien debe ser responsable de crear una nueva instancia de una clase, tal como lo l o se plantea en el libro "Diseño de sistemas software en UML - Ernest Teniente Teniente López, Antoni Olivé Oli vé Ramon, Enric Mayol Sarroca, Cristina Gómez Seone" para resolver este problema debemos tener en cuenta que la clase B será la creadora de la clase A si cumple una de las siguientes clausulas:
B es un agregado de objetos de A. B contiene objetos de A. guarda instancias de objetos de A. B guarda usa muchos objetos de A. B usa B tiene los datos necesarios para inicializar un objeto de A (B tiene los valores de los parámetros del constructor de A). (Teniente López, livé Ramon, & Enric M, 2004)
49
Controlador
Author: Jorge Rivera Rosero - Felipe Roa Narvaez El patrón controlador aumenta la cohesión en el sistema puesto que propone que toda la lógica de negocios este claramente definida y organizada, es decir que es el encargado de ser el intermediario entre la capa de recolección de datos o vistas y la capa de almacenamiento de los mismos por lo tanto se recomienda dividir los eventos del sistema en el mayor número de controladores esto también aporta a la reutilización de código. Siguiendo el patrón controlador también se aporta en gran medida a bajar el indice de acoplamiento debido a la marcada división que se presenta de cada uno de los procesos de lógica de negocios en la capa.
Un Controlador: Debería ser el primer objeto llamado después de un cambio en la interfaz de usuario. Controla/ejecuta un caso de uso. No hace demasiado por si solo, controla, coordina. Pertence a la capa de aplicación o a la de servicios. (Teniente López, livé Ramon, & Enric M, 2004)
50
Bajo acoplamiento .Author: Jhon Alexander Cardenas Campaña - Ray Johnathan Barcenas T. Un elemento tiene bajo acoplamiento con otros elementos estos pueden ser clases, subsistemas, sistemas, etc en la medida en que la fuerza de conexión de este elemento hacia los otros sea mínimo, esto hace que no dependa mucho de los otros elementos. “El bajo acoplamiento soporta el diseño de clases que son más independientes, lo que reduce el impacto del cambio. No se puede considerar de manera aislada a otros patrones como el Experto o el de alta Cohesión, sino que necesita incluirse como uno de los diferentes principios de diseño que influyen en una elección al asignar una responsabilidad”. (Larman, 2014, p.216). Cuando hay bajo acoplamiento en un nivel extremo es cuando no existe acoplamiento entre clases, pero esto no es deseable ya que el paradigma orientado a objetos propone un sistema de objetos conectados que se comunican mediante el paso de mensajes. El bajo acoplamiento llevado al extremo producirá un diseño pobre dando cabida a unos pocos objetos saturados con actividad compleja que hacen todo el trabajo y muchos objetos pasivos sin acoplamiento que actúan como simples repositorios de datos. Diseño A:
Diseño B:
51
Bajo acoplamiento En el Diseño A, en el que la Caja crea el Pago, añade acoplamiento entre la Caja y el Pago, mientras que en el Diseño B en el que la Venta lleva a cabo la creación del Pago, no incrementa el acoplamiento. Es preferible el Diseño B, porque mantiene el acoplamiento global mas bajo desde el punto de vista puramente del acoplamiento. El Patron Bajo Acoplamiento promueve la asignación de responsabilidades de tal manera que su localización no aumente el acoplamiento hasta un nivel en el que tengamos resultados negativos al tener un acoplamiento alto.
52
Alta Cohesión
Author: Jhon Alexander Cardenas Campaña - Ray Johnathan Barcenas T. Un elemento tiene alta cohesión, en la medida en que tiene responsabilidades altamente relacionadas y que no hace gran cantidad de trabajo, estos elementos pueden ser clases, subsitemas, etc. Una clase con baja cohesión es la que hace muchas cosas no relacionadas, esto produce problemas comunes como que son difíciles de entender, difíciles de reutilizar, difíciles de mantener, y son constantemente afectadas por los cambios. Diseño A:
Diseño B:
En el Diseño A, la asignación de responsabilidades de Hacer un Pago esta en la Caja, pero además tiene la tarea de crear un Pago, en este sentido la clase Caja se convierte en un objeto saturado y sin cohesión, ya que realiza el mayor trabajo dentro del sistema. Es deseable el Diseño B, puesto que soporta alta cohesión y también bajo acoplamiento.
53
Alta Cohesión Una clase con alta cohesión es ventajosa porque es fácil de entender y reutilizar, además debe poseer un numero pequeño de funciones o métodos con funcionalidad altamente relacionada para no realizar mucho trabajo y comparte el esfuerzo con otras clases.
54
Fabricación Pura
Author: Albeiro N. Chamorro - Wilmer L. Mora Paz Fabricación Pura: Este concepto hace referencia a clases que el diseñador planea para resolver un problema, pero que no corresponden al mismo o son simplemente son ideadas para cumplir el objetivo, debido a esto, poseen bajo acoplamiento y alta cohesión, es por esto que este patrón se conoce como fabricación pura, ya que estas clases carecen de impurezas. Por ejemplo: si se necesita resolver una fórmula química, y para ello se debe calcular la regresión lineal, se podría usar una clase estática que tenga entre sus métodos esta operación, de esta forma, la clase posee un nivel de acoplamiento muy bajo pero un alto grado de cohesión, ya que realiza la operación deseada, pero de una manera indiferente al problema en general. Por lo general se utiliza este tipo de patrón cuando se observa que es la forma más fácil o la única forma de resolver un problema. Además, las clases generadas utilizando este patrón de diseño tienen un alto grado de reutilización. Otro ejemplo un poco mas claro, es cuando se crea una clase que se encarga de trabajar con la base de datos; esta clase hace que el desarrollador se desentienda de las tareas a ejecutar en cuestiones de almacenamiento permanente, esta clase sera reutilizable, y contara con las caracteristicas de bajo acoplamiento y alta cohesion. Otro ejemplo un poco más claro, es cuando se crea una clase que se encarga de trabajar con la base de datos; esta clase hace que el desarrollador se desentienda de las tareas a ejecutar en cuestiones de almacenamiento permanente, esta clase será reutilizable, y contara con las características de bajo acoplamiento y alta cohesión.
55
Polimorfismo
Author: Albeiro N. Chamorro - Wilmer L. Mora Paz Polimorfismo: En el desarrollo de software, este concepto se relaciona a la creación de un servicio u operación con un nombre en específico y asociarlo con objetos de diferentes ti pos. De esta forma, se podría decir que este paradigma está pensado para crear clases genéricas, permitiendo así un futuro cambio en la implementación. Aunque se puede incidir en la práctica de realizar todo de forma genérica aun cuando exista una alta probabilidad de que no se produzca un cambio en el futuro. Por ejemplo, se podría tener una clase padre llamada Figura y tener como clases hijos a: Cuadrado, Triángulo, Rectángulo, entre otras figuras que puedan representar una clase. Para crear el polimorfismo, se podría crear en cada una de las clases hijos un método "obtenerArea()", esto permite que cada objeto Figura pueda enviar un mensaje utilizando el servicio obtenerArea() a cualquier ítem de su lista, con la seguridad de que (independientemente de la clase que sea) va a saber responder a dicho mensaje.
En el siguiente ejemplo, de un sistema que desea calcular los impuestos, se puede observar una interface con el método getImpuestos() y diferentes sistemas o adaptadores que se van a conectar y procesar la información a como estén programados pero al final estos sistemas saben calcular y devolver el valor de los impuestos para cada uno de los casos.
56
Polimorfismo
(Craig larman, UML y patrones, 2 Edicion, Madrid 2003, P. 306)
57
Indirección
Author: Cristian David Villota - Dario José Martinez Rodriguez Indirección Este patrón de diseño, o "buena práctica" sugiere que, se mejore el acoplamiento entre dos clases, delegando la responsabilidad de intermediación entre estas clases, a un tercer elemento, que puede ser otra clase. Como ejemplo de este patrón de diseño encontramos los pagos electrónicos, que utilizan una UI (interfaz de usuario) a través de la cual, se realiza la mediación entre el banco, el cliente y la tienda, de lo anterior se generan clases que realizan diferentes métodos de pago y establecen una conexión entre los involucrados. Problema ¿Dónde asignar responsabilidades para evitar/reducir el acoplamiento directo entre elementos y mejorar la reutilización? Solución Asigne la responsabilidad a un objeto que medie entre los elementos.
58
Variaciones protegidas
Author: Cristian David Villota - Dario José Martinez Rodriguez
Variaciones Protegidas En este patron de diseño lo importante es protegerse ante el cambio, para ello se usan técnicas que identifiquen los módulos, clases o partes del sistema que pueden ser susceptible a modificaciones durante el tiempo y sean envueltas en una i nterfaz con ayuda del polimorfismo, dejando que ésta, sea lo mas independiente posible a nuestro sistema, permitiendo que, cuando se genere una variación o un cambio, afecte en la menor medida posible, que no presente efectos colaterales y que no modifique la estructura principal del sistema. Las variaciones Protegidas hacen parte de los patrones Grasp avanzados. Para entender este concepto es necesario tener claro lo qué es el polimorfismo y la indirección; como se ha expresado anteriormente en este libro, Polimorfismo es "la propiedad que permite que una misma operación sea aplicada a varios objetos del mismo tipo"; por su parte la indirección, es "la propiedad que permite mejorar el bajo acoplamiento entre dos clases asignando la responsabilidad de la mediación entre ellos a una clase intermedia". En conclusion, el patrón de Variaciones Protegidas nos permite ir un paso adelante del cambio, para cuando el cliente o el contexto nos obligue a realizar modificaciones, sea lo menos perturbador posible, de esta manera, protegemos ciertas partes del sistema ante el cambio y le damos flexibilidad a los componenetes que lo requieran.
59
Variaciones protegidas
60
