Algoritmos y Programación III 5. Desarrollo orientado a objetos - Introducción Carlos Fontela, 2005

Temario Orientación a objetos: recapitulación UML: recapitulación Desarrollo en cascada y desarrollos incrementales Proceso Unificado Métodos ágiles Extreme Programming

OO: objetivos ¡¡¡Manejo de la complejidad!!! Conceptos comunes de modelado a lo largo del ciclo de vida Reducción de brecha entre problemas y modelos Reutilización y extensión del código Uso de prototipos Programación en ambientes de interfaz de usuario gráfica. Programación por eventos. Programación para la World Wide Web. Desarrollo de aplicaciones distribuidas. Uso de patrones. ¡¡¡Manejo de la complejidad!!!

Conceptos Método o proceso Notación Herramienta Define quién debe hacer qué, cuándo y cómo se deben realizar las distintas tareas. Proceso Unificado, Extreme Programming, Scrum, Yourdon, etc. Notación Lenguaje de especificación de modelos. Para diagramar los conceptos principales del software a construir. UML, Yourdon, OMT, etc. Herramienta Aplicación que facilita el desarrollo. Suele generar parte del código. Rational Rose, Borland ModelMaker, XDE (Extended Development Environment, de Microsoft), Cool:Plex, etc.

UML Notación de modelado Creada por Booch-Rumbaugh-Jacobson Usa diagramas Diferentes diagramas para distintos modelos Importante: mantener flexibilidad y sencillez Muy buena fama y estandarizado por OMG No confundir con RUP o PUDS: no es un proceso o método

Desarrollo en cascada

Inconvenientes de la cascada Impide comenzar una etapa hasta que la anterior no está concluida => retraso. Cambios sobre una etapa ya terminada, a costa de burocracia y documentación. Soluciones locales: remediar en diseño errores de análisis o en implementación errores de diseño. El usuario final recién ve el sistema una vez que está terminado: poco consustanciado con el desarrollo no advierte errores de concepción a tiempo.

Métodos incrementales Cascadas parciales. Facilidad para atender cambios de requerimientos. Errores aparecen antes. Mayor continuidad entre fases. Competencias más amplias: Analista se confunde con diseñador Diseñador con programador

Categorías de métodos Grandes metodologías Métodos ágiles Se utilizan en grandes proyectos. Suelen ser inaceptablemente pesadas para sistemas pequeños o medianos. Destaca el Proceso Unificado de Desarrollo de Software (PUDS). Métodos ágiles O evolutivos o adaptables. Permiten organizar desarrollos medianos sin caer en burocracias paralizantes. Alternativa a carecer de metodología. Destaca Extreme Programming (XP).

Proceso Unificado (flujos) Requisitos Análisis Diseño Implementación Prueba ¡No se refieren al tiempo! Asociados a tareas

Proceso Unificado (fases) Inicio o Concepción Elaboración Construcción Transición Se refieren al tiempo Asociadas a hitos y objetivos

PUDS – Fases – Inicio Objetivos del hito de finalización: Qué hacer: Haber definido los objetivos del sistema. Tener una idea aproximada del costo. Establecer la factibilidad del proyecto (si conviene proseguir). Qué hacer: Planificar el proyecto. Estudiar factibilidad. Delimitar alcance. No suele ser una fase iterativa.

PUDS – Fases – Elaboración Objetivos del hito de finalización: Haber acotado los riesgos. Tener definida la arquitectura básica. Tener definido el plan de iteraciones de construcción. indicando qué casos de uso se realizan en qué iteraciones, empezar por los prioritarios para el cliente y los de mayor riesgo. Qué hacer: Establecer las “arquitecturas”. Analizar los riesgos mayores. Puede ser una fase iterativa.

PUDS – Fases – Construcción Objetivos del hito de finalización: Tener la capacidad operativa inicial (versión beta). Es la fase iterativa por excelencia. Qué hacer en cada iteración: Miniproyecto que debe terminar con una entrega al usuario y pruebas de sistema. Involucra análisis, diseño e implementación. Se pueden hacer cambios de arquitectura. E ir ajustando la planificación de las iteraciones.

PUDS – Fases – Transición Objetivos del hito de finalización: Lanzamiento del producto. Qué hacer: Desplegar el producto para ser utilizado. Puesta a punto. Adaptación a necesidades no previstas de los usuarios que surjan de las pruebas beta. Añadir optimizaciones: no se añaden funciones nuevas, pero se desarrolla para optimizar y depurar.

PUDS (fases y flujos)

PUDS (casos de uso) Dirigen todo el proceso

PUDS – Control del riesgo Inicio: se estudian los casos de uso con los usuarios y construyen prototipos para validar conceptos. Elaboración: se exploran escenarios y arquitecturas con los usuarios. Construcción: se van ensamblando partes ya probadas sobre un código también probado. Transición: se hacen despliegues graduales en las etapas anteriores.

PUDS - Conclusiones Metodología muy desarrollada. Analizar en otro lado. Libros y cursos. Muy amplio: Se puede combinar con otros métodos. ¡Sin trampas!

Métodos ágiles (I) Adaptables o adaptativos. Se adaptan a cada desarrollo. Para desarrollos menos predecibles. Bastante comunes en el software. Para facilitar cambios de requisitos sobre la marcha. No para cualquier cliente. No para cualquier informático. Diseño y programación muy acoplados.

Métodos ágiles (II) Ojo con: Variables manejables Tiempos fijos. Alcances fijos. Presupuestos fijos. Variables manejables Calidad Costo Tiempo de desarrollo Alcance Ajustar el alcance y no la calidad.

Métodos ágiles (III) Extreme programming (XP) ASD Cristal Código abierto un nombre engañoso Scrum Desarrollo manejado por rasgos (FDD) DSDM (Método de desarrollo de sistema dinámico)

Extreme Programming (I) Kent Beck y la comunidad Smalltalk. Lleva al extremo las buenas prácticas. Objetivos Bajar el riesgo. Permitir cambios de especificaciones durante el desarrollo. Favorecer la comunicación con el cliente. Que la inversión crezca gradualmente.

Extreme Programming (II) ¿Probar programas es bueno? Hacer pruebas unitarias y funcionales todo el tiempo. El desarrollo es dirigido por las pruebas: Test-Driven Development (TDD). Se diseñan antes de codificar. ¿Los diseños de software son cambiantes? El diseño evoluciona junto con la programación. Lo hacen los propios programadores.

Extreme Programming (III) ¿Hacer pruebas de integración es importante? Integración sigue inmediatamente a las pruebas unitarias. Permite que no sea cada vez más complicado integrar código de varias fuentes. ¿Revisar la calidad del código es recomendable? Revisar código todo el tiempo. Refactorizaciones (cambio de diseño para hacerlo simple, sin cambiar funcionalidad).

Extreme Programming (IV) ¿Estándares de codificación permiten una mejor comunicación y reducen errores? Fijar estándares precisos y estrictos. ¿Es bueno que el sistema sea simple? Buscar siempre la simplicidad. Diseñar sólo lo que se necesita en el momento. Principio más controvertido de XP. ¿Los requerimientos de arquitectura son cambiantes? Refinar la arquitectura constantemente.

Extreme Programming (V) ¿El desarrollo incremental es positivo? Hacer iteraciones muy cortas. Diseñar una pequeña porción, codificarla y probarla. Preocuparse sólo por lo que se está haciendo. Nada por adelantado. ¿Es importante tener una comunicación frecuente con el cliente? Un cliente acompañando el desarrollo. Fundamental para escribir pruebas funcionales y priorizar tareas.

Extreme Programming (VI) ¿Es frecuente que los proyectos se suspendan por falta de presupuesto? Usar el alcance como variable de ajuste. Implementar primero lo que tiene mayor valor para el cliente. La primera iteración debe implementar un esqueleto, con funcionalidades básicas. En la mayoría de los sistemas, el 20% del desarrollo genera el 80% del beneficio.

Extreme Programming (VII) ¿Dos cabezas piensan más que una? Los programadores trabajan de a dos. Cada pareja es responsable de una tarea. Aspecto más mencionado de XP. Y a la vez el menos conocido. Como refuerzo de las prácticas anteriores. ¿Es difícil mantener la documentación de desarrollo? “Burn it” (Beck). Aspecto muy cuestionado. Mucha comunicación interna.

Extreme Programming (VIII) Simplicidad “The simplest thing that could possibly work”. Complejidad dificulta refactorizaciones, comunicación y depuraciones. No implementar lo que no se sabe si servirá, y en el 80% de los casos no sirve. Se mantiene baja la inversión inicial en el proyecto. El código ejecutable permanece más chico. La simplicidad cuesta trabajo y es fruto de un buen diseño.

No aplicar XP en... Proyectos que necesiten especificaciones precisas desde el comienzo. Equipos de trabajo con más de 20 programadores (el número ideal es 10). Equipos de trabajo que deben trabajar separados. Cuando la tecnología es un impedimento, por tiempos de prueba o integración. Precio y plazo fijos. Bibliotecas genéricas, sobre todo si no se puede llevar la biblioteca a producción hasta terminarla.

Pruebas Ver www.fi.uba.ar/materias/7507F Centrarse en pruebas unitarias y de integración.

Documentación Ver www.fi.uba.ar/materias/7507F Documentación interna: en el código, para los programadores Claridad Comentarios Documentación en línea

javadoc - HTML /** documentación para javadoc */ @see nombre-de-clase @ version información-de-versión @author información-del-autor @param nombre-de-parámetro descripción @return descripción @throws clase-de-excepción-con-sus-calificadores descripción

Diagramas UML (I) Clases Paquetes Objetos Estructura estática en términos de clases, interfaces y colaboraciones Y las relaciones entre ellas. Paquetes Grupos de clases y sus dependencias. Objetos Instancias de los elementos de un diagrama de clases, mostrando un conjunto de objetos en un momento concreto, con sus estados y relaciones.

Diagramas UML (II) Estados y transiciones Componentes Despliegue Comportamientos dinámicos de objetos en términos de estados, transiciones y eventos. Componentes Componentes de software. Despliegue Nodos de procesamiento y los componentes que residen en ellos.

Diagramas UML (III) Interacción Secuencia Colaboración Representación temporal de los objetos y sus interacciones. Objetos e interacciones, pero privilegiando las relaciones entre los distintos objetos.

Resumen No confundir notaciones, procesos y herramientas. Los métodos formales van bien con organizaciones formales. Y con presupuestos, tiempos y alcances fijos. Los métodos ágiles se adaptan a requisitos cambiantes.

Bibliografía y otras fuentes Una explicación de la programación extrema, Kent Beck. El Proceso Unificado de Desarrollo de Software, Rumbaugh-Booch-Jacobson. UML gota a gota, Martin Fowler. La Web.

Muchas Gracias. Carlos Fontela, 2005