DISEÑO Y DESARROLLO DE UN SISTEMA COMPUTACIONAL BASADO EN ...

1

DISEÑO Y DESARROLLO DE UN SISTEMA COMPUTACIONAL BASADO EN LA WEB QUE PERMITA CONTROLAR EL INVENTARIO Y LA FACTURACIÓN

DE VENTAS Y SERVICIOS DE LA EMPRESA CENTRO DE COMUNICACIONES MY SPACE

MILTON FERLEY RENTERIA FLOREZ

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRÁCTICAS ACADÉMICAS

PEREIRA 2011

2

DISEÑO Y DESARROLLO DE UN SISTEMA COMPUTACIONAL BASADO EN LA WEB QUE PERMITA CONTROLAR EL INVENTARIO Y LA FACTURACIÓN

DE VENTAS Y SERVICIOS DE LA EMPRESA CENTRO DE COMUNICACIONES MY SPACE

INFORME DE PRÁCTICA ACADÉMICA

MILTON FERLEY RENTERIA FLOREZ

TUTOR FRANCY NELLY LARGO MUÑOZ

INGENIERA DE SISTEMAS Y TELECOMUNICACIONES

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRÁCTICAS ACADÉMICAS

PEREIRA 2011

3

DEDICATORIA

Este proyecto lo dedico a mi familia que siempre me han apoyado en este difícil pero gratificante proceso de adquirir conocimiento. A mi padre y a mi madre por darme ejemplo de entereza y dedicación. Muchas gracias.

4

AGRADECIMIENTOS

Principalmente agradezco a mis padres por el apoyo incondicional que me han brindado a lo largo de mi proceso educativo y por ser los pilares que sostienen mi ánimo en lo más alto. Agradezco a mi tutora de proyecto y a mi jefe inmediato por su colaboración. Agradezco a la Universidad Católica de Pereira por darme la oportunidad de adquirir nuevos conocimientos al lado de sus excelentes docentes. Agradezco a mis amigos por apoyarme a seguir adelante con este proyecto.

5

TABLA DE CONTENIDO

Pág.

SÍNTESIS ................................................................................................................ 9

INTRODUCCIÓN .................................................................................................. 10

1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA ............ 11

1.1. RESEÑA HISTÓRICA .............................................................................. 11

1.2. MISIÓN .................................................................................................... 11

1.3. VISIÓN ..................................................................................................... 11

1.4. VALORES DE LA ORGANIZACIÓN ........................................................ 11

1.5. SERVICIOS .............................................................................................. 12

2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN ...................................... 13

3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN O IDENTIFICACIÓN DE

LAS NECESIDADES ............................................................................................. 14

3.1. REQUERIMIENTOS POR PARTE DEL CLIENTE ................................... 14

3.2. REQUERIMIENTOS POR PARTE DEL INGENIERO .............................. 14

4. EJE DE INTERVENCIÓN ............................................................................... 16

5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN ........................................... 17

6. OBJETIVOS .................................................................................................... 18

6.1. OBJETIVO GENERAL ............................................................................. 18

6.2. OBJETIVOS ESPECÍFICOS .................................................................... 18

7. MARCO TEÓRICO ......................................................................................... 19

7.1. MODELO DE REQUISITOS ..................................................................... 19

7.2. MODELO DE CASOS DE USO ............................................................... 20

7.2.1. Documentación .................................................................................. 20

7.3. MODELO DE ANÁLISIS ........................................................................... 20

7.3.1. Arquitectura de Clases ...................................................................... 21

7.3.2. Identificación de Clases según Estereotipos ..................................... 21

7.3.3. Clases según Casos de Uso ............................................................. 22

6

7.3.4. Diagramas de Secuencias ................................................................. 22

7.4. MODELO DE DISEÑO ............................................................................. 23

7.5. ESTRATEGIAS DE DISEÑO ................................................................... 23

7.5.1. Arquitectura ....................................................................................... 24

7.5.2. Robustez ........................................................................................... 24

7.5.3. Reuso ................................................................................................ 24

7.5.4. Extensibilidad..................................................................................... 24

7.6. DISEÑO DE OBJETOS ............................................................................ 25

7.7. DISEÑO DE BASES DE DATOS ............................................................. 25

7.7.1. Etapas del diseño de bases de datos ................................................ 25

7.7.2. El Modelo de Datos Entidad-Relación (E/R) ...................................... 26

Entidades y Relaciones ............................................................................... 27

Representación gráfica de Entidades y Relaciones .................................... 28

7.7.3. Herramienta de diseño de bases de datos relacionales .................... 28

7.8. IMPLEMENTACIÓN ................................................................................. 29

7.8.1. Gestor de bases de datos .................................................................. 29

7.8.2. Lenguaje de programación ................................................................ 30

7.8.3. Herramientas de desarrollo web ........................................................ 30

7.8.4. Modelo de ciclo de vida ..................................................................... 32

7.8.5. Definición de un Modelo de Ciclo de Vida. ........................................ 32

7.9. MODELO DE PRUEBAS .......................................................................... 33

7.9.1. Tipos de Pruebas ............................................................................... 34

8. CRONOGRAMA DE ACTIVIDADES PLANEADAS ........................................ 35

9. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS ........................................ 36

9.1. JUSTIFICACIÓN DEL MODELO DE CICLO DE VIDA ELEGIDO ............ 36

9.2. JUSTIFICACIÓN DEL ENFOQUE METODOLÓGICO ELEGIDO ............ 36

9.3. REQUERIMIENTOS DEL SOFTWARE ................................................... 37

9.3.1. Identificación y clasificación de requerimientos ................................. 37

9.4. ACTORES Y CASOS DE USO ................................................................ 38

9.4.1. Actores .............................................................................................. 38

7

9.5. DISEÑO DE DATOS ................................................................................ 47

9.5.1. Modelo Relacional ............................................................................. 47

9.5.2. Modelo lógico entidad relación .......................................................... 48

9.5.3. Modelo Físico de datos ...................................................................... 49

9.6. DESARROLLO DE LA INTERFACE WEB ............................................... 52

9.6.1. Validación de usuario pantalla P-0 .................................................... 52

9.6.2. Ingreso Administrador pantalla P-1 .................................................... 56

9.6.3. Registro Usuario pantalla P-4 ............................................................ 59

Código Pantalla P-4 ................................................................................. 59

9.6.4. Actualizar empleado .......................................................................... 62

10. CONCLUSIONES ........................................................................................ 68

11. RECOMENDACIONES ............................................................................... 69

REFERENCIAS BIBLIOGRAFICAS ...................................................................... 70

APENDICE ............................................................................................................ 72

8

TABLA DE ILUSTRACIONES

ILUSTRACIÓN 1 Representación relaciones ........................................................ 28

ILUSTRACIÓN 2. Representación general del sistema ........................................ 38

ILUSTRACIÓN 3. Modelo relacional ..................................................................... 47

ILUSTRACIÓN 4. Entidad relación ........................................................................ 48

ILUSTRACIÓN 5. Pantalla P-0 .............................................................................. 52



ILUSTRACIÓN 8. Actualizar empleado ................................................................. 62

9

SÍNTESIS

SÍNTESIS Se pretende desarrollar un software hecho a medida que supla las necesidades contables de la empresa Centro de Comunicaciones My Space. Para lograrlo se utilizarán varias herramientas de desarrollo tales como: Dreamweaver CS3 para el diseño de la interfaz WEB, MySQL Workbench para diseñar la base de datos relacional, HeidiSQL el cual gestionará la base datos que será construida en el sistema de gestión de bases de datos MySQL, cuya interfaz grafica será construida con el lenguaje de programación PHP. Con la utilización estas herramientas de desarrollo se pretende generar una aplicación estable que optimice los procesos contables de la empresa. Descriptores: MySQL, SQL, PHP, Bases de datos, Workbench, desarrollo de software, diseño de bases de datos.

ABSTRACT To develop a custom software that meets the needs company accounting My Space Communications Center. To achieve this use various development tools such as Dreamweaver CS3 for WEB interface design, MySQL Workbench to design the database relational, HeidiSQL which manage the database to be built inmanagement system MySQL, which will be built GUI with the programming language PHP. By using these tools development aims to generate a stable application that optimizes processes company accounting. Keywords: MySQL, SQL, PHP, Databases, Workbench, software development, database design.

10

INTRODUCCIÓN

La empresa Centro de Comunicaciones My Space necesita mejorar el manejo del inventario de los productos y la facturación, ya que este manejo actualmente se lleva de manera rudimentaria e ineficiente, esto produce constantes errores humanos que afectan el adecuado funcionamiento de la empresa, generando información errónea sobre el estado actual de los inventarios, o el estado de la facturación, lo que conlleva a cometer errores en la toma de decisiones por parte la administración, y también provoca demoras en los procesos contables y de verificación de los estados de resultados, la anterior información resulta ser muy importante para la continuidad de la empresa. Por lo anterior, se decide construir un software hecho a medida que satisfaga las necesidades contables de la empresa y optimice el manejo de los inventarios y la facturación, dicho software deberá ser accesible vía web.

11

1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA

1.1. RESEÑA HISTÓRICA El Centro de comunicaciones My Space nace el 18 de marzo de 2007 debido a la necesidad que tenia la población del municipio de Alcalá (Valle del Cauca) de acceder a las tecnologías de la información y las comunicaciones buscando aumentar su progreso y desarrollo, ya que muchas personas no poseen la capacidad económica para pagar una mensualidad por la conexión a internet y mucho menos para adquirir un computador, por esto se ven en la necesidad de ir a los café internet para alquilar los computadores con acceso a internet a un precio cómodo . El principal objetivo de la empresa era posicionarse como el mejor café internet del municipio, lugar que no demoró en ocupar ya que fue el primer café internet del municipio que ofreció internet banda ancha. En la actualidad la empresa sigue con la idea de innovar y ofrecer servicios de calidad. En octubre de 2008 debido al éxito alcanzado en el municipio de Alcalá la empresa decidió ampliar sus horizontes y abrió otra sede en la ciudad de Ansermanuevo (Valle del Cauca) en la cual siguió con la estrategia de combinar un excelente servicio con una buena atención y en poco tiempo se ubicó como el mejor café internet de Ansermanuevo, actualmente la empresa tiene como proyecto a corto plazo abrir dos nuevas sedes, una en Quimbaya (Quindío) y otra en Ulloa (Valle del cauca).

1.2. MISIÓN Ofrecer servicios de calidad brindando a nuestros clientes internet de alta velocidad y equipos eficientes que les permitan realizar sus actividades sin contratiempos, además se le brinda asesoría personalizada y oportuna al momento de utilizar alguno de nuestros servicios.

1.3. VISIÓN Ubicar nuevas sedes en municipios de la región en los que exista la necesidad de contratar servicios de calidad.

1.4. VALORES DE LA ORGANIZACIÓN Definimos los valores de la organización como aquellos que deben distinguir nuestra empresa y guiar la actuación y desempeño de cada integrante del grupo de trabajo que la conforma. Los 7 Principios básicos enfocados en garantizar la calidad de nuestros servicios y la distinción de la empresa son:

- SERVICIO

12

- ATENCIÓN - CALIDAD - EFICIENCIA - INNOVACIÓN - CONSTANCIA - COMPETITIVIDAD

1.5. SERVICIOS

La empresa tiene como objeto principal la prestación de servicios de internet y llamadas nacionales e internacionales. Actualmente la empresa ofrece los siguientes productos y servicios:

- Acceso a internet Banda ancha de hasta 10 Mbps de velocidad - Servicio de llamadas nacionales e internacionales - Servicio de FAX nacional e internacional - Impresiones a blanco y negro y a color - Servicio de escáner - Recargas en línea a celulares - Copia de CD y DVD - Video conferencia - Venta de computadores, partes y accesorios - Venta de memorias USB, CD y DVD - Mantenimiento Preventivo y correctivo de computadores (outsourcing)

13

2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su posterior uso, generados para cubrir una necesidad (objetivo). Dichos elementos formarán parte de alguna de estas categorías:

- Personas. - Datos. - Actividades o técnicas de trabajo. - Recursos materiales en general (típicamente recursos informáticos y de

comunicación, aunque no tienen por qué ser de este tipo obligatoriamente).

Todos estos elementos interactúan entre sí para procesar los datos (incluyendo procesos manuales y automáticos) dando lugar a información más elaborada y distribuyéndola de la manera más adecuada posible en una determinada organización en función de sus objetivos. De acuerdo a la definición anterior y observando las tareas que se desarrollarán en la práctica queda claro que la línea de intervención que se abordará en el proceso de práctica académica será Sistemas de Información.

14

3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN O IDENTIFICACIÓN DE LAS NECESIDADES

La empresa en la actualidad lleva su contabilidad por medio de la aplicación Microsoft Office Excel, dicha contabilidad se realiza de la siguiente manera: las empleadas de cada sede todas las mañanas llenan un formato de Excel en el cual registran las ventas de los diferentes artículos y servicios, como también los gastos, créditos y pagos del día anterior, luego lo envían por correo electrónico a la encargada de la contabilidad, la cual pasa esos datos a otro documento de Excel en el cual realizan los cálculos correspondientes para realizar el cuadre de caja y verificar si las cuentas están bien, al mismo tiempo se actualizan los inventarios y se decide si hay que reabastecer de insumos o productos a alguna de las sedes. A vuelta de correo la encargada de la contabilidad informa a las empleadas de cada sede de los errores que tuvieron y de los reportes que arrojó la actualización de inventarios. Al tiempo se le envía un informe al gerente por correo electrónico con la información necesaria para tomar decisiones con respecto al funcionamiento de la empresa. El levantamiento de los requerimientos se realizó entrevistando directamente a los encargados del área de contabilidad.

3.1. REQUERIMIENTOS POR PARTE DEL CLIENTE El área de contabilidad necesita verificar en tiempo real el estado de los diferentes productos y servicios que se prestan en las sedes.

Llevar el control de inventario y ventas en tiempo real.

Será accesible desde internet.

Sea de fácil manejo y pueda ser manipulado por una sola persona.

Envíe informes de inventario y ventas por correo electrónico al gerente.

Consulta de informes en cualquier momento.

Informar de inmediato a cada cajera en la mañana el estado de los servicios antes de iniciar las actividades (- estado de los planes de minutos: se van a acabar ó todavía quedan muchos, llamar de determinada cabina. - estado de las recargas a móviles: cuánto dinero debe haber, cuadre de recargas. - estado del inventario: que productos necesitan pedido).

Llevar la información de los clientes que poseen crédito e informar cuales están pasados de tiempo, o cantidad de dinero.

3.2. REQUERIMIENTOS POR PARTE DEL INGENIERO

El aplicativo será desarrollado por módulos. El acceso al aplicativo será controlado a través de un usuario y contraseña, el cual tendrá asociado un nivel de acceso a los diferentes módulos.

La organización deberá suministrar un equipo en donde tendrá instalado el servidor WEP y la base de datos

15

La organización debe contar con los medios de acceso que le permitan a cada una de sus sedes acceder a internet, además de poseer una IP pública o dominio para acceder a la aplicación.

16

4. EJE DE INTERVENCIÓN El proceso anterior es redundante, lento y algo rudimentario, la empresa ha probado diferentes aplicaciones de contabilidad que existen en el mercado con el fin de optimizar este proceso pero no se encontró alguno que cumpliera con los requerimientos. La falta de información a tiempo le produce pérdidas de dineros considerables a la empresa.

17

5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN La gestión de una empresa tiene un rol importante en su estabilidad y eficiencia al tiempo que de ella depende la obtención de buenos resultados. Una buena gestión requiere de actividades de control, seguimiento y medición, para tener un derrotero de las acciones a tomar de acuerdo con la información obtenida y a si tomar decisiones confiables que permitan lograr una eficacia administrativa y productiva. El producto que se pretende generar será una aplicación web echa a la medida que supla las necesidades de contabilidad de la empresa, la cual registre en tiempo real las ventas, gastos y diferentes registros que los administradores de cada sede realizan todos los días al tiempo que actualiza los inventarios, muestra informes y envía datos del funcionamiento de la empresa al gerente.

18

6. OBJETIVOS

6.1. OBJETIVO GENERAL Diseñar y desarrollar un sistema computacional basado en la web que permita controlar el inventario y la facturación de las ventas y servicios

6.2. OBJETIVOS ESPECÍFICOS

Analizar y comprender la situación problemática que se presenta.

Elegir un modelo ciclo de vida del software apropiado para abordar cada una de las etapas del proyecto.

Elegir una metodología de ingeniería del software para el desarrollo del proyecto.

Elegir y aplicar las herramientas de programación y la base de datos a emplear para el desarrollo de la aplicación.

Elaborar el manual de uso del sistema.

19

7. MARCO TEÓRICO

7.1. MODELO DE REQUISITOS El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo. El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso. (Weitzenfeld, 2002) Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí: - Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante. - Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación. - Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más. - Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación. - Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración. - Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc. (Weitzenfeld, 2002)

20

7.2. MODELO DE CASOS DE USO El modelo de casos de uso describe un sistema en término de sus distintas formas de utilización, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarán cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automóvil sería la secuencia de eventos desde que el conductor entra en el coche encendiendo el motor hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso de un sistema primero es necesario saber quiénes son sus usuarios. Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente. Para ello se define el concepto de actor, correspondiente al tipo de usuario que está involucrado en la utilización de un sistema, siendo el actor una entidad externa al propio sistema. Juntos, el actor y el caso de uso representan los dos elementos básicos de este modelo lo cual se muestran de manera gráfica de acuerdo a la notación UML. (Weitzenfeld, 2002)

7.2.1. Documentación Parte fundamental del modelo de casos de uso es una descripción textual detallada de cada uno de los actores y casos de uso identificados. Estos documentos son sumamente críticos ya que a partir de ellos se desarrollará el sistema completo. (Weitzenfeld, 2002)

7.3. MODELO DE ANÁLISIS Cuando ya se ha desarrollado y aceptado el modelo de requisitos se comienza el desarrollo del modelo de análisis. El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementación, lo cual incluye al lenguaje de programación, manejador de base de datos, distribución o configuración de hardware, etc. En otras palabras el análisis pretende modelar el sistema bajo condiciones ideales, garantizando que la arquitectura de software resultante se suficientemente robusta y extensible para servir de base a la estructura lógica de la aplicación pero sin consideraciones relativas al entorno de implementación que es posible que cambien incluso radicalmente. Tarde o temprano el sistema tendrá que ser adaptado a las condiciones de implementación deseadas, algo que se hará durante el diseño, cuando todas las consideraciones que han sido descartadas durante el análisis sean consideradas. Es importante enfatizar que el modelo de análisis no es una reflexión del dominio del problema sino una representación de ésta adaptada a la aplicación particular. El modelo de análisis genera una representación conceptual del sistema, consistiendo de clases de objetos. Cada una de las clases de objetos contribuye de manera especial para lograr la robustez de la arquitectura. (Weitzenfeld, 2002)

21

7.3.1. Arquitectura de Clases El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas bordes de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura. En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de bordes y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sola dimensión. (Weitzenfeld, 2002)

7.3.2. Identificación de Clases según Estereotipos Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos como se discutió anteriormente. Para lograr esto se debe identificar primero las clases borde, luego las entidad y finalmente las de control. En general, se desea asignar la funcionalidad más especializada correspondiente a la “política” de la aplicación a los objetos control, la cual depende y afecta al resto de los objetos. Por otro lado, los objetos entidad e borde deben contener funcionalidad más bien local limitando su efecto en los demás objetos. El trabajo del analista consiste en distribuir lo mejor posible el comportamiento especificado en el modelo de requisitos en los diferentes tipos de objetos de la arquitectura de análisis. La asignación de funcionalidad es bastante difícil en la práctica afectando de gran manera la robustez y mantenimiento del sistema. Los buenos analistas consideran cambios potenciales al sistema a la hora de llevar a cabo este proceso. En general, los cambios más comunes a un sistema son los cambios en su funcionalidad e bordes. Cambios a las bordes deben afectar típicamente solo los objetos borde. Cambios a la funcionalidad son más difíciles, ya que la funcionalidad puede abarcar todos los tipos de objetos. Si la funcionalidad está ligada a la información existente, tales cambios afectan al objeto entidad representando esa información, o puede involucrar múltiples objetos incluyendo objetos control. Típicamente, esta funcionalidad se define en uno o varios casos de uso y se asigna a uno o varios objetos control. (Weitzenfeld, 2002)

22

7.3.3. Clases según Casos de Uso En estos diagramas incluiremos de manera preliminar asociaciones y multiplicidad. Para simplificar este proceso de asignación de asociaciones y para ser consistentes entre diagramas, asignaremos a la clase control de cada caso de uso como el “centro de las comunicaciones” para todas las clases borde y entidad pertenecientes al mismo caso de uso. Estas clases borde y entidad no estarán asociadas entre sí por el momento. Asimismo asociaremos entre sí a las clases control utilizadas en el caso de uso. Y finalmente se asociarán todas las clases borde correspondiente a pantallas con la clase InterfaceUsuario. Nótese que sólo se incluyen las clases bordes correspondientes a pantallas que se consideren “esenciales” para el caso de uso, en otras palabras aquellas que implementan los flujos principales pero no tanto ligas adicionales de navegación entre pantallas. En relación a la multiplicidad, asignaremos todas las asociaciones como de “uno-uno” con excepción de las relaciones entre clases entidades que se mantendrán de acuerdo al dominio del problema y entre clases control y clases entidad donde por lo general será “uno-muchos”. La razón para esto es que típicamente sólo se requiere una instancia de cada clase control e borde para implementar el caso de uso, mientras que las clases entidad se instancian múltiples veces ya que corresponden a diversas instancias de información, como por ejemplo, múltiples usuarios. Como veremos en la sección de diagramas de interacción más adelante en el capítulo, a partir de estas relaciones estamos forjando la lógica de control del caso de uso. (Weitzenfeld, 2002)

7.3.4. Diagramas de Secuencias Una vez identificadas las clases anteriores, proseguimos describiendo los casos de uso del modelo de requisitos según la lógica que deberán presentar estas clases para lograr la funcionalidad descrita en los diversos casos de uso. Este es un paso muy importante ya que en base a la lógica propuesta para esta descripción, definiremos la arquitectura de análisis tanto estructural como funcional. Dada la complejidad y la importancia de estas descripciones, es importante probar las secuencias funcionales de los casos de uso flujos revisar qué tan bien nuestra lógica y arquitectura de clase resuelve la funcionalidad establecida. Para eso introducimos el concepto de diagramas de secuencias, interacción o eventos, los cuales describen como los diferentes casos de uso son implementados mediante los objetos de nuestra arquitectura recién generados. Los diagramas correspondientes muestran la interacción entre los objetos participantes a nivel de eventos que se envían entre si, excluyendo cualquier detalle interno de ellos. El formato de un diagrama de secuencia se muestra en la nótese que es un diagrama exclusivamente de objetos y no de clases. Sin embargo, los objetos son instancias de clases que al no tener ningún nombre particular se muestran a través del nombre de la clase subrayada y con el prefijo de “:”, correspondiente a la notación para diagramas de objetos. (Weitzenfeld, 2002)

23

7.4. MODELO DE DISEÑO El modelo de diseño es un refinamiento y formalización adicional del modelo de análisis donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficientemente formal para poder llegar al código fuente. Por tal motivo se debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la comunicación entre los diferentes objetos, los eventos que los objetos envían entre sí, etc. El sistema real debe adaptarse al ambiente de implementación. En el análisis se asume un mundo ideal para el sistema, en la realidad se debe adaptar el sistema al ambiente de implementación, algo que puede cambiar durante el ciclo de vida del sistema. Se busca además aspectos como, los requisitos de rendimiento, necesidades de tiempo real, concurrencia, el lenguaje de programación, el sistema de manejo de base de datos, etc. Se desea también validar los resultados del análisis. Según el sistema crece y se formaliza, se verá qué tan bien los modelos de requisitos y análisis describen al sistema. Durante el diseño, se puede ver si los resultados del análisis son apropiados para su implementación. Si se descubre aspectos que no están claros en alguno de los modelos anteriores, estos deben ser clarificados, quizás regresando a etapas anteriores. Aunque esto pudiera verse como deficiencias del resultado de las fases anteriores que deben ser clarificadas aquí, esto sería una visión incorrecta de las diferentes etapas del desarrollo, ya que el propósito de los modelos de requisitos y análisis es comprender el sistema y darle una buena estructura. También es importante comprender que las consideraciones tomadas en cuenta durante el diseño deben influir en la estructura del sistema lo menos posible. Es la propia aplicación la que controla la estructura, no las circunstancias de su implementación. Se considera el modelo de diseño como una formalización del espacio de análisis, extendiéndolo para incluir una dimensión adicional correspondiente al ambiente de implementación. (Weitzenfeld, 2002)

7.5. ESTRATEGIAS DE DISEÑO Antes de poder resolver el diseño es necesario tomar decisiones generales sobre las estrategias de diseño a seguir.

24

Algunas de las decisiones a tomar se presentan a continuación y se relacionan con aspectos que incluyen la arquitectura, robustez, reuso y extensibilidad del sistema. (Weitzenfeld, 2002)

7.5.1. Arquitectura El término arquitectura se refiere, en nuestro caso, a la organización de las clases dentro del sistema. Durante el modelo de análisis se generó una arquitectura de clases para el sistema y se definió la funcionalidad “conceptual” ofrecida por las distintas clases dentro de la arquitectura. Durante el diseño esta arquitectura debe detallarse pudiéndose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada clase, e incluso las propias clases. El conocimiento y funcionalidad asignada a cada clase puede ser vista como la “inteligencia” de cada clase dentro del sistema. En otras palabras, algunas clases pueden ser vistas como más inteligentes que otras según el conocimiento y control que tengan sobre las demás clases. Por ejemplo, colecciones de objetos tales como listas o arreglos, no se consideran como particularmente inteligentes ya que pueden manipular y obtener información sobre las clases que almacenan, pero tienen relativamente poco impacto sobre estas u otras clases dentro del sistema. Por otro lado, un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la interacción con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase aún más inteligente es el controlador o manejador de la lógica completa de la aplicación, ya que es responsable de administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema. (Weitzenfeld, 2002)

7.5.2. Robustez La robustez de un sistema debe ser uno de los objetivos principales del diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego sean removidas durante la producción. En general se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones. (Weitzenfeld, 2002)

7.5.3. Reuso El reuso es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema. (Weitzenfeld, 2002)

7.5.4. Extensibilidad La mayoría de los sistemas son extendidos en manera no prevista por el diseño original. Por lo tanto, los componentes reutilizables mejorarán también la extensibilidad. (Weitzenfeld, 2002)

25

7.6. DISEÑO DE OBJETOS El diseño de objetos es un proceso de añadir detalles al análisis y tomar decisiones junto con diseño de sistema, o sea al ambiente de implementación, de manera que podamos lograr una especificación detallada antes de comenzar la implementación final. Algunos de los aspectos a ser resueltos diseño de objetos son determinar cómo las clases, atributos y asociaciones del modelo de análisis deben implementarse en estructuras de datos específicas. También es necesario determinar si se requiere introducir nuevas clases en el modelo de diseño para los cuales no se tiene ninguna representación en el modelo de análisis o si se requiere modificar o eliminar clases identificadas durante el modelo de análisis. Se debe agregar herencia para incrementar el reuso del sistema. También es necesario determinar los algoritmos para implementar las operaciones, así como todos los aspectos de optimizaciones. Para el diseño de objeto se seguirá el diseño por responsabilidades (RDD - Responsibility-Driven Design). Este diseño está basado en un modelo cliente-servidor donde las clases son vistas como clientes cuando generan alguna petición hacia otra clase y como servidores cuando reciben peticiones de alguna otra clase. De tal manera, una misma clase puede ser vista en distintos momentos como cliente o servidor. La funcionalidad ofrecida por las clases servidores se define en término de sus responsabilidades, las cuales deben ser satisfechas por lograr sus servicios con las demás clases. Los servicios y responsabilidades corresponderán finalmente a los métodos de la clase. A su vez, las clases servidores a su vez pueden tener colaboraciones con otras clases para lograr la satisfacción de responsabilidades que por sí solas no pueden lograr. Como consecuencia de esto, se integran las responsabilidades y colaboraciones entre clases para definir contratos los cuales definen la naturaleza y alcance de las interacciones cliente-servidor. Los contratos y colaboraciones representan los requisitos de servicios entre los objetos. En resumen, se buscará identificar los contratos entre los objetos cliente y servidor diseñando su distribución entre los distintos objetos del sistema. (Weitzenfeld, 2002)

7.7. DISEÑO DE BASES DE DATOS El diseño de una base de datos consiste en definir la estructura de los datos que debe tener la base de datos de un sistema de información determinado. En el caso relacional, esta estructura será un conjunto de esquemas de relación con sus atributos, dominios de atributos, claves primarias, claves foráneas, etc. (Costal Costa, 2008)

7.7.1. Etapas del diseño de bases de datos El diseño de una base de datos no es un proceso sencillo. Habitualmente, la complejidad de la información y la cantidad de requisitos de los sistemas de

26

información hacen que sea complicado. Por este motivo, cuando se diseñan bases de datos es interesante aplicar la vieja estrategia de dividir para vencer. Por lo tanto, conviene descomponer el proceso del diseño en varias etapas; en cada una se obtiene un resultado intermedio que sirve de punto de partida de la etapa siguiente, y en la última etapa se obtiene el resultado deseado. De este modo no hace falta resolver de golpe toda la problemática que plantea el diseño, sino que en cada etapa se afronta un solo tipo de subproblema. Así se divide el problema y, al mismo tiempo, se simplifica el proceso. (Costal Costa, 2008)

Etapa del diseño conceptual: en esta etapa se obtiene una estructura de la información de la futura BD independiente de la tecnología que hay que emplear. No se tiene en cuenta todavía qué tipo de base de datos se utilizará –relacional, orientada a objetos, jerárquica, etc. –; en consecuencia, tampoco se tiene en cuenta con qué SGBD ni con qué lenguaje concreto se implementará la base de datos. Así pues, la etapa del diseño conceptual nos permite concentrarnos únicamente en la problemática de la estructuración de la información, sin tener que preocuparnos al mismo tiempo de resolver cuestiones tecnológicas.

Etapa del diseño lógico: en esta etapa se parte del resultado del diseño conceptual, que se transforma de forma que se adapte a la tecnología que se debe emplear. Más concretamente, es preciso que se ajuste al modelo del SGBD con el que se desea implementar la base de datos. Por ejemplo, si se trata de un SGBD relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, claves primarias y claves foráneas.

Etapa del diseño físico: en esta etapa se transforma la estructura obtenida en la etapa del diseño lógico, con el objetivo de conseguir una mayor eficiencia; además, se completa con aspectos de implementación física que dependerán del SGBD. Por ejemplo, si se trata de una base de datos relacional, la transformación de la estructura puede consistir en lo siguiente: tener almacenada alguna relación que sea la combinación de varias relaciones que se han obtenido en la etapa del diseño lógico, partir una relación en varias, añadir algún atributo calculable a una relación, etc. Los aspectos de implementación física que hay que completar consisten normalmente en la elección de estructuras físicas de implementación de las relaciones, la selección del tamaño de las memorias intermedias (buffers) o de las páginas, etc. (Costal Costa, 2008)

7.7.2. El Modelo de Datos Entidad-Relación (E/R)

Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de

27

crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos. Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios. (Universidad de Sevilla, 2003) Entidades y Relaciones

El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:

Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:

- Que sea única. - Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada cliente un número de cliente?. - Que sea mínima, ya que será muy utilizada por el gestor de base de datos.

Relación.- Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:

- Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO). - Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN). - Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA). (Universidad de Sevilla, 2003)

28

Representación gráfica de Entidades y Relaciones Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se utilizan los siguientes elementos gráficos: ILUSTRACIÓN 1 Representación relaciones

Fuente: (Universidad de Sevilla, 2003)

Otra forma de representar las relaciones es con la notación para de gallo donde

(0,1) =

(1,1) =

(0,n) =

(1,n) =

7.7.3. Herramienta de diseño de bases de datos relacionales MySQL Workbench: es una aplicación para el diseño y documentación de bases de datos (sucesora de la aplicación DBDesigner4) pensada para ser usada con el sistema de gestión de bases de datos MySQL (recién adquirido por Oracle). Existen dos versiones del producto, una es gratuita y la otra es una versión comercial. Evidentemente, la versión comercial proporciona algunas funcionalidades que pueden resultar de interés en algún ámbito, aunque la versión gratuita es más que suficiente para la realización de la práctica. Algunas de sus características son:

Edición de de diagramas basada en Cairo, con posibilidad de realizar una salida en los formatos como OpenGL, Win32, X11, Quartz, PostScript, PDF…

Proporciona una representación visual de las tablas, vistas, procedimientos y funciones almacenadas y claves foráneas.

Permite acceso a bases de datos e ingeniería inversa de las mismas para crear los SQL de creación

Ofrece sincronización con la base de datos y el modelo. Permite generar los scripts SQL a partir del modelo creado. Ofrece una arquitectura extensible.

29

Tiene soporte para exportar los datos como script SQL CREATE. Permite importar modelos de DBDesigner4. Ofrece soporte completo a las características de MySQL 5.

Puede ser descargado de manera gratuita desde el siguiente enlace http://dev.mysql.com/downloads/workbench/5.2.html

7.8. IMPLEMENTACIÓN El modelo de implementación toma el resultado del modelo de diseño para generar el código final. Esta traducción debe ser relativamente sencilla y directa, ya que las decisiones mayores han sido tomadas durante las etapas previas. Durante el modelo de implementación se hace una adaptación al lenguaje de programación y/o la base de datos de acuerdo a la especificación del diseño y según las propiedades del lenguaje de implementación y base de datos. Aunque el diseño de objetos es bastante independiente del lenguaje actual, todos los lenguajes tendrán sus particularidades, las cuales deberán adecuarse durante la implementación final. La elección del lenguaje influye en el diseño, pero el diseño no debe depender de los detalles del lenguaje. Si se cambia de lenguaje de programación no debe requerirse el re-diseño del sistema. En general, no se debe comenzar prematuramente a programar, es importante primero completar el proceso de planeación del sistema final desarrollado durante el diseño. Se debe usar guías de programación existentes en la organización. Si no existen, el equipo de software debe crear sus propias guías para decidir aspectos, como formatos para la asignación de nombres a las variables, estilo de programación, métodos de documentación, y documentación en línea. Vale la pena resaltar que aunque existe cierta automatización en el proceso de generación del código final, en su gran mayoría los programadores hacen de manera “manual” la transición final a código fuente. (Weitzenfeld, 2002)

7.8.1. Gestor de bases de datos MySQL: es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en inglés) muy conocido y ampliamente usado por su simplicidad y notable rendimiento. Aunque carece de algunas características avanzadas disponibles en otros SGBD del mercado, es una opción atractiva tanto para aplicaciones comerciales, como de entretenimiento precisamente por su facilidad de uso y tiempo reducido de puesta en marcha. Esto y su libre distribución en Internet bajo licencia GPL le otorgan como beneficios adicionales (no menos importantes) contar con un alto grado de estabilidad y un rápido desarrollo. (Casillas Santillan, Gilbert Ginestá, & Pérez Mora, 2003) Sus características son:

Está desarrollado en C/C++. Se distribuyen ejecutables para cerca de diecinueve plataformas diferentes.

http://dev.mysql.com/downloads/workbench/5.2.html

30

La API se encuentra disponible en C, C++, Eiffel , Java, Perl, PHP, Python, Ruby y TCL.

Está optimizado para equipos de múltiples procesadores. Es muy destacable su velocidad de respuesta. Se puede utilizar como cliente-servidor o incrustado en aplicaciones. Cuenta con un rico conjunto de tipos de datos. Soporta múltiples métodos de almacenamiento de las tablas, con

prestaciones y rendimiento diferentes para poder optimizar el SGBD a cada caso concreto.

Su administración se basa en usuarios y privilegios. Se tiene constancia de casos en los que maneja cincuenta millones de

registros, sesenta mil tablas y cinco millones de columnas. Sus opciones de conectividad abarcan TCP/IP, sockets UNIX y sockets NT,

además de soportar completamente ODBC. Los mensajes de error pueden estar en español y hacer ordenaciones

correctas con palabras acentuadas o con la letra ‟ñ‟. Es altamente confiable en cuanto a estabilidad se refiere.

Puede ser descargado de manera gratuita desde el siguiente enlace http://dev.mysql.com/downloads/mysql/

7.8.2. Lenguaje de programación PHP: es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente para la interpretación del lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+. (www.wikipedia.org, 2011) El lenguaje de script PHP se ha popularizado extraordinariamente durante los últimos años, gracias a su sencillez y su sintaxis heredada de otros lenguajes como C, Perl o Visual Basic, que casi todos los desarrolladores ya conocían en mayor o menor grado. Su fácil integración con los servidores web más populares (Apache, IIS, etc.), sin necesidad de recompilaciones o configuraciones complejas, ha contribuido también a que casi todos los proveedores de espacio web, desarrolladores de aplicaciones de software libre basadas en web, y proveedores de aplicaciones empresariales, lo usen para sus productos. (Gilbert Ginestá, 2003)

7.8.3. Herramientas de desarrollo web Adobe Dreamweaver: es una aplicación en forma de estudio (basada en la forma de estudio de Adobe Flash) que está destinada a la construcción y edición de sitios y aplicaciones Web basados en estándares. Creado inicialmente por Macromedia (actualmente producido por Adobe Systems) es el programa de este tipo más utilizado en el sector del diseño y la programación web, por sus funcionalidades, su integración con otras herramientas como Adobe Flash y,

http://dev.mysql.com/downloads/mysql/

31

recientemente, por su soporte de los estándares del World Wide Web Consortium. Su principal competidor es Microsoft Expression Web y tiene soporte tanto para edición de imágenes como para animación a través de su integración con otras. (www.wikipedia.org, 2011) Adobe CS es una suite de distintas aplicaciones en forma de talleres y estudios dotados de herramientas y funciones altamente profesionales creada y producida por Adobe Systems y que están dirigidas a la Publicación Impresa, Publicación Web, Post Producción de Video, y Dispositivos Móviles. Adobe Creative Suite nace del exitoso intento de la casa Adobe de unir todos sus programas profesionales, que antes solo se conseguían individualmente, en diferentes conjuntos entre los cuales se tiene un fin común y un conjunto de un Máximo fin común dando como resultado una adquisición de productos más económica para el usuario y que contiene un conjunto de utilidades profesionales para diferentes propósitos de publicación. Este ingeniosa unión de sus productos en conjuntos ha dado muy buenos resultados para Adobe en los últimos años, no obstante, la compañía sigue vendiendo sus productos también individualmente. Adobe Creative Suite está disponible en distintas versiones, la más novedosa de ellas, CS5 esta complementada con las más novedosas acciones para las aplicaciones de Adobe y por lo demás tiene una muy versátil interfaz para facilitar las operaciones ejecutadas con los software. En algunos casos la aplicación cambia casi totalmente, en cambio, en sus otras versiones (CS, CS2, CS3) la funcionalidad de la aplicación es más constante que en el caso de CS4; además la versión CS5 implementa nuevas funciones a las aplicaciones Adobe, y mucho mayor integración entre ellas así como las aplicaciones compradas a Macromedia. Recientemente ha sido lanzada la versión CS5.5, que mejora el contenido de algunos programas. (www.wikipedia.org, 2011) Heidi SQL: es una interfaz gráfica open source para la gestión simplificada de tus bases de datos MySQL locales y/o remotas. Esta ligera aplicación gratuita ofrece una gran cantidad de funcionalidades para que la gestión de tus bases de datos se convierta en una tarea asequible. Entre otras muchas funciones, HeidiSQL permite: - La gestión y consulta de tus bases y tablas de datos a partir de una interfaz intuitiva - La importación de datos desde archivos de texto. - La exportación de tablas de datos CSV, HTML y XML. - La sincronización de tablas entre dos bases de datos. - La gestión de los distintos usuarios y sus privilegios. - La edición sencilla de tablas de datos. - La escritura de queries con sintaxis coloreada.

32

Puede ser descargado de manera gratuita desde el siguiente enlace http://www.heidisql.com/download.php

7.8.4. Modelo de ciclo de vida

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, “Cascada”, fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos. (Weitzenfeld, 2002)

7.8.5. Definición de un Modelo de Ciclo de Vida. Un modelo de ciclo de vida de software es una visión de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas. Un modelo de ciclo de vida del software:

- Describe las fases principales de desarrollo de software. - Define las fases primarias esperadas de ser ejecutadas durante esas fases. - Ayuda a administrar el progreso del desarrollo, y - Provee un espacio de trabajo para la definición de un detallado proceso de

desarrollo de software. Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. (Weitzenfeld, 2002)

Paradigmas:

Los paradigmas, también conocidos a menudo como Estrategias de Desarrollo de Software (EDS), son propuestas de actuación computacional utilizadas en el desarrollo de software. Hay muchas clases de paradigmas se encuentran los demostrativos, declarativos, imperativo, funcionales y orientados a objetos. Los paradigmas que iniciaron en los años 60 al lado del MCVS lineal o en cascada, permitían abordar de manera secuencial el problema como un todo (programación, datos, informes, etc.). En estos estadios de la historia del desarrollo de software se tenía un sistema en el que no había separación de

http://www.heidisql.com/download.php

33

conceptos, datos y funcionalidad se mezclaban sin una línea divisoria clara. Los historiadores han coincidido en que a esta etapa se la conoce como la del código spaghetti, ya que se tenía una maraña entre datos y funcionalidad que recuerda a la que se forma cuando comemos un plato de esta pasta italiana. (Weitzenfeld, 2002) Sin embargo, la historia de la ingeniería del software, en lo que a su evolución respecta, ha observado progresos significativos gracias a la necesidad que ha tenido el ingeniero de resolver problemas de manera diferente y más eficiente: representar la vida cotidiana, la descomposición de un sistema complejo en partes, etc. Años después, se pasó a aplicar la llamada descomposición funcional, que pone en práctica el principio de „divide y vencerás‟ identificando las partes más manejables como funciones que se definen en el dominio del problema. La principal ventaja que proporciona esta descomposición es la facilidad de integración de nuevas funciones, aunque también tiene grandes inconvenientes, como son el hecho de que las funciones quedan algunas veces poco claras debido a la utilización de datos compartidos, y el que los datos quedan esparcidos por todo el código, con lo cual, normalmente el integrar un nuevo tipo de datos implica que se tengan que modificar varias funciones. Intentando solventar estas desventajas con respecto a los datos, se dio otro paso en el desarrollo de los sistemas software. El paradigma orientada a objetos (POO) ha supuesto uno de los avances más importantes de los últimos años en la ingeniería del software para construir sistemas complejos utilizando el principio de descomposición, ya que el modelo de objetos subyacente se ajusta mejor a los problemas del dominio real que la descomposición funcional. La ventaja que tiene es que es fácil la integración de nuevos datos, aunque también quedan las funciones esparcidas por todo el código, y tiene los inconvenientes de que, con frecuencia, para realizar la integración de nuevas funciones hay que modificar varios objetos, y de que se produce un enmarañamiento de los objetos en funciones de alto nivel que involucran a varias clases. (Weitzenfeld, 2002)

7.9. MODELO DE PRUEBAS Probar un producto es relativamente independiente de la metodología de desarrollo utilizada para construirlo. Existen diversos tipos de pruebas aplicados durante las diferentes actividades del proceso de desarrollo. Estas pruebas requieren de tiempo y presupuesto adicional, pudiendo llegar a significar entre un 30% y un 50% del costo total de desarrollo. Por tal motivo, el modelo de pruebas debe ser planificado con anticipación y de manera integral junto con el propio desarrollo del sistema. Es un error pensar que las pruebas son la última actividad del desarrollo ya que no se puede lograr software de alta calidad sólo mediante pruebas finales y depuraciones. Las pruebas deben hacerse en paralelo al

34

desarrollo del sistema, teniendo pruebas finales únicamente como certificación final de la calidad del producto y no como la oportunidad para encontrar errores. Encontrar errores al final del desarrollo es bastante problemático dado que requerirá regresar a etapas anteriores para resolverlos. Se considera que "evitar defectos" es más poderoso que "remover defectos". (Weitzenfeld, 2002)

7.9.1. Tipos de Pruebas Los tipos de pruebas se dividen de manera general en pruebas de verificación y validación. En el caso de la verificación se revisa si el resultado corresponde a la especificación del sistema, en otras palabras, si se está construyendo el sistema correctamente, algo por sí sólo no garantiza la satisfacción de los clientes. En el caso de la validación se revisa si el resultado es realmente lo que el cliente quería, en otras palabras, si se está construyendo el sistema correcto de manera que tanto la especificación como el resultado sean los correctos. En este capítulo nos concentraremos principalmente en la verificación del sistema. La validación del sistema debiera hacerse durante la especificación inicial del sistema a través de prototipos que deben ser aprobados por el cliente y que correspondan a la funcionalidad deseada. El sistema debe validarse continuamente durante el proceso de desarrollo del sistema de manera siempre corresponda con lo especificado. La validación se basa en el modelo de casos de uso. Existen también diferentes técnicas y niveles de pruebas que pueden aplicarse. (Weitzenfeld, 2002)

35

8. CRONOGRAMA DE ACTIVIDADES PLANEADAS

ACTIVIDADES Enero Febrero Marzo Abril Mayo Junio

1º 2º 3º 4º 1º 2º 3º 4º 1º 2º 3º 4º 1º 2º 3º 4º 5º 6º 7º 8º 9º 10º 11º 12º Requisitos del software Descripción del problema Definición de requisitos Análisis de requerimientos Validación de requisitos Diseño del software Identificación de la herramienta de desarrollo Diseño de base de datos

Diseño diagrama entidad relación Desarrollo de la estructura y arquitectura del sw

Arquitectura de clases Validación diseño Desarrollo del prototipo Codificación Pruebas Ajustes Implantación Construcción del documento de practicas

36

9. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS

Se debe dejar claro que según el cronograma anterior el informe de práctica

académica y el proyecto de intervención deben ser entregados a finales de Junio

razón por la que el software todavía está en proceso de desarrollo y aun no esta

completo.

9.1. JUSTIFICACIÓN DEL MODELO DE CICLO DE VIDA ELEGIDO

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas ellas. El modelo de ciclo de vida prototipado evolutivo acepta que los requerimientos del usuario pueden cambiar en cualquier momento. Se elige este modelo, ya que, la práctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto es extremadamente difícil, no solo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. Además este modelo de ciclo de vida del software permite involucrar directamente al usuario en el proceso de desarrollo del proyecto, permitiendo conocer claramente el problema planteado y aumentando la posibilidad de satisfacer las necesidades del cliente.

9.2. JUSTIFICACIÓN DEL ENFOQUE METODOLÓGICO ELEGIDO La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelan software facilitando la construcción de sistemas complejos a partir de componentes. El tipo de problema que se desea resolver puede ser abordado con un enfoque orientado a objetos, ya que este nos proporciona conceptos y herramientas con las cuales se puede modelar y representar el mundo real tan fielmente como sea posible. Además ofrece metodologías para construir sistemas de software a partir de unidades modulares y reutilizables, dividiendo en pequeñas partes el problema planteado mejorando su comprensión y manipulación, aumentando la calidad de la aplicación desarrollada.

37

9.3. REQUERIMIENTOS DEL SOFTWARE

9.3.1. Identificación y clasificación de requerimientos Requerimientos del proceso y del producto:

Del producto

Llevar y almacenar un control sobre cada venta con fecha, hora y usuario.

Actualizar el inventario en tiempo real.

Mostrar alertas en tiempo real sobre el estado del inventario

Al hacer la apertura de caja y después de ingresar la información correspondiente generar un informe al operador sobre el estado de los servicios (minutos restantes, dinero para recargas a móviles, etc.) y del inventario.

Al hacer el cierre de caja será enviado un correo electrónico al administrador con los informes de ventas e inventarios.

Consultar reportes en cualquier momento.

Del proceso

El código fuente del software debe ser creado en un lenguaje de programación de alto nivel basado en la web, para que pueda ser accesible desde cualquier navegador web.

En el proceso de desarrollo es posible que se agreguen nuevos requerimientos y funcionalidades al sistema es por esto que se debe seguir un ciclo de vida prototipado evolutivo.

El sistema deberá ser desarrollado siguiendo un enfoque metodológico orientado a objetos con la intención de utilizar características como abstracción, modularidad y reutilización.

Requerimientos funcionales y no funcionales

Funcionales

Registrar usuarios

Validar usuarios

Asignar privilegios a cada usuario

Hacer apertura de caja

Calcular la cantidad de minutos restantes en las líneas celulares

Calcular el dinero disponible para recargas a líneas celulares

Generar ventas de artículos y servicios

Controlar el inventario

Hacer cierre de caja

Generar informes de ventas e inventarios

Enviar informes por correo electrónico

Consultar información

Registrar costos y precios de venta

38

No funcionales

El sistema deberá ser accesible desde internet

El sistema podrá ser accesible desde cualquier navegador web

El sistema deberá ser de fácil manejo e intuitivo para los usuarios

El sistema deberá admitir en el futuro cambios en sus funcionalidades, agregar o quitar funcionalidades después de que esté en funcionamiento

El sistema deberá tener una disponibilidad del 100% o un valor cercano en el horario de trabajo

Requerimientos del sistema

El sistema deberá contar con un servidor web Apache, además de un motor de bases de datos MySQL que puedan interactuar con el lenguaje PHP

El sistema deberá contar el espacio suficiente para alojar los datos de la empresa

El sistema deberá contar con una buena conexión a internet que posea disponibilidad superior a 99% mensual, al igual que una velocidad constante superior a 1000Kbps.

9.4. ACTORES Y CASOS DE USO

9.4.1. Actores

Primarios

Usuario Secundarios

Base de datos

ILUSTRACIÓN 2. Representación general del sistema

Casos de uso

Caso de uso general del sistema

40

Caso de uso General

Actores Administrador, Empleado, Base de datos

Tipo Básico

Propósito Permite gestionar y controlar las ventas y los inventarios

Resumen Es iniciado por el usuario. Ofrece las funcionalidades necesarias para controlar las ventas y los inventarios

Precondiciones Es necesario ejecutar antes el caso de uso validar usuario para ingresar al sistema y poder utilizar el sistema

Flujo principal Se muestra al usuario una pantalla de login donde ingresa los datos correctos para acceder al sistema y poder ejecutar las funcionalidades deseadas en la pantalla principal

Validar usuario Caso de Uso: Validar Usuario

Actores: Administrador, Empleado, Base de datos

Tipo: Inclusión

Propósito: Permitir validar la identidad del usuario ante el sistema

Resumen: Este caso de uso es iniciado por el usuario. Valida al usuario mediante un Usuario y Contraseña para poder utilizar el sistema

Precondiciones: El usuario debe conocer el usuario y contraseña por defecto.

41

Flujo Principal: Se presenta al usuario la Pantalla de inicio de sesión (P-0). El usuario ingresa su nombre de usuario y contraseña por defecto. El usuario puede seleccionar entre las siguientes opciones: “ingresar" y "Salir". Si la actividad seleccionada es "ingresar", se valida el registro de usuario mediante el usuario y una contraseña insertados por el usuario en la Pantalla de inicio de sesión (P-0). Una vez validado el usuario (E-1), Se continúa con el caso de uso Ofrecer Información. Si la actividad seleccionada es "Salir" se saldrá del sistema.

Subflujos: Ninguno

Excepciones: E-1 no hubo validación: El usuario/Contraseña no se valido correctamente.

Ofrecer Información Caso de Uso: Ofrecer Información

Actores: Administrador, Empleado, Usuario

Tipo: Inclusión

Propósito: Ofrecer los diferentes tipos alertas sobre el estado de los servicios e inventarios a un usuario que haya iniciado sesión.

Resumen: Este caso de uso es iniciado por el Usuario o presentado por el sistema, cuando ingresa un Usuario presenta alertas sobre el estado de los servicios y los inventarios. Tiene opciones para utilizar las diferentes funcionalidades del sistema

Precondiciones: Se requiere la correcta validación del Usuario

Flujo Principal: Se presenta al usuario la Pantalla Información (P-1). El usuario según sus privilegios puede seleccionar entre las siguientes actividades: “Apertura de Caja”, “Vender”, "Cerrar Caja", "Ajustar inventario", “Generar informes” y “Usuarios”. Si la actividad seleccionada es "Apertura de Caja", se continúa con el caso de uso Apertura de Caja. Si la actividad seleccionada es "Vender", se continúa con el caso de uso Registrar Ventas. Si la actividad seleccionada es "Cerrar Caja", se continúa con el caso de uso Cierre de Caja. Si la actividad seleccionada es "Ajustar Inventario", se continúa con el caso de uso Actualizar Inventario. Si la actividad seleccionada es "Generar Informes", se continúa con el caso de uso Registrar Usuario. Si la actividad seleccionada es "Usuarios", se continúa con el caso de uso Registrar Usuario. Si la actividad seleccionada es "Salir" se saldrá del sistema.

Subflujos: Ninguno.

Excepciones: Ninguno.

Apertura de Caja Caso de Uso: Apertura de Caja

Actores: Empleado, Base de datos

42

Tipo: Básico

Propósito: Permita al Usuario ingresar la información necesaria para iniciar las actividades.

Resumen: Este caso de uso es iniciado por el usuario, allí se indica el dinero existente en la caja al iniciar cada turno de trabajo, así como consumo acumulado de minutos, dinero disponible de recargas y el resto de información necesaria

Precondiciones: Requiere ser un usuario valido, La caja debe estar cerrada

Flujo Principal: Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuara con los diversos subflujos de este caso de uso

Subflujos: S-1 Abrir caja Se presenta al usuario la pantalla (P-2), donde el usuario debe llenar una lista las casillas con la información necesaria para hacer la apertura de la caja, lo que incluye, Saldo con el que inicia la caja, consumo acumulado de minutos por plan, dinero disponible de recargas en la pagina y dinero de recargas en la caja, seleccionar el turno. El usuario puede seleccionar entre las siguientes actividades: "Abrir Caja " y "Salir". Si el usuario selecciona “Abrir”, el sistema hará la apertura de la caja (E-1, E-2). Se continuara con el caso de uso Ofrecer Información. Si la actividad seleccionada es "Salir" se saldrá del sistema (si aún no se ha presionado “Abrir Caja", la información será perdida).

Excepciones: E-1 información incompleta: Falta llenar información en el registro de usuario. Se vuelve a solicitar al usuario que complete el registro. E-2 La caja no se ha cerrado: Si antes se realizo la apertura de la caja y no fue cerrada no se puede hacer otra apertura

Registrar Usuario Caso de Uso: Registrar Usuario

Actores: Administrador, Base de datos

Tipo: Básico

Propósito: Permite registrar un usuario para que pueda utilizar el sistema

Resumen: Este caso de uso es iniciado por el Administrador, ofrece la funcionalidad para crear, modificar y eliminar el registro de los usuarios del sistema.

Precondiciones: Se requiere ejecutar inicialmente el caso de uso Validar usuario y ser usuario con privilegios del sistema.

Flujo Principal: Se presenta al usuario en una pantalla (P-3) lista los usuarios ya creados en el sistema y se da la opción de crear, modificar o eliminar los usuarios.

Subflujos: S-1 Agregar usuario El usuario selecciona “Agregar usuario”. Se presenta al usuario la pantalla Agregar usuario (P-4). Esta pantalla contiene una serie de casillas de información que deberán ser llenadas por el usuario, Nombre completo, Usuario, Contraseña, verificar Contraseña para

43

asegurarse de su corrección, Tipo de usuario (Administrador, Empleado) para asignar los privilegios correspondientes. El Usuario y el Contraseña se utilizaran para autenticarse en el sistema. El usuario puede seleccionar entre “Crear” y “Salir”. Si selecciona “Crear” se genera un nuevo registro en la base de datos (E-1, E-2, E-3). Si selecciona “salir” se cerrara la pantalla (P-4). S-2 Eliminar usuario Se selecciona un usuario de la lista mostrada en la pantalla (P-2), luego la opción “Eliminar” para borrar el registro correspondiente de la base de datos.

Excepciones: E-1 campos vacios: Falta llenar información en el registro de usuario. Se vuelve a solicitar al usuario que complete el registro. E-2 registro ya existe: Si ya existe un registro bajo ese Usuario, se solicitará al usuario que lo cambie o que termine el caso de uso. E-3 contraseña no coincide: no se validó la contraseña correctamente.

Registro de Ventas Caso de Uso: Registrar ventas


Tipo: Básico

Propósito: Permite Registrar las ventas de los diferentes productos que se venden en la empresa

Resumen: Este caso de uso es iniciado por el Usuario. Ofrece la funcionalidad para registrar la venta de llamadas, artículos, y demás productos.

Precondiciones: Se debe haber ejecutado anteriormente el caso de uso Apertura de Caja

Flujo Principal: Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuara con los diversos subflujos de este caso de uso

Subflujos: S-1 Registrar Venta Se presenta al usuario la pantalla (P-5), donde habrá una lista de los productos, y varias opciones de filtrado ( ID_producto, Tipo, Nombre...) el usuario podrá elegir el producto y seleccionar entre las siguientes actividades: “Agregar a la venta”, “Registrar venta” y “salir”. Si la actividad seleccionada es “Agregar a la venta”, el sistema creara otra lista con los productos agregados donde se elegirá la cantidad y se mostrara el precio total. Si el usuario selecciona la actividad “Registrar Venta” se utilizan los datos de la lista de productos agregados y se envía una pantalla de confirmación (E-1). Si el usuario selecciona la actividad “Salir” Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-5)

Excepciones: E-1 Si la lista de productos agregados esta vacía no se podrá registrar la venta

44

Cierre de caja Caso de Uso: Cierre de Caja


Tipo: Básico

Propósito: Permita al usuario ingresar la información necesaria para terminar sus actividades y hacer entrega de su turno

Resumen: Este caso de uso es iniciado por el usuario, allí se indica el dinero existente en la caja al iniciar cada turno de trabajo, así como consumo acumulado de minutos, dinero disponible de recargas y el resto de información necesaria

Precondiciones: Requiere ser un usuario valido, se debe haber ejecutado anteriormente el caso de uso Apertura de Caja

Flujo Principal: Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuara con los subflujos de este caso de uso

Subflujos: S-1 Cerrar caja Se presenta al usuario la pantalla (P-6), donde el usuario debe llenar una lista las casillas con la información necesaria para hacer el cierre de caja, lo que incluye, Saldo con el que se cierra la caja, dinero disponible de recargas en la pagina y dinero de recargas en la caja. El usuario puede seleccionar entre las siguientes actividades: "Cerrar Caja " y "Salir". Si el usuario selecciona “Cerrar”, el sistema hará el Cierre de la caja (E-1, E-2). Se continuara con el caso de uso Ofrecer Información. Si la actividad seleccionada es "Salir" se saldrá del sistema (si aún no se ha presionado “Cerrar Caja", la información será perdida).

Excepciones: E-1 información incompleta: Falta llenar información en el registro de usuario. Se vuelve a solicitar al usuario que complete el registro. E-2 La caja no se ha Abierto: Si antes se realizo un cierre de la caja y no fue abierta no se podrá hacer el cierre de caja

Generar Informes Caso de Uso: Generar Informes


Tipo: Básico

Propósito: Permite hacer consultas sobre el estado del inventario y las ventas

Resumen: Este caso de uso es iniciado por el Administrador o el Usuario. Ofrece la funcionalidad de generar informes sobre las ventas o el consultar información sobre el estado del inventario

Precondiciones: Se requiere la correcta validación del Usuario


Subflujos: S-1 Informes

45

Se presenta al usuario la Pantalla Información (P-7). El usuario puede seleccionar entre las siguientes actividades: “Ventas”, “Inventario”, “Salir”. Si la actividad seleccionada es "ventas", se continúa con el subflujo Consultar Ventas (S-2). Si la actividad seleccionada es "Inventario", se continúa con el subflujo Consultar Inventario(S-4). Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-7) S-2 Consultar Ventas Se presenta al usuario la pantalla Consultar Ventas (P-8). En esta pantalla se deben seleccionar las opciones de filtrado como tipo de producto, rango de fechas, empleado…El usuario puede seleccionar de las siguientes actividades: “Consultar”, “Salir”. Si el usuario presiona “Consultar”, el sistema recibe la información (E-1, E-2), se continúa con el subflujo Devolver Ventas (S-3). Si el usuario selecciona la actividad “Salir” Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-8) S-3 Devolver Ventas Se presenta la pantalla Informe Ventas (P-9) conteniendo la información solicitada. El usuario puede seleccionar entre las siguientes actividades: “Nueva Consulta”, “Salir”. Si la actividad seleccionada es "Nueva Consulta", se continúa con el subflujo Consultar Ventas (S-2). Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-9 y P-8) S-4 Consultar Inventarios Se presenta al usuario la pantalla Consultar Inventario (P-10). En esta pantalla se deben seleccionar las opciones de filtrado como tipo de producto, cantidad, fecha de ingreso…El usuario puede seleccionar de las siguientes actividades: “Consultar”, “Salir”. Si el usuario presiona “Consultar”, el sistema recibe la información (E-1, E2), se continúa con el subflujo Devolver Inventario (S-3). Si el usuario selecciona la actividad “Salir” Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-10) S-3 Devolver Ventas Se presenta la pantalla Informe Inventario (P-11) conteniendo la información solicitada. El usuario puede seleccionar entre las siguientes actividades: “Nueva Consulta”, “Salir”. Si la actividad seleccionada es "Nueva Consulta", se continúa con el subflujo Consultar Ventas (S-4). Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-10 y P-11)

Excepciones: E-1 información incompleta: Falta llenar información indispensable, ciudad de origen o de destino. Se le vuelve a pedir al usuario la información. E-2 información inválida: Una de las entradas de la solicitud es

46

incorrecta.

Actualizar inventario Caso de Uso: Actualizar inventario


Tipo: Básico

Propósito: Permitir al Usuario actualizar la cantidad de productos en el inventario

Resumen: Este caso de uso es iniciado por el Administrador, allí se pueden crear, modificar, o eliminar productos existentes en el inventario.

Precondiciones: Requiere ser un usuario valido


Subflujos: S-1 Actualizar Se presenta al usuario la pantalla Actualizar (P-12). Lista los productos ya creadas en el sistema y El usuario puede seleccionar entre las siguientes actividades: “Agregar”, “Editar”, “Eliminar”, “Salir”. S-1 Agregar El usuario selecciona “Agregar”. Se presenta al usuario la pantalla Agregar (P-13). Esta pantalla contiene unas casillas de información que deberán ser llenadas por el usuario, Nombre del producto, ID, Precio, Costo, Cantidad. El usuario puede seleccionar entre “Crear” y “Cancelar”. Si selecciona “Crear” se genera un nuevo registro en la base de datos y se agrega a la lista de productos desplegados en (P.12) (E-1). Si selecciona “Cancelar” se cerrara la pantalla (P-13). S-2 Editar Se selecciona un producto de la lista mostrada en la pantalla (P-12), y se selecciona “Editar” luego se presenta al usuario una pantalla (P-14) con toda la información del producto la cual podrá ser editada por el usuario, con la opción “Cargar” y “Salir”. Si selecciona “Cargar” se despliega una pantalla de confirmación. Si ha seleccionando “Salir” se cerrara (P-14). S-3 Eliminar Se selecciona una producto de la lista mostrada en la pantalla (P-12), luego la opción “Eliminar” para borrar el registro de correspondiente de la base de datos. Si la actividad seleccionada es "Salir" se saldrá de la pantalla (P-12)

Excepciones: E-1 registro ya existe: Si ya existe un registro con el ID (P-13, P-14), se solicitará al usuario que lo cambie o que termine el caso de uso.

47

9.5. DISEÑO DE DATOS

9.5.1. Modelo Relacional ILUSTRACIÓN 3. Modelo relacional

Fuente: Autor

48

9.5.2. Modelo lógico entidad relación ILUSTRACIÓN 4. Entidad relación

Fuente: Autor

49

9.5.3. Modelo Físico de datos SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0; SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL'; CREATE SCHEMA IF NOT EXISTS `contabilidad` ; USE `contabilidad`; -- ----------------------------------------------------- -- Table `contabilidad`.`proveedor` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`proveedor` ( ìdproveedor` INT NOT NULL , `nombreprov` VARCHAR(45) NULL , `telefonoprov` VARCHAR(45) NULL , `ciudadprov` VARCHAR(45) NULL , `direccionprov` VARCHAR(45) NULL , PRIMARY KEY (ìdproveedor`) ) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.`producto` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`producto` ( ìdproducto` INT NOT NULL , `nombrepro` VARCHAR(45) NOT NULL , `tipopro` VARCHAR(45) NULL , `cantidad_disponible` INT NOT NULL , `cantidad_minima` INT NULL , ìmagenpro` VARCHAR(45) NULL , `proveedor_idproveedor` INT NOT NULL , `Precio_pro` INT NULL , `Costo_pro` INT NULL , PRIMARY KEY (ìdproducto`, `proveedor_idproveedor`) , INDEX `fk_producto_proveedor1` (`proveedor_idproveedor` ASC) , CONSTRAINT `fk_producto_proveedor1` FOREIGN KEY (`proveedor_idproveedor` ) REFERENCES `contabilidad`.`proveedor` (ìdproveedor` ) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.èmpleado`

50

-- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.èmpleado` ( ìdempleado` INT NOT NULL , `nombreemp` VARCHAR(45) NULL , `telefonoemp` VARCHAR(45) NULL , `direccionemp` VARCHAR(45) NULL , ùsuario` VARCHAR(45) NOT NULL , `clave` VARCHAR(45) NOT NULL , `correo` VARCHAR(45) NULL , `privilegio` VARCHAR(45) NOT NULL , PRIMARY KEY (ìdempleado`) , UNIQUE INDEX ìndex2` (ùsuario` ASC) ) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.`ventaproductos` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`ventaproductos` ( ìdventaproductos` INT NOT NULL AUTO_INCREMENT , `valorventa` INT NOT NULL , `fechahoraventa` DATETIME NOT NULL , èmpleado_idempleado` INT NOT NULL , ìdproducto1` INT NULL , `cantidad1` INT NULL , ìdproducto2` INT NULL , `cantidad2` INT NULL , ìdproducto3` INT NULL , `cantidad3` INT NULL , PRIMARY KEY (ìdventaproductos`, èmpleado_idempleado`) , INDEX `fk_ventaproductos_empleado` (èmpleado_idempleado` ASC) , CONSTRAINT `fk_ventaproductos_empleado` FOREIGN KEY (èmpleado_idempleado` ) REFERENCES `contabilidad`.èmpleado` (ìdempleado` ) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.`planes` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`planes` ( ìdplanes` INT NOT NULL , `numeroplan` INT NULL , `cantidadtotalmin` INT NULL , `fecha de corte` DATE NULL ,

51

PRIMARY KEY (ìdplanes`) ) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.`caja` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`caja` ( ìdcaja` INT NOT NULL , `fechahoraabre` DATETIME NULL , `saldoabre` INT NULL , `fechahoracierra` DATETIME NULL , `saldocierra` INT NULL , èmpleado_idempleado` INT NOT NULL , PRIMARY KEY (ìdcaja`, èmpleado_idempleado`) , INDEX `fk_caja_empleado1` (èmpleado_idempleado` ASC) , CONSTRAINT `fk_caja_empleado1` FOREIGN KEY (èmpleado_idempleado` ) REFERENCES `contabilidad`.èmpleado` (ìdempleado` ) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `contabilidad`.`consumoplanes` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `contabilidad`.`consumoplanes` ( ìdconsumoplanes` INT NOT NULL AUTO_INCREMENT , ìdplan` INT NULL , `fechaconsulta` DATE NULL , `cantidadconsulta` INT NULL , PRIMARY KEY (ìdconsumoplanes`) , UNIQUE INDEX ìndex2` (ìdplan` ASC) ) ENGINE = InnoDB; SET SQL_MODE=@OLD_SQL_MODE; SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

52

9.6. DESARROLLO DE LA INTERFACE WEB

9.6.1. Validación de usuario pantalla P-0 ILUSTRACIÓN 5. Pantalla P-0

Fuente: Autor

Codigo Pantalla P-0: <?php require_once('../Connections/cn2.php'); ?> <?php if (!function_exists("GetSQLValueString")) { function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue; $theValue = function_exists("mysql_real_escape_string") ? mysql_real_escape_string($theValue) : mysql_escape_string($theValue); switch ($theType) { case "text": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "long": case "int": $theValue = ($theValue != "") ? intval($theValue) : "NULL"; break; case "double": $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL"; break; case "date": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break;

53

case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } } mysql_select_db($database_cn2, $cn2); $query_Recordset1 = "SELECT idempleado, usuario, clave FROM empleado"; $Recordset1 = mysql_query($query_Recordset1, $cn2) or die(mysql_error()); $row_Recordset1 = mysql_fetch_assoc($Recordset1); $totalRows_Recordset1 = mysql_num_rows($Recordset1); ?><?php // *** Validate request to login to this site. if (!isset($_SESSION)) { session_start(); } $loginFormAction = $_SERVER['PHP_SELF']; if (isset($_GET['accesscheck'])) { $_SESSION['PrevUrl'] = $_GET['accesscheck']; } if (isset($_POST['usuario'])) { $loginUsername=$_POST['usuario']; $password=$_POST['contraseña']; $MM_fldUserAuthorization = "privilegio"; $MM_redirectLoginSuccess = "bienvenidaadmin.php"; $MM_redirectLoginFailed = "error.php"; $MM_redirecttoReferrer = false; mysql_select_db($database_cn2, $cn2); $LoginRS__query=sprintf("SELECT usuario, clave, privilegio FROM empleado WHERE usuario=%s AND clave=%s", GetSQLValueString($loginUsername, "text"), GetSQLValueString($password, "text")); $LoginRS = mysql_query($LoginRS__query, $cn2) or die(mysql_error()); $loginFoundUser = mysql_num_rows($LoginRS); if ($loginFoundUser) { $loginStrGroup = mysql_result($LoginRS,0,'privilegio'); //declare two session variables and assign them

54

$_SESSION['MM_Username'] = $loginUsername; $_SESSION['MM_UserGroup'] = $loginStrGroup; if (isset($_SESSION['PrevUrl']) && false) { $MM_redirectLoginSuccess = $_SESSION['PrevUrl']; } header("Location: " . $MM_redirectLoginSuccess ); } else { header("Location: ". $MM_redirectLoginFailed ); } } ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <form id="form1" name="form1" method="POST" action="<?php echo $loginFormAction; ?>"> <div align="center"> <table width="421" height="251" border="1"> <tr> <td><div align="center"> <p>Inicio de sesión</p> <table width="208" height="104" border="1"> <tr> <td width="74">Usuario</td> <td width="110"><label> <input type="text" name="usuario" id="usuario" /> </label></td> </tr> <tr> <td>Contraseña</td> <td><label> <input type="password" name="contraseña" id="contraseña" /> </label></td> </tr> <tr> <td> </td> <td><label> <input type="submit" value="Iniciar sesión" />

55

</label></td> </tr> </table> <p align="left"> </p> </div> <div align="center"></div> <div align="center"></div></td> </tr> </table> </div> <div align="center"></div> </form> <p> </p> </body> </html> <?php mysql_free_result($Recordset1); ?> Con el código anterior se valida al usuario, por medio de un nombre de Usuario y una contraseña, el sistema verifica que el usuario este registrado y al tiempo identifica el nivel de acceso y dependiendo de ello lo envía una siguiente ventana: si el privilegio es administrador lo enviará a la ventana P-1(bienvenidaadmin.php) y si el privilegio es empleado lo enviara a la ventana P-15(bienvenida.php).

56

9.6.2. Ingreso Administrador pantalla P-1 ILUSTRACIÓN 6. Pantalla P-1

Fuente: Autor

Codigo pantalla P-1

<?php if (!isset($_SESSION)) { session_start(); } $MM_authorizedUsers = "administrador";

57

$MM_donotCheckaccess = "false"; // *** Restrict Access To Page: Grant or deny access to this page function isAuthorized($strUsers, $strGroups, $UserName, $UserGroup) { // For security, start by assuming the visitor is NOT authorized. $isValid = False; // When a visitor has logged into this site, the Session variable MM_Username set equal to their username. // Therefore, we know that a user is NOT logged in if that Session variable is blank. if (!empty($UserName)) { // Besides being logged in, you may restrict access to only certain users based on an ID established when they login. // Parse the strings into arrays. $arrUsers = Explode(",", $strUsers); $arrGroups = Explode(",", $strGroups); if (in_array($UserName, $arrUsers)) { $isValid = true; } // Or, you may restrict access to only certain users based on their username. if (in_array($UserGroup, $arrGroups)) { $isValid = true; } if (($strUsers == "") && false) { $isValid = true; } } return $isValid; } $MM_restrictGoTo = "bienvenida.php"; if (!((isset($_SESSION['MM_Username'])) && (isAuthorized("",$MM_authorizedUsers, $_SESSION['MM_Username'], $_SESSION['MM_UserGroup'])))) { $MM_qsChar = "?"; $MM_referrer = $_SERVER['PHP_SELF']; if (strpos($MM_restrictGoTo, "?")) $MM_qsChar = "&"; if (isset($QUERY_STRING) && strlen($QUERY_STRING) > 0) $MM_referrer .= "?" . $QUERY_STRING; $MM_restrictGoTo = $MM_restrictGoTo. $MM_qsChar . "accesscheck=" . urlencode($MM_referrer); header("Location: ". $MM_restrictGoTo); exit; }

58

?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <p>Bienvenido Administrador</p> <table width="561" height="451" border="1"> <tr> <td width="425"><div align="center"> <p>En el momento no esta disponible el servicio de infomacion del estado de los productos, servicios y facturación</p> <p> </p> <p>Disculpe las molestias </p> </div></td> <td width="120"><form id="form1" name="form1" method="post" action=""> <fieldset> <legend>Productos</legend> <p align="left"><a href="creaproductos.php">Crear</a></p> <p align="left"><a href="actulizarprod.php">Actualizar</a></p> <p align="left"><a href="eliminaprod.php">Eliminar</a></p> </fieldset> <p align="center"> <legend></legend> </p> <fieldset> <legend>Proveedores</legend> <p align="left"><a href="creaproveedor.php">Crear</a></p> <p align="left"><a href="actualizaprov.php">Modificar</a></p> <p align="left"><a href="eliminaprov.php">Eliminar</a></p> </fieldset> <fieldset> <legend>Empleados</legend> <p><a href="creaempleado.php">Crear </a></p> <p><a href="actualizaemp.php">Modificar</a></p> <p><a href="eliminaemp.php">Eliminar</a></p> <fieldset> </fieldset> </fieldset> </form> <p> </p></td>

59

</tr> </table> <p> </p> <p> </p> </body> </html>

9.6.3. Registro Usuario pantalla P-4 ILUSTRACIÓN 7. Pantalla P-4

Fuente: Autor

Código Pantalla P-4

<?php require_once('../Connections/cn2.php'); ?> <?php if (!function_exists("GetSQLValueString")) { function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue; $theValue = function_exists("mysql_real_escape_string") ? mysql_real_escape_string($theValue) : mysql_escape_string($theValue); switch ($theType) { case "text": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";

60

break; case "long": case "int": $theValue = ($theValue != "") ? intval($theValue) : "NULL"; break; case "double": $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL"; break; case "date": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } } $editFormAction = $_SERVER['PHP_SELF']; if (isset($_SERVER['QUERY_STRING'])) { $editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']); } if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] == "form2")) { $insertSQL = sprintf("INSERT INTO empleado (idempleado, nombreemp, telefonoemp, direccionemp, usuario, clave, correo, privilegio) VALUES (%s, %s, %s, %s, %s, %s, %s, %s)", GetSQLValueString($_POST['idempleado'], "int"), GetSQLValueString($_POST['nombreemp'], "text"), GetSQLValueString($_POST['telefonoemp'], "text"), GetSQLValueString($_POST['direccionemp'], "text"), GetSQLValueString($_POST['usuario'], "text"), GetSQLValueString($_POST['clave'], "text"), GetSQLValueString($_POST['correo'], "text"), GetSQLValueString($_POST['privilegio'], "text")); mysql_select_db($database_cn2, $cn2); $Result1 = mysql_query($insertSQL, $cn2) or die(mysql_error()); $insertGoTo = "listaempleados.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; }

61

header(sprintf("Location: %s", $insertGoTo)); } ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <form action="<?php echo $editFormAction; ?>" method="post" name="form2" id="form2"> <p align="center">Crear Empleado</p> <table align="center"> <tr valign="baseline"> <td nowrap="nowrap" align="right">Idempleado:</td> <td><input type="text" name="idempleado" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Nombreemp:</td> <td><input type="text" name="nombreemp" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Telefonoemp:</td> <td><input type="text" name="telefonoemp" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Direccionemp:</td> <td><input type="text" name="direccionemp" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Usuario:</td> <td><input type="text" name="usuario" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Clave:</td> <td><input type="text" name="clave" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Correo:</td> <td><input type="text" name="correo" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Privilegio:</td>

62

<td><input type="text" name="privilegio" value="" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right"> </td> <td><input type="submit" value="Insertar registro" /> <label><a href="bienvenidaadmin.php">volver</a></label></td> </tr> </table> <input type="hidden" name="MM_insert" value="form2" /> </form> <p> </p> </body> </html>

9.6.4. Actualizar empleado

ILUSTRACIÓN 8. Actualizar empleado

63

Codigo pantalla actualizar empleado

<?php require_once('../Connections/cn2.php'); ?> <?php if (!function_exists("GetSQLValueString")) { function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue; $theValue = function_exists("mysql_real_escape_string") ? mysql_real_escape_string($theValue) : mysql_escape_string($theValue); switch ($theType) { case "text": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "long": case "int": $theValue = ($theValue != "") ? intval($theValue) : "NULL"; break; case "double": $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL"; break; case "date": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } } $currentPage = $_SERVER["PHP_SELF"]; $editFormAction = $_SERVER['PHP_SELF']; if (isset($_SERVER['QUERY_STRING'])) { $editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']); }

64

if ((isset($_POST["MM_update"])) && ($_POST["MM_update"] == "form1")) { $updateSQL = sprintf("UPDATE empleado SET nombreemp=%s, telefonoemp=%s, direccionemp=%s, usuario=%s, clave=%s, correo=%s, privilegio=%s WHERE idempleado=%s", GetSQLValueString($_POST['nombreemp'], "text"), GetSQLValueString($_POST['telefonoemp'], "text"), GetSQLValueString($_POST['direccionemp'], "text"), GetSQLValueString($_POST['usuario'], "text"), GetSQLValueString($_POST['clave'], "text"), GetSQLValueString($_POST['correo'], "text"), GetSQLValueString($_POST['privilegio'], "text"), GetSQLValueString($_POST['idempleado'], "int")); mysql_select_db($database_cn2, $cn2); $Result1 = mysql_query($updateSQL, $cn2) or die(mysql_error()); $updateGoTo = "actemp.php"; if (isset($_SERVER['QUERY_STRING'])) { $updateGoTo .= (strpos($updateGoTo, '?')) ? "&" : "?"; $updateGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $updateGoTo)); } $maxRows_rsempleado = 1; $pageNum_rsempleado = 0; if (isset($_GET['pageNum_rsempleado'])) { $pageNum_rsempleado = $_GET['pageNum_rsempleado']; } $startRow_rsempleado = $pageNum_rsempleado * $maxRows_rsempleado; mysql_select_db($database_cn2, $cn2); $query_rsempleado = "SELECT * FROM empleado"; $query_limit_rsempleado = sprintf("%s LIMIT %d, %d", $query_rsempleado, $startRow_rsempleado, $maxRows_rsempleado); $rsempleado = mysql_query($query_limit_rsempleado, $cn2) or die(mysql_error()); $row_rsempleado = mysql_fetch_assoc($rsempleado); if (isset($_GET['totalRows_rsempleado'])) { $totalRows_rsempleado = $_GET['totalRows_rsempleado']; } else { $all_rsempleado = mysql_query($query_rsempleado); $totalRows_rsempleado = mysql_num_rows($all_rsempleado); }

65

$totalPages_rsempleado = ceil($totalRows_rsempleado/$maxRows_rsempleado)-1; $queryString_rsempleado = ""; if (!empty($_SERVER['QUERY_STRING'])) { $params = explode("&", $_SERVER['QUERY_STRING']); $newParams = array(); foreach ($params as $param) { if (stristr($param, "pageNum_rsempleado") == false && stristr($param, "totalRows_rsempleado") == false) { array_push($newParams, $param); } } if (count($newParams) != 0) { $queryString_rsempleado = "&" . htmlentities(implode("&", $newParams)); } } $queryString_rsempleado = sprintf("&totalRows_rsempleado=%d%s", $totalRows_rsempleado, $queryString_rsempleado); ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <form id="form1" name="form1" method="POST" action="<?php echo $editFormAction; ?>"> <p align="center">Actualizar Empleado</p> <table align="center"> <tr valign="baseline"> <td nowrap="nowrap" align="right">Idempleado:</td> <td><input type="text" name="idempleado" value="<?php echo $row_rsempleado['idempleado']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Nombreemp:</td> <td><input type="text" name="nombreemp" value="<?php echo $row_rsempleado['nombreemp']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Telefonoemp:</td>

66

<td><input type="text" name="telefonoemp" value="<?php echo $row_rsempleado['telefonoemp']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Direccionemp:</td> <td><input type="text" name="direccionemp" value="<?php echo $row_rsempleado['direccionemp']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Usuario:</td> <td><input type="text" name="usuario" value="<?php echo $row_rsempleado['usuario']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Clave:</td> <td><input type="text" name="clave" value="<?php echo $row_rsempleado['clave']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Correo:</td> <td><input type="text" name="correo" value="<?php echo $row_rsempleado['correo']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Privilegio:</td> <td><input type="text" name="privilegio" value="<?php echo $row_rsempleado['privilegio']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right"> </td> <td><input type="submit" value="Modificar" /></td> </tr> </table> <p align="center"> <div align="center"> <table border="0"> <tr> <td><?php if ($pageNum_rsempleado > 0) { // Show if not first page ?> <a href="<?php printf("%s?pageNum_rsempleado=%d%s", $currentPage, 0, $queryString_rsempleado); ?>"><img src="./First.gif" border="0" /></a> <?php } // Show if not first page ?> </td> <td><?php if ($pageNum_rsempleado > 0) { // Show if not first page ?> <a href="<?php printf("%s?pageNum_rsempleado=%d%s", $currentPage, max(0, $pageNum_rsempleado - 1), $queryString_rsempleado); ?>"><img src="./Previous.gif" border="0" /></a>

67

<?php } // Show if not first page ?> </td> <td><?php if ($pageNum_rsempleado < $totalPages_rsempleado) { // Show if not last page ?> <a href="<?php printf("%s?pageNum_rsempleado=%d%s", $currentPage, min($totalPages_rsempleado, $pageNum_rsempleado + 1), $queryString_rsempleado); ?>"><img src="./Next.gif" border="0" /></a> <?php } // Show if not last page ?> </td> <td><?php if ($pageNum_rsempleado < $totalPages_rsempleado) { // Show if not last page ?> <a href="<?php printf("%s?pageNum_rsempleado=%d%s", $currentPage, $totalPages_rsempleado, $queryString_rsempleado); ?>"><img src="./Last.gif" border="0" /></a> <?php } // Show if not last page ?> </td> </tr> </table> </p> Registros <?php echo ($startRow_rsempleado + 1) ?> a <?php echo min($startRow_rsempleado + $maxRows_rsempleado, $totalRows_rsempleado) ?> de <?php echo $totalRows_rsempleado ?> </div> <p> </p> <input type="hidden" name="MM_update" value="form1" /> </form> </body> </html> <?php mysql_free_result($rsempleado); ?>

68

10. CONCLUSIONES El uso de herramientas de modelado como MySQL Workbench facilita en gran medida la creación de bases de datos relacionales ya que permite exportar el código SQL, solo con realizar los diagramas entidad relación lo que produce un ahorro considerable en la construcción física de la base de datos además de evitar errores de digitación. Un aspecto importante a resaltar es la conexión que se realiza entre la herramienta dreamweaver CS3 y la base de datos lo cual permite generar sitios web que interactúan de manera dinámica con la base de datos, y utilizando la pestaña “aplicación” de dreamweaver se puede tener una visión global de la base de datos, inclusive antes de generar el código dreamweaver genera pantallazos de las consultas que se quieren realizar. Fue acertada la decisión de elegir el ciclo de vida prototipado ya que permitió al cliente participar activamente en la construcción y aprobación de los prototipos presentados y se genero una retroalimentación entre el cliente y el desarrollador del proyecto.

69

11. RECOMENDACIONES Antes de utilizar alguna herramienta de diseño de bases de datos cerciórese que esta pueda generar y exportar el código SQL, ya que existen muchas aplicaciones que no lo hacen. Para explotar al máximo la herramienta dreamweaver y su conexión con las bases de datos deberá documentarse sobre la opción objetos de datos de dreamweaver CS3. Un software para la gestión de inventarios y ventas puede resolver en gran parte el problema que genera una mala administración. Uno de los problemas de la empresa es que se les complica llevar la contabilidad de los planes celulares, una opción alternativa que se recomienda es implementar un Gateway gsm con conexión a un computador para llevar un mejor control de los planes.

70

REFERENCIAS BIBLIOGRAFICAS Universidad de Coruña; Rodriguez Penabad, Miguel; Gonzalez Ares, Luis. (25 de 05 de 2010). www.udc.es. Recuperado el 30 de 05 de 2011, de http://coba.dc.fi.udc.es/~bd/bd2/#bd2_prf: http://coba.dc.fi.udc.es/~bd/bd2/MySQLWB/tutorialWB.html

Adobe Systems Incorporated. (2007). http://livedocs.adobe.com/es_ES/Dreamweaver/9.0/. Recuperado el 20 de 05 de 2011, de http://livedocs.adobe.com/es_ES/Dreamweaver/9.0/

Casillas Santillan, L. A., Gilbert Ginestá, M., & Pérez Mora, Ó. (17 de 02 de 2003). http://ocw.uoc.edu/. Recuperado el 30 de 05 de 2011, de http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/Course_listing: http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/Course_listing

Costal Costa, D. (2008). http://ocw.uoc.edu/. Recuperado el 30 de 05 de 2011, de http://ocw.uoc.edu/informatica-tecnologia-y-multimedia/bases-de-datos: http://ocw.uoc.edu/informatica-tecnologia-y-multimedia/bases-de-datos/materiales/

Gilbert Ginestá, M. (17 de 02 de 2003). http://ocw.uoc.edu/. Recuperado el 30 de 05 de 2011, de http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/Course_listing: http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/Course_listing

Oracle. (2011). http://dev.mysql.com. Recuperado el 30 de 05 de 2011, de http://dev.mysql.com/doc/workbench/en/index.html: http://dev.mysql.com/doc/workbench/en/index.html

Universidad de Sevilla. (17 de 02 de 2003). http://www.cs.us.es/. Recuperado el 30 de 05 de 2011, de http://www.cs.us.es/cursos/bd-2002/HTML/modeloER.htm#entidades_relaciones: http://www.cs.us.es/cursos/bd-2002/HTML/modeloER.htm#entidades_relaciones

Weitzenfeld, A. (2002). INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS. Mexico: ITAM.

71

www.wikipedia.org. (27 de 04 de 2011). www.wikipedia.org. Recuperado el 30 de 05 de 2011, de http://es.wikipedia.org/wiki/CS3

www.wikipedia.org. (28 de 05 de 2011). www.wikipedia.org. Recuperado el 02 de 06 de 2011, de http://es.wikipedia.org/wiki/Adobe_Dreamweaver

72

APENDICE

Codigo para eliminar empleados

<?php require_once('../Connections/cn2.php'); ?> <?php if (!function_exists("GetSQLValueString")) { function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue; $theValue = function_exists("mysql_real_escape_string") ? mysql_real_escape_string($theValue) : mysql_escape_string($theValue); switch ($theType) { case "text": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "long": case "int": $theValue = ($theValue != "") ? intval($theValue) : "NULL"; break; case "double": $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL"; break; case "date": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } } if ((isset($_POST['idempleado'])) && ($_POST['idempleado'] != "")) { $deleteSQL = sprintf("DELETE FROM empleado WHERE idempleado=%s", GetSQLValueString($_POST['idempleado'], "int")); mysql_select_db($database_cn2, $cn2); $Result1 = mysql_query($deleteSQL, $cn2) or die(mysql_error());

73

$deleteGoTo = "mselemp.php"; if (isset($_SERVER['QUERY_STRING'])) { $deleteGoTo .= (strpos($deleteGoTo, '?')) ? "&" : "?"; $deleteGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $deleteGoTo)); } mysql_select_db($database_cn2, $cn2); $query_rsempleado = "SELECT * FROM empleado"; $rsempleado = mysql_query($query_rsempleado, $cn2) or die(mysql_error()); $row_rsempleado = mysql_fetch_assoc($rsempleado); $totalRows_rsempleado = mysql_num_rows($rsempleado); ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <form id="form1" name="form1" method="post" action=""> <p> </p> <table align="center"> <tr valign="baseline"> <td nowrap="nowrap" align="right">Idempleado:</td> <td><input type="text" name="idempleado" value="<?php echo $row_rsempleado['idempleado']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Nombreemp:</td> <td><input type="text" name="nombreemp" value="<?php echo $row_rsempleado['nombreemp']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Telefonoemp:</td> <td><input type="text" name="telefonoemp" value="<?php echo $row_rsempleado['telefonoemp']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Direccionemp:</td> <td><input type="text" name="direccionemp" value="<?php echo $row_rsempleado['direccionemp']; ?>" size="32" /></td>

74

</tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Usuario:</td> <td><input type="text" name="usuario" value="<?php echo $row_rsempleado['usuario']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Clave:</td> <td><input type="text" name="clave" value="<?php echo $row_rsempleado['clave']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Correo:</td> <td><input type="text" name="correo" value="<?php echo $row_rsempleado['correo']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right">Privilegio:</td> <td><input type="text" name="privilegio" value="<?php echo $row_rsempleado['privilegio']; ?>" size="32" /></td> </tr> <tr valign="baseline"> <td nowrap="nowrap" align="right"> </td> <td><input type="submit" value="Eliminar" /></td> </tr> </table> <p> </p> </form> </body> </html> <?php mysql_free_result($rsempleado); ?>

Codigo para ver el estado de los productos

<?php require_once('../Connections/cn2.php'); ?> <?php if (!function_exists("GetSQLValueString")) { function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue;

75

$theValue = function_exists("mysql_real_escape_string") ? mysql_real_escape_string($theValue) : mysql_escape_string($theValue); switch ($theType) { case "text": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "long": case "int": $theValue = ($theValue != "") ? intval($theValue) : "NULL"; break; case "double": $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL"; break; case "date": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } } $currentPage = $_SERVER["PHP_SELF"]; $maxRows_reproductos = 10; $pageNum_reproductos = 0; if (isset($_GET['pageNum_reproductos'])) { $pageNum_reproductos = $_GET['pageNum_reproductos']; } $startRow_reproductos = $pageNum_reproductos * $maxRows_reproductos; mysql_select_db($database_cn2, $cn2); $query_reproductos = "SELECT * FROM producto"; $query_limit_reproductos = sprintf("%s LIMIT %d, %d", $query_reproductos, $startRow_reproductos, $maxRows_reproductos); $reproductos = mysql_query($query_limit_reproductos, $cn2) or die(mysql_error()); $row_reproductos = mysql_fetch_assoc($reproductos); if (isset($_GET['totalRows_reproductos'])) { $totalRows_reproductos = $_GET['totalRows_reproductos']; } else {

76

$all_reproductos = mysql_query($query_reproductos); $totalRows_reproductos = mysql_num_rows($all_reproductos); } $totalPages_reproductos = ceil($totalRows_reproductos/$maxRows_reproductos)-1; $queryString_reproductos = ""; if (!empty($_SERVER['QUERY_STRING'])) { $params = explode("&", $_SERVER['QUERY_STRING']); $newParams = array(); foreach ($params as $param) { if (stristr($param, "pageNum_reproductos") == false && stristr($param, "totalRows_reproductos") == false) { array_push($newParams, $param); } } if (count($newParams) != 0) { $queryString_reproductos = "&" . htmlentities(implode("&", $newParams)); } } $queryString_reproductos = sprintf("&totalRows_reproductos=%d%s", $totalRows_reproductos, $queryString_reproductos); ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> </head> <body> <table border="2" cellpadding="3" cellspacing="2"> <tr> <td>idproducto</td> <td>nombrepro</td> <td>tipopro</td> <td>cantidad_disponible</td> <td>cantidad_minima</td> <td>imagenpro</td> <td>proveedor_idproveedor</td> </tr> <?php do { ?> <tr> <td><?php echo $row_reproductos['idproducto']; ?></td> <td><?php echo $row_reproductos['nombrepro']; ?></td>

77

<td><?php echo $row_reproductos['tipopro']; ?></td> <td><?php echo $row_reproductos['cantidad_disponible']; ?></td> <td><?php echo $row_reproductos['cantidad_minima']; ?></td> <td><?php echo $row_reproductos['imagenpro']; ?></td> <td><?php echo $row_reproductos['proveedor_idproveedor']; ?></td> </tr> <?php } while ($row_reproductos = mysql_fetch_assoc($reproductos)); ?> </table> <p> <table border="0"> <tr> <td><?php if ($pageNum_reproductos > 0) { // Show if not first page ?> <a href="<?php printf("%s?pageNum_reproductos=%d%s", $currentPage, 0, $queryString_reproductos); ?>"><img src="./First.gif" border="0" /></a> <?php } // Show if not first page ?> </td> <td><?php if ($pageNum_reproductos > 0) { // Show if not first page ?> <a href="<?php printf("%s?pageNum_reproductos=%d%s", $currentPage, max(0, $pageNum_reproductos - 1), $queryString_reproductos); ?>"><img src="./Previous.gif" border="0" /></a> <?php } // Show if not first page ?> </td> <td><?php if ($pageNum_reproductos < $totalPages_reproductos) { // Show if not last page ?> <a href="<?php printf("%s?pageNum_reproductos=%d%s", $currentPage, min($totalPages_reproductos, $pageNum_reproductos + 1), $queryString_reproductos); ?>"><img src="./Next.gif" border="0" /></a> <?php } // Show if not last page ?> </td> <td><?php if ($pageNum_reproductos < $totalPages_reproductos) { // Show if not last page ?> <a href="<?php printf("%s?pageNum_reproductos=%d%s", $currentPage, $totalPages_reproductos, $queryString_reproductos); ?>"><img src="./Last.gif" border="0" /></a> <?php } // Show if not last page ?> </td> </tr> </table> </p> Registros <?php echo ($startRow_reproductos + 1) ?> a <?php echo min($startRow_reproductos + $maxRows_reproductos, $totalRows_reproductos) ?> de <?php echo $totalRows_reproductos ?> </body> </html> <?php

78

mysql_free_result($reproductos); ?>

DISEÑO Y DESARROLLO DE UN SISTEMA COMPUTACIONAL BASADO EN ...

Documents

Transcript of DISEÑO Y DESARROLLO DE UN SISTEMA COMPUTACIONAL BASADO EN ...