Técnica para reusar artefactos de análisis y diseño en el modelamiento de software

Transcripción

1 Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (67-78) Universidad La Salle Arequipa, Perú Técnica para reusar artefactos de análisis y diseño en el modelamiento de software 1 Percy Oscar Huertas Niquén Universidad La Salle Arequipa, Perú 2 Juan Lazo Lazo Laboratorio de Inteligencia Computacional Aplicada Río de Janeiro, Brasil Resumen Una de las infraestructuras de soporte son los artefactos de software, cuya concepción permite llegar a comprender, en su totalidad, la lógica del negocio del problema a resolver. El versionamiento se comporta como un repositorio de documentos con información útil para el personal que está modelando un nuevo sistema de información. Estos documentos también contribuyen al aprendizaje por medio de la consulta de activos que incluyan ejemplos y material de formación para entender y aplicar la lógica del negocio. El presente trabajo de investigación propone una técnica que permite conseguir la reutilización de los artefactos de software de manera que contribuyan en la construcción de un nuevo producto. Esta técnica implementa un procedimiento de acción que permite utilizar aquellos componentes que pueden servir de base para la conceptualización de productos de software nuevos. Palabras clave: reuso, diseño en modelamiento, software. Cuando se construyen productos de desarrollo de software, estos se encuentran basados en un proyecto de desarrollo que contienen procesos que deben ser respetados para lograr productos de calidad (Pressman, 2005; Sommerville, 2005). Cuando se obedecen estos procesos, el desarrollo se torna fácil en todo el ciclo, la veri cación y control de la calidad aumentan la con anza del producto. Por otro lado, se tiene que pensar continuamente en 1 Lic. en Estadística de la Universidad San Martín de Porres. Maestría en Ciencias de la Computación por la Universidad de Chile. Magíster en Ingeniería de Sistemas con Mención en Ingeniería de Software por la Universidad Nacional de San Agustín. Es Director de la Carrera de Ingeniería Informática de la Universidad La Salle. Correspondencia a phuertas@ulasalle.edu.pe -67-

2 una mejora de procesos para proporcionar bene cios a la organización, como por ejemplo, reducción de costos, incremento de la productividad, mejora de la calidad, satisfacción del cliente y, lo más importante, lograr un mayor nivel competitivo (Pressman, 2005; Sommerville, 2005). Sin embargo, los proyectos de mejora de procesos requieren de un gran esfuerzo humano, son largos en su ejecución y, por consiguiente, muy costosos (Pressman, 2005). Estos proyectos son críticos para la organización que los aborda, puesto que implican un cambio en su proceso de producción, con el n de lograr una mayor productividad y calidad de los productos que elaboran (Sommerville, 2005). Actualmente, se puede decir que la de nición de procesos está en un nivel poco maduro (Medina, 2010). Por consiguiente, la tarea de de nir procesos es difícil y costosa puesto que cada vez que se aborda la de nición de un nuevo proceso se parte de cero. Por otro lado, el despliegue de los procesos de nidos, constituye la tarea más desa ante a la que una organización se enfrenta (Medina, 2010). Una posible solución a este problema es elaborar una técnica que permita reutilizar los artefactos de proyectos de software en nuevos proyectos de desarrollo de software, basados en la experiencia de las personas que han hecho posible las construcciones pasadas. La elaboración y nalización de los proyectos de desarrollo de software ha generado una documentación histórica muy importante sobre cómo se han llevado a cabo sus procesos y de cómo han ido cambiando las versiones del producto. Antecedentes Medina (2010) menciona que emprender una mejora de procesos bene cia a la organización llevando a cabo un incremento de la productividad y la calidad. Para que esto ocurra, es necesario de un gran esfuerzo humano y de una gran paciencia para lograr los objetivos trazados. Mani esta que actualmente la de nición de procesos se encuentra poco madura y es por eso que plantea, de manera práctica, la formalización de la de nición y el despliegue del proceso. Su solución la orienta a la reutilización de los activos de procesos en nuevos proyectos y en donde propone el encapsulamiento del conocimiento, una estrategia corporativa para desplegar los procesos en toda la organización y una plataforma colaborativa para resolver el problema del equipo de trabajo. Gómez (2010) indica el auge que ha adquirido la ingeniería de software en los últimos años, otorgando especial atención a los procesos de desarrollo basándose en la idea de la calidad del producto la cual está relacionada directamente con la construcción del mismo. Ros (2009) presenta una propuesta de ingeniería de requisitos para líneas de productos que integra -68-

3 modelos de análisis del dominio y requisitos en lenguaje natural. Su propuesta se construye bajo tres esquemas claramente diferenciados: la reutilización de requisitos textuales (en donde incluye un modelo de procesos y una herramienta que lleva a cabo la integración); una descripción del modelamiento de la línea del producto; y, nalmente, el interés por la integración de modelos de ingeniería de software con especi caciones de requisitos en lenguaje natural. Ingeniería de Software La Ingeniería de Software es una disciplina que concierne a todos los aspectos de la producción de software que requiere un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción de ne el alcance del proyecto y desarrolla un caso de negocio. La elaboración de ne un plan del proyecto, especi ca las características y fundamenta la arquitectura. La construcción crea el producto y la transición trans ere el producto a los usuarios (Pressman, 2005). Actualmente se encuentra en una etapa de madurez el enfoque OO (Object oriented - Orientado a Objetos) como paradigma del desarrollo de sistemas de información. El OMG (Object Management Group, es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO). El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especi caciones entorno a la tecnología OO. Una de las especi caciones más importantes es la adopción en 1998 el Lenguaje de Modelado Uni cado o UML (del inglés Uni ed Modeling Language) como un estándar, que junto con el Proceso Uni cado están consolidando la tecnología OO (Pressman, 2005). Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería tradicional en la naturaleza lógica del producto software. Recordemos que el software se desarrolla, no se fabrica en un sentido clásico. En todos los proyectos de ingeniería la buena calidad se adquiere mediante un buen diseño, pero en el caso del software, la etapa de construcción incide pobremente en su calidad, no así en la construcción de hardware o de una obra civil. Así, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricación (Sommerville, 2005; Bedini, 2005; Palacio & Ruata, 2011). La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de -69-

4 software fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. La gestión se puede resumir en las etapas que más adelante se detallarán y que se sustentan en los trabajos de Sommerville (2005) y Palacio y Ruata (2011). Técnica Propuesta Para llevar a cabo el desarrollo de la técnica, se analiza primero el artefacto original, y todo su versionamiento, y a partir de este se construirá el procedimiento para llevar a cabo la reutilización del mismo. Los artefactos presentados se exponen de manera independiente y la información contenida ayudará a proporcionar los elementos de juicio para lograr entender cuáles son los elementos a reutilizar, dentro del artefacto de software, para futuras aplicaciones. En la reutilización del artefacto y la concepción de la técnica, se contemplan tres casos: software con educciones similares, software con educciones diferentes y software con educciones medianamente similares. El software con educciones similares implica que son productos iguales y que sus necesidades son ligeramente diferentes. El software con educciones diferentes implica que los productos a construir son diferentes. Finalmente, se toca el tema del software con educciones medianamente similares, el cual implica la existencia de dos productos parecidos con una cantidad de artefactos parecidos. Etapa de análisis del sistema Educción, elicitación y especi cación de requerimientos La ingeniería de requerimientos se lleva a cabo con el artefacto denominado Documento de Educción de Requerimientos, el cual consiste en un conjunto de tablas que permiten recoger el conocimiento inicial del producto a construir. En ella se traduce las expectativas del cliente con respecto al producto a desarrollar. El procedimiento para la reutilización es el siguiente: 1. Marcar en rojo toda la plantilla de requerimientos. 2. Agregar, con color negro, los conceptos que se inserten en el nombre del requerimiento hasta formar el requerimiento deseado. Si los conceptos coinciden, reutilizar el 100% del concepto que se encuentra en la plantilla. -70-

5 3. Eliminar el nombre del antiguo autor e insertar el nuevo. Si el autor es el mismo reutilizar el 100% del mismo. 4. Eliminar el nombre de la fuente e insertar el nombre de la nueva fuente. Si la fuente es la misma reutilizar el 100% del campo de la plantilla. 5. Agregar, con color negro, los conceptos de la nueva descripción utilizando los que se encuentran en la plantilla. Si el caso es el mismo reutilizar el 100% del campo de la plantilla. 6. Agregar, en color negro, los conceptos para el nuevo comentario utilizando aquellos que se encuentran en la plantilla. Si el caso es el mismo, reutilizar el 100% del campo de la plantilla. 7. Contabilizar la cantidad de cambios para formar el índice correspondiente. Casos esenciales de uso Los casos esenciales de uso se llevan a cabo con el artefacto denominado Documento de Análisis, el cual consiste en un conjunto de tablas que permiten recoger el conocimiento inicial del modelo del negocio visto por el analista de sistemas. En ella se traduce las expectativas del analista de sistema con respecto al modelo de negocio elicitado. El procedimiento para la reutilización es el siguiente: Se identi can los campos comunes y luego se lleva a cabo lo especi cado en el numeral A para casos de uso. Diagramas de casos esenciales de uso El diagrama de casos esenciales de uso se lleva a cabo con el artefacto denominado Documento de Análisis, el cual consiste en un conjunto de casos de uso que permiten recoger el modelo conceptual, en su etapa inicial, del modelo del negocio visto por el analista de sistemas. En ella se traduce las expectativas del analista de sistema con respecto a la modularización del sistema a construir. El procedimiento de reutilización, para los tres casos previstos, es el siguiente: Ambigüedades surgidas por la aplicación de la descomposición Cuando la estructura de los casos de uso se ve re ejada directamente en el código, de modo que el diseño de los casos de uso del sistema se parece a los -71-

6 casos de uso del usuario. Un síntoma común es encontrar al comportamiento de los objetos manipulando datos: esto es poco más que una estructura de datos encapsulada. Este tipo de diseño ayuda a perder la mayor parte de los bene cios y características de los objetos. El sistema duplica el comportamiento a través de los distintos controladores y el conocimiento de esta estructura de datos también es conocido por los demás controladores. La esencia del problema es que la descomposición funcional nos anima a pensar en el contexto de un comportamiento de alto nivel. Ambigüedades surgidas por el abuso de la abstracción Los objetos nacen de la abstracción. Un buen diseño es aquel que se basa en las abstracciones simples, haciendo de un problema complejo algo manejable. Así como los diseñadores utilizan la abstracción, otros integrantes del equipo de desarrollo de software también la pueden usar. Pero la abstracción puede llevar a problemas en los casos de uso. Comúnmente, los usuarios entienden los casos de uso, al principio, y posteriormente, se sienten perdidos con los casos de uso más abstractos. Ambigüedades surgidas por el uso de las interfaces grá cas del usuario Con todas las herramientas para diseñar interfaces grá cas de usuario que existen en estos días, muchos desarrolladores las están usando para ayudar a determinar los casos de uso. Esta lógica es atractiva. Una interfaz grá ca de usuario es concreta a un usuario, nos ayuda a no olvidar detalles; da al usuario una sensación de cómo se verá el sistema. Las interfaces grá cas de usuario son fáciles de prototipar ya que hacen demostraciones razonables para explicar la capacidad del futuro sistema. Al mostrar un prototipo de una interfaz grá ca de usuario a un usuario, parece que casi todo lo hace, y que lo único que queda son pocos detalles detrás de las escenas. Ambigüedades surgidas por el uso de plantillas de otros proyectos de desarrollo de software En muchas ocasiones insertamos, en el proyecto actual, plantillas de casos de uso de otros proyectos llevados a cabo. El problema con estos casos de uso es que no abordan directamente las necesidades de un usuario. Las necesidades reales del usuario son algo así como garantizar un formato consistente dentro de un documento. El problema con ir directamente al caso de uso del sistema es que se le niega la oportunidad de llegar a los casos de uso de otro sistema que se ocupe de lo mismo. -72-

7 Ambigüedades surgidas por el mal diseño de los casos de uso Cuando se plani ca la construcción de un sistema automatizado se prevé que los artefactos generados en las etapas iniciales sean los adecuados para la etapa de diseño. El defecto de los casos de uso, para esta etapa, implica que no existen los mecanismos adecuados para lograr determinar los comportamientos generales o especializados haciendo que el actor, relacionado con el caso de uso, viaje a través de la generalización y la especialización del caso de uso correspondiente. Ambigüedades surgidas por la arquitectura Otro problema importante corresponde a la arquitectura del sistema que puede dar lugar a una mala interpretación de los casos de uso. Esto, debido a la mala interpretación que se lleva a cabo con respecto a la arquitectura del software. Dichas arquitecturas, típicamente, exhiben encapsulación pobre y de acoplamiento excesivo, y una inadecuada distribución de la inteligencia de la demanda entre las clases. Ambigüedades surgidas por los escenarios Esta ambigüedad surge por la poca claridad que existe entre el concepto de caso de uso y escenario. Ambigüedades surgidas por la educción de requerimientos Esta es la primera etapa de la ingeniería de requerimientos. En ella se toma contacto con el cliente para empezar a entender el problema que se tiene que resolver. Generalmente, los clientes no entienden de computación o informática y proporcionan sus ideas de manera desordenada pensando que el ingeniero de sistemas puede entenderlas a cabalidad. Ambigüedades surgidas por la elicitación de requerimientos Esta es la segunda etapa de la ingeniería de requerimientos. El ingeniero de sistemas tiene en mente toda la problemática del problema a resolver; incluso se arriesga a representar el problema con los primeros casos de uso. Después de varias iteraciones concibe el documento de elicitación de requerimientos. A partir de este artefacto se diseñan los casos de uso posteriores. Las fallas de redacción, ortografía, sintaxis y semántica conllevan a una mala interpretación de los casos de uso. -73-

8 Modelamiento conceptual El modelamiento conceptual (que se lleva a cabo con el artefacto denominado Documento de Análisis), consiste en un conjunto de entidades que permiten recoger el conocimiento más estructurado del producto a construir. En ella se traduce las primeras expectativas del diseñador del sistema con respecto al modelo de negocio. El procedimiento para la reutilización es el siguiente: 1. Identi car todas las entidades comunes con la concepción del nuevo sistema y reutilizarlos si es necesario, caso contrario agregar las nuevas entidades representativas. 2. Eliminar las entidades que no corresponden a la construcción del nuevo sistema. 3. Identi car las relaciones comunes y dejarlas en el grá co correspondiente, caso contrario eliminarlas. 4. Versionar el nuevo documento. 5. Llevar a cabo la métrica de contabilización de elementos. Diagramas de secuencias El diagrama de secuencias, que se lleva a cabo con el artefacto denominado Documento de Análisis, tiene que ver con la forma en que responde el sistema cuando el usuario lo ejecuta y lo usa para sus necesidades. En ella se traduce las primeras expectativas del diseñador del sistema con respecto al punto de vista de la construcción del código fuente. El procedimiento para la reutilización es el siguiente: 1. Identi car los mensajes que el usuario le proporciona al sistema, si estos coinciden reutilizarlo al 100%, caso contrario agregar, en color diferente, los nuevos mensajes del sistema. 2. Identi car las respuestas del sistema, si estas coinciden reutilizar al 100%, caso contrario insertar las nuevas respuestas del sistema. 3. Eliminar los mensajes y respuestas que no corresponden al modelo de negocio del nuevo sistema a construir. -74-

9 4. Contabilizar los cambios. Etapa de diseño del sistema Casos reales de uso Los casos reales de uso se llevan a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un lenguaje mucho más formal y orientado a los desarrolladores del producto. Es la primera forma de migrar al código fuente. En ella se traduce las primeras expectativas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software. Su reutilización es similar al de los casos de uso esenciales. Interfaces de usuario Las interfaces de usuario se llevan a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un lenguaje básico las funcionalidades del sistema a emplear por parte del usuario nal. En ella se traduce las primeras expectativas del usuario nal por entender cómo el sistema solucionará sus problemas; además de brindarle un espectro nal de todo el sistema mandado a construir. El procedimiento para la reutilización en cada uno de las interfaces de usuario es el siguiente: 1. Llevar a cabo el análisis de componentes de cada uno de las interfaces de usuario. Si el objetivo es similar entonces reutilizar el componente; luego analizar el contenido del componente para saber si los ítems son los mismos a considerar. Si esto es verdad, reutilizar todo el componente y su contenido, caso contrario agregar los nuevos conceptos al contenido del componente. 2. Llevar a cabo un análisis, dentro de la pantalla, de la posición donde se encuentra el componente. Si la posición es correcta, tomarla como tal, caso contrario desplazar a la nueva posición. 3. Llevar a cabo un análisis de la densidad de la interfaz de usuario. Si la densidad es alta, siete más menos dos objetos, diseñar una nueva interfaz de usuario reutilizando aquellos elementos que son necesarios. Insertarlos dentro del modelo de navegabilidad correspondiente. 4. Contabilizar las métricas correspondientes. -75-

10 Modelo de navegabilidad El modelo de navegabilidad se lleva a cabo con el artefacto denominado Documento de Diseño, el cual consiste en expresar, mediante un diagrama de precedencias, la forma como aparecerán o desaparecerán las interfaces de usuario a medida que los use el usuario nal. En ella se traduce el recorrido que llevarán a cabo las expectativas del usuario nal por solucionar los problemas de la organización que están re ejados en el sistema computacional. El procedimiento para la reutilización es el siguiente: 1. Analizar el modelo de navegabilidad original comparando con el nuevo modelo propuesto. 2. Si existen componentes comunes, reutilizarlos; caso contrario confeccionar uno nuevo para luego insertarlo en el nuevo modelo. 3. Contabilizar los cambios efectuados. Diagrama de diseño de clases El diagrama de clases se lleva a cabo con el artefacto denominado Documento de Análisis, el cual consiste en expresar, en un conjunto de entidades, la forma de nitiva de las relaciones y asociaciones de los objetos en el sistema a construir. En ella se traduce las expectativas de nitivas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software y elicitación de requerimientos. El procedimiento para la reutilización, en los tres casos contemplados, es el siguiente: cuando se hace el análisis y diseño de sistemas y se emplea la herencia, encontraremos algunas ambigüedades tanto en herencia simple, como en herencia múltiple. La herencia simple presenta una debilidad en la clase base. La clase base de la cual se va a heredar desconoce la cantidad de hijos que tendrá por consiguiente cualquier cambio realizado en dicha clase podría ocasionar problemas sobre todo en aplicaciones que usan un gran número de clases. En este caso diremos que la clase base es una clase débil. Esquema de las bases de datos El esquema de las bases de datos se lleva a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un conjunto de entidades, la forma de nitiva de las relaciones y asociaciones de los objetos en el sistema a construir en forma física. En ella se traduce las -76-

11 expectativas de nitivas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software y elicitación de requerimientos con respecto a las consultas del usuario al sistema. El procedimiento para la reutilización es el siguiente: 1. Llevar a cabo un análisis de las entidades participantes, si estas son necesarias reutilizarlos, caso contrario eliminarlas e insertar nuevas entidades. 2. Si la entidad es reutilizada, analizar las claves primarias. Si estas son necesarias, reutilizarlos; caso contrario eliminar la antigua e insertar la nueva clave primaria. 3. Si la entidad es reutilizada, analizar las claves secundarias. Si estas son necesarias, reutilizarlos; caso contrario eliminar la antigua e insertar la nueva clave secundaria. 4. Llevar a cabo un análisis de la cardinalidad de las relaciones, si coincide, reutilizarlo; caso contrario eliminar la antigua e insertar el nuevo concepto. 5. Analizar las relaciones en forma general para entender que las conectividades tienen lógica. Si coinciden reutilizarlos; caso contrario insertar las nuevas asociaciones. 6. Llevar a cabo las métricas del caso. Conclusiones La técnica propuesta nos permite reutilizar, eliminar e insertar componentes nuevos sobre el producto destino, logrando así reutilizar los activos de la documentación histórica del producto de software desarrollado. Se propone, encaminar la reutilización bajo un conjunto de patrones según las fases de construcción del producto. Así, de nir el patrón educción de requerimientos nos permite encaminar el modelo de negocio de manera clara permitiendo una reutilización con mayor análisis de criterio. Las fases de construcción proporcionan patrones de trabajo muy orientados a lo que se desea reutilizar. La estrategia de representación se encuentra basada en separar claramente la especi cación del artefacto a reutilizar, en el proyecto origen, de la -77-

12 implementación del mismo en el proyecto destino. Si el producto inicial tuvo un modelamiento de calidad, el producto destino también lo tendrá. Estadísticamente se demuestra que la mayoría de los artefactos reutilizados o que se reutilizan son más del 94% de sus componentes. Referencias Bedini, A. (2005).Gestión de proyectos de software. Chile: Universidad Santa María Gómez, A. (2010). Metamodelado de procesos de desarrollo software y sistemas multiagente. Tesis para optar el grado de doctor con mención en doctorado europeo. Universidad de Vigo. España. Medina, F. (2010). Marco metodológico para la mejora de la e ciencia de uso de los procesos software. Tesis para optar el grado de doctor. Universidad Carlos III de Madrid. España. Palacio, J. & Ruata, C. (2011). Scrum Manager Gestión de Proyectos. s.l.e.: Safe Creative. Pressman, R. (2005). Ingeniería del software: Un enfoque práctico. 6ta ed. México: McGraw Hill. Ros, J. (2009). Una propuesta de gestión integrada de modelos y requisitos en líneas de productos software. Tesis para optar el grado de doctor. Universidad de Murcia. España. Sommerville, I. (2005). Ingeniería del Software. 7ma ed. México: Prentice Hall. -78-