Lenguaje descriptor y patrones de arquitectura de software.
2012
1
Lenguaje descriptor y patrones de arquitectura de software. Unidad 2, Evidencia de aprendizaje.
UNAD
Matrícula: AL10528218 | Confidencial
Alumno: Edgar García Contreras Matrícula: AL10528218 Grupo: DS-DRS-1203-001 Facilitador: José Francisco Ruiz López
Lenguaje descriptor y patrones de arquitectura de software.
2
Contenido Introducción. ....................................................................................3 Contrastando arquitectura y patrón de diseño. ................................4 Tiendas de conveniencia. ...............................................................4 Justificación del uso del patrón. .....................................................6 Presentación de la arquitectura de capas propuesta. ....................8 Conclusiones. ..................................................................................11 Bibliografía. .....................................................................................12
Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
3
Introducción. 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_EDGC. 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| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
4
Contrastando arquitectura y patrón de diseño. Tiendas de conveniencia. Se llaman tiendas de conveniencia a los establecimientos con menos de 500 m², con un horario comercial superior a las 18 horas, un periodo de apertura de 365 días del año. De ahí el nombre popular de 24 horas.
El concepto de tiendas de conveniencia ha sufrido cambios debido a la constante y dinámica modernización del mercadeo, tratando de mejorar los niveles de satisfacción y de servicio acorde a las necesidades del cliente y las exigencias del mercado actual. Este concepto en si es diferente al de tiendas de autoservicio y vienen a substituir a la antigua tienda de "la esquina", con respecto a la imagen, servicio y distribución. Son tiendas más profesionalizadas y menos personalizadas denominándoseles también tiendas de emergencia, ya que la mercancía o el producto pueden requerirse en un momento dado. En la actualidad los bienes conveniencia se refieren a los bienes de consumo que el cliente usualmente compra con frecuencia, inmediatamente y con el mínimo esfuerzo. Algunos también lo llaman " bienes de compra rápida". La conveniencia o comodidad puede estar representada en términos de cercanía a la casa del comprador, fácil acceso a algún medio de transporte, proximidad a lugares donde la gente va durante el día y la noche. Tienen un amplio surtido de productos, centrado en bebidas, alimentación, bazar, etc. A cambio de la amplitud de horarios y la variedad de productos, sus precios suelen ser ligeramente superiores a los de los supermercados al uso. Generalmente, se ubican en el centro de las ciudades aunque también se engloban bajo esta denominación otros locales como, por ejemplo: los situados junto a gasolineras o las tiendas situadas en los aeropuertos. Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
5
Las tiendas de conveniencia, por su tamaño, ofrecen una variedad menor de productos que los supermercados, pero aun considerable por sí sola. Los productos ofrecidos suelen centrarse en bebidas (alcohólicas y no alcohólicas) y alimentos, principalmente comida chatarra (panecillos, frituras, dulces y golosinas), comida rápida, enlatados, congelados, conservas y minoritariamente, productos frescos. Debido a que los clientes suelen ir de paso o con prisa, es frecuente que se venda comida preparada y consumible inmediatamente, como sándwiches refrigerados, hot dogs y café.
Debido a las necesidades del mercado, muchas tiendas de conveniencia también proveen periódicos, revistas, productos de uso doméstico y para la higiene personal, así como fármacos de venta libre.
Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
6
Justificación del uso del patrón. Retomando el caso de estudio de la actividad 2, nos dice: “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” En base a lo estudiado en la unidad, el patrón arquitectónico más conveniente para la solución de este caso es el de capas. En primer lugar, quiero explicar por qué descarté los patrones de tubería-filtro y pizarra, para posteriormente reforzar los motivos de la elección del patrón arquitectónico elegido. Según la narración del caso, se trata del diseño de un portal web, la interfaz es una pantalla de computadora o de un dispositivo móvil, en donde el patrón tubería-filtro presenta las siguientes desventajas:
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.
En cuanto al patrón de pizarra o tableros, 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. No es el caso del problema que estamos desarrollando. Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
7
En cuanto al patrón de capas, que es el que propongo para este caso, tenemos las siguientes características:
El estilo también se encuentra en forma más o menos pura en arquitecturas de bases de datos y sistemas operativos, así como en las especificaciones relacionadas con XML. A nivel arquitectónico, se puede tratar con XML en diversos planos de abstracción. El estilo soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un problema complejo en una secuencia de pasos incrementales. El estilo admite muy naturalmente optimizaciones y refinamientos. Proporciona amplia reutilización. Se pueden utilizar diferentes implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes.
El número adecuado de capas 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. Cuando hablamos de una aplicación de N capas, estas pueden ser las siguientes:
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 o Modelo lógico de Datos o Clases Base (Patrón Layer-Supertype) o Infraestructura tecnología ORM Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
8
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.
Presentación de la arquitectura de capas propuesta. Para la solución de este caso propongo una arquitectura de 3 capas: 1. Capa de presentación. 2. Capa de negocios. 3. Capa de acceso a datos.
Continuando con el desarrollo de la aplicación del patrón arquitectónico al caso de estudio podemos observar las siguientes capas a utilizar: Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
9
Capa de Presentación Esta capa es responsable de mostrar información al usuario e interpretar sus acciones. Los componentes de las capas de presentación implementan la funcionalidad requerida para que los usuarios interactúen con la aplicación. En esta capa se encuentran los formularios y los controles de los mismos. Es en esta capa donde se proporcionan los mecanismos base para que el usuario utilice la aplicación, así como la ayuda para sincronizar y orquestar las interacciones del usuario. La finalidad de esta primera capa es la de traducir funciones y resultados en algo que el usuario pueda comprender. Con esta capa estamos cubriendo el requisito “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” Capa de negocios.
Gestiona las reglas negocio o la lógica empresarial de la aplicación y puede acceder a funciones de la tercera capa. En este nivel se implementa la parte esencial de la aplicación, la funcionalidad que proporciona. De esta manera, se realizan decisiones lógicas, evaluaciones y cálculos. Asimismo, traslada y procesa datos entre la primera y segunda capa. Esta capa proporciona un medio de acceso remoto basado en canales de comunicación y mensajes de datos.
Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
10
En esta capa implementaremos los servicios Web, de manera que los clientes y proveedores puedan consultar la información en línea, así como enviar sus comentarios. Aquí implementamos la coordinación de la “fontanería” de la aplicación, como coordinación de transacciones, ejecución de unidades de trabajo, y en definitiva llamadas a tareas necesarias para la aplicación (software como tal). Otros aspectos a implementar aquí pueden ser optimizaciones de la aplicación, conversiones de datos/formatos, etc. pero siempre nos referimos solo a la coordinación. Esta capa define los trabajos que deben realizar la aplicación y redirige a los objetos del dominio y a la infraestructura, quienes son los que deben resolver los problemas Esta capa también 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. También debe contener los estados que reflejan la situación de los procesos de negocio. Capa de Acceso a Datos Esta capa proporciona la capacidad de persistir datos así como lógicamente acceder a ellos. Pueden ser datos propios del sistema o incluso acceder a datos expuestos por sistemas externos (Servicios Web externos, etc.). Así pues, esta capa de persistencia de datos expone el acceso a datos a las capas superiores, normalmente las capas del dominio. En esta capa se encapsulan los componentes que proporcionan los métodos necesarios para la consulta y actualización de la información almacenada. Permite realizar todas las operaciones con la base de datos de forma transparente para la capa de negocio. El propósito primario de esta es separar al proveedor de datos del resto de la aplicación. En este nivel, la información se recupera desde la base de datos y eventualmente es retornada al usuario final del sistema. Capas de Infraestructura Transversal/Horizontal
En esta capa es donde podemos implementar los servicios de Seguridad (Autenticación, Autorización y Validación), para poder validar tanto a los proveedores como a los clientes. También tenemos en esta capa las tareas de gestión de operaciones (políticas, logging, trazas, monitorización, configuración, etc.).
Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software.
11
Conclusiones. En esta actividad se hace uso de un patrón de arquitectura para solucionar un problema de software de una tienda de conveniencia. El patrón arquitectónico propuesto para esta actividad es el de capas, que nos da la oportunidad de cubrir con los requisitos que plantea el caso en cuestión. Este tipo de actividades tienen la finalidad de aplicar los conocimientos adquiridos a situaciones reales, que podemos observar en nuestra vida diaria. Como podemos darnos cuenta, el uso del patrón arquitectónico de capas nos proporciona los siguientes beneficios en su uso en este caso en específico:
Desarrollo estructurado, homogéneo y similar de las diferentes aplicaciones de la tienda de conveniencia. Facilidad de mantenimiento de las aplicaciones pues los diferentes tipos de tareas están siempre situados en las mismas áreas de la arquitectura. Fácil cambio de tipología en el despliegue físico de una aplicación, pues las diferentes capas pueden separarse físicamente de forma fácil.
Diseño y Arquitectura de Software| UNAD
Lenguaje descriptor y patrones de arquitectura de software. Bibliografía. Apuntes de: Diseño y Arquitectura de Software Unidad 2. Modelos de Arquitectura. Reynoso, Carlos (2004) Introducción a la Arquitectura de Software UNIVERSIDAD DE BUENOS AIRES. http://cybertesis.upc.edu.pe/upc/2008/vasquez_dc/html/sdx/vasquez_dc-TH.5.html
Diseño y Arquitectura de Software| UNAD
12