Proyecto final
93
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
-
Upload
helena-perez-calderon -
Category
Documents
-
view
469 -
download
0
Transcript of Proyecto final
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
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
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
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
INDICE DE TABLAS
Tabla 1 Requerimientos de Hardware...............................................................24
Tabla 2 Requerimientos de Software.................................................................25
Tabla 3 Caso de Uso de Requerimientos Detallados........................................31
Tabla 4 Requerimientos Del Sistema................................................................32
Tabla 5 Análisis de Riesgos...............................................................................34
Tabla 6 Primer Caso de Uso.............................................................................36
Tabla 7Segundo Caso de Uso...........................................................................38
Tabla 8 Tercer Caso de Uso..............................................................................40
Tabla 9 Cuarto Caso de Uso.............................................................................42
Tabla 10 Quinto caso de Uso............................................................................44
Tabla 11 Sexto Caso de Uso.............................................................................46
Tabla 12 Septimo Caso de Uso.........................................................................48
Tabla 13 Octavo Caso de Uso...........................................................................50
Tabla 14 Noveno Caso de Uso..........................................................................51
Tabla 15 Decimo Caso de Uso..........................................................................52
Tabla 16 Decimo Primer Caso de Uso..............................................................54
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
Ilustración 32 Pantalla Edicion Mecanicos........................................................69
Ilustración 33 Pantalla Reporte Autos...............................................................70
Ilustración 34 Pantalla Reporte Mecanicos......................................................70
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.
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.
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.
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.
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 de mejora 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 a la 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.
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.
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.
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
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.
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
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.
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.
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
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".
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).
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.
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-and-
Feel 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.
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.
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: Descripción:
01 - 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
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 de
programación 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
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 en
operació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 costos del
sistema actual, y los costos que tendría un nuevo sistema, conociendo de
antemano 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
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 dentro del taller, reduciendo de esta
manera el tiempo de 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 los usuarios
involucrados con el mismo (personal) ya sean los que interactúan en forma
directa con este, como también aquellos que reciben información producida por
el sistema.
La necesidad y deseo de un sistema, llevo a la aceptación de diseñarlo, de una
manera sencilla y amigable, que cubra todos sus requerimientos, expectativas
y proporcione la información en forma oportuna 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.
CRONOGRAMA DE ACTIVIDADES.
Febrero Marzo Marzo Abril Abril MayoIDENTIFICACION DEL PROBLEMAPLATEAMIENTO DEL PROBLEMAOBJETIVOS GENERAL Y ESPECIFICO
GENERALIDADES
DESARROLLO DEL TEMA
ESTUDIO DE FACTIBILIDADANÁLISIS DE LOS REQUERIMIENTOS
ANALASIS DE RIESGOSDOCUMENTACION (DIAGRAMAS)
CONCLUSIONES
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 Se encarga de ediciones en el sistema.
AS-4 Base de Datos Se encarga del registro de los autos de entradas
y salidas en el sistema.
Tabla 3 Actores en el Sistema
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 3 Caso de Uso de Requerimientos Detallados
REQUERIMIENTOS DE SISTEMAS.
LISTA DE REQUERIMIENTOS DE SISTEMAS
ID Descripción
RS-1 Microsoft Windows XP Professional
RS-2En 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
ANÁLISIS DE RIESGOS.
ANÁLISIS DE RIESGOS
Riesgo Probabilidad Impacto Aceptación Plan de Acción
El plan del
servicio está mal
balanceado
Alto Critica Tolerable Definir los recursos y
el servicio con el
cliente, para así de
esta manera
encontrar el balance
de ellos mismos.
El plan no
concuerda con
las expectativas
reales.
Alto Desastrosa Tolerable Analizar y replantear
las ventajas y
desventajas del plan
buscando mas apego
a las expectativas.
Se puede dar
menor prioridad
a las tareas
importantes.
Alto Grave Tolerable Supervisar cada una
delas tareas a
desarrollar con el fin
de que se lleven a
cabo con la prioridad
que les es
correspondida.
Los miembros
del cuerpo de
trabajo no se
encuentran
disponibles.
Alto Critica Tolerable Se debe contar con
un miembro extra
para que lo
remplacen en caso
de no estar
disponible.
El tiempo
solicitud de
servicio es muy
corto
Alto Critica Inaceptable Modificar el tiempo
asignado para poder
brindar un servicio
adecuado.
El servicio
requerido
requiere más
tiempo de lo
estimado
Alto Critica Tolerable Realizar un plan de
contingencia,
presentando posibles
opciones para la
realización del
servicio.
La presión
disminuye la
productividad
Alto Critica Inaceptable Revisar la
programación de
cada una de las
tareas programadas.
La fecha de
entrega ha sido
cambiada sin
considerar los
alcances
Alto Critico Inaceptables Planear los alcances
e implementar
ajustes para evitar en
lo posible una nueva
modificación en la
fecha de entrega.
El
desconocimiento
de algunas áreas
repercute en el
tiempo de
realización
Alto Critico Inadmisible Se debe, reasignar la
realización de las
tareas, con el fin de
encargarla a alguien
con los
conocimientos que
sean necesarios.
Tabla 5 Análisis de Riesgos
ANEXOS
DIAGRAMA DE CASOS DE USO:
Ilustración 1 Diagrama de Casos de Uso
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
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.
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 los datos del automóvil en el sistema.
4. El Sistema guarda los datos en la base de datos5. Una vez guardado esos datos, permite que se introduzca otro automóvil o salir de la aplicación.
Tabla 7Segundo Caso de Uso
Ilustración 3 Segundo Caso de Uso
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.
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 RESPUESTA DEL SISTEMA1. El administrador entra 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
Bajo de autos
Ilustración 4 Tercer Caso de Uso
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.
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 RESPUESTA DEL SISTEMA
1. El administrador entra 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.
Ediciones de autos
Ilustración 5 Cuarto Caso de Uso
Tabla 9 Cuarto Caso de Uso
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.
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
Realizar consultas autos
Ilustración 6 Quinto Caso de Uso
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.
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 RESPUESTA DEL SISTEMA
1. El administrador entra 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
los datos de los mecánicos a
dar de alta.
4. El sistema guarda los datos de
los mecánicos 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
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.
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 o encargado
capture los datos de los
mecánicos que desea dar de
baja.
3. El administrador o encargado
introduce o captura los datos
del mecánico a eliminar en el
sistema.
4. El sistema elimina a los
mecánicos que se dieron de
baja.
5. Una vez actualizado los datos,
permite eliminar otro mecánico
o salir de la aplicación.
Tabla 12 Septimo Caso de Uso
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 cuadro de texto donde pueda introducir esos datos, al
sistema.
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 datos que desea editar.
4.- El sistema guarda los datos, en la BD.El sistema muestra un mensaje informando que los datos se han guardado.
Ilustración 7 Octavo Caso de Uso
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.
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 Realiza la consulta.
4.- El sistema cierra la aplicación.
Notas:
Ilustración 8 Noveno Caso de Uso
Tabla 14 Noveno Caso de Uso
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.
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
datos de los mecánicos dentro del sistema.
4. El Sistema guarda los datos en la
base de datos
Ilustración 9 Decimo Caso de Uso
5. Una vez guardado esos datos,
permite que se introduzca otro reporte o
salir de la aplicación.
Tabla 15 Decimo Caso de Uso
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.
DECIMO PRIMERO 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
datos de los reporte de autos dentro del
sistema.
4. El Sistema guarda los datos en la
base de datos
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
Cursos alternos
Ilustración 10 Decimo Primer Caso de Uso
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.
DIAGRAMAS DE SECUENCIAS:
ACCESO AL SISTEMA.
ALTA DE AUTOMOVILES.
Ilustración 11 Acceso al sistema
Ilustración 12 Alta de Automóviles
BAJA DE AUTOMOVILES.
EDICION DE AUTOMOVILES.
Ilustración 13 Baja de Autos
Ilustración 14 Edicion Automoviles
CONSULTA AUTOMOVILES.
ALTA MECANICOS.
Ilustración 16 Alta Mecánicos
BAJA MECANICOS.
Ilustración 15 Consulta Automóviles
Ilustración 17 Baja Mecanicos
EDICION MECANICOS.
Ilustración 18 Edicion Mecanicos
CONSULTA MECANICOS.
REPORTES MECANICOS.
REPORTES DE AUTOS.
Ilustración 19 Consulta Mecanicos
Ilustración 20 Reportes Mecanicos
Ilustración 21 Reportes Autos
DIAGRAMAS DE CLASE
Ilustración 22 Diagrama De Clase
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.
La segunda pantalla nos mostrara el menú con las opciones disponibles. Solo el administrador tendrá acceso a todas las funciones del menú.
Ilustración 23 Pantalla de Acceso al Sistema
Ilustración 24 Pantalla Altas
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.
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 25 Pantalla Alta Autos
Ilustración 26 Pantalla Alta Mecanicos
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.
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 27 Pantalla Baja Autos
Ilustración 28 Pantalla Baja Mecanicos
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.
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 mostrada en pantalla.
Ilustración 29 Pantalla Consulta Autos
Ilustración 30 Pantalla Consulta Mecanicos
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.
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 31 Ediciones Autos
Ilustración 32 Pantalla Edicion Mecanicos
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.
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 33 Pantalla Reporte Autos
Ilustración 34 Pantalla Reporte Mecanicos
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.
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.
