UNIVERSIDAD AUTNOMA DE GUERRERO UNIDAD ACADMICA DE INGENIERA

SEMINARIO DE TITULACIN ENERO-MARZO 2012

TRABAJO DE TITULACIN
MODALIDAD: MONOGRAFA

ARQUITECTURA DIRIGIDA POR MODELOS

QUE PRESENTA RAQUEL TORRES CANT

PARA OBTENER EL TTULO DE INGENIERO EN COMPUTACIN

DIRECTOR DE TRABAJO DE TITULACIN M. C. JORGE VZQUEZ GALARCE

CHILPANCINGO, GUERRERO, MARZO DE 2012.

DEDICATORIAS
A Mis Padres Por darme la oportunidad de realizar mis estudios Y estar siempre a mi lado demostrndome su amor, Confianza y cario por creer en m, a ellos les doy Las gracias hoy y siempre. Rafael Torres Talavera (+). Esperanza Cant Ramos.

A Mis Hermanos Quienes son mi gran apoyo y por toda la confianza Que me dieron Demostrndome su cario en los Momentos ms difciles de Nuestras vidas una vez ms Les hago sentir mis ms sinceros Agradecimiento por Todo lo que me han dado.

A Mi Familia Por ser personas importantes para m Y por darme nimos en los momentos Difciles y desearme lo mejor.

AGRADECIMIENTOS

A Dios Por darme la oportunidad De realizar mis estudios, y Sobre todo por darme un Hogar lleno de amor y confianza.

A Mis Amigos Por los momentos que compartimos Durante la carrera y por el apoyo mutuo Que se dio entre nosotros

A mi Director Por guiar nuestro trabajo por Tener paciencia, consejos Para la elaboracin.

CONTENIDO Paginas.
INTRODUCCIN......... 1 Justificacin... 2 Alcances.... Objetivos 2

I. ARQUITECTURA DE SOFTWARE
1.1. Evolucin de la arquitectura de software.. 3 1.2. Arquitectura de software............ 3

1.3. Patrones y estilos arquitectnicos................ 4 1.4. Ciclo de desarrollo de la arquitectura de software.. 5 1.4.1. Diseo arquitectnico... 6 1.4.2. vistas arquitectnicas... 1.4.3. Lenguajes de descripcin arquitectnica.. 7 7

1.5. Componentes.... 8 1.6. Campos de la arquitectura de software.... 9

II. MODELO DE VISTAS ARQUITECTONICAS DE SOFTWARE

2.1. Modelos propuestos de vistas en la arquitectura 10 2.2. Especificacin del modelo vista modular.. 14 2.3. Especificacin del modelo vista componentes y conectores 16

III. MODELO MDA

3.1. Antecedentes MDA.. 17

3.2 Lenguaje unificado de modelado UML.......... 19 3.3. Modelos MDA... 3.4. Transformacin de modelos... 21 22

3.5. Herramientas de transformacin 24 3.6. Desarrollo MDA. 24 3.7. Beneficios MDA CONCLUSIONES.... REFERENCIAS LISTA DE TABLAS Y FIGURAS......... 25 26 27 28

INTRODUCCIN
La arquitectura de software como una disciplina es importante, ya que los sistemas de software crecen de tal manera que resulta complicado, disear, especificar y entenderlos por un solo individuo. La arquitectura es un componente fundamental en la creacin de sistemas, las relaciones que se da entre ellos. La arquitectura es la organizacin de los componentes, estos se pueden clasificar en modelos que permiten ver la estructura y sus relaciones desde el anlisis y todos sus requerimientos necesarios, que ayudan a la toma de decisiones. Los modelos juegan un papel importante debido a que se quedan plasmados, contribuyendo en el proceso de desarrollo, es decir es la documentacin de los procesos y etapas en la elaboracin de un sistema. Dentro de la arquitectura de software podemos estudiar las vistas arquitectnicas, estas juegan un papel importante, ya que una vista es una representacin de una estructura arquitectnica que est compuesta por elementos y de relaciones. La representacin que una vista hace de una estructura, va ms all de la simple notacin grafica informal que se uso en los inicios de la arquitectura para representarla, esta se fundamenta en un modelo el cual contiene los elementos y las reglas para su realizacin. La arquitectura dirigida por modelos MDA se enfoca en la transformacin de modelos, proponiendo modelos independientes de computacin y de plataforma, que van desde el modelado, anlisis y el diseo. El propsito de MDA es lograr compatibilidad entre las plataformas obteniendo beneficios como productividad, portabilidad, interoperabilidad, mantenimiento y documentacin. Estos beneficios pueden darse a travs de los procesos de desarrollo, utilizando el modelo de plataforma independiente PIM y el modelo de plataforma especfico PSM en MDA que son pieza importante para realizar la transformacin en un modelo

JUSTIFICACION
La Arquitectura Dirigida por Modelos (MDA) es un tema importante el cual debemos de profundizar con ms detalle, ya que en la actualidad se requiere de una estructura bien formada y diseada de software. A medida en que las empresas u organizaciones se vuelven ms complejas los sistemas de desarrollo de software deben de crecer y cubrir todas las necesidades. La presente investigacin se realiza con la finalidad de dar a conocer la importancia y los beneficios que tiene la arquitectura de software y el modelo MDA.

ALCANCES
Esta investigacin esta dirigida a los estudiantes de la carrera de ingeniero en computacin y a todo profesional interesado, sobre la construccin y transformacin de modelos. Abarca los conceptos bsicos, de los diferentes tipos de lenguajes, procesos y beneficios del modelo MDA.

OBJETIVOS
Objetivos generales Dar a conocer de manera terica el modelo MDA, todo el proceso de desarrollo y beneficios que se pueden obtener a travs de el. Objetivos especficos Definir el concepto de la arquitectura de software y cuales son los elementos para el desarrollo. Cual es la funcin de las vistas y la importancia que tienen dentro de la arquitectura de software Dar una perspectiva de lo que es el modelo MDA, cuales son sus funciones y beneficios a porta.

1. ARQUITECTURA DE SOFTWARE 1.1. Evolucin de la Arquitectura de Software La arquitectura de software retoma sus antecedentes en 1960, su historia no ha sido continua, como la ingeniera de software, la arquitectura de software quedo en vida de estado oculto, durante varios aos. Iniciando su expansin de forma sorprendente con los escritos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado. Perry y Wolf son considerados los fundadores de la disciplina y su nombramiento, la arquitectura de software surge en la literatura haciendo referencia a la configuracin morfolgica de una aplicacin. Mary menciona las abstracciones de alto nivel, exigiendo un espacio para convencer y predecir que las abstracciones en el proceso de desarrollo de software, surge en un nivel de arquitectura de software en el diseo. Y por otra parte el desarrollo de grandes sistemas de software requiere de abstracciones de alto nivel. A principios de los 90s se menciono por primera vez la arquitectura de software en la nocin en la que se conoce actualmente y aparece realmente como disciplina cuando se publican los trabajos de Royce, Rechtin, Kruchten, destacando el trabajo de Perry y Wolf. Este trabajo es considerado como punto de inicio del auge de la arquitectura de software. El desarrollo y el inters hacia la arquitectura de software continuo desarrollndose y creciendo, integrndose como parte fundamental de la ingeniera de software. Convirtindose en una verdadera disciplina dentro de la ingeniera de software.

1.2. Arquitectura de Software. La arquitectura de Software es la estructura que comprende los componentes del software, sus propiedades visibles y las relaciones entre ambas.Es la organizacin fundamental de un sistema de software representado en sus componentes, el ambiente principios que orientan su diseo y evolucin. La necesidad del manejo de la arquitectura de un sistema de software nace con los sistemas de mediano y gran tamao que se proponen como una solucin a un problema determinado. En la medida que los sistemas crecen en complejidad. La arquitectura de software puede ser vista como la estructura del sistema en funcin de la definicin de sus componentes y sus interacciones. De la misma manera la arquitectura de software se considera como el puente entre los requerimientos y la implantacin. Las actividades que predominan en la definicin de la arquitectura se pueden ubicar en las fases tempranas del ciclo de desarrollo, anlisis de los requerimientos, anlisis de riesgos. Desde esta perspectiva, la arquitectura constituye una estructura de la actividad de diseo, el cual se utiliza de medio de comunicacin entre los integrantes del equipo de desarrollo, los clientes y usuarios finales, esta estructura pasa a ser la base del diseo a desarrollar, razn por la que la arquitectura es considerada como un plan de diseo ya que es usada como gua para el desarrollo.

Al hablar de arquitectura de software se hace mencin a la especificacin de la estructura entendida como la organizacin entre ellos, los requerimientos que debe integrar, las restricciones a las que esta sujeta, as mismo las propiedades no funcionales, su impacto sobre la calidad del mismo, las reglas y decisiones de diseo que rigen la estructura argumentos que justifiquen las decisiones tomadas. La arquitectura de software es importante ya que la manera en que se estructura un sistema tiene impacto directo sobre la capacidad de satisfacer los atributos de calidad los cuales son partes de los requerimientos que deben expresarse de forma cuantitativa. La arquitectura de software se necesita para: Organizar el desarrollo: Dividiendo el sistema en subsistemas, con las interfaces definidas y sus relaciones para realizaren las tareas. Fomentar la reutilizacin: especificando componentes determinadas que puedan ser usadas conjuntamente. con funcionalidades

Hacer que evolucione: que los cambios en los requerimientos puedan ser implementados sin mayor esfuerzo. La arquitectura de software es importante ya que facilita la comunicacin, ayuda a la toma de decisiones en cuanto a diseo, definiendo restricciones de implementacin, identificando atributos de calidad, manejando los cambios y utilizando modelos transferibles y reusables. Todos estos beneficios demuestran la necesidad de definir y especificar la arquitectura de software como paso previo a la construccin de un sistema.

1.3. Patrones y Estilos Arquitectnicos Un patrn de arquitectura de software es un esquema para solucionar determinados problemas. Este esquema se especifica describiendo los componentes responsabilidades, relaciones y las formas en que contribuyen. Un patrn arquitectnico tiene las siguientes funcionalidades: Ayuda a construir la experiencia colectiva. Resuelve problemas recurrentes es una abstraccin problema solucin. Identifica y especifica abstracciones de niveles ms altos. Los patrones buscan dar solucin de acuerdo al argumento en el que se encuentren, a raz de la recurrencia de situaciones, debido a esto surgen los estilos de arquitectura de software que son capaces de definir a sus componentes y conectores por las configuraciones y por las restricciones.

De acuerdo al entorno en que se encuentre la arquitectura de software su nivel de visualizacin tendr diferentes perspectivas. Un estilo arquitectnico representa los componentes y las relaciones, que existen las restricciones de su aplicacin asociaciones y reglas de diseo para su construccin. En un estilo arquitectnico se define un vocabulario de componente y conectores, es decir con los patrones arquitectnicos identificados, se propone una solucin que da paso a los estilos arquitectnicos que son aplicados.

1.4. Ciclo de Desarrollo de la Arquitectura de Software. Dentro del desarrollo de un proyecto, sin importar que metodologa se este usando, hablamos del desarrollo de la arquitectura de software, este procede a la construccin del sistema, comprendiendo cinco actividades fundamentales. Especificacin de software: Esta actividad es el resultado de la obtencin y anlisis de cada uno de los requerimientos generando el documento de las especificaciones. Diseo de software esta actividad permite convertir los requerimientos a un modelo, permitiendo definir cada uno de los componentes que se integran en la aplicacin de software. Desarrollo del software: Esta actividad consiste en la traduccin del diseo en una plataforma tecnolgica. Validacin del software: Se analiza la funcin a distintos niveles, para comprobar que los requerimientos sean cumplidos. Evolucin del software: Se agregan nuevas caractersticas al software desarrolladas, corrigiendo los problemas que se hayan detectado durante su uso. Anlisis de Requerimientos: Es un proceso que se realiza definicin de los servicios que se necesitan. para la comprensin y

En esta etapa se identifican y definen las restricciones desarrollo. Esto permite entender las principales funciones que deben incluirse en el software realizando un documento que tenga la especificacin. Diseo: En esta etapa se describe la estructura, componentes, conectores, interfaces y los algoritmos utilizados en el software que se desea implementar. Se desarrolla de forma iterativa a travs de varias versiones ya que no se llega a un diseo detallado inmediatamente. Diseo arquitectnico: Permite estructurar de forma general, el objetivo es tener una visin clara de lo que se desea realizar.

 Especificacin abstracta: Toma la arquitectura y la especificacin de requerimientos para definir al software en general. Diseo de interfaces: Estudia el flujo de la informacin para analizar la comunicacin entre los distintos componentes. Especificacin de componentes: permite identificar grupos de elementos para formar componentes. Cada componente permite abstraer una funcionalidad para poder ser reutilizado. Diseo de las estructuras de datos: es la actividad que detalla cada una de las clases y objetos que son necesarios para la construccin. El diseo es considerado una actividad importante que debe ser el centro de todo el desarrollo de software. A este nuevo enfoque se le conoce como desarrollo centrado en la arquitectura. El enfoque consiste en aprovechar todos los beneficios de la arquitectura de software para beneficio de lo que se desea desarrollar. Una buena arquitectura de software esta destinada al xito. En cambio una arquitectura deficiente esta destinada al fracaso.

1.4.1. Diseo Arquitectnico. Es la primera etapa del proceso de diseo en donde se identifican los elementos, se establece un marco de control y comunicacin. El diseo arquitectnico juega un papel muy importante en la ingeniera de diseo y los requerimientos siendo este el enlace entre ambas etapas. La documentacin de una buena arquitectura traer ventajas como: Comunicacin entre las diferentes personas que participan en el desarrollo: Esto se debe a que la arquitectura es una representacin de alto nivel, la cual es el punto de partida de intercambio de ideas. Anlisis de sistema: Dado que la arquitectura describe la estructura de todo el sistema, es posible realizar un anlisis en etapas tempranas del desarrollo permitiendo localizar los errores y tomar decisiones de diseo. Reutilizacin: La arquitectura nos muestra los diferentes componentes y la forma de cmo estos interactan, una buena arquitectura permite identificar los componentes que se pueden reutilizar.

1.4.2. Vistas Arquitectnicas Kruchten propone el modelado de arquitecturas utilizando cuatro diferentes vistas 4+1. Vista lgica: representa los requerimientos funcionales, usando abstracciones elaboradas desde el dominio del problema, esta es utilizada por el usuario final para asegurar que todos los requerimientos funcionales hayan sido considerados en la implementacin. Vista de procesos: describe los mecanismos de concurrencia y sincronizacin usados. Esta vista es utilizada por los integrantes para el anlisis del rendimiento y escalabilidad del sistema. Vista de desarrollo muestra el diseo del cdigo en el ambiente de desarrollo es utilizada por los lideres del proyecto y tiene como fin ayudar en la planeacin y evaluacin de progreso del proyecto. Vista fsica: muestra el mapeo del software en el hardware y refleja los aspectos de la distribucin, esta vista es desarrollada para determinar la topologa del sistema y sus requerimientos de comunicacin entre los distintos componentes. Los escenarios son el termino +1 dentro del 4+1. Los escenarios ilustran las distintas decisiones que son tomadas a lo largo de las cuatro vistas. En ellos se capturan las caractersticas generales.

1.4.3. Lenguaje de Descripcin Arquitectnica Desde el principio de la arquitectura del software surgi la necesidad de disponer de una notacin especfica para describirla, separando aspectos relativos de la estructura del sistema de otros detalles de desarrollo. Estas notaciones han ido evolucionando y recibiendo distintos nombres, siendo la denominacin ms utilizada actualmente la de lenguajes de descripcin arquitectnica o lenguajes de descripcin de arquitecturas (LDA) que se define como. Una notacin que describe y analiza formalmente las propiedades observables de una arquitectura software, dando soporte a distintos estilos arquitectnicos a diferentes niveles de abstraccin. La gran ventaja de usar un lenguaje de descripcin arquitectnica LDA sobre otras notaciones informales es que permiten una mejor comunicacin entre el diseador, implementadores y lectores debido a que la formalidad no deja lugar a la ambigedad, permite el anlisis formal y temprano de las decisiones de diseo. Los lenguajes de descripcin arquitectnica LDA son lenguajes que permiten modelar la arquitectura del sistema, analizar si es adecuada, determinar sus puntos crticos, incluso, simular su comportamiento. Todo esto es abordado antes de la implementacin.

Los lenguajes de descripcin arquitectnica LDA proporcionan construcciones para especificar abstracciones arquitectnicas y mecanismos para descomponer un sistema en componentes y conectores describen de qu manera estos elementos se combinan para formar configuraciones. Un arquitecto utiliza un lenguaje de descripcin arquitectnica LDA puede razonar sobre las propiedades del sistema de manera precisa, sin dejar un nivel de abstraccin que sea lo suficientemente alto. Su objetivo general es determinar los puntos crticos del desarrollo y eventualmente, simular su comportamiento. Las ventajas de un lenguaje de descripcin arquitectnica LDA viene dada por su poder expresivo para especificar la estructura y el comportamiento, pero tambin por su forma de uso, funcionalidad, rendimiento, flexibilidad, la capacidad de reutilizacin, la facilidad de comprensin y las restricciones tecnolgicas.

1.5. Componentes. Los componentes que encapsulan al procesamiento y los datos en una arquitectura de software son llamados componentes de software. Un componente de software es una entidad arquitectural que encapsula un subconjunto de funcionalidades del sistema y restringe el acceso a ese subconjunto. Este puede ser muy simple como una sola operacin o muy compleja como todo un sistema, dependiendo de la arquitectura, la perspectiva y las necesidades. Conectores: Un conector puede resultar un elemento crtico ya que es necesario para la integracin de funcionalidad de varios componentes y obtener el resultado esperado. Un conector de software es el encargado de gestionar las interacciones entre los componentes. Puerto: El concepto de puerto es similar al conector, pero no se debe confundir. Se denomina puerto a cada uno de los puntos por los que un componente puede realizar cualquier tipo de interaccin. Se puede decir que es cada uno de los segmentos en los que se fragmenta la interfaz de un componente. Hace referencia a un punto de entrada o de salida de la caja que se considera el componente. Los puertos se refieren tanto a los servicios que ste oferta. Por tanto, los puertos configuran la naturaleza externa de los componentes, lo que a su vez condiciona la estructura de la arquitectura.

1.6. Campos de la Arquitectura de Software La arquitectura del software abarca diferentes reas de investigacin terica y prctica. Se le asignan los siguientes campos de desarrollo: Lenguajes de descripcin de arquitecturas. Fundamentos formales de la arquitectura de software. Tcnicas de anlisis arquitectnico. Mtodos de desarrollo basados en arquitectura. Recuperacin y reutilizacin de arquitectura. Codificacin y gua arquitectnica. Herramientas y entornos de diseo arquitectnico. Casos de estudio. La reutilizacin es lo que ms justifica la arquitectura del software. Los estudios actuales tratan de conseguir un almacenamiento estructurado de este tipo de informacin reutilizable, en informacin de diseo de alto nivel propia de una familia de sistemas. Los campos ms prometedores de la arquitectura de software AS, tienen que ver con el tratamiento sistemtico de estilos, el desarrollo de los lenguajes de descripcin arquitectnica, la formulacin de metodologas, el trabajo con patrones de diseo. Se necesitan modelos precisos que permitan razonar sobre las propiedades de una arquitectura, verificar su consistencia y completitud. (Tahuiton Juan, 2011)

2. MODELO DE VISTAS ARQUITECTONICAS DE SOFTWARE.

Una vista es una representacin de una estructura arquitectnica est compuesta por elementos y relaciones asociadas, esta estructura representa el desarrollo y es constituida de los diferentes intereses en medida en que se involucra a los usuarios del sistema de software. Una estructura arquitectnica solicita el conjunto de elementos de software, incluidos en el nivel arquitectnico y no a todos los dems niveles del software. La representacin de una vista hace que una estructura, vaya mas all de la simple notacin grafica informal que se uso en los inicios de la arquitectura para representar (lneas, cuadros y crculos), ya que cada vista se fundamenta en un modelo el cual contiene los elementos y las reglas para establecer sus relaciones. Una vista en la arquitectura ha sido modelada de diversas maneras. Tomando como referencia lo anterior se puede profundizar en lo siguiente: Caracterstica de una vista, es la representacin de un sistema de software abarca todo la estructura, no solo una parte de l, as que independientemente de que elementos use una vista, puede modelar todo el sistema. Esta representacin se basa en un modelo que aporta reglas de como relacionar los elementos y el mtodo a seguir para su diseo. Una vista puede tener ms de un modelo y un modelo puede participar en ms de una vista. Notar y proyecta la vista, hacer notar que la vista viene de la percepcin que tienen los actores involucrados en el desarrollo de software, es la visualizacin que tiene el usuario. Con respecto a la vista arquitectnica, esta dirige a los atributos de calidad que sern aplicados en la arquitectura. Corresponde a un punto de vista, es una especificacin para construir y usar una vista en un patrn o plantilla para desarrollar vistas individuales, estableciendo los propsitos de una vista, tcnicas para su creacin y anlisis.

2.1 Modelos propuestos de vistas en la arquitectura. El diseo del software uno de las vas para realizar la separacin en varias dimensiones, mediante la descomposicin del sistema en estructuras que representan las vistas, la descomposicin de un sistema en estructuras es vital para un mejor entendimiento con varios niveles, para resolver problemas que surgen durante su anlisis esto es precisamente lo que se pretende con las vistas, descomponer la estructura en varios niveles.

En el nivel de requisitos, se ha mostrado como las vistas, han sido de gran apoyo en la disminucin de la complejidad de control del problema creando marcos de trabajo en funcin de ellas para el anlisis de los requisitos. Desde los inicios de la arquitectura de software se planteo la necesidad de contar con varias vistas para separar los diferentes elementos de software. Para poder realizarse se necesita un nmero de vistas diferentes de la arquitectura de software para diferente usos y usuarios estos son requeridas para detallar y entender diferentes aspectos de la arquitectura. Para esto se hace mencin de las diferentes propuestas que se describirn. Propuesta de Kruchten: consiste en un modelo llamado 4+1 vistas. El nombre de este modelo detalla el nmero de vistas en que se plantean 4 vistas. Son consideradas como ortogonales (aunque no del todo), la ltima es usada para vincular a las dems, dando un total de 5 vistas.

Vista lgica Escenario

Vista de desarrollo

Vista de procesos

Vista fsica

Figura 2.1 Modelo de vistas 4+1.

Como se muestra en la Figura 2.1 las vistas consideradas como ortogonales son la lgica, la del desarrollo, la de procesos y la fsica, la que las vincula es la de vista escenarios. Vista lgica: Esta vista esta enfocada al control del problema, guiando la separacin de los servicios que el sistema debe proporcionar a los usuarios finales, por lo cual sus principales asuntos de inters son los requerimientos funcionales, los cuales pueden ser modelados a travs de clases.

 Vista de procesos: La perspectiva de esta vista dirige una parte de espacio de la solucin, que comprende los requisitos no funcionales de desempeo la disponibilidad del sistema. Vista de desarrollo. La perspectiva en este suceso, esta orientada hacia la organizacin de los mdulos de software que ya han sido diseados e implementados dentro del ambiente de desarrollo. Los asuntos de inters requeridos, introduce los requisitos internos sobre las facilidades de desarrollo, administracin del software, reutilizacin y las limitaciones establecidas por el lenguaje de desarrollo. Vista fsica. Comprende determinados requisitos no funcionales, engloba la disponibilidad, fiabilidad, desempeo y escalabilidad del sistema, los cuales incluyen sus principales objetivos. Esta vista refleja la distribucin del sistema y los elementos de las vistas de desarrollo y de proceso son asignados a los nodos que conforman esta vista fsica, con lo cual se establece una correspondencia entre estas vistas. Vista de escenario. Esta vista tiene la funcin de unir a las otras cuatro vista mediante secuencias e interacciones que establece sus elementos. Tiene dos propsitos, como una gua arquitectnica para descubrir elementos arquitectnicos en el momento del diseo, y para validar e ilustrar el diseo de la arquitectura. Esta vista no crea ningn vnculo constante que mantenga la relacin entre una vista y otra, las interacciones que se establecen entre ellas se realizan con fines de prueba y validacin. A pesar de que este modelo no cuente con una manera clara de relacionar los elementos de una vista con otra, mantiene una relacin de correspondencia entre ellas, ya que los elementos de una vista son relacionados con los elementos de otra, lo cual expresa que las vistas no son de todo independientes. Propuesta de Siemens: Esta propuesta plantea cuatro vistas necesarias para organizar la arquitectura, estas vistas son: la conceptual, de mdulos, de ejecucin y de cdigo. Este enfoque establece una fuerte correspondencia entre los elementos de una vista con los de otra, ya que una vista produce elementos que son usados en otra, y a su vez cada vista esta limitada por otra. Estas relaciones de correspondencia son mostradas esquemticamente en la figura 2.2 mediante flechas, la flecha de mayor grosor indica lo que una vista aporta a la otra, y la flecha ms delgada las acciones o condiciones que una vista aplica a la otra

Arquitectura de software Vista conceptual

Vista de ejecu cion

Arquitectura

Vista modulo

Vista cdigo

Cdigo fuentes
Figura 2.2 Relacin entre las cuatro vistas.

Vista conceptual: Esta vista abarca la estructura funcional del sistema que se describe a travs de componentes funcionales enlazados mediante conectores, usando puertos y roles como interfaces. Esta vista es la mas cercana al control de la aplicacin porque esta restringida por la plataforma de software. La vista de mdulos. Se modela la estructura precisa de los subsistemas mediante su descomposicin en mdulos, estos mdulos son asignados a diferentes capas estos corresponden nicamente a los subsistemas, cada capa se relaciona con otra mediante un vinculo de dependencia. La vista de ejecucin. Esta vista consiste en representar la funcionalidad del sistema con elementos de procesos y libreras compartidas que corresponden a la plataforma de tiempo de ejecucin. La vista de cdigo. Es una consideracin del sistema en tiempo de diseo donde se muestra la implementacin del sistema organizado dentro del cdigo y los componentes de desarrollo. No se requiere una vista adicional para relacionar a las cuatro vistas consideradas, ya que cada una de ellas se encarga de establecer las relaciones con la vista correspondiente. Propuesta de SEI: plantea tres vistas como las estructuras fundamentales de la arquitectura de un sistema de software, esta es la de mdulos, de componentes y

conectores y la de asignacin. Cada una de estas tres vistas agrupa a su vez a otras vistas mas especificas, las cuales comparten los mismos tipos de elementos dentro de su grupo, lo que las hace diferentes es la forma en que se relacionan los elementos de cada una. La vista modular. Esta vista hace una particin de las funciones del software agrupndolas en unidades llamadas mdulos (de ah su nombre). Cada modulo representa las responsabilidades que el sistema debe cumplir de acuerdo a la especificacin dada en los requisitos. Las relaciones que se establecen entre los mdulos sealan la forma en que se hace la particin del software. La vista de componentes y conectores. En esta vista pretende modelar los aspectos del software en tiempo de ejecucin, como concurrencia y la comunicacin de procesos. Los componentes y conectores son los elementos que se usan para representar a las entidades del software que intervienen en la ejecucin. Las relaciones que se establecen entre ellos son bsicamente de comunicacin, en el cual los componentes se comunican a travs de los conectores. La vista de asignacin. Esta vista sirve para incorporar los elementos de las otras dos vistas (mdulos, componentes y conectores), a elementos del ambiente donde estarn ubicadas. La correspondencia que existe entre los elementos de una vista con los de la otra, en trminos generales establece una relacin entre sus elementos de muchos a muchos. 2.2. Especificacin del modelo vista modular. Esta vista se basa en una estructura que representa la descomposicin del sistema. La forma de descomponer el sistema mediante esta estructura es adecuada para modelar los sistemas complejos que se da en el software, ya que representan relaciones de jerarqua, lo cual es particular de los sistemas complejos, al observar la representacin que asume la estructura de varios sistemas El modulo es usado para agrupar las responsabilidades del sistema, es considerado como el elemento esencial para abordar la complejidad al ocultar los detalles de la implementacin. La estructura modular se ha consolidado como algo fundamental. El modulo representa la unidad de implementacin de software, al disear la arquitectura incluye la especificacin de las funciones que sern posteriormente diseadas e implementadas en las siguientes fases del desarrollo, ya que el propsito fundamental de la modularidad es incluir decisiones que deben realizar los mdulos antes de que se conviertan en unidades de implementacin.

Atributos que se usan para definir el modulo: Funcin principal que desempea es definir el modulo.

 Las responsabilidades que son asignadas, las cuales definen a los requisitos detectados y son considerados dentro del modulo. Las interfaces hacen posible establecer con precisin los roles que desempean los mdulos dentro del sistema. La informacin adicional con las caractersticas de la implementacin sobre la plataforma en que un modulo ser desarrollado Relaciones que se establecen entre los mdulos. Relacin usa: esta implica que un elemento tipo modulo usara las funciones de otro elemento de este tipo para completar sus funciones. Esto significa que el primer elemento (el que usa) tenga una fuerte dependencia del segundo (del usado), puesto que aunque son dos mdulos independientes el segundo es complementario del primero. Relacin usa capa: Se usa el mecanismo de abstraccin llamado capa, que permite realizar una separacin de tareas agrupando a los mdulos en diferentes niveles de abstraccin, de forma que los elementos de una capa se depuran en las funciones que en su conjunto brindan los elementos de otra capa. Relacin de descomposicin: Esta relacin indica que un modulo esta compuesto de varios mdulos mas, creando una divisin de un sistema en subsistemas. El objeto de esta divisin es dar un panorama de arriba hacia abajo del sistema, para entender como los mdulos pueden ser agrupados (o desagrupados) para despus organizar la asignacin de los productos de software a desarrollar al equipo de desarrollo.

MODULO X
Modulo a Modelo b Modulo a Modulo c

Modulo X

Modulo b

Modulo c

Figura 2.3 Representacin esquemtica de la relacin de Descomposicin.

Relacin de generalizacin: esta relacin concentran en un elemento las propiedades comunes que comparten varios elementos de mdulos, lo cual es nombrado como

generalizacin. En esta relacin se crea una estructura jerrquica donde el elemento padre posee las caractersticas comunes de los descendientes.

2.3. Especificacin del modelo vista componentes y conectores. Muestra las estructuras que adoptan los elementos de software usados en tiempo de ejecucin. En esta vista se modela la capacidad de interacciones entre las entidades ejecutables de software que se manifiesta al realizar las operaciones. El modelado a nivel arquitectnico de esta vista consiste en describir como estas interacciones llegan a configurarse, su tipo de flujo de comunicacin que se establecen entre estas entidades y el rol que desempea cada elemento. Esta vista es la que mas se menciona dentro de la arquitectura de software, ya que los componentes y conectores son considerados desde el nacimiento de la arquitectura de software. Se hace mencin de los componentes como elementos para el procesamiento y a los conectores se les denomina como elementos de interconexin. Son considerados como dos elementos bsicos de una arquitectura, ubicndolos en diferentes niveles de abstraccin. Actualmente, estos elementos son la base de casi todos lenguajes desarrollados para la descripcin arquitectnica (ADL`s). Los componentes son los principales elementos computacionales ejecutables y de almacenamiento de datos que intervienen en tiempo de ejecucin. Ya que un componente dentro de la arquitectura representa a dos tipos de elementos de un sistema (a elementos ejecutables y a los almacenes de datos), quienes juegan un papel importante en el ambiente de ejecucin. (Limn Rogelio, 2009)

3. MODELO MDA
3.1 Antecedentes MDA A finales del ao 2000 OMG (Object Management Group) presento su iniciativa MDA (Model Driven Architecture) arquitectura dirigida por modelos el cual tiene como objetivo acelerar el desarrollo de aplicaciones, simplificar la integracin entre distintas tecnologas y reducir el costo de la migracin de aplicaciones a nuevas plataformas. La clave de MDA es la importancia de los modelos en el proceso de desarrollo de software. MDA propone la definicin y uso de modelos a diferentes niveles de abstraccin para guiar todo el proceso de desarrollo (anlisis, diseo, mantenimiento y hasta la integracin), as mismo da la posibilidad de la generacin automtica de cdigo a partir de los modelos definidos y de las reglas de transformacin entre dichos modelos MDA aparece como respuestas a dos problemas fundamentales dentro de la industria informtica: Diversidad de plataformas y tecnologas: en la actualidad se oye hablar con frecuencia de los objetos distribuidos, los componentes, web services, entre otras tantas estrategias tecnolgicas en las que no hay mucha compatibilidad y que tienen tendencia a aumentar. La acelerada evolucin tecnolgica: esto ocasiona que las plataformas muy pronto sean obsoletas. MDA tiene el propsito de lograr la compatibilidad de las herramientas y plataformas, posibilitando evadir los problemas por la diversidad de las mismas y la evolucin tecnolgica. Obteniendo beneficios en aspectos fundamentales como: Productividad: Por medio de los modelos independientes de cmputo (CIM), modelo independiente de plataforma (PIM) y el modelo de plataforma especfica (PSM), se logran las transformaciones automticamente, en gran parte, al igual que la generacin de cdigo, permitiendo que el trabajo lo realice la herramienta y no el desarrollador. Portabilidad: Se da mediante el modelo de plataforma independiente PIM, el cual permite que todo lo definido en el pueda ser portable hacia cualquier plataforma. Interoperabilidad: los modelos PSM no podrn comunicarse directamente entre ellos, ya que pueden pertenecer a diferentes tecnologas. Este problema se resuelve generando los modelos PSM y los puentes entre ellos. Mantenimiento y documentacin: el modelo PIM desempea el papel de la documentacin de alto nivel que se necesita para cualquier sistema de software. Para conseguir los beneficios mencionados, MDA plantea el siguiente proceso de desarrollo.

1. Primero los requerimientos para el sistema se presentan en un modelo CIM, que describe la situacin en que el sistema ser usado. 2. Posteriormente este modelo es transformado en un modelo PIM que describe el sistema, pero no muestra los detalles de su uso en una plataforma tecnolgica particular. 3. Despus de obtener el modelo PIM se realiza otra transformacin hacia un modelo PSM, que contiene el detalle necesario para utilizar la plataforma tecnolgica en que el sistema funcionar. 4. Por ltimo teniendo el modelo PSM se realiza una transformacin que resulta en la generacin de cdigo para lograr una solucin o modelo ejecutable. Para entender el modelo MDA se deben considerar los siguientes conceptos: Modelo: el modelo de un sistema es una descripcin o especificacin de su entorno para desempear un determinado objetivo. Dirigido por modelos: MDA es dirigido por modelos porque usa mecanismos para guiar el mbito del desarrollo, el diseo, la construccin, implementacin, operacin, mantenimiento y la modificacin de la aplicacin. Arquitectura: la arquitectura de un sistema es la especificacin de sus partes que lo integran como las conexiones, las normas de interaccin haciendo uso de las conexiones especificadas. Plataforma: Es un conjunto de subsistemas y tecnologas a travs de interfaces y determinados patrones ya que cualquier aplicacin que sea construida para alguna plataforma se pueda usar, sin preocuparse por la forma en como funciona. Aplicacin: En MDA se define el trmino aplicacin como una funcionalidad que tiene que ser desarrollada. Podemos definir un sistema en funcin de la implementacin de las aplicaciones que soporta la plataforma. Independencia de la plataforma: Es una ventaja que presentan los modelos. Lo cual indica que un modelo tiene caractersticas que incluyen las plataformas. Transformacin de modelos: Se considera el proceso central MDA, con el objetivo de lograr un estndar para la transformacin, OMG inicia un proceso de estandarizacin que favorece la presentacin de propuestas (RFP Request for Proposal) por parte de la comunidad informtica alrededor del estndar denominado QVT (Queries/Views/ Transformations). Este estndar est basado en MOF y permite establecer un lenguaje para la transformacin de modelos (T), un lenguaje para consulta de modelos (Q), un lenguaje para la definicin y generacin de vistas (V) que facilite el anlisis de modelos desde diferentes perspectivas de los desarrolladores.

La arquitectura dirigida por modelos MDA utiliza el modelo del lenguaje unificado UML para guiar el proceso de desarrollo y generar a travs del mismo.

3.2 Lenguaje Unificado de Modelado UML UML es un lenguaje grafico de propsito general para especificar, construir, visualizar y documentar los objetos del sistema. UML se emplea: Durante todo el ciclo de vida del sistema. Con distintas tecnologas. Emplea un proceso de desarrollo guiado por casos de uso. Modelos y diagramas de UML Describe completamente el sistema pero desde un nico punto de vista, son abstracciones del sistema que permiten especificar de distinto nivel de detalle. Diagramas de casos de uso: muestra las relaciones entre actores y casos de uso dentro del sistema. Describen el comportamiento, establecen los lmites del sistema y las relaciones en el entorno.

Caso de uso 1

Caso de uso 2

Caso de uso

Actor 1

Caso de uso 3 Actor Actor 3 Interaccin

Figura 3.1 Diagramas de casos de uso

Diagramas de clases: es representado por un rectngulo, el cual contiene el nombre de la clase los atributos y las operaciones que van a realizar.

Nombre de la clase Atributos Operaciones

Figura 3.2 Diagrama de clases

Modelo de paquetes: Los paquetes proporcionan un mecanismo general para organizar los distintos submodelos en los que se divide un modelo.

Nombre del paquete

Figura 3.3 Modelo de paquetes

Diagrama de transicin de estado: muestra todos sus estados relevantes y sus transiciones necesarias para pasar de un estado a otro.

Figura 3.4 diagrama de transicin de estados

Diagramas de componentes: representan los tipos de elementos software, archivos, paquetes .Describe los elementos fsicos del sistema y sus relaciones. Permite modelar la estructura del software y la dependencia entre componentes.

Componente Componente

Componente

Figura 3.5 Diagrama de componentes

3.3 Modelos MDA La arquitectura dirigida por modelos define dos modelos conceptuales dentro de su estructura. Modelo independiente de plataforma (Pim Platform Independent Model). Modelo especifico de plataforma PSM ( Platform Specific Model). Modelo independiente de plataforma PIM (Platform Independent Model). Es un modelo con un alto nivel de abstraccin que describe la estructura, funcionalidad y restricciones del sistema, sin mostrar detalles de su utilizacin en una plataforma especifica. El modelo independiente de plataforma tiene las siguientes utilidades Fcil comprensin para los usuarios. Facilita la generacin de diferentes implementaciones del sistema en diferentes plataformas, conservando su estructura y funcionalidad bsica. El modelo independiente de plataforma PIM debe expresarse en un lenguaje bien definido y preciso que permita definir los aspectos estructurales y el comportamiento del sistema

Modelo especifico de plataforma PSM Es un modelo del sistema con detalles especficos de la plataforma en la que ser implementado. Este modelo es generado a partir del modelo independiente de plataforma PIM, de tal manera que representa el mismo sistema pero a un distinto nivel de abstraccin. Un PSM es un PIM con detalles especficos para ser implementado en una plataforma determinada. Los puentes de comunicacin. Es importante mencionarlos por que a partir de un mismo modelo independiente de plataforma pueden generarse varios modelos especficos de plataformas, cada uno realizando una descripcin del sistema desde una perspectiva diferente. Cdigo de la aplicacin: El cdigo es generado mediante la aplicacin, a partir del modelo especfico de plataforma, a travs de la herramienta de transformacin, en la cual se obtiene una gran parte del cdigo que implementa el sistema para la plataforma seleccionada.

3.4 Transformacin de Modelos. La transformacin es el proceso, basado en una serie de reglas, define los mecanismos para el paso de un modelo origen a un modelo destino. A partir de la estandarizacin promovida por QVT, atendiendo a las necesidades prcticas de la transformacin de modelos, surgen diversas estrategias de transformacin que van ms all del uso de elementos del modelo y definen mecanismos de transformacin basados en tipos de elementos, patrones, plataforma y otros modelos. Una de las ventajas de esta arquitectura es lograr que de un mismo PIM se pueda generar ms de un PSM. Para permitir la interoperabilidad entre los diferentes PSM. Transformacin de modelos. Una transformacin de modelos (Mapping MDA), proporciona la especificacin de la transformacin de un PIM en un PSM para una plataforma determinada. Para llevar a cabo esta actividad se especifican dos tipos de transformaciones. Transformacin de tipos. Transformacin de instancias. Transformacin de tipos: A cada tipo de elemento PIM se le aplica una regla determinada para transformarlo en uno o en varios elementos PSM. Transformacin de instancias: Identifica elementos especficos de PIM que deben ser transformados de forma particular dada, en una plataforma. Toda transformacin de instancias del modelo tiene restricciones implcitas, que deben cumplirse al marcar el modelo, para que la transformacin tenga sentido.

PIM

TRANSFORMACION

PSM
Figura 3.6 Transformacin de modelos

Caractersticas de transformacin. El proceso de transformacin de modelos contiene una serie de propiedades para realizar los objetivos de la arquitectura dirigida por modelos. Estas propiedades son: Ajustar las transformaciones. Trazabilidad. Consistencia incremental. Bidireccionalidad.

Ajustar las transformaciones: Las herramientas de transformacin de modelos deben permitir al desarrollador tener el control sobre el proceso de transformacin. Esto se logra de la siguiente forma. Control manual: el desarrollador tiene control directo sobre la transformacin. Seleccionando los elementos a ser transformados con determinadas reglas de trasformacin definidas. Condiciones en la transformacin: el desarrollador asigna una condicin a una regla de transformacin, indicando como y cuando debe aplicarse esa regla. Parmetros de transformacin: se identifican las definiciones de las transformaciones con el propsito de que el desarrollador pueda tener un control total del proceso de transformacin. Trazabilidad: es una caracterstica muy importante dentro de las transformaciones, permite conocer el elemento origen a partir d el cual se ha generado cualquier elemento en el modelo destino. La utilidad que proporciona esta propiedad dentro de MDA es la bsqueda y correccin de errores que pueden ocurrir en el proceso de transformacin de modelos.

Consistencia incremental: una vez generado un modelo destino a partir de un modelo origen, podra suceder que sea necesario un cambio en el modelo destino, por ejemplo un refinamiento de la interfaz del usuario, en este caso se puede generar nuevamente el destino, debido a cambios en el modelo origen, manteniendo estos cambios. Bidireccionalidad: implica que las transformaciones pueden operar en ambas direcciones. Esto se puede lograr de dos formas. Ambas transformaciones: se ejecutan de acurdo con una nica definicin de transformacin. Una transformacin y su inversa se especifica mediante dos definiciones de transformaciones diferentes.

3.5 Herramientas de Transformacin. Las herramientas de transformacin son parte fundamental de MDA ya que son las que permitan trabajar de manera transparente con todos los conceptos. MDA puede darse en diferentes variantes y en distinto tipo de herramientas de transformacin. Herramientas de transformacin de PIM A PSM: Este tipo de herramientas permiten transformar un modelo independiente de plataforma (PIM) de alto nivel en uno o varios modelos especficos de plataforma (PSM). Herramientas de transformacin de PSM a cdigo: El soporte ms popular para MDA existe en las herramientas que transforman PSM a cdigo. Tiene una definicin de transformacin integrada tomando un tipo predefinido de modelo de entrada (PSM) y producen uno ms predefinido como salida. Esta herramienta mantiene la relacin entre el PSM y el cdigo, generando que los cambios realizados en cualquiera de los modelos se realicen inmediatamente en el otro. Herramientas de transformacin de PIM a cdigo: Este soporta las dos transformaciones mencionadas anteriormente, de PIM a PSM y de PSM a cdigo, este proceso ser transparente para el desarrollador, ya que nicamente se vera una transformacin directa de PIM a cdigo, dejando de manera implcita al PSM.

3.6 Desarrollo MDA El proceso de desarrollo con arquitectura dirigida por modelos MDA mismas etapas del desarrollo tradicional. Anlisis. Diseo. Codificacin. Prueba. Implementacin. mantiene las

Anlisis: Se desarrolla el modelo independiente de plataforma PIM guiados por las necesidades y la funcionalidad que incorporar el sistema. Diseo: Los encargados, realizaran la transformacin del PIM a uno o mas PSM, los involucrados debern tener conocimientos sobre las distintas plataformas y arquitecturas. Codificacin: En esta etapa se reduce la generacin de cdigo mediante herramientas especializadas. La persona encargada de realizar esta operacin, se encargara de dar funcionalidad.

3.7 Beneficios MDA Productividad: la parte central de MDA es el PIM, ya que este genera de forma automtica los PSM, una vez realizada esta tarea de manera correcta, se pueden utilizar en trabajos posteriores de forma mas rpida utilizando estas herramientas de transformacin. Portabilidad: Se da a partir de el PIM, ya que es un modelo independiente de cualquier plataforma y tecnologa todo lo que se define dentro de esta es totalmente portable. Interoperabilidad: Los PSM generados a partir de un mismo PIM normalmente tienen una relacin entre si. MDA adems de generar PSM a partir de un mismo PIM tambin genera los puentes de comunicacin entre ellos. Mantenimiento y documentacin: El modelo independiente de plataforma PIM desempea el papel de la documentacin de alto nivel que se necesita para cualquier sistema. El PIM no se abandona despus de la codificacin. Los cambios realizados en el sistema se reflejan en todo los niveles, mediante la regeneracin de los PSM y el cdigo.
(Das Ana, 2009)

Conclusiones
La arquitectura de software es la base para la creacin de sistemas, ya que a travs de esta se hace el anlisis y creacin de toda la estructura de software, este anlisis queda plasmado en la documentacin del sistema o proyecto para futuras modificaciones que se hagan. Esto resulta difcil ya que no se trabaja as, muchos desarrolladores ya no dan el mantenimiento a la documentacin quedando esta obsoleta, ya que por lo regular cuando surgen cambios en el cdigo estos no se agregan a la documentacin y por tanto se va perdiendo la interaccin entre ambos (estructura y cdigo). La arquitectura dirigida por modelos MDA es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. MDA tiene como propsito la compatibilidad entre las diversas plataformas, evadiendo los problemas de la acelerada evolucin tecnologa, obtenido mejores beneficios como productividad, portabilidad, interoperabilidad y mantenimiento. La transformacin de modelos es la parte central de MDA, apoyndose en el lenguaje unificado UML el cual permite especificar, construir y visualizar los objetos a travs de los diferentes modelos y diagramas utilizados en este lenguaje. Facilitando su comprensin de toda la estructura del sistema a crear. Llegando a la conclusin de que la arquitectura de software y el modelo MDA son de gran importancia para el desarrollo de software gracias a los procesos, herramientas y los modelos que se utilizan en la creacin, dando una vista general de toda la estructura del sistema, logrando que el desarrollo sea mas rpido para una mejor toma de decisiones. Ayuda a resolver los problemas de portabilidad entre las diferentes plataformas que existen y es ms rpido su desarrollo, lo cual genera menos costo y es ms productivo.

REFERENCIAS

(Ingeniera de modelos mda)

http://dis.um.es/~jmolina/Ingenieria%20de %20modelos%20con%20MDA.pdf http://bibdigital.epn.edu.ec/bitstream/15000 /342/1/CD-0306.pdf. http://www.dsic.upv.es/docs/bibdig/tesis/etd-10132009-094823/borradortesis-rogelio-2.pdf.

(bibdigital,edu)

(Limn Rogelio, 2009)

(Vsquez, Morales)

http://www.moralesvazquez.com/pdfs/arqui tectura.pdf. ftp://190.5.199.3/jjurado/ingenieriasoftware 2011 arquitecturasoftware.pdf

(Ingeniera de software, 2011)

(Journal, org) http://www.iiisci.org/journal/CV$/risci/pdfs/ C476AI.pdf (bibdigital,edu) http://bibdigital.epn.edu.ec/bitstream/15000 /342/1/CD-0306.pdf.

(Universidad pontifica de salamanca)

Arquitectura dirigida por modelos para J2ME. Luis Enrique Corredera de Colsa. Doctorando en Ingeniera del software. Universidad Pontificia de Salamanca. http://cs.cinvestav.mx/TesisGraduados/ 2011/tesisJuanTahuiton.pdf

(Tahuiton Juan, 2011)

(Das Ana, 2009)

http://bibcyt.ucla.edu.ve/edocs bciucla/DiasAna/tdigD53 V.2009.pdf

LISTA DE TABLAS Y FIGURAS Pgina. Figura 2.1. Modelo de vistas 4+1.. 11 Figura 2.2. Relacin entre las cuatro vistas.... 13 Figura 2.3. Representacin esquemtica de la relacin de descomposicin... Figura 3.1. Diagrama de casos de usos.. Figura 3.2. Diagrama de clases.... 15 19 20

Figura 3.3. Modelo de paquetes 20 Figura 3.4. Diagrama de transicin de estados.. 20 Figura 3.5. Diagrama de componentes 21 Figura 3.6. Transformacin de modelos.. 23