Arquitectura De Software

FACULTAD DE CIENCIAS BÁSICAS E INGENIERIA CORPORACIÓN UNIVERSITARIA REMINGTON DIRECCIÓN PEDAGÓGICA Ingeniería de Sistemas

Asignatura: Arquitectura del Software Dirección de Educación a Distancia y Virtual Este material es propiedad de la Corporación Universitaria Remington (CUR), para los estudiantes de la CUR en todo el país. 2012

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

CRÉDITOS

El módulo de estudio de la asignatura Arquitectura del Software es propiedad de la Corporación Universitaria Remington. Las imágenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la bibliografía. El contenido del módulo está protegido por las leyes de derechos de autor que rigen al país. Este material tiene fines educativos y no puede usarse con propósitos económicos o comerciales.

AUTOR Edilberto Restrepo Restrepo Magister en Educación Superior de la Pontificia Universidad Javeriana, Especialista en Gerencia de Proyectos de la Universidad del Tolima, Administrador de Empresas y Tecnólogo en Administración de Redes de Datos. Con 18 Años de experiencia como docente y Diseñador de asignaturas en las áreas de Lógica y Programación, Mantenimiento de computadores, Administración de Redes de Datos, asesoría de proyectos informáticos y productivos de emprendimiento. En instituciones como CESDE, Universidad San Martin, Universidad Cooperativa de Colombia, Comfenalco, Comfama y Microempresas de Antioquia. Actualmente coordinador de la Unidad de formación en la corporación Universitaria Remington. Con ponencias sobre procesos evaluativos, Cesde 2005, Aprendizajes colaborativos, Remington, 2011. Actualmente miembro del grupo de investigación AVICUR. [email protected] [email protected] Nota: el autor certificó (de manera verbal o escrita) No haber incurrido en fraude científico, plagio o vicios de autoría; en caso contrario eximió de toda responsabilidad a la Corporación Universitaria Remington, y se declaró como el único responsable.

RESPONSABLES Dr.Jorge Mauricio Sepúlveda Castaño [email protected] Director de la Facultad de Ciencias Básicas e Ingeniería Tomás Vásquez Uribe Director Educación a Distancia y Virtual tvasquez @remington.edu.co Angélica Ricaurte Avendaño Coordinadora de Remington Virtual (CUR-Virtual) [email protected]

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

GRUPO DE APOYO Personal de la Unidad de Remington Virtual (CUR-Virtual) EDICIÓN Y MONTAJE Primera versión. Febrero de 2011.Segunda versión Marzo 2012 Derechos Reservados

Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

TABLA DE CONTENIDO 1. MAPA DE LA ASIGNATURA ................................................................................................. 9 2. EL MODELAMIENTO UNIFICADO ....................................................................................... 10 2.1. Relación de conceptos ............................................................................................................ 11 2.2. Prueba Inicial ........................................................................................................................... 11 2.3. Técnicas comunes y Avanzadas de modelado con UML. ........................................................ 12 2.4. Reglas del Negocio .................................................................................................................. 25 2.5. Principios de desarrollo de aplicaciones Web......................................................................... 26 2.6. La Arquitectura en el Proceso Unificado de Desarrollo .......................................................... 29 3. LA ARQUITECTURA DE SOFTWARE. ................................................................................... 37 3.1. Relación de conceptos ............................................................................................................ 37 3.2. Prueba Inicial ........................................................................................................................... 38 3.3. Modelos de arquitectura de software. ................................................................................... 38 3.4. Enfoques arquitectónicos de software ................................................................................... 47 3.5. Modelado Arquitectónico en UML 2.0 .................................................................................... 51 4. DEFINICIONES Y PATRONES DE SOFTWARE. ...................................................................... 63 4.1. Prueba Inicial ........................................................................................................................... 64 4.2. Definiciones Básicas ................................................................................................................ 64 4.3. Catálogos de Patrones ........................................................................................................... 68 5. FRAMEWORKS Y EL MÓDELO MDA (MODEL DRIVEN ARCHITECTURE) ............................. 101 5.1. Relación de conceptos .......................................................................................................... 101 5.2. Prueba Inicial ......................................................................................................................... 102 5.3. Definición y Estructura del Frameworks .............................................................................. 102 5.4. MDA (Model Driven Architecture) ........................................................................................ 106 6. ASPECTOS ...................................................................................................................... 121 6.1. Relación de conceptos .......................................................................................................... 121 6.2. Prueba Inicial ......................................................................................................................... 121 6.3. Definiciones Básicas .............................................................................................................. 122 Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

6.4. Lenguajes orientados a aspectos .......................................................................................... 127 7. PISTAS DE APRENDIZAJE ................................................................................................. 134 8. GLOSARIO ...................................................................................................................... 135 9. BIBLIOGRAFÍA ................................................................................................................ 136

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

1. MAPA DE LA ASIGNATURA ARQUITECTURA DEL SOFTWARE

OBJETIVO GENERAL DEL MODULO En un mundo globalizado, donde cada día desaparecen las barreras comerciales y culturales, la calidad se torna en necesidad, pues permite competir con mayores posibilidades de éxito. A pesar de que la programación de sistemas no había sido concebida desde la perspectiva de la calidad, la calidad en productos de software ha tenido un auge importante en la sociedad informatizada de hoy, La calidad del software permite elaborar actividades sistemáticas que se necesitan para lograr software con calidad, la Calidad involucra actividades de evaluaciones, auditorias y revisiones, estándares que se aplicarían al proyecto, mecanismos de medida (métricas), métodos y herramientas de análisis, diseño, programación y prueba, documentación y control.

OBJETIVO GENERAL Apropiar en el estudiante conceptos y prácticas de Arquitectura y Diseño de Software aplicables a escenarios de la vida real. OBJETIVOS ESPECÍFICOS Dar a conocer las generalidades y conceptos básicos de UML y el desarrollo de aplicaciones para la infraestructura de un proyecto web. Presentar de manera práctica las diferentes metodologías y buenas prácticas para documentación y evaluación de arquitecturas de software Apropiar el uso de catálogos de elementos reusables en el diseño de sistemas software Identificar las características de un framework para Web y apropiarse del modelado bajo el enfoque MDA. Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos.

UNIDAD 1 Mediante la conceptualización y aplicación en situaciones problema, el estudiante podrá apropiarse de los procesos de modelamientos UML.

UNIDAD 2 El estudiante podrá plantear propuestas metodológicas para la documentación de las prácticas productivas de desarrollo de software.

UNIDAD 3 Mediante el abordaje y aplicación de los diferentes patrones de elementos reusables el estudiante obtendrá criterios de aplicación en contextos diversos

UNIDAD 4 Identificando las características de los frameworks, y modelado MDA, el estudiante planteará solución a necesidades reales de desarrollo de software

UNIDAD 5 Conociendo los conceptos sobre la programación orientada a aspectos, el estudiante podrá determinar las situaciones en las cuales sea más pertinente su aplicación en el desarrollo de software

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

2. EL MODELAMIENTO UNIFICADO OBJETIVO GENERAL Dar a conocer las generalidades y conceptos de UML y el desarrollo de aplicaciones Web para la infraestructura de un proyecto de software. OBJETIVOS ESPECÍFICOS Evidenciar las técnicas comunes y avanzadas del Modelamiento UML gráficamente la arquitectura de un proyecto web.

mostrando

Determinar de forma adecuada las políticas o reglas del negocio que rigen a una empresa para hacerlo escalable en el tiempo. Argumentar de forma clara y precisa cada una de las etapas empleadas en el Proceso Unificado de Desarrollo. Proponer modelamiento de negocios adecuado y apropiado a cualquier escenario de la vida real.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

2.1. Relación de conceptos

2.2. Prueba Inicial Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su grado de asimilación a) b) c) d) e) f) g) h)

¿Qué entiende usted por Modelado UML? ¿Qué técnicas de modelamiento puedes describir? ¿Cómo se dividen los bloques de construcción? ¿Qué entiende usted por clase, Interfaz, Colaboración, Casos de uso, Clase Activa? ¿Qué Conoce de los diagramas que se involucran en el modelamiento UML? ¿Qué aspectos se identifican mediante las reglas del negocio? ¿Sobre qué principios se fundamenta el desarrollo de aplicaciones web? ¿Mediante qué elementos se estructura el proceso unificado de desarrollo?

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

2.3. Técnicas comunes y Avanzadas de modelado con UML. Notas Una nota es un símbolo gráfico utilizado para suministrar restricciones o comentarios vinculados a un elemento o a una colección de elementos. Gráficamente, una nota se representa como un rectángulo con la esquina superior derecha doblada, junto con un comentario textual o gráfico. El UML proporciona todas las herramientas necesarias para visualizar, especificar, construir y documentar los artefactos de un rango amplio de sistemas completos de software. También podemos encontrar en algunas ocasiones de otros elementos adicionales al UML para poder modelar un escenario que se adapte a nuestras necesidades. Un lenguaje es usado o empleado para comunicar una idea de forma clara y precisa para cualquier sistema de información. En UML utilizamos notas para dar a entender una idea clara sobre algo y por medio de ellas explicamos ideas que de forma gráfica se hace difícil. Las notas pueden representar artefactos, para hacer más atractivo del ciclo de vida en el desarrollo de software, también como los requerimientos solicitados por el usuario, o pueden representar simplemente observaciones en forma libre, revisiones, o explicaciones. El UML proporciona la nota como una representación gráfica para incluir comentarios o restricciones; por medio de las notas se permite realizar enlaces a archivos. En la Figura 1 tenemos un ejemplo de una nota en UML. Estereotipos: Un estereotipo amplía el vocabulario UML, permitiendo crear nuevos tipos de bloques de construcción similares a los existentes pero específicos para tu problema. Gráficamente, un estereotipo se representa con un nombre encerrado entre pico paréntesis y colocado arriba del nombre de otro elemento. Como una opción, el elemento estereotipado puede ser representado usando un nuevo icono asociado con el estereotipo. Los estereotipos, valores etiquetados y las restricciones son los mecanismos, proporcionados por el UML, utilizados para añadir nuevos bloques de construcción, crear nuevas propiedades y especificar semánticas nuevas respectivamente. Por ejemplo, si estás modelando una red, puedes necesitar símbolos para los enrutadores y los concentradores; puedes usar nodos estereotipados para hacer que estos elementos aparezcan como bloques primitivos de construcción. Similarmente, si eres parte del equipo responsable del ensamble, de la prueba y de la liberación, puedes conservar registros con respecto al número de versión y resultados de la prueba para cada subsistema. Puedes usar valores etiquetados para añadir información a tus modelos. Finalmente, si estás modelando con dificultad sistemas en tiempo real, puedes adornar tus modelos con información de tiempo presupuestal y líneas muertas; puedes usar restricciones para capturar estos requerimientos de tiempo.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Ilustración sobre Estereotipos, Valores etiquetados y Restricciones.

Valor etiquetado:Un valor etiquetado amplía las propiedades de un elemento UML, permitiendo crear nueva información en lo que respecta a la especificación del elemento. Gráficamente, un valor etiquetado se representa como una cadena encerrada entre llaves y colocada bajo el nombre de otro elemento. Restricción: Una restricción amplía la semántica de un elemento UML, permitiendo añadir nuevas reglas, o modificar las existentes. Gráficamente, una restricción se representa como una cadena encerrada entre llaves y colocada junto al elemento asociado o, conectada a el(los) elemento(s) con relación de dependencia. Como una alternativa, puedes incluir una restricción en una nota.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Técnicas avanzadas de modelado con UML Primero comencemos haciendo una diferencia entre Metodología y Modelo, Una metodología es aquella guía que se sigue a fin de realizar las acciones propias de una investigación. En términos más sencillos se trata de la guía que nos va indicando qué hacer y cómo actuar cuando se quiere obtener algún tipo de investigación. Es posible definir una metodología como aquel enfoque que permite observar un problema de una forma total, sistemática, disciplinada y con cierta disciplina. Al intentar comprender la definición que se hace de lo que es una metodología, resulta de suma importancia tener en cuenta que una metodología no es lo mismo que la técnica de investigación. Las técnicas son parte de una metodología, y se define como aquellos procedimientos que se utilizan para llevar a cabo la metodología, por lo tanto, como es posible intuir, es uno de los muchos elementos que incluye. En el contexto de la investigación son muchas las metodologías que es posible seguir, sin embargo, existen 2 grandes grupos que incluyen a otras más específicas. Se trata de la metodología de investigación cuantitativa y la cualitativa. La metodología cuantitativa es aquella que permite la obtención de información a partir de la cuantificación de los datos sobre variables, mientras que la metodología cualitativa, evitando la cuantificación de los datos, produce registros narrativos de los fenómenos investigados. En este tipo de metodología los datos se obtienen por medio de la observación y las entrevistas, entre otros. Como vemos, la diferencia más importante entre la metodología cuantitativa y la Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

cualitativa radica en que la primera logra sus conclusiones a través de la correlación entre variables cuantificadas, y así poder realizar generalizaciones y producir datos objetivos, mientras que la segunda estudia la relación entre las variables obtenidas a partir de la observación en contextos estructurales y situacionales. Ahora miremos qué es un modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas para un conjunto de descripciones que de otra manera no podrían ser sistematizadas. De esta manera, su estructura es diferente de la que se supone existe en el conjunto de fenómenos de la naturaleza. Para el caso de arquitectura de software usamos el Modelo de UML. A continuación veamos la Historia del UML La notación UML se deriva y unifica las tres metodologías de análisis y diseño Orientada a Objeto más extendidas: Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones. Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique). Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case). El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE. De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos. Qué es UML? UML es el primer método en publicar una meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de una meta-modelo auto-referencial, cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

UML es un lenguaje estándar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real. UML es solamente un lenguaje por lo que es sólo una parte de un método de desarrollo software, es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, además es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la representación conceptual y física del sistema. UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos o mediante texto obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos. Debido a su estandarización y su definición completa no ambigua, y aunque no sea un lenguaje de programación, UML se puede conectar de manera directa a lenguajes de programación como Java, C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniería directa (obtener el código fuente partiendo de los modelos) pero además es posible reconstruir un modelo en UML partiendo de la implementación, o sea, la ingeniería inversa. UML proporciona la capacidad de modelar actividades de planificación de proyectos y de sus versiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles así como la propia arquitectura. Mediante estas capacidades se obtiene una documentación que es válida durante todo el ciclo de vida de un proyecto. El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter de completitud y no-ambigüedad que antes comentábamos. Los bloques de construcción se dividen en tres partes: Elementos, que son las abstracciones de primer nivel. Relaciones, que unen a los elementos entre sí.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Diagramas, que son agrupaciones de elementos. Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos: Elementos estructurales. Elementos de comportamiento. Elementos de agrupación Elementos de anotación. Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relaciones de asociación, relaciones de generalización y relaciones de realización. Se utilizan diferentes diagramas dependiendo de qué, nos interese representar en cada momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle..., por esta razón UML soporta un gran número de diagramas diferentes aunque, en la práctica, sólo se utilicen un pequeño número de combinaciones. UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones entre objetos para poder obtener modelos bien formados, estas son reglas semánticas que afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros, a la integridad de unos elementos con otros y a la ejecución, o sea la vista dinámica del sistema. UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas reglas para que en el trasfondo de la adaptación no se pierda la semántica propia de UML. Dentro de estos mecanismos están las especificaciones, que proporcionan la explicación textual de la sintaxis y semántica de los bloques de construcción. Otro mecanismo es el de los adornos que sirven para conferir a los modelos de más semántica, los adornos son elementos secundarios ya que proporcionan más nivel de detalle, que quizá en un primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos se dividan al menos en un par de formas diferentes para facilitar la comprensión desde distintos puntos de vista, en primer lugar tenemos la división entre clase y objeto (clase es una abstracción y objeto es una manifestación de esa abstracción), en segundo lugar tenemos la división interfaz / implementación donde la interfaz presenta un contrato (algo que se va a cumplir de una determinada manera) mientras que la implementación es la manera en que se cumple dicho contrato.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Por último, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados, para extender las propiedades un bloque, y las restricciones, para extender la semántica. De esta manera UML es un lenguaje estándar “abierto-cerrado” siendo posible extender el lenguaje de manera controlada.

Elementos Estructurales Los elementos estructurales en UML, es su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales. Clases Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.

Clase

Describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces.

Interfaz: Una interfaz es una colección de operaciones que especifican un servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su implementación. Se representa con un círculo, y rara vez se encuentra aislada sino que más bien conectada a la clase o componente que realiza.

Interfaz

Agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un círculo para representar las interfaces, aunque lo más normal es emplear la clase con el nombre en cursiva.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Colaboración: Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Las colaboraciones tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las colaboraciones representan la implementación de patrones que forman un sistema. Se representa mediante una elipse con borde discontinuo.

Colaboración

Define una interacción entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.

Casos de Uso: Un caso de uso es la descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboración.

Caso de uso

Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de interés. Se emplea para estructurar los aspectos de comportamiento de un modelo.

Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución por lo y tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Se representa igual que una clase, pero con líneas más gruesas

Clase activa

Se trata de una clase, en la que existen procesos o hilos de ejecución concurrentes con otros elementos. Las líneas del contorno son más gruesas que en la clase “normal”

Componentes: Un componente es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Un Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones. Componente

Parte física y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos.

Nodos: Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso Computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Nodo

Elemento físico que existe en tiempo de ejecución y representa un recurso computacional con capacidad de procesar.

Diagramas de Casos de Usos: Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Casos de Uso

Muestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organización del sistema.

Diagramas de Secuencia y de Colaboración: Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin pérdida de información, lo mismo ocurren en sentido opuesto.

Secuencia

Colaboración

Son diagramas de interacción, muestran un conjunto de objetos y sus relaciones, así como los mensajes que se intercambian entre ellos. Cubren la vista dinámica del sistema. El diagrama de secuencia resalta la ordenación temporal de los mensajes, mientras que el de colaboración resalta la organización estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboración de la figura de la izquierda, se puede ver que los elementos gráficos no son cajas rectangulares, como cabría esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol específico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un Actor, una Interfaz, un Control (modela un comportamiento) y una Instancia (modela un objeto de dato).

Diagramas de Estados: Muestran una máquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.

Estados

Muestra una máquina de estados, con sus estados, transiciones, eventos y actividades. Cubren la vista dinámica de un sistema. Modelan comportamientos reactivos en base a eventos.

Diagramas de Actividades: Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Actividades

Tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema.

Diagramas de Componentes: Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones Diagramas de Despliegue: Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más componentes.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Diagrama de Despliegue Veamos un ejemplo de UML con casos de uso Primero que todo debemos describir el problema sobre el cual vamos a aplicar el Modelo UML Para mover una caja, el jugador debe colocarse al lado y empujarla. Si la casilla hacia la que está empujando la caja está libre la caja se moverá. Si el jugador se queda bloqueado, es decir, no puede terminar el nivel, puede reiniciar el nivel perdiendo una vida. Cuando el jugador pierde todas sus vidas la partida termina. También debemos mirar que solicitudes le hacen al sistema para que podamos dar comienzo a la representación del Modelo UML. El sistema debe permitir comenzar una nueva partida y terminarla. El sistema debe permitir mover al jugador y a las cajas y reiniciar el nivel cuando el usuario lo solicite. El sistema deberá almacenar varios niveles y cambiar de nivel cuando el usuario complete el nivel actual A continuación miremos los casos de uso resultantes de acuerdo a la descripción del problema y los requerimientos que nos hace el usuario dueño del sistema:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

2.4.

Reglas del Negocio

Esta capa es la encargada de procesar y validar las reglas del negocio, actúa como un servidor para la capa de presentación y traslada las solicitudes de esta a la capa de datos actuando como cliente de la misma. Así mismo también funciona de la misma manera de la forma inversa. Los servicios de negocios son el “puente” entre un usuario y los servicios de datos. Responden a peticiones del usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo. Cumplen con esto aplicando procedimientos formales y reglas de negocio a los datos relevantes. Cuando los datos necesarios residen en un servidor de bases de datos, garantizan los servicios de datos indispensables para cumplir con la tarea de negocios o aplicar su regla. Esto aísla al usuario de la interacción directa con la base de datos. Una tarea de negocios es una operación definida por los requerimientos de la aplicación, como introducir una orden de compra o imprimir una lista de clientes. Las reglas de negocio (business rules) son políticas que controlan el flujo de las tareas. Como las reglas de negocio tienden a cambiar más frecuentemente que las tareas específicas de negocios a las que dan soporte, son candidatos ideales para encapsularlas en componentes que están lógicamente separados de la lógica de la aplicación en sí. Para ayudar a los desarrolladores a construir la lógica de negocio basado en componentes Windows DNA incluye un conjunto muy poderoso de servicios que se encargan de la comunicación Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

en una aplicación de tres capas. Estos servicios están altamente integrados unos con otros, bajo un sistema operativo, y expuestos de forma única a través de COM. El nivel de servicios de negocios es responsable de: Recibir la entrada del nivel de presentación Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los que la aplicación fue diseñada a automatizar (por ejemplo, la preparación de impuestos por ingresos, el procesamiento de órdenes y así sucesivamente). Enviar el resultado procesado al nivel de presentación. Algunos de los servicios DNA para la capa de negocios son los siguientes: Servicios Web a través de Microsoft Internet Information Server (IIS) Transacciones y Servicios de Componentes, Microsoft Transaction Server (MTS) Servicios Asíncronos, Microsoft Message Queue Server (MSMQ). Server-side Scripting, via Active Server Pages (ASP).

2.5. Principios de desarrollo de aplicaciones Web Desarrollar un sitio, un proyecto web, no es tan complicado como pareciera. Solo hace falta tener las ideas claras para hacerlo. A través de mi experiencia práctica, he aprendido algunas ideas desde dónde comenzar para desarrollar un sitio o portal web. Los llamo Principios para desarrollar un proyecto para Internet. Estos son los Principios: El proyecto debe ser orientado al usuario, no al desarrollador. El proyecto debe tener contenido ético. El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseño gráfico como en usabilidad y contenidos. El proyecto debe ser estético y atractivo visualmente. El proyecto debe transmitir emociones, según su naturaleza. El proyecto debe tener herramientas y contenido más actuales disponibles y estos deben mantenerse constantemente actualizadas. El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el mensaje y la fuente, completando el ciclo de la comunicación. El proyecto debe tener enfoque global, es decir, que no debe ser un fin en sí mismo, sino un medio para completar otros objetivos mayores, a la vez que mantiene consistencia con estos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El proyecto debe ser orientado al usuario, no al desarrollador. Es demasiado fácil caer en la trampa de empezar a desarrollar un proyecto teniendo como prioridad tus propios criterios, o los del desarrollador. Con el tiempo te darás cuenta de que mientras más apegado se esté a los criterios del desarrollador, más complejo le será acceder al usuario a la información, proyecto, servicio, etc. Son innumerables los casos de esto, los más típicos son los portales de la Administración pública, universidades, etc., que hacen que el usuario comience tirándose de los pelos, impaciente, hasta que al final o bien se da por vencido, o bien termina siendo un experto en informática solo por usar una página web. Por el contrario, Organizaciones o portales web que manejan una enorme cantidad de información han sido muy exitosos, donde en un abrir y cerrar de ojos el usuario aprende a manejarlos muy bien, acceder y regresar una y otra vez, dado que los desarrolladores lo ponen muy fácil. ¿Cómo saber si tu página o proyecto web está orientado al usuario? Muy fácil: pregúntaselo a tus usuarios. El proyecto debe tener contenido ético. Todo proyecto serio, y que se precie de serlo, debe cuidar que sus contenidos sean éticos. También innumerables son los casos que puedo poner como ejemplos: contenidos que te ofrecen hacerte millonario/a de la noche a la mañana, te prometen la luna, las estrellas, vida eterna, etc,. Asimismo, una amonestación a quienes usan la estrategia del correo electrónico no solicitado (llámese SPAM), ventanas emergentes no solicitadas (pop ups), banners parpadeantes sin cesar (aarrgghhhhh!! mis ojos!!!) etc… ni hablar de los sitios puramente fraudulentos. No. No es necesario caer en esas prácticas para atraer lectores o usuarios. Así vendas lotería, coches, dietas, o información que puede dar beneficios al lector, tu producto, información o servicio puede ser difundido desarrollando un proyecto éticamente, sin forzar, sin mentir. Ofreciendo al usuario las ventajas y desventajas de tu información, haciendo comparaciones honestas y, sobre todo, permitiéndole tomar una decisión. El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseño gráfico como en usabilidad y contenidos. Un proyecto puede ser tan complejo como quieras y al mismo tiempo ser simple de usar y leer. Sin tanta parafernalia, sin tanto gráfico. Echa un vistazo a Google.com y verás lo simple que es esa página, que hoy por hoy es la más visitada de todo el mundo. En definitiva, debes ofrecer a tus lectores/usuarios la información que necesitan sin hacerlos dar vueltas por todos lados para hallarla, o se irán sin pensarlo dos veces. Existen varias maneras de lograr hacer un proyecto muy

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

accesible, como por ejemplo mapas, buscadores internos, formas de redactar simples y al grano, etc. Simplicidad es la palabra clave. El proyecto debe ser estético y atractivo visualmente. Antes he dicho que la usabilidad, orientada al usuario, es uno de los aspectos más importantes al momento de desarrollar un proyecto para Internet. Pues bien, podría decir que la estética también juega un papel importante, dicha estética, que personalmente prefiero minimalista, creo es la clave en la credibilidad de lo que escribimos, también logra que nuestros usuarios/as se sientan cómodos utilizando lo que ponemos a su disposición. Concretamente hablando de desarrollo de sitios web, por ejemplo, he visto cómo contenidos interesantes -algunos publicados por catedráticos o expertos en alguna materia- quedan sepultados bajo un diseño muy pobre, que ni siquiera había razón para ser tan deficiente respecto a estética. También por el contrario, he visto unos superdiseños gráficos, tantos, que sepultan el verdadero contenido. Por tanto te recomiendo atención a la estética, simplicidad y equilibrio en este aspecto. El proyecto debe transmitir emociones, según su naturaleza. No podemos evitarlo, somos humanos que tenemos emociones y, sea mediante la palabra al redactar o mediante la ayuda de gráficos, transmitir un mensaje que contenga alguna emoción, acorde a la naturaleza del mensaje, será muy efectivo, por muchísimo. La industria de la publicidad es experta en ello, pero también escritores que, mediante la palabra, nos transportan a otros mundos. El proyecto debe tener herramientas y contenido actuales disponibles y estos deben mantenerse constantemente actualizadas. Así es. Cuando comencé a desarrollar proyectos para Internet, a diseñar mis propias páginas, Internet ya llevaba varios años de andaduría, y en esa época las páginas se hacían una por una, eran estáticas y sus contenidos lentamente actualizados. Hoy, hasta se puede ver televisión, vídeos, escuchar radio, música y mil cosas más. En estos tiempos se empieza a poner de moda la llamada Web 2.0 (como las redes sociales), donde los usuarios -y no el desarrollador- son quienes ‘tienen la última palabra’ en lo que hacen por Internet, etc. Con tanto cambio, ¿dónde quedarán tus contenidos o tu proyectos si nunca actualizas?… El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el mensaje y la fuente, completando el ciclo de la comunicación. La comunicación, para que sea completa, debe ser un ciclo entre la fuente, el mensaje y el receptor que interactúan simultáneamente. ¿Cómo te sentirías hablando con alguien que no te Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

contesta, ni siquiera con un gesto? En Internet es prácticamente igual. Por tanto, es importante que tú, como desarrollador, permitas que tus usuarios puedan interactuar contigo de alguna manera, enviar feedback, sea mediante formularios, mensajes electrónicos, foros, etc, etc. Así también tú podrás ir adquiriendo nuevas ideas que te podrían servir para implementar… ¿comprendes? El proyecto debe tener enfoque global, es decir, que no debe ser un fin en sí mismo, sino un medio para completar otros objetivos mayores, a la vez que mantiene consistencia con estos. Siempre que desarrolles un proyecto para Internet, ten mucho cuidado de que el proyecto no sea el fin, sino solo una herramienta más para alcanzar algún objetivo. De otra manera, puede que termines gastando tiempo y recursos en otra cosa que no sea tu verdadero objetivo. Recuerda, el proyecto es solo una herramienta o medio más. Mantén la visión equilibrada y no descuides otras herramientas o medios que también podrían serte útiles.

2.6. La Arquitectura en el Proceso Unificado de Desarrollo Etapas, hitos, iteraciones y ciclos Identifica los diferentes procesos que deben llevar a cabo dentro de las fases de un proceso unificado de desarrollo de software. Iniciación. Elaboración. Construcción. Transición.

El proceso unificado de desarrollo de software Es un proceso orientado a objetos, es un proceso guiado por casos de uso, centrado en la arquitectura y Con un ciclo de vida iterativo e incremental Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El proceso unificado de desarrollo de software usa UML como podemos visualizar en la siguiente figura El proceso unificado de desarrollo de software está organizado de la siguiente manera: a) Guiado por casos de uso. b) Centrado en la arquitectura. c) Ciclo de vida iterativo e incremental. a) Guiado por casos de uso: Los sistemas se crean para dar servicio a los usuarios Qué REQUISITOS se necesitan Un CASO de USO es una pieza de FUNCIONALIDAD de un sistema que le proporciona a algún USUARIO un RESULTADO o VALOR. Todos juntos constituyen el modelo de casos de uso 



Funcionabilidad completa Para todos los usuarios

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Veamos a continuación un ejemplo de un modelo de casos de uso: En qué beneficia a un desarrollo guiado por casos de uso? Los casos de uso: capturan requisitos, se especifican (analizan), se diseñan, se implementan y se prueban En siguiente figura podemos apreciar un ejemplo de un desarrollo por casos de uso:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

a) Centrado en la arquitectura: La arquitectura de un sistema software es un extracto de los modelos del sistema es decir una vista de cada módulo. Que da una idea de la forma que tiene el sistema completo

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

b) Ciclo de vida iterativo e incremental En el iterativo se repiten varios miniproyectos en el Incremental cada miniproyecto amplía el producto, en el ciclo de vida del proceso unificado podemos anotar que Un ciclo de vida se repite a lo largo del tiempo Tras cada ciclo de vida  versión nueva del producto Un ciclo de vida se divide en fases Cada fase se divide en iteraciones En cada iteración se realizan flujos de trabajo Miremos gráficamente estos componentes

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Fases dentro del ciclo de vida del proceso unificado Iniciación: Describir producto final / análisis del negocio Identificar riesgos más importantes Establecer planificación inicial del proyecto Decidir si se continúa Elaboración: Establecer Plan Y Arquitectura Estable Construcción: desarrollar el producto Transición: proporcionar sistema a usuarios Los flujos de trabajo, actividades, roles y artefactos Dentro de los flujos de trabajo deben involucrarse aspectos referidos a conceptos que determinan de alguna manera conceptos de Modelado del negocio, Análisis de requerimientos, Análisis y diseño, Implementación, Pruebas y Despliegue. Flujos de trabajo Captura de requisitos implica: identificar requisitos del sistema, construir un modelo del mismo (de casos de uso y de dominio o negocio Análisis que implica: Especificar requisitos y construir modelo del análisis Diseño para encontrar la forma del sistema (solución) y construir modelo del diseño Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Implementación donde se debe codificar el diseño (solución) y construir modelo de implementación Pruebas para verificar la implementación y construir modelo de pruebas Fase de Iniciación: Establecer la planificación del proyecto • ¿Qué va a hacer el sistema para cada uno de sus usuarios principales? – Un MCU simplificado con los CU más críticos • ¿Cómo sería la arquitectura para un sistema como ese? – Borrador con los subsistemas principales • ¿Cuál es el plan y cuánto va a costar desarrollar el producto? – Identificar los riesgos principales y priorizarlos, planificar elaboración y presupuesto aproximado Fase de Elaboración: Establecer un plan para el proyecto y una arquitectura correcta Especificar en detalle los CU + críticos Diseñar la arquitectura Mediante vistas de todos los modelos del SI Vista arquitectónica de MCU, M. Análisis, M. Diseño, M. Implementación (con los componentes que demuestran que la arquitectura es ejecutable) y M. Distribución. Al final de esta fase se debe poder planificar las actividades y estimar los recursos para poder completar el proyecto. ¿Son los CU, arquitectura y planes lo suficientemente estables y los riesgos bajo control suficiente para firmar un contrato para terminar el trabajo de desarrollo? Fase de Construcción: Desarrollar el sistema, Se construye el producto. En esta fase: La arquitectura se completa para construir un sistema bien cimentado La visión evoluciona hasta convertirse en un producto preparado para los usuarios Es donde se gastan la mayoría de los recursos La arquitectura del sistema es estable. Sin embargo, se pueden realizar cambios mínimos a la misma. ¿El producto se ajusta suficientemente a las necesidades de algunos usuarios como para enviárselo ya? Fase de transición: Proporcionar el sistema a los usuarios finales, El producto se encuentra en fase beta Un grupo reducido de usuarios experimentados prueba el producto e informa de los defectos y deficiencias y sugieren mejoras. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Los desarrolladores corrigen las deficiencias e incorporan algunas de las mejoras propuestas en una versión para un grupo de usuarios mayor. En esta fase se encuentran actividades como la venta, formación de los usuarios, ofrecimiento de ayuda en línea y corrección de defectos descubiertos tras la implantación. Los defectos: (1) los que justifican la aparición de una nueva versión del sistema, (2) los que se pueden dejar para la siguiente versión que se cree. Ejercicio de autoevaluación Obtener el modelo conceptual de un sistema que gestiona las matrículas de los estudiantes de la Universidad Remington. Una persona viene caracterizada por su ID, nombre, dirección y estado civil, y ésta puede convertirse en estudiante al darse de alta como tal en la universidad. Como estudiante podrá matricularse de las asignaturas que se imparten en la universidad, que tendrán un código, un nombre, un profesor responsable y un curso asignado. Una vez matriculado, el estudiante podrá recibir una beca, y en su nueva condición de becario tendrá asignado un nuevo código y se conocerá el importe de la misma; al finalizar el curso, la condición de becario acabará. Una vez el estudiante se matrícula, tanto si recibe beca como si no, deberá examinarse de las asignaturas en las que se encuentra matriculado hasta que finalice el curso y vuelva a matricularse de nuevo, o bien deje la universidad y con ello deje de ser estudiante. Además, convendrá tener una serie de aplicaciones tales como dar de alta a nuevas personas y asignaturas, llevar a cabo la matriculación de estudiantes en asignaturas, registrar las notas obtenidas por los estudiantes al examinarse de cualquier asignatura en la que están matriculados y una serie de listados tales como los alumnos matriculados en una asignatura, las asignaturas en las que se ha matriculado un alumno y el listado de notas por asignatura (actas).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

3. LA ARQUITECTURA DE SOFTWARE. OBJETIVO GENERAL Presentar de manera práctica las diferentes metodologías y buenas prácticas para documentación y evaluación de arquitecturas de software OBJETIVOS ESPECÍFICOS Identificar y comprender los diversos aspectos del software utilizando distintos modelos o vistas. Describir y diseñar una arquitectura basados en la estructura sintáctica y semántica del ADL. Estructurar todo el análisis del proyecto por medio de estructuras que nos provee UML 2.0. Crear Arquitecturas de servicios web por medio SOA para garantizar una comunicación rápida y transparente entre aplicaciones. Desarrollar implementaciones sobre computación móvil aplicando arquitecturas de alta escalabilidad.

3.1. Relación de conceptos

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

3.2. Prueba Inicial Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su grado de asimilación a) b) c) d) e)

¿Qué caracteriza el diseño en la arquitectura del software? ¿Cuáles modelos de la arquitectura puedes mencionar? Indique al menos una característica de los estilos arquitectónicos ¿Qué es ADL y que componentes de éste puedes indicar? ¿Cuáles son las cualidades del enfoque arquitectónico a tener en cuenta para dicho proceso de modelamiento? f) Indique algunos componentes del modelado UML 2.0

3.3. Modelos de arquitectura de software. Características de un diseño de arquitectura Propiedades estructurales: Define los componentes de un sistema y la manera en que dichos componentes se agrupan en paquetes e interaccionan entres ellos. Propiedades extra-funcionales: Debe indicar cómo el diseño arquitectónico alcanza los requisitos no funcionales como: rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad, etc. Familias de sistemas relacionados: Debe permitir reconocer su estructura en los patrones repetitivos que se encuentran de manera habitual en el diseño de sistemas similares. Debe ser capaz de reutilizar bloques de construcción arquitecturales. Modelos: Estructurales: Representan la arquitectura como una colección organizada de componentes. De Frameworks: Identifican patrones de diseño arquitectónico repetibles que se encuentran en aplicaciones similares. Dinámicos: Muestran los aspectos del comportamiento dinámico de la arquitectura, indicando como la estructura o la configuración del sistema pueden cambiar en función de eventos externos. De procesos: Se enfocan en el diseño de los procesos del negocio que el sistema debe soportar.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Funcionales: Pueden utilizarse para representar la jerarquía funcional de un sistema. Para tener un concepto más claro sobre arquitectura de software podemos tener en cuenta los siguientes aspectos: Facilita la comunicación entre los diferentes participantes en el desarrollo. Resalta las decisiones de diseño que pueden tener un gran impacto en todo el proceso de desarrollo posterior. Aporta una visión de cómo se estructura el sistema y cómo sus componentes trabajan juntos. Miremos ahora los estilos arquitectónicos: Modelos de descomposición de sistemas. Modelo de almacén central. Cliente/servidor. Modelo de máquinas abstractas. Modelo de control Centralizado. Modelo de eventos. Modelos de descomposición modular Modelo de flujo de datos. Modelo orientado a objetos. Modelo de dominio específico Arquitectura centrada en los datos. Arquitectura centrada en los flujos de datos. Arquitectura llamada y respuesta (call and return) Arquitectura orientada a objetos. Arquitectura en capas. Un problema puede satisfacerse mediante diferentes estructuras a las que se llegarán posiblemente utilizando técnicas distintas, A veces la frontera entre dos estilos no está muy clara, lo que provoca que haya mezcla entre ellos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Arquitectura centrada en los datos: Como parte central de esta arquitectura aparece un almacén de datos, el cual es accedido de manera frecuente por otros componentes que actualizan, añaden, borran o modifican dichos almacenes. Repositorio pasivo: El cliente software accede a los datos independientemente de cualquier cambio en los datos o a las acciones de otros clientes software. Repositorio activo (pizarra): El repositorio envía información a los clientes cuando los datos de su interés cambian, siendo por tanto un ente activo. Arquitectura centradas en datos proporcionan integridad, es decir, los componentes existentes pueden cambiar y pueden añadirse nuevos componentes a la arquitectura sin que afecte a otros clientes. A su vez los datos pueden ser pasados entre cliente a través de mecanismos que coordinen dicha transferencia de información. Miremos a continuación una figura que nos visualiza de manera más general lo que acabamos de expresar. Componentes cliente ejecutan procesos independientemente

Arquitectura centrada en los flujos de datos: Se basa en el patrón “pipe and filter” (tuberías y filtros). Este consta de un conjunto de componentes denominados “filtros” conectados entre sí por “tuberías” que transmiten datos desde un componente al siguiente. Cada filtro trabaja de manera independiente de los componentes que se encuentran situados antes o después de ella. Se diseñan de tal modo que esperan un conjunto de datos en un determinado formato y obtiene como resultado otros datos de salida en un formato específico.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Si el flujo degenera en una única línea de transformación, se denomina secuencial batch. Veamos una figura referente a esta arquitectura

Arquitectura llamada y respuesta (call and return): Permite a los diseñadores software conseguir estructuras de programas relativamente fáciles de modificar y escalar. Podemos encontrar diferentes estilos de este tipo: Programa principal/subprograma: Descompone las funciones en una jerarquía de control donde el programa principal invoca a los otros programas subordinados, los cuales pueden a su vez invocar otros. Llamada de procedimiento remoto: Los componentes de la arquitectura son distribuidos entre diferentes ordenadores de la red. Veamos a continuación una figura de esta arquitectura:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Arquitectura orientada a objetos: Los componentes del sistema encapsulan datos y operaciones que deben utilizarse para manipular dichos datos. La comunicación y coordinación entre componentes se realiza mediante envío de mensajes. En esencia es un sistema parecido al anterior, donde se enfatiza el empaquetamiento entre datos y operaciones que permiten manipular y acceder a dichos datos. Arquitectura en capas: Se definen un conjunto de niveles o capas, cada nivel interno que se atraviesa se aproxima más al nivel del conjunto de instrucciones máquina.

Sistemas en capas puros: Cada capa sólo puede comunicarse con las vecinas. Esta solución aunque puede ser menos eficiente en algunos casos, facilita la portabilidad de los diseños. A continuación visualizamos una figura: Una vez que el arquitecto de software, tras conocer el requerimiento, se decide a delinear su estrategia y a articular los patrones que se le ofrecen hoy en profusión, se supone que debería expresar las características de su sistema, o en otras palabras, modelarlo, aplicando una convención gráfica o algún lenguaje avanzado de alto nivel de abstracción. A esta altura del desarrollo de la arquitectura de software, podría pensarse que hay abundancia de herramientas de modelado que facilitan la especificación de desarrollos basados en principios arquitectónicos, que dichas herramientas han sido consensuadas y estandarizadas hace tiempo y que son de propósito general, adaptables a soluciones de cualquier mercado vertical y a cualquier Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

estilo arquitectónico. La creencia generalizada sostendría que modelar arquitectónicamente un sistema se asemeja al trabajo de articular un modelo en ambientes ricos en prestaciones gráficas, como es el caso del modelado de tipo CASE o UML, y que el arquitecto puede analizar visualmente el sistema sin sufrir el aprendizaje de una sintaxis especializada. También podría pensarse que los instrumentos incluyen la posibilidad de diseñar modelos correspondientes a proyectos basados en tecnología de internet, Web services o soluciones de integración de plataformas heterogéneas, y que, una vez trazado el modelo, el siguiente paso en el ciclo de vida de la solución se produzca con naturalidad y esté servido por técnicas bien definidas. Como se verá en este documento, la situación es otra, dista de ser clara y es harto más compleja. Entre las comunidades consagradas al modelado OO y la que patrocina o frecuenta los ADLS (así como entre las que se inclinan por el concepto de estilos arquitectónicos y las que se trabajan en función de patrones) existen relaciones complejas que algunas veces son de complementariedad y otras de antagonismo. Aunque algunos arquitectos influyentes, como Jorgen Thelin, alegan que el período de gloria de la OOP podría estar acercándose a su fin, el hecho concreto es que el modelado orientado a objetos de sistemas basados en componentes posee cierto número de rasgos muy convenientes a la hora de diseñar o al menos describir un sistema. En primer lugar, las notaciones de objeto resultan familiares a un gran número de ingenieros de software.

TEMA 2 Criterios de definición de un ADL Los ADLs se remontan a los lenguajes de interconexión de módulos (MIL) de la década de 1970, pero se han comenzado a desarrollar con su denominación actual a partir de 1992 o 1993, poco después de fundada la propia arquitectura de software como especialidad profesional. La definición más simple es la de Tracz [Wolf97] que define un ADL como una entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y restricciones (constraints). Una de las definiciones más tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe modelar o soportar los siguientes conceptos: Componentes Conexiones Composición jerárquica, en la que un componente puede contener una sub-arquitectura Completa Paradigmas de computación, es decir, semánticas, restricciones y propiedades no funcionales Paradigmas de comunicación Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Modelos formales subyacentes Soporte de herramientas para modelado, análisis, evaluación y verificación Composición automática de código aplicativo Basándose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como requerimientos: Abstracción de componentes Abstracción de comunicación Integridad de comunicación (sólo los componentes que están conectados pueden comunicarse) Capacidad de modelar arquitecturas dinámicas Composición jerárquica Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas) Tomando como parámetro de referencia a UniCon, Shaw y otros [SDK+95] alegan que un ADL debe exhibir: Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones Capacidad de modelar conectores con protocolos, aserción de propiedades e implementaciones Abstracción y encapsulamiento Tipos y verificación de tipos Capacidad para integrar herramientas de análisis Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados explícitamente como entidades de primera clase (lo que dejaría al margen de la lista a dos de ellos al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de composición, abstracción, reusabilidad, configuración, heterogeneidad y análisis, lo que excluiría a todos los lenguajes convencionales de programación y a los MIL. La especificación más completa y sutil (en tanto que se presenta como provisional, lo que es propio de un campo que recién se está definiendo) es la de Medvidovic [Med96]: Componentes Interfaz Tipos Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Semántica Restricciones (constraints) Evolución Propiedades no funcionales Conectores Interfaz Tipos Semántica Restricciones Evolución Propiedades no funcionales Configuraciones arquitectónicas Comprensibilidad Composicionalidad Heterogeneidad Restricciones Refinamiento y trazabilidad Escalabilidad Evolución Dinamismo Propiedades no funcionales Soporte de herramientas Especificación activa Múltiples vistas Análisis Refinamiento Generación de código Dinamismo Nótese, en todo caso, que no se trata tanto de aspectos definitorios del concepto de ADL, sino de criterios para la evaluación de los ADLs existentes, o sea de un marco de referencia para la clasificación y comparación de los ADLs.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

En base a las propuestas señaladas, definiremos a continuación los elementos constitutivos primarios que, más allá de la diversidad existente, son comunes a la ontología de todos los ADLs y habrán de ser orientadores de su tratamiento en este estudio. Componentes: Representan los elementos computacionales primarios de un sistema. Intuitivamente, corresponden a las cajas de las descripciones de caja-y-línea de las arquitecturas de software. Ejemplos típicos serían clientes, servidores, filtros, objetos, pizarras y bases de datos. En la mayoría de los ADLs los componentes pueden exponer varias interfaces, las cuales definen puntos de interacción entre un componente y su entorno. Conectores. Representan interacciones entre componentes. Corresponden a las líneas de las descripciones de caja-y-línea. Ejemplos típicos podrían ser tuberías (pipes), llamadas a procedimientos, broadcast de eventos, protocolos cliente-servidor, o conexiones entre una aplicación y un servidor de base de datos. Los conectores también tienen una especie de interfaz que define los roles entre los componentes participantes en la interacción. Configuraciones o sistemas. Se constituyen como grafos de componentes y conectores. En los ADLs más avanzados la topología del sistema se define independientemente de los componentes y conectores que lo conforman. Los sistemas también pueden ser jerárquicos: componentes y conectores pueden subsumir la representación de lo que en realidad son complejos subsistemas. Propiedades. Representan información semántica sobre un sistema más allá de su estructura. Distintos ADLs ponen énfasis en diferentes clases de propiedades, pero todos tienen alguna forma de definir propiedades no funcionales, o pueden admitir herramientas complementarias para analizarlas y determinar, por ejemplo, el throughput y la latencia probables, o cuestiones de seguridad, escalabilidad, dependencia de bibliotecas o servicios específicos, configuraciones mínimas de hardware y tolerancia a fallas. Restricciones. Representan condiciones de diseño que deben acatarse incluso en el caso que el sistema evolucione en el tiempo. Restricciones típicas serían restricciones en los valores posibles de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de clientes que se puede conectar simultáneamente a un servicio. Estilos. Representan familias de sistemas, un vocabulario de tipos de elementos de diseño y de reglas para componerlos. Ejemplos clásicos serían las arquitecturas de flujo de datos basados en grafos de tuberías (pipes) y filtros, las arquitecturas de pizarras basadas en un espacio de datos compartido, o los sistemas en capas. Algunos estilos prescriben un framework, un estándar de integración de componentes, patrones arquitectónicos o como se lo quiera llamar. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Evolución. Los ADLs deberían soportar procesos de evolución permitiendo derivar subtipos a partir de los componentes e implementando refinamiento de sus rasgos. Sólo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de diseño arquitectónico sino los de programación. Propiedades no funcionales. La especificación de estas propiedades es necesaria para simular la conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear implementaciones sobre procesadores determinados, etcétera.

3.4.

Enfoques arquitectónicos de software

Antes de enfrentarnos a tomar la decisión de una arquitectura creo que debemos tener en cuenta cualidades como: Performance, Availability, Security, Modifiability También se debe analizar muy bien atributos como: El sistema debe ser robusto El sistema debe ser modificable El sistema debe ser seguro El sistema debe tener un desempeño aceptable A continuación vamos a centrarnos en 2 enfoques arquitectónicos SAAM y ATAM SAAM - Software Architecture Analysis Method Propósito, Contexto y escenarios, Roles, Método de análisis, Fortalezas, Debilidades Propósito: Basado en escenarios, Foco modificabilidad, Evaluar una arquitectura o evaluar y comparar varias Contexto y escenarios: Atributos de calidad complejos y amorfos para evaluarse simplemente Dependientes del contexto: Escenario. Interacción entre un interesado y el sistema Un escenario directo es el que puede satisfacerse sin la necesidad de modificaciones en la arquitectura.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Un escenario indirecto es aquel que requiere modificaciones en la arquitectura para poder satisfacerse. Interacción de escenarios n escenarios. Dos o más escenarios indirectos requieren cambios sobre el mismo componente Roles: Interesados externos externos (Organización cliente, usuarios finales, administradores del sistema, etc.) Interesados internos internos(Arquitectos de Software, analistas de requerimientos) Equipo SAAM SAAM(Líder, expertos en el dominio de la aplicación, expertos externos en arquitectura y secretario) Método de análisis: Paso1: Desarrollo de escenarios. Paso2: Descripción de la Arquitectura. Paso3: Clasificación de escenarios. Paso4: Evaluación de escenarios. Paso5: Interacción de escenarios. Paso6: Evaluación general. 1. Desarrollo de escenarios: Un escenario es una breve descripción de usos anticipados o deseados del sistema. De igual forma, estos pueden incluir cambios a los que puede estar expuesto el sistema en el futuro. 2. Descripción de la arquitectura La arquitectura (o las candidatas) debe ser descrita haciendo uso de alguna notación arquitectónica que sea común a todas las partes involucradas en el análisis. Deben incluirse los componentes de datos y conexiones relevantes, así como la descripción del comportamiento general del sistema. El desarrollo de escenarios y la descripción de la arquitectura son usualmente llevados a cabo de forma intercalada, o a través de varias iteraciones. 3. Clasificación y asignación de prioridad de los escenarios La clasificación de los escenarios puede hacerse en dos clases: directos e indirectos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Los escenarios indirectos son de especial interés para SAAM, pues son los que permiten medir el grado en el que una arquitectura puede ajustarse a los cambios de evolución que son importantes para los involucrados en el desarrollo. 4. Evaluación individual de los escenarios indirectos Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula su costo. Una modificación sobre la arquitectura significa que debe introducirse un nuevo componente o conector, o que alguno de los existentes requiere cambios en su especificación. 5. Evaluación de la interacción entre escenarios Cuando dos o más escenarios indirectos proponen cambios sobre un mismo componente, se dice que interactúan sobre ese componente. Es necesario evaluar este hecho, puesto que la interacción de componentes semánticamente no relacionados revela que los componentes de la arquitectura efectúan funciones semánticamente distintas. De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel correcto de descomposición estructural. 6. Creación de la evaluación global Debe asignársele un peso a cada escenario, en términos de su importancia relativa al éxito del sistema. Esta asignación de peso suele hacerse con base en las metas del negocio que cada escenario soporta. En el caso de la evaluación de múltiples arquitecturas, la asignación de pesos puede ser utilizada para la determinación de una escala general. Fortalezas: Los interesados comprenden con facilidad las arquitecturas evaluadas. La documentación es mejorada. El esfuerzo y el costo de los cambios pueden ser estimados con anticipación. Analogía con el concepto de bajo acoplamiento y alta cohesión. Debilidades: La generación de escenarios está basada en la visión de los interesados. No provee una métrica clara sobre la calidad de la arquitectura Evaluada.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El equipo de evaluación confía en la experiencia de los arquitectos para proponer arquitecturas candidatas. Ahora miremos el enfoque con: ATAM Architecture Tradeoff Analysis Method Este método de evaluación indica cuan bien una arquitectura particular satisface las metas de calidad, y provee ideas de cómo esas metas de calidad interactúan entre ellas, como realizan concesiones mutuas (trade off) entre ellas. El método consta de 9 pasos divididos en cuatro grupos: 1. 2. 3. 4.

Presentación. Investigación y Análisis. Pruebas Informes

Grupo 1 Presentación: 1. Presentación del ATAM: El líder de evaluación describe el método a los participantes, trata de establecer las expectativas y responde las preguntas propuestas. 2. Presentación de las metas del negocio: Se realiza la descripción de las metas del negocio que motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectónico. 3. Presentación de la arquitectura: El arquitecto describe la arquitectura, enfocándose en cómo ésta cumple con los objetivos del negocio. Grupo 2 Investigación y Análisis: 4. Identificación de los enfoques arquitectónicos: Estos elementos son detectados, pero no analizados. 5. Generación del UtilityTree: Se priorizan los atributos de calidad que engloban la “utilidad” del sistema (desempeño, disponibilidad, seguridad, modificabilidad, usabilidad, etc.), especificados en forma de escenarios. Se anotan los estímulos y respuestas, así como se establece la prioridad entre ellos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

6. Análisis de los enfoques arquitectónicos: Con base en los resultados del establecimiento de prioridades del paso anterior, se analizan los elementos del paso 4. En este paso se identifican riesgos arquitectónicos, puntos de sensibilidad y puntos de balance. Grupo 3 Pruebas: 7. Lluvia de ideas y establecimiento de prioridad de escenarios: Con la colaboración de todos los involucrados, se complementa el conjunto de escenarios. 8. Análisis de los enfoques arquitectónicos: Este paso repite las actividades del paso 6, haciendo uso de los resultados del paso 7. Los escenarios son considerados como casos de prueba para confirmar el análisis realizado hasta el momento. Grupo 4 Reporte: 9. Presentación de los resultados: Basado en la información recolectada a lo largo de la evaluación del ATAM, se presentan los hallazgos a los participantes.

3.5. Modelado Arquitectónico en UML 2.0 DESCOMPOSICION DE UN SISTEMA

UML 2.0 usa interfaces basadas en componentes de desarrollo. Descompone jerárquicamente el sistema en partes más pequeñas. Permite la reutilización en diferentes contextos. AÑADIENDO EL COMPORTAMIENTO A LA MEZCLA

El comportamiento de una clase es delegada a sus partes y la clase misma debe contener su comportamiento. (Máquina de estado, d. actividad, d. interacción ) El contenedor describe el comportamiento de cómo crear las partes. ACTUANDO SOBRE LAS ACCIONES

Acciones: Es la unidad fundamental de la especificación de comportamiento que representa alguna transformación o proceso. Las acciones tienden a ser generales y se aplican a todos los tipos e comportamiento por instancia, máquinas de estado, interacciones o actividades. Actividad: Es la construcción básica del comportamiento, utilizados para modelar diagramas de actividad, que especifican el comportamiento usando un hibrido entre el control y un modelo del flujo de datos.) Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

ARQUITECTURA DE SISTEMAS EXISTENTES. Esto sucede cuando el sistema ha sido desarrollados in una descripción arquitectónica, o cuando el arquitecto tiene que abandonar el proyecto por algún motivo. Para poder tener una descripción arquitectónica en estos casos se hace uso de la ingeniería en reversa. Es necesario tener esta descripción arquitectónica, con el fin de hacer mantenimiento y desarrollo de nuevas versiones del mismo sistema. EVALUACIÓN ARQUITECTÓNICA

El propósito de esta evaluación es determinar la calidad de la descripción arquitectónica, y predecir la calidad del sistema que cuyas arquitecturas hacen parte de la descripción arquitectónica. UML 2.0 integra las actividades con sus acciones relacionadas. UML tuvo la iniciativa para especificar modelos ejecutables. Sustituye los modelos de acción anteriores con uno nuevo en el que se puede expresar acciones con semántica de precisión porcentual. El sistema permite la verificación en una etapa más temprana en el desarrollo del ciclo de vida y permite a las herramientas automatizar las pruebas mediante el uso de modelos UML. La notación no se ha especificado para las acciones de UML, diferentes vendedores de herramientas especifican su propia sintaxis. UML está destinado a muchas áreas diferentes, tiene una definición flexible de la semántica que debe reforzarse en algunas zonas o especificar con más detalle otras. Los programadores normalmente definen un conjunto de tipos de datos predefinidos para ser usados directamente en los modelos; El mecanismo de los perfiles de UML se destinan para acomodarse a cada caso. USOS DE LA DESCRIPCIÓN ARQUITECTÓNICA Análisis de alternativas arquitectónicas. Planeación para la migración de arquitecturas. Comunicación entre compradores y desarrolladores. Comunicación entre compradores y desarrolladores.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Comunicación entre las organizaciones involucradas en el desarrollo, la producción, presentación, operación, y mantenimiento del sistema. Documentación para el desarrollo y el mantenimiento. Soporte operacional y de infraestructura. Soporte para planeación y presupuesto. Preparación de documentos de adquisición. Revisión, análisis y evaluación del sistema a través del ciclo de vida. Especificación para un grupo de sistemas que comparten las mismas características. PRÁCTICAS DE DESCRIPCIÓN ARQUITECTÓNICA Documentación arquitectónica.Ladescripcióndeunaarquitecturadebecontenerlossiguientesítems: Fecha y estado de la cuestión. Organización de la cuestión. Historial de cambios. Resumen. Alcance. Contexto. Glosario. Referencias. Usuarios del sistema. Compradores del sistema. Desarrolladores del sistema. Encargados del mantenimiento del sistema. Vistas arquitectónicas. Es importante tener en cuenta que cada una de las vistas generadas, debe estar relacionada con uno de los puntos de vistas mencionados anteriormente. Estas vistas deben contener: Un identificador y una información introductoria. Representación del sistema. Información de la configuración. Consistencia entre las vistas arquitectónicas. Justificación arquitectónica. Conclusiones:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

SOA (Services Oriented Architecture) Para empezar este tutorial, me gustaría comenzar con una serie de afirmaciones que creo que nadie me podría negar: Los procesos de negocio de las empresas son cada día más complejos. La evolución del mercado y la fuerte competencia exige a las empresas una respuesta más ágil para aprovechar la curva de oportunidad, a la hora de ofrecer distintos servicios a los clientes. Esta fuerte competencia implica que las empresas tengan que ofrecer servicios de mayor valor añadido apoyándose en acuerdos con otras empresas (por ejemplo, una línea aérea quiere ofrecer a través de su vez, no sólo reservar billetes en un vuelo, sino ofrecer una solución completa en base a itinerarios, hoteles, coches de alquiler, etc...) Sin embargo, gran parte de los problemas con los que se encuentran las empresas para evolucionar acorde al mercado es la infraestructura tecnológica, o dicho de otro modo, la arquitectura A lo largo de los años, en nuestras empresas se han ido acumulando una gran cantidad de aplicaciones distintas que se fueron desarrollando para tratar de resolver las distintas necesidades que iban surgiendo: ERPs, CRMs, Bases de datos, Mainframes, Sistemas CICS junto con aplicaciones WEB / J2EE, .NET, etc... . Pero estas aplicaciones no se crearon con la idea de interactuar entre ellas, sino como herramientas para resolver un problema en un momento dado. En definitiva, el paisaje que nos encontramos es parecido a un archipiélago de aplicaciones.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

La realidad del mercado nos ha llevado a las siguientes aseveraciones: Nuestras aplicaciones internas están de alguna manera condenadas a entenderse, si queremos dar una respuesta ágil, a las necesidades de negocio que surgen. Las aplicaciones de nuestra empresa están condenadas a entenderse de alguna manera ágil con las aplicaciones de las empresas con las que queremos cooperar para ofrecer mejor servicio a nuestros clientes. Es, en este cajón de sastre, donde SOA pretende hacer su aparición. La palabra arquitectura en el mundo del software se podría definir como un conjunto de decisiones que hemos de tomar a la hora de organizar nuestras aplicaciones, como van a interactuar entre ellas, qué software se va a usar a la hora de comunicar entre ellas (MOMs, EAIs etc...), qué plataformas, máquinas, sistemas operativos, lenguajes de programación, qué tipo de mensajes se van a intercambiar, etc... Las decisiones que tomamos a la hora de decidir nuestra arquitectura son fundamentales, no tanto a corto plazo, sino más bien a largo plazo, y pueden ser a veces una trampa mortal. SOA pretende ayudarnos a la hora de tomar este tipo de decisiones. ¿QUÉ NO ES SOA? La mejor manera de comenzar a explicar SOA, es explicar qué NO es: SOA no es un software, no es un MOM, no es un EAI, aunque una arquitectura SOA puede apoyarse en un conjunto de herramientas como MOMs o EAIs para conseguir su objetivo. SOA no es una metodología de proyecto, aunque a la hora de iniciar un proyecto orientado a conseguir una arquitectura SOA en mi empresa, algunas metodologías se ajustan mejor que otras: es preferible seguir un modelo en iteraciones (no confundir con iterativo como UP), como las metodologías ágiles (XP, etc..), que seguir metodologías Waterfall SOA no es otra forma de llamar a los WebServices, aunque los webservices son una herramienta válida para conseguir una arquitectura SOA, incluso una arquitectura SOA podría apoyarse en la programación distribuida (DCOM, CORBA, RMI, EJBs...) ¿QUÉ ES SOA? Entonces, ¿Qué es SOA? Yo me atrevería a definir SOA "una arquitectura donde la pieza fundamental es el servicio. Al ser una arquitectura, entendemos que es un conjunto de decisiones que debemos adoptar para Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

montar nuestra infraestructura tecnológica. Para poder continuar explicando la definición, urge definir previamente qué es un servicio. Primeramente, antes de continuar con la exposición, os planteo la siguiente pregunta: ¿Cuál es la duración media de los componentes que forman parte de la infraestructura tecnológica de una empresa? Una respuesta aproximada podría ser: Las innovaciones tecnológicas y productos nuevos aparecen aproximadamente cada 5 años. Nuestras aplicaciones empresariales tienen una duración de unos 8 a 10 años La lógica de negocio o los procesos de negocio permanecen en vigor unos 17 o 18 años. Los datos (o la estructura de los datos) perduran aproximadamente 25 años. En base a esas respuestas, podemos intuir que a la hora de elegir como organizar nuestra infraestructura tecnológica, si nuestro objetivo es obtener la máxima reusabilidad y permanencia en el tiempo, debemos adoptar decisiones que vayan orientadas hacia la independencia tecnológica y al acercamiento al proceso de negocio y los datos. Entonces, ¿Qué es un servicio? Un servicio lo podríamos definir como la resolución de una necesidad de negocio, que debe ser autocontenida (es decir que no contenga la resolución de otra necesidad en el mismo) y que está constituido por tres partes bien diferenciadas: 1. Un contrato: que define la especificación del propósito del servicio, así como restricciones en su uso, calidad que debe ofrecer etc..., pero sin especificar nada acerca de la tecnología subyacente. 2. Un interfaz físico donde los clientes que quieren usar el servicio pueden invocarlo (podría ser una URL) 3. Una implementación: un servicio se apoya en alguna tecnología para realizar lo que se expone en su contrato. La implementación de un servicio podrá consistir en la interacción de distintos artefactos (EJBs, CORBA, Bases de datos ... ), y estará compuesta de: 1. Una lógica de negocio 2. Una serie de datos. La idea que presenta SOA es construir nuestra arquitectura en base a un gran conjunto de servicios independientes, localizables e invocables de manera transparente y agnósticos de la tecnología. Estos servicios que podríamos denominar básicos, permitirán construir servicios de mayor valor añadido mediante la composición o el engranaje de estos servicios básicos. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

¿ACTORES DE SOA? Una vez que hemos visto lo que es un servicio, os voy a presentar los demás actores que deberían participar en una arquitectura SOA: 1. Frontales de aplicación. Estos serán no tanto partes funcionales de una arquitectura SOA sino aquellos que se van a beneficiar de ella, es decir serán aquellos que quieran hacer uso de los servicios ofrecidos dentro de la arquitectura. Frontales de aplicación podrán ser tanto aplicaciones WEB, CRMs, ERPs..., así como procesos Batch que se ejecutan de manera nocturna, etc...

2. Servicios. 3. Repositorio de servicios. Un repositorio de servicios será algún componente de mi arquitectura que permitirá tanto a los frontales de aplicación como a otros servicios, descubrir que servicios existen, cuál es su interfaz y donde se encuentran físicamente. Los objetivos de este componente serán:

1. Crear un nivel de indirección para localizar a los servicios 2. Servir como repositorio de información de los servicios existentes, contratos, calidad de los mismos, etc...

4. Bus de servicios (ESB). Este será un componente que permitirá a todos los participantes o actores de la arquitectura SOA comunicarse entre ellos. Este componente fundamental en la arquitectura SOA debe ofrecer:

1. Conectividad entre frontales de aplicación y los servicios. 2. Debe ser agnóstico de lenguajes de programación y tecnologías. Es decir debe ofrecer una forma de comunicación universal, para que todos puedan entenderse (por ejemplo, puede usar XML como formato de comunicación de los mensajes) 3. Debe ser capaz de ofrecer diferentes paradigmas de comunicación (sincronismo y asincronismo). Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

4. Debería ser capaz de ofrecer otra serie de funcionalidades transversales como:

Trazabilidad de las operaciones (logging) Mecanismos de seguridad (autenticación, autorización, encriptación, no repudio ...) Mecanismos de transaccionalidad: protocolo de commit en dos fases (2PC) o transacciones en cadena y mecanismos de compensación (SAGA) etc... Enriquecimiento de mensajes, adaptación etc... Control centralizado, mecanismos de monitorización. Que incluyese un procesador de BPM, que permitiese construir servicios de mayor valor añadido en base a servicios básicos, simplemente definiendo la lógica en algún lenguaje del tipo BPEL o BPEL4WS, etc... EPÍLOGO Conseguir reorganizar la infraestructura tecnológica de nuestra empresa para que se encamine hacia una arquitectura SOA es un proceso muy complejo. He leído en algún sitio que el 70% de los proyectos que se embarcan en esta tarea fracasan. No sólo nos encontraremos problemas tecnológicos, sino también muchos problemas debido a la política y cultura empresarial. Además, es un proceso largo (de años) que debe ser iniciado de manera muy cuidadosa. Es muy recomendable llevarlo a cabo de una manera gradual, y no todo de una vez, acompañando la tarea de llevarlo a cabo con una continua "evangelización" de las ventajas de SOA a todos los niveles de la empresa. Es probable que debamos cambiar la metodología de proyectos para orientarlo hacia metodologías más ágiles (XP) etc... Es probable también que debamos empezar a modelar siguiendo la filosofía de MDA (Model Driven Architecture), de una manera independiente de la tecnología, partiendo desde los procesos de negocio para ir gradualmente obteniendo el modelado específico de la plataforma en la que vamos a realizar la implementación del proceso de negocio (o servicio).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Por mi parte nada más, espero que os haya servido para entender un poco de que va esto del SOA. Arquitecturas para computación móvil A principios del nuevo milenio las tecnologías móviles, obviamente, no estaban tan evolucionadas como en la actualidad. Entre otros, se tenían los celulares por un lado, los busca personas por otro, y las PDA (Asistentes Personales Digitales), a las que tenía acceso el autor eran las de familia PALM, el color que predominaba en la pantalla de estos dispositivos era el verde. Para la comunicación se disponía de un accesorio denominado modem; este accesorio se utilizaba para enviar y recibir datos por medio de la línea telefónica. Emulador Palm OS, principios de los 2000

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Toma del Pedido, almacenado en el Dispositivo móvil y Envió posterior por medio de la línea telefónica. Arquitectura de una aplicación móvil Existen varios escenarios en los cuales se puede establecer la arquitectura de aplicaciones móviles; aquí se abordaran dos de ellos. En el primero participan tres elementos: La aplicación central El proceso de sincronización La aplicación en el dispositivo móvil

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Escenario número1. En el segundo escenario participan dos elementos: El dispositivo móvil La aplicación central Ejercicio de autoevaluación De acuerdo a las siguientes figuras desarrolle una aplicación con los elementos descritos en esta unidad teniendo en cuenta una muy buena arquitectura de software, como lenguaje de programación puede utilizar Java y su herramienta NetBeans u otra.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

4. DEFINICIONES Y PATRONES DE SOFTWARE. OBJETIVO GENERAL Apropiar el uso de catálogos de elementos reusables en el diseño de sistemas software OBJETIVOS ESPECÍFICOS Clarificar cada uno de los conceptos utilizados en patrones de software Evitar la reiteración en la búsqueda de soluciones a problemas solucionados anteriormente Estandarizar el modo en que se realiza el diseño por medio de la utilización de patrones GoF Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existentes

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

4.1. Prueba Inicial Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su grado de asimilación a) ¿Qué entiendes por patrones de diseño de software? b) ¿Cuáles son los propósitos y el ámbito de los patrones de diseño? c) ¿Caracterice de forma sencilla al menos 2 patrones de diseño?

4.2. Definiciones Básicas Patrones de diseño software El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, que permite describir el sistema con el suficiente detalle como para ser implementado. Pero los principios y reglas no son suficientes, en el contexto de diseño podemos observar que los buenos ingenieros Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

tienen esquemas y estructuras de solución que usan numerosas veces en función del contexto del problema. Este es el sentido cabal de la expresión "tener un mente bien amueblada", y no el significado de tener una notable inteligencia. Estos esquemas y estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza un esquema de solución ante problemas similares. El concepto de "patrón de diseño" que tenemos en Ingeniería del Software se ha tomado prestado de la arquitectura. En 1977 se publica el libro "A Pattern Language: Towns/Building/Construction", de Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, Oxford University Press. Contiene numerosos patrones con una notación específica de Alexander. Alexander comenta que “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”. El patrón es un esquema de solución que se aplica a un tipo de problema, esta aplicación del patrón no es mecánica, sino que requiere de adaptación y matices. Por ello, dice Alexander que los numerosos usos de un patrón no se repiten dos veces de la misma forma. La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos diseñadores se dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más famoso de patrones se encuentra en “Design Patterns: Elements of Reusable Object-Oriented Software”, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison-Wesley, también conocido como el libro GOF (Gang-Of-Four). Siguiendo el libro de GOF los patrones se clasifican según el proposito para el que han sido definidos: Creacionales: solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación. Estructurales: solucionan problemas de composición (agregación) de clases y objetos. De Comportamiento: soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan. Según el ámbito se clasifican en patrones de clase y de objeto:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Creación

Estructural

De Conducta Interprete Plantilla

Clase

Método de Fabricación Adaptador (clases)

Objeto

Cadena de Responsabilidad, Adaptador (objetos), Comando (orden), Iterador, Fábrica, Constructor, Puente, Composición, Intermediario, Observador, Estado, Prototipo, Singleton Decorador, Fachada, Estrategia, Visitante, Flyweight Memoria

Concepto de patrón de diseño "Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles". (Grady Booch) Los patrones de diseño son descripciones de clases cuyas instancias colaboran entre sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso debemos especificar: Nombre Propósito o finalidad Sinónimos (otros nombres por los que puede ser conocido) Problema al que es aplicable

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Estructura (diagrama de clases) Participantes (responsabilidad de cada clase) Colaboraciones (diagrama de interacciones) Implementación (consejos, notas y ejemplos) Otros patrones con los que está relacionado Ventajas de los patrones: La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada. Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento. Un patrón es un esquema o microarquitectura que supone una solución a problemas (dominios de aplicación) semejantes (aunque los dominios de problema pueden ser muy diferentes e ir desde una aplicación CAD a un cuadro de mando empresarial). Interesa constatar una vez más la vieja distinción entre dominio del problema (donde aparecen las clases propias del dominio, como cuenta, empleado, coche o beneficiario) y el dominio de la solución o aplicación (donde además aparecen clases como ventana, menú, contenedor o listener). Los patrones son patrones del dominio de la solución. También conviene distinguir entre un patrón y una arquitectura global del sistema. Por decirlo en breve, es la misma distancia que hay entre el diseño de un componente (o módulo) y el análisis del sistema. Es la diferencia que hay entre el aspecto micro y el macro, por ello, en ocasiones se denomina a los patrones como "microarquitecturas". En resumen, un patrón es el denominador común, una estructura común que tienen aplicaciones semejantes. Esto también ocurre en otros ordenes de la vida. Por ejemplo, en nuestra vida cotidiana aplicamos a menudo el esquema saludo-presentación-mensaje-despedida en ocasiones diversas, que van desde un intento de ligar hasta dar una conferencia (si todavía no cree que existan patrones o que no son útiles intente ligar con el esquema despedida-mensajepresentación-saludo, a ver qué ocurre).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

4.3. Catálogos de Patrones Patrón "delegado" La herencia es útil para modelar relaciones de tipo es-uno es-una, ya que estos tipos de relaciones son de naturaleza estática. Sin embargo, relaciones de tipo es-un-rol-ejecutado-por son mal modeladas con herencia. Un objeto receptor delega operaciones en su delegado. Presente en muchos patrones: State, Strategy, Visitor,..

Un ejemplo: supongamos que un objeto debe ordenar una estructura de datos. Puede delegar en otro objeto el método de comparación. En Java tenemos un caso: la clase Collections tiene el método estático sort(); desde este método se delega en un comparador para establecer el orden: Collections tiene el método sort() con un algoritmo de ordenación. Comparador tiene el método compare() que implementa el orden de comparación. import java.util.Comparator; public class comparador implements Comparator { public int compare( Object o1, Object o2 ) { if ( ((ente)o1).obt_id() < ((ente)o2).obt_id() ) return –1; if ( ((ente)o1).obt_id() > ((ente)o2).obt_id() ) Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

return 1; return 0; } }

Patrón "compuesto"

Crear jerarquías parte/todo de tal forma que los clientes manejan a los objetos primitivos y compuestos de forma uniforme. Por ejemplo, crear figuras que son una composición de otras figuras simples. Otro ejemplo puede ser un activo financiero (un fondo de inversión) que es un compuesto de otros activos financieros simples (valores o acciones). Los clientes pueden tratar objetos primitivos y compuestos de modo uniforme y es fácil añadir nuevos tipos de componentes. Implementación Vamos a ver un ejemplo con un applet AWT en donde existen diferentes subclases de Component: Componentes simples como TextField, List, Button, etc. Componentes compuestos como Container, del que hereda Panel. Veamos los atributos de la clase:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

public class calculador2 extends Applet { TextField t_n1 = new TextField(8); TextField t_n2 = new TextField(8); List lista = new List(); Button bot = new Button( "C a l c u l a r"); Panel panel_sup = new Panel(); Para crear compuestos podemos: Añadir un componente simple a un Panel (tipo de Container): panel_sup.add( t_n1 ) Crear compuestos recursivos, añadiendo un Panel a otro Panel: panel_global.add( panel_sup, BorderLayout.NORTH ) Referencias de componentes hijos a su padre puede ayudar a el recorrido y manejo de la estructura compuesta. Patrón "decorador" Imaginemos que tenemos un editor de texto básico y queremos añadirle nuevas funcionalidades, como un scroll o un borde. Una solución podría ser crear subclases para un editor con scroll, sin scroll, con scroll y con borde, etc. Evidentemente esta no es una buena solución, ya que acabamos con una jungla de clases y subclases. Con este patrón tratamos de evitar este efecto de herencia-jungla, ya que asignamos dinámicamente nuevas responsabilidades a un objeto. Es una alternativa más flexible a crear subclases para extender la funcionalidad de una clase. De esta forma añadimos atributos o comportamiento adicional a un objeto concreto, no a una clase.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Un ejemplo de implementación con Java El componente gráfico es un modesto editor de texto: JEditorPane panel_text = new JEditorPane(); Es muy sencillo añadir la funcionalidad del scroll sin usar herencia: JScrollPane scroll_text = new JScrollPane( panel_text ); // Asignamos scroll al panel de texto. El último paso es añadir el decorador (y por añadidura el editor) al contenedor raíz del applet: cont_global.add( scroll_text ); El componente no conoce a su decorador (en este caso el scroll). Es el decorador el que referencia a su componente. Esta es la razón de que al añadir (add) al contenedor raíz debamos usar el decorador (scroll) y no el componente (editor). Componentes y decoradores deben heredar de una clase común. En nuestro ejemplo JEditorPane y JScrollPane heredan de JComponent. Para ir a un tutorial sobre el patrón Decorador en tecnologías .NET pulse aquí.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Patrón "intermediario" Supongamos una ventana con numerosos componentes gráficos (widgets) que tienen fuertes dependencias entre si. Por ejemplo, reglas del tipo "si el campo de edición E2 está relleno, entonces inhabilito el botón B1 y el campo de edición E3". El mediador o intermediario encapsula la forma en que interaccionan un conjunto de objetos ("colegas"). Es el especialista que define las interdependencias entre ellos. Favorece un bajo acoplamiento, ya que evita que los objetos se referencien unos a otros de forma explícita. Permite variar la interacción sin tocar los colegas, por tanto favorece la reutilización.

Ventajas: Evita crear subclases Desacopla a los colegas Simplifica los protocolos entre las clases Abstrae el cómo cooperan los objetos Centraliza el control en el mediador: clase difícil de mantener Para la implementación: No hay necesidad de definir una clase abstracta Mediator si los colegas trabajan con un único mediador Los colegas deben comunicarse con el mediador cuando un evento de interés ocurre, esta comunicación puede hacerse con un Observer o un interfaz de notificación (ViewManager de Smalltalk-V). Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Cada colega tiene una referencia al mediador y de esta manera le pueden informar de los cambios realizados. Por ejemplo, una lista informa al mediador del cambio de item seleccionado; el mediador puede responder solicitando el texto seleccionado en la lista y mandándolo a un campo de texto. Ver el siguiente diagrama:

Patrón "iterador" Supongamos que tenemos un contenedor (por ejemplo, un vector) y queremos tener una forma de acceder a los elementos sin mostrar los detalles. Un objeto contenedor debe permitir una forma de recorrer sus elementos sin exponer su estructura interna, es decir, separar el contenedor de la forma de recorrer sus elementos. Con este patrón tenemos la ventaja de simplificar la interfaz de un contenedor, ya que no contiene los métodos de recorrerlo. Un ejemplo típico lo tenemos en Java. El cliente solicita al contenedor un iterador. A continuación el iterador dirige la forma de recorrer el contenedor: Vector vec = new Vector(); vec.add( new String( "hola“ ) ); vec.add( new String( "adios“ ) ); Iterator it = vec.iterator(); while ( it.hasNext() ) System.out.println( (String) it.next() );

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Patrón "observador" Definir una dependencia de 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean avisados y se actualicen automáticamente. Supongamos que tenemos un o unos objetos dependientes de otro. Por ejemplo, supongamos que una ventana o applet depende de los componentes gráficos que reciben eventos (clic en botón, etc.). Otro caso, típico del patrón, es tener diversas vistas de una fuente de datos, de tal forma que si cambia la fuente, entonces las vistas se actualicen automáticamente. El observador no es un mediador entre los sujetos (objetos que cambian de estado) y los objetos dependientes, ya que el mismo es un objeto dependiente. El observador recibe la orden de actualizarse por parte del sujeto "dominante"

Interesante cuando un cambio en un objeto implique cambios en otros y no se sepa cuantos objetos necesitan cambiar. Como se puede observar en el siguiente diagrama el sujeto tiene un método notify() que se encarga de mandar el mensaje de update() a todos los observadores.

Permite la división de un sistema en niveles. Además de permitir reusar sujetos y observadores por separado.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Una extensión natural de este patrón es hacer mezcla del patrón mediador y del patrón observador, de tal forma que los avisos de cambios que mandamos al observador sean notificados a otros objetos dependientes. El observador recibe un mensaje de cambio de estado y notifica a los objetos dependientes que se actualicen. Dicho de otra forma, cuando las relaciones de dependencia entre Subject y Observer son complicadas conviene encapsular la semántica de actualización en una clase ManejadorCambio(Mediador). Implementación Es posible que un observer esté ligado a más de un subject: la operación update tendrá como argumento el subject.¿Quién dispara la notificación? Métodos set en la clase Subject Clientes de la clase Subject Asegurarse de notificar siendo el estado de Subject consistente. Al registrar un observar es posible asociarle el evento sobre el que quiere ser notificado: attach(Observer obs, Evento interes); Ejemplo de implementación en Java Java 1.1 introdujo un nuevo modelo de eventos para GUI basado en el patrón Observer. Componentes GUI que pueden generar eventos son llamados fuentes de eventos (event sources). Objetos que desean ser notificados de eventos GUI son llamados oyentes de eventos (event listeners). Estos oyentes en Java trabajan como observers de nuestro patrón. Los listeners deben registrarse en las fuentes (componentes GUI). El orden sería "componente_GUI --->Listener ---> Objeto_dependiente (un applet, por ejemplo) Un ejemplo en Java, extraido de una clase applet, donde al botón le añadimos un listener: boton_crear.addActionListener(new ap_robot_boton_actionAdapter(this)); Lo primero es que el listener (ap_robot_boton_actionAdapter) se registra en el componente GUI (en este caso boton_crear de la clase Button) por medio de una llamada a addItemListener(). En segundo lugar, cuando se produce un evento el componente lo notifica al listener y este manda un mensaje al applet (en nuestro caso a boton_crear_actionPerformed(ActionEvent e), para que realice las acciones oportunas:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

void boton_crear_actionPerformed(ActionEvent e) { ... } Obsérvese que el evento queda encapsulado por la clase ItemEvent. Patrón "Modelo-Vista-Controlador" Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño ModeloVista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Si realizamos un diseño ofuscado, es decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la consecuencia será que, cuando necesitemos cambiar el interfaz, tendremos que modificar trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error. Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos. Elementos del patrón: Modelo: datos y reglas de negocio Vista: muestra la información del modelo al usuario Controlador: gestiona las entradas del usuario

Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc. Veamos cada componente:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

1. El modelo es el responsable de: 2. Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. 3. Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor". 4. Lleva un registro de las vistas y controladores del sistema. 5. Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc). 6. El controlador es responsable de: Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega( nueva_orden_de_venta )". 7. Las vistas son responsables de: Recibe datos del modelo y los muestra al usuario. Tienen un registro de su controlador asociado (normalmente porque además lo instancia).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Pueden dar el servicio de "Actualización ()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes). Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la navegación web, que responde a las entradas del usuario, pero no detecta los cambios en datos del servidor. El diagrama de secuencia: Pasos: 1. El usuario introduce el evento. 2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista). 3. El modelo (si es necesario) llama a la vista para su actualización. 4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo. 5. El Controlador recibe el control. Bien, pero esto ¿cómo se implementa? Existe una pequeña dificultad: la mayor parte de las herramientas de desarrollo incorporan en las clases de la vista gran parte o todo el procesamiento de eventos. Con lo que el controlador queda semioculto dentro de la vista. A pesar de ello, podemos acercarnos bastante al patrón. En el siguiente ejemplo en Java, el objeto vista es un Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Applet AWT. El controlador (controlador.java) puede gestionar el clic en un botón, de tal forma que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet) para su actualización (vista.mostrar_texto( )): /**************************************************************** Responde al click en botón "abrir" La respuesta al evento es hacer que se abra en la vista el archivo correspondiente a la referencia seleccionada en el combo box ****************************************************************/ void b_abrir_actionPerformed(ActionEvent e) { String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo /*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/ if (texto_archivo != null) { vista.mostrar_texto(texto_archivo); // Mostrar texto vista.mostrar_aviso("Carga de " + path + " completada."); } else vista.mostrar_aviso("Error en la carga de " + path); } Patrón "Factoria" En realidad son una familia de patrones: Factoria simple: una clase que crea objetos de otras clases. No delega en otras subclases y sus métodos pueden ser estáticos. Factory Method: Se define una interface para crear objetos, como en el Abstract Factory, pero se delega a las subclases implementar la creación en concreto Abstract Factory: Nos da una interface para crear objetos de alguna familia, sin especificar la clase en concreto Los dos últimos están incluidos en el catálogo del GoF

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Estos patrones entran en la categoría de patrones de creación [GoF95], la cual comparten con otros patrones tales como el Singleton, Builder y Prototype [GoF95]. Tienen la responsabilidad de crear instancias de objetos de otras clases. Tienen además la responsabilidad y el conocimiento necesario para encapsular la forma en que se crean determinados tipos de objetos en una aplicación. Existen diferentes patrones de tipo Factory. Factorial simple Como en todas las factorias, tenemos las clases instanciadas (JuegoDelDado y JuegoDeMoneda) que se relacionan con una clase madre (extends) o con un interfaz lógico (implements). En nuestro caso usamos interfaz. A continuación puede ver un sencillo ejemplo en el que cada juego implementa el método lanzar (): el juego del dado muestra un número aleatorio del 1 al 6 y el de la moneda 'Cara' o 'Cruz': public interface Juego { void lanzar(); } import java.util.Random; public class JuegoDelDado implements Juego { public void lanzar() { Random ran = new Random(); Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

int resul = ran.nextInt(6) + 1;

// Aleatorio de 1 a

6 System.out.println( resul ); } } import java.util.Random; public class JuegoDeMoneda implements Juego { public void lanzar() { Random ran = new Random(); if ( ran.nextBoolean() ) System.out.println( "Cara" ); else System.out.println( "Cruz" ); } }

La clase FactoriaJuegos es única. No delega en una subclase la creación de instancias (a diferencia de Factory Method). Esta factoria es muy sencilla: en función del argumento crea un juego u otro: public class FactoriaJuegos { public static Juego getJuego( String nombreJuego ) { Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

if ( nombreJuego.equals("JuegoDelDado") ) return new JuegoDelDado(); else { if ( nombreJuego.equals("JuegoDeMoneda") ) return new JuegoDeMoneda(); else return null; } } } Lo esencial de la clase Factoria es que oculta a la clase cliente (Inicio.java) la complejidad de crear un objeto. Encapsula la creacioón de la instancia. La clase cliente (Inicio.java) llama al método estático getJuego() de la factoría, para que le devuelva el juego señalado en el argumento. Introduce todos los juegos en un vector y a continuación le dice a cada juego que juegue. El método jugar() es un ejemplo de patrón 'estrategia': el método contiene un comportamiento genérico (en nuestro ejemplo realiza dos lanzamientos para cada juego). El comportamiento específico se define en función del objeto que se pasa como argumento. La parte que varía es el argumento, esta es la estrategia. public class Inicio { public static void main(String[] args) { //// Crea un vector de juegos Vector vec = new Vector(); vec.add(FactoriaJuegos.getJuego( "JuegoDelDado") ); vec.add(FactoriaJuegos.getJuego( "JuegoDeMoneda") ); vec.add(FactoriaJuegos.getJuego( "JuegoDelDado") ); //// A cada juego del vector le dice que juegue for ( int i = 0; i < vec.size(); i++ ) { Juego j = (Juego) vec.get(i); if ( j != null ) jugar( j ); else System.out.println("Juego no encontrado"); } } /***************************************************************** * Lanza dos veces Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

****************************************************************/ public static void jugar( Juego juego ) { juego.lanzar(); juego.lanzar(); } } Al recorrer el vector de juegos vemos un ejemplo típico de polimorfismo: a cada referencia del tipo Juego (usamos el mismo interfaz) le decimos que juegue, pero cada juego implementa su forma específica de jugar (más en concreto de lanzar). Es la idea de polimorfismo: un interfaz y múltiples implementaciones. Aunque la forma más abstracta y profesional es usar en la factoria newInstance() en función de los valores de un archivo .properties: import java.io.*; public class FactoriaJuegos { // true=Carga de Properties desde archivo private static boolean propiedadesCargadas = false; // Propiedades private static java.util.Properties prop = new java.util.Properties(); ********************************************************** Crea y devuelve el juego ***************************************************************** public static Juego getJuego( String nombreJuego ) { try { //// La clase se consigue leyendo del archivo properties Class clase = Class.forName( getClase( nombreJuego ) ); //// Creo una instancia return (Juego) clase.newInstance(); } catch (ClassNotFoundException e) { // No existe la clase e.printStackTrace(); return null; } catch (Exception e) {// No puedo instanciar la clase Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

e.printStackTrace(); return null; } } ********************************************************** * Lee un archivo properties donde se indica la clase que debe ser instanciada *********************************************************** private static String getClase( String nombrePropiedad ) { try { // Carga de propiedades desde archivo if ( !propiedadesCargadas ) { FileInputStream archivo = new FileInputStream( "src/factoriaJuegosNewInstanceProperties/propiedades.properties" ); prop.load( archivo ); // Cargo propiedades propiedadesCargadas = true; } // Lectura de propiedad String nombreClase = prop.getProperty( nombrePropiedad, ""); if ( nombreClase.length() > 0) return nombreClase; return null; } catch ( FileNotFoundException e) { // No se puede encontrar archivo e.printStackTrace(); return null; } catch ( IOException e) { // Falla load() e.printStackTrace(); return null; } catch (Exception e) { e.printStackTrace(); return null; } } } En el archivo properties tenemos: dado=factoriaJuegosNewInstanceProperties.JuegoDelDado moneda=factoriaJuegosNewInstanceProperties.JuegoDeMoneda

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Patrón "Data Access Object" El problema que viene a resolver este patrón es el de contar con diversas fuentes de datos (base de datos, archivos, servicios externos, etc). De tal forma que se encapsula la forma de acceder a la fuente de datos. Este patrón surge históricamente de la necesidad de gestionar una diversidad de fuentes de datos, aunque su uso se extiende al problema de ancapsular no sólo la fuente de datos, sino además ocultar la forma de acceder a los datos. Se trata de que el software cliente se centre en los datos que necesita y se olvide de cómo se realiza el acceso a los datos o de cuál es la fuente de almacenamiento. Enlace a las páginas de SUN. Las aplicaciones pueden utilizar el API JDBC para acceder a los datos de una base de datos relacional. Este API permite una forma estándar de acceder y manipular datos en una base de datos ralacional. El API JDBC permite a las aplicaciones J2EE utilizar sentencias SQL, que son el método estándar para acceder a tablas y vistas. La idea de este patrón es ocultar la fuente de datos y la complejidad del uso de JDBC a la capa de presentación o de negocio. Un DAO define la relación entre la lógica de presentación y empresa por una parte y por otra los datos. El DAO tiene un interfaz común, sea cual sea el modo y fuente de acceso a datos.

Algunas características: No es imprescindible, pero en proyectos de cierta complejidad resulta util que el DAO implemente un interfaz. De esta forma los objetos cliente tienen una forma unificada de acceder a los DAO.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El DAO accede a la fuente de datos y la encapsula para los objetos clientes. Entendiendo que oculta tanto la fuente como el modo (JDBC) de acceder a ella. El TransferObject encapsula una unidad de información de la fuente de datos. El ejemplo sencillo es entenderlo como un "bean de tabla", es decir, como una representación de una tabla de la base de datos, por lo que representamos las columnas de la tabla como atributos del TransferObject. El DAO crea un TransferObject (o una colección de ellos) como consecuencia de una transacción contra la fuente de datos. Por ejemplo, una consulta sobre ventas debe crear tantos objetos (TransferObject) de la clase Venta como registros de la consulta; el DAO devolverá la colección de TrasnferObject de la clase Venta al objeto Cliente. También puede ocurrir que el objeto Cliente mande un TransferObject para parametrizar una consulta o actualización de datos por parte del DAO. En el siguiente gráfico se muestran las interacciones entre los elementos del patrón. En este gráfico el TransferObject se denomina ValueObject. Puede observarse las llamadas que recibe y genera el DAO para una consulta y actualización de datos:

1. 2. 3. 4. 5. 6.

El DAO es creado por el cliente (BusinessObject) (llamada 1 del gráfico). A continuación el cliente solicita los datos al DAO (getData) (2). El DAO responde a la llamada pidiendo los datos a la fuente de datos (2.1). Para cada fila recibida, el DAO crea un TransferObjet (ValueObject del gráfico) (2.2). El DAO devuelve al cliente el(los) TransferObject (2.3). A continuación el cliente define un TransferObject mediante llamadas a setProperty. Por ejemplo, supongamos que buscamos personas de sexo varón y 36 años; para ello el BusinessObject define en el objeto de la clase Persona la edad y sexo que busca. Lo siguiete es fácil de imaginar: el BusinessObject invoca al DAO, pasando a la persona como argumento (3,4, y 5 del gráfico). 7. En DAO.setData() se solicita (5.1 y 5.2) al TransferObjet o ValueObject (nuestra persona del ejemplo) los datos (edad, sexo, etc.) para realizar el acceso a datos (dataSource.setData()), (5.3).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Ejemplo de código: los bean (Transfer Object) En el siguiente sencillo ejemplo tenemos dos tablas en nuestra base de datos. La tabla de clientes incluye: Codigo (clave primaria) Nombre, apellido 1 y apellido 2 Edad En la tabla de ventas tenemos las ventas realizadas a cada cliente: Id de la venta (clave primaria) Codigo de cliente (clave externa) Precio y coste de la venta Vamos a representar estas tablas en clases que de manera informal se conocen como "beans de tabla". Antes de crear estas tablas vamos a ver su interface común (Bean.java): package dao.bean; public interface Bean {

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

//// Me indica si los objetos corresponden al mismo registro de base de datos (identidad de clave primaria) public boolean esIgual( Bean bean ); } A continuación escribimos los bean de tabla que implementan el interface anterior, empezamos por la calse Cliente.java: ***************************************************************** * Bean de tabla "cliente" ***************************************************************** public class Cliente implements Bean { private String codigo = null; private String nombre = null; private String ape1 = null; private String ape2 = null; private Integer edad = null; private Vector ventas = null; public Cliente( String codigo, String nombre, String ape1, String ape2, Integer edad ) { setCodigo( codigo ); setNombre( nombre ); setApe1( ape1 ); setApe2( ape2 ); setEdad( edad ); } public Cliente(){} public String getApe1() { return ape1; } public void setApe1(String ape1) { this.ape1 = ape1; } ... Otros métodos set/get ... // Me indica si los objetos corresponden al mismo registro (identidad de clave primaria) public boolean esIgual( Bean bean ) { Cliente cli = (Cliente) bean; if ( cli.getCodigo().equals( this.getCodigo()) ) return true; Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

return false; } public String toString() { return (codigo + ", " + nombre + ", " + ape1 + ", " + ape2 + ", " + edad); } } En Cliente.java se puede observar que uno de los atributos es un vector de ventas. La utilidad de este Vector es representar en modo "objetos" una relación 1:N de tablas (cliente y ventas) de la base de datos. Seguimos con la clase Venta.java: ***************************************************************** * Bean de tabla "venta" ***************************************************************** public class Venta implements Bean { Integer idVenta = null; String codigo = null; Float precio = null; Float coste = null; Cliente cliente = null; public Venta(Integer idVenta, String codigo, Float precio, Float coste ) { setIdVenta( idVenta ); setCodigo( codigo ); setPrecio( precio ); setCoste( coste ); } public Venta() {} public Float getCoste() { return coste; } public void setCoste(Float coste) {this.coste = coste; } ... Otros métodos set/get ... //// Me indica si los objetos corresponden al mismo registro (identidad de clave primaria) public boolean esIgual( Bean bean ) { Venta ven = (Venta) bean; if ( ven.getIdVenta().intValue() == this.getIdVenta().intValue() ) return true; return false; Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

} public String toString() { return (idVenta + ", " + codigo + ", " + precio + ", " + coste ); } } Ejemplo de código: los DAOs Hemos empezado por lo más sencillo, representar las tablas de nuestra base de datos. Dicho de otra forma proyectar el modelo relacional sobre un modelo de objetos. Ahora tenemos que implementar los DAOs, los componentes que encapsulan el acceso a la fuente de datos (la base de datos). Empezamos creando un interface (InterfaceDAO.java) que representa el comportamiento genérico de cualquier DAO: package dao.accesoDatos; import java.sql.SQLException; import java.util.Vector; import dao.bean.Bean; public interface InterfaceDAO { public int insert( Bean bean ) throws SQLException; public int update( Bean bean, String condicion ) throws SQLException; public Bean find( String codigo ) throws SQLException; public Vector select( String condicion ) throws SQLException; public int delete(String condicion) throws SQLException; } A continuación y a modo de resumen, una parte de DAOCliente.java. Se puede ver que implementa el interface anterior y que además hereda de DAOGeneral, una clase que contiene servicios comunes, como por ejemplo getConexion(), cerrarConexion(Connection), etc: public class DAOCliente extends DAOGeneral implements InterfaceDAO { /***************************************************************** * Inserta cliente (argumento bean) *****************************************************************/ public int insert( Bean bean ) throws SQLException { int numFilas = 0; Cliente cli = (Cliente) bean; Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Connection con = getConexion(); String orden = "INSERT INTO CLIENTE VALUES (" + (cli.getCodigo()==null? null: "'" + cli.getCodigo() + "' ") + ","+ (cli.getNombre()==null? null: "'" + cli.getNombre() + "' ") +", " + (cli.getApe1()==null? null: "'" + cli.getApe1() + "' ") +", " + cli.getApe2()==null? null: "'" + cli.getApe2() + "' ") + ", " + cli.getEdad() + ")"; Statement sentencia = con.createStatement(); numFilas = sentencia.executeUpdate(orden); sentencia.close(); cerrarConexion( con ); return numFilas; } .... El método insert() recibe el Transfer Object (bean) que vamos a insertar, devolviendo el número de registros insertados (uno si ha ido bien, 0 en caso de no inserción). En el método select() recibimos la condición (claúsula WHERE) y devuelve un vector cuyos elementos son los clientes que cumplen la condición. Podría también devolver un ArrayList, que resulta más eficiente, pero lo esencial es que este método, al igual que el anterior, oculta el uso de SQL y JDBC a la clase que la llama (presentación o BusinessObject): public Vector select( String condicion ) throws SQLException { Vector vecClientes = new Vector(); Cliente cli; Connection con = getConexion(); // Si la condición es null o vacia, no hay parte WHERE String orden = "SELECT * FROM cliente c " + (condicion==null || condicion.length()==0 ? "":"WHERE " + condicion) + " ORDER BY c.ape1, c.ape2, c.nombre"; Statement sentencia = con.createStatement(); ResultSet rs = sentencia.executeQuery( orden ); while (rs.next()) { cli = new Cliente( rs.getString("codigo"), rs.getString("nombre"), rs.getString( "ape1" ), rs.getString( "ape2" ), (rs.getString( "edad" )==null ? null : new Integer(rs.getInt( "edad" )))); vecClientes.add( cli ); } sentencia.close(); cerrarConexion( con ); Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

return vecClientes; } En la siguiente figura se muestra la relación de las clases anteriores:

Ejemplo de código: la factoría de DAOs Aunque no resulta imprescindible, en proyectos de cierta envergadura necesitaremos una factoria de objetos DAO, que se responsabiliza de instanciar el DAO adecuado (en nuestro ejemplo DAOCliente.java o DAOVenta.java). Enlace al patrón factoria. En nuestro ejemplo hemos implementado una Factoria Simple (FactoriaDAO.java): package dao.accesoDatos; import java.io.*; /***************************************************************** * * Factoria que crea el DAO en función del argumento del método getDAO() * *****************************************************************/ public class FactoriaDAO { // true=Carga de Properties desde archivo private static boolean propiedadesCargadas = false; // Propiedades private static java.util.Properties prop = new java.util.Properties(); /***************************************************************** * Crea y devuelve el DAO *****************************************************************/ public static InterfaceDAO getDAO( String nombre ) { try { Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Class clase = Class.forName( getClase( nombre ) ); // La clase se consigue leyendo del archivo properties return (InterfaceDAO) clase.newInstance(); // Creo una instancia } catch (ClassNotFoundException e) { // No existe la clase e.printStackTrace(); return null; } catch (Exception e) { // No puedo instanciar la clase e.printStackTrace(); return null; } } /***************************************************************** * Lee un archivo properties donde se indica la clase que debe ser instanciada *****************************************************************/ private static String getClase( String nombrePropiedad ) { String nombreClase = null; try { //// Carga de propiedades desde archivo if ( !propiedadesCargadas ) { FileInputStream archivo = new FileInputStream ( "src/dao /propiedades.properties" ); prop.load( archivo ); // Cargo propiedades propiedadesCargadas = true; } //// Lectura de propiedad nombreClase = prop.getProperty( nombrePropiedad, ""); if ( nombreClase.length() == 0) return null; } catch ( FileNotFoundException e) {// No se puede encontrar archivo e.printStackTrace(); } catch ( IOException e) { // Falla load() e.printStackTrace(); } catch (Exception e) {

/accesoDatos

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

e.printStackTrace(); } return nombreClase; } } Esta clase lee un archivo properties donde asociamos una clave con una clase DAO. Su contenido es sencillo: cliente=dao.accesoDatos.DAOCliente venta=dao.accesoDatos.DAOVenta El método getClase() recibe un String (la vlave: cliente o venta). Si no se ha cargado el archivo properties en el atributo 'Properties prop', entonces lee archivo y carga las propiedades en prop. getClase() devuelve el valor de la clave, por ejemplo, si recibe 'cliente' devuelve 'dao.accesoDatos.DAOCliente'. El método getDAO() llama a getClase() para saber la clase DAO que debe instanciar. Un aspecto importante es lo que devuelve getDAO(): el tipo InterfaceDAO. Al devolver el interface, estamos actuando con bástante generalidad: instanciamos objetos concretos, un DAOCliente.java o un DAOVenta.java, pero lo esencial es que usamos como tipo de referencia el interface que ambas clases implementan. La factoria hace su trabajo de modo genérico o abstracto, ya que aunque tenga 15 clases de DAOs diferentes que instanciar, devuelve un tipo genérico, es decir, devuelve el interface que implementan todos los DAOs. Ejemplo de código: usando lo anterior Vamos a ver un sencillo ejemplo de capa cliente, es decir, la capa (sea presentación o de negocio) que debe usar lo anterior (factoria, beans y DAOs). Este sencillo ejemplo destaca una de las ventajas de trabajar con los interface: obtenemos abstracción (y resuabilidad). Veamos el ejemplo: condicion = Teclado.getCadena("Condición:"); // Obtengo condición por teclado InterfaceDAO dao = FactoriaDAO.getDAO( nombreTabla ) // Obtengo el DAO de la factoria Vector vec = dao.select( condicion ); // La Select devuelve Vector Iterator it = vec.iterator(); while (it.hasNext()) { bean = (Bean) it.next(); System.out.println( bean.toString()); }

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

La variable nombreTabla es un sencillo String que contiene la clave del archivo properties. De esta forma la factoria sabe la clase DAO que debe instanciar. Lo primero que interesa destacar es que el DAO instanciado y devuelto por la factoria lo manejamos por medio del tipo interface (InterfaceDAO): sea la que sea la clase instanciada usamos un tipo genérico (el interface que implemnetan los DAO). Esto nos permite actuar con un alto grado de generalidad: para cualquier tipo de DAO le mandamos el mismo mensaje: dao.select( condicion ). No nos vemos obligados a realizar un código para DAOCliente, otro para DAOVenta, etc; sino que con el mismo código manejamos diversos DAOs. Este es un ejemplo de patrón estrategia: el código es el mismo (unificado) y la estrategia (el comportamiento específico) depende de los objetos (DAOs) utilizados. Un ejemplo final de abstracción es que los elementos del vector los manejamos con el tipo interface Bean (que implementan las clases 'bean'). Esto permite que les mande a todos el mismo mensaje, bean.toString(), y que cada bean (sea de la clase que sea) implemente su comportamiento específico. Otro ejemplo de aplicación del patrón DAO con servlets. En este ejemplo las clases DAO han cambiado ligeramente para soportar un login y password diferentes en cada conexión. Nota final Evidentemente los DAOs deben implementar los métodos del interface (InterfaceDAO) que declaran. Pero además pueden implementar otros métodos que no están en el interfaz (lo cual resta generalidad). En nuestro ejemplo hemos introducido un método que nos permite hacer un select de clientes con sus ventas correspondientes. Antes hemos visto que uno de los atributos del 'bean' Cliente.java es un vector de ventas:

public class Cliente implements Bean { ... private Vector ventas = null; Este vector nos permite representar en nuestro modelo de objetos la relación 1:N de nuestras tablas. El siguiente método de DAOCliente.java nos devuelve un vector de clientes y cada cliente contiene un vector de ventas: /***************************************************************** * Consulta de clientes CON sus ventas * Si condición es null o vacia, no se aplica en el WHERE

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

*****************************************************************/ public Vector selectConVentas( String condicion ) throws SQLException { Vector vecClientes = new Vector(); Venta ven; Cliente cliAnterior = null, cliActual = null; Connection con = getConexion(); //// Si la condición es null o vacia, no hay parte WHERE String orden = "SELECT c.codigo, c.nombre, c.ape1, c.ape2, c.edad, v.id_venta, v.precio, v.coste FROM cliente c, venta v " + " WHERE c.codigo = v.codigo " + (condicion==null || condicion.length()==0 ? "":"AND " + condicion) + " ORDER BY c.ape1, c.ape2, c.nombre"; Statement sentencia = con.createStatement(); ResultSet rs = sentencia.executeQuery( orden ); //// Recorremos el ResultSet y guardamos los clientes en un vector. Cada cliente tiene su vector de ventas while (rs.next()) { //// Obtengo cliente y venta cliActual = new Cliente(rs.getString("c.codigo"), rs.getString("c.nombre"), rs.getString( "c.ape1" ), rs.getString( "c.ape2" ), (rs.getString( "c.edad" )==null ? null : new Integer(rs.getInt( "c.edad" )))); ven = new Venta( rs.getInt("v.id_venta"), rs.getString("c.codigo"), rs.getFloat("v.precio"), rs.getFloat("v.coste")); //// SI ES NUEVO: Si es el primer cliente (cliAnterior==null) o es distinto que el anterior ... if ( cliAnterior == null || !cliActual.esIgual( cliAnterior ) ) { //// El anterior es el actual cliAnterior = cliActual; //// Inicializo vector de ventas del cliente actual y añado venta cliActual.setVentas( new Vector()); cliActual.addVenta( ven ); //// Añado cliente actual al vector vecClientes.add( cliActual ); } //// SI NO ES NUEVO CLIENTE: simplemente añado venta al cliente else { //// Añado venta al cliente actual cliAnterior.addVenta( ven ); Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

} } sentencia.close(); cerrarConexion( con ); return vecClientes; } Patrón "Proxy" El proxy es útil si queremos añadir o modificar comportamiento de una clase (la llamaremos "objeto real") sin tener que modificarla. El proxy es un intermediario que implica un recubrimiento del objeto real. Un ejemplo Tenemos un interface para escribir y leer de un soporte: public interface Soporte { public void escribir( String mensaje ); public String leer( int numLinea ); public Vector leer(); } Además tenemos una clase, denominada Pizarra, que implementa el interface Soporte y que en su método escribir(String mensaje) simplemente añade el argumento a un Vector. El método leer(int numLinea) devuelve la cadena cuyo orden dentro del vector es el argumento. El cliente (main) pueda insertar (escribir) y obtener (leer) cadenas. import java.util.*; public class Pizarra implements Soporte { private Vector mensajes = new Vector(); public void escribir(String mensaje) { mensajes.add(mensaje); } public String leer(int numLinea) { return mensajes.get(numLinea); }

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

public Vector leer() { return mensajes; } } El proxy es un intermediario (que también implementa el interface del objeto real) y que nos permite añadir o modificar comportamiento sin reescribir el objeto real. En escribir() del proxy añado el número de línea y delega en la Pizarra el resto de comportamiento. Es interesante observar que este patrón evita abusar del uso de herencia. Este abuso es la primera tentación del novato, ya que piensa: "si quiero modificar el comportamiento de una clase hago el nuevo comportamiento en una clase hija". No es que la herencia sea de partida ilegal o inconveniente, simplemente se trata de no abusar de ella aplicándola a todo tipo de problema. De esta forma no caeremos en el vicio de aquel que sólo sabía usar martillos y todos los problemas le parecían clavos. import java.util.Vector; public class ProxyDePizarra implements Soporte { private Soporte soporte; public ProxyDePizarra() { this.soporte = new Pizarra(); } public ProxyDePizarra( Soporte soporte) { this.soporte = soporte; } public void escribir( String mensaje ) { String linea = String.valueOf(soporte.leer().size()+1) + " " + mensaje; soporte.escribir( linea ); } public String leer( int numLinea ) { return soporte.leer( numLinea ); } public Vector leer() { return soporte.leer(); } } Un aspecto importante del cliente es que sólo utiliza el tipo Interface Soporte para acceder al proxy, con lo que conseguimos generalidad:

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

public class Inicio { static public void main(String[] args) { try { //// Creamos el proxy Soporte proxy = Factoria.getPizarra("ProxyDePizarra"); //// Escribimos (el proxy inserta número de línea) proxy.escribir("En un lugar de La Mancha"); proxy.escribir("de cuyo nombre no quiero acordarme"); for (String str : proxy.leer()) Visor.mostrar(str); } catch (Exception e) { e.printStackTrace(); } } } La factoria simple es otro patrón importante. Una factoría se centra en ocultar la instanciación de una clase. En nuestro caso anterior devuelve un objeto del tipo ProxyDePizarra: /***************************************************************** * Factoria de pizarra (objeto real o proxy). Recibe el nombre de la clase * (sin especificar paquete) y crea y devuelve el objeto (real o proxy). *****************************************************************/ public class Factoria { static public Soporte getPizarra( String nomClase ) throws Exception { Class clase = Class.forName( Factoria.class.getPackage().getName() + "." + nomClase); return (Soporte) clase.newInstance(); } } Nota: Para que el newInstance() de la Factoria pueda funcionar debe existir un constructor sin argumentos en el ProxyDePizarra. El visor es algo elemental, tan sólo sirve para diferenciar el modelo de la vista: public class Visor { static public void mostrar( String mensaje ) { System.out.println( mensaje ); } } El resultado final sería: Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

1 En un lugar de La Mancha 2 de cuyo nombre no quiero acordarme Otras características El proxy y el objeto real comparten interface. El proxy debe tener una referencia al objeto real.

Ya hemos dicho que el proxy es un intermediario que implica un recubrimiento del objeto real para añadir o modificar comportamiento. Especialmente apropiado cuando estamos en situaciones en las que tenemos que elegir entre las operaciones del objeto real y las del proxy. Aunque en el ejemplo anterior no hacemos instancia del objeto real ni permitimos ningún acceso directo a él, podríamos tener dos tipos de acceso: uno directo al objeto real y otro al proxy. soporte piz = Factoria.getPizarra("Pizarra"); Soporte proxy = new ProxyDePizarra(piz); piz.escribir("XYZ"); // NO añade nº de línea proxy.escribir("QQQ"); // SI añade nº de línea

Ejercicio de autoevaluación Diseñe el análisis del ejercicio de la Unidad1 utilizando Patrones de Software de tal manera que el objetivo final sea la base fundamental para una posterior implementación en cualquier lenguaje de programación orientado por aspectos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

5. FRAMEWORKS Y EL MÓDELO MDA (MODEL DRIVEN ARCHITECTURE) OBJETIVO GENERAL Identificar las características de un framework para Web y apropiarse del modelado bajo el enfoque MDA. OBJETIVOS ESPECÍFICOS Conocer y graficar los conceptos y estructura de un frameworks Establecer y aplicar las técnicas para la implementación de framework a nivel empresarial. Identificar y diferenciar las tecnologías para desarrollos de software basados en MDA/MDD Diferenciar PSM de PIM aplicadas en MDA

5.1. Relación de conceptos

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

5.2. Prueba Inicial Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su grado de asimilación 1. 2. 3. 4. 5. 6.

¿Sabes en que consiste el Framework? ¿Qué aspectos relevantes del patrón MVC podrías indicar? ¿Qué podrías aportar acerca de Strust y URLs desde éste contexto? ¿Sobre los conceptos MDA, PIM, PSM y CIM que podrías aportar? ¿Podrías graficar el proceso interactivo del modelado MDA? ¿A qué se hace referencia con los términos infraestructura y núcleo común, perfiles y metamodelado.

5.3. Definición y Estructura del Frameworks El objetivo de este trabajo es explicar de forma clara y sencilla en que consiste un framework para sistemas Web y las características generales de éstos, A continuación se realiza una breve descripción de Struts, uno de los framewoks más utilizados en desarrollo Web bajo plataforma Java. 1. ¿Qué es un framework Web?. En general, con el término framework, nos estamos refiriendo a una estructura software compuesta de componentes personalizables e intercambiables para el desarrollo de una aplicación. En otras palabras, un framework se puede considerar como una aplicación genérica incompleta y configurable a la que podemos añadirle las últimas piezas para construir una aplicación concreta. Los objetivos principales que persigue un framework son: acelerar el proceso de desarrollo, reutilizar código ya existente y promover buenas prácticas de desarrollo como el uso de patrones. Un framework Web, por tanto, podemos definirlo como un conjunto de componentes (por ejemplo clases en java y descriptores y archivos de configuración enXML) que componen un diseño reutilizable que facilita y agiliza el desarrollo de sistemas Web.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

2. Patrón MVC y Model 2. Para comprender como trabajan los frameworks Web existentes es imprescindible conocer el patrón MVC. El patrón Modelo-Vista-Controlador es una guía para el diseño de arquitecturas de aplicaciones que ofrezcan una fuerte interactividad con usuarios. Este patrón organiza la aplicación en tres modelos separados, el primero es un modelo que representa los datos de la aplicación y sus reglas de negocio, el segundo es un conjunto de vistas que representa los formularios de entrada y salida de información, el tercero es un conjunto de controladores que procesa las peticiones de los usuarios y controla el flujo de ejecución del sistema. La mayoría, por no decir todos, de los framewroks para Web implementan este patrón. Una aplicación de este patrón en entornos Java para programación Web es lo que se conoce con el nombre de arquitectura modelo 2.

Esta arquitectura consiste, a grandes rasgos, en la utilización de servlets paraprocesar las peticiones (controladores) y páginas JSP para mostrar la interfaz de usuario(vistas), implementando la parte del modelo mediante JavaBeans o POJOs. 3. Tipos de framework Web. Existen varios tipos de frameworks Web: orientados a la interfaz de usuario, como Java Server Faces, orientados a aplicaciones de publicación de documentos, como Coocon, orientados a la parte de control de eventos, como Struts y algunos que incluyen varios elementos como Tapestry. La mayoría de frameworks Web se encargan de ofrecer una capa de controladores de acuerdo con el patrón MVC o con el modelo 2 de Servlets y JSP, ofreciendo mecanismos para facilitar la

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

integración con otras herramientas para la implementación de las capas de negocio y presentación. 4. Características. A continuación enunciamos una serie de características que podemos encontraren prácticamente todos los frameworks existentes.

5. Un ejemplo: Struts El framwrok open-source Struts ha sido desarrollado en Java mediante servlets y está basado en el Modelo 2, el cual es una variante del patrón MVC.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Struts ofrece su propio componente controlador y proporciona integración con otras tecnologías para implementar el modelo, mediante tecnologías de acceso a datos como JDBC o Hibernate, y la vista, mediante JSP, Velocity o XSLT. Struts ofrece un sistema de tuberías que permite la comunicación entre el modelo que contiene los datos y las vistas que ofrecen estos datos a los usuarios y reciben sus órdenes. 6. URLs.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

5.4. MDA (Model Driven Architecture) Model Driven Architecture (MDA) es una aproximación definida por el Object Management Group (OMG) [OMG], mediante la cual el diseño de los sistemas se orienta a modelos. En ocasiones, el término MDA se intercambia con el de MDD (Model-Driven Development). MDD se refiere a las actividades que llevan a cabo los desarrolladores, mientras que MDA se refiere a su definición formal. Definición creada por el grupo de trabajo OMG, que se centra en la creación de un marco de trabajo formal, en el que puede operar MDD [Gardner 2006]. A pesar de estas sutiles diferencias, ambos términos se utilizan de manera indistinta en este trabajo. El desarrollo orientado a modelos permite una alta flexibilidad en la implementación, integración, mantenimiento, prueba y simulación de los sistemas. Una de las ideas principales por la que surge MDA es separar la especificación de los sistemas de los detalles de su implementación en una determinada plataforma. MDA provee un conjunto de herramientas para especificar un sistema independientemente de la plataforma de implementación, especificar dichas plataformas, elegir una determinada plataforma para el sistema, y transformar las especificaciones de los sistemas a la plataforma elegida. Todo esto se complementa con los objetivos de portabilidad, interoperabilidad y reusabilidad. La independencia propuesta por MDA se consigue mediante una catalogación de modelos que permiten especificar el sistema desde diferentes puntos de vista. Los tipos más destacables de modelos son los siguientes: Computational Independent Model (CIM): son visiones de los sistemas desde el punto de vista del problema a resolver, es decir, un modelo simplificado que se abstrae de detalles específicos. Platform Independent Model (PIM): muestra una vista del diseño del sistema obviando detalles de plataformas concretas. Platform Specific Model (PSM): muestra un diseño del sistema incluyendo detalles específicos de la plataforma.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Desarrollo de Software Tradicional El desarrollo de sistemas software siempre ha sido una labor intensa, pero a medida que ha ido evolucionando la tecnología, esta labor se ha complicado cada vez más. La evolución de los lenguajes, entornos y técnicas de programación provoca que haya que desarrollar los mismos sistemas una y otra vez, que éstos utilicen e integren diferentes tecnologías o que exista una necesidad de comunicación entre sistemas dispares. A todo esto hay que añadirle los continuos cambios en los requerimientos, ya sean impuestos por los usuarios de los sistemas o derivados de los cambios tecnológicos [Schach 2005]. El enfoque tradicional del desarrollo de software no es capaz de absorber toda esta casuística de una forma eficiente, por problemas que vienen derivadas de su propio planteamiento, que se resumirán a continuación. Uno de los principales problemas es la productividad. Los desarrollos como los conocemos están dirigidos por un diseño y una codificación a bajo nivel. El proceso típico de un desarrollo de software, tal y como se muestra en la Figura 2-1 ([Kleppe 2005]), incluye las siguientes fases: Conceptualización y toma de requisitos Análisis y descripción funcional Diseño Codificación Pruebas Implantación

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Ciclo de vida del desarrollo de software tradicional Como se expresa en la figura, las tres primeras fases se centran en generar la documentación y los diagramas que definen el sistema, e incluso en muchos casos, se utiliza UML [OMG UML] para definir los casos de uso, diagramas de clases, de interacción o de actividades. Por el contrario, las tres últimas fases se centran básicamente en la codificación, utilizando como punto de partida la documentación generada previamente. En el momento de iniciar la codificación del software, toda la documentación generada hasta el momento, la utilizan los programadores para poder iniciar su trabajo. Incluso, en el caso de utilizar UML en la fase de análisis, muchas herramientas CASE generan código a partir de los diagramas. El desarrollo tradicional de software trata las fases del ciclo de vida como fases independientes y completas. [Schach 2005], explica gráficamente que si un sistema es un modelo de la realidad, si ésta cambia, el sistema debe cambiar, por lo que los requerimientos pueden modificarse constantemente. Este y otros factores como los errores que se puedan producir por el equipo de desarrollo en las diferentes fases del ciclo de vida, lo que provocan el que haya un proceso iterativo que obligue a volver a la fase de requisitos para volver a revisar todas las fases anteriores. Las iteraciones deben ser completas por muchas razones, pero la principal es el mantenimiento de la documentación, ya que ésta es uno de los valores fundamentales de los sistemas. Un sistema no es sólo el código.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Aproximación MDA

La arquitectura dirigida por modelos (MDA) [Mellor 2004] es una aproximación para el desarrollo de software definido por el OMG. La clave de MDA es la importancia que le da a los modelos en el los procesos de desarrollo. Como se puede observar en la Figura 2-2 ([Kleppe 2005]), que el ciclo de vida de los desarrollos MDA, no es muy diferente del visto en la sección anterior. En realidad, el enfoque de Kleppe se centra en las fases de desarrollo, pero en según el proceso unificado de desarrollo [Jacobson 2001], el ciclo de vida del desarrollo de software se basa en una combinación de incrementos de estas fases. Como ya se ha comentado, se pueden cometer errores en cada una de estas, por lo que es conveniente detectarlos de forma temprana para evitar costes y desviaciones posteriores. Para facilitar esta tarea, lo ideal es abordar los diferentes componentes de un sistema de información (o artefactos) de forma incremental, de manera que en cada incremento se van a realizar todas las fases del ciclo de vida en mayor o menor medida. Cada incremento, será como un pequeño proyecto en el que se ejecutarán las fases de requisitos, análisis, diseño implementación y pruebas. Dentro de cada una de ellas, existirán las iteraciones necesarias para revisar cada artefacto hasta que se complete el incremento y se pueda continuar con el siguiente.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Básicamente los modelos tres tipos de modelos explicados a continuación, son la base de MDA [OMG 2003a]: Modelos independientes del cómputo (CIM): asimilable a los modelos del dominio y/o del negocio del proceso unificado de desarrollo [Jacobson 2001]. Así, por ejemplo, un CIM de una biblioteca hablaría de las entidades persistentes Usuario, Ejemplar, Préstamo, etc. Modelos independientes de la plataforma (PIM): son modelos con un alto nivel de abstracción que son independientes de la tecnología en la que se van a implantar. Describen el sistema desde el punto de vista de los procesos de negocio que van a soportar. Así, un PIM de una biblioteca hablaría de servicios de la aplicación de la biblioteca, de los objetos del negocio Usuario, Ejemplar, Préstamo, etc. Modelos específicos de plataforma (PSM): especifican el sistema en términos de las construcciones que se van a implementar a la hora de desarrollar. Un modelo PIM puede generar distintos modelos PSM, en función de las tecnologías utilizadas. Así, un PSM de una biblioteca hablaría de JSP [SUN JSP], conexiones JDBC [SUN JDBC], etc. Código: la fase final del desarrollo es transformar cada PSM en código. Como cada PSM es relativo a una tecnología determinada esta transformación es, teóricamente, relativamente sencilla.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Proceso unificado de desarrollo. Diagrama de incrementos e iteraciones MDA define los modelos PIM, PSM y el código, así como la manera de relacionarse unos con otros. Los modelos PIM se deben crear, después se deben transformar en uno o varios PSM (el paso más complejo en los desarrollos MDA) y finalmente transformarlo en código. La novedad de MDA frente al desarrollo tradicional, es que las transformaciones se hacen se pueden hacer mediante herramientas que las ejecutan de forma automática. En concreto, la mayor aportación de MDA y su mayor beneficio, es la transformación de modelos PIM a modelos PSM. Las transformaciones, aunque es deseable que se realicen de forma automática mediante herramientas, no siempre se pueden realizar. La portabilidad en MDA se consigue gracias a su propio planteamiento. Siempre se va a partir del mismo PIM y en el caso de tener que migrar el sistema a otra tecnología, sólo será necesario generar el PSM apropiado para la nueva plataforma. Sólo es necesario tener una herramienta que realice la transformación, que puede encontrarse en el mercado para tecnologías con una alta tasa de uso o que haya que construirla, en caso de ser una tecnología poco utilizada.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Interoperabilidad MDA mediante puentes Como hemos visto más arriba, un PIM puede generar uno o varios PSM, en función de las plataformas en las que se vaya a implantar el sistema. El conjunto resultante de PSM, sin embargo, no estarán directamente comunicados entre ellos. Para conseguir la interoperatibilidad, hay que transformar conceptos de una plataforma en los de otra, construyendo lo que en terminología MDA se llaman puentes (bridges). Esta idea está mostrada en la Figura 2-4 ([Kleppe 2005]). En un caso como el del ejemplo, se pueden deducir los elementos relacionados de los PSM, mediante las transformaciones que se deben realizar desde el PIM a cada uno de los PSM resultantes. Como conocemos los detalles técnicos de ambas plataformas, ya que sin ellos no se podrían definir las transformaciones, podemos obtener toda la información necesaria para construir los puentes entre los dos PSM. Lo mismo ocurre a nivel de código. Infraestructura común La infraestructura UML se define por la InfrastructureLibrary que especifica el núcleo (core) del metalenguaje. Define constructores básicos y conceptos comunes que se reutilizan para definir varios metalenguajes, tales como MOF o CWM, a parte del propio UML. También tiene el objetivo de alinear arquitectónicamente MOF y UML con el fin de poder reutilizar los mismos metamodelos para ambos lenguajes. Por último, esta librería también permite una personalización de UML mediante perfiles que facilitan la creación de nuevos lenguajes basados en el mismo core.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

La InfrastructureLibrary es un paquete que está compuesto a su vez por los paquetes Core y Profiles.

El paquete Core es un metamodelo completo diseñado para una alta reusabilidad, de manera que permita extender metamodelos descritos en MOF en el mismo metanivel, mediante la utilización o especialización de sus metaclases. Tal es el caso de UML, CWM y MOF que todas dependen de un núcleo común, tal y como se muestra en la Figura 3-1 ([OMG 2007a]). El paquete Core, por lo tanto, es el corazón que sustenta toda la arquitectura de la aproximación MDA. Papel del núcleo común El paquete Profiles depende del paquete Core y define los mecanismos que se usan para personalizar metamodelos existentes centrándose en plataformas específicas o dominios particulares. Si se desea extender un metamodelo, como es el caso de UML, se puede especificar un perfil partiendo de este paquete y generar un nuevo lenguaje de modelado específico y personalizado. Se puede considerar como un mecanismo de extensión ligero de los metamodelos definidos con MOF alternativo al metamodelado, ya que es mucho más cómodo ampliar el metamodelo que crear uno completamente nuevo. Además la ventaja es que, como se indica en la Figura 3-2 ([OMG 2007a]), con Profiles se puede extender un metamodelo definido en MOF sin variar su definición original.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Extensión de un metamodelo mediante Profiles En este ejemplo se ve que MiMetamodelo es un metamodelo que contiene dos metaclases. MiPerfil es un perfil que referencia a MiMetamodelo y a una de sus clases (Metaclase1). Sin embargo hay una referencia explícita a Metaclase2 que anula la referencia al metamodelo. La aplicación de MiPerfil sobre algún modelo basado en MiMetamodelo, mostrará instancias de Metaclase2 (porque está explícitamente referenciada mediante una referencia de metaclase). También estarán visibles las instancias de Metaclase1 que son extendidas por una instancia de MiEstereotipo. Sin embargo, las instancias de Metaclase1 que no se extienden por MiEstereotipo permanecerán ocultas. Unified Model Language (UML) UML [Booch 2005] es un lenguaje estándar para visualización, especificación, construcción y documentación de sistemas software y otros sistemas no software. Representa una colección de buenas prácticas que proporcionan un éxito acreditado en el modelado de grandes y complejos sistemas [OMG 2005a]. Fusiona conceptos de las metodologías de Booch [Booch 2007], de OMT (Object Modeling Technique) [Rumbaugh 1996] y de OOSE (Object-Oriented Software Engineering) [Jacobson 1996] consiguiendo como resultado un lenguaje de modelado común, sencillo y ampliamente utilizado por los usuarios de éstos y otros métodos de desarrollo, ampliando sus posibilidades. Por ejemplo, UML puede modelar sistemas concurrentes y distribuidos. Los grandes objetivos que se persiguen con UML son los siguientes: Proveer a los usuarios de un lenguaje de modelado fácil de usar y visual para el desarrollo de modelos. Proporcionar mecanismos de especialización y extensión de conceptos elementales del Core. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Soportar especificaciones independientes de lenguajes de programación y procesos de desarrollo específicos. Alentar a la industria para aportar nuevas herramientas al mercado. Soportar conceptos de desarrollo de alto nivel como componentes, colaboraciones, entornos de trabajo y patrones. Integrar las buenas prácticas en los procesos de desarrollo. La especificación del lenguaje UML está basada en la aproximación de metamodelado, por lo que se sitúa en el nivel M2 de la arquitectura MDA. La definición de UML está basada en los siguientes principios de diseño [OMG 2007a]: Modularidad: que se consigue agrupando constructores en paquetes y organizando aspectos comunes en metaclases. Estratificación: la división en capas se aplica de dos formas en el metamodelo UML. La primera es la estructura de los paquetes que se estratifica para separar los constructores, que forman el núcleo (core) del metalenguaje, de los constructores de alto nivel que los usan. En segundo lugar, el patrón de la arquitectura de cuatro capas se aplica para separar aspectos en diferentes niveles de abstracción. División en partes: se organizan en partes diferentes áreas conceptuales dentro de la misma capa. Extensibilidad: UML se puede extender de dos maneras. Mediante el uso de perfiles (profiles) se pueden crear nuevos dialectos, adaptando construcciones a plataformas o dominios específicos. Reutilizando parte del paquete InfraestructureLibray para aumentarlo con nuevas metaclases y metarrelaciones y así crear un nuevo lenguaje de modelado relacionado con UML, que estrictamente sería ya un metamodelo diferente. Reusabilidad: la reusabilidad se consigue mediante librerías de metamodelado flexibles que permitan definir metamodelos como el UML o como otros relacionados, tales como MOF (Meta Object Facility) o CWM (Common Warehouse Metamodel), que se verán más adelante. El metamodelo de UML se define en UML Superstructure [OMG 2007b], metamodelo descrito en MOF y que a su vez está basado también el paquete Core, como se ha comentado en el apartado anterior. El paquete UML proporciona los constructores a nivel de usuario y se compone de diferentes paquetes que se encargan de gestionar los diferente modelos estáticos (o de estructura) y dinámicos (o de comportamiento).

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Paquetes UML que soportan modelos estructurales y de comportamiento UML Profiles Como ya hemos comentado, UML Infrastructure define la posibilidad de extender UML de manera que se pueda crear un nuevo lenguaje de modelado sin necesidad de definirlo modificando su metamodelo definido en MOF. Este mecanismo lo proporcionan los perfiles UML (Profiles) y lo que permiten es aplicar a UML nuevas especificaciones añadiendo nuevos tipos de elementos del lenguaje o restricciones al mismo. Este mecanismo lo proporciona el paquete Profiles el cual define los mecanismos para extender y adaptar las clases de un metamodelo cualquiera descrito en MOF a diferentes propósitos o necesidades concretas, tales como los demandados por diferentes plataformas (como pueden ser J2EE o .NET) o dominios de aplicación (como los de tiempo real, modelado de procesos de negocio, etc.). [OMG 2007a] señala varias razones por las que se puede necesitar personalizar un metamodelo: Disponer de una terminología propia que se adapte a una plataforma particular o un dominio de aplicación.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Dotarse de una sintaxis para construcciones que no cuentan con una notación propia (como es el caso de las acciones). Obtener nuevas notaciones para símbolos ya existentes para adaptarlas al dominio de aplicación. Añadir semántica no especificada en el metamodelo Añadir restricciones al metamodelo de manera que acoten el uso del metamodelo y sus constructores. Añadir información útil para la realización de transformaciones entre modelos. Un perfil se define en un paquete UML estereotipado «profile» que extiende a un metamodelo o a otro perfil. Los mecanismos para definir los perfiles son tres: estereotipos (stereotypes), restricciones (constraints) y valores etiquetados (tagged values) [Fuentes 2004]. Un estereotipo viene definido por un nombre y por una serie de metamodelos sobre los que puede asociarse. Gráficamente, los estereotipos se definen dentro de cajas estereotipas «stereotypes» que se asocian con las metaclases que va a extender, según la Figura 3-4 ([Fuentes 2004]), el perfil UML WeighthsAndColors define dos estereotipos: Colored y Weighed que se asocian a las metaclases Class y Association el primero y sólo a Association el segundo. Las restricciones son condiciones que se aplican a los estereotipos. En concreto a los elementos del metamodelo que han sido estereotipados. En el ejemplo de la Figura 3-4, se puede imponer la restricción de que si dos o más clases están unidas por una asociación coloreada, el color de las clases debe coincidir con el de la asociación. Estas restricciones suelen escribirse con el lenguaje OCL. Un valor etiquetado es una meta-atributo adicional que se asocia a una metaclase del metamodelo extendido por un perfil. Todo valor etiquetado deberá tener un nombre y un tipo y deberá estar asociado a un determinado estereotipo. En el ejemplo de la Figura 3-4 el estereotipo Weighed tiene un valor etiquetado Weight de tipo integer que indicará el peso de cada asociación que haya sido estereotipada como Weighed. Los valores etiquetados se representan como atributos de la clase que define el estereotipo.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

EJEMPLO DE PERFIL UML Meta Object Facility (MOF) MOF es un estándar de OMG que provee de un marco de trabajo de gestión de metadatos y de un conjunto de servicios para permitir el desarrollo de la interoperabilidad de sistemas dirigidos por modelos y metadatos [OMG 2006a]. Muchas de las tecnologías estandarizadas por OMG (UML, el propio MOF, CWM, SPEM, XMI y varios perfiles UML) usan MOF y sus tecnologías derivadas para un intercambio dirigido por metadatos y la manipulación de los mismos. Así mismo, MOF introduce el concepto de los modelos independientes de plataforma de metadatos, además del mapeo de estos PIM a plataformas específicas.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Meta niveles de MOF y UML Como se muestra en la Figura anterior, en la arquitectura de metamodelado de cuatro capas MOF estaría situado a nivel del meta-meta modelo (M3), ya que con él, como hemos viso, se definen los meta modelos situados en el nivel M2. No obstante, desde su primera versión, MOF ha estado íntimamente ligado a UML, debido al alineamiento arquitectónico derivado de compartir el mismo core. Uno de los mayores éxitos de la infraestructura común es precisamente este alineamiento. Mediante el paquete Core se consigue que todos los elementos del meta modelo sean compartidos por UML y MOF. No obstante, UML se define como un modelo descrito mediante un metamodelos MOF. Es decir, cada elemento de UML es una instancia de un elemento del modelo de MOF. Este alineamiento es posible porque la InfrastructureLibrary UML se usa en ambos metaniveles. El hecho de que tanto MOF como UML tengan en común la InfrastructureLibrary, incluye los siguientes beneficios: Simplifica las reglas para el modelado de metadatos Las tecnologías de mapeos de MOF (XMI, JMI, etc.), se pueden aplicar a los modelos UML, incluidos los perfiles UML. Permite un amplio abanico de herramientas para el metamodelado, ya que cualquier herramienta UML se podrá utilizar para modelar metadatos fácilmente Además de estos beneficios, MOF incluye una serie de paquetes que facilitan la consecución de las capacidades de reutilización de MOF desde otros modelos o metamodelos. Estos paquetes son los descritos a continuación: Reflection: que extiende un modelo con la habilidad de ser autodescriptivo. Identifiers: que provee una extensión para objetos del metamodelo identificados excepcionalmente, sin contar con el dato del modelo que puede ser sujeto de cambio. Extensión: un simple significado para extensiones de elementos del modelo con el par nombre – valor. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Ahora veamos un esquema completo de MDA

Ejercicios de autoevaluación Explique claramente por medio de un cuadro paralelo las ventajas, desventajas, diferencias y características sobre los diferentes FrameWorks. Aplique el modelo MDA completamente al ejercicio planteado para la Unidad 1

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

6. ASPECTOS OBJETIVO GENERAL Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos. OBJETIVOS ESPECÍFICOS Identificar e implementar los parámetros sobre diferenciadores entre los lenguajes por objetos y lenguajes por aspectos Crear ambientes de desarrollo aplicando las metodologías por aspectos Apropiar las principales características de las Bases de Datos orientadas a aspectos.

6.1. Relación de conceptos

6.2. Prueba Inicial Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su grado de asimilación ¿Qué significan las siglas POA, LOA? ¿Qué propiedades debe satisfacer el LOA? ¿En el este contexto y en sus palabras defina lo que es un aspecto? ¿Qué lenguajes orientados a aspectos puedes indicar?

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

6.3. Definiciones Básicas La idea central que persigue la POA es permitir que un programa sea construido describiendo cada concepto separadamente. El soporte para este nuevo paradigma se logra a través de una clase especial de lenguajes, llamados lenguajes orientados a aspectos (LOA), los cuales brindan mecanismos y constructores para capturar aquellos elementos que se diseminan por todo el sistema. A estos elementos se les da el nombre de aspectos. Una definición para tales lenguajes sería: Los LOA son aquellos lenguajes que permiten separar la definición de la funcionalidad pura de la definición de los diferentes aspectos. Los LOA (Lenguajes Orientados a Aspectos) deben satisfacer varias propiedades deseables, entre ellas: - Cada aspecto debe ser claramente identificable. - Cada aspecto debe auto-contenerse. - Los aspectos deben ser fácilmente intercambiables. - Los aspectos no deben interferir entre ellos. - Los aspectos no deben interferir con los mecanismos usados para definir y evolucionar la funcionalidad, como la herencia. ¿Qué es un aspecto? Gregor Kickzales y su grupo, Lo que propone es agrupar los lenguajes orientados a objetos, los procedurales y funcionales como lenguajes de procedimiento generalizado (LPG), ya que sus mecanismos claves de abstracción y composición pueden verse como agrupados bajo una misma raíz. Esa raíz tendría la forma de un procedimiento generalizado. Los métodos de diseño que han surgido para los LPG tienden a dividir el sistema en unidades de comportamiento o funciones. A este estilo se lo conoce como descomposición funcional (si bien la naturaleza exacta de la descomposición funcional difiere entre los paradigmas, para los propósitos de este trabajo alcanza con agruparlos bajo LPG). En general, decimos que dos propiedades se entrecruzan si al implementarse deben componerse de manera diferente, y aún deban ser coordinadas. Esto se debe a que tienen un comportamiento en común. Al proveer los LPG solamente un único medio de composición, es el programador quien debe realizar la tarea extra deco-componer manualmente las propiedades que se entrecruzan, lo cual lleva a un oscurecimiento y a un aumento de la complejidad del código. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Al momento de implementar una propiedad, tenemos que la misma tomará una de las dos siguientes formas: 1. Un componente: si puede encapsularse claramente dentro de un procedimiento generalizado. Un elemento es claramente encapsulado si está bien localizado, es fácilmente accesible y resulta sencillo componerlo. 2. Un aspecto: si no puede encapsularse claramente en un procedimiento generalizado. Los aspectos tienden a ser propiedades que afectan la performance o la semántica de los componentes en forma sistemática (Ejemplo: sincronización, manejo de memoria, distribución, etc.) A la luz de estos términos, podemos enunciar la meta principal de la POA: brindar un contexto al programador que permita separar claramente componentes y aspectos, separando componentes entre sí, aspectos entre sí, y aspectos de componentes, a través de mecanismos que hagan posible abstraerlos y componerlos para producir el sistema completo. Tenemos entonces una importante y clara diferencia respecto de los LPG, donde todos los esfuerzos se concentran únicamente en los componentes, dejando de lado los aspectos. Una vez diferenciados los aspectos de los componentes, estamos en condiciones de definir a un aspecto como un concepto que no es posible encapsularlo claramente, y que resulta diseminado por todo el código. Los aspectos son la unidad básica de la programación orientada a aspectos. Una definición más formal, y con la que se trabaja actualmente es: Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de implementación es una unidad modular del programa que aparece en otras unidades modulares del programa. Dicha definición pertenece al creador de la POA, Gregor Kickzales. Ahora que ya hemos introducido los principales rasgos de la POA, podemos comparar la forma de una implementación basada en los LPG versus implementación basada en POA.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Implementación POA versus LPG Fundamentos de la POA Los tres principales requerimientos de la POA son: Un lenguaje para definir la funcionalidad básica, conocido como lenguaje base o componente. Podría ser un lenguaje imperativo, o un lenguaje no imperativo (C++, Java, Lisp, ML). Uno o varios lenguajes de aspectos, para especificar el comportamiento de los aspectos. (COOL, para sincronización, RIDL, para distribución, AspectJ, de propósito general.) Un tejedor de aspectos (Weaver), que se encargará de combinar los lenguajes. Tal proceso se puede retrasar para hacerse en tiempo de ejecución o en tiempo de compilación. Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para encapsular aquellos conceptos que cruzan todo el código. Estructura general La estructura de una implementación basada en aspectos es análoga a la estructura de una implementación basada en los LPG. Una implementación basada en LPG consiste en: Un lenguaje. Un compilador o intérprete para ese lenguaje. Un programa escrito en ese lenguaje que implemente la aplicación. Veamos a continuación una gráfica de los LPG Una implementación basada en POA consiste en: Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El lenguaje base o componente para programar la funcionalidad básica. Uno o más lenguajes de aspectos para especificar los aspectos. Un tejedor de aspectos para la combinación de los lenguajes. El programa escrito en el lenguaje componente que implementa los componentes. Uno o más programas de aspectos que implementan los aspectos. Visualicemos, por medio de una gráfica

Estructura de POA

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Desarrollo orientado a aspectos Diseñar un sistema basado en aspectos requiere entender qué se debe incluir en el lenguaje base, qué se debe incluir dentro de los lenguajes de aspectos y qué debe compartirse entre ambos lenguajes. El lenguaje componente debe proveer la forma de implementar la funcionalidad básica y asegurar que los programas escritos en ese lenguaje componente no interfieran con los aspectos. Los lenguajes de aspectos tienen que proveer los medios para implementar los aspectos deseados de una manera intuitiva, natural y concisa. En general el desarrollo de una aplicación basada en aspectos consiste de tres pasos: 1- Descomposición de aspectos: es descomponer los requerimientos para distinguir aquellos que son componentes de los que son aspectos. 2- Implementación de requerimientos: implementar cada requerimiento por separado. 3- Recomposición: dar las reglas de recomposición que permitan combinar el sistema completo. En un reporte técnico de la Universidad de Virginia, se establece que muchos de los principios centrales a la POO son ignorados dentro del diseño orientado a aspectos, como por ejemplo el ocultamiento de información, debido a que los aspectos tienen la habilidad de violar estos principios. Para esto se propone una filosofía de diseño orientada a aspectos que consiste de cuatro pasos: Un objeto es algo. Un aspecto no es algo. Es algo sobre algo. Los objetos no dependen de los aspectos. Los aspectos representan alguna característica o propiedad de los objetos, pero no tienen control sobre los mismos. Un objeto es algo: un objeto existe por sí mismo, es una entidad. Un aspecto no es algo. Es algo sobre algo: un aspecto se escribe para encapsular un concepto entrecruzado. Por definición un aspecto entrecruza diferentes componentes, los cuales en la POO son llamados objetos. Si un aspecto no está asociado con ninguna clase, entonces entrecruza cero clases, y por lo tanto no tiene sentido en este contexto. Luego, para que un aspecto tenga sentido debe estar asociado a una o más clases; no es una unidad funcional por sí mismo. Los objetos no dependen de los aspectos: Un aspecto no debe cambiar las interfaces de las clases asociadas a él. Solo debe aumentar la implementación de dichas interfaces. Al afectar solamente la implementación de las clases y no sus interfaces, la encapsulación no se rompe. Las clases Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

mantienen su condición original de cajas negras, aun cuando puede modificarse el interior de las cajas. Los aspectos no tienen control sobre los objetos: Esto significa que el ocultamiento de información puede ser violado en cierta forma por los aspectos porque éstos conocen detalles de un objeto que están ocultos al resto de los objetos. Sin embargo, no deben manipular la representación interna del objeto más allá de lo que sean capaz de manipular el resto de los objetos. A los aspectos se les permite tener esta visión especial, pero debería limitarse a manipular objetos de la misma forma que los demás objetos lo hacen, a través de la interface.

6.4. Lenguajes orientados a aspectos A continuación describiremos informalmente algunos lenguajes orientados a aspectos disponibles actualmente. En la sección 3.9 estudiaremos con mayor profundidad el lenguaje orientado a aspectos AspectJ, ya que hemos seleccionado este lenguaje por ser la herramienta con mayor usabilidad, futuro, popularidad y desarrollo. JPAL La principal característica de esta herramienta es que los puntos de enlace son especificados independientemente del lenguaje base. Estos puntos de enlace independientes reciben el nombre de Junction Point (JP). Por lo tanto la herramienta se llama JPAL que significa Junction Point Aspect Language, esto es, Lenguaje de Aspectos basados en JP. Usar programas escritos en JPAL para describir nuevos lenguajes de aspectos facilita para ese lenguaje el desarrollo de tejedores. De hecho, el tejedor JPAL genera un esquema del tejedor de aspectos llamado Esquema del Tejedor. Este esquema tiene un mecanismo que automáticamente conecta el código base con los programas de aspectos en puntos de control llamados acciones. El código que agrega el Esquema del Tejedor invoca, cuando es alcanzado en ejecución, las acciones correspondientes para permitir la ejecución de los programas de aspectos. Esto permite una vinculación dinámica con los programas de aspectos, lo cual hace posible modificar en tiempos de ejecución los programas de aspectos. Sin embargo, esta solución no es lo suficientemente poderosa como para agregar o reemplazar programas de aspectos en ejecución. Para tal efecto se agrega al Esquema del Tejedor una entidad llamada Administrador de Programas de Aspectos (APA), el cual puede registrar un nuevo aspecto de una aplicación y puede llamar a métodos de aspectos registrados. Es implementado como una librería dinámica que almacena los Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

aspectos y permite dinámicamente agregar, quitar o modificar aspectos, y mandar mensajes a dichos aspectos. La comunicación entre el Administrador y el Esquema del Tejedor se logra a través de un Protocolo de Comunicación entre Procesos que permite registrar aspectos dinámicamente.

Arquitectura JPAL Resumiendo, JPAL, un descendiente de AspectJ, tiene la particularidad de separar los puntos de enlace, que son independientes del lenguaje base, de sus acciones asociadas que dependen de decisiones de implementación. Esta separación permite generar un Esquema de Tejedor para cualquier lenguaje de aspectos. Este esquema ofrece un puente entre el control de la ejecución y la ejecución de la acción. Tomando ventaja de esta redirección se obtiene un modelo de arquitectura para el manejo dinámico de aspectos. Su principal aplicación es para la implementación de sistemas distribuidos. D D es un ambiente de lenguajes de aspectos para la programación distribuida. Se llama ambiente de lenguajes, en vez de solamente lenguaje, porque consiste en realidad de dos lenguajes: COOL, para controlar la sincronización de hilos(threads), y RIDL, para programar la interacción entre componentes remotos. Estos dos lenguajes se diseñaron de manera independiente de un lenguaje componente. Sin embargo establecen un número de condiciones sobre el lenguaje componente. Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El diseño de D es semi-independiente del lenguaje componente, ya que D impone requerimientos sobre el lenguaje componente que satisfacen naturalmente los lenguajes orientados a objetos. Luego el lenguaje componente puede ser cualquiera mientras sea orientado a objetos. Por lo tanto, en teoría podría ser implementado con C++, Smalltalk, CLOS, Java o Eiffel. Cristina Lopez, principal diseñadora del lenguaje, implementó D sobre Java llamando al lenguaje resultante DJ. Con respecto a la herencia, los módulos de aspectos se relacionan con la herencia de clases a través de simples reglas: Sea C una clase y A el módulo de aspecto asociado a C, se verifican las siguientes propiedades: Visibilidad de campos: Los elementos heredados desde ancestros de C son visibles a A. No hay propagación de efectos: A no afecta a ninguna superclase de C. Redefinición de semántica: A redefine completamente cualquier módulo de aspecto del mismo tipo definido en una superclase de C. No hay ninguna relación entre A y los módulos de aspectos de las superclases de C. - Herencia de coordinación: A afecta todas las subclases de C que no tienen asociado un módulo de aspecto del mismo tipo. A no afecta los nuevos métodos definidos en una subclase de C. Si un método mdeclarado en C es redefinido por una subclase de C sin asociarle otromódulo de aspecto del mismo tipo entonces A también es el aspecto para ese método. No es posible para los módulos de aspectos referir a otro módulo de aspecto, como consecuencia no es posible establecer ninguna relación entre los módulos de aspectos, incluyendo a la herencia. COOL COOL (COOrdination aspect Language) es un lenguaje de aspectos de dominio específico para tratar con la exclusión mutua de hilos, sincronización, suspensión y reactivación de hilos. Un programa COOL consiste de un conjunto de módulos coordinadores. Los módulos coordinadores, o directamente coordinadores, se asocian con las clases a través del nombre. Un mismo coordinador puede coordinar a más de una clase. La unidad mínima de sincronización es el método. La declaración de un coordinador describe la estrategia de coordinación. Los coordinadores no son clases: utilizan un lenguaje diferente, no pueden ser instanciados y sirven para un propósito muy específico. Los coordinadores se asocian automáticamente con las instancias de clases que coordinan en tiempo de instanciación, y durante el tiempo de vida de los objetos esta relación tiene un protocolo bien definido.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

El cuerpo de un coordinador contiene declaración de variables de condición y ordinarias, un conjunto de métodos auto-exclusivos, varios conjuntos de métodos mutuamente exclusivos y manejadores de métodos. Los métodos nombrados en el cuerpo deben ser métodos válidos de las clases coordinadas. Un coordinador asociado a una clase C tiene la siguiente visibilidad: Todos los métodos públicos, protegidos y privados de C. Todos los métodos no privados de las superclases de C. Todas las variables privadas, protegidas y públicas de C. Todas las variables no privadas de las superclases de C. La siguiente figura describe el protocolo de comunicación entre un coordinador y un objeto:

Protocolo de comunicación de un coordinador en COOL RIDL RIDL (Remote Interaction and Data transfers aspect Language) es un lenguaje de aspectos de dominio específico que maneja la transferencia de datos entre diferentes espacios de ejecución.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Un programa RIDL consiste de un conjunto de módulos de portales. Los módulos de portales o directamente portales se asocian con las clases por el nombre. Un portal es el encargado de manejar la interacción remota y la transferencia de datos de la clase asociada a él, y puede asociarse como máximo a una clase. La unidad mínima de interacción remota es el método.

Protocolo de comunicación de un portal en RIDL Tenemos otros lenguajes POA ASPECTC ASPECTS ASPECTC++ MALAJ HYPERJ A continuación veamos un resumen de estas herramientas

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

Ejercicio de autoevaluación De acuerdo a todos los temas vistos y analizados en esta unidad, se pide realizar el siguiente trabajo que abarca los siguientes numerales de manera óptima y clara: 1. Interacción entre aspectos en aplicaciones AOP (EA, IMP) 2. ¿Qué es un aspecto a nivel arquitectónico? (EA, ARQ) 3. Los aspectos identificados en la especificación de requisitos son luego aspectos a nivel arquitectónico? 4. Significado de las relaciones de weaving en el modelo de objetivos. ¿Qué técnicas pueden ser utilizadas para especificar el weaving en early aspects. 5. Identificación de aspectos en la especificación de requisitos/objetivos. 6. Conceptos reales de DSOA ¿Están demasiado influenciados por AspectJ? 7. Derivación de arquitecturas (¿AO?) de una especificación orientada a aspectos. 8. ¿Qué es un aspecto a nivel arquitectónico? (EA, ARQ) 9. Los aspectos identificados en la especificación de requisitos son luego aspectos a nivel arquitectónico? 10. Varias opciones de diseño vivas a lo largo del ciclo de vida. ¿Ventajas? 11 Aspectos asociados a conectores Vs aspectos asociados a componentes 12. ¿Son diferentes los aspectos arquitectónicos? 13. Derivación de arquitecturas (¿AO?) de una especificación orientada a aspectos. 14. Hasta qué nivel MDA se mantiene la separación?

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

7. PISTAS DE APRENDIZAJE Tenga presente: Dentro de un procesos unificado de desarrollo, deben tenerse muy pendientes y bien estructuradas las diferentes fases y etapas propuestas por el modelo UML. Tener en cuenta: Al diseñar y desarrollar software para la web, los Principios planteados para ello en éste módulo, son determinantes de su eficiencia, eficacia y funcionalidad Traer a la memoria: Que las reglas del negocio están determinadas por las necesidades y parámetros sobre los cuales debe levantarse el diseño del software a desarrollar. Tenga presente: Los diferentes diagramas mostrados son solo guías de solución a posibles necesidades presentadas en la cotidianidad del desarrollo de software. Tener en cuenta: Los patrones son modelos a seguir que han sido probados y aprobados en escenario específicos, pero no constituyen como tal una solución estandarizada a una situación de desarrollo. Traer a la memoria: Que los diferentes procesos y patrones de modelamiento serán efectivos en la medida que se usen en los escenarios más adecuados para ello. Tenga presente: UML es un lenguaje para interpretar sistemas mediante gráficos o texto obteniendo modelos explícitos para a la comunicación durante el desarrollo al ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño Tener en cuenta: Que una restricción se representa como una cadena encerrada entre llaves y colocada junto al elemento asociado o conectada a los elementos con relación de dependencia. Tenga presente: Que los valores etiquetados se representa como una cadena encerrada entre llaves y colocada bajo el nombre de otro elemento. Traer a la memoria: usar las notas para suministrar restricciones o comentarios vinculados a un elemento o a una colección de elementos.

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

8. GLOSARIO FRAMEWORK: Estructura software compuesta de componentes personalizables e intercambiables

UML: Lenguaje de Modelamiento Unificado (Unified Model Language) MOF: Estándar de OMG que provee un marco de trabajo de gestión de metadatos JPAL: Junction Point Aspect Language D: ambiente de lenguajes de aspectos para la programación distribuida COOL: Coordination aspect Language, Coordinación de Aspectos del lenguaje RIDL: Remote Interaction and Data transfers aspect Language: Interacción Remota y Transferencia de Datos en lenguajes orientados a aspectos. LOA: Lenguaje de programación Orientado a Aspectos POA: Programación Orientada a Aspectos MALAJ: Modularización de aspectos de sincronización y relación

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia

Dirección de Educación a Distancia y Virtual Ingeniería de Sistemas Asignatura: Arquitectura del Software

9. BIBLIOGRAFÍA SÁNCHEZ PÉREZ Javier, Metodologías de Desarrollo Software Facultad de Informática, 1998, GARCÍA MOLINA Jesús Ignacio, Departamento de Informática y Sistemas, 2004, Univ. De Murcia. REYNOSO Billy, Arquitectura para distribución y agregación: Services Oriented Architecture (SOA) 2006, U. Buenos Aires CARMONA VANEGAS Juan de Dios, Web Services en paralelo con SOA , implementaciones, 2010 CESDE, CARMONA VANEGAS Juan de Dios, Diagramas de casos de uso de los ejercicios que realizados para proyectos de producción, 2011, CESDE. WEBGRAFÍA www.monografías.com, Arquitectura de Desarrollo de Software, tomado el 4 de Noviembre 2011 www.wikipedia.com www.Lawebdelprogramador.com

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington Página Web: www.remington.edu.co - Medellín - Colombia