jskanken - iit | instituto de investigacion tecnológica · kanjis, aprender kanjis, kanji kentei,...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA

JSKanken

Plataforma de estudio y preparación de exámenes oficiales de lengua japonesa

Autor: Serrano Mata, Jesús María Director: Pérez-Campanero Atanasio, Juan Antonio

Madrid Mayo 2012

Autorizada la entrega del proyecto del alumno/a:

Jesús María Serrano Mata

EL DIRECTOR DEL PROYECTO

Juan Antonio Pérez-Campanero Atanasio

Fdo.: …..................................... Fecha: ………. /………. /……….

Vº Bº del Coordinador de Proyectos

David Contreras Bárcena

Fdo.: …..................................... Fecha: ………. /………. /……….

AGRADECIMIENTOS

Mi agradecimiento a todas aquellas personas que me han ayudado a terminar este proyecto, y a

cumplir mis expectativas durante este último año de carrera. En especial a:

A mi hermano y mis padres, por darme ánimos para finalizarlo, y que no me

desviase del camino.

A Beatriz, por su paciencia al escuchar todas las quejas y problemas que me

han surgido durante todo el año, y por apoyarme hasta el final.

A Iron, mi compañero que siempre ha estado a mi lado.

Y por último, a Juan Antonio, mi director y profesor durante la carrera que

siempre me ha dado la posibilidad de realizar mis metas.

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

INGENIERO INFORMÁTICO

Cap

ítu

lo:

I

JSKANKEN – PLATAFORMA DE ESTUDIO Y PREPARACIÓN DE

EXÁMENES OFICIALES DE LENGUA JAPONESA

Autor: Serrano Mata, Jesús María

Director: Pérez-Campanero Atanasio, Juan Antonio

RESUMEN DEL PROYECTO

Palabras claves: Estudiar japonés, web de estudio, practicar japonés, escritura

japonesa, preparación de exámenes, exámenes oficiales de japonés, escritura de

kanjis, aprender kanjis, kanji kentei, kanken.

En los últimos años, se ha ido incrementando de forma significativa el número de

estudiantes que se interesan por el idioma japonés. Uno de los últimos estudios

realizados por la “Japan Foundation” en 2009 sobre el número de extranjeros que se

interesan por el idioma nipón, revela que en ese año, 2009, existían en total 3.651.232

estudiantes. Solamente en Europa Occidental, los estudiantes de japonés registrados

han aumentado, prácticamente doblado, desde el año 2008 (47.451 estudiantes) hasta el

año del estudio, 2009 (72.594 estudiantes).

Datos estadísticos de la Japan Foundation 1



Cap

ítu

lo: R

ES

UM

EN

DE

L P

RO

YE

CT

O

II

El desarrollo de este proyecto consiste en poner a disposición de estos estudiantes,

más de tres millones de estudiantes, una plataforma online que les facilite el

estudio y aprendizaje del idioma japonés y así poder afrontar de una forma más

rápida los exámenes oficiales de lengua japonesa.

Para lograrlo, se ha desarrollado una plataforma que abarca el primer nivel de escritura

japonesa compuesto por un total de 80 kanjis, también denominado kanken kentei shiken.

Mediante la plataforma, el estudiante de japonés podrá realizar dos tipos de tareas:

Aprendizaje del idioma.

Preparación de exámenes.

Lo más novedoso y que distingue a esta plataforma de otras que puedan existir, es la

capacidad de poder practicar la escritura, dibujando el kanji dentro de la plataforma

a mano alzada.

Esto se ha conseguido creando un OCR para la plataforma que reconoce los 80 kanjis

que contiene el examen en el que se centra el desarrollo del proyecto. Como se puede

ver con el siguiente ejemplo pueden surgir problemas a la hora de reconocer un kanji:

右石

Para recoger el dibujo a mano alzada

introducido por el usuario en la plataforma,

se ha decidido emplear el canvas de

HTML5. El OCR recibirá la imagen del

mismo, y además un parámetro de control

que contendrá todos los trazos del dibujo

con la siguiente estructura:

(XI, YI, XF, YF, FF);



Cap

ítu

lo: R

ES

UM

EN

DE

L P

RO

YE

CT

O

III

Las variables de la estructura anterior son:

XI: Punto del eje de abscisas o eje X, inicial.

YI: Punto del eje de ordenadas o eje Y, inicial.

XF: Punto del eje de abscisas o eje X, final.

YF: Punto del eje de ordenadas o eje Y, final.

FF: Frecuencia de puntos que contiene el trazo, es decir, depende de la longitud

del trazo y la rapidez de escritura.

Ideogramas japoneses que reconoce la aplicación una vez el usuario los escriba de

forma correcta:

一百下口森犬学白十九

二千左人田虫校青上土

三日右子空貝先円耳目

四月大女雨石生正林川

五火中男天王字早竹草

六水小名気玉文入音車

七木手年夕力本出赤町

八金足山花糸村立見休

El desarrollo de esta plataforma ha sido realizado, en su mayoría, en PHP.



Cap

ítu

lo: R

ES

UM

EN

DE

L P

RO

YE

CT

O

IV



Cap

ítu

lo: A

BS

TR

AC

T

V

JSKANKEN – STUDY PLATFORM AND OFFICIAL EXAM

PREPARATION FOR JAPANESE LANGUAGE

Author: Serrano Mata, Jesús María

Supervisor: Pérez-Campanero Atanasio, Juan Antonio

ABSTRACT

Keywords: Japanese study, study website, Japanese practice, Japanese writing, test

Preparation, Japanese official test, kanji writing, learn kanji, kanji kentei, kanken.

In recent years, the number of students who are interested in the Japanese language

has increased significantly. One of the latest studies conducted by the

"Japan Foundation" in 2009 on the number of foreign students, who are interested

in Nippon language, reveals that in that year, 2009, there were a total

of 3,651,232 students. Only in Western Europe, Japanese registered students have

increased, almost doubled from the year 2008 (47.451 students) to the year that study

was made in 2009 (72.594 students).

Statistical data of the Japan Foundation 1



Cap

ítu

lo: A

BS

TR

AC

T

VI

The purpose of this project is to make available to these students, which are more than

three million students, an online platform that facilitates the study and learning the

Japanese language so they can face the official test of Japanese language in a quicker

way.

To achieve this, it has developed a platform which covers the first level of Japanese

writting composed by a total of 80 kanji, also called Kanken Kentei shiken.

Through the platform, the Japanese student may perform two types of tasks:

Language Learning.

Exam preparation.

The newest and most distinguishes of this platform, than others that may exist is

the ability to practice writing, drawing the kanji within the platform by hand.

This was achieved by creating a platform OCR for recognizing the 80 kanji containing

the test that focuses on project development. As you can see by the following

example can arise when recognizing a kanji:

右石

To collect the freehand drawing input by

the user on the platform, we decided to

use the HTML5 canvas. The OCR will

receive the image of it, and also a control

parameter containing all the lines of the

drawing with the following structure:


Variables of the above structure are:

XI: Point the abscissa or X axis,

initially.



Cap

ítu

lo: A

BS

TR

AC

T

VII

YI: Point ordinate axis or Y axis, initially.

XF: Point the abscissa or X axis, final.

YF: Point ordinate axis or Y axis end.

FF: Frequency of points that contains the line, that is, depends on the length of

the stroke and speed of writing.

Japanese ideograms recognizes the application once the user enter correctly:

一百下口森犬学白十九

二千左人田虫校青上土

三日右子空貝先円耳目

四月大女雨石生正林川

五火中男天王字早竹草

六水小名気玉文入音車

七木手年夕力本出赤町

八金足山花糸村立見休

The development of this platform has been mostly done in PHP.



Cap

ítu

lo: A

BS

TR

AC

T

VIII



Cap

ítu

lo: In

trod

ucc

ión

1

ÍNDICE DE LA MEMORIA

1. Introducción ................................................................................................................ 9

1.1. Definición del proyecto ................................................................................................. 9

1.2. Conceptos básicos ........................................................................................................... 9

1.2.1. RIA (Rich Internet Application) ......................................................................... 9

1.2.2. OCR ......................................................................................................................... 10

1.2.3. KANJI ..................................................................................................................... 10

1.3. Estudio del mercado actual......................................................................................... 11

1.3.1. Fase de estudio ...................................................................................................... 11

1.3.2. Fase de Interacción/Práctica ............................................................................. 13

1.4. Motivación del proyecto ............................................................................................. 15

2. Alcance del proyecto ............................................................................................... 21

2.1. Introducción al ámbito del proyecto ........................................................................ 21

2.1.1. Exámenes oficiales de Nivel de Lengua Japonesa ......................................... 21

2.2. Definición del ámbito del proyecto ........................................................................... 24

3. Identificación de necesidades ................................................................................ 29

3.1. Introducción ................................................................................................................... 29

3.2. Documento de Concepto del Sistema ....................................................................... 30

3.2.1. Objetivos ................................................................................................................ 30

3.2.2. Partes del sistema ................................................................................................. 31

4. Especificación ........................................................................................................... 37

4.1. Reconocimiento del problema .................................................................................... 38

4.2. Contexto general de la plataforma ........................................................................... 39

4.3. Requisitos de la plataforma ........................................................................................ 40

4.3.1. Requisitos Funcionales ....................................................................................... 42



Cap

ítu

lo: In

trod

ucc

ión

2

4.3.2. Requisitos de Interfaz .......................................................................................... 50

4.3.3. Requisitos de Calidad .......................................................................................... 54

4.3.4. Requisitos de Proyecto ........................................................................................ 56

4.3.5. Requisitos de Evolución ...................................................................................... 57

4.3.6. Requisitos de Soporte .......................................................................................... 58

5. Diseño de la plataforma .......................................................................................... 61

5.1. Jerarquía de usuario ..................................................................................................... 62

5.2. Casos de uso ................................................................................................................... 63

5.2.1. Diagrama de caso de uso para usuario nuevo............................................... 64

5.2.2. Diagrama de caso de uso para usuario registrado ...................................... 65

5.2.3. Diagrama de caso de uso para administrador .............................................. 66

5.3. Modelo Lógico de Datos ............................................................................................. 67

5.3.1. Nivel 0: Nivel de contexto de JKanken........................................................... 70

5.3.2. Nivel 1: Modelo conceptual de JSKanken ...................................................... 72

5.3.3. Nivel 2: Explosión del proceso «GESTOR»: ................................................ 74

5.3.4. Nivel 2: Explosión del proceso «Examinador»: ............................................ 77

5.3.5. Nivel 2: Explosión del proceso «Aprender»: .................................................. 79

5.3.6. Nivel 3: Explosión del proceso «Generar Nōken n5»: .................................. 81

5.3.7. Nivel 3: Explosión del proceso «Generar Kanken 10»: ................................. 83

5.3.8. Nivel 3: Explosión del proceso «Control de examen»: ................................... 85

5.4. Diccionario de datos ..................................................................................................... 88

5.5. Diseño de la base de datos .......................................................................................... 96

5.6. Diseño del OCR de la plataforma ............................................................................ 106

5.7. Diseño del generador de exámenes de la plataforma ......................................... 110

5.8. Diseño del logo de la plataforma ............................................................................. 111

5.8.1. ¿Qué es un logo? ................................................................................................. 111



Cap

ítu

lo: In

trod

ucc

ión

3

5.8.2. Tipos de logos ..................................................................................................... 111

5.8.3. Modelo de color a emplear ............................................................................... 111

5.8.4. Elaboración del logo .......................................................................................... 112

6. Tecnologías empleadas ......................................................................................... 117

6.1. MS Office 2010 ............................................................................................................ 118

6.2. Adobe Photoshop CS5.1 ............................................................................................ 119

6.3. Netbeans 7.1 ................................................................................................................. 119

6.4. MySQL 5.5 ................................................................................................................... 120

6.5. PHP 6 ............................................................................................................................ 121

6.6. Zend Framework ........................................................................................................ 121

6.7. JpGraph ......................................................................................................................... 121

6.8. JQuery ........................................................................................................................... 122

6.9. JavaScript...................................................................................................................... 122

6.10. HTML5 .................................................................................................................... 122

6.11. CSS ............................................................................................................................. 123

6.12. XAMPP .................................................................................................................... 123

7. Manual de usuario .................................................................................................. 127

7.1. Inicio de la plataforma ............................................................................................... 128

7.2. Funcionalidades .......................................................................................................... 130

7.2.1. Perfil ...................................................................................................................... 130

7.2.2. Buscador de Kanjis ............................................................................................. 131

7.2.3. Realizar prueba ................................................................................................... 135

7.2.4. Resultados ............................................................................................................ 140

8. Planificación y presupuesto.................................................................................. 143

8.1. Estructura desagregada de tareas ........................................................................... 143

8.2. Planificación del proyecto ......................................................................................... 144



Cap

ítu

lo: In

trod

ucc

ión

4

8.3. Presupuesto del proyecto .......................................................................................... 146

9. Conclusiones ............................................................................................................ 151

10. Futuros desarrollos ............................................................................................. 155

11. Bibliografía y referencias ................................................................................... 159

ÍNDICE DE FIGURAS

Figura 1 – Colección Minna No Nihongo ................................................................................. 11

Figura 2 – Juego de Nintendo DS (Kanken DS3) .................................................................. 14

Figura 3 – Análisis estadístico de la Japan Foundation ......................................................... 15

Figura 4 – Contexto general de la plataforma ........................................................................ 39

Figura 5 – Jerarquía de usuario ................................................................................................. 62

Figura 6 – Caso de uso para usuario nuevo ............................................................................... 64

Figura 7 – Caso de uso para usuario registrado ........................................................................ 65

Figura 8 – Caso de uso para administrador .............................................................................. 66

Figura 9 – Nivel 0: Nivel de contexto de JSKanken ............................................................. 70

Figura 10 – Nivel 1: Modelo conceptual de JSKanken ......................................................... 72

Figura 11 – Nivel 2: Explosión del proceso Gestor ................................................................ 74

Figura 12 – Nivel 2: Explosión del proceso Examinador ..................................................... 77

Figura 13 – Nivel 2: Explosión del proceso Aprender ........................................................... 79

Figura 14 – Nivel 3: Explosión del proceso Generar Nōken N5 ......................................... 81

Figura 15 – Nivel 3: Explosión del proceso Generar Kanken 10 ......................................... 83

Figura 16 – Nivel 3: Explosión del proceso Control de examen ........................................... 85

Figura 17 – Relaciones de las tablas de la Base de Datos .................................................... 96

Figura 18 – Análisis de un kanji por el OCR ........................................................................ 106



Cap

ítu

lo: In

trod

ucc

ión

5

Figura 19 – Ejemplo de similitudes en kanjis ....................................................................... 107

Figura 20 – Ejemplo de dibujo a mano alzada ...................................................................... 108

Figura 21 – Modelo de color CMYK ...................................................................................... 111

Figura 22 – Logo de la plataforma JSKanken....................................................................... 112

Figura 23 – MVC de la plataforma ......................................................................................... 117

Figura 24 – Pantalla de inicio de la plataforma .................................................................... 128

Figura 25 – Pantalla de registro de la plataforma ............................................................... 129

Figura 26 – Perfil del usuario ................................................................................................... 130

Figura 27 – Buscador de kanjis de la plataforma ................................................................. 131

Figura 28 – Ejemplo de búsqueda de los kanjis con 4 trazos ............................................ 132

Figura 29 – Información previa de un kanji .......................................................................... 132

Figura 30 – Información completa de un kanji .................................................................... 133

Figura 31 – Pregunta 1 de un examen tipo kanken 10 ....................................................... 135



Figura 34 – Preguntas 5 y 6 de un examen tipo kanken 10 .............................................. 136


Figura 36 – Panel de escritura ................................................................................................. 137

Figura 37 – Ejemplo de kanji (ejercicios 3 y 4) .................................................................... 138

Figura 38 – Pantalla con la evaluación de un examen de la plataforma ......................... 139

Figura 39 – Gráfico de ejemplo de los resultados de un examen ..................................... 139

Figura 40 – Pantalla con los resultados de los exámenes realizados de la plataforma 140

Figura 41 – Estructura desagregada de tareas ..................................................................... 143

Figura 42 – Planificación del proyecto ................................................................................... 144

Figura 43 – Diagrama GANTT de la planificación ............................................................ 144



Cap

ítu

lo: In

trod

ucc

ión

6

ÍNDICE DE TABLAS

Tabla 1 – Niveles de Noken ........................................................................................................ 22

Tabla 2 – Niveles de Kanken ...................................................................................................... 24

Tabla 3 – Lista de kanjis del primer nivel de examen .......................................................... 25

Tabla 4 – Lista de kanjis reconocidos ....................................................................................... 33

Tabla 5 – Tipos de requisitos ..................................................................................................... 41

Tabla 6 – Diccionario de datos del sistema JSKanken .......................................................... 95

Tabla 7 – Tabla TBL_USREG .................................................................................................. 97

Tabla 8 – Tabla TBL_KANJIS .................................................................................................. 98

Tabla 9 – Tabla TBL_LECTURAS ......................................................................................... 99

Tabla 10 – Tabla TBL_EJEMPLOS ...................................................................................... 100

Tabla 11 – Tabla TBL_EXK10 ............................................................................................... 101

Tabla 12 – Tabla TBL_PEK10 ................................................................................................ 103

Tabla 13 – Tabla TBL_EXN5 ................................................................................................. 104

Tabla 14 – Tabla TBL_PEN5 .................................................................................................. 105

Tabla 15 – Horas de trabajo ..................................................................................................... 146

Tabla 16 – Presupuesto del proyecto ..................................................................................... 147



Cap

ítu

lo: In

trod

ucc

ión

7

Capítulo 1

INTRODUCCIÓN.



Cap

ítu

lo: In

trod

ucc

ión

8



Cap

ítu

lo: In

trod

ucc

ión

9

1. INTRODUCCIÓN

Para comenzar a desarrollar este proyecto, se empezará haciendo una pequeña

introducción, que contendrá todo lo necesario para que cualquier persona pueda

entenderlo perfectamente.

Básicamente, este punto se centra en una breve descripción del proyecto a

desarrollar y en los conceptos necesarios para la comprensión del desarrollo de esta

memoria, así como la motivación que ha llevado a su desarrollo y un estudio del

mercado actual con posibles productos similares al obtenido por en el desarrollo de

este proyecto.

1.1. DEFINICIÓN DEL PROYECTO

El proyecto a desarrollar consiste en la creación de una plataforma web, que

permita la preparación de los exámenes oficiales de japonés. Esta plataforma será

un método educativo que permitirá, a todo aquel interesado/-a en la escritura e idioma

nipón, adquirir los conocimientos necesarios para superar los exámenes oficiales

de lengua y escritura japonesa.

En posteriores apartados se detallará el alcance del proyecto.

1.2. CONCEPTOS BÁSICOS

Se detallarán los principales conceptos que cualquiera lector debe asimilar para la

total comprensión de esta memoria, y que serán utilizados a lo largo del desarrollo de

esta memoria.

1.2.1. RIA (RICH INTERNET APPLICATION)

Aplicaciones web que se asemejan a las aplicaciones de escritorio comunes, con

características y funcionalidades similares. La principal diferencia con las aplicaciones

de escritorio, es que las RIA no necesitan instalar la aplicación de forma local en el

ordenador del usuario, sino que son accesibles desde un navegador web. Esto quiere

decir que son aplicaciones “crossPlataform”, es decir, que no importa la plataforma que



Cap

ítu

lo: In

trod

ucc

ión

10

el usuario utilice para acceder a estas aplicaciones que siempre funcionarán y se verán

de la misma forma.

1.2.2. OCR

Abreviatura con la que se conoce al Reconocimiento Óptico de Caracteres.

Son aplicaciones dirigidas a la digitalización de textos; identifican de manera

automática símbolos o caracteres que pertenezcan a un determinado alfabeto, a partir

de una imagen para almacenarla en forma de datos con los que se puede interactuar

mediante un programa de edición de texto o similar.

1.2.3. KANJI

Son los ideogramas utilizados en la escritura de la lengua japonesa. Este será el

gran pilar en el que se centra este proyecto. Los kanji, es una de las tres principales

formas de escritura de la lengua japonesa.

Los otros dos son los silabarios hiragana y katakana, que se entenderá que

cualquier usuario que pretenda utilizar la plataforma a desarrollar con este proyecto,

los comprende perfectamente, tanto lectura como escritura.

Los kanji son utilizados en su mayoría para expresar conceptos. A cada uno le

corresponde un significado, y este se usa como determinante de la raíz de la palabra.

Un kanji puede tener diferentes pronunciaciones o lecturas, dependiendo del

contexto, uso en combinación, y su localización en la oración. Estas lecturas son

categorizadas dependiendo de si son derivadas del chino original (on’yomi) o si fueron

adaptadas a la lengua nativa (kun’yomi). La mayor parte de los kanjis poseen dos

lecturas, una kun’yomi y otra on’yomi, pero algunos kanji, muchos de ellos de uso diario,

poseen diez o más posibles lecturas.



Cap

ítu

lo: In

trod

ucc

ión

11

1.3. ESTUDIO DEL MERCADO ACTUAL

En este punto se va a realizar un breve estudio sobre las herramientas que

actualmente, los estudiantes de japonés tienen a su disposición. Con este estudio se

podrá valorar si realmente merece la pena el desarrollo que se plantea en este proyecto.

A continuación se procede con el análisis.

Como se irá explicando a lo largo de esta memoria, la plataforma contempla

distintas formas de estudio, por lo que el análisis a realizar también abarcará todas

estas fases.

No se hará hincapié en dichas fase, aunque si se mencionarán las más

importantes y generales sin proceder a su desarrollo.

1.3.1. FASE DE ESTUDIO

Dicha fase se centra principalmente en lo que se indica en el nombre, “estudio”.

El usuario de la aplicación podrá utilizar un temario dispuesto en la plataforma para

poder memorizar lo necesario para su comprensión del idioma. A continuación se

exponen los métodos actuales para el aprendizaje del idioma:

1.3.1.1. COLECCIÓN “MINNA NO NIHONGO” (みんなの日本語)

Figura 1 – Colección Minna No Nihongo



Cap

ítu

lo: In

trod

ucc

ión

12

Está compuesta por tres niveles generales (I, II, III), cada uno dispone de libro de

clase, libro de ejercicios, libro de kanji, libro de ejercicios de kanji y discos de audio

basados en vocabulario, conversación y dictado. Actualmente sólo están disponibles en

lengua hispana los libros de clase correspondientes a los niveles I y II. A pesar de

dichas traducciones, y su uso para el aprendizaje del idioma fuera de Japón, estos libros

están enfocados al público japonés.

1.3.1.2. LIBRO “KANJI AL COMPLETO”

Es una obra centrada básicamente en los kanjis necesarios para poder leer cosas

en japonés, es decir, los 1945 kanjis que contempla el idioma japonés como básicos. A

día de hoy descatalogado.

“Kanji al completo” presenta los 1945 caracteres de la lista de kanjis de uso

común agrupados según los niveles en que se estudian en el sistema educativo japonés.

Para cada kanji se presentra su información de pronunciación, significado, número de

trazos, radical principal, nivel en el que se estudia y hasta ocho palabras de ejemplo

formadas con ese carácter.

En general, es una obra muy completa para el estudio de kanjis.

1.3.1.3. COLECCIÓN “KANJI EN VIÑETAS”

Se divide en tantos tomos como niveles de kanji existen. En estos momentos sólo

están disponibles los 3 primeros niveles.

Con respecto a “Kanji al completo” no aporta diferencia de información a

excepción de añadir algún ejercicio “básico” para comprender los kanjis, pero “Kanji en

viñetas” tiene el inconveniente de su división en tomos y como se ha mencionado

anteriormente, que actualmente solo existen 3 niveles, lo que corresponde a 440 kanjis.

1.3.1.4. COLECCIÓN “KANKEN KAKO MONDAISHIYUU JITSUKIYUU”

Como se puede apreciar en el título del libro, es una colección de libros dirigida

al público japonés, por lo que no facilita, sino al contrario, el aprendizaje del idioma. A

diferencia con el resto de obras analizadas, esta colección es la considerada como la

“oficial” que contempla todo lo necesario para el aprendizaje de los kanjis y casos de



Cap

ítu

lo: In

trod

ucc

ión

13

ejemplo que se pueden asemejar a los empleados en los exámenes oficiales de escritura

japonesa, así como ejercicios para su correcto entendimiento, todo ello, en japonés.

Para el uso de esta colección se requieren unos conocimientos intermedios del

idioma, correspondientes a un nivel B del marco europeo, para poder sacarle algo de

partido a las explicaciones.

Uno de los grandes inconvenientes para el público no japonés es la dificultad

para poder conseguir los tomos en los que se divide la colección, ya que actualmente,

solo están disponibles en Japón.

1.3.2. FASE DE INTERACCIÓN/PRÁCTICA

Esta fase concentra todo lo relacionado con la escritura y su práctica, así como la

realización de exámenes oficiales de la lengua.

1.3.2.1. EXÁMENES OFICIALES

Una de las posibilidades para la preparación de los exámenes oficiales del idioma

japonés es mediante los propios exámenes de convocatorias anteriores. El gran

inconveniente de esto es la gran dificultad de conseguir dichos exámenes, puesto que

no están a la venta.

1.3.2.2. JUEGOS DE NINTENDO DS

Sin duda alguna, uno de los mejores métodos de estudio. Son juegos aprobados

por el gobierno japonés para facilitar el aprendizaje del idioma y sobre todo de la

escritura. La mayoría de estos juegos se centran sobre todo en la parte de los kanjis, ya

que es la parte “difícil” del idioma japonés. De todos los juegos que pueden existir,

merece la pena destacar uno, “Kanken DS3”. Es una de las últimas versiones que se

centra en la preparación de los exámenes oficiales de escritura.



Cap

ítu

lo: In

trod

ucc

ión

14

Figura 2 – Juego de Nintendo DS (Kanken DS3)

Este juego permite al usuario escribir el kanji para así practicar también la forma

de escribirlo, no solo cuenta el saber reconocerlo, sino también el orden de los trazos,

sus múltiples lecturas y sus conjugaciones con otros kanjis. Pero como en otros casos,

este juego está destinado al público japonés, además del inconveniente de tener que

disponer de una consola Nintendo DS.



Cap

ítu

lo: In

trod

ucc

ión

15

1.4. MOTIVACIÓN DEL PROYECTO

En los últimos años, se ha ido incrementando de forma significativa el número de

estudiantes que se interesan por el idioma japonés. Uno de los últimos estudios

realizados por la “Japan Foundation” en 2009 (figura n.3) sobre el número de

extranjeros que se interesan por el idioma nipón, revela que en ese año, 2009, existían

en total 3.651.232 estudiantes. Solamente en Europa Occidental, los estudiantes de

japonés registrados han aumentado, prácticamente doblado, desde el año 1998 (47.451

estudiantes) hasta el año del estudio, 2009 (72.594 estudiantes).

Figura 3 – Análisis estadístico de la Japan Foundation

Añadido a todo esto, existen otras motivaciones que llevan a cabo el desarrollo

de este proyecto, las cuales se pueden catalogar en dos tipos. El primer tipo comprende

todas las motivaciones de carácter general, y el segundo tipo, todas las de índole

personal.

Con respecto a las del primer tipo o de carácter general, cabe destacar:

Ausencia “parcial” del uso de la tecnología para abordar el tema del

estudio de la escritura japonesa.



Cap

ítu

lo: In

trod

ucc

ión

16

Con ausencia “parcial” se refiere a que existen herramientas que

utilizan tecnología, como se ha explicado en el sub-apartado de

estudio de mercado, pero enfocadas al público japonés y que

requieren una consola para poder utilizarlas, con lo que no están al

acceso de todo el mundo. Con el desarrollo de este proyecto se

intenta poner a disposición de toda aquella persona interesada en el

idioma japonés, una plataforma accesible, sin tener que desembolsar

una gran cantidad de dinero.

Poner a disposición del estudiante una plataforma que le permita

realizar un aprendizaje autodidacta más sencillo.

Debido al gran aumento de estudiantes del idioma japonés que se ha

producido en los últimos, como se puede observar en la figura

anterior, se ve como una gran oportunidad de negocio.

Entrando en las motivaciones del segundo tipo o de carácter personal, citar:

Proyecto multi-disciplinar.

El desarrollo de este proyecto, como se comentará en el sub-apartado

“Alcance del proyecto”, está centrado en el aprendizaje de los kanjis

del Kanken 10kyu y el Nokken N5. Posteriormente al desarrollo de

este proyecto, se podrán incluir progresivamente, todo lo necesario

para su utilización en niveles superiores. Esta es una de las

principales motivaciones del desarrollo de este proyecto, por un lado

se centra en el estudio del idioma japonés y por otro en el desarrollo

web dentro del campo de la informática.

Mejorar las relaciones.

Con el desarrollo de este proyecto se pretende generar unas buenas

relaciones con de departamento de cultura y educación de la

Embajada Japonesa de Madrid.



Cap

ítu

lo: In

trod

ucc

ión

17

Ampliación de conocimientos.

Por último, cabe destacar como motivación “personal”, la ampliación

de conocimientos tanto en el estudio del idioma japonés, como en el

aprendizaje de lenguajes de programación y entornos de desarrollo

empleados para llevar a cabo la realización del proyecto.



Cap

ítu

lo: In

trod

ucc

ión

18



Cap

ítu

lo: In

trod

ucc

ión

19

Capítulo 2

ALCANCE DEL

PROYECTO.



Cap

ítu

lo: In

trod

ucc

ión

20



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

21

2. ALCANCE DEL PROYECTO

El desarrollo de este proyecto tiene como finalidad, aportar una plataforma

para todo aquel que esté interesado en el estudio del idioma japonés, facilitándole el

estudio y aprendizaje del mismo. La plataforma se centra principalmente en la parte

del idioma que se considera más difícil de aprender, la escritura. A continuación se irá

definiendo y acotando el ámbito que cubrirá el desarrollo de esta plataforma.

2.1. INTRODUCCIÓN AL ÁMBITO DEL PROYECTO

La escritura japonesa está comprendida por tres sistemas de escritura clásicos y

uno de transcripción:

Hiragana. Silabario para palabras japonesas.

Katakana. Silabario para palabras extranjeras.

Kanji. Silabario para expresar conceptos.

Romaji. Empleada en la transcripción del idioma japonés al alfabeto

latino.

Dentro de la preparación del idioma, existen dos tipos de exámenes oficiales de

Nivel de Lengua Japonesa (Noken y Kanken).

2.1.1. EXÁMENES OFICIALES DE NIVEL DE LENGUA JAPONESA

A continuación se procede a explicar los tipos de exámenes oficiales de Nivel de

Lengua Japonesa en vigor actualmente.

2.1.1.1. NIHONGO NORYOKU SHIKEN

Conocido popularmente como Noken (JLPT), ha sido organizado por la Japan

Foundation y la Japan Educational Exchanges and Services desde 1984 como medio

fiable para evaluar y certificar la competencia en japonés de los hablantes no nativos.

En la primera convocatoria a nivel mundial, se presentaron 7.000 examinantes, y en

2009, un total de 770.000. Con el paso del tiempo, este examen ha pasado de ser una

forma de medir las cuatro habilidades lingüísticas, a hacerse uso de los resultados como



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

22

medio de evaluación para la contratación laboral, la promoción profesional, el aumento

de los salarios, así como una forma de cualificar al examinado.

Actualmente, el examen se divide en 5 niveles diferentes (N5, N4, N3, N2, N1),

siendo el N5 el de nivel más bajo y el N1 considerando a la persona que lo posea como

“bilingüe”.

Nivel Partes y tiempos del examen

N1 Conocimiento de la Lengua (Vocabulario/Gramática) –

Lectura

110 minutos

Audición

60 minutos

N2 Conocimiento de la Lengua (Vocabulario/Gramática) –

Lectura

105 minutos

Audición

50 minutos

N3 Conocimiento de la

Lengua (Vocabulario)

30 minutos

Conocimiento de la Lengua

(Gramática) – Lectura

70 minutos

Audición

40 minutos



30 minutos



60 minutos

Audición

35 minutos



30 minutos



50 minutos

Audición

30 minutos

Tabla 1 – Niveles de Noken



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

23

2.1.1.2. NIHON KANJI NORYOKU KENTEI SHIKEN

Conocido popularmente como Kanji Kentei o Kanken, es un examen que evalúa

el nivel de lectura, escritura, y correcto empleo de los kanjis. En este tipo de examen,

existen 12 niveles diferentes (10, 9, 8, 7, 6, 5, 4, 3, Pre-2, 2, Pre-1, 1), siendo el Kanken

10 el de nivel más bajo y el Kanken 1 el de nivel más alto. En dicho examen, se exige

un porcentaje de respuestas correctas del 80% para los niveles 10, 9, 8, Pre-2, 2, Pre-1,

1; y un 70% para el resto.

En Japón, se “exige” para los japoneses disponer de la certificación del nivel Pre-2,

que incluyen los kanjis necesarios para poder leer periódicos, prensa y libros

correctamente.

Nivel Kanjis Puntuación

10 kyu 80 kanjis 150 puntos








Pre-2

kyu 1945 kanjis 200 puntos

2 kyu

1945 kanjis

300 kanjis de nombres

200 puntos

Pre-1 3000 kanjis 200 puntos



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

24

kyu


Tabla 2 – Niveles de Kanken

2.2. DEFINICIÓN DEL ÁMBITO DEL PROYECTO

En este punto se define y explica el ámbito que cubre el desarrollo de este

proyecto. Como se ha ido mencionando anteriormente, abarca el desarrollo de una

plataforma que permite un mejor aprendizaje y preparación del idioma japonés que los

actuales métodos existentes en el mercado, para ello, se hará uso de las tecnologías

actuales.

Como se ha podido observar anteriormente, el proyecto puede ser todo lo amplio

que se quiera, pero al tratarse de un proyecto final de carrera, se acotará el ámbito que

debe cubrir.

El proyecto se centrará principalmente en los primeros niveles de cada examen

oficial, es decir:

Nihongo Noryoku Shiken N5 (Noken N5).

Nihon Kanji Noryoku Kentei Shiken 10 (Kanken 10 kyu).

Ambos exámenes han sido explicados anteriormente, pero en definitiva la

plataforma debe ser capaz de enseñar los 80 primeros kanjis definidos por el gobierno

japonés como básicos. A continuación se pone una lista de los kanjis que contienen

ambos exámenes:

一百下口森犬学白

二千左人田虫校青

三日右子空貝先円



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

25

四月大女雨石生正

五火中男天王字早

六水小名気玉文入

七木手年夕力本出

八金足山花糸村立

九土目川草車町休

十上耳林竹音赤見

Tabla 3 – Lista de kanjis del primer nivel de examen

Además, el usuario de la aplicación podrá preparar y practicar los dos tipos de

exámenes que abarca, así como poder estudiar los kanjis por separado

independientemente de las pruebas de examen. En cada prueba realizada por el usuario,

esté podrá conocer los resultados obtenidos en la misma.



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

26



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

27

Capítulo 3

IDENTIFICACIÓN DE

NECESIDADES.



Cap

ítu

lo: A

lcan

ce d

el p

royec

to

28



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

29

3. IDENTIFICACIÓN DE NECESIDADES

3.1. INTRODUCCIÓN

En este punto se definen los objetivos y necesidades que el desarrollo de este

proyecto intenta resolver, y se fijan unas normas a seguir para la dirección del proyecto,

además de establecer los límites y restricciones que afectan al proyecto.

Esta fase decidirá el buen desarrollo del proyecto por lo que la información

obtenida tanto de la investigación, como la definida, debe ser lo más precisa posible.

Como resultado de esta etapa, se obtiene el Documento de Concepto del Sistema

que contiene los siguientes puntos:

Objetivos del sistema. Explica desde el punto de vista organizativo el

propósito del proyecto.

Tipología de los usuarios finales. A quien va dirigido el resultado del

proyecto, quienes van a ser los usuarios que utilicen la aplicación obtenida

del desarrollo del proyecto.

Restricciones. Impedimentos que se puedan encontrar, tanto técnicos

como funcionales.

Antecedentes. Sistemas similares implantados antes de este proyecto.

Este apartado del desarrollo de la memoria del proyecto, se ha centrado

principalmente en la definición exhaustiva de los objetivos del proyecto, así como una

concisa explicación de ciertos aspectos técnicos, necesarios para entender el

funcionamiento y el desarrollo realizado en este proyecto.

Es importante especificar de una forma detallada y completa todos los aspectos

del proyecto, para así, hacer lo más fácil la tarea de desarrollo.

Al ser esta, la fase inicial del desarrollo, se va a hacer especial hincapié en definir

lo más claramente, cuáles son los objetivos del sistema.



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

30

3.2. DOCUMENTO DE CONCEPTO DEL SISTEMA

Como se acaba de mencionar en el anterior sub-apartado, a continuación se va a

proceder a definir el Documento de Concepto del Sistema sobre el que partirá el

desarrollo del proyecto.

3.2.1. OBJETIVOS

El proyecto que se va a desarrollar, pretende ofrecer una nueva forma de

aprender el idioma japonés y su compleja escritura. El objetivo principal y final del

mismo, es el desarrollo de una plataforma accesible a todo aquel interesado/-a en la

preparatoria de exámenes oficiales de japonés, para poder prepararse para las

convocatorias oficiales de ambos exámenes definidos en el apartado de “Alcance del

sistema”, utilizando tecnología actual al alcance de cualquiera, como un ordenador con

acceso a internet o un Smartphone.

Los objetivos principales son los siguientes:

Ofrecer una nueva alternativa de aprendizaje y estudio del idioma japonés.

Utilizar tecnología accesible para promover su uso.

Permitir a los usuarios la preparatoria de exámenes oficiales.

Permitir a los usuarios conocer sus resultados en las pruebas realizadas

para que puedan ver en qué área del idioma deben mejorar.

Atraer al mayor número de usuarios al uso de la plataforma.

La plataforma debe permitir añadir más contenido una vez finalizado el

desarrollo de este proyecto, es decir, además del contenido establecido

para este proyecto que contiene los niveles definidos en el apartado de

“Alcance del proyecto”, posteriormente, se podrá añadir otros niveles de

preparación.



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

31

3.2.2. PARTES DEL SISTEMA

A continuación se presentan las partes en las que se ha dividido el desarrollo de

este proyecto.

3.2.2.1. PARTE 1 – PRESENTACIÓN

Esta parte concentra toda la capa de presentación, correspondiente a la interfaz

que se le mostrará al usuario. Permite introducir la “información” necesaria para el

posterior tratamiento, y muestra los datos obtenidos de la manipulación de dicha

“información”, todo ello, de la forma más sencilla e intuitiva posible.

Como indica su nombre, se centra en la capa de presentación de la versión web de

la plataforma a desarrollar. Dentro de este sub-módulo se pueden encontrar cuatro

secciones bien diferenciadas:

Parte 1.1.1 – Identificación/Login WEB.

Se compone de las páginas correspondientes al registro de los

usuarios para el uso de la plataforma, y de las páginas

correspondientes a la identificación de los usuarios ya registrados.

Parte 1.1.2 – Perfil/Calificaciones WEB.

Se compone principalmente de una página general, a la que será re-

direccionado el usuario, una vez esté identificado, en la que éste podrá

ver su perfil con sus últimas pruebas realizadas y sus resultados

logrados.

Parte 1.1.3 – Buscador/Aprendizaje WEB.

Se compone de una página para definir los filtros de búsqueda, otra

para mostrar los resultados y una última para la información más

detallada de dichos resultados. Esta última es la que contendrá los

datos necesarios para que los usuarios puedan aprender todo lo

relacionado con los elementos buscados.



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

32

Parte 1.1.4 – Examen/Pruebas WEB.

Se compone de las páginas necesarias para realizar las pruebas de los

exámenes que permitan a los usuarios examinarse y demostrar lo

aprendido del idioma. Como se ha mencionado a lo largo de este

proyecto, se divide en dos exámenes, es decir, dos tipos de páginas

según sean las pruebas del Kanken 10kyu o del Noken N5.

Una vez desarrollado esta parte, deberá permitir realizar cambios deseados en

cuestión de estilos, por lo que deberán modularse para poder permitirlo más adelante.

3.2.2.2. PARTE 2 – RECONOCIMIENTO DE ESCRITURA (OCR)

Esta parte es el que más valor añadido otorga a la plataforma al permitir a los

usuarios escribir dentro de la ella, lo que favorece al alza el aprendizaje del usuario en

la escritura del idioma.

Una vez el usuario realice la escritura correspondiente a un kanji en la capa de

presentación, este módulo realiza el tratamiento de la información relativa al kanji

“escrito” por el usuario y la analiza, devolviendo el kanji considerado como óptimo para

la escritura realizada.

Es la parte más denso y costosa, y debe ser capar de realizar el correspondiente

reconocimiento de los kanjis definidos para este proyecto:

一百下口森犬学白

二千左人田虫校青

三日右子空貝先円

四月大女雨石生正

五火中男天王字早

六水小名気玉文入



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

33

七木手年夕力本出

八金足山花糸村立

九土目川草車町休

十上耳林竹音赤見

Tabla 4 – Lista de kanjis reconocidos

3.2.2.3. PARTE 3 – EXAMINADOR/EVALUADOR

Este parte contiene el resto de la capa de negocio de la plataforma referente a la

funciones de examinar y de evaluar los exámenes.

La parte 3 (Examinador/Evaluador), se divide en dos sub-partes:

Parte 3.1 – Examinador.

Parte 3.2 – Evaluador.

3.2.2.3.1. PARTE 3.1 – EXAMINADOR

Determina los ejercicios de examen que debe realizar el usuario según su nivel,

con ejercicios típicos de exámenes oficiales del idioma. Se divide en los secciones según

el tipo de examen:

Parte 3.1.1 – Examinador K.

Evalúa el nivel del usuario en este tipo de examen y le propone

ejercicios correspondientes a su nivel del examen de escritura,

Kanken 10kyu.

Parte 3.1.2 – Examinador N.

Evalúa el nivel del usuario en este tipo de examen y le propone

ejercicios correspondientes a su nivel del examen de habilidades

lingüísticas, Noken N5.



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

34



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

35

Capítulo 4

ESPECIFICACIÓN.



Cap

ítu

lo: Id

enti

fica

ción

de

nec

esid

ades

36



Cap

ítu

lo: E

spec

ific

ació

n

37

4. ESPECIFICACIÓN

Este punto del documento se centra en la especificación técnica de características

operacionales de la plataforma; indica la interfaz del software con otros elementos de la

plataforma, y establece las restricciones que debe tener el software.

Se seguirán varias reglas prácticas para crear el modelo de análisis:

El modelo debe centrarse en los requisitos visibles de la plataforma.

Cada elemento del modelo de análisis debe agregarse a un acuerdo

general de requisitos del software y proporcionar una visión interna del

comportamiento de la plataforma.

Se debe minimizar el acoplamiento de toda la plataforma.

Se debe tener seguridad de que el modelo de análisis proporciona valor a

todos los interesados.

El modelo debe mantenerse tan simple como sea posible.

“¿Por qué debemos construir modelos? ¿Por qué no construimos el

modelo y ya? La respuesta es que podemos construir modelos de tal

forma que resaltemos o enfaticemos ciertas características críticas de

un sistema, al mismo tiempo que quitamos énfasis a otros aspectos

del sistema.”

Ed Yourdon



Cap

ítu

lo: E

spec

ific

ació

n

38

4.1. RECONOCIMIENTO DEL PROBLEMA

En esta sección del documento se procede a plantear el problema existente a

solventar con el desarrollo de este proyecto.

Como se ha ido comentando a lo largo de todo el documento, este proyecto

abarca un aspecto en general de cualquier estudiante de idiomas que desee obtener un

certificado oficial que acredite sus conocimientos, es decir, lo que el desarrollo de este

proyecto intenta resolver, es la ayuda en la preparación de los exámenes oficiales de

capacidad lingüística usando la tecnología actualmente disponible, concretamente en el

idioma japonés.

En esta sección no se volverá a definir el alcance del proyecto, para volver a

revisarlo acuda al apartado 2 de este documento.

En definitiva, se intenta solucionar los problemas que tienen los estudiantes de

japonés para acceder a los recursos necesarios para la preparatoria de exámenes

oficiales de la lengua. Todo ello engloba, tanto la fase de estudio/aprendizaje, como la

fase de práctica.

La plataforma a implantar con la finalización de este proyecto debe ser útil para

los estudiantes, permitiéndoles adquirir los conocimientos necesarios y habilidades

lingüísticas suficientes para superar con éxito las convocatorias de los exámenes

oficiales que abarca el proyecto expuestos en el apartado 2 del documento. Para

lograrlo, la plataforma debe contar con dos módulos bien diferenciados:

Módulo de aprendizaje. Contiene todo lo necesario para que el

estudiante pueda preparar los exámenes oficiales.

Módulo de práctica y evaluación. El estudiante podrá poner en uso

todos los conocimientos adquiridos durante la fase de aprendizaje.



Cap

ítu

lo: E

spec

ific

ació

n

39

4.2. CONTEXTO GENERAL DE LA PLATAFORMA

En esta sección del documento se va a mostrar de una forma gráfica, el contexto

general en el que funcionará la plataforma, es decir, las diferentes formas de interacción

con las entidades externas que tienen relación con ella.

Figura 4 – Contexto general de la plataforma



Cap

ítu

lo: E

spec

ific

ació

n

40

4.3. REQUISITOS DE LA PLATAFORMA

En esta sección del documento se analizan los requisitos de la plataforma a

desarrollar, clasificándolos según sean: funcionales, de interfaz, de calidad, de proyecto,

de evolución o de soporte.

El propósito principal de esta fase, es conseguir una comprensión más precisa de

los requisitos y una descripción de los mismos que sea fácil de mantener y ayude a

estructurar el sistema completo, incluyendo la arquitectura. Para alcanzar el

conocimiento suficiente del sistema, será necesario representar los problemas y

necesidades en un modelo conceptual del sistema.

Todos los requisitos expuestos a continuación han sido considerados como

necesarios u óptimos para el buen desarrollo de este proyecto por el director y el

alumno encargado de su desarrollo.

Cada requisito, sea del tipo que sea, contendrá al menos un identificador, un

nombre, una descripción que lo explique y la importancia que tiene el cumplimiento del

requisito para lograr un desarrollo satisfactorio del proyecto.

El principal núcleo del requisito, es la descripción, que debe ser clara y concisa.

En la siguiente tabla se expone una relación de los identificadores utilizados para

los requisitos, donde las dos primeras letras se corresponden con el tipo de requisito y

la “X” con el número de requisito.

IDENTIFICADOR TIPO DE REQUISITO

FN.X Requisito Funcional

IN.X Requisito de Interfaz

CA.X Requisito de Calidad

PR.X Requisito de Proyecto



Cap

ítu

lo: E

spec

ific

ació

n

41

EV.X Requisito de Evolución

SO.X Requisito de Soporte

Tabla 5 – Tipos de requisitos

A continuación se describen los distintos tipos de “importancia” que puede poseer

cada requisito:

Esencial. Se considera que el cumplimiento del requisito es, en cierto

modo, obligatorio para considerar satisfactorio el desarrollo de este

proyecto.

Condicional. El requisito con este tipo de importancia no es de obligado

cumplimiento, aunque si deseado, si fuera de otro forma no estaría en la

lista de requisitos.

Además de los campos mencionados anteriormente que posee cada requisito,

pueden tener otros campos como:

Medible. Expone métodos que se realizarán para llevar a cabo las

comprobaciones del cumplimiento del requisito.

Alcanzable. Expresa como se piensa lograr el cumplimiento del requisito.

Relevante. Expresa lo que conlleva el cumplimiento del requisito.



Cap

ítu

lo: E

spec

ific

ació

n

42

4.3.1. REQUISITOS FUNCIONALES

En este punto del documento se procede a plasmar los requisitos funcionales del

desarrollo de este proyecto, es decir, aquellos requisitos que definen el funcionamiento

interno de la plataforma: cálculos, detalles técnicos, manipulación de datos y otras

funcionalidades específicas; en definitiva, son los requisitos que plasman los

comportamientos necesarios de la plataforma.

FN.1: Conexión a la plataforma mediante autenticación.

Descripción: El acceso a la plataforma debe ser controlado. Los usuarios que

deseen emplear la plataforma de estudio deben validarse mediante un nombre

de usuario y una contraseña.

Importancia: Esencial.

Validez:

o Medible: Se debe comprobar el acceso a la plataforma con intentos desde

diferentes cuentas y con diferentes técnicas de hacking como sql-inject.

o Alcanzable: Se empleará una base de datos segura, así como una capa de

seguridad para realizar la identificación de los usuarios en la plataforma.

o Relevante: El cumplimiento de este requisito es fundamental para poder

tener controlado el uso de la plataforma, y en caso de ser necesario,

restringir el acceso a personas no deseadas.

FN.2: Alta de usuarios.

Descripción: El usuario que desee utilizar la aplicación debe poder registrarse

en la plataforma mediante un formulario de registro que debe contener unos

campos de datos, referentes al usuario, mínimos.


Validez:

o Medible: Se debe comprobar el registro en la plataforma mediante

varios registros de pruebas.

o Alcanzable: Se empleará una base de datos segura, así como una capa de

comprobación de los campos del formulario para garantizar que éstos

son correctos.



Cap

ítu

lo: E

spec

ific

ació

n

43

o Relevante: El cumplimiento de este requisito es fundamental para

permitir el registro de los usuarios en la plataforma. Principalmente

servirá para poder llevar un control del número de usuarios que utilizan

la plataforma y realizar estadísticas sobre estudiantes del idioma

japonés. Además servirá para poder realizar envíos electrónicos con las

nuevas actualizaciones de la plataforma.

FN.3: Baja de usuarios.

Descripción: El usuario que, por los motivos que sean, desee darse de baja en

la aplicación, pueda hacerlo mediante un formulario en el que indique el motivo

de su baja en la plataforma.

Importancia: Condicional.

Validez:

o Medible: Se comprobará realizando la baja de los usuarios registrados

como “usuarios de prueba” de la plataforma.

o Alcanzable: Se realizará un formulario con distintos motivos de la baja,

y estos deben quedar almacenados en una tabla de la base de datos de la

plataforma.

o Relevante: El cumplimiento de este requisito mejoraría

considerablemente la experiencia de usuario en la plataforma. Se

podrían realizar estadísticas con los diferentes motivos de baja de los

usuarios y poder detectar los principales fallos de la plataforma, que

hacen que los usuarios dejen de utilizarla para el estudio del idioma

japonés. De esta forma se podría intentar solventar estos fallos y lograr

una plataforma más robusta.

FN.4: Escritura a mano.

Descripción: La plataforma debe permitir un aprendizaje correcto sobre la

escritura de los kanjis, por ello, es recomendable que el usuario pueda escribir

los kanjis para la realización de los exámenes oficiales de japonés, y así adquirir

un mejor conocimiento del idioma y la escritura japonesa.


Validez:



Cap

ítu

lo: E

spec

ific

ació

n

44

o Medible: Se realizarán pruebas de escritura de los kanjis con estudiantes

voluntarios del “Centro Superior de Idiomas Modernos” de la

Universidad Complutense de Madrid. Dichos estudiantes deberán tener

suficiente nivel en el idioma y al menos, superado el nivel de examen en

el que se centra la plataforma en su primera versión, Kanken N10.

o Alcanzable: Para lograr dicho objetivo se empleará el uso de canvas de

HTML5 junto con JavaScript y PHP. El uso de estos lenguajes

combinados permitirá realizar una “escritura a mano” del kanji adecuada.

o Relevante: El cumplimiento de este requisito, se considera como uno de

los más importantes, ya que será lo que permita a los usuarios avanzar

más rápidamente y adecuadamente en su aprendizaje del idioma japonés.

FN.5: Reconocimiento automático de kanjis.

Descripción: La plataforma debe ser capaz de, una vez escrito el kanji por el

usuario, reconocerlo automáticamente de forma transparente al usuario, que no

tiene por qué saber “que es”, “para que sirve” o “como funciona” dicho motor de

reconocimiento.


Validez:

o Medible: Si un usuario de la plataforma que tenga conocimientos bajos

en informática, es decir, un usuario normal de la plataforma, es capaz de

interaccionar con el motor de reconocimiento satisfactoriamente, el

requisito se habrá cumplido. Para cumplirlo, se realizarán pruebas de

escritura con estudiantes voluntarios del “Centro Superior de Idiomas

Modernos” de la Universidad Complutense de Madrid. Dicho grupo

debe contener todo tipo de perfiles de “usuarios finales”, así como

disponer de un suficiente conocimiento del idioma japonés para poder

realizar dichas pruebas.

o Alcanzable: Mediante programación de las distintas clases que se

precisen y el Framework ZEND de PHP, se podrá crear el motor de

reconocimiento evitando dependencias externas de la plataforma.



Cap

ítu

lo: E

spec

ific

ació

n

45

o Relevante: Se trata de un requisito fundamental de la plataforma para

proporcionar valor añadido a la plataforma que hará que destaque entre

los métodos existentes de estudio del idioma japonés.

FN.6: Detectar fallos de escritura.

Descripción: La plataforma debe ser capaz de detectar los kanjis escritos

correctamente dentro de los 80 kanjis definidos para el reconocimiento

automático que engloba este proyecto, pero en el caso de detectar fallos en la

escritura o ningún kanji reconocido, se deberá mostrar al usuario el pertinente

mensaje con las correspondientes soluciones a dicho problema.


Validez:

o Medible: Se realizarán pruebas de escritura con estudiantes voluntarios

del “Centro Superior de Idiomas Modernos” de la Universidad

Complutense de Madrid, de modo, que introduzcan tanto respuestas

correctas como incorrectas llevando un control de los resultados para

poder calcular la tolerancia a fallos de la plataforma.

o Alcanzable: Junto con el motor de reconocimiento se desarrollará una

capa de correspondencia, que ayudará a mejorar los resultados del

reconocimiento. En el caso de que se detecte fallos en la escritura o un

kanji no se reconoce, se podrán ofrecer al usuario kanjis similares al

escrito por el usuario o la posibilidad de volver a realizar la escritura.

o Relevante: El cumplimiento de este requisito, aseguraría una mejor

experiencia de usuario, por lo tanto se considera como un requisito

recomendable, pero no primordial para el desarrollo de la plataforma.

FN.7: Distintos modelos y exámenes.

Descripción: La plataforma debe ser capaz de generar ambos tipos de

exámenes oficiales de japonés, tanto el Nō ken N5 como Kanken 10. El usuario

podrá realizar cualquiera de los exámenes anteriormente mencionados, con

diferentes preguntas, es decir, no siempre el mismo modelo.


Validez:



Cap

ítu

lo: E

spec

ific

ació

n

46

o Medible: Se realizarán pruebas de generación de modelos de ambos

exámenes, tanto de forma aislada como integrada en la plataforma.

o Alcanzable: Para lograr una buena generación de preguntas, se

emplearán exámenes tipo suministrados por el Gobierno de Japón.

o Relevante: Los futuros usuarios de la plataforma la emplearán como

medio de estudio del idioma japonés y como medio de práctica para

poder afrontar los exámenes oficiales, por lo que, el cumplimiento de

este requisito es muy importante para evitar que los usuarios caigan en

monotonía y como consecuencia abandonen el uso de la plataforma.

FN.8: Controlar las respuestas de la evaluación.

Descripción: La plataforma debe ser capaz de analizar las respuestas a las

preguntas de los exámenes, introducidas por el usuario de manera automática, y

realizar las correspondientes comprobaciones para obtener una salida coherente

y veraz sobre el nivel de conocimiento demostrado durante el transcurso de la

prueba.


Validez:

o Medible: Se realizarán las pruebas necesarias hasta reducir a “cero” las

posibilidades de fallo en la evaluación de las pruebas de examen, para así

garantizar el correcto funcionamiento de la plataforma.

o Alcanzable: Mediante tablas de la base de datos correspondiente,

relacionadas entre sí, y mediante análisis de las respuestas introducidas

por el usuario y las soluciones almacenadas, se podrá garantizar el

cumplimiento de este requisito.

o Relevante: El cumplimiento de este requisito es indispensable para

poder atraer al mayor número de usuarios a usar la plataforma. Si no se

logra verificar este requisito, el desarrollo de la plataforma no tendrá

ningún sentido.



Cap

ítu

lo: E

spec

ific

ació

n

47

FN.9: Controlar el orden de escritura.

Descripción: El usuario debe aprender el orden adecuado de los trazos de los

kanjis, ya que es uno de los factores importantes de la escritura japonesa. Por

ello, la plataforma debe ser capaz de analizar la escritura realizada por los

usuarios en el OCR de la misma y evaluar el orden de escritura de los kanjis.


Validez:

o Medible: Se realizarán pruebas del OCR de la plataforma con

estudiantes voluntarios del “Centro Superior de Idiomas Modernos” de

la Universidad Complutense de Madrid.

o Alcanzable: Se analizarán los trazos realizados por los usuarios en el

proceso de escritura de los kanjis para así poder realizar un diagnóstico

adecuado.

o Relevante: El cumplimiento de este requisito es muy recomendable

aunque no obligatorio. La plataforma puede funcionar de manera

correcta sin su realización, aunque ayudaría a los usuarios a obtener un

conocimiento más “refinado” de la escritura japonesa.

FN.10: Manual para solucionar posibles problemas de los usuarios.

Descripción: Contar con un manual de usuario con las instrucciones necesarias

para dar soluciones a los posibles problemas que se les puedan presentar a los

usuarios durante el uso de la plataforma.


Validez:

o Alcanzable: Se analizarán todos los aspectos destacables de la

plataforma y todas las opciones posibles a realizar por los usuarios, y

éstas, se plasmarán en un manual de usuario. Dicho manual debe estar

adjunto con este documento.

o Relevante: El cumplimiento de este requisito es muy importante, ya que

da un aspecto distinto hacia el público, además ahorra tiempo al usuario

y mejora el servicio de la plataforma. En definitiva, es contar con una



Cap

ítu

lo: E

spec

ific

ació

n

48

base de conocimiento sobre la plataforma que pueda ayudar al uso

completo de la misma.

FN.11: Evaluación al instante.

Descripción: Ofrecer al usuario los resultados de las pruebas realizadas de

examen al instante. Una vez que el usuario decida que ha terminado el examen,

este se evaluará y mostrando al usuario los resultados obtenidos en la prueba

realizada.


Validez:

o Medible: Se realizarán las pertinentes pruebas de evaluación de distintos

modelos de examen generados previamente por la aplicación y se

observarán los tiempos de respuesta de la corrección de dichos

exámenes.

o Alcanzable: Se programará un módulo que se encargará de evaluar las

pruebas de examen realizadas por los usuarios de la plataforma.

o Relevante: El cumplimiento de este requisito es indispensable para

ofrecer un aspecto atractivo de la plataforma que atraiga la atención de

los usuarios.

FN.12: Generación rápida de modelos de examen.

Descripción: La plataforma debe ofrecer una buena disponibilidad y una

rapidez aceptable a la hora de generar los modelos de examen y presentárselos

al usuario.


Validez:

o Medible: Se realizarán pruebas con un número determinado de usuarios

conectados a la vez a la plataforma para ver la velocidad de la

plataforma a la hora de generar los modelos de exámenes.

o Alcanzable: Para lograr este requisito se precisa realizar una correcta

extracción de los datos de la base de datos correspondiente, así como

disponer de un servidor adecuado para un cierto número de conexiones,



Cap

ítu

lo: E

spec

ific

ació

n

49

que se estudiarán según el número de usuarios esperados y la

popularidad de la plataforma.

o Relevante: El cumplimientos de este requisito garantiza el buen

funcionamiento de la plataforma, y por consiguiente, una posible “gran”

aceptación por parte de los usuarios. Este requisito es principalmente

para el desarrollo de la versión web de JSKanken.

FN.13: Disponer de un diccionario.

Descripción: La plataforma deberá disponer de un diccionario de kanjis para

facilitar el aprendizaje de los mismos al usuario. Deberán contener información

suficiente para poder realizar un correcto aprendizaje. Deberá permitir realizar

distintos tipos de búsqueda.


Validez:

o Medible: El contenido del diccionario de la plataforma lo validará una

persona con los conocimientos suficientes en el lenguaje japonés.

o Alcanzable: Se desarrollará un apartado en la plataforma como “rama de

estudio”, que pondrá al alcance de los usuarios un diccionario con la

información necesaria de cada kanji.

o Relevante: El cumplimiento de este requisito se considera deseable para

poder ofrecer al usuario todo lo necesario para realizar los exámenes

oficiales y no tener que depender de material externo de la propia

plataforma.



Cap

ítu

lo: E

spec

ific

ació

n

50

4.3.2. REQUISITOS DE INTERFAZ

En este punto del documento se procede a plasmar los requisitos de interfaz

considerados necesarios para el desarrollo del proyecto, es decir, aquellos requisitos

que definen principalmente el aspecto visual de la plataforma a desarrollar.

IN.1: Interfaz sencilla.

Descripción: La UI (Interfaz de Usuario), debe ser lo más sencilla posible en

primera instancia, para poder facilitar el uso de la plataforma. Debe ser un

entorno intuitivo, atractivo y amigable para los usuarios.


Validez:

o Medible: Se realizarán pruebas de la plataforma con estudiantes


Universidad Complutense de Madrid.

o Alcanzable: Se emplearán para el desarrollo de la plataforma estilos

atractivos para los usuarios y etiquetas que permitan un mejor

entendimiento de la plataforma.

o Relevante: El cumplimiento de este requisito es primordial si se desea

llegar al máximo de usuario posibles de la plataforma. Su cumplimiento

facilitaría el uso, a usuarios menos experimentados, ofreciendo la

posibilidad de emplear esta plataforma como alternativa para el estudio

del idioma japonés.

IN.2: Panel de usuario.

Descripción: La plataforma debe contener una ficha con la información

correspondiente al usuario que la esté utilizando. Constará como el perfil del

usuario, que contendrá los datos del usuario con su foto de perfil, así como los

últimos resultados obtenidos en las pruebas que haya realizado con anterioridad.


Validez:

o Medible: Se realizarán pruebas de los perfiles con estudiantes




Cap

ítu

lo: E

spec

ific

ació

n

51

Universidad Complutense de Madrid. Además de comprobar los

resultados de las pruebas realizadas con los datos proporcionados por el

Gobierno Japonés sobre exámenes oficiales.

o Alcanzable: Se emplearán los datos proporcionados por los usuarios y

las pruebas realizadas para construir una vista de la “ficha del usuario”.

o Relevante: El cumplimiento de este requisito es importante para darle

aspecto de red social a la plataforma de cara al usuario y poder ofrecerle

al usuario una visión sobre su progreso para “animarle” a mejorar sus

conocimientos.

IN.3: Ficha de estudio.

Descripción: Cada kanji integrado en la plataforma debe contener toda la

información necesaria para proporcionar a los usuarios un mejor estudio del

mismo. Deberá contener al menos el significado e ideograma del kanji, el

número de trazos, todas las posibles lecturas del kanji (on’yomi y kun’yomi), así

como al menos tres ejemplos de uso del kanji.


Validez:

o Medible: Se realizarán al menos dos tipos de fichas para representar los

kanjis, y los usuarios que realizarán las pruebas de la plataforma

elegirán cual es la más adecuada y atractiva.

o Alcanzable: Para realizar las fichas de los kanjis se utilizaran estilos web

atractivos que atraigan la atención de los usuarios, pero sin dificultar la

lectura o entendimiento del contenido de la ficha.

o Relevante: El cumplimiento de este requisito es deseado aunque no

imprescindible, puesto que la información se mostrará de una manera u

otra a los usuarios, pero es deseable porque resultaría una interfaz

mucho más atractiva.

IN.4: Examen modelo.

Descripción: Los diferentes exámenes generados por la plataforma para

evaluar al usuario sobre los conocimientos del idioma japonés, se deben mostrar

como si se tratase de un examen oficial, para así, facilitar al usuario la



Cap

ítu

lo: E

spec

ific

ació

n

52

realización de este de manera oficial cuando se presente a una convocatoria de

dicho examen.


Validez:

o Medible: Se generarán distintos exámenes con las cuentas de “usuarios

de pruebas”, y comparando el modelo generado de examen de la

plataforma, con los modelos de examen oficiales proporcionados por el

Gobierno de Japón.

o Alcanzable: Se creará un panel que contendrá el examen generado y se

mostrará pregunta a pregunta según el orden oficial. Para lograr la

mayor similitud posible y compatibilidad con todo tipo de navegadores

web, se empleará el atributo “title” para mostrar las lecturas de los

campos a rellenar del examen generado.

o Relevante: El cumplimiento de este requisito es deseable pero no

imprescindible. Con su consecución se logra ofrecer al usuario de la

plataforma una visión más fiel de cara a su presentación a convocatorias

oficiales.

IN.5: Resultado de las pruebas.

Descripción: La plataforma debe obtener los resultados de las pruebas de

examen realizadas por los usuarios y mostrarlos. Los resultados del examen

Kanken N10 se deben mostrar en forma de gráfico radial, de la misma forma

que el oficial.


Validez:

o Medible: Se generarán diversos gráficos a partir de unos resultados

dados aleatoriamente.

o Alcanzable: Mediante la librería de PHP, JPGraph, se generarán los

gráficos radiales utilizando de modelo los oficiales proporcionados por el

Gobierno de Japón. Dichos gráficos se deben almacenar en el servidor

por si el usuario desea consultarlos en otras ocasiones.

o Relevante: El cumplimiento de este requisito es deseado, puesto que lo

que se quiere es una gran similitud con los exámenes oficiales. Además



Cap

ítu

lo: E

spec

ific

ació

n

53

daría valor añadido a la plataforma, dotándola de un componente más

visual. Es una forma más directa de ver los resultados.

IN.6: Desarrollo de logotipo.

Descripción: Consiste en el desarrollo de un logotipo adecuado con la temática

y el nombre de la plataforma, es decir, sobre el idioma japonés, la enseñanza e

importante contener el nombre de JSKanken en el logotipo.


Validez:

o Alcanzable: Se desarrollará el logotipo de forma vectorial de manera que

no pierda calidad al ampliar o reducir su tamaño. Además, debe estar

con gama de colores CMYK y con una resolución de 300 píxeles por

pulgada para garantizar, nuevamente, la calidad a la hora de realizar

impresiones del mismo.

o Relevante: Este requisito se considera deseada, ya que el disponer de un

logotipo propio da una mejor imagen a los usuarios y al público en

general. Principalmente se realiza por la imagen de la plataforma.



Cap

ítu

lo: E

spec

ific

ació

n

54

4.3.3. REQUISITOS DE CALIDAD

En esta sub-sección del documento se procede a plasmar los requisitos de calidad

necesarios para obtener un “producto final” adecuado y que llegue al mayor número de

usuarios posibles con las mejores condiciones posibles.

CA.1: JSKanken plataforma sencilla.

Descripción: La plataforma JSKanken debe ser lo más sencilla posible, como ya

se ha mencionado anteriormente, para facilitar y posibilitar su utilización por

parte de usuario con “escasos” conocimientos informáticos.


Validez:

o Medible: Se evaluará la experiencia de distintos perfiles de usuarios de

la plataforma, en el caso de que no tengan dificultades para realizar las

pruebas de la plataforma, el requisito se verá satisfecho.

o Alcanzable: Se simplificará todo lo posible el uso de la plataforma con

etiquetas o los “elementos” que se consideren necesarios para una fácil

utilización de la misma. De esta manera, un usuario poco experimentado

podrá utilizar la plataforma sin problemas.

o Relevante: En caso de no llegar al cumplimiento de este requisito, hará

caer en picado la calidad de la plataforma JSKanken, ya que una de sus

principales características debe ser la facilidad de uso.

CA.2: Salvaguarda de los datos.

Descripción: Para asegurar la calidad de la plataforma, debe existir una copia

de los datos de la misma, tanto del código de la propia plataforma como de las

bases de datos.


Validez:

o Alcanzable: Se realizarán copias de las bases de datos y existirán dos

versiones de la plataforma una vez esté expuesta al público, coexistiendo

una versión de producción y otra de desarrollo.



Cap

ítu

lo: E

spec

ific

ació

n

55

o Relevante: El cumplimiento de este requisito garantiza la buena calidad

en caso de fallos de la plataforma o intrusión en los servidores. Al existir

una copia de los datos se asegura que los usuarios no pierdan sus

progresos realizados y que la propia plataforma pueda reponerse en caso

de ataques.



Cap

ítu

lo: E

spec

ific

ació

n

56

4.3.4. REQUISITOS DE PROYECTO

En esta sub-sección del documento se procede a plasmar los requisitos de

proyecto que se centran principalmente en directrices de restricciones sobre el

desarrollo de este proyecto.

PR.1: Límites de tiempo.

Descripción: Este proyecto se desarrolla para la asignatura de “Proyecto Final

de Carrera” de Ingeniería Informática Superior de la Universidad Pontificia de

Comillas, por ello, el proceso de desarrollo está acotado a, aproximadamente, 8

meses de trabajo, comprehendidos entre Octubre de 2011 y Mayo de 2012.


Validez:

o Alcanzable: En el periodo especificado en la descripción del requisito, el

desarrollo de la plataforma JSKanken deberá ser lo más completa

posible, fiel a los requisitos expuestos en esta lista. Se tratará conseguir

una versión usable de la plataforma para la fecha límite del proyecto.

o Relevante: El cumplimiento de este requisito no es obligatorio para la

fecha de mayo puesto que existe otra fecha para la presentación del

proyecto, pero si es deseable lograr el desarrollo del proyecto en las

fechas de este requisito.



Cap

ítu

lo: E

spec

ific

ació

n

57

4.3.5. REQUISITOS DE EVOLUCIÓN

En esta sub-sección del documento se procede a plasmar los requisitos de

evolución del desarrollo del proyecto, es decir, requisitos necesarios para poder realizar

ampliaciones que se consideren necesarias una vez finalizado el desarrollo de este

proyecto.

EV.1: Actualizable.

Descripción: La plataforma podrá aumentar según la cantidad de usuarios, por

ello, deberá permitir actualizaciones de contenidos, así como permitir aumentar

los kanjis reconocidos por el OCR de la plataforma para poder abarcar más

niveles de exámenes oficiales y no solo del nivel inicial de la lengua japonesa.


Validez:

o Alcanzable: Para lograr cumplir este requisito se debe realizar una

programación adecuada y limpia que permita un fácil entendimiento

para futuras ampliaciones de la plataforma.

o Relevante: El cumplimiento de este requisito es importante de cara a

continuar con el desarrollo de este proyecto una vez evaluada su utilidad

con los usuarios registrados.



Cap

ítu

lo: E

spec

ific

ació

n

58

4.3.6. REQUISITOS DE SOPORTE

En esta sub-sección del documento se procede a plasmar los requisitos de soporte

necesarios para la posterior utilización del “producto final” obtenido del desarrollo de

este proyecto. Estos requisitos no son propios para el desarrollo de la plataforma en la

que se centra este proyecto, sino requisitos que deben cumplir los futuros usuarios de

la plataforma para poder utilizar la misma.

SO.1: Usuario con Internet.

Descripción: Al tratarse de una plataforma web, el computador del usuario

deberá contar con conexión a internet y con al menos un navegador, con el fin

de posibilitar el uso de la plataforma al usuario. De otra manera, la plataforma

no sería funcional para el usuario.


SO.2: Usuario con Smartphone.

Descripción: El desarrollo de este proyecto, como se ha comentado en

anteriores apartados de este documento, incluye de forma obligatoria el

desarrollo de la plataforma en versión web y de forma opcional, el desarrollo de

la misma plataforma en versión móvil (android), y de esta forma atraer a un

mayor número de usuarios posibles. Por ello, el usuario que desee utilizar la

plataforma en su versión móvil, deberá disponer de un dispositivo adecuado

para la utilización de la correspondiente aplicación. En próximos apartados se

especificarán los requisitos necesarios de Smartphone.




Cap

ítu

lo: E

spec

ific

ació

n

59

Capítulo 5

DISEÑO DE LA

PLATAFORMA.



Cap

ítu

lo: E

spec

ific

ació

n

60



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

61

5. DISEÑO DE LA PLATAFORMA

En este punto de la documentación del proyecto, se procede a explicar y detallar

todos los pasos que se han seguido y realizado para determinar y desarrollar el diseño

de la plataforma JSKanken.

Se comenzará exponiendo la jerarquía de usuarios de la plataforma, en el que se

indicarán los distintos tipos de usuarios que existen. Para proseguir, se desarrollará

los diagramas de casos de uso de las principales categorías de la jerarquía de usuarios.

Para proseguir, se realizará el modelo lógico de datos de nuevo sistema, con una

breve descripción sobre qué es un DFD, para qué sirve, y el porqué de su desarrollo;

así como las diferentes descomposiciones del sistema con una explicación de su

funcionamiento y el diccionario de datos del modelo lógico.

Por último, se desplegará el modelo de diseño de las tablas de la base de datos de

la plataforma.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

62

5.1. JERARQUÍA DE USUARIO

Las categorías de usuarios finales que interactúan con la plataforma se identifican

como parte de las tareas de formulación y de recopilación de requisitos. En la mayoría

de los casos, las categorías de usuario son relativamente limitadas y no necesitan de

representación UML. Sin embargo, cuando el numero de categorías de usuario crece,

es aconsejable desarrollar una jerarquía de usuario, como se muestra en la siguiente

figura.

Figura 5 – Jerarquía de usuario

Las categorías de usuario, también llamados actores, indican la funcionalidad que

ofrece la plataforma.

En la misma figura, el usuario de JSKanken.com en la parte superior de la

jerarquía representa la clase de usuario más general y se refina niveles abajo. Un

visitante es un usuario que visita el sitio pero no se registra, estos usuarios usualmente

buscan información general sobre la plataforma. Un usuario registrado dedica tiempo

para ofrecer información y se le considera un contacto. Las subcategorías para los

usuarios registrados incluyen:

o Usuario nuevo: usuario registrado que quiere registrarse en la

plataforma.

o Usuario existente: un usuario que ya a participado con anterioridad en la

plataforma y la ha utilizado las funcionalidades existentes en la

plataforma.

Usuario de JSKanken.com

Visitante Usuario registrado

Usuario nuevo Usuario existente

Administrador



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

63

5.2. CASOS DE USO

Los casos de uso describen cómo interactuará con la plataforma una categoría de

usuario específica. La acción puede ser tan simple como adquirir contenido definido, o

tan compleja como que el usuario realice un análisis detallado de registros

seleccionados que se mantiene en una base de datos. En definitiva, los casos de uso

describen la interacción desde el punto de vista del usuario.

Aunque desarrollarlos y analizarlos toma tiempo, los casos de uso:

o Ayudan al desarrollador a entender cómo perciben los usuarios su

interacción con la plataforma.

o Proporcionan el detalle necesario para crear un modelo de análisis

efectivo.

o Ayudan a dividir en compartimentos el trabajo.

o Ofrecen una guía importante para quienes deben probar la plataforma.

Franklin [FRA01] se refiere a los casos de uso como “haces de funcionalidad”.

Esta descripción captura la esencia de esta importante técnica de modelado de análisis.

Los casos de uso se desarrollan para cada categoría de usuario descrita en la jerarquía

de usuario.

A continuación se realizarán los diagramas de caso de uso para usuario registrado

y administrador.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

64

5.2.1. DIAGRAMA DE CASO DE USO PARA USUARIO NUEVO

La siguiente figura representa un diagrama UML de caso de uso para la

categoría de usuario “usuario nuevo”. Cada grafía circular en el diagrama representa

un caso de uso que describe una interacción específica entre el “usuario nuevo” y la

plataforma.

Figura 6 – Caso de uso para usuario nuevo

Como se puede observar, un usuario nuevo en la plataforma la única forma que

tendrá de interaccionar con ella, será registrarse.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

65

5.2.2. DIAGRAMA DE CASO DE USO PARA USUARIO REGISTRADO

En este caso de uso se representa la funcionalidad que podrá realizar un usuario

registrado en la plataforma.

Figura 7 – Caso de uso para usuario registrado

Como se puede ver en la figura superior, si el actor que interactúa con el sistema

tiene la categoría de usuario registrado, podrá identificarse, configurar el perfil,

realizar aprendizaje del idioma, realizar pruebas de exámenes, ver su progreso y salir

de la plataforma.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

66

5.2.3. DIAGRAMA DE CASO DE USO PARA ADMINISTRADOR

En este caso de uso se representa la funcionalidad que podrá realizar un usuario

con la categoría de “administrador” en la plataforma.

Figura 8 – Caso de uso para administrador

En la figura superior, han quedado reflejadas las principales funcionalidades de

un administrador de la plataforma JSKanken, desde identificarse como tal, hasta

gestionar todos los contenidos y usuarios de la plataforma.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

67

5.3. MODELO LÓGICO DE DATOS

Un diagrama de flujo de datos (DFD) es una representación gráfica del “flujo”

de datos a través de un sistema de información. Es una práctica muy común para un

diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción

entre el sistema y las entidades externas.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el

desarrollador original del diseño estructurado, basado en el modelo de computación de

Martin y Estrin: “flujo gráfico de datos”. Los diagramas de flujo de datos (DFD) son

una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño

por el método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán

que ser informados y consultados en todas las etapas de una evolución del sistema. Con

un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el

sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica.

En ocasiones, también es elaborado el antiguo sistema de diagramas de flujo para

establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente.

Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario

final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un

efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es

desarrollado puede determinarse a través de un diagrama de flujo de datos. El

desarrollo de un DFD ayuda en la identificación de los datos de la transición en el

método de datos.

Todo sistema se suele dividir en al menos tres niveles:

Nivel 0: Diagrama de contexto.

Nivel 1: Diagrama de nivel superior.

Nivel 2: Diagrama de detalle o expansión.

Desglosar un DFD de nivel 2, significa que necesita una explosión más para

poder definir mejor el sistema.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

68

Las principales características de este método de representación del flujo de datos

del sistema son:

Gráfica: Utiliza gráficos para especificar.

Concisa: No pretende documentos voluminosos.

Top-Down: El sistema se acomete de arriba abajo.

Particionada: El sistema se descompone en piezas tan pequeñas como sea

preciso.

No redundante: Cada elemento es definido una sola vez.

Esencia: Hace hincapié en qué debe hacer el sistema y no en cómo se

configura.

El modelado de datos orientado al flujo es una de las notaciones de análisis

utilizadas con mayor amplitud en la actualidad, pero con un antiguo historial. Aunque

el diagrama de flujo de datos (DFD), los diagramas y la información relacionados, no

son una parte formal de UML, pueden utilizarse para completar los diagramas en

UML y proporcional un conocimiento adicional de los requisitos y flujo del sistema.

El DFD tiene una visión del sistema del tipo entrada-proceso-salida. Esto quiere

decir, que los objetos de datos que fluyen hacia el interior del software, se transforman

mediante elementos de procesamiento, y los objetos de datos resultantes fluyen hacia

el exterior del software. Los objetos de datos se representan mediante flechas rotuladas

y las transformaciones se representan por medio de círculos, también denominadas

burbujas. El DFD se presenta en forma de jerarquía, esto es, el primer modelo de flujo

de datos (llamado DFD de nivel 0 o diagrama de contexto) representa el sistema de

forma general, como un todo. Los diagramas de flujo subsecuentes refinan el diagrama

de contexto, ya que proporcionan una cantidad creciente de detalle con cada nivel

subsiguiente.

“El propósito de los diagramas de flujos de datos es proporcionar un

puente semántico entre los usuarios y los desarrolladores de

sistemas”.

Kenneth Kozar



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

69

El diagrama flujo de datos permite desarrollar modelos del dominio de

información y del dominio funcional al mismo tiempo. A medida que el DFD se refina

hacia grados mayores de detalle, el analista desempeña una descomposición funcional

implícita del sistema. Al mismo tiempo el refinamiento del DFD resulta en un

correspondiente refinamiento de datos mientras se mueve hacia los procesos que

incorpora el sistema.

Unas pocas directrices que permiten obtener una ayuda invaluable durante la

creación de un diagrama de flujo de datos son las siguientes:

1. El nivel 0 del diagrama de flujo de datos debe representar al sistema como

una sola burbuja.

2. La entrada y salida deben establecerse con cuidado.

3. La refinación debe comenzar por el aislamiento de procesos, objetos de

datos y almacenamiento de datos, candidatos a ser representados en el

siguiente nivel.

4. Todas las flechas y burbujas se deben rotular con nombres significativos.

5. Se debe mantener la continuidad del flujo de información al cambiar de

nivel a nivel.

6. La refinación de las burbujas debe hacerse una por una.

Existe una tendencia natural a complicar de más, el diagrama de flujo de datos.

Esto ocurre cuando el analista intenta mostrar muchos detalles con antelación o

representar aspectos de procedimientos del software en lugar de elementos del flujo de

información.

En muchos tipos de sistemas, el modelo de datos y el diagrama de flujo de datos

son todo lo que se necesita para obtener una visión significativa de los requisitos de

software. Sin embargo, existe una clase muy grande de sistemas que están guiadas por

eventos en lugar de datos, que producen información de control en lugar de reportes o

despliegues, y que procesan información con un especial interés por el tiempo y

rendimiento. Dichos sistemas requieren aplicar el modelado de control del flujo.

A continuación se va a presentar el modelo lógico del nuevo sistema. No se

considera necesario representar el del sistema actual, puesto que “no existe” nada



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

70

parecido. Para representar los diagramas de flujo del sistema JSKanken se ha empleado

el método de Yourdon.

5.3.1. NIVEL 0: NIVEL DE CONTEXTO DE JKANKEN

A continuación se muestra la figura correspondiente al nivel 0 o nivel de

contexto de la plataforma JSKanken, y posteriormente una breve descripción de la

interacción de la entidad externa con la plataforma.

Figura 9 – Nivel 0: Nivel de contexto de JSKanken

En el nivel contextual del sistema se puede observar una entidad externa que

rodea a la plataforma JSKanken, que se corresponde con el “dispositivo del usuario”

que interaccione con ella. Se procede a reseñar de una forma breve la entidad externa:

0

JSKanken

v1.0

Dispositivo

Usuario

Iniciar APP

Solicitar

Ident./Reg.

Estudiar

Datos Ident./Reg.

Solicitar

Acción

Ident./Reg.

OK/Error

Realizar Examen

Ver Progreso

Salir

Solicitar Baja

Elegir Tipo

Elección Tipo

Mostrar Examen

Gen.

Datos Examen

Mostrar

Resultados

Ex.Mostrar Progreso

Mostrar Op.

EstudioOp. Estudio

Mostrar Estudio

Estado Baja

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name

f :\jskank~1\dfdjsk~1\

dfd00001.dfd

Yourdon - Nivel 0

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

71

Dispositivo Usuario.

Como su nombre indica, esta entidad externa es el dispositivo de

entrada/salida que empleará cualquier usuario que desee hacer uso de

la plataforma JSKanken. Este dispositivo puede ser tanto un

computador como un dispositivo móvil adecuado para poder utilizar

el sistema.

Entrando más en detalle, esta entidad externa, será el encargado de

mostrar todos los flujos de datos que la plataforma requiera

comunicar al usuario, así como los flujos de datos que el usuario

necesite transmitir a la plataforma. En la siguiente tabla se pueden

ver todos los flujos de datos de interacción entre el usuario y el

sistema, realizando una breve descripción.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

72

5.3.2. NIVEL 1: MODELO CONCEPTUAL DE JSKANKEN

A continuación se muestra la figura correspondiente al nivel 1 o nivel conceptual

de la plataforma JSKanken, y posteriormente una breve descripción de cada

proceso/entidad involucrado en ella.

Figura 10 – Nivel 1: Modelo conceptual de JSKanken

En la figura superior se pueden distinguir tres grandes procesos que son los

encargados de ofrecer unos flujos de datos de respuesta al usuario dependiendo de los

flujos de datos de entrada. Se procede a analizar estos tres procesos destinados a

cumplir las funcionalidades del sistema:

Gestor.

Es el proceso principal que se encarga de gestionar desde que un

usuario establece la conexión con la plataforma hasta que se

desconecta. Sus principales funciones son el proceso de

1

Gestor

2

Examinador

3

AprenderOp. Estudio

Datos Examen

Elección Tipo

Solicitar Baja

Salir

Ver Progreso

Realizar Examen

Datos Ident./Reg.

Estudiar

Iniciar APP

Estado Baja

Mostrar Estudio

Mostrar Op.

Estudio

Mostrar Progreso

Mostrar

Resultados

Ex.

Mostrar Examen

Gen.

Elegir Tipo

Ident./Reg.

OK/Error

Solicitar

Acción

Solicitar

Ident./Reg.

Realizar Ex.

OK

Estudiar OK



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

73

conexión/desconexión de la plataforma, la identificación y registro de

los usuarios, y gestionar las acciones que puede realizar un usuario en

la plataforma.

Examinador.

Este proceso es el encargado de administrar la realización de pruebas

de exámenes de la plataforma. Una vez que el usuario decide la

opción de realizar un examen, el proceso «Gestor», le indica que puede

empezar con sus correspondientes funciones a interaccionar con el

usuario, enviándoles el correspondiente flujo de datos al proceso

«Examinador». Sus principales funciones son las de: ofrecer los tipos

de exámenes que los usuarios pueden realizar, y generar dichos

exámenes de forma adecuada para presentárselos a los usuarios, así

como recoger las respuestas al examen del usuario y evaluarlas,

mostrándole los resultados obtenidos.

Aprender.

Es el proceso destinado a realizar la funcionalidad de aprendizaje

disponible en la plataforma. Una vez el proceso del «Gestor» analiza

la opción del usuario y determina que este desea utilizar el panel de

aprendizaje de la plataforma, el proceso «Aprender» le ofrece los tipos

de estudio disponibles y según la respuesta del usuario, realiza uno u

otro, genera el estudio correspondiente y se lo muestra al usuario.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

74

5.3.3. NIVEL 2: EXPLOSIÓN DEL PROCESO «GESTOR»:

Se procede a mostrar la figura correspondiente al nivel 2 o primer nivel de

explosión del proceso 1, o también denominado proceso «Gestor» para entrar más en

detalle en su funcionamiento.

Figura 11 – Nivel 2: Explosión del proceso Gestor

1.1

Iniciar

Identif icación

1.2

Registrar

Us.

1.3

Identif icar

Us.

BD

Usuarios

1.4

Control

Usuarios

1.5

Mostrar

Op.

1.6

Realizar

Baja

1.7

Recuperar

Progreso

1.8

Realizar

Otros

BD Progreso

Usuarios

1.9

Organizar

Progreso

Iniciar APP

Estudiar

Datos Ident./Reg.

Realizar Examen

Ver Progreso

Salir

Solicitar Baja

Estudiar OKRealizar Ex.

OK

Solicitar

Ident./Reg.

Solicitar

Acción

Ident./Reg.

OK/Error

Mostrar Progreso

Estado Baja

Registro

Identif icación

Inscribir Us.

Petición Us.

FG1

Proc. OK

Op. Baja OK

Petición Baja

Us.

Estado Baja

Op. Porgreso

OK

Op.Estudiar

OK

Op. Examen OK

Petición de

progresos

Datos Progreso

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name


dfd00011.dfd

Módulo Gestor

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

75

En la figura anterior se pueden distinguir un total de nueve sub-procesos que

conforman el proceso «Gestor», dos generales que definen de una forma más concreta

las funcionalidades que se permiten realizar en este nivel de explosión (sub-proceso 1.1

y sub-proceso 1.5), y otros siete sub-procesos que se encarga de llevar a cabo las

acciones derivadas de los otros dos sub-procesos. Se procede a analizar estos nueve

sub-procesos de este primer nivel de explosión.

Iniciar identificación.

Uno de los sub-proceso principales del proceso «Gestor». Una de sus

principales funciones es la de presentar al usuario las opciones de la

plataforma una vez éste establece conexión con la plataforma, es decir,

le solicita al usuario que se registre o se identifique para poder

proseguir con la utilización de la plataforma. Una vez este sub-

proceso recibe los datos que el usuario introduzca, los analiza, y

según detecte un registro o una identificación actuará en consecuencia.

Registrar us.

Sub-proceso que inicia su funcionamiento mediante un flujo recibido

del sub-proceso 1.1 «Iniciar Identificación». Su principal función es la

de analizar los datos recibidos por el flujo de datos y generar la

correspondiente query para la inserción del usuario en la base de datos

de la plataforma.

Identificar us.

Sub-proceso que inicia su funcionamiento mediante un flujo recibido

del sub-proceso 1.1 «Iniciar Identificación». Su principal función es la

de analizar los datos recibidos por el flujo de datos y generar la

correspondiente query para la identificación del usuario en la

plataforma, y así permitirle proseguir con su utilización.

Control usuarios.

Sub-proceso que recibe el flujo de datos generado de la ejecución de

las querys realizadas por los sub-procesos 1.2 y 1.3 a la base de datos.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

76

Se encarga de analizar dicho flujo de datos, y dependiendo del

resultado obtenido, permitir proseguir al usuario con la utilización de

la plataforma o denegarle el acceso mediante un mensaje de error.

Mostrar op.

Uno de los sub-proceso principales del proceso «Gestor». Su principal

funcionalidad es la de ofrecer al usuario las posibles opciones de las

que dispone para el uso de la plataforma, es decir; realizar aprendizaje

del idioma, realizar exámenes tipo modelo oficial, ver progreso de

estudio, o darse de baja. Dependiendo de cuál sea la respuesta del

usuario, este sub-proceso se encargará de mandar una orden de

ejecución al sub-proceso correspondiente.

Realizar Baja.

Sub-proceso encargado de realizar la baja de un usuario de la

plataforma, mediante previa petición de este. Su principal función es

la de generar la correspondiente query para realizar la petición de

baja de la base de datos, y una vez llevada a cabo, mostrar al usuario

el estado de la misma, ya sea correcta o errónea.

Recuperar progreso.

Sub-proceso que recibe la orden de recuperar el progreso de un

usuario y se encarga de generar la adecuado query y ejecutarla.

Realizar otros.

Sub-proceso que se encarga de gestionar las opciones de realizar

examen y realizar aprendizaje disponibles en la plataforma.

Organizar progreso.

Sub-proceso que analiza los datos obtenidos mediante la petición

realizada por el sub-proceso 1.7. Su principal función es la de analizar

los datos, estructurarlos, generar el correspondiente gráfico para



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

77

poder mostrar al usuario dichos resultados de una forma gráfica y

más sencilla de comprehender, y mostrarlos.

5.3.4. NIVEL 2: EXPLOSIÓN DEL PROCESO «EXAMINADOR»:


explosión del proceso 2, o también denominado proceso «Examinador» para entrar más

en detalle en su funcionamiento.

Figura 12 – Nivel 2: Explosión del proceso Examinador

En la figura superior se muestran un total de cuatro sub-procesos, dos con flujos

de entrada/salida del proceso «Examinador», y otros dos con flujos internos. Se

prosigue describiendo los cuatro sub-procesos identificados de la figura:

2.1

Seleccionar

Tipo

2.3

Generar

Kanken

10

2.2

Generar

Noken

N5

2.4

Controlar

Examen

Realizar Ex.

OK

Mostrar Examen

Gen.

Elección Tipo

Datos Examen

Elegir Tipo

Mostrar

Resultados

Ex.

Tipo K

Tipo N

Ex. K GeneradoEx. N Generado

Ex. Generado

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name


dfd00006.dfd

Módulo Examinador

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

78

Seleccionar tipo.

Este sub-proceso inicia su funcionalidad mediante un flujo de entrada

que le indica que el usuario quiere realizar un examen. La función de

este sub-proceso es la de darle a elegir al usuario los tipos de exámenes

disponibles, y una vez reciba el tipo, mandar la orden de ejecución al

sub-proceso correspondiente: 2.2 o 2.3.

Generar Nōken N5.

Este sub-proceso es el encargado de generar el examen tipo N, es decir,

tipo Nōken N5, a partir de preguntas aleatorias extraídas de la base de

datos de la plataforma. Una vez generado el examen, lo recibe el sub-

proceso 2.4.

Generar Kanken 10.

Este sub-proceso es el encargado de generar el examen tipo K, es decir,

tipo Kanken 10, a partir de preguntas aleatorias extraídas de la base de

datos de la plataforma. Una vez generado el examen, lo recibe el sub-

proceso 2.4.

Controlar examen.

Su principal función, es una vez recibido uno de los dos flujos de datos

de salida de los sub-procesos 2.2 o 2.3, éste inicia su funcionalidad,

mostrando el examen generado por la plataforma y esperando la

respuesta del mismo por parte del usuario, para así poder empezar su

corrección y mostrarle los resultados obtenidos en el examen al

usuario.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

79

5.3.5. NIVEL 2: EXPLOSIÓN DEL PROCESO «APRENDER»:


explosión del proceso 3, o también denominado proceso «Aprender», para entrar más en

detalle en su funcionamiento.

Figura 13 – Nivel 2: Explosión del proceso Aprender

En la figura anterior se pueden diferenciar un total de tres sub-procesos y un

almacén que conforman el proceso «Aprender». Se procede a analizar estos tres sub-

procesos de este primer nivel de explosión.

Iniciar estudio.

Sub-proceso encargado de, una vez recibe el flujo de «Estudiar OK»,

mostrarle al usuario las opciones de aprendizaje disponibles en la

plataforma. Una vez el usuario decide qué forma de aprendizaje desea

realizar, este sub-proceso le manda la opción elegida por el usuario al

sub-proceso 3.2 para comenzar con su análisis.

3.1

Iniciar

Estudio

3.2

Analizar

Op.

BD

Kanjis

3.3

Generar

Ficha

Estudio

Estudiar OK

Op. Estudio

Mostrar Op.

Estudio

Mostrar Estudio

Opción Petición DE

Datos DE

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name


dfd00007.dfd

Modulo Estudiar

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

80

Analizar op.

Sub-proceso que analiza la opción de aprendizaje elegida por el

usuario y prepara la correspondiente petición para extraer los datos

adecuados de la base de datos de la plataforma para posteriormente

mostrarlos al usuario.

Generar ficha estudio.

Sub-proceso que una vez recibidos los datos filtrados mediante la

petición del subproceso 3.2 a la base de datos, adecua los datos,

ordenándolos, maquetando y genera las oportunas fichas de

aprendizaje para mostrárselas al usuario.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

81

5.3.6. NIVEL 3: EXPLOSIÓN DEL PROCESO «GENERAR NŌKEN N5»:

Se procede a mostrar la figura correspondiente al nivel 3 o segundo nivel de

explosión del proceso 2.2, o también denominado proceso «Generar Nōken N5», para

entrar más en detalle en su funcionamiento.

Figura 14 – Nivel 3: Explosión del proceso Generar Nōken N5

Como se puede apreciar en la figura anterior, el proceso 2.2 lo forman dos sub-

procesos y un almacén. A continuación se detallarán ambos sub-procesos, indicando

sus funcionalidades.

Iniciar gen. Tipo N5.

Una vez se define que el usuario desea realizar un examen tipo N, es

decir, un examen modelo Nōken N5, este sub-proceso se encarga de

realizar la correspondiente petición a la base de datos para poder

extraer las preguntas correctas para su posterior presentación al

usuario.

2.2.1

Inciar

Gen.

Tipo N5

BD Preguntas

Modelos ExamenN

2.2.2

Organizar

Examen

N5Tipo N Ex. N Generado

Petición de

Preguntas Preguntas

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name


dfd00009.dfd

Generar Noken N5

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

82

Organizar examen N5.

El sub-proceso 2.2.2, recibe el resultado de la petición a la base de

datos de la plataforma con las correspondientes preguntas. Su

principal función es la de organizar dichas preguntas, maquetándolas

con los componentes necesarios para que el usuario pueda rellenar el

examen y así poder evaluarlo posteriormente.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

83

5.3.7. NIVEL 3: EXPLOSIÓN DEL PROCESO «GENERAR KANKEN 10»:

Se procede a mostrar la figura correspondiente al nivel 3 o segundo nivel de

explosión del proceso 2.3, o también denominado proceso «Generar Kanken 10», para

entrar más en detalle en su funcionamiento.

Figura 15 – Nivel 3: Explosión del proceso Generar Kanken 10

En la figura anterior, se pueden distinguir dos sub-procesos y un almacén que

forman el proceso 2.3. A continuación se detallarán ambos sub-procesos, indicando sus

funcionalidades.

Iniciar gen. Tipo K10.

Una vez se define que el usuario desea realizar un examen tipo K, es

decir, un examen modelo Kanken 10, este sub-proceso se encarga de

realizar la correspondiente petición a la base de datos para poder

extraer las preguntas correctas para su posterior presentación al

usuario.

2.3.1

Inciar

Gen.

Tipo K10

2.3.2

Organizar

Examen

K10

BD Preguntas

Modelos ExamenK

Tipo K Ex. K Generado

Petición de

PreguntasK10

PreguntasK10

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modif ied On:

Modif ied By:

New Project Name


dfd00010.dfd

Generar Kanken 10

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

84

Organizar examen K10.

El sub-proceso 2.3.2, recibe el resultado de la petición a la base de

datos de la plataforma con las correspondientes preguntas. Su

principal función es la de organizar dichas preguntas, maquetándolas

con los componentes necesarios para que el usuario pueda rellenar el

examen y así poder evaluarlo posteriormente.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

85

5.3.8. NIVEL 3: EXPLOSIÓN DEL PROCESO «CONTROL DE EXAMEN»:

Para concluir este modelo lógico de datos o DFD, se ha considerado necesario la

explosión del proceso 2.4, también denominado «Control de examen», que es el proceso

encargado de analizar los datos recibidos del usuario en respuesta a algún tipo de

examen propuesto, analizarlos, y proceder con la descomposición precisa de los datos a

su correspondiente evaluación con el OCR o el sistema evaluador de la plataforma,

para finalmente, poder mostrarle al usuario las calificaciones obtenidas.

Figura 16 – Nivel 3: Explosión del proceso Control de examen

2.4.1

Iniciar

Control

2.4.2

Esperar

Respuestas

2.4.3

Dividir

Respuestas

BD Respuestas

Examen

2.4.4

Comparar

Resultados

2.4.5

Generar

Gráf ico

Resultados

2.4.6

OCR

Kanjis

Ex. Generado Datos Examen

Mostrar

Resultados

Ex.

Mostrar Examen

Gen.

FDC1

FDC2

Petición

Respuestas

Respuestas

Examen

FD3

Resultados

Info. Escritura

FD4

Project Name:

Project Path:

Chart File:

Chart Name:

Created On:

Created By:

Modified On:

Modified By:

New Project Name


dfd00008.dfd

Controlar Examen

May-03-2012

STIC

May-03-2012

STIC



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

86

En la figura anterior, se pueden diferenciar seis sub-procesos y un almacén que

forman el proceso 2.4. A continuación se realiza una breve descripción de los sub-

procesos involucrados en este nivel de explosión.

Iniciar control.

Sub-proceso que, recibido el flujo de datos con el examen generado,

se lo presenta al usuario de una forma adecuada. Una vez presentado

el examen al usuario, envía un flujo al sub-proceso 2.3.2, indicando a

la plataforma que permanezca a la espera de las respuestas del usuario.

Esperar respuestas.

Sub-proceso que permanece a la espera de recibir las respuestas del

examen presentado al usuario. Cuando recibe las respuestas del

examen, mediante el flujo denominado «Datos examen», este sub-

proceso le indica al sub-proceso 2.4.3 que puede empezar el filtrado

de los datos.

Dividir respuestas.

Sub-proceso encargado de realizar un filtrado de las respuestas del

usuario al examen expuesto. Principalmente, separa las respuestas

que están destinadas a un posterior tratamiento con el OCR de la

plataforma. Cuando tiene todas las respuestas divididas, envía las de

escritura u OCR, al sub-proceso 2.4.6, y el resto de respuestas al sub-

proceso 2.4.4. Igualmente, realiza la correspondiente petición de

soluciones al examen propuesto a la base de datos de la plataforma.

OCR kanjis.

Sub-proceso que analiza las respuestas de escritura a mano alzada del

usuario para su posterior tratamiento en el sub-proceso 2.4.4.

Comparar resultados

Sub-proceso que recibe tres flujos de datos de la plataforma, el

resultante de la petición de soluciones a la base de datos por parte del



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

87

sub-proceso 2.4.3, y las respuestas tratadas por los sub-procesos 2.4.3

y 2.4.6. Una vez comparadas las respuestas del usuario con las

soluciones del examen, calcula los resultados obtenidos y se los envía

al sub-proceso 2.4.5.

Generar gráfico resultados.

Sub-proceso que recibe los resultados del examen de forma numérica

y se encarga de generar el gráfico de dichos resultados. Genera el

gráfico según los tipos de preguntas del examen, y realiza un gráfico

adecuado a dichos tipos de preguntas.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

88

5.4. DICCIONARIO DE DATOS

En este punto, se describen todos los flujos de datos que intervienen en la

plataforma, y que han quedado reflejados en el modelo lógico de datos presentado

anteriormente. Para ello, todos los flujos de datos quedan expresados en la siguiente

tabla con su correspondiente descripción y el tipo de flujo que es.

Nombre del flujo Descripción Tipo de flujo

Iniciar APP El “dispositivo de usuario” establece la

conexión con la plataforma.

Entrada

Solicitar Ident./Reg. La plataforma, una vez la conexión está

establecida con el “dispositivo de usuario”,

le requiere a este que proceda a realizar

una de las dos acciones posibles:

Identificarse como usuario

registrado.

Registrarse para poder utilizar la

plataforma.

Salida

Datos Ident./Reg. El “dispositivo de usuario” envía a la

plataforma los datos correspondientes a

una de las dos opciones posibles en un

primer momento.

Entrada

Ident./Reg. OK/Error La plataforma responde al usuario un

mensaje de OK o error, según resulte la

función elegida por el usuario. Este flujo

es un mensaje que le comunica al usuario

si todo ha resultado según lo previsto o ha

ocurrido algún error.

Salida

Solicitar Acción La plataforma le muestra al usuario las

actividades que puede realizar.

Estudiar.

Salida



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

89

Realizar examen.

Ver progreso/avances.

Salir.

Solicitar Baja.

Realizar Examen Respuesta del usuario al sistema a la

petición de “solicitar acción”, eligiendo la

opción de “realizar examen”.

Con esta acción, el usuario le está

indicando a la plataforma que desea

realizar una prueba de examen.

Entrada

Ver Progreso Respuesta del usuario al sistema a la


opción de “ver progreso”.


indicando a la plataforma que desea

revisar sus anteriores resultados en las

pruebas realizadas.

Entrada

Estudiar Respuesta del usuario al sistema a la


opción de “estudiar”.

Entrada

Salir Respuesta del usuario al sistema a la


opción de “salir”.

Con esta acción, el usuario se está “des-

loguando” de la plataforma.

Entrada

Solicitar Baja Respuesta del usuario al sistema a la


opción de “solicitar baja”.


indicando a la plataforma que desea dejar

Entrada



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

90

de pertenecer a ella.

Elegir Tipo La plataforma le ofrece al usuario dos

posibilidades de examen una vez que este,

le solicita la acción de “realizar examen”.

Se le ofrecen dos tipos:

Kanken 10.

Nōken N5.

Salida

Elección Tipo El usuario le indica a la plataforma el tipo

de examen que desea realizar.

Entrada

Mostrar Examen Gen. Una vez generado el examen, este flujo se

lo devuelve al “dispositivo usuario”.

Salida

Datos Examen La plataforma recibe los datos con las

soluciones rellenadas por el usuario sobre

un examen propuesto.

Entrada

Mostrar Resultados Ex. La plataforma le devuelve al usuario los

resultados que ha obtenido de la prueba de

examen realizada.

Salida

Mostrar Progreso La plataforma le muestra al usuario los

resultados de pruebas realizadas con

anterioridad.

Salida

Mostrar Op. Estudio La plataforma le da a elegir al usuario las

opciones disponibles de “modo de estudio”.

Salida

Op. Estudio El usuario le envía a la plataforma la

opción de estudio elegida.

Entrada

Mostrar Estudio La plataforma muestra el contenido

referente a la opción de estudio

seleccionada por el usuario.

Salida

Estado Baja La plataforma le informa al usuario del

estado actual de su solicitud de baja, tanto

Salida



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

91

si se ha realizado, está en proceso, o han

ocurrido problemas.

Realizar Ex. OK Una vez el proceso “Módulo Gestor”

recibe la orden de realizar examen por

parte del usuario, este proceso le da paso

al proceso “Módulo Examinador” para

empezar a realizar el examen.

Interno

Estudiar OK Una vez el proceso “Módulo Gestor”

recibe la orden de aprendizaje por parte

del usuario, este proceso le da paso al

proceso “Módulo Examinador” para

comenzar con sus correspondientes

funciones.

Interno

Tipo N El proceso 2.1 le comunica al proceso 2.2

que puede comenzar a generar un examen

tipo N, es decir, un examen de la

modalidad Nōken N5.

Interno

Tipo K El proceso 2.1 le comunica al proceso 2.3

que puede comenzar a generar un examen

tipo N, es decir, un examen de la

modalidad Kanken 10.

Interno

Ex. N Generado El proceso 2.2 envía la información

necesaria con el examen tipo N generado.

Interno

Ex. K Generado El proceso 2.3 envía la información

necesaria con el examen tipo N generado.

Interno

Ex. Generado Flujo que inicia el proceso 2.4. Contiene la

información relativa al examen generado

previamente.

Interno

Registro Flujo que inicia el proceso 1.2, es decir,

inicia el proceso de registro en la

plataforma de un usuario nuevo.

Interno



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

92

Identificación Flujo que inicia el proceso 1.3, es decir,

inicia el proceso de identificación en la

plataforma de un usuario existente.

Interno

Inscribir Us. Flujo que envía el proceso 1.2 una vez ha

tratado los datos para realizar el alta del

usuario en la base de datos de la

plataforma.

Interno

Petición Us. Flujo que envía el proceso 1.3 una vez ha

tratado los datos para realizar la

validación del usuario, extrayendo los

datos de la base de datos de la plataforma.

Interno

FG1 Flujo de datos generado con las peticiones

correspondientes a la base de datos de

usuarios de la plataforma.

Interno

Proc. OK Una vez que el proceso 1.4 Interno

Op. Baja OK Cuando el proceso 1.5 recibe la opción de

“darse de baja” de un usuario, este proceso

envía el flujo identificado como “Op. Baja

OK” al proceso 1.6.

Interno

Op. Estudiar OK Cuando el proceso 1.5 recibe la opción de

“realizar aprendizaje” de un usuario, este

proceso envía el flujo identificado como

“Op. Estudiar OK” al proceso 1.8.

Interno

Op. Examen OK Cuando el proceso 1.5 recibe la opción de

“realizar examen” de un usuario, este

proceso envía el flujo identificado como

“Op. Examen OK” al proceso 1.8.

Interno

Op. Progreso OK Cuando el proceso 1.5 recibe la opción de

“ver progreso” de un usuario, este proceso

envía el flujo identificado como “Op.

Interno



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

93

Progreso OK” al proceso 1.7.

Petición Baja El proceso 1.6 envía una petición de datos

a la base de datos de usuarios de la

plataforma para llevar a cabo la tarea de

“dar de baja” a un usuario.

Interno

Estado Baja Flujo de datos con el estado de la petición

de baja de un usuario. En definitiva, es un

mensaje de error en el caso de que se

produjese algún error en el proceso de

baja del usuario en la base de datos o un

mensaje de confirmación de dicha baja.

Interno

Petición de Progresos El proceso 1.7 le envía una petición de

datos a la base de datos de progreso de los

usuarios de la plataforma.

Interno

Datos Progreso Respuesta que recibe el proceso 1.9 sobre

la petición de datos de progreso realizada

por el proceso 1.7

Interno

Opción Flujo de datos con la opción de

aprendizaje seleccionada por el usuario.

Interno

Petición DE Petición de datos por parte del proceso 3.2

a la base de datos de kanjis de la

plataforma con las opciones prefijadas por

el usuario.

Interno

Datos DE Respuesta con los datos filtrados de la

base de datos de kanjis de la plataforma

que recibe el proceso 3.3.

Interno

FDC1 Flujo que envía el proceso 2.4.1 al proceso

2.4.2, indicándole que el examen generado

ha sido expuesto al usuario y la plataforma

está a la espera de las respuestas del

usuario.

Interno



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

94

FDC2 Flujo que envía el proceso 2.4.2 una vez

recibe los datos de respuestas al examen

expuesto al usuario, para proceder con su

análisis con el proceso 2.4.3.

Interno

Info. Escritura Flujo que envía el proceso 2.4.3 al proceso

2.4.6, con las respuestas de escritura que

necesiten ser analizadas por el OCR de la

plataforma.

Interno

FD3 Flujo que envía el proceso 2.4.3 al proceso

2.4.4 con las respuestas que no precisen

del OCR de la plataforma para su

tratamiento.

Interno

FD4 Flujo que envía el proceso 2.4.6 al proceso

2.4.4 con las respuestas de escritura

tratadas por el OCR de la plataforma.

Interno

Petición Respuestas Petición de datos a la base de datos de

respuestas de examen de la plataforma por

parte del proceso 2.4.3.

Interno

Respuestas Examen Flujo con las respuestas de examen

extraídas y filtradas de la base de datos de

la plataforma para comenzar su

tratamiento en el proceso 2.4.6.

Interno

Resultados Flujo de datos con los porcentajes

obtenidos en el proceso 2.4.4 una vez

evaluado respuestas de examen

introducidas por el usuario y comparadas

con las respuestas oficiales. Este flujo lo

recibe el proceso 2.4.5.

Interno

Petición de Preguntas Petición del proceso 2.2.1 a la base de

datos de preguntas de examen

correspondientes al examen tipo N5 de la

Interno



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

95

plataforma.

Preguntas Flujo de datos con las respuestas extraídas

de la base de datos correspondiente de la

plataforma que recibe el proceso 2.2.2.

Interno

Petición de PreguntasK10 Petición del proceso 2.3.1 a la base de

datos de preguntas de examen

correspondientes al examen tipo K10 de la

plataforma.

Interno

PreguntasK10 Flujo de datos con las respuestas extraídas

de la base de datos correspondiente de la

plataforma que recibe el proceso 2.3.2.

Interno

Tabla 6 – Diccionario de datos del sistema JSKanken



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

96

5.5. DISEÑO DE LA BASE DE DATOS

En este punto se procede a mostrar las tablas contenidas en la base de datos de la

plataforma. En cada tabla se indicará los siguientes campos:

Campo: Nombre de los campos de la tabla correspondiente.

Tipo: tipo de dato almacenado para un campo.

Descripción: una breve explicación de cada campo de la tabla.

En total, la base de datos de la plataforma se compone de las siguientes tablas:

TBL_USREG

TBL_KANJIS

TBL_LECTURAS

TBL_EJEMPLOS

TBL_EXK10

TBL_PEK10

TBL_EXN5

TBL_PEN5

En el diseño de estas tablas se ha evitado en mayor medida posible las

redundancias que pudiesen existir.

Figura 17 – Relaciones de las tablas de la Base de Datos

En el conjunto de las tablas existen las referentes a los dos tipos de exámenes

que trata la plataforma (K10 y N5). Se ha decidido mantener tablas separadas para cada

examen para lograr un mejor mantenimiento y gestión de ambos exámenes. De esta



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

97

forma, además de lo comentado anteriormente, se consiguen tener estudios estadísticos

por separado de los alumnos en ambos exámenes.

A continuación se exponen las fichas de las tablas:

TABLA TBL_USREG

CAMPO TIPO DESCRIPCIÓN

ID INT(11) Identificador asignado al usuario. Cada usuario posee un

identificador numérico auto-incremental y único.

CE VARCHAR(50) Correo electrónico del usuario. Es el “nombre de usuario” con

el que se identificarán los usuarios al entrar en la plataforma.

Deberá tener la estructura de correo electrónico. No podrán

existir dos usuarios con el mismo correo electrónico.

PW VARCHAR(50) Contraseña del usuario para validarse en la plataforma. Esta

tendrá una longitud mínima de seis caracteres y se codificará

con MD5 para mantener las contraseñas de los usuarios

cifradas en caso de intrusión no deseada en la base de datos.

NO VARCHAR(50) Nombre del usuario registrado. Este campo se utilizará

principalmente para hacer una plataforma más amigable y

para referirse al propio usuario.

AP VARCHAR(50) Apellido del usuario registrado. Este campo se utilizará

principalmente para hacer una plataforma más amigable y

para referirse al propio usuario.

IP VARCHAR(50) Imagen de perfil del usuario. Se le asignará una por defecto

hasta que el propio usuario la modifique. Sirve para dar un

toque más personal a la página privada del propio usuario.

Tabla 7 – Tabla TBL_USREG



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

98

TABLA TBL_KANJIS


IDKANJI INT(11) Identificador asignado a cada kanji. Cada kanji posee

un identificador numérico auto-incremental y único.

IDEOGRAMA VARCHAR(20) Ideograma del kanji.

NTRAZ INT(11) Numero de trazos del kanji.

SIGN VARCHAR(45) Significado del kanji.

NIVK VARCHAR(5) Nivel de examen Kanken al que pertenece el kanji.

NIVN VARCHAR(2) Nivel de examen Nōken al que pertenece el kanji.

BUSQ INT(11) Número de veces que ha sido buscado el kanji. Este

campo sirve principalmente para realizar

estadísticas de aprendizaje.

Tabla 8 – Tabla TBL_KANJIS



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

99

TABLA TBL_LECTURAS




Este campo sirve generalmente para identificar el

kanji en la TBL_KANJIS.

IDLECT INT(11) Identificador asignado a cada lectura almacenada en

la tabla TBL_LECTURAS de la base de datos. Cada

lectura posee un identificador numérico auto-

incremental y único.

TIPOLECT VARCHAR(1) Tipo de lectura, es decir, O de lectura On-yomi, o K

de lectura Kun-yomi. Estos tipos de lectura han sido

explicados con anterioridad en este documento.

LECTJAP VARCHAR(20) Lectura japonesa del kanji. Esta lectura estará en

katakana o hiragana según le corresponda.

LECTROM VARCHAR(20) Lectura romaji del kanji. Este campo sirve

principalmente para que un usuario recién iniciado

sea capaz de utilizar la plataforma.

Tabla 9 – Tabla TBL_LECTURAS



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

100

TABLA TBL_EJEMPLOS




Este campo sirve generalmente para identificar el

kanji en la TBL_KANJIS.

IDEJEM INT(11) Identificador asignado a cada ejemplo almacenada

en la tabla TBL_EJEMPLOS de la base de datos.

Cada ejemplo posee un identificador numérico auto-


EJJAP VARCHAR(100) Lectura del ejemplo en alfabeto japonés, es decir, en

kanji, hiragana, una mezcla de los dos anteriores, o

katakana.

EJROM VARCHAR(100) Lectura del ejemplo en romaji.

EJESP VARCHAR(100) Significado del ejemplo en español. Esto servirá para

poder entender mejor los ejemplos.

Tabla 10 – Tabla TBL_EJEMPLOS



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

101

TABLA TBL_EXK10


IDEK10 INT(11) Identificador asignado a cada examen kanken 10.

Cada examen posee un identificador numérico auto-


TIEK10 INT(11) Indica el tipo de ejercicio. Este número varía de 1 a

7 para el kanken 10. Servirá para identificar los

ejercicios para su posterior corrección.

EJEK10 VARCHAR(100) Este campo contiene diferentes ejercicios del

examen kanken 10. Generalmente estarán escritos en

lengua japonesa, pero dependerá del tipo de

ejercicio.

SOLEK10 VARCHAR(30) Solución correcta del ejercicio del campo EJEK10.

Se utilizará para su posterior corrección. Cada

ejercicio puede tener varias soluciones, todas ellas

almacenadas en este campo.

NSOLEK10 INT(11) El número de soluciones que tiene el ejercicio

propuesto. Coincide con el número de soluciones del

campo anterior. Sirve de control.

Tabla 11 – Tabla TBL_EXK10



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

102

TABLA TBL_PEK10


ID INT(11) Campo que indica el identificador del usuario a la

que pertenece el resultado. Cada usuario posee un

identificador numérico único.

IDPE INT(11) Identificador numérico de la prueba de examen. Este

campo es numérico, único y auto-incremental.

PEFE DATETIME Fecha en la que se realizo la prueba. Esta fecha se

almacena con el formato largo, es decir:

YYYY-MM-DD HH:MM:SS

PEV1 INT(11) Resultado de las preguntas referentes al ejercicio 1.

Este campo servirá para el posterior tratamiento de

los resultados.



los resultados.



los resultados.



los resultados.



los resultados.



los resultados.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

103



los resultados.



los resultados.



los resultados.

PERES INT(11) Calificación global obtenida por el usuario en la

prueba de examen realizada.

Tabla 12 – Tabla TBL_PEK10



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

104

TABLA TBL_EXN5


IDEN5 INT(11) Identificador asignado a cada examen nōken 5. Cada

examen posee un identificador numérico auto-


TIEN5 INT(11) Indica el tipo de ejercicio. Este número varía de 1 a

3 para el nōken 5. Servirá para identificar los

ejercicios para su posterior corrección.

EJEN5 VARCHAR(100) Este campo contiene diferentes ejercicios del

examen nōken 5. Generalmente estarán escritos en

lengua japonesa, pero dependerá del tipo de

ejercicio.

SOLEN5 VARCHAR(30) Solución correcta del ejercicio del campo EJEN5. Se

utilizará para su posterior corrección. Cada ejercicio

puede tener varias soluciones, todas ellas

almacenadas en este campo.

Tabla 13 – Tabla TBL_EXN5



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

105

TABLA TBL_PEN5


ID INT(11) Campo que indica el identificador del usuario a la

que pertenece el resultado. Cada usuario posee un

identificador numérico único.

IDPEN INT(11) Identificador numérico de la prueba de examen. Este

campo es numérico, único y auto-incremental.

PEFEN DATETIME Fecha en la que se realizo la prueba. Esta fecha se

almacena con el formato largo, es decir:

YYYY-MM-DD HH:MM:SS

PEV1N INT(11) Resultado de las preguntas referentes al ejercicio 1.


los resultados.



los resultados.



los resultados.

PERESN INT(11) Calificación global obtenida por el usuario en la

prueba de examen realizada.

Tabla 14 – Tabla TBL_PEN5



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

106

5.6. DISEÑO DEL OCR DE LA PLATAFORMA

En este punto del documento se procede a realizar una explicación del diseño del

OCR de la plataforma. No se detallarán aspectos, ni tipos de OCR. Lo necesario que

hay que saber de los OCR está expuesto en puntos anteriores del documento.

Para comenzar, tiene que quedar claro, que la plataforma debe servir para que los

usuarios de la misma aprendan de una forma correcta y adecuada, la escritura japonesa.

Por ello, uno de los aspectos importantes a tener en cuenta es el orden de trazos y el

sentido de los mismos.

Estas dos características son muy importantes en los exámenes de escritura del

idioma japonés, hasta el punto de considerarse un arte.

En la figura de arriba se expone la representación de uno de los ideogramas

japoneses que contiene la plataforma, y a su derecha una leyenda con el número de

trazo y su color correspondiente.

El diseño del OCR de la plataforma se ha llevado a cabo de una forma en

particular para realizar una comprobación exhaustiva de la escritura de los kanjis, en

Trazo 1

Trazo 2

Trazo 3

Trazo 4

Trazo 5

Figura 18 – Análisis de un kanji por el OCR



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

107

gran parte, debido a evitar posibles errores, tanto en el aprendizaje del usuario, como

en el tratamiento de los kanjis por parte de la plataforma. A continuación se muestran

algunas parejas de kanjis que podrían confundirse con un OCR:

右石

九力

Figura 19 – Ejemplo de similitudes en kanjis

Por ello, uno de los factores importantes es el sentido de los trazos, además se ha

determinado, el análisis de la pendiente de los trazos como una característica

importante del OCR.

Para recoger el dibujo a mano alzada introducido por el usuario en la

plataforma, se ha decidido emplear el canvas de HTML5, debido a su alta

compatibilidad con dispositivos móviles como tablets. El OCR recibirá la imagen del

mismo, y además un parámetro de control que contendrá todos los trazos del dibujo

con la siguiente estructura:


Las variables de la estructura anterior son:

o XI: Punto del eje de abscisas o eje X, inicial.

o YI: Punto del eje de ordenadas o eje Y, inicial.

o XF: Punto del eje de abscisas o eje X, final.

o YF: Punto del eje de ordenadas o eje Y, final.

o FF: Frecuencia de puntos que contiene el trazo, es decir, depende de la

longitud del trazo y la rapidez de escritura.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

108

A continuación se va a mostrar un ejemplo del funcionamiento del OCR:

a) El usuario introduce el dibujo del kanji en la plataforma, dentro del área

de dibujo.

Figura 20 – Ejemplo de dibujo a mano alzada

b) Una vez dibujado, el usuario pulsa en el botón de “control”.

c) El OCR comienza el análisis del dibujo y todas las variables

anteriormente comentadas, así como las nuevas variables formadas a

partir de estas.

d) Conforme se va analizando el kanji y sus partes, se acota la búsqueda del

kanji deseado. En este caso, la plataforma aísla dos kanjis en concreto:

九 95%

力 80%



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

109

e) Una vez aislados, como resultado final, se muestra aquel que haya logrado

mayor índice porcentual del análisis del dibujo a mano alzada.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

110

5.7. DISEÑO DEL GENERADOR DE EXÁMENES DE LA PLATAFORMA

En este punto se procede a comentar de una forma breve y concisa, la forma que

tiene la plataforma de generar los exámenes para evaluar al usuario de los

conocimientos de la lengua.

a) El primer paso que realiza el generador de exámenes, es hacer las

peticiones que precise a la base de datos para formar un modelo de

examen.

b) Una vez extraídos los datos de la base de datos, el generador de exámenes

comienza a analizarlos y a separar las lecturas de los kanjis de las

preguntas para empezar a formar los ejercicios del examen. Un ejemplo

de una parte de datos extraídos es el siguiente:

|くさ|むらでてんとう |むし|を |ご| ひきみつけた。

Los ideogramas encerrados entre “|” se corresponden con las lecturas de

los kanjis que el usuario debe escribir.

c) Cuando se hayan separado las lecturas de la pregunta, el generador de

exámenes procede a montar la pregunta:

d) En cada cuadro amarillo, el usuario deberá introducir el kanji

correspondiente. Para ver cómo funciona la plataforma se recomienda ver

el manual de usuario incluido en esta memoria.

Este es el funcionamiento de cómo se generan las preguntas 1, 5, 6 y 7 con

alguna variación de estilos. El resto de preguntas se consideran una generación básica

por lo que no se detallará su montaje.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

111

5.8. DISEÑO DEL LOGO DE LA PLATAFORMA

En este punto del documento se procede a explicar los conceptos necesarios para

llevar a cabo el diseño del logo, y el diseño final elegido del mismo.

5.8.1. ¿QUÉ ES UN LOGO?

Un logo es una imagen constituida por icono y tipografía, que tiene la función

principal de representar a una compañía o entidad, es decir, el logotipo es a la empresa

lo que la firma al empresario: un sello de garantía.

5.8.2. TIPOS DE LOGOS

Por su composición morfológica, el logo se divide en tres tipos:

Logotipo. Tipo de logo que carece de icono y se constituye

exclusivamente de tipografía.

Isotipo. Tipo de logo que se basa exclusivamente en icono y carece de

tipografía.

Isologotipo. Tipo de logo que combina al logotipo y al isotipo.

5.8.3. MODELO DE COLOR A EMPLEAR

Modelo CMYK. Este modelo de color define los colores con estas componentes:

Cian (C).

Magenta (M).

Amarillo (Y).

Negro (K).

Los componentes cian, magenta, amarillo

y negro son las cantidades de tinta de estos

colores que contiene un color CMYK y se

miden en porcentajes de 0 a 100.

El modelo de color CMYK es un modelo

sustractivo. Estos modelos emplean la luz reflejada para mostrar los colores.

Figura 21 – Modelo de color CMYK



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

112

Tiene una desventaja, y es que la mezcla de pigmentos cian, magenta y amarillo

no produce el color blanco, sino un color gris sucio, neutro. En cuanto al negro,

tampoco es posible obtenerlo a partir de los primarios, obteniéndose el modelo CMYK.

El sistema CMYK, define los colores de forma similar a como funciona una

impresora de inyección de tinta o una impresora comercial cuatricromía. El color

resulta de la superposición o de colocar juntas, gotas de tinta semitransparente, de los

colores cian, magenta, amarillo y negro.

Los colores generados con este modelo vienen expresados de la manera (C, M, Y,

K).

5.8.4. ELABORACIÓN DEL LOGO

El tipo de logo seleccionado para representar la plataforma es el logotipo, puesto

que lo que se busca principalmente es que los usuarios recuerden fácilmente el nombre

de la misma. Además como está reflejado en los requisitos, el modelo de color necesario

para su desarrollo debe ser el CMYK explicado anteriormente.

El logotipo final de la plataforma debe contener el nombre de la misma y algún

detalle que induzca al idioma japonés. A continuación se expone el diseño del logotipo

de la plataforma.

Figura 22 – Logo de la plataforma JSKanken

Como se puede observar en la figura superior, el logotipo se divide en las

siguientes partes:

Un primer elemento que indica que la plataforma es de, o para, idioma

japonés. Está representado el nombre de Japón en kanji (日本).



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

113

Un segundo elemento, que será con el que se queden los usuarios, que es

el nombre del dominio donde está alojada la plataforma,

JSKANKEN.COM.

Y por último, un tercer elemento, que es el slogan de la plataforma, el

cual pretende atraer al mayor número de usuarios.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

114



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

115

Capítulo 6

TECNOLOGÍAS

EMPLEADAS.



Cap

ítu

lo: D

iseñ

o d

e la

pla

tafo

rma

116



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

117

6. TECNOLOGÍAS EMPLEADAS

En este punto del documento se van a explicar las tecnologías empleadas para el

desarrollo de este proyecto.

Primero se mostrará una figura con la arquitectura que se ha mantenido para el

desarrollo de la plataforma:

Figura 23 – MVC de la plataforma

Como se puede ver, se ha desarrollado siguiendo la estructura de MVC (Modelo-

Vista-Controlador).

A partir de aquí, se va a proceder a realizar una breve descripción de las

siguientes herramientas/tecnologías:

Suite de Office de Microsoft 2010.

o Microsoft Word.

o Microsoft Project.

o Microsoft PowerPoint.

o Microsoft Excel.

Adobe Photoshop CS5.1.

Modelo

MySQL

OCR

Examinador

•Examinador K

•Examinador N

Vista

Presentación

•Identificación

•Perfil

•Buscador

•Examen

•Resultados

Controlador

Gestor



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

118

Netbeans 7.1.

MySQL 5.5.

PHP 6.

Zend Framework.

JpGraph.

JQuery.

JavaScript.

HTML5.

CSS.

XAMPP.

o Apache.

6.1. MS OFFICE 2010

Microsoft Office 2010 es la última versión comercial a día de hoy que existe de la

suite ofimática de Microsoft Office de Microsoft, y sucesora de Microsoft Office 2007.

Se trata de un conjunto de programas informáticos que realizan tareas ofimáticas, es

decir, que permiten automatizar y optimizar las actividades de una empresa.

Entre las distintas funcionalidades de la suite, para este desarrollo se han

utilizado las siguientes:

Word, es uno de los programas más populares que forman parte de

Microsoft Office. Consiste en un procesador de textos que incluye un

corrector ortográfico, diccionario de sinónimos y la posibilidad de trabajar

con diversas fuentes (tipografías).

Excel, por su parte, está compuesto por hojas o planillas de cálculo. Su

principal atractivo es la posibilidad de realizar cálculos aritméticos de

manera automática, lo que facilita el desarrollo de balances y estados

contables.

PowerPoint, es el programa de Office que se utiliza para crear y exhibir

presentaciones visuales. Su base está en el desarrollo de diapositivas

multimedia que pueden incluir texto, imágenes, videos y sonido.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

119

Project, es un software de administración de proyectos diseñado, para

asistir a administradores de proyectos en el desarrollo de planes,

asignación de recursos a tareas, dar seguimiento al progreso, administrar

presupuesto y analizar cargas de trabajo.

MS Office 2010 ha sido usado para el desarrollo del documento, la planificación,

el presupuesto, y la presentación final del proyecto.

6.2. ADOBE PHOTOSHOP CS5.1

Adobe Photoshop es una aplicación para la creación, edición y retoque de

imágenes. Es desarrollado por la compañía Adobe Systems.

Se ha utilizado para el diseño de las imágenes de los kanjis correspondientes a los

ejercicios 3 y 4 del examen kanken 10, así como el resto de imágenes que aparecen en

este documento.

Por otra parte, ha sido empleado también para el desarrollo del logotipo de la

plataforma, entre otras cosas, por tratarse de una de las mejores herramientas de

diseño gráfico existentes en el mercado, y por la alta calidad de las soluciones que

genera photoshop.

Hay que distinguir dos tipos de diseño:

Diseños en 300ppp (píxeles por pulgada). Estas imágenes son las

diseñadas para impresión.

Diseños en 72ppp (píxeles por pulgada). Estas imágenes son las

diseñadas para la web.

6.3. NETBEANS 7.1

NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para

el lenguaje de programación Java, pero también disponible para PHP. Existe además

un número importante de módulos para extenderlo. NetBeans IDE es un producto

libre y gratuito sin restricciones de uso.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

120

NetBeans es un proyecto de código abierto de gran éxito con una gran base de

usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo el

mundo. Sun MicroSystems fundó el proyecto de código abierto NetBeans en junio de

2000 y continúa siendo el patrocinador principal de los proyectos.

6.4. MYSQL 5.5

MySQL es la base de datos open source más popular y, posiblemente, mejor del

mundo. Su continuo desarrollo y su creciente popularidad está haciendo de MySQL un

competidor cada vez más directo de gigantes en la materia de las bases de datos como

Oracle.

MySQL es un sistema de administración de bases de datos (Database

Management System, DBMS) para bases de datos relacionales. Así, MySQL no es más

que una aplicación que permite gestionar archivos llamados de bases de datos.

Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas

relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza

múltiples tablas para almacenar y organizar la información.

MySQL fue escrito en C y C++ y destaca por su gran adaptación a diferentes

entornos de desarrollo, permitiendo su interactuación con los lenguajes de

programación más utilizados como PHP, Perl y Java y su integración en distintos

sistemas operativos.

También es muy destacable, la condición de open source de MySQL, que hace

que su utilización sea gratuita e incluso se pueda modificar con total libertad, pudiendo

descargar su código fuente. Esto ha favorecido muy positivamente en su desarrollo y

continuas actualizaciones, para hacer de MySQL una de las herramientas más

utilizadas por los programadores orientados a Internet.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

121

6.5. PHP 6

PHP (Hypertext Preprocessor) es un lenguaje de código abierto muy popular

especialmente adecuado para desarrollo web y que puede ser incrustado en HTML.

Lo que distingue a PHP de algo lado-cliente como Javascript, es que el código es

ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente recibirá

los resultados de ejecutar el script, sin ninguna posibilidad de determinar qué código

ha producido el resultado recibido. El servidor web puede ser incluso configurado para

que procese todos los archivos HTML con PHP y entonces no hay manera que los

usuarios puedan saber que tienes debajo de la manga.

En este lenguaje de programación se basa principalmente el desarrollo de la

plataforma JSKanken.

6.6. ZEND FRAMEWORK

Zend Framework (ZF) es un framework de código abierto para desarrollar

aplicaciones web y servicios web con PHP 5 o superior. ZF es una implementación que

usa código 100% orientado a objetos. La estructura de los componentes de ZF es algo

único; cada componente está construido con una baja dependencia de otros

componentes. Esta arquitectura débilmente acoplada permite a los desarrolladores

utilizar los componentes por separado. A menudo se refiere a este tipo de diseño como

"use-at-will" (uso a voluntad).

6.7. JPGRAPH

JpGraph es una librería de clases orientadas a objetos para PHP, para la creación

dinámica de imágenes. Con JpGraph se pueden crear gráficas complejas con un

mínimo de código y con un control muy detallado. Con el único requerimiento de que

se tenga instalado el soporte para la librería GD Graphics library.

Esta librería se ha empleado para el desarrollo de los gráficos radiales que sirven

para mostrar de una forma gráfica los resultados obtenidos en los exámenes a los

usuarios.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

122

6.8. JQUERY

JQuery es una biblioteca de JavaScript, creada inicialmente por John Resig, que

permite simplificar la manera de interactuar con los documentos HTML, manipular el

árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la

técnica AJAX a páginas web. Fue presentada el 14 de enero de 2006 en el BarCamp

NYC.

JQuery es software libre y de código abierto, posee un doble licenciamiento bajo

la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso en

proyectos libres y privativos.1 jQuery, al igual que otras bibliotecas, ofrece una serie de

funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más

código, es decir, con las funciones propias de esta biblioteca se logran grandes

resultados en menos tiempo y espacio.

6.9. JAVASCRIPT

JavaScript es un lenguaje de programación interpretado, dialecto del estándar

ECMAScript. Se define como orientado a objetos,3 basado en prototipos, imperativo,

débilmente tipado y dinámico.

Se utiliza principalmente en su forma del lado del cliente (client-side),

implementado como parte de un navegador web permitiendo mejoras en la interfaz de

usuario y páginas web dinámicas, en bases de datos locales al navegador...4 aunque

existe una forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS). Su

uso en aplicaciones externas a la web, por ejemplo en documentos PDF, aplicaciones de

escritorio (mayoritariamente widgets) es también significativo.

6.10. HTML5

HTML5 (HyperText Markup Language, versión 5) es la quinta revisión

importante del lenguaje básico de la World Wide Web, HTML. HTML5 especifica dos

variantes de sintaxis para HTML: un «clásico» HTML (text/html), la variante

conocida como HTML5 y una variante XHTML conocida como sintaxis XHTML5



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

123

que deberá ser servida como XML (XHTML) (application/xhtml+xml). Esta es la

primera vez que HTML y XHTML se han desarrollado en paralelo.

Todavía se encuentra en modo experimental, lo cual indica la misma W3C;

aunque ya es usado por múltiples desarrolladores web por sus avances, mejoras y

ventajas.

Se decidió emplear este lenguaje de programación en plena expansión debido a su

compatibilidad y sus múltiples etiquetas que sirven de utilidad para la plataforma como

el elemento canvas.

6.11. CSS

CSS (Cascading Style Sheets) es la tecnología desarrollada por el World Wide

Web Consortium (W3C) con el fin de separar la estructura de la presentación.

6.12. XAMPP

XAMPP es un servidor independiente de plataforma, software libre, que consiste

principalmente en la base de datos MySQL, el servidor web Apache y los intérpretes

para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para

cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl.

El programa está liberado bajo la licencia GNU y actúa como un servidor web

libre, fácil de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está

disponible para Microsoft Windows, GNU/Linux, Solaris y MacOS X.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

124



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

125

Capítulo 7

MANUAL DE USUARIO.



Cap

ítu

lo: T

ecn

olo

gía

s em

ple

adas

126



Cap

ítu

lo: M

anu

al d

e u

suar

io

127

7. MANUAL DE USUARIO

El manual de usuario es un documento técnico de un determinado sistema que

intenta dar asistencia a sus usuarios. En este caso el siguiente manual de usuario se

corresponde con el desarrollo del sistema del presente proyecto, JSKanken.

Los manuales de usuario generalmente son incluidos a dispositivos electrónicos,

hardware de computadora y aplicaciones. Puede venir tanto en forma de libro como en

forma de documento digital, e incluso poder ser consultado por internet.

En general, un manual de usuario debería poder ser entendido por cualquier

usuario principiante, como así también serle útil a usuarios avanzados.

Un manual de usuario completo suele tener:

Un prefacio con información sobre cómo usar el propio manual.

Un índice.

Una guía rápida sobre cómo usar las funciones principales del sistema.

Una sección para la resolución de problemas.

Una FAQ.

Información de contacto.

Un glosario.

Para el desarrollo de este manual de usuario, al estar integrado en la

documentación general del proyecto, no incluirá ni un prefacio, ni un índice como tal

para el manual de usuario de forma individual, sino que se integrará en el índice

general de la documentación del proyecto.



Cap

ítu

lo: M

anu

al d

e u

suar

io

128

7.1. INICIO DE LA PLATAFORMA

Para comenzar a usar la plataforma web de JSKanken, será necesario que el

usuario disponga de un computador con un navegador web actualizado. Para iniciar la

plataforma es necesario abrir la siguiente dirección web con el navegador:

http://www.jskanken.com

La anterior dirección, será la principal dirección de acceso a la plataforma.

Una vez abierta la dirección web se mostrará la siguiente página:

Figura 24 – Pantalla de inicio de la plataforma

Para poder proceder con el uso de la plataforma es necesario identificarse con

usuario registrado utilizando los campos de usuario y contraseña que se encuentran

en el recuadro de la derecha de la imagen superior.

En el caso de que aún no sea usuario registrado de la plataforma se puede

formalizar el registro pulsando en “Regístrate” y procediendo a rellenar los campos

que aparecen al pulsar:



Cap

ítu

lo: M

anu

al d

e u

suar

io

129

Nombre.

Apellidos.

Correo electrónico.

Contraseña.

Tanto el nombre como los apellidos simplemente serán usados para realizar un

trato amigable de la plataforma con el usuario, nunca serán utilizados para otros fines,

ni estadísticos ni de venta de datos.

A continuación se muestra la pantalla de registro descrita:

Figura 25 – Pantalla de registro de la plataforma



Cap

ítu

lo: M

anu

al d

e u

suar

io

130

7.2. FUNCIONALIDADES

Una vez identificado en la plataforma, el usuario podrá acceder a las diferentes

funcionalidades de la plataforma JSKanken.

7.2.1. PERFIL

La imagen de la derecha muestra la versión beta

del perfil de los usuarios. En este perfil contiene el

menú principal de la plataforma y la foto personal del

usuario.

Desde el menú se pueden realizar las siguientes

acciones:

Gestión de la cuenta. El usuario puede

modificar sus datos de acceso a la plataforma.

Cerrar sesión. El usuario se desconecta

de la plataforma. Elimina la sesión de la página activa.

Buscador de kanjis. Esta opción del

menú, se corresponde con la parte de aprendizaje de la

plataforma. Más adelante se detallará su uso.

Realizar prueba. En esta opción del menú, el usuario puede realizar

exámenes para evaluar sus conocimientos en el idioma japonés.

Resultados. El usuario puede ver los resultados obtenidos en las pruebas

realizadas y ver su progreso.

La imagen relativa al perfil de los usuarios mostrada arriba, se corresponde con

la imagen por defecto, pero cualquier usuario será libre de cambiarla como guste

siempre y cuando la imagen que desee subir el usuario tenga el formato y tamaño

adecuados.

Figura 26 – Perfil del usuario



Cap

ítu

lo: M

anu

al d

e u

suar

io

131

7.2.2. BUSCADOR DE KANJIS

Si el usuario pulsa la opción de “Buscador de kanjis” del menú general de la

plataforma mostrado anteriormente, accederá a la siguiente página:

Figura 27 – Buscador de kanjis de la plataforma

En esta parte de la plataforma, el usuario podrá acceder a información relevante

sobre el idioma japonés para poder realizar el aprendizaje que precise.

En definitiva es un diccionario de kanjis, en el que se pueden realizar búsquedas

por números de trazos, significados o ambos.



Cap

ítu

lo: M

anu

al d

e u

suar

io

132

A continuación se muestra un ejemplo de búsqueda con parámetro de filtrado de:

Número de trazos = 4

Figura 28 – Ejemplo de búsqueda de los kanjis con 4 trazos

Figura 29 – Información previa de un kanji

Cada kanji encontrado, después del filtrado que decida cada usuario, se mostrará

con la siguiente información como se muestra en la figura superior:

Ideograma.

Significado.

Numero de trazos.

Icono para ampliar información.



Cap

ítu

lo: M

anu

al d

e u

suar

io

133

Una vez realizada la búsqueda, los usuarios podrán seleccionar el kanji que

deseen para ampliar su información, para ello se utilizará el icono de:

Una vez pulsado el icono de información de uno de los kanji, aparece la siguiente

ficha con la información precisa.

Figura 30 – Información completa de un kanji

En este caso, esta ficha se corresponde con el kanji del número 10.

Como se puede observar en la ficha, se muestran todos los datos referentes al

kanjis como son:

Ideograma.

Significado.

Numero de trazos.

Nivel Kanken.

Nivel Noken.



Cap

ítu

lo: M

anu

al d

e u

suar

io

134

Lecturas.

Ejemplos.

En la pestaña de lecturas de la ficha, se diferencian los dos tipos de lecturas

existentes en el idioma mediante el símbolo correspondiente y un color.

Naranja si se corresponde con la lectura on-yomi.

Azul si se corresponde con la lectura kun-yomi.

Tanto en los ejemplos como en las lecturas de cada kanji, poseen su escritura en

japonés con la correspondiente transcripción del idioma en la parte superior.



Cap

ítu

lo: M

anu

al d

e u

suar

io

135

7.2.3. REALIZAR PRUEBA

Si el usuario selecciona la opción de “Realizar prueba”, se generará un examen

automáticamente para que el usuario proceda con su desarrollo. A continuación se

muestra un ejemplo de examen generado del modelo Kanken 10.

Figura 31 – Pregunta 1 de un examen tipo kanken 10




Cap

ítu

lo: M

anu

al d

e u

suar

io

136


Figura 34 – Preguntas 5 y 6 de un examen tipo kanken 10



Cap

ítu

lo: M

anu

al d

e u

suar

io

137


Como se observan en las figuras de arriba, los exámenes se componen de siete

preguntas, y cada una se responde de distinta forma. Las preguntas 1, 6 y 7, se

responden mediante la inserción de un kanji a través del panel de la plataforma

destinado para ello que se corresponde con la siguiente figura:

Figura 36 – Panel de escritura

La pregunta 2 se responde eligiendo la lectura que el usuario considere oportuna

entre dos posibilidades; la pregunta 3 y 4 se responden indicando con un valor

numérico el número de trazo de color azul.



Cap

ítu

lo: M

anu

al d

e u

suar

io

138

Figura 37 – Ejemplo de kanji (ejercicios 3 y 4)

Por último, en la pregunta número cinco, se debe escribir con escritura romaji, la

lectura que le corresponda al kanji seleccionado.

Para dar por finalizado el examen, se debe pulsar el botón amarillo del final de la

página:

Una vez se evalúe el examen realizado por el usuario, se le muestran a este los

resultados obtenidos en el mismo.

Los resultados se muestran en una tabla con las calificaciones obtenidas en cada

ejercicio del examen. Cada ejercicio tiene una puntuación diferente, y para lograr un

aprobado en el examen, el usuario debe lograr una puntuación total de 120 sobre 150,

al igual que en los exámenes oficiales del idioma.

Además de la puntuación de cada ejercicio, el usuario puede ver los resultados de

forma gráfica mediante un gráfico radial pulsando el botón de “ver gráfico”.



Cap

ítu

lo: M

anu

al d

e u

suar

io

139

Figura 38 – Pantalla con la evaluación de un examen de la plataforma

Cuando se pulse el botón de “ver gráfico”, se abre una ventana emergente con

dicho gráfico.

Figura 39 – Gráfico de ejemplo de los resultados de un examen



Cap

ítu

lo: M

anu

al d

e u

suar

io

140

7.2.4. RESULTADOS

Para finalizar con este manual de usuario, se procede a explicar el funcionamiento

de la plataforma, cuando el usuario pulsa en la opción de “resultados” de la web.

Figura 40 – Pantalla con los resultados de los exámenes realizados de la plataforma

Al pulsar sobre esta opción, el usuario puede ver los resultados de todos los

exámenes realizados con sus correspondientes puntuaciones, fechas de realización y

tipo de examen.

Los exámenes que el usuario haya pasado con éxito, se mostrarán en color verde

y los no pasados, en color rojo.

De igual forma el usuario podrá ver los resultados de forma gráfica de cualquiera

de los exámenes siempre que éste desee para ver sus progresos. Para acceder a esta

opción el usuario debe pulsar sobre el icono de información correspondiente a cada

resultado.



Cap

ítu

lo: M

anu

al d

e u

suar

io

141

Capítulo 8

PLANIFICACION Y

PRESUPUESTO.



Cap

ítu

lo: M

anu

al d

e u

suar

io

142



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

143

8. PLANIFICACIÓN Y PRESUPUESTO

En este punto se procede a realizar un breve desarrollo que englobe la

planificación y el presupuesto estimado para el desarrollo de este proyecto.

Para empezar, a continuación se muestra una estructura desagregada de tareas

que engrosan el proyecto.

8.1. ESTRUCTURA DESAGREGADA DE TAREAS

Figura 41 – Estructura desagregada de tareas

JSK

anke

n

A1. - Documentación inicial

A1.1. - Anexo A

A1.2. - Anexo B

A2. - Investigación

A3. - Desarrollo

A3.1. - Capa presentación

A3.2. - Capa negocio

A3.2.1. - Identificación (2 h.)

A3.2.2. - Buscador (14 h.)

A3.2.3. - ORC Kanjis (230 h.)

A3.2.4. - Generador exámenes (17 h.)

A3.2.5. - Evaluador exámenes (21 h.)

A3.3. - Capa datos

A4. - Pruebas

A4.1. - Pruebas OCR

A4.2. - Pruebas Web

A5. - Implantación

A5.1. - Preparación del servidor

A5.2. - Pruebas del servidor

A6. - Documentación final



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

144

En la figura anterior se han especificado los paquetes de trabajo en los que se

divide el proyecto de una forma muy de alto nivel, es decir, muy general.

8.2. PLANIFICACIÓN DEL PROYECTO

Según los paquetes de trabajo expuestos anteriormente, se procede a dejar

reflejada la planificación que se ha seguido para llevar a cabo el desarrollo del proyecto.

Para el desarrollo de la planificación se ha empleado MS Project 2010, realizando

su correspondiente diagrama GANTT.

Figura 42 – Planificación del proyecto

Figura 43 – Diagrama GANTT de la planificación



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

145

Como se puede apreciar en la primera de las dos figuras anteriores que reflejan la

planificación del proyecto, existen al final de los paquetes de trabajo de la EDT

(estructura desagregada de tareas) dos tareas periódicas tan importantes como el resto:

Reuniones director.

Reuniones Alumnos Beta.

La primera de las tareas periódicas dejan fijadas las fechas de reunión con el

director del proyecto. Estas, han sido fijadas cada cuatro semanas.

Por otro lado, las reuniones con los alumnos que realizarán las pruebas de la

plataforma como usuarios beta de la plataforma. Están empiezan en el mes de marzo

para realizar las primeras pruebas del OCR, y posteriormente de la plataforma de

forma completa.



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

146

8.3. PRESUPUESTO DEL PROYECTO

Una vez realizada la planificación del proyecto, y sabiendo todas las tareas en las

que se divide el proyecto, se procede a realizar un análisis de los perfiles de trabajo que

se precisan para el desarrollo de este proyecto:

o Jefe de proyecto (JF).

o Analista (AN).

o Programador PHP (PP).

o Programador UNIX (PU).

o Lingüista japonés (LJ).

Estos cinco tipos de perfiles son los necesarios para poder llevar a cabo un buen

desarrollo del proyecto y lograr su finalización.

A continuación se expone un cálculo de horas/hombre necesarias para el

desarrollo del proyecto según los distintos perfiles:

JF AN PP PU LJ

Documentación inicial 10 h. 10 h.

Investigación 20 h. 15 h. 30 h. 65 h.

Desarrollo 10 h. 35 h. 239 h. 284 h.

Pruebas 30 h. 30 h.

Implantación 2 h. 10 h. 12 h.

Documentación final 25 h. 10 h. 15 h. 15 h. 5 h. 70 h.

45 h. 97 h. 239 h. 25 h. 35 h. 471 h.

Tabla 15 – Horas de trabajo



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

147

Para realizar el cálculo del costo final del proyecto en cuestión de recursos

humanos, se han tomado tarifas estándar de los diferentes perfiles de trabajo.

Precio/hora Horas Coste

JF 65 €/h. 45 h. 2.925 €

AN 45 €/h. 97 h. 4.365 €

PP 35 €/h. 269 h. 9.415 €

PU 35 €/h. 25 h. 875 €

LJ 60 €/h. 35 h. 2.400 €

19.979 €

Tabla 16 – Presupuesto del proyecto

El coste total del desarrollo del proyecto es de 19.979 €, sin impuestos

añadidos.

En cuanto al coste de software o material, no se han tenido gastos añadidos, al

llevar a cabo el desarrollo del proyecto con material ya disponible y software libre que

no conlleva en gasto alguno.



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

148



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

149

Capítulo 9

CONCLUSIONES.



Cap

ítu

lo: P

lan

ific

ació

n y

pre

supu

esto

150



Cap

ítu

lo: C

on

clu

sion

es

151

9. CONCLUSIONES

En este punto se van a explicar las conclusiones obtenidas una vez se ha

realizado el proyecto. Se explicarán en primera persona los resultados obtenidos.

Después de llevar tres años como estudiante de japonés y haber superado los

niveles de los exámenes que engloba este proyecto, tengo presente la dificultad que

presenta realizar dichos exámenes con los sistemas de ayuda existentes.

Una vez desarrollado este proyecto puedo afirmar que facilita mucho la labor de

práctica y ayuda a conseguir un mejor aprendizaje para afrontar los exámenes

oficiales de japonés. Personalmente pienso que, con un mayor contenido, la plataforma

puede llegar a emplearse en las escuelas que ofrezcan el idioma para ayudar a sus

alumnos a superar las pruebas lingüísticas del idioma japonés.

De todas las partes diseñadas y desarrolladas, de las que se compone el proyecto,

considero que se ha logrado lo propuesto para este proyecto, desarrollando módulos

eficientes y potentes, aunque se podría mejorar ampliando los niveles de exámenes que

puede realizar el usuario.

En el aspecto de la programación, se puede decir, que ha resultado complejo, y en

algunas ocasiones, difícil de elaborar, ya que se han empleado tecnologías que no

conocía personalmente, y a veces, se carecía de información suficiente. Sin embargo, he

de admitir, que al final, ha sido gratificante ir obteniendo resultados después de todo el

esfuerzo.

No obstante, la programación y la recopilación de información no ha sido el único

problema durante el desarrollo. Especialmente, para el desarrollo del OCR de la

plataforma, ha sido necesario investigar a fondo. Al principio, se obtenían unas altas

tasas de errores en las pruebas del OCR, pero se fue refinando la programación a lo

largo del desarrollo del proyecto llegando a conseguir una baja tasa de errores y en

algunos casos, eliminándola completamente.

Una vez expuestos mis pensamientos acerca del proyecto realizado, se van a

incluir también unos futuros desarrollos, abriendo nuevas líneas de desarrollo sobre el

tema, que aun puede mejorar más.



Cap

ítu

lo: C

on

clu

sion

es

152



Cap

ítu

lo: C

on

clu

sion

es

153

Capítulo 10

FUTUROS

DESARROLLOS.



Cap

ítu

lo: C

on

clu

sion

es

154



Cap

ítu

lo: F

utu

ros

des

arro

llos

155

10. FUTUROS DESARROLLOS

Referentes a futuros desarrollos con respecto a la aplicación JSKanken:

Al finalizar este proyecto, con la realización de la versión beta de la plataforma, si

se logra que tenga una buena aceptación entre el público estudiante del idioma japonés,

se pretende desarrollar una posterior versión con una mejora notable en el aspecto y

sobretodo, en el contenido, añadiendo el contenido de niveles superiores de los

exámenes oficiales, así como mejorando más aun, la tasa de error existente en el OCR

actual. Además de finalizar la versión de móvil iniciada durante el desarrollo de este

proyecto, y que no pudo ser finalizada, debido al alcance del producto web.

Un aspecto interesante, sería añadir técnicas de SEO para la plataforma y lograr

una mejor expansión de la misma a través de internet.

Una mejora que podría también ayudar a atraer más estudiantes a la plataforma,

es la de implantar otras formas de aprendizaje como pueden ser:

Zona para dibujar kanjis en a que los usuarios puedan realizar un estudio

de los mismos más enfocado aún a su correcta escritura.

Zona de juegos, todo ello orientado a lo mismo, es estudio de la lengua

japonesa.



Cap

ítu

lo: F

utu

ros

des

arro

llos

156



Cap

ítu

lo: F

utu

ros

des

arro

llos

157

Capítulo 11

BIBLIOGRAFÍA Y

REFERENCIAS.



Cap

ítu

lo: F

utu

ros

des

arro

llos

158



Cap

ítu

lo: B

ibli

og

rafí

a y r

efer

enci

as

159

11. BIBLIOGRAFÍA Y REFERENCIAS

Minna no Nihongo

Editorial: Nippan Shuppan Hanbai

Kanken kako mondaishiyuu jitsukiyuu 2011

Ingeniería del software

Autor: Roger S. Pressman

Editorial: McGrawHill

Japanese-Language Proficiency Test

http://www.jlpt.jp/e/

Kanji Kenti Shiken

http://www.kanken.or.jp/index.php

Wikipedia

http://es.wikipedia.org/

[FRA01] Franklin, S., “Planing your web site with UML”, webreview.

http://www.webreview.com/2001/05_18/developers/index01.shtml

http://www.jlpt.jp/e/

http://www.kanken.or.jp/index.php

http://es.wikipedia.org/wiki/Wikipedia:Portada

http://www.webreview.com/2001/05_18/developers/index01.shtml

jskanken - iit | instituto de investigacion tecnológica · kanjis, aprender kanjis, kanji kentei,...

Documents