Issuu on Google+

Dise単o y Arquitectura de Software

UNIVERSIDAD ABIERTA Y A DISTANCIA DE MEXICO

INGENIERIA DE DESARROLLO DEL SOFTWARE

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

PROFESOR: CUITLAHUAC VARGAS MILLAN ALUMNA: GUADALUPE AYALA IBARRA.


Diseño y Arquitectura de Software INSTRUCCIONES 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.


Diseño y Arquitectura de Software Patrones de arquitectura. Los patrones arquitectónicos permiten plasmar de forma clara la solución de un problema a través de la arquitectura de software. También permite comunicar el diseño arquitectónico a las etapas posteriores del desarrollo de software. •

Un patrón es “un modelo que se toma como muestra para reproducir un objeto o concepto igual”

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”

Estilo se define como “Cada una de las distintas formas de realizar algo”.

Al inicio se detectó repetición en el comportamiento de las soluciones de Arquitectura de Software (AS) aplicadas a problemas similares.

Un estilo es una “clase” o “tipo” de arquitectura o piezas repetibles.

Cuando se han identificado de manera clara estas piezas (estilos) se puede pensar en volver a utilizarlos en ambientes y situaciones similares a las que permitieron su surgimiento.

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.

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. Categorías de tipos de patrones arquitectónicos - Capas - Tubería-filtro - Pizarra - Repositorio Sistemas distribuidos - Broker - CAGS - Cliente-Servidor Sistemas interactivos - Modelo-Vista-Controlador - Presentación-Abstracción-control Patrones adaptables - Microkernel - Reflexión Patrones simples


Diseño y Arquitectura de Software A continuación se puntualizan estos patrones: Patrón arquitectónico Capas

Características  

  

 Tubería-filtros

   

Pizarra

 

       Sistemas distribuidos

  

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. 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. Patrón arquitectónico perteneciente a una clasificación (familia) de patrones que se centra primordialmente en la reutilización y la modificación Pertenece a las llamadas arquitecturas de flujo de datos Se relaciona con redes de procesos y procesos secuenciales Debe ser percibido como una serie de transformaciones sucesivas La arquitectura en pizarra consta de múltiples elementos funcionales, denominados agentes, y un instrumento de control denominado pizarra. Los agentes suelen estar especializados en una tarea concreta o elemental. Todos ellos cooperan para alcanzar una meta común, si bien, sus objetivos individuales no están aparentemente coordinados. El comportamiento básico de cualquier agente consiste en examinar la pizarra, realizar su tarea y escribir sus conclusiones en la misma pizarra. De esta manera, otro agente puede trabajar sobre los resultados generados por otro. La computación termina cuando se alcanza alguna condición deseada entre los resultados escritos en la pizarra. La pizarra tiene un doble papel. Coordinar a los distintos agentes Facilitar su intercomunicación. El estado inicial de la pizarra es una descripción del problema que resolver y el estado final será la solución del problema. Los resultados generados por los agentes deben responder a un lenguaje y semántica común. En general, se suelen utilizar formalismos lógicos o matemáticos, tales como expresiones lógicas de primer orden. Los sistemas distribuidos necesitan claramente un software distinto que los sistemas centralizados. Generalmente, las tecnologías y patrones utilizados son distintos también. El crecimiento de las redes de información y la mejora sustancial de la comunicación entre los componentes de esas redes, dio lugar a sistemas completos de software

Utilidad 

  

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.

Se usa en procesos por lotes Permite especificar la secuencia de un número conocido de pasos Todos los componentes situados corriente abajo son capaces de inspeccionar y actuar sobre los datos que vienen de corriente arriba (secuencia). Todos los agentes cooperan para alcanzar una meta común, si bien, sus objetivos individuales no están aparentemente coordinados. Examinan la pizarra, realizan su tarea y escribir sus conclusiones en la misma pizarra.

El software de los sistemas distribuidos permite la transparencia respecto a que equipo se utiliza, la escalabilidad, la tolerancia a fallas, la fiabilidad, disponibilidad, consistencia, etc.


Diseño y Arquitectura de Software distribuidos en la red, sin un punto único de centralización de la información. - Bróker     - CAGS

  

  

 

El patrón Bróker puede ser usado para estructurar sistemas de software distribuidos con componentes desacoplados que interactúan mediante invocaciones a servicios remotos. Un componente Bróker es responsable de la coordinación de la comunicación, como el envío de peticiones y la transmisión de respuestas y excepciones. El patrón Bróker comprende seis componentes principales: clientes, servidores, brókers, puentes, proxies del cliente y proxies del servidor. Los servidores se registran en el bróker y hacen disponibles sus servicios a través de sus interfaces (proxies). Los clientes acceden a esas funcionalidades a través de sus proxies, enviando la solicitud vía brókers. Las tareas del bróker incluyen localizar el servidor apropiado, enviarle la solicitud, y transmitir resultados y excepciones, de regreso, al cliente. Utilizando el patrón Bróker, una aplicación puede acceder a los servicios distribuidos enviando mensajes al objeto apropiado, en vez de enfocarse en la comunicación entre procesos de bajo nivel. Además, el patrón Bróker es flexible porque permite cambiar, añadir, quitar y reubicar objetos dinámicamente. El patrón Bróker reduce la complejidad en el desarrollo de aplicaciones distribuidas porque hace que la distribución sea transparente al desarrollador, mediante la introducción de un modelo de objetos en el que los servicios distribuidos se encapsulan en objetos. Por lo tanto, los sistemas Bróker ofrecen una ruta para la integración de dos tecnologías: distribución y objetos. Asimismo, los sistemas Bróker extienden los modelos de objetos desde aplicaciones individuales hasta aplicaciones distribuidas que constan de componentes desacoplados que pueden ejecutarse en máquinas heterogéneas, y que pueden escribirse en lenguajes de programación diferentes.

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las 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. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema. La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones

Permite que diversos componentes de software escritos en múltiples lenguajes de programación y que corren en diferentes computadoras, puedan trabajar juntos. Facilita el desarrollo de aplicaciones distribuidas en entornos heterogéneos.

- Cliente-Servidor. 

 

  

 

La capacidad de proceso está repartida entre los clientes y los servidores Son importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico


Diseño y Arquitectura de Software 

 Sistemas interactivos

- Modelo-vistacontrolador

 

- Presentaciónabstracción-control

 

Sistemas adaptables

   

con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta. Separación de las partes lógicas y físicas que conforman la solución de software El patrón de arquitectura de software Modelo-VistaControlador (MVC) se centra únicamente en la separación de las tareas de un sistema de software Un sistema de software se divide en 3 partes: Lo que el usuario ve (pantallas), que es la parte específica que representa la capa de la Vista La aplicación de las reglas de negocio propias del contexto, que es la parte específica que representa la capa del Controlador y, En dónde se almacenan los datos, que es la parte específica que representa la capa del Modelo. Modelo: es la representación de los datos de la aplicación, generados y almacenados dentro del ámbito de su competencia. Un sistema puede tener muchas fuentes de datos (manejadores de bases de datos, hojas de cálculo, archivos de texto plano, sistemas de información, entre otros) de las cuales toma información. La capa del modelo debe ser capaz de recuperarlos y mostrarlos a las demás capas sin que “se enteren” del trabajo que tuvo que realizar para lograrlo. Vista: es la representación del Modelo en un formato amigable al usuario y permite su interacción. Está representada por la interfaz gráfica de usuario (GUI, por sus siglas en inglés), que es el conjunto de ventanas donde el usuario interactúa con la aplicación. En esta capa del software recibe información procesada y representada de manera clara y fácil de interpretar, ingresa datos si es que el uso así lo amerita. Controlador: aplicación del funcionamiento propio del contexto, responde a peticiones del usuario hechas desde la vista y a su vez, hace peticiones al modelo para tomarlo como entrada para su proceso. Puede tomarse como la parte de comunicación entre el modelo y la vista, aplicando reglas de existencia entre ellos

La idea principal sobre la cual gira el PAC es la de agentes cooperativos que hacen una función bastante similar a una capa en el MVC. Los agentes tienen una organización jerárquica que define el arquitecto de software y con una función específica dentro del sistema en general; la jerarquía está compuesta por tres capas, de ahí viene el nombre del patrón: Presentación, Abstracción, Control. La presentación tiene el mismo trabajo que Vista en el modelo MVC. La abstracción se encarga del manejo y almacenamiento de los datos, aunque puede haber más agentes encargados de esta tarea. Una representación multiagente para la abstracción. El control se equipara al controlador en MVC. Recibe eventos disparadores desde la presentación o desde la abstracción y da respuesta a ellos respecto a las reglas de funcionamiento que se hayan impuesto dentro de él. Igual puede tener una visión multiagente. Un sistema adaptable es aquel que se modifica en función de las circunstancias específicas que se presenten en ese momento particular. Las circunstancias pueden ser modificaciones no predecibles en el ámbito de aplicación de sistema, variables no consideradas en la concepción inicial del diseño de éste. La entropía, que es el “desorden” de un sistema y que

Permite realizar aplicaciones entendibles, con muy baja interdependencia entre capas lo que implica aplicaciones entendibles y fáciles de mantener

Separa las aplicaciones en:  Modelo.- reglas de negocio  Vista.- interfaz de usuario  Controlador.- indica hacia que capa (programa) debe continuar la ejecución del sistema

Permite realizar aplicaciones entendibles, con muy baja interdependencia entre capas lo que implica aplicaciones entendibles y fáciles de mantener

Separa las aplicaciones en:  Abstracción.- reglas de negocio, manejo y almacenamiento de datos  Presentación.- interfaz de usuario  Control.- indica hacia que capa (programa) debe continuar la ejecución del sistema.

Tolera fallos de diseño (entropía interna) compensándolas con su principal característica, la adaptabilidad. Son tolerantes a la entropía, a variables no consideradas y a las modificaciones no esperadas, sea


Diseño y Arquitectura de Software 

puede tener origen en el interior o el exterior. Los sistemas adaptables son tolerantes a la entropía, a estas variables no consideradas y a las modificaciones no esperadas, sea cual sea el origen de éstas. Tolera fallos de diseño (entropía interna) compensándolas con su principal característica, la adaptabilidad.

cual sea el origen de éstas

- Reflexión         

- Microkernel

   

 

  

El patrón “reflexión” provee un mecanismo para cambiar la estructura y comportamiento de un software de manera dinámica. Soporta la modificación de aspectos fundamentales, como los tipos de estructura y el mecanismo de llamados a funciones. En este patrón, la aplicación se divide en dos partes. Un meta nivel provee información acerca de propiedades y comportamiento particulares del sistema y posibilita modificarlas. Un nivel de base incluye la lógica de la aplicación, pero sigue lo especificado en el meta nivel. Cambios en el meta nivel impactan en el nivel base. A veces sólo se utiliza el meta nivel para observar el nivel base, pero no modificarlo. Otras veces, los cambios están permitidos. Generalmente, la reflexión es dinámica (en tiempo de ejecución). Lenguajes de programación como Java, C# o Python disponen de un meta nivel para sus aplicaciones utilizando el patrón Reflexión.

El patrón microkernel aplica claramente a sistemas de software que son susceptibles a cambios en el tiempo. Separan la mínima funcionalidad principal (el core) de la funcionalidad extendida y las partes específicas del cliente. También sirve como un socket para encastrar estas extensiones y coordinar su colaboración. Durante el diseño de un sistema aplicando el patrón microkernel, es fundamental encontrar las funcionalidades esenciales que necesitarán la gran mayoría de las extensiones. Estas funcionalidades formarán parte del “microkernel” y brindarán servicios básicos hacia el resto de los componentes. Se buscará un equilibrio en el número de funcionalidades. Es necesario que el tamaño del microkernel no sea muy grande, pero tiene que cubrir todas las necesidades básicas de las extensiones. El microkernel provee dos tipos de componentes “servidores”. Unos internos, que extienden la funcionalidad que provee el microkernel, y unos externos que proveen interfaces de programación a los clientes. Los “servidores” internos sólo son utilizados por los externos a través del microkernel como una extensión de este. Los externos resuelven a través del microkernel la funcionalidad invocada por los clientes. El cliente no interactúa directamente sobre los servidores externos, sino que lo hace a través de adapters.

Provee un mecanismo para cambiar la estructura y comportamiento del software de manera dinámica. Soporta la modificación de los tipos de estructura y el mecanismo de llamados a funciones.

La principal o más conocida utilidad del microkernel es en su aplicación en el desarrollo de sistemas operativos por lo cual es necesario que el tamaño del microkernel no sea muy grande, pero tiene que cubrir todas las necesidades básicas de las extensiones


Diseño y Arquitectura de Software CASO DE ESTUDIO.  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.  Al mismo tiempo los usuarios podrán comentar sobre su experiencia de compran en línea o en el sitio. Estos comentarios los podrán hacer a través de un equipo de cómputo convencional o a través de un dispositivo móvil que será capaz de conectarse al sitio de la tienda.  Que sus proveedores puedan acceder a un sitio privado y vean automáticamente las existencias del producto que surten.  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 de 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, el grado escolar y comentarios hechos).  Deberá ser fácil de usar para todos los usuarios.  Deberá de manejar diferentes tipos de roles (administrador del sitio, gerente general, gerente de la tienda, vendedor, proveedor, usuario normal).  Cada rol tendrá acceso a diferentes privilegios asignados por el administrador del sitio.


Diseño y Arquitectura de Software Propuesta de solución en base a los requerimientos del caso de estudio. En base a los requerimientos del caso de estudio de esta unidad 2 es propuesta la siguiente solución a la problemática de la tienda de conveniencia. Elemento arquitectónico. Lenguaje de definición -> UML

Categoría de tipo de Patrón -> Patrones Simples

Patrón -> Patrón de Capas.

Características del patrón arquitectónico.

Justificación Se propone UML como lenguaje de arquitectura porque tiene todas las virtudes de un lenguaje de programación y permite modelar o abstraer la realidad que pretendemos solucionar por medio de un sistema computacional como es el caso de estudio de la tienda de conveniencia. UML nos permite comunicarnos con los cliente, es decir, mostrarles cómo va a quedar la solución al planteamiento de la tienda de conveniencia y con los desarrolladores al mostrarles que se pretende hacer con un cierto modulo o clase. En la tabla del Categorías de tipos de patrones arquitectónicos del archivo U2_Modelos_de_Arquitectura(2).pdf, esta resumida la clasificación de tipos de patrones o estilos arquitectónicos. Una de las categorías son los Patrones Simples. Dentro de esta categoría se encuentra el patrón de Capas. El patrón por capas es el elegido en esta propuesta. También se propone software confiable y probado en el mercado como el lenguaje de programación Java, el cual permite la programación de clases (core Java), web (Servlets, JSPs) y dispositivos móviles (Java micro edition) y el DBMS MySql. Se propone este patrón por que separa 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. El patrón por capas será dividido en las capas que se enuncian a continuación:  Lo que el usuario ve (pantallas), que es la parte específica que representa la capa de la Presentación.  La aplicación de las reglas de negocio propias del contexto, que es la parte específica que representa la capa del Negocio.  En dónde se almacenan los datos, que es la parte específica que representa la capa de Datos.


Diseño y Arquitectura de Software Propuesta de solución. De acuerdo a los puntos vistos en las páginas previas la propuesta de solución contendrá los siguientes elementos en las diferentes capas. Capa. Negocio.

Presentación.

Datos.

Elementos de la capa. Programas: o Programa que ejecuta las operaciones de los vendedores. o Programa que ejecuta las operaciones de los clientes desde la computadora. o Programa que ejecuta las operaciones de los clientes desde el dispositivo móvil. o Programa que ejecuta las operaciones de los proveedores. o Programa que ejecuta las operaciones del gerente. o Programa que ejecuta las operaciones del gerente general. Pantallas o interfaces para la computadora. Pantalla común a todos los usuarios: o Pantalla de inicio. o Pantalla de autenticación. o Pantalla de ayuda. Pantallas para el vendedor: o Pantalla de venta. o Pantalla de ayuda Pantallas cliente: o Pantalla de registro. o Pantalla de compra. o Pantalla de comentarios. o Pantalla de sugerencias de compra. o Pantalla de ayuda. Pantallas de proveedores: o Pantalla de existencias. o Pantalla de ayuda. Pantallas del gerente: o Pantalla de tendencias de ventas. o Pantalla de ayuda. Pantallas del gerente general: o Pantalla de administración de proveedores, vendedores, gerentes. o Pantalla de ayuda. Pantallas para el dispositivo móvil: o Pantalla de comentarios de la experiencia de compra en línea. o Pantalla de comentarios respecto al sitio. o Pantalla de ayuda. Base de datos con las tablas de: o Ventas.


Dise単o y Arquitectura de Software o o o o o o o o o

Detalle de ventas. Usuarios. Vendedores. Clientes. Proveedores. Gerentes. Gerente general. Inventario o productos. Comentarios.


Dise単o y Arquitectura de Software


Dise単o y Arquitectura de Software


Dise単o y Arquitectura de Software Referencias: o o o o o o

Wikipedia Unidad uno y dos esad Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, 1996. Shaw, M., Garlan, D. Patterns of Enterprise Application architecture. Addison-Wesley, 2002. Fowler, M. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Gamma, E., Helm, R., Johnson, R., Vlissides, J.


Drs u2 ea guai retroalim 22 sep 13