1. TRABAJO DE INVESTIGACION N° 3 PATRONES DE DISEÑO, ANTIPATRONES Y ARQUITECTURAS DE SOFTWARE

JHON HAROLD ARIZA SUAZA – 20132578099LILIANA MORA CHAVEZ - 20142578120

NICOLAS ESTEBAN CARO AREVALO – 20151578063

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA

TECNOLOGIA EN SISTEMATIZACION DE DATOS

BOGOTA 2017

2. Introducción.

Para todo desarrollador es importante saber utilizar herramientas que se encuentra en su entorno para ayudarlo a solucionar problemas para esto, el documento que podrá observar a continuación encontrara patrones de diseño y anti patrones de igual manera encontrara arquitectura de software lo cual es fundamental para la carrera.

3. Patrones de Diseño de Software

3.1. Definición

Los patrones de diseño son soluciones para problemas típicos y recurrentes que nos podemos encontrar a la hora de desarrollar una aplicación.

Aunque nuestra aplicación sea única, tendrá partes comunes con otras aplicaciones: acceso a datos, creación de objetos, operaciones entre sistemas etc. En lugar de reinventar la rueda, podemos solucionar problemas utilizando algún patrón, ya que son soluciones probadas y documentadas por multitud de programadores.

Si queremos desarrollar aplicaciones robustas y fáciles de mantener, debemos cumplir ciertas "reglas". Lo pongo entre comillas porque aunque estas reglas de diseño son recomendables (muy recomendables), no son obligatorias. Siempre podemos decidir no aplicarlas. Aunque si no lo hacemos, hay que ser conscientes de la razón de no aplicarlas y de sus consecuencias.

Los patrones de diseño nos ayudan a cumplir muchos de estos principios o reglas de diseño. Programación SOLID, control de cohesión y acoplamiento o reutilización de código son algunos de los beneficios que podemos conseguir al utilizar patrones.

Para Christopher Alexander: “Cada patrón escribe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces”.

https://www.genbetadev.com/metodologias-de-programacion/patrones-de-diseno-que-son-y-por-que-debes-usarlos

Historia

La idea de patrón de diseño que utilizamos en ingeniería de software viene de la arquitectura. En 1977 se publicó “A Pattern language: Towns Buildin” de Cristopher Alexander y otros.

Según Alexander, cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces si hacerlo siquiera dos veces de la misma forma. Los patrones de diseño de Software nacen en los 80´s son Kent Beck y Ward Cunningham. Que discutían patrones para Smalltalk.

3.2. Características

Solución a un problema Es un concepto probado La solución no es obvia; muchas técnicas de solución de problemas tratan de hallar

soluciones por medio de principios básicos Describen participantes y relaciones entre ellos; no solo describen módulos sino

estructuras y mecanismos complejos Repetición, adaptabilidad y utilidad Proporciona un vocabulario común a los desarrolladores Se logra mejorar diseños ya que sabemos de antemano los pros y contras que pueda

tener una solución planteada

3.3. Ventajas y Desventajas

Ventajas

Podrás ahorrar tiempo Establecen un lenguaje común Incorpora objetivos de calidad El software construido es más fácil de comprender, mantener y extender

Desventajas

Genera mucho tiempo en el desarrollo de los sistemas Modelo costoso Requiere experiencia en la identificación de riesgos El uso de un patrón no se refleja claramente en el código Sobrecarga de trabajo a la hora de implementar

Conceptos equivocados sobre qué son los patrones de diseño

“Un patrón es una solución a un problema en un contexto”. Si bien esta es una definición de Christopher Alexander, hay algunos factores adicionales a considerar: - Recurrencia: lo que hace relevante a la solución para situaciones diferentes que la inmediata. - Enseñanza: debe proveer el entendimiento suficiente como para personalizar la solución ofrecida al nuevo problema.

- Nombre: debe proveer un nombre por el cual referirse al patrón.

Cualquier definición que indique las partes constituyentes de un patrón debe expresar recurrencia, enseñanza, y nombre adicionalmente al problema, solución y contexto.

• “Los patrones son simplemente jerga, reglas y trucos de programación”. Comparado otras áreas de la informática, los patrones introducen relativamente pocos términos nuevos. Un

buen patrón es intrínsicamente accesible a su audiencia. Puede utilizar la jerga del dominio en cuestión, pero es escasa la necesidad de utilizar terminología específica de patrones. Tampoco son reglas que se pueden aplicar ciegamente, ya que la componente de enseñanza debería impedir esta tendencia. • “Los patrones necesitan herramientas o soporte metodológico para ser efectivos”. Uno de los grandes beneficios de los patrones es que pueden ser aplicados directamente, sin ningún tipo de soporte.

3.4 Tipos de Patrones

Tipos

Según el nivel de abstracción los patrones de diseño pueden clasificarse de la siguiente forma:

• Patrones arquitectónicos. Centrados en la arquitectura del sistema. Definen una estructura fundamental sobre la organización del sistema. Proveen un conjunto predefinido de subsistemas, cuáles son sus responsabilidades y como se interrelacionan.

• Patrones de diseño. Esquemas para refinar los subsistemas o componentes de un sistema de software, o sus relaciones. Describen una estructura recurrente y común de componentes comunicantes que resuelven un problema de diseño dentro de un contexto. Ejemplo: el patrón singleton asegura que exista sólo una instancia de una determinada clase.

• Patrones de codificación o modismos (idioms). Patrones que ayudan a implementar aspectos particulares del diseño en un lenguaje de programación específico. Ejemplo: en Java implementar una interface en una clase anónima.

Los patrones arquitectónicos podrían considerarse estrategias de alto nivel que abarcan componentes a gran escala, propiedades y mecanismos del sistema. Tienen implicancias muy amplias que afectan tanto a la estructura como a la organización del sistema. Los patrones de diseño son tácticas de medio nivel para profundizar en la estructura y comportamiento de ciertos componentes y sus relaciones. Los patrones de diseño no influencian la estructura del sistema sino que definen micro-arquitecturas para los subsistemas y componentes. Por último, los modismos son técnicas específicas del paradigma y lenguaje de programación que complementan detalles de bajo nivel (internos o externos) de la estructura de un componente.

Clasificación

Creacionales; Solucionan problemas de creación de instancias. Nos ayudan a encapsular y atraer dicha creación

Los patrones creacionales están basados en dos conceptos:

Encapsular el conocimiento acerca de los tipos concretos que nuestro sistema utiliza. Estos patrones normalmente trabajarán con interfaces, por lo que la implementación concreta que utilicemos queda aislada.

Ocultar cómo estas implementaciones concretas necesitan ser creadas y cómo se combinan entre sí.

Estructurales; solucionan problemas de composición de clase y objetos

Comportamiento; se define como patrones de diseño de Software que ofrecen soluciones respeto a la iteración y responsabilidades entre clases y objetos así como los algoritmos que encapsulan

Comportamiento; En este último grupo se encuentran la mayoría de los patrones, y se usan para gestionar algoritmos, relacionales y responsables entre objetos.

Patron Creacional

Los patrones creacionales más conocidos son:

Abstract Factory: Nos provee una interfaz que delega la creación de un conjunto de objetos relacionados sin necesidad de especificar en ningún momento cuáles son las implementaciones concretas.

Factory Method: Expone un método de creación,  delegando en las subclases la implementación de este método.

Builder: Separa la creación de un objeto complejo de su estructura, de tal forma que el mismo proceso de construcción nos puede servir para crear representaciones diferentes.

Singleton: limita a uno el número de instancias posibles de una clase en nuestro programa, y proporciona un acceso global al mismo.

Prototype: Permite la creación de objetos basados en “plantillas”. Un nuevo objeto se crea a partir de la clonación de otro objeto.

Patrones estructurales

Son patrones que nos facilitan la modelización de nuestro software especificando la forma en la que unas clases se relacionan con otras.

Los patrones estructurales especifican la forma en que unas clases se relacionan con otras.CLIC PARA TUITEAR

Los patrones estructurales que definió la Gang of Four:

Adapter: Permite a dos clases con diferentes interfaces trabajar entre ellas, a través de un objeto intermedio con el que se comunican e interactúan.

Bridge: Desacopla una abstracción de su implementación, para que las dos puedan evolucionar de forma independiente.

Composite: Facilita la creación de estructuras de objetos en árbol, donde todos los elementos emplean una misma interfaz. Cada uno de ellos puede a su vez contener un listado de esos objetos, o ser el último de esa rama.

Decorator: Permite añadir funcionalidad extra a un objeto (de forma dinámica o estática) sin modificar el comportamiento del resto de objetos del mismo tipo.

Facade: Una facade (o fachada) es un objeto que crea una interfaz simplificada para tratar con otra parte del código más compleja, de tal forma que simplifica y aísla su uso. Un ejemplo podría ser crear una fachada para tratar con una clase de una librería externa.

Flyweight: Una gran cantidad de objetos comparte un mismo objeto con propiedades comunes con el fin de ahorrar memoria.

Proxy: Es una clase que funciona como interfaz hacia cualquier otra cosa: una conexión a Internet, un archivo en disco o cualquier otro recurso que sea costoso o imposible de duplicar.

Patrones de comportamiento

En este último grupo se encuentran la mayoría de los patrones, y se usan para gestionar algoritmos, relaciones y responsabilidades entre objetos.

Los patrones de comportamiento gestionan algoritmos, relaciones y responsabilidades entre objetos.CLIC PARA TUITEAR

Los patrones de comportamiento son:

Command: Son objetos que encapsulan una acción y los parámetros que necesitan para ejecutarse.

Chain of responsibility: se evita acoplar al emisor y receptor de una petición dando la posibilidad a varios receptores de consumirlo. Cada receptor tiene la opción de consumir esa petición o pasárselo al siguiente dentro de la cadena.

Interpreter: Define una representación para una gramática así como el mecanismo para evaluarla. El árbol de sintaxis del lenguaje se suele modelar mediante el patrón Composite.

Iterator: Se utiliza para poder movernos por los elementos de un conjunto de forma secuencial sin necesidad de exponer su implementación específica.

Mediator: Objeto que encapsula cómo otro conjunto de objetos interactúan y se comunican entre sí.

Memento: Este patrón otorga la capacidad de restaurar un objeto a un estado anterior

Observer: Los objetos son capaces de suscribirse a una serie de eventos que otro objetivo va a emitir, y serán avisados cuando esto ocurra.

State: Permite modificar la forma en que un objeto se comporta en tiempo de ejecución, basándose en su estado interno.

Strategy: Permite la selección del algoritmo que ejecuta cierta acción en tiempo de ejecución.

Template Method: Especifica el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan el comportamiento real.

Visitor: Permite separar el algoritmo de la estructura de datos que se utilizará para ejecutarlo. De esta forma se pueden añadir nuevas operaciones a estas estructuras sin necesidad de modificarlas.

4. Anti patrones

4.1. Definición

Los Anti patrones, por su parte, se corresponden a las malas experiencias ya que reúnen soluciones que han producido efectos negativos. Los Anti patrones proveen dos soluciones: la problemática (aquélla con el impacto negativo), y la reautorizada (aquélla que transforma la situación negativa en una más saludable).

Los anti-patrones, también llamados trampas, son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una auditoria.

El término anti-patrón se origina como una contra parte al término patrón, acuñado en arquitectura de software, para definir las buenas prácticas de programación, diseño o gestión de sistemas. De tal manera podríamos hablar de que un sistema “bien hecho” está lleno de patrones, y debería carecer de anti-patrones; al menos ese sería un sistema ideal.

Si aplicamos una analogía social, podríamos decir que si a tú, amigo lector, no caes en el anti-patrón (nombrémosle estereotipos) de criminal, terrorista, pervertido, drogadicto, brujo, dictador, y similares, entonces podríamos afirmar que no eres una mala persona. Lo cual no implica, que seas buena; para serlo deberías, no sólo no encajar en los anti-patrones mencionados, sino además, cumplir con uno o más patrones (llamémosle cualidades): honesto, trabajador, buen hijo y/o buen padre, etcétera.

Los anti-patrones en arquitectura de software, son similares a sus análogos sociales, soluciones negativas, acciones que presentan mayores problemas que soluciones. Sin embargo, representan un camino fácil y rápido. Pero continuando con la analogía, podríamos pensar que si necesitas dinero, tienes dos opciones: el patrón (buen comportamiento) trabajar arduamente o el anti-patrón (rápido y con consecuencias a largo plazo) robar un banco.

El mismo concepto se aplica fácilmente en ingeniería, y en otras actividades donde esté presente el esfuerzo humano. Así, anti-patrones como reinventar la rueda, la cosa, el programa Dios, casarse con el diablo, la tubería de la estufa, corn cob (juntos pero no revueltos), etcétera. Dejan la enseñanza de cuál es la mejor forma de no hacer sistemas de cómputo.

En la elaboración de un sistema, intervienen al menos, diversos actores: arquitectos de software, administradores de proyecto y desarrolladores. Para cada uno de ellos, existen anti-patrones que describen comportamientos y soluciones incorrectas Los anti-patrones (una vez conocidos) constituyen para cada uno de los actores involucrados, descripciones de problemas recurrentes en la construcción de software, les proporcionan un vocabulario común para identificar problemas y discutir posibles soluciones y les sugieren pasos para la re-ingeniería, y re-organización estructural de un sistema.

4.2. Características

The Blob (“Clases gigantes”): Este antipatrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados.

Lava Flow (“Código muerto”): Este antipatrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y, al ser expuesto, sus características no pueden ser modificadas.

Poltergeists (“No se sabe bien lo que hacen algunas clases”): Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema.

Golden Hammer (“Para un martillo todo son clavos”): Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc. para cualquier problema o situación incluso cuando es evidente que no va ser útil.

Spaghetti Code (“Muchos if ó switch”): se refiere a un código mal estructurado. Cut & Paste programming (“Cortar y pegar código”).

4.3 Ventajas y Desventajas

Desventajas

Mal uso de flujos Confusion entre eventos y tareas Uso de mecanismo de secuencia de flujo

4.4 Los tipos de anti patrones que hay son tres:

Anti patrones de desarrollo de software Anti patrones de arquitectura de software Antipatrones de gestión de proyectos de software.

Anti-patrones de Codificación

Revisemos algunas técnicas para codificación incorrecta de software.

1. Lava Flow. Algo así como “programar al estilo volcán”. Es construir grandes cantidades de código de manera desordenada, con poca documentación y poca claridad de su función en el sistema. Conforme el sistema avanza en su desarrollo, y crece, se dice que estos flujos de lava se solidifican, es decir, se vuelve mucho más complicado corregir los problemas que originan, y el desorden va creciendo geométricamente. Esto se hace patente cuando:

1. Se declaran variables no justificadas.

2. Se construyen clases o bloques de código muy grande y complejo sin documentar, o que

no se relacionan claramente con la arquitectura.

3. Usando un inconsistente y difuso estilo de evolución de una arquitectura. 4. Cuando en el sistema existen muchas áreas con código por terminar o reemplazar. 5. Y claro, cuando dejamos código sin uso abandonado; interfaces o componentes obsoletos en el cuerpo del sistema. Los resultados son predecibles: conforme los flujos se endurecen y solidifican (se escribe código y pasa el tiempo), rápidamente se vuelve imposible documentar el código o entender su arquitectura lo suficientemente bien como para hacer mejoras.

2. The God.- Un programa omnipresente y desconocido. Aquel sistema donde una sola clase ó modulo (la función main o equivalente) hace todo. Así que el programa es un solitario y único archivo de muchísimas líneas. En consecuencia, tenemos un código desorganizado y fuertemente interdependendiente.

3. Golden Hammer.- También conocida como la técnica de la barita mágica. Es un vicio relacionado con aferrarse a un paradigma, para solucionar todos los problemas que se nos presenten al desarrollar sistemas, como por ejemplo, siempre querer usar el mismo lenguaje de programación para todos los desarrollos, sea o no conveniente. Es el caso de enamorarnos de .Net, de Java, de PHP. Es importante comprender que cada uno tiene capacidades y limitaciones en aplicaciones particulares. En consecuencia se trata de, uno, el uso obsesivo de una herramienta, y dos, una terquedad de los desarrolladores para usar un paradigma de solución en todos los programas. Lo cual conlleva ocasionalmente a consumir mucho más esfuerzo para resolver un problema.

4. Spaghetti Code.- Se dice de una pieza de código fuente no documentado, donde cualquier pequeño movimiento convulsiona la estructura completa del sistema. En expresión coloquial: codificar con las... los “pies”. A diferencia del estilo volcán, donde la crítica es a la forma en que el sistema crece (se anexan módulos), aquí la crítica es a la forma en que se escribe cada una de las líneas, desde la indentación hasta el lenguaje o lenguajes utilizados y su interacción. Ya en el contexto spaghetti, si mezclamos más de un lenguaje de programación en el mismo archivo, el spaghetti es más sabroso. La receta clásica con lenguajes scripts del tipo PHP con HTML y sazonado con JavaScript, ¡es delicioso! (entiéndase un enorme problema). El origen del spaghetti es regularmente un programa creado para hacer una pequeña demostración, que termina, en un dos por tres,

trabajando como producto final. Donde está el problema, bien podemos citar lo siguiente como ejemplos: 1. 50% del tiempo de mantenimiento se invierte en entender al sistema original. 2. El spaghetti es causa directa del síndrome del programador desesperado: ¡mejor reescribimos todo el programa! 3. Y obviamente el reuso es imposible. Pero si para colmo, tenemos sólo un chef, o en el contexto un “Programador Solitario”. ¿Quién era ese hombre tras el monitor? Que no está disponible para explicarnos su receta. Simplemente se tienen problemas, muchos problemas.

5. Fantasmas.- Demasiadas clases en un programa o tablas en una base de datos. Varias clases o tablas con mínimas responsabilidades. Muchas veces se utiliza para disfrazar la presencia del anti-patrón The God. Se colocan clases inútiles, que disfrazan el hecho que todo el sistema se encuentra construido en uno, o unos cuantos archivos, módulos o clases. Este anti-patrón sugiere un modelo de análisis y/o diseño inestable: el diseño no coincide con la implementación, y por ello es imposible hacer extensiones al sistema, porque entre tanto “fantasma”, encontrar los elementos relevantes es imposible.

Anti patrones de desarrollo de software

The Blob: Este anti patrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados. El tamaño de estos objetos perjudica su tiempo de carga.

Lava Flow: Este anti patrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y al ser expuesto, sus características no pueden ser modificadas – como un flujo de lava cuando se solidifica.

Poltergeist: Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema. Suelen identificarse por su nombre: “start_”, “manager_”. La solución para evitarlos es eliminarlos y poner su funcionalidad en la clase a la que invocan.

Golden Hammer: Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc.. para cualquier problema o situación incluso cuando es evidente que no va ser útil.

Anti patrones de arquitectura de software

Stovepipe enterprise: Este mal se da cuando disponemos de varios sistemas aislados entre si – lo que se llama islas de automatización – y que no pueden colaborar entre si para desarrollar otros sistemas más grandes y útiles para la organización. Sucede cuando no se dispone de una planificación de los sistemas y no se ha tenido en cuenta la ínter operatibilidad.

Stovepipe system: Este anti patrón se refiere a 2 posibles circunstancias:a) Un sistema que no puede ínter operar con el resto de los sistemas de una organización.

b) Un sistema heredado que un ensamblaje de pequeños sistemas que están tan unidos entre sí que no es posible diferenciar cada uno de ellos, imposibilitando su actualización, refactorización etc…

Vendor Lock-In: El anti patrón “Vendor Lock-in” sucede cuando dependemos de una arquitectura, plataforma o tecnología. Esta dependencia puede tener unas consecuencias muy negativas puesto que nuestros desarrollos pueden ser dependientes de características proporcionadas por terceros, pueden verse “rotos” por el cambio de las características de estas tecnologías, etc…

Antipatrones de gestión de proyectos de software Analysis Paralysis: Parálisis del Análisis (en inglés analysis paralysis) sucede

cuando se pretende descubrir y modelar todos y cada uno de los detalles de un sistema informático en una fase inicial, invirtiendo un tiempo excesivo con la intención de no regresar a la etapa de análisis. Las dos creencias que provocan este fallo son la creencia de que se ha de codificar solo cuando se ha terminado el análisis y que una vez que hemos comenzado a codificar no se debe volver al análisis.

Corncob: Es habitual que en el desarrollo de un proyecto de un proyecto de software, ciertas personas dificulten su desarrollo. Se ha calculado que al menos la mitad del tiempo en un proceso de desarrollo de software se invierte en la comunicación entre personas. Las dificultades de comunicación son debidos al stress, a la personalidad,a la falta de preparación, negativa a recibir formación etc…Reinvent the wheel: Este es un antipatrón obvio; en muchas ocasiones por falta de un estudio de las tecnologías, diseños o posibilidades existentes se pierde mucho dinero y tiempo desarrollando cosas que ya estaban en el mercado o que ya se encontraban disponibles.

5 Arquitectura de Software

5.1. Definición

Arquitectura de software. La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construcción de un software, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación. Es considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto que establecen la estructura, funcionamiento e interacción entre las partes del software.

Componentes

La arquitectura de software se compone por: clientes y servidores. bases de datos. filtros. Niveles en sistemas jerárquico.

Interacciones

Entre los componentes de la arquitectura de software existe un conjunto de interacciones entre las que sobresalen:

Llamadas a procedimientos. Comportamiento de variables. Protocolos cliente servidor. Transmisión asíncrona de eventos.

5.2 Historia

Todavía no se ha escrito una historia aceptable de la AS. Desde que Mary Shaw o David Garlan reseñaran escuetamente la prehistoria de la especialidad a principios de los 90, los mismos párrafos han sido reutilizados una y otra vez en la literatura, sin mayor exploración de las fuentes referidas en la reseña primaria y con prisa por ir al grano, que usualmente no es de carácter histórico. En este estudio se ha optado, más bien, por inspeccionar las fuentes más de cerca, con el objeto de señalar las supervivencias y las resemantizaciones que han experimentado las ideas fundadoras en la AS contemporánea, definir con mayor claridad el contexto, entender que muchas contribuciones que pasaron por complementarias han sido en realidad antagónicas y comprender mejor por qué algunas ideas que surgieron hace cuatro décadas demoraron un cuarto de siglo en materializarse.

Esta decisión involucra algo más que el perfeccionamiento de la lectura que pueda hacerse de un conjunto de acontecimientos curiosos. Las formas divergentes en que se han interpretado dichas ideas, después de todo, permiten distinguir corrientes de pensamiento diversas, cuyas diferencias distan de ser triviales a la hora de plasmar las ideas en una metodología. Todo lo que parece ser un simple elemento de juicio, no pocas veces implica una disyuntiva. Situar las inflexiones de la breve historia de la AS en un contexto temporal, asimismo, ayudará a comprender mejor cuáles son sus contribuciones perdurables y cuáles sus manifestaciones contingentes al espíritu de los tiempos y a las modas tecnológicas que se han ido sucediendo.

Si bien la AS acostumbra remontar sus antecedentes al menos hasta la década de 1960, su historia no ha sido tan continua como la del campo más amplio en el que se inscribe, la ingeniería de software [Pfl02] [Pre01]. Después de las tempranas inspiraciones del legendario Edsger Dijkstra, de David Parnas y de Fred Brooks, la AS quedó en estado de vida latente durante unos cuantos años, hasta comenzar su expansión explosiva con los manifiestos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado [PW92]. Puede decirse que Perry y Wolf fundaron la disciplina, y su llamamiento fue respondido en primera instancia por los miembros de lo que podría llamarse la escuela estructuralista de Carnegie Mellon: David Garlan, Mary Shaw, Paul Clements, Robert Allen.

Se trata entonces de una práctica joven, de apenas unos doce años de trabajo constante, que en estos momentos experimenta una nueva ola creativa en el desarrollo cabal de sus

técnicas en la obra de Rick Kazman, Mark Klein, Len Bass y otros metodólogos en el contexto del SEI, en la misma universidad. A comienzos del siglo XXI comienzan ya a discernirse tendencias, cuyas desavenencias mutuas todavía son leves: al menos una en el sur de California (Irvine y Los Angeles) con Nenad Medvidovic, David Rosenblum y Richard Taylor, otra en el SRI de Menlo Park con Mark Moriconi y sus colegas y otra más vinculada a las recomendaciones formales de la IEEE y los trabajos de Rich Hilliard. Hoy se percibe también un conjunto de posturas europeas que enfatizan mayormente cuestiones metodológicas vinculadas con escenarios y procuran inscribir la arquitectura de software en el ciclo de vida, comenzando por la elicitación de los requerimientos. Antes de Perry y Wolf, empero, se formularon ideas que serían fundamentales para la disciplina ulterior. Comencemos entonces por el principio, aunque siempre cabrá la posibilidad de discutir cuál puede haber sido el momento preciso en el que todo comenzó.

Cada vez que se narra la historia de la arquitectura de software (o de la ingeniería de software, según el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnológica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier manera [Dij68a]. Dijkstra, quien sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas y sugería seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la noción de sistemas operativos organizados en capas que se comunican sólo con las capas adyacentes y que se superponen “como capas de cebolla”. Inventó o ayudó a precisar además docenas de conceptos: el algoritmo del camino más corto, los stacks, los vectores, los semáforos, los abrazos mortales. De sus ensayos arranca la tradición de hacer referencia a “niveles de abstracción” que ha sido tan común en la arquitectura subsiguiente. Aunque Dijkstra no utiliza el término arquitectura para describir el diseño conceptual del software, sus conceptos sientan las bases para lo que luego expresarían Niklaus Wirth [Wir71] como stepwise refinement y DeRemer y Kron [DK76] como programming-in-the large (o programación en grande), ideas que poco a poco irían decantando entre los ingenieros primero y los arquitectos después.

En la conferencia de la NATO de 1969, un año después de la sesión en que se fundara la ingeniería de software, P. I. Sharp formuló estas sorprendentes apreciaciones comentando las ideas de Dijkstra: Pienso que tenemos algo, aparte de la ingeniería de software: algo de lo que hemos hablado muy poco pero que deberíamos poner sobre el tapete y concentrar la atención en ello. Es la cuestión de la arquitectura de software. La arquitectura es diferente de la ingeniería. Como ejemplo de lo que quiero decir, echemos una mirada a OS/360. Partes de OS/360 están extremadamente bien codificadas.

5.3 Características

La arquitectura de software forma la columna vertebral para construir un sistema de software,es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del software.Además es un modelo abstracto reutilizable[1] que puede transferirse de un sistema a otro y que

representa un medio de comunicación y discusión entre participantes del proyecto,permitiendo así la interacción e intercambio entre los desarrolladores con el objetivo final de establecer el intercambio de conocimientos y puntos de vista entre ellos.

Tipos de arquitecturas

Para utilizar la arquitectura de software se sigue un conjunto de patrones arquitectónicos,entre los cuales podemos encontrar:

Cliente-Servidor Blackboard. Modelo entre capas. Intérprete. Orientado a servicios.

Niveles de un diseños de software

El diseño de software tiene varios niveles los cuales están relacionados entre sí,cada nivel tiene sus propios problemas,técnicas de análisis y componentes los que pueden ser simples o complejos,reglas de composición las cuales permiten construir componentes complejos.

Modelos de la arquitectura de software

La arquitectura de software cuenta con varios modelos,ellos son:

Modelos estructurales

Son similares a la vista estructural, pero su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición. Los modelos de framework a menudo se refieren a dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes específicos, como PRISM.

Modelos dinámicos

Enfatizan la cualidad conductual de los sistemas,“Dinámico” puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de la computación, tales como valores cambiantes de datos.

Modelos de proceso

Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa construcción. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar arquitecturas.

El ciclo de desarrollo de la arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, esta dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo.

A continuación se describen dichas etapas.

Requerimientos. La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones.

Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías por que están “de moda”.

Documentación. Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama.

Evaluación. Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.

5.5. Ejemplos de arquitecturas de software

Cliente servidor: es un modelo de diseño de software en el que tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola

computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

Ejemplo:

Implementar reglas comerciales en la aplicación de cliente-servidor de ejemplo Visual Studio .NET 2003 La aplicación de cliente-servidor de ejemplo utiliza un servidor de Automatización personalizado para reforzar las reglas comerciales. Esta arquitectura, conocida como el modelo de tres capas, permite la implementación de las reglas comerciales en la capa del medio, aparte de los datos actuales y aparte de la interfaz del cliente. Hay muchas aplicaciones y muchas bases de datos que pueden utilizar el mismo conjunto de reglas comerciales, codificado y mantenido en una única ubicación.  El servidor de Automatización personalizado en la aplicación de cliente-servidor de ejemplo es Bizrules. El proyecto para el servidor de Automatización es Bizrules.pjx y la clase se define en Bizrules.pjx:

La programación por capas:  es un modelo de desarrollo software en el que el objetivo primordial es la separación (desacoplamiento) de las partes que componen un sistema software o también una arquitectura cliente-servidor: lógica de negocios capa de presentación y capa de datos. De esta forma, por ejemplo, es sencillo y mantenible crear diferentes interfaces sobre un mismo sistema sin requerirse cambio alguno en la capa de datos o lógica.

Modelo vista controlador: es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario.12 Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

Ejemplo

El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)

El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.

El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.

El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.

La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

5.6 ESTILOS ARQUITECTONICOS

Sistemas basados en Flujos de Datos:

Descripción: la arquitectura de flujo de datos, todo el sistema de software es vista como una serie de transformaciones en piezas consecutivas o conjunto de datos de entrada, donde los datos y las operaciones son independientes entre sí. En este enfoque, los datos de entrada en el sistema y luego fluye a través de la que los módulos a la vez hasta que se asignan a un destino final (salida o un almacén de datos).

Las conexiones entre los componentes o módulos pueden implementarse como corriente de E / S, E / S tampones, hilo, u otros tipos de conexiones. Los datos se pueden volar en la topología gráfico con los ciclos, en una estructura lineal sin ciclos, o en una estructura de tipo árbol. [1]

Estructura (Diagrama):

Características:

Reutilización

Modificabilidad

Serie de transformaciones sobre elementos sucesivos de datos de entrada

Se Utiliza: Para lograr cualidades de reutilización y modificabilidad. Es adecuado para aplicaciones que involucran una serie bien definida de las transformaciones de datos independientes o cálculos en la entrada y la salida ordenada definida como compiladores y aplicaciones de procesamiento de datos de la empresa.

Restricciones Los datos entran al sistema y luego navegan a través de componentes al mismo tiempo, antes de ser asignados a su destino final.

Sistemas Call/Return

Descripción:

Los sistemas "Call and Return" han sido el estilo arquitectónico dominante en los últimos 30 años. Se caracterizan por ver al sistema como una serie de llamadas a procedimientos o funciones, forma en la que interactúan los componentes del mismo.

Estructura (Diagrama):

Características:

Sistemas orientados a objetos

Capas jerárquicas

Principal-sub rutinas

Se Utiliza:

Estos estilos arquitecturales están enfocados al flujo de control entre subsistemas los cuales tienen toda la responsabilidad para controlar, iniciar y parar los otros subsistemas.

Ventajas y desventajas:

Ventajas: uso a gran escala, todas las ventajas del encapsulamiento (bien usado) y el información hiding, correspondencia en los objetos del dominio con objetos del mundo real.

Desventaja principal: complejidad del código llevada al diseño.

Restricciones:

Los objetos son responsables de la integridad de sus representaciones por lo cual dicha representación es ocultada al resto de los objetos

La interacción está limitada a las capas adyacentes.

5.7. Lenguaje de descripción arquitecturas:

Java,c,c#,c++.

Sistemas de Componentes Independientes

Descripción:

Es un estilo de diseño para aplicaciones compuestas de componentes individuales. Pone énfasis en la descomposición del sistema en componentes lógicos o funcionales que tienen interfaces bien definidas. Define una aproximación de diseño que usa componentes discretos, los que se comunican a través de interfaces que contienen métodos, eventos y propiedades.

Estructura (Diagrama):

Características:

Procesos de comunicación

Cliente / Servidor

Sistemas de Acontecimientos o Eventos

Se Utiliza:

Par su utilización es indispensable la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, este adopta una interfaz proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interfaz puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados.

Ventajas y desventajas:

Ventajas:

Menor tiempo de desarrollo del software

Reutilización de componentes software

Facilitar la combinación y configuración dinámica de componentes existentes

Desventajas:

Evaluación de los componentes candidatos

Adaptación de los componentes seleccionados

Integración e interconexión de los componentes

Restricciones:

Consiste de un número de objetos o procesos independientes que se comunican a través de mensajes. La modificabilidad se logra por el desacoplamiento en varias porciones de procesamiento. Solo se envían mensajes entre los objetos, sin tener control directamente

Lenguaje de descripción arquitecturas:

Java, .NET

Sistemas Centrados en Datos

Descripción: Un almacén de datos se encuentra en el centro de esta arquitectura, otro componente tiene acceso a él y cuentan con la opción de gestionar los datos de ese almacén. El software cliente tiene acceso a un almacén central, en algunos casos este es pasivo, el software cliente accede a los datos independientemente de cualquier cambio hecho en los datos o las acciones de otro software cliente.

Una variación de este enfoque transforma el depósito en un pizarrón que envía notificaciones al software cliente cuando cambian datos de interés para el cliente.

Estructura (Diagrama):

Características:

Bases de Datos

Sistemas de HiperTexto

Sistemas de pizarra

Se Utiliza: Estos sistemas se han usado en aplicaciones que requieren complejas interpretaciones de proceso de señales (reconocimiento de patrones, reconocimiento de habla, etc), o en sistemas que involucran acceso compartido a datos con agentes débilmente acoplados. También se han implementado estilos de este tipo en procesos en lotes de base de datos y ambientes de programación organizados como colecciones de herramientas en torno a un repositorio común.

Ventajas y desventajas:

Ventajas:

Proporciona integridad de los datos, copia de seguridad y funciones de restauración.

Proporciona escalabilidad y capacidad de reutilización de agentes, ya que no tienen comunicación directa entre sí.

Reduce la sobrecarga de datos transitorios entre los componentes de software.

Desventajas

Alta dependencia entre la estructura de datos del almacén de datos y sus agentes.

Los cambios en la estructura de datos altamente afectan los clientes.

Evolución de los datos es difícil y costoso.

Costo de trasladar los datos sobre la red de datos distribuidos.

Restricciones: el estilo de pizarra y las referencias a repositorios son más bien convencionales o implícitos; tampoco lo hacen las estrategias mayores alternativas de la industria.

Sistemas Centrados en Tuberías y Filtros

Descripción: Un sistema de transformación de corrientes de datos o la transmisión en transductores independientes. Transforma los datos de la corriente de datos de entrada, lo procesa, y escribe el flujo de datos transformado en un tubo para el siguiente filtro de procesar. Funciona de manera gradual, en el que comienza a trabajar tan pronto como llegan los datos a través del tubo conectado.

Filtro Activo: Permite tuberías conectadas a extraer los datos y empujar hacia afuera los datos transformados. Opera con tubería pasiva, que proporciona mecanismos de leer / escribir para tirar y empujar. Este modo se utiliza en la tubería UNIX y mecanismo de filtro.

Filtro Pasivo: Permite tuberías conectadas a empujar y tirar datos de salida de datos. Opera con tubo activo, que extrae datos de un filtro y empuja los datos al siguiente filtro. Se debe proporcionar leer mecanismos /escritura.

Estructura (Diagrama):

Características:

Existen dos tipos de filtro: pasivo y activo

Deben ser identidades independientes

Puede no compartir estados con filtros

Los filtros no conocen la identidad de sus vecinos

Especificar cuándo se Utiliza:

Para el procesamiento de datos excesivo

Para reutilización y simplificación del sistema

Se utiliza para la ejecución, tanto secuencial y paralela

Ventajas y desventajas:

Ventajas: Gracias al invariante de ocultación es posible reemplazar la Implementación sin que afecte a los clientes

Desventajas: Para invocar métodos de un objeto se debe conocer su identidad y para efectos colaterales

Restricciones:

No se puede utilizar para interacciones dinámicas

Si no existe un común denominador bajo para la transmisión de datos en formatos ASCII

Sobrecarga de transformación de datos entre los filtros

Difícil de configurar esta arquitectura de forma dinámica

Sistemas abstractos de Datos y OO

Descripción: Las representaciones de los datos y las operaciones están encapsulados en un tipo abstracto de datos u objeto, de acuerdo los componentes son objetos y Las invocaciones de métodos son los conectores

Estructura (Diagrama):

Características:

Basada en abstracción de datos y organización OO

Los componentes son Objetos o TADs

Los objetos interactúan a través de invocación de funciones y procedimientos

Algunos sistemas permiten ejecución concurrente de tareas; otras permiten objetos con múltiples interfaces.

Es posible cambiar la implementación de objetos sin afectar a los clientes.

Los diseñadores pueden descomponer el problema en colecciones de agentes interactuando

Se Utiliza:

Debe describir los roles abstractos que juegan los componentes

Restricciones

Los objetos son responsables de la integridad de sus representaciones Dicha representación es ocultada al resto de los objetos

Lenguaje de descripción arquitecturas

Sistemas invocación implícita basada en eventos

Descripción:

En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento.

La ocurrencia de un evento causa la invocación “implicita” de procedimientos en otros módulos.

Los componentes son los módulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos

Los conectores incluyen llamadas a procedimientos tradicionales así como el ligado de eventos con llamadas a procedimientos

Estructura (Diagrama):

Características:

Comunicación basada en la propagación de eventos

Procesos publicadores/suscriptores

El bus gestiona la comunicación y garantiza la notificación de eventos a los procesos interesados

Se Utiliza:

Los generadores de eventos no saben cuáles componentes se afectarán por el evento. Ejemplos de este estilo son los sistemas de gestión de bases de datos cuando aseguran la consistencia de los datos, las aplicaciones con interfaces de usuarios al separar la representación de los datos de las aplicaciones que la gerencia. 

Ventajas y desventajas:

Ventajas

Provee un robusto soporte de reusabilidad

Facilita la evolución del sistema

Desventajas

Pérdida de control en el comportamiento del sistema

Problemas en el intercambio de datos

Es difícil asegurar la corrección global del sistema

Restricciones:

·         Quien anuncia el evento no conoce a que componentes afecta el evento·         No se pueden hacer asunciones acerca del orden de procesamiento

6. CONCLUSIONES:

La arquitectura de software, ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema.

La arquitectura de software también nos permite mejorar en algunos aspectos: 

• Mejora la comprensión de sistemas grandes y complejos.

• Permite una mejor comunicación entre los diferentes sistemas. 

• Mejora las posibilidades de reutilización.

• Proporciona planos para la construcción. 

En el desarrollo de productos de software las etapas de análisis de requerimientos y diseño toman gran parte del tiempo del proyecto. El modelo planteado en un proyecto pretende establecer unos parámetros de diseño generales que permitan agilizar la implementación de proyectos tipo sistemas de control por software, cuya base común es el procesamiento de señales digitales en busca de comportamientos de interés para unos requerimientos específicos.

7. BIBLIOGRAFIA

[1] w3ii.com, «Arquitectura de flujo de datos,» 2017. [En línea]. Available: http://www.w3ii.com/es/software_architecture_design/data_flow_architecture.html.

[2] SA, «Slideshare,» [En línea]. Available: https://es.slideshare.net/kaolong/patrones-de-diseo-i.

[3] A. Leiva, «devexperto,» [En línea]. Available: https://devexperto.com/patrones-de-diseno-software/.

[4] SA, «Marco de desarrollo de la junta de Andalucia,» [En línea]. Available: http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/204.

[5] SA, «ITECHWEBPERU CODELABS,» [En línea]. Available: https://codelabs.itechwebperu.com/.

[6] SA, «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/Cliente-

servidor#Ejemplos.

[7] SA, «Eli,» [En línea]. Available: https://ylez.wordpress.com/2010/09/06/ejemplo-de-diseno-de-la-arquitectura-del-software-y-aplicaciones-monoliticas/.

[8] SA, «Servicio de Informática,» [En línea]. Available: https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html.

[9] cbuitragop, «emaze,» [En línea]. Available: https://www.emaze.com/@ALOQTQCR.

[10] J. Lopez, «Componentes Independientes,» [En línea]. Available: http://componentesindependiente.blogspot.com.co/ .

[11] SA, «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software_basada_en_componentes .

[12] SA, «Ecured,» [En línea]. Available: https://www.ecured.cu/Estilos_arquitect%C3%B3nicos .

[13] [En línea]. Available: http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF .

[14] SA, «Arquitecturas de Software,» [En línea]. Available: http://pegasus.javeriana.edu.co/~mad/Arquitecturas%20de%20SW.pdf .

[15] SA, «Arquitectura de datos centrada,» [En línea]. Available: http://www.w3ii.com/es/software_architecture_design/data_centered_architecture.html.