Desarrollo de Software - Departamento de Telemáticadtm.unicauca.edu.co/esptelematica-cali/Arquitecturas/transp/1.0... · • RUP y XP • Arquitectura y Modelado 2. 2 Tarea 1 Ordenar

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


Base de Datos

Aplicaciones

Usuario AdministradorCONSULTA

Web 1.0 Actualización

HTMLHTMLHTML


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)


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


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


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


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


• 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


• 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


Tiempo

Desarrollo en Cascada

Tamaño

Modelos Código


RequisitosAnálisis

DiseñoImplementación

Pruebas

Tiempo

Tamaño

Desarrollo Incremental

13


Tiempo

Tamaño

Desarrollo basado en Modelos

RequisitosAnálisis

DiseñoPruebas Transformación

Pruebas

(“Software model checking takes off”, Miller et al., 2010)


Codificación

Tiempo

Tamaño

Método Ágil

RequisitosMetáfora

Pruebas

14


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

Documents

Desarrollo de Software - Departamento de Telemáticadtm.unicauca.edu.co/esptelematica-cali/Arquitecturas/transp/1.0... · • RUP y XP • Arquitectura y Modelado 2. 2 Tarea 1 Ordenar