UML Ejecutable y MDA

Santiago, 11 de Enero de 2007. Santiago, 11 de Enero de 2007.

Agenda

Metas de la presentacin Ingeniera de Software: Ayer, Hoy y Maana UML en la Ingeniera de Software El Prximo Paso: UML Ejecutable y MDA Una Herramienta UML: Enterprise Architect Una Herramienta MDA: Enterprise Analyst

1

Metas de la presentacin presentaci presentacin

Identificar los problemas del desarrollo tradicional - Recorrer la historia de la ingeniera de software - Analizar los datos estadsticos de los proyectos Entender las ventajas del desarrollo orientado a modelos - Concepto de UML, UML Ejecutable y MDA (lo nuevo de OMG) - MDA en la luz de las estadsticas anteriores Demostrar los ejemplos de las Herramientas - Enterprise Architect de Sparx Systems (UML) - Enterprise Analyst de Craftware (MDA)

Negocios Hoy

Globalizacin

Velocidad

Muchos Recursos

Crecimiento

La gran mayora de los proyectos de software hoy, abarcan los sistemas de apoyo a procesos de negocio

2

Ingeniera de Desarrollo de Software Hoy Ingenier IngenieraNegocios y Sistemas Informticos - Los negocios modernos no solo dependen de los sistemas; los sistemas forman parte de los negocios - Amazon, DeRemate, Despegar.com, etc.

Ingeniero de Performance Analista

Desafos - Equipos ms grandes - Especializacin - DistribucinTesteador Liberacin y Distribucin Jefe de Proyecto Desarrollador

- Rapidez del cambio tecnolgico

Estadsticas de los Proyectos de Software Estad Estadsticas

Entre 30-80% de los Proyectos de Software

Nunca Terminan!

3

Estadsticas de los Proyectos de Software (cont.) Estad EstadsticasComo Terminan los Proyectos de Software?Terminan en tiempo26%

29%

6% 6% 8% 16% 9%

Terminan atrasados 200% Nunca Terminan

Por Qu los Proyectos de Software Fracasan? Por Qu Proyectos de Software Fracasan?

Requerimientos incompletos Falta de Involucramiento de Cliente/Usuario Falta de Recursos Expectativas poco Reales Falta del soporte de alta gerencia Requerimientos cambiantes Falta de Planificacin Perdida de la necesidad (atraso?) Falta de administracin Poco conocimiento de la tecnologa

13,1 12,4 10,6 9,9 9,3 8,7 8,1 7,5 6,2 4,3(en porcentajes)

4

Qu Marca los Proyectos Exitosos? Qu Qu

Involucramiento del Cliente/Usuario Soporte de alta gerencia Requerimientos claramente especificados Planificacin adecuada Expectativas reales Hitos ms pequeos Equipo comprometido Clara propiedad Visin y objetivos claros El equipo bien enfocado Otro

15,9 13,9 13 9,6 8,2 7,7 7,2 5,3 2,9 2,4 13,9(en porcentajes)

Los Errores en los Proyectos de SoftwareEn Qu Etapa se Introducen los errores?

Pruebas 20%

Anlisis 20%

Construccin 35%

Diseo 25%

Ms de 40% de los errores de software se introducen en las tareas de documentacin!

5

Los Errores en los Proyectos de Software (cont.)En Qu Etapa se detectan los errores?Operacin 5% Anlisis 10% Diseo 20%

Pruebas 45%Construccin 20%

Ms de 40% de los errores de software se detectan en las tareas de revisin de documentacin!

Costo de un Error en el Proyecto de SoftwareSi un error introducido en Anlisis y An detectado en Anlisis cuesta 1, entonces An entoncesError introducido en anlisis, detectado en operacin

Un error introducido en Anlisis An corregido en Diseo cuesta 5 Dise 5

Costo de error

Un error introducido en Anlisis An corregido en Construccin cuesta 10 Construcci 10Operacin Un error introducido en Anlisis A Construccin corregido en Testing cuesta 100 DEtapa de deteccin de error

Error introducido en anlisis y detectado en anlisis es el ms barato

Anlisis

Un error introducido en Anlisis corregido en Operacin cuesta 1000-10000!

O

P

C

Etapa de introduccin de error

6

Productos y Enfoques de Desarrollo de SoftwareProducto

AbstracciEnfoque n 00. - Integracin y servicios WEB 90. - ComponentesExpuestos alrededor de las clases OO

- Integracin de negocios

- Negocios individuales

- Partes de negocios - Sistemas genricos de uso comn - Formulas matemticas, operaciones bsicas

70. - Orientacin a objetos

Implementadas usando lenguajes orientados a objetos

60. - Lenguaje estructurado 50. - Lenguaje de mquina

Abstraccin en Desarrollo de Software Abstracci AbstraccinAbstraccin en SoftwareLa brecha entre las abstracciones demuestra una tendencia de crecimiento

Abstraccin

Producto Enfoque Tradicional

1950

1960

1970

1990

2000

2005

Aos

- Los ingenieros todava gastan la mayora de su tiempo sobre los cdigos fuentes - La abstraccin del producto ha superado este nivel hace mucho tiempo

7

Introduccin al UML Introducci IntroduccinLas dems ingenieras abandonaron hace mucho tiempo el modelo del master builder Diseo (ingenieros y arquitectos) separado de la construccin (programadores) Intercambio fuerte de informacin tcnica => elemento indispensable: lenguaje (grfico) preciso de especificacin UML nace desde las notaciones grficas existentes Historia:1995: 1997: 2000: 2005: Inicio de construccin de UML Primer estndar UML 1.1 liberado UML 1.4 liberado UML 2.0 liberado

Introduccin al UML (cont.) Introducci Introduccin UML (cont.)

UML Permite ver un sistema de distintos puntos de vista UML aleja al ingeniero de los cdigos fuentes UML logra un aumento de abstraccin de enfoque

8

Diagramas de UMLLa versin de UML 2.0 define 13 distintos diagramas:

Estructura- clases - objetos - compuesto - paquetes - componentes - despliege

Comportamiento- casos de uso - comunicacin - secuencias - interaccin - actividades - estados - temporal

Diagramas de Casos de Uso

Funcionalidad de Sistema, requisitosSistema de Pub

Informar Bodega

Sistema de Bodega extend

Vender Bebida

Barmen include

Registrar Venta

9

Diagramas de ClasesBodega Cliente 1 1..* 1 Venta + valor: Doble ImprimirBoleta() 0..* realiza 1 Barmen Jugo Natural Gaseosa

1 almacena Pedido tiene 1..* 0..* Bebida

protegee en nti

co

ah

Anlisis y Diseo Lgico y Fsico

orr a

posee

usa

Diagramas de SecuenciaUsuario Interfaz Operativa (from Trmites) Asignar tarea Controlador Tareas (from Trmites) Tareas (from Trmites)

Grabar tarea

Ver tareas asignadas

(from Actores)

Comportamiento del sistema

10

Diagramas de Componentes

Piezas fsicas de sistemaEA API

EA

ES Plug-In

:GUI

:Compiler

:Simulator

:Obj ect Space

:Class Model

Diagramas de Procesos de Negocio (UML extendido)

Flujos de procesos de negocio

goal Perforar no menos de 10.000 platos semanales : Quantitativ e Goal

achieve

people :Maestro process control

physical :Plato resource flow

Proceso de taladrado

resource flow

physical Perforado : Plato

Perforar

Calibrar

Leer instruccin de taladrado

Iniciar taladrado

Taladrar

resource :Mquina

information :Instrucciones

11

UML y ProductividadCdigo implementado Manualmentesin UML; 100 100 80 60 40 20 0 Interfaz Lgica Datos UML; 10 UML; 56 UML; 40 sin UML; 100 sin UML; 100

Una gran parte de cdigo (ms de la mitad) se puede generar directamente desde los modelos UML

UML y Errores IntroducidosErrores introducidossin UML; 100 100 UML; 30 50

0

A qu se debe esta baja de los errores? - Documentacin de mejor calidad y ms fcil de generar y revisar - Generacin automtica de los cdigos fuentes - Comunicacin entre todos menos ambigua, etc.

12

Abstraccin en Desarrollo de Software (cont.) Abstracci AbstraccinAbstraccin en SoftwareLa brecha entre las abstracciones con UML se va disminuyendo

Abstraccin

Producto Enfoque Tradicional Enfoque UML

1950

1960

1970

1990

2000

2005

Aos

- Los ingenieros se pueden enfocar en las tareas de anlisis y diseo

Problemas del UMLUML permite hacer especificaciones ms claras, pero no permite automatizar su validacin UML mantiene alta ambigedad de ciertos diagramas (casos de uso) UML est orientado a los ingenieros y tcnicos, y mantiene difcil comunicacin con los usuarios y clientes UML es relativamente complejo

UML no se puede ejecutar!

13

Introduccin al UML Ejecutable Introducci Introduccin

Un intento de resolver los problemas bsicos de UML, relacionados con su semntica dbil Nunca ha sido oficializado como un estndar Un paso intermedio entre UML y MDA Informalmente conocido como xUML

UML y UML Ejecutable

UMLSemnticamente dbil Complejo muchos diagramas Ambigedad presente Generacin parcial del cdigo (solo estructura) Lenguaje visual con descripciones textuales informales El modelo es dibujo

xUMLSemnticamente fuerte Simple pocos diagramas Sin ambigedad Generacin completa de cdigo (estructura + comportamiento) Lenguaje visual + lenguaje de acciones formal El modelo es cdigo

UML especifica los sistemas xUML implementa los sistemas

14

xUML ResumidoxUML xUMLFactura + monto: double nr: int fecha_pago: date 0..* pago(date) : void 0..*Usuario Cobrar Factura

=1 -

UML UML

-

Elementos Elementos ambiguos ambiguos

+

Lenguaje Lenguaje de de Acciones Acciones

Cliente RUT: string nombre: string

Ingresar Factura

1 Orden de Compra monto: int

pago( fecha: date):PAGADA

Ingresar Factura

pago ENTREGADA

self.fecha_pago = fecha self.estado = PAGADA [si]Serv idor

Cobrada? [no] Suspender Factura

perdida PERDIDA entrega

Cobrar Factura

Sistema Facturas

CREADA

Elementos de xUMLSistema- Es una estructura de Dominios y sus relaciones - Interfaz Usuaria, Mdulos Lgicos, Persistencia, etc.

Interfaz Usuaria

Dominio

- Representado usando diagrama de clases - Reutilizable - Se comunica con otro Dominio

Facturacin

e-mailing

Base de Datos

15

Elementos de xUML (cont.)Clases y Asociaciones

- Representan la estructura interna de Dominios - Altamente formales y validables

Factura + monto: double nr: int fecha_pago: date 0..* pago(date) : void 0..* Cliente 1 RUT: string nombre: string

1 Orden de Compra monto: int

Elementos de xUML (cont.)Mquinas de Estados-

Definen ciclo de vida de los objetos de clases Altamente formales y validables Base de ejecucin de los modelos Se comunican entre ellas enviando seales Ejecucin concurrentePAGADA

pago ENTREGADA

perdida PERDIDA entrega

CREADA

16

Elementos de xUML (cont.)Lenguaje de Acciones

- Define comportamiento de bajo nivel - Equivalente a los lenguajes de programacin, pero en nivel ms alto nivel de clases, objetos y estados - Especifica ejecucin de estados, transiciones, etc. - Se est estandarizando

pago( fecha: date): self.fecha_pago = fecha self.estado = PAGADA

Elementos de xUML (cont.)

Compilador/Generador

- Genera los cdigos fuentes desde los modelos - Pueden cubrir distintas arquitecturas - Generacin basada en las decisiones arquitectnicas

17

Resumen de UML Ejecutable

Agrega semntica formal de ejecucin a UML Alto porcentaje de cdigo generado (100% o casi 100%), pero poca flexibilidad No estandarizado ntimamente relacionado con los sistemas en tiempo real No directamente aplicable a los desarrollos de los sistemas corporativos (enterprise)

Introduccin al MDA (Model Driven Architecture) Introducci (Model Architecture) Introduccin

Nuevo estndar de la casa de UML - OMG Todava en la etapa de investigacin y propuestas Construido en base a los estndares anteriores: UML, OCL, XML, etc. Enfrenta los desarrollos modernos, corporativos y de gran escala

18

Metas de MDA

AbstraccinResolver los siguientes problemas de la ingeniera: Obsolescencia tecnolgica Portabilidad Productividad Durabilidad Calidad Integracin Mantenimiento Pruebas y simulacin ROI

Como?

Conceptos Claves de MDAModelo - Una especificacin formal del sistema de un punto de vista bien definido Punto de Vista -Tcnica de ver el sistema enfocndose en ciertos detalles, e ignorando todo aquello ajeno a ellos Plataforma - Un conjunto de los subsistemas claramente identificados, que proveen interfaz bien definida a otros subsistemas Independencia de la Plataforma - Cualidad que posee el modelo si sus detalles no dependen de cierta Plataforma Transformacin del Modelo - El proceso de conversin de un Modelo al otro, dentro del mismo sistema

19

Tres Puntos de Vista de MDAModelo Independiente de Computacin (CIM) - El modelo que no contiene informacin de estructura sistmica - Ejemplo: Modelo de negocio, modelo de dominio Modelo Independiente de Plataforma (PIM) - El modelo computacional, sin detalles de plataforma de implementacin - Ejemplo: Modelo conceptual, diagramas de estados Modelo Especfico de Plataforma (PSM) - El modelo con detalles de plataforma de implementacin - Ejemplo: Diagrama de clases J2EE o .NETPlataforma es un concepto relativo

El Proceso de Desarrollo MDABasado en una disminucin controlada de abstraccin - Modelamiento formal desde el inicio - Disminucin gradual de la brechas entre producto y el sistema - Definicin clara de punto de vista en cada momentoEjecucin/Simulacin del PIM

Modelo PIMTransformacin

Modelo PSM

Informacin complementariaNuevo PIM

Decisiones arquitectnicas

20

Transformaciones MDA

PIMModelo Conceptual Modelo de Estados Lenguaje de Acciones Modelo de Arquitectura Modelo de Implementacin

PSMtransformacin (Cliente/Servidor, Multicapas, etc.) transformacin (J2EE, .NET, etc) transformacin

Modelo de Arquitectura

Modelo de Implementacin Cdigos Fuentes (Vector, Coleccin, etc.)

Lenguaje de Transformaciones en Construccin

MDA y Productividad

Cdigo Implementado Manualmente100 80 60 40 20 0 Interfaz Lgica Datos 16 5 56 40 10 sin UML UML MDA 0 100 100 100

Casi todo el cdigo se genera automticamente a partir de los modelos simulados!

21

MDA y Errores IntroducidosErrores Introducidossin UML 100 sin UML 50 UML MDA 0 1 UML MDA

A qu se debe esta baja de los errores? - El modelo es documentacin y el cdigo - Generacin de los cdigos fuentes automtica - Simulacin en nivel abstracto pruebas tempranas

Abstraccin en Desarrollo de Software (cont.) Abstracci AbstraccinAbstraccin en Software140 120 100 80 60 40 20 0 1950 1960 1970 1990 Aos 2000 2005La brecha entre las abstracciones casi desapareci

Abstraccin

Producto Enfoque Tradicional Enfoque UML Enfoque MDA

- Los ingenieros se pueden enfocar en las tareas de anlisis, automatizando hasta diseo!

22

Por Qu los Proyectos de Software Fracasan? Por Qu Proyectos de Software Fracasan?Requerimientos incompletos Falta de Involucramiento de Cliente/Usuario Falta de Recursos Expectativas poco Reales Falta del soporte de alta gerencia Requerimientos cambiantes Falta de Planificacin Perdida de la necesidad (atraso?) Falta de administracin Poco conocimiento de la tecnologa 13,1 12,4 10,6 9,9 9,3 8,7 8,1 7,5 6,2 4,3

40% de los factores de fracaso directamente abarcados por MDA

Qu Marca los Proyectos Exitosos? Qu QuInvolucramiento del Cliente/Usuario Soporte de alta gerencia Requerimientos claramente especificados Planificacin adecuada Expectativas reales Hitos ms pequeos Equipo comprometido Clara propiedad Visin y objetivos claros El equipo bien enfocado Otro 15,9 13,9 13 9,6 8,2 7,7 7,2 5,3 2,9 2,4 13,9

30% de los factores de xito directamente abarcados por MDA

23

Transicin hacia MDA Transici TransicinAsume un Fuerte Cambio Organizacional - Debe ser gradual y controlado - Debe ser planificado - Debe tener fuerte soporte de alta gerencia

Paso 1: Hacia UML

Paso 2: Hacia MDA

Sin Modelo

Cdigo es Modelo

Modelo es Cdigo

Sin el uso de UML Sin especializacin de roles Enfoque en programacin Dependencia de Plataformas

Con uso de UML Roles ms especializados Enfoque en Diseo

Con uso de MDA Roles especializados Enfoque en Anlisis Independencia de Plataformas

Ejemplos de las HerramientasUna Herramienta UML: Enterprise Architect - Cobertura 100% de UML 2 - Gran presencia en Chile - Precio bajo - Capacitacin - Soporte metodolgico

Una Herramienta MDA: Enterprise Analyst - Add-in de EA - Validacin/Simulacin del modelo en nivel conceptual - Validacin/Generacin de la documentacin - Capacitacin - Soporte metodolgico

24

Bibliografa Bibliograf BibliografaExecutable UML, A Foundation for Model-Driven Architecture, S. J. Mellor, M. J. Balcer MDA Explained, The Model Driven Architecture: Practice and Promise, A. Kleppe, J. Warmer, W. Blast MDA Distilled, Principles of Model-Driven Architecture, S. J. Mellor, K. Scott, A. Uhl, D. Weise Model Driven Architecture, Applying MDA to Enterprise Computing, D. S. Frankel The Object Constraint Language Second Edition, Getting Your Models Ready for MDA, J. Warmer, A. Kleppe Domain-Frontier Aproach to MDA, Aleksandar Orlic, OMGs Second MDA Workshop, Orlando, Mayo 2004. Futuro de la Ingeniera de Software, Aleksandar Orlic, articulo en revista Informtica, edicin Enero/Febrero de 2006.

Bibliografa (cont.) Bibliograf BibliografaStandish Group Survey, 1999 The Basics of Model-Driven Architecture, Cephas Consulting Corp Model Driven Architecture, Applying MDA to Enterprise Computing, D. S. Frankel Operational Excellence through Efficient Software Testing Metrics, Ramesh Pusala, Infosys Requeriments Engineering, Dr. Annie I. Antn, NCSU www.omg.org/uml, www.omg.org/mda y otras fuentes en Internet.

25

Gracias! Gracias!Craftware Consultores Ltda. Craftware Consultores Ltda. www.craftware.net www.craftware.net info@craftware.net info@craftware.net

26