Architecture and Design Recovery
Ideally, a software project commences with requirements gathering and specification, reaches its major milestone with system implementation and delivery, and then continues, possibly indefinitely, into an operation and maintenance phase. The software system's architecture is in many ways the linchpin of this process: it is supposed to be an effective reification of the system's requirements and to be faithfully reflected in the system's implementation. Furthermore, the architecture is meant to guide system evolution, while also being updated in the process. However, in reality developers frequently deviate from the architecture, causing architectural erosion, a phenomenon in which the initial architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold.
Our research addresses this problem of architectural erosion Our approach assumes that a given system's implementation is available, while the architecturally-relevant information either does not exist, is incomplete, or is unreliable. We use techniques for architectural recovery from system implementations; we then leverage architectural styles to identify and reconcile any mismatches between the existing and recovered architectural models.
Relevant Publications
- Improving System Understanding via Interactive, Tailorable Source Code Analysis
- Stemming Architectural Erosion by Coupling Architectural Discovery and Recovery
- Automated Abstraction of Class Diagrams
- Compositional and Relational Reasoning During Class Abstraction
Related Research
| Consistency Checking of Models |
| Software Model Traceability |
| Model Transformation |
| Requirements to Architecture |
| Software Architecture and UML |