SlideShare una empresa de Scribd logo
1 de 10
Universidad Nacional Abierta y a Distancia Carrera
Ingeniería en Desarrollo de Software
2013
Propuesta de Arquitectura para tienda de
Conveniencia
Alumno: Alfredo Razo Cabeza, Matricula: AL10505782
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
[Escribir la dirección de la compañía]
Índice
Necesidades del usuario 3
Requerimientos 4
Lenguaje ADL Propuesto: ADML 5
Arquitectura Propuesta: N capas orientada al dominio 6
Caso de Uso para ventas 8
Caso de Uso para compras 9
Modelo de Datos para el Servidor 10
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Necesidades del usuario
“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”.
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Requerimientos de la tienda de conveniencia para desarrollo de
Aplicación de ventas en línea
Automatizar procesos:
 Compra
 Venta
 Seguimiento de clientes
 Consulta de tendencia de ventas y sugerencia en base a compras
anteriores (histórico de ventas)
Conectividad exterior por medio de:
 Equipo de cómputo convencional
 Dispositivo móvil
Registro y Actualización de perfil de compradores
Seguridad:
– Control de acceso por tipo de usuario:
 Clientes
 Proveedores
 Administración
– Manejo de roles y permisos para los diferentes tipos de
usuarios.
Servicios
 Correo electrónico
 Internet
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Lenguaje Propuesto ADML
El sistema contempla que la venta sea en línea, ADML a través del manejo de
una interfaz basada en XML puede establecer los vínculos necesarios para
dirigir al cliente hacia diferentes sitios que puedan resultar de interés y de esa
manera encontrar una debida clasificación y variedad de artículos.
Con respecto al proveedor también se puede direccionar hacia el sitio donde se
encuentran los datos de las existencias que provee y saber que productos se
necesita surtir nuevamente por haber alcanzado o estén por alcanzar un stock
mínimo de existencia.
Por lo tanto este lenguaje con sus componentes y su característica de estar
basado en archivos XML, puede ser muy útil en la representación
arquitectónica del caso de esta aplicación para sistematizar las ventas en línea
de la tienda de conveniencia.
“Como hubiera sido de esperarse ante la generalización del desarrollo en la era
del Web, ADML (Architecture Description Markup Language) constituye un
intento de estandarizar la descripción de arquitecturas en base a XML.”
“En consonancia con la expansión de Internet, ADML permite también definir
vínculos con objetos externos a la arquitectura (fundamentación racional,
diseños, componentes, etcétera), así como interactuar con diversos repositorios
de la industria.”
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Arquitectura Propuesta: En capas orientada al
dominio
Este patrón considera el aspecto de seguridad como una fase para todas las
diferentes capas que conforman los sistemas, y por medio de esta
característica se pueden administrar los diferentes roles y privilegios a los
usuarios (que sus proveedores puedan acceder a un sitio privado).
Por otra parte la conectividad que se pretende desde una computadora
convencional o un móvil puede ser cubierta por medio de la capa de
servicios distribuidos (Servicios Web) que forma parte de este patrón.
Otro aspecto importante de este patrón es la capa de infraestructura de
persistencia de datos, esta capa permite almacenar información como la
descrita en el caso “los usuarios podrán comentar sobre su experiencia de
compra en línea o en el sitio”, y el perfil con todos los datos enumerados en
el caso.
Las razones por las que es recomendable hacer uso de una “Arquitectura N
capas Orientada al Dominio”, es especialmente en los casos donde el
comportamiento del negocio a automatizar (lógica del dominio) está sujeta
a muchos cambios y evoluciones. En este caso especifico, disponer de un
“Modelo de Dominio” disminuirá el costo total de dichos cambios y a
mediano plazo será mucho menor que si la aplicación hubiera sido
desarrollada de una manera más acoplada, porque los cambios no tendrán
tanto impacto.
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Ordenar
pedido
Revisa productos
y precios
Recibe y revisa
pedido
Pago de
pedido
Verificar pedido
y existencia
Enviar pedido por
mensajería
Caso de Uso para ventas en línea de tienda de conveniencia
Actores Principales: Clientes y Personal de ventas
Flujo Principal:
Un cliente consulta el conjunto de artículos de la tienda.
El cliente ordena un pedido de los artículos de su interés.
El personal de ventas verifica que haya existencias
El personal de ventas envía pedido por mensajería al cliente
El cliente recibe y revisa pedido
El cliente paga pedido o muestra ficha de depósito de pago (pago electrónico), y el personal de ventas recibe
pago o toma nota de comprobante de pago.
Cliente Ventas
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Caso de Uso para compras
Actores Principales: Personal de Compras y Proveedores
Flujo Principal:
•Los Proveedores y el personal o gerente de compras consultan periódicamente la existencia de artículos de la
tienda.
•El Proveedores informa de la necesidad de volver a surtir algunos artículos.
•El Gerente efectúa el pedido de los artículos que han llegado a una existencia mínima.
•El Proveedores envía pedido a la empresa o al gerente de Ventas.
•El Proveedor entrega pedido y se realiza el pago o el cargo si se trata de compra a crédito
•El departamento de compras actualiza la existencia de productos comprados.
Informar
productos a
resurtir
Consultar
existencias
Se actualizan
archivos de
existencia
Efectuar pedido
Proveedor Gerente comprasEnviar pedido a
la empresa
Pago de pedido
Capturista
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura
Clientes
ClaveCliente
Nombre
Edad
Sexo
Domicilio
Datos de Perfil
Seguimiento
Teléfono
Correo electrónico
Fecha alta
Productos
ClaveProducto
Descripción
Precio
Existencia
ClaveProveedor
Proveedores
ClaveProveedor
Nombre/Razón Social
Domicilio
FechaAlta
TipoDePago
Pedidos
ClaveProducto
ClaveCliente
FechaVenta
Cantidad
Precio
FormaPago
Compras
ClaveProducto
ClaveProveedor
Cantidad
Precio
FechaCompra
•Modelo de Datos para el Servidor
Esta estructura puede ser fácilmente cambiada o ampliada según las necesidades de información de la
tienda, momentáneamente se proporciona un esquema básico de datos.
Diseño y Arquitectura de Software
5 Cuatrimestre
Unidad 2. Modelos de Arquitectura

Más contenido relacionado

La actualidad más candente

Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de softwareJorge Rodriguez
 
Apostila de uml
Apostila de umlApostila de uml
Apostila de umlaudiclerio
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Juan C. S. Suárez
 
Modelo de especificação de caso de uso
Modelo de especificação de caso de usoModelo de especificação de caso de uso
Modelo de especificação de caso de usoLeandro Rodrigues
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareSaraEAlcntaraR
 
Arquitetura Hexagonal: uma introdução
Arquitetura Hexagonal: uma introduçãoArquitetura Hexagonal: uma introdução
Arquitetura Hexagonal: uma introduçãoMorvana Bonin
 
Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Daniel Brandão
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesCarlos Macallums
 
Patrón de diseño Modelo-Vista-Controlador (MVC)
Patrón de diseño Modelo-Vista-Controlador (MVC)Patrón de diseño Modelo-Vista-Controlador (MVC)
Patrón de diseño Modelo-Vista-Controlador (MVC)Jose R. Hilera
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de softwareyecka25
 

La actualidad más candente (14)

Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de software
 
Apostila de uml
Apostila de umlApostila de uml
Apostila de uml
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software
 
Modelo de especificação de caso de uso
Modelo de especificação de caso de usoModelo de especificação de caso de uso
Modelo de especificação de caso de uso
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
 
Arquitetura Hexagonal: uma introdução
Arquitetura Hexagonal: uma introduçãoArquitetura Hexagonal: uma introdução
Arquitetura Hexagonal: uma introdução
 
Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)
 
SOA y Web Services
SOA y Web ServicesSOA y Web Services
SOA y Web Services
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Patrón de diseño Modelo-Vista-Controlador (MVC)
Patrón de diseño Modelo-Vista-Controlador (MVC)Patrón de diseño Modelo-Vista-Controlador (MVC)
Patrón de diseño Modelo-Vista-Controlador (MVC)
 
UML: CASOS DE USO
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USO
 
Abstract Factory
Abstract FactoryAbstract Factory
Abstract Factory
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 

Destacado

Uml videotienda (1)
Uml videotienda (1)Uml videotienda (1)
Uml videotienda (1)cgviviana
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemaUniversidad Tecnológica
 
Proyecto 5 semestre
Proyecto 5 semestreProyecto 5 semestre
Proyecto 5 semestredkwolf
 
Zoraida susan base de datos
Zoraida susan base de datosZoraida susan base de datos
Zoraida susan base de datosmaryzori
 
Desarrollo móvil híbrido bien entendido
Desarrollo móvil híbrido bien entendidoDesarrollo móvil híbrido bien entendido
Desarrollo móvil híbrido bien entendidoJosé Manuel López
 
Arquitectura N-Capas y ADo.NET
Arquitectura N-Capas y ADo.NETArquitectura N-Capas y ADo.NET
Arquitectura N-Capas y ADo.NETRoberto Taborda
 
Recuperar password de root en linux centos
Recuperar password de root en linux centosRecuperar password de root en linux centos
Recuperar password de root en linux centosEcatel SRL
 
1 Introducción a la Arquitectura Empresarial
1  Introducción a la Arquitectura Empresarial1  Introducción a la Arquitectura Empresarial
1 Introducción a la Arquitectura EmpresarialMatersys
 
Tienda y abarrotes el gordo
Tienda y abarrotes el gordoTienda y abarrotes el gordo
Tienda y abarrotes el gordoTIENDAELGORDO
 
Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Marta Silvia Tabares
 

Destacado (15)

Diagrama de casos de usos
Diagrama de casos de usosDiagrama de casos de usos
Diagrama de casos de usos
 
Uml videotienda (1)
Uml videotienda (1)Uml videotienda (1)
Uml videotienda (1)
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 
Abarrotes javier
Abarrotes javierAbarrotes javier
Abarrotes javier
 
Clases 30 05
Clases 30 05Clases 30 05
Clases 30 05
 
Proyecto 5 semestre
Proyecto 5 semestreProyecto 5 semestre
Proyecto 5 semestre
 
Zoraida susan base de datos
Zoraida susan base de datosZoraida susan base de datos
Zoraida susan base de datos
 
Desarrollo móvil híbrido bien entendido
Desarrollo móvil híbrido bien entendidoDesarrollo móvil híbrido bien entendido
Desarrollo móvil híbrido bien entendido
 
Arquitectura N-Capas y ADo.NET
Arquitectura N-Capas y ADo.NETArquitectura N-Capas y ADo.NET
Arquitectura N-Capas y ADo.NET
 
Recuperar password de root en linux centos
Recuperar password de root en linux centosRecuperar password de root en linux centos
Recuperar password de root en linux centos
 
Programacion en n capas
Programacion en n capasProgramacion en n capas
Programacion en n capas
 
1 Introducción a la Arquitectura Empresarial
1  Introducción a la Arquitectura Empresarial1  Introducción a la Arquitectura Empresarial
1 Introducción a la Arquitectura Empresarial
 
Arquitectura Empresarial 11.0
Arquitectura Empresarial 11.0Arquitectura Empresarial 11.0
Arquitectura Empresarial 11.0
 
Tienda y abarrotes el gordo
Tienda y abarrotes el gordoTienda y abarrotes el gordo
Tienda y abarrotes el gordo
 
Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2
 

Similar a Arquitectura N capas para tienda en línea

PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOS
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOSPRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOS
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOSRis Fernandez
 
presentacion BD.pptx
presentacion BD.pptxpresentacion BD.pptx
presentacion BD.pptxAsaelAleman1
 
Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A
Proyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.AProyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.A
Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.AJr. Rodriguez Valladares
 
Especificación de requisitos portal web ok
Especificación de requisitos portal web okEspecificación de requisitos portal web ok
Especificación de requisitos portal web okgonzalo de la campa
 
Tienda Virtual.- Gygacom
Tienda Virtual.- GygacomTienda Virtual.- Gygacom
Tienda Virtual.- GygacomHikaiwaba
 
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTAPROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTARoyer Tuesta Salas
 
Analisis de requisitos
Analisis de requisitosAnalisis de requisitos
Analisis de requisitosVivianaMl
 
Desarrollo fi s2
Desarrollo fi s2Desarrollo fi s2
Desarrollo fi s2svaclaro
 
Prestashop en 15 minutos
Prestashop en 15 minutosPrestashop en 15 minutos
Prestashop en 15 minutosJordiob.com
 
Solucion ccna1 s ssssiii1
Solucion ccna1 s ssssiii1Solucion ccna1 s ssssiii1
Solucion ccna1 s ssssiii1josequin1011
 
Proceso de e commerce
Proceso de e commerceProceso de e commerce
Proceso de e commerceSamuel Mejia
 
Informe de practicas Pre_Profesional_I
Informe de practicas Pre_Profesional_IInforme de practicas Pre_Profesional_I
Informe de practicas Pre_Profesional_IWilmer Vera Ostios
 
Arquitectura Para El Comercio Electrónico
Arquitectura Para El Comercio ElectrónicoArquitectura Para El Comercio Electrónico
Arquitectura Para El Comercio ElectrónicoSamPinilla
 
Diseño y construcción de un software para una tienda
Diseño y construcción de un software para una tiendaDiseño y construcción de un software para una tienda
Diseño y construcción de un software para una tiendaOscar Hernando Sanchez Roa
 

Similar a Arquitectura N capas para tienda en línea (20)

Drs u2 ea_fegc
Drs u2 ea_fegcDrs u2 ea_fegc
Drs u2 ea_fegc
 
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOS
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOSPRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOS
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOS
 
presentacion BD.pptx
presentacion BD.pptxpresentacion BD.pptx
presentacion BD.pptx
 
PROYECTO FINAL ANÀLISIS Y DISEÑO ll
PROYECTO FINAL ANÀLISIS Y DISEÑO llPROYECTO FINAL ANÀLISIS Y DISEÑO ll
PROYECTO FINAL ANÀLISIS Y DISEÑO ll
 
Analisis y diseño exposicion
Analisis y diseño exposicionAnalisis y diseño exposicion
Analisis y diseño exposicion
 
Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A
Proyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.AProyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.A
Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A
 
Especificación de requisitos portal web ok
Especificación de requisitos portal web okEspecificación de requisitos portal web ok
Especificación de requisitos portal web ok
 
Drupal commerce
Drupal commerceDrupal commerce
Drupal commerce
 
Tienda Virtual.- Gygacom
Tienda Virtual.- GygacomTienda Virtual.- Gygacom
Tienda Virtual.- Gygacom
 
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTAPROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
 
Analisis de requisitos
Analisis de requisitosAnalisis de requisitos
Analisis de requisitos
 
Desarrollo fi s2
Desarrollo fi s2Desarrollo fi s2
Desarrollo fi s2
 
Distribucion udes ii
Distribucion   udes iiDistribucion   udes ii
Distribucion udes ii
 
Prestashop en 15 minutos
Prestashop en 15 minutosPrestashop en 15 minutos
Prestashop en 15 minutos
 
Solucion ccna1 s ssssiii1
Solucion ccna1 s ssssiii1Solucion ccna1 s ssssiii1
Solucion ccna1 s ssssiii1
 
Proceso de e commerce
Proceso de e commerceProceso de e commerce
Proceso de e commerce
 
Informe de practicas Pre_Profesional_I
Informe de practicas Pre_Profesional_IInforme de practicas Pre_Profesional_I
Informe de practicas Pre_Profesional_I
 
Arquitectura Para El Comercio Electrónico
Arquitectura Para El Comercio ElectrónicoArquitectura Para El Comercio Electrónico
Arquitectura Para El Comercio Electrónico
 
Diseño y construcción de un software para una tienda
Diseño y construcción de un software para una tiendaDiseño y construcción de un software para una tienda
Diseño y construcción de un software para una tienda
 
Proceso de e commerce
Proceso de e commerce Proceso de e commerce
Proceso de e commerce
 

Arquitectura N capas para tienda en línea

  • 1. Universidad Nacional Abierta y a Distancia Carrera Ingeniería en Desarrollo de Software 2013 Propuesta de Arquitectura para tienda de Conveniencia Alumno: Alfredo Razo Cabeza, Matricula: AL10505782 Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura [Escribir la dirección de la compañía]
  • 2. Índice Necesidades del usuario 3 Requerimientos 4 Lenguaje ADL Propuesto: ADML 5 Arquitectura Propuesta: N capas orientada al dominio 6 Caso de Uso para ventas 8 Caso de Uso para compras 9 Modelo de Datos para el Servidor 10 Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 3. Necesidades del usuario “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”. Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 4. Requerimientos de la tienda de conveniencia para desarrollo de Aplicación de ventas en línea Automatizar procesos:  Compra  Venta  Seguimiento de clientes  Consulta de tendencia de ventas y sugerencia en base a compras anteriores (histórico de ventas) Conectividad exterior por medio de:  Equipo de cómputo convencional  Dispositivo móvil Registro y Actualización de perfil de compradores Seguridad: – Control de acceso por tipo de usuario:  Clientes  Proveedores  Administración – Manejo de roles y permisos para los diferentes tipos de usuarios. Servicios  Correo electrónico  Internet Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 5. Lenguaje Propuesto ADML El sistema contempla que la venta sea en línea, ADML a través del manejo de una interfaz basada en XML puede establecer los vínculos necesarios para dirigir al cliente hacia diferentes sitios que puedan resultar de interés y de esa manera encontrar una debida clasificación y variedad de artículos. Con respecto al proveedor también se puede direccionar hacia el sitio donde se encuentran los datos de las existencias que provee y saber que productos se necesita surtir nuevamente por haber alcanzado o estén por alcanzar un stock mínimo de existencia. Por lo tanto este lenguaje con sus componentes y su característica de estar basado en archivos XML, puede ser muy útil en la representación arquitectónica del caso de esta aplicación para sistematizar las ventas en línea de la tienda de conveniencia. “Como hubiera sido de esperarse ante la generalización del desarrollo en la era del Web, ADML (Architecture Description Markup Language) constituye un intento de estandarizar la descripción de arquitecturas en base a XML.” “En consonancia con la expansión de Internet, ADML permite también definir vínculos con objetos externos a la arquitectura (fundamentación racional, diseños, componentes, etcétera), así como interactuar con diversos repositorios de la industria.” Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 6. Arquitectura Propuesta: En capas orientada al dominio Este patrón considera el aspecto de seguridad como una fase para todas las diferentes capas que conforman los sistemas, y por medio de esta característica se pueden administrar los diferentes roles y privilegios a los usuarios (que sus proveedores puedan acceder a un sitio privado). Por otra parte la conectividad que se pretende desde una computadora convencional o un móvil puede ser cubierta por medio de la capa de servicios distribuidos (Servicios Web) que forma parte de este patrón. Otro aspecto importante de este patrón es la capa de infraestructura de persistencia de datos, esta capa permite almacenar información como la descrita en el caso “los usuarios podrán comentar sobre su experiencia de compra en línea o en el sitio”, y el perfil con todos los datos enumerados en el caso. Las razones por las que es recomendable hacer uso de una “Arquitectura N capas Orientada al Dominio”, es especialmente en los casos donde el comportamiento del negocio a automatizar (lógica del dominio) está sujeta a muchos cambios y evoluciones. En este caso especifico, disponer de un “Modelo de Dominio” disminuirá el costo total de dichos cambios y a mediano plazo será mucho menor que si la aplicación hubiera sido desarrollada de una manera más acoplada, porque los cambios no tendrán tanto impacto. Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 7.
  • 8. Ordenar pedido Revisa productos y precios Recibe y revisa pedido Pago de pedido Verificar pedido y existencia Enviar pedido por mensajería Caso de Uso para ventas en línea de tienda de conveniencia Actores Principales: Clientes y Personal de ventas Flujo Principal: Un cliente consulta el conjunto de artículos de la tienda. El cliente ordena un pedido de los artículos de su interés. El personal de ventas verifica que haya existencias El personal de ventas envía pedido por mensajería al cliente El cliente recibe y revisa pedido El cliente paga pedido o muestra ficha de depósito de pago (pago electrónico), y el personal de ventas recibe pago o toma nota de comprobante de pago. Cliente Ventas Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 9. Caso de Uso para compras Actores Principales: Personal de Compras y Proveedores Flujo Principal: •Los Proveedores y el personal o gerente de compras consultan periódicamente la existencia de artículos de la tienda. •El Proveedores informa de la necesidad de volver a surtir algunos artículos. •El Gerente efectúa el pedido de los artículos que han llegado a una existencia mínima. •El Proveedores envía pedido a la empresa o al gerente de Ventas. •El Proveedor entrega pedido y se realiza el pago o el cargo si se trata de compra a crédito •El departamento de compras actualiza la existencia de productos comprados. Informar productos a resurtir Consultar existencias Se actualizan archivos de existencia Efectuar pedido Proveedor Gerente comprasEnviar pedido a la empresa Pago de pedido Capturista Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura
  • 10. Clientes ClaveCliente Nombre Edad Sexo Domicilio Datos de Perfil Seguimiento Teléfono Correo electrónico Fecha alta Productos ClaveProducto Descripción Precio Existencia ClaveProveedor Proveedores ClaveProveedor Nombre/Razón Social Domicilio FechaAlta TipoDePago Pedidos ClaveProducto ClaveCliente FechaVenta Cantidad Precio FormaPago Compras ClaveProducto ClaveProveedor Cantidad Precio FechaCompra •Modelo de Datos para el Servidor Esta estructura puede ser fácilmente cambiada o ampliada según las necesidades de información de la tienda, momentáneamente se proporciona un esquema básico de datos. Diseño y Arquitectura de Software 5 Cuatrimestre Unidad 2. Modelos de Arquitectura