algoritmos y programación iii 5. desarrollo orientado a objetos - introducción carlos fontela,...
TRANSCRIPT
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