RESEB

Sistema de facturación
Documentación de arquitectura de software

UNIVERSIDAD DE COSTA RICA

IF 6100 – Análisis y Diseño de Sistemas

Integrantes

García Borge José Adrián B83155

Medina Gómez Rebecca B84752

Meléndez Contreras Ana B74642

Viales Pizarro Kryssia B88452

RESEB
 Historial de revisión
Fecha Versión Descripción Autor
< dd/mmm/yy> < x.x> < detalles> < nombre>
 Tabla de contenido

Introducción 4
Propósito 4
Alcance 4
Definiciones, acrónimos y abreviaturas 4
Referencias 5
Referencias 5
Visión general 5
Representación arquitectónica 5
Metas y limitaciones arquitectónicas 5
Vista de caso de uso 6
Vista logica 9
Descripción general 9
Paquetes de diseño arquitectónicamente significativos 9
Realizaciones de casos de uso 9
Vista del proceso 9
Vista del despliegue 10

Vista de implementación 10
Descripción general 10
Vista de datos 10
Tamaño y rendimiento 10
Calidad 10
1. Introducción

Este documento presenta de manera general y especifica la documentación de un sistema de

información referente a la empresa de facturación electrónica RESEB cuyas siglas significan

sistema de facturación electrónica, eficiente, seguro y confiable, como parte de la

documentación se extenderá sobre las especificaciones del software, del hardware y las

interfaces de usuario.

1.1 Propósito

En este documento se ofrece un panorama arquitectónico completo del sistema, su propósito

principal es facilitarle al usuario la comprensión sobre las capacidades que tiene el sistema ya

sean en funcionalidad, plan de contingencia e integridad. También facilitará considerablemente

a los desarrolladores del software la codificación de este a futuros desarrolladores y para que

puedan hacer la implementación de mejoras del software.

1.2 Alcance

Este documento se aplica a

1.3 Definiciones, acrónimos y abreviaturas

RESEB: Sistema de facturación electrónica, eficiente, seguro y confiable.

 Login: inicio de sesión en el que el usuario debe ingresar su nombre y contraseña para

acceder y disfrutar de las funcionalidades del sistema.

Interfaz: Pantalla utilizada como medio para la interacción entre el sistema y el usuario.

1.4 Referencias

NA

1.5 Visión general

RESEB ofrece sistemas de facturación adecuados para las empresas que requiera la emisión de

comprobantes electrónicos por compras con el fin de facilitar el proceso de compra y venta.

Nuestro sistema de facturación cuenta con una accesible y amigable interfaz con el cliente.

Vista de Casos de Uso: describe la lista los casos de uso o escenarios del modelo de casos de

uso que representen funcionalidades centrales del sistema.

Vista Lógica: describe las partes arquitectónicamente indicadoras del modelo de diseño, como

la descomposición en capas, subsistemas o paquetes.

Vista de Despliegue: describe uno o más escenarios de distribución física del sistema y la

comunicación entre los diferentes nodos que los componen.

Vista de Implementación: describe la estructura general del Modelo de Implementación y el

mapeo de los subsistemas, paquetes y clases de la Vista Lógica a subsistemas y componentes

de implementación.

Vista de Datos: describe los elementos principales del Modelo de Datos, dando una vista
 general del modelo en términos de tablas, vistas, índices, etc.

[This subsection describes what the rest of the Software Architecture Document
contains and explains how the Software Architecture Document is organized.]
2. Representación arquitectónica

Resumen de involucrados

Rol Categoría Actividades y

Nombre Profesional Responsabilidades Información de Contacto

José Adrián Administrador de Estudiante Responsable de los

García Borge la BD, Analista y aspectos de la BD, aporte garciarubiojose79@gmail.com
Programador a la creación de casos de
uso, convertir a código el
trabajo de diseño
Diseñadora y Estudiante Creación de las interfaces
Rebeca Medina Documentadora de usuario, aporte a la Rebemedi99@gmail.com
Gómez documentación.
Analista y Estudiante Documentación y análisis
Ana Meléndez Documentadora funcional del AnitaMelendez92@gmail.com
Contreras sistema
Analista, Estudiante Resolver los problemas
Krissia Viales Administrador de que se presenten, análisis kryssiavp@gmail.com
Pizarro Proyectos y funcional del sistema,
Programadora convertir a código el
trabajo de diseño
 Requerimientos funcionales

Código Requerimiento Prioridad del

Actor requisito
RF-01 Sistema despliega ventana de inicio para que los Alta / Esencial
usuarios ingresen sus datos para el proceso de Administrador
registro.
RF-02 El sistema permite al usuario tener un control de Alta / Esencial
los productos en stock Administrador

RF-03 El sistema debe permitir al usuario generar el Alta / Esencial

boleto de factura por cada venta realizada Administrador

RF-04 El sistema debe permitir al usuario visualizar Alta / Esencial

todas las facturas generadas Administrador

RF-05 Todos los usuarios deberán hacer el “login” e Alta / Esencial

ingresar un correo y contraseña válidos en el Encargado de factura
sistema para poder entrar a éste.
RF-06 El usuario puede agregar, modificar y eliminar un Alta / Esencial
producto en lista de productos. Encargado de factura

RF-07 El cliente procede a comprar un producto. Alta / Esencial

Cliente

Diagrama de contexto
3. Metas y limitaciones arquitectónicas

Plataforma de software de base

Cliente

Sistema Operativo Multiplataforma

Browser Internet Explorer, Chrome, Microsoft edge

Tecnologías utilizadas HTML5

CSS
JS
Bootstrap

Lenguajes utilizados JavaScript

Herramientas de desarrollo

Servidor de aplicación

Sistema Operativo Multiplataforma

 Application Server IIS Express

Lenguajes utilizados C#

Framework utilizados ASP.NET Core

Servidor de base de datos

Sistema Operativo Multiplataforma

Base de datos SQL Server 2019

[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 caso de uso

Introduccion

En este apartado se describe la lista los casos de uso o escenarios del modelo de casos de uso
que representen funcionalidades centrales del sistema.

Diagrama de casos de uso

Descripción de casos de uso

Mantener datos de usuarios

Nombre Mantener datos de usuarios

Actor Administrador

Precondición El usuario ha sido admitido en el sistema con el rol de Administrador.

Postcondición Se ha registrado en el sistema el mantenimiento de los datos de usuarios,

 más específicamente se ha añadido un nuevo usuario o se ha modificado,
eliminado un usuario existente.

Flujo Básico - 1. El caso de uso comienza cuando el Administrador “Registra un

Registrar usuario”
2. El sistema muestra formulario vacío para llenar los datos del nuevo
usuario
3. El Administrador ingresa los datos que se solicitan del usuario.
4. El Administrador indica “Guardar”.
5. El sistema valida los datos
6. El sistema registra el nuevo usuario

Flujo Básico - 1. El caso de uso comienza cuando el Administrador selecciona

Modificar “Editar” en uno de los usuarios.
2. El sistema muestra formulario con los datos del usuario
3. El Administrador modifica los datos que desea
4. El Administrador indica “guardar”.
5. El sistema valida datos
6. El sistema registra el cambio en el usuario

Flujo Básico - 1. El caso de uso comienza cuando el Administrador selecciona

Eliminar “eliminar” en uno de los usuarios
2. El sistema solicita confirmación
3. El Administrador confirma la eliminación
4. El sistema registra la eliminación

Flujos alternativos 1. En el paso 5 de Registrar o paso 5 de Modificar, si el sistema

encuentra algún error en algún dato, muestra mensaje de error y
vuelve a solicitar los datos
2. En el paso 6 de Eliminar, si el Administrador no confirma, el
sistema regresa al formulario del usuario sin eliminarlo.

Gestionar Inventario

Nombre Gestionar Inventario

Actor Administrador
Precondición El usuario ha sido admitido en el sistema con el rol de Administrador.

Postcondición Se ha registrado en el sistema el mantenimiento de los datos del producto,

más específicamente se ha añadido un nuevo usuario o se ha modificado,
eliminado un usuario existente.

Flujo Básico - 1. El caso de uso comienza cuando el Administrador “Registra un

Registrar producto”
2. El sistema muestra formulario vacío para llenar los datos del nuevo
producto
3. El Administrador ingresa los datos que se solicitan del producto.
4. El Administrador indica “Guardar”.
5. El sistema valida los datos.
6. El sistema registra el nuevo producto.

Flujo Básico - 1. El caso de uso comienza cuando el Administrador selecciona

Modificar “Editar” en uno de los productos.
2. El sistema muestra formulario con los datos del producto.
3. El Administrador modifica los datos que desea
4. El Administrador indica “guardar”.
5. El sistema valida datos
6. El sistema registra el cambio en el producto.

Flujo Básico - 1. El caso de uso comienza cuando el Administrador selecciona

Eliminar “eliminar” en uno de los productos.
2. El sistema solicita confirmación
3. El Administrador confirma la eliminación
4. El sistema registra la eliminación

Flujos alternativos 1. En el paso 5 de Registrar o paso 5 de Modificar, si el sistema

encuentra algún error en algún dato, muestra mensaje de error y
vuelve a solicitar los datos
2. En el paso 6 de Eliminar, si el Administrador no confirma, el
sistema regresa al formulario del producto sin eliminarlo.

Creación de Factura
Nombre Creación de Factura

Actor Administrador o Encargado de factura

Precondición El usuario ha sido admitido en el sistema con el rol de Administrador o

Encargado de factura

Postcondición Se crea una factura.

Flujo Básico 1.

Flujos alternativos

Emitir reporte

Nombre Emitir reporte

Actor Administrador

Precondición El usuario ha sido admitido en el sistema con el rol de Administrador.

Postcondición

Flujo Básico

Flujos alternativos

Ingreso al sistema

Nombre Ingreso al sistema

Actor Encargado de factura

Precondición El usuario ha sido admitido en el sistema con el rol de Encargado de

factura

Postcondición

Flujo Básico

Flujos alternativos
 Mantener datos de producto

Nombre Mantener datos de producto.

Actor Encargado de factura

Precondición El usuario ha sido admitido en el sistema con el rol de encargado de

factura.

Postcondición Se ha agregado en el sistema la lista de productos, es decir se ha añadido

un nuevo producto o se ha modificado, eliminado uno existente.

Flujo Básico - 1. El caso de uso comienza cuando el encargado de factura “Agrega

Agregar un producto a la lista”
2. Se muestra la lista de productos.
3. El encargado de factura ingresa el producto a la lista
4. El encargado de factura indica “Guardar”.
5. Se agrega el nuevo producto a la lista.

Flujo Básico - 1. El caso de uso comienza cuando el encargado de factura selecciona

Modificar “Editar” en uno de los productos.
2. Se muestra la lista de productos.
3. El encargado de factura modifica los productos que desee.
4. El encargado de factura indica “guardar”.
5. Se registra el cambio en la lista de productos.

Flujo Básico - 1. El caso de uso comienza cuando el encargado de factura selecciona

Eliminar “eliminar” en uno de los productos de la lista.
2. Se solicita confirmación.
3. El encargado de factura confirma la eliminación.
4. Se registra la eliminación.

Flujos alternativos 1. En el paso 5 de Agregar o paso 5 de Modificar, si el sistema

encuentra algún error en algún dato, muestra mensaje de error y
vuelve a solicitar los datos
2. En el paso 3 de Eliminar, si el encargado de factura no confirma, el
sistema regresa al la lista con el producto sin eliminarlo.
 Comprar producto

Nombre Comprar producto

Actor Cliente

Precondición El usuario ha sido admitido en el sistema con el rol de cliente.

Postcondición El usuario ha realizado la compra de productos.

Flujo Básico 1. El caso comienza cuando el cliente selecciona la lista de productos.

2.

Flujos alternativos

Diagramas de clases
Diagramas de secuencias

Mantener datos de usuarios

 Gestionar Inventario

Creación de Factura

Emitir reporte

Ingreso al sistema

Mantener datos de producto.

5. Vista logica
[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 Descripción general
[This subsection describes the overall decomposition of the design model in terms of its
package hierarchy and layers.]
5.2 Paquetes de diseño arquitectónicamente 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.
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 Realizaciones 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 del proceso
[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 del 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 implementacion
[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 Descripción general
[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
[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. Tamaño 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 impl ications,
they must be clearly delineated.]