Especialización en Telemática Desarrollo de Software Arquitecturas de Sistemas Telemáticos Dr. Ing. Álvaro Rendón Gallón Cali, mayo de 2012 Temario 2 Tarea 1: Ordenar datos Tarea 2: Un juego en red Consideraciones para el desarrollo de software Proceso de Desarrollo RUP y XP Arquitectura y Modelado 1
Tarea 1 3 Ordenar los datos de una tabla usando el algoritmo de ordenamiento de burbuja public void bubble(int [] a) { for (int i=1; i<a.length;i++) { for(int j=0;j<a.length-1;j++) { if (a[j] > a[j+1]) { int temp = a[j]; a[j]= a[j+1]; a[j+1]= temp; } } } } http://es.wikipedia.org/wiki/ordenamiento_de_burbuja Tarea 2 4 Desarrollar un juego en red para dos jugadores Cliente 2
Problemas del Software 5 Dificultades que enfrentan los proyectos software: Retraso en la entrega Falta de fiabilidad Coste excesivo Ineficiencia Mantenimiento problemático Falta de adaptabilidad Escasa portabilidad Carencia de documentación etc. Un error de USD 500 millones 6 Hecho: 4 de junio de 1996, Ariane 5 explotó 40 segundos después del lanzamiento. Causa: Error en un fragmento de código que no se usaba en vuelo. La falla de Ariane 5 fue causada por la pérdida completa de la información de guía y altitud. La conversión de un dato de coma flotante de 64 bits a un valor entero de 16 bits causó una excepción que no tenía un manejador asociado y abortó el programa. Código heredado: El error en la conversión no se presentaba en Ariane 4 pero sí en Ariane 5. 3
Desarrollo de aplicaciones Web 7 Navegador Servidor Web HTTP JavaScripts CGI Servlet ASP Applets ActiveX I IOP DCOM Servidor de Aplicaciones Base de Datos y de Web 1.0 a Web 2.0 8 Navegador Web 1.0 Servidor Web Actualización Usuario CONSULTA Aplicacio nes Base de Datos Administrador Navegador Web 2.0 Servidor Web Usuario PRODUCCIÓN/ CONSULTA Aplicacio nes Base de Datos BLOGS WIKIS REDES SOCIALES 4
Arquitectura a 3 niveles 9 3-tier Nivel 1 Cliente Interfaz de usuario Nivel 2 Servidor de Aplicaciones Gestión de procesos (Lógica del negocio) Nivel 3 Servidor de Bases de Datos Gestión de los Datos Arquitectura de Google (aproximación) 10 Navegador HTTP Servidor Web Servidor Web Servidor Web Nivel 1 Google Architecture http://highscalability.com/google-architecture Servidor de Aplicaciones Servidor de Aplicaciones Servidor de Aplicaciones Nivel 2 Internet Base de Datos Base de Datos Base de Nivel 3 Datos 5
Por qué modelar? 11 Uso creciente de Internet como proveedor de múltiples servicios Internet Consideraciones para el desarrollo 12 Diversidad de participantes en el desarrollo de las aplicaciones Alta gerencia Público Otras empresas Diseñadores gráficos Comunicadores Abogados... Equipo de desarrollo 6
Consideraciones para el desarrollo 13 Continua evolución de las aplicaciones una aplicación Web estancada está muerta (Booch) Negocio Tecnologías Consideraciones para el desarrollo 14 Las aplicaciones deben cumplir con características exigentes: Calidad Fiable: Capacidad de ofrecer los mismos resultados bajo las mismas condiciones. Eficiente: Utilización óptima de los recursos de la máquina. Robusto: No poseer un comportamiento catastrófico ante situaciones excepcionales (Tolerante a fallos). Correcto: Se ajusta a las especificaciones dadas por el usuario. 7
Consideraciones para el desarrollo 15 Las aplicaciones deben cumplir con características exigentes: Calidad Fiable: Portable: Capacidad Capaz de de integrarse ofrecer los en mismos entornos resultados distintos con bajo el mismo las mismas esfuerzo. condiciones. Eficiente: Adaptable Utilización (extensibilidad): óptima Modificar de los recursos alguna de función la sin máquina. que afecte a sus actividades. Robusto: Inteligible: No Diseño poseer claro, un comportamiento bien estructurado catastrófico y ante documentado. situaciones excepcionales (Tolerante a fallos). Correcto: Se ajusta (en suma) a las Mantenible: especificaciones dadas por el usuario. El software debe evolucionar para adaptarse a las necesidades cambiantes Consideraciones para el desarrollo 16 Las aplicaciones deben cumplir con características exigentes: Calidad Portable: No Erróneo: Capaz No de exista integrarse diferencia en entornos entre los distintos valores con el reales mismo y los esfuerzo. calculados. Adaptable Reutilizable (extensibilidad): (reusabilidad): Modificar Facilidad que alguna ofrece función para sin usar que sus afecte funcionalidades a sus actividades. o componentes en nuevos proyectos Inteligible: Diseño claro, bien estructurado y documentado. Oportuno (en suma) Mantenible: Económico El software debe evolucionar para adaptarse a las necesidades cambiantes 8
Proceso de Desarrollo 17 El desarrollo de aplicaciones requiere contar con herramientas conceptuales y metodológicas, además de las informáticas En general, un Proceso define QUIÉN está haciendo QUÉ, CUÁNDO y CÓMO, para alcanzar un cierto objetivo En ingeniería de software, el objetivo es construir un producto software o mejorar uno existente Proceso de Desarrollo de Software 18 Provee guías para el desarrollo eficiente de software de calidad Clientes, usuarios, desarrolladores y gerentes Captura y presenta las mejores prácticas que permite el estado del arte Reduce el riesgo e incrementa la predictibilidad Promueve una visión y cultura de desarrollo comunes 9
Proceso de Desarrollo de Software Fases genéricas: Definición Se identifican los requisitos clave del sistema y del software: información, funcionalidad, interfaces, rendimiento, etc. Desarrollo Diseño del software, generación de código y pruebas Mantenimiento DESARROLLO Corrección, Adaptación, Mejora y Prevención DEFINICIÓN 19 MANTENIMIENTO Proceso de Desarrollo en V 20 Captura de Requisitos Requisitos del Sistema Especificación Especificación del Sistema Diseño Diseño del Sistema Plan de Pruebas de Aceptación Plan de Pruebas del Sistema Plan de Pruebas de Integración Implementación y Pruebas de Unidad Sistema Entregado Pruebas de Integración Pruebas de Aceptación Pruebas de Sistema Módulos probados Sistema Probado Sistema Integrado 10
Validación temprana 21 Nivel de Sistema Pruebas de Especificación Análisis Preliminar del Sistema Pruebas de Diseño e Integración Arquitectura del Sistema Pruebas de Producto Producción y Entrega Base de Datos Solicitud de Nuevas Tecnologías Nivel de Componente Elaboración de Componentes Pruebas de Componente Solicitud de Nuevos Componentes Modelado/Codificación 22 Tamaño Código Tiempo Proyectos pequeños (sólo código) 11
Modelado/Codificación 23 Tamaño Modelos Código Tiempo Desarrollo en Cascada Modelado/Codificación 24 Tamaño Pruebas Implementación Diseño Análisis Requisitos Tiempo Desarrollo Incremental 12
Modelado/Codificación 25 Tamaño Pruebas Diseño Análisis Requisitos Pruebas Transformación Tiempo Desarrollo basado en Modelos ( Software model checking takes off, Miller et al., 2010) Modelado/Codificación 26 Tamaño Pruebas Codificación Metáfora Requisitos Tiempo Método Ágil 13
Proceso de Desarrollo de Software 27 Dos paradigmas de desarrollo: Desarrollo basado en modelado Proceso Unificado de Desarrollo RUP: Rational Unified Process The three amigos : Booch, Rumbaugh, Jacobson Desarrollo basado en construcción de código Programación Extrema XP: extreme Programming Kent Beck Proceso Unificado de Desarrollo 28 Características: Iterativo. Refinamiento sucesivo Controlado. Gestión de requisitos y control de cambios Construcción de modelos Centrado en la arquitectura Desarrollo de software basado en componentes Conducido por los Casos de Uso Soporta técnicas OO. Uso del UML Configurable Fomento al control de calidad 14
Proceso Unificado de Desarrollo 29 Organización por Componentes COMPONENTES DEL PROCESO Modelado de la Organización Captura de Requisitos Análisis Diseño Implementación Pruebas Puesta en Servicio COMPONENTES DE SOPORTE Gestión de Configuración y Cambios Gestión del Proyecto Entorno Hitos Organización en el tiempo Gestación Preparac. Construcción Inicial Prep. Prep. #1 #2 FASES Const. #1 Const. #2 Iteraciones Transición Arquitectura! Const. Trans. Trans. #N #1 #2 Planificación Versiones pequeñas Metáfora* Diseño simple Pruebas Recodificación * sustituye mucho de lo que otra gente llama arquitectura (K. Beck) Programación Extrema Prácticas: Programación en parejas Propiedad colectiva del código Integración continua 40 horas semanales Cliente en el sitio Estándares de codificación 30 15
Programación Extrema 31 Arquitectura! http://www.extremeprogramming.org/ Papel de la Arquitectura 32 Arquitectura: Aspecto central en el desarrollo de una aplicación Qué es la arquitectura? Arquitectura se refiere a la representación abstracta de los componentes de un sistema y su comportamiento. La arquitectura no contiene detalles de implementación. Curso SUN SL-425: Architecting and Designing J2EE Applications 16
Modelo: Papel del modelado Representación en pequeña escala Diccionario Larousse Abstracción de algo con el propósito de entenderlo antes de construirlo Rumbaugh (OMT) UML: Unified Modeling Language (Lenguaje Unificado de Modelado) Notación para representar: Modelos (RUP) Arquitectura/Diseños (XP) 33 Referencias 34 Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified Software Development Process. Addison-Wesley. Reading (USA). 1998. Pablo López. Introducción a la Ingeniería de Software. Transparencias de Clase. Universidad de Málaga (España). 2006. http://www.lcc.uma.es/~lopez/modular/ingsw/transp_ingsw.pdf Douglas N. Arnold. The Explosion of the Ariane 5. 2000. http://www.ima.umn.edu/~arnold/disasters/ariane.html María D. Lozano. Introducción al Desarrollo de Sistemas Software. Transparencias de Clase. Universidad de Castilla-La Mancha (España). 2007. http://www.dsi.uclm.es/asignaturas/42541/teoria.html Steven P. Miller, Michael W. Whalen, and Darren D. Cofer. Software model checking takes off. Communications of the ACM, Vol. 53, No. 2, February 2010, pp. 58-64. Don Wells. Extreme Programming: A gentle introduction. 2006. http://www.extremeprogramming.org/ Kent Beck. Una explicación de la Programación Extrema. Aceptar el cambio, (Traducción: F.J. Zapata). Addison Wesley. Madrid. 2002. 17