Universidad de San Carlos de Guatemala Facultad de Ingeniera Escuela de Ingeniera en Ciencias y Sistemas APLICACIN DE LA METODOLOGA RUP PARA EL DESARROLLO RPIDO DE APLICACIONES BASADO EN EL ESTNDAR J2EE JULIO CSAR RUEDA CHACN Asesorado por: Ing. Jos Ricardo Morales Prado Guatemala, marzo de 2006 UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERA APLICACIN DE LA METODOLOGA RUP PARA EL DESARROLLO RPIDO DE APLICACIONES BASADO EN EL ESTNDAR J2EE TRABAJO DE GRADUACIN PRESENTADO A LA JUNTA DIRECTIVA DE LA FACULTAD DE INGENIERA POR JULIO CSAR RUEDA CHACN Asesorado por: Ing. Jos Ricardo Morales Prado AL CONFERRSELE EL TTULO DE INGENIERO EN CIENCIAS Y SISTEMAS GUATEMALA, MARZO DE 2006 UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERA NMINA DE JUNTA DIRECTIVA DECANOIng. Murphy Olympo Paiz Recinos VOCAL I VOCAL IILic. Amahn Snchez lvarez VOCAL IIIIng. Julio David Galicia Celada VOCAL IVBr. Kenneth Issur Estrada Ruiz VOCAL VBr. Elisa Yazminda Vides Leiva SECRETARIAInga. Marcia Ivonne Vliz Vargas TRIBUNAL QUE PRACTIC EL EXAMEN GENERAL PRIVADO DECANOIng. Murphy Olympo Paiz Recinos EXAMINADORIng. Edgar Estuardo Santos Sutuj EXAMINADORInga. Floriza Felipa Avila de Medinilla EXAMINADORInga. Virginia Victoria Tala Ayerdi SECRETARIAInga. Marcia Ivonne Vliz Vargas HONORABLE TRIBUNAL EXAMINADOR Cumpliendo con los preceptos que establece la ley de la Universidad de SanCarlosdeGuatemala,presentoasuconsideracinmitrabajode graduacin titulado: APLICACIN DE LA METODOLOGA RUP PARA EL DESARROLLO RPIDO DE APLICACIONES BASADO EN EL ESTNDAR J2EE, temaquemefueraasignadoporlaCoordinacindelaCarrerade Ciencias y Sistemas, en febrero de 2004. Julio Csar Rueda ChacnAGRADECIMIENTOS A: DiosCreador de todo lo existente y gua de mi vida, que me da la oportunidaddeseguircreciendomentalmente,yponer siemprealaspersonasindicadaseneltranscurrirdemi vida. Mis padresRigobertoRueda,quienmehabrindadotodossus conocimientosdesdelosiniciosdemividayloms importante,elejemplodellevarunavidadignadeserun hombreaadmirar;padre,estarsiguiendosiempretus pasos;EleonoraChacn,quienmehadadosucario, atenciones, recuerdos y alegras desde mi niez y por estar siemprependientedem,aambosporelapoyo incondicionalquemedieronalolargodelacarrerayalo largo de mi vida. Mi hermanoPorsus consejosyapoyoypor los buenos tiempos queByron hemos vivido, que siempre estarn en mis pensamientos. Mi familiaPorquesiempremehanapoyado,aconsejadoybrindado todoelcarioquehasidofundamentalenmivida;familia, este logro es de todos. Mi asesorIngenieroRicardoMorales,porsuexcelenteasesoray direccin en mi trabajo de investigacin. Mis amigosQuesindudaalguna,susconsejos,experienciasysobre todo,suapoyoypaciencia,contribuyeronentodosmis xitos.MuyespecialmenteaSuanporelapoyo incondicional que me ha brindado. La Facultad de Porelsoporteinstitucionaldadoparami formacin y porIngeniera ende al pueblo de Guatemala. En generalAtodasaquellaspersonasquedeunauotraforma, colaboraron o participaron en mi formacin como persona y profesional, hago extensivo mi ms sincero agradecimiento. ACTO QUE DEDICO A: Mis padresRigoberto Rueda Cmbara y Eleonora Chacn Umaa de Rueda Mis abuelosJos Luis Rueda (pap Chepe) Mara Luisa Cmbara de Rueda (mam Gicha) Mara Elena Umaa de Chacn (abuelita Elena) y JosMaraChacnVillela(abuelitoChema),queDioslo tenga en su gloria. Mi familiaA cada uno de ellos.

I NDICE GENERAL NDICE DE ILUSTRACIONESV TABLASIX GLOSARIOXI RESUMENXVII OBJETIVOSXIX INTRODUCCINXXI 1.METODOLOGA DE DESARROLLO APLICADA1 1.1.Introduccin al RUP1 1.1.1.Dimensiones del RUP1 1.1.2.Fases4 1.1.2.1.Planeando las fases4 1.1.2.2.Esfuerzo respecto de los flujos de trabajo7 1.1.2.3.Esfuerzo respecto de las fases8 1.1.3.Iteraciones9 1.1.3.1.Proceso Iterativo e Incremental10 1.1.4.Disciplinas12 1.1.4.1.Modelado del negocio13 1.1.4.2.Requerimientos13 1.1.4.3.Anlisis y diseo13 1.1.4.4.Implementacin14 1.1.4.5.Pruebas14 1.1.4.6.Despliegue14 1.1.4.7.Gestin y configuracin de cambios15 1.1.4.8.Gestin del proyecto15

II 1.1.4.9.Entorno16 1.1.5.Organizacin y elementos en RUP16 1.1.5.1.Actores o roles17 1.1.5.2.Artefactos19 1.1.5.2.1.Conjuntos de artefactos19 1.1.5.2.2. Grado de finalizacin de artefactos21 1.2.Introduccin al UML22 1.2.1.Descripcin del lenguaje24 1.2.1.1.Inconvenientes en UML25 1.2.1.2.Perspectivas de UML25 1.2.2.Descripcin de los diagramas26 1.3.Metodologa del RUPpara anlisis y diseo29 1.3.1.Descripcin de estereotipos31 1.3.2.Enlace del RUP con el UML32 1.3.3.Descripcin del mtodo40 2.TECNOLOGA PARA DESARROLLO RPIDO DE APLICACIONES43 2.1.Introduccin al RAD43 2.1.1.Etapas de la metodologa RAD45 2.1.2.Caractersticas de la metodologa RAD46 2.1.3.Problemas en la metodologa RAD47 2.2.Introduccin a J2EE47 2.2.1.JSR48 2.2.2.JCP48 2.2.3.Ventajas de J2EE51 2.2.4.Desventajas de J2EE52 2.2.5.Integracin con otros sistemas53 2.3.Arquitectura de mltiples capas54 2.3.1.El modelo de desarrollo de J2EE54 2.3.2.Servidores de aplicaciones56

III 2.3.2.1.JBoss57 2.3.2.2.JOnAS58 2.3.2.3.OpenEJB58 2.3.2.4.Ejemplo prctico de servidor de aplicaciones58 2.4.Enlace del RUP, UML, RAD y J2EE.59 2.4.1.Diseador rpido de rational (RRD)60 2.4.2.Modelando el sistema con RRD62 3.HERRAMIENTASAUTILIZARPARAUNDESARROLLORPIDO DEAPLICACIONES67 3.1.Herramienta XDE67 3.1.1.Introduccin a XDE67 3.1.2.Caractersticas de rational XDE68 3.2.Herramienta WebSphere69 3.2.1.Enfoque de soluciones de la herramienta72 3.3.Pasos para modelar en la herramienta XDE72 3.3.1.Tipos de entornos73 3.3.1.1.Entorno de modelado73 3.3.1.2.Entorno de desarrollo74 3.3.1.3.Entorno mixto75 3.3.2.Tipos de modelos76 3.3.3.Modelado de UML en XDE77 3.3.3.1.Casos de uso en XDE y sus diagramas78 3.3.3.2.Diagrama de clases con XDE79 3.3.3.3.Diagramas de secuencia85 3.3.3.4.Diagrama de estados con XDE86 3.3.3.5.Diagrama de actividades con XDE88 3.3.3.6.Diagramas de componentes con XDE90 3.4.Generacin de cdigo91 3.5.Publicacin de cdigo93

IV 4.EXPLICACINASOCIATIVADELASMETODOLOGAS ESTNDARESYHERRAMIENTASPARAELDESARROLLO RPIDO DEAPLICACIONES95 4.1.Ttulo del sistema95 4.2.Descripcin general del sistema95 4.3.Requerimientos a satisfacer96 4.3.1.Otros requerimientos a satisfacer98 4.4.Stakeholder y descripciones de usuarios98 4.5.Ambiente a utilizar98 4.6.Modelo de casos de uso99 4.7.Anlisis del caso de uso Oferta en Vehculo100 4.8.Diagrama de clases del anlisis de la realizacin del caso de uso105 4.9.Diagramadesecuenciadelanlisisdela realizacin del caso de uso111 4.10.Diagramadecolaboracindelanlisisdelarealizacindel caso de uso114 4.11.Diseo de la realizacin del caso de uso115 4.12.Diagrama de clases del diseo de la realizacin del caso de uso118 4.13.Diagramadesecuenciadeldiseodela realizacin del caso de uso122 4.14.Diagrama de colaboracin del diseo de larealizacindel caso de uso124 4.15.Arquitectura125 4.16.Vista de despliegue127 CONCLUSIONES128 RECOMENDACIONES130 BIBLIOGRAFA132

V NDICE DE ILUSTRACIONES FIGURAS 1.Disciplinas, fases, iteraciones del RUP2 2.Fases del RUP4 3.Recursos utilizados en las fases del RUP en el tiempo.6 4.Ciclo evolutivo en la elaboracin de software basado en el RUP7 5.Esfuerzo respecto de los flujos de trabajo8 6.Esfuerzo respecto de las fases9 7.Ciclo de vida Iterativo incremental10 8.Enfoque cascada11 9.Ciclo de vida de un software con un enfoque iterativo incremental12 10.Elementos que conforman el RUP17 11.Grado de finalizacin de artefactos22 12.Desarrollo de UML, con sus versiones24 13.Relaciones de enlaces entre modelos27 14.Diagramas, partes de un modelo27 15.Ejemplo de estereotipo31 16.Comparacin entre diagramas de casos de uso (a) RUP (b) UML33 17.Comparacin entre diagramas de clases (a) RUP (b) UML34 18.Comparacin entre diagramas de objetos (a) RUP (b) UML35 19.Comparacin entre diagramas de estados (a) RUP (b) UML35 20.Comparacin entre diagramas de actividades (a) RUP (b) UML36 21.Diagrama de secuencia37 22.Comparacin entre diagramas de colaboracin (a) RUP (b) UML38 23.Diagrama de componentes38

VI 24.Comparacin entre diagramas de despliegue (a) RUP (b) UML39 25.Esquema del JCP49 26.Esquema de un modelo mixto de tres y cuatro capas55 27.JBosseselservidordeaplicacionesqueestmsdemodaactualmente57 28.Ejemplo de servidor de aplicaciones59 29.Unin de lasaplicaciones con losdiversosniveles medianteel RRD basado en la plataforma RAD61 30.ModelandoenRRDbasadoenlaplataformaRAD,yenla metodologa RUP64 31.Entorno de modelado74 32.Entorno de desarrollo75 33.Entorno mixto75 34.Crear modelo en XDE77 35.Barradeobjetosparacrearcasosdeuso(a)ycasodeusocreado en XDE (b)78 36.Diagrama de clases en XDE79 37.Ventana de propiedades para el diagrama de clases en XDE80 38.Creacin de atributos (a) y ventana de propiedades para los atributos (b) utilizados en los diagramas de clases en XDE80 39.Visibilidaddeatributosymtodosdeunaclaseutilizadaenun diagrama de clases en XDE81 40.Definicin de estereotipos para undiagrama de clases en XDE81 41.LneasparaunirartefactosutilizadasenundiagramadeclasesenXDE82 42.Relaciones entre artefactos, utilizadas en undiagrama de clases en XDE83

VII 43.Restriccionesentreartefactos,utilizadasenundiagramadeclases enXDE,(a)vistamodeladadelarestriccin(b)seleccindela restriccin83 44.Diagramadeunainterfazutilizadaenundiagramadeclasesen XDE84 45.Cualificadores entre artefactos, utilizados en undiagrama de clases en XDE, (a) vista modelada de la cualificacin (b) seleccin de la cualificacin84 46.Diagrama de secuencia (a)y barra deobjetospara creardiagramas de secuencia (b)85 47.Diagrama de estados en XDE86 48.Formadecrearunestado,utilizadoenundiagramadeestadosen XDE87 49.Accionescreadasaunestado,utilizadoenundiagramadeestados en XDE87 50.Diagrama de actividades en XDE89 51.Modeladodeunaactividad(a)yformadecrearunaactividad utilizada en un diagrama de actividades en XDE89 52.Diagrama de componentes en XDE90 53.SeleccindeAutoSyncparagenerarcdigoautomticamenteen XDE91 54.Seleccin del estilo de cdigoa generar en XDE92 55.Publicacin de cdigo en XDE93 56.Caso de uso sistema de subastas en lnea de vehculos101 57.Realizacindelcasodeusosistemadesubastasenlneadevehculos102 58.Estereotipos106 59.Diagrama de clases del anlisis de la realizacin del caso de uso108 60.Diagrama de secuencia del anlisis de la realizacin del caso de uso113

VIII 61.Diagramadecolaboracindelanlisisdelarealizacindelcasode uso114 62.Diagrama de clases del diseo de la realizacin del caso de uso119 63.Diagrama de secuencia del diseo de la realizacin del caso de uso123 64.Diagramadecolaboracindeldiseodelarealizacindelcasode uso124 65.Arquitecturaimplementadaenelsistemadesubastasenlneade vehculos127 66.Vista de despliegue del sistema de subastas en lnea de vehculos127

IX TABLAS I. Esfuerzo-horario contra fases del RUP6

X

XI GLOSARIO AUTOSYNCFuncinquerealizalageneracindecdigodeforma automtica en la herramienta XDE. B2BBusinesstoBusiness.Consisteennegocioselectrnicos entre dos empresas. B2CBusiness to Commerce. Consiste en el comercio electrnico entre empresas y clientes. BOOCHJuntamente con los mtodosObjectoryyOMT representan las notaciones bases del surgimiento del lenguaje UML. CUCasodeUso.Esunasecuenciadepasosaseguirparala realizacin de un fin o propsito. DAO DataAccessObjects.Objetoquepermitelaconexinpara la transferencia de datos. DHTMLHTMLDinmicoqueesunamejoradeMicrosoftdela versin4.0deHTMLquelepermitecrearefectos especiales. E-BUSINESSTrmino utilizado para nombrar a los Negocios mediante la Web (Internet).

XII EJBEnterpriseJavaBeans.Interfacesdeprogramacinde aplicaciones que forman parte del estndar de construccin deaplicacionesempresarialesJ2EE,proporcionanla posibilidaddeusarcomponentessoftwaretransaccionales queresidenenelservidordeaplicaciones.Estos componentesdesoftwarepuedenserusadosdesde cualquier programa Java de forma distribuida. ENTERPRISEObjetosdistribuidos,que contienen lalgica de negocioJAVA BEANS denuestrasaplicacionesyquehacentransparenteal programadoroperacionescomolapersistencia,la seguridad, la gestin de transacciones, etc. FRAMEWORKSPlantillas predefinidas, que facilitan la programacin. J2EEJava 2 Enterprise Edition. Plataforma creada por la empresa SUNenelao1997;eslaqueofreceperspectivasde desarrollo para empresas que quieran basar su arquitectura en productos basados en software libre. JADJoint Application Development. Pequeosgrupos (hasta10 personas)deusuariosyanalistasquehacen,paraenun cortoespaciodetiempo,analizaryespecificarentradas, procesosysalidas,atravsdeldesarrolloconjuntodeun prototipo de desarrollo de software. JBOSSServidordeaplicacioneslibresporexcelenciayest implementado al 100% en Java.

XIII JCPOrganismoformadoporalrededorde500empresas, asociacionesyparticulares,cuyoobjetivoesasegurarla evolucin de las plataformas basadas en Java. JONAS Servidordeaplicacionesyporsuscaractersticas,esuno delosproyectosmsambiciososdelmundodelsoftware libre en Java y pronto superar a JBoss en aceptacin. JSRJavaSpecificationRequest.Esundocumentocreadopor unapersonaoentidadquecreequeesnecesariala presenciadeunadeterminadatecnologadentrodelas plataformas basadas en Java. Dentro de este documento se relata por qu es necesaria dicha tecnologa, por qu no se puedenabordarlosproblemasquesolucionaconlas tecnologas existentes. JSRCuandounapersonaoentidadcreequeesnecesariala presenciadeunadeterminadatecnologadentrodelas plataformas basadas en Java, lo que hace es crear un JSR y presentarlo para su aprobacin. OBJECTORYJuntamente con los mtodos Booch y OMT representan las notaciones bases del surgimiento del lenguaje UML. OMG Object Management Group. Consorcio del cual forman parte las empresas ms importantes que se dedican al desarrollo de software.

XIV OMT JuntamenteconlosmtodosBoochyObjectory representanlasnotacionesbasesdelsurgimientodel lenguaje UML. OPENEJBNo es un servidor de aplicaciones completo, sino que es un contenedordeEJBs.Noseobtienetodoloqueofreceun servidor(mensajera,contenedorWeb,etc.),sinoqueslo permite utilizar ejes, esto lo hace ms ligero. RAD DesarrolloRpidodeAplicaciones.Metodologaque permitealasorganizacionesdesarrollarsistemas estratgicamenteimportantes,demaneramsrpida, reduciendo a la vez los costos de desarrollo y manteniendo lacalidad.Existenvariastecnologasqueutilizanesta metodologa y que intentan reducir el tiempo de desarrollo. RRD RationalRapidDeveloper.DiseadorRpidodeRational, herramienta que integra elmodelado visual y automatiza la construccin del sistema que permite el diseo, desarrollo y desplieguerpido,enaplicacionesdecomercioelectrnico y otras. RUPRationalUnifiedProcess.ProcesoUnificadodeRational, metodologadelprocesodeingenieradesoftwareque proporcionaunenfoquedisciplinadoparaasignartareasy responsabilidadesdentrodeunaorganizacindel desarrollo.

XV SERVLETSMdulos java que nos sirven para extender las capacidades de los servidores Web, son programas para los servidores. SISTEMAS Conectoresqueproporcionaelservidordeaplicaciones,LEGACY para acceder a otros ficheros o sistemas STAKEHOLDERPersonasuorganizacionesqueestndirectamente envueltasenlaelaboracinotomasdedecisionesclaves acerca de la funcionalidad y propiedades del Sistema. TOOLBOXOpcionesqueproveeenunmenunaherramientade desarrollo. UML UnifiedModelingLanguage.LenguajeUnificadode Modelado, notacin estndar para el modelado de sistemas software. WEBSPHEREHerramientadedesarrolloqueayudaaincrementarla eficiencia operacional, aportando agilidad y escalabilidad WORKFLOUSFlujosdetrabajo,loscualessonunasecuenciadepasos para la culminacin de cada disciplina del RUP. XDEExtended Development Environment. Herramienta diseada especialmenteparadesarrolladores,integrando herramientasdediseoydesarrollodecdigoenunnico ambiente de desarrollo tanto para la plataforma .NET como J2EE.

XVI XMLeXtensibleMarkupLanguage.Lenguajedemarcado ampliableoextensible;suobjetivoprincipalesconseguir unapginaWebmssemntica;esunestndarparael intercambio de datos entre diversas aplicaciones.

XVII RESUMEN Las metodologas y estndares utilizados en un desarrollo de software nos proporcionanlasguasparapoderconocertodoelcaminoarecorrerdesde antesdeempezarlaimplementacin,conlocualseaseguralacalidaddel producto final, as como tambin el cumplimiento en la entrega del mismo en un tiempo estipulado. Esdesumaimportanciaelegirlametodologaadecuada,ascomolas herramientasdeimplementacinadecuadas,esporelloquelametodologa RUPbasadaenUMLnosproporcionatodaslasbasesparallevaralxitola elaboracin del software, para ello la utilizacin de la herramienta RRD es una de las elecciones ms acertadas debido a que se fundamenta en el RUP para el desarrollo rpido de aplicaciones. Estetrabajoconstadecuatrocaptulos,loscualessedescribena continuacin. En el captulo uno se abarcar la explicacin de la metodologa RUP con sus bases en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos observar la interrelacin entre ambos y la importancia de su uso en el desarrollo de aplicaciones.

XVIII EnelcaptulodosseabarcarloqueeselRAD,conlocualpodemos tenerlainformacinnecesariaparaundesarrollorpidodeaplicaciones, conjuntamenteconelRRDparaobtenerlainterrelacinentreunDesarrollo Rpido de Aplicaciones utilizando la metodologa RUP, por lo tanto, nos vemos en la necesidad de seguir una serie de pasos que estn definidos en forma de estndar para poder aplicar este desarrollo rpido en un lenguaje en particular, con esto nos referimos al J2EE, el cual nos provee esta informacin, ya que se estar describiendo la funcionalidad del mismo. Ya teniendo toda esta informacin, estaremos en la capacidad de tener el conocimiento adecuado para el desarrollo de aplicaciones siguiendo modelos y estndares,porlotanto,enelcaptulotresestaremosdescribiendolas herramientasXDEyWebSphereparaelmodeladoyelaboracinde aplicaciones respectivamente, para poder relacionar el uso que se le puede dar aestasherramientassiguiendolosmodelosyestndaresdefinidosenlos primeros dos captulos. Paraterminarseestardescribiendolainterrelacinentreelestndar J2EE,lametodologaRUPconlasherramientasparaelmodeladoXDEyla herramientadedesarrolloWebSphereutilizandolaherramientaRRDbasada enRUPyRADparalainterrelacinyaslograrunDesarrolloRpidode Aplicaciones, con lo cual, se estar informando las conectividades que se tienen quedarparaquetodoestocomopartesindividualessepuedanmezclar, formandountodoconelcualsercapacesdeconseguirelaboracinde aplicaciones de forma rpida y que cumplan con la funcionalidad requerida.

XIX OBJETIVOS General ExplicarcmoseinterrelacionanelestndarJ2EEylametodologa RUPbasadaenUML,paraelDesarrolloRpidodeAplicacionesconlas herramientasdemodeladoXDEydesarrolloWebSphere,utilizandola herramienta RRDbasada en RUP y RAD para la interrelacin. Especficos 1.Describir el funcionamiento de la metodologa RUP, el lenguaje UML y el enlace entre ellos. 2.Describir el Desarrollo Rpido de Aplicaciones y su metodologa. 3.Describir las caractersticas y funcionalidad delestndar J2EE. 4.DescribirlascaractersticasdelaherramientademodeladoXDEyla herramienta de desarrollo WebSphere. 5.ExplicarlaHerramientaRRDparautilizarlaenunDesarrolloRpidode Aplicaciones. 6.Conocer la interrelacin entre la metodologa RUP y la herramienta RRD.

XX

XXI INTRODUCCIN Enlaactualidad,lautilizacindemetodologasparaeldesarrollode aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variablesqueconllevaelmismodesarrollo,yparalaordenadaelaboracinde lasaplicaciones,porlotanto,seguirmetodologasyestndaresnosllevana estar en competitividad en todo momento. Esdesumaimportanciaconocerelmodocomoseinterrelacionan metodologasconestndaresyherramientassiguiendounnicopropsito,el cual consiste en la elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos. LametodologaRUPnosproporcionadisciplinasenlascualesse encuentranartefactosconlocualsepodrcontarconguasparapoder documentar e implementar de una manera fcil y eficiente, todas las guas para unbuendesarrollo,todoestodentrodelasrespectivasfasesconlascuales cuenta. Al contar con las guas en las cuales nos podremos basar durante todo el desarrollo, sepodrutilizar laherramienta RRD basadaen elRUP para poder implementar todo lo prescrito en nuestras guas de una manera segura y sobre todo rpida.

XXII Adems,contandoconelestndarJ2EEsepodrentrelazarla metodologaRUPconste,yaqueseofreceunagraninteroperabilidadentre ambos, con lo cual laimplementacindel softwareutilizandoRRDse realizar de una manera mucho ms sencilla, ordenada y eficiente. No es posible realizar un desarrollo de software de una manera lenta, ya que las exigencias de los clientes actuales conllevan a verse en la necesidad de implementarsolucionesrpidasyquecumplanconlosrequerimientos planteados,porloqueelDesarrolloRpidodeAplicacionesesunadelas caractersticasquemsimpactotieneenlaactualidad,parasolventarestose deben utilizar herramientas basadas en este nuevo enfoque. 1 1.METODOLOGA DE DESARROLLO APLICADA 1.1.Introduccin al RUP LassiglasRUPeninglessignificaRationalUnifiedProcess(Proceso Unificado de Rational) es un producto del proceso de ingeniera de software que proporcionaunenfoquedisciplinadoparaasignartareasyresponsabilidades dentro de una organizacin del desarrollo.Su meta es asegurar la produccin delsoftwaredealtacalidadqueresuelvelasnecesidadesdelosusuarios dentro de un presupuesto y tiempo establecidos. 1.1.1.Dimensiones del RUP El RUP tiene dos dimensiones: El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. Elejeverticalrepresentalasdisciplinas,queagrupanactividades definidas lgicamente por la naturaleza. Laprimeradimensinrepresentaelaspectodinmicodelprocesoyse expresaen trminosde fases,de iteraciones,y la finalizacinde las fases.La segundadimensinrepresentaelaspectoestticodelproceso:cmose describeentrminosdecomponentesdeproceso,lasdisciplinas,las actividades, los flujos de trabajo, los artefactos, y los roles. 2 En la figura 1 se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases.Por ejemplo, eniteracionestempranas,pasamosmstiempoenrequerimientos,yenlas ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en si. Figura 1. Disciplinas, fases, iteraciones del RUP Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: 3 Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin delosCasosdeUsoparaeldesenvolvimientoydesarrollodelas disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP.Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de unfinopropsito,yserelacionadirectamenteconlosrequerimientos,ya que un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente. ProcesoIterativoeIncremental:EselmodeloutilizadoporRUPparael desarrollodeunproyectodesoftware.Estemodeloplanteala implementacindelproyectoarealizarenIteraciones,conlocualse puedendefinirobjetivosporcumplirencadaiteracinyaspoderir completandotodoelproyectoiteracinporiteracin,conlocualsetienen variasventajas,entreellassepuedemencionarladetenerpequeos avances del proyectos que son entregables al cliente el cual puede probar mientrasseestadesarrollandootraiteracindelproyecto,conlocualel proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica mas adelante a detalle. Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, yunaarquitecturaejecutableconstruidacomounprototipoevolutivo. Arquitecturadeunsistemaeslaorganizacinoestructuradesuspartes ms relevantes.Una arquitectura ejecutable es una implementacin parcial delsistema,construidaparademostraralgunasfuncionesypropiedades.RUPestablecerefinamientossucesivosdeunaarquitecturaejecutable, construida como un prototipo evolutivo. 4 1.1.2.Fases Figura 2. Fases del RUP ElciclodevidadelsoftwaredelRUPsedescomponeencuatrofases secuenciales (figura 2).En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de lafinalizacin de fase) para determinar si los objetivos de la fase se han cumplido.Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase. 1.1.2.1.Planeando las fases Elciclodevidaconsisteenunaseriedeciclos,cadaunodeloscuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cadaunadeestasfasesestcompuestaporunnmerodeiteraciones,estas fases son: 1. Concepcin, Inicio o Estudio de oportunidad Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto 5 2. Elaboracin Tantolafuncionalidadcomoeldominiodelproblemaseestudianen profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles 3. Construccin Elproductosedesarrollaatravsdeiteracionesdondecadaiteracin involucra tareas de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que esaqurefinadademaneraincrementalconformeseconstruye(se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo Estafaseproporcionaunproductoconstruidojuntoconla documentacin 4. TransicinSe libera el producto y se entrega al usuario para un uso real Seincluyentareasdemarketing,empaquetadoatractivo,instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Losmanualesdeusuariosecompletanyrefinanconlainformacin anterior Estas tareas se realizan tambin en iteraciones Todaslasfasesnosonidnticasentrminosdetiempoyesfuerzo.Aunqueestovaraconsiderablementedependiendodelproyecto,unciclode desarrolloinicialtpicoparaunproyectodetamaomedianodebeanticiparla distribucin siguiente el esfuerzo y horario: 6 Tabla I. Esfuerzo-horario contra fases del RUP ConcepcinElaboracinConstruccinTransicin Esfuerzo~5 %20 %65 %10% Horario10 %30 %50 %10% Lo cul se puede representar grficamente como se muestra en la figura 3: Figura 3. Recursos utilizados en las fases del RUP en el tiempo. Enuncicloevolutivo,lasfasesdeconcepcinyelaboracinseran considerablementemspequeas.Algunasherramientasquepueden automatizar una cierta porcin del esfuerzo de la fase de Construccin pueden atenuaresto,haciendoquelafasedeconstruccinseamuchomspequea quelasfasesdeconcepcinyelaboracinjuntas.Esteesprecisamenteel objetivo del trabajo. Cada paso con las cuatro fases produce una generacin del software.A menosqueelproducto"muera",sedesarrollarnuevamenterepitiendola mismasecuencialasfasesdeconcepcin,elaboracin,construcciny transicin, pero con diversos nfasis cada fase. 7 Estos ciclos subsecuentes se llaman los ciclos de la evolucin.Mientras queelproductopasadurantevariosciclos,seproducenlasnuevas generaciones.En la figura 4 se muestre este ciclo evolutivo. Figura 4. Ciclo evolutivo en la elaboracin de software basado en el RUP Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por elusuario,cambiosenelcontextodelusuario,cambiosenlatecnologa subyacente,reaccinalacompeticin,etctera.Losciclosevolutivostienen tpicamentefasesdeconcepcinyelaboracinmuchomscortas,puestoque ladefinicinylaarquitecturabsicasdelproductosondeterminadasporlos ciclosdedesarrolloanteriores.Lasexcepcionesaestareglasonlosciclos evolutivosenloscualesocurreosurgeunproductosignificativoouna redefinicin arquitectnica. 1.1.2.2.Esfuerzo respecto de los flujos de trabajo Enlafigura5semuestranciertosporcentajes,deformaverticalse muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. 8 Explicando mas puntualmente la figura 5 se puede observarque para la obtencin de requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va declinando en la fase de construccin, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y as sucesivamente con las dems disciplinas. Enesta seccinyla siguiente, los porcentajes pueden variar de un proyecto a otro Figura 5. Esfuerzo respecto de los flujos de trabajo 1.1.2.3.Esfuerzo respecto de las fases En la figura 6 se muestran dos filas de porcentajes, el primero que es el esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones dentrodecadafase;yenlasegundafila,laduracinquetiene aproximadamenteenporcentajesdeltiempototaldelproyectoparacadauna de las fases incluyendo todas las iteraciones que conlleven realizar cada fase. 9 Explicando ms puntualmente una pequea parte de la figura 6 se puede observar que para la fase de construccin se tiene que dedicar ms esfuerzo y mayorduracin,siempreycuandodependiendodequedisciplinaestemos ejecutando,porejemploenladisciplinadeimplementacinsetienemucho auge en la fase de construccin. Figura 6. Esfuerzo respecto de las fases 1.1.3.Iteraciones El RUP maneja el proceso Iterativo Incremental para el desarrollo de las aplicacionesoproyectos,portalmotivoesdesumaimportanciaexplicar brevemente en que consiste este proceso. 10 1.1.3.1.Proceso Iterativo e Incremental Este proceso se refiere a la realizacin de un ciclo de vida de un proyecto ysebasaenlaevolucindeprototiposejecutablesquesemuestranalos usuarios y clientes. En este ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una iteracinenfuncindelaevaluacindelasiteracionesprecedentesylas actividades se encadenan en una mini-cascada con un alcance limitado por los objetivosdelaiteracin.Enlafigura7semuestranlospasosarealizarpara seguir el ciclo de vida iterativo incremental, hasta la realizacin de una fase. Figura 7. Ciclo de vida Iterativo incremental AnlisisDiseoCodific.Pruebas eIntegracinn veces Paralarealizacindecadaiteracinsetienequetomarencuentala planificacin de la iteracin, estudiando los riesgos que conlleva su realizacin, tambinincluyeelanlisisdeloscasosdeusoyescenarios,eldiseode opcionesarquitectnicas,lacodificacinypruebas,laintegracingradual durantelaconstruccindelnuevocdigoconelexistentedeiteraciones anteriores,laevaluacindelaentregaejecutable(evaluacindelprototipoen funcindelaspruebasydeloscriteriosdefinidos)ylapreparacindela entrega(documentacineinstalacindelprototipo).Algunosdeestos elementos no se realizan en todas las fases. 11 Acontinuacinsepresentaunacomparacinentre2enfoquesdeun ciclo de vida del desarrollo de software, el primero consiste en el ciclo comn, el deCascada(figura8),enelcualcadadisciplinaserealizaalfinalizarsu predecesoraysoloalfinalizarlanuevaseempiezalasucesorayashasta terminar con las disciplinas necesarias. Figura 8. Enfoque cascada Enlafigura9semuestraelciclodevidadeunsoftwaresiguiendoel enfoqueIterativoIncremental(utilizadoporelRUP),enelcualsepuede observar que en cada iteracin se realiza una pequea parte de cada disciplina enparalelo,aumentandoaspocoapocohastaconcluirconlarealizacinde todaslasdisciplinasconunnumerodeiteracionesprudente.Enlagrfica siguientesehabladeingenieradelnegocioyenlasiguienteseccinde modeladodelnegocio,esnecesarioconservarlaconsistenciadeestoentodo el trabajo, una u otra. 12 Figura 9. Ciclo de vida de un software con un enfoque iterativo incremental 1.1.4.Disciplinas Lasdisciplinasconllevanlosflujosdetrabajo,loscualessonuna secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividenendosgrupos:lasprimariasylasdeapoyo.Lasprimariassonlas necesariasparalarealizacindeunproyectodesoftware,aunquepara proyectosnomuygrandessepuedenomitiralgunas;entreellassetienen: ModeladodelNegocio,Requerimientos,AnlisisyDiseo,Implementacin, Pruebas,Despliegue.Lasdeapoyosonlasquecomosunombreloindica sirvendeapoyoalasprimariasyespecificanotrascaractersticasenla realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios.A continuacin se describe rpidamente cada una de estas disciplinas.

13 1.1.4.1.Modelado del negocio Estadisciplinatienecomoobjetivoscomprenderlaestructurayla dinmicadelaorganizacin,comprenderproblemasactualeseidentificar posiblesmejoras,comprenderlosprocesosdenegocio.UtilizaelModelode CUdelNegocioparadescribirlosprocesosdelnegocioylosclientes,elModelodeObjetosdelNegocioparadescribircadaCUdelNegocioconlos Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. 1.1.4.2.Requerimientos Estadisciplinatienecomoobjetivosestablecerloqueelsistemadebe hacer(EspecificarRequisitos),definirloslmitesdelsistema,yunainterfazde usuario,realizarunaestimacindelcostoytiempodedesarrollo.UtilizaelModelodeCUparamodelarelSistemaquecomprendenlosCU,Actoresy Relaciones,ademsutilizalosdiagramasdeEstadosdecadaCUylas especificaciones suplementarias. 1.1.4.3.Anlisis y diseo Esta disciplinadefine laarquitecturadel sistemay tiene como objetivos trasladarrequisitosenespecificacionesdeimplementacin,aldeciranlisisse refiereatransformarCUenclases,yaldecirdiseoserefierearefinarel anlisisparapoderimplementarlosdiagramasdeclasesdeanlisisdecada CU,losdiagramasdecolaboracindedecadaCU,eldeclasesdediseode cadaCU,eldesecuenciadediseodeCU,eldeestadosdelasclases,el modelo de despliegue de la arquitectura. 14 1.1.4.4.Implementacin Estadisciplinatienecomoobjetivosimplementarlasclasesdediseo comocomponentes(ej.ficherofuente),asignarloscomponentesalosnodos, probarloscomponentesindividualmente,integrarloscomponentesenun sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamentelosDiagramasdeComponentesparacomprendercmose organizan los Componentes y dependen unos de otros. 1.1.4.5.Pruebas Estadisciplinatienecomoobjetivosverificarlaintegracindelos componentes(pruebadeintegracin),verificarquetodoslosrequisitoshan sidoimplementados(pruebasdelsistema),asegurarquelosdefectos detectados han sido resueltos antes de la distribucin 1.1.4.6.Despliegue Estadisciplinatienecomoobjetivosasegurarqueelproductoest preparado para el cliente, proceder a su entrega y recepcin por el cliente. En estadisciplina se realizan lasactividadesde probar el softwareen suentorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. 15 1.1.4.7.Gestin y configuracin de cambios Esesencialparacontrolarelnmerodeartefactosproducidosporla cantidad de personal que trabajan en un proyecto conjuntamente.Los controles sobreloscambiossondemuchaayudayaqueevitanconfusionescostosas como la compostura de algo que ya se haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: Actualizacinsimultnea:Eslaactualizacindealgoelaboradocon anterioridad, sin saber que alguien ms lo est actualizando. Notificacinlimitada:Alrealizaralgunamodificacin,nosedeja informacin sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones. 1.1.4.8.Gestin del proyecto Su objetivo esequilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades deambosclientesconxito(losquepaganeldinero)ylosusuarios.Conla Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software.En resumen su propsito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo. 16 Sinembargo,estadisciplinanointentacubrirtodoslosaspectosde direccin del proyecto. Por ejemplo, no cubre problemas como:Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes. 1.1.4.9.Entorno Estadisciplinaseenfocasobrelasactividadesnecesariaspara configurarelprocesoqueenglobaeldesarrollodeunproyectoydescribelas actividades requeridas para el desarrollo de las pautas que apoyan un proyecto.Supropsitoesproveeralaorganizacinquedesarrollarelsoftware,un ambienteenelcualbasarse,elcualproveeprocesosyherramientaspara poder desarrollar el software. 1.1.5.Organizacin y elementos en RUP Yaconociendo varias partes del RUP nos concentraremos ahora en los elementosquelocomponen,entreestossetienen:FlujosdeTrabajo,Detalle de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura 10 se muestranmasclaramentecomoserepresentangrficamentecadaunode estos elementos y la interrelacinentre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su ves son los encargados de laejecucindevariasactividades,lascualesalavezestndefinidasen artefactos o guas para su realizacin. 17 Figura 10. Elementos que conforman el RUP 1.1.5.1.Actores o roles Sonlospersonajesencargadosdelarealizacindelasactividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estosactoressedividenenvariascategoras:Analistas,Desarrolladores, Probadores, Encargados, Otrosactores. A continuacin se presenta una lista de actores de acorde a las categoras mencionadas con anterioridad: Analistas Analista del Proceso del Negocio Diseador del Negocio Revisor del Modelo del Negocio Revisor de Requerimientos Analista del Sistema Especificador de Casos de Uso Diseador de Interfaz del Usuario 18 Desarrolladores Arquitecto Revisor de la Arquitectura Diseador de Cpsulas Revisor del Cdigo y Revisor del Diseo Diseador de la Base de Datos Diseador Implementador y un Integrador Probadores Profesionales Diseador de Pruebas Probador EncargadosEncargado de Control del Cambio Encargado de la Configuracin Encargado del Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto Otros Cualquier trabajador Artista Grfico Stakeholder Administrador del Sistema Escritor tcnico Especialista de Herramientas 19 1.1.5.2.Artefactos Losartefactossonelresultadoparcialofinalqueesproducidoyusado porlosactoresduranteelproyecto.Sonlasentradasysalidasdelas actividades,realizadasporlosactores,loscualesutilizanyvanproduciendo estosartefactosparatenerguas.Unartefactopuedeserundocumento,un modelo o un elemento de modelo. 1.1.5.2.1.Conjuntos de artefactos Setieneunconjuntodeartefactosdefinidosencadaunadelas disciplinasyutilizadasdentrodeellasporloactoresparalarealizacindelas mismas,acontinuacinsedefinencadaunadeestascategorasogruposde artefactos dentro de las disciplinas del RUP: a)Modelado del negocio Losartefactosdelmodeladodelnegociocapturanypresentanel contextodelnegociodelsistema.Losartefactosdelmodeladodelnegocio sirven como entraday comoreferencia para los requisitos del sistema. b)Requerimientos Losartefactosderequerimientosdelsistemacapturanypresentanla informacin usada en definir las capacidades requeridas del sistema. 20 c)Anlisis y diseo del sistema Losartefactosparaelanlisisydeldiseocapturanypresentala informacin relacionada con la solucin a los problemas se presentaronen los requisitos fijados. d)Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema. e)Pruebas Losartefactosdesarrolladoscomoproductosdelasactividadesde pruebay de la evaluacin sonagrupadas por el actor responsable, con el cual sellevaunconjuntodedocumentosdeinformacinsobrelaspruebas realizadas y las metodologas de pruebas aplicadas. f)Despliegue Losartefactosdeldesplieguecapturanypresentanlainformacin relacionadaconlatransitividaddelsistema,presentadaenlaimplementacin en el ambiente de la produccin. g)Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con elproyecto, el planeamiento y a la ejecucin del proceso. 21 h)Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentanlainformacinrelacionadaconladisciplinadeconfiguraciny administracin del cambio. i)Entorno o ambiente Elconjuntodeartefactosdelambientepresentanlosartefactosquese utilizancomodireccinatravsdeldesarrollodelsistemaparaasegurarla consistencia de todos los artefactos producidos. 1.1.5.2.2.Grado de finalizacin de artefactos Consisteencuantohemosfinalizadodelartefactopropuesto,conesto nos referimospor ejemplo, si definimos que vamos a utilizar un artefacto, este nosdiceloslineamientosquenecesitaparasercompletado,porlotantocon grado de finalizacin nos referimos a cuantos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se encuentre, para entender de mejor manera lo antes dicho se muestralafigura11,enlacualsepuedeobservarqueenlafasede Concepcin,enladisciplinadeImplementacindelSistemalosartefactos tienenunapocafinalizacinyvanaumentandoprogresivamenteencadafase hastallegarasuculminacinenlafasedeTransicin,enladisciplinade Ingeniera delNegocio los artefactos tienenuna media finalizaciny sucede lo mismoqueconlosartefactosdeladisciplinaanteriorloscualesfinalizan tambin en la fase de Transicin. 22 Figura 11. Grado de finalizacin de artefactos Conestosepuedemostrarelaumentoprogresivodelosartefactosen cada disciplina en la fase dada, teniendo una idea un poco ms amplia sobre el desenvolvimiento del proyecto hablando en trminos de sus artefactos. 1.2.Introduccin al UML UMLsurgecomorespuestaalproblemadecontarconunlenguaje estndarparaescribirplanosdesoftware.Muchaspersonashancredover UML como solucin para todos los problemas sin saber en muchos casos de lo que se trataba en realidad. 23 El Lenguaje Unificado de Modelado, UML es una notacin estndar para elmodeladodesistemassoftware,resultadodeunapropuestade estandarizacin promovida por el consorcio OMG (Object Management Group), delcualformanpartelasempresasmsimportantesquesededicanal desarrollo de software, en 1996. UMLrepresentalaunificacindelasnotacionesdelosmtodosBooch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodlogos entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel,RichardHelm,RalphJohnson,StephenMellor,BertrandMeyer,Jim Odell,KennyRubin,SallyShlaer,JohnVlissides,PaulWard,RebeccaWirfs-Brock y Ed Yourdon.EnSeptiembrede2001sehapublicadalaespecificacindelaversin 1.4. Es importante recalcar que slo se trata de una notacin, es decir, de una seriedereglasyrecomendacionespararepresentarmodelos.UMLnoesun procesodedesarrollo,esdecir,nodescribelospasossistemticosaseguir paradesarrollarsoftware.UMLslopermitedocumentaryespecificarlos elementoscreadosmedianteunlenguajecomndescribiendomodelos.Enla figura12sepuedeobservareldesarrollodeUMLysusversionesenloaos dados,sufriendorevisionesmenores,yciertosparticipantesenlasdiversas versiones. 24 Figura 12. Desarrollo de UML, con sus versiones 1.2.1.Descripcin del lenguaje UMLesunlenguajedepropsitogeneralparaelmodeladoorientadoa objetos,quecombinanotacionesprovenientesdesde:ModeladoOrientadoa Objetos,ModeladodeDatos,ModeladodeComponentes,ModeladodeFlujos de Trabajo (Workflows). Entodoslosmbitosdelaingenieraseconstruyenmodelos,en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamosadesarrollar:losarquitectosutilizanyconstruyenplanos(modelos)de los edificios, los grandes diseadores de coches preparan modelos en sistemas existentescontodoslosdetallesylosingenierosdesoftwaredeberan igualmente construir modelos de los sistemas software. 25 Unenfoquesistemticopermiteconstruirestosmodelosdeunaforma consistentedemostrandosuutilidadensistemasdeciertotamao.Cuandose trata de un programa de cincuenta, cien lneas, la utilidad del modelado parece discutibleperocuandoinvolucramosacientosdedesarrolladorestrabajandoy compartiendoinformacin,elusodemodelosyelproporcionarinformacin sobrelasdecisionestomadas,esvitalnosloduranteeldesarrollodel proyecto,sinounavezfinalizadoste,cuandoserequierealgncambioenel sistema.Enrealidad,inclusoenelproyectomssimplelosdesarrolladores hacen algo de modelado, si bien informalmente. Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los dems, por lo cual con un nico modelo no tenemos bastante. 1.2.1.1.Inconvenientes en UML ComotodoeneldesarrollodesoftwareUMLpresentaciertos inconvenientes,entreloscualessepuedenmencionar:Faltaintegracincon respectodeotrastcnicastalescomopatronesdediseo,interfacesde usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML. 1.2.1.2.Perspectivas de UML TambinseprevvariasperspectivasdeUMLyaqueporserun lenguajedepropsitogeneralserunlenguajedemodeladoorientadoa objetosestndarpredominantelosprximosaos,estosebasaenlas siguientes razones: 26 Participacin de metodlogos influyentes Participacin de importantes empresas Aceptacin del OMG como notacin estndar Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc. 1.2.2.Descripcin de los diagramas Unmodelocapturaunavistadeunsistemadelmundoreal.Esuna abstraccindedicho sistema, considerando un cierto propsito. As,el modelo describecompletamenteaquellosaspectosdelsistemaquesonrelevantesal propsito del modelo, y a un apropiado nivel de detalle. Undiagramaesunarepresentacingrficadeunacoleccinde elementosdemodelado,amenudodibujadacomoungrafoconvrtices conectados por arcos Unprocesodedesarrollodesoftwaredebeofrecerunconjuntode modelos que permitan expresar el producto desde cada una de las perspectivas de inters. EsaqudondesehaceevidentelaimportanciadeUMLenel contexto de un proceso de desarrollo de software. Elcdigofuentedelsistemaeselmodelomsdetalladodelsistema(y adems es ejecutable). Sin embargo, se requieren otros modelos. 27 Figura 13. Relaciones de enlaces entre modelos Cadamodeloescompletodesdesupuntodevistadelsistema,sin embargo, existen relaciones de enlaces entre los diferentes modelos (figura 13). Variosmodelosaportandiferentesvistasdeunsistemaloscualesnos ayudanacomprenderlodesdevariosfrentes.As,UMLrecomiendala utilizacindenuevediagramasque, para representar las distintas vistas deun sistema. Estos diagramas de UML se presentan en la figura14 y se describen a continuacin: Figura 14. Diagramas, partes de un modelo 28 a)DiagramadeCasosdeUso:modelalafuncionalidaddelsistema agrupndolaendescripcionesdeaccionesejecutadasporunsistema para obtener un resultado. b)Diagrama de Clases: muestra las clases (descripcionesdeobjetos que comparten caractersticas comunes) que componen el sistema y cmo se relacionan entre s. c)DiagramadeObjetos:muestraunaseriedeobjetos(instanciasdelas clases) y sus relaciones. d)DiagramasdeComportamiento:dentrodeestosdiagramasse encuentran: DiagramadeEstados:modelaelcomportamientodelsistemade acuerdo con eventos. DiagramadeActividades:simplificaelDiagramadeEstados modelandoelcomportamientomedianteflujosdeactividades.Tambinsepuedenutilizarcaminosverticalesparamostrarlos responsables de cada actividad. Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan: Diagrama de Secuencia: enfatiza la interaccin entre los objetos ylosmensajesqueintercambianentresjuntoconelorden temporal de los mismos. 29 DiagramadeColaboracin:igualmente,muestralainteraccin entrelosobjetosresaltandolaorganizacinestructuraldelos objetos en lugar del orden de los mensajes intercambiados. e)Diagramas de implementacin DiagramadeComponentes:muestralaorganizacinylas dependencias entre un conjunto de componentes. Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribucin en el mismo. 1.3.Metodologa del RUPpara anlisis y diseo ElRUPproponelautilizacindelosmodelosparalaimplementacin completa de todas sus fases respectivamente con sus disciplinas: ModelodeCasosdeUsodelNegocio:DescribelarealizacindelCaso de Uso, es realizado en la disciplina de Modelado del Negocio.Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la organizacin, es realizado en la disciplina de Modelado del Negocio. Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y suambiente,ademssirvecomouncontratoentreelclienteylos diseadores.Esconsideradoesencialaliniciarlasactividadesde anlisis,diseoyprueba;estemodeloesrealizadoenladisciplinade Requerimientos. 30 Modelo de Anlisis: Contiene los resultados del anlisis del Caso de Uso, ycontieneninstanciasdelartefactodeAnlisisdeClases;esrealizado en la disciplina de Anlisis y Diseo. ModelodeDiseo: Es un modelode objetos quedescribe larealizacin delCasodeUso,ysirvecomounaabstraccindelmodelode implementacinysucdigofuente,esutilizadocomoentradaenlas actividades de implementacin y prueba; este modelo se realizado en la disciplina de Anlisis y Diseo. ModelodeDespliegue:Muestralaconfiguracindelosnodosdel procesoentiempodeejecucin,muestraloslazosdecomunicacin entre estos nodos, as como las de los objetos y componentes que en el se encuentran; se realizado en la disciplina de Anlisis y Diseo. Modelo de Datos: Es un subconjunto del modelo de implementacin que describelarepresentacinlgicayfsicadedatospersistentesenel sistema.Tambinincluyecualquierconductadefinidaenlabasede datos como disparadores, restricciones, etc. Es elaborado en la disciplina de Anlisis y Diseo. ModelodeImplementacin:Esunacoleccindecomponentes,yde subsistemasdeaplicacinquecontienenestoscomponentes,entre estosestnlosentregables,ejecutables,archivosdecdigofuente.Es realizado en la disciplina de Implementacin. Modelo de Pruebas: Es utilizado para la elaboracin de las pruebas, y se realiza en la disciplina de Pruebas. EstosmodelosrepresentanlosdiagramasqueproponeelUMLparael desarrollodemodeladodeunproyectodesoftware,conloscualessepuede representar los propuesto por UML mediante la metodologa RUP utilizando las herramientas que esta provee para la implementacin fcil, clara y estructurada de los diagramas utilizados. 31 1.3.1.Descripcin de estereotipos ParapoderentenderlainterrelacinquetieneUMLconRUPsetiene que saber que el inicio de todo est con los casos de uso, para poder tener una basesobrelocualsequieretrabajar,loscasosdeusosonlabaseparaesta tcnica;luegoseprocedealaobtencindelosdiagramasexpuestos anteriormente,dependiendodecualessonlosnecesariosdeimplementar, luegoseprocedealaidentificacindelosestereotipos,yaquecadaunode estosrepresentanlasfuncionesquesevanadefinirdentrodelosdiagramas, estos diagramas nos ayudan a entender la lgica del caso de uso expuesto. Lasclases,aligualquelosdemselementosnotacionalesdelUML, puedenestarclasificadasdeacuerdoavarioscriterios,comoporejemplosu objetivo dentro de un programa. Esta clasificacin adicional se puede expresar mediante la utilizacin de estereotipos. Figura 15. Ejemplo de estereotipo Enlafigura15,Auto3DestclasificadoconelestereotipoMundo (denotado por ), y la clase Window con el de interfaz. Ntese que tambin lasrelacionespuedentenerestaclasificacin,enestecasolarelacinse identifica como Observer. 32 Losestereotiposmscomunesutilizadosparaclasificarlasclasesson: Entidad(entity),Frontera(boundary),Control(control).Seproponenvarias pautas a seguir a la hora de encontrar las clases de nuestro sistema durante la fasedeanlisis.Dichaspautassecentranenlabsquedadelosestereotipos entidad, control y frontera:Unaclaseentidadmodelalainformacindelargavidaysu comportamiento asociado. Este tipo de clase suele reflejar entidades del mundorealoelementosnecesariospararealizartareasinternasal sistema. Tambin se denominan clase dominio, ya que suelen tratar con abstracciones de entidades del mundo real.Una clase frontera maneja comunicaciones entre el entorno del sistema y elsistema,suelenproporcionarlainterfazdelsistemaconunusuarioo conotrosistema,engeneral,portanto,modelanlasinterfacesdel sistema.Cuandosetratadeclasesquedefinenlainterfazconotro sistema se refinarn durante la fase de diseo, para tener en cuenta los protocolos de comunicacin elegidos.Unaclasecontrolmodelaelcomportamientosecuenciadoespecficode uno o varios casos de uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinmica. 1.3.2.Enlace del RUP con el UML Conociendolosestereotiposutilizadosparalarepresentacindelas clases(Entidad,ControlyFrontera),ahorapodemosexplicarlainterrelacin que existe entre el UML y RUP describiendo los diagramas que describe UML y como se convierten en diagramas del RUP que utilizan estos estereotipos. 33 El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el RUP, la nica diferencia es la forma de dibujar los estereotipos, ya que en el RUP son una elipse con una diagonal al lado derecho (pero esto es para casos de uso de negocio, los de sistema no tienen la diagonal), y en UML solamente una elipse, pero en el RUP significa lo mismo a lo que se refiere en UML.En la figura 16 se muestra lo descrito anteriormente, aunque no nos importa en este caso el motivo por el cual se hicieron los diagramas, o la utilizacin que se les dio,yaquenicamentenosinteresaconocerlaformadedibujarambos diagramas para conocer sus diferencias: Figura 16. Comparacin entre diagramas de casos de uso (a) RUP (b) UML

(a) (b) LosdiagramasdeClasestienenlamismalgicaparalocualfueron creadosenamboslenguajes,solamenteconlasdiferenciasenlaformade dibujar los cuadros que indican las clases, por ejemplo se pueden observar en las siguientesfiguras17(a)y17(b), queenel RUP se dibujan loscuadros con unapestaainferiorderechadoblada,yenUMLsolamenterectnguloscon ngulosrectos;otracaractersticaquesepuedeobservaresquealahorade ejemplificarlasrelacionesunoauno,unoamuchosetc.,serealizande diferentemanera.Peroenamboslenguajessepuedeobservarquelos diagramas de clases son lo ms cercano a la elaboracin de un modelo Entidad Relacin para la puesta en prctica de la finalizacin del proyecto de software. 34 Figura 17. Comparacin entre diagramas de clases (a) RUP (b) UML (a) CompaanombredireccinPersonanombres.s.0.. 1*jefe0.. 1Administraempleado*0..10..1mujer0..1casado-conmarido0..1** trabaja-para* emplea-a* (b) Losdiagramasdeobjetos,difierennicamenteenlaformacomose dibujanlosobjetosoinstanciasdelasclases,yaqueenelRUPsedibujan crculosconunadiagonalenlaparteinferiorderecha,yenUMLcomo rectngulosconlasesquinasredondeadas,tambinenRUPnosecolocan flechasindicativas,yenUMLsi.Enlassiguientesfigurassepresentanlas diferencias planteadas anteriormente, es importante mencionar que la lgica de cada figura no nos importa en este momento, solamente deseamos representar laformaenquesedibujanlosobjetos,estoyaquecadaunadelasfiguras 18(a) y 18(b) se refieren a distintos ejemplos. 35 Figura 18. Comparacin entre diagramas de objetos (a) RUP (b) UML (a) (b) Lossiguientesdosdiagramas(figura19(a)y(b))presentanlaforma comoseelaboraundiagramadeestadosenRUPyUML,sepuedeobservar quedeigualmaneraseelaboranambos,nicamentequeeneldiagramade UMLsemuestranunosrectngulosconlaesquinasuperiorderechadoblada, que indican notas sobre este estado. Figura 19. Comparacin entre diagramas de estados (a) RUP (b) UML

(a)(b) 36 Enlosdiagramasdeactividadesseutilizantodoslosbloquesutilizados enlaelaboracindediagramasdeflujo,porlotantoenamboslenguajesse utilizanlosmismos,acontinuacinpodemosverlafigura20quemuestra ejemplos de ambos lenguajes, aunque el enfoque de cada diagrama presentado esdistinto,solamentesetomarondeejemplosparaejemplificarlosbloques utilizados. Figura 20. Comparacin entre diagramas de actividades (a) RUP (b) UML

(a) (b) Enlosdiagramasdesecuenciasepuedenencontrardiferenciasleves, como se puede mostrar en la figura 21 los diagramas de secuencia de UML no llevanlossmbolosqueidentificanlosestereotiposinterfase(crculoconuna rayahorizontaldelladoizquierdoyjuntoaestaotravertical),control(crculo conunaflechasobresubordeapuntandoalladoizquierdo)yentidad(crculo conunarayahorizontalenlaparteinferiordelmismo),representadospor crculos con caractersticas independientes 37 Figura 21. Diagrama de secuencia Losdiagramasdecolaboracinserepresentansimilares,conlanica diferenciadelosbloquesquerepresentanlasclases,yaqueenelRUPse representanpormediodeloscrculosconsuscaractersticasindividualesde acordealafuncinquedesempean(interfaz,control,entidad),yenUML solamentecomorectngulos.Enambossecolocanlasactividadesque conllevanrealizarparallegaraunaclasedeterminada,estosecoloca directamenteenlaflechadibujadaenlalneaquevahacialaclase.Estose puede observar en la figura 22. 38 Figura 22. Comparacin entre diagramas de colaboracin (a) RUP (b) UML

(a) (b) Dentrodelosdiagramasdeimplementacinseencuentranlosde componentes(figura23),loscualesserepresentandemanerasimilaren ambos lenguajes, como se muestra en la figura siguiente. Figura 23. Diagrama de componentes Ladiferenciabsicaenlosdiagramasdedespliegue(figura24)esque enUMLsedibujandentrodelascajasloscomponentesutilizados,encambio enelRUPsediagramandeformaseparadacomosemuestranenlasfiguras siguientes. 39 Figura 24. Comparacin entre diagramas de despliegue (a) RUP (b) UML (a) (b) Sepuedeobservarentodoslosdiagramaspresentadosanteriormente quelasimilitudentreamboslenguajesesdemasiadogrande,yesdeesperar esto,yaqueRUPutilizalosdelUMLyporlotantorecopilatodoloqueeste lenguajenecesitaparalaimplementacin,yagregamejoras,siendouna herramientademodeladomuyeficiente,yaqueproporcionatodaslas herramientas necesarias para tal funcin, por lo tanto la funcionalidad completa deUMLestadescritaeimplementadaporelRUP,solamentemejorandolas caractersticas como el cambio de ciertos diagramas de una manera sutil, para diferenciarmasclaramentequeesloqueseestahaciendoynoperderel enfoque de lo que se desea. 40 1.3.3.Descripcin del mtodo Primero que todo debemos recordar que existe un Caso de Uso, el cual nosdicelasecuenciadepasosaseguirparacompletarunobjetivo,adems esteCasodeUsotieneinteraccionesconUsuariosoActores,ascomocon otros Casos de Uso. Tambinrecordemosqueexisten3estereotipos principales: Frontera o Presentacin, Control y Entidad. Ahora bien, es muy sencilla la implementacin de este mtodo y consiste enpasarloqueseconocecomoCasodeUso(talycomoloentiendeel Cliente),alaRealizacindelCasodeUso(talycomoloentiendenlos desarrolladores del sistema). nicamentesedebededesglosarelCasodeUsoycomprendercon quienes o que va a interactuar, al conocer esto se pueden comprender cuantos y cuales estereotipos Frontera se tienen que colocar, por ejemplo: si el sistema es una Caja de un Banco, se debe tener clase Frontera (boundary) para que el Usuario (Cajero) pueda acceder a las opciones del sistema. Enelmismoejemplosepuedeentenderqueelcajeronecesita comunicarseconelBancomediantelaclaseFrontera,paraenviaryrecibir informacin, por tal motivo se necesita un estereotipo Control para el manejo de dichas funciones. Asmismosepuedeobservarenesteejemploqueesnecesariala informacindelUsuarioydelaCuenta(comosuID,NumeroCuenta,Monto Disponible),todosestosestnenelSistemadelBancoyporlotantocada repositorio de datos que contenga el Banco es una clase Entidad. 41 Con este ejemplo sencillo podemos observar que de un Caso de Uso se puedemapearaunaRealizacindelmismoenelAnlisisnicamente identificandolosestereotiposqueinteractanentodoelprocesodelCasode Uso.Esdesumaimportanciamencionarquepuedenexistirnestereotipos Frontera,Control(generalmenteessolouno)yEntidadenunCasodeUso particular. Al encontrar todos los estereotipos del Caso de Uso, se pueden realizar losdiagramasdeClases,SecuenciayColaboracinetc.necesariospara ejemplificar los distintos escenarios que se descubran en el Caso de Uso. Es sumamente sencillo identificar los estereotipos necesarios, para tener basesdecmohacerloverlaseccinDescripcindeEstereotiposincluidaen estetrabajo;enlacualsemencionancaractersticasatomarencuentapara poder identificar de una manera concisa estos esteriotipos. En el Captulo 4 se explica un ejemplo ms concisamente de un Caso de UsoysuRealizacin,enelcualsepodrobservarlamaneradeIdentificar estos estereotipos. 42 43 2.TECNOLOGA PARA DESARROLLO RPIDO DE APLICACIONES 2.1.Introduccin al RAD JamesMartincreeltrminoDesarrolloRpidodeAplicaciones apuntandohaciaunametodologayconjuntodeherramientasespecficos. Mientrastanto,hoydaseutilizaeltrminoRADparasealarunaseriede tecnologasqueutilizanestametodologayqueintentanreducireltiempode desarrollo.Estaesunametodologaquepermitealasorganizaciones desarrollarsistemasestratgicamenteimportantes,demaneramsrpida reduciendo a la vez los costos de desarrollo y manteniendo la calidad. Esto se hace por medio de la automatizacin de porciones grandes del ciclo de vida del desarrollodesistemas,imponiendolmitesentrelosplazosdedesarrolloy volviendo a usar los componentes existentes y se logra mediante el uso de una seriede tcnicas deutilidad comprobada de desarrollo deaplicaciones,dentro de una metodologa bien definida. Algunas de estas tecnologas son: JAD(JointApplicationDevelopment):pequeosgrupos(hasta10 personas)deusuariosyanalistashacenreuniones,paraenuncorto espaciode tiempoanalizaryespecificar entradas,procesosysalidas,a travs del desarrollo conjunto de un prototipo. GeneradoresdeAplicacin:estasherramientasposibilitangenerar cdigoejecutableapartirdedefinicionesgeneralesoprototipos.Son utilizadascomopartedeunprocesomayordeJADoprototipacin.El mayorproblemaeslacalidad(desempeo)delcdigogenerado, principalmente en un ambiente multiusuario. 44 Prototipacinrpida:elobjetivodeestatcnicaesobtenerenelmenor tiempoposibleelanlisis,diseoeimplementacindeunsistema, completooparcial,atravsdelautilizacindetcnicasytecnologas complementarias (JAD, generadores de aplicacin, etc.). Estas tcnicas incluyen el uso de: Equipos pequeos de desarrollo y bien capacitados. Prototipos evolutivos. Herramientas poderosas integradas que apoyan el modelo, el prototipo y la reutilizacin de componentes. Undepsitocentraldelainformacinparatenerlaalamanoenel momento que se le necesita. Requisitos interactivos y talleres de diseo. Lmites rgidos en los plazos de desarrollo. Lasherramientasgrficasorientadasaobjetostienen,casitodas, interiorizadaselconceptogeneraldeRAD.Adems,conlacreacinbien planificada de objetos, la programacin de nuevos mdulos se vuelve cada vez ms simplificada, reutilizando los objetos creados anteriormente. UnodelosconceptosdeRADmsinteresantes,yqueproveemejores resultadosprcticos,eseldeentregaincrementaldeproductos.Laideaes detectarduranteelanlisismdulosdelsistematributarioquepuedanser desarrollados e implantados aisladamente, y trabajar en este sentido utilizando las tcnicas descritas anteriormente. 45 Por ejemplo, en el subsistema de Registro de Contribuyentes, el mdulo decapturadedatosdelcontribuyentepuedeserrpidamentedesarrolladoe implantadoporunpequeoequipodepersonas,mientrassedesarrollanotros mdulos: actualizacin, emisin de tarjetas, estadsticas, etc. Para el xito de un desarrollo tipo RAD el personal tcnico elegido debe poseerfuerteshabilidadesderelacionesinterpersonales,aliadasaundominio excelente de las herramientas utilizadas y tambin conocer el negocio. Adems, es esencial la disponibilidadyel fcil acceso a losusuariospara larealizacin delasmuchasreunionesrequeridas.Conestosepuededecirqueunadelas limitantes de implementar el RADesel costoelevado,debidoa las exigencias que requiere para su implementacin, tanto de personal como de tecnologa. El RAD apoya el anlisis, el diseo, el desarrollo y la implementacin de lossistemasdeaplicacinindividual.Sinembargo,elRADnoapoyala planificacin o el anlisis necesario para definir las necesidades de informacin de la empresa en su totalidad o de un rea empresarial principal de la empresa. 2.1.1.Etapas de la metodologa RAD La metodologa del RAD tiene cuatro etapas principales: 1.La etapa de Definicin Conceptual que define las funciones del negocio y las reas sujeto de datos que el sistema apoyar y determina el alcance del sistema. 46 2.La etapa de Diseo Funcional que usa los talleres para modelar los datos y los procesos del sistema y para construir un prototipo de trabajo de los componentes crticos del sistema.3.La etapa de Desarrollo que completa la construccin fsica de la base de datosydelsistemadeaplicacin,construyeelsistemadeconversiny elaboraayudasdeusuariosyplanesdetrabajoadesarrollarode despliegue. 4.La etapa de Despliegue que incluye la puesta a prueba y la capacitacin del usuario final, la conversin de datos y la implementacin del sistema de aplicacin. 2.1.2.Caractersticas de la metodologa RAD ModeloCentral:Sepuedencrearmodelosoredefinirmodelos existentes,ysepuedenintegrarestosmodelosconlafuncionalidadde aplicaciones existentes (componentes, paquetes, etc.) DesarrolloVisual:Proporcionaunnivelaltodeabstraccin,yda facilidad de crear nuevas aplicaciones y mantener las existentes. CdigoConstruido:Diseadoparaaltorendimiento,escalabilidady ahorro de tiempo. FinalizacindelaIntegracindelDesarrollodelCiclodeVida: Proporcionaundesarrollodeartefactosysemnticadelnegocio capturadosyorganizadosenmodelosvisuales.Universalmente aplicados durante el desarrollo del proyecto. DaresfuerzoalaOrientacinaObjetos:Implicaqueelprocesode desarrollo esta manejado por el modelo del negocio (clases). 47 Extensible: La integracin que tiene abarca: XML, Servicios Web, Java / componentes EJB, DHTML. 2.1.3.Problemas en la metodologa RAD Los problemas que se han encontrado a esta metodologa son: 1.Se requiere que el problema sea fcilmente modularizable.2.Se requiere de recursos Humanos para cada equipo3.Cada equipo debe estar altamentecomprometido y con la capacidad de manejar las herramientas muy bien. RADnoesrecomendablecuandolosriesgostcnicosdelproyectoson altos. Por ejemplo cuando se introducen nuevas herramientas, nueva tecnologa noprobada,ocuandoserequieredecomplicadasinterfacesconsoftwareya existente. HayvocesenfavoryencontradelaefectividaddelatcnicaRAD. Algunasveces,eltiemporeducidodepuestaenmarchadeunsistemaes obtenidoalcostodebajacalidady/odifcilmantenimientoy/ounpobre desempeo. 2.2.Introduccin a J2EE J2EE,laplataformacreadaporSUNenelao1997eslaqueofrece perspectivas de desarrollo para empresas que quieran basar su arquitectura en productos basados en software libre. 48 2.2.1.JSR JSR es el acrnimo de Java Specification Request. Cuando una persona oentidadcreequeesnecesarialapresenciadeunadeterminadatecnologa dentrodelasplataformasbasadasenJava,loquehaceescrearunJSRy presentarlo para su aprobacin. Dentro de este documento se relata por que es necesariadichatecnologa,porquenosepuedenabordarlosproblemasque soluciona con las tecnologas existentes, etc. 2.2.2.JCP Java,siemprefuecriticadoporsernicayexclusivamentedeSUN.A razdetodasesascrticas,SUN,el8dediciembrede1998,decididarla posibilidad a todo el mundo de participar en la evolucin de Java y de todas las plataformas que se basan en Java. Con esa intencin se cre el JCP, que es un organismo formado por alrededor de 500 empresas, asociaciones y particulares cuyo objetivo es asegurar la evolucin de las plataformas basadas en Java. ParaentraraformarpartedelJCPlasempresaseindividualeshande pagarunacuotaanualaSUN.Cualquierapuedeparticipareneldesarrollode cualquier parte de la plataforma, previo pago de esa cuota, y por supuesto, si el comitdelaespecificacinenlaquequiereparticiparconsideraqueesa personaoentidadtienelosconocimientosnecesariosparaaportaralgn beneficio. 49 Figura 25. Esquema del JCP UnadelaslaboresdelJCPesladecontrolarlaevolucindelas diferentesespecificacionesqueformanlasplataformasbasadasenJava.Este organismoeselencargadodedecidirqueespecificacionesseapruebanyde controlar las fases por las que pasan. DespusdeverlosconceptosdeJSRyJCPestamospreparadospara definir lo quees J2EE. J2EE esunaespecificacin, un JSR (concretamente el JSR-151),quedefineunaplataformadedesarrolloempresarial,alaque llamaremoslaplataformaJ2EE.LaplataformaJ2EEestformadadevarios componentes: Un conjunto de especificaciones que relatan por que es necesaria dicha tecnologa, y que problemas va a solucionar. Una prueba de compatibilidad, el J2EE Compatibility Test Suite (CTS).La implementacin de referencia de J2EE.Unconjuntodeguasdedesarrolloydeprcticasaconsejadas denominadas J2EE BluePrints. 50 Estasespecificacionesdefinenconmuchomsdetallelosdiferentes componentesdelosservidoresdeaplicaciones(sedescribeposteriormente esteconcepto),comopuedanseruncontenedorWeb,unservidorde mensajera, el sistema de seguridad, etc. De algn modo, se podra decir que la especificacin J2EE engloba a un gran conjunto de especificaciones. Por poner unejemploenlaespecificacindeJ2EE1.4sedefinenlassiguientes especificaciones:JSR-109, (Servicios Web)JSR-101, (JAX-RPC, Java API for XML-based RPC)JSR-67, (JAXM, Java API for XML Messaging)JSR-93, (JAXR, Java API for XML Registries)JSR-77, (Configuracin y control)JSR-88, (API de despliegue)JSR-115, (Interfaz de servicios de autorizacin)JSR-56, (JNLP, Ejecucin remota de aplicaciones)JSR-112, (JCA 2.0, Arquitectura de conectores)JSR-152, (JSP 1.3, Java Server Pages)JSR-152, (Servlets 2.4)JSR-153, (EJB 2.1, Enterprise Java Beans)JSR-9XX, (JAXP 1.2, Soporte de esquemas XML)JSR-9XX, (JMS 1.1, API de mensajera)Comosepuedever,todasestasespecificacionestienenasociadoun JSR,regidoporuncomitdeempresas,asociacionesoindividuosquese asegurandecreardichasespecificacionesydequevayanevolucionando. Cualquiera puede descargar las especificaciones y a la vez puede participar en la creacin de estas. 51 La gran importancia de toda esta enorme lista de especificaciones radica enquecuandoseutilizaunservidordeaplicacionesqueimplementala plataformaJ2EE,secuentademaneraautomticacontodosestosservicios. Esdecir,seponenanuestradisposicinunagrancajadeherramientasque podemosaprovecharpararealizaraplicacionesdeunamaneramuchoms eficaz. 2.2.3.Ventajas de J2EE J2EE, nos ofrece entre otras las siguientes ventajas:Soportedemltiplessistemasoperativos:Alserunaplataformabasadaen ellenguajeJava,esposibledesarrollararquitecturasbasadasenJ2EE utilizando cualquier sistema operativo donde se pueda ejecutar una mquina virtual Java. Organismodecontrol:LaplataformaJ2EEestcontroladaporelJCP,un organismoformadopormsde500empresas.Entrelasempresasquelo formanestntodaslasmsimportantesdelmundoinformtico(SUN,IBM, Oracle, SAP, HP, AOL, etc.) lo que garantiza la evolucin de la misma. Competitividad: Muchas empresas crean soluciones basadas en J2EE y que ofrecencaractersticascomorendimiento,precio,etc.,muydiferentes.De este modo el cliente tiene una gran cantidad de opciones a elegir.Madurez:Creadaenelao1997comorespuestaalatecnologaMTSde Microsoft,J2EEtieneyacincoaosdevidayunagrancantidadde proyectos importantes a sus espaldas. 52 Solucioneslibres:EnlaplataformaJ2EEesposiblecreararquitecturas completasbasadasnicayexclusivamenteenproductosdesoftwarelibre. Nosloeso,sinoquelosarquitectosnormalmentedisponendevarias soluciones libres para cada una de las partes de su arquitectura. 2.2.4.Desventajas de J2EE Anas,laplataformadeJ2EEtambintienedesventajas,algunas importantes: Dependedeunnicolenguaje:LaplataformaJ2EEdepende exclusivamente del lenguaje Java. Slo se puede utilizar este lenguaje para desarrollaraplicacionesloquepuedesuponerungranproblemasinuestro equiponodisponedelosconocimientossuficientesotieneotras preferencias. Complejidad: Aunque no es una plataforma tan compleja como CORBA, no existe un VB .NET en Java. La creacin de aplicaciones bajo J2EE requiere normalmentedesarrolladoresmsexperimentadosquelosnecesariospara desarrollarbajo.NET.EsaqudondeherramientascomoRADpueden ayudar. Heterogeneidad:Existeunagranheterogeneidadenlassolucionesde desarrollo.NoexisteenJ2EEunsmilaVisualStudio.NET.Lagran cantidaddeherramientasdisponiblescausaconfusindentrodelos desarrolladores y puede crear dependencias dentro de las empresas. 53 Existe mucha confusin, sobre todo entre la gente alejada del mundo de Java,sobreloqueesenrealidadJ2EE.Laconfusinmshabitualespensar que J2EEesunproductoconcretoquedistribuyeSUNMicrosystemsyque sepuededescargardesdesupginaWeb.Nadamslejosdelarealidad.No existe un J2EE concreto, no se puede ir a la pgina Web de SUN Microsystems y descargar "el J2EE". 2.2.5.Integracin con otros sistemas En cuanto a la integracin con otros sistemas, gran parte del modelo de J2EE (en especial los EJB) est basado en CORBA lo que quiere decir que es posiblecomunicarsesinningntipodeproblemaconotrasaplicaciones creadas en otros lenguajes diferentes de Java y viceversa. Las posibilidades de integracin todava son mayores ya que cualquier EJB que hayamos creado se puede exponer como un servicio Web. Por ltimo otra tecnologa que merece la pena nombrar es la de los conectores, que por explicarlo de una manera clara, sonunpuenteentreJ2EEysistemaslegacy(porejemplounconjuntode ficheros de datos en COBOL), Los conectores tienen un API estndar que nos permiteaccederaestossistemaslegacydeunamaneratransparenteysin apenas esfuerzo.OtradelasgrandesventajasdeJ2EEvienedelhechodequeest basadoenJava,yaquelavariedaddeclientesquepuedenconectarseauna arquitectura J2EE es inmensa, desde aplicaciones de escritorio, hasta mviles, pasandoportelevisiones,PDAs,etc.,cualquieradeestosproductospuede conectarse ya sea a travs de cualquier protocolo de comunicacin lo que nos daunagrangamadeposibilidadesencuantoalaconectividaddenuestros sistemas. 54 2.3.Arquitectura de mltiples capas 2.3.1.El modelo de desarrollo de J2EE La plataforma de J2EE define un modelo de programacin encaminado a lacreacindeaplicacionesbasadasenn-capas.Tpicamenteunaaplicacin puede tener cinco capas diferentes:Capa de cliente: Representa el interfaz de usuario que maneja el cliente.Capadepresentacin:Representaelconjuntodecomponentesque generanellainformacinqueserepresentarenelinterfazdeusuario del cliente. Tpicamente se crear a travs de componentes basados en Servlets y JSP.Capade lgica de negocio: Contiene nuestros componentes de negocio reutilizables. Normalmente se forma a partir de componentes EJB.Capa de integracin: Aqu se encuentran componentes que nos permiten hacer ms transparente el acceso a la capa de sistemas de informacin. Porejemploesteesellugaridneoparaimplementarunalgicade objetos de acceso a datos, DAO (Data Access Objects).Capadesistemasdeinformacin:Estacapaenglobaanuestros sistemasdeinformacin:basesdedatosrelacionales,basesdedatos orientadas a objetos, sistemas legacy, etc.Las ventajas de un modelo como este son muy importantes. Al tener las capasseparadastenemosqueexistepocoacoplamientoentrelasmismas,de modo que es mucho ms fcil hacer modificaciones en ellas sin que interfieran en las dems. 55 Todoestoredundaenlaobtencindemejorasencuantoa mantenibilidad,extensibilidadyreutilizacindecomponentes.Otradelas ventajas que obtenemos es que se promueve la heterogeneidad de los clientes yaqueaadirnuevostiposdecliente(mviles,set-top-boxes,PCs,etc.)se reduceaaadirnuevascapasdeinterfazdeusuarioypresentacin,sintener que modificar todo el resto de capas. Figura 26. Esquema de un modelo mixto de tres y cuatro capas En la figura 26 se puede ver lo que sera una posible arquitectura J2EE. Elmodeloqueapareceenlafiguraestdivididoenvariascapas,conuna separacinclaraentrepresentacin,lgicadenegocioysistemasde informacinempresariales.Enestecasoadems,podemosvercomosetrata deunmodelomixto.Enlapartedearribatenemosqueserecorreuncamino porunaestructuradetrescapas(aplicacin-lgicadenegocio-sistemasde informacin), mientras que por el segundo camino recorremos una estructura de cuatro capas (aplicacin - lgica de presentacin - lgica de negocio - sistemas de informacin). 56 Como ya hemos dicho, el modelo de desarrollo con J2EE est basado en componentesreutilizables,conelobjetivodeaumentarlareusabilidaddelas aplicaciones.Estoscomponentes,adems,graciasalasespecificaciones,son intercambiablesentreservidoresdeaplicaciones,porloquelaportabilidadde nuestros desarrollos es mxima. Si hay un tipo de componentes que requieren una atencin especial estos son los Enterprise Java Beans. Se trata de objetos distribuidos, que como hemos dicho contienen la lgica de negocio de nuestras aplicacionesyquehacentransparentealprogramadoroperacionescomola persistencia, la seguridad, la gestin de transacciones, etc. 2.3.2.Servidores de aplicaciones Los servidores de aplicaciones son el corazn de la plataforma J2EE. En ellosresidirntodosloscomponentesdeunaempresa,yaseanobjetos distribuidosaccesiblesremotamente,pginasWeb,oinclusoaplicaciones completas. Un servidor de aplicaciones que implemente la plataforma J2EE nos tendr que ofrecer de manera automtica todas las especificaciones que define esteestndar.Estoesmuyimportante,yaquedeunamanerasencillael desarrolladorseencuentraconunagrancajadeherramientas.Deestemodo, en un servidor de aplicaciones normal tendremos un contenedor de servlets, un contenedordeEJBs,sistemasdemensajera,yungrannmerode herramientas que nos ayudarn a incrementar la productividad del equipo.Lapiezamsimportantedentrodeunservidordeaplicacionesesel contenedor de EJBs. Los EJBs son objetos reutilizables que contienen la lgica de negocio de nuestro sistema. Los contenedores de EJBs son servidores que se encargan de controlar todos estos componentes, esto es muy importante ya queseautomatizantareascomolagestindelciclodevida,lagestindelas transacciones, la gestin de persistencia, etc. 57 Losdesarrolladores,deestemodo,notienenquecentrarseencrear serviciosdebajo nivelypueden centrarse en la creacin de lgica denegocio empresarial.En la actualidad el mercado de los servidores de aplicaciones es uno de losmsactivosytodaslasempresasestnluchandoferozmenteporserlos lderesdelsector.Estosdosservidoressonrealmentemaravillastecnolgicas perosupreciohacequemuchasempresasnosepuedanpermitirellujode comprarsuslicencias.Porsuerteexistenunaseriedeservidoresde aplicaciones absolutamente libres que no tienen demasiado que envidiarles. 2.3.2.1.JBoss JBoss es el servidor de aplicaciones libres por excelencia (figura 27). Su licencia es LGPL y est implementado al 100% en Java. Tiene ms de 150.000 descargasmensualesloqueleconvierteenelservidordeaplicacionesms descargado del mundo. JBoss est avalado por un grupo de desarrollo formado por arquitectos con gran experiencia y repartido por todo el globo.Figura 27. JBoss es el servidor de aplicaciones que est ms de moda actualmente 58 2.3.2.2.JOnAS NotanconocidocomoJBossesteservidordeaplicaciones,porsus caractersticas, es uno de los proyectos ms ambiciosos del mundo del software libre en Java y pronto superar a JBoss en aceptacin. 2.3.2.3.OpenEJB Estrictamente, OpenEJB no es un servidor de aplicaciones. OpenEJB es uncontenedordeEJBsperolohemosincluidodentrodelapartadode servidoresdeaplicacionesyaqueescompaginadoconotrosproductosdela empresa que lo desarrolla. 2.3.2.4.Ejemplo prctico de servidor de aplicaciones Sedeseamontarunsistemacapasdeejecutarlaspeticionesdelos clientessituadosendiferentesdelegacioneslejanasaestesistema,todoesto por medio de la Web, ofreciendo las ventajas del trabajo por medio de la Web; tambinsepretendetenerunagrancantidaddeclientesutilizandoeste sistema,oseaquesoportargrancantidaddeprocesos.Tambinsedebern accederbasesdedatoslocalizadasenotroslugarespormediodelsistema, paraelprocesamientodelainformacinqueelusuarionecesite.A continuacinsepresentaunasolucinfactibleysencillautilizandolos servidores JBoss: PrimeroseinstalarunclsterdeservidoresJBoss,demodoquese puedaaprovecharlascaractersticasdebalanceodecargaqueofrecenestos sistemas.Esteselocalizarenlacentraldealgnlugarlejanoydesdeahse servirn las peticiones de los clientes situados en las diferentes delegaciones. 59 Figura 28. Ejemplo de servidor de aplicaciones Comosepuedeapreciarenlafigura28,dentrodelservidorde aplicaciones estar el contenedor de EJBs donde residirn los diferentes EJBs del sistema que contienen la lgica de negocio. Estos componentes reciben de maneraautomticaunaseriedeserviciosqueproporcionaelcontenedor: transacciones,persistencia,seguridad,etc.Adems,estoscomponentes puedenaprovecharsedelosconectoresqueproporcionaelservidorde aplicacionesparaaccederasistemaslegacy,porejemploparaaccedera ficheros COBOL, etc. 2.4. Enlace del RUP, UML, RAD y J2EE ComoyaseindicoelRUPnaceapartirdellenguajeUML,porlotanto traetodaslascaractersticasdelmismo,yconlasmejorasquefueron presentadas, incluyendo las herramientas utilizadas por el mismo. 60 2.4.1.Diseador rpido de rational (RRD) El Diseador Rpido de Rational (Rational Rapid Developer RRD) integra elmodeladovisualyautomatizalaconstruccindelsistemaquepermiteel diseo,desarrolloydesplieguerpido,enaplicacionese-business(comercio electrnico)yendtoend(extremoaextremo).ElRRDseenfoca particularmenteaencontrarlosdesafosinmediatosdeunaempresaIT (Tecnologa de Informacin), incluyendo el comercio B2B (business to business, negocioconnegocio),laintegracindeaplicacionesdeempresa,ycreando, publicando, descubriendo e integrando servicios Web. RRDtransformaeldesarrollodelaaplicacin,deunaformade programacinmetdicaaunadisciplinaarquitectnicaydiseada,yaquese desarrollan los modelos de las aplicaciones utilizando un juego de herramientas arquitectnicas visuales, esto logra un desarrollo rpido de aplicaciones con alta calidadsintenerquesaberlascomplejidadesdelaprogramacindirectade cdigoenaplicacionesdencapas,yaquelageneracindecdigopormedio delosmodelosofrececaractersticasdeseguridadyfiabilidadenla funcionalidaddelsistema.Debidoalaevolucinqueestnviviendoestas aplicaciones, cambiando los requerimientos del negocio y de tecnologa, el uso delRRDcombinalautilizacindelmodeladobasadoenelRUPparalafcil generacin y modificacin de estas aplicaciones. Enlafigura29semuestralamaneraenqueelRRDbasadoenla plataformaRAD,unecualquierproblemadelavidareal,conlosdiversos niveles,loscualesrepresentanlonecesarioparaquesepuedarealizarel sistemayquefuncionedeacordealosrequerimientosplanteadosporel problemaencuestin.Comosepuedeapreciar,encadanivelsemuestrala diversidad de opciones que se pueden tomar. 61 Figura 29. Unin de las aplicaciones con los diversos niveles mediante el RRD basado en la plataforma RAD Enlafigura29sepuedeobservarqueelRRDqueutilizalaplataforma RADnecesitadelaplataformaJ2EEcomounabaseenlageneracinde componentes mediante la generacin de cdigo creado con un desarrollo rpido o simplemente utilizar los existentes, basados en los estndares definidos en la seccindeespecificacionesdeJ2EE.UtilizandoelJ2EEsetieneuna aplicacin con todas las ventajas del cdigo Java.Utilizando estas plataformas sepuedentenerservidoresdeaplicacionesqueutilicenlosdemsniveleso capasparaentrelazarfuncionalidadesdiversassegnsealanecesidaddela aplicacin a realizar. 62 2.4.2.Modelando el sistema con RRD Eldesarrollodeunaaplicacinempiezaconlaobtencindelos requerimientos funcionales, el Modelado del Sistema en RRD se usa para crear modelosdetalladosbasadosenlosrequerimientosplanteados.Elmodelado empiezaenlafasedeincepcindelaaplicacin,almomentodelaobtencin derequerimientos,llevandoenparalelolafasedediseo,cuandoseesta creandoelnivelmasaltomostradoenlafigura29,endelaaplicacinquese desee implementar. Finalmente, durante la fase de aplicacin, se planean las partesdetalladasdelaaplicacin,queincluyenaspectoscomo:objetosdel negocio,interfacesdeusuario,mensajera,eintegracin.Elprocesode modelado, debe incluir alguna persona que codifique, pero este trabajo se limita a la creacin esencial de la lgica del negocio, necesitada para implementar las reglasdelnegocioydeprocesos,yestcomprendidaenmenosdel5%del total de cdigo en la aplicacin. RRDproveeunmodeladodetalladodeunaaplicacin,implementando estosmodelosdentrodelasfasesdelRUP,seobtienentodaslasventajas antesmencionadasdeundesarrollorpidodeaplicaciones.ElRRD conjuntamenteconelRAD,implementanlasdisciplinasdelRUP,aunque minimiza el uso de todas estas y las agrupa en 4 principales, para poder tener las ventajas de un desarrollo rpido (ver figura 30). Los diversos modelos que se pretenden realizar durante la elaboracin de una aplicacin, se muestran en lafigura30,variosdeestosmodelosfueronexplicadosenlaseccindelos modelos (ver ndice), siendo estos los que utiliza la metodologa RUP, ms sin embargo,aparecenotrosmodelosqueconjuntamenteconlosanteriores,son utilizadosenelRRD.Estasdisciplinasoflujosdetrabajoconjuntamentecon sus modelos son explicados a continuacin: 63 Requerimientos: (Modelo de Casos de Uso), cuyo objetivo fundamental eselmodeladodeloscasosdeuso,mediantelosrequerimientos planteados. ModelandoObjetivosdelNegocio:(ModelodeClases,Modelode Procesos,ModelodeBasedeDatos,ModelodeAnlisis,Modelode Seguridad,ModelodeReglasdelNegocio)esteempiezaconel modelado de las clases, con lo cual se define la estructura esttica de la aplicacin; sedefine la persistenciade clases a travs del modeladode la base dedatos. La dinmica de laaplicacines modelada utilizando ServiciosWeb,modelandocomponentesymodelandoprocesos;el modeladodelsistematambinproveeelmodeladodeseguridady modelado de reglas del negocio. ModelandoInterfasedeUsuario:(ModelosdeSitios,Modelosde Estilo,ModelosdeTema,ModelosdePgina)proveeunsistemade modeladodesitiosdenavegacinparalosusuariosypoderaslograr interfaces comprensivas y fcil de utilizar.Con el modelado de temas y estilos se pueden lograr apariencias consistentes y agradables.La parte msimportantedeestesistemademodelado,eselmodelode transaccinqueesincluidoencadapgina,queinterrelacionalos objetosdelnegocioydatos;estemodelodetransaccinpermiteala pgina proporcionar interaccin total con la aplicacin. ModelandoMensajera:(ModelodeProtocolo,ModelosdeMensajes, Modelos de Integracin) provee un sistema de modelado de mensajera, parapoderenviaryrecibirmensajesenmuchosformatos,incluyendo XML;sepuedenenviaryrecibirmensajesutilizandounavariedadde plataformasincluyendoseriesMQ,SistemadeMensajeradeJava,y otros. 64 ModelandoelDespliegue:(ModelodeTecnologa,Modelode Despliegue, Modelo de Cdigo, Modelo de la Prueba) provee un sistema de modelado de la tecnologa a utilizar, si es servidor o una computadora personal,lamarcayeltipo,conlocualsepuedemodelaresta tecnologa;tambinmodelarlaspruebasarealizar,ascomoel despliegue que tendr la aplicacin. Figura 30. Modelando en RRD basado en la plataforma RAD, y en la metodologa RUP 65 Elobjetivoesaprenderautilizarlosprincipios,actividadesyartefactos definidos por RUP para identificar requisitos, analizarlos y transformarlos en un diseo robusto en el entorno J2EE, tambin aplicar lasdiferentes fases de RUP enlaplataformaRADobteniendoelRRDsobreproyectosdedesarrollo basadosenlaplataformaJ2EE.Ellenguajeunificadodemodelado,UML,se implementadeformaintensivapararepresentaryrefinarlosdiferentes artefactosdelametodologa.Conestosenlacesseescapazdecomprender lasdiferentesperspectivasdeunaarquitecturadesoftwareyhaceruso apropiadodeellaparaladefinicinyprogramacindecomponentesdela plataforma J2EE, basados en un esquema de desarrollo rpido RRD. 66 67 3.HERRAMIENTAS A UTILIZAR PARA UN DESARROLLO RPIDO DE APLICACIONES 3.1.Herramienta XDE 3.1.1.Introduccin a XDE XDEesunaherramientadiseadaespecialmenteparadesarrolladores, comounambienteextendidodedesarrollo(eXtendedDevelopment Environment), integrando herramientasdediseoydesarrollo de cdigoen un nico ambiente de desarrollo tanto para la plataforma .NET como J2EE; permite quelosusuariostrabajenenunnicoambiente,evitandolanecesidadde cambiar entre muchos no integrados.Cuenta con un poderoso motor de soporte de patrones que hace posible su fcil adopcin y permitir acelerar los proyectos ya que no hay necesidad de comenzarconunapginaenblancoyaqueestospatronesnosproporcionan cdigo en el cual se puede empezar a especificar el propio cdigo a partir de un esqueleto. Con esta herramienta se puede realizar en menos tiempo lo deseado yaqueproveevisualizacinUML,templatesdecdigo,ysincronizacin automticaomanualdecdigoymodelos,presentadadeformatalquese puede aprender Unified Modeling Language (UML) a medida que se produce.Conestaherramientaseoptimizalaformadetrabajo,basadoenlas siguientes caractersticas: 68 Sincronizacin automtica o manual de patrones.Templates de patrones y cdigo definible por el usuario para automatizar las tareas repetitivas de codificacin.Modeladodeformatolibreparaformaspersonalizadasespecficasdel dominio.Referencias cruzadas entre modelos y versionado hasta el nivel de clase ydiagramapermitenlaestructuracinqueseajustaalcualquier proyecto.Esteentornocompletodedesarrollocombinalascaractersticasde: Modelado, Codificacin, Construccin, Compilacin, Debug. 3.1.2.Caractersticas de rational XDE Desarrollado en Java Entorno totalmente integrado de desarrollo con el modelado de diseo Sincronizacin de cdigo con modelado de diseo Ingeniera inversa Editor de cdigo Java Plantillas de cdigo que nos permiten automatizar tareas repetitivas. Personalizacin de patrones o uso de los ya incorporados de GoF. Plantillas de frameworks. Integracin con Clear Case para todo el proyecto: cdigo, documentacin y diseo. 69 MltiplesModelos.Podemostrabajarconmltiplesmodelosde abstraccin manteniendo trazabilidad. Modelado libre. Podemos trabajar en un formato libre sin las restricciones del lenguaje, para as poder reflejar nuevas ideas. 3.2.Herramienta WebSphere Estaherramientaproporcionafuncionalidade-business(negociosporla Web)bajodemanda,yoperaenmsde35sistemasoperativosdiferentes, incluyendo Linux. WebSphereesunaherramientaqueayudaaincrementarlaeficiencia operacional, aportando agilidadyescalabilidad. Los servidoresde aplicaciones paraentornosdedesarrolloyejecucinJ2EEparalaadministracinde transaccionesconunamayorseguridad,rendimiento,disponibilidady conectividad, permitiendo el equilibrio entre servicios Web y activos de software existentes.Otracaractersticaesqu