Categoría: Software Engineering

El mantenimiento de software es una subárea importante de la ingeniería de software. Las investigaciones en esta área han producido muchos descubrimientos sorprendentes que se están utilizando en la industria del software. No solo en la industria del software, sino también en muchas aplicaciones web optimizadas para SEO (a través de proveedores como spamzilla.io) hacen uso de esta área de la ingeniería de software. ¿Por qué la parte de mantenimiento es tan importante y tan difícil? Puede haber un montón de respuestas para esta pregunta, como problema de análisis de requisitos, problema de diseño, estilo de programación de cada programador, etc.

De hecho, juntos contribuyen a esta cuestión. Sin embargo, desde un alto nivel de vista, son los errores los que contribuyen a la gran carga de mantenimiento. Si un sistema tiene un análisis de requisitos correcto (lo cual es imposible), un diseño correcto y todos hacen su parte siguiendo las normas / reglas / convenciones, el problema de mantenimiento se reducirá significativamente. ¿Pero cómo?

Lo que estoy pensando es hacer que los sistemas se generen automáticamente. Una descripción simple de la idea es la siguiente.

Haga un diagrama / diagramas que resuman la funcionalidad del sistema, luego ingrese el diagrama a un generador de sistema automático. Después de eso, el sistema se construye con estándar y conversiones.

Si esto se puede hacer y alcanzar un nivel feliz, la importancia del análisis de software puede disminuir. Lo mismo ocurre con otras áreas relacionadas con el mantenimiento de software.

Desde la primera vez que pensé en esta idea, supe que esto puede resultar extremadamente difícil. Pero como enfoque normal para resolver problemas enormes y difíciles, esto se puede dividir en varios problemas menores diferentes. He aquí algunos de ellos en mi mente.

• Abstracción del flujo de trabajo empresarial.
• Un diagrama para representar la abstracción anterior.
• Un nuevo lenguaje que puede representar el diagrama.
• Un traductor para traducir el idioma al modelo de negocio.
• Módulo de generación de código para cada función o modularidad específica, como conexión de base de datos / upadte, interfaz de usuario, etc.
• Un enfoque para convertir un modelo de negocio específico en código, por cada módulo de generación de código.

Esta es solo una idea cruda mía. ¿Es demasiado optimista? Creo que sí. De todos modos, una de las diferencias entre la industria y la academia es optimista. La investigación es exploración, lo que no puede garantizar un resultado determinado. Examinaré cada pequeño problema y veré si hay algún área interesante para mi investigación.

Hare es una lista de las mejores conferencias en el área de investigación de Ingeniería de Software. La investigación en ingeniería de software es muy creativa. Como característica del software, los investigadores pueden crear cualquier software de innovación siempre que ayude al desarrollo de software de alguna manera.

• ASE – Conferencia internacional sobre ingeniería de software automatizada
• ICSE – Congreso Internacional de Ingeniería de Software
• ESEC / FSE
• OOPSLA
• ICSM – Conferencia internacional sobre mantenimiento de software
• WCRE – Conferencia de trabajo de IEEE sobre ingeniería inversa
• ECOOP – Conferencia europea sobre programación orientada a objetos
• ISSTA – Simposio internacional sobre análisis y pruebas de software
• AP-SEPG – Conferencia del Grupo de Procesos de Ingeniería de Software de Asia-Pacífico

Algunas investigaciones de ingeniería de software requieren evaluación humana. A diferencia del programa que usted tiene bajo su control, los factores humanos a veces están fuera de su control. Para asegurarse de que la evaluación vaya bien, se debe hacer lo siguiente:

1. Tenga algunos evaluadores de respaldo en caso de que alguien no pueda completar a tiempo. Incluso la evaluación es muy importante, es posible que algunas personas no la tomen en serio o la olviden.

2. Asegúrate de la calidad de los evaluadores, no de la cantidad. Para garantizar la calidad, preparar una tarjeta regalo no es una mala idea.

Aquí hay algunas investigaciones sobre el asistente de código realizadas en el área de investigación de ingeniería de software. Esos temas son bastante comunes y mucha gente ha desarrollado varios tipos de herramientas.

1. Directivas de subclasificación mineras para mejorar la reutilización del marco.
Idea: ingeniería inversa a partir del código específico de la aplicación, la documentación de cómo usar un artefacto de software en particular se puede inferir de cómo se usa realmente.
Proponer cuatro tipos diferentes de directivas de subclasificación
Subclasificación del marco de mina a partir del código del cliente

2. Thex: Minería de metapatrones de Java
El metapatrón es más fácil de detectar. El patrón de diseño de diferencia puede compartir un modelo de metapatrón subyacente común. Por ejemplo, estado y estrategia.
Se presentaron cuatro formas de metapatrones, basados ​​en la relación entre GANCHO y PLANTILLA.

3. Micropatrones en código Java

4. Asignación de API de minería para la migración de idiomas
Encuentre el mapeo entre dos versiones diferentes de la aplicación.
usar código de cliente

5. Patrones de API de minería como pedidos parciales del código fuente: desde escenarios de uso hasta especificaciones

6. Cartera: encontrar funciones relevantes y sus usos

7. XSnippet: Minería para código de muestra

Diagrama vale (a veces) diez mil palabras.

Durante la etapa de inicio de mi investigación, estoy tratando de comprender mejor el estado del arte en el área de ingeniería de software. El siguiente diagrama es el primero de esta serie. Contiene los temas de investigación básica en el área de mantenimiento / evolución de software de la ingeniería de software. Para comprender mejor cada tema pequeño de este diagrama, también dibujaré un diagrama de jerarquía en cada tema pequeño para descubrir el trabajo relacionado, los enfoques de investigación, etc.

Dirección de descarga: http://www.programcreek.com/wp-content/uploads/2011/07/Software_Engineering_research_areas.jpg

Los informes de errores son artefactos que rastrean los defectos de los sistemas de software. En el área de investigación de mantenimiento de software, ha habido un montón de trabajo de investigación que aborda el problema de los informes de errores en los últimos años.

Bugzilla es uno de los sistemas de informes de errores más populares. En aras de su popularidad y su función de código abierto, Bugzilla proporciona en gran medida los datos para la investigación.

El siguiente diagrama muestra las principales categorías de trabajo en esta área. La esquina inferior izquierda es un informe de error de muestra de Bugzilla.

La investigación anterior se ha centrado principalmente en detectar duplicados, categorizar informes de errores, estudios estadísticos e intentar generar un resumen para los informes de errores.

Las técnicas que se utilizan están relacionadas principalmente con el proceso del lenguaje natural. La técnica de ingeniería de software no se ha utilizado mucho, como la creación de relaciones entre los informes de errores y el código, entre los informes de errores y el diseño / seguridad, etc.

La indexación semántica latente (LSI) es una técnica común en el área de procesamiento del lenguaje natural. Este artículo trata sobre cómo funciona LSI comparando la búsqueda pura basada en palabras clave.

¿Qué es LSI?

La indexación semántica latente (LSI) es un método de indexación y recuperación que utiliza una técnica matemática llamada Descomposición de valores singulares (SVD) identificar patrones en las relaciones entre los términos y conceptos contenidos en una colección de texto no estructurado. LSI se basa en el principio de que las palabras que se utilizan en los mismos contextos tienden a tener significados similares. – wiki

Por ejemplo, Paris y Hilton están asociados con una mujer en lugar de una ciudad y un hotel, Tiger y Woods están asociados con el golf.

Búsqueda de palabras clave normal frente a LSI

Al utilizar la búsqueda normal de palabras clave, un documento contiene la palabra dada o no, y no hay término medio.

LSI agrega un paso importante al proceso de indexación de documentos. LSI examina una colección de documentos para ver qué documentos contienen algunas de esas mismas palabras. LSI considera que los documentos que tienen muchas palabras en común son semánticamente cercanos y los que tienen menos palabras en común son menos cercanos.

Cuando busca en una base de datos indexada por LSI, el motor de búsqueda observa los valores de similitud que ha calculado para cada palabra de contenido y devuelve los documentos que cree que se ajustan mejor a la consulta. Debido a que dos documentos pueden ser semánticamente muy cercanos incluso si no comparten una palabra clave en particular, LSI no requiere una coincidencia exacta para devolver resultados útiles. Cuando una búsqueda de palabra clave simple fallará si no hay una coincidencia exacta, LSI a menudo devolverá documentos relevantes que no contienen la palabra clave en absoluto.

Un ejemplo de LSI

Si usamos LSI para indexar una colección de artículos y las palabras “programa” y “código” aparecen juntas con suficiente frecuencia, el algoritmo de búsqueda notará que los dos términos son semánticamente cercanos. Por lo tanto, una búsqueda de «programa» devolverá un conjunto de artículos que contienen esa frase, pero también artículos que contienen solo la palabra «código». LSI no comprende la palabra distancia, pero al examinar una cantidad suficiente de documentos, sabe que los dos términos están relacionados. A continuación, utiliza esa información para proporcionar un conjunto ampliado de resultados con un mejor recuerdo que una simple búsqueda de palabras clave.

El siguiente diagrama describe el efecto entre LSI y la búsqueda por palabra clave. W significa documento.

Referencia:

1. seobook
2. conceptos erróneos

Alguien dice que el lenguaje de programación también es un lenguaje. Esto es verdad.

Más allá de esto, durante el ciclo de vida de un desarrollo de software, se agregan diferentes tipos de lenguajes naturales para diversos propósitos, como análisis de requisitos, comentarios, informes de errores, etc. El área de ingeniería de software se ha realizado mediante el uso de técnicas de procesamiento del lenguaje natural.

Las técnicas de PNL incluyen, entre otras, las siguientes:

• sistema de preguntas / respuestas
• análisis de sintaxis
• modelo n-gram
• resumen
• comprensión del texto y representación del conocimiento

Mi investigación será algo que combine SE y PNL con seguridad. La cuestión incierta es cuál es el problema exacto que abordaré.

Así que tenemos soluciones para cada problema / tema general. ¿Podemos encontrar soluciones alternativas para abordar el mismo problema?

El enredo de código y la dispersión de código impactan el software de muchas maneras:

1. Escasa trazabilidad: la implementación simultánea de varias preocupaciones dificulta el rastreo de los requisitos hasta la implementación.

2. Menor productividad: la implementación simultánea de múltiples preocupaciones cambia el enfoque de la preocupación principal a las preocupaciones periféricas. El acoplamiento alto conduce a una menor productividad. Además, las diferentes preocupaciones implementadas en un módulo requieren diferentes habilidades para manejar el módulo.

3. Menor reutilización de código: no es difícil de entender, ya que un módulo implementa múltiples preocupaciones.

4. Calificación deficiente: el código enredado hace que sea difícil examinar el código y encontrar problemas.

5. Evolución difícil: debido a los cuatro problemas anteriores, el software es difícil de mantener.

AOP puede resolver esos problemas separando esas preocupaciones transversales. De hecho, esos problemas existen comúnmente en el software. Aquellos se identifican como problemas. A pesar de que AOP puede resolver esos problemas, no todos los sistemas se pueden aplicar con AOP (según mi entendimiento).

Ahora, la pregunta es: ¿qué otras técnicas se pueden aplicar para hacer lo mismo como AOP?

Para comenzar la investigación de marcos, necesitamos comprender qué es un marco y por qué se crea. Aquí solo nos enfocamos en los frameworks de Java.

Uno de los personajes más importantes de Frameworks que se diferencia de otras bibliotecas regulares se llama «Reversión de control». Cuando escribimos un programa Java, siempre hay un punto de entrada: «public static void main (String[] args) «. Llama a diferentes partes de nuestros proyectos e inicia la funcionalidad del programa. Para algunos tipos de aplicaciones, una gran cantidad de código se escribe una y otra vez, pero de manera desordenada. Framework define las transacciones comunes, por lo que las aplicaciones cliente simplemente completar su propia parte.

La razón por la que el marco es útil es porque estandariza la codificación en algunos escenarios de uso común, como las aplicaciones GUI y WEB. Si usamos una analogía simple diciendo que una aplicación Java es un automóvil. El marco sería el marco del automóvil, como el marco, las 4 ruedas, etc. Una biblioteca sería una bolsa de piezas pequeñas. Puedes cambiar una pequeña parte de un coche, pero no puedes redefinir un marco una vez que eliges el marco de 4 ruedas.

Aparte de los excelentes marcos de conveniencia que brindan, existen muchos problemas al usar esos marcos.

En primer lugar, existe un grave problema de aprendizaje. A partir de las observaciones de innumerables tutoriales de varios tipos de marcos, podemos concluir fácilmente que el aprendizaje no es una tarea trivial. En realidad, cuanto mejor es un marco, más difícil puede resultar.

En segundo lugar, cuando usamos un marco, hay muchos problemas involucrados, depuración, pruebas, uso adecuado, etc.

Los investigadores han identificado algunos problemas notables de los marcos y publican una gran cantidad de trabajo de investigación.

Para entender qué es un marco, aquí está mi publicación anterior sobre el marco.