sistema para dar soporte en la generaciÓn del contenido de...
TRANSCRIPT
UNIVERSIDAD NACIONAL ABIERTA VICERRECTORADO ACADEMICO
AREA DE INGENIERÍA
CARRERA INGENIERÍA DE SISTEMAS
SISTEMA PARA DAR SOPORTE EN LA GENERACIÓN
DEL CONTENIDO DE UN CURSO APLICANDO RECURSOS
MULTIMEDIA, Caso de Estudio CURSO INTRODUCTORIO.
Autor: Euhen Alexander Sochackyj Amaro
Cédula de Identidad: 11.808.157
Centro Local: Aragua
Maracay, Enero del 2004
UNIVERSIDAD NACIONAL ABIERTA VICERRECTORADO ACADEMICO
AREA DE INGENIERÍA
CARRERA INGENIERÍA DE SISTEMAS
SISTEMA PARA DAR SOPORTE EN LA GENERACIÓN
DEL CONTENIDO DE UN CURSO APLICANDO RECURSOS
MULTIMEDIA, Caso de Estudio CURSO INTRODUCTORIO.
Autor: Euhen Alexander Sochackyj Amaro
C.I.: 11.808.157
Tutor Académico: Ing. Mireya Delgado
Tutor Industrial: Ing. Judith Carvallo
Centro Local Aragua
Maracay, Enero, 2004
UNIVERSIDAD NACIONAL ABIERTA VICERRECTORADO ACADEMICO
AREA DE INGENIERÍA
CARRERA INGENIERÍA DE SISTEMAS
SISTEMA PARA DAR SOPORTE EN LA GENERACIÓN DEL CONTENIDO DE
UN CURSO APLICANDO RECURSOS MULTIMEDIA, Caso de Estudio CURSO
INTRODUCTORIO.
Resumen El presente Trabajo de Grado, que se centró en “el desarrollo de un sistema para dar soporte en la generación del contenido de un Curso aplicando recursos Multimedia”, interactúa con el personal académico responsable del nuevo diseño curricular del Curso Introductorio de la Universidad Nacional Abierta. Con el propósito de lograr una base firme de comunicación e interacción, se empleó tecnología de punta mediante el uso de una Red Local empleando tecnología de Internet como herramienta de comunicación y los servicios FTP que hace posible el transporte de los datos en tiempo real. La estrategia metodológica utilizada esta enmarcado en el desarrollo de sistemas orientados a objeto mediante el Proceso Unificado Rational propuesto por Jacobson, Booch, Rumbaugh y Kruchten como marco central dirigido por Casos de Uso, centrado en la arquitectura y desarrollado a través de un ciclo de vida iterativo e incremental, aunado a la metodología de sistemas de actividad humana propuesta por Checkland la cual permitió enfrentar problemas no estructurados donde los objetivos y las necesidades estaban vagamente definidas. Para reforzar las pruebas del sistema se desarrolló un instrumento basado en la estructura PIECES propuesta por James Wetherbe, el cual permitió validar el producto final obtenido, capturando la opinión de los usuarios durante la confrontación del prototipo. La metodología empleada trae como beneficios generales el aumento en la reutilización de los componentes de software, y la fácil adaptación a los cambios de los requerimientos, entre otros.
Palabras Claves: sistemas suaves, PIECES, prototipo evolutivo, Proceso
Orientado a Objeto, UML.
INDICE GENERAL pp DEDICATORIA..................................................................................................................... iv AGRADECIMIENTO............................................................................................................ v INDICE GENERAL............................................................................................................... vi INDICE DE FIGURAS........................................................................................................... INDICE DE TABLAS............................................................................................................ INTRODUCCIÓN.................................................................................................................. 1 Capítulo I Marco Teórico....................................................................................................... 3 I.1 Recursos Multimedia, La Educación a Distancia y las Redes Locales empleando Tecnología de Internet.......................................................................................... 3 I.2 Principios y Lineamientos de Usabilidad de Interfaces realizados por Jacob Nielsen.......................................................................................................................... 7 I.2.1 Principios y lineamientos en el Diseño.......................................................................... 7 I.2.2 Principio y lineamientos referentes a la Navegabilidad o Interacción con el sistema.... 8 I.2.3 Acerca de la Usabilidad de Sistemas.............................................................................. 9 I.3 Métodos y Procedimientos aplicados al Marco Metodológico.......................................... 10 I.3.1 Objeto............................................................................................................................. 10 I.3.1.1- Características de un Objeto....................................................................................... 12 I.3.1.2 Mensaje........................................................................................................................ 13 I.3.2 Clases.............................................................................................................................. 13 I.3.2.1 Atributo....................................................................................................................... 15 I.3.2.2 Operación..................................................................................................................... 16 I.3.2.3 Método......................................................................................................................... 16 I.3.3 El Enfoque Orientado a Objeto para el desarrollo de sistemas....................................... 17 I.3.3.1 Análisis Orientado a Objeto......................................................................................... 17 I.3.3.2 Diseño Orientado a Objeto.......................................................................................... 17 I.3.4. El Modelo de Objetos.................................................................................................... 18 I.3.4.1 Abstracción.................................................................................................................. 18 I.3.4.2 Encapsulamiento.......................................................................................................... 19 I.3.4.3 Modularidad................................................................................................................. 20 I.3.4.4 Jerarquía....................................................................................................................... 20 I.3.4.5 Tipos............................................................................................................................ 20 I.3.4.6 Concurrencia................................................................................................................ 20 I.3.4.7 Persistencia.................................................................................................................. 21 I.3.5 Relaciones entre Objetos y entre Clases........................................................................ 21 I.3.5.1 Relaciones entre Objetos............................................................................................. 21 I.3.5.1.1 Enlace........................................................................................................................ 21 I.3.5.1.2 Agregación................................................................................................................ 21 I.3.5.2 Relaciones entre Clases............................................................................................... 23 I.3.5.2.1 Herencia.................................................................................................................... 23 I.3.5.2.2 Asociación................................................................................................................ 24 I.3.5.2.3 Multiplicidad............................................................................................................. 25 I.3.5.3 Dependencia o Instanciación (uso).............................................................................. 26 I.3.5.4 Polimorfismo............................................................................................................... 27
I.3.6 Lenguaje de Modelado Unificado (UML)...................................................................... 27 I.3.7- Conceptos Metodológicos del Proceso de Desarrollo Unificado Rational (RUP)...................................................................................................................................... 28 I.3.7.1 Requerimientos............................................................................................................ 30 I.3.7.1.1 Modelo de Casos de Uso.......................................................................................... 31 I.3.7.1.1.1 Actor ..................................................................................................................... 31 I.3.7.1.1.2 Casos de Uso......................................................................................................... 32 I.3.7.1.1.3 Relaciones entre Casos de Uso.............................................................................. 33 I.3.7.2 Prototipos..................................................................................................................... 34 I.3.7.3 Análisis y Diseño........................................................................................................ 36 I.3.7.3.1 Artefactos que se Desarrollan en la Disciplina de Análisis y Diseño....................... 36 I.3.7.3.1.1 Modelo de Análisis................................................................................................ 36 I.3.7.3.1.2 Clases de Análisis.................................................................................................. 36 I.3.7.3.1.3 Modelo de Diseño.................................................................................................. 37 I.3.7.3.1.4 Clases de Diseño................................................................................................... 37 I.3.7.3.1.5 Diagramas en el Modelo de Diseño...................................................................... 37 I.3.7.3.1.5.1 Diagrama de Clases............................................................................................ 37 I.3.7.3.1.5.2 Diagramas de Colaboración................................................................................ 38 I.3.7.3.1.5.3 Diagramas de Secuencia..................................................................................... 38 I.3.7.4 Implementación.......................................................................................................... 41 I.3.7.4.1 Artefactos de la Disciplina de Implementación........................................................ 41 I.3.7.4.1.1 Modelo de Implementación................................................................................... 41 I.3.7.4.1.2 Componentes......................................................................................................... 42 I.3.7.5 Prueba......................................................................................................................... 42 I.3.7.5.1 Plan de Prueba.......................................................................................................... 42 I.3.8 Términos de la Metodología de Sistemas Suaves (SSM).............................................. 43 I.3.8.1 Pensamientos de Sistemas........................................................................................... 43 I.3.8.2 Pensamientos de Sistemas “duros” ............................................................................. 43 I.3.8.3 Pensamientos de Sistemas “suaves”............................................................................ 43 I.3.8.4 Metodología en general (SSM).................................................................................... 44 I.3.8.5 Técnicas....................................................................................................................... 44 I.3.8.6 Sistema de actividad humana....................................................................................... 44 Capítulo II Definición del Trabajo de Grado.......................................................................... 45 II.1 Título del Proyecto........................................................................................................... 45 II.2 El Problema, Sus Antecedentes, Una Alternativa de Solución........................................ 45 II.3 Objetivos del Proyecto..................................................................................................... 48 II.3.1. Objetivo general........................................................................................................... 48 II.3.2 Objetivos específicos.................................................................................................... 48 II.4 Alcances del Proyecto...................................................................................................... 49 Capítulo III Metodología y Resultados................................................................................... 50 III.1 Disciplina: Conceptualizar el Sistema............................................................................. 55 III.1.1 Actividad 1: Indagar sobre la Metodología de Sistemas de Actividad Humana........ 56 III.1.2 Actividad 2: Conceptualizar el Sistema formulando Definiciones Raíz de Sistemas Pertinentes...................................................................................................
66
III.1.3. Actividad 3: Confeccionar y Verificar un Modelo Conceptual.................................. 69 III.2 Disciplina: Requerimientos............................................................................................. 71
III.2.1. Actividad 1: Identificar los Actores........................................................................... 72 III.2.2. Actividad 2: Identificar los Casos de Uso.................................................................. 73 III.2.3. Actividad 3: Documentar los Casos de Uso............................................................... 76 III.2.4. Actividad 4: Establecer las Relaciones Presentes...................................................... 78 III.3 Disciplinas: Análisis y Diseño........................................................................................ 82 III.3.1 Actividad 1: Identificar las Clases de Análisis mediante los Casos de Uso................ 83 III.3.2 Actividad 2: Diseñar las Interfaces del Usuario........................................................... 85 III.3.3 Actividad 3: Modelar las relaciones entre las Clases de Análisis mediante Diagramas de Colaboración.................................................
88
III.3.4 actividad 4: identificar las clases de diseño a partir de las clases de análisis.............. 90 III.3.5 Actividad 5: Modelar las Vistas Dinámicas entre Clases mediante Diagramas de Secuencias.............................................................................
93
III.3.6 Actividad 6: Modelar las Vistas Estática de las Clases de Diseño identificadas......... 95 III.3.7 Actividad 7: Construir el Diccionario de Clases del Sistema...................................... 101 III.4 Disciplinas: Implementación........................................................................................... 111 III.4.1 Actividad 1: Construir Prototipo Evolutivo................................................................. 112 III.4.2 Actividad 2: Generar el código fuente......................................................................... 113 III.5 Disciplinas: Prueba.......................................................................................................... 115 III.5.1 Actividad 1: Realizar Pruebas de sistema.................................................................... 115 III.5.2 Actividad 2: Realizar Pruebas con los Usuarios.......................................................... 116 III.6 Disciplinas: Documentación........................................................................................... 118 III.6.1 Actividad 1: Elaborar la documentación del sistema................................................... 119 III.6.2 ACTIVIDAD 2: Adiestrar al personal relacionado que utilizará el Sistema............... 119 Conclusiones y Recomendaciones.......................................................................................... 120 Bibliografias y Referencias Bibliográficas............................................................................. 123 Apéndice A Resultados de Requerimientos............................................................................ 125 Apéndice B Resultados de Análisis y Diseño......................................................................... 151 Anexo Metodología en Resumen (después de Checkland, 1975)........................................... 198
INDICE DE FIGURAS pp Fig. 1 Representación de la Clase en UML............................................................................ 14 Fig. 2 Clases y Objetos (Martin/Odell,1994)........................................................................ 15 Fig. 3 Operaciones en una clase(Martin/Odell,1994)............................................................ 16 Fig. 4 Ejemplo de Agregación................................................................................................ 22 Fig. 5 Notación en diagrama de clases para herencia (Modelado de Objetos con UML)....... 24 Fig. 6 Clasificación de la naturaleza de una asociación por una forma verbal (Modelos de Objetos con UML).............................................................................................
25
Fig. 7 Multiplicidad de una asociación "uno-uno" (Modelado de Objeto con UML)........... 26 Fig. 8 Multiplicidad de una asociación de "uno-muchos" (Modelado de Objeto con UML)............................................................................................
26
Fig. 9. Ejemplo de Instanciación............................................................................................. 26 Fig. 10 Muestra la arquitectura global del RUP..................................................................... 29 Fig. 11 Representación del Actor por UML........................................................................... 31 Fig. 12 Representación de un Caso de Uso por UML............................................................ 32 Fig. 13 Representación del diagrama de Casos de Uso por UML.......................................... 33 Fig. 14 Representación de un diagrama de secuencia........................................................... 39 Fig. 15 Diagrama de Secuencia con eventos.......................................................................... 40 Fig. 16 Izquierda: Mensaje de un objeto a otro objeto. Derecha: Mensaje al mismo objeto.........................................................................................
40
Fig. 17 Fases y Disciplinas en la Estrategia Metodológica de desarrollo.............................. 51 Fig. 18 Estrategia Metodología Aplicada en el Trabajo de Grado......................................... 53 Fig. 19 Ejemplo de Uso para Guía para las actividades de la estrategia metodológica de desarrollo.....................................................................................................
54
Fig. 20 Los estadíos 1 y 2 (Checkland; 1993. Pág. 190)......................................................... 57 Fig. 21 Estadío 3 (Checkland; 1993. Pág. 192)....................................................................... 59 Fig. 22 Estadíos 4 (Checkland; 1993. Pág. 194)..................................................................... 59 Fig. 23 Ejemplo modelo conceptual de sistema de actividad humana (Checkland; 1993. Pág. 320)...................................................................................................
61
Fig. 24 Estadío 5 (Checkland; 1993. Pág. 202)...................................................................... 62 Fig. 25 Los estadíos 6 y 7 (Checkland; 1993. Pág. 206)......................................................... 64 Fig. 26 Transformación que ejecuta el Sistema Generador (Elaborado por el tesista).......... 68 Fig. 27 Modelo Conceptual Del Generador del Curso Introductorio..................................... 70 Fig. 28 Diagrama de Casos de Uso del Subsistema Administrar Contenido.......................... 80 Fig. 29 Diagrama de Casos de Uso del Subsistema Administrar Aspectos Técnicos............. 80 Fig. 30 Diagrama de Casos de Uso del Subsistema Generar Estructura y Test de Evaluación................................................................................
81
Fig. 31 Diagrama de Casos de Uso del Subsistema Generar el Curso Multimedia................ 81 Fig. 32 Interfaz del Caso de Uso Generar Esquema................................................................. 86 Fig. 34 Diagrama de Secuencia Generar Esquema.............................................................................. 94
Fig. 35 Diagrama de Clases Subsistema Generar Estructura y Test de Evaluación............................. 97 Fig. 36 Diagrama de Clases Subsistema Administrar Contenido........................................... 98 Fig. 37 Diagrama de Clases Subsistema Generar Curso Multimedia..................................... 99 Fig. 38 Diagrama de Clases Subsistema Administrar Aspectos Técnicos........................................... 100 Fig. 38 Pantalla Entrar al Sistema SGCM............................................................................... 126 Fig. 39 Pantalla Generar Esquema SGCM............................................................................. 129 Fig. 40 Pantalla Adjuntar Archivo SGCM.............................................................................. 129 Fig. 41 Pantalla Test Desarrollo SGCM................................................................................. 132 Fig. 42 Pantalla Test Selección SGCM................................................................................... 132 Fig. 43 Pantalla Ver Archivos con Observaciones SGCM..................................................... 133 Fig. 44 Documentación del Caso de Uso Mostrar Visor Configuración................................ 135 Fig. 45 Pantalla Añadir Archivo............................................................................................. 135 Fig. 46 Pantalla Mantenimiento Claves del Sistema SGCM.................................................. 136 Fig. 47 Pantalla Modificar Estructura del Directorio SGCM................................................. 137 Fig. 48 Pantalla Visor Contenido SGCM............................................................................... 139 Fig. 49 Pantalla Ingreso Clave Curso Multimedia.................................................................. 141 Fig. 50 Pantalla Visor CD Multimedia................................................................................... 141 Fig. 51 Pantalla Iniciar Curso Multimedia.............................................................................. 142 Fig. 52 Pantalla Presentación Curso Multimedia.................................................................... 144 Fig. 53 Pantalla Mostrar Contenido Curso Multimedia.......................................................... 144 Fig. 54 Pantalla Mostrar Videos Curso Multimedia............................................................... 145 Fig. 55 Pantalla Test Selección Curso Multimedia................................................................. 147 Fig. 56 Pantalla Test Desarrollo Curso Multimedia................................................................ 147 Fig. 57 Pantalla Visor Texto................................................................................................... 150 Fig. 58 Diagrama de Colaboración del Caso de Uso Entrar Al Sistema................................ 155 Fig. 59 Diagrama de Colaboración del Caso de Uso Generar Esquema................................ 156 Fig. 60 Diagrama de Colaboración del Caso de Uso Adjuntar Archivo................................ 157 Fig. 61 Diagrama de Colaboración del Caso de Uso Elaborar Test....................................... 158 Fig. 62 Diagrama de Colaboración del Caso de Uso Ver Archivos con Observaciones....... 159 Fig. 63 Diagrama de Colaboración del Caso de Uso Mostrar Visor Configuración.............. 160 Fig. 64 Diagrama de Colaboración del Caso de Uso Administrar Claves............................. 161 Fig. 65 Diagrama de Colaboración del Caso de Uso Modificar Estructura del Directorio.... 162 Fig. 66 Diagrama de Colaboración del Caso de Uso Ver Visor Contenido........................... 163 Fig. 67 Diagrama de Colaboración del Caso de Uso Entrar al Curso.................................... 164 Fig. 68 Diagrama de Colaboración del Caso de Uso Mostrar Visor CD Multimedia............ 165 Fig. 69 Diagrama de Colaboración de los Casos de Uso Iniciar Curso Multimedia, Esquema del Módulo..........................................................................................
166
Fig. 70 Diagrama de Colaboración del Caso de Uso Ver Visor Contenido........................... 167 Fig. 71 Diagrama de Colaboración de los Casos de Uso Mostrar Test Evaluación, Mostrar Examen, Iniciar Corrección, Mostrar Resultado.......................................................
168
Fig. 72 Diagrama de Secuencia del Caso de Uso Entrar al Sistema...................................... 175 Fig. 73 Diagrama de Secuencia del Caso de Uso Generar Esquema..................................... 176 Fig. 74 Diagrama de Secuencia del Caso de Uso Adjuntar Archivo..................................... 177 Fig. 75 Diagrama de Secuencia del Caso de Uso Elaborar Test............................................ 178 Fig. 76 Diagrama de Secuencia del Caso de Uso Ver Archivos con Observaciones............. 179 Fig. 77 Diagrama de Secuencia del Caso de Uso Mostrar Visor Configuración................... 180
Fig. 78 Diagrama de Secuencia del Caso de Uso Administrar Claves.................................. 181 Fig. 79 Diagrama de Secuencia del Caso de Uso Mostrar Directorio................................... 182 Fig. 80 Diagrama de Secuencia del Caso de Uso Ver Visor Contenido................................ 183 Fig. 81 Diagrama de Secuencia del Caso de Uso Mostrar Esquema Modulo........................ 184 Fig. 82 Diagrama de Secuencia de los Casos de Uso Mostrar Contenido, Mostrar Videos, Buscar Archivos Asociados, Imprimir Página.............................................
185
Fig. 83 Diagrama de Secuencia de los Casos de Uso Mostrar Test de Evaluación, Mostrar Exámen, Iniciar Corrección, Mostrar Resultado.......................................................
186
Fig. 84 Diagrama de Secuencia del Caso de Uso Entrar Al Curso........................................ 187 Fig. 85 Diagrama de Secuencia del Caso de Uso Mostrar Visor CD Multimedia................. 188 Fig. 86 Diagrama de Clase del Caso de Uso Entrar al Curso................................................. 190 Fig. 87 Diagrama de Clase del Caso de Uso Generar Esquema............................................ 191 Fig. 88 Diagrama de Clase del Caso de Uso Adjuntar Archivo............................................. 191 Fig. 89 Diagrama de Clase del Caso de Uso Elaborar Test................................................... 192 Fig. 90 Diagrama de Clase del Caso de Uso Ver Archivos con Observaciones.................... 192 Fig. 91 Diagrama de Clase del Caso de Uso Mostrar Visor Configuración.......................... 193 Fig. 92 Diagrama de Clase del Caso de Uso Administrar Claves.......................................... 193 Fig. 93 Diagrama de Clase del Caso de Uso Mostrar Estructura Directorio......................... 194 Fig. 94 Diagrama de Clase del Caso de Uso Ver Visor Contenido........................................ 194 Fig. 95 Diagrama de Clase del Caso de Uso Ver Entrar Al Curso......................................... 195 Fig. 96 Diagrama de Clase del Caso de Uso Mostrar Visor CD Multimedia......................... 196 Fig. 97 Diagrama de Clase de los Casos de Uso Iniciar Curso Multimedia, Esquema del Módulo...............................................................................................................
196
Fig. 98 Diagrama de Clase del Caso de Uso Ver Visor Contenido........................................ 197 Fig. 99 Diagrama de Clase de los Casos de Uso Mostrar Test de Evaluación, Mostrar Exámen, Iniciar Corrección, Mostrar Resultado.......................................................
197
INDICE DE TABLAS pp Tabla 1 Lista de Actores........................................................................................................ 73 Tabla 2 Lista de Casos de Uso............................................................................................... 74 Tabla 2 Lista de Casos de Uso (Continuación)....................................................................... 75 Tabla 3 Formato para documentar Casos de Uso, donde los aspectos a describirse corresponden a un subconjunto de los sugeridos por el RUP..............
76
Tabla 4. Caso de Uso Generar Esquema................................................................................. 77 Tabla 5 Clases de Análisis identificadas Caso de Uso Generar Esquema.............................. 85 Tabla 6 Consideraciones en la construcción y/o modificación de las Interfaces de Usuario.........................................................................................................
87
Tabla 7 Clases de Diseño del Caso de Uso Generar Esquema............................................... 91 Tabla 8 Componentes de desarrollo........................................................................................ 114 Tabla 9 Valoración de los aspectos considerados por el Instrumento PIECES...................... 118 Tabla 10 Documentación del Caso de Uso Entrar al Sistema................................................ 126 Tabla 11 Documentación del Caso de Uso Generar Esquema................................................ 127 Tabla 12 Documentación del Caso de Uso Adjuntar Archivos.............................................. 128 Tabla 13 Documentación del Caso de Uso Elaborar Test...................................................... 131 Tabla 14 Documentación del Caso de Uso Añadir Archivo................................................... 131 Tabla 15 Documentación del Caso de Uso Ver Archivos con Observaciones....................... 133 Tabla 16 Documentación del Caso de Uso Mostrar Visor Configuración.............................. 134 Tabla 17 Documentación del Caso de Uso Administrar Claves............................................. 136 Tabla 18 Documentación del Caso de Uso Modificar Estructura del Directorio.................... 137 Tabla 19 Documentación del Caso de Uso Ver Visor Contenido........................................... 138 Tabla 20 Documentación del Caso de Uso Entrar al Curso................................................... 140 Tabla 21 Documentación del Caso de Uso Mostrar Visor CD Multimedia............................ 140 Tabla 22 Documentación del Caso de Uso Iniciar Curso Multimedia................................... 142 Tabla 23 Documentación del Caso de Uso Mostrar Esquema del Módulo............................ 143 Tabla 24 Documentación del Caso de Uso Mostrar Contenido Informativo.......................... 143 Tabla 25 Documentación del Caso de Uso Mostrar Videos................................................... 145 Tabla 26 Documentación del Caso de uso Buscar Archivos Asociados................................. 146 Tabla 27 Documentación del Caso de uso Mostrar Test de Evaluación................................ 146 Tabla 28 Documentación del Caso de Uso Mostrar Examen................................................. 146 Tabla 29 Documentación del Caso de Uso Iniciar Corrección.............................................. 148 Tabla 30 Documentación del Caso de Uso Mostrar Resultado.............................................. 148 Tabla 31 Documentación del Caso de uso Imprimir Página.................................................. 149 Tabla 32 Documentación del Caso de uso Mostrar Ayuda..................................................... 149 Tabla 33 Documentación del Caso de uso Buscar Ayuda....................................................... 150 Tabla 34 Clases de Análisis identificadas............................................................................... 153 Tabla 35 Clases de Diseño Identificadas................................................................................. 170
INTRODUCCIÓN
Los continuos avances en tecnología de computadoras y comunicaciones tienen un efecto profundo sobre
la forma en que las personas trabajan. El uso cada vez más extenso de sistemas de información está cambiando la
naturaleza propia de la sociedad que hace uso de ellos, aunado con las ventajas que ofrecen las Redes y
específicamente los servicios de Internet como el protocolo FTP que permite la transferencia de información entre
las computadoras.
El desarrollo de sistemas de información se encuentra sumido en una nueva etapa de
transformación y evolución hacia nuevos esquemas de trabajo, las empresas han encontrado la
necesidad de utilizar las Redes como vehículo de intercambio de fuente de datos, disponiendo
de dispositivos cada vez más sofisticados para desplazar datos, con accesos rápido, sencillo, y
mayor grado de interacción, convirtiéndose en el principal entorno de trabajo para el desarrollo
de sistemas que gestionan información.
La tecnología es el lenguaje del nuevo milenio, la tecnología multimedia ha logrado un
gran impacto en nuestras vidas, ofreciendo una interfaz entre el hombre y la máquina,
mezclando diferentes medios (vídeo, música, audio, texto), mejorando la retención de la
información y el entendimiento. Los computadores permiten cosas interesantes desde el punto
de vista de la enseñanza: no se cansan nunca; mantienen un cuerpo de conocimientos que se
puede transmitir. Estos medios permiten organizar la información de maneras muy diferentes a
las convencionales (libros), y en algunas ocasiones, de manera muy superior a como puede
hacerlo un profesor. Permiten, además, individualizar la formación. Las personas pueden
aprender aspectos específicos que quieren aprender, y ampliar la información de manera fácil,
algo que en las clases presenciales resulta más difícil.
El tema del aprendizaje a través de medios virtuales es muy amplio, el aprendizaje
virtual es un tipo de aprendizaje que en lugar de interacción entre personas (profesores y
alumnos) propone un tipo de interacción en la que en medio está un sistema. En esta clase de
aprendizaje, muchas veces a distancia, se produce una mediación profesor-alumno y no hay
encuentro físico. Por tanto, la manera de aprender se realiza tanto con los profesores como con
los recursos que han surgido. El Material instruccional Electrónico puede estar almacenado en
un CD-ROM, DVD u otro medio.
Bajo esta concepción, la Universidad Nacional Abierta está incorporando nuevas
tecnologías de la información y la comunicación, que cumplan un papel de mediación en el
proceso de enseñanza, en esta línea de acción se concibió esta investigación que consistió en
desarrollar un sistema para dar soporte en la generación del contenido de un Curso aplicando
recursos Multimedia, caso de estudio Curso Introductorio.
El desarrollo del presente Trabajo de Grado, se expone mediante la siguiente estructura:
En el Capítulo I, Marco Teórico, se exponen las definiciones y términos relacionados
con la metodología seleccionada y el área de conocimiento correspondiente. Estructurado en
tres aspectos:
Educación Abierta y a distancia, Sistemas Multimedia, Redes aplicando tecnología de
Internet.
Estudios de Usabilidad de Jacob Nielsen.
Proceso de Desarrollo Unificado Rational (RUP) para el desarrollo de sistemas de software
Orientados a Objetos, así como conceptos acerca de la Metodología de sistemas para
enfrentar problemas no estructurados o de sistemas “suaves”.
En el Capítulo II, Definición del Trabajo de Grado, se presenta la solución propuesta para el
problema (abarca los objetivos y alcances perseguidos) y el planteamiento de la problemática
identificada.
En el Capítulo III, Metodología y Resultados, se describe la estrategia metodológica, que
representa el marco de guía para el desarrollo del proyecto, basada en el Proceso Unificado
Rational (RUP), y compuesta de las siguientes disciplinas: Conceptualizar el Sistema,
Requerimientos, Análisis y Diseño, Implementación, Prueba y Documentación.
En el Capítulo IV, se incluyen las conclusiones y recomendaciones en el desarrollo del
presente proyecto.
CAPÍTULO I
MARCO TEÓRICO
El Marco Teórico orienta el desarrollo de toda labor investigativa, se concibe como el
pilar fundamental del trabajo, describe los elementos teóricos de uno o varios autores
permitiendo al investigador fundamentar su proceso de conocimiento.
En este capitulo se exponen las bases teóricas que sustentan todo el desarrollo del
proyecto, divididos en tres (3) tópicos: en primer lugar con el área de aplicación: recursos
multimedia, la educación a distancia y las Redes Locales aplicando tecnología de Internet, en
segundo lugar se hace referencia a los aspectos relacionados con la usabilidad utilizados en este
trabajo y en tercer lugar tecnología de Objetos aplicados en el marco metodológico.
I.1 RECURSOS MULTIMEDIOS, LA EDUCACIÓN A DISTANCIA Y LAS REDES
LOCALES EMPLEANDO TECNOLOGÍA DE INTERNET.
Podemos comenzar extrayendo del glosario de términos publicado en Internet por la Universidad Autónoma de
México, la definición de Educación a Distancia, ésta es:
Modalidad del sistema educativo que permite el logro de objetivos de aprendizaje mediante una relación no presencial, cualitativamente distinta a la del sistema convencional y con una combinación de medios diversos que facilitan el desarrollo del proceso de aprendizaje para las personas que no pueden estar sujetas a condiciones rígidas de calendario, espacio y tiempo [UNAM; 1998].
De la misma manera definen a la Educación Abierta como:
La modalidad del sistema educativo formal que se apoya en los principios de la enseñanza individualizada a la cual tienen acceso aquellas personas que, debido a limitaciones de tiempo, no han podido asistir a una escuela tradicional, entendiendo. por Enseñanza Individualizada aquella en la que el estudiante avanza a su propio ritmo, de acuerdo con sus capacidades y limitaciones[UNAM; 1998].
La educación a distancia, nace por la necesidad de ampliar la cobertura a sectores no
atendidos de nuestra población, rompiendo los esquemas tradicionales de Tiempo y Espacio al
eliminar la obligatoriedad de presencialidad en sitio y hora de nuestra educación tradicional.
Según Peters [1989], citado por Ortiz [1996],: “La educación a distancia es un método de
impartir conocimiento a un gran número de estudiantes al mismo tiempo y en los lugares donde
ellos habitan”.
El aprendizaje, que pasa a ser el centro del hecho educativo, se da a través de la
actividad del estudiante, quien asume la responsabilidad en su progreso. La UNESCO llamó
Reducción Copérnico a la transferencia de gravedad de la mentalidad centrada en el maestro
hacia la mentalidad centrada en quien aprende, y su responsabilidad y decisión incluye aspectos
como los mencionados por Salinas y Sureda [1999], citados por Delgado [2001],: “Cómo
aprendo (métodos, medios)? ; Dónde aprendo (lugar de estudio)? ; Cuándo aprendo (en qué
momento)? ”.
La educación a distancia depende de la posibilidad de superar la distancia como bien lo
establecen Garrison y Shale, citadas por Ortiz [1996]:
La característica más importante de la educación a distancia no es su morfología, sino la forma en que la comunicación entre docente y estudiante es facilitada. Como el docente y el estudiante están separados por la distancia, este tipo de educación debe depender de la tecnología como mediador en el proceso de comunicación.
El plan intencionado de enseñanza destinado a facilitar el aprendizaje humano, o en la
forma que lo define el diccionario de las Ciencias de la Educación de Santillana [1983], el
currículum como “El conjunto de estudios y prácticas destinadas a que el alumno desarrolle
plenamente sus posibilidades”.
Entenderemos por Tecnología, al unísono con Ignacio Avalos [1994], “Un método,
basado en alguna forma de conocimiento y empleado de manera repetitiva con el propósito de
producir un bien o, en nuestro caso, prestar un servicio”. La capacidad tecnológica, pensamos,
es un requisito necesario, aunque no suficiente, para lograr los objetivos de las organizaciones,
que no excluyen, por supuesto, las educativas.
Como dice Nicholas Negroponte [1995], el director de Multimedios del MIT, en su best
seller titulado Ser Digital: “Enfrentamos la disyuntiva de ser digitales o no ser”. La sociedad
virtual es un hecho, está en gestación en el mundo entero. Por otro lado, nada menos que Bill
Gates [1995] afirma en su libro Camino al Futuro: “El futuro de los profesores pivoteará
sobre la Tecnología”.
Según José Luis Rodríguez Illera, director del Máster de Multimedia educativo, de la
Universidad de Barcelona: el aprendizaje virtual es un tipo de aprendizaje que en lugar de
interacción entre personas (profesores y alumnos) propone un tipo de interacción en la que en
medio está un sistema. En esta clase de aprendizaje, muchas veces a distancia, se produce una
mediación entre profesor y alumno y no hay encuentro físico. Por tanto, la manera de aprender
se realiza tanto con los profesores como con los recursos que han surgido. El tema del
aprendizaje a través de medios virtuales es muy amplio y, desde mi punto de vista, está mal
definido. Esta indefinición puede estar relacionada con los rapidísimos cambios que
experimenta la sociedad contemporánea. Antes los cambios eran mucho más lentos, pero ahora
hablar de aprendizaje a través de las tecnologías es algo que tiene cierto grado de inseguridad,
porque lo que vemos hoy es diferente a lo que veíamos hace unos años, y no estamos seguros
de que será igual dentro de 20 o 30 años.
Hasta hace unos pocos años, un escritor consideraba el libro como el destino lógico y
único de su trabajo. Ahora, el libro convencional ha perdido esa exclusividad: hay otros
formatos, soportes y medios de difusión. La aparición de los libros electrónicos provocarán un
cambio profundo no sólo en el negocio editorial sino en las costumbres de lectura y en la
producción literaria. Habrán de desaparecer muchos intermediarios y los más beneficiados
serán los lectores y los autores (Marcela Cejas directora de e-libro.net).
Con el tiempo los libros electrónicos desplazarán a los libros tradicionales, como los mensajes de correo
han desplazado a las cartas tradicionales. Según un estudio de Júpiter Research, en el mercado norteamericano se
han vendido unos 100.000 dispositivos de lectura electrónica. La empresa asegura que en el 2005, cuando los
precios sean inferiores y la calidad mejore, existirá 1,9 millones de usuarios de libros electrónicos (Universal.com,
Miercoles 22 de Mayo del 2002).
NODO: Elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que
generalmente tiene alguna memoria y a menudo, capacidad de procesamiento [Booch, Jacobson, Rumbaugh;
2002].
RED: Dos o más computadoras conectadas entre sí, lo cual las capacitan para el
intercambio de información y de recursos a voluntad de los usuarios del sistema. Ejemplo: En
un laboratorio o aula de computación, la maestra puede interactuar con sus alumnos, así como,
seguir sus logros en una determinada actividad de aprendizaje [Proyecto SISE; Ministerio de
Educación].
RED LOCAL (LOCAL AREA NETWORK): Sistema de comunicación establecido para
unir las computadoras de un área limitada de una determinada empresa o institución. Ejemplo:
Un funcionario convoca a todos los jefes de programas del edificio sede del Ministerio de
Educación, a una reunión urgente a celebrarse ese mismo día, dicha convocatoria la hace llegar
desde su computadora a todas las computadoras de las distintas dependencias, a través del
correo interno de su red local [Proyecto SISE; Ministerio de Educación].
RED EXTENSA (WIDE AREA NETWORK): Unión de todas las redes locales de una
determinada empresa o institución. Ejemplo: Desde el Edificio Sede del Ministerio de
Educación, se envía a través de la red que une a las Autoridades Educativas de los
diferentes estados, las planillas y lineamientos para la recolección de la estadística del venidero
año escolar. Una vez recolectada la información, retorna, por el mismo medio, a la sede del
M.E [Proyecto SISE; Ministerio de Educación].
PROTOCOLOS: son un conjunto de reglas para el intercambio de datos que permiten a
los usuarios comunicarse entre diferentes redes [Cybesrcursos.net].
TCP/IP: es un conjunto de protocolos diseñados para las redes de Area Amplia (WAN).
INTERNET: es una red de redes. Actualmente conecta miles de redes para permitir
compartir información y recursos a nivel mundial. Las comunicaciones en Internet son posibles
entre redes de diferentes ambientes y plataformas. Este intercambio dinámico de datos se ha
logrado debido al desarrollo de los protocolos de comunicación [Cybesrcursos.net].
HOST: computadoras cliente/servidor. En ellos es donde los usuarios ven la interacción
con la Internet. Cada computadora que se conecta directamente a una red es un host. Todos los
hosts tienen una dirección de red única. Esta es un comúnmente conocida como la dirección IP.
File Transfer Protocol (FTP): protocolo básico de comunicación en Internet, permite a
los usuarios mover archivos entre hosts de Internet. Algunos hosts de Internet están dedicados
exclusivamente a este servicio y son conocidos como FTP sites [Cybesrcursos.net].
SERVIDOR WEB: almacena y administra las páginas Web. También recibe las
solicitudes de los clientes, las procesa y las contesta, ejemplo el Internet Information Server
[Cybesrcursos.net].
WEB BROWSER: Un browser es una aplicación cliente que permite la comunicación de una
computadora con el servidor Web u otros servidores de Internet, ejemplo el Internet Explorer o el Netscape
Navigator [Cybesrcursos.net].
I.2 PRINCIPIOS Y LINEAMIENTOS DE USABILIDAD DE INTERFACES realizados
por Jacob Nielsen.
I.2.1 PRINCIPIOS Y LINEAMIENTOS EN EL DISEÑO
Los colores, la organización de la información y una buena definición de la estructura
forman parte importante de un buen diseño. En esta sección se explicarán los principios y
lineamientos generales de diseño con respecto al fondo, imágenes, iconos, y texto.
En cuanto a Fondo:
Se debe evitar el uso de imágenes con figuras o relieves muy resaltados en el fondo de la
página, ya que por lo general hacen difícil la lectura del texto. El fondo no debe entorpecer la
lectura y la cantidad de colores utilizados debe ser solo la necesaria para no sobrecargar la
página.
En cuanto a imágenes:
No se deben incluir elementos que se muevan incesantemente. Las imágenes en
movimiento (animaciones) suelen tener un efecto molesto en la visión periférica humana. Al
incluir animaciones se debe permitir al usuario la opción para deshabilitarlas, o limitarlas a un
período corto de duración.
En cuanto a Texto:
Cuando una página está conformada principalmente por texto, es conveniente el uso de
encabezados y listas para dar al usuario una mayor orientación, sin resaltar exageradamente lo
que está dentro del encabezado.
I.2.2 PRINCIPIO Y LINEAMIENTOS REFERENTES A LA NAVEGABILIDAD O
INTERACCIÓN CON EL SISTEMA.
El desarrollador debe considerar algunos aspectos importantes que le permitan ofrecer
un buen esquema. Un conjunto de estos aspectos se muestra a continuación.
Los títulos de las páginas son importantes como soporte para la navegación, ya que
generalmente son usados para referirse a ellas en los diferentes mecanismos de búsqueda, al
comienzo del título debe evitarse el uso de palabras como: El, La, Y, Una, Un, ya que algunos
resultados se listan por orden alfabético. Como guía, un título debe tener entre 4 y 10 palabras.
La estructura completa debe ser fácil de entender para el usuario, de manera que pueda
formar una imagen mental de los tópicos cubiertos. Esto facilita y agiliza al usuario la
navegación.
Se deben colocar puntos de interacción, para que los usuarios puedan hacer llegar sus
opiniones, esto ayuda a corregir errores y colocar servicios no previstos anteriormente.
I.2.3 ACERCA DE LA USABILIDAD DE SISTEMAS.
La usabilidad es una cualidad del software que posee los siguientes atributos:
Eficiencia: proveer al usuario maneras rápidas y bien explícitas para la búsqueda de
información, permitiendo que el usuario consiga la información deseada lo más eficientemente
posible.
Memorización: fácil de recordar, para ahorrarle al usuario el proceso de familiarización
y la búsqueda de información.
La Usabilidad es medida en relación a ciertos usuarios y ciertas tareas, es decir,
típicamente es medida con un número de usuarios de prueba y un conjunto de tareas
específicas. Un test de usabilidad investiga a los usuarios, las tareas y los ambientes, para
evaluar el rendimiento del producto con respecto a los atributos que caracterizan el software
usable. Para garantizar la usabilidad de un sistema es recomendable la realización de pruebas a
los usuarios desde las etapas iniciales del proceso de construcción de software.
A continuación se presenta un conjunto de principios que se deben tener presentes con el fin de
obtener la mayor usabilidad posible, aunque ésta sólo puede ser medible, como se mencionó
anteriormente, por medio de pruebas realizadas preferiblemente con los usuarios finales.
Con estudios realizados por el equipo de trabajo de Jacob Nielsen, se ha llegado a la
conclusión que aproximadamente sólo el 10% de los usuarios usan las barras de
desplazamiento para ver la información que está mas allá de la pantalla (aunque esta cifra va en
aumento según estudios recientes de usabilidad).
Evitar la sobrecarga de muchas imágenes y elementos que retarden el tiempo de
despliegue de la pantalla. Las imágenes no se deben usar sin ningún sentido ya que pueden
distraer la atención del usuario, las imágenes deben ser usadas cuando son un mejor camino
para transmitir algún tipo de información, representación.
I.3 MÉTODOS Y PROCEDIMIENTOS APLICADOS AL MARCO METODOLÓGICO.
A continuación se expondrán los conceptos relacionados con el proceso de desarrollo de
sistemas de información orientado a objeto, propuestos en su mayoría por los autores: Jacobson,
Booch, Rumbaugh y Kruchten (2002).
I.3.1 OBJETO
Un Objeto representa una entidad inventada o del mundo real. Es un concepto, “una
abstracción o algo que dispone de unos límites bien definidos y tiene una significación para el
sistema que se pretende modelar” (Odell, 1986).
Un objeto es un elemento o concepto del mundo real el cual puede ser distintivamente
identificado. El mundo en que vivimos está constituido por objetos materiales de todo tipo. Su
tamaño es muy variable: algunos son pequeños, como los granos de arena, y otros muy grandes,
como las estrellas. Nuestra percepción intuitiva de lo que constituye un objeto se basa en el
concepto de masa, es decir, en una dimensión que caracteriza la cantidad de materia de un
cuerpo.
El objeto es una unidad atómica formada por la unión de un estado y de un
comportamiento. De forma intuitiva un objeto se puede definir como una entidad que posee
atributos propios que lo caracterizan y su comportamiento está determinado por un grupo de
acciones asociadas a ellos que pueden modificarlos, así como también por acciones que esta
requiera de otros objetos.
Por extensión, es perfectamente posible definir otros objetos sin masa, como las cuentas
bancarias, las pólizas de seguros o bien las ecuaciones matemáticas. Estos objetos
corresponden entonces a conceptos en lugar de a entidades físicas. Siempre por extensión, los
objetos pueden pertenecer también a mundos virtuales, por ejemplo, en asociación con Internet,
para crear comunidades de personas que no están situadas en el mismo punto geográfico.
Los objetos informáticos definen una representación abstracta de las entidades de un
mundo real o virtual, con el objetivo de controlarlos o simularlos. Esta representación abstracta
puede ser vista como una especie de espejo informático, que devuelve una imagen simplificada
de un objeto que existe en el mundo percibido por el usuario. La noción de objeto juega el papel
fundamental en el Enfoque Orientado a Objetos, debido a que los sistemas van a ser detallados
de la misma forma que el problema del mundo real que se quiere resolver. En el contexto
computacional se vislumbra como: una entidad que posee un estado y un conjunto de
operaciones para acceder o modificar ese estado, el cual mantiene los efectos causados por las
operaciones. Así, los objetos no sólo modelan el estado interno de las cosas del mundo real, si
no además lo manejan a través de sus operaciones.
Cualquier cosa que incorpore una estructura y un comportamiento se le puede considerar
como un objeto. Ejemplo: Un carro posee un tamaño y un color y se le puede encender o
apagar. Un objeto debe tener una identidad coherente, al que se le puede asignar un nombre
razonable y conciso. Ejemplo: Se consideran perros a todos los animales con una apariencia,
comportamiento, y forma similar.
Los objetos se definen según el contexto de la aplicación. Ejemplo: Una persona
llamada Pedro Pérez se considera un objeto para una Universidad, mientras que para un
laboratorio el corazón de Pedro Pérez es un objeto. Los objetos deben tener nombres en
singular, y no en plural. Ejemplo: Un automóvil es un objeto, automóviles son simplemente
muchos objetos y no un solo objeto. Parte de una cosa puede considerarse un objeto. Ejemplo:
La rueda, la cual es parte del automóvil, se puede considerar un objeto. Por otro lado, el lado
izquierdo del automóvil sería un mal objeto. Los objetos deben tener nombres razonables y
concisos para evitar la construcción de objetos que no tengan una identidad coherente.
I.3.1.1- CARACTERÍSTICAS DE UN OBJETO.
Un atributo de una clase “representa un pedazo de información sobre un objeto de la
clase que se guarda con el objeto” (Odell, 1986). Un atributo tiene un tipo. Cada atributo y tipo,
respectivamente, tienen un nombre.
Identidad: Permite distinguir los objetos de forma no ambigua e independiente de su
estado. En otras palabras: dos objetos serán distintos aun cuando los valores de todos sus
atributos (tales como el nombre y el tamaño) sean idénticos.
Comportamiento: Describe las acciones y reacciones de un objeto. Es como actúa y
reacciona un objeto, en términos de sus cambios de estado y paso de mensajes.
El comportamiento de un objeto esta determinado por las operaciones que pueden ser
reconocidas por él. Dichas operaciones son los denominados métodos. Ellos constituyen la
descripción de la manipulación de los objetos, es decir, “un método constituye la
implementación de una operación para una clase” (Odell, 1986).
Estructura y función:
• Identidad ¿Quien soy? = Atributos
• Propósito ¿Cual es mi misión? = Justificación
• Responsabilidades ¿Qué debo hacer? = Métodos
• Procedencia ¿De qué Clase provengo? = Origen
• Relaciones ¿Qué mensajes entiendo? = Comportamiento
I.3.1.2 MENSAJE
La unidad de comunicación entre objetos se llama mensaje. El mensaje es el soporte de
una relación de comunicación que vincula, de forma dinámica, los objetos que han sido
separados por el proceso de descomposición. Él es quien asegura la delegación de las tareas y
garantiza el respeto de las restricciones. Cuando un objeto recibe un mensaje (receptor del
mensaje), en principio realiza una búsqueda dentro de una tabla que contiene los nombres de los
métodos que soporta la clase, seleccionando la implementación que corresponda al coincidir el
selector de mensaje con los nombres que aparecen en la tabla.
Las características fundamentales de los mensajes radican en que el selector es sólo un
nombre de la acción deseada que describe lo que el usuario desea que suceda, no como deba
suceder. Debido a que posee enlace dinámico, el mensaje puede ser interpretado de diferentes
maneras por diferentes receptores. Junto con el selector, un mensaje puede contener otros
objetos que forman parte de la manipulación (argumento del mensaje) que pueden ser
opcionales. La existencia de argumentos se debe a la necesidad de indicar toda la información
relevante que se requiera, ya que el envío del mensaje es la única forma de comunicación entre
el ambiente y los objetos, y/o entre los mismos.
Otro aspecto importante con relación a los mensajes es que la respuesta que da un objeto
al requerimiento solicitado puede ser cambiar o consultar su estado, enviar un mensaje a otro
objeto, crear otro objeto, o combinación de ellas.
I.3.2 CLASES
Desde una perspectiva física, una Clase “es una pieza de un sistema de información que
actúa como un molde para fabricar tipos particulares de objetos que disponen de los mismos
atributos y métodos” (Odell, 1986). Ejemplo: La clase es como un molde de una cerámica de la
cual se pueden crear múltiples cerámicas, todas con exactamente las mismas características.
Para modificar las cerámicas hay que primero construir un nuevo molde. Al definir múltiples
objetos en clases se logra una abstracción del problema. Se generaliza de los casos específicos
definiciones comunes, como nombres de la clase, atributos, y operaciones (explicadas más
adelante).
Una clase es una implantación de un tipo de objeto. Especifica una estructura de datos y
los métodos operativos permisibles que se aplican a cada uno de sus objetos. Una clase de
objetos describe un grupo de objetos con propiedades (atributos) y comportamientos similares,
con relaciones comunes con otros y con una semántica común. Persona, compañía, animal,
proceso y ventana son todos ellos clases de objetos. Una clase puede entenderse como un patrón
que describe la estructura y comportamiento uniforme que son comunes a todos sus objetos.
La clase permite la creación de objetos y puede interpretarse análogamente como la
definición de un tipo, así una clase surge como el producto de una abstracción conceptual entre
distintos objetos. Ejemplo: Al estudiar las motos, tenemos que existen varios tipos: de paseo,
deportivas, de trabajo, etc. que se consideran miembros de la clase moto, donde todas las
motos tienen una marca y un color. CANTV y Microsoft pertenecen a la clase compañía, donde
todas las compañías tienen una dirección, un número de empleados, y una ganancia al año.
Fig. 1 Representación de la Clase en UML.
En donde: <Nombre Clase>: Contiene el nombre de la clase
<Atributos>: Contiene los atributos (o variables de instancia) que caracterizan a la clase
(pueden ser privado, protegido o publico)
<Operaciones o Métodos>: Contiene los métodos, los cuales son la forma como interactúa el
objeto con su entorno (dependiendo de la visibilidad privado, protegido o publico)
I.3.2.1 ATRIBUTO
Son las características que comparten los objetos definidos en una clase. Cada atributo
tiene un valor por cada instancia del objeto. Las instancias distintas de un cierto objeto pueden
tener el mismo valor o valores distintos para un atributo dado. El nombre del atributo es único
dentro de la clase. Color, peso y año del modelo son atributos de los objetos del tipo
Automóvil.
La Figura Nº 2 muestra una notación para el modelado de objetos. La clase Persona
tiene como atributos nombre y edad. Nombre es una cadena y edad es un entero. Un objeto de
la clase Persona tiene el valor Juan García como nombre y el valor 24 como edad. Otro objeto
tiene el nombre María Pérez y la edad 52.
Persona
Nombre: cadena
Edad: Entero
Clases con sus atributos Objetos con sus valores Fig. 2 Clases y Objetos (Martin/Odell,1994).
Los atributos de una clase pueden ser de tres tipos, los que definen el grado de
comunicación 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 solo será accesible desde dentro de la clase (solo sus métodos
lo pueden acceder)
Protected (#): Indica que el atributo no será accesible desde fuera de la clase
I.3.2.2 OPERACIÓN
Una operación es una función o transformación que se puede aplicar o que puede ser
aplicada por los objetos de una clase. Todos los objetos de una clase comparten las mismas
operaciones. Abrir, cerrar, ocultar y mostrar son operaciones de la clase Ventana.
Una misma operación puede aplicarse a muchas clases distintas. Tal operación será
polimórfica; esto es una misma operación adopta distintas formas en distintas clases. En la
Figura 3 la clase Automóvil tiene los atributos Marca y color y las operaciones encender y
apagar. Marca, color, encender y apagar son características (Característica es una palabra
genérica tanto para un atributo como para operación) de Automóvil.
(Automóvil) Juan García 24
(Automóvil) María Pérez 52
Persona
Nombre
edad
Cambiar de trabajo
Cambiar de direcció
Fig. 3 Operaciones en una clase(Martin/Odell,1994).
I.3.2.3 MÉTODO
Como ya se ha mencionado el comportamiento de un objeto esta determinado por las
operaciones que pueden ser reconocidas por él. Dichas operaciones son los denominados
métodos. Ellos constituyen la descripción de la manipulación de los objetos, es decir, un
método constituye la implementación de una operación para una clase. Por ejemplo, La
operación Imprimir de la clase Archivo se puede implementar con diferentes métodos. Un
método Imprimir contiene el argumento dispositivo el cual manda el archivo a la impresora
correspondiente. Otro método Imprimir, con exactamente el mismo nombre, pero sin
argumentos, mandaría a la pantalla, en lugar de la impresora.
Los métodos de una clase son la forma en como ésta interactúa con su entorno, éstos
pueden tener las características:
Public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es
accesible desde todos lados
Private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros
métodos de la clase lo pueden acceder)
Protected (#): Indica que el método no será accesible desde fuera de la clase.
I.3.3 EL ENFOQUE ORIENTADO A OBJETO PARA EL DESARROLLO DE
SISTEMAS.
I.3.3.1 ANALISIS ORIENTADO A OBJETO.
El Análisis Orientado a Objeto es un método que examina los requerimientos desde las
perspectivas de las clases y objetos, básicamente, los productos del análisis orientado a objeto
sirven como modelos de los que se puede partir para un Diseño Orientado a Objetos. Los
productos del Diseño Orientado a Objeto pueden utilizarse entonces como anteproyectos para la
implementación completa de un sistema utilizando métodos de Programación Orientada a
Objeto.
I.3.3.2 DISEÑO ORIENTADO A OBJETO
Los métodos de diseño enfatizan la estructuración correcta y efectiva de un sistema
complejo. El Diseño Orientado a Objeto es un método que abarca el proceso de
Descomposición Orientada a Objeto utilizando diversas notaciones para expresar los diferentes
modelos. El soporte para la Descomposición Orientada a Objeto es lo que hace el Diseño
Orientado a Objetos diferente al diseño estructurado.
El Diseño Orientado a Objetos se basa en la Programación Orientada a Objetos, donde
el bloque físico de construcción es el módulo, que representa una colección lógica de clases y
objetos. El modelado de objeto ha demostrado ser un concepto unificador en la informática,
aplicable no solo a los lenguajes de programación, sino también al diseño de interfaces de
usuario, bases de datos e incluso arquitectura de computadoras[Booch; 1994].
I.3.4. EL MODELO DE OBJETOS
El Modelo de Objetos, promueve la creación de desarrollos de aplicación reutilizables,
produce sistemas que son flexibles al cambio y evolucionan con el tiempo [Booch; 1994].
El Modelado de Objetos presenta cuatro elementos fundamentales, al decir
fundamentales, quiere decir que en un modelo que carezca de cualquiera de estos elementos no
es Orientado a Objeto [Booch; 1994].
Abstracción.
Encapsulamiento
Modularidad
Jerarquía
Hay tres elementos secundarios del modelo de objetos:
Tipos
Concurrencia
Persistencia
Por secundario quiere decirse que cada uno de ellos es una parte útil del modelo de
objetos, pero no es esencial.
I.3.4.1 ABSTRACCIÓN
Es el acto de identificar un objeto, sin detallar todas las características del mismo, solo
aquellas que están dentro del ámbito de interés y lo identifican en forma única, es decir, el
considerar sólo la generalidad de aspectos constituyentes del problema y no de sus
detalles, es lo que va permitir reconocer los objetos. Una abstracción se centra en la visión
externa de un objeto (“Que Es” y “Que Hace”) y no su composición interna (“Como lo Hace”)
[Booch; 1994].
Por ejemplo moto es un tipo de vehículo. De manera general una moto es un vehículo de
dos ruedas, con motor que sirve para trasladas uno o dos pasajeros. La forma de trasladarse se
puede describir indicando el comportamiento que se puede realizar: arrancar, acelerar, frenar y
parar.
I.3.4.2 ENCAPSULAMIENTO
Es el acto de esconder los detalles (datos y/o algoritmos) de realización de la Clase
dejando visibles solamente las interfaces. La abstracción y el encapsulamiento son conceptos
Comentario [AJ1]:
complementarios: la abstracción se centra en el comportamiento observable de un objeto,
mientras el Encapsulamiento se centra en la implementación que da lugar a este
comportamiento. Representa una herramienta para la construcción de sistemas con lo cual un
conjunto de operaciones y datos están juntos en una entidad simple, que en este contexto se
denomina objeto. La encapsulación separa el usuario externo (o consumidor) de un objeto, de
los datos y los métodos internos del mismo, restringiendo su acceso solo a través de una
interfaz operacional bien definida.
Se centra en la implementación que da lugar al comportamiento del objeto. Se consigue
mediante la ocultación de la información que no contribuye a sus características esenciales. La
estructura de un objeto y la implantación de sus métodos están ocultos[Booch; 1994].
Suponiendo el ejemplo anterior, para arrancar la moto el piloto mueve con el pie el
pedal de arranque y con la mano mueve el acelerador (interfaz). El piloto no necesita saber los
mecanismos internos que se activan al arrancar la moto (implementación).
I.3.4.3 MODULARIDAD
Es el mecanismo que permite dividir un sistema complejo, en una serie de subsistemas
de menor complejidad y fácilmente identificables. Estas divisiones, reciben el nombre de
módulos y tienen como características ser cohesivos (agrupando abstracciones que guardan
cierta relación lógica) y débilmente acoplables (minimizando las dependencias entre módulos)
[G. Booch; 1994].
Desde el punto de vista modular, la moto se puede dividir en varios subsistemas:
carburación y motor, suspensión, frenos, electricidad.
I.3.4.4 JERARQUÍA
Frecuentemente un conjunto de abstracciones forma una jerarquía y la identificación de
esas jerarquías en el diseño simplifica en gran medida la comprensión del problema. Se define
jerarquía como una clasificación u ordenación de abstracciones. Las dos jerarquías más
importantes son la jerarquía de clases o herencia (estructura de clases) y la jerarquía de objetos
(estructura de objetos) [Booch; 1994].
I.3.4.5 TIPOS
Aunque los conceptos de clase y tipo son similares, se incluyen los tipos como
elementos separados del Modelo de Objetos porque el concepto de tipo pone énfasis en el
significado de la abstracción en un sentido muy distinto. En concreto, se establece lo siguiente:
Los tipos son las puestas en vigor de la clase de los objetos, de modo que los objetos de tipos
distintos no pueden intercambiarse solo de formas muy restringidas.
I.3.4.6 CONCURRENCIA
La concurrencia se centra en la abstracción de procesos y la sincronización. El objeto es
un concepto que unifica estos dos puntos de vistas distintos: cada objeto (extraído de una
abstracción del mundo real) puede representar un hilo separado de control (una abstracción de
un proceso). Tales objetos se llaman activos. En un sistema basado en Diseño Orientado a
Objetos, se puede conceptuar el mundo como un conjunto de objetos cooperativos, algunos de
los cuales son activos y sirven como centros de actividad independiente. Partiendo de esta
concepción, se define la concurrencia como sigue: La concurrencia es la propiedad que
distingue un objeto activo de uno no activo.
I.3.4.7 PERSISTENCIA
La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo
(es decir, el objeto continúa existiendo después que su creador deja de existir) y/o el espacio
(es decir, la posición del objeto varía con respecto al espacio de direcciones en el que fue
creado).
I.3.5 RELACIONES ENTRE OBJETOS Y ENTRE CLASES.
I.3.5.1 RELACIONES ENTRE OBJETOS
Los objetos colaboran a través de sus relaciones, contribuyendo al comportamiento del
sistema. Existen dos tipos de jerarquía de objetos [Booch; 1994], enlaces y agregación:
I.3.5.1.1 ENLACE
Los objetos se vinculan por enlaces, que son instancias de las relaciones entre las clases
de los objetos considerados. Por ejemplo. Ana María estudia en la Universidad Nacional
Abierta. Matemáticamente, se define un enlace como una tupla, esto es, una lista ordenada de
instancia de objetos. Un enlace es una instancia de una asociación.
I.3.5.1.2 AGREGACIÓN
Las jerarquías parte de describe relaciones de agregación. La agregación es una
forma particular de asociación que expresa un acoplamiento más fuerte entre clases. Una de las
clases cumple una función más importante que la otra en la relación. La agregación permite
representar relaciones de tipo amo y esclavos, todo y partes o compuesto y componentes.
Si consideramos la moto como el todo; el motor, el tanque, el asiento, las ruedas, etc.
son sus partes.
Cuando se requieren componer objetos que son instancias de clases definidas por el
desarrollador de la aplicación, tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está
condicionado por el tiempo de vida del que lo incluye. Esta relación es comúnmente llamada
Composición (el Objeto base se construye a partir del objeto incluido, es decir, es
“parte/todo”).
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada
Agregación (el Objeto base utiliza al incluido para su funcionamiento).
Un ejemplo es el siguiente:
Fig. 4 Ejemplo de Agregación
En donde se destaca que:
Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee la
referencia)
Cuando se destruye el objeto Almacén también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Clientes asociados.
La Composición (por Valor) se destaca por medio de un rombo relleno.
La agregación (por Referencia) se destaca por un rombo transparente.
I.3.5.2 RELACIONES ENTRE CLASES
I.3.5.2.1 HERENCIA
La herencia es la jerarquía de clases más importante. La herencia es la recepción
(por parte de una entidad) de propiedades o características de otra dándose normalmente como
resultado de alguna especial relación entre el emisor y el receptor. Las propiedades obtenidas
por el receptor no están limitadas a aquellas que hereda, ni en general son todas las propiedades
y características heredadas. Esto es cierto, para el tipo usual de herencia que toma lugar en la
sociedad humana, en donde el emisor y el receptor de personas y las relaciones son típicamente
las encontradas en el árbol genealógico.
Almacén
Cuenta Cliente
En el Enfoque Orientado a Objeto es precisamente este concepto aplicados a clases, el
cual se define:
El proceso por medio del cual una clase adquiere propiedades y características de otra
clase ya existente. Herencia es una relación "es-una" entre las clases las más refinadas y más
generales. Herencia es útil para el modelo conceptual al igual que para la implementación.
Como modelo conceptual da buena estructuración a las clases. Como modelo de
implementación es un buen vehículo para no replicar innecesariamente el código.
Por ejemplo, al estudiar las motos, tenemos que existen varios tipos: de paseo,
deportivas, de trabajo, etc. La herencia puede ser de dos tipos: simple y múltiple. [Booch;
1994].
Herencia Simple: ocurre cuando una clase hija recibe propiedades de una clase base.
Herencia Múltiple: ocurre cuando una clase hija recibe propiedades de varias clases base.
Para representar la herencia, se utiliza un triángulo conectando a la superclase con sus
subclases. La superclase está del lado superior del vértice del triángulo, mientras que las
subclases están en la parte inferior de la base del triángulo. Los atributos y operaciones
comunes a un grupo de subclases se asocian a la superclase y son compartidos por todas las
subclases, en la Figura 5 se representa una vista antagónica de herencia.
Fig. 5 Notación en diagrama de clases para herencia (Modelado de Objetos con UML).
Superclase
Subclase
I.3.5.2.2 ASOCIACIÓN
La asociación expresa una conexión semántica bidireccional entre clases. Una
asociación es una abstracción de los enlaces que existen entre los objetos instancias de las
clases asociadas. Hay que destacar que la asociación es un concepto del mismo nivel de
abstracción que las clases. La asociación no es contenida por las clases o subordinada a las
clases; es el reflejo de una conexión que existe en el ámbito de aplicación. Para mejorar la
legibilidad de los diagramas, la asociación puede ir acompañada por una forma verbal activa o
pasiva. En los ejemplos siguientes, el sentido de lectura se precisa por los signos < y >.
Ejemplo: La relación Alberga> y <Estudia en, entre Universidad y Estudiante, se muestra en la
Figura 6
Fig. 6 Clasificación de la naturaleza de una asociación por una forma verbal (Modelos de Objetos con
UML).
I.3.5.2.3 MULTIPLICIDAD
Cada función de una asociación lleva una indicación de multiplicidad que muestra
cuántos objetos de la clase considerada pueden ser relacionados con un objeto de la otra clase.
La multiplicidad es una información consecuencia de la función, bajo la forma de una expresión
entera acotada.
Universidad EstudianteAlberga >
Universidad Estudiante<Estudia en
La multiplicidad depende del contexto de la aplicación. Existen, distintos tipos de
multiplicidad para las asociaciones de las cuales las más relevantes son las siguientes:
"uno-uno": donde dos objetos se relacionan de forma exclusiva, uno con el otro. Ejemplo: Cada
País tiene un Presidente, y cada Presidente rige un País.
"uno-muchos": donde uno de los objetos pueden estar ligado a muchos otros objetos. Ejemplo:
Muchas Personas pueden trabajar en una Empresa, y una sola Empresa da empleo a cada
Persona.
"muchos-muchos": donde cada objeto de cada clase puede estar ligados a muchos otros objetos.
Ejemplo: Muchas Personas pueden trabajar en varias Empresas.
La multiplicidad se incluye en el diagrama de clases únicamente. La multiplicidad para
relaciones de mayor grado es más compleja, volviéndose esta notación un poco ambigua para
relaciones de mayor orden ya que no sabría cómo leerse la relación. Se incorpora la siguiente
notación en cada uno de los extremos de una asociación binaria. La notación para relaciones
"uno-uno", donde dos objetos solo pueden tener una liga entre ellos, es la notación básica de
asociación hasta ahora dada, la Figura 7 muestra un ejemplo de dos clases conectadas por una
asociación de 1 a 1, donde no es necesario disponer de un coche para construir un motor y
viceversa.
Fig. 7 Multiplicidad de una asociación "uno-uno" (Modelado de Objeto con UML).
La notación para relaciones "uno-muchos", donde uno de los objetos pueden estar ligado
a muchos otros objetos, está dada por una "bolita negra" (asterisco) representando el lado de
"muchos", el cual corresponde a uno o más ligas, en la Figura 8, la multiplicidad de valor 0..*
en el lado de la clase Persona significa que una empresa emplea de cero a varias personas.
Fig. 8 Multiplicidad de una asociación de "uno-muchos" (Modelado de Objeto con UML).
I.3.5.3 DEPENDENCIA O INSTANCIACIÓN (USO)
Coche Motor1 1
Persona Empresa0..* 1
La dependencia es una relación de utilización unidireccional entre elementos (de
modelado y de visualización). La relación de dependencia enlaza elementos dentro de un
mismo modelo. El uso más particular de este tipo de relación es para denotar la dependencia
que tiene una clase de otra, como por ejemplo (ver figura 9) una aplicación gráfica que
instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación
desde el objeto Aplicación).
Fig. 9. Ejemplo de Instanciación
Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena
dentro del objeto que lo crea (en este caso la Aplicación).
I.3.5.4 POLIMORFISMO
El término polimorfismo describe la característica de un elemento que puede tomar
varias formas, como el agua que se encuentra en estado sólido, líquido o gaseoso. En
informática, el polimorfismo designa un concepto de la teoría de los tipos, según el cual un
nombre de objeto puede designar instancias de clases diferentes surgidas de un mismo árbol.
Las interacciones entre objetos se escriben según los términos de las especificaciones definidas,
no en las clases de los objetos, sino en sus superclase.
El término polimorfismo designa la posibilidad de desencadenar operaciones diferentes
en respuesta a un mismo mensaje. Cada subclase hereda de la especificación de las operaciones
de sus superclase, pero tiene la posibilidad de modificar localmente el comportamiento de estas
operaciones, a fin de tener en cuenta mejor la peculiaridades relacionadas con un nivel de
abstracción dado. Desde este punto de vista, una operación dada es polimorfa porque su
realización puede tomar varias formas.
Aplicación Ventana
I.3.6 LENGUAJE DE MODELADO UNIFICADO (UML)
UML es una especificación de notación Orientada a Objetos. Se basa en las anteriores
especificaciones BOOCH, RUMBAUGH y JACOBSON. Divide cada proyecto en un número
de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los
que representa la arquitectura del proyecto.
UML es un lenguaje que provee el vocabulario y las reglas que lo rigen, con lo que
permite la representación conceptual y física de los sistemas, maneja un vocabulario que abarca
tres clases de bloques: elementos, relaciones y diagramas. Los elementos son abstracciones que
representan entidades de un modelo, las relaciones son mecanismos para enlazar los elementos,
y los diagramas manejan diferentes visualizaciones de conjuntos de elementos conectados entre
sí. Con UML debemos olvidar el protagonismo excesivo que se le da al diagrama de clases que
solo representa una vista estática del sistema (Ver explicación más adelante en este Capítulo),
es decir muestra al sistema parado. UML introduce nuevos diagramas que representa una visión
dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos
darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las
partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en
cada momento. UML también intenta solucionar el problema de propiedad de código que se da
con los desarrolladores, al implementar un lenguaje de modelado común para todos los
desarrollos se crea una documentación también común, que cualquier desarrollador con
conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para
el desarrollo.
UML es ahora un estándar, no existe otra especificación de Diseño Orientado a Objetos,
ya que es el resultado de las tres opciones existentes en el mercado. Su utilización es
independiente del lenguaje de programación y de las características de los proyectos, ya que
UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos como de
arquitectura, o de cualquier otro ramo.
I.3.7- CONCEPTOS METODOLÓGICOS DEL PROCESO DE DESARROLLO
UNIFICADO RATIONAL (RUP)
El Proceso Unificado Rational (RUP) es un proceso para el diseño de sistemas de
software. Su finalidad es asegurar la producción de sistemas de calidad superior que satisface
las necesidades de sus usuarios finales.
Evolución del Proceso de Desarrollo Unificado Racional (RUP)
Booch, Jacobson y Rumbaugh
“El Proceso Unificado de Desarrollo de Software”, 1999
Kruchten
“The Rational Unified Process”, 2000
Arquitectura del RUP
Fases y Disciplinas del RUP: Fuente: RUP, 2002
Fig. 10 Muestra la arquitectura global del RUP.
El eje vertical de la gráfica representa las disciplinas del ciclo de vida del desarrollo de
sistemas, las cuales agrupan las actividades que se deben realizar para conseguir los productos
del proceso. El eje horizontal representa el tiempo y muestra las fases del ciclo de vida y los
aspectos del proceso que deben cubrirse en cada una de ellas. Las curvas representan la
cantidad de trabajo concentrado en una disciplina determinada [RUP; 2002]
La fase de Inicio es de principal importancia para dirigir los esfuerzos del desarrollo
hacia la identificación de los riesgos que deben mitigarse para asegurar que el proyecto merece
la pena y es posible de realizar [RUP; 2002].
La fase de Elaboración se realizan los Casos de Uso que se identificaron en la fase de
inicio, el resultado de esta fase es la línea base de la arquitectura [RUP; 2002]
La fase de Construcción su meta es clarificar los requisitos restantes y completar el
desarrollo del sistema basado en la línea base de la arquitectura [RUP; 2002].
La fase de Transición cubre el período durante el cual el producto se convierte en la
primera versión del sistema software, conlleva actividades como: fabricación, formación del
cliente, asistencia [RUP; 2002].
Entre las características que ofrece el Proceso Unificado Rational tenemos:
• Iterativo e incremental: permite desarrollar un sistema a través de refinamientos sucesivos
e incorporación de nuevas funcionalidades, creando una solución efectiva, en múltiples
iteraciones.
• Arquitectura de un Sistema: La descripción del Sistema a través de vistas -Proyección de
la organización y estructura de un sistema enfocándose en aspectos particulares-
utilizando diagramas y modelos.
• Basado en Casos de Uso: Permiten una representación gráfica adecuada de las
funcionalidades requeridas por usuarios, clientes.
El Proceso Unificado Rational lleva a cabo una serie de labores durante el ciclo de vida de desarrollo del
sistema de información.
I.3.7.1 REQUERIMIENTOS
La disciplina de requerimientos tiene como meta definir y delimitar la funcionalidad del
sistema de información. Un requerimiento se define como "una condición o capacidad que un
sistema debe conformar." [RUP; 2002].
I.3.7.1.1 MODELO DE CASOS DE USOS.
El modelo generado (Modelo de Casos de Uso) sirve como base de negociación y
contrato entre el desarrollador del sistema y el usuario, y por lo tanto refleja los deseos del
usuario. Es esencial que los usuarios que no tengan un conocimiento de la computación puedan
comprender el modelo para facilitar la interacción con ellos
El Modelo de Caso de Uso especifica la funcionalidad del sistema desde una perspectiva
de usuario y define qué deberá hacerse dentro del sistema, basándose en Actores y Casos de
Uso.
Los Diagramas (Modelos) de los Casos de Uso involucran tres elementos básicos, a
saber:
• Actor
• Caso de Uso
• Relaciones entre los Casos de Uso
I.3.7.1.1.1 ACTOR
Los actores representan los roles que el usuario del sistema puede desempeñar en un
momento dado. Los actores constituyen entidades (humanos, máquinas, otros sistemas) que son
externas e interactúan directamente con el sistema.
Un mismo usuario puede desempeñar varios roles, de tal manera que puede representar
diferentes actores. Así como también, un mismo actor puede utilizar de diferentes maneras el
sistema. Un actor utiliza un Caso de Uso para hacer cumplir alguna pieza de trabajo la cual
concierne a valores del negocio. En la figura 11 se presenta la notación para un actor por Ivar
Jacobson.
Fig. 11 Representación del Actor por UML
En cada iteración e incremento del desarrollo del sistema los actores identificados
toman un mayor nivel de refinamiento hasta constituirse en el conjunto de los actores
plenamente identificados. Al definir todos los actores y Casos de Uso en el sistema, se define la
funcionalidad completa del sistema.
I.3.7.1.1.2 CASOS DE USO
Es una manera específica de usar el sistema. En él se describen las posibles secuencias
de interacción entre el sistema y uno o más actores, en respuesta a algún estímulo inicial
emitido por alguno de los actores.
El Caso de Uso define la funcionalidad interna del sistema: representa la visión del
usuario final, en complemento a la visión del desarrollador que se representa mediante los
objetos. Por lo general, cada Caso de Uso se centra en una funcionalidad particular del sistema,
esto permite desarrollar el sistema en paralelo. Al agrupar todos los Casos de Uso tenemos la
funcionalidad global del sistema.
Cada Caso de Uso constituye un flujo completo de eventos especificando la interacción
que toma lugar entre el actor y el sistema. La ejecución del Caso de Uso termina cuando el
actor genera un evento que requiera un Caso de Uso nuevo. Las diferentes instancias (flujo
específico de eventos a través del sistema) de Caso de Uso se conocen como escenarios. Como
varios Casos de Uso pueden comenzar de una misma forma, no es siempre sencillo decidir
cual Caso de Uso se ha instanciado hasta que se haya completado. En la Figura Nº 12, se
presenta la notación para de un Caso de Uso por Ivar Jacobson.
Fig. 12 Representación de un Caso de Uso por UML
I.3.7.1.1.3 RELACIONES ENTRE CASOS DE USO
Los Diagramas de Casos de Uso representan los Casos de Uso, los actores y las
relaciones entre los Casos de Uso y los actores. UML define tres tipos de relaciones entre
actores y Casos de Uso:
Una relación de comunicación es una asociación entre una clase de actor y una clase de
Caso de Uso, indicando que sus instancias interactúan. Los Casos del Uso y actores actúan
recíprocamente enviándose señales entre si. El sentido de la flecha (señal) indica el iniciador de
la interacción.
La relación de Uso o Incusión (Incluye) es una relación de extensión de un Caso de Uso
a un Caso de Uso base, especificando cómo la conducta definida para el Caso de Uso de
extensión puede insertarse en la conducta definida para el Caso de Uso base.
La relación de extensión (Extiende) especifica cómo un Caso de Uso fuente extiende el
comportamiento del Caso de Uso destino. Después que la extensión se ha terminado, el curso
original continúa como si nada hubiera ocurrido. Por regla general, se describe primeros los
Casos de Uso básicos totalmente independientes de cualquier extensión de funcionalidad y
luego aquellos de extensión.
En la Figura 13 se muestra la notación para extensión, utilizando la etiqueta “extiende”,
donde el Caso de Uso de Giro por Internet es extendido mediante el Caso de Uso Giro. En la
misma figura se etiqueta una relación con “incluye”. Por ejemplo, el Caso de Uso de Giro
incluye el Caso de Uso Identificación.
<<Extende>>
<<Incluye>>
Usuario Fig. 13 Representación del diagrama de Casos de Uso por UML
I.3.7.2 PROTOTIPOS
La categorización clásica y el agrupamiento conceptual son suficientemente expresivos
para utilizarse en la mayoría de las clasificaciones que se necesiten realizar en el diseño de
sistema de software complejos. Sin embargo, existen algunas situaciones en las cuales estas
aproximaciones no son adecuadas. Esto conduce al desarrollo de prototipos. Una clase de
objeto se representa por un objeto prototípico, y se considera un objeto como un miembro de
una clase si y solo si se parece a este prototipo de forma significativa. El proceso de desarrollo
y empleo de un prototipo tiene cinco características, como son:
• El prototipo es una aplicación que funciona
• La finalidad del prototipo es probar varias suposiciones formuladas por un analista y
usuarios con respecto a las características requeridas por el sistema
• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo
• Los prototipos tienen un costo bajo de desarrollo
Para la construcción del prototipo es necesario tomar en cuenta las diferentes situaciones de
interacción que se presentan en cada uno de los Casos de Uso analizados. Normalmente, un
prototipo funcional de requerimientos mostrando las interfaces de usuario es una estrategia
importante. Esto ayuda al usuario a visualizar los Casos de Uso según serán mostrados por el
Giro por Internet
Giro
Identificación
sistema a ser construido. Cuando se diseña las interfaces de usuario es esencial tener a los
usuarios involucrados, siendo esencial que las interfaz reflejen la visión lógica del sistema. De
esta forma y observando todo el escenario, la interfaz resultante debe ajustarse a la
características de la aplicación. Los prototipos permiten diseñar la interfaz gráfica, sin incluir su
operatividad, hasta tanto no evolucionen y se ajusten en su totalidad a la funcionalidad deseada.
Los prototipos son una manera rápida para comprender los modelos de requerimientos, análisis,
diseño, implementación y pruebas de un sistema. Sin embargo, existe la idea errónea de que
gracias a la Tecnología Orientada a Objetos los prototipos se pueden evolucionar iterativamente
hasta llegar al sistema final.
Se cree que simplemente se comienza a codificar y se deja que el producto se desarrolle.
Esto realmente varía y depende del tipo de prototipo que se esté desarrollando:
• Prototipos de requerimientos: Un prototipo de requerimientos permite que los usuarios
interactúen con una “interfaz” del sistema que muestre toda o casi toda la funcionalidad
requerida del producto final sin que realmente se implemente. El objetivo es ayudar a clarificar
los requerimientos y solicitar nuevas ideas. Como las interfaces complejas son difíciles de
documentar, el prototipo puede incluirse como parte de la documentación de requerimientos. Es
el tipo de prototipo desarrollado para el desarrollo del sistema en estudio.
• Prototipos de análisis: Un prototipo de análisis permite generar una arquitectura general del
sistema de manera rápida que considere las características principales del sistema, como qué
componentes podrían ser utilizados. La idea es mostrar un bosquejo rápido de esta arquitectura
que se apegue a los requerimientos especificados originalmente.
• Prototipos de diseño: Un prototipo de diseño se desarrolla para explorar y comprender la
arquitectura particular del sistema. El prototipo puede servir como base para la evaluación de
rendimiento y espacio, y para pruebas de redundancia o inconsistencias en el diseño.
Evaluación del rendimiento de un prototipo de diseño puede identificar cuellos de botella en el
sistema, dónde se requiere revisar con más detalle antes de poder desarrollar el producto final.
• Prototipos verticales: Un prototipo vertical se usa para comprender una sección o parte de un
problema y su solución completa. Esto se hace cuando los conceptos básicos no están bien
comprendidos y cuando el desarrollar todos los aspectos de una funcionalidad muy limitada
ayuda a aclararlos.
• Prototipos de factibilidad: Un prototipo de factibilidad se usa para demostrar si un aspecto
del proyecto es posible. Por ejemplo, si una arquitectura particular es aplicable; si la manera de
conectarse a una base de datos ofrece un rendimiento adecuado; si es posible que un grupo de
desarrollo aprenda a programar en cierto lenguaje; si la tecnología es apropiada para la
organización; o si los costos esperados por un proyecto cubren sus gastos.
I.3.7.3 ANÁLISIS Y DISEÑO
Los propósitos de la disciplina de Análisis y Diseño son:
Para transformar los requerimientos en el diseño del sistema.
Para envolver una arquitectura robusta para el sistema.
Adaptar el diseño para emparejar al ambiente de aplicación, diseñándolo para la actuación
I.3.7.3.1 ARTEFACTOS QUE SE DESARROLLAN EN LA DISCIPLINA DE ANÁLISIS
Y DISEÑO
I.3.7.3.1.1 MODELO DE ANÁLISIS
Un modelo de objeto que describe la realización de Casos de Uso, y qué sirve como una
abstracción del Modelo de Diseño.
I.3.7.3.1.2 CLASES DE ANÁLISIS
Las clases de análisis representan un modelo conceptual inicial para las cosas que ‘en el
sistema tienen responsabilidades y conducta (comportamiento) '. Pueden estereotiparse las
clases de análisis como una de las siguientes:
Clases Interfaz
Clases Control
Clases Entidad
Clases Interfaz: Una clase interfaz es una clase utilizada para modelar la interacción
entre los ambientes del sistema y sus funcionamientos internos. Tales interacciones involucran
transformaciones y traducciones de los eventos y cambios en la presentación del sistema (como
la interfaz).
Clases control: Una clase control es una clase que modela la conducta del control
específico a uno o varios Casos de Uso. Los objetos de control (instancias de clases de control)
a menudo controlan otros objetos, así que su conducta es de tipo coordinando. Las clases
control encapsulan la conducta específica de Casos de Uso.
Clases entidad: Una clase entidad es una clase que modela la información y el
comportamiento asociado que deban guardarse. El objeto entidad (instancias de clases entidad)
es usado para manejar y actualizar la información sobre algún fenómeno, como un evento, una
persona, o algún objeto de la vida real. Son normalmente persistentes, teniendo atributos y
relaciones que se necesitan por un largo período, a veces durante toda la vida del sistema.
I.3.7.3.1.3 MODELO DE DISEÑO
El Modelo de Diseño es un modelo de objeto que describe la realización de los Casos de
Uso, y sirve como una abstracción del modelo de implementación y su código fuente. El
Modelo de Diseño se usa como entrada esencial a las actividades en la implementación y
prueba.
I.3.7.3.1.4 CLASES DE DISEÑO
Una clase de diseño representa una abstracción de una o varias clases en la
implementación del sistema; exactamente lo que corresponde a depender del lenguaje de
implementación. Por ejemplo, en un lenguaje Orientado a Objeto como C++, una clase puede
corresponder a una clase plana.
I.3.7.3.1.5 DIAGRAMAS EN EL MODELO DE DISEÑO
I.3.7.3.1.5.1 DIAGRAMA DE CLASES
Un Diagrama de Clase se presenta como una vista de diseño estática de un sistema a
través de los elementos del modelo, como las clases interfaces y sus relaciones, conectados
como un gráfico entre uno y otros y a sus contenidos. Los Diagramas de Clase pueden
organizarse en (y poseídos por) paquetes, mostrando lo que es pertinente dentro de un paquete
particular.
I.3.7.3.1.5.2 DIAGRAMA DE COLABORACIÓN
Un Diagrama de Colaboración describe un modelo de interacción entre los objetos;
muestra los objetos que participan en la interacción por sus vínculos a cada uno y los mensajes
que envían entre cada uno de ellos.
Se usan los Diagramas de Colaboración para mostrar cómo los objetos actúan
recíprocamente para realizar la conducta de un Caso de Uso particular, o una parte de un Caso
de Uso. Junto con los Diagramas de Secuencia, las colaboraciones son usadas por los
diseñadores para definir y clarificar los roles que los objetos realizan en un flujo particular de
eventos de un Caso de Uso. Son la fuente primaria de información usada para determinar
responsabilidades de las clases e interfaces.
I.3.7.3.1.5.3 DIAGRAMA DE SECUENCIA
Un Diagrama de Secuencia representa una interacción entre objetos insistiendo en la
cronología de los envíos de mensajes. Los objetos se comunican intercambiando mensajes
representados por medio de flechas horizontales, orientadas del emisor del mensaje hacia el
destinatario.
En la mayoría de los casos se usa un Diagrama de Secuencia para ilustrar las
realizaciones de Casos de Uso, es decir, para mostrar cómo los objetos actúan recíprocamente
para realizar la conducta de todo o parte de un Caso de Uso. Uno o más Diagramas de
Secuencia pueden ilustrar las interacciones de los objetos que promulgan un Caso de Uso. Una
organización típica es tener un Diagrama de Secuencia para el flujo principal de eventos y un
Diagrama de Secuencia para cada flujo subalterno independiente del Caso de Uso.
El formato de un Diagrama de Secuencia se muestra en la Figura 14. Nótese que es un
diagrama exclusivamente de objetos y no de clases. Sin embargo, los objetos son instancias de
clases que al no tener ningún nombre particular se muestran a través del nombre de la clase
subrayada y con el prefijo de “:”, correspondiente a la notación de clases abstractos usada en la
UML[Jacobson, Booch y Rumbaugh].
:Clase1 :Clase2 :Clase3 :Clase4
Fig. 14 Representación de un diagrama de secuencia
Cada clase participante se representa por una barra, dibujadas como líneas verticales en
el diagrama. El orden entre las barras es insignificante y debe elegirse para dar la mayor
claridad. Si hubiera varias instancias de las clases que interactúan entre sí, se dibujarían las
instancias como barras diferentes.
Además de los objetos, es importante representar entidades externas al sistema en los
Diagramas de Secuencia. En nuestro caso, estas entidades externas que se incluyen como barras
adicionales en el diagrama representando instancias de los actores. El comienzo del diagrama
de secuencia corresponde al inicio del Caso de Uso. Para describir la comunicación entre
objetos se utilizan estímulos o eventos, los cuales se envían de un objeto a otro para activar una
ejecución en ese objeto, que además puede enviar nuevos estímulos a otros objetos. El diagrama
de secuencia de la Figura 15 muestra un ejemplo de estos eventos.
:Clase1 :Clase2 :Clase3 :Clase4
a1
a3a2
a4
a5
1:e1
2:·e2
3:e3
4:34
5:e5
6:36
Fig. 15 Diagrama de Secuencia con eventos
Fig. 16 Izquierda: Mensaje de un objeto a otro objeto. Derecha: Mensaje al mismo objeto
En el diagrama de la Figura 15, las barras gruesas corresponden a actividades dentro
del objeto, denominadas por a, mientras que las flechas corresponden a eventos, denominadas
por e. Un evento se dibuja como una flecha horizontal que comienza en la barra
correspondiente al objeto que lo envía y termina en la barra correspondiente al objeto que lo
recibe (Ver Figura 16).
Un aspecto importante que los Diagramas de Secuencia deben considerar es que las
secuencias de eventos sean continuas y no haya interrupciones.
Por otro lado la gran mayoría de los Diagramas de Secuencia, y por lo tanto los Casos de
Uso, deben comenzar con un evento externo que se genera a partir de una de las instancias de
los actores del sistema.
I.3.7.4 IMPLEMENTACIÓN
El propósito de la disciplina de Implementación es:
Definir la organización del código, en lo que se refiere a subsistemas de implementación.
Implementar clases y objetos en lo que se refiere a los componentes (archivos fuentes,
binarios, ejecutables, y otros).
Probar los componentes desarrollados.
Integrar los resultados producidos en un sistema ejecutable
I.3.7.4.1 ARTEFACTOS DN LA DISCIPLINA DE IMPLEMENTACIÓN.
I.3.7.4.1.1 MODELO DE IMPLEMENTACIÓN.
El resultado obtenido del Modelo de Diseño es utilizado por el Modelo de
Implementación para generar el código fuente. El modelo de implementación abarca todos los
artefactos necesitados para construir y manejar el sistema en el ambiente de tiempo de
ejecución.
El modelo de implementación es una colección de componentes (explicado más
adelante) y subsistemas que los contienen. En el ambiente de programación, los componentes
toman la forma de archivos de código fuente, archivos binarios, y archivos de datos,
organizados en los directorios; se materializan los subsistemas en la forma de directorios.
I.3.7.4.1.2 COMPONENTES
Un componente representa un pedazo de código del sistema de información, o un
archivo que contiene información. Un componente también puede ser un agregado de otros
componentes; por ejemplo, una aplicación que consiste en varios ejecutables.
Es posible estereotipar los componentes, por ejemplo, «aplicación», «documento»,
«ejecutable», «archivo», «biblioteca», «página», «tabla» o «componente de prueba».
I.3.7.5 PRUEBA
La disciplina de prueba actúa como un proveedor de servicio a las otras disciplinas, su
función es describir los resultados de las pruebas. En las pruebas se evalúa o valora la calidad
del sistema a través de varias prácticas:
Encontrando y documentando los defectos en la calidad del sistema de información.
Demostrando la validez del diseño.
Validando que los productos del sistema de información funcionan como fueron diseñados.
Validando que los requerimientos se han implementados apropiadamente.
I.3.7.5.1 PLAN DE PRUEBA
Constituye la definición de las metas y objetivos de las pruebas dentro del alcance del
proyecto, los recursos requeridos y las entregas a ser producidas.
I.3.8 TÉRMINOS DE LA METODOLOGÍA DE SISTEMAS SUAVES (SSM)
I.3.8.1 Pensamientos de Sistemas: hace uso consciente del concepto particular de integridad
que se aprende en la palabra “sistema”, para ordenar nuestros pensamientos. Implica razonar
acerca del mundo que hay fuera de nosostros, y hacerlo mediante el concpto de “sistema”
[Checkland; 1993].
El pensamiento de sistemas asume seriamente la idea de una entidad “todo” que podría
exhibir propiedades como si fuese un todo individual (“propiedades emergentes”), propiedades
que no tienen significado en términos de las “partes” del todo. El ejercer el pensamiento de
sistemas significa confrontar algunos todos abstractos construidos (a menudo denominados
“modelos de sistemas”) con el mundo real percibido, para así aprender acerca de éste último. El
propósito de hacer esto puede ir desde el ingenierar alguna parte del mundo percibido como un
sistema, hasta la búsqueda de discernimiento o iluminación [Checkland-Scholes; 1994].
I.3.8.2 Pensamientos de Sistemas “duros”: asume que el mundo es sistemático[Checkland-
Scholes; 1994].
Está dirigido a una meta, en el sentido de que un estudio en particular comienza con la
definición de la meta deseada a alcanzarse. La ingeniería de sistemas define “la necesidad” o el
objetivo a alcanzarse, y el análisis de sistemas proporciona una forma ordenada para seleccionar
el mejor de entre los sistema alternativos que podrían satisfacesr esa necesidad. La creencia de
que los problemas del mundo real se pueden formular de esta forma es la característica
distintiva de todo el pensamiento de sistemas “duros” [Checkland; 1993].
I.3.8.3 Pensamientos de Sistemas “suaves”: crea el proceso de indagación bajo la forma de
un sistema [Checkland-Scholes; 1994].
Aplicación de métodos a problemas donde las metas a menudo son oscuras, donde los
supuestos solucionadores de problemas se ven enfrentados no con la definición de las metas del
sistema, sino con la selección de lo que se va a considerar como el “sistema” de un gran número
de posibilidades.La principal diferencia entre los enfoques “duros” y “suaves” es que donde el
primero puede dar inicio a preguntarse “Qué sistema se tiene que ingenierear para resolver este
problema? o “Qué sistema satisfacerá esta necesidad?” y puede tomar al problema o la
necesidad como “dada”; el último tiene que permitir que emerjan respuestas completamente no
esperadas en estadios posteriores[Checkland; 1993].
I.3.8.4 Metodología en general (SSM): desarrollo de principios concernientes al uso de ideas
de sistema en la solución de problemas, en situaciones del mundo real [Checkland; 1993]. La
SSM es un proceso sistemático de indagación que también hace uso de los modelos de sistemas.
Ella así incluye el enfoque duro, que es un caso especial de la misma, un enfoque que surge
cuando existe acuerdo local sobre algún sistema que ha de ingenierarse.
I.3.8.5 Técnicas: es un programa de acción específico y preciso que generará un método
estandar. Una técnica indica el “como” y una filosofía le indica el “que”, una metodología
contiene elementos tanto del “que” como del “cómo”.
I.3.8.6 Sistema de actividad humana: en contraste con otros tipos de sistema, los sitemas de
actividad humana nunca se pueden describir o “modelar” en un solo reporte que sea aceptable
generalmente o suficiente. Para un sistema de este tipo puede muy bién haber tantas
descripciones de él como hay gente que no es completamente indiferente a él. Esta es la
característica del mundo real que obliga a la metodología a volverse un medio para organizar la
discusión, el debate y el argumento, en vez de un medio para ingeniar “soluciones” eficientes
[Checkland; 1993].
La palabra “holon” se utiliza para designar a los todos abstractos construidos,
concediendo a la palabra “sistema” el significado del lenguaje diario, sin tratar de utilizarla
como término técnico. La SSM utiliza un tipo particular de holon, en otras palabras, un así
denominado “sistema de actividad humana”. Este es un grupo de actividades tan conectadas
como para construir un todo con propósito definido[Checkland-Scholes; 1994].
CAPÍTULO II
DEFINICIÓN DEL TRABAJO DE GRADO II.1 Título del Proyecto
Sistema para dar soporte en la generación del contenido de un Curso aplicando recursos
Multimedia.
II.2 El Problema, Sus Antecedentes, Una Alternativa de Solución.
La educación a distancia nace por la necesidad de ampliar la cobertura a sectores no
atendidos de nuestra población, rompiendo los esquemas tradicionales de Tiempo y Espacio al
eliminar la obligatoriedad de presencialidad en sitio y hora de nuestra educación tradicional.
En cierta medida la educación a distancia da respuesta a los problemas de masificación o
expansión acelerada del sector universitario tradicional. Muchas personas que de otra manera
no podrían acceder a la enseñanza pueden hacerlo gracias a estos nuevos medios (personas
separadas en núcleos de población, trabajadores o personas que tienen dificultades de acceso
"normal"), de ahí, el auge actual de la enseñanza a distancia.
En la educación a distancia el proceso de enseñanza-aprendizaje se efectúa,
fundamentalmente, a través de material impreso como el Medio Maestro. Normalmente textos
que tratan de ser autoinstructivos. Ahora bien, a la educación a distancia le interesa acercarse a
sus estudiantes y, evidentemente, transmitirles eficientemente información, y para eso hace falta
aprovechar el potencial que ofrecen las Tecnologías. La capacidad tecnológica, es un requisito
necesario, aunque no suficiente, para lograr los objetivos de las organizaciones, que no
excluyen, por supuesto, las educativas.
En Julio de 1975, el Estado Venezolano crea una Comisión Organizadora de la
Universidad Nacional Abierta (UNA), en Septiembre de 1976, dicha comisión presenta al
Consejo Nacional de Universidades (CNU), la primera etapa de la planificación, que
comprendía estudios de justificación, factibilidad y caracterización general de la institución.
La Universidad Nacional Abierta se crea formalmente el 22 de Septiembre de 1977,
según decreto Nº 2398, destinada a la formación de profesionales en áreas prioritarias del
desarrollo nacional utilizando sistemas no tradicionales de enseñanza-aprendizaje. Los
estudiantes forman un grupo heterogéneo en edad, intereses, motivaciones, experiencias y
aspiraciones, son en su mayoría, adultos o jóvenes adultos, que no han podido ingresar a las
universidades presenciales por limitaciones de distinta índole: trabajo, responsabilidades
familiares, académicas, financieras, geográficas. A partir del año 1978 se constituyen los
Centros Locales en cada una de las capitales de los estados del país.
El currículum se concibe como un proyecto que opera para orientar la concepción y
práctica educativa, así como también para evidenciar los compromisos y responsabilidades en
la formación de individuos competentes hacia la participación y solución de problemas sociales,
científicos y tecnológicos. Las propuestas de ajustes curriculares efectuados a las carreras que
ofrece la Universidad Nacional Abierta (2002) plantean también la necesidad de hacerlo al
componente curricular del Curso Introductorio, de tal manera que este sea pertinente y responda
a las exigencias del continuo curricular. En concordancia con esta perspectiva, los conceptos y
premisas del Modelo Teórico Curricular de la UNA (1977) se refiere a: la realidad como
punto de partida para la formación personal y profesional del estudiante y de las posibilidades
de modificación por medio del conocimiento; el adulto capaz de contribuir a su propio
desarrollo y al del país; la ciencia susceptible de incremento y revalidación; la enseñanza
como concreción de un conjunto de oportunidades, que permiten la relación entre la persona y
la realidad y la búsqueda de soluciones en su entorno mediante la realización o incremento de
su formación integrada; la interacción en la enseñanza de la teoría y la práctica; el
conocimiento y la realidad; la docencia-el aprendizaje-investigación, con la extensión como
acción y compromiso educativos con la comunidad; la educación a distancia, principalmente
para adultos con experiencias y conocimientos previos capaces de participar en la construcción
de nuevos aprendizajes, y el uso de medios de comunicación como factores de enseñanza, que
la diferencian del sistema formal.
Los medios instruccionales se refieren a los materiales impresos y a los recursos
complementarios para desarrollar los procesos de orientación y formación, en correspondencia
con las tareas, los conocimientos y rasgos del ser como estudiante de la modalidad abierta y a
distancia. Los medios instruccionales impresos (escritos), presentan una serie de debilidades
como lo son: la desactualización de los contenidos y la dificultad de actualizarlos, los costos
elevados, y las limitaciones físicas de algunos Centros Locales para la realización de
actividades grupales entre otros, de allí la necesidad de contar con un recurso de apoyo para
generar material instruccional electrónico con un formato digitalizado sencillo y de entorno
amistoso, que contribuya con el estudiante en salvar dificultades en pro de logros exitosos, que
le permita una mayor motivación y estímulo para aprender, y que estén dentro de sus
posibilidades socioeconómicas.
Actualmente la Universidad está incorporando nuevas tecnologías de la información y la
comunicación, que cumplan un papel de mediador en el proceso de enseñanza. Los
computadores permiten cosas interesantes desde el punto de vista de la enseñanza: no se cansan
nunca; mantienen un cuerpo de conocimientos que se puede transmitir; permiten una
intervención multimedia: mezcla de diferentes medios (vídeo, música, audio, texto), permiten
colocar gran cantidad de información en soportes pequeños y pueden recuperarla, lo que antes
no era posible. Estos medios permiten organizar la información de maneras muy diferentes a las
convencionales (libros), y en algunas ocasiones, de manera muy superior a como puede hacerlo
un profesor. Permiten, además, individualizar la formación. Las personas pueden aprender
aspectos específicos que quieren aprender, y ampliar la información de manera fácil, algo que
en las clases presenciales resulta más difícil.
El tema del aprendizaje a través de medios virtuales es muy amplio, el aprendizaje
virtual es un tipo de aprendizaje que en lugar de interacción entre personas (profesores y
alumnos) propone un tipo de interacción en la que en medio está un sistema. En esta clase de
aprendizaje, muchas veces a distancia, se produce una mediación entre profesor y alumno y no
hay encuentro físico. Por tanto, la manera de aprender se realiza tanto con los profesores como
con los recursos que han surgido. El Material instruccional Electrónico puede estar almacenado
en un CD-ROM, DVD u otro medio.
Sus características son:
1- “La facilidad para cambiar y actualizar la información contenida”.
2- “La capacidad que dispone para almacenar información, que afecta todos los tipos y la forma
de uso”.
3- “La interactividad”.
Estando en armonía con lo anteriormente planteado, el objetivo de la investigación
consiste en:
“Desarrollar un sistema para dar soporte en la generación del contenido de un Curso
aplicando recursos Multimedia.
II.3 Objetivos del Proyecto.
II.3.1 Objetivo general
Desarrollar un sistema para dar soporte en la generación del contenido de un Curso
aplicando recursos Multimedia.
II.3.2 Objetivos específicos
1- Conceptualizar el Sistema propuesto.
2- Detectar las necesidades y requerimientos de los usuarios.
3- Analizar los requerimientos de los usuarios para transformarlos en el diseño del sistema a
construir.
4- Confrontar la interfaz del usuario, enfocando sus necesidades y metas, mediante el desarrollo
de un instrumento PIECES.
5- Implementar el diseño realizado.
6- Realizar pruebas para validar que los productos funcionan como fueron diseñados.
7- Documentar el sistema generador de Contenidos Multimedia.
8- Adiestrar al personal relacionado que utilizará el sistema generador de Contenidos
Multimedia.
II.4 Alcances del Proyecto.
A continuación se describen los alcances de este proyecto, y los productos que se
obtuvieron mediante la aplicación de la estrategia metodológica.
Se definirá un sistema pertinente al sistema en estudio a través de la formulación de
definiciones raíz.
Se confeccionará un Modelo Conceptual sobre la base de la Definición Raíz.
Se construirá un Modelo de Caso de Uso a partir del Modelo Conceptual y los
requerimientos de los usuarios basado en actores, Casos de Usos, sus descripciones y
relaciones, donde se representará la funcionalidad del sistema generador de Contenidos
Multimedia.
Se desarrollará el Modelo de Análisis como base para el Modelo de Diseño en donde se
presentarán y describirán las clases de análisis que participan en cada Caso de Uso y sus
relaciones (diagramas de colaboración).
Se diseñarán prototipos de interfaz las cuales iterativamente evolucionarán (Prototipos
evolutivos) hasta considerarse eficientes y eficaces para convertirse en las interfaces
definitivas (Sistema deseado).
Se desarrollará el modelo de diseño para transformar los requerimientos de los usuarios en
el diseño del sistema, el cual determinará la arquitectura integral del sistema, a través de los
diagramas de secuencia y de clases para cada Caso de Uso, asimismo, se diseñará el Modelo
de Clases del sistema.
Sobre la base del Modelo de Diseño, se Elaborará un Modelo de Implementación que
cumpla con los requerimientos inicialmente determinados
Se construirá un instrumento PIECES, que será empleado para confrontar los prototipos.
Se desarrollará y aplicará un Plan de prueba para asegurar el buen desempeño del sistema
generador de Contenidos Multimedia.
Se proveerá los manuales de Usuario y técnico para facilitar el uso, configuración y
modificación del sistema generador de Contenidos Multimedia.
Se realizará el adiestramiento inicial a los usuarios potenciales del Sistema en la generación
del Curso.
CAPÍTULO III
METODOLOGÍA Y RESULTADOS
El desarrollo de sistemas puede ser visto como un proceso de descripción de modelos
con diferentes niveles de abstracción o grados de detalle, que van desde los primeros modelos
con un nivel de abstracción elevado, basados en características externas del sistema, hasta llegar
a los menos abstractos, donde se describe cómo será construido el sistema y como funcionará.
Éste es un proceso que está expuesto a una serie de cambios sucesivos que vienen expresados
mediante requerimientos que introducen nuevas funcionalidades o mejoras a las
funcionalidades ya existentes [RUP; 1999].
En este capítulo se describe la aplicación de la estrategia metodológica seleccionada
para las actividades realizadas y los resultados obtenidos. El desarrollo del Sistema propuesto,
fue llevado a cabo siguiendo como línea central el Proceso Unificado Rational (RUP) propuesto
por Jabcoson, Booch, Rumbaugh y Kruchten (2002) como principales autores,
complementando con la metodología de Sistemas Suaves de Checkland(1993) y el instrumento
PIECES proporcionado por James Wetherbe para apoyar la clasificación de los problemas, las
oportunidades y las normas en el análisis de sistemas, obteniéndose de esta manera una
metodología de desarrollo fortificada, tomando como base la teoría presentada en el marco
teórico de este informe. La Figura N° 17 mostrada a continuación ilustra las disciplinas y fases
de la estrategia metodológica de desarrollo sobre la base del RUP(2002).
Como se puede observar en la Figura Nº 17 la estrategia metodológica de desarrollo
tiene dos dimensiones: el eje de las abscisas representa el tiempo y muestra los aspectos o fases
del ciclo de vida del proceso de desarrollo. El eje de las ordenadas representa las disciplinas o
grupo de actividades que deben realizarse a lo largo de las fases para cumplir el ciclo [RUP;
1999].
Fig. 17 Fases y Disciplinas en la Estrategia Metodológica de desarrollo.
El gráfico muestra por ejemplo, que en las iteraciones tempranas, se invirtió más tiempo
en los requerimientos, y en las iteraciones más tardías se gastó más tiempo en la
implementación. Las iteraciones en la fase de inicio escalonaron el enfoque en la
Conceptualización del Sistema; en la fase de elaboración en los requerimientos; en la fase de
construcción en el análisis, diseño e implementación de actividades; las iteraciones en la fase de
transición escalonaron el enfoque en las pruebas y documentación.
Dentro de cada fase el proyecto tuvo un ciclo de vida incremental e iterativo tal como
lo plantea el RUP, que consistió de varias iteraciones, donde cada iteración incorporaba un
juego secuencial de actividades, se dicen que son iterativas debido a que conllevan varias
pasadas por las seis (6) disciplinas (Conceptualizar el sistema, Requerimiento, Análisis y
Diseño, Implementación, Prueba, y Documentación), en varias proporciones dependiendo del
ciclo de desarrollo en que la iteración se localizaba, generando versiones del Sistema
(productos), cada vez más depurada.
La Disciplina de Requerimientos tiene como meta definir y delimitar la funcionalidad
del sistema. La Disciplina de Análisis comienza con el desarrollo del modelo de análisis que
toma como punto de partida la especificación de requerimientos y tiene como meta desarrollar
una estructura lógica del sistema, la cual debe ser estable, robusta, mantenible y extensible. El
análisis se enfoca en qué debe hacer el sistema, en lugar de cómo se supone que lo hará. El
modelo de análisis será un modelo prototípico para el modelo de diseño, extendiendo la
arquitectura general. La Disciplina de Implementación toma el resultado del modelo de diseño
para generar el código. La Disciplina de Prueba se ocupa principalmente de encontrar y exponer
las debilidades del producto del sistema de software. La disciplina de documentación ocurre a
lo largo del desarrollo del sistema y no como una etapa final del mismo, aunque corresponde a
esta fase presentarla como definitiva. Desde el punto de vista de un sistema, las disciplinas
constituyen las entradas, de un proceso, conformado por las actividades realizadas en las fases,
que generan los productos o artefactos [RUP; 2002].
Con base en los lineamientos RUP, el trabajo de grado se desarrolló en seis (6)
disciplinas como se esquematiza en la Figura Nº 18, en donde se muestra el orden en que
fueron ejecutadas, las actividades de cada disciplina y los productos obtenidos en cada una de
ellas. Las actividades que se desarrollaron para cada una de las tareas en las diferentes
disciplinas a lo largo de cada de una de las fases establecidas, habiéndose obtenido los
resultados planificados, como se detalla más adelante. En la Figura Nº 18 se puede apreciar
que las disciplinas interactúan de la siguiente manera: la Disciplina Conceptualizar el Sistema
obtuvo como productos la definición raíz y el modelo conceptual, este último constituyó la
entrada a la Disciplina Requerimiento. La Disciplina Requerimientos obtuvo como producto el
Modelo de Casos de Uso, que sirvieron de entrada a las Disciplinas Análisis y Diseño,
Implementación y Prueba. La Disciplina de Análisis y Diseño produjo el Modelo de Análisis,
el Prototipo de Interfaz y el Modelo de Diseño, estos constituyeron la entrada a la Disciplina
Implementación, produciendo el modelo de Implementación, el cual consistió de código fuente:
inicialmente se construyó un prototipo derivado de la concepción inicial del tesista acerca del
sistema requerido, el cual evolucionó hasta convertirse en el sistema deseado por los usuarios.
El Modelo de Implementación constituyó la entrada a las Disciplinas Prueba y Documentación.
La Disciplina Prueba obtuvo como productos los Prototipos Confrontados y el Sistema
Probado. La Disciplina Documentación produjo los manuales del Sistema; concluido el ciclo
(iteración) se hizo una nueva pasada por todas las disciplinas, refinando los productos tantas
veces como fue necesario, hasta obtener los productos definitivos.
Fig. 18 Estrategia Metodología Aplicada en el Trabajo de Grado. Para aclarar como será usado el gráfico Figura Nº 18 a lo largo de la narrativa de
aplicación de la estrategia metodológica, se introduce el siguiente ejemplo: Las actividades
• Identificar las clases de análisis mediante los casos de uso. • Diseñar las interfaces del usuario. • Modelar las relaciones entre las clases de análisis mediante
diagramas de colaboración. • Identificar las clases de diseño a partir de las clases de
análisis. • Modelar las vistas dinámicas entre clases mediante diagramas
de secuencias. • Modelar las vista estática de las clases de diseño
identificadas.
• Identificar los Actores. • Estructurar el sistema en C.U. a partir del modelo conceptual. • Describir cada Caso de Uso. • Establecer las relaciones presentes.
• Indagar sobre la Metodología de Sistemas de actividad humana.
• Conceptualizar el Sistema formulando definiciones raíz de sistemas pertinentes • Confeccionar el Modelo Conceptual sobre la base de la
definición raíz.
Sistema Probado
Inicio Elaboración Construcción Transición
• Construir un prototipo de interfaz. • Generar el código fuente: los componentes del sistema
(Evolución del prototipo hacia el sistema final)..
• Realizar pruebas de sistema. • Realizar pruebas con los usuarios.
• Elaborar la documentación del sistema. • Adriestar al personal relacionado que utilizará el sistema.
Conceptualizar el Sistema
Definición Raíz
Modelo Conceptual
Requerimiento
Modelo de Caso de Usos - Actores - Casos de Usos - Relaciones
Análisis y Diseño
Implementa-ción
Prueba
Documentación
Modelo de Análisis
Diseño de Interfaz
Modelo de Diseño
Modelo de Implementación
Prototipo Confrontado y aprobado
DISCIPLINAS
PRODUCTOS
FASES
Manuales Sistema.
desarrolladas en la Disciplina Conceptualizar el Sistema son presentadas en la fase de Inicio. A
pesar de que se realizan en varias fases, es en la fase de Inicio donde mayor peso tienen, por lo
tanto, se presentan los resultados obtenidos en esta fase, en el gráfico (Figura Nº 19) esto se
puede observar mediante un color más oscuro del fondo de la fase Inicio y la disciplina
Conceptualizar el Sistema). En otros términos, para el ejemplo anterior, en la sección que
corresponda a explicar esas actividades, se verá lo siguiente:
Fig. 19 Ejemplo de Uso para Guía para las actividades de la estrategia metodológica de desarrollo
De igual forma se seguirá con las demás fases y disciplinas, que se presentaron como
componentes de la metodología de desarrollo expuesta en la Figura Nº 18.
Una vez explicada la estrategia metodológica de desarrollo, se pasa a describir en las
próximas páginas, el detalle de como se aplicó las actividades realizadas de cada disciplina. En
cuanto a los productos obtenidos, los definitivos se van presentado a medida que se logran lo
cual se hará de manera secuencial para facilitar la lectura, en el entendido que su ejecución
siguió un ciclo iterativo (sucesivas pasadas por las disciplinas) e incremental (obtención de
productos cada vez más refinados) dentro de las actividades correspondientes.
III.1 DISCIPLINA: CONCEPTUALIZAR EL SISTEMA
Inicio
FASE
Conceptualizar el Sistema
DISCIPLINA
• Indagar sobre la Metodología de Sistemas de actividad humana.
• Conceptualizar el Sistema formulando definiciones raíz de sistemas pertinentes
• Confeccionar el Modelo Conceptual sobre la base de la definición raíz.
ACTIVIDADES
FASE DISCIPLINA ACTIVIDADES
Corresponde a la primera disciplina en el ciclo de desarrollo del sistema; la primera
actividad realizada consistió en investigar acerca de los sistemas de actividad humana o
sistemas “suaves” y la metodología para enfrentar problemas no estructurados “SSM”
(Checkland, 1993). La realización de esta investigación proporcionó al tesista conocimientos
acerca del modelaje de sistemas de actividad humana que le permitieron afrontar con éxito la
conceptualización del sistema en estudio.
Al inicio del desarrollo del proyecto se presentó una situación donde los objetivos y las
necesidades del sistema a construir no estaban bién claros, lo que hacía difícil definir el
contexto de la situación problema, este tipo de situaciones son las que enfrenta la metodología
de sistemas suaves (SSM) propuesta por Checkland(1993) y Checkland y Scholes(1994),
Para cumplir con el proposito de la Disciplina, las actividades a desarrollar se dividieron
como sigue:
Indagar sobre la Metodología de Sistemas de actividad humana.
Conceptualizar el Sistema formulando definiciones raíz de sistemas pertinentes.
Confeccionar el Modelo Conceptual sobre la base de la definición raíz.
A continuación se presenta en detalle como se desarrollaron cada una de estas actividades y
los resultados obtenidos que se lograron.
III.1.1 ACTIVIDAD 1: Indagar sobre la Metodología de Sistemas de actividad humana.
Inicio Conceptualizar el Sistema
• Indagar sobre la Metodología de Sistemas de actividad humana.
• Conceptualizar el Sistema formulando definiciones raíz de sistemas pertinentes
• Confeccionar el Modelo Conceptual sobre la base de la definición raíz.
La bibliografía consultada para indagar sobre los sistemas “suaves” fue la propuesta por
los autores Checkland(1993), Checkland y Scholes (1994). Los conocimientos adquiridos se
resumen a continuación mediante una explicación concisa de la Metodología “SSM”.
La metodología representa una secuencia cronológica de estadios mencionados a
continuación (Ver Anexo), los cuales se deben leer del 1 al 7:
1. La situación problema no estructurada.
2. La situación problema expresada.
3. Definiciones raiz de los sitemas pertinentes.
4. Modelos Conceptuales.
4a Concepto de sitema formal.
4b Otros pensamientos de sistemas.
5. Comparación de 4 con 2.
6. Cambios deseables viables.
7. Acción para mejorar la situación problema.
Los autores suministran una secuencia lógica que es más adecuada para describir la
metodología pero que no es necesario seguir para usarla. Ellos dicen que es posible iniciar un
proyecto en el estadio 4, por ejemplo, y en principio un inicio se puede hacer desde cualquier
punto. La iteración y la exploración en reversa también son esenciales.
La metodología de sistemas para enfrentar problemas no estructurados incluye dos tipos
de actividades. Los estadios 1,2,5,6, y 7 son actividades “del mundo real” que necesariamente
involucra gente en la situación problema; los estadios 3,4,4a y 4b son actividades del
“pensamiento de sistemas” que quizá pueda o no involucrar a aquellas en la situación problema,
dependiendo de las circunstancias individuales del estudio.
LOS ESTADÍOS 1 Y 2: Son una fase de “expresión” durante la cual se hace un intento
por construir la imagen más rica posible, no del “problema” sino de la situación en la cual se
percibe que hay un problema. La pauta más útil aquí consiste en que este análisis inicial se
debe hacer al registrar los elementos de estructura lenta al cambio dentro de la situación y los
elementos de proceso de cambio continuo y al formar una visión sobre cómo la estructura y el
proceso se relacionan entre sí dentro de la situación que se investiga.
Fig. 20 Los estadíos 1 y 2 (Checkland; 1993. Pág. 190)
En los análisis de sistemas “duros” el concepto expresa que existe un sistema a
ingeniarse y que éste ocupa un lugar inequívoco en una jerarquía de sistemas manifiesta. En los
sistemas “suaves”_ que incluyen la mayoría de los sistemas de actividad humana considerados
en un nivel más alto que el de las operaciones físicas _ siempre habrá muchas versiones
posibles del “sistema a ingeniarse o mejorarse”; por lo que las fronteras y objetivos del sistema
quizá sean muy probablemente imposibles de definir.
ESTADÍO 3: El objetivo es obtener una formulación explícita cuidadosamente
fraseada de la naturaleza de algunos sistemas que subsecuentemente se van a considerar como
pertinentes para mejorar la situación del problema. Esto no se puede garantizar, por supuesto,
pero la formulación siempre se puede modificar en interacciones posteriores cuando el
entendimiento se profundice. Estas definiciones en el estadio 3 se denominan “definición raíz”
con lo que se planea indicar que ellas encapsulan la naturaleza fundamental de los sistemas
elegidos.
Una definición raíz adecuada debe contener seis elementos:
1.- EL NÚCLEO: de un sistema será un proceso de transformación (t), es decir, los
medios por los cuales las entradas definidas se transforman en salidas definidas. La
transformación inclinará el objeto directo de los verbos de actividad principal que se quieren
subsecuentemente para describir el sistema.
2.- POSESIÓN (O): habrá posesión del sistema, alguna mediación que tenga un interés
primario en el sistema y el poder último para ocasionar que el sistema deje de existir. Los
poseedores pueden argumentar acerca del sistema.
3.-ACTORES (A): dentro del sistema mismo habrá actores, los agentes que llevan a
cabo las actividades principales del sistema, especialmente su transformación principal.
4.-CONSUMIDORES (C): dentro y/o sin el sistema habrá los consumidores del sistema,
que son los beneficiarios o víctimas afectadas por las actividades del sistema. Los consumidores
serán objetos indirectos de los verbos principales empleados para describir al sistema.
5.- RESTRICCIÓNES DEL MEDIO (E): son características en los medios del sistema
y/o sistemas más amplios que éste tiene que asumir como “dadas”.
6.- WELTANSCHAUUNG (w): raramente esta explícita en una definición raíz, pero
nunca se puede excluir. Habrá una (W), una perspectiva, marco o imagen que da significado a
esta definición raíz particular: Habrá por definición mas de una W posible, por supuesto; se ha
argumentado que ésta es la naturaleza de los sistemas de actividad humana. Pero, en áreas de un
sistema de pensamiento coherente, se deberá formular una definición raíz separada para cada W
que se considere pertinente, ya sea que éste la proporcione el analista mismo o la expresen las
personas en la situación problema.
A éstas seis elementos que se describen en una definición raíz bien formada se les
recordará mediante el mnemónico CATWOE. Las definiciones raíz tienen el status de hipótesis
pertinentes al mejoramiento eventual de la situación problema por medio de cambios
habilitados que tanto el analista de sistemas como los propietarios del problema les parezcan
“viables y deseables”.
“Pertinente” no implica aquí que el sistema seleccionado sea necesariamente deseable, y
ciertamente tampoco que éste sea el sistema que deba diseñar e implementar en el mundo real.
Una definición raíz debe ser una descripción concisa de un sistema de actividad humana
que capture una visión particular de éste.
Fig. 21 Estadío 3 (Checkland; 1993. Pág. 192)
ESTADÍO 4: CONFECCIÓN Y VERIFICACIÓN DE MODELOS CONCEPTUALES:
Fig. 22 Estadíos 4 (Checkland; 1993. Pág. 194)
Cualquier información raíz se puede considerar como una descripción de un grupo de
actividades humanas con propósito determinado concebido como un proceso de transformación.
Lo que se hace ahora en el estadío 4 es construir un modelo sistema de actividad necesario para
lograr la transformación descrita en la definición.
La definición es un reporte de lo que el sistema es; el modelo conceptual es un reporte
de las actividades que el sistema debe hacer para convertirse en el sistema nombrado en la
definición.
Debido a que el modelo conceptual es un modelo de un sistema de actividad, sus
elementos serán verbos. La “ técnica “ del modelo consiste en ensamblar la lista mínima de
verbos que describen las actividades que son necesarias en un sistema especificado en la
definición raíz y en estructurar los verbos en una secuencia de acuerdo a la lógica_ por
ejemplo “definir donadores potenciales” tendría que ir antes de “ubicar donadores potenciales”_
el valor principal en éste modelo que describe el núcleo de la transformación sería “transferir”.
Es mejor comenzar la construcción del modelo conceptual escribiendo no más de media
docena de verbos que describan las actividades principales implicadas en las definiciones raíz.
Algunas veces una definición combinada virtualmente bosqueja las actividades principales y
sus relaciones unas con otras, y por ello bosquejan la estructura del modelo.
Sea éste o no el caso, se han descubierto mejores maneras para determinar un modelo en
un “nivel de resolución” bajo, y de ahí expandir cada actividad importante en un nivel mas alto
de resolución.
El arte en la construcción del modelo de este tipo consiste, de hecho, en mantener
separadas las actividades más importantes del sistema y, en un modelo dado, en mantener la
consistencia del nivel de resolución.
Técnicas para construir Modelos Conceptuales:
La técnica para construir modelos conceptuales se basa en principios muy simples, un
modelo de sistema de actividad humana incluirá un grupo de actividades conectadas entre sí. El
lenguaje básico incluye a todos los verbos en el lenguaje que habla el analista. El modelo
incluirá el número mínimo de verbos necesarios para el sistema, para que sea el que se nombra
y se describe concisamente en la definición raíz. Estos tendrán que estar conectados entre sí
para que representen al sistema como si fuera una entidad, y la forma más básica que esta
conectividad podría tomar es la de un número de flechas que indican dependencias lógicas.
Donde parezca esencial el representar un flujo (ya sea de materiales, dinero, energía o
información), se debe indicar la naturaleza de dicho flujo.
El objetivo es construir un modelo de actividad de lo que debe ir en el sistema. Los
como particulares (se incluyen por ejemplo roles, estructuras organizacionales y maneras
específicas para llevar a cabo las actividades) se deben incluir solo si están nombrados
específicamente en la definición raíz. Los como por supuesto que podrían involucrarse en
modelos mas detallados subsecuentemente que se obtengan al expandir el modelo de primer
nivel.
La siguiente figura representa una indicación de tema libre de la naturaleza general de
un modelo conceptual de sistema de actividad humana. En este sistema nocional, seis
actividades conectadas constituyen un proceso de transformación que genera reportes
periódicos y requiere entradas de información. Fig. 23 Ejemplo modelo conceptual de sistema de actividad humana (Checkland; 1993. Pág. 320).
La actividad 4, que el verbo 4 describe, requiere el terminado de antemano de las
actividades 1 y 2 (verbos 1 y 2). La actividad 5 depende de la 4 y 3, y posibilita que se lleve a
cabo la actividad 6, siendo esta última el origen de la salida de sistema.
La tarea en la construcción de modelos conceptuales consiste simplemente en ensamblar
la lista de verbos que describen las actividades que la definición raíz requiere, en conectarlos
de acuerdo con los requerimientos de la lógica y en indicar cualquier flujo que parezca esencial
en este primer nivel de resolución.
Un proceso para su elaboración frecuentemente consiste en preguntar acerca de cada
actividad:
_ ¿Qué información es necesaria para llevar a cabo esta actividad?.
_ ¿A partir de qué recurso?.
_ ¿ Con qué frecuencia?.
_ ¿ En qué forma?.
En el modelo de actividad básica entonces se vuelve el origen de un modelo de flujo de
información que se puede usar para indagar sobre flujos de información presentes o para
diseñar nuevos sistemas de información.
ESTADÍO 5: COMPARACIÓN DE LOS MODELOS CONCEPTUALES CON LA
REALIDAD:
Fig. 24 Estadío 5 (Checkland; 1993. Pág. 202)
Este estadio se denomina así porque en él partes de la situación problema analizada en el
estadio 2 se examinan a la par de los modelos conceptuales: Esto se debe hacer junto con los
participantes interesados en la situación problema, con el objeto de generar un debate acerca de
posibles cambios.
Este estadio no es una comparación exactamente de igual con igual. La comparación es
el punto en el cual las percepciones intuitivas del problema se confrontan con las
construcciones de sistemas que en el pensador de sistemas asegura proporcionar una
descripción de la realidad más general y epistemológicamente mas profunda, debajo de las
apariencias superficiales.
El estado de comparación es un medio para despedazar las complejidades de la
“realidad”.
Maneras para hacer las comparaciones:
Se han identificado cuatro maneras para hacer la comparación ya que estudios de
diferentes tipos al parecer requieren de formas distintas de llevar a cabo la comparación.
1._ Utilizar los modelos de sistemas para abrir un debate acerca del cambio. Este
método para utilizar los modelos conceptuales como una base de cuestionamiento ordenado en
la situación problema siempre será una manera posible de avanzar en cualquier estudio.
2._ Reconstruir una secuencia de sucesos del pasado y al comparar lo que había
sucedido al producirlo con lo que habría sucedido si los modelos conceptuales pertinentes se
hubiesen habilitado de verdad. Esto es lógicamente una manera satisfactoria para exhibir el
significado de los modelos, y quizás las diferencias de los procesos reales.
3._Generar preguntas estratégicas muy importantes acerca de las actividades presentes
mas que las indagaciones detalladas acerca de los procedimientos; preguntas tales como: ¿Por
qué hacer esto?, más que: ¿Está esto bien hecho?.
4._ Método de “encimamiento de modelo”: Después de terminar la conceptualización
basada en la definición raíz elegida, se hace un segundo modelo, esta vez de lo “que existe”;
este segundo modelo conceptual, el objetivo es redibujar ese modelo cambiando únicamente
donde la realidad difería del modelo conceptual, esto revela cabalmente el desajuste, que es la
fuente de la discusión del cambio.
Estos cuatro métodos ayudan a asegurar que el estadio de comparación se haga con
conciencia, que sea coherente y sustentable.
ESTADIO 6 Y 7: HABILITACIÓN DE CAMBIOS
“PLAUSIBLES Y DESEABLES”
Fig. 25 Los estadíos 6 y 7 (Checkland; 1993. Pág. 206)
ESTADIO 6: En éste estadio es posible tres tipos de cambios:
Cambios de estructura: Son los cambios que hacen a aquellas partes de la realidad que a
corto plazo, en los acatables de las cosas, no cambian.
Cambios de procedimiento: Son cambios para los elementos dinámicos: los procesos de
informar y reportar, verbalmente o sobre papel, sobre todas las actividades que se llevan a cabo
dentro de las estructuras (relativamente) estáticas.
Cambios de actitud: Son cambios en características cruciales aunque intangibles que
residen en la conciencia individual y colectiva de los seres humanos en grupos, como por
ejemplo cambios en la disposición para calificar ciertos tipos de comportamiento como “bueno”
o “malo”. Es esencial y principal el monitorear continuamente las “actitudes” si es que se van
a hacer cambios en las situaciones percibidas como problemas de forma que los actores
involucrados en la situación estén de acuerdo de que se ha logrado una “mejoría”.
El propósito del estadio 6 consiste en usar la comparación entre los modelos
conceptuales y “lo que es”, para generar la discusión de los cambios de cualquiera de los tres
tipos descritos anteriormente.
El debate acerca del cambio llevado a cabo en el mundo real del problema con los
“actores involucrado”, tiene como objetivo, el definir los cambios que satisfagan dos criterios.
Ellos deben ser sistemáticamente deseables (cosa argumentable) como resultado del
discernimiento obtenido a partir de la selección de definiciones raíz y de la construcción del
modelo conceptual, y deben ser también culturalmente plausible dadas las características de la
situación, la gente en ella, sus experiencias compartidas y sus prejuicios.
ESTADIO 7: IMPLANTACIÓN DE CAMBIOS:
Una vez que se ha acordado los cambios, la habilitación de ellos quizá sea inmediato. O
su introducción, quizá cambie la situación de forma que aunque el problema generalmente
percibido ha sido eliminado, emergen nuevos problemas. La metodología no ha emergido como
un enfoque único y para siempre de algo definido exactamente como “un problema”, sino como
una manera general para llevar a cabo actividad con propósito que obtiene algo a partir del
poder del pensamiento de sistema formal, pero que al mismo tiempo no requiere que los seres
humanos individuales se comporten como si fueran autómatas racionales.
Aplicación de la Metodología al Caso de Estudio:
Debido a la flexibilidad que ofrece la metodología de permitir que se inicie un proyecto
en cualquiera de las siete etapas o “estadíos” que la conforman, lo cual se aprovechó para
utilizar el Estadío 3 “Definiciones raíz de sistemas pertinentes”, a fin de concebir una
definición de la naturaleza del sistema que se consideraría como pertinente para mejorar la
situación problema. Las formulaciones de las definiciones (definición raíz) se modificaron a
medida que el entendimiento del sistema se profundizó. Posteriormente se aplicó el Estadío 4a:
“Confección de modelos conceptuales” a fin de construir un modelo de “las actividades que el
sistema debe hacer” donde se describieron las actividades necesarias requeridas por el sistema,
mediante un grupo estructurado de verbos, denominado modelo conceptual de la definición
raíz. A continuación se explican como fueron ejecutadas estas actividades:
III.1.2 ACTIVIDAD 2: Conceptualizar el Sistema formulando definiciones raíz de sistemas pertinentes.
Esta actividad, siguiendo a los autores, consistió en nombrar un sistema que pudiera ser
pertinente al problema en estudio, y preparar una definición de lo que el sistema es, a través de
una formulación cuidadosamente fraseada del sistema que pudiera ser pertinente para mejorar
la situación problema, esta definición denominada “definición raíz”, encapsula la naturaleza
fundamental del sistema elegido.
Las definiciones raíz tienen el status de hipótesis pertinentes al mejoramiento eventual
de la situación problema por medio de cambios habilitados que tanto el analista de sistemas
como a los propietarios del sistema les parezcan “viables y deseables” [Checkland; 1993].
La construcción de la definición raíz se basó inicialmente en la intuición y experiencia
del tesista, la formulación se fue modificando producto de la iteracción con los usuarios del
sistema en estudio, y a medida que el entendimiento sobre el problema se fue incrementando.
A continuación se muestra la primera definición raíz junto a su revisión sobre la base de
los elementos CATWOE (Ver III.1.1 estadio 3), formulada para el SISTEMA GENERADOR
DEL CURSO INTRODUCTORIO. En ella se refleja la perspectiva del tesista y sus tutores
acerca del “deber ser” de dicho sistema.
Primera definición raíz.
“Es un sistema de la Universidad Nacional Abierta, que interactúa con el
personal académico responsable del contenido del Curso Introductorio para generar
un Libro Virtual”.
Esta perspectiva inicial del sistema bajo estudio, se fue ampliando progresivamente a
través de los resultados que se fueron obteniendo en la confrontación de los prototipos en la
Disciplina Prueba, los cuales se aplicaron para realizar sucesivos refinamientos de la definición
raíz inicial, hasta llegar a la definición raíz definitiva, que refleja lo que perciben y piensan los
actores participantes con respecto al “deber ser” del SISTEMA GENERADOR DEL CURSO
INTRODUCTORIO:
Definición raíz definitiva;
“Es un sistema de la Universidad Nacional Abierta, que interactúa con el
personal académico responsable del contenido del Curso Introductorio para apoyarlos
tecnológicamente, aplicando recursos Multimedia, en la Generación y actualización
del Curso Virtual dirigido a todos los estudiantes que inician estudios en la
Universidad”.
Una revisión de la estructura de la “definición raíz inicial” mediante un examen de los
elementos CATWOE (Ver III.1.1 estadio 3), revela lo siguiente:
La transformación (T) está dada por la conversión de la ausencia de soporte tecnológico
que permitiera mantener actualizados los contenidos del Curso Introductorio, al total soporte
tecnológico que utilizando recursos multimedia, facilita al personal académico responsable (Ver
Figura 26):
1- La organización e integración de contenidos previamente digitalizados.
2- Almacenamiento en CD para los estudiantes
Los actores (A) están constituidos por Personal Académico y Técnico.
Los clientes (C) están conformados por una parte por los integrantes del Personal
Académico responsables de producir los contenidos del Curso Introductorio y por otra parte,
son también beneficiarios de este sistema los estudiantes que dispondrán de un Curso Virtual
actualizado y los profesores que asesoran las asignaturas.
El propietario (O) del sistema es la Universidad Nacional Abierta.
La restricción del medio (E) representada por las limitaciones de tiempo y
disponibilidad del personal para generar y mantener actualizado los contenidos del Curso
Introductorio, y por la tecnología disponible para soportar la generación del Curso Virtual.
La Weltanschauung (W) de la definición expresa que es un sistema que interactúa con el
personal responsable del Curso Introductorio a fin de apoyarlos tecnológicamente en la
elaboración y mantenimiento de los contenidos del Curso Introductorio.
Fig. 26 Transformación que ejecuta el Sistema Generador (Elaborado por el tesista)
III.1.3. ACTIVIDAD 3: Confeccionar y Verificar un Modelo Conceptual.
Las definiciones raíz involucran el nombrar algunos sistemas que parece pudieran ser
pertinentes al problema en estudio y el preparar definiciones concisas de lo que éstos sistemas
“son” en contraposición a lo “que” ellos hacen [Checkland; 1993].
La elaboración del Modelo Conceptual se llevó acabo de la siguiente manera:
1. Se identificaron los verbos presentes en la definición raíz que
describían las actividades necesarias en el sistema especificado por la
definición.
Verbos: Administrar - Generar
Personal Responsable de
Contenido. Contenidos previamente digitalizados (imágenes, vídeo, texto)
SISTEMA GENERADOR
Curso Introductorio Virtual almacenado en CD
ENTRADA TRANSFORMACIÓN SALIDA
2. El Modelo Conceptual se construyó estructurando los verbos en una secuencia
lógica y colocando las actividades que se consideraron necesarias en el sistema
especificado en la definición raíz.
Para cada definición raíz obtenida se elaboró el Modelo Conceptual, a través de
reiteradas confrontaciones con las personas interesadas en la situación problema, tal como se
mencionó en la actividad anterior, se fue refinando la definición raíz y el Modelo Conceptual
hasta llegar al Modelo Conceptual de la definición raíz definitiva que se presenta en la Figura
27.
La Figura Nº 27, que se muestra a continuación
representa una indicación de la naturaleza del Modelo
Conceptual del SISTEMA PARA DAR SOPORTE EN LA GENERACIÓN DEL
CONTENIDO DEL CURSO INTRODUCTORIO. En este sistema, cuatro (4) actividades (lista
de verbos que describen las actividades de la definición raíz) conectadas de acuerdo a los
requerimientos de la lógica, constituyeron un proceso de transformación. Cada actividad del
Modelo Conceptual constituyó un subsistema del GENERADOR DEL CURSO, dichos
subsistemas fueron la base para generar los Casos de Usos en la disciplina requerimientos,
explicada más adelante.
Los subsistemas del SISTEMA GENERADOR definidos a partir del Modelo Conceptual
fueron:
• Subsistema Administrar aspectos técnicos.
• Subsistema Administrar contenido.
• Subsistema Generar el Curso Multimedia.
• Subsistema Generar Estructura y Test de Evaluación.
Fig. 27 Modelo Conceptual Del Generador del Curso Introductorio.
III.2 DISCIPLINA: REQUERIMIENTOS
Esta disciplina es de vital importancia ya que las disciplinas restantes se desarrollan a
partir de ella, tiene como función delimitar y definir la funcionalidad del sistema. El desafío de
Elaboración
FASE
Requerimiento
DISCIPLINA
• Identificar los actores. • Estructurar el sistema en Casos de Usos a partir
del modelo conceptual. • Describir cada Caso de Uso. • Establecer las relaciones presentes.
ACTIVIDADES
la especificación de los requerimientos comienza al momento de comunicar los conceptos, lo
cual no es generalmente posible de hacer adecuadamente por medio de una simple expresión.
La especificación de los requerimientos es particularmente difícil cuando la información es
incompleta, los expertos no pueden articular lo que saben, o no están seguros o incluso son
incoherentes sobre su conocimiento o creencias. [RUP; 1999].
Una meta importante fue entender el problema que se intentaba resolver con este
sistema identificando las personas involucradas, recogiendo y analizando sus demandas. El
Modelo de Caso de Uso especificó la funcionalidad del Sistema desde la perspectiva del usuario
y definió que debía hacer el sistema sobre la base del Modelo Conceptual construido, a través
de los Casos de Uso, Actores, descripciones de cada uno de ellos y sus relaciones.
Cada Caso de Uso describe paso a paso cómo el sistema actúa recíprocamente con los
actores, y lo que el sistema hace en el Caso de Uso [RUP; 1999]. Los Casos de Uso funcionaron
como un hilo unificándose a lo largo del ciclo de vida del sistema; el mismo Modelo de Caso de
Uso se usó en el análisis, diseño, implementación y prueba del sistema, como se puede apreciar
en la explicación de cada disciplina más adelante.
Para cumplir con el propósito o meta de la disciplina de requerimientos se desarrollan
una serie de actividades para determinar las necesidades de los usuarios, los productos fueron
obtenidos progresivamente en cada iteración del ciclo de desarrollo del sistema, a continuación
se nombran y explican cada una de las actividades realizadas en esta disciplina:
Identificar los Actores. Identificar los Casos de Usos. Documentar los Casos de Uso. Establecer las relaciones presentes.
III.2.1. ACTIVIDAD 1: Identificar los Actores.
Un actor es algo que intercambia datos con el sistema. Un actor puede ser un usuario,
hardware externo, u otro sistema. La diferencia entre un actor y un usuario del sistema
individual es que un actor representa una clase particular de usuario o un rol que cumple un
usuario en lugar de un usuario real. Varios usuarios pueden jugar el mismo rol que significa que
ellos pueden ser uno y el mismo actor [UML; 1999].
En el caso del sistema en estudio se identificó qué grupos requerían soporte para llevar
a cabo sus actividades, el personal encargado del Diseño Curricular del Curso facilitó la labor
en la identificación de los usuarios y la organización en categorías para representar tipos de
actores. Se observó que existía un grupo de usuarios que jugaban diversos roles, así como
actores que aparecen repetidos en varios subsistemas (Ver Modelo Conceptual, Punto III.1.3),
sin que esto signifique que sean roles diferentes, además los nombres se establecieron de
manera de comunicar la semántica deseada y se realizó una descripción que esboza sus
necesidades y responsabilidades. En la Tabla N° 1 se muestra la lista de los actores
identificados en cada subsistema del Modelo Conceptual. A continuación se procede a dar una
breve descripción de los mismos:
Personal Contenido: Corresponde al personal académico de la Universidad Nacional
Abierta que conforma el equipo de producción del Curso Introductorio, encargado de ensamblar
la estructura, generar y digitalizar los contenidos, así como elaborar los Test de Evaluación del
Curso.
Supervisor Contenido: Corresponde al Coordinador del equipo, encargado de revisar y
aprobar el contenido del Curso Introductorio.
Supervisor Técnico: personal encargado de asignar las claves de seguridad, de acuerdo
al perfil del usuario del Generador Curso Introductorio, y efectuar un seguimiento en el proceso
de construcción de cada Unidad del Curso.
Lista de Actores Subsistemas con el que interactúa
Supervisor Técnico Administrar aspectos técnicos Generar el Curso Multimedia
Supervisor Contenido Administrar contenido
Personal Contenido Generar Estructura y Test de Evaluación
Tabla 1 Lista de Actores
III.2.2. ACTIVIDAD 2: Identificar los Casos de Uso. Mediante esta actividad se profundizó en las posibles funcionalidades, extraídas
inicialmente del Modelo Conceptual (Ver Punto III.1.3). A continuación se describe la manera
como se llevó a cabo esta actividad.
Para realizar la identificación de los Casos de Uso se analizó cada actividad
(subsistema) del Modelo Conceptual, es decir, para cada subsistema se generaron un conjunto
de Casos de Uso, que permitieron cumplir con los requerimientos de los actores y además se
establecieron las relaciones que permitieron a actores y Casos de Uso conseguir como un todo,
lo que el sistema debía hacer basándose en lo planteado por la Definición Raíz.
Las actividades del Modelo Conceptual describieron los requerimientos necesarios del
sistema, posteriormente en un análisis más detenido y a través de la confrontación de los
prototipos se reestructuró la definición de los Casos de Uso identificados al inicio.
Los Casos de Uso fueron interpretados dentro del contexto del sistema, repasando los
actores uno por uno y proponiendo los Casos de Uso para soportar su trabajo, determinando que
por cada actor identificado existiese por lo menos un Caso de Uso adecuado a sus necesidades.
A través de todas las consideraciones anteriores se logró estructurar el sistema
identificando los Casos de Uso, y procediendo a distribuirlos para cada uno de los subsistemas
del Modelo Conceptual, construyendo así el Modelo de Casos de Uso.
A continuación se muestran (Tabla N° 2) los Casos de Usos identificados en relación
con cada uno de los subsistemas del Modelo Conceptual, se eligió un nombre para cada Caso de
Uso de forma que hiciera pensar en la secuencia de acciones concreta que añade valor a un
actor, el verbo refleja el objetivo de la interacción entre el actor y el sistema.
Es importante destacar, tal como se mencionó anteriormente, que para lograr los
objetivos del sistema con base en la Definición Raíz, se establecieron relaciones (interacciones)
entre los subsistemas (Ver punto III.1.3), ya que de lo contrario tendríamos solo un grupo de
partes (subsistemas) aisladas.
Lista de Casos de Uso En relación al subsistema Administrar aspectos técnicos
• Entrar al Sistema (acceso al sistema a través de una clave de entrada). • Mostrar Visor Configuración (efectuar un seguimiento a los archivos asociados
Esquema (índice) de Contenido). • Administrar Claves (efectuar mantenimiento a las claves de seguridad). • Modificar Estructura del Directorio (efectuar mantenimiento a las carpetas
componentes del sistema).
Tabla 2 Lista de Casos de Uso
En relación al subsistema Administrar contenido • Elaborar Test (establecer las preguntas y respuestas de los Test de Evaluación
Curso). • Entrar al Sistema. • Mostrar Visor Configuración. • Ver Visor Contenido (observar los videos, imágenes, test y textos para aproba
rechazar los contenidos del Curso). En relación al subsistema Generar Estructura y Test de Evaluación
• Entrar al Sistema. • Generar Esquema. (ensamblar el Esquema (índice) del contenido del Curso) • Adjuntar Archivos (vincula cada archivo creado por aplicaciones externas al Esque
de Contenido). • Elaborar Test. • Añadir Archivo a Vincular (buscar y adjuntar archivo al Esquema). • Ver Archivos con Observaciones (visualizar archivos de textos que deben
corregidos). En relación al subsistema Generar el Curso Multimedia
• Entrar al Curso (Iniciar el estudio del Curso Multimedia). • Mostrar Esquema del Módulo (seleccionar elemento del Esquema de Contenido). • Mostrar Contenido Informativo (Observar los archivos asociados al elemento
Esquema de Contenido). • Mostrar Vídeos (Observar los videos del Curso). • Buscar Archivos Asociados (ubicar los archivos vinculados al elemento del Esque
Seleccionado). • Mostrar Test de Evaluación (para medir el aprendizaje al estudiante). • Mostrar Examen (buscar preguntas y respuestas según el elemento del Esque
seleccionado. • Iniciar Corrección (mostrar las opciones correctas del Test de Evaluación). • Mostrar Resultado (mostrar resultado de la evaluación). • Imprimir Página (visualizar en formato impreso opción seleccionada. • Buscar Ayuda (ubicar ayuda que se ajusta a la página seleccionada por el usuario). • Mostrar Ayuda (visualizar ayuda que se ajusta a la página seleccionada por el usuario
Tabla 2 Lista de Casos de Uso (Continuación)
III.2.3. ACTIVIDAD 3: Documentar los Casos de Uso.
Parte fundamental del Modelo de Casos de Uso es la descripción textual detallada de
cada uno de los Casos de Uso identificados. Estos documentos son sumamente críticos ya que a
partir de estos se desarrolló el sistema completo Las descripciones de los Casos de Uso
representan todas las posibles interacciones (relaciones) de los actores con el sistema,
basándose en eventos enviados por los actores al sistema o recibidos por los actores como
respuesta del sistema [RUP; 1999].
Una vez identificados los actores del sistema y los posibles Casos de Uso resaltando que
los productos fueron obtenidos progresivamente en cada iteración del ciclo de vida del
desarrollo del sistema, se procedió a describir los Casos de Uso. En esta etapa tal como indica
el RUP, no se incluyeron eventos internos al propio sistema ya que hubieran agregado
complejidad innecesaria, estos fueron tratados durante el análisis. Para realizar la descripción
detallada de cada Caso de Uso, se empleó un documento narrativo cuyo formato se muestra en
la tabla N° 3, cuya primera columna presenta los aspectos a describirse y la segunda columna
las descripciones correspondientes.
Nombre Cada Caso de Uso debe tener un nombre que indica lo que se logra por
interacción con el(los) actor(es) Descripción breve La breve descripción del Caso de Uso debe reflejar su propósito.
escribir la descripción, debe referirse a los actores involucrados en el cde uso.
Flujo principal El flujo básico de eventos que debe cubrir lo que "normalmente" pcuando el caso de uso se ha realizado
Flujo alternativo Los flujos alternativos de eventos cubren comportamientos de carácoptativo o excepcional respecto a la conducta normal, y también variaciones de la conducta normal
Pre-condición Una condición previa es una restricción cuando un Caso de Uso puempezar. No es el evento que empieza el caso de uso.
Post-condiciones Una condición posterior para un Caso de Uso que debe ser verdad tener en cuenta que se ejecutaron los flujos alternativos; sólo no debe verdad para el flujo principal
Tabla 3 Formato para documentar Casos de Uso, donde los aspectos a describirse corresponden a un subconjunto de los sugeridos por el RUP
A continuación se muestra el detalle del Caso de Uso Generar Esquema (Ver Tabla Nº
4) que forma parte del Modelo de Caso de Uso del sistema, la descripción de los restantes
Casos de Uso del Sistema, se incluyen en el Apéndice A.
Nombre Generar Esquema Descripción breve Permite al Actor Personal Contenido ensamblar el Esquema (índice) de Contenido de
Curso Multimedia. Flujo principal 1. El caso de uso se inicia cuando el sistema encuentra el Componente asociado co
clave ingresada por el Actor. 2. El sistema responde mostrando una pantalla, la cual le permite al Actor:
2.1. Cambiar el nombre de un elemento del Esquema. 2.2. Insertar, o eliminar el elemento del Esquema. 2.3. Disminuir, o aumentar el nivel del elemento del Esquema. 2.4. Subir o bajar el elemento del Esquema una posición. 2.5. Ir al Siguiente Paso del Asistente. 2.6. Cancelar los cambios realizados. 2.7. Obtener Ayuda. 2.8. Seleccionar un elemento del Esquema de Contenido.
3. El Actor efectúa una acción en el sistema seleccionando una opción. 4. El sistema responde evaluando la acción efectuada por el actor 4.1. En Caso que la opción seleccionada sea Eliminar, Disminuir un nivel, Aumentun nivel, Subir elemento, o Bajar elemento. 4.1.1. El sistema verifica que un elemento del Esquema de Contenido esté seleccionado. 4.1.2. Si la opción es Eliminar, el sistema elimina el elemento del Esquema
Contenido seleccionado junto con todos los archivos asociados. 4.1.3. Si la opción es Disminuir o Aumentar un nivel, el sistema elimina un espa
de indentación a la izquierda o agrega un espacio de indentación a la dererespectivamente del elemento del Esquema de Contenido que ha sido selecciona
4.1.4. Si la opción es Subir elemento, el sistema mueve el elemento del Esque
seleccionado a la posición anterior. 4.1.5. Si la opción es Bajar elemento, el sistema mueve el elemento seleccionad
la siguiente posición. 4.2. En Caso contrario si la opción seleccionada es Renombrar, o Insertar.
4.2.1. El sistema verifica que el actor haya escrito el nombre del elemento del Esquema de Contenido.
4.2.2. El sistema verifica que un elemento del Esquema de Contenido eseleccionado.
4.2.3. Si la opción es Renombrar, el sistema actualiza el nombre del elemento Esquema de Contenido.
4.2.4. Si la opción es Insertar, el sistema inserta un nuevo elemento del Esquede Contenido.
4.3. Si selecciona la opción Siguiente Paso, se activa el Caso de Uso Adjuntar Archivos.
4.4.. Si la opción seleccionada es Ayuda se activa el Caso de Uso Mostrar Ayuda. 5. El Caso de Uso retorna al punto 2.
Flujo alternativo 4. Si el Actor selecciona la opción Cancelar, el sistema responde cerrando la ventanacaso de uso finaliza.
Pre-condición Post-condiciones
Tabla 4. Caso de Uso Generar Esquema El propósito de la descripción inicial de Casos de Uso fue la construcción de un
prototipo evolutivo, que bajo la concepción del tesista, mostraba lo que se pensó debería hacer
el sistema. La confrontación con los usuarios permitió efectuar ajustes a los Casos de Usos
existentes, y describir los nuevos Casos de Uso, logrando la evolución del prototipo hacia la
versión definitiva en sucesivas iteraciones.
Una vez descritos los Casos de Uso, se identificaron las relaciones entre Casos de Uso y entre éstos y los
actores, siguiendo los lineamientos reflejados en el Marco Teórico de este trabajo, como se explica a continuación:
III.2.4. ACTIVIDAD 4: Establecer las relaciones presentes.
En esta actividad se elaboraron los diagramas de Casos de Uso que ilustró cómo un
Caso de Uso relaciona a actores y otros Casos de Uso modelando el comportamiento del
sistema, siguiendo los criterios de la UML(1999) y el RUP(2002). Los diagramas agruparon los
requerimientos funcionales del sistema, y sirvieron de entrada a las Disciplinas de Análisis y
Diseño.
Los Casos de Uso se agruparon en subsistemas según el Modelo Conceptual (Ver punto
III.1.3) para facilitar su comprensión, y formar una especificación de funcionalidad completa.
Los Diagramas se fueron completando y estructurando en iteraciones sucesivas, mediante los
siguientes pasos:
1. Se identificaron las relaciones entre los actores y los subsistemas según el Modelo
Conceptual (Ver Punto III.1.3), tomando en cuenta los siguientes criterios:
La asociación de comunicación es una asociación entre una clase de actor y una clase de
Caso de Uso, indicando que sus instancias interactúan. Los Casos de Uso y actores actúan
recíprocamente enviándose señales entre sí. Para indicar tales interacciones se usan las
asociaciones de comunicación entre el Caso de Uso y el actor [UML; 1999].
Un Caso de Uso tiene a lo sumo una asociación de comunicación con un actor específico, y
un actor tiene a lo sumo una asociación de comunicación con un Caso de Uso específico, no
importa cuántas señales trasmitidas hay. La red completa de tales asociaciones es un cuadro
estático de la comunicación entre el sistema y su ambiente [RUP; 2002].
2. Se plasmaron las relaciones entre Casos de Uso, mediante los siguientes criterios:
La relación de extensión es una relación de un Caso de Uso a un Caso de Uso base,
especificando cómo la conducta definida para el Caso de Uso de extensión puede insertarse en
la conducta definida para el Caso de Uso base. Se inserta implícitamente en el sentido que la
extensión no se muestra en el Caso de Uso base [UML; 1999].
Se puede usar las extensiones para varios propósitos [RUP; 2002]:
Para mostrar que una parte de un caso de uso es opcional, o potencialmente opcional la
conducta del sistema. De esta manera, se separa la conducta opcional de la conducta
obligatoria en su modelo.
Para mostrar que un subflujo sólo se ejecuta bajo ciertas (a veces excepcional) condiciones,
como activar una alarma.
Para mostrar que puede haber un conjunto de segmentos de conducta, de las cuáles, algunas
pueden insertarse en un punto de extensión en un Caso de Uso base. Los segmentos de
conducta que se insertan (y el orden en que ellos se insertan) dependerá de la interacción
con los actores durante la ejecución del Caso de Uso base.
Se puede usar la relación de inclusión como factor fuera de la conducta del Caso de Uso
base que no es necesaria para la comprensión del propósito primario del Caso de Uso, sólo el
resultado de él es importante. Factor fuera de la conducta que es en común para dos o más casos
de uso [RUP; 2002].
A continuación se muestran los diagramas resultantes:
Fig. 28 Diagrama de Casos de Uso del Subsistema Administrar Contenido
Fig. 29 Diagrama de Casos de Uso del Subsistema Administrar Aspectos Técnicos
Fig. 30 Diagrama de Casos de Uso del Subsistema Generar Estructura y Test de Evaluación
Fig. 31 Diagrama de Casos de Uso del Subsistema Generar el Curso Multimedia III.3 DISCIPLINAS: ANÁLISIS Y DISEÑO
El propósito fundamental del Análisis y Diseño consistió en modelar el sistema y encontrar su forma, construyendo una arquitectura estable, robusta, mantenible y extensible, que soporte todos los requerimientos. Tomó como punto de partida los requerimientos funcionales y específicamente el Modelo de Casos de Uso.
El Análisis se enfocó en qué debe hacer el sistema, permitió una especificación más precisa
de los requerimientos, un mayor formalismo debido a que emplea el lenguaje de los desarrolladores, y estructura los requerimientos de modo de facilitar su comprensión, preparación, modificación y mantenimiento.
Los productos obtenidos en la Disciplina de Análisis constituyeron un Modelo base para el Diseño, extendiendo la arquitectura general. Este refinamiento se debió a dos razones principales:
• Para llegar al código final se refinaron las estructuras de la arquitectura general del Modelo de Análisis, especificando las operaciones que deben utilizarse, eventos, comunicación entre clases, entre otros.
Elaboración
FASE
Análisis y Diseño.
DISCIPLINA
• Identificar las clases de análisis mediante los Casos de Uso.
• Diseñar las interfaces del usuario. • Modelar las relaciones entre las clases de análisis
mediante diagramas de colaboración. • Identificar las clases de diseño a partir de las clases
de análisis. • Modelar las vistas dinámicas entre clases mediante
Diagramas de Secuencias. • Modelar las vista estática de las clases de diseño
identificadas. • Construir el diccionario de clases del sistema
ACTIVIDADES
• Entre otros aspectos, se consideraron los requerimientos de rendimiento, aspectos de
tiempo real, concurrencia, propiedades del lenguaje de programación, entre otros, adaptando el Modelo de Análisis al ambiente de implementación del sistema.
El Diseño se acercó más al código final conservando la estructura impuesta por el Análisis.
Los productos de la Disciplina de Análisis y Diseño se obtuvieron progresivamente en cada iteracción del desarrollo del sistema. A continuación se explica como se llevaron a cabo las siguientes actividades para cumplir con el propósito de la Disciplina Análisis y Diseño:
Identificar las clases de Análisis presentes en los Casos de Uso. Diseñar las interfaces del usuario sobre la base de las clases de interfaz identificadas para
cada Caso de Uso. Modelar las relaciones entre las clases de Análisis mediante Diagramas de Colaboración Identificar las clases de Diseño a partir de las clases de Análisis. Modelar las vistas dinámicas entre clases mediante Diagramas de Secuencias. Modelar la vista estática de las clases de Diseño identificadas para cada Caso de Uso y para
cada subsistema. Construir el diccionario de clases del sistema.
III.3.1 ACTIVIDAD 1: Identificar las clases de Análisis mediante los Casos de Uso En esta actividad se identificaron las clases de Análisis necesarias para realizar los
Casos de Uso, describiendo su rol y responsabilidades. Las clases de Análisis se utilizaron para
capturar las responsabilidades en el sistema, dando lugar a las abstracciones para el Diseño del
sistema: las clases de diseño.
La forma como se identificaron las clases de Análisis se describe a continuación:
Se analizó cuidadosamente la narrativa de cada Caso de Uso, identificando las frases que
permitieran identificar los objetos.
Se elaboró una lista de posibles clases de Análisis para cada Caso de Uso, eliminando las
clases redundantes.
Para clasificar las clases de Análisis en uno de los tres estereotipos: de Interfaz, de Control
o de Entidad (Ver estereotipos de clases de Análisis, Capítulo I), se tomaron en cuenta los
siguientes aspectos:
Las clases que permitieron la interacción entre el sistema y sus actores, que implicó
recibir (y presentar) información y peticiones de (y hacia) los usuarios, se identificaron como
clases de interfaz, describiendo la información y las peticiones que se intercambian entre el
sistema y sus actores.
Las clases que modelaban la información persistente de larga duración se identificaron
como clases de entidad.
Las clases que representaban derivaciones y cálculos complejos, coordinación,
secuencia, transacciones, y control de otros objetos, que no podían asociarse con ninguna
información concreta, de larga duración, almacenada por el sistema se identificaron como
clases de control.
Como primera aproximación se repartieron los comportamiento entre las clases Interfaz y
Entidad para cada Caso de Uso, luego se analizó si existía un comportamiento el cual
involucraba procedimientos, tareas, cálculos u operaciones que significaban un proceso y
que no se podía asignar de forma natural a ninguna de las clases Interfaz y Entidad, el
comportamiento que resultaba demasiado complicado se asignó como una clase Control.
De esta manera se obtuvo un esbozo de las clases necesarias para llevar a delante los Casos
de Uso del sistema. A continuación en la Tabla Nº 5 se presenta las clases de análisis que
fueron identificadas para el Caso de Uso Generar Esquema (detallado anteriormente en la
disciplina de requerimientos), clasificadas de acuerdos a los estereotipos Interfaz, Entidad y
Control, la totalidad de las clases de análisis se encuentran en el apéndice B, a continuación del
Caso de Uso respectivo.
Nombre de la Clases de Análisis Descripción
Interfaz Esquema Interfaz Es responsable de permitir el ensamble
Esquema de Contenido del Curso Multimedia. Nombre de la Clases de Análisis Descripción
Control Esquema Control Es responsable de proveer los procesos necesa
para permitir la modificación, eliminacinserción, organización y búsqueda de un deelemento del Esquema de Contenido.
Nombre de la Clases de Análisis Descripción Entidad
Componente Entidad Es responsable de mantener la información dedescripción y archivos asociados de cada elemedel Esquema de Contenido.
Tabla 5 Clases de Análisis identificadas Caso de Uso Generar Esquema
Luego de haber identificado las clases de Análisis, en especial las clases interfaz, que
como se mencionó corresponden a las interfaces de usuario, se presenta en el siguiente
apartado como se llevó a cabo la actividad que precisamente consistió en concebir dichas
interfaces.
III.3.2 ACTIVIDAD 2: Diseñar las interfaces del usuario.
Diseñar las interfaces es describir como se presenta la información entre los actores y el
sistema. Se especifica en detalle como son vistas las interfaces de usuario al ejecutar cada uno
de los Casos de Uso. Es de hacer notar, que un Caso de Uso puede estar relacionado a más de
una interfaz de usuario, y viceversa, es decir, una interfaz puede relacionarse a varios Casos de
Uso, además, un Caso de Uso puede no estar ligado a alguna interfaz, ya que su funcionalidad
no requiere de ella, no actúa directamente con el actor, o solo se relaciona con otro Caso de Uso
[RUP; 1999].
Un prototipo (Ver Capítulo I) funcional de las interfaces de usuario constituyó una
estrategia importante, esto ayudó al usuario a visualizar los Casos de Uso, mostrando la
funcionalidad del sistema a ser construido, eliminando muchas posibilidades de malos
entendimientos.
Al comienzo en el desarrollo del proyecto, no se contaba con ninguna interfaz por lo
que las consideraciones iniciales para su construcción estaban basadas en la definición raíz.
Posteriormente fue esencial tener a los usuarios involucrados (personal académico encargado
del diseño curricular del Curso Introductorio) en el diseño de las interfaces, reflejando la visión
lógica del sistema logrando la consistencia entre la imagen conceptual del usuario y el
comportamiento real del sistema. Estas descripciones de interfaces fueron parte esencial de las
descripciones de los Casos de Uso por lo tanto las acompaña, a continuación se presenta la
interfaz del Caso de Uso Generar Esquema:
Fig. 32 Interfaz del Caso de Uso Generar Esquema
Las interfaces obtenidas para el proyecto en las primeras faces (Inicio y Elaboración),
se diseñaron pensando en los requerimientos de los usuarios, así como en la facilidad de uso,
facilidad de encontrar y utilizar sus contenidos, facilidades en crear un entorno agradable
utilizando adecuadamente los colores, tipos de letras, en la rapidez del acceso al formulario,
como aspectos importantes.
Las consideraciones en cuanto al diseño, facilidad de uso y navegabilidad de las
interfaces (Ver Tabla Nº 6), no desvirtuó el objetivo principal, cubrir los requerimientos del
usuario. Los fundamentos que permitieron obtener los criterios de usabilidad, se basaron en
los estudios realizados por Jacob Nielsen, los cuales aconseja seguir ciertos lineamientos o
reglas, que brindan la mayor satisfacción al usuario (Ver Capítulo I).
Consideraciones en la construcción y/o modificación de las Interfaces de Usuario • Utilización de Colores Suaves (pasteles). • Proporcionar un buen contraste con el fondo para mayor legalidad de los datos en el
caso de formularios. • Proporcionar una pantalla inicial maestro que permite acceder a la funcionalidades de
sistema. • No utilizar imágenes con colores fuertes y/o animadas. • Utilizar un tipo de letra común (Times New Roman, Arial y Verdana). • No utilizar términos desconocidos o rebuscados. • No utilizar demasiadas operaciones conjuntas que maximicen el consumo de memori• No mantener demasiados objetos o componentes activos en memoria. • Proporcionar ayuda en los tópicos más complicados
Tabla 6 Consideraciones en la construcción y/o modificación de las Interfaces de Usuario
Las interfaces operativas finales de este proyecto se presentan en conjunto con la
descripción de los Casos de Uso en el Apéndice A. Las consideraciones antes mencionadas, el
uso de prototipos y teniendo en cuenta que es necesario satisfacer los requerimientos de los
usuarios, se logró obtener interfaces útiles, sencillas y agradables al usuario facilitando su
trabajo.
En la siguiente sección se explica como las clases de Análisis identificadas una vez
instanciadas colaboran para lograr la realización de los Casos de Uso.
III.3.3 ACTIVIDAD 3: Modelar las relaciones entre las clases de Análisis mediante Diagramas de Colaboración.
Un Diagrama de Colaboración describe un modelo de interacción entre objetos, es decir,
muestra como interaccionan los objetos que participan a través de vínculos y los mensajes que
se envían entre ellos. Es necesario aclarar que en los Diagramas se habla de objetos, es decir,
instancias de las clases de Análisis ya identificadas, esto debido a que el objetivo principal es
ver como colaboran los objetos para la realización del Caso de Uso [RUP; 1999].
Luego de haber identificado las clases de Análisis para cada Caso de Uso, se describió
como interactúan los objetos instancias de estas clases a través de los Diagramas de
Colaboración, identificando los diferentes roles y responsabilidades de los objetos con respecto
al sistema.
Los Diagramas de Colaboración representaron una herramienta para detectar la
cobertura de las responsabilidades de las clases de Análisis para la realización del Caso de Uso
correspondiente.
Solo se elaboraron Diagramas de Colaboración que aportaban información de interés al
Diseño. Los Diagramas de colaboración se inician cuando el actor invoca al Caso de Uso a
través de algún mensaje, un objeto interfaz recibirá este mensaje y enviará a su vez un mensaje
a algún otro objeto, y de esta forma los objetos interaccionan para llevar a cabo el Caso de Uso
creando enlaces entre ellos y añadiendo mensajes a esos enlaces, denotando el propósito del
objeto invocante en la interacción con el objeto invocado.
A continuación en la Figura Nº 33, se presenta el Diagrama de Colaboración para el
Caso de Uso Generar Esquema, detallado en la disciplina de requerimiento, donde se muestra
cómo los objetos actúan recíprocamente para realizar la conducta del Caso de Uso, en el
Apéndice B se obtiene el resto de los Diagramas de Colaboración.
Fig. 33 Diagrama de Colaboración para el Caso de Uso Generar Esquema
En el Diagrama anterior el actor inicia la selección de una opción pero para ello en
primera instancia el objeto Esquema Interfaz tiene la responsabilidad de ensamblar el
Esquema de Contenido del Curso Multimedia por medio del objeto Esquema Control a través
del Elemento del Esquema y la opción seleccionada por el usuario y el objeto FileFTP Control
Personal de Contenido
Esquema Interfaz
Esquema Control
FileFTP Control
Componente Entidad
CASO DE USO GENERAR ESQUEMA
Selecciona opción
5: S
olicit
ar(E
lemen
to,O
pción
):Esq
uem
a
6: E
sque
ma
2: Solicitar Información(NombreArchivo)4: Información Solicitada
7: Solicitar Actualizar(NombreArchivo):Esquema
3: Obtener Arch
ivo(NombreArchivo)
8: Actualiza
r Archivo(NombreArch
ivo)
a través del Nombre de la Unidad del Curso. El objeto FileFTP Control obtiene los datos de
Información de la Unidad del objeto entidad Componente Entidad, que luego retorna al objeto
Esquema Interfaz, la información necesaria para construir el Esquema de Contenido.
En la siguiente actividad se presentan las clases de Diseño, que se obtuvieron adaptando
y refinando las clases de Análisis al ambiente de aplicación.
III.3.4 ACTIVIDAD 4: Identificar las clases de Diseño a partir de las clases de Análisis.
En esta actividad se identificaron las clases de Diseño para realizar los Casos de Uso,
que tuvieron como fundamento base los objetos identificados en el Modelo de Análisis de la
siguiente manera:
Inicialmente se evaluaron las clases de Análisis que participaron en la realización de los
Casos de Uso para determinar si tenían la suficiente importancia para ser modelados como
clases de Diseño (traza entre las clases de diseño hacia las clases de análisis) de acuerdo a los
siguientes criterios:
...clases redundantes: de las clases que expresaban la misma información, se retuvieron las que
presentaban el nombre más descriptivo.
...clases irrelevantes: las clases que tenían poco o nada que ver con el problema, fueron
eliminadas.
...Atributos: los nombres que describían objetos individuales fueron recalificadas como
atributos.
...Estructuras de implementación: las estructuras ajenas al mundo real (las estructuras de datos
como listas enlazadas, árboles, matrices y tablas, son casi siempre de implementación) se
eliminaron del análisis.
Para el modelado de las clases de Diseño se consideraron las operaciones de mayor
interés, es decir, todos los atributos y operaciones utilizados. Cada clase de Diseño cumplió con
los estereotipos de las clases de Análisis: Interfaz, Entidad y Control.
Las clases de Diseño identificadas para el Caso de Uso Generar Esquema se presentan a
continuación:
Nombre de la Clase Descripción Atributos Interfaz
Nombre Tipo
Cuadro de Texto Texto Botón de Comando Botón SiguientePaso() Cancelar() Ayuda() IrAnterior() IrSiguiente() Cancelar() Aceptar() FinalizarTest()
Esquema Interfaz Es responsable de permitir el ensamble Esquema de Contenido del CuMultimedia.
BorrarObservación() Control Nombre Tipo
EliminarItem() AñadirItem() ModificarItem() SubirItem() BajarItem() AumentarNivel() DisminuirNivel()
Esquema Control Es responsable de proveer los procenecesarios para permitir la modificaceliminación, inserción, organización búsqueda de un de un elemento Esquema de Contenido.
ConstruirJeraquía() Entidad Nombre Tipo
Descripción Texto Componente Entidad Es responsable de mantener la informacde la descripción y archivos asociadoscada elemento del Esquema de ContenidoUbicación Archivo Texto
Tabla 7 Clases de Diseño del Caso de Uso Generar Esquema
Debido a que esta actividad está ligada a las consideraciones de implementación, para la
transición al código fuente, se muestra a continuación los puntos relevantes considerados para
la implementación de cada subsistema (tal como fue expuesto en el Modelo Conceptual) del
sistema generador del Curso Multimedia (Ver Modelo Conceptual, Punto III.1.3).
Ambiente de Implementación Identificado
Subsistemas: Administrar Contenido, Generar Estructura y Test de Evaluación,
Administrar Aspectos Técnicos.
Plataforma Microsoft® Windows
Rendimiento rápido y capacidad de memoria promedio media
Red de computadoras.
Tiempo promedio de acceso a Internet medio
Capacidad de respuesta rápida
Entorno de desarrollo Microsoft® Visual Studio 6.0.
Lenguaje de desarrollo Microsoft® Visual Basic 6.0
Procesador de texto Microsoft Word
Servidor FTP
Subsistema: Generar Curso Multimedia
Plataforma Microsoft® Windows
Rendimiento rápido y capacidad de memoria promedio media
Capacidad de respuesta rápida
Procesador de texto Microsoft Word
Las clases de Diseño resultantes se muestran en el Apéndice B.
El Modelo de Diseño se desarrolló siguiendo los lineamientos de la Metodología del
Proceso de Desarrollo Unificado Rational (RUP) mediante los siguientes Diagramas empleados
para mostrar las relaciones que se utilizaron en la realización del Caso de Uso:
Diagrama de Secuencia
Diagrama de Clases
Durante el Análisis se modelaron las clases involucradas de manera estática, donde la
lógica del sistema resultó difícil de apreciar, por tal razón se elaboraron los Diagramas de
Secuencia a partir de las clases anteriormente definidas, mostrando así los aspectos dinámicos.
A continuación se muestra la aplicación y resultado de modelar dinámicamente las clases.
III.3.5 ACTIVIDAD 5: Modelar las vistas dinámicas entre clases mediante Diagramas de Secuencias.
Los Diagramas de Secuencia muestran interacciones entre objetos (instancias de las
clases de Diseño) según un punto de vista temporal. El contexto de los objetos no se representa
de manera explícita como en los Diagramas de Colaboración. La representación se concentra
sobre las expresiones de las interacciones. Ellos proveen un mapa secuencial de mensajes que
pasan entre los objetos a medida que avanza el tiempo, el orden de envío de los mensajes
viene dado por la posición sobre el eje vertical (la línea discontinua vertical que representa la
existencia de un objeto a lo largo de un período de tiempo). El eje vertical puede ser graduado
para expresar con precisión las restricciones temporales en el caso. El Modelo incluye qué
actividades se inician en el sistema, cuáles procesos y cambios ocurren internamente y que
salidas son generadas [RUP; 1999].
Por medio de los Diagramas de Secuencia se pudo ir refinando aún más las clases de
Análisis hasta obtener un diseño que permitiera una suave transición a la implementación.
Para crear un Diagrama de Secuencia, se comenzó por el principio del flujo del Caso de Uso, decidiendo
qué objetos del diseño y qué interacciones de instancias de actores eran necesarias para realizar cada paso. Todas
las clases de Diseño identificadas en la actividad anterior tuvieron por lo menos una instancia en el Diagrama de
Secuencia. Los objetos se ajustaron de manera natural a la secuencia de interacciones de la realización de cada
Caso de Uso, en donde los mensajes del Diagrama de Colaboración llevaron además de una secuencia una línea de
vida. Los mensajes están representados por flechas horizontales, orientadas del emisor del mensaje hacia el
destinatario, insistiendo en la cronología de los envíos de mensajes.
Se observa lo siguiente sobre estos Diagramas de Secuencia:
El causante de la invocación del Caso de Uso fue un mensaje de una instancia de un actor
hacia un objeto del diseño.
Fue importante comprender el orden cronológico de las transferencias de mensajes entre
objetos.
El Diagrama de Secuencia trató todas las relaciones de cada Caso de Uso.
A continuación se muestra el Diagrama de Secuencia para el Caso de Uso Generar
Esquema Fig. 34 Diagrama de Secuencia Generar Esquema
En el Diagrama de Secuencia anterior las interacciones comenzaron por parte del actor
quien indica al sistema la opción seleccionada en una instancia de la clase Esquema Interfaz,
luego el objeto Esquema Interfaz envía un mensaje con el parámetro Nombre de Archivo
(Indica el Nombre de la Unidad del Curso) al objeto instanciado de la clase FileFTP Control
quien envía posteriormente un mensaje de retorno al Objeto Esquema Interfaz sobre el
resultado de la información encontrada, luego el Objeto Esquema Interfaz envía un mensaje
con los parámetros opción elegido por el usuario y el Elemento del Esquema seleccionado al
Objeto FileFTP Control, una vez hecho esto el Objeto FileFTP Control envía al Objeto
Esquema Interfaz los cambios solicitados al Esquema de Contenido, si la opción seleccionada
por el actor es actualizar los datos en la lista del Esquema, el Objeto Esquema Interfaz solicita
al Objeto FileFTP Control actualizar la información en el Objeto Componente Entidad. Es
así, como por medio de los Diagramas de Secuencia se pueden ir refinando aún más las clases
de Análisis hasta obtener un diseño que permite una suave transición a la implementación.
Todos los Diagramas de Secuencias realizados en este proyecto para cada uno de los
Casos de Uso se muestran en el Apéndice B.
III.3.6 ACTIVIDAD 6: Modelar las vistas estática de las clases de Diseño identificadas.
Al igual que una clase describe un conjunto de objetos, una asociación describe un
conjunto de enlaces; los objetos son instancias de clases y los enlaces son instancias de
relaciones de un objeto dado, pero describe de manera abstracta los enlaces potenciales de un
objeto hacia otros objetos. Las clases pueden ser heredadas de otras clases (esto significa que
ellas pueden heredar todos los comportamientos y estados de su padre y adicionar la nueva
funcionalidad propia), tener otras clases como atributos, delegar responsabilidades a otras
clases e implementar interfaz abstracta [UML; 1999].
Para modelar la vista estática de las clases de Diseño se utilizaron los Diagramas de
Clases involucrando las clases y sus relaciones, mostrando la estructura estática del modelo, sin
información temporal.
El Diagrama de Clases es la esencia del Análisis y Diseño orientado a objeto, expresa
tanto el estado de persistencia como el comportamiento del sistema. Una clase encapsula
estados (atributos) y ofrece servicios para manipular esos estados (comportamiento). Un buen
diseño orientado a objeto limita el acceso directo a los atributos de la clase y los servicios que
ofrece los cuales manipulan esos atributos a favor de la llamada [RUP; 1999].
En lo que respecta a este proyecto se presenta una vista estática por cada subsistema (tal
como fue expuesto en el Modelo Conceptual) del sistema generador del Curso Multimedia (Ver
Modelo Conceptual, Punto III.1.3). Las interacciones entre los objetos en el Diagramas de
Colaboración del Modelo de Análisis, permitieron determinar las interacciones (Asociaciones)
entre las clases correspondientes en los Diagramas de Clases, es decir, las relaciones en el
Modelo de Análisis implicaron la necesidad de una o varias relaciones en el Modelo de Diseño.
A continuación se muestran las vistas estáticas de cada subsistema a través de
diagramas de clases (figuras 35, 36, 37, 38) del sistema. Las figuras muestran las clases que
intervienen al ser instanciadas en la realización de los Casos de Uso de cada subsistema, así
como las relaciones entre estas clases navegables en ambos sentidos (carecen de flechas). Es de
notar que el signo positivo (+) o negativo (-) en las propiedades (atributos y operaciones) de las
clases indica que son publicas o privadas respectivamente. Además el tipo de los atributos u
operaciones que devuelvan un valor será de acuerdo a los establecidos para el lenguaje
considerado para implementar estos sistemas, en este caso los de Visual Basic 6.0.
Los Diagramas de Clases obtenidos en cada Caso de Uso (Ver Capítulo I) se muestran
en el Apéndice B. Como algunas clases de Diseño han sido modificadas, para reflejar estos
cambios se mostrará en el punto siguiente el diccionario de clases actualizado, que constituye el
punto final del desarrollo del diseño para posteriormente continuar en la disciplina de
implementación siguiendo la estrategia metodológica seleccionada.
Fig. 35 Diagrama de Clases Subsistema Generar Estructura y Test de Evaluación
+Cancelar()
-Botón de comando : Object-Cuadro de Texto : Object
Acceso Interfaz
+ConectarFTP()+DesconectarFTP()+AbrirSesiónFTP()+CerrarSesiónFTP()
Conexión Control
+VerificarClave()+InsertarClave()+ModificarClave()+EliminarClave()
Clave Control
+EliminarArchivo()+InsertarArchivo()
+VisualizarArchivos()+BuscarArchivo()
+EnviarDefectuoso()+ExportarArchivo()+ImportarArchivo()+ImprimirArchivo()+VerPropiedades()+ListarArchivos()+AsignarStatus()
FileFTP Control
-Nombre : String-Clave : String
Claves Entidad
-Componente : StringBloqueado Entidad
-Solicitar Conexión de
1
-Dar status conexión a
1
-Solicitar Verificar Clave de1
-Enviar status Clave a
1
-EnviarArchivos del Curso a
1
-Solicitar Descarga de 1
-Obtener información de
1
1
-Obtener información de1
1
+Cancelar()+SiguientePaso()+ObtenerAyuda()
-Botón de comando : Object-Cuadro de Texto : Object
Esquema Interfaz
-Obtener informacion de1
*
+EliminarItem()+AñadirItem()+ModificarItem()+SubirItem()+BajarItem()+AumentarNivel()+DisminuirNivel()+ConstruirJerarquía()
Esquema Control
1
1
-Descripción : String-UbicaciónArchivo : String
Componente Entidad
-Enviar información Solicitada
1
-Solicitar información de1
+Cancelar()+SiguientePaso()+ObtenerAyuda()+PasoAnterior()+FinalizarAsistente()+GuardarCambios()
-Cuadro de lista : Object-Rejilla : Object
Adjunto Interfaz
1
11
1
-Pregunta : String-Respuesta : String-Opción correcta : String
Test Entidad
+InsertarPregunta()+ModificarPregunta()+EliminarPregunta()+DeterminarPregunta()+EvaluarResultado()+VerCorrectas()+ImprimirTest()+DuraciónTest()
Test Control
+Cancelar()+Aceptar()+ObtenerAyuda()+IrAnterior()+IrSiguiente()+FinalizarTest()+BorrarObservación()
-Cuadro de lista : Object-Botón de Comando : Object-Cuadro de Texto
Test Interfaz
1 1
*
-Obtener información de
1
-Solicita información de1
-Enviar información solicitada a
1
-Ruta : StringDefectuoso Entidad
-Obtener información de
1
*
+Cerrarr()+MostrarNombre()+ObtenerAyuda()+MostrarContenido()
-Botón de Comando : Object-Cuadro de Texto Enriquecido : Object-Cuadro de lista : Object
Observaciones Interfaz
1
1
Fig. 36 Diagrama de Clases Subsistema Administrar Contenido
+Cancelar()
-Botón de comando : Object-Cuadro de Texto : Object
Acceso Interfaz
+ConectarFTP()+DesconectarFTP()+AbrirSesiónFTP()+CerrarSesiónFTP()
Conexión Control
+VerificarClave()+InsertarClave()+ModificarClave()+EliminarClave()
Clave Control
+EliminarArchivo()+InsertarArchivo()+VisualizarArchivos()+BuscarArchivo()+EnviarDefectuoso()+ExportarArchivo()+ImportarArchivo()+ImprimirArchivo()+VerPropiedades()+ListarArchivos()+AsignarStatus()
FileFTP Control
-Nombre : String-Clave : String
Claves Entidad
-Componente : StringBloqueado Entidad
-Solicitar Conexión de
1-Dar status conexión a
1
-Solicitar Verificar Clave de1
-Enviar status Clave a
1
-EnviarArchivos del Curso a
1
-Solicitar Descarga de 1-Obtener información de
1
1
-Obtener información de_11
-_1
1
+ObtenerAyuda()+Salir()+SeleccionarComponente()+MostrarConfiguración()
-Botón de comando : Object-Cuadro de Texto : Object-Rejilla : Object
Configuración Interfaz
1
1
+EliminarItem()+AñadirItem()+ModificarItem()+SubirItem()+BajarItem()+AumentarNivel()+DisminuirNivel()+ConstruirJerarquía()
Esquema Control
11
-Servidor : String-Curso : String-Componente : String
VisorConfig Entidad
-Obtener información de
1
*
-Descripción : String-UbicaciónArchivo : String
Componente Entidad
-Obtener información de
1*
+Aceptar()+Cancelar()+ObtenerAyuda()+Mostrar Archivo() : Object+Modificar Texto() : Object
-Botón de comando : Object-Cuadro de Texto : Object-Cuadro de Lista : Object-Control de Imagen : Object-Control de Texto Enriquecido : Object-Control de Video : Object
Contenido Interfaz
1
1
+Cancelar()+Aceptar()+ObtenerAyuda()+IrAnterior()+IrSiguiente()+FinalizarTest()+BorrarObservación()
-Cuadro de lista : Object-Botón de Comando : Object-Cuadro de Texto
Test Interfaz
-Solicitar Información de1
-Enviar Información Solicitada a1
+InsertarPregunta()+ModificarPregunta()+EliminarPregunta()+DeterminarPregunta()+EvaluarResultado()+VerCorrectas()+ImprimirTest()+DuraciónTest()
Test Control
1
1
-Pregunta : String-Respuesta : String-Opción correcta : String
Test Entidad
-Obtener información de
1
*
+Cancelar()
-Botón de comando : Object-Cuadro de Texto : Object
Acceso Interfaz
+VerificarClave()+InsertarClave()+ModificarClave()+EliminarClave()
Clave Control
-Solicitar Verificar Clave de1
-Enviar status Clave a1
+EliminarArchivo()+InsertarArchivo()+VisualizarArchivos()+BuscarArchivo()+EnviarDefectuoso()+ExportarArchivo()+ImportarArchivo()+ImprimirArchivo()+VerPropiedades()+ListarArchivos()+AsignarStatus()
FileFTP Control
-EnviarArchivos del Curso a 1
-Solicitar Descarga de 1
-Nombre : String-Clave : String
Claves Entidad
-Obtener información de
11
-Descripción : String-UbicaciónArchivo : String
Componente Entidad
-Obtener información de
1
*
-Servidor : String-Curso : String-Componente : String
VisorConfig Entidad
-Obtener información de1
*
+Aceptar()+Cancelar()+ObtenerAyuda()+InvocarSoftwareCD()
-Botón de comando : Object-Cuadro de Texto : Object-Cuadro de Lista : Object
Reporte Interfaz
1
1
-Descripción : String-UbicaciónArchivo : String
Componente Entidad
-Obtener información de
1
*
+Cancelar()+SiguientePaso()+ObtenerAyuda()
-Botón de comando : Object-Cuadro de Texto : Object
Esquema Interfaz
+EliminarItem()+AñadirItem()+ModificarItem()+SubirItem()+BajarItem()+AumentarNivel()+DisminuirNivel()+ConstruirJerarquía()
Esquema Control
1
1
-Solicitar Información de1
-Enviar información Solicitada1
+Aceptar()+Cancelar()+ObtenerAyuda()+Mostrar Archivo() : Object+Modificar Texto() : Object
-Botón de comando : Object-Cuadro de Texto : Object-Cuadro de Lista : Object-Control de Imagen : Object-Control de Texto Enriquecido : Object-Control de Video : Object
Contenido Interfaz
1
1
-Pregunta : String-Respuesta : String-Opción correcta : String
Test Entidad
1
*
+InsertarPregunta()+ModificarPregunta()+EliminarPregunta()+DeterminarPregunta()+EvaluarResultado()+VerCorrectas()+ImprimirTest()+DuraciónTest()
Test Control
+Cancelar()+Aceptar()+ObtenerAyuda()+IrAnterior()+IrSiguiente()+FinalizarTest()+BorrarObservación()
-Cuadro de lista : Object-Botón de Comando : Object-Cuadro de Texto
Test Interfaz
1
1
-Solicitar Información de
1
-Enviar Información Solicitada a
1
Fig. 37 Diagrama de Clases Subsistema Generar Curso Multimedia
Fig. 38 Diagrama de Clases Subsistema Administrar Aspectos Técnicos
+Cancelar()
-Botón de comando : Object-Cuadro de Texto : Object
Acceso Interfaz
+ConectarFTP()+DesconectarFTP()+AbrirSesiónFTP()+CerrarSesiónFTP()
Conexión Control
+VerificarClave()+InsertarClave()+ModificarClave()+EliminarClave()
Clave Control
+EliminarArchivo()+InsertarArchivo()+VisualizarArchivos()+BuscarArchivo()+EnviarDefectuoso()+ExportarArchivo()+ImportarArchivo()+ImprimirArchivo()+VerPropiedades()+ListarArchivos()+AsignarStatus()
FileFTP Control
-Nombre : String-Clave : String
Claves Entidad
-Componente : StringBloqueado Entidad
-Solicitar Conexión de
1
-Dar status conexión a
1
-Solicitar Verificar Clave de1
-Enviar status Clave a
1
-EnviarArchivos del Curso a
1
-Solicitar Descarga de 1
-Obtener información de
1 1
-Obtener información de1
1
+ObtenerAyuda()+Salir()+SeleccionarComponente()+MostrarConfiguración()
-Botón de comando : Object-Cuadro de Texto : Object-Rejilla : Object
Configuración Interfaz
1
1
+EliminarItem()+AñadirItem()+ModificarItem()+SubirItem()+BajarItem()+AumentarNivel()+DisminuirNivel()+ConstruirJerarquía()
Esquema Control
1
1
-Servidor : String-Curso : String-Componente : String
VisorConfig Entidad
-Obtener información de
1
*
+ObtenerAyuda()+Salir()+SeleccionarComponente()+MostrarConfiguración()
-Botón de comando : Object-Cuadro de Texto : Object-Rejilla : Object
Configuración Interfaz
1
1
1
1
+Aceptar()+Cancelar()+ObtenerAyuda()
-Botón de comando : Object-Cuadro de Texto : Object-Rejilla : Object
Claves Interfaz
1 1
+AñadirCarpeta()+EliminarCarpeta()+ModificarNombre()+GenerarJerarquía()+VerificarUnidadCD()
Directorio Control
+Aceptar()+Cancelar()+ObtenerAyuda()
-Botón de comando : Object-Cuadro de Texto : Object-Cuadro de Lista : Object
Directorio Interfaz
1
1
1
1
III.3.7 ACTIVIDAD 7: Construir el Diccionario de Clases del Sistema.
A continuación se presenta el diccionario de clases, que constituye la última actividad
del desarrollo del diseño.
Acceso Interfaz: Es responsable de permitir el inicio de la verificación de la clave y asignación
de un nivel de seguridad.
Atributos:
Botón de comando
Cuadro de texto
Operaciones:
Cancelar()
Casos de Uso: Entrar al Sistema, Entrar al Curso
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia.
Esquema Interfaz: Es responsable de permitir el ensamble del Esquema de Contenido del
Curso Multimedia.
Atributos:
Botón de comando
Cuadro de texto
Operaciones:
SiguientePaso()
Cancelar()
ObtenerAyuda()
Casos de Uso: Generar Esquema, Iniciar Curso Multimedia, Esquema del Módulo
Subsistemas: Generar Estructura y Test de Evaluación, Generar el Curso Multimedia
Adjunto Interfaz: Es responsable de permitir la vinculación de cada archivo creado a través de
aplicaciones externas con cada elemento del Esquema de Contenido.
Atributos:
Botón de comando
Cuadro de lista
Rejilla
Operaciones:
SiguientePaso()
PasoAnterior()
GuardarCambios()
FinalizarAsistente()
Cancelar()
ObtenerAyuda()
Casos de Uso: Adjuntar Archivos
Subsistemas: Generar Estructura y Test de Evaluación.
Observaciones Interfaz: Es responsable de mostrar los archivos de textos cuyos contenidos
deben ser corregidos.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
Operaciones:
Cerrar()
MostrarNombre()
MostrarContenido()
ObtenerAyuda()
Casos de Uso: Ver Archivos con Observaciones
Subsistemas: Generar Estructura y Test de Evaluación.
Test Interfaz: Es responsable de permitir elaborar un Test de Evaluación asociado a un
elemento del Esquema de Contenido.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
Operaciones:
Cancelar()
Aceptar()
IrAnterior()
IrSiguiente()
FinalizarTest()
BorrarObservación()
ObtenerAyuda()
Casos de Uso: Elaborar Test, Mostrar Test de Evaluación, Mostrar Examen, Iniciar Corrección,
Mostrar Resultado.
Subsistemas: Administrar contenido, Generar Estructura y Test de Evaluación, Generar
el Curso Multimedia.
ArchivoExterno Interfaz: Es responsable de permitir seleccionar el archivo (imagen, video,
documento) creado por aplicaciones externas al sistema, relacionado con un elemento del
Esquema de Contenido.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
RutaArchivo
Casos de Uso: Añadir Archivo a Vincular
Subsistemas: Generar Estructura y Test de Evaluación.
Claves Interfaz: Es responsable de permitir efectuar mantenimiento a las claves de Seguridad
del Sistema.
Atributos:
Botón de comando
Cuadro de texto
Rejilla
Operaciones:
Aceptar()
Cancelar()
ObtenerAyuda()
Casos de Uso: Administrar Claves
Subsistemas: Administrar aspectos técnicos.
Directorio Interfaz: Es responsable de permitir efectuar mantenimiento al directorio del Curso.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
Operaciones:
Aceptar()
Cancelar()
ObtenerAyuda()
Casos de Uso: Modificar Estructura Directorio
Subsistemas: Administrar aspectos técnicos.
Contenido Interfaz: Es responsable de permitir observar los videos, las imágenes, los test de
evaluación y los documentos generados del Curso.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
Control Imagen
Control Video
Operaciones:
MostrarArchivo()
ModificarTexto()
Aceptar()
Cancelar()
ObtenerAyuda()
Casos de Uso: Ver Visor Contenido
Subsistemas: Administrar contenido, Generar el Curso Multimedia.
Inicio Interfaz: Es responsable de permitir iniciar el estudio del Curso Multimedia.
Atributos:
Botón de comando
Cuadro de Lista
Control Imagen
Control Video
Operaciones:
SeleccionarComponente()
Aceptar()
Cancelar()
ObtenerAyuda()
Casos de Uso: Entrar al Curso
Subsistemas: Generar el Curso Multimedia.
Examen Interfaz: Es responsable de permitir medir el aprendizaje del estudiante.
Atributos:
Control de Texto Enriquecido
Botón de comando
Control Opción
Cuadro de Texto
Operaciones:
IrAnterior()
IrSiguiente()
MostrarCorrectas()
MostrarResultados()
MostrarTiempo()
Detener()
Cerrar()
ObtenerAyuda()
Casos de Uso: Generar Esquema, Iniciar Curso Multimedia, Mostrar Esquema del Módulo
Subsistemas: Administrar aspectos técnicos, Generar el Curso Multimedia.
Reporte Interfaz: Es responsable de permitir el Quemado al CD del Curso Multimedia.
Atributos:
Botón de comando
Cuadro de texto
Cuadro de Lista
Operaciones:
InvocarSoftwareCD()
Aceptar()
Cancelar()
ObtenerAyuda()
Casos de Uso: Mostrar Visor CD Multimedia
Subsistemas: Generar el Curso Multimedia.
Clave Control: Es responsable de proveer los procesos necesarios para permitir que se realicen
la verificación del nivel de Seguridad, así como efectuar mantenimiento a las claves de acceso
del Sistema.
Operaciones:
VerificarClave()
InsertarClave()
ModificarClave()
EliminarClave()
Casos de Uso: Entrar al Sistema, Administrar Claves, Entrar al Curso.
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia, Administrar contenido.
Esquema Control: Es responsable de proveer los procesos necesarios, para permitir la
modificación, eliminación, inserción, organización, y búsqueda de un elemento del Esquema de
Contenido.
Operaciones:
EliminarItem()
AñadirItem()
ModificarItem()
SubirItem()
BajarItem()
AumentarNivel()
DisminuirNivel()
ConstruirJerarquía()
Casos de Uso: Generar Esquema, Adjuntar Archivos, Mostrar Visor Configuración, Iniciar
Curso Multimedia,
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia.
FileFTP Control: Es responsable de proveer los procesos necesarios para permitir la gestión de
los archivos del Servidor FTP.
Operaciones:
EliminarArchivo()
InsertarArchivo()
VisualizarArchivos()
BuscarArchivo()
EnviarDefectuoso()
ExportarArchivo()
ImportarArchivo()
ImprimirArchivo()
VerPropiedades()
ListarArchivos()
AsignaStatus()
Casos de Uso: Entrar al Sistema, Generar Esquema, Adjuntar Archivos, Elaborar Test, Ver
Archivos con Observaciones, Mostrar Visor Configuración, Administrar Claves, Modificar
Estructura Directorio, Ver Visor Contenido, Entrar al Curso, Mostrar Visor CD Multimedia,
Iniciar Curso Multimedia, Ver Visor Contenido, Mostrar Test de Evaluación, Mostrar Exámen,
Iniciar Corrección, Mostrar Resultado.
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia, Administrar contenido.
Conexión Control: Es responsable de proveer los procesos necesarios para permitir la
conexión y desconexión del Test de Evaluación.
Operaciones:
ConectarFTP()
DesconectarFTP()
AbrirSesiónFTP()
CerrarSesiónFTP()
Casos de Uso: Entrar al Sistema,
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Administrar contenido.
Test Control: Es responsable de proveer los procesos necesarios para permitir la gestión de la
Información del Test de Evaluación.
Operaciones:
InsertarPregunta()
ModificarPregunta()
EliminarPregunta()
DeterminarPregunta()
EvaluarResultado()
VerCorrectas()
ImprimirTest()
DuraciónTest()
Casos de Uso: Elaborar Test, Mostrar Test de Evaluación, Mostrar Exámen, Iniciar
Corrección, Mostrar Resultado.
Subsistemas: Administrar contenido, Generar Estructura y Test de Evaluación, Generar
el Curso Multimedia.
Directorio Control: Es responsable de proveer los procesos necesarios para permitir generar
un árbol jerárquico de directorio (carpetas y subcarpetas) de los Cursos y Unidades
(Componentes) del Sistema.
Operaciones:
AñadirCarpeta()
EliminarCarpeta()
ModificarNombre()
GenerarJerarquía()
VerificarUnidadCD()
Casos de Uso: Modificar Estructura Directorio.
Subsistemas: Administrar aspectos técnicos.
Claves Entidad: Es responsable de mantener la información de las claves de acceso del
Sistema.
Atributos:
Nombre
Clave
Casos de Uso: Entrar al Sistema, Administrar Claves, Entrar al Curso
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia, Administrar contenido.
VisorConfig Entidad: Es responsable de mantener la información de la ubicación del Servidor,
Curso y Unidad(Componente) de cada Curso.
Atributos:
Servidor
Curso
Componente
Casos de Uso: Mostrar Visor Configuración, Modificar Estructura Directorio, Entrar al Curso,
Visor CD Multimedia,
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia, Administrar contenido.
Componente Entidad: Es responsable de mantener la información de la descripción y archivos
asociados de cada elemento del Esquema de Contenido.
Atributos:
Descripción
Ubicación Archivo
Casos de Uso: Generar Esquema, Adjuntar Archivos, Ver Visor Contenido, Entrar al Curso,
Mostrar Visor CD Multimedia, Iniciar Curso Multimedia, Ver Visor Contenido.
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Generar el Curso Multimedia, Administrar contenido.
Test Entidad: Es responsable de mantener la información de los Test de Evaluación del Curso
Multimedia.
Atributos:
Ruta
Casos de Uso: Elaborar Test, Mostrar Test de Evaluación, Mostrar Exámen, Iniciar Correción,
Mostrar Resultado.
Subsistemas: Administrar contendio, Generar Estructura y Test de Evaluación, Generar
el Curso Multimedia.
Defectuosos Entidad: Es responsable de mantener la información de los archivos que
presentan observaciones asociados a una Unidad del Curso.
Atributos:
Ruta
Casos de Uso: Ver Archivos con Observaciones.
Subsistemas: Generar Estructura y Test de Evaluación.
Bloqueado Entidad: Es responsable de mantener la información de las
Unidades(Componentes) del Curso que están bloqueados por un usuario.
Atributos
Componente
Casos de Uso: Entrar al Sistema.
Subsistemas: Administrar aspectos técnicos, Generar Estructura y Test de Evaluación,
Administrar contenido.
III.4 DISCIPLINAS: IMPLEMENTACIÓN
Durante el Diseño se capturó gran parte de la arquitectura del sistema, la disciplina de
Implementación tomó el resultado del Modelo de Diseño para desarrollar la arquitectura como
un todo y generar el código fuente.
La especialización al lenguaje de programación describe, cómo se tradujo los términos
usados en el diseño a los términos y propiedades del lenguaje de Implementación. El sistema se
fue Implementando a través de prototipos evolutivos, hacia la versión definitiva del Software
requerido por los usuarios; en cada iteración se fue integrando el sistema e incrementando su
funcionalidad.
Un aspecto importante durante el diseño de objetos se basó en la selección del lenguaje
de programación. El lenguaje de programación no tiene que ser necesariamente orientado a
objetos. Sin embargo, el uso de un lenguaje de programación orientado a objetos hace más fácil
la implementación de un diseño orientado a objetos.
Las consideraciones relativas al ambiente de implementación presentadas con
anterioridad en el diseño, fueron las establecidas para este proyecto, allí se seleccionó el
lenguaje de programación.
Construcción
FASE
Implementación
DISCIPLINA
• Construir un prototipo evolutivo (prototipo de interfaz)
• Generar el código fuente: los componentes del sistema (Evolución del prototipo hacia el sistema final).
ACTIVIDADES
Las actividades de la disciplina son:
Construir un prototipo evolutivo
Generar el código fuente: los componentes del sistema (Evolución del prototipo hacia el
sistema final).
III.4.1 ACTIVIDAD 1: Construir prototipo evolutivo.
La realización del prototipo para el entendimiento de los requerimientos del usuario,
tuvo su fundamento en el desarrollo de código del lenguaje de programación seleccionado, por
ese motivo, el desarrollo de los prototipos evolutivos también corresponde a la Disciplina de
Implementación. Esto se justifica por el hecho de que la metodología utilizada es incremental e
iterativa, es decir, se desarrollaron los Casos de Uso, donde se identificaron las clases de
Análisis y se diseñaron las Interfaces que posteriormente se utilizaron para construir el
prototipo evolutivo.
El empleo de prototipos evolutivos permitió a los usuarios conocer de forma clara el
funcionamiento del sistema, y como a través de sucesivas iteraciones el sistema se iba ajustando
a sus requerimientos y refinando hasta obtener la versión definitiva.
El lenguaje de programación empleado para generar los códigos fuentes e implementar
la interfaz de las clases de diseño fue Microsoft Visual Basic 6.0. La implementación de las
clases se realizó en forma progresiva.
También se utilizaron los siguientes Software:
Windows 2000
Internet Information Server (Servicios FTP)
Microsoft Office
Los recursos Técnicos requeridos para la implementación son los siguientes:
Computadores: Intel Pentium 233 Mhz o superior, unidades de disco de 4 Gb o
superior, memoria Ram mínima 64, Monitores SVGA, Fax-Modem de 56k o
superior, equipos interconectados en red.
Impresoras (Impacto o Inyección a tinta).
Unidad de CD de lectura y escritura.
Servidor FTP
Windows, Word
Internet Explorer.
III.4.2 ACTIVIDAD 2: Generar el código fuente.
En este proyecto se crearon componentes de varios tipos como son:
Componentes de desarrollo:
Ejecutables
Librerías
Tablas de configuración
Componentes resultados del trabajo
Código Fuente
En la página siguiente se muestra (Tabla N° 8) un listado de los componentes generados
para este proyecto (los archivos de librerías vienen incluidos al compilar los ejecutables, que
representan componentes de dependencia de compilación).
Estos componentes constituyeron el Modelo de Implementación construido en este
proyecto. Estos componentes posteriormente se probaron e integraron para asegurar que se
cumplió con los requerimientos inicialmente establecidos. En las páginas siguientes se explica
ese aspecto con más detalle.
Componentes de desarrollo
Ejecutables
Generador.exe LibroVirtual.exe CDMultimedia.exe Librerías
Asycfilt.dll CMDLGES.DLL COMCAT.DLL COMDLG32.OCX MSCC2ES.DLL MSCMCES.DLL MSCOMCT2.OCX MSCOMCTL.OCX msdxm.ocx MSHFGES.DLL MSHFLXGD.OCX MSSTDFMT.DLL Msvbvm60.dll msvcrt.dll oleaut32.dll olepro32.dll RCHTXES.DLL RICHED32.DLL RICHTX32.OCX scrrnes.dll scrrun.dll STDFTES.DLL VB6ES.DLL VB6STKIT.DLL Wininet.dll
Tablas de Configuración (En formato txt)
Claves
VisorConfig
Componente
Test
Defectuoso
Bloqueado Tabla 8 Componentes de desarrollo
III.5 DISCIPLINAS: PRUEBA
Es importante planificar el proceso de prueba: las pruebas son muy extensas y se deben
ejecutar en paralelo con otros procesos [RUP; 1999].
Para el caso en estudio se realizaron dos tipos de pruebas: al sistema para comprobar su
correcta ejecución y con los usuarios para comprobar su funcionalidad y usabilidad.
Las actividades de la disciplina son:
Realizar Pruebas de sistema. Realizar Pruebas con los usuarios.
III.5.1 ACTIVIDAD 1: Realizar Pruebas de sistema.
Esta actividad permitió revisar la calidad del sistema desarrollado, comenzando con los
niveles más bajos (Módulos de Objetos), hasta llegar a las pruebas de integración (integrando
partes cada vez más grandes) de manera progresiva en cada interacción del proceso de
desarrollo del sistema.
Un aspecto importante en el proceso de desarrollo del sistema fue la integración, una
característica primordial lo constituyó la Modularidad en los subsistemas. Inicialmente los
subsistemas se desarrollan de manera independiente, hasta lograr su integración total. Los
subsistemas considerados corresponden a cada una de las actividades del Modelo Conceptual de
Transición
FASE
Prueba
DISCIPLINA
• Realizar pruebas de sistema. • Realizar pruebas con los usuarios.
ACTIVIDADES
sistemas de actividad humana (Ver Capítulo III, Punto III.3). Este enfoque permitió manejar
mejor la complejidad del sistema efectuando pruebas, primero en los componentes por separado
y luego en su totalidad.
Las pruebas se realizaron con la finalidad de validar que tanto los requerimientos como
los productos obtenidos fueran implementados correctamente y evaluar la integridad del
sistema.
Se realizaron pruebas de red para constatar la correcta comunicación de los equipos de
la Intranet con el Servidor FTP, verificando la correcta transferencia de datos por la red, y
efectuando pruebas del funcionamiento de sistema.
III.5.2 ACTIVIDAD 2: Realizar Pruebas con los Usuarios.
Para guiar la recolección de las opiniones de los usuarios en la presente
investigación, se utilizó la estructura de PIECES de James Wetherbe [1994], útil para la
clasificación de los problemas, las oportunidades y las normas.
La importancia de la estructura reside en su capacidad para mostrar cómo examinar los
sucesos que impulsan los proyectos en función de sus impactos sobre la organización. Las
categorías de la estructura PIECES son [James Wetherbe; 1994]:
P Necesidad de mejorar las prestaciones.
I Necesidad de mejorar la información (o los datos).
E Necesidad de mejorar el control económico y de costes.
C Necesidad de mejorar el control y la seguridad.
E Necesidad de mejorar la eficacia de personas y máquinas.
S Necesidad de mejorar el servicio a los clientes, los colaboradores, los empleados. y
así sucesivamente.
Para determinar las expectativas del usuario, se confrontó el prototipo evolutivo
tomando en cuenta los siguientes aspectos:
Categoría: Prestaciones
Cantidad de trabajo realizado en un cierto período de tiempo (Productividad)
Tiempo medio transcurrido entre una transacción o solicitud y la respuesta a dicha
transacción o solicitud.
Categoría: Información
Información Necesaria
Información en un formato no útil
Información difícil de producir
Categoría: Eficacia
El esfuerzo requerido por las tareas es excesivo.
Categoría: Servicios
El sistema produce resultados fiables.
El sistema es fácil de aprender.
El sistema es fácil de usar.
El sistema es cómodo de usar.
Cada aspecto determinó si el sistema funcionaba de la manera esperada por el usuario y
dependiendo de la incidencia de la interfaz en cuanto al Diseño, Navegación y Usabilidad que
ofrecía el Curso Multimedia al estudiante, el personal responsable del Curso Introductorio
estableció si era aceptable, regular o inaceptable. Es así como se valoró cada aspecto de la
estructura PIECES:
• H = Aspecto Aceptable
• M = Aspecto Regular
• L = Aspecto Inaceptable
El tipo de estrategia empleada para valorar cada aspecto considerado no corresponde a
ninguna de las planteadas en el marco teórico, si no que fueron diseñadas por el propio tesista.
Una vez diseñado el instrumento PIECES para confrontar los prototipos, se identificó la
población de usuarios para la realización de las pruebas, la cual se restringió al contexto de la
UNA específicamente a la Unidad de Apoyo al Estudiante; donde el objeto de interés para la
investigación se centró en los profesores responsables del Diseño Curricular del Curso
Introductorio.
Se efectuaron pruebas de aceptación de las interfaces, aplicando el instrumento
diseñado, para probar si corresponden a lo que el cliente realmente quería y recolectar sus
opiniones. Los resultados de las pruebas, se presentan en la Tabla Nº 9, donde se puede
observar que para todos los aspectos se logró la valoración H, después de sucesivos
refinamientos para incorporar las opiniones de los usuarios.
Aspecto Valoración Cantidad de trabajo realizado en un cierto período de tiempo (Productividad)
H
Tiempo medio transcurrido entre una transacción o solicitud y la respuesta a dicha transacción o solicitud.
H
Información Necesaria H
Información en un formato no útil H Información difícil de producir H El esfuerzo requerido por las tareas es excesivo. H El sistema produce resultados fiables H
El sistema es fácil de aprender H
El sistema es fácil de usar. H
El sistema es cómodo de usar. H Tabla 9 Valoración de los aspectos considerados por el Instrumento PIECES
III.6 DISCIPLINAS: DOCUMENTACIÓN
La documentación orienta a los usuarios para un mejor desenvolvimiento en el
desempeño de sus labores [RUP; 1999].
Transición
FASE
Documentación
DISCIPLINA
• Elaborar la documentación del Sistema. • Adiestrar al personal relacionado que utilizará
el Sistema.
ACTIVIDADES
Aunque corresponde a esta disciplina presentar la documentación definitiva, se fue
elaborando a lo largo del desarrollo del sistema. Los documentos generados como apoyo al
sistema, se dirigieron a distintos tipos de personas (desde los usuarios no técnicos hasta los
desarrolladores más técnicos) cumpliendo diferentes objetivos.
Las actividades de la disciplina son:
Elaborar la documentación del sistema.
Adiestrar al personal relacionado que utilizará el Sistema.
III.6.1 ACTIVIDAD 1: Elaborar la documentación del sistema.
Para la documentación del sistema se desarrolló el Informe de Tesis de Grado que
constituye el Sistema y el Manual de Usuario dividido en dos (2) partes, que será utilizado por
el Personal encargado del Diseño Curricular del Curso y el Supervisor Técnico como una guía
instruccional en la instalación, configuración y uso del sistema.
III.6.2 ACTIVIDAD 2: Adiestrar al personal relacionado que utilizará el Sistema.
El Adiestramiento fue realizado a lo largo de todo el trabajo: al confrontar los prototipos
con los usuarios. Al presentarle el funcionamiento de los sistemas, se cumplía con el propósito
de adiestrarlos y orientarlos en el uso, manejo, configuración e instalación del sistema.
CAPÍTULO IV
CONCLUSIONES Y RECOMENDACIONES
Este capítulo presenta las conclusiones y recomendaciones de la investigación realizada,
Las conclusiones abarcan tres aspectos: con respecto al producto obtenido, con respecto al
proceso seguido para obtener dicho producto y con respecto al aprendizaje del Tesista en la
aplicación de la metodología.
CONCLUSIONES RESPECTO AL PRODUCTO OBTENIDO.
La Universidad viene trabajando con un modelo instruccional clásico con reglas
establecidas. El sistema ofrece no solo a la Carrera Ingeniería de Sistemas sino a cualquier
Carrera, una plataforma tecnológica para producir material rompiendo el paradigma que se ha
venido usando, cambiando la estructura organizacional e institucional, aportando a las nuevas
asignaturas los siguientes beneficios:
El sistema SGCM constituye un invaluable aporte que contribuye a la presentación de un
servicio oportuno, eficiente y de calidad al estudiante que inicia estudios en la UNA.
El alumno obtiene un material teórico a través de interfaces multimedia.
Un aspecto importante para el diseño de las interfaces del Curso Multimedia destinado al
estudiante, fueron los lineamientos o normas ofrecidos por Jacob Nielsen, donde se brindan
un conjunto de recomendaciones para la construcción de Interfaces WEB agrupados en tres
aspectos Navegación, Usabilidad, y Diseño.
El sistema proporciona al personal académico (especialista en contenido, evaluador,
mecanógrafo, especialista en medios) una herramienta de apoyo para generar contenidos y
escenarios de aprendizaje, donde el estudiante encontrará texto, imágenes, videos, sonidos
que le facilitan la comprensión de los contenidos.
El sistema ofrece al personal docente, facilidades para actualizar los contenidos teóricos,
imágenes, videos de un Curso Multimedia.
Se evidenciaron además algunos beneficios colaterales, por ejemplo, mayor disposición y
entusiasmo dentro del personal, mejor distribución del tiempo y esfuerzo, un mayor control
de las actividades realizadas, entre otros.
CONCLUSIONES RESPECTO A LA APLICACIÓN DEL RUP.
El RUP permitió al tesista la ejecución ordenada y controlada de cada una de las disciplinas
(Conceptualizar el sistema, Requerimientos, Análisis y Diseño, Implementación, Prueba y
Documentación) llevados a cabo para el logro del sistema lográndose construir un ciclo de
vida de desarrollo iterativo e incremental.
Con la técnica de Casos de Uso se logró un lenguaje de entendimiento
usuario/desarrollador, que permitió a este último comprender las necesidades de los
usuarios que debían ser satisfechas.
Se capturó las funcionalidades del sistema, a través de vistas estáticas y dinámicas,
modelando la manera como se ejecutan internamente los Casos de Uso.
La confrontación con los usuarios y los Casos de Uso facilitaron la construcción y
evolución de los prototipos del sistema, proporcionando los requerimientos de los usuarios.
El instrumento diseñado (estructura PIECES), permitió recoger las percepciones de los
usuarios acerca del sistema y realizar ajustes a su desarrollo.
CONCLUSIONES DEL TESISTA EN RELACION A SU APRENDIZAJE.
El proceso de desarrollo permitió al Tesista actuar como investigador en el área de trabajo,
permitiéndole integrarse de manera activa al ámbito profesional y laboral.
La aplicación de nuevas metodología, proporcionó al Tesista conocimientos actualizados
de los cambios y avances tecnológicos de las últimas décadas. Se pueden realizar solicitudes
de información específica no solo por la vías convencionales, si no a través de la Intranet
como un vehículo casi instantáneo.
La ciencia, la tecnología, los métodos, entre otros proporcionan una base sólida para
enfrentar cualquier situación que se debe resolver.
El Tesista logró comprender los beneficios de la tecnología Orientada a Objetos, el
diseñador piensa en término del comportamiento de objetos y no en detalles de bajo nivel,
diseño de mayor calidad, mantenimiento más sencillo, modelado más realista, mejor
comunicación entre los profesionales de los sistemas de información y los usuarios.
El proyecto de grado permitió al tesista conocer el campo profesional del Ingeniero de
Sistemas, así como también el conjunto de métodos, estrategias y herramientas con que
cuenta el profesional del área de Sistemas para enfrentar y solucionar de forma efectiva
cualquier problema.
A continuación se exponen las recomendaciones con la finalidad de mantener y
optimizar las gestiones ofrecidas por el sistema y permitir su evolución.
RECOMENDACIONES
1. Efectuar cada cierto tiempo una evaluación del Sistema, con la finalidad de determinar
nuevos requerimientos.
2. Crear o incorporar un módulo al sistema que permita realizar cambios en la interfaz gráfica
del Curso Multimedia destinado al estudiante.
3. Crear planes de contingencia en caso de fallas o eventualidades en la funcionalidad del
sistema.
4. Adecuar la estructura física (hardware) de acuerdo a las necesidades propias del sistema y
de los usuarios.
5. Se recomienda cada cierto tiempo la revisión de los contenidos de los Cursos Multimedia
generados, para su posterior actualización
6. Se recomienda configurar el Servidor FTP, con un IP externo a fin que no exista
limitaciones de distancia para trabajar con el sistema.
7. Incorporar un módulo al sistema que permita realizar respaldos de la información contenida
en el servidor FTP.
8. Crear un módulo que permita al Supervisor Técnico, actualizar los paquetes de instalación
(archivos.cab, setup, setup.lst) del Curso Multimedia, ubicados en el Servidor FTP.
BIBLIOGRAFIAS Y REFERENCIAS BIBLIOGRÁFICAS
[Booch, Grady.; 1986]. Object-Oriented Development IEEE Transactions on Software
Engineering. Vol SE-12 Nº 2.
[Booch, Grady.; 1996]. Análisis y diseño Orientado a Objeto con aplicaciones. 2da Edición.
Editorial Addison-Wesley.
[Seen, James.; 1996] Análisis y diseño de sistemas de información. 2da Edición. México. Mc-
Graw-Hil.
[Jacobson, Ivar.; 1987]. Object oriented development in an Industrial Environment. Procceding
of OOPSLA 87 Conference, Orlando FL. Special ISSUE of SIGPLAN notices, Vol N°
22.
[Organization Manager Group.; September 2001]. OMG Unified Modeling Language
Specification.Version 1.4. [On line]. Disponible en http://www.omg.org
[Barrantes, Rodrigo; 1999]. Investigación un camino al Conocimiento (Un enfoque cualitativo
y cuantitativo). Costa Rica. EUNED.
[Rational Software Corporation.; 2002]. Rational Unified Process®. Version 2002.05.00. [On
line]. Disponible en http://www.rational.com
[Jacobson, Ivar; Booch, Grady y Rumbaugh, James; 2000]. El Lenguaje de Modelado
Unificado (Guía de Referencia). Madrid: Addison-Wesley.
[Jacobson, Ivar; Booch, Grady. y Rumbaugh, James; 2000]. El Proceso Unificado de Desarrollo
de Software (Guía de Referencia). Madrid: Addison-Wesley.
[Peter Checkland; (1993)]. Pensamiento de Sistemas. Práctica de Sistemas. Edit. Grupo Noriega
Editores.
[Peter Checkland y Sholes; 1994]. Metodología de los Sistemas Suaves. Edit. Grupo Noriega
Editores.
[UNA; 1987]. Análisis y Diseño de Sistemas. Universidad Nacional Abierta, Caracas: Autor.
[MICROSOFT; 1998]. Microsoft Visual Basic 6.0 Manual del Programador Edit. Mc Graw
Hill.
[Fortunato, Brown; 1985]. Principios de redacción. Caracas: ABCD.
[Edgar, Redondo; 2001]. Sistema Educativo basado en la Web para el Apoyo Académico a la
Asignatura Investigación de Operaciones (308) en la Universidad Nacional Abierta.
[©Improdex Desarrollo Empresarial; 2001-2002]. Usabilidad en la Web. [On line]. Disponible
en: http://www.creaciondempresas.com
[Fortunato, Brown; 1985]. Principios de redacción. Caracas: ABCD.
UNIVERSIDAD NACIONAL ABIERTA
VICERRETORADO ACADEMICO
INGENIERIA DE SISTEMAS
MANUAL DEL SISTEMA PARA DAR SOPORTE EN LA GENERACIÓN DEL CURSO INTRODUCTORIO
UTILIZANDO RECURSOS MULTIMEDIA
AUTOR:
EUHEN ALEXANDER SOCHACKYJ AMARO
C.I: 11.808.157
TELF: 0245-5713837
TUTOR INDUSTRIAL:
Prof. JUDI CARVALLO
C.I: 5.122.077
TUTOR ACADEMICO:
PROF(UNA): MIREYA DELGADO
CENTRO LOCAL: ARAGUA
MARACAY, ENERO DEL 2004
INTRODUCCIÓN Esta sección introduce primero una explicación sobre el sistema para dar
soporte en la generación de un Curso.
Bienvenidos al Sistema
Bienvenidos al sistema en su versión 1.1.0, la manera más rápida y
sencilla de generar cursos multimedia. Tanto si es un experimentado en el
manejo de aplicaciones de computación como un recién llegado en la
manipulación de tales aplicaciones, el sistema ofrece un juego completo de
herramientas que facilitan su utilización.
El sistema permite dar soporte en la generación del contenido de un
Curso aplicando recursos Multimedia.
Comprobar los requisitos de hardware y del sistema
Para ejecutar el sistema, tiene que disponer de cierto hardware y software
instalado en su equipo. Entre los requisitos del sistema cabe citar los
siguientes:
Microsoft Windows 95 o posterior, o Microsoft Windows NT 4.0 o
posterior (se recomienda Service Pack 3).
Procesaror Pentium o modelo superior de procesador o cualquier
procesador Alpha que ejecute Microsoft Windows NT Workstation.
Una unidad de CD-ROM.
Pantalla VGA o de mayor resolución, compatible con Microsoft
Windows.
2
16 MB RAM para Windows 95, 32 MB de RAM para Windows NT
Workstation como mínimo.
Un mouse (ratón) u otro dispositivo de puntero.
ACCESO Y ENTORNO AL Sistema. Para el iniciar el sistema seleccione en la barra de inicio la opción
programas luego seleccione el icono correspondiente en el grupo de
programa GENERADOR. También puede crear un icono de acceso directo en
el escritorio de Microsoft Windows.
En el Sistema se manejan tres niveles de acceso autorizados para operar
según los servicios ofrecidos para su tratamiento y/o administración. El tercer
nivel permite ensamblar la estructura y contenido del Curso, así como generar
los Test de Evaluación, el segundo permite revisar y aprobar los contenidos del
Curso, y el último nivel ofrece la capacidad de asignar las claves de seguridad,
efectuar un seguimiento en el proceso de construcción del Módulo.
El nivel de acceso es implementado a través de una pantalla inicial la
cual solicita una contraseña personal, asignando el nivel de seguridad que haya
sido establecido en el registro de personal con acceso autorizado. Dicha
pantalla se presenta en la figura siguiente.
3
Fig. Nº 1 Pantalla Contraseña
Después de ingresar la contraseña se presiona el botón Aceptar para
procesar la solicitud, si es correcta la información suministrada se carga la
pantalla de acuerdo al nivel de acceso del usuario. Si el acceso es a nivel
tres(3), se muestra el primer paso del Asistente para generar el contenido del
Curso (Ver Figura Nº 2).
Fig. Nº 2 Generar Esquema
4
PANTALLA GENERAR ESQUEMA
El Asistente dispone para la incorporación de un Esquema en el Curso
Multimedia de un Editor de Esquema, cada elemento o ítem del Esquema de
Contenido dispone de varios niveles. El proceso para la construcción es
sumamente sencillo la Figura Nº 2 muestra la ventana que permite ensamblar
el Esquema de Contenido, donde cada ítem del Esquema representa un punto
del Componente o Módulo del Curso Multimedia, para ello se cuenta con las
siguientes opciones:
La opción “Renombrar”: requiere que el usuario seleccione
previamente un ítem del Esquema (Válido para las opciones Eliminar,
Disminuir un nivel, Aumentar un nivel, Subir, Bajar, o Insertar un elemento)
y escriba el nuevo nombre en el área de edición “Elemento del Esquema de
Contenido” de esta manera se modifica el nombre del elemento.
La opción “Eliminar”: la supresión de un elemento del Esquema de
Contenido seleccionado se consigue pulsando el botón Eliminar , si el
elemento del Esquema posee archivos asociados (Imágenes, Videos, Texto,
Test de Evaluación) estos también serán eliminados.
Para la Inserción de un nuevo elemento o ítem del Esquema entre otros
ya existentes, se activará en el Editor el elemento delante del cual se va a
insertar, y se presiona el botón “Insertar”.
Las opciones “<<” (Disminuir un Nivel) o “>>” (Aumentar un Nivel)
elimina o agrega respectivamente un espacio tabulado (identado) a la izquierda
5
del elemento del Esquema de Contenido seleccionado, de esta manera se logra
que de un elemento o ítem del Esquema se deriven otros, subdividiendo el
Esquema en niveles. La Figura Nº , muestra la ventana del Editor con sub-
elementos (Viajes 3d, Descripción, Ficha Descriptiva, Trastornos,
Funciones) que cuelgan del elemento Sistema Oseo.
Con las opciones Subir o Bajar Elemento, el editor desplaza el
elemento o ítem seleccionado una posición arriba o debajo de la posición
actual, ofreciendo al usuario facilidades para organizar la estructura del
Esquema de Contenido.
Las opción “Cancelar”: finaliza el Asistente descartando los cambios
realizados por el usuario. La opción Siguiente activa la ventana Adjuntar
Archivo, segundo paso del Asistente para generar el contenido del Curso
(Ver Figura Nº 3).
.
Fig. Nº 3 Adjuntar Archivos
6
PANTALLA ADJUNTAR ARCHIVO
El segundo paso del Asistente permite asociar(adjuntar) los archivos de
tipo Imagen, Vídeo, Texto (creado a través de aplicaciones externas) a cada
elemento del Esquema de Contenido, la pantalla cuenta con las siguientes
opciones:
La opción “Añadir”: verifica que el usuario haya seleccionado un
elemento o ítem del Esquema de Contenido, y seguidamente muestra el cuadro
de diálogo Abrir (Ver Figura Nº 4).
Fig. Nº 4 Abrir Archivo
El cuadro de diálogo Abrir permite abrir archivos que se encuentran en
distintas ubicaciones. Puede abrir un archivo que se encuentre en el disco duro
del equipo o en una unidad de red con la que tenga conexión.
7
Pasos para Abrir un archivo que está en el disco duro o en la red
1. Haga clic en Añadir.
2. En el cuadro Buscar en, haga clic en la unidad, o carpeta que contenga el
archivo.
3. En la lista de carpetas, haga doble clic en las carpetas hasta que abra la
carpeta que contenga el archivo que desea.
4. Haga doble clic en el archivo que desee abrir.
Nota: los formatos de archivo que reconoce el sistema son: Imagen(bmp, wmf,
emf, gif, jpg), Documento(doc), Vídeo(avi, asf, asx, rmi, wav, wma, wax).
Aparecerá en cada columna de la cuadrícula (Ver Figura Nº 3) la
información necesaria para identificar los archivos adjuntados, tales campos
son los enumerados en la siguiente lista: Nombre, Ubicación, Tipo (Imagen,
Vídeo, Texto, Test de Evaluación), Status (Revisado o Sin Revisar).
La opción “Eliminar”: la supresión de un archivo adjunto seleccionado de
la Cuadrícula se consigue pulsando el botón Eliminar, el Asistente muestra una
pantalla de confirmación de eliminación, si el usuario selecciona la opción
Aceptar, se elimina el archivo, si selecciona Cancelar la eliminación no se
lleva a cabo.
Las opción “Cancelar”: finaliza el Asistente descartando los cambios
realizados por el usuario. La opción “Finalizar”: guarda todos los cambios
efectuados por el usuario y finaliza el Asistente.
8
La opción Anterior retorna a la pantalla Generar Esquema, primer paso del
Asistente para generar el contenido del Curso. Las opciones Archivos
Observaciones y Test de Evaluación se explican a continuación:
PANTALLA ARCHIVOS CON OBSERVACIONES
Cuando el usuario selecciona la opción Archivos Observaciones de la
Pantalla Adjuntar Archivos se muestra la Pantalla Archivos con
Observaciones (Ver Figura Nº 5), que permite al usuario transferir los
archivos que presentan alguna observación, desde el servidor al disco local
para posteriormente efectuar las correcciones necesarias.
Fig. Nº 5 Pantalla Archivos con Observaciones
9
La pantalla cuenta con las siguientes opciones: Copiar, Cortar,
Eliminar, Visor de Texto.
Si el usuario selecciona la opción Copiar o Cortar: el sistema verifica
que un archivo se haya seleccionado, y se activa la siguiente pantalla:
Fig. Nº 6 Pantalla Guardar como
Pasos para guardar un archivo al disco local o en la red
1. Para guardar el documento en una carpeta distinta, haga clic en una unidad
distinta del cuadro Guardar en o doble clic en una carpeta distinta de la lista
de carpetas.
2. Para guardar el documento en una nueva carpeta, haga clic en Crear nueva
carpeta .
3 En el cuadro Nombre de archivo, escriba un nombre para el documento.
4 Haga clic en Guardar.
10
La opción Cortar se diferencia de la opción Copiar, en que al transferir el
archivo del servidor FTP al disco local, el archivo fuente (archivo ubicado en
el servidor) se elimina.
Una vez el archivo ha sido transferido al disco local o de red, el usuario
procede a efectuar los cambios necesarios con el uso de aplicaciones externas
al sistema (la aplicación Word en este caso), para luego adjuntarlo
nuevamente al Esquema de Contenido con el apoyo del Asistente generador
del Curso Multimedia (Ver opción Añadir de la Pantalla Adjuntar Archivo).
La opción “Eliminar”: la supresión de un archivo seleccionado de la
Lista se consigue pulsando el botón Eliminar, el sistema muestra una pantalla
de confirmación de eliminación, si el usuario selecciona la opción Aceptar, se
elimina el archivo, si selecciona Cancelar la eliminación no se lleva a cabo.
La opción Visor Texto: en la lista de archivos con observaciones haga
clic en el archivo que desee ver y presione el botón Visor Texto, el sistema
muestra el contenido del archivo seleccionado. Si el usuario selecciona la
opción Cerrar: el sistema responde cerrando la Pantalla Archivos con
Observaciones y retornando a la Pantalla Adjuntar Archivos.
PANTALLA TEST DE EVALUACIÓN
Cuando el usuario selecciona la opción Test de Evaluación de la
Pantalla Adjuntar Archivos e indica el tipo de Test a realizar (Selección o
Desarrollo) se muestra la Pantalla Test de Evaluación (Ver Figuras 7 y 8).
Pantalla que permite al usuario responsable del contenido del Curso
11
Multimedia establecer las preguntas y respuestas del Test de Evaluación
asociados a un elemento (ítem) del Esquema (Estructura) de Contenido.
Fig. Nº 7 Pantalla Test de Desarrollo
Fig. Nº 8 Pantalla Test de Selección
12
La pantalla cuenta con las siguientes opciones: Añadir, Eliminar, o
Modificar Preguntas y Respuestas, Borrar Observación, Duración del
Test, Ir a la Pregunta Anterior, Ir a la Pregunta Siguiente, Guardar
Cambios, Cancelar, Finalizar Test.
La opción “Añadir”: esta opción permite al usuario a través de un
formulario (inicialmente vacío) para ingresar los datos, escribir una pregunta y
toda la información asociada.
La opción “Eliminar”: la supresión de una pregunta junto con toda la
información asociada se consigue pulsando el botón Eliminar, el sistema
muestra una pantalla de confirmación de eliminación, si el usuario selecciona
la opción Aceptar, se elimina la pregunta, si selecciona Cancelar la eliminación
no se lleva a cabo.
Pulsando el botón “Modificar”: el usuario puede editar (modificar) los
datos de una pregunta, una vez realizados los cambios se presiona el botón
Aceptar para guardar los cambios.
La opción “Asignar Tiempo Test”: permite asignar el tiempo destinado
para tomar una prueba, está medido en minutos. Si el usuario desea una prueba
mayor de una hora debe introducir el total de minutos. Ejemplo: si la prueba es
de una hora y media escriba 90.
Las opciones Anterior y Siguiente, son botones de navegación que
permiten al usuario ir a la pregunta siguiente o a la anterior.
13
En caso de seleccionar “Aceptar”, el sistema responde guardando los
cambios del registro. En caso de seleccionar “Borrar Observaciones”, el
sistema verifica que el actor haya escrito una observación, borrando la
observación asociada a una pregunta.
La opción “Cancelar”: finaliza la pantalla ignorando los cambios
realizados por el usuario. Si el usuario selecciona la opción “Finalizar”, el
sistema responde guardando todos los cambios efectuados por el usuario y
cerrando la pantalla.
Si el Test de Evaluación es del tipo selección:
En caso de seleccionar la opción Añadir una respuesta, el sistema
verifica que el usuario haya escrito una respuesta y agrega la respuesta a una
lista de respuestas.
En caso de seleccionar Eliminar respuesta, el sistema verifica que una
respuesta de la lista de respuestas este seleccionada y se elimina la respuesta.
En caso de seleccionar Modificar una respuesta de la lista de
respuestas, el sistema verifica que una respuesta de la lista está seleccionada y
que el usuario haya escrito una respuesta, para posteriormente modificar la
respuesta seleccionada de la lista.
14
PANTALLA VISOR DE CONFIGURACIÓN
Si despues de ingresar la contraseña en la pantalla “Contraseña” y de
presionar el botón Aceptar, el sistema verifia que el acceso del usuario es a
nivel uno(1) o dos(2), se muestra la pantalla “Visor de Configuración” (Ver
Figura Nº 9).
Fig. Nº 9 Visor de Configuración.
La pantalla “Visor de Configuración” permite, efectuar un seguimiento
de los archivos asociados al Esquema de Contenido, mostrando información
acerca del: tamaño, Status, y Cantidad de CD’s requeridos por el Curso, el
Nombre, Tamaño, Status, y Cantidad de CD’s de los Componentes (o
Módulos) del Curso.
Si el usuario selecciona un elemento de la Estructura o Esquema de
Contenido, aparecerá en cada columna de la cuadrícula (Ver Figura Nº 9)
15
información necesaria para identificar los archivos adjuntos, tales campos son
los enumerados en la siguiente lista: Nombre, Ruta del Servidor, Status
(Revisado o Sin Revisar), Tamaño, y Tipo (Texto, Imagen, Video, Test de
Evaluación) de los archivos. La pantalla cuenta con las siguientes opciones:
Administrador de claves, Estructura de Directorio, Visor Contenido,
Salir.
PANTALLA ADMINISTRADOR DE CLAVES
Cuando el usuario selecciona la opción Administrador de claves de la
Pantalla Visor de Configuración, se muestra la Pantalla Administrador de
Claves (Ver Figura 10). Pantalla que permite al usuario Supervisor Técnico
(acceso de seguridad a nivel uno) efectuar mantenimiento a las claves de
Seguridad del Sistema.
Fig. Nº 10 Pantalla Administrador de Claves.
16
Pasos para asignar claves:
1. El usuario escribe una clave o selecciona una clave ya existente (asociada al
Curso, Componente, o Administrador del Sistema).
2. Luego presiona el botón “Actualizar Clave” y se asigna o modifica la
clave.
En caso de seleccionar “Aceptar”, el sistema responde guardando los
cambios efectuados por el usuario y cerrando la pantalla “Mantenimiento de
Claves”. La opción “Cancelar”: finaliza la pantalla ignorando los cambios
realizados por el usuario.
PANTALLA MODIFICAR ESTRUCTURA DE DIRECTORIO
Cuando el usuario selecciona la opción Estructura de Directorio de la
Pantalla Visor de Configuración, se muestra la Pantalla Modificar
Estructura de Directorio (Ver Figura 11), que permite al usuario Supervisor
Técnico (usuario con acceso de seguridad de nivel uno) efectuar
mantenimiento a las Carpetas (Cursos y Unidades del Curso) del Sistema.
La pantalla cuenta con las siguientes opciones: Añadir y Eliminar
Cursos (Carpeta creada en el Servidor FTP), así como Añadir y Eliminar
Módulos (Unidades del Curso), Aceptar, Cancelar, Ayuda.
17
Fig. Nº 11 Pantalla Mostrar Directorio del Servidor.
En caso de seleccionar la opción Añadir Curso o Añadir Módulo, el
sistema verifica que el usuario haya escrito un nombre. Si la verificación es
correcta, el sistema crea la carpeta del Curso o Unidad(Módulo) en el Servidor
FTP, en caso contrario, el sistema muestra un mensaje de error al usuario.
En caso de seleccionar Eliminar Curso o Eliminar Módulo, se muestra
una pantalla de confirmación de eliminación. Si el usuario selecciona la
opción aceptar, se elimina el elemento seleccionado. Si selecciona cancelar, se
cancela la eliminación.
18
.En caso de seleccionar “Aceptar”, el sistema responde guardando los
cambios realizados por el usuario.
La opción “Cancelar”: finaliza la pantalla ignorando los cambios
realizados por el usuario.
Nota: Para mostrar las Unidades de cada curso, en el panel Directorio,
haga clic en el signo más (+) situado junto a la carpeta. O bien, haga doble clic
en la carpeta.
PANTALLA VER VISOR CONTENIDO
Cuando el usuario selecciona la opción Ver Contenido de la Pantalla
Visor de Configuración se muestra la Pantalla Ver Visor Contenido (Ver
Figura Nº ), que permite al Supervisor de Contenido observar los videos, las
imágenes, los test de evaluación y los textos generados para aprobar o
rechazar su contenido, así como transferir los archivos que presentan alguna
observación, desde el disco local al Servidor para que el usuario (Personal de
Contenido) efectúe las correcciones necesarias.
La pantalla cuenta con las siguientes opciones: Seleccionar un archivo
del listado, Mostrar o Eliminar un archivo seleccionado, Enviar los
archivos con Observaciones al Personal de Contenido, Enviar los archivos
corregidos al Servidor, Seleccionar la opción Revisado, Obtener la Ayuda,
Aceptar, Cancelar.
19
Fig. Nº 12 Pantalla Ver Visor Contenido.
Pasos para Mostrar el contenido de un Archivo:
1. El Sistema verifica que el actor seleccionó un archivo de la lista.
2. El sistema verifica el tipo de archivo.
- Si el archivo es una imagen, o un texto, se muestra el contenido del
archivo.
- Si el archivo es un vídeo, el usuario puede iniciar la ejecución del
archivo con la opción Reproducir o parar la ejecución del archivo en
caso de seleccionar la opción Detener.
- Si el archivo es un Test de Evaluación, se activa la pantalla Test de
Evaluación (Explicada anteriormente).
20
Pasos para enviar el Documento (Archivo con formato .doc) al Servidor o
al Personal de Contenido:
1. El sistema verifica que el usuario haya efectuado alguna modificación al
documento a transferir.
2. Si selecciona la opción Enviar al Servidor, el sistema guarda las
correcciones efectuados del documento en el Servidor.
3. Si selecciona la opción Enviar al Personal de Contenido, el sistema
transfiere el documento a la carpeta Observaciones asociada a la Unidad
del Curso con las respectivas indicaciones.
Opción Revisado: permite al usuario (Supervisor de Contenido) indicar si
un archivo (documento, imagen, vídeo, Test de Evaluación) cumplen con todas
las especificaciones del Curso Multimedia. Si el usuario al hacer clic sobre el
control se marca la casilla de verificación indica que el archivo ha sido
revisado.
Pasos para Eliminar un Archivo de la lista:
1. El Sistema verifica que el actor seleccionó un archivo de la lista.
2. Al seleccionar la opción Eliminar, se muestra una pantalla de confirmación
de eliminación, el actor selecciona una opción.
- Si es aceptar, se elimina el archivo seleccionado.
- Si es cancelar, se cancela la eliminación.
21
En caso de seleccionar “Aceptar”, el sistema responde guardando los
cambios realizados por el usuario.
La opción “Cancelar”: finaliza la pantalla ignorando los cambios
realizados por el usuario.
GUÍA DEL SUPERVISOR TÉCNICO.
Pasos para acceder al servidor FTP:
1. Invocar al Internet Explorer de Windows, y escribir la siguiente dirección
FTP://192.168.0.200.
2. Escribir como nombre de usuario: lilianazt y como contraseña: lilianazt
Pasos para efectuar respaldos manuales del servidor FTP:
1. Acceder al servidor FTP
2. El usuario tiene pleno acceso de todos los archivos y directorios del Sistema.
3. Copiar los archivos y directorios a respaldar en un disco local utilizando Mi PC o
el Explorador de Windows.
Pasos para modificar la interfaz del Curso Multimedia:
1. Ubicar en el disco local la carpeta CursoMultimediaEstudiante.
2. Abrir el archivo de Proyecto CursoVirtual.
3. Realizar todos los cambios desde Visual Basic 6.0
22
Pasos para actualizar los instaladores del Curso Multimedia:
1. Compilar el proyecto seleccionando la opción Archivo de la barra de menú y
posteriormente la opción Generar CursoVirtual.exe
2. Empaquetar el proyecto a través de la herramienta Asistente para Empaquetado
y Distribución de Microsoft Visual Studio 6.0, seleccionando el proyecto
compilado y siguiendo los pasos del Asistente.
Pasos para copiar los instaladores del Curso Multimedia al Servidor FTP:
1. Acceder al Servidor FTP
2. Borrar todos los archivos ubicados en la carpeta InstalarSGCM ubicada en el
directorio raíz del Servidor FTP.
3. Copiar todos los archivos instaladores (Archivos.cab, setup, SETUP.LST)
ubicados en el disco local al Servidor FTP (\InstalarSGCM) utilizando Mi PC o el
Explorador de Windows.
Pasos para el Grabar (Quemar) el CD Curso Multimedia:
1. Para el iniciar el sistema seleccione en la barra de inicio la opción programas
luego seleccione el icono correspondiente en el grupo de programa
LIBROVIRTUAL. También puede crear un icono de acceso directo en el
escritorio de Microsoft Windows.
2. El nivel de acceso es implementado a través de una pantalla inicial la cual solicita
una clave al Supervisor. Dicha pantalla se presenta en la figura siguiente.
Fig. Nº 13 Pantalla Ingreso Clave
23
3. Después de ingresar la clave se presiona el botón Aceptar para procesar la
solicitud, si es correcta la información suministrada, se descargan todos los
archivos del Servidor FTP al disco local del Curso Multimedia que será grabado
en el CD, y posteriormente se muestra la pantalla REPORTE DEL
CONTENIDO DEL CD’s MULTIMEDIA (Ver Figura Nº 14).
Fig. Nº 14 Pantalla Reporte del Contenido del CD’s Multimedia
4. La pantalla muestra las Unidades, Archivos, Carpetas necesarios para grabar el
Curso Multimedia, así como la distribución y el Total de CD’s requeridos. El
Supervisor selecciona la opción Quemar CD y examina el disco local para abrir
el archivo ejecutable (.exe) que inicia la aplicación para la organización y grabado
del contenido del Curso Multimedia en el CD.
5. Una vez que el Supervisor ha copiado los archivos de configuración requeridos
para cada CD, así como las carpetas y las Unidades del Curso, el proceso culmina
al seleccionar la opción grabar, obteniendo finalmente el producto ha ser
distribuido por la Universidad Nacional Abierta.
24
25