Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BD - Desarrollo de software con patrones de diseño

No description
by

Angel Vargas Roldan

on 22 December 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BD - Desarrollo de software con patrones de diseño

Patrones de Creación
Definición
Tienen como objetivo no sólo el reutilizar código, sino también el diseño de objetos, sistemas, modelos de análisis etc. que se sabe que funcionan; esto es, la
reutilización del conocimiento
.
Clasificación
Propósito:
qué hace el patrón
.
Creación
: creación de objetos.
Estructura
: composición de clases y objetos
Comportamiento
: interacción entre objetos.
Alcance:
clases u objetos
Clases
: relaciones estáticas entre clases
Objetos
: relaciones dinámicas entre objetos.
Consecuencias:
La clase Singleton es la única que puede acceder a una instancia de sí misma
.
Acceso controlado a la instancia única
.
Requiere cuidado en la iniciación del Singleton en aplicaciones multi-hilo.
Factory Method
Objetivo: Definir una interfaz para crear objetos, permitiendo a las subclases decidir qué clase concreta instanciar.
Usar cuando:
Una clase no pueda anticipar las clases de los objetos que debe crear.
Una clase requiere que sus subclases especifiquen los objetos que la propia clase crea.
Prototype
Facilita la creación dinámica al definir clases cuyos objetos pueden crear copias de sí mismos.
Builder
Simplifica la creación de objetos complejos, definiendo una clase cuyo propósito es construir la instancia de otra clase.
Programar para interfaces y no para implementaciones:
Patrones de diseño
Patrones
Origen de los patrones:
Arq. Cristopher Alexander, 70’sWard
Cuningham y Kent Beck 1987
Erich Gamma, Richard Helm, Ralph Johonson y Hohn Vissides (el grupo de los cuatro) 1990/1994
Qué es
un patrón?
Antipatrones
Qué son?
Forma literaria que describe una
solución comúnmente dada a un
problema que genera consecuencias negativas decididamente.
Patrones
de diseño
Guardar experiencia de diseño (OOP).
Agrupar correctamente la experiencia de diseño.
Facilitan la reutilización de diseños.
Mejorar la documentación y mantenimiento de sistemas.
Nos ayuda a lograr diseños correctos en menor tiempo.
Su objetivo
Principios de diseño
(Los patrones de diseño se basan en los siguiente principios de diseño)
- Favorece la composición de objetos frente a la
herencia de clases.
Descripción de los patrones de diseño
Notaciones gráficas:
Reutilización de diseño:
Sin bien, las notaciones gráficas son importantes y útiles, generalmente no son suficiente. Estas solo toman el producto terminado del proceso de diseño como relaciones entre clases y objetos.
Para la reutilización de diseño, se deben guardar las decisiones, alternativas y ventajas que nos llevaron a este diseño. Los ejemplos concretos son también muy importantes, porque estos nos ayudan a comprender el funcionamiento del diseño
Plantillas
de patrones
1 - Nombre del patrón
2 - Propósito
3 - También conocido como
4 - Motivación
5 - Aplicabilidad
6 - Estructura
7 - Participantes
8 - Colaboraciones
9 - Consecuencias
10 - Implementación
11 - Código de ejemplo
12 - Usos conocidos
13 - Patrones relacionados
- Determina qué es común y que es variable:
- Permite el reemplazo de lo variable mediante una
interfaz común.
Común = Estable
Una solución, probada, y
documentada a un problema
que se repite en un determinado contexto.
Los antipatrones son considerados una parte importante del conocimiento, en otras palabras, es muy importante conocer y entender las buenas soluciones y las malas soluciones.
Los diseñadores intentan evitar los antipatrones siempre que sea posible, pero para esto se debe poder reconocerlos e identificarlos lo antes posible. Los antipatrones más útiles son aquellos que no permiten rehacer un buen diseño a partir de uno malo.

Los diseñadores intentan evitar los antipatrones siempre que sea posible, pero para esto se debe poder reconocerlos e identificarlos lo antes posible.
Los antipatrones más útiles son aquellos que no permiten rehacer un buen diseño a partir de uno malo.
Gracias!
Soportan:
Extensión de aplicaciones.
Adaptación con tecnologías emergentes
Adaptación con requerimientos funcionales cambiantes
Sistemas Adaptables
Dan la visión al mas alto nivel del sistema.
Los lineamientos fundamentales para organizar de manera lógica la estructura de un sistema.
Nos definen: Las partes que conforman al sistema, las responsabilidades de cada una de esas partes y como se comunican entre si.
Están conformados por:
Reflexión (Reflection)
Microkernel
Otorga la habilidad a un sistema para inspeccionar su propia estructura interna, poder modificarla en tiempo de ejecución y por lo tanto su comportamiento
Patrones estructurales
Evitan dispersión de los componentes
Descomposición controlada de la tarea del sistema en sub-tareas cooperativas.

Adapter
Bridge
Desacoplar una abstracción de su implementación para que ambas puedan cambiar independientemente
Desacoplar una abstracción de su implementación. La Herencia liga una implementación a una abstracción dificultando la modificación, extensión y reutilización.
Composite
Patrón que permite crear una composición de objetos
Este útil patrón permite crear y manejar estructuras de objetos en forma de árbol, en las que un objeto puede contener a otro(s).
Facade
La intención de este patrón es exponer una interfaz unificada hacia un conjunto de interfaces en un subsistema
Simplificar el acceso a un conjunto de clases proporcionando una única clase que todos utilizan para comunicarse con dicho conjunto de clases.

Reducir la complejidad y minimizar dependencias.
Proxy
Controlar el acceso a un objeto, expone un sustituto o representante desde la perspectiva de otro objeto.
Patrón que habilita la comunicación entre clases con interfaces incompatibles.
Decorator
Patrón que permite crear objetos añadiéndole funcionalidad, evitando las complicaciones de la herencia.
Pros:
No se aplican modificaciones directas para mantener el SW.
Facilita la incorporación de cambios en el sistema.
Da soporte a varios tipos de cambios.
Patrones de Estructura
Capas (Layer)
Tuberías y Filtros
El patrón de tuberías y filtros es bueno para problemas donde hay una secuencia de pasos para procesar la información y la secuencia de procesamiento puede cambiar. Las tuberías conectan fuentes de datos filtros y repositorios de datos.
Pizarron (BlackBoard)
Nos ayuda a resolver problemas donde no hay una solución única para un problema, donde hay varias alternativas de solución y tenemos que elegir una de todas las soluciones planteadas.
Evitan dispersión de los componentes
Descomposición controlada de la tarea del sistema en sub-tareas cooperativas.
Layer (capas).
Tuberías y filtros (pipe and filters).
Pizarron (BlackBoard).
Descomponer los sistemas de acuerdo a:
Los servicios que ofrecen.
Las responsabilidades de los componentes que conforman al sistema.
Cuando aplicarlo:
El sistema es muy grande y tenemos que descomponerlo.
Los objetos de mas alto nivel dependen de otros de mas bajo nivel.
El sistema requiere una estructura horizontal.
Los cambios no deben propagarse por el sistema, de esta manera el cambio esta limitado a el componente alterado.
Se requieran partes reutilizables.
Estructura
Cuando Utilizarlo
Cuando el sistema a desarrollar debe procesar o transformar un flujo de datos.
Se desea que los pasos del procesamiento puedan ser configurables o re-ordenables.
Cuando se requiera que los datos sean presentados o almacenados de distintas maneras.
Cuando se necesite dividir la tarea de un sistema en varios pasos.
La entrada al sistema es provista por una fuente de datos.
Diagrama Estructura
Filtros
: Obtienen los datos, los transforman y entregan datos de salida.
Tuberías
: Transfiere datos entre filtros, dividir el flujo de datos y sincroniza filtros de salida.
como aplicarlo
Se tiene que estructurar el sistema como un conjunto de programas que trabajan cooperativamente sobre una estructura de datos comunes.
Cada programa se especializa en resolver una parte del problema global.
Todos los programas tienen que estar trabajando en conjunto para llegar a la solución.
Los programas son independientes entre si: No se llaman entre si. No hay una secuencia de activación.
Estructura
Sistemas Distribuidos
Patrón Intermediario: Broker
Define una infraestructura completa para aplicaciones distribuidas.
Facilita la interacción entre sistemas.
Cuando utilizarlo
El entorno es un sistema distribuido y posiblemente heterogéneo con componentes independientes colaborando.
El broker es responsable de coordinar la comunicación: Delega las peticiones de servicios remotos al servidor que corresponda, transmite a los usuarios los resultados de sus peticiones y las eventuales excepciones si las hay.
Estructura
Participantes
:
-
Cliente
: Envía peticiones a servidores atravez de proxy.
-
Broker:
Le hace las peticiones al servidor
-
Servidor
: Implementa los servicios y entrega respuesta a las peticiones de servicio.



Sistemas Interactivos
Soportan sistemas Orientados a la interacción con seres humanos.

Esta categoría esta conformada por:
Modelo-Vista-Controlador.
Presentación-Abstracción-Control
Modelo-Vista-Controlador
Presentación - Abstracción - Control
Resuelve el problema de la interacción entre varios agentes cooperativos.
Modelo
Encapsula los datos y comportamiento de la aplicación.
Registra a las vistas y controladores que dependen de el.
Cuando los datos cambian, le avisa a los componentes que dependen de el.
Es independiente de la representación de los datos
Controlador
Recibe los eventos de entrada desde los usuarios.
Transforma los eventos de entrada en:
-Invocaciones a servicios para el modelo
-Invocaciones de visualización para las vistas.
En caso de ser necesario actualiza las vistas cuando el modelo se actualiza.


Vista
Muestran al usuario los datos encapsulados por el modelo en algún formato.
Crea e inicializa a su controlador asociado.
Despliega la información hacia el usuario.
Implementa el procedimiento de actualización.
Recupera los datos desde el modelo.
Existen tantas como sea necesario.
Utilizar cuando se requieran aplicaciones interactivas con interfaz flexible, orientada a interactuar con seres humanos.
Estructura
Presentación
: Es responsable de la interacción con el exterior del agente
Abstracción
: Contiene el modelo de datos, controla el acceso a los datos del agente.
Control
: Comunica la presentación con la abstracción, comunica al agente con otros agentes.
Estructura
Patrones de Arquitectura
Contras:
Los cambios en meta-nivel pueden tener efectos no deseados.
Alto número de componentes.
Compromente fuertemente el desempeño.
Gran número de cambios en meta-nivel.
Implementar la reflexión puede ser difícil en muchos lenguajes de programación.
Soporta la adaptación y el cambio mediante un mecanismo que permite extender el software, adicionando funcionalidad y/o personalizando la funcionalidad existente.
Patrones de Arquitectura
Patrones similares o relacionados: Decorator, Facade y Strategy.
http://codejavu.blogspot.mx/2013/08/ejemplo-patron-adapter.html
http://java-white-box.blogspot.mx/2014/10/patrones-de-diseno-patron-bridge-puente.html
http://java-white-box.blogspot.mx/2014/10/patrones-de-diseno-composite.html
http://informaticapc.com/patrones-de-diseno/facade.php
https://danielggarcia.wordpress.com/2014/04/07/patrones-estructurales-vii-patron-proxy/
http://migranitodejava.blogspot.mx/2011/06/decorator.html
Patrones de Conducta
Se definen como patrones de diseño software que ofrecen soluciones respecto a la interacción y responsabilidades entre clases y objetos.
Template Method
Iterator
Command
Observer
State
Strategy
Pros:
Portabilidad.
Flexibilidad y extensibilidad.
Separación en MK de funcionalidad básica y compleja,
Escalabilidad.
Transparencia de ubicación.
Contras:
Menor eficiencia frente a un sistema sin MK.
Diseño e implementación complejos.
Dificultad para delimitar sus tareas.
Dificultad para definir la separación entre funcionalidad básica y compleja.
Definir el esqueleto de un algoritmo en una operación, diferir algunos pasos a subclases. Template Method permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.
Proporciona una forma de acceder a los elementos de un objeto agregado secuencialmente sin exponer su representación subyacente.
Encapsula una solicitud como un objeto, lo que permite parametrizar clientes con peticiones diferentes, solicitudes de cola o registro y admite operaciones deshacer.
Define una dependencia de uno a muchos entre los objetos para que cuando un objeto cambie de estado, todos sus dependientes sean notificados y actualizados automáticamente.
Permite que un objeto altere su comportamiento cuando cambia su estado interno. El objeto aparecerá para cambiar su clase.
Define una familia de algoritmos, encapsula cada uno, y los hace intercambiables. La estrategia permite que el algoritmo varíe independientemente de los clientes que lo utilizan.
Mediator
Define un objeto que encapsula cómo interactuar con un conjunto de objetos. El mediador busca reducir la dependencia evitando que los objetos se relacionen entre ellos de forma explícita, y permitiendo variar cualquier interacción independientemente
Singleton
Garantiza que una clase tiene una instancia única, proporcionando un solo punto de acceso global a ella
Aplicar cuando se tiene un objeto con:
Estructura compleja, con relaciones de agregación o composición con otras clases.
Partes dependientes entre sí, para forzar la construcción por etapas.
Dependencia de otros objetos difíciles o poco convenientes de obtener durante su creación.
de Creación
Estructural
de Comportamiento
Interpreter
Template Method
Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Adapter (de clase)
Adapter (de objetos)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Factory Method
Abstract Factory
Builder
Protopype
Singleton
Ámbito
Clase
Objeto
Abstract Factory
- Propósito:
- Aplicabilidad (Cuando usarlo?):
Proporcionar una interfaz para la creación de familias de objetos relacionados sin especificar sus clases concretas.
Un sistema debe ser independiente de la forma en que sus productos son creados, compuestos y representados.
Un sistema debe ser configurado con una de muchas familias de productos disponibles.
Una familia de productos son diseñados para su uso conjunto, y se requiere asegurar este uso conjunto.
Se desea proporcionar una biblioteca de productos presentando su interfaz, pero no su implementación
Abstract Factory (Estructura)
Abstract Factory (Ejemplo)
(Sistema con múltiples conexiones de base de datos)
Los patrones estructurales se enfocan en como las clases y objetos se componen para formar estructuras mayores, los patrones estructurales describen como las estructuras compuestas por clases crecen para crear nuevas funcionalidades de manera de agregar a la estructura flexibilidad y que la misma pueda cambiar en tiempo de ejecución lo cual es imposible con una composición de clases estáticas.
Maricarmen Saldivar
Omar López
Antonio Huerta
José Nabor
Angel Vargas
Basado en la presentación de
Javier Mora
Cómo describir los
patrones de diseño?
Por qué es
importantes
conocerlos?
Teoría general de los sistemas
Aristoteles
Ludwig von Bertalanffy (Teoría general de los sistemas)
* Son partes relacionadas entre si que colaboran con un fin.

La arquitectura
Es el conocimiento del diseño del sistema compartido por todo el equipo de desarrollo, este conocimiento representa:
La descomposición al mas alto nivel
Garlan & Shawn
La arquitectura de software constituye un nuevo tipo de problema a resolver que incluye decisiones relacionadas con:
1.- Organización global de la infraestructura (ejemplo cuando tienes xp)
2.- Protocolos de comunicación (forma de comunicación)
3.- Mecanismos de sincronización y acceso a datos
4.- Asignación de responsabilidades (funcionalidad) a elementos de diseño
5.- Despliegue físico (ejemplo deploy, no solo desarrollo)
6.- Composición de los elementos del diseño
7.- Escalabilidad y desempeño
8.- Selección entre alternativas de diseño (no resolver siempre la misma alternativa)

Definición IEEE
- Organización fundamental de un sistema comprendiendo sus componentes, sus relaciones entre si así como los principios que rigen su diseño y evolución
- Es la forma en la que encaja la totalidad del sistema con: restricciones económicas, minimalistas (hacer mas con menos) y aspecto de estética y estilo
Principios de la arquitectura
1.- Los objetos se modelan como sistemas
2.- Un sistema puede descomponerse en subsistemas mas pequeños.
3.- Un sistema debe de considerar su iteración con otros sistemas
4.- Un sistema debe de ser considerado a lo largo de todo su ciclo de vida
5.- Un sistema se comunica con otros por medio de una interfaz
6.- Un sistema puede ser considerado en varios niveles de abstracción
7.- Un sistema puede ser visto de a cuerdo a varias capas
8.- Un sistema puede describirse mediante modelos interrelacionados
9.- Un sistema puede ser descrito desde diferente puntos de vista


Requisitos
* La arquitectura surge de los requisitos
* No es un requisito hasta que no se documenta
* Algunos atributos de los requisitos: Identificador, Nombre (corto), Descripción, Prioridad, Tipo, Estabilidad, Responsable y Estado.
Tipo de requisitos
* Requisitos de producto:
Funcionales (como es la operación del negocio)
Calidad del servicio (no funcionales) desempeño o usabilidad
Plataforma tecnológica (Técnicos)
* Requisitos del proyecto (No técnicos)
Alcance, tiempo y recursos
Implementación
Procesos, estándares


Requsitos con arquitectura -> calidad del servicio
Atributos del modelo de requisitos:
* Completo
-Todos los involucrados
- Todos los tipos de requisitos
* Medible
- Requisitos cuantitativos además de cualitativos
_ Cada requisito se debe de poder medir objetivamente
* Independientes de la solución
- Expresados en necesidades del negocio
Full transcript