Ingeniera del Software y Construccin de Workflows - ICC
Desarrollo de Software y FlujosDiciembre 2008
Ivn Prraga [email protected]
1Parte 1Ingeniera del Software y Metodologas2
2El problema. Por qu es tan difcil desarrollar software?
Arquitectura de Aplicaciones. Cmo organizamos el caos?
Metodologas. Pero no podemos empezar a programar
directamente?
Entornos y herramientas. Vamos a la guerra!ndice33Mdulo 1El
ProblemaPor qu es tan difcil desarrollar software?
44La problemtica de la construccin de software
La ingeniera del software como solucin
Partes fundamentales de la ingeniera del software
Ciclos de vida de construccin de softwareQu vamos a ver?5
5Crisis del SoftwareTrmino acuado en 1968 en la 1 conferencia
sobre desarrollo de software organizada por la OTANDificultad en
escribir programas libres de defectos, fcilmente 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]66Resultado Proyectos
Informticos Fuente: Oficina de Cuentas del G. Norteamericano,
1979[GAO, 1979] 77Problemas y CausasProblemasProyectos fuera de
plazoDesajuste con el presupuestoBaja calidadNo cumplir las
especificacionesCdigo no mantenibleCausasDisciplina jovenNaturaleza
del softwareComplejidadGestin88Solucin? Ingeniera del softwareTrata
del establecimiento de los principios y mtodos de la ingeniera a
fin de obtener software de modo rentable, que sea fiable y trabaje
en mquinas reales (Bauer, 1972)
Aplicacin prctica del conocimiento cientfico al diseo y
construccin de programas de computadora y a la documentacin
asociada requerida para desarrollar, operar y mantenerlos. Se
conoce tambin como Desarrollo de Software o Produccin de Software
(Bohem, 1976)
Es el estudio de los principios y metodologas para el desarrollo
y mantenimiento de sistemas software (Zelkovitz, 1978)
Aplicacin de un enfoque sistemtico, disciplinado y cuantificable
al desarrollo, operacin y mantenimiento del software; es decir, la
aplicacin de la ingeniera al software (IEEE, 1993)
99Un ingeniero10
Dispone de herramientas, tcnicas y metodologas probadasSe
preocupa de la fiabilidad y el rendimientoReduce costes y
complejidadRealiza modelos y prototipos basados en teoras slidas y
estndarUtiliza diagramas formalesDocumenta de forma
adecuada10Factores de calidad y
conflictos11EficienciaFlexibilidadIntegridadMantenibilidadPortabilidadFiabilidadActualidadReusabilidadTestabilidadUsabilidadInteroperabilidadEficiencia-XXXXXXXXFlexibilidadX-XIntegridadXX-XXXMantenibilidadX-XXPortabilidadX-XFiabilidad-XActualidadXXX-XXReusabilidadXX-TestabilidadXXX-UsabilidadX-InteroperabilidadXXXX-11Ingeniera
todava jovenMuchas metodologas diferentes y a veces contrapuestasLa
industria todava no se ha puesto de acuerdo sobre cul es LA
metodologaAplicar una metodologa y unas buenas prcticas, al menos
garantizan una conciencia de lo qu se hace, permite tener unas
mtricas de calidadLa ausencia GARANTIZA el FRACASOSe garantiza el
xito?12
La ingeniera del software 12Para obtener un producto software
final se distinguen una serie de fases diferenciadas
El conjunto de estas fases, cmo se organizan y cmo se relacionan
es lo que se conoce como el ciclo de vida del software
Existen diferentes ciclos de vida
Ciclo de vida13
13
Proceso Ingeniera C. Vida
Clsico14AnlisisEspecificacinDiseoImplementacinPruebasMantenimientoAnlisisGeneracinSeleccinEspecificacinImplementacinMantenimiento
Comparacin del ciclo de vida clsico con respecto al proceso de
ingeniera14Anlisis y toma de requerimientos (analistas)Consiste en
determinar qu ha de hacer el sistemaEspecificacin
(analistas)Formalizacin de los requerimientosDiseo
(arquitectos)Eleccin de la arquitectura y planificacin del
sistemaImplementacin (programadores)Codificacin del sistemaTesting
(testers)Verificacin de que todo funcionar conforme a la
especificacinInstalacin (deployers)Mantenimiento (explotacin)Ciclo
de vida: algunas definiciones1515Ciclo de vida en cascada (I)El ms
tradicionalNo se empieza una fase hasta que ha acabado la
anteriorCada fase genera documentacin que es la entrada de la
siguienteCada fase puede tener personal
especializado16AnlisisEspecificacinDiseoImplementacinPruebasMantenimiento16Ciclo
de vida en cascada (II)VentajasPlanificacin sencillaCalidad del
productoPermite trabajar con perfiles con grados de especializacin
(y sueldos) diferentes en cada fase
InconvenientesNormalmente los requerimientos nunca estn al 100%
bien definidosSi ha habido errores, es difcil volver a una fase
anteriorNo hay producto hasta el finalDifcil determinar el progreso
realLentoMayor coste
1717Ciclo de vida iterativo
(I)18AnlisisEspecificacinDiseoImplementacinPruebasVersin
1AnlisisEspecificacinDiseoImplementacinPruebasVersin 218Ciclo de
vida iterativo (II) VentajasPlanificacin sencillaCalidad del
productoPermite trabajar con personal poco cualificado en algunas
etapasSe tienen versiones antes de acabar el proyectoDisminuye los
problemas por toma de requerimientos incorrectaInconvenientesNo hay
producto hasta el finalDifcil determinar el progreso realLentoMayor
coste
1919Se construye un prototipo antes de hacer el producto
final
til cuando se usan nuevas tecnologas o que no se conocen o
cuando los requerimientos son muy vagos
Permite evaluar si la solucin adoptada es satisfactoria antes de
implementar toda la funcionalidad
Prototipaje (I)2020Prototipaje (II)21Especificaciones
incompletasSeleccin del prototipoDesarrollo delprototipoEvaluacin
delprototipoEspecificaciones completasFase de prototipado21Ciclo de
vida evolutivoSe usa en proyectos donde se van conociendo los
requerimientos poco a pocoEn cada iteracin se implementa el
requerimiento que se conoce Al final de cada iteracin tenemos una
versin
22
22Ciclo de vida en espiralConocemos todos los requerimientos al
principio (no es evolutivo)En cada iteracin:Planificacin: seleccin
de requerimientosAnlisis de riesgosImplementacinEvaluacin por parte
del cliente23
23En 1969 se acu el trmino Crisis del Software y naci el embrin
de la ingeniera del softwareLa ingeniera del software es una
disciplina joven pero madura que intenta superar la crisis del
softwareUn ingeniero tiene herramientas y mtodos para solucionar
problemasSe definen diferentes ciclos de vida para construir
softwareQu hemos visto?24
24[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)
Bibliografa25
25Mdulo 2Arquitectura de aplicacionesCmo organizamos el
caos?26
26Componentes de un sistema
Evolucin y tipos de arquitecturas
Patrones de diseoQu vamos a ver?27
27
Los diferentes subcomponentes de un sistema de informacin
Cmo se organizan y relacionan estos componentes Arquitectura
software?2828Elementos de interfaz de usuarioInteraccin con el
usuarioComponentes de lgica de negocioImplementan las funciones de
la aplicacinBases de datosPersistencia fiable de
datosConectoresIntegracin de sistemas diferentesProtocolosLenguajes
que utilizan los diferentes sistemas para comunicarseMiddlewareEs
el pegamento que une todos los componentes en entornos
distribuidos
Tipos de componentes2929Interfaces: consolaLas primeras
interfaces eran todas as
Algunas sistemas las conservan por motivos histricos
tiles para controlar dispositivos (routers, sensores, etc.) de
manera remota30
30Tipos de interfaces: GUILas interfaces grficas de cualquier
sistema de ventanas actual
Hoy da, casi exclusivamente para aplicaciones de
escritorio31
31Tipos de interfaces: webEl usuario slo necesita un navegador
web
Por tanto: independiente de la plataforma
til en entornos distribuidos32
32Lgica de negocio33
33Bases de datosSe encargan de mantener la persistencia de la
informacin
Son resistentes a cadas del sistema
Muchos productos pero lenguaje de interaccin comn y
estandarizado: SQL34
34Permiten que (sub)sistemas y componentes de fabricantes
diferentes puedan comunicarse
Conectores y protocolos35
ConectorConectorConector35Es el software que integra, gestiona,
arbitra todos los subsistemas en entornos
distribuidosMiddleware36ScreenScrapeScreenScrapeScreenScrapeScreenScrapeCola
deMensajesCola deMensajesCola
deMensajesDownloadFileDownloadFileDownloadFileTransactionFileTransactionFileTransactionFileORBORBCICS
GatewayCICS
GatewayAPPCAPPCRPCRPCTransactionFileSocketsSocketsMensajeMensajeAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacin
36Evolucin de la arquitectura37
37La persistencia de datos y la lgica de negocio integrados en
la mismo servidorEl usuario tiene una terminal tonta (sin capacidad
de proceso) que le conecta al servidor
Arquitec. HOST / Mainframe (I)38
Terminales tontasMainframe(datos y lgica de negocio)38Arquitec.
HOST / Mainframe (II)VentajasInconvenientesAdministracin sencilla
de las terminales
Administracin centralizada del servidorComplicado modificar o
aadir funcionalidadesEscalabilidad limitada: solo el mainframe
procesa datosBaja reutilizacin de cdigoNula interconexin de
sistemas3939Las mquinas de los usuarios tienen capacidad de clculo
y se comunican con un protocolo a medida con el
servidorArquitectura cliente / servidor (I)40
Servidor(datos y lgica de negocio)
Ordenadores personales40Arquitectura cliente / servidor
(II)VentajasInconvenientesSe libera al servidor de carga de trabajo
ya que los ordenadores del usuario pueden hacer parte del
procesoCada vez que se modifica alguna funcionalidad en el servidor
hay que actualizar todos los clientes
Complicado modificar o aadir funcionalidades (datos y lgica
mezclados)4141Sistemas especializados por tareas en los
servidoresLos usuarios acceden mediante un navegador web
estndarArquitectura multicapa (I)42
SGBDLgica de NegocioPresentacin42Arquitectura multicapa
(II)VentajasInconvenientesMantenibleSistemas separados por
responsabilidadesFcil aadir / modificar funcionalidadesEscalable:
los diferentes subsistemas pueden dimensionarse
independientementeMayor reusabilidadFcil gestin de las mquinas de
los usuariosTodava es difcil integrarse con sistemas ms all de la
empresa: no es un modelo B2B
4343SOA = Service Oriented Architecture
No tan nueva tecnologa pero que esta en estado de madurez en la
actualidad (est de moda)Arquitectura Orientada al Servicio44
44Servicio: es un bloque funcional que responde a una necesidad
de la organizacinPor ejemplo: dar de alta empleadoPara usarlo se
puede asumir:Invocacin remotaInteroperabilidad de plataformas
diferentesIndependencia de plataformaSOA: qu es un
servicio?4545Integracin B2B (clientes / proveedores)Incrementar la
agilidad de los sistemas de informacin para que respondan igual de
rpido que los cambios del negocio: reducir el time to
marketReutilizar las funcionalidades existentesCrear nuevas
funcionalidadesIndependencia de plataforma (lenguajes y SO)Datos y
procesos distribuidosSOA: Necesidades actuales4646Las
organizaciones han ido aadiendo sistemas de informacin a medida que
los han necesitadoPara integrar los sistemas se han hecho
conectores 1 a 1Resultado: un caos no mantenibleSOA: La problemtica
existente47ScreenScrapeScreenScrapeScreenScrapeScreenScrapeCola
deMensajesCola deMensajesCola
deMensajesDownloadFileDownloadFileDownloadFileTransactionFileTransactionFileTransactionFileORBORBCICS
GatewayCICS
GatewayAPPCAPPCRPCRPCTransactionFileSocketsSocketsMensajeMensajeAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacinAplicacin47Los
sistemas se ponen de acuerdo para hablar un nico idioma:
webservicesSlo necesitamos conversores a este idiomaAdems los
servicios son reusables y exportables ms all de la organizacinSOA
da respuesta tecnolgica al BPM (Business Process Management)SOA: La
solucin4848SOA: La foto49
49Mltiples componentes: interfaces, bases de datos,
conectores
Mltiples arquitecturas posibles
Mltiples necesidades: satisfacer requerimientos, eficiencia,
mantenibilidad, usabilidad
Patrones al rescateQu complicado!50
50Algunos problemas de diseo de aplicaciones aparecen una y otra
vez: hay que evitar reinventar la rueda!
Los patrones de diseo son soluciones probadas y basadas en la
experiencia para problemas conocidos
Es uno de los principales recursos de un arquitecto software
Existen diferentes catlogos de patronesPatrones de diseo51
51El catlogo de patrones del GoF[GoF ]= Gang of Four
Fue el primer catlogo de patrones de software
Publicado en 1994 sigue siendo un libro esencial que cualquier
arquitecto debera conocer
Otros catlogo se basan en ste52
52Libreras (bibliotecas) y FrameworksBibliotecaFrameworkConjunto
de subrutinas o clases usadas para desarrollar softwareProporciona
servicios a programas independientes sin forzar una arquitectura
concretaPor ejemplo una biblioteca matemticas puede proporcionar
subrutinas para calcular ecuaciones diferencialesRepresenta una
arquitectura de software que modela las relaciones generales de las
entidades de un dominioDefine una forma de trabajar para
desarrollar un producto softwareP. e. un framework para desarrollo
web puede forzar el uso del patrn de diseo M-V-C5353Un sistema
software se compone de mltiples componentes que se relacionan entre
s
La manera en que se relacionan estos componentes definen una
arquitectura
Los patrones de diseo son soluciones probadas que permiten
definir arquitecturas adecuadas para problemas recurrentesQu hemos
visto?54
54[GoF] Design Patterns, Elements of Reusable Object-Oriented
Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,
Addison Wesley (30 ed, 2004)Bibliografa55
55Mdulo 3MetodologasPero no podemos empezar a programar
directamente?56
56Por qu las metodologas tradicionales no son suficiente
Metodologas giles
TDD
Qu vamos a ver?57
57Como hemos visto existen diferentes ciclos de vida
Existen distintas metodologas que se adaptan a cada uno de los
ciclos de vida
Cul es la buena? Discusin sin fin en la industria
Veamos cul es el problemaMltiples metodologas5858
Proceso Ingeniera C. Vida
Clsico59AnlisisEspecificacinDiseoImplementacinPruebasMantenimientoAnlisisGeneracinSeleccinEspecificacinImplementacinMantenimiento
Comparacin del ciclo de vida clsico con respecto al proceso de
ingeniera59Mapea en el desarrollo del software con el proceso de
ingeniera tradicional
En muchos casos no ha sido una solucin para superar la crisis
del software
Al desarrollo del software no se le puede aplicar el proceso de
ingeniera tradicional porque las premisas en las que se basa no son
ciertas en este mbitoEl ciclo de vida en cascada6060
Premisas del proceso de ingenieraIngeniera civilIngeniera del
softwareLos requerimientos no cambian (debe medir 50 m)
Los diferentes perfiles tienen grados de cualificacin muy
diferenciados (el albail slo tiene que poner ladrillos y
cemento)
Es fcil medir el progreso del proyecto (se tarda x horas en
asfaltar z km)Los requerimientos cambian constantemente (quiero
aadir un nuevo listado y el anterior no me sirve)
Los diferentes perfiles necesitan una visin global (el
programador debe entender la arquitectura para no introducir
defectos)
La naturaleza del software no permite tener certeza del progreso
(sndrome del 95%)6161
Valorar ms a las personas y su interaccin que a los procesos y
las herramientas
Valorar ms el software que funciona que la documentacin
exhaustiva
Valorar ms la colaboracin con el cliente que la negociacin
contractual
Valorar ms la respuesta al cambio que el seguimiento de un plan
Valores del manifiesto gil [MA]62En marzo de2001diecisiete crticos
de los modelos de mejora deldesarrollo de softwarebasados en
procesos, convocados porKent Beck, quien haba publicado un par de
aos antesExtreme Programming Explained, libro en el que expona una
nueva metodologa denominadaExtreme Programming, se reunieron enSalt
Lake Citypara tratar sobre tcnicas y procesos para desarrollar
software. En la reunin se acu el trmino Mtodos giles para definir a
los mtodos que estaban surgiendo como alternativa a las metodologas
formales (CMMI,SPICE) a las que consideraban excesivamente pesadas
y rgidas por su carcter normativo y fuerte dependencia de
planificaciones detalladas previas al desarrollo.Los integrantes de
la reunin resumieron los principios sobre los que se basan los
mtodos alternativos en cuatro postulados, lo que ha quedado
denominado como Manifiesto gil.Hasta 2005 han sido frecuentes las
posturas radicales entre los defensores de los modelos de procesos
y los defensores de modelos giles, quiz ms ocupados en descalificar
al otro que en estudiar sus mtodos y conocerlos para mejorar los
propios.
Manifiesto gil, firmado porKent Beck,Mike Beedle,Arie van
Bennekum,Alistair Cockburn,Ward Cunningham,Martin Fowler,James
Grenning,Jim Highsmith,Andrew Hunt,Ron Jeffries,Jon Kern,Brian
Marick,Robert C. Martin,Steve Mellor,Ken Schwaber,Jeff
SutherlandyDave Thomas
Valores del Manifiesto gilValorar ms a los individuos y su
interaccin que a los procesos y las herramientassEste es
posiblemente el principio ms importante del manifiesto. Por
supuesto que los procesos ayudan al trabajo. Son una gua de
operacin. Las herramientas mejoran la eficiencia, pero sin personas
con conocimiento tcnico y actitud adecuada, no producen
resultados.Las empresas suelen predicar muy alto que sus empleados
son lo ms importante, pero la realidad es que en los aos 90 la
teora de produccin basada en procesos, la re-ingeniera de procesos
ha dado a stos ms relevancia de la que pueden tener en tareas que
deben gran parte de su valor al conocimiento y al talento de las
personas que las realizan.Los procesos deben ser una ayuda y un
soporte para guiar el trabajo. Deben adaptarse a la organizacin, a
los equipos y a las personas; y no al revs. La defensa a ultranza
de los procesos lleva a postular que con ellos se pueden conseguir
resultados extraordinarios con personas mediocres, y lo cierto es
que este principio es peligroso cuando los trabajos necesitan
creatividad e innovacin.
Valorar ms el software que funciona que la documentacin
exhaustivaPoder ver anticipadamente como se comportan las
funcionalidades esperadas sobre prototipos o sobre las partes ya
elaboradas del sistema final ofrece una retroalimentacin (feedback)
muy estimulante y enriquecedor que genera ideas imposibles de
concebir en un primer momento; dificlmente se podr conseguir un
documento que contenga requisitos detallados antes de comenzar el
proyecto.El manifiesto no afirma que no hagan falta. Los documentos
son soporte de la documentacin, permiten la transferencia del
conocimiento, registran informacin histrica, y en muchas cuestiones
legales o normativas son obligatorios, pero se resalta que son
menos importantes que los productos que funcionan. Menos
trascendentales para aportar valor al producto.Los documentos no
pueden sustituir, ni pueden ofrecer la riqueza y generacin de valor
que se logra con la comunicacin directa entre las personas y a
travs de la interaccin con los prototipos. Por eso, siempre que sea
posible debe preferirse, y reducir al mnimo indispensable el uso de
documentacin, que genera trabajo que no aporta un valor directo al
producto.Si la organizacin y los equipos se comunican a travs de
documentos, adems de perder la riqueza que da la interaccin con el
producto, se acaba derivando a emplear a los documentos como
barricadas entre departamentos o entre personas.
Valorar ms la colaboracin con el cliente que la negociacin
contractualLas prcticas giles estn especialmente indicadas para
productos difciles de definir con detalle en el principio, o que si
se definieran as tendran al final menos valor que si se van
enriqueciendo con retro-informacin continua durante el desarrollo.
Tambin para los casos en los que los requisitos van a ser muy
inestables por la velocidad del entorno de negocio.Para el
desarrollo gil el valor del resultado no es consecuencia de haber
controlado una ejecucin conforme a procesos, sino de haber sido
implementado directamente sobre el producto. Un contrato no aporta
valor al producto. Es una formalidad que establece lneas divisorias
entre responsabilidades, que fija los referentes para posibles
disputas contractuales entre cliente y proveedor.En el desarrollo
gil el cliente es un miembro ms del equipo, que se integra y
colabora en el grupo de trabajo. Los modelos de contrato por obra
no encajan.
Valorar ms la respuesta al cambio que el seguimiento de un
planPara un modelo de desarrollo que surge de entornos inestables,
que tienen como factor inherente al cambio y la evolucin rpida y
continua, resulta mucho ms valiosa la capacidad de respuesta que la
de seguimiento y aseguramiento de planes pre-establecidos. Los
principales valores de la gestin gil son la anticipacin y la
adaptacin; diferentes a los de la gestin de proyectos ortodoxa:
planificacin y control para evitar desviaciones sobre el plan.
62Nuestra principal prioridad es satisfacer al cliente a travs
de la entrega temprana y continua de software de valor.Son
bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos giles se doblegan al cambio como ventaja
competitiva para el cliente.Entregar con frecuencia software que
funcione, en periodos de un par de semanas hasta un par de meses,
con preferencia en los periodos breves.Las personas del negocio y
los desarrolladores deben trabajar juntos de forma cotidiana a
travs del proyecto.Principios del manifiesto (I)6363Construccin de
proyectos en torno a individuos motivados, dndoles la oportunidad y
el respaldo que necesitan y procurndoles confianza para que
realicen la tarea.La forma ms eficiente y efectiva de comunicar
informacin de ida y vuelta dentro de un equipo de desarrollo es
mediante la conversacin cara a cara.El software que funciona es la
principal medida del progreso.Los procesos giles promueven el
desarrollo sostenido. Los patrocinadores, desarrolladores y
usuarios deben mantener un ritmo constante de forma
indefinida.Principios del manifiesto (II)6464La atencin continua a
la excelencia tcnica enaltece la agilidad.La simplicidad como arte
de maximizar la cantidad de trabajo que no se hace, es esencial.Las
mejores arquitecturas, requisitos y diseos emergen de equipos que
se auto-organizan.En intervalos regulares, el equipo reflexiona
sobre la forma de ser ms efectivo y ajusta su conducta en
consecuencia.Principios del manifiesto (III)6565
Metodologas giles66
AgileCrystalAgile es un trmino que acta de paraguas para
diferentes metodologas que estn de acuerdo con el manifiesto
gil6667
67El cliente es el usuario del software, por ejemplo otro
departamento de la compaa o nosotros mismos
Aunque sea software de autoconsumo todas las tcnicas que definen
las diferentes metodologas giles siguen siendo aplicablesPero
nosotros no tenemos clientes!68
68Las distintas metodologas tienen diferentes prcticas (aunque
con un alto solapamiento)
Las prcticas es el tipo de cosas que hace el equipo de
desarrollo para garantizar el cumplimiento de los principios
giles
Diferentes prcticas son: iteraciones cortas, TDD, programacin en
parejas, historias, integracin continua, diseo incremental,
etc.Prcticas giles6969Las historias son unidades de funcionalidad
del sistema que aportan valor al negocioUna historia tiene que ser
lo suficientemente pequea para poder se desarrollada en una
iteracinAl principio de una iteracinEl cliente (el negocio) propone
historias a desarrollarLos desarrolladores estiman el esfuerzo
requerido para implementar las historias (p.e. en horas de
trabajo)El cliente organiza las historias a implementar en la
iteracin sin superar el mximo esfuerzo disponible en la
iteracinHistorias70
70Ciclo de vida en espiral Iteraciones son cortas (1 2
semanas)Cada iteracin genera software listo para produccin
En cada iteracin se llevan a cabo todas las fases (anlisis,
especificacin, diseo, implementacin) para las pocas historias
seleccionadas
Los perfiles tcnicos son ms difusos (todo el mundo es un poco
arquitecto, diseador, programador, tester)Ciclo de vida e
iteraciones71
71Dos personas programando delante del mismo ordenador
Favorece la transmisin de conocimiento: no hay profesionales
indispensables, todo el equipo conoce todo el sistema (se combate
la posesin del cdigo y el profesional imprescindible)
Favorece la uniformidad del cdigo de acuerdo a unos formatos o
libros de estilo, lo que a su vez facilita el mantenimiento
Toda lnea de cdigo ha sido revisada en el mismo momento en el
que se programado (evita la necesidad de arduas sesiones de revisin
de cdigo)
Programacin en parejas7272Desarrollo guiado por las pruebas
Los tests de validacin del cdigo se construyen antes que la
propia funcionalidad
A continuacin se escribe lafuncionalidad que debe superar el
testTDD (Test Driven Development)73
73Todo el software est testeado
Fija una manera de trabajar sistemtica: escribir un test y a
continuacin el cdigo que lo supere y as sucesivamente
Obliga al desarrollador a pensar explcitamente qu debe hacer
exactamente la funcionalidad que va a implementar: permite centrar
el foco de atencin
Permite detectar tempranamente cdigo que es difcil de testear;
ello generalmente implica un mal diseoVentajas del TDD
(I)7474Confianza: evita el sndrome del si funciona no lo toques
Doble validacin: la misma funcionalidad se ve desde dos puntos
de vista, el cdigo y el test
El conjunto de tests se convierten en una autntica, valiosa y
mantenible fuente de documentacin de qu debe hacer el software y
cmo debe hacerloVentajas del TDD (II)75
75Tests 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 integracin: se verifica que varias piezas de software
que se relacionan entre s lo hacen de manera correcta
Tests de aceptacin: tests que permiten mostrar al cliente (o
usuario) que el software hace lo que se supone que debera hacer
Y ms: estrs, regresinTipos de tests7676Un pequeo esfuerzo
adicional durante el desarrollo que favorece la productividad en el
corto plazo:Reduccin de introduccin de defectos (de manera
exponencial)Facilidad de mantenimiento (atrvete a tocar algo que ya
funciona!)No estamos solos! Mltiples frameworks y herramientasTDD
Ms trabajo?77
77Diseo incremental78
Se har el diseo suficiente para implementar las historias de la
iteracin Es un sobre-esfuerzo y una prdidade tiempo intentar
adelantarrequerimientos que no conocemosen ese momento
Cuando sea necesario se refactorizarn aquellas partes del
sistemas que lo requieranLa batera de tests permite combatir el
sndrome de no toques lo que funciona que se rompe (actan como tests
de regresin)78
Normalmente un sistema se construye por ms de una persona (o
equipo)
Cada desarrollador trabaja de formaaislada en su cdigo y su
mquina
En la fase de integracin se pone en comn el trabajo de todos los
desarrolladores
Muchos problemas: las piezas no encajan, el testeo se hace
tedioso, se introducen defectos, siempre lleva ms tiempo del
previsto (a veces MUCHO ms), etc.Qu es la integracin?7979
Los desarrolladores integran muy a menudo (al menos una vez al
da) todo su trabajo
Detecta malentendidos rpidamente
La integracin forma parte del trabajodiario conviertindolo en un
procesomucho ms previsible que si fuera un ltimo gran paso
Generalmente se tiene un entorno de integracin automatizado que
informa de posibles problemas a los desarrolladores tan pronto se
producenIntegracin continua8080Existen diferentes metodologas
La aplicacin directa del proceso de ingeniera a la ingeniera del
software no funciona porque las premisas de ambos modelos son
diferentes
El cambio de requerimientos es inevitable
Las metodologas giles racionalizan la gestin del cambioQu hemos
visto?81
81Extreme 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/ Bibliografa82
8283
83Mdulo 4Entornos y HerramientasVamos a la guerra!84
84Entornos de desarrollo
IDEs
Plug-ins e integracin de herramientasQu vamos a ver?85
85Los desarrolladores del software, los que lo mantienen, los
que lo administran, etc., son personas (incluso departamentos )
diferentes
Varios desarrolladores pueden trabajar en el mismoproyecto, cmo
se gestionan los cambios y conflictos en el cdigo?
Desarrollar directamente sobre un sistema en produccin es
potencialmente muy peligroso Necesidad de entornos diferentes86
86Entornos: 1 aproximacin87
DesarrolloIntegracinPreproduccinProduccin87Gestiona de forma
adecuada varios desarrolladores trabajando sobre el mismo cdigo
ayudando a resolver posibles conflictos
Permite crear fotos del cdigo en un momento dado que se pueden
recuperar en cualquier momento (versiones)
Permite crear ramas de cdigo. Por ejemplo, mantener tener una
rama de desarrollo y otra para corregir defectos de la versin en
produccinRepositorio de cdigo (I)8888
Repositorio de cdigo (II)89
89Entornos: 2 aproximacin90
Integracin
Preproduccin
Produccin
Nueva Versin
MergeTesting90Mantener varias versiones de cdigo siempre es
complicado:Se pueden encontrar defectos en muchas fasesCuanto ms
tiempo pasa entre la creacin de una rama y el siguiente merge ms se
puede complicar todoLos desarrolladores tienen que hacer un cambio
mental cada vez que cambian de ramaSe crea una sensacin de
confrontacin entre desarrolladores y testers (son el enemigo!) que
puede ser muy contraproducenteProblemas9191Ya hemos visto que en un
entorno gil:Los desarrolladores integran como mnimo a
diarioFavorece la deteccin temprana de problemas y tener una fase
de integracin ms corta
Un servidor de integracin continua es una herramienta que nos
permite gestionar esta forma de trabajar con un alto grado de
automatizacin
Funciona bien en un entorno TDD
Servidor de integracin continua9292Entornos: 1 aproximacin
gil93
Servidor de Integracin
Repositorio
Test
TestModificar
e-mailRSSWEB
93
Entornos: 2 aproximacin gil94
Repositorio
Servidor de IntegracinTodo Correcto!Ups, algo est mal
El cdigo del repositorio siempre funciona!94Entornos:
aproximacin gil95
DesarrolloIntegracinProduccin95Entorno tradicional vs Entorno
gilTradicionalgilMltiples ramas en el repositorio
Desarrolladores vs Testers
Sndrome si ya funciona no lo toques
Minimiza la aparicin de ramas en el repositorio
Desarrolladores y Testers son los mismos (comprensin)
Los tests unitarios actan como tests de regresin (confianza) lo
que facilita la refactorizacin969697Hudson
97IDE = Integrated Development Environment(Entorno de desarrollo
Integrado)
Facilita las diferentes fases ms o menos complejas del
desarrollo del software en una misma herramientaEditar
cdigoCompilar / Enlazar / ConstruirConfigurar bibliotecasConsultar
documentacinIntegracin con el repositorioEtc.
El IDE98
98Especficos para un lenguaje / plataforma
De propsito general
Configurables con plug-insTipos de IDEs99
99
Mtricas de calidad de cdigo
Mtricas de estilo de cdigo
Anlisis de cdigoDeteccin de defectos (bugs)Deteccin de
estructuras peligrosas
Plug-ins de testing y cobertura de cdigo
Tipos de plug-ins para IDEs100Checkstyle
Cobertura100101
EditorTestings101Una posible configuracin102
Checkstyle
Cobertura
Checkstyle
CoberturaRepositorioDesarrolloServidor
Integracin102103Hudson
103Es necesaria la existencia de diferentes entornos
Hay diferentes maneras de organizar los entornos
Los IDEs facilitan el trabajo del desarrollador
Una organizacin gil es ms minimalista e integradaQu hemos
visto?104
104Servidores de Integracin[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 auditora de
cdigo[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
cdigo[CVS] http://ximbiot.com/cvs/wiki/ [SVN]
http://subversion.tigris.org/ [Mercurial]
http://www.selenic.com/mercurial/wiki/
Bibliografa105
105Parte 2Vamos a picar cdigo!
106Buenas prcticas. Te lo dije! Eso se podra haber evitado!
Programacin Paralela. Se pueden hacer dos cosas a la vez?
Asincrona y colas Uy! Esto llevar algn tiempo, vyase a casa y ya
le avisar
Midiendo. Por qu #$%&@! esto funciona tan mal?
Definicin de flujos
ndice107107
Mdulo 5Buenas prcticasTe lo dije! Eso se podra haber
evitado!108
108Buenas prcticas generales
Particularidades del software cientfico
CheckpointsQu vamos a ver?109
109Los programas monolticos son difciles de testear, mantener y
poco flexibles ante cambios
Dividir el problema en subproblemas: anlisis descendente
Paradigma procedural -> mdulosParadiga de orientacin a
objetos -> clases bien definidas
Los mdulos o clases deberan ser:Altamente cohesivos: tareas muy
concretas y especializadasDeberan presentar el mnimo acople entre
sProgramacin modular110110Cualquier desarrollo software debera
estar documentado paraFacilitar el mantenimientoPoder mostrar a un
nuevo miembro del equipo la arquitectura del sistemaEvitar el
chantaje del desarrollador imprescindible
La documentacin puede ser de varios tiposEn un lenguaje de
modelado: UMLMediante bateras de tests de un desarrollo con
TDDDocumentacin111
111En un entorno gil todo mdulo tiene asociado una batera de
tests (unitarios, integracin, aceptacin) que constituye una valiosa
documentacin existe un servidor de integracin que puede
configurarse para construir documentacin de forma automtica
mediante herramientas de ingeniera inversa cada vez que construye
el proyectoDocumentacin automtica?112Javadoc Tool
112Programas muy pesadosUso intensivo de CPUNecesidad de grandes
cantidades de memoriaClculos sin fin (por ejemplo la simulacin)
Software muy especializado
En ocasiones desarrollado por perfiles sin conocimientos
profundos en desarrollo de software
Particularidades del soft. cientfico113
113
Problemas y solucionesProblemaPosibles solucionesUso intensivo
CPU
Necesidad de mucha memoria
Clculos muy largos (posibles prdidas de informacin)
Falta de conocimiento tcnicoOptimizacin, clculo distribuido
Uso eficiente de los recursos, refactoring
Introduccin de checkpoints
Formacin, asesora114
114
Checkpoints, os necesito!1151Desarrollo del soft
26 meses de clculo
Se va la luz!34Se pierde tiempo y dinero
5Ruedan cabezas115Consiste en salvar el estado de la ejecucin
del clculo de manera persistenteEn un disco duroEn una base de
datos
En caso de desastre slo se pierde la informacin desde el ltimo
checkpoint
Tiene un coste asociado en espacio y rendimiento: hay que
encontrar un equilibrioCheckpoints116
116El cdigo debe desarrollarse de manera modular y los mdulos
deben ser altamente cohesivos y estar acoplados al mnimo entre
s
La documentacin es una valiosa herramienta que se puede
automatizar en parte
El software cientfico tiene ciertas particularidades que
estudiaremos en los siguientes mdulos
Softwares con ejecuciones de larga duracin deberan utilizar
checkpoints para poder restaurar el estado en caso de desastreQu
hemos visto?117
117[JavaDoc] http://java.sun.com/j2se/javadoc/
[UMLGraph] http://www.umlgraph.org/ Bibliografa118
118Mdulo 6Programacin ParalelaSe pueden hacer dos cosas a la
vez?119
119Qu es la programacin paralela
Conceptos y clasificaciones
Programacin paralela
Qu ayudas tiene el programadorQu vamos a ver?120
120Hilo de ejecucin, thread y proceso se refieren a un flujo de
instrucciones que se ejecutan secuencialmente
Un programa paralelo tiene varios hilos
Ejecucin concurrente vs ejecucin paralelaParalelismo: algunas
definiciones121121Hay partes del software que no tienen
dependencias funcionales y que potencialmente se podran calcular a
la vez (con la ganancia de tiempo que ello conlleva)
Hoy da disponemos de mquinas con ms de una CPU y
supercomputadores que nos permitiran explotar estas
circunstancias
Hay aplicaciones que es ms fcil pensarlas (y programarlas) como
tareas que se ejecutan en paraleloPor qu programacin
paralela?122122
Operaciones sobre matrices
Resolucin de ecuaciones / integrales
Procesamiento de imgenes
Dinmica molecular
Simulacin de fluidos
Etc.
Ejemplos de aplicaciones 123
123Un ordenador con una nica CPUUn problema se divide en un
conjunto de instruccionesLas instrucciones se ejecutan
secuencialmenteUna instruccin ejecutada a cada ciclo de la
CPUProgramacin secuencial124ProblemaCPUInstrucciones124Programacin
paralela125Subprob. 1CPU 1InstruccionesSubprob. 2CPU
2ProblemaDescomposicin: divide et
imperaInstrucciones125Dependencias funcionales126X =
ClculoPesado_1();Y = ClculoPesado_2(X);Z = ClculoPesado_3();A =
ClculoPesado_4(X,
Z)CalculoPesado_1CalculoPesado_3CalculoPesado_2CalculoPesado_4Grafo
de DependenciasCmo pasamos informacin entre los diferentes
procesos?126Arquitecturas paralelasMem. Compartida -
UMANon-UMATodas las CPUs comparten la misma memoriaEl paso de
informacin se hace directamente en memoriaCada CPU tiene su espacio
de memoriaEl paso de informacin se tiene que hacer mediante
mensajera127MemoriaCPU 1CPU NMemoria 1CPU 1Memoria NCPU
NMensaje127Descomposicin de tareas
Sincronizacin de flujos
Paso de informacin entre flujos
Acceso simultneo a recursos compartidosNo es trivial128
128Algunos lenguajes tienen soporte nativo para hilos en
arquitecturas UMA (Delphi, Java, C#)
Para otros lenguajes existen libreras bien conocidas (con
soporte para casi todos los lenguajes, incluyendo C, C++,
Fortran)Modelos UMA: Pthreads, OpenMPModelos N-UMA: MPIPero no
estamos solos129
129Un lenguaje o una librera es declarativa cuando se dice qu se
quiere hacer pero no el cmo
OpenMP y MPI son libreras declarativas
El programador etiqueta qu partes deben ser ejecutadas en
paralelo, qu dependencias hay, qu informacin debe compartirse
La librera hace el trabajo sucio (creacin de procesos de
sistema, gestin de la mensajera, abstraccin de la red,
etc.)Libreras declarativas130130La programacin paralela permite
ejecutar ms de un flujo de ejecucin de manera simultnea
Hoy da, un mayor rendimiento no se consigue mediante
procesadores ms rpidos sino con una adecuada paralelizacin de las
tareas
El paradigma de programacin paralela introduce nuevas
complejidades que hay que considerar
Existen lenguajes y libreras que ofrecen abstracciones sobre
estas complejidades facilitando la vida al desarrolladorQu hemos
visto?131
131[Wikipedia]http://en.wikipedia.org/wiki/Parallel_computing
[MPI] http://www-unix.mcs.anl.gov/mpi/
[OpenMP] http://openmp.org/wp/ Bibliografa132
132Mdulo 7Asincrona y colasUy! Esto llevar algn tiempo, vyase a
casa y ya le avisar133
133Sincrona vs asincrona
Sistemas de colasQu vamos a ver?134
134El problema (I): peticiones largas135
www.icc.es
ClienteServidor Web
Clster de Clculo
Cliente
135El problema (II): peticiones pesadas136
memoria
136Una llamada o peticin sncronabloquea al llamador hasta que la
operacin invocada no termina
Una llamada o peticin asncrona devuelve el control
inmediatamente al llamador. Tanto el llamador como la operacin
llamada pueden mantener flujos de ejecucin separados y
concurrentesSincrona y asincrona137
137El cliente (llamador) hace la peticin asncrona
El servidor encola la peticin del cliente en una cola de tareas
a hacer
El servidor va ejecutando las tareas de la cola segn la carga
que pueda soportar y las polticas que se hayan definido (nmero de
tareas simultneas, prioridades, etc.)Cmo implementar la
asincrona?138138El servidor notifica al cliente la finalizacin de
la tarea (e-mail, rss, protocolo a medida, etc.)
El cliente obtiene un identificador al hacer la peticin asncrona
y lo usa para ir preguntndole al servidor de vez en cuando has
acabado mi tarea? (es lo que se conoce como notificacin por
encuesta)Polticas de notificacin al cliente139
139Una posible implementacin140
1Peticin2sers notificadoCola3Encolamos peticin4El servidor
procesa las tareas previas5El servidor procesa nuestra
tarea6Notificamos al cliente
140Tarea pesada distribuida141
Planificador de TareasNodos de Clculo1Peticin2sers
notificado3planificacin4ejecucin5Notificamos al cliente
141Productos142
PBSNQSIBM - Tivoli Workload Scheduler
JMS142En el modelo sncrono, llamador y llamado estn fuertemente
acoplados
Este acoplamiento puede ser no deseado para tareas que consumen
grandes cantidades de tiempo o recursos
El modelo asncrono permite desacoplar el llamador del llamadoQu
hemos visto?143
143[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
Bibliografa144
144Mdulo 8 MidiendoPor qu #$%&@! esto funciona tan
mal?145
145Debugging
Logging
Profiling
BenchmarkingQu vamos a ver?146
146Problemas funcionales: el software no hace lo que debera
hacer - debugging
Problemas no funcionales: el software tiene un rendimiento
diferente al esperado o deseable - profiling
Qu implicaciones tendra sustituir este subsistema software o
hardware? qu mejora he obtenido al refactorizar esta parte? -
benchmarking
Problemtica147147Necesitamos mtricas (posiblemente
proporcionadas por herramientas) que nos diganqu debemos mejorarnos
permitan decir cunto hemos mejorado con la solucin 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 debera haberse tocadoMedir antes de intentar
arreglar!148
148A veces el software no hace lo que se supone que debera
hacer
Seguir el flujo del ejecucin a ojopuede resultar complicado
La introduccin de chivatos, ensucia el cdigo y hace difcil su
mantenimientoDebugging149
149Un debugger es una herramienta que permite ejecutar un
programa paso a paso e inspeccionar el contenido de variables y
otras estructuras en tiempo de ejecucin
Dependiendo del lenguaje se requiere la activacin de algn flag
en la fase de compilacin, pero no es necesario modificar el
cdigo
Hoy da son herramientas grficas integradas en el
IDEDebugger150150
151ThreadsLnea en ejecucinComandos de ejecucinValores de las
variablesModificadas en el ltimo paso151Consiste en registrar en un
soporte persistente (ficheros o base de datos) eventos relevantes
en la ejecucin de un programaProblemasTrazas de usoInformacin de
accounting
Requiere modificar el cdigo fuente del programa
Logging (bitcoras)152152Existen libreras que permiten hacer un
uso eficiente del cdigo de logging
Gestin asncrona de la escritura en los soportes para no
penalizar el rendimiento
Mltiples niveles de logging (debug, warning, error, severe)
Activacin y desactivacin de niveles de logging en caliente (sin
tener que apagar la aplicacin)Libreras de logging153
Pantheios
log4tran153Tambin 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
comnCuellos de botella154
154Son herramientas que analizan la ejecucin de programas para
buscar cuellos de botella
Muchas veces requieren la instrumentalizacin del cdigo para
capturar estadsticas en tiempo de ejecucin
Capturan informacin como:Estadsticas sobre tiempos de ejecucin
de una rutinaNmero de ejecuciones de una rutina
Detectan el cdigo donde hay que centrar los esfuerzos de
optimizacin: (10.000 x 1) > (1 x 1000)
Profilers155
155Son procedimientos de comparacinDe alternativasPara medir la
mejora al aplicar una solucinPara medir la escalabilidad del
sistema (tests de estrs)
De varios tiposFull stack: mide el rendimiento global de un
sistema software (caja negra)De componente: mide el rendimiento de
un susbsistema (caja blanca)Benchmarking156
SysBench Database Test Suite 156Todo junto157
1Desarrollo del soft2Testing & DebuggingDebugger
SGBDLgica de NegocioPresentacin3Profiling full
stack4BenchmarkingProfiler
vs
157Durante la fase de desarrollo el debugger puede ayudar a
analizar posibles problemas
El uso de logging permite registrar eventos interesantes en
desarrollo o produccin
Para optimizar un software es importante tomar medidas mediante
profiling y benchmarkingQu hemos visto?158
158[JMeter] http://jakarta.apache.org/jmeter/ Bibliografa159
159Mdulo 9Definicin de flujos160
160Cmo poner en prctica todo lo aprendido para construir flujos
robustos
Definicin de flujos o procesos encajando todas las piezas
Webservices como implementacin de una arquitectura SOA de
construccin de flujosQu vamos a ver?161
161Ejemplo de flujo (workflow)162Seleccionar
ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNO162Problemas:
lenguajes diferentes163Seleccionar
ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNO
FORTRAN
Lenguajes Diferentes163Problemas: procesos pesados164Seleccionar
ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNOProceso muy
largo en hardware costoso164Problemas: ejecucin
paralela165Seleccionar ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNOProgramacin
paralela165Problemas: modificacin del flujo166Seleccionar
ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNOPreparacin
2166Problemas: tareas largas167Seleccionar
ProtenaPreparacinEquilibradoAjuste de
ParmetrosSimulacinPost-simulacinAnlisis 1Anlisis NSNOTareas
Asncronas167Lo sabemos resolver todo!ProblemaSolucinIntegracin de
lenguajes diferentes
Procesos pesados y costosos
Algoritmos complejos y/o tareas sin dependencias
Procesos largos que bloquean el flujo
Modificacin del workflowEnvolver los procesos mediante
webservices
Aadir checkpoints
Programacin paralela
Uso de sincrona y colas
Herramientas de orquestacin de servicios y TDD168
168Es una implementacin de la arquitectura SOA
Encapsulan un servicio (una unidad funcional)
Actan como un esperanto de los lenguajes de programacin
(interoperabilidad e independencia de la plataforma)
Permiten invocacin remotaWebservices, ya hemos visto169169La
maraa de los
webservices170SOAPUDDIWSDLRESTWS-IDocumentLiteralRPCEncodedXMLBPEL170Interoperabilidad
con webservices171
FORTRAN
WebserviceFORTRANWebservicePerfil WS-I171Permiten orquestar los
serviciosConstruir workflows (posiblemente de manera
visual)Modificar workflows en tiempo de ejecucin
Simular workflows
Definir polticas, qu pasa si un servicio falla? no est
disponible? tarda ms de lo que debiera?
Monitorizar la ejecucin de workflows
Herramientas de workflows172
172173
173174
174La arquitectura SOA y los webservices son una solucin para
construir y gestionar flujos complejos
Cada uno de los servicios puede hacer uso de las tcnicas que
hemos visto a lo largo del seminario
Existen herramientas que permiten trabajar con los workflows
amigablementeQu hemos visto?175
175[WS-I] Web Services Interoperability Organization -
http://www.ws-i.org/
[BPEL-Eclipse] http://www.eclipse.org/bpel/
[Taverna] http://taverna.sourceforge.net/ Bibliografa176
176The EndPreguntas?177
177Gracias por su atencin!Ivn Prraga
[email protected] de Negocio
SGBDTerminal Tonta
Lgica de Negocio
SGBDLgica de Negocio
Ordenador Personal
Lgica de Negocio
SGBDNavegador web
Lgica de Negocio
SGBDLgica de Negocio
Clientes
Mquinas del Usuario
Servidores de la empresa
HOST / Mainframe
Cliente / Servidor
Multi-capa
Orientada al Servicio (SOA)
Tipo de Arquitectura
DatosLgica de Negocio
SGBDTerminal Tonta
Lgica de Negocio
SGBDLgica de Negocio
Ordenador Personal
Lgica de Negocio
SGBDNavegador web
Lgica de Negocio
SGBDLgica de Negocio
Clientes
Mquinas del Usuario
Servidores de la empresa
HOST / Mainframe
Cliente / Servidor
Multi-capa
Orientada al Servicio (SOA)
Tipo de Arquitectura
Servidor de Aplicaciones
ERP (Enterprise resource planning)
SGBD
CRM(Customer Relationship Management)
CMS(Content Management System)
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Servicio
Los sistemas ofrecen sus funcionalidades como servicios
Servicio
Servicio
Servicio
Servicio
Servicios ms generales usan los diferentes servicios
Servicio
Proceso
Proceso
Organizacin 1
Organizacin 2
Ejemplo: comprobar stock
Ejemplo: enviar promocin a cliente
Procesos de negocio se mapean con servicios
