sábado, 23 de abril de 2016

Entrada Final

Análisis de Resultados

Como entrada final de la bitácora, se procede a realizar un recuento de todo el trabajo realizado, donde se involucrarán datos como la cantidad de horas que requirió para elaborarla, las secciones que funcionan y las que no.

Comenzando con una pequeña reseña de lo que se ha realizado desde que se inició el proceso de la creación de la página web, se podría mencionar que para el desarrollo de este proyecto la inicialización del trabajo no se llevó a cabo desde los primeros días que fue asignada la tarea, esto debido a que se indagaron diversas fuentes de información con tal de poder aprender y por supuesto implementar una conexión entre el manejador de base de datos y visual studio.

Luego de dicha investigación, se procedió con la creación de las tablas y sus relaciones, donde su diseño principal fue tomado del modelo visto en clase y brindado por el profesor. No obstante es importante darse cuenta que durante el avance y desarrollo de la aplicación, algunas relaciones y atributos irían cambiando, por lo que el modelado final no  es idéntico al original, pero si se revisan con cautela todas las entradas de la bitácora, se irán mostrando estos cambios que a la postre son mínimos. ejemplo de estos son los mostrados en la sección Ultimas Modificaciones


Posterior a la creación de la base de datos, llamada GOPATO, se procede con la creación y conexión de la BD hacia la aplicación en capa lógico. Cabe mencionar que no fue una tarea muy ardua aunque de cierta manera suene arrogante, pero esto realmente es debido a que se encontró material de apoyo suficiente para poder comprender el funcionamiento entre estos dos manejadores. Como nota importante, se podría mencionar que la información para guiarse con el establecimiento de la conexión, se encuentra en el siguiente link: Conexión BD - PáginaWeb, donde se puede visualizar material explicativo de dicho proceso.

Una vez llegados a este punto sólo bastaría comenzar con la creación de los SP y de los métodos en capa lógica, donde los mismos iban siendo creados a conforme se fuesen necesitando, ya que no se podía predecir con facilidad que SPs serían necesarios y cuales no, por lo tanto se optó por su creación en el momento que surgiese la necesidad tal como se menciona en los reglones previos.

Por otra parte, y dando como terminada a grandes rasgos esta reseña del proceso con el que fue creada la aplicación, sólo nos bastará mencionar aquellas partes o secciones que cumplieron a cabalidad con las especificaciones de la tarea programada, y por su puesto las que no. Para ello dividimos esta porción en dos interrogantes:

¿Que funciona?:

Basándonos en los resultados obtenidos, se podría decir que todo lo solicitado en la especificación de la tarea programada se ha cumplido con éxito, no obstante se es consiente de que siempre el sistema podrá llegar a presentar fallos, más si este no ha sido depurado al máximo. Cabe resaltar que hasta el momento no se ha detectado ninguno por lo que el sistema ha corrido perfectamente.
Entre algunas de las cosas que funcionan, se podrían mencionar las siguientes:

  • El cliente puede ingresar una solicitud de cotización al sistema.
  • El cliente puede firmar el llegado de la solicitud, consultarla (por medio de un código) y pagarla con éxito.
  • El usuario puede ingresar a su cuenta de administrador por medio de un nombre de Usuario y un Password sin ningún tipo de problema. (Este punto no se solicita pero se decide implementar con el fin de que el sistema sea más adecuado y realista), ya que un cliente no debe poder ingresar al sistema administrativo.
  • El usuario administrador puede elegir cualquier solicitud entrante y proceder a cotizarla.
  • La cotización se genera correctamente
  • Además el Usuario administrador tiene la posibilidad de Insertar, Borrar y hacer modificaciones sobre los registros de las tablas solicitadas (Usuario, Mensajero, Tarifa) en la parte de mantenimiento.
  • Se logra poner en funcionamiento la asignación del mensajero a una cotización
  • El mensajero se libera y se ocupa, es decir cuando el mismo entrega o se le asigna un envío este cambia de estado 
  • El control del tiempo estimado para las cotizaciones que están en proceso de envío, se realiza correctamente, colocando de color Rojo aquellas filas que se encuentran fuera de tiempo y en color verde las que no presenten ningún altercado.
  • Por último está de más decir, que cabe la posibilidad que no se hayan tomado en cuenta o mencionado todos los aspectos y procesos funcionales que presenta la tarea, ya sea por descuido o simplemente porque no se consideraron importantes.



¿Que no funciona?:

  • Uno de los aspectos disfuncionales que se podrían mencionar es la siguiente: las tablas en la BD deberían tener campos donde se lleve el registro de los cambios llevados a cabo por el sistema en dicha tabla, con el fin de poder deshacer alguna acción no deseada ejecutada intencionalmente o no.

  • Con el fin de recrear una simulación lo más apegada a la realidad se pretendió en algún momento crear una interfaz exclusiva para los mensajeros, ya que ellos deberían tener una comunicación directa y personal con la empresa al momento confirmar la entrega del producto al cliente. Esta interfaz no se implementó por razones de tiempo pero se compensó dejando en manos del cliente la confirmación del recibimiento del producto.


Registro de horas trabajadas:

Como punto final pero no menos importante, se pide realizar un recuento de las horas que se invirtieron en el desarrollo de la aplicación. Para ello se detallará entrada a entrada cuantas horas se invirtieron en las mismas, y por último el total de horas.

Nota

El tiempo considerado para cada entrada es calculado según el tiempo efectivo trabajado. Esto debido a que consideramos como una falacia el hecho de poner un conteo de horas donde se abarquen grandes periodos, ya que evidentemente uno tiende a procrastinar y por ende 'pierde'  tiempo en cosas ajenas y distantes al trabajo.

A continuación se presenta el reparto de horas entre las diferentes etapas de la creación de la aplicación:

***********  Nombre de la Entrada  ******************  Horas Invertidas  ***********
  1. Investigación acerca de las relaciones entre tablas              0.5      horas
  2. Investigación para creación y diseño de pagina web            2        horas
  3. Prueba de conexión entre BD y pagina web                         2        horas
  4. Creación de la BD y sus relaciones                                      1.5     horas
  5. Creación de la Página Web con .net                                     4         horas
  6. Calcular Cotización                                                              4         horas
  7. Alteración de la Tabla Usuario, y creación del SP Login    0.5      horas
  8. Inserción de algunos Datos Predeterminados                      //no presenta esto debido a que se
                                                                                                                         contempla en la entrada 7
  9. Distinciones de interfaz entre cliente y usuario                   3         horas
  10. Implementación de los controles de Inserción                     4         horas
  11. Control de errores y Validaciones                                        2.5      horas
  12. Controles de Borrado y Modificación                                  6         horas
  13. Últimas Modificaciones                                                        //no presenta esto debido a que se 
                                                                                                                         contempla en la entrada siguiente
  14. Consultar, Firmar Conforme y Pagar una solicitud             4          horas
  15. Asignar Mensajero                                                               6          horas
********************** Total de Horas Trabajadas: |     40 horas     |  **********************



Asignar Mensajero en la Cotización Y Visualizar estado de los Envíos

Desarrollo de la sección encargada de asignar un mensajero a cotizacion, como se muestra a continuación podemos observar que tenemos dos dropdown list, en uno de ellos se despliegan las solicitudes pagadas por un cliente:




Este despliegue se logra gracias a la ejecución del Store Procedure llamado "SeleccionarCotizacionesPagadas", este busca en la tabla de cotizaciones las que se encuentren pagadas y sin asignar mensajero. A continuacion el SP "SeleccionarCotizacionesPagadas":



En el segundo Dropdown list se despliegan los choferes disponibles en la oficina previanmente seleccionada en la cotización, para efectuar la asignación del mensajero a cotización se debe seleccionar en primera instancia la cotización y posteriormente seleccionar algún
chofer que se encuentre muestre. Finalmente se presiona el boton "Asignar Mensajero", para llevar a cabo el SP encargado de dicha labor.



El despliegue de este DropDown List se ejecuta según 2 aspectos: La oficina registrada en la cotización seleccionada y la disponibilidad (estado) del mensajero de dicha oficina. Para esto se ejecuta un SP "SeleccionarMensajerosLibres" el cual realiza dicho filtro:



Se puede apreciar un botón  , este se encarga de asignar a la cotización seleccionada el mensajero también seleccionado en el segundo DropDown List, esencialmente su función es cambiar el estado de Cotización a "Asignada" y además asignar un mensajero a la cotización. Esto se logra gracias a los SPs "AsignarMensajeroEnCotizacion" y "cambiarEstadoMensajero" los cuales aluden muy bien el nombre a sus funciones:




En la parte inferior encontramos dos grillas las cuales cumplen la función de mostrarle información actualizada al Administrador y que este sepa cuando una cotización está a sobretiempo.
La imagen siguiente resalta la sección de las grillas, en la grilla superior se muestran las cotizaciones en curso, es decir, las que se encuentran pagadas y con un mensajero asignado el cual está en el proceso de entrega del producto.


En esta grilla podemos monitorear el estado de las cotizaciones en curso, además cuando una entrega está sobrepasando el tiempo estimado de entrega se activa automaticamente una alerta pintando la celda de esa solicitud roja.




El origen de los datos de la grilla anterior proviene de la ejecucion del SP "SeleccionarCotizacionesAsignadas" el cual reune la informacion relacionada a las cotizaciones que poseen un mensajero asignado:



La grilla inferior muestra las cotizaciones que ya han sido entregadas al clientes, cabe resaltar que está grilla es acumulativa, y se va llenando con el transcurso del tiempo en medida de que se efectuen las cotizaciones pagadas.



La última grilla muestra los detalles de las cotizaciones finalizadas, es decir entregadas, esto se logra ejecutando un SP el cual reune la información necesaria acerca de las cotizaciones con estado "finalizada":


Tiempo Invertido: 6 horas

viernes, 22 de abril de 2016

Consultar, Firmar Conforme, y Pagar una Cotización

El día de hoy se trabaja sobre la sección de consulta del proceso de entrega, es decir consultar acerca del estado que presenta la solicitud realizada. Para esto es necesario ingresar un respectivo identificador, que en el fondo es con el cuál se realizará la consulta y activación de los Links (botones), con los que el cliente podrá pagar y firmar el llegado o acuerdo de entrega del envío realizado.
Para ilustrar esta sección se presenta la siguiente imagen, la cuál como se puede percibir, pertenece a la ventana cliente, ya que obviamente este será el que realice la respectiva consulta.
Modificación de la Ventana
Cliente, con la respectiva sección de
consulta.
Centrándonos más en la sección del código que se implementó para el funcionamiento de esta ventana, se podrían mencionar o dividir el proceso en cuatro grandes etapas, mencionadas a continuación:
Pero previo a ello, es importante ver la siguiente imagen para poder entender como se realiza una consulta:


Ahora bien, procedemos a mostrar las 4 etapas:

  1. Despliegue del código de solicitud:    
    El cual consiste en brindarle al cliente el código de acceso con el que podrá consultar el estado que presenta su solicitud en un momento determinado..
  2. Consultar el estado de la solicitud:
    Básicamente este proceso se lleva a cabo por medio de la consulta (con el código proporcionado por el usuario) del estado de la cotización donde dependiendo del resultado o respuesta del procedimiento ejecutado se lleva a cabo una determinada acción.

    Al accionar el botón de consulta, este desencadena un evento (_Click), y a la vez el proceso de consulta el cuál está dividido en tres secciones:

    * Evento invocado (_click):
    Método invocado al realizar
    click sobre el botón de consulta.

    * Método de llamado al SP y de conexión a la BD:
    Método encargado de consultar
    el estado de una solicitud

    * SP encargado de la Consulta:

    SP utilizado para seleccionar una cotización
    con la cuál se verifica el estado de la solicitud
    del cliente.
  3. Pagar la cotización que se realizó:
    Otro de los puntos o secciones en las que se divide este avance, es el proceso de pagado de la cotización. Cabe resaltar que este se puede llevar a cabo <=> el usuario administrador a realizado la respectiva cotización sobre la solicitud.

    En la imagen que se presenta a continuación se puede percibir como llevar a cabo el pago de una cotización
    Simplemente deberá consultar el estado
    de la solicitud que desea pagar, y si la misma
    se encuentra cotizada, se le activará la opción de pagado.
    Por otro lado es importante tomar en cuenta que es lo que en sí realiza este proceso, para ello se ilustran las siguientes imágenes de las funciones que ejecuta este evento al ser invocado. No obstante para mayor claridad del lector estas secciones son:
    *  Modificación del estado de la cotización:
    *  Inserción de un nuevo registro de pago, en la tabla Pagar de la BD

    Los métodos y funciones que se ejecutan en esta sección son los siguientes

    Para la modificación del estado de la cotización:
    Función (_Click) para pagar la cotización
    Note que esta función, se encarga de ejecutar tanto la
    modificación del estado, como de registrar el pago

    Realizar el pago de solicitud
    Método que realiza la conexión a BD
    y llama al SP correspondiente

    SP utilizado para modificar el estado de
    una cotización

    Para la inserción de un Registro de Pago:
    Método de conexión a BD, para registrar
    un nuevo pago

    SP utilizado para registrar un nuevo pago
    en la tabla Pagar
  4. Firmar el acuerdo de llegada del pedido (firmar conforme):

    Finalmente se presentan las funciones de firmar el acuerdo de llegada del pedido. En la imagen que se presenta a continuación se puede percibir como llevar a cabo el Firmado de conformidad de entrega de un pedido.
    Botón utilizado para Confirmar Recibido
    Igual que en el punto #3, esta acción de firmar el llegado del pedido, se divide en diferentes partes, es decir modifica varios atributos de algunas tablas. Estas modificaciones son las siguientes:

    Modificación del estado de una Cotización:
    Como dato importante, hay que saber que esta sección utiliza el método de RealizarPagoSolicitud, ya que la misma realiza el mismo propósito(cambiar el estado de la cotización) tanto de realizar el pago, como de firmar el recibido. Y además de este método también se reutiliza el código del SP invocado, ya que como se dijo en los renglones previos, estos presentan el mismo fin.
    Método utilizado por el cliente para firmar el
    llegado del pedido

    Modificación o liberación del mensajero (cambiar su estado):
    Actualizar el estado de un Mensajero

    SP utilizado para actualizar el estado
    de un mensajero y con ello
    poder liberarlo para ser asigando a
    otro pedido nuevamente..
Con esto se da por concluido el trabajo de consulta, pagado y confirmación de llegada sobre una cotización.


Tiempo Invertido: 4 horas

Últimas modificaciones realizadas en las tablas de la BD

Esta entrada o recopilación pretende mostrar algunos de los cambios que se realizaron sobre las tablas de la BD, con el fin de que la información pudiese ser consultada de mejor manera, o simplemente porque se presentaba algún atributo o tablas que no cumplían los requerimientos.
Cabe resaltar que en esta sección no se encuentran todas las modificaciones, debido a que algunas de estas se mostraron previamente.

Modificación del tamaño del atributo Texto perteneciente a la tabla cotización

  * Esto se lleva a cabo debido a que originalmente el  varchar se creó con un tamaño de 50, no obstante este no era suficiente para almacenar la cotización y esto provocaba un error en el sistema, por lo que se modificó a un tamaño de 500 para evitar cualquier altercado.


Modificación de los atributos de tiempo en la tabla cotización

  * Se agrega un nuevo atributo FechaAsignado de tipo DateTime, esto con el fin de poder controlar las grillas en la ventana de Solicitudes pagadas, ya que como se mencionaba en la especificación de la tarea programada, estas debían mostrarse en verde o en rojo si se encontraban dentro del lapso de tiempo estimado para la entrega o no.

  * Por otro lado, se hace un renombrado del atributo fk_HoraEntrega que era de tipo entero, ya que en primera instancia HoraEntregado (nombre actualizado) no debía llevar el acrónimo fk_ y además de ello no tenía porque ser de tipo entero si el mismo representaría una fecha.


Como evidencia de los cambios ejecutados, se muestra el código utilizado para realizar las actualizaciones y cambios llevados a cabo sobre la tabla de cotización.

ALTER TABLE Cotizacion ALTER COLUMN texto char(500);

EXEC sp_rename 'Cotizacion.Fk_HoraEntrega', 'HoraEntregado';


ALTER TABLE Cotizacion ALTER COLUMN HoraEntrega Datetime;

ALTER TABLE Cotizacion ADD Fk_Mensajero int;

ALTER TABLE Cotizacion ADD FechaAsignado DateTime;


La tabla actualizada con todos estos cambios se percibe de la siguiente manera:

Tabla Cotización


Tiempo Invertido:
No considerado para esta entrada, ya que se contabiliza en la entrada Consultar-FirmarConforme-y-Pagar

jueves, 21 de abril de 2016

Implementación de los controles de Modificación y Borrado en la Ventana de Mantenimiento

El día de hoy como en el título de este apartado se menciona, se trabaja y se pone en marcha el funcionamiento total de la ventana de mantenimiento del usuario administrador, esto gracias a que se realizó la programación respectiva tanto para el botón de borrar de cada Tabla (Mensajeros, Usuarios, Tarifas)  como para el botón de modificación de las mismas tablas. Para ilustrar dichos botones se presenta la siguiente imagen:

Ventana de Mantenimiento

Azul = Modificación
Rojo = Borrado.

Cabe resaltar que esta ventana fue modificada en su diseño, con el fin de poder insertar todos los objetos necesarios para la recepción y emisión de los datos de cada tabla en los campos o elementos de la interfaz.

Continuando con el funcionamiento de cada botón se presentan los respectivos eventos (_click), es decir los dos tipos de accionar, donde cada uno de estos se desencadena en la invocación de 3 diferentes etapas (Descritas a continuación), para ejecutar por completo la acción de borrado o modificado del registro:

Accionar #1: Borrado de registros en las Tablas:
Esta sección de divide en tres diferentes métodos, entre los cuales se encuentran:


  1. Método invocado al realizar "click" sobre el botón de eliminación de cada tabla.
    Estos métodos se codificaron de la siguiente manera


    Acción _Click : Borrar Mensajero

    Acción _Click : Borrar Usuario

    Acción _Click : Borrar Tarifa
  2. Métodos de la clase administrador, donde la misma se encarga de realizar la conexión a la BD y llama al SP respectivo.
    Los tres métodos de la clase administrador encargados de invocar al SP, se perciben de la manera que acontece:

    Clase Administrador : Borrar Mensajero
    Clase Administrador : Borrar Usuario

    Clase Administrador : Borrar Tarifa
  3. Código del Store Procedure, encargado de eliminar un registro de la BD.

SP : Borrar Mensajero
SP : Borrar Usuario
SP : Borrar Tarifa


Accionar #2: Modificación de los registros en las Tablas:
Esta sección de divide en tres diferentes métodos igual que el Accionar anterior, entre los cuales se encuentran:


  1. Método invocado al realizar "click" sobre el botón de modificación de cada tabla.
    Estos métodos se codificaron de la siguiente manera
    Acción _Click : Modificar Mensajero
    Acción _Click : Modificar Usuario
    Acción _Click : Modificar Tarifa
  2. Método de la clase administrador, donde la misma se encarga de realizar la conexión a la BD y llama al SP respectivo.
    Los tres métodos de la clase administrador encargados de invocar al SP, se perciben de la manera que acontece:
    Clase Administrador : Modificar Mensajero
    Clase Administrador : Modificar Usuario
    Clase Administrador : Modificar Tarifa
  3. Código del Store Procedure, encargado de modificar un registro de la BD.

    SP : Actualizar Mensajero

    SP : Actualizar Usuario
    SP : Actualizar Tarifa
Por otra parte y para finalizar con la entrada del día de hoy, se mostrarán algunos SP que fueron utilizados para seleccionar datos de la BD, con el fin de mostrarlos al usuario administrador y poder enlazar los DropDownList con la información pertinente y actualizada. Sin más preámbulo se muestra a continuación el código implementado y una pequeña explicación de lo que estos SP realizan..


SP : Encargado de seleccionar UN SÓLO usuario
Para poder tomar sus datos y con ello poder mostrar
el User y Password del mismo, para poder ser modificados..
SP encargado de seleccionar todos
los usuarios administradores, con
el fin de poder enlazar los DropDownList
de modificación y eliminación..
SP encargado de seleccionar todos los mensajeros de
una oficina en específico, con el fin de enlazar estos datos
con los DropDownList de Borrado y modificado de los
mensajeros..
Tiempo Invertido: 6 horas

sábado, 16 de abril de 2016

Control de Errores (Validaciones)

En esta etapa de la programación se implementan algunas validaciones en las diferentes facetas (usuario y administrador) de la tarea programada. Tal como se muestra en las siguientes imágenes de algunos mensajes de control de errores:

Validación de Campos Nulos (vacíos)
Validación del proceso de visualización
de la cotización
Validación de los tipos de datos proporcionados por el usuario

Validación de los tipos de datos en la ventana usuario

Cabe resaltar que en esta última también se valida que el dato proporcionado en el campo  "Email" sea del tipo de formato email, es decir "example@extention", donde lo que importa más es el símbolo @.

Por otra parte se implementa la variable de control (denominada "respuesta") en los SP, con el fin de controlar el flujo de la transacción, es decir que por medio de esta se pueda dar a conocer si la transacción o corrimiento del SP se llevó a cabo de manera correcta. Sin más preámbulo a continuación se muestran los store procedures modificados (validados) que se mostraron en la entrada CalcularCotización, y algunos desarrollados posteriormente para la selección e inserción de registros en las diferentes tablas de la BD:

SP encargado de Insertar Solicitud del cliente
SP encargado de Seleccionar una Tarifa con
respecto a un ID en específico
SP encargado de Seleccionar una Solicitud con
respecto a un ID en específico

SP encargado de Seleccionar Todas las Solicitudes
que se encuentren en el sistema


SP encargado de Seleccionar Todos los tipos de Transportes
que se encuentren en el sistema


SP encargado de Seleccionar Todas las Oficinas
que se encuentren en el sistema


Note que para esta validación o uso de la variable respuesta, se implementó la declaración de una transacción de BD, con el fin de poder realizar un mejor control del flujo de corrimiento en el SP y con ello poder hacer commit (para "terminar" con éxito la transacción) o Rollback (para "devolver" todos los procedimientos llevados a cabo) con el fin de dejar todo como si nada hubiese sucedido. Además de ello se implementó el manejo de excepciones por medio de las condiciones try and catch dentro del SP, esto por si el código se encuentra "pulgoso".


Tiempo Invertido: 2 horas y 30 minutos