algoritmos y programación iii 5. desarrollo orientado a objetos - introducción carlos fontela,...

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

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

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

Requisitos

Análisis

Diseño

Implementación

Pruebas

Producción/Mantenimiento

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

Flujos – Fases Inicio Elaboración Construcción Transición

Requisitos 50% > 80% 100% 100%

Análisis y Diseño 5% 20% 100% 100%

Implementación, pruebas unitarias y de integración

0% < 10% 80% - 90% 100%

Despliegue, pruebas finales, puesta a punto

0% 0% 0% 100%

PUDS (casos de uso)

Dirigen todo el proceso

Casos de uso > Identificados Descriptos AnalizadosDiseñados, implemen-

tados y probados

Inicio 50% 10% 5% Sólo algún prototipo

Elaboración > 80% 40% - 80% 20% - 40% < 10%

Construcción 100% 100% 100% 100%

Transición

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

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

Secuencia Representación temporal de los objetos y sus

interacciones.

Colaboración 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