Generación de nuevos Biopolímeros a partir de subproductos ...
Generación de Escenarios de Calidad a partir de ...
77
Generación de Escenarios de Calidad a partir de Requerimientos Textuales Tesis para el grado de Ingeniero de Sistemas Facultad de Ciencias Exactas Andreés Vicente Javier Enrique Marsicano Bajo la supervisioén de: Dra. Claudia Marcos Dr. J. Andreés Díaz Pace Universidad Nacional del Centro de la Provincia de Buenos Aires Tandil, Argentina Diciembre 2017
Transcript of Generación de Escenarios de Calidad a partir de ...
Generación de Escenarios de Calidad
a partir de Requerimientos Textuales
Tesis para el grado de Ingeniero de Sistemas
Facultad de Ciencias Exactas
Andreés Vicente
Javier Enrique Marsicano
Bajo la supervisioén de:
Dra. Claudia Marcos
Dr. J. Andreés Díaz Pace
Universidad Nacional del Centro de la Provincia de Buenos Aires
Tandil, Argentina
Diciembre 2017
INDICE GENERAL
Resumen..............................................................................................................................................6 1 Introducción......................................................................................................................................9
1.1.Problemática............................................................................................................................101.2.Enfoque de QAGen..................................................................................................................111.3.Organización del Informe........................................................................................................13
2 Marco teórico..................................................................................................................................142.1.Atributos de Calidad................................................................................................................14
2.1.1 Performance...................................................................................................................14 2.1.2 Usabilidad......................................................................................................................15 2.1.3 Modificabilidad.............................................................................................................15 2.1.4 Seguridad.......................................................................................................................16 2.1.5 Otras consideraciones sobre QAs..................................................................................16
2.2.Arquitectura de Software.........................................................................................................172.3.Escenarios de calidad...............................................................................................................172.4.Natural Language Understanding (NLU)................................................................................20
2.4.1 Análisis Léxico y Segmentación...................................................................................20 2.4.2 Lematización.................................................................................................................21 2.4.3 Etiquetado gramatical....................................................................................................21 2.4.4 Análisis sintáctico..........................................................................................................23
2.5.Generación de Lenguaje Natural (NLG).................................................................................23 2.5.1 Corpus NLG..................................................................................................................24 2.5.2 Arquitectura de un sistema NLG...................................................................................24 2.5.3 Relación de NLG con NLU...........................................................................................26
2.6.Información no estructurada....................................................................................................272.7.UIMA.......................................................................................................................................27
3 Trabajos relacionados....................................................................................................................293.1.Modelo para la Elicitación y Especificación manual de QAs.................................................293.2.EAMiner..................................................................................................................................303.3.QAMiner..................................................................................................................................313.4.REAssistant..............................................................................................................................333.5.Scenarios Tool..........................................................................................................................343.6.Resumen..................................................................................................................................36
4 QAGen: Un Enfoque para Generación de Escenarios de Calidad..................................................374.1.Uso de QAGen para generar escenarios de calidad.................................................................384.2.Herramientas de desarrollo de software escogidas..................................................................394.3.Proceso y etapas de QAGen....................................................................................................40
4.3.1 Etapa de segmentación..................................................................................................42 4.3.2 Etapa de pre-análisis......................................................................................................42 4.3.3 Etapa de QA Mining......................................................................................................44 4.3.4 QA Mining con UIMA Ruta..........................................................................................47 4.3.5 Etapa de Scenario Linking.............................................................................................48 4.3.5.1 Microplanner y análisis gramatical............................................................................49 4.3.5.2 Seed Extractors...........................................................................................................51 4.3.5.3 Generación de los escenarios de calidad....................................................................53
4.4.Arquitectura de QAGen...........................................................................................................54 5 Evaluación......................................................................................................................................55
5.1.Procedimiento experimental....................................................................................................55
2
5.1.1 Experimento #1.............................................................................................................56 5.1.2 Experimento #2.............................................................................................................57
5.2.Métricas...................................................................................................................................59 5.2.1 Coeficiente de Jaccard...................................................................................................60 5.2.2 Sorensen-Dice...............................................................................................................60 5.2.3 Similitud del Coseno....................................................................................................61 5.2.4 Normalized Levenshtein...............................................................................................61 5.2.5 Jaro-Winkler.................................................................................................................61 5.2.6 Aplicación de las métricas............................................................................................62
5.3.Discusión de los resultados......................................................................................................63 5.3.1 Similitud con escenarios de referencia.........................................................................63 5.3.2 Velocidad de ejecución.................................................................................................67
6 Conclusiones...................................................................................................................................686.1.Contribuciones.........................................................................................................................696.2.Limitaciones............................................................................................................................706.3.Trabajos futuros.......................................................................................................................70
7 Apéndice.........................................................................................................................................727.1.Escenarios generados y reales (benchmark)............................................................................727.2.Performance sentences del caso de estudio MSLite................................................................737.3.Valores obtenidos al aplicar las métricas.................................................................................737.4.Herramienta QAGen................................................................................................................75
8 Referencias.....................................................................................................................................76
3
INDICE DE FIGURAS
Figura 1.1: Proceso del enfoque propuesto.......................................................................................12 Figura 2.1: Partes del escenario de calidad........................................................................................18 Figura 2.2: Performance scenario sample.........................................................................................19 Figura 2.3: Ejemplo de lexema y morfemas......................................................................................21 Figura 2.4: Categorías gramaticales Penn Treebank.........................................................................22 Figura 2.5: Grafo de análisis sintáctico.............................................................................................23 Figura 2.6: Arquitectura NLG...........................................................................................................26 Figura 2.7: UIMA Analytics..............................................................................................................28 Figura 3.1: Tangling vs. Scattering....................................................................................................30 Figura 3.2: Overview of QAMiner approach....................................................................................32 Figura 3.3: Overview of REAssistant approach................................................................................33 Figura 3.4: Esquema de funcionamiento...........................................................................................35 Figura 4.1: Fases y etapas del pipeline de QAGen............................................................................38 Figura 4.2: Proceso completo de QAGen..........................................................................................39 Figura 4.3: Fase Estructuración con sus etapas.................................................................................42 Figura 4.4: Fase Análisis QA con sus etapas.....................................................................................44Figura 4.5: Resultado de aplicar las reglas a las oraciones de ejemplo de performance....................46 Figura 4.6: Resultado de aplicar Parser a las oraciones de ejemplo de Performance........................50 Figura 4.7: Ejemplo de oración donde se aplican varios patrones....................................................52 Figura 5.1: Fórmula de Jaccard.........................................................................................................60 Figura 5.2: Fórmula Sorensen-Dice..................................................................................................61 Figura 5.3: Fórmula de similitud del Coseno....................................................................................61 Figura 5.4: Fórmula Levenshtein......................................................................................................61 Figura 5.5: Fórmula Jaro...................................................................................................................62 Figura 5.6: Fórmula Jaro-Winkler.....................................................................................................62 Figura 5.7: Valores obtenidos al aplicar las métricas de similitud....................................................63 Figura 5.8: Valores de similitud con R1 y R2....................................................................................64 Figura 5.9: Valores de similitud con R1............................................................................................65 Figura 5.10: Valores de comparación con R2....................................................................................66 Figura 7.1: Pantalla de generación de escenarios de calidad.............................................................75 Figura 7.2: Pantalla del contexto de la QA Sentence........................................................................75
4
INDICE DE TABLAS
Tabla 2.1: Conceptos de performance (adaptado de [IEEE1992]).....................................................15Tabla 4.1: Ejemplo de POS tagging....................................................................................................43Tabla 4.2: Palabras clave de la taxonomía Constraint........................................................................44Tabla 4.3: Palabras clave de la taxonomía LTD.................................................................................45Tabla 4.4: Palabras clave de la taxonomía Event...............................................................................45Tabla 4.5: Palabras clave de la taxonomía Time................................................................................45Tabla 4.6: Frases candidatas para escenarios generadas.....................................................................53Tabla 5.1: Performance sentence detectada en HWS.........................................................................56Tabla 5.2: Performance sentences detectadas en CRS.......................................................................57Tabla 5.3: Secciones candidatas generadas para HWS y CRS...........................................................57Tabla 5.4: Secciones candidatas generadas para MSLite...................................................................58Tabla 5.5: Escenario candidato generado para MSLite......................................................................59Table 5.6: Valores de similitud con R1 y R2......................................................................................63Table 5.7: Valores de comparación con R1........................................................................................65Table 5.8: Valores de comparación con R2........................................................................................66Table 5.9: Tiempos de ejecución del procedimiento registrados........................................................67Tabla 7.1: Códigos de referencia a los escenarios de calidad generados por QAGen........................72Tabla 7.2: Códigos de referencia a los escenarios de calidad reales..................................................73Tabla 7.3: Performance sentences detectadas en MSLite...................................................................73Table 7.4: Valores obtenidos comparando contra R1.........................................................................74Table 7.5: Valores obtenidos comparando contra R2.........................................................................74
5
Resumen
Para el desarrollo de un sistema de software, es necesario contar con la especificación de
los requerimientos. Los mismos suelen referirse a la funcionalidad del sistema, es decir, a la
capacidad del sistema para hacer el trabajo para el cual fue pensado. Sin embargo, el éxito o
fracaso del desarrollo de un sistema no está determinado sólo por los requerimientos funcionales,
sino también por los no funcionales, o atributos de calidad (QAs). Para lograr un sistema de
calidad es importante tomar buenas decisiones al momento de diseñar la arquitectura, ya que un
diseño puede cumplir con la funcionalidad deseada y fallar a la hora de satisfacer sus QAs; es por
ello que es imprescindible identificarlos durante la captura de requerimientos, para tenerlos en
cuenta en la etapa de diseño y obtener especificaciones concretas de cada uno de ellos.
Los QAs se pueden representar, especificar y analizar mediante escenarios de calidad. El
escenario de calidad es un mecanismo que permite caracterizar y capturar aspectos de QAs de
una forma concreta, que puede ser evaluada y utilizada en las actividades de diseño, y luego
durante el desarrollo. La tarea de analizar los requerimientos para especificar escenarios de
calidad concretos suele resultar dificultosa para el analista o arquitecto, ya que requiere de mucho
tiempo y esfuerzo; además que para lograrlo de manera eficaz debe poseer experiencia y
conocimiento sobre cada uno de los QAs relevados.
En este trabajo se presenta una herramienta para asistir a un arquitecto o analista en la
tarea de especificación de escenarios de calidad, obteniendo información de un documento de
requerimientos textuales, gracias a técnicas de procesamiento de lenguaje natural (NLP) e
información no estructurada, para detectar los atributos de calidad y generar, de manera semi
automática, escenarios de calidad a partir de las especificaciones de requerimientos. La
herramienta, llamada QAGen, puede entonces asistir a un analista que no tiene experiencia
suficiente y minimizar los tiempos que demanda una inspección manual, para obtener los
escenarios de calidad que son tan importantes para el diseño arquitectónico del sistema.
Para evaluar la técnica propuesta se realizaron 2 experimentos, con diferentes métricas de
similitud entre escenarios generados y reales, obteniendo una buena cantidad de cifras que fueron
sintetizadas y analizadas con valores de similitud aceptables. Además se evaluaron los tiempos
de análisis y generación de escenarios candidatos, que en ningún caso superaron los 20
segundos. Estos fueron muy favorables, sobre todo en comparación con herramientas similares,
que utilizan otras técnicas, demandando tiempos mayores en varios órdenes de magnitud.
6
DedicatoriasA mi madre por su apoyo con paciencia, amor, sacrificio, recursos y compañía.
A mi amada Adriana por ser la persona con la que compartiremos no sólo este sino muchos logros
y desafíos al unirnos con amor para toda la vida.
A todos mis amigos y parientes que me acompañaron, comprendieron y apoyaron con su fe, amor
fraternal, y siendo parte de alguna u otra manera.
Pero sobre todo a Jesucristo por ser la razón de mi nueva vida, fuente de inspiración y fortaleza.
J. E. M.
En primer lugar a Dios, porque todo es por él y para él.
Luego a Joana, mi esposa, la persona que alegra mi vida; por su compañía, apoyo, empuje,
paciencia, dedicación y amor incondicional.
A mis padres, Néstor y Viviana, por su esfuerzo, sustento, educación, paciencia y amor.
A mis hermanos, mi abuela, mis amigos y todos los que creyeron en mi y comparten esta
alegría conmigo.
A. V.
7
AgradecimientosAgradecemos a nuestros directores Dr. Jorge Andrés Díaz Pace y Claudia Marcos, por escuchar
esta propuesta de Tesis y compartir el mismo entusiasmo que nosotros en la realización de este
proyecto, con predisposición y paciencia. También queremos hacer llegar nuestro agradecimiento
a todos los profesionales que formaron parte de nuestro ciclo académico, sin su vocación docente
no podríamos haber realizado este logro. A todos ellos, muchas gracias.
8
1 IntroducciónUn sistema de software posee normalmente estructuras que comprenden: sus elementos
de software (por ejemplo, componentes), relaciones entre ellos (por ejemplo, “usos” entre
componentes), y las propiedades de dichos elementos y relaciones [Bass 2003]. Tales estructuras
conforman la arquitectura de software del sistema. Una de las premisas más importantes a tener
en cuenta respecto a una arquitectura de un software, es que debe ser identificada y definida de
manera concisa y desde etapas tempranas para lograr un sistema de calidad y evitar serias
consecuencias como desperdicio de tiempo y recursos (debido a una arquitectura incorrecta). De
esta manera, se debe elaborar una representación de la arquitectura que la modele
adecuadamente y pueda quedar claramente documentada. De hecho, algunos sistemas poseen
una arquitectura compleja, y no puede ser obviada ni representada en forma vaga.
Para el desarrollo de sistemas de software es necesario contar con una especificación de
los requerimientos que debe cumplir tal sistema, de manera tal de asegurarse que se hayan
comprendido las necesidades y objetivos de los stakeholders, y así se puedan alcanzar las
expectativas. Las especificaciones de software suelen contener requerimientos que se refieren a
la funcionalidad de un sistema, ya que es lo primero que tiene en cuenta el cliente o la parte
interesada. Sin embargo, el éxito o fracaso del desarrollo de un sistema de software no está
determinado sólo por los requerimientos funcionales, sino también por los requerimientos no
funcionales o atributos de calidad (QAs). Los QAs, como pueden ser: Usabilidad, Seguridad,
Disponibilidad, Portabilidad, Modificabilidad, o Performance, son requerimientos que hacen
referencia a características de calidad o restricciones de un sistema [Gorton 2011]. La arquitectura
de software de un sistema está determinada por los QAs requeridos para tal sistema. Es por ello
que es imprescindible identificar los QAs durante la captura de requerimientos y tenerlos en
cuenta en la etapa de diseño, para poder tomar las decisiones apropiadas y elegir la arquitectura
correcta que los satisfaga.
El desafío no es sólo identificar todos los QAs involucrados en un sistema de software,
sino también obtener especificaciones concretas de cada uno de ellos. Además, hay QAs que
comprometen a otros QAs de manera negativa, haciendo necesario el análisis de los tradeoffs
arquitectónicos [Smith 1993]
Un atributo de calidad de un sistema de software se puede representar, especificar y
analizar mediante escenarios de calidad. El escenario de calidad es un mecanismo que permite
caracterizar y capturar aspectos de QAs de una forma concreta, que puede ser evaluada y
utilizada en las actividades de diseño, y luego durante el desarrollo. Es así que una arquitectura
puede ser diseñada y evaluada utilizando escenarios de calidad. [Bass 2003]
9
1.1. Problemática
Aunque los QAs pueden ser especificados y documentados mediante escenarios de
calidad, este mecanismo no es utilizado frecuentemente [Shaw 1996]. La tarea de analizar los
requerimientos suele resultar dificultosa para el analista o arquitecto, ya que a menudo tiene que
dedicar mucho tiempo y esfuerzo; además que para lograrlo de manera eficaz debe poseer
experiencia y conocimiento sobre cada uno de los QAs relevados. Otra complicación de obtener
los escenarios de calidad de un sistema, es que los QAs provienen de diversas fuentes, como
objetivos de negocio, entrevistas, especificaciones de requerimientos, etc. Generalmente los
documentos que resultan de la elicitación de requerimientos poseen información de QAs de forma
parcial y dispersa entre las especificaciones funcionales del sistema, lo que hace que puedan
llegar a pasar desapercibidos por el analista [Haak 2005]. De esta manera, hay un riesgo alto de
que ocurran consecuencias negativas tanto en la etapa de desarrollo e implementación, como en
la de mantenimiento del sistema. Además, pueden suceder consecuencias posteriores como:
fallas en el negocio, pérdida de ingresos, aumento del costo del proyecto, relaciones dañadas con
el cliente, entre otras consecuencias. Por ejemplo, las consecuencias de una especificación
equivocada de seguridad en un sistema bancario o financiero pueden resultar en accesos no
deseados a información clasificada, o en vulnerabilidades para potenciales ataques de hackers.
Por otro lado, si hay dos o más QAs en consideración y los mismos no están bien especificados,
podría ser dificultoso y hasta quizás pasarse por alto el análisis de tradeoffs entre los QAs en
cuestión.
Existen diversas propuestas para la especificación y documentación de requerimientos no
funcionales en forma sistemática y eficaz. Por ejemplo, en [Dorr 2003] se presentan métodos
organizados para elicitar y especificar de forma manual QAs, pero demandan tiempo y esfuerzo
de parte de los analistas y arquitectos. Es así que se han considerado técnicas que puedan asistir
a un analista (de forma automatizada) en la tarea de elicitar y especificar QAs. En [Sampaio 2007]
se presenta EAMiner como una técnica semiautomatica para separar Crosscutting Concerns
(CCCs), los cuáles están estrechamente relacionados con los QAs. El enfoque de EAMiner se
basa en procesamiento de lenguaje natural utilizando una matriz para registrar información
linguística y realizar inferencias para identificar abstracciones y CCCs. Además, se ha
desarrollado la herramienta QAMiner [Bertoni 2010] que tiene como objetivo identificar un conjunto
de atributos de calidad candidatos, presentes en los casos de uso de un sistema, basándose en
aspectos tempranos detectados previamente. El enfoque de QAMiner utiliza una ontología que
representa el dominio de atributos de calidad y escenarios de calidad conteniendo relación entre
las palabras y los QAs, y se recurre a técnicas de procesamiento de lenguaje natural. Por otro
lado, se ha desarrollado REAssistant que consiste en una herramienta que, de manera muy
flexible, provee soporte para el desarrollo e integración de técnicas para el procesamiento y
análisis de requerimientos textuales. Los aspectos clave del enfoque propuesto para REAssistant
son la aplicación de una arquitectura de análisis de texto extensible (Unstructured Information
Management) que se compone de varios módulos NLP para procesar los requisitos, el análisis
semántico y la combinación de diferentes estrategias para descubrir concerns automáticamente.
10
De la revisión de la literatura, puede notarse que ninguna de las propuestas logran obtener una
especificación de QAs por medio de escenarios de calidad a partir de los documentos de
requerimientos. Además, las herramientas semiautomáticas que se pueden encontrar suelen
demandar muchos datos de entrada que no siempre están disponibles, mucho tiempo de
procesamiento para grandes volúmenes de información, proveer datos de parte del analista o
herramientas que realicen un preprocesamiento, entre otras demandas. Sin embargo, mediante
avances recientes en materia de procesamiento de lenguaje natural se pueden superar estas
limitaciones combinando NLU (Natural Language Understanding) y NLG (Natural Language
Generation) para construir herramientas semiautomáticas que extraigan información sobre QAs
en documentos de requerimientos y se pueda asistir al analista para generar los escenarios de
calidad correspondientes.
1.2. Enfoque de QAGen
En este trabajo se argumenta que es posible asistir a un arquitecto o analista en la tarea
de especificación de escenarios de calidad, obteniendo información necesaria para detectar los
atributos de calidad (de un medio textual) y generar posibles escenarios de calidad a partir de las
especificaciones de requerimientos. El aprovechamiento de técnicas basadas en procesamiento
de lenguaje natural e información no estructurada permite, en principio, automatizar el análisis de
los documentos disponibles. Es así que se desarrolló un enfoque que tiene como objetivo resolver
el siguiente problema: dado un documento de requerimientos como entrada, obtener elementos
“básicos” para construir posibles escenarios de calidad en base a las descripciones de tales
requerimientos.
La entrada del proceso son los documentos donde se especifican los requerimientos del
sistema, y un diccionario de taxonomías por cada atributo de calidad que puede proveer un
experto del dominio o las fuentes de la literatura. Todas las entradas deben estar en formato de
texto plano. Adicionalmente se puede configurar el enfoque mediante el lenguaje de consultas de
UIMA y definición de extractores para ajustar la detección de QAs y la generación de las
secciones de los escenarios de calidad.
El proceso, básicamente, consta de dos fases, como se muestra en la Figura 1.1. La
primer fase, denominada “Estructuración”, analiza la información no estructurada, y en formato de
texto plano, de manera tal que pueda generarse metainformación y estructuras de datos que
permitan a un sistema de computadora realizar los procesamientos pertinentes. La segunda fase,
denominada “Análisis QA”, se encarga de procesar toda la metainformación para detectar
oraciones y frases que contengan información referente a QAs, de los cuales se extraen datos que
pueden servir para generar las secciones de los escenarios de calidad. Finalmente, aplicando
NLG, se utilizan los datos e información extraídos obtener texto que puede aproximar las
secciones de un escenario de calidad.
11
Figura 1.1: Proceso del enfoque propuesto
La salida es presentada como un formulario típico de un escenario de calidad [Bass 2003],
donde por cada sección se pueden visualizar y seleccionar las distintas frases que podrían
conformar tal sección en un escenario de calidad concreto.
Para aplicar esta técnica se desarrolló un plugin de Eclipse, denominado QAGen, que sirve
como herramienta de software para asistir en la generación de escenarios de calidad. QAGen le
presenta al analista un conjunto de potenciales secciones de escenarios de calidad (Figura 7.1), y
para cada una puede mostrar el contexto dentro del documento de donde se ha extraído la
información que sirvió para inferir tal sección (Figura 7.2). Se pueden validar y descartar las
secciones según corresponda, para finalmente generar escenarios de calidad concretos con dos
estrategias: i) combinatoria entre las potenciales secciones, o ii) seleccionando las que se desean
que conformen un escenario de calidad específico.
Para determinar el desempeño de la técnica se evaluaron los resultados de QAGen
realizando un procedimiento experimental. Tal procedimiento consistió en utilizar como corpus de
entrada los textos de especificaciones para tres casos de estudio para obtener escenarios de
calidad de Performance. Con los escenarios de calidad generados se analizaron las similitudes
con escenarios de calidad de referencia mediante varias métricas obteniendo índices aceptables.
Por ejemplo, con la estrategia de similitud del Coseno, que es una de las más conocidas en
Recuperación de Información, se obtuvieron valores de similitud entre 0,4 y 0,54.
El trabajo realizado presenta diferentes contribuciones al campo de la Ingeniería de
Software. Primero, se desarrolló un modelo para asistir a un analista durante la especificación de
escenarios de atributos de calidad de un sistema. En segundo lugar, para implementar tal modelo,
se definieron reglas y diccionarios para extraer información del atributo de calidad Performance y
se integraron diversas técnicas y componentes de software para funcionar en conjunto.
12
1.3. Organización del Informe
El resto del informe de este trabajo se organiza de la siguiente manera.
En el Capítulo II se explican los conceptos teóricos relativos a atributos de calidad,
especificación de requerimientos, arquitecturas de software y escenarios de calidad.
Adicionalmente, se introducen algunas técnicas y conceptos relacionados al procesamiento de
lenguaje natural y análisis de información no estructurada.
En el Capítulo III se describen y comparan algunos trabajos de investigación en el campo
de la identificación de QAs, y enfoques propuestos para resolver el problema de la especificación
de escenarios de calidad.
En el Capítulo IV se presenta el enfoque QAGen. Se provee una descripción general del
proceso que conforma la técnica y cada componente del proceso desde un punto de vista
arquitectónico. Luego, se realiza una explicación del uso de la herramienta y cómo un analista o
usuario debe interactuar con la herramienta. Finalmente, se detallan las estrategias y heurísticas
actualmente implementadas en la herramienta para las distintas etapas del procesamiento.
En el Capítulo V se presentan los resultados de la evaluación del desempeño de la
herramienta QAGen con distintas especificaciones textuales de requerimientos de tres casos de
estudio. Se exhiben los tiempos de ejecución que se registraron y se analiza la efectividad
comparando con diferentes métricas de similitud con los textos generados y los de referencia.
Finalmente, en el Capítulo VI se presenta las conclusiones del presente trabajo,
mencionando los aportes del enfoque y las limitaciones del mismo. Además, se enumeran algunas
líneas futuras de trabajo en el campo de escenarios de calidad, y también posibles mejoras de
esta propuesta.
13
2 Marco teóricoEn este capítulo se presentan los conceptos principales que se utilizan a lo largo del
desarrollo de este informe. Primeramente, se introducen los conceptos de Atributos de Calidad,
Escenarios de Calidad y Arquitectura de Software. Luego, se describen los conceptos de
Procesamiento de Lenguaje Natural e Información no estructurada, ya que estos suelen
aplicarse para automatizar el proceso de especificación de requerimientos.
2.1. Atributos de Calidad
Los Atributos de Calidad (QAs) son propiedades medibles y evaluables de un sistema,
estas propiedades son usadas para indicar el grado en que el sistema satisface las necesidades
de los stakeholders [Wojcik 2013]. Los QAs además son concebidos como aquellos
requerimientos que no son funcionales. De hecho, la funcionalidad es mayormente ortogonal a los
QAs; un diseño puede cumplir con la funcionalidad deseada y fallar a la hora de satisfacer sus
requerimientos de calidad. De esta manera, se entiende a la funcionalidad como la capacidad del
sistema para hacer el trabajo para el cual fue pensado, independientemente de la estructura.
Existen QAs mayormente usados que se suelen identificar en numerosos sistemas y se
describirán a continuación, aunque la lista no es final ya que muy a menudo hay situaciones en
que podrían identificarse y proponerse nuevas propiedades para las diversas necesidades de
stakeholders.
2.1.1 Performance
El atributo de calidad Performance se refiere a la capacidad de responder, ya sea el tiempo
requerido para responder a eventos determinados, o bien, la cantidad de eventos procesados en
un intervalo de tiempo dado. La Performance caracteriza la proyección en el tiempo de los
servicios entregados por el sistema.
La Performance radica en la naturaleza de los recursos empleados para cumplir las
demandas, y cómo recursos compartidos deben ser asignados cuando se deben considerar
múltiples demandas sobre los mismos recursos. [IEEE 1992]
Un esquema muy conciso y explicativo surge a partir de los trabajos de dos referentes
[Smith 1993] para modelar y describir taxonómicamente las implicancias y conceptos en cuanto a
performance. Este esquema se observa en la Tabla Tabla 2.1
14
Concerns
Latencia
Response windowPrecedenciaJitterCriticality
ThroughputObservation intervalProcessing rateCriticality
CapacidadUtilizationSchedulable utilizationSpare capacity
Modos
Factores
Demanda Arrival patternExecution time
SistemaType of resourcesSoftware servicesResource allocation
Tabla 2.1: Conceptos de performance (adaptado de [IEEE1992])
En la Tabla Tabla 2.1 se sintetizan las características de los concerns propios de
Performance, los cuales se definen a continuación.
Latencia: Cuánto tiempo lleva responder a un evento específico.
Throughput: Cuántos eventos pueden ser atendidos dentro de un intervalo de tiempo.
Capacidad: Cuánta demanda se puede sobrellevar en el sistema mientras se siguen
cumpliendo los requerimientos de latencia y throughput.
Modos: Cómo puede cambiar la demanda y los recursos a lo largo del tiempo. Qué sucede
cuando la capacidad del sistema es excedida y no todos los eventos pueden ser atendidos en la
proyección de tiempo.
2.1.2 UsabilidadEste atributo de calidad se refiere a la facilidad con la que un usuario puede aprender a
utilizar e interpretar los resultados producidos por un sistema [Barbacci 1995]. Para este atributo
de calidad, se suelen considerar diversos aspectos de la interacción humanocomputadora, tales
como: aprendizaje del sistema, utilización eficiente del sistema, minimización del impacto de
errores, adaptación del sistema a las necesidades del usuario, confianza y satisfacción, entre
otros.
2.1.3 ModificabilidadEsta propiedad trata sobre la capacidad de un sistema para que puedan modificarse
diversas propiedades del mismo sobre todo la funcionalidad sin que demande demasiado
15
tiempo, esfuerzo y/o recursos. La mayoría de los sistemas son propensos a que se precise
introducirles cambios, ya sea para actualizarlos porque cambian las reglas de negocio, o
simplemente cambian de parecer los clientes y otros stakeholders. Es la modificabilidad de tales
sistemas lo que determina la facilidad con la que el sistema se pueda adaptar ante dichos cambios
[Bachmann 2007].
Particularmente si los componentes de un sistema están estrechamente dependientes
entre sí (acoplamiento), es muy probable que no sólo haya que realizar grandes modificaciones en
el componente específico al cambio requerido, sino también en otros componentes que no
necesariamente tienen esa responsabilidad; demandando así mayor cantidad de horas de trabajo
de los desarrolladores. Estas incidencias pueden presentarse desde los más altos niveles de
abstracción como componentes y sus conectores; hasta bajo nivel de abstracción como las
interfaces, contratos, estructura y comunicación de los datos, etc.
2.1.4 SeguridadEs el equilibrio entre la confidencialidad, la integridad, la irrefutabilidad y la disponibilidad
de la información y datos manipulados por el sistema. Se trata del estado de un sistema, el cual
puede ser transitorio y volátil. La seguridad de un sistema se caracteriza por mecanismos y
técnicas empleados para intentar reducir los más posible el impacto provocado por un ataque, y
las amenazas (entendidas como los caminos mediante los cuales se pueden provocar un ataque).
Abarca los planos de observación físico, lógico y humanos. Posee tres tipos de enfoque:
prevención, precaución y reacción.
2.1.5 Otras consideraciones sobre QAsPueden encontrarse además muchos otros QAs como portabilidad, configurabilidad,
reusabilidad, testeabilidad, mantenibilidad, etc. Pero la lista puede cambiar a medida que cambian
los paradigmas, evolucionan las tecnologías y las reglas de negocio. Además varios QAs están
estrechamente relacionados entre sí.
Existen grandes comunidades que estudian los diversos QAs, las cuales están en
constante crecimiento investigando y aportando al conocimiento sobre cada uno. Cada comunidad
maneja su propio vocabulario y conjunto de conceptos. [Bass 2003] Por ejemplo términos y
conceptos utilizados en la comunidad de seguridad informática son cifrado, criptografía,
esteganografía, vulnerabilidad, etc. Por otra parte, suelen emplearse los mismos términos para
diferentes QAs por sus comunidades, pero su significado y semántica pueden ser muy distintas;
no es lo mismo riesgo, impacto y contingencia en el ámbito de la seguridad que en el de la
disponibilidad.
Las especificaciones en cuanto a QAs por parte de stakeholders suelen ser indirectas, y
muchas veces pueden aplicar a varios QAs [Wojcik 2013], por ejemplo: "Introduce new
capabilities seamlessly" puede aplicar a Performance, Disponibilidad y Modificabilidad; “Integrate
with other systems easily” puede aplicar a Interoperabilidad, Portabilidad y Modificabilidad.
16
Un gran problema que suele ocurrir en la elicitación de requerimientos, o en la etapa de
diseñar un sistema, es que la especificación de QAs suele estar fragmentada o desestimada, y
debido a esto los sistemas son frecuentemente rediseñados. El mejor momento para especificar
atributos de calidad es antes de establecer la arquitectura de software.[Bass 2003] Sin embargo,
los QAs no sólo deben ser considerados en la elicitación de requerimientos, sino en todas las
etapas de diseño, implementación y deployment. El analista o arquitecto de software debe
capturar, analizar, organizar y documentar los requerimientos, pero muchas veces se dificulta la
correcta identificación de los QAs.
2.2. Arquitectura de Software
Una arquitectura de software es una descripción de las estructuras del sistema, representa
el diseño de alto nivel de un sistema y comprende elementos de software con propiedades y
relaciones entre ellos [Bass 2003]. Es el vehículo de comunicación entre los stakeholders, ya que
provee un lenguaje común en el que los diferentes concerns pueden expresarse, negociarse, y
resolverse a un nivel que es posible dominar intelectualmente, aún para sistemas grandes y
complejos.
Una determinada arquitectura está dictaminada principalmente por sus QAs, y es el primer
artefacto que puede ser analizado para determinar qué tan bien se están cumpliendo sus QAs
[Bass 2003], ya que las decisiones arquitectónicas se basan en ciertos QAs, ponderando así unos
por sobre otros. Es crucial corroborar que el diseño de la arquitectura satisfaga los requerimientos
de QAs antes de la implementación del sistema. Además, es de suma importancia prevenir
diversas problemáticas del ciclo de vida de software que suelen aparecer a posteriori, como por
ejemplo la erosión arquitectónica [Medvidovic 2003].
Durante la construcción de la arquitectura, se deben tomar decisiones de diseño y
plasmarlas en documentos arquitectónicos, como puede ser el Software Architecture Document,
que contendrá información relevante sobre el funcionamiento y la arquitectura del sistema. Dichos
documentos son construidos con el objetivo de que las decisiones de diseño sean tenidas en
cuenta cuando se materialice el sistema.
Existen tres tipos principales de estructuras, a saber: de módulos, de componentes y
conectores, y de asignación. Estas estructuras son una herramienta muy útil para diseñar una
arquitectura, debido a que permiten modelar distintos aspectos de un sistema.
Una arquitectura y los QAs que la caracterizan pueden ser especificados y evaluados por
medio de Escenarios de Calidad.
2.3. Escenarios de calidad
Los escenarios de calidad se pueden definir como requerimientos que indican el grado en
el cual un sistema debe exhibir varias propiedades en una combinación deseada [Bass 2003]. El
escenario de calidad es un mecanismo que permite capturar aspectos de QAs de una forma
concreta, que puede ser evaluada y utilizada en las actividades de diseño, y luego durante el
desarrollo. Los requerimientos de QAs pueden ser capturados como escenarios de calidad, ya que
17
son una forma de representar los QAs de un sistema de una manera formal [Bass 2003]. Cada
escenario de calidad consiste de seis partes o secciones como se muestra en la Figura 2.1, las
cuales se explicarán a continuación.
Figura 2.1: Partes del escenario de calidad
I. Source Es alguna entidad que generó el estímulo.
II. Stimulus El estímulo es una condición o evento que afecta al sistema y necesita
ser considerada.
III. Environment El estímulo ocurre bajo ciertas condiciones.
IV. Artifact Algún artefacto que es estimulado. Esto puede ser el sistema completo o
partes del mismo.
V. Response La respuesta es la actividad que resulta del estímulo.
VI. Response measure Cuando una respuesta ocurre, debe ser medida de alguna
manera, de modo que el requerimiento pueda ser evaluado.
Hay dos tipos de escenarios de calidad: Escenarios Generales, que son aquellos que no
dependen de algún sistema, pero pueden potencialmente pertenecer a un sistema; y por otra
parte los Escenarios Concretos, los cuales son específicos a un sistema en particular que se esté
considerando [Bass 2003]. Cabe señalar que pueden haber escenarios concretos que no posean
las seis secciones.
Por la misma razón que los casos de uso son esenciales para determinar los
requerimientos funcionales, una colección de escenarios de calidad concretos pueden ser usados
para especificar requerimientos de QAs para un sistema en particular. Cada escenario es lo
suficientemente concreto como para tener un significado para el arquitecto, y sus detalles son lo
suficientemente significativos como para evaluar si el sistema ha logrado las características
propias del atributo de calidad [Bass 2003].
En teoría la generación de escenarios de calidad debe realizarse en la elicitación de
requerimientos de un proyecto, pero en la práctica pocas veces es concretada estrictamente. De
hecho los requerimientos de QAs para un sistema rara vez son elicitados de una manera
disciplinada. Esta situación se puede solucionar generando escenarios concretos, utilizando tablas
(templates) específicas a un atributo de calidad para crear los escenarios generales y a partir de
estos derivar los escenarios concretos específicos al sistema. Por cada atributo se presenta una
18
tabla que brinda posibles valores independientes del sistema para las seis partes de un escenario
de calidad. Las tablas sirven de lista de validación para asegurarse que todas las posibilidades
fueron consideradas [Bass 2003], ya que la omisión de algún requerimiento de atributo de calidad
puede tener serias consecuencias.
Por ejemplo si se desea crear un escenario de calidad de performance concreto, cada una
de las seis partes del escenario podrían instanciarse como se muestra en la Figura 2.2. Una vez
decididas las partes correspondientes, es posible generar un escenario de calidad concreto para
un requerimiento no funcional “Users initiate 1,000 transactions per minute stochastically under
normal operations, and these transactions are processed with an average latency of two seconds”
como se observa en la Figura 2.2.
De forma análoga al atributo de calidad performance, se pueden crear distintos escenarios
concretos para los restantes atributos de calidad.
Figura 2.2: Performance scenario sample
Los escenarios de calidad sirven para generar un gran número de escenarios, genéricos,
independientes del sistema que sirven para especificar los requerimientos para un atributo de
calidad en particular. Es entonces que los escenarios deben ser traducidos a escenarios
específicos, es decir con términos concretos del sistema en cuestión. Particularmente, un
escenario general puede tener muchas versiones de escenarios específicos al sistema.
Cabe destacar también que existen enfoques como ATAM [Klein 2000] el cual permite
evaluar las consecuencias de las decisiones arquitectónicas considerando los requerimientos de
atributos de calidad, y para ello utiliza escenarios de calidad organizados por medio de técnicas de
priorización. Se puede decir que la obtención de escenarios de calidad a partir de especificaciones
de requerimientos es determinante para lograr la arquitectura apropiada en siguientes etapas en el
ciclo de vida del software.
19
2.4. Natural Language Understanding (NLU)
El procesamiento de lenguaje natural (NLP por sus siglas en inglés) es un área de estudio
que tiene sus inicios en el mismo momento en que se comenzó a estudiar e investigar la
inteligencia artificial en las ciencias de computación con la publicación de Alan Turing en 1950
[Turing 1950].
NLP se trata de las técnicas computacionales que procesan lenguaje humano hablado y
escrito, desde aplicaciones rudimentarias como contabilización automática de palabras, hasta
aplicaciones sofisticadas (como aquellas que responden preguntas automáticamente y traducción
de lenguaje hablado en tiempo real). Lo que distingue estas aplicaciones de procesamiento de
lenguaje de otros sistemas de procesamiento es su uso del conocimiento del lenguaje. [Jurafsky
2000] Al diseñar un sistema NLP debe definirse el dominio o conjunto de posibles entradas, las
cuales también servirían para realizar pruebas y ejemplos de demostración (por ejemplo
documentos de texto). A tal colección de ejemplos de entrada de datos se la denomina corpus.
NLP se divide en la subárea de interpretación de lenguaje humano (NLU por sus siglas en
inglés), y la subárea de generación de lenguaje natural (NLG por sus siglas en inglés). A NLG
también se la considera entre las tareas semánticas que son parte de NLU.
NLU involucra varias tareas, que suelen aplicarse secuencialmente modeladas como un
pipeline. De las diversas tareas de NLU que existen, las que se han considerado para el presente
trabajo son: Análisis léxico y segmentación de oraciones, lematización y segmentación
morfológica de inflexiones, etiquetado de parte del discurso y análisis gramatical (sintáctico). En
este orden es que mayormente suele ser aplicadas en un pipeline, y cada una será explicada a
continuación.
2.4.1 Análisis Léxico y SegmentaciónPara que a un texto se le aplique procesamiento de lenguaje, lo primero a considerar es
que necesita ser segmentado en unidades lingüísticas tales como palabras, signos de puntuación,
números, formas alfanuméricas. El texto debe ser fraccionado y enriquecido con meta
información, la cual es utilizada para asignar a priori datos de interés y analizarlos a posteriori;
favoreciendo la deducción y relación de información. La unidad básica de texto que puede ser
enriquecida se denomina Token. El análisis léxico también llamado tokenización es el proceso
de convertir una secuencia de caracteres en una secuencia de tokens. Además, es muy útil para
la identificación de unidades que no necesitan ser descompuestas para posteriores
procesamientos, de manera tal que puedan ser descartadas y optimizar el proceso.
Generalmente, la tokenización puede facilitar el análisis sintáctico y gramatical por lo que suelen
combinarse tales procesamientos. A menudo la tokenización es considerada entre las tareas más
simples y que menos se presta atención en idiomas con lenguaje segmentado como inglés y
español. Sin embargo, los errores cometidos en esta subtarea pueden propagarse a tareas
posteriores y afectar mucho los resultados finales. [Craig 2013]
20
Hay varios niveles de granularidad en la segmentación. La granularidad más pequeña es la
que discrimina palabras, signos, números, etc; pero una mayor granularidad de segmentación
suele utilizarse: segmentación de oraciones. Es de especial interés la segmentación de oraciones
cuando se considera a priori llegar a aplicar análisis gramatical, ya que desde el punto de vista
gramatical, la oración es la unidad mínima de sentido.
2.4.2 LematizaciónOtra tarea muy importante dentro de NLP es la lematización, proceso lingüístico que
consiste en dada una inflexión (es decir, en plural, en femenino, conjugada, etc.), hallar el lema
correspondiente. Un lema es la forma que, por convención, se acepta como representante de
todas las inflexiones de una misma palabra1, es decir simplificar las diversas y numerosas
variaciones de morfemas que dependen de un mismo lexema, y finalmente escoger una sola
palabra que represente el significado básico de las diferentes palabras que coinciden en un mismo
lexema (pero difieren en cuanto a sus morfemas).
Por ejemplo, el lexema “señor” puede ser un lema que represente cualquiera de las
palabras "señora” “señoras” “señores” “señorita” Figura 2.3.
Figura 2.3: Ejemplo de lexema y morfemas
Una técnica que suele ser muy útil para aplicar junto con el procesamiento del lenguaje es
clasificar las palabras en taxonomías; también confeccionar tesauros, lista de palabras o términos
controlados empleados para representar conceptos. Al utilizar este tipo de técnicas, es
imprescindible sintetizar la lista de términos utilizando lematización.
2.4.3 Etiquetado gramaticalLa categoría gramatical (POS por sus siglas en inglés) es una clasificación de las palabras
según su tipo. En lingüística computacional, el etiquetado gramatical (conocido también por su
nombre en inglés, partofspeech tagging, POS tagging) es el proceso de asignar (o etiquetar) a
cada una de las palabras de un texto de entrada su categoría gramatical, por medio de
marcadores (por ejemplo anotaciones).
1 https://es.wikipedia.org/wiki/Lematizaci%C3%B3n
21
Estas clasificaciones son útiles debido a la mucha información que brindan sobre una
palabra y sus subyacentes. Saber si una palabra es un sustantivo o un verbo denota sobre las
potenciales palabras subyacentes (por ejemplo los sustantivos son precedidos por determinantes)
y sobre la estructura sintáctica entorno a la palabra. Esto hace que el etiquetado gramatical sea
un componente importante en el análisis sintácticogramatical y también para otras tareas de
extracción de información. La categoría gramatical es además útil cuando se desea sintetizar la
inmensa cantidad de datos que se pueden extraer de un documento, aplicando un filtrado sobre
los datos con una selección de las palabras importantes de tal documento, como los sustantivos o
verbos. Existe una categorización gramatical muy aceptada para el idioma inglés, denominada
Penn Treebank [Mitchell 1993], que consiste en 45 categorías, tal como se muestra en la Figura
2.4. Por ejemplo si una palabra está etiquetada con “VBG”, tal palabra se trata de un verbo en
pasado conjugado en gerundio. O la etiqueta “NNS” se aplicó a una palabra, se trata de un
sustantivo en plural.
Figura 2.4: Categorías gramaticales Penn Treebank
La entrada de un algoritmo de etiquetado es una secuencia de palabras y un conjunto de
etiquetas, y la salida es una secuencia de etiquetas.
Una tarea que debe considerarse en el procesamiento de lenguaje es la desambiguación
[Jurafsky 2000], ya que las palabras suelen ser ambiguas (se les pueden asignar más de un
POS). El desafío del etiquetado gramatical es resolver tales ambigüedades, escogiendo la
etiqueta apropiada para su contexto.
22
2.4.4 Análisis sintácticoLa gramática centra la atención en la oración como unidad mínima de sentido. Es por esto
que para extraer información de un texto y procesarlo debe considerarse el análisis sintáctico, que
consiste en analizar las funciones sintácticas o relaciones de concordancia y jerarquía que
guardan las palabras cuando se agrupan entre sí en forma de sintagmas oraciones simples y
oraciones compuestas de proposiciones mediante una gramática de la lengua en cuestión. Un
constituyente sintáctico es una palabra o secuencia de palabras que funcionan en conjunto como
una unidad dentro de la estructura jerárquica de una oración.
A partir de un análisis sintáctico se puede producir un grafo en el cual cada nodo es una
palabra de la oración y los vértices indican qué relación gramatical hay entre las palabras. Por
ejemplo aplicando una análisis sintáctico a la oración “Bills on ports and immigration were
submitted by Brownback Republican Senator of Kansas” puede producirse el grafo de la Figura
2.5 donde se indica que la palabra “were” se relaciona con la palabra “submitted” como su auxiliar
de voz pasiva.
Figura 2.5: Grafo de análisis sintáctico
2.5. Generación de Lenguaje Natural (NLG)
NLG es un área de la inteligencia artificial y la lingüística computacional, que es concebida
para el desarrollo de sistemas de software que pueden producir textos en lenguaje natural que
pueden ser interpretados por humanos. La producción de texto por NLG se realiza a partir de
alguna representación subyacente de información que no tenga características lingüísticas. Las
tecnologías NLG combinan conocimiento sobre el lenguaje y el dominio de aplicación para
producir automáticamente documentos, reportes, explicaciones, mensajes de ayuda, entre otros
diversos tipos de textos.
Internamente, los sistemas de computadora usan representaciones que son directamente
manipulables por tales sistemas, por ejemplo base de datos sobre aerolíneas, planillas de cálculo
23
contables, etc. En muchos casos, sin embargo, estas representaciones de información requieren
ser interpretados por personas expertas; es así que la gran utilidad de la tecnología NLG es crear
sistemas de computadora que presentan información a personas, y en una representación que les
resulte fácil de comprender.
Las técnicas NLG podrían preferirse antes que la creación manual de documentos porque
pueden incrementar la precisión y reducir el tiempo de actualización, o porque garantizan la
aplicación a estándares [Dale 1995], lo cual es muy aplicable a la creación de escenarios de
calidad.
2.5.1 Corpus NLGEn el contexto de un sistema NLG corpus consiste en ejemplos de textos de salida,
además de textos de ejemplo para ser procesados. Un buen corpus es un recurso muy útil para
adquirir conocimiento cuando módulos específicos de NLG están siendo diseñados; ya que para
hacer un análisis de requerimientos a la hora de diseñar un componente NLG, se recomienda
disponer de un corpus inicial de textos creados por humanos y sus entradas asociadas. En el caso
más simple, el corpus inicial puede ser creado usando ejemplos de textos creados por humanos
que ya hayan sido archivados. Por ejemplo un Corpus de reporte de clima puede ser basado en
reportes reales escritos en el pasado, o también aplica a documentos de especificaciones técnicas
de sistemas similares como escenarios de calidad de software desarrollados anteriormente.
El corpus debe cubrir toda la variedad posible de textos que se esperan producir con el
sistema NLG: incluir casos inusuales tanto como casos típicos. A veces suele ser necesario
solicitar a los expertos del dominio escribir ejemplos de textos de salida apropiados. Por ejemplo
para escenarios de calidad, puede solicitarse a arquitectos y analistas ejemplos de las salidas que
esperan para la generación, o a veces ajustar y retocar los textos que ya se disponen. Puede
implicar mucho esfuerzo elaborar un corpus objetivo, sin embargo, es tiempo bien invertido ya que
un buen corpus facilita el desarrollo de un buen sistema NLG.
Una vez que se dispone del Corpus, las oraciones que contiene deben clasificarse en
alguna de las siguientes categorías: texto que no cambia, datos directamente disponibles, datos
computables y datos no disponibles.
2.5.2 Arquitectura de un sistema NLGDentro de la comunidad NLG hay un consenso en cuanto a seis actividades básicas que
se deben llevar a cabo a lo largo de todo el proceso NLG, desde los datos de entrada hasta el
texto de salida. Estas actividades son Content Determination, Discourse Planning, Sentence
Aggregation, Lexicalization, Referring Expression Generation, Linguistic Realisation.
● Content Determination es el proceso de decidir qué información debe ser comunicada en el
texto, más precisamente qué información necesitan los usuarios para cumplir sus
objetivos. Se deben crear un conjunto de mensajes desde el sistema de entrada o fuentes
subyacentes de datos; estos mensajes son objetos de datos que luego son usadas por los
procesos de generación de lenguaje subsecuentes.
24
● Discourse Planning también denominada Document Structuring es el proceso de definir
un orden y una estructura sobre el conjunto de mensajes a ser transmitidos, su tarea de
lograr estructurar los mensajes producidos por el proceso Content Determination en un
texto coherente. Esto es como el caso cuando se narra una historia, en la cual se tiene un
comienzo, luego nudo, y finalmente desenlace. Una estructuración correcta puede hacer el
texto más fácil de leer.
● Sentence Aggregation es el proceso de agrupar mensajes juntos en una misma oración.
No siempre es necesario, ya que cada mensaje se puede expresar en una oración
separada, pero en muchos casos puede lograr un texto con mayor legibilidad y fluidez.
● Lexicalization es el proceso de decidir específicamente cuáles palabras y cuales frases
deben ser escogidas para expresar conceptos del dominio y relaciones que podrían
aparecer en los mensajes. También se puede lograr un texto con fluidez si se diversifican
las palabras con sinónimos.
● Referring Expression Generation es la tarea de seleccionar palabras o frases para
identificar entidades del dominio. Está directamente relacionada con Lexicalization, pero
referring expression generation es una tarea de discriminación, sobre todo para las
situaciones donde se hace referencia reiteradas veces a una misma entidad dentro del
mismo contexto.
● Linguistic Realisation es el proceso de aplicar reglas de la gramática para producir un texto
que sea correcto sintácticamente, morfológicamente, y ortográficamente. Este proceso
usualmente es visto como el inverso del proceso de parsing, ya que en el mismo se utiliza
una gramática para mapear una oración materializada, a una representación del contenido
semántico de tal oración. En este modelo de parsing inverso, la tarea del Realiser es tomar
como entrada una representación de un contenido semántico de una oración, que es
similar a las representaciones producidas por las salidas de los parsers, y a partir de esto
produce una oración materializada que expresa dicho contenido semántico.
Hay muchas maneras de construir un sistema que realiza las tareas que se describieron, la
más simple es implementar un módulo separado para cada tarea, y conectar estos módulos por
un pipeline de una sóla dirección. Pero desde una perspectiva más pragmática, la arquitectura
más común en sistemas aplicados es un pipeline de tres etapas, a saber: Textplanner, Sentence
planner y Linguistic Realiser ( Figura 2.6).
Textplanner: Esta etapa, también denominada Document Planner, combina las tareas de
Content Determination y Discourse Planning.
Sentenceplanner: Esta etapa combina Sentence Aggregation, Lexicalization, y Referring
Expression Generation. También se la suele llamar Microplanner.
25
Figura 2.6: Arquitectura NLG
2.5.3 Relación de NLG con NLUDesde una perspectiva de investigación NLG es un subarea de NLP, y más aún, NLG está
directamente relacionado con la otra subarea de NLP: Comprensión del Lenguaje Natural (NLU)
que es el estudio de los sistemas de computadora que interpretan lenguajes humanos. Ambos
comparten los mismos fundamentos teóricos y a menudo son utilizados en conjunto dentro de una
misma herramienta de software.
Se puede pensar el proceso de NLG como el inverso de NLU. NLG es el proceso de
mapear a lenguaje humano las representaciones internas de computadora sobre cierta
información, mientras que NLU es el proceso de mapear lenguaje humano a representaciones
internas de computadora. Desafortunadamente, por más intuitiva que sea la idea es difícil
construir sistemas bidireccionales efectivos en la práctica. Esto se debe a que muchos problemas
de NLU no lo son en NLG y vice versa. Por ejemplo, un gran desafío en construir sistemas NLU
reales es la necesidad de manipular una entrada gramaticalmente incorrecta o mal conformada, lo
cual no sería un problema en NLG; mientras que en NLG el gran problema es asegurar que el
texto generado sea fácil de entender para humanos, lo cual es omitido en NLU. Para una tarea en
NLG, a menudo basta con lograr una manera de decir, describir o relatar algo, mientras que
cualquier experimento en NLU tiene que tener en cuenta el hecho que entradas diferentes pueden
tener un mismo significado.
Un obstáculo relacionado para sistemas bidireccionales es que las representaciones que
muchos de los analizadores sintácticos de NLU producen como salida, son bastante diferentes a
26
la entrada que muchos realizers NLG requieren; como es el caso del proceso de parsing. Esta
incompatibilidad básica hace difícil construir un sistema que hace tanto realisation como parsing.
[Reiter 2000]
2.6. Información no estructurada
La información noestructurada se refiere al producto directo de las comunicaciones
humanas. Por ejemplo documentos, correos electrónicos, diálogos, imágenes y videos. Es
información que no fue en principio codificada para ser procesada por máquinas sino generada
por humanos y para humanos. Se define noestructurada porque carece de la semántica explícita
(estructura) como un modelo de datos predefinido requerida para que los programas de
computadora puedan interpretar la información. Esa ausencia de estructura en la información
resulta en irregularidades y ambigüedades que dificultan el procesamiento que realizan tales
programas2. La información no estructurada puede tener una pseudo estructura o aún ser
altamente estructurada pero en maneras que no son anticipadas. Es por esto que este tipo de
información primero debe ser analizada para asignar, al contenido noestructurado, semánticas
específicas de programas de computadora. La estructura añadida provee explícitamente las
semánticas requeridas por los programas de computadora para interpretar los datos
correctamente3.
Los documentos de requerimientos de software son una clase de información es una
definición formal de tipos, propiedades, y relaciones entre entidades que realmente o
fundamentalmente existen para un dominio de discusión en particular. noestructurada donde
puede aplicarse este enriquecimiento de estructuración, para aplicar análisis pertinente que pueda
inferir valiosa información como atributos de calidad. Pero en un gran número de casos no es
cierto que los documentos no tienen metadatos absolutamente. El lenguaje en sí posee una
estructura inherente denominada gramática, ya que la gramática describe cómo se organizan las
palabras dentro de una oración y se relacionan entre ellas, mediante conjunto de reglas y
principios que gobiernan el uso del lenguaje. De esta manera, se puede considerar aplicar al texto
no estructurado un análisis gramático en todos sus niveles: sintáctico, sintácticomorfológico,
léxicosemántico mediante técnicas de procesamiento de lenguaje natural.
2.7. UIMA
Las aplicaciones de Gestión de Información No Estructurada (Unstructured Information
Management UIM) son sistemas de software que analizan grandes volúmenes de información no
estructurada, como texto en lenguaje natural o audio, para descubrir conocimiento que es
relevante para el usuario final.
Una aplicación UIM puede ser consumir texto plano e identificar entidades, tales como
personas, lugares, organizaciones; o relaciones, por ejemplo “trabaja para” o “se ubica en”.
2 https://en.wikipedia.org/wiki/Unstructured_data 3 http://docs.oasis-open.org/uima/v1.0/uima-v1.0.html
27
La Arquitectura UIM (UIMA) es una arquitectura y un framework de software para crear,
descubrir, componer y desplegar un amplio rango de capacidades de análisis multimodal e
integrarlos con tecnologías de búsqueda. Uno de los objetivos de diseño de UIMA es ser
independiente de la modalidad. Por esta razón UIMA no restringe el tipo de datos que puede
funcionar como un objeto de análisis (texto, audio, video, etc), y admite diferentes
implementaciones de la vinculación entre una anotación y la región del artefacto de información;
más aún evita restringirse por la forma original de contenido.
Esta y varias herramientas de NLP definen como “anotación” al tipo de metainformación
que apunta a una región dentro del objeto de análisis (Sofa), generalmente indicada por valores
de desplazamiento (offset). UIMA denomina Analytics a la etapa del proceso que agrega meta
información 4, y lo define como el puente entre el dominio de información estructurada y el dominio
de la información no estructurada como ilustra la Figura 2.7; además provee modelos uniformes
de intercambio de datos, interfaces para componentes y control de proceso, los cuales simplifican
la interoperabilidad de los componentes y facilitan la especificación de pipelines.
Además UIMA tiene integrada una tecnología que sirve para definir reglas de consulta y
creación de anotaciones denominado UIMA Ruta 5.
Figura 2.7: UIMA Analytics
4 https://uima.apache.org/d/uimaj-current/index.html 5 https://uima.apache.org/ruta.html
28
3 Trabajos relacionados Se han dedicado muchos trabajos para proponer enfoques que contribuyan a mejorar y
optimizar la tarea especificación de atributos de calidad. Algunos de estos enfoques se basan en
la inspección manual pero, aunque son concretos y metódicos, pueden llegar a demandar mucho
tiempo y esfuerzo. Es por ello que los últimos aportes se tratan de técnicas y herramientas que
asisten en el análisis de documentos de requerimientos de manera automatizado o semi
automática. Se tratan de diversas técnicas que emplean mecanismos computacionales que
permiten al sistema de computadora extraer y/o deducir información de los textos de
especificaciones de requerimientos. Algunos requieren menos intervención humana que otros, y
cada uno arroja resultados con distintas precisiones. En este capítulo se hace una reseña de los
trabajos que emplean técnicas similares a la que se propone en este trabajo. De esta manera se
podrán comparar entre sí, a la vez que se adquiere un mayor entendimiento de la materia.
3.1. Modelo para la Elicitación y Especificación manual de QAs
El enfoque de [Dorr 2003] propone un modelo con el fin de lograr un conjunto de QARs
(Quality Attribute Requirement) relacionados con el atributo de calidad de “Eficiencia”, en
concordancia con los casos de uso y, si está disponible, la arquitectura del sistema. Dicho
conjunto debe ser mínimo, completo, medible y trazable:
• “Mínimo” se refiere a que solo los QARs relevantes son detectados para no
restringir a la arquitectura prematuramente.
• “Completo” indica que todos los QARs de los stakeholders son identificados.
• “Medibles” significa que se puede verificar mediante una o mas métricas, que
el sistema final satisface el QAR detectado.
• “Trazable” se refiere a que el enfoque propuesto también provee la lógica
efectuada por la cual se identifica cada QAR. Por ejemplo en qué documento o parte
del mismo se identificó la información que fue utilizada para identificar cada QAR.
Los principales conceptos del enfoque están representados en un metamodelo que luego
debe ser instanciado en un modelo de calidad. El metamodelo define a un atributo de calidad (QA)
como una característica no funcional de un sistema, tarea del usuario, tarea del sistema u
organización. La distinción entre diferentes tipos de QAs es importante para el proceso de
elicitación. Cada atributo es elicitado de diferente forma. Además, tanto un atributo como un
sistema pueden ser refinados en más atributos o sistemas y, éste último, se encuentra restringido
por requerimientos arquitectónicos. Existen requerimientos no funcionales (non functional
requirement, NFR) que describen un cierto valor para un QA que debe alcanzarse en un proyecto
específico, limitándolo mediante la determinación de un valor para una métrica asociada. El
modelo distingue entre refinamientos orientados a problemas (refinamientos de NFRs en base a
restricciones de QAs) y refinamientos orientados a soluciones, materializado a través de
29
significados (means), utilizados para satisfacer cierto conjunto de NFRs. En muchas situaciones
un significado describe una solución arquitectónica que satisface cierto atributo de calidad (por
ejemplo, “balanceo de carga” es utilizada para satisfacer un conjunto de atributos de calidad
relacionados con el atributo “distribución de la carga del trabajo”).
Por otro lado, se crea un modelo de calidad (Quality Model) instanciando partes del
metamodelo. El modelo describe refinamientos de QAs de alto nivel en QAs, métricas y
significados más específicos. La idea del modelo es refinar QAs en QAs más medibles; por
ejemplo, QAs en los cuales una métrica puede ser asociada. A su vez describe relaciones entre
distintos QAs, capturando experiencias de proyectos previos.
El enfoque propuesto en este trabajo presenta un modelo de calidad que puede ser
utilizado sin modificaciones pero además permite hacer adaptaciones al contexto de cada
empresa o proyecto y extenderlo para para especificar requerimientos relacionados con otros
atributos de calidad.
3.2. EAMiner
La herramienta EAMiner [Sampaio 2007] se trata de una técnica que ha sido desarrollada
para detectar y separar de manera semiautomática concerns y sus relaciones transversales. Un
Crosscutting Concern (CCC) es cualquier asunto de interés al nivel de requerimientos de software
que puede descomponerse en una unidad del modelo dominante de descomposición [Sutton
2002]. El asunto de interés puede ser por ejemplo producto, proceso, tiempo y costo, etc; y
muchos casos están relacionados con Atributos de Calidad. Los CCC son difíciles de separar y
aislar, ya que a menudo atraviesan transversalmente a varios artefactos u otros concerns. Hay
dos síntomas que indican la presencia de CCC en los artefactos de requerimientos: Scattering
(diseminación) y Tangling (mezcla). Scattering es cuando una responsabilidad como por ejemplo
“seguridad” se encuentra dispersa en dos o más abstracciones que tienen otra responsabilidad
principal. Tangling es cuando una abstracción posee entre sus responsabilidades dos o más que
no son de su alcance exclusivo Figura 3.1.
Figura 3.1: Tangling vs. Scattering
30
Se han definido abstracciones para modularizar CCC denominadas aspectos. Un aspecto
temprano es considerado un aspecto a nivel de requerimientos, entendido como una entidad que
atraviesa transversalmente un concern. El aspecto temprano modulariza responsabilidades que
podrían estar diseminadas entre varios concerns o mezcladas dentro de un mismo concern.
La Ingeniería de Requerimientos orientada a aspectos (AORE, por sus siglas en inglés)
ayuda a lograr eficazmente la separación de CCC al nivel de requerimientos y obteniendo una
mejora en la modularización de artefactos de requerimientos. AORE facilita la creación
composición y evolución de los artefactos de requerimientos. [Rashid 2003] [Whittle 2004]
En AORE las actividades de identificación y análisis son complejas y consumen tiempo. La
identificación es una tarea compleja debido a la gran cantidad de información y la naturaleza
enlazada de las fuentes de requerimientos, tales como transcripciones de entrevistas,
documentación legacy, manuales, etc.
EAMiner utiliza un procesador de lenguaje natural que hace uso de una matriz denominada
WMATRIX [Sawyer 2002] para el preprocesamiento de los documentos de entrada y obtener
información relevante. En WMATRIX se registra la información de etiquetado semántico y parte
del discurso (POS), análisis de frecuencia y concordancias para identificar conceptos del dominio
que pueden ser muy útiles. El análisis semántico agrupa palabras y expresiones relacionadas en
campos semánticos y, a su vez, provee datos estadísticos para distinguir la relevancia de cada
campo. De esta manera WMATRIX es utilizada por EAMiner para realizar inferencias sobre la
identificación de abstracciones y CCC. Finalmente WMATRIX genera un archivo XML que
consiste en el archivo de entrada enriquecido con anotaciones del etiquetado.
EAMiner soporta cuatro actividades de ingeniería de requerimientos: elicitación,
identificación, presentación de resultados y descarte de abstracciones irrelevantes. En la
presentación de resultados se obtiene un modelo interno que puede visualizarse de diferentes
maneras, representados en el modelo AORE seleccionado previamente. Este modelo en la
actividad final puede ser refinado y traducido a un documento de especificación de requerimientos.
Las ventajas de EAMiner son:
a) Ayuda a automatizar las actividades que son propensas a errores y consumen tiempo tales
como identificación de concerns, aspectos tempranos y sus relaciones.
b) Puede proveer fácilmente soporte para el refinado del modelo y para la generación de
especificaciones.
c) Permite que el ingeniero de requerimientos adquiera una comprensión del sistema
mostrando las abstracciones clave y la información relevante.
d) Ayuda a lograr la separación de concerns al nivel de requerimientos, modularizando CCC
como aspectos tempranos.
3.3. QAMiner
La técnica QAMiner [Bertoni 2010] tiene como objetivo identificar un conjunto de atributos
de calidad candidatos, presentes en los casos de uso de un sistema, basándose en aspectos
31
tempranos detectados previamente. Esta herramienta permite al analista seleccionar el aspecto
temprano que desea analizar, junto a los casos de uso que los relaciona para contar con
información acerca de los atributos de calidad identificados para el conjunto de datos de entrada.
Es decir, para cada aspecto temprano del sistema se muestra un ranking de porcentajes con un
atributo de calidad cada uno, indicando el grado de relación entre ese aspecto temprano y los
distintos atributos de calidad presentes en la ontología. De esta manera, el analista puede
seleccionar los atributos de calidad destacados, para tenerlos en cuenta en las etapas siguientes
del ciclo de desarrollo.
Las entradas del proceso son los casos de uso, definidos por el analista, y el aspecto
temprano que los relaciona, previamente identificado por medio de alguna herramienta de
detección de aspectos tempranos, como por ejemplo la herramienta Aspect Extractor Tool [Haak
2005]. Para analizar esto, se utiliza una ontología que representa el dominio de atributos de
calidad y escenarios de calidad, y sirve para consultar el grado de relación de las palabras que
conforman la entrada con los diferentes atributos de calidad.
Figura 3.2: Overview of QAMiner approach
El proceso, básicamente, consta de dos etapas:
1) La primera etapa es Generación de Tokens, en donde se analiza léxica y semánticamente
la información de entrada secuencialmente para representarla en un formato uniforme y
clasificarla. Para esto se utiliza el patrón arquitectónico de Pipes & Filters y se aplican
técnicas de tokenización, unificación de palabras llevándolas a lower case, filtro de stop
words, stemming, conteo de ocurrencias y asignación de pesos basado en la sección del
caso de uso en la que aparezca.
2) La segunda etapa es Análisis de Tokens en donde se realiza el análisis de los tokens
generados por la etapa anterior para calcular, con ayuda de la ontología, el grado de
relación de cada uno de ellos con los diferentes atributos de calidad y, así, generar la
salida.
32
Para representar la salida, se utilizan Quality Attribute Theme (QAT), que están formados
por un subconjunto de los casos de uso y un aspecto temprano, que en forma conjunta hacen
referencia a uno o varios atributos de calidad candidatos. Como resultado, se proporciona una
lista priorizada de QATs que resume los concerns y atributos de calidad candidatos de una
especificación de requerimientos.
3.4. REAssistant
REAssistant [Rago 2014] es una herramienta flexible, que fue desarrollada como un
conjunto de plugins de Eclipse y cuenta con el soporte arquitectónico del framework UIMA para
procesar variadas fuentes de texto con el fin de descubrir crosscutting concerns latentes en
especificaciones de casos de uso. La principal contribución de esta herramienta es su soporte
para el desarrollo e integración de técnicas para el procesamiento y análisis de requerimientos
textuales.
Los aspectos clave de la técnica propuesta para REAssistant son la aplicación de una
arquitectura de análisis de texto compuesta por varios módulos de Natural Language Processing
para procesar los requisitos, el análisis semántico y la combinación de diferentes estrategias para
descubrir concerns automáticamente.
Figura 3.3: Overview of REAssistant approach
REAssistant presenta tres objetivos específicos:
1) Separar el análisis del texto de las técnicas de detección de CCC para crear una solución
más simple y más flexible, donde los usuarios puedan utilizar más de una técnica para
detectar concerns, con estrategias de búsqueda pas adaptadas a sus necesidades.
2) El segundo objetivo es mejorar la forma en que las herramientas actuales inspeccionan los
requerimientos textuales, incluyendo mejoras en el análisis semántico de las oraciones,
para evitar algunas fallas de los enfoques existentes y descubrir información más relevante
sobre las CCC.
33
3) El tercer objetivo es emplear una arquitectura de procesamiento de texto extensible, que
pueda manejar una variedad de análisis de texto. Esto no sólo contribuye a la flexibilidad
de la herramienta, soportando nuevos módulos de NLP o el intercambio de los mismos,
sino que también permite a los analistas personalizar las técnicas de descubrimiento de
concerns (por ejemplo: ajustar ciertos módulos de NLP particulares) para diferentes
dominios de software.
REAssistant utiliza tecnologías como Eclipse PDE, EMF, UIMA, entre otras. En particular,
UIMA es usado como base para el procesamiento de lenguaje natural, para realizar un análisis
robusto y extensible.
REAssistant incluye varios módulos para identificar conceptos relevantes de los
requerimientos, entre ellos componentes de NLP y módulos que se centran en el análisis
semántico del texto para la identificación de concerns ( Figura 3.3).
Específicamente dos técnicas que aprovechan las anotaciones semánticas y automatizan
la búsqueda de concerns:
1) La primera técnica utiliza un inventario de sentido y medidas de similitud semántica en
combinación con técnicas de agrupamiento para detectar comportamientos recurrente en
los documentos. La principal ventaja de esta técnica es que la intervención del analista es
mínima, proporcionando una rápida visión inicial de los concerns de un sistema.
2) La segunda técnica utiliza un lenguaje de consulta que puede interpretar las salidas de los
análisis NLP para descubrir concerns específicas, por separado. Las ventajas de esta
última técnica es que los analistas pueden participar en la definición de las mismas,
haciendo posible ajustar la herramienta a sus propósitos particulares. Además, se pueden
codificar interpretaciones semánticas de las oraciones en las consultas, permitiendo
detectar incidencias más sutiles de los concerns.
3.5. Scenarios Tool
En la práctica, la información sobre atributos de calidad de la mayor a de los proyectos deı ı
software suele documentarse de forma parcial y entremezclada con las especificaciones
funcionales del sistema [Shaw1996]. ScenariosTool es un enfoque de derivación de escenarios de
calidad, materializado en una herramienta desarrollada en Java, con una interfaz gráfica que
permite al arquitecto ingresar las partes del escenario parcial que conoce y seleccionar la parte
faltante a inferir por la misma. Una vez generados los resultados, se muestran en forma tabular en
la sección de resultados, de donde el arquitecto puede utilizar la información brindada para
completar la documentación sobre un sistema en particular.
El objetivo principal de este enfoque es utilizar técnicas de Inteligencia Artificial para poder
asistir de forma semiautomática a un arquitecto en la especificación de escenarios de atributos de
calidad.
34
El enfoque se encuentra dividido en dos etapas: de aprendizaje y de razonamiento Figura
3.4. Tal enfoque requiere un conjunto de información como entrada para conformar la fuente de
conocimiento, que consiste principalmente de libros de arquitecturas de software, papers
científicos, guías de diseño, entre otros. Además, se requiere una colección de escenarios de
atributos de calidad completos como assets, especificados completamente y son brindados al
enfoque por un experto. Los escenarios son utilizados como referencia para obtener información
de escenarios especificados parcialmente.
Figura 3.4: Esquema de funcionamiento
Ante la consulta de un arquitecto respecto a un escenario de atributos de calidad
incompleto, el enfoque produce sugerencias a partir de un razonamiento mediante analog a entreı ı
los escenarios completos de referencia y la información aprendida por la computadora. Este
razonamiento mediante analog a establece relaciones entre partes especificadas de escenarios deı ı
atributos de calidad de tal forma que sea posible inferir partes faltantes. Las sugerencias
brindadas pueden ser utilizadas por el arquitecto para completar de forma apropiada los
escenarios del sistema que está desarrollando.
1) La primera etapa, denominada ‘Aprendizaje’, tiene como objetivo aprender relaciones entre
las diferentes partes de los escenarios de atributos de calidad a partir de la fuente de
conocimiento brindada como datos de entrada. Para lograr esto, se utilizan dos
componentes:
I) El primero realiza un preprocesamiento de texto de la fuente de conocimiento donde
se aplican técnicas de eliminación y modificación de caracteres para dar formato a la
entrada, unificarla y eliminar datos no relevantes.
II) El segundo componente toma como entrada los datos preprocesados y genera como
salida un modelo compuesto por todas las palabras que componen la fuente de
35
conocimiento, junto a una representación vectorial de cada palabra, que la describe en
términos de su contexto y cantidad de apariciones en la fuente de información. Para la
implementación de este componente, se utiliza un framework externo, denominado
word2vec [Mikolov 2013]. Esta representación es útil para poder realizar operaciones
algebraicas entre las palabras permitiendo, por ejemplo, medir la distancia entre ellas,
ya que son representadas mediante vectores numéricos.
2) La segunda etapa, denominada ‘Razonamiento’, es la encargada de utilizar el modelo de
tal forma que se puedan extraer datos relativos a información faltante o incompleta de
escenarios de atributos de calidad. En esta etapa se utilizan el modelo generado
previamente y el conjunto de escenarios de atributos de calidad de referencia como assets,
brindados al enfoque una sola vez por un experto. Como entrada para esta etapa, el
arquitecto ingresa un escenario incompleto y el componente de recomendación completa
la información faltante del escenario ingresado conformando la salida.
3.6. Resumen
Los trabajos presentados proponen diversas herramientas y estrategias que de una u otra
manera ayudan en la especificación de atributos de calidad. La gran mayoría recurren a técnicas
del área de la Inteligencia Artificial o subáreas de ésta (como el procesamiento de lenguaje
natural). Si bien los resultados que obtienen no son totalmente precisos y certeros, no dejan de
ser un aporte y contribución en la resolución de problemática, sobre todo porque logran reducir los
tiempos de procesamiento y principalmente de la inspección manual de los documentos.
36
4 QAGen: Un Enfoque paraGeneración de Escenarios de Calidad
El problema a resolver es el siguiente: dado un documento de requerimientos como
entrada (input), se deben obtener elementos para construir escenarios de calidad en base a las
descripciones de tales requerimientos (output). La combinación de técnicas NLP y NLG posee
potencial para lograr herramientas de software semiautomáticas que puedan asistir al analista en
la exploración de escenarios de calidad. Se plantea una técnica, y una herramienta que la
implementa denominada QAGen (Quality Attribute Scenario Generation), la cual logra el objetivo
procesando los documentos de requerimientos texto no estructurado con un análisis sintáctico y
morfológico, para obtener información estructurada que provea los datos necesarios y así deducir
atributos de calidad y los elementos que componen los escenarios de calidad. Actualmente se
dispone de herramientas que identifican atributos de calidad y crosscutting concerns, y QAGen
realiza un aporte al detectar no sólo información de atributos de calidad sino también facilitar la
generación de escenarios de calidad candidatos a partir de dichos atributos de calidad.
La técnica propuesta se divide en dos fases que están compuestas etapas, las cuales
conforman un pipeline incremental de procesamiento, como se muestra en la Figura 4.1. En la
primera fase, llamada “Estructuración”, se enriquece el texto con anotaciones básicas para
permitir el análisis y cómputo de información; y en la segunda fase, denominada “Análisis de QA”,
se utiliza la metainformación recolectada en la fase anterior para generar potenciales secciones
de escenarios de calidad que, una vez validadas por el analista, constituyen los escenarios
concretos.
En la primera fase, la etapa que realiza el enriquecimiento propiamente dicho, llamada
“Preanálisis”, se añade el lema (inflexión más básica) y el POS (part of speech) al token de cada
palabra; pero esta etapa requiere una tokenización rudimentaria, es decir que el texto haya sido
marcado con los token más básicos (sin metainformación), lo cual lo realiza la etapa previa
denominada “Segmentación”. En la segunda fase, la primera etapa es “QAMining”, que identifica
las porciones de texto (oraciones) de donde se puede extraer información útil para los escenarios
de calidad; y la siguiente etapa, “Scenario Linking”, utiliza estas porciones de texto para generar
las secciones de escenarios de calidad.
37
Figura 4.1: Fases y etapas del pipeline de QAGen
4.1. Uso de QAGen para generar escenarios de calidad
La herramienta QAGen está diseñada para asistir a los analistas en la generación de
escenarios de calidad, tomando como entrada los documentos de requerimientos más un
diccionario de taxonomías y generando uno o más escenarios como salida, que se puede
visualizar en la misma herramienta.
El analista debe facilitar los documentos en texto plano, con un preprocesamiento mínimo
para eliminar caracteres extraños, como por ejemplo viñetas o íconos, y estructuras como son las
tablas, para simplificar la segmentación de los mismos. Por otro lado, el mismo debe proveer los
diccionarios, los cuales contienen listas de palabras para indicar por ejemplo conceptos referidos a
contraints, events, time, etc. Con estos datos de entrada el pipe principal de QAGen genera los
archivos resultantes con los scenarios sections, como se puede ver en la Figura 4.2.
Cada scenario section, generado automáticamente, posee diferentes oraciones candidatas
para cada parte del escenario. Estas se pueden editar, ver el contexto de donde fueron extraídas
en el documento original y seleccionarlas para generar manualmente los los escenarios de calidad
propiamente dichos, como salida final del proceso.
38
Figura 4.2: Proceso completo de QAGen
4.2. Herramientas de desarrollo de software escogidasExisten varias herramientas de desarrollo de software que facilitan la implementación de
aplicaciones de procesamiento del texto no estructurado. Una de las más populares, y que ha sido
aceptada por una gran comunidad, es Apache UIMA (Arquitectura para Gestión de Información
No Estructurada), que permite descomponer las aplicaciones en componentes que implementan
interfaces definidas por el framework y provee metadatos autodescriptivos por medio de archivos
XML. El framework administra estos componentes y el flujo de datos entre ellos, y permite
configurar y ejecutar un pipeline de componentes llamados Annotator. Estos componentes hacen
el verdadero trabajo de analizar la información no estructurada. Los usuarios pueden escribir sus
propios anotadores, o configurar y utilizar anotadores preexistentes.
Se define como anotación al tipo de metainformación que apunta a una región dentro del
objeto de análisis (Sofa), generalmente indicada por valores de desplazamiento (offset). UIMA
provee modelos uniformes de intercambio de datos, interfaces para componentes y control de
39
proceso, los cuales simplifican la interoperabilidad de los componentes y facilitan la especificación
de pipelines.
UIMA tiene integrada una tecnología que sirve para definir reglas de consulta y creación de
anotaciones denominado UIMA Ruta. Se trata de un componente que consiste de dos partes: un
Motor de Análisis (Analysis Engine), que interpreta y ejecuta un lenguaje imperativo de scripting
basado en reglas; y un conjunto de herramientas para el IDE Eclipse, las cuales proveen soporte
para el desarrollo de las reglas. Cada regla define un patrón de anotaciones con condiciones
adicionales. Si el patrón se aplica, entonces las acciones de la regla son realizadas sobre las
anotaciones seleccionadas. Las condiciones especifican restricciones adicionales que el texto
seleccionado o las anotaciones deben cumplir. Las acciones definen las consecuencias de la
regla, y suelen utilizarse para crear nuevas anotaciones o modificar las existentes. Esta es una
herramienta que permite aplicar sofisticados procesamientos de manera incremental, por lo que es
muy adecuada para implementar la fase más avanzada de QAGen, Análisis QA.
Otra herramienta muy difundida es ClearTk [Bethard 2014], un framework para desarrollo
de componentes para procesamiento de lenguaje natural a través de UIMA, creado por un centro
de investigación de la universidad de Colorado. ClearTk provee módulos de UIMA para utilizar
frameworks y bibliotecas de terceros, externos a UIMA, como por ejemplo: Snowball stemmer,
OpenNLP, Berkeley syntactic parser, ClearNLP, Stanford CoreNLP, entre otras bien conocidas y
aceptadas en el ámbito de NLP. Cada componente que se desarrolla con ClearTk es extensible y
con alta reusabilidad, lo que permite implementar nuevos componentes más específicos y
optimizados para resolver y procesar información en contextos muy similares a los objetivos del
presente trabajo. ClearTk permite que la implementación de la fase inicial, de estructuración,
pueda llevarse a cabo de una manera robusta, simple y eficaz; permitiendo probar e intercambiar
la disposición de los componentes que conforman el pipeline.
Para el desarrollo de software que involucra generación de texto, se dispone de algunos
frameworks de NLG (natural language generation) como SimpleNLG [Gatt 2009] , que es uno de
los que más se adecua a los fines del proyecto. Este framework puede verse como un “realization
engine” cuyo propósito es proveer simples y robustas interfaces para generar estructuras
sintácticas, y alinearlas mediante un mecanismo sencillo.
4.3. Proceso y etapas de QAGenLas etapas en las que se divide el proceso de QAGen están compuestas por actividades,
las cuales se explicarán detalladamente a continuación.
Los documentos de especificaciones de requerimientos son ingresados al proceso, por lo
tanto son el input de la primer etapa, y estos documentos escritos en lenguaje natural son
procesados para llevarlos a una representación interna adecuada para facilitar el análisis y
cómputo automatizado de la información, generando estructuras de datos y aplicando relaciones
lógicas a dichas estructuras de manera incremental. Para ello se utilizan técnicas basadas en
NLP. El texto es fraccionado y enriquecido con metainformación, representada como estructuras
de datos que poseen varios atributos, los cuales son utilizados para asignar a priori datos de
40
interés y analizarlos a posteriori; favoreciendo la deducción y relación de la información. La unidad
básica de texto que puede ser enriquecida se denomina token.
A continuación se enumeran cada una de las etapas que componen todo el procesamiento
(Figura 4.2) junto con y las actividades que contienen:
1) Etapa de segmentación
◦ Sentence Split
◦ Tokenization
2) Etapa de preanálisis
◦ POS Tagging
◦ Lemmatization
3) Etapa de QA Mining
◦ QAW Tagging
◦ QAS Tagging
4) Etapa de Scenario Linking
◦ Dependency Parsing
◦ Microplanner
◦ Scenario Sections
Como prueba de concepto, se escogió “performance” como atributo de calidad para
ejemplificar, realizar pruebas y explicar todo el proceso, ya que es uno de los atributos más
comunes, pero complejo en cuanto a diversidad. A continuación se presenta un conjunto de
oraciones que contienen información de atributos de calidad performance de donde se puede
extraer la información para los escenarios de calidad:
Las oraciones de arriba conformarán un ejemplo guía que también servirá para la
explicación del proceso. La primer oración fue extraída del documento de requerimientos del caso
41
a) The system shall provide access to the legacy course catalog database with no more than a 10 second latency.
b) The alarm is displayed on the user interfaces of all users that must receive the alarm within 3 seconds.
c) When the FSS updates a value either by itself or after executing a command that it received from MSLite it publishes a COV event.
d) If the FSS fails to execute a command that it received, and notifies MSLite, then the UI must be updated to reflect the failed command.
e) Only relevant GUI screens for these ‘m’ users will reflect the update within having received the notification from the FSS.
de estudio Course Registration System y el resto de las oraciones del caso de estudio MSLite.
[Brown 2011] [Mullick 2006]
Figura 4.3: Fase Estructuración con sus etapas
4.3.1 Etapa de segmentaciónLo primero a realizar en esta etapa es fraccionar el texto no estructurado en oraciones, lo
cual se lleva a cabo en la primera actividad, denominada Sentence split. El procesamiento de
lenguaje natural considera a la oración como la unidad de análisis de análisis, claramente es de
importancia crucial asegurarse que, dado un texto, se pueda fraccionar en fragmentos de
oraciones [Dale 2000].
La segunda actividad de esta etapa – tokenization consiste en fraccionar el texto en
tokens. Es así que se logra un preprocesamiento del texto que provee la infraestructura necesaria
para análisis y procesamientos ulteriores, y más sofisticados (Figura 4.3).
La actividad Sentence Split es implementada utilizando SentenceDetector, un segmentador
de oraciones de OpenNLP. El anotador TokenAnnotator de ClearTK implementa la actividad
Tokenization, tomando como entrada texto ya enriquecido con anotaciones Sentence.
4.3.2 Etapa de pre-análisis La segunda etapa, considerada como de preanálisis, realiza un procesamiento léxico
gramatical. En una primera actividad, etiqueta cada unidad del texto como un token que contiene
información lingüística denominada Parte del Discurso (POS tagging). Se trata de categorizar
cada palabra según sus propiedades gramaticales, por ejemplo: verbo, adverbio, sustantivo, etc.
Las palabras que tienen asignado el mismo POS generalmente demuestran el mismo
comportamiento en términos de sintaxis y morfología.
La segunda actividad de esta etapa consiste en llevar cada palabra a una representación
genérica de manera tal que se puedan unificar palabras que difieren en su secuencia de
42
caracteres pero se refieren a un mismo concepto, simplificando en gran manera el análisis y
procesamiento en actividades subsiguientes. Una técnica para lograrlo es el stemming, que consta
en reducir una palabra a su raíz (parte que no cambia morfológicamente), pero opera en una
palabra individual sin conocimiento de su contexto, por lo tanto no puede discriminar entre
palabras que tienen diferentes significados según su “parte del discurso”. Por su simpleza la
ejecución del stemming es veloz, sin embargo su falta de precisión puede resultar en ineficacia del
proceso6 . Es así que se decidió utilizar una técnica más sofisticada y eficaz: la lematización,
proceso lingüístico que consiste en, dada una inflexión (es decir, en plural, en femenino,
conjugada, etc.), hallar el lema correspondiente. Algunos ejemplos son: "interrupts" > "interrupt",
"delivered" > "deliver", "simplest" > "simple", "simpler" > "simple", "matching" > "match",
"celebrities" > "celebrity".
Formalmente, se define el token TOKEN<begin, end, pos, lemma>; una instancia del
mismo sería por ejemplo: ALARM<65305, 65310, NN, alarm>. Cada token posee un
desplazamiento que indica dónde encontrar el inicio y el fin de la porción de texto que representa.
En la Tabla Tabla 4.1 se esquematiza el resultado de aplicar a la oración de ejemplo b) el proceso
POS tagging.
The alarm is displayed
BEGIN 65301 65305 65311 65314END 65304 65310 65313 65323POS DT NN VBZ VBNLEMMA the alarm be display
Tabla 4.1: Ejemplo de POS tagging
La fase POS tagging se concreta con el anotador PosTaggerAnnotator, un etiquetador de
partedeldiscurso perteneciente a OpenNLP. La lematización se realiza con MpAnalyzer, un
analizador morfológico de ClearTk que toma palabras y sus anotaciones POS como entrada y
genera lemas de tales palabras.
Los documentos se cargan con el lector de colección UriCollectionReader y luego es
preparado como primer entrada del pipeline con UriToDocumentTextAnnotator.
Finalmente, de la salida del pipeline se obtiene un CAS (Estructura de análisis común) de
texto enriquecido con toda la metainformación propicia para aplicar procesamientos y análisis
mas específicos. Este CAS es serializado y guardado en un archivo XMI.
6 https://en.wikipedia.org/wiki/Stemming
43
Figura 4.4: Fase Análisis QA con sus etapas
4.3.3 Etapa de QA MiningEn esta tercera etapa ya se dispone de la metainformación resultante del procesamiento
genérico y del texto no estructurado, y es aquí donde se realiza el análisis específico para la
identificación de atributos de calidad. Como la gramática centra la atención en la oración como
unidad mínima de sentido, el objetivo es identificar aquellas oraciones que puedan contener
información para los escenarios de calidad a generar.
La primera actividad, QAW tagging, tiene el propósito de identificar tokens que estén
estrechamente relacionados con algún atributo de calidad en particular. Cada uno de estos tokens
es identificado al encontrar alguna de las palabras clave que caracteriza el concepto que pretende
representar dicho token. Esas palabras clave son agrupadas en diccionarios de taxonomías y
ontologías propias del atributo de calidad en cuestión.
Por ejemplo, para el atributo de calidad “Performance”, se definieron los siguientes tokens:
tokenTime, tokenLTD, tokenStart, tokenEnd, tokenConstraint y tokenEvent.
La Tabla Tabla 4.2 contiene las palabras clave que identifica tokenConstraint.
Constraintaccuracy latency precedence respond criticality deadline response demand mustresponsiveness exceed simultaneous overload
Tabla 4.2: Palabras clave de la taxonomía Constraint
44
Tales diccionarios se construyeron en base a conceptos, definiciones y relaciones
extraídas de IEEE Standard for a Software Quality Metrics Methodology [IEEE 1992], y a cada
palabra que lo integra se le aplica el procesamiento de lematización (explicado en el apartado
anterior) para adecuarlo a esta actividad.
Es indispensable aplicar técnicas de desambiguación, y la lematización aporta mucho al
respecto, pero pueden haber casos particulares que deben ser contemplados de manera
específica. Por ejemplo la palabra "segundo" puede referirse a posición o a unidad de tiempo; es
una cuestión sintáctica que se puede resolver considerando el contexto de la palabra, en este
caso si la palabra la precede un número puede deducirse que se está hablando de unidad de
tiempo.
El resto de palabras clave para identificar Tokens de performance están contenidas en
tokenEvent (Tabla Tabla 4.3), tokenLTD (Tabla Tabla 4.4) y tokenTime (Tabla Tabla 4.5).
LTD
latency after bandwidth throughput between frequency demand start stream interval end arrival before since rate
Tabla 4.3: Palabras clave de la taxonomía LTD
EVENT
event arrive sampling transaction process deliver
interrupt calculation accessupdate complete display
Tabla 4.4: Palabras clave de la taxonomía Event
TIME time less minute
within time hour
Tabla 4.5: Palabras clave de la taxonomía Time
En la siguiente actividad, QAS tagging, el objetivo es identificar oraciones que estén
estrechamente relacionadas con algún atributo de calidad en particular. Las oraciones se
identifican al cumplirse ciertas reglas y condiciones semánticológicas cuya definición es propia a
cada atributo de calidad. Dichas reglas son muy diversas y varían mucho en efectividad y
complejidad.
Continuando con el ejemplo de performance, una oración se marca con la anotación
performanceSentence si se cumple alguna de las siguientes condiciones:
45
I. Contiene un tokenEvent y un tokenTime.
II. Contiene un tokenEvent y un tokenLTD.
III. Contiene un tokenEvent, un tokenStart y un tokenEnd.
IV. Contiene un tokenEvent y un tokenConstraint.
V. Contiene un tokenConstraint y un tokenTime.
VI. Contiene un tokenConstraint y un tokenLTD.
La regla (I) identifica los casos de oraciones que describen un evento que afecta al
sistema, y en la misma oración hace mención a algún concepto de tiempo, pero el caso (III) en la
misma oración haría mención a comienzo y fin de dicho evento.
La última regla se aplica a la oración que contiene conceptos de latencia, rendimiento o
demanda y, a su vez, se halla algún concepto de restricción estricta.
Es fundamental idear combinaciones de reglas que sean exhaustivas en los casos que
aplican, pero sin redundancia, ya que elevaría la complejidad innecesariamente. Es muy posible
que alguna combinación no tenga sentido, es decir, que no aporte a la detección de un atributo de
calidad en ningún caso o que directamente sea absurda (por ejemplo: contradicción, casos
excluyentes, etc).
Estas son sólo una de las tantas combinaciones lógicas que podrían favorecer a la
identificación de un atributo de calidad, siendo un desafío desarrollar aquellas que contemplan
otras combinaciones aún más efectivas. Por eso es indispensable disponer de una herramienta
que facilite la definición de reglas como UIMA Ruta Workbench.
En la Figura 4.5, se observan con los ejemplos de performance que en a) se cumplen las
reglas (I) y (II), en b) se cumplen las reglas (I) y (IV), en c) se cumple (I), en d) se cumple (IV), y en
e) se cumple (I):
a) The system shall provide access to the legacy course catalog database with nomore than a 10 second latency.
b) The alarm is displayed on the user interfaces of all users that must receivethe alarm within 3 seconds.
c) When the FSS updates a value either by itself or after executing a command thatit received from MSLite it publishes a COV event.
d) If the FSS fails to execute a command that it received, and notifies MSLite,then the UI must be updated to reflect the failed command.
e) Only relevant GUI screens for these ‘m’ users will reflect the update withinhaving received the notification from the FSS.
Referencias de tokenEvent LTD Time
Constraint
Figura 4.5: Resultado de aplicar las reglas a las oraciones de ejemplo de performance
46
El objetivo de esta etapa es identificar oraciones candidatas y cada una de las anotaciones
que la componen es requisito necesario, pero no suficiente, para lograr una eficaz detección de
atributos de calidad. Es de suma importancia evitar o minimizar los falsos positivos, es decir,
aquellas secciones del texto que pueden ser identificados y anotados con alguna regla pero que
en realidad no aplican. Es uno de los mayores desafíos de NLP distinguir similares construcciones
lingüísticas complejas pero que tienen una semántica e interpretación muy diferente.
Suele ser de gran utilidad recurrir a la desambiguación, debido a los numerosos
potenciales casos donde puede hallarse una misma palabra con varios significados que hacen
referencia a conceptos muy distintos. Por ejemplo, la siguiente oración posee la palabra "second",
que puede referirse a posición o tiempo, y puede generar un falso positivo ya que si se interpreta
como tiempo hace referencia a un concepto de Performance.
The employee provides the data to be updated: Name, New password
(with second password field for confirmation), and Current password.
Ningún procesamiento tiene completa efectividad ni total precisión, por eso en una
determinada etapa pueden generarse numerosas anotaciones que pueden complicar a ulteriores
etapas del procesamiento. Es prudente descartar aquellas anotaciones inertes antes de avanzar a
la siguiente etapa del pipeline.
4.3.4 QA Mining con UIMA Ruta
En el script desarrollado con UIMA Ruta, primero se realiza una desambiguación de una
palabra clave para este atributo de calidad, y se trata de distinguir si la ocurrencia de la palabra
"segundo" se refiere a tiempo o a posición. Para el último caso, la lematización lo normaliza con la
etiqueta especial #ord#; y para el caso de interés (tiempo) se crea la etiqueta #time#, la cual es
identificada si la palabra está precedida de un número. Esto se logra con la siguiente sentencia:
NUM Token{REGEXP(".*second[s]?", true)->Token.lemma="#time#"}
Se consideraron listas de palabras clave que hacen referencia a un concepto específico de
Performance. Se definen reglas que analizan si el atributo "lema" de cada Token coincide con
alguna de las palabras clave definidas en la lista de taxonomías de un concepto (las cuales deben
ser palabras ya lematizadas y cargadas previamente). En caso afirmativo se genera la anotación
correspondiente a ese concepto. Por ejemplo, para generar anotaciones "tokenConstraint" se
define la siguiente regla:
Token{INLIST(kwds_constraint,Token.lemma) -> MARK(TokenConstraint)}
47
También se implementan las respectivas reglas para los demás conceptos de
Performance, que son: tokenTime, tokenLTD, tokenStart, tokenEnd, y tokenEvent.
Es muy posible que sea necesario definir conceptos que son referidos por una sola palabra
puntual, en cuyo caso se pueden utilizar expresiones regulares, como para las anotaciones
tokenStart y tokenEnd:
Token{REGEXP("start", true) -> MARK(TokenStart)}Token{REGEXP("end", true) -> MARK(TokenEnd)}
Se define una misma regla para marcar una oración con la anotación
performanceSentence si se cumple alguna de las condiciones definidas en el apartado 4.3.3; por
ejemplo la condición a) Contiene un tokenEvent y un tokenTime. Con que se cumpla al menos una
de las 6 condiciones, se generará la anotación. Por lo tanto, todas las condiciones se relacionan
entre sí disyuntivamente con la siguiente regla:
Es adecuado para optimizar los procesamientos siguientes, más específicos y sofisticados;
realizar una limpieza de postprocesamiento para eliminar los falsos positivos, anotaciones
candidatas y vestigios generados por actividades anteriores. También se debe tener en cuenta la
minimización de los tiempos de procesamiento en grandes volúmenes de texto.
4.3.5 Etapa de Scenario LinkingPara el inicio de esta etapa ya se ha localizado el texto de donde se puede extraer la
información para deducir secciones de escenarios de calidad. Consecuentemente el desafío en
este punto es aplicar el análisis adecuado a dicho texto para realizar la extracción propiamente
dicha, y luego utilizar esa información para instanciar escenarios concretos de calidad. Es aquí
donde se presenta una situación apropiada para sacar provecho de la combinación de técnicas
NLP conjuntamente con técnicas NLG.
48
Sentence{OR( AND (CONTAINS(TokenEvent), CONTAINS(TokenTime)), AND (CONTAINS(TokenEvent), CONTAINS(TokenConstraint)), AND (CONTAINS(TokenEvent), CONTAINS(TokenLTD)), AND (CONTAINS(TokenEvent), CONTAINS(TokenStart),
CONTAINS(TokenEnd)), AND (CONTAINS(TokenTime), CONTAINS(TokenConstraint)), AND (CONTAINS(TokenLTD), CONTAINS(TokenConstraint)) ) -> MARK(PerformanceSentence)
}
El subsistema NLG permite ensamblar oraciones y frases mediante operaciones donde se
indican los lemas que conformarán construcciones lingüísticas, y componer la sintaxis y
morfología del texto de salida.
Al identificar las oraciones que poseen información de atributos de calidad, se deben
analizar de manera tal que se pueda inferir elementos para escenarios de calidad. La estructura
lingüística de dichas oraciones posee ciertos patrones que se repiten en frases o conjuntos de
palabras que servirían como semillas para el mecanismo NLG. Con el análisis sintáctico que
efectúa un componente Parser se pueden extraer las denominadas “semillas”. El Parser genera
un grafo donde cada nodo es una palabra, y cada arista es la relación gramática entre las
palabras. Definiendo recorridos sobre el grafo, en base a los patrones establecidos, se pueden
extraer las semillas.
Un subsistema NLG consiste en tres componentes interconectados como un pipeline Error:
no se encontró el origen de la referencia, a saber: Document Planner, Sentence Planner y
Linguistic realiser [Dale 1997]. El componente Document Planner puede ignorarse ya que el
contenido y estructuración del texto a generar está determinado a priori por la misma estructura de
los escenarios de calidad. El componente Linguistic Realizer es implementado por el framework
Simple NLG, el cual provee un conjunto de operaciones para indicar los lexemas que conformarán
las partes de una construcción lingüística gramatical. Como parte de esta etapa de la técnica se
implementó un componente Sentence Planner a medida para la generación de escenarios de
calidad, denominado Microplanner.
4.3.5.1 Microplanner y análisis gramaticalEl procesamiento Dependency Parsing es un procesamiento NLP que permite realizar un
análisis de las dependencias gramaticales. El framework CoreNLP de Standford aplica dicho
procesamiento añadiendo una estructura de datos de grafo, como metainformación de cada
oración, donde se señalan las relaciones gramaticales entre las palabras. Definimos formalmente
el grafo de la siguiente manera:
Sea { w1 , w2 , …, wn } Є W, el conjunto de palabras que conforman la oración; y
sea r (wg , wd) , una relación gramatical entre dos palabras (binaria y no simétrica) donde wg
se lo denomina gobernador y a wd se lo denomina dependiente; y { r1(w x , w y) ,
r2(wx ' ,w y ' ) , …, rm(w xn ,w y
n) } Є R, el conjunto de relaciones gramaticales; el grafo
direccionado se define como G = <W,R>. Las relaciones gramaticales son sintagmas con su
nombre abreviado, por ejemplo amod (adjectival modifier); las abreviaturas se encuentran
definidas y especificadas en el manual de dependencias de Standford [Manning 2008]
El Parser requiere un análisis léxico previo para identificar que parte del discurso posee
cada palabra, y en el caso del Parser de dependencias de CoreNLP utiliza los tags de Penn
Treebank [Marcinkiewicz 1994]. De esta manera el framework CoreNLP provee componentes para
aplicar cada procesamiento como pipeline, y además una potente API que permite realizar
49
numerosas operaciones sobre el grafo de relaciones gramaticales como recorrer el mismo,
acceder a nodos y aristas, obtener las palabras y la metainformación, etc.
Continuando con las oraciones de ejemplo, el esquema de la Figura 4.6 permite visualizar
la estructura de grafo y los tags de POS, resultante del procesamiento de CoreNLP a los ejemplos
de performance:
El Parser de CoreNLP se aplica sólo a las oraciones de performance identificadas en la
etapa QA Mining, ya que debe minimizarse el tiempo que emplea su procesamiento. Las
estructuras de grafo resultantes de las oraciones de performance presentan ciertos patrones que
se repiten cuando hay construcciones lingüísticas, frases, o conjunto de palabras que proveen
información específica para alguna sección de escenarios de calidad. Por ejemplo cuando se
presenta un subgrafo como el siguiente: {nsubjpass(w1,w2), det(w2,w3), auxpass(w1,w4)}, las
palabras y componentes lingüísticos que lo conforman contienen información útil para elaborar
una definición de la sección Response del escenario de calidad.
La flexibilidad y potencia que ofrecen estas operaciones permiten realizar construcciones
lingüísticas y variarlas de muchas maneras, simplemente proveyendo las palabras base que
necesita, las cuales denominamos semillas. Las semillas pueden obtenerse recorriendo el grafo
de dependencias conforme al patrón pertinente.
50
Figura 4.6: Resultado de aplicar Parser a las oraciones de ejemplo de Performance
4.3.5.2 Seed ExtractorsSe han identificado varios patrones que proveen información para la sección de Response
del template de escenarios de calidad. A continuación se listan los subgrafos que los describen:
Es evidente que se cumple que A⊂B⊂C⊂D , por lo que ciertos patrones pueden estar
incluidos en otros.
Considerando el mecanismo descrito de SimpleNLG y las características de los patrones,
se ha diseñado un componente que extrae las semillas del grafo de dependencias gramaticales y
las incorpora a la representación abstracta de construcción lingüística de SimpleNLG para así
generar el texto candidato a pertenecer a una sección del escenario de calidad. Este componente,
denominado Extractor, es lo suficientemente modificable, reutilizable y extensible para modelar los
patrones y construcciones lingüísticas para las más diversas combinaciones, y para varias
secciones de escenarios de calidad.
Un extractor que opera sobre patrones como A, a su vez puede utilizar eventualmente otro
extractor que opera sobre patrones como {nmod(w1,w2), case(w2,w3), det(w2,w4), compound(w2,w5),
compound(w2,w6), … , compound(w2,wn)} y subconjuntos del mismo.
Además se ha identificado otra serie de patrones para Stimulus (del template de escenario
de calidad) que aplica a los siguientes subgrafos:
La Figura 4.7 ilustra otro buen ejemplo de oración donde se observa un grafo con varios
patrones de los descritos hasta el momento.
51
E = {dobj(w1,w2), det(w2,w3)}
F = {dobj(w1,w2), det(w2,w3), compound(w2,w4)}
G = {dobj(w1,w2), det(w2,w3), amod(w2, w4)}
A = {nsubjpass(w1,w2), det(w2,w3), auxpass(w1,w4)}
B = {nsubjpass(w1,w2), det(w2,w3), auxpass(w1,w4), nmod(w1,w5), case(w5,w6)}
C = {nsubjpass(w1,w2), det(w2,w3), auxpass(w1,w4), nmod(w1,w5), case(w5,w6),
det(w5,w7)}
D = {nsubjpass(w1,w2), det(w2,w3), auxpass(w1,w4), nmod(w1,w5), case(w5,w6),
det(w5,w7), compound(w5,w8)}
Cada extractor provee una función que, dada una oración con información de un atributo
de calidad y sus anotaciones pertinentes, obtiene una representación abstracta de frase a generar
y la implementa conforme a determinado patrón. El texto que instancia dicha representación se
añade como candidato a pertenecer a una sección predeterminada del escenario de calidad.
Consecuentemente se modelan los extractores con una jerarquía donde el la clase base posee
gran parte de esta lógica algorítmica, y las clases que heredan especializan la manera en que se
recorre el grafo y se extraen las semillas de acuerdo al patrón que representan respondiendo al
patrón Template Method.
La función assemble es la que implementa cada extractor dependiendo del patrón que
representa; y conforme a tal patrón recorre el grafo para que extraiga la palabra que representan
los nodos del recorrido, y la agrega en la representación abstracta de construcción lingüística que
genera una oración para la sección del escenario de calidad a la cual aplica. Al crear una instancia
de representación de frase para la sección de escenario de calidad, se indica el texto generado
(oración) y el desplazamiento en el texto del documento de requerimientos donde localizar el
segmento de texto del que se dedujo la información. El desplazamiento se obtiene de la meta
información de cada QA Sentence que fue generada en la etapa de QAMining, y esa meta
información, en esta etapa, se ha traduce al formato de anotación soportada por el Dependency
Parser.
Cada Extractor posee un nombre descriptivo que indica el lexema en el que se
fundamenta. Por ejemplo si el patrón se caracteriza por recorrer los vértices adyacentes a los
nodos relacionados como objeto directo o buscan la primer ocurrencia de una arista con esa
relación, entonces su nombre tendrá como prefijo “DirectObject”.
Al crear extractores, se debe especificar la sección para la cual se realiza la extracción,
para permitir combinaciones y flexibilidad. Esto podría ser configurado por el usuario final
mediante una interfaz de usuario apropiada, pero es realizado por un componente denominado
ExtractorManager que simula esas configuraciones.
Finalmente, aplicando los correspondientes extractores a los ejemplos de performance, se
obtienen las frases candidatas para secciones de escenarios de calidad de la Tabla Tabla 4.6
52
Figura 4.7: Ejemplo de oración donde se aplican varios patrones
Ejemplo a. Response: Provide access to the legacy course catalog database
Ejemplo b. Response: Receive the alarm Display the alarm
Ejemplo c. Response: The FSS updates a value Publish a COV event
Stimulus: Execute a command
Ejemplo d. Response: Update de UI Reflect the failed command
Stimulus: Execute a command
Ejemplo e. Response: Reflect the update
Stimulus: Receive the notification from the FSS
Tabla 4.6: Frases candidatas para escenarios generadas
El proyecto Eclipse Modeling Framework es una herramienta de modelado que provee
infraestructura de generación de código para desarrollar software y otras aplicaciones basadas en
un modelo de estructura de datos. EMF permite generar una batería de componentes de software
que constituyen patrones de diseño que permiten modelar y visualizar escenarios de calidad y
realizar operaciones de creación y modificación de instancias de tal modelo, con una estructura de
alta modificabilidad y extensibilidad. Con EMF ha sido posible implementar fácilmente la
persistencia de los escenarios de calidad generados y/o editados, y cargarlos posteriormente
cuando se desee continuar con su análisis.
4.3.5.3 Generación de los escenarios de calidadUna vez generadas todas las secciones de escenarios de calidad a partir de la información
extraída, procesada y analizada solo resta que el analista confirme de cada repertorio aquellas
secciones que resultan factibles y correctas.
A partir de las secciones validadas se pueden generar escenarios de calidad de diferente
índole, de tal manera que el entregable pueda estar junto con su información representada de
manera concisa y ordenada. Una estrategia posible es instanciar escenarios de calidad concretos
con una y sólo una sección, otra estrategia consiste en instanciar escenarios con más de una
sección. La segunda estrategia no requiere de mucho procesamiento, sólo descartar aquellas que
el analista no incluyó en su validación. Para la primera estrategia, se hace una combinatoria entre
las secciones validadas, es decir generar un escenario por cada combinación de las secciones
validadas. Implementando el patrón Strategy se logra intercambiar fácilmente entre ambas
estrategias, donde la clase que implementa la combinatoria aplica una búsqueda exhaustiva con
recursión para generar todas las posibles combinaciones.
53
De esta manera, en esta instancia de la última etapa ya se dispone de los escenarios de
calidad que se esperaban como salida (resultado final) del proceso completo, con información
extraída de los datos de entrada (documentos de requerimientos) y validada por el mismo analista.
4.4. Arquitectura de QAGen
Las actividades anteriormente descritas, que se conciben como integrantes de una etapa
de procesamiento específica, pueden ser modeladas como una arquitectura Pipes & Filters. Cada
actividad tiene una entrada de datos que, al ser procesados de una forma transparente, genera
una salida respectiva de datos; conformando así un Filter. La salida se conecta a la entrada de
otro Filter y así sucesivamente se construye el Pipeline que transforma los datos de manera
incremental hasta obtener un resultado elaborado. Cada Filter puede ser sustituido por otro que
respete las interfaces de entrada y salida (Pipe), y realiza un procesamiento diferente, o igual pero
con operaciones distintas.
Todo el flujo de datos es sometido a un procesamiento batch secuencial a través de los
Filter descritos. Y en los Pipes los datos migran utilizando un mecanismo Push / Pop. Cada Filter
analiza, procesa y enriquece el texto con metainformación de manera incremental para luego
dejarla lista en el Pipe de salida de manera tal que el siguiente Filter pueda consumirla.
Esta arquitectura se caracteriza por bajo un acoplamiento y alta cohesión entre
componentes dentro de un mismo Filter, lo que la hace muy favorable para refinar y/o especializar
el proceso. Por ejemplo, si en la etapa de preanálisis hay palabras que no son bien lematizadas o
su POS es reconocido como verbo en lugar de sustantivo, o bien se desea minimizar el tiempo de
procesamiento de dicha etapa; se puede reemplazar el componente que implementa la actividad
correspondiente por otro componente que cumpla las restricciones especificadas.
54
5 EvaluaciónEn este capítulo se presenta una evaluación de la herramienta QAGen, simulando la
asistencia de un arquitecto en la tarea de obtener escenarios de calidad para especificar los
requerimientos no funcionales.
Para determinar el desempeño de la técnica propuesta, se realizó un procedimiento con
QAGen, preparando los documentos de especificaciones de 3 casos de estudio para ser
analizados por la herramienta. Luego se evalúa, por un lado, los tiempos que el proceso completo
requiere para completarse; y por otro lado, para uno de los casos de estudio, se evalúan los
escenarios de calidad generados comparando el texto que define cada uno contra el texto de los
escenarios de calidad descritos por un experto. Se consideraron diversas métricas de similitud
para realizar la comparación entre los textos de los escenarios de calidad, escogiendo las más
viables para los propósitos del trabajo. Finalmente se analizan los resultados obtenidos, para
determinar el desempeño de la técnica que implementa la herramienta.
Los 3 casos de estudio utilizados fueron HWS, CRS y MSLite, los cuales se describen
brevemente a continuación.
● Caso de estudio CRS: Course Registration System es un sistema provisto por IBM para
demostrar sus herramientas CASE [Bell 2011]. CRS es un sistema distribuido para ser
usado dentro de una intranet universitaria; el cual permite a los estudiantes inscribirse a
cursadas, soporta la creación de nuevas cursadas por profesores, y reportar las
calificaciones de los estudiantes. Esta especificación contiene 8 casos de uso.
● Caso de estudio HWS: Health Watcher System es un sistema desarrollado por académicos
para una institución gubernamental de Brasil [Greenwood 2011]. HWS describe un sistema
de información web que provee acceso en línea de usuarios para registrar quejas, leer
noticias de salud, y realizar consultas respecto a asuntos de salud. Esta especificación
consiste de 9 casos de uso. Cabe destacar que otros investigadores han usado HWS
como modelo para analizar propiedades de atributos de calidad [Haimei 2010].
● Caso de estudio MSLite: Management System Lightweight es un sistema desarrollado en
conjunto con profesionales de Carnegie Mellon University y Siemens [Gersmann 2005].
MSLite es un sistema que controla y monitorea automáticamente varias funciones de un
sistema, tales como: calefacción, ventilación, aire acondicionado, accesos y seguridad,
entre otros. El sistema opera en una red, y gestiona las interacciones entre diferentes
dispositivos conectados a la red. La especificación consiste de 22 casos de uso.
5.1. Procedimiento experimental
En esta sección se describe el procedimiento experimental de evaluación de la técnica de
generación de escenarios de calidad QAGen. Se escogió el atributo de calidad Performance para
55
el desarrollo del proceso y las pruebas, dado que es uno de los atributos más comunes. Para este
atributo de calidad se crearon los diccionarios de constraints, events, LTD, performanceKeywords
y time (Tablas Tabla 4.2, Tabla 4.3, Tabla 4.4 y Tabla 4.5) basados en conceptos, definiciones y
relaciones extraídas de [IEEE 1992]. Una vez definidos estos diccionarios, se definieron las reglas
de UIMA Ruta para detectar los tokens relacionados con estas palabras y 6 reglas más para
detectar frases referentes a la performance (perfomanceSentences):
• Contiene un tokenEvent y un tokenTime.
• Contiene un tokenEvent y un tokenLTD.
• Contiene un tokenEvent, un tokenStart y un tokenEnd.
• Contiene un tokenEvent y un tokenConstraint.
• Contiene un tokenConstraint y un tokenTime.
• Contiene un tokenConstraint y un tokenLTD.
Durante este proceso se detectaron problemas, como por ejemplo la ambigüedad de las
palabras (por ej. la palabra “second”) que se trataron utilizando las etiquetas #time# y #ord# al
momento de definir las reglas de selección de los tokens específicos para cada diccionario.
Para evaluar la técnica propuesta se realizaron 2 experimentos, basados en 3 casos de
estudio. En el experimento #1 se utilizaron los casos de estudio de HWS y CRS, dado que son
casos simples y poco extensos, con el fin de medir tiempos y refinar las diferentes configuraciones
de la herramienta. En cambio, para el experimento #2 se utilizó MSLite, un caso de estudio más
completo para poder evaluar el proceso entero, su comportamiento con una entrada más extensa
y así poder validar, mediante diversas métricas, los escenarios generados en comparación con
escenarios reales, creados por un experto.
Se registraron los tiempos de ejecución para ambos experimentos, teniendo en cuenta que
se realizaron en una PC convencional, procesador Intel core i7 y 12 GB de RAM, con sistema
operativo Linux.
5.1.1 Experimento #1Para el experimento #1, se tomaron como entrada los requerimientos de HWS y CRS en
texto plano, limpiando los formatos y caracteres extraños, tablas y viñetas para facilitar su
procesamiento, junto con los diccionarios y reglas propuestos.
Para el primer caso HWS, se obtuvo una entrada resultante, en texto plano, de 2078
palabras, de donde se logró detectar solo una oración (Tabla Tabla 5.1) relacionada con el atributo
de calidad performance (perfomanceSentences).
The response time must not exceed 5 seconds.
Tabla 5.1: Performance sentence detectada en HWS
56
En el caso de CRS, se obtuvo una entrada en texto plano de 884 palabras, que si bien es
un caso menos extenso, tiene más información referente a performance, por lo que, como se
puede ver en la Tabla Tabla 5.2, se detectaron más Performance Sentences.
The system error messages shall include a text description of the error, the operating system error code (if applicable), the module detecting the error condition, a data stamp, and a time stamp.
Mean Time Between Failures shall exceed 300 hours.
The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.
Database Access Response Time: The system shall provide access to the legacy course catalog database with no more than a 10 second latency.
Transaction Response Time: The system must be able to complete 80% of all transactions within 2 minutes.
Tabla 5.2: Performance sentences detectadas en CRS
Estas frases detectadas, si bien provinieron de casos de estudio pequeños, fueron útiles
para redefinir las reglas de una forma más precisa y definir los Seed Extractors en la etapa de
Scenario Linking para generar las secciones candidatas para los escenarios de calidad finales,
mediante el análisis del grafo resultante del procesamiento de CoreNLP.
Como resultado, como se puede observar en la Tabla Tabla 5.3, solo se pudo generar una
frase correspondiente a HWS y 7 frases para CRS, en ambos casos relacionadas únicamente a la
sección response.
HWS RESPONSE exceeds second
CRS RESPONSE
includes a description
detects the condition
exceeds hours
supports to user
provides access
Responses Time
completes %
Tabla 5.3: Secciones candidatas generadas para HWS y CRS
Con respecto a los tiempos, se midió un tiempo de procesamiento de 15.97 segundos para HWS y
16 segundos para CRS. También se realizó la prueba de medición procesando ambos casos de
estudio en forma conjunta y se obtuvo un tiempo de 18,34 segundos.
5.1.2 Experimento #2Para el segundo experimento, se tomó como entrada las reglas y diccionarios definidos
anteriormente, pero con un nuevo caso de uso: MSLite. Este es un caso de uso más amplio, que
presenta la lista de requerimientos junto con un par de escenarios de calidad de performance
57
creados por un experto (Tabla Tabla 7.2), los cuales son útiles para ser utilizados como texto
benchmark, es decir, para comparar y validar contra los generados por QAGen.
Para adecuar el corpus como entrada de la herramienta, se eliminaron los 2 escenarios de
calidad de MSLite ya especificados y se ajustó el formato eliminando los gráficos, tablas y
caracteres extraños como las viñetas, obteniendo un texto plano de 10470 palabras,
considerablemente mayor al del experimento #1.
Tras correr las primeras etapas, de segmentación, preanálisis y QA Mining, se obtuvieron
las Performance Sentences de la Tabla Tabla 7.3.
Como puede observarse, con este caso de estudio se detectaron más frases relacionadas
a performance que en el experimento #1. Estas frases son tomadas como entrada para la
siguiente etapa, con el fin de extraer las semillas para generar las secciones candidatas para los
escenarios de calidad, obteniendo las secciones de escenarios de calidad de performance de la
Tabla Tabla 5.4.
STIMULUS
reflects transmission in the UI
displays property in the alarm viewer
selects item in the Hierarchy Tree Editor
updates value on all user screen
displays alarm on the user
RESPONSE
executes a command
publishes an event
receives from MSLite
displays the old value
displays within second
receives the alarm
receives within second
reflects the update
receives the notification
Tabla 5.4: Secciones candidatas generadas para MSLite
Una vez generadas las secciones candidatas, se procedió a generar los escenarios de
calidad con la ayuda de la herramienta visual de edición y generación de escenarios de QAGen,
donde redujo manualmente la cantidad de posibles secciones, descartando las menos relevantes,
y se seleccionó el source y el environment de cada lista. Como se puede notar, la herramienta
genera de forma automática frases candidatas para las secciones de stimulus y response, dado
que estas suelen ser las secciones que llevan frases más elaboradas y complejas de detectar
para un escenario. El resto de las secciones se pueden completar seleccionándolas de una lista
predefinida para cada parte, en base a los templates de escenarios generales de calidad [Bass
58
2003]. En la Tabla Tabla 5.5 se muestra el escenario candidato resultante, con las secciones
seleccionadas.
SOURCE system
STIMULUS
reflects transmission in the UI
displays property in the alarm viewer
selects item in the Hierarchy Tree Editor
ENVIRONMENT normal conditions
RESPONSEexecutes a command
publishes an event
Tabla 5.5: Escenario candidato generado para MSLite
Dado este escenario con todas las secciones candidatas generadas por la herramienta y
seleccionadas manualmente, se prosiguió a generar los escenarios concretos mediante el uso del
generador, seleccionando la opción “Combination” que aplica una búsqueda exhaustiva con
recursión para generar todas las posibles combinaciones. Esta combinatoria se realizó también
teniendo en cuenta escenarios con y sin source y environment, obteniendo como resultado 24
escenarios listados en la Tabla Tabla 7.3.
Los 24 escenarios generados se utilizaron para comparar con los escenarios reales a fin
de evaluar, mediante distintas métricas, la similitud de los mismos. Cabe destacar que esta
comparación se realiza con 2 escenarios de ejemplo, creados por un experto, pero no son puntos
de comparación absolutos dado que la generación manual es algo subjetivo y otro experto podría
proveer escenarios diferentes.
El tiempo de procesamiento para este experimento, para la generación automática de
stimulus y response fue de 20,04 segundos.
5.2. Métricas
Para realizar una evaluación del desempeño de herramientas de Recuperación de
Información, por un lado, se suelen calcular y comparar los tiempos que emplean los
procesamientos, desde el comienzo de la ejecución hasta obtener la salida o resultados finales; y,
si corresponde, los tiempos de entrenamiento o aprendizaje previo, entre otros.
Por otro lado, el desempeño se puede evaluar según cuán acertados o aproximados
fueron los resultados a un modelo de referencia denominado benchmark. Cuando se trata de
textos se suelen utilizar diversas métricas para comparar dos secuencias de caracteres,
considerándose diferentes niveles de granularidad; es decir, se puede comparar carácter a
carácter, palabra a palabra, o cadena a cadena. Existen métricas de distancia, que indican
cuánto difieren las secuencias de caracteres, y métricas de similitud, que indican cuánto se
asemejan las secuencias de caracteres. Las diversas métricas suelen indicar valores numéricos
que se basan en escalas que pueden diferir de las empleadas por otras métricas, por lo tanto,
para poder utilizarlas en conjunto y realizar comparaciones se normalizan de manera tal de
59
obtener valores entre 0 y 1. Por otra parte, las métricas de similitud y distancia para comparar
secuencias de caracteres se clasifican en sintácticas y semánticas.
La similitud semántica es la medida de la interrelación existente entre dos textos y que
evalúa el grado en que coinciden sus significados. Estas métricas son las más complejas y suelen
tener muchas variables y parámetros, además requieren un preprocesamiento como lematización
y análisis sintáctico. La evaluación de similitud semántica escapa al alcance del presente trabajo y
puede ser considerada como trabajo futuro. Para evaluar el desempeño de QAGen se utilizaron
las métricas de: Coseno, Jaccard, JaroWinkler, Normalized Levenshtein y SorensenDice. Es
importante destacar que en el caso de aquellas funciones que realizan un cálculo de la distancia
entre dos elementos, se consideró la similitud como el inverso de dicha distancia.
A continuación, se describe cada una de las estrategias escogidas como métricas. Para
cada función se brinda una descripción corta, su definición formal y, si es necesario, algunas
consideraciones para su uso.
5.2.1 Coeficiente de JaccardLa distancia de Jaccard es una métrica usada para comparar la similitud y la diversidad de
conjuntos finitos de muestras. Esta estrategia es muy útil para analizar similitud de texto en
colecciones inmensas [Rajaraman 2012].
La Figura 5.1 muestra la ecuación que define formalmente esta estrategia, donde A y B
son los conjuntos de elementos a comparar.
J (A , B)=|A∩B|
|A∪B|Figura 5.1: Fórmula de Jaccard
Se puede interpretar como la cardinalidad de la intersección de ambos conjuntos dividida
por la cardinalidad de su unión. Para el presente trabajo se consideraron conjuntos de ngramas
(secuencia de n caracteres). Cabe señalar que este índice está determinado por la cantidad de
elementos que son compartidos y la cantidad de elementos que difieren entre los conjuntos.
5.2.2 Sorensen-DiceEl coeficiente de SorensenDice, es un método estadístico utilizado para comparar la
semejanza de dos muestras [Dice 1945]. Se basa en el análisis de la presencia o ausencia de los
datos en las muestras. Comparado con la distancia Euclidiana o la distancia de Jaccard, esta
estrategia da menos peso a los datos de partes aisladas, manifestando así su utilidad para el
análisis de conjuntos de datos heterogéneos.
60
SD( A ,B )=2|A∩B|
|A|+|B|Figura 5.2: Fórmula Sorensen-Dice
5.2.3 Similitud del CosenoLa representación de distribuciones como vectores permite medir la similitud entre la
correlación de tales vectores [Huang 2008]. Tal similitud puede ser cuantificada como el coseno
del ángulo entre los vectores. Esta estrategia es independiente del tamaño de las distribuciones, y
es una de las más utilizadas en sistemas recuperación de información. La Figura 5.3 presenta la
ecuación que define formalmente la similitud del coseno donde t⃗ a y t⃗ b son los vectores a
comparar.
Figura 5.3: Fórmula de similitud del Coseno
Se interpreta como el producto de los vectores dividido el producto de la cardinalidad de
los vectores.
5.2.4 Normalized LevenshteinLevenshtein es una métrica de edición [Levenshtein 1966] dada como el mínimo número
de ediciones de caracteres individuales (inserción, eliminación y sustitución) requeridas para
transformar una cadena de caracteres a otra. Se le considera una generalización de la distancia
de Hamming, que se usa para cadenas de la misma longitud y que solo considera como operación
la sustitución.
min {H(x* , y*)}Figura 5.4: Fórmula Levenshtein
La distancia Levenshtein normalizada es calculada como la distancia Levenshtein dividido
la longitud de la secuencia más larga. Siendo D(A,B) la distancia Levenshtein normalizada, la
similitud se calcula como 1 D(A,B).
5.2.5 Jaro-WinklerLa distancia Jaro–Winkler [Winkler 1990] es una métrica de cadenas para medir la
distancia de edición entre dos secuencias. Es una variante de la distancia Jaro [Jaro 1989]
propuesta por William E. Winkler. Informalmente, la distancia Jaro entre dos palabras es el
número mínimo de transposiciones a caracteres individuales requeridas para transformar una
61
palabra en otra. La similitud Jaro–Winkler está dada por 1 Dw, donde Dw es la distancia Jaro
Winkler. La Figura 5.5 describe formalmente la distancia Jaro d j de dos cadenas de caracteres
s1 y s2.
Figura 5.5: Fórmula Jaro
Donde |si| es la longitud de la cadena si; m es el número de caracteres coincidentes; y t es
el número de transposiciones, es decir, la mitad del número de caracteres coincidentes (pero en
diferente orden).
La distancia de JaroWinkler usa un factor de prefijos que pondera el índice de cadenas
que coinciden desde el comienzo para un prefijo de longitud l. La Figura 5.6 describe formalmente
la distancia JaroWinkler de dos cadenas de caracteres x e y.
Figura 5.6: Fórmula Jaro-Winkler
Donde Jaro(x, y) es la similitud de Jaro; y LCP(x, y) es la longitud del prefijo común entre x
e y.
5.2.6 Aplicación de las métricasPara evaluar el desempeño de la técnica se compara la similitud de cada uno de los
escenarios generados con los escenarios reales especificados por un experto. Los escenarios
reales se consideran como texto benchmark, es decir, cuanto más similar el texto de los
escenarios generados, más acertada es la salida de la herramienta. Se utilizó la biblioteca java
string similarity7 que implementa las 5 métricas descritas en lenguaje Java, lo que permite
aplicarlas al corpus mediante un mecanismo a medida y presentar los resultados en el formato
deseado. Para facilitar el análisis y poder sintetizar los resultados en gráficos y tablas se
asignaron códigos de referencia a cada uno de los textos, tanto los generados (Tabla Tabla 7.1),
como los textos benchmark (Tabla Tabla 7.2).
Los valores obtenidos se pueden ver en las tablas 7.4 y 7.5 del Apéndice, los cuales se
reflejan en el gráfico de la Figura 5.7.
7 https://github.com/tdebatty/java-string-similarity
62
Figura 5.7: Valores obtenidos al aplicar las métricas de similitud
5.3. Discusión de los resultados
Los 24 textos extraídos de los escenarios de calidad generados se compararon contra los
dos textos de escenarios de calidad de referencia R1 y R2 aplicando las cinco métricas, con lo
que se obtuvieron cifras para dos casos de comparación. Por otra parte, se registraron los tiempos
de ejecución durante el procedimiento experimental para analizar el desempeño también en esta
dimensión.
5.3.1 Similitud con escenarios de referenciaPara sintetizar todos los valores obtenidos tanto para el caso de comparación R1 como R2
se calcularon sus máximos, mínimos, promedios, medianas, y desviación estándar que se
observan en la Tabla 5.6 y se reflejan en el gráfico de la Figura 5.8.
R1R2 Cosine Jaccard JaroWinklerNormalizedLevenshtein
SorensenDice
Max 0,5360 0,2423 0,6382 0,3093 0,3900
Min 0,1983 0,0492 0,5357 0,1262 0,0938
Promedio 0,3497 0,1563 0,5921 0,2253 0,2670
Mediana 0,3388 0,1626 0,5985 0,2430 0,2797
Desviación Estándar 0,0742 0,0508 0,0283 0,0496 0,0777
Table 5.6: Valores de similitud con R1 y R2
63
Figura 5.8: Valores de similitud con R1 y R2
Considerando los índices que arrojaron las cinco métricas, se puede ver claramente que
con la métrica JaroWinkler se obtuvieron, para los dos casos de comparación, las cifras más altas
que superaron ampliamente las de las otras métricas. De hecho, los valores mínimos de Jaro
Winkler, que fueron 0.542 y 0.5357 para R1 y R2 respectivamente (Tabla 5.7 y Tabla 5.8), están
por encima de la mayoría de los valores de las demás métricas incluyendo sus máximos (salvo los
valores máximos de Coseno). No obstante, tales valores se encuentran muy concentrados,
indicados por la desviación estándar global 0.0283 que fue la mínima. Esto se debe a que Jaro
Winkler es una métrica ideada para detectar errores de tipeo, y aplicarla a secuencias de
caracteres cortas como palabras individuales o nombres de pila [Winkler 1990]; es por ello que se
debe tener en cuenta que los resultados de JaroWinkler, si bien dan buenos índices de similitud,
no son muy confiables al evaluar el desempeño de QAGen.
Por otra parte, los índices obtenidos con Jaccard fueron los más bajos entre las cinco
métricas. De hecho, los valores máximos obtenidos con Jaccard (0.2381 y 0.2423) son muy
inferiores a la mayoría de los obtenidos con las otras cuatro métricas. Esto se debe a que está
fundamentado simplemente en teoría de conjuntos (se basa en análisis de la presencia o ausencia
de los datos en las muestras) y su coeficiente es muy rudimentario al no añadir ningún factor o
variable heurística de ajuste, ponderación, aproximación, etc. Particularmente se puede destacar
que al aplicar Jaccard a los escenarios generados, los índices de esta métrica se vieron muy
influenciados por la cantidad de palabras no detectadas del texto benchmark, y las palabras que
se generaron y no estaban en el texto benchmark, las cuales superaron a las palabras que sí
coincidieron. La métrica SorensenDice, en cambio, es más confiable por ser una variante de
Jaccard que da menos peso a los datos de partes aisladas, siendo más apropiada para los textos
con las características de los que se desean analizar para el desempeño de QAGen.
La métrica que arrojó resultados más razonables y descriptivos fue la del Coseno, y de
hecho esta estrategia es ampliamente utilizada y aceptada en numerosos casos de evaluación de
herramientas de Recuperación de Información. Los índices obtenidos con la estrategia de similitud
64
del Coseno fueron mayormente aceptables, lo cual se aprecia observando que los promedios y la
mediana de los dos casos de comparación (Tabla 5.7 y Tabla 5.8) están por encima de 0.32; y el
máximo total fue 0.536.
En la Figura 5.9 se reflejan los cálculos de análisis para los valores obtenidos con el caso
de comparación contra R1.
Figura 5.9: Valores de similitud con R1
Los valores máximos obtenidos con Coseno, Jaccard y SorensenDice (0.421967,
0.238095 y 0.3846 respectivamente) son de comparar G08 contra R1 en el que coinciden varias
palabras por ser el más completo.
Los escenarios G13 y G01 son los más incompletos y por lo tanto los índices obtenidos
están entre los más bajos para las 5 métricas. Todos los cálculos de análisis para el caso de
comparación contra R1 se agrupan en la Tabla 5.7.
R1 Cosine Jaccard JaroWinklerNormalizedLevenshtein
SorensenDice
Max 0,4220 0,2381 0,6382 0,3093 0,3846
Min 0,1983 0,0571 0,5420 0,1289 0,1081
Promedio 0,3278 0,1569 0,5962 0,2373 0,2679
Mediana 0,3322 0,1689 0,6010 0,2552 0,2890
Desviación Estándar 0,0609 0,0495 0,0285 0,0533 0,0761
Table 5.7: Valores de comparación con R1
No obstante, los escenarios generados fueron más aproximados a R2. Los cálculos de
análisis para los valores obtenidos con el caso de comparación contra R1 se reflejan en la Figura
5.10.
65
Figura 5.10: Valores de comparación con R2
Entre los valores obtenidos con las estrategias Coseno, Normalized Levenshtein y
SorensenDice, hubo varios que superaron a la mayoría de los obtenidos en el caso de
comparación R1 con la misma estrategia. Tales valores corresponden a G05, G08, G11, G17 y
G20 que contienen “alarm”, un concepto que se menciona tres veces en R2.
Los valores para R2 podrían haber superado aún más ampliamente si se unificaban “UI”
(que se menciona en los generados) y “user interface” (que se menciona en R2). Esto sirve como
lección para considerar reglas en la etapa de QAMining que unifiquen siglas y abreviaturas.
R2 Cosine Jaccard JaroWinklerNormalizedLevenshtein
SorensenDice
Max 0,5360 0,2423 0,6266 0,2570 0,3900
Min 0,2440 0,0492 0,5357 0,1262 0,0938
Promedio 0,3716 0,1558 0,5881 0,2132 0,2660
Mediana 0,3543 0,1583 0,5964 0,2313 0,2733
Desviación Estándar 0,0797 0,0521 0,0276 0,0422 0,0793
Table 5.8: Valores de comparación con R2
Cabe mencionar que todas las métricas empleadas comparan los textos sin tener en
cuenta su significado, sintaxis, gramática, etc.; por lo tanto, puede darse el caso en que en un
texto se encuentre el mismo verbo que en el texto benchmark pero en otra conjugación, y en tal
caso deberían tener el mismo valor semántico e incrementar el índice obtenido. Es por ello que se
planteó, entre las diversas estrategias para evaluar, obtener los lemas de las palabras de ambos
textos a comparar y calcular cuántos lemas coinciden aplicando una estrategia como la de
Jaccard para obtener este índice. Existen numerosas métricas semánticas las cuales, por su
sofisticada configuración y aplicación, y complejidad para analizar y comparar sus resultados,
66
escapan al alcance del presente trabajo, pero sin lugar a dudas podrían utilizarse para realizar una
evaluación más precisa y confiable.
5.3.2 Velocidad de ejecuciónUna de las características observadas en las validaciones realizadas fue la velocidad de
ejecución dado que, como se pudo observar, se obtuvieron resultados consistentes, en tiempos
razonables, con aproximadamente 20 segundos de procesamiento para una entrada extensa
como lo es MSLite. QAGen presenta una ventaja considerable en este aspecto, con respecto a
herramientas similares, dado que muchas de ellas realizan procesamientos más costosos y
utilizan técnicas de entrenamiento y aprendizaje que suelen requerir gran cantidad de datos y
tiempo.
En la Tabla 5.9 se muestran los tiempos obtenidos para cada caso de estudio analizado,
junto con la cantidad de palabras analizadas. En cada caso se discrimina por tiempo de
configuración inicial y de procesamiento donde se puede observar que los tiempos, si bien crecen
de acuerdo al tamaño de la entrada, no lo hace en forma proporcional a la extensión. Cabe
destacar que todas las mediciones se realizaron en una misma PC y bajo las mismas condiciones,
reiniciando el ordenador antes de cada prueba para asegurar siempre una primera corrida y evitar
datos potencialmente cacheados.
Caso de estudio
Número de palabras Tiempo de setup Tiempo promedio total Desviación
HWS 2078 6,853 seg. 14,432 seg. 0,242 seg.
CRS 884 7,595 seg. 15,282 seg. 0,416 seg.
MSLite 10470 8,566 seg. 18,696 seg. 0,457 seg.
CRS + HWS 884 + 2078 8,311 seg. 17,564 seg. 0,422 seg.
Table 5.9: Tiempos de ejecución del procedimiento registrados
Los tiempos de configuración inicial corresponden a la preparación de Stanford CoreNLP,
que consiste principalmente de la inicialización del dependency parser, carga del modelo y
preparación del POS tagging. Estas tareas de configuración inicial se ejecutan sólo una vez, lo
que permite mejorar los tiempos incluyendo todos los corpus de entrada en una sola corrida.
Además, al utilizarse una estructura de pipelines, se ejecutan las tareas de manera continua y
secuencial, lo cual optimiza el tiempo resultante. Por ejemplo, en el caso de CRS + HWS, se
incluyeron ambos textos como entrada, lo cual tuvo un ligero aumento de tiempo total (poco más
de 3 segundos) con respecto al procesamiento individual de cada uno de ellos, dando un
promedio de aproximadamente 9 segundos cada uno, contra unos 15 segundos que dieron como
resultado cuando se corrieron por separado.
67
6 ConclusionesLa especificación de atributos de calidad es una tarea que tiene un gran impacto en todo el
ciclo de vida del software. La manera en que se lleve a cabo esta tarea puede afectar mucho ya
sea positivamente o negativamente el diseño arquitectónico (el comportamiento y estructura del
sistema) y por lo tanto la satisfacción de los stakeholders. Aun así, las especificaciones de
atributos de calidad en los documentos de requerimientos suelen ser realizadas de forma vaga y
hasta omitidas. Esto se debe, generalmente, a que se presta más atención a los requerimientos
funcionales; y por otro lado, la identificación de requerimientos no funcionales requiere que el
analista tenga mucha experiencia y conocimiento sobre diversos atributos de calidad. Un gran
obstáculo para la elicitación y especificación de atributos de calidad es que es una tarea que
demanda tiempo y esfuerzo.
Los escenarios de calidad son un mecanismo para especificar atributos de calidad de una
forma clara, concisa y eficaz. Además, sirven para evaluar la arquitectura del sistema y pueden
conformar su documentación entre otros artefactos. De esta manera, se debe considerar que es
de suma importancia facilitar la obtención de escenarios de calidad a partir de los requerimientos
del sistema.
Se han logrado considerables contribuciones en la Ingeniería de Requerimientos con el
desarrollo de herramientas que asisten de forma automatizada en las distintas tareas de esta
área. Se han implementado varias herramientas semiautomáticas aprovechando los avances de
las áreas de Inteligencia Artificial, Natural Language Understanding, o Natural Language
Generation, Machine Learning, etc; las cuales poseen mucho potencial para estos propósitos.
El enfoque propuesto en esta tesis plantea aprovechar las funciones de distintas tareas de
Natural Language Processing, de manera tal que se puedan identificar y analizar las secciones del
texto de los documentos de requerimientos que contienen información de atributos de calidad. A
partir de la información analizada, se pueden obtener datos que sirven para generar escenarios de
calidad aprovechando las técnicas de Natural Language Generation, por medio de las cuáles, se
pueden obtener frases que conforman las secciones de source, stimulus, artifact, environment,
response y response measure. Este enfoque se materializó con una herramienta denominada
QAGen. El mismo consta de un análisis por medio de un pipeline, el cuál se divide en distintas
etapas. A lo largo de cada etapa se aplica un procesamiento incremental, al cual una vez que
identifica oraciones con información relacionada a atributos de calidad, se le realiza un análisis
gramatical para extraer los elementos que el componente de generación de lenguaje natural utiliza
para armar las frases que pueden pertenecer a alguna sección de los escenarios de calidad.
Finalmente, el enfoque permite validar las frases candidatas y generar escenarios generales de
calidad y también escenarios de calidad concretos por medio de combinatoria. La herramienta
QAGen puede entonces asistir a un analista que no tiene experiencia suficiente o minimizar los
68
tiempos que demanda una inspección manual, a su vez obtener los escenarios de calidad que son
tan importantes para el diseño arquitectónico del sistema.
Para evaluar el enfoque, se escogió el atributo de calidad Performance, definiendo reglas y
diccionarios de palabras clave para la detección de oraciones de tal atributo de calidad.
Se puede concluir que la utilización de técnicas de procesamiento de lenguaje natural es
muy útil para lograr herramientas de software que automaticen gran parte de las tareas que
implica la especificación de requerimientos no funcionales, reduciendo el tiempo y esfuerzo que
demandan al hacerlo de forma manual. También estas herramientas logran que se pueda
prescindir (hasta cierto punto) de un experto en atributos de calidad. Además, para obtener
resultados precisos y satisfactorios se debe encontrar la manera de combinar las diversas
técnicas NLP y la mejor configuración de cada uno. Por otra parte, suelen presentarse
complicaciones al intentar integrar componentes de software NLP que no han sido pensados para
ser compatibles entre sí. Finalmente, la gran variedad de atributos de calidad presentan el desafío
de abarcar diferentes escenarios que pueden no ser contemplados por los patrones planteados
inicialmente. Pero sobre todo la comprensión de la lingüística es muy compleja debido a sus
diversos fenómenos como la polisemia, las siglas y abreviaturas, y los innumerables dominios y
contextos en que puede estar denotado un significado.
6.1. Contribuciones
La herramienta propuesta en este trabajo realiza diversas contribuciones al estado del
arte, las cuales se enumeran a continuación:
● Se ha desarrollado una herramienta que asiste al analista para generar escenarios de
calidad a partir de los documentos de requerimientos. Tal herramienta cuenta con una
interfaz de usuario intuitiva que guía en todo el proceso, de esta manera permite que sea
utilizada por un analista que puede no ser experto en especificación de requerimientos no
funcionales.
● Se ha logrado combinar componentes de Natural Language Understanding y Natural
Language Generation y explotar en conjunto sus características. El proceso pipeline
resultante hace que la extracción de información de los documentos sea
considerablemente más rápida y fácil que otras herramientas que utilizan otras técnicas de
inteligencia artificial que son muy complejas, difíciles de configurar y demandan tiempo,
como el caso de Machine Learning.
● Se han implementado e integrado módulos modificables, extensibles y reutilizables,
permitiendo utilizar componentes de distintas librerías y realizar futuros cambios en el
pipeline fácilmente. Por ejemplo, funcionalidades de librerías como Snowball Stemmer,
OpenNLP, Berkeley Syntactic Parser, ClearNLP y Stanford CoreNLP pueden sustituir
alguno de los componentes del pipeline o incorporarse como uno nuevo. De esta manera
se pueden aprovechar otras técnicas de NLP que permitirían ajustar y adaptar el
procesamiento total, y lograr resultados más específicos o precisos.
69
● La utilización del lenguaje de UIMA Ruta permite realizar extracción de información de los
documentos de una manera muy potente y flexible por ser un lenguaje de paradigma
declarativo. Se pueden escribir nuevas reglas que obtengan mejores resultados o que
apliquen para otros atributos de calidad. El diccionario de taxonomías también es flexible y
puede ser modificado por un usuario que no necesariamente tenga conocimientos de
programación.
6.2. Limitaciones
La herramienta propuesta posee una serie de limitaciones observadas durante la
evaluación experimental. Las mismas, se listan a continuación:
● Los documentos que la herramienta implementada toma como entrada deben estar en
idioma inglés y no se admite ningún otro idioma. Además, el formato debe ser texto plano,
sin tablas, separadores, ni estructuras de presentación de información.
● La detección de secciones con información de atributos de calidad suele tener falsos
positivos entre sus resultados, los cuales pueden ingresar ruido para las etapas posteriores
y obtener un resultado final confuso.
● La detección de patrones gramaticales para proveer al componente Natural Language
Generation se realiza por medio de extractores implementados en Java. Se debería
soportar que fácilmente se añadan nuevos extractores para patrones que aún no se habían
contemplado, y estos patrones podrían aún variar para diferentes atributos de calidad. La
implementación actual requiere que si se desea contemplar otros patrones se debe contar
con un desarrollador Java.
● El proceso requiere que el analista valide las oraciones identificadas como texto con
información sobre atributos de calidad y luego valide las secciones de escenarios de
calidad detectados para, finalmente, obtener los escenarios concretos. Además, se debe
contar con las reglas y diccionarios para cada atributo de calidad, los cuales deberían
ajustarse conforme a sus criterios. Lo ideal sería automatizar todo el proceso minimizando
la intervención humana.
6.3. Trabajos futuros
Si bien se alcanzaron los objetivos propuestos, se identificaron algunos trabajos futuros
que escapan al alcance del presente trabajo pero que poseen potencial para investigaciones o
tesis a partir de este enfoque. Las siguientes propuestas podrían ser consideradas:
● Definir reglas, diccionarios y taxonomías, y extractores de patrones para contemplar otros
atributos de calidad a parte de performance; y aún refinar el proceso del enfoque planteado
para obtener resultados más precisos y efectivos.
● Al obtener varios escenarios de calidad para un mismo documento de requerimientos, los
mismos no suelen tener todos la misma relevancia, importancia y efectividad. Se pueden
priorizar escenarios obtenidos con algunas de las diferentes técnicas de priorización
70
sistemática existentes como Analytic Hierarchy Process [Saaty 1994]. Además, se puede
aplicar priorización a las secciones generadas y aún las oraciones identificadas con
información de atributos de calidad.
● Las métricas de similitud semántica pueden ser muy aplicables para evaluar los resultados
y reajustar la técnica, utilizando herramientas como SEMILAR8 .
● El campo de la Inteligencia Artificial está en constante desarrollo y ya se cuenta con
comunidades y herramientas que aportan descubrimientos y técnicas cada vez más
sofisticadas y eficaces. Por ejemplo, integrando al presente enfoque Machine Learning,
podrían obtenerse mejores resultados; incluso otras técnicas dentro del campo de la
lingüística computacional.
● Este enfoque se podría implementar en otros lenguajes como C++ (UIMA lo permite), o
Python, que pertenece a un paradigma muy apropiado para resolver este tipo de
problemas y hay bibliotecas como NLTK9 que son muy aceptadas en la comunidad de
procesamiento de lenguaje natural.
8 http://www.semanticsimilarity.org/ 9 http://www.nltk.org/
71
7 Apéndice
7.1. Escenarios generados y reales (benchmark)
En este apéndice se listan los escenarios utilizados para la aplicación de las métricas de
similitud, identificados numéricamente, con los prefijos G y R para los escenarios generados y
reales, generados por un experto, respectivamente.
Escenarios de calidad generados por QAGen
G01 system reflects transmission in the UI
G02 system displays property in the alarm viewer
G03 system selects item in the Hierarchy Tree Editor
G04 system reflects transmission in the UI normal conditions
G05 system displays property in the alarm viewer normal conditions
G06 system selects item in the Hierarchy Tree Editor normaString gen = "conditions";
G07 system reflects transmission in the UI normal conditions executes a command
G08 system displays property in the alarm viewer normal conditions executes a command
G09 system selects item in the Hierarchy Tree Editor normal conditions executes a command
G10 system reflects transmission in the UI normal conditions publishes an event
G11 system displays property in the alarm viewer normal conditions publishes an event
G12 system selects item in the Hierarchy Tree Editor normal conditions publishes an event
G13 reflects transmission in the UI
G14 displays property in the alarm viewer
G15 selects item in the Hierarchy Tree Editor
G16 reflects transmission in the UI normal conditions
G17 displays property in the alarm viewer normal conditions
G18 selects item in the Hierarchy Tree Editor normal conditions
G19 reflects transmission in the UI normal conditions executes a command
G20 displays property in the alarm viewer normal conditions executes a command
G21 selects item in the Hierarchy Tree Editor normal conditions executes a command
G22 reflects transmission in the UI normal conditions publishes an event
G23 displays property in the alarm viewer normal conditions publishes an event
G24 selects item in the Hierarchy Tree Editor normal conditions publishes an event
Tabla 7.1: Códigos de referencia a los escenarios de calidad generados por QAGen
72
Escenarios de calidad reales
R1a field system detects a change of some value and notifies mslite the system operates under normal conditions the value is updated on all user screens that display the old value within 3seconds
R2an alarm occurs either originating in a field system or in mslite the system operates under normal conditions the alarm is displayed on the user interfaces of all users that must receive the alarm within 3 seconds
Tabla 7.2: Códigos de referencia a los escenarios de calidad reales
7.2. Performance sentences del caso de estudio MSLite
En este apéndice se listan listan las oraciones detectadas por QAGen, relacionadas con el
atributo de calidad performance (performance sentence), para el caso de estudio MSLite.
When the FSS updates a value either by itself or after executing a command that it received from MSLite it publishes a COV event.
The successful transmission of a command to the FSS is reflected in the UI. If the FSS fails to execute a command that it received, and notifies MSLite, then the UI must be updated to reflect the failed command.
The following properties for the alarm are displayed in the alarm viewer: (i) Alarm Name - The custom name of the alarm specified at the time of the creation of the Alarm Rule.
System displays “Alarm Acknowledgment Request” dialog for all logged in users with read access to the associated alarm property.[UC004.UI001] This dialog shows the following elements: a. Alarm Name - The custom name of the alarm specified at the time of the creation of the Alarm Rule.
2. System displays the “Configure Hierarchies” screen.[UC101.UI001] 3. User selects the “Create Hierarchy” button.[UC101.UI001] 4. System displays the “Create Hierarchy” screen.[UC101.UI002] 5. User enters a hierarchy name in step 1.[UC101.UI002] 6. User enters a hierarchy description in step 2.[UC101.UI002] 7. User selectively instantiates one of the following extending use cases: UC104: Create Logical Node UC105: Delete Logical Node (only after a logical node has been created) UC106: Rename Logical Node (only after a logical node has been created) UC107: Add Field Object UC108: Remove Field Object (only after a field object has been added) 8. User selects the “Create Hierarchy” button.[UC101.UI003] 9. System verifies the hierarchy name is unique.
Extension 108.8b 8b – No item is selected in the “Hierarchy Tree Editor”: 1. System displays an error message asking the user to select a field object before using this button.
The value is updated on all user screens that display the old value within 3 seconds.
The alarm is displayed on the user interfaces of all users that must receive the alarm within 3 seconds.
The Time durations specified in this scenario are performance goals and are not to be taken as hard deadlines.
Only relevant GUI screens for these ‘m’ users will reflect the update within having received the notification from the FSS.
Tabla 7.3: Performance sentences detectadas en MSLite
7.3. Valores obtenidos al aplicar las métricas
En este apéndice se listan todos los valores obtenidos al aplica las cinco estrategias de
comparación (similitud) entre los escenarios generados con el procedimiento general y los
escenarios de calidad de referencia.
73
Cosine Jaccard JaroWinklerNormalizedLevenshtein
SorensenDice
Suma total
R1 G01 0,276916 0,084746 0,56283 0,159794 0,15625 0,56283G02 0,292999 0,11236 0,541952 0,180412 0,20202 0,541952G03 0,27693 0,092896 0,575005 0,201031 0,17 0,575005G04 0,372687 0,167598 0,593224 0,226804 0,287081 0,593224G05 0,413675 0,213483 0,597372 0,231959 0,351852 0,597372G06 0,317247 0,143564 0,602418 0,252577 0,251082 0,602418G07 0,385452 0,194737 0,619637 0,293814 0,325991 0,619637G08 0,421967 0,238095 0,624175 0,298969 0,384615 0,624175G09 0,391887 0,205128 0,634516 0,309278 0,340426 0,634516G10 0,36315 0,175258 0,638156 0,28866 0,298246 0,638156G11 0,395594 0,21875 0,61973 0,293814 0,358974 0,61973G12 0,371106 0,18593 0,637892 0,304124 0,313559 0,637892G13 0,198342 0,057143 0,568553 0,128866 0,108108 0,568553G14 0,200603 0,073034 0,545918 0,14433 0,136126 0,545918G15 0,209041 0,071429 0,544567 0,164948 0,133333 0,544567G16 0,313649 0,141243 0,584881 0,201031 0,247525 0,584881G17 0,342336 0,174157 0,575608 0,195876 0,296651 0,575608G18 0,324462 0,15847 0,583053 0,216495 0,273585 0,583053G19 0,333342 0,170213 0,614927 0,268041 0,290909 0,614927G20 0,358697 0,201058 0,599615 0,262887 0,334802 0,599615G21 0,344984 0,185567 0,603816 0,278351 0,313043 0,603816G22 0,309425 0,151042 0,620055 0,262887 0,262443 0,620055G23 0,331105 0,182292 0,609419 0,257732 0,30837 0,609419G24 0,322504 0,166667 0,611959 0,273196 0,285714 0,611959
Total R1 0,421967 0,238095 0,638156 0,309278 0,384615 0,638156
Table 7.4: Valores obtenidos comparando contra R1
Cosine Jaccard JaroWinklerNormalizedLevenshtein
SorensenDice
Suma total
R2 G01 0,315353 0,081522 0,54779 0,149533 0,150754 0,54779G02 0,46227 0,138889 0,535689 0,168224 0,243902 0,535689G03 0,297318 0,08377 0,582594 0,182243 0,154589 0,582594G04 0,379267 0,16129 0,603072 0,196262 0,277778 0,603072G05 0,53604 0,238889 0,576523 0,219626 0,38565 0,576523G06 0,332609 0,149758 0,597335 0,214953 0,260504 0,597335G07 0,359378 0,17 0,626594 0,247664 0,290598 0,626594G08 0,496389 0,242268 0,603242 0,252336 0,390041 0,603242G09 0,363638 0,180488 0,624885 0,257009 0,305785 0,624885G10 0,352 0,163366 0,604551 0,247664 0,280851 0,604551G11 0,484709 0,235897 0,595467 0,252336 0,381743 0,595467G12 0,356558 0,173913 0,624885 0,257009 0,296296 0,624885G13 0,243998 0,04918 0,540907 0,126168 0,09375 0,540907G14 0,408667 0,106145 0,540618 0,135514 0,191919 0,540618G15 0,244068 0,063158 0,543572 0,154206 0,118812 0,543572G16 0,322861 0,12973 0,577334 0,17757 0,229665 0,577334G17 0,490927 0,206704 0,571537 0,196262 0,342593 0,571537G18 0,335286 0,152632 0,60004 0,196262 0,26484 0,60004G19 0,307817 0,140704 0,594233 0,242991 0,246696 0,594233G20 0,452128 0,212435 0,611524 0,247664 0,350427 0,611524G21 0,323194 0,161765 0,608321 0,252336 0,278481 0,608321G22 0,299564 0,134328 0,590497 0,242991 0,236842 0,590497G23 0,439908 0,206186 0,608304 0,247664 0,34188 0,608304G24 0,315409 0,15534 0,60375 0,252336 0,268908 0,60375
Total R2 0,53604 0,242268 0,626594 0,257009 0,390041 0,626594
Table 7.5: Valores obtenidos comparando contra R2
74
7.4. Herramienta QAGen
En este apéndice se muestran capturas de pantalla de la herramienta QAGen, desarrollada
para implementar el enfoque de la técnica propuesta para el presente trabajo.
Figura 7.1: Pantalla de generación de escenarios de calidad
75
Figura 7.2: Pantalla del contexto de la QA Sentence
8 Referencias[Bass 2003] Bass, Clements. Soft Arch in Practice. Second. Longman. 2003
[Gorton 2011] I. Gorton. Essential Software Architecture. ,2011
[Smith 1993] C. Smith, L. Williams. , Software Performance Engineering: A Case Study Including Performance Comparison with Design Alternatives, 1993
[Shaw 1996] M. Shaw, D. Garlan.. Software Architecture: perspectives on an emergingdiscipline.. . . 1996
[Haak 2005] Haak, B., Pryor, A. and Marcos, C. .Identificacion Temprana de Aspectos. ,2005
[Dorr 2003] Dörr, J., et al. , Eliciting Efficiency Requirements with Use Cases, 2003
[Sampaio 2007] Sampaio, Americo & Rashid, Awais & Chitchyan, Ruzanna & Rayson, Paul., EA-Miner: Towards Automation in Aspect-Oriented Requirements Engineering, 2007
[Bertoni 2010] Francisco Andrés Bertoni Sebastián Villanueva, Identificación de Atributos de Calidad en requerimientos. , 2010
[Wojcik 2013] Rob Wojcik, Architecting in a Complex World: Eliciting and Specifying Quality Attribute Requirements, 2013
[IEEE 1992] Software & Systems Engineering Standards Committee, Standard for a Software Quality Metrics Methodology, 1992
[Barbacci 1995] M. Barbacci, M. Klein, T. Longstaff, C. Weinstock. Quality Attributes. . Software Engineering Institute. 1995
[Bachmann 2007] F. Bachmann, L. Bass, R. Nord. Modifiability Tactics . . . 2007
[Medvidovic 2003] N. Medvidovic, A. Egyed, P. Gruenbacher, Stemming architectural erosion by coupling architectural discovery and recovery, 2003
[Klein 2000] Rick Kazman, Mark Klein Paul Clements. ATAM: Method for Architecture Evaluation. . . 2000
[Turing 1950] A. M. Turing, Computing Machinery and Intelligence, 1950
[Jurafsky 2000] Daniel Jurafsky and James H. Martin. . . Alan Apt. 2000
[Craig 2013] Tim Craig.The Art of Tokenization. ,2013
[Mitchell 1993] Mitchell P. Marcus Mary Ann Marcinkiewicz Beatrice Santorini, Building a large annotated corpus of English: the penn treebank, 1993
[Dale 1995] Dale, R. and Reiter, E. , Computational interpretations of the Gricean maxims in the generation of referring expressions, 1995
[Reiter 2000] Dale, R. and Reiter. Building Natural Language Generation Systems . . . 2000
[Sutton 2002] Sutton Jr, Stanley & Rouvellou, I.. Modeling of Software Concerns in Cosmos. . . 2002
[Rashid 2003] A. Rashid, A. Moreira, and J. Araujo, Modularisation and Composition of Aspectual Requirements, 2003
[Whittle 2004] J. Whittle and J. Araujo, Scenario Modeling with Aspects, 2004
76
[Sawyer 2002] P. Sawyer, P. Rayson, and R. Garside, REVERE: Support for Requirements Synthesis from Documents,
[Rago 2014] Alejandro Rago, Claudia Marcos, J. Andres Diaz-Pace, Assisting requirements analyststo find latent concerns with REAssistant,
[Shaw1996] M. Shaw, D. Garlan.. Software Architecture: perspectives on an emergingdiscipline.. . .1996
[Mikolov 2013] T. Mikolov, K. Chen, G. Corrado, J. Dean.. Efficient Estimation of Word Representations in Vector Space. . . 2013
[Bethard 2014] S. Bethard, P. Ogren, and L. Becker, ClearTK 2.0: Design Patterns for Machine Learning in UIMA, 2014
[Gatt 2009] Albert Gatt, Ehud Reiter, SimpleNLG: A realisation engine for practical applications, 2009
[Brown 2011] Brown N, Nord R, Ozkaya I, Pais M , Analysis and managementof architectural dependencies in iterative release planning, 2011
[Mullick 2006] Mullick N, Bass M, Houda Z, Paulish P, Cataldo M, Siemens globalstudio project: experiences adopting an integrated gsd infrastructure., 2006
[Dale 2000] Robert Dale, Hermann Moisl, Harold Somers. Handbook of Natural Language Processing. . CRC Press . 2000
[Dale 1997] Ehud Reiter, Robert Dale, Building Applied Natural Language GenerationSystems, 1997
[Manning 2008] Marie-Catherine de Marneffe and Christopher D. Manning, Stanford typed dependencies manual, 2008
[Marcinkiewicz 1994] Mitchell Marcus, Grace Kim, Mary Ann Marcinkiewicz, et. al., The Penn Treebank: annotating predicate argument structure, 1994
[Bell 2011] Rick Bell, Course registration system., 2011
[Greenwood 2011] Phil Greenwood., Tao: A testbed for aspect oriented software development., 2011
[Haimei 2010] Haimei Zhang and Kerong Ben, Architectural design of the health watch system with an integrated aspect-oriented modeling approach, 2010
[Gersmann 2005] Stefan Gersmann. Development of Strategies for Global Software Development. . Diplomarbeit, Technische Universitat Munchen, Fakultat fur Informatik. 2005
[Rajaraman 2012] A. Rajaraman and J. D. Ullman. Mining of massive datasets. . Cambridge University Press. 2012
[Dice 1945] L. R. Dice, Measures of the amount of ecologic association between species, 1945
[Huang 2008] A. Huang, Similarity measures for text document clustering, 2008
[Levenshtein 1966] Levenshtein, Vladimir I. , Binary codes capable of correcting deletions, insertions, and reversals, 1966
[Winkler 1990] Winkler, W. E., String Comparator Metrics and Enhanced Decision Rules in the Fellegi-Sunter Model of Record Linkage, 1990
[Jaro 1989] Jaro, Matthew A, Advances in Record-linkage Methodology a Applied to Matching the 1985 Census of Tampa, Florida, 1989
[Saaty 1994] Thomas L Saaty, How to make a decision: the analytic hierarchy process, 1994
77
