Artesanos de software: El uso e implementación de patrones de diseño en sistemas productivos, no todo en la vida son frameworks.
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Artesanos de software: El uso e implementación de patrones de diseño en sistemas productivos, no todo en la vida son frameworks.

  • 409 views
Uploaded on

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......

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).

More in: Software
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
409
On Slideshare
407
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 2

https://twitter.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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