Como líderes de proyectos, líderes técnicos, arquitectos de aplicaciones o desarrolladores, al comenzar un nuevo proyecto, dar mantenimiento sobre sistemas existentes o realizar una reingeniería de una aplicación, en la mayoría de los casos surgen las siguientes preguntas: ¿Qué tecnología usar para el desarrollo?, ¿Qué framework nos facilitará el trabajo de implementación?, ¿Cómo puedo acelerar el desarrollo del sistema?. Éstas y más interrogantes se generan al momento de la definición de la arquitectura de un nuevo proyecto, todo con un objetivo final: cumplir con las características ideales de una aplicación (que ésta sea mantenible, escalable, robusta, entendible y un largo etcétera necesario para cumplir con los deseos de los usuarios en el menor tiempo posible). La sesión expondrá diversos sistemas y casos de éxitos que cuentan con la implementación de una serie de patrones de diseño que permite prescindir de un framework en particular para su desarrollo, se expondrá una arquitectura de referencia con los principales patrones utilizados, ventajas/desventajas así como ejemplos y recomendaciones de cuando utilizar un framework, realizar una implementación in-house e incluso una mezcla de ambos enfoques. Semblanza del conferencista: Actualmente es Lider de Proyecto Aplicaciones Empresariales en Telcel, donde es responsable de definición de Arquitecturas de Aplicaciones Empresariales Orientadas a Servicios e Integración de Plataformas. Es Ingeniero en Sistemas Computacionales por el Instituto Tecnológico de Ciudad Guzmán. Maestría en Ciencias en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET).

1. El uso e implementación
de Patrones de Diseño.
Pedro Quiñonez Bernardino
Líder de Proyecto-Telcel

2. A G E N D A
●
La historia se repite...............
●
Objetivo
●
Que es un patrón
●
Clasificación
●
Implementaciones
●
Utilización de enfoques (cuando sí y cuando no)
●
Ventajas / Desventajas

3. La historia se repite...............
https://www.youtube.com/watch?v=qwZhHVl5hRU

4. Objetivo

5. Que es un patrón?
http://lema.rae.es/drae/?val=patr%C3%B3n
●
Un evento o problema que ocurre infinidad de veces en
nuestro entorno, así como la solución al mismo.
●
Un patrón define una posible solución correcta para un
problema de diseño dentro de un contexto dado.
Referencia: http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o#Categor.C3.ADas_de_patrones

6. Los 4 fantásticos...............
●
Elementos reusables.
●
No reinventar el hilo negro.
●
Homogenizar vocablos.
●
Estandarizar los diseños.
●
Facilitar el reconocimiento de
problemas.
●
Cerrar alternativas vs nuevas formas
de implementaciones.
●
Generar un ambiente cerrado a la
creatividad inherente en el
desarrollo de software.
Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides publican
Design Patterns
1979-Christopher Alexander

7. Clasificación
Creación
●
Abstract Factory
●
Factory Method
●
Builder
●
Singleton
●
Prototype
Estructura
●
Adapter
●
Bridge
●
Composite
●
Decorator
●
Facade
●
Proxy
●
Flyweight

8. ●
Chain of Responsability
●
Interpreter
●
Mediator
●
Memento
●
Visitor
●
Command
●
Iterator
●
Observer
●
State
●
Strategy
●
Template Method
Comportamiento
Clasificación

9. Implementaciones
●
Servidor Sockets Consultas S-HDR
●
Servidor de Reportes Corporativos (RUBI)
●
Front–End captura de información de Reportes y
Procesamiento Movimientos.

10. Servidor Sockets Consultas
S-HDR
●
Concurrencia●
Performance ●
Volumen
Objetivo: Implementación de un componente para la
comunicación de aplicaciones con plataforma de validación.
●
Traza y Logueo●
Comunicación Síncrona

11. Servidor Sockets Consultas
S-HDR

12. Servidor Sockets Consultas
S-HDR
P o o l C o n e c t i o n S i n g l e t o n
+ g e t I n s t a n c e ( )
+ c r e a t e I n s t a n c e ( )
+ g e t D a t a S o u r c e ( )
I C o n s u l t a S I A N T E L
C o n s u l t a S t o r e P r o c e d u r e J d b c S I A N T E L I m p l
+ s e t D a t a S o u r c e ( )
+ c o n s u lt a U n i t a r ia S I A N T E L ( )
+ c o n s u lt a M a s iv a S I A N T E L ( )
I C o m u n i c a t o r I n t e r f a c e
A b s t r a c t S t r e a m
+ d e b u g T r a m a ( )
O b j e c t S t r e a m C o m u n i c a t o r I m p l
+ O b j e c t S t r e a m C o m u n ic a t o r I m p l ( )
+ le e L i n e a ( )
+ e s c r ib e L in e a s ( )
+ e s c r ib e L in e a ( )
+ le e M e t o d o C o n s u l t a ( )
+ s e t I n p u t S t r e a m ( )
+ s e t O u t p u t S t r e a m ( )
+ le e R e s p u e s t a S e r v e r ( )
C o m u n i c a t o r F a c t o r y
+ c r e a C o m u n ic a t o r ( )
C o n s u l t a S i a n t e l F a c t o r y
+ c r e a C o n s u lt o r ( )
S i a n t e l S e r v e r
+ r u n ( )
+ c lo s e ( )
T a s k S i a n t e l E x e c u t e
+ r u n ( )
+ c lo s e S o c k e t ( )
+ i n it ( )
+ c o n s u lt a U n ic a ( )
+ c o n s u lt a M a s iv a ( )
S t a r t S i a n t e l S e r v e r
+ m a in ( )
C o n s t a n t e s U t i l
+ C O N S U L T A _ M A S I V A
+ C O N S U L T A _ U N I C A
G l o b a lP a r a m e t e r s
+ g e t P a r a m I d R e q u e s t ( )
+ c r e a t e I n s t a n c e ( )
+ g e t V a lu e ( )
D B B a s e D a o
+ c lo s e C o n n e c t io n ( )
+ e x e c u t e Q u e r y ( )
+ e x e c u t e U p d a t e ( )
+ g e t C o n n e c t i o n ( )
+ p r e p a r e C A L L ( )
+ p r e p a r e S Q L ( )

13. Servidor Sockets Consultas
S-HDR

14. ●
Reflection: obtiene instancia de implementación a utilizar en runtime.
●
Singleton: generación de única instancia de parámetros de configuración.
●
Factory Method: creación de instancia de objeto a realizar las consultas
a plataforma de validación.
●
Strategy: para permitir el intercambio de funcionalidad o algorítmo sin
afectar el flujo de la aplicación.
●
Pool de hilos: soporte de concurrencia por el servidor.
Servidor Sockets Consultas
S-HDR
Implementación.............................

15. Servidor de Reportes RUBI
Objetivo: Eliminar la problemática inherente en la
generación de los reportes del Sistema de Integral de
Aplicaciones.
Problemas:
●
Saturación de conexiones sobre sistema legacy.
●
Indisponibilidad de recursos compartidos entre aplicaciones.
●
Saturación de Cluster y servidores de aplicaciones.
●
Lentitud e indisponibilidad de aplicaciones.

16. Servidor de Reportes RUBI
Estado inicial..................

17. Servidor de Reportes RUBI

18. Servidor de Reportes RUBI

19. Servidor de Reportes RUBI
●
Template Method: Define algoritmo
de generación de reporte.
●
Observer: Pasos a nivel flujo de
reporte.
●
Strategy: Intercambio de
funcionalidad de reportes.
●
Singleton: Unica instancia de Pool de
Hilos (Reportes y Observadores).

20. Servidor de Reportes RUBI
Template Method: Define algoritmo de generación de reporte.

21. Servidor de Reportes RUBI
Observer: Pasos a nivel flujo de reporte.

22. Cúando sí y cúando no................
Implementación in-house:
●
Aplicaciones ligeras en tamaño (no en funcionalidad).
●
La funcionalidad es concreta y específica (no existen
indefiniciones).
●
No es opción actualizar aplicación (negocio).
●
Sistemas heredados con tecnologías desactualizadas
(aplicaciones operando, diversidad de API´s, alto costo en
actualización de aplicación).
●
Nivel intermedio-alto en conocimiento de POO, POA, Patrones
y estilos arquitectónicos.

23. Cúando sí y cúando no................
Implementación híbrida (framework + patrones):
●
Aplicaciones con funcionalidad más extensa y variada (no
reinventes el hilo negro).
●
La posibilidad de definir y proporner las tecnologías a utilizar
(proyectos de desarrollos nuevos).
●
El alcance del desarrollo es ambiguo (demasiada incertidumbre
e indefinición).
●
Robustez e implementaciones validadas por toda una
comunidad.

24. Ventajas / Desventajas...............
Ventajas:
●
Conocimiento y control total de “las tripas” de las aplicaciones.
●
Aplicaciones compactas, dedicadas y puras.
●
Identificación de un área de oportunidad y posible
implementación.
●
Promoción de pensamiento abstracto.
●
Comprensión de la forma de trabajo de API´s y framework.
●
Generación de mejores niveles de programación.
●
Especialización en la generalización.

25. Ventajas / Desventajas...............
Desventajas:
●
Curva de aprendizaje.
●
Cambio de cultura y pensamiento de abstracto.
●
Fuertes conocimientos de conceptos de programación y
orientación a objetos: “Ya sé porque no funciona.........”.
●
Caer en sobreingeniería y antipatrones.
●
Conocimiento puntual y especializado (saber qué, cómo, porque
y cuando).

26. Preguntas:
@quinonezbp
http://mx.linkedin.com/in/pquinonez
pedro.quinonez@gmail.com