Soporte técnico para una instalación de arte interactivobibing.us.es/proyectos/abreproy/12129/fichero/PFC_Manuel_Lissen_Aguayo... · Aproximación Modelado ¿ConUMLbasta? Perhaps

Parte IV

Metodologiacutea

49

Aproximacioacuten

Modelado

iquestCon UML basta

Perhaps my experiences in the 1980s when CASE tool vendors bombardedthe IT industry with similar promises has made me a little jaded but myexpectation is that the complexity of software development and the pace oftechnological change will outstrip the ability of tool vendors to generate rea-sonably efficient source code to meet my current needs In other words I fullyexpect the cobblerrsquos children to go without shoes or in this case for developersto go without ldquoultimate toolsrdquo for quite some time

Scott AmblerAgileModelingcom9

UML es el estaacutendar de la industria software en cuanto a notacioacuten para la construc-cioacuten de aplicaciones desarrolladas bajo orientacioacuten a objetos o componentes Resultadifiacutecil encontrar literatura o herramientas sobre modelado software que no utiliceno esteacuten inspirados en UML Con los antildeos se han desarrollado complementos del es-taacutendar especiacuteficos para aplicaciones en tiempo real y sistemas embebidos ampliandoauacuten maacutes si cabe el alcance de esta herramienta Sin embargo a la vista del objetodel Soporte Teacutecnico - en el que se combinan aspectos de redes de sensores inteli-gencia ambiental y orientacioacuten a servicio - cabe preguntarse si la visioacuten de UML essuficiente o si necesitamos algo maacutes

Como primera precaucioacuten debemos advertir que UML representa a la vez unapraacutectica de modelado y una categoriacutea de software En principio el modelado UMLno necesita maacutes herramientas que laacutepiz y papel ya que basta con seguir la notacioacuteny las reglas del estaacutendar para producir esquemas que representen una aplicacioacutenen teacuterminos asimilables incluso para quienes no manejan por completo las normasUML Esta praacutectica se ha llevado hasta el extremo en algunos entornos de desarrolloen los que el propio producto de modelado se aprovecha para generar el coacutedigo delprograma Muchas herramientas UML no son estrictamente aplicaciones de modela-do sino entornos de desarrollo que incorporan prestaciones CASE10 y admiten soacuteloaquellos complementos del estaacutendar que son capaces de manejar y traducir

9httpwwwagilemodelingcomessaysrealisticUMLhtm10 Computed Aided Software Engineering

51

Capiacutetulo 4

Al tratarse de un proyecto eminentemente software el desarrollo del Soporte Teacutecniconecesita contar con herramientas de modelado para capturar el objeto y las espe-cificaciones pero por sus caracteriacutesticas resulta difiacutecil encontrar un entorno quecontenga todo el dominio de la aplicacioacuten apoyaacutendose tan soacutelo en los rudimentosUML Por otra parte la adopcioacuten de un meacutetodo de desarrollo que confiacutee en unaherramienta de ayuda a la programacioacuten UML podriacutea obligarnos a dedicar casi elmismo tiempo a preparar el entorno de trabajo que a desarrollar la aplicacioacuten en siacutelo cual seriacutea prohibitivo con los maacutergenes establecidos

Llegamos al caso de que aunque UML se disentildeoacute para prevenir que cada proyectotuviera que garantizar su propia consistencia de modelado en el contexto de la inves-tigacioacuten sobre sistemas ubiacutecuos y aplicaciones orientadas a servicio cada proyectoincorpora su propia extensioacuten al lenguaje UML ajustada a sus especificaciones eintereses11 En este contexto de indefinicioacuten el uacutenico punto de acuerdo es el intereacutespor mantener la notacioacuten original de UML aunque parece evidente que la metodo-logiacutea de disentildeo tradicionalmente asociada a UML no nos sirve para abordar en sutotalidad un sistema dinaacutemico adaptable y distribuido

Asumiendo que no vamos a desarrollar coacutedigo a partir de una herramienta CASE yque el Soporte Teacutecnico deberiacutea estar documentado esencialmente a partir de diagra-mas UML la pregunta es entonces iquestcoacutemo debemos utilizar UML en el modeladodel Soporte Teacutecnico Esto es iquestQueacute teacutecnicas son compatibles con UML y puedencomplementarlo en los aspectos en los que UML no es suficiente

Modelado de la Arquitectura de Servicio

Los servicios son unidades de funcionalidad deacutebilmente acopladas que no contienenllamadas a otras clases de servicio Cada uno implementa una accioacuten como mostrarun estracto bancario validar una reserva online o en nuestro caso reproducir unaescena de iluminacioacuten al paso de un visitante En vez de incorporar meacutetodos de in-tercambio basados en una interfaz de programacioacuten los servicios utilizan protocolospara comunicarse con sus homoacutenimos

11Ver por ejemplo

Fuentes L Gamez N Sanchez P Aspect-Oriented Executable UML Mod-els for Context-Aware Pervasive Applications Model-based Methodologies for Perva-sive and Embedded Software 2008 MOMPES 2008 5th International Workshopon vol no pp34-43 5-5 April 2008 doi 101109MOMPES200814 URLhttpieeexploreieeeorgstampstampjsptp=amparnumber=4520168ampisnumber=4520157

Howard Foster (LSS) Laacuteszloacute Goumlnczy (BUTE) Nora Koch (LMUCIR) Philip Mayer (LMU)Carlo Montangero (PISA) Daacuteniel Varroacute (BUTE) D14b UML for Service-Oriented Systems(second version) 2010 Integrated Project funded by the European Community under theldquoInformation Society Technologiesrdquo Programme (2002mdash2006)

52

El Open Group Architecture Forum (TOGAF) propone dos definiciones para elconcepto de Arquitectura de acuerdo con el contexto podriacutea tratarse de ldquouna des-cripcioacuten formal de un sistemardquo o ldquoun plan detallado para guiar su implementacioacutena nivel de componentes incluyendo la estructura de estos componentes su inter-relacioacuten y los principios y criterios que gobiernan su disentildeo y maduracioacutenrdquo Ambasdefiniciones son relevantes para comprender la ldquoArdquo de SOADesarrollando un poco maacutes la idea anterior observamos que la arquitectura es ne-cesaria para conseguir lo siguiente12

Disentildear un modelo en diferentes capas de abstraccioacuten

Separar las especificaciones de la implementacioacuten

Construir un sistema flexible

Garantizar el cumplimiento de los requisitos del proyecto

Analizar el impacto de cualquier cambio en los requisitos

Aplicar de forma efectiva los principios y la experiencia de disentildeo de los expertos enla materia

De forma general los sistemas SOA se clasifican en cuatro tipos de acuerdo con sudisentildeo estructural La utilizacioacuten de estos referentes nos ayuda a describir serviciosestandarizados y articulables Tambieacuten puede ilustrar con claridad las dependenciasentre servicios ayudando a construir un sistema limpio y coherenteLos cuatro modelos SOA sonArquitectura de Servicio Se trata del disentildeo maacutes basico que incorpora todos los

recursos necesarios para la explotacioacuten de un determinado servicio Como par-te de estos recursos podemos encontrar bases de datos componentes softwaresistemas heredados archivos de identidad esquemas XML salvaguardas o di-rectorios de intercambio entre otros La Arquitectura de Servicio tambieacuten sueleincluir todos los agentes utilizados por los servicios ya que en ellos delegantodo su procesamiento de mensajesLa arquitectura actua como punto de referencia para la maduracioacuten de losservicios calibrando el impacto de los cambios en su disentildeoImaginemos por ejemplo un sistema especializado en enviar mensajes conpromociones y publicidad a un suscriptor moacutevil en funcioacuten de su proximidada un establecimiento o una zona comercial Desde el punto de vista de suproveedor la arquitectura de este servicio incluye la informacioacuten comercial detodos sus clientes (las empresas) con su categoriacutea de suscripcioacuten los mensajesde promocioacuten y el profile de usuario al que va a dirigir sus ofertas En elextremo usuario la arquitectura incorpora todos los agentes necesarios paralocalizar e identificar al terminal en el sistema resolviendo internamente lacomunicacioacuten entre los extremos proveedor y consumidor de informacioacuten

12Extraido de httpwwwibmcomdeveloperworkslibraryws-soa-term1indexhtml

53

Capiacutetulo 4

Arquitectura de composicioacuten de Servicio Una de las principales caracteriacutesticas delos servicios desarrollados mediante el paradigma de disentildeo SOA es que sonarticulables Los servicios asiacute construidos tienen el potencial de cubrir nue-vos requisitos tan soacutelo recomponiendo su articulacioacuten con una configuracioacutendistintaUna arquitectura de composicioacuten es en siacute misma un estado de agregacioacuten delas arquitecturas separadas que participan en los servicios De acuerdo con elprincipio de abstraccioacuten de servicio este tipo de arquitectura tan soacutelo debedocumentar el ldquocontrato de serviciordquo y todos los paraacutemetros que determinanel grado de coordinacioacuten entre servicios Los detalles internos de cada serviciono son visibles para el resto del sistema El disentildeo de servicios puede incluirtambieacuten caminos alternativos como por ejemplo condiciones de error quepueden introducir nuevos servicios en la composicioacuten habilitadaLa arquitectura de composicioacuten se diferencia de la simple arquitectura en elhecho de que la configuracioacuten de cada uno de los servicios incorporados alsistema depende de condiciones globales derivadas del estado general de laaplicacioacuten y del punto de operacioacuten establecido por las especificaciones delusuario Hablamos por tanto de una aplicacioacuten orgaacutenica que se adapta a lascondiciones externas para desarrollar una prestacioacuten de forma cooperativaPara ilustrar el concepto imaginemos una aplicacioacuten con un buscador de res-taurantes un motor de reservas y un conector a una red social geolocalizadaque se quiere combinar con el sistema de enviacuteo de promociones del punto an-terior En este caso la aplicacioacuten debe mantener su estructura original (elbuscador y el motor de reservas) incorporando las partes moacuteviles y de conec-tividad social soacutelo para los usuarios que accedan al sistema por un terminalmoacutevil y un tipo de cuenta con privilegios Si vemos la aplicacioacuten como unconjunto de servicios orquestados parece evidente que la composicioacuten de es-tos servicios seraacute distinta en el caso de un usuario anoacutenimo realizando unabuacutesqueda raacutepida por una paacutegina de internet y en el caso de un usuario queutiliza la aplicacioacuten instalada en su moacutevil y estaacute interesado en recibir cuponespromocionales o conocer la valoracioacuten que han hecho otros usuarios de unestablecimiento

Arquitectura de inventario de Servicios Un inventario se compone de servicios in-dividuales que resuelven o automatizan determinadas partes de un proceso denegocio En el disentildeo del inventario lo maacutes importante es considerar la ca-pacidad combinada de procesamiento de los servicios incluidos y de formacomplementaria identificar los potenciales cuellos de botella trazando los re-querimientos de cada uno de los serviciosEste tipo de arquitectura prioriza la visioacuten global de la aplicacioacuten a la imple-mentacioacuten particular de cada uno de los servicios La arquitectura incluye ladescripcioacuten de las caracteriacutesticas de los servicios inventariados de forma queun servicio concreto puede revisarse o sustituirse sin afectar al funcionamiento

54

del conjunto de la aplicacioacutenPodemos imaginar la arquitectura de inventario como una caja de herramien-tas con sus juegos de llaves de distinto calibre si fueran componentes deservicio todas las llaves de un mismo juego responderiacutean al mismo ldquocontratode serviciordquo cada una disentildeada para unos requisitos distintos Si trasladamosesta idea a una aplicacioacuten por ejemplo el aacuterea de cliente de la paacutegina web deuna entidad bancaria que ha absorbido recientemente a otra podemos figu-rarnos que una solucioacuten basada en un inventario de servicios proveeraacute sobrela misma interfaz informacioacuten actualizada al usuario de la antigua entidadde todos los servicios que tuviera contratados recabando informacioacuten de suscuentas corrientes depoacutesitos preacutestamos avales seguros o domiciliaciones ypresentaacutendola como si fueran parte del mismo sistema con independencia delformato anterior que tuviera la base de datos

Arquitectura empresarial orientada a Servicio Se trata de la versioacuten maacutes abstrac-ta de arquitectura de servicios incorporando tanto el disentildeo de servicios comocomposiciones e inventarios asiacute como cualquier recurso tecnoloacutegico de uso em-presarial accesible para la arquitectura como por ejemplo sistemas ERP Laintegracioacuten de este tipo de arquitecturas en los sitemas empresariales puedeconllevar la necesidad de soluciones de adaptacioacuten para determinados compo-nentes heredados cobrando especial importancia el concepto de middlewarecomo capa de integracioacuten y orientacioacuten a servicio de las islas de funcionalidadincorporadas

El modelado orientado a servicio se esfuerza en crear modelos que provean una vistacomprensible del anaacutelisis disentildeo y arquitectura de todas las entidades software quecomponen un sistema Esta filosofiacutea propone una visioacuten de los componentes softwarecomo ldquoactivosrdquo que se combinan para desarrollar ldquoserviciosrdquo aunque eacutesto no es unmodelo aplicable de forma general a los cuatro tipos de SOASe han propuesto varias estrategias para el modelado de servicios Algunas de laspropuestas son en realidad adaptaciones de otras metodologiacuteas para la definicioacuten deestos nuevos artefactos software mientras que otras incluyen un desarrollo completode un lenguaje nativo de modelado Entre las existentes destacamos SOMA y SOMFpor su entidad y alcanceIBM anuncioacute en 2004 su Service-Oriented Modeling and Architecture (SOMA)como la primera metodologiacutea SOA13 SOMA se refiere al dominio maacutes general demodelado de servicios necesario para crear SOA Cubre un alcance muy amplioimplementado un proceso de anaacutelisis y disentildeo orientado a servicio a traveacutes de laidentificacioacuten especificacioacuten y realizacioacuten de servicios componentes que implemen-tan estos servicios (denominados ldquocomponentes de serviciordquo) y flujos de trabajo quepueden aplicarse en su composicioacutenPor su parte SOMF es una metodologiacutea de desarrollo del ciclo de vida con orien-13httpwwwibmcomdeveloperworkslibraryws-soa-design1

55

Chapter 4

tacioacuten a servicio especiacutefica del proceso de modelado Ofrece un grupo de praacutecticasde modelado y disciplinas que contribuyen al mejor desarrollo de un ciclo de vidaorientado a servicio a lo largo de un proyecto A grandes rasgos aclara los elementosimprescindibles en un esquema de desarrollo de serviciosLa imagen a continuacioacuten muestra las cuatro secciones de la estructura de mode-lado que identifican la direccioacuten general y las unidades de trabajo que componenla estrategia SOMF praacutecticas entornos disciplinas y artefactos Estos elementosenmarcan el contexto de una tarea de modelado pero no necesariamente describenel proceso o la secuencia de actividades necesarias para cumplir con todas las metasdel mismo Eacutestas deberaacuten marcarse durante el plan de trabajo donde generalmentequedan establecidos los liacutemites del alcance el marco de tiempo las responsabilidadesy los hitos de desarrollo del proyecto14

Figura 43 Presentacioacuten del Service Oriented Modeling Framework (SOMF)

Para el intereacutes del Soporte Teacutecnico estas metodologiacuteas quedan lejos del objeto delProyecto y plantean un reto antildeadido al tratarse de teacutecnicas hasta ahora descono-cidas Cabe preguntarse si la utilizacioacuten de estas metodologiacuteas pudiera ser contra-producente al renunciar a herramientas manejables y contrastadas pudiendo com-prometer la calidad y la audiencia potencial del trabajo Para el eacutexito del SoporteTeacutecnico resultariacutea maacutes atractivo encontrar un complemento a UML (no necesa-riamente una extensioacuten del estaacutendar) que facilite la traslacioacuten de las teacutecnicas demodelado de componentes a una instalacioacuten flexible de arte interactivo No obstan-te la Figura 43 concentra todos los elementos que una metodologiacutea de modeladode servicios debe incorporar y por tanto debemos confrontar cualquier propuestacon este esquema14httpenwikipediaorgwikiService-oriented_modeling

56

Agile Modeling

Agile Modeling es una metodologiacutea heuriacutestica para el modelado y la documenta-cioacuten de sistemas software Pretende ser una coleccioacuten de valores principios y reco-mendaciones tales que puedan aplicarse en un proyecto de desarrollo de una formamucho maacutes flexible que las metodologiacuteas tradicionalesAgile Modeling se enmarcaen el movimiento de la filosofia de desarrollo Agile de la que son exponentes entreotros muchos Extreme Programming Agile Unified Process o Scrum

Agile puede beneficiarnos en el desarrollo del Soporte Teacutecnico a varios niveles15

Desde el punto de vista del problema de disentildeo

bull La primera ventaja del modelado es que facilita un medio para pensaren todo el sistema antes de proceder a construirlo Agile prioriza en esteobjetivo de visualizacioacuten global del problema y deja viacuteas abiertas para suposterior traslacioacuten al entorno de desarrollo que mejor se acomode a lascostumbres del programador

bull Agile facilita los medios para aclarar aquellos requisitos que no estaacutenadecuadamente descritos o son difiacuteciles de implementar ajustando el nivelde detalle a las necesidades de cada momento de desarrollo

bull En el aacutembito interno de desarrollo obliga a una adecuada evaluacioacuten delas cuestiones teacutecnicas y las estrategias de implementacioacuten a traveacutes de larevisioacuten de modelos antes de proceder a la programacioacuten

bull En resumen Agile no obliga a documentar ni preparar un gran disentildeoantes de escribir el coacutedigo valorando el detalle de los modelos seguacuten lasituacioacuten y la madurez del proyecto

Desde el punto de vista de la gestioacuten del proyecto

bull Facilita la organizacioacuten del trabajo en iteraciones cortas Cada iteracioacutendebe estar centrada en alcanzar una funcionalidad concreta como maacuteximaprioridad La ldquopila de requisitosrdquo del proyecto iraacute cambiando durantesu desarrollo por lo que Agile Modeling prioriza la actualizacioacuten yreevaluacioacuten antes que la planificacioacuten a largo plazo

bull El modelado sirve como mecanismo de intercambio y compromiso entrelos objetivos del proyecto y los plazos de desarrollo ya que el modelosirve para concretar las actividades a acometer y a traveacutes de ellas quedanfijados los tiempos necesarios

bull Agile Modeling cambia la filosofiacutea de modelado pasando de ser unatarea programable a una actividad a realizar just-in-time (JIT) repetidasveces a lo largo del proyecto

15Extraido de httpwwwagilemodelingcomessaysmodelingTechniqueshtm

57

Capiacutetulo 4

La metodologiacuteaAgile nos permite relajar la exigencia teoacuterica de un modelo completoy riguroso antes de abordar el desarrollo del proyecto pudiendo ademaacutes estructurarel trabajo de la forma que maacutes convenga a las condiciones de dificultad e integracioacutende cada una de las partes del sistema Esto no supone en ninguacuten caso un compromisopara la calidad del proyecto sino que permite avanzar de una forma maacutes aacutegil yaprovechar los productos intermedios como impulsos para realimentar el nivel deexigencia durante el desarrollo

Figura 44 Praacutecticas recomendadas en Agile

Ontologiacuteas

Como uacuteltima gran disciplina de modelado presentamos una teacutecnica empleada en eldisentildeo de sistemas expertos y aplicaciones de inteligencia ambiental las ontologiacuteas

Las ontologiacuteas se desarrollan para facilitar una semaacutentica aplicable en maacutequinas queoperen sobre fuentes de informacioacuten y deban comunicarse con agentes software ohumanos A lo largo de la uacuteltima deacutecada se han presentado varias definiciones peroquizaacutes la que mejor captura la escencia del concepto es la siguiente una ontologiacuteaes una especificacioacuten formal y expliacutecita de una conceptualizacioacuten compartida Unaldquoconceptualizacioacutenrdquo se refiere a un modelo abstracto de alguacuten sistema en el quequedan identificados los conceptos maacutes relevantes que lo caracterizan ldquoExpliacutecitordquosignifica que los conceptos manejados asiacute como sus limitaciones de uso se definen demanera evidente en teacuterminos objetivos Por ldquoformalrdquo nos referimos al hecho de quela ontologiacutea deberiacutea ser procesable para una maacutequina en este sentido no obstanteson posibles varios grados de formalismo

Fundamentalmente el papel de las ontologiacuteas es facilitar la construccioacuten de unesquema maestro que sea uacutetil en la conceptualizacioacuten de una aplicacioacuten de ingenieriacuteaconcentrando los teacuterminos y las relaciones que modelan su dominio de trabajo1616Extracto del libro Ontologies Silver Bullet for Knowledge Management and Electronic

Commerce de Dieter Fensel Referencia en Google Books

58

En teacuterminos de modelado los principales elementos de una ontologiacutea son Clasesque representan a las entidades del dominio bajo estudio El segundo elemento cons-tructivo son las Relaciones que se establecen entre las clases del dominio Cada clasepuede contener subclases que representan conceptos maacutes especiacuteficos asiacute como ins-tancias que seriacutean elementos del mundo real etiquetados como miembros de la clase

El uso de las ontologiacuteas estaacute prescrito en la etapa maacutes temprana de disentildeo defi-niendo las entidades implicadas en el dominio de una aplicacioacuten y estableciendo lasrelaciones entre ellas En todo caso la ontologiacutea representa el nivel maacutes elaborado dedescripcioacuten de un sistema complejo y su aplicacioacuten soacutelo se considera imprescindibleen la introduccioacuten de nuevos dominios en los que todaviacutea no se ha establecido niformalizado el significado ni el rol de las distintas entidades ([8])

Figura 45 Metamodel of an ambient intelligence application

El modelado por medio de ontologiacuteas es interesante para su aplicacioacuten en el SoporteTeacutecnico porque es una herramienta propia de aplicaciones semaacutenticas que ha sidotrasladado y utilizado con eacutexito en otros sistemas como es el caso del sistema deintegracioacuten domoacutetico DOG del que ya hemos hablado en anteriores capiacutetulos Elnuacutecleo de este sistema es una ontologiacutea - DogOnt ([4]) - que se ha disentildeado prestandoespecial atencioacuten a la interoperabilidad entre sistemas domoacuteticos Las bases de estemodelo se desprenden del estudio de casos reales centraacutendose en el modelado dedispositivos estados y funcionalidades La ontologiacutea DogOnt se desarrolla en cincocategoriacuteas generales que son ndash Elemento Constructivo objetos disponibles para elmodelado (controlables o no) ndash Entorno Constructivo describen localizaciones pa-ra los elementos constructivos ndash Estados capturan las configuraciones estables quepueden asumir los elementos controlables ndash Funcionalidades modelan las capacida-des de los controlables - Componente de Red Domoacutetica capturan las caracteriacutesticasde una determinada planta domoacutetica

59

Capiacutetulo 4

Figura 46 Parte de una ontologiacutea donde se definen las entidades y relacionesinvolucradas en un sistema de monitorizacioacuten de pacientes para un servicio demedicina nuclear

El referente de DogOnt marca el punto de desarrollo maacutes complejo que podemos al-canzar aplicando una teacutecnica de modelado propia del campo de la teoriacutea de sistemasEsta teacutecnica como hemos planteado a lo largo del capiacutetulo pertenece a la etapa dedisentildeo y por tanto es sucedida por otras teacutecnicas en la etapa de implementacioacutenque deben transformar la ontologiacutea en una aplicacioacuten No se ha encontrado informa-cioacuten sobre una metodologiacutea de desarrollo apoyada sobre las ontologiacuteas por lo quesuponemos como en el caso de SOMF que los autores utilizan herramientas CASEpara crear prototipos de aplicacioacuten a partir de la representacioacuten formal del modeloNo obstante una ontologiacutea es completamente transparente a la arquitectura que lasoporta y por consiguiente participa tan soacutelo en la capa de traduccioacuten de datos quemedia entre la aplicacioacuten de usuario y la infraestructura que garantiza la cohesioacutendel sistema Esto tiene dos consecuencias inmediatas por un lado la ontologiacutea nocubre todo el alcance del desarrollo del Soporte Teacutecnico ya que hay ciertos aspectosque no son visibles para este modelo de datos por otra parte una ontologiacutea puedeser el modelo en el que se apoye la definicioacuten de los contratos de servicio desplegadospor una aplicacioacuten permitiendo asiacute una combinacioacuten de las mejores prestaciones deambas herramientas para construir una capa de negociacioacuten que aune las virtudesde una buena arquitectura de servicios y una buena API de desarrollo y documen-tacioacuten basada en un modelo de entidad - relacioacuten derivado de la Ontologiacutea delSoporte Teacutecnico

Organizacioacuten del trabajoTodos hemos visto muchos libros y artiacuteculos donde se intenta capturar to-

dos los detalles de la arquitectura de un sistema usando un uacutenico diagramaPero si miramos cuidadosamente el conjunto de cajas y flechas que muestranestos diagramas resulta evidente que sus autores han trabajado duramentepara intentar representar maacutes de un plano que lo que realmente podriacutea ex-presar la notacioacuten iquestAcaso las cajas representan programas en ejecucioacuten iquestO

60

representan partes del coacutedigo fuente iquestO computadores fiacutesicos iquestO acaso me-ras agrupaciones de funcionalidad iquestLas flechas representan dependencias decompilacioacuten iquestO flujo de control Generalmente es un poco de todo

Planos Arquitectoacutenicos El Modelo de ldquo4+1rdquo Vistas de la Arquitectura del Software17

Philippe Krutchen

RUP (Rational Unified Process)

El Proceso Unificado de Rational es un producto desarrollado por IBM RationalSe trata de un procedimiento de desarrollo de sistemas que se despliega en cascadaen pequentildeas iteraciones y entregas incrementales al mismo tiempo que garantiza elseguimiento de las praacutecticas de maacutexima calidad en el desarrollo El RUP consta decuatro fases Concepcioacuten Elaboracioacuten Construccioacuten y Transicioacuten que se ejecutan deforma secuencial El trabajo se agrupa en actividades loacutegicas llamadas disciplinasque se realizan de forma iterativa a lo largo de las cuatro fases El Proceso Unificadono es soacutelo un proceso de desarrollo sino tambieacuten una plataforma que puede adaptarsea las necesidades particulares de cada proyecto18

Figura 47 Distribucioacuten tiacutepica de un proyecto mostrando la relaciones entre lascuatro fases del Proceso Unificado

En conjuncioacuten con la experiencia de desarrollo RUP facilita la articulacioacuten delos meacutetodos de excelencia de la ingenieriacutea de software contemporaacutenea que puedenresumirse en

1 Desarrollar iterativamente tomando el riesgo como el conductor primario de laiteracioacuten

2 Gestionar los requisitos

3 Utilizar una arquitectura basada en componentes

4 Modelar visualmente el software

5 Contrastar permanentemente la calidad17Artiacuteculo publicado en IEEE Software 12(6) Noviembre 1995 Traducido por Mariacutea Cecilia Bas-

tarrica en Marzo 200618 A Managerrsquos Introduction to The Rational Unified Process (RUP) Scott W Ambler 2005

61

Capiacutetulo 4

6 Controlar los cambios

RUP fue creado en 1996 cuando la empresa Rational adquirioacute los derechos delObjectory Process que habiacutea desarrollado Ivar Jacobson La versioacuten original incorpo-raba fundamentalmente la aproximacioacuten al modelado propuesta por Jim Rumbaughen su Metodologiacutea de Modelado de Objetos (OMT) la metodologiacutea Booch de GradyBooch y por supuestoUML 10 En 1997 se incluyeron las disciplinas Requisitos yTest En 1998 dos nuevas disciplinas fueron introducidas en el meacutetodo Modeladodel caso19 - que habiacutea sido praacutecticamente cubierto por el Objectory Process- y Configuracioacuten y Gestioacuten de cambios En la versioacuten 11 de UML se integraronotras teacutecnicas incluyendo aacutereas como pruebas de rendimiento disentildeo de interfacesde usuario ingenieriacutea de datos y una versioacuten actualizada de RUP En 1999 se incor-poroacute una disciplina de gestioacuten de proyectos para el desarrollo de software en tiemporeal A partir del antildeo 2000 la mayoriacutea de las actualizaciones se han centrado ennuevas teacutecnicas incorporar plantillas y guiacuteas paso a paso automatizando la posibi-lidades de personalizacioacuten de RUP de forma que cada cliente pueda crear su propiaversioacuten manteniendo la compatibilidad con las siguientes mejoras de Rational

RUP y PMBOK

Una metodologiacutea de desarrollo de aplicaciones consiste en una serie de fases y pro-cesos que intervienen en aspectos administrativos y teacutecnicos de forma superpuesta eiterativa buscando generar un producto o una mejora del mismo para el caso unaaplicacioacuten En su parte administrativa estas metodologiacuteas responden al plantea-miento de la Guiacutea PMBOK ofreciendo una serie de praacutecticas y procesos organiza-dos de forma que nos permitan administrar todos los aspectos del ciclo de desarrollosoftware La combinacioacuten de los conocimientos del PMBOK y de una metodolo-giacutea especiacutefica de desarrollo es posible antildeadiendo la solidez teoacuterica y la experienciade gestioacuten de un estaacutendar reconocido con el conocimiento y las herramientas deprogramacioacuten maacutes adecuadas al caso de trabajo que aborda nuestro proyectoEl Proceso Unificado proporciona un enfoque disciplinado para asignar tareas y res-ponsabilidades dentro de una organizacioacuten de desarrollo de software Su objetivo esgarantizar la produccioacuten de software de alta calidad que satisfaga las necesidadesde sus usuarios finales dentro de un cronograma y un presupuesto previsibles Co-mo hemos dicho las mejores praacutecticas modernas de la industria de desarrollo sonaplicadas como parte de RUP encajando en una amplia variedad de proyectos Laimplementacioacuten de estas buenas praacutecticas ofrece a los equipos de programadores unaserie de ventajas clave aportando directrices modelos y herramientas para sacar elmaacuteximo rendimiento al desarrollo software20Los elementos clave de RUP son tres el Rol la Actividad y los Artefactos Un roldesarrolla una actividad para producir un artefacto Cada rol se encarga fundamen-19Traduccioacuten libre de la expresioacuten Business Model20Extraiacutedo de httpwwwiiisorgCDs2008CD2009CSCCISCI2009PapersPdfC690MIpdf

62

talmente de un grupo de actividades y artefactos pero todos los roles contribuyenal desarrollo de las demaacutes actividades dentro del proceso La combinacioacuten de rolesactividades y artefactos se utiliza repetidamente en la ejecucioacuten del ciclo de tra-bajo Este ciclo (workflow) estaacute compuesto por una secuencia de tareas especiacuteficapara cada una de las nueve disciplinas software recogidas por el RUP El marco detrabajo de RUP por tanto es bidimensional con un eje dependiente del tiempo yotro dependiente del contenido La dimensioacuten temporal se organiza en fases itera-ciones e hitos mientras que el plano de contenidos se desarrolla en las mencionadasdisciplinas conteniendo sus flujos de trabajo con los roles actividades y artefactospropios

Figura 48 Organizacioacuten en tiempo (Fases) y contenido (Disciplinas) de RUP

Mientras que el PMBOK se describe un ciclo de proyecto general en RUP se pres-cribe uno geneacuterico para el desarrollo de software dentro de un ciclo de proyectomaacutes grande En PMBOK encontramos una guiacutea aplicable a proyectos de cualquierdimensioacuten y por su parte los meacutetodos de RUP pueden adaptarse al desarrollo deun proyecto software de cualquier tamantildeo21 En base a la comparacioacuten entre loselementos de RUP y PMBOK se concluye que no existen incompatibilidades entreambos estaacutendares por el contrario encontramos teacuterminos distintos para describirconceptos cercanos o incluso similares pero nada dentro de RUP que contradiga laspraacutecticas PMBOK ni viceversa22

Es posible aplicar las herramientas de RUP en un proyecto de ingenieriacutea gobernadocon PMBOK al tratarse de metodologiacuteas 100 compatibles La disponibilidad dela Guiacutea PMBOK garantiza que podamos descomponer el proyecto mediante unaWBS que todos los productos de trabajo desarrollados mediante RUP o mediante21httpwwwibmcomdeveloperworksrationallibrary4763html22httpwwwibmcomdeveloperworksrationallibrary4721html

63

Capiacutetulo 4

Figura 49 Equivalencias entre RUP y PMBOK

herramientas RUP (como UML) se van a integrar en el alcance del proyecto y portanto agregan valor al desarrollo Implica tambieacuten que podemos trazar el cumpli-miento de los requisitos a traveacutes de los entregables lo que brinda la posibilidadde cuantificar el grado de avance del trabajo y tambieacuten de cualificar el productodesarrollado en base a las expectativas y las limitaciones reales del proyecto Por suparte la incorporacioacuten de RUP aporta un lenguaje y una organizacioacuten al procesode desarrollo da contenido especiacutefico a la gestioacuten de calidad y de riesgos y establecelos criterios para controlar la apertura y el cierre de las fases de trabajo

Podemos decir en definitiva que el PMBOK aporta el modelo de gestioacuten en elque encajan los meacutetodos de trabajo RUP No obstante RUP es una metodologiacuteabasada en la programacioacuten orientada a objetos que nosotros queremos superar aquiacuteal apostar por la orientacioacuten a servicio Hasta donde sabemos RUP es incompatiblecon SOA porque se apoyan en paradigmas distintos Tanto la programacioacuten SOAcomo RUP parten de la definicioacuten de unos requisitos muy claros necesarios para lapresentacioacuten de un modelo completo del sistema lo que no significa que no puedanconvivir y hasta cierto punto colaborar en el desarrollo del Soporte Teacutecnico Desde elprincipio hemos establecido un dominio del Soporte en el que procede la aplicacioacuten

64

de SOA y un dominio separado que responde a una solucioacuten de integracioacuten demedios Desde el punto de vista SOA el uacutenico requisito de la solucioacuten de integracioacutenes que debe permitir el despliegue de una capa de componentes de servicio lo queimplica de forma complementaria que el modelo de arquitectura de servicios debeser compatible con la infraestructura de la solucioacuten de integracioacutenLa organizacioacuten modular del Soporte nos permite desacoplar las teacutecnicas de disentildeode cada parte pero como vemos cada dominio debe desarrollarse sin perder laperspectiva de su composicioacuten en el sistema En el centro de esta composicioacuten estaacuteAgile en las costuras mismas del Proyecto seraacute Agile con su filosofiacutea relajada encuanto a la precisioacuten de los requisitos y su apuesta por el avance raacutepido del trabajola que contenga y haga viable el desarrollo del Soporte Teacutecnico Veamos coacutemo

Agile sobre RUP

Como se indica en Figura 410 Agile Modeling estaacute pensado para apoyarseen metodologiacuteas maacutes complejas y consistentes como XP o RUP facilitando unametodologiacutea de desarrollo ajustada a las necesidades reales del trabajo

Figura 410 Agile potencia otras metodologiacuteas de desarrollo

Las teacutecnicas de AM pueden ser usadas para potenciar otra metodologiacutea software maacutescompleta como eXtreme Programming (XP) RUP OpenUp o Agile Unified Process(AUP) por nombrar algunos Estos meacutetodos cubren un alcance maacutes amplio que elde AM contemplando en algunos casos todo el proceso de desarrollo y produccioacutenAunque todas estas metodologiacuteas incluyen actividades de modelado y documenta-cioacuten en una u otra forma ciertamente dejan espacio para la mejora y la innovacioacutenEn el caso de XP es posible mejorar la definicioacuten del proceso de modelado en elcaso de RUP el modelado podriacutea hacerse mucho maacutes aacutegil etc23La filosofiacutea Agile actuacutea como catalizador sobre la metodologiacutea RUP aportando uncriterio de organizacioacuten eficaz del trabajo y estableciendo los indicadores para ircerrando etapas de desarrollo garantizando gracias al rigor de RUP la coherenciadel disentildeo y la precisioacuten y claridad de las especificaciones La gran ventaja de aplicarAgile sobre RUP es que podemos conservar lo mejor del modelado UML y lo mejordel modelo 4+1 y aplicarlo en un entorno de desarrollo capaz de producir resultados23Fuente httpwwwagilemodelingcomessaysagileModelingRUPhtmFit

65

Capiacutetulo 4

raacutepidamente y adaptarse con comodidad a los cambios Ambos meacutetodos son uacutetilespara el proyecto ya que necesitamos UML para capturar los componentes de servicioy la infraestructura de integracioacuten y necesitamos un meacutetodo ligero de desarrollo paradar cabida a la posibilidad de reconfigurar los efectos de la instalacioacuten interactiva ydesarrollar las partes maacutes valiosas del Soporte en los plazos de ejecucioacuten del proyectofin de carrera Para cerrar este ciacuterculo soacutelo necesitamos descubrir los puntos de unioacutenentre Agile SOA y la metodologiacutea de gestioacuten que vamos a seguir

Agile y PMBOK

El Agile Manifesto24 fue publicado por primera vez en febrero de 2001Despueacutes de 11 antildeos el nivel de intereacutes en APM (Agile Project Management) ylas metodologiacuteas recogidas bajo el paraguas de la filosofiacutea ldquoAgilerdquo ndash tales comoScrum Extreme Programming Lean Crystal DSDM o el Desarrollo Guiado porCaracteriacutesticas 25 - ha ido creciendo de forma constante En este momentoparece claro que hay dos escuelas de pensamiento en la gestioacuten de proyectos que apriori parecen antagonistas por un lado la aproximacioacuten tradicional - cuyo maacuteximoexponente es la Guiacutea PMBOK - y por otro los meacutetodos Agile

Para los partidarios de Agile la aproximacioacuten APM supone una revolucioacuten en lacultura de proyectos que para ellos implica una ruptura con los aspectos conven-cionales de la cultura anterior Se suele asociar la gestioacuten de proyectos tradicional conla organizacioacuten en cascada y el ciclo de vida secuencial Frente a estas caracteriacutesticasse objeta principalmente la exigencia burocraacutetica y formal en la planificacioacuten inicialy la oposicioacuten a los cambios lo que se asocia a una idiosincrasia y una organizacioacutenriacutegida y autaacuterquica en la que difiacutecilmente puede acomodarse la innovacioacuten

Desde el punto de vista del PMI la situacioacuten se ve de un modo diferente En pri-mer lugar las metodologiacuteas aacutegiles son una aproximacioacuten evolutiva a la gestioacuten deproyectos La Guiacutea PMBOK no fue concebida como un paso a paso para elaborarun proyecto sino como un marco muy general para controlar proyectos en todoslos sectores sin importar su complejidad o dificultad Por tanto desde su puntode vista estas nuevas metodologiacuteas responden a un conjunto de teacutecnicas que enca-jan en el marco general de PMBOK De hecho la Guiacutea no se postula a favor deuna metodologiacutea sobre las demaacutes y propone tres modelos para el ciclo de vida deun proyecto secuencial (cascada) superpuesto e iterativo (en la quinta versioacuten seintroduce tambieacuten el ldquociclo de vida adaptativordquo)

Efectivamente la Guiacutea PMBOK permite la ldquoelaboracioacuten progresivardquo y en generales necesario realizar actualizaciones de todos los elementos de un plan de gestioacuteny de las liacuteneas maestras de un proyecto durante su ciclo de vida De hecho Agilepodriacutea interpretarse como un tipo novedoso de planificacioacuten en oleadas donde las24httpwwwagilemanifestoorg25 Feature Driven Development

66

fases tradicionales de proyeccioacuten software (disentildeo conceptual disentildeo detallado codi-ficacioacuten desarrollo evaluacioacuten de unidad prueba integrada liberacioacuten) se repitenen cada iteracioacuten o sprintAdemaacutes el PMI no dogmatiza sobre la renuencia a los cambios ni sobre la plani-ficacioacuten exhaustiva para alcanzar el Plan de Proyecto tan perfecto que no necesiteconsiderar los cambios Tampoco obliga a la adopcioacuten de roles directivos que dis-pensen sus instrucciones a los miembros del grupo de trabajo para llevar a cabo elPlan Muy al contrario se reconoce la necesidad de que los jefes de proyecto adoptendiferentes estiles de gestioacuten en los diferentes momentos de avance y para diferentesniveles de madurez de los miembros del equipo y se acepta que la adopcioacuten de laldquogestioacuten por objetivosrdquo o la ldquoteoriacutea Yrdquo puede ser perfectamente apropiada en ciertassituaciones26Sin embargo a pesar de estos puntos de encuentro entre ambas filosofiacuteas hay algunoselementos clave en los que las metodologiacuteasAgile y la Guiacutea PMBOK son claramenteirreconciliables

Un Plan de Proyecto tiene que ser muy detallado incluyendo un nuacutemero miacute-nimo de componentes o piezas Para el desarrollo Agile no es necesario incluirun plan ni una guiacutea subsidiaria para cada componente En su lugar el equipodeberiacutea contar con la libertad de escoger los elementos que necesitan y la con-fianza para escoger el nivel de documentacioacuten adecuado para el proyecto Estaaproximacioacuten cambia la dinaacutemica prescriptiva o de ldquopresioacutenrdquo de PMBOK porun proceso Just in time o de ldquoatraccioacutenrdquo en Agile27PMI recomienda insistentemente utilizar su Meacutetodo del Valor Antildeadido (EVM28)en todos los proyectos Para que eacuteste funcione es necesario disponer de unas liacute-neas maestras muy precisas desde etapas tempranas del proyecto No obstanteen Agile no existen tales referencias La razoacuten es que en Agile no se traducen losrequisitos del cliente en especificaciones teacutecnicas ni elementos de anaacutelisis auacutenmaacutes no se de-construyen los requerimientos teacutecnicos en una WBS En Agileno se utiliza WBS en su lugar los requisitos se definen desde el punto de vistadel cliente como ldquocaracteriacutesticasrdquo o ldquohistoriasrdquo Sin una WBS el trabajo nopuede ldquopaquetizarserdquo ni dividirse en actividades por lo que es imposible crearuna Planificacioacuten ni establecer un Plan de referencia Sin estos medios no sepuede estimar el coste ni el presupuesto por lo que no puede establecerse unaliacutenea de costes No podemos estimar la desviacioacuten en tiempo costes o valorni realizar previsiones Por el contrario en Agile el progreso se mide en cadasprint por medio de las historias y los llamados ldquoBurndown chartsrdquo yldquoBurn-up chartsrdquo

Es quizaacutes esta diferencia la que marca un punto de discordia perentorio entre ambas26Para maacutes informacioacuten ver Harold Kerzner Project Management a Systems Approach to Plan-

ning Scheduling and Controlling (New York Wiley 2009) pp 194-19527En el original ingleacutes se contraponen los verbos ldquopushrdquo y ldquopullrdquo28httpenwikipediaorgwikiEarned_value_management

67

Capiacutetulo 4

filosofiacuteas de gestioacuten Sin embargo puede que encontremos un punto de encuentro enla nocioacuten de los ldquoproyectos hiacutebridosrdquo Es evidente que tanto para entusiastas de Agilecomo de PMI hay muchos proyectos para los que resulta maacutes efectiva la aproximacioacuteniterativa a la hora de desarrollar un prototipo En favor de la velocidad se podriacuteanrelajar las condiciones del PMBOK y posponer una WBS detallada limitaacutendonos auna Estructura de Caracteriacutesticas Esto podriacutea ser interesante para desarrollar en uncorto plazo una ldquoPrueba de Conceptordquo En compensacioacuten los meacutetodos Agile podriacuteanadquirir maacutes densidad en las siguientes iteraciones incluyendo una estructuracioacuten yuna planificacioacuten a traveacutes de las que pudieran trazarse los requisitos del proyecto ycontrolar el valor antildeadido del producto29

Construyendo un meacutetodo de proyeccioacuten sobre Agile y SOA

iquestMeacutetodo y arquitectura son excluyentes Podriacuteamos argumentar que las praacutecti-cas de desarrollo son en general independientes del modelo de arquitectura softwarepero esto no es cierto en el caso de SOA y Agile Los meacutetodos Agile estaacuten muy enfo-cados al disentildeo y promueven principios como el Big Design Up Front (BDUF)para disuadir de otras estrategias Por su parte los desarrollos en SOA se centranen el conjunto de servicios y por propia naturaleza priman los aspectos de comuni-cacioacuten y composicioacuten que entran dentro del terreno de las metodologiacuteas Por tantoambos dominios se solapan iquestQuiere esto decir que SOA y Agile son incompatibleso pueden conjugarse

SOA y Agile son ldquoenemigosrdquo Como hemos encontrado un punto de unioacuten entremetodologiacutea y arquitectura podriacuteamos pensar que al compartir metas ambas teacutec-nicas deberiacutean ser compatibles Sin embargo encontramos diferencias sustancialesentre la personalidad y la filosofiacutea de trabajo de SOA y Agile debidas a sus oriacutegenesdisparesEspeciacuteficamente hay tres puntos en los que SOA y Agile chocan

SOA prima la arquitectura como esquema principal del proyecto mientras queAgile apuesta por el disentildeo30SOA potencia la organizacioacuten funcional del trabajo mientras que Agile favo-rece la organizacioacuten transversalSOA no tiene una posicioacuten fija sobre la realimentacioacuten del cliente o la gestioacuten decambios mientras que Agile estaacute completamente centrado en la comunicacioacutentanto a nivel teacutecnico como personal

29httpwwwbestpractices-pmptrainingcomabstract-agile-vs-the-pmbok-guide-updated-june-2012-230En cierto modo disentildeo y arquitectura pueden interpretarse como un dualismo en la resolucioacuten

del problema ya que la arquitectura es el ldquoesqueletordquo de la solucioacuten mientras que el disentildeoes la ldquoideardquo En el contexto de este Proyecto no obstante la primaciacutea de los principios Agileimpone la idea de un Disentildeo del que va a derivarse la Arquitectura de forma iterativa hasta suestado de documentacioacuten final

68

Agile y SOA son ldquoamigosrdquo Ninguna de las razones apuntadas es suficientementefuerte como para romper los lazos entre ambas filosofiacuteas Una arquitectura y unametodologiacutea de trabajo son complementarias por naturaleza y ademaacutes SOA y Agilecomparten sus metas generales Ambas reconocen la necesidad de hacer frente alos cambios y la importancia de gestionarlos eficazmente31 El encaje entre Agiley la Arquitectura Orientada a Servicio es casi perfecto sobre todo porque ambasbuscan hacer la tecnologiacutea maacutes flexible y adaptable a los cambios en los requisitosde negocioAntonio Bruno project manager analista software y promotor Scrum explicacoacutemo se enriquecen mutuamente la metodologiacutea Agile y la Tecnologiacutea de Servicios

SOA introduces a controlled environment in which changes are ac-commodated in support of Agile processes where quality efficiency andproductivity are increased through the appliance of design patterns stan-dards and governance procedures Design patterns like service reusabilitycomposability and abstraction to cite a few are leveraged to provide flex-ible and adaptable ecosystems Agile methods also enable the lifecycle tobe more incremental and interactive allowing the business to getgivefaster feedback fromto IT They both support the continuous business-IT cycle that is needed to allow businesses to set up strategies alignedwith IT

En conclusioacuten SOA no aportaraacute todo su valor a un proyecto si no se aplica unaaproximacioacuten Agile en su desarrollo software32

31Extraiacutedo de httpwwwinfoqcomarticlesSOA-Agile-Friends-Or-Foes32Fuente httpwwwzdnetcomblogservice-orientedwhat-does-soa-bring-to-agile-or-agile-to-soa

8041

69

Plan de desarrollo del SoporteTeacutecnico

Figura 411 Marco conceptual del plan de desarrollo del Soporte Teacutecnico

En el capiacutetulo anterior hemos tratado de exponer los motivos por los que el desa-rrollo del Soporte Teacutecnico debe ser tratado como un proyecto de investigacioacuten auacutentrataacutendose de un proyecto claacutesico de desarrollo La nocioacuten de cambio en los requisi-tos estaacute en la raiacutez de la aplicacioacuten ya que el Soporte Teacutecnico no es una aplicacioacutencerrada a un uso especiacutefico sino una plataforma aplicable a multitud de escenariosEstas condiciones unidas a la arquitectura modular e integrada eliminan la posibi-lidad de recurrir a una metodologiacutea formal de modelado y desarrollo y nos obliga aadoptar una solucioacuten hiacutebrida inspirada en las normas de referencia del sector soft-ware pero guiadas por la filosofiacutea Agile El objetivo final del trabajo es desarrollaruna ldquoprueba de valorrdquo - si no fuera posible un prototipo completo- lo que justificaeste compromiso entre rigor teacutecnico y de gestioacuten necesario para abordar todos losdetalles del problema en el tiempo y las condiciones del proyecto acadeacutemico

71

Capiacutetulo 4

En la Figura 411 quedan reunidos todos los referentes combinados en la metodolo-giacutea que vamos a seguir En el plano de gestioacuten nos apoyaremos en la Guiacutea PMBOK- contextualizada en los aspectos software por RUP - para controlar el avance delproyecto y muy especialmente para generar los documentos de control que cuan-tifican el trabajo de desarrollo e integracioacuten en su dimensioacuten material (a traveacutes deuna Estructura de Trabajo) y temporal (a traveacutes de una Planificacioacuten) En el planode desarrollo el Desarrollo Aacutegil Guiado por Modelos va a permitirnos desacoplarlas caracteriacutesticas de los distintos bloques del sistema para abordarlos con las he-rramientas maacutes adecuadas al plano de abstraccioacuten y los requisitos de integracioacuten decada uno haciendo posible que convivan en la misma solucioacuten aspectos de orienta-cioacuten a componentes - necesarios para un desarrollo de calidad de la infraestructurade integracioacuten - con aspectos de orientacioacuten a servicios - muy uacutetiles para canalizarlos cambios en las especificaciones de cada posible aplicacioacuten del Soporte Teacutecnico

Para dar contenido a esta propuesta vamos a seguir la metodologiacutea de modeladopresentada en la Figura 412 en la que se han sustituido los elementos geneacutericos deSOMF de la Figura 43 por las herramientas de modelado que son realmente uacutetilespara el Soporte Teacutecnico Como hemos dicho el bloque de servicios del SoporteTeacutecnico pretende habilitar los mecanismos para traducir las acciones del usuarioen acciones dentro de la arquitectura Para ello la aplicacioacuten debe comunicarse enteacuterminos asimilables fuera del dominio teacutecnico y para conducir esta interaccioacuten seemplea aquiacute el estudio de los Casos de Uso Hacia el interior los requisitos capturadosen los casos de uso sirven como punto de partida para la estructuracioacuten del trabajo laEDT es la matriz en la que conectan los entregables para formar la solucioacuten completaal Soporte Teacutecnico pero su desarrollo no se va a lograr de forma secuencial - comopropondriacutea una aproximacioacuten claacutesica de desarrollo - sino en sucesivas iteracionesldquoaacutegilesrdquo en las que se va profundizando cada vez maacutes en la estructura y se vanevaluando los cambios y el cumplimiento de los requisitos con lo que se adquiereuna visioacuten maacutes profunda del conjunto con cada vuelta Los liacutemites a la extensioacuten deltrabajo los marca el Alcance acotado por la normativa del proyecto fin de carreray los objetivos iniciales del proyecto Gracias a estas herramientas de anaacutelisis esposible construir una metodologiacutea de modelado para el Soporte Teacutecnico que combinecomo esperamos el lenguaje UML los principios Agile y las caracteriacutesticas de lastecnologiacuteas y referentes incorporados

Los demaacutes elementos de esta metodologiacutea se identifican como ldquodisciplinas de mo-deladordquo y ldquoproductos de modeladordquo En la fase de conceptualizacioacuten del Soporterecurriremos a las disciplinas propias de los campos de aplicacioacuten en el proyectopor lo que volveremos sobre aspectos de integracioacuten inteligencia ambiental y el mo-delo ontoloacutegico del sistema Como producto de esta fase esperamos obtener unarelacioacuten de las diferentes entidades que participan en la aplicacioacuten asiacute como de unmodelo de datos comuacuten a todos los dominios del sistema estos descriptores seraacuten labase para desarrollar el protocolo de intercambio la programacioacuten de servicios y lasolucioacuten de integracioacuten que son los productos de las siguientes fases de modeladoPara alcanzar estos productos haremos uso en la fase de resolucioacuten de las discipli-

72

nas de disentildeo de servicios seguacuten SOA y la estructuracioacuten de trabajo de PMBOK porlo que partiendo de los puntos de alcance el desarrollo quedaraacute organizado en unaWBS33 de la que colgaraacuten los componentes y agentes de servicio que constituyanel ldquonuacutecleordquo de la arquitectura de servicio ofrecida al usuario final como parte delSoporte Teacutecnico

Figura 412 Propuesta metodoloacutegica para el modelado del Soporte Teacutecnico

En la siguiente figura definimos la arquitectura del Soporte visto por componentesy tecnologiacuteas de acuerdo con el modelo orientado a servicio Vemos coacutemo partien-do de los servicios ldquopuacuteblicosrdquo del sistema (los que son directamente visibles parael usuario final - sea un visitante o un creativo de la obra) se van incorporandoniveles de abstraccioacuten que se integran en el nuacutecleo del servidor Los planos colorea-dos en rojo corresponden a la parte del proyecto prescrita para su implementacioacutenen ZigBee la verde corresponde a UPnP y la azul a OSGi Podemos observar queZigBee se desarrolla en dos partes esto es debido a que la rama inferior (las ldquopatasrdquodel sistema) reflejan la parte de la red encargada de la recogida de datos mientrasque la otra (que seriacutea uno de los ldquobrazosrdquo) corresponde a los efectores instaladosen la red al igual que su rama simeacutetrica corresponde a la otra salida del sistemalos efectos multimedia de la instalacioacuten El soporte queda rematado por la interfaz33 Work Breakdown Structure o Estructura Detallada de Trabajo

73

Capiacutetulo 4

de usuario desde la que debe tener acceso a todos los dispositivos y servicios Estainterfaz no seriacutea efectiva sin la disponibilidad de una funcioacuten de asociacioacuten entre lasentidades de control de la red con sus dispositivos actuadores (resuelta en la ldquocapade participacioacutenrdquo del sistema) y una funcioacuten de intermediacioacuten que vuelque en lainterfaz web las variables de estado y control y de cara al sistema traduzca lasacciones del usuario en operaciones que puedan resolverse directamente en la capade participacioacuten Como vemos las partes maacutes complejas del proyecto correspondena los dos anillos que rodean al nuacutecleo en los que se desarrolla realmente la interope-rabilidad necesaria para coordinar tecnologiacuteas distintas y dar soporte a multitud deservicios

Figura 413 Arquitectura de la solucioacuten propuesta

El resto del documento de Proyecto queda organizado en torno a la Memoria dondese realiza todo el recorrido conceptual y teacutecnico para presentar explicar y justificarel Soporte como solucioacuten de integracioacuten y control para una obra de arte interactivoPartiendo de los Capiacutetulo 5 de la aplicacioacuten y el producto a desarrollar entrare-mos en el Seccioacuten 91 teoacuterico que nos conduce directamente a la especificacioacuten delCapiacutetulo 12 del trabajo para pasar a una descripcioacuten de los elementos de disentildeo yarquitectura software del Soporte Teacutecnico Para complementar esta descripcioacuten seincluye una parte de Parte VII en la que se han incluido todos los estudios bocetosy caacutelculos que apoyan el trabajo de ingenieriacutea presentado Finalmente se enume-ran y clasifican todos los elementos de desarrollo y documentacioacuten aportados con elProyecto incluyendo una los requisitos teacutecnicos y la organizacioacuten de todos estos ele-mentos en la EDT En un segundo volumen quedan reunidos todos los documentoscomplementarios al Proyecto que exige la normativa incluyendo planos de arquitec-tura archivos de configuracioacuten y manifiestos de la loacutegica de aplicacioacuten un listado

74

completo de los archivos de programa generados y los estudios con caraacutecter propiopara un proyecto software incluyendo un pequentildeo manual de puesta en servicio lapresentacioacuten de la documentacioacuten de coacutedigo y el anaacutelisis de viabilidad del proyecto

75