drs_u2_a2_roag

Diseño y Arquitectura de SoftwareUnidad 2 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.

El proceso de análisis basado en modelos UML.UML: Unified Modeling Language, Lenguaje Unificado de Modelado, se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema software.

NOMBRE: Roberto Álvarez GranadosMATRÍCULA: AL12501836CARRERA: Ingeniería en Desarrollo de Software

1


En este apartado se abordar la fase de análisis, con ayuda de la metodología UML en donde se desarrollará un modelo de la aplicación donde diferenciaremos a los actores que interactúan con los objetos del sistema mediante distintas relaciones.Considerando que análisis es el proceso de construcción de un modelo, o especificación detallada del problema del mundo real al que nos enfrentamos. Está desprovisto de consideraciones de diseño e implementación. Todo esto nos ayudará a crear un sistema robusto y mantenibles.La notación que propongo utilizar es la proporcionada por el estándar UML. En este caso usaremos los diagramas de clases, casos de uso y diagramas de secuencia.

2. Identificar qué patrón será el que se utilizará para representar esta arquitectura propuesta.

Realizaremos una descripción de nuestro proyecto con un mayor nivel de detalle, teniendo en cuenta las características de un entorno Web.Plantearemos como llevar a cabo la implementación de la aplicación Web pero, sin entrar en los detalles de una tecnología concreta. Definiendo la arquitectura que define los principales componentes de nuestra aplicación en el contexto de un entorno Web.Utilizaré el Patrón de arquitectura multicapa.Una arquitectura multicapa es un conjunto ordenado de subsistemas, cada uno de los cuales están constituidos en términos de los que tiene por debajo y proporciona la base de la implementación de aquellos que están por encima de él.Los objetos de cada capa suelen ser independientes, aunque suelen haber dependencias entre objetos de distintas capas.Existe una relación cliente/servidor entre las capas inferiores, que son las que proporcionan los servicios, y las capas superiores, los usuarios de estos servicios.El diseño de nuestra aplicación se basa en una arquitectura multicapa, más concretamente en una arquitectura de tres capas:

Capa de presentación, también conocida como interfaz gráfica, se encarga de la presentación de los resultados al usuario y la recogida de información del usuario al sistema.

Capa de negocio o lógica de la aplicación, proporciona la funcionalidad de la aplicación. Es el encargado de realizar todas las operaciones a nivel aplicación.


2


Capa de datos o persistencia, este nivel es el encargado de almacenar toda la información de nuestra aplicación, además de asegurar el acceso a la información de una forma controlada y segura. Este nivel lo forman la base de datos y el software de gestión de base de datos.

Nivel de presentación.En nuestra aplicación existen siete perfiles distintos por lo tanto siete vistas, la del usuario anónimo, usuario registrado, administrador, gerente general, gerente de tienda, vendedor y proveedor. El diseño de la interfaz será similar en estas siete vistas, con la diferencia de que dependiendo del usuario este disponga de más o menos opciones en su menú.

La organización de nuestra aplicación Web será la siguiente:

Parte superior, contendrá el logotipo junto al nombre de nuestra tienda.Nos permitirá darnos de alto o bien realizar el registro de nuevo usuario, además de visualizar nuestro carrito de la compra y salir de la sesión de nuestro usuario.El usuario anónimo, dispondrá de las opciones de búsqueda de productos del catálogo, al igual que el resto de usuarios.El usuario registrado podrá completar las compras además de poder realizar las funciones del usuario anónimo.Al administrador se le añaden las opciones de gestión de categorías, producto, socios registrados y compras. Que incorporan tanto las opciones de altas y bajas así como cambio de estados en las compras. Y permite realizar todo tipo de listados.Al gerente general son las mismas que el administrador, solamente que no tiene las opciones de altas y bajas así como como cambio de estados en las compras.Al gerente de tienda se le permite realizar todo tipo de listados.


3


Al vendedor solamente se le permite listar o consultar lo referente a su área lo mismo que al proveedor.En el marco izquierdo de las principales pantallas incorporaremos el catálogo de productos informáticos, dividido en categorías.En el centro de la pantalla aparecerá la descripción del producto cuando sea seleccionado, así como los formularios de registro. Si es el administrador el usuario identificado, entonces utilizaremos la pantalla central para toda la presentación de las acciones que se puedan llevar a cabo.Las siguientes capturas corresponden con los distintos perfiles que hemos definido en nuestra aplicación.En la zona que más nos guste estará ubicado el logotipo de nuestra empresa ficticia, este logo aparecerá en la misma zona en todas nuestras páginas independientemente del perfil de usuario que acceda a la aplicación.En nuestro menú de navegación justo debajo del logotipo de la empresa, el cual se compondrá de las siguientes opciones:

Inicio, nos lleva hasta la página principal, en nuestro caso index.php. Login desde aquí insertando nuestro nombre de usuario y password se nos

permite identificarnos siempre que estemos dados de alta. Dar de alta, esta opción permite al usuario anónimo rellenar un formulario

para registrarse. Carrito en este apartado podremos realizar la consulta de los productos que

se van añadiendo para su posterior compra. Administrar podremos acceder, siempre que seamos usuario administrador,

a las opciones de gestión. Gerente General podremos acceder, siempre que seamos usuario Gerente

General, a las opciones de gestión. Gerente de tienda podremos acceder, siempre que seamos usuario

Gerente de tienda, a las opciones de gestión. Vendedores podremos acceder, siempre que seamos usuario vendedor, a

las opciones de gestión. Proveedores podremos acceder, siempre que seamos usuario proveedor, a

las opciones de gestión. Logout este botón permite eliminar la sesión actual, es decir borrará todos

los productos del carro y la sesión de usuario.

En esta primera plantilla en el lateral izquierdo estará ubicada la zona donde aparecerán desplegadas las distintas categorías, las categorías aparecerán en


4


toda las páginas de usuario anónimo y registrado a excepción del carrito de la compra.En el pie de página estará ubicado todo lo referente a gastos, envíos, información de la empresa, normativa de compra, protección de datos y contacto.La zona superior derecha estará una pequeña aplicación que nos permitirá realizar una búsqueda, introduciendo una palabra o frase, nos dará como resultado todos los productos que contengan dicha clave.Para terminar en la zona central de nuestra pantalla, donde nos irán apareciendo los productos, sus características, los formularios de registro y acceso, los mensajes de erros o éxito…Otra plantilla será la zona de carrito de la compra, la cual se podrá acceder con cualquiera de los usuarios a excepción de la última parte de confirmación de compra, no accesible para anónimos.Y una tercera y última plantilla corresponde a la zona de gestión, solo accesible por nuestro usuario administrador.En la parte central, aparecerán las opciones de gestión del administrador, una vez elegidas se accederá a los formularios que permitirán realizar listados, cambios, altas y bajas de los distintos productos, usuarios, categorías y pedidos.

Nivel de lógica de la aplicación.

Este nivel estará formado por un conjunto de funciones que agruparemos en librerías, estas funciones sustituyen a los métodos que tendrían las clases correspondientes a los diagramas de clases de UML.Su funcionalidad hará posible las operaciones descritas en apartados anteriores, conexión con la base de datos, manipulación de la base de datos, validación de usuarios y datos, registro socios, alta productos, listar usuarios, búsqueda de productos…La separación por capas nos permite tener una independencia entre niveles, de esta manera el mantenimiento y las posibles ampliaciones de la aplicación se realizarán de una forma sencilla, rápida y limpia.

Nivel de datos o persistencia.

Este nivel estará formado por una base de datos relacional, la cual, almacenará todos los datos relacionados con nuestra aplicación Web, tanto usuarios registrados, como los datos de todos los productos de nuestro catálogo, las compras…


5


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).

Conclusión:

En resumen la experiencia ha sido muy grata, el aprendizaje muy completo y satisfactorio mejorando las expectativas que tenía. Pienso que al principio estaba en el limbo pero poco a poco y todo este esfuerzo me llevaron a entender claramente este tema.


6

drs_u2_a2_roag

Documents