INFORME SEMINARIO DE GRADO MODELO ENTIDAD RELACION

DIAGRAMA DE CLASES CASOS DE USO SV-AMBU

ALVARO FELIPE CRUZ CUBIDES

BRAYAN ANDRES AVENDAÑO SILVA

MANUEL STIVEN GONZALEZ MAHECHA

SEMINARIO DE GRADO

SV-AMBU

UNIVERSIDAD COOPERATIVA DE COLOMBIA

FACULTAD DE INGENIERIA

PROGRAMA INGENIERIA DE SISTEMAS

IBAGUE -TOLIMA

2017

INFORME SEMINARIO DE GRADO MODELO ENTIDAD RELACION

DIAGRAMA DE CLASES CASOS DE USO SV-AMBU

PRESENTADO POR:

ALVARO FELIPE CRUZ CUBIDES

CODIGO: 370506

BRAYAN ANDRES AVENDAÑO SILVA

CODIGO: 371630

MANUEL STIVEN GONZALEZ MAHECHA

CODIGO: 371567

PRESENTADO A:

JORGE MANUEL PACHECO CASADIEGO

SEMINARIO DE GRADO

SV-AMBU

UNIVERSIDAD COOPERATIVA DE COLOMBIA

FACULTAD DE INGENIERIA

PROGRAMA INGENIERIA DE SISTEMAS

IBAGUE -TOLIMA

2017

Esta obra está bajo una Licencia Creative Commons Atribución-

NoComercial-CompartirIgual 4.0 Internacional.

1. INDICE

1. INDICE ............................................................................................................. 3

2. INTRODUCCIÓN ............................................................................................. 6

3. PLANTEAMIENTO DEL PROBLEMA .............................................................. 8

4. OBJETIVO GENERAL ..................................................................................... 9

5. OBJETIVOS ESPECIFICOS .......................................................................... 10

6. MARCO TEORICO ........................................................................................ 11

6.2. PLATAFORMA ............................................................................................ 12

7. METODOLOGIA ............................................................................................ 14

7.1. ANALISIS DEL SISTEMA ............................................................................ 14

7.1.1. ALCANCE ................................................................................................ 14

7.1.2. REQUERIMIENTOS FUNCIONALES ...................................................... 15

7.2. DISEÑO ....................................................................................................... 26

7.2.1. ARQUITECTURA MODULAR .................................................................. 28

7.2.1.1. DIAGRAMA DE JERARQUIA DE MODULOS ......... ¡Error! Marcador no definido.

7.3. CONSTRUCCIÓN ....................................................................................... 34

7.3.1. CAPA DE ALMACENAMIENTO .................. ¡Error! Marcador no definido.

7.3.2. CAPA LOGICA ......................................................................................... 34

7.3.2.1. PROCEDIMIENTOS ............................................................................. 34

7.3.3. CAPA DE PRESENTACIÓN .................................................................... 35

7.3.3.1. INTERFAZ MENU PRINCIPAL ............................................................. 35

7.3.3.2. INTERFAZ DE EDICION ....................................................................... 41

7.3.3.2.1. GENERADA DE FORMA AUTOMATICA .......................................... 42

7.3.3.2.2. GENERADA CON LLAMADO A PROCEDIMIENTOS PL/SQL ......... 47

8. CONCLUSION 9. REFERENCIAS

LISTA DE FIGURAS

FIGURA 01. EDITAR GRUPOS ESPECIALIZADOS DE VENTAS……………………………..14

FIGURA 02. EDITAR UBICACIONES DE VENTAS AMBULANTES…………………………..15

FIGURA 03. EDITAR INFORMACIÓN BÁSICA DE LOS VENDEDORES………………………16

FIGURA 04. EDITAR INFORMACIÓN SOCIAL DE LOS VENDEDORES……………………...18

FIGURA 05. EDITAR GRADOS DE ESCOLARIDAD…………………………………………19

FIGURA 06. EDITAR SEGURIDAD SOCIAL……………………………..…………………..20

FIGURA 07. EDITAR NORMAS………………………………..……………………………21

FIGURA 8. MODELO CONCEPTUAL PARTE 1……………………………..………………..22

FIGURA 9. MODELO CONCEPTUAL PARTE 2……………………………..………………..23

FIGURA 10. MODELO RELACIÓN……………………………..……………………………24

FIGURA 11. ARQUITECTURA DE INSERCIÓN VENDEDOR…………………………………..25

FIGURA 12. ARQUITECTURA DE CONSULTA VENDEDOR…………………………….…….26

FIGURA 13. ARQUITECTURA DE INSERCIÓN GRUPO DE VENDEDOR ………………....…..27

FIGURA 14. ARQUITECTURA DE CONSULTA DE UN GRUPO DE VENDEDOR……………….28

FIGURA 15. PÁGINA DE INGRESO……………………………..…………………………..33

FIGURA 16. PÁGINA MENÚ……………………………..…………………………………34

FIGURA 17. INFORMACIÓN SOBRE EL SITIO………………………………………………35

FIGURA 18. JURÍDICO……………………………..………………………………………35

FIGURA 19. GALERÍAS……………………………..……………………………………..36

FIGURA 20. CONTACTOS……………………………..…………………………………..37

FIGURA 21. REPORTES……………………………..…………………………………….38

FIGURA 22. EDICIÓN……………………………..……………………………................39

FIGURA 23. FORM UBICACIÓN……………………………..……………………………..39

FIGURA 24. REPORTE 1……………………………..…………………………………….40

FIGURA 25. REPORTE 2……………………………..……………………………………40

FIGURA 26. FORM FAMILIAR……………………………..……………………………….41

FIGURA 27. FORM NORMAS……………………………..………………………………..41

FIGURA 28. FORM EDICION NORMA…………….……..…………………………………42

FIGURA 29. FORM VENDEDOR……………………………………………………………42

FIGURA 30. REPORTE 3 ……………………………..……………………………..….…43

FIGURA 31. GESTIÓN DE VENDEDOR……………………………..………………………44

FIGURA 32. GESTIÓN FAMILIARES ……………………………………………………….45

2. INTRODUCCIÓN

En la actualidad se ha podido evidenciar que a través del tiempo se ha presentado

en nuestra ciudad la proliferación o el aumento de los vendedores ambulantes, los

cuales originan algunas situaciones de orden público en cuanto a la invasión del

espacio púbico el cual no ha podido ser controlado por las autoridades

gubernamentales que no han creado estrategias o centros de ubicación que

permitan conocer las necesidades reales de esta población que labora en las calles

de manera no formalizada.

Aun teniendo en cuenta los avances en el manejo de información y la

implementación de las diversas tecnologías cuyo objetivo ha sido mejorar la

accesibilidad a estos grandes volúmenes de datos, que le permitan al hombre, en

las empresas o comunidades, tener un mayor control mediante los diferentes

elementos de hardware y software para procesarlos más rápido, obtener

información precisa, oportuna y confiable que contribuya al planteamiento y a la

toma de decisiones. A diferencia de lo que solía ser antiguamente los sistemas de

información y el manejo de estos, era más complicado, eran precarios, lentos, no

del todo seguros y sobre todo costosos.

Es aquí donde las autoridades gubernamentales deberán contar con una base de

datos y sistema de información que permita cuantificar en forma clara y precisa el

potencial de vendedores ambulantes que habitan en la ciudad y que generan

problemas de competencia al sector de comercio formalizado. Para esto se requiere

un estudio socioeconómico apoyado en herramientas de informática moderna y

tecnológicas de información que cuente con un software avanzado y robusto de

gran capacidad que permita clasificar a dichos vendedores por actividad comercial,

grupo de población, norma que regula su actividad y por ubicación, donde este

sistema cuente con un repositorio de información, sistema de captura, manejo y

reporte de estos.

A la vez tratar de evitar que la población infantil recurra a estos tipos de trabajo

donde algunos casos son apoyados por sus padres y no permiten que la niñez asista

a centros de educación y formación; por tal motivo se hace perentorio que las

autoridades municipales planifiquen y cree programas de apoyo, capacitación,

información y además brinden los mecanismos necesarios para que este grupo de

mercado logre desempeñar una actividad comercial de manera digna responsable

y segura.

3. PLANTEAMIENTO DEL PROBLEMA

Debido al constante crecimiento de la población Ibaguereña se ha notado que el

sector de vendedores ambulantes se encuentra invadiendo las calles de la ciudad,

en razón a que no se cuenta con otros medios de trabajo ni posibilidades laborales

que les permitan lograr un nivel de vida aceptable para su familia.

Es por esto que mucho de los ciudadanos que ejercen esta labor se ven abocados

a tener que vender sus productos de manera ambulante, invadiendo el espacio

público que es muy reducido por el alto crecimiento urbanístico en la ciudad.

Este problema se ha generalizado y en algunas ocasiones se observa el abuso de

autoridad quienes decomisan los productos a los vendedores, los privan de su

libertad y los humillan de manera inhumana; por tal razón la administración

municipal deberá crear fuentes de empleo que permitan combatir este flagelo laboral

como es el incremento de vendedores ambulantes sobre todo en temporadas de

fiestas como el mes de junio y temporada navideña.

La ciudad no cuenta con una herramienta que facilite el control del crecimiento de

esta población y gracias a que no hay un minucioso seguimiento de esta información

no es fácil tomar decisiones con las personas que usan este medio para la obtención

del sustento diario, pese al esfuerzo que han hecho las autoridades encargadas no

se ha podido dar una mejor calidad de vida a estas personas.

4. OBJETIVO GENERAL

Desarrollar un sistema de información que controle la gestión de datos de los

vendedores ambulantes en el centro de la ciudad de Ibagué.

5. OBJETIVOS ESPECIFICOS

Categorizar por grupos de ventas a los vendedores ambulantes.

Detallar las ubicaciones donde más se agrupan estas personas.

Identificar posibles ideas que solucionen la reubicación de estas personas

para librar el espacio público.

6. MARCO TEORICO

6.1. ANTECEDENTES

En [1] contempla el “espacio público el conjunto de inmuebles públicos y los

elementos arquitectónicos y naturales de los inmuebles privados, destinados por su

naturaleza, por su uso o afectación, a la satisfacción de necesidades urbanas

colectivas que transcienden, por tanto, los límites de los intereses, individuales de

los habitantes.”

Por ende, se define este espacio público como las áreas que están siendo

requeridas no solo por peatonales sino vehicular, también se tienen en cuenta las

áreas para la recreación publica, ya sea activa o pasiva para la tranquilidad

ciudadana. Se reconocen a los vendedores informales ambulantes como [2] “Sin

confianza legítima, aquellas personas naturales que se dediquen a la

comercialización de bienes de uso y/o consumo que no se encuentren debidamente

acreditados con la prenda o chaleco entregado por la secretaria de Gobierno

Municipal”

[3]“En Bogotá el 35% de los trabajadores están en la informalidad. En Medellín el

15,3%; Barranquilla el 13%; Bucaramanga 4%; Cúcuta e Ibagué 17%, Pereira y

Pasto 8%. Mientras que en Cali este indicador descendió 2,5% y en Manizales

4,5%.”

Las cifras en algunas ciudades disminuyen, pero en otras aumentan gracias al

crecimiento que cada una de estas tiene, aumentando el desplazamiento de

personas que usan este método para adquirir su sustento diario, la ciudad siempre

se verá enfrentada al crecimiento o desarrollo ilegal de barrios en lugares de esta,

e invasión de los mismos en lugares públicos.

[4] Gracias a esto nace la duda de como poder tener un mayor control de esto. Los

sistemas de gestión de información de mano de las tecnologías que avanzan día a

día son un gran aporte para estos temas.

Estos sistemas han cambiado la manera en que se mueven las organizaciones

actualmente, por su fácil uso se obtienen importantes mejores, ya que estas

optimizan los procesos operativos y suministran la información necesaria para la

toma de decisiones.

6.2. Plataforma

Según un artículo en Gestiopolis “Un Sistema de Información es un conjunto de

elementos que interactúan entre sí con el fin de apoyar las actividades de una

empresa o negocio. En un sentido amplio, un sistema de información no

necesariamente incluye equipo electrónico. Sin embargo, en la práctica se utiliza

como sinónimo de “sistema de información computarizado”.

Oracle Application Express

[5] Oracle Application Express te permite diseñar, desarrollar e implantar

aplicaciones responsivas sobre la base de datos usando sólo tu navegador web.

Entérate de cómo tomar ventaja de esta característica gratuita y totalmente

soportada de la base de datos de Oracle.

[6] Esta aplicación nos permite desarrollar en un moderno y poderoso entorno de

desarrollo para implantar aplicaciones de manera muy rápida, personalizable y fácil.

Maneja un entorno de desarrollo basado en web, editor de código con resaltado de

sintaxis y sugerencias de código, diseño intuitivo con herramientas de tipo “arrastrar

y soltar”, haz cambios al momento sin tener que compilar o implantar la aplicación,

generación de reportes sobre los metadatos de la aplicación, soporte completo de

SQL, PL/SQL y Javascript, integración perfecta con las características de la base

de datos de Oracle (Data Mining, Spatial, RAS, y más), integración con servicios

REST y SOAP, extensible con Plug-ins, interfaces de usuario para dispositivos

móviles con jQuery Mobile.

[7] PL / SQL es un lenguaje de procedimientos diseñados específicamente para

abrazar las sentencias SQL dentro de su sintaxis. PL / SQL unidades de programa

son compilados por el servidor de base de datos Oracle y almacenados dentro de

la base de datos. Y en tiempo de ejecución, tanto de PL / SQL y SQL se ejecutan

dentro del mismo proceso de servidor, con lo que la eficiencia óptima. PL / SQL

hereda automáticamente la solidez, seguridad y portabilidad de la base de datos

Oracle.

El motivo porque se utilizan estos lenguajes es porque una aplicación que utiliza

bases de datos Oracle es inútil a menos que se conserva sólo los datos correctos y

completos. La manera tradicional de asegurar esto es para exponer la base de datos

sólo a través de una interfaz que oculta los detalles de implementación - las tablas

y las sentencias SQL que operan en éstos.

7. METODOLOGIA

7.1. ANALISIS DEL SISTEMA

7.1.1. ALCANCE Elaboración de un sistema de información, el cual facilite la administración de la

información referente a los aspectos comerciales, sociales y normativos pertinentes

a los vendedores ambulantes del centro de Ibagué. Lo mismo que agregar,

visualizar, modificar datos de un usuario.

Este sistema de información pretende además mantener y actualizar la información

de eventos, decretos, leyes y todo el ámbito jurídico que está detrás del sector

económico de los vendedores ambulantes y el espacio público.

Con el desarrollo de este proyecto se pretende diseñar el SI y BD que permitan

tener un control efectivo sobres las personas que ejercen esta profesión en el centro

de la cuidad de Ibagué, logrando un mejoramiento en las soluciones de estadísticos,

otorgamiento de permisos, y reubicación de los vendedores informales.

7.1.2. REQUERIMIENTOS FUNCIONALES EDITAR GRUPOS ESPECIALIZADOS DE VENTAS

Registrar Grupos:

Se requieren los siguientes datos para el registro de grupos especializados de ventas: nombre, descripción, productos, ubicación, hora de inicio y hora de finalización.

Modificar Grupos:

Se podrá realizar modificación de datos respecto a los grupos especializados de ventas en cualquier momento, además cada acción quedará guardada en una bitácora.

Consultar Grupos

Se podrán consultar los siguientes datos de los grupos: nombre, descripción, productos, ubicación, hora de inicio y hora de finalización.

Generar Reporte de Grupos

Al momento de generar el reporte los usuarios tendrán la opción de visualizarlo por sea por pantalla o imprimirlo, para así tener un soporte de la información que haya en el sistema de información

Reportes

Por sexo

Fecha ingreso

Edades

Situación familiar

Antecendentes

Normas que los acobijan

Cumplimientos de dichas normas

Figura 01. Editar Grupos especializados de Ventas.

En este caso de uso en la figura 01 se puede apreciar que está diseñado para realizar registro, modificación, consulta sobre los diferentes grupos especializados de ventas, pero también es posible generar reportes de los mismos.

EDITAR UBICACIONES DE VENTAS AMBULANTES

Registrar Ubicación de Venta

Se requieren de los siguientes datos para el registro de Ubicación de Veta: nombre y descripción de ubicación.

Modificar Ubicación de Venta

Se podrá realizar modificación de datos respecto a la Ubicación de Venta en cualquier momento, además cada acción quedará guardada en una bitácora.

Figura 02. Editar Ubicaciones De Ventas Ambulantes

En este caso de uso en la figura 02 se puede apreciar que está diseñado para realizar registro y modificación sobre la ubicación de las ventas ambulantes.

EDITAR INFORMACION BASICA DE LOSVENDEDORES

Registrar Información Básica de los Vendedores:

Se requieren de los siguientes datos para el registro de la información básica de los vendedores: nombre, tipo de identificación, identificación, grupo de venta al que pertenece.

Modificar Información Básica de los Vendedores

Se podrá realizar modificación de datos respecto a la Información Básica de los Vendedores en cualquier momento, además cada acción quedará guardada en una bitácora.

Consultar Información Básica de los Vendedores

Se podrán consultar los siguientes datos de la Información básica de los Vendedores: nombre, tipo de identificación, identificación, grupo de venta al que pertenece.

Generar Reporte de Información Básica de los Vendedores

Figura 03. Editar Información Básica De Los vendedores

En este caso de uso en la figura 03 se puede apreciar que está diseñado para realizar registro, modificación, consulta de la información básica de los vendedores, pero también es posible generar reportes de los mismos.

EDITAR INFORMACION SOCIAL DE LOS VENDEDORES

Registrar Información Social de los Vendedores

Se requieren de los siguientes datos para el registro de la información social de los Vendedores: municipio de procedencia, dirección de residencia, nivel de escolaridad, seguridad social, estrato socioeconómico, integrantes del núcleo familiar.

Modificar Información Social de los Vendedores

Se podrá realizar modificación de datos respecto a la Información Social de los Vendedores en cualquier momento, además cada acción quedará guardada en una bitácora.

Consultar Información Social de los Vendedores

Se podrán consultar los siguientes datos de la Información Social de los Vendedores: municipio de procedencia, dirección de residencia, nivel de escolaridad, seguridad social, estrato socioeconómico, integrantes del núcleo familiar.

Figura 04. Editar Información Social De Los Vendedores

En este caso de uso en la figura 04 se puede apreciar que está diseñado para realizar registro, modificación y consulta sobre la información social de los vendedores.

CONSULTAR DATOS DEL VENDEDOR

Consultar Ubicación de los Vendedores:

Se podrán consultar los siguientes datos de la Ubicación de los Vendedores: nombre del vendedor, nombre y descripción de ubicación.

Generar Reporte de la Ubicación de los Vendedores

Generar Reporte del Grupo al que Pertenecen los Vendedores

EDITAR GRADOS DE ESCOLARIDAD

Registrar Grados De Escolaridad

Se requieren de los siguientes datos para el registro de Grados de Escolaridad: id del grado, nombre del grado de escolaridad, descripción del grado de escolaridad.

Modificar Grados De Escolaridad

Se podrá realizar modificación de datos respecto a los Grados de Escolaridad en cualquier momento, además cada acción quedará guardada en una bitácora.

Figura 05. Editar Grados De Escolaridad

En este caso de uso en la figura 05 se puede apreciar que está diseñado para realizar registro y modificación de los grados de escolaridad de cada vendedor.

EDITAR SEGURIDAD SOCIAL

Registrar Seguridad Social

Se requieren de los siguientes datos para el registro de la Seguridad Social: id de la seguridad social, tipo de seguridad social, detalle de la seguridad social.

Modificar Seguridad Social

Se podrá realizar modificación de datos respecto a la Seguridad Social en cualquier momento, además cada acción quedará guardada en una bitácora.

Figura 06. Editar Seguridad Social

En este caso de uso en la figura 06 se puede apreciar que está diseñado para realizar registro y modificación de la seguridad social de cada vendedor

EDITAR NORMAS

Registrar Normas:

En el registro de normas se debe ingresar el código de la norma, tipo, numero, año de inicio de vigencia.

Modificar Normas:

Al modificar las normas se actualizarán los mismos datos que se ingresaron en el registro.

Figura 07. Editar Normas

En este caso de uso en la figura 07 se puede apreciar que está diseñado para realizar registro y modificación de las diferentes normas que debe cumplir cada uno de los vendedores ambulantes.

7.1.3. MODELO CONCEPTUAL DE DATOS

Figura 8. Modelo conceptual parte 1

pertenece

se organiza

comercializanreferenciado

aplica

ejecuta

contiene

pertenece a

tip_norma

id_tipo_norma

cod_tipo

<pi> Short integer

Integer

<M>

Identifier_1 <pi>

norma

cod_norma

num_norma

año_norma

descrip

direccion_archivo

<pi> Integer

Integer

Date

Variable characters (150)

Variable characters (90)

<M>

Identifier_1 <pi>

acciones

id_accion

descripcion_accion

<pi> Short integer

Variable characters (150)

<M>

Identifier_1 <pi>

tema

id_tema

descripcion_tema

<pi> Short integer

Variable characters (150)

<M>

Identifier_1 <pi>

grupo_norma

id_grupo_norma <pi> Short integer <M>

Identifier_1 <pi>

grupo_venta

id_grupo

nombre_grupo

descrip

<pi> Short integer

Variable characters (50)

Variable characters (150)

<M>

Identifier_1 <pi>

producto

id_producto

nombre_producto

<pi> Short integer

Variable characters (50)

<M>

Identifier_1 <pi>

gurpo/ubicacion

id_grupo/ubicacion

frecuencia

hora_inicio

hora_final

<pi> Short integer

Variable characters (100)

Time

Time

<M>

Identifier_1 <pi>

ubicacion

id_ubicacion

nombre_ubicacion

descripcion_ubicacion

<pi> Short integer

Variable characters (50)

Variable characters (150)

<M>

Identifier_1 <pi>

Parte uno y dos del modelo conceptual en la figura 08 y figura 09, diseño realizado en Sqldeveloper donde se muestran las relaciones y los atributos de cada entidad presente en la base de datos. Encontramos la estructura de la base de datos, contando con las entidades, vendedor, familiar, seguridad social, grupo de venta, grupo de vendedor, estrato, municipio, familia del vendedor, norma, tipo de norma, se encuentran debidamente relacionadas según sea

7.2. DISEÑO

se identifica

pertenecee

pertenece aa

pertenece--

ultimo grado

corresponde a

proviene de

pertenece

vive en

se ubica

grupo_venta

id_grupo

nombre_grupo

descrip

<pi> Short integer

Variable characters (50)

Variable characters (150)

<M>

Identifier_1 <pi>

grupo_vendedor

id_grupo_vendedor <pi> Short integer <M>

Identifier_1 <pi>

municipio

id_municipio

nombre_municipio

<pi> Short integer

Variable characters (20)

<M>

Identifier_1 <pi>

vendedor

tipo_id

id_vendedor

nom_vendedor

<pi>

Variable characters (20)

Integer

Variable characters (50)

<M>

Identifier_1 <pi>

estrato

id_estrato

estrato

<pi> Short integer

Variable characters (10)

<M>

Identifier_1 <pi>

escolaridad

id_escolaridad

nivel_escolaridad

descrip

<pi> Short integer

Variable characters (10)

Variable characters (150)

<M>

Identifier_1 <pi>

seguridad_social

id_seguridad

nombre_entidad

descrip

<pi> Short integer

Variable characters (50)

Variable characters (150)

<M>

Identifier_1 <pi>

familia/vendedor

consecutivo <pi> Integer <M>

Identifier_1 <pi>

familiar

id_familiar

nombre_familiar

identificacion

<pi> Integer

Variable characters (50)

Integer

<M>

Identifier_1 <pi>

tipo_familiar

id_tipo_familiar

tipo_familiar

<pi> Short integer

Variable characters (20)

<M>

Identifier_1 <pi>

Figura 9. Modelo conceptual parte 2

tip_norma

id_tipo_norma

cod_tipo

SMALLINT

INTEGER

<pk>

norma

cod_norma

id_tipo_norma

id_tema

num_norma

año_norma

desc_grupo_venta

direccion_archivo

INTEGER

SMALLINT

SMALLINT

INTEGER

DATE

VARCHAR2(150)

VARCHAR2(90)

<pk>

<fk1>

<fk2>

acciones

id_accion

id_tema

descripcion_accion

SMALLINT

SMALLINT

VARCHAR2(150)

<pk>

<fk>

tema

id_tema

descripcion_tema

SMALLINT

VARCHAR2(150)

<pk>

grupo_norma

id_grupo_norma

cod_norma

id_grupo

SMALLINT

INTEGER

SMALLINT

<pk>

<fk1>

<fk2>

grupo_venta

id_grupo

nombre_grupo

desc_grupo_venta

SMALLINT

VARCHAR2(50)

VARCHAR2(150)

<pk>

grupo_vendedor

id_grupo

id_grupo_vendedor

id_vendedor

SMALLINT

SMALLINT

INTEGER

<pk,fk1>

<pk>

<fk2>

producto

id_producto

id_grupo

nombre_producto

SMALLINT

SMALLINT

VARCHAR2(50)

<pk>

<fk>

grupo/ubicacion

id_grupo

id_grupo/ubicacion

id_ubicacion

frecuencia

hora_inicio

hora_final

SMALLINT

SMALLINT

SMALLINT

VARCHAR2(100)

DATE

DATE

<pk,fk1>

<pk>

<fk2>

ubicacion

id_ubicacion

nombre_ubicacion

descripcion_ubicacion

SMALLINT

VARCHAR2(50)

VARCHAR2(150)

<pk>

municipio

id_municipio

nombre_municipio

SMALLINT

VARCHAR2(20)

<pk>

vendedor

tipo_id

id_vendedor

id_municipio

id_escolaridad

mun_id_municipio

id_estrato

id_seguridad

nom_vendedor

ape_vendedor

genero

telefono

mail

VARCHAR2(20)

INTEGER

SMALLINT

SMALLINT

SMALLINT

SMALLINT

SMALLINT

VARCHAR2(50)

VARCHAR2(45)

VARCHAR2(45)

VARCHAR2(45)

VARCHAR2(45)

<pk>

<fk1>

<fk4>

<fk2>

<fk3>

<fk5>

estrato

id_estrato

estrato

SMALLINT

VARCHAR2(10)

<pk>

escolaridad

id_escolaridad

nivel_escolaridad

desc_grupo_venta

SMALLINT

VARCHAR2(10)

VARCHAR2(150)

<pk>

seguridad_social

id_seguridad

nombre_entidad

desc_grupo_venta

SMALLINT

VARCHAR2(50)

VARCHAR2(150)

<pk>

grupo_familiar

consecutivo

id_vendedor

id_familiar

INTEGER

INTEGER

INTEGER

<pk>

<fk1>

<fk2>

familiar

id_familiar

id_tipo_familiar

nombre_familiar

identificacion

INTEGER

SMALLINT

VARCHAR2(50)

INTEGER

<pk>

<fk>

tipo_familiar

id_tipo_familiar

tipo_familiar

SMALLINT

VARCHAR2(20)

<pk>

Figura 10. Modelo Relación

7.2.1. ARQUITECTURA MODULAR 7.2.1.1. Arquitectura de inserción de vendedor Figura 11. Arquitectura de inserción vendedor

En la figura 11 se aprecia la arquitectura que se utiliza para la inserción de un vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)

INSERTAR VENDEDOR

REG_VENDEDOR

MSG REG_VENDEDOR

CAPA PRESENTACIÓN

CONTROLADOR DE LA INSERCIÓN

VERIFICAR VENDEDOR

DESPLEGAR MENSAJE

MEN

RES

Id_vendedor

7.2.1.2 Arquitectura de consulta Vendedor. En la figura 12 se aprecia la arquitectura que se utiliza para la consulta de un vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)

Figura12.Arquitectura de consulta a un VENDEDOR

DESPLEGAR VENDEDOR

Id_vendedor

RES

Id_vendedor

V_REG

V_REG

MSG Id_vendedor

CAPA PRESENTACIÓN

CONTROLADOR VERIFICADOR DE LA

CONSULTA

VERIFICAR VENDEDOR CONSULTAR VENDEDOR

7.2.1.3 Arquitectura de inserción Grupo de Vendedor En la figura 13 se aprecia la arquitectura que se utiliza para la inserción de un grupo de vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)

Figura 13. Arquitectura de inserción GRUPO DE VENDEDOR

INSERTAR GRUPO DE VENDEDOR

REG_GRUPOVENDEDOR

MSG REG_GRUPOVENDEDOR

CAPA PRESENTACIÓN

CONTROLADOR DE LA INSERCIÓN

VERIFICAR GRUPO DE VENDEDOR

DESPLEGAR GRUPO DE VENDEDOR

MEN

RES

Id_GRUPOVENDEDOR

7.2.1.4 Arquitectura de consulta de un Grupo de Vendedor. En la figura 14 se aprecia la arquitectura que se utiliza para la consulta de un grupo vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)

Figura 14. Arquitectura de consulta a un GRUPO DE VENDEDOR

DESPLEGAR GRUPO DE VENDEDOR

Id_GRUPOVENDEDOR

RES

Id_GRUPOVENDEDOR

V_REG

V_REG

MSG Id_GRUPOVENDEDOR

CAPA PRESENTACIÓN

CONTROLADOR VERIFICADOR DE LA

CONSULTA

VERIFICAR GRUPO DE VENDEDOR

CONSULTAR GRUPO DE VENDEDOR

7.2.1.5 DESCRIPCIÓN DE MÓDULOS

7.2.1.5.1 Funcionalidad consulta proyecto Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador verificador de la consulta, por medio de la variable ID_PROYECTO, después el módulo controlador verificador de la consulta invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje. Controlador verificador de la consulta: Este módulo facilita el control de la secuencia para hacer el procedimiento consultar un proyecto a la base de datos, atreves de la invocación de los módulos VERIFICAR PROYECTO, CONSULTAR PROYECTO Y DESPLEGAR MENSAJE. Verificar proyecto: Este módulo es llamado atreves de la variable ID_PROYECTO, que trae acoplamiento de datos (atributos), para constatar la existencia o no del proyecto, enviando así, una bandera de control por medio de la variable RES para continuar el proceso. Consultar Proyecto: Permite la consulta de datos del proyecto a la base de datos por medio de la variable ID_PROYECTO que trae los atributos correspondientes al proyecto. Desplegar Mensaje: Generar y muestra el mensaje en la capa gráfica.

7.2.1.5.2 Funcionalidad inserción proyecto Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador de la inserción por medio de la variable REG_PROYECTO, después el módulo controlador de la inserción invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje.

Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador de la inserción por medio de la variable REG_PROYECTO, después el módulo controlador de la inserción invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje. Controlador de la Inserción: Este módulo facilita el control de la secuencia para hacer el procedimiento de insertar a la base de datos, atreves de la invocación de los módulos VERIFICAR PROYECTO, INSERTAR PROYECTO Y DESPLEGAR MENSAJE. Verificar Proyecto: Este módulo es llamado atreves de la variable ID_PROYECTO, que trae acoplamiento de datos (atributos), para constatar la existencia o no del proyecto, enviando así, una bandera de control por medio de la variable RES para continuar el proceso. Insertar Proyecto: Permite el registro de datos del proyecto a la base de datos por medio de la variable REG_PROYECTO que trae los atributos correspondientes al proyecto. Desplegar Mensaje: Generar y muestra el mensaje en la capa gráfica.

7.3. CONSTRUCCIÓN 7.3.1. CAPA DE ALMACENAMIENTO “Script de la base de datos Vendedores (Ver Anexo A)”.

7.3.2. CAPA LOGICA

7.3.2.1. PROCEDIMIENTOS Se muestran a continuación los procedimientos utilizados para la inserción de algunas entidades o atributos del aplicativo, con su respectivo procedimiento diseñado el SQLDEVELOPER. -------------------------------------------------------------------------------------------------------------- Insertar municipio create or replace procedure insertarmunicipio(reg_municipio municipio%rowtype) is begin insert into municipio values(reg_municipio.id_municipio, reg_municipio.nombre_municipio); commit; end;

Insertar Familiar create or replace PROCEDURE PRINSERTAFAMILIAR (rgfamiliar in familiar%rowtype, omsn OUT varchar2) IS BEGIN INSERT INTO FAMILIAR(ID_FAMILIAR,ID_TIPO_FAMILIAR,NOMBRE_FAMILIAR,IDENTIFICACION) VALUES(rgfamiliar.ID_FAMILIAR,rgfamiliar.ID_TIPO_FAMILIAR,rgfamiliar.NOMBRE_FAMILIAR,rgfamiliar.IDENTIFICACION);

omsn := 'Familiar asignado satisfactoriamente'; EXCEPTION WHEN OTHERS THEN omsn := SQLERRM; END; -------------------------------------------------------------------------------------------------------------- Insertar vendedor create or replace PROCEDURE PRINSERTAVENDEDOR (rgvendedor in vendedor%rowtype, omsn OUT varchar2) IS BEGIN INSERT INTO VENDEDOR(ID_VENDEDOR,ID_MUNICIPIO,ID_ESCOLARIDAD,MUN_ID_MUNICIPIO,ID_ESTRATO,ID_SEGURIDAD,NOM_VENDEDOR,APE_VENDEDOR,GENERO,TELEFONO,MAIL) VALUES (rgvendedor.ID_VENDEDOR,rgvendedor.ID_MUNICIPIO,rgvendedor.ID_ESCOLARIDAD,rgvendedor.MUN_ID_MUNICIPIO,rgvendedor.ID_ESTRATO, rgvendedor.ID_SEGURIDAD,rgvendedor.NOM_VENDEDOR,rgvendedor.APE_VENDEDOR,rgvendedor.GENERO,rgvendedor.TELEFONO,rgvendedor.MAIL); omsn := 'VENDEDOR Creada Satisfactoriamente'; EXCEPTION WHEN OTHERS THEN omsn := SQLERRM; END;

7.3.3. CAPA DE PRESENTACIÓN

7.3.3.1. INTERFAZ MENU PRINCIPAL Página Ingreso

Figura 15. Página de ingreso

En la Figura 15 se muestra donde el usuario deberá ingresar con los datos que se le van a brindar para tener total acceso a la aplicación, claramente los usuarios tendrán un rango de permisos y de acceso al aplicativo, ocultando áreas según el rol que cumplan.

Página Menú Figura 16. Página Menú.

En la figura 16 se encuentran las áreas de información para los usuarios visitantes de la página, a continuación, se presenta cada una de ellas. Sobre el sitio

Figura 17. Información sobre el Sitio

En la Figura 17 se muestra la información básica sobre el sitio de aplicación, sobre su uso y lo que se puede encontrar dentro de este. Jurídico Figura 18. Jurídico

En la figura 18 se muestra la información respecto a el ámbito jurídico que implementa el sistema de información y en parte definiciones establecidas por el ente gubernamental, donde se referenciaran las normas que acobijan las distintas clasificaciones de los vendedores. Galerías Figura 19. Galería.

En la figura 19 se muestra la página donde se podrán observar distintas fotos de cómo se encuentra la ciudad en donde más se concentran los vendedores ambulantes, el estado en que se encuentran, la ubicación y la manera en la que obstruyen el espacio público.

Contáctenos Figura 20. Contactos

En la figura 20 se muestra el área donde el usuario invitado podrá enviar solicitudes de información o de petición de registro en la base de datos o modificaciones, fácilmente se podrá contactar el usuario y brindar información respecto a la solicitud.

Reportes Figura 21. Reportes

En la figura 21 se muestra el área donde se generarán algunos reportes de información básica para los demás usuarios visitantes, como tales la lista de normas, ubicaciones y alguna otra información no tan comprometedora de los vendedores.

7.3.3.2. INTERFAZ DE EDICION Figura 22. Edicion.

En la figura 22 se muestra la interfaz de edición se encuentran algunas pestañas donde se podrán hacer modificaciones y entre estas hay dos (Social, Vendedor) las cuales están elaboradas por procedimientos PL/SQL pero de igual manera están del modo automático en los “Form”

7.3.3.2.1. GENERADA DE FORMA AUTOMATICA Figura 23. Form Ubicación

En la figura 23 se muestra el formulario donde se puede evidenciar como la aplicación al seleccionar una ubicación el permitirá realizar la edición del nombre de esta y también su descripción.

Figura 24. Reporte 1

En la figura 24 se muestra el Reporte 1 generado con edición habilitada se muestra en la figura 24, para que liste las ubicaciones en las cuales se encuentran ubicados los vendedores ambulantes, con el nombre de la ubicación y la descripción de esta, claramente este reporte permite la adición, edición y eliminación de estas mientras el rol en el cual haya ingresado tenga los permisos. Form Social Figura 25. Reporte 2

En la figura 25 se muestra el reporte de la información social del vendedor, se listará la información de este y de igual manera tambien es posible modificar esta para facilitar la actualización de la información en la base de datos, encontramos información general de los familiares de cada vendedor, con numero de identificación, nombres y tipo de familiar. Figura 26. Form Familiar

Edición de un familiar según la lista anterior en la Figura 26, en esta muestra el tipo de familiar, el id del familiar, el nombre del familiar, y el número de identificación, permitiendo actualizar estos datos en caso de algún ingreso erróneo. Form Normas Figura 27. Form Normas

En la figura 27 se encuentra la lista de normas que acobijan las distintas clasificaciones de los vendedores ambulantes, según tipo, tema, n° de norma, año y descripción de esta, de igual manera permite la modificación de cada una de estas. Figura 28. Form edición Norma

En la figura 28 se muestra como se puede editar la información de la norma registrada, claramente estas solo podrán modificarla usuarios con los permisos adecuados ya que se habla de algo legal y no deberá tener modificaciones fácilmente a menos de que a nivel nacional haya una actualización de esta. Form Vendedor Figura 29. Form Vendedor

En esta figura 29 se puede realizar la edición de la información del vendedor en la cual se registra el municipio, escolaridad, estrato, seguridad social, nombres, apellidos, genero, teléfono y e-mail. Facilitando así la actualización de datos de los vendedores registrados en el sistema. Figura 30. Reporte 3

En la figura 30 se muestra el reporte generado de los vendedores que se encuentran actualmente inscritos en la base de datos, con toda su información incluyendo información social, ubicación y las normas que los acobijan.

7.3.3.2.2. GENERADA CON LLAMADO A PROCEDIMIENTOS PL/SQL Figura 31. Gestión de Vendedor

En la Figura 31 se visualiza el formulario en el que se podrá ingresar un nuevo vendedor con los datos que solicita, claramente es obligatorio rellenar cada campo ya que se encuentra señalizado como requerido.

Figura 32. Gestión Familiares

En la Figura 32 se muestra el formulario para el ingreso de un nuevo familiar agregando la conexión directamente con el vendedor para que así quede relacionado a la hora de realizar búsquedas.

CONCLUSIONES

Este proyecto el cual tiene como bases principales el proceso de registro, almacenamiento y control de los datos de los vendedores ambulantes del centro de la cuidad de Ibagué, mejorando la administración de esta información y de lo que podemos concluir:

Con el diseño y desarrollo de este sistema de información; si se logra implementar

y se registran los datos correspondientes se obtendrán reportes que ayudarán a la

administración municipal a tomar mejores decisiones en determinado momento.

Para los trabajadores del área de Dirección de Espacio Público y Control Urbano,

se hace cada vez más evidente la necesidad de contar con un sistema automatizado

que les permita registrar los datos y obtener los informes de manera ágil, para dar

respuestas rápidas y llevar un control más riguroso de este tipo de información.

REFERENCIAS [1] Ley N° 9 de 1989, Capitulo II, Articulo 5. enero 11, Tomado 14 febrero de 2017. [2] Decreto No. 0091 de 2005, febrero 21 de 2005. Artículo Tercero, Tomado 14 de febrero de 2017. [3] Barranquilla, Cúcuta e Ibagué con el mayor número de informales, tomado de www.dinero.com [4] Sitio oficial de la alcaldía municipal de Ibagué - Por Ibagué con todo el Corazón. (2017). Alcaldía caracteriza vendedores informales de la ciudad. [online] Disponible en: http://www.ibague.gov.co/portal/seccion/noticias/index.php?Idnt=1537 [5] Oracle.com. (2017). Oracle APEX (Aplication Express in Oracle DB) [online] Disponible en: http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html [6] Oracle.com. (2017). Oracle PL/SQL. [online] Disponible en: http://www.oracle.com/technetwork/issue-archive/2011/11-mar/o21plsql-242570.html [7] Oracle.com. (2015). Oracle PL/SQL. [online] Disponible en: http://www.oracle.com/technetwork/database/features/plsql/index.html