2.3 Estimation
2.3.2 Calibration, prior selection, estimation settings, and estimation
La Tabla 2 presenta un resumen de los trabajos discutidos en esta sección. Los mismos, fueron comparados de acuerdo a seis características, a saber: artefacto analizado, técnicas, objetivo del análisis, salida, ventajas y desventajas. El campo artefacto analizado hace referencia al tipo de documentación que se analiza en cada herramienta. El campo técnicas hace referencia a las técnicas aplicadas por cada herramienta. El campo objetivo se refiere al propósito de la herramienta. El campo salida indica cual es el resultado de la ejecución de la herramienta. Por último, las ventajas/contribuciones y desventajas/limitaciones enuncian los pro y contras de cada herramienta analizada.
3.4 Resumen
A partir de los enfoques analizados, se puede concluir que independientemente del documento textual que se requiera analizar, es primordial hacer el análisis en etapas tempranas del desarrollo. A menudo sucede que no hay tiempo suficiente para realizar análisis manuales o en otros casos estos análisis pueden omitir u obviar determinada información crítica para el desarrollo del sistema, que de no ser detectada a tiempo puede tener como consecuencia el fracaso del proyecto.
El volumen de información contenida en los documentos y los diferentes intereses de los lectores hace indispensable que se cuente con técnicas que faciliten la escritura y la navegación/filtrado de los documentos. El Procesamiento de texto en Lenguaje Natural (NLP) está presente en gran parte de los trabajos analizados en este capítulo, con el propósito de detectar y recuperar información relevante. Asimismo, se evidencia el uso de tecnologías Wikis para el almacenamiento y gestión de documentos SADs, debido a que ofrece un entorno flexible y amigable (comparado con ambientes de documentación tradicionales).
35
36
4. Enfoque SadAnalyzer
La definición de la arquitectura de un sistema es una tarea compleja y una correcta documentación es importante para el éxito del proyecto ya que permite dejar asentadas las estructuras del sistema y las decisiones de diseño que satisfacen los atributos de calidad. Además de servir como repositorio de conocimiento arquitectónico, el SAD (Software Architecture Document) es un medio de entendimiento y comunicación entre los stakeholders del proyecto.
Los stakeholders pueden encontrarse con diferentes problemas relacionados a la diversidad de formatos y estructuras al tratar de comprender el contenido de un SAD. Esto podría ocurrir al comparar SADs de diferentes organizaciones o de una misma organización en la que no se tiene bien definido un estándar de documentación. Asimismo, los stakeholders pueden tener diferentes propósitos al utilizar este documento [CLE10], por ejemplo, un arquitecto puede analizar el SAD para negociar tradeoffs, un programador para asegurar que se respeten las decisiones de diseño, un tester para crear pruebas de sistema que validen los atributos de calidad, o un administrador de redes para determinar si el sistema soporta la carga de operación, entre otros. Estas características sumadas al volumen del SAD hacen que la inspección manual del documento pueda resultar una tarea tediosa.
En este contexto, las herramientas que faciliten el acceso a información de interés para un stakeholder particular podrían ser de gran ayuda para reducir los tiempos de búsqueda y filtrar partes del SAD que no son relevantes a un stakeholder particular. En este capítulo, se describe un enfoque para asistir al stakeholder en el proceso de análisis de un SAD y para ello se plantea analizar un documento de arquitectura teniendo en cuenta las etapas definidas en la Figura 13. Debido que el SAD a analizar será un archivo en formato digital, y de acuerdo con las problemáticas planteadas anteriormente, se plantea un enfoque en 3 etapas. En primer lugar, la etapa de Lectura del Documento permite extraer el contenido, independientemente del formato en el que se encuentre el mismo. La etapa de Procesamiento, a continuación, tiene la responsabilidad de identificar las estructuras sintácticas y semánticas del texto por medio de técnicas NLP. Por último, la etapa de Consulta utiliza las estructuras identificadas en la etapa anterior para recuperar fragmentos de texto que respondan a las consultas realizadas por diferentes interesados. A continuación se detalla cada una de las etapas mencionadas.
4.1 Etapa de Lectura
La etapa de Lectura de Documentos será la encargada de obtener el texto de un SAD proveniente de una las distintas fuentes digitales de información disponibles (HTML, PDF, Wiki, etc.). Cada una de estas fuentes de información tiene una manera distinta de almacenarse, por lo que es importante abstraerse del formato de los documentos de
37
manera que la información obtenida del proceso de lectura no quede ligada al formato original del documento.
La clave para extraer el texto del documento es contar con diferentes mecanismos de lectura del SAD y generar una única estructura de información como entrada para la etapa de procesamiento.
Figura 13: Esquema inicial
En la Figura 14 se ilustra el proceso de lectura para el ejemplo del Sistema de voto electrónico en formato Dokuwiki2. El SAD recibido como entrada es procesado por el mecanismo de lectura acorde para el formato Dokuwiki, recuperando el contenido de cada una de las secciones (Figura 14: Background de la Solución) referenciadas en el índice. Como resultado, se obtiene una lista de secciones con el texto plano correspondiente a cada una de ellas, que será tomado como fuente de información para la etapa de procesamiento. En la Figura 14 ya referenciada, se observa en la salida el mismo texto tomado como entrada pero ya sin formato.
4.2 Etapa de Procesamiento
En esta etapa, se toma el texto resultante de la etapa de Lectura que en general es extenso y desestructurado (texto plano y sin formato) escrito en lenguaje natural. Básicamente, la herramienta busca descomponer el texto de los SADs en constructos lingüísticos tales como párrafos y oraciones. Luego, por cada oración busca identificar
2
38
cada palabra y descartar aquellas que no aportan valor al análisis (artículos, pronombres y preposiciones). A las palabras restantes se las lleva a su raíz y se las etiqueta con la categoría gramatical correspondiente.
Figura 14: Proceso de lectura - Sistema de Voto Electrónico – Dokuwiki
En la Figura 15 se visualiza un fragmento de la documentación del Sistema de Voto electrónico, en la que se resalta una oración que contiene palabras destacadas para ejemplificar el procesamiento que se realiza sobre el texto. En primer lugar, se descartan las palabras que no aportan información, como es el ejemplo de las preposiciones “a”, “que” y “de”. Luego, tomando como referencia la palabra “soportada” se la lleva a su raíz y se la etiqueta con su categoría gramatical, “soportado” y “adjetivo” respectivamente. En la Figura 15 ya referenciada pueden observarse más ejemplos del procesamiento realizado a cada palabra.
Esta información, será tomada como entrada de la Etapa de Consulta de manera de brindarle la información necesaria para realizar el análisis semántico de la oración y recuperar con éxito la información solicitada por el stakeholder.
4.3 Etapa de Consulta
La etapa de Consulta será la encargada de brindar al stakeholder la posibilidad de realizar consultas sobre el documento procesado y recuperar la información deseada.
39
Para ello se utilizan los resultados obtenidos de las etapas anteriores mediante un conjunto de consultas definidas por expertos del dominio.
A partir de la información gramatical deberá definirse el conjunto de consultas buscando identificar información que se considere relevante, para ello las consultas podrían ser creadas basándose en palabras claves, relaciones entre palabras o detección de expresiones que definan el concepto que se quiere buscar. El resultado de las consultas será el conjunto de oraciones que satisfagan el criterio de búsqueda establecido.
Figura 15: Análisis sintáctico de una sentencia
Se definen dos tipos de consultas a saber: generales y específicas. Las consultas generales están destinadas a identificar un determinado atributo de calidad a partir de su definición. Las consultas específicas están destinadas a detectar tácticas o técnicas asociadas a un atributo de calidad. A modo de ejemplo, considere que un arquitecto podría estar interesado en consultar aquellos lugares donde se describe un escenario de calidad de Escalabilidad (consulta general - Figura 16), o también podría estar interesado en analizar las tácticas que se utilizan para satisfacer dicho atributo de calidad (consulta específica - Figura 17).
40
Figura 16: Consulta general - Escalabilidad
41
5. Materialización SadAnalyzer
Para materializar el enfoque propuesto, se desarrolló la herramienta SADAnalyzer (Software Architecture Document Analyzer). La misma está compuesta de dos plugins para el IDE Eclipse. A continuación se presenta el ejemplo de Sistema de Voto Electrónico analizado a lo largo del trabajo de investigación de manera de describir los plugins desarrollados.