Consultoría y Asesoría

1. Consultoría y Asesoría Jose Estrada Gerente de Servicios jose@techeras.com Migrando un Aplicativo Cliente/Servidor a Distribuido/WEB

2. Agenda • Objetivo • Arquitectura Cliente/Servidor • Problemas de la Arquitectura Cliente/Servidor • Aplicativo Cliente/Servidor • Diseñando la nueva Solución • Metodologia de RMPI bajo la Arquitectura Distribuida • Aplicando la Nueva Metodología • Aplicativo en entorno Distribuido

3. Objetivo

4. Objetivo Quieres llevar migrar tu Aplicativo Cliente/Servidor a WEB ? Nosotros te Ayudamos.... A continuación te mostramos cuales son los pasos para Migrar un Aplicativo en Arquitectura Cliente/Servidor a una Arquitectura Distribuida en WEB

5. Analisis de Situación Actual

6. Análisis de la Situación Actual • Arquitectura : Cliente/Servidor • Arquitectura Obsoleta y no Escalable • Poca/Nula Documentación de los Procesos • No hay Estandares para el Desarrollo • Pocos Informaticos conocen el Negocio de la Empresa • Conformismo y Falta de Visión

7. Arquitectura Cliente/Servidor Servidor de Base de Datos Cliente Vendedor / Platform-Specific API • Interfaz de usuario • Lógica de negocio • Administracion del Sistema • Administración de los datos • Lógica de negocio “propietario” en procedimientos almacenados y triggers

8. El manejo del código no particionado Volver a probar los cambios La administración de la máquina cliente El despliegue de cambio de la aplicación a los mútilples clientes La administración de la performance Deja la inversión del Hardware existente Problemas con la arquitectura Cliente/Servidor • Falta de control centralizado • Díficil de implementar la seguridad • Cuello de bolletas en el servidor de la base de datos/por la muchas conexiones • Lógica de negocio almacenada en la base de datos escrita en el lenguaje propietario • No preparado para otras interfaces

9. Problemas de Seguridad en la Arquitecura Cliente/Servidor El Driver de Conexión hacia la Base de Datos al estar instalado en el Cliente estamos expuestos a sufrir ataques indeseados por Usuarios con cierto conocimiento de Base de Datos o por intrusos ajenos a la Organización

10. Código No Particionado El código para la Administración de la Lógica del Negocio se encuentra disperso a lo largo de la Aplicación sin ningún orden. esto hace que el mantenimiento al Aplicativo sea complejo y tedioso

11. Problemas en el Tiempo de Respuesta En una Arquitectura C/S las conexiones son Síncronas, es decir un usuario está conectado a la Base de Datos durante el tiempo que el Aplicativo esté activo, sin un usuario abre el aplicativo y no realiza ninguna acción estará consumiendo una conexión.

12. Falta de un Control Centralizado El desarrollador no sabe con certeza en que capa realizar los cambios o generación de nuevo Codigo La Lógica de Negocio al no estar Centralizada en un servidor de componentes se encuentra tanto en el lado del Cliente y la Base de Datos. Esto trae problemas al momento de querer cambiar reglas del Negocio; muchas veces las reglas del Negocio están repetidas Lógica del Negocio en el Cliente Lógica de Negocio en la Base de Datos

13. Gastos en el Hardware del Cliente Cada vez se le aumenta más Lógica del Negocio al Cliente, requiriendo cada vez un Hardware más Robusto Cada vez que Incremente más Lógica del Negocio en el Cliente, este requerirá de un Hardware más Robusto

14. No está Preparado para Escalar • Lógica del Negocio Dispersa sin control : La logica al no estar centralizada no podra ser Reusada por otras aplicaciones y con ello se estara redundando el mismo codigo en diferente aplicaciones • Arquitectura Aislada : Esta Arquitectura NO nos permite comunicarnos con otras Plataformas que trabajan bajo WebServices y estan orientadas a la Arquitectura SOA • Arquitectura Obsoleta : Esta Arquitectura tiende a desaparecer por la misma necesidad de la empresa de entrar a un mundo mas globalizado y cada vez mas competitivo Desktop C/S

15. Poca/Nula Documentación del Sistema Muchas veces por la Premura de entregar resultados se omite un paso muy importante dentro del proyecto : La documentación de los Procesos y el Modelamiento. La documentación es la sustentación técnica del Proyecto, esto sirve de mucha ayuda cuando un nuevo integrante quiere conocer cuales son los procesos y los Flujos Internos que sigue el mismo o se desea hacer un rediseño. No hay Documentación de los Procesos X El desarrollador muchas veces tiene que explorar entre cientos de líneas de código para entender que hace el Programa, se pierden Horas/Hombre.

16. Falta de Estandares en el Desarrollo No hay un estandar unico para la codificación tanto a lado del cliente y del Servidor de Base de Datos , por la falta de control cada Desarrollador a escrito el código de acuerdo a su criterio, esto trae consigo un gran desorden y en muchas casos el código es poco entendible al momento de realizar tareas de Mantenimiento

17. Pocos Informaticos conocen el Negocio Un Problema que hemos detectado es que muchos informaticos NO conocen el negocio de la empresa, esto es debido a que la mayoria se preocupa por labores netamente de programación pero pocos hacen enfasis en el dominio del conocimiento del negocio que es en muchos casos lo que deseamos automatizar

18. Conformismo y Falta de Visión Que el avanze Tecnologico no te tome de sorpresa, en Techera dictamos cursos de PowerBuilder Distribuido y WEB.... Te esperamos Un Problema frecuente es el conformismo, la idea de que “Nunca voy a necesitar cambiar mi Arquitectura...si todo funciona bien” se viene abajo cuando hay que compartir informacion en linea con aplicaciones externas via WebServices por ejemplo o cuando debemos generar una interfaz WEB de nuestra aplicación .... Que haremos.....? Pues reescribir todo la Logica del Negocio, la Falta de visión a largo plazo genera un caos cuando el Aplicativo C/S tiene que escalar a otras plataformas, esto en muchos casos puede costar el puesto de Trabajo a los lideres del Area Informatica.

19. Cuales son los Pasos para migrar mi Aplicativo a Distribuido-WEB ?

20. Diseñando la nueva Solución • La experiencia nos ha enseñado que los Proyectos deben contener • Las siguientes etapas : • Redacción del Plan de Proyecto • Explicación de la Nueva Arquitectura • Metodología de Desarrollo a Cinco Capas • Análisis y Modelamiento del Aplicativo • Diseño de los Prototipos • Separando las Tareas antes del Desarrollo • Generación de Código • Pruebas Unitarias • Pruebas Integrales / Casos de Prueba • Preparación de los Manuales del Sistema, Usuario y Guía de Operación • Transferencia Tecnológica del Proyecto al Reponsable del Area

21. Redacción del Plan de Proyecto • El Plan de Proyecto contiene en forma general cuales • seran las etapas para la generación del nuevo Aplicativo • El Plan de Proyecto es casi como un acuerdo Previo de • Las tareas a realizar ; este documento lo revisa el Area • Informatica para dar su consentimiento, este documento • contiene : • Objetivos • Funciones principales • Tiempos Estimados • Estándares propuestos • Documentos de gestión de Riesgos • Metodología

22. Gestión de Riesgos durante el Proyecto El documento de Gestión de Riesgos nos permite planificar todos los posibles eventos que pueden suceder a lo largo del Proyecto. Este documento también nos indica como haremos para mitigar las incidencias. Riesgos del Proyecto El Lider del Proyecto debera mitigar los Riesgos, evitando que estos afecten el éxito del proyecto

23. Explicación de la Nueva Arquitectura Servidor de base de datos Servidor de Aplicaciones Cliente • Administración de los datos • Lógica de negocio • Cache de Conexiones • Manejo de las transacciones • Transparencia de los datos a los usuarios • Balanceo de carga • Interfaz de usuario • Alguna lógica de negocio (reducida)

24. Ventajas y Desventajas • Ventajas • Cientes “más delgados” • Disminuye la administración del cliente • Encapsulación de la lógica • Mejor perfomance • Escalabilidad • Consistencia, control y seguridad • Reutilización de componentes existentes • Posicionamiento para la Web • Desventajas • Cambios en los hábitos de programación • Más curvas de aprendizaje

25. Herramientas a Usar • Las siguientes son las Herramientas a usar para la Generación del nuevo Aplicativo con Interfaz WEB y bajo la Arquitectura Distribuida : • Lenguaje de Programación – Componentes : PowerBuilder v.10.0 • Lenguaje de Programación – JSP,Servlets, Struts: NetBeans v.3.5 • Modelamiento de Procesos, Negocios, Clases: PowerDesigner v.11.0 • Servidor de Aplicaciones (Componentes,Web): EAServer v.5.2 • Diseño de Hojas de Estilos, Gráficos : DreamWeaver • Redacción de Documentos : MS-Office

26. Las Aplicaciones Web • Fácil para Usar • Rápido acceso a la información • Contenido personalizado de acuerdo a los parámetros de los usuarios

27. Las Aplicaciones Web • Perspectivas de los Clientes • Reportes en línea • Información las 24 horas del día los 7 días de la semana • Información Segura • Poder exportar e importar los datos

28. Las Aplicaciones Web • Porqué de las Aplicaciones Web? • Información en Línea • Información las 24 horas del día • Consulta de Servicios Web • Independencia de Configuración de equipos clientes • Clientes delgados • Preparados para crecimientos de las empresas • Información Electrónica

29. Las Aplicaciones Web • Cómo Trabajan las Aplicaciones Web • El navegador puede considerarse como una interfaz de usuario universal. Dentro de sus funciones están la petición de las páginas Web, la representación adecuada de sus contenidos y la gestión de los posibles errores que se puedan producir. • Para todo esto, los fabricantes de navegadores les han dotado de posibilidades de ejecución de programas de tipo script, con modelos de objetos que permiten manipular los contenidos de los documentos.

30. Las Aplicaciones Web Como es el flujo de información

31. Beneficios de las Aplicaciones Web • Globalización de los Servicios • Integración de los Servicios • Integración con Arquitecturas Móviles • Escalabilidad

32. Beneficios de las Aplicaciones Web • Globalización de los Servicios • Tener la información preparada para cualquier parte del mundo • Soporte de todos los mecanismos de control • Integración con otras plataformas • Soporte de Tecnologías XML • Soporte de Tecnologías Web Services • Integración de Servicios • Permite poder integrarse con diferentes servicios Web • Informar a los clientes en Línea • Generar reportes actualizados

33. Beneficios de las Aplicaciones Web • Integración con Móviles y Wireless • Extender la funcionalidad para poder interactuar con clientes móviles: • Acceder a través internet móvil • Acceso Wireless desde équipos móviles • Escalabilidad • Las Aplicaciones Web, pueden escalar de acuerdo a las necesidades que se van generando, por estar basados sobre una tecnología Orientada a Objetos. • Trabajan con las últimas tecnologías del mercado, las cuales les permite soportar los cambios. • Trabajan sobre diferentes arquitecturas y esto es lo que les permite poder escalar a otras plataformas.

34. Seguridad en las Aplicaciones Web • Seguridad con Certificados Digitales • Se realiza a través de Certificados quienes podrán validar el acceso a Través de claves públicas y privadas • Seguridad a nivel Sistema Operativo • Se realiza mediantes los usuarios que se tienen establecidos en las redes de las empresas • Seguridad a través de Perfiles • Son definidos perfiles para que los usuarios puedan acceder a los sitios web

35. Metología de Desarrollo a cinco Capas usando RMPI • Esta arquitectura separa y organiza las tareasdel Proyecto, haciendo que las personas se puedan especializar en una determinada Capa. • Esta arquitecturahace énfasis en la • separación de las reglas del negocio de la empresa con la Interfaz para una correcta organización del software, se Divideen cinco capas : • Capa de Presentación • Capa de Aplicación • Capa de Negocio • Capa de Persistencia • Capa de Datos

36. Metología de Desarrollo a cinco Capas Capa de Presentacion (Paginas) Capa de Aplicación (Servlets) RMPI Capa de Negocios (Componentes) Capa de Datos (Tablas) Capa de Persistencia (Componentes)

37. Beneficios de Trabajar en esta Arquitectura • Análisis y Documentación por Cada Capa • Eficiente organización y distribución de los objetos por cada capa • Cada capa es modelada bajo UML usando PowerDesigner • Alta Reusabilidad de los Objetos en cualquiera de las Capas. • Especialización del Personal en alguna de las capas • Fácil y optima comunicación entre las diferentes capas  • Centralización de la Lógica del Negocio  • Rápido diagnóstico de Errores y corrección de los mismos • Preparados para escalar a la Arquitectura de SOA

38. UML (Lenguaje Unificado de Modelamiento) • UML es un lenguaje estándar para crear planos de software. • No es un lenguaje de programación. Sin embargo permite hacer una rápida transición del modelo al código. • Es una herramienta de la ingeniería de software.

39. ¿Por qué utilizar UML? • Porque recoge lo mejor de diferentes sistemas de modelamiento. • Porque es adaptable a casi cualquier sistema. • Porque puede ser utilizado en la mayoría de fases de un proyecto. ¿Qué ventajas trae esto?...

40. UML en un proyecto • UML dispone de herramientas que pueden ser utilizadas en la mayoría de fases de un proyecto de ingeniería de software. • Esto permite tener información consistente en cada fase. CADA MODELO HACE REFERENCIA A OTROS MODELOS.

41. Análisis y Modelamiento del Aplicativo Los Diagramas usados en el Modelamiento para el Proyecto Son : Modelo de Negocios Diagrama de Casos de Uso Diagrama de Actividades Diagrama de Clases General Diagrama de Clases por cada Capa Diagrama de Secuencia Diagrama de Base de Datos Diagrama de Casos de uso Diagrama de Clases general Diagrama de Secuencia Diagramas usados dentro de la Metología de cinco Capas Modelo de Negocios Diagrama de Actividades Diagrama de Clases por cada Capa Diagrama de Base de Datos

42. Análisis y Modelamiento del Aplicativo – Modelo de Negocios Hacer un Análisis de los procesos principales del sistema actual y en función a esto generar el Modelo de Negocios del Sistema, este Modelo muestra como interactúan las diferentes unidades organizacionales que hacen uso del Sistema.

43. Análisis y Modelamiento del Aplicativo – Diagrama de Actividades El Diagrama de actividades Muestra el Flujo en los procesos Principales, esto nos permite ver como fluye la Información.

44. Análisis y Modelamiento del Aplicativo- Diagrama de Caso de Uso El Diagrama de Casos de Uso nos permite describir la acción desde el punto de vista del Usuario, esta es una técnica de aciertos y errores hasta llegar a entender lo que el Usuario desea

45. Análisis y Modelamiento del Aplicativo- Diagrama de Clases El Diagrama de clases muestra las diferentes entidades y como se interrelacionan una con otras.

46. Análisisy Modelamiento del Aplicativo- Diagrama de Secuencia El Diagrama de secuencia Muestra el fjujo de información entre los Objetos de las Diferentes capas, nótese que bajo nuestra Metología se respeta el número de Capas.

47. Análisis y Modelamiento del Aplicativo- Modelo de Datos El Modelo de Base de Datos muestra las Entidades que formaran parte de nuestro nuevo Modelo de Datos, este Modelo ha sido generado a partir del Diagrama de Clases.

48. Preparando los Prototipos Antes de comenzar el desarrollo se preparan los Prototipos para validarlos con el usuario; es muy importante que el usuario participe en las diferentes etapas del Proyecto para que el haga suyo el Proyecto y se sienta comprometido con el éxito del mismo. El Usuario debe validar si el Prototipo se ajusta a sus Requerimientos, en este punto la interacción con el usuario es alta, la idea es que el usuario sienta que el Aplicativo que se desarrolla se ajusta a su necesidades. Una vez hecha las correcciones y teniendo la conformidad del usuario continuamos con el Desarrollo.

49. Separación de Tareas Antes de distribuir la carga de Trabajo es importante conocer la Fortaleza de cada integrante del equipo de Desarrollo; el éxito del proyecto esta en descubrir las habilidades y destrezas de cada Integrante para realizar una correcta distribución de Trabajo. El Líder o Jefe de Proyecto debe asignar las Tareas de acuerdo a las Habilidades

50. Generación de Código – Agregando Operaciones Desde PowerDesigner registramos las operaciones o métodos por cada Clase.