informe tesis

Universidad de La SerenaFacultad de Ciencias

Departamento de Matemáticas

Estudio y Análisis de Arquitecturas de Software y Patrones de Diseño, con el

propósito de determinar potencialidades y restricciones.

Caso de Estudio: Propuesta de una Arquitectura para soporte de la Docencia en la Universidad de La Serena.

Memoria presentada en conformidad a los requisitos para obtener el título de

Ingeniero en Computación

Profesor GuíaMg. Raúl Gómez González

Profesor CoreferenteDr. Raúl Monge Anwandter

Gustavo Esteban Gatica González

** *****

La Serena, 2006

Evaluación Memoria de Título

uego de haberse cumplido hoy, ____ de mayo de 2006, con la defensa oral que establece el Reglamento Interno para optar al Título de Ingeniero en Computación, en lo que respecta a la Memoria de Título del Señor Gustavo Gatica G.

La Comisión Examinadora, integrada por los profesores: Mg. Raúl Gómez G., Lic. Guillermo Leyton G., y Dr. Ing. Raúl Monge A.; ha otorgado las siguientes calificaciones:

Informe Final: ___ promedio, cuyo 50% corresponde a ___

Defensa Oral: ___ promedio, cuyo 50% corresponde a ___

De lo anterior se desprende que la Nota de Memoria de Título corresponde a:

Sr. Ingeniero Gustavo Gatica G. ( ___, ____)

2

AGRADECIMIENTOS

A mi familia agradezco el incesante apoyo que durante estos largos años. Sin ellos hubiese sido imposible llegar a estas instancias. Hoy que una etapa se ha cumplido, es el momento de ser un agradecido de la vida y de la familia que el Gran Hacedor me ha brindado, y a mi abuelita de la cual solo me queda su nombre y su recuerdo le debo los valores y las ganas de luchar hasta estos momentos, ella me ha dado la luz de la sabiduría para poder avanzar en paso regulado y acompasado por este camino de perfeccionamiento. A mi compañera, Carolina que siempre confió en mí y me dio las esperanza de un futuro mejor.

En segundo lugar, agradezco al Departamento de Matemáticas por haberme dado la confianza y la responsabilidad de ser uno de sus eslabones, como si fuese una espiga de trigo, de la cual una de sus semillas, ha caído en la buena tierra, y ahora ha dado uno de sus frutos.

3

DEDICATORIA

Dedico este trabajo mi familia a la cual les agradezco este segundo paso, por su apoyo constante durante estos largos años. Sin ellos hubiese sido imposible llegar a estas instancias, y a mi abuelita de la cual solo me queda su nombre y su recuerdo le debo los valores y las ganas de luchar hasta estos momentos, ella me ha dado la luz de la sabiduría para poder avanzar en paso regulado y acompasado por este camino de perfeccionamiento. A mi compañera, Carolina que siempre confió en mí y me dio las esperanza de un futuro mejor.

En segundo lugar, agradezco al Departamento de Matemáticas por haberme dado la confianza y la responsabilidad de ser uno de sus eslabones, como si fuese una espiga de trigo, de la cual una de sus semillas, ha caído en la buena tierra, y ahora ha dado uno de sus frutos.

4

RESUMEN

****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************.

ABSTRACT

******************************************************************************************************************************************************************************************************************************************************************************************************************************************.

******************************************************************************************************************************************************************************************************************************************************************************************************************************************n.

******************************************************************************************************************************************************************************************************************************************************************************************************************************************.

ÍNDICE

ÍNDICE............................................................................................................................................... 2Índice de Tablas y Figuras...............................................................................................................6INTRODUCCIÓN............................................................................................................................... 1CAPÍTULO 1: ARQUITECTURA DE SOFTWARE.............................................................................3

1. Introducción........................................................................................................................... 32. Historia de la Arquitectura de Software.................................................................................43. Definiciones Formales de Arquitectura de Software............................................................113.1. Mary Shaw y David Garlan..............................................................................................113.2. Bass, Clements y Kazman..............................................................................................113.3. IEEE Estandard 1471:2000.............................................................................................123.4. Alan Cooper....................................................................................................................123.5. Steve McConnell.............................................................................................................123.6. Perry and Wolfe..............................................................................................................123.7. Frank Buschmann...........................................................................................................133.8. Kruchten.......................................................................................................................... 133.9. Paul G. Basset................................................................................................................134. Lenguajes de Descripción de Arquitecturas, ADLS..............................................................134.1. Especificaciones de los ADLS.........................................................................................174.1.1. Propiedades Extra - funcionales de los Componentes (NFR).....................................174.1.2. Naturaleza de las interacciones entre componentes..................................................175. ¿Arquitectura de Software, una Ciencia o Disciplina?.........................................................176. Ingenierizando las Arquitecturas de Software.....................................................................187. Lenguaje de Representación de ArquitecturaS de Software (SARL)..................................188. Estilo, Patrón o Idioma Arquitectónico.................................................................................198.1. Definición semiformal de Estilo Arquitectural..................................................................208.2. Identificación de un Estilo Arquitectural...........................................................................208.3. Resumen de la clasificación propuesta por David Garlan...............................................208.3.1. Pipeline, Tubos y Filtros..............................................................................................218.3.2. Datos Abstractos y Organización Orientada a Objetos...............................................228.3.3. Invocación Implícita, Dirigida por Eventos..................................................................228.3.4. Repositorio..................................................................................................................238.3.5. Table Driven Interpreters (Intérprete conducido por Tablas).......................................248.3.6. Niveles o Capas..........................................................................................................258.3.7. Arquitectura de Procesos Distribuidos........................................................................268.3.8. Arquitectura de Rutinas y subrutinas..........................................................................268.3.9. Arquitecturas de Software para Domínios Específicos...............................................278.3.10. Sistemas de Transición de Estados............................................................................278.3.11. Sistemas de Control de Procesos...............................................................................278.3.12. Arquitecturas Heterogéneas.......................................................................................278.4. EL rol de UML.................................................................................................................289. Campos de Acción de las Arquitecturas de Software..........................................................3110. Modalidades y Tendencias..............................................................................................3310.1. Arquitectura como etapa de Ingeniería y diseño Orientado a Objetos........................3310.2. Arquitectura Estructural, basada en un modelo estático de estilos, ADLs y vistas.....3410.3. Estructuralismo Arquitectónico Radical.......................................................................3510.4. Arquitectura basada en Patrones................................................................................3510.5. Arquitectura Orientada al Proceso o Arquitectura Procesual......................................3610.6. Arquitectura basada en Escenarios............................................................................3610.7. Ideas Complementarias y Conclusiones.....................................................................3711. Aspectos que debe considerar una Arquitectura de Software.........................................3811.1. Comprensión de la Arquitectura..................................................................................38

2

11.2. Reutilización................................................................................................................3911.3. Construcción...............................................................................................................3911.4. Evolución....................................................................................................................3911.5. Análisis....................................................................................................................... 3911.6. Gerencia o Administración..........................................................................................4011.7. Comunicación.............................................................................................................4012. La importancia de las Arquitecturas de Software hoy en día..........................................4013. Problemas latentes de las Arquitecturas de Software.....................................................4214. EL Rol del Arquitecto de Software...................................................................................4514.1. Análisis Arquitectónico:...............................................................................................4714.2. Construir y determinar la vialidad de un Modelo Conceptual:.....................................4714.3. Priorizar los casos de uso...........................................................................................4814.4. Identificar mecanismos y elementos para el diseño....................................................4814.5. Incorporar elementos de diseños existentes...............................................................4914.6. Estructurar el modelo de implementación...................................................................4914.7. Describir la arquitectura en tiempo de ejecución........................................................4914.8. Ser capaz de describir la distribución de la arquitectura.............................................5014.9. Desarrollar guías de programación y diseño...............................................................5015. Revisión de una Arquitectura de Software.....................................................................5116. Documentación de una Arquitectura de Software, SAD..................................................5416.1. Vista de Casos de Uso...............................................................................................5616.2. Vista Lógica................................................................................................................5616.3. Vista de Proceso.........................................................................................................5716.4. Vista de Implementación.............................................................................................5816.5. Vista de Datos.............................................................................................................5816.6. Vista de Despliegue....................................................................................................5916.7. Tamaño y Desempeño................................................................................................59

CAPÍTULO 2: PATRONES...............................................................................................................611. Introducción......................................................................................................................... 612. Desarrollo Histórico.............................................................................................................613. Definición............................................................................................................................. 624. Tipos de Patrones...............................................................................................................634.1. Patrones de Análisis........................................................................................................634.2. Patrones de Diseño (GOF, 1995)....................................................................................644.2.1. Patrones de Creación (Creational Patterns)...............................................................654.2.1.1. FáBRICA Abstracta (Abstract Factory)...................................................................654.2.1.2. Constructor (Builder)...............................................................................................674.2.1.3. Método Fábrica (Factory Method)...........................................................................694.2.1.4. Prototipo (Prototype)...............................................................................................694.2.1.5. Singleton................................................................................................................. 704.2.2. Patrones Estructurales (Structural Patterns)...............................................................714.2.2.1. Adapter o Wrapper.................................................................................................714.2.2.2. Puente (Bridge).......................................................................................................724.2.2.3. Composición (Composite)......................................................................................734.2.2.4. Decorador (Decorator)............................................................................................754.2.2.5. Fachada (Façade)..................................................................................................764.2.2.6. Peso Mosca (Flyweight).........................................................................................774.2.2.7. APoderado o Representante (Proxy)......................................................................794.2.3. Patrones de Comportamiento (BehaviorAl Patterns)..................................................804.2.3.1. Cadena de Responsabilidades (Chain of Responsibility).......................................804.2.3.2. Comando (Command)............................................................................................814.2.3.3. Intérprete (Interpreter)............................................................................................834.2.3.4. Iterador (Iterator).....................................................................................................844.2.3.5. Mediador (Mediator)...............................................................................................854.2.3.6. Recuerdo (Memento)..............................................................................................854.2.3.7. Observador (Observer)...........................................................................................86

3

4.2.3.8. Estado (State).........................................................................................................874.2.3.9. Estrategia (Strategy)...............................................................................................884.2.3.10. Método Plantilla (Template Method).......................................................................894.2.3.11. Visitador (Visitor)....................................................................................................904.2.3.12. Modelo Vista Controlador (MVC)............................................................................914.2.3.13. Controlador frontal (front controler).........................................................................944.2.3.14. InverSion of control (IOC).......................................................................................984.2.3.15. Patrón Dependency Injection..................................................................................984.2.3.16. patrón page controller...........................................................................................1004.2.3.17. Patrón Intercepting filter........................................................................................1064.2.3.18. Patrón Businnes delegate.....................................................................................114

CAPÍTULO 3: CASO DE ESTUDIO...............................................................................................1161. Propuesta Técnica.............................................................................................................1162. Resumen Situación Actual................................................................................................1172.1. Diagnóstico Inicial.........................................................................................................1172.2. Sistemas de Apoyo Actuales.........................................................................................1182.3. Marco Institucional del Proyecto...................................................................................1203. Diagnóstico........................................................................................................................ 1213.1. Realización Actual de los Procesos..............................................................................1213.2. Criterios de Valor Agregado para Realizaciones Alternativas.......................................1223.3. Arquitectura Actual del CMS Matemática......................................................................1223.3.1. Petición de un Recurso.............................................................................................1233.3.2. Generación de Respuesta........................................................................................1243.4. Modelo de Conceptual de MATCMS.............................................................................1253.5. Modelo de Clases de MATCMS....................................................................................1274. Descripción de la Solución Propuesta...............................................................................1284.1. Propósito del Sistema...................................................................................................1284.1.1. Propuesta Página Académico...................................................................................1294.1.2. Propuesta Página Alumnos.......................................................................................1304.2. Requerimientos Funcionales.........................................................................................1304.3. Requerimientos NO Funcionales..................................................................................1314.4. Modelos de Alto Nivel....................................................................................................1324.4.1. Casos de Usos..........................................................................................................1324.4.2. Modelo Conceptual...................................................................................................1324.4.3. Modelo Físico de Base de Datos..............................................................................1364.4.4. Diagrama de Actividad de la Solución Propuesta.....................................................1364.5. Realización propuesta de los Procesos........................................................................1384.5.1. Definiciones de Negocio...........................................................................................1384.5.2. Reglas de Negocio....................................................................................................1384.5.3. Procesos de Negocios..............................................................................................1404.5.4. Árbol Jerárquico de los Recursos Asignaturas.........................................................1424.6. Aspectos Técnicos de la Solución.................................................................................1434.7. Aspectos de Calidad de Servicios.................................................................................1434.8. Contribuciones Claves de la Solución Propuesta..........................................................1444.9. Tecnología Clave a Utilizar...........................................................................................1464.10. Relevancia de la Solución a la ULS..........................................................................1465. Marco Metodológico..........................................................................................................1485.1. Análisis y Diseño Orientado a Objetos..........................................................................1485.2. Principios Metodológicos...............................................................................................1495.3. Métodos Modernos de Desarrollo.................................................................................1505.4. RaTional Unified Process (RUP)...................................................................................1505.4.1. Características y Principios.......................................................................................1505.4.2. Descripción Dinámica: Fases e Iteraciones..............................................................1505.4.3. Descripción Estática: Actividades y Artefactos.........................................................1515.5. Apoyo Metodológico......................................................................................................1526. Plan de Trabajo................................................................................................................. 152

4

6.1. Fase Inicial....................................................................................................................1526.2. Fase de Elaboración.....................................................................................................1536.2.1. Levantamiento y Análisis de Requerimientos...........................................................1536.2.2. Diseño de la Solución...............................................................................................1536.2.2.1. Diseño Preliminar: Diseño Conceptual y Arquitectónico.......................................1536.2.2.2. Diseño Detallado, diseño físico............................................................................1536.2.3. Revisiones y Entregables..........................................................................................1546.2.4. Planificación Fase II..................................................................................................1546.2.5. Fase de Término.......................................................................................................1546.3. Carta Gantt....................................................................................................................1546.4. Estrategia a Utilizar para el Control y Seguimiento del Proyecto..................................1547. Organización..................................................................................................................... 1557.1. Equipo del Proyecto......................................................................................................1557.2. Experiencia del Equipo..................................................................................................1567.3. Costos del Proyecto......................................................................................................1568. Entregables....................................................................................................................... 1578.1. Tipos de Entregables....................................................................................................1578.1.1. Descripción del Problema.........................................................................................1578.1.2. Arquitectura del Sistema...........................................................................................1588.1.3. Casos de Prueba......................................................................................................1598.1.4. Plataforma y Equipo de Construcción.......................................................................1598.1.5. Plataforma de Explotación........................................................................................1608.1.6. Manuales de Uso y Operación del Sistema..............................................................1608.1.7. Prototipos.................................................................................................................. 1608.1.7.1. Prototipos Funcionales.........................................................................................1608.1.7.2. Prototipos Tecnológicos.......................................................................................1618.1.8. Entregables para cada etapa de la Fase I................................................................1619. Garantía Técnica de Soporte y Capacitación....................................................................163

Conclusiones.................................................................................................................................. 166apéndices Memoria de Titulación...................................................................................................170

5

Índice de Tablas y Figuras.

Tabla 1: Lenguajes de Descripción de Arquitecturas................................................................................15Figura 2: Descripción de un Pipes de Unix.................................................................................................21Figura 3: Descripción Datos Abstractos y Objetos.....................................................................................22Figura 4: Ejemplo Repositorio.......................................................................................................................24Figura 5: Ejemplo Table Driven Interpreters...............................................................................................25Figura 6: Ejemplo Modelo de Capas............................................................................................................26Tabla 7: Cuadro Comparativo de Distribuciones de UML.........................................................................30Figura 8: Rol de la Arquitectura de Software..............................................................................................38Tabla 9: Virtudes de las Arquitecturas de Software...................................................................................41Tabla 10: Aspectos Negativos de las Arquitecturas de Software............................................................43Tabla 11: Contrastes entre la Empresa y la Academia.............................................................................44Figura 12: Revisión de una Arquitectura de Software...............................................................................53Tabla 13: Explicación Proceso de Revisión................................................................................................53Tabla 14: Elementos de un SAD...................................................................................................................55Figura 15: Representación de los Patrones de Diseño, según Vince Houston.....................................65Figura 16: Modelo de Clases en UML de Abstract Factory......................................................................66Figura 17: Estructura en UML del Patrón Builder.......................................................................................67Figura 18: Diagrama de Colaboración del Patrón Builder........................................................................68Figura 19: Ejemplo en UML del Patrón Builder..........................................................................................68Figura 20: Modelo de Clases en UML del Patrón Factory Method..........................................................69Figura 21: Ejemplo en UML del Patrón Prototipo.......................................................................................70Figura 22: Ejemplo en UML del Patrón Singleton......................................................................................71Figura 23: Ejemplo en UML del Patrón Wrapper........................................................................................72Figura 24: Ejemplo en UML del Patrón Bridge...........................................................................................73Figura 25: Estructura en UML del Patrón Composite................................................................................74Figura 26: Ejemplo en UML del Patrón Decorator.....................................................................................75Figura 27: Ejemplo en UML del Patrón Façade..........................................................................................76Figura 28: Ejemplo en UML del Patrón Flyweight......................................................................................78Figura 29: Ejemplo en UML del Patrón Proxy.............................................................................................79Figura 30: Ejemplo en UML de Cambio de Responsabilidades..............................................................80Figura 31: Ejemplo en UML del Patrón Command....................................................................................82Figura 32: Ejemplo en UML del Patrón Intérprete......................................................................................83Figura 33: Ejemplo en UML del Patrón Iterator..........................................................................................84Figura 34: Ejemplo en UML del Patrón Mediator.......................................................................................85Figura 35: Ejemplo en UML del Patrón Memento......................................................................................86Figura 36: Ejemplo en UML del Patrón Observador..................................................................................87Figura 37: Ejemplo en UML del Patrón Estado..........................................................................................88Figura 38: Ejemplo en UML del Patrón Estrategia.....................................................................................88Figura 39: Ejemplo en UML del Template Method.....................................................................................89Figura 40: Ejemplo en UML del Patrón Visitador.......................................................................................90Figura 41: Estructura del Patrón MVC.........................................................................................................91Figura 42: Diagrama de Componentes del Patrón MVC...........................................................................92Figura 43: Estructura del Patrón Front Controller......................................................................................96Figura 44: Responsabilidades del Patrón Front Controller.......................................................................96Figura 45: Diagrama en UML de IOC...........................................................................................................98Figura 46: Dependencia Simple versus Dependency Injection..............................................................100Figura 47: Patrón Page Controller..............................................................................................................102Figura 48: Eliminando Duplicación de Código..........................................................................................102Figura 49: Separación del código de la Aplicación Web.........................................................................104Figura 50: Estructura de clases del Patrón Intercepting Filter...............................................................108

6

Figura 51: Diagrama de Secuencias del Patrón Intercepting Filter.......................................................108Figura 52: Diagrama de Secuencias utilizando el Patrón Decorator....................................................110Figura 53: Diagrama de Secuencias sin utilizar el Patrón Decorator....................................................111Figura 54: Diagrama de Secuencias para el Patrón (2 estrategias).....................................................112Figura 55: Diagrama de Secuencias de la Estrategia Plantilla..............................................................113Figura 56: AdminRequestBD establece y adapta otros componentes del negocio............................115Tabla 57: Mecanismos Publicación de Contenidos Actuales.................................................................119Figura 58: Arquitectura MATCMS...............................................................................................................123Figura 59: Diagrama de Secuencia, Petición de Recurso......................................................................125Figura 60: Diagrama Conceptual de MATCMS........................................................................................126Figura 61: Diagrama de Clases de MATCMS...........................................................................................127Figura 62: Look and Feel, Página de los Alumnos..................................................................................130Figura 63: Diagrama de Casos de Usos....................................................................................................132Figura 64: Diagrama Conceptual de Base de Datos...............................................................................133Figura 65: Diagrama Físico de Base de Datos.........................................................................................136Figura 66: Diagrama de Actividad...............................................................................................................137Figura 67: Árbol de Recursos Asignaturas, explicación de Permisos..................................................139Figura 68: Ejemplo de cómo se estructura CMS de Matemática..........................................................145Tabla 69: Requisitos y Tecnologías............................................................................................................147Tabla 70: Equipo de Desarrollo...................................................................................................................155Tabla 71: Funcionalidad por Rol.................................................................................................................156Tabla 72: Costos Proyecto...........................................................................................................................156Tabla 73: Entregables en cada etapa de la Fase I..................................................................................162

7

INTRODUCCIÓN

La etapa de especificación de desarrollo de un sistema informático es clave, en el sentido que debe entregar como resultado un modelo que represente en forma precisa el problema real, de tal forma que contenga todas sus características claves, a fin de que su implementación entregue los resultados correctos.

En el desarrollo de la Informática han surgido diferentes enfoques y sus métodos correspondientes para el desarrollo de sistemas, cada uno mejorando la especificación, en el sentido antes descrito. Esta línea es la denominada Ingeniería de Software, y se caracteriza por entregar métodos de desarrollo que describen los modelos en lenguajes y diagramas enfocados principalmente al desarrollador, y no al usuario, lo cual es una deficiencia importante, ya que éste, como experto en el problema, es conocedor de mucha información acerca de él, la que, en conjunto con el conocimiento técnico que tiene el informático, puede conducir a obtener un sistema simple y robusto.

De esta manera surgió la idea de una disciplina que proporcione métodos los cuales, sin tener la rigidez que entregan los métodos de la Ingeniería de Software, pero sin perder su calidad, involucre al usuario en el desarrollo del sistema, además que permita la obtención de modelos más flexibles como solución de problemas informáticos. Para ello, éstos deben tener la capacidad de mostrar diversas vistas, a fin de que sean entendibles por todos los involucrados en el sistema (stakeholders). Esta disciplina se denomina Arquitectura de Software, debido a que los modelos de los sistemas que pretenden representar son esquemas basados en módulos que interactúan, más la definición de interfaces con su ambiente, sin especificar elementos informáticos propiamente tales, los que serán agregados posteriormente por las herramientas disponibles por la Ingeniería de Software.

Respecto de la estructura modular de una las arquitecturas de software, es fácil ver que el enfoque de objetos es el adecuado para modelar sus componentes, ya que entre ellos subyace la misma filosofía. Más aún, es posible construir módulos estándares que permitan resolver problemas específicos y de diversa naturaleza, que pueden ser clasificados y utilizados de diversas maneras para construir una arquitectura de un sistema. Dichos módulos se denominan Patrones de Diseño.

En este Trabajo de Titulación se hace un exhaustivo estudio y análisis de las Arquitecturas de Software y Patrones de Diseño, a fin de aplicarlos a un Caso de Estudio concreto, con el propósito de determinar sus potencialidades y restricciones en el modelado de un sistema, lo cual es el objetivo central de este Trabajo.

La Universidad de La Serena actualmente está acreditada por dos años por la CNAP, lo cual significa que deberá hacer esfuerzos por el quehacer académico en todos los ámbitos, en particular en la administración. La presente Memoria de Titulación propone el caso de estudio como una propuesta de arquitectura de software para mejorar el sistema de manejo, administración, y soporte de la información de la docencia en la Universidad.

En el Primer Capítulo de la presente Memoria de Titulación se desarrolla en extenso el concepto, origen histórico, elementos estructurales, y temas afines de las Arquitecturas de Software, la cual ha resultado fundamental en la reducción de costos, evitando errores, encontrando fallas, implementando sistemas de misión crítica, en la Industria del Software1.

En el Segundo Capítulo, se estudia el concepto de Patrón de Diseño, enfocado principalmente al análisis y desarrollo de sistemas.

En el Tercer Capítulo se desarrolla el Caso de Estudio, el que está conformado con la aplicación de los capítulos anteriores, obteniendo un documento arquitectural para el problema planteado.

Del estudio conceptual de los temas tratados en los tres capítulos, y del desarrollo del Caso de Estudio, se obtienen las conclusiones, y se proponen posibles trabajos futuros.

Para complementar conceptos y métodos de desarrollo asociados a esta Memoria, se adiciona un conjunto de Apéndices, entre los cuales se destacan: Patrones de Coplien, Métodos de Desarrollo, Frameworks, Líneas de Productos, y Refactoring.

1 Barry Boehm, creador de COCOMO.

2

CAPÍTULO 1: ARQUITECTURA DE SOFTWARE

1. INTRODUCCIÓN

A medida que el tamaño y la complejidad de los sistemas de software aumentan, el análisis, el diseño, y la especificación de la estructura global del sistema, llegan a ser una etapa crítica para cualquier equipo de desarrollo.

Las decisiones estructurales consideran: la organización del sistema en su composición de componentes; las estructuras de control global; los protocolos de comunicación, la sincronización, el acceso a los datos, la asignación de la funcionalidad para el diseño de los elementos, la composición de los elementos del diseño, la distribución física, el escalamiento, el funcionamiento, y las dimensiones de la evolución. Esto es considerado la etapa de diseño de una arquitectura de software2.

Desde los años 70, con la construcción de los primeros simuladores de vuelos, las decisiones arquitectónicas han surgido como un subcampo muy importante en la Ingeniería de Software, pero no han sido utilizadas satisfactoriamente.

Una buena arquitectura puede ayudar para asegurar que un sistema dará cumplimientos a los requisitos en áreas claves, tales como: rendimiento, confiabilidad, portabilidad, escalabilidad, e interoperabilidad. En cambio, una mala arquitectura puede llegar a ser desastrosa para el futuro de alguna aplicación.

A todo nivel, ya sea en la academia o en las empresas de desarrollo de software, se ha reconocido la importancia de realizar decisiones arquitectónicas explícitas.

Hoy en día, existen libros que sirven como apoyo para el diseño arquitectónico, conferencias, cursos, y talleres, dedicados específicamente para el estudio de Arquitecturas del Software, y un número creciente de estándares formales arquitectónicos.

La estructuración de principios, de métodos, y de prácticas arquitectónicas, ha iniciado la utilización de procesos repetibles en el diseño arquitectónico, los cuales son conocidos como Patrones o Estilos Arquitecturales; los criterios permiten la retroalimentación entre las diversas arquitecturas, como a su vez los estándares de documentación permiten analizar a las arquitecturas en ejecución.

“La Arquitectura de Software se ha convertido en un área de investigación en la comunidad de la Ingeniería de Software”3. Han surgido un gran número de herramientas de soporte y de estilos arquitectónicos que permiten modelar arquitecturas.

2 David Garlan, Carnegie Mellon University, CMU, Pittsburgh, USA.3 Nenad Medvidovic, [email protected]

3

Este capítulo expondrá una breve historia de las Arquitecturas de Software, conceptos y principios fundamentales de esta disciplina, la problemática que tratan resolver; se expondrá brevemente el Dominio Específico de Arquitectura de Software (DSSA4), los Estilos Arquitectónicos, los Lenguajes de Descripción de Arquitectura (ADL), y otros temas relacionados.

2. HISTORIA DE LA ARQUITECTURA DE SOFTWARE.

Desde que Mary Shaw junto a David Garlan5 cuestionaran si la Arquitectura de Software es una disciplina o una ciencia, los mismos párrafos han sido reutilizados una y otra vez en la bibliografía disponible, sin mayor profundidad sobre las referencias de los documentos originales, con el objetivo de destacar directamente el concepto y sus principios.

En el estudio desarrollado por Carlos Reynoso6, se ha optado por inspeccionar las fuentes con mayor profundidad, con el objetivo de señalar las supervivencias y las reformulaciones que han experimentado las ideas fundadoras de la Arquitectura de Software contemporánea, para definir con mayor claridad el contexto, entender los aportes y contribuciones, que en algunos casos, incluso fueron complementarios; en realidad, éstos han sido antagónicos, y permiten comprender mejor por qué algunas ideas que surgieron hace cuatro décadas demoraron un cuarto de siglo en materializarse.

Si bien la Arquitectura de Software remonta sus orígenes no antes de la década de 1960, su historia no ha sido tan continua como la del campo más amplio en el que se inscribe, la Ingeniería de Software7. En este punto cabe destacar la propuesta del académico Hernán Astudillo8, al respecto indica: “La Arquitectura de Software se dirige principalmente hacia el modelo o diseño del Sistema; en cambio, la Ingeniería de Software calcula, al igual que las otras ingenierías”.

Después de las tempranas ideas de Edsger Dijkstra, David Parnas, y Fred Brooks, la Arquitectura de Software quedó en estado latente durante muchos años, hasta comenzar su expansión con los manifiestos de Dewayne Perry9 y Alexander Wolf10.

Puede decirse que Perry y Wolf fundaron la disciplina, y fueron seguidos por los miembros de Carnegie Mellon11.

4 Domain Specific Software Architectures5 David Garlan, “Reseca Directions in Software Architecture”, ACM Computing Surveys, vol 27, nº 2, Junio 1995.6 Carlos Reynoso, “Reporte Técnico sobre Arquitecturas de Software”, Universidad de Buenos Aires, 2000.7 Shari Lawrence Pfleeger. “Ingeniería de Software: Teoría y Práctica”. Prentice-Hall, 2002.8 Hernán Astudillo, Universidad Técnica Federico Santa María, consultor de ACM.9 Funcionario de AT&T Bell Laboratories de New Jersey y Universidad de Colorado, respectivamente.10 Dewayne E. Perry y Alexander L. Wolf. “Foundations for the study of software architecture”. ACM SIGSOFT Software Engineering Notes, 17(4), pp. 40–52, Octubre de 1992.

11 Cuna de la Escuela Estructuralista: David Garlan, Mary Shaw, Paul Clements, Robert Allen, Rick Kazman, Mark Klein y Len Bass.

4

A comienzos del siglo XXI, se pueden visualizar diversas tendencias, dentro de las cuales se pueden mencionar: la de la Universidad de Irvine12, la de SRI de Menlo Park13, y otras, vinculadas a las recomendaciones formales de la IEEE y los trabajos de Rich Hilliard14.

Actualmente, existen un conjunto de posturas europeas, especialmente, de la Universidad Politécnica de Milán15, que enfatizan aspectos metodológicos vinculados con los escenarios, y hacen hincapié en inscribir la Arquitectura de Software dentro del ciclo de vida, comenzando por la clasificación de los requerimientos.

El nacimiento de la Arquitectura de Software se puede establecer hacia 1968, con Edsger Dijkstra16; quien propuso que se establezca una estructuración correcta de los sistemas de software antes de comenzar a programar, para evitar escribir el código desordenadamente17. Pese a que no utiliza el término Arquitectura para describir el Diseño Conceptual del Software, sus conceptos sientan las bases para lo conocido por “Refinamiento por Etapas18” y como “Programación en Grande19”, ideas que poco a poco se fueron decantando entre los ingenieros de software, y posteriormente entre los arquitectos.

En la conferencia de la OTAN20 de 1969, un año después de la sesión en que se fundara simbólicamente la Ingeniería de Software, Peter Sharp21 comentó lo formulado por Dijkstra:

“Pienso que tenemos algo, aparte de la Ingeniería de Software: algo de lo que hemos hablado muy poco, pero que deberíamos poner sobre el tapete, y concentrar la atención en ello: es la Arquitectura de Software, que es diferente de la Ingeniería de Software. La razón de que un Sistema Operativo sea un acumulamiento amorfo de programas, es que no tuvo arquitecto. Su diseño fue delegado a una serie de grupos de ingenieros, cada uno de los cuales generó su propia arquitectura. Y cuando estos módulos se unieron, no produjeron un software entendible”.

12 Referentes: Nenad Medvidovic, David Rosenblum y Richard Taylor. http://www.uci.edu/13 http://www.sri.com/, cuyo principal referente es Mark Moriconi.14Universidad de Bremen, Alemania, http://www.db.informatik.uni-bremen.de/umlbib/authors/HilliardRich.html15 Universidad Politécnica de Milán, Italia; http://www.unimi.it/16 Universidad Tecnológica de Eindhoven, Holanda.17 Edsger Dijkstra. “The Structure of the Multiprogramming system.” Communications of the ACM, 26(1), pp. 49-52, Enero de 1983.18 Niklaus Wirth. “Program development by stepwise refinement”, Communications of the ACM, 14(4), pp. 221-227, Abril de 197119 Frank DeRemer y Hans Kron, “Programming-in-the-large versus programming-in-the-small”. IEEE Transaction in Software Engineering, 2, pp. 80-86, 1976.20 Acrónimo de Organización del Tratado del Atlántico Norte.21 http://lemoigne.home.cern.ch/lemoigne/esiWeb/lecturers.html, email: [email protected]

5

Dentro de éste contexto. Peter Sharp, indica: “Probablemente llegue a hablarse de La Escuela de Arquitectura de Software de Dijkstra”, indicando:

“Las especificaciones de software se consideran especificaciones funcionales. Sólo se habla sobre lo que se quiere que haga el programa. Desde mi perspectiva, cualquiera que sea el responsable de la implementación de un componente de software, debe especificar más que esto. Debe especificar el diseño, la forma; y dentro de ese marco de referencia, los programadores e ingenieros deben crear algo. Ningún ingeniero o programador, ninguna herramienta de programación, ayudará, y tampoco lo harán las reglas de negocio del software. El control, la administración, la educación, y la planificación se consideran importantes; pero el personal que implementa debe entender lo que el Arquitecto piense”.

En 1975, Fred Brooks22 utilizaba el concepto de Arquitectura del Sistema para designar “la especificación completa y detallada de la interfaz de usuario, y consideraba que el Arquitecto es un agente del usuario, haciendo un paralelo con quien diseña una casa, empleando una nomenclatura apropiada”23. En el mismo texto, identificaba y razonaba sobre las Estructuras de alto nivel, y reconocía la importancia de las decisiones tomadas a nivel de diseño. También distinguía entre Arquitectura e Implementación; mientras aquella decía qué hacer, la implementación se ocupaba de cómo hacerlo, estableciendo desde ese entonces la diferencia entre un Arquitecto de Software y un Ingeniero de Software.

Una novedad importante en la década de 1970 fue el nacimiento del diseño estructurado y los primeros modelos explícitos de desarrollo de software. Estos modelos comenzaron a basarse en una estrategia evolutiva, cíclica, dejando atrás el desarrollo en cascada, que se inspiraban más bien en la línea de montaje de la ingeniería del hardware y la manufactura en general. Surgieron entonces las primeras investigaciones académicas en materia de diseño de sistemas complejos o “intensivos”. Poco a poco el diseño se fue independizando de la implementación, y nacieron herramientas, técnicas, y lenguajes de modelado específicos.

En la misma época, David Parnas24 demostró que los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas, y propuso diversos principios de diseño que debían seguirse, con el fin de obtener una estructura adecuada. Desarrolló temas tales como: módulos con ocultamiento de información25, estructuras de software26 y familias de programas27, enfatizando siempre la búsqueda de la calidad del software, cuantificable en términos de ahorro en los procesos de desarrollo y mantención. 22 Diseñador del Sistema Operativo OS/360; http://www.answers.com/topic/fred-brooks23 Frederick Brooks Jr. “The mythical man-month”, Addison-Wesley, 1975.24 http://www.cas.mcmaster.ca/sqrl/parnas.homepg.html 25 David Parnas. “On the Criteria for Decomposing Systems into Modules”, Communications of the ACM 15(12), pp. 1053-1058, Diciembre de 1972.26 David Parnas. “On a Buzzword: Hierarchical Structure”, Programming Methodology, pp. 335-342. Berlin, Springer-Verlag, 1978.27 David Parnas. “On the Design and Development of Program Families”, IEEE Transactions on Software Engineering SE-2, 1, pp. 1-9, Marzo de 1976.

6

Parnas es sin duda el precursor de algunas de las nociones más esenciales y permanentes de la Arquitectura de Software, publicando en 1972 un ensayo en el cual discutía la forma en que la modularidad en el diseño de sistemas podía mejorar la flexibilidad y el control conceptual de éstos, disminuyendo los tiempos de desarrollo. Introdujo entonces el concepto de “ocultamiento de información”. La importancia de este concepto en la ingeniería y en la arquitectura es bien conocida, y se confunde estrechamente con la idea de abstracción. Pero lo fundamental radica en la idea de basar la técnica de modularización en decisiones de diseño, mientras que los “niveles de abstracción” de Dijkstra involucraban más bien técnicas de programación.

El concepto de ocultamiento de información se fue mezclando con encapsulamiento y abstracción. Los arquitectos deben distinguir entre encapsulamiento y ocultamiento, considerando a aquél como una capacidad de los lenguajes de programación y a éste como un principio más general de diseño.

Parnas no hablaba en términos de Programación Orientada a Objetos, sino de módulos y sub-rutinas, porque aún dicha técnica no existía. Además, fue un precursor de las familias de programas; en particular, anticipa ideas que luego habrían de desarrollarse a propósito de los estilos arquitecturales: “Una familia de programas es un conjunto de programas, para los cuales es provechoso o útil considerar como grupo”. Esto evita el uso de conceptos ambiguos, tales como “similitud funcional”, que surgen cuando se describen dominios.

Parnas, expuso que las decisiones tempranas de desarrollo serían las que probablemente permanecerían invariantes en el desarrollo de una solución. Esas “decisiones tempranas” constituyen de hecho lo que hoy se conocen por decisiones arquitectónicas.

Paul Clements y Northrop28 coincidían con la última idea, es decir, la estructura es primordial, y la elección de la estructura correcta ha de ser crítica para el éxito del desarrollo de una solución. “La elección de la estructura correcta” sintetiza, como ninguna otra expresión, el programa y la razón de ser de la Arquitectura de Software.

Por la década de 1980, los métodos de desarrollo estructurado, demostraron que no se puede escalar en forma suficiente y eficiente y es por ello que fueron dejando el lugar a un nuevo paradigma, el Enfoque Orientado a Objetos, ya que parecía posible modelar el dominio del problema y el de la solución, para luego implementarlo en cierto lenguaje.

28 Paul Clements y Linda Northrop. “Software architecture: An executive overview”. Technical Report, CMU/SEI-96-TR-003, ESC-TR-96-003. Febrero de 1996.

7

Paralelamente, hacia fines de la década de 1980 y comienzos de la década siguiente, la expresión “Arquitectura de Software” ya hace referencia a la “Configuración morfológica de una aplicación”.

La Arquitectura de Software, como disciplina bien delimitada, es mucho más reciente de lo que se sospecha. El primer texto, que habla de las abstracciones de alto nivel, proponiendo un espacio para esa reflexión y augurando que el uso de esas abstracciones en el proceso de desarrollo puede resultar en “un nivel de Arquitectura de Software en el Diseño” son las publicaciones de Mary Shaw29. En esos años, se referían, a un nivel de abstracción en su conjunto; todavía no estaban en su lugar los elementos de juicio que permitieran ver la necesidad de una disciplina, y menos de una profesión en particular.

El primer estudio, en el cual aparece la expresión “Arquitectura de Software”, es con Perry y Wolf30 en 1992. En él, los autores proponen a la Arquitectura de Software por analogía con la Arquitectura de Edificios. El artículo comienza exactamente indicando:

“El propósito de este artículo, es construir el fundamento para la Arquitectura de Software. Primero se desarrollará una intuición para La Arquitectura de Software, recurriendo a diversas disciplinas arquitectónicas bien definidas. Sobre la base de esa intuición, se presenta un modelo para la Arquitectura de Software, la cual consiste de tres componentes: elementos, forma y razón. Los elementos, pueden ser de procesamiento, datos, o conexión. La forma se define en términos de las propiedades, y las relaciones entre los elementos, son restricciones operadas sobre ellos. La razón proporciona una base subyacente para la arquitectura, en términos de las restricciones del sistema, de los requerimientos del sistema. Se discutirán los componentes del modelo en el contexto tanto de la arquitectura como de los estilos arquitectónicos....”

Es claro que en la declaración anterior, cada idea y cada intuición han perdurado desde ese entonces.

En la década de 1970, los investigadores destacaron que el diseño es una actividad separada de la implementación y que requiere de notaciones, técnicas, y herramientas especiales. Los resultados son visibles hoy en día, con la consolidación de las herramientas de Ingeniería de Software Asistida por Computadoras, CASE31. Pero uno de los resultados negativos de la utilización de éstas ha sido la integración de las herramientas de diseño con los lenguajes de

29 Mary Shaw, “Abstraction Techniques in Modern Programming Languages”. IEEE Software, Octubre, pp. 10-26, 1984. y Larger scale systems require higher level abstractions de 1989.30 Dewayne E. Perry y Alexander L. Wolf, “Foundations for the study of software architecture”. ACM SIGSOFT Software Engineering Notes, 17(4), pp. 40–52, Octubre de 1992.

8

implementación. Esto tiende a confundir la diferencia entre diseño e implementación.

En la década de 1980 se perfeccionaron las técnicas descriptivas y las notaciones formales, las cuales permiten razonar sobre los sistemas. Para la caracterización de lo que sucederá en la década siguiente, se formulan32:

“La década de 1990, será la década de la Arquitectura de Software. Se utiliza el término “Arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los Arquitectos de Software), y de estilo. Es tiempo de reexaminar el rol de la Arquitectura de Software, en el contexto más amplio del proceso de software y de su administración, así como señalar las nuevas técnicas que han sido adoptadas”.

Considerada como una disciplina por algunos, la Arquitectura de Software, es beneficiosa como marco de referencia para satisfacer los requerimientos, una base esencial para la estimación de costos, administración del proceso, el análisis de las dependencias, y la consistencia del sistema.

La década de 1990 fue la consolidación y difusión de la Arquitectura de Software. Las contribuciones más importantes surgieron en torno del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon (CMU SEI33). En la misma década, surge también la programación basada en componentes, que en su momento de mayor impacto impulsó a algunos arquitectos, como Paul Clements34, a afirmar: “La Arquitectura de Software promovía un modelo que debía ser más de integración de componentes preprogramados, que de programación”.

Un segundo gran tema fue el surgimiento de los patrones35, que promueve una expansión de la Programación Orientada a Objetos, y se desarrolla un marco levemente más asociado a la Arquitectura de Software. Este movimiento se ha expandido desde ese entonces.

Si bien la idea de Arquitectura de Software, actualmente con la utilización de los patrones, está más cerca de la implementación y el código, algunos arquitectos de la Escuela de Carnegie Mellon formalizaron un acercamiento con la estrategia de David Garlan y Mery Shaw donde tanto en los patrones como la arquitectura, tiene como ideas dominantes la reutilización.

31 Reporte Técnico sobre el Listado de herramientas CASE disponibles para la Ingeniería de Software en la Universidad de California, USA. http://www.qucis.queensu.ca/Software-Engineering/tools.html32 Dewayne E. Perry y Alexander L. Wolf, “Foundations for the study of software architecture”. ACM SIGSOFT Software Engineering Notes, 17(4), pp. 40–52, Octubre de 1992.33 Página Institucional de CMU, http://www.cs.cmu.edu/34 Paul Clements. “Coming attractions in Software Architecture”. Technical Report, CMU/SEI-96-TR-008, ESC-TR-96-008, Enero de 1996.35 Tema tratado inextenso en el Capítulo 2 de la Presente Memoria de Título

9

La Arquitectura de Software en este período permitió la homogenización de la terminología, desarrollando la tipificación de los estilos arquitectónicos, y permitió la elaboración de los Lenguajes de Descripción de Arquitectura (ADLs). También se consolidó la concepción de las vistas arquitectónicas, reconocidas en todos y cada uno de los frameworks generalizadores que se han propuesto (4+1, TOGAF36, RM/ODP37, IEEE).

Uno de los hechos más importantes para la Arquitectura de Software del año 2000, fue la tesis de Roy Fielding38, quién presentó el modelo REST39, el cual relaciona las tecnologías de Internet y los modelos orientados a servicios y recursos, como el centro de las preocupaciones de la disciplina. En el mismo año se publica la versión definitiva de la recomendación IEEE Std 1471, las cuales procuran homogeneizar y ordenar la nomenclatura de descripción arquitectónica, y homologa los estilos como un modelo fundamental de representación conceptual.

En el siglo XXI, la Arquitectura de Software aparece inmersa en estrategias orientadas a líneas de productos, y en el intento de establecer modalidades de análisis, diseño, verificación, refinamiento, recuperación, diseño basado en escenarios, estudios de casos, y justificación económica, redefiniendo todas las metodologías ligadas al ciclo de vida en términos arquitectónicos.

Todo lo que se ha hecho en ingeniería debe reformularse, integrándole la Arquitectura de Software. La producción de estas nuevas metodologías ha sido masiva, y tiene como centro neurálgico el trabajo de la CMU40.

La aparición de las metodologías basadas en arquitectura, junto con la popularización de los métodos ágiles en general, y Extreme Programming en particular, han causado una reorganización del campo de los métodos, hasta entonces bajo las estrategias de diseño riguroso.

3. DEFINICIONES FORMALES DE ARQUITECTURA DE SOFTWARE.

Existen variadas definiciones, pero por lo general coinciden en muchos aspectos, a continuación, se presentan las definiciones propuestas por distintos

36 Acrónimo de Open Group Architecture Framework, http://www.opengroup.org/37 Acrónimo de Reference Model for Open Distributed Processing, Antonio Vallecillo, http://www.lcc.uma.es/~av/RM-ODP38 Roy Fielding, http://www.ics.uci.edu/~fielding “Architectural styles and the design of network-based software architectures”. Tesis doctoral, University of California, Irvine, 200039 Acrónimo de The Representational State Transfer.40 Carnegie Mellon University

10

http://www.cmu.edu/

investigadores, y la definición personal del autor de la presente Memoria de Título será una de las conclusiones del trabajo realizado.

3.1.MARY SHAW Y DAVID GARLAN.

“Los elementos estructurales incluyen la organización de un sistema como la composición de componentes; estructuras de control global; protocolos de comunicación; etc.”

La asignación de la funcionalidad de los elementos corresponde a su diseño, distribución física, y rendimiento. Por Componentes de un programa y/o sistema, se refiere a la forma en que se asigna la funcionalidad de un sistema de software, la cual es realizada por los componentes individuales; incluyendo asuntos de modularidad y granularidad de los componentes de software. Las interrelaciones son la coordinación entre componentes de software como comunicación, cooperación y sincronización. A su vez, los principios y normas están relacionados a las decisiones que se toman, su deducción, y las políticas para adoptar, y hacer cumplir estas decisiones. Estos principios y normas orientan la forma de cómo se construye el sistema, y cómo se espera que evolucione en el tiempo.

3.2.BASS, CLEMENTS Y KAZMAN.

“La Arquitectura de Software de una aplicación o sistema, es la estructura o estructuras del sistema, que comprenden los componentes de software, las propiedades externamente visibles de éstos, y las relaciones entre ellos.”

De la definición, se puede interpretar por propiedades externamente visibles a los supuestos, que ciertos componentes pueden realizar sobre otros (servicios, rendimiento, manejo de fallas, seguridad, etc.).

No cabe duda, que los sistemas pueden tener más de una estructura, pero su arquitectura considera:

Definición de cada uno de los componentes. Asociación de la información, sobre cómo los componentes interactúan

entre sí y qué aspectos omite. La Arquitectura es vista desde la perspectiva pública de la división

producida por la interfaz; el lado privado no necesariamente puede ser visto como Arquitectura.

Organización de los subsistemas, en caso de existir.

La definición propuesta admite buenas y malas Arquitecturas, las cuales permiten o impiden que el sistema cumpla sus requerimientos funcionales, de rendimiento, y de ciclo de vida.

11

3.3. IEEE ESTANDARD 1471:2000.41

La Arquitectura de Software es “La organización fundamental de un sistema, incorporando a sus componentes sus relaciones, considerando el ambiente, y los principios que conducen su diseño y evolución42”.

Se tiene que una arquitectura es la vista de un sistema a alto nivel, junto con su ambiente. Se entiende por alto nivel lo esencial del sistema, unificando conceptos y principios. El sistema es la aplicación en sí, la plataforma, los sistemas de sistemas, la empresa, y las líneas de producto, entre otros. El ambiente se refiere al desarrollo, el contexto operacional, la programación, y otros.

3.4.ALAN COOPER.

Pese a que la definición es casi idéntica a la propuesta por Mery Shaw, este autor se refiere principalmente al rol del Arquitecto, el cual sintetiza y organiza el personal, la tecnología, y sus objetivos, para crear la visión de una solución a un problema43.

3.5.STEVE MCCONNELL.

“Una Arquitectura de Software provee la estructura técnica de un proyecto, y corresponde al diseño de la estructura organizacional de un sistema, las reglas de comunicación, la visión global, y las guías de implementación. También es conocido como diseño de alto nivel o arquitectura del sistema44”.

3.6.PERRY AND WOLFE

“La Arquitectura de Software está conformada por elementos, formas, y relaciones, es decir, qué, cómo, y por qué”.

3.7.FRANK BUSCHMANN.

“Una Arquitectura de Software es una descripción de los subsistemas y componentes de un sistema y las relaciones entre ellos. Los subsistemas y componentes se especifican normalmente por medio de diferentes vistas, para dar 41 Su título original es: “Recommended Practice for Architecture Descriptions of Software Intensive Systems” y su traducción es Práctica recomendada para la Descripción de Arquitectura de Sistemas, 2000.42Definición de Enterprise Systems Architecture Laboratory Stockholm, Suecia http://www.auldenfire.com43 http://www.alan-cooper.co.uk/44 “Software Project Survival Guide--How to Be Sure Your First Important Project Isn't Your Last”. Microsoft Press, 1998

12

a conocer las propiedades funcionales relevantes e irrelevantes de un sistema. La Arquitectura de Software de un sistema es el resultado de la actividad del diseño45”.

3.8.KRUCHTEN.

“La Arquitectura de Software está relacionada con el diseño y la implementación de estructuras de software de alto nivel, con el objetivo de ensamblar elementos arquitecturales, a fin de satisfacer tanto los requerimientos funcionales, como también los no funcionales, tales como: el rendimiento, las relaciones, la escalabilidad, la portabilidad, y la disponibilidad46”.

La Arquitectura se preocupa de la abstracción, la descomposición, la composición, el estilo, y la estética del sistema, ya sean internas como externas.

3.9.PAUL G. BASSET.

“La Arquitectura de Software de un programa o sistema computacional es la estructura del sistema, la cual considera los componentes de software, las propiedades externamente visibles entre estos componentes, y las relaciones entre ellos47”.

4. LENGUAJES DE DESCRIPCIÓN DE ARQUITECTURAS, ADLS48.

La necesidad de estandarizar las diversas vistas que se pueden obtener al cabo de un análisis de algún problema, ha motivado la generación de diversos Lenguajes de Descripción de Arquitecturas, ya que los diagramas, los cuales se pueden definir como informales, al analizar su consistencia, la completitud, o la correctitud, ha provocado más de algún problema entre los stakeholders. Los supuestos arquitectónicos, en el diseño inicial, no se hacen cumplir mientras que un sistema se desarrolla. Existen pocas herramientas para la ayuda de los diseñadores arquitectónicos en sus respectivas tareas.

No cabe lugar a duda que ha existido un progreso importante para disminuir los problemas ya mencionados. En primer lugar, se ha fomentado la aparición de pautas y de estándares apropiados para la documentación. Esto ha ayudado a codificar de una manera eficiente las mejores prácticas, y proporcionar una cierta uniformidad a las arquitecturas mientras éstas son documentadas49. En segundo lugar, la creación de notaciones formales para representar y analizar diseños

45 F. Buschmann, “Reflection, in Pattern-oriented software architecture –A system of patterns”, J. Wiley & Sons, 1996.46 Philippe Kruchten, http://philippe.kruchten.com/47 “Framing Software Reuse”. Yourdon Press Computing Series, 199748 Universidad de Irvine, Califorma USA, http://www.ics.uci.edu.

13

Arquitectónicos, que son conocidos como “Lenguaje de Descripción de Arquitecturas” o “Lenguajes de Definición de Arquitecturas” (ADLs)50; estas notaciones generalmente proporcionan el marco conceptual y la sintaxis concretas, para caracterizar las Arquitecturas del Software. Además, proporcionan normalmente las herramientas para analizar, exhibir, compilar, y simular descripciones arquitectónicas.

En la siguiente tabla se presentan algunos ejemplos de ADLs, con sus principales características.

ADLS CaracterísticasACME51 Proporciona apoyo para el intercambio de

descripciones arquitectónicas.ADAGE52 Apoya la descripción de los frameworks

arquitectónicos para la navegación y la dirección de la aeronáutica.

AESOP53 Permite el soporte de estilos arquitecturales.

C254 Proporciona soporte para la descripción de interfaces de usuarios, utilizando un estilo basado en eventos.

Darwin55 Proporciona soporte al análisis del paso de mensajes en sistemas distribuidos.

Rapide56 Permite que los diseños arquitectónicos sean simulados, y dispone de herramientas para analizar los resultados de esas simulaciones.

Meta-H57 Proporciona las directrices a los diseñadores del software de control en tiempo real de la aeroelectrónica.

SADL58 Provee una base formal para el

49 “Sofware Architecture Documentation in Practice”, P. Clements, F. Bachmann, L. Bass, D. Garlan, Addison Wesley 200150 N. Medvidovic y R. N. Taylor, “Architecture description languages”. ESEC/FSE 97, Zurich, Suiza 1997 51 Acme: Architectural Description of Component-Based Systems.52 L. Coglianese and R. Szymanski, “DSSA-ADAGE: An Environment for Architecture-based Avionics Development”. In Proceedings of AGARD’93, May 1993.53 D. Garlan, R. Allen and J. Ockerbloom, “Exploiting style in architectural design environments”, 1994.54 N. Medvidovic, P. Oreizy, J. E. Robbins and R. N. Taylor. “Using object-oriented typing to support architectural design in the C2 style”. In SIGSOFT’96: Proceedings of the 4th ACM Symposium on the Foundations of Software Engineering. ACM Press. Oct 1996.55 http://www-dse.doc.ic.ac.uk/Software/Darwin/56 D. C. Luckham, L. M. Augustin, J. J. Kenny, J. Veera, D. Bryan, and W. Mann. “Specification and analysis of system architecture using Rapide”. IEEE Transactions on Software Engineering, 21(4): 336-355, April 1995.57 P. Binns and S. Vestal. “Formal real-time architecture specification and analysis”. 10th IEEE Workshop on Real-Time Operating Systems and Software, May 1993.

14

refinamiento de arquitecturas.Unicon59 Dispone de un compilador de alto nivel

para los diseños arquitectónicos que apoyan una conjunto heterogéneo de variados tipos de componentes y de conectores.

Wright60 Proporciona apoyo a la especificación y el análisis formal de las interacciones entre los componentes arquitectónicos.

Tabla 1: Lenguajes de Descripción de Arquitecturas.

La primera observación a la Tabla anterior, es determinar si se tiene una buena descripción arquitectónica, esto es beneficioso para las múltiples visiones, en donde cada visión captura cierto aspecto del sistema. Dos son los tipos de visiones más importantes:

Visiones Orientadas al Código, que describen cómo el software se organiza en módulos, y en qué tipos de módulos, y si existen dependencias en la implementación entre esos módulos. Se utilizan, por lo general, diagramas de Clases y diagramas de Capas.

Vista Orientada a la Ejecución, que describen cómo el sistema aparece en el tiempo, proporcionando normalmente uno o más estados en ciertos momentos de un sistema en acción. Estas vistas son útiles para documentar y analizar las características de ejecución, tales como funcionamiento, confiabilidad, y seguridad.

Como segunda característica, se puede mencionar que la descripción arquitectónica de las vistas Orientadas a la Ejecución, y según a lo incorporado en la mayoría de los ADLs ya mencionados, requieren la capacidad de modelar las siguientes entidades del diseño:

Componentes: Son los bloques de construcción primarios de una Arquitectura; representan los almacenes, elementos de cómputo, y los datos del sistema. Intuitivamente, corresponden a las líneas y cajas, las cuales intentan proporcionar las descripciones de las Arquitecturas de Software. Algunos ejemplos de componentes, consideran a las entidades

58 M. Moriconi, X. Qian and R. Riemenschneider. “Correct architecture refinement”. IEEE Transactions onSoftware Engineering, Special Issue on Software Architecture, 21(4):356-372, April 1995.59 M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young and G. Zelesnick. “Abstractions for Software architecture and tools to support them”. IEEE Trans on Software Engineering. 21(4):314-335. April 1995. 60 R. Allen and D. Garlan, “A formal basis for architectural connection”. ACM Transactions on Software Engineering and Methodology, July 1997.

15

computacionales activas, tales como: clientes, servidores, filtros, pizarras61, y las bases de datos. Los componentes pueden tener múltiples interfaces, en donde cada interfaz define un punto de la interacción entre un componente y su ambiente. (ejemplo, un servidor puede tener varias conexiones activas del http, con una interfaz y quizás un segunda interfaz de administración).

Conectores: Al igual que los componentes, es un elemento primario de una Arquitectura, representa las interacciones entre componentes. Proporcionan las uniones para los diseños arquitectónicos, y corresponden a las líneas en las descripciones que unen las cajas negras. Los conectores median las actividades de comunicación y coordinación entre los componentes. Los ejemplos, incluyen formas simples de interacción, tales como pipes (Unix), llamada a procedimientos remotos (RPC), y difusión de un evento. Los conectores también pueden representar interacciones complejas, tales como, un protocolo del servidor de un cliente, o un acoplamiento del SQL entre una base de datos y una aplicación. Los conectores tienen interfaces que definen los roles desempeñados por los participantes o actores en la interacción. A menudo no corresponden a elementos discretos del sistema en ejecución, es decir, rpc, protocolos, flujos, entre otros.

Sistemas: Representan diagramas de componentes y de conectores. En general, los sistemas pueden ser jerárquicos; los componentes y los conectores pueden representar los subsistemas, los cuales tienen sus propias arquitecturas internas62. Cuando un sistema o parte de él tiene una representación, es necesario explicar tanto las interfaces internas como externas.

Características: Representan la información adicional (más allá de la estructura) sobre las partes o elementos de una descripción arquitectónica. Aunque éstas se pueden expresar por diversos ADLs, varían considerablemente; se utilizan normalmente para representar, entre otros: aspectos adicionales, funcionalidades por anticipado, o requeridas en un diseño arquitectónico. Por ejemplo, algunos ADLs permiten calcular el rendimiento del procesamiento del sistema, el estado latente basado en estimaciones del funcionamiento de los componentes constitutivos y los conectores. En general, es deseable asociar características a cualquier elemento arquitectónico en una descripción (componentes, conectores, sistemas, y sus interfaces). Por ejemplo, una característica de una interfaz puede describir a un protocolo de interacción.

Estilos o Tipos: Representan a las familias de sistemas relacionados. Un estilo arquitectónico, define normalmente un vocabulario de los tipos de

61 Son generalmente conocidos por su nombre en inglés, blackboard.62 Las Arquitecturas de cada uno de los componentes, son conocidos como representaciones.

16

elementos del diseño como un sistema de componentes, de conectores, de puertos, de roles, de bloqueo, y de tipos de características, junto con las reglas para los casos que componen a cada tipo.

4.1.ESPECIFICACIONES DE LOS ADLS.

Se han dado a conocer variados Lenguajes de Descripción de Arquitecturas, pero por lo general y a modo de conclusión, ellos especifican los siguientes aspectos:

4.1.1. PROPIEDADES EXTRA - FUNCIONALES DE LOS COMPONENTES (NFR63).

Esto quiere decir que se especifica: rendimiento, capacidad, algunos supuestos sobre el entorno, confiabilidad, seguridad, throughput64, robustez, requerimientos de espacio, compatibilidad con estándares, entre otros.

4.1.2. NATURALEZA DE LAS INTERACCIONES ENTRE COMPONENTES.

El encapsulamiento de los componentes, considera el tipo de componente y los tipos de interacciones que soporta. La elección es en general independiente de la funcionalidad, pero deben ser encapsulados de formas compatibles si se espera y planifica la cooperación entre ellos.

5. ¿ARQUITECTURA DE SOFTWARE, UNA CIENCIA O DISCIPLINA65?

Existe actualmente una proliferación de actividades en torno a la disciplina de la Arquitectura del Software. Estas actividades se consideran una disciplina, pues el foco principal de ellas está en el estudio de las características de las arquitecturas existentes. En La Universidad de Carnegie Mellon66, los investigadores han identificado y descrito estilos de Arquitecturas encontrados en sistemas de software existentes.

Estos estilos determinan la macro Arquitectura de un sistema, lo que no quiere decir que al examinar con más detalle los componentes de mayor envergadura, se pueda llegar a concluir que tienen estilos híbridos, debido a que combinan las características predominantes.En el campo de la investigación de los Objetos, el estilo predominante es la utilización de los patrones de diseño, los cuales se revisarán en extenso en el Capítulo 2 de la presente Memoria de Titulación. Estos patrones Orientados a Objetos son las Micro Arquitecturas que facilitan la síntesis y el entendimiento de las arquitecturas macro.

63 Acrónimo de Non Funcional Requirements64 Rendimiento global de procesamiento del Sistema.65 Diccionario Online de la Real Academia Española. http://www.rae.es/66 Universidad de Carnegie Mellon, Estados Unidos. http://www.cmu.edu/

17

El análisis de las cualidades de calidad de las arquitecturas es un factor importante, en donde gran parte del trabajo se puede apreciar una vez realizado el sistema.

Un ejemplo de análisis arquitectónico fue realizado en el dominio de las herramientas de interfaz de usuario67. Los investigadores eligieron el atributo de modificabilidad para su análisis. Entonces seleccionaron una arquitectura de referencia ideal y un conjunto de benchmarks (ejemplo, cambio de un componente, tal como un toolkit o un menú) como base para la comparación.

6. INGENIERIZANDO68 LAS ARQUITECTURAS DE SOFTWARE.

Existe un gran aumento de las actividades en torno a la ingenierización de las arquitecturas de software. Se consideran dentro de estas actividades, el dirigir o gerenciar el proyecto, porque el foco principal está en la construcción de arquitecturas que apoyan el desarrollo de sistemas de alta calidad.

Muchos de estos esfuerzos de ingeniería se han centrado en desarrollar las Arquitecturas de Software para Dominios Específicos (DSSAs69), que son Arquitecturas para una familia de sistemas de uso en un dominio. DSSAs permite la ayuda para la reutilización de conocimientos en el diseño y de los componentes con la utilización de varios modelos (por ejemplo, estructural y de comportamiento).

El desarrollo y la aplicación de DSSAs permite ajustar o dar soporte a los modelos basados en la Ingeniería de Software, la cual considera el análisis del dominio y otras actividades relacionadas con la reutilización.

7. LENGUAJE DE REPRESENTACIÓN DE ARQUITECTURAS DE SOFTWARE (SARL70).

SARL es crítico para capturar el conocimiento asociado a un DSSAs. Por lo general, utiliza diseño, notaciones estructuradas y es Orientado a Objetos, pero no es un apoyo completo a un DSSAs. SARLs debe ayudar al entendimiento de variados stakeholders y aplicar el conocimiento del DSSA.

SARLs debe estar asociado a las herramientas que facilitan la composición, la generación, y el análisis de los sistemas derivados de un DSSA. Existe una gran variedad de SARLs que nacen ayudados y patrocinados por ARPA71. Varían

67 Kazman, Bass, Abowd, Webb “SAAM: A Method for Analyzing the properties of Software Architecture 16th ICSE May 199468 Éste término, se refiere principalmente, a que en la Ingeniería tiene métodos, y por ello son más ordenados que los Arquitectos, quienes son más liberales en tomar decisiones.69 Acrónimo de Domain Specific Software Architectures.70 Acrónimo de Software Architecture Representation Language.71 Acrónimo de Defense Advanced Research Projects Agency, http://www.darpa.mil.

18

extensamente en términos, en el sentido de qué estilos arquitecturales apoyan y qué formas de análisis se permiten.

¿Cómo incorporar los DSSAs en el proceso de desarrollo del software?, ¿Cómo los DSSAs se desarrollan en el dominio de modelos y/o la reingeniería de diseños existentes de algún sistema?, ¿Cómo se debería construir un caso de negocio para un DSSA? ¿Cómo se calculan los beneficios de los activos (conocimiento, componentes, herramientas)?, ¿Cómo se estiman los costos de desarrollo en un proceso basado en DSSA? “El poder resolver estas interrogantes, proporciona las líneas de estudio para una Tesis de Postgrado u otra reformulación de proyecto de memoria de título para pregrado”72.

8. ESTILO, PATRÓN O IDIOMA ARQUITECTÓNICO.

Esta clasificación está basada en la noción de estilos arquitectónicos73, es decir, la descripción centrada en los patrones de la organización de los componentes y los mecanismos de control utilizados para su coordinación. Estos patrones difieren en cuatro aspectos principales:

Modelo de Sistemas: Identifica el modo intuitivo en el cual se basa la arquitectura.

Tipo de Componentes: Características de índole computacional de los componentes para construir un sistema, dentro del estilo de la arquitectura.

Conectores: Definen el modo en que los componentes interactúan. Estructura de Control: Define la forma de cómo está organizada la

computación, es decir, cómo se procesan los datos.

Por medio de estas propiedades es posible estudiar y comparar los diferentes estilos arquitectónicos, y formalizarlos. De este modo, teniendo descripciones uniformes de las Arquitecturas disponibles, es posible determinar cuál resulta más adecuada para representar las características del problema a resolver.

Otro esquema más amplio es el propuesto por Gilbert Cockton’s74, quién presenta un esquema para el caso especial de sistemas interactivos, pero que puede ser proyectado a sistemas en general. Este esquema abarca cuatro dimensiones: orientación, topología, provisión de componentes, y propagación de datos y de control, a través, de las cuales pueden ser estudiadas las diferentes arquitecturas existentes.

8.1.DEFINICIÓN SEMIFORMAL DE ESTILO ARQUITECTURAL.

“Un estilo caracteriza una familia de sistemas que están relacionadas por compartir propiedades estructurales y semánticas”75.

72 Mg. Raúl Gómez G., Académico del Departamento de Matemática, ULS, 2005.73 Mary Shaw y David Garlan, “An Introduction of Architecture of Software”, CMU-CS-94-166, 1994.74 Gilbert Cockton’s, http://osiris.sunderland.ac.uk/~cs0gco/75 Mary Shaw y David Garlan, “An Introduction of Architecture of Software.”, CMU-CS-94-166, 1994.

19

“Un estilo arquitectónico es una descripción de los tipos de componentes y de los patrones de interacción entre ellos. Se puede considerar como un conjunto de restricciones sobre una arquitectura, que a su vez definen una familia de arquitecturas que la satisfacen”76.

8.2. IDENTIFICACIÓN DE UN ESTILO ARQUITECTURAL.

La identificación de un estilo arquitectural puede identificarse al responder un conjunto de interrogantes, las cuales se describen a continuación:

¿Cuál es el vocabulario de diseño, es decir, los tipos de componentes y conectores a utilizar o utilizados?

¿Cuáles son los patrones arquitecturales permitidos? ¿Cuál es el modelo computacional subyacente? ¿Cuáles son los invariantes esenciales del estilo? ¿Cuáles son algunos ejemplos comunes de su uso? ¿Cuáles son las ventajas y desventajas de utilizar este estilo? ¿Cuáles son algunas de las especializaciones comunes?8.3.RESUMEN DE LA CLASIFICACIÓN PROPUESTA POR DAVID

GARLAN.

Para David Garlan77, un estilo arquitectural define una familia de sistemas en términos de un patrón, dada su estructura organizacional. Más específicamente, un estilo arquitectural determina el vocabulario de los componentes y los conectores que pueden ser utilizados en una instancia de ese estilo, incluso como un conjunto de restricciones. Esto puede incluir las restricciones de orden topológico en las descripciones arquitectónicas (ej.: ningún ciclo). Otras restricciones indican qué hacer con las ejecuciones semánticas, y también puede ser parte de la definición del estilo.

Dado el marco referencial propuesto, se pueden identificar:

8.3.1. PIPELINE, TUBOS Y FILTROS78.

Conectores: Canales de transmisión de datos, transmiten las salidas de un filtro como entrada de otro.

Componentes: Filtros puramente computacionales, en donde, cada filtro tiene un conjunto de entradas y uno de salidas. Además, cada filtro lee un

76 Paul Clements, Bass y Kazman77 Reporte Técnico, “An Introduction to Software Architecture”, CMU-CS-94-166, 1994.78 M. J. Bach, “The Design of the UNIX Operating System”, Prentice-Hall, 1986.

20

flujo de datos en sus respectivas entradas y produce flujos de datos en sus salidas.

Modelo de Sistema: Mapeo de datos en datos. Estructuras de Control: Flujos de Datos. Invariantes: Sobre los filtros, ellos deben ser independientes, en particular

no deben compartir el estado con otros. No deben conocer la identidad de sus continuadores o predecesores. La corrección de la salida del sistema no debe depender del orden en el cual actúan.

Especializaciones: La utilización de pipelines en lugar de una red de pipe-and-filter. Con interconexiones acotadas y tipadas.

Propiedades: Permite entender, en especial al diseñador, las Entradas y Salidas, como composición de filtros individuales. Soporte para la reutilización: dos filtros cualesquiera pueden unirse para algún objetivo. Facilita el Mantenimiento: creación, actualización y reemplazo de filtros. Ayuda a la ejecución concurrente. Permite otros análisis especializados, tales como rendimiento del procesamiento.

Desventajas: Los sistemas conducen a menudo a una organización cuyos procesos son batch. Por medio de los filtros, los datos tienen un proceso incremental, y son intrínsecamente independientes; el diseñador se fuerza a pensar en cada filtro como abastecimiento de una transformación completa de los datos de entrada para producir la salida de datos, ya que este estilo no es muy apropiado para el manejo de sistemas o aplicaciones interactivas. Los pipes pueden ser obstaculizados, ya que deben mantener correspondencias entre dos pipes separados, pero con flujos relacionados. Debe forzarse en la implementación un MCD79 de los datos transmitidos.

Ejemplo:

Figura 2: Descripción de un Pipes de Unix80.

8.3.2. DATOS ABSTRACTOS Y ORGANIZACIÓN ORIENTADA A OBJETOS.

Modelo de Sistema: Mantención local del estado. Componentes: Administradores de datos. Conectores: Invocación a procedimientos. Estructuras de Control: Descentralizada.

79 Mínimo Común Múltiplo80 David Garlan, “An introduction to Software Architecture”, 1994.

21

Propiedades: Las mismas que proporciona el enfoque Orientado a Objeto, es decir, gracias a lo oculto de la representación del objeto es posible cambiar su implementación sin interrumpir a los objetos clientes.

Ventajas: Descomposición del problema en módulos. Desventajas: Un objeto debe trabajar recíprocamente con otro (vía llamada

de procedimiento), pero debe conocer la identidad de él. Esto se diferencia de los de los pipelines, en donde los filtros no necesitan conocer sus predecesores o sucesores para trabajar recíprocamente. La significación de esto es que siempre que la identidad de un objeto cambie, es necesario modificar el resto de los objetos que lo invocan explícitamente. En el lenguaje Orientado a Objetos, este proceso se conoce como la necesidad de cambiar la lista de la "importación" de cada módulo que utilice el módulo cambiante.

Ejemplo:

Figura 3: Descripción Datos Abstractos y Objetos.

8.3.3. INVOCACIÓN IMPLÍCITA, DIRIGIDA POR EVENTOS. Modelo de Sistema: Procesos reactivos independientes. Componentes: Procesos o módulos que generan eventos sin conocimiento

de los receptores. La interfaz del módulo, contiene a las variables, procedimientos, eventos y estados posibles. Un procedimiento puede invocarse de la forma usual. Un módulo puede asociar procedimientos con eventos del sistema y comunicar esta relación. Los procedimientos se invocan al anunciarse eventos relacionados.

Conectores: Invocación automática de procesos que han registrado interés en el tratamiento de eventos. Cada módulo puede anunciar eventos de su interfaz al sistema.

Estructuras de Control: Descentralizada, sin conocimiento mutuo. Invariantes: Los anunciantes de los eventos no saben qué módulos

responderán. Ventajas: La reutilización puede ser válida para cualquier módulo, es decir,

se puede incorporar un módulo en cualquier sistema solo, a la espera de los eventos del sistema en el cual se agregó. Puede reemplazarse, actualizarse, y modificarse cualquier módulo del sistema, es decir, existe la posibilidad de evolución.

22

Desventajas: Los módulos ceden el control sobre el cómputo realizado por el sistema. El intercambio de datos puede suceder junto con el evento o pueden existir áreas compartidas para interacción, rendimiento, y administración de recursos. Razonamiento sobre la corrección. Si la identidad del que proporciona algún recurso al sistema se modifica, deben ser cambiadas las interfaces de todos los módulos clientes. Si un componente anuncia un evento, no tiene la seguridad de que otros componentes responderán, y si así ocurriese no está en conocimiento de cuándo un componente terminará su ejecución. El rendimiento global y el manejo de los recursos pueden ser críticos. El razonar sobre la correctitud, puede ser problemático, puesto que el significado de un procedimiento que anuncie un evento dependerá del contexto, y de las interrupciones. Esto está en contraste con el razonamiento tradicional sobre las llamadas del procedimiento, las cuales solo necesitan considerar un procedimiento con las pre y post-condiciones cuando se razona sobre una invocación de éste.

Ejemplo: Entornos de programación: integración de herramientas; e interfaces de usuario: separar los datos de las aplicaciones que manejan los datos DBMS81, un ejemplo para asegurar la integridad.

8.3.4. REPOSITORIO. Modelo de Sistema: Datos Centralizados Estructurados. Componentes: Procesos Computacionales Puros; Fuentes de Conocimiento: paquetes independientes del conocimiento

dependiente de la aplicación. La interacción entre fuentes del conocimiento ocurre solamente por medio del blackboard; Estructura de Datos del Blackboard: estado de los datos de la solución del problema, organizados en una jerarquía dependiente del uso. Las fuentes del conocimiento realizan los cambios al blackboard que conducen incrementalmente a una solución del problema.

Control: conducido completamente por el estado del blackboard. Las fuentes del conocimiento responden oportunamente cuando los cambios en el blackboard los hacen aplicables.

Conectores: Acceso directo a datos e invocación a procedimientos. Estructuras de Control: Externa o interna. Ventajas: Los usos que se han visto tradicionalmente como arquitecturas de

pipes, se pueden interpretar más exactamente como sistemas de repositorios.

Ejemplo: Los sistemas de blackboard se han utilizado tradicionalmente para la interpretación del proceso de señales complejas, tales como discurso y reconocimiento de patrón82. También han aparecido en otras clases de sistemas que implican el acceso compartido a los datos mediante los agentes83. Los sistemas secuenciales de batch con bases de datos globales son un caso especial. Los ambientes de programación se organizan a

81 Data Base Manager System.82 H.P. Nii, “Blackboard System Parts 1 & 2”, AI Magazine, 198683 V. Ambriola, P. Ciancarini, C. Montangero, “Software process enactment in oikos”, 1990

.

23

menudo como una colección de herramientas, junto con un depósito compartido de programas y de fragmentos de programas.

Figura 4: Ejemplo Repositorio.

En el diagrama no hay representación explícita del componente de control. La invocación de una fuente del conocimiento es accionada por el estado del blackboard. El actual foco de control, y por lo tanto su implementación, puede estar en las fuentes del conocimiento, el blackboard, un módulo aislado, o en alguna combinación de éstos.8.3.5. TABLE DRIVEN INTERPRETERS (INTÉRPRETE CONDUCIDO

POR TABLAS).

Modelo de Sistema: Máquina Virtual. Componentes: Máquina de Transición de Estados. Conectores: Acceso directo a datos e invocación a procedimientos. Estructuras de Control: Transición de Estados Input-Driven.

Ejemplo:

24

Figura 5: Ejemplo Table Driven Interpreters.

8.3.6. NIVELES O CAPAS. Modelo de Sistema: Jerarquía de Capas. Componentes: Composición de procedimientos o funciones. Conectores: Llamadas a procedimientos visibles. Cliente Servidor. Estructuras de Control: Hebra simple. Ventajas: Apoya al diseño basándose en el aumento de los niveles de

abstracción, con el objetivo que los desarrolladores distribuyan el problema en una secuencia de pasos incrementales. Apoyan el crecimiento, como por ejemplo los pipelines, ya que cada capa interactúa con la mayoría de las capas superiores e inferiores; al momento de cambiar alguna función de una de las capas afecta a todas con las cuales interactúa. Ayuda a la reutilización; ejemplo: los Tipos de Datos Abstractos (TDA). Conduce a la posibilidad de definir interfaces estándares de la capa a los cuales diversos implementadores pueden construir. Ejemplo de ello es el modelo de la ISO de la OSI.

Desventajas: No todos los sistemas se pueden estructurar mediante capas. Si un sistema se puede estructurar lógicamente mediante capas, las consideraciones de funcionamiento pueden requerir un acoplamiento mayor entre las funciones de alto nivel y su implementación de bajo nivel. En el caso del modelo ISO, existen dificultades, ya que estos protocolos tienen un puente sobre varias capas. El hecho que éstos sistemas permitan una mayor interacción, hace muy difícil definir capas semindependientes, a diferencia de los pipes y los filtros, puesto que una capa debe apoyar a los protocolos específicos en sus límites superiores e inferiores. Pero también permite una interacción mucho mayor entre las capas, y permite la transmisión de dos vías de información.

Ejemplo:

25

Figura 6: Ejemplo Modelo de Capas.

8.3.7. ARQUITECTURA DE PROCESOS DISTRIBUIDOS.

Los sistemas distribuidos han desarrollado diversas organizaciones comunes para los sistemas de multiproceso84. Algunos se pueden caracterizar sobre todo por sus características topológicas, tales como organizaciones de anillo o de estrella. Otros se caracterizan mejor en los términos de las clases de protocolos entre procesos que se utilicen para la comunicación. No se puede dejar de mencionar el WWW85, que es un Sistema Distribuido a gran escala.

Una mención especial en estas arquitecturas la forman las denominadas Cliente/Servidor86. En estos sistemas, un servidor representa un proceso que proporciona servicios a otros procesos (los clientes). El servidor desconoce generalmente las identidades o el número de clientes que tendrán acceso en el tiempo de ejecución. Por otra parte, los clientes conocen la identidad de un servidor (o puede descubrirlo a través de otro servidor) y tienen acceso mediante Llamados de Procedimientos Remotos (RPC).

8.3.8. ARQUITECTURA DE RUTINAS Y SUBRUTINAS.

La organización primaria de muchos sistemas refleja el lenguaje de programación en el cual fue desarrollado. Para los lenguajes sin soporte para la modularización ésto da a menudo lugar a un sistema organizado alrededor de un programa principal y de un conjunto de subprogramas. El programa principal actúa como el conductor para los subprogramas, proporcionando habitualmente una guía de control para ordenar a los subprogramas con un cierto orden. (Top Down)

8.3.9. ARQUITECTURAS DE SOFTWARE PARA DOMÍNIOS ESPECÍFICOS.

Actualmente existe un gran interés para que las arquitecturas lleguen a ser una "referencia" para los dominios específicos. Estas arquitecturas proporcionan una

84 G.R. Andrews, “Paradigms for process interaction in distributed programs”, 199185 Acrónimo de World Wide Web, el mejor referente es el Consortium: http:// www.w3.org/86 A. Berson, “Client/Server Architecture”. McGraw Hill 1992

26

estructura de organización adaptada a una familia de usos, tales como, aeronáutica, comando y control, o sistemas de manejo del vehículo. Dando énfasis a la arquitectura al dominio, es posible aumentar la descripción de sus estructuras internas.

8.3.10. SISTEMAS DE TRANSICIÓN DE ESTADOS.

Una organización común para muchos sistemas reactivos es el sistema de Transición de Estados. Estos sistemas se definen en términos un sistema de estados y un sistema de las transiciones numeradas que mueven un sistema a partir de un estado a otro.

8.3.11. SISTEMAS DE CONTROL DE PROCESOS.

Los desarrolladores de sistemas proponen proporcionar control dinámico a un ambiente físico, y lo organizan a menudo como sistemas de control de proceso87.

Estos sistemas se caracterizan como lazo de regeneración, en el cual las entradas de los sensores sean utilizadas por el sistema de control de procesos, para determinar en un sistema las salidas que producirán un nuevo estado del ambiente.

8.3.12. ARQUITECTURAS HETEROGÉNEAS.

En los puntos anteriores se han explicado los estilos arquitectónicos puros, pero se sabe que los sistemas no lo son, y siempre existirán las combinaciones de los estilos arquitecturales, para la generación de una arquitectura que dé soporte al dominio y a la solución de un problema.

Un ejemplo de ello es Mediante las jerarquías, podría ser un pipe de Unix, en el cual los componentes individuales se pueden representar, pero internamente pueden utilizar un estilo en particular, pero incluso las jerarquías pueden ser descompuestas, permitiendo que un solo componente utilice una mezcla de conectores arquitectónicos. Por ejemplo, un componente puede tener acceso a un repositorio por medio de su interfaz, pero interactúa a través de los pipes con otros componentes en un sistema, y acepta la información de control a través de otra parte de su interfaz. Otro ejemplo es una "base de datos activa". Éste es un repositorio que activa componentes externos mediante la invocación implícita. En esta organización los componentes externos presentan interés en las tablas de la base de datos. La base de datos invoca automáticamente a las herramientas apropiadas basadas en esta asociación.

No cabe dudas que en este grupo de formas compuestas o indóciles a la clasificación en las categorías habituales. Es por cierto objetable y poco elegante que existan clases residuales de este tipo en una taxonomía, pero ninguna clasificación conocida ha podido resolver este dilema conceptual. Se podrían 87 K.J. Astrom and B. Wittenmark, “Computer Controller System Desig. Prentice Hall”, 1990

27

agregar formas que aparecen esporádicamente en la comunidad de desarrollo, como los sistemas de control de procesos industriales, sistemas de transición de estados, arquitecturas específicas de dominios88 o estilos derivados de otros, tales como, GenVoca89, C290 o REST91.

8.4.EL ROL DE UML.

El Lenguaje de Modelo Unificado, UML, es un meta-lenguaje de modelado, el cual sirve para Visualizar, Especificar, Construir, y Documentar un sistema, y es muy útil debido a que permite modelar los Patrones de Diseño, y por lo tanto una Arquitectura de Software basada en éste enfoque.

En el contexto de este trabajo, no se puede ignorar que UML es sólo un lenguaje, por ende, es independiente del proceso de desarrollo de software, el cual debería estar guiado por los casos de usos, centrado en la arquitectura, y con un ciclo de vida, de manera que sea incremental e iterativo.

UML es el producto de distintos métodos Orientado a Objetos y distintas notaciones, pero que tienen mucho en común. Éste meta-lenguaje combina notaciones del Modelado Orientado a Objetos, Modelado de Datos, Componentes, y Flujos de Trabajo92.

Cabe destacar que UML, no es una metodología, sino un lenguaje formal y visual. Con el tiempo se ha ido consolidando en ser el Lenguaje de Modelado Universal, en la Comunidad de Desarrollo de Sistemas.

UML se sustenta en el Enfoque Orientado a Objetos, y por ende tiene objetivos, de los cuales se destacan:

Proporciona un lenguaje visual de modelado expresivo, con el cual se pueden crear e intercambiar modelos inteligibles.

Provee mecanismos de extensión y especialización, para ampliar los conceptos básicos.

Es independiente de cualquier lenguaje de programación y de cualquier proceso de desarrollo.

Permite incluir fundamentos formales para comprender el metalenguaje. Ha impulsado el mercado de desarrollo de herramientas Orientadas a

Objetos. Soporta los conceptos de desarrollo de alto nivel, tales como

colaboraciones, frameworks, patrones, y componentes.

88 David Garlan y Mary Shaw. “An introduction to software architecture”. CMU Software Engineering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21, 1994.89 GenVoca es un acercamiento para construir sistemas generadores de software, basado en capas orientadas a los objetos que la componen. http://www.program-transformation.org90 Cunningham and Cunnigham, Inc, http://c2.com/91 Representational State Transfer, http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm92 Pese a que en la industria es conocido por su nombre en Inglés: Workflow.

28

Actualmente, la utilización de UML 2 se realiza tanto en el mundo académico como en la industria, y cual fue construido sobre UML 1.x, intentándose no reemplazar los elementos bajo ninguna razón. Los cambios que se realizaron fueron pensados para producir el menor impacto posible sobre los usuarios actuales de las versiones anteriores.

UML 2, tiene como objetivos principales resumir las especificaciones de requisitos, y además:

Soporta el desarrollo basado en componentes, incluyendo una definición completa para soportar diversos plugs ins.

Permite un modelado más completo del contexto de ejecución de componentes, especialmente necesarios ante la proliferación de middleware y aplicaciones Web.

Suministrar perfiles estándar o extensiones para algunos lenguajes de programación.

Soporta la implementación automatizada de patrones comunes de interacción.

El mejoramiento del Metalenguaje para la arquitectura en ejecución, incluyendo soporte de estructura interna, en especial, caminos de comunicación, además de la descripción del comportamiento dinámico de esta estructura interna.

Mejorar las máquinas de estado, con una especificación más clara de los enlaces al comportamiento y las reglas de especialización.

Mejorar los gráficos de actividad con un mejor control y con características de flujo de datos.

Soportar la composición de mecanismos de interacción, definición de las secuencias e interacciones, y alternar interacciones y ejecuciones paralelas.

A continuación, se puede visualizar una investigación, de las distribuciones gratuitas para el modelado en UML.

HerramientaUML

Studio Dia DOMEArgoUML

FUJABA mUML

Poseidon

Compañía Pragsoft Corporation

Dia Honeywell Tigris Universidad de Paderborn

MountField Computers

GentleWare

Plataforma WINDOWS LINUX, WINDOWS

SMALLTALK JAVAJAVA JAVA JAVA

29

Licencia Versión sin Licencia (con restricciones)

Libre Libre Libre

Libre Libre Libre

Diagramas Todos los diagramas UML menos diagramas de objetos y de despliegue.

Todos los diagramas UML menos diagramas de actividades, de despliegue y de objetos.

Todos los diagramas UML menos los diagramas de objetos y de componentes.

De Clases, de Estado, de Actividad, de Casos de Uso, de Colaboración

De Clases y de Actividades (Combinación de diagramas de Colaboración con los de Actividad y Estado)

Todos los diagramas UML

De Clases, de Estado, de Actividad, de Casos de Uso, de Colaboración.

Generación de Códigos

C++, JAVA, CORBA, IDL

NO Lo tiene que implementar el usuario

JAVA JAVA (para Clases y Actividades)

JAVA, CORBA, IDL

JAVA, HTML

GeneraciónDocumetación.

HTML y RTF

NO RTF, MIF, IAF,TXT, SGML

NONO SI SI

Ingeniería Inversa.

C++, JAVA, CORBA, IDL

NO Se implementa por el usuario.

NO

JAVA

JAVA (también desde bases de datos)

SI

Exportación Diagramas

bmp, jpg, png

SVG, EPS, PostScript, etc.

XWD bitmap, PostScript, RTF, MIF

GIF, PostScript, EPS, PGML, SVG

PostScript

JPEG, Página Web

GIF, PostScript, EPS, PGML, SVG

Tabla 7: Cuadro Comparativo de Distribuciones de UML.

9. CAMPOS DE ACCIÓN DE LAS ARQUITECTURAS DE SOFTWARE.

La Arquitectura de Software es hoy en día un conjunto, inmenso y heterogéneo, de áreas de investigación teórica y de formulación práctica, por lo que es conveniente mencionar algunos de sus campos y sus focos.

La Arquitectura de Software comenzó siendo una abstracción descriptiva puntual, que en los primeros años no se investigó de manera sistemática ni las relaciones

30

que la vinculaban con los requerimientos previos, ni los pasos metodológicos a dar para iniciar el diseño. Pero esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, a medida que pasa el tiempo, la Arquitectura de Software tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la Ingeniería de Software, sólo que a un mayor nivel de abstracción, agregando una nueva dimensión reflexiva en lo que concierne al proceso.

Hay pocas caracterizaciones, y mucha actividad de copiado y pegado en torno de las áreas que componen la actividad. David Garlan y Dewayne Perry93 indican las áreas de investigación más promisorias, entre las cuales están:

Lenguajes de Descripción de Arquitecturas, ADLs. Fundamentos formales de la Arquitectura de Software (bases matemáticas,

caracterizaciones formales de propiedades extra-funcionales, tales como mantenibilidad, teorías de la interconexión, etc.).

Técnicas de análisis arquitectónicas. Métodos de desarrollo basados en Arquitecturas. Recuperación y reutilización de Arquitecturas. Codificación y guía arquitectónica. Herramientas y ambientes de diseño arquitectónico. Estudios de casos relacionados.

En la concepción de Clements y Northrop94, el criterio de reusabilidad es el que más justifica a la disciplina misma. Para ellos, el estudio actual de la Arquitectura de Software puede ser visto como un esfuerzo para proporcionar un almacén estructurado de este tipo de información reutilizable de diseño de alto nivel, propio de una familia de sistemas. De esta manera, las decisiones de alto nivel inherentes a cada miembro de una familia de programas no necesitan ser reinventadas, revalidadas, y reescritas. Un razonamiento arquitectónico es, además, un argumento sobre las cuestiones estructurales de un sistema. El concepto de estilo es el indicio principal de reusabilidad en el plano arquitectónico.

Paul Clements95, define cinco temas fundamentales, en torno de los cuales se asocia la disciplina:

Diseño o selección de la arquitectura: Cómo crear o seleccionar una Arquitectura en base de requerimientos funcionales, de rendimiento, o de calidad.

Representación de la arquitectura: Cómo comunicar una arquitectura. Este problema se ha manifestado como el problema de la representación de arquitecturas, utilizando recursos lingüísticos, pero el problema también incluye la selección del conjunto de información a ser comunicada.

93 David Garlan y Dewayne Perry, “IEEE Transactions on Software Engineering”, abril de 1995.94 P. Clements, F. Bachmann, L. Bass, D. Garlan, “Sofware Architecture Documentation in Practice”, Addison Wesley 2001.95 P. Clements, F. Bachmann, L. Bass, D. Garlan, “Sofware Architecture Documentation in Practice”, Addison Wesley 2001.

31

Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cómo comparar y escoger entre diversas arquitecturas en competencia.

Desarrollo y evolución basados en arquitectura: Cómo construir y mantener un sistema, dada una representación de la cual se cree que es la arquitectura que resolverá el problema correspondiente.

Recuperación de la arquitectura: Cómo hacer que un sistema jerárquico evolucione, cuando los cambios afectan su estructura; para los sistemas de los que se carezca de documentación confiable, esto involucra primero una “arqueología arquitectónica96” que extraiga su arquitectura.

Mary Shaw expuso, en el 2001, que los campos más promisorios de la Arquitectura de Software siguen teniendo relación con el tratamiento sistemático de los estilos, el desarrollo de lenguajes de descripción arquitectónica, la formulación de metodologías, y ahora el trabajo con patrones de diseño. Se requieren todavía modelos más precisos, que permitan razonar sobre las propiedades de una arquitectura y verificar su consistencia y completitud, así como la automatización del proceso de análisis, diseño, y síntesis. Debe aprenderse una lección a partir de la experiencia de la Ingeniería de Software, la cual no obstante haberse desenvuelto durante treinta años, no ha logrado plasmar un conjunto de paradigmas de investigación comparable al de otras áreas de las Ciencias de la Computación. Se estima que la Arquitectura de Software se encuentra ya en su fase de desarrollo y extensión, pero que tanto las ideas como las herramientas aún no están maduras.

Un campo que no figura en el listado, pero sobre el cual se está trabajando intensamente, es en el de la coordinación de los ADLs que sobrevivan con UML 2.0, por un lado, y con XML, por otro. Ningún lenguaje de descripción arquitectónica en el futuro, con excepción de los que tengan un nicho técnico muy particular, será viable si no satisface esos dos requisitos.

Los ejercicios que pueden realizarse para precisar los campos de la Arquitectura de Software son incontables. Ahora que la Arquitectura de Software se ha enfocado en el desarrollo de metodologías, hace falta, por ejemplo, establecer con más claridad en qué difieren sus elaboraciones en torno del diseño, del análisis de requerimientos, o de justificación económica de las llevadas a cabo por la Ingeniería de Software.

No existe una lista sistemática y exhaustiva que describa los dominios de incumbencia de la disciplina, tal como un examen de riesgo de duplicación de 96 Se refiere principalmente a identificar una arquitectura preliminar, la cual puede ser básica, es decir, a un bajo nivel de detalle, ella se puede obtener mediante técnicas tales como, reingeniería de procesos.

32

esfuerzos entre campos disciplinarios mal comunicados, una situación que a primera vista parecería contradictoria con el principio de reusabilidad.

10.MODALIDADES Y TENDENCIAS

En la década de 1990 se establece definitivamente la Arquitectura de Software como un dominio todavía hoy separado de manera confusa de lo que es el desarrollo de sistemas, y, en particular, del diseño. Aunque no hay un planteamiento explícito y consciente sobre “Escuelas de Arquitectura de Software”, ni se ha publicado un estudio reconocido y sistemático que analice las particularidades de cada una, actualmente se pueden distinguir a grandes rasgos seis corrientes97.

Generar una taxonomía de estrategias no es una simple solución determinista. En distintos momentos de su existencia, algunos precursores y seguidores de la Arquitectura de Software se identifican ocasionalmente, de una táctica u otra, o evolucionan de un punto de vista más genérico a otro más particular, o realizan diferentes trabajos operando en marcos distintos. Además, con la excepción de una disputa metodológica existente entre los métodos pesados y ligeros, las discusiones entre las distintas posturas, no se han manifestado como choques frontales entre ideologías irreconciliables, por lo que a menudo se debe leer entre líneas para percatarse que una afirmación cualquiera es una crítica a otra manera de ver las cosas, o una toma de posición definida.

10.1. ARQUITECTURA COMO ETAPA DE INGENIERÍA Y DISEÑO ORIENTADO A OBJETOS.

Es el modelo propuesto por el Grupo de los Cuatro98, ligado estrechamente al mundo de UML y Rational Rose, ellos proponen que la Arquitectura se restringe a las fases iniciales y preliminares del proceso, y concierne a los niveles más elevados de abstracción, pero no está sistemáticamente ligada al requerimiento que viene antes, o a la composición del diseño que viene después.

Para este movimiento, la Arquitectura se confunde también con el modelado y el diseño, los cuales constituyen los conceptos dominantes. En esta corriente, se manifiesta predilección por un modelado denso y una profusión de diagramas, tendiente al modelo metodológico CMM o a UPM99; no hay, sin embargo, una prescripción formal. Importa más la abundancia y el detalle de diagramas y técnicas disponibles que la simplicidad de la visión de conjunto. Cuando se habla de estilos, se confunde con patrones arquitectónicos o de diseño100. No se hace referencia a los lenguajes de descripción arquitectónica, que representan uno de

97 Descritas en el punto anterior.98 James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman, y otros.99 CMM : Capability Maturity Model , UPM: Units of Product Measurement.100 Craig Larman. “UML y Patrones”. 2a edición, Madrid, Prentice Hall

33

los parámetros reconocidos de la Arquitectura de Software; sucede como si la disponibilidad de un Lenguaje Unificado de Modelado los considerara intrascendentes.

La definición de arquitectura que se promueve en esta corriente, tiene que ver con aspectos formales a la hora del desarrollo; esta arquitectura es isomorfa a la estructura del código de los componentes. Una definición típica y demostrativa sería la de Grady Booch; para él, “La Arquitectura de Software es la estructura lógica y física de un sistema, forjada por todas las decisiones estratégicas y tácticas que se aplican durante el desarrollo”. Otras definiciones revelan que la Arquitectura de Software, en esta perspectiva, concierne a decisiones sobre organización, selección de elementos estructurales, comportamiento, composición, y estilo arquitectónico, susceptibles de ser descritas a través de las cinco vistas clásicas del modelo 4+1101.

10.2. ARQUITECTURA ESTRUCTURAL, BASADA EN UN MODELO ESTÁTICO DE ESTILOS, ADLs Y VISTAS.

Constituye la corriente fundacional y clásica de la Arquitectura de Software como disciplina. Los representantes de esta corriente son todos académicos102, principalmente de la Universidad Carnegie Mellon, en Pittsburgh. Se trata, de la visión de Arquitectura de Software dominante en la Academia, la cual se ha esforzado en el reconocimiento de la Arquitectura de Software como disciplina; sus categorías y herramientas son todavía mal conocidas en la práctica industrial. En el interior del movimiento se pueden observar distintas divisiones. Hay una variante informal de “boxología”, y una vertiente más formalista, representada por el grupo del SRI103.

En principio, se pueden reconocer tres modalidades en cuanto a la formalización; los más informales utilizan descripciones verbales o diagramas de cajas negras, los de carácter intermedio utilizan los ADLs, y los más exigentes emplean lenguajes formales de especificación, tales como, CHAM104 y Z105.

En todas las corrientes, el diseño arquitectónico no sólo es el de más alto nivel de abstracción, sino que, además, no tiene por qué coincidir con la configuración explícita de las aplicaciones; rara vez se encontrarán referencias a lenguajes de programación o fragmentos de código, y, en general, no se habla de clases o de objetos.

10.3. ESTRUCTURALISMO ARQUITECTÓNICO RADICAL.

101 Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Software 12(6), pp. 42-50, Noviembre de 1995.102 Mary Shaw, Paul Clements, David Garlan, Robert Allen, Gregory Abowd, John Ockerbloom103 Mark Moriconi, Stanford Research Institute. 104 Chemical Abstract Machine105 http://www-users.cs.york.ac.uk/~susan/abs/z.htm

34

Se trata de un desprendimiento de la corriente anterior, mayoritariamente europeo, que asume una actitud más confrontacional con el mundo UML. En el seno de este movimiento existen al menos dos tendencias:

Excluye tajantemente la relevancia del modelado orientado a objetos para La Arquitectura de Software.

Busca definir nuevos metamodelos y estereotipos de UML como correctivos de la situación.

10.4. ARQUITECTURA BASADA EN PATRONES.

Si bien se reconoce la importancia de un modelo emanado históricamente del diseño Orientado a Objetos, esta corriente, surgida hacia 1996, no se encuentra tan rígidamente vinculada a UML en el modelado, ni a CMM en la metodología. El texto sobre patrones que esta variante reconoce como referencia es la serie POSA106 de Buschmann107, y secundariamente el texto del Grupo de los Cuatro108. La diferencia entre ambos textos de la comunidad de patrones no es menor; en el primero, la expresión “Software Architecture” figura en el mismo título; el segundo se llama Design Patterns: Elements of Reusable Object-Oriented Software, y su tratamiento de la arquitectura es mínimo. En esta manifestación de la Arquitectura de Software prevalece cierta tolerancia hacia modelos de procesos tácticos, no tan macroscópicos, y eventualmente, se acerca a las ideas de Martin Fowler y las premisas de la Programación Extrema, es decir, al concepto de modularidad o tareas y al nivel de detalle que se obtiene.

El diseño consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitecturales que trató en profundidad Mery Shaw y David Garlan109.

10.5. ARQUITECTURA ORIENTADA AL PROCESO O ARQUITECTURA PROCESUAL.

Nace a comienzos del siglo XXI, tiene como epicentro el SEI, y en conjunto con la participación de algunos de los arquitectos de Carnegie Mellon de la primera generación y muchos nombres nuevos, denominándola la segunda generación110.

En este tipo de Arquitectura, se busca establecer modelos de ciclo de vida y técnicas de clasificación de requerimientos, tormenta de ideas, diseño, análisis, selección de alternativas, validación, comparación, estimación de calidad, y justificación económica específicas para la Arquitectura de Software. 106 POSA: A System of Patterns.107 Buschmann et al, “Pattern-Oriented Software Architecture”, Wiley, 1996108 Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. “Design Patterns: Elements of reusable object-oriented Software”. Reading, Addison-Wesley, 1995109 David Garlan, “Reseca Directions in Software Architecture”, ACM Computing Surveys, vol 27, nº 2, Junio 1995.110 Rick Kazman, Len Bass, Paul Clements, Felix Bachmann, Fabio Peruzzi, Jeromy Carrière, Mario Barbacci, y Charles Weinstock.

35

Toda la documentación puede encontrarse ordenada en el SEI, pero no se mezcla jamás con la de CMM, la que se redefine completamente. Otras variantes dentro de esta corriente, se caracterizan por otras maneras de las etapas del proceso: extracción de arquitectura, generalización, reutilización111.

10.6. ARQUITECTURA BASADA EN ESCENARIOS.

Es la corriente más nueva. Se trata de un movimiento predominantemente europeo, con centro en Holanda. Recupera el nexo de la Arquitectura de Software con los requerimientos y la funcionalidad del sistema, ocasionalmente difuso en la Arquitectura Estructural Clásica.

Los teóricos y practicantes de esta modalidad de Arquitectura se inclinan dentro del canon delineado por la Arquitectura Procesual, respecto de la cual el movimiento constituye una especialización. En esta corriente suele utilizarse diagramas de casos de uso UML, como herramienta informal u ocasional, dado que los casos de uso son uno de los escenarios posibles.

Los casos de uso no están Orientados a Objetos. Los autores vinculados con esta modalidad han sido, aparte de los codificadores de ATAM112, CBAM113, QASAR114 y otros métodos del SEI, los arquitectos holandeses de la Universidad Técnica de Eindhoven115, de la Universidad de Amsterdan116, de la Universidad de Groningen117, y del Centro de Investigación de Philips. El números de científicos holandeses118 es significativo; la Universidad de Eindhoven es, el lugar en el que surgió la escuela arquitectónica de Dijkstra.

10.7. IDEAS COMPLEMENTARIAS Y CONCLUSIONES

En todos los simposios han existido intentos de fundación de otras variedades de Arquitectura de Software, tales como: una Arquitectura Adaptativa, inspirada en ideas de la programación genética o en teorías de la complejidad, la autoorganización, el caos y los fractales; una arquitectura centrada en la acción que recurre a la inteligencia artificial heideggeriana119 o al postmodernismo; y una

111 Sharon White y Cuauhtémoc Lemus-Olalde. “The software architecture process”. 1997112 Architecture Tradeoff Analysis Method.113 The Concerns-Based Adoption Model (CBAM): Especial para un modelo de cambios individuales. http://www.nas.edu/rise/backg4a.htm114 Standard for Quality and Safety Achievement Recognition. http://www.hq.nasa.gov/office/codeq/qasar/115 http://w3.tue.nl/en/116 www.uva.nl117 http://www.rug.nl/corporate/index118 Mugurel Ionita, Dieter Hammer, Henk Obbink, Hans de Bruin, Hans van Vliet, Eelke Folmer, Jilles van Gurp, Jan Bosch.119 Página Web, en la cual se puede encontrar una definición formal de Inteligencia Artificial heideggeriana http://www.geocities.com/fdomauricio/hei.htm

36

arquitectura epistemológicamente reflexiva que tiene a Popper o a Kuhn120 entre sus referentes.

Pero existe al menos un movimiento a considerar; es muy posible que pueda hablarse también de una anti-arquitectura, que en nombre de los métodos heterodoxos se opone tanto al modelado Orientado a Objetos y los métodos sobre la documentación impulsada por consultoras corporativas, como a la Abstracción Arquitectónica que viene de la academia. El Manifiesto por la Programación Agil121, destaca:

Los individuos y las interacciones están por encima de los procesos y las herramientas.

El software funciona por sobre una documentación exhaustiva. La colaboración con el cliente se ubica por encima de la negociación

contractual. La respuesta al cambio debe ser superior al seguimiento de un plan.

Hay muchas formas, de organizar las tendencias y las escuelas. Discernir la naturaleza de cada una puede tener efectos prácticos en el momento de comprender antagonismos, concordancias, sesgos, disyuntivas, incompatibilidades, y fuentes de recursos.

Nadie ha analizado los límites de una herramienta como UML o de los métodos ultra-formales; por ejemplo, los que se oponen a su uso por razones teóricas precisas, ya sea en la definición, o construcción, o desarrollo de una Arquitectura de Software.

11.ASPECTOS QUE DEBE CONSIDERAR UNA ARQUITECTURA DE SOFTWARE.

Desde la perspectiva propuesta por David Garlan122, la estructura, desde su perspectiva, entrega una visión del sistema en las decisiones a nivel superior del diseño, incluyendo aspectos, tales como, ¿Cómo el sistema se estructura de componentes que se complementan?, ¿Dónde están los principales caminos de interacción? y ¿Cuáles son las características dominantes de cada componente? Además, una descripción arquitectónica incluye idealmente la suficiente información para permitir análisis de alto nivel y valoración crítica.

La Arquitectura de Software desempeña normalmente un rol dominante como puente entre los requisitos y el código. Lo cual se puede representar por la figura siguiente.

120 Referencia Web de una propuesta de Arquitectura Reflexiva de Popper, http://dieumsnh.qfb.umich.mx/pensamientoC/popper.htm121 Mayor referencia en el apéndice de Métodos de Desarrollo.122 David Garlan, http://www.cs.cmu.edu/~garlan/

37

Figura 8: Rol de la Arquitectura de Software.

La Arquitectura obtenida proporciona una descripción o modelo del sistema, en el cual se exponen ciertas características, y se ocultan otras. Esta representación, es una guía intelectual manejable para la totalidad del sistema, permitiendo que los diseñadores razonen sobre la capacidad de un sistema de satisfacer ciertos requisitos, y sugiere un modelo para la construcción y la composición del sistema.

Para elaborar la Arquitectura del Software desde la perspectiva propuesta por David Garlan, se puede desempeñar un papel importante en por lo menos seis aspectos del desarrollo del software.

11.1. COMPRENSIÓN DE LA ARQUITECTURA.

La Arquitectura de Software, simplifica la capacidad de comprender sistemas, presentándolos en un nivel de abstracción, en el cual el diseño de un sistema pueda ser entendido fácilmente123. Además, su mejor descripción arquitectónica expone las restricciones de alto nivel de diseño, así como el futuro análisis para las opciones arquitectónicas específicas.

11.2. REUTILIZACIÓN.

El diseño arquitectónico puede servir de soporte para la reutilización. Actualmente ésta se centra generalmente en bibliotecas de componentes. Desde el punto de vista arquitectónico del diseño, además, la reutilización de grandes componentes (o de subsistemas) y también los frameworks, en los cuales los componentes pueden ser integrados. Tales frameworks reutilizables, pueden ser los Estilos Arquitectónicos del Software de Dominio Específicos124, los estándares de la integración de componentes, especialmente con el paradigma de la programación Orientada a Objetos, y los patrones arquitectónicos de diseño.

11.3. CONSTRUCCIÓN.

Una descripción arquitectónica proporciona un modelo parcial para el desarrollo, indicando los principales componentes de software y las dependencias entre ellos.

123 http://www.ece.utexas.edu/~perry/index.html124 Un ejemplo de ello son los Javabeans de Sun Microsystem Inc.

Requerimientos Arquitectura de Sw.

Código

38

Por ejemplo, una vista de las capas de una arquitectura documenta generalmente los límites de abstracción entre las partes de una puesta en marcha del sistema, identificando claramente las interfaces internas del sistema, y obligando a determinar qué partes de un sistema pueden confiar de los servicios proporcionados por otros.

11.4. EVOLUCIÓN.

La Arquitectura de Software puede exponer las diferentes dimensiones, a lo largo de las cuales se espera que un sistema se desarrolle. Haciendo explícitas las interfaces de un sistema, pueden comprenderse mejor las ramificaciones de los cambios, y estimar exactamente los costos de las modificaciones. Por otra parte, las descripciones arquitectónicas separan las preocupaciones por la funcionalidad de un componente, en el sentido de las conexiones e interacciones de él (o las interacciones con) entre otros componentes, distinguiendo claramente los componentes y los mecanismos que permiten que interactúen. Esta separación permite mecanismos de conexión y manejo de los cambios del desarrollo por funcionamiento y reutilización del sistema.

11.5. ANÁLISIS.

Las descripciones arquitectónicas proporcionan nuevas oportunidades para el análisis, incluyendo la comprobación de la consistencia del sistema125y126, la conformidad a las restricciones de un estilo, la conformidad a las cualidades de calidad127, un análisis arquitectónico de la dependencia, y los análisis de dominio específicos para las arquitecturas construidas en los estilos específicos.

11.6. GERENCIA O ADMINISTRACIÓN.

La experiencia ha demostrado un acertado éxito en los proyectos cuando se tiene una Arquitectura de Software como factor dominante en un proceso industrial de desarrollo de Software. La evaluación crítica de una arquitectura conduce a una mejor comprensión de los requisitos, de las estrategias de la puesta en práctica, y de los riesgos potenciales, en donde un factor importante son los stakeholders, a los cuales por lo general los satisface un ciclo de vida en espiral para el desarrollo, es decir, un ver para creer.

11.7. COMUNICACIÓN.

Una descripción arquitectónica sirve, como vehículo para la comunicación entre los stakeholders. Por ejemplo, las revisiones arquitectónicas del diseño permiten que los stakeholders expresen opiniones sobre características de relativa

125 Se verificó este estudio mediante la Utilización de Rapide (ADLs), el cual se basa en eventos y está diseñado utilizando el enfoque Orientado a Objeto.126 Mucha importancia en las etapas tempranas del desarrollo del sistema; se realizaron mediante la utilización de métodos formales, estudios de Allen y Garlan por los años 90.127 Puede ser realizado utilizado SAAM, perteneciente al CMU.

39

importancia o peso, y las cualidades de la calidad que deben ser considerados para evaluaciones sucesivas.

12.LA IMPORTANCIA DE LAS ARQUITECTURAS DE SOFTWARE HOY EN DÍA.

Aún, no se ha constituido un repositorio uniforme base de casos de estudios, del cual se puedan extraer conclusiones lo suficientemente claras, La Arquitectura de Software, ha resultado fundamental en la reducción de costos, evitando errores, encontrando fallas, implementando sistemas de misión crítica. Cada uno de los documentos que describen Lenguajes de Descripción Arquitectónica destaca su utilización exitosa en proyectos de gran envergadura, requeridos por organizaciones de gobierno o por grandes empresas. No hay lugar a dudas de la necesidad de una visión arquitectónica. Según Barry Boehm128:

“Si un proyecto no ha logrado una Arquitectura del Sistema, incluyendo su justificación, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo del desarrollo de los procesos y la mantención”129.

Se pueden mencionar algunas virtudes de las Arquitecturas de Software, las cuales se indican en la siguiente tabla:

Comunicación mutua. Representa un alto nivel de abstracción común, que la mayoría de los participantes, sino todos, pueden usar como base para crear un entendimiento mutuo, formar consenso, y comunicación.

Una descripción arquitectónica expone las restricciones de alto nivel sobre el diseño del sistema, así como la justificación de decisiones arquitectónicas fundamentales.Las decisiones tempranas de diseño representan las decisiones fundamentales de un sistema, y esos vínculos son un factor fundamental para el desarrollo, distribución y mantención del sistema.La arquitectura representa lo que el método SAAM130 busca, es decir, el desarrollo no puede proseguir hasta que los participantes involucrados aprueben su diseño.Restricciones constructivas. Una descripción arquitectónica proporciona lineamientos parciales para el desarrollo, indicando los componentes y las dependencias entre ellos. Por ejemplo, una vista en capas de una arquitectura documenta, generalmente, por los límites de abstracción entre las partes, identificando las interfaces principales, y estableciendo las formas en que se pueden interactuar.Reutilización o abstracción transferible de un sistema. Considera un modelo relativamente pequeño, intelectualmente tratable, de la forma en

128 http://sunset.usc.edu/people/barry.html, especialista en gestión de riesgo y creador del método COCOMO y del método de desarrollo en espiral129 Barry Boehm. “Engineering Context for Software Architecture.” Invited talk, First International Workshop on Architecture for Software Systems. Seattle, Abril de 1995130 SAAM, acrónimo de “A Method for Analyzing the Properties of Software Architectures”.

40

que un sistema se estructura, y sus componentes se entienden entre sí; este modelo es transferible por medio de sistemas; en particular, se puede aplicar a otros sistemas que exhiben requerimientos parecidos, y puede promover la reutilización a gran escala. El diseño arquitectónico permite el soporte para la reutilización de grandes componentes, o incluso de frameworks, en los que se pueden integrar nuevos componentes.Evolución. Puede exponer las dimensiones a lo largo de las cuales puede esperarse que evolucione un sistema. Haciendo explícitas estas delimitaciones perdurables, quienes mantienen un sistema pueden comprender mejor las ramificaciones de los cambios, y estimar con mayor precisión los costos de las modificaciones. Esas delimitaciones ayudan a establecer mecanismos de conexión que permiten manejar requerimientos cambiantes de interoperabilidad, prototipazo, y reutilización. Análisis. Las descripciones arquitectónicas proporcionan nuevas oportunidades para el análisis, incluyendo verificaciones de consistencia del sistema, conformidad con las restricciones impuestas por un estilo, conformidad con atributos de calidad, análisis de dependencias y análisis específicos de dominio y negocios.Administración. Los proyectos exitosos consideran una arquitectura viable como un logro clave del proceso de desarrollo industrial. La evaluación crítica de una arquitectura conduce a una comprensión más clara de los requerimientos, las estrategias de implementación, y los riegos potenciales.

Tabla 9: Virtudes de las Arquitecturas de Software.

La Arquitectura de Software se encuentra en una etapa aún formativa. Sus teóricos no se encuentran todavía en condiciones de asegurar que, “con este libro como guía, usted podrá producir, dentro de un plan predecible y un presupuesto razonable, el software de la más alta calidad posible”131. Los mejores arquitectos de software, en general, consideran que su disciplina es tentativa y que se encuentra en estado de estudio.

13.PROBLEMAS LATENTES DE LAS ARQUITECTURAS DE SOFTWARE.

Aunque la evaluación del desarrollo de las Arquitecturas de Software es positiva, se perciben desacuerdos y frustraciones en la disciplina. Para empezar, está muy claro que su definición original, formulada en círculos académicos guarda poca relación con la imagen que se tiene de la Arquitectura de Software en las prácticas de la industria.

Aún dentro del mundo académico, a menudo las presentaciones representan posturas teóricas particulares, que se quieren imponer por vía de la

131 Una clase de discución que llevó a Aron Trauring (http://www.aronst.org/Work/work.html) a lamentar que no hubiese algo así como una FDA (Food and Drug Administration), que fiscalice los mensajes publicitarios de los metodólogos.

41

argumentación. Muchas de esas posturas son más programáticas que instrumentales.

Un gran número de artículos y ponencias destacan el hecho de no llegar a una definición de La Arquitectura de Software, universalmente aceptada.

Algunos aspectos “negativos” fueron elaborados por Clements y Northrop132:

Los defensores de las distintas posturas tienen sus sesgos. Las definiciones propuestas para la Arquitectura de Software coinciden en su núcleo, pero difieren seriamente en los bordes. Algunos autores requieren que la Arquitectura incluya racionalización, mientras otros piden pasos para el proceso de construcción. Algunos exigen que se identifique la funcionalidad de los componentes, pero otros requieren que una simple topología es suficiente. Para comprender la definición de Arquitectura de Software, se torna esencial, entonces, conocer la motivación de sus responsables.El estudio de la Arquitectura de Software está detrás de la práctica, no liderándola. Éste ha evolucionado con la observación de los principios de diseño y las acciones que toman los diseñadores cuando trabajan en sistemas de la vida real. Ella es un intento de abstraer los rasgos comunes inherentes al diseño de sistemas, y como tal, debe dar cuenta de un conjunto de actividades, conceptos, métodos, estrategias, y resultados. Lo que en realidad sucede es que la Arquitectura de Software se redefine constantemente en función de lo que hacen los programadores.El estudio es relativamente nuevo. Aunque sus raíces se extienden en el tiempo; el campo de La Arquitectura de Software es realmente muy nuevo, como puede justificarse por el número de libros, conferencias,

132 Paul Clements y Linda Northrop. “Software architecture: An executive overview”. Technical Report, CMU/SEI-96-TR-003, ESC-TR-96-003. Febrero de 1996.

42

talleres, y literatura.Los fundamentos han sido imprecisos. El campo se ha destacado por la proliferación de términos inciertos. Por ejemplo, la arquitectura definida como “la estructura global de un sistema” agrega confusión en lugar de reducirla, porque implica que un sistema tiene una sola estructura.El término se ha mal utilizado. El significado de la palabra “arquitectura”, en su relación con la Ingeniería de Software, se ha ido diluyendo simplemente porque parece estar de moda. Es posible encontrar referencias a las siguientes “clases” de arquitecturas: específica el dominio, la megaprogramación, el destinatario, los sistemas, las redes, la infraestructura, las aplicaciones, las operaciones, la técnica, el framework, el aspecto conceptual, el de referencia, el empresarial, el C4I133, la de manufactura, lo de construcción, de máquina-herramienta. A menudo la palabra “arquitectura” se usa de maneras inapropiadas.

Tabla 10: Aspectos Negativos de las Arquitecturas de Software.

Hacia el año 2000, Richard Taylor134 y Nenad Medvidovic135 indicaban que da la impresión que la Arquitectura de Software se ha convertido en una moda que prometía más de lo que se podía realizar; además, puede terminar confundiéndose con los ADLs y con el diseño.

La arquitectura es una noción académica, y se ha transferido muy poca de la tecnología resultante a la industria, y cuando se ha realizado, ha faltado comunicación. Si los errores o interpretaciones ganan terreno, surge el peligro que los beneficios concretos y los resultados positivos de la investigación arquitectónica sufran las consecuencias136.

La concordancia entre la cantidad y calidad de vistas arquitectónicas, así como la falta de un mecanismo de coordinación formal entre las diferentes vistas, es un problema técnico que surge en la integración de las vistas y diagramas de UML, y en las recomendaciones de los investigadores y el personal de las empresas.

Un problema a tratar es la discrepancia en las definiciones de la Arquitectura de Software que prevalecen en la academia y las que son comunes en la industria, considerando tanto a los proveedores de software como a los equipos de

133 http://www.c4i.org, sitio del DOD de los Estados Unidos, acrónimo de Command, Control, Communications, Computers, and Intelligence.134 Instituto de Investigación del Software (SRI), de la Universidad de California Irving. http://www.ics.uci.edu/~taylor/ 135 Departamento de Ciencias de la Computacion de la Universidad de Southern California. Página personal: http://sunset.usc.edu/~neno/136 Richard Taylor, Nenad Medvidovic, Kennet Anderson, James Whitehead Jr, Jason Robbins, Kari Nies, Peyman Oreizy y Deborah Dubrow. “A component- and message-based architectural style for GUI software”. Reporte para el proyecto F30602-94-C-0218, Advanced Research Projects Agency, 1994

43

desarrollos en las empresas. Al respecto, Jan Bosch137 ha confeccionado una tabla de contrastes que seguramente podría enriquecerse con nuevas antinomias.

Academia IndustriaLa Arquitectura se define explícitamente.

Prevalece una comprensión conceptual de la Arquitectura. Las definiciones explícitas son mínimas, por lo general mediante notaciones.

Consiste en componentes y conectores.

No hay conectores explícitos (a veces hay soluciones en tiempo de ejecución).

Los ADLs describen la arquitectura explícitamente y a veces la generan.

Se utilizan lenguajes de programación.

Los componentes reutilizables son entidades de caja negra.

Los componentes son grandes estructuras de software, de alta complejidad interna, y no necesariamente encapsulados.

Los componentes tienen interfaces con un solo punto de acceso.

Las interfaces se proporcionan mediante entidades (clases en los componentes). Las entidades de interfaz no tienen diferencias explícitas.

Se da prioridad a la funcionalidad y a la verificación formal.

La funcionalidad y los atributos de calidad (rendimiento, robustez, tamaño, reusabilidad, mantenibilidad) tienen igual importancia.

Tabla 11: Contrastes entre la Empresa y la Academia.

No es conveniente sobredimensionar el contraste, prejuzgando que la academia está desconectada de la realidad industrial; por el contrario, la mayor parte de las herramientas académicas se elaboraron en el contexto de proyectos industriales y de gobierno, casi todos ellos de seguridad crítica y de gran envergadura. El número de problemas de consistencia detectados a tiempo (y que se hubiera manifestado sin guía arquitectónica) es inmensa. El problema consiste en el desconocimiento que la industria tiene de la Arquitectura académica, y en el denominar arquitectura a lo que sólo es diseño.

Todavía no se ha elaborado una apreciación ordenada de las dificultades enfrentadas por la disciplina. Algunas de ellas son fruto de los riesgos del mercado: por ejemplo, la escasa consideración de los ADLs, debido a las limitaciones de los lenguajes de modelado que compiten con ellos, o la baja atención que la industria concede a los métodos verdaderamente formales por poco que su utilización exija el dominio de una notación complicada. Pero a pesar que los ADLs o los métodos formales no han logrado abrirse camino, la Arquitectura de Software en su conjunto sí lo ha hecho, aunque la imagen que el público tiene de ella puede en algún sentido ser confuso, o estar contaminada por ideas difusas referidas a metodologías, o herramientas no necesariamente arquitectónicas.

14. EL ROL DEL ARQUITECTO DE SOFTWARE.

137 Profesor de Ingeniería de Software, Universidad de Groningen, Holanda. [email protected], http://www.cs.rug.nl/~bosch

44

Como ya se dijo anteriormente, el rol o la competencia del arquitecto del software es ser garante del proceso de gestación para el desarrollo del sistema o proyecto.

Según lo propuesto por Mary Shaw y David Garlan138, el rol del Arquitecto, se refiere principalmente a las decisiones estructurales, incluyen la organización a grandes rasgos, y la estructura global de control, los protocolos de comunicación, la sincronización, y el acceso a los datos, la asignación de funcionalidad a elementos del diseño, la distribución física, la composición de los elementos de diseño, la escalabilidad, el rendimiento, y la selección entre las alternativas de diseño.

La creación de la macro estructura no sólo depende del arquitecto, ya que su construcción, es en conjunto con otros stakeholders. Este equipo139, que en lo ideal debiera ser multidisciplinario, tiene como objetivo lograr construir un sistema que tenga un alto rendimiento, una alta calidad (visto desde varias perspectivas, pero en especial si se ajusta a los estándares de calidad de la empresa que desarrolla el sistema), que sea completamente funcional, verificable, con una “interfaz de usuario agradable”, altamente disponible, que sea correcta en la entrega de sus resultados, que sea extensible, y en especial, tolerante a los cambios, que sea robusto, de fácil mantención140, portable (problemas de compatibilidad por navegadores y sistemas operativos), seguro, y que el costo de producir el sistema cumpla con las características antes mencionadas.

El arquitecto de software, tiene la responsabilidad técnica en cada uno de los aspectos antes expuestos, él debe seleccionar entre los patrones arquitecturales y las tecnologías disponibles en ese momento. Es por ello que la arquitectura seleccionada o la creación de una arquitectura híbrida es el producto de las aptitudes, experiencias, y juicios del Arquitecto de Software, en conjunto con su equipo.

Pese que para algunos autores el Arquitecto puede llegar a ser el administrador del proyecto, desde el punto de vista del grupo COAL141, el arquitecto presenta la descripción de la Arquitectura, es decir, se puede desarrollar el sistema, sin encontrar ninguna sorpresa técnica importante que resolver; es ésta la justificación por la cual no debería ser jefe de proyecto, ya que ese puesto tiene más dificultades que tener a cargo la Arquitectura del Sistema. No cabe duda que el Arquitecto debe tener el apoyo irrestricto de la dirección del proyecto, con la finalidad de crear la mejor arquitectura posible, y lograr que la solución se ajuste a lo propuesto. Además, ese apoyo no debe ser acatado estrictamente por los demás integrantes del grupo, ya que el arquitecto debe tener la tolerancia de ser

138 “An introduction to software architecture”. CMU Software Engineering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21, 1994.139 Ver Apéndice Patrones de Coplien.140 “El software por sencillo que sea es difícil de mantener” Roger Pressman, Ingeniería de Software un caso práctico.141 Subgrupo del Laboratorio de Ciencias de Computación (LCC) del Instituto de Computación (InCo) de la Facultad de Ingeniería, Universidad de la República - Uruguay.

45

http://www.rau.edu.uy/

http://www.fing.edu.uy/inco

flexible para la incorporación de opiniones útiles de cualquiera de los integrantes del grupo.

Puede darse el caso de que en proyectos de gran envergadura se requiera más de un arquitecto, con el objetivo de crear y mantener la arquitectura.

El rol principal del arquitecto es dirigir y coordinar las actividades y los aspectos técnicos del desarrollo. El rol del arquitecto es más en amplitud que en profundidad; el arquitecto, en términos generales, es capaz de identificar los modelos necesarios, con su consiguiente estructura general, determinando en forma eficaz los componentes y cada una de sus interfaces, y por último, describir la Arquitectura.

Lo destacable del Arquitecto, es el desempeño en variados aspectos, y puede decirse incluso de diferentes disciplinas, tales como: la Ingeniería de Requisitos, el Análisis y Diseño, la Implementación, y el Ambiente. Pero en especial, las actividades relacionadas con el Análisis y Diseño, ya que las principales decisiones se realizan al inicio del proyecto. Si se midiese la cantidad de esfuerzo aplicada a cada iteración, se encontrará que es muy variada, ya que en algunas iteraciones su intervención puede ser muy relevante, y por ende, requerir un gran esfuerzo; en cambio, en otras iteraciones puede ser sólo de control, es decir, revisión de los avances y el ajuste de algunos detalles en los componentes, o verificación de la planificación.

A continuación se listarán las principales actividades que debería realizar el Arquitecto de Software:

14.1. ANÁLISIS ARQUITECTÓNICO:

El Arquitecto, debe ser capaz de:

Definir una Arquitectura candidata, considerando. como base, la experiencia y el conocimiento del dominio.

Debe definir los Patrones de Arquitecturas y las convenciones del modelado.

Definir la estrategia de reutilización de la Arquitectura propuesta. Indicar las pautas para realizar la planificación. Desarrollar una vista previa de la Arquitectura, para facilitar la visión del

sistema, explorando y evaluando opciones de arquitectura de alto nivel, todo esto con el objetivo de entregar una estructura general a cada uno de los stakeholders.

Tener siempre una postura investigativa, es decir, buscar nuevas tecnologías, y, si hay, algunos componentes que se puedan adaptar para el proyecto.

Definir una organización de alto nivel de los subsistemas, con lo cual se llega a la construcción de un modelo de diseño preliminar.

46

Identificar las abstracciones del proyecto, con el objetivo de atacar el dominio del problema en sí.

Desarrollar un modelo de desarrollo de alto nivel, es decir, proveer una base sustentable, tanto para la determinación de la vialidad de la implementación del sistema, así como también una estimación de los costos y esfuerzos asociados. Además, con lo anterior, se adquiere una mejor comprensión de la distribución geográfica de la complejidad del proyecto.

Identificar los mecanismos de análisis, es decir, definir los mecanismos que sirvan a los diseñadores para poder crear sus objetos.

Identificar las interacciones características del sistema, es decir, identificar los componentes, o, mejor dicho, su comportamiento.

Revisar y analizar los resultados, para que ellos sean completos y consistentes.

14.2. CONSTRUIR Y DETERMINAR LA VIALIDAD DE UN MODELO CONCEPTUAL:

Sintetizar al menos una solución que dé satisfacción a los requerimientos críticos para la arquitectura.

Un modelo conceptual, considera los siguientes aspectos:

Una solución, la cual puede ser solamente conceptual. Los requerimientos significativos de la arquitectura identificados al inicio del

proceso.

Con la construcción del modelo conceptual, se decide el enfoque con el cual se enfrenta al problema, siempre y cuando se utilicen las técnicas apropiadas para identificar los APOC142.

El modelo conceptual en etapa de construcción, sirve para identificar las nuevas tecnologías y los requerimientos necesarios para cumplir con los APOC definidos.

La viabilidad del Modelo facilita la verificación de los requerimientos críticos desde el punto de vista arquitectural, es decir, si realmente se puede construir o no; he aquí la importancia que debe tener el Ingeniero de Software.

La determinación de los criterios de evaluación, depende de los requerimientos a estudiar por los APOC.

Los requerimientos riesgosos siempre son convenientes negociarlos, debido a sus costos, alto riesgo, y características.

14.3. PRIORIZAR LOS CASOS DE USO.

142 APOC : A point of control, puntos de control o los hitos del software a los cuales se hace referencia en el libro de Roger Pressman.

47

Definir los escenarios apropiados, cada uno de ellos representa lo que puede llegar a ser fundamental en el desarrollo, con el objetivo de analizar cada iteración del proyecto, especialmente si se trabaja por módulos independientes ya definidos.

Los casos de uso, cubren en forma sustancial la Arquitectura definida.

Gracias a los casos de uso, se propone el contenido técnico funcional del proyecto y se logran diferenciar las iteraciones del proyecto, y si se cumplen las etapas propuestas.

La incorporación de información extra a cada caso de uso, permite la elaboración de la documentación de la Arquitectura de Software.

14.4. IDENTIFICAR MECANISMOS Y ELEMENTOS PARA EL DISEÑO.

El objetivo principal es refinar los mecanismos de análisis en mecanismos de diseño, en base a las restricciones impuestas o auto-impuestas por el entorno de la implementación.

Es necesario refinar los mecanismos de análisis y los de implementación, es decir, bajar los niveles de abstracción, con el objetivo de capturar las características de los servicios, pese a no estar aún diseñados, sin preocuparse de su proveedor.

Generar la debida correspondencia entre los mecanismos de diseño y los mecanismos de implementación.

Crear algún mecanismo de arquitectura, es decir, las guías de diseño, para luego identificar, documentar, y luego implementar los elementos, clases, subsistemas, interfaces, protocolos, señales, y eventos del sistema.

14.5. INCORPORAR ELEMENTOS DE DISEÑOS EXISTENTES.

Refinar la arquitectura, reutilizando todo lo que sea posible, con el objetivo de abaratar los costos de horas/hombres.

Identificar los problemas comunes y las soluciones comunes, es decir, la utilización de patrones de diseño, los cuales se tratarán en extenso en el Capítulo 2 del presente trabajo de Memoria de Título.

Incorporar los elementos significativos desde el punto de vista arquitectural en la vista lógica del problema.

Realizar ingeniería inversa a módulos, extrayéndolos de otros proyectos u otras fuentes.

Actualizar la organización del Modelo Conceptual y vistas lógicas.

48

14.6. ESTRUCTURAR EL MODELO DE IMPLEMENTACIÓN.

Establecer la estructura en la cual se implementará el proyecto.

Asignar las responsabilidades a los subsistemas de implementación y su contenido.

Generar una estructura inicial de modelo.

Ajustar los subsistemas de implementación, con el objeto de organizar los equipos de desarrollo y las limitaciones del o los lenguajes de programación.

Definición de las dependencias entre subsistemas.

Actualizar y validar la vista de implementación y el modelo de implementación.

14.7. DESCRIBIR LA ARQUITECTURA EN TIEMPO DE EJECUCIÓN.

Esta descripción tiene como objetivo el analizar los requerimientos de concurrencia, identificar los procesos críticos, tales como alguna consulta de alto costo, la cual dificulta el rendimiento, identificar el ciclo de vida de los procesos, y, por último, identificar cómo se distribuyen los principales elementos del sistema entre los variados componentes.

Analizar la concurrencia; en particular, es necesario ver si se justifica la programación paralela de los procesos.

Identificar con más detalles los procesos y hebras de control (threads).

Identificar cuándo un proceso o hebra de control se debe crear, y posteriormente destruir.

Identificar y documentar el mecanismo de protocolo de comunicación entre los procesos.

La identificación de los recursos que suelen ser escasos, con el objetivo de manejar los típicos atascamientos que suelen originarse.

Distribuir los elementos de diseño entre los procesos, es decir, determinar qué clases y subsistemas ejecutan cada proceso.

14.8. SER CAPAZ DE DESCRIBIR LA DISTRIBUCIÓN DE LA ARQUITECTURA.

El objetivo principal es identificar cómo la funcionalidad del sistema se distribuye entre los nodos físicos.

49

Solamente requerido para sistemas distribuidos.

Definir la configuración de la red, considerando protocolos y topologías.

Mediante la utilización de los nodos, es posible asignar los procesos a éstos, con el objetivo de distribuir la carga del sistema.

14.9. DESARROLLAR GUÍAS DE PROGRAMACIÓN Y DISEÑO.

Las guías de programación permiten describir ciertas convenciones para ser aplicadas al trabajo con algún lenguaje de programación, es decir, las disposiciones de comentarios, nombre de las variables, modificaciones, entre otros.

Lo anterior permite construir un sistema homogéneo desde el punto de vista del código o del desarrollador.

Una guía de diseño selecciona las áreas que son relevantes del sistema, obtenidas del análisis de éste.

Se deben considerar los aspectos relacionados con el ambiente de implementación, es decir, plataforma, interfaces de usuario, herramientas para el desarrollo, manejo de las bases de datos, entre otros.Documentar cada una de las decisiones en las guías de diseño.

A modo de conclusión, de las características que ha de cumplir el Arquitecto de Software, deben ser experiencia, tanto en el manejo del dominio del problema, como también, en el dominio de la Ingeniería de Software. Una segunda cualidad radica en que debe tener la capacidad de liderazgo para poder dirigir el esfuerzo técnico a través de los variados equipos, debe saber tomar buenas decisiones, y que se cumplan bajo la presión que ha de tener un proyecto. Una tercera cualidad y virtud, es su capacidad de comunicación, es decir, en el sentido de persuadir y obtener la confianza de sus dirigidos, ya que no puede ser un tirano, sino un hombre de consenso. Utilizando la tolerancia y teniendo sus objetivos claros en el desarrollo de sus variadas actividades, su trabajo debe estar enfocado a los resultados, no a las buenas intenciones, debe ser consecuente con lo que se tiene, y no ser un romántico soñador de bellos proyectos, y por último, la experiencia de ser un buen diseñador.

15.REVISIÓN DE UNA ARQUITECTURA DE SOFTWARE.

La revisión de una Arquitectura no debería variar sustancialmente en relación a otras revisiones, pero éstas deben realizarse en formato de reunión, con el objetivo de que interactúen algunos de los stakeholders, no cabe lugar a dudas que las revisiones y monitoreos de la Arquitectura es para obtener un proyecto de calidad.

50

Existen variados tipos de revisiones, dentro de las cuales se pueden destacar:

La revisión formal de un módulo se presenta a los interesados, esperando comentarios, ya sean éstos positivos o negativos, aprobaciones u objeciones.

La revisión por Inspección, es aquella en la cual los módulos son analizados en detalle, con el objetivo de encontrar errores y otros problemas, e incluso puede considerar los defectos.

La revisión por “Recorrida”, es el proceso en el cual un desarrollador guía, o jefe de componente guía a un equipo de desarrolladores mediante el código de su propiedad; El equipo revisor interroga y realiza comentarios al presentador, difiere del equipo SQA, ya que ellos solo se encargan de una revisión binaria.

Aplicación de los patrones organizacionales de Coplien.

Las distintas revisiones al realizarse en forma cruzada entre los distintos equipos conforman una revisión mediante un modelo SQA, pero estas revisiones cruzadas permiten compartir principalmente diseños y códigos, para luego dar solución a los errores y defectos encontrados; además, permite una mayor coordinación entre los variados grupos, y por último, proporciona la posibilidad de reutilización.

En éstas reuniones pueden ingresar los aprendices del proyecto, es decir, personal que no tiene la experiencia de desarrollo, pero sí pueden escuchar mucho y hablar poco, con el único objetivo de aprender.

Las revisiones no son una simple reunión, deben tener objetivos y alcances, deben ser planificadas, es decir, se deben considerar las preguntas que se realizarán, qué se revisará, y por qué. Claramente, para cada fase o iteración del proyecto se tienen distintas preguntas. En una reunión formal, cada participante tiene su rol claramente predefinido, y debe existir un concenso entre expertos técnicos, y los expertos del dominio del problema.

El personal que debe haber en las revisiones va desde tres a siete143; si ellos son elegidos en forma apropiada, serán capaces de identificar problemas. Si se tiene más personal, lamentablemente baja el nivel de la calidad de la revisión, ya que se hace demasiada extensa, y dificulta la participación, ya que muchas ideas pueden ser poco coincidentes, y pueden agregarse discusiones y asuntos externos al proyecto. Pero un número menor de personal al propuesto tiene el riesgo de no visualizar los problemas, y no existir las necesarias perspectivas del producto.

La ejecución de la revisión debe tener un orden en el cual se consideren los roles de un moderador, secretario, presentador, y revisor; si el último encuentra un problema, se discute y analiza para una pronta decisión; en cambio, en algunos equipos de desarrollo, un defecto se identificada para luego ser atendido, con lo que se puede perder tiempo demasiado valioso.

143 Ver apéndice patrones de Coplien

51

Según los expertos en la revisión de calidad144, se deben considerar las siguientes recomendaciones: tener claro el componente a revisar, que cada integrante del equipo tenga claro su rol, siempre contar con un moderador, las reuniones deben ser bien pautadas y breves, y por último, identificar problemas y no buscar la solución dentro de la reunión, pero sí asignar responsables para la solución futura.

No cabe duda que una revisión es inconducente si no se encuentran problemas, es por ello que al finalizar una reunión, se deben priorizar la lista de problemas, para luego crear los mecanismos de seguimiento, y luego darles solución. Es propicio asignar comisiones reducidas, pero no resolutivas, para indagar respecto a asuntos inconclusos. Designar a los responsables apropiados para solucionar aquellos problemas que son factibles de solucionar en esta iteración, no esperar la siguiente, con el objetivo de ganar tiempo. Los problemas pendientes o errores que se puedan identificar para las próximas reuniones, y deben ser documentados.

Cabe destacar que la responsabilidad sobre un problema no indica resolverlo, ya que la responsabilidad puede ser la coordinación de una investigación adicional y acciones a futuro.

La revisión de una Arquitectura de Software es un problema complejo, ya que no se tienen medidas para muchos de sus atributos; por ejemplo, el rendimiento es cuantificable, pero la integridad conceptual es altamente subjetiva, y es por ello que la Arquitectura de Software es muy difícil de evaluar, ya que no se dispone de referencias claras.

El momento en que se realiza cada revisión, debe ser mediante la utilización de enfoques de representación, información, y escenarios propuestos, ya que afecta el propósito y la utilidad de la Arquitectura de Software, como se indica en la siguiente figura.

Figura 12: Revisión de una Arquitectura de Software.

En la siguiente tabla se proporcionan los detalles para comprender la figura antes propuesta

REVISIÓN DESCRIPCIÓN1 La Arquitectura es poco descriptiva. La revisión puede

revelar objetivos poco realistas, componentes faltantes, y la

144 Apruss plus, en Chile es un ejemplo.

52

no consideración de la reutilización de componentes existentes.

2 Es el momento preciso para identificar el verdadero valor de la Arquitectura, ya que ésta etapa se centra en identificar claramente los requerimientos, para luego llegar a los cimientos de ella. La revisión en este hito es obligatoria, pues aquí se revisan la mayor cantidad de cualidades de ella.

3 Durante esta fase se puede analizar la valoración de cualidades específicas, tales como el rendimiento. Al final de esta fase, se puede decidir si el producto realizado hasta el momento es posible de operar y si cumple con lo solicitado.

4 Al final de la construcción, e incluso en la transición, pueden llevarse a cabo valoraciones de control de daños. Esto suele realizarse cuando existen problemas graves, tales como el no término apropiado del producto. Una gran cantidad de problemas inaceptables aparecen con la instalación de éste último.

5 Es posible realizar una revisión final de la fase de Transición, con el objetivo de realizar un catastro de los componentes reutilizables, ya sea para un nuevo proyecto o una evolución del ya finalizado.

Tabla 13: Explicación Proceso de Revisión.El rol de revisor de la Arquitectura consiste en planificar y realizar las revisiones de ésta en general, y puede llegar a tener un rol similar al del arquitecto, pero mayoritariamente encargado del área técnica. Su principal misión es generar un balance entre los riesgos y los costos.

El objetivo de revisar la Arquitectura es detectar las discrepancias entre lo que se tiene y los requerimientos, es decir, el recordar requerimientos omitidos, migraciones, instalación, etc. Permite la evaluación de las cualidades de la Arquitectura, es decir, rendimiento, confiabilidad, modificabilidad, seguridad, e identificación de la posibilidad de reutilización.

A modo de conclusión, el propósito final de revisar la Arquitectura es descubrir riesgos para la planificación y presupuesto. Así como también el detectar cualquier falla o defecto en el diseño de ésta, pese a que son muy difíciles de corregir.

16.DOCUMENTACIÓN DE UNA ARQUITECTURA DE SOFTWARE, SAD145.

La Documentación provee una vista global de la Arquitectura, ya que es un medio de comunicación entre el Arquitecto y el resto del equipo de desarrollo, ya que utiliza diversas vistas para revelar diferentes aspectos de la Arquitectura propuesta, como también esta documentación debe contener información que no se puede obtener en las vistas.

145 SAD: Software Architectural Documentation

53

Las versiones iniciales del SAD se generan principalmente durante la etapa de gestación146 del proceso, etapa en la cual se documentan las guías de representación arquitectónica y una versión inicial de los casos de usos, pese a que la construcción del SAD se realiza principalmente en la etapa de Elaboración del proyecto, y se refina en la fase de Construcción.

En primer lugar, se debe realizar la elaboración de las vistas de los casos de usos147, ya que ellos pueden marcar las restricciones del sistema, y posteriormente la elaboración de las otras vistas, tales como la implantación, la distribución física, entre otras. En sistemas que contengan cierto nivel de concurrencia y de distribución, las vistas de procesos y despliegue se consideran en primer lugar.

La estructura y el contenido del SAD, siempre debe adaptarse a la naturaleza del proyecto en la cual se va a utilizar, ya que cada sistema tiene alguna vista que lo describe mejor, es por ello que la vista más completa es la que describe mejor el problema; en algunos casos, algún tipo de vista puede ser irrelevante; un ejemplo de ello es determinar para qué se requiere una vista de despliegue en un sistema monoprocesador, o una vista de proceso, si se trata de un sistema con una sola hebra de control.

No cabe lugar a dudas que como hay vistas que se pueden prescindir, hay otras que pueden ser necesarias, como por ejemplo, si se trata de un sistema en el cual la persistencia es relevante, o cuando el mecanismo de persistencia requiere de un mapeo entre los datos persistentes o no, en cuyo caso se requiere de una vista de los datos. Otro lo proporcionan los sistemas orientados a los servicios, que requieren adicionar la vista de servicio con el objetivo que el SAD sea mejor comprendido.

Algunos aspectos de la Arquitectura que es necesario destacar, pueden requerir de su propia sección, por ejemplo, la administración de los datos y la usabilidad. Pueden agregarse apéndices para explicar ciertos aspectos, tales como: decisiones críticas tomadas, soluciones descartadas, principios generales de diseño, y otras. El SAD puede variar según sean los grupos de desarrollo.

En primer lugar, dentro de la estructura que debe tener el documento, debe presentarse la contextualización del sistema, la cual está provista de una vista previa del documento completo, identificándose los elementos que aparecen en la tabla a continuación.

Propósito Describe brevemente la estructura de la documentación, pero debe identificar claramente hacia quien está dirigida, e indicar cómo se espera que sea utilizada, es decir, no se pueden definir guías de diseño cuando esta documentación se pretende entregar al cliente.

Alcance Una breve descripción sobre qué trata el documento y

146 Conocido por su nombre en Inglés, Inception.147 En Sonda Chile, la declaración de un caso de uso, es un documento de análisis de sobre 40 páginas por caso de uso.

54

sobre qué factores afecta este documento.Definiciones y Acrónimos

Deben estar identificadas cada una de las notaciones y abreviaciones indicadas en el documento, a modo de glosario o apéndice, con el objetivo que el documento sea comprendido.

Referencias Deben ser listados los documentos referenciados y cómo obtenerlos; cada documento debe tener título, fecha, y organización que publica.

Revisión Describe qué contiene el documento y cómo está organizado.

Tabla 14: Elementos de un SAD.

En la representación de la Arquitectura, es necesario indicar cómo se representa, es decir, mediante las vistas que son utilizadas, y cada una de ellas indica qué elementos del modelo son utilizados.

El objetivo de cada una de las vistas es describir de manera eficiente los requerimientos que tienen cierto impacto en la Arquitectura, es decir, seguridad, privacidad, productos inconclusos, portabilidad, distribución, y reutilización. Además, las distintas vistas permiten identificar las estrategias de diseño e implementación, estructura y organización del grupo de desarrollo, herramientas a utilizar, códigos ligados, planificación, etc.

A continuación se presenta un punteo con una breve descripción de los elementos a considerar para cada una de las vistas a utilizar para la confección del SAD.

16.1. VISTA DE CASOS DE USO

Son utilizados para describir el resto de las vistas de la Arquitectura. Cada Caso de Uso se compone de:

Nombre representativo. Descripción. Actores participantes Flujo de eventos, es decir, pueden ser todos los escenarios, algunos, o en

el peor de los casos, ninguno. Descripción de los requerimientos especiales, por ejemplo, requerimientos

no funcionales relacionados con el caso de uso. Descripción de las relaciones con otros casos de usos. Puede incluir imágenes de la interfaz de usuario que ayuda a describir el

caso de uso. Las realizaciones de los casos de usos.16.2. VISTA LÓGICA.

55

Describe la estructura lógica en un nivel alto de abstracción del sistema completo; pero la realización de los casos de usos mediante las vistas de ellos, deben tratarse en un bajo nivel.

Puede utilizarse mayor cantidad de niveles de abstracción, si es necesario, para tener el manejo del dominio del problema.

Debe ser consistente con los Elementos del Modelo en el Diseño.

Presenta la descomposición del sistema en subsistemas y paquetes, permitiendo esta descomposición gracias a la utilización de patrones.

Pueden incluirse más niveles de refinamiento para los subsistemas y paquetes, generalmente hasta llegar a los niveles de abstracción más bajos.

El menor nivel de abstracción muestra la descomposición de los subsistemas y paquetes, incorporando los elementos más significativos, los que generalmente se presentan en término de clases.Esta vista presenta cómo funciona el sistema realmente, mostrando el desarrollo de los casos de usos, en las vistas de ellos.

Los elementos significativos se pueden identificar cuando:

Representan una abstracción importante del dominio del problema Son utilizados por varios elementos Encapsulan un mecanismo del sistema Participan en las interfaces con el Sistema Operativo. Implementan un patrón estructural Impacto en el rendimiento del sistema.

Los elementos significativos del sistema evolucionan en las primeras iteraciones del proyecto, ya que al iniciar el desarrollo se descubren las dificultades técnicas.

Los elementos significativos deben estabilizarse lo antes posible, ya que son el esqueleto del sistema.

A lo más el 10% de los elementos deben ser consideradas significativos, ya que el concepto de arquitectura se diluye, ya que todo sería arquitectura.

16.3. VISTA DE PROCESO.

Describe la estructura de procesos completamente.

Considera sólo las hebras más significativos.

Se organiza en subsistemas de procesos.

56

Describe los principales mecanismos de comunicación entre los procesos, es decir, el envío de mensajes, interrupciones, rendezvous.

Presenta la distribución de elementos de la vista lógica a procesos, ya que permite visualizar aspectos de sincronización.

Utiliza el paralelismo, principalmente cuando sea un requerimiento.

Pueden necesitarse hebras propias de ejecución cuando:

Un objeto actúa de interfaz con un dispositivo o un sistema externo. Ciertas tareas deben ser realizadas después que el usuario finalizó su

tarea, por ejemplo el envío de un mail de notificación.

Para cada subsistema de proceso se muestran:

Los procesos que contiene y sus threads más significativos. Los elementos de la vista lógica que le corresponden. La interacción entre los procesos y therads.

Para cada proceso se describe, el comportamiento, ciclo de vida y las características de su comunicación.

16.4. VISTA DE IMPLEMENTACIÓN.

Describe la estructura general del Modelo de Implementación.

Se organiza en subsistemas de implementación.

Presenta el mapeo de los subsistemas, paquetes y clases de la vista lógica hacia subsistemas y componentes de implementación.

Solamente presenta el nivel de los componentes de despliegue.

Puede mostrarse cómo los componentes de despliegue están compuestos por otros componentes de despliegue.

Muestras las dependencias entre subsistemas y componentes.

16.5. VISTA DE DATOS.

Describe los elementos persistentes más significativos del Modelo de Datos.

57

Presenta una vista previa de los Modelos de Datos y su organización en término de tablas, vistas, índices, y otros.

Describe el mapeo de clases persistentes de la vista lógica a las estructuras de datos de la Base de Datos.

Esta vista considera: El mapeo de clases de diseño claves, principalmente cuando éste no es

trivial. Las partes significativas del sistema que fueron implementadas en las

bases de datos, a modo de gatilladores148 y procedimientos almacenados. Decisiones importantes de otras vistas que tengan implicancias sobre los

datos, como por ejemplo la elección de la estrategia transaccional, distribución, y concurrencia.

La estructura física de la Base de Datos, especialmente cuando ésta es distribuida.

16.6. VISTA DE DESPLIEGUE.

Presenta una o más configuraciones físicas sobre las cuales se hará el despliegue y el cómo se ejecutará el sistema.

Da a conocer la distribución del procesamiento a lo largo de dichos nodos, en correspondencia con los elementos de la vista de procesos.

Se muestra la ubicación física de las instancias de componentes de la Vista de Implementación en la infraestructura concreta de producción.

Comúnmente abarca la infraestructura informática completa de la organización.

Para cada configuración se debe incluir:

Los nodos y sus interconexiones. Los dispositivos más significativos. Las características más relevantes de ellos.

Debe considerar, además, los mapeos:

Los procesos de la vista de procesos a los nodos. Los componentes de despliegue de la vista de implementación a los nodos. Los elementos de la vista de datos a los nodos.

No todos los mapeos son obligatorios.

Pueden mostrarse cada uno con un diagrama diferente.

16.7. TAMAÑO Y DESEMPEÑO.

148 Generalmente se conoce por su nombre en Inglés Triggers.

58

Se describen las principales características del tamaño del sistema y las restricciones de desempeño que impacten en la Arquitectura.

Las cualidades se describen en términos de requerimientos.

Para cada requerimientos se adjunta una discusión respecto de cómo la Arquitectura da soporte.

Considera los siguientes aspectos:

La cantidad de elementos significativos que el sistema deberá mantener. Las restricciones claves de desempeño, como por ejemplo, el tiempo

promedio de respuesta a eventos importantes, tasas máximas y mínimas de procesamiento.

Tamaño de los ejecutables y la cantidad de consumo de memoria, en especial si se trata de un sistema empotrado.

El propósito de la descripción de cada una de las vistas (las cuales provienen de UML), es para describir cómo la arquitectura contribuye a todas las cualidades del software, ya que se listan las principales cualidades que impactan a la Arquitectura.

59

CAPÍTULO 2: PATRONES

1. INTRODUCCIÓN

Para entender el concepto de patrones, se debe remontar a la década de los 70, cuando el arquitecto alemán Christopher Alexander los aplicó a su campo profesional, llegando a concluir que “Un patrón describe una solución correcta para un problema frecuente, el cual debe estar expresamente descrito, dentro del contexto en el cual será utilizado149”.

Cada patrón, describe un problema que ocurre una y otra vez, luego se proporciona lo modular de la solución a éste, de tal manera que se pueda utilizar en otras ocasiones.

149 “A Pattern Language: Towns, Buildings, Construction”, Oxford University Press, 1977 y “The Timeless Way of Building”, Oxford University Press, 1979

60

Pero el objetivo de compartir las soluciones se remonta ya en los años 50, cuando se publicaron los primeros libros que agrupaban problemas recurrentes y la descripción de los algoritmos150 que los solucionaban151.

Además de los patrones, también coexisten los antipatrones, los cuales se pueden definir como una solución que aparece como respuesta a algún problema, pero no es la mejor forma de solucionarlo, tal como se ha comprobado.

A continuación, se presentará una mirada histórica, en donde el surgimiento de los patrones de diseño ha marcado un hito en el desarrollo de las aplicaciones computacionales, para luego clasificar y describir los distintos patrones identificados.

2. DESARROLLO HISTÓRICO

Para comprender el concepto y el desarrollo histórico de los Patrones, se debe disponer de algunas definiciones, tales como, Algoritmos, Estructuras de Datos, y Objetos, los cuales son tratados brevemente en el apéndice denominado “Desde los Algoritmos a los Patrones.”

Cuando el profesor Carlos Vizcaíno152 en su cátedra exigía a cada uno de sus dirigidos “…educar a nuestra gente en la reutilización de objetos, en el ensamblado de componentes de Software”, como gran solución al desarrollo en la industria del Software en México, a muchos, y en especial para Hanna Oktaba153, les parecía una tarea imposible, pero actualmente es factible mediante los patrones, los cuales se describen como una solución genérica a los problemas planteados por la programación orientada a objetos154.

3. DEFINICIÓN

En la etapa de diseño de aplicaciones computacionales la literatura se sustenta en base al trabajo desarrollado por el arquitecto alemán Christopher Alexander, durante los años 70155.

150 Algoritmo: conjunto de pasos finitos con un orden lógico que da solución a un problema determinado151 Donald Kunth, “The Art of Computer Programming”, 1973.152 Carlos Viscaíno Sahagún, Universidad Autónoma de México, “La verdadera importancia de los Objetos”, Número 20 año 1995.153 Universidad Autónoma de México., http:// www.unam.mx/154 Ver Apéndice desde Algoritmos a Patrones.155 Chistopher Alexander, “A Pattern Language: Towns, Buildings, Construction, Oxford University Press”, 1977 y The Timeless Way of Building Oxford University Press, 1979

61

Las ideas presentadas por Alexander, son aplicables en distintos campos, incluyendo el software. En 1987, Ward Cunningham y Kent Beck utilizaron algunas de las ideas de Alexander, y desarrollaron cinco patrones para el diseño de interfaces de usuario (UI)156. Pero no se debe olvidar que el desarrollo orientado a objetos debe su éxito al incremento de la calidad del software, escrito bajo este enfoque, haciéndolo más flexible, modular, reutilizable, y comprensible.

Gracias a las clases y a los objetos, se han podido encapsular las abstracciones, dividir la realidad, y, lo más importante, disminuir la complejidad. Incluso todos los esfuerzos de los analistas han consistido en resolver los problemas en forma más explicita.

La existencia de los patrones ha proporcionado la posibilidad de organizar las clases en estructuras comunes y bien probadas, modificando las aplicaciones para mejorar su flexibilidad y extensibilidad. Así, éstos han incrementado la facilidad para adaptar el software a los cambios de especificación e incrementado la posible reutilización.

Claramente, los patrones han proporcionado los mismos beneficios que otorga la Programación Orientada a Objetos, pero mejorando la calidad del diseño, y por lo tanto, el software en sí mismo.La noción de patrones de diseño se ha incrementado gracias a la aparición de la Pandilla de los Cuatro, GOF157, quienes realizaron una recopilación de 23 patrones, marcando un hito en el desarrollo de los patrones de diseño.

Existen distintos tipos de patrones; por ejemplo, los patrones GRASP, desarrollados por Craig Larman, los cuales son patrones generales de software para asignar responsabilidades158.Si se recurre a la definición propuesta por el GOF: “los patrones de diseño son descripciones de objetos y clases comunicándose, que son adaptadas para resolver un problema de diseño general, en un contexto particular”, en virtud de ello se puede indicar que los patrones están dentro de la micro y macro estructura de las aplicaciones.

Cabe destacar que si se analiza la definición de patrón, éstos pueden ser aplicados en otros contextos.

4. TIPOS DE PATRONES

156 Artículo de OOPSLA'87, “Using Pattern Languages for Object-Oriented Programs”, 1987.157 Pandilla de los Cuatro, GOF, Gang of Four; integrada por Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides, “Design Patters: Elements of Reusable Object-Oriented Software”, 1995.158 Craig Larman, “UML y Patrones: Introducción al análisis y diseño orientado a objetos”, Editorial: Prentice Hall, 1999.

62

Existen diversos tipos de Patrones, aplicados a distintas áreas del Análisis y el Diseño de Software; en éste punto se tratarán en forma independiente, haciendo hincapié en los propuestos por el GOF; se encuentran otros patrones que fueron necesarios para la construcción del Caso de Estudio, en particular algunos patrones de comportamiento, tales como MVC (Model View Controller). Cabe destacar, que no se desconoce la existencia de los Core J2EE Patterns de Sun, en particular para aplicaciones distribuidas, los cuales pueden ser materia para otra investigación o trabajo futuro.

4.1.PATRONES DE ANÁLISIS

Los principales exponentes en esta área son Peter Coad159 y Martin Fowler160, quienes, bajo la premisa de un proverbio latino, “El ejemplo educa”, realizaron una compilación para enseñar la Programación Orientada a Objetos.

El objetivo es desarrollar estrategias, es decir, la planificación para llegar a una meta. Éstas se utilizan para construir el modelo de objeto, que corresponde principalmente a las fases de análisis y diseño.

Las estrategias utilizadas, están divididas en distintas áreas de acción:

Actividades y Componentes Mayores. Identificación de los Objetivos y las Características del Sistema. Selección de los Objetos. Asignación de Responsabilidades. Aspecto dinámico con escenarios. Descubrir nuevas estrategias y nuevos patrones.

Un patrón, según Coad, es un agrupamiento de clases y objetos, con responsabilidades estereotipadas asociadas, y ejemplos típicos de interacción.

La colección de lo patrones de Coad está encabezada por el patrón fundamental, del cual se derivan los demás patrones, y que se clasifican en:

Patrones de Transacción. Patrones de Agregación. Patrones de Planificación. Patrones de Interacción.

La forma mediante la cual se documentan los patrones es:

Número. Nombre.

159 Peter Coad , D North y M. Mayfield, “Objects Models Strategies, Patterns, and Aplications”, Yourdon Press, Prentice Hall, 1995160 Marin Fowler, Consultor ACM, [email protected] , “Analysis Patterns, Reusable Object Models''; Addison Wesley, 1997

63

Tipo de patrón. Diagrama de clases que conforman el patrón, en la notación apropiada

(Nombre en singular, Mayúscula cada nombre de clase). Comentarios acerca del diagrama.4.2.PATRONES DE DISEÑO (GOF, 1995)

Los patrones propuestos por el GOF, están clasificados de la siguiente manera, donde en primer lugar se explica la estrategia utilizada para definirlos, los patrones de creación, los patrones estructurales, y en último lugar los patrones de comportamiento.

Se puede indicar que la estrategia utilizada para definir y describir los patrones de diseño, es mediante la utilización de una regla que indica lo siguiente:

El nombre del patrón. El problema a resolver. La solución provista. Las consecuencias, sean éstas beneficios o problemas de su utilización.

Otros autores, proporcionan mayor detalle a la descripción del patrón, de los que se puede destacar:

Intención. Conocido como.Motivo. Aplicaciones.Estructura del patrón. Participantes.Colaboraciones. Consecuencias.Implementación. Código de ejemplos.Usos conocidos. Patrones relacionados.

El GOF identificó 23 patrones161, los cuales los clasificaron en tres grandes grupos, que se detallan en la siguiente figura162:

161 Los códigos estructurales de cada uno de ellos se encuentran disponibles en variados sitios de Internet, los cuales están diseñados para distintas plataformas como también para distintos lenguajes de programación.162 Vince Houston, Investigador Programación Orientada a Objetos, Java y C++ , http://home.earthlink.net/~huston2/dp/patterns.html

64

Figura 15: Representación de los Patrones de Diseño, según Vince Houston.

4.2.1. PATRONES DE CREACIÓN (CREATIONAL PATTERNS)

Los patrones que se identifican fueron los siguientes.

4.2.1.1. FÁBRICA ABSTRACTA (ABSTRACT FACTORY)

Provee un interfaz para crear familias de objetos dependientes o relacionados, sin necesidad de especificar sus clases concretas (p.e.: widgets163 en distintas plataformas)

163 Nombre otorgado a los variados comandos que mediante las formas extraen información de los usuarios la cual puede o no ser confidencial.

65

Figura 16: Modelo de Clases en UML de Abstract Factory.

Entre las aplicaciones, en las cuales se puede encontrar este patrón, destacan aquellas en que en muchas ocasiones existen diferentes recursos para realizar lo mismo, e incluso se presume que existirán nuevos recursos y queremos desarrollar sistemas compatibles con todos ellos. Si se desea que el software funcione sobre distintos recursos se debe abstraerse de qué librerías se utilizan.

Como toda clase requiere de colaboraciones, ya que toda relación entre el exterior del sistema y las clases de la factoría se realiza únicamente a través de los métodos de la clase abstracta. Se puede utilizar métodos virtuales en la clase abstracta para acceder a los métodos de las clases a instanciar.

Entre las consecuencias de la aplicación de éste patrón destacan:

Aisla las clases concretas. Facilita el intercambio de familias en tiempo de ejecución gracias al

polimorfismo. Es difícil dar “cabida” a nuevo tipos de productos, debido a los métodos

“CrearProductoAbstracto” y “CrearProductoConcreto”. El ocultamiento de las clases de implementación. Esto permite ofrecer

clases sin mostrar su implementación, pudiéndose reservar la posibilidad de cambiar la implementación en el futuro.

Alta facilidad de sustitución de conjuntos de clases por otras equivalentes. Consistencia entre productos (ya que todos cumplen la misma interfaz), al

desarrollarse las aplicaciones con un mismo conjunto homogéneo de clases, dichas aplicaciones son más consistentes entre ellas.

Los usos conocidos son los escritorios KDE/GNOME, las librerías MOTIF/Windows/OpenView, las librerías OpenGL/DirectX y GTK.

66

4.2.1.2. CONSTRUCTOR (BUILDER)

El creador es Ashish Jaiman, hacia el año 1992164, y su patrón está incorporado en el libro del GOF.

Es un patrón para la creación paso a paso de un objeto complejo, de modo que el mismo proceso de construcción pueda generar diversas representaciones, la rutina en el patrón de construcción hace un control más refinado sobre el proceso de construcción (por ejemplo: conversores de formatos de texto). Generalmente, todos los constructores heredan desde una clase abstracta que declara, las funciones a utilizar, para permitir crear al producto en partes.

La motivación es similar al patrón fábrica abstracta, pero en éste, el cliente utiliza los métodos abstractos de la clase fábrica (factory) para crear su propio objeto; en el constructor, el cliente ordena a la clase del constructor el cómo crear el objeto y después se solicita el resultado. Es una diferencia sutil, pero significativa.

Este patrón es aplicable cuando el algoritmo para crear un objeto complejo, debe ser independiente de los elementos que generan el objeto, y de cómo están ensamblados; el proceso de la construcción debe permitir diversas representaciones para que los objetos sean construidos.

Una aplicación con una clase superior Builder, es en la creación de clases menores, es decir: cuando sea necesario crear y agregar instancias de clases; cuando sea necesario contener múltiples instancias de clases; cuando la clase superior dispone de los datos necesarios para la clase a instanciar.

Figura 17: Estructura en UML del Patrón Builder.

164 Ashish trabaja como desarrollador de software de Lexign Inc, además diseña sistemas distribuidos, él es certificado MCSD (Microsoft Certified Software Developer) y de SCJP (Sun Certified Java Programmer). Códigos del patrón desarrollado se pueden encontrar en http://www.c-sharpcorner.com/Code/2002/Feb/CreationalPatternBuilderAJ.asp

67

Figura 18: Diagrama de Colaboración del Patrón Builder.

En la figura de a continuación se presenta un ejemplo de este patrón.

Figura 19: Ejemplo en UML del Patrón Builder.

Las consecuencias de la aplicación de éste patrón, son:

Reduce el acoplamiento. Permite variar la representación interna de estructuras compleja,

respetando la interfaz común de la clase Builder. Se independiza el código de construcción de la representación. Las clases

concretas que tratan las representaciones internas no forman parte de la interfaz del Builder.

Cada ConcreteBuilder tiene el código específico para crear y modificar una estructura interna concreta.

Distintos Director con distintas utilidades (visores, parsers, etc) pueden utilizar el mismo ConcreteBuilder.

Permite un mayor control en el proceso de creación del objeto. El Director controla la creación paso a paso, solo cuando el Builder ha terminado de construir el objeto, lo recupera el Director.

68

Los usos conocidos en la comunidad de desarrollo son:

Tratamiento de diferentes formatos de archivos. Creación de objetos complejos independientes de los elementos que lo

componen.4.2.1.3. MÉTODO FÁBRICA (FACTORY METHOD)

Define una interfaz para crear un objeto, pero deja que las subclases decidan qué clase instanciar. Este patrón delega la instanciación de una clase a sus subclases (como un constructor virtual).

Su diagrama en UML es el siguiente:

Figura 20: Modelo de Clases en UML del Patrón Factory Method.

Los participantes de éste patrón son:

Product (Page): Define la interfaz del objeto que el método de la fábrica crea.

ConcreteProduct (SkillsPage, EducationPage, ExperiencePage): Implementa la interfaz de Product.

Creator (Document): Declara el método fábrica (Method factory), el cual retorna un objeto de tipo Product. Creador; puede definir por defecto la implementación del método fábrica, que retorna por defecto un objeto ConcreteProduct. Además, puede llamar al método fábrica para crear un objeto Product.

ConcreteCreator (Report, Resume): Sobrescribe o elimina al método fábrica para devolver una instancia de ConcreteProduct.

El código estructural presenta al patrón, el cual proporciona una gran flexibilidad para crear diversos objetos. La clase abstracta puede proporcionar un objeto por defecto, pero cada subclase puede instanciar y extender una versión del objeto.

4.2.1.4. PROTOTIPO (PROTOTYPE)

Éste patrón especifica las clases de objetos y crea nuevos objetos copiando a un prototipo.

69

Su diagrama de clases en UML es el siguiente:

Figura 21: Ejemplo en UML del Patrón Prototipo.

En donde sus clases y/u objetos participantes son:

Prototype (ColorPrototype): Declara una interfaz para reproducirse. ConcretePrototype (Color): Implementa una operación para reproducirse. Client (ColorManager): Genera un nuevo objeto para solicitar un prototipo

para reproducirse.

El código estructural presenta al patrón, en el cual se crean los nuevos objetos por copias de objetos preexistentes (prototipos) de la misma clase.

4.2.1.5. SINGLETON

Asegura que una clase sólo tendrá una instancia, y provee un punto global de acceso a la misma, es decir, ofrecer una instancia de una clase y un punto de acceso a la misma.

El motivo de éste que proporciona un modelo que garantiza que sólo hay una instancia y que se puede acceder a ella por todos. Para ello, en lugar de tener una variable global, la instancia se almacena en un atributo estático de la clase y se accede a ella por el método Instance.

Es utilizado en las aplicaciones en las cuales debe existir un solo objeto de una clase y poder ser accesible desde cualquier punto, como una memoria compartida por varios Threads, un Spool, etc. Además, debe ser extensible por herencia

El diagrama de clases en UML es el siguiente:

70

Figura 22: Ejemplo en UML del Patrón Singleton.

Sus clases y/u objetos participantes son:

Singleton (LoadBalancer): Define una instancia de operación que permite un único acceso a sus clientes. La instancia es una operación de la clase. Además, la clase es responsable de crear y de mantener su única instancia.

Las consecuencias de la aplicación de este patrón son:

Solo existe una instancia de la clase Singleton. Las clases que requieran acceder a la instancia de Singleton lo consiguen

mediante el método de recuperación de la instancia Singleton: getInstance. Evidentemente, el método getInstance debe ser estático (para acceder sin

una instancia concreta) o método de clase, en lenguajes que no dispongan de esta facilidad se puede usar una función global.

Evitar variables globales, ya que el uso de estas variables rompe la modularidad.

Este patrón, se puede combinar con otros muchos, no obstante es muy frecuente utilizarlo junto a patrones tales como, Abstract Factory, Builder y Prototype, es decir, para obtener una instancia única que se utilizará para construir objetos. También se le ha relacionado con el patrón Cache Management, utilizado para implementar caché de objetos, solo que el patrón Singleton tendría un caché de un solo objeto.

4.2.2. PATRONES ESTRUCTURALES (STRUCTURAL PATTERNS)

El GOF identificó a los siguientes patrones dentro de ésta categoría.

4.2.2.1. ADAPTER O WRAPPER

Se utiliza para convertir la interfaz de una clase en otra interfaz, que es la esperada por el objeto cliente, es decir, adapta interfaces incompatibles.


71

Figura 23: Ejemplo en UML del Patrón Wrapper.


Target (ChemicalCompound): Define la interfaz específica dentro del dominio que utiliza un Cliente.

Adapter (Compound): Adapta la interfaz Adapter para la interfaz de Target. Adaptee (ChemicalDatabank): Define una interfaz existente que necesita

adaptarse. Client (AdapterApp): Colabora con los objetos que se crean con la interfaz

del Target.

El código estructural presenta al patrón, el cual “mapea” la interfaz de una clase, sobre otras, de modo que puedan trabajar juntos. Las clases incompatibles pueden provenir de diferentes bibliotecas o frameworks.

4.2.2.2. PUENTE (BRIDGE)

Se utiliza para desacoplar la definición abstracta de un objeto de su implementación. Con el objetivo que ambos puedan evolucionar independientemente, es decir, desacopla una abstracción desde la implementación, tal que ambos pueden desarrollarse independientemente.

El diagrama de clases en UML, es el siguiente:

72

Figura 24: Ejemplo en UML del Patrón Bridge.


Abstraction (Business Object): Define la interfaz de abstracción. Además, se mantiene como referencia a un objeto del tipo Implementor.

Refined Abstraction (CustomersBusinessObject): Extiende la interfaz definida por la Abstracción.

Implementor (DataObject): Define la interfaz para implementar las clases. Esta interfaz no tiene que corresponder exactamente a la interfaz de la abstracción; de hecho, las dos interfaces pueden ser diferentes. Por lo general, la implementación de la interfaz proporciona solamente operaciones primitivas, y la abstracción define las operaciones de alto nivel.

ConcreteImplementor (CustomersDataObject), implementa la interfaz de Implementor y define su implementación concreta.

El código estructural presenta al patrón, el cual separa la interfaz de su implementación. La implementación puede modificarse y los clientes no se percatan del cambio.

4.2.2.3. COMPOSICIÓN (COMPOSITE)

Se utiliza para construir objetos de complejidad mayor mediante otros más sencillos de forma recursiva, formando una estructura similar a un árbol. El patrón permite tratar a los objetos clientes de forma uniforme para la composición de objetos individuales.

El motivo de la aplicación de este patrón, se debe a que generalmente en las aplicaciones gráficas frecuentemente se requieren agrupar objetos en contenedores y utilizarlos de forma semejante aún siendo elementos individuales distintos. Así, permite a las clases cliente utilizar de igual forma los objetos compuestos que los individuales.

73


Figura 25: Estructura en UML del Patrón Composite.


Component (DrawingElement): Declara la interfaz para los objetos en composición. Es conveniente la implementación y el comportamiento de las interfaces comunes de todas las clases. Este patrón, permite la declaración de una interfaz para acceder y manejar los componentes hijos. Incluso, en forma opcional, se definen las interfaces para acceder a componentes padres de la estructura recursiva y a su implementación.

Leaf (PrimitiveElement): Representa a objetos hojas en la composición. Cabe destacar que una hoja no es un hijo. Además, define el comportamiento primitivo de objetos en la composición.

Composite (CompositeElement): Define el comportamiento de los componentes que tienen hijos. Además, permite almacenar los componentes hijos. Implementa las operaciones relacionadas con los hijos en la interfaz del componente.

Client (CompositeApp): Permite manipular objetos en la composición, a través del componente interfaz.

Una de las principales aplicaciones, es cuando sea necesario utilizar de igual forma objetos sencillos que agrupaciones de éstos. Las consecuencias de la aplicación de éste patrón son:

Se crea una jerarquía de objetos básicos y de composiciones de estos. Simplifica el cliente al tratar todos de igual forma. Facilita agregar nuevas clases insertándolas en un contenedor compatible. Generaliza el diseño.

74

El código estructural presenta al patrón, el cual permite la creación de una estructura arborescente, en la cual los nodos individuales están enlazados uniformemente.

4.2.2.4. DECORADOR (DECORATOR)

Este patrón agrega responsabilidades a un objeto dinámicamente. Además, provee una alternativa flexible para subclasificar y así extender su funcionalidad.


Figura 26: Ejemplo en UML del Patrón Decorator.


Component (LibraryItem): Define las interfaces de los objetos que tienen responsabilidades adicionadas dinámicamente.

ConcreteComponent (Book, Video): Define un objeto al cual las responsabilidades adicionales puedan ser integradas.

Decorator (Decorator): Mantiene una referencia al objeto Componente y define una interfaz que está compuesta por la interfaz de Componente.

ConcreteDecorator (Borrowable): Adiciona responsabilidades a los componentes.

El código estructural presenta al patrón, el cual agrega dinámicamente funcionalidad extra a los objetos existentes.

75

4.2.2.5. FACHADA (FAÇADE)

Este patrón provee una interfaz unificada para un conjunto de interfaces en un subsistema. Además, provee una interfaz de alto nivel, que permite que un subsistema sea fácil de utilizarlo, con lo cual simplifica el acceso a un conjunto de clases o interfaces. Con ello permite acceder a elementos del sistema y realizar operaciones más complejas, de forma transparente.

El motivo de utilizar este patrón se debe principalmente a:

Reducir la dependencia entre clases. Facade ofrece un punto de acceso al resto de clases. Si éstas cambian o se sustituyen por otras, sólo hay que actualizar la clase

Facade sin que el cambio afecte a las aplicaciones cliente. Facade no oculta las clases, sino que ofrece una forma más sencilla de

acceder a ellas. En los casos en que se requiere se puede acceder directamente a ellas.


Figura 27: Ejemplo en UML del Patrón Façade.


Facade (MortgageApplication): Esta clase es la encargada de saber qué clases son responsables ante un requerimiento. Además, delega las peticiones del cliente a objetos apropiados del subsistema.

Subsystem classes (Bank, Credit, Loan): Implementan la funcionalidad del subsistema. Corresponden a cada uno de los trabajos asignados al objeto Façade. Además, las clases del subsistema no tienen el conocimiento del objeto Façade, y no mantienen referencia a éste objeto.

76

La aplicación de éste patrón, permite:

Ofrecer un acceso sencillo a subsistemas complejos. Descomponer un sistema en capas, para así ofrecer una interfaz de acceso

entre las mismas. Cuando se requiere suministrar al cliente una interfaz simplificada. En el caso que existan muchas dependencias entre el cliente y las clases

del subsistema. Para dividir los subsistemas en capas (subsistemas).

Las consecuencias de la aplicación de éste patrón son:

Oculta a los clientes parte de la complejidad de los subsistemas. Disminuye el acoplamiento entre subsistemas y cliente. Disminuye el acomplamiento (las interfaces de por sí reducen el

acoplamiento). Facilidad de uso: forma estándar de usar un subsistema. Ocultación de componentes del subsistema. Que el cliente pueda utilizar toda la funcionalidad del sistema.

El código estructural presenta al patrón, el cual tiene una interfaz simplificada y uniforme, de los grandes subsistemas.

4.2.2.6. PESO MOSCA165 (FLYWEIGHT)

Este patrón se utiliza para compartir y apoyar una gran cantidad de objetos eficientemente. Además de compartir objetos de grano fino con el objetivo de ahorrar memoria, ya que muchos objetos iguales serían referencias a un solo objeto.

El motivo del diseño de objetos de grano fino mínimo proporciona una óptima flexibilidad, pero puede ser tremendamente inaceptable en términos de rendimiento y utilización de memoria.


165 Relacionado con los términos del boxeo.

77

Figura 28: Ejemplo en UML del Patrón Flyweight.


Flyweight (Character): Declara una interfaz, por medio de la cual el objeto flyweights puede recibir y actuar en un estado extrínsico.

ConcreteFlyweight (CharacterA, CharacterB, ,,,,, CharacterZ): Implementa la interfaz de Flyweight y agrega el almacén para un estado intrínsico en caso de haberlo. Un objeto ConcreteFlyweight, debe ser compartido. Cualquier estado que almacene debe ser intrínsico, es decir, debe ser independiente del contexto del objeto de ConcreteFlyweight.

UnsharedConcreteFlyweight (not used): No todas las subclases de Flyweight necesariamente debe ser compartidas. La interfaz de Flyweight habilita la posibilidad de compartir, pero no lo obliga hacerlo. Esto es común para objetos UnsharedConcreteFlyweight, debido a que tiene objetos ConcreteFlyweight como hijos en algunos niveles de la estructura del objeto flyweight (como lo tienen las filas y columnas de clases).

FlyweightFactory (CharacterFactory): Crea y maneja objetos flyweight. Con ello se asegura que flyweight está apropiadamente compartido. Cuando un cliente requiere de flyweight, el objeto FlyweightFactory, suple una instancia existente, o crea una en caso de no existir.

Client (FlyweightApp): Mantiene una referencia a flyweight(s). Computan o alamacenan los estados extrínsicos de los flyweight(s).

Algunas aplicaciones en las cuales este patrón han sido utilizado son los widgets Motif, los cuales se han diseñado como gadgets de peso ligero (flyweight). Ellos son “inteligentes” sin conocer a sus propietarios. Los gadgets existen con independencia de sus creadores y cada gadget sólo es responsable del estado y comportamiento del contexto independiente.

78

El código estructural muestra al patrón, el cuál es compartido por un número relativamente pequeño de objetos, muchas veces de diversos clientes.

4.2.2.7. APODERADO O REPRESENTANTE (PROXY)

Proporciona un sustituto o un lugar de especial posición para controlar el acceso a un objeto.


Figura 29: Ejemplo en UML del Patrón Proxy.


Proxy (MathProxy): Mantiene una referencia que permite que el acceso al proxy sea real. Proxy puede referir hacia Subject si las interfaces de RealSubject y Subject son las mismas. Esta clase, provee una interfaz idéntica a Subject que un proxy puede sustituir por el verdadero subject. Los controles tienen acceso al subject verdadero, y pueden ser responsables de crearlo o de eliminarlo. Además, se pueden mencionar otras responsabilidades que dependen del tipo de Proxy, de las cuales se pueden enumerar:

o remote proxies, es responsable de codificar una petición y enviar la solicitud codificada al subject real, en un espacio de direcciones diferentes.

o virtual proxies, puede depositar la información adicional sobre el subject real, de modo que puedan posponer su acceso.

o protection proxies, comprueba que el solicitante tenga los permisos requeridos.

Subject (IMath): Define una interfaz común de RealSubject y Proxy, de modo que un Proxy puede ser utilizado en cualquier RealSubject si es necesario.

79

RealSubject (Math): Define un objeto real que representa a un Proxy.

El código estructural muestra al patrón, el cual proporciona un objeto representativo (proxy), con los controles que tienen acceso a otro objeto similar.

4.2.3. PATRONES DE COMPORTAMIENTO (BEHAVIORAL PATTERNS)

En este grupo se pueden encontrar a los siguientes patrones.

4.2.3.1. CADENA DE RESPONSABILIDADES (CHAIN OF RESPONSIBILITY)

Evita el “juntar” el remitente (sender) de una petición a su receptor (receiver), proporcionando a más de un objeto una ocasión de manejar la petición. Cambia el objeto receptor y traspasa la petición a lo largo de una cadena de objetos hasta que uno de ellos toma el control, es decir, delega responsabilidades a una clase especializada.

También, es conocido como Expert o Experto.

Este patrón, es una forma de distribuir la ejecución repartiendo las responsabilidades. Es la forma básica de distribuir las responsabilidades al realizar un Diseño Orientado a Objetos, por lo tanto lo utilizamos de forma intuitiva en este tipo de diseños.

Se puede utilizar junto al patrón Composite, de forma que los hijos tienen un enlace al padre que les permita acceder a información sin conocer la clase que las contiene, así como propagar la ejecución.


Figura 30: Ejemplo en UML de Cambio de Responsabilidades.


80

Handler (Approver): Define una interfaz para manejar las peticiones. Además, en forma opcional, implementa un link sucesor.

ConcreteHandler (Director, VicePresident, President): Maneja las peticiones y define la responsabilidad de acceder al sucesor. Si el ConcreteHandler puede manejar la petición, no hay problema; en caso contrario, se transmite la petición a su sucesor.

Client (ChainApp): Inicializa la petición del objeto ConcreteHandler en la cadena.

Las consecuencias inmediatas de utilizar este patrón son:

Ofrecer las principales ventajas de la Programación Orientada a Objetos. Mejorar la encapsulación. Facilitar el mantenimiento. Ofrecer reusabilidad.

El código estructural presenta al patrón Chain of Responsability, en el cuál se publican varios objetos linkeados (la cadena), con la opción de responder a una petición o anular al objeto posteriormente.

4.2.3.2. COMANDO (COMMAND)

Encapsula una petición como un objeto, esto facilita la parametrización de los requerimientos (inicialización de los parámetros por el constructor), el encolado de múltiples peticiones (estructura de datos de objetos comando) y su reordenación, y permite implementar el hacer/deshacer (do/undo) mediante métodos. Por otro lado se facilita la creación de macros agrupando los comandos más frecuentes.

El concepto de "comando" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: intérpretes de comandos del sistema operativo, lenguajes de macros de paquetes ofimáticos, gestores de bases de datos, protocolos de servidores de Internet, etc. Es por ello, que este patrón presenta una forma sencilla y versátil de implementar un sistema basado en comandos facilitando su utilidad y diversidad.


81

Figura 31: Ejemplo en UML del Patrón Command.


Command (Command): Declara una interfaz para la ejecución y la operación.

Concrete Command (Calculador Command): Declara un puente entre el objeto receptor y una acción implementada Execute, para invocar a la(s) correspondiente(s) operación(es) del Receptor.

Client (CommandApp): Crea un objeto Concrete Command y configura un receptor.

Invoker (User): Solicita el comando para realizar una petición. Receiver (Calculator): Conoce cómo realizar las operaciones asociadas

para realizar una petición.

Las principales aplicaciones que proporciona este patrón, son:

Facilitar la parametrización de las acciones a realizar. Independizar el momento de petición del de ejecución. Implementar CallBacks, especificando que comandos que se desea que se

ejecuten en ciertas situaciones de otros comandos. Es decir, un parámetro de un comando puede ser otro comando a ejecutar.

Soportar el "deshacer". Desarrollar sistemas utilizando comandos de alto nivel que se construyen

con operaciones más sencillas (primitivas).

Las principales consecuencias del patrón, son:

Se independiza la parte de la aplicación que invoca los comandos de la implementación de los mismos.

Al tratarse los comandos como objetos, se puede realizar herencia de los mismos, composiciones de comandos (mediante el patrón Composite).

Se facilita la ampliación del conjunto de comandos.

82

Dentro de los usos conocidos, se pueden mencionar, las clases Button y MenuItem de Java, las cuales declaran los métodos getActionCommand y setActionCommand para dar nombres a las acciones realizadas por los objetos, facilitándose una correspondencia entre ambos.

El código estructural muestra al patrón, el cuál almacena las peticiones como objetos cliente, permitiendo que se ejecute o se registre una petición.

4.2.3.3. INTÉRPRETE (INTERPRETER)

Dado un lenguaje, es conveniente definir una representación para su gramática, junto con un intérprete que utilice la representación, para interpretar las sentencias del lenguaje.


Figura 32: Ejemplo en UML del Patrón Intérprete.


Abstract Expression (Expression): Declara una interfaz para ejecutar una operación.

Terminal Expression (ThousandExpression, HundredExpression, TenExpression, OneExpression): Implementa una operación asociada al Intérprete, con símbolos terminales en la gramática. Se requiere una instancia para cada símbolo terminal en la sentencia.

NonterminalExpression (not used): Una clase, es requerida para cada regla R:= R1R2...Rn en la gramática. La instancia mantiene variables del tipo Abstract Expression para cada uno de los símbolos R1 a Rn. Se implementa una operación del Intérprete para cada uno de los símbolos no terminales en la gramática. Por lo general, el Intérprete se invoca en forma recursiva, con las variables que se representan desde R1 a Rn.

83

Context (Context): Mantiene información que es global del Intérprete. Client (InterpreterApp): Construye (o es dado) una representación

arborescente, con una sintaxis abstracta de una sentencia en particular, en un lenguaje que define la gramática. El árbol abstracto de sintaxis se llama desde una instancia de la clase Non Terminal Expression y Terminal Expression. Además, el cliente invoca una operación del Intérprete.

El código estructural muestra al patrón, el cual utiliza una gramática definida; proporciona al intérprete qué declaraciones de procesos fueron analizados.

4.2.3.4. ITERADOR (ITERATOR)

Este patrón provee una forma de tener acceso a un elemento de algún objeto agregado, sin exponer su representación subyacente.


Figura 33: Ejemplo en UML del Patrón Iterator.

Sus clases y/u objetos participantes son:

Iterator (AbstractIterator): Define una interfaz para acceder y modificar algún elemento.

ConcreteIterator (Iterator): Implementa una interfaz del Iterator. Mantiene la posición actual del elemento agregado en forma transversal.

Aggregate (Abstract Collection): Define una interfaz para la creación del objeto Iterator.

Concrete Aggregate (Collection): Implementa la creación de una interfaz de Interator, para retornar una instancia apropiada de Concrete Iterator.

84

El código estructural presenta al patrón, el cuál provee una manera de iterar sobre una colección de artículos o ítems, sin detallar la estructura subyacente de la colección.

4.2.3.5. MEDIADOR (MEDIATOR)

Define un objeto que encapsula la forma de cómo interactúa un conjunto de objetos. Este patrón incentiva un débil acoplamiento para mantener a los objetos referidos explícitamente, dejando a sus interacciones que cambien independientemente.


Figura 34: Ejemplo en UML del Patrón Mediator.


Mediator (IChatroom): Define una interfaz para mantener la comunicación con el objeto Colleague.

ConcreteMediator (Chatroom): Implementa un comportamiento cooperativo para coordinar al objeto Colleague. Conoce y mantiene a sus pares.

Colleague classes (Participant): Cada clase Colleague conoce a su objeto Mediador. Cada colega se comunica con su mediador, siempre que se hubiera comunicado de otra manera con otro colega.

El código estructural muestra al patrón Mediator, el cual facilita la comunicación libremente entre los diversos objetos y tipos de objetos. El Mediator es un HUB o concentrador, a través del cual debe pasar toda la interacción.

4.2.3.6. RECUERDO (MEMENTO)

El encapsulamiento captura y externaliza el estado interno de un objeto, con el fin de restaurar el objeto a este estado más adelante.


85

Figura 35: Ejemplo en UML del Patrón Memento.

En donde sus clases y/u objetos participantes son: Memento (Recuerdo): Almacena el estado interno del objeto Creador

(Originator). El memento puede almacenar mucho o una pequeña parte del estado interno del Originator, como la discreción necesaria del Originator. Este patrón se protege ante el acceso de otros objetos que no sean del Originator. Este patrón debe tener necesariamente dos interfaces. Caretaker ve una interfaz de Memento. Éste puede pasar solo el Memento a otros objetos. Al contrario, Originator ve una interfaz amplia, que lo deja tener acceso a todos los datos necesarios para volver a su estado anterior. Idealmente, solo el Originator reproduce el Memento, debería permitir el acceso del estado interno de Memento.

Originator (Sales Prospect): Crea un Memento, que contiene una imagen (containing) del estado interno actual. Además, utiliza el Memento para restaurar su estado interno.

Caretaker (Caretaker): Es responsable de almacenar el Memento. Además, examina el contenido de un memento.

El código estructural muestra al patrón Memento, el cual temporalmente guarda y almacena el estado interno de otros objetos.

4.2.3.7. OBSERVADOR (OBSERVER)

Define dependencias del tipo uno a muchos entre objetos, con el objetivo que cuando un objeto cambia de estado, se notifica y se actualizan todas sus dependencias automáticamente.


86

Figura 36: Ejemplo en UML del Patrón Observador.


Subject (Stock): Conoce sus observadores. Cualquier número de objetos Observer puede ser visto como un subject. Además, provee una interfaz para agregar y detallar un objeto Observer.

Concrete Subject (IBM): Almacena el estado de interés para Concrete Observer. Además, envía una notificación a los observadores cuando cambia su estado.

Observer (Investor): Define una interfaz de actualización para aquellos objetos que se deban notificar a cualquier cambio del Subject.

Concrete Observer (Investor): Mantiene una referencia al objeto Concrete Subject. Además, almacena el estado que debe permanecer constante en el subject. Este objeto implementa la interfaz de actualización de Observer para mantener un estado consistente en subject.

El código del patrón, se confirma que se encarga de notificar a los objetos ante cualquier cambio de su estado.

4.2.3.8. ESTADO (STATE)

Permite que un objeto altere su comportamiento cuando su estado interno cambia. El objeto da la impresión de cambiar su clase.


87

Figura 37: Ejemplo en UML del Patrón Estado.

Las clases y/u objetos participantes son:

Context (Account): Define la interfaz de interés para el cliente. Además, mantiene una instancia de la subclase Concrete State subclase, la cual define su estado actual.

State (State): Define una interfaz que encapsula el comportamiento asociado con un estado en particular de Context.

Concrete State (RedState, SilverState, GoldState): Cada comportamiento de una subclase implementada, está asociada con el estado de Context.

El código muestra al patrón, el cual permite que un objeto se comporte de acuerdo a su estado interno. La diferencia de su comportamiento está delegado a los objetos que representan su estado.

4.2.3.9. ESTRATEGIA (STRATEGY)

Define una familia de algoritmos, los cuales son encapsulados y se hacen permutables. Además, permite que cada algoritmo se modifique, independientemente de los clientes que lo utilicen.


Figura 38: Ejemplo en UML del Patrón Estrategia.

Las clases y/u objetos participantes son:

88

Strategy (SortStrategy): Define una interfaz común para dar soporte a todos los algoritmos. Context, utiliza esta interfaz para llamar al algoritmo definido por una Concrete Strategy.

Concrete Strategy (QuickSort, ShellSort, MergeSort): Implementa el algoritmo utilizando la interfaz Strategy.

Context (SortedList): Se configura con el objeto Concrete Strategy. Además, mantiene una referencia al objeto Strategy. Así, puede definir una interfaz que permite el acceso de Strategy a sus datos.

El código estructural muestra al patrón Strategy, el cual encapsula la funcionalidad en un objeto. Esto permite que los clientes cambien dinámicamente sus estrategias algorítmicas.

4.2.3.10. MÉTODO PLANTILLA (TEMPLATE METHOD)

Define el esqueleto de un algoritmo en una operación, derivando algunos pasos a sus subclases. El patrón permite que las subclases redefinan algunos pasos del algoritmo, sin cambiar su estructura.


Figura 39: Ejemplo en UML del Template Method.


Abstract Class (Data Object): Define las operaciones abstractas primitivas que las subclases concretas definen para la ejecución de un algoritmo. Además, se implementa el método template, el cual define el esqueleto de un algoritmo. El método template llama a las operaciones primitivas que se definen en Abstract Class o en otros objetos.

ConcreteClass (CustomerDataObject): Implementa las operaciones primitivas de los pasos específicos del algoritmo en cada subclase.

El código estructural muestra al patrón Método Template, el cual provee un esqueleto para llamar a una secuencia de métodos. Se pueden definir uno o más pasos de las subclases que ponen estos pasos en ejecución, sin cambiar la secuencia del llamado.

89

4.2.3.11. VISITADOR (VISITOR)

Representa una operación que se realizará en un elemento de la estructura del objeto. El visitador permite definir una nueva operación, sin cambiar las clases de los elementos en los cuales funciona.


Figura 40: Ejemplo en UML del Patrón Visitador.


Visitor (Visitor): Declara una operación Visit, para cada clase de Concrete Element en la estructura del objeto. El nombre y la firma de la operación identifican a la clase que envía la petición de la visita (Visit) al visitante (Visitor). Con ello, permite al visitante determinar la clase concreta del elemento que es visitado. Entonces, el visitador puede acceder directamente a los elementos por medio de su propia interfaz.

90

ConcreteVisitor (Income Visitor, Vacation Visitor): Implementa cada operación declarada por el Visitador. Con ello provee el contenido del algoritmo y almacena el estado local. Este estado a menudo acumula el resultado, en una estructura transversal.

Element (Element): Define una operación de Aceptación que toma al visitador como un argumento.

ConcreteElement (Employee): Implementa una operación de aceptación, que toma al visitador como un argumento.

ObjectStructure (Employees): Puede enumerar estos elementos, además, puede proveer una interfaz de alto nivel mediante la cual el visitador recorre estos elementos. Incluso puede ser cualquier patrón Composite o una colección (lista o un conjunto de algoritmos).

El código muestra al patrón Visit, en el cual un objeto atraviesa una estructura de objetos y realiza la misma operación en cada nodo de esta estructura. Diversos objetos del visitante definen diversas operaciones.

4.2.3.12. MODELO VISTA CONTROLADOR (MVC166)

Este patrón plantea la separación del problema en tres capas: la capa model, que representa la realidad; la capa controller, que conoce los métodos y atributos del modelo, recibe y realiza lo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo, y es utilizada por la capa anterior para interaccionar con el usuario.

Presentación al Cliente

Vista

Controlador

Modelo

Dato Dato Dato

Figura 41: Estructura del Patrón MVC.

166 Generalmente conocido por su nombre en Inglés, Model View Controler.

91

Cabe destacar que éste define la organización, independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación: "si estoy aquí y me piden esto entonces hacer tal cosa, si sale bien mostrar esto y sino lo otro aquello ").

Un ejemplo se puede describir como sigue: El navegador genera una solicitud que es atendida por el Controller (un Servlet especializado). Él mismo se encarga de analizar la solicitud, seguir la configuración que se le ha programado en su XML, y llamar al Action correspondiente, pasándole los parámetros enviados. El Action instanciará y/o utilizará los objetos de negocio para concretar la tarea. Según el resultado que retorne el Action, el Controller derivará la generación de la interfaz a una o más páginas (php, asp, jsp), las cuales podrán consultar los objetos del Model a fines de realizar su tarea.

Modelo

Modelo

ControladorVista

Los datos del Modelo se

util izan en la Vista

La Vista sólo puede

solicitar datos al modelo

Llamadas al Controlador

Notifica cambios de

estado provenientes

Figura 42: Diagrama de Componentes del Patrón MVC.

La implementación del patrón MVC requiere los siguientes componentes167:

Modelo: Es el componente que contiene una o más clases e interfaces que son las responsables de mantener los datos del modelo. El estado del modelo se mantiene dentro de los atributos y la implementación de los métodos. Para poder mantener una comunicación y percatarse de los cambios que se generan dentro de la Vista, el Modelo debe mantener las referencias a las posibles Vistas a utilizar registradas. Así, cuando exista un cambio, todas las vistas tendrán la información de éste o estos cambios.

Vista: Las clases e interfaces de la vista proporcionan y muestran los datos que se obtienen dentro del componente del modelo. Puede consistir también con componentes visuales, aunque no siempre se requerirá de una GUI. Si se desea que la vista trabaje correctamente, deberá hacérsele notar al Modelo que la Vista existe, o bien registrarla para que trabaje correctamente, y se pueden percibir los cambios dentro del Modelo, ya que ésta es la responsable de representar todos los cambios al usuario y también de cómo se deben hacer. La Vista mantiene una comunicación con

167 Sitio dedicado al estudio de éste patrón y su complemento con PHP, http://www.phpmvc.net/

92

el Modelo para poder recuperar los datos, pero no puede modificarlos. Otra tarea importante que también puede representar una Vista es para interpretar al Controlador, pero todas las notificaciones de cambio deben hacerse a través de una clase Controlador, por lo que deberán existir referencias a uno o más Controladores.

Controlador: Este es el componente que dirige los cambios dentro del Modelo, es el que informa al Modelo en qué momento debe cambiar de estado, y mantiene la responsabilidad de ejecutar los cambios; del mismo modo, mantiene la comunicación con todos los componentes Vista, para poder saber si es que las notificaciones de cambio vienen de parte de estos componentes.

Las fortalezas del patrón son:

La interfaz lógica por lo general cambia más rápidamente que la lógica de negocios, especialmente en aplicaciones basadas en la Web. Por ejemplo, una nueva página de interfaz de usuario puede ser agregada, o la disposición de las páginas existentes puede ser entrelazada. Una de las ventajas de las Aplicaciones Web basadas en un “Cliente Delgado” (thin-client), es el hecho que se pueda modificar o cambiar la interfaz de usuario sin modificar la distribución de la aplicación. Si el código de presentación y la lógica del negocio se combinan en un solo objeto, cada vez que se realice una modificación en la interfaz de usuario, se debe modificar el objeto que contiene la lógica del negocio, con la consiguiente alta probabilidad de errores en cascada.

En algunos casos, las aplicaciones despliegan la misma información en distintos formatos o diversas maneras. Por ejemplo, en el MATCMS, la forma de representar la información en un PDA es diferente a cómo se despliega en un Computador Personal. En algunas interfaces de usuarios de clientes ricos (rich-client), múltiples visiones del mismo dato son presentadas al mismo tiempo. Si un usuario modifica un dato en una de las vistas, la actualización en las otras debe reflejarse automáticamente.

El diseñar páginas en HTML visualmente atrayentes, requiere de una gran habilidad, en el supuesto que se modifique la lógica de negocios. Es por ello que es deseable disponer por separado el desarrollo de la lógica de negocios de la de usuarios.

Generalmente las interfaces de usuarios consisten de dos componentes: presentación y actualización. La presentación recupera los datos de una fuente de datos (data source) y ajusta los datos en un formato de despliegue. Cuando un usuario realiza una acción basada en los datos, el componente de actualización retorna el control a la lógica de negocio para actualizar los datos.

93

Éste patrón, en la práctica es una manera de simplificar la distribución de la funcionalidad de la aplicación168. Proporcionando una manera eficaz de poder extender la flexibilidad y adaptabilidad de alguna aplicación a diversas circunstancias o situaciones. Se puede aplicar de diversas formas, estáticas y dinámicas. Facilitando la estructura, haciendo que las nuevas clases, correspondientes a Vistas y Controlador, sólo se incorporen dentro de la aplicación principal (esta es la forma estática), o que los objetos de estas nuevas clases se permitan modificar dentro de la aplicación, pero en tiempo de ejecución o forma dinámica.

4.2.3.13. CONTROLADOR FRONTAL (FRONT CONTROLER)

Si debido a una decisión arquitectural se ha optado por utilizar el MVC, con el objetivo de separar la interfaz lógica desde la lógica de negocios de una aplicación Web dinámica. Ya se revisado el patrón controlador de páginas, pero el controlador de clases ha complicado la lógica del negocio, debido a que son parte de una herencia de muchos niveles, o en su defecto, la aplicación determina la navegación entre las páginas dinámicas, las cuales están basadas en reglas configurables.

Dado el contexto anterior, se pueden plantear ¿Cómo estructurar el controlador para los usos complejos de las aplicaciones Web, de modo que se pueda alcanzar la reutilización y la flexibilidad, evitando la duplicación del código?

Existen aspectos del patrón MVC, que se pueden aplicar a este patrón, entre los cuales se destacan:

Si la lógica común se repliega en diversas vistas en el sistema, se requiere centralizar esta lógica para reducir la duplicación del código. Eliminar el código duplicado es fundamental para mejorar la capacidad de mantención del sistema.

La recuperación de datos es fundamental en una localización. Un ejemplo es un conjunto de vistas que utilizan los mismos datos desde la base de datos. Es mejor implementar la recuperación de estos datos, que cada vista realice la recuperación; con ello se evita el duplicar el código de acceso a las bases de datos.

Según lo propuesto por MVC, el código de prueba de interfaz de usuario tiende a ser una pérdida de tiempo y tedioso. La separación de los roles realza una testabilidad total.

Las siguientes fortalezas se desprenden del utilizar éste patrón versus el patrón Page Controller:

Una implementación común del patrón Page Controller implica la creación de una clase base para el comportamiento compartido entre las páginas individuales. Sin embargo, en un cierto plazo estas clases bases pueden

168 Ingeniero Francisco Javier Oropeza López, Universidad de las Américas Puebla, México.

94

crecer en el código que no es común a todas las páginas. Esta clase requiere de una refactorización periódica, para asegurar que sólo contenga el comportamiento común. Por ejemplo, no se quiere que una página examine una petición y decida (a petición los parámetros basados) transferir el control a otra, porque este tipo de decisión es más específico a una función en particular, más que al campo común entre todas las páginas.

Para evitar el agregar una lógica condicional excesiva en la clase base, se puede crear una jerarquía de herencia más profunda, con el objetivo de eliminar la lógica condicional. Por ejemplo, en una aplicación que tiene tres áreas funcionales, puede ser útil disponer de sólo una clase base, que tiene una funcionalidad común para la aplicación. Se puede contar con otra clase para cada área funcional, en donde toda la aplicación hereda desde la clase base. Este tipo de estructura, por lo general, es innata, pero conduce a menudo a un diseño y a una implementación muy delicada, y por ende, a un código extenso y complejo, el cual es de difícil mantención; a ello se le puede denominar incluso un antipatrón.

La solución del page controller, describe un objeto por cada página lógica. Esta solución se analiza cuando se requiere controlar o coordinar el proceso durante páginas múltiples. Por ejemplo, si se supone que se tiene una navegación compleja y configurable, que se almacena en XML, en su uso de la Web. Cuando llega una petición, la aplicación basada en su estado actual debe ir al servidor, y luego “mirar” dónde dirigirse posteriormente.

Como el page controller se implementa con un objeto por página lógica, es difícil aplicar constantemente una acción particular a través de todas las páginas en un uso de la Web. La seguridad, por ejemplo, se implementa lo mejor posible de una manera coordinada. Manejar la seguridad por cada objeto de la vista o del page controller es complicado, porque puede generar inconsistencias y puede conducir a los denominados “hoyos de seguridad”. Una solución adicional a este problema puede ser ayudado por el patrón “Filter Controller”.

La asociación del URL a un objeto controlador en particular puede ser una obligación a las aplicaciones Web. Por ejemplo, el sitio tiene una interfaz mediante un wizard para recopilar la información. Este wizard consiste en un número de páginas obligatorias y un número de páginas opcionales, basadas en las entradas del usuario. Cuando son implementadas con el Page Controller, las páginas opcionales tendrían que ser implementadas con una lógica condicional en la clase base para seleccionar a la página siguiente.

Este patrón soluciona la descentralización presente en el patrón Page Controller, canalizando todas las peticiones mediante un solo controlador. El Controller por lo

95

general es implementado en dos partes: el manejador y una jerarquía de comandos.

Figura 43: Estructura del Patrón Front Controller.

El manejador tiene dos responsabilidades fundamentales.

Recuperación de Parámetros: El manejador recibe o consigue del HTTP la petición del Web server, y recupera los parámetros relevantes de la petición.

Selección de Comandos: El manejador utiliza los parámetros de la petición al elegir el comando correcto, y entonces transfiere el control para procesarlos.

El siguiente diagrama de actividad aclara las responsabilidades recién mencionadas.

Figura 44: Responsabilidades del Patrón Front Controller.

Los comandos son parte del controlador. Ellos representan las acciones específicas según lo descrito en el patrón Command. La representación organiza el cómo los objetos individuales permiten que el controlador trabaje con cualquier

96

comando de manera genérica, en comparación con la invocación de los métodos específicos de una clase base del Command.

Con la utilización de este patrón se obtienen las siguientes ventajas:

Control centralizado. El patrón, coordina todas las peticiones que se hacen a la aplicación Web. La solución describe el usar un solo controlador, en vez del modelo distribuido, usado como un controlador por tipo de página. Este controlador está en la ubicación perfecta para hacer cumplir políticas de la aplicación (Wide-aplication), tales como seguridad, workflow, y seguimientos de la aplicación.

Hebra de Seguridad169. Ya que cada petición implica el crear de un nuevo objeto command, éste por sí mismo no necesita tener su hebra de seguridad. Esto significa que se evita que la seguridad en las aplicaciones, tengan una hebra en las clases del command. Esto no significa que se pueda evitar las ediciones de las hebras en conjunto, porque el código en el que actúan los command sobre el código modelo, todavía son importantes170.

Flexibilidad de configuración. En el servidor Web, sólo necesita ser configurado un Front Controller; el manejador cumple el rol de enviar. Ésto simplifica la configuración del servidor Web. Usar command dinámicos permite agregar nuevos command sin modificar el servidor.

Si bien éste patrón tiene ventajas, en forma análoga ha de tener responsabilidades, dentro de las cuales figuran:

Consideraciones del funcionamiento. El Front Controller sólo es un controlador que maneja todas las solicitudes de una aplicación Web. De los dos elementos, el manejador debe examinar los problemas de rendimiento, porque él determina el tipo de comando que realiza la petición. Si el manejador debe realizar una pregunta a la base de datos o una pregunta de un documento en XML para tomar una decisión, consecuentemente el rendimiento podría ser bajo.

Complejidad creciente. El Front Controller es más complicado que Page Controller. Implica a menudo el substituir del controlador incorporado en el servidor Web, por un Front Controller desarrollado a la medida. Implementar esta solución aumenta los costos de mantención y el tiempo de diseño de los desarrolladores que lo implementan.

Está relacionado con los Patrones Page Controller, e Intercepting Filter.

4.2.3.14. INVERSION OF CONTROL (IOC)

169 Su nombre en inglés, es Thread-safety.170 Martin Fowler, http://www.martinfowler.com

97

Cuando dos contenedores se comunican, se debe a que utilizan un Inversion of Control; este patrón es una característica común de los frameworks, en el manejo de los contenedores especiales.

El diagrama en UML que puede representar el funcionamiento del patrón es el que se presenta en la siguiente figura.

Figura 45: Diagrama en UML de IOC.

¿Cuál es el aspecto de control que se está invirtiendo? Cuando funciona en primer lugar la inversión del control, el principal está en la interfaz del utilizador. Cada interfaz de usuario es controlada por un programa de la aplicación. Se dispondría de una secuencia de comandos del tipo “incorpore el nombre”, “incorpore la dirección”; el programa antes mencionado sería el conductor de los avisos, solicitudes, y las respuestas a éstos. Mediante interfaces gráficas de usuarios (o basadas en pantallazos o wizard) y frameworks, se dispondría de la conexión para manejar los eventos generados de la aplicación.

Para este nuevo tipo de contenedores para la inversión, se encuentran las operaciones de búsqueda, implementadas mediante un plug-in.

Tanto el nombre de éste patrón, como su funcionamiento, lamentablemente son demasiado genéricos, es que conlleva a la definición más formal del patrón Dependency Injection, el cual es definido a continuación.

4.2.3.15. PATRÓN DEPENDENCY INJECTION

Hoy en día el paradigma de la reutilización de componentes, junto con el complemento a componentes dispares, genera a corto y largo plazo una arquitectura cohesiva. Debido a las dependencias la tarea de generar, reutilizar, y adaptar componentes, es una tarea desalentadora debido a la complejidad de los sistemas171.

171 Martin Fowler, http://www.martinfowler.com

98

Es por ello que para disminuir la proliferación de éstas dependencias, se está utilizando este patrón, el cual permite que se agreguen objetos a una clase, en vez de dejar a la clase que cree los objetos.

La utilización de los patrones, y en especial de clases Factory, es fundamental para la implementación de éste patrón. Cuando un componente crea una instancia privada de otra clase, éste incorpora la lógica de inicialización dentro del componente. Esta lógica de inicialización es raramente reutilizable externamente del componente que crea, y por lo tanto se debe duplicar para cualquier otra clase que requiera una instancia de la clase a ser creada.

Por lo general, los desarrolladores automatizan tareas monótonas, pero realizan casi manualmente la construcción de objetos y la resolución de la dependencia172. La última, puede ser descrita como la resolución de dependencias de un tipo o de un objeto. En cambio, éste patrón, apunta a reducir la cantidad de líneas de dependencias (boilerplate wiring) y la estructura del código a ser escrito.

Un Dependency Injection en particular, reduce los tipos de dependencias, proporcionando una descripción genérica de clases Factory, que inicializa las instancias de clases. Esas instancias son configuradas por un contenedor, mediante una construcción lógica para ser reutilizada a cierto nivel.

Dependency Injection no sólo se basa en los patrones Factory, si no que tiene muchas correlaciones con otros patrones, tales como Builder, Assembly, y Visitor.

También el patrón puede ser desarrollado utilizando contenedores, los cuales son cajas que contienen una abstracción de una clase en su interior. Por lo general, el manejo del control del objeto lo asume cualquier contenedor que se esté utilizando para manejar esos objetos. Sin embargo, los contenedores pueden asumir el control de las instancias, la configuración, así como también en el uso de servicios específicos a los objetos.

El contenedor de Dependency Injection no sólo cumple con muchas metas, sino que también agrega una significativa cantidad de flexibilidad y funcionalidad a las aplicaciones.

Éste patrón puede reducir no sólo el acoplamiento entre los componentes, sino que también disminuye la creación de código, al igual que casi elimina la duplicación de éste. Spring.NET es un ejemplo de un framework que proporciona un contenedor para utilizar con Dependency Inyection, pero no es el único.

En la siguiente figura se puede apreciar tanto la dependencia simple, versus la dependencia utilizando éste patrón.

172 Generalmente conocido por su nombre en inglés, dependency resolution.

99

Figura 46: Dependencia Simple versus Dependency Injection.

4.2.3.16. PATRÓN PAGE CONTROLLER173

Si por decisión arquitectónica se utiliza el patrón Modelo-Vista-Controlador (MVC) para separar la interfaz de los componentes de la aplicación Web de la lógica del negocio, la aplicación se construye mediante páginas dinámicas, pero la navegación entre las páginas es por sobre todo estática.

El problema que se genera al tomar esta decisión, es ¿Cómo generar la mejor estructura del controlador para aplicaciones Web, con el objetivo de alcanzar reutilización y alta flexibilidad, pero evitando la duplicación del código?

Para dar solución a la problemática recién planteada, se deben revisar las fortalezas a considerar, de las cuales se destacan:

Considerando que el patrón MVC, se concentra en la separación entre el modelo y las vistas, y por ende presenta mayor atención al controlador. En muchos escenarios del rich-client, la separación entre el controlador y las vistas son menos críticas y se omite a menudo. En una aplicación del tipo thin-cliente, sin embargo, la visión y el controlador intrínsecamente se separan porque la presentación ocurre en el browser del cliente, mientras que el controlador es parte del uso del lado del servidor. El controlador, por lo tanto, autoriza un revisión más cercana.

En aplicaciones Web, las acciones de múltiples usuarios pueden conducir a diversas lógicas controladoras, pero con la misma página de presentación. Por ejemplo, en una aplicación que se utilice el E-mail, el enviar un mensaje y suprimir un mensaje del inbox, es probable que retorne al inbox al usuario (pero con la página actualizada). Aunque la misma página se actualiza (render) después de cualquier actividad, el uso que debe realizar en una acción, está basada en la página anterior y el botón que el usuario presiona.

173 Martin Fowler 2003, http://www.martinfowler.com

100

El código de la mayoría de las páginas dinámicas consiste de pasos muy similares: verificar la autentificación del usuario, extrayendo los parámetros de la página de la secuencia de la pregunta o los campos del formulario174, recopilando la información de la sesión, recuperando datos de una fuente de datos, presentando175 la porción dinámica de la página. Esto puede conducir a una cantidad significativa de duplicación del código.

Las páginas del servidor de Scripting (tales como ASP.NET, PHP, JSP) pueden ser fáciles de crear, pero pueden tener un número de desventajas mientras que la aplicación crece. Las páginas de Scripted proporcionan una pobre separación entre el controlador y la vista, lo cual reduce las oportunidades para la reutilización. Por ejemplo, si múltiples acciones conducen a la misma página, es difícil reutilizar el código de exhibición a través de múltiples controladores, porque es mediante la intervención del código del controlador. Las páginas del servidor de Scripting que se entremezclaron para eliminar errores en la lógica del negocio y en la lógica de la presentación, son también más difíciles de reutilizar. Finalmente, el desarrollo de un servidor de páginas de Scripting requiere de un alto manejo de la lógica del negocio y el hacer que las páginas sean visualmente atractivas y eficientes en HTML; estas competencias es difícil que las tengan una misma persona; debido a estas consideraciones, tiene sentido de reducir al mínimo el código del Scripting del servidor y desarrollar la lógica del negocio en clases.

Como ya se dijo en el patrón MVC, el código de prueba de interfaz de usuario, tiende a ser un mal gasto de recursos, y por ende tedioso. Si se puede separar el código de la interfaz de usuario de la lógica real del negocio, la prueba de la, lógica del negocio llega a ser más simple y más repetible. Esto no es solo válido para la presentación, sino también para el controlador de la aplicación.

Una apariencia y una navegación común, tiende a mejorar el reconocimiento y usabilidad de la aplicación Web. Sin embargo, una apariencia común conlleva a altos niveles de duplicación de código, especialmente si el código está con scripting en las páginas del servidor. Por lo tanto, se requiere un mecanismo para mejorar la reutilización de la lógica de la presentación a través de las páginas.

Para dar solución a las problemáticas recién presentadas, se sugiere la utilización del patrón Page Controller, para aceptar la entrada de la petición de página, e invocar las acciones solicitadas en el modelo, y determinar la vista correcta de la página que resulta. El separar la lógica que se envía de cualquier vista del código relacionado. Cuando sea apropiado, crear una clase base común para que todos los controladores de página eviten la duplicación del código y aumenten la consistencia y la testabilidad. La siguiente figura muestra cómo el patrón se relaciona con el modelo y la visión.

174 Por lo general es conocido por su nombre en inglés, form.175 El presentador es conocido por render.

101

Figura 47: Patrón Page Controller.

El Page Controller, recibe una petición de página, extrae los datos relevantes, invoca cualesquiera actualización al modelo, y transfiere la petición a la vista. La vista alternadamente depende del modelo para la recuperación de los datos que se exhibirán. El definir un controlador separado de la página, aísla al modelo de una petición específica de la Web, por ejemplo, la administración de la sesión, o el uso de secuencias de preguntas o los campos ocultos del formulario para pasar parámetros a la página. De ésta básica forma, se crea un controlador para cada acoplamiento en la aplicación Web. Esto mantiene los controladores simples, porque se tiene que referir solamente a una acción a la vez.

El crear un controlador independiente para cada Web page (o la acción), puede conducir a la duplicación del código. Por lo tanto, se debe crear una clase de BaseController para incorporar funciones comunes, tales como, validar parámetros.

Figura 48: Eliminando Duplicación de Código.

Cada controlador individual de página puede heredar esta funcionalidad común desde el BaseController. Además de la herencia de una clase base común, se puede también definir un sistema de clases amigas, para que los controladores pueden invocarlas para realizar sus funciones comunes.

102

Este acercamiento funciona óptimamente cuando las páginas son similares y se pueden dejar las funciones comunes en una sola clase base. Cuantas más variaciones se tienen, más son los niveles de páginas que se deben considerar, al igual que un árbol. Todas las páginas analizan parámetros, pero solamente las páginas que exhiben listas recuperan los datos de las bases de datos, mientras que las páginas que requieren de actualización de los datos de entrada; el modelo más bien recupera los datos. Ahora se podrían incorporar dos nuevas clases bases, ListController y DataEntryController; ambas heredan de BaseController. Las páginas de la lista podrían entonces heredar de ListController, y las páginas de la entrada de datos podrían heredar de DataEntryController. Aunque este acercamiento puede trabajar bien en este ejemplo sencillo, el árbol de la herencia puede tener mayor profundidad y complejidad si se está ocupando en una aplicación con variadas reglas de negocios.

Claramente, al tener la estructura anterior, el incorporar la lógica condicional en las clases bases para adaptar algunas de las variantes, es un antipatrón, ya que se violan los principios de encapsulación y hace en las clases bases un embotellamiento notorio para cualquier cambio al sistema. Por lo tanto, se debe considerar el usar las clases como soporte o de patrón Front Controler, si las aplicaciones llegan a ser más complejas.

La utilización de éste patrón en aplicaciones Web, es una necesidad tan común que la mayoría de los frameworks de desarrollo Web, proporcionan una implementación por defecto del patrón. La mayoría de los frameworks incorporan el patrón en la formulario de una página del servidor (por ejemplo, ASP, JSP, y PHP). Las páginas del servidor combinan las funciones de las vistas y del controlador, y no proporcionan realmente la separación deseada entre el código de la presentación y el código del controlador. Desafortunadamente, algunos de los frameworks mezclan los códigos relacionados con las vistas y los relacionados con el controlador, y por ende, haciendo difícil separar correctamente la lógica del controlador. Consecuentemente, la utilización de éste patrón ha generado una mala impresión a muchos desarrolladores. Ahora, muchos desarrolladores asocian a éste patrón como un mal diseño y a Front Controller como un buen diseño. Esta opinión, de hecho, resultó de una opción (culpable) específica de la puesta en marcha; la utilización de ambos patrones son opciones arquitectónicas perfectamente viables.

Por lo tanto, es preferible separar la lógica del controlador en clases separadas, las cuales se puedan llamar de la página del servidor. El framework de página con ASP.NET proporciona un mecanismo excelente para alcanzar esta separación, llamado code-behind classes.

Éste patrón no es un patrón heterodoxo, es decir, tiene variantes, en la mayoría de los casos, el patrón es dependiente de peticiones basadas en http específicas de una aplicación Web. Consecuentemente, el controllercode de la página, contiene referencias a los encabezados del HTTP, secuencias de preguntas, campos de un formulario, peticiones del formulario de múltiples partes, y así sucesivamente.

103

Esto hace muy difícil probar el código del controlador fuera del framework de la aplicación Web. La única opción es probar el controlador simulando peticiones desde HTTP y analizando los resultados. Este tipo de prueba es despilfarrador de tiempo y propenso a errores. Por lo tanto, para mejorar la testabilidad, se puede separar el código dependiente e independiente de la Web, como se explica en la siguiente figura.

Figura 49: Separación del código de la Aplicación Web.

En este ejemplo, AspNetController encapsula todas las dependencias en el framework de la aplicación (ASP.NET). Por ejemplo, puede extraer todos los parámetros entrantes de la petición de la Web y pasarlos a BaseController de una manera que sea independiente de la interfaz (por ejemplo, en una colección). Este acercamiento mejora no sólo la testabilidad, sino que permite reutilizar el código del controlador con otras interfaces del manejador, por ejemplo un interfaz del rich-client o una lenguaje basado en scripting.

El downside de este acercamiento son los gastos indirectos adicionales. Ahora se dispone de una clase adicional, y cada petición tiene que pasar con una “traducción” antes de que pueda ser mantenida. Por lo tanto, se debe guardar el ambiente específico del controlador tanto como sea posible, y considerar los tradeoffs entre las dependencias reducidas y un desarrollo y una ejecución más eficientes.

La utilización de éste patrón, tiene ventajas y responsabilidades, dentro de las cuales se destacan:

Simplicidad. Debido a que cada página Web dinámica es manejada por un controlador específico, los controladores tienen que ocuparse solamente de un alcance limitado y pueden seguir siendo simples. Además, cada controlador de página trata solamente con un solo tipo de página; éste se adapta satisfactoriamente para los aplicaciones Web con simple navegación.

104

Características incorporadas al framework. En su forma más básica, el controlador se construye en la mayoría de las plataformas Web. Por ejemplo, si el usuario hace click en una página Web, eso conduce a una página dinámica generada por una escritura de ASP.NET, el Web server analiza el URL, asociado al acoplamiento y ejecuta la página asociada de ASP.NET. En efecto, la página de ASP.NET es el controlador para la acción tomada por el usuario. El framework de la página de ASP.NET, además, proporciona código detrás de las clases para ejecutar el código del controlador. Este código proporciona una mejor separación entre el controlador y la vista, y permite que se pueda crear una clase base del controlador, que incorpora una funcionalidad común a través de todos los controladores.

Incremento de la Reutilización. Crear una clase base del controlador reduce la duplicación de código, y permite reutilizar el código común a través de controladores de la página. Se puede reutilizar el código poniendo la lógica en ejecución que se repite en la clase base. Esta lógica entonces es heredada automáticamente por todos los objetos del controlador de páginas. Si la implementación de la lógica varía entre las páginas, se puede utilizar un método como plantilla (template), y poner la estructura básica de la ejecución en otra clase base; la implementación de los subpasos específicos puede variar, dependiendo del tipo de página y el tipo de aplicación.

Extensibilidad. Se puede ampliar un page controller, utilizando clases amigas. Si la lógica dentro del controlador llega a ser demasiado compleja, se puede delegar parte de la lógica a las clases del ayudante. Las clases amigas también proporcionan otro mecanismo para la reutilización, además de la herencia.

Separación de las responsabilidades del Desarrollador. Con page controller, las clases amigas permiten separar las responsabilidades entre los miembros del equipo del desarrollo. El desarrollador del controlador debe familiarizarse con el modelo del dominio y la lógica del negocio, implementados en la aplicación. El diseñador de la vista, por otra parte, puede centrarse en el estilo de la presentación de los resultados.

Debido a su simplicidad, el page controller, en la práctica se implementa en la mayoría de las aplicaciones Web. Sin embargo, se deben considerar las siguientes limitaciones:

105

Un controlador por página. Lo clave del contenedor Page Controller, es que se crea un controlador para cada página Web. Esto trabaja satisfactoriamente para las aplicaciones de páginas estaticas y de un mapa simple de navegación. Aplicaciones más complejas requieren de una configuración de páginas dinámicas y de mapas de navegación entre ellos. Separar esta lógica, mediante controladores por tipo de página, conllevaría a una aplicación de difícil mantención, incluso si parte de la lógica se almacena en un controlador base. Además, las características incorporadas en el framework de la Web pueden reducir la flexibilidad que se tiene en el nombramiento de URLs y de las trayectorias de los recursos (aunque se puede compensar con mecanismos tales como los filtros de ISAPI176). En este escenario, es apropiado utilizar el Front Controller, el cual intercepta todas las peticiones de la Web y transmite la petición el tratante apropiado, basado en reglas configurables.

Árboles profundos de herencia. La herencia se parece a la utilizada en la programación Orientada a Objetos. Usar herencia solamente para reutilizar funcionalidad común puede conducir a una herencia inflexible en cuanto a la jerarquía.

Dependencia en el Framework de la Web. En la forma básica, el controlador de página todavía depende del ambiente de la aplicación Web y no se puede probar independientemente. Se debe utilizar un mecanismo para separar la parte dependiente de la Web, pero hacer que se requiera de un nivel de indirección adicional.

Éste patrón está relacionado con los patrones, MVC, Front Controller e Intercepting Filter.

4.2.3.17. PATRÓN INTERCEPTING FILTER

Como ya se ha podido apreciar, cada uno de los patrones se identifica en cierto contexto, en éste caso el mecanismo de direccionamiento de una petición a ser representado recibe diversos tipos de solicitudes, que requieren de distintos tipos de procesos. Algunas peticiones se remiten simplemente a un componente apropiado del controlador, mientras que otras peticiones deben ser modificadas, con revisión, o sin comprensión anterior de lo que será procesado.

El problema a resolver es el proceso previo y el post-procesamiento de una petición y de una respuesta a una petición de un cliente de la Web.

Cuando una petición ingresa desde una aplicación Web, debe aprobar varias pruebas de ingreso en la etapa de proceso principal. Por ejemplo:

El cliente fue autentificado.176 Para la instalación de filtros ISAPI, en servidores Microsoft, se puede visitar la siguiente referencia Web, http://www.adrformacion.com , en donde se especializan en la configuración de los Servidores Webs.

106

El cliente está en una sesión válida. ¿Es la dirección IP del cliente de una red confiable? ¿La trayectoria de la petición viola alguna restricción? ¿Qué codificación utiliza el cliente para enviar y recibir los datos? El browser del cliente dispone de su soporte apropiado.

Algunos de estos cuestionamientos son pruebas, dando por resultado alguna o ninguna respuesta, la cual se determinará a medida que el proceso continúa. Otras revisiones manipulan la secuencia de datos entrantes, de una forma conveniente para procesar los correspondientes datos de salida.

La solución clásica y básica consiste de una serie de revisiones condicionales, en donde, ante cualquier fracaso de la revisión, se aborta la petición. Las declaraciones jerárquicas if/else son una estrategia estándar, pero esta solución conduce aun código frágil y una especie de copiar y pegar en cuanto a programación, porque el flujo de filtrado y de acción se compila en la aplicación.

Para solucionar éste problema de una manera flexible y discreta, se dispone de un mecanismo sencillo para agregar y quitar los componentes de proceso, en los cuales cada componente termina una acción de filtrado específica.

Las fortalezas de aplicar éste patrón son:

Un proceso común, es decir, una especie de comprobación del esquema de dato-codificación o registro de la información sobre cada petición, y término de la petición.

Es deseable la centralización de la lógica. Los servicios deben ser fáciles de agregar o de quitar, sin afectar a los

componentes existentes, para poder utilizar una variedad de combinaciones, por ejemplo:

o Registro (Logging) y autentificación.o Para un cliente específico eliminar los errores y la transformación de

las salidas.o Compresión y un esquema de codificación para convertir las

entradas.

La solución reside en la creación de filtros “pluggable” o de fácil instalación, para procesar servicios comunes de una manera estándar, sin requerir cambios al código en el proceso de la solicitud. Los filtros interceptan peticiones entrantes y respuestas salientes, permitiendo el pre-proceso y el post-proceso. Se pueden agregar y quitar estos filtros, sin requerir cambios al código existente.

Se puede, en efecto, mejorar el proceso principal con una variedad de servicios comunes, tales como seguridad, registro, eliminación de bugs, y así sucesivamente. Estos filtros son los componentes que son independientes del código de la aplicación principal, y pueden ser agregados o ser quitados declarativamente. Por ejemplo, un archivo de configuración del despliegue se

107

puede modificar para instalar una cadena de filtros. El mismo archivo de configuración puede incluir una traza del URL específico a esta cadena de filtros. Cuando un cliente solicita un recurso que une este URL configurado, los filtros en la cadena se procesan cada uno en orden antes de que se invoque el recurso solicitado.

La estructura en UML de este patrón se puede visualizar en el siguiente diagrama.

Figura 50: Estructura de clases del Patrón Intercepting Filter.

Figura 51: Diagrama de Secuencias del Patrón Intercepting Filter.

En donde sus participantes y responsabilidades son:

108

FilerManager: Maneja el proceso de filtro. Genera el FilterChain con los filtros apropiados, en el orden correcto, e inicia el proceso.

FilterChain: Es una colección solicitada de filtros independientes. FilterOne, FilterTwo, FilterThree: Éstos son los filtros individuales que son

mapeados. El FilterChain coordina su proceso. Target: Es el recurso solicitado por el cliente.

Para poder utilizar éste patrón existen diversas estrategias, entre las que destacan:

Filtro por Encargo (Custom Filter Strategy)o Las estratégias son implementadas por el desarrollador. Tiene menor

potencial que un Filtro Estándar, porque no puede preveer el resolver una petición de los objetos y entregar la respuesta de una manera estándar y portable.

o La solicitud del objeto no puede ser modificada, y un mecanismo de clase de almacenamiento temporal (buffering), deben ser incorporados si los filtros controlan el flujo de salida. Cabe destacar que para implementar éste patrón, se debe tener un cabal conocimiento del patrón Decorador, para disponer de un seguimiento lógico del procesamiento.

o Para comprender ésta estrategia, se debe considerar que cada componente escribe su salida cuando se ejecuta.

o Además, una cadena de procesos se ejecuta en orden. Cada proceso, a excepción del anterior en la cadena, se considera un filtro. El componente final del proceso es donde se encapsula la base, procesando lo que se desea terminar con cada petición. Dado este diseño, se requiere modificar el código en la clase de CoreProcessor, así como en cualquier filtro, cuando se quiere modificar como manejo de peticiones.

109

Figura 52: Diagrama de Secuencias utilizando el Patrón Decorator.

o Cabe destacar que cuando se utiliza el patrón Decorator, cada filtro invoca al filtro siguiente directamente, pero usando un interfaz genérica. Alternativamente, esta estrategia se puede poner en ejecución utilizando un FilterManager y un FilterChain. En este caso, estos dos componentes coordinan y manejan el filtro que procesa, y los filtros individuales no se comunican directamente. Este diseño se aproxima al de un servlet, pese a ser una práctica rígida, pero no deja de ser por solicitud.

110

Figura 53: Diagrama de Secuencias sin utilizar el Patrón Decorator.

o Ésta estrategia no permite crear los filtros suficientemente flexibles o de gran alcance. Los filtros se agregan y se quitan a nivel de programación. Mientras que se podría crear un mecanismo propietario para manejar la adición y eliminación de filtros que estén almacenados, pero no se tendría ninguna manera de hacer un correcto seguimiento (wrapper) de la petición y de la respuesta. Además, sin un mecanismo sofisticado de buffering, esta estrategia no proporciona el postprocesamiento flexible.

Filtro Estándar (Standard Filter Strategy)o Se controlan los filtros explícitamente utilizando un descriptor del

despliegue, como se describe en la especificación de un servlet. La especificación del servlet incluye un mecanismo estándar para la construcción de las cadenas de filtros, como también para agregar y quitar los filtros de esas cadenas. Los filtros se construyen alrededor de interfaces, y son agregados o quitados en una manera declarativa, modificando el descriptor del despliegue para una aplicación Web.

o Como ejemplo, si se crea un filtro que preprocesa solicitudes codificadas de cualquier forma, tales solicitudes se pueden manejar semejantemente a una petición base. ¿Por qué pudo ser esto necesario? Los formularios en HTML que incluyen un uso del upload de diverso tipo, la codificación en la mayoría de los casos está en los

111

formularios. Así, los datos que acompañan el upload no están disponibles vía invocaciones simples del getParameter(). Así pues, se crean dos filtros que preprocesan las peticiones, traduciendo toda la codificación a un solo formato constante. El formato que se elige debe tener todos los datos de la forma disponibles como cualidades de la petición.

o Un filtro maneja la codificación de la forma estándar de los formularios, y el otro maneja el tipo de codificación menos común, que se utiliza para las formas que incluyen uploads de archivos. Los filtros traducen todos los datos del mismo formulario a las cualidades de la petición, así que el mecanismo de direccionamiento de petición base puede trabajar con cada petición de manera semejante, en vez que con diversos cifrados.

Figura 54: Diagrama de Secuencias para el Patrón (2 estrategias).

o El StandardEncodeFilter y el MultiPartEncodeFilter interceptan el control cuando un cliente hace una petición al controlador del servlet. El contenedor cumple el rol del encargado del filtro y del control de los vectores a estos filtros invocando sus métodos del doFilter. Después de terminar su proceso, cada filtro pasa su control a FilterChain que contiene, la que ordena ejecutar el filtro siguiente. Ambos filtros han recibido el control posteriormente abandonado; el componente siguiente ha recibir el control es el recurso real, en este caso es el controlador del servlet.

112

Filtro Base (Base Filter Strategy) o Es un filtro de bajo nivel que sirve como super clase común para

todos los filtros. Las características comunes se pueden encapsular en el filtro más bajo y así compartir entre todos los filtros. Por ejemplo, un filtro bajo es un buen lugar para incluir el comportamiento por defecto para los métodos de servicio repetido del contenedor en la estrategia declarada por el filtro.

Plantilla de Filtro (Template Filter Strategy)o Con un filtro del cual todos los otros hereden, permite que la clase

base proporcione la funcionalidad del patrón Método Plantilla. En este caso, el filtro bajo se utiliza para dictar los pasos generales que cada filtro debe terminar, mientras que deja los específicos de cómo determinar ese paso a cada subclase del filtro. Generalmente, éstos definirían los métodos básicos que incorporan una estructura limitada ante cada plantilla. Esta estrategia se puede combinar con cualquier otra estrategia de filtros.

o Dada esta definición de la clase para Template Filter, cada filtro se pone en ejecución como una subclase, que debe tener sólo el método doMainProcessing en ejecución. Estas subclases tienen la opción, de disponer los tres métodos en ejecución si se desean.

Figura 55: Diagrama de Secuencias de la Estrategia Plantilla.

o En la figura anterior, las subclases del filtro, tales como, DebuggingFilter, definen el proceso específico, eliminando al método abstracto doMainProcessing y, opcionalmente, doPreProcessing y doPostProcessing. Así, el filtro plantilla impone una estructura a

113

cada filtro que procesa, así como el abastecimiento de un lugar para el código de encapsulado, que es común a cada filtro.

Éste patrón tiene consecuencias directas, entre las que se destacan:

Centralizar el control con bajo acoplamiento del controladoro Los filtros proporcionan un lugar central para manejar el proceso

mediante múltiples peticiones, al igual que un controlador. o Los filtros son mejores para dar solución a las peticiones, al

momento de direccionar un recurso objetivo (solicitado), igual que un controlador.

o Además, un controlador liga a menudo la administración de servicios comunes sin mucha relación, tales como autentificación, registro, cifrado, y así sucesivamente, mientras que el filtrado permite a los tratantes mucho más, los que pueden ser combinados de varias maneras.

Mejorar Reutilizacióno Los filtros promueven la reutilización. Estos interceptores pluggable

transparentes se agregan o se quitan del código existente, y debido a su interfaz estándar, trabajan en cualquier combinación, y son reutilizables para distintas presentaciones.

Declarar una configuración flexibleo Los numerosos servicios se combinan en permutaciones que varían,

sin necesidad de recompilar el código base. La información compartida es ineficiente

o El compartir la información entre los filtros puede ser ineficaz, por la definición de cada filtro. Si grandes cantidades de información se deben compartir entre los filtros, esta aproximación puede ser costosa.

Como todo patrón, no está solo como se ha podido apreciar, se relaciona con distintos de patrones, entre los que figuran, Front Controler, Decorador, Método Plantilla, Interceptor y relación con el estilo arquitectural de Tubos y filtros.

4.2.3.18. PATRÓN BUSINNES DELEGATE

Si un cliente quiere acceder a un servicio Web177, por lo general se accede mediante un Bussiness Delegate, el cual tiene la función de control y protección para el servicio de negocio.

En aplicaciones distribuidas, la dirección de las operaciones de búsqueda y excepciones para los componentes del negocio puede ser compleja. Cuando las aplicaciones utilizan componentes del negocio directamente, el código de la aplicación debe cambiar para reflejar cambios en los componentes APIs del negocio.

177 Cabe hacer la observación de no confundir un servicio Web con un Web service.

114

Estos problemas pueden ser solucionados incorporando una clase intermedia, denominada Bussiness Delegate, que independiza componentes del negocio, de los que utiliza el código. El patrón Bussiness Delegate maneja la complejidad de componentes distribuidos de las operaciones de búsqueda y de excepción, y pueden adaptar la interfaz del componente del negocio a un interfaz más simple para la aplicación Web.

Un ejemplo de ello es la clase AdminRequestBD del Bussiness Delegate de la aplicación, ella controla las operaciones de búsqueda distribuidas, recupera y adapta excepciones; en el ejemplo de la figura se presenta en el centro a Order Processing Center (OPC).

El Bussiness Delegate, AdminRequestBD maneja operaciones de búsqueda en componentes distribuidos y controla las excepciones. El diagrama estructural de la figura siguiente muestra al servlet ApplRequestProcessor, utilizando AdminRequestBD para encontrar y utilizar componentes distribuidos del negocio.

Figura 56: AdminRequestBD establece y adapta otros componentes del negocio.

El procesador de petición (OPC178), también utiliza AdminRequestBD para acceder a los componentes del negocio.

La clase ApplRequestProcessor del servlet OPC recibe las solicitudes del servicio del cliente del admin en forma de mensajes XML, transmitidos utilizando HTTP. Uno de estas peticiones está para la estadística sobre las órdenes que tienen un estado dado.

178 Empresas que se han dedicado a ésta área son http://www.matrikonopc.com y http://opcsystems.com/

115

CAPÍTULO 3: CASO DE ESTUDIO

1. PROPUESTA TÉCNICA.

La presente propuesta técnica comprende una solución para el manejo del contenido académico en nuestra Casa de Estudios. La propuesta arquitectural de solución que se expondrá, está basada en las últimas técnicas y nuevas metodologías que se podrían aplicar a nivel informático en el interior de la Universidad de La Serena.

Las diferentes secciones que se compone esta propuesta, considera:

Resumen de la Situación Actual, sección en que se realiza una descripción del proceso, su propósito y el marco institucional en el cual está inserto.

Diagnóstico: Colaboraciones del Negocio, sección en donde se grafica cuáles son las entidades que participan en el proceso y de qué manera colaboran, como también qué criterios deberían entenderse como valor agregado a este proyecto.

Descripción de la Solución Propuesta, en términos de realizar los procesos haciendo una buena utilización de la tecnología, y cuáles son los aspectos claves de la solución.

Marco Metodológico, que establece la metodología, tecnología, técnicas y herramientas que serán utilizadas en el desarrollo del proyecto.

Plan de Trabajo, descripción de las diferentes etapas y actividades que deberán ser cubiertas durante el proyecto, integrando las actividades tradicionales en este tipo de proyecto, con las nuevas tecnologías.

Organización, donde se describen los roles que tendrán los integrantes del grupo de trabajo, la experiencia de éstos, y la aplicación de los patrones de Coplien para tales efectos.

Entregables, se describe las planificaciones y las guías de acción de las fases siguientes.

Garantía Técnica de Soporte y Capacitación, según los contratos que se puedan llegar a firmar al cabo de esta etapa, se propondrá un plan de capacitación para las distintas unidades básicas.

No cabe lugar a dudas que éste documento es eminentemente técnico, pero su objetivo es proporcionar un enfoque lo más realista posible al proyecto.

116

2. RESUMEN SITUACIÓN ACTUAL

En esta sección se resume tanto la información disponible de la Memoria de Titulación de los Ingenieros en Computación, Señores Carlos Gómez y Álvaro Olivares, complementada con los datos que se disponen de las distintas Unidades Básicas de nuestra Casa de Estudios. Se omite información referente a los LMS (Learning Management System), ya que éstos últimos constituyen un campo relacionado con el E-learning, y puede llegar a ser una nueva línea de investigación para futuros trabajos.

2.1.DIAGNÓSTICO INICIAL.

En primer lugar, se debe indicar la Misión de nuestra Casa de Estudios, “En virtud que la misión de una Universidad es su razón de ser y es el reflejo de la realidad actual, pero orientada hacia el futuro, la Universidad de La Serena debe ser una institución regional, con proyección al ámbito nacional e internacional, cuya misión es la gestión de conocimiento, que se manifieste a través de acciones de calidad y pertinencia, con una fuerte vocación de servicio público y de liderazgo intelectual y cultural.179”. Apoyándose de la definición anterior, al ser un reflejo de la realidad actual, no hay lugar a dudas que gracias a los últimos gobiernos se ha dado un impulso a la tecnología y a la incorporación del país a un mundo globalizado, es por ello que la utilización de las TICs180 es fundamental para dar cumplimiento a la misión de nuestra Casa de Estudios.

En segundo lugar, ya el Centro de Computación e Informática de la Universidad de La Serena, CICULS, ya ha realizado varios avances para situar a la gestión de la Universidad en los nuevos tiempos, cabe mencionar algunos de estos sistemas: las Actas de Calificaciones, la Toma de Asignaturas, Los módulos de Autoayuda disponibles en varios lugares de la Universidad, entre otros.

Es por ello que la siguiente alternativa es otro paso para que la Universidad sea un foco Intelectual, tanto para el país, como para la Región.

El año 2004, se produjo el cierre de la Central de Publicaciones de la Universidad, lugar al cual los alumnos asistían a adquirir módulos, guías de ejercicios, apuntes, encuadernaciones; los motivos del cierre fueron por motivos económicos, ya que casi la totalidad de cada una de las Unidades Básicas y otros Estamentos, disponen de sus propios medios de fotocopiado, y de los espacios para la postulación mediante proyectos, para generar textos de apoyo, sitios Web, plataformas docentes, publicaciones, entre otros.

179 Universidad de La Serena, http://www.userena.cl180 Acrónimo de Tecnologías de la Información y la Comunicación.

117

Casi la totalidad de las Carreras de Pregrado, como también los programas de postgrado de la Universidad, demandan la utilización de herramientas computacionales básicas, tales como, editores de textos, planillas electrónicas, software para lectura de archivos no modificables. Para ello los alumnos disponen de diversos laboratorios de computación, en el cual todos tienen acceso a la red de la Universidad y por ende acceso a Internet.

La Comision Nacional de Acreditación de Pregrado, CNAP, dentro de las deficiencias encontradas a varias carreras, hizo hincapié en el bajo e inefectivo uso de la Computación, y en particular de Internet, por parte de los Académicos, para dar soporte a la Educación; ese informe, en el cual me siento identificado debido a mi trabajo de Académico Jornada Parcial del Departamento de Matemáticas de Nuestra Casa de Estudios, fue un factor de motivación para realizar esta propuesta.

2.2.SISTEMAS DE APOYO ACTUALES.

Un gran paso que realizó el Departamento de Matemáticas, pero en particular el de los actuales Ingenieros en Computación titulados en esta Casa de Estudios, Carlos Gómez y Álvaro Olivares, fue la creación de una herramienta de Soporte para el proceso docente, a través de la Publicación Colectiva de un sitio Web académico para un Ambiente Universitario, el cual no ha estado exento de reclamos, tanto de los alumnos como de los académicos, debido a las modificaciones que se le realizaron para resguardar el contenido de las asignaturas. Además, de los constantes problemas de red. Hoy en día, el sistema tiene una baja utilización, debido a la desmotivación de los principales actores.

Actualmente, distintas unidades básicas han encomendado y realizado, el desarrollo de variadas plataformas docentes, las cuales cabe destacar que no ha sido la construcción de un sistema, sino la adaptación de herramientas GNU para tales propósitos; si se menciona las herramientas que se adaptaron, ya que se desconocen los costos en los cuales han incurrido las distintas unidades básicas, las cuales no se asesoraron con el CICULS ni con las unidades que disponen de las competencias computacionales en nuestra Casa de Estudio, puede traer consigo problemas, debido a los costos a los cuales han incurrido las Unidades Básicas.

A continuación se mencionan algunas unidades básicas, escuelas, o académicos que disponen de páginas y plataformas Webs, las cuales cabe mencionar no están debidamente autorizadas por nuestra Casa de Estudios, ya que requieren ser debidamente reglamentadas.

Unidades Dirección Web Observación

118

Básicas, Escuelas o Académicos

Matemática http://mat.uls.cl Dispone de Plataforma Docente, desarrollada según los requerimientos propuestos en la Memoria de Titulación de los señores Álvaro Olivares y Carlos Gómez, orientada hacia la Asignatura.

Ing. Mecánica. http://mecanicauls.cl Dispone de Plataforma Docente, orientada a la asignatura, solución no propietaria, con alta seguridad del contenido, nula uniformidad de interfaz, en el contenido del Departamento.

Ing. Industrial http://www.ici.userena.cl Portal orientado hacia los alumnos, sin plataforma docente, con tratamiento colectivo de la información, con foros y encuestas. No es solución propietaria. Semejante a un grupo yahoo.

Esc. Ing. en Alimentos

http://www.ingenieriaenalimentos.cl

Portal sin plataforma docente, a cargo de los alumnos, sin solución propietaria.

Auditoría http://auditoriauls.galeon.com Portal netamente informativo, sin plataforma docente, casi completamente estático.

Prof.: Eric Jeltsch F.

http://dns.uls.cl/~ej Página Personal, en la cual se puede encontrar información de índole académica, de las asignaturas que dicta el académico; la página es completamente estática, pero funcional.

Ing. de Minas. http://www.uvirtual.cl Programa especial, de Diplomado de Voladura de Rocas, dirigido por el Dr. Alfonso Carvajal C.

Esc. de Ing. Computación

No disponible actualmente Orientada y dirigida por los alumnos, sin una plataforma docente efectiva.

Prof.: Gustavo Gatica G.

Correo Comunitario Dispone de un email, en Gmail, http://www.gmail.com, el cual se identifica por etiquetas, para cada asignatura.

Prof.: Jorge Rojas L.

Grupos Yahoo. Manejo de un grupo para cada una de las asignaturas que él dicta.

Tabla 57: Mecanismos Publicación de Contenidos Actuales.

119

Un lugar de privilegio, lo ocupa la aplicación diseñada por el CICULS para la toma de asignaturas y para las actas de calificaciones semestrales o anuales. Se hace referencia a esta aplicación, ya que independiente del diseño que hay para la solución a dicho problema, que cabe destacar ya lleva más de 6 años de estudio, cuyo resultado no ha estado exento de polémicas, reclamos, e intolerancia, la abstracción del problema es vital para el caso de estudio de la presente Memoria de Titulación.

2.3.MARCO INSTITUCIONAL DEL PROYECTO

La Universidad dispone de variadas plataformas Webs, de las cuales no todas dependen del CICULS, pero sí son subdominios en algunos casos de la Universidad; ejemplo de ello son el portal de la Biblioteca y el de Vicerrectoría Académica.

La Universidad, por medio de sus Unidades Básicas, está impulsando la difusión de éstas mediante las TIC.

La solución propuesta, de ser aprobada, debe ser un aporte para la Institución, desde tres perspectivas complementarias.

Perspectiva del Usuario.o Servicio de mejor Calidad.o Ampliación de la disponibilidad horaria, es decir, facilidad a los

Académicos de poder coordinar las actividades desde cualquier computador con acceso a Internet, especialmente cuando éstos están en Congresos, Capacitaciones, Conferencias, etc.

o Facilidad de acceso, tanto para los alumnos como para los académicos.

o Retroalimentación, mediante la utilización de foros y/o líneas de comunicación, tales como correo electrónico.

Perspectiva Institucional: descentralizar / externalizar procesos.o Reducción de Costos de multiplicación de material (Los costos se

traspasan a los Estudiantes o terceros).o Vía de comunicación hacia las empresas que requieran de algún tipo

de servicio o asesorías, que pueda realizar un académico o los alumnos dirigidos por éste.

Perspectiva Externa.o Estar a la vanguardia de la utilización de los recursos

computacionales, en especial de las TICs.o Una forma de trabajo colaborativo entre la Institución y el personal

académico.o Beneficios tanto particulares como institucionales, debido a que

estarán disponibles las competencias de los académicos que prestan servicios a la Universidad, independiente de cual sea su tipo de contrato con la Casa de Estudios.

120

o Una forma de dar a conocer los servicios que puedan necesitar las empresas, mediante alumnos en práctica, o contactos profesionales con los académicos.

3. DIAGNÓSTICO

La elaboración de una nueva plataforma para dar solución al manejo del contenido generado por las Unidades Básicas, es factible de gestionar si se realiza un trabajo mancomunado, identificando las tareas que ya puede realizar el CMS de Matemáticas, y los procesos adicionales que son requeridos para la publicación, mantención, y difusión, de las páginas personales de los académicos.

Si bien en este punto es importante reconocer lo ya realizado por el CICULS, es necesaria la unión de esfuerzos, tanto a nivel académico como a nivel institucional, para el funcionamiento óptimo del Sistema, esto ya sea con incentivos institucionales y capacitaciones.

3.1.REALIZACIÓN ACTUAL DE LOS PROCESOS.

El CMS de Matemática realiza la publicación del contenido académico, separado mediante los TEL de las asignaturas; lamentablemente, una de las mayores debilidades del actual CMS es la nula integración con la información que dispone el CICULS, pero en particular Matrícula y Registro Académico.

Además, debido a las deficiencias que tiene la red de nuestra Casa de Estudio, el acceso interno y externo al CMS, es poco eficiente, lento, y tiene una disponibilidad inferior al 60%181. El equipo en el cual está el CMS no es un servidor, es sólo un equipo mejorado, y por ende el acceso a disco es extremadamente lento.

Actualmente los alumnos, después de las mejoras que se realizaron al CMS, pueden visualizar sólo el contenido de las asignaturas a las cuales está inscrito, pero para el caso del académico se pueden visualizar todas las asignaturas, y de ahí se debe acceder a la cual se tienen los permisos de publicación.

El Departamento de Matemática, en particular, no dispone del personal, para la mantención y actualización del “servidor”.

Los procesos de publicación de asignaturas ya están disponibles, tanto en el CMS de Matemática, como en los otros que actualmente están operativos en la Universidad; una mejora a ello, sería la posibilidad de las páginas personales de los académicos, con una duplicación en el respectivo CMS que les corresponda.

181 Estadística obtenida en Diciembre del año 2005.

121

Debido a la gran cantidad de virus, además que el problema de seguridad es crítico, y los correos electrónicos y otras formas electrónicas de comunicación, no funcionan eficientemente.

3.2.CRITERIOS DE VALOR AGREGADO PARA REALIZACIONES ALTERNATIVAS

Con lo disponible actualmente, muchas de las soluciones o propuestas de solución en este caso son factibles. La solución propuesta valoriza a los procesos actualmente implementados, agregando factores, tales como:

Alto grado de innovación tecnológica. Completitud en el trabajo de análisis y diseño. Comprensión y manejo del problema. Medición de la utilización de los prototipos, con consultas a los distintos

actores del sistema, las cuales deben ser cuantificables y cualificables. Incorporación de estándares y procedimientos para la plataforma

computacional. Diseño arquitectónico escalable. Diseñar nuevos servicios que refuercen el apoyo del Sistema. Cumplimiento de las condiciones de Operación, es decir, los requisitos no

funcionales.

3.3.ARQUITECTURA ACTUAL DEL CMS MATEMÁTICA.

Se considerará como esquema inicial la solución Arquitectural propuesta por los Ingenieros Álvaro Olivares y Carlos Gómez, la cual será explicada en profundidad a continuación.

122

MatCMS

Repositorio

Contenido

Base deDatos

Metadata

Archivos

Núcleo

UsuarioControl de AccesoWorkflowCacheAdministraciónEstadísticasExcepciones

CMS_page

Mantención

Apache 2.0

Trabajo deCRON

mod_php

Manejadores deTipos de Recursos

Asistente de CreaciónAsistente de EdiciónDespliegue

Tipo de RecursoTemplate

Figura 58: Arquitectura MATCMS.

Analizando esta Arquitectura, se puede describir el ciclo de vida de una petición (pasando por la URL del navegador Web), la cual es respondida por el sistema siguiendo los pasos que se detallan a continuación.

3.3.1. PETICIÓN DE UN RECURSO.

El punto de acceso externo único del sistema, es el que se denomina CMS_page. Éste es un script ubicado en la raíz del sitio que actúa como Front Controller182, el cual tiene por responsabilidad parsear183 el URL solicitado al Servidor Web (Apache) y delegar la responsabilidad de responder a la petición al Núcleo de la Aplicación.

El Núcleo recibe la petición, obtiene del contexto184 el ID185 del usuario que está realizando la petición. Con los datos: Recurso Solicitado y Nombre de Usuario, el sistema obtiene del ACL186 la lista de permisos asociados.

182 Ver capítulo 2 de la Presente Memoria de Titulación.183 Se entiende por Parsear, un analizador sintáctico el cual es un programa que reconoce si una o varias cadenas de carácteres forman parte de un determinado lenguaje.184 Referenciado a lo que está en el ambiente.185 Identificador.186 Access control list.

123

El Sistema evalúa si el usuario actual dispone de los permisos necesarios para realizar la operación solicitada. El sistema repite este proceso para el Padre del Recurso, y a su vez para el padre de éste, hasta llegar a la raíz del sitio. Si al concluir la evaluación de los permisos la respuesta es negativa, se informa al usuario que su petición ha sido denegada.

Si el usuario tiene acceso al recurso, el sistema evalúa el estado actual de éste, lo cual se realiza en base al Workflow definido para los recursos del sistema187.

Si el Recurso está en Estado Publicado o está Esperando Publicación, y el usuario que está solicitando es el creador del recurso, que espera aprobación, y el Sistema autoriza la petición.

3.3.2. GENERACIÓN DE RESPUESTA.

Una vez que se autorizó la petición, el núcleo obtiene de la Metadata del Recurso, el Tipo de Recurso; con esta información utiliza el patrón de Diseño Factory, para obtener otro patrón de Diseño, Dependency Inyection, con lo cual se logra cargar dinámicamente el Controlador del Tipo de Recurso solicitado.

Si el sistema reconoció el Tipo de Recurso, encontró el Controlador y logró cargarlo exitosamente, el sistema realiza la llamada al Método que corresponde a la Interfaz genérica de los Controladores de Tipo Recurso y con ello carga la plantilla o template asociada188.

El sistema delega la responsabilidad (patrón Chain of Responsability) de realizar la acción específica solicitada por el usuario en el controlador de Tipo de Recurso que corresponde, ya que éste conoce el Negocio para el Recurso específico, y tiene acceso a la información específica asociada al Recurso, a diferencia del Núcleo, que no tiene información del Negocio, y sólo tiene acceso a la Metadata del Recurso.

La respuesta generada por el Controlador del Tipo de Recurso es enviada al Cliente, y se incrementan los contadores de acceso en la Metadata.

187 Ver capítulo 3, de la Memoria de Titulación de los Ingenieros Álvaro Olivares y Carlos Gómez.188 Acá se ve la aplicación de otro Patrón de Diseño, Template y Builder.

124

DelegaResposabilidad

Solicita ID_Usuario

Obtiene Permisos Asociados

Busca Hasta Raiz del Sitio

Autoriza Peticion

Obtiene Metadata del Recurso

Solicita Tipo de Recurso

CMSPAGE_FrontControler CMSPAGE_Nucleo Directorio_TipoRecurso

Figura 59: Diagrama de Secuencia, Petición de Recurso.

3.4.MODELO DE CONCEPTUAL DE MATCMS.

125

pertenece

esta

Tiene permiso asociado

controla

otorga

posee

tiene

clasifica

otorga_permiso

dueñoautorpublicador

es hijo

Tipo

Tiene un

Es un

Tipo

Tiene un

Es un

Tipo

Tiene un

Es un

Tipo

Tiene un Es un

Tipo

Tiene unEs un

Tipo

Tiene un

Es un

es_administrado

acl_grupo

autonomosubdirectoriolecturaescrituraejecucion

BLBLBLBLBL

grupo

id_gruponombrefecha_caducadou_moderadorrid_asignaturarid_tel

<pi> IA50DLILILI

<M>

Identifier_1 <pi>

acl

autonomosubdirectoriolecturaescrituraejecucion

BLBLBLBLBL

recurso

id_recursoubicacionvisiblef_creacionf_modificacionf_revisionf_caducadototal_accesolast_weekacceso_ponderadothis_weekf_next_week

<pi> LIA50BLDTDTDTDTLILILILILI

<M>

Identifier_1 <pi>

Usuario

uidusernameclavenombrespaternomaternoactivoemailhomepagetelefonof_creaciontotal_accesolast_weekacceso_ponderadothis_weekf_next_weeklast_loginpag_usuario

<pi> LIA15A15A35A20A20BLA255A255A20DTLILILILILITSLI

<M>

Identifier_1 <pi>

estado

id_estadonombredescripcion

<pi> A1A50A70

<M>

Identifier_1 <pi>

tipo_recurso

tipo_recursonombretipo_hijosolo_tipovisibletiene_hijosauto_actualizar

<pi> A3A50A3BLBLBLBL

<M>

Identifier_1 <pi>

grupo_usuario

aprobado BL

aviso

textourl

A100A255

Identifier_1 <pi>

pagina

nombredescripcion

A50A70

link

urldescripcion

A255A70

agenda

id_agendanombreanhodescripcionactiva

LIA50SIA70BL

evento

nombrefechahoraduracionubicaciondescripcionvisible

A50<UNDEF><UNDEF><UNDEF>A50A70BL

sitio

hosttemplatebrowser

A50LIA80

Figura 60: Diagrama Conceptual de MATCMS.

126

3.5.MODELO DE CLASES DE MATCMS.

1..1

1..11..1

1..1

1..1 1..*

0..1

0..*

CMS

++++++

CMS_dirtiempodb_repodbinicio_xmlxslt_procc

: string: object: string: string: string: resource

+ CMS ()

chrono

cronometro

+ contador : int

+++++

cronometro ()inicia_func ()fin_func ()show_gantt ()busca_fin ()

: void: void: void: int

Permiso

+++++++

dblinkaccesopermisosuidrecursoid_otorgador

: string: int: array: array: int: int: int

+++++++++++++++++

Permiso ()set_user_rec ()datos_recurso ()listado_padres ()set_permiso ()edit_permiso ()del_permiso ()check_permiso_all ()derecho_de_acceso ()permiso_de ()permiso_de_padres ()lista_otorgador ()get_otorgador ()acceso_total ()abrir_conexion ()usar_conexion ()cerrar_conexion ()

: void: array: array: void: void: void: void: void: boolean: boolean: void: int: boolean: void: void: void

CMS_Repositorio

++++

UIDrecursosaccesosclase_crear

: int: array: array: array

+++++++++++++++++++++++++++++++++++++++++++++++++++

CMS_Repositorio ()sel_root ()show ()show_in_panel ()nombre ()descripcion ()ext ()get_clase ()crear ()borrar ()editar ()crear_sigte ()borrar_sigte ()editar_sigte ()u_name ()username_uid ()get_user ()get_user_list ()check_user ()nom_tipo_recu ()tipo_recu ()list_tipo_recu ()get_sitio ()get_sitio_name ()get_sitio_menu ()get_sitio_title ()path ()dir_punto ()dir ()new_last_update ()aplicar ()xml_get ()mejor_alternativa ()tiene_acceso ()check_recu ()get_recu ()crear_recu ()editar_recu ()borrar_recu ()set_dueno ()set_autor ()workflow ()por_aprobar ()por_revizar ()estado_recu ()estado ()set_fechas ()carga_clase ()carga_clase_crear ()update_stats ()update_stats_usuario ()

: string: void: void: string: string: string: string: string: string: string: string: string: string: string: string: array: array: boolean: string: array: array: array: array: string: string: array: array: array: string: void: string: int: boolean: boolean: array: int: void: void: void: void: void: aray: array: string: string: void: void: void: void: void

CMS_tipo

+++++

RIDCMSUbiTipoerrores

: int: CMS_Repositorio: string: string: array

+++++++++++++++++++++++++

CMS_tipo ()nombre ()descripcion ()ext ()show ()show_solo ()show_in_template ()show_in_panel ()actualiza ()crear ()borrar ()editar ()crear_sigte ()borrar_sigte ()editar_sigte ()do_crear ()do_editar ()do_borrar ()error ()xml_errores ()borrar_errores ()hay_errores ()pasar_archivo ()pasar_ext ()directorio_xml ()

: string: string: string: void: void: void: void: boolean: string: string: string: string: string: string: boolean: boolean: boolean: void: string: void: void: void: string: string

CMS_tipo_age

CMS_tipo_Arc

+++++++++++++

nombre ()show_solo ()show_in_template ()ext ()crear ()crear_sigte ()editar ()editar_sigte ()borrar ()borrar_sigte ()do_crear ()do_editar ()do_borrar ()

: string: void: void: void: string: string: string: void: string: string: boolean: boolean: boolean

uploader

CMS_tipo_DIR

+++++++

nombre ()descripcion ()show_in_template ()show_in_panel ()crear ()crear_sigte ()do_crear ()

: string: string: void: void: string: void: boolean

CMS_tipo_ASI

+++++++++++

show_in_template ()modulo ()novedades ()novedad ()secciones ()secciones2 ()ultima_clase ()listado ()crear ()crear_sigte ()do_crear ()

: void: void: string: string: void: void: string: string: string: string: boolean

CMS_tipo_avi

++

textourl

: string: string

++++++++

nombre ()descripcion ()show_solo ()show_in_template ()carga ()crear ()crear_sigte ()do_crear ()

: string: string: void: void: void: string: string: boolean

CMS_tipo_cal

++++

ext ()show_in_panel ()show_solo ()show_in_template ()

: string

calendario

+++++++++++++

diamesyeard_inicio_mesn_diasn_semanasmesesdias_ldias_ctemplatepaginapagina_sigcss

: int: int: int: int: int: int: array: array: array: int: int: int: int

+++++

calendario ()genera_xml ()dias_mes ()calcula_semanas ()crea ()

: string: int: int

CMS_tipo_css

++

ext ()show_solo ()

: string

CMS_tipo_Dav

++

show_in_template ()show_solo ()

CMS_tipo_Dur

++

show_in_template ()show_in_panel ()

CMS_tipo_eve

CMS_tipo_pag

+++

nombredescripcioncargadas

: string: string: int

++++++++

nombre ()descripcion ()carga_cahe ()show_in_template ()ext ()crear ()crear_sigte ()do_crear ()

: string: string: int

: string: string: string: boolean

CMS_tipo_htm

++

show_in_template ()ext ()

CMS_tipo_rss

+ actualizado :

+++++

nombre ()show_in_template ()show_in_panel ()actualiza ()ext_rss ()

: string

: boolean: string

CMS_tipo_sys

+ show_in_template ()

CMS_tipo_TAR

+ show_in_template :

CMS_tipo_TEL

++

show_in_template ()show_in_panel ()

CMS_tipo_tie

+ actualizado : boolean

+++++

nombre ()show_in_panel ()show_in_template ()actualiza ()ext_tie ()

: string

: boolean: string

CMS_tipo_tpl

++++

nombreshow_solochange_tagschange_head

: string: : string: string

CMS_tipo_url

++++++++++++++

nombredescripcionextshow_in_templateshow_solocrearcrear_sigteeditareditar_sigteborrarborrar_sigtedo_creardo_editardo_borrar

: string: string: string: : : string: string: string: string: string: string: boolean: boolean: boolean

CMS_tipo_wiz

+ xml : string

++++

nombre ()show_in_template ()show_solo ()aplicar_asistente ()

: string

CMS_Transforma

+ pre_body : string

++++++++++++++++++++

CMS_Transforma ()bread_crumb ()show_title ()show_site_name ()show_title_site ()menu ()vea_tambien ()mapa ()_mapa ()mapa_publi ()_mapa_publi ()lastmod ()autor ()link_user ()onload ()head ()set_javascript ()inicio_html ()show_login ()show_modulos ()

: string

: string: string: string: string: string: string: string: string: string: string: string

CMS_tipo_

Figura 61: Diagrama de Clases de MATCMS.

127

4. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA

4.1.PROPÓSITO DEL SISTEMA.

Una Plataforma Docente para la publicación de contenidos personales (Nombre completo, grados académicos, líneas de interés, publicaciones), contenidos de Docencia, ya sea en pre y post grado.

Lo anterior, mediante un look and feel uniforme, con distintos niveles de acceso, es decir, en el caso la docencia, si el académico lo decide, puede estar disponible para todo visitador (patrón visitador); en cuanto a contenido protegido, requerirá de un mecanismo de autentificación.

Tener una amplia cobertura, con un alto nivel de disponibilidad, es decir, acceso las 24 horas del día, los 365 días del año, desde cualquier punto en el cual se disponga de Internet.

Proporcionar cualquier tipo de información publicada, para el apoyo de la docencia a todo nivel universitario.

Ser un mecanismo efectivo de comunicación con el personal académico, mediante un Webmail.

Consolidar, a nivel tecnológico a nuestra Casa de Estudio, con el empleo de las TICs, como soporte a la labor docente, tanto en pregrado como en postgrado.

Disponer de una plataforma uniforme como Casa de Estudios, para la prestación de servicios.

Mediante la utilización del correo electrónico, ser un medio de comunicación con los alumnos inscritos en las asignaturas, pero en especial para aquellos que no disponen del tiempo de asistir a clases, jornadas vespertinas, programas especiales, y con aquellos que sólo asisten a las evaluaciones.

Eliminación progresiva de la publicación de contenidos en diarios murales autorizados y no autorizados, de información relevante para las asignaturas.

Evitar la publicación de las evaluaciones en los diarios murales antes descritos, o simplemente en las puertas o ventanas de los académicos.

Uniformidad de la presentación de información, de horarios, evaluaciones, informaciones entre otros.

Reducir los innumerables llamados telefónicos, para consultar si un académico puede ser contactado en su respectiva oficina.

128

4.1.1. PROPUESTA PÁGINA ACADÉMICO.

Cada académico puede solicitar la habilitación de su página personal, a un sitio destinado para ello, como por ejemplo, http://www.alumnosuls.cl/academicos/ggatica/ en donde se puede encontrar la siguiente información pública:

Antecedentes Personales, nombre, título profesional y grado académico, teléfonos, líneas de interés, curriculum resumido, etc.

Formulario de Contacto. Distribución de la carga horaria para el Semestre, indicando los horarios de

atención de alumnos, en caso de disponer de éstos189. Docencia:

o Pregrado: Primer Semestre 2006

Curso Unoo Programa de Estudioo Apuntes y Archivos para descargaro Tareas y Ejercicioso Notaso Enlaces de Interéso Avisos de la Asignaturao Listado Alumnos Inscritos en las Asignaturaso Envío Correo Masivo (alumnos inscritos)o Creación Foro de Discusión

Curso Dos Laboratorio Uno

Segundo Semestre 2006 Curso Laboratorio tres

o Postgrado: Depende de la formulación del programa de estudios. Publicaciones Enlaces de Interés Avisos y Noticias de Interés Módulo de Administración

Si la información de las asignaturas los académicos deciden que sea de carácter privado, la situación varía solo en el hecho que no se tendría acceso a los contenidos de las asignaturas, y solo se publicaría el nombre de ellas.

Como cada académico, y es más, cada funcionario de la Universidad, tiene un código de funcionario de 6 caracteres, con el objetivo de proporcionar una mayor seguridad, se sugiere que la clave de acceso al sistema sea modificada a una de sobre 8 caracteres.

189 Cabe destacar que los académicos con Jornada Parcial, no están obligados a disponer de horarios de atención de alumnos, por diversos motivos que no se ajustan al objetivo del trabajo.

129

4.1.2. PROPUESTA PÁGINA ALUMNOS.

Cada alumno ya dispone de su propio portal, sólo se debe incorporar un espacio para la plataforma docente.

Figura 62: Look and Feel, Página de los Alumnos.

4.2.REQUERIMIENTOS FUNCIONALES

El sistema consiste de cinco funcionalidades claramente identificables.

1. Creación Página Personal Académico: a. Cada académico tiene la capacidad de actualizar su pseudos blog, es

decir, eliminar avisos antiguos, incorporación de nuevas publicaciones, revisión de sus históricos, modificación de su currículum resumido.

b. Es el espacio propicio para ofrecer sus competencias a la empresa, por cierto fuera de su horario de trabajo; en el caso de ser un científico destacado, dar a conocer los resultados de sus investigaciones.

c. Publicación de horarios de clase, investigación, y disponibilidad.2. Asignatura:

a. Proceso de Publicación de Archivo, ya sea este de tipo Word, imagen, Excel, presentaciones, programas, etc.

b. Proceso de Publicación de Enlaces de Interés, en donde es necesario una descripción, nombre, y dirección Web.

c. Proceso de Publicación de Aviso, concerniente a la asignatura, por ejemplo, horario y lugar de una evaluación y su corrección, modificación de la entrega de un trabajo, entre otros.

d. Envío de correo masivo a los alumnos inscritos en una Asignatura en particular.

e. Inscripción de alumnos al contenido de la asignatura manualmente (Especialmente a los alumnos de postgrados o diplomados).

3. Proceso de Actualización de las Asignaturas: Esta funcionalidad se refiere a la continuidad que habitualmente tienen algunos académicos en la Universidad, al dictar semestral o anualmente las mismas asignaturas.

a. Revisión del material publicado.b. Actualización de los Contenidos.

130

c. Eliminación de los alumnos inscritos semestre a semestre.4. Comunicación mediante Correo Electrónico masivo.

a. El sistema notificará a los alumnos inscritos en una Asignatura, mediante correo electrónico que un académico ha realizado una nueva publicación.

b. El sistema puede permitir en vez de publicar un aviso en la aplicación, enviar directamente el aviso en su totalidad a los alumnos registrados en la asignatura.

5. Publicación de Avisos y Noticias de Interés.a. Los avisos son los concernientes al académico, tales como, la ausencia

de éste por diferentes motivos.b. En caso de ser académico jornada parcial, informar su horario para la

atención de alumnos.c. Noticia de interés relacionada con la línea de especialización del

académico.d. Informar defensas de Memorias de Titulación, en la cual es profesor

guía o correferente.

Las siguientes opciones son deseables como una posible mejora.

6. Foros por Asignatura.a. Puede habilitarse la opción de generar un tema de discusión referente a

la asignatura o de actualidad.b. Especialmente es la opción de referirse a tópicos de actualidad,

principalmente en asignaturas de índole humanistas.7. Generación de una encuesta de interés para el académico.

4.3.REQUERIMIENTOS NO FUNCIONALES

La Plataforma deberá tener las siguientes propiedades sistémicas:

Operación 7 días a la semana, por 24 horas día. Disponibilidad de Servicios del 99%, esto quiere decir que no estará la

Plataforma a disposición de los usuarios, sólo 3 días en todo el año. Volumen Transaccional de 50 TPS (Transacciones por segundo). Clientes en línea por sobre 3000 usuarios de tipo alumno, considerando

que la matrícula de la ULS es superior a 8000 alumnos. Capacidad de respaldo de 5 años. Navegadores: Internet Explorer 5.5 o superior, Netscape 5.0 o superior,

Mozilla Firefox 1.0 o superior, Opera (Linux), entre otros. Equipos de Accesos Fijos (Computadores personales, notebook) o Móviles

(PDA, celulares), aplicación del patrón Adapter. Mecanismos de Seguridad del Sitio y/o Aplicaciones: HTTPS, SFTP, Firma

Electrónica, Sesión, Base de Datos encriptadas. Tiempo de Carga por página, inferior a un segundo en el servidor. Según las estimaciones realizadas, y considerando que la estructura

organizacional de la Casa de Estudios, se dividen en Facultades, y éstas a

131

su vez, en Unidades Básicas, los Departamentos190; se estima por sobre 900 páginas personales191.

4.4.MODELOS DE ALTO NIVEL

Los datos resumidos de los puntos anteriores, han permitido la elaboración de modelos parciales de alto nivel, es decir, casos de usos, modelo estático del dominio, arquitectura, entre otros.

4.4.1. CASOS DE USOS

En virtud de los puntos anteriores, una descripción de la solución del problema, se puede apreciar mediante el siguiente diagrama de Casos de Usos.

Administrador (CICULS)

Habilita Espacio del Académico

Estima espacio, proporciona usuario, y declara las reglas del negocio

Académico

Página Personal Académicoshttp://alumnosuls.cl/academicos/ggatica

Presentación Datos Académicos

Asistentes de Publicación de Contenidos

ContenidosPúblicos

ContenidoProtegido

Inscripción ManualAlumnos

Alumnos

Público General

Portal Oficial de los Alumnos

Asignaturas Inscritas mediante BIAOtros

Tienen

Administran

Visitan

Manejan

Solicita

Incorpora

Figura 63: Diagrama de Casos de Usos.

4.4.2. MODELO CONCEPTUAL.

190 Si se estima que el Departamento de Matemáticas tiene 22 académicos y cubren el 40% de la Docencia, al menos es necesaria la contratación de personal con jornada parcial de sobre 30 personas.191 Información proporcionada informalmente por la Asociación de Académicos.

132

Genera

Tiene

Traspasa

ESTA

Tiene

Dispone

Clasifica

DaAcceso

TienePermisoAsociado

Dueno

EsHijo

Efectua La Accion

Otorga_Permiso

SID

SecurityIdentifierEsGrupoFechaCreacionUsuarioCreadorNombre

<pi> A50BLDTA50A50

<M><M><M><M><M>

Identifier_1 <pi>

GRUPOUSUARIO

ApPaternoApMaternoEmailHomepageTelefonoPaginaUsuarioNombres

A50A50A255A255A20LIA40

<M><M>

<M>

GRUPO_USUARIO

Aprobado BL <M>

ACL

LeerMetaDataLeerDataEscribirDataCaducarBorrarHacerseDuenoPublicacionAutonomaLeerPermisosEsRecibidaPorHerenciaNoHeredardelPadreNoHeredableParaHijosVerTraficodelRecurso

IIIIIIIIBLBLBLI

<M><M><M><M><M><M><M><M><M><M><M><M>

RECURSO

IdRecursoVisibleURLNameNombreRecursoDescripcionRecurso

<pi> LIBLA30A255A255

<M>

<M><M><M>

Identifier_1 <pi>

TIPO_RECURSO

IdTipoRecursoTipoHijoPorDefectoSoloTipoHijoPorDefectoPuedeTenerHijoNecesitaActualizacionNombreTipoRecursoDescripcionTipoRecurso

<pi> A3A3BLBLBLA255A255

<M><M><M><M><M><M><M>

Identifier_1 <pi>

LOG_DE_ACCESO

FechaInicioFechaTerminoContadorTotaldeAccesosUltimoAcceso

<pi> DTDTLIDT

<M>

<M><M>

Identifier_1 <pi>

ESTADO

IdEstadoNombreEstado

<pi> A3A50

<M><M>

Identifier_1 <pi>

RECURSO_ESTADO

FechaHora DT <M>

Figura 64: Diagrama Conceptual de Base de Datos.

A continuación se detallan algunos componentes del modelo anterior.

133

Access Control List, ACL.o Leer Metadata: Permite leer lo que está en la tabla Recursos; por

ejemplo, solicitar el listado de hijos de un directorio; otro ejemplo a considerar es saber el nombre de las asignaturas que se dictan, sin necesidad de Ingresar a cada Asignatura. Actualmente el CMS de Matemáticas, al Ingresar al Sistema, se desconocen cuales son las TEL de cada asignatura, y por ende quiénes son sus responsables.

o Leer Data: Éste campo permite abrir y visualizar el contenido de un recurso en particular.

o Escribir Data: Permite modificar un Recurso, un ejemplo puntual de ello podría ser modificar el texto de un aviso, o modificar un archivo que estaba publicado.

o Caducar, este campo permite cambiar el Estado del Recurso a Caducado, con lo cual ya no es visible a los usuarios.

o Borrar, como su nombre lo indica, permite eliminar definitivamente un Recurso, debido a distintos inconvenientes, como por ejemplo, un recurso que fue mal publicado.

o Hacerse Dueño, el dueño o propietario tiene los permisos de realizar cualquier acción sobre el recurso, por lo tanto, hacerse dueño implica tomar el control total sobre el Recurso, quitándole el permiso al usuario actualmente dueño.

o Publicación Autónoma, cuando éste es Falso, la acción es quedar en espera hasta que el usuario que solicitó el permiso las apruebe.

o Leer Permisos, permite utilizar el resultado de la suma de los permisos asociados a éste recurso.

o Es Recibida Por Herencia, no es un permiso explícito al recurso, ya que lo recibe por herencia.

o No Hereda del Padre, si este campo es verdadero, el recurso no va a recibir ningún permiso proveniente del padre, sino que debe redefinir todos sus permisos.

o No Hereda Para Hijos, si este campo es verdadero, quiere decir que sus permisos no pueden ser heredados.

o Ver Tráfico del Recurso, tiene acceso para visualizar el tráfico que ha tenido el recurso.

Recurso.o Visible, si este campo es falso no será mostrado en un directorio.o URL Name, opción de mejora al CMS actual del Departamento de

Matemáticas, el cual permite visualizar un nombre en la URL en vez de una concentración de números.

o Name, nombre del recurso, aparece en un directorio como título de un Recurso.

o Descripción, aparece como segunda línea del nombre.

134

Log de Acceso.o Fecha de Inicio, inicio del periodo de la unidad de medición (días,

semanas, meses).o Contador Total de Acceso, permite cuantificar la cantidad de acceso

que se registran entre la fecha de Inicio y la Fecha de Término.o Último Acceso, adquiere relevancia cuando los periodos de medición

son demasiados extensos. Tipo de Recurso.

o Tipo Hijo Por Defecto, es el tipo de recurso sugerido cuando se quiere generar un hijo para este tipo de Recursos, un ejemplo de ello, El tipo de hijo por Defecto del Directorio Aviso es Aviso.

o Solo Tipo Hijo Por Defecto, es el Tipo Hijo Por Defecto, es el único tipo permitido como hijo del Recurso.

o Visible, éste campo permite que ese tipo de Recurso no va a ser nunca postrado en un Directorio como por ejemplo Tipos del Sistema, ejemplo Sitio, Template.

o Puede Tener Hijo, el recurso puede tener hijos asociados, por ejemplo, un archivo no tendrá jamás hijos.

o Necesita Actualización, el sistema debe preocuparse de refrescar el Recurso periódicamente, ejemplo contenido externo como RCS e informe del Tiempo.

o Estado, los estados posibles son Creado, En Edición, Esperando Aprobación Para Publicación, Publicado, Marcado Para Revisión, Caducado Por No Revisión y Caducado Por El Usuario.

SID, es el Security Identifier, es un número único asignado por usuario por sistema, para evitar la duplicación de usuarios.

Usuarioo Homepage, el URL que puede ser direccionada hacia cualquier parte

del www.o Pagina Usuario, es el ID de la Página Personal del Usuario.

135

4.4.3. MODELO FÍSICO DE BASE DE DATOS.

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE% FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

FK_%REFERENCE%

SID

SecurityIdentifierEsGrupoFechaCreacionUsuarioCreadorNombre

char(50)tinyint(1)datetimechar(50)char(50)

<pk>

GRUPO

SecurityIdentifierUSU_SecurityIdentifier

char(50)char(50)

<pk,fk2><fk1>

USUARIO

SecurityIdentifierApPaternoApMaternoEmailHomepageTelefonoPaginaUsuarioNombres

char(50)char(50)char(50)char(255)char(255)char(20)bigintchar(40)

<pk,fk>

GRUPO_USUARIO

GRU_SecurityIdentifierSecurityIdentifierAprobado

char(50)char(50)tinyint(1)

<pk,fk1><pk,fk2>

ACL

IdRecursoSecurityIdentifierUSU_SecurityIdentifierLeerMetaDataLeerDataEscribirDataCaducarBorrarHacerseDuenoPublicacionAutonomaLeerPermisosEsRecibidaPorHerenciaNoHeredardelPadreNoHeredableParaHijosVerTraficodelRecurso

bigintchar(50)char(50)intintintintintintintinttinyint(1)tinyint(1)tinyint(1)int

<pk,fk1><pk,fk2><fk3>

RECURSO

IdRecursoIdTipoRecursoREC_IdRecursoSecurityIdentifierVisibleURLNameNombreRecursoDescripcionRecurso

bigintchar(3)bigintchar(50)tinyint(1)char(30)char(255)char(255)

<pk><fk1><fk3><fk2>

TIPO_RECURSO

IdTipoRecursoTipoHijoPorDefectoSoloTipoHijoPorDefectoPuedeTenerHijoNecesitaActualizacionNombreTipoRecursoDescripcionTipoRecurso

char(3)char(3)tinyint(1)tinyint(1)tinyint(1)char(255)char(255)

<pk>

LOG_DE_ACCESO

IdRecursoFechaInicioFechaTerminoContadorTotaldeAccesosUltimoAcceso

bigintdatetimedatetimebigintdatetime

<pk,fk><pk>

ESTADO

IdEstadoNombreEstado

char(3)char(50)

<pk>

RECURSO_ESTADO

IdRecursoIdEstadoSecurityIdentifierFechaHora

bigintchar(3)char(50)datetime

<pk,fk1><pk,fk2><fk3>

Figura 65: Diagrama Físico de Base de Datos.

4.4.4. DIAGRAMA DE ACTIVIDAD DE LA SOLUCIÓN PROPUESTA.

El diagrama de actividad de la solución propuesta a diferencia del utilizado en MATCMS, omite la búsqueda recurrida, con lo cual permite menores costos de búsqueda, es decir, ésta es lineal, a diferencia de MATCMS que es de O(n2).

136

DelegaResposabilidadObtiene_ID_Usuario

Obtiene del ACL los Permisos del Usuario

Evalua Los Permisos Recursivamente

Verifica Estado Actual del Recurso

Obtencion del Tipo de Recurso

Mostrar Contenido

Retorna Contenido de la Respuesta

Incrementa Controles de Acceso de la Metadata

Retorna Contenido

CMSPAGE_FrontControler CMS_Nucleo Manejador_TipoRecurso

Figura 66: Diagrama de Actividad.

137

4.5.REALIZACIÓN PROPUESTA DE LOS PROCESOS.

4.5.1. DEFINICIONES DE NEGOCIO.

En éste punto en particular, cabe destacar al menos las siguientes Definiciones, las cuales están acompañadas con al menos un ejemplo.

Alumno Inscrito en Asignatura: Es un usuario con permisos de lectura, sobre un recurso de tipo asignatura o tipo TEL, el cual pertenece al grupo alumnos, es decir, corresponde a todos los alumnos de la asignatura o solo al ejercicio, además responde a la siguiente pregunta: “Todos los alumnos que pertenecen a un TEL o a toda la asignatura”; otro ejemplo a citar es un aviso a los Alumnos inscritos en la Teoría 3 de Introducción al Cálculo: “Estimados alumnos no hay clases mañana viernes debido a que el profesor se encuentra en perfeccionamiento, fecha de publicación miércoles 09:00 hrs”.

Académico Responsable de un TEL: Es el dueño del Recurso TEL, es decir, es el académico que publica en el TEL; un ejemplo de ello podría ser que el Académico XXX YYY, publica en el ejercicio 2 de XXXXXX, para los alumnos de YYYYYYYY.

Contenido Reutilizable: Es un recurso de un tipo específico, el cual tiene la propiedad de reutilizable en TRUE.

4.5.2. REGLAS DE NEGOCIO.

En este acápite cabe mencionar algunas de las reglas de negocio que conciernen al problema.

Cuando se genera un TEL, si la asignatura no existe, se crea asignando como dueño al sistema, y dentro de ello se crea el TEL a generar.

El TEL tiene como dueño a un profesor responsable, proporcionando el permiso para poder escribir en la Asignatura, es decir, cualesquiera académico tiene la facultad de asumir la coordinación (No puede eliminar la Asignatura).

Lista Control de Acceso (ACL192); los permisos pueden o no ser heredables, los hijos pueden o no tomar los permisos del padre; si se cumple lo anterior, es posible negar el acceso de un recurso que ha recibido al permiso por herencia (permiso explícito)

Los permisos son acumulativos, es decir, los permisos de un usuario, son la unión de los permisos del usuario más los permisos de todos los grupos a los cuales éste pertenece.

Los permisos de un TEL, sobrescriben a los permisos de una asignatura. Los permisos de negación tienen precedencia sobre los permisos de

acceso.

192 Acrónimo de Access Control List, http://msdn.microsoft.com/library/default.asp. ó en su defecto MSDN Active Directory, Security Principals.

138

Los permisos explícitos tienen precedencia sobre los permisos heredados; es decir, los permisos del TEL tienen precedencia sobre la asignatura.

Un permiso explícito va a sobrescribir a un permiso heredado de negación. Todos los recursos tienen un dueño, teniendo éste último todos los

permisos sobre el recurso. Ejemplo, en la siguiente figura se puede apreciar un árbol de recursos

Sistema (Todos tienen permiso de Lectura) Docencia (Todos los Académicos tienen permiso de Escritura)

Asignatura 1 (Permiso de Negación, “Rol del Encargado”) Teoría 1 Teoría 2 Teoría 3 (Hereda permiso de Escritura) …… Teoría N Ejercicio 1 Ejercicio 2 Ejercicio 3 …. Ejercicio N Laboratorio 1 Laboratorio 2 Laboratorio 3 …. Laboratorio N

Asignatura 2 Asignatura 3 …. Asignatura N

Figura 67: Árbol de Recursos Asignaturas, explicación de Permisos.

Basándose en la implementación utilizada por Microsoft en Windows 2003, al momento de hacer el login, se genera un Acces Token193, el cual es almacenado en una cookie. El access Token, ofrece un almacenamiento seguro (encriptado y validado) para guardar el SID del usuario y de todos los grupos a los cual pertenece.

Los recursos de tipo Asignatura tienen una propiedad que indica el Régimen de Estudio, es decir, si las asignaturas son de carácter semestral o anual.

193 Access Token.

139

4.5.3. PROCESOS DE NEGOCIOS.

En éste punto cabe mencionar los procesos del negocio que son fundamentales:

Importar Asignaturas, el proceso es el siguiente:o Obtener las asignaturas del Académico.o Seleccionar la(s) asignatura(s) a importar.

Para cada asignatura Seleccionada: Crear la asignatura como nuevo recurso donde el

sistema indica (Configuración). Asignar los permisos al Académico y bloquear el

acceso siempre y cuando la asignatura se define como privada.

Obtener los nuevos alumnos del TEL. Inscribir los alumnos a la Asignatura (Ver definiciones

de Negocio). Crear Asignatura, este proceso son aquellas asignaturas que no se pueden

obtener por la BIA, por ejemplo Diplomados, Postgrados)o Se crea un recurso del tipo Asignatura.

Se generan los N recursos hijos de tipo TEL. Se crean todos los recursos hijos de las TEL y de las

asignaturas. Cambio de Semestre, por lo general también conocido como el archivo de

la Asignatura.o Moviliza todos los recursos asignaturas que son del tipo semestral y

los archiva en una subcarpeta del sistema la cual a su vez tiene registrado el semestre y el año.

o Se retira el permiso a los alumnos de cada asignatura. Reutilizar Contenido.

o Buscar todas las oportunidades que se encuentre registrado que se publicó esa asignatura.

o Se listan todos los semestres en los cuales se dictó una Asignatura o TEL; se selecciona uno, junto los tipos de recursos tipificados como reutilizables.

o El Recurso Reutilizado se ubicará en la sección correspondiente en la nueva asignatura.

Creación Página Académico.o Es un recurso del sistema, el cual contiene al menos 8 recursos

hijos, los cuales están nombrados en el punto 4.11, de éste capítulo.o El tipo de recurso que será el horario del académico, permitirá su

edición (Mediante un Asistente), para ser publicado en la sección correspondiente.

o Los datos personales del Académico estarán almacenados en la Base de Datos, los cuales pueden ser modificados por un asistente manejado por el académico.

140

o El formulario de contacto para el envío de correo electrónico, será semejante al que aparece en el sitio oficial194 de la Universidad.

o El contenido de la Docencia del Académico, dispondrá de las asignaturas que actualmente éste dicta y de las que ha dictado, los permisos de estas serán los asignados al momento de la creación de la asignatura.

o Las publicaciones serán mediante un asistente, el cual permitirá la publicación de archivos. (Aún no se restringe el tamaño de los archivos)

o Los enlaces de interés también serán mediante un asistente, el cual consiste de nombre del enlace, descripción, y dirección Web.

o Los avisos y noticias serán semejantes a los anteriores, mediante la utilización de asistentes.

Caducación de Académico.o Como el nombre lo indica, se caduca, es decir, se cambia el estado

del recurso a caducado.o Cabe mencionar que ésta operación debe ser realizada por un

usuario que disponga de los permisos de acceso a la Base de Datos de los Académicos.

Creación de Horario, como ya se explicó en la creación de la página personal del Académico, esto se realizará mediante un asistente.

Creación de Asignatura, Las asignaturas son los tipos de recursos que concentra todo los recursos publicados por los docentes para una asignatura.

o Cuando se crea una asignatura a través del asistente de publicación también se crea la siguiente estructura interna compuesta de otros tipos de recursos, los cuales el usuario puede modificar, caducar y crear nuevos recursos para acomodar sus necesidades.

AsignaturaInformación de la AsignaturaAvisosSitios de Interés

TeoríaMaterial y ApuntesPresentacionesNotas y Pautas de PruebasOtros

EjerciciosGuías de EjerciciosApuntesEvaluacionesOtros

Laboratorios

194 http://www.userena.cl/directorio.html

141

Guías de LaboratorioEvaluaciones y TareasOtros

AyudantíasApuntes y GuíasPruebas AnterioresOtros

o El asistente crea todos estos recursos considerando la cantidad de teorías, ejercicios, laboratorios y ayudantías definidas al momento de crear la asignatura.

Los avisos, son el tipo más sencillo de publicación, puesto que sólo tienen un título, un mensaje y una dirección Web, la cual puede ser un URL, otro sitio o el número del recurso, asociada a ellos.

o Un aviso no requiere que el usuario indique una fecha de publicación o una fecha de caducado, puesto que MatCMS lo publica inmediatamente y lo caduca al cabo de un tiempo definido en el controlador.

Enlaces de Interés, en este tipo de recurso se almacena el nombre y la dirección de enlace que se desea guardar. MatCMS también permite agregar una descripción que explique al usuario qué tipo de información se puede encontrar en dicha dirección Web. En esta solución la descripción es obligatoria.

o Cuando un usuario hace un clic sobre una dirección Web, se contabiliza la visita y se direcciona una página a la dirección indicada.

4.5.4. ÁRBOL JERÁRQUICO DE LOS RECURSOS ASIGNATURAS.

En este punto se determinará el tipo de recurso que será cada sección.

Asignatura, Tipo Asignatura.Información de la Asignatura, Tipo Directorio.Avisos, Tipo Directorio Avisos.Sitios de Interés, Tipo Directorio Sitio de Interés.

Teoría, Tipo TEL.Material y Apuntes, Tipo Directorio.Presentaciones, Tipo Directorio.Notas y Pautas de Pruebas, Tipo Directorio.Otros, Tipo Directorio.

Ejercicios, Tipo TEL.Guías de Ejercicios, Tipo Directorio.Apuntes, Tipo Directorio.Evaluaciones, Tipo Directorio.Otros, Tipo Directorio.

Laboratorios, Tipo TEL.Guías de Laboratorio, Tipo Directorio.

142

Evaluaciones y Tareas, Tipo Directorio.Otros, Tipo Directorio.

Ayudantías, Tipo Directorio.Apuntes y Guías, Tipo Directorio.Pruebas Anteriores, Tipo Directorio.Otros, Tipo Directorio.

4.6.ASPECTOS TÉCNICOS DE LA SOLUCIÓN

La solución propuesta define mecanismos y tecnologías de interacción con el sistema, según los tipos de uso de los actores de éste. De las cuales se destacan las siguientes caraterísticas técnicas

El perímetro del sistema tendrá acceso controlado, vía perfiles y mecanismos de seguridad. Los mecanismos de acceso serán sincrónicos (servicios Web con XML) o asincrónicos (Web).

El sistema contendrá repositorios del registro de los recursos e históricos de estos. Estos repositorios e históricos residirán en bases de datos relacionales (SQL Server o Mysql), pero la decisión de un sistema centralizado o una estructura federada se propondrá dependiendo de la cantidad de carga que se tenga.

El sistema permitirá una conexión vía un Web services para la actualización de las BIAS para definir los permisos de los actores a los recursos asignaturas.

Los participantes internos tendrán soporte para sus flujos de trabajo, vía una sistema de Workflow que representa tales flujos. Falta dilucidar si un usuario dará permiso a otro (ejemplo recurrente del permiso que proporciona el profesor a los ayudantes) para administrar sus recursos, lo cual ya lo permite el MATCMS.

La topología del sistema será de 3 capas (recursos, aplicación, servidor Web), lo que facilitará su implantación en un servidor Web. Se ha considerado un servidor Windows con plataforma ASP con replicación de Base de Datos.

4.7.ASPECTOS DE CALIDAD DE SERVICIOS.

La arquitectura propuesta no restringe soluciones a problemas que puedan surgir con las propiedades sistémicas requeridas, tales como, rendimiento, confiabilidad, seguridad y disponibilidad.

Una clara estructura, la utilización de tecnologías abiertas, y el estar directamente basada en el negocio a ser apoyado, permiten abordar paramétricamente problemas de calidad de servicio. Algunas opciones disponibles serían aumentar el número de servidores Web, replicación selectiva del tipo de datos, uso de base de datos distribuidas lo cual mejora el rendimiento, y permite el reemplazo de componentes que correspondan a tecnologías que han progresado durante la construcción del sistema.

143

4.8.CONTRIBUCIONES CLAVES DE LA SOLUCIÓN PROPUESTA.

En la Memoria de Titulación presentada por los ahora ingenieros Álvaro Olivares y Carlos Gómez, en el punto 4.5.3 y con mayor detalle en los puntos 4.5.3.1 y 4.5.3.2, se mencionó que se podrían hacer mejoras del Motor de Bases de Datos, actualmente MYSQL está en la versión estable 5.0, en donde una de sus principales características es la mejora de las consultas, especialmente en el caché de éstas.

Con la solución propuesta, la utilización de ACL no recursivo, es decir, preprocesado, resuelve la consulta anidada con lo cual mejora el Rendimiento, en particular el tiempo de consulta en el servidor.

La “implementación pura”, del CMS de Matemática, utiliza la resolución de permisos de acceso, en base a la consulta recursiva del ACL, lo cual no es escalable, puesto que a mayor profundidad y mayor número de recursos hijos, la cantidad de consultas crece en forma logarítmica, dicho proceso fue optimizado utilizando cachés parciales de consultas, con la actual solución propuesta, considera un cambio arquitectural, debido a la utilización eficiente del preprocesamiento, se obtienen consultas con tiempo O(1), es decir, solo se requiere una consulta (conocida también como roundtrip) al ACL para otorgar o rechazar el acceso al Recurso.

A modo de ejemplo se puede tener, 10 niveles internos y se quiere solicitar un directorio como un listado de asignatura, se deben realizar al menos 10*2 consultas (una por el usuario y otra por el grupo, y así por el número de niveles) desde el nivel inferior hacia el superior (doun-up) y una por cada hijo, es decir sobre 100 consultas sin optimización. Para visualizar el ejemplo antes mencionado, se puede visualizar en la siguiente figura:

144

o root Sitio

Inicioo Docencia

Asignaturas Actuales Algebra …… Sistemas de Computación DAA Sistemas Operativos …. Programación

o T1 Novedades Archivos Avisos Notas

o T2o L1o ….o Laboratorio N

Figura 68: Ejemplo de cómo se estructura CMS de Matemática.

En la figura anterior, cuando se hacía la consulta a la asignatura de Programación, en primer lugar se busca que nuevos hijos tiene, por ejemplo, Novedades, y esto provocaba una disminución considerable en el desempeño del Servidor; La solución al problema anterior fue el caché de consulta y con la nueva arquitectura planteada es la optimización del ACL.

Una ventaja cuantitativa y cualitativa del modelo, es la utilización del GUID195 o de un SID196 frecuentemente utilizado por Microsoft.

En la Memoria de Titulación utilizada como referencia, no está explicito el concepto de reutilización de contenidos, pese a que se manejaba el linkeo de recursos, es decir, que un recurso apunte a otro, y con ello se obtiene posteriormente la reutilización, a éste proceso se denominó Acceso Directo (3.4.3.14)

Dentro del contexto anterior cabe destacar, las guías gubernamentales197 a utilizar para el desarrollo del proyecto, ellas fueron propuestas por el Gobierno de Chile el año 2004.

195 Acrónimo de Globally Universally, Unique Identifier. Búsqueda sugerida en Google, “generate guid PHP”196 Acrónimo de Security Identifier.197 http://www.guiaWeb.gob.cl/recursos/documentos.htm

145

4.9.TECNOLOGÍA CLAVE A UTILIZAR

La Solución propuesta puede ser implementada haciendo uso de un conjunto de tecnologías.

Servidor de Aplicaciones Webo Internet (Web) [Acceso Público]o Balanceo de Carga [Confiabilidad]o Fail-Over [Confiabilidad]o Replicación [Recuperación, Eficiencia]

Base de Datos Relacionalo Replicación [Recuperación, Eficiencia]

Servicios Webo Integración con Sistemas Externos (CICULS)o Flexibilidad en Creación de Aplicaciones [Público]

Workflowo Flujo de Publicacióno Manejo de Contenidos Publicadoso Publicaciones Varias

Manejo de Contenidoso Proceso de Modificación de Recursos [Seguridad, Recuperación]o Control de Acceso a Contenidos [Seguridad]

4.10. RELEVANCIA DE LA SOLUCIÓN A LA ULS

La Solución propuesta apoyará tanto la labor de distribución del material de las asignaturas, además, será un mecanismo efectivo de comunicación de la empresa con el personal pero en particular con los servicios profesionales que pueda realizar el personal académico de la Casa de Estudio.

Para los alumnos, la solución propuesta es una manera efectiva de evitar visitar distintas páginas Web, para disponer de una copia del material electrónico.

La siguiente tabla, explica cómo las tecnologías propuestas satisfacen los requisitos de las perspectivas mencionadas inicialmente.

146

PERSPECTIVA REQUISITO TECNOLOGÍAPerspectiva del Usuario

Servicio de Mejor Calidad Acceso remoto, Disponibilidad de Servicio, Servicios Web, Integración de Datos.

Ampliación de Cobertura Geográfica y Horaria

Con Servidores de Aplicaciones Web, e interfaces Web, accesibles por sobre el 99% al año.

Publicaciones Varias Interfaces y acceso directo a los cursos, publicaciones académicos, mediante workflows.

Reducción de Costos Utilización efectiva del correo electrónico, disminución de los costos de fotocopiado.

Perspectiva Institucional

Eficiencia de los procesos Sistema único de controlador de contenido dinámico, además de la realización de workflow de procesos.

Integración de la Información Plataforma única de cobertura mundial, interfaces automáticas, bases de datos centralizadas o federadas.

Soporte a la Gestión Docente Bases relacionales multipropósitos.

Perspectiva Externa

Intercambio de Información. Web services, B2B198, Utilización de estándares gubernamentales en el diseño de la aplicación.

Trabajo Colaborativo Web services (CICULS con Unidades Básicas), B2B, aplicación de estándares.

Reducción de Tiempos y Autentificación

Web Services para la inscripción de las asignaturas.

Reducción de Costos y Beneficios Mutuos

Web Services y B2B.

Tabla 69: Requisitos y Tecnologías.

198 Acrónimo de Businnes to Businnes

147

La tabla anterior, es una visión de la posible solución en base a lo planteado anteriormente en los puntos precedentes, pero sin lugar a dudas en virtud de los plazos el determinar la solución más adecuada y conveniente, dependerá del soporte que proporcionen las Escuelas y el CICULS.

5. MARCO METODOLÓGICO

Ésta sección tratará lo concerniente a la descripción e las herramientas y enfoques a utilizar para dar solución al problema.

5.1.ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

El proceso de desarrollo de software ha sido tradicionalmente llevado a cabo como una sucesión de fases, en orden de abstracción decreciente:

Ingeniería de requisitos para comprender la organización. Análisis para comprender el problema específico. Diseño preliminar (o “lógico”) para elaborar una solución de alto nivel. Diseño detallado (o “físico”) para completar los detalles de la solución. Implementación para construir el software. Pruebas para verificar lo construido.

Las fases se suceden en secuencia, y cada una toma como entrada inicial el producto final de la fase anterior. Este modelo de cascada es relativamente fácil de imaginar y de administrar, pero su efectividad disminuye considerablemente en presencia de complejidad:

Complejidad del Dominio: el problema puede ser demasiado complejo para ser resuelto en una pasada “top-down”.

Especialización del equipo: una organización que desarrolla software utiliza eficientemente los especialistas (escasos) en varios proyectos a la vez, repartiendo el costo total entre ellos.

Tamaño del Equipo: un proceso que requiere un equipo grande de desarrollo.

Tamaño del Sistema: en la práctica, todo sistema suficientemente complejo no puede ser especificado en una pasada, dado que nuevos aspectos aparecen constantemente.

Variabilidad del Problema: en la práctica, todo sistema complejo está sujeto a cambios en su ambiente y en su gestión.

148

La creciente complejidad de los sistemas construidos ha llevado a la adopción de técnicas de programación (más recientemente) y de diseño “orientadas a objetos”, que conciben un sistema de software como la colaboración de piezas construidas usando mecanismos de reutilización textual199. Tradicionalmente, los métodos de objetos tienden a privilegiar los invariantes estructurales (reflejados en datos) por sobre los aspectos funcionales (reflejados en tareas). Esto ha provocado a un problema adicional:

Impedancia Conceptual: el paso de un análisis tradicionalmente funcional (por lo tanto, sin objetos) a un diseño/construcción con orientación a objetos conlleva a severos problemas de traducción, ya que un modelo privilegia tareas debe ser usado para “deducir” uno que privilegia datos.

5.2.PRINCIPIOS METODOLÓGICOS

Los métodos de análisis y diseño orientados a objetos que combinan el estudio funcional del problema (adecuado para modelar funciones de negocios y comunicarse con usuarios), el modelado de datos (que privilegia los invariantes organizacionales de información), la descripción de software en términos orientados a objetos, el control de riesgos durante el proceso, y el control de complejidad del dominio, del sistema y del equipo. Es por ello que:

Iteración: Los métodos exigen iterar, separando el proceso global en etapas menores; los resultados intermedios permiten evaluar lo hecho y corregir el rumbo si fuese necesario.

Refinamiento Sucesivo: Los modelos iniciales del problema y de la solución son de alto nivel, pero cubren todo el ámbito del proyecto; sucesivas etapas van refinando áreas específicas, hasta lograr un nivel de detalle suficiente (no necesariamente exhaustivo; sólo se pretende guiar la construcción).

Trabajo en Equipos: Los sistemas modernos, en general, requieren la participación de una colección de especialistas, que a su vez trabajan en varios proyectos; por lo tanto, las dependencias entre ellos (debidas a resultados intermedios) son explícitamente abordados.

Orientación a Objetos: La mayoría de los sistemas que resultan de un análisis y diseño Orientado a Objetos son también construidos con tecnologías Orientados a Objetos; aunque no siempre es el caso, los métodos están particularmente adaptados para tal transición.

Visiones Parciales: Para controlar la complejidad, los modelos de análisis y de diseño son descritos en notaciones que permiten identificar y describir segmentos que derivan de un punto de vista específico, sea por naturaleza (ejemplo, estático versus dinámico) o por función (ejemplo, análisis versus diseño).

199 Objetos, Herencias y Tipos de Recursos en este caso.

149

5.3.MÉTODOS MODERNOS DE DESARROLLO.

A fines del siglo pasado, existía gran diversidad de métodos para desarrollo de software que invocaban los principios antes mencionados, para ello es propicio ver el apéndice de Métodos de Desarrollo de la Presente Memoria de Titulación. Como conclusión de ello se utilizará como método de desarrollo RUP, el cual será tratado en el siguiente punto.

5.4.RATIONAL UNIFIED PROCESS (RUP)

No cabe lugar a dudas la relevancia de éste método, pero su utilización se debe a sus características y principios, que lo han llegado a posesionar como el más utilizado en la empresa y en la academia como método de desarrollo.

5.4.1. CARACTERÍSTICAS Y PRINCIPIOS

Algunas de las características que lo distinguen de los métodos tradicionales son :

Es Iterativo e Incremental, ya que sus resultados son plasmados en modelos, y los modelos son refinados progresivamente a lo largo del proyecto; cada iteración (re)elabora uno o más modelos, y al final de cada iteración se valida lo alcanzado.

Organiza el Trabajo como Actividades Concurrentes, debido a que el trabajo consiste de especialistas complementarios, que consideran aspectos diferentes del mismo problema o sistema; por lo tanto, no es útil imponer un orden de trabajo artificial.

Está Centrado en la Arquitectura, uno de los primeros resultados es una arquitectura preliminar, que determina la factibilidad de continuar con la construcción del sistema; esta arquitectura es considerada la pieza clave de la descripción de la solución, por ser una descripción de alto nivel que evita detalles operativos pero permite evaluar opciones de tecnología y construcción.

Enfatiza el Modelado Visual, una utilización efectiva de RUP normalmente se asocia con técnicas de modelado visual, cuya productividad se ve reforzada por la densidad semántica de diagramas y por las posibilidades de validación por expertos del dominio.

Define Vistas Alternativas y Complementarias, tanto el proceso mismo como sus productos (especialmente la arquitectura) son descritos y manipulados mediante las vistas parciales: un modelo de software tiene aspectos dinámicos, estáticos y de estado, y el RUP mismo ofrece un conjunto de vistas organizadas por especialistas (llamado el 4+1).

5.4.2. DESCRIPCIÓN DINÁMICA: FASES E ITERACIONES

Como se indica en el apéndice RUP define 4 fases, cada una de las cuales tiene un propósito específico, implica ciertas decisiones críticas, y termina en un hito.

150

Fase Inicial (Objetivos del Proyecto): Identifica el ámbito del proyecto, los participantes (actores), las interacciones claves (casos de uso), y los objetivos del proyecto, considerando criterios de éxito, estimación y control de riesgos, plan de trabajo preliminar, y estimación de recursos.

Elaboración (Arquitectura del Sistema): Analiza el dominio del problema, determina una arquitectura preliminar, planifica el resto del proyecto en mayor detalle, y determina qué elementos son los más riesgosos. Una estrategia de minimización de riesgo sugiere abordar tales elementos inicialmente, para detectar cuanto antes los efectos que puedan causar. El resultado de esta fase es suficientemente detallado para determinar si se procede a la fase siguiente, y para ejecutarla si es el caso.

Construcción (Sistema incrementalmente Operacional): Construye los artefactos o componentes de software especificados, usando las dependencias determinadas en los modelos de la arquitectura; el análisis de dependencias entre componentes es el punto de partida para la planificación del desarrollo. Resultados intermedios pueden y deben ser verificados y validados a medida que son productivos.

Transición (Sistema Entregado): El sistema se pone en operación y se inserta en su contexto operacional, con la modalidades que sea del caso (ejemplo, operación en paralelo)

5.4.3. DESCRIPCIÓN ESTÁTICA: ACTIVIDADES Y ARTEFACTOS

RUP propone 9 actividades, 6 de ellas directamente relacionadas al desarrollo y otras 3 con actividades de apoyo. Estas actividades no son etapas del proyecto, sino tipos de tareas especializadas, y en general se repiten iterativamente a lo largo del proyecto. Las actividades son:

Modelado del Negocio, en donde se describe la organización, en términos de procesos de negocios. Esta etapa examina el ámbito y el valor relativo del proyecto, y permite identificar posibles situaciones de riesgo externo.

Requisitos, se describen las metas y restricciones del proyecto, y elaboración de una visión. Las funciones del negocio se describen con casos de uso, identificando que hará el sistema.

Análisis y Diseño, en esta actividad se realiza un estudio detallado del dominio y problema a resolver. La solución se describe en una arquitectura del sistema.

Implementación, se construye el sistema especificado en la arquitectura. Puede considerar una aceptación más formal.

Pruebas, se verifica y valida el sistema, desde componentes unitarios agregados (subsistemas). La validación de más alto nivel se basa directamente en los casos de uso identificados en la actividad de requisitos.

Despliegue, empaquetamiento, entrega e instalación del sistema, o partes de él, en la medida que sean liberados.

151

Administración del Proyecto, la planificación y ejecución de las actividades a realizar durante el proyecto, así como las consecuentes tareas de asignar recursos y controlar el proceso. Una parte importante de esta actividad es la determinación de riesgos y evaluación de alternativas.

Control de Cambios y Configuración, en donde el control de los artefactos (software, modelos, documentos) que son producidos durante el proyecto. Esta tarea es fundamental debido a la naturaleza iterativa del RUP (que genera nuevas versiones con cada iteración) y al uso de las vistas complementarias para describir modelos (lo cual genera problemas de integridad).

Ambiente de Desarrollo, la actividad que provee y administra los procesos, técnicas y herramientas que el equipo de desarrollo emplea. Esta actividad es priorizada en versiones comerciales de RUP, donde proveedores de métodos entregan recursos de entrenamiento, plantillas de contenidos, etc. En el caso de esta propuesta más se orienta a la metodología.

5.5.APOYO METODOLÓGICO

Como apoyo metodológico y debido a los problemas de financiamiento, se propone la utilización de la herramienta Enterprise Architect y ArgoUML, para la generación de modelos.

ArgoUML será utilizado para generar modelos en UML (casos de uso y algunos modelos de arquitectura)

Ciertos modelos (por ejemplo, roles, estándares gráficos, patrones de entendimiento) no son bien representados en UML, por lo cual se utilizará OpenOfficce y otros que tienen licencia libre.

6. PLAN DE TRABAJO

Para efectos de aplicar un enfoque metodológico del Proceso de Desarrollo Racional Unificado, se adaptarán las dos primeras fases de éste al proyecto.

6.1.FASE INICIAL

Esta fase de breve duración considera:

La toma de razón oficial del proyecto por parte del equipo de desarrollo, haciendo las presentaciones de las respectivas contrapartes.

La recopilación de todos los antecedentes por los cuales es proyecto se debe regir, tales como, las normas y estándares de desarrollo de sistemas.

Se presentará el enfoque metodológico a utilizar, con el objetivo de aunar criterios respecto a la terminología, las etapas del ciclo de vida de este proyecto, y los entregables.

152

Se revisarán, en conjunto con las contrapartes, en este caso La Universidad de La Serena, documentos preliminares que entregan antecedentes respecto al ámbito del proyecto (tipos de recursos), usuarios, sistemas relacionados de modo que el equipo de proyecto adquiera comprensión del tema de modo de definir líneas de acción más detalladas.

Elaboración de un plan preliminar de reuniones de trabajo. En la medida que se avance en el conocimiento de todos las funciones y, actores en ámbito del proyecto se tendrán que programar nuevas reuniones.

Revisión de la Carta Gantt para afinar tareas y actividades.

6.2.FASE DE ELABORACIÓN

Esta fase tiene por finalidad diseñar todos los aspectos de la solución final del problema, generando los respectivos documentos definidos en el punto de Entregables.

6.2.1. LEVANTAMIENTO Y ANÁLISIS DE REQUERIMIENTOS

Como se indicó en el marco metodológico a utilizar, el proceso de análisis y diseño será iterativo y paulatino, en donde cada ciclo se irá profundizando en detalles que conlleven a la solución final. No obstante, desde el punto de vista metodológico interesa contar a la brevedad con un visión global de todos los requerimientos para efectos de examinar alternativas y proponer una Arquitectura inicial de solución. Para estos efectos se consideró como punto inicial la arquitectura propuesta del CMS ya que utiliza el Departamento de Matemáticas y de allí iniciar a incorporar a las distintas unidades básicas.

6.2.2. DISEÑO DE LA SOLUCIÓN

6.2.2.1. DISEÑO PRELIMINAR: DISEÑO CONCEPTUAL Y ARQUITECTÓNICO

Como producto de este análisis y producto más representativo de los procesos de publicación, se generó un Diseño Conceptual y modelo Arquitectural preliminar. Dichos modelos, contextualizan en términos estructurales una solución al problema. El diseño conceptual y arquitectónico contempla los aspectos esenciales de la solución propuesta tanto en lo relativo a funciones y procesos del negocio a soportar, como también la solución tecnológica que se elija.

6.2.2.2. DISEÑO DETALLADO, DISEÑO FÍSICO

Los detalles del modelo físico se refinan a medida que se analiza en detalle las necesidades de todos los involucrados (procesos, actores, sistemas, etc.) y se resuelve qué opciones tomar en cada caso (facilidad, tecnología, etc.).

153

6.2.3. REVISIONES Y ENTREGABLES

Se ha planteado como estrategia para asegurar la calidad del desarrollo (tanto en lo relativo a la completitud de la solución, como el cumplimiento de metas y plazos) revisiones periódicas, las que se harán considerando los entregables definidos en el punto de Entregables de la presente propuesta.

Cabe destacar que durante la Fase de Elaboración se deben considerar 2 instancias de entrega de resultados (entregas parciales).

6.2.4. PLANIFICACIÓN FASE II

Una vez que todos los elementos de diseño estén completamente detallados, se procederá a la planificación de la Fase II del Proyecto. Esto tendrá por finalidad generar todos los documentos para posteriormente poder construir e implementar el sistema.

6.2.5. FASE DE TÉRMINO

Presentar el sistema a todas las Unidades Básicas de la Universidad de La Serena.

6.3.CARTA GANTT

La Carta Gantt se puede apreciar al final de éste capítulo.

6.4.ESTRATEGIA A UTILIZAR PARA EL CONTROL Y SEGUIMIENTO DEL PROYECTO

Ya que el plan de trabajo, es un desarrollo del proyecto en espiral, se propone realizar un control y seguimiento para asegurar la calidad basado en las siguientes premisas:

Control periódico al interior del equipo de trabajo, en una modalidad de “brain storming”, que permita establecer una suerte de validación preliminar.

Proceso iterativo de una prueba de estrés del resultado parcial, con la activa participación de los usuarios, con el objetivo de revisar el grado de cumplimiento de los requerimientos establecidos desde la etapa de análisis.

Validación mediante la utilización de un prototipo a nivel de interfaz usuaria (sin funcionalidad) en torno a determinar la completitud de la información que esté siendo considerada.

Control de avance del proyecto, a través del gerenciamiento realizado por un profesional no incluido en las tareas diarias propias del desarrollo del proyecto. El control de avance se debe realizar en reuniones en la cual se encuentre el arquitecto del proyecto, jefe de éste y un representante de la Universidad de La Serena.

154

Lo anterior, deberá quedar respaldado a través del uso de minutas que describan las reuniones que se hayan realizado y los compromisos adquiridos. Esto último no solo en el contexto de las reuniones de avance, sino que durante el proceso de análisis y revelamiento donde pueda existir compromisos tanto a nivel de usuario como de la contraparte técnica. En este mismo sentido deberán establecerse acuerdos en relación a los tiempos de espera por los diferentes compromisos, en particular aquellos que impliquen la aceptación y/o aprobación de alguna proposición o solución intermedia.

7. ORGANIZACIÓN

7.1.EQUIPO DEL PROYECTO

El equipo de desarrollo deberá estar constituido por al menos 10 personas, con la característica que se detallan en la siguiente tabla.

Recursos de Consultoría Técnico

Funcional

Nombre Dedicación Estado Actual

Arquitecto del Proyecto Gustavo Gatica G. Jornada Completa Académico ULS.Jefe de Proyecto Gustavo Gatica G. Jornada Completa Académico ULS.Analista e Integrador Samuel López M. Jornada Completa Alumno ULS, Ing.

en Comp.Documentadota Paulina Valenzuela S. Jornada Completa Alumno ULS, Ing.

en Comp.Diseñador de Interfaz Gonzalo Silva Jornada Parcial Alumno ULS,

Diseño.Desarrolladores Samuel López M.

Esteban Toledo P.José Sepúlveda Ri.Rodrigo Adones V.Fernando Varas C.Roberto Barquín F.

Jornada Completa Alumnos ULS, Ingeniería en Computación.

Tabla 70: Equipo de Desarrollo.

La funcionalidad de cada recurso técnico funcional, se puede apreciar en la siguiente tabla.

155

Arquitecto del Proyecto

Está familiarizado con los detalles técnicos, será el encargado de materializar lo recopilado por los analistas en los entregables, haciendo uso del marco metodológico indicado.

Jefe de Proyecto. Liderar el equipo del proyecto.Administrar el proyecto, planificar, conseguir y distribuir recursos y evaluar riesgos.Junto a los Ingenieros Analista, estará encargado de realizar todas las labores de relevamiento y análisis.

Analistas Junto con el jefe de proyecto, estarán encargados de realizar todas las labores de relevamiento y análisis, generando una descripción detallada del problema.

Documentadora Encargada de llevar a los documentos finales, los entregables elaborados por el arquitecto, haciendo uso de herramientas para estos efectos.

Tabla 71: Funcionalidad por Rol.

7.2.EXPERIENCIA DEL EQUIPO

La experiencia del equipo propuesto, es limitada, pero una fortaleza de ello es la identificación de los integrantes del equipo con la Casa de Estudio.

7.3.COSTOS DEL PROYECTO

Según la planificación el proyecto de ser aprobado durante el mes de marzo, se iniciaría el 01 de abril, con una duración aproximada de 5 meses, es costo total asciende los 22 millones de pesos, los gastos se desglozan en la siguiente tabla.

ROL Mensual Nº Meses TotalArquitecto y Jefe de Proyecto

900.000 5 4.500.000

Analista e Integrador

600.000 5 3.000.000

Desarrollador 400.000 5* 5 10.000.000Documentador 250.000 5 2.500.000Diseñador 100.000 4 400.000Imprevistos, Personal Extra

1.600.000

Total 22.000.000

Tabla 72: Costos Proyecto.

156

8. ENTREGABLES

Durante el proyecto, la comprensión gradual del problema y especificación de la solución seá plasmada en documentos y modelos.

8.1.TIPOS DE ENTREGABLES

El método propuesto genera los siguientes tipos de entregables:

Una descripción del problema a ser resuelto con la construcción del sistema, en suficiente detalle para ser validado por los clientes y usuarios, y así guiar el trabajo del arquitecto: modelo de análisis y modelos de seguridad.

La arquitectura del sistema a ser construido durante la Fase II, en suficiente detalle para guiar el trabajo del equipo correspondiente: modelos: diseño, servicios, componentes, conexiones, despliegue y otros.

Los casos de prueba a ser usados para verificar y validar que el sistema construido se ajusta a la especificación.

La especificación de la plataforma y equipo de construcción que debe estar disponible para poder ejecutar la Fase II.

La especificación de la plataforma de explotación que será requerida para poder poner el sistema en producción.

Los manuales de uso y de operación del sistema (versiones iniciales serán utilizadas para validar los requisitos con los usuarios y para guiar la construcción)

Algunos prototipos para validar y/o demostrar aspectos claves de la funcionalidad y/o tecnología.

Estos tipos de entregables son descritos en mayor detalle en el resto de la sección.

8.1.1. DESCRIPCIÓN DEL PROBLEMA

En esta parte del sistema se debe dar solución a los modelos de análisis, es decir, los procesos, mediante:

Modelo de workflow de procesos de negocio. Diagramas de workflow. Casos de uso para procesos en ámbito. Escenarios normales. Escenarios alternativos (anormales). Diagramas de casos de uso, de secuencia, de colaboración. Modelo del Dominio. Actores. Roles.

157

8.1.2. ARQUITECTURA DEL SISTEMA

En primer lugar los modelos de diseño, es decir, las aplicaciones en sí, consideran:

Modelos estáticos: Objetos, clases, tipos, métodos, entre otros. Diagrama de Clases. Paquetes (packates). Modelo Dinámico. Diagramas de frecuencia, de colaboración, de estados. Modelo de Componentes. Subsitemas.

Se indican los Servicios (usados por otros componentes): interfaz, secuencias válidas (protocolos).

Autentificación. Traza (log). Transacción. Traducciones de formato/escritura. (Otros servicios identificados en la Fase I)

Si compete a la solución del problema, componentes comerciales requeridos.

Bibliotecas de estructuras de datos. Componentes gráficos. Componentes de comunicación. (Otros componentes identificados en la Fase I)

El modelo de despliegue (deployment), debe considerar.

Componentes ejecutables (programas). Componentes integrables (bibliotecas, DLLs). Procesos (en la máquina): escalonamiento, recursos, privilegios.

Modelos de Conexiones entre aplicaciones.

Medio (papel, inalámbrico, OCR, entre otros). Protocolos y transporte (HTTP, HTTPS, SOAP) Modelos de control: push o pull, con o sin sesión, etc. Frecuencia de conexión.

Modelo de Datos.

Modelo lógico: entidad-relación. Modelo Físico: tablas, patrones de acceso, volúmenes.

158

Modelo de Seguridad.

Roles (individuales y grupos) Recursos (individuales, jerárquicos y grupos) Derechos de cada rol sobre cada recurso. Mapeo de roles/recursos al modelo de aplicaciones y al modelo de datos.

8.1.3. CASOS DE PRUEBA

Los casos de prueba pueden muchas veces derivarse de los casos de uso, por lo que se propone entregar conjuntamente versiones iniciales de ambos tipos de casos.

Casos de prueba funcionales, considerando para caso de uso:o Escenario Normal.o Escenarios Alternativos.

Casos de pruebas sistémicos, para cada área no-funcional, considerando resultados esperados, entre otros:

o Disponibilidad, tasa MTBF200, acceso horario crítico.o Rendimiento, volumen de transacciones por segundo, media,

mediana, peor caso.o Latencia, tiempo de espera promedio, mediana, peor caso.

8.1.4. PLATAFORMA Y EQUIPO DE CONSTRUCCIÓN.

Se considera el ambiente de trabajo para la Fase II.

Lenguaje(s) y ambientes de programación (IDEs), en este caso el lenguaje de scripting será ASP y .NET.

Herramientas adicionales (control de configuración y versiones, seguimiento de reportes de fallas, “test harness”)

Requisitos para el ambiente de prueba (a diferencia del ambiente de explotación)

También se considera el proceso de desarrollo para la Fase II (plan detallado)

Actividades y dependencias. Entregables. Mecanismos de control de calidad.

En último lugar, es apropiado definir el equipo de desarrollo para la Fase II, en donde se analiza en mayor detalle el perfil de los miembros del equipo, considerando la solución propuesta y el proceso sugerido.

200 Acrónimo de Mean Time Between Failures, Tiempo medio entre fallas.

159

8.1.5. PLATAFORMA DE EXPLOTACIÓN

En particular esta etapa considera la configuración de los servidores.

La configuración de los servidores de aplicaciones, de Web, y de base de datos, considerando:

Configuración de replicación. Esquema de fail-over (para recuperación dinámica de fallas) Esquema de respaldo (para recuperación de fallas catastróficas) Red (si corresponde definir una subred)

También, corresponde definir los criterios para seleccionar productos específicos, por ejemplo cuando se especifica un tipo de producto específico, se debe indicar requisitos mínimos operacionales, de conexión, de protocolos, etc.

En caso de existir una migración y poblado de datos, se deben entregar las especificaciones correspondientes.

8.1.6. MANUALES DE USO Y OPERACIÓN DEL SISTEMA

Cada iteración del proyecto debe generar versiones de algunos manuales; las versiones iniciales pueden ser utilizadas para validar requisitos con usuario y para guiar la construcción.

Los manuales de uso y operación se pueden clasificar en:

Un manual de uso para cada rol/actor. Manual de operación. Manual de configuración del Servidor.

8.1.7. PROTOTIPOS

El propósito de un prototipo es minimizar algún riesgo, y dado que constituyen un esfuerzo inicial cuyo resultado debe descartarse201, por lo general su utilización se restringe a permitir una evaluación de algún riesgo específico, sea funcional o tecnológico.

8.1.7.1. PROTOTIPOS FUNCIONALES

Se utilizan para validar algunos requisitos funcionales (tareas) que sean considerados problemáticos o de difícil validación. A modo de ejemplo, se pueden señalar:

201 Según Hernán Astudillo, no existe peor error que tratar de convertir un prototipo en una parte del sistema; los criterios que hacen un prototipo valioso (rapidez de construcción y simplificaciones internas) lo hacen un pésimo inicio para el desarrollo de un componente robusto y estable.

160

Diseño inicial de experiencia de acceso al portal de los alumnos de la ULS. Cambio dinámico de derechos de acceso a recursos (control de seguridad).

8.1.7.2. PROTOTIPOS TECNOLÓGICOS

Para demostrar la facilidad de alguna opción tecnológica cuya validación sería muy difícil o bien sería imposible de cambiar después de haber avanzado el proyecto, a modo de ejemplo se puede indicar:

Mecanismo de generación automática de una asignatura. Propagación en tiempo real de cambios a los derechos de acceso.

8.1.8. ENTREGABLES PARA CADA ETAPA DE LA FASE I

La tabla siguiente indica que entregables pueden ser liberados durante el desarrollo de la Fase I, y se agrupan en las categorías mencionadas anteriormente, es decir, Descripción del Problema, Arquitectura del Sistema, Casos de Prueba, Plataformas, etc.

161

Fase de Rup Fase Inicial

Fase de Elaboración

Versión Entregable 1 2 3 FinalDescripción del Sistema

Modelo de Análisis X X X XDescripción del Sistema

Modelo de Aplicaciones

X X X

Servicios X X XComponentes X X XModelo de Despliegue

X X X

Conexiones X X XModelo de Datos X X X XModelo de Seguridad X X X X

Casos de PruebasCasos de Pruebas Funcionales

X X

Casos de Pruebas Sistémicos

X X

Plataforma y Equipo de Construcción

Ambiente de Trabajo XProceso de Desarrollo Fase II

X

Equipo para Fase II XPlataforma de Explotación

Configuración de los Servidores

X X

Criterios para Productos

X X

Manuales de Uso y Operación del Sistema

Manuales X X XPrototipos

Prototipos Funcionales

X X X

Prototipos Tecnológicos

X X

Tabla 73: Entregables en cada etapa de la Fase I.

9. GARANTÍA TÉCNICA DE SOPORTE Y CAPACITACIÓN

162

La garantía técnica que se proporcionará, será de soporte y proporcionando las facilidades del caso para responder dudas metodológicas o de concepto a la entidad que se le adjudique la etapa de Construcción e Implantación del Sistema. Sin prejuicio de ello, el equipo se puede reservar el derecho de cuestionar la calidad de la consulta o solicitud de soporte si se determina que existe una falta de conocimiento de la tecnología y/o arquitectura definida para desarrollar la solución definida.

Se deben considerar al menos 3 factores:

Un periodo de cinco días hábiles para la transferencia de información, es decir, explicación de la solución definida como resultado del análisis y diseño, en base a los entregables.

Durante los primeros tres meses de construcción e Implantación, será mediante la presencia de un profesional en las dependencias de la ULS, equivalente a 20 horas semanales, mediante prestación de servicios, en escalafón A-15, es decir, aproximadamente, 14.000 pesos hora mes.

Durante los siguientes tres meses, será a través de soporte telefónico, vía email o SFTP202; si es necesario un miembro del personal puede asistir para asesorar, pero con costo adicional.

202 Secure FTP Server.

163

Aca va la carta gantt

164

Capitulo 1: Conclusiones

En la actualidad y gracias al alto nivel desarrollo de las telecomunicaciones y de las redes computacionales, se ha llegado a un punto en el cual se tiene la facilidad de que los sistemas de software requieran de información online en cada uno de sus puntos o peers, además que deben facilitar la integración con otros sistemas; ello ha provocado que en el ámbito del software, las aplicaciones computacionales sean mucho más flexibles, administrables, multiplataformas, más seguras, reutilizables, evolutivas, y de fácil análisis para futuras modificaciones y crecimiento.

Lo mencionado anteriormente, requiere que se disponga de nuevos enfoques para desarrollar software, de tal forma que los sistemas resultantes cumplan con los requisitos antes mencionados.

El estudio realizado en la presente Memoria de Titulación, permite determinar que el enfoque de Arquitecturas de Software, basado en Patrones, proporciona un conjunto de herramientas y metodologías que permiten construir sistemas que satisfacen los requerimientos anteriores. Esto se debe a que un modelo de una Arquitectura de Software, está constituido por un conjunto de módulos que interactúan entre ellos, que el sistema completo dispone de interfaces para comunicarse con otros sistemas (Webservices), la planificación y distribución de las tareas requeridas, el aprendizaje de los distintos stakeholders, la capacitación de los usuarios, la generación de una documentación comprensible y adecuada a cada rol (vistas), y la función que ha de cumplir el Arquitecto del Software, en el desarrollo de los modelos en distintos niveles de abstracción y ser el garante de éste proceso. Es común confundir, Vista Arquitectura con Arquitectura, donde se debe tener claro que la vista es una “foto parcial” que está orientada a cada rol del sistema, mientras que la Arquitectura, es un modelo sistémico y la planificación del problema.

En este contexto, se hizo un estudio conceptual de las Arquitecturas de Software y de los Patrones, considerando su desarrollo histórico, las definiciones formales, los Lenguajes de Descripción de Arquitectura, los Estilos Arquitecturales, Los Modelos y Vistas, las tendencias Europeas, los aspectos críticos que debe considerarse al desarrollar un modelo Arquitectural, la función del Arquitecto, y las decisiones que se deben tomar para aplicar patrones a una problemática, la decisión puede ser rutinaria, pero ella ya tiene un nombre específico y ha sido identificada y documentada por la Comunidad de Desarrolladores de Software.

Todo sistema tiene una Arquitectura, esto no significa que alguien la conozca, ya que es posible que no cumpla con un patrón o estándar arquitectural. Esto da a conocer la diferencia existente entre la arquitectura de un sistema y su descripción o especificación.

166

El comportamiento de cada componente, es parte de la Arquitectura, ya que es observable o deducible desde el exterior, por lo tanto, la mayoría de los diagramas de líneas y cajas negras, no describen una Arquitectura, puede definir solo su comportamiento.

No cabe lugar a dudas que dentro de la comunidad de software, existe un gran interés en el diseño de alto nivel.

El aumento de la importancia del software en los sistemas está conduciendo el renacimiento de la Arquitectura del Software como foco de estudio. Los problemas de no disponer de una clara y eficiente Arquitectura de Software contribuye a grandes dificultades en cualquier proyecto de software. Esto se debe a que las decisiones arquitectónicas se toman generalmente tempranamente en el ciclo de vida, y, por ende, son las más difíciles de modificar, y por lo tanto las más críticas y de gran envergadura.

Sin una buena arquitectura del sistema, es difícil alcanzar la satisfacción del funcionamiento basándose en los requisitos del comportamiento y es probablemente imposible realizar cambios importantes en el diseño.

La Arquitectura de Software, también proporciona el contexto crítico para la alta reutilización tanto en el diseño y como en los componentes, ya que un razonamiento arquitectónico, es un argumento sobre las cuestiones estructurales de un sistema. Pero aún se requieren modelos más precisos, que permitan razonar sobre las propiedades de una arquitectura y verificar su consistencia y completitud, así como la automatización del proceso de análisis, diseño, y síntesis.

La importancia del contexto arquitectónico para la reutilización se deriva de observar las prácticas comunes en campos maduros de la ingeniería, tales como la Ingeniería Civil o Química. Dentro de la Ingeniería de Software, las prácticas y las soluciones comunes dentro de áreas de aplicación particulares se pueden reutilizar para proporcionar las ventajas en el dominio de las decisiones del alto nivel arquitectónico; y a su vez, a medida que pasa el tiempo, la Arquitectura de Software tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la Ingeniería de Software, sólo que a un mayor nivel de abstracción, agregando una nueva dimensión reflexiva en lo que concierne al proceso

La revisión de una Arquitectura de Software es un problema complejo, ya que no se tienen medidas para muchos de sus atributos; por ejemplo, el rendimiento es cuantificable, pero la integridad conceptual es altamente subjetiva, y es por ello que la Arquitectura de Software es muy difícil de evaluar, ya que no se dispone de referencias claras. El propósito final de revisar la Arquitectura es descubrir riesgos para la planificación y presupuesto. Así como también el detectar cualquier falla o defecto en el diseño de ésta, pese a que son muy difíciles de corregir.

167

Cabe destacar la diferencia sustancial entre el Ingeniero de Software y el Arquitecto de Software. El primero especifica un sistema, en cambio la función del segundo es de un nivel de abstracción superior, ya que, es el garante de la concepción, desarrollo, y evolución de un sistema, ya sea realizando cambios internos, de presentación de la información, como la adaptación del sistema a nuevas solicitudes y a nuevos ambientes.

En el punto 3.3 del Caso de Estudio, se puede observar que se utilizan en forma explícita los patrones, MVC, IOC, Intercepting Filter, entre otros. Cabe destacar, que se confunde en su utilización los patrones Chain of Responsability con Intercepting Filter. Estos patrones resultaron fundamentales en el momento de asignar la responsabilidad de solicitar un Recurso.

Del Caso de Estudio, se concluye que dentro de la descripción de una solución, la clara definición de: el propósito del sistema, de los diversos modelos de alto nivel, de las definiciones, reglas, y procesos de negocios, son fundamentales para la elaboración de un Marco Metodológico acorde a lo anteriormente expuesto. Gracias ello, se pueden confeccionar los compromisos a los cuales ambas partes (cliente- grupo de desarrollo) se comprometen a resolver y además, las decisiones de diseño tienen un nombre, es decir, que las soluciones y decisiones, ya han sido estudiadas, clasificadas y documentadas por miembros de la Comunidad de Desarrollo del Software, facilitando su utilización, en base a la tecnología disponible.

Del Caso de Estudio, se desprenden algunas líneas de investigación, tales como, LMS, la definición de una Estructura de Base de Datos Federada para el modelo planteado, y la definición de un eficaz roundtrip para la consulta a las Bases de Datos.

Así como nacen nuevas tecnologías, también lo hacen las metodologías de desarrollo, cada una de ellas busca su propio nicho de mercado y sus seguidores, es así como a medida que avanza el tiempo, cada metodología se complementa con otras. Del estudio de los Métodos de Desarrollo, se concluye que la mejor metodología nunca arribará, debido a que cada una de ellas tiene deficiencias o son demasiados rigurosas; es por ello que el conocer cada una de estas, permite a los equipos de desarrollo buscar las mejores cualidades de cada método para poderlas aplicar al desarrollo de sistemas en un momento dado y bajo circunstancias específicas.

168

Cabe destacar, la propuesta de Coplien en la cual se propone la necesidad que los equipos de desarrollo pero en particular el Arquitecto, tengan basto conocimiento de marketing, terapias ocupacionales y motivacionales, tolerancia, y buen manejo de equipo, lo anterior permite que los grupos de desarrollo trabajen motivados, mediante incentivos proporcionales al trabajo realizado, permitiendo que el producto final tenga grandes cualidades, y sea de alta calidad ya que se sienten comprometidos como equipo y empresa, es por ello que en el caso de Estudio, el personal propuesto son integrantes de Nuestra Casa de Estudio, lo cual implica un compromiso mutuo y satisfactorio, hacia y con la Institución. Estos patrones son convenientes para la construcción y la evolución de la Organización, porque se describen como la actividad dentro de ella, y proporcionan una perspectiva de patrón, al análisis de la Organización, debido a que todos los estudios hacen referencia al Control de ésta.

De todo lo expuesto en esta sección, queda claro que la Arquitectura de Software, es un área fundamental de desarrollo de sistemas, ya que dispone de elementos o conceptos propios, líneas de acción claramente establecidas, procedimientos para la confección de la documentación, y herramientas para facilitar la elaboración de un modelo arquitectural. Entre las herramientas, se destacan los diversos tipos de patrones, las líneas de producto, las refactorizaciones, la ingeniería inversa, la interoperabilidad (Webservices) y el aprendizaje.

Todo lo anteriormente expuesto en la presente Memoria de Titulación, motiva a un estudio de mayor profundidad, en diversas áreas, algunas de las cuales por motivo de espacio no pudieron ser tratadas, entre estas líneas de investigación futura, se encuentran: La generación de un modelo Arquitectural mediante COTS, la aplicación de métodos ágiles de desarrollo ya sea como caso práctico o mediante un caso de estudio, y la inserción de un programa de Arquitectura de Software en el currículum del Ingeniero de Computación.

169

apéndices Memoria de Titulación

170

informe tesis

Documents