Finding reusable software components in large systems

Neighbors, James M.

doi:10.1109/wcre.1996.558783

Cited by 23 publications

(11 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…En [9] se describe un enfoque para la construcción de componentes reutilizables de grandes sistemas existentes mediante la identificación de los subsistemas estrechamente acopladas contenidos en el sistema. El enfoque se basa principalmente en el uso de métodos informales y experimentales y el objetivo principal era hacer observaciones acerca de las experiencias vividas con algunos sistemas grandes.…”

Section: Trabajos Relacionadosunclassified

Guía para la Reingeniería de Sistemas Legados: Una Experiencia Práctica y Real

Bianchiotti¹,

Casas²

2014

Revista Latinoamericana De Ingenieria De Software

View full text Add to dashboard Cite

Resumen-Este trabajo presenta una experiencia real de reingeniería de sistemas legados. La misma tuvo lugar en la Administración General de Vialidad Provincial (Santa Cruz) y demandó aproximadamente un año de trabajo. El proyecto de reingeniería tuvo dos objetivos muy concretos: a) desarrollar un marco de trabajo de reingeniería que se adecuara a los sistemas legados de la organización con la finalidad de poder ser replicado a otros sistemas legados de la organización. Este objetivo dio por resultado la elaboración de una guía para su posterior reutilización a estos contextos. b) su aplicación a uno de los sistemas legados de la organización. En esta primera instancia se aplicó al sistema de Patrimonio.Palabras Clave-Sistemas legados, reingeniería, migración, mantenimiento. I. INTRODUCCIONPragmáticamente los sistemas legados se han definido como "software que es vital para la organización, pero no se sabe qué hacer con él" [1]. Los sistemas legados son uno de los principales problemas del mantenimiento de software. A pesar que la crisis Y2K forzó a muchas organizaciones a sustituir los sistemas antiguos, existe aún software que supera los 20 años. Se trata de software monolítico, dividido en subsistemas que cumplen funciones importantes para las organizaciones, pero de los cuales no se dispone documentación, los desarrolladores originales ya no trabajan en la organización y solo se dispone de los códigos fuentes e incluso en algunos casos ni siquiera eso.Aunque tecnologías más modernas (aplicaciones clienteservidor, BD relacionales, tecnologías OO / componentes, etc.) suponen mayor facilidad de mantenimiento y además ofrecen mas oportunidades, ocurre que el ciclo de vida de los sistemas se extiende más de lo debido. Sneed [2] afirma que las empresas no invierten recursos en ingeniería inversa o reingeniería a las nuevas tecnologías sobre la base de que los costes de mantenimiento son menores. Sin embargo, en un punto el mantenimiento adaptativo [3] obliga a realizar el mayor esfuerzo y más riesgoso, el desarrollo de un nuevo sistema, la migración de los datos, la recuperación de la lógica de negocios, es decir una reingeniería [4]. Los procesos de reingeniería son complejos, y no existen formulas preestablecidas que se puedan aplicar con éxito a todos los casos, por otro lado conllevan una importante carga de trabajo manual, aún cuando se puedan utilizar herramientas que automaticen ciertas actividades.Este trabajo presenta una experiencia real de reingeniería de sistemas legados. La misma tuvo lugar en la Administración General de Vialidad Provincial (Santa Cruz) y demandó aproximadamente un año de trabajo. El proyecto de reingeniería tuvo dos objetivos muy concretos: a) desarrollar un proceso de reingeniería que se adecuara los sistemas legados de la organización con la finalidad de poder ser replicado a otros sistemas legados de la misma. Este objetivo dio por resultado la elaboración de una guía para su posterior reutilización a estos contextos. b) su aplicación a uno de los sistemas legados de la organizaci...

show abstract

Section: Trabajos Relacionadosunclassified

Guía para la Reingeniería de Sistemas Legados: Una Experiencia Práctica y Real

Bianchiotti¹,

Casas²

2014

Revista Latinoamericana De Ingenieria De Software

View full text Add to dashboard Cite

show abstract

“…Also the complexity of algorithm was cubic which makes it difficult to work on large systems. Neighbours [28] investigated compile-time and link time dependencies among components to identify subsytems with the ultimate goal of extracting reusable components. Anquetil and Lethbridge [3] looked at informal information like names of various entities of the system.…”

Section: Related Workmentioning

confidence: 99%

Probabilistic component identification

Sajnani

Lopes

2014

Proceedings of the 7th India Software Engineering Conference

View full text Add to dashboard Cite

Automatic component identification is an important step for many software engineering tasks and tools, from reverse engineering to program comprehension. Although being a topic of research for a long time, generally applicable solutions remain elusive with very low recall. Most component identification techniques impose structure on the software, therefore requiring substantial knowledge about the software, instead of inferring such structure.We propose PCI, a non-parametric, probabilistic algorithm to the problem of automatic component identification. The proposed approach uses structural, behavioural and lexical features of the software to infer the underlying structure and identify the components. In order to evaluate this approach, multiple experiments are performed on a software system for which components have previously been identified [by others]. The proposed algorithm is compared to two existing algorithms. The experiments measure precision and recall, and attempt to unveil the impact of each source of information on the accuracy of the approach. We find PCI outperforms the others most notably on recall, with improvements that go from 4x to 10x better recall.

show abstract

“…Neighbors' approach [7] was to find the locations of loosely coupled code regions in a system rather than individually extracting the software components. His study was based on a structure-based approach to analyze the existing program's architecture and interconnection data graph.…”

Section: Related Workmentioning

confidence: 99%