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 The same term may be described many times across different projects.

o At the program level, links from elements of the code to domain concepts

are non-existent. Such links would facilitate the process of

comprehension.

These semantics also play a critical role in the evolution of a software system.

While technologies such as ebXML attempt to address the semantics problem at a

superficial level, little attention has been given to:

o Specification of ontologies including concepts and their relationships/

mappings.





Reference

SEI website with all the software

architecture definitions

o Capture of semantics during requirements engineering, and linking it to a

core ontology.

o Semantic mining paradigms, in which terms are translated and matched.

1.3 Architecture Centric Software Evolution

The Software Architecture Evolution Group at the University of Limerick envisages an

architecture centric, software evolution process in line with the �architecture-centric’

tenet of CBSE. In this vision components are added, removed and replaced in a software

architecture either statically or dynamically, in line with, and explicitly linked to, altered

business