Universidad Libre de Colombia<

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE INFORMACIN EN LA NUBE.

Documento de Arquitectura de Software

Version <1.0>

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

Historial de revisiones
Date
16/FEB/02

Confidencial

Version

Description

Author

1.0

Universidad Libre<, 2016

Page 2 of 7

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

Table of Contents
1.

Introduccin
1.1
Propsito.
1.2
Alcance
1.3
Definiciones, Acrnimos, y Abreviaturas
1.4
Referencias
1.5
Visin de Conjunto

2.

Representacin Arquitectnica

3.

Objetivos Arquitectnicos y Coacciones

4.

Vista de Caso de Uso

5.

Vista Lgica
5.1
Visin de Conjunto
5.2
Paquetes de Diseo Arquitectnicamente Significativos
5.3
Realizaciones de Caso de Uso

6.

Vista de Procesos

7.

Vista de Despliegue

8.

Vista de Implementaciones
8.1
Vista de Conjunto
8.2
Capas

9.

Vista de Datos(Optional)

10.

Tamao y Rendimiento

11.

Calidad

Confidencial

Universidad Libre<, 2016

Page 3 of 7

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

Documentacin de Arquitectura de Software

Funcionales.
1- El sistema debe registrar las ventas realizadas en un punto de venta.
2- La aplicacin deber permitir al usuario administrador del sistema agregar al sistema de ms de 1500
productos, editarlos o eliminarlo en caso de necesitar hacerlo, no podr editar el cdigo del producto el
cual es definido por la base de datos.
3- El usuario admin del sistema podr eliminar facturas registradas en el sistema.
4- El usuario admin del sistema podr solicitar al sistema, los reportes de ventas en un lapso de tiempo
definido manualmente por el usuario administrador.
5- El usuario admin del sistema podr solicitar reportes del inventario actual a la aplicacin, de los productos
registrados en el sistema de ventas.
6- El LogIn del sistema deber validar el ingreso a el sistema solicitando los datos id y contrasea.
7- El usuario client (cajeros) podr registrar las ventas realizadas por los clientes.
8- Las ventas registradas en la tabla de facturacin podrn ser editadas antes de ser registrada en el sistema,
mostrando en pantalla los productos registrados en una tabla independiente, para que pueda seleccionar los
productos que desea eliminar o agregar a la factura, una vez registrada la factura no podr modificar su
contenido.
9- El usuario client (cajero) podr consultar las ventas diarias en el sistema, pero esta consulta solo le mostrara
las ventas registradas en el da que solicite el reporte de ventas.
10- el sistema deber permitir que el usuario cambie su contrasea de ingreso, pero no su nombre de usuario,
en caso de tener que cambiar el usuario deber solicitarlo al administrador del sistema (DBA).
No funcional
1- El lenguaje de programacin debe ser asp.NET.
2- La aplicacin tendr dable interface, una para el Administrador (Usuario Admin) del sistema, y otra para
los cajeros (Usuario Client).
3- La interface grfica garantizara la fcil lectura y alta velocidad de procesamiento de datos.
4- El sistema deber implementar un sistema de LogIn, para permitir el ingreso a personas que posean la
informacin de ingreso al sistema.
5- El Hosting est basado en un motor de base de dato MySQL.
6- El sistema deber soportar multiusuarios, para el manejo de la aplicacin.
7- Los productos ingresados al sistema debern tener los siguientes datos:
a. Stock.
b. Nombre.
c. precio de proveedor.
d. precio de venta.
e. detalle del producto.
8- Los productos estarn identificados por un cdigo generado automticamente por el motor de la base de
datos.
9- Los reportes de ventas generados por la aplicacin debern mostrar los siguientes datos.
a. Productos vendidos.
b. Stock vendido por productos.
c. Precio de venta de cada producto.
d. Precio de Proveedor de cada producto.
e. Informacin de Total de ventas.
f. Informacin de ganancia de las ventas realizadas.
10- El diseo del Aplicativo web debe disearse usando como mnimo una arquitectura de Tres capas.
a. Capa de Presentacin.
b. Capa de Negocio.
c. Capa de Datos.
11- La gestin de la informacin para la toma de decisiones en el nivel central se realizar en lnea a travs de
Confidencial

Universidad Libre<, 2016

Page 4 of 7

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

un administrador de contenidos.
12- El id y contrasea que solicita el sistema de ingreso de la aplicacin, estar compuesto por la cedula del
usuario, y una contrasea definida por l.
13- El sistema deber mostrar una pantalla dos tablas una donde se realizaran los registros de las ventas de los
productos, para poder escoger los productos cliquendolos con el puntero del mouse, o escribiendo el
cdigo del producto en un recuadro de texto, y otra en donde se mostraran por categoras todos los
productos registrados en el sistema
14- El id y contrasea por defecto que tendr la aplicacin, sern:
a. ID:
administrados
b. CONTRASEA:
abc%1234
15- Los reportes del sistema se generaran en formato pdf, no modificables.

1. Introduccin.
1.1 Propsito.
Desarrollar una aplicacin web, que minimice en su mayor proporcin, la posibilidad de prdida de
informacin de las ventas realizadas por una empresa dedicada a la venta de productos.
1.2 Alcance
-

La aplicacin no garantizara ser escalable.

El sistema de LogIn ser el nico parmetro de seguridad utilizado en la aplicacin para validad
el ingreso al sistema.

El sistema solo ser compatible con sistema de bases de datos MySQL.

La aplicacin tendr dos interfaces, una para el administrador del sistema y otra para las cajas o
puntos de ventas (tipo cliente).

La aplicacin no permitir manejar varias contabilidades.

El sistema puede tener un numero n de cajeros, este nmero estar definidos por el
administrador del sistema, el cual se encargara de realizar el registro en la aplicacin de los
cajeros

La aplicacin solo generara los reportes en pdf.

Los lmites de almacenamiento estarn definidos por el motor de base de datos (MySQL v5,6).

La aplicacin solo podr ser implementada en supermercados, tiendas pequeas, tiendas de

ropa y calzado.

La aplicacin no garantiza compatibilidad con tabletas o celulares.

La aplicacin no manejara WebShop, solo ser para registro de ventas..

1.3 Definicin, Acrnimos, y abreviaciones.

DBA: Data Base Administator

WebShop: Tienda On-line
Interface: En informtica se utiliza para nombrar a la conexin fsica y funcional entre dos
sistemas o dispositivos de cualquier tipo dando una comunicacin entre distintos niveles
Pdf:: formato de documento porttil
ID: Identificador
Contrasea: palabra clave
Stock: Unidades disponibles de productos en un sistema de ventas
Usuario Admin: Administrador del sistema

Confidencial

Universidad Libre<, 2016

Page 5 of 7

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

Usuario Client: Cajeros, usuarios del sistema.

Sistema: cuyos componentes se relacionan con al menos algn otro componente.
Multiusuarios: todos los sistemas que cumplen simultneamente las necesidades de dos o ms usuarios.
LogIn: sistema de ingreso y validacin de credenciales de usuario nico.
1.4 Referencias

1. Auger, P. y Gallaugher, J.M. (1997). Factors affecting the adoption of an Internet2.

3.
4.

based sales presence for small business, The Information Society, Vol. 13 No. 1, pp.
55-74.
Avlonitis, G.J., Kouremenos, A. y Tzokas, N. (1994). Assessing the innovativeness of
organizations and its antecedents: Project Innovstrat, European Journal of Marketing,
Vol. 28 No. 11, pp. 5-2
Castells, M.; Vilaseca, J. (dirs.); Llads, J. (coord.); Ammetller, G.; Esteban, I.;
Fernndez, M.; Llads, J.; Rodrguez, I.; Torrent, J.; Vilaseca, J. (2007). Entorno
innovador, iniciativa emprendedora y desarrollo local. Barcelona: Octaedro.
Chaston, I. y Mangles, T. (2002). E-commerce in small UK manufacturing firms: a
pilot study on internal competencies, Journal of Marketing Management, Vol. 18 No.
3/4, pp. 341-360.
1.5 Visin de Conjunto
[This subsection describes what the rest of the Software Architecture Document contains and explains
how the Software Architecture Document is organized.]

2. Representacin Arquitectnica.
[This section describes what software architecture is for the current system, and how it is represented. Of
the Use-Case, Logical, Process, Deployment, and Implementation Views, it enumerates the views that are
necessary, and for each view, explains what types of model elements it contains.]

3. Objetivos Arquitectnicos y Coacciones

[This section describes the software requirements and objectives that have some significant impact on the
architecture; for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution,
and reuse. It also captures the special constraints that may apply: design and implementation strategy,
development tools, team structure, schedule, legacy code, and so on.]

4. Vista de Casos de Uso

[This section lists use cases or scenarios from the use-case model if they represent some significant, central
functionality of the final system, or if they have a large architectural coveragethey exercise many
architectural elements or if they stress or illustrate a specific, delicate point of the architecture.]

5. Vista Lgica.
[This section describes the architecturally significant parts of the design model, such as its decomposition
into subsystems and packages. And for each significant package, its decomposition into classes and class
utilities. You should introduce architecturally significant classes and describe their responsibilities, as well
as a few very important relationships, operations, and attributes.]
5.1 Vista de Conjunto.
[This subsection describes the overall decomposition of the design model in terms of its package hierarchy
and layers.]
5.2 Paquetes de Diseo Arquitectnicamente Significativos.
[For each significant package, include a subsection with its name, its brief description, and a diagram with
all significant classes and packages contained within the package.
Confidencial

Universidad Libre<, 2016

Page 6 of 7

SISTEMAS DE VENTAS MULTIUSUARIOS CON ALMACENAMIENTO DE

INFORMACIN EN LA NUBE.

Version:

Documento de Arquitectura de Software

Date: 02/FEB/02

<1.0>

For each significant class in the package, include its name, brief description, and, optionally, a description
of some of its major responsibilities, operations, and attributes.]
5.3 Relaciones de Casos de Uso.
[This section illustrates how the software actually works by giving a few selected use-case (or scenario)
realizations, and explains how the various design model elements contribute to their functionality.]

6. Vista de Procesos.
[This section describes the system's decomposition into lightweight processes (single threads of control)
and heavyweight processes (groupings of lightweight processes). Organize the section by groups of
processes that communicate or interact. Describe the main modes of communication between processes,
such as message passing, interrupts, and rendezvous.]

7. Vista de Despliegue.
[This section describes one or more physical network (hardware) configurations on which the software is
deployed and run. It is a view of the Deployment Model. At a minimum for each configuration it should
indicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus,
LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the
physical nodes.]

8. Vista de Implementacin.
[This section describes the overall structure of the implementation model, the decomposition of the
software into layers and subsystems in the implementation model, and any architecturally significant
components.]
8.1 Vista de Conjunto
[This subsection names and defines the various layers and their contents, the rules that govern the
inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the
relations between layers. ]
8.2 Capas
[For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer,
and a component diagram.]

9. Vista de datos(optional)
[A description of the persistent data storage perspective of the system. This section is optional if there is
little or no persistent data, or the translation between the Design Model and the Data Model is trivial.]

10. Tamao y rendimiento

[A description of the major dimensioning characteristics of the software that impact the architecture, as
well as the target performance constraints.]

11. Calidad
[A description of how the software architecture contributes to all capabilities (other than functionality) of
the system: extensibility, reliability, portability, and so on. If these characteristics have special significance,
such as safety, security or privacy implications, they must be clearly delineated.]

Confidencial

Universidad Libre<, 2016

Page 7 of 7