Instituto

Politécnico Nacional
Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y
Administrativas

Herramientas Automatizadas

Arquitectura proyecto ilustrativa

Elaborado por:

Arredondo Amaro Carlos Jair

Garcia Sánchez Johana Monserrat

Guerrero Hernández Angel

Malo Bautista Vanessa Anahi

Pineda González Esteban Antonio

Robles Garcia José Isaac

Soto Zores Oswaldo Martin

Fecha de entrega: 23 de Noviembre de 2020



Resumen

El presente documento contiene la especificaci´on de la arquitectura del proyecto. La

arquitectura corresponde al modelo de vistas 4+1, tomando en cuenta u´nicamente la
vista de procesos y la vista de escenarios. En la vista de escenarios se describe de
forma detallada el comportamiento de cada escenario planteado.




Índice general


1. Introduccion 1

1.1. Descripcióngeneral del proyecto .................................................1
1.2. Propósito del documento.................................................................2
1.3. Alcande del documento ....................................................................2
1.4. Contenido................................................................................................3

2. Arquitectura 4

2.1. Vista de procesos.............................................................................. 5
2.1.1. Visualizar productos..................................................................... 5
2.1.2. Registrar producto........................................................................ 6
2.2. Vista de escenarios.......................................................................... 7
2.2.1. CU1 Visualizar productos.......................................................... 8
2.2.2. CU1.1 Registrar producto..........................................................10
2.2.3 CU 1.2 Editar producto……………………………………………..15
2.2.4CU 1.3 Eliminar producto ………………………………………….21
2.2.5 Reglas de negocio...........................................................................23
2.2.6 Mensajes ............................................................................................24

Bibliografía 25

i





Indice de figuras

2.1. Modelo de arquitectura 4+1 de Kruchten……………………………………….4
2.2. Proceso para visualizar productos......................................................................5
2.3. Proceso para registrar producto......................................................................... 6
2.4. Vista de escenarios.....................................................................................................7
2.5. Visualizar productos: Sin registros………………………..……………………….8
2.6. Visualizar productos : Con registros ……………………………………………...9
2.7. Registrar prodcuto : Inicio ...................................................................................10
2.8. Registrar producto: Ingreso de información………………………………….11
2.9. Registrar producto : Registro exitoso……………………………………………11
2.10. Registrar producto: Campos obligatorios no ingresados……..............12
2.11. Registrar producto: Campos obligatorios no ingresados………………12
2.12.Registrar producto : Campo ingresado con un formato incorrecto…13
22. 2.13Registrar producto: Formato incorrecto………………………………….……13
2.14. Registrar producto: Código ingresado duplicado………………………...14
2222.15.Registrar producto: Código duplicado…………………………………………14










Ii














Capítulo 1 Introducción


En el presente capítulo se muestra una descripción general del proyecto, el
propósito y alcance del documento, así como una semblanza de los posteriores
capítulos.

1.1. Descripción general del proyecto

Actualmente una tienda departamental de productos de higiene personal y
limpieza, se encuentra registrando sus productos en hojas de cálculo. El
departamento encargado de realizar dicho registro, debe mantener actualiza-
da la información de cada producto que se ofrece en la tienda, y se enfrenta a la
siguiente problemática:

• Se producen errores en la información de productos previamente regis-
trados, debido a que el personal encargado del registro, al registrar un
nuevo producto, siempre corre el riesgo de modificar involuntariamente
la información de otro producto sin darse cuenta.

• Los errores en la información de registro de los productos se mantienen
hasta que el departamento de ventas identifica el problema.

• No existe una forma homologada para el registro de productos, debido a
que cada persona en el departamento encargado del registro cuenta en
este momento con un archivo de hoja de cálculo diferente para el
registro de productos a ofertarse en la tienda.

• Se dan casos en donde se realiza una sobre escritura de archivos de hoja
de c cálculo o la eliminación de algun archivo, de forma involuntaria.




1





CAPITULO 1. INTRODUCCION 2

Lo anterior deriva en las siguientes consecuencias:

• Los errores involuntarios provocan que las listas de productos tengan
que ser verificadas constantemente.

• Cuando el departamento de ventas detecta el problema, por lo regular
es porque ya se registró una venta y la imagen con loss clientes queda
afectada.

• Al no contar con una forma homologada de registro de información, no
se pueden tener reportes para toma de decisiones que sean confiables.

• La pérdida de archivos completos de información provoca que el
proceso de registro de productos completo deba ser ejecutado
nuevamente.

Para abordar todos los aspectos anteriores, se propone el desarrollo de un sistema de
administración de productos para la tienda, que aborde el registro de los mismos,
homologando la informaci ́on y permitiendo que el personal encargado del registro
tenga menos riesgo de errores.

1.2. Propósito del documento

El presente documento tiene como prop ́osito describir a detalle la ar- quitectura de la
soluci ́on a implementar, la cual esta definida a partir del modelo 4+1.

1.3. Alcande del documento

La arquitectura de la aplicación se describe tomando en cuenta el modelo de vistas 4
+1, tomando u ́nicamente para este caso las siguientes vistas:

• Vista de procesos. Diagramas de actividades y su descripción.

• Vista de escenarios. Diagramas de casos de uso y la descripción
detallada de cada escenario, incluyendo las reglas de negocio y
mensajes utilizados.

3







CAPITULO 1. INTRODUCCION 3


1.4. Contenido

A continuación se describe el contenido de los capítulos subsecuentes.

• Capítulo 2 Arquitectura. Contiene los diagramas asociados a la vista de
procesos y de escenarios, as ́ı como sus correspondientes descripciones.
































Capítulo 2 Arquitectura
La arquitectura basada en el modelo de vistas 4+1 fue desarrollada por Philippe Kruchten en
1995 y consta de 4 vistas principales: Vista de Procesos, Vista Lógica, Vista de Desarrollo y
Vista Física; más una vista que ocupa informaci ́on derivada de las demás vistas, denominada
como Vista de Escenarios. La figura 2.1 muestra la arquitectura basada en las vistas antes
mencionadas, su flujo de interacci ́on y la indicación de a qui ́en va dirigida cada vista.

Figura 2.1: Modelo de arquitectura 4+1 de Kruchten

A continuación se describen las vistas de procesos y de escenarios, que son las vistas que se
utilizan para modelar el presente proyecto.

́
CAPITULO 2. ARQUITECTURA 5
2.1. Vista de procesos
A continuación se muestran los diagramas de actividades correspondientes a las 4 acciones
que permite realizar la aplicación a desarrollar: Visualizar productos, Registrar producto,
Editar producto y Eliminar producto.

2.1.1. Visualizar productos

En la figura 2.2 se muestra el diagrama de actividades correspondiente a la visualizaci ́on de
productos, la cual consta de dos participantes: Encargado de registro y Sistema de
Administración de Productos. El objetivo es obtener la visualizaci ́on del listado de los
productos que se tienen registrados en la tienda departamental en el momento en que se
necesite. Se tienen dos casos posibles, el primero es cuando no se tienen productos
registrados y la única opción para el Encargado de registro es registrar productos; y el
segundo es cuando se tienen uno o más productos registrados, con la opción de registro de
productos, y para cada producto se puede actualizar su informaci ́on o eliminar un producto
en particular.

Figura 2.2: Proceso para visualizar productos

CAPITULO 2. ARQUITECTURA 6
2.1.2. Registrar producto
En la figura 2.3 se muestra el diagrama de actividades correspondiente al registro de
productos, el cual consta de dos participantes: Encargado de registro y Sistema de
Administración de Productos. El objetivo es poder registrar un producto en la aplicaci ́on, para
que se encuentre disponible en el catálogo de productos de la tienda. Se tienen dos casos
posibles, el primero es cuando el Encargado de registro ingresa la información de forma
correcta y el registro del producto se realiza de forma exitosa en la aplicación; y el segundo es
cuando el Encargado de registro ingresa información incorrecta y la aplicaci ́on le notifica del
error. En cualquier momento, el Encargado de registro puede decidir cancelar la actividad.

Figura 2.3: Proceso para registrar producto

CAPITULO 2. ARQUITECTURA 7
2.2. Vista de escenarios
A continuaci ́on se muestra en la figura 2.4 el diagrama de casos de uso que representa la vista
de escenarios, y que esta asociada a los requerimientos funcionales establecidos para la
aplicaci ́on a desarrollar.

Figura 2.4: Vista de escenarios

A continuación se describen de manera detallada cada uno de los esce- narios.

2.1.1. CU1 Visualizar productos

Actores: Encargado de registro

Reglas de negocio: No aplica

Mensajes: No aplica

El actor inicia la aplicación y puede darse una de dos opciones al

iniciar:

1. No se tienen productos registrados. Como se muestra en la pan-

talla mostrada en la figura 2.5, la única acción que se puede realizar es
registrar, a la cual se tiene acceso mediante el botón

Figura 2.5: Visualizar productos: Sin registros

 2. Se tienen productos registrados. Como se muestra en la panta-
lla mostrada en la figura 2.6, se puede registrar un nuevo producto
mediante el botón: , actualizar la información de un producto
previamente registrado mediante el icono: o eliminar un producto
existente mediante el icono:

Figura 2.6: Visualizar productos: Con registros


2.1.2 CU1.1 Registrar producto

Actores: Encargado de registro

Reglas de negocio: RN1 Campos obligatorios, RN2 Formato de da-

tos y RN3 Duplicidad de elemento

Mensajes: MSG1 Operación exitosa, MSG2 Campo obligatorio fal-

tante, MSG3 Formato de dato incorrecto y MSG4 Duplicidad de ele-
mento.

El actor puede registrar un producto, cuando dentro del caso de uso CU1
Visualizar productos (subsección 2.2.1) se presiona el botón de
la pantalla mostrada en la figura 2.5, correspondiente al caso en que no se
tienen productos registrados; o de la pantalla mostrada en la figura 2.6,
correspondiente al caso en que s´ıse tienen productos registrados. Una vez
que se presiona el botón , el sistema debe mostrar la pantalla indicada
en la figura 2.7.

Figura 2.7: Registrar producto: Inicio

El actor deberá ingresar toda la información de un producto a registrar, como lo mostrado
en la pantalla indicada en la figura 2.8.

Figura 2.8: Registrar producto: Ingreso de información

Para realizar el registro del nuevo producto, el actor deberá presionar el

botón y el sistema mostrará la pantalla indicada en la figura 2.9, bajo
el contexto del caso de uso CU1 Visualizar productos (subsección 2.2.1), in-
dicando que el registró se ha realizado exitósamente y con el nuevo prodcuto
mostrado en la tabla correspondiente.

Figura 2.9: Registrar producto: Registro exitoso


Si el actor desea cancelar el registro del producto, en cualquier momento
podrá presionar el botón , y el sistema regresará a la pantalla co-
rrespondiente de acuerdo al CU1 Visualizar productos (subsección 2.2.1)
dependiendo de la pantalla de donde venga, ya sea de la pantalla mostrada
en la figura 2.5, correspondiente al caso en que no se tienen productos re-
gistrados; o de la pantalla mostrada en la figura 2.6, correspondiente al caso
en que s´ıse tienen productos registrados.

El sistema mostrará mensajes de error, para los siguientes casos:

Campos obligatorios faltantes: Cuando uno o más campos mar-

cados como obligatorios son omitidos, como en la pantalla mostrada
en la figura 2.10, y una vez que el actor presiona el botón , el
sistema deberá indicar los campos que han sido omitidos como en la
pantalla mostrada en la figura 2.11.

Figura 2.10: Registrar producto: Campos obligatorios no ingresados

Figura 2.11: Registrar producto: Campos obligatorios no ingresados


Formato incorrecto. Cuando uno o más campos son ingresados con
un formato incorrecto, como en la pantalla mostrada en la figura 2.12,
y una vez que el actor presiona el botón , el sistema deberá indicar
los campos que han sido ingresados de manera incorrecta como en la
pantalla mostrada en la figura 2.13

Figura 2.12: Registrar producto: Campo ingresado con un formato incorrecto

Figura 2.13: Registrar producto: Formato incorrecto


Duplicidad de elemento. Cuando se ingresa un código de produc- to
que ya se encuantra previemente registrado, como en la pantalla
mostrada en la figura 2.14 (Suponga que el código ya esta registrado
previamente), y una vez que el actor presiona el botón , el sis-
tema deberá indicar que el código de producto ya esta previamente
registrado como en la pantalla mostrada en la figura 2.15

Figura 2.14: Registrar producto: Código ingresado duplicado

Figura 2.15: Registrar producto: Código duplicado


2.2.3 CU 1.2 Editar producto

Actores: Encargado de registro

Reglas de negocio: RN1 Campos obligatorios, RN2 Formato de da-

tos y RN3 Duplicidad de elemento

Mensajes: MSG1 Operación exitosa, MSG2 Campo obligatorio fal-

tante, MSG3 Formato de dato incorrecto y MSG4 Duplicidad de ele-
mento.

El actor puede editar el precio de un producto cuando dentro del caso de uso CU 1.1
registrar producto (subseccion 2.2.2) se presione el boton de la pantalla mostrada
en la figura 2.9, correspondiente al caso registrar producto. una vez presionadoel boton ,
el sistema debe mostrar la pantalla indicada en la figura 2.16.

Figura 2.16 Editar Precio Inicio

El actor deberá ingresar el nuevo precio.



Para realizar el cambio en el precio del producto, el actor debera presionar el botón
y el sistema mostrara la pantalla indicada en la figura 2.17, bajo el contexto de
CU1.2 Editar producto subseccion 2.2.3 indicando que el registro se ha modificado
exitosamente.

Figura 2.17:Editar producto: Registro se ha modificado exitosamente


Campos obligatorios faltantes

Cuando uno o mas campos marcados como obligatorios son omitidos, como en la
pantalla mostrada en la figura 2.18 y una vez que el actor presiona el boton,
el sistema debera indicar los campos que han sido omitidos como en la pantalla
mostrada en la figura 2.19.

Figura 2.18 Editar producto: Campos obligatorios no ingresados

Figura 2.19 Editar producto: Campos obligatorios no ingresados


Formato incorrecto

Cuando uno o mas campos son ingresados con un formato incorrecto, como en la pantaa
mostrada en la figura 2.20 y una vez que el actor presiona el boton. , el sistema debera
inidicar los campos que han sido ingresados de manera incorrecta como en la pantalla
mostrada en la figura 2.21.

Figura 2.20 Editar producto. Campo ingresado en formato incorrecto

Figura 2.21 Editar producto: Formato incorrecto




Duplicidad de elemento.

Cuando se ingresa un codigo de producto que ya se encuentra previamente registrado, como
en la pantalla mostrada en la figura 2.22 (suponga que el codigo ya esta registrado
previamente), y una vez que el actor presiona el boton. , el sistema debera inidicar que
el codigo de producto,
















Figura 2.22 Editar producto: Codigo ingresado duplicado

Figura 2.23 Editar producto: Codigo duplicado


NUMERO DE CÓDIGO

Cuando se ingresa un codigo de producto que no cumple con los dígitos necesarios, como en la
pantalla mostrada en la figura 2.24, y una vez que el actor presiona el botón el sistema
debera indicar que el código de producto debe ser de tres digitos, como en la pantalla
mostrada en la figura 2.25.

Figura 2.24 Editar producto: Codigo ingresado erroneo

Figura 2.25 Editar producto: El codigo debe ser de tres digitos


2.2.4CU 1.3 Eliminar producto

Actores: Encargado de registro

Reglas de negocio: No aplica

Mensajes: MSG1 Operación exitosa.

El actor puede eliminar un producto cuando dentro del caso de uso CU1.1 registrar producto
(subseccion 2.2.2) presione el boton de de la pantalla mostrada en la figura 2.9,
correspondiente al caso de registrar producto. Una vez presionado el boton el sistema debe
mostrar la pantalla indicada en la figura 2.26.












Figura 2.26 Eliminar producto: Confirmación para eliminar producto

Para realizar la eliminación el actor deberá presiona el botón y el sistema mostrara
la pantalla indicada en la figura 2.27 eliminando el producto mostrando el mensaje de el
registro se ha eliminado exitosamente












Figura 2.7 Eliminar producto. El registro se ha eliminado exitosamente


2.1.2. Reglas de negocio
A continuación se muestra la especificación de cada una de las reglas de
negocio utilizadas en el sistema, ası́ como la identificación de los casos de
uso en donde se ocupa cada regla.

RN1 Campos obligatorios.

• Especificación: Los campos obligatorios a ingresar en el sistema

se indican en pantalla mediante un * al inicio del nombre de cada
campo, además de estar especificados en el diccionario de datos.
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto

RN2 Formato de datos.

• Especificación: Cada uno de los campos a ingresar en el sistema

deberán cumplir con el formato y tipo de dato especificado en el
diccionario de datos para tomarse como correctos por el sistema.
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto

RN3 Duplicidad de elementos.

• Especificación: La duplicidad de elementos será definida como

sigue:
◦ Producto. El campo Código es el que determina la duplici-
dad, tal como se indica también en el dicionario de datos.
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto.
 2.1.5 Mensajes
A continuación se muestra la especificación de cada uno de los mensajes
utilizados en el sistema, ası́ como la identificación de los casos de uso en
donde se ocupa cada mensaje.

MSG1 Operación exitosa

• Especificación: El/La ACCIÓN se ha realizado exitósamente

◦ ACCIÓN: Nombre de la operación realizada
• Ejemplo: El registro se ha realizado exitósamente
• Salida: Pantalla
• Ubicación: Debajo del tı́tulo de la pantalla, de manera centrada
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto

MSG2 Campo obligatorio faltante

• Especificación: Campo obligatorio

• Ejemplo: Campo obligatorio
• Salida: Pantalla
• Ubicación: Debajo del campo obligatorio que ha sido omitido
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto

MSG3 Formato de dato incorrecto

• Especificación: Formato incorrecto

• Ejemplo: Formato incorrecto
• Salida: Pantalla
• Ubicación: Debajo del campo ingresado con formato incorrecto
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto
 MSG4 Duplicidad de elemento

• Especificación: Ya se cuenta con un/una NOMBRE ENTIDAD

registrado/registrada con el/la mismo/misma DUPLICIDAD ENTIDAD
◦ NOMBRE ENTIDAD: Nombre de la entidad sobre la que se
esta trabajando
◦ DUPLICIDAD ENTIDAD: Nombre del atributo de la enti-
dad sobre la que se esta trabajando, el cual determina la
duplicidad de la misma
• Ejemplo: Ya se cuenta con un Producto registrado con el mismo
Código
• Salida: Pantalla
• Ubicación: Debajo del tı́tulo de la pantalla, de manera centrada
• Casos de uso donde se ocupa: CU1.1 Registrar producto y CU1.2
Editar producto.


Bibliografía

[1] Artíıculo de Arquitrectura 4 +1

[2] UML OMG

[3] Documento de requerimientos

13