Desarrollo de una aplicación de gestión para una empresa de instalaciones eléctricas

Desarrollo de una aplicación de gestión para una empresa de instalaciones eléctricas Página 2 Página 3 Contenido INTRODUCCIÓN .................................................................................................................................. 7 MOTIVACIÓN ............................................................................................................................................... 7 DESCRIPCIÓN DEL PROBLEMA ........................................................................................................................... 7 OBJETIVOS DEL PROYECTO ............................................................................................................................... 8 BENEFICIOS .................................................................................................................................................. 8 MARCO TEÓRICO ............................................................................................................................... 9 LENGUAJE DE PROGRAMACIÓN......................................................................................................................... 9 Delphi ................................................................................................................................................... 9 Objetos, Componentes y controles .................................................................................................... 10 INTERBASE ................................................................................................................................................. 11 Administración de la base de datos: EMS SQL MANAGER ................................................................. 12 DISEÑO DE INFORMES: QUICKREPORT ............................................................................................................. 12 ARQUITECTURA DE LA APLICACIÓN: PROGRAMACIÓN POR CAPAS. ......................................................................... 15 DISEÑO DE LA BASE DE DATOS ........................................................................................................................ 18 Modelos de datos .............................................................................................................................. 19 El modelo entidad relación ................................................................................................................ 19 Entidad ............................................................................................................................................... 20 Relación ............................................................................................................................................. 20 Atributo .............................................................................................................................................. 21 Identificador ....................................................................................................................................... 22 INTERFAZ GRÁFICA DE USUARIO ...................................................................................................................... 22 DISEÑO DEL PROTOTIPO................................................................................................................................ 23 ESPECIFICACIÓN DE REQUISITOS SOFTWARE ..................................................................................... 26 INTRODUCCIÓN ........................................................................................................................................... 26 PROPÓSITO ................................................................................................................................................ 26 DESCRIPCIÓN GENERAL ................................................................................................................................. 27 Funciones del producto ...................................................................................................................... 27 Características del usuario ................................................................................................................. 28 REQUISITOS ESPECÍFICOS .............................................................................................................................. 28 Clientes .............................................................................................................................................. 29 Personas de contacto ......................................................................................................................... 31 Delegaciones ...................................................................................................................................... 32 Proveedores ....................................................................................................................................... 33 Albaranes ........................................................................................................................................... 35 Codigos Postales ................................................................................................................................ 35 Artículos ............................................................................................................................................. 36 Familia Artículo .................................................................................................................................. 37 Tipo Artículo ....................................................................................................................................... 38 Forma de pago ................................................................................................................................... 38 Obra ................................................................................................................................................... 38 Ofertas ............................................................................................................................................... 40 Pedidos .............................................................................................................................................. 41 CONCLUSIÓN .............................................................................................................................................. 42 DESARROLLO DE LA APLICACIÓN ....................................................................................................... 44 PLANIFICACIÓN ........................................................................................................................................... 44 Página 4 DISEÑO DE LA APLICACIÓN ............................................................................................................................ 45 Análisis de los requisitos .................................................................................................................... 45 Construcción del prototipo ................................................................................................................. 45 Diagrama de casos de uso ................................................................................................................. 46 Diagrama UML .................................................................................................................................. 47 Diagrama Entidad Relación ............................................................................................................... 47 GENERACIÓN DE INFORMES CON QUICKREPORT ................................................................................................ 48 PRUEBAS ................................................................................................................................................... 49 INSTALLSHIELD ........................................................................................................................................... 50 PUESTA EN MARCHA ................................................................................................................................... 50 CONCLUSIÓN .............................................................................................................................................. 50 EJEMPLO DE LA APLICACIÓN .............................................................................................................. 51 INTRODUCCIÓN ........................................................................................................................................... 51 ARRANCAR LA APLICACIÓN ............................................................................................................................ 52 INTRODUCCIÓN DE USUARIO Y CONTRASEÑA ..................................................................................................... 52 CREACIÓN DE UN PRESUPUESTO ..................................................................................................................... 54 CREACIÓN DE UN CLIENTE ............................................................................................................................. 55 CREACIÓN DE UNA OFERTA ............................................................................................................................ 56 CREACIÓN DE UN PROVEEDOR ........................................................................................................................ 57 CREACIÓN DE UN PEDIDO .............................................................................................................................. 58 CREACIÓN DE UN ALBARÁN ........................................................................................................................... 59 CREACIÓN DE UNA FACTURA .......................................................................................................................... 60 CONCLUSIÓN .............................................................................................................................................. 61 CONCLUSIONES ................................................................................................................................. 62 BENEFICIOS DEL PROYECTO ............................................................................................................................ 62 POSIBLES AMPLIACIONES .............................................................................................................................. 62 CONCLUSIONES ........................................................................................................................................... 63 REFERENCIAS .................................................................................................................................... 64 Página 5 Índice de figuras. FIGURA 1 HERENCIA EN DELPHI .......................................................................................................................... 10 FIGURA 2 PROGRAMACIÓN POR CAPAS ................................................................................................................ 16 FIGURA 3 COMPONENTES DE UN DIAGRAMA ENTIDAD-RELACIÓN ............................................................................. 20 FIGURA 4 FASES DE UN PROTOTIPO ..................................................................................................................... 24 FIGURA 5. PROTOTIPO EVOLUTIVO ..................................................................................................................... 25 FIGURA 6 PROTOTIPOS DESECHABLES .................................................................................................................. 25 FIGURA 7 DIAGRAMA DE USO ............................................................................................................................ 46 FIGURA 8 DIAGRAMA UML ............................................................................................................................... 47 FIGURA 9 DIAGRAMA ENTIDAD-RELACIÓN ........................................................................................................... 48 FIGURA 10 INTERFAZ QUICKREPORT ................................................................................................................... 49 FIGURA 11 EJEMPLO DE APLICACIÓN ................................................................................................................... 52 FIGURA 12 ICONO DE LA APLICACIÓN................................................................................................................... 52 FIGURA 13 LOGIN DE LA APLICACIÓN ................................................................................................................... 53 FIGURA 14 INTERFAZ PRINCIPAL DE LA APLICACIÓN ................................................................................................. 54 FIGURA 15 CREACIÓN DE UN PRESUPUESTO .......................................................................................................... 55 FIGURA 16 CREACIÓN DE UN CLIENTE .................................................................................................................. 56 FIGURA 17 CREACIÓN DE UNA OFERTA ................................................................................................................ 57 FIGURA 18 CREACIÓN DE UN PROVEEDOR ............................................................................................................ 58 FIGURA 19 CREACIÓN DE UN PEDIDO .................................................................................................................. 59 FIGURA 20 CREACIÓN DE UN ALBARÁN ................................................................................................................ 60 FIGURA 21 CREACIÓN DE UNA FACTURA .............................................................................................................. 61 Página 6 Página 7 Introducción En este capítulo se explican las motivaciones para realizar este proyecto, así como el problema que había antes de implantar la aplicación. También nombramos los posibles beneficios que la aplicación nos dará en un futuro. Motivación Este proyecto empezó con la idea de mejorar un sistema que, aunque funcionaba, no cubría las necesidades de la empresa. La empresa en la que se va a implantar se dedica a las instalaciones eléctricas. Para la gestión de dicha empresa utilizan diversas herramientas que no llegan a cubrir totalmente las necesidades. Por ello, se pensó en implantar un sistema de gestión que incluyese todo lo necesario para llevar una correcto control de todo. El proyecto consiste en el desarrollo de una aplicación que será implantada en una empresa de instalaciones eléctricas con la finalidad de informatizar la información que maneja dicha empresa y simplificar el proceso de gestión. Descripción del problema Los elementos principales del sistema de información de la empresa lo forman los artículos, los clientes y los proveedores. La empresa dispone actualmente de un listado de clientes, proveedores y artículos que la aplicación deberá incorporar. Adicionalmente, la aplicación deberá permitir añadir nuevos artículos, clientes y proveedores, así como modificar o eliminar los existentes. Cuando un cliente le encarga una obra a la empresa, la empresa determina los artículos necesarios para su realización y solicita una oferta a los proveedores. Tras estudiar las ofertas de los proveedores, la empresa selecciona la que mejor se adecua a sus necesidades y realiza el pedido. Junto con la recepción del pedido llega también un albarán de entrega, con el que se comprueba si el pedido es correcto o si por el contrario hay que hacer una devolución de dichos artículos. Los artículos recibidos pueden ser enviados a obra, donde se están realizando los trabajos, o al almacén de la empresa. Mediante un parte de almacén, en el que se especifican los artículos que se van a retirar, es posible posteriormente remitir a la obra un pedido guardado en el almacén. Todo este proceso debe quedar registrado en la aplicación: La aplicación debe poder almacenar todas las ofertas recibidas de los proveedores para facilitar a la empresa la toma de decisiones. Los pedidos realizados a los proveedores deben poder ser consultados para verificar que se reciben correctamente. Del mismo modo, deberán almacenarse Página 8 los albaranes y los partes de almacén para que todo el proceso quede adecuadamente controlado por la aplicación. Como puede observarse, una parte fundamental es el tratamiento eficiente de la información, por lo que será necesario diseñar una base de datos adecuada para la aplicación. Por otra parte, la aplicación también deberá tener conexión con diversos programas para poder leer documentos en formatos como por ejemplo: PDF, Excel, Word… Del mismo modo deberá proporcionar diversas plantillas con el logotipo de la empresa para poder utilizarlas en el envío de las ofertas y pedidos o para imprimirlos para su archivo. Objetivos del proyecto Esta aplicación tiene como objetivo implantar en la empresa un sistema que, en principio, controlará todo el proceso mencionado anteriormente, pero que posteriormente será ampliado con el fin de desarrollar muchos más aspectos que son necesarios para la empresa como, por ejemplo, control de empleados, vehículos, facturación, presupuestos… Beneficios La aplicación proporcionará los siguientes beneficios a la empresa: Realizar los procesos de gestión de la empresa con más rapidez y eficiencia, ya que se podrá realizar todo desde la misma aplicación. Utilizar una base de datos donde se almacenarán todos los datos tanto de clientes como de proveedores. Disponer de un sistema de consultas para revisar todo la información de la empresa. Generar informes rápidamente sin necesidad de realizar los cálculos a mano. Realizar una actualización eficiente de los precios de los artículos, gracias a un sistema de actualización cedido por los proveedores e integrado en la aplicación. Todo esto, junto con el hecho de poder ampliar la aplicación para nuevas necesidades, conforma los beneficios que dará el proyecto a la empresa. Página 9 Marco Teórico En esta parte se explican los conceptos estudiados para poder realizar esta aplicación. Se explica el lenguaje utilizado para su desarrollo, el tipo de bases de datos utilizado para almacenar la información, el generador de informe instalado y la arquitectura de la aplicación. Lenguaje de programación Un lenguaje de programación es un lenguaje artificial que puede ser usado para controlar el comportamiento de un ordenador. Este se compone de un conjunto de reglas sintácticas y semánticas que permiten expresar instrucciones que luego serán interpretadas. (1) El programador es el encargado de utilizar un lenguaje de programación para crear un conjunto de instrucciones que, al final, constituirá un programa o subprograma informático. Los lenguajes de programación pueden clasificarse en: procedimentales, orientados a objetos, funcionales, lógicos, híbridos, etc. En este proyecto vamos a utilizar el lenguaje de programación Delphi. Delphi Delphi es un entorno de desarrollo de software diseñado para la programación de propósito general con énfasis en la programación visual. Es producido comercialmente por la empresa estadounidense CodeGear (antes lo producía Borland), adquirida en mayo de 2008 por Embarcadero Technologies, una empresa del grupo Thoma Cressey Bravo. Delphi está basado en una versión de Pascal denominada Object Pascal. Borland en los últimos años defendía que el nombre correcto del lenguaje es también Delphi, posiblemente debido a pretensiones de marca, aunque en sus mismos manuales el nombre del lenguaje aparecía como Object Pascal, por lo que la comunidad de programadores no ha adoptado mayoritariamente este cambio (supuesta aclaración, según Borland). (2) Object Pascal expande las funcionalidades del Pascal estándar.: • Soporte para la programación orientada a objetos (habitualmente llamada POO) también existente desde Turbo Pascal 5.5, pero más evolucionada en cuanto a: • Encapsulación: declarando partes privadas, protegidas, públicas y publicadas de las clases. • Propiedades: concepto nuevo que luego han adaptado muchos otros lenguajes. Las propiedades permiten usar la sintaxis de asignación para setters y getters (en Delphi setters = write y getters = read). • Simplificación de la sintaxis de referencias a clases y punteros. Página 16 Figura 2 Programación por capas La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos. Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suele usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseño más en boga actualmente es el diseño en tres niveles (o en tres capas). Capas y niveles 1.- Capa de presentación: es la que ve el usuario (también se la denomina “capa de usuario”), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser “amigable” (entendible y fácil de usar) para el usuario. 2.- Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se Página 17 comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. 3.- Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos. En una arquitectura de tres niveles, los términos “capas” y “niveles” no significan lo mismo ni son similares. El término “capa” hace referencia a la forma como una solución es segmentada desde el punto de vista lógico: Presentación/ Lógica de Negocio/ Datos. En cambio, el término “nivel” corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo: Una solución de tres capas (presentación, lógica, datos) que residen en un solo ordenador (Presentación+lógica+datos). Se dice que la arquitectura de la solución es de tres capas y un nivel. Una solución de tres capas (presentación, lógica, datos) que residen en dos ordenadores (presentación+lógica, lógica+datos). Se dice que la arquitectura de la solución es de tres capas y dos niveles. Una solución de tres capas (presentación, lógica, datos) que residen en tres ordenadores (presentación, lógica, datos). La arquitectura que la define es: solución de tres capas y tres niveles. Página 18 Diseño de la base de datos Una base de datos correctamente diseñada permite obtener acceso a información exacta y actualizada. Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la base de datos, parece lógico emplear el tiempo que sea necesario en aprender los principios de un buen diseño ya que, en ese caso, es mucho más probable que la base de datos termine adaptándose a sus necesidades y pueda modificarse fácilmente. (7) En general, el objetivo del diseño de una base de datos relacional es generar un conjunto de esquemas de relaciones que permitan almacenar la información con un mínimo de redundancia, pero que a la vez faciliten la recuperación de la información. Una de las técnicas para lograrlo consiste en diseñar esquemas que tengan una forma normal adecuada. Para determinar si un esquema de relaciones tiene una de las formas normales se requiere mayor información sobre la empresa del "mundo real" que se intenta modelar con la base de datos. La información adicional la proporciona una serie de limitantes que se denominan dependencias de los datos. El diseño de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico. El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta información. El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto. El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el Página 19 diseño físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de datos. Modelos de datos Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de datos: los modelos conceptuales y los modelos lógicos. Los modelos conceptuales se utilizan para representar la realidad a un alto nivel de abstracción. Mediante los modelos conceptuales se puede construir una descripción de la realidad fácil de entender. En los modelos lógicos, las descripciones de los datos tienen una correspondencia sencilla con la estructura física de la base de datos. (8) En el diseño de bases de datos se usan primero los modelos conceptuales para lograr una descripción de alto nivel de la realidad, y luego se transforma el esquema conceptual en un esquema lógico. El motivo de realizar estas dos etapas es la dificultad de abstraer la estructura de una base de datos que presente cierta complejidad. Un esquema es un conjunto de representaciones lingüísticas o gráficas que describen la estructura de los datos de interés. Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades: Expresividad: deben tener suficientes conceptos para expresar perfectamente la realidad. Simplicidad: deben ser simples para que los esquemas sean fáciles de entender. Minimalidad: cada concepto debe tener un significado distinto. Formalidad: todos los conceptos deben tener una interpretación única, precisa y bien definida. En general, un modelo no es capaz de expresar todas las propiedades de una realidad determinada, por lo que hay que añadir aserciones que complementen el esquema. El modelo entidad relación El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. (9) Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido. Página 20 Figura 3 Componentes de un diagrama Entidad-Relación Entidad Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual. Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia depende de la existencia de otra entidad. Una entidad fuerte es una entidad que no es débil. Relación Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior. Las entidades que están involucradas en una determinada relación se denominan entidades participantes. El número de participantes en una relación es lo que se denomina grado de la relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si son tres las entidades participantes, la relación es ternaria; etc. Página 21 Una relación recursiva es una relación donde la misma entidad participa más de una vez en la relación con distintos papeles. El nombre de estos papeles es importante para determinar la función de cada participación. La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio. A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas, denominados trampas, suelen producirse a causa de una mala interpretación en el significado de alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende completamente el significado de cada relación. Si no se entienden las relaciones, se puede crear un esquema que no represente fielmente la realidad. Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de resolverla es reestructurando el esquema para representar la asociación entre las entidades correctamente. Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso, se produce una pérdida de información que se puede subsanar introduciendo la relación que sugería el esquema y que no estaba representada. Atributo Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen. Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos sobre un mismo dominio. Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que tiene un solo componente, que no se puede dividir en partes más pequeñas que tengan un significado propio. Un atributo compuesto es un Página 22 atributo con varios componentes, cada uno con un significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente mediante un óvalo. Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada ocurrencia de la entidad o relación a la que pertenece. Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente deben pertenecer a la misma entidad o relación. Identificador Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones: No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse. Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores. Interfaz gráfica de usuario La interfaz gráfica de usuario, conocida también como GUI (del inglés graphical user interface) es un programa informático que actúa de interfaz de usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. Su principal uso, consiste en proporcionar un entorno visual sencillo para permitir la comunicación con el sistema operativo de una máquina o computador. (10) Página 23 En el contexto del proceso de interacción persona-ordenador, la interfaz gráfica de usuario es el artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del lenguaje visual, una interacción amigable con un sistema informático. Interfaz gráfica de usuario es un tipo de visualización que permite al usuario elegir comandos, iniciar programas y ver listas de archivos y otras opciones utilizando las representaciones visuales (iconos) y las listas de elementos del menú. Las selecciones pueden activarse bien a través del teclado o con el ratón. (Véase Interfaz de usuario). Las interfaces gráficas de usuario ofrecen un entorno que se encarga de la comunicación con el ordenador o computadora. Esto hace que el programador pueda concentrarse en la funcionalidad, ya que no está sujeto a los detalles de la visualización ni a la entrada a través del ratón o del teclado. También permite a los programadores crear programas que realicen de la misma forma las tareas más frecuentes, como guardar un archivo, porque la interfaz proporciona mecanismos estándar de control como ventanas y cuadros de diálogo. Otra ventaja es que las aplicaciones escritas para una interfaz gráfica de usuario son independientes de los dispositivos: a medida que la interfaz cambia para permitir el uso de nuevos dispositivos de entrada y salida, como un monitor de pantalla grande o un dispositivo óptico de almacenamiento, las aplicaciones pueden utilizarlos sin necesidad de cambios. Diseño del prototipo Un prototipo es una representación limitada del diseño de un producto que permite a las partes responsables de su creación experimentar, probarlo en situaciones reales y explorar su uso. Un prototipo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo software En Ingeniería de software El Modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software. (11) El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para Página 24 satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto. A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en: Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos. Que el prototipo se descarte, al menos en parte. Que después se desarrolle el software real con un enfoque hacia la calidad. Un prototipo de software apoya dos actividades del proceso de ingeniería de requerimientos: Obtención de requerimientos: los usuarios experimentan como el sistema ayudará su trabajo. Validación de requerimientos: el prototipo puede revelar errores u omisiones en los requerimientos propuestos Figura 4 Fases de un prototipo Página 25 Existe gran diferencia entre los dos tipos de prototipos: El prototipo evolutivo entrega a los usuarios finales un sistema funcionando. Se usa con los requerimientos que mejor se comprenden. Figura 5. Prototipo Evolutivo El prototipo desechable valida o deriva los requerimientos del sistema. Se usa con los requerimientos que no se conocen bien. Período de vida corto Figura 6 Prototipos desechables Página 32 Proceso Se comprueba que el cliente exista en la base de datos. Salidas Actualización del registro o un mensaje informando que el cliente ya existe. Delegaciones Cuando una empresa no puede abarcar todo el territorio en el que actúa, tiene la necesidad de crear nuevos centros de trabajo para estar más próximos a sus clientes y así ofrecer un mejor servicio. A estos centros de trabajo se les llama Delegación. Desde el punto de vista de los clientes de J.A. Martínez Etayo sería para estar más cerca de sus obras y así controlar la dirección de la obra. Desde el punto de vista de proveedor para dar mejor servicio a sus clientes. Atributos Descripción Tipo Formato Ejemplo Código Número #(4) 1 Nombre Texto X(100) Peisa Gandía Observaciones Texto X(500) Nada Empresa Texto X(20) Peisa Operaciones Dar de alta un nueva delegación Entradas Datos de la delegación Proceso Se comprueba que la delegación no exista y se crea. Salidas Un nuevo registro o un mensaje de error. Eliminar una delegación Entradas Datos de la delegación Proceso Se comprueba que la delegación existe y se elimina. Salidas Se elimina el registro o un mensaje de error. Página 33 Modificar una delegación Entradas Datos de la delegación Proceso Se comprueba que la delegación exista y se actualizan los datos. Salidas Actualización del registro o un mensaje de error. Proveedores Los proveedores son quienes realizan la oferta y recibe el pedido para posteriormente ser servido a la empresa. Atributos Descripción Tipo Formato Ejemplo Código Número #(5) 1 Nombre Texto X(50) PEISA CIF Texto #X(8) B11225588 Domicilio Texto X(50) C/Zamarra Código_Postal Número #5 46900 Población Texto X(100) Xirivella Provincia Texto X(100) Valencia Fecha_Alta Fecha DD/MM/AA AA 12/02/2006 Email Texto X(100) [email protected] om Persona_Contac to Texto X(50) Ricardo Telefono_Conta cto Texto X(12) 96 111 11 15 Observaciones Texto X(300) Nada Página 34 Cuenta_Bancari a Texto X(50) La Caixa Teléfono1 Texto X(12) 96 111 11 22 Teléfono2 Texto X(12) 96 111 11 33 Fax Texto X(100) 96 111 11 11 Forma_Pago Texto X(4) CONT Delegacion Texto X(20) General Operaciones Crear un nuevo proveedor Entradas Datos del Proveedor Proceso Se comprueba que el proveedor no existe y se crea Salidas Se añade el registro o se emite un mensaje de error. Desactivar un Proveedor Entradas Datos del Proveedor Proceso Se comprueba que el proveedor existe y se pasa a la lista de desactivado. Salidas Desactivación del registro o se emite un mensaje de error. Modificar un proveedor Entradas Datos del Proveedor Proceso Se comprueba que el proveedor existe y se modifica. Salidas Actualización del registro o se emite un mensaje de error. Página 35 Albaranes Los albaranes sirven para comprobar que el pedido se ha recibido correctamente. Atributos Descripción Tipo Formato Ejemplo Código Texto X(20) 22474aa251 Num_Pedido Texto X(20) 125 Fecha Fecha DD/MM/AAAA 12/02/2008 Observaciones Texto X(300) Nada Proveedor Texto X(20) 9 Total_Albaran Número #(5) 23,25 Total_Pedido Numero #(5) 120,25 Operaciones Crear un nuevo albarán Entradas Datos del albarán Proceso Se comprueba que el albarán no se haya creado ya. Salidas Un nuevo albarán en la base de datos o un mensaje de error. Modificar un albarán Entradas Datos del albarán Proceso Se comprueba que el albarán ya exista y se modifica Salidas Actualización del albarán en la base de datos o un mensaje de error. Codigos Postales Los códigos postales se almacenan en una tabla para poder utilizarlos en varias partes de la aplicación. Atributos Página 36 Descripción Tipo Formato Ejemplo Código Número #(5) 46901 Provincia Texto X(100) Valencia Población Texto X(100) Torrent Operaciones Dar de alta un nuevo código postal Entradas Datos del código postal Proceso Se comprueba que el código postal no exista y se crea. Salidas Un nuevo registro o un mensaje de error. Artículos Los artículos conforman la parte principal de la base de datos. Se utilizan para realizar ofertas y pedidos. Atributos Descripción Tipo Formato Ejemplo Código Texto X(20) AEMS1000 Descripción Texto X(100) Caja de Electricidad Precio Número #(7) 20,02 Familia Texto X(20) AEMSA Operaciones Crear un nuevo artículo Entradas Datos del artículo Proceso Se comprueba que el artículo no se haya creado ya. Salidas Un nuevo artículo en la base de datos o un mensaje de error. Página 37 Modificar un artículo Entradas Datos del artículo Proceso Se comprueba que el artículo exista y se modifica. Salidas Actualización del artículo en la base de datos o un mensaje de error. Eliminar un artículo Entradas Fichero txt con los artículos Proceso Se comprueba que los artículos no existan y se crean los que no existen. Salidas Unos nuevos registros en la base de datos o aparece un mensaje de error. Eliminar un artículo Entradas Datos del artículo Proceso Se comprueba que el artículo exista y se elimina. Salidas El artículo eliminado de la base de datos o un mensaje de error. Familia Artículo Cada artículo pertenece a una familia para conseguir una mejor ordenación de los artículos. Atributos Descripción Tipo Formato Ejemplo Código Texto X(20) AEMSA Descripción Texto X(100) Aemsa Tipo Texto X(100) Electricidad Página 38 Tipo Artículo Cada artículo pertenece a una tipo para conseguir una mejor ordenación de los artículos. Atributos Descripción Tipo Formato Ejemplo Código Texto X(20) MANO Descripción Texto X(100) Mano de Obra Forma de pago Cada cliente y cada proveedor tienen distinta forma de pago. Atributos Descripción Tipo Formato Ejemplo Código Texto X(4) CHEQ Nombre Texto X(50) Cheque Operaciones Añadir una forma de pago Entradas Datos de la forma de pago Proceso Se comprueba que la forma de pago no exista y se crea. Salidas Un nuevo registro o un mensaje de error. Obra La obra se crea cuando un cliente acepta un presupuesto. Atributos Página 39 Descripción Tipo Formato Ejemplo Código Número #(5) 1 Nombre Texto X(100) URB. EL MOLI Fecha_Inicio Fecha DD/MM/AA AA 12/02/200 2 Dirección Texto X(100) C/Zamar ra Código_Postal Número #5 46900 Población Texto X(100) Xirivella Provincia Texto X(100) Valencia Fecha_Fin Fecha DD/MM/AA AA 12/02/200 6 Cliente Número #5 1 Técnico Texto X(100) Ricardo Jefe_Obra Texto X(100) Juan Observaciones Texto X(300) Nada Encargado_Obra Texto X(100) Pepe Teléfono_Jefe Texto X(12) 96 111 11 22 Teléfono_Encarga do Texto X(12) 96 111 11 33 Contrato Texto X(100) 182d.39 45 Archivo Texto X(100) Tercero Finalizada Texto X(1) S Operaciones Página 40 Crear una nueva obra Entradas Datos de la obra Proceso Se comprueba que la obra no exista y se crea Salidas Un nuevo registro o un mensaje de error. Modificar datos de una obra Entradas Datos de la obra Proceso Se comprueba que la forma de pago exista y se actualiza. Salidas Actualización del registro o un mensaje de error. Ofertas Las ofertas están formadas por una serie de artículos que son mandados a unos proveedores con el fin de recibir un precio del artículo. Atributos Descripción Tipo Formato Ejemplo Código Texto X(20) 11 Fecha Fecha DD/MM/AAAA 15/02/2005 Observaciones Texto X(100) Nada Operaciones Crear una nueva oferta Entradas Datos de la oferta Proceso Se comprueba que la oferta no existe y se crea Salidas Un nuevo registro o se emite un mensaje de error. Eliminar una oferta Entradas Datos de la oferta Proceso Se comprueba que la oferta existe y se elimina Página 41 Salidas Se elimina el registro o se emite un mensaje de error. Modificación de datos de una oferta Entradas Datos de la oferta Proceso Se comprueba que la oferta existe y se modifica Salidas Se actualiza el registro o se emite un mensaje de error. Pedidos Los pedidos son realizados a un proveedor una vez se ha recibido la oferta con los precios de los artículos. Atributos Descripción Tipo Formato Ejemplo Código Número #(5) 51 Proveedor Número #(5) 12 Fecha Fecha DD/MM/AAAA 12/02/2008 Observaciones Texto X(300) Nada Validado Texto X(1) N Total_Bruto Número #(5) 123,25 Total Número #(5) 120,25 Servido Texto X(1) S Obra Número #(5) 33 Artículo Texto X(8) AEMS1000 Oferta Número #(5) 12 Cliente Número #(5) 4 Operaciones Crear un nuevo Pedido Página 48 Figura 9 Diagrama Entidad-Relación Generación de informes con Quickreport Para realizar los distintos informes de la aplicación hemos utilizado el generador QuickReport, ya que tiene mucha diversidad de formatos y plantillas para realizar los informes. Los informes se guardan por defecto en formato .QRP pero tiene la opción de pasarlos a una gran variedad de formatos, como por ejemplo PDF, DOC, JPG… En la siguiente ilustración podemos ver el entorno visual de QuickReport. Página 49 Figura 10 Interfaz QuickReport Pruebas Las pruebas realizadas en la aplicación suponen un factor clave para comprobar el correcto funcionamiento. También nos sirven para definir mejor factores que creíamos que estaban correctos, así como nuevas posibles mejores de la aplicación. Para realizar las pruebas hemos comprobado si se han cumplido las restricciones que hemos puesto en los siguientes campos: • Campo Fecha: Solo se pueden introducir fechas en el siguiente formato DD/MM/AAAA • Campo Código Postal: Solo se puede introducir un número de 5 cifras. • Campo Teléfono Fax: Solo se pueden introducir un número de 9 cifras. También se han realizado las siguientes pruebas para comprobar que todo funcionaba correctamente: • Realizar inserciones en clientes, proveedores, obras, artículos… comprobando que se realizaban con éxito. • Intentar volver a insertar un cliente, proveedor, obra… que ya estaba insertado comprobando que no se podía realizar la inserción. • Realizar un pedido con artículos creados anteriormente y comprobar que posteriormente se podía buscar entre todos los pedidos. Página 50 • Borrar clientes, proveedores, obras… y comprobar que han desaparecido de la búsqueda. Una vez realizadas las pruebas, ya se puede integrar el sistema en la empresa. InstallShield Una vez hecha la aplicación tenemos que distribuirla por los puestos de trabajo. Esto se puede realizar de varias formas: • -Comprimir todos los archivos necesarios para la ejecución y luego descomprimirlos en el puesto de trabajo. • -Utilizar un programa externo para realizar esta operación. La mejor opción es utilizar un programa externo para que no nos falte ningún componente de la aplicación para instalar. Un ejemplo de programa es InstallShield X Express. Mediante este software podemos crear instalaciones que guían al usuario final en todas las etapas de la instalación. Puesta en Marcha Una vez integrado el sistema en la empresa se puso en marcha la aplicación y se hizo una demostración de su uso. Conclusión En este capítulo, he explicado los pasos a seguir para desarrollar la aplicación. Al tratarse del desarrollo de un sistema de información las fases de desarrollo coinciden con las etapas de desarrollo de software. Para realizar estas fases tuvo gran importancia los requisitos de la empresa para realizar el modelo de la aplicación. El paso siguiente fue la codificación en el que además de implementar toda las funciones de la aplicación, se desarrollan algunos componentes para generar informes. Finalmente, también fueron muy importantes las pruebas realizadas para comprobar que estaba todo correcto. Página 51 Ejemplo de la aplicación Introducción En este capítulo se verá una pequeña demostración de la aplicación ante un escenario de ejecución. Para esto, un ejemplo de uso puede ser el siguiente: Un cliente solicita un presupuesto Se da de alta el cliente si no estaba creado (5.4) Se crea un presupuesto. (5.3) Si el cliente lo acepta, se crean ofertas de material para enviárselo a los proveedores (5.5) Se crean los proveedores que no estén creados. (5.6) Página 52 Arrancar la aplicación Para entrar en la aplicación, hacemos doble clic en el icono de la aplicación. Figura 12 Icono de la aplicación En los siguientes apartados, se muestran algunos ejemplos de uso. Introducción de usuario y contraseña Una vez iniciada la aplicación, utilizaremos nuestro usuario y contraseña para entrar en la aplicación. Una vez recibida la oferta, se crea un pedido (5.7) Una vez realizado el pedido, se crea un albarán (5.8) Una vez realizada la obra, enviamos la factura al cliente. (5.9) Figura 11 Ejemplo de aplicación Página 53 Figura 13 Login de la aplicación Una vez validado el usuario y la contraseña, entramos en el interfaz principal. Página 54 Figura 14 Interfaz principal de la aplicación En esta pantalla, vemos todos los apartados a los que podemos acceder. Creación de un presupuesto Una vez creado el cliente, ya podemos crear el presupuesto para enviárselo al cliente. Página 55 Para esto, nos vamos a “PresupuestosNuevo”. Figura 15 Creación de un presupuesto Si no hemos creado el cliente anteriormente, podemos crearlo aquí. Creación de un cliente Para poder realizar un presupuesto a un cliente, antes hay que darlo de alta. Para ellos vamos a “ClientesNuevo”. Página 56 Figura 16 Creación de un cliente Como podemos observar, también nos da un código automático de cliente, que no es modificable. Rellenamos los datos y damos a Aceptar. Creación de una oferta Una oferta se envía a cada proveedor que queramos que lo valore. Para ello, vamos a OfertasNueva. Página 57 Figura 17 Creación de una oferta Una vez creado, damos a Aceptar. Creación de un proveedor Cuando se contacta con un proveedor para pedir material, hay que crearlo en la base de datos para que posteriormente se puedan realizar pedidos a ese proveedor. Para eso, vamos ProveedoresNuevo. Página 64 Referencias 1. (s.f.). Obtenido de Definición de lenguaje artificial: http://chislugo.com 2. (s.f.). Obtenido de Página web de software de embarcadero.: http://www.embarcadero.com/ 3. (s.f.). Obtenido de Interbase para programadores Delphi. Reyes, Pablo. 4. (s.f.). Obtenido de EMS SQL MANAGER: http://sqlmanager.net 5. (s.f.). Obtenido de Reflexiones sobre QuickReportSalvador Jove. 6. (s.f.). Obtenido de Programacion por capas: http://es.wikipedia.org 7. (s.f.). Obtenido de Diseño de bases de datos: www.monografias.com 8. (s.f.). Obtenido de El modelo relacional: http://usuarios.multimania.es 9. (s.f.). Obtenido de Modelo entidad-relacion: http://es.wikipedia.org 10. (s.f.). Obtenido de Interfaz gráfica de usuario: http://es.wikipedia.org 11. (s.f.). Obtenido de Prototipos en el diseño: http://albertolacalle.com