Anteproyecto Residencias
-
Upload
carlos-pimentel -
Category
Documents
-
view
251 -
download
2
description
Transcript of Anteproyecto Residencias
OPCIÓN X
MEMORIA DE RESIDENCIA PROFESIONAL
CD. GUZMAN JALISCO, MEXICO, FEBRERO 2014
INSTITUTO TECNOLÓGICO DE CD.GUZMAN
INSTITUTO TECNOLÓGICO DE CD. GUZMAN
TEMA:
“DON EQUIPAL”
QUE PARA OBTENER EL TITULO DE:
LICENCIADA EN INFORMATICA
PRESENTA:
MARIA FERNANDA BARAJAS TORRES
ASESORES:
LIC. ADA MABEL VAZQUEZ PAZ
LIC. JOEL OCHOA VAZQUEZ
ÍNDICE Introducción ..................................................................................................................1
Justificación ..................................................................................................................2
Objetivo general y específicos ......................................................................................3
Caracterización del área que participo .........................................................................4
Problemas a resolver priorizándolo ..............................................................................6
Alcenses y limitaciones ................................................................................................7
Fundamento teórico .....................................................................................................8
Fundamentos de sistemas ........................................................................................8
Modelos clásico .....................................................................................................8
Modelos cascada .................................................................................................10
Modelos incremental ............................................................................................13
Modelos espiral ....................................................................................................15
Diagrama Warnier/Orr .........................................................................................18
Elementos básicos ...............................................................................................18
Uso de diagramas de Warnierr/Orr ......................................................................19
Diagrama de contexto ..........................................................................................21
Elementos del diagrama de contexto ...................................................................22
Diagrama de flujo de datos ..................................................................................22
Fundamentos de lenguaje unificado (UML).............................................................25
Diagrama de casos de uso ..................................................................................27
Relaciones de casos de uso ................................................................................28
extensión .............................................................................................................29
generalización .....................................................................................................29
Diagrama de estados ...........................................................................................31
Diagrama de colaboración ..................................................................................34
Diagrama de clases .............................................................................................38
Fundamentos de bases de datos ............................................................................40
Tipos de bases de datos ......................................................................................40
Bases de datos estáticas .....................................................................................41
Bases de datos dinámicas ...................................................................................41
Bases de datos bibliográficas ..............................................................................42
Modelo Entidad-Relación .....................................................................................42
Entidades .............................................................................................................42
Atributos...............................................................................................................43
Claves ..................................................................................................................43
Relaciones ...........................................................................................................45
Correspondencia de cardinalidades ....................................................................45
Restricciones de partición ....................................................................................46
Modelo relacional .................................................................................................46
Normalización ......................................................................................................47
Grados de normalización .....................................................................................48
Primera forma normal ..........................................................................................49
Segunda forma normal ........................................................................................49
Tercera forma normal ..........................................................................................50
Fundamentos de SQL .............................................................................................51
Características generales de SQL ......................................................................51
Tipos de datos .....................................................................................................52
Optimización ........................................................................................................56
Lenguaje de definición de datos ..........................................................................57
Fundamentos de visual basic ..................................................................................60
Formularios Windows form ..................................................................................60
Biblioteca de clases .............................................................................................61
Controles comunes visual basic 2010 .................................................................62
Propiedades de objetos .......................................................................................63
Objetos y clases ..................................................................................................67
Caracteres en visual basic .NET ..........................................................................69
Identificadores .....................................................................................................70
Tipos ....................................................................................................................72
Palabras reservadas ............................................................................................72
Declaración de variables ......................................................................................74
Operadores de relación .......................................................................................77
Sentencias visual .................................................................................................79
Case ....................................................................................................................80
Sentencia For ......................................................................................................81
Sentencias Do .....................................................................................................82
ADO.NET .............................................................................................................82
Data set ...............................................................................................................83
ADO.NET Y visual studio.NET .............................................................................85
ADO.NET Entity framework .................................................................................85
Report viewer .......................................................................................................86
Procedimiento y descripción de las actividades realizadas ........................................88
Análisis ...................................................................................................................88
Políticas ...............................................................................................................88
Entradas ..............................................................................................................88
Salidas .................................................................................................................89
Procesos ..............................................................................................................89
Almacenes ..........................................................................................................90
Entidades externas ..............................................................................................90
Diagrama de Warnier/Orr.....................................................................................91
Diagrama de contexto ..........................................................................................93
Diagrama de casos de uso general .....................................................................94
Tabla de funciones ..............................................................................................95
Diagrama de movimientos ...................................................................................96
Diseño ................................................................................................................... 104
Diccionario de datos .......................................................................................... 104
Normalización .................................................................................................... 116
Diagrama de clases ........................................................................................... 126
Pantallas del sistema ......................................................................................... 127
Codificación ........................................................................................................... 129
Diagrama de módulos ........................................................................................ 129
Diccionario de módulos del sistema .................................................................. 130
Diagrama de clases ........................................................................................... 134
Pruebas y depuración ........................................................................................... 134
Implantación .......................................................................................................... 153
Planeación de la implantación ........................................................................... 153
Implantación del sistema ................................................................................... 153
Capacitación ...................................................................................................... 153
Captura de datos ............................................................................................... 154
Ajustes y correcciones ....................................................................................... 154
Liberación .......................................................................................................... 154
Cronograma de actividades ............................................................................... 154
Resultados y gráficos ............................................................................................... 155
Conclusión ............................................................................................................... 161
Referencias bibliográficas ........................................................................................ 162
Anexos ..................................................................................................................... 164
ÍNDICE DE TABLAS
Tabla elementos de diagrama de Warnier/Orr ........................................................20
Tabla identificador para la declaración de variables ...............................................69
Tabla tipos de datos comunes ................................................................................71
Tabla palabras reservadas ......................................................................................72
Tabla operadores aritméticos ..................................................................................76
Tabla operadores de relación ..................................................................................77
Tabla operadores lógicos ........................................................................................78
Tabla de funciones (8).............................................................................................95
Tabla diccionario de datos (9) ............................................................................... 130
1
INTRODUCCIÓN
En el presente informe encontrará una introducción y la justificación de éste
trabajo de residencias profesionales, objetivo general y específicos, problemas a
resolver, alcances y limitaciones, fundamentos de sistemas de información, de UML y
de Visual Basic. de igual forma contiene el análisis y diseño de los diagramas de
estado, colaboración, caso de uso expandido, contexto y Warnier/Orr.
Actualmente la tecnología forma parte importante de la vida cotidiana de todas
las personas y las organizaciones. A diario, se vive en un mundo rodeado de ella, en
la casa, en la escuela y la sociedad. Es por ello que existe la necesidad de
mantenerse actualizado y aprovechar todos los beneficios que las nuevas tendencias
tecnológicas nos ofrecen.
El objetivo de este proyecto es el desarrollo e implantación de un sistema
integral para el control de ventas e inventario.
Este sistema ha sido desarrollado para cubrir las necesidades básicas del
establecimiento Burritos “Los Equipales”, haciendo uso de la tecnología existente
para el desarrollo del negocio. El sistema “Don Equipal” está diseñado para ofrecer
un mejor servicio a sus usuarios proporcionándoles una forma diferente de
información y atención de sus necesidades.
En la actualidad la gestión de la comanda de los clientes y el control de
inventario se realiza manualmente desde hace muchos años. Esta situación, ha
permitido llegar a la conclusión de que existe un amplio margen de mejora en todos
los procesos diarios que se realizan en el establecimiento Burritos “Los Equipales”.
Este sistema propone una revolución en la gestión de los diferentes elementos
principales del establecimiento, haciendo uso de la tecnología en servicios de sus
usuarios.
El sistema de información está programado en el lenguaje de Visual Basic
2010 con una base de datos en SQL Server 2008 y con sistema operativo Windows.
2
JUSTIFICACIÓN
Actualmente en el establecimiento Burritos “Los Equipales” se cuenta con un
sistema manual para lleva el control de comandas e inventarios.
Uno de los problemas a resolver es el manejo de las comandas puesto que
cada vez que el cliente vuelve a ordenar un pedido se realiza una comanda nueva
pero no se lleva un control adecuado ocasionando que el pedido se pierde o no se
sabe a qué cliente pertenece y esto genera servicio lento y deficiente. Otro problema
se encuentra en el manejo de inventario debido al despilfarro de materia prima y
bebida causando la pérdida de ganancias.
Estos son factores que limitan por completo el desarrollo del negocio de no
solucionar estos problemas el negocio experimentaría perdida de dinero, clientes
inconformes y ventas escasas.
3
OBJETIVO GENERAL
Desarrollar un sistema de información monousuario para una computadora de
escritorio que permita llevar el control de ventas e inventario, para el establecimiento
de comida rápida, Burritos “Los Equipales”.
OBJETIVOS ESPECÍFICOS
Registro de Clientes.
Registro de Empleados.
Registro de Materia Prima.
Registro de Bebidas.
Registro de Ventas.
Registro de Compras.
Registro de Comanda (Local -Teléfono).
Llevar un control de Entradas y Salidas en materia prima.
Llevar un control de Entradas y Salidas en bebidas.
Impresión de Notas de Consumo.
Reporte de Ventas por día.
Relación de Comandas por empleado.
Relación de Gastos por periodo.
Reporte de Ventas por Periodo.
Reporte de Compras por Periodo.
4
CARACTERIZACIÓN DEL ÁREA EN QUE PARTICIPÓ
Organigrama de la empresa.
En la Figura 1. Se muestra el organigrama de la empresa.
Figura 1. Organigrama del establecimiento.
Domicilio del establecimiento: Mariano Escobedo #235, colonia centro.
Gerente Juan Carlos Castillo
Zuñiga
Empleado 1 Empleado 2 Empleado 3
5
Funciones del gerente del establecimiento
1. Definir y ejecutar el trabajo requerido.
2. Actualizar los datos entrantes de empleados y clientes junto con su
información dentro de los registros.
3. Levantar la comanda pedida por los clientes.
4. Registra notas de consumo.
5. Actualizar la información entrante en las bebidas y materia prima.
6. Desarrollar los paquetes promocionales del establecimiento.
7. Apoya en el desarrollo de las actividades del negocio.
8. Gestionar las cuentas del establecimiento.
9. Facilita la incorporación e integración de las personas dentro del negocio.
10. Realización del pago de los empleados.
6
PROBLEMAS A RESOLVER PRIORIZÁNDOLOS
Registro de comandas.
Se modificó el procedimiento de registro de la comanda, ya que en el negocio
se duplicaban comandas para él mismo cliente cuando después de realizar un
pedido inicial quería agregar algo más ocasionando un mal control en las comandas,
perdida de información, así como también errores al momento de cobrar.
Registro de inventario.
Problemas debido a que el dueño quiere llevar un inventario de toda su
materia prima que se usa para cocinar los burritos ya que parte del material son
alimentos perecederos, pero después de llegar a un acuerdo y con la experiencia al
cocinar ciertos alimentos, se llegó a un arreglo, pero será imposible registrar en el
inventario toda la materia prima.
Control de pérdidas y ganancias.
Por el motivo anterior y para saber el total de las ganancias se generarán
reportes con la información relevante y más importante de lo que se vende día a día.
7
ALCANCES Y LIMITACIONES
Alcances.
Este sistema realiza las comandas de los clientes del establecimiento Burritos
“Los Equipales”, así como también lleva el control convenientemente de parte de la
materia prima y de las bebidas, gestionando un buen inventario. Cuenta con un
registro de los clientes que realizan pedidos a domicilio o de los clientes que
prefieren hacer consumo en el establecimiento.
Genera notas de consumo para de esta manera evitar errores ocasionados en
el momento del cobro. El sistema ofrece una opción de reportes para que el gerente
pueda consultar los clientes, compras, ventas, ganancias, etc. día a día de la
información obtenida de su negocio, así como también una opción de ayuda de cómo
utilizar el sistema y otra más de respaldo de información.
Limitaciones.
Es un sistema exclusivamente para el negocio Burritos “Los Equipales”.
Los reportes no pueden ser modificados.
Es un sistema monousuario.
8
FUNDAMENTO TEÓRICO
FUNDAMENTOS DE SISTEMAS
Modelo clásico.
El ciclo de vida del desarrollo de sistemas es el conjunto de actividades que
los analistas, diseñadores y usuarios, necesitan llevar a cabo para desarrollar y
poner en marcha un sistema de información. El ciclo de vida del desarrollo de un
sistema consiste en las siguientes actividades:
El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de
información puede originarse por varias razones: sin importar cuales sean estas, el
proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto
fundamental del análisis de sistemas es comprender todas las facetas importantes
por parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con
los empleados y administradores, deben estudiar todos o cada uno de los procesos
de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema?
9
¿Qué tan serio es?
¿Cuál es la causa que lo origina?
3). Diseño del sistema: El diseño de un sistema de información produce los
detalles que establecen la forma en la que el sistema cumplirá con los requerimientos
identificados durante la fase de análisis. Los especialistas en sistemas se refieren,
con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo
del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden
instalar software comprobando a terceros o escribir programas diseñados a la
medida del solicitante. La elección depende del costo de cada alternativa, del tiempo
disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones
pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea
de manera experimental para asegurarse de que el software no tenga fallas, es decir,
que funciona de acuerdo con las especificaciones y en la forma en que los usuarios
esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y
después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e
instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos
los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones
se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios
cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las
semanas y los meses.
Por consiguiente, es indudable que debe darse mantenimiento a las
aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos
10
débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes
dimensiones:
Evaluación operacional: Valoración de la forma en que funciona el sistema,
incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los
formatos de información, confiabilidad global y nivel de utilización.
Impacto organizacional: Identificación y medición de los beneficios para la
organización en áreas tales como finanzas, eficiencia operacional e impacto
competitivo. También se incluye el impacto sobre el flujo de información
externo e interno.
Opinión de loa administradores: Evaluación de las actividades de directivos
y administradores dentro de la organización así como de los usuarios finales.
Desempeño del desarrollo: La evaluación de proceso de desarrollo de
acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan
con presupuestos y estándares, y otros criterios de administración de
proyectos. También se incluye la valoración de los métodos y herramientas
utilizados en el desarrollo.
Modelo cascada.
Este, aunque es más comúnmente conocido como modelo en cascada es
también llamado «modelo clásico», «modelo tradicional» o «modelo lineal
secuencial».
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría
un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o
rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a
escasos y pequeños sistemas a desarrollar.
11
En estas circunstancias, el paso de una etapa a otra de las mencionadas sería
sin retorno, por ejemplo: pasar del diseño a la codificación implicaría un diseño
exacto y sin errores ni probable modificación o evolución: «codifique lo diseñado sin
errores, no habrá en absoluto variantes futuras». Esto es utópico; ya que
intrínsecamente el software es de carácter evolutivo, cambiante y difícilmente libre
de errores, tanto durante su desarrollo como durante su vida operativa.
Algún cambio durante la ejecución de una cualquiera de las etapas en este
modelo secuencial implicaría reiniciar desde el principio todo el ciclo completo, lo
cual redundaría en altos costos de tiempo y desarrollo.
Sin embargo, el modelo cascada en algunas de sus variantes es uno de los
actualmente más utilizados, por su eficacia y simplicidad, más que nada en software
de pequeño y algunos de mediano porte; pero nunca (o muy rara vez) se le usa en
su "forma pura", como se dijo anteriormente. En lugar de ello, siempre se produce
alguna realimentación entre etapas, que no es completamente predecible ni rígida;
esto da oportunidad al desarrollo de productos software en los cuales hay ciertas
incertezas, cambios o evoluciones durante el ciclo de vida. Así por ejemplo, una vez
capturados y especificados los requisitos (primera etapa) se puede pasar al diseño
del sistema, pero durante esta última fase lo más probable es que se deban realizar
ajustes en los requisitos (aunque sean mínimos), ya sea por fallas detectadas,
ambigüedades o bien por qué los propios requisitos han cambiado o evolucionado;
con lo cual se debe retornar a la primera o previa etapa, hacer los reajuste
pertinentes y luego continuar nuevamente con el diseño; esto último se conoce como
realimentación. Lo normal en el modelo cascada será entonces la aplicación del
mismo con sus etapas realimentadas de alguna forma, permitiendo retroceder de una
a la anterior (e incluso poder saltar a varias anteriores) si es requerido.
Lo dicho es, a grandes rasgos, la forma y utilización de este modelo, uno de
los más usados y populares. El modelo cascada realimentado resulta muy atractivo,
hasta ideal, si el proyecto presenta alta rigidez (pocos cambios, previsto no
evolutivo), los requisitos son muy claros y están correctamente especificados.
12
Hay más variantes similares al modelo: refino de etapas (más etapas,
menores y más específicas) o incluso mostrar menos etapas de las indicadas,
aunque en tal caso la faltante estará dentro de alguna otra. El orden de esas fases
indicadas en el ítem previo es el lógico y adecuado, pero adviértase, como se dijo,
que normalmente habrá realimentación hacia atrás.
El modelo lineal o en cascada es el paradigma más antiguo y extensamente
utilizado, sin embargo las críticas a él (ver desventajas) han puesto en duda su
eficacia. Pese a todo, tiene un lugar muy importante en la Ingeniería de software y
continúa siendo el más utilizado; y siempre es mejor que un enfoque al azar.
Desventajas del modelo cascada:
Los cambios introducidos durante el desarrollo pueden confundir
al equipo profesional en las etapas tempranas del proyecto. Si los
cambios se producen en etapa madura (codificación o prueba) pueden
ser catastróficos para un proyecto grande.
No es frecuente que el cliente o usuario final de información
abundante clara y completamente los requisitos (etapa de inicio); y el
modelo lineal lo requiere. La incertidumbre natural en los comienzos es
luego difícil de acomodar.
El cliente debe tener paciencia ya que el software no estará
disponible hasta muy avanzado el proyecto. Un error detectado por el
cliente (en fase de operación) puede ser desastroso, implicando reinicio
del proyecto, con altos costos.
13
Modelo incremental.
La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de
programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo
que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones
entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del
sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son
comenzar con una implementación simple de los requerimientos del sistema, e
iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema
completo esté implementado. En cada iteración, se realizan cambios en el diseño y
se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en sí mismo consiste de:
Etapa de inicialización
Etapa de iteración
Lista de control de proyecto
Etapa de inicialización.
Se crea una versión del sistema. La meta de esta etapa es crear un producto
con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe
ofrecer una muestra de los aspectos claves del problema y proveer una solución lo
suficientemente simple para ser comprendida e implementada fácilmente. Para guiar
el proceso de iteración se crea una lista de control de proyecto, que contiene un
historial de todas las tareas que necesitan ser realizadas. Incluye cosas como
nuevas funcionalidades para ser implementadas, y áreas de rediseño de la solución
ya existente. Esta lista de control se revisa periódica y constantemente como
resultado de la fase de análisis.
14
Etapa de iteración.
Esta etapa involucra el rediseño e implementación de una tarea de la lista de
control de proyecto, y el análisis de la versión más reciente del sistema. La meta del
diseño e implementación de cualquier iteración es ser simple, directa y modular, para
poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control
de proyecto. El código puede, en ciertos casos, representar la mayor fuente de
documentación del sistema. El análisis de una iteración se basa en la
retroalimentación del usuario y en el análisis de las funcionalidades disponibles del
programa. Involucra el análisis de la estructura, modularidad, usabilidad,
confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del
proyecto se modifica bajo la luz de los resultados del análisis.
Las guías primarias que guían la implementación y el análisis incluyen:
Cualquier dificultad en el diseño, codificación y prueba de una
modificación debería apuntar a la necesidad de rediseñar o recodificar.
Las modificaciones deben ajustarse fácilmente a los módulos fáciles de
encontrar y a los aislados. Si no es así, entonces se requiere algún
grado de rediseño.
Las modificaciones a las tablas deben ser especialmente fáciles de
realizar. Si dicha modificación no ocurre rápidamente, se debe aplicar
algo de rediseño.
Las modificaciones deben ser más fáciles de hacer conforme avanzan
las iteraciones. Si no es así, hay un problema primordial usualmente
encontrado en un diseño débil o en la proliferación excesiva de parches
al sistema.
15
Los parches normalmente deben permanecer solo por una o dos
iteraciones. Se hacen necesarios para evitar el rediseño durante una
fase de implementación.
La implementación existente debe ser analizada frecuentemente para
determinar qué tal se ajusta a las metas del proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez
para ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar
deficiencias en la implementación referida por él.
Modelo espiral.
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemáticos del Modelo Cascada. Proporciona potencial para
desarrollo rápido de versiones incrementales. En el modelo Espiral el software se
construye en una serie de versiones incrementales. En las primeras iteraciones la
versión incremental podría ser un modelo en papel o bien un prototipo.
En las últimas iteraciones se producen versiones cada vez más completas del
sistema diseñado.
El modelo se divide en un número de Actividades de marco de trabajo,
llamadas «regiones de tareas». En general existen entre tres y seis regiones de
tareas (hay variantes del modelo).
16
En este caso se explica una variante del modelo original de Boehm, expuesto
en su tratado de 1988; en 1998 expuso un tratado más reciente.
Las regiones definidas en el modelo de la figura son:
Región 1 - Tareas requeridas para establecer la comunicación entre el
cliente y el desarrollador.
Región 2 - Tareas inherentes a la definición de los recursos, tiempo y
otra información relacionada con el proyecto.
Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de
gestión del proyecto.
Región 4 - Tareas para construir una o más representaciones de la
aplicación software.
Región 5 - Tareas para construir la aplicación, instalarla, probarla y
proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
Región 6 - Tareas para obtener la reacción del cliente, según la
evaluación de lo creado e instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se
aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las
regiones que definen esas actividades comprenden un «conjunto de tareas» del
trabajo: ese conjunto sí se debe adaptar a las características del proyecto en
particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de
tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en sì.
Proyectos pequeños requieren baja cantidad de tareas y también de
formalidad. En proyectos mayores o críticos cada región de tareas contiene labores
de más alto nivel de formalidad. En cualquier caso se aplican actividades de
protección (por ejemplo, gestión de configuración del software, garantía de calidad,
etc.).
17
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor
del espiral (metafóricamente hablando) comenzando por el centro y en el sentido
indicado; el primer circuito de la espiral puede producir el desarrollo de una
especificación del producto; los pasos siguientes podrían generar un prototipo y
progresivamente versiones más sofisticadas del software.
Cada paso por la región de planificación provoca ajustes en el plan del
proyecto; el coste y planificación se realimentan en función de la evaluación del
cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para
completar el desarrollo.
El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo
de vida del software (en el modelo clásico, o cascada, el proceso termina a la
entrega del software).
Cuando la espiral se caracteriza de esta forma, está operativa hasta que el
software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se
produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado
(por ejemplo, en «mejora del producto»).
El modelo espiral da un enfoque realista, que evoluciona igual que el software;
se adapta muy bien para desarrollos a gran escala.
Este modelo requiere considerar riesgos técnicos en todas las etapas del
proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero
problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo
de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos
(Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea
necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión.
18
Desventajas importantes:
Requiere mucha experiencia y habilidad para la evaluación de los
riesgos, lo cual es requisito para el éxito del proyecto.
Es difícil convencer a los grandes clientes que se podrá controlar este
enfoque evolutivo.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por
lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y
difícil de implementar y controlar.
Diagrama de Warnier/Orr.
Los diagramas de Warnier/Orr (también conocidos como construcción lógica
de programas/construcción lógica de sistemas), fueron desarrollados inicialmente en
Francia por Jean Dominique Warnier y en los Estados Unidos por Kenneth Orr. Este
método ayuda al diseño de estructuras de programas identificando la salida y
resultado del procedimiento, y entonces trabaja hacia atrás para determinar los
pasos y combinaciones de entrada necesarios para producirlos. Los sencillos
métodos gráficos usados en los diagramas de Warnier/Orr hacen evidentes los
niveles en un sistema y más claros los movimientos de los datos en dichos niveles.
Elementos básicos.
Los diagramas de Warnier/Orr muestran los procesos y la secuencia en que
se realizan. Cada proceso se define de una manera jerárquica; es decir, consta de
conjuntos de subprocesos que lo definen, en cada nivel, el proceso se muestra en
una llave que agrupa a sus componentes.
19
Puesto que un proceso puede tener muchos subprocesos distintos, un
diagrama de Warnier/Orr, usa un conjunto de llaves para mostrar cada nivel del
sistema.
Uso de diagramas de Warnier/Orr.
La capacidad de mostrar la relación entre procesos y pasos de un proceso no
es exclusiva de los diagramas de Warnier/Orr, así como tampoco lo es el uso de la
iteración, selección de alternativas o el tratamiento de casos individuales.
Tanto los diagramas de flujo estructurado y los métodos del español
estructurado logran eso también. Sin embargo, el enfoque que se usa para
desarrollar las definiciones de un sistema por medio de estos diagramas es distinto y
se adaptan bien a los que se usan en el diseño de sistemas lógicos.
Para desarrollar un diagrama de Warnier/Orr, el analista trabaja hacia atrás,
empezando con la salida del sistema y usando un análisis orientado hacia la salida.
En el papel el desarrollo se mueve de izquierda a derecha. En primer lugar, se
definen la salida o resultados esperados del procedimiento. En el nivel siguiente,
mostrado mediante la inclusión por medio de una llave, se definen los pasos
necesarios para producir la salida. A su vez, cada paso se define un poco más. Las
llaves adicionales agrupan los procesos requeridos para producir el resultado en el
siguiente nivel.
20
La simbología del diagrama Warnier/Orr se muestra en la Tabla 1.
Tabla 1. Elementos del diagrama Warnier/Orr.
Los diagramas de Warnier/Orr ofrecen a los expertos en sistemas algunas
ventajas distintivas. Son simples en apariencia y fáciles de entender. Aun así, son
poderosas herramientas de diseño. Tienen la ventaja de mostrar agrupaciones de
procesos y los datos que deben transferirse de nivel a nivel. Además, la secuencia
del trabajo hacia atrás garantiza que el sistema estará orientado hacia el resultado.
Simbología Significado
Se Utiliza Para conjuntos
y Subconjuntos
(N)
Ejecutar el conjunto N
veces
(0,1)
Una condición debe ser
cierta o falsa.
+
Enunciados arriba y abajo
del + son alternativas
mutuamente excluyentes.
PREFORM Utilizado para saltar a otra
parte del diagrama
21
Diagrama de contexto.
El diagrama de contexto es un caso especial del diagrama de flujo de datos,
en donde una sola burbuja representa todo el sistema.
El diagrama de contexto muestra a través de flujos de datos las interacciones
existentes entre los agentes externos y el sistema, sin describir en ningún momento
la estructura del sistema de información.
En este tipo de diagrama, el sistema de información debe representarse como
un único proceso de muy alto nivel con entradas y salidas hacia los agentes externos
que lo limitan, de forma equivalente a una caja negra.
Teniendo en cuenta que este diagrama debe de ser comprensible, no es
posible representar todos los flujos de datos del sistema en él, sino más bien debe
representarse en él una visión general del sistema desde la perspectiva de los
propietarios de sistemas siguiendo dos lineamientos básicos:
Representar únicamente los flujos de datos que tengan algo que ver con el
objetivo principal del sistema.
Utilizar flujos de datos compuestos que representen a aquellos que sean
similares.
Dentro de éste diagrama se enfatizan varias características importantes del
sistema.
Las personas, organizaciones y sistemas con los que se comunica el sistema
son conocidos como terminadores.
Los datos que el sistema recibe del mundo exterior y que deben procesarse
de alguna forma.
Los datos producidos por el sistema y que se enviarán al exterior.
Los almacenes de datos que el sistema comparte con los terminadores.
La frontera entre el sistema y el resto del mundo.
22
Elementos del diagrama de contexto.
El diagrama de contexto consiste de terminadores, flujos de datos y flujos de
control, almacenes de datos y un solo proceso, que consiste en una sola burbuja. El
nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo
convenido.
Los terminadores se representan por medio de rectángulos y se comunican
con el sistema utilizando flujos de datos o de control, los cuales son representados
por flechas, o a través de almacenes externos.
Hay que recalcar que los terminadores no se comunican entre sí, al menos no
en el diagrama de contexto, ya que denotarían interacciones externas al sistema.
Diagrama de flujo de datos.
Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una
representación gráfica del “flujo” de datos a través de un sistema de información. Un
diagrama de flujo de datos también se puede utilizar para la visualización de
procesamiento de datos (diseño estructurado). Es una práctica común para
un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción
entre el sistema y las entidades externas. Este contexto a nivel de DFD se utiliza
para mostrar más detalles del sistema que se está modelando.
Los diagramas de flujo de datos fueron inventados por Larry Constantine, el
desarrollador original del diseño estructurado, basado en el modelo de computación
de Martin y Estrin: "flujo gráfico de datos" .
Los diagramas de flujo de datos (DFD) son una de las tres perspectivas
esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM.
El patrocinador de un proyecto y los usuarios finales tendrán que ser
informados y consultados en todas las etapas de una evolución del sistema.
23
Con un diagrama de flujo de datos, los usuarios van a poder visualizar la
forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se
pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser
elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer
diferencias y mejoras a aplicar para desarrollar un sistema más eficiente.
Los diagramas de flujo de datos pueden ser usados para proporcionar al
usuario final una idea física de cómo resultarán los datos a última instancia, y cómo
tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier
sistema es desarrollado, puede determinarse a través de un diagrama de flujo de
datos, modelo de datos. Los símbolos del diagrama de flujo de datos se observan en
la Figura 2.
Figura 2. Símbolos utilizados en el diagrama de flujo de datos.
Los terminadores representan por medio de rectángulos y se comunican con
el sistema utilizando flujos de datos o e control, los cuales son representados por
flechas, o a través de almacenes externos. Hay que mencionar que los terminadores
no se comunican entre sí, al menos no en el diagrama de contexto, ya que
denotarían interacciones externas al sistema. En la Figura 3 se muestra un ejemplo
de diagrama de contexto.
24
Figura 3. Ejemplo de un diagrama de contexto.
25
FUNDAMENTOS DEL LENGUAJE UNIFICADO DE MODELDO (UML)
El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la
sucesión de una serie de métodos de análisis y diseño orientadas a objetos que
aparecen a fines de los 80's y principios de los 90s. UML es llamado un lenguaje de
modelado, no un método. Los métodos consisten de ambos de un lenguaje de
modelado y de un proceso. El UML, fusiona los conceptos de la orientación a objetos
aportados por Booch, OMT (Booch, G. et al., 1999).
UML incrementa la capacidad de lo que se puede hacer con otros métodos de
análisis y diseño orientados a objetos. Los autores de UML apuntaron también al
modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje
maneje adecuadamente estos dominios.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los
métodos para expresar un diseño. El proceso indica los pasos que se deben seguir
para llegar a un diseño.
La estandarización de un lenguaje de modelado es invaluable, ya que es la
parte principal del proceso de comunicación que requieren todos los agentes
involucrados en un proyecto informático.
Si se quiere discutir un diseño con alguien más, ambos deben conocer el
lenguaje de modelado y no así el proceso que se siguió para obtenerlo.
Una de las metas principales de UML es avanzar en el estado de la
integración institucional proporcionando herramientas de interoperabilidad para el
modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de
modelos de información entre herramientas, se requirió definir a UML una semántica
y una notación.
26
La notación es la parte gráfica que se ve en los modelos y representa la
sintaxis del lenguaje de modelado. Por ejemplo: la notación del diagrama de clases
define como se representan los elementos y conceptos como son: una clase, una
asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o
multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un
diagrama, usualmente de clases, que define la notación).
Para que un proveedor diga que cumple con UML debe cubrir con la
semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas
en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede
cumplir con la notación de UML.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para
dar soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o
proceso usar.
UML no puede compararse con la programación estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos, sin
embargo, la programación orientada a objetos viene siendo un complemento perfecto
de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
27
Diagrama de casos de uso.
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
especie de diagrama de comportamiento. UML no define estándares para que el
formato escrito describa los casos de uso, y así mucha gente no entiende que esta
notación gráfica define la naturaleza de un caso de uso; sin embargo una notación
gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de
casos de uso. Los diagramas de casos de uso son a menudo confundidos con los
casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son
mucho más detallados que los diagramas de casos de uso.
La descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios
humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es
un mecanismo de organización, un conjunto de casos de usos coherentes y
consistentes promueven una imagen fácil de comprender del comportamiento
del sistema, un entendimiento común entre el cliente/propietario/usuario y el
equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar
detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de
uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento,
temas de escalabilidad/gestión, o cumplimiento de estándares.
El sujeto se representa como un rectángulo que contiene un conjunto de
elipses que son los casos de uso. Los actores se muestran como monigotes fuera del
rectángulo, con el nombre debajo, las líneas rectas conectan los iconos de los
actores con las elipses de los casos de uso. Las relaciones entre los casos de uso se
dibujan dentro del rectángulo, como se puede apreciar en la Figura 4.
28
Figura 4. Ejemplo de un diagrama de caso de uso.
Relaciones de casos de uso.
Las tres relaciones principales entre los casos de uso son soportadas por el
estándar UML, el cual describe notación gráfica para esas relaciones. Por ejemplo:
una revisión de ellas a continuación: inclusión (include o use).
Es una forma de interacción o creación, un caso de uso dado puede "incluir"
otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de
uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes
desde múltiples casos de uso a una descripción individual, desde el caso de uso. El
estándar de lenguaje de modelado unificado de OMG define una notación gráfica
para realizar diagramas de casos de uso, pero no el formato para describir casos de
uso. Mucha gente sufre la equivocación pensando que un caso de uso es una
notación gráfica (o es su descripción).
29
Extensión (Extend).
Es otra forma de interacción, un caso de uso dado (la extensión)
puede extender a otro. Esta relación indica que el comportamiento del caso de la
extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener
extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de
uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta
con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con
la etiqueta «extend».
Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos
requisitos durante el mantenimiento del sistema y su extensión.
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los
objetos de la extensión son los ejemplos o instancias de los conceptos”. Documentan
el comportamiento de un sistema desde el punto de vista de un usuario.
Generalización.
Entonces la generalización es la actividad de identificar elementos en común
entre conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
taxonómicas entre conceptos que entonces se representan en jerarquías de clases.
Las subclases conceptuales son conformes con las superclases conceptuales en
cuanto a la intención y extensión.
En la tercera forma de relaciones entre casos de uso, existe una relación
generalización/especialización. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notación es una línea sólida terminada
en un triángulo dibujado desde el caso de uso especializado al caso de uso general.
30
Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica
puede ser útil factorizar comportamientos comunes, restricciones al caso de uso
general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos
de uso especializados.
En la Figura 5: se muestran los símbolos utilizados en el diagrama de casos
de uso.
Figura 5: Símbolos utilizados en el diagrama de casos de uso.
31
Diagrama de estados.
Los diagramas de estados son una técnica conocida para describir el
comportamiento de un sistema. Describen todos los estados posibles en los que
puede entrar un objeto particular y la manera en que cambia el estado del objeto,
como resultado de los eventos que llegan a él. En la mayor parte de las técnicas
orientadas a objetos, los diagramas de estado se dibujan para una sola clase,
mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.
Existen muchas formas de diagramas de estado, cada una con semántica
ligeramente diferente. La más popular que se emplea en las técnicas de OO se basa
en la tabla de estados de David Harel (Vol. 8). OMT fue quien la uso por primera vez
para los métodos de OO y fue adoptada por Grady Booch en su segunda edición
(1994).
El estado en el que se encuentra un objeto determina su comportamiento.
Cada objeto sigue el comportamiento descrito en el diagrama de estados asociado a
su clase. Los diagramas de estados y escenarios son complementarios, los
diagramas de estados son autómatas jerárquicos que permiten expresar
concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y
deterministas. La transición entre estados es instantánea y se debe a la ocurrencia
de un evento.
Los diagramas de estado muestran el conjunto de estados por los cuales pasa
un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y
acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de
la clase. Normalmente contienen: estados y transiciones. Como los estados y las
transiciones incluyen, a su vez, eventos, acciones y actividades. Al igual que otros
diagramas, en los diagramas de estado pueden aparecer notas explicativas y
restricciones.
32
Los símbolos utilizados para el diagrama de estados se observan en la Figura 6.
Figura 6. Símbolos para el diagrama de estados
Eventos.
Un evento es una ocurrencia que puede causar la transición de un estado a
otro de un objeto. Esta ocurrencia puede ser una:
Condición que toma el valor de verdadero (normalmente descrita como una
expresión booleana). Es un evento cambio.
Recepción de una señal explícita de un objeto a otro. Es un evento señal.
Recepción de una llamada a una operación. Es un evento llamada.
Paso de cierto período de tiempo, después de entrar al estado actual, o de
cierta hora y fecha concretas. Es un evento tiempo.
El nombre de un evento tiene alcance dentro del paquete en el cual está
definido y puede ser usado en los diagramas de estado por las clases que tienen
visibilidad dentro del paquete. Un evento no es local a la clase donde está declarado.
33
En la Figura 5.1: se muestra un ejemplo de un diagrama de estados.
Figura 5.1: Ejemplo diagrama de estados.
34
Diagrama de colaboración.
Un diagrama de colaboración en las versiones de UML 1.x es esencialmente
un diagrama que muestra interacciones organizadas alrededor de los roles. A
diferencia de los diagramas de secuencia, los diagramas de colaboración, también
llamados diagramas de comunicación, muestran explícitamente las relaciones de los
roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una
dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia
tanto la secuencia de mensajes como los hilos concurrentes.
Muestra cómo las instancias específicas de las clases trabajan juntas para
conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases mediante el paso de
mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de comunicación es también un diagrama de clases que contiene
roles de clasificador y roles de asociación en lugar de sólo clasificadores y
asociaciones. Los roles de clasificador y los de asociación describen la configuración
de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia
de la comunicación. Cuando se instancia una comunicación, los objetos están
ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de
asociación puede ser desempeñado por varios tipos de enlaces temporales, tales
como argumentos de procedimiento o variables locales del procedimiento. Los
símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.
Usos.
Un uso de un diagrama de colaboración es mostrar la implementación de una
operación. La comunicación muestra los parámetros y las variables locales de la
operación, así como asociaciones más permanentes.
35
Cuando se implementa el comportamiento, la secuencia de los mensajes
corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.
Tipos.
Es útil marcar los objetos en cuatro grupos: los que existen con la interacción
entera; los creados durante la interacción (restricción {new}); los destruidos durante
la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la
interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la implementación de una
operación, pueden también mostrar la realización de una clase entera. En este uso,
muestran el contexto necesario para implementar todas las operaciones de una
clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden
desempeñar en varias operaciones.
Mensajes.
Los mensajes se muestran como flechas etiquetadas unidas a los enlaces.
Cada mensaje tiene un número de secuencia, una lista opcional de mensajes
precedentes, una condición opcional de guarda, un nombre y una lista de
argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el
nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan
secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que
haya una dependencia secuencial explícita.
36
Flujos.
Generalmente, un diagrama de comunicación contiene un símbolo para un
objeto durante una operación completa. Sin embargo, a veces, un objeto contiene
diferentes estados que se deban hacer explícitos. Los diferentes símbolos de objeto
que representan un objeto se pueden conectar usando flujos "become" o
"conversión". Un flujo "become" es una transición, a partir de un estado de un objeto
a otro. Se dibuja como una flecha de línea discontinua con el estereotipo "become" o
"conversión" y puede ser etiquetado con un número de serie para mostrar cuando
ocurre.
Los símbolos utilizados para el diagrama de colaboración se observan en la
Figura 7.
Figura 7. Símbolos para el diagrama de colaboración.
37
En la Figura 7.1: Se muestra un ejemplo de un diagrama de colaboración.
Figura 7.1: Ejemplo diagrama de colaboración.
38
Diagrama de clases.
Un diagrama de clases es un tipo de diagrama estático que describe la
estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos.
Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que se manejará en
el sistema, y los componentes que se encargaran del funcionamiento y la relación
entre uno y otro.
Representación de requerimientos en entidades y actuaciones la arquitectura
conceptual de un dominio, soluciones de diseño en una arquitectura, componentes
de software orientados a objetos.La estructura de un diagrama de clases se muestra
a continuación, ver Figura 8.
Figura 8: Ejemplo de diagrama de clases.
39
Propiedad de objetos que tienen propiedades y/u operaciones que contienen
un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero
clases de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir
los datos con las operaciones.
El diagrama de clases incluye mucha más información como la relación entre
un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz gráfica. Las
relaciones en el diagrama de clases de muestra con línea y un rombo ver Figura 8.1.
Figura 8.1: Relaciones diagrama de clases.
Relación por composición: Relación estática, en donde el tiempo de vida del objeto
incluido está condicionado por el tiempo de vida que lo incluye, la flecha que lo
distingue se muestra a continuación, ver Figura 8.2.
Figura 8.2: Relación por Composición.
Relación por agregación: Relación dinámica, donde el tiempo de vida del objeto
incluido es independiente del que lo incluye, la flecha que lo distingue se muestra a
continuación, ver Figura 8.3.
Figura 8.3: Relación por agregación.
40
FUNDAMENTOS DE BASES DE DATOS
Una base de datos o banco de datos es un conjunto de datos pertenecientes a
un mismo contexto y almacenados sistemáticamente para su posterior uso. En este
sentido, una biblioteca puede considerarse una base de datos compuesta en su
mayoría por documentos y textos impresos en papel e indexados para su consulta.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y
la electrónica, la mayoría de las bases de datos están en formato digital (electrónico),
y por ende se ha desarrollado y se ofrece un amplio rango de soluciones al problema
del almacenamiento de datos.
Existen programas denominados: Sistema Gestor de Base de Datos”,
abreviado SGBD, que permiten almacenar y posteriormente acceder a los datos de
forma rápida y estructurada. Las propiedades de estos SGBD, así como su utilización
y administración, se estudian dentro del ámbito de la informática.
Las aplicaciones más usuales son para la gestión de empresas e instituciones
públicas. También son ampliamente utilizadas en entornos científicos con el objeto
de almacenar la información experimental.
Aunque las bases de datos pueden contener muchos tipos de datos, algunos
de ellos se encuentran protegidos por las leyes de varios países. Por ejemplo: en
España, los datos personales se encuentran protegidos por la Ley Orgánica de
Protección de Datos de Carácter Personal (LOPD).
Tipos de bases de datos.
Las bases de datos pueden clasificarse de varias maneras, de acuerdo al
contexto que se esté manejando, la utilidad de las mismas o las necesidades que
satisfagan.
41
Bases de datos estáticas.
Son bases de datos de sólo lectura, utilizadas primordialmente para almacenar
datos históricos que posteriormente se pueden utilizar para estudiar el
comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones,
tomar decisiones y realizar análisis de datos para inteligencia empresarial.
Bases de datos dinámicas.
Éstas son bases de datos donde la información almacenada se modifica con el
tiempo, permitiendo operaciones como actualización, borrado y adición de datos,
además de las operaciones fundamentales de consulta. Un ejemplo de esto puede
ser la base de datos utilizada en un sistema de información de un supermercado, una
farmacia, un videoclub o una empresa.
En la Figura 9: se ilustra un ejemplo de una SGBD.
Figura 9: Esquema SGBD.
42
Bases de datos bibliográficas.
Sólo contienen un subrogante (representante) de la fuente primaria, que
permite localizarla. Un registro típico de una base de datos bibliográfica contiene
información sobre el autor, fecha de publicación, editorial, título, edición, de una
determinada publicación, etc. Puede contener un resumen o extracto de la
publicación original, pero nunca el texto completo, porque si no, se tratara de una
base de datos a texto completo (o de fuentes primarias). Como su nombre lo indica,
el contenido son cifras o números. Por ejemplo, una colección de resultados de
análisis de laboratorio, entre otras.
Modelo Entidad-Relación.
Un diagrama o “Modelo Entidad-Relación” (a veces denominado por sus siglas
en inglés, E-R "Entityrelationship", o del español DER "Diagrama de Entidad
Relación") es una herramienta para el modelado de datos que permite representar
las entidades relevantes de un sistema de información así como sus interrelaciones y
propiedades.
Entidades.
Las entidades son el fundamento del modelo entidad relación. Podemos
adoptar como definición de entidad cualquier cosa o parte del mundo que es
distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las
cuentas bancarias se podrían interpretar como entidades. Las entidades pueden
representar entes concretos, como una persona o un avión, o abstractas, como por
ejemplo un préstamo o una reserva. Se representan por medio de un rectángulo.
43
Atributos.
Se representan mediante un círculo o elipse etiquetado mediante un nombre
en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar
dicha etiqueta.
Por motivos de legibilidad, los atributos suelen no aparecer representados en
el diagrama entidad-relación, sino descritos textualmente en otros documentos
adjuntos.
Claves.
Es un subconjunto del conjunto de atributos comunes en una colección de
entidades, que permite identificar unívocamente cada una de las entidades
pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las
relaciones de un conjunto de relaciones.
Dentro de los conjuntos de entidades existen los siguientes tipos de claves:
Superclave: Es un subconjunto de atributos que permite distinguir
unívocamente cada una de las entidades de un conjunto de entidades. Si se
añade un atributo al anterior subconjunto, el resultado seguirá siendo una
superclave.
Clave candidata: Dada una superclave, si ésta deja de serlo quitando
únicamente uno de los atributos que la componen, entonces ésta es una clave
candidata.
Clave primaria: Es una clave candidata, elegida por el diseñador de la base de
datos, para identificar unívocamente las entidades en un conjunto de
entidades.
Los valores de los atributos de una clave, no pueden ser todos iguales para
dos o más instancias.
44
Para poder distinguir unívocamente las relaciones en un conjunto de
relaciones R, se deben considerar dos casos.
R No tiene atributos asociados: En este caso, se usa como clave primaria de
R la unión de las claves primarias de todos los conjuntos de entidades
participantes.
R tiene atributos asociados: En este caso, se usa como clave primaria de R la
unión de los atributos asociados y las claves primarias de todos los conjuntos
de entidades participantes.
Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave
primaria está compuesto de relaciones binarias, con los conjuntos de entidades
participantes A y B, se consideran los siguientes casos, según sus cardinalidades:
R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A,
como clave primaria de R.
R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B,
como clave primaria de R.
R es de uno a uno de A a B entonces se toma cualquiera de las dos claves
primarias, como clave primaria de R.
R es de muchos a muchos de A a B entonces se toma la unión de los
atributos que conforman las claves primarias de A y de B, como clave primaria
de R.
Cabe destacar que para todo proceso de modelado, formalmente, los
diagramas ER son un lenguaje gráfico para describir conceptos. Informalmente, son
simples dibujos o gráficos que describen información que trata un sistema de
información y el software que lo automatiza.
45
Relaciones.
Se representan mediante un rombo etiquetado en su interior con un verbo.
Este rombo se debe unir mediante líneas con las entidades (rectángulos) que
relaciona, para así saber cuál es la relación que lleva cada uno.
Correspondencia de cardinalidades.
Dado un conjunto de relaciones en el que participan dos o más conjuntos de
entidades, la correspondencia de cardinalidad indica el número de entidades con las
que puede estar relacionada una entidad dada.
Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la
correspondencia de cardinalidades puede ser:
Uno a Uno: Una entidad de A se relaciona únicamente con una entidad en B y
viceversa (ejemplo relación vehículo - matrícula: cada vehículo tiene una única
matrícula, y cada matrícula está asociada a un único vehículo).
Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en
B. Pero una entidad en B se relaciona con una única entidad en A (ejemplo
vendedor - ventas).
Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad
en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en
A (ejemplo empleado-centro de trabajo).
Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas
entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos
ciudadanos pueden pertenecer a una misma asociación, y cada ciudadano
puede pertenecer a muchas asociaciones distintas).
46
Restricciones de participación.
Dado un conjunto de relaciones R en el cual participa un conjunto de
entidades A, dicha participaciones pueden ser de dos tipos:
Total: Cuando cada entidad en A participa en al menos una relación de R.
Parcial: Cuando al menos una entidad en A No participa en alguna relación
de R.
Modelo relacional.
El modelo relacional para la gestión de una base de datos es un modelo de
datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo
más utilizado en la actualidad para modelar problemas reales y administrar datos
dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de
los laboratorios IBM en San José (California), no tardó en consolidarse como un
nuevo paradigma en los modelos de base de datos.
Su idea fundamental es el uso de relaciones. Estas relaciones podrían
considerarse en forma lógica como conjuntos de datos llamados tuplas. Pese a que
ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd,
la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, esto
es, pensando en cada relación como si fuese una tabla que está compuesta
por registros (cada fila de la tabla sería un registro o tupla), y columnas (también
llamadas campos).
En este modelo todos los datos son almacenados en relaciones, y como cada
relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene
relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene
la considerable ventaja de que es más fácil de entender y de utilizar por un usuario
no experto.
47
La información puede ser recuperada o almacenada por medio de consultas
que ofrecen una amplia flexibilidad y poder para administrar la información.
Tabla: Tipo de modelado de datos, donde se guardan los datos recogidos por
un programa de una base de datos, formada de filas y columnas o campos,
contienen los datos que pertenecen a una misma repetición de entidad..
Registro: (fila o tupla) representa un objeto único de datos implícitamente
estructurados en una tabla.
Fila: Representa un conjunto de datos relacionados, y todas las filas de la
misma tabla tienen la misma estructura.
Normalización.
El proceso de normalización de bases de datos consiste en aplicar una serie
de reglas a las relaciones obtenidas tras el paso del modelo entidad-
relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualización de los datos en las tablas.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para
que una tabla sea considerada como una relación tiene que cumplir con algunas
restricciones:
Cada tabla debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.
48
La normalización es el proceso mediante el cual se transforman datos
complejos a un conjunto de estructuras de datos más pequeñas, que además de ser
más simples y más estables, son más fáciles de mantener. También se puede
entender la normalización como una serie de reglas que sirven para ayudar a los
diseñadores de bases de datos a desarrollar un esquema que minimice los
problemas de lógica. Cada regla está basada en la que le antecede. La
normalización se adoptó porque el viejo estilo de poner todos los datos en un solo
lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a
errores de lógica cuando se trataban de manipular los datos.
La normalización también hace las cosas fáciles de entender. Los seres
humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con
casi todo, desde los animales hasta con los automóviles. Vemos una imagen de gran
tamaño y la hacemos más simple agrupando cosas similares juntas. Las guías que la
normalización provee crean el marco de referencia para simplificar una estructura de
datos compleja.
Otra ventaja de la normalización de base de datos es el consumo de espacio.
Una base de datos normalizada ocupa menos espacio en disco que una no
normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un
mucho menor uso de espacio en disco.
El proceso de normalización tiene un nombre y una serie de reglas para cada
fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va
entendiendo el proceso, así como las razones para hacerlo de esta manera.
Grados de normalización.
Existen básicamente tres niveles de normalización: Primera Forma Normal
(1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de
estas formas tiene sus propias reglas.
49
Cuando una base de datos se conforma a un nivel, se considera normalizada
a esa forma de normalización. No siempre es una buena idea tener una base de
datos conformada en el nivel más alto de normalización, puede llevar a un nivel de
complejidad que pudiera ser evitado si estuviera en un nivel más bajo de
normalización.
A continuación se describe brevemente en qué consiste cada una de las
reglas, y posteriormente se explican con más detalle.
Primera Forma Normal (1FN).
Incluye la eliminación de todos los grupos repetidos. Resuelve el problema de
los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de
datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán
columnas que representen los mismos datos.
La normalización ayuda a clarificar la base de datos y a organizarla en partes
más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla
gigantesca y monolítica que tiene muchos diferentes aspectos, sólo tenemos que
entender los objetos pequeños y más tangibles, así como las relaciones que guardan
con otros objetos también pequeños.
Segunda Forma Normal (2FN).
Asegura que todas las columnas que no son llave sean completamente
dependientes de la llave primaria (PK).
La regla de la segunda forma normal establece que todas las dependencias
parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia
parcial es un término que describe a aquellos datos que no dependen de la llave
primaria de la tabla para identificarlos.
50
Una vez alcanzado el nivel de la segunda forma normal, se controlan la
mayoría de los problemas de lógica. Se puede insertar un registro sin un exceso de
datos en la mayoría de las tablas.
Tercera Forma Normal (3FN).
Elimina cualquier dependencia transitiva.
Una tabla está normalizada en esta forma si todas las columnas que no son
llave son funcionalmente dependientes por completo de la llave primaria y no hay
dependencias transitivas. Una dependencia transitiva es aquella en la cual existen
columnas que no son llave que dependen de otras columnas que tampoco son llave.
Cuando las tablas están en la tercera forma normal se previenen errores de
lógica cuando se insertan o borran registros. Cada columna en una tabla está
identificada de manera única por la llave primaria, y no debe haber datos repetidos.
Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.
Un dato sin normalizar no cumple con ninguna regla de normalización.
51
FUNDAMENTOS DE SQL
Características generales de SQL (SelectedQueryLanguaje).
El SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y
potencia de los sistemas relacionales y permite así gran variedad de operaciones.
Es un lenguaje declarativo de "alto nivel" o "de no procedimiento" que, gracias
a su fuerte base teórica y su orientación al manejo de conjuntos de registros y no a
registros individuales permite una alta productividad en codificación y la orientación a
objetos. De esta forma, una sola sentencia puede equivaler a uno o más programas
que se utilizarían en un lenguaje de bajo nivel orientado a registros. SQL también
tiene las siguientes características:
Lenguaje de definición de datos: El LDD de SQL proporciona comandos
para la definición de esquemas de relación, borrado de relaciones y
modificaciones de los esquemas de relación.
Lenguaje interactivo de manipulación de datos: El LMD de SQL incluye
lenguajes de consultas basado tanto en álgebra relacional como en cálculo
relacional de tuplas.
Integridad: El LDD de SQL incluye comandos para especificar las
restricciones de integridad que deben cumplir los datos almacenados en la
base de datos.
Definición de vistas: El LDD incluye comandos para definir las vistas.
Control de transacciones: SQL tiene comandos para especificar el comienzo
y el final de una transacción.
SQL incorporado y dinámico: Esto quiere decir que se pueden incorporar
instrucciones de SQL en lenguajes de programación como: C++, C, Java,
Cobol, Pascal y Fortran.
Autorización: El LDD incluye comandos para especificar los derechos de
acceso a las relaciones y a las vistas.
52
Tipos de datos.
Los tipos datos de SQL:
Categoría Descripción Tipo de Dato Descripción
Binary
Un dato Binary almacena
cadenas de bits. El dato
consiste de números
hexadecimales. Por ejemplo,
el número decimal 245 vale
en hexadecimal F5.
binary
Los datos deben tener la
misma longitud fija (hasta 8
KB)
varbinary
Los datos pueden variar en
el número de dígitos
hexadecimales (hasta 8 KB)
image
Los datos pueden ser de
longitud variable y exceder
los 8 KB.
Character
Los datos Character consisten
de cualquier combinación de
letras, símbolos, y caracteres
numéricos. Por ejemplo,
datos character
válidos:"John928"
"(0*&(%B99nh jkJ"
char
Los datos deben tener la
misma longitud fija (hasta 8
KB)
varchar
Los datos pueden variar en
el número de caracteres
(hasta 8 KB)
text
Los datos pueden ser cadena
de caracteres ASCII que
excedan los 8 KB.
Date time
Los datos Date time
consisten de combinaciones
de fechas o horas válidas. No
existe tipos de datos
separados para fechas y
datetime
Los datos fecha están
comprendidos entre en el 1
de Enero de 1753 hasta el
31 de diciembre de 9999
(requiere 8 bytes por dato).
53
Categoría Descripción Tipo de Dato Descripción
horas para almacenar solo
fechas o solo horas
smalldatetime
Los datos fecha están
comprendidos entre en el 1
de Enero de 1900 hasta el
31 de diciembre de 2079
(requiere 4 bytes por dato).
Decimal
Los datos Decimal consisten
de datos numéricos que son
almacenados al menor dígito
significativo
decimal
Los datos pueden tener un
máximo de 30 dígitos, que
pueden estar todos a la
derecha de la coma decimal.
El tipo de dato almacena un
representación exacta del
número.
numeric
En SQL Server, el tipo de
datos numeric es
equivalente al tipo de datos
decimal.
Floating
point
Datos numéricos
aproximados que consisten
de datos con una
aproximación tanto como el
sistema de numeración
binaria pueda ofrecer
float Desde –1.79E + 308 a 1.79E
+ 308.
real Desde –3.40E + 38 a 3.40E
+ 38.
Integer
Los datos Integer consisten
de números enteros positivos
y negativos tales como: –15,
0, 5, y 2.509.
bigint
Desde –2^63 (–
9223372036854775808) a
2^63–1
(9223372036854775807).
Tamaño 8 bytes.
int Desde –2.147.483.648 a
2.147.483.647 (requiere de
54
Categoría Descripción Tipo de Dato Descripción
4 bytes por valor).
smallint
Desde –32,768 a 32.767
(requiere de 2 bytes por
valor).
tinyint Desde cero a 255 (requiere
de 1 bytes por valor).
Monetary
Monetary representa montos
de dinero positivos o
negativos
money
Desde –
922.337.203.685.477,5808
a
+922.337.203.685.477,5807
Tamaño 8 bytes.
smallmoney
Desde –214.748,3648 a
214.748,3647 Tamaño 4
bytes.
Special
Special se utiliza para datos
que caben en ninguna de las
categorís anteriores.
bit
Consisten en un 1 o un 0. Se
usan para representar
valores lógicos VERDADERO
o FALSO, SI o NO
cursor
Este tipo de dato es usado
para variables o prámetros
OUTPUT en procedimientos
almacenados que contenga
una referencia a un cursor.
Cualquier variable creada
con el tipo de datos cursor
puede tomar valor nulo
timestamp Este tipo de datos es usado
55
Categoría Descripción Tipo de Dato Descripción
para indicar la secuencia de
la actividad del SQL Server
sobre una fila y es
representado por un número
incremental en formato
binario.
uniqueidentifier
Consiste de números
hexadecimales de 16 byte,
indicando un identificador
único global (GUID). Los
GUID son usados cuando
una columna deba ser única
frente a cualquier otra
columna.
SQL_variant
Este tipo de datos soporta a
cualquier otro tipo de datos
soportado por SQL Server
excepto text, ntext,
timestamp, image, y
sql_variant.
table
Es utilizado para almacenar
un conjunto de resultados
para su posterior
procesamiento. El tipo de
datos Table puede ser usado
únicamente para para definir
variable locales de tipo table
o para retornar valores de
una función definida por el
usuario.
56
Categoría Descripción Tipo de Dato Descripción
Unicode
Al usar tipo de datos Unicode,
una columna puede
almacenar cualquier cualquier
caracter definido por el
estándar Unicode. Lo cual
incluye a todos los caracteres
definidos en los distintos
conjuntos de caracteres. Los
tipos de datos Unicode toman
el doble de espacio de
almacenamiento que los tipos
no-Unicode.
nchar
Los datos deben tener la
misma longitud fija (hasta
4000 caracteres Unicode)
nvarchar
Los datos pueden variar en
el número de caracteres
(hasta 4000 caracteres
Unicode)
ntext Los datos pueden exceder
los 4000 caracteres Unicode.
Optimización.
Como ya se dijo antes, y suele ser común en los lenguajes de acceso a bases
de datos de alto nivel, el SQL es un lenguaje declarativo. O sea, que especifica qué
es lo que se quiere y no cómo conseguirlo, por lo que una sentencia no establece
explícitamente un orden de ejecución.
El orden de ejecución interno de una sentencia puede afectar gravemente a la
eficiencia del SGBD, por lo que se hace necesario que éste lleve a cabo una
optimización antes de su ejecución. Muchas veces, el uso de índices acelera una
instrucción de consulta, pero ralentiza la actualización de los datos.
Dependiendo del uso de la aplicación, se priorizará el acceso indexado o una
rápida actualización de la información. La optimización difiere sensiblemente en cada
motor de base de datos y depende de muchos factores.
57
Existe una ampliación de SQL conocida como FSQL (Fuzzy SQL, SQL difuso)
que permite el acceso a bases de datos difusas, usando la lógica difusa. Este
lenguaje ha sido implementado a nivel experimental y está evolucionando
rápidamente.
Lenguaje de definición de datos (DDL).
El lenguaje de definición de datos (en inglés Data DefinitionLanguage, o DDL),
es el que se encarga de la modificación de la estructura de los objetos de la base de
datos. Incluye órdenes para modificar, borrar o definir las tablas en las que se
almacenan los datos de la base de datos. Existen cuatro operaciones básicas:
CREATE, ALTER, DROP y TRUNCATE.
CREATE
Este comando crea un objeto dentro del gestor de base de datos. Puede ser
una base de datos, tabla, índice, procedimiento almacenado o vista.
Ejemplo (crear una tabla).
CREATE TABLE Clientes
(
IdCliente INT NOT NULL IDENTITY (1,1) PRIMARY KEY,
Nombre VARCHAR(15),
Apellido VARCHAR(25),
Dirección VARCHAR(30),
Ciudad VARCHAR(30),
Teléfono VARCHAR(15),
)
58
DROP.
Este comando elimina un objeto de la base de datos. Puede ser una
tabla, vista, índice, trigger, función, procedimiento o cualquier otro objeto que el
motor de la base de datos soporte. Se puede combinar con la sentencia ALTER.
Ejemplo:
DROPTABLEClientes.
TRUNCATE.
Este comando trunca todo el contenido de una tabla. La ventaja sobre el
comando DROP, es que si se quiere borrar todo el contenido de la tabla, es mucho
más rápido, especialmente si la tabla es muy grande.
Ejemplo:
TRUNCATETABLE Clientes;
INSERT.
Una sentencia INSERT de SQL agrega uno o más registros a una (y sólo una)
tabla en una base de datos relacional.
Ejemplo:
Insert into Clientes values ( 115,‟Alejandra‟)
59
UPDATE.
Una sentencia UPDATE de SQL es utilizada para modificar los valores de un
conjunto de registros existentes en una tabla.
Ejemplo:
Update Clientes set Direccion=‟Constitucion 39‟ WHERE IdCliente=‟4‟
DELETE.
Una sentencia DELETE de SQL borra uno o más registros existentes en una
tabla.
Ejemplo:
DELETE FROM Clientes WHERE Domicilio = „Constitucion 39‟
60
FUNDAMENTOS DE VISUAL BASIC
Fundamentos de Visual Basic .NET 2010.
Visual Basic .NET (VB .NET) es un lenguaje de programación orientado a
objetos que se puede considerar una evolución de Visual Basic implementada sobre
el framework .NET. Su introducción resultó muy controvertida, ya que debido a
cambios significativos en el lenguaje VB. NET no es compatible hacia atrás con
Visual Basic, pero el manejo de las instrucciones es similar a versiones anteriores de
Visual Basic, facilitando así el desarrollo de aplicaciones más avanzadas con
herramientas modernas.
La gran mayoría de programadores de VB .NET utilizan el entorno de
desarrollo integrado Microsoft Visual Studio en alguna de sus versiones (desde el
primer Visual Studio .NET hasta Visual Studio .NET 2012, que es la última versión de
Visual Studio para la plataforma .NET), aunque existen otras alternativas,
como SharpDevelop (que además es libre).
Al igual que con todos los lenguajes de programación basados en .NET, los
programas escritos en VB .NET requieren el Framework.NET o Mono para
ejecutarse.
Formularios Windows Forms.
Puesto que los formularios son la unidad básica de una aplicación, es
importante realizar algunas consideraciones sobre su función y su diseño. Un
formulario es, en última instancia, una hoja en blanco que el desarrollador rellena con
controles, para crear una interfaz de usuario, y con código, para procesar los datos.
Para ese fin, Visual Studio proporciona un entorno de desarrollo integrado que ayuda
a escribir el código, así como un completo conjunto de controles escrito con .NET
Framework.
61
La funcionalidad de estos controles se complementa con el código escrito por
el desarrollador, lo que permite desarrollar fácil y rápidamente las soluciones
deseadas.
En la Figura 10: Se muestra el ejemplo de un formulario.
Figura 10: Muestra la aplicación de para crear un formulario, de Windows Forms.
Bibliotecas de clases.
La biblioteca de clases de .NET Framework está constituida por espacios de
nombres. Cada espacio de nombres contiene tipos que se pueden utilizar en el
programa: clases, estructuras, enumeraciones, delegados e interfaces.
Cuando se crea un proyecto de Visual Basic .NET o Visual C# en Visual
Studio, se sigue haciendo referencia a las DLL más comunes de la clase base
(ensamblados).
62
No obstante, si se necesita utilizar un tipo incluido en una DLL a la que aún no
se hace referencia, se deberá agregar la referencia de esa DLL.
Controles comunes Visual Basic 2010.
Puntero. Se utiliza para seleccionar las variables que estamos o que
vamos a utilizar en el programa.
Button. Desencadena un evento cuando un usuario hace clic sobre él.
CheckBox. Permite al usuario seleccionar o quitar la opción asociada.
CheckedListBox. Muestra una lista de elementos con una casilla a la
izquierda de cada elemento.
ComboBox. Muestra un cuadro de texto editable con una lista desplegable
de los valores permitidos.
DataTimePicker. Permite al usuario seleccionar fecha y hora, así como
mostrar ambas en un formato especificado.
Label. Proporciona información en tiempo de ejecución o texto descriptivo
para un control.
LinkLabel. Muestra un control de etiqueta que admite funcionalidad de
hipervínculo, formato y seguimiento.
ListView. Muestra una colección de elementos en una de cinco vistas
diferentes.
MaskedTexBox. Utiliza una máscara para distinguir si los datos que
proporciona el usuario son apropiados o inapropiados.
MonthCalendar. Muestra un calendario mensual donde el usuario puede
seleccionar una fecha.
NotifyIcon. Muestra un icono en el área de notificación, a la derecha de la
barra de tareas de Windows, en tiempo de ejecución.
NumericUpDown. Muestra un único valor numérico que el usuario puede
aumentar o reducir haciendo clic en los botones de arriba y abajo del
control.
PictureBox. Muestra una imagen.
63
ProgressBar. Muestra una barra que se va completando para indicar al
usuario el progreso de una operación.
RadioButton. Permite al usuario seleccionar una única opción de entre un
grupo de opciones cuando están emparejadas con otros RadioButtons.
RichTextBox. Proporciona una entrada de texto y características de
edición avanzadas, como el formato de párrafo y de caracteres.
TextBox. Permite al usuario especificar un texto, así como funciones de
edición de varias líneas y máscaras de caracteres para contraseñas.
ToolTip. Muestra información cuando el usuario mueve el puntero sobre
un control asociado.
Propiedades de objetos.
TextBox
Text: Texto que aparecerá en el control.
Name: Nombre del control.
MultiLine: Permite introducir varias lineas de texto.
Alignment: Alineación que tendrá el texto dentro del control que puede ser
izquierdo, derecho, centrado.
Visible: Si esta propiedad esta en falso la caja de texto no sera visible cuando
este en ejecución el programa. si está en verdadero si se podrá ver.
MaxLength: Número máximo de caracteres que tendrá el control.
Looked: Con esta propiedad se puede bloquear el control para que el usuario
no pueda escribir ni modificar.
BackColor: Color que tendrá el fondo de la caja de texto.
ForeColor: Es el color de la letra que tendrá el control.
Font: Tipo y tamaño que contendrá el control.
Height, Left, Top, Width: Se refieren al tamaño del espacio reservado para
las TextBox.
64
Label.
Caption: Texto que contendrá el control.
BorderStyle: Borde alrededor del texto.
BackStyle: Borde transparente o no transparente.
BackColor: Para cambiar color del fondo.
Visible: Si está en True el control está visible si está en False está oculto.
Name: Es el nombre del control y sirve para hacer referencia al mismo en el
código, como todos los controles.
Enabled: Si está en True (Verdadero) el control está activado y se puede
utilizar normalmente, si se encuentra en False, el control está desactivado.
FontName: El nombre de la fuente que utilizará el texto del control.
ForeColor: Indica el color del Texto.
Height y Width: Ancho y alto del Label.
ToolTipText: Muestra el mensaje de descripción cuando se pasa el mouse
por encima del control.
CommandButton.
Caption: Texto para el usuario.
Enable: Inhabilita o habilita el control con el fin de que ese disponible para el
usuario.
Style: Cuando está en 1 habilita al backColor y cuando esta en 0 lo
deshabilita.
65
Picture e picture.
Name: Especifíca el nombre del control para poder referenciarlo e
identificarlo.
Appearance: Esta propiedad determina si el Image posee o no efecto 3d
con respecto a su apariencia. Los valores son: 1 - 3D y 0 - None. Para que
esta propiedad se pueda utilizar, la propiedad BorderStyle debe estar con
el valor 1.
BorderStyle: Determina si el control Image posee o no un borde. Al igual
que el anterior tiene dos posibles valores, 0 sin borde o 1 con borde.
Picture: Esta es la propiedad principal del control, que también es la
propiedad por defecto o default. Picture es la que establece la imagen o
gráfico que mostrará el control.
Stretch: Esta es una de las propiedades más importantes. Si está en True la
imagen se ajustará al tamaño que posea el control Image, si está en False el
control Image es el que se adaptará al tamaño y dimensiones de la imagen.
Las demás propiedades son las clásicas y comunes para la mayoría de los
controles, como la propiedad Index, Visible, EnabledToolTipText, Width,
Heigth, etc.
Frame.
Name: Este es el nombre como se le reconocerá al objeto durante el
programa, se acostumbra escribir frm antes del nombre para saber que es un
Frame (Ej: frmFondo).
Caption: Este es el mensaje que se quiere que aparezca en el Frame.
Height,Left,Top,Width: Se refieren al tamaño del espacio reservado para los
Frames.
Font: Permite escoger el tipo de letra, tamaño y estilo de la letras a usar.
BorderStyle: Si esta en 0 no dibuja el recuadro.
66
Listbox.
Name: Este es el nombre como se le reconocerá al objeto durante el
programa, se acostumbra escribir lst antes del nombre para saber que es un
List Box (Ej: lstLista).
List: Ingresa elementos nuevos al List Box.
Font: Permite escoger el tipo de letra, tamaño y estilo de la letras a usar.
Sorted: Si el valor es verdadero la lista aparecerá en orden alfabético.
Height,Left,Top,Width: Se refieren al tamaño del espacio reservado para los
List Box.
ScrollBar.
Name: Este es el nombre como se le reconocerá al objeto durante el
programa, se acostumbra escribir scb antes del nombre para saber que es un
Scroll Bar (Ej: scbFila).
Max: Este indica el valor máximo que puede alcanzar el Scroll al moverse.
Min: Es el valor mínimo con el cual empieza la barra de Scroll.
Height,Left,Top,Width: Se refieren al tamaño del espacio reservado para los
ScrollBar.
Shape.
Shape: Esta propiedad es la forma que tomará el control.
BorderColor: Color del borde.
BorderStyle: Estilo del borde.
BorderWidth: Ancho del borde.
FillColor: Este es el fondo, esta funciona si FillStyle en opaco.
67
En la Figura 11: Se muestran los controles comunes de Visual Basic .NET.
Figura 11: Controladores comunes de Visual.NET.
Objetos y clases.
Los objetos permiten declarar variables y procedimientos una vez y utilizarlos
siempre que sean necesarios. Por ejemplo, si se desea agregar un corrector
ortográfico a una aplicación, puede definir todas las variables y funciones auxiliares
para proporcionar funcionalidad de corrección ortográfica. Si se crea el corrector
ortográfico como una clase, se puede volver a utilizarlo en otras aplicaciones
mediante la inclusión de una referencia en el ensamblado compilado.
68
Clases.
Cada objeto de Visual Basic está definido por una clase. Una clase describe
las variables, propiedades, procedimientos y eventos de un objeto. Los objetos son
instancias de clases; pueden crearse tantos objetos como sean necesarios una vez
que se defina una clase.
Para comprender la relación entre un objeto y su clase, como los moldes de
hacer galletas y en las galletas. El molde es la clase. Define las características de
cada galleta, por ejemplo, el tamaño y la forma. La clase se utiliza para crear objetos.
Los objetos son las galletas.
Dos ejemplos en Visual Basic podrían ayudar a ilustrar la relación entre las clases
y objetos.
Los controles en el cuadro de herramientas de Visual Basic representan las
clases. Cuando se arrastra un control del Cuadro de herramientas a un
formulario, se está creando un objeto; una instancia de una clase.
El formulario con el que se trabaja en tiempo de diseño es una clase. En
tiempo de ejecución, Visual Basic crea una instancia de la clase del formulario,
es decir, un objeto.
Eventos.
A pesar de que se puede visualizar un proyecto de Visual Studio como una
serie de procedimientos que se ejecutan consecutivamente, en realidad la mayoría
de los programas están dirigidos por eventos, es decir, el flujo de ejecución está
determinado por elementos externos denominados eventos.
Un evento es una señal que comunica a una aplicación que ha sucedido algo
importante. Por ejemplo, cuando un usuario hace clic en un control de un formulario,
el formulario puede provocar un evento Click y llamar a un procedimiento que
controla el evento.
69
Los eventos también permiten que las tareas separadas se comuniquen, por
ejemplo, que una aplicación realiza una tarea de ordenación independientemente de
la aplicación principal. Si un usuario cancela la ordenación, la aplicación puede
enviar un evento de cancelación que ordene la detención del proceso de ordenación.
Caracteres en Visual Basic .NET.
Visual Basic .NET proporciona un conjunto de caracteres de tipo
identificador que se pueden utilizar en una declaración para especificar el tipo de
datos de una variable o constante. La Tabla 2. Muestra los caracteres de tipo
identificador disponibles, con ejemplos de su utilización.
Tabla 2. Identificador para la declaración de variables.
Carácter de tipo identificador Tipo de datos
% Integer
& Long
@ Decimal
! Single
# Double
$ String
70
En algunos casos, puede anexar el carácter $ a una función de Visual Basic
.NET, por ejemplo: Left$ en lugar de Left, para obtener un valor devuelto de
tipo String. En todos los casos, el carácter de tipo identificador debe ir
inmediatamente después del nombre del identificador.
Identificadores.
Los identificadores de Visual Basic .NET deben cumplir los estándares de
Unicode 3.0, Report 15 y Annex 7, con la diferencia de que los identificadores
pueden comenzar con un carácter de subrayado (conector).
Si un identificador comienza con un carácter de subrayado, debe contener al
menos un carácter identificador para eliminar la ambigüedad de la continuación de
línea.
Los identificadores normales no pueden coincidir con palabras clave, pero sí
los identificadores de escape. Un identificador de escape es un identificador
delimitado por corchetes. Los identificadores de escape siguen las mismas reglas
que los identificadores regulares con la diferencia de que pueden coincidir con las
palabras clave y no pueden tener caracteres de tipo.
La longitud máxima del identificador es de 16383 caracteres.
Tipos.
En Visual Basic .NET a toda variable que se use en un programa, se le debe
asociar (generalmente al principio del programa) un tipo de dato especifico.
Un tipo de dato define todo el posible rango de valores que una variable puede
tomar al momento de ejecución del programa y a lo largo de toda la vida útil del
propio programa.
71
Los tipos de datos más comunes en Visual Basic .Net son. Ver Tabla 3:
Tipo Rango
Byte 0-255
Integer(%) +-2,147,483,698
Single(!) 3.4E+-38(7 DECIMALES)
Double(#) 1.8E+308(16 DECIMALES)
Currency 15 DIG IZQ 4 DIG DEECHA
String($) 2 BILLONES CHARS
Boolean TRUE, FALSE
Date FECHA
Variant TODOS LOS TIPOS y más
usado en este curso
Tabla 3: Tipos de datos comunes en visual.
Recordar también que en Visual Basic .NET toda variable usada en un
programa se deberá declarar al principio del programa el formato de declaración más
sencillo es:
Ejemplos:
Dimalfa As Integer
Dimalfa As Long, beta As Long
Dimalfa As Integer, nombre As String
Dim ciudad As String * 20, alfa As Double
En Visual Basic .NET un problema común, es la necesidad de convertir
variables numéricas a strings y también el problema inverso es decir convertir strings
a su representación numérica.
72
Para este último problema por ejemplo se tiene:
Dim alfa As String Alfa=“3.1416”
Como se observa del ejemplo anterior, se puede dar en algún momento
convertir la string ALFA a su valor numérico, para resolver este problema se deberán
usar las siguientes funciones de conversión numérica que
proporciona Visual Basic.NET
Palabras reservadas.
Las palabras clave siguientes están reservadas, lo que significa que no se
pueden utilizar como nombres para los elementos de programación, como son las
variables o los procedimientos. Se puede omitir esta restricción incluyendo el nombre
entre corchetes ([ ]). Para obtener más información, vea "Nombres de escape"
en Nombres de elementos declarados. Ver Tabla 4.
Nota:No se recomienda utilizar nombres de escape porque pueden complicar la lectura
del código y llevar a errores imperceptibles difíciles de encontrar.
AddHandler AddressOf Alias And
AndAlso As Boolean ByRef
Byte ByVal Call Case
Catch CBool CByte CChar
CDate CDec CDbl Char
CInt Class CLng CObj
Const Continue CSByte CShort
CSng CStr CType CUInt
73
CULng CUShort Date Decimal
Declare Default Delegate Dim
DirectCast Do Double Each
Else ElseIf End EndIf
Enum Erase Error Event
Exit False Finally For
Friend Function Get GetType
Global GoSub GoTo Handles
If Implements Imports In
Inherits Integer Interface Is
IsNot Let Lib Like
Long Loop Me Mod
Module MustInherit MustOverride MyBase
MyClass Namespace Narrowing New
Next Not Nothing NotInheritable
NotOverridable Object Of On
Operator Option Optional Or
OrElse Overloads Overridable Overrides
ParamArray Partial Private Property
Protected Public RaiseEvent ReadOnly
ReDim REM RemoveHandler Resume
74
Tabla 4: Tabla de palabras reservadas.
Declaración de variables.
Una variable se declara para especificar su nombre y sus características. La
instrucción de declaración para variables es Instrucción Dim (Visual Basic .NET). Su
ubicación y contenido determinan las características de la variable.
Para las reglas de denominación de variables y consideraciones,
consulte Nombres de elementos declarados.
Return SByte Select Set
Shadows Shared Short Single
Static Step Stop String
Structure Sub SyncLock Then
Throw To True Try
TryCast TypeOf Variant Wend
UInteger ULong UShort Using
When While Widening With
WithEvents WriteOnly Xor #Const
#Else #ElseIf #End #If
- & &= *
*= / /= \
\= ^ ^= +
+= = -=
75
Valor local y variables miembros.
Una variable local es aquella que se declara dentro de un procedimiento.
Una variable miembro es un miembro de un tipo de Visual Basic; se declara en
el nivel de módulo, dentro de una clase, estructura o módulo, pero no dentro de
ningún procedimiento interno de esa clase, estructura o módulo.
Variables compartidas y de instancias.
La categoría de una variable miembro, en una clase o estructura, depende de
que la variable esté o no compartida. Si una variable se declara con la palabra
clave Shared, es una variable compartida, y existe en una única copia compartida por
todas las instancias de la clase o estructura.
De lo contrario, es una variable de instancia, y se crea una copia
independiente de ella para cada instancia de la clase o estructura. Una copia
determinada de una variable de instancia sólo está disponible en la instancia para la
cual se creó. Es independiente de una copia en cualquier otra instancia.
Declaración de variables:
Dim NombreDeVariable [as tipo].
Dim nCantidad As Integer.
Dim s Nombre As String.
Dim b Descontar As Booleano.
Declaración de constante:
Const dTipoCambio As Double=3.2.
DimnCantidad As Integer.
Const sNombreWeb As String=”solocodigofuente”.
76
Ámbito de las Variables: El ámbito de las variables determina su nivel de
acceso, quiere decir que una variable declarada dentro de un bloque de código, sólo
podrá ser utilizado dentro de ella, más no en otro bloque de código.
Operadores.
En Visual Basic .NET un operador es un símbolo especial que indica al
compilador que debe efectuar una operación matemática o lógica.
Visual Basic .NET reconoce los siguientes operadores aritméticos:
La siguiente Tabla muestra los operadores aritméticos, ver Tabla 5.
Operador Operacion
+ Suma
- Resta
* Multiplicacion
/ Division Flotante
\ Division Entera
^ Potencia
MOD Modulo
Tabla 5. Operadores aritméticos.
77
Operadores de relación.
A continuación se recogen los operadores de comparación definidos en Visual
Basic .NET. Ver Tabla 6.
Operador True si False si
< (Menor que) expression1 < expression2 expression1 >= expression2
<= (Menor o igual que) expression1 <= expression2 expression1 > expression2
> (Mayor que) expression1 > expression2 expression1 <= expression2
>= (Mayor o igual que) expression1 >= expression2 expression1 < expression2
= (Igual a) expression1 = expression2 expression1 <> expression2
<> (Distinto de) expression1 <> expression2 expression1 = expression2
Nota: = (Operador, Visual Basic) también se utiliza como un operador de asignación.
Tabla 6. Tabla de operadores de relación.
Operadores lógicos.
La siguiente Tabla contiene una lista con los operadores de comparación
relacionales y las condiciones que determinan si resultado es True o False.
El Not (Operado, Visual Basic .NET) realiza la negación lógica en una
expresión Boolean. Produce el contrario lógico de su operación. Si la expresión se
evalúa como True, Not devuelve False, si la expresión se evalúa como False, Not
devuelve True.
78
Esto se ilustra en el siguiente ejemplo:
Dim x, y As Boolean
x = Not 23 > 14 y = Not 23 > 67
En Visual Basic existen 6 operadores lógicos. Ver Tabla 7.
Tabla 7. Tabla de operadores lógicos.
Operadores de asignación.
A continuación se recogen los operadores de asignación definidos en Visual
Basic.
Operador =
Operador ^=
Operador *=
Operador /=
Operador Descripción
And Cuando ambas expresiones son verdaderas
Or Evalua una de dos expresiones
Not Niega una expresión
Xor La expresión completa se considera verdadera, si las 2 expresiones
evaluadas no son verdaderas o ambas son falsas
Eqv Ambas expresiones debe ser verdaderas o falsas para evaluar la
expresión completa como verdadera
Imp La expresión completa es verdadera excepto cuando la primer expresión
es verdadera y la segunda expresión es falsa
79
\= (Operador)
Operador +=
Operador -=
Operador <<=
Operador >>=
Operador &=
Operadores de concatenación.
Los operadores de concatenación combinan varias cadenas en una sola. Hay
dos operadores de concatenación: + y &. Los dos realizan la operación de
concatenación básica, como se muestra en el ejemplo siguiente.
Dim x As String = "Con" & "caten" & "ation"
Dim y As String = "Con" + "caten" + "ation"
Estos operadores también concatenan variables String, como en el ejemplo
siguiente:
Dim a As String = "abc"
Dim d As String = "def"
Dim zAs String = a & d
Dim w As String = a + d
Sentencias visual.
Las sentencias de flujo también llamadas estructuras de control o flujo
permite cambiar las secuencias de instrucciones de un programa y ejecutar varias
veces un bloque de las mismas sin necesidad de escribirlas tantas veces como se
requieran.
80
Todas las sentencias de control sirven para tomar la decisión de ejecutar o no
un bloque de instrucciones dependiendo del resultado de la evaluación, de una
condición o variable.
Sintaxis.
if condición then
instrucciones.
else
Otras instrucciones
Endif
Otra forma es:
if condición then
instrucciones
end if
Si condición entonces
Instrucciones
Fin del if
Case.
Estructura de control para ejecutar un bloque de instrucciones solo cuando el
resultado de la comparación de 2 expresiones coincida.
81
Es importante mencionar que las instrucciones asociadas al bloque case de la
expresión coincidente se ejecutaran una vez y que el control del programa pasará a
la siguiente línea de finalizar.
Sintaxis.
select case expresión
case expresión 1
case expresión 2
caseelse
endselect
selección de casos expresión
caso expresión
caso expresión
caso expresión
o si no este caso
fin del case
Sentencia For.
El for es utilizado para repetir un número determinado de veces un mismo
bloque instrucciones.
Sintaxis.
For contador= número inicial to numero final step
Codigo
Next
82
Sentencia Do.
Estructura de control que al igual que la sentencia for genera un ciclo
repetitivo, la diferencia es que para ejecutar las instrucciones se debe evaluar una
condición.
Sintaxis.
Do while<condicion>
Codigo.
loop.
ADO.NET
ADO.NET es un conjunto de componentes del software que pueden ser
usados por los programadores para acceder a datos y a servicios de datos. Es una
parte de la biblioteca de clases base que están incluidas en el
Microsoft .NET Framework. Es comúnmente usado por los programadores para
acceder y para modificar los datos almacenados en un Sistema Gestor de Bases de
Datos Relacionales, aunque también puede ser usado para acceder a datos en
fuentes no relacionales. ADO.NET es a veces considerado como una evolución de la
tecnología ActiveX Data Objects (ADO), pero fue cambiado tan extensivamente que
puede ser concebido como un producto enteramente nuevo.
83
ADO.NET consiste en dos partes primarias
Data provider.
Estas clases proporcionan el acceso a una fuente de datos, como Microsoft
SQL Server y Oracle. Cada fuente de datos tiene su propio conjunto de objetos del
proveedor, pero cada uno tiene un conjunto común de clases de utilidad:
Connection: Proporciona una conexión usada para comunicarse con la fuente
de datos. También actúa como Abstract Factory para los objetos command.
Command: Usado para realizar alguna acción en la fuente de datos, como
lectura, actualización, o borrado de datos relacionales.
Parameter: Describe un simple parámetro para un command. Un ejemplo
común es un parámetro para ser usado en un procedimiento almacenado.
DataAdapter: "Puente" utilizado para transferir data entre una fuente de datos
y un objeto DataSet (ver abajo).
DataReader: Es una clase usada para procesar eficientemente una lista
grande de resultados, un registro a la vez.
DataSet.
Los objetos DataSets, es un grupo de clases que describen una simple base
de datos relacional en memoria, fueron la estrella del show en el lanzamiento inicial
(1.0) del Microsoft .NET Framework. Las clases forman una jerarquía de contención:
Un objeto DataSet representa un esquema (o una base de datos entera o un
subconjunto de una). Puede contener las tablas y las relaciones entre esas
tablas.
Un objeto DataTable representa una sola tabla en la base de datos. Tiene un
nombre, filas, y columnas.
84
Un objeto DataView "se sienta sobre" un DataTable y ordena los datos (como
una cláusula "orderby" de SQL) y, si se activa un filtro, filtra los registros (como
una cláusula "where" del SQL). Para facilitar estas operaciones se usa un
índice en memoria. Todas las DataTables tienen un filtro por defecto, mientras
que pueden ser definidos cualquier número de DataViews adicionales,
reduciendo la interacción con la base de datos subyacente y mejorando así el
desempeño.
Un DataColumn representa una columna de la tabla, incluyendo su nombre y
tipo.
Un objeto DataRow representa una sola fila en la tabla, y permite leer y
actualizar los valores en esa fila, así como la recuperación de cualquier fila
que esté relacionada con ella a través de una relación de clave primaria -
clave extranjera.
Un DataRowView representa una sola fila de un DataView, la diferencia entre
un DataRow y el DataRowView es importante cuando se está interactuando
sobre un resultset.
Un DataRelation es una relación entre las tablas, tales como una relación de
clave primaria - clave ajena. Esto es útil para permitir la funcionalidad del
DataRow de recuperar filas relacionadas.
Un Constraint describe una propiedad de la base de datos que se debe
cumplir, como que los valores en una columna de clave primaria deben ser
únicos. A medida que los datos son modificados cualquier violación que se
presente causará excepciones.
Un DataSet es llenado desde una base de datos por un DataAdapter cuyas
propiedades Connection y Command que han sido iniciados. Sin embargo, un
DataSet puede guardar su contenido a XML (opcionalmente con un esquema
XSD), o llenarse a sí mismo desde un XML, haciendo esto excepcionalmente
útil para los servicios web, computación distribuida, y aplicaciones
ocasionalmente conectadas desconectados.
85
ADO.NET y Visual Studio .NET.
En el IDE Visual Studio .NET existe la funcionalidad para crear las subclases
especializadas de las clases del DataSet para un esquema particular de base de
datos, permitiendo el acceso conveniente a cada campo a través de propiedades
fuertemente tipadas. Esto ayuda a capturar más errores de programación en tiempo
de compilación y hace más útil la característica Intellisense del IDE.
ADO.NET Entity Framework.
El ADO.NET Entity Framework es un conjunto de APIs de acceso a datos para
el Microsoft .NET Framework, apuntando a la versión de ADO.NET que se incluye
con el .NET Framework 3.5. Fue lanzado como actualización separada junto con el
Service Pack 1 para el .NET Framework, después del lanzamiento de tanto el .NET
Framework 3.5 y el Visual Studio 2008. Una nueva versión del Entity Framework (v
4.0) será liberada junto al Visual Studio 2010 y el .NET Framework 4.0.
Una entidad del Entity Framework es un objeto que tiene una clave
representando la clave primaria de una entidad lógica de datastore. Un modelo
conceptual Entity Data Model (modelo Entidad-Relación) es mapeado a un modelo
de esquema de datastore. Usando el Entity Data Model, el Framework permite que
los datos sean tratados como entidades independientemente de sus
representaciones del datastore subyacente.
El Entity SQL es un lenguaje similar al SQL para consultar el Entity Data
Model (en vez del datastore subyacente). Similarmente, las extensiones del Linq,
Linq-to-Entities, proporcionan consultas tipeadas en el Entity Data Model. Las
consultas Entity SQL y Linq-to-Entities son convertidas internamente en un Canonical
QueryTree que entonces es convertido en una consulta comprensible al datastore
subyacente (ej. en SQL en el caso de una base de datos relacional). Las entidades
pueden utilizar sus relaciones, y sus cambios enviados de regreso al datastore.
86
Report Viewer.
Es un control de libre distribución que permite la incorporación de informes en
las aplicaciones desarrolladas con .NET Framework. Los informes se han
desarrollado con la simplicidad de arrestar y soltar el diseñador de informes incluidos
en Visual Basic 2010.
El Report Viewer facilita la creación de informes simples y dispone también de
herramientas poderosas necesarias para generar informes complejos o
especializados desde casi cualquier origen de datos. Su objetivo principal es ayudar
a cualquier usuario a analizar e interpretar la información importante.
Los informes que genera el Report Viewer son herramientas de
administración que sirven para facilitar una rápida comprensión de los elementos
básicos y relacionados entre los datos sin formatos y ayudarle a tomar decisiones
correctas. Para que un informe sea eficaz, debe presentar los datos adecuados de
forma lógica. Si presenta datos incorrectos, o datos correctos de forma desordenada,
el informe puede retrasar el proceso de decisión o incluso provocar que se tome una
decisión incorrecta. Los datos de los informes se pueden agrupar y ordenar de
diversas formas esto le provee mucha flexibilidad para personalizar los informes.
El “modo local” o “modo remoto” puede utilizar enunciados de SQL estos se
pueden utilizar para obtener un conjunto especifico de datos de una base de
datos,los cuales se pueden ordenar, agrupar y seleccionar campos de enunciados de
SQL.
El control además soporta el uso de parámetros para solicitar al usuario de un
informe que especifique la información antes de que se genere el informe. La
información que escribe el usuario determinara lo que aparecerá en el informe.
87
Por ejemplo, en un informe usado por vendedores, puede existir una
parámetro que pida al usuario que elija una región. El informe devuelve los
resultados de la región.
El control permite dar formato a las cosas que puede hacer para cambiar la
presentación y el diseño de su informe, la apariencia del texto, de objetos o
secciones enteras del informe:
Dividir las secciones de un informe.
Llamar la atención sobre ciertos datos.
Cambiar la presentación de fechas, números, valores, cadenas de
texto.
Ocultar secciones no deseadas.
Dar el informe una apariencia profesional.
Ventajas:
Procesos de datos eficientes. El motor de informes integrado en ReportViewer
puede realizar operaciones tales como el filtrado, clasificación, agrupación y
agregación.
Soporta una gran variedad de formas para presentar los datos. Puede
presentar los datos como listas, tablas, cuadros y matrices (también conocido
como tablas de referencias cruzadas.)
Añade atractivo visual. Puede especificar las fuentes, colores, estilos de
borde, imágenes de fondo, etc para hacer su informe atractivo a la vista.
Permite la interactividad en los informes. Puede tener secciones plegables,
mapa del documento, marcadores, clasificación etc interactivo en su informe.
Soporta el formato condicional. Puede incrustar expresiones en el informe
para cambiar el estilo de visualización dinámica en función de los valores de
datos.
Apoya la impresión y vista preliminar.
88
Soporta la exportación a Excel, Word y PDF. (Exportación de Word en Visual
Studio 2010 y.)
PROCEDIMIENTO Y DESCRIPCION DE LAS ACTIVIDADES
REALIZADAS
En esta sección del informe se explica cómo se realizaron las
actividades para desarrollar el sistema denominado “Don Equipal”.
ANÁLISIS.
Políticas.
El pago es solo en efectivo.
Solo existen descuentos para estudiantes, presentando su credencial.
Entradas.
Clientes.
Empleados.
Comidas.
Bebidas.
Recetas.
Materia Prima.
Comandas.
Notas.
89
Salidas.
Relación de clientes ordenado por nombre.
Relación de empleados ordenado por nombre.
Reporte de materia prima por día.
Reporte de bebidas por día.
Reporte de compras por período.
Impresión de notas.
Relación de comandas por empleado.
Reporte de ventas por periodo.
Listado de precios.
Procesos.
Compras (materia prima y bebidas).
Comandas.
Notas.
90
Almacenes.
Clientes.
Empleados.
Comidas.
Bebidas.
Materia prima
Comandas.
Detalle bebida/ comida.
Recetas.
Entidades externas.
Empleados.
91
Diagrama de Warnier/Orr.
En la Figura 12. Se ilustra el diagrama de Warnier/Orr en el que se muestra el
funcionamiento general del sistema.
Registrar
Clientes Consultar
Modificar (teléfono, dirección, colonia, ciudad, calles)
Registrar
Empleados Consultar
Modificar (tel, dir, colonia, ciudad, sueldo, fecha ingreso)
Comidas
CATÁLOGOS
Registrar existencias =0
Consultar
Registra
Recetas Consulta por comida
Registrar
Consultar
Modificar (precio)
Bebidas
Registrar existencias =0
Consultar
Modificar (precio)
Materia prima
Figura 12. Diagrama de Warnier/Orr.
92
Compras
MOVIMIENTOS Comanda
Notas
Relación de clientes ordenado por nombre.
Relación de empleados ordenado por nombre.
Reporte de materia prima por día.
Reporte de bebidas por día.
Reporte de ventas por periodo.
Reporte de compras por periodo.
Impresión de notas.
Relación de comandas por empleado.
Listado de precios.
Ayuda
Respaldo
Restaurar
Figura 12. Diagrama de Warnier/Orr.
Materia prima
Bebidas
+ Existencias
Actualiza costo/unidad Registra
Consulta por no. compra
+ Existencias
Actualiza costo/unidad
Registra
Actualiza - existencias
Comida
Cancela
Bebida
Consulta pro no. comanda
Comida
Bebida
- Existencias
Comadna Edo = ‘A’
- Existencias
Comanda Edo = ‘A’
- Existencias
Comanda Edo = ‘C’
- Existencias
Comanda Edo = ‘C’
Registra Comanda Edo. = ‘P’
Imprime
REPORTES
UTILERIAS
93
Diagrama de contexto.
En la Figura 13. Se ilustra el diagrama de contexto en el que se muestra el
funcionamiento general del sistema.
Figura 13. Diagrama de contexto del sistema “Don Equipal”.
94
Diagrama de casos de uso general.
En la Figura 14. Se observa el diagrama de casos de uso general del sistema
donde se muestran los movimientos que incluye el sistema “Don Equipal” y también
los actores con los que trabaja.
Figura 14. Diagrama de caso de uso general.
95
Tabla de funciones.
En la Tabla 8. Se muestran las funciones que aparecen en los diagramas de
casos expandidos.
Tabla 8. Funciones de los diagramas de caso expandidos.
No. de
función
Descripción Tipo
1 Incrementa no de comanda Evidente
2 Selecciona cliente Evidente
3 Busca y muestra datos Evidente
4 Selecciona tipo de pedido Evidente
5 Selecciona número de mesa Evidente
6 Selecciona empleado Evidente
7 Selecciona comida Evidente
8 Selecciona bebida Evidente
9 Calcula total Evidente
10 Incrementa número de nota Evidente
11 Selecciona número de comanda Evidente
96
Diagramas de movimientos.
Diagrama de flujo de datos para registrar comanda.
En la Figura 15. Se ilustra el diagrama de flujo de datos para registrar una
comanda.
Figura 15. Diagrama flujo de datos para registrar una comanda.
97
Diagrama de caso de uso expandido para registrar comanda.
En la Figura 16. Se ilustra el diagrama de caso de uso expandido para
registrar una comanda.
Figura 16. Diagrama de caso de uso expandido.
Nombre: Diagrama de caso de uso expandido para registrar comandas.
Actores: cliente y empleado.
Descripción: incrementa el número de comanda, selecciona el cliente a realizar la
comanda, busca y muestra los datos del cliente, selecciona tipo de comanda, si la comanda
es local entonces incrementa, selecciona el número de mesa despues selecciona el
empleado, busca y muestra los datos del empleado, elige la comida del cliente y si desea
bebida tambien y por ultimo calcula el total de la comanda.
Funciones: 1, 2, 3, 4, 5, 6 , 7, 8 y 9.
98
Diagrama de estados para registrar comanda.
En la Figura 17. Se ilustra el diagrama de estados para registrar una comanda.
Figura 17. Diagrama de estados.
Precondición: Registra una nueva
comanda.
Poscondición: Graba una nueva comanda.
Caminos alternos: Tipo de pedido por
teléfono, si el cliente desea más pedido y si
desea más bebida.
Descripción: Incrementa el número de
comanda, se toma la fecha del sistema
operativo para la comanda, se elige el
empleado se buscan sus datos y se
muestran, seleccionar el tipo de pedido, si la
opción es local entonces se elige la mesa, si
es teléfono se brinca esta opción. Después
se escoge el nombre del cliente, se busca
sus datos y se muestran, seleccionar la
comida se busca y se muestra en la rejilla y
la misma opción para las bebidas, en caso
de que el cliente desee mas comida o
bebida se regresa a elegirla, se calcula el
subtotal, el estado de la comanda es = „A‟ y
se decrementan existencias en la comanda
y se graba la comanda junto con el detalle
de comida y detalle de bebida.
99
Diagrama de colaboración para registrar comanda.
En la Figura 18. Se ilustra el diagrama de colaboración para registrar una
comanda.
Figura 18. Diagrama de colaboración para registrar comanda.
100
Diagrama de flujo de datos para registrar nota.
En la Figura 19. Se ilustra el diagrama de colaboración para registrar una
comanda.
Figura 19. Diagrama de colaboración para registrar notas.
101
Diagrama de caso de uso expandido para registrar nota.
En la Figura 20. Se ilustra el diagrama de caso de uso expandido para
registrar nota.
Figura 20. Diagrama de caso de uso expandido para registrar nota.
Nombre: Diagrama de caso de uso expandido para registrar nota.
Actores: cliente y empleado.
Descripción: incrementa el número de nota, selecciona el número de comanda a pagar,
busca y muestra datos del empleado, busca y muestra los datos del cliente, busca y
muestra los datos de comanda.
Funciones: 3, 10, 11.
102
Diagrama de estados para registrar nota.
En la Figura 21. Se ilustra el diagrama de estados para registrar una nota.
Figura 21. Diagrama de estados para registrar nota.
Precondición: Registra una nueva nota.
Poscondición: Graba una nueva nota.
Caminos alternos: No se realiza ninguna
nota.
Descripción: incrementa el número de nota,
se toma la fecha del sistema operativo, se
elige en número de la comanda para realizar
la nota, se muestra el tipo de pedido y se
buscan y muestran datos como el de
empleado, cliente y los datos de la
comanda. Cambia el estado de la comanda
a „P‟ de pagada y se graba la nota.
103
Diagrama de colaboración para registrar nota.
En la Figura 22. Se ilustra el diagrama de colaboración para registrar una nota.
Figura 22. Diagrama de colaboración para registrar nota.
104
DISEÑO
Diccionario de datos.
Clientes
Entidad: Clientes
Objetivo: Almacena los datos principales de las asistencias de los clientes.
Atributos: 8
Campo Llave: IdCliente
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdCliente Int 10 No Campo llave, almacena la
clave única del cliente
0-9
2 Nombre Nvarchar 45 No Guarda el nombre del
cliente
a-z, 0-9
3 Dirección Nvarchar 45 Si Almacena la dirección del
cliente
a-z, 0-9
4 Colonia Nvarchar 23 Si Almacena la colonia del
cliente
a-z, 0-9
5 Calle1 Nvarchar 35 Si Almacena la primer calle del
domicilio del cliente
a-z, 0-9
6 Calle2 Nvarchar 35 Si Almacena la segunda calle
del cliente
a-z, 0-9
7 Ciudad Nvarchar 23 Si Almacena la ciudad del
cliente
a-z, 0-9
8 Teléfono Nvarchar 18 Si Almacena el teléfono del
cliente
a-z, 0-9
105
Empleados
Entidad: Empleados
Objetivo: Almacena los datos principales de los clientes.
Atributos: 9
Campo Llave: IdEmpleado
No. Nombre Tipo Long Nulo
Descripción Dominio
1 IdEmpleado Int 5 No Campo llave,
almacena la clave
única del empleado
0-9
2 Nombre Nvarchar 45 No Guarda el nombre del
empleado
a-z, 0-9
3 Dirección Nvarchar 45 No Almacena la dirección
del empleado
a-z, 0-9
4 Colonia Nvarchar 23 Si Almacena la colonia
del empleado
a-z, 0-9
5 Ciudad Nvarchar 23 Si Almacena la ciudad
del empleado
a-z, 0-9
6 Teléfono Nvarchar 18 Si Almacena el teléfono
del empleado
a-z, 0-9
7 Celular Nvarchar 18 No Almacena el no.
celular del empleado
a-z, 0-9
8 Fecha_Ingreso Nvarchar 15 Si Almacena la fecha
ingreso del empleado
Fecha
válida
9 Sueldo Decimal (18,2) Si Almacena la cantidad
sueldo del empleado
0-9
106
Bebidas
Entidad: Bebidas
Objetivo: Almacena los datos de las bebidas.
Atributos: 6
Campo Llave: IdBebida
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdBebida Int 5 No Campo llave, almacena
la clave de la bebida
0-9
2 Descripción Nvarchar 35 No Guarda la descripción
de la bebida
a-z, 0-9
3 Costo Decimal (18,2) Si Almacena el costo de la
bebida
0-9
4 Precio Decimal (18,2) No Almacena la contraseña
del usuario
0-9
5 Existencia Int 10 No Almacenaexistencias de
bebidas
0-9
6 Imagen Nvarchar (MAX) Si Almacena la imagen de
la bebida
a-z, 0-9
107
Detalle Bebidas
Entidad: DetalleBebida
Objetivo: Almacena el detalle de las bebidas.
Atributos: 6
Campo Llave: IdComanda e IdBebida
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdComanda Int 10 No Campo llave, almacena la
clave de la comanda
0-9
2 IdBebida Int 5 No Campo llave, almacena la
clave de la bebida
0-9
3 Cantidad int 10 No Almacena la cantidad de
la bebida
0-9
4 Precio Decimal (18,2) No Almacena el precio de la
bebida
0-9
108
Comidas
Entidad: Comidas
Objetivo: Almacena los principales datos de las comidas.
Atributos: 4
Campo Llave: IdComida
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdComida Int 10 No Campo llave, almacena
la clave de la comida
0-9
2 Descripcion Nvarchar 80 No Almacena la descripción
de la comida
0-9
3 Precio Decimal 10 No Almacena el precio de
la comida
0-9
4 Imagen Nvarchar (MAX) Si Almacena la imagen de
la comida
0-9
109
Detalle Comidas
Entidad: DetalleComida
Objetivo: Almacena en detalle de las comidas.
Atributos: 4
Campo Llave: IdComanda e IdComida
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdComanda Int 10 No Campo llave, almacena la
clave de la comanda
0-9
2 IdComida Int 10 No Campo llave, almacena la
clave de la comida
0-9
3 Cantidad Int 10 No Almacena la cantidad de la
comida
0-9
4 Precio Decimal (18,2) No Almacena la el precio de la
comida
0-9
110
Comandas
Entidad: Comanda
Objetivo: Almacena los principales datos de la comanda de los clientes.
Atributos: 8
Campo Llave: IdComanda
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdComanda Int 10 No Campo llave, almacena
la clave de la comanda
0-9
2 IdEmpleado Int 5 No Almacena la clave del
empleado
0-9
3 IdCliente Int 10 No Almacena la clave del
cliente
0-9
4 Fecha Date NA Si Almacena la fecha de la
comanda
Fecha
válida
5 Tipo Nvarchar 10 No Almacena el tipo de
comanda
a-z, 0-9
6 Mesa Int 3 Si Almacena el no. de mesa
de la comanda
0-9
7 Total Decimal (18,2) No Almacena el total de la
comanda
0-9
8 Estado Nvarchar 4 No Almacena el estado de la
comanda
a-z, 0-9
111
Compras
Entidad: Compras
Objetivo: Almacena los principales datos de las compras del establecimiento.
Atributos: 4
Campo Llave: NoCompra
No. Nombre Tipo Long Nulo Descripción Dominio
1 NoCompra Int 10 No Campo llave, almacena el
no. de compra
0-9
2 Factura Int 10 Si Almacena la clave de la
factura
0-9
3 Fecha Date NA Si Almacena la fecha de la
compra
Fecha
válida
4 Total Decimal (18,2) No Almacena el total de la
compra
0-9
112
Detalle CompBeb
Entidad: DetalleCompBeb
Objetivo: Almacena los detalle de las compras de bebidas del establecimiento.
Atributos: 4
Campo Llave: NoCompra e Idbebida
No. Nombre Tipo Long Nulo Descripción Dominio
1 NoCompra Int 10 No Campo llave, almacena el
no. de compra
0-9
2 Idbebida Int 5 No Campo llave, almacena el
no. de bebida
0-9
3 Cantidad Int 5 No Almacena la cantidad de la
bebida
0-9
4 Costo Decimal (18,2) No Almacena el costo de la
bebida
0-9
113
Detalle CompMP
Entidad: DetalleCompMP
Objetivo: Almacena los detalle de las compras de materia prima del establecimiento.
Atributos: 4
Campo Llave: NoCompra e IdProducto
No. Nombre Tipo Long Nulo Descripción Dominio
1 NoCompra Int 10 No Campo llave, almacena el
no. de compra
0-9
2 IdProducto Int 5 No Campo llave, almacena el
no. de materia prima
0-9
3 Cantidad Decimal (18,3) No Almacena la cantidad de la
materia prima
0-9
4 Costo Decimal (18,2) No Almacena el costo de la
materia prima
0-9
114
Materia Prima
Entidad: MateriaPrima
Objetivo: Almacena los principales datos de la materia prima.
Atributos: 4
Campo Llave: IdProducto
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdProducto Int 5 No Campo llave, almacena
el no. de producto
0-9
2 Descripcion Nvarchar 20 No Almacena la descripción
de la materia prima
a-z, 0-9
3 Existencias Decimal (18,3) No Almacena la cantidad de
existencias de la materia
prima
0-9
4 Unidad Nvarchar 12 No Almacena la unidad del la
materia prima
a-z, 0-9
5 Costo_Unid Decimal (18,2) Si Almacena el costo por
unidad de la materia
prima
0-9
115
Notas
Entidad: Nota
Objetivo: Almacena los principales datos de la nota del cliente.
Atributos: 4
Campo Llave: NoNota
No. Nombre Tipo Long Nulo Descripción Dominio
1 NoNota Int 10 No Campo llave, almacena el
no. de nota
0-9
2 IdComanda Int 10 No Almacena el número de la
comanda
0-9
3 Fecha Date No Almacena la fecha de la
nota
Fecha
válida
4 Total Decimal (18,2) No Almacena el total de la
nota
0-9
Recetas
Entidad: Recetas
Objetivo: Almacena los principales datos de las recetas.
Atributos: 3
Campo Llave: IdComanda e IdProducto
No. Nombre Tipo Long Nulo Descripción Dominio
1 IdComanda Int 10 No Campo llave, almacena el
no. de comanda
0-9
2 IdProducto Int 5 No Campo llave, almacena el
no. de producto
0-9
3 Cantidad Decimal (18,3) No Almacena la cantidad de
las recetas
0-9
116
Normalización.
Tabla: Clientes
Primera Forma Normal (1FN):La tabla clientes cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdCliente).
Segunda Forma Norma (2FN): La tabla clientes cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Nombre, Dirección, Colonia, Calle1, Calle2, Ciudad, Teléfono) depende
completamente de la llave primaria (IdCliente).
Tercera Forma Normal (3FN): La tabla clientes se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Nombre, Dirección, Colonia, Calle1, Calle2, Ciudad, Teléfono) dependen no
transitivamente de la llave primaria (IdCliente).
Tabla: Empleados
Primera Forma Normal (1FN):La tabla empleados cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdCliente).
117
Segunda Forma Norma (2FN): La tabla empleados cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Nombre, Direccion, Colonia, Ciudad, Teléfono, Celular, Fecha_Ingreso,
Sueldo) depende completamente de la llave primaria (IdEmpleado).
Tercera Forma Normal (3FN): La tabla clientes se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Nombre, Direccion, Colonia, Ciudad, Teléfono, Celular, Fecha_Ingreso,
Sueldo) dependen no transitivamente de la llave primaria (IdEmpleado).
Tabla: Bebidas
Primera Forma Normal (1FN): La tabla bebidas cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdBebida).
Segunda Forma Norma (2FN): La tabla bebidas cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Descripcion, Costo, Precio, Existencias, Imagen) depende completamente
de la llave primaria (IdBebida).
118
Tercera Forma Normal (3FN): La tabla clientes se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Descripcion, Costo, Precio, Existencias, Imagen) dependen no
transitivamente de la llave primaria (IdBebida).
Tabla: DetalleBebida
Primera Forma Normal (1FN): La tabla detallebebida cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con dos llaves primaria (IdComanda, IdBebida).
Segunda Forma Norma (2FN): La tabla detallebebida cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Cantidad, Precio) depende completamente de las llaves primarias
(IdComanda, IdBebida).
Tercera Forma Normal (3FN): La tabla detallebebida se encuentra en la
tercera forma normal, ya que cumple con la segunda forma normal y todos sus
atributos no primos (Cantidad, Precio) dependen no transitivamente de las llaves
primarias (IdComanda, IdBebida).
119
Tabla: Comidas
Primera Forma Normal (1FN): La tabla comidas cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdComida).
Segunda Forma Norma (2FN): La tabla comidas cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Descripcion, Precio, Imagen) depende completamente de la llave primaria
(IdComida).
Tercera Forma Normal (3FN): La tabla comidas se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Descripcion, Precio, Imagen) dependen no transitivamente de la llave
primaria (IdComida).
Tabla: DetalleComida
Primera Forma Normal (1FN): La tabla detallecomida cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con dos llaves primarias (IdComanda, IdComida).
120
Segunda Forma Norma (2FN): La tabla detallecomida cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Cantidad, Precio) depende completamente de las llaves primarias
(IdComanda, IdComida).
Tercera Forma Normal (3FN): La tabla detallecomida se encuentra en la
tercera forma normal, ya que cumple con la segunda forma normal y todos sus
atributos no primos (Cantidad, Precio) dependen no transitivamente de las llaves
primarias (IdComanda, IdComida).
Tabla: Comandas
Primera Forma Normal (1FN):La tabla comandas cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdComanda).
Segunda Forma Norma (2FN): La tabla comandas cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (IdEmpleado, IdCliente, Fecha, Tipo, Mesa, Total, Estado) depende
completamente de la llave primaria (IdComanda).
121
Tercera Forma Normal (3FN): La tabla comidas se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (IdEmpleado, IdCliente, Fecha, Tipo, Mesa, Total, Estado) dependen no
transitivamente de la llave primaria (IdComanda).
Tabla: Compras
Primera Forma Normal (1FN):La tabla compras cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (NoCompra).
Segunda Forma Norma (2FN): La tabla compras cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Factura, Fecha, Total) depende completamente de la llave primaria
(NoCompra).
Tercera Forma Normal (3FN): La tabla compras se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Factura, Fecha, Total) dependen no transitivamente de la llave primaria
(NoCompra).
122
Tabla: DetalleCompBeb
Primera Forma Normal (1FN): La tabla detallecompbeb cumple con la
primera forma normal (1FN), ya que por cada renglón, columna, se tienen valores
atómicos, los valores de sus celdas poseen valores simples e indivisibles y en cada
una de sus columnas todos sus atributos son del mismo tipo, así como también las
columnas cuentan con un nombre único y cumplen con la regla de no tener registros
repetidos ya que cuenta con dos llaves primarias (NoCompra, IdBebida).
Segunda Forma Norma (2FN): La tabla detallecompbeb cumple con la
segunda forma norma (2FN), ya que cumple con la primera forma normal y todos sus
atributos no primos (Cantidad, Costo) depende completamente de las llaves
primarias (NoCompra, IdBebida).
Tercera Forma Normal (3FN): La tabla detallecompbeb se encuentra en la
tercera forma normal, ya que cumple con la segunda forma normal y todos sus
atributos no primos (Cantidad, Costo) dependen no transitivamente de las llaves
primarias (NoCompra, IdBebida).
Tabla: DetalleCompMP
Primera Forma Normal (1FN): La tabla detallecompmp cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con dos llaves primarias (NoCompra, IdProducto).
123
Segunda Forma Norma (2FN): La tabla detallecompmp cumple con la
segunda forma norma (2FN), ya que cumple con la primera forma normal y todos sus
atributos no primos (Cantidad, Costo) depende completamente de las llaves
primarias (NoCompra, IdProducto).
Tercera Forma Normal (3FN): La tabla detallecompmp se encuentra en la
tercera forma normal, ya que cumple con la segunda forma normal y todos sus
atributos no primos (Cantidad, Costo) dependen no transitivamente de las llaves
primarias (NoCompra, IdProducto).
Tabla: MateriaPrima
Primera Forma Normal (1FN): La tabla materiaprima cumple con la primera
forma normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos,
los valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (IdProducto).
Segunda Forma Norma (2FN): La tabla materiaprima cumple con la segunda
forma norma (2FN), ya que cumple con la primera forma normal y todos sus atributos
no primos (Descripcion, Existencias, Unidad, Costo_Unid) depende completamente
de la llave primaria (IdProducto).
124
Tercera Forma Normal (3FN): La tabla materiaprima se encuentra en la
tercera forma normal, ya que cumple con la segunda forma normal y todos sus
atributos no primos (Desripcion, Existencias, Unidad, Costo_Unid) dependen no
transitivamente de la llave primaria (IdProducto).
Tabla: Nota
Primera Forma Normal (1FN): La tabla nota cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con una llave primaria (NoNota).
Segunda Forma Norma (2FN): La tabla nota cumple con la segunda forma
norma (2FN), ya que cumple con la primera forma normal y todos sus atributos no
primos (IdComanda, Fecha, Total) depende completamente de la llave primaria
(NoNota).
Tercera Forma Normal (3FN): La tabla nota se encuentra en la tercera forma
normal, ya que cumple con la segunda forma normal y todos sus atributos no primos
(IdComanda, Fecha, Total) dependen no transitivamente de la llave primaria
(NoNota).
125
Tabla: Recetas
Primera Forma Normal (1FN): La tabla recetas cumple con la primera forma
normal (1FN), ya que por cada renglón, columna, se tienen valores atómicos, los
valores de sus celdas poseen valores simples e indivisibles y en cada una de sus
columnas todos sus atributos son del mismo tipo, así como también las columnas
cuentan con un nombre único y cumplen con la regla de no tener registros repetidos
ya que cuenta con dos llaves primarias (IdComida, IdProducto).
Segunda Forma Norma (2FN): La tabla recetas cumple con la segunda forma
norma (2FN), ya que cumple con la primera forma normal y todos sus atributos no
primos (Cantidad) depende completamente de las llaves primarias (IdComida,
IdProducto).
Tercera Forma Normal (3FN): La tabla compras se encuentra en la tercera
forma normal, ya que cumple con la segunda forma normal y todos sus atributos no
primos (Cantidad) dependen no transitivamente de las llaves primarias (IdComida,
IdProducto).
126
Diagrama de clases.
127
Pantallas del sistema.
El diseño del sistema está basado en 1 menú principal.
Pantalla general.
Reportes, Utilería, Salir, Levantar Orden, Clientes, Empleados, Comidas,
Bebidas, Materia Prima, Recetas, Compras, Nota. Se muestra en la Figura 23.
Figura 23. Pantalla general.
128
Pantalla de Utilerías.
Ayuda, Respaldar, Restaurar. Se muestra en la Figura 24.
Figura 24. Pantalla de Utilerías.
Pantalla de Reportes.
Se muestra en la Figura 25.
Figura 25.Pantalla de reportes.
129
CODIFICACIÓN
Diagrama de módulos.
En la Figura 26. Se muestra el diagrama de módulos del sistema, con todos los
componentes que lo conforman.
Figura 26. Diagrama de módulos del sistema “Don Equipal”.
130
Diccionario de módulos del sistema.
En la siguiente tabla se muestra los formularios diseñados y las tablas a las
que se tiene acceso cada uno. Ver tabla 9.
Tabla 9. Diccionario de módulos del sistema.
Opción Formulario descripción Tablas que accesa
Catálogo clientes
frmClientes.vb
A través de este catálogo se puede: Registrar nuevo
cliente. Modificar datos del
cliente. Consultar datos de los
clientes.
Clientes
Catálogo empleados
frmEmpleados.vb
A través de este catálogo se puede: Registrar nuevo
empleado. Modificar datos del
empleado. Consultar datos de los
empleados.
Empleados
Catálogo Comidas
frmComidas.vb
A través de este catálogo se puede: Registrar nueva
comida. Modificar datos de la
comida. Consultar datos de las
comidas.
Comidas
Catálogo Bebidas
frmBebidas.vb
A través de este catálogo se puede: Registrar nueva
bebida. Modificar datos de la
bebida. Consultar datos de las
bebidas.
Bebidas
131
Catálogo Materia Prima
frmMateriaPrima.vb
A través de este catálogo se puede: Registrar nueva
materia prima. Consultar datos de las
materias primas.
MateriaPrima
Catálogo Recetas
frmRecetas.vb
A través de este catálogo se puede: Registrar nueva
receta. Consultar datos de la
receta.
Recetas
Proceso Compras
1.-frmCompras.vb 2.-frmCompraBeb.vb
3.-frmCompraMP.vb
A través de este proceso se puede: Registrar nueva
compra. Consultar datos de la
compra.
Compras DetalleCompMP DetalleCompBeb Bebidas MateriaPrima
Proceso
Nota
frmNotas.vb
A través de este proceso se puede: Registrar nueva nota.
Imprime datos de la
nota.
Nota
Proceso levantar orden
1.-frmComandas.vb 2.-frmActualizarComanda.vb 3.-frmCancelarComanda.vb
A través de este proceso se puede: Registrar nueva orden.
Actualizar la orden.
Cancelar la orden.
Consultar datos de la
orden.
Comandas DetalleComida DetalleBebida Bebidas MateriaPrima Recetas
Relación de
Clientes
Clientes.rpt
Esta pantalla permite consultar e imprimir La relación de todos los clientes ordenados por Nombre.
Clientes
Relación de Empleados
Empleados.rpt
Esta pantalla permite consultar e imprimir la relación de todos los clientes
Empleados
132
ordenados por Nombre.
Reporte de
Materia Prima
MateriaPrima_Exist.rpt
Esta pantalla permite consultar e imprimir el reporte de las existencias de la materia prima por día.
Materia Prima
Reporte Bebidas
1.-Bebidas_Exist.rpt 2.-Lista_PreBeb.rpt
Estas pantallas permiten consultar e imprimir el reporte de las existencias de las bebidas por día y la lista de precios.
Bebidas
Reporte Comidas
Lista_PreComi.rpt
Esta pantalla permite consultar e imprimir el reporte de la lista de precios de las comidas.
Comidas MateriaPrima
Reporte de comandas
1.-Comandas_Emplea.rpt 2.-Ventas_Periodo.rpt
Estas pantallas permite consultar e imprimir el reporte de las comandas por empleado y comandas en un periodo.
Comandas DetalleComida DetalleBebida Empleados Comidas Bebidas
Reporte Compras
Compras_Periodo.rpt
Esta pantalla permite consultar e imprimir el reporte de todas las compras en un período.
Compras DetalleCompBeb DetalleCompMP
Utilería de ayuda
frmAyuda.vb
Esta utilería incluye todos los temas relacionados con la ayuda para manejar el sistema, se incluyen aspectos de cada parte principal del programa, su funcionamiento, así como puntos importantes a considerar, además esta ayuda cuenta con una interfaz amigable para el usuario.
No aplica
Esta utilería sirve para que el gerente del establecimiento
133
Utilería de Respaldo
frmRespaldar.vb pueda crear un respaldo de la base de datos del sistema en cualquier momento que lo necesite.
No aplica
Utilería de Restaurar
frmRestaurar.vb
Esta utilería sirve para que el gerente del establecimiento pueda restaurar la base de datos del sistema en cualquier momento que lo necesite.
No aplica
134
PRUEBAS Y DEPURACIÓN
Caso de prueba: Registrar Cliente
Entradas
El empleado registrará un nuevo cliente, los datos que se encuentran en la
tabla de “Clientes” son los siguientes, ver Figura 27.
Figura 27. Tabla de clientes.
Condiciones
Los datos a ingresar a este cliente son los siguientes:
1. IdCliente: 6
2. Nombre: tzirinzi magaña bautista
3. Direccion: rosales #54
4. Colonia: bugambilias
5. Calle1: de las rosas
6. Calle2: “”
7. Ciudad: tamazula
8. Telefono: 358 357 541
135
En la Figura 28. Se muestra la pantalla con los datos del cliente.
Figura 28. Pantalla de captura de los datos del cliente.
Para grabar el cliente es necesario presionar el botón de grabar. Se espera el
mensaje de “Se ha grabado exitosamente” como se observa en la Figura 29.
Figura 29. Pantalla de grabado exitoso.
136
Salidas
Al momento de grabar, se insertará un nuevo registro en la tabla “Clientes” con
los datos antes proporcionados. Ver Figura 30.
Figura 30. Pantalla de la tabla de clientes después de la inserción correcta.
Caso de prueba: Registrar Materia Prima.
Entradas
El gerente registrará una nueva materia prima, los datos que se encuentran en
la tabla de materia prima son los siguientes, ver Figura 31:
Figura 31.Tabla de materia prima.
137
Condiciones
Los datos a ingresar a esta materia prima son los siguientes:
1. IdProducto: 5
2. Descripcion: tortilla
3. Existencias: 0
4. Unidad: pieza
5. Costo_Unid: 1.00
En la Figura 32. Se muestra la pantalla con los datos de la materia prima.
Figura 32. Pantalla de captura de los datos del cliente.
138
Para grabar la materia prima es necesario presionar el botón de grabar. Se
espera el mensaje de “Se ha grabado exitosamente” como se observa en la Figura
33.
Figura 33. Pantalla de grabado exitoso.
Salidas
Al momento de grabar, se insertará un nuevo registro en la tabla
“MateriaPrima” con los datos antes proporcionados. Ver Figura 34.
Pantalla 34. Pantalla de la tabla de materia prima después de la inserción
correcta.
139
Caso de prueba: Levantar Orden
Entradas
El empleado registrará una nueva comanda, los datos que se encuentran en la
tabla de comandas son los siguientes, ver Figura 35.
Figura 35.Tabla de comandas.
La tabla de DetalleComida muestra la siguiente información, ver Figura 36.
Figura 36. Datos del detalle de comida.
140
La tabla de DetalleBebida muestra la siguiente información, ver Figura 37.
Figura 37.Datos del detalle de bebida.
La tabla de Clientes de la clave “6” muestra la siguiente información, ver
Figura 38.
Figura 38. Datos principales del cliente “6”
La tabla de Empleados de la clave “5” muestra la siguiente información, ver Figura
39.
Figura 39. Datos principales del cliente “5”.
141
La tabla de Recetas muestra la siguiente información, ver Figura 40.
Figura 40. Datos de la Receta.
La tabla de MateriaPrima muestra la siguiente información, ver Figura
41.
Figura 41.Datos de la materia prima.
142
La tabla de Bebidas muestra la siguiente información, ver Figura 42.
Figura 42. Datos de las bebidas.
La tabla de Comidas muestra la siguiente información, ver Figura 43.
Figura 43. Datos de las Comidas.
143
Condiciones
Los datos a ingresar a esta comanda son los siguientes:
6. IdComanda: 5
7. IdEmpleado:2
8. IdCliente:1
9. Fecha: 20-11-2013
10. Tipo: Local
11. Mesa: 3
12. Total: 213.5
13. Estado: “A”
En la Figura 44. Se ilustra la pantalla con los datos de la comanda.
Figura 44. Pantalla de captura de los datos de la comanda.
144
Para grabar la comanda es necesario presionar el botón de grabar. Se muestra el
mensaje de “Se ha grabado exitosamente” como se observa en la Figura 45.
Figura 45. Pantalla de grabado exitoso.
Salidas
Al momento de grabar, se insertará un nuevo registro en la tabla “Comandas”
con los datos antes proporcionados. Ver Figura 46.
Figura 46. Pantalla de la tabla de comandas después de la inserción Correcta.
Se insertará nuevos registros en la tabla “DetalleComida” con el pedido de
comida de la comanda. Ver Figura 47.
145
Figura 47. Pantalla de la tabla de DetalleComida después de la inserción
correcta
Se insertará nuevos registros en la tabla “DetalleBebida” con el pedido de
bebidas de la comanda. Ver Figura 48.
Figura 48. Pantalla de la tabla de DetalleBebida después de la inserción
correcta.
146
Se consultará la receta en la tabla “Recetas” para ver la cantidad a
decrementar de materia prima. Ver Figura 49.
Figura 49. Pantalla de la tabla de Recetas para consultar la cantidad de
productos a decrementar.
Se actualizará la materia prima en la tabla “MateriaPrima” decrementando la
cantidad de producto que se necesitó en la receta. Ver Figura 50.
Figura 50. Pantalla de la tabla de MateriaPrima después de
decrementar el producto.
147
Se actualizará la bebida en la tabla “Bebidas” decrementando la cantidad de
bebida que se solicitó en el pedido. Ver Figura 51.
Figura 51. Pantalla de la tabla de Bebidas después de decrementar la bebida.
148
Dentro del programa se puede consultar el registro de la comanda al presionar
el botón de consultar que aparece en la Figura 44. A continuación se muestra la
consulta individual de la comanda con una vez oprimido el botón. Ver Figura 52.
Figura 52. Consulta de comanda.
149
Caso de prueba: Nota
Entradas
El empleado registrará una nueva nota, los datos que se encuentran en la
tabla de notas son los siguientes, ver Figura 53.
Figura 53. Tabla de notas.
La tabla de comanda muestra la siguiente información, ver Figura 54.
Figura 54. Tabla de Comanda.
150
Condiciones
Los datos a ingresar a esta nota son los siguientes:
1. NoNota: 4
2. IdComanda:5
3. Fecha: 20-11-2013
4. Total: 213.50
En la Figura 55. Se ilustra la pantalla con los datos de la nota.
Figura 55. Pantalla de captura de los datos de la nota.
151
Para grabar la nota es necesario presionar el botón de grabar. Se espera el
mensaje de “Se ha grabado exitosamente” como se observa en la Figura 56.
Figura 56. Pantalla de grabado exitoso.
Salidas
Al momento de grabar, se insertará un nuevo registro en la tabla “Notas” con
los datos antes proporcionados. Ver Figura 57.
Figura 57. Pantalla de la tabla de Notas después de la inserción Correcta.
152
Se actualizará el estado de la comanda en la tabla “Comandas” una vez
pagada edo=”P”. Ver Figura 58.
Figura 58. Pantalla de la tabla de comandas después de actualizar el estado.
153
IMPLANTACIÓN
El método de implantación que se utilizó fue el de forma paralela, ya que el
gerente del establecimiento junto con los empleados llevan el control de inventario y
de comandas de forma manual. De esta forma podrán llevar el control de forma
manual y automatizada, hasta que se familiaricen con el sistema y éste.
Planeación de la implantación.
Objetivo: implantar el sistema “Don Equipal” en un periodo de 3 semanas.
Objetivos específicos:
Instalación del sistema.
Capacitación.
Ajustes y correcciones.
Implantación del sistema.
Se instalará el sistema “Don Equipal”.
Capacitación.
Se les mostrará a la persona o personas que vayan a manejar el sistema de
cuáles son las opciones que contiene, sobre cómo se tiene que manejar y el saber
utilizar la ayuda en caso de que se le presente alguna limitante.
154
Captura de datos.
En este paso se tendrá que reunir toda la información actualizada y detallada
con la que se cuenta para que las bases de datos se encuentren con información
actual y arroje resultados congruentes.
Ajustes y correcciones.
Desarrollar una serie de pruebas que permiten verificar y corregir los errores
que se presenten.
Liberación.
Cuando ya se hayan cumplido todos los objetivos mencionados anteriormente
se liberará el sistema.
Cronograma de actividades.
En la Figura 59 se ilustra el total de semanas invertidas en la implantación del
sistema, mostrando todos los puntos anteriores que se tomaron en cuenta.
ACTIVIDAD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Análisis
Diseño
Codificación
Pruebas
Implantación
Documentación
Mantenimiento
Figura 59. Cronograma de actividades.
155
RESULTADOS Y GRÁFICOS
En las siguientes imágenes se muestran algunos de los resultados obtenidos
en el sistema. En la Figura 60 se muestra la consulta general de los clientes.
Figura 60. Consulta general de clientes.
156
Como gráfico se presenta el reporte de clientes que se muestra a continuación
en la Figura 61 relacionado con la tabla de la Figura 60.
Figura 61. Reporte de relación de clientes.
157
En la Figura 62. Se muestra la consulta general de materia prima.
Figura 62. Consulta general de materia prima.
158
Como gráfico se presenta el reporte de existencias de materia prima que se
muestra a continuación en la Figura 63 relacionado con la tabla de la Figura 62.
Figura 63. Consulta de existencias de materia prima.
159
En la Figura 64. Se observa la relación de comandas por empleado en un
período.
Figura 64. Relación de comandas por empleado.
160
En la Figura 65. Se observa el reporte de compras en un período.
Figura 65. Reporte de compras en un período.
161
CONCLUSIÓN
Al terminar éste sistema nos podemos dar cuenta que en la actualidad los
sistemas de información son una herramienta indispensable para las empresas, pues
juegan un papel muy importante dentro de ella, con el fin de que puedan enfrentarse
en el mundo de la competencia por medio de la información que genera, los cuales
nos permiten tener una mejor toma de decisiones para la empresa.
Los sistemas de información dentro de las empresas son demasiado
importantes, por ello es bueno conocer el funcionamiento y todo lo que pueden
realizar. Uno de los principales problemas que aqueja a los directivos es la escases
de información para poder tomar las decisiones adecuadas, resulta de mucha
importancia el tener un sistema de información adecuado a las necesidades que les
permita planear, gestionar y controlar de manera optima los objetivos que se
requieren, para así poder tomar la decisión según la situación en la que se
encuentre.
La realización e implementación del sistema de información propuesto cumple
con las consideraciones anteriores y facilita el manejo de inventario y comandas para
el establecimiento Burritos “Los Equipales”.
162
REFERENCIAS BIBLIOGRÁFICAS
http://translate.google.com.mx/translate?hl=es&sl=en&u=http://en.wikipedia.org/wiki/
Warnier/Orr_diagram&prev=/search%3Fq%3Ddiagrama%2Bwarnier/orr%26sa%3DX
%26biw%3D520%26bih%3D450
http://clases3gingsof.wikifoundry.com/page/Diagrama+de+Contexto
http://es.wikipedia.org/wiki/Diagrama_de_Flujo_de_Datos
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
http://markblogs-markmendoza.blogspot.mx/2010/12/diagramas-de-estado.html
http://es.wikipedia.org/wiki/Diagrama_de_colaboración
http://es.wikipedia.org/wiki/Diagrama_de_clases
http://utubersidad.com/?page_id=1234
http://www.slideshare.net/JaimeDavidRomero/fundamentos-de-las-bases-de-datos
http://es.wikipedia.org/wiki/Modelo_entidad-relación
163
http://es.wikipedia.org/wiki/Modelo_relacional
http://www.buenastareas.com/ensayos/Grados-De-Normalización-Validación-De-
Datos-Reglas/24186855.html
https://www.google.com.mx/search?q=simbolo+para+el+diagrama+de+colaboracion&
source=lnms&tbm=isch&sa=X&ei=FnaCUqHaGYf8iQK374HoCQ&ved=0CAcQ_AUo
AQ&biw=1024&bih=498#q=diagrama%20de%20colaboracion%20interfaz&tbm=isch
http://www.slideshare.net/ece79/visual-basic-net-5186125
http://es.wikipedia.org/wiki/SQL
http://msdn.microsoft.com/es-es/library/ms187752.aspx
http://gotreportviewer.com/
164
ANEXOS
Modulo de Recetas el cual es para llevar el control de la cantidad de materia
prima (producto) que tienen los alimentos para sacar las existencias de la comida.
Imports System.Data.SqlClient Public Class frmRecetas
Dim conexion As New SqlConnection("data source=(local); initial catalog=LosEquipales; integrated security=true")
Private Sub btnNuevo_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnNuevo.Click 'Desabilita Cajas de texto cboComida.Enabled = True cboProducto.Enabled = True cboUnidad.Enabled = True mskCantidad.Enabled = True dgRecet.Rows.Clear() 'Carga la descripcion de las comidas registradas Dim comando As New SqlCommand("select Descripcion from Comidas", conexion) conexion.Open() Dim lector As SqlDataReader = comando.ExecuteReader While lector.Read cboComida.Items.Add(lector(0)) End While conexion.Close() 'carga la descripcion de la materia prima Dim comando1 As New SqlCommand("Select Descripcion from MateriaPrima", conexion) conexion.Open() Dim lector1 As SqlDataReader = comando1.ExecuteReader While lector1.Read cboProducto.Items.Add(lector1(0)) End While conexion.Close()
165
'limpia las cajas de texto txtComida.Text = "" cboComida.Text = "" cboProducto.Text = "" txtProducto.Text = "" mskCantidad.Text = "" cboUnidad.Text = "" 'Habilitar/Desabilita Botones btnGrabar.Enabled = True btnConsultar.Enabled = False btnNuevo.Enabled = False 'btnAgregar.Enabled = True End Sub Private Sub cboComida_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cboComida.SelectedIndexChanged ' se trae datos de la Comida y los muestra Dim comando As New SqlCommand("select Comidas.IdComida, Imagen from Comidas where Descripcion='" & cboComida.Text & "'", conexion) conexion.Open() Dim lector As SqlDataReader = comando.ExecuteReader comando.Parameters.AddWithValue("@id", Convert.ToString(cboComida.Text)) If lector.Read() Then txtComida.Text = lector(0) PictureBox1.Image = Image.FromFile(Convert.ToString(lector("Imagen"))) End If conexion.Close() cboComida.Enabled = False End Sub Private Sub cboProducto_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cboProducto.SelectedIndexChanged ' se trae datos de la materia prima (Producto) y los muestra Dim comando As New SqlCommand("select MateriaPrima.IdProducto from MateriaPrima where Descripcion='" & cboProducto.Text & "'", conexion) conexion.Open()
166
Dim lector As SqlDataReader = comando.ExecuteReader While lector.Read txtProducto.Text = lector(0) End While conexion.Close() End Sub Private Sub btnGrabar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnGrabar.Click try 'Graba Receta For x = 0 To dgRecet.Rows.Count - 2 Dim coman As New SqlCommand("INSERT INTO Recetas VALUES('" & txtComida.Text & "','" &dgRecet.Item(0, x).Value & "','" & dgRecet.Item(2, x).Value & "')", conexion) conexion.Open() coman.ExecuteNonQuery() conexion.Close() Next x MsgBox("Datos Guardados exitosamente") dgRecet.Rows.Clear() catch ex As Exception MsgBox("No se Puede insertar el registro", MsgBoxStyle.Critical, "Atención") End try 'Inhabilitar las cajas de texto txtComida.Enabled = False cboComida.Enabled = False cboProducto.Enabled = False txtProducto.Enabled = False mskCantidad.Enabled = False cboUnidad.Enabled = False
167
'limpia las cajas de texto txtComida.Text = "" cboComida.Text = "" cboProducto.Text = "" txtProducto.Text = "" mskCantidad.Text = "" cboUnidad.Text = "" 'habilita/Desabilita botones btnGrabar.Enabled = False btnConsultar.Enabled = True btnNuevo.Enabled = True 'btnAgregar.Enabled = False End Sub Private Sub btnConsultar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnConsultar.Click frmConsultaRecetas.ShowDialog() End Sub Private Sub btnAgregar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) 'agrega a la rejilla dgRecet.Rows.Add(txtProducto.Text, cboProducto.Text, mskCantidad.Text, cboUnidad.Text) 'si ya se eligio un producto o materia prima se elimana del combo cboProducto.Items.Remove(cboProducto.SelectedItem) mskCantidad.Text = "" cboProducto.Text = "" cboUnidad.Text = "" txtProducto.Text = "" End Sub
168
En la Figura 66. Se ilustra la nota de remisión del establecimiento.
Figura 66. Nota de remisión del establecimiento.