R. Sharma, S. Gulia and K. K. Biswas, Automated generation of activity and sequence diagrams from natural language requirements, 2014 9th International Conference on Evaluation of Novel Approaches to Software Eng

Machine Translated by Google
Vea discusiones, estadísticas y perfiles de autor para esta publicación en: https://www.researchgate.net/publication/289466272
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural
Artículo ∙ Enero 2014
CITAS
LEE
17
543
3 autores:
Richa Sharma
sarita gulia
Instituto Indio de Tecnología de Delhi
UNIVERSIDAD KR MANGALAM
18 PUBLICACIONES 120 CITAS
14 PUBLICACIONES 69 CITAS
VER EL PERFIL
Kanad Biswas
Instituto Indio de Tecnología de Delhi
101 PUBLICACIONES 1.354 CITAS
VER EL PERFIL
Algunos de los autores de esta publicación también están trabajando en estos proyectos relacionados:
Detección de actividad humana inusual usando Markov Logic Networks Ver proyecto
Neurociencia Cognitiva Ver proyecto
Todo el contenido que sigue a esta página fue subido por Sarita Gulia el 26 de febrero de 2021.
El usuario ha solicitado la mejora del archivo descargado.
VER EL PERFIL
Machine Translated by Google
Generación automatizada de diagramas de actividad y secuencia a partir de
Requisitos del lenguaje natural
1
Richa Sharma1, Sarita Gulia2 y KK Biswas3
Escuela de Tecnología de la Información, IIT Delhi, Nueva Delhi, India
2
Departamento de Ciencias de la Computación, Facultad de Ingeniería Dronacharya, Gurgaon, India
3
Departamento de Informática e Ingeniería, IIT Delhi, Nueva Delhi, India
Palabras clave: Modelos UML, Diagrama de Actividad, Diagrama de Secuencia, Procesamiento del Lenguaje Natural, Frames.
Abstracto:
El proceso de análisis de requisitos implica el desarrollo de modelos abstractos para el sistema de software previsto o
propuesto. Estos modelos se utilizan para ayudar a refinar y enriquecer los requisitos del sistema. El lenguaje de modelado
unificado (UML) se ha convertido en el estándar para los requisitos de software de modelado. Sin embargo, los requisitos de
software se capturan en forma de lenguaje natural y la generación de modelos UML a partir de requisitos de lenguaje natural
depende en gran medida de la experiencia individual. En este documento, presentamos un enfoque hacia la generación
automatizada de modelos UML de comportamiento, a saber, diagramas de actividad y diagramas de secuencia. Nuestro
enfoque se basa en transformar las declaraciones de requisitos en representaciones estructuradas intermedias: marcos y
luego, traducirlos a los modelos UML de comportamiento. Estamos utilizando patrones de conocimiento gramatical y análisis
léxico y sintáctico de declaraciones de requisitos para completar marcos para las declaraciones correspondientes. El
conocimiento almacenado en marcos se utiliza luego para generar automáticamente un diagrama de actividad y secuencia.
Presentamos nuestro enfoque a través de los estudios de casos realizados.
1. INTRODUCCIÓN
La ingeniería de requisitos (RE) es la fase más crucial en todo el
ciclo de vida del desarrollo de software.
El proceso de RE implica obtener, analizar, documentar y validar
los requisitos.
Los modelos se diseñan y utilizan durante el proceso de RE para
ayudar a derivar y analizar los requisitos de un sistema
(Sommerville, 2011). Los modelos de requisitos ayudan a cerrar
las brechas de comunicación entre las expectativas de los
clientes y la comprensión de los requisitos por parte de los
analistas. Durante la fase RE, los modelos del sistema existente
ayudan a aclarar a los analistas lo que hace el sistema existente;
y, los modelos del nuevo sistema ayudan a los analistas, así
como a las partes interesadas, a comprender y visualizar los
requisitos del sistema propuesto (Sommerville, 2011). Los
requisitos recopilados durante la obtención de requisitos
generalmente se capturan en forma de lenguaje natural (NL) en
la industria.
Sin embargo, generar modelos a partir de la representación de
requisitos de NL es una tarea que requiere mucho esfuerzo y
tiempo, ya que no existe un soporte automatizado para generar
modelos directamente a partir de los requisitos de NL.
Debido a la falta de soporte automatizado, el desarrollo
Los modelos manualmente siguen siendo más una preocupación
subjetiva que depende de la experiencia y los conocimientos del
individuo. Por lo tanto, la necesidad de una herramienta de
soporte automatizado para la generación de modelos a partir de
los requisitos de NL.
Una gran cantidad de esfuerzo de investigación se ha
dirigido a identificar modelos adecuados para representar
requisitos y también a automatizar el proceso de generación de
esos modelos a partir de la representación de requisitos de NL.
Los diagramas de flujo de datos y los gráficos estructurados son
los modelos generados como resultado del análisis estructurado
(Svoboda, 1997). El análisis orientado a objetos implica dibujar
diagramas UML que representan el comportamiento estático y
dinámico del sistema propuesto (Booch, 1994). Los gráficos
conceptuales se han utilizado para representar múltiples vistas
de los requisitos del software (Delugach, 1996). De estos
enfoques, UML se ha convertido en el lenguaje de modelado
estándar para el modelado orientado a objetos en la industria.
Se han propuesto varios enfoques automatizados y
semiautomáticos para automatizar la generación de diagramas
UML a partir de los requisitos de NL, como se analiza en detalle
en la sección 2. UML admite varios tipos de diagramas con el
objetivo de representar los detalles del sistema propuesto desde
diferentes perspectivas. Sin embargo,
Sharma R., Gulia S. y Biswas K..
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural.
DOI: 10.5220/0004893600690077
En Actas de la 9ª Conferencia Internacional sobre Evaluación de Nuevos Enfoques de Ingeniería de Software (ENASE­2014), páginas 69­77
ISBN: 978­989­758­030­7
Copyright c 2014 SCITEPRESS (Publicaciones de Ciencia y Tecnología, Lda.)
69
Machine Translated by Google
ENASE 2014 ­ 9° Congreso Internacional de Evaluación de Nuevos Enfoques de Software para Ingeniería de Software
no todos los diagramas UML se usan con frecuencia; y una encuesta
lenguaje de modelado, útil para visualizar, especificar, construir y
realizada por Erickson y Siau (Erickson y Siau, 2007) informó que
documentar los artefactos del sistema intensivo en software (OMG,
los usuarios suelen trabajar con cinco tipos de diagramas UML, a
2003).
saber: diagramas de clase, diagramas de casos de uso, diagramas
UML define tres amplias categorías de diagramas, a saber (a)
de estado, diagramas de actividad y diagramas de secuencia. La
diagramas estáticos como diagramas de clases y objetos; (b)
revisión de la literatura en el contexto de la generación automática
diagramas de comportamiento como diagramas de casos de uso,
de diagramas UML a partir de los requisitos de NL indica que los
diagramas de actividad, diagramas de secuencia y diagramas de
diagramas de actividad y los diagramas de secuencia no se han
estado; (c) diagramas de implementación como diagramas de
investigado de manera exhaustiva, excepto en algunos casos como
componentes y diagramas de implementación.
(Li, 1999), (Yue et al., 2010). Motivados por la necesidad de
Estos diagramas proporcionan múltiples perspectivas del sistema
generación automatizada de modelos a partir de los requisitos de
previsto. Al centrarnos en los diagramas de actividad y secuencia
NL y la encuesta de Erickson y Siau, así como la encuesta de
en este documento, discutiremos estos diagramas en detalle a
literatura, enfocamos nuestro trabajo hacia la generación
continuación.
automatizada de diagramas de actividad y diagramas de secuencia.
El trabajo realizado en (Li, 1999), (Yue et al., 2010) espera una
2.1.1 Diagrama de actividades
entrada estructurada en forma de casos de uso textuales para
generar los diagramas respectivos. Sin embargo, nuestro enfoque
Los diagramas de actividad muestran el flujo de control de
no impone restricciones estructurales sobre los requisitos de entrada
procedimiento mientras se procesa una actividad. Los diagramas de
para la generación automatizada de diagramas de actividad y
actividad se utilizan mejor para modelar procesos de negocios de
diagramas de secuencia. Procesamos los requisitos de entrada para
alto nivel a nivel de unidad de negocios o para modelar el flujo de
estructurarlos en forma de marcos (Minsky, 1988) utilizando
procesos de bajo nivel. Estos son útiles para visualizar partes de
Grammatical Knowledge Patterns (Bowker, 2003) y análisis léxico y
pequeños escenarios en caso de que los casos de uso sean
sintáctico de los enunciados de requisitos. La representación
bastante grandes y complejos. Dicha representación visual en forma
estructurada de los requisitos ayuda a comprender mejor la
de diagramas de actividad puede capturar flujos de trabajo integrados
semántica de los requisitos; identificar a los actores o agentes de la
en descripciones de casos de uso. Por lo tanto, los diagramas de
acción; la secuencia de acciones e interacciones entre acciones y
actividad proporcionan una representación más detallada y
agentes; y también puede procesar declaraciones complejas.
comprensible de un escenario de caso de uso. Una actividad en
los diagramas de actividad se modela como un rectángulo. El
diagrama comienza con un círculo sólido conectado a la actividad
inicial.
Las actividades están conectadas con otras actividades a través de
una línea de transición modelada con flechas. Cualquier condición
El documento está organizado de la siguiente manera: la
Sección 2 ofrece una descripción general de los modelos UML de
comportamiento, los patrones de conocimiento y los marcos junto
con el trabajo relacionado realizado. La sección 3 presenta nuestro
enfoque seguido por el estudio de caso presentado en la sección 4.
En la sección 5, presentamos la discusión y la conclusión.
de toma de decisiones se modela utilizando una caja de diamantes.
2.1.2 Diagrama de secuencia
Los diagramas de secuencia también están destinados a mostrar un
flujo detallado para un caso de uso específico o una parte de él.
El diagrama de secuencia es un diagrama de interacción que
muestra el flujo de llamadas o mensajes entre diferentes agentes u
2. FONDO
objetos de forma secuencial.
Un diagrama de secuencia tiene dos dimensiones: la dimensión
vertical muestra la secuencia de llamadas o mensajes en el orden
2.1 modelos UML
de tiempo en que ocurren; y, la dimensión horizontal muestra las
instancias de objeto o agente a las que se envían los mensajes.
Como la guía UML (Especificación del lenguaje de modelado
unificado, 2003) establece la importancia del modelado: desarrollar
Los dos diagramas discutidos anteriormente son importantes
un modelo para un sistema de software de potencia industrial antes
desde el punto de vista de obtener una comprensión clara y precisa
de su construcción o renovación es tan esencial como tener un plano
para un edificio grande, los buenos modelos son esenciales para la
de un caso de uso grande y complejo que involucra interacciones
entre varios objetos/agentes. El desafío en el procesamiento de
comunicación entre equipos de proyecto, clientes y partes
descripciones de casos de uso es que se captura en forma de NL.
interesadas. UML fusiona los conceptos de Tecnología de modelado
de objetos (OMT) y Análisis y diseño orientado a objetos (OOAD).
El desafío sigue siendo el mismo incluso si los detalles del escenario
UML es una imagen
del caso de uso se capturan en forma de texto fluido en lugar de
un caso de uso estructurado. NL en sí
70
Machine Translated by Google
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural
es ambiguo y puede ser interpretado de manera diferente por
los analistas y el equipo de desarrollo. También es posible
que los expertos del dominio que expresan los escenarios
como texto normal o caso de uso textual puedan perder
alguna información que tienden a sentir implícita. Sin
embargo, este conocimiento implícito puede no estar con los
analistas y desarrolladores. Una representación visual del
escenario puede ser útil para extraer más información y
comprender mejor los requisitos.
2.2 Patrones y marcos de conocimiento
El procesamiento de texto de NL requiere un análisis léxico
y sintáctico de las declaraciones de NL. Patrones: el
conocimiento gramatical o específico del dominio resulta útil
para mejorar la calidad del análisis. Los patrones de
conocimiento, en general, se pueden definir como palabras,
combinaciones de palabras o rasgos paralingüísticos que
frecuentemente indican relaciones conceptuales (Marshman
et al., 2002). Han sugerido tres tipos de patrones: patrones
léxicos para indicar una relación; patrones gramaticales, que
son combinaciones de partes del discurso; y Patrones
Paralingüísticos, que incluyen puntuación, paréntesis,
estructura del texto, etc.
Los patrones de conocimiento gramatical (GKP) se han
estudiado ampliamente en la lingüística inglesa (Hunston y
Francis, 2000) con el objetivo de comprender la semántica
de las declaraciones y extraer información útil. Hemos
utilizado el GKP para categorizar los enunciados en simples
y complejos y luego extraer conceptos de ellos.
La información analizada, obtenida después de aplicar el
análisis sintáctico y los patrones, debe almacenarse en un
formato adecuado que pueda ser referenciado y reutilizado.
Dado que se requiere metainformación de la unidad sintáctica
para referenciar y reutilizar, encontramos marcos como una
opción apropiada para representar los detalles de la oración.
Los marcos son estructuras de relleno de ranuras que se
utilizan para almacenar y representar conocimientos, donde
las ranuras representan aspectos clave y los rellenos actúan
como contenedores de espacio para los valores clave
correspondientes (Minsky, 1988). Los marcos se pueden
utilizar para representar el conocimiento como objetos
estructurados. Los marcos dividen el conocimiento en
subestructuras, que se pueden conectar entre sí según sea
necesario, para formar la idea completa. (Fikes y Kehler,
1985) han sugerido que los marcos son una forma concisa
de representar el conocimiento de manera Orientada a
Objetos y son un medio eficiente para el razonamiento.
2.3 Trabajo relacionado
Los analistas y profesionales de la industria utilizan NL como
el modo preferido de representar y compartir la
requisitos según lo informado en varias encuestas como
(Luisa et al., 2004). La importancia de identificar los
conceptos, las relaciones en los documentos y visualizarlos
en forma de modelos ha sido enfatizada por varios
investigadores en la literatura. La motivación para generar
modelos visuales automáticamente para los requisitos del NL
se deriva del hecho de que los modelos mejoran la claridad
y la comprensión del escenario representado.
La herramienta Use Case Driven Development Assistant
(UCDA) ayuda a desarrollar diagramas de clase, modelos de
casos de uso y también a visualizar estos modelos usando la
herramienta Rational Rose (Subramaniam et al., 2004).
La herramienta hace uso del análisis sintáctico de las
declaraciones de requisitos para desarrollar diagramas de
casos de uso. La herramienta Linguistic Assistant for Domain
Analysis (LIDA) (Overmeyer et al., 2001) ayuda a los analistas
a identificar elementos de tipo en el modelo orientado a
objetos como clase, atributo, rol, etc. LIDA admite
descripciones de hipertexto del modelo para ayudar a validar
un modelo. Sin embargo, LIDA requiere la interacción del
usuario para marcar una palabra o frase como elemento de modelo candidato.
(Vinay et al., 2009), (Ibrahim y Ahmad, 2010), (More y
Phalnikar, 2012) y (Joshi y Dehspande, 2012) siguen
enfoques similares de procesamiento del lenguaje natural
para identificar conceptos en los requisitos; las relaciones
entre los conceptos y luego generar diagramas de clases.
(Herchi y Abdessalem, 2012) han sugerido reglas para
identificar conceptos y luego generar diagramas de clases a
partir de los requisitos del NL. Ormandjieva e Ilieva han
sugerido extraer el modelo híbrido gráfico de los requisitos
textuales (Ormandjieva e Ilieva, 2006). El generador de
modelos UML estáticos a partir del análisis de requisitos
(SUGAR) (Deeptimahanti y Sanyal, 2008) sigue el análisis
orientado a objetos para la obtención de objetos a partir de
requisitos de NL para generar un modelo de clase UML
estático y modelos de casos de uso. Los autores sugieren
reglas de reconstrucción sintáctica para declaraciones de
requisitos e identifican actores como frases nominales y
casos de uso como flujos de eventos en el sistema.
El generador de modelos UML a partir del análisis de
requisitos (UMGAR) (Deeptimahanti y Sanyal, 2011)
proporciona soporte semiautomático basado en el análisis
morfológico y sintáctico de declaraciones de requisitos para
generar modelos de casos de uso, modelos de clases y
diagramas de colaboración que representan la relación entre
los actores y los objetos. . Li ha propuesto un enfoque
semiautomático para traducir casos de uso textuales a
diagramas de secuencia (Li, 1999). Sin embargo, su enfoque
requiere que los analistas primero reescriban declaraciones
complejas como declaraciones simples. Entonces, el
remitente, los receptores y las acciones son
71
Machine Translated by Google
ENASE 2014 ­ 9° Congreso Internacional de Evaluación de Nuevos Enfoques de Software para Ingeniería de Software
identificados a partir de declaraciones de requisitos reformuladas
Parser (Marneffe et al., 2006) respectivamente. Nuestro estudio
para generar una secuencia de acciones. Yue, Brand y Labiche
manual nos alentó a identificar seis patrones genéricos que, a su
presentan un enfoque automatizado para generar diagramas de
vez, ayudan a clasificar las declaraciones de requisitos y almacenar
secuencia y actividad a partir de los requisitos de NL expresados
la información semántica de la declaración en forma de marcos.
como casos de uso, siguiendo algunas reglas de restricción; dicha
forma de casos de uso se denomina Modelos de casos de uso
restringidos (RUCM)
Hemos desarrollado un enfoque automatizado para identificar
estos patrones en las declaraciones de requisitos. El algoritmo
(Yue et al., 2010). Los autores han desarrollado una herramienta,
automatizado se basa en realizar primero un análisis léxico y
aToucan, para transformar casos de uso en RUCM en diagramas
sintáctico de las declaraciones de requisitos utilizando Stanford
de secuencia y actividad.
El trabajo anterior realizado hacia la generación semiautomática
Tagger and Parser. El algoritmo de coincidencia de cadenas, luego,
hace coincidir las etiquetas de dependencia de las declaraciones
o automatizada de modelos UML ha hecho uso del análisis léxico y
para que coincidan con las etiquetas predefinidas de los marcos y
sintáctico de los requisitos sin ninguna representación intermediaria.
luego, completa el valor correspondiente en el marco.
En nuestro enfoque, hemos hecho uso de marcos como
representación intermediaria de las declaraciones de requisitos,
cuyos detalles se analizan en la siguiente sección. Un escenario se
Las subsecciones a continuación presentan detalles de GKP
patrones, así como las estructuras de marco propuestas:
puede expresar de múltiples maneras; sin embargo, la representación
estructurada como marco aún puede capturar la esencia del
3.1.1 Identificación GKP
escenario; esta es la principal ventaja de nuestro enfoque.
En esta subetapa, discutimos nuestro enfoque para la identificación
de GKP. Elegimos para ello las siguientes propiedades lingüísticas:
• Estructura de la oración: Activa o Pasiva.
3 NUESTRO ENFOQUE
• Partes especiales de la oración (por ejemplo: preposición,
Nuestro enfoque sigue generando una representación estructurada
• Palabras clave de condición previa (por ejemplo: después, antes, si
marcadores, conjunciones, etc.)
de declaraciones de requisitos y luego, usando esa representación
para generar diagramas de actividad y diagramas de secuencia
automáticamente. La ventaja de este enfoque es doble: primero,
podemos procesar sentencias complejas; y, en segundo lugar, el
conocimiento estructurado puede reutilizarse para realizar consultas
y razonar. Primero presentamos una breve descripción general de
etc.)
Aquí se presenta un resumen de los patrones identificados: • Voz
activa: una declaración en voz activa siempre sigue la forma:
<sujeto> <verbo principal> <objeto>
nuestro enfoque de identificación de GKP y paso de población de
Usamos etiquetas de dependencia en la salida del analizador para
marcos; los detalles de la misma han sido discutidos en (Bhatia et
extraer el patrón indicado anteriormente.
al., 2013). Luego, discutiremos el paso de generación del diagrama
• Voz pasiva: Una declaración en voz pasiva
de actividad y secuencia a través de un escenario de ejemplo.
siempre sigue la forma:
<forma de TO BE> <verbo en PASADO
PARTICIPIO>
Las siguientes subsecciones resumen brevemente los detalles
relevantes:
3.1 Población de cuadros
Cualquier verbo en declaración pasiva siempre se etiqueta
como "verbo en participio pasado" y, este verbo está precedido
por un verbo auxiliar de la forma de <to be>. Las formas de <to
be> pueden ser {is, are, am was, were, has been, have been, ,
had been, will be, will have been, being}.
Nuestro enfoque hacia la identificación de GKP y la población de
marcos se puede dividir en dos fases: fase de aprendizaje y fase de
automatización. Primero aprendimos GKP presente en las
declaraciones de requisitos al realizar un análisis manual del corpus
de requisitos. Durante el estudio manual, tomamos un subconjunto
de 25 documentos de requisitos y observamos patrones gramaticales
frecuentes. El estudio manual se basó en el resultado del análisis
léxico y sintáctico de las declaraciones de requisitos utilizando
Stanford POS Tagger (Toutanova et al., 2003) y Stanford
72
• Conjunción: hemos observado que en el contexto de los enunciados
de coordinación de requisitos,
presentes
las conjunciones suelen estar
entre dos verbos o dos sustantivos. Hemos identificado los
siguientes patrones para la conjunción coordinada (p. ej., y, ni,
pero, o, sin embargo, así que, etc.) de nuestro corpus de
documentos de requisitos como: <cláusula> <verbo_1>
<CONJUNCIÓN> <verbo_2> <cláusula>
Machine Translated by Google
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural
<cláusula> <sustantivo_1> <CONJUNCIÓN>
<sustantivo_2> <cláusula>
• Preposición: una preposición vincula sustantivos, pronombres
y frases con otras palabras o frases. La palabra introducida
por preposición (por ejemplo: copia de libro, “de” aquí
introduce el objeto “libro”) se llama objeto de preposición.
Aunque hay casi 150 preposiciones en inglés, solo se
usa un conjunto limitado de preposiciones (por ejemplo:
por, como, después, en, en , con, pero y arriba) en el
contexto de los documentos de requisitos como
encontramos durante el estudio manual.
El patrón observado es:
capturar la semántica de la declaración.
En correspondencia con estas claves, determinamos las
etiquetas de dependencia del analizador que se pueden usar
para extraer automáticamente los valores de las claves de
marco de las declaraciones de requisitos.
<cláusula> <SUSTANTIVO/PRONOMBRE/FRASE>
<PREPOSICIÓN> <OBJETO DE PREPOSICIÓN>
<cláusula>
Figura 1: Categorización de declaraciones de requisitos.
• Precondición: una precondición se encuentra principalmente en la
acción principal que se realiza en la declaración de requisitos.
La declaración de requisito con condición previa se puede
dividir en dos cláusulas: la cláusula de condición previa y la
cláusula dependiente. Nos dimos cuenta de que dichas
condiciones previas se pueden identificar utilizando los
siguientes patrones: <DESPUÉS/ON/UNA
VEZ/HABIDO> <Cláusula de condición previa> <Cláusula
dependiente>
<SI> <Cláusula de condición previa> <ENTONCES>
<Cláusula dependiente>
<HABING> <verbo en PARTICIPIO PASADO>
<Cláusula de condición previa> <Dependiente
cláusula>
• Marcador: Los marcadores son palabras de enlace o frases
de enlace que unen una pieza de escritura.
Los patrones de marcador muestran que las palabras
clave de marcador pueden conectar dos cláusulas
cualesquiera, dependientes o independientes. Las
palabras clave marcadoras que encontramos en los
documentos de requisitos son:"pero",
“porque”, “y”, “o”. El
patrón correspondiente es:
<cláusula> <PALABRA CLAVE_MARCADOR> <cláusula>
3.1.2 Estructura del marco
La categorización de las declaraciones de requisitos se basa
en el GKP presente, como se muestra en la figura 1. Cada
declaración en los documentos de especificación de requisitos
pertenece a una o más de una categoría de nivel de hoja
dependiendo de los GKP(s) que tenga:
• Categoría única: Voz Activa o Pasiva • Categorías
múltiples: (Activa o Pasiva) con uno o más de (Conjunción,
Preposición,
Precondición y Marcador)
Para cada categoría de nivel de hoja en la figura 1, hemos
definido una estructura de marco, con claves de marco que
Cada declaración de requisitos puede ser una declaración
simple o una declaración compleja. Las declaraciones simples
se harán en voz activa o en voz pasiva.
Las declaraciones complejas se caracterizan por la presencia
de declaraciones simples junto con uno o más de estos
elementos: conjunción, preposición, precondición o marcador.
Hemos diseñado marcos separados para declaraciones
simples y complejas. Los marcos para enunciados complejos
son simplemente la unión de marcos para enunciados simples
y los marcos para elementos presentes en enunciados
complejos. Las siguientes tablas ilustran las claves de marco
y las etiquetas de dependencia correspondientes para
algunos elementos.
Tabla 1: Estructura de la trama – Voz Activa.
CLAVE DE CUADRO
Actor
Modificadores de actor
Acción
Objeto
ETIQUETAS DE DEPENDENCIA
,
SUBJ( ­ actor )
CONDICIÓN (actor, ?)
ROOT
DOBJ (acción, objeto )
Modificador de objetos AMOD/ADVMOD ( obj , modificador)
Tabla 2: Estructura de Trama – Voz Pasiva.
CLAVE DE CUADRO
AGENTE DE ETIQUETAS DE
,
Actor
DEPENDENCIA ( ­ actor )
Modificadores de actor
CONDICIÓN (actor, ?)
Acción
RAÍZ
Objeto
NSUBJPASS
Modificador de objetos
DOBJ (acción, objeto )
Tabla 3: Estructura de trama – Conjunción entre Verbos en Voz
Pasiva.
CLAVE DE CUADRO
Conjunción
Términos en Conjunción
Actor para el verbo 1
Actor para el verbo 2
ETIQUETAS DE DEPENDENCIA
CONJ_ conj, PARATAXIS CONJ_*
NSUBJ /
AGENTE(VERBO1, ?)
NSUBJ / AGENTE(VERBO2, ?)
Objeto para el verbo 1
DOBJ / NSUBJPASS(VERBO1, ?)
Objeto para el verbo 2
DOBJ / NSUBJPASS(VERBO2, ?)
73
Machine Translated by Google
ENASE 2014 ­ 9° Congreso Internacional de Evaluación de Nuevos Enfoques de Software para Ingeniería de Software
Tabla 4: Estructura del marco – Preposición.
CLAVE DE CUADRO
Preposición
Objeto de preposición
modificadores
4.1 Diagrama de actividades
ETIQUETAS DE DEPENDENCIA
PREP_prep
POBJ, PREP_*
AMOD, ADVMOD, NÚM
Sin nodo de decisión: Considere el siguiente escenario de un
estudiante que se registra para el proceso de
colocación: Escenario 1: El usuario inicia 'Solicitar' el proceso
3.2 Generación de diagramas de
comportamiento UML
de colocación. El usuario ingresa el número de entrada del
En esta fase, hacemos uso de la información almacenada en
Consideremos una declaración compleja en el escenario
estudiante. El usuario selecciona la empresa para la que desea
aplicar. El usuario selecciona el horario no para la empresa seleccionada.
marcos para generar la actividad y el diagrama de secuencia
anterior: el usuario selecciona la empresa para la que desea
para el escenario de requisitos dado expresado como
postularse. Salida truncada del Stanford Dependency Parser
declaraciones NL. La representación intermedia de las
para la declaración anterior:
declaraciones de requisitos en forma de marcos nos permite
nsubj(selecciona­2, Usuario­1) root(RAÍZ­0,
manejar declaraciones de requisitos complejas también. El
selecciona­2) dobj(selecciona­2,
módulo de generación de diagramas es independiente del
empresa­4) rel( quiere­8, cuál­6) nsubj(quiere­8,
procesamiento de las declaraciones de requisitos de NL. Este
él­7) xsubj(solicitar­10, él­7)
módulo toma entradas de los elementos del marco y compone
rcmod(empresa­4, quiere­8)
las frases requeridas para diferentes diagramas. La relativa
xcomp(quiere­8, solicitar­10)
independencia del módulo de procesamiento de declaraciones
de requisitos y el módulo de generación de diagramas hace
que nuestro enfoque también sea escalable para procesar
escenarios más grandes.
3.2.1 Generación de diagramas de actividad
Salida del etiquetador de POS de
VBZ, Usuario/NN, el/DT,Stanford:
empresa/NN,
selecciona/
para/IN, cuál/WDT, él/PRP,
quiere/VBZ, para/PARA, aplicar/VB.
Los diagramas de actividad representan el flujo de actividades.
En esta declaración, la salida del etiquetador indica la presencia
Para un escenario de entrada dado, formamos frases de acción
extrayendo acciones y objetos junto con modificadores, si
del patrón de voz activo: <selects/VBZ> y la cláusula
subordinada de preposición: o<company/NN, for/IN, which/
están presentes. Si hay frases preposicionales o condicionales,
WDT>.
entonces agregamos estas frases también a la frase de acción.
Cualquier cláusula subordinada que modifique un actor u objeto
se procesa como una declaración independiente después de
Tabla 5: Estructura del marco: declaración del escenario 1.
VALORES
CLAVE DE CUADRO
ser marcada como cláusula subordinada y adjuntada en
Actor
Usuario
consecuencia.
Acción
Selecciona
Objeto
3.2.2 Generación de diagramas de secuencia
Los diagramas de secuencia representan el flujo de mensajes
o llamadas entre objetos que pueden ser actores o agentes de
Compañía
Preposición
Para
Preposición
Objeto de preposición
Compañía
Cual
modificador
Oración subordinada
cualquier acción. Para un escenario de entrada dado, formamos
Actor
Él
una frase de mensaje extrayendo las acciones y los objetos
Acción
Quiere
Modificador de cláusula relativa
Aplicar
junto con los modificadores, si están presentes. Las frases
preposicionales se utilizan para identificar las interacciones
entre dos actores o agentes/objetos. El elemento 'Actor' del
marco corresponde al actor o agente involucrado en la
interacción secuencial.
En consecuencia, este enunciado se clasifica como
enunciado complejo y el marco correspondiente se muestra en
la tabla 5. Usamos esta información del marco para generar el
diagrama de actividad. El diagrama generado para este
escenario se muestra en la figura 2 a continuación:
4 ESTUDIO DE CASO
Realizamos un estudio de caso en varios escenarios de nuestro
corpus de requisitos. Para ilustrar nuestro enfoque con detalles
elaborados, consideremos declaraciones de requisitos con
diferentes escenarios que se presentan a continuación:
74
Machine Translated by Google
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural
Figura 2: Diagrama de actividad ­ Escenario 1.
Figura 3: Diagrama de actividad ­ Escenario 2.
Nodo de decisión presente:
Escenario 2: Primero solicitamos material mediante un formulario
de solicitud de compra. Si el departamento de compras tiene
proveedores actuales, el departamento de compras identifica a
nuestro proveedor actual para el tipo de material solicitado; de
lo contrario, solicita ofertas de proveedores potenciales y evalúa
sus ofertas para determinar el mejor valor. El departamento de
compras entonces ordena el material solicitado.
Siguiendo un enfoque similar al descrito para el escenario 1, el
diagrama de actividad para el escenario 2 se genera como se
muestra en la figura 3 anterior.
4.2 Diagrama de secuencia
Los diagramas de secuencia también se generan utilizando un
enfoque similar al que hemos utilizado para generar diagramas
de actividad. Para generar diagramas de secuencia, primero
consideramos los actores o agentes que son responsables de
llevar a cabo una acción; estos se identifican por el elemento
'actor' en el marco. El enfoque para identificar frases de acción
es similar al de la generación de diagramas de actividad. A
continuación, presentamos dos posibles escenarios diferentes:
el escenario 3 considera el caso en el que un usuario es
responsable de la secuencia de iniciaciones de acciones; el
escenario 4 representa el caso de secuencia de interacciones
entre actores y agentes en una secuencia:
75
Machine Translated by Google
ENASE 2014 ­ 9° Congreso Internacional de Evaluación de Nuevos Enfoques de Software para Ingeniería de Software
Escenario 3: Considere el siguiente escenario de un estudiante
que se registra para el proceso de colocación: El usuario
necesitaba dinero para las tarifas. El usuario fue al cajero
automático. El usuario ingresó la contraseña en la máquina. El
usuario puso el dinero en su bolsillo.
la intervención manual es opcional y se requiere solo si hay
Escenario 4: considere el siguiente escenario de cajero
automático: la persona camina hacia el cajero automático.
5 DISCUSIÓN Y
Cajero automático pide contraseña al usuario. El usuario ingresa
la contraseña en la máquina.
Los diagramas de secuencia para los escenarios 3 y 4 se
presentan en las figuras 4 y 5, respectivamente, a continuación:
problemas con los escenarios expresados en los documentos
de requisitos.
CONCLUSIÓN
El documento propone un enfoque para generar automáticamente
diagramas de actividad y secuencia a partir de las
especificaciones de requisitos de NL. Nuestro enfoque hace
4.3 Limitaciones
uso de una representación estructurada intermedia de requisitos;
Una de las limitaciones de nuestro trabajo es que asumimos
ninguna restricción en el formato de entrada. Estas son algunas
y no requiere ninguna reescritura si las declaraciones, ni pone
que los escenarios para los que queremos generar diagramas
de comportamiento UML se establecen sin información
redundante. Sin embargo, la redundancia y la ambigüedad a
menudo están presentes en los documentos de requisitos y su
presencia puede ser una posible amenaza para nuestro
enfoque. También es posible que la secuencia de acciones sea
incorrecta en el escenario de requisitos establecidos. Para
mitigar esta limitación, hemos agregado una opción para
cambiar la secuencia de acciones que se muestran después
del procesamiento automatizado de las declaraciones de
requisitos. El usuario puede modificar la secuencia o la
declaración de acción en sí y confirmar su envío para que sus
cambios se almacenen en la estructura de marco
correspondiente. Luego, los diagramas se generan de acuerdo
posibles razones por las que los enfoques existentes para la
generación automatizada de diagramas UML no han tenido
mucho éxito en la industria. Hemos propuesto una solución que
almacena la representación textual de los requisitos en un
formulario intermedio que también puede aceptar cambios
(opcional) del usuario. Sin embargo, la precisión de nuestro
enfoque está limitada por la exactitud de los resultados
proporcionados por Tagger y Parser. No obstante, los resultados
utilizando el etiquetador y el analizador de Stanford son bastante
satisfactorios. Creemos que nuestro enfoque mejorará
sustancialmente el análisis de requisitos de software y, en
consecuencia, conducirá a un mejor desarrollo de software.
Seguimos trabajando en probar escenarios complejos, así
como en la generación automatizada de otros diagramas UML.
con las modificaciones sugeridas por el usuario. Sin embargo,
esto
Figura 4: Diagrama de secuencia ­ Escenario 3.
Figura 5: Diagrama de secuencia ­ Escenario 4.
76
Machine Translated by Google
Generación automatizada de diagramas de actividad y secuencia a partir de requisitos de lenguaje natural
REFERENCIAS
Sommerville, I., 2011, Ingeniería de software, Pearson.
India, 9ª edición.
Svoboda, CP, 1997, Análisis estructurado, en: Thayer RH y
Dorfman M. (eds.), Ingeniería de requisitos de software, 2.ª
edición, IEEE Computer Society Press, Los Alamitos, CA,
págs. 255­274.
Booch, G., 1994, Análisis y diseño orientados a objetos con
aplicaciones, Benjamin­Cummings Publishing Co., Inc.
Redwood City, CA, EE. UU., 2ª edición.
Delugach, HS, 1996, Un enfoque de la retroalimentación
conceptual en el modelado de requisitos de software de
múltiples vistas, en Viewpoints 1996: Taller internacional
sobre múltiples perspectivas en el desarrollo de software,
San Francisco, CA, pp. 242­246.
Subramaniam, K., Liu, D., Far BH y Eberlein, A., 2004, UCDA:
Use Case Driven Development Assistant Tool for Class
Model Generation, en SEKE '04: 16.ª Conferencia
internacional sobre ingeniería de software e ingeniería del
conocimiento, Canadá, págs. 324­329.
, Lavoie B. y Rambow, O., 2001, Modelado
Overmeyer, S.
conceptual a través del análisis lingüístico utilizando LIDA,
en ICSE'01: 23ª Conferencia internacional sobre ingeniería
de software, Canadá, págs. 401­410.
Vinay, S. , Aithal S. y Desai, P., 2009, Un enfoque hacia la
automatización del análisis de requisitos, en IMECS'09:
Multiconferencia internacional de ingenieros e informáticos,
Hong Kong.
Herchi, H. y Abdessalem, WB, 2012, De los requisitos del usuario
al diagrama de clase UML, CoRR abs/1211.0713.
More, P. y Phalnikar, R., 2012, Generación de diagramas UML
a partir de especificaciones de lenguaje natural, International
Journal of Applied Information Systems, vol. 1, no. 8, págs.
19­23.
Joshi, SD y Deshpande, D., 2012, Análisis de requisitos textuales
para la extracción de diagramas UML mediante NLP,
International Journal of Computer Applications, vol. 50, núm.
8, págs. 42­46.
Ibrahim, M. y Ahmad, R., 2010, Extracción de diagramas de
clases a partir de requisitos textuales utilizando técnicas de
procesamiento de lenguaje natural (NLP), en la 2ª
Conferencia internacional sobre investigación y desarrollo
informático, págs. 200­204.
Ormandjieva, O. e Ilieva, MG, 2006, Comprensión automática
de los requisitos textuales del usuario y su modelado estático
y dinámico, en SERP'06: Conferencia internacional sobre
investigación y práctica de ingeniería de software, Nevada,
EE. UU., págs. 266­273.
Deeptimahanti DK y Sanyal, R., 2008, Generador de modelos
UML estáticos a partir del análisis de requisitos (SUGAR),
en ASEA'08: Conferencia internacional sobre ingeniería de
software avanzada y sus aplicaciones, China, págs. 77­84.
Conferencia de ingeniería, Kerala, India, págs. 165­174.
Li, L., 1999, Un enfoque semiautomático para traducir casos de
uso a diagramas de secuencia, en Proceedings of Technology
of Object­Oriented Languages and Systems, pp.184­193.
Yue, T., Briand, LC y Labiche, Y., 2010, An Automated Approach
to transform Use Cases into Activity Diagrams, en ECMFA'10:
Actas de la 6.ª Conferencia Europea sobre Fundamentos y
Aplicaciones de Modelado, París, Francia, págs. 337 ­353.
Erickson J. y Siau, K., 2007, Complejidad teórica y práctica de
los métodos de modelado, ACM Communications, vol. 50,
núm. 8, págs. 46­51.
M. Minsky, 1988, A Framework for Representing Knowledge, en:
Haugeland J. (ed.), Mind Design: Philosophy, Pscychology,
Artificial Intelligence, MIT Press, Cambridge, MA, pp. 95­128.
Bowker, L., 2003, Patrones de conocimiento léxico, relaciones
semánticas y variedades lingüísticas: exploración de las
posibilidades para refinar la recuperación de información en
un contexto internacional, en: Williamson NJ y Beghtol, C.,
(eds.), Organización y clasificación del conocimiento en
International Information Retrieval coeditado como Cataloging
and Classification Quarterly, 37(1), The Haworth Information
Press, Binghamton, NY, pp. 153­171.
Especificación del lenguaje de modelado unificado, versión 1.5,
2003, documento OMG, disponible en: http://www.omg.org/
spec/UML/1.5/ [4 de enero de 2014].
Marshman, E., Morgan T. y Meyer, I., 2002, Patrones franceses
para expresar relaciones de conceptos, Terminología, vol.
8, núm. 1, págs. 1­29.
Hunston S. y Francis, G., 2000, Pattern Grammar: A Corpus­
Driven Approach to the Lexical Grammar of English, John
Benjamins, Ámsterdam.
Fikes, RE y Kehler, T., 1985, El papel de la representación
basada en marcos en la representación y el razonamiento
del conocimiento, Comunicaciones de la ACM, vol. 28, núm.
9, págs. 904­920.
Luisa, M., Mariangela F. and Pierluigi, NI, 2004, Investigación de
mercado sobre el análisis de requisitos utilizando
herramientas lingüísticas, Ingeniería de requisitos, vol.9,
no.1, pp. 40­ 56.
Bhatia, J., Sharma, R., Biswas, KK y Ghaisas, S., 2013, Uso de
patrones de conocimiento gramatical para estructurar
especificaciones de requisitos, en RePa'13: 3er taller
internacional de IEEE sobre patrones de requisitos, Río de
Janeiro, Brasil, págs. .31­34.
Toutanova, K., Klein, D., Manning, C. y Singer, Y., 2003,
Etiquetado de parte del discurso rico en funciones con una
red de dependencia cíclica. En Actas de HLT NAACL 2003,
págs. 252­259.
,
Marneffe, MC de, MacCartney, B. y Manning, CD
2006, Generación de análisis de dependencia tipificados a partir
de análisis de estructura de frase, en LREC 2006.
Deeptimahanti DK y Sanyal, R., 2011, Generación semiautomática
de modelos UML a partir de requisitos de lenguaje natural,
en ISEC'11: 4th India Software
77
Ver estadísticas de publicación