Arquitectura orientada a servicios para el módulo de inventario del ERP cubano. 1

En el presente trabajo se expone una propuesta de Arquitectura Orientada a Servicios para el Módulo de Inventario del ERP Cubano, de modo que le posibilite al mismo ser: portable, seguro, escalable e integrable con otros sistemas y que a la vez sea extensible a otros módulos del ERP.

Para lograr el objetivo propuesto de definir y describir la arquitectura de software se partió de un estudio de los elementos que constituyen la misma y las tendencias actuales según los autores más prestigiosos del tema, así como la experiencia del desarrollo del Sistema de Gestión de Inventarios y Almacenes (SIGIA).

El éxito de la definición y descripción de la arquitectura estará en dependencia principalmente de las decisiones arquitectónicas que se tomen durante su desarrollo, la tecnología más adecuada que se decida y aspectos del diseño que permitan un desarrollo favorable del propio sistema, donde se tengan en cuenta las relaciones y configuraciones entre los componentes y que permita organizar la estructura del sistema que se desarrolla brindando a todo el equipo de trabajo una idea clara de lo que se esta desarrollando.

INTRODUCCIÓN

Con la desaparición del socialismo en la Unión de Repúblicas Socialistas Soviéticas y el recrudecimiento del bloqueo de Estados Unidos hacia Cuba en la década de 1990, la economía cubana quedó paralizada.

Debido a esto el país se vio en la necesidad de realizar un proceso de rediseño de la política económica. Desde entonces se comenzó a llevar a cabo un programa gradual de medidas económicas que tenían como objetivo superar la situación de la nación al menor costo social posible.

A raíz de las dificultades económicas a las que se estaba enfrentando el país, el estado cubano comenzó a invertir en varios sectores estratégicos de la economía y empezó a destinar gran cantidad de recursos a elevar el nivel de informatización de la sociedad, donde el ejemplo más fehaciente y actual lo constituye la creación de la Universidad de las Ciencias Informáticas para producir software de gran calidad e insertarlo en el mercado mundial. Como resultado de dicha estrategia, se han estado obteniendo sistemas empresariales más eficientes y de mayor calidad, a la altura de las exigencias tecnológica del momento.

A partir del perfeccionamiento empresarial, las empresas trabajan para lograr una mayor eficiencia en su producción o en los servicios que brindan. De ahí la utilización de sistemas informáticos que permitan la automatización de los procesos empresariales y de este modo, hacerlos mucho más eficientes. Uno de los sistemas que posibilita esto, son los Enterprise Recources Planning (ERP), que son sistemas de gestión de información que integran y automatizan en una única aplicación todos los procesos de negocio de una empresa, entiéndase por esto: producción, ventas, compras, logística, contabilidad, gestión de proyectos, inventarios, control de almacenes, pedidos, nóminas, recursos humanos, entre otras.

Los ERP brindan soporte a los usuarios del negocio, un manejo eficiente de la información para la toma de decisiones, tiempos rápidos de respuesta y una disminución de los costos totales de las operaciones. (Martínez, et al., 2001).

Uno de los procesos más importantes en la planificación de recursos de una empresa son los sistemas de inventario y por ello constituye una base sólida en el desarrollo de sistemas ERP.

En la economía de hoy día, el manejo de inventarios ha llegado a la cumbre de los problemas de la administración de empresas debido a que es un componente fundamental de la productividad. Si se mantienen inventarios demasiado altos, el costo podría llevar a una empresa a tener problemas de liquidez financiera. Por otro lado, si se mantiene un nivel insuficiente de inventario, podría no atenderse a los clientes de forma satisfactoria, lo cual traería como consecuencia reducción de ganancias y pérdida de mercado (Sanchez, 2006). Por lo que se puede apreciar que llevar inventarios sanos garantizará a cualquier empresa e industria una mayor confiabilidad a la hora de mover los productos dentro del almacén.

En Cuba existen Sistemas de Gestión de Inventarios, entre ellos se tienen: El Sistema de Inventario del Patrimonio Cultural y Natural (SIP), como su nombre lo indica fue creado con fines patrimoniales como: el registro, el control y la conservación de los mismos. El Sistema Informatizado para el Procesamiento del Inventario Forestal (INVENFOR 1.0), realizado con el fin de registrar y procesar los datos obtenidos del inventario forestal en función de estimar los parámetros dasométricos de los Rodales de forma tal que tribute a una planificación del manejo forestal más eficiente. Otros ejemplos de sistemas son: DRIM, FONDUS, SI e IHMM 2000 de la empresa GET (Grupo de Electrónica para el Turismo), este último con el objetivo de usarse en las instalaciones hoteleras.

Todos tienen algo en común, y es que la mayoría de estos sistemas están especializados para el funcionamiento de determinadas empresas, de aquí que no sean flexibles, sino más bien, cerrados en su diseño, difíciles de estandarizar el proceso de gestión de inventarios y la integración con otros sistemas, elementos primordiales que se proponen resolver.
Razón ésta, por la que se hace preciso el desarrollo de un nuevo sistema de gestión de inventarios que cumpla con las necesidades actuales de las empresas y del país como tal, dotado de la tecnología más reciente, de modo que sea más flexible, moderno, amigable, confiable y seguro, y además que sea capaz de integrarse con otros sistemas. Precisando de este que sea configurable a partir de las necesidades particulares de los clientes, que cumpla con las nuevas regulaciones que establece el Ministerio de Finanzas y Precios. En fin, que cumpla con todos los nuevos requerimientos que los antiguos sistemas no brindan por haber quedados obsoletos.

Para el desarrollo satisfactorio de cualquier sistema de software y que a la vez el mismo garantice una determinada calidad y bajos costes, se hace necesario la utilización de metodologías de desarrollo, las que guían este proceso. Un elemento significativo en el proceso de desarrollo es la concepción de un diseño de alto nivel, que permita organizar y comprender la estructura del sistema que se desarrolla y brinde a todo el equipo una idea clara de lo que se está desarrollando.

Es un hecho que durante el proceso de desarrollo de software surgen situaciones que limitan y dificultan el proceso en sí. Entre ellos se pueden ver: la escasa reutilización, la mala selección de elementos de software, estilos arquitectónicos, patrones de arquitectura, protocolos de comunicación, composición de elementos de diseño, asignación de funcionalidad a elementos del diseño, herramientas, frameworks, problemas de sincronización y acceso a datos, programadores escribiendo código de cualquier manera siempre y cuando cumpla con lo que quieren que haga el programa, influyendo todo esto en cuestiones de escalabilidad, rendimiento y costo. Donde la solución a todos estos problemas está en la correcta definición y descripción de una Arquitectura de Software.

La Arquitectura de Software surge de la necesidad de hacer los sistemas más modulares, que permitan la reutilización de componentes, por lo que su implementación reduce considerablemente el coste. Permite además mantener un bajo acoplamiento entre los elementos del sistema, pero con muy alta cohesión, ya que se establece bien claro la estructura de los componentes, sus formas de comunicarse y las relaciones que existen entre ellos.

Todo lo expuesto conllevó a la definición del siguiente problema:

¿Cómo tomar decisiones de diseño de alto nivel en el proceso de desarrollo del Sistema de Gestión de Inventarios que le permita a este, ser escalable, seguro, portable e integrable con otros sistemas de gestión empresarial?

La investigación se centra en el objeto de estudio: Proceso de Desarrollo del Sistema de Gestión de Inventario. Para ello se plantea el siguiente objetivo general: Proponer una Arquitectura de Software Orientada a Servicios que le permita al Sistema de Gestión de Inventario ser escalable, seguro, portable e integrable con otros sistemas de gestión empresarial.

Definiendo como campo de acción: Arquitectura de Software para el Sistema de Gestión de Inventario.

La investigación se realizó mediante las siguientes tareas para dar cumplimiento al objetivo propuesto:

• Realización de un estudio del estado del arte de la Arquitectura del Software para conocer los distintos enfoques de arquitectura, cómo evolucionaron, principales tendencias y definiciones, así como estilos arquitectónicos más significativos que están teniendo auge en el desarrollo de sistemas empresariales.

• Identificación de patrones y estilos arquitectónicos a utilizar, fundamentar la utilización de estos, así como su aplicación.
• Definición de los marcos de trabajo (frameworks) y las herramientas de desarrollo a utilizar.
• Definición y descripción de la Arquitectura.
• Validación por criterio de especialistas.
Para realizar las tareas se emplearon los siguientes métodos:
Métodos Teóricos
• Histórico – Lógico: Para determinar las tendencias actuales de desarrollo de los modelos y enfoques arquitectónicos.
• Analítico – Sintético: Para llegar a conclusiones en la investigación a partir de la información que se procese y precisar características del modelo arquitectónico propuesto.
• Método Sistémico: Para definir los elementos del sistema y sus relaciones.
Métodos Empíricos
• Medición: para la evaluación de los tiempos de respuesta en situaciones críticas del caso de estudio.

Posibles resultados

Propuesta de Arquitectura de Software Orientada a Servicios para el Sistema de Gestión de Inventarios que le permita a este, ser escalable, seguro, portable e integrable con otros sistemas de gestión empresarial.

El presente trabajo está estructurado en tres capítulos

Capítulo 1: Fundamentación Teórica.
En este capítulo se realiza la fundamentación teórica de la investigación basándose en un estudio del estado del arte de la Arquitectura de Software, así como de los distintos enfoques de arquitectura, principales tendencias y definiciones. Se realiza un estudio de los estilos arquitectónicos más significativos que están teniendo auge, exponiendo sus ventajas y desventajas. En fin todos aquellos aspectos que permitirán modelar el marco teórico que fundamenta la investigación.

Capítulo 2:
En este capítulo se realiza la propuesta de solución al problema planteado en el diseño teórico de la investigación, la misma viene dada por el artefacto Documento Descripción de Arquitectura que propone la Universidad de las Ciencias Informáticas a emplear en los proyectos productivos.

Capítulo 3:
En este capítulo se realiza la especificación de las herramientas que brindarán soporte a la propuesta arquitectónica realizada en el capítulo anterior para el Sistema de Gestión de Inventario. Además se efectúa un análisis de la propuesta de solución desde el punto de vista de la calidad.

CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA

1.1. Introducción

En este capítulo se realiza la fundamentación teórico de la investigación, un estudio del arte de la Arquitectura de Software, así como de los distintos enfoques de arquitectura, principales tendencias y definiciones. Un estudio de los estilos arquitectónicos más significativos que están teniendo auge en el desarrollo de sistemas empresariales y de gestión, exponiendo sus ventajas y desventajas para seleccionar el adecuado para el desarrollo del Sistema de Gestión de Inventarios. Un análisis de los distintos niveles de abstracción de la Arquitectura de Software, los lenguajes de modelado arquitectónico, el estilo Arquitectura Orientada a Servicio como desafío del presente y la calidad en la Arquitectura de software.

1.2. Estado del arte de la Arquitectura de Software

La Arquitectura de Software es una práctica joven de apenas unos pocos años de trabajo constante. Tiene sus orígenes en la década del 60, pero no fue hasta los años 90 que Dewayne Perry y Alexander Wolf, la exponen en el sentido que hoy se conoce.

“La década de 1990, creemos, será la década de la arquitectura de software. Usamos 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 re-examinar el papel 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.” (Perry, et al., 1992).

Esta década se consideró como la década de la arquitectura de software, según profetizaron Perry y Wolf. A partir de este momento la Arquitectura de Software comenzó a tener auge vertiginoso tanto en la academia como en la industria.

1.2.1. Principales definiciones

1.2.1.1. Arquitectura de Software

La Arquitectura de Software es una disciplina reciente (Szyperski, 2000), pero no por ser una normativa joven deja de tener la importancia que requiere. A medida que crece la complejidad de las aplicaciones, y que se extiende el uso de sistemas distribuidos, los aspectos arquitectónicos del desarrollo de software están recibiendo un interés cada vez mayor, tanto desde la comunidad científica como desde la propia industria del software (Velasco, 2000).

En la actualidad existen un sin número de definiciones de Arquitectura de Software, pero ninguna que sea adoptada completamente por la totalidad de los arquitectos del mundo. Aunque es válido aclarar que ninguna definición reprocha a la otra, sino que es otro modo de ver la cosas.

Entre las definiciones más reconocidas de la academia se encuentra la de Paul Clements: “La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones” (Reynoso, 2006).

De manera similar Bass define de la siguiente forma: “La Arquitectura de Software de un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos.” (Pressman, 2002).

Por otra parte la definición que más reconocida internacionalmente por muchos arquitectos tributa a la industria y pertenece a la IEEE 1471, la cual cita así: "La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución." (Reynoso, 2006).

A pesar de la abundante cantidad de definiciones que existen de Arquitectura de Software, la gran mayoría coincide en que esta se refiere a la estructura a grandes rasgos del sistema (alto nivel de abstracción), estructura consistente en componentes y relaciones entre ellos. Por lo que se define Arquitectura de Software como la estructura y organización de los elementos de software de un Sistema Informático, cómo y bajo qué condiciones y configuraciones se van a comunicar dichos elementos.

Se puede concluir que la Arquitectura de Software es: una disciplina independiente de cualquier metodología de desarrollo, representa un alto nivel de abstracción del sistema y responde a los requerimientos no funcionales ya que estos se satisfacen mediante el modelado y diseño de la aplicación. De la misma forma se puede llegar a la conclusión de que la Arquitectura de Software no es: diseño de software, una normativa madura, tratada de igual manera en la academia que en la industria.

1.2.1.2. Estilo

En general cuando se habla de la arquitectura, de una forma o de otra se refiere a algo en específico muy relacionado: las clasificaciones. El hecho es que no es solo como una cuestión clasificatoria, sino que cada forma arquitectónica tiene gran relación y se asocia con herramientas, conceptos, experiencias y problemas.

A estas clasificaciones se les ha llamado de varias formas, como: clases de arquitectura, tipos arquitectónicos, arquetipos recurrentes, especies, paradigmas topológicos, marcos comunes y varias docenas más. Desde hace más de una década esas cualificaciones arquitectónicas se vienen denominando: estilos, o alternativamente patrones de arquitectura. Los estilos sólo se manifiestan en arquitectura teórica descriptiva de alto nivel de abstracción; los patrones, por todas partes. (Reynoso, et al., 2004).

Las primeras definiciones explícitas de estilo parecen haber sido propuestas por Dewayne Perry y Alexander Wolf en octubre de 1992. Los mismos establecen el razonamiento sobre estilos de arquitectura como uno de los aspectos fundamentales de la disciplina. “Un estilo es un concepto descriptivo que define una forma de articulación u organización arquitectónica. El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composición de los estilos fundamentales” (Perry, et al., 1992).

Según Pressman (Pressman, 2002), un estilo describe una categoría de sistema que abarca un conjunto de componentes que realizan una función requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la coordinación y cooperación entre los componentes, las restricciones que definen como se integran los componentes para conformar el sistema, y los modelos semánticos que facilitan al diseñador el entendimiento de todas las partes del sistema. El estilo arquitectónico es también un patrón de construcción.

Los estilos conjugan componentes, conectores, configuraciones y restricciones (constraints). La descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un Lenguaje de Descripción Arquitectónica (ADL) o en Lenguajes Formales de Especificación (LFE).

Se puede concluir que:

• Un estilo contempla las cuatro “C” de la AS (elementos, conectores, configuraciones y restricciones), por sus siglas en inglés.
• Sirve para sintetizar estructuras de soluciones que luego serán refinadas a través del diseño.
• Pocos estilos abstractos encapsulan una enorme variedad de configuraciones concretas.
• Definen los patrones posibles de las aplicaciones, evitando errores arquitectónicos.
• Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales.

1.2.1.3. Patrón

“Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces” (Fowler, et al., 2002).

Se podría ver a un patrón como una solución a un problema determinado, una codificación de algo específico basado en un conocimiento específico acumulado por la experiencia.
“Un sistema bien estructurado esta lleno de patrones” (Reynoso, 2005).

Se puede decir que cada vez que se utiliza un patrón se utiliza un poco de aquí y otro poco de allá. Se verá la misma solución varias veces, pero nunca exactamente igual a ninguna otra.

Si se hace una primera clasificación de los patrones software atendiendo al nivel de abstracción de éstos, pudieran quedar: los patrones arquitectónicos, de diseño o centrados en el código, entre otros.

Elementos de un Patrón (Reynoso, 2005):
• Nombre
o Define un vocabulario de diseño
o Facilita abstracción
• Problema
o Describe cuando aplicar el patrón
o Conjunto de fuerzas: objetivos y restricciones
o Prerrequisitos
• Solución
o Elementos que constituyen el diseño (template)
o Forma canónica para resolver fuerzas
• Consecuencias
o Resultados, extensiones y tradeoffs

Patrón Arquitectónico

Según Buschmann los patrones de arquitectura se pueden ver como la descripción de un problema en particular y recurrente de diseño, que aparece en contextos de diseño arquitectónicos específicos, y representa un esquema genérico demostrado con éxito para su solución. El esquema de solución se especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y desarrollos, así como también la forma en que estos colaboran entre sí. (Buschmann, et al., 1996).

Los patrones arquitectónicos se definen sobre aspectos fundamentales de la estructura del sistema software, donde se especifican un conjunto de subsistemas con sus responsabilidades y una serie de recomendaciones para organizar los distintos componentes. Posteriormente, el diseño hará uso de patrones de diseño para resolver problemas específicos.

Patrón de Diseño

Un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comúnmente recurrente de los componentes en comunicación, que resuelve un problema general de diseño en un contexto particular (Buschmann, et al., 1996).

Son menores en la escala de abstracción que los patrones arquitectónicos, además tienden a ser independientes de los lenguajes y paradigmas de programación. Su aplicación tiene efectos sobre subsistemas, debido a que especifica a un mayor nivel de detalle, sin llegar a la implementación, el comportamiento de los componentes del subsistema.

1.2.1.4. Marco de trabajo

El concepto de marco de trabajo (framework) no es sencillo de definir, a pesar de que cualquiera con experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté utilizando su propio framework.

El concepto framework se emplea en muchos ámbitos del desarrollo de sistemas software. Se pueden encontrar frameworks para el desarrollo de aplicaciones web, aplicaciones de escritorio, aplicaciones médicas, para el desarrollo de juegos, y para cualquier ámbito que se le pueda ocurrir a uno.

En general, el término framework, se refiere a una estructura software compuesta de componentes personalizables e intercambiables para el desarrollo de una aplicación. En otras palabras, un framework se puede considerar como una aplicación genérica incompleta y configurable a la que se le puede añadir las últimas piezas para desarrollar una aplicación concreta.

Por lo que resumiendo, un framework es el esqueleto de una aplicación que debe ser adaptado por el programador según sus necesidades específicas para desarrollar una aplicación.

1.2.2. Tendencias

Aunque no existe hoy en día nada que avale explícitamente la existencia de escuelas de Arquitectura de Software, ni una referencia que analice las particularidades de cada una, en al actualidad se pueden distinguir a grandes rasgos unas seis corrientes. El pertenecer a una de estas corrientes no representa algo determinista, ya que en distintos momentos algunos practicantes de la Arquitectura de Software realizan diferentes trabajos operando en marcos distintos, o porque simplemente cambian de concepción.

La división de escuelas de Arquitectura de Software que se propone es la siguiente:
1. Arquitectura como etapa de ingeniería y diseño orientada a objetos. Evidentemente 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” [Boo91]. 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 descriptas a través de las cinco vistas clásicas del modelo 4+1 de Kruchten. (Reynoso, 2006).

2. Arquitectura estructural, basada en un modelo estático de estilos, ADLs y vistas. Los representantes de esta corriente son todos académicos, mayormente de la Universidad Carnegie Mellon. Se trata también de la visión de la Arquitectura de Software dominante en la academia, y aunque es la que ha hecho el esfuerzo más importante por 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 de Mark Moriconi en el SRI de Menlo Park. En principio se pueden reconocer tres modalidades en cuanto a la formalización; los más informales utilizan descripciones verbales o diagramas de cajas, los de talante intermedio se sirven de ADLs y los más exigentes usan lenguajes formales de especificación como CHAM y Z. En toda la corriente, 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 piezas de código, y en general nadie habla de clases o de objetos. Mientras algunos participantes excluyen el modelo de datos de las incumbencias de la Arquitectura de Software (Shaw, Garlan, etc), otros insisten en su relevancia (Medvidovic, Taylor). (Reynoso, 2006).

3. Estructuralismo arquitectónico radical. Se trata de un desprendimiento de la corriente anterior, mayoritariamente europeo, que asume una actitud más confrontativa con el mundo UML. En el seno de este movimiento hay al menos dos tendencias, una que excluye de plano la relevancia del modelado orientado a objetos para la Arquitectura de Software y otra que procura definir nuevos meta-modelos y estereotipos de UML como correctivos de la situación. (Reynoso, 2006).

4. Arquitectura basada en patrones. Si bien reconoce la importancia de un modelo emanado del diseño orientado a objetos, 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 POSA de Buschmann y otros, y secundariamente el texto de la Banda de los Cuatro [Gof95]. El diseño consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitectura. (Reynoso, 2006).

5. Arquitectura procesual. Desde comienzos del siglo XXI, con centro en el SEI y con participación de algunos de los arquitectos de Carnegie Mellon de la primera generación y muchos nombres nuevos de la segunda: Rick Kazman, Len Bass, Paul Clements, entre otros. Intenta establecer modelos de ciclo de vida y técnicas de elicitación de requerimientos, brainstorming, 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. (Reynoso, 2006).

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 borroso en la arquitectura estructural clásica. 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 objeto. Los autores vinculados con esta modalidad han sido, aparte de los codificadores de ATAM, CBAM, QASAR y demás métodos del SEI, los arquitectos holandeses de la Universidad Técnica de Eindhoven, de la Universidad Brije, de la Universidad de Groningen y de Philips Research. (Reynoso, 2006).

1.2.3. Diferencia entre Arquitectura de Software y Diseño

La comunidad académica de Arquitectura de Software difiere sustancialmente de confundir diseño con arquitectura, aunque algunos practicantes a la hora de referirse al tema dejan muy ambiguo la relación que existe entre ambos campos.

En alguna medida, la arquitectura y el diseño sirven al mismo propósito. Sin embargo, la Arquitectura de Software se centra en la estructura del sistema y en las interconexiones de los componentes, distinguiéndose del diseño de software tradicional, tales como el diseño orientado a objetos, que se concentra más en el modelado de abstracciones de más bajo nivel, tales como algoritmos y tipos de datos. A medida que la arquitectura de alto nivel se refina, sus conectores pueden perder prominencia, distribuyéndose a través de los elementos arquitectónicos de más bajo nivel, resultando en la transformación de la arquitectura en diseño. (Reynoso, et al., 2004).

La Arquitectura de Software, es una disciplina relativamente nueva en materia de diseño de software y en realidad abarca también las metodologías de diseño, así como metodologías de análisis. El arquitecto de software contemporáneo, ejecuta una combinación de roles como los de analista de sistemas, diseñador de sistemas e ingeniero de software. Pero la arquitectura es más que una recolocación de funciones. El concepto de arquitectura intenta subsumir las actividades de análisis y diseño en un framework de diseño más amplio y más coherente. Pero la arquitectura es algo más integrado que la suma del análisis por un lado y el diseño por el otro. La integración de metodologías y modelos, es lo que distingue la AS de la simple yuxtaposición de técnicas de análisis y de diseño. (Albin, 2003).

La arquitectura concierne a un nivel de abstracción más elevado; se ocupa de componentes y no de procedimientos; de las interacciones entre esos componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos, los procedimientos y los tipos. En cuanto a la composición, la de la arquitectura es de grano grueso, la del diseño es de fina composición procedural; las interacciones entre componentes en arquitectura tienen que ver con un protocolo de alto nivel (en el sentido no técnico de la palabra), mientras que las del diseño conciernen a interacciones de tipo procedural (mensajes, llamadas a rutinas) (Perry, 1997).

Por lo que se puede concluir que la Arquitectura de Software no es diseño de software, ya que ocurre en una etapa más temprana del desarrollo de un proyecto a un alto nivel de abstracción ocupándose de componentes, conectores, configuraciones, restricciones, dejándole al diseño detallar elementos arquitectónicos de más bajo nivel, más refinados como: procedimientos, algoritmos y tipos de datos.

1.3. Niveles de Abstracción de la Arquitectura de Software

1.3.1. Estilos Arquitectónicos

1.3.1.1. Clasificación de Estilos

¿Cuántos y cuáles son los estilos?

En un estudio realizado por Mary Shaw y David Garlan (Garlan, et al., 1994), proponen la siguiente taxonomía, en la que se entremezclan lo que antes se llamaba “arquitecturas” con los “modelos de diseño”:

1. Tubería-filtros
2. Organización de abstracción de datos y orientación a objetos
3. Invocación implícita, basada en eventos
4. Sistemas en capas
5. Repositorios
6. Intérpretes orientados por tablas
7. Procesos distribuidos. Una forma particular de proceso distribuido es, por ejemplo, la arquitectura cliente-servidor.
8. Organizaciones programa principal / subrutina.
9. Arquitecturas de software específicas de dominio
10. Sistemas de transición de estado
11. Sistemas de procesos de control
12. Estilos heterogéneos

En Software Architecture in Practice, un texto fundamental de Bass, Clements y Kazman (Bass, et al., 1998), se proporciona una sistematización de clases de estilo en cinco grupos:
• Flujo de datos (movimiento de datos, sin control del receptor de lo que viene “corriente arriba”)
o Proceso secuencial por lotes
o Red de flujo de datos
o Tubería-filtros
• Llamado y retorno (estilo dominado por orden de computación, usualmente con un solo thread de control)
o Programa principal / Subrutinas
o Tipos de dato abstracto
o Objetos
o Cliente-servidor basado en llamadas
o Sistemas en capas
• Componentes independientes (dominado por patrones de comunicación entre procesos independientes, casi siempre concurrentes)
o Sistemas orientados por eventos
o Procesos de comunicación
• Centrados en datos (dominado por un almacenamiento central complejo, manipulado por computaciones independientes)
o Repositorio
o Pizarra
• Máquina virtual (caracterizado por la traducción de una instrucción en alguna otra)
o Intérprete
Los estilos a diferencia de patrones son unos pocos, y se agrupan en clases de estilos, siendo la clasificación más actual, concisa y que se asume durante la investigación la siguiente (Reynoso, 2005):
• Estilos de Flujo de Datos
o Tubería y filtros
• Estilos Centrados en Datos
o Arquitecturas de Pizarra o Repositorio
• Estilos de Llamada y Retorno
o Model-View-Controller (MVC)
o Arquitecturas en Capas
o Arquitecturas Orientadas a Objetos
o Arquitecturas Basadas en Componentes
• Estilos de Código Móvil
o Arquitectura de Máquinas Virtuales
• Estilos heterogéneos
o Sistemas de control de procesos
o Arquitecturas Basadas en Atributos
• Estilos Peer-to-Peer
o Arquitecturas Basadas en Eventos
o Arquitecturas Orientadas a Servicios (SOA)
o Arquitecturas Basadas en Recursos

1.3.1.2. Estilos más Populares

En la década de 1960 y 1970 era natural estructurar una aplicación en términos de los servicios funcionales que ésta debía proveer. De hecho, las metodologías como el análisis y diseño estructurado partían de una descomposición funcional jerárquica que luego se transformaba en procedimientos dentro de la aplicación. Con el aumento de la complejidad de las aplicaciones y la necesidad de hacerlas evolucionar, este enfoque no fue suficiente. En los 80s y 90s se popularizó el desarrollo de software orientado-objetos que buscaba, entre otros objetivos, permitir la construcción de aplicaciones más mantenibles. (Casallas, et al., 2005).

Hoy parecen no ser suficiente los objetos, no porque hayan dejado de ser buenos, sino porque el problema ha cambiado. Estos cambios son consecuencia de los avances tecnológicos y el incremento de las expectativas de los clientes. Por ejemplo, las características no funcionales se han vuelto más críticas y el problema de la integración de aplicaciones ha llegado a ser prioritario. Se necesita contar con arquitecturas flexibles y lo más independientes posibles de las herramientas que se utilicen. En el (anexo 1) se muestra como han ido evolucionando las arquitecturas de los sistemas a lo largo de estos años.

Arquitectura Orientada a Objetos

A este tipo de arquitectura se le conoce de varias maneras, entre ellas: Arquitecturas Basadas en Objetos, Abstracción de Datos y Organización Orientada a Objetos.
Los componentes de este estilo son los objetos, o más bien instancias de los tipos de dato abstractos. En la caracterización clásica de David Garlan y Mary Shaw, los objetos representan una clase de componentes que ellos llaman managers, debido a que son responsables de preservar la integridad de su propia representación. Un rasgo importante de este aspecto es que la representación interna de un objeto no es accesible desde otros objetos. (Garlan, et al., 1994)

Según Billy Reinoso (Reynoso, et al., 2004), si hubiera que resumir las características de las arquitecturas orientadas a objetos, se podría decir que:

• Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y polimorfismo. Son asimismo las unidades de modelado, diseño e implementación, y los objetos y sus interacciones son el centro de las incumbencias en el diseño de la arquitectura y en la estructura de la aplicación.

• Las interfaces están separadas de las implementaciones. En general la distribución de objetos es transparente, y en el estado de arte de la tecnología apenas importa si los objetos son locales o remotos. El mejor ejemplo de orientación a objetos para sistemas distribuidos es Common Object Request Broker Architecture (CORBA), en la cual las interfaces se definen mediante Interface Description Language (IDL); un Object Request Broker media las interacciones entre objetos clientes y objetos servidores en ambientes distribuidos.

• En cuanto a las restricciones, puede admitirse o no que una interfaz pueda ser implementada por múltiples clases. Hay muchas variantes del estilo; algunos sistemas, por ejemplo, admiten que los objetos sean tareas concurrentes; otros permiten que los objetos posean múltiples interfaces.

Ventajas:

• Se puede modificar la implementación de un objeto sin afectar a sus clientes.
• Un objeto es una entidad reutilizable en el entorno de desarrollo
• Encapsulamiento.

Desventajas:

• Para poder interactuar con otro objeto a través de una invocación de procedimiento, se debe conocer su identidad.
• Presenta problemas de efectos colaterales en cascada: si A usa B y C también lo usa, el efecto de C sobre B puede afectar a A.
• Granularidad muy fina para sistemas grandes.

Arquitectura en Capas

Garlan y Shaw definen el estilo en capas como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior (Reynoso, et al., 2004). (Ver anexo 2).

En un estilo en capas, los conectores se definen mediante los protocolos que determinan las formas de la interacción. Las restricciones topológicas del estilo pueden incluir una limitación, más o menos rigurosa, que exige a cada capa operar sólo con capas adyacentes, y a los elementos de una capa entenderse sólo con otros elementos de la misma; se supone que si esta exigencia se relaja, el estilo deja de ser puro y pierde algo de su capacidad heurística (MSDN, 2004); también se pierde, naturalmente, la posibilidad de reemplazar de cuajo una capa sin afectar a las restantes, disminuye la flexibilidad del conjunto y se complica su mantenimiento.

A veces se argumenta que el cruce excesivo de muchos niveles involucra eventuales degradaciones de performance; pero muchas más veces se sacrifica la pureza de la arquitectura en capas precisamente para mejorarla: colocando, por ejemplo, reglas de negocios en los procedimientos almacenados de las bases de datos, o articulando instrucciones de consulta en la capa de la interface del usuario.

Ventajas

• Modularidad (hasta cierto punto)
• Soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un problema complejo en una secuencia de pasos incrementales.
• Proporciona amplia reutilización.
• Soporta fácilmente la evolución del sistema; los cambios sólo afectan a las capas vecinas
• Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes.

Desventajas

• Es difícil razonar a priori sobre la separación en capas requerida
• Formatos, protocolos y transportes de la comunicación entre capas suelen ser específicos y propietarios
• No todos los sistemas pueden estructurarse en capas.

Arquitectura basada en Componentes

Actualmente en el desarrollo de software hay una gran necesidad de hacer uso de la reutilización de partes o módulos de software existente, que podrían ser utilizadas para la generación de nuevas extensiones de las aplicaciones o las aplicaciones completas. Cuando se hable de reutilización en los procesos de ingeniería, esta muy implícito el concepto de “componente”, pues a las partes eficientes de software que pueden ser utilizadas para la construcción de aplicaciones se les conoce como “componentes software”.

Son varias las definiciones este término (Componente de Software):
• Según Krutchen, un componente es una parte no trivial, casi independiente y reemplazable de un sistema que cumple una función dentro del contexto de una arquitectura bien definida. Un componente cumple con un conjunto de interfaces y provee la realización física de ellas. (Brown, et al., 1998).
• El Software Engineering Institute (SEI) de la Universidad Carnegie Mellon formuló una definición con el propósito de consolidar las diferentes opiniones acerca de lo que debía ser un componente de software: “un componente es una implementación opaca de funcionalidad, sujeta a composición por terceros y que cumple con un modelo de componentes” (Bachmann, et al., 2000).
• Según Szyperski, un componente de software es una unidad de composición con interfaces especificadas contractualmente y solamente dependencias explícitas de contexto. Un componente de software puede ser desplegado independientemente y está sujeto a composición por terceros. (Szyperski, 2002).
Se puede ver que la mayoría de las definiciones giran sobre lo esencial de un componente, que es una implementación de un artefacto de software, que ejecuta una o varias funcionalidades, liberadas por servicios, vistos como un conjunto de interfaces y provee la realización física de ellas.

Características

Una de las características más importantes de los componentes es que son reutilizables. Para ello los componentes deben satisfacer como mínimo el siguiente conjunto de características:
• Identificable: un componente debe tener una identificación clara y consistente que facilite su catalogación y búsqueda en repositorios de componentes.
• Accesible sólo a través de su interfaz: el componente debe exponer al público únicamente el conjunto de operaciones que lo caracteriza (interfaz) y ocultar sus detalles de implementación. Esta característica permite que un componente sea reemplazado por otro que implemente la misma interfaz.
• Servicios son invariantes: las operaciones que ofrece un componente, a través de su interfaz, no deben variar. La implementación de estos servicios puede ser modificada, pero no deben afectar la interfaz.
• Documentado: un componente debe tener una documentación adecuada que facilite su búsqueda en repositorios de componentes, evaluación, adaptación a nuevos entornos, integración con otros componentes y acceso a información de soporte.
La evaluación dominante del estilo de componentes subraya su mayor versatilidad respecto del modelo de objetos, pero también su menor adaptabilidad comparado con el estilo orientado a servicios (Reynoso, et al., 2004).
Ventajas:
• Reutilización del software. Lleva a alcanzar un mayor nivel de reutilización de software.
• Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
• Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
• Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
Desventajas:
• Si no existen los componentes, hay que desarrollarlos y se puede perder mucho tiempo, así como en que estos componentes pueden tener conflictos si de estos sale una nueva versión es posible que haya que re-implementar estos componentes.
• Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.
v Arquitectura Orientada a Servicios (SOA)
Las Arquitecturas Orientadas a Servicios (SOA: Service Oriented Architecture) están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma y del lenguaje de programación (por ejemplo WSDL: Web Services Description Language). La definición de la interfaz encapsula las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Java o .NET).
Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reusables, ya que la interfaz se define siguiendo un estándar; así, un servicio desarrollado en CSharp podría ser usado por una aplicación Java.
Una de las características más resaltante de SOA, es que esta basada en contratos, donde el proveedor establece las reglas de comunicación, el transporte, y los datos de estrada y salida que serán intercambiados por ambas partes. Para ver mas características de SOA ver (anexo 3).

¿Qué es SOA?

• SOA es una arquitectura conceptual.
• Organiza funciones de negocio como servicios interoperables.
• Permite reutilización de servicios para satisfacer necesidades de negocio.
• SOA es basado en estándares.
• Independencia de fabricantes.
• SOA es una estrategia de IT a nivel empresarial.

SOA es un estilo de arquitectura en el cual se exponen los procesos de negocio del sistema a construir como servicios independientes de alta cohesión y bajo acoplamiento que encapsulan dichos procesos y pueden ser invocados a través de interfaces bien definidas.

¿Qué no es SOA?

SOA como tal no es:
• Metodología de Desarrollo de Proyectos.
• Metodología de Arquitectura Empresarial.

SOA como estilo arquitectónico
• Componente: Servicio
• Conectores: Antes, RPC – Ahora, paso de mensajes.
• Configuración: Distribuido
• Restricciones (Constraint): Bajo acoplamiento, independencia de modelo de programación, independencia de plataforma, transporte y protocolo por acuerdo de industria

Ventajas

• Mejorar toma de decisiones.
o Panorámica unificada. Más información con mejor calidad.
• Mejorar productividad de empleados.
o Acceso optimo a sistemas. No limitación de TIC
• Potenciar relación con los clientes y proveedores.
o Mayor capacidad de respuesta a los clientes.
• Aplicaciones más productivas y flexibles.
• Aplicaciones más seguras y manejables.

Desventajas

• Los tiempos de llamado no son despreciables, gracias a la comunicación de la red, tamaño de los mensajes, entre otros. Esto necesariamente implica la utilización de mensajería confiable.
• La respuesta del servicio es afectada directamente por aspectos externos como problemas en la red, configuración, entre otros.
• Debe manejar comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes fuera de secuencia, etcétera.

1.3.2. Patrones Arquitectónicos

Existe una categorización muy utilizada dividida en 2 de los sistemas de patrones de arquitectura más extendidos, siendo los mismos: el de Pattern Oriented Software Architecure (POSA) (Buschmann, et al., 1996) y el de Pattern of Enterprise Application Architecture (PEAA) (Fowler, et al., 2002).
Categorías de POSA
En el libro de referencia de patrones de arquitectura POSA, se divide a los patrones de la siguiente forma:
• From Mud to Structure: Estos patrones ayudan a evitar una abundancia de componentes u objetos. En particular, soportan una descomposición controlada de una tarea del sistema en sub-tareas que cooperan.
• Distributed Systems
• Interactive Systems
• Adaptable Systems
En el (anexo 4) se muestra la distribución de los patrones de POSA en las categorías enunciadas y seguidamente en el (anexo 5) se muestra una breve explicación de algunos de ellos.
Categorías de PEAA
En PEAA (Fowler, et al., 2002), describen una gran cantidad de patrones orientados a la arquitectura de aplicaciones empresariales.
En PEAA se definen las siguientes categorías de patrones:
• Layering: Patrones para dividir un sistema en capas.
• Organización de la lógica del dominio: Formas de organizar los objetos del dominio.
• Mapping to Relational Databases: Se relaciona con la comunicación entre la lógica del dominio y los repositorios de datos. Incluye el mapeo entre modelos de objetos y bases de datos relacionales.
• Web Presentation: La presentación Web es uno de los desafíos que han tenido que sortear en los últimos años las aplicaciones empresariales. Los clientes delgados Web proveen muchas ventajas, siendo una de las principales la facilidad de distribución (no es necesario instalar software en los equipos cliente). Esta categoría incluye una serie de patrones para gestionar la presentación Web. (Welicki, 2007)
• Concurrency: Manejo de la concurrencia. Las aplicaciones actuales basadas en tecnologías Web tienen grandes necesidades de gestión de la concurrencia.
• Sesion State: Patrones para el manejo de la sesión en servidores Web.
• Distribution Strategies: Distribución de objetos en múltiples emplazamientos, basada en conocimientos empíricos en clientes.
En el (anexo 6) se muestra la distribución de los patrones definidos en PEAA en las categorías antes expuestas.
Los términos patrón de arquitectura y estilo de arquitectura suelen confundirse y muchos de los estudiosos de la disciplina parecen no estar bien claros al respecto. Con la intención de hacer una comparación clara entre estilo arquitectónico y patrón arquitectónico, en (anexo 7) se presenta algunas de las diferencias entre estos conceptos, construida a partir del planteamiento (Buschmann, et al., 1996).
1.3.3. Relación entre los Niveles de Abstracción
En (anexo 8) se muestra la relación de abstracción existente entre los conceptos de estilo arquitectónico, patrón arquitectónico y patrón de diseño.
Los estilos y patrones ayudan al arquitecto a definir la composición y el comportamiento del sistema de software, y una combinación adecuada de ellos permite alcanzar los requerimientos de calidad permitiendo de esa manera que el sistema de software a construir perdure en el tiempo.
Ahora bien, la organización del sistema de software debe estar disponible para todos los involucrados en el desarrollo del sistema, ya que establece un mecanismo de comunicación entre los mismos. Esto se logra mediante la representación de la arquitectura en formas distintas, obteniendo así una descripción de la misma de forma tal que puede ser entendida y analizada por todos los involucrados, con miras a obtener un sistema de calidad. Estas descripciones pueden establecerse a través de las vistas arquitectónicas, las notaciones como UML y los lenguajes de descripción arquitectónica (Bengtsson, 1999).
Las vistas arquitectónicas, a través de distintos niveles de abstracción, resaltan varias cuestiones que conciernen a los involucrados en el desarrollo. Por lo que resulta interesante analizar estas perspectivas de una arquitectura, y la forma en que éstas ayudan a todos los involucrados en el proceso de desarrollo a razonar sobre los atributos de calidad del sistema.
1.3.4. Marcos de Trabajo
En la sección 1.2.1.4 se ha dado una breve definición sobre lo que es un framework por lo que esta sección se intentará abordar más sobre los mismos.
Los objetivos principales que persigue un framework son: acelerar el proceso de desarrollo, reutilizar código ya existente y promover buenas prácticas de desarrollo como el uso de patrones, entre otros.
La labor del usuario del framework debe ser, por un lado, de seleccionar, instanciar, extender y reutilizar los componentes que este proporciona, y por otro, completar la arquitectura del mismo desarrollando componentes específicos, que deben ser acoplados en el framework, logrando así desarrollar diferentes aplicaciones siguiendo las restricciones estructurales impuestas por el framework.
¿Qué ventajas tiene utilizar un framework?
Las que se derivan de utilizar un estándar; entre otras:
• El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que “rellenar”.
• Facilita la colaboración. Cualquiera que haya tenido que pelearse con el código fuente de otro programador, o incluso con el propio, sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.
• Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el desarrollo.
Aunque el uso de los frameworks sea una buena práctica para el desarrollo de un sistema software no significa que haya que utilizar obligatoriamente uno, ya sea conocido o no, ni nada por el estilo. Esto va a estar en dependencia de la magnitud del proyecto y de la experiencia que se tenga por parte del equipo de desarrollo y el arquitecto.
Según uno de los principios de la programación segura, ¿Por qué no utilizar un framework ya definido, y aprovechar el trabajo de otros desarrolladores?, o sea, ¿Por qué reinventar la rueda? Si se tiene algo que probado, que funciona, y está en explotación, no hay necesidad de hacer algo que haga lo mismo, esto es poco útil y solo puede traer complicaciones como la pérdida de tiempo.
Es cierto que la utilización de un framework implica cierto coste inicial (curva de aprendizaje), pero esto es algo que se compensa a la larga durante el desarrollo de un proyecto software.
1.4. SOA: Desafío del presente
La Arquitectura Orientada a Servicios es un concepto de arquitectura de software que define la utilización de servicios como construcciones básicas para el desarrollo de aplicaciones. Es una arquitectura de una aplicación donde las funcionalidades se definen como servicios independientes, con interfaces accesibles, bien definidas, que pueden ser llamadas en secuencias dadas para formar procesos de negocios.
“SOA ha surgido como la mejor manera de afrontar el desafío de hacer más con menos recursos. Promete hacer la reutilización y la integración mucho más fáciles, ayudando a reducir el tiempo de desarrollo y aumentando la agilidad organizacional. No sorprendentemente, el 80% de las organizaciones de IT están implementando aplicaciones usando SOA con web services subyacentes. SOA proporciona mayor flexibilidad para afrontar los cambios tanto en el ambiente de negocios como en la infraestructura tecnológica” (Reynoso, 2005).
Gartner, proveedor líder de investigación y análisis de la industria global de tecnologías de información (TI), en el 2003 plantea: “Hacia 2008, SOA será la práctica prevalente de ingeniería de software, acabando con los 40 años de dominación de las arquitecturas monolíticas (probabilidad 0.7)” (Natis, 2003).

1.4.1. Razones para usar SOA

Existen varias razones para que una empresa adopte un enfoque SOA, y más concretamente un enfoque SOA basado en servicios web:

• Reutilización: El factor fundamental en el cambio a SOA es la reutilización de los servicios de negocio. Las funciones de negocio, dentro de una empresa y con los business partners , pueden ser expuestos como servicios web y ser reutilizadas para cubrir nuevas necesidades de negocio.

• Interoperabilidad: El objetivo de una arquitectura débilmente acoplada es que los clientes y servicios se comuniquen independientemente de la plataforma en que residan. Los protocolos de comunicación con servicios web son independientes de la plataforma, lenguaje de codificación y sistema operativo por lo que facilitan la comunicación con los business partners.

• Escalabilidad: Como los servicios de SOA están débilmente acoplados, las aplicaciones que usan esos servicios escalan fácilmente. Esto es debido a que existe muy poca dependencia entre las aplicaciones clientes y los servicios que usan.

• Flexibilidad: Es otra de las características que proporciona el acoplamiento débil entre los servicios. Cualquier cambio en la implementación de uno de ellos no afectaría al resto siempre que se mantenga la interfaz.

• Eficiencia de coste: Las arquitecturas SOA se basan en la exposición de servicios ya existentes para ser reutilizados. Al usar servicios web, para exponer estos servicios, se reutilizan la infraestructura web existente en virtualmente todas las organizaciones por lo que se limita considerablemente el coste.

1.4.2. Elementos de SOA

Esta arquitectura presenta una forma de construir sistemas distribuidos que entreguen a la aplicación funcionalidad como servicios para aplicaciones de uso final u otros servicios.
En el anexo 9 se muestran los elementos que podrían observarse en una arquitectura orientada a servicios. En el mismo se pueden diferenciar dos zonas, una que abarca los aspectos funcionales de la arquitectura y otra que abarca aspectos de calidad de servicio. A continuación se describen los elementos brevemente (Endrei, et al., 2004):

• Funciones

o Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el proveedor hacia el consumidor.
o Protocolo de comunicación de servicios: es un mecanismo acordado a través del cual un proveedor de servicios y un consumidor de servicios comunican qué está siendo solicitado y qué está siendo respondido.
o Descripción de servicio: es un esquema acordado para describir qué es el servicio, cómo debe invocarse, y qué datos requiere el servicio para invocarse con éxito.
o Servicios: describe un servicio actual que está disponible para utilizar.
o Procesos de Negocio: es una colección de servicios, invocados en una secuencia particular con un conjunto particular de reglas, para satisfacer un requerimiento de negocio.
o Registro de Servicios: es un repositorio de descripciones de servicios y datos que pueden utilizar proveedores de servicios para publicar sus servicios, así como consumidores de servicios para descubrir o hallar servicios disponibles.

• Calidad de Servicio

o Política: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para consumidores.
o Seguridad: es un conjunto de reglas que pueden aplicarse para la identificación, autorización y control de acceso a consumidores de servicios.
o Transacciones: es el conjunto de atributos que podrían aplicarse a un grupo de servicios para entregar un resultado consistente.
o Administración: es el conjunto de atributos que podrían aplicarse para manejar los servicios proporcionados o consumidos.
Las colaboraciones en SOA siguen el paradigma publicar, descubrir e invocar, donde un consumidor de servicios realiza la localización dinámica de un servicio consultando el registro de servicios para hallar uno que cumpla con un determinado criterio. Si el servicio existe, el registro proporciona al consumidor la interfaz de contrato y la dirección del servicio proveedor. (Endrei, et al., 2004).

En el anexo 10 se ilustra las entidades (roles, operaciones y artefactos) en una Arquitectura Orientada a Servicios donde estas colaboran.
Cada entidad de las que se muestra en el diagrama del (anexo 10) puede tomar el rol de consumidor, proveedor y/o registro:
• Un consumidor de servicios es una aplicación, un módulo de software u otro servicio que requiere un servicio, y ejecuta el servicio de acuerdo a un contrato de interfaz.
• Un proveedor de servicios es una entidad direccionable a través de la red que acepta y ejecuta consultas de consumidores, y publica sus servicios y su contrato de interfaces en el registro de servicios para que el consumidor de servicios pueda descubrir y acceder al servicio.
• Un registro de servicios es el encargado de hacer posible el descubrimiento de servicios, conteniendo un repositorio de servicios disponibles y permitiendo visualizar las interfaces de los proveedores de servicios a los consumidores interesados.
Las operaciones son:
• Publicar. Para poder acceder a un servicio se debe publicar su descripción para que un consumidor pueda descubrirlo e invocarlo.
• Descubrir. Un consumidor de servicios localiza un servicio que cumpla con un cierto criterio consultando el registro de servicios.
• Ligar e Invocar. Una vez obtenida la descripción de un servicio por parte de un consumidor, éste lo invoca de acuerdo a la información en la descripción del servicio.
Finalmente, los artefactos en una arquitectura orientada a servicios son (Alvez, et al., 2006):
• Servicio. Un servicio que está disponible para el uso a través de una interfaz publicada y que permite ser invocado por un consumidor de servicios.
• Descripción de servicio. Una descripción de servicio especifica la forma en que un consumidor de servicio interactuará con el proveedor de servicio, especificando el formato de consultas y respuestas desde el servicio. Esta descripción también puede especificar el conjunto de precondiciones, pos-condiciones y/o niveles de calidad de servicio.
Analizando lo anteriormente planteado se puede concluir que el elemento básico en este tipo de arquitectura es el servicio, pero únicamente con este artefacto no se podría diseñar una SOA. Para conformar una SOA se necesita básicamente la conjunción de operaciones, servicios, mensajes y procesos de negocio.

1.4.2.1. Tipos de Servicios

• Servicios básicos: pueden estar centrados en datos o en lógica y encapsulan funcionalidades como cálculos complejos, acceso a datos y reglas complejas de negocio.
• Servicios intermediarios: servicios adaptadores, fachadas, etcétera. Suelen ser servicios sin estado.
• Servicios de proceso: servicios de negocio que encapsulan la lógica de proceso. Suelen conservar estado y pueden residir en herramientas BPM.
• Servicios públicos: servicios accesibles por terceros (fuera de la organización).
Un servicio de negocio es un componente reutilizable de software, con significado funcional completo, y que está compuesto por (ver anexo 11):
• Contrato: especificación de la finalidad, funcionalidad, forma de uso y restricciones del servicio.
• Interfaz: mecanismo de exposición del servicio a los usuarios.
• Implementación: debe contener la lógica o el acceso a datos.

1.4.3. Servicios Web

Las Arquitecturas Orientadas a Servicios, en contraste con las Arquitecturas Orientadas a Objetos, están formadas por servicios de aplicación altamente interoperables y débilmente acoplados. Donde estos servicios se pueden ver como la evolución en complejidad de un componente distribuido, diferenciándose en que son (Alvez, et al., 2006):
• Mucho menos acoplados con sus aplicaciones cliente que los componentes.
• Menor granularidad que los componentes.
• No son diseñados e implementados necesariamente como parte de una aplicación end-to-end.
• Son controlados y administrados de manera independiente.
• Expone su funcionalidad a través de protocolos abiertos e independientes de plataforma. Incluso arriesgando el rendimiento y consumo de recursos.
• Son transparentes de su localización en la red, de esta manera garantizan escalabilidad y tolerancia a fallos.
Por lo general, los servicios incluyen tanto lógica de negocios como manejo de datos, relevantes a la solución del problema para el cual fueron diseñados. Un servicio funciona como una aplicación independiente, teniendo sus propias reglas de negocio, datos, procedimientos de administración y operación, políticas de escalabilidad, seguridad, tolerancia a fallos, manejo de excepciones y configuración. Expone toda su funcionalidad utilizando una interfaz basada en mensajes, por lo que la comunicación con el servicio, es realizada mediante mensajes y no llamadas a métodos. Estos mensajes deben contener o referenciar toda la información necesaria para ser entendidos.
Los servicios web comunican aplicaciones, lo cual permite que se comparta información independientemente de cómo se hayan creado, cuál sea el sistema operativo o la plataforma en que se ejecutan y cuáles sean los dispositivos utilizados para obtener acceso a ellas. La comunicación se caracteriza por el intercambio de mensajes XML y por ser independientes del protocolo de comunicación. Para lograr esta independencia, el mensaje XML se envuelve de manera apropiada para cada protocolo gracias a la creación del protocolo de transporte SOAP (Simple Object Access Protocol: Protocolo de Acceso a Objetos Simples). (Alvez, et al., 2006)
El Lenguaje de Descripción de los Servicios Web (WSDL: Web Services Description Languaje), expresado en XML, describe cómo acceder al servicio, de qué funciones dispone, qué argumentos necesita y qué devuelve cada uno.
La otra tecnología fundamental implicada es la de Descripción Universal, Descubrimiento e Integración (UDDI: Universal Description, Discovery, and Integration). UDDI es un directorio de servicios web donde se puedan publicar los servicios ofrecidos, dar características del tipo de servicio, y realizar búsquedas.
En resumen, SOAP define un protocolo XML para la interoperabilidad básica entre servicios, WSDL introduce un lenguaje común para describir servicios y UDDI provee la infraestructura requerida para publicar y descubrir servicios programáticamente. Juntas, estas especificaciones permiten a las aplicaciones interactuar siguiendo un modelo débilmente acoplado e independiente de la plataforma subyacente.
1.4.3.1. Tecnologías asociadas
WSDL
El lenguaje de descripción de servicios web, nació en septiembre de 2000 de la mano de Microsoft, IBM y Ariba, y constituye un estándar para la descripción de servicios del World Wide Web Consortium (W3C), organización que guía el desarrollo en la web. (Endrei, et al., 2004)
En esencia, WSDL es un contrato entre el proveedor del servicio y el cliente mediante el que el proveedor del servicio indica (Alvez, et al., 2006):
• Qué funciones que se pueden invocar
• Qué tipos de datos utilizan esas funciones
• Qué protocolo de transporte se utilizará para el envío y recepción de los mensajes (típicamente, pero no únicamente, mensajes SOAP).
• Cómo acceder a los servicios. En esencia, mediante qué URL se utilizan los servicios.
SOAP
Es un protocolo simple para el intercambio de información estructurada en un entorno distribuido y descentralizado. Define como dos objetos en diferentes procesos pueden comunicarse por medio del intercambio de datos XML. Utiliza XML para definir un framework extensible de mensajería proveyendo un formato de mensaje que puede ser intercambiado sobre una variedad de protocolos subyacentes. El framework fue diseñado para ser independiente de cualquier modelo de programación o cualquier semántica específica de alguna implementación (W3C, 2007).
El hecho de que SOAP use XML tiene sus ventajas como la facilidad de comprensión por las personas, pero a la vez tiene sus inconvenientes debido a que los mensajes son más largos.
UDDI
Es un elemento central del grupo de estándares involucrados en la tecnología servicios web. Es el mediador a través del cual se conocen los posibles clientes con los proveedores de los servicios. Define un método estándar para publicar y descubrir servicios en el contexto SOA (Alvez, et al., 2006).
La especificación de UDDI nació casi a la vez que la de WSDL, de la mano de las mismas compañías. La versión actual es la 3.0, especificación que data de agosto de 2003, siendo gestionada por Organization for the Advancement of Structured Information Standards (OASIS). La implementación de estas especificaciones se denomina “Registro UDDI”, el cual proporciona un conjunto de servicios web de registro y consulta vía SOAP.
El propósito funcional de un registro UDDI es la representación de datos y metadatos acerca de servicios web. Tanto para ser usado en una red pública como dentro de la infraestructura interna de una organización, un registro UDDI ofrece un mecanismo basado en estándares para clasificar, catalogar y manejar servicios web de forma de que puedan ser descubiertos y consumidos por otras aplicaciones.
Estructuras de datos en UDDI
La información almacenada en un registro UDDI es un conjunto de las denominadas “estructuras de datos UDDI”. Estas estructuras, en XML, definidas en la especificación, son las que el cliente intercambiará con el registro UDDI. Cada instancia de estas estructuras se identifica de manera única con un identificador denominado Universal Unique Identifier (UUID) (OASIS, 2004).
Las principales estructuras de alto nivel son las siguientes (Alvez, et al., 2006):
• BusinessEntity. Contiene información básica de la empresa: persona de contacto, una clasificación de la empresa conforme a alguna de las taxonomías definidas, así como una descripción en lenguaje natural de las actividades de la empresa.
• PublisherAssertion. Una empresa puede declarar su relación con otras empresas, por ejemplo, como socios o como clientes. Cada una de estas relaciones se modela como una PublisherAssertion.
• BusinessService. Este elemento muestra los servicios ofrecidos por una empresa. Estos servicios pueden ser servicios web o no. Una BusinessEntity se compone de uno o varios elementos businessService, y un elemento businessService puede ser usado por varios elementos BusinessService.
• BindingTemplate. Este elemento contiene referencias a descripciones técnicas (por ejemplo, URLs apuntando a manuales técnicos) y a las URL de acceso de los servicios web. Cada elemento BusinessService puede tener uno o varios elementos BindingTemplate.
• TModel. Este elemento describe la manera de interactuar con el servicio web y su comportamiento. Entre sus datos se encuentra la URL donde se encuentra el documento WSDL. También pueden aparecer aquí las categorías en las que se puede englobar el servicio (pueden ser distintas de las que podían aparecer en BusinessEntity).
1.4.4. Composición de Servicios
En situaciones en las que un sistema de software, para completar un proceso de negocio, tiene que interactuar con otros sistemas independientemente de su distribución física y heterogeneidad, las Arquitecturas Orientadas a Servicios son más que útiles.
De las Arquitecturas Orientadas a Servicios y más precisamente del uso de servicios web surge un nuevo concepto denominado composición de servicios. Esta composición no solo permite modelar el proceso de negocio sino que también maximiza las potencialidades que SOA brinda a través de la integración de datos y aplicaciones.
La composición de servicios implica encontrar un mecanismo que permita a dos o más de ellos cooperar entre sí para resolver requerimientos que van más allá del alcance de sus capacidades individuales. Algunos de los requisitos básicos que se deben cumplir son (Alvez, et al., 2006):
• Interacciones asincrónicas con servicios: de manera de dar la posibilidad de crear procesos que transcurran durante largos períodos de tiempo.
• Interacciones simultáneas entre servicios: esto introduce el procesamiento en paralelo lo cual redunda en un aumento considerable de la eficiencia.
• Manejo de excepciones: un proceso basado en múltiples servicios puede fallar en su ejecución si al menos uno de sus componentes falla. Se debe tener en cuenta la ocurrencia de errores y proveer mecanismos para manejarlos.
• Integridad transaccional: un proceso de larga duración puede eventualmente fallar, en este caso puede requerirse que parte de las acciones ya efectuadas se deshagan.
Dos términos comúnmente usados para referirse a la colaboración entre servicios son orquestación y coreografía. Ambos están directamente relacionados con la composición pero se enfocan en aspectos complementarios de la interacción entre servicios.
Orquestación
Un proceso se puede considerar una orquestación de servicios cuando es controlado totalmente por una única entidad. Este proceso define completamente las interacciones con los servicios componentes y la lógica requerida para conducir correctamente esas interacciones. Este tipo de proceso puede entenderse como privado y ejecutable ya que solo la entidad que está orquestando el proceso conoce el flujo de control e información que sigue el proceso que se está orquestando. De esta manera se crea un proceso que utiliza diferentes servicios manipulando la información que fluye entre ellos, convirtiendo, por ejemplo, los datos de salida de algunos servicios en datos de entrada de otro. Aquí, cada entidad que participa implementa y controla su propio proceso (Cubillos, et al., 2004).
Coreografía
Un proceso es una coreografía de servicios cuando define las colaboraciones entre cualquier tipo de aplicaciones componentes, independientemente del lenguaje o plataforma en el que estén definidas las mismas. Un proceso de coreografía no es controlado por uno solo de los participantes. A diferencia de la orquestación, la coreografía puede verse como un proceso público y no ejecutable. Público porque define un comportamiento común que todas las entidades participantes deben conocer, y no ejecutable porque está pensado para verse más bien como un protocolo de negocio que dicta las reglas para que dichas entidades puedan interactuar entre sí (Cubillos, et al., 2004).
1.4.5. SOA & Web Service
Una SOA a menudo es malinterpretada y confundida con los servicios web. SOA es un acercamiento al diseño de sistemas, dirige como los recursos tecnológicos serán integrados y que servicios serán expuestos. A su vez los servicios web son una metodología de implementación que usa estándares específicos y protocolos de lenguaje para ejecutar la solución SOA.
Una Arquitectura Orientada a Servicios es un método de diseñar y construir soluciones de software poco acopladas que expongan sus funciones del negocio como servicios de software accesibles a través de programación para ser usadas por otras aplicaciones a través de la publicación de interfaces. Los servicios web representan una implementación de una Arquitectura Orientada a Servicios pero no todas las aplicaciones SOA pueden ser consideradas servicios web, tal es el caso de Representational State Transfer (REST).
A pesar de esto los servicios web son la tecnología actual, y al parecer, la tecnología que ha llegado para quedarse. De hecho WSDL sigue desarrollándose, y todas las tecnologías más allá del lenguaje de descripción que tiene que ver con servicios web siguen haciéndolo de manera muy vertiginosa.
Por otra parte las Arquitecturas Orientadas a Servicios son un concepto mucho más amplio que los servicios web, aunque estos sean la implementación actual.
Un servicio web es SOA si (Reynoso, 2005):
• Las interfaces se basan en protocolos de web (HTTP, SMTP, FTP)
• Los mensajes se basan en XML.
1.4.6. Modelo de Madurez de SOA
¿Qué es un modelo de Madurez?
• Permite medir el estado actual de una arquitectura empresarial respecto a la utilización de SOA.
• Permite establecer una ruta de evolución.
¿Por qué un Modelo de Madurez?
• Habilita aprendizaje por capas incluyendo buenas prácticas
• Forma la base para comunicar y extender capacidades.
• Ayuda en la construcción de itinerarios.
• Forma la base para crear una adopción incremental de SOA.
El modelo de madurez propuesto en esta sección consta de cinco niveles: servicios iniciares, servicios arquitecturados, servicios de negocio, de colaboración, de métricas de negocio y optimizados de negocio. Estos niveles van a permitir ir escalando en ganancia de una SOA ya que en este tipo de arquitecturas se va de menos a más (Ver anexo 12). Este modelo de madurez es propuesto por Progress Software Corporation una reconocida empresa de software dedicada al suministro de plataformas de aplicaciones de negocios, entre ellas, infraestructuras SOA y de integración. Tiene productos en el mercado del software reconocidos como: SONIC ESB, entre otros.
1.5. ADLs y UML
ADL
Los Lenguajes de Descripción de Arquitectura (ADL: Architecture Description Language) permiten modelar una arquitectura antes que se lleve a cabo la programación de las aplicaciones que la componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular su comportamiento. Los mismos son bien reconocidos por la comunidad académica de Arquitectura de Software, sin embargo parecen no gozar de la misma aceptación en la practica industrial, al no utilizarlos en sus proyectos de software.
Estos suministran construcciones para especificar abstracciones arquitectónicas y mecanismos para descomponer un sistema en componentes y conectores, especificando de qué manera estos elementos se combinan para formar configuraciones y definiendo familias de arquitecturas o estilos. (Reynoso, et al., 2004)
Los ADLs están caracterizados por la abstracción que proveen al usuario, además la mayoría de las vistas provistas por estos lenguajes contienen información predominantemente arquitectónica y el análisis provisto por el lenguaje se fundamenta en información de nivel arquitectónico.
Algunas de las ventajas que proponen los ADLs son:
• Es posible hacer la descripción del comportamiento y sus elementos asociados, tales como el tipo de eventos que producen, o a los que responden, incluyendo descripciones o documentación de alto nivel.
• Facilidad con la que puede introducirse y mantenerse la información referente al sistema.
• Los componentes pueden ser refinados en la medida que sea necesario, para distintos tipos de análisis.
A pesar de todo lo anterior expuesto se puede decir que los ADLs son convenientes, pero no han demostrado aún ser imprescindibles, sobre todo por la permanencia de UML, ahora con la versión 2.0 (Reynoso, et al., 2004).
UML
El Lenguaje de Modelado Unificado (UML: Unified Modeling Language) está especializado en construir, especificar, visualizar y documentar los elementos que se producen en el proceso de desarrollo de software de Sistemas de Software Orientados a Objetos. Está compuesto por diversos elementos gráficos que se combinan para conformar diagramas y debido a que es un lenguaje, cuenta con reglas para combinar tales elementos. Ofrece soporte para clases, relaciones, comportamiento por interacción, empaquetamiento, entre otros. Estos elementos se pueden representar mediante varios diagramas ofrecidos por este lenguaje que son: de clases, de objetos, de casos de uso, de secuencia, de colaboración, de estados, de actividades, de componentes y de desarrollo.
UML a pesar de no calificar en absoluto como ADL, se ha probado que puede utilizarse no tanto como un ADL por derecho propio, sino como metalenguaje para simular otros ADLs, y en particular C2 y Wright (Reynoso, et al., 2004).
En UML se identifican:
• Elementos (abstracciones que constituyen los bloques básicos de construcción)
• Relaciones (Ligan los elementos)
• Diagramas (Representación gráfica de un conjunto de elementos)
UML provee una notación para la descripción de la proyección de los componentes de software en el hardware, correspondiendo con la vista física del modelo 4+1 de Kruchten para la descripción de arquitecturas de software (Kruchten, 1999).
En UML existe soporte para algunos de los conceptos asociados a las arquitecturas de software, como los componentes, los paquetes, las librerías y la colaboración por lo que se puede decir que los elementos básicos de la arquitectura se pueden modelar muy bien con UML. Pero para una representación total de la arquitectura harían falta otras herramientas y lenguajes, pues la representación total no es solo la comunicación que existe entre sus componentes, también se deben documentar y justificar todo lo realizado para lograr un buen diseño arquitectónico.

1.6. Calidad en la Arquitectura de Software

La Arquitectura de Software de los Sistemas de Software a ser construidos, se convierte en un factor de importancia para lograr que éste tenga un alto nivel de calidad. El poseer una buena Arquitectura de Software es de suma importancia, ya que ésta es el corazón de todo Sistemas de Software y determina cuáles serán los niveles de calidad asociados al sistema.

De lo anterior se puede deducir que los objetivos de evaluar una arquitectura es saber si puede habilitar los requerimientos, atributos de calidad y restricciones para asegurar que el sistema a ser construido cumple con las necesidades de los stakeholders y en qué grado lo hace. Además de analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante.

Cabe señalar que los requerimientos no funcionales también son llamados atributos de calidad. Un atributo de calidad es una característica de calidad que afecta a un elemento.

Donde el término característica se refiere a aspectos no funcionales y el término elemento a componente (Gómez, 2007).

Técnicas de Evaluación

Existen un grupo de técnicas para evaluar que se clasifican en cualitativas y cuantitativas (Brey, et al., 2005) (ver anexo 13):

• Técnicas de cuestionamiento o cualitativas. Utilizan preguntas cualitativas para preguntarle a la arquitectura
o Cuestionarios. Abiertas. Temprana
o Checklists. Especifico del Dominio de la aplicación.
o Escenarios. Especificas del Sistema. Arquitectura avanzada.
• Measuring techniques. Sugiere hacerle medidas cuantitativas a la arquitectura.
o Utiliza métricas arquitectónicas, como acoplamiento, cohesividad en los módulos, profundidad en herencias, modificabilidad.
o Simulaciones, Prototipos, y Experimentos

Por lo regular, las técnicas de evaluación cualitativas son utilizadas cuando la arquitectura está en construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada (Gómez, 2007).

¿Por qué cualidades puede ser evaluada una Arquitectura?

A grandes rasgos, Bass establece una clasificación de los atributos de calidad en dos categorías (Camacho, et al., 2004):

• Observables vía ejecución: aquellos atributos que se determinan del comportamiento del sistema en tiempo de ejecución. La descripción de algunos de estos atributos se presenta en el (anexo 14).

• No observables vía ejecución: aquellos atributos que se establecen durante el desarrollo del sistema. La descripción de algunos de estos atributos se presenta en el (anexo 15).

¿Qué resultados produce la evaluación de una Arquitectura?

Una vez que se ha efectuada la evaluación se debe elaborar un reporte. Que debe presentarse como un documento preliminar, con la finalidad de que se corrija por las personas que participaron en la evaluación. El contenido del reporte responde a dos tipos de preguntas (Gómez, 2007):

• ¿Se ha diseñado la arquitectura más apropiada para el sistema?

• ¿Cuál de las arquitecturas propuestas es la más apropiada para el sistema a construir?.

Además de responder estas preguntas, el reporte también indica:

• El grado en que se cumplieron los atributos de calidad.

• Lista priorizada de los atributos de calidad requeridos para la arquitectura que está siendo evaluada.

• Riesgos y no riesgos.

Hoy en día existen varios métodos para realizar evaluaciones a una Arquitectura de Software que verifican el cumplimiento o no de ciertos atributos de calidad, siendo unos más específicos que otros, como es el caso de: Architecture Trade-off Analysis Method (ATAM), Bosch (2000), Active Design Review (ADR), Active Reviews for Intermediate Design (ARID), Losavio (2003).

Existen otros métodos de evaluación de arquitectura que evalúan un atributo de calidad específico, como: Architecture Level Modifiability Analysis (ALMA), Performance Assessment of Software Architecture (PASA), Scenario based Architecture Level Usability Analysis (SALUTA) y Survivable Network Analysis (SNA).

Independientemente de cuan especifico o no pueda ser el método de evaluación la gran mayoría tiene algo en común y es que utilizan la técnica de escenarios como vía de constatar en qué medida la arquitectura responde a los atributos de calidad requeridos por el sistema.
Un método de evaluación no es mejor que otro, sino que evalúa mejor, en ciertas condiciones, un atributo de calidad dado. Por lo que se concluye que en dependencia de las condiciones y lo que se desea evaluar, será el método de evaluación empleado (que no tiene que ser solo uno).

Relación entre la Arquitectura de Software y Atributos de Calidad

Durante el proceso de desarrollo de todo sistema de software se toman decisiones de diseño arquitectónico que permiten alcanzar ciertos y determinados atributos de calidad. Para esto el arquitecto se debe cuestionar frecuentemente cuál será el impacto que esa decisión causara sobre otros atributos de calidad.

Cada decisión incorporada en una arquitectura de software puede afectar potencialmente los atributos de calidad (Bass, et al., 2000). Por lo que se puede decir que al tomar dichas decisiones generalmente se tienen consecuencias como:

• Formulación de argumentos que expliquen cómo la decisión tomada permite alcanzar los atributos de calidad propuestos.

• Preguntas referentes al impacto de tomar dicha decisión, sobre otros atributos de calidad.
La relación que existe entre los Atributos de Calidad y la Arquitectura de Software tiene diversos beneficios (Camacho, et al., 2004):

• Realza en gran medida el proceso de análisis y diseño arquitectónico, ya que el arquitecto puede reutilizar análisis existentes y determinar acuerdos explícitamente en lugar de hacerlo sobre la marcha.

• Una vez que el arquitecto entiende el impacto de los componentes arquitectónicos sobre uno o varios atributos de calidad, estaría en capacidad de reemplazar un conjunto de componentes por otro cuando lo considere necesario.

• Una vez que se codifica la relación entre arquitectura y atributos de calidad, es posible construir un protocolo de pruebas que habilitará la certificación por parte de terceros.

1.7. Conclusiones parciales

A partir de los objetivos propuestos para este capítulo, se puede concluir lo siguiente:
A lo largo de este capítulo se ha expuesto los principales aspectos dentro de la disciplina como: concepción de las principales definiciones, tendencias actuales, estilos más novedosos y reinantes en el mundo de las aplicaciones empresariales, exponiendo sus características, ventajas y desventajas. Se analizaron los patrones arquitectónicos y niveles de abstracción de la arquitectura que ayudaron a comprender conceptos como: estilos arquitectónicos y marcos de trabajo. También se ha abordaron temas como la calidad en la Arquitectura de Software definiéndose los principales atributos de calidad y métodos empleados para constatar en que medida la arquitectura cumple con los parámetros de calidad que se establezcan. De igual forma se analizaron las Arquitecturas Orientadas a Servicios como máximo exponente del presente que permitió adoptarlo para aplicarlo en la propuesta de solución ya que brindará una mayor flexibilidad al sistema ante el negocio cambiante que experimentan las empresas hoy en día y a la facilidad de integración que brinda este tipo de arquitectura.

CAPÍTULO 2: PROPUESTA DE SOLUCIÓN

2.1. Introducción

En este capítulo se realiza la propuesta de solución al problema planteado en el diseño teórico de la investigación, la misma viene dada por el artefacto Documento Descripción de Arquitectura que propone la Universidad de las Ciencias Informáticas a emplear en los proyectos productivos. Siendo dicho artefacto de gran importancia ya que proporciona, entre otras cosas, una vista arquitectónica del sistema a todos los implicados en el mismo.

2.2. Descripción de la Arquitectura

2.2.1. Introducción

2.2.1.1. Propósito

Este documento identifica la arquitectura propuesta para el Sistema de Gestión de Inventario a partir las 4+1 vistas arquitectónicas propuestas por la metodología RUP, las mismas facilitan la comprensión de la arquitectura propuesta y aportan argumentos para la identificación de los elementos claves del sistema en desarrollo, proporcionando información al cliente sobre las decisiones arquitectónicas en la construcción del producto.

Además este documento persigue los siguientes propósitos fundamentales:

• Proporcionar una comprensión arquitectónica global del sistema a los stakeholders, mediante el uso de de vistas arquitectónicas, de modo que se muestre los aspectos más significativos del sistema.
• Proporcionar soporte para toma de decisiones arquitectónicamente significativas que deban ser tomadas en el desarrollo del sistema.
• Organizar el desarrollo del sistema.
• Fomentar la reutilización.
• Hacer evolucionar el sistema.

2.2.1.2. Alcance

El alcance del presente documento se extiende a todo el Sistema de Gestión de Inventarios, a todos los integrantes del proyecto encargados de desarrollarlo ya que el mismo influye en la toma de desiciones arquitectónicas, y a todos los implicados en el desarrollo del sistema como: clientes, para que comprendan con suficiente detalle qué se esta haciendo y cómo, de modo que facilite su participación.

2.2.2. Representación Arquitectónica

A partir del estudio de los estilos arquitectónicos realizado en el capítulo 1 y de las características particulares del sistema a desarrollar, siendo el mismo un módulo del ERP cubano; como parte de las decisiones arquitectónicas para definir la propuesta de arquitectura se decidió utilizar para el Sistema de Gestión de Inventarios una Arquitectura Orientada a Servicios. El por qué de esta decisión viene dado por diferentes razones:

• Porque las Arquitecturas Orientadas a Servicios permiten responder más rápidamente a las condiciones cambiantes del negocio empresarial, promoviendo y permitiendo la reutilización, la interconexión de tecnologías existentes en vez de consumir tiempo y costos en la reinvención.

• Un Sistema de Gestión de Inventarios está formado por un conjunto de procesos que se ejecutan y que son reutilizables para otros módulos como el de contabilidad, comerciales, logística, entre otros.

• Por otra parte el Sistema de Gestión de Inventarios, al formar parte del ERP, necesitará intercambiar gran cantidad de información e interactuar con otros módulos del mismo.

• Es un estilo arquitectónico que se basa fundamentalmente en estándares de desarrollo de los servicios web como: XML, WSDL y SOAP, garantizando la interoperabilidad entre distintos servicios y aplicaciones que colaboran con la agilidad del negocio. Tiene la ventaja de ser un modelo arquitectural escasamente acoplado, lo cual le dota de una enorme flexibilidad para la definición, implementación, sustitución, evolución de los servicios y las funcionalidades que contiene.

Las Arquitecturas Orientadas a Servicios básicamente siguen la filosofía de un proveedor-consumidor, auxiliándose de un repositorio UDDI que brinda servicios de directorio, por llamarlo de alguna manera, ya que los proveedores publican las descripciones de los servicios en el repositorio de servicios, que para la solución se propone usar JUDDI que es una implementación libre de UDDI para java, y cuando el consumidor necesite de algún servicio consultará ese repositorio para encontrar la información necesaria para localizar dicho servicio, si existe, para su posterior invocación. La propuesta de solución no estará exenta de ese principio tan básico de este tipo de arquitecturas, que muestra como colaboran las aplicaciones en una Arquitecturas Orientadas a Servicios.

Figura 1. Colaboración en una Arquitecturas Orientadas a Servicios

La propuesta de solución, según el modelo de madurez analizado en el capítulo anterior, estará enmarcada en un primer nivel con elementos del segundo, como son: la UDDI y WS-Security, garantizándose de esta forma la integración del sistema con cualquier otra aplicación o servicio que necesite información de los inventarios, así como la seguridad de los servicios web.

El sistema propuesto estará estructurado en subsistemas y módulos definidos de forma vertical que colaboran entre sí mediante interfaces y una estructuración por niveles lógicos (capas) de forma horizontal posibilitando así el intercambio de datos, al servirse el nivel superior del inferior y este a su vez brinda sus servicios a su inmediato superior, donde la capa de servicios compartidos expondrá los procesos de negocio mediante servicios web.

La estructuración del sistema en capas viene dada por las ventajas que propicia como son: la flexibilidad, escalabilidad, reutilización, capacidad de mantenimiento, entre otras, que coinciden, en gran parte, con las variables que se proponen los autores resolver con dicha solución.

Figura 3. Arquitectura en Capas de la Propuesta SOA

v Capa de Presentación

Esta capa es la encargada de gestionar los datos de entrada y salida mediante las interfaces de usuario, que van a permitir la interacción del sistema con los usuarios potenciales. En otras palabras, maneja el contexto del usuario e interactúa con la capa de negocio donde está implementada toda la lógica de la aplicación.

A partir de los Requisitos no Funcionales de los clientes y de las facilidades que brinda el diseño arquitectónico propuesto, la capa de presentación del Sistema de Gestión de Inventarios puede ser desarrollada en cualquier ambiente, tanto Web como Desktop. Finalmente se decidió desarrollar la capa de presentación sobre la Web haciendo uso del framework MyFaces. De esta forma se busca abaratar la solución mediante el uso de clientes ligeros, los cuales no ejecutan demasiadas labores de procesamiento para la ejecución de la aplicación misma.

Es válido destacar que la decisión de realizar la aplicación web también viene dada por el concepto de no dejar que el cliente realice demasiadas tareas, solo lo necesario para que lleve a cabo su trabajo y dejar que en el lado del servidor se realicen las operaciones importantes: almacenamiento de datos, transacciones, reglas del negocio y la lógica del programa.

Entre las ventajas de las aplicaciones basadas en la web se pueden mencionar:

• Compatibilidad multiplataforma
• Actualizaciones al sistema son más rápidas y fáciles, pues basta con realizar los cambios sobre el servidor donde este corriendo la aplicación y todos los clientes dispondrán de ella una vez que accedan al sistema.
• Acceso inmediato vía cuenta online.
• Facilidad de prueba.
• Menores requerimientos de memoria local.
• Precio ya que consumen menor cantidad de recursos.
• Múltiples usuarios concurrentes.

Por otra parte, si bien es cierto que la arquitectura cliente servidor de la web ha ofrecido muchas ventajas, también es cierto que carece de la riqueza gráfica de las aplicaciones de escritorio que cuentan con controles inteligentes que dan mayor fluidez al trabajo del usuario, esto ha sido resuelto con varias estrategias o tecnologías tales como AJAX, FLASH, Web 2, entre otras. Así que en vez de ir perdiendo fuerza debido a la pobreza en sus interfaces gráficas, la web busca alternativas que le permitan ofrecer todas sus ventajas pero con la posibilidad de ofrecer controles visuales más amigables al trabajo del usuario.

• Patrones

o Presentación
§ Nombre: Modelo – Vista – Controlador (MVC)
§ Problema: La lógica de un interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Si se realiza un diseño ofuscado, es decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la consecuencia será que, cuando se necesite cambiar el interfaz, se tendrá que modificar trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error. (Lago, 2007).
§ Solución: Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos.
§ Elementos del patrón:
ü Modelo: datos y reglas de negocio.
ü Vista: muestra la información del modelo al usuario.
ü Controlador: gestiona las entradas del usuario.

Figura 4. Estructura del patrón Modelo – Vista – Controlador (Lago, 2007)

v Capa de Servicios

Una característica peculiar de las arquitecturas en capas es que las capas inferiores brinden las funcionalidades que necesitan las capas inmediatamente superiores, y a la vez estas, solo puedan acceder a las funcionalidades proporcionadas por las capas inmediatamente inferiores. Visto de esta manera, la capa de servicios es la encargada proporcionar las funcionalidades que necesita la capa de presentación. Además es la responsable de gestionar toda la lógica de negocio de la aplicación y a la vez representa el contenedor lógico donde se ubican los servicios compartidos.

Las transacciones y operaciones de negocio serán realizadas por los servicios web que son los encargados de exponer toda la funcionalidad del sistema. De tal forma que los procesos de negocio del sistema de gestión de inventario serán expuestos mediante servicios web compartidos que podrán ser accedidos por otros servicios o sistemas que necesiten información de los inventarios.

Para el desarrollo de cada servicio web se utilizarán los estándares de la industria, entre ellos los: XML como formato estándar para los datos que se vayan a intercambiar, SOAP como protocolo para el intercambio de datos, WSDL para la descripción de la interfaz pública de los servicios web, WS-Security para la autenticación de los actores y la confidencialidad de los mensajes enviados y finalmente la UDDI para publicar la información de los servicios web y comprobar qué servicios web están disponibles.

Otro aspecto común a todos los servicios que se desarrollen, será crearle una fachada al negocio. Crear esta fachada tiene como objetivo diferenciar los objetos del negocio de los objetos que necesitan los servicios web, ya que es una mala práctica usar los mismos objetos para las dos cosas, debido a que, quien quiera que utilice el servicio web no tiene por qué conocer más allá de la información necesaria para utilizarlo.

A lo largo de esta capa habrá un conjunto de configuraciones y utilidades comunes para todos los servicios que se desarrollen, que se encargan, entre otras cosas, de la interconexión entre las diferentes capas vía XML.

Las Arquitecturas Orientadas a Servicios se distinguen por exponer la lógica del negocio mediante servicios web que deben poder ser accedidos por todas aquellas aplicaciones que necesiten de ellos. La vía más utilizada hoy en día para acceder a estos servicios es a través de un registro UDDI, mediante el cual las aplicaciones pueden publicar y descubrir dichos servicios para su invocación.

Segunda parte

Nota: Es probable que en esta página web no aparezcan todos los elementos del presente documento. Para tenerlo completo y en su formato original recomendamos descargarlo desde el menú en la parte superior

Graduado de Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas en el 2008. Ha trabajado como desarrollador en sistema de gestión hotelera para el ministerio del Turismo Cubano y como arquitecto principal en Sistemas de Gestión de Inventario y Almacenes para el Ministerio del Turismo basados sobre la plataforma J2EE. Ha formado parte del equipo central de arquitectura como arquitecto de integración del proyecto ERP Cubano. Posteriormente se he desempeñado como arquitecto de sistema y de datos de la línea contabilidad financiera del proyecto ERP Cubano. Ha asumido el rol de jefe de la línea de contabilidad financiera y actualmente se desempeña como arquitecto principal de la línea de finanzas del ERP cubano que se encuentra en desarrollo basado en tecnologías libres como PHP y PostgreSQL.

Graduado de Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas en el 2008. Ha trabajado como desarrollador en sistema de gestión hotelera para el ministerio del Turismo Cubano basados en la plataforma J2EE, como arquitecto principal en Sistema de Gestión de Inventario y Almacenes para el Ministerio del Turismo basados sobre la plataforma J2EE, como arquitecto de Sistema del proyecto ERP (Enterprise Resource Planning) cubano, como arquitecto principal del Subsistema Costos y Procesos del Proyecto ERP cubano y como Jefe de Línea del Subsistema Costos y Procesos del ERP cubano, proyecto para obtener un software de gestión, del tipo ERP que se encuentra en desarrollo sobre tecnologías libres como PHP y PostgreSQL.

Arquitectura orientada a servicios para el módulo de inventario del ERP cubano. 1

Autor: Ing. Yoan Arlet Carrascoso Puebla e Ing. Enrique Chaviano Gómez

Tecnología e internet

15-05-2009

En el presente trabajo se expone una propuesta de Arquitectura Orientada a Servicios para el Módulo de Inventario del ERP Cubano, de modo que le posibilite al mismo ser: portable, seguro, escalable e integrable con otros sistemas y que a la vez sea extensible a otros módulos del ERP.