Producción Chifles Final

MODELADOS DE DATOS
GESTIÓN DE PRODUCCIÓN DE PRODUCTOS AGROINDUSTRIALES DASOL
INTEGRANTES
Martínez Balladares Mirella Elena
Urbina Avendaño Francisco Dampier
Ruiz Carrión Antonella
Morales García Aldair
Ruesta Sánchez Fabricio
Universidad Nacional de Piura
Facultad de Ingeniería Industrial
Escuela Profesional de Ingeniería Informática
Ing. Héctor Fiestas Bancayán Mgr
06 de agosto 2019
Contenido
I. Introducción.....................................................................................................................4
II. Objetivos......................................................................................................................5
III. Marco teórico...............................................................................................................6
3.1. Referencia de la Organización.................................................................................6
3.1.1. Giro del negocio de la empresa.........................................................................6
3.1.2. Misión y Visión de la empresa..........................................................................6
3.1.3. Estudio de Sistemas..........................................................................................6
3.1.4. El subsistema a estudiar....................................................................................9
3.1.5. Procesos de negocio en el que participa el Subsistema Operaciones.............10
3.2. Diagrama de Actividades.......................................................................................10
3.2.1. Especificaciones del Diagrama de actividades...............................................10
3.2.2. Diagrama de actividades del proceso actual...................................................11
3.2.3. Deficiencias del D.A. del proceso actual........................................................13
3.2.4. Diagrama de actividades del proceso mejorado..............................................16
3.3. Modelos de Caso de Uso según su nivel de organización......................................17
3.3.1. Nivel Operativo...............................................................................................17
3.3.2. Nivel Táctico...................................................................................................34
3.3.3. Nivel Estratégico.............................................................................................38
3.4. Diagrama de clases según su nivel de organización...............................................40

2
3.4.1. Especificaciones del diagrama de clases.........................................................40
3.4.2. Identificación de sustantivos...........................................................................45
3.4.3. Diagrama de clases del nivel operacional.......................................................46
3.4.4. Diagrama de clases del nivel táctico...............................................................48
3.4.5. Diagrama de clases del nivel estratégico........................................................49
3.5. Diagrama de entidad-relación según su nivel de organización..............................50
3.5.1. Especificaciones del Diagrama de entidad-relación.......................................50
3.5.2. Diagrama de entidad-relación del nivel Operacional......................................61
3.5.3. Diagrama de entidad-relación del nivel Táctico.............................................62
3.5.4. Diagrama de entidad-relación del nivel Estratégico.......................................63
IV. Conclusiones..............................................................................................................64
V. Bibliografía................................................................................................................65
3
I. Introducción
En el desarrollo del presente trabajo, se analizará el desarrollo de un sistema a través del
análisis de modelado de datos para la empresa Agroindustrias Dasol EIRL, empresa
dedicada a la fabricación, comercialización y exportación de productos agroindustriales;
elaborado con el fin de la implementación de un software informático que automatice
ciertos procedimientos con los datos propios de la empresa que se llevan a cabo ,
enfocándonos en el nivel operativo, realizando los diagramas y descripciones de los casos
de usos de los diferentes actores de la empresa, el nivel estratégico, realizando los
diagramas de casos de uso de los actores gerenciales que toman decisiones y por último el
nivel táctico, que se presenta los actores que toman decisiones a corto plazo de la empresa.
El enfoque del presente desarrollo de software es conocer, analizar y diseñar un sistema
didáctico en el cual los usuarios tengan acceso a la completa información que les compete,
automatizando el flujo de datos, además de facilitar el procesado y trámite de
documentación.
4
II. Objetivos
Objetivo General.
 Desarrollar un sistema para la “Gestión de producción de productos
agroindustriales DASOL” a través del modelado de datos.
Objetivo Específico.
 Estudiar la razón de ser del subsistema con el que se trabajará, “El subsistema
de producción”, lo cual se detallará a través de un diagrama de actividades de la
empresa (uno actual y otro mejorado)
 Proporcionar una visión abstracta de los datos implementando el modelo de
casos de uso, que incluye el diagrama de casos de uso por actor y una interfaz
gráfica de usuario.
 Elaborar un diagrama de clases para comprender y analizar la multiplicidad
existente entre instancias de diferentes clases.
 Elaborar el diagrama entidad relación para la conexión de datos con la base de
datos del sistema, esto realizado para cada nivel de usuario (Operativo, Táctico
y Estratégico).
5
III. Marco teórico
III.1. Referencia de la Organización
Empresa objeto de estudio: “AGROINDUSTRIAS DASOL E.I.R.L”.
III.1.1. Giro del negocio de la empresa
Agroindustrias Dasol EIRL es una empresa dedicada a la fabricación, comercialización y
exportación de productos agroindustriales, productos como: Chifles (Como producto
insignia), algarrobina, miel de abeja, natilla, toffee de sabores, cocadas, chumbeque,
alfajores, suplemento vitamínico, dulces, etcétera.
III.1.2. Misión y Visión de la empresa
 Misión:
Contribuir a que nuestros más tradicionales dulces se mantengan vigentes en el tiempo,
logrando satisfacer así a todos los clientes de cada ciudad en la que estamos presentes a
través de nuestras tiendas Delicias Peruanas.
 Visión:
Llegar a cada hogar del mundo con los más ricos y tradicionales dulces peruanos.
III.1.3. Estudio de Sistemas
 Asistencia independiente:
 Sistemas e Informática:
- Incrementar la capacidad tecnológica de la empresa.
- Promocionar control total a Gerencia general.
- Automatizar procesos de producción y comercialización.
6
- Asistencia al personal.
- Mantenimiento del software.
 Subsistemas:
A. Subsistema de Gerencia
 Gerencia General:
- Planificar, organizar, dirigir, controlar el trabajo de la empresa.
- Proponer metas a los subsistemas, y de manera mensual les
solicita resultados.
- Sancionar, elegir al personal (junto a las subgerencias), aprobar
presupuestos y requerimientos.
- Representar a la empresa en actividades financieras,
comerciales, y legales.
 Gerencia de Operaciones:
- Tener a cargo y controlar a los subsistemas: Almacén, Logística
y Mantenimiento, y Producción.
 Gerencia de Comercialización:
- Tener a cargo y controlar a los subsistemas: Marketing, Ventas
de Pts. Propios y Venta de Campo.
B. Subsistema Almacén:
 Conservar en buen estado los productos.
 Verificar la cantidad de productos ingresados y entregados.
 Contabilizar los insumos productivos y los resultados de producción.
 Distribuir a las tiendas a través de los sistemas de ventas.
7
C. Logística y Mantenimiento:
 Realizar el inventario en el periodo de un mes.
 Costos de producción
 Gestión del Mantenimiento de maquinarias, vehículos, y otros que
se utilicen para la producción o venta.
 Brindar capacitación al personal en el uso del sistema de ventas.
 Supervisiones a las plantas productivas para verificar que los
insumos se utilicen de manera óptima y completa.
 Supervisiones a tiendas para verificar el flujo y rotación de los
productos, además de revisar que siempre tengan stock de los
mismos. (Y en caso haya desabastecimiento, identificar el problema
y solucionarlo)
D. Subsistema de Producción:
 Transforma materia prima e insumos.
 Uso de la tecnología en el proceso productivo.
 Lleva a cabo el proceso de Frituras.
 Etiquetado, envasado y sellado de las frituras.
 Despacho de Productos finales a los distintos puntos de venta.
 Realizar control de calidad de los productos elaborados.
E. Subsistema de Marketing:
 Promoción y marketing de los productos.
8
 Búsqueda y selección de canales de producción (nuevos clientes o
mercados).
 Realizar propagandas, catálogos y anuncios de los productos
comercializados.
 Controlar, monitorear y dirigir el fanpage de la empresa.
F. Subsistema de Ventas de productos propios:
 Venta de productos de nivel regional y nacional.
 Garantizar a los clientes una buena experiencia en su compra.
 Implementar, capacitar y optimizar la fuerza comercial (ventas).
 Manejo del volumen de venta.
 Manejo del tipo de pago.
G. Subsistema de Contabilidad:
 Cuadrar ingresos y egresos en el libro contable.
 Llevar un registro de compras y ventas (Libro diario).
 Declarar a tiempo los tributos de la empresa.
 Presentar balance de ganancias y pérdidas cuando sea requerido.
 Tener conocimiento de los estados bancarios de la empresa.
 Elaborar documentación contable y información financiera para la
adquisición de créditos en entidades financieras.
III.1.4. El subsistema a estudiar
El subsistema a estudiar será el Subsistema de Producción.
9
III.1.5. Procesos de negocio en el que participa el Subsistema Operaciones
- Producción de producto que pasa por un proceso de fritura (Chifles de
plátano y camote).
- Producción de carne seca.
- Producción de dulces (Información confidencial).
III.2. Diagrama de Actividades
III.2.1. Especificaciones del Diagrama de actividades
El Diagrama de Actividad es un diagrama de flujo del proceso multipropósito que se usa
para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar
para modelar un Caso de Uso, o una clase, o un método complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los
diagramas de actividad pueden mostrar procesado paralelo. Un proceso paralelo es aquel
que se realiza al mismo tiempo que otro, siendo ejecutados ambos de modo simultáneo.
[ CITATION Dav \l 10250 ]
 Beneficios de los diagramas de actividades
Los diagramas de actividades presentan una serie de beneficios para los usuarios. Considera
crear un diagrama de actividades para:
 Demostrar la lógica de un algoritmo.
 Describir los pasos realizados en un caso de uso UML.
10
 Ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y el sistema.
 Simplificar y mejorar cualquier proceso clarificando casos de uso complicados.
 Modelar elementos de arquitectura de software, tales como método, función y
operación.
 Componentes básicos de un diagrama de actividades
Antes de empezar a crear un diagrama de actividades, debes comprender primero su
composición. Algunos de los componentes más comunes de un diagrama de actividades
incluyen:
 Acción: Un paso en la actividad en el que los usuarios o el software realizan una
tarea dada.
 Nodo de decisión: Una rama condicional en el flujo que se representa con un
diamante. Incluye una sola entrada y dos o más salidas.
 Flujos de control: Otro nombre para los conectores que muestran el flujo entre
pasos en el diagrama.
 Nodo inicial: Simboliza el inicio de la actividad. El nodo inicial se representa con
un círculo negro.
 Nodo terminal: Representa el paso final en la actividad. El nodo terminal se
representa por medio de un círculo negro de contorno blanco. [ CITATION luc19 \l
10250 ]
III.2.2. Diagrama de actividades del proceso actual
11
12
13
III.2.3. Deficiencias del D.A. del proceso actual
Actividad Implementación de Uso

TICs
Ordenar inicio del Sistema que sea El sistema proporcionará al usuario (Gerente de
proceso de manejado por el Producción) en una lista desplegable el producto
producción. Gerente de al cual dará la orden de comenzar con el proceso
Producción, productivo, además de permitir ingresar la
mediante una cantidad de producción.
PANTALLA. Una vez grabada la orden, el sistema enviará
automáticamente un correo al Jefe de turno para
que ejecute su trabajo.
Solicitar Sistema que sea El sistema proporcionará al usuario (jefe de
requerimiento de manejado por el jefe producción de turno) una lista de insumos usados
insumos productivos. de producción de en el proceso ya determinado (Cada uno
turno, mediante una identificado con un CÓDIGO) además podrá
PANTALLA. ingresar la cantidad por cada insumo, para luego
grabar y enviar el listado de insumos necesitados a
Almacén.
Enviar insumos Sistema que sea El sistema permitirá enviar una relación de los
productivos. manejado por el jefe insumos productivos solicitados a los operarios,
de Almacén, con la cantidad de cada uno de ellos.
mediante una
PANTALLA.
Verificar cantidad Sistema que sea El sistema registrará la cantidad de insumos
solicitada. manejado por los recibidos. Si la cantidad de insumos solicitada es
operarios de turno, igual a la cantidad de insumos recibidos, si es así
mediante una enviará Al Jefe de Almacén una constancia de
PANTALLA. haber RECIBIDO los insumos, caso contrario
enviará un documento describiendo que y cuantos
insumos no han sido enviados.
Operaciones del Sistema que sea El sistema proporcionará a los usuarios (operarios
proceso productivo manejado por los de turno) una relación que incluya cada una de las
(descascar, cortar, operarios de turno, operaciones mencionadas, en las cuales registrarán
freír y empaquetar). mediante una la hora de inicio y la hora en la que se finalizó
PANTALLA. cada operación.
Reportar cantidad de Sistema que sea El sistema proporcionará a los usuarios (operarios
productos obtenidos. manejado por los de turno) la posibilidad de ingresar la cantidad de
operarios de turno, productos obtenidos y el tipo de estos. Para luego
mediante una enviar informe por correo electrónico al Jefe de
PANTALLA. producción de turno.
Informar a gerencia. Sistema que sea El sistema enviará informe al Gerente de
manejado por el jefe Producción acerca de la cantidad y estado de los
de producción de productos obtenidos en el día.
turno, mediante una
PANTALLA.
14
Comprar stock con Sistema que sea El sistema registrará el stock de los productos
documentación. manejado por el presentes en planta y los comparará con los datos
Gerente de de los informes, en el caso que falten o sobren,
producción, registrará a los Operarios de turno para hacerles el
mediante una descuento respectivo.
PANTALLA.
15
III.2.4. Diagrama de actividades del proceso mejorado
16
III.3. Modelos de Caso de Uso según su nivel de organización
III.3.1. Nivel Operativo
III.3.1.1. Especificaciones del modelo de casos de uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del
usuario. Es una herramienta valiosa dado que es una técnica de aciertos y errores para
obtener los requerimientos del sistema, justamente desde el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema usando actores y casos
de uso. Los casos de uso son servicios o funciones provistas por el sistema para sus
usuarios.
Un caso de uso representa una unidad funcional coherente de un sistema, subsistema o
clase. En un caso de uso uno o más actores interaccionan con el sistema que realiza algunas
acciones.[ CITATION Kar17 \l 10250 ]
Elementos
 Sistema: El rectángulo representa los límites del sistema que contiene los casos de
uso. Los actores se ubican fuera de los límites del Sistema.
17
 Caso de uso: Se representan con óvalos. La etiqueta en el óvalo indica la función
del sistema.
Tipos de casos de uso
Según cual sea el nivel de detalle:
Resumidos o de ’alto nivel’: Durante la fase de inicio la mayor parte de los casos de uso
deben tener esta forma.
Extensos: Durante la fase de elaboración los casos de uso deben escribirse de esta forma.
También se distingue entre:
Esenciales de implementación, reales o concretos: hacen referencia a detalles de la
interface.
18
 Actor: Un diagrama de caso de uso contiene los símbolos del actor y del caso de
uso, junto con líneas conectoras. Los actores son similares a las entidades externas;
existen fuera del sistema. El término actor se refiere a un rol específico de un
usuario del sistema.
Los actores no necesariamente coinciden con los USUARIOS. Un usuario puede
interpretar distintos roles, correspondientes a distintos actores.
Por ejemplo:
Un actor puede ser un empleado, pero también puede ser un cliente en la tienda de
la empresa. Incluso cuando es la misma persona en el mundo real, se representa
como dos símbolos distintos en un diagrama de caso de uso, ya que la persona
interactúa con el sistema en distintos roles.
19
Tipos de actores
 Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan
directa y frecuentemente con el software.
 Secundarios: soporte del sistema para que los primarios puedan trabajar.
 Iniciadores: no utilizan directamente el sistema, pero desencadenan el trabajo de
otro actor. (No aparecen en UML, pero sí los consideran otros autores)
Comunicaciones
Comunicación actor → sistema
 Para iniciar el caso de uso (siempre los inicia un actor).
 Para solicitar información del sistema.
 Para modificar la información del sistema.
 Para informar al sistema de que ha ocurrido algo en su entorno que le incumbe.
Comunicación sistema → actor
 Para comunicarle que ha sucedido algo, en el sistema, que le concierne.
20
 Para que le ayude a tomar una decisión necesaria para cumplir los objetivos del
sistema.
 Para delegar alguna responsabilidad en el actor.
Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con una línea simple. Para
relaciones entre casos de uso, se utilizan flechas etiquetadas “incluir” o “extender.” Una
relación “incluir” indica que un caso de uso es necesitado por otro para poder cumplir una
tarea. Una relación “extender” indica opciones alternativas para un cierto caso de uso.
 Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se utilizan
principalmente en los diagramas de casos de uso. Hay cuatro tipos básicos de
relaciones de comportamiento: comunica, incluye, extiende y generaliza.
21
Documentación de los casos de uso.
Existen dos formas principales de documentar un caso de uso:
 Un diagrama en UML
 Un documento detallado
Documentar casos de usos no es una tarea fácil que se pueda dominar de un día para otro,
requiere de tiempo, disciplina y experiencia, sin embargo, podemos definir una serie de
pasos identificables para escribir los casos de uso. [ CITATION Mar \l 10250 ]
22
 Formato de la documentación de caso de uso para los actores que participen:
 Documentación de un caso de uso:
23
24
III.3.1.2. Modelo de caso de uso del Gerente De Producción
Diagrama de Caso de Uso
Prototipos de Interfaz
25
26
III.3.1.3. Modelo de caso de uso de jefe de almacén.
Diagrama de caso de uso
Prototipos de interfaz
27
28
III.3.1.4. Modelo de caso de uso del jefe de produccion de turno.
Jefe de producción de
turno
29
30
III.3.1.5. Modelado de Caso de Uso del Operario de turno.
Prototipo de interfaz.
31
III.3.1.6. Modelado de Caso de Uso del jefe de control de calidad.
32
III.3.1.7. Modelado de Caso de Uso del Operario de control de calidad.
33
III.3.2. Nivel Táctico
III.3.2.1. Modelado de Caso de Uso del jefe de producción de turno.
34
III.3.2.2. Modelado de Caso de Uso del jefe de control de calidad.
 Diagrama de caso de uso
35
III.3.2.3. Modelado de Caso de Uso del jefe de almacén.
 Diagrama de Caso de Uso
36
37
III.3.3. Nivel Estratégico
III.3.3.1. Modelado de Caso de Uso del gerente de producción
 Diagrama de Caso de Uso
38
39
III.4. Diagrama de clases según su nivel de organización
III.4.1. Especificaciones del diagrama de clases
El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se
representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus
relaciones con los demás objetos, pero no muestra información temporal.
Con el fin de facilitar la comprensión del diagrama, se pueden incluir paquetes como
elementos del mismo, donde cada uno de ellos agrupa un conjunto de clases.
Este diagrama no refleja los comportamientos temporales de las clases, aunque para
mostrarlos se puede utilizar un diagrama de transición de estados.
Utilidad
 Ilustrar modelos de datos para sistemas de información, sin importar qué tan
simples o complejos sean.
 Comprender mejor la visión general de los esquemas de una aplicación.
 Expresar visualmente cualesquier necesidades específicas de un sistema y divulgar
esa información en toda la empresa.
 Crear diagramas detallados que resalten cualquier código específico que será
necesario programar e implementar en la estructura descrita.
 Ofrecer una descripción independiente de la implementación sobre los tipos
empleados en un sistema que son posteriormente transferidos entre sus
componentes.[ CITATION Luc \l 8192 ]
Elementos
 Clases
40
Una clase describe un conjunto de objetos con propiedades (atributos) similares y un
comportamiento común. Los objetos son instancias de las clases.
No existe un procedimiento inmediato que permita localizar las clases del diagrama de
clases. Estas suelen corresponderse con sustantivos que hacen referencia al ámbito del
sistema de información y que se encuentran en los documentos de las especificaciones de
requisitos y los casos de uso.
Dentro de la estructura de una clase se definen los atributos y las operaciones o métodos:
Los atributos de una clase representan los datos asociados a los objetos instanciados por esa
clase.
Las operaciones o métodos representan las funciones o procesos propios de los objetos de
una clase, caracterizando a dichos objetos.
Estructura de una clase:
En UML, una clase se representa con un rectángulo que posee tres divisiones, nombre de la
clase, atributos que tiene y mensajes que entiende.
En el primero de los cuadros se anota el nombre de la clase. Si es abstracta, se escribe en
letra cursiva o también se utiliza un estereotipo como < > arriba del nombre de la clase.
En la segunda parte van los atributos o variables de instancia; las variables de clase van
subrayados.
En el último cuadro se escriben las operaciones, es decir, los mensajes que puede entender.
Lo importante es documentar los mensajes más relevantes y no todos los mensajes de un
solo objeto.[ CITATION okd19 \l 8192 ]
41
 Relaciones
Los tipos más importantes de relaciones estáticas entre clases son los siguientes:
1.Asociación. Las relaciones de asociación representan un conjunto de enlaces entre
objetos o instancias de clases. Es el tipo de relación más general, y denota básicamente una
dependencia semántica. Por ejemplo, una Persona trabaja para una Empresa.
Cada asociación puede presentar elementos adicionales que doten de mayor detalle al tipo
de relación:
Rol, o nombre de la asociación, que describe la semántica de la relación en el sentido
indicado. Por ejemplo, la asociación entre Persona y Empresa recibe el nombre de trabaja
para, como rol en ese sentido.
Multiplicidad, que describe la cardinalidad de la relación, es decir, especifica cuántas
instancias de una clase están asociadas a una instancia de la otra clase. Los tipos de
multiplicidad son: Uno a uno, uno a muchos y muchos a muchos.
2.Herencia. Las jerarquías de generalización/especialización se conocen como herencia.
Herencia es el mecanismo que permite a una clase de objetos incorporar atributos y
métodos de otra clase, añadiéndolos a los que ya posee. Con la herencia se refleja una
relación “es_un” entre clases. La clase de la cual se hereda se denomina superclase, y la que
hereda subclase.
La generalización define una superclase a partir de otras. Por ejemplo, de las clases
profesor y estudiante se obtiene la superclase persona. La especialización o especificación
es la operación inversa, y en ella una clase se descompone en una o varias subclases. Por
42
ejemplo, de la clase empleado se pueden obtener las subclases secretaria, técnico e
ingeniero.
3.Agregación. La agregación es un tipo de relación jerárquica entre un objeto que
representa la totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento
físico de estructuras relacionadas lógicamente. Los objetos “son-parte-de” otro objeto
completo. Por ejemplo, motor, ruedas, carrocería son parte de automóvil.
Composición. La composición es una forma de agregación donde la relación de propiedad
es más fuerte, e incluso coinciden los tiempos de vida del objeto completo y las partes que
lo componen. Por ejemplo, en un sistema de Máquina de café, las relaciones entre la clase
máquina y producto, o entre máquina y depósito de monedas, son de composición.
4.Dependencia. Una relación de dependencia se utiliza entre dos clases o entre una clase y
una interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus
servicios.
 Interfaces
Una interfaz es una especificación de la semántica de un conjunto de operaciones de una
clase o paquete que son visibles desde otras clases o paquetes. Normalmente, se
corresponde con una parte del comportamiento del elemento que la proporciona.
 Paquetes
Los paquetes se usan para dividir el modelo de clases del sistema de información,
agrupando clases u otros paquetes según los criterios que sean oportunos. Las dependencias
entre ellos se definen a partir de las relaciones establecidas entre los distintos elementos que
se agrupan en estos paquetes
43
Notación
Las diferentes propiedades de la relación se pueden representar con la siguiente notación:
- Multiplicidad: La multiplicidad puede ser un número concreto, un rango o una
colección de números. La letra ‘n’ y el símbolo ‘*’ representan cualquier número.
- Orden: Se puede especificar si las instancias guardan un orden con la palabra clave
‘{ordered}’. Si el modelo es suficientemente detallado, se puede incluir una
restricción que indique el criterio de ordenación.
- Navegabilidad: La navegación desde una clase a la otra se representa poniendo una
flecha sin relleno en el extremo de la línea, indicando el sentido de la navegación.
- Rol o nombre de la asociación: Este nombre se coloca junto al extremo de la línea
que esta unida a una clase, para expresar cómo esa clase hace uso de la otra clase
con la que mantiene la asociación.
Además, existen notaciones específicas para los otros tipos de relación, como son:
- Agregación: Se representa con un rombo hueco en la clase cuya instancia es
una agregación de las instancias de la otra.
- Composición: Se representa con un rombo lleno en la clase cuya instancia
contiene las instancias de la otra clase.
44
- Dependencia: Una línea discontinua con una flecha apuntando a la clase cliente.
La relación puede tener un estereotipo que se coloca junto a la línea, y entre el
símbolo: << ... >>.
- Herencia: Esta relación se representa como una línea continua con una flecha
hueca en el extremo que apunta a la superclase.[ CITATION man \l 8192 ]
III.4.2. Identificación de sustantivos
1. Producción.
2. Insumos.
3. Almacén.
4. Gerencia.
5. Constancia.
6. Producto.
7. Control de calidad.
8. Proceso productivo.
9. Plátano.
10. Chifle.
11. Stock.
45
12. Jefe.
13. Operario de Turno.
III.4.3. Diagrama de clases del nivel operacional
46
47
III.4.4. Diagrama de clases del nivel táctico.
48
III.4.5. Diagrama de clases del nivel estratégico.
49
III.5. Diagrama de entidad-relación según su nivel de organización
III.5.1. Especificaciones del Diagrama de entidad-relación
Un diagrama entidad-relación, también conocido como modelo entidad relación o ERD, es
un tipo de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o
conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo
para diseñar o depurar bases de datos relacionales en los campos de ingeniería de software,
sistemas de información empresarial, educación e investigación. También conocidos como
los ERD o modelos ER, emplean un conjunto definido de símbolos, tales como rectángulos,
diamantes, óvalos y líneas de conexión para representar la interconexión de entidades,
relaciones y sus atributos. Son un reflejo de la estructura gramatical y emplean entidades
como sustantivos y relaciones como verbos.
50
Los diagramas de ER se relacionan con los diagramas de estructura de datos (DSD), que se
centran en las relaciones de los elementos dentro de las entidades, en lugar de las relaciones
entre las entidades mismas. Los diagramas ER a menudo se combinan con los diagramas de
flujo de datos (DFD), que trazan el flujo de la información para procesos o sistemas.
III.5.1.1. Usos de los diagramas entidad-relación
 Diseño de bases de datos: los diagramas ER se usan para modelar y diseñar bases
de datos relacionales, en términos de reglas de negocio y lógicas (en un modelo de
datos lógicos) y en términos de la tecnología específica que se implementará (en un
modelo de datos físicos). En ingeniería de software, un diagrama ER a menudo es
un primer paso para determinar los requisitos de un proyecto de sistemas de
información. También se usa más adelante para modelar una base de datos en
particular o varias. Una base de datos relacional tiene una tabla relacional
equivalente y puede expresarse así potencialmente, según sea necesario.
51
 Solución de problemas de bases de datos: los diagramas ER se usan para analizar
las bases de datos existentes con el fin de hallar y resolver problemas de lógica o
implementación. Al dibujar un diagrama se debería descubrir dónde está el
problema.
 Sistemas de información empresarial: los diagramas se usan para diseñar o
analizar las bases de datos relacionales empleadas en procesos de negocio.
Cualquier proceso de negocio que utilice datos de campo relacionados con
entidades, acciones e interacción puede beneficiarse potencialmente de una base de
datos relacional. Puede simplificar procesos, revelar información de forma más
sencilla y mejorar los resultados.
 Reingeniería de procesos de negocio (BPR): Los diagramas ER ayudan a analizar
las bases de datos empleadas en la reingeniería de procesos de negocio y en el
modelado de la configuración de una nueva base de datos.
 Educación: las bases de datos son el método actual de almacenamiento de
información relacional para propósitos educativos y la posterior recuperación. Así,
los diagramas ER pueden ser útiles para la planificación de esas estructuras de
datos.
 Investigación: como hay muchas investigaciones centradas en los datos
estructurados, los diagramas ER pueden desempeñar un papel fundamental en la
configuración de bases de datos útiles para analizar los datos.
52
III.5.1.2. Los componentes y las características de un diagrama ER
Los diagramas ER se componen de entidades, relaciones y atributos. También representan
la cardinalidad, que define las relaciones en términos de números. Puedes ver un glosario a
continuación:
Entidad
Algo que se puede definir, como una persona, objeto, concepto u evento, que puede tener
datos almacenados acerca de este. Piensa en las entidades como si fueran sustantivos. Por
ejemplo: un cliente, estudiante, auto o producto. Por lo general se muestran como un
rectángulo.
Tipo de entidad: un grupo de cosas que se pueden definir, como estudiantes o atletas,
mientras que la entidad sería el estudiante o atleta específico. Otros ejemplos son clientes,
autos o productos.
Conjunto de entidades: es igual que un tipo de entidad, pero se define en un momento
determinado, como por ejemplo estudiantes que se inscribieron en una clase el primer día.
Otros ejemplos son clientes que realizaron una compra en el último mes o autos registrados
actualmente en Florida. Un término relacionado es una instancia, en la que una persona
determinada o un auto específico podría ser una instancia del conjunto de entidades.
Categorías de entidades: las entidades se clasifican en fuertes, débiles o asociativas.
Una entidad fuerte se puede definir únicamente por sus propios atributos, en cambio,
una entidad débil no. Una entidad asociativa es aquella que relaciona entidades (o
elementos) dentro de un conjunto de entidades.
53
Claves de entidad: se refiere a un atributo que únicamente
define una entidad en un conjunto de entidades. Las claves de entidad se dividen en
superclave, clave candidata o clave primaria. Superclave: un conjunto de atributos (uno o
más) que juntos definen una entidad en un conjunto de entidades. Clave candidata: es una
superclave mínima, es decir, contiene el menor número posible de atributos para seguir
siendo una superclave. Un conjunto de entidades puede tener más de una clave
candidata. Clave primaria: es una clave candidata seleccionada por el diseñador de la base
de datos para identificar únicamente al conjunto de entidades. Clave extranjera: identifica
la relación entre las entidades.
Relación
Cómo las entidades interactúan o se asocian entre sí. Piensa en las relaciones como si
fueran verbos. Por ejemplo, el estudiante mencionado podría inscribirse en un curso. Las
dos entidades serían el estudiante y el curso, y la relación representada es el acto de
inscribirse, que conecta ambas entidades de ese modo. Las relaciones se muestran, por lo
general, como diamantes o etiquetas directamente en las líneas de conexión.
54
Relación recursiva: la misma entidad participa más de una vez en la relación.
Atributo
Una propiedad o característica de una entidad. A menudo se muestra como un óvalo o
círculo.
Atributo descriptivo: una propiedad o característica de una relación (frente a una entidad).
Categorías de los atributos: los atributos se clasifican en simples, compuestos y
derivados, así como de valor único o de valores múltiples. Simples: significa que el valor
del atributo es mínimo y ya no puede dividirse, como un número de teléfono. Compuestos:
los subatributos surgen de un atributo. Derivados: los atributos se calculan o derivan de otro
atributo, por ejemplo, la edad se calcula a partir de la fecha de nacimiento.
Valores múltiples: se denota más de un valor del atributo, como varios números de
teléfono para una persona.
Valor único: contienen solo un valor de atributo. Los tipos se pueden combinar, por ejemplo, puede
haber atributos de valor único simples o atributos de múltiples valores compuestos.
Cardinalidad
55
Define los atributos numéricos de la relación entre dos entidades o conjuntos de entidades. Las tres
relaciones cardinales principales son uno a uno, uno a muchos y muchos a muchos. Un ejemplo de
uno a uno sería un estudiante asociado a una dirección de correo electrónico. Un ejemplo de uno a
muchos (o muchos a uno, en función de la dirección de la relación) sería un estudiante que se
inscribe en muchos cursos, y todos esos cursos se asocian a ese estudiante en particular. Un
ejemplo de muchos a muchos sería los estudiantes en grupo están asociados a múltiples miembros
de la facultad y a su vez los miembros de la facultad están asociados a múltiples estudiantes.
Vistas de cardinalidad: la cardinalidad puede estar del lado opuesto o del mismo, en función de
dónde se muestran los símbolos.
Restricciones de cardinalidad: Los números máximos o mínimos que se aplican a una relación
Símbolos y notaciones de diagramas ER
Hay numerosos sistemas de notación que son similares, pero que se diferencian en algunos aspectos
específicos. [ CITATION luc191 \l 10250 ]
56
III.5.1.3. Estilo de la notación de Chen
Estilo
de la
ingeniería de la información, notación de Martin y notación patas de gallo
III.5.1.4. Estilo de la notación de Bachman
57
Estilo de la notación de IDEF1X
Relationships
Estilo de la notación de Barker
58
III.5.1.5. Modelos de datos físicos, lógicos y conceptuales
Los modelos de datos y los modelos ER se dibujan típicamente con hasta tres niveles de detalle:
 Modelo de datos conceptuales: la visualización de nivel más alto que contiene la
menor cantidad de detalle. Su valor muestra el alcance global del modelo y
representa la arquitectura del sistema. Para un sistema de menor alcance, quizás no
sea necesario dibujarlo. En cambio, se comienza con el modelo lógico.
 Modelo de datos lógicos: contiene más detalle que un modelo conceptual. Ahora se
definen las entidades transaccionales y operativas más detalladas. El modelo lógico
es independiente de la tecnología en la que se implementará.
 Modelo de datos físicos: uno o más modelos físicos pueden desarrollarse a partir
de cada modelo lógico. El modelo físico debe mostrar los suficientes detalles
tecnológicos para producir e implementar la base de datos en cuestión.
Ten en cuenta que existen niveles de alcance y de detalle similares en otros tipos de diagramas,
como los diagramas de flujo de datos, pero esto se contrasta con el enfoque de tres esquemas de la
ingeniería de software, que divide la información de forma diferente. En algunas ocasiones, los
ingenieros ramificarán los diagramas ER con jerarquías adicionales con el fin de agregar los niveles
de información necesarios para el diseño de la base de datos. Por ejemplo, pueden agregar
categorías mediante la ampliación hacia arriba con superclases y hacia abajo con subclases.
Limitaciones de los modelos y diagramas ER
 Exclusivo para datos relacionales: comprende que el propósito es solo mostrar las
relaciones. Los diagramas ER muestran únicamente la estructura relacional.
59
 Inadecuado para datos no estructurados: a menos que los datos se delineen
claramente en campos, filas o columnas diferentes, es probable que los diagramas
ER tengan un uso limitado. Lo mismo sucede con los datos semiestructurados,
porque solo algunos datos serán útiles.
 Complicaciones al realizar una integración con una base de datos
existente: usar modelos ER para realizar una integración con bases de datos
existentes puede ser un desafío debido a las diferentes arquitecturas.
Cómo dibujar un diagrama ER básico
 Propósito y alcance: definen el propósito y el alcance de lo que estás analizando o
modelando.
 Entidades: identifican las entidades involucradas. Cuando estés listo, comienza a dibujarlas
en rectángulos (o en la figura que selecciones en tu sistema) y etiquétalas como sustantivos.
 Relaciones: determinan cómo se relacionan todas las entidades. Dibuja líneas entre ellas
para indicar las relaciones y etiquétalas. Algunas entidades pueden no estar relacionadas, y
eso está bien. En diferentes sistemas de notación, la relación se puede etiquetar en un
diamante, otro rectángulo o directamente sobre la línea de conexión.
 Atributos: brindan más detalles mediante la adición de atributos clave de las entidades. Los
atributos a menudo se muestran como óvalos.
 Cardinalidad: muestra si la relación es 1-1, 1-muchos o muchos a muchos. [ CITATION
Onl \l 8192 ]
60
III.5.2. Diagrama de entidad-relación del nivel Operacional
61
III.5.3. Diagrama de entidad-relación del nivel Táctico
62
III.5.4. Diagrama de entidad-relación del nivel Estratégico
63
IV. Conclusiones
Luego del desarrollo de nuestro proyecto, las conclusiones son las siguientes:
 La elaboración del diagrama de actividades fue fundamental para comprender y
conocer el trabajo que se desarrolla en el subsistema de producción, si bien es cierto
que la empresa Agroindustrias Dasol EIRL necesita uno y solo un sistema
unificado, para fines didácticos el proyecto solo centró su estudio en dicho
subsistema. Elaborando así dos diagramas de actividades, el primero contiene el
trabajo actual que lleva la empresa en aquel subsistema y el segundo contiende la
versión mejorada del mismo.
 Es necesario conocer en que caso los actores ya definidos darán uso del sistema que
se desarrollará, por ello se trabajó un modelo de casos de uso, en el cual se
diagramó los casos de uso de cada actor y se diseñó una interfaz gráfica de usuario
con la cual se comunicará el actor y el sistema.
 Las instancias de las diferentes clases se comunican entre sí creando un vinculo de
multiplicidad, en el cual no es aceptada la relación de muchas instancias de una
clase con muchas de otras, dando como alternativa de solución la creación de una
clase puente. Esto se ve reflejado y aclarado en el uso del diagrama de clases.
 Existe un diagrama de entidad relación el cual es el fruto de un buen desarrollo del
diagrama de clases, aquí después de la aplicación de tres formas normales se obtiene
el primer prototipo para la implementación de bases de datos.
64
V. Bibliografía
Centeno, D. (s.f.). Modelado de Sistemas com UML.
Cevallos, K. (11/12/2017). UML: Casos de Uso.
Lucidchart. (s.f.). Obtenido de https://www.lucidchart.com/pages/es/tutorial-de-diagrama-
de-clases-uml
lucidchart. (2019). Obtenido de https://www.lucidchart.com/pages/es/tutorial-diagrama-de-
actividades-uml
lucidchart. (2019). lucidchart. Obtenido de https://www.lucidchart.com/pages/es/que-es-un-
diagrama-entidad-relacion
manuel.cillero.es. (s.f.). Diagrama de Clases. Obtenido de
https://manuel.cillero.es/doc/metrica-3/tecnicas/diagrama-de-clases/
Marco de Desarrollo de la Junta de Andalucía. (s.f.). juntadeandalucia. Obtenido de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
ok diario. (05 de Agosto de 2019). Obtenido de https://okdiario.com/curiosidades/que-
diagrama-clases-3323710
Online Diagram Software & Visual Solution | Lucidchart. (s.f.). Obtenido de Qué es un
diagrama entidad-relación: https://www.lucidchart.com/pages/es/que-es-un-
diagrama-entidad-relacion
65
66

Producción Chifles Final

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Producción Chifles Final

Cargado por

Copyright:

Formatos disponibles

MODELADOS DE DATOS

GESTIÓN DE PRODUCCIÓN DE PRODUCTOS AGROINDUSTRIALES DASOL

Martínez Balladares Mirella Elena

Urbina Avendaño Francisco Dampier

Ruiz Carrión Antonella

Morales García Aldair

Ruesta Sánchez Fabricio

Universidad Nacional de Piura

Facultad de Ingeniería Industrial

Escuela Profesional de Ingeniería Informática

Ing. Héctor Fiestas Bancayán Mgr

III. Marco teórico...............................................................................................................6

3.1. Referencia de la Organización.................................................................................6

3.1.1. Giro del negocio de la empresa.........................................................................6

3.1.2. Misión y Visión de la empresa..........................................................................6

3.1.3. Estudio de Sistemas..........................................................................................6

3.1.4. El subsistema a estudiar....................................................................................9

3.1.5. Procesos de negocio en el que participa el Subsistema Operaciones.............10

3.2. Diagrama de Actividades.......................................................................................10

3.2.1. Especificaciones del Diagrama de actividades...............................................10

3.2.2. Diagrama de actividades del proceso actual...................................................11

3.2.3. Deficiencias del D.A. del proceso actual........................................................13

3.2.4. Diagrama de actividades del proceso mejorado..............................................16

3.3. Modelos de Caso de Uso según su nivel de organización......................................17

3.3.1. Nivel Operativo...............................................................................................17

3.3.2. Nivel Táctico...................................................................................................34

3.3.3. Nivel Estratégico.............................................................................................38

3.4. Diagrama de clases según su nivel de organización...............................................40

3.4.2. Identificación de sustantivos...........................................................................45

3.4.3. Diagrama de clases del nivel operacional.......................................................46

3.4.4. Diagrama de clases del nivel táctico...............................................................48

3.4.5. Diagrama de clases del nivel estratégico........................................................49

3.5. Diagrama de entidad-relación según su nivel de organización..............................50

3.5.1. Especificaciones del Diagrama de entidad-relación.......................................50

3.5.2. Diagrama de entidad-relación del nivel Operacional......................................61

3.5.3. Diagrama de entidad-relación del nivel Táctico.............................................62

3.5.4. Diagrama de entidad-relación del nivel Estratégico.......................................63

En el desarrollo del presente trabajo, se analizará el desarrollo de un sistema a través del

análisis de modelado de datos para la empresa Agroindustrias Dasol EIRL, empresa

dedicada a la fabricación, comercialización y exportación de productos agroindustriales;

elaborado con el fin de la implementación de un software informático que automatice

enfocándonos en el nivel operativo, realizando los diagramas y descripciones de los casos

de usos de los diferentes actores de la empresa, el nivel estratégico, realizando los

El enfoque del presente desarrollo de software es conocer, analizar y diseñar un sistema

automatizando el flujo de datos, además de facilitar el procesado y trámite de

 Desarrollar un sistema para la “Gestión de producción de productos

agroindustriales DASOL” a través del modelado de datos.

de producción”, lo cual se detallará a través de un diagrama de actividades de la

empresa (uno actual y otro mejorado)

 Proporcionar una visión abstracta de los datos implementando el modelo de

 Elaborar un diagrama de clases para comprender y analizar la multiplicidad

existente entre instancias de diferentes clases.

 Elaborar el diagrama entidad relación para la conexión de datos con la base de

III.1. Referencia de la Organización

Empresa objeto de estudio: “AGROINDUSTRIAS DASOL E.I.R.L”.

III.1.1. Giro del negocio de la empresa

Agroindustrias Dasol EIRL es una empresa dedicada a la fabricación, comercialización y

exportación de productos agroindustriales, productos como: Chifles (Como producto

insignia), algarrobina, miel de abeja, natilla, toffee de sabores, cocadas, chumbeque,

alfajores, suplemento vitamínico, dulces, etcétera.

III.1.2. Misión y Visión de la empresa

Contribuir a que nuestros más tradicionales dulces se mantengan vigentes en el tiempo,

través de nuestras tiendas Delicias Peruanas.