estudio y anÁlisis del uso de aplicaciones mÓviles en la sala de clases
DESCRIPTION
El presente informe es resultado del diseño e implementación de un ambiente para apoyar el estudio y análisis del uso de aplicaciones móviles en la sala de clases, para lo cual se siguió una adaptación de Rational Unified Process y se adoptó el modelo de N-capas para distribuir los componentes de software de acuerdo a su funcionalidad específica. El sistema implementado transforma los registros de uso generados al utilizar dispositivos móviles a través Autómatas Finitos Deterministas, obteniendo datos concretos que son entregados como reportes. Además se diseñaron e implementaron diferentes componentes de software y reglas que facilitan la definición e implementación de los reportes. Como resultado se obtuvo un sistema que se combina con un conjunto de procesos para poder mejorar las debilidades al incorporar tecnología en la educación.TRANSCRIPT
UNIVERSIDAD DE TARAPACÁ
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE COMPUTACIÓN E
INFORMÁTICA
DISEÑO E IMPLEMENTACIÓN DE UN AMBIENTE
PARA APOYAR EL ESTUDIO Y ANÁLISIS DEL USO
DE APLICACIONES MÓVILES EN LA SALA DE
CLASES
Memoria para optar al título de Ingeniero Civil en Computación e
Informática
Alumno: Francisco Ricardo Gregorio Mamani
Profesor Guía: Miguel Nussbaum Voehl
Arica –Chile
2004
2
Dedicado a mis padres Josefa y Benjamín, a mis hermanas Angélica, Sandra
y Paula, y a mí hermano Nelson.
Siempre los llevo conmigo.
3
Resumen
El presente informe es resultado del diseño e implementación de un
ambiente para apoyar el estudio y análisis del uso de aplicaciones móviles en
la sala de clases, para lo cual se siguió una adaptación de Rational Unified
Process y se adoptó el modelo de N-capas para distribuir los componentes
de software de acuerdo a su funcionalidad específica.
El sistema implementado transforma los registros de uso generados al utilizar
dispositivos móviles a través Autómatas Finitos Deterministas, obteniendo
datos concretos que son entregados como reportes. Además se diseñaron e
implementaron diferentes componentes de software y reglas que facilitan la
definición e implementación de los reportes.
Como resultado se obtuvo un sistema que se combina con un conjunto de
procesos para poder mejorar las debilidades al incorporar tecnología en la
educación.
4
Índice
1 INTRODUCCIÓN ..................................................................................... 7
2 CAPÍTULO I: ANTECEDENTES DEL PROYECTO ............................... 10
2.1 La Empresa................................................................................. 10
2.2 Motivación del Proyecto.............................................................. 11
2.3 Objetivo General ......................................................................... 12
2.4 Objetivos Específicos.................................................................. 12
3 CAPÍTULO II: MARCO TEÓRICO.......................................................... 13
3.1 El Proceso de Desarrollo ............................................................ 13
3.2 Arquitectura de N-Capas ............................................................ 25
3.3 Compiladores y Autómatas Finitos Deterministas....................... 29
4 CAPÍTULO III: MODELADO DE NEGOCIO........................................... 34
4.1 Objetivo Estratégico.................................................................... 34
4.2 Identificación de los Procesos de Negocio ................................. 34
4.3 Identificación de Roles del Entorno del Negocio......................... 44
4.4 Descripción de los Casos de Uso del Negocio ........................... 45
4.5 Especificación de Reglas de Negocio......................................... 62
5 CAPÍTULO IV: MODELADO DE REQUISITOS ..................................... 69
5.1 Obtención de Casos de Uso ....................................................... 69
5
5.2 Descripción de Casos de Uso..................................................... 70
5.3 Obtención del Modelo Conceptual .............................................. 72
5.4 Requisitos no Funcionales.......................................................... 74
6 CAPÍTULO V: MODELADO DE ANÁLISIS ............................................ 76
7 CAPÍTULO VI: MODELADO DE DISEÑO.............................................. 79
7.1 Modelo de la Solución................................................................. 79
7.2 Arquitectura Lógica ..................................................................... 81
7.3 Arquitectura Física ...................................................................... 84
7.4 Diagramas de Clases de Implementación .................................. 85
7.5 Diseño de Base de Datos ........................................................... 93
8 CAPÍTULO VII: IMPLEMENTACIÓN.................................................... 100
8.1 Reporte de Actividades Grupales ............................................. 100
8.2 Interfaz del Sistema .................................................................. 103
9 CONCLUSIONES ................................................................................ 107
9.1 Trabajos Futuros....................................................................... 108
10 BIBLIOGRAFÍA .................................................................................... 110
11 ANEXO A: LA PLATAFORMA .NET .................................................... 112
11.1 Common Language Runtime y .NET Framework Class Library 112
11.2 Microsoft ActiveX Data Objects .NET y XML ............................ 115
11.3 ASP.NET................................................................................... 116
6
11.4 Otras Características ................................................................ 117
12 ANEXO B: FIGURAS DE CLASES DE IMPLEMENTACIÓN ............... 120
13 ANEXO C: DESCRIPCIÓN DE LOS EVENTOS DEL REPORTE DE
ACTIVIDADES GRUPALES REALIZADAS ................................................ 124
7
1 INTRODUCCIÓN
Actualmente muchos sistemas que incorporan tecnología son utilizados en
las áreas de educación, comercio, industria, etc. Un aspecto poco
considerado es el estudio del uso de estos sistemas para identificar sus
debilidades y fortalezas como medio de evaluación y base para su
perfeccionamiento. Las estrategias de obtención de información más
comunes son las encuestas, las entrevistas verbales y la observación directa;
pero todas ellas presentan desventajas. Por ejemplo, las encuestas entregan
una visión reducida limitándose a un número de preguntas, las entrevistas
verbales aportan información volátil y a veces poco precisa, la observación
directa puede ser molesta para los usuarios, además que altera el
comportamiento de éstos. Otro defecto es la dificultad de obtener información
exacta de algunos aspectos, por ejemplo, si se desea responder a preguntas
tales como ¿cuál fue el período de utilización?, ¿qué se hizo durante su
utilización?, ¿cuál fue la cantidad de personas que participaron?, etc. ¿Quién
entrega esta información? Si la respuesta es el usuario, entonces se está
sobrecargando su trabajo traspasándole mayor responsabilidad y
complejidad.
8
Edunova es una organización dedicada a desarrollar soluciones educativas
formadas por una arquitectura tecnológica y sistemas computacionales que a
través de metodologías permiten administrar y aplicar contenido educativo
(Ver Figura 1.1). En el aspecto de la arquitectura tecnológica y sistemas
destacan los dispositivos móviles como Asistentes Personales Digitales
(PDAs, dispositivos móviles desde ahora en delante) y software diseñado
especialmente para aplicar el contenido educativo en la sala de clases que,
además, permite capturar información de lo sucedido al utilizar los
dispositivos móviles.
Figura 1.1: Soluciones educativas de Edunova.
Dado lo anterior, se propone diseñar e implementar un ambiente para el
estudio y análisis sobre el uso de las soluciones de Edunova, que utilice la
9
información capturada durante el trabajo con los dispositivos móviles en la
sala de clases.
10
2 CAPÍTULO I: ANTECEDENTES DEL PROYECTO
En este capítulo se describen brevemente los aspectos relacionados con la
Empresa, Motivación y Objetivos del proyecto.
2.1 La Empresa
Edunova es una organización dependiente de la Dirección de Investigaciones
Científicas y Tecnológicas de la Pontificia Universidad Católica de Chile
(DICTUC SA). DICTUC tiene como misión: “Desarrollar e implementar
comercialmente proyectos de innovación y transferencia tecnológica, que se
traduzcan en nuevos productos, procesos y/o servicios, así como
capacitación y perfeccionamiento que puedan tener un alto impacto
tecnológico y económico, en los mercados nacionales e internacionales”
[Dic04]. Edunova surge como empresa para transferir el trabajo de
Investigación y Desarrollo en el ámbito educativo, que por más de 5 años
llevan a cabo en conjunto las Escuelas de Ingeniería y Psicología de la
Pontificia Universidad Católica de Chile (PUC). La misión de Edunova es
“desarrollar soluciones educativas para hacer más eficiente el aprendizaje a
través de la incorporación de tecnología en la enseñanza” [Edu04]. Para
11
ello, Edunova cuenta con un equipo multidisciplinario de Educadores,
Diseñadores, Psicólogos e Ingenieros que trabajan en:
1. Desarrollar una arquitectura, basada en tecnología portátil e inalámbrica
que permite utilizar fácilmente las soluciones educativas en la sala de
clases.
2. Desarrollar y perfeccionar contenidos educativos, de acuerdo a los
planes y programas del Ministerio de Educación.
3. Capacitar a profesores y alumnos para que se apropien de la tecnología
y apoyar permanentemente el funcionamiento de la misma dentro del
colegio.
2.2 Motivación del Proyecto
Este proyecto surge para satisfacer la necesidad de analizar el uso de las
soluciones educativas de Edunova mediante un método no invasivo, que
complemente las observaciones realizadas en terreno, las entrevistas y la
documentación generada en la sala de clases. Este análisis permitirá
detectar problemas y oportunidades que retroalimentarán los procesos
internos y externos de Edunova.
12
2.3 Objetivo General
Diseñar e implementar un ambiente de consulta que apoye el estudio y
análisis del uso de soluciones educativas en la sala de clases.
2.4 Objetivos Específicos
1. Acortar el tiempo dedicado al estudio y análisis sobre el uso del las
soluciones educativas en la sala de clases.
2. Hacer transparente la obtención de información sobre la utilización de
los dispositivos móviles.
3. Representar la información sobre el uso de los dispositivos móviles
mediante una interfaz intuitiva.
4. Integrar este ambiente con los sistemas de Edunova.
13
3 CAPÍTULO II: MARCO TEÓRICO
En este capítulo se describe el proceso de desarrollo utilizado en este
proyecto, la arquitectura lógica de capas que se adoptó para el sistema
desarrollado, y la teoría de autómatas que fue la base para la transformación
de la información.
3.1 El Proceso de Desarrollo
Actualmente un gran número de sistemas computacionales son
desarrollados utilizando tecnología de orientación a objeto (OO) y el lenguaje
estándar para modelar estos sistemas es Unified Modeling Languaje (UML).
UML “es un lenguaje para construir modelos; no guía al desarrollador en la
forma de realizar análisis y diseño OO ni le indica cual es el proceso de
desarrollo a adoptar” [Lar99]. Por lo tanto, se debe seguir un proceso de
desarrollo de software independientemente de cual sea el lenguaje utilizado
para modelar un sistema. “Un proceso de desarrollo de software es un
método de organizar las actividades relacionadas con la creación,
presentación y mantenimiento de los sistemas de software” [Lar99].
14
En este proyecto se utiliza UML como lenguaje de modelado OO y el proceso
de desarrollo se basa en Rational Unified Process (RUP) combinado con la
propuesta de “El modelo de Negocio como base Del Modelo de Requisitos”
de María José Ortín Ibáñez, quien dice: “El modelo del negocio puede ser la
base para la especificación de los requisitos más importantes del sistema
que dará soporte al negocio, siendo por tanto el propio negocio lo que
determine los requisitos” [Ort00].
Por otro lado, “el Proceso Unificado Rational captura muchas de las prácticas
más buenas en el desarrollo del software moderno en un modelo que puede
ser adaptado a una amplia gama de proyectos y organizaciones” [Kru04].
Las principales características de RUP son:
1. Dirigido por los casos de uso: Los casos de uso capturan los requisitos
de los usuarios (personas y otros sistemas). “El concepto de casos del
uso, y los escenarios dirigen el flujo desde el modelado de negocio y
requisitos hasta las pruebas, y proporciona los hilos coherentes e
identificables a través del desarrollo y la entrega del sistema” [Kru04].
2. Centrado en la arquitectura: “El Proceso Unificado Racional se enfoca
en el desarrollo anticipado y basado en una arquitectura del software
robusta que facilite el desarrollo paralelo, reducción de la duplicación de
15
trabajo, aumento de la reusabilidad y mantenibilidad. Esta arquitectura
se usa para planificar y administrar el desarrollo alrededor del uso de
componentes del software” [Kru04].
3. Iterativo e incremental: “El Proceso Unificado Racional es un proceso
iterativo. Dado los sistemas de software sofisticados de hoy, no es
posible secuencialmente definir el problema completo, diseñar la
solución completa, construir el software, y finalmente probar el
producto. Se requiere un acercamiento iterativo para entender el
problema a través de los refinamientos sucesivos, y para desarrollar
una solución eficaz incrementalmente sobre de las iteraciones múltiples.
Este acercamiento da una adecuada flexibilidad acomodándose a los
nuevos requisitos o los cambios tácticos en los objetivos de negocio, y
permite al proyecto identificar y resolver riesgos anticipadamente”
[Kru04]. Este acercamiento iterativo es posible a través de la dirección
cuidadosa de los requisitos y la gestión de cambios para asegurar el
equilibrio entre la funcionalidad esperada, el nivel esperado de calidad,
y para permitir un control de los costos y tiempos asociados en cada
iteración.
Además RUP da énfasis a la creación y mantenimiento de modelos por sobre
la documentación excesiva; se apoya en técnicas OO y utiliza UML como
16
notación; promueve el desarrollo del software basado en componente, los
componentes son módulos importantes, subsistemas que cumplen una
función clara, de tal manera que pueden ensamblarse en una arquitectura
bien definida, o ad hoc, o alguna infraestructura de componentes como
Internet, CORBA, J2EE, COM/DCOM en la emergente industria de
componentes reusables; es un proceso adaptable a diferentes proyectos de
acuerdo a las necesidades de una organización que lo utilice; involucra a
usuarios, cliente, desarrolladores y mandos administrativos.
Las etapas del proceso de desarrollo utilizado son:
3.1.1 Modelado de Negocio
Tiene por objetivo comprender el dominio del problema, identificando el
objetivo estratégico de la organización y los procesos de negocio
involucrados con éste. Un proceso de negocio se caracteriza por un conjunto
de datos que son manipulados a través de actividades, en las que participan
agentes (personas o sistemas) ejecutando roles específicos de acuerdo a un
flujo de trabajo determinado. Además, estos procesos se encuentran sujetos
a un conjunto de reglas de negocio que determinan la estructura de la
17
información y las políticas de la empresa [Ort00]. Por lo tanto, un proceso de
negocio consta de:
Datos + Actividades + Roles + Flujo de trabajo + Reglas de negocio.
Especificación del Objetivo Estratégico
Es un objetivo de alto nivel, está relacionado con la alta administración de la
organización o empresa.
Identificación de los Procesos de Negocio
Una vez especificado el objetivo estratégico, éste se divide en subobjetivos y
a cada subobjetivo se le asocia un proceso de negocio. De esta manera un
objetivo estratégico se lleva a cabo a través de un conjunto de procesos de
negocio.
Identificación de los Roles del Entorno del Negocio
Identificados los procesos de negocio se deben encontrar los roles de los
agentes participantes. Un rol es una abstracción para representar las
colaboraciones entre los agentes [Ort99], muestra las propiedades
estructurales y de comportamiento de un agente en un contexto. Un agente
puede jugar uno o más roles, y además, un rol puede ser realizado por uno o
18
más agentes. Existen roles externos e internos al entorno de la organización;
en esta etapa del proceso de desarrollo interesa delimitar el entorno de la
organización, por lo tanto, se deben identificar los roles externos. Para esto
se utiliza un “diagrama de casos de uso del negocio” donde cada rol externo
es un actor y un proceso de negocio es un caso de uso.
Descripción de los Casos de Uso
La descripción de un caso de uso del negocio consta de diferentes
actividades:
1. Una descripción textual a través de la plantilla mostrada en la Tabla
3.1.
2. Construcción de un diagrama de roles (equivalente a un diagrama de
clases de UML), donde se muestra el aspecto estático o estructural de
la colaboración. En este diagrama se puede apreciar la multiplicidad y
sentido de la asociación entre los roles. El sentido de la asociación
muestra el conocimiento de un rol respecto de otro.
3. Construcción de diagramas de secuencia y de proceso (equivalente a
un diagrama de actividades en UML), que muestran el aspecto
dinámico o comportamiento de la colaboración. En el diagrama de
procesos cada rol posee una calle (swimlane) para delimitar su dominio
19
y responsabilidad, además se puede apreciar la sincronización entre
actividades y la información que entra y sale de cada actividad.
Proceso de negocio: Nombre del proceso de negocio.
Objetivo: Objetivo del proceso de negocio.
Pasos: Flujo normal del proceso de negocio.
Variaciones: Describe los posibles flujos alternos.
Prioridad: Alta, media, baja o no tiene. Se refiere a la prioridad de
automatización del proceso.
Tabla 3.1: Plantilla de los casos de uso del negocio.
Especificación de Reglas del Negocio
Las reglas de negocio son las restricciones de una organización cuando
realiza un proceso de negocio. Para especificar estas reglas se confeccionan
diccionarios de información y de actividades basándose en las plantillas
mostradas en la Tabla 3.2 y Tabla 3.3 respectivamente.
Actividad: Nombre de la actividad.
20
Origen: Actividad(es) precedente(s).
Agente: Rol que realiza la actividad.
Pasos: Descripción del caso de uso.
Precondiciones: Estado anterior al desarrollo de la actividad.
Poscondiciones: Estado posterior a la realización de la actividad.
Caso de uso: Nombre del caso de uso que representa la actividad.
Tabla 3.2: Plantilla para describir una actividad.
Nombre del objeto información
Atributos: Listado de atributos de la información.
Restricciones: Restricciones de los atributos de la información.
Clase: Clase que modelará esta información.
Tabla 3.3: Plantilla para describir una información.
3.1.2 Modelado de Requisitos
Teniendo como base el modelado de negocio se deben obtener los requisitos
funcionales. Los requisitos no funcionales se derivan, algunos, del modelado
21
de negocio y el resto se identifica a través de los aspectos de mantenibilidad,
rendimiento, interfaz de usuario, seguridad, etc. Las tareas a realizar en esta
etapa son:
Obtención de los Casos de Uso del Sistema
Por lo general a cada actividad del diagrama de procesos se le asocia un
caso de uso del sistema. No necesariamente todas las actividades del
diagrama de proceso se convertirán en casos de uso del sistema, ni tampoco
los casos de uso identificados desde el diagrama de proceso serán todos los
casos de uso del sistema. Se pueden agregar casos de uso no identificados
o descomponer las actividades muy complejas en más de un caso de uso del
sistema.
Además del diagrama de casos de uso del sistema, los casos de uso se
describen a través de la plantilla mostrada en la Tabla 3.4.
Caso de uso: Nombre del caso de uso.
Descripción: Descripción breve del caso de uso.
Actores: Actor principal y secundarios (si los hubiere).
Pasos: Flujo normal del caso de uso.
22
Precondiciones: Condiciones que deben cumplirse para que se lleve a
cabo el caso de uso
Poscondiciones: Condiciones luego de realizarse el caso de uso.
Variaciones: Flujo alterno del caso de uso.
Requisitos no funcionales: Propios del caso de uso que se describe.
Tabla 3.4: Plantilla para describir los casos de uso del sistema.
Obtención del Modelo Conceptual Inicial
“Un modelo conceptual explica (a sus creadores) los conceptos significativos
del dominio de un problema” [Lar99]. Por lo general, cada elemento del
diccionario de información será una clase; los otros conceptos del dominio se
identifican en el diccionario de actividades y el diagrama de roles siempre
que sean relevantes para el sistema que se va a implementar. En este
modelo se puede apreciar la multiplicidad, las asociaciones y la dirección de
lectura de la asociación de los conceptos del dominio.
Especificación de los Requisitos no Funcionales
23
Para completar el modelado de requisitos se deben agregar el conjunto de
requisitos no funcionales, es decir, requisitos relacionados con la interfaz de
usuario, mantenibilidad del sistema, cuestiones de implementación, etc.
3.1.3 Modelado de Análisis
Este capítulo muestra el comportamiento del sistema, es decir, la interacción
entre los actores y el sistema. “El comportamiento del sistema es una
descripción de lo que hace, sin explicar la manera en que lo hace” [Lar99], el
sistema es una caja negra. A este nivel lo que interesa es “qué” o la
respuesta del sistema al interactuar con el usuario y no “cómo” realiza
cálculos y operaciones para generar las respuestas esperadas.
3.1.4 Modelado de Diseño
En la etapa de modelado de análisis se plantea lo que el sistema debe hacer
(el “qué”). En esta etapa se describe mediante diferentes puntos de vistas
como se realizará esto (el “cómo”).
24
Modelo de la Solución
Se describe la filosofía y principios para el diseño de los componentes que
formarán el sistema.
Definir la Arquitectura Lógica.
El modelo lógico es una vista de implementación del sistema, las clases se
agrupan en paquetes y se muestran las relaciones y dependencias entre
ellos.
Describir Arquitectura Física
Se describe el sistema desde un punto de vista hardware. Los diferentes
nodos hardware entregan el soporte necesario para que los componentes de
la arquitectura lógica puedan alojarse sobre la arquitectura física.
Obtención de los Diagramas de Clases de Implementación
Se refina el diagrama conceptual inicial para obtener las clases que
realizarán los casos de uso del sistema.
Diseño de base de datos
25
Para el diseño de base de datos se utiliza la extensión de UML Data
Modeling Profile, que fue propuesta por Racional para soportar el modelado
de base de datos relacional con UML. Incluye extensiones personalizadas
para objetos tales como tablas, claves primarias, triggers y restricciones
[Rat00] [Spa01] [Gor02].
3.1.5 Implementación
Los diseños realizados en la etapa anterior se materializán en elementos de
software como la interfaz de usuario, objetos que realizaran procesos de
cálculo, acceso y almacenamiento de datos.
3.2 Arquitectura de N-Capas
Los sistemas computacionales poseen por lo general una arquitectura clásica
de tres capas como muestra la Figura 3.1. Esta arquitectura permite aislar la
lógica de la aplicación y convertirla en una capa intermedia bien definida
[Lar99].
1. Presentación: Es la interfaz e interacción con el usuario (u otro sistema).
26
2. Lógica de aplicación: Son las tareas y reglas que rigen los procesos.
3. Datos: Mecanismos de almacenamiento persistente, ya sean un sistema
gestor de base de datos, archivos u otro medio.
Figura 3.1: Arquitectura lógica de tres capas.
La arquitectura de tres capas se puede seguir subdividiendo verticalmente,
de manera que cada capa puede especializarse en tareas específicas. La
Figura 3.2 muestra como la capa de lógica de aplicación puede dividirse en
tres subcapas [Tro03] [Mic03]:
1. La capa de flujo de trabajo se preocupa de coordinar pequeñas tareas
para lograr un objetivo mayor. Otra característica de esta capa es que
permite manejar estados incompletos a diferencia de la lógica de
negocio transaccional, como por ejemplo: la determinación de si una
27
compra es realizada o no en una aplicación de comercio electrónico.
2. La capa de lógica de negocio se especializa en el procesamiento de
datos.
3. La capa de acceso a datos se encarga de la obtención de datos para
ser procesados en la capa de negocio y almacenamiento de datos. Los
datos pueden estar en una base de datos, en archivos XML, pueden ser
provistos por otro sistema, etc.
Figura 3.2: Evolución a una arquitectura de N-capas.
28
Con el modelo de N-capas se persiguen los siguientes beneficios:
1 Incrementar mantenibilidad y usabilidad: Por lo general diferentes
componentes de una aplicación implementan un comportamiento
similar; una mala práctica es copiar el código fuente entre estas
componentes. Al separar los componentes por capas, estos
componentes pueden ser modificados fácilmente y son utilizados
cuando se necesitan.
2. Independencia del cliente y la fuente de datos: Al mezclar la lógica de
presentación con la lógica de negocio se ata la lógica de negocio a un
tipo específico de cliente. Al separar ambas lógicas se puede atender a
diferentes clientes como un celular (WAP), pocket PC, un cliente en
modo consola, un cliente con navegador web, otro sistema, etc. Lo
mismo sucede con los datos, al implementar la capa de acceso datos se
logra independencia de la fuente de datos.
3. Incrementar el número de servidores (escalamiento horizontal) para
responder a diferentes niveles de demanda distribuyendo la carga de
trabajo.
4. Separación de los roles de los desarrolladores: Un desarrollador puede
29
especializarse en una de las capas.
Mientras mayor sea el número de capas más flexible será el modelo:
mantenibilidad, extensibilidad, reusabilidad, escalabilidad, seguridad entre
capas. En algunos casos los datos son estáticos, es decir, no necesitan de
mucho procesamiento para ser mostrados; en estos casos el número de
capas puede disminuir y algunas capas como la capa de negocio pueden
desaparecer.
3.3 Compiladores y Autómatas Finitos Deterministas
En términos generales un compilador traduce un programa (conjunto de
palabras) escrito en un lenguaje A en otro programa escrito en un lenguaje B.
Y un Autómata Finitos Determinista (AFD) es un reconocedor de palabras de
un lenguaje.
Un compilador es un programa que lee un programa escrito en un lenguaje,
el lenguaje fuente, y lo traduce a un programa equivalente en otro lenguaje,
el lenguaje objeto. En el proceso de traducción el compilador indica la
presencia de errores en el programa fuente (Ver Figura 3.3) [Aho90].
30
Figura 3.3: Esquema de un Compilador.
Los AFDs son utilizados en diferentes áreas, siendo una de las áreas más
conocidas el diseño de los compiladores. Un AFD es un modelo matemático
formado por:
1. Un conjunto de estados Q.
2. Un conjunto de símbolos sigma (el alfabeto de símbolos de entrada).
3. Una función de transición delta, que transforma una dupla estado y
símbolo en un estado.
4. Un estado q0 que se considera estado inicial. q0 pertenece a Q.
5. Un conjunto de estados F considerados como estados de aceptación o
estados finales. Con F subconjunto de Q.
31
Un AFD reconoce una secuencia de símbolos (palabra), si y solo si, hay
alguna secuencia de transiciones desde el estado inicial a algún estado final
consumiendo todos los símbolos de entrada (ver Figura 3.4).
Figura 3.4: Esquema de un Autómata Finito Determinista.
Para el AFD de la Figura 3.5 el alfabeto sigma = {a, b}, los estados Q = {1, 2,
3}, el estado inicial q0 = 1, el conjunto de estados finales F = {3}, la función
de transición delta se muestra en la Tabla 3.5:
Estado Símbolo a b
1 2 -
2 3 2
3 - -
Tabla 3.5: Función de transición.
32
Figura 3.5: Ejemplo de AFD.
En la Tabla 3.6 se pueden apreciar las transiciones para la palabra abbbba,
la cual, al ejecutarse la sexta transición se ha consumido llegando al estado
de aceptación 3, por lo que abbbba es una palabra reconocida por el AFD.
Transición Símbolo de entrada
Delta(1, a) = 2 abbbba
Delta (2, b) = 2 abbbba
Delta (2, b) = 2 abbbba
Delta (2, b) = 2 abbbba
Delta (2, b) = 2 abbbba
Delta (2, a) = 3 abbbba
Tabla 3.6: transiciones para la palabra abbbba.
33
Para la palabra abbbbaa las transiciones son idénticas a la palabra anterior
salvo que en la sexta transición no se ha consumido la palabra completa. La
última transición es (3, a), pero (3, a) no es una transición valida, por lo tanto,
la palabra no es reconocida por el AFD.
34
4 CAPÍTULO III: MODELADO DE NEGOCIO
En este capítulo se describe el entorno de Edunova a través de los procesos
de negocio relacionados con este proyecto.
4.1 Objetivo Estratégico
En el momento que se plantea la necesidad de realizar este proyecto
Edunova ya posee un conjunto de procesos y servicios externos e internos,
automatizados y no automatizados, que forman parte de su estrategia
organizativa. Este proyecto implica la unión de procesos de negocio que ya
existen con nuevos procesos para lograr el objetivo estratégico: “Mejorar las
soluciones educativas”.
4.2 Identificación de los Procesos de Negocio
La incorporación de las soluciones educativas a una institución educacional
se puede apreciar en la Figura 4.1. “Este modelo permite utilizar la tecnología
dentro de la propia sala de clases, aumentando la cobertura, ya que cada
35
alumno tiene a su disposición un equipo, los que además son compartidos
entre distintos cursos” [Edu04].
Para la gestión y aplicación de contenido educativo en la sala de clases a
través de la incorporación de tecnología, se cuenta con un sistema Web y
software para los dispositivos móviles. El sistema Web permite:
1. Administración de los contenidos educativos.
2. La creación de actividades a partir de los contenidos educativos. Luego
las actividades serán aplicadas en la sala de clases
3. Traspaso de actividades hacia la máquina del profesor.
4. Capturar resultados de actividades desde la máquina del profesor.
5. Etc.
36
Figura 4.1: Modelo de uso de las soluciones de Edunova.
Un dispositivo móvil puede cumplir una de las siguientes funciones:
1. Master o máquina del profesor: Este dispositivo móvil tiene las
actividades y software que permite desarrollar las actividades en la sala
de clases.
2. Slave o máquina del alumno: Este dispositivo móvil recibe las
actividades desde el master para que los alumnos puedan trabajar en
37
clases.
Existen tres formas de trabajo con dispositivos móviles:
1. Trabajo con alumnos: Esta opción permite realizar actividades con
alumnos.
2. Modalidad individual: Permite al profesor revisar las distintas
actividades que se encuentran cargadas en el Master.
3. Rescate de resultados: Se utiliza cuando no se ha podido recuperar
información de los alumnos.
Dentro del trabajo con alumnos existen tres tipos de actividades que se
pueden realizar:
1. Colaborativas: Los alumnos forman grupos y trabajan
colaborativamente (cada uno con un dispositivo móvil) para responder
preguntas.
2. Presentación: Se presentan diapositivas para apoyar el desarrollo de
las clases.
3. Evaluación: Cada alumno trabaja en forma individual respondiendo un
conjunto de preguntas. Posteriormente las respuestas son procesadas
para generar reportes de calificación a través del sitio web.
38
El master además de capturar los resultados de las actividades desarrolladas
registra la información sobre el uso de los dispositivos móviles en archivos
con formato XML denominados userlog (ver Figura 4.2). Cada registro de un
userlog es un evento (suceso de interés) formado por la fecha y hora en que
ocurrió, el nombre del evento y cero o más parámetros que lo describen.
Actualmente existen 207 eventos diferentes, y están clasificados como
eventos de administración de actividades, de actividad colaborativa, de
actividad de presentación, y de actividad de evaluación. Los eventos pueden
dejar de registrarse, pueden ser cambiados por uno o más eventos o pueden
surgir nuevos eventos según los intereses de investigación de Edunova.
39
Figura 4.2: Extracto de un archivo userlog.
En la Figura 4.3 se distinguen tres eventos de ejemplo:
1 Evento wakeup indica que se encendió el dispositivo móvil, el
parámetro netisup indica si al momento de prenderse el dispositivo
40
móvil hay comunicación o se trata de establecer comunicación entre los
dispositivos móviles (yes o no).
2 El evento battlevel indica el nivel de batería del dispositivo móvil a
través del parámetro level de 0 a 100 o AC (cargando).
3 El evento selmode indica la selección de modo de trabajo (mode):
single (modo individual), group (trabajo con alumnos) o logrescue
(rescate de resultados).
Figura 4.3: Los eventos wakeup, battlevel y selmode.
Los procesos de negocio involucrados en el mejoramiento de las soluciones
educativas relevantes para este proyecto son: Desarrollar software, Entregar
soporte técnico, Entregar soporte pedagógico, Consolidar información,
Generar reportes, Detectar problemas y oportunidades, y Evaluar
oportunidades. Los archivos userlogs son generados al utilizar los
dispositivos móviles (Realizar clases principalmente). Los procesos
41
Consolidar información y Generar reportes son procesos de negocio nuevos,
que se deben agregar y combinar con los procesos existentes para poder
completar el ciclo de estudio de uso de los dispositivos móviles, como se
muestra en la Figura 4.4:
En el proceso Realizar clases se generan userlogs.
En el proceso Consolidar información se recopilan los userlogs generados en
diferentes instituciones educacionales.
El proceso Generar reportes utiliza los userlogs disponibles para
confeccionar reportes sobre el uso de los dispositivos móviles.
Para llevar acabo el proceso Detectar problemas y oportunidades se utilizan
los reportes. Los problemas pueden ser de carácter técnico, pedagógico, o
de software.
Si se detectan problemas técnicos se debe capacitar a las personas que
utilizan los dispositivos móviles desde un punto de vista técnico (Entregar
soporte técnico).
Si son problemas pedagógicos se debe capacitar a los profesores y alumnos
de ser necesario (Entregar soporte pedagógico).
En el caso de ser problemas de software se utiliza el informe de problemas
para realizar los cambios necesarios en el software que utilizan los
42
dispositivos móviles; estos cambios pueden involucrar capacitaciones de
carácter técnico o pedagógico (Desarrollar software).
En el caso de Evaluar oportunidades se sigue otro flujo de procesos que no
son relevantes para el desarrollo de este proyecto y no se describirán.
43
Figura 4.4: Procesos de negocio.
44
4.3 Identificación de Roles del Entorno del Negocio
Figura 4.5: Diagrama de casos de uso del negocio.
45
En el diagrama de casos de uso del negocio (Ver Figura 4.5) se pueden
apreciar:
Roles externos: alumno, profesor y soporte técnico de institución
educacional.
Procesos de negocio internos: Generar reporte, Detectar problemas y
oportunidades, Evaluar oportunidades, Desarrollar software.
Procesos de negocio internos-externos: Entregar soporte técnico, Entregar
soporte pedagógico y Consolidar información.
Procesos de negocio externos: Realizar clases, Realizar actividades
individuales, Realizar actividad de presentación, Realizar actividad de
evaluación, Realizar actividad colaborativa y Rescate de resultados.
Los roles internos serán identificados en el siguiente punto.
4.4 Descripción de los Casos de Uso del Negocio
A continuación se describen los casos de uso de los procesos de negocio
identificados en este proyecto:
46
Proceso de negocio: Realizar clases.
Objetivo: Realizar una o más actividades con alumnos.
47
Pasos:
1. El profesor entrega un slave a cada alumno y él trabaja con uno o
más masters.
2. El profesor enciende su master, selecciona modo de trabajo en
grupo, selecciona una tripleta curso, letra del curso y canal
(frecuencia de 0 a 15) generándose un número de red que es
dictado a los alumnos. El número de red identifica a una red formada
entre el master y los slaves de los alumnos para desarrollar una
actividad. En una clase pueden existir redes paralelas, es decir,
actividades de un mismo curso, pero con frecuencia diferente.
3. Cada alumno enciende su slave, ingresa el número de red y su RUT.
4. Mientras el profesor decida realizar una actividad:
4.1 El profesor selecciona la actividad, busca los alumnos en la red y
envía la actividad a los alumnos.
4.2 Si es actividad de presentación, iniciar caso de uso Realizar
actividad de presentación.
4.3 Si es actividad de evaluación, iniciar caso de uso Realizar actividad
de evaluación.
4.4 Si es actividad de colaboración, iniciar caso de uso Realizar
actividad colaborativa.
5. El profesor finaliza la clase.
48
Variaciones:
1. Si antes Realizar clases el profesor considera necesario puede
revisar las actividades que están en el master, extender caso de uso
Realizar actividades individuales. Seguir con el paso 1.
4.a Si es que existen alumnos que han llegado atrasados a clases el
profesor puede iniciar una actividad paralela con otro master y los
alumnos atrasados. Continuar paralelamente en el paso 2.
4.b Si es que existen problemas que impiden el desarrollo normal de la
actividad se deben reiniciar los dispositivos móviles necesarios.
Continuar en el paso 2. Prioridad: No tiene.
Proceso de negocio: Realizar actividad de presentación.
Objetivo: Realizar una actividad de presentación con alumnos.
Pasos:
1. El profesor y alumnos se encuentran observando la primera slide, es
decir, el índice de contenidos.
2. Mientras el profesor no finalice la actividad de presentación:
2.1 El profesor decide desde el master la siguiente slide que se
49
mostrará a los alumnos. Si considera necesario podrá usar las notas
(apuntes y recomendaciones que puede o no tener una slide) del
profesor o usar el modo de rayado de pantalla (permite al profesor
utilizar una slide como pizarra). Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Realizar actividad de evaluación.
Objetivo: Realizar una actividad de evaluación con alumnos.
Pasos:
1. Los alumnos se encuentran observando la pantalla de selección de
género (masculino/femenino) y seleccionan el género.
2. Mientras existan preguntas y el profesor no finalice la actividad:
2.1 Cada alumno responde a la pregunta actual según las alternativas
dadas.
2.2 El profesor aclara dudas del alumno, para ello se puede apoyar en
su master desde donde puede ver una copia de la actividad. Variaciones:
2. La finalización de la actividad de evaluación implica el rescate de
50
resultados, es decir, los resultados de los alumnos en esa
evaluación. Si el rescate de resultados falla extender caso de uso
Rescate de resultados. Prioridad: No tiene.
Proceso de negocio: Rescate de resultado.
Objetivo: Rescatar resultados de una actividad de evaluación.
Pasos:
1. El profesor selecciona el modo de rescate de resultado desde su
master.
2. El profesor ingresa el curso, letra y canal (red) de la actividad que no
se pudo rescatar los resultados.
3. Los alumnos ingresan el número de red y su respectivo RUT.
4. El profesor selecciona la actividad en cuestión, busca los alumnos
en la red y rescata los resultados de la actividad. Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Realizar actividad colaborativa.
51
Objetivo: Realizar una actividad de colaboración con alumnos.
Pasos:
1. El profesor acepta la formación de grupos entregadas por el master.
2. Mientras el profesor no finalice la actividad:
2.1 Todos los alumnos que conforman un grupo discuten la pregunta
actual y responden según las alternativas disponibles; si es
incorrecta, continúan en la misma pregunta con la última opción
seleccionada deshabilitada; si es correcta, pasan a la siguiente
pregunta.
2.2 El profesor desde su master monitorea el avance de los grupos
mediante una matriz (grilla) donde las filas son los grupos de
alumnos y las columnas son las preguntas. En cada celda de la grilla
se puede apreciar el resultado: verde si el grupo ha contestado
correctamente en la primera oportunidad; amarillo si ha sido en la
oportunidad enésima, con n en el rango (1, M]; y rojo en otro caso.
M = (número de alternativas de la pregunta -1) / 2)
También puede monitorear el avance de los grupos mediante una
lista de los grupos formados y la pregunta actual, puede congelar o
descongelar el avance de uno o todos los grupos para corregir
52
errores en la forma de trabajar de los alumnos y puede hacer saltar
al grupo a una pregunta cualquiera. Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Realizar actividades individuales
Objetivo: Revisar actividades que se encuentran cargadas en el Master.
Pasos:
1. El profesor enciende el master y selecciona el modo de trabajo
individual. Mientras no se finalice el modo individual:
1.1 Seleccionar actividad y revisar contenido. Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Entregar soporte pedagógico.
Objetivo: Entregar apoyo y solucionar problemas pedagógicos.
Pasos:
1. El profesor solicita apoyo al soporte pedagógico.
53
2. El soporte pedagógico instruye sobre el uso y propósito de las
soluciones educativas apoyándose en manuales. De ser necesario
el soporte pedagógico acompaña al profesor en terreno. Variaciones:
1. El soporte pedagógico detecta el problema. Continuar con el paso 2. Prioridad: No tiene.
Proceso de negocio: Entregar soporte técnico.
Objetivo: Entregar apoyo y solucionar problemas técnicos.
Pasos:
1. El soporte técnico de la institución educacional reporta un problema
o duda a través de chat, e-mail o teléfono.
2. El soporte técnico Edunova responde al problema o duda por chat,
e-mail, teléfono o visita en terreno si es necesario. Variaciones:
1. El problema es detectado por el soporte técnico Edunova. El soporte
técnico Edunova contacta al soporte de la institución educacional
por chat, mail, teléfono. Seguir en el paso 2.
54
Prioridad: No tiene.
Proceso de negocio: Consolidar información.
Objetivo: Respaldar datos sobre la utilización de dispositivos móviles.
Pasos:
1. El soporte técnico de la institución educacional recibe los master del
profesor, los conecta a su computador para rescatar los userlogs y
los envía al soporte técnico Edunova.
2. El soporte técnico Edunova entrega los userlogs al encargado de
base de datos.
3. El encargado de base de datos almacena la información en la base
de datos. Variaciones:
1. Los userlogs pueden perderse por un hard-reset del master, en este
caso la información no podrá ser recuperada. Se informa de la
pérdida de los datos al soporte técnico Edunova. Finalizar caso de
uso.
El hard-reset implica la pérdida de los datos que contiene el
dispositivo móvil, se produce por un nivel insuficiente de energía
para mantener el funcionamiento o por manipulación humana.
55
Prioridad: No tiene.
Proceso de negocio: Generar reportes.
Objetivo: Generar reportes de lo sucedido en la sala de clases.
Pasos:
1. La persona interesada o usuario Edunova (investigador pedagógico
y soporte pedagógico) organizan los userlogs por masters e
institución educacional y selecciona los eventos de los userlogs que
son relevantes, según su interés.
El ingeniero de tecnología web, ingeniero de tecnología móvil y
soporte técnico Edunova también suelen estar interesados en el uso
de los dispositivos móviles, pero esto es esporádico.
2. El usuario Edunova organiza e interpreta los eventos, generando
datos concretos, por ejemplo, inicio y término de una actividad,
nombre de actividad, número de alumnos que participó en la
actividad, etc.
3. Los datos obtenidos se representan en uno o más reportes, cada
uno con una o más presentaciones. Variaciones:
56
1. La información de los userlog puede estar incompleta. Si es posible
continuar con el paso 2.
2. La interpretación de lo de lo sucedido en la sala de clases en un
nivel macro puede ser difícil y no se puede realizar. Terminar caso
de uso. Prioridad: Alta.
Proceso de negocio: Detectar problemas y oportunidades.
Objetivo: Detectar problemas y oportunidades en el uso de las soluciones
educativas.
Pasos:
1. Cuando el usuario Edunova detecta anomalías en los reportes:
actividades que no se desarrollan completamente, demasiados
problemas en la red, demasiado tiempo ocupado en preparar una
actividad, actividades que no se ejecutan de forma normal, etc., se
determinan las causas de los problemas.
2. Si son problemas de carácter pedagógico iniciar caso de uso
Entregar soporte pedagógico.
2.1 Si son problemas técnicos iniciar caso de uso Entregar soporte
técnico.
57
2.2 Si son problemas de software iniciar caso de uso Desarrollar
software.
3. Una vez tomadas las acciones para corregir el error se deben
realizar los seguimientos necesarios.
4. Si se detectan oportunidades, entonces iniciar caso de uso Analizar
oportunidades. Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Desarrollar software.
Objetivo: Mejorar el software existente o desarrollar nuevos servicios.
Pasos:
1. El ingeniero de tecnología móvil o web obtiene requisitos.
2. El ingeniero de tecnología móvil o web desarrolla lo requerido.
3. El ingeniero de tecnología móvil o web crea manuales técnicos y
58
entrega el software.
3.1 Si el software requiere soporte técnico iniciar caso de uso Entregar
soporte técnico.
3.2 Si el software requiere soporte pedagógico iniciar caso de uso
Entregar soporte pedagógico. Variaciones: No tiene.
Prioridad: No tiene.
Proceso de negocio: Evaluar oportunidades.
Objetivo: Determinar factibilidad de nuevos servicios para las soluciones.
Pasos:
1. El investigador pedagógico analiza, desarrolla, y evalúa plan
pedagógico.
2. El gerente de Edunova analiza factibilidad tecnológica, técnica, y
económica.
3. El gerente de Edunova aprueba o rechaza oportunidad. Variaciones: No tiene.
Prioridad: No tiene.
59
De acuerdo a la descripción anterior los roles internos son: usuario Edunova,
soporte técnico Edunova, soporte pedagógico, investigador pedagógico,
ingeniero de tecnología móvil, ingeniero de tecnología web, gerente y
encargado de base de datos. La jerarquía de generalización especialización
de los roles se muestran en la Figura 4.6:
Figura 4.6: Jerarquía de generalización especialización.
El diagrama de roles de los casos de uso del negocio muestran los aspectos
estructurales o estáticos de la colaboración entre los roles para llevar a cabo
60
un proceso de negocio, tales como, la visibilidad y multiplicidad entre ellos.
(Ver Figura 4.7).
61
Figura 4.7: Diagrama de roles de los casos de uso del negocio.
Para visualizar el aspecto dinámico y de comportamiento de la colaboración
a continuación se muestran los diagramas de secuencia y de procesos para
el caso Generar reportes que es el proceso de negocio que se va a
automatizar. Ambos diagramas fueron confeccionados luego de realizar un
prototipo que mostraba los userlogs en forma verbal, es decir, la secuencia
de eventos que sucedió.
Figura 4.8: Diagrama de secuencia para el caso de uso Generar Reportes.
62
Figura 4.9: Diagrama de procesos para el caso de uso Generar Reportes.
4.5 Especificación de Reglas de Negocio
63
Para poder especificar las reglas de negocio se confeccionaron los
siguientes diccionarios de actividades y de información.
Actividad: Organizar y seleccionar eventos.
Origen: Inicio.
Agente: Usuario Edunova.
Pasos:
1. Seleccionar los master para el reporte.
2. Por cada master seleccionar uno o más userlogs.
3. Para cada userlog seleccionar los eventos de interés. Precondiciones:
1. Se sabe cuáles son los eventos de interés para el reporte.
2. Se pueden considerar uno o más masters. Poscondiciones:
1. Por cada master se genera un resumen con los eventos de interés
para el reporte. Caso de uso: Está contenido en Obtener reporte.
64
Actividad: Generar datos del reporte.
Origen: Organizar y seleccionar eventos.
Agente: Usuario Edunova.
Pasos:
1. Por cada resumen de eventos de userlogs identificar datos de interés
y obtener datos más concretos, por ejemplo, a partir del inicio y final
de la actividad calcular la duración de ésta.
2. Crear detalle del reporte, es decir, organizar y estructurar los datos. Precondiciones: No tiene.
Poscondiciones:
1. Se obtienen datos concretos, por ejemplo: nombre y duración de una
actividad, curso, número de alumnos participantes, etc. Caso de uso: Está contenido en Obtener reporte.
Actividad: Crear vistas de reportes.
Origen: Interpretar eventos.
Agente: Usuario Edunova.
Pasos:
65
1. Para los datos del reporte crear la representación más apropiada. Precondiciones:
1. Cada reporte puede tener una o más representaciones. Poscondiciones: No tiene.
Caso de uso: Está contenido en Obtener reporte.
Objeto de información: Userlog.
Atributos:
Número de serie del master,
IP del master,
Versión del software utilizado,
Fecha de inicio, y
Conjunto de eventos. Restricciones:
1. El número de serie del master e identificador de la institución
educacional serán únicos.
2. Un userlog puede contener información minutos, horas o días de un
master. Por lo general se utilizan varios masters en la sala de clases.
66
Clase de dominio: Userlog.
Objeto de información: Resumen de eventos de userlog.
Atributos:
Nombre del reporte,
Identificador de la institución educacional,
Nombre de la institución educacional,
Número de serie del master,
IP del master,
Versión del software utilizado,
Fecha de inicio,
Fecha de término, y
Conjunto de eventos. Restricciones:
1. El número de serie del master e identificador de la institución
educacional serán únicos.
2. El resumen de userlog puede contener eventos de uno o más
userlogs.
67
3. La versión del software utilizado será la del primer userlog utilizado
en el resumen. Clase de dominio: Master.
Objeto de información: Datos del reporte.
Atributos:
Nombre del reporte,
Nombre de la institución educacional,
Identificador de la institución educacional,
Identificador del master,
Fecha de inicio,
Fecha de término, y
Conjunto de registros (datos del reporte). Restricciones:
1. El detalle del reporte varía dependiendo del tipo de reporte. Clase de dominio: Listado de datos.
68
Objeto de información: Reporte.
Atributos:
Encabezado (representación de los datos del reporte).
Detalle del reporte (representación de los datos del reporte). Restricciones:
1. Un reporte puede tener una o más representaciones. Clase de dominio: Reporte.
69
5 CAPÍTULO IV: MODELADO DE REQUISITOS
En este capítulo se identifican los requisitos funcionales y no funcionales del
sistema. En este proyecto los requisitos funcionales son derivados de la
etapa de modelado de negocio; los requisitos no funcionales también se
obtienen de modelado de negocio y son complementados con nuevos
requisitos no identificados en la etapa anterior del proceso de desarrollo.
5.1 Obtención de Casos de Uso
El rol identificado es el Usuario Edunova, que incluye a investigador
pedagógico, soporte pedagógico, ingeniero de tecnología web, ingeniero de
tecnología móvil y soporte técnico Edunova. Por otro lado como las
actividades del proceso de negocio Generar reportes son genéricos, se han
Identificado los casos de uso Obtener reporte y Obtener reporte de actividad
grupal, los reportes identificados son:
• Reporte de actividades grupales,
• Reporte de actividad colaborativa,
• Reporte de actividad de evaluación,
• Reporte de actividad de presentación, y
70
• Reportes verbales de subconjuntos de eventos.
Figura 5.1: Diagrama de casos de uso del sistema.
5.2 Descripción de Casos de Uso
Caso de uso: Obtener reporte.
Descripción: El Usuario Edunova solicita un reporte y el sistema muestra
el reporte solicitado.
Actores: Usuario Edunova.
Pasos:
1. El usuario ingresa al sistema.
2. Selecciona la institución educacional.
3. Selecciona un reporte.
4. Selecciona fecha inicial y final del reporte.
5. Solicita el reporte y el sistema genera el reporte.
71
Precondiciones:
1. El usuario debe tener permiso sobre el sistema de reportes de uso. Poscondiciones:
Variaciones:
1. Usuario inválido, el sistema rechaza el ingreso y muestra mensaje de
error.
3. Si el tipo de reporte no incluye todos los master de la institución
educacional, entonces se debe seleccionar número de IP del master.
Continuar con el paso 4.
5.a El usuario no ha seleccionado alguno de los datos de entrada, el
sistema muestra mensaje de selección de datos no realizada.
5.b Si el reporte es de actividades grupales (todas las actividades
colaborativas, de evaluación, y de presentación), entonces, extender
caso de uso obtener reporte de actividad grupal. Requisitos no funcionales:
1. El tiempo de respuesta debe ser menor a 30 segundos.
Caso de uso: Obtener reporte de actividad grupal.
72
Descripción: El usuario Edunova, desde el reporte de actividades
grupales, solicita el reporte de una actividad grupal en particular
(colaborativa).
Actores: Usuario Edunova.
Pasos:
1. El usuario Edunova selecciona una actividad en particular.
2. El sistema muestra el reporte de la actividad seleccionada. Precondiciones: No hay.
Poscondiciones: No hay.
Variaciones:
1. Si no hay datos o la actividad colaborativa no fue desarrolla
correctamente, el sistema muestra mensaje de datos no suficientes. Requisitos no funcionales:
1. El tiempo de respuesta debe ser menor a 30 segundos.
5.3 Obtención del Modelo Conceptual
73
En la Figura 5.2 se presenta el diagrama conceptual inicial: el usuario
Edunova genera un reporte, un reporte usa un conjunto de eventos de
interés, el reporte incluye a uno o más masters, cada master tiene un
resumen de userlogs que considera a los eventos de uno o más userlogs que
sean de interés para confeccionar el reporte. Finalmente con los resúmenes
de userlogs se obtienen un listado de datos para el reporte.
Figura 5.2: Modelo Conceptual Inicial.
74
5.4 Requisitos no Funcionales
Requisitos de interfaz de usuario:
1. El sistema debe mantener la interfaz de los sistemas de Intranet de
Edunova.
2. El sistema debe tener una interfaz intuitiva.
3. El sistema debe ser adaptable a cualquier idioma. Requisitos de implementación:
1. El sistema debe integrarse con aplicaciones y datos existentes de
Edunova. Esto implica utilizar la plataforma .NET de Microsoft.
2. Las consultas a base de datos deben ser mediante procedimientos
almacenados.
3. Se debe utilizar el formato estándar XML.
4. El sistema debe ser mantenible y extensible.
5. El sistema principal de Edunova se encargará del ingreso a la
Intranet, el sistema a desarrollar debe controlar permisos de acceso
75
a los reportes. Requisitos de software:
1. Los clientes deben tener Internet Explorer 5.5 o superior.
El servidor web será Internet Information Server que se ejecutará
sobre el sistema operativo Windows 2003 Server.
El sistema gestor de base de datos será SQL Server 2000 y se
ejecutará sobre el sistema operativo Windows 2003 Server.
2. El servidor web que alojará al sistema debe poseer el Framework
.NET 1.1 o superior.
76
6 CAPÍTULO V: MODELADO DE ANÁLISIS
En este capítulo se muestra la interacción del usuario con el sistema a través
de diagramas de secuencia donde el sistema se representa como una caja
negra.
La Figura 6.1 muestra el caso en que el usuario Edunova selecciona un
reporte que incluye la información de todos los masters de una institución
educacional (por ejemplo, el reporte de Actividades grupales incluye
implícitamente a todos los masters que se utilizaron en una clase).
Figura 6.1: Diagrama de secuencia del caso de uso Obtener Reporte.
77
El usuario Edunova también puede seleccionar un reporte que considere la
información de un solo master, esta situación se muestra en el diagrama de
la Figura 6.2.
Figura 6.2: Diagrama de secuencia del flujo alternativo del caso de uso Obtener Reporte.
Además, desde el reporte de Actividades grupales se puede acceder a las
actividades realizadas (ver Figura 6.3).
78
Figura 6.3: Diagrama de secuencia del caso de uso Obtener Reporte de Actividad Grupal.
79
7 CAPÍTULO VI: MODELADO DE DISEÑO
En este capítulo se presentan los modelos que muestran la arquitectura del
sistema que se implementó.
7.1 Modelo de la Solución
La relación entre un compilador y este proyecto es evidente; se debe
transformar un conjunto de archivos userlogs en reportes, donde cada
userlog está formado por eventos (símbolos). Un evento puede contener
parámetros.
Un reporte tendrá un AFD asociado con las siguientes características:
1. El alfabeto de entrada será un conjunto de eventos de interés para
confeccionar el reporte.
2. Los estados se definirán de acuerdo a las necesidades del reporte, de
tal manera que permitan distinguir patrones de secuencia de eventos
que tengan un significado para el reporte y sean trasformados en datos
para el reporte. Un estado es una secuencia de “eventos” reconocidos.
3. Existirá un estado inicial q0, un conjunto de estados finales F.
80
4. La función de transición incluirá a los parámetros de los eventos de ser
necesario, es decir, dado un estado y un evento-símbolo, el resultado
de la transición pueden ser estados diferentes dependiendo de los
valores de los parámetros del evento-símbolo.
5 Pueden existir reportes donde no se necesiten transiciones, ya que
todos los eventos formarán parte del reporte.
El esquema general se puede apreciar en la Figura 7.1:
1. El usuario Edunova solicitará un reporte.
2. Se solicitará la información del reporte y los eventos correspondientes a
la base de datos.
3. Se retornará la definición del reporte solicitado y los eventos de interés.
4. El AFD procesará los eventos y se generarán los datos para el reporte.
5. Los datos serán formateados para ser mostrados.
81
Figura 7.1: Esquema de la solución general.
7.2 Arquitectura Lógica
Se adapta el modelo de 5 capas mostrado en capítulo III:
1 Presentación: Presenta los datos y maneja las entradas del usuario.
82
2. Lógica de flujo de trabajo: Controla el flujo entre las otras capas.
3. Lógica de negocio: Procesa y transforma la información.
4. Lógica de acceso a datos: Se preocupa de acceder a las fuentes de
datos.
5. Fuentes de datos: Contienen los datos.
En la Figura 7.2 se puede apreciar la estructura lógica de cinco capas a
través de un diagrama de paquetes. Las clases del paquete Controllers
heredarán de las clases proporcionadas por el paquete Multilanguage,
obtendrán los datos a través de los servicios entregados por el paquete
SQLconnection, traspasarán los datos a clases del paquete Reports, el
paquete Reports junto a los demás paquetes del dominio procesarán los
datos para obtener información del reporte. Finalmente, una vez que se
hayan procesados los datos, éstos serán entregados al clases del paquete
Presentation que se preocuparán de crear la interfaz del sistema. Cabe
mencionar que la capa de acceso a datos es una componente desarrollada
por Edunova, de la cual sólo se utilizaron sus servicios.
83
Figura 7.2: Diagrama de paquetes, arquitectura lógica del sistema.
84
7.3 Arquitectura Física
La arquitectura física muestra el sistema desde el punto de vista hardware.
Las arquitecturas lógica y física se pueden relacionar de manera de asociar
capas lógicas sobre capas físicas donde se ejecutan, como lo muestra la
Figura 7.3 y la Tabla 7.1:
Figura 7.3: Diagrama de despliegue, arquitectura física.
Capa Lógica Tecnología Capa Física Tipo de ejecución
Presentación HTML Cliente Interpretado
Presentación Java Script Cliente Interpretado
Presentación ASPX Servidor Interpretado
Presentación XML / XSLT Servidor Interpretado
85
Negocio, Acceso a Datos
y Flujo de Trabajo
Visual Basic .NET Servidor Compilado
Datos (Procedimientos
almacenados)
Transact SQL Servidor BD Compilado
Tabla 7.1: Tecnologías utilizadas.
7.4 Diagramas de Clases de Implementación
A continuación se presentan los diagramas de clases de implementación, los
cuales fueron refinados del diagrama conceptual inicial. Las clases están
agrupadas en paquetes.
La Figura 7.4 muestra el paquete MobileDevice, que se encarga de reunir los
eventos de entrada para el AFD. La clase Master posee los eventos
utilizados por el reporte (m_xmlEventList), los que serán procesados para
generar nuevos datos (m_xmlItemDocument) necesarios para confeccionar
el reporte. La clase MasterCollection hereda de la clase CollectionBase
proporcionada por las librerías del Framework .Net y es una colección de los
masters necesarios para construir un reporte.
86
Figura 7.4: Componente MobileDevice.
El componente Parser (Ver Figura 7.5) se preocupa de analizar las entradas
de los eventos proporcionados por la componente MobileDevice. La clase
AFD encapsula las funcionalidades de un Autómata Finito Determinista.
87
Figura 7.5: Componentes de Parser.
88
El paquete ActivityResult (Ver Figura 7.6) contiene clases que facilitan el
manejo de la información en algunos reportes. La clase Grid representa la
grilla o matriz de resultados (grupo, pregunta) para un reporte de actividad
colaborativa o de evaluación. Las clases que componen este paquete
pueden aumentar de acuerdo a las necesidades de manejo de datos en los
reportes, pudiendo crearse nuevos paquetes si es necesario.
Figura 7.6: Paquete ActivityResult.
89
El paquete Reports (ver Figura 7.7) está formado por la clase abstracta
ReportBase, que representa las funcionalidades básicas de un reporte. Todo
reporte debe contener un AFD y una colección de masters para poder
generar un documento XML (m_reportDocument) con los datos exactos que
se deben mostrar, para ello cada reporte heredará de ReportBase e
implementará los métodos Parse y SetBodyOfReport. El método Parse se
debe encargar de generar nuevos datos a partir de los estados del AFD, el
método SetBodyOfReport organizará y dará estructura a los datos
generados.
90
Figura 7.7: Componente Reports.
El paquete Multilanguage se preocupa de coordinar el sistema con un idioma
determinado. Este paquete fue implementado principalmente por Edunova, y
en este proyecto se agregó la clase MultilanguagePageWebControls que
91
tiene la misma filosofía de la clase MultilanguagePage implementada por
Edunova.
Figura 7.8: Componente MultilanguagePage.
El paquete Controllers maneja el flujo de datos entre la capa de
presentación, capa de lógica de negocios y la capa de acceso a datos. Cada
clase de este paquete hereda de MultilanguagePage,
MultilanguagePageWebControls o Page (de .net Frameworks) y tiene
asociado los elementos del paquete Presentation, que está formado por
archivos: XML, XSLT, Java Script, y ASPX.
92
Figura 7.9: Clases genéricas de los paquetes Controllers y Presentation.
93
El paquete SQLConection está formado por una clase que permite realizar
en forma simple y transparente llamados a procedimientos almacenados, los
aspectos de conexión a la base de datos están ocultos.
Para mayor detalle sobre los atributos y métodos de las clases ver Anexo B.
7.5 Diseño de Base de Datos
El último paquete implementado fue el de StoredProcedures que esta
compuesto por seis procedimientos almacenados:
1. pr_XML_SULSaveUserlog: Almacena un userlogs en la base de datos.
2. pr_XML_SULSaveReport: Recibe la definición en formato XML de un
reporte y lo almacena en la base de datos.
3. pr_XML_SULGetReportMenu: Se encarga de entregar los datos para la
selección de reportes en el menú principal.
4. pr_XML_SULGetMaster: Se encarga de obtener los master para los
reportes que necesitan la información de más de un master.
5. pr_XML_SULGetReportDefinition: Obtiene la definición de un reporte
(AFD).
94
6. pr_XML_SULGetUserlogs: Retorna los eventos de un master para un
reporte específico en un período de tiempo.
Los procedimientos pr_XML_SULSaveUserlog y pr_XML_SULSaveReport se
utilizan para poblar la base de datos y no están conectados al sistema
implementado; los demás procedimientos se encargan de entregar los datos
(en formato XML) para poder generar un reporte.
95
Figura 7.10: Paquete StoredProcedures.
96
El diseño de la base de datos se puede apreciar en la Figura 7.11, las tablas
se pueden organizar de la siguiente forma:
1. Tablas que almacenen los userlogs: PPC, USERLOG,
USERLOG_EVENT, EVENT_PARAMETER, EVENT y PARAMETER.
Un Dispositivo móvil (PPC) registra USERLOGs, un USERLOG
contiene uno o más ocurrencias de eventos (USERLOG_EVENT) un
evento (EVENT) tiene parámetros (PARAMETER) y los valores para los
parámetros son guardados en EVENT_PARAMETER.
2. Tablas que almacenan la definición del los reportes: REPORT, STATE,
SYMBOL, TRANSITION, CONDITION, SYMBOL_PARAMETER, y
PARAMETER_VALUE. Un reporte tiene símbolos (SYMBOL) y estados
(STATE). Una transición (TRANSITION) tiene un estado actual, un
símbolo actual, un estado siguiente y puede tener condiciones
(CONDITION). Las condiciones están asociadas a valores de los
parámetros de los símbolos (SYMBOL_PARAMETER) y el universo de
parámetros se puede restringir a un conjunto finito de valores
(PARAMETER_VALUE). Además un reporte tiene características
representadas por las tablas TYPE y REPORT_TYPE.
97
Para visualizar mejor el diseño de base de datos se pueden ver la Figura
7.11 y la Figura 7.12.
98
Figura 7.11: Diseño de base de datos con UML.
99
Figura 7.12: Diseño de base de datos para SQL Server 2000.
100
8 CAPÍTULO VII: IMPLEMENTACIÓN
En este capítulo se presentan los resultados al materializar los diseños
anteriores en componentes de software.
8.1 Reporte de Actividades Grupales
Para explicar como se obtienen los reportes se toma como ejemplo el
Reporte de Actividades grupales realizadas, que obtiene todas las
actividades desarrolladas en un período de tiempo. Su definición es:
101
Figura 8.1: Definición del Reporte de actividades grupales.
La Figura 8.2 muestra el resultado luego de la transformación de los eventos
utilizados en el reporte de Actividades grupales realizadas.
102
Figura 8.2: Extracto de los datos generados en el reporte de Actividades grupales realizadas.
103
El AFD del reporte de actividades grupales realizadas se puede apreciar en
la Figura 8.3:
Figura 8.3: AFD para el reporte de Actividades grupales realizadas.
Para mayores detalles sobre los eventos ver el Anexo C.
8.2 Interfaz del Sistema
104
A continuación se muestran las pantallas para obtener el reporte de
Actividades grupales realizadas. La Figura 8.4 muestra el menú principal,
desde donde se pueden seleccionar los reportes y la Figura 8.5 muestra el
reporte de Actividades grupales realizadas. Desde este reporte se pueden
acceder a los reportes de las actividades realizadas.
Figura 8.4: Menú principal de reportes.
105
Figura 8.5: Reporte de Actividades grupales realizadas.
En la Figura 8.6 se muestra el reporte de una actividad colaborativa. En ella
se pueden apreciar los grupos participantes (filas) y las preguntas
(columnas). Los colores muestran el resultado del grupo en la pregunta. Lo
mismo se puede apreciar en la Figura 8.7 para una actividad de evaluación.
Los colores varían (de negro a blanco) entre rojo, verde, amarillo y blanco.
106
Figura 8.6: Reporte de Actividad colaborativa.
Figura 8.7: Reporte de una Actividad de evaluación.
107
9 CONCLUSIONES
Se ha utilizado la adaptación de un proceso de desarrollo ampliamente
conocido y aceptado como RUP a un proyecto web pequeño, permitiendo
guiar las diferentes etapas del desarrollo disminuyendo riesgos y asegurando
la trazabilidad entre las diferentes etapas.
Los componentes desarrollados tienen bases técnicas como las de los
Autómatas Finitos Deterministas, ampliamente usadas, sencillas, y flexibles.
También se adecuó el modelo de N-capas para separar los componentes de
acuerdo a su funcionalidad, para asegurar mantenibilidad, extensibilidad,
reuso y flexibilidad.
Los componentes de negocio son independientes de la fuente de información
y de la forma de presentación, permitiendo replicar esta solución en otros
sistemas similares, adaptándose a diferentes orígenes de datos y forma de
presentación de los reportes.
El trabajo realizado permite acortar el tiempo dedicado en la obtención de
nuevos reportes; se definió un estándar para su especificación, el
procesamiento de los datos es genérico y ya fue implementado.
108
El sistema puede adaptarse a los cambios (eliminación, creación y
modificación) de los eventos considerados para generar reportes,
asegurando flexibilidad y mantenibilidad.
El sistema desarrollado ha sido integrado a los demás sistemas de Edunova,
actualmente está siendo utilizado y los reportes obtenidos son fieles a la
realidad, lo que se traduce en la disminución de los tiempos utilizados en el
análisis del el uso de dispositivos móviles.
En la implementación de la interfaz del sistema se han utilizado conceptos y
abstracciones del dominio facilitando la comprensión y lectura de los
reportes.
9.1 Trabajos Futuros
El objetivo estratégico identificado en la etapa de modelado de negocio es
“Mejorar las soluciones educativas de Edunova”, objetivo a mediano y largo
plazo. En esta línea, el ambiente desarrollado debe evolucionar para
entregar reportes que permitan visualizar nuevos aspectos sobre el uso de la
109
tecnología. Se prevé desde el punto de vista del diseño que esto no será
difícil debido a las características del sistema desarrollado.
Se propone un subsistema que permita identificar posibles reportes
(relaciones entre eventos), su especificación (utilizando el estándar ya
definido en este proyecto) y posterior publicación.
Por último se plantea automatización del proceso de negocio Consolidar
información para disminuir los tiempos y riesgos en la captura de los datos.
110
10 BIBLIOGRAFÍA
[Aho90] Alfred Aho, Ravi Sethi, Jeffrey Ullman. Compiladores principios,
técnicas y herramientas. Addison Wesley. 1990.
[Edu04] Edunova. Tecnología portátil en la sala de clases, Manual del
Profesor. Pontificia Universidad Católica de Chile. 2004.
[Gar01] David García Gil. Definición y aplicación de un proceso software
basado en UML para el desarrollo de aplicaciones Web. Universidad de
Murcia, España. 2001.
[Gar02] Jesús García Molina, María José Ortín, Begoña Moros, Joaquín
Nicolás. “Transforming the OOram Three-Model Architecture into a UML-
based Process”. Universidad de Murcia, España. 2002.
[Gor02] Davor Gornik, UML Data Modeling Profile. Rational Software
Corporation.
[Kru04] Philippe Kruchten. An Introduction to the Rational Unified Process.
Addison Wesley. 2004.
[Lar99] Craig Larman. “UML y patrones”. Prentice Hall. 1999.
[Mic03] Microsoft. MDSN Library. Microsoft Corporation. 2003.
[Ort99] María José Ortín Ibáñez, Jesús García Molina. Modelado basado en
111
roles con UML. Universidad de Murcia, España. 1999.
[Ort00] María José Ortín Ibáñez, Jesús García Molina, Begoña Moros,
Joaquín Nicolás. El modelo de Negocio como base Del Modelo de
Requisitos. Universidad de Murcia, España. 2000.
[Rat00] Rational Whitepaper. The UML and Data Modeling, Rational
Software Corporation.
[Spa01] Geoffrey Sparks.Database Modeling in UML. Martinig & Associates.
[Sin02] Inderjeet Singh, Beth Stearns, Mark Johnson, and the Enterprise
Team. Designing Enterprise Applications with the J2EE Platform, Addison
Wesley. 2002.
[Ses01 ]Roger Sessions, “Java 2 Enterprise Edition (J2EE) versus The .NET
Platform Two Visions for eBusiness”, ObjectWatch Inc.
[Tro03] David Trowbridge, Dave Mancini, Dave Quick, Gregor Hohpe, James
Newkirk and David Lavigne. Enterprise Solution Pattners Using Microsoft
.NET. Microsoft Corporation. 2003
112
11 ANEXO A: LA PLATAFORMA .NET
La plataforma .NET es la reunión de un conjunto de tecnologías dispersas,
algunas de las cuales ya existían y que Microsoft ha integrado con el objetivo
de facilitar el desarrollo de aplicaciones distribuidas en Internet. Algunas de
sus componentes son:
11.1 Common Language Runtime y .NET Framework Class Library
Common Language Runtime (CLR) es el entorno que administra y ejecuta
código de aplicaciones .NET. El conjunto de bibliotecas integradas de .NET
sobre las cuales se desarrollan aplicaciones es conocido como .Net
Framework Class Library.
El CLR permite tanto la ejecución de código administrado (managed code) y
código no administrado (unmanaged code). El código administrado sólo
ocupa bibliotecas de .NET mientras que el código no administrado utiliza
bibliotecas externas a .NET. El CLR se ejecuta sobre el sistema operativo y
es el único intérprete entre las aplicaciones de código administrado y el
sistema operativo. El código administrado hace uso de las clases de la
113
biblioteca .NET Framework y de las bibliotecas propias o externas del
desarrollador. Por otro lado, el código no administrado hace uso directo del
sistema operativo, sin pasar por la supervisión del CLR.
Existe un segundo CLR que ejecuta los servicios Web y aplicaciones
ASP.NET, siendo específico para funcionar sobre Internet Information Server
(IIS) y hace uso de las funcionalidades adicionales y restricciones de este
entorno.
Otra característica de .NET es que soporta más de un lenguaje de
programación como Visual Basic. NET, C++ .NET, C #, Cobol, J # etc.
114
Figura 11.1: Modelo de ejecución en .NET.
En la Figura 11.1 se muestra el modelo de ejecución de .NET:
1. Dependiendo del lenguaje de programación utilizado, el compilador de
.NET para ese lenguaje genera Microsoft Intermediate Language MSIL.
2. El código MSIL antes de ejecutarse se compila nuevamente a código
nativo de una arquitectura en particular, esto es conocido como
compilación “Just in Time” y se realiza la primera vez que se ejecuta el
código.
115
3. Cuando se realiza la ejecución del código nativo (código administrado)
el CLR proporciona un conjunto de servicios, tales como: seguridad,
chequeo de datos, administración de memoria, etc.
11.2 Microsoft ActiveX Data Objects .NET y XML
En la Figura 11.2 se pueden apreciar otros componentes de la Plataforma
.Net. ADO.NET es una librería que permite acceder ya sea a base de datos o
a información en formato XML, desde una aplicación web multicapa, desde
servicio web, o una aplicación Windows Forms.
Figura 11.2: La Plataforma .NET.
116
.NET provee soporte para el acceso y manipulación de datos en formato
XML mediante: Extensible Stylesheet Language Transformation (XSLT) o el
conjunto de clases que permiten manipular documentos XML para procesar
su información o transformarlos a otros formatos.
11.3 ASP.NET
Es un modelo que permite separar el código HTML y la lógica de la
aplicación. Una página ASP.NET tiene extensión .aspx y está asociada a una
clase (Visual Basic, C #, C++, etc), que encapsula la lógica de la aplicación,
proporcionando un alto rendimiento ya que las clases son compiladas. A
través de estas páginas se puede tener acceso a un conjunto de controles y
componentes proporcionados por .NET. Los controles de servidor se usan
para crear la interfaz del usuario para la aplicación Web. La Figura 11.3
muestra las características de una pagina ASP.NET. La página ASP.NET
hereda de la clase que encapsula la lógica de aplicación, su modo de
ejecución es interpretado y genera código HTML como respuesta.
117
Figura 11.3: Modelo de uso de una página ASP .NET.
11.4 Otras Características
.NET no es la primera plataforma que permite la integración de servicios y
desarrollo de aplicaciones distribuidas sobre Internet; le antecede la
Plataforma Java 2 Enterprise Edition (J2EE) de Sun Microsystems que ha
sentado las primeras bases de sistemas sobre Internet y entornos
distribuidos. Como se puede apreciar en la Tabla 11.1 la filosofía y conceptos
de estas dos plataformas son similares [Ses01]:
118
Característica .NET J2EE
Tipo de tecnología Producto Estándar
Empresa que lo
ofrece
Microsoft Más de 30
Librerías de
desarrollo
.NET Framework SDK Java core API
Intérprete Common Language
Runtime (CLR)
Java Runtime Environment
(JRE)
Páginas dinámicas Active Server Pages .NET
(ASP.NET)
Servlets, Java Server Page
(JSP)
Componentes .NET Managed
Components
Enterprise Java Bean
(EJB)
Acceso a bases de
datos
Microsoft ActiveX Data
Objects (ADO.NET)
Java Database
Connectivity (JDBC),
SQL/J
Servicios Web Simple Object Access Protocol(SOAP), Web Service
Description Language(WDSL), Universal Description,
Discovery and Integration(UDDI), eXtensible Markup
Languaje(XML)
119
Interfaces gráficas Win Forms y Web Forms Java Swing
Herramienta de
desarrollo
Visual Studio .NET Depende del fabricante
Transacciones
distribuidas
Distributed Transaction
Coordinator (DTC)
Java Transaction Service
(JTS)
Servicios de
directorios
Active Directory Services
Interfaces (ADSI)
Java Naming and Directory
Interface (JNDI)
Librería de
encolado de
mensajes
Microsoft Message Queuing
Services (MSMQ)
Java Message Service
(JMS)
Lenguajes
utilizados
C Sharp (C#), Visual Basic,
C++, J#, otros
Java
Lenguaje
intermedio
Microsoft Intermediate
Language (MSIL)
Java Byte codes
Tabla 11.1: Comparación de las Plataformas .NET y J2EE.
.NET y J2EE son Plataformas evidentemente similares, más aún si se
considera el proyecto MONO de Ximian está desarrollando la Arquitectura
.NET para Linux, con lo que .NET se puede considerar como multiplataforma
y estándar.
120
12 ANEXO B: FIGURAS DE CLASES DE
IMPLEMENTACIÓN
En este anexo se presentan las clases de implementación que no pudieron
ser mostradas completamente en el capítulo VII.
121
Figura 12.1: Clases del paquete ActivityResult.
122
Figura 12.2: Clases del paquete Parser (1 de 2).
123
Figura 12.3: Clases del paquete Parser (2 de 2).
124
13 ANEXO C: DESCRIPCIÓN DE LOS EVENTOS DEL
REPORTE DE ACTIVIDADES GRUPALES REALIZADAS
En este anexo se describen los eventos considerados en la confección del
reporte de Actividades grupales realizadas, no todos los parámetros
descritos fueron considerados en la confección de este reporte.
actmmngstart: El master fue reseteado.
1. mode: master ó slave.
selnet: Se selecciona e inicia un número de red.
1. number: Número de red creada.
2. group: Nombre del grupo (curso) elegido.
3. subgroup: Nombre del subgrupo elegido.
4. chanel: Canal elegido.
5. groupid: Identificador del grupo elegido.
6. subgroupid: Identificador del subgrupo elegido.
125
exeactgroup: Comenzó la ejecución de la actividad en modo grupal.
1. file: Archivo a ejecutar.
2. display: Nombre de la actividad.
3. total: Cantidad de slaves en la red.
4. failed: Cantidad de slaves que han fallado hasta el momento.
actloaded: Terminó de cargar la actividad en memoria, y comienza la
ejecución.
1. failed: Cantidad de slaves que han fallado hasta el momento.
actfinishedgroup: Terminó actividad en modo grupal
actfinishedgroupdefault: Se reseteo el master antes de terminar una actividad
en modo grupal. Este es un evento artificial, representa a cualquier evento
perteneciente a una actividad (de presentación, de evaluación o colaborativa)
y es definido para manejar las situaciones de actividades que no han
terminado correctamente.