Software Architecture Evolution Framework

SAEF “Software Architecture Evolution Framework” –

The Vision

1.1 Motivation

In many cases, informal architectural diagrams are available to the personnel who

maintain software systems. However, there is little tool support linking such architectural

descriptions to system requirements and the source code. This can create a number of

problems. For example, inconsistencies can arise between the requirements, the

architectural artefacts and the source code, making the code-base the only trustworthy

representation of the system. Consequently maintainers are forced to adopt a code centric

approach whereby they work with a large, complex and formal representation of the

system.

1.2 Three Facets of Software Architecture Evolution

Typically, software maintenance is performed in a code centric fashion, whereby mental

models of the software architecture are developed by maintenance engineers through

analysis of the code base. In many cases, informal architectural diagrams are available to

facilitate this comprehension but there is no formal support for the capturing of these

mental models. When the system evolves a maintenance engineer’s mental model also

evolves but rarely is the new architecture documented.

The question is how can this information be captured, maintained and presented in such a

way that increases the understanding of a software system and reduces maintenance

effort?

In trying to answer this question our initial research has identified three major areas of

interest concerning the evolution of software systems:



Reference

ArchJava

- Architecture, while the concept of architecture continues to be a source of

considerable debate in the software community, its importance in industry is

widely accepted. Software architecture is an abstraction of the organisation of the

structural elements of a software system. The relationships between structural

elements are governed by collaborations that are mediated through interfaces. The

architecture disciplines the composition of the static and the behavioural elements

into progressively larger subsystems. The advent of Architecture Description

Languages (ADLs) within the academic community provides a structured

framework for the specification of software systems.

- Process,

- Semantics, currently component composition is achieved manually by maintainers

semantically interpreting syntactic types at the interface level. To semi automate

this process would require the system itself to have knowledge of the relationships

between the syntactic types of component interfaces and their associated

semantics. The term Domain Knowledge Engineering has been used to describe

the process of semantic capture and mining. It is often the case that in the absence

of a structured approach to domain knowledge engineering:

o The definitions of many significant domain concepts remain buried in text

based use case descriptions.

o Data dictionaries, when used, are populated with subjective descriptions of

domain terms. Quite often, the same term will have different descriptions

deposited in the dictionary during requirements and analysis.

o