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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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.

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


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

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

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

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

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

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.

ACCION DEL ACTOR
1. El

administrador

entra

al

sistema y elige la opción dar
ediciones al auto
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
permite que se introduzca otro
equipo o salir de la aplicación.
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

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


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

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
que tipo de datos le pide para cada autos y delante de ellos el cuadro de texto

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

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

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


1. El administrador o sistema
entra al sistema i elige la
opción

de

eliminar

mecánicos.
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

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

OCTAVO CASO DE USO

Ilustración 7 Octavo Caso de Uso

Caso de uso:
Ediciones de Mecánicos.
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


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.

NOVENO CASO DE USO

Ilustración 8 Noveno Caso de Uso
Caso de uso: Consulta de Mecánicos.
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


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.

DECIMO CASO DE USO.

Ilustración 9 Decimo Caso de Uso
Caso de Uso:

REPORTES DE LOS MECANICOS

Actores:


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.

ACCIÓN DEL ACTOR


1. El administrador entra al sistema y
elige la opción de reporte de los
mecánicos
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.

base de 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
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.

Ilustración 10 Decimo Primer Caso de Uso

Caso de Uso:

REPORTES DE AUTOS ATENDIDOS

Actores:


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.

ACCIÓN DEL ACTOR


1. El administrador entra al sistema y
elige la opción de reporte de autos
atendidos
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

base de datos

sistema.
permite que se introduzca otro reporte o
salir de la aplicación.
Tabla 16 Decimo Primer Caso de Uso

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

Ilustración 11 Acceso al sistema

ALTA DE AUTOMOVILES.

Ilustración 12 Alta de Automóviles

BAJA DE AUTOMOVILES.

Ilustración 13 Baja de Autos

EDICION DE AUTOMOVILES.

Ilustración 14 Edicion Automoviles

CONSULTA AUTOMOVILES.

Ilustración 15 Consulta Automóviles

ALTA MECANICOS.

Ilustración 16 Alta Mecánicos

BAJA MECANICOS.

Ilustración 17 Baja Mecanicos

EDICION MECANICOS.

Ilustración 18 Edicion Mecanicos

CONSULTA MECANICOS.

Ilustración 19 Consulta Mecanicos

REPORTES MECANICOS.

Ilustración 20 Reportes Mecanicos

REPORTES DE AUTOS.

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.

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

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

La segunda opción del
menú es „BAJAS‟ en la
información
necesaria
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‟
llenar con la información
mente se buscara en la
base de datos para ser
eliminada.

Ilustración 28 Pantalla Baja Mecanicos

La tercer opción del
menú es „CONSULTAS‟
en la opción „AUTOS‟
llenar
con
la
información necesaria
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
base de datos para ser
Ilustración 30 Pantalla Consulta Mecanicos

mostrada en pantalla.

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

La quinta opción del menú
es „REPORTESS‟ en 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‟
en ella los campos a llenar
con
la
información
base de datos para
generar un reporte que se
mostrara en pantalla.

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.

Proyecto final

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Proyecto final

Similar to Proyecto final (20)

More from Helena Pérez Calderón

More from Helena Pérez Calderón (13)

Proyecto final