Diseño y Arquitectura de Software

Diseño y Arquitectura de S o f t w a r e Unidad 2. Modelos de Arquitectura

Ingeniería en Desarrollo de software 5 Cuatrimestre

Programa de la asignatura: Diseño y Arquitectura de Software Unidad 2. Modelos de Arquitectura

Clave: 150920517/ 150920517 Universidad abierta y a distancia de México

Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 1


Índice

UNIDAD 2. MODELOS DE ARQUITECTURA.................................................................... 3 Presentación de la unidad ................ ................. .................. ................. .................. ................. .... 3 Propósito ........................................................................................................................................

3

Competencia específica ..............................................................................................................

3

2.1. Patrones y arquitectura de software .................................................................................. 3 2.1.1. Tipos de patrones y arquitectura ....................................................................................

5

2.1.2. Características de patrones y arquitectura .................. ................. .................. ............... 7 Actividad 1. Patrones Patrones aplicables aplicables a la arquitectura arquitectura de software. ............................................ 8 2.2. Patrones de estructura ......................................................................................................... 9 2.2.1. Capas en modelos arquitectónicos ..............................................................................

10

2.2.2. Tuberías y filtros ..............................................................................................................

15

2.2.3. Tableros ............................................................................................................................

17

Actividad 2. Caso de estudio ....................................................................................................

17

Actividad 3. Contrastando Contrastando arquitectura arquitectura y patrón de de diseño. ................................................ 19 Autoevaluación Autoevaluación ...........................................................................................................................

19

Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de software 19 Autorreflexiones Autorreflexiones ..........................................................................................................................

20

Cierre de la unidad .....................................................................................................................

20

Para saber más ................. ................. ................. .................. ................. .................. .................. . 20 Fuentes de consulta ...................................................................................................................

21



Unidad 2. Modelos de Arquitectura Presentación de la unidad En esta segunda unidad revisarás de manera profunda los patrones de arquitectura y su influencia sobre la arquitectura de software , los tipos que existen y las características de cada patrón; asimismo conocerás las distintas propuestas existentes en la industria del desarrollo de software. Los temas desarrollados en la unidad te ayudarán a identificar el modelo adecuado a aplicar para una determinada problemática en el desarrollo de software. Finalmente distinguirás diferencias primordiales en los estándares más aplicados y extendidos en la industria del desarrollo de software. ¡Bienvenido(a) a la unidad 2!

Propósito Analizar los tipos de patrones aplicables a la arquitectura de software para poder proponer una solución preliminar a un problema sobre la base de los requerimientos de software dados por el usuario o patrocinador.

Competencia específica Diseñar una propuesta de arquitectura para el diagnóstico de información de los usuarios, mediante el análisis y uso de herramientas de diferentes tipos de sistema.

2.1. Patrones y arquitectura de s o f t w a r e Los patrones arquitectónicos son una forma clara de plasmar la solución de un problema mediante el uso de arquitectura de software, se usa también para comunicar diseño arquitectónico a las etapas posteriores del desarrollo de software.

En el sentido estricto de la palabra, un patrón es “un modelo que se toma como muestra para reproducir un objeto o concepto igual ” (RAE, 2012a). Para complementar la definición de un patrón tenemos que, un modelo “representa una realidad o un sistema que se distinguen por ser complejos, generalmente la representación con el uso de un lenguaje matemático formal ” (RAE, 2012b).



De las definiciones anteriores se puede deducir que ambas llevan a formar un estilo propio de cómo hacer las cosas para poder explicar un sistema o una realidad compleja. Entonces, podemos definir al estilo como “Cada una de las distintas formas de realizar algo”. Esta consecución de definiciones y deducciones nos lleva a comprender lo básico de los Patrones Arquitectónicos o Estilos Arquitectónicos. En los últimos años la sistematización de los estilos arquitectónicos ha sido uno de los temas más recurrentes; sin embargo, solo en breves ocasiones la literatura técnica especializada sobre patrones arquitectónicos realmente hace un buen análisis del vínculo innegable entre estilos y patrones. Suele decirse que están íntegramente comunicados, y se deja muy poco clara la barrera de separación entre uno y otra, pero nadie se atreve a articular de forma sistemática y formal su relación. Para no seguir con discusiones que por ahora son interminables, se abordará directamente el tema de estilos arquitectónicos, que con las definiciones dadas al introducir el tema se dirá que es semejante a un patrón arquitectónico; además, a manera aclaratoria, se tiene que una diferencia básica entre ellos se da porque aquellas personas que trabajan con estilos se inclinan hacia un tratamiento que lleva una alta carga teórica, un enfoque académico y de abstracción mucho más elevado para su aplicación, mientras las personas que trabajan con patrones se inclinan por el diseño, lo práctico, la implementación en aspectos reales, el refinamiento y el código duro. Antes de siquiera pensar en definir lo que es un estilo arquitectónico, se debe entender cuál fue el origen. En los principios se detectó repetición en el comportamiento de las soluciones de Arquitectura de Software (AS) aplicadas a problemas similares. El número de apariciones del comportamiento fue limitado, pero repetible, y tomando como referencia la arquitectura en edificios reales, se les llamó estilos. Un estilo es una “clase” o “tipo” de arquitectura o piezas repetibles que se dieron con el

andar de las cosas. Y no se debe hacer mucho esfuerzo por encontrar esas piezas, pues la misma práctica va otorgándolas. Cuando se han identificado de manera clara estas piezas (estilos) por sentido común y lógica se puede pensar en volver a utilizarlos en ambientes y situaciones parecidas a aquellos en los cuales surgieron. Los identificadores comúnmente dados, entre otros, a los estilos arquitectónicos son: Cliente-servidor Modelo-vista-controlador Tubería-filtro Arquitectura en capas    

Si los nombres que aparecen en la lista anterior parecen conocidos, es porque se comparten con los patrones de arquitectura; esto quiere decir que si las características de un patrón de arquitectura son similares a las características de un estilo arquitectónico, se



usa el mismo nombre. Para poder hacer una clara distinción entre los estilos arquitectónicos y los patrones de arquitectura convendrá poder diferenciarlos por los diferentes tipos que ellos tienen.

2.1.1. Tipos de patrones y arquitectura Existen diferentes tipos de patrones aplicables en la AS, los cuales se usan dependiendo de la naturaleza del problema a resolver; sirven para tomarlos como punto de partida, ya que se usan como andamiaje para construir la solución sobre una idea ya avanzada y no comenzar siempre la solución desde la nada. Tratar de hacer un catálogo detallado de los tipos de estilo sería una idea poco práctica, pues cada autor, e inclusive cada arquitecto, podrían dar una lista propia a su gusto. Por ello sólo se enumerarán las consideraciones primarias de la literatura técnica especializada sobre patrones arquitectónicos y se podrá tomar como una clasificación de primer orden. La enumeración primaria de la que se hace mención puede llevar a preguntarse: ¿Cuántos estilos existen? ¿Cuáles son? ¿Son suficientes? La idea de organizar los patrones y sus tipos comenzó por la necesidad de hacer una distinción clara entre ellos, pues el número de patrones que se estaba conociendo llegó a ser tan alto que había siempre confusiones. De acuerdo con Reynoso y Kicillof (2004), la siguiente lista se puede tomar como una primera propuesta:        

Arquitectura orientada a objeto Arquitectura de estados Arquitecturas de control de realimentación Arquitectura de tiempo real Modelo de diseño de descomposición funcional Modelo orientado por eventos Modelo de control de procesos Modelo de tabla de decisión

En un segundo acercamiento, al refinar la lista anterior, surge la necesidad de replantear la clasificación (combinando arquitecturas y modelos de diseño), llegando a la lista siguiente: Tubería-filtros Organización de abstracción de datos Invocación implícita   



Sistemas en capas Repositorios Intérpretes orientados por tablas Procesos distribuidos. Organizaciones programa principal-subrutina. Arquitecturas de software específicas de dominio Sistemas de transición de estado Sistemas de procesos de control Estilos heterogéneos

        

Para escribir los acercamientos anteriores (el primero y su refinamiento) se tomó como base la información contenida en el material de Reynoso y Kicillof (2004). Nótese que las clasificaciones presentadas tienen un parecido amplio, pues ambas están sobre la base de listar estilos que se usan para poder expresar algún tipo de organización estructural claramente definido, además son parte sustantiva para los sistemas de software , pues estos, por definición basan su estructura en una organización jerárquica, que con los estilos arquitectónicos se puede detallar de manera práctica y clara, incluyendo sus subsistemas (como el software mismo en su definición más ortodoxa) qué y cuáles son los procesos que debe seguir (especifican responsabilidades y lineamientos para organizar las relaciones entre ellos), a continuación se puntualizan estos patrones: o Capas o Tubería-filtros o Pizarra o Sistemas distribuidos Bróker CAGS Cliente-Servidor. o Sistemas interactivos Modelo-vista-controlador Presentación-abstracción-control o Sistemas adaptables Reflexión Microkernel   

 

 

En los escritos de Reynoso y Kicillof (2004) sobre estilos arquitectónicos se propone una sistematización en cinco grupos: 1. Flujo de datos a. Proceso secuencial por lotes b. Red de flujo de datos c. Tubería-filtros 2. Llamado y retorno (estilo dominado por orden de computación, usualmente con un solo thread de control). a. Programa principal / Subrutinas b. Tipos de dato abstracto



c. Objetos d. Cliente-servidor basado en llamadas e. Sistemas en capas 3. Componentes independientes (dominado por patrones de comunicación entre procesos independientes, casi siempre concurrentes) a. Sistemas orientados por eventos b. Procesos de comunicación 4. Centrados en datos (dominado por un almacenamiento central complejo, manipulado por computaciones independientes) a. Repositorio b. Pizarra 5. Máquina virtual (caracterizado por la traducción de una instrucción en alguna otra) a. Intérprete Dentro de estas cinco clases de todos los estilos arquitectónicos, quedan fuera de ellas algunos muy importantes, aunque en términos generales si se presentaran más clasificaciones o tipos de patrones o estilos arquitectónicos se estaría dando vueltas sobre lo mismo, de tal forma que puede resumirse en la siguiente tabla: Categorías de tipos de patrones arquitectónicos Capas Tubería-filtro Patrones simples Pizarra Repositorio Broker Sistemas distribuidos CAGS Cliente-Servidor Modelo-Vista-Controlador Sistemas interactivos Presentación-Abstracción-control Microkernel Patrones adaptables Reflexión           

La serie de listas y categorías presentadas en el apartado actual permitirán tener una clara diferenciación entre los tipos de patrones y en dónde ubicarlos respecto del tipo de sistema al cual pertenecen. Otro punto a tomar en cuenta para la correcta clasificación son las características propias de cada tipo de patrón.

2.1.2. Características de patrones y arquitectura La principal característica de un patrón arquitectónico es la comunicación de diseños. Una característica es un rasgo distintivo que sólo posee algo (un objeto, persona, animal, entre otros) o un grupo de ellos. Otras características que se pueden enumerar respecto a los patrones de diseño, son:  

No reinventan soluciones a patrones conocidos. Rehúsan el conocimiento experto relativo a un diseño


Diseño y Arquitectura de S o f t w a r e Unidad 2. Modelos de Arquitectura 



 

Personas inexpertas pueden fácilmente hacer un diseño de alta calidad gracias a los patrones. Se tienen menores errores al modelar la arquitectura de la solución debido al uso de diseños ya probados y que solucionaron problemas similares. Los diseños que están probados son fácilmente mantenibles. A partir de los patrones, el software puede diseñarse para tener ciertas características deseadas por el cliente o que la misma solución necesite.

Además de la lista presentada, se debe tener en cuenta algo muy importante: cuando se trata de características de patrones de software no toda aquella solución que tenga un cierto parecido a esta lo es. Deben hacerse pruebas (de compatibilidad entre soluciones, de similaridad, de homogeneidad, entre otras) a problemas que tienen las mismas premisas, y si es aplicable, se considerará un patrón. Sin embargo, deberá pasar además una serie de pruebas aplicadas única y particularmente a los patrones. Antes de estas pruebas, la mencionada solución no dejará de ser un patrón-primigenio. Cuando un patrón haya pasado el conjunto de pruebas que haya que aplicar, tendrá las siguientes características: Solucionar un problema: si no puede hacer más allá de tener principios o estrategias abstractas, entonces no será patrón. Ser un concepto probado: como el punto anterior, si no ofrecen soluciones plenamente demostrables, entonces no será patrón. La solución no es obvia: un patrón busca soluciones a problemas complejos de forma que abstraen dentro de sí soluciones pequeñas para cada parte del problema o de forma indirecta. Describe participantes y relaciones entre ellos: se describe de manera clara y detallada un sistema completo, no sólo módulos aislados. El nivel de complejidad puede crecer sin causar problema para el patrón arquitectónico. El patrón tiene un componente humano significativo: la principal razón de fabricar (o diseñar) software es para facilitar el trabajo humano, de manera directa o indirecta. 









Otra característica necesaria de los patrones arquitectónicos, mas no suficiente, es la repetición, si no la tiene entonces no es un patrón. En términos formales se definirá que: La repetición se debe tomar como una característica cuantitativa La utilidad y adaptabilidad como características cualitativas.  

Para poder comprobar la existencia o ausencia de estas características se proponen en diferentes textos algunas formas empíricas de poder hacerlo, el cual no es tema a tratar en la presente asignatura.

Actividad 1. Patrones aplicables a la arquitectura de s o f t w a r e . Ahora que ya se comprendieron los temas expuestos previamente, podrás participar en la wiki con el análisis de patrones aplicables a la arquitectura de software , donde



colaborarás con el resto de tus compañeros de la asignatura para formar entre todos una arquitectura base haciendo uso de los conocimientos adquiridos. El propósito es la construcción de conceptos para el correcto análisis de los patrones aplicables a la arquitectura de software . Por la misma naturaleza de la herramienta wiki, harán en grupo esta tarea formativa y acumulativa de los conceptos de los patrones aplicables a la arquitectura de software . Instrucciones •

•

•

•

• •

Un integrante del grupo de estudiantes, a voluntad o por indicación del (la) Facilitador(a), deberá añadir un primer comentario donde explique la elaboración de su arquitectura base; el (la) Facilitador(a) puede designar a más de un estudiante para este punto, y lo hará público dentro de la wiki. Los demás integrantes del grupo deberán verter opiniones sobre la arquitectura presentada por el (la) primer(a) compañero(a). Estos comentarios deberán encaminarse hacia el fortalecimiento de las áreas de oportunidad observadas entre todo el grupo. El (la) Facilitador(a) designará a los participantes que deberán realizar las correcciones pertinentes de cada arquitectura expuesta, de acuerdo a los comentarios recibidos, y publicará de nuevo la propuesta. Todos(as) deberán aplicar en un párrafo inferior a los puntos anteriores las mejoras pertinentes a la propia arquitectura y la habrán de subir (a manera de descripción escrita) a la plataforma. El (la) primero(a) que realice este punto deberá colocar el título “Propuestas de mejoras” para comenzar su participación. Cada integrante del grupo de estudiantes deberá comentar por lo menos una posible mejora para cada arquitectura que esté expuesta. Al final deberán elegir cuál es la más completa (después de las mejoras) en una votación, de la cual el (la) Facilitador(a) publicará los resultados.

2.2. Patrones de estructura La base sobre la cual está formado cualquier sistema es una estructura que puede ser física o lógica. Esta estructura puede ser completamente nueva, respecto al problema que se quiera resolver, o estar tomando fundamentos de conocimientos aplicado antes a la resolución de problemas parecidos, en donde se esperan resultados similares, en tiempo y espacio similar; los patrones de estructura surgen cuando se cumplen las condiciones antes mencionadas. La aplicación formal de los patrones de estructura a una arquitectura de software debe hacerse de manera sistemática y organizada, no se puede resolver el problema al que el arquitecto se enfrenta con la sola aplicación de un patrón determinado. Esta organización estructurada la proporcionan las capas en modelos arquitectónicos.



2.2.1. Capas en modelos arquitectónicos Los sistemas computacionales organizados en capas (o arquitectura de software en capas) es uno de los hitos que mayormente aparece referido en la literatura especializada en arquitectura de software . La arquitectura en capas intenta hacer una discriminación formal de los estilos o patrones arquitectónicos separando en piezas (o subsistemas) la solución de software . El objetivo principal de la separación de los distintos componentes del software (la lógica del negocio, la vista del usuario, la capa de datos, entre muchas otras) es tener piezas identificables y unificadas sobre la base de la labor que desempeñarán dentro de la solución completa. Cada capa de software en los modelos arquitectónicos es una parte que coopera para lograr los objetivos del propio sistema. La principal razón por la cual es ampliamente usado este tipo de patrón de arquitectura, es la facilidad de mantenimiento que ofrece al software que se aplica. Como los niveles se separan y no dependen directamente uno del otro, ni entre ellos, cuando viene un cambio se ataca sin mayor dificultad la “capa” específica a la cual se deberá hacer la corrección o mejora. El patrón arquitectónico en capas es más una organización jerárquica, de manera que cada capa da servicio a la capa inmediatamente superior y consume los servicios de la capa dispuesta en el inmediato inferior. Esto es muy parecido a la organización que se sigue en distintos ámbitos de la vida diaria no sólo del software, y por eso es otra razón por la cual su comprensión es tan fácil y natural para cualquier persona. La manera de organizarlo también es igual que una estructura jerárquica (por niveles): las capas inferiores están ocultas para todos (por cualquier razón que el lector desee considerar), excepto para las capas que hacen consumo de sus servicios. En términos prácticos, y para clarificar: una capa so lo “sabe” de su vecino superior e inferior. En otro tipo de sistemas las capas pueden ser parcialmente visibles. Cuando se transportan estos conceptos a la vida diaria, una capa es una entidad compleja formada por varios paquetes o subsistemas; en casos de extrema refinación, una capa puede estar formada por otras capas. Su uso está ampliamente extendido en los sistemas de software que cualquier persona aplica en sus labores de la vida diaria. Como en todo sistema (en su definición más genérica) los componentes deben tener un canal bien establecido de comunicación, en este caso los componentes del sistema son las capas. La manera en que se comunican las capas son los conectores, y la forma de comunicación está definido por los protocolos que determinan la interacción entre ellas. La sensación de pertenencia de un nivel superior con otro inferior se da de manera natural en este patrón arquitectónico; su representación suele hacerse con conectores y se entiende que la relación es de arriba abajo y de abajo a arriba. Inclusive es tan natural su uso y representación que se puede representar con círculos concéntricos denotando jerarquía entre sus elementos y sus pertenencias. Ahora observa la siguiente imagen para que comprendas lo explicado:



Arquitectura N-Layer DDD en VS.2010 (De la Torre y otros, 2010) Aunque no todo es perfecto: este tipo de patrón arquitectónico tiene una gran desventaja que es su topología. De manera natural, como ya se mencionó, las capas solo conocen entre su vecindad y esto mismo hace que solo se puedan considerar soluciones con esta ventaja/desventaja, pues si surge la necesidad de comunicar una capa con otra y su nivel de relación no es de primer orden, deberá recurrirse a métodos no tan transparentes para poder lograrlo. Si esta capacidad de comunicación solo entre vecinos se deja un poco de lado, pierde por completo la razón de ser y su estilo más puro, como se debe seguir siempre. Si se sigue el método relajado de dejar al mínimo la independencia entre capas o módulos de ellas, se llegará al punto donde la mezcla de las capas será muy fuerte, y entonces al menor cambio de requerimientos se deberá trabajar sobre dos (o más) capas distintas para poder hacer la modificación requerida, haciendo el grado de mantenimiento muy complejo, se pierde la capacidad de mover o reemplazar una capa completa sin afectar a las demás, disminuyendo la flexibilidad de los gránulos y del conjunto por propia definición.



Arquitectura 3-Tier, física (De la Torre y otros, 2010) En este tipo de patrón hay una premisa básica: cada capa debe hacer algo, siempre. En la literatura especializada se pueden encontrar argumentos a favor o en contra de esta aseveración. Muchas capas pueden eventualmente degradar el rendimiento de la aplicación; pero muchas veces se tiene que echar mano de soluciones no tan puras para poder brindarle rendimiento a la aplicación, por ejemplo que una regla de negocio se programe como un procedimiento almacenado en el lado de los datos, o haciendo sentencias de consulta a base de datos desde la capa de presentación. Ante todo esto es natural preguntarse por el número adecuado de capas, y la respuesta es que dependerá de cada sistema; el número mínimo es dos, y el máximo lo determinará cada problema que se quiera resolver con este patrón arquitectónico. Hay sistemas que llegan a los cientos de capas y cada una de ellas está conformada por otro tanto.



Arquitectura N-Capas con Orientación al Dominio (De la Torre y otros, 2010) Cuando se habla de una aplicación de N capas (De la Torre, 2010) se puede decir que son: Capa de Presentación o Subcapas de Componentes Visuales (Vistas) o Subcapas de Proceso de Interfaz de Usuario (Controladores y similares) Capa de Servicios Distribuidos (Servicios-Web) o Servicios-Web publicando las Capas de Aplicación y Dominio Capa de Aplicación o Servicios de Aplicación (Tareas y coordinadores de casos de uso) o Adaptadores. o Subcapa de Workflows (Opcional) o Clases base de Capa Aplicación (Patrón Layer-Supertype ) Capa del Modelo de Dominio o Entidades del Dominio o Servicios del Dominio o Especificaciones de Consultas (Opcional) o Contratos/Interfaces de Repositorios o Clases base del Dominio (Patrón Layer-Supertype ) Capa de Infraestructura de Acceso a Datos o Implementación de Repositorios 











Modelo lógico de Datos o Clases Base (Patrón Layer-Supertype ) o Infraestructura tecnología ORM o Agentes de Servicios externos Componentes/Aspectos Horizontales de la Arquitectura o Aspectos horizontales de Seguridad, Gestión de operaciones, o Monitorización, Correo Electrónico automatizado, etc. o



Quedarse con el concepto abstracto de capas te será suficiente para poder lograr una comprensión básica de su aplicación, pero si se trata de diseñar una AS de nivel profesional, debes comprender cada concepto que las conforma y poder llevar su uso de manera correcta en el problema específico. A continuación se presenta una descripción de las principales y más usadas capas dentro de la AS: Capa de presentación al usuario Es la primera capa donde tiene contacto el usuario y es ahí donde él mismo realiza el trabajo propio de la aplicación; recibe información del exterior y la presenta dependiendo de los resultados que haya obtenido. Se encarga de comunicar la información procesada desde las capas inferiores hacia el usuario, solo presenta lo que necesita, refinando la presentación. Hace composición y filtrado de datos para hacer un resumen al usuario y no presentarle los datos en crudo. Los componentes de las capas de presentación implementan la funcionalidad requerida para que los usuarios interactúen con la aplicación. Capa de Aplicación Situar la realidad del software en el contexto específico de aplicación es importante para saber qué es lo que hará esta capa. El contexto donde trabajará el software es importante para poder decidir qué arquitectura se utilizará para conocer el dominio de aplicación. Esta capa forma parte de la propuesta de arquitecturas orientadas al dominio. Capa del Dominio Es en esta capa donde se implementan y desarrollan todas las reglas de negocio que el cliente haya solicitado como resultado de la etapa de análisis del problema, es aquí donde se establecen “las reglas del juego”; es responsable de representar conceptos de negocio, información sobre la situación de los procesos de negocio e implementación de las reglas del dominio Capa de Infraestructura de Acceso a Datos Los datos que genera una aplicación deben ser independientes en su manejo respecto al funcionamiento de la plataforma en general. Su integridad debe ser lo principal que se busca y no debe estar mezclado su manejo dentro la lógica del negocio o de la presentación de los mismos. Un ejemplo claro de esto es: en donde la aplicación está alojada en un servidor en Los Ángeles, California, y los datos que usa esta aplicación están alojados en Argentina. La independencia entre los datos debe ser total. Así pues, esta capa de persistencia de datos expone el acceso a datos a las capas superiores (normalmente las capas del dominio). Esta exposición deberá realizarse de una forma desacoplada.



En este mismo escrito (De la Torre, 2010) se hace una importante mención del desacoplamiento de las capas. La dependencia entre ellas debe ser hasta cierto punto nula y en un mundo ideal poder trabajar solamente la capa realizando su función de presentar información al usuario, manipular, obtener y guardar datos y así cada capa no dependerá de alguna otra, y aunque el sistema esté cohesionado, el grado de desacoplamiento asegurará que su funcionamiento sea el correcto, de tal manera que es fundamental destacar que no solo se deben de delimitar los componentes de una aplicación entre diferentes capas. Adicionalmente, también debe tenerse especial atención en cómo interaccionan unos componentes/objetos con otros, es decir, cómo se consumen y en especial cómo se instancian unos objetos desde otros. En general, este desacoplamiento debería realizarse entre todos los objetos (con lógica de ejecución y dependencias) pertenecientes a las diferentes capas, pues existen ciertas capas que puede interesar mucho el que se integren en la aplicación de una forma desacoplada. Este es el caso de la mayoría de capas de Infraestructura (ligadas a unas tecnologías concretas), como puede ser la propia capa de persistencia de datos, que puede haberse ligado a una tecnología concreta de ORM (por sus siglas en inglés, Object-Relational mapping) o incluso a un acceso a backend externo. En definitiva, para poder integrar esa capa de forma desacoplada, no se deben instanciar directamente sus objetos. Pero la esencia final de la separación de las partes del software en capas, realmente trata del desacoplamiento entre cualquier tipo/conjunto de objetos, bien sean conjuntos de objetos diferentes dentro del propio Dominio, o bien, en los componentes de Capa de presentación poder simular la funcionalidad de Servicios-Web, o en la Capa de Persistencia poder también simular otros Servicios-Web externos y en todos esos casos realizarlo de forma desacoplada para poder cambiar de la ejecución real a la simulada o a otra ejecución real diferente, con el menor impacto. En todos esos ejemplos tiene mucho sentido un desacoplamiento de por medio. La organización de las capas debe tener una comunicación clara u homogénea para ser transparente en su acoplamiento.

2.2.2. Tuberías y filtros Este tipo de patrón arquitectónico pertenece a una clasificación (familia) de patrones que se centra primordialmente en la reutilización y la modificación. Por ejemplo: si se está realizando alguna arquitectura de un banco donde sus datos necesitan una serie de condiciones (paso del tiempo, sucesiones anteriores, entre otras) la arquitectura de tuberías y filtros es la indicada. Lo que normalmente se conoce como proceso por lotes. Por lo descrito en el párrafo anterior, normalmente se dice que el patrón arquitectónico de tuberías y filtros pertenece a las llamadas arquitecturas de flujo de datos. Se relaciona con redes de procesos y procesos secuenciales (procesos por lotes). Una idea que ha persistido y que podría considerarse una buena área de oportunidad es que la parte de los filtros comúnmente realiza esta tarea, filtrar; pero no es forzoso que lo haga siempre, por tanto la forma más pura no se respeta. Para conectar componentes computacionales, se ha apoyado de muchas técnicas y protocolos diferentes, desde el paso de mensajes entre objetos hasta los métodos



asíncronos más modernos. En el caso de este patrón arquitectónico, el método de comunicación son las tuberías. La nomenclatura específica es, en correspondencia directa: Objeto Componentes computacionales Conectores

Descripción Filtros Tubos/tuberías

La tabla anterior obedece al orden en que el flujo de datos va de manera secuencial, directa. Los datos se transportan de manera que se ve cómo los datos se convierten en entrada o salida (depende de la perspectiva) de un filtro a otro. Como puedes observar, la simplicidad de este patrón arquitectónico es obvia y puede tomarse muy a la ligera, pero la potencia de resolución de problemas es muy amplia debido a que gran parte de los problemas a los que se enfrentan las soluciones basadas en software en la actualidad obedecen a este tipo de estructura organizacional. La siguiente imagen representa algo muy familiar para cualquier persona:

La numeración presentada en la imagen obedece al flujo que sigue el agua cuando es distribuida en una casa habitación, algo bastante normal de conceptualizar para cualquiera. Esta misma familiaridad y sencillez del patrón arquitectónico da para poder aplicarlo a muchos escenarios del ámbito de la arquitectura de software. Nota cómo el flujo del agua (datos, en nuestro caso) es simple y muy fácil de deducir hacia donde será la siguiente iteración. Además de la sencillez explicada con el ejemplo del flujo del agua, otro punto importante a considerar es que este patrón arquitectónico debe ser percibido como una serie de transformaciones sucesivas, donde el flujo de datos se da a través de las tuberías y los filtros, que son quienes realizan las dichas transformaciones. En el estilo secuencial por lotes (batch sequential ) los componentes son programas independientes; el supuesto es que un paso no puede seguir hasta que el anterior esté completo, como sucede en la distribución del agua, si no ha llegado al repositorio de la casa habitación, no puede distribuirse a los aparatos que requieran de ella.



¿Cómo y cuándo se debe aplicar este tipo de patrón arquitectónico? Este estilo debe aplicarse cuando: Se puede especificar la secuencia de un número conocido de pasos. No se requiere esperar la respuesta asincrónica de cada paso. Se busca que todos los componentes situados corriente abajo sean capaces de inspeccionar y actuar sobre los datos que vienen de corriente arriba (pero no viceversa).   

De igual manera, se reconocen como ventajas del estilo tubería-filtros: Es fácil de implementar. Obliga a que el proceso se lleve a través de una forma secuencial. Es fácil aislar en una operación con un único resultado. Los filtros se hacer fácilmente distribuibles. Desventajas: El patrón puede resultar demasiado simplista, especialmente la ejecución de la lógica de negocios de formas complicadas. No maneja con demasiada eficiencia lógica de negocios donde se involucren decisiones o repeticiones para el control del flujo. Eventualmente puede llegar requerir almacenamiento de tamaño no conocido. No es apto para manejar situaciones de relación entre distintos actores, sobre todo cuando se necesita la presentación de datos a una salida estándar, como una pantalla de computadora.    





 

2.2.3. Tableros Cuando se habla del patrón arquitectónico tipo “tablero” se deben considerar dos

componentes principales siguientes: 

Una estructura de datos que representa el estado actual.



Una colección de componentes independientes.

La aplicación de este tipo de estilo arquitectónico es para problemas especializados, como en la resolución de problemas concernientes a inteligencia artificial, donde actúan múltiples agentes. La diversidad de soluciones que pueden alcanzar los agentes debe manejarse en una arquitectura que soporte esta complejidad. Contrastando con estilos arquitectónicos presentados en las pantallas anteriores, en aquellos la interacción era simple y directa entre partes bien definidas, por el contrario, en los tableros se hace manejo de información de diversas fuentes (agentes). Se puede llamar arquitectura multi agentes.

Actividad 2. Caso de estudio



“La aplicación de los modelos arquitectónicos debe hacerse sobre ejemplos que se presentan en la vida diaria ”.

A continuación se te presenta un caso de estudio en donde deberás poner en práctica los conceptos aprendidos hasta el momento. Deberás considerar diferentes escenarios de solución al problema propuesto sobre la base del análisis de los diferentes modelos y decidir cuál es el mejor para poder resolver el problema propuesto; la finalidad de la actividad es que tengas de manera clara la aplicación de los modelos arquitectónicos comenzando con ejemplos sencillos, como el que se presenta. Cuando se haya completado el temario hasta este punto, se presenta un FORO de discusión, creado para que participes en él. La idea del foro es que con base en el conocimiento adquirido con la consecución de la unidad, seas capaz de hacer una propuesta de arquitectura con relación al caso de estudio que se describe enseguida: “Una tienda de conveniencia necesita automatizar sus procesos de compra, venta y seguimiento de clientes. Lo desea hacer a través de venta en línea para sus clientes y que sus proveedores puedan acceder a un sitio privado y vean automáticamente las existencias del producto que surten, al mismo tiempo los usuarios podrán comentar sobre su experiencia de compra en línea o en el sitio; estos comentarios los podrán hacer a través de un equipo de cómputo convencional o mediante un dispositivo móvil que será capaz de conectarse al sitio de la tienda. El gerente de la tienda necesita que se obtengan tendencias de ventas y que se haga una posible sugerencia a los compradores sobre la base a sus compras anteriores, y sobre todo considerando su perfil (se entiende que el sistema deberá generar ese perfil en el que se incluya la edad, el sexo, la ubicación, los amigos, las fotografías, su grado escolar y comentarios hechos). Deberá ser fácil de usar para todos los usuarios y deberá manejar diferentes tipos de roles (administrador del sitio, gerente general, gerente de tienda, vendedor, proveedor, usuario normal) y cada uno tendrá acceso a diferentes privilegios asignados por el administrador del sitio ”

1. Identifica qué ADL’s (Lenguaje de Definición de Arquitectura) será el más apropiado para usar en este caso. 2. Identificar qué patrón será el que se utilizará para representar esta arquitectura propuesta. 3. Redactar en un archivo de cualquier procesador de texto una justificación amplia del por qué es el mejor patrón para solventar el caso de estudio presentado. Esto implica proponer una Arquitectura base para el problema expuesto. 4. Guarda la actividad con el nombre DRS_U2_A2_XXYZ, y envía tu archivo de propuesta al foro. 5. Participa en el foro comentando y enriqueciendo las propuestas de tus compañeros(as).



Actividad 3. Contrastando arquitectura y patrón de diseño. El uso de un patrón arquitectónico y saber la diferencia entre la variedad de ellos es importante a la hora de seleccionar cuál es el adecuado para resolver o proponer una arquitectura. En esta actividad deberás realizar una redacción en donde expliques esta diferencia entre los que se citan en el desarrollo del tema. El alumno deberá investigar por lo menos otros tres patrones arquitectónicos que no se encuentren descritos en el mismo tema desarrollado en esta unidad. Redactar reporte escrito donde se explique y justifique la razón por la cual se decidió utilizar el patrón de diseño seleccionado para la construcción de la arquitectura. Instrucciones: 1. Identifica qué es un patrón de arquitectura. 2. Redacta reporte escrito donde se describan las diferencias entre los distintos patrones arquitectónicos y arquitecturas. 3. Guarda la actividad con el nombre DRS_U2_A3_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido. 4. Ingresa al apartado de Tareas. 5. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.

Autoevaluación Para reforzar los conocimientos relacionados con los temas que se abordaron en esta primera unidad del curso, es necesario que resuelvas el cuestionario de Autoevaluación. Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y elegir la opción adecuada para cada uno.

Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de s o f t w a r e Para demostrar tu conocimiento acerca de los tipos de patrones arquitectónicos, tú diseñarás una propuesta de arquitectura que sirva para solucionar un problema; para ello considerarás que el patrocinador (la empresa que solicitó la solución) es una tienda de conveniencia, tú analizarás sus requerimientos de software y lo contrastarás con las herramientas de diferentes tipos de sistema, siendo capaz de elaborar una propuesta. Como parte de la evaluación de esta unidad, es necesario realizar en forma gráfica la arquitectura de una tienda de conveniencia aplicando y justificando el uso del patrón específico.



1. Justifica el uso del patrón. 2. Realiza la representación de la arquitectura propuesta. Para hacer esta presentación, usarás herramientas de diseño gráfico de arquitectura y, en base a los ejemplos mostrados en la unidad, hacer un diagrama con la arquitectura propuesta. 3. Guarda la actividad con el nombre DRS_U2_EA_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido. 4. Envía el archivo a tu Facilitador(a) a través de la sección Evidencia de aprendizaje.

Autorreflexiones Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses al foro Preguntas de Autorreflexión y consultes las interrogantes que presenta tu Facilitador(a), a partir de ellas elabora tu Autorreflexión en un archivo de texto llamado DRS_U2_ATR_XXYZ. Recuerda sustituir las XX por las dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido. Posteriormente envía tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad Has concluido la Unidad 2. Modelos de arquitectura. La revisión de este tema te sirvió para conocer los patrones arquitectónicos, su correcto uso y aplicación dentro de la solución de un problema en un ámbito específico, lo cual ayuda a que esta solución sea confiable y adherida a buenas prácticas de armado de arquitectura. La aplicación de los patrones dará la flexibilidad y la facilidad de uso, con la experiencia, para hacer ágil la implementación de una arquitectura confiable a la hora de diseñar la solución. El aprendizaje no debe quedarse en las explicaciones tan cortas y mejorables que se presentan en el desarrollo del tema o a lo largo de las unidades, es importante que se amplíe con la práctica y la consulta de fuentes bibliográficas externas para hacer un trabajo complementario.

Para saber más Es importante que identifiques un software de código libre y realices una descripción formal de arquitectura basándote en un lenguaje de definición de arquitectura, instálalo en tu computadora personal para que realices pruebas de descripción y veas la aplicación de los conceptos presentados.


Diseño y Arquitectura de S o f t w a r e Unidad 2. Modelos de Arquitectura Fuentes de consulta 





De la Torre Llorente, C., Zorrilla Castro, U., Calvarro Nelson, J., Ramos Barroso, M. A. (2010). Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0. España: Krasis PRESS. Real Academia Española. (2012a). Disquisición. En Diccionario de la lengua española (22.a ed.). Recuperado de http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=Patr%C3%B3n Reynoso, C., Kicillog, N. (2004). Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Argentina: Universidad de Buenos Aires.


Diseño y Arquitectura de Software

Recommend Documents