Diciembre 2008
Iván Párraga García
[email protected]
V1.1
Ingeniería del Software y Metodologías
2
Índice
1.
El problema. ¿Por qué es tan difícil desarrollar software?
2. Arquitectura de Aplicaciones. ¿Cómo organizamos el caos?
3. Metodologías. ¿Pero no podemos empezar a programar
directamente?
4. Entornos y herramientas. ¡Vamos a la guerra!
3
¿Por qué es tan difícil desarrollar software?
4
¿Qué vamos a ver?
 La problemática de la construcción de
software
 La ingeniería del software como
solución
 Partes fundamentales de la ingeniería
del software
 Ciclos de vida de construcción de
software
5
Crisis del Software
 Término acuñado en 1968 en la 1ª conferencia sobre
desarrollo de software organizada por la OTAN
 “Dificultad en escribir programas libres de defectos,
fácilmente comprensibles, y que sean verificables. Las
causas son, entre otras, la complejidad que supone la
tarea de programar y los cambios a los que se tiene que
ver sometido un programa para ser continuamente
adaptado a las necesidades de los usuarios”
[Wikipedia]
6
Resultado Proyectos Informáticos
Usado despues de
cambios
3% 2%
Usado como se entregó
19%
29%
47%
Entregado pero nunca
usado satisfactoriamente
Pagado pero no entregado
Fuente: Oficina de Cuentas del G. Norteamericano, 1979
[GAO, 1979]
Usado pero ampliamente
modificado o abandonado
después
7
Problemas y Causas
 Problemas
 Proyectos fuera de plazo
 Desajuste con el
presupuesto
 Baja calidad
 No cumplir las
especificaciones
 Código no mantenible
 Causas
 Disciplina joven
 Naturaleza del software
 Complejidad
 Gestión
8
¿Solución? Ingeniería del software
 “Trata del establecimiento de los principios y métodos de la
ingeniería a fin de obtener software de modo rentable, que sea
fiable y trabaje en máquinas reales” (Bauer, 1972)
 “Aplicación práctica del conocimiento científico al diseño y
construcción de programas de computadora y a la
documentación asociada requerida para desarrollar, operar y
mantenerlos. Se conoce también como Desarrollo de Software
o Producción de Software” (Bohem, 1976)
 “Es el estudio de los principios y metodologías para el
desarrollo y mantenimiento de sistemas software” (Zelkovitz,
1978)
 “Aplicación de un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento del
software; es decir, la aplicación de la ingeniería al software”
(IEEE, 1993)
9
Un ingeniero…
 Dispone de herramientas, técnicas y





metodologías probadas
Se preocupa de la fiabilidad y el
rendimiento
Reduce costes y complejidad
Realiza modelos y prototipos basados
en teorías sólidas y estándar
Utiliza diagramas formales
Documenta de forma adecuada
10
Factores de calidad y conflictos
Flexibilidad
X
-
X
Integridad
X
X
-
Mantenibilidad
X
Portabilidad
X
-
X
Testabilidad
X
Usabilidad
X
Interoperabilidad
X
X
X
X
X
X
X
X
-
X
X
X
X
-
Reusabilidad
X
X
-
X
X
X
Fiabilidad
Actualidad
Interoperabilidad
X
Usabilidad
Portabilidad
X
Testabilidad
Mantenibilidad
X
Reusabilidad
Integridad
X
Actualidad
Flexibilidad
-
Fiabilidad
Eficiencia
Eficiencia
X
X
X
-
X
X
X
11
¿Se garantiza el éxito?
 Ingeniería todavía joven
 Muchas metodologías diferentes y a veces
contrapuestas
 La industria todavía no se ha puesto de acuerdo sobre
cuál es LA metodología
 Aplicar una metodología y unas buenas prácticas, al
menos garantizan una conciencia de lo qué se hace,
permite tener unas métricas de calidad
 La ausencia GARANTIZA el FRACASO
12
Ciclo de vida
 Para obtener un producto software final se
distinguen una serie de fases diferenciadas
 El conjunto de estas fases, cómo se organizan y
cómo se relacionan es lo que se conoce como el
ciclo de vida del software
 Existen diferentes ciclos de vida
13
Proceso Ingeniería – C. Vida Clásico
Análisis
Análisis
Generación
Especificación
Selección
Diseño
Especificación
Implementación
Implementación
Pruebas
Mantenimiento
Mantenimiento
14
Ciclo de vida: algunas definiciones
 Análisis y toma de requerimientos (analistas)
 Consiste en determinar qué ha de hacer el sistema
 Especificación (analistas)
 Formalización de los requerimientos
 Diseño (arquitectos)
 Elección de la arquitectura y planificación del sistema
 Implementación (programadores)
 Codificación del sistema
 Testing (testers)
 Verificación de que todo funcionar conforme a la especificación
 Instalación (deployers)
 Mantenimiento (explotación)
15
Ciclo de vida en cascada (I)
Análisis
Especificación
Diseño
Implementación
Pruebas
 El más tradicional
 No se empieza una fase
hasta que ha acabado
la anterior
 Cada fase genera
documentación que es
la entrada de la
siguiente
 Cada fase puede tener
personal especializado
Mantenimiento
16
Ciclo de vida en cascada (II)
 Ventajas
 Planificación “sencilla”
 Inconvenientes
 Normalmente los
 Calidad del producto
 Permite trabajar con perfiles
con grados de especialización
(y sueldos) diferentes en cada
fase





requerimientos nunca están
al 100% bien definidos
Si ha habido errores, es difícil
volver a una fase anterior
No hay producto hasta el
final
Difícil determinar el
progreso real
Lento
Mayor coste
17
Ciclo de vida iterativo (I)
Análisis
Análisis
Especificación
Especificación
Diseño
Diseño
Implementación
Implementación
Pruebas
Pruebas
Versión 1
Versión 2
18
Ciclo de vida iterativo (II)
 Ventajas
 Planificación sencilla
 Calidad del producto
 Permite trabajar con personal
poco cualificado en algunas
etapas
 Se tienen versiones antes de
acabar el proyecto
 Disminuye los problemas por
toma de requerimientos
incorrecta
 Inconvenientes
 No hay producto hasta el
final
 Difícil determinar el
progreso real
 Lento
 Mayor coste
19
Prototipaje (I)
 Se construye un prototipo antes de hacer el
producto final
 Útil cuando se usan nuevas tecnologías o que no se
conocen o cuando los requerimientos son muy
vagos
 Permite evaluar si la solución adoptada es
satisfactoria antes de implementar toda la
funcionalidad
20
Prototipaje (II)
Especificaciones
incompletas
Selección del
prototipo
Especificaciones
completas
Desarrollo del
prototipo
Evaluación del
prototipo
Fase de prototipado
21
Ciclo de vida evolutivo
 Se usa en proyectos
donde se van
conociendo los
requerimientos poco a
poco
 En cada iteración se
implementa el
requerimiento que se
conoce
 Al final de cada
iteración tenemos una
versión
22
Ciclo de vida en espiral
 Conocemos todos los
requerimientos al
principio (no es
evolutivo)
 En cada iteración:
 Planificación: selección
de requerimientos
 Análisis de riesgos
 Implementación
 Evaluación por parte del
cliente
23
¿Qué hemos visto?
 En 1969 se acuñó el término Crisis del
Software y nació el embrión de la
ingeniería del software
 La ingeniería del software es una
disciplina joven pero madura que intenta
superar la crisis del software
 Un ingeniero tiene herramientas y
métodos para solucionar problemas
 Se definen diferentes ciclos de vida para
construir software
24
Bibliografía
 [Wikipedia]
 http://en.wikipedia.org/wiki/Software_crisis
 [GAO, 1979] Estudio de la Oficina de Cuentas del
Gobierno de Estados Unidos sobre el desarrollo del
software
 Enginyeria del Software Especificació, Dolors Costat, M.
Ribera Sancho, Ernest Teniente, Edicions UPC (2002)
25
¿Cómo organizamos el caos?
26
¿Qué vamos a ver?
 Componentes de un sistema
 Evolución y tipos de arquitecturas
 Patrones de diseño
27
¿Arquitectura software?
 Los diferentes subcomponentes de un sistema de
información
 Cómo se organizan y
relacionan estos
componentes
28
Tipos de componentes
 Elementos de interfaz de usuario
 Interacción con el usuario
 Componentes de lógica de negocio
 Implementan las funciones de la aplicación
 Bases de datos
 Persistencia fiable de datos
 Conectores
 Integración de sistemas diferentes
 Protocolos
 “Lenguajes” que utilizan los diferentes sistemas para comunicarse
 Middleware
 Es el “pegamento” que une todos los componentes en entornos
distribuidos
29
Interfaces: consola
 Las primeras interfaces
eran todas así
 Algunas sistemas las
conservan por motivos
históricos
 Útiles para controlar
dispositivos (routers,
sensores, etc.) de
manera remota
30
Tipos de interfaces: GUI
 Las interfaces gráficas
de cualquier sistema de
ventanas actual
 Hoy día, casi
exclusivamente para
aplicaciones de
escritorio
31
Tipos de interfaces: web
 El usuario sólo necesita
un navegador web
 Por tanto:
independiente de la
plataforma
 Útil en entornos
distribuidos
32
Lógica de negocio
33
Bases de datos
 Se encargan de mantener
la persistencia de la
información
 Son resistentes a caídas del
sistema
 Muchos productos pero
lenguaje de interacción
común y estandarizado:
SQL
34
Conectores y protocolos
 Permiten que (sub)sistemas y componentes de
fabricantes diferentes puedan comunicarse
Conector
35
Middleware
 Es el software que integra, gestiona, arbitra todos los
subsistemas en entornos distribuidos
Aplicación
Screen
Scrape
Cola de
Mensajes
Aplicación
Sockets
Download
File
ORB
Download
File
Aplicación
Mensaje
Aplicación
Transaction
File
Aplicación
Screen
Scrape
Transaction
File
CICS Gateway
Aplicación
Screen
Scrape
Transaction
File
Aplicación
Sockets
Aplicación
APPC
Cola de
Transaction
Mensajes
File
Aplicación
Screen
Scrape
RPC
Aplicación
CICS Gateway
Mensaje
ORB
Download
File
Cola de
Mensajes
APPC
RPC
36
Evolución de la arquitectura
Tipo de Arquitectura
Servidores de la
empresa
HOST / Mainframe
SGBD
Lógica de
Negocio
Cliente / Servidor
SGBD
Lógica de
Negocio
Multi-capa
SGBD
Lógica de
Negocio
Máquinas del
Usuario
Terminal
Tonta
Lógica de
Negocio
Ordenador
Personal
Navegador
web
Clientes
Orientada al Servicio
(SOA)
SGBD
Lógica de
Negocio
Lógica de
Negocio
37
Arquitec. HOST / Mainframe (I)
 La persistencia de datos y la lógica de negocio
integrados en la mismo servidor
 El usuario tiene una terminal tonta (sin capacidad
de proceso) que le conecta al servidor
Terminales
tontas
Mainframe
(datos y lógica de negocio)
38
Arquitec. HOST / Mainframe (II)
Ventajas
Inconvenientes
 Administración sencilla de
 Complicado modificar o
las terminales
 Administración
centralizada del servidor
añadir funcionalidades
 Escalabilidad limitada:
solo el mainframe
procesa datos
 Baja reutilización de
código
 Nula interconexión de
sistemas
39
Arquitectura cliente / servidor (I)
 Las máquinas de los usuarios tienen capacidad de
cálculo y se comunican con un protocolo a medida
con el servidor
Ordenadores
personales
Servidor
(datos y lógica de negocio)
40
Arquitectura cliente / servidor (II)
Ventajas
Inconvenientes
 Se libera al servidor de
 Cada vez que se modifica
carga de trabajo ya que los
ordenadores del usuario
pueden hacer parte del
proceso
alguna funcionalidad en el
servidor hay que actualizar
todos los clientes
 Complicado modificar o
añadir funcionalidades
(datos y lógica mezclados)
41
Arquitectura multicapa (I)
 Sistemas especializados por tareas en los
servidores
 Los usuarios acceden mediante un navegador web
estándar
Presentación
SGBD
Lógica de Negocio
42
Arquitectura multicapa (II)
Ventajas
Inconvenientes
 Mantenible
 Sistemas separados por
responsabilidades
 Fácil añadir / modificar
funcionalidades
 Escalable: los diferentes
 Todavía es difícil integrarse
con sistemas más allá de la
empresa: no es un modelo
B2B
subsistemas pueden
dimensionarse
independientemente
 Mayor reusabilidad
 Fácil gestión de las máquinas
de los usuarios
43
Arquitectura Orientada al Servicio
 SOA = Service Oriented Architecture
 No tan nueva tecnología pero que esta en estado de
madurez en la actualidad (está de moda)
44
SOA: ¿qué es un servicio?
 Servicio: es un bloque funcional que responde a
una necesidad de la organización
 Por ejemplo: “dar de alta empleado”
 Para usarlo se puede asumir:
 Invocación remota
 Interoperabilidad de plataformas diferentes
 Independencia de plataforma
45
SOA: Necesidades actuales
 Integración B2B (clientes / proveedores)
 Incrementar la agilidad de los sistemas de
información para que respondan igual de rápido
que los cambios del negocio: reducir el time to
market
 Reutilizar las funcionalidades existentes
 Crear nuevas funcionalidades
 Independencia de plataforma (lenguajes y SO)
 Datos y procesos distribuidos
46
SOA: La problemática existente
 Las organizaciones han ido añadiendo sistemas de
información a medida que los han necesitado
 Para integrar los sistemas se han hecho conectores 1 a 1
 Resultado: un caos no mantenible
Screen
Scrape
Aplicación
Download
Aplicación
File
Screen
Aplicación
Scrape
Sockets
Transaction
Screen
Transaction
File
Scrape
File
Aplicación
Sockets
Download CICS Gateway
RPC
ORB
File
Aplicación APPC
Mensaje
Aplicación
ORB
Cola de
Aplicación
Transaction
Mensajes
File
Aplicación
Cola de
Mensajes
CICS Gateway
Transaction Screen
Scrape
File
Download APPC
Mensaje
RPC
Aplicación
File
de
Aplicación Cola
Mensajes
47
SOA: La solución
 Los sistemas se ponen de acuerdo para “hablar” un
único “idioma”: webservices
 Sólo necesitamos conversores a este “idioma”
 Además los servicios son reusables y exportables
más allá de la organización
 SOA da respuesta tecnológica al BPM (Business
Process Management)
48
SOA: La foto
Los sistemas ofrecen sus
funcionalidades como
servicios
Servicios más generales
usan los diferentes
servicios
Procesos de negocio se
mapean con servicios
Servicio
Servicio
Servidor de
Aplicaciones
Servicio
Servicio
Servicio
ERP
(Enterprise resource
planning)
Servicio
Servicio
Proceso
Organización 2
Ejemplo: comprobar stock
Servicio
Servicio
SGBD
Servicio
Servicio
CRM
(Customer Relationship
Management)
Servicio
Servicio
Servicio
Proceso
Ejemplo: enviar promoción a cliente
Servicio
Servicio
CMS
(Content Management
System)
Servicio
Organización 1
49
¡Qué complicado!
 Múltiples componentes: interfaces, bases de datos,
conectores…
 Múltiples arquitecturas posibles
 Múltiples necesidades: satisfacer requerimientos,
eficiencia, mantenibilidad, usabilidad…
 Patrones al rescate
50
Patrones de diseño
 Algunos problemas de diseño de aplicaciones aparecen
una y otra vez: ¡hay que evitar reinventar la rueda!
 Los patrones de diseño son soluciones probadas y
basadas en la experiencia para problemas conocidos
 Es uno de los principales recursos de un arquitecto
software
 Existen diferentes catálogos de patrones
51
El catálogo de patrones del GoF
 [GoF ]= Gang of Four
 Fue el primer catálogo de
patrones de software
 Publicado en 1994 sigue siendo
un libro esencial que cualquier
arquitecto debería conocer
 Otros catálogo se basan en éste
52
Librerías (bibliotecas) y Frameworks
Biblioteca
Framework
 Conjunto de subrutinas o
 Representa una arquitectura
clases usadas para desarrollar
software
 Proporciona servicios a
programas independientes
sin forzar una arquitectura
concreta
 Por ejemplo una biblioteca
matemáticas puede
proporcionar subrutinas para
calcular ecuaciones
diferenciales
de software que modela las
relaciones generales de las
entidades de un dominio
 Define una forma de trabajar
para desarrollar un producto
software
 P. e. un framework para
desarrollo web puede “forzar”
el uso del patrón de diseño
M-V-C
53
¿Qué hemos visto?
 Un sistema software se compone de
múltiples componentes que se
relacionan entre sí
 La manera en que se relacionan estos
componentes definen una arquitectura
 Los patrones de diseño son soluciones
probadas que permiten definir
arquitecturas adecuadas para problemas
recurrentes
54
Bibliografía
 [GoF] Design Patterns, Elements of Reusable Object-
Oriented Software, Erich Gamma, Richard Helm, Ralph
Johnson, John Vlissides, Addison Wesley (30 ed, 2004)
55
¿Pero no podemos empezar a programar directamente?
56
¿Qué vamos a ver?
 Por qué las metodologías
tradicionales no son suficiente
 Metodologías ágiles
 TDD
57
Múltiples metodologías
 Como hemos visto existen diferentes ciclos de vida
 Existen distintas metodologías que se adaptan a cada
uno de los ciclos de vida
 ¿Cuál es la buena? Discusión sin fin en la industria
 Veamos cuál es el problema…
58
Proceso Ingeniería – C. Vida Clásico
Análisis
Análisis
Generación
Especificación
Selección
Diseño
Especificación
Implementación
Implementación
Pruebas
Mantenimiento
Mantenimiento
59
El ciclo de vida en cascada…
 Mapea en el desarrollo del software con el proceso de
ingeniería tradicional
 En muchos casos no ha sido una solución para superar
la crisis del software
 Al desarrollo del software no se le puede aplicar el
proceso de ingeniería tradicional porque las premisas
en las que se basa no son ciertas en este ámbito
60
Premisas del proceso de ingeniería
Ingeniería civil
Ingeniería del software
 Los requerimientos cambian
 Los requerimientos no
constantemente (quiero añadir un
cambian (debe medir 50 m)
nuevo listado y el anterior no me sirve)
 Los diferentes perfiles tienen
grados de cualificación muy
diferenciados (el albañil “sólo”
necesitan una visión global (el
programador debe entender la arquitectura
para no introducir defectos)
tiene que poner ladrillos y cemento)
 Es fácil medir el progreso del
proyecto (se tarda x horas en asfaltar
km)
 Los diferentes perfiles
z
 La naturaleza del software no
permite tener certeza del
progreso (síndrome del 95%)
61
Valores del manifiesto ágil [MA]
 Valorar más a las personas y su interacción que a los
procesos y las herramientas
 Valorar más el software que funciona que la
documentación exhaustiva
 Valorar más la colaboración con el cliente que la
negociación contractual
 Valorar más la respuesta al cambio que el seguimiento de
un plan
62
Principios del manifiesto (I)
Nuestra principal prioridad es satisfacer al cliente a
través de la entrega temprana y continua de software
de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si
llegan tarde al desarrollo. Los procesos ágiles se doblegan
al cambio como ventaja competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en
periodos de un par de semanas hasta un par de meses, con
preferencia en los periodos breves.
4. Las personas del negocio y los desarrolladores deben
trabajar juntos de forma cotidiana a través del proyecto.
1.
63
Principios del manifiesto (II)
Construcción de proyectos en torno a individuos
motivados, dándoles la oportunidad y el respaldo que
necesitan y procurándoles confianza para que realicen la
tarea.
6. La forma más eficiente y efectiva de comunicar
información de ida y vuelta dentro de un equipo de
desarrollo es mediante la conversación cara a cara.
7. El software que funciona es la principal medida del
progreso.
8. Los procesos ágiles promueven el desarrollo
sostenido. Los patrocinadores, desarrolladores y
usuarios deben mantener un ritmo constante de forma
indefinida.
5.
64
Principios del manifiesto (III)
9. La atención continua a la excelencia técnica
enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad
de trabajo que no se hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños
emergen de equipos que se auto-organizan.
12. En intervalos regulares, el equipo reflexiona sobre
la forma de ser más efectivo y ajusta su conducta en
consecuencia.
65
Metodologías ágiles
Agile
Crystal
66
67
¡Pero nosotros no tenemos clientes!
 El “cliente” es el usuario del software, por ejemplo otro
departamento de la compañía o nosotros mismos
 Aunque sea software de autoconsumo todas las
técnicas que definen las diferentes metodologías ágiles
siguen siendo aplicables
68
Prácticas ágiles
 Las distintas metodologías tienen diferentes prácticas
(aunque con un alto solapamiento)
 Las prácticas es el tipo de cosas que hace el equipo de
desarrollo para garantizar el cumplimiento de los
principios ágiles
 Diferentes prácticas son: iteraciones cortas, TDD,
programación en parejas, historias, integración
continua, diseño incremental, etc.
69
Historias
 Las historias son unidades de funcionalidad del
sistema que aportan valor al negocio
 Una historia tiene que ser lo suficientemente pequeña
para poder se desarrollada en una iteración
 Al principio de una iteración
 El cliente (el negocio) propone historias a desarrollar
 Los desarrolladores estiman el esfuerzo requerido
para implementar las historias (p.e. en horas de trabajo)
 El cliente organiza las historias a implementar en la
iteración sin superar el máximo esfuerzo disponible
en la iteración
70
Ciclo de vida e iteraciones
 Ciclo de vida en espiral
 Iteraciones son cortas (1 ó 2 semanas)
 Cada iteración genera
software listo para producción
 En cada iteración se llevan a cabo
todas las fases (análisis, especificación, diseño,
implementación…) para las pocas historias seleccionadas
 Los perfiles técnicos son más difusos (todo el mundo es
un poco arquitecto, diseñador, programador, tester…)
71
Programación en parejas
 Dos personas programando delante
del mismo ordenador
 Favorece la transmisión de conocimiento: no hay
profesionales indispensables, todo el equipo conoce todo el
sistema (se combate la “posesión del código” y el “profesional
imprescindible”)
 Favorece la uniformidad del código de acuerdo a unos formatos
o libros de estilo, lo que a su vez facilita el mantenimiento
 Toda línea de código ha sido revisada en el mismo momento
en el que se programado (evita la necesidad de arduas sesiones
de revisión de código)
72
TDD (Test Driven Development)
 Desarrollo guiado por las pruebas
 Los tests de validación del código se construyen antes
que la propia funcionalidad
 A continuación se escribe la
funcionalidad que debe superar el test
73
Ventajas del TDD (I)
 Todo el software está testeado
 Fija una manera de trabajar sistemática: escribir un test
y a continuación el código que lo supere y así
sucesivamente
 Obliga al desarrollador a pensar explícitamente qué debe
hacer exactamente la funcionalidad que va a implementar:
permite centrar el foco de atención
 Permite detectar tempranamente código que es difícil de
testear; ello generalmente implica un mal diseño
74
Ventajas del TDD (II)
 Confianza: evita el síndrome del “si funciona no lo toques”
 Doble validación: la misma
funcionalidad se ve desde dos puntos
de vista, el código y el test
 El conjunto de tests se convierten en una auténtica, valiosa
y mantenible fuente de documentación de qué debe hacer
el software y cómo debe hacerlo
75
Tipos de tests
 Tests unitarios: cada pieza software tiene una contraparte
que es un test que verifica que esa pieza software se
comporta de forma aislada como debe hacerlo
 Tests de integración: se verifica que varias piezas de
software que se relacionan entre sí lo hacen de manera
correcta
 Tests de aceptación: tests que permiten mostrar al
cliente (o usuario) que el software hace lo que se supone
que debería hacer
 Y más: estrés, regresión…
76
TDD ¿Más trabajo?
 Un pequeño esfuerzo adicional durante el desarrollo
que favorece la productividad en el corto plazo:
 Reducción de introducción de defectos (de manera
exponencial)
 Facilidad de mantenimiento (¡atrévete a tocar algo que
ya funciona!)
 ¡No estamos solos! Múltiples frameworks y
herramientas
77
Diseño incremental
 Se hará el diseño suficiente para implementar las
historias de la iteración
 Es un sobre-esfuerzo y una pérdida
de tiempo intentar adelantar
requerimientos que no conocemos
en ese momento
 Cuando sea necesario se refactorizarán aquellas partes
del sistemas que lo requieran
 La batería de tests permite combatir el síndrome de “no
toques lo que funciona que se rompe” (actúan como tests de
regresión)
78
¿Qué es la integración?
 Normalmente un sistema se construye por más de una
persona (o equipo)
 Cada desarrollador trabaja de forma
aislada en su código y su máquina
 En la fase de integración se pone en común el trabajo de
todos los desarrolladores
 Muchos problemas: las piezas no “encajan”, el testeo se
hace tedioso, se introducen defectos, siempre lleva más
tiempo del previsto (a veces MUCHO más), etc.
79
Integración continua
 Los desarrolladores integran muy a menudo (al menos una vez
al día) todo su trabajo
 Detecta malentendidos rápidamente
 La integración forma parte del trabajo
diario conviertiéndolo en un proceso
mucho más previsible que si fuera
un último gran paso
 Generalmente se tiene un entorno de integración
automatizado que informa de posibles problemas a los
desarrolladores tan pronto se producen
80
¿Qué hemos visto?
 Existen diferentes metodologías
 La aplicación directa del proceso de
ingeniería a la ingeniería del software no
funciona porque las premisas de ambos
modelos son diferentes
 El cambio de requerimientos es inevitable
 Las metodologías ágiles racionalizan la
gestión del cambio
81
Bibliografía
 Extreme Programming Explained, Kent Beck, Cynthia
Andres, Addison Wesley (2ª ed, 2004)
 [MA] http://agilemanifesto.org/
 [JUnit] http://www.junit.org/
 [NUnit] http://www.nunit.org/
 [Selenium] http://seleniumhq.org/
 [JMeter] http://jakarta.apache.org/jmeter/
82
83
¡Vamos a la guerra!
84
¿Qué vamos a ver?
 Entornos de desarrollo
 IDEs
 Plug-ins e integración de
herramientas
85
Necesidad de entornos diferentes
 Los desarrolladores del software, los que lo
mantienen, los que lo administran, etc., son personas
(incluso departamentos ) diferentes
 Varios desarrolladores pueden trabajar en el mismo
proyecto, ¿cómo se gestionan los cambios y
conflictos en el código?
 Desarrollar directamente sobre un sistema en
producción es potencialmente muy peligroso
86
Entornos: 1ª aproximación
Desarrollo
Integración
Preproducción
Producción
87
Repositorio de código (I)
 Gestiona de forma adecuada varios desarrolladores
trabajando sobre el mismo código ayudando a resolver
posibles conflictos
 Permite crear “fotos” del código en un momento dado
que se pueden recuperar en cualquier momento
(versiones)
 Permite crear “ramas” de código. Por ejemplo,
mantener tener una rama de desarrollo y otra para
corregir defectos de la versión en producción
88
Repositorio de código (II)
89
Entornos: 2ª aproximación
Integración
Preproducción
Producción
Testing
TRUNK
Versión 1
Nueva
Versión
Versión 1
Versión 1
Merge
90
Problemas
 Mantener varias versiones de código siempre es
complicado:
 Se pueden encontrar defectos en muchas fases
 Cuanto más tiempo pasa entre la creación de una rama y
el siguiente merge más se puede complicar todo
 Los desarrolladores tienen que hacer un “cambio
mental” cada vez que cambian de rama
 Se crea una sensación de confrontación entre
desarrolladores y testers (¡son el enemigo!) que puede
ser muy contraproducente
91
Servidor de integración continua
 Ya hemos visto que en un entorno ágil:
 Los desarrolladores integran como mínimo a diario
 Favorece la detección temprana de problemas y tener
una fase de integración más corta
 Un servidor de integración continua es una
herramienta que nos permite gestionar esta forma de
trabajar con un alto grado de automatización
 Funciona bien en un entorno TDD
92
Entornos: 1ª aproximación ágil
Repositorio
Test
Servidor de
Integración
Modificar
Test
e-mail
RSS
WEB
93
Entornos: 2ª aproximación ágil
Repositorio
Servidor de
Integración
¡Todo
Correcto!
Ups, algo está mal…
¡El código del repositorio
siempre funciona!
94
Entornos: aproximación ágil
Desarrollo
Integración
Producción
95
Entorno tradicional vs Entorno ágil
Tradicional
Ágil
 Múltiples ramas en el
 Minimiza la aparición de
repositorio
 Desarrolladores vs Testers
ramas en el repositorio
 Desarrolladores y Testers son
los mismos (comprensión)
 Síndrome “si ya funciona no
lo toques”
 Los tests unitarios actúan
como tests de regresión
(confianza) lo que facilita la
refactorización
96
Hudson
97
El IDE
 IDE = Integrated Development Environment
(Entorno de desarrollo Integrado)
 Facilita las diferentes fases más o menos complejas del
desarrollo del software en una misma herramienta
 Editar código
 Compilar / Enlazar / Construir
 Configurar bibliotecas
 Consultar documentación
 Integración con el repositorio
 Etc.
98
Tipos de IDEs
 Específicos para un lenguaje / plataforma
 De propósito general
 Configurables con plug-ins
99
Tipos de plug-ins para IDEs
 Métricas de calidad de código
 Métricas de estilo de código
Checkstyle
 Análisis de código
 Detección de defectos (bugs)
 Detección de estructuras peligrosas
 Plug-ins de testing y cobertura de código
Cobertura
100
Editor
Testings
101
Una posible configuración
Desarrollo
Repositorio
Servidor Integración
Checkstyle
Checkstyle
Cobertura
Cobertura
102
Hudson
103
¿Qué hemos visto?
 Es necesaria la existencia de diferentes
entornos
 Hay diferentes maneras de organizar los
entornos
 Los IDEs facilitan el trabajo del
desarrollador
 Una organización ágil es más minimalista e
integrada
104
Bibliografía
 Servidores de Integración
 [Hudson] https://hudson.dev.java.net/
 [CruiseControl] http://cruisecontrol.sourceforge.net/
 [TeamCity] http://www.jetbrains.com/teamcity/
 Entornos de Desarrollo Integrados
 [Elipse] http://www.eclipse.org/
 [NetBeans] http://www.netbeans.org/
 Herramientas de calidad y auditoría de código





[PMD] http://pmd.sourceforge.net/
[JUnit] http://www.junit.org/
[FindBugs] http://findbugs.sourceforge.net/
[CheckStyle] http://checkstyle.sourceforge.net/
[Cobertura] http://cobertura.sourceforge.net/
 Repositorios de control de código
 [CVS] http://ximbiot.com/cvs/wiki/
 [SVN] http://subversion.tigris.org/
 [Mercurial] http://www.selenic.com/mercurial/wiki/
105
¡Vamos a picar código!
Índice
5. Buenas prácticas. ¡Te lo dije! ¡Eso se podría haber evitado!
6. Programación Paralela. ¿Se pueden hacer dos cosas a la vez?
7. Asincronía y colas ¡Uy! Esto llevará algún tiempo, váyase a casa
y ya le avisaré
8. Midiendo. ¿Por qué #$%&@!€ esto funciona tan mal?
9. Definición de flujos
107
¡Te lo dije! ¡Eso se podría haber evitado!
108
¿Qué vamos a ver?
 Buenas prácticas generales
 Particularidades del software
científico
 Checkpoints
109
Programación modular
 Los programas monolíticos son difíciles de testear,
mantener y poco flexibles ante cambios
 Dividir el problema en subproblemas: análisis descendente
 Paradigma procedural -> módulos
 Paradiga de orientación a objetos -> clases bien definidas
 Los módulos o clases deberían ser:
 Altamente cohesivos: tareas muy concretas y especializadas
 Deberían presentar el mínimo acople entre sí
110
Documentación
 Cualquier desarrollo software debería estar
documentado para
 Facilitar el mantenimiento
 Poder mostrar a un nuevo miembro del equipo la
arquitectura del sistema
 Evitar el “chantaje del desarrollador imprescindible”
 La documentación puede ser de varios tipos
 En un lenguaje de modelado: UML
 Mediante baterías de tests de un desarrollo con TDD
111
¿Documentación automática?
 En un entorno ágil…
 … todo módulo tiene asociado una batería de tests
(unitarios, integración, aceptación) que constituye una
valiosa documentación
 … existe un servidor de integración que puede
configurarse para construir documentación de forma
automática mediante herramientas de ingeniería inversa
cada vez que construye el proyecto
Javadoc Tool
112
Particularidades del soft. científico
 Programas muy pesados
 Uso intensivo de CPU
 Necesidad de grandes cantidades de memoria
 Cálculos sin fin (por ejemplo la simulación)
 Software muy especializado
 En ocasiones desarrollado por perfiles sin
conocimientos profundos en desarrollo de software
113
Problemas y soluciones
Problema
Posibles soluciones
 Uso intensivo CPU
 Optimización, cálculo
distribuido
 Necesidad de mucha
memoria
 Cálculos muy largos (posibles
pérdidas de información)
 Falta de conocimiento técnico
 Uso eficiente de los recursos,
refactoring
 Introducción de checkpoints
 Formación, asesoría
114
Checkpoints, ¡os necesito!
1
2
Desarrollo del soft
6 meses de cálculo
4
Se pierde tiempo y
dinero
5
Ruedan cabezas
¡Se va la luz!
3
115
Checkpoints
 Consiste en salvar el estado de la ejecución del cálculo
de manera persistente
 En un disco duro
 En una base de datos
 En caso de desastre sólo se pierde la información desde
el último checkpoint
 Tiene un coste asociado en espacio y rendimiento: hay
que encontrar un equilibrio
116
¿Qué hemos visto?
 El código debe desarrollarse de manera modular
y los módulos deben ser altamente cohesivos y
estar acoplados al mínimo entre sí
 La documentación es una valiosa herramienta
que se puede automatizar en parte
 El software científico tiene ciertas
particularidades que estudiaremos en los
siguientes módulos
 Softwares con ejecuciones de larga duración
deberían utilizar checkpoints para poder
restaurar el estado en caso de desastre
117
Bibliografía
 [JavaDoc] http://java.sun.com/j2se/javadoc/
 [UMLGraph] http://www.umlgraph.org/
118
¿Se pueden hacer dos cosas a la vez?
119
¿Qué vamos a ver?
 Qué es la programación paralela
 Conceptos y clasificaciones
 Programación paralela
 Qué ayudas tiene el programador
120
Paralelismo: algunas definiciones
 Hilo de ejecución, thread y proceso se refieren a un
flujo de instrucciones que se ejecutan secuencialmente
 Un programa paralelo tiene varios hilos
 Ejecución concurrente vs ejecución paralela
121
¿Por qué programación paralela?
 Hay partes del software que no tienen dependencias
funcionales y que potencialmente se podrían calcular a
la vez (con la ganancia de tiempo que ello conlleva)
 Hoy día disponemos de máquinas con más de una CPU
y supercomputadores que nos permitirían explotar
estas circunstancias
 Hay aplicaciones que es más fácil pensarlas (y
programarlas) como tareas que se ejecutan en paralelo
122
Ejemplos de aplicaciones
 Operaciones sobre matrices
 Resolución de ecuaciones / integrales
 Procesamiento de imágenes
 Dinámica molecular
 Simulación de fluidos
 Etc.
123
Programación secuencial
 Un ordenador con una única CPU
 Un problema se divide en un conjunto de
instrucciones
 Las instrucciones se ejecutan secuencialmente
 Una instrucción ejecutada a cada ciclo de la CPU
Instrucciones
Problema
CPU
124
Programación paralela
Instrucciones
CPU
1
Subprob. 1
Problema
Descomposición: divide et impera
CPU
2
Subprob. 2
Instrucciones
125
Dependencias funcionales
X = CálculoPesado_1();
Y = CálculoPesado_2(X);
Z = CálculoPesado_3();
A = CálculoPesado_4(X, Z)
¿Cómo pasamos
información entre los
diferentes procesos?
Grafo de Dependencias
CalculoPesado_1
CalculoPesado_3
CalculoPesado_2
CalculoPesado_4
126
Arquitecturas paralelas
Mem. Compartida - UMA
Non-UMA
 Todas las CPUs comparten la
 Cada CPU tiene su espacio de
misma memoria
 El paso de información se
hace directamente en
memoria
memoria
 El paso de información se
tiene que hacer mediante
mensajería
Memoria
CPU
1
…
Memoria 1
CPU
N
CPU
1
…
Mensaje
…
Memoria N
CPU
N
127
No es trivial…
 Descomposición de tareas
 Sincronización de flujos
 Paso de información entre flujos
 Acceso simultáneo a recursos compartidos…
128
Pero no estamos solos…
 Algunos lenguajes tienen soporte nativo para hilos en
arquitecturas UMA (Delphi, Java, C#)
 Para otros lenguajes existen librerías bien conocidas
(con soporte para casi todos los lenguajes, incluyendo
C, C++, Fortran…)
 Modelos UMA: Pthreads, OpenMP
 Modelos N-UMA: MPI
129
Librerías declarativas
 Un lenguaje o una librería es declarativa cuando se dice qué
se quiere hacer pero no el cómo
 OpenMP y MPI son librerías declarativas
 El programador “etiqueta” qué partes deben ser ejecutadas
en paralelo, qué dependencias hay, qué información debe
compartirse
 La librería hace el “trabajo sucio” (creación de procesos de
sistema, gestión de la mensajería, abstracción de la red,
etc.)
130
¿Qué hemos visto?
 La programación paralela permite ejecutar más
de un flujo de ejecución de manera simultánea
 Hoy día, un mayor rendimiento no se consigue
mediante procesadores más rápidos sino con
una adecuada paralelización de las tareas
 El paradigma de programación paralela
introduce nuevas complejidades que hay que
considerar
 Existen lenguajes y librerías que ofrecen
abstracciones sobre estas complejidades
facilitando la vida al desarrollador
131
Bibliografía
 [Wikipedia]
 http://en.wikipedia.org/wiki/Parallel_computing
 [MPI] http://www-unix.mcs.anl.gov/mpi/
 [OpenMP] http://openmp.org/wp/
132
¡Uy! Esto llevará algún tiempo, váyase a casa y ya le avisaré
133
¿Qué vamos a ver?
 Sincronía vs asincronía
 Sistemas de colas
134
El problema (I): peticiones largas
Servidor Web
Clúster de Cálculo
www.icc.es
Cliente
Cliente
135
El problema (II): peticiones pesadas
memoria
136
Sincronía y asincronía
 Una llamada o petición síncrona
bloquea al llamador hasta que la
operación invocada no termina
 Una llamada o petición asíncrona devuelve el
control inmediatamente al llamador.
Tanto el llamador como la operación
llamada pueden mantener flujos de
ejecución separados y concurrentes
137
¿Cómo implementar la asincronía?
1.
El cliente (llamador) hace la petición asíncrona
2. El servidor encola la petición del cliente en una cola
de tareas a hacer
3. El servidor va ejecutando las tareas de la cola según
la carga que pueda soportar y las políticas que se
hayan definido (número de tareas simultáneas,
prioridades, etc.)
138
Políticas de notificación al cliente
 El servidor notifica al cliente la finalización de la tarea
(e-mail, rss, protocolo a medida, etc.)
 El cliente obtiene un identificador al hacer la petición
asíncrona y lo usa para ir preguntándole al servidor de
vez en cuando “¿has acabado mi tarea?” (es lo que se
conoce como notificación por encuesta)
139
Una posible implementación
6
Notificamos al cliente
Cola
1
Petición
3
2
Encolamos petición
“serás notificado”
4
El servidor procesa las tareas previas
5
El servidor procesa nuestra tarea
140
Tarea pesada distribuida
Nodos de Cálculo
5
1
2
Notificamos al cliente
Petición
“serás notificado”
Planificador de Tareas
3
planificación
4
ejecución
141
Productos
IBM - Tivoli Workload Scheduler
PBS
JMS
NQS
142
¿Qué hemos visto?
 En el modelo síncrono, llamador y
llamado están fuertemente acoplados
 Este acoplamiento puede ser no deseado
para tareas que consumen grandes
cantidades de tiempo o recursos
 El modelo asíncrono permite desacoplar
el llamador del llamado
143
Bibliografía
 [Wikipedia]
 http://en.wikipedia.org/wiki/Distributed_Resource_Manager
 [PBS] http://www.openpbs.org/
 [GridEngine] http://gridengine.sunsource.net/
 [Tivoli] http://www-01.ibm.com/software/tivoli/
products/scheduler/
 [SLURM] https://computing.llnl.gov/linux/slurm/
 [ASG-Zena] http://www.asg.com/products/
product_details.asp?code=ZNC
144
¿Por qué #$%&@!€ esto funciona tan mal?
145
¿Qué vamos a ver?
 Debugging
 Logging
 Profiling
 Benchmarking
146
Problemática
 Problemas funcionales: el software no hace lo que
debería hacer - debugging
 Problemas no funcionales: el software tiene un
rendimiento diferente al esperado o deseable profiling
 ¿Qué implicaciones tendría sustituir este subsistema
software o hardware? ¿qué mejora he obtenido al
refactorizar esta parte? - benchmarking
147
¡Medir antes de intentar arreglar!
 Necesitamos métricas (posiblemente proporcionadas
por herramientas) que nos digan
 qué debemos mejorar
 nos permitan decir cuánto
hemos mejorado con la solución adoptada
 Intentar arreglar algo ciegamente nos puede llevar a
perder tiempo (y dinero) por “arreglar” algo que no
era necesario tocar y por obviar lo que sí debería
haberse tocado
148
Debugging
 A veces el software no hace lo que se supone que
debería hacer
 Seguir el flujo del ejecución “a ojo”
puede resultar complicado
 La introducción de “chivatos”, ensucia el código y hace
difícil su mantenimiento
149
Debugger
 Un debugger es una herramienta que permite ejecutar
un programa paso a paso e inspeccionar el contenido
de variables y otras estructuras en tiempo de ejecución
 Dependiendo del lenguaje se requiere la activación de
algún flag en la fase de compilación, pero no es
necesario modificar el código
 Hoy día son herramientas gráficas integradas en el IDE
150
Threads
Comandos de ejecución
Modificadas en
el último paso
Valores de las variables
Línea en
ejecución
151
Logging (bitácoras)
 Consiste en registrar en un soporte persistente
(ficheros o base de datos) eventos relevantes en la
ejecución de un programa
 Problemas
 Trazas de uso
 Información de accounting
 Requiere modificar el código fuente del programa
152
Librerías de logging
 Existen librerías que permiten hacer un uso eficiente del
código de logging
 Gestión asíncrona de la escritura en los soportes para no
penalizar el rendimiento
Pantheios
 Múltiples niveles de logging (debug, warning, error, severe)
 Activación y desactivación de niveles de logging “en
caliente” (sin tener que apagar la aplicación)
log4tran
153
Cuellos de botella
 También conocidos como “bottlenecks” o “hot spots”
 Son aquellos puntos de un software
que limitan su rendimiento
 No siempre se corresponden con lo
que indica el sentido común
154
Profilers
 Son herramientas que analizan la ejecución de programas para
buscar cuellos de botella
 Muchas veces requieren la
instrumentalización del código para capturar
estadísticas en tiempo de ejecución
 Capturan información como:
 Estadísticas sobre tiempos de ejecución de una rutina
 Número de ejecuciones de una rutina
 Detectan el código donde hay que centrar los esfuerzos de
optimización: “(10.000 x 1) > (1 x 1000)”
155
Benchmarking
 Son procedimientos de comparación
 De alternativas
 Para medir la mejora al aplicar una solución
 Para medir la escalabilidad del sistema (tests de estrés)
SysBench
 De varios tipos
 “Full stack”: mide el rendimiento global de un sistema
software (caja negra)
 De componente: mide el rendimiento de un susbsistema
(caja blanca)
Database Test Suite
156
Todo junto
Debugger
Profiler
Presentación
1
Desarrollo del soft
2
Testing & Debugging
SGBD
vs
3
Profiling full stack
4
Benchmarking
Lógica de Negocio
157
¿Qué hemos visto?
 Durante la fase de desarrollo el debugger
puede ayudar a analizar posibles
problemas
 El uso de logging permite registrar
eventos interesantes en desarrollo o
producción
 Para optimizar un software es
importante tomar medidas mediante
profiling y benchmarking
158
Bibliografía
 [JMeter] http://jakarta.apache.org/jmeter/
159
160
¿Qué vamos a ver?
 Cómo poner en práctica todo lo
aprendido para construir flujos
robustos
 Definición de flujos o procesos
encajando todas las piezas
 Webservices como
implementación de una
arquitectura SOA de construcción
de flujos
161
Ejemplo de flujo (workflow)
Seleccionar
Proteína
Preparación
Equilibrado
SÍ
Ajuste de
Parámetros
Simulación
Análisis 1
…
Postsimulación
NO
Análisis N
162
Problemas: lenguajes diferentes
Seleccionar
Proteína
Preparación
Equilibrado
Ajuste de
Parámetros
FORTRAN
SÍ
Análisis 1
…
Simulación
Lenguajes Diferentes
Postsimulación
NO
Análisis N
163
Problemas: procesos pesados
Seleccionar
Proteína
Análisis 1
…
Preparación
Equilibrado
Proceso muySÍlargo en
hardware costoso
Postsimulación
Ajuste de
Parámetros
Simulación
NO
Análisis N
164
Problemas: ejecución paralela
Seleccionar
Proteína
Análisis 1
…
Preparación
Equilibrado
ProgramaciónSÍparalela
Postsimulación
Ajuste de
Parámetros
Simulación
NO
Análisis N
165
Problemas: modificación del flujo
Seleccionar
Proteína
Preparación
Equilibrado
SÍ
Ajuste de
Parámetros
Simulación
Análisis 1
…
Postsimulación
NO
Análisis N
166
Problemas: tareas largas
Seleccionar
Proteína
Preparación
Equilibrado
Tareas Asíncronas
SÍ
Ajuste de
Parámetros
Simulación
Análisis 1
…
Postsimulación
NO
Análisis N
167
¡Lo sabemos resolver todo!
Problema
Solución
 Integración de lenguajes
 “Envolver” los procesos
diferentes
 Procesos pesados y costosos
 Algoritmos complejos y/o tareas
mediante webservices
 Añadir “checkpoints”
 Programación paralela
sin dependencias
 Procesos largos que “bloquean”
 Uso de sincronía y colas
el flujo
 Modificación del workflow
 Herramientas de orquestación
de servicios y TDD
168
Webservices, ya hemos visto…
 Es una implementación de la arquitectura SOA
 Encapsulan un servicio (una unidad funcional)
 Actúan como un esperanto de los lenguajes de
programación (interoperabilidad e independencia de
la plataforma)
 Permiten invocación remota
169
La maraña de los webservices
SOAP
WSDL
XML
Document
RPC
UDDI
REST
Encoded
WS-I
Literal
BPEL
170
Interoperabilidad con webservices
FORTRAN
FORTRAN
Webservice
Webservice
171
Herramientas de workflows
 Permiten orquestar los servicios
 Construir workflows (posiblemente de manera visual)
 Modificar workflows en tiempo de ejecución
 Simular workflows
 Definir políticas, ¿qué pasa si un servicio…
 … falla?
 … no está disponible?
 … tarda más de lo que debiera?
 Monitorizar la ejecución de workflows
172
173
174
¿Qué hemos visto?
 La arquitectura SOA y los webservices
son una solución para construir y
gestionar flujos complejos
 Cada uno de los servicios puede hacer
uso de las técnicas que hemos visto a lo
largo del seminario
 Existen herramientas que permiten
trabajar con los workflows
amigablemente
175
Bibliografía
 [WS-I] Web Services Interoperability Organization -
http://www.ws-i.org/
 [BPEL-Eclipse] http://www.eclipse.org/bpel/
 [Taverna] http://taverna.sourceforge.net/
176
¿Preguntas?
177
Iván Párraga García
[email protected]
178
Descargar

descargar aquí