Proyecto final

  • 313 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
313
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SEP DGEST INSTITUTO TECNOLOGICO DE TUXTEPEC MATERIA: TALLER DE INVESTIGACION I MC. AIDA PACHECO ANTONIO UNIDAD 2 “DESARROLLO DE UN SISTEMA DE BASE DE DATOS DEL SERVICIO MECANICO REVAL SA/CV EN TUXTEPEC, OAXACA” PRESENTAN: VANESSA ACEVEDO TEODORO ROSA MARIA CRISTOBAL JOAQUIN ELIZABETH MENESES MIGUEL LAURA HELENA PEREZ CALDERON Semestre: 6 Grupo: A AREA: ING. INFORMATICA Mayo de 2013
  • 2. CONTENIDO INTRODUCCION ............................................................................................... 6 ANTECEDENTES DEL PROBLEMA.................................................................. 9 PLANTEAMIENTO DEL PROBLEMA ...............................................................11 OBJETIVOS ..................................................................................................... 12 OBJETIVO GENERAL .................................................................................. 12 OBJETIVOS ESPECIFICOS ......................................................................... 12 JUSTIFICACIÓN ........................................................................................... 12 ALCANCES Y LIMITACIONES ..................................................................... 13 FORMULACIÓN DE HIPÓTESIS.................................................................. 13 MARCO TEORICO ........................................................................................... 14 1.- BASE DE DATOS........................................................................................ 14 1.1 ¿QUÉ SON LAS BD? .............................................................................. 14 1.2 EVOLUCIÓN DE LAS BD ....................................................................... 15 1.3 Arquitecturas de las BD ........................................................................... 16 2.- Herramientas CASE. ................................................................................... 17 2.1 ¿Qué son? .............................................................................................. 17 2.2 Objetivos ................................................................................................. 18 2.3 Clasificación ............................................................................................ 19 2.4 EJEMPLOS ............................................................................................. 20 Herramientas Abiertas ............................................................................... 20 Herramientas Comerciales/Cerradas ......................................................... 20 3. BOUML......................................................................................................... 21 3.1 INTRODUCCIÓN ................................................................................... 21 3.2 ENTORNO ............................................................................................. 22 3.3. INSTALACIÓN ....................................................................................... 22 4. LENGUAJE JAVA. ........................................................................................ 23
  • 3. 4.1 ¿QUÉ ES? .............................................................................................. 23 4.2 EL LENGUAJE ........................................................................................ 23 4.3 APARIENCIA ........................................................................................... 24 4.5 RENDIMIENTO ....................................................................................... 24 5. MYSQL ......................................................................................................... 25 ESTUDIO DE FACTIBILIDAD .......................................................................... 26 FACTIBILIDAD TÉCNICA: ............................................................................ 26 FACTIBILIDAD ECONÓMICA: ...................................................................... 28 FACTIBILIDAD OPERATIVA: ........................................................................ 29 CRONOGRAMA DE ACTIVIDADES ................................................................ 31 ANÁLISIS DE LOS REQUERIMIENTOS.......................................................... 32 REQUERIMIENTOS FUNCIONALES. .......................................................... 32 CASO DE USO REQUERIMIENTOS DETALLADOS. .................................. 33 REQUERIMIENTOS DE SISTEMAS. ........................................................... 34 ANÁLISIS DE RIESGOS. ................................................................................. 35 ANEXOS .......................................................................................................... 37 DIAGRAMA DE CASOS DE USO: ................................................................... 37 CASOS DE USO .............................................................................................. 38 PRIMER CASO DE USO .............................................................................. 38 SEGUNDO CASO DE USO. ......................................................................... 40 TERCER CASO DE USO ............................................................................. 42 CUARTO CASO DE USO ............................................................................. 44 QUINTO CASO DE USO .............................................................................. 46 SEXTO CASO DE USO ................................................................................ 48 SEPTIMO CASO DE USO ............................................................................ 50 OCTAVO CASO DE USO.............................................................................. 52 NOVENO CASO DE USO ............................................................................. 53
  • 4. DECIMO CASO DE USO. ............................................................................. 54 DECIMO PRIMERO CASO DE USO. ........................................................... 56 DIAGRAMAS DE SECUENCIAS: ..................................................................... 58 ACCESO AL SISTEMA. ................................................................................ 58 ALTA DE AUTOMOVILES. ............................................................................ 58 BAJA DE AUTOMOVILES. ............................................................................ 59 EDICION DE AUTOMOVILES....................................................................... 59 CONSULTA AUTOMOVILES. ........................................................................ 60 ALTA MECANICOS. ...................................................................................... 60 BAJA MECANICOS....................................................................................... 61 EDICION MECANICOS. ............................................................................... 61 CONSULTA MECANICOS............................................................................. 62 REPORTES MECANICOS. ........................................................................... 62 REPORTES DE AUTOS. .............................................................................. 63 DIAGRAMAS DE CLASE .............................................................................. 64 CONCLUSION ................................................................................................. 71 BIBLIOGRAFIA. ............................................................................................... 72
  • 5. INDICE DE TABLAS Tabla 1 Requerimientos de Hardware .............................................................. 26 Tabla 2 Requerimientos de Software ................................................................ 27 Tabla 3 Caso de Uso de Requerimientos Detallados ....................................... 33 Tabla 4 Requerimientos Del Sistema ............................................................... 34 Tabla 5 Análisis de Riesgos .............................................................................. 36 Tabla 6 Primer Caso de Uso............................................................................. 38 Tabla 7Segundo Caso de Uso .......................................................................... 40 Tabla 8 Tercer Caso de Uso ............................................................................. 42 Tabla 9 Cuarto Caso de Uso ............................................................................ 44 Tabla 10 Quinto caso de Uso ........................................................................... 46 Tabla 11 Sexto Caso de Uso ............................................................................ 48 Tabla 12 Septimo Caso de Uso ........................................................................ 50 Tabla 13 Octavo Caso de Uso .......................................................................... 52 Tabla 14 Noveno Caso de Uso ......................................................................... 53 Tabla 15 Decimo Caso de Uso ......................................................................... 54 Tabla 16 Decimo Primer Caso de Uso ............................................................. 56
  • 6. INDICE DE FIGURAS Ilustración 1 Diagrama de Casos de Uso ......................................................... 37 Ilustración 2 Primer Caso de Uso ..................................................................... 38 Ilustración 3 Segundo Caso de Uso ................................................................. 40 Ilustración 4 Tercer Caso de Uso ..................................................................... 42 Ilustración 5 Cuarto Caso de Uso..................................................................... 44 Ilustración 6 Quinto Caso de Uso ..................................................................... 46 Ilustración 7 Octavo Caso de Uso .................................................................... 52 Ilustración 8 Noveno Caso de Uso ................................................................... 53 Ilustración 9 Decimo Caso de Uso ................................................................... 54 Ilustración 10 Decimo Primer Caso de Uso ...................................................... 56 Ilustración 11 Acceso al sistema....................................................................... 58 Ilustración 12 Alta de Automóviles .................................................................... 58 Ilustración 13 Baja de Autos ............................................................................. 59 Ilustración 14 Edicion Automoviles ................................................................... 59 Ilustración 15 Consulta Automóviles ................................................................. 60 Ilustración 16 Alta Mecánicos ........................................................................... 60 Ilustración 17 Baja Mecanicos .......................................................................... 61 Ilustración 18 Edicion Mecanicos ..................................................................... 61 Ilustración 19 Consulta Mecanicos ................................................................... 62 Ilustración 20 Reportes Mecanicos .................................................................. 62 Ilustración 21 Reportes Autos........................................................................... 63 Ilustración 22 Diagrama De Clase .................................................................... 64 Ilustración 23 Pantalla de Acceso al Sistema ................................................... 65 Ilustración 24 Pantalla Altas ............................................................................. 65 Ilustración 25 Pantalla Alta Autos ..................................................................... 66 Ilustración 26 Pantalla Alta Mecanicos ............................................................. 66 Ilustración 27 Pantalla Baja Autos .................................................................... 67 Ilustración 28 Pantalla Baja Mecanicos ............................................................ 67 Ilustración 29 Pantalla Consulta Autos ............................................................. 68 Ilustración 30 Pantalla Consulta Mecanicos ..................................................... 68 Ilustración 31 Ediciones Autos.......................................................................... 69
  • 7. Ilustración 32 Pantalla Edicion Mecanicos ....................................................... 69 Ilustración 33 Pantalla Reporte Autos .............................................................. 70 Ilustración 34 Pantalla Reporte Mecanicos ..................................................... 70
  • 8. INTRODUCCION Para el caso de este TALLER MECANICO que se encuentra dentro de las microempresas, el reto es aún mayor debido a la falta de capacitación y formación, que en ocasiones dificultan su fortalecimiento. El área de trabajo del TALLER MECANICO en general ha ido evolucionando durante los últimos años, iniciando con el número de trabajadores y su conocimiento en el ámbito. Los procesos que se llevan a cabo en el Taller Mecánico, REVAL. Ubicado en la calle colima Nº 178 interior col. Grajales. Tiene la finalidad de estandarizar la ejecución de los mismos, así como de los formatos utilizados dentro de cada uno de los procesos; y poner esta información al alcance de todo el personal que labora en el Taller Mecánico logrando así, hacer más fácil cada uno de los procesos y tratar de realizar innovaciones y mejoras continuas en las labores desarrolladas. Tendrá la capacidad para manejar de una forma eficiente y controlar las órdenes de reparaciones y servicios para el TALLER MECANICO. En el TALLER MECANICO todos los procesos son realizados manualmente, es por lo que se desea implementar un sistema que permita el realizar los servicios que ofrece el taller de mecánica y llevarlos a computadoras. Se espera que con este sistema se reduzcan mucho gasto por operación, se controle y se aumente de una manera positiva los ingresos que el TALLER MECANICO tiene.Permite que la información esté actualizada en todo momento. Uno de los más grandes retos de los últimos años es mantener la competitividad y los niveles de desarrollo, a fin de consolidar su permanencia dentro del mercado laboral.
  • 9. ANTECEDENTES DEL PROBLEMA El panorama general del TALER MECANICO REVAL. Se genera de la siguiente forma: Los servicios con los que cuenta son: Mecánica general Diagnósticos Servicio eléctrico Los objetivos globales de nuestro diagnostico se centran en el siguiente aspecto: Mejorar la posición competitiva del TALLER MECANICO en la comunidad. El proceso de este servicio, como todos sabemos comienza con el arribo de un cliente al establecimiento, se da un presupuesto del costo del servicio, es aceptada o rechazada por el cliente y se lleva acabo el trabajo. Sin embargo aquí es en donde situamos una de las problemáticas la principal es: la cadena de suministros del TALLER MECANICO, ya que no cuenta con una refaccionaria cercana o algún suministro/almacén de refacciones, con lo cual generamos una carencia en el servicio que este proporciona. Al requerir de alguna refacción para la compostura de algún servicio existe una pérdida de tiempo en cuestión de ausencia de la actividad de mano de obra de la persona que suministra este recurso al TALLER MERCANICO, así mismo genera un costo extra el gasto o consumo de gasolina generado por el transporte en busca de la pieza requerida. El TALLER MECANICO carece de una presentación más adecuada en cuestión de diseño, limpieza, orden, logotipo; así como el uniforme de los confortantes de la empresa, con una debida integración editorial.
  • 10. Las victimas dentro de esta situación, son los clientes que se acuden a este taller y que debido a la falta de refacciones en el negocio, el cliente tenga que buscar las piezas por su cuenta, la problemática que genera pérdida de tiempo a los cliente así como gastos al tener que buscar las refacciones en las diferente refaccionarias y al no encontrarlas en el establecimiento al que acuden, al buscarlas por su cuenta también origina que el cliente adquiera una pieza que no sea la adecuada para el mecánico y la rechace. Los aspectos críticos de esta situación es que se puede generar molestias entre los clientes del taller y darles una mala imagen, esto provocaría, a pesar de calidad de los trabajos que realizan los mecánicos que los clientes dejen de asistir al establecimiento y busquen otros talleres y todo esto lo vea reflejado el propietario en sus ganancias.
  • 11. PLANTEAMIENTO DEL PROBLEMA Aspectos que ahora se pretenden cambiar. Así mismo encontramos la necesidad de implementar un sistema o control de clientes para brindar un servicio de atención más completo y sobre todo de calidad. La presencia de este programa incrementaría la competitividad del TALLER MECANICO, ya que se tendrá un servicio más, que en estos tiempos está teniendo un auge impresionante; la calidad del servicio al cliente. Llevando el control de cada cliente así como el control de sus servicios periódicos que se le han realizado. Los cambios que se requieren para solucionar la problemática es la adquisición de refacciones con un proveedor directo y venderlas a un precio justo al cliente y así se disminuyan los tiempos de servicio y se obtengan la satisfacción del cliente. También se pretende la elaboración de un programa en el cual se establezca una base de datos generado de los servicios prestados y que en base a ellos arroje pronósticos de la demandas de refacciones, en cuanto a cantidades y tipo de piezas para adquirir con los proveedores. Y de esta manera mejorar la posición competitiva del TALLER MERCANICO. El enfoque a utilizar en la elaboración del sistema es el de pronósticos de la demanda ya que el propósito fundamental de los pronósticos es hacer buenas estimaciones en la cuales basar los modelos para la toma de decisiones. Los pronósticos constituyen la problemática fundamental dentro de la gestión de la actividad de una empresa debido a la complejidad de los problemas encontrados cuando se pronostica y a su impacto sobre todas las decisiones de la empresa.
  • 12. OBJETIVOS OBJETIVO GENERAL Análisis y Diseño de un sistema de información para una empresa de servicio mecánico, “RAVEL” OBJETIVOS ESPECIFICOS Diseñar un sistema para la base de datos del servicio mecánico. Hacer propuestas demejora para la empresa. Acercar tanto a la empresa como a los usuarios, a la tecnología. Brindar a la empresa mayor competitividad en el mercado. JUSTIFICACIÓN La información se constituye como uno de los activos más valiosos para toda empresa puesto que de ella depende la toma de decisiones que puede afectarla o lograr un papel fundamental en su crecimiento económico. Teniendo en cuenta este punto de vista se recomienda dar un tratamiento especial ala manera de cómo se manipulan o se operan los datos en los diferentes sistemas de información; a la forma de cómo se procesa y especifica que usuarios son los que pueden tener acceso a determinados datos; es decir, que solo sean personas debidamente autorizadas. Lo anterior se logra a través de sistemas automatizados que permiten salvaguardar la información. Con ello pretendemos, contribuir al crecimiento de la empresa, y la expansión de sus horizontes tecnológicos, brindarles un mejor servicio a los clientes, y en consecuencia aumentar los ingresos económicos, tanto para el dueño, como para los empleados laborando en ella.
  • 13. ALCANCES Y LIMITACIONES El sistema a desarrollar llevara registro controlado de la información de los movimientos y servicios brindados, con el fin de obtener todos los datos necesarios de cada uno de una forma organizada, confiable y correcta. El sistema se realizara para uso exclusivo del Taller mecánico. Con esto se lograra optimizar el servicio, con la automatización de procesos, ahorrar tiempo e incrementar los ingresos, brindándole así una capacidad de crecimiento en el mercado laboral, a mediano plazo. A pesar de que el sistema llevara un registro actualizado de altas y bajas de los datos contenidos en él, no será transferible a otro Negocio, aunque sea del mismo ramo. Otra de las posibles limitaciones, podría presentarse al dejar de utilizar el sistema, no darle mantenimiento o posiblemente no realizar las respectivas actualizaciones en él, o en dado caso, que en el proceso de implementación se agotaran los recursos necesarios para la conclusión del proyecto. FORMULACIÓN DE HIPÓTESIS Los beneficios que se obtendrán al análisis y desarrollo de un sistema para el registro y control de procesos para el taller mecánico „‟REVAL‟‟, son el manejo acertado de la información institucional, cuyos resultados pretenden: Un apoyo de amplia dimensión para realizar las actividades en el sistema a través de la sistematización. Alto porcentaje de utilidad tanto para los directivos como para todo el personal. Satisfacción total y expectativas para la implementación de software. Control de los procesos, datos y registros generados por los servicios brindados.
  • 14. MARCO TEORICO 1.- BASE DE DATOS 1.1 ¿QUÉ SON LAS BD? Una base de datos (cuya abreviatura es BD) es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente está relacionado con el de red ya que se debe poder compartir esta información. De allí el término base. "Sistema de información" es el término general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado.
  • 15. 1.2 EVOLUCIÓN DE LAS BD Principio: Bibliotecas, censos, archivos médicos, Desarrollaron principios básicos utilizados hoy como los índices (fichas ordenadas de las bibliotecas) Década 1960-1970: Primeras bases de datos: Aplicaciones Ad-hoc, Orientadas a registro Poco eficientes, propensos a errores Modelos en red y jerárquico Año 1969: Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks de Edgar F.Codd Proponía separar el modelo lógico del físico Bases del modelo relacional, el más utilizado hoy En los años 70 aparecen las primeras bases de datos relacionales: Ingres SystemR 1976: Chen propone el diagrama Entidad-Relación 1980: Los sistemas relacionales comienzan a utilizarse de forma habitual SQL se hace el lenguaje estándar para BBDD Aparecen numerosas compañías como RIM, RBASE 5000, PARADOX, OS/2 Database Manager, Dbase III, IV (después Foxbase y Visual FoxPro), Watcom SQL Los modelos jerárquicos y de red van dejando de ser utilizados
  • 16. 1990s: Aparece Internet Se buscan técnicas para acceder de forma remota y segura a los datos: JDBC, Oracle Server 2000…. 2000‟s: Quedan sólo 3 grandes compañías: IBM, Microsoft, Oracle Nuevas técnicas y problemas: almacenes y minerías de datos, OLAP ¿Futuro? XML con XPath y XQuery BBDD con terabytes de información 1.3 Arquitecturas de las BD La arquitectura de un sistema de base de datos está influenciada en gran medida por el sistema informático subyacente en el que se ejecuta el sistema de base de datos. En la arquitectura de un sistema de base de datos se reflejan aspectos como la conexión en red, el paralelismo y la distribución: La arquitectura centralizada es la más clásica. En ella, el SGBD está implantado en una sola plataforma u ordenador desde donde se gestiona directamente, de modo centralizado, la totalidad de los recursos. Es la arquitectura de los centros de proceso de datos tradicionales. Se basa en tecnologías sencillas, muy experimentadas y de gran robustez. La conexión en red de varias computadoras permite que algunas tareas se ejecuten en un sistema servidor y que otras se ejecuten en los sistemas clientes. Esta división de trabajo ha conducido al desarrollo de sistemas de bases de datos cliente-servidor.
  • 17. La distribución de datos a través de las distintas sedes o departamentos de una organización permite que estos datos residan donde han sido generados o donde son más necesarios, pero continuar siendo accesibles desde otros lugares o departamentos diferentes. El hecho de guardar varias copias de la base de datos en diferentes sitios permite que puedan continuar las operaciones sobre la base de datos aunque algún sitio se vea afectado por algún desastre natural, como una inundación, un incendio o un terremoto. Se han desarrollado los sistemas de bases de datos distribuidos para manejar datos distribuidos geográfica o administrativamente a lo largo de múltiples sistemas de bases de datos. El procesamiento paralelo dentro de una computadora permite acelerar las actividades del sistema de base de datos, proporcionando a las transacciones unas respuestas más rápidas, así como la capacidad de ejecutar más transacciones por segundo. Las consultas pueden procesarse de manera que se explote el paralelismo ofrecido por el sistema informático subyacente. La necesidad del procesamiento paralelo de consultas ha conducido al desarrollo de los sistemas de bases de datos paralelos. No debe confundirse el SGBD con la arquitectura que se elige para implantarlo. Algunos SGBD sólo se pueden implantar en una de las arquitecturas y otros en todas ellas. 2.- Herramientas CASE. 2.1 ¿Qué son? Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas
  • 18. pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras. Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer). 2.2 Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software. 2. Aumentar la calidad del software. 3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos. 4. Mejorar la planificación de un proyecto 5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos. 6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto. 7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación 8. Gestión global en todas las fases de desarrollo de software con una misma herramienta. 9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
  • 19. 2.3 Clasificación Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros: 1. Las plataformas que soportan. 2. Las fases del ciclo de vida del desarrollo de sistemas que cubren. 3. La arquitectura de las aplicaciones que producen. 4. Su funcionalidad. La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación. Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones. Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación. Meta CASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del meta-modelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.
  • 20. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa. Por funcionalidad podríamos diferenciar algunas como: Herramientas de generación semiautomática de código. Editores UML. Herramientas de Refactorización de código. Herramientas de mantenimiento como los sistemas de control de versiones· 2.4 EJEMPLOS Herramientas Abiertas Umbrello ArgoUML Gaphor Herramientas Comerciales/Cerradas Rational Rose Together System Architect Visual Paradigm Poseidon
  • 21. 3. BOUML 3.1 INTRODUCCIÓN Habitualmente suelo utilizar el UML en las aplicaciones que construimos en Autentia. El uso que le suelo dar es para usarlo como herramienta de análisis y diseño que me ayude a descubrir nuevos aspectos del sistema y debatir estos con mis compañeros, o para documentar ciertas partes importantes del sistema. Para realizar este tipo de tareas suelo utilizar el ArgoUML: herramienta Java gratuita, que, aunque sencilla, cubre mis necesidades (además tiene una cosa bastante curiosa que es que te va criticando el modelo intentando descubrir fallos o deficiencias). Pero en este tutorial no os quiero hablar del ArgoUML, os quiero hablar del BOUML. Esta también es una herramienta CASE gratuita (licencia GPL) que he descubierto hoy y que me parece una muy buena alternativa porque: Permite trabajar con UML 2 (ArgoUML todavía no lo permite). Soporta gran cantidad de diagramas (incluidos los de secuencia que en el ArgoUML funcionan una versión si y otra no, a ver si terminan de estabilizarlo ;) Es rápida y apenas consume memoria. Es sencilla de utilizar. Puedes generar código para Java, C++ e IDL (y controlar bastante la generación), y puedes hacer reingeniería inversa (a partir del código sacar el modelo). También es capaz de generar documentación en varios formatos (HTML, XMI, ...) Puedes trabajar en grupo con sus módulos "Project Control" y "Project Synchro".
  • 22. Y además, aunque no es Java, también es multiplataforma: Linux, MacOS y Windows. En definitiva, todas estas características y su bajo precio (0 :) la convierten en una alternativa por lo menos digna de evaluar (ya veremos que nos dice el tiempo y el uso ;) 3.2 ENTORNO El tutorial está escrito usando el siguiente entorno: Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD). Sistema Operativo: GNU / Linux, Debian (unstable), Kernel 2.6.21, KDE 3.5 BOUML 2.29 3.3. INSTALACIÓN Como siempre, en Debian, la instalación resulta sumamente sencilla. Basta con hacer: # Apt-get bouml bouml-plugouts-src Si tenemos otro sistema operativo, siempre podemos ir a la página http://bouml.free.fr/download.html y descargar la versión que nos interese. En http://bouml.free.fr/ además también podemos encontrar mucha documentación que está bastante bien, y otros tutoriales (en inglés y francés).
  • 23. 4. LENGUAJE JAVA. 4.1 ¿QUÉ ES? Java es un lenguaje de programación de alto nivel orientado a objetos, desarrollado por James Gosling en 1995. El lenguaje en sí mismo toma mucha de su sintaxis de C, Cobol y Visual Basic, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria. La memoria es gestionada mediante un recolector de basura. 4.2 EL LENGUAJE En un sentido estricto, Java no es un lenguaje absolutamente orientado a objetos, a diferencia de, por ejemplo, Ruby o Smalltalk. Por motivos de eficiencia, Java ha relajado en cierta medida el paradigma de orientación a objetos, y así por ejemplo, no todos los valores son objetos. El código Java puede ser a veces redundante en comparación con otros lenguajes. Esto es en parte debido a las frecuentes declaraciones de tipos y conversiones de tipo manual (casting). También se debe a que no se dispone de operadores sobrecargados, y a una sintaxis relativamente simple. Sin embargo, J2SE 5.0 introduce elementos para tratar de reducir la redundancia, como una nueva construcción para los bucles „‟‟foreach‟‟‟. A diferencia de C++, Java no dispone de operadores de sobrecarga definidos por el usuario. Los diseñadores de Java tomaron esta decisión puesto que consideraban que, bajo ciertas circunstancias, esta característica podía complicar la lectura y mantenimiento de los programas.
  • 24. 4.3 APARIENCIA La apariencia externa (el „„„look and feel‟‟‟) de las aplicaciones GUI (Graphical User Interface) escritas en Java usando la plataforma Swing difiere a menudo de la que muestran aplicaciones nativas. Aunque el programador puede usar el juego de herramientas AWT (Abstract Windowing Toolkit) que genera objetos gráficos de la plataforma nativa, el AWT no es capaz de funciones gráficas avanzadas sin sacrificar la portabilidad entre plataformas; ya que cada una tiene un conjunto de APIs distinto, especialmente para objetos gráficos de alto nivel. Las herramientas de Swing, escritas completamente en Java, evitan este problema construyendo los objetos gráficos a partir de los mecanismos de dibujo básicos que deben estar disponibles en todas las plataformas. El inconveniente es el trabajo extra requerido para conseguir la misma apariencia de la plataforma destino. Aunque esto es posible (usando GTK+ y el Look-andFeel de Windows), la mayoría de los usuarios no saben cómo cambiar la apariencia que se proporciona por defecto por aquella que se adapta a la de la plataforma. 4.5 RENDIMIENTO El bytecode de Java puede ser interpretado en tiempo de ejecución por la máquina virtual, o bien compilado al cargarse el programa, o durante la propia ejecución, para generar código nativo que se ejecuta directamente sobre el hardware. Si es interpretado, será más lento que usando el código máquina intrínseco de la plataforma destino. Si es compilado, durante la carga inicial o la ejecución, la penalización está en el tiempo necesario para llevar a cabo la compilación.
  • 25. 5. MYSQL MySQL es la base de datos open source más popular y, posiblemente, mejor del mundo. Su continuo desarrollo y su creciente popularidad están haciendo de MySQL un competidor cada vez más directo de gigantes en la materia de las bases de datos como Oracle. MySQL es un sistema de administración de bases de datos (Database Management System, DBMS) para bases de datos relacionales. Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza múltiples tablas para almacenar y organizar la información. MySQL fue escrito en C y C++ y destaca por su gran adaptación a diferentes entornos de desarrollo, permitiendo su interactuación con los lenguajes de programación más utilizados como PHP, Perl y Java y su integración en distintos sistemas operativos. También es muy destacable, la condición de open source de MySQL, que hace que su utilización sea gratuita e incluso se pueda modificar con total libertad, pudiendo descargar su código fuente. Esto ha favorecido muy positivamente en su desarrollo y continuas actualizaciones, para hacer de MySQL una de las herramientas más utilizadas por los programadores orientados a Internet.
  • 26. ESTUDIO DE FACTIBILIDAD Una vez definida la problemática establecida anteriormente, es necesario realizar un estudio de factibilidad para determinar la infraestructura y la capacidad técnica que implica la implantación del sistema. Con este sistema es posible determinar las posibilidades de diseñar el sistema propuesto, considerando tres áreas: FACTIBILIDAD TÉCNICA: La factibilidad técnica consistió en realizar una evolución tecnológica existente en el Taller mecánico, este estudio estuvo destinado a recolectar información sobre los componentes técnicos que posee esta entidad (Taller) y la posibilidad de hacer uso de los mismos en el desarrollo e implementación del sistema a realizar. De acuerdo a la tecnología necesaria para la implementación del Taller Mecánico, se evaluó bajo dos enfoques: Hardware y software: Hardware: Necesariamente el servidor donde debe estar instalado el sistema propuesto, debe de cubrir con los siguientes requerimientos mínimos: Hardware requerido: Cantidad: 01 Descripción: - Microsoft Windows XP Professional - En Windows XP: Procesador Pentium 4 o AMD Athlon de doble núcleo a 1.6 GHz. - 2 GB de Memoria RAM. - 250 GB en disco duro. Tabla 1 Requerimientos de Hardware
  • 27. Software: Con el software, ya contamos con aplicaciones que emplearan para el diseño del proyecto y funcionamiento del sistema lo cual no es necesario invertir en la adquisición del mismo. Las estaciones de trabajo operaran bajo el ambiente de Windows. Software requerido: Cantidad: Descripción: Funcionalidad: 01 Windows Sistema 01 BOUML Herramienta case para el modelado del sistema 01 Java y NetBeans Lenguaje programación de para el desarrollo del sistema 01 MySQL Gestor de base de datos para la administración de la información 01 Apache Para la administración de sitios web Tabla 2 Requerimientos de Software
  • 28. FACTIBILIDAD ECONÓMICA: A continuación se presenta un estudio que dio como resultado la factibilidad económica del desarrollo del nuevo sistema. Se determinaron los recursos para desarrollar, implantar, y mantener enoperación el sistema programado.Se determinó el análisis de costos y beneficios. Análisis Costos-Beneficios Este análisis permitió hacer una comparación entre la relación costosdel sistema actual, y los costos que tendría un nuevo sistema, conociendo deantemano los beneficios que la ciencia de la Informática ofrece. Beneficios Tangibles Los beneficios tangibles aportados por el sistema propuesto están dados por los siguientes aspectos: Ahorro de tiempo Ahorro de espacio La información se procesara más rápido Información confiable Aumento de ingresos Se podrá generar reportes inmediatamente. Beneficios Intangibles. Entre los beneficios intangibles del sistema propuesto se pueden incluir: Generar información más eficiente y confiable, que sirva de apoyo a la toma de decisiones
  • 29. Mejor capacidad de búsqueda y actualización de información, reduciendo la fuerza de trabajo en el proceso y control de recursos. Mayor y mejor aprovechamiento de los recursos del Taller mecánico. Optimizar las actividades dentro del Taller aumentando la productividad del personal. Un control y seguimiento de los actores involucrados en el proceso de gestión, que permite un mejor y más efectivo empleo de los recursos del Taller. Mejor privacidad de información Aumentará la satisfacción del cliente La calidad del servicio aumentara. Relación Costo-Beneficio. El Análisis Costo-Beneficio presenta grandes ventajas para la organización, ya que la misma cuenta con los recursos técnicos necesarios (hardware y software) para el diseño, desarrollo e implantación del nuevo sistema. De igual manera, el nuevo sistema trae mejoras significativas para el normal desenvolvimiento de las actividades manera el tiempo de dentro del taller, reduciendo de esta procesamiento y generación de la información, disminuyendo las cargas de trabajo a los usuarios, ya que la velocidad de procesamiento, veracidad y confiabilidad de los procesos y resultados serán los deseados. FACTIBILIDAD OPERATIVA: La Factibilidad Operativa permite predecir, si se pondrá en marcha el sistema propuesto, aprovechando los beneficios que ofrece, a todos losusuarios involucrados con el mismo (personal) ya sean los que interactúan en formadirecta con este, como también aquellos que reciben información producidapor el sistema.
  • 30. La necesidad y deseo de un sistema, llevo a la aceptación de diseñarlo,de unamanerasencilla y amigable, que cubratodossusrequerimientos, expectativas y proporcione la información en formaoportuna y confiable. Con la finalidad de garantizar el buen funcionamiento del sistema y que este impactará en forma positiva a los usuarios, (Administrador, Encargado y Mecánico) el mismo serádesarrollado en forma estándar, presentando una interfaz amigable al usuario, lo que se traduce en una herramienta de fácil manejo y comprensión, tanto las pantallas como los reportes serán familiares a los operadores, contando con la opinión de los mismos para cualquier modificación del sistema.
  • 31. CRONOGRAMA DE ACTIVIDADES. Febrero IDENTIFICACION DEL PROBLEMA PLATEAMIENTO DEL PROBLEMA OBJETIVOS GENERAL Y ESPECIFICO GENERALIDADES DESARROLLO DEL TEMA ESTUDIO DE FACTIBILIDAD ANÁLISIS DE LOS REQUERIMIENTOS ANALASIS DE RIESGOS DOCUMENTACION (DIAGRAMAS) CONCLUSIONES Marzo Marzo Abril Abril Mayo
  • 32. ANÁLISIS DE LOS REQUERIMIENTOS. REQUERIMIENTOS FUNCIONALES. Actores. LISTA DE ACTORES ID Nombre Descripción AS – 1 Administrador Se encarga del control total de todo lo establecido en el sistema. AS –2 Encargado Verifica las acciones en el sistema (Altas, consultas). AS –3 Mecánico AS-4 Base de Datos Se encarga de ediciones en el sistema. Se encarga del registro de los autos de entradas y salidas en el sistema. Tabla 3 Actores en el Sistema
  • 33. CASO DE USO REQUERIMIENTOS DETALLADOS. LISTA DE REQUERIMIENTOS DETALLADOS ID Acción Descripción CU-1 Altas El Administrador es el encargado de dar de alta, baja, cambiar o consultar los nombres del personal trabajando y de los clientes. Así mismo el Encargado también tiene podrá dar de alta. CU-2 Bajas El sistema permitirá solamente al administrador dar de baja al personal, al igual que los clientes. CU-3 Ediciones El sistema permitirá al Administrador, y al Mecánico accesar al sistema, cuando el nombre de los clientes y/o clientes hayan sido modificado o cambiado. C4-4 Consultas El sistema permitirá al Administrador, Encargado, Mecánico; pueden registrar la alta de los vehículos, registrando la marca, placa, modelo, color, costo. CU-5 Acceso a la BD El sistema permitirá al administrador que puede eliminar la información de la base de datos de algún cliente. Tabla 3Caso de Uso de Requerimientos Detallados
  • 34. REQUERIMIENTOS DE SISTEMAS. LISTA DE REQUERIMIENTOS DE SISTEMAS ID Descripción RS-1 Microsoft Windows XP Professional RS-2 En Windows XP: Procesador Pentium 4 o AMD Athlon de doble núcleo a 1.6 GHz. RS-3 2 GB de Memoria RAM. RS-4 250 GB en disco duro. Tabla 4 Requerimientos Del Sistema
  • 35. ANÁLISIS DE RIESGOS. ANÁLISIS DE RIESGOS Riesgo El plan Probabilidad del Impacto Aceptación Plan de Acción Alto Critica Tolerable Definir los recursos y servicio está mal el servicio con el balanceado cliente, para así de esta manera encontrar el balance de ellos mismos. El plan no concuerda Alto Desastrosa Tolerable con Analizar y replantear las ventajas y las expectativas desventajas del plan reales. buscando mas apego a las expectativas. Se puede dar Alto Grave Tolerable Supervisar cada una menor prioridad delas a desarrollar con el fin las tareas importantes. tareas a de que se lleven a cabo con la prioridad que les es correspondida. Los del miembros cuerpo trabajo no Alto Critica Tolerable Se debe contar con de un miembro extra se para que lo encuentran remplacen en caso disponibles. de no disponible. estar
  • 36. El tiempo solicitud Alto Critica Inaceptable Modificar el tiempo de asignado para poder servicio es muy brindar un servicio corto adecuado. El servicio Alto Critica Tolerable requerido contingencia, requiere tiempo Realizar un plan de más de presentando posibles lo opciones estimado para realización la del servicio. La presión disminuye Alto Critica Inaceptable la Revisar la programación cada productividad de las una de tareas programadas. La fecha de Alto Critico Inaceptables Planear los alcances entrega ha sido e cambiada sin ajustes para evitar en considerar los lo posible una nueva alcances implementar modificación en la fecha de entrega. El Alto Critico Inadmisible Se debe, reasignar la desconocimiento realización de algunas áreas tareas, con el fin de repercute en el encargarla a alguien tiempo con de realización de conocimientos sean necesarios. Tabla 5 Análisis de Riesgos las los que
  • 37. ANEXOS DIAGRAMA DE CASOS DE USO: Ilustración 1 Diagrama de Casos de Uso
  • 38. CASOS DE USO PRIMER CASO DE USO. Ilustración 2 Primer Caso de Uso Caso de Uso: Acceso al sistema Actores: Administrador, Sistema. Propósito: Permitir ingresar al sistema para realizar las actividades. Resumen: El administrador introduce su nombre de usuario y contraseña, para poder entrar al sistema. CURSO NORMAL DE EVENTOS. ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. El administrador entra al sistema de bienvenida. 2. El Sistema muestra una interfaz gráfica que permite que el administrador introduzca su nombre de usuario y contraseña. 3. El administrador introduce su nombre de usuario y contraseña. 4. El Sistema verifica los datos con la base de datos. 5. Una vez verificados los datos si estos son correctos se obtiene el acceso autorizado al sistema. Tabla 6 Primer Caso de Uso
  • 39. CURSOS ALTERNOS Paso 3: Si en caso ocurre algún error al introducir los datos de usuario y contraseña, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 2: La interfaz consiste en una ventana donde estará escrito que tipo de datos le pide al administrador, en este caso su nombre de usuario y contraseña, y cuenta con un botón de ENTRAR para acceder automáticamente.
  • 40. SEGUNDO CASO DE USO. Ilustración 3 Segundo Caso de Uso Caso de Uso: Dar de alta a los Automóviles. Actores: Administrador, Sistema, Base de Datos. Propósito: Permitir dar de alta a todos los autos que llegan al Servicio Mecánico para cualquier reparación o mantenimiento. Resumen: El administrador entra al sistema, y captura los datos del Auto que se va a reparar o dar mantenimiento. CURSO NORMAL DE EVENTOS. ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. El administrador entra al sistema y elige la opción de dar de alta automóviles. 2. El Sistema muestra una interfaz gráfica que permite que el administrador capture los datos de los automóviles. 3. El administrador introduce o captura 4. El Sistema guarda los datos en la los datos del automóvil en el sistema. base de datos 5. Una vez guardado esos datos, permite que se introduzca otro automóvil o salir de la aplicación. Tabla 7Segundo Caso de Uso
  • 41. CURSOS ALTERNOS Paso 3: Si en caso ocurre algún error al guardar los datos de los Automóviles en la base de datos, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 2:La interfaz consiste en una ventana donde estará escrito que tipo de datos le pide para cada automóvil y delante de ellos el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 42. TERCER CASO DE USO Bajo de autos Ilustración 4 Tercer Caso de Uso Caso de uso: dar de baja autos. Actores: administrador, encargado, mecánico. Propósito: permite dar de baja al auto que entran al taller mecánico. Resumen: el administrador entra al sistema y captura los datos del auto que dará de baja. CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR 1. El administrador entra RESPUESTA DEL SISTEMA al sistema y elije la opción dar de baja al auto. 2. El sistema muestra una interfaz gráfica que le permite que el administrador capture los datos del auto. 3. El administrador captura los datos del auto en el sistema. 4. El sistema guarda los datos en la base de datos. 5. Una vez guardado los datos, permite que se capture otro auto o salir de la aplicación. Tabla 8 Tercer Caso de Uso
  • 43. CURSOS ALTERNOS Paso 1. En caso de que ocurra un error al guardar los datos del auto en la base de datos, el sistema notificara un mensaje de error al administrador para que vuelva introducir los datos. NOTAS Paso 1. La interfaz consiste en una ventana con label‟s donde estará escrito que tipo de datos le pide para cada auto y delante de él, el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 44. CUARTO CASO DE USO Ediciones de autos Ilustración 5 Cuarto Caso de Uso Caso de uso: ediciones de autos Actores: administrador, sistema, base de datos Propósito: permitir dar ediciones de autos que entran al taller mecánico. Resumen: el administrador entre al sistema y captura los datos de los autos que entran al taller mecánico. CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR 1. El administrador entra RESPUESTA DEL SISTEMA al sistema y elige la opción dar ediciones al auto 2. El Sistema muestra una interfaz gráfica que permite que el administrador capture los datos de los autos. 3.- 3. El administrador introduce o captura los datos del auto en el sistema. 4. El Sistema guarda los datos en la base de datos 5. Una vez guardado esos datos, permite que se introduzca otro equipo o salir de la aplicación. Tabla 9 Cuarto Caso de Uso
  • 45. CURSOS ALTERNOS Paso 3: Si en caso ocurre algún error al guardar los datos de los autos en la base de datos, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 2: La interfaz consiste en una ventana con label‟s donde estará escrito que tipo de datos le pide para cada auto y delante de ellos el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 46. QUINTO CASO DE USO Realizar consultas autos Ilustración 6 Quinto Caso de Uso Caso de Uso: Dar consultas a los autos Actores: Administrador, Sistema, Base de Datos. Propósito: Permitir dar consultas a los autos que entran al taller mecánico. Resumen: El administrador entra al sistema, y captura los datos del auto que entran al taller mecánico. ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El administrador entra al sistema y elige la opción de consulta de autos. 2. El Sistema muestra una interfaz gráfica que permite que el administrador consulte los datos de los autos. 3. Una vez consultada la información permite que el administrador pueda consultar otro equipo o salir de la aplicación. Tabla 10 Quinto caso de Uso
  • 47. Cursos Alternos Paso 3: Si en caso ocurre algún error al guardar los datos de los autos en la base de datos, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 3: La interfaz consiste en una ventana con label‟s donde estará escrito que tipo de datos le pide para cada autos y delante de ellos el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 48. SEXTO CASO DE USO Caso de uso: Dar de alta a los mecánicos. Actores: Administrador, Encargado y Base de datos. Propósito: Permitir dar de alta a los mecánicos para accesar al sistema. Resumen: El administrador accede al sistema para capturar los datos de los mecánicos que trabajaran en el Taller. ACCIÓN DEL ACTOR 1. El administrador entra RESPUESTA DEL SISTEMA al sistema y elige la opción dar de alta a los mecánicos. 2. El sistema muestra una interfaz que permitirá que el administrador pueda capturar los datos de los mecánicos. 3. El administrador introduce 4. El sistema guarda los datos de los datos de los mecánicos a los mecánicos dar de alta. en la base de datos 5. Una vez introducidos los datos de los mecánicos, permite elegir entre si se introduce otro usuario o salir de la aplicación. Tabla 11 Sexto Caso de Uso
  • 49. CURSOS ALTERNOS Paso 3: Si en alguno de los casos ocurre un erro al momento de guardar los datos de los mecánicos en la base de datos, el sistema le notificara un mensaje de error al administrador para que vuelva a introducir los datos correctamente. Paso 2: La interfaz consiste en una ventana de etiquetas donde está escrito que tipo de datos le pide a cada mecánico y un cuadro de datos donde puede introducir los datos al sistema.
  • 50. SEPTIMO CASO DE USO Caso de uso: Dar de baja a los mecánicos Actores: El Administrador, Encargado y la Base de datos Propósito: Permitir eliminar (dar de baja) a él (s) mecánicos del sistema. Resumen: El administrador y/o encargado acceden al sistema y capturan los datos del mecánico que desean eliminar (dar de baja). ACCIÓN DE ACTOR RESPUESTA DEL SISTEMA 1. El administrador o sistema entra al sistema i elige la opción de eliminar mecánicos. 2. El Sistema muestra una interfaz gráfica que permite que el administrador capture los o encargado datos de los mecánicos que desea dar de baja. 3. El administrador o encargado 4. El sistema elimina a los introduce o captura los datos mecánicos que se dieron de del mecánico a eliminar en el baja. sistema. 5. Una vez actualizado los datos, permite eliminar otro mecánico o salir de la aplicación. Tabla 12 Septimo Caso de Uso
  • 51. CURSOS ALTERNOS Paso 3: Si en algún caso ocurre error al eliminar un usuario en la base de datos, el sistema le notificara con un mensaje de error al administrador o encargado y que vuelva a introducir los datos. NOTAS: Paso 2: La interfaz consiste en una ventana con etiquetas donde estará escrito que tipo de datos le pide para cada mecánico que desea eliminar y delante de ellos el sistema. cuadro de texto donde pueda introducir esos datos, al
  • 52. OCTAVO CASO DE USO Ilustración 7 Octavo Caso de Uso Caso de uso: Ediciones de Mecánicos. Actores: Administrador, Sistema, Base de Datos. Propósito: Modificar los Datos Contenidos en la BD, en casa de modificaciones. Resumen: El administrador, accesa al sistema y elije los datos almacenados a modificar. ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1.- El administrador accesa al sistema y elije la opción de Ediciones de Mecánicos 2.- El sistema muestra la interfaz para realizar las ediciones. 3.- El administrador introduce los 4.- El sistema guarda los datos, en la datos que desea editar. BD. El sistema muestra un mensaje informando que los datos se han guardado. Tabla 13 Octavo Caso de Uso Notas: Paso 2: La interfaz consiste en una ventana con etiquetas donde estará indicada la información requerida para llenar el campo seleccionado para su edición. Casos alternos: Paso 3: En caso ocurrir algún error al guardar los datos en la base de datos, el sistema le informara mediante un mensaje de error al administrador y pedirá que vuelva a introducir los datos.
  • 53. NOVENO CASO DE USO Ilustración 8 Noveno Caso de Uso Caso de uso: Consulta de Mecánicos. Actores: Administrador, Sistema, Base de Datos. Propósito: Consultar Datos Contenidos en la BD, referentes a los mecánicos registrados. Resumen: El administrador, accesa al sistema y elije consultar los datos almacenados, referente a los mecánicos. ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1.- El administrador accesa al sistema y elije la opción de Consulta de mecánicos 2.- El sistema accesa a la BD para elegir los datos a mostrar. 3.- El administrador consulta. Realiza la 4.- El sistema cierra la aplicación. Tabla 14 Noveno Caso de Uso Notas: Paso 2: La interfaz consiste en una ventana que mostrara los datos pertenecientes a los mecánicos registrados, y que fueron almacenados en la BD. Casos alternos: Paso 3: En caso ocurrir algún error de consulta, el sistema le informara mediante un mensaje de error al administrador y pedirá que vuelva a realizar la consulta.
  • 54. DECIMO CASO DE USO. Ilustración 9 Decimo Caso de Uso Caso de Uso: REPORTES DE LOS MECANICOS Actores: Administrador, Sistema, Base de Datos. Propósito: Permitir Los reportes de los mecánicos dentro del taller. Resumen: El administrador entra al sistema, y captura los datos del reporte de cada mecánico que están laborando dentro del taller. CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. El administrador entra al sistema y elige la opción de reporte de los mecánicos 2. El Sistema muestra una interfaz gráfica que permite que el administrador capture el reporte que se debe hacer a cada mecánico. 3. El administrador introduce o captura los 4. El Sistema guarda los datos en la datos de los mecánicos dentro del sistema. base de datos 5. Una vez guardado esos datos, permite que se introduzca otro reporte o salir de la aplicación. Tabla 15 Decimo Caso de Uso
  • 55. Cursos Alternos Paso 3: Si en caso ocurre algún error al guardar los datos de los reportes en la base de datos, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 2: La interfaz consiste en una ventana con label‟s donde estará escrito que tipo de datos le pide para cada mecánico y delante de ellos el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 56. DECIMO PRIMERO CASO DE USO. Ilustración 10 Decimo Primer Caso de Uso Caso de Uso: REPORTES DE AUTOS ATENDIDOS Actores: Administrador, Sistema, Base de Datos. Propósito: Permitir Los reportes de los autos que ya se atendieron en el taller. Resumen: El administrador entra al sistema, y captura los datos del reporte de cada auto que ya fue atendido y compuesto dentro del taller. CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. El administrador entra al sistema y elige la opción de reporte de autos atendidos 2. El Sistema muestra una interfaz gráfica que permite que el administrador capture el reporte de cada auto que ya fue atendido. 3. El administrador introduce o captura los 4. El Sistema guarda los datos en la datos de los reporte de autos dentro del base de datos sistema. 5. Una vez guardado esos datos, permite que se introduzca otro reporte o salir de la aplicación. Tabla 16 Decimo Primer Caso de Uso
  • 57. Cursos alternos Paso 3: Si en caso ocurre algún error al guardar los datos de los reportes de los autos atendidos en la base de datos, el sistema le notificara con un mensaje de error al administrador y que vuelva a introducir los datos. Notas Paso 2: La interfaz consiste en una ventana con label‟s donde estará escrito que tipo de datos le pide para reporte de los carros y delante de ellos el cuadro de texto donde pueda introducir esos datos, al sistema.
  • 58. DIAGRAMAS DE SECUENCIAS: ACCESO AL SISTEMA. Ilustración 11 Acceso al sistema ALTA DE AUTOMOVILES. Ilustración 12 Alta de Automóviles
  • 59. BAJA DE AUTOMOVILES. Ilustración 13 Baja de Autos EDICION DE AUTOMOVILES. Ilustración 14 Edicion Automoviles
  • 60. CONSULTA AUTOMOVILES. Ilustración 15 Consulta Automóviles ALTA MECANICOS. Ilustración 16 Alta Mecánicos
  • 61. BAJA MECANICOS. Ilustración 17 Baja Mecanicos EDICION MECANICOS. Ilustración 18 Edicion Mecanicos
  • 62. CONSULTA MECANICOS. Ilustración 19 Consulta Mecanicos REPORTES MECANICOS. Ilustración 20 Reportes Mecanicos
  • 63. REPORTES DE AUTOS. Ilustración 21 Reportes Autos
  • 64. DIAGRAMAS DE CLASE Ilustración 22 Diagrama De Clase
  • 65. La pantalla de acceso al sistema, es la primer pantalla que aparece al abrir la aplicación, en ella se ingresara un nombre de usuario y contraseña, para poder ver, editar y agregar información. Ilustración 23 Pantalla de Acceso al Sistema La segunda pantalla nos mostrara el menú con las opciones disponibles. Solo el administrador tendrá acceso a todas las funciones del menú. Ilustración 24 Pantalla Altas
  • 66. La primer opción del menú es „ALTAS‟ en la opción „AUTOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se almacenara en la base de datos. Ilustración 25 Pantalla Alta Autos La primer opción del menú es „ALTAS‟ en la opción „MECANICOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se almacenara en la base de datos Ilustración 26 Pantalla Alta Mecanicos
  • 67. La segunda opción del menú es „BAJAS‟ en la opción „AUTOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser eliminada. Ilustración 27 Pantalla Baja Autos La segunda opción del menú es „BAJAS‟ en la opción „MECANICOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser eliminada. Ilustración 28 Pantalla Baja Mecanicos
  • 68. La tercer opción del menú es „CONSULTAS‟ en la opción „AUTOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser mostrada en pantalla. Ilustración 29 Pantalla Consulta Autos La tercer opción del menú es „CONSULTAS‟ en la opción „MECANICOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser Ilustración 30 Pantalla Consulta Mecanicos mostrada en pantalla.
  • 69. La cuarta opción del menú es „EDICIONES‟ en la opción „AUTOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser modificada y almacenada. Ilustración 31 Ediciones Autos La cuarta opción del menú es „EDICIONES‟ en la opción „MECANICOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para ser modificada y almacenada Ilustración 32 Pantalla Edicion Mecanicos
  • 70. La quinta opción del menú es „REPORTESS‟ en la opción „AUTOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para generar un reporte que se mostrara en pantalla. Ilustración 33 Pantalla Reporte Autos La quinta opción del menú es „REPORTES‟ en la opción „MECANICOS‟ mostrara esta pantalla y en ella los campos a llenar con la información necesaria que posterior mente se buscara en la base de datos para generar un reporte que se mostrara en pantalla. Ilustración 34 Pantalla Reporte Mecanicos
  • 71. CONCLUSION El modelado de sistemas nos ayuda a implementar nuevas tecnologías en la vida diaria y aporta gran solidez a empresas que desean una mejor organización de datos más confiable. El sistema se planea para que sea una interfaz fácil de utilizar y sobre todo entendible para todos los usuarios que tengan acceso a las funciones del sistema, Por otra parte se planea introducir la tecnología y utilización de sistemas de bases de datos, para un mejor manejo y organización de la información. El hecho de poder manejar un requerimiento como un Objeto hace de los use cases una herramienta sumamente poderosa en el manejo y especificación de requerimientos. El desarrollo del sistema está basado esencialmente en la integración de dos estándares utilizados en los procesos que realiza el servicio mecánico. El modelado esta implementado utilizando el lenguaje de programación Java, facilitando de este modo ampliamente la re-escritura. Al desarrollar el sistema notamos que se permite observar si realmente se está modelando lo que se desea y lo que se espera del proceso.Hemos Comprobado que el desarrollo del sistema del servicio mecánico nos sirve para realizar las labores que en el mundo real que podrían ser un poco complicadas debido a la falta de organización dentro de un taller, este sistema esta planeado para diseñarse apoyándonos en las herramientas sencillas como UML y generador de tablas como WorkBench.
  • 72. BIBLIOGRAFIA. Thomas Connolly; Database Systems: A practical approach to design, implementation and management; Second Edition; Addison-Wesley. Capítulo 19. Abraham Silberschartz; Fundamentos de bases de datos; tercera edición; Mc Graw Hill. Capítulos 16, 18. David M. Kroenke; Procesamiento de bases de datos; 5ª edición; Prentice Hall; Capítulo 16. Gary N. Hansen, James V. Hansen; Diseño y administración de bases de datos; 2ª edición; Prentice Hall; Capítulos 1, 9.