Traducido del inglés al español - www.onlinedoctranslator.
com
Técnica de Análisis Semántico de Recuperación de Lógicas para
Pruebas de software a partir de documentos de especificación
Satoshi Masuda, Futoshi Iwama, Tohru Matsuodani
Nobuhiro Hosokawa Investigación de ingeniería de depuración
IBM Research – Tokio Laboratorio
Toyosu, Tokio, Japón Tama-shi, Tokio, Japón
{smasuda, gama, matsuodani@debugeng.com
carvin}@jp.ibm.com
Abstracto—Las pruebas de software a menudo se enfocan en
documentos de especificación de lenguaje natural. La creación de casos
de prueba depende de las habilidades del ingeniero, por lo que es
importante la automatización de la creación de casos de prueba a partir
de la especificación del lenguaje natural. La recuperación de lógicas es
una técnica necesaria para automatizar la creación de casos de prueba,
porque una vez que se recuperan las lógicas podemos transformarlas en
tablas de decisión y también crear casos de prueba a partir de las tablas
de decisión. Además, la estructura del idioma japonés es diferente del
inglés. Si nos dirigimos al lenguaje natural japonés, también se requiere
una nueva técnica. Proponemos una Técnica de Análisis Semántico de
Recuperación de Lógicas para Pruebas de Software a partir de
Documentos de Especificación del Sector Público Japonés. Esta técnica
es una recuperación de nueva lógica a partir de la armonización entre la
técnica de procesamiento del lenguaje natural y las pruebas de
software.
Palabras clave: caso de prueba; procesamiento natural del lenguaje; análisis
semántico; recuperación de lógicas; idioma japonés
yo yoNTRODUCCIÓN
Las pruebas de software requieren una alta cobertura de casos de prueba a
medida que el software se vuelve grande y complejo. La prueba contra
documentos de especificación de lenguaje natural es el enfoque estándar para las
pruebas de sistema y aceptación [2]. Los casos de prueba suelen crearse
manualmente, por lo que la cobertura de casos de prueba depende de las
habilidades de cada individuo. Bajo estas circunstancias, es difícil crear casos de
prueba de alta cobertura. Para crear casos de prueba de alta cobertura, se
requiere cubrir para probar todas las funciones que se describen en sus
documentos de especificación al menos. Los documentos de especificación, como
los requisitos y el diseño externo, a menudo se describen en sus lenguajes
naturales, porque los documentos son el resultado de las discusiones de las partes
interesadas. Acerca de la cobertura para probar todas las funciones de los
documentos de especificación de lenguaje natural, es una técnica importante para
recuperar la lógica de los documentos. La técnica de recuperación de lógica
depende de las habilidades individuales hasta el momento. Es importante para la
creación de casos de prueba recuperar sus lógicas de los documentos de
especificación correctamente. Una vez que se recuperan las lógicas, podemos
crear una tabla de decisiones y también crear los casos de prueba a partir de la
tabla [18]. Si podemos recuperar las lógicas automáticamente sin depender de las
habilidades de cada individuo, es una forma más eficiente de crear casos de
prueba.
En este artículo, proponemos una técnica de análisis semántico de
recuperación de lógicas para pruebas de software del público japonés.
2015 IEEE Octava Conferencia Internacional sobre Talleres de Prueba, Verificación y Validación de Software (ICSTW) 2.º
Taller Internacional sobre Arquitectura de Prueba de Software (InSTA 2015)
978-1-4799-1885-0/15/$31.00 ©2015 IEEE
kazuhiko tsuda
Universidad de Tsukuba
Bunkyo-ku, Tokio, Japón
tsuda@gssm.otsuka.tsukuba.ac.jp
documentos de especificación del sector como Fig.1. El idioma japonés tiene
una estructura diferente del idioma inglés. Esta técnica es un enfoque para
aplicar el procesamiento del lenguaje natural para resolver los problemas en
la creación de casos de prueba. La armonización entre las técnicas de
procesamiento del lenguaje natural y las pruebas de software es un área
clave para determinar cómo dirigimos el desarrollo de casos de prueba.
Creemos que este es un diseño de arquitectura de prueba. Este enfoque se
clasifica en el diseño de la arquitectura de prueba y también esta técnica de
lógica de recuperación es una de análisis de requisitos de prueba.
Fig. 1. La técnica de análisis recupera la lógica de los documentos de especificación.
II. BANTECEDENTES Y MOTIVACIÓN
Se proponen lenguajes formales como UML, SysML para describir la
especificación de documentos. Ya se conocen las técnicas de
recuperación de lógicas a partir de los documentos que describen estos
lenguajes formales como pruebas basadas en modelos. Sin embargo, en
la industria de TI, especialmente en los sistemas empresariales como
sistemas administrativos, estos lenguajes formales no son populares.
Las partes interesadas a menudo usan su lenguaje natural para
intercambiar su idea, procesos comerciales, reglas comerciales y otras
especificaciones y describen las especificaciones en documentos
mediante su lenguaje natural. Bajo esta situación, Sneed2007 [2] ha
propuesto un enfoque para aplicar los requisitos del lenguaje natural en
el sistema y las pruebas de aceptación. Este enfoque consiste en aplicar
sus reglas de procesamiento originales que no utilizan técnicas estándar
de procesamiento del lenguaje natural, como el análisis morfológico y el
análisis estructural. Al pensar en reutilizar los resultados de la
investigación del procesamiento del lenguaje natural, se requiere otra
técnica que esté de acuerdo con las técnicas estándar de procesamiento
del lenguaje natural.
La investigación entre las pruebas de software a partir de documentos
de especificación y el procesamiento del lenguaje natural japonés es
insuficiente. El enfoque de Sneed2007 es para el idioma inglés. Todavía
hay una gran demanda de servicios de TI, incluidas las pruebas de
software en Japón. El PIB japonés es el tercero del mundo y TI
las empresas siguen creciendo en el idioma japonés. Luego, hay
oportunidades para aplicar el procesamiento del lenguaje natural
japonés al desarrollo y prueba del sistema. Como la gente sabe, existen
diferencias entre el idioma japonés y el inglés en cuanto al carácter, la
estructura y la gramática. Ha habido un proceso de desarrollo de
software a partir del proceso del lenguaje natural [11]. Este no es el
punto de vista de las pruebas de software.
La técnica de análisis recupera la lógica de cada oración en los documentos
de especificación como talón de condición (CS), entrada de condición (CE),
talón de acción (AS) y entrada de acción (AE). Estos elementos lógicos
provienen de la definición de la tabla de decisiones [1]. El
la lógica se puede describir como (1).
Si (CS) es (CE), (AS) es (AE). (1) procesamiento del lenguaje en pruebas de software.
Definimos reglas y algoritmos para la recuperación de lógicas. En futuras
investigaciones, si establecemos más reglas, la proporción de memoria
crecerá. En este documento, nos enfocamos en los documentos de
especificación del sector público japonés. Las razones son que el tamaño de
la empresa de desarrollo y prueba del sistema del sector público japonés
alcanzó los 2200 millones de yenes japoneses, lo que representó alrededor
del 20 % del mercado total de servicios de TI de Japón [6], y podemos
obtener los documentos de especificación de ellos en Internet.
tercero ROBRAS ELEVADAS
Muchos investigadores ya intentaron aplicar el procesamiento del
lenguaje natural al desarrollo de software y/o pruebas de software
[3, 13]. Sneed2007 [2] presentó pruebas contra los requisitos del
lenguaje natural. El enfoque fue analizar los requisitos y extraer
casos de prueba de ellos. El documento ilustraba el enfoque en una
aplicación industrial. El documento no menciona las técnicas de
procesamiento del lenguaje natural y el idioma de destino es el
inglés.
Saeki1989 [11] presentó el proceso de desarrollo de software a partir
de la especificación del lenguaje natural. Ese fue un enfoque para
resolver problemas sobre la especificación del lenguaje natural
mediante el proceso que se definió como "diseño" y "elaboración". El
enfoque era no tratar de automatizar mediante el uso de técnicas de
procesamiento de lenguaje natural.
IEEE830 [7] recomienda la práctica para las especificaciones de
requisitos de software. El estándar describe la consideración para
producir una buena especificación de requisitos de software, partes de
ellos y proporciona plantillas. Kim2008 [9] presentó la medición del
nivel de las actividades de control de calidad en el desarrollo de
software. La definición de ambigüedad se describió en el documento.
Cuando nos enfocamos en los requisitos del lenguaje natural, estos dos
documentos son muy efectivos desde el punto de vista de cómo se
deben describir los requisitos y cómo medirlos.
Uetsuki2013 [5] presentó un método de prueba de software eficiente
mediante la verificación de la tabla de decisiones. Eso fue para verificar
la lógica entre documentos y códigos fuente comparando cada tabla de
decisiones que se extraía de documentos y códigos. Tenían como
objetivo que el documento se describiera en lenguaje formal.
En este documento nos enfocamos en el lenguaje natural japonés,
luego analizamos los trabajos de investigación del lenguaje. Kuno1973
[10] presentó diferencias entre el idioma japonés y el idioma inglés
Al igual que las diferencias de dependencia de las palabras, los árboles de sintaxis tienden a profundizarse
en el lado izquierdo y así sucesivamente.
Fukui1988 [8] presentó la derivación de las diferencias entre
inglés y japonés en un estudio de caso en sintaxis paramétrica. Ese
fue un modelo de solución de las diferencias entre el idioma inglés
y japonés hacia la gramática universal. Estos documentos son muy
esenciales para establecer el procesamiento del lenguaje natural
japonés.
En este artículo, sin embargo, no nos centramos en las diferencias
del idioma japonés, porque la técnica de procesamiento del
lenguaje natural japonés ya ha resuelto las diferencias en su
análisis morfométrico y/o análisis estadístico japonés. Nos
enfocamos en aplicar los resultados del natural japonés
Cuando apuntamos al idioma japonés, Tanaka1993 [16] presentó
la estructura lógica recuperada de los documentos legales
japoneses. Katayama2007 [17] también propuso ingeniería legal
[14] y las investigó. Shimazu2012 [12] propuso una metodología
para diseñar un sistema social confiable mediante el análisis de
documentos legales japoneses. Estos análisis de documentos
legales japoneses son útiles para nuestro problema. La gran
diferencia entre ellos y nosotros es que se dirigen a documentos
legales que se describen de manera más formal que los
documentos de requisitos del sistema. Los documentos legales
están escritos por expertos eficientes que tienen licencias, para no
tener ambigüedad, exhaustividad, coherencia, etc. Los documentos
de especificación del sistema están escritos por muchas personas
que no son especialistas en idiomas.
Con base en estos trabajos relacionados, proponemos nuestra técnica de
análisis semántico de recuperación de lógica para documentos de
especificación de sistemas japoneses.
IV. STÉCNICA DE ANÁLISIS EMÁNTICO DE RECUPERACIÓN DE LÓGICAS
Discutimos la técnica de análisis. En primer lugar, usamos la
oración de especificación de muestra (a) y explicamos la técnica de
análisis de manera intuitiva. Cuando tenemos una oración (a),
sigamos para recuperar los pasos lógicos de la oración. La oración
(a) muestra (a)-1 oración en japonés descrita por caracteres
alfabéticos y (a)-2 oración en inglés que significa lo mismo que la
oración en japonés para ambos idiomas.
(a) Oración de especificación de muestra
1. Japonés:
Miraini betsuno detaga haitteitabaai, sono jitennno
tyokuzennwo shuuryoubitosurukoto.
2. Inglés:
Si existen otros datos en un campo futuro, establezca una fecha justo antes de los
datos como fecha de finalización.
El objetivo de la técnica de análisis es recuperar una lógica como la de la
figura 2 a partir de esta oración. La figura 2 muestra una estructura de lógica
como "si (A) es (B) entonces (C) es (D)" en inglés, y "(A) ga (B) nobaai (C) ha (D)
dearu" en inglés. Japonés. Esta lógica describe la lógica de ramificación de la
especificación. Las lógicas de ramificación son importantes para
Casos de prueba. Cuando recuperamos la condición de rama, podemos
poner cada elemento de rama en elementos de tabla de decisiones y
transformarlos en casos de prueba.
• Paso 4: busque la palabra más cercana (A) que dependa de (B)
oAl igual que el paso 3, la palabra más cercana tiene la más fuerte
dependencia con la palabra objetivo.

TABLA I. SESTRUCTURA DE DATOS DE ENTRADA QUE ES EL RESULTADO DE

(A)ga (B)nobaai (C) ha (D) querido
jANÁLISIS MORFOLÓGICO APANESO Y ANÁLISIS DE DEPENDENCIA
((A)) (si .. es (b)) ((C)) es (D)
Ejemplo de estructura de datos de entrada
Fig. 2. Dependencia lógica de una condición.
i PAGmetro(i)*1 Depmetro(i)

La Tabla I. muestra un resultado de las técnicas de procesamiento del miraini

1 4
lenguaje natural japonés que incluye análisis morfológico y análisis de (campo futuro)
Betsuno
dependencia para la oración de muestra. Al usar este resultado, la Fig. 3 2 3
(otro)
muestra los pasos para recuperar la lógica de las oraciones de la siguiente
detaga
manera: 3 4
(datos)
• Requerir: Las oraciones se han analizado morfológicamente y la
4
haiteitabaai
8
dependencia se ha analizado como en la Tabla I. (si existe)
sono
5 6
• Paso 1: busque (B) palabras por coincidencia de patrones de palabras (el)
clave. En este documento establecemos una regla que (B) Las palabras jitenno
6 7
(una cita)
tienen "baai" en japonés que significa "si" en inglés.
tyokuzennwo
7 8
• Paso 2: busque (D) palabras de las que dependa (B). (justo antes)
shuuryoubitosurukoto
8 T
• Paso 3: busque la palabra más cercana (C) que depende de (D) (establece la fecha de finalización)

a.
* 1: japonés (inglés)
oLa palabra más cercana tiene una dependencia más fuerte con
Entonces podemos obtener la lógica de la condición de la oración como "si
la palabra objetivo.
(A) es (B), (C) es (D)”. La definición de la tabla de decisiones [1] es como la Fig.
4.
Las oraciones se han analizado morfológicamente y se ha
analizado la dependencia.

Requerir: miraini Betsuno detaga haiteitabaai sono jitennno tyokuzennwo shuuryoubitosurukoto.

(campo futuro) (otro) (datos) (si existe) (el) (una cita) (justo antes) (establecer como fecha de finalización)

(B)
Paso 1: tyokuzennwo shuuryoubitosurukoto.
miraini Betsuno detaga haiteitabaai sono jitennno
(campo futuro) (otro) (datos) (si existe) (el) (una cita) (justo antes) (establecer como fecha de finalización)

Búsqueda por palabra clave

Búsqueda de dependencia

(B) (D)
Paso 2: tyokuzennwo shuuryoubitosurukoto.
miraini Betsuno detaga haiteitabaai sono jitennno
(campo futuro) (otro) (datos) (si existe) (el) (una cita) (justo antes) (establecer como fecha de finalización)

Búsqueda de dependencia
(A) (B) (D)
Paso 3: tyokuzennwo shuuryoubitosurukoto.
miraini Betsuno detaga haiteitabaai sono jitennno
(campo futuro) (otro) (datos) (si existe) (el) (una cita) (justo antes) (establecer como fecha de finalización)

Búsqueda de dependencia
(A) (B) (C) (D)
Etapa 4: tyokuzennwo
miraini Betsuno detaga haiteitabaai sono jitennno shuuryoubitosurukoto.
(campo futuro) (otro) (datos) (si existe) (el) (una cita) (justo antes) (establecer como fecha de finalización)

Fig. 3. Pasos para recuperar la lógica de las oraciones.

 oLa entrada de acción esAE

talón de condición Entrada de condición Condición • Fórmulas de recuperación de lógica de condición o

FI(K, Pmetro(i))

- PAGmetro(i)es la primera frase que

incluyekEstePAGmetro(i)Se define como
talón de acción Entrada de acción Acción CE.

o DE(CE, Pmetro(i))

- PAGmetro(i)es frase queCEtiene

Talón Entrada
dependencia y final de frases. Este
PAGmetro(i)Se define comoAE.
Figura 4. Definición de tabla de decisión [1]
o NDA (AE, Pmetro(i))

Una vez que recuperamos una lógica de condición, podemos mapear la lógica en la - PAGmetro(i)es la frase más cercana que
tabla de decisiones como la Tabla II. depende deAE. EstePAGmetro(i)Se define
comoCOMO.
TABLA II. LMAPEO ÓGICO ENDDEFINICIÓN DE LA TABLA DE ECISIÓN
o CDN(CE, Pmetro(i))
talón de condición Entrada de condición
(A) (B) - PAGmetro(i)es la frase más cercana que
talón de acción Entrada de acción depende deCE. EstePAGmetro(i) Se
(C) (D) define comoCS.

Las tablas de decisiones se utilizan en muchos dominios de soporte de El diagrama de flujo de la técnica de análisis es como la Figura 3.

decisiones, como los sistemas de soporte de decisiones comerciales, la ingeniería

de software o el análisis (o evaluación) de sistemas. Las tablas de decisión son una
herramienta poderosa, simple e importante para proporcionar razonamiento en para cadaDmetro
una forma compacta [15].
Después de eso, definimos formalmente la técnica de análisis de la siguiente
manera:
FI(K,Pmetro(i))

• Todos los documentos de destino sonDTodo

• Cada oración esD1, D2,…Dmetro

DE(CE,
oDTodo= {D1, D2,…Dmetro} PAGmetro(i))

• Estructura de dependencia de la frase.PAGque provienen del

análisis morfológico y la comparación de dependencias
NDA (AE,
o Dmetro= {PAGmetro(1), Pmetro(2), …Pmetro(norte)}
PAGmetro(i))

o patrón de dependencia de Dmetro son

{Depmetro(1),Depmetro(2),…Depmetro(n-1)}.Depmetro(i)
es el número de frase que la frasePAGmetro(i) CDN(CE,
depende de PAGmetro(i))

• kes el conjunto de palabras clave que buscan palabras de

condición
Recuperación de lógica

o k={k1, k2,…kyo}
Fig. 5. Diagrama de flujo de la técnica de análisis
o En este papel,k=k1=”baai”(si)

• El símbolo terminal de las oraciones esT VEEXPERIMENTOS

• De acuerdo con la definición de la tabla de decisiones, las descripciones de la Experimentamos la técnica de análisis mediante la creación de
lógica de condición son algoritmos, el desarrollo de programas y la aplicación de documentos
de especificación japoneses. El algoritmo 1 muestra cómo recuperar la
o El talón de condición esCS La
lógica de condición de los documentos. Hemos implementado el
o entrada de condición esCE La algoritmo de la técnica de análisis en el programa Perl. También
utilizamos análisis morfológico japonés y análisis de dependencia.
o acción esCOMO
La técnica de análisis es independiente de la técnica y las 0,65 a 0,79. Eso significa que la técnica de análisis puede recuperar la lógica
herramientas de análisis morfológico y análisis de dependencia. de la condición.

Algoritmo 1El algoritmo de la técnica de análisis. precisión = (a) / ((a) + (b)) (2)
Aporte:documentos que han sido analizados momorfológicamente y analizados
según la dependencia
1: para cadaDmetrohacer
recordar = (a) / ((a) + (c)) (3)
2: para todosPAGmetro(i)hacer

3: siPAGmetro(i)=K1entonces

4: CEi=i
5: PAGmetro(i)=CE CUADRO III. TLISTA DE DOCUMENTOS DE OBJETIVO
6: siPm(Depmetro(i))∈DmetroyPAGmetro(Dep.metro(i))∈Tentonces
7: Docu- Caracteres
AEi = yo
8: mento (Doble Tamaño del archivo
PAGmetro(Dep.metro(i)) = EA otra
9: Grupos Paginas bytes) (Bytes) Fecha de Creación
cosa siguienteDmetro

10: final siguienteDmetro A 93 74,559 1,702,400 2010/09/16

11: fin para
12: para todosPAGmetro(i)hacer
A 17 3,283 4,555,776 2014/03/18
13: siDepmetro(i)=CEiymáximo (yo)entonces A 14 9,502 60.416 2008/06/01
14: PAGmetro(Dep.metro(i)) = COMO otra

15: cosa siguienteDmetro

A 15 11,182 51,712 2014/07/01
dieciséis: siDepmetro(i) = AEiymaxi)entonces A 76 63,908 1,008,129 2003/03/01
17: PAGmetro(Dep.metro(i)) = EC otra
18: B 10 6,825 50,688 2014/06/01
cosa siguienteDmetro

19: fin para B 2 779 97,280 2007/11/14

20: fin para
B 22 14,560 499,712 2008/04/01

B 17 11,211 54,272 2006/09/01

La Tabla I muestra la estructura de los datos de entrada que son los
resultados del análisis morfológico y de dependencia. Elise le asigna un B 19 6,844 79,360 2010/05/01

número para cada palabra,PAGmetro(i)es una frase de los resultados del B 9 7,844 140.800 2014/01/01
análisis morfológico, yDepmetro(i)son los resultados del análisis de C 157 152,568 1,995,521 2012/11/01
dependencia. La Tabla IV muestra la lista de documentos de este C 56 55,738 609,407 2005/07/01
experimento. Los documentos están abiertos al público en Internet. Los
C 73 70,167 2.775.933 2011/07/06
documentos provienen del gobierno y las ciudades casi japonesas como
D 11 9,060 37,888 2012/04/01
sector público. El gobierno japonés ordena que su software y sistemas
se hagan públicos para que la empresa de servicios de TI pueda ofertar D 41 38,527 653,312 2012/04/01

el pedido. Luego, los documentos son documentos de especificación D 327 296,451 6,210,032 2012/04/01
del sistema que la empresa de servicios de TI puede estimar la función mi 25 20,364 880,640 2009/12/02
y calcular sus costos. En estos experimentos, agrupamos los mi 8 6,717 77,312 2012/04/01
documentos de la A a la F. Usamos el grupo A y B en el experimento
mi 7 9,852 313,871 2014/04/01
inicial para verificar nuestra técnica de análisis y ajustarla. Una vez
mi 10 8,035 72,192 2013/05/01
fijado el algoritmo de la técnica de análisis y el programa Perl,
aplicamos el programa del grupo C al F. F 10 4,419 90,624 2011/10/01

F 8 5,012 10,223 2013/04/01

Los expertos en pruebas de software que tienen 20 años de F 173 188,919 1,172,389 2007/04/01
experiencia en pruebas de software evalúan los resultados de la técnica F 18 26,466 618,214 2013/04/01
de análisis. Los puntos de evaluación son si recuperan las lógicas
manualmente, comparan los resultados de la técnica de análisis y los
manuales por exhaustividad, corrección de frases y se pueden CUADRO IV. RRESULTADOSTEL TÉCNICA DE ANÁLISIS VS. miVALUACIÓN
transformar en una tabla de decisiones. En la tabla IV se muestran los
El
resultados de la técnica de análisis versus evaluación por positivo y análisis Positivo Negativo
negativo. Por ejemplo, cuando la técnica de análisis recupera la lógica técnica
de condición y los expertos en pruebas de software, la lógica es buena, Positivo Negativo Positivo Negativo
Evaluaciones
(a) (b) (C) (d)
entonces la lógica de recuperación cuenta para positivo-positivo. Otro
A 31 1 15 2
ejemplo, cuando la técnica de análisis excluye una oración pero los
expertos en pruebas de software deben recuperar la lógica que evalúa B 15 1 4 3
las oraciones, entonces la lógica cuenta para negativo-positivo. C 43 2 17 4
La Tabla V muestra los resultados de los experimentos usando factores de D 62 5 33 21
memoria y precisión. El recuerdo y la precisión se calculan mediante la
mi 35 1 19 6
ecuación (2) y (3) usando (a) a (c) en la tabla IV. Como muestra la tabla V, la
F 107 8 40 26
precisión alcanzó de 0,93 a 0,97 y la recuperación alcanzó
 CUADRO V. RRESULTADOS DERLLAMADA Y PRECISIÓN
Grupos de documentos
A B C D mi F
Precisión 0.97 0,94 0,96 0,93 0.97 0,93
Recordar 0,67 0.79 0.72 0,65 0,65 0.73
Observamos sobre razones de evaluación negativa de los
resultados como (b), (c) y (d). En el caso (b), la técnica de análisis
es positiva y la evaluación es negativa. Cuando hay paréntesis,
caracteres alfabéticos y otros caracteres especiales en frases
que dependen deCE, el motor de análisis morfológico puede
determinar que los caracteres son frases individuales. En este
caso, si se recupera la lógica, las frases no son comprensibles.
Son solo caracteres de paréntesis. En el caso (c) que la técnica
de análisis negativa y la evaluación positiva, hay algunas
razones. Primero, el análisis morfológico no lo analizó como se
esperaba. Por ejemplo, cuando hay una coma “,” justo antesCEla
frase, incluidas las palabras clave de condición, el motor de
análisis determina que no hay dependencia con elCE. El
segundo ejemplo es también un análisis morfológico. Cuando la
siguiente frase deCEes un gerundio (en inglés -En gsustantivo),
el motor de análisis determinaCE depende del gerundio como
verbo que no se recoge dependencia. El análisis morfológico
japonés y el análisis de dependencia dependen del método que
implementen los motores de análisis. La técnica de análisis
puede usar cualquier motor si deriva frases de oraciones y
genera la dependencia entre frases. Las (c) oraciones
categorizadas son oraciones compuestas, oraciones complejas,
oraciones de listado, etc. El algoritmo actual ignora este tipo de
oraciones porque no se puede determinar la dependencia de la
frase de condición. En el caso de (d) que la técnica de análisis
resulte negativa y la evaluación también resulte negativa. Las
oraciones categorizadas en este (d) son descripciones originales
incorrectas. Los casos (d) son candidatos para nuestros trabajos
futuros a la retroalimentación de la descripción manual en los
documentos de especificación. Cuando los expertos no
entendieron la lógica de las oraciones, debe haber algo
incorrecto en las oraciones. Entonces es importante para
nosotros investigar el caso (d) para el trabajo futuro.
VI. CONCLUSIÓN
Propusimos la técnica de análisis, una técnica de análisis semántico de
recuperación de lógica para pruebas de software a partir del concepto
de documentos de especificación del sector público japonés, técnica y
presentamos los resultados de los experimentos. El resultado fue que la
precisión alcanzó de 0,93 a 0,97 y la recuperación de 0,65 a 0,79. Eso
mostró que la técnica de análisis funcionó para recuperar la lógica de
las condiciones. Confirmamos que la técnica de análisis podía recuperar
la lógica de los documentos de especificación del lenguaje natural
japonés. Cuando apuntamos a recuperar lógicas de condiciones, la
cantidad de palabras clave para condiciones es limitada. Luego, la
técnica de análisis funciona para las condiciones de recuperación de los
documentos de especificación.
Este resultado es el punto de partida para la investigación sobre la
armonización entre el procesamiento del lenguaje natural y las pruebas
de software. Matsuodani2012[4] también propuso los beneficios de
recuperar la lógica de los documentos de especificación en
mesas de decisión y examinó las oportunidades del futuro de la mesa de
decisión. La técnica de análisis puede detectar la ambigüedad lógica de los
documentos de especificación y las mediciones de retroalimentación para la
calidad del documento. Kim2008 propone las medidas de los documentos de
especificación como métricas de calidad, por ejemplo, densidad de defectos
de documentos, reutilización de documentos, etc. La técnica de análisis
puede retroalimentar cómo escribimos documentos de especificación
manualmente con precisión. Cuanto más correcto podamos describir la
lógica en los documentos de especificación por adelantado, menor será la
carga de trabajo para corregir la lógica incorrecta.
RFERENCIAS
[1] Asociación de Normas de la Industria de Japón, "Tabla de decisiones JIS X 0125-1986", en
Normas de la Industria de Japón, 1986
[2] HM Sneed, "Pruebas frente a los requisitos del lenguaje natural", en
IEEEQuality Software, 2007. QSIC'07. Séptima Conferencia Internacional
sobre, 2007, pp.380-387
[3] K. Tsuda y M. Nakamura, "El método de extracción de la clase de
significado de palabras", en IEEE Knowledge-Based Intelligent
Information Engineering Systems, 1999. Tercera Conferencia
Internacional, 1999, pp.534-537
[4] T. Matsodani, "Aplicación de la tabla de decisiones a la lógica del software con
diseño y prueba", en Reliability Enginerring Association of Japan, 2012,
pp.397-404
[5] K. Uetsuki, T. Matsuodani y K. Tsuda, "Un método de prueba de software eficiente
mediante la verificación de tablas de decisiones", en International Journal of
Computer Applications in Technology, 2013, pp.54-64
[6] S. Kishimoto, "Sistema de contratación pública y sistema de TI -
Quién levantó o constructor general de TI", en http://
www.rieti.go.jp/jp/projects/denshi/04.pdf, 2003, pp .37-47
[7] Comité ICSSES y Junta I.-SS, "Práctica recomendada de IEEE para
especificaciones de requisitos de software", en el Instituto de
Ingenieros Eléctricos y Electrónicos, 1998
[8] N. Fukui, "Derivar las diferencias entre inglés y japonés", en English
Linguistics, 1988, pp.249-270
[9] C. Kim, S.-M. Kim y K.-W. Song, "Medición del nivel de actividades de control de
calidad en el desarrollo de software [Cuadernillos de puntuación de control
de calidad]", en IEEEConvergence and Hybrid Information Technology, 2008.
ICHIT'08. Conferencia Internacional sobre, 2008, pp.763-770
[10] S. KUNO, "La estructura del idioma japonés", en Cambridge,
MA:MIT Press., 1973
[11] M. Saeki, H. Horai y H. Enomoto, "Proceso de desarrollo de software a partir
de la especificación del lenguaje natural", en ACM Actas de la 11ª conferencia
internacional sobre ingeniería de software, 1989, pp.64-73
[12] A. Shhimazu, "Ingeniería Jurídica: Metodología para el Diseño de
Sistemas Sociales Confiables -Análisis de Documentos Legales-", en
IEICE Foundamentals Review, 2012, pp.320-328
[13] T. Kudo y Y. Matsumoto, "Análisis de dependencia japonés mediante
fragmentación en cascada", en Journal of Information Processing Society of
Japan, 2002, pp.1834-1842
[14] Y. Kimura, M. Nakamura, A. Shimazu, "Expresión lógica de transformación de
documentos legales que tienen listados y referencias", en Asociación para el
procesamiento del lenguaje natural, 2008, pp.612-615
[15] Y. Tang y R. Meersman, "Sobre la construcción de tablas de decisiones semánticas",
en SpringerDatabase and Expert Systems Applications, 2007, pp.34-44
[16] K. Tanaka, I. Kawazoe y H. Narita, "Estructura estándar de disposiciones
legales - Para el procesamiento de conocimiento legal por lenguaje natural
-", en Information Processing Society of Japan Natural Language Processing,
1993, pp.79-86
[17] T. Katayama, "Ingeniería jurídica: un enfoque de ingeniería de las leyes en la era de la
sociedad", en Proc. de la 1ra Internacional Taller sobre JURISIN, 2007
[18] S. Masuda, T. Matsuodani y K. Tsuda, "Un método para crear un patrón de prueba para el
método por pares mediante el uso del conocimiento de los valores de los parámetros", en
Procedia Computer Science, 2013, pp.521-528