Anteproyecto Residencias

175
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

description

Documentación de una documento de residencias profesionales.

Transcript of Anteproyecto Residencias

Page 1: 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

Page 2: Anteproyecto Residencias
Page 3: Anteproyecto Residencias

Í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

Page 4: Anteproyecto Residencias

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

Page 5: Anteproyecto Residencias

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

Page 6: Anteproyecto Residencias

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

Page 7: Anteproyecto Residencias

Í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

Page 8: Anteproyecto Residencias

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.

Page 9: Anteproyecto Residencias

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.

Page 10: Anteproyecto Residencias

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.

Page 11: Anteproyecto Residencias

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

Page 12: Anteproyecto Residencias

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.

Page 13: Anteproyecto Residencias

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.

Page 14: Anteproyecto Residencias

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.

Page 15: Anteproyecto Residencias

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?

Page 16: Anteproyecto Residencias

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

Page 17: Anteproyecto Residencias

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.

Page 18: Anteproyecto Residencias

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.

Page 19: Anteproyecto Residencias

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.

Page 20: Anteproyecto Residencias

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.

Page 21: Anteproyecto Residencias

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.

Page 22: Anteproyecto Residencias

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).

Page 23: Anteproyecto Residencias

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.).

Page 24: Anteproyecto Residencias

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.

Page 25: Anteproyecto Residencias

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.

Page 26: Anteproyecto Residencias

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.

Page 27: Anteproyecto Residencias

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

Page 28: Anteproyecto Residencias

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.

Page 29: Anteproyecto Residencias

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.

Page 30: Anteproyecto Residencias

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.

Page 31: Anteproyecto Residencias

24

Figura 3. Ejemplo de un diagrama de contexto.

Page 32: Anteproyecto Residencias

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.

Page 33: Anteproyecto Residencias

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.

Page 34: Anteproyecto Residencias

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.

Page 35: Anteproyecto Residencias

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).

Page 36: Anteproyecto Residencias

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.

Page 37: Anteproyecto Residencias

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.

Page 38: Anteproyecto Residencias

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.

Page 39: Anteproyecto Residencias

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.

Page 40: Anteproyecto Residencias

33

En la Figura 5.1: se muestra un ejemplo de un diagrama de estados.

Figura 5.1: Ejemplo diagrama de estados.

Page 41: Anteproyecto Residencias

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.

Page 42: Anteproyecto Residencias

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.

Page 43: Anteproyecto Residencias

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.

Page 44: Anteproyecto Residencias

37

En la Figura 7.1: Se muestra un ejemplo de un diagrama de colaboración.

Figura 7.1: Ejemplo diagrama de colaboración.

Page 45: Anteproyecto Residencias

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.

Page 46: Anteproyecto Residencias

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.

Page 47: Anteproyecto Residencias

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.

Page 48: Anteproyecto Residencias

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.

Page 49: Anteproyecto Residencias

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.

Page 50: Anteproyecto Residencias

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.

Page 51: Anteproyecto Residencias

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.

Page 52: Anteproyecto Residencias

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).

Page 53: Anteproyecto Residencias

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.

Page 54: Anteproyecto Residencias

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.

Page 55: Anteproyecto Residencias

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.

Page 56: Anteproyecto Residencias

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.

Page 57: Anteproyecto Residencias

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.

Page 58: Anteproyecto Residencias

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.

Page 59: Anteproyecto Residencias

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).

Page 60: Anteproyecto Residencias

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

Page 61: Anteproyecto Residencias

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

Page 62: Anteproyecto Residencias

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.

Page 63: Anteproyecto Residencias

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.

Page 64: Anteproyecto Residencias

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),

)

Page 65: Anteproyecto Residencias

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‟)

Page 66: Anteproyecto Residencias

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‟

Page 67: Anteproyecto Residencias

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.

Page 68: Anteproyecto Residencias

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).

Page 69: Anteproyecto Residencias

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.

Page 70: Anteproyecto Residencias

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.

Page 71: Anteproyecto Residencias

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.

Page 72: Anteproyecto Residencias

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.

Page 73: Anteproyecto Residencias

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.

Page 74: Anteproyecto Residencias

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.

Page 75: Anteproyecto Residencias

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.

Page 76: Anteproyecto Residencias

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

Page 77: Anteproyecto Residencias

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.

Page 78: Anteproyecto Residencias

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.

Page 79: Anteproyecto Residencias

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

Page 80: Anteproyecto Residencias

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

Page 81: Anteproyecto Residencias

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

- & &= *

*= / /= \

\= ^ ^= +

+= = -=

Page 82: Anteproyecto Residencias

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”.

Page 83: Anteproyecto Residencias

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.

Page 84: Anteproyecto Residencias

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.

Page 85: Anteproyecto Residencias

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

Page 86: Anteproyecto Residencias

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.

Page 87: Anteproyecto Residencias

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.

Page 88: Anteproyecto Residencias

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

Page 89: Anteproyecto Residencias

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.

Page 90: Anteproyecto Residencias

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.

Page 91: Anteproyecto Residencias

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.

Page 92: Anteproyecto Residencias

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.

Page 93: Anteproyecto Residencias

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.

Page 94: Anteproyecto Residencias

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.

Page 95: Anteproyecto Residencias

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.

Page 96: Anteproyecto Residencias

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.

Page 97: Anteproyecto Residencias

90

Almacenes.

Clientes.

Empleados.

Comidas.

Bebidas.

Materia prima

Comandas.

Detalle bebida/ comida.

Recetas.

Entidades externas.

Empleados.

Page 98: Anteproyecto Residencias

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.

Page 99: Anteproyecto Residencias

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

Page 100: Anteproyecto Residencias

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”.

Page 101: Anteproyecto Residencias

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.

Page 102: Anteproyecto Residencias

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

Page 103: Anteproyecto Residencias

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.

Page 104: Anteproyecto Residencias

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.

Page 105: Anteproyecto Residencias

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.

Page 106: Anteproyecto Residencias

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.

Page 107: Anteproyecto Residencias

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.

Page 108: Anteproyecto Residencias

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.

Page 109: Anteproyecto Residencias

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.

Page 110: Anteproyecto Residencias

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.

Page 111: Anteproyecto Residencias

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

Page 112: Anteproyecto Residencias

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

Page 113: Anteproyecto Residencias

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

Page 114: Anteproyecto Residencias

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

Page 115: Anteproyecto Residencias

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

Page 116: Anteproyecto Residencias

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

Page 117: Anteproyecto Residencias

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

Page 118: Anteproyecto Residencias

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

Page 119: Anteproyecto Residencias

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

Page 120: Anteproyecto Residencias

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

Page 121: Anteproyecto Residencias

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

Page 122: Anteproyecto Residencias

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

Page 123: Anteproyecto Residencias

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).

Page 124: Anteproyecto Residencias

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).

Page 125: Anteproyecto Residencias

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).

Page 126: Anteproyecto Residencias

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).

Page 127: Anteproyecto Residencias

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).

Page 128: Anteproyecto Residencias

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).

Page 129: Anteproyecto Residencias

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).

Page 130: Anteproyecto Residencias

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).

Page 131: Anteproyecto Residencias

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).

Page 132: Anteproyecto Residencias

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).

Page 133: Anteproyecto Residencias

126

Diagrama de clases.

Page 134: Anteproyecto Residencias

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.

Page 135: Anteproyecto Residencias

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.

Page 136: Anteproyecto Residencias

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”.

Page 137: Anteproyecto Residencias

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

Page 138: Anteproyecto Residencias

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

Page 139: Anteproyecto Residencias

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

Page 140: Anteproyecto Residencias

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

Page 141: Anteproyecto Residencias

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

Page 142: Anteproyecto Residencias

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.

Page 143: Anteproyecto Residencias

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.

Page 144: Anteproyecto Residencias

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.

Page 145: Anteproyecto Residencias

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.

Page 146: Anteproyecto Residencias

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.

Page 147: Anteproyecto Residencias

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”.

Page 148: Anteproyecto Residencias

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.

Page 149: Anteproyecto Residencias

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.

Page 150: Anteproyecto Residencias

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.

Page 151: Anteproyecto Residencias

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.

Page 152: Anteproyecto Residencias

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.

Page 153: Anteproyecto Residencias

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.

Page 154: Anteproyecto Residencias

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.

Page 155: Anteproyecto Residencias

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.

Page 156: Anteproyecto Residencias

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.

Page 157: Anteproyecto Residencias

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.

Page 158: Anteproyecto Residencias

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.

Page 159: Anteproyecto Residencias

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.

Page 160: Anteproyecto Residencias

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.

Page 161: Anteproyecto Residencias

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.

Page 162: Anteproyecto Residencias

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.

Page 163: Anteproyecto Residencias

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.

Page 164: Anteproyecto Residencias

157

En la Figura 62. Se muestra la consulta general de materia prima.

Figura 62. Consulta general de materia prima.

Page 165: Anteproyecto Residencias

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.

Page 166: Anteproyecto Residencias

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.

Page 167: Anteproyecto Residencias

160

En la Figura 65. Se observa el reporte de compras en un período.

Figura 65. Reporte de compras en un período.

Page 168: Anteproyecto Residencias

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”.

Page 169: Anteproyecto Residencias

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

Page 170: Anteproyecto Residencias

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/

Page 171: Anteproyecto Residencias

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()

Page 172: Anteproyecto Residencias

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()

Page 173: Anteproyecto Residencias

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

Page 174: Anteproyecto Residencias

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

Page 175: Anteproyecto Residencias

168

En la Figura 66. Se ilustra la nota de remisión del establecimiento.

Figura 66. Nota de remisión del establecimiento.