Tesis de Grado
Universidad Nacional del Centro de la
Provincia de Buenos Aires
Un Asistente Inteligente para derivar Escenarios de
Atributos de Calidad en Arquitecturas de Software
Kevin Ruau
Director: Dr. Alejandro Rago
Co-Directora: Dra. Claudia Marcos
´
Indice
1. Introducci´on 7
1.1. Problem´atica de los Escenarios de Calidad . . . 8
1.2. ScenariosTool . . . 10
1.3. Esquema General . . . 13
2. Conceptos Te´oricos Relacionados 15 2.1. Arquitecturas de Software . . . 15
2.1.1. Estructura de M´odulos . . . 16
2.1.2. Estructura de Componentes y Conectores . . . 16
2.1.3. Estructura de Alocaci´on . . . 17
2.1.4. Ejemplo de Arquitectura de Software . . . 17
2.2. Atributos de Calidad . . . 19
2.2.1. Performance . . . 21
2.2.2. Disponibilidad . . . 21
2.2.3. Modificabilidad . . . 21
2.2.4. Seguridad . . . 22
2.2.5. Usabilidad . . . 22
2.2.6. Testeabilidad . . . 22
2.3. Escenarios de Atributos de Calidad . . . 23
2.4. M´etodos de Desarrollo y Evaluaci´on de Arquitecturas de Soft-ware . . . 25
2.4.1. Attribute Driven Design . . . 25
2.4.2. Architecture Trade-off Analysis Method . . . 26
2.4.3. Quality Attribute Workshop . . . 27
2.5. Inteligencia Artificial . . . 28
2.5.1. Machine Learning . . . 29
2.5.2. Natural Language Processsing . . . 30
2.5.3. Redes Neuronales . . . 30
3. Trabajos Relacionados 34
3.1. Aprendizaje Supervisado . . . 34
3.1.1. El Dise˜no de Arquitecturas de Software . . . 34
3.1.2. Identificaci´on y Clasificaci´on de Requerimientos No Fun-cionales . . . 36
3.2. Aprendizaje No Supervisado . . . 38
3.2.1. Duplicaci´on de Funcionalidad: ReqAligner . . . 39
3.2.2. Definici´on de Requerimientos No Funcionales . . . 40
3.3. Conclusiones . . . 42
4. Derivaci´on de Escenarios de Atributos de Calidad con Sce-nariosTool 43 4.1. ScenariosTool . . . 44
4.2. Aprendizaje: Preprocesamiento y Generaci´on del Modelo . . . 47
4.2.1. Preprocesamiento . . . 48
4.2.2. Generador del Modelo con las Caracter´ısticas de las Palabras . . . 51
4.3. Razonamiento Arquitect´onico . . . 55
4.3.1. Recomendaci´on de Partes de Escenarios de QA . . . . 56
4.4. Resumen . . . 61
5. An´alisis de Resultados 62 5.1. Procedimiento Experimental . . . 62
5.2. Configuraci´on de la Herramienta . . . 64
5.3. M´etricas . . . 65
5.4. Escenarios de Atributos de Calidad Individuales . . . 67
5.5. Escenarios del Mismo Atributo de Calidad en Conjunto . . . . 69
5.6. Escenarios de Atributos de Calidad en Conjunto . . . 72
5.7. Discusi´on de Resultados . . . 75
6.2. Limitaciones . . . 78 6.3. Trabajos Futuros . . . 79
7. Bibliograf´ıa 81
´
Indice de Figuras
1.1. Enfoque simplificado . . . 12
2.1. Estructura de M´odulos . . . 16
2.2. Estructura de Componentes y Conectores . . . 17
2.3. Estructura de Alocaci´on . . . 18
2.4. Soluci´on de KeyWord in Context con arquitectura Pipes and Filters . . . 19
2.5. Partes de un escenario de atributo de calidad . . . 23
2.6. Variantes gen´ericas de un escenario de disponibilidad . . . 24
2.7. Escenario de disponibilidad . . . 25
2.8. Pasos de ADD . . . 27
2.9. Ejemplo de ´arbol de utilidad . . . 28
2.10. Pasos de QAW . . . 29
2.11. Modelo de Continuous Bag of Words . . . 32
2.12. Modelo de Skip-Gram . . . 33
3.1. Enfoque basado en CBR . . . 35
3.2. Acercamiento semi-supervisado para la clasificaci´on de reque-rimientos no funcionales . . . 37
3.3. Acercamiento supervisado para la clasificaci´on de requerimien-tos no funcionales . . . 38
3.4. Esquema de la herramienta ReqAligner para la especificaci´on de casos de uso . . . 40
3.5. Esquema de funcionamiento . . . 41
4.1. Esquema de funcionamiento . . . 46
4.2. Interfaz gr´afica de la herramienta . . . 47
4.3. Componente de Preprocesamiento . . . 49
4.4. Red neuronal de word2vec . . . 53
4.5. Ejemplo sobre recomendaci´on por analog´ıa . . . 58
4.6. Ejemplo del segundo resultado de la Figura 4.7 . . . 59
´
Indice de Tablas
1. Comparaci´on entre procedimientos experimentales . . . 64
2. Escenarios preexistentes de Disponibilidad . . . 84
3. Escenarios preexistentes de Modificabilidad . . . 85
4. Escenarios preexistentes de Performance . . . 85
5. Escenarios preexistentes de Seguridad . . . 86
6. Escenarios preexistentes de Testeabilidad . . . 87
7. Escenarios preexistentes de Usabilidad . . . 87
1.
Introducci´
on
Durante el dise˜no de un sistema de software, los arquitectos son respon-sables de tomar decisiones claves del desarrollo y plasmarlas en documentos arquitect´onicos, con el objetivo de que las mismas sean tenidas en cuenta cuando se materialice el sistema. Un aspecto relevante de estas decisiones es que responden a determinados atributos de calidad del sistema, esenciales para que el producto desarrollado satisfaga las necesidades del cliente. Los atributos de calidad, como pueden ser Performance, Disponibilidad, Modifi-cabilidad, Seguridad, Usabilidad, etc., son requerimientos no funcionales que referencian caracter´ısticas de calidad o restricciones de un sistema [5]. En el caso de los atributos de calidad, los mismos son analizados y especifica-dos por un arquitecto con el fin de elegir una arquitectura de software que los satisfaga correctamente. La correcta identificaci´on y consideraci´on de los atributos de calidad en el dise˜no de un sistema se relacionan directamente con el ´exito o fracaso del mismo. Si los atributos de calidad de un sistema no son considerados durante su dise˜no, es posible que el producto desarrollado no logre satisfacer adecuadamente las necesidades de los stakeholders. Por ejemplo, si las restricciones deSeguridad de un sistema bancario no se consi-deran en profundidad, el mismo podr´ıa sufrir ataques y generar p´erdidas de dinero.
1.1.
Problem´
atica de los Escenarios de Calidad
Si bien los escenarios de calidad proveen un mecanismo para la especi-ficaci´on de requerimientos no funcionales, los mismos no son utilizados de manera frecuente [7]. Esto se debe principalmente a la dificultad que se pre-senta para especificarlos, ya que para ello se necesita que el arquitecto posea amplia experiencia y conocimiento en cada atributo de calidad particular. Por lo general, este tipo de informaci´on de los atributos de calidad suele documentarse de forma parcial y entremezclada con las especificaciones fun-cionales del sistema [7]. Si esto ocurre, puede haber consecuencias negativas durante la construcci´on del sistema y su posterior mantenimiento. Por ejem-plo, sup´ongase que un equipo de assessment arquitect´onico quisiera evaluar el dise˜no de un sistema para encontrar cuellos de botella en la Performance. Sin embargo, si los arquitectos han definido los atributos de calidad de Per-formance de forma vaga y ambigua, es posible que los tiempos de respuesta esperados no est´en expl´ıcitamente definidos en la documentaci´on, dificul-tando el an´alisis de la arquitectura en tiempo de ejecuci´on. Por otro lado, sup´ongase que se requiere agregar nueva funcionalidad al sistema. En este caso, puede que cierta informaci´on con respecto a cu´an r´apida o segura debe ser la misma no sea tenida en cuenta. Si esto sucede, la nueva funcionali-dad puede no resultar ´util para el usuario ya que se realiza de forma muy lenta, o es vulnerable a ataques indeseados. Adem´as, en el caso de conocer las caracter´ısticas de Performance y Seguridad deseadas por el cliente, es posible encontrar tradeoffs arquitect´onicos que no se aprecian f´acilmente y que pueden ser analizados tempranamente mediante el uso de escenarios de atributos de calidad [18].
guia-dos por atributos de calidad en arquitecturas SOA, utilizando una t´ecnica que recupera soluciones que hayan sido ´utiles para problemas similares al que se intenta resolver. Estas soluciones abarcan distintos documentos de di-se˜no de arquitecturas de software que deben ser clasificados detalladamente por expertos para cumplir criterios de b´usqueda. En [11] y [14] se intenta resolver la problem´atica de identificaci´on y clasificaci´on de requerimientos no funcionales con dos propuestas diferentes. Por un lado, en [11] es nece-saria la intervenci´on de expertos que realicen un preprocesamiento manual de un subconjunto de los datos para que los mismos sirvan posteriormente para clasificar datos nuevos. A partir de estas clasificaciones se confecciona un clasificador de requerimientos no funcionales. Adem´as, en [11] es nece-sario obtener un feedback sobre resultados brindados por la propuesta para mejorar su rendimiento. Por otro lado, en [14] es necesaria la intervenci´on de expertos para clasificar la totalidad de los datos, lo que requiere un gran tiempo de preprocesamiento para la utilizaci´on del enfoque. En [28] se pro-pone una alternativa para poder resolver otro problema de la etapa de dise˜no de un sistema, relativo a la duplicaci´on de funcionalidad en la especificaci´on de los requerimientos. Par lograr esto, se una analog´ıa entre requerimientos de un sistema y cadenas de ADN para identificar patrones repetidos. En esta propuesta no es necesaria la intervenci´on rigurosa de expertos, por lo que presenta una ventaja con respecto a las propuestas mencionadas anterior-mente. Sin embargo, la misma no se centra en la especificaci´on de atributos de calidad. Por ´ultimo, en [15] se aborda la especificaci´on de atributos de calidad, donde es necesaria la intervenci´on de un experto que defina detalla-damente caracter´ısticas de diferentes atributos de calidad para poder especi-ficarlos. Esta propuesta requiere contar con expertos con mucha experiencia y conocimiento sobre diversos atributos de calidad, y no es flexible ante la incorporaci´on de nuevos atributos de calidad.
suelen aplicar enfoques supervisados que requieren informaci´on etiquetada manualmente, la cual raramente est´a disponible de antemano. Adem´as, la informaci´on utilizada por los algoritmos tradicionales necesita ser preproce-sada cuidadosamente para que los mismos produzcan resultados aceptables. Sin embargo, mediante los avances recientes en materia de Inteligencia Ar-tificial y Machine Learning, es posible superar estas limitaciones y construir herramientas capaces de asistir el trabajo de un arquitecto de software du-rante la etapa de especificaci´on de los escenarios de calidad. Particularmente, es viable efectuar el procesamiento de una gran cantidad de informaci´on sin que la misma sea adaptada y clasificada por expertos para que los algoritmos tengan un desempe˜no aceptable. Una de las nuevas tecnolog´ıas que permite realizar esto es word2vec [2]. Dicha tecnolog´ıa permite procesar una gran cantidad de texto de tal forma de obtener una representaci´on vectorial de las palabras que lo componen. De esta forma, se puede reducir el tiempo de dise˜no de un sistema mediante la asistencia a arquitectos que no tengan experiencia suficiente o arquitectos experimentados que quieran verificar las decisiones que tomaron previamente.
1.2.
ScenariosTool
caso, no se especifica en cu´anto tiempo se debe recuperar de la falla interna producida. Un aspecto interesante del enfoque es que se utilizan escenarios de referencia para direccionar la b´usqueda de las partes incompletas de los escenarios. Dichos escenarios de referencia se encuentran con todas sus partes especificadas detalladamente y son brindados por un experto una ´unica vez. El enfoque presentado se divide en dos etapas (Figura 1.1). La prime-ra etapa de Aprendizaje tiene como objetivo aprender relaciones entre las diversas partes de los escenarios de atributos de calidad. El experto es el en-cargado de seleccionar diversos textos relativos a la Ingenier´ıa de Software, que conforman la entrada de esta primera etapa del enfoque. Como salida, se produce unasset denominadomodelo, el cual contiene las relaciones entre las partes de los escenarios de calidad. Por ejemplo, la palabra internal es la fuente de un escenario y est´a relacionada con la palabra recover que re-presenta la respuesta de un escenario. La segunda etapa de Razonamiento
tiene como objetivo identificar las partes ausentes en un escenario median-te el an´alisis de las palabras almacenadas en el modelo y la exploraci´on de analog´ıas con escenarios de referencias (que contienen las partes faltantes). Como entrada de esta etapa, un arquitecto ingresa un escenario parcial so-bre el cual quiere obtener sugerencias de partes faltantes. Como salida, se producen sugerencias sobre partes faltantes del escenario parcial ingresado. Por ejemplo, sup´ongase que un arquitecto cuenta con un escenario de Dispo-nibilidad que tiene como fuente el concepto internal y del cual no conoce la respuesta. En este caso, a partir de un escenario de referencia y la utilizaci´on del modelo se podr´ıa inferir la respuesta que el arquitecto necesita. Para rea-lizar esto, se establece una relaci´on entre la fuente del escenario parcial del arquitecto (internal) y la fuente del escenario de referencia. Dicha relaci´on debe ser an´aloga para la parte respuesta de los escenarios. Esta relaci´on entre las partes respuesta de los escenarios es trasladada al modelo para obtener la parte respuesta faltante. Finalmente, las sugerencias obtenidas son brindadas al arquitecto.
Sce-Figura 1.1: Enfoque simplificado
nariosTool. Dicha herramienta fue implementada en Java, y cuenta con una interfaz gr´afica que facilita su utilizaci´on. A partir de la interfaz gr´afica, el experto puede generar un modelo mediante la selecci´on de una fuente de conocimiento y cargar escenarios de referencia. Por otro lado, un arquitecto que utiliza la herramienta puede ingresar un escenario parcial para obtener sugerencias sobre partes faltantes del mismo. Dichas sugerencias se presen-tan en forma de lista, junto a la posibilidad de examinar los escenarios de referencia que se encuentran cargados.
utilizaci´on de los escenarios de referencia completos del mismo atributo de ca-lidad utilizados en conjunto, los resultados fueron muy buenos, permitiendo que la herramienta arroje sugerencias correctas con unaconfianza de 49.3 %. Por ´ultimo, con respecto a los escenarios de referencia completos de cualquier atributo de calidad utilizados en conjunto, los resultados obtenidos no fueron satisfactorios, obteniendo una confianza de 23.8 %.
El trabajo realizado presenta diferentes contribuciones al campo de la Ingenier´ıa de Software e Inteligencia Artificial. Primero, se desarroll´o una herramienta que permite asistir a un arquitecto durante la especificaci´on de escenarios de atributos de calidad de un sistema. Segundo, se us´o la tecnolog´ıa
word2vec en un dominio nuevo, obteniendo buenos resultados para identi-ficar relaciones entre las partes de escenarios de calidad. Otra contribuci´on es la extensi´on de la analog´ıa realizada entre las representaciones vectoriales de las palabras a m´ultiples vectores, aprovechando la estructura de 6 partes de los escenarios. A partir de dicha extensi´on es posible alcanzar resultados m´as precisos y ´utiles para el arquitecto de software que utiliza la asistencia de la herramienta.
1.3.
Esquema General
El esquema general de este trabajo se organiza de la siguiente manera. En elCap´ıtulo 2se presentan conceptos te´oricos relativos a arquitecturas de software y atributos de calidad. Adem´as, se realiza una descripci´on de diferentes t´ecnicas de Inteligencia Artificial utilizadas en este trabajo.
En elCap´ıtulo 3se describen diversos enfoques propuestos para resolver el problema de la especificaci´on de escenarios de atributos de calidad. Estos enfoques se dividen en dos grupos seg´un utilicen t´ecnicas de aprendizaje supervisado o no supervisado.
En el Cap´ıtulo 5 se presentan los resultados de la evaluaci´on realizada a ScenariosTool. Primero, se describen las preguntas de investigaci´on junto a los procedimientos experimentales realizados. Luego, se analizan y comparan los resultados obtenidos.
2.
Conceptos Te´
oricos Relacionados
En este cap´ıtulo se presentan los conceptos principales que se utilizan a lo largo del desarrollo de este informe. Inicialmente, se har´a ´enfasis en los conceptos de Arquitectura de Software, Atributos de Calidad, Esce-narios de Calidad. Luego, se introducir´an M´etodos de Desarrollo y Evaluaci´on de Arquitecturas de Software. Finalmente, se explicar´an distin-tos concepdistin-tos relativos a laInteligencia Artificial, debido a que los mismos suelen aplicarse para automatizar el proceso de definici´on de una Arquitec-tura de Software.
2.1.
Arquitecturas de Software
En el desarrollo de sistemas de software, una Arquitectura es el conjunto de estructuras de software necesarias para razonar sobre un sistema, com-prendiendo elementos de software, sus relaciones y propiedades de los mismos [1][7]. Durante la construcci´on de la arquitectura, se deben tomar decisiones de dise˜no y plasmarlas en documentos arquitect´onicos, como puede ser el Software Architecture Document, que contendr´a informaci´on relevante sobre el funcionamiento y la arquitectura del sistema. Dichos documentos son cons-truidos con el objetivo de que las decisiones de dise˜no sean tenidas en cuenta cuando se materialice el sistema.
2.1.1. Estructura de M´odulos
Un sistema puede ser particionado en unidades de implementaci´on, deno-minadas m´odulos. Para dividir las tareas durante el desarrollo, las responsa-bilidades funcionales son asignadas a m´odulos espec´ıficos. Esto permite, por ejemplo, la posibilidad de que un m´odulo sea desarrollado por un equipo de trabajo y otro m´odulo diferente sea desarrollado por otro equipo distinto. Las estructuras de m´odulos son est´aticas, debido a que se focalizan en c´omo se divide la funcionalidad del sistema [1]. En la Figura 2.1 se puede ver una estructura de m´odulos de una arquitectura Cliente-Servidor. En este caso, el tanto el Cliente como el Servidor son m´odulos del sistema.
Figura 2.1: Estructura de M´odulos
2.1.2. Estructura de Componentes y Conectores
se comunica con dos Clientes, permitiendo el intercambio de informaci´on. Cuando un Cliente necesita comunicarse con el Servidor, hace una petici´on al mismo, el cual generar´a una respuesta que es enviada al Cliente que la solicit´o. El Servidor provee servicios a trav´es de sus interfaces, y los Clientes utilizan las mismas para enviar peticiones al servidor.
Figura 2.2: Estructura de Componentes y Conectores
2.1.3. Estructura de Alocaci´on
La estructura de alocaci´on describe la relaci´on entre las estructuras del sistema y los ambientes de organizaci´on, desarrollo, instalaci´on y ejecuci´on en los que se encuentra. Por ejemplo, los componentes del sistema son uti-lizados en un cierto hardware para poder funcionar, y esta situaci´on puede ser descrita mediante una estructura de alocaci´on [1]. La Figura 2.3 muestra dos componentes, el Cliente y el Servidor, que son alojados en dos compu-tadoras f´ısicas, Computadora del Cliente y Computadora del Servidor, que se comunican a trav´es de Internet.
2.1.4. Ejemplo de Arquitectura de Software
Para poder comprender mejor las diferentes estructuras, se describir´a una posible soluci´on al problema que analiz´o Parnas en [16]. El problema con-sist´ıa del siguiente enunciado:
ve-Figura 2.3: Estructura de Alocaci´on
ces, quitando la primera palabra y a˜nadi´endola al final de la l´ınea. El sistema de KWIC tiene como salida un listado, ordenado alfab´eticamente, de todos los posi-bles desplazamientos circulares de todas las l´ıneas.”
Una posible soluci´on al problema se presenta en el diagrama de com-ponentes y conectores de la Figura 2.4, donde se observa que mediante la utilizaci´on de distintos filtros y comunicaci´on entre ellos es posible ir modifi-cando los datos de entrada hasta llegar a la soluci´on final. La arquitectura de software utilizada para resolver el problema es com´unmente conocida como
Puntualmente, los filtros realizan las siguientes transformaciones. Una serie de “Datos de entrada” ser´an entregados al filtro “Entrada”, que ser´a el encargado de iniciar el proceso de transformaci´on de los datos. El filtro “Desplazamiento Circular” permite, como su nombre lo indica, mover las oraciones entregadas por el filtro “Entrada” en forma circular, de tal forma que puedan ser ordenadas alfab´eticamente por el filtro “Ordenador”. Por ´
ultimo, el filtro “Salida” prepara las sentencias ordenadas para que puedan ser almacenadas en un medio f´ısico como “Datos de salida”. Los componentes encargados de realizar el pasaje de los datos entre los filtros son las tuber´ıas.
Figura 2.4: Soluci´on de KeyWord in Context con arquitectura Pipes and Filters
2.2.
Atributos de Calidad
Los Atributos de Calidad (QA, Quality Attributes) hacen referencia a ciertos requerimientos no funcionales que el sistema debe satisfacer, adem´as de cumplir con los requerimientos funcionales [5]. Estos atributos de calidad pueden ser performance, disponibilidad, usabilidad, seguridad, entre otros.
importancia durante la etapa de dise˜no, debido a que ´esta impactar´a directa o indirectamente sobre los atributos de calidad del sistema. Si las partes interesadas establecen distintas condiciones sobre atributos de calidad del sistema que se quiere construir, la arquitectura deber´a ser elegida en funci´on de la satisfacibilidad de dichas condiciones [7].
Los atributos de calidad pueden clasificarse en dos grupos [1]:
Observables en tiempo de ejecuci´on. Se puede apreciar su comporta-miento mientras que el sistema est´a corriendo, por ejemplo, performan-ce, disponibilidad, seguridad, entre otros.
No observablesen tiempo de ejecuci´on. Se puede apreciar su compor-tamiento mientras se desarrolla y evoluciona el sistema, por ejemplo, modificabilidad, escalabilidad, entre otros.
Los atributos de calidad son independientes de la funcionalidad que un sistema tiene que realizar. Sin embargo, los mismos tienen un impacto en la forma en que se satisface dicha funcionalidad [1]. Por ejemplo, en un sis-tema bancario se deben poder realizar transferencias de una cuenta de un cliente del banco a otra cuenta. Si las partes interesadas en la utilizaci´on o comercializaci´on del sistema indican que las transferencias bancarias deben ser procesadas por el sistema en un determinado lapso de tiempo, la funcio-nalidad no sufre variaciones, pero s´ı la forma en la que debe ser implementada para poder satisfacer las restricciones impuestas. En este caso, el atributo de calidadperformance debe ser considerado en el dise˜no de la arquitectura del sistema, de tal forma que la operaci´on de realizar una transferencia sea hecha en un determinado lapso de tiempo m´aximo.
2.2.1. Performance
Este atributo de calidad se refiere a la capacidad de realizar tareas cum-pliendo determinadas restricciones, como pueden ser velocidad, tiempo, entre otros. [9]. Sin embargo, esta definici´on es bastante general para ser utilizada en el ´ambito de la Ingenier´ıa de Software. Por esta raz´on, en dicho ´ambito se suele utilizar la definici´on de [18], donde se dice que la performance se refiere a larespuesta del sistema, ya sea en tiempo requerido para responder ante un determinado evento, o al n´umero de eventos procesados en un determinado intervalo de tiempo.
2.2.2. Disponibilidad
Este atributo de calidad se refiere a la capacidad de un sistema de estar listo para ser utilizado [17]. Por lo general, est´a relacionado con las fallas que pueden ocurrir en un sistema (en tiempo de ejecuci´on) y sus consecuencias. Una falla ocurre cuando los servicios provistos por un sistema no operan de acuerdo a su especificaci´on. Dicha falla suele ser visible para los usuarios del sistema, o incluso para otros sistemas. Una vez que ocurre una falla, es importante intentar reparar el sistema para que pueda volver a estar dispo-nible para su uso. Por ejemplo, se puede necesitar que un sistema bancario est´e funcionando las 24 horas del d´ıa, y en el caso que ocurra alguna falla y el sistema deje de funcionar, el restablecimiento del mismo ocurra en un determinado lapso m´aximo de tiempo.
2.2.3. Modificabilidad
bancario se quiere agregar la posibilidad de ofrecer descuentos a los clientes si se opera con tarjetas de d´ebito, se deber´a analizar qu´e partes del sistema son afectadas por la modificaci´on, qui´en har´a el cambio, cu´anto esfuerzo costar´a dicho cambio, entre otros.
2.2.4. Seguridad
Este atributo de calidad se refiere a la protecci´on de los datos del sistema contra su modificaci´on, revelaci´on o destrucci´on, adem´as de la protecci´on del sistema en s´ı mismo [17], para que no se altere su funcionalidad. En otras palabras, se relaciona con la habilidad del sistema de resistir intentos no au-torizados de uso o modificaci´on de comportamiento, proveyendo al mismo tiempo servicio a usuarios leg´ıtimos. Por lo general, este atributo de cali-dad suele especializarse utilizando conceptos de confidencialicali-dad, integricali-dad, auditor´ıa, entre otros.
2.2.5. Usabilidad
Este atributo de calidad se refiere a la facilidad con la que un usuario pue-de aprenpue-der a utilizar e interpretar los resultados producidos por un sistema [17]. Para este atributo de calidad, se suelen considerar diversos aspectos de la interacci´on humano-computadora, tales como: aprendizaje del sistema, utilizaci´on eficiente del sistema, minimizaci´on del impacto de errores, adapta-ci´on del sistema a las necesidades del usuario, confianza y satisfacci´on, entre otros.
2.2.6. Testeabilidad
2.3.
Escenarios de Atributos de Calidad
Para poder entender y comunicar los atributos de calidad, es necesario contar con un mecanismo que permita realizar una descripci´on detallada de los mismos. Para realizar dicha especificaci´on, se utilizan los escenarios de atributos de calidad, los cuales permiten describir de manera formal los requerimientos no funcionales que deber´a satisfacer el sistema [6]. Cada esce-nario est´a relacionado con un atributo de calidad en particular, por ejemplo, existen escenarios de calidad para performance, disponibilidad, usabilidad, entre otros. Los escenarios constan de seis partes bien definidas (Figura 2.5):
Est´ımulo: evento que afecta al sistema.
Fuente: la entidad que genera est´ımulo.
Ambiente: la condici´on bajo la cual ocurre el est´ımulo.
Artefacto: el artefacto del sistema que se ve estimulado.
Respuesta: la actividad que resulta del est´ımulo.
Medida de la Respuesta: la medida de la respuesta por la cual el sistema ser´a evaluado.
Los escenarios son importantes ya que permiten especificar los atributos de calidad a cada sistema en particular. Por ejemplo, si se quiere crear un escenario de calidad de disponibilidad concreto, cada una de las seis partes del escenario podr´ıa contener una de las posibles opciones mostradas en la Figura 2.6. Una vez decididas las partes correspondientes, es posible generar un escenario de calidad concreto para un requerimiento no funcional “Under normal operation, an internal fault causes the running process to crash. The system should recover from the failure in less than 1 minute”, como se ob-serva en la Figura 2.7.
Figura 2.6: Variantes gen´ericas de un escenario de disponibilidad
funcionales que deben ser analizados nuevamente para verificar la satisfaci-bilidad de los mismos.
Figura 2.7: Escenario de disponibilidad
2.4.
M´
etodos de Desarrollo y Evaluaci´
on de
Arquitec-turas de Software
Existen varios m´etodos en la Ingenier´ıa de Software que utilizan el con-cepto de atributo de calidad y hacen uso de los escenarios para construir software con mejores cualidades. A continuaci´on, se presentar´an los m´etodos m´as utilizados. En primer lugar, se ver´a el m´etodo ADD, que utiliza esce-narios para dise˜nar una arquitectura. Luego, se ver´a el m´etodo ATAM que realiza una evaluaci´on de la arquitectura, teniendo en cuenta los atributos de calidad que deber´ıa satisfacer. Por ´ultimo, se ver´a el m´etodo QAW, que es utilizado en complemento con ATAM para determinar los atributos de calidad en etapas tempranas del dise˜no del sistema.
2.4.1. Attribute Driven Design
atributos de calidad [6]. Este m´etodo sigue un proceso de descomposici´on re-cursiva donde, en cada etapa de la descomposici´on, t´acticas y patrones arqui-tect´onicos son elegidos para satisfacer un conjunto de escenarios de atributos de calidad [6]. En la Figura 2.8 se pueden observar los diferentes datos de en-trada (Requerimientos funcionales, Restricciones de dise˜no y Requerimientos de atributos de calidad) que utiliza el m´etodo para poder generar la salida (documento que contiene el Dise˜no de la arquitectura de software). El m´ eto-do consta de 8 pasos, eto-donde primeramente se confirma que haya la cantidad suficiente de informaci´on sobre requerimientos para poder empezar a aplicar el m´etodo. Seguido a esto, se iteran seis pasos hasta que sea necesario finalizar el proceso. Los seis pasos que se iteran son: 2) Elegir un elemento del siste-ma a descomponer, 3) Identificar los conductores arquitect´onicos candidatos, 4) Elegir un concepto de dise˜no que satisfaga los conductores arquitect´ oni-cos, 5) Instanciar los elementos arquitect´onicos y asignar responsabilidades, 6) Definir interfaces para los elementos instanciados y 7) Verificar y refinar requerimientos y hacerlos restricciones para los elementos instanciados.
2.4.2. Architecture Trade-off Analysis Method
Figura 2.8: Pasos de ADD
2.4.3. Quality Attribute Workshop
Figura 2.9: Ejemplo de ´arbol de utilidad
existencia de una arquitectura de software. En la Figura 2.10 se puede obser-var los diferentes pasos que realiza el m´etodo QAW para lograr su objetivo. En primer lugar, se hace una presentaci´on del funcionamiento del m´etodo QAW y una breve introducci´on, luego se presentan los objetivos de negocio y el plan arquitect´onico. Lo siguiente es la identificaci´on de los conductores arquitect´onicos, seguido del brainstorming, consolidaci´on, priorizaci´on y re-finamiento de escenarios. Estos 8 pasos se repiten la cantidad de veces que se considere necesaria con diversas partes interesadas en el sistema.
2.5.
Inteligencia Artificial
El proceso de identificaci´on, definici´on y especificaci´on de QA y escena-rios de atributos de calidad es una tarea ardua y compleja. Por esta raz´on, se utilizan t´ecnicas de Inteligencia Artificial para asistir en las etapas del dise˜no de un sistema de software. Para resolver la problem´atica planteada, la Inteli-gencia Artificial provee diversas t´ecnicas que aportan algoritmos capaces de automatizar el proceso de dise˜no de un sistema.
Figura 2.10: Pasos de QAW
inteligentes [4], donde un agente inteligente es un sistema que percibe su entorno y es capaz de actuar sobre ´el, de tal modo que pueda cumplir con ciertos objetivos [20]. Existen diversas ramas de investigaci´on dentro del cam-po de la Inteligencia Artificial. Estas ramas cam-poseen diferentes caracter´ısticas y utilizan conceptos comunes que podr´ıan ser utilizados en la definici´on y es-pecificaci´on de la arquitectura de un sistema de software, por ejemplo, “Ma-chine Learning”, “Natural Language Processing”, “Redes Neuronales” y “Re-presentaciones de palabras” (particularmente “Continuous Bag of Words” y “Skip-Gram”), que ser´an presentadas a continuaci´on.
2.5.1. Machine Learning
patrones en grandes vol´umenes de datos. El funcionamiento de las diferentes t´ecnicas consiste en crear programas capaces de generalizar comportamien-tos a partir de una informaci´on no estructurada suministrada en forma de ejemplos. Adem´as, las t´ecnicas de ML han sido de gran importancia en ´areas tales como la bioinform´atica, la recuperaci´on de informaci´on en la Web, la inteligencia de negocios y el desarrollo de veh´ıculos aut´onomos [22].
2.5.2. Natural Language Processsing
El Procesamiento de Lenguaje Natural o Procesamiento de Texto (Natu-ral Language Processing, NLP) es uno de los campos de investigaci´on m´as recientes dentro de la Inteligencia Artificial. El NLP se puede definir como la habilidad de una computadora para leer y manipular un documento de texto con el fin de obtener resultados ´utiles [4]. El NLP puede ser visto desde tres perspectivas diferentes, a saber:
Nivel de palabra: donde se puede determinar el origen morfol´ogico de una palabra, su estructura, etc.
Nivel de sentencia: se basa en el orden de una palabra dentro de una sentencia, su gram´atica, su significado en conjunto, etc.
Nivel global: se puede observar a una palabra en un contexto general, considerando el dominio y contexto general en el cual es utilizada. Esto se debe a que una palabra puede variar significativamente seg´un el contexto en donde se encuentra.
Dependiendo del tipo de an´alisis que se quiere realizar, se deber´an tener en cuenta las distintas caracter´ısticas de los mismos.
2.5.3. Redes Neuronales
informaci´on con la que trabajen (ya sean im´agenes, sonido, texto o series de tiempo), por lo que se deber´a hacer una transformaci´on de los datos de entrada a una representaci´on num´erica.
Las redes neuronales est´an formadas por neuronas y conexiones entre las ellas. Las neuronas son la unidad funcional de la red neuronal, las mismas reciben datos de entrada, los modifican seg´un diferentes criterios, y producen datos de salida. las conexiones entre las neuronas permiten que los datos fluyan desde un punto de entrada a uno de salida dentro de la red neuronal. Normalmente, las redes neuronales son especificadas considerando tres caracter´ısticas principales:
Arquitectura: indica las variables involucradas en la red neuronal y la topolog´ıa que forman.
Regla de actividad: las reglas locales de cada neurona que definen c´omo cambia la actividad neuronal en respuesta a diversos est´ımulos.
Regla de aprendizaje: especifican c´omo la importancia o influencia de cada neurona var´ıa en el tiempo
.
Las redes neuronales son muy utilizadas en la identificaci´on de caracte-res en im´agenes, debido a su facilidad para reconocer patrones. Por ejemplo, se utilizan en el ´ambito de la identificaci´on de patentes de autom´oviles que viajan por las rutas, de tal forma de automatizar el proceso de control de velocidad. Se captura una imagen de la patente del autom´ovil, junto a la velocidad con la que se encuentra viajando, y mediante una aplicaci´on que utiliza redes neuronales se identifican los caracteres que forman la paten-te, permitiendo que se pueda realizar una infracci´on al automovilista si la velocidad es mayor a la permitida.
2.5.4. Representaciones de Palabras
palabras a una representaci´on que sea entendible por los algoritmos de In-teligencia Artificial. Existen dos t´ecnicas de representaci´on de palabras que resultan de inter´es para el ´area de Arquitecturas de Software, denominadas “Continuous Bag of Words” y “Skip-Gram”. Ambas t´ecnicas permiten, a partir de un texto, generar una representaci´on vectorial del mismo.
El modeloContinuous Bag of Words(CBOW) es un m´etodo que se utiliza en el procesamiento de texto para representar documentos ignorando el or-den de las palabras [2]. Cada documento contendr´a un conjunto de palabras que conforman una estructura desordenada denominada bolsa. Las princi-pales ventajas de utilizar este modelo es su facilidad de uso y su eficiencia computacional. En este modelo, es posible predecir una palabra mediante el conocimiento del contexto en el que se encuentra, como se muestra en la Fi-gura 2.11, donde se cuenta con una entrada de m´ultiples palabras. A partir de las palabras de entrada se genera una proyecci´on, sumando sus valores provenientes del vector de palabras, y produciendo un valor de salida que representar´a a una palabra en particular.
Figura 2.11: Modelo de Continuous Bag of Words
palabra, predecir cu´al ser´a el contexto que rodea a la misma, como se mues-tra en la Figura 2.12, donde se cuenta con una sola palabra de enmues-trada. A partir de la proyecci´on del valor num´erico de la representaci´on de la palabra de entrada, es posible obtener un vector de salida con los valores que estar´an asociados a las palabras que forman el contexto de la palabra de entrada.
Figura 2.12: Modelo de Skip-Gram
3.
Trabajos Relacionados
El dise˜no de un sistema de software es una tarea compleja de realizar, para la cual es necesario contar con experiencia y conocimiento [6]. Es por esta raz´on que existen diversos trabajos que proponen mecanismos para au-tomatizar el proceso de especificaci´on y definici´on de la arquitectura de un sistema, de tal forma de disminuir la complejidad que conlleva dicha etapa. En este cap´ıtulo se presentan una serie de trabajos que proponen distin-tas alternativas de automatizaci´on. El cap´ıtulo se dividir´a en dos secciones principales, a saber: Aprendizaje supervisado y Aprendizaje no supervisado. Cada una de estas secciones contendr´a ejemplos de trabajos relacionados, problem´aticas y soluciones propuestas.
3.1.
Aprendizaje Supervisado
El aprendizaje supervisado es una t´ecnica de Inteligencia Artificial que permite generar una fuente de informaci´on a partir de datos de entrada pre-viamente clasificados [22]. De esta forma, si se tiene un dato no clasificado, se puede estimar una clasificaci´on mediante la fuente de informaci´on gene-rada previamente. A continuaci´on, se presentar´an una serie de trabajos que utilizan aprendizaje supervisado para resolver diferentes problem´aticas.
3.1.1. El Dise˜no de Arquitecturas de Software
En [13] se aborda la problem´atica que tienen ciertas organizaciones con respecto a tener el control interno de las aplicaciones que utilizan, e imple-mentarlas de tal forma que se satisfagan ciertos atributos de calidad. Ellos consideran que la implementaci´on de unaArquitectura Orientada a Servicios (SOA) teniendo en cuenta atributos de calidad (por ejemplo, performance, interoperabilidad, seguridad, entre otros.) requiere que los dise˜nadores explo-ren soluciones alternativas; esto resulta una tarea que consume mucho tiempo y es propensa a errores, incluso para dise˜nadores expertos.
Learning, conocida comoCase Base Reasoning (CBR). Esta t´ecnica permite obtener una soluci´on a un problema, mediante la b´usqueda de problemas si-milares dentro de una base de conocimiento formada por problemas previos y sus respectivas soluciones. La mayor´ıa de los dise˜nadores utilizan experien-cias pasadas para reutilizar soluciones que resuelvan el problema del dise˜no de una arquitectura hacia su implementaci´on; por eso, CBR naturalmente se ajusta en este proceso de dise˜no basado en la utilizaci´on del conocimiento de la organizaci´on [13].
En este enfoque, un caso Ci se define como una 2-upla<Pi, Si>, donde
Pi est´a compuesto por propiedades de un conector arquitect´onico, atributos
de calidad y escenarios de calidad para ese conector. Mientras que Si es la
materializaci´on de ese conector en t´erminos de dise˜nos orientados a objetos.
Figura 3.1: Enfoque basado en CBR
SOA en t´erminos de atributos de calidad, escenarios de calidad y conectores arquitect´onicos. Con la descripci´on del problema, se procede a recuperar de la base de casos aquellos casos que hayan sido ´utiles para resolver problemas similares [13]. Una vez que se encuentra la soluci´on m´as adecuada al problema planteado, se puede evaluar si la misma fue correcta, permitiendo agregar el problema resuelto en la base de casos para que pueda ser usado en el futuro.
3.1.2. Identificaci´on y Clasificaci´on de Requerimientos No
Fun-cionales
En [11] y [14] se plantea la problem´atica de realizar la captura de requeri-mientos de un sistema. Dicha tarea ocurre en una etapa temprana del dise˜no de un sistema, y no es sencilla de llevar a cabo, principalmente debido a que las partes interesadas en el sistema pueden no tener una visi´on clara de lo que el sistema debe realizar, ni c´omo debe hacerlo. La captura de requerimien-tos funcionales resulta ser m´as evidente durante el proceso de elicitaci´on del sistema; esto no ocurre as´ı para el caso de los requerimientos no funcionales. Para resolver esta problem´atica, existen dos propuestas. La primera utiliza t´ecnicas de aprendizaje semi-supervisado [11], y la segunda de aprendizaje supervisado [14].
clasifica-dos. Opcionalmente, los requerimientos clasificados con la mayor confianza, o aquellos que hayan recibido un buen feedback por parte de los analistas, pueden ser utilizados como requerimientos categorizados para repetir el pro-ceso de aprendizaje [11].
Figura 3.2: Acercamiento semi-supervisado para la clasificaci´on de requeri-mientos no funcionales
Figura 3.3: Acercamiento supervisado para la clasificaci´on de requerimientos no funcionales
3.2.
Aprendizaje No Supervisado
3.2.1. Duplicaci´on de Funcionalidad: ReqAligner
En [28] se propone una alternativa para poder resolver el problema de la duplicaci´on de funcionalidad en la especificaci´on de los requerimientos de un sistema. Esta alternativa llamada ReqAligner ayuda a los analistas en la b´usqueda de funcionalidad duplicada en especificaciones textuales de requerimientos, mediante t´ecnicas avanzadas de procesamiento de texto.
En la Figura 3.4, se puede observar el esquema de funcionamiento de la herramienta ReqAligner, que consta de cinco pasos, a saber:
1. Procesamientodel Lenguaje Natural b´asico sobre las especificaciones de requerimientos.
2. An´alisissem´antico de las especificaciones. 3. Generaci´on de secuencias de especificaciones.
4. Alineamiento de las secuencias de especificaciones.
5. Recomendaciones sobre las relaciones entre especificaciones.
Figura 3.4: Esquema de la herramienta ReqAligner para la especificaci´on de casos de uso
3.2.2. Definici´on de Requerimientos No Funcionales
En [15] se propone una alternativa para asistir a los analistas en el dise˜no de sistemas de software, m´as puntualmente en la especificaci´on de requeri-mientos no funcionales. Se identifican dos problemas relativos a la definici´on de requerimientos no funcionales, a saber:
1. Las definiciones no son precisas, y por ende no son entendibles ni aplicables.
2. Las definiciones no proveen ayuda o soporte en su aplicaci´on a un contexto organizacional dado.
Figura 3.5: Esquema de funcionamiento
posible adaptar el atributo de calidad performance a un contexto organiza-cional espec´ıfico, produciendo especificaciones textuales de los requerimientos no funcionales de un sistema (Figura 3.5).
El esquema de funcionamiento de la propuesta consta de cuatro partes distintas, a saber:
1. Identificaci´on de elementos de contenido relevante.
2. Definici´on precisa de los elementos de contenido relevante. 3. Adaptaci´on a un contexto organizacional.
4. Proveer una forma de especificar los requerimientos en sentencias.
3.3.
Conclusiones
4.
Derivaci´
on de Escenarios de Atributos de
Calidad con ScenariosTool
La especificaci´on de escenarios de atributos de calidad es una tarea dif´ıcil de realizar. Esto se debe, principalmente, a que el arquitecto debe poseer una amplia experiencia y conocimiento en el dise˜no de sistemas de software. Adem´as, los arquitectos pueden estar especializados en solo algunos atribu-tos de calidad espec´ıficos. En la pr´actica, la informaci´on sobre atributos de calidad de la mayor´ıa de los proyectos de software suele documentarse de for-ma parcial y entremezclada con las especificaciones funcionales del sistefor-ma [7]. Para resolver el problema de la especificaci´on de escenarios de atribu-tos de calidad, distinatribu-tos autores han planteado diferentes propuestas como asistentes inteligentes y recomendadores [15]. Estas propuestas utilizan en su mayor´ıa t´ecnicas de aprendizaje supervisado, que requieren una gran canti-dad de instancias para su implementaci´on. Adem´as, las mismas ofrecen poca flexibilidad frente a cambios, ya que requieren procesos de re-entrenamiento y procesamiento manual de datos, entre otros.
En este contexto, el enfoque que se presenta en este cap´ıtulo permite ayudar a los arquitectos en la definici´on de escenarios de atributos de cali-dad durante el dise˜no de un sistema. El objetivo principal de este enfoque es aprovechar de t´ecnicas de Inteligencia Artificial para poder asistir de forma semi-autom´atica a un arquitecto que no cuenta con la experiencia o conoci-miento suficiente para especificar escenarios de atributos de calidad. Adem´as, el enfoque tambi´en permite guiar a arquitectos experimentados que quieren verificar decisiones tomadas. La hip´otesis de trabajo es que es posible que una computadora adquiera conocimiento sobre conceptos de arquitecturas de software. A partir de este aprendizaje y en base a ejemplos de escenarios completos, se puede inferir informaci´on de otros escenarios incompletos los cuales no han sido precargados con anterioridad.
de arquitecturas de software, papers cient´ıficos, gu´ıas de dise˜no, entre otros. Estos documentos son utilizados para conformar la fuente de conocimiento del enfoque, la cual es generada una sola vez y utilizada reiteradas veces pos-teriormente. A diferencia de las t´ecnicas de aprendizaje supervisado, en este enfoque no se realiza una clasificaci´on de los documentos que conforman la fuente de conocimiento. Adem´as, se requiere una colecci´on de escenarios de atributos de calidad completos comoassets. Dichos escenarios se encuentran especificados completamente y son brindados al enfoque por un experto. Los mismos son utilizados como referencia para obtener informaci´on de escena-rios especificados parcialmente. Ante la consulta de un arquitecto respecto a un escenario de atributos de calidad incompleto, el enfoque produce suge-rencias a partir de un razonamiento mediante analog´ıa entre los escenarios completos de referencia y la informaci´on aprendida por la computadora. Este razonamiento mediante analog´ıa establece relaciones entre partes especifica-das de escenarios de atributos de calidad de tal forma que sea posible inferir partes faltantes. Las sugerencias brindadas pueden ser utilizadas por el ar-quitecto para completar de forma apropiada los escenarios del sistema que est´a desarrollando.
A continuaci´on, se presentar´a el enfoque desarrollado en este trabajo. Inicialmente se introduce el funcionamiento general del mismo, mediante un gr´afico explicativo. Posteriormente, se detallan los componentes que forman el enfoque y la relaci´on entre los mismos.
4.1.
ScenariosTool
fuente de conocimiento (1.Preprocesamiento) y se genera unmodelo como salida (2.Generador del modelo). En esta etapa es necesaria la interven-ci´on de un experto, cuya tarea es seleccionar informaci´on ´util para conformar la fuente de conocimiento. Una vez que el enfoque genera el modelo, el mismo puede ser utilizado reiteradas veces en la etapa posterior por el arquitecto. El modelo est´a compuesto por todas las palabras que componen la fuente de conocimiento, junto a una representaci´on vectorial de cada palabra. Esta representaci´on vectorial describe a cada palabra en t´erminos de su contexto y cantidad de apariciones de la misma en la fuente de informaci´on [2]. Dicha representaci´on resulta ´util para poder realizar operaciones algebraicas entre palabras, ya que las mismas son representadas mediante vectores num´ericos. La segunda etapa, denominada Razonamiento, es la encargada de utilizar el modelo de tal forma que se puedan extraer datos relativos a informaci´on faltante o incompleta de escenarios de atributos de calidad. En esta etapa se utilizan el modelo generado previamente y un conjunto de escenarios de atri-butos de calidad de referencia comoassets, brindados al enfoque una sola vez por un experto. Como entrada para esta etapa, el arquitecto ingresa un esce-nario incompleto. Como salida, el componente3.Recomendaci´oncompleta la informaci´on faltante del escenario ingresado. En la etapa de Razonamien-to, se realiza un razonamiento mediante analog´ıa entre la informaci´on de las partes de los escenarios de referencia y el escenario parcial ingresado por el arquitecto. Las partes involucradas en la analog´ıa pueden ser trasladadas al modelo generado previamente y obtener as´ı informaci´on faltante.
la t´actica para satisfacer modificabilidad. El mismo razonamiento puede ser utilizado para inferir partes de escenarios de atributos de calidad. Por ejem-plo, si se sabe que un Est´ımulo se relaciona con una Medida de Respuesta de una cierta manera, dado otro Estimulo se puede inferir una Medida de Respuesta que se relacione de la misma manera.
Figura 4.1: Esquema de funcionamiento
de referencia.
Figura 4.2: Interfaz gr´afica de la herramienta
4.2.
Aprendizaje: Preprocesamiento y Generaci´
on del
Modelo
repa-raci´on cuando ocurren fallas en los mismos. A partir del preprocesamiento y la transformaci´on vectorial, es posible registrar la correlaci´on entre las fa-llas de un sistema y el tiempo como una medida de respuesta al est´ımulo, principalmente por las reiteradas apariciones en conjunto de estas dos partes. Para poder generar el modelo, resulta necesario definir dos componen-tes, que ser´an los encargados de transformar una fuente de informaci´on de entrada en el modelo descrito anteriormente. Estos componentes son deno-minadosPreprocesamiento y Transformaci´on a representaci´on vectorial, que se detallan a continuaci´on.
4.2.1. Preprocesamiento
El componente de preprocesamiento es el encargado de procesar los docu-mentos de arquitectura de software (papers cient´ıficos, libros, entre otros), de tal forma que se elimine la informaci´on que no es relevante para el an´alisis y de preparar la informaci´on relevante al formato adecuado para ser procesada. Este preprocesamiento de los documentos es importante ya que en los mismos existen palabras, como pueden ser conectores del lenguaje, art´ıculos, preposi-ciones, etc., las cuales deben ser excluidas ya que no aportan informaci´on de importancia e incluso pueden llegar a disminuir la eficacia de los algoritmos de inferencia aplicados a los documentos [5]. Asimismo, debido a que la in-formaci´on de los documentos puede estar almacenada en diversos formatos, los documentos se deben transformar a una representaci´on apropiada para la manipulaci´on de su informaci´on.
Figura 4.3: Componente de Preprocesamiento
distintos “valores” que pueden tener las partes de los escenarios, o bien men-cionar ejemplos de sistemas reales, ense˜nar la especificaci´on de escenarios, entre otros. A partir de alguna de estas caracter´ısticas, los textos son ´utiles para ser utilizados por ScenariosTool.
Internamente, el preprocesamiento se encarga de manipular los datos de entrada, de tal forma que la salida producida no contenga caracteres o pa-labras inv´alidas. Las t´ecnicas utilizadas en esta herramienta son eliminaci´on de caracteres y modificaci´on de caracteres:
Modificaci´on de Caracteres En cuanto a la modificaci´on de caracteres, se aplica un filtro que permite transformar todas las letras de la entrada en letras min´usculas. Este filtro es aplicado debido a la necesidad de mantener una relaci´on de igualdad entre las diferentes formas de escribir una misma palabra. Por ejemplo, en la oraci´on: “1. The User wants to modify the UI, it should not take more than 2 days.”, la palabra User (may´uscula) tiene el mismo significado que la palabra user (min´usculas) en el contexto de este trabajo. Si no se aplicase este filtro, las palabras podr´ıan no ser considera-das como equivalentes en etapas posteriores del an´alisis y la derivaci´on de escenarios, produciendo equivocaciones al realizar las recomendaciones a los arquitectos.
“1) There are several known tactics to satisfy Performance. For instance, the usage of a cache memory is always considered a good option. 2) In the same way, if a system has to achieve a high level of Modifiability,
using an intermediary would be a wise decision! ”
Inicialmente, se transforman todos los caracteres en las palabras del frag-mento a min´usculas, por lo que el mismo se convertir´ıa en:
“1) there are several known tactics to satisfy performance. for instance, the usage of a cache memory is always considered a good option.
2) in the same way, if a system has to achieve a high level of modifiability, using an intermediary would be a wise decision! ”
Como resultado, las palabrasThere,Performance,For,In y Modifiability fueron cambiadas athere,performance,for,in ymodifiability, respectivamen-te.
Eliminaci´on de caracteres En cuanto a la eliminaci´on de caracteres, exis-ten diferentes filtros que son aplicados por el preprocesador. En una primera instancia, se eliminan de la entrada todas las palabras denominadas Stop Words. Estas palabras son de uso frecuente en la escritura (como pueden ser art´ıculos, conectores, preposiciones, entre otros), que no agregan ning´un va-lor adicional al contexto donde se encuentran las dem´as palabras. Ejemplos de Stop Words en Ingl´es son: “a”, “of”, “the”, etc. Por otro lado, tambi´en se utilizaron filtros que eliminan caracteres que no aportan informaci´on al objetivo de la herramienta, como pueden ser n´umeros, signos de exclamaci´on y puntuaci´on, y cualquier caracter que no sea ASCII.
Continuando con el ejemplo, se eliminan las palabras Stop Words. En el fragmento, el resultado ser´ıa:
“1) known tactics satisfy performance. , usage cache memory considered option.
Por ´ultimo, se eliminan los caracteres inv´alidos (“1”, “)”,“.”, “,”, “2”,“!”), reduciendo el texto original del fragmento a las siguientes dos oraciones:
“known tactics satisfy performance usage cache memory considered option” “system has achieve high level modifiability using intermediary wise
decision”
4.2.2. Generador del Modelo con las Caracter´ısticas de las
Pala-bras
La segunda parte de la primera etapa, denominada Generador del Mode-lo, est´a encargada de la construcci´on de una representaci´on vectorial de las palabras que conforman el texto preprocesado. Para la implementaci´on de este componente, se utiliza un framework externo, denominado word2vec
[2]. El mismo fue desarrollado porGoogle, y su principal funci´on es el an´alisis de texto para obtener una representaci´on vectorial de las palabras que lo con-forman seg´un su contexto y cantidad de apariciones. El modelo producido por word2vec resulta de gran utilidad para este trabajo ya que la repre-sentaci´on vectorial de las palabras permite establecer relaciones de distancia entre las mismas.
El framework word2vec est´a conformado por una red neuronal de 3 capas (capa de entrada, capa oculta, capa de salida), especializadas en el procesamiento de texto. Word2vec recibe como entrada un documento de texto, y produce como resultado una lista de palabras, donde cada palabra tiene asociado un vector num´erico que la representa. A cada componente num´erica del vector que representa una palabra en el modelo se la denomina caracter´ıstica. Una caracter´ıstica resume informaci´on sobre la aparici´on de la palabra en diversos contextos en relaci´on con otras palabras, junto con la cantidad de apariciones de la palabra en la fuente de conocimiento.
Por fines pr´acticos y para comprender en detalle la generaci´on de las caracter´ısticas de las palabras, se considera como texto de entrada para
intermediary”. La cantidad de palabras del texto preprocesado se denomina
N, en el caso del ejemplo N = 4. El framework word2vec crea N vectores unitarios de N dimensiones, denominados V0..N−1. Cada vector unitario se
utiliza para representar a una palabra. Adem´as, cada palabra est´a asociada a una de las N dimensiones de los vectores unitarios, seg´un su orden de apa-rici´on en el texto preprocesado. Dichos vectores unitarios est´an compuestos de todos ceros menos en la dimensi´on asociada a la palabra que representan, donde su valor es 1. Por ejemplo, la palabra performance est´a asociada a la dimensi´on 0 por ser la primera en el texto preprocesado, por ende su vector unitario es V0 = [1,0,0,0]. Del mismo modo, la palabra modifiability est´a
asociada a la dimensi´on 2 por ser la tercera en el texto preprocesado, por ende su vector unitario es V2 = [0,0,1,0].
Cada vector unitario es asociado a una neurona que conforma la capa de entrada. En la capa oculta se encontrar´an dos matrices, denominadas W I
de tama˜no N ×C y W O de tama˜no C ×N, donde C indica el n´umero de caracter´ısticas (C = 100 es el valor por defecto sugerido por los desarrolla-dores del framework). Finalmente, la capa de salida est´a conformada por un vector de salida, que tiene asociada una palabra a cada neurona que compone la capa (Figura 4.4), indicando la probabilidad de que la palabra asociada a la neurona de salida aparezca en el contexto de la palabra de entrada. El framework word2vec busca realizar una optimizaci´on de los valores de la matriz W I y W O de tal forma que se aprendan relaciones entre palabras. Para que se aprenda una relaci´on entre dos palabras, el vector unitario de la primera de ellas es el vector de entrada. La red neuronal calcula el vector de salida y el mismo es sustra´ıdo al vector unitario que representa la segunda palabra con el fin de calcular el error. Una vez obtenido el error, el mismo es propagado hacia la red neuronal de tal forma que se actualizan los valores de las matrices W I y W O. Este procedimiento se repite para cada par de palabras que est´an relacionadas. Una palabra est´a relacionada con otra si la segunda aparece en el contexto de la primera de ellas.
ume-Figura 4.4: Red neuronal de word2vec
ros reales entre -1 y 1. Estos valores son elegidos al azar ya que los mismos var´ıan a trav´es de las diferentes relaciones entre palabras que se aprenden, siendo ajustados constantemente hasta terminar el proceso de aprendizaje. Continuando con el ejemplo, se supone el siguiente contenido inicial para las matrices, considerando C = 3:
W I =
−0,094491 0,443977 0,313917
−0,490796 −0,229903 0,065460 0,072921 0,172246 −0,357751 0,104514 0,463000 0,079367
W O=
0,023074 0,479901 0,432148 0,375480
−0,368008 −0,424778 −0,257104 −0,148817 0,422434 0,364503 0,467865 −0,020302
Sup´ongase que en el ejemplo solo se quiere aprende la relaci´on entre las palabras modifiability eintermediary. En este caso, se consideran los vectores
V2 = [0,0,1,0] y V3 = [0,0,0,1], correspondientes a las palabras
vector V3 sirve para calcular el error del resultado, indicando que la palabra
intermediary est´a en el contexto de la palabra modifiability. La red neuronal toma el vector V2 y lo multiplica por la matriz W I, y como resultado se
ob-tiene el vector W I[2] = [0,072921; 0,172246;−0,357751]. Posteriormente, el resultado obtenido es multiplicado por la matriz W O, obteniendo el vector
V O = [−0,212832;−0,168573;−0,180152; 0,009010], que representa la capa de salida de la red neuronal. Para transformar el vector V O en un vector de probabilidades se utiliza la funci´on softmax, de tal forma que la suma de todos los valores de las neuronas de la capa de salida sumen 1. Una vez obtenidas las probabilidades, se calcula el error con respecto al vector V3
(valor esperado como resultado), y a partir de dicho error los valores de las matrices W I y W O son actualizados para disminuirlo. Luego de realizar el proceso de aprendizaje, el contenido de W I es una buena aproximaci´on que contiene la informaci´on de las relaciones entre las palabras. Para el ejemplo, el resultado es el siguiente:
W I =
−0,127484 0,106689 0,022012
−0,152681 0,112004 0,061398 0,164218 0,097453 0,110850
−0,105762 0,043238 −0,085115
El modelo es constituido por la lista de palabras y sus respectivos vectores de caracter´ısticas, que corresponden a las filas de la matriz W I. A partir de estos vectores, es posible cuantificar la relaci´on existente entre las palabras. Esta relaci´on puede ser medida por la similitud de sus caracter´ısticas. Dicha similitud puede ser calculada como un valor decimal de 0 a 1 (1 m´as lejano, 0 m´as cercano), conocido como distancia del coseno. De esta forma, la dis-tancia entre dos palabras se reduce a una simple operaci´on matem´atica entre vectores. Continuando con el ejemplo, se obtienen los siguientes resultados de distancia:
distancia(“modif iability00,“perf ormance00) = 0,833
distancia(“modif iability00,“cache00) = 0,782
Como las primeras dos palabras no fueron brindadas a la red neuronal para formar el contexto de la palabramodifiability, su distancia a la misma es mayor, lo que implica una menor similitud. Como el contexto demodifiability fue formado por la palabraintermediary, la distancia entre las mismas es baja (es decir, son similares y se encuentran “espacialmente cerca”).
El procedimiento mostrado anteriormente muestra el funcionamiento b´ asi-co del algoritmo pero el mismo es implementado asi-con leves mejoras enword2vec, principalmente para soportar una gran cantidad de palabras de entrada y considerar un contexto m´as grande para cada palabra mediante la aplicaci´on de las t´ecnicas Continuous Bag of Words y Skip-Gram [2]. Continuous Bag of Words realiza una modificaci´on en la capa de entrada, la cual produce una entrada para la capa oculta conformada por un vector conteniendo el pro-medio de todos los vectores de palabras que conforman el contexto. Por otro lado, Skip-Gram realiza una modificaci´on en la capa de salida, generando tantos vectores de salida como palabras haya en el contexto. Por cada vector de salida, se calcula la funci´on softmax, y se realiza un promedio entre los errores obtenidos, que ser´a propagado hacia la red neuronal. En Scenarios-Tool, word2vec fue configurado con un C = 100, N = 7675, el algoritmo utilizado fue Skip-Gram.
4.3.
Razonamiento Arquitect´
onico
4.3.1. Recomendaci´on de Partes de Escenarios de QA
A partir del modelo generado en la etapa de Aprendizaje, el componente que conforma esta etapa es capaz de recomendar informaci´on de escenarios de atributos de calidad haciendo un razonamiento por analog´ıa. La entrada del componente de recomendaci´on es un escenario con informaci´on faltante ingresado por el arquitecto como consulta. Adem´as, el modelo generado en la etapa anterior y un conjunto de escenarios preexistentes con informaci´on completa (definidos y provistos una ´unica vez por un experto) son utilizados como assets. Por otra parte, la salida del componente son las posibles partes de escenarios que pueden complementar la documentaci´on del sistema que el arquitecto quiere dise˜nar en un atributo de calidad particular.
principales. Dichas dimensiones principales que no son filtradas son divididas en dos grupos y combinadas para conformar solamente dos dimensiones. En la Figura 4.5 se pueden observar las tres palabras ubicadas en un espacio bidimensional. Se observa que contando con las representaciones vectoriales de las palabras “internal”, “recover” y “external” es posible, mediante ope-raciones vectoriales, encontrar espacialmente el lugar o la vecindad donde deber´ıa encontrarse la parte que se quiere inferir. A este lugar espacial se lo denomina vector resultado. De esta forma, si al vector que representa la palabra “internal” se le sustrae el vector que representa la palabra “exter-nal”, y al resultado se le suma el vector que representa la palabra “recover”, entonces se obtiene el vector resultado. Los vectores positivos en la ecuaci´on son denominadosfactores positivos, mientras que los negativos se denominan factores negativos. La ecuaci´on tendr´a la siguiente forma:
VectorResultado = vector(“internal”) - vector(“external”) + vector(“recover”)
El vector resultado deber´a ser comparado con las palabras que conformen el modelo para encontrar aquellas m´as cercanas. Dichas palabras formar´an una vecindad de conceptos posibles (ilustrado con un c´ırculo en la Figura 4.5), los cuales ser´an retornados al arquitecto como recomendaci´on para completar el escenario ingresado. En este caso, la palabra “detect” debe encontrarse en la vecindad de conceptos, producto del aprendizaje de libros de arquitectura y dise˜no de software.
Figura 4.5: Ejemplo sobre recomendaci´on por analog´ıa
consideraci´on de m´as partes de escenarios en el c´alculo del vector resultado implica un mejor resultado, ya que la vecindad obtenida se hace m´as peque˜na y se focaliza en las partes buscadas.
punteadas entre las palabras que hacen referencia a una misma parte de los escenarios de calidad para facilitar la comprensi´on. La ecuaci´on correspon-diente a dicho resultado del ejemplo deber´ıa considerar como valores positivos a las partes con informaci´on del escenario incompleto m´as la informaci´on del escenario preexistente correspondiente a la parte faltante, a saber: “recover”, “internal”, “fault” y “system”. Mientras que los factores negativos deber´ıan ser el contexto del escenario preexistente, a saber: “external”, “crash” y “sys-tem”. Una peculiaridad es que ambos escenarios contienen la palabra system para la parte Artifact, la cual es identificada con color verde. La ecuaci´on quedar´ıa formada de la siguiente forma:
VectorResultado = vector(“recover”) vector(“external”) vector(“crash”) -vector(“system”)+ vector(“internal”) + vector(“fault”) + vector(“system”)
Figura 4.6: Ejemplo del segundo resultado de la Figura 4.7
En este caso, como la cantidad de partes consideradas de los escenarios para realizar el razonamiento mediante analog´ıa es mayor, se cuenta con m´as vec-tores involucrados en la operaci´on algebraica, reduciendo as´ı el tama˜no de la vecindad de palabras en torno al vector resultado. Esto produce mejores resultados, como se puede observar en las vecindades encontradas. Por un lado, el ejemplo extendido infiere como palabras m´as cercanas al vector re-sultado a detection y recovery, que pueden ser utilizadas como la Respuesta del escenario. Por otro lado, al usar menos informaci´on, no todas las palabras m´as cercanas al vector resultado pueden ser utilizadas como laRespuesta del escenario, por ejemplotactic. De esta forma, se observa en los resultados ob-tenidos en la versi´on extendida que considera m´as informaci´on en el c´alculo del resultado es m´as precisa.
4.4.
Resumen
En este cap´ıtulo se present´o el enfoque propuesto junto con la herramien-ta que lo materializa. Para ilustrar su funcionamiento, herramien-tambi´en se describi´o el desarrollo de la interfaz gr´afica que permite que los arquitectos puedan utilizar la herramienta de forma simple. El objetivo principal de este enfoque es asistir a un arquitecto que no cuenta con la experiencia o conocimiento suficiente para realizar la especificaci´on completa de los escenarios de atri-butos de calidad de un sistema durante la etapa de dise˜no del mismo. Este objetivo se logra mediante el aprovechamiento de t´ecnicas de Inteligencia Ar-tificial, que asisten al arquitecto de forma semi-autom´atica. El enfoque est´a dividido en dos etapas. La primera etapa, denominada Aprendizaje, es la en-cargada de aprender relaciones entre las diferentes partes de los escenarios de atributos de calidad a partir de documentos y literatura de arquitecturas de sistemas de software. El aprendizaje es realizado con el frameworkword2vec
5.
An´
alisis de Resultados
En este cap´ıtulo se presenta una evaluaci´on de la herramienta Scena-riosTool, simulando la asistencia a un arquitecto al especificar escenarios de atributos de calidad. Para determinar el desempe˜no de la herramienta, la misma fue evaluada a partir de un conjunto de escenarios de atributos de calidad obtenidos de diversas fuentes bibliogr´aficas y sistemas reales. El objetivo principal de la evaluaci´on fue, a partir del razonamiento median-te analog´ıa realizado con escenarios de atributos de calidad de referencia, determinar si era posible inferir correctamente las partes de un escenario parcial. La hip´otesis experimental es que la herramienta es capaz de sugerir informaci´on faltante de escenarios de atributos de calidad, permitiendo al ar-quitecto que la utiliza elegir el resultado que m´as se ajuste al sistema que est´a desarrollando. Para poner a prueba la hip´otesis planteada, como as´ı tambi´en guiar el an´alisis de los resultados, se plantearon las siguientes preguntas de investigaci´on:
PI#1 : ¿Sirve un ´unico escenario de atributo de calidad de referencia para inferir partes de otro escenario del mismo atributo?
PI#2 : ¿Sirve un conjunto de escenarios de atributos de calidad de referencia para inferir partes de otro escenario del mismo atributo?
PI#3 : ¿Sirve un conjunto de escenarios de cualquier atributo de calidad para inferir partes de otro escenario?