![](bg2.png)
substantial pre-investment in hardware and software
that may be many years old” (O’Callaghan, 2000).
Sooner or later, legacy systems must be taken off
because their architectural constitution will make
their adaptation very costly and difficult. However,
since those systems have an important role for the
organization, we need to provide a framework to let
them work while we gradually replace them.
An architect must have a wide vision to model
systems that will grow up along with user’s
requirements. System qualities are part of
stakeholders’ requirements and they are in a
continuous evolution too. A lot of systems lack of a
good design because they has been built to
accomplish only a set of initial requirements.
As time passes by, users will require more
functionalities and communication capacities from
the system. Also, as the computational environment
grows, it becomes more complex, so we need to
increase governability and usability in each system.
When we add new capacities to a system, we
provoke an evolution on it. The system is adapted to
new circumstances and requirements by applying
maintenance. Maintenance adds complexity to the
system, so later adaptations will be harder and more
expensive to do.
Software reengineering is used to reduce
complexity and to increase evolution capacity of a
system by refactoring software code; but, it doesn’t
help to change its architecture or functionality
(Sommerville, 2004). This strategy is associated
with some kind of preventive or perfective
maintenance; it’s a costly and difficult evolution
strategy (Pressman, 2004).
Re-engineering of legacy systems will not
always be possible because of different factors such
as absence of source code, lack of tools to recompile
it, lack of skills and knowledge to do it, etc.
A similar situation applies to interoperability.
Many systems have been designed to work
separately, so their communication capacity is very
limited. Systems that aren’t prepared to interoperate
must incorporate complex and inefficient
mechanisms to exchange information.
We add interaction capacities to exchange
information and functionality between independent
systems in a more effective way.
Integration adds an additional coordination
element to interaction. In this case a system takes
partial or total control over functionality and
information of other systems. System integration can
bring us various benefits such as reduction of
software complexity, increment of systems
governance and establishment of a framework for
evolution of the computational environment.
System integration is a way to simplify a
computing environment. This strategy helps to
improve software qualities like: efficiency,
governability, maintainability and usability.
To achieve an extensive capacity of interaction,
integration and evolution of systems using any
available technology requires models to support the
design of software architectures.
If we don´t have a good architectural design
since the beginning, we will need to change the core
structure of the system to add or expand functional
and non-functional characteristics in critical systems
that cannot be replaced in a short time. This is a
difficult task because software architects will find
complex structures, different programming styles,
ignorance and lack of documentation of how the
whole system works, among other problems.
With architectural models we can share
conceptual rules to develop new patterns that will
help to make easier the task of designing and
redesigning software systems.
Creation of reference architectural models to
facilitate designing efforts will require establishing a
practical method for identifying generic architectural
elements in existing systems to develop decision
rules and to decide which will be the best suited
model under certain conditions.
3 BACKGROUND AND RELATED
WORK
Evolution is required to maintain systems operating
in a changing environment. Robertson applies
Dynamic Object Oriented Programming, specific
domain programming languages and reflection to
change system’s behaviour at runtime (Robertson,
1997). He also says that connecting legacy systems
helps to replace them by doing parallel deployments.
In the work of Ziegler and Dittrich (Ziegler &
Dittrich, 2004) we can find a set of approaches that
have been used to integrate information from
different systems; such as: common user interfaces,
applications, middleware, global views of data,
common data storage, and so on. This work makes
special emphasis on the need for adequacy of
semantics, which certainly is a problem to be solved
because we need to establish a comprehensive way
to integrate components into an architectural model
that will carry out contextualization tasks, a topic
that is not addressed in that document.
Architectural integration of large systems has
been studied by Garland and Antony (Garland &
Antony, 2003). They recommend two strategies, one
MODELS FOR INTERACTION, INTEGRATION AND EVOLUTION OF PRE-EXISTENT SYSTEMS AT
ARCHITECTURAL LEVEL
221