Proyecto Final Escuela Virtual

1
NDICE DE CONTENIDOS

1. GENERALIDADES ................................................................................................................................... 9
1.1. INTRODUCCIN ................................................................................................................................. 9
1.2. ANTECEDENTES ............................................................................................................................... 10
1.3. PLANTEAMIENTO DEL PROBLEMA .................................................................................................. 12
1.3.1. DESCRIPCIN DEL PROBLEMA .................................................................................................... 12
1.3.2. IDENTIFICACIN DE LA CAUSA DEL PROBLEMA ......................................................................... 12
1.3.3. FORMULACIN DEL PROBLEMA ................................................................................................. 13
1.4. OBJETIVOS ....................................................................................................................................... 13
1.4.1. OBJETIVO GENERAL .................................................................................................................... 13
1.4.2. OBJETIVOS ESPECFICOS ............................................................................................................. 13
1.5. JUSTIFICACIN ................................................................................................................................ 14
1.5.1. JUSTIFICACIN TCNICA ............................................................................................................. 14
1.6. ALCANCES Y LMITES DEL SISTEMA ................................................................................................. 14
1.6.1. ALCANCE TEMTICO ................................................................................................................... 14
1.6.2. ALCANCE INSTITUCIONAL ........................................................................................................... 15
1.6.3. ALCANCE TCNICO ...................................................................................................................... 15
1.7. APORTES ......................................................................................................................................... 15
1.8. HERRAMIENTAS .............................................................................................................................. 16
2. DESARROLLO DE LA FUNDAMENTACIN TERICA .................................................................................. 18
2.1. INTRODUCCIN ............................................................................................................................... 18
2.2. SISTEMA DE INFORMACIN ............................................................................................................ 18
2.3. PROCESO UNIFICADO ...................................................................................................................... 20
2.3.1. CARACTERSTICAS DEL PROCESO UNIFICADO ............................................................................ 20
2.3.1.1. ITERATIVO E INCREMENTAL ................................................................................................... 21
2.3.1.2. DIRIGIDO POR LOS CASOS DE USO ......................................................................................... 22
2.3.1.3. CENTRADO EN LA ARQUITECTURA ......................................................................................... 23
2.4. LENGUAJE UNIFICADO DE MODELADO ........................................................................................... 24
2.4.1.1. DIAGRAMA DE CASOS DE USO ............................................................................................... 26
2.4.1.2. DIAGRAMA DE SECUENCIA ..................................................................................................... 28
2.4.1.3. DIAGRAMA DE COLABORACION ............................................................................................. 29
2.4.1.4. DIAGRAMA DE CLASE ............................................................................................................. 29
2.4.1.5. DIAGRAMA DE ESTADOS ........................................................................................................ 33
2.4.1.6. DIAGRAMA DE COMPONENTES ............................................................................................. 35
2

2.5. MODELO ENTIDAD-RELACIN DE BASE DE DATOS ............................................................................. 35
2.5.1. ENTIDADES Y RELACIONES .............................................................................................................. 35
2.6. ARQUITECTURA CLIENTE-SERVIDOR ................................................................................................... 37
2.6.1. CARACTERISTICAS ........................................................................................................................... 38
2.6.2. VENTAJAS ........................................................................................................................................ 39
2.6.3. DESVENTAJAS .................................................................................................................................. 40
2.6.4. JUSTIFICACIN ................................................................................................................................ 40
2.7. SOCKETS .............................................................................................................................................. 40
2.7.1. FUNCIONAMIENTO GENERICO ........................................................................................................ 41
2.7.2. REQUISITOS ..................................................................................................................................... 42
2.7.3. PROPIEDADES INHERENTES A LOS SOCKETS ................................................................................... 43
2.8. METRICAS DE CALIDAD ........................................................................................................................ 43
2.8.1. FUNCIONABILIDAD .......................................................................................................................... 44
2.8.2. CONFIABILIDAD ............................................................................................................................... 47
2.8.3. PORTABILIDAD ................................................................................................................................ 47
2.8.4. MANTENIBILIDAD ............................................................................................................................ 48
2.9. JAVA (LENGUAJE DE PROGRAMACIN) .......................................................................................... 48
2.9.1. INDEPENDENCIA DE LA PLATAFORMA........................................................................................ 49
2.9.2. SINTAXIS ..................................................................................................................................... 49
2.9.3. JAVA EN APLICACIONES DE ESCRITORIO..................................................................................... 50
2.9.4. PLATAFORMAS QUE SOPORTAN JAVA ........................................................................................ 51
2.9.5. APARIENCIA ................................................................................................................................ 51
2.9.6. RECURSOS ................................................................................................................................... 51
2.9.7. COMPONENTES .......................................................................................................................... 52
2.9.8. JAVA EN CDIGO ABIERTO ......................................................................................................... 52
2.9.9. SOCKETS EN JAVA ....................................................................................................................... 53
2.9.10. MODELOS DE COMUNICACIN DE LOS SOCKETS EN JAVA .................................................... 53
2.9.11. JUSTIFICACIN DE LA HERRAMIENTA .................................................................................... 53
2.10. MYSQL ............................................................................................................................................. 54
2.10.1. LENGUAJE DE PROGRAMACIN SOPORTADOS ...................................................................... 54
2.10.2. ESPECIFICACIONES DE MYSQL ................................................................................................ 55
2.10.3. CARACTERISTICAS DE MYSQL ................................................................................................. 56
2.10.4. LICENCIA ................................................................................................................................. 56
2.11. NETBEANS ....................................................................................................................................... 57
2.11.1. PLATAFORMA NETBEANS ....................................................................................................... 57
2.11.2. NETBEANS IDE ........................................................................................................................ 58
3. MARCO DEL APLICATIVO .......................................................................................................................... 60
3

3.1. INTRODUCCIN ............................................................................................................................... 60
3.2. ANLISIS DEL SISTEMA ACTUAL ...................................................................................................... 60
3.3. PLANIFICACIN PARA EL DESARROLLO DEL SISTEMA ..................................................................... 60
3.3.1. DESCRIPCION DE LOS ACTORES .................................................................................................. 60
3.3.2. IDENTIFICACIN DE LOS CASOS DE USO .................................................................................... 61
3.3.3. CATLOGO DE REQUERIMIENTOS DEL SISTEMA ........................................................................ 62
3.3.4. FUNCIONES BSICAS DEL SISTEMA............................................................................................. 63
3.4. ANLISIS .......................................................................................................................................... 66
3.4.1. DIAGRAMA DE CASOS DE USO.................................................................................................... 66
3.4.2. DIAGRAMA DE SECUENCIA ......................................................................................................... 70
3.4.3. DIAGRAMA DE COLABORACIN ................................................................................................. 74
3.4.4. DIAGRAMA DE CLASES ................................................................................................................ 78
3.4.5. DIAGRAMA DE ESTADOS............................................................................................................. 79
3.4.6. DIAGRAMA DE COMPONENTES .................................................................................................. 81
3.5. MODELOS CONCEPTUAL DE LA BASE DE DATOS DEL SISTEMA ...................................................... 82
3.6. DISEO DE LA INTERFAZ DE USUARIO ............................................................................................ 83
3.6.1. USUARIO DEL SISTEMA ............................................................................................................... 83
3.6.2. ADMINISTRADOR DEL SISTEMA .................................................................................................. 84
4. CALIDAD DEL SOFTWARE .......................................................................................................................... 89
4.1. INTRODUCCIN ............................................................................................................................... 89
4.2. FUNCIONABILIDAD .......................................................................................................................... 89
4.3. CONFIABILIDAD ............................................................................................................................... 93
4.4. PORTABILIDAD ................................................................................................................................ 94
4.5. MANTENIBILIDAD ............................................................................................................................ 94
4.5.1. MANTENIMIENTO ADAPTIVO ..................................................................................................... 94
4.5.2. MANTENIMIENTO PERFECTIVO .................................................................................................. 94

BIBLIOGRAFA

ANEXOS

4

NDICE DE FIGURAS

FIGURA 2.1- ESQUEMA SISTEMA DE INFORMACIN..19
FIGURA 2.2: EL CICLO DE VIDA DEL PROCESO UNIFICADO.21
FIGURA 2.3: EL PROCESO UNIFICADO DE DESARROLLO DE
SOFTWARE.25
FIGURA 2.4: DIAGRAMAS UML.26
FIGURA 2.5: ACTOR DEL SISTEMA. ...27
FIGURA 2.6: CASO DE USO DEL SISTEMA. ....27
FIGURA 2.7: DIAGRAMA DE SECUENCIA. ...28
FIGURA 2.8: DIAGRAMA DE COLABORACIN...29
FIGURA 2.9: REPRESENTACIN DE UNA CLASE...30
FIGURA 2.10: HERENCIA DE LOS ATRIBUTOS DE UNA CLASE...32
FIGURA 2.11: DIAGRAMA DE CLASES...33
FIGURA 2.12: DIAGRAMA DE ESTADOS...34
FIGURA 2.13: DIAGRAMA DE COMPONENTES..35
FIGURA 2.14: MODELO ENTIDAD-RELACIN ...37
FIGURA 2.15: MODELO CLIENTE-SERVIDOR..38
FIGURA 2.16: PETICIN Y RESPUESTA EN LA ARQUITECTURA CLIENTE-SERVIDOR.39
FIGURA 2.17: FUNCIONAMIENTO DE UNA CONEXIN SOCKET...41
FIGURA 3.1 DIAGRAMA DE CASO DE USO PRINCIPAL. .66
FIGURA 3.2: DIAGRAMA DE SECUENCIA PARA SOLICITUD DE USUARIO PARA LA INSCRIPCIN A UN CURSO. ..70
FIGURA 3.3: DIAGRAMA DE SECUENCIA PARA INICIO DE SESIN DEL USUARIO REGISTRADO. ....71
FIGURA 3.4: DIAGRAMA DE SECUENCIA PARA CIERRE DE SESIN DEL USUARIO REGISTRADO. .71
FIGURA 3.5: DIAGRAMA DE SECUENCIA PARA REGISTRO DE NUEVO USUARIO. ...72
FIGURA 3.6 DIAGRAMA DE SECUENCIA PARA CREACIN DE UN NUEVO CURSO. .72
FIGURA 3.7: DIAGRAMA DE SECUENCIA PARA GENERACIN DE INFORME DE ASISTENCIA. ...73
FIGURA 3.8 DIAGRAMA DE SECUENCIA PARA GENERACIN DE REPORTES SOBRE PARTICIPANTES...73
FIGURA 3.9: DIAGRAMA DE SECUENCIA PARA GENERACIN DE REPORTES SOBRE COMPUTADORAS...74
FIGURA 3.10: DIAGRAMA DE COLABORACIN DE INICIO DE SESIN DE USUARIO. ....74
FIGURA 3.11: DIAGRAMA DE COLABORACIN DE CIERRE DE SESIN DE USUARIO. ...75
FIGURA 3.12: DIAGRAMA DE COLABORACIN DE REGISTRO DE USUARIO. .75
FIGURA 3.13: DIAGRAMA DE COLABORACIN DE GENERACIN DE INFORME DE ASISTENCIA. .76
FIGURA 3.14: DIAGRAMA DE COLABORACIN DE GENERACIN DE REPORTE ESPECFICO. .76
FIGURA 3.15: DIAGRAMA DE COLABORACIN DE GENERACIN DE REPORTE DEL USO DE LAS COMPUTADORAS. ...77
FIGURA 3.16: DIAGRAMA DE COLABORACIN DE CREACIN DE NUEVO CURSO. .77
FIGURA 3.17: DIAGRAMA DE CLASES DEL SISTEMA. .78
FIGURA 3.18: DIAGRAMA DE ESTADO DE INICIO DE SESIN DE USUARIO. ..79
FIGURA 3.19: DIAGRAMA DE ESTADO DE CIERRE DE SESIN DE USUARIO. .79
FIGURA 3.20: DIAGRAMA DE ESTADO DE REGISTRO DE USUARIO. ..79
FIGURA 3.21: DIAGRAMA DE ESTADO DE GENERACIN DE INFORME DE ASISTENCIA. ....80
FIGURA 3.22: DIAGRAMA DE ESTADO DE GENERACIN DE REPORTE ESPECFICO. ..80
FIGURA 3.23: DIAGRAMA DE ESTADO DE GENERACIN DE REPORTE DEL USO DE LAS COMPUTADORAS. ..80
5

FIGURA 3.24: DIAGRAMA DE ESTADO DE CREACIN DE NUEVO CURSO. .80
FIGURA 3.25: DIAGRAMA DE COMPONENTES DEL SISTEMA. ..81
FIGURA 3.26: MODELO ENTIDAD-RELACIN DEL SISTEMA. .82
FIGURA 3.27: VISTA DE LA SOLICITUD DE AUTENTIFICACIN DEL USUARIO. ..83
FIGURA 3.28: VISTA DE SOLICITUD DE AUTENTIFICACIN ACEPTADA. ..83
FIGURA 3.29: VISTA DE MEN PRINCIPAL DEL ADMINISTRADOR DEL SISTEMA. ..84
FIGURA 3.30: VISTA DE MEN DE REPORTES DEL SISTEMA. ...84
FIGURA 3.31: VISTA FORMULARIO DE INSCRIPCIN DE NUEVOS USUARIOS. .85
FIGURA 3.32: VISTA VENTANA DE REGISTRO EXITOSO DE NUEVOS USUARIOS. .86
FIGURA 3.33: VISTA VENTANA DE EDICIN DE DATOS DE USUARIO. ..86
FIGURA 3.34: VISTA VENTANA MEN DE ASISTENCIA DE USUARIOS. .87
FIGURA 3.35: VISTA VENTANA DE ASISTENCIA DE USUARIOS POR DAS DE LA SEMANA. .87

6

NDICE DE TABLAS

TABLA 1.1 ESPECIFICACIN DEL SOFTWARE..16
TABLA 1.2 ESPECIFICACIN DE HARDWARE.....16
TABLA 2.1 DOMINIOS DE INFORMACIN DE PUNTO FUNCIN. .45
TABLA 2.2: CLCULOS DE LOS PUNTO FUNCIN. ..46
TABLA 3.1: IDENTIFICACIN DE CASOS DE USO62
TABLA 3.2: REGISTRO DE NUEVOS USUARIOS AL SISTEMA. 63
TABLA 3.3: REALIZAR EL SEGUIMIENTO DE LAS ASISTENCIAS DIARIAS DE LOS USUARIOS DEL LABORATORIO DE
ENSEANZA. .64
TABLA 3.4: REALIZAR REPORTES GENERALES DEL TOTAL DE PARTICIPANTES SEGN ALGN FACTOR DE
DISCRIMINACIN (EDAD, GNERO, PROFESIN, ETC.). .64
TABLA 3.5: REALIZAR REPORTES GENERALES DEL TIEMPO DE USO DE LAS COMPUTADORAS DEL LABORATORIO DE
ENSEANZA. .65
TABLA 3.6: ASISTENCIA A LOS CURSOS COMPUTACIONALES. 65
TABLA 3.7: ESPECIFICACIN DE CASO DE USO SOLICITUD DE INSCRIPCIN.67
TABLA 3.8: ESPECIFICACIN DE CASO DE USO INICIO DE SESIN67
TABLA 3.9: ESPECIFICACIN DE CASO DE USO CIERRE DE
SESIN...68
TABLA 3.10: ESPECIFICACIN DE CASO DE USO REGISTRO DE USUARIO68
TABLA 3.11: ESPECIFICACIN DE CASO DE USO CREACIN DE UN NUEVO CURSO. ..69
TABLA 3.12: ESPECIFICACIN DE CASO DE USO GENERACIN DE REPORTES. ..69
TABLA 4.1: ENTRADAS PARA EL CLCULO DE FUNCIONALIDAD. .90
TABLA 4.2: CLCULO DE PUNTOS DE FUNCIN SIN AJUSTAR. ..90
TABLA 4.3: AJUSTE DE COMPLEJIDAD DEL PUNTO FUNCIN. 92

7

RESUMEN

El laboratorio de enseanza desempea funciones de capacitacin a la poblacin
cochabambina interesada en aprender sobre paquetes computacionales o el uso de
las herramientas de Microsoft office, por el momento se realiza la capacitacin de
manera presencial con un anhelo que posteriormente dicha capacitacin tambin se
la realice de manera virtual, cabe destacar que los cursos actualmente impartidos
son de un nivel bsico y procuran el aprendizaje bsico sobre el uso del
computador, para ello se cuenta con el curso entorno Windows 7 en el cual se
detalla el funcionamiento del software de una computadora, a su vez existe el curso
bsico sobre el uso de la herramienta Microsoft office Word, curso bsico sobre el
uso de la herramienta Microsoft office Excel, curso bsico sobre el uso de la
herramienta Microsoft office PowerPoint, curso bsico sobre el uso de Internet
Explorer, dichos cursos mencionados tienen la finalidad de orientar a los usuarios
sobre el modo de operarlos bsicamente.

Debido al crecimiento poblacional de los usuarios que acuden al laboratorio de
enseanza, este se ve en la necesidad de llevar un registro adecuado y ordenado
de dichos usuarios, a su vez se tiene la necesidad de generar reportes sobre los
participantes de los cursos y sobre el tiempo de uso de las computadoras del
laboratorio de enseanza.

El presente proyecto se presenta como una alternativa de solucin al problema
sobre los registros de usuarios a travs del desarrollo de un aplicativo que facilite el
registro de nuevos usuarios y facilite la generacin de reportes sobre los usuarios
participantes de los distintos cursos que son impartidos en el laboratorio de
enseanza.

El presente proyecto se divide en 5 captulos que se describen a continuacin:

Cap. I Comprende las generalidades del proyecto de grado.

Cap. II Comprende todos los conceptos que sern utilizados en el desarrollo
del proyecto.

Cap. III Comprende la Planeacin, anlisis, diseo e implantacin del
proyecto.

Cap. IV Comprende la calidad del software.

Cap. V Comprende las conclusiones del proyecto y las recomendaciones.

8

Capitulo 1
Marco referencial

9

1. GENERALIDADES

1.1. INTRODUCCIN

Hoy en da, la informtica en red se ha convertido en un factor importante en la vida
de una empresa la razn principal implica la cantidad de informacin que
actualmente se maneja, hace que el tratamiento automtico de la informacin sea
realmente til y necesario.

En la actualidad los sistemas de informacin estn basados en computadoras que
son objetos de gran consideracin en la toma de decisiones oportunas, confiables y
efectivas en cuanto a tcnicas de planificacin, programacin y administracin con
el fin de garantizar su xito, limitar el riesgo y reducir costos.

Debido a esta razn, nace la idea de automatizar las actividades cotidianas en las
organizaciones, cabe mencionar el vertiginoso avance de las telecomunicaciones y
el progreso que han experimentado las ciencias informticas que obliga a estar a
tono y entrar al mundo moderno de la tecnologa.

Por las razonas mencionadas previamente se a convertido en algo primordial que
los registro de usuarios que pueda tener cualquier empresa o institucin sean
llevados de manera adecuada y ordena a travs de un medio electrnico.

El anlisis hecho en el laboratorio de enseanza, ha permitido identificar
claramente que la mayora de los procesos se los realiza de una manera manual,
los cuales afectan el funcionamiento del laboratorio de enseanza situacin que se
ha hecho evidente en la forma como se ejecutan los procesos y funciones propias
de estas reas.

Por lo tanto, estos aspectos son importantes para la elaboracin y diseo de
sistemas de informacin y as satisfacer los requerimientos de los usuarios y
mejorar las tareas con respecto a los informes que debe generar el laboratorio de
enseanza.

Actualmente el laboratorio de enseanza no cuenta con un sistema informtico que
facilite administrar los datos personales de los usuarios que hacen uso de las
computadoras del laboratorio de enseanza.

Dicho aplicativo debe minimizar los problemas de registro de nuevos usuarios que el
laboratorio de enseanza va recibiendo a medida que avanza el tiempo, el modo de
10

funcionamiento y las interfaces del aplicativo se detallan mas adelante en este
documento.

1. 2. ANTECEDENTES

Gracias a los pasos agigantados que da la tecnologa se vuelve una necesidad que
todas las personas sepan como operar una computadora o en su defecto usar de
manera apropiada los programas ofrecidos, ya que no solo brinda una herramienta
para la elaboracin de documentos, tablas y dems sino que a su vez facilita la
elaboracin de las mismas y esto permita ahorrar tiempo en tareas repetitivas.

Debido a esto el laboratorio de enseanza ve la oportunidad de brindar cursos
computacionales a la poblacin cochabambina de manera presencial, estos cursos
se abocan de una manera bsica al aprendizaje del funcionamiento del sistema
operativo Windows 7 y sus paquetes Microsoft office.

Dicho laboratorio de enseanza tiene tambin como una principal finalidad facilitar
a la comunidad cochabambina un espacio fsico donde las personas puedan recibir
capacitacin sobre el uso del computador y a su vez brindarles una computadora
con acceso a internet donde los usuarios puedan consultar dudas o ver informacin
de su inters personal, se busca crear cierta confianza en el usuario para que
paulatinamente desaparezca el miedo a la interaccin con la computadora, ya que el
uso de una computadora en nuestros das es inevitable y un correcto manejo de
esta facilita de sobremanera las distintas tareas cotidianas.
1

El laboratorio de enseanza cuenta con una instalacin que se inicio con 60
computadoras completas (CPU, monitor, teclado y ratn), todas conectadas en red
de rea local.

En la actualidad se sumo una proyectora de multimedios Epson PowerLite 1915 que
facilita la capacitacin de los usuarios en los distintos cursos que se imparten en
este laboratorio ya que los participantes de los cursos pueden ver el monitor del
instructor reflejado en la proyeccin.
Entre los cursos ofrecidos actualmente por el laboratorio de enseanza tenemos los
siguientes:

1
Datos obtenidos en la observacin de trabajo de campo del funcionamiento del laboratorio de enseanza.

11

Uso de la herramienta Microsoft Paint (nios de knder).
Nivel bsico.
o Windows 7 bsico.
Entorno Windows 7.
Microsoft office Word 2007.
Microsoft office Excel 2007.
Microsoft office PowerPoint 2007.
Internet bsico.
Nivel intermedio.
o Microsoft office Word 2007 nivel intermedio.
Diseo de pginas.
Mrgenes.
Orientacin de hojas.
Otros.
o Microsoft office Excel 2007 nivel intermedio.
Tablas.
Formulas del Excel.
Generalizacin de formulas del Excel.
Otros.
o Microsoft office Power Point 2007 nivel intermedio
Insercin de imgenes en diapositivas.
Animacin de diapositivas.
Tiempos de animacin.
Otros.
o Internet nivel intermedio
Creacin de correo electrnico.
Comunidades virtuales.
Foros.
Chat.
Otros.

La duracin de cada curso ofrecido es de 10 horas acadmicas, desarrolladas en
una semana de lunes a viernes con una duracin de dos horas por da.
A la finalizacin de cada curso se entrega un certificado de participacin a cada
participante que haya asistido a un mnimo de cuatro de las cinco clases.
Las personas participantes en alguno de los cursos ofrecidos, se registran en una
lista de asistencia en la cual el interesado debe firmar cada da, confirmando su
asistencia en un mnimo de cuatro de los cinco das para la obtencin de su
certificado de participacin.

12

1. 3. PLANTEAMIENTO DEL PROBLEMA

1. 3. 1. DESCRIPCIN DEL PROBLEMA

El laboratorio de enseanza al recibir a un gran nmero de personas en sus
instalaciones se ve la necesidad de llevar un registro adecuado de dichos usuarios a
travs de un formulario de registro en donde se detalla el nombre completo de
estos, el nmero de clula de identidad, su edad, su profesin, su genero y otros
datos personales que sirven para llevar un registro completo y a partir de ellos
generar reportes para el anlisis de gestin del laboratorio de enseanza.
Dicho registro de nuevos usuarios se la realiza de manera manual, para ello un
encargado del laboratorio de enseanza va preguntado al nuevo usuario sus datos
personales para despus introducirlos en registros en hojas de papel para despus
archivarlos en carpetas.
Diariamente de los participantes de los cursos impartidos en el laboratorio de
enseanza deben llenar un formulario en hojas de papel en el cual detallan todos
sus datos personales, el formulario sirve para poder controlar la asistencia diaria de
los usuarios y as llevar un control adecuado de los das de asistencia de dichos
usuarios para la entrega de los certificados de asistencia, una vez finalizado el curso
los formularios de control de asistencia son archivados en carpetas.
Por otro lado para los encargados del laboratorio de enseanza deben rendir
reportes a sus superiores con respecto a la asistencia de los usuarios, estos
reportes estn catalogados por el numero de participantes en el laboratorio de
enseanza, por la edad de los participantes en el laboratorio de enseanza, por el
genero de los participantes en el laboratorio de enseanza, por el colegio o
institucin al que pertenecen los participantes en el laboratorio de enseanza,
dichos datos son recuperados de los formularios de asistencia que son llenados por
los usuarios del laboratorio de enseanza.
Finalmente se pudo reconocer que en laboratorio de enseanza no llevan ningn
registro con respecto al tiempo que cada usuario pasa en cada computadora
(computadora-tiempo-usuario), al mismo tiempo no lleva un registro del tiempo de
uso de las computadoras.

1. 3. 2. IDENTIFICACIN DE LA CAUSA DEL PROBLEMA

Debido a que el registro de nuevos usuarios del laboratorio de enseanza se la
realiza de manera manual en registros de papel, este trae bastantes problemas
relacionados con errores ortogrficos, el cual es un inconveniente al momento de
imprimir los certificados de asistencia.
Al momento donde cada usuario hace el llenado de sus datos personales en los
formularios de asistencia para constatar su asistencia a determinado curso, suele
13

surgir el inconveniente que algunos usuario no llenan las hojas de registro con letra
clara y en ciertas ocasiones incluso olvidan el llenado de ciertos campos
importantes como ser su nmero de clula de identidad o su edad.
En estos momentos el laboratorio de enseanza no cuenta con ninguna herramienta
para medir el tiempo de uso de cada computadora con relacin a cada usuario en
especfico, razn por la cual no tienen ningn registro del tiempo de uso de las
Para la generacin de los informes de participantes, los encargados del laboratorio
de enseanza deben contar manualmente los participantes de cada curso,
discriminarlos segn su edad, genero, colegio o institucin al que pertenecen para
finalmente entregar un total de estos con respecto a los requerimientos de sus
superiores.

1. 3. 3. FORMULACIN DEL PROBLEMA

El aplicativo de gestin y apoyo en al administracin de los usuarios del laboratorio
de enseanza busca facilitar y optimizar los procesos de registro de usuarios,
generacin de reportes de participantes y generacin de reportes de uso de las
computadoras.

1. 4. OBJETIVOS

1. 4. 1. OBJETIVO GENERAL

Implantacin de un aplicativo informtico que facilite el registro de nuevos
usuarios, genere reportes de asistencia y reportes de uso de las
computadoras.

1. 4. 2. OBJETIVOS ESPECFICOS

Recopilar informacin para determinar la entrada de datos al aplicativo
informtico.

Disear una base de datos para almacenar detalladamente los datos de los
nuevos usuarios que hagan uso de las computadoras en el laboratorio de
enseanza.

Permitir el registro y actualizacin de datos en el aplicativo informtico.

Elaborar un mdulo de reportes que brinde informacin sobre la asistencia de
14

nuevos usuarios en los cursos dictados en el laboratorio de enseanza.

Elaborar un mdulo de reportes que brinde informacin sobre el tiempo de uso
de las computadoras con relacin a los usuarios que hagan uso de ellas.

1. 5. JUSTIFICACIN

La justificacin es detalla con respecto a los siguientes aspectos:

1. 5. 1. JUSTIFICACIN TCNICA

La implantacin del presente aplicativo informtico es justificada puesto que al
momento de registrar nuevos usuario mitigara los posibles errores ortogrficos que
el encargado del laboratorio de enseanza puede cometer al momento del llenado
del registro de inscripcin.
Debido que el usuario para constatar su asistencia diaria simplemente ingresara un
login y un password en la computadora de su uso en el laboratorio de enseanza,
esto reducir en un 90% el tiempo que tarda cada usuario en el llenado del
formulario de asistencia, a su vez eliminara completamente el inconveniente que
ciertos usuarios no llenan los campos del formulario de asistencia de manera
legible, incluso el inconveniente que ciertos usuarios olvidan llenar bastantes
campos de dicho formulario de asistencia.
Reducir el tiempo que ocupan los encargados del laboratorio de enseanza en
generar los informes de participacin de los usuarios que hacen uso de las
Generara informes sobre el uso de las computadoras del laboratorio de enseanza
con relacin a los usuarios y el tiempo que ocuparon las mismas.

1. 6. ALCANCES Y LMITES DEL SISTEMA

Al ser una aplicacin genrica que puede ser utilizada en cualquier laboratorio de
enseanza o centro donde se dicten cursos computacionales el sistema en si fue
desarrollado bajo ciertas caractersticas generales que se detallan a continuacin

1. 6. 1. ALCANCE TEMTICO

El aplicativo informtico para el laboratorio de enseanza corresponde al rea de
sistemas de la informacin y bases de datos.
15

1. 6. 2. ALCANCE INSTITUCIONAL

El presente aplicativo informtico involucra a dicho laboratorio de enseanza, pero a
su vez posee un alcance general para ser aplicado en cualquier laboratorio que
cuente con computadoras conectadas en red local.

1. 6. 3. ALCANCE TCNICO

El sistema permite el registro de usuarios en la base de datos del laboratorio
de enseanza.

El sistema permite fijar fecha de inicio y finalizacin del curso (casos donde los
cursos duren ms de una semana o en su defecto menos de una semana).

El sistema solo genera informes especficos y no as personalizables.

El sistema solo permite introducir horarios especficos para los cursos por lo
tanto no se pueden agregar nuevos horarios.

El sistema solo registra profesiones de usuario predeterminadas, al ser
genrico no contempla que algunos usuarios puedan tener alguna otra
formacin profesional.

1. 7. APORTES

Los aportes que ofrecer este proyecto ser automatizar sus procesos rutinarios,
minimizar y optimizar tiempos de ejecucin generando informacin que sea til para
el laboratorio de enseanza.

Los participantes de los cursos contaran con una herramienta automatizada
para su correcto control de asistencia.

Se llevara un registro y control mas detallado de los usuarios del laboratorio
de enseanza.

El modulo de reportes de usuarios facilitara la tarea de los encargados del
laboratorio de enseanza, permitiendo generar de una manera rpida y
correcta estos informes sobre los participantes de los cursos.

El modulo de reportes de uso de las computadoras brindara informacin a los
encargados del laboratorio de enseanza sobre el uso de las computadoras
con relacin a los participantes de los cursos.
16

1. 8. HERRAMIENTAS

Las herramientas que se utilizaran en el desarrollo e implementacin del proyecto
harn uso de los siguientes elementos tanto del software como hardware

Tabla 1.1 Especificacin del Software.

SOFTWARE
SISTEMA OPERATIVO WINDOWS 7
LENGUAJE DE PROGRAMACIN JAVA
GESTOR DE BASE DE DATOS MYSQL
ENTORNO DE DESARROLLO NETBEANS IDE

Fuente: Creacin Propia.

Tabla 1.3 Especificacin de Hardware.

HARDWARE
USUARIO ADMINISTRADOR
MICROPROCESADOR PENTIUM
DUAL CORE
MICROPROCESADOR PENTIUM
DUAL CORE
MEMORIA 512 MB MEMORIA 1 GB
DISCO DURO 40 G DISCO DURO 80 G
MONITOR 15 PLG. MONITOR 15 PLG.
TECLADO TECLADO
MOUSE MOUSE

Fuente: Creacin Propia.

17

Capitulo 2
Marco TERICO

18

2. DESARROLLO DE LA FUNDAMENTACIN TERICA

2. 1. INTRODUCCIN

En este capitulo se detallaran los conceptos mas relevantes sobre las
metodologas, mtodos y herramientas utilizadas para el desarrollo del presente
proyecto.

El hecho de poseer un amplio marco terico, este factor crea la dificultad de
explicar detalladamente toda la teora completa es por eso que en este documento
se tratara de mencionar y explicar los detallas mas importantes para as facilitar su
comprensin al lector.

2. 2. SISTEMA DE INFORMACIN
Sistema de informacin (SI) es un conjunto de elementos orientados al tratamiento y
administracin de datos e informacin, organizados y listos para su posterior uso,
generados para cubrir una necesidad (objetivo).
2

Un sistema de informacin es un conjunto de elementos interrelacionados con el
propsito de prestar atencin a las demandas de informacin de una organizacin,
para elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de
decisiones y desarrollo de acciones. (Ingeniera de software: Una gua para crear
sistemas de informacin, Alejandro Pea Ayala).
3

Otros autores de una manera ms acertada define sistema de informacin como:
conjunto de elementos que interactan entre s con el fin de apoyar las actividades
de una empresa o negocio. Teniendo muy en cuenta el equipo computacional
necesario para que el sistema de informacin pueda operar y el recurso humano
que interacta con el Sistema de Informacin, el cual est formado por las personas
que utilizan el sistema.

Un sistema de informacin realiza cuatro actividades bsicas: entrada,
almacenamiento, procesamiento y salida de informacin.
4

2
http://definicion.de/sistema-de-informacion/
3
http://www.youblisher.com/p/188825-Guia-para-crear-Sistemas-de-
Informacion/
4
http://www.econlink.com.ar/sistemas-informacion/definicion
19

Entrada de Informacin: Es el proceso mediante el cual el Sistema de Informacin
toma los datos que requiere para procesar la informacin. Las entradas pueden ser
manuales o automticas. Las manuales son aquellas que se proporcionan en forma
directa por el usuario, mientras que las automticas son datos o informacin que
provienen o son tomados de otros sistemas o mdulos.
Esto ltimo se denomina interfaces automticas. Las unidades tpicas de entrada de
datos a las computadoras son las terminales, las cintas magnticas, las unidades de
diskette, los cdigos de barras, la voz, los monitores sensibles al tacto, el teclado y
el mouse, entre otras.

Almacenamiento de informacin: El almacenamiento es una de las actividades o
capacidades ms importantes que tiene una computadora, ya que a travs de esta
propiedad el sistema puede recordar la informacin guardada en la seccin o
proceso anterior. Esta informacin suele ser almacenada en estructuras de
informacin denominadas archivos. La unidad tpica de almacenamiento son los
discos magnticos o discos duros, los discos flexibles o diskettes y los discos
compactos (CD-ROM).

Procesamiento de Informacin: Es la capacidad del Sistema de Informacin para
efectuar clculos de acuerdo con una secuencia de operaciones preestablecida.
Estos clculos pueden efectuarse con datos introducidos recientemente en el
sistema o bien con datos que estn almacenados. Esta caracterstica de los
sistemas permite la transformacin de datos fuente en informacin que puede ser
utilizada para la toma de decisiones.

Salida de Informacin: La salida es la capacidad de un Sistema de Informacin para
sacar la informacin procesada o bien datos de entrada al exterior.

Figura 2.1: Esquema sistema de informacin.

Fuente: http://es.wikipedia.org/wiki/Archivo:Esquema_sistema_de_informacion.png.

Elementos de un sistema de informacin.
5

Personas.

5
http://es.wikipedia.org/wiki/Archivo:Esquema_sistema_de_informacion.png
20

Datos.

Actividades o tcnicas de trabajo

Recursos materiales en general (tpicamente recursos informticos y de
comunicacin, aunque no tienen por qu ser de este tipo obligatoriamente).
Todos estos elementos interactan entre s para procesar los datos dando lugar a
informacin ms elaborada y distribuyndola de la manera ms adecuada posible
en una determinada organizacin en funcin de sus objetivos.
2. 3. PROCESO UNIFICADO

En la ingeniera de software el objetivo es construir un producto de software
6
, vale
decir, que todos los proyectos necesitan de un proceso que guie sus actividades.
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es
un marco de desarrollo de software que se caracteriza por estar dirigido por casos
de uso, centrado en la arquitectura y por ser iterativo e incremental.
7

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De la
misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye
aquellos elementos que son comunes a la mayora de los refinamientos existentes.
Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o
RUP son marcas registradas por IBM (desde su compra de Rational Software
Corporation en 2003). El primer libro sobre el tema se denomin, en su versin
espaola.

El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue
publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos
tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado.
Desde entonces los autores que publican libros sobre el tema y que no estn
afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores
que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

2. 3. 1. CARACTERSTICAS DEL PROCESO UNIFICADO

6
The r oad t o t he uni f i ed sof t war e devel opment pr ocess [ I VAR JACOBSON]
7
http://www.mitecnologico.com/Main/ElModeloProcesoUnificado
21

Iterativo e incremental

Dirigido por los casos de uso

Centrado en la arquitectura

2. 3. 1. 1. ITERATIVO E INCREMENTAL
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto
de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada
una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo
consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como
resultado un incremento del producto desarrollado que aade o mejora las
funcionalidades del sistema en desarrollo.
8

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de
requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una
de ellas vara a lo largo del proyecto.

Figura 2.2: El ciclo de vida del Proceso Unificado

8
http://www.slideshare.net/juliopari/5-clase-el-proceso-unificado-rational
22

Fuente:http://audiemangt.blogspot.com/2010/05/metodologia-agil-proceso-unificado-de.html

Se puede resumir que el proceso unificado de desarrollo de software, habla acerca
la estrategia ms adecuada para desarrollar un producto de software en pasos
pequeos y manejables:

Planificar un poco

Especificar, disear e implementar un poco

Integrar, probar y ejecutar un poco cada iteracin.

Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento
secuencial de un sistema a travs de mltiples ciclos de desarrollo de anlisis,
diseo, implementacin y pruebas.
El modelo incremental entrega el software en partes pequeas pero utilizables,
llamadas incrementos
9
.

Las ventajas de un desarrollo de software con un ciclo de vida iterativo se dan
gracias a la retroalimentacin en cada ciclo por lo cual se crea un sistema mas
robusto. En cada incremento que y tiene el sistema se va perfeccionando a un mas,
lo cual permite al usuario realizar las modificaciones requeridas en el transcurso del
tiempo
10

Actualmente se puede hablar de ciclos de vida en los que se realizan varios
recorridos por todas las fases. Cada recorrido por las fases se denomina iterativo
del proyecto en la que se realizan varios tipos de trabajo (denominados flujos).
Adems cada iteracin parte de la anterior incrementado o revisando la
funcionalidad implementada.

2. 3. 1. 2. DIRIGIDO POR LOS CASOS DE USO
Los casos de uso son los encargados de la captura de requisitos. Con ellos se
identifican y especifican clases, subsistemas, interfaces, casos de prueba y se
planifican las iteraciones del desarrollo y de la integracin. En una iteracin nos
guan a travs del conjunto completo de flujos de trabajo. Los objetivos de la captura
de requisitos son dos:
Encontrar los verdaderos requisitos

9
Ingeniera del software -un enfoque prctico [roger s. Pressman]
10
Ingeniera del software -un enfoque prctico [roger s. Pressman]
23

Representarlos de un modo adecuado para los usuarios, clientes y
desarrolladores.
La descripcin obtenida de los requerimientos debe ser comprendida por los casos
de uso que ayudan a recopilar la informacin sobre las interacciones que tienen los
usuarios en este caso actores del sistema.

En otras palabras un caso de uso es una secuencia, reacciones que el sistema lleva
a cabo para ofrecer un resultado de valor a algn actor, que sirven para realizar
pruebas sobre los componentes desarrollados.

Motivacin de los casos de uso:
Proporcionan un medio sistemtico de capturar requisitos funcionales
centrndose en el valor aadido para el usuario.

Dirigen el proceso de desarrollo porque el anlisis, diseo y prueba se
planifican en trminos de casos de uso.

Para idear la arquitectura (cada iteracin implementa un conjunto de casos de
uso proporcionando un incremento).

2. 3. 1. 3. CENTRADO EN LA ARQUITECTURA

El Proceso Unificado no tiene un modelo nico que cubra todos los aspectos del
sistema. Por dicho motivo existen mltiples modelos y vistas que definen la
arquitectura de software de un sistema. La analoga con la construccin es clara,
cuando construyes un edificio existen diversos planos que incluyen los distintos
servicios del mismo: electricidad, fontanera, etc.
La necesidad de una arquitectura radica en poder comprender el sistema y a su vez
que otras personas tambin comprendan el funcionamiento del mismo, es decir que
todos los que estn involucrados con su desarrollo deben entender el problema al
cual va enfocado el sistema de software para satisfacer las demandas individuales y
de la organizacin mediante la utilizacin de los diagramas definidos por UML.

Al conocer el dominio de problema y con que componentes se piensa en como
conectar estos componentes para cumplir con los requisitos del sistema y realizar
los modelos de casos de uso reutilizando dichos componentes.

24

2. 4. LENGUAJE UNIFICADO DE MODELADO

UML es un lenguaje para especificar, construir, visualizar y documentar los
artefactos de un sistema de software.

UML permite modelar todos los componentes del proceso de desarrollo de
aplicaciones, sin embargo, hay que tener en cuenta un aspecto importante del
modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un
lenguaje de modelado.
11

UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad
de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es
una forma de programar como lo es la orientacin a objetos, sin embargo, la
programacin orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML slo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas
para dar soporte a una metodologa de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o
proceso usar.

11
http://www.monografias.com/trabajos5/insof/insof.shtml
25

Figura 2.3: El proceso unificado de desarrollo de software

3
El proceso unificado de
desarrollo de software
El Proceso Unificado de Desarrollo usa UML
PROCESO UNIFICADO DE
DESARROLLO DE RATIONAL
UML
Herramientas Proceso
Notacin
RATIONAL ROSE
VISIO

Fuente: www.vc.ehu.es/jiwotvim/2.%20El%20proceso%20unificado.ppt

RUP y UML estn estrechamente relacionados entre si, pues mientras el primero
establece las actividades y los criterios para conducir un sistema desde su mximo
nivel de abstraccin, el segundo ofrece la notacin grafica necesaria para
representar los sucesos, modelos, que se obtienen de procesos de refinamiento.

2.4.1. DIAGRAMAS UML

UML es un conjunto de herramientas, que permite modelar (analizar y disear)
sistemas orientados a objetos.

Diagramas de requisitos

o Diagrama de casos de uso

Diagramas de interaccin

o Diagrama de secuencia
26

o Diagrama de colaboracin

Diagramas de anlisis y diseo

o Diagrama de clase

o Diagrama de estados

Diagramas de implementacin

o Diagrama de componentes

Figura 2.4: Diagramas UML

Fuente: http://www.info-ab.uclm.es/asignaturas/42530/pdf/m2tema6.pdf

2. 4. 1. 1. DI AGRAMA DE CASOS DE USO
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera
con el sistema en desarrollo, adems de la forma, tipo y orden en como los
elementos interactan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.

Casos de Uso.
27

Relaciones de Uso, Herencia y Comunicacin.
Elementos
Actor:

Figura 2.5: Actor del sistema.

Fuente: http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html
Una definicin previa, es que un Actor es un rol que un usuario juega con respecto
al sistema. Es importante destacar el uso de la palabra rol, pues con esto se
especifica que un Actor no necesariamente representa a una persona en particular,
sino ms bien la labor que realiza frente al sistema.
Caso de Uso:

Figura 2.6: Caso de uso del sistema.

Fuente: http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html
Un caso de uso es una operacin/tarea especfica que se realiza tras una orden
de algn agente externo, sea desde una peticin de un actor o bien desde la
invocacin desde otro caso de uso.
Relaciones:
o Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso
de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha
simple.
o Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con
una flecha punteada.

28

o Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>).
Extends: Se lo utiliza cuando un caso de uso es similar a otro (caractersticas).
Uses: Se lo utiliza cuando se tiene un conjunto de caractersticas que son
similares en ms de un caso de uso y no se desea mantener copiada la
descripcin de la caracterstica.
Especificacin de casos de uso:
Una vez identificados los casos de uso el siguiente paso es especificarlos uno a
uno, es decir que procedemos a nombrar cada caso de uso y detallar los actores
implicados, condiciones para el cumplimiento de cada caso de uso, el camino de
procesos que sigue cada caso de uso, las posible anomalas que pueden pasar
durante dichos procesos, y el resultado final una vez concluido el caso de uso.
2. 4. 1. 2. DI AGRAMA DE SECUENCI A

El diagrama de secuencia es un tipo de diagrama de interaccin cuyo objetivo es
describir el comportamiento dinmico del sistema de informacin haciendo nfasis
en la secuencia de los mensajes intercambiados por los objetos

El diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo
y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior
hacia el interior, cada objeto tiene asociado una lnea de vida

Figura 2.7: Diagrama de secuencia.

FUENTE: EL PROCESO UNI FI CADO DE DESARROLLO DE SOFTWARE [ JACOBSON]
29

2. 4. 1. 3. DI AGRAMA DE COLABORACI ON

Los diagramas de colaboracin muestran las interacciones que ocurren entre los
objetos que participan en una situacin determinada. Esta es ms o menos la
misma informacin que la mostrada por los diagramas de secuencia, pero
destacando la forma en que las operaciones se producen en el tiempo, mientras que
los diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su
topologa.
En los diagramas de colaboracin los mensajes enviados de un objeto a otro se
representan mediante flechas, mostrando el nombre del mensaje, los parmetros y
la secuencia del mensaje. Los diagramas de colaboracin estn indicados para
mostrar una situacin o flujo programa especficos y son unos de los mejores tipos
de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica
del programa.

Figura 2.8: Diagrama de colaboracin

Fuente: http://wwwkncervero.blogspot.com/

2. 4. 1. 4. DI AGRAMA DE CLASE

Los diagramas de clases muestran las diferentes clases que componen un sistema
y cmo se relacionan unas con otras. Se dice que los diagramas de clases son
diagramas estticos porque muestran las clases, junto con sus mtodos y
atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu
otras clases o qu clases son parte de otras clases, pero no muestran los
mtodos mediante los que se invocan entre ellas.
30

Un diagrama de clases esta compuesto por los siguientes elementos:
Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.
Elementos
Clase
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es
una instancia de una clase). A travs de ella podemos modelar el entorno en estudio
(una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:

Figura 2.9: Representacin de una clase

Fuente: http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

En donde:

o Superior: Contiene el nombre de la Clase

o Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).

o Inferior: Contiene los mtodos u operaciones, los cuales son la forma
como interacta el objeto con su entorno (dependiendo de la visibilidad:
private, protected o public).

Atributos y Mtodos:
o Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:
Public: Indica que el atributo ser visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.

Private: Indica que el atributo slo ser accesible desde dentro de la clase
(slo sus mtodos lo pueden acceder).
31

Protected: Indica que el atributo no ser accesible desde fuera de la clase,
pero si se podr acceder por mtodos de la clase adems de las subclases
que se deriven (ver herencia).

o Mtodos:
Los mtodos u operaciones de una clase son la forma en como sta interacta
con su entorno, stos pueden tener las caractersticas:

Public: Indica que el mtodo ser visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.

Private: Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden acceder).

Protected: Indica que el mtodo no ser accesible desde fuera de la clase,
pero si se podr acceder por mtodos de la clase adems de mtodos de
las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
interrelacionar dos o ms clases (cada uno con caractersticas y objetivos
diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relacin y stas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)

nmero fijo: m (m denota el nmero).

Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar objetos que
colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo
de vida de un objeto no depende del otro.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es instanciada
(su instanciacin es dependiente de otro objeto/clase). Se denota por una flecha
punteada.
32

El uso ms particular de este tipo de relacin es para denotar la dependencia que
tiene una clase de otra.
Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por una super
Clase, por ende la Subclase adems de poseer sus propios mtodos y atributos,
poseer las caractersticas y atributos visibles de la super Clase (public y protected).

Figura 2.10: Herencia de los atributos de una clase

Fuente: http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto
posee las Caractersticas de Vehculo, adems posee algo particular que es
Descapotable, en cambio Camin tambin hereda las caractersticas de Vehculo
pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo
Caractersticas aplicable a instancias de Vehculo, Auto y Camin, pues tiene
definicin pblica, en cambio atributos como Descapotable no son visibles por ser
privados.
Agregacin:
Para modelar objetos complejos, no bastan los tipos de datos bsicos que proveen
los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere
33

componer objetos que son instancias de clases definidas por el desarrollador de la
aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del
objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este
tipo de relacin es comnmente llamada Composicin

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida
del objeto incluido es independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).

Figura 2.11: Diagrama de clases

Fuente: http://1.bp.blogspot.com/

2. 4. 1. 5. DI AGRAMA DE ESTADOS

Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso
de uso o un objeto a lo largo de su vida dentro el sistema. En l se indican qu
34

eventos hacen que se pase de un estado a otro y cules son las respuestas y
acciones que genera.

En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos
son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres
de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su
interior, una transicin se representa como una flecha desde el estado origen al
estado destino.

Una accin de entrada aparece en la forma entrada/accin asociada donde accin
asociada es el nombre de la accin que se realiza al entrar en ese estado. Cada vez
que se entra al estado por medio de una transicin la accin de entrada se ejecuta.

Una accin de salida aparece en la forma salida/accin asociada. Cada vez que se
sale del estado por una transicin de salida la accin de salida se ejecuta.

Una accin interna es una accin que se ejecuta cuando se recibe un determinado
evento en ese estado, pero que no causa una transicin a otro estado. Se indica en
la forma nombre de evento/accin asociada.

Figura 2.12: Diagrama de estados

Fuente:http://ingenieriasoftwaredos.wikispaces.com/Diagramas+de+Estado

35

2. 4. 1. 6. DI AGRAMA DE COMPONENTES
Los diagramas de componentes muestran los componentes del y los artilugios de
que est compuesto como los archivos de cdigo fuente, las libreras o las tablas de
una base de datos.

Figura 2.13: Diagrama de componentes

Fuente:http://gzloluna8sm.blogspot.com/2010/06/diagrama-de-componentes.html

2. 5. MODELO ENTIDAD-RELACIN DE BASE DE DATOS
Cuando se utiliza una base de datos para gestionar informacin, se est plasmando
una parte del mundo real en una serie de tablas, registros y campos ubicados en un
ordenador; crendose un modelo parcial de la realidad. Antes de crear fsicamente
estas tablas en el ordenador se debe realizar un modelo de datos.
12

2. 5. 1. ENTIDADES Y RELACIONES
Entidad.-Entidad es un objeto del mundo real sobre el que queremos almacenar
informacin Las entidades estn compuestas de atributos que son los datos que
definen el objeto. De entre los atributos habr uno o un conjunto de ellos que no
se repite; a este atributo o conjunto de atributos se le llama clave de la entidad.
En toda entidad siempre hay al menos una clave que en el peor de los casos

12
http://www.cs.us.es/cursos/bd-2002/HTML/modeloER.htm
36

estar formada por todos los atributos de la tabla. Ya que pueden haber varias
claves y necesitamos elegir una, lo haremos atendiendo a estas normas:

o Que sea nica.

o Que se tenga pleno conocimiento de ella.- Por qu en las empresas se asigna
a cada cliente un nmero de cliente.

o Que sea mnima, ya que ser muy utilizada por el gestor de base de datos.

Relacin.- Es la asociacin que existe entre entidades, sin existencia propia en el
mundo real que estamos modelando, pero necesaria para reflejar las
interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:

o Relaciones uno-uno.- Las entidades que intervienen en la relacin se
asocian una a una.

o Relaciones uno-muchos.- Una ocurrencia de una entidad est asociada con
muchas de otra.

o Relaciones muchos-muchos.-Cada ocurrencia, en cualquiera de las dos
entidades de la relacin, puede estar asociada con muchas de la otra y
viceversa.

37

Figura 2.14: Modelo entidad-relacin

Fuente:http://mayerlyrueda.blogspot.com/2010/04/que-es-una-relacion.html

2. 6. ARQUITECTURA CLIENTE-SERVIDOR
La arquitectura cliente-servidor es un modelo de aplicacin distribuida en el que las
tareas se reparten entre los proveedores de recursos o servicios, llamados
servidores, y los demandantes, llamados clientes.
13

Esta idea tambin se puede aplicar a programas que se ejecutan sobre una sola
computadora, aunque es ms ventajosa en un sistema operativo multiusuario
distribuido a travs de una red de computadoras.

13

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/marquez_a_bm/capitulo5
.pdf
38

Figura 2.15: Modelo cliente-servidor

Fuente:http://es.wikipedia.org/wiki/Archivo:Cliente-servidor.jpeg

En esta arquitectura la capacidad de proceso est repartida entre los clientes y los
servidores, aunque son ms importantes las ventajas de tipo organizativo debidas a
la centralizacin de la gestin de la informacin y la separacin de
responsabilidades, lo que facilita y clarifica el diseo del sistema.
La red cliente-servidor en otras palabras es aquella red de comunicacin en la que
todos los clientes estn conectados a un servidor, en el que se centralizan los
diversos recursos y aplicaciones con que se cuenta, y que los pone a disposicin de
los clientes cada vez que estos son solicitados.
Esto significa que todas las gestiones que se realizan se concentran en el servidor,
de manera que en l se disponen los requerimientos provenientes de los clientes
que tienen prioridad, los archivos que son de uso pblico y los que son de uso
restringido, los archivos que son de slo lectura y los que, por el contrario, pueden
ser modificados, etc.
2. 6. 1. CARACTERISTICAS
En la arquitectura cliente-servidor el remitente de una solicitud es conocido como
cliente. Sus caractersticas son:

Su principal caracterstica es la de iniciar solicitudes o peticiones, tienen por tanto
un papel activo en la comunicacin.

Espera y recibe las respuestas del servidor.

39

Normalmente interacta directamente con los usuarios finales mediante una
interfaz grfica de usuario.

Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus
caractersticas son:

Al iniciarse espera las solicitudes de los clientes, desempean entonces un papel
pasivo en la comunicacin.

Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al
cliente.

Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos
casos el nmero mximo de peticiones puede estar limitado).

No es frecuente que interacten directamente con los usuarios finales.

Figura 2.16: Peticin y respuesta en la arquitectura cliente-servidor

Fuente: http://xiaoblogs.blogspot.com/2011/11/modelo-cliente-servidor.html
2. 6. 2. VENTAJ AS
Centralizacin del control: los accesos, recursos y la integridad de los datos son
controlados por el servidor de forma que un programa cliente defectuoso o no
autorizado no pueda daar el sistema. Esta centralizacin tambin facilita la tarea
de poner al da datos u otros recursos.

Escalabilidad: se puede aumentar la capacidad de clientes. Cualquier elemento
puede ser aumentado (o mejorado) en cualquier momento, o se pueden aadir
nuevos nodos a la red (clientes).

Fcil mantenimiento: al estar distribuidas las funciones y responsabilidades entre
varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o
incluso trasladar un servidor, mientras que sus clientes no se vern afectados por
ese cambio (o se afectarn mnimamente).
40

Existen tecnologas, suficientemente desarrolladas, diseadas para el paradigma
de cliente-servidor que aseguran la seguridad en las transacciones, la
amigabilidad de la interfaz, y la facilidad de empleo.

2. 6. 3. DESVENTAJAS
La congestin del trfico ha sido siempre un problema en el paradigma de
cliente-servidor. Cuando una gran cantidad de clientes envan peticiones
simultaneas al mismo servidor, puede ser que cause muchos problemas para
ste (a mayor nmero de clientes, ms problemas para el servidor).

Cuando un servidor est cado, las peticiones de los clientes no pueden ser
satisfechas.

El software y el hardware de un servidor son generalmente muy determinantes.
Un hardware regular de un ordenador personal puede no poder servir a cierta
cantidad de clientes. Normalmente se necesita software y hardware especfico,
sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto
aumentar el coste.

El cliente no dispone de los recursos que puedan existir en el servidor.

2. 6. 4. JUSTIFICACIN
Debido al actual funcionamiento del laboratorio de enseanza se deduce que el
mejor modelo de aplicacin esta basada en la arquitectura cliente-servidor, ya que
existen 58 computadoras que funcin de manera cliente y una computadora que
tiene un funcionamiento de servidor.
14

Adicionalmente los encargados del laboratorio de enseanza manifestaron desde un
comienzo la necesidad de implementar dicha arquitectura en su laboratorio de
enseanza.
15

2. 7. SOCKETS
Socket hace referencia a un concepto abstracto por el cual dos programas
(posiblemente situados en computadoras distintas) pueden intercambiar cualquier
flujo de datos, generalmente de manera fiable y ordenada.
Los sockets de Internet constituyen el mecanismo para la entrega de paquetes de
datos provenientes de la tarjeta de red a los procesos o hilos apropiados. Un socket

14
Informacin recolectada de la observacin del funcionamiento del laboratorio
de enseanza.
15
Informacin brindada por los encargados del laboratorio de enseanza.
41

queda definido por un par de direcciones IP local y remota, un protocolo de
transporte y un par de nmeros de puerto local y remoto.

Figura 2.17: Funcionamiento de una conexin socket

Servidor Cliente

Fuente: http://zarza.usal.es/~fgarcia/doc/tuto2/V_2.htm

2. 7. 1. FUNCIONAMIENTO GENERICO

Normalmente, un servidor se ejecuta sobre una computadora especfica y tiene un
socket que responde en un puerto especfico. El servidor nicamente espera,
escuchando a travs del socket a que un cliente haga una peticin.
42

En el lado del cliente: el cliente conoce el nombre de host de la mquina en la cual
el servidor se encuentra ejecutando y el nmero de puerto en el cual el servidor est
conectado.
16

Para realizar una peticin de conexin, el cliente intenta encontrar al servidor en la
mquina servidora en el puerto especificado.
Si todo va bien, el servidor acepta la conexin. Adems de aceptar, el servidor
obtiene un nuevo socket sobre un puerto diferente. Esto se debe a que necesita un
nuevo socket (y, en consecuencia, un numero de puerto diferente) para seguir
atendiendo al socket original para peticiones de conexin mientras atiende las
necesidades del cliente que se conect.

Por la parte del cliente, si la conexin es aceptada, un socket se crea de forma
satisfactoria y puede usarlo para comunicarse con el servidor. Es importante darse
cuenta que el socket en el cliente no est utilizando el nmero de puerto usado para
realizar la peticin al servidor. En lugar de ste, el cliente asigna un nmero de
puerto local a la mquina en la cual est siendo ejecutado.

2. 7. 2. REQUISITOS
Para que dos programas puedan comunicarse entre s es necesario que se cumplan
ciertos requisitos:
Que un programa sea capaz de localizar al otro.

Que ambos programas sean capaces de intercambiarse cualquier secuencia de
octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los tres recursos que originan el concepto de socket:
Un protocolo de comunicaciones, que permite el intercambio de octetos.

Un par de direcciones del protocolo de red (direccin IP, si se utiliza el protocolo
TCP/IP), que identifican la computadora de origen y la remota.

Un par de nmeros de puerto, que identifican a un programa dentro de cada
computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La
comunicacin debe ser iniciada por uno de los programas que se denomina
programa "cliente".

16
http://www.dlsi.ua.es/asignaturas/sid/JSockets.pdf
43

El segundo programa espera a que otro inicie la comunicacin, por este motivo se
denomina programa "servidor".

Un socket es un proceso o hilo existente en la mquina cliente y en la mquina
servidora, que sirve en ltima instancia para que el programa servidor y el cliente
lean y escriban la informacin. Esta informacin ser la transmitida por las
diferentes capas de red.

2. 7. 3. PROPIEDADES INHERENTES A LOS SOCKETS
Las propiedades de un socket dependen de las caractersticas del protocolo en el
que se implementan. El protocolo ms utilizado es Transmission Control Protocol;
una alternativa comn a ste es User Datagram Protocol.
Cuando se implementan con el protocolo TCP, los sockets tienen las siguientes
propiedades:
Son orientados a la conexin.

Se garantiza la transmisin de todos los octetos sin errores ni omisiones.

Se garantiza que todo octeto llegar a su destino en el mismo orden en que se ha
transmitido.
Estas propiedades son muy importantes para garantizar la correccin de los
programas que tratan la informacin.
El protocolo UDP es un protocolo no orientado a la conexin. Slo se garantiza que
si un mensaje llega, llegue bien. En ningn caso se garantiza que llegue o que
lleguen todos los mensajes en el mismo orden que se mandaron. Esto lo hace
adecuado para el envo de mensajes frecuentes pero no demasiado importantes,
como por ejemplo, mensajes para los refrescos (actualizaciones) de un grfico.
2. 8. METRICAS DE CALIDAD

La calidad del software se define como la ausencia de errores en el funcionamiento
del sistema. El ajuste a las necesidades del usuario, el sistema debe ser flexible u
susceptible a modificaciones que se puedan realizar de manera rpida y oportuna.

El sistema debe alcanzar un desempeo apropiado en trminos de tiempo, volumen
y espacio.

44

2. 8. 1. FUNCIONABILIDAD

La funcionalidad de un sistema se puede entender como el grado en que el software
satisface las necesidades de los usuarios.
17

Los puntos de funcin (PF) son medidas bsicas desde donde se calculan mtricas
de productividad.

Para generar las estimaciones de los PF se deben extraer los siguientes datos del
sistema e introducirlos en el formato de la siguiente tabla:

17
http://squac.iti.upv.es/glosario-calidad/
45

Tabla 2.1: Dominios de informacin de Punto Funcin.

Dominio de Informacin Descripcin
Nmero de entradas del usuario Se debe contar cada dato nico de
usuario o entrada de control que se
introduce en los lmites de la
aplicacin y actualiza un fichero
lgico interno, conjunto de datos,
tabla o dato independiente.
Nmero de salidas del usuario Se debe contar cada dato nico de
usuario o salida de control
generado proceduralmente y que
sale del lmite de la aplicacin.
nmero de peticiones del usuario Se debe contar cada combinacin
nica de entrada/salida en la que la
entrada on-line definida por el
usuario genera una salida inmediata
on-line. Las consultas se pueden
proporcionar a/desde otra
aplicacin
Nmero de archivos
Se debe contar cada grupo lgico
mayor de datos de usuario o de
informacin de control mantenidos
dentro de los lmites de la
aplicacin.
Nmero de interfaces externas Se debe contar como uno cada
fichero lgico de otro grupo de
datos ( o informacin de control)
que se enva fuera de los lmites de
la aplicacin, o se comparte o es
recibido desde otra aplicacin

Fuente:http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion.shtml

Una vez concluido el conteo de dominios de la informacin se procede a llenar la
siguiente tabla

46

Tabla 2.2: Clculos de los Punto Funcin.

Fuente: http://pabloaguilar3.blogspot.com/2010/12/medidas-metricas-indicadores.html

Para calcular los PF, se utiliza la relacin siguiente:
PF = CUENTA TOTAL *(0.65 + 0.01 * U(Fi))

CUENTA TOTAL = Sumatoria de todas las entradas de la anterior tabla
Fi = Son valores de ajuste a la complejidad segn las respuestas a las siguientes
preguntas.
1. .Requiere el sistema copias de seguridad y recuperacin flexible?
2. .Se requiere comunicacin de datos?
3. .Existen funciones del procedimiento distribuido?
4. .Es critico el rendimiento?
5. .Se ejecutara el sistema en un entorno operativo existente y fuertemente
utilizado?
6. .Requiere el sistema entrada de datos interactiva?
7. .Requiere la entrada de datos interactiva que las transiciones de entrada se lleven
a cabo sobre mltiples pantallas u operaciones?
8. .Se actualiza los archivos maestros de forma interactiva?
9. .Son complejas las entradas, las salidas, los archivos y las peticiones?
10. .Es complejo el procesamiento interno?
11. .Se ha diseado el cdigo para ser reutilizable?
12. .Estn concluidas en el diseo la conversin y la instalacin?
13. .Se ha desarrollado el sistema para soportar mltiples instalaciones en
diferentes organizaciones?
factor de ponderacin
Parmetros de
medicin conteo Simple medio complejo resultado
Nmero de entradas
de usuario N1 3 4 6 N1*factor
Nmero de salidas de
usuario. N2 4 5 7 N2*factor
Nmero de peticiones
de usuario. N3 3 4 6 N3*factor
Nmero de archivos. N4 7 10 15 N4*factor
Nmero de interfaces
externas. N5 5 7 10 N5*factor
CUENTA TOTAL

(Ni*factor)
47

14. .Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente
utilizado por el usuario?
Cada una de las preguntas, es respondida usando una escala con rangos desde 0
(no importante), hasta 5 (absolutamente esencial).

2. 8. 2. CONFIABILIDAD

La confiabilidad esta definida como la probabilidad que el sistema se ejecute libre de
fallos en un contexto de ejecucin determinado y durante un periodo de tiempo.
18

La confiabilidad se expresa como una probabilidad, esta se encuentra en una escala
de 0 a 1.

Si la probabilidad se acerca a uno, mas confiabilidad brindar a el sistema. Para el
usuario, el sistema ser mas confiable mientras presenta menos errores.

La confiabilidad de un sistema se calcula mediante la siguiente funcin:

Probabilidad de hallar una falla:

P (T<=t) = F (t)

Probabilidad de no hallar una falla:

P (T>t) = 1 V F(t)

Con F(t) = Fc * ( e (-f/7 * 12) )

Donde:

Fc = 0.87: Funcionalidad del sistema.
N = 1: Tasa de fallos en 7 ejecuciones dentro de un mes.

2. 8. 3. PORTABILIDAD

La portabilidad de un sistema de informacin, se define como la factibilidad de
transferir un producto a diferentes entornos de hardware/software, sin necesidad de
aplicar acciones o mecanismos distintos. Tambin es considerado como la
capacidad del producto software para ser usado en lugar de otro producto software,

18
http://squac.iti.upv.es/glosario-calidad/
48

para el mismo propsito dentro del mismo entorno. Las caractersticas ms
importantes que se consideran para este factor son: la facilidad de instalacin,
facilidad de ajuste y facilidad de adaptacin al cambio.
19

2. 8. 4. MANTENIBILIDAD

Dentro de los tipos de mantenimiento para la mejora, se detallan los siguiente dos:
el mantenimiento adaptativo y el mantenimiento perfectivo.

Adaptativo. Modificacin de un producto software, despus de su entrega,
para conseguir que sea utilizable en un nuevo entorno.

Perfectivo. Modificacin de un producto software despus de su entrega, para
mejorar su rendimiento o su mantenibilidad.

2. 9. JAVA (LENGUAJE DE PROGRAMACIN)
Java es un lenguaje de programacin orientado a objetos, desarrollado por Sun
Microsystems a principios de los aos 90. El lenguaje en s mismo toma mucha de
su sintaxis de C y C++, pero tiene un modelo de objetos ms simple y elimina
herramientas de bajo nivel, que suelen inducir a muchos errores, como la
manipulacin directa de punteros o memoria. Con respecto a la memoria, su gestin
no es un problema ya que sta es gestionada por el propio lenguaje y no por el
programador.
20

Las aplicaciones Java estn tpicamente compiladas en un bytecode, aunque la
compilacin en cdigo mquina nativo tambin es posible. En el tiempo de
ejecucin, el bytecode es normalmente interpretado o compilado a cdigo nativo
para la ejecucin, aunque la ejecucin directa por hardware del bytecode por un
procesador Java tambin es posible.
La implementacin original y de referencia del compilador, la mquina virtual y las
bibliotecas de clases de Java fueron desarrolladas por Sun Microsystems en 1995.
Desde entonces, Sun ha controlado las especificaciones, el desarrollo y evolucin
del lenguaje a travs del Java Community Process, si bien otros han desarrollado
tambin implementaciones alternativas de estas tecnologas de Sun, algunas
incluso bajo licencias de software libre.
Entre diciembre de 2006 y mayo de 2007, Sun Microsystems liber la mayor parte
de sus tecnologas Java bajo la licencia GNU GPL, de acuerdo con las
especificaciones del Java Community Process, de tal forma que prcticamente todo
el Java de Sun es ahora software libre.

19
http://www.monografias.com/trabajos15/ingenieria-software/ingenieria-
software.shtml
20
http://www.cad.com.mx/historia_del_lenguaje_java.htm
49

2. 9. 1. INDEPENDENCIA DE LA PLATAFORMA
La independencia de la plataforma hace referencia que programas escritos en el
lenguaje Java pueden ejecutarse igualmente en cualquier tipo de hardware. Este es
el significado de ser capaz de escribir un programa una vez y que pueda ejecutarse
en cualquier dispositivo, tal como reza el axioma de Java, write once, run
anywhere.
21

Para ello, se compila el cdigo fuente escrito en lenguaje Java, para generar un
cdigo conocido como bytecode (especficamente Java bytecode) instrucciones
mquina simplificada especfica de la plataforma Java. Esta pieza est a medio
camino entre el cdigo fuente y el cdigo mquina que entiende el dispositivo
destino. El bytecode es ejecutado entonces en la mquina virtual (JVM), un
programa escrito en cdigo nativo de la plataforma destino (que es el que entiende
su hardware), que interpreta y ejecuta el cdigo. Adems, se suministran bibliotecas
adicionales para acceder a las caractersticas de cada dispositivo (como los
grficos, ejecucin mediante hebras o threads, la interfaz de red) de forma unificada.

La licencia sobre Java de Sun insiste que todas las implementaciones sean
compatibles. Esto dio lugar a una disputa legal entre Microsoft y Sun, cuando ste
ltimo aleg que la implementacin de Microsoft no daba soporte a las interfaces
RMI y JNI adems de haber aadido caractersticas dependientes de su
plataforma. Sun demand a Microsoft y gan por daos y perjuicios (unos 20
millones de dlares) as como una orden judicial forzando la acatacin de la licencia
de Sun. Como respuesta, Microsoft no ofrece Java con su versin de sistema
operativo, y en recientes versiones de Windows, su navegador Internet Explorer no
admite la ejecucin de applets sin un conector (o plugin) aparte. Sin embargo, Sun y
otras fuentes ofrecen versiones gratuitas para distintas versiones de Windows.

La portabilidad es tcnicamente difcil de lograr, y el xito de Java en ese campo ha
sido dispar. Aunque es de hecho posible escribir programas para la plataforma Java
que acten de forma correcta en mltiples plataformas de distinta arquitectura, el
gran nmero de estas con pequeos errores o inconsistencias llevan a que a veces
se parodie el eslogan de Sun, "Write once, run anywhere" como "Write once, debug
everywhere" (o Escrbelo una vez, ejectalo en cualquier parte por Escrbelo una
vez, depralo en todas partes)
2. 9. 2. SINTAXIS
La sintaxis de Java se deriva en gran medida de C++. Pero a diferencia de ste, que
combina la sintaxis para programacin genrica, estructurada y orientada a objetos,
Java fue construido desde el principio para ser completamente orientado a objetos.
Todo en Java es un objeto (salvo algunas excepciones), y todo en Java reside en
alguna clase (recordemos que una clase es un molde a partir del cual pueden
crearse varios objetos).

21
http://www.clubdesarrolladores.com/articulos/mostrar/38-java-su-historia-
ediciones-versiones-y-caracteristicas-como-plataforma-y-lenguaje-de-
programacion
50

Todo en Java est dentro de una clase, incluyendo programas autnomos.

El cdigo fuente se guarda en archivos con el mismo nombre que la clase que
contienen y con extensin .java. Una clase (class) declarada pblica (public)
debe seguir este convenio.

El compilador genera un archivo de clase (con extensin .class) por cada
una de las clases definidas en el archivo fuente. Una clase annima se trata
como si su nombre fuera la concatenacin del nombre de la clase que la
encierra, el smbolo $, y un nmero entero.

Los programas que se ejecutan de forma independiente y autnoma, deben
contener el mtodomain().

La palabra reservadavoid indica que el mtodo main no devuelve nada.

El mtodo main debe aceptar un array de objetos tipo String. Por acuerdo se
referencia comoargs, aunque puede emplearse cualquier otro identificador.

La palabra reservadastatic indica que el mtodo es un mtodo de clase,
asociado a la clase en vez de una instancias de la misma. El mtodo main
debe ser esttico o de clase.

La palabra reservada public significa que un mtodo puede ser llamado desde
otras clases, o que la clase puede ser usada por clases fuera de la jerarqua
de la propia clase. Otros tipos de acceso sonprivate o protected.

La utilidad de impresin (en pantalla por ejemplo) forma parte de la biblioteca
estndar de Java: la clase System define un campo pblico esttico
llamado out. El objeto out es una instancia de PrintStream, que ofrece el
mtodo println (String) para volcar datos en la pantalla (la salida estndar).

Las aplicaciones autnomas se ejecutan dando al entorno de ejecucin de
Java el nombre de la clase cuyo mtodo main debe invocarse.

El nombre de la clase cuyo mtodo main se llama puede especificarse
tambin en el fichero MANIFEST del archivo de empaquetamiento de Java
(.jar).

2. 9. 3. JAVA EN APLICACIONES DE ESCRITORIO
Hoy en da existen multitud de aplicaciones grficas de usuario basadas en Java, el
entorno de ejecucin Java (JRE) se ha convertido en un componente habitual en los
PC de usuario de los sistemas operativos ms usados en el mundo.
Adems, muchas aplicaciones Java lo incluyen dentro del propio paquete de la
aplicacin de modo que se ejecuten en cualquier PC.
51

En las primeras versiones de la plataforma Java existan importantes limitaciones en
las APIs de desarrollo grfico (AWT). Desde la aparicin de la biblioteca Swing la
situacin mejor substancialmente y posteriormente con la aparicin de bibliotecas
como SWT hacen que el desarrollo de aplicaciones de escritorio complejas y con
gran dinamismo, usabilidad, etc.
2. 9. 4. PLATAFORMAS QUE SOPORTAN J AVA
Una versin del entorno de ejecucin Java JRE (Java Runtime Environment) est
disponible en la mayora de equipos de escritorio. Sin embargo, Microsoft no lo ha
incluido por defecto en sus sistemas operativos. En el caso de Apple, ste incluye
una versin propia del JRE en su sistema operativo, el Mac OS. Tambin es un
producto que por defecto aparece en la mayora de las distribuciones de GNU/Linux.
Debido a incompatibilidades entre distintas versiones del JRE, muchas aplicaciones
prefieren instalar su propia copia del JRE antes que confiar su suerte a la aplicacin
instalada por defecto. Los desarrolladores de applets de Java o bien deben insistir a
los usuarios en la actualizacin del JRE, o bien desarrollar bajo una versin antigua
de Java y verificar el correcto funcionamiento en las versiones posteriores.
2. 9. 5. 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 grficos de la
plataforma nativa, el AWT no es capaz de funciones grficas avanzadas sin
sacrificar la portabilidad entre plataformas; ya que cada una tiene un conjunto de
APIs distinto, especialmente para objetos grficos de alto nivel. Las herramientas de
Swing, escritas completamente en Java, evitan este problema construyendo los
objetos grficos a partir de los mecanismos de dibujo bsicos que deben estar
disponibles en todas las plataformas. El inconveniente es el trabajo extra requerido
para conseguir la misma apariencia de la plataforma destino.
22

2. 9. 6. RECURSOS
El JRE (Java Runtime Environment, o Entorno en Tiempo de Ejecucin de Java) es
el software necesario para ejecutar cualquier aplicacin desarrollada para la
plataforma Java. El usuario final usa el JRE como parte de paquetes software o
plugins (o conectores) en un navegador Web. Sun ofrece tambin el SDK de Java 2,
o JDK (Java Development Kit) en cuyo seno reside el JRE, e incluye herramientas
como el compilador de Java, Javadoc para generar documentacin o el depurador.
Puede tambin obtenerse como un paquete independiente, y puede considerarse
como el entorno necesario para ejecutar una aplicacin Java, mientras que un
desarrollador debe adems contar con otras facilidades que ofrece el JDK.

22
http://es.debugmodeon.com/articulo/aplicaciones-swing-con-apariencia-nativa
52

2. 9. 7. COMPONENTES
Bibliotecas de Java, que son el resultado de compilar el cdigo fuente desarrollado
por quien implementa la JRE, y que ofrecen apoyo para el desarrollo en Java.
Las bibliotecas centrales, que incluyen:
Una coleccin de bibliotecas para implementar estructuras de datos como
listas, arrays, rboles y conjuntos.

Bibliotecas de integracin, que permiten la comunicacin con sistemas
externos.

La API para acceso a bases de datos JDBC (Java DataBase Conectivity).

Bibliotecas para la interfaz de usuario.

El conjunto de herramientas nativas AWT (Abstract Windowing Toolkit), que
ofrece componentes GUI (Graphical User Interface), mecanismos para usarlos
y manejar sus eventos asociados.

Las Bibliotecas de Swing, construidas sobre AWT pero ofrecen
implementaciones no nativas de los componentes de AWT.

Una implementacin dependiente de la plataforma en que se ejecuta de la
mquina virtual de Java (JVM), que es la encargada de la ejecucin del cdigo
de las bibliotecas y las aplicaciones externas.

Documentacin y licencia.
23

2. 9. 8. JAVA EN CDIGO ABIERTO
Java se ha convertido en un lenguaje con una implantacin masiva en todos los
entornos (personales y empresariales). El control que mantiene Sun sobre ste ha
generado reticencias en la comunidad de empresas con fuertes intereses en Java
(IBM, Oracle) y obviamente en la comunidad de desarrolladores de software libre.
24

La evolucin basada en un comit en el que participen todos los implicados no es
suficiente y la comunidad demandaba desde hace tiempo la liberacin de las APIs y
bibliotecas bsicas de la JDK.
En diciembre de 2006, Sun comenz relanzamiento de su plataforma Java bajo la
licencia GPL de GNU.
En abril de 2009 Oracle adquiri Sun Microsystems, lo que gener temor en la
comunidad ante la posible mercantilizacin del lenguaje de programacin a objetos

23
http://apl.jhu.edu/~hall/java/
24
http://www.itespresso.es/java-sigue-siendo-el-lenguaje-mas-popular-
55785.html
53

ms popular actualmente. Por ahora Oracle ha seguido manteniendo Java, siendo
las versiones posteriores a la 6 bajo su control.
25

2. 9. 9. SOCKETS EN JAVA

El paquete java.net de la plataforma Java proporciona una clase Socket, la cual
implementa una de las partes de la comunicacin bidireccional entre un programa
Java y otro programa en la red.

La clase Socket se sita en la parte ms alta de una implementacin dependiente
de la plataforma, ocultando los detalles de cualquier sistema particular al programa
Java. Usando la clase java.net.Socket en lugar de utilizar cdigo nativo de la
plataforma, los programas Java pueden comunicarse a travs de la red de una
forma totalmente independiente de la plataforma.

De forma adicional, java.net incluye la clase ServerSocket, la cual implementa un
socket el cual los servidores pueden utilizar para escuchar y aceptar peticiones de
conexin de clientes.

2. 9. 10. MODELOS DE COMUNICACIN DE LOS SOCKETS EN JAVA

El modelo de sockets ms simple es:

o El servidor establece un puerto y espera durante un cierto tiempo (timeout
segundos), a que el cliente establezca la conexin. Cuando el cliente
solicite una conexin, el servidor abrir la conexin socket con el mtodo
accept().

o El cliente establece una conexin con la mquina host a travs del puerto
que se designe en puerto#

o El cliente y el servidor se comunican con manejadores InputStream y
OutputStream

2. 9. 11. JUSTIFICACIN DE LA HERRAMIENTA
La utilizacin del lenguaje de programacin Java se justifica debido a los siguientes
hechos:

25
http://avances-tecnologicos.euroresidentes.com/2006/11/java-cdigo-
abierto.html
54

Java posee licencia pblica.

Es un lenguaje de programacin muy popular y bastante completo para el
desarrollo de aplicaciones de escritorio.

Brinda gran soporte en sus libreras.

Brinda una interfaz sencilla para el usuario final.

Brinda soporte para el gestor de base de datos MYSQL.

Brinda soporte para la utilizacin de socket.

Existen una gran variedad de IDE (Entorno de desarrollo) para desarrollar
aplicaciones

2. 10. MYSQL
MySQL es un sistema de gestin de bases de datos relacional, multihilo y
multiusuario con ms de seis millones de instalaciones.
1

Oracle Corporation desde abril de 2009 desarrolla MySQL como software libre en un
esquema de licenciamiento dual.
26

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en productos
privativos deben comprar a la empresa una licencia especfica que les permita este
uso. Est desarrollado en su mayor parte en ANSI C.
Al contrario de proyectos como Apache, donde el software es desarrollado por una
comunidad pblica y los derechos de autor del cdigo estn en poder del autor
individual, MySQL es patrocinado por una empresa privada, que posee el copyright
de la mayor parte del cdigo.
Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado.
Adems de la venta de licencias privativas, la compaa ofrece soporte y servicios.
Para sus operaciones contratan trabajadores alrededor del mundo que colaboran
va Internet.
2. 10. 1. LENGUAJE DE PROGRAMACIN SOPORTADOS
Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de
programacin, acceder a las bases de datos MySQL,como ser:

C

C++

C#

26
http://dev.mysql.com/doc/
55

Pascal

Delphi (via dbExpress)

Eiffel, Smalltalk

Java (con una implementacin nativa del driver de Java)

Lisp

Perl

PHP

Python

Ruby,Gambas

REALbasic (Mac y Linux)

Cada uno de estos utiliza una API especfica. Tambin existe una interfaz ODBC,
llamado MyODBC que permite a cualquier lenguaje de programacin que soporte
ODBC comunicarse con las bases de datos MySQL. Tambin se puede acceder
desde el sistema SAP.
Gracias al soporte que brinda sobre el lenguaje de programacin java, MySQL se
convierte en el gestor de bases ms indicado para el desarrollo del aplicativo.
2. 10. 2. ESPECIFICACIONES DE MYSQL

PLATAFORMAS
MySQL funciona sobre mltiples plataformas:

GNU/Linux

Mac OS X

Solaris

SunOS

Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP,
Windows Vista, Windows 7 y Windows Server (2000, 2003 y 2008).
56

Debido a la predominancia del sistema operativo Windows 7 instalado en las
computadoras del laboratorio de enseanza, se ve la necesidad de que el sistema
gestor de base de datos en este caso MYSQL debe funcionar bajo la plataforma
mencionada.
2. 10. 3. CARACTERISTICAS DE MYSQL
Un amplio subconjunto de ANSI SQL 99, y varias extensiones.

Soporte a multiplataforma.

Procedimientos almacenados

Disparadores (triggers).

Vistas actualizables.

Soporte a VARCHAR

Motores de almacenamiento independientes (MyISAM para lecturas rpidas,
InnoDB para transacciones e integridad referencial).

Soporte para SSL.

Sub-SELECTs (o SELECTs anidados).

Rplica con un maestro por esclavo, varios esclavos por maestro, sin soporte
automtico para mltiples maestros por esclavo.

Embedded database library

Soporte completo para Unicode.
Todas las caractersticas mencionadas previamente son de gran ayuda al momento
de desarrollar el aplicativo y necesarias para su correcto funcionamiento, es por eso
que MYSQL se elegido como gestor de base de datos para el desarrollo de la
aplicacin.
2. 10. 4. LICENCIA
La licencia GNU GPL de MySQL obliga a que la distribucin de cualquier producto
derivado (aplicacin) se haga bajo esa misma licencia. Si un desarrollador desea
incorporar MySQL en su producto pero desea distribuirlo bajo otra licencia que no
sea la GNU GPL, puede adquirir una licencia comercial de MySQL que le permite
hacer justamente eso.
57

MySQL fue escogido para el desarrollo del aplicativo por sus siguientes
caractersticas:

MySQL posee licencia pblica.

Es un gestor de base de datos muy popular y bastante completo para el
desarrollo de aplicaciones de escritorio.

Brinda soporte sobre el lenguaje de programacin Java.

2. 11. NETBEANS

NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el
lenguaje de programacin Java. Existe adems un nmero importante de mdulos
para extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de
uso.
27

NetBeans es un proyecto de cdigo abierto de gran xito con una gran base de
usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en
todo el mundo. Sun MicroSystems fund el proyecto de cdigo abierto NetBeans en
junio de 2000 y contina siendo el patrocinador principal de los proyectos.

La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de
un conjunto de componentes de software llamados mdulos. Un mdulo es un
archivo Java que contiene clases de java escritas para interactuar con las APIs de
NetBeans y un archivo especial (manifest file) que lo identifica como mdulo.

Las aplicaciones construidas a partir de mdulos pueden ser extendidas
agregndole nuevos mdulos. Debido a que los mdulos pueden ser desarrollados
independientemente, las aplicaciones basadas en la plataforma NetBeans pueden
ser extendidas fcilmente por otros desarrolladores de software.
2. 11. 1. PLATAFORMA NETBEANS
La Plataforma NetBeans es una base modular y extensible usada como una
estructura de integracin para crear aplicaciones de escritorio grandes. Empresas
independientes asociadas, especializadas en desarrollo de software, proporcionan
extensiones adicionales que se integran fcilmente en la plataforma y que pueden
tambin utilizarse para desarrollar sus propias herramientas y soluciones.
La plataforma ofrece servicios comunes a las aplicaciones de escritorio,
permitindole al desarrollador enfocarse en la lgica especfica de su aplicacin.
Entre las caractersticas de la plataforma estn:

27
http://www.planetnetbeans.org/es/
58

Administracin de las interfaces de usuario (ej. mens y barras de
herramientas)

Administracin de las configuraciones del usuario

Administracin del almacenamiento (guardando y cargando cualquier tipo de
dato)

Administracin de ventanas

Framework basado en asistentes (dilogos paso a paso)
2. 11. 2. NETBEANS IDE
El IDE NetBeans es un entorno de desarrollo integrado, una herramienta para
programadores pensada para escribir, compilar, depurar y ejecutar programas. Est
escrito en Java pero puede servir para cualquier otro lenguaje de programacin.
Existe adems un nmero importante de mdulos para extender el IDE NetBeans.
El IDE NetBeans es un producto libre y gratuito sin restricciones de uso.
El NetBeans IDE es un IDE de cdigo abierto escrito completamente en Java
usando la plataforma NetBeans. El NetBeans IDE soporta el desarrollo de todos los
tipos de aplicacin Java (J2SE, web, EJB y aplicaciones mviles).
NetBeans IDE 6.5, la cual fue publicada el 19 de noviembre de 2008, extiende las
caractersticas existentes del Java EE (incluyendo Soporte a Persistencia, EJB 3 y
JAX-WS). Adicionalmente, el NetBeans Enterprise Pack soporta el desarrollo de
Aplicaciones empresariales con Java EE 5, incluyendo herramientas de desarrollo
visuales de SOA, herramientas de esquemas XML, orientacin a web servicies (for
BPEL), y modelado UML. El NetBeans C/C++ Pack soporta proyectos de C/C++,
mientras el PHP Pack, soporta PHP 5.
Desde julio de 2006, NetBeans IDE es licenciado bajo la Common Development and
Distribution License (CDDL), una licencia basada en la Mozilla Public License
(MPL).

Como ya se mencionaron las caractersticas tcnicas del NetBeans cabe recalcar
los siguientes puntos:
NetBeans IDE posee licencia pblica.

NetBeans IDE es un entorno de desarrollo integrado muy popular y bastante
completo para el desarrollo de aplicaciones de escritorio.

Brinda una interfaz sencilla para el desarrollo de aplicaciones de escritorio.

Brinda soporte para el gestor de base de datos MYSQL.

Brinda soporte para el lenguaje de programacin Java.
59

Capitulo 3
Marco aplicativo

60

3. MARCO DEL APLICATIVO
3. 1. INTRODUCCIN

El anlisis del proyecto Aplicacin informtica de gestin y apoyo en la
administracin de los usuarios de un laboratorio de computadoras conectadas en
una red de rea local, hace uso de los instrumentos, mtodos y tcnicas, descritas
en el capitulo anterior Marco terico brindando al laboratorio de enseanza un
aplicativo para la administracin de usuarios.

3. 2. ANLISIS DEL SISTEMA ACTUAL

En el laboratorio de enseanza diariamente se debe registrar nuevos usuarios,
almacenar sus datos personales y controlar su asistencia

Adems de generar reportes de los participantes y/o usuarios de los cursos
computacionales.

Estos procesos se realizan manualmente, lo que representa un esfuerzo por parte
de los encargados del laboratorio de enseanza por que cada vez se hace mas
grande el nmero de inscrito, lo cual genera una dificultad aun mayor para hacer un
control efectivo de asistencia, si contaran con un sistema de informacin, dichas
tareas se realizaran en un menor tiempo.

Tambin reducira notoriamente el tiempo que ocupan para el desarrollo de los
informes sobre los participantes de los cursos computacionales.

3. 3. PLANIFICACIN PARA EL DESARROLLO DEL SISTEMA

3. 3. 1. DESCRIPCION DE LOS ACTORES

A continuacin se da una lista de los actores o usuarios identificados.

Administrador

Es la persona encargada de registrar nuevos usuarios, crear cursos y generar
reportes de gestin.

Sus acciones mas propiamente descritas son las siguientes:

61

Introduce datos personales de los usuarios a un registro de inscripcin.

Crea nuevos cursos, detallando el nombre del curso, la fecha de inicio y
finalizacin del curso, tambin el horario de inicio y finalizacin del curso.

Genera reportes de asistencia de los participantes en los cursos
computacionales.

Genera reportes del total de participantes de los cursos computacionales
segn algn factor de discriminacin (edad, gnero, profesin, etc.).

Usuario

Es la persona que hace uso de las computadoras del laboratorio de enseanza, y
asiste a los cursos difundidos

Sus acciones mas propiamente descritas son las siguientes:

Introduce sus datos personales en los formularios de asistencia.

3. 3. 2. IDENTIFICACIN DE LOS CASOS DE USO

El proyecto Aplicacin informtica de gestin y apoyo en la administracin de los
usuarios de un laboratorio de computadoras conectadas en una red de rea local
esta constituido por los siguientes casos de uso:

62

Tabla 3.1: Identificacin de casos de uso

ACTOR CASOS DE USO

ADMINISTRADOR REGISTRO DE NUEVOS USUARIOS AL
SISTEMA.
REGISTRO DE NUEVOS CURSOS
EMISIN DE REPORTES DE ASISTENCIA
SOBRE PARTICIPANTES
EMISIN DE REPORTES GENERALES
SOBRE PARTICIPANTES.
EMISIN DE REPORTES GENERALES
SOBRE EL USO DE LAS
COMPUTADORAS.
USUARIO INSCRIPCION EN CURSO
COMPUTACIONAL
ASISTENCIA AL CURSO
COMPUTACIONAL

Fuente: Creacin propia

3. 3. 3. CATLOGO DE REQUERIMIENTOS DEL SISTEMA

Un proyecto no puede cumplir su objetivo sin una especificacin correcta y
exhaustiva de los requerimientos, donde describe las necesidades o deseos del
software a ser desarrollado.

Registro de los datos personales de los nuevos usuarios del laboratorio de
enseanza.

Realizar el seguimiento de las asistencias diarias de los usuarios del

Realizar reportes generales del total de participantes en los cursos
computacionales segn algn factor de discriminacin (edad, gnero,
profesin, etc.).

Realizar reportes generales del tiempo de uso de las computadoras del

63

3. 3. 4. FUNCIONES BSICAS DEL SISTEMA

Las funciones del sistema son aquellas acciones que el sistema deber realizar sin
fallas.

Estas funciones o requerimientos del sistema se detallan a continuacin
asignndoles adems la categora de visible y oculta.

Visible: Funcin que debe realizarse, y el usuario debera saber que se ha
realizado.

Oculta: Debe realizarse, aunque no es visible para los usuarios.

Funciones del administrador

Registro de nuevos usuarios al sistema

Tabla 3.2: Registro de nuevos usuarios al sistema.

FUNCIN CATEGORA
Llenar el formulario de datos
personales del nuevo
usuario.
Visible
Se introducen los datos
personales del nuevo usuario
al sistema.
Oculta
Generar mensaje sobre el
estado de la introduccin de
datos al sistema.
Visible

Fuente: elaboracin propia

64

Realizar el seguimiento de las asistencias diarias de los usuarios del
laboratorio de enseanza

Tabla 3.3: Realizar el seguimiento de las asistencias diarias de los usuarios del

Funcin CATEGORA
Introduccin del nombre del
curso al que se desea
acceder a la lista de la
asistencia de sus
participantes
Visible
Verificar el total de das
asistidos por parte de los
usuarios usuario del
laboratorio de enseanza a
determinado curso.
Oculta
Generar una tabla con los
datos personales de los
usuarios y el total de das
asistidos a un determinado
curso.
Visible


Realizar reportes generales del total de participantes en los cursos
computacionales segn algn factor de discriminacin (edad, gnero,
profesin, etc.).

Tabla 3.4: Realizar reportes generales del total de participantes segn algn factor de
discriminacin (edad, gnero, profesin, etc.).

Funcin Categora
Introduccin del nombre del
curso al que se desea
acceder a la lista de sus
participantes
Visible
Verificar el total de
participantes del determinado
curso.
Oculta
datos de los participantes del
determinado curso.
Visible

65

Realizar reportes generales del tiempo de uso de las computadoras del

Tabla 3.5: Realizar reportes generales del tiempo de uso de las computadoras del

FUNCIN CATEGORA
Introduccin del nmero de
terminal de las computadoras
a las que se desea acceder
para ver la informacin del
tiempo de uso de estas.
Visible
Verificar el tiempo de uso de
las computadoras del
Oculta
tiempos de uso de las
computadoras del laboratorio
de enseanza.
Visible


Funciones del cliente

Asistencia a los cursos computacionales

Tabla 3.6: Asistencia a los cursos computacionales.

FUNCIN CATEGORA
Llenar dos campos de texto
para marcar sus asistencia a
determinado curso
Visible
Comprobar la veracidad de
los datos introducidos
previamente e introducir a la
base de datos un registro del
da asistido
Oculta
Generar un mensaje de
conformidad sobre la
correcta marcacin del da de
asistencia
Visible


66

3. 4. ANLISIS

3. 4. 1. DIAGRAMA DE CASOS DE USO

El siguiente diagrama de casos de uso explica los requerimientos de los actores
involucrados al sistema.

Figura 3.1: Diagrama de caso de uso principal.

Fuente: Creacin propia.

genera reportes
usuario no
registrado
solicita inscripcion a un curso
Administrador
usuario registrado
inicia sesin
cierra sesin
crea cursos
registra usuarios
inserta datos al sistema
67

Especificacin de los casos de uso

Casos de uso del usuario.
Tabla 3.7: Especificacin de caso de uso solicitud de inscripcin.
Nombre caso de uso: Solicitud de inscripcin
Actores involucrados: Usuarios no registrados, Administrador.
Precondicin: El usuario no debe estar registrado en el
sistema.
Camino normal: 1. El usuario no registrado se
aproxima al administrador.
2. El administrador informa al usuario
no registrado de los cursos
ofertados.
3. El usuario no registrado solicita su
registro al administrador en alguno
de los cursos ofertados.
4. El administrador inscribe al usuario
en alguno de los cursos ofertados
Camino alternativo: 4.1 El administrador informa de algn
fallo en la inscripcin al curso.
Post-condicin:

El usuario pasa a estar inscrito en algn
curso.

Tabla 3.8: Especificacin de caso de uso inicio de sesin.
Nombre caso de uso: Inicio de sesin
Actores involucrados: Usuarios registrados.
Precondicin: El usuario debe estar registrado en
el sistema y contar con su login y
password.
Camino normal: 1. El usuario ingresa su login y
password a travs de la
interfaz del sistema.
2. El sistema comprueba la
correctitud de los datos
introducidos.
3. El sistema devuelve un
mensaje de inicio de sesin
exitoso.
Camino alternativo: 3.1 El sistema devuelve un
mensaje de error con
respecto a los datos
introducidos.

Post-condicin: El usuario inicia sesin

68

Tabla 3.9: Especificacin de caso de uso cierre de sesin.
Nombre caso de uso: Cierre de sesin
Actores involucrados: Usuarios registrados
Precondicin: El usuario debe haber iniciado
sesin correctamente.
Camino normal: 1. El usuario accede a cerrar su
sesin.
2. El sistema almacena los
datos de salida.
mensaje de cierre de sesin
exitoso.
mensaje de error al momento
de cerrar sesin.

Post-condicin:

El usuario cierra sesin
correctamente.

Casos de uso del administrador.
Tabla 3.10: Especificacin de caso de uso registro de usuario.
Nombre caso de uso: Registro de usuario
Actores involucrados: Usuarios no registrados,
Administrador.
Precondicin: El usuario no debe estar registrado
Camino normal: 1. El usuario no registrado se
aproxima al administrador.
2. El usuario no registrado
solicita su registro al
administrador.
3. El usuario no registrado
facilita sus datos personales
al administrador.
4. El administrador ingresa
dichos datos al sistema.
5. El administrador informa del
registro exitoso al usuario.

Camino alternativo: 5.1 El administrador informa de
fallo en el registro al sistema.
Post-condicin:

El usuario no registrado pasa a
estar registrado en el sistema

69

Tabla 3.11: Especificacin de caso de uso creacin de un nuevo curso.
Nombre caso de uso: Creacin de un nuevo curso
Actores involucrados: Administrador
Precondicin: El administrador desea crear un
nuevo curso.
Camino normal: 1. El administrador ingresa al
sistema a travs de la
interfaz de creacin de un
nuevo curso.
2. El sistema comprueba la
correctitud de los datos
introducidos.
mensaje de creacin de
curso exitoso.
de crear el curso.
Post-condicin:

El administrador crea el curso
exitosamente.

Tabla 3.12: Especificacin de caso de uso generacin de reportes.
Nombre caso de uso: Generacin de reportes.
Actores involucrados: Administrador
Precondicin: El administrador desea generar
algn reporte
Camino normal: 1. El administrador accede al
sistema a travs de la
interfaz del men de
reportes.
2. El administrador ingresa el
tipo de reporte que desea
generar.
3. El sistema devuelve el
reporte pedido por el
administrador.
de generar el reporte
especificado.
Post-condicin:

El administrador genera el reporte
especificado.

70

3. 4. 2. DIAGRAMA DE SECUENCIA

El diagrama de secuencia mostrara la forma en que se comunican los objetos al
transcurrir el tiempo en el orden de las llamadas/eventos del sistema.

A continuacin se muestran los diagramas de secuencia correspondientes al
sistema:

Usuario

Figura 3.2: Diagrama de secuencia para solicitud de usuario para la inscripcin a un
curso.


usuario no
registrado
administrador
solicitud de inscripcin a un curso
recoleccin de datos para la inscripcion
facilitacion de datos personales
mensaje sobre el estado de inscripcin
71

Figura 3.3: Diagrama de secuencia para inicio de sesin del usuario registrado.


Figura 3.4: Diagrama de secuencia para cierre de sesin del usuario registrado.


usuario
registrado
sistema
introduccion de datos login y password
mensaje con el estado de sesin actual
comprobacion de corecctitud de datos
insercin de datos de entrada al sistema
usuario
registrado
sistema
mensaje para cierre de sesin
insercion de datos de salida al sistema
mensaje con el estado de sesin actual
72

Administrador
Figura 3.5: Diagrama de secuencia para registro de nuevo usuario.


Figura 3.6: Diagrama de secuencia para creacin de un nuevo curso.

administrador sistema
introduccin de datos de un nuevo usuario
comprobacion sobre correctitud de los datos introducidos
insercin de datos al sistema
mensaje sobre el estado de registro de usuario
introduccin de datos del nuevo curso
comprobacion sobre correctitud de los datos introducidos
insercin de datos al sistema
mensaje sobre el estado de creacin del nuevo curso
73

Figura 3.7: Diagrama de secuencia para generacin de informe de asistencia.

Figura 3.8 Diagrama de secuencia para generacin de reportes sobre participantes


introduccin de datos para generar informe de asistencia
consulta de datos al sistema
detalle del informe de asistencia
introduccin de datos para generar reporte de participantes
detalle del reporte sobre participantes
74

Figura 3.9: Diagrama de secuencia para generacin de reportes sobre computadoras


3. 4. 3. DIAGRAMA DE COLABORACIN

Figura 3.10: Diagrama de colaboracin de inicio de sesin de usuario.


introduccin de datos para generar reporte sobre computadoras
detalle del reporte sobre computadoras
interfaz sistema
usuario registrado
(f rom Use-Case Model)
salida sistema
inicio sesion
el usuario introduce
sus datos sistema
el sistema almacena
datos de entrada
el sistema devuelve mensaje
del estado de sesin
el usuario ve el mensaje
sobre el estado de sesin
75

Figura 3.11: Diagrama de colaboracin de cierre de sesin de usuario.


Figura 3.12: Diagrama de colaboracin de registro de usuario.


interfaz sistema
usuario registrado
salida sistema
cierre sesion
el usuario introduce su mensaje
para el cierre de sesin
el sistema almacena
datos de salida
el sistema devuelve mensaje
del estado de sesin
el usuario ve el mensaje
sobre el estado de sesin
interfaz menu registro
usuario
estado
registro
salida
sistema
Administrador
ingresa al menu
de administrador
ingresa al fomulario
de registro
el sistema asigna un login
al usuario
el sistema devuelve el
dato generado
el administrador observa
el dato generado
76

Figura 3.13: Diagrama de colaboracin de generacin de informe de asistencia.


Figura 3.14: Diagrama de colaboracin de generacin de reporte especfico.


interfaz menu
menu informe
asistencia
opciones informe
asistencia
estado
informe
salida
Administrador
de administrador
ingresa al menu ingresa al menu
de informes de asitencia
selecciona una opcin
para generar el informe
dato generado
el sistema muestra en una
el dato generado
interfaz menu menu reporte opciones reporte
Administrador
salida estado reporte
ingresa al menu
de administrador
ingresa al menu
de generacion de reportes
para generar el reporte
tabla el informe
el dato generado
dato generado
77

Figura 3.15: Diagrama de colaboracin de generacin de reporte del uso de las
computadoras.


Figura 3.16: Diagrama de colaboracin de creacin de nuevo curso.


menu reporte reporte
computadoras
estado reporte
interfaz menu
Administrador
salida
de administrador
ingresa al menu
ingresa al menu de generacin
de reportes de computadoras
para generar el reporte
dato generado
tabla el informe
el dato generado
crear nuevo curso
estado creacion curso
interfaz menu
Administrador
salida
ingresa al menu
de administrador
introduce los datos del curso
ingresa al menu para
la creacin de un curso
estado del curso creado
el dato generado
78

3. 4. 4. DIAGRAMA DE CLASES

Figura 3.16: Diagrama de clases del sistema.


79

3. 4. 5. DIAGRAMA DE ESTADOS

Figura 3.17: Diagrama de estado de inicio de sesin de usuario.


Figura 3.18: Diagrama de estado de cierre de sesin de usuario.


Figura 3.19: Diagrama de estado de registro de usuario.


introduccin
datos
datos
correctos
datos
incorrectos
inicio de sesin
correcto
error al introducir
los datos
mensaje
cierre sesin
cierre de
sesin
introduccin de datos
para crear curso
datos
correctos
datos
incorrectos
error al introducir
los datos
insercion de datos
del usuario
80

Figura 3.20: Diagrama de estado de generacin de informe de asistencia.


Figura 3.21: Diagrama de estado de generacin de reporte especfico.


Figura 3.22: Diagrama de estado de generacin de reporte del uso de las computadoras.


Figura 3.23: Diagrama de estado de creacin de nuevo curso.


introduccin de datos para
generar informe generacion de
informe en tabla
generar reporte de participantes
generacion de
reporte en tabla
generar reporte de computadoras
generacion de
reporte en tabla
introduccin de datos
para crear curso
datos
correctos
datos
incorrectos
error al introducir
los datos
insercion de
datos del curso
81

3. 4. 6. DIAGRAMA DE COMPONENTES

Figura 3.24: Diagrama de componentes del sistema.


interfaz_cliente.java
conector_java_c
on_mysql.jar
socket
base de datos
interfaz_servidor.java
conectar.java
registro_
usuarios.java
reportes_generados.
java
insersion_datos.
java
insercion datos_
entrada_salida.java
82

3. 5. MODELOS CONCEPTUAL DE LA BASE DE DATOS DEL
SISTEMA

A continuacin se presenta el modelo conceptual de la base de datos del sistema
que es representado grficamente a travs del modelo entidad-relacin.

Figura 3.25: Modelo entidad-relacin del sistema.


asi ste
asi sti o
usa
usuari o
cod_usuari o
nombres
apel l i do_pat
apel l i do_mat
edad
genero
profesi on
col egi o_i nsti tuci on
curso
fecha_i nscri pci on
fecha_naci mi ento
fecha_i ni _curso
fecha_fi n_curso
di recci on
mai l
tel efono
cel ul ar
password
<pi > <Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<M>
Identi fi er_1 <pi >
asi stenci a
cod_asi tenci a
di a_uso
i d_curso
i d_compu
fecha_i ni
fecha_fi n
hora_i ni
hora_fi n
<pi > <Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<M>
cursos
cod_curso
nombre
fecha_i ni
fecha_fi n
horari o_i ni
horari o_fi n
<pi > <Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<M>
computadora
cod_compu
termi nal
hora_i ni
hora_fi n
di a_uso
i d_usuari o
<pi > <Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<Undefi ned>
<M>
83

3. 6. DISEO DE LA INTERFAZ DE USUARIO

En las siguientes imgenes se muestra el prototipo inicial de la interfaz del sistema.
3. 6. 1. USUARIO DEL SISTEMA

Figura 3.26: Vista de la solicitud de autentificacin del usuario.

Descripcin.-La figura, muestra la ventana de ingreso al sistema por parte del
usuario.

Figura 3.27: Vista de solicitud de autentificacin aceptada.

Descripcin.-La figura, muestra la ventana de autentificacin exitosa donde se indica
al usuario que el inicio de sesin fue exitoso y se le recuerda que debe cerrar
sesin al finalizar el uso de la computadora pulsando en el botn cerrar.
84

3. 6. 2. ADMINISTRADOR DEL SISTEMA

Figura 3.28: Vista de men principal del administrador del sistema.

Descripcin.-la figura, muestra el men principal del administrador del sistema,
atreves del cual puede ingresar a las diversas opciones como ser reportes, registro
de nuevos usuario, edicin de datos de usuario y ver reportes de tablas de
asistencia.

Figura 3.29: Vista de men de reportes del sistema.

Descripcin.-la figura, muestra el men de reportes donde se especifica el detalle
necesario para la impresin de reportes.
85

Figura 3.30: Vista formulario de inscripcin de nuevos usuarios.

Descripcin.-la figura, muestra el formulario de inscripcin de nuevos usuarios al
sistema.

86

Figura 3.31: Vista ventana de registro exitoso de nuevos usuarios.

Descripcin.-la figura, muestra una ventana notificando el registro exitoso del nuevo
usuario y otras opciones ms.

Figura 3.32: Vista ventana de edicin de datos de usuario.

Descripcin.-la figura, muestra una ventana donde se debe introducir el login del
usuario a ser editado.

87

Figura 3.33: Vista ventana men de asistencia de usuarios.

Descripcin.-la figura, muestra una ventana donde se puede escoger la modalidad
para ver los reportes de asistencia de los usuarios.

Figura 3.34: Vista ventana de asistencia de usuarios por das de la semana.

Descripcin.-la figura, muestra una ventana donde se puede apreciar la asistencia
de los usuarios en el transcurso de la semana en determinado curso

88

Capitulo 4
Calidad del software

89

4. CALIDAD DEL SOFTWARE
4. 1. INTRODUCCIN

La calidad del software es un tema al cual todos los programadores dedican gran
parte del tiempo y grandes esfuerzos, a pesar de esto el software casi nunca es
perfecto.

Todo proyecto tiene como objetivo producir software de calidad, que cumpla los
requerimientos de los usuarios e incluso pueda superar sus expectativas.
La calidad de concordancia es un aspecto en el desarrollo de software que se aboca
principalmente a la implementacin, es decir si la implementacin sigue al diseo y
el sistema resultante cumple con los objetivos de requisitos, la calidad de
concordancia es alta.
Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del
software:
Funcionalidad

Confiabilidad

Portabilidad

Mantenibilidad

4. 2. FUNCIONABILIDAD

El punto funcin es una mtrica que pretende medir la funcionalidad entregada al
usuario independientemente de la tecnologa utilizada para la construccin y
explotacin del software
Se centra en la funcionalidad o utilidad del programa, los puntos de funcin se
calculan realizando una serie de actividades comenzando por determinar los
siguientes nmeros:

Nmero de entradas de usuarios. Se cuenta cada entrada del usuario a la
aplicacin que proporciona diferentes datos orientados a la aplicacin.

Nmero de salidas de usuarios. Se cuenta cada salida que proporciona al
usuario la aplicacin. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos de datos particulares dentro
de un informe no se cuentan de forma separada.

90

Nmero de consultas. Una consulta esta definida como una entrada interactiva
que resulta de la generacin de algn tipo de respuesta en forma de salida.

Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un
grupo lgico de datos que puede ser una parte de una gran base de datos o
un archivo independiente).

Nmero de interfaces externas. Se cuenta todas las interfaces legibles por el
ordenador que son solicitados para transmitir informacin a otro sistema.

De acuerdo a lo mencionado anteriormente se tienen los siguientes resultados en la
tabla:
Tabla 4.1: Entradas para el clculo de funcionalidad.

Entradas de usuario 450
Salidas de usuario 500
Consultas de usuario 400
Nmero de archivos 700
Interfaces externas 0

Los puntos de funcin se calculan rellenando la tabla 4.2 con los datos obtenidos,
considerando un factor de ponderacin medio.

Tabla 4.2: Clculo de puntos de funcin sin ajustar.

Fuente:
Creacin propia.

Parmetros de
medicin conteo
factor de ponderacin
medio totales
Nmero de entradas
de usuario 450 x 4 = 1800
Nmero de salidas de
usuario 500 x 5 = 2500
Nmero de consultas
de usuario 400 x 4 = 1600
Nmero de archivos 700 x 10 = 7000
Nmero de interfaces
externas 0 x 7 = 0
Puntos de funcin no ajustados 12900
91

La siguiente relacin nos permite calcular los puntos de funcin:
PF=CUENTA_TOTAL*(Grado_de_Confiabilidad+Tasa_de_error* fi)

PF = Puntos de funcin

CUENTA_TOTAL = Es la suma del valor de las entradas, salidas, consultas,
archivos e interfaces externas.

Grado_de_confiabilidad = Es la confiabilidad estimada del sistema.

Tasa_de_error = Probabilidad subjetiva estimada del dominio de la
informacin, este error estimado es del 1%.

Fi = Son valores de ajuste de complejidad que toman los valores de la tabla
4.4 y que dan respuesta a las preguntas de la tabla 4.3

92

Tabla 4.3: Ajuste de complejidad del punto funcin.

Factor 0 1 2 3 4 5
1. Requiere el sistema copias de seguridad y de
recuperacin fiables? x
2. Requiere comunicacin de datos? x
3. Existen funciones de procesamiento distribuido? x
4. Es crtico el rendimiento? x
5. Se ejecutar el sistema en un entorno operativo
existente y fuertemente utilizado? x
6. Requiere entrada de datos interactiva? x
7. Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre
mltiples pantallas u operaciones? x
8. Se actualizan los archivos maestros de forma
interactiva? x
9. Son complejas las entradas, las salidas, los archivos
o las peticiones? x
10. Es complejo el procesamiento interno? x
11. Se ha diseado el cdigo para ser reutilizable? x
12. Estn incluidas en el diseo la conversin y la
instalacin? x
13. Se ha diseado el sistema para soportar mltiples
instalaciones en diferentes organizaciones? x
14. Se ha diseado la aplicacin para facilitar los
cambios y para ser fcilmente utilizada por el usuario? x


Gracias al clculo de los anteriores datos y considerando un grado de confiabilidad
del 65% es que a continuacin calculamos el valor de PF:

PF = Cuenta_Total*(Grado_de_Confiabilidad + Tasa_de_error*Fi)

PF = 12900 * (0.65 + 0.01 * 38)

PF = 13287

Si consideramos el mximo valor de ajuste de complejidad como Fi = 70, se tiene:

PF = 12900 * (0.65 + 0.01 * 70)
93

PF = 17415

Entonces si Fi es considerada como el 100%, la relacin obtenida entre los puntos
ser:

PF / Pf mximo = 13287/17415 = 0.76

Por lo tanto la funcionalidad del sistema es del 76% tomando en cuenta el punto de
funcin mximo.

4. 3. CONFIABILIDAD

En la cantidad de tiempo que el software esta disponible para su uso, es posible
medir la confiabilidad tomando en cuenta la probabilidad del sistema que este libre
de fallos en un contexto determinado y durante un periodo de tiempo

Probabilidad de hallar una falla: P (T<=t) = F(t)

Probabilidad de no hallar una falla: P (T>t) = 1 F(t)

Con F (t) = Fc * (e (-/7 * 12) )

Donde:

Fc=0.76: Funcionalidad del sistema.

=1: Tasa de fallos en 7 ejecuciones dentro de un mes.

Hallando la confiabilidad:

F (t) = Fc * (e (-/7 * 12) )
F (t) = 0.76 * (e (-1/7 * 12) )
F (t) = 0.14

P (T<=t) = F (t)
0.14

94

1 F (t)
1-0.14 = 0.86

Por lo tanto, el sistema presenta una confiabilidad del 0.86, lo que quiere decir que
el 86% de las ocasiones, el sistema funciona sin presentar fallos y el resto (14%),
presenta fallos que no afectan de sobremanera el desempeo global del sistema.
4. 4. PORTABILIDAD

El presente sistema funciona bajo un hardware estable del lado del servidor, esta
dado por un equipo con procesador dual core, el acceso a este servidor es a travs
de una intranet donde solo pueden acceder los usuarios autorizados dentro la red
de rea local.

Las terminales de donde se accede al servidor tienen caractersticas de ser equipos
procesadores dual core.

Por otro lado el Sistema Operativo del lado del servidor es Windows 7, al igual que
las terminales de acceso al sistema.

El software es apto para funcionar bajo distintas plataformas, especficamente en
Linux debido a que es una aplicacin hecha en lenguaje de programacin java y
Gestor de Base de Datos MySQL.

Por lo tanto, podemos concluir que el sistema no requiere de un gran esfuerzo para
su traslado de un entorno a otro ya sea a nivel de Hardware o a nivel de Software.

4. 5. MANTENIBILIDAD

4. 5. 1. MANTENIMIENTO ADAPTIVO

El mantenimiento adaptativo que se podra ejecutar sobre el sistema ocurrir
cuando se cambien la estructura del funcionamiento del laboratorio de enseanza, a
ciertos cambios el sistema est preparado para adaptarse, pero para otros ms
complejos se deber hacer revisin de los procesos y su adaptacin con los nuevos
cambios que se generen.

4. 5. 2. MANTENIMIENTO PERFECTIVO
El sistema contempla algunos cambios con respecto a su mantenibilidad, cambios
que siempre y cuando sean relacionados con el servicio e informacin que brinda el
sistema.

Proyecto Final Escuela Virtual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Proyecto Final Escuela Virtual

Hochgeladen von

Copyright:

Verfügbare Formate

1

Das könnte Ihnen auch gefallen