desarrollo de software - departamento de...
TRANSCRIPT
1
Desarrollo de Software
Arquitecturas de Sistemas TelemáticosDr. Ing. Álvaro Rendón Gallón
Cali, mayo de 2012
Especialización en Telemática
Temario
• 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
• 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
2
2
Tarea 1
Ordenar los datos de una tabla usando el algoritmo de ordenamiento de burbuja
3
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
Desarrollar un juego en red para dos jugadores
4
Cliente
3
Problemas del Software
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.
5
Un error de USD 500 millones
• 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.
6
4
Desarrollo de aplicaciones Web 7
HTMLHTMLHTML
CGIServletASP
Base de Datos
Servidor WebNavegador
HTTP
JavaScripts
I IOPDCOM
AppletsActiveX
Servidor deAplicaciones
…y de Web 1.0 a Web 2.0 8
HTMLHTMLHTML
Servidor WebNavegador
Base de Datos
Aplicaciones
Usuario AdministradorCONSULTA
Web 1.0 Actualización
HTMLHTMLHTML
Servidor WebNavegador
Base de Datos
Aplicaciones
Usuario PRODUCCIÓN/CONSULTA
Web 2.0
REDES SOCIALESWIKISBLOGS …
5
Arquitectura a 3 niveles 9
Cliente
Servidor deBases de Datos
Interfaz de usuario
Gestión de procesos (Lógica del negocio)
Gestión de los Datos
Nivel 1
Nivel 2
Nivel 3
3-tier
Servidor deAplicaciones
Arquitectura de Google (aproximación) 10
Servidor WebServidor
WebServidor Web
Navegador
HTTP
Internet
Base de DatosBase de
DatosBase de Datos
Servidor deAplicacionesServidor de
AplicacionesServidor deAplicaciones
Google Architecturehttp://highscalability.com/google-architecture
Nivel 1
Nivel 3
Nivel 2
6
Por qué modelar? 11
Uso creciente de Internet como proveedor de múltiples servicios
Internet
Consideraciones para el desarrollo
• Alta gerencia• Público• Otras empresas• Diseñadores gráficos• Comunicadores• Abogados• ...• Equipo de desarrollo
12
Diversidad de participantes en el desarrollo de las aplicaciones
7
Consideraciones para el desarrollo 13
• Negocio• Tecnologías
Continua evolución de las aplicaciones“una aplicación Web estancada está muerta” (Booch)
Consideraciones para el desarrollo 14
Las aplicaciones deben cumplir con características exigentes: Calidad
• 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.
• Fiable: Capacidad de ofrecer los mismos resultados bajo las mismas condiciones.
8
Consideraciones para el desarrollo 15
• 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.
• Fiable: Capacidad de ofrecer los mismos resultados bajo las mismas condiciones.
Las aplicaciones deben cumplir con características exigentes: Calidad
• Adaptable (extensibilidad): Modificar alguna función sin que afecte a sus actividades.
• Inteligible: Diseño claro, bien estructurado y documentado.
(en suma) Mantenible:
El software debe evolucionar para adaptarse a las necesidades cambiantes
• Portable: Capaz de integrarse en entornos distintos con el mismo esfuerzo.
Consideraciones para el desarrollo 16
• Adaptable (extensibilidad): Modificar alguna función sin que afecte a sus actividades.
• Inteligible: Diseño claro, bien estructurado y documentado.
(en suma) Mantenible:
El software debe evolucionar para adaptarse a las necesidades cambiantes
• Portable: Capaz de integrarse en entornos distintos con el mismo esfuerzo.
Las aplicaciones deben cumplir con características exigentes: Calidad
• Reutilizable (reusabilidad): Facilidad que ofrece para usar sus funcionalidades o componentes en nuevos proyectos
• No Erróneo: No exista diferencia entre los valores reales y los calculados.
• Oportuno
• Económico
9
Proceso de Desarrollo
• El desarrollo de aplicaciones requiere contar con herramientas conceptuales y metodológicas, además de las informáticas
17
• En general, un Proceso define QUIÉNestá 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
• 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
18
10
Proceso de Desarrollo de Software
• 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– Corrección, Adaptación,
Mejora y Prevención
19
Fases genéricas:
DEFINICIÓN
DESARROLLO
MANTENIMIENTO
Proceso de Desarrollo en V 20
Pruebas de Integración
Pruebas de Sistema
Pruebas de Aceptación
Plan de Pruebas de Aceptación
Plan de Pruebas de Integración
Plan de Pruebas del Sistema
Módulos probados
Sistema Entregado
Sistema Probado
Sistema Integrado
Diseño del Sistema
Requisitos del Sistema
Especificación del Sistema
Captura de Requisitos
Especificación
Diseño
Implementación y Pruebas de
Unidad
11
Validación temprana 21
Análisis Preliminar
del Sistema
Producción y Entrega
Arquitecturadel Sistema
Elaboración de Componentes
Base de Datos
Pruebas de Especificación
Pruebas de Componente
Pruebas de Producto
Pruebas de Diseño e
Integración
Nivel de Sistema
Nivel de Componente
Solicitud deNuevasTecnologías
Solicitud deNuevosComponentes
Modelado/Codificación 22
Tiempo
Tamaño
Proyectos pequeños (sólo código)
Código
12
Modelado/Codificación 23
Tiempo
Desarrollo en Cascada
Tamaño
Modelos Código
Modelado/Codificación 24
RequisitosAnálisis
DiseñoImplementación
Pruebas
Tiempo
Tamaño
Desarrollo Incremental
13
Modelado/Codificación 25
Tiempo
Tamaño
Desarrollo basado en Modelos
RequisitosAnálisis
DiseñoPruebas Transformación
Pruebas
(“Software model checking takes off”, Miller et al., 2010)
Modelado/Codificación 26
Codificación
Tiempo
Tamaño
Método Ágil
RequisitosMetáfora
Pruebas
14
Proceso de Desarrollo de Software
Dos paradigmas de desarrollo:
• Desarrollo basado en modeladoProceso Unificado de Desarrollo
RUP: Rational Unified ProcessThe “three amigos”: Booch, Rumbaugh, Jacobson
• Desarrollo basado en construcción de códigoProgramación Extrema
XP: eXtreme ProgrammingKent Beck
27
Proceso Unificado de Desarrollo
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
28
15
Proceso Unificado de Desarrollo 29
Organización por Organización en el tiempo
COMPONENTES DE SOPORTE
COMPONENTES DEL PROCESO
Iteraciones
Inicial
Gestación Preparac. Construcción Transición
Prep.#1
Prep.#2
Const.#1
Const.#2
Const.#N
Trans.#1
Trans.#2
FASESComponentes
Captura de Requisitos
Análisis
Diseño
Implementación
Pruebas
Puesta en Servicio
Modelado de la Organización
Gestión de Configuración y Cambios
Gestión del Proyecto
Entorno
Hitos
Arquitectura!Arquitectura!
Programación Extrema
• Planificación
• Versiones pequeñas
• Metáfora*
• Diseño simple
• Pruebas
• Recodificación
• 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
Prácticas:
* “sustituye mucho de lo que otra gente llama ‘arquitectura’”(K. Beck)
16
Programación Extrema 31
http://www.extremeprogramming.org/
Arquitectura!Arquitectura!
Papel de la Arquitectura
Arquitectura:
Aspecto central en el desarrollo de una aplicación
¿Qué es la arquitectura?
• Arquitectura se refiere a la representación abstractade 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”
32
17
Papel del modelado
Modelo:– “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• 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.
34