Software Architecture Evolution

WOLLO UNIVERSITY

Kombolcha Institute of Technology

COLLEGE OF INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING

Software Evolution and Maintenance ( SEng 5551 )

Group member

Name Id

1. Hailemariyam kebede WOUR/1000/12

2. Abiyot Ashebir WOUR/0128/12
3. Elsabet Bekele WOUR/0681/12
4. Ebisa Tebelu WOUR/0642/12
5. Edilawit Beyene WOUR/0654/12

SUBMITTED TO: Mr. Yibeletal(MSc)

[Type text] Page 1

 Software Architecture Evolution

Contents
Chapter 6 .................................................................................................................................................. 1
Software Architecture Evolution .............................................................................................................. 1
6.1 Introduction ............................................................................................................................. 1
6.2 Component-Based Software Architecture: Concepts and Open Issues ................................... 2
6.2.1 Architecture Specification and Analysis ........................................................................... 2
6.2.2 System Configuration and Code Generation ................................................................... 3
6.2.3 Architecture Centric integrated Development Enviroment ............................................ 4
6.2.4 Evaluation: Managing Software Architecture Evolution ................................................ 5
6.3 Dynamic Software Architecture Description ............................................................................ 6
6.3.1 Explicit Specification of Software Architecture Dynamics .............................................. 6
6.3.2 Evaluation ......................................................................................................................... 7
6.3.3 Frame for Dynamic Software Architecture ...................................................................... 8
6.4 Aspect-Oriented Architectures Description Language ........................................................... 10
6.4.1 Issue................................................................................................................................ 10
6.4.2 Using Aspects in Architectural Description ................................................................... 11
6.4.3 Evaluation ....................................................................................................................... 12
6.5 The Safe Integration of New Concerns in a Software Architecture ....................................... 13
6.5.1 Overview of Tran SAT .................................................................................................... 13
6.5.2 Integrating a Session Expiration Concern using TranSAT framework ........................... 14
6.5.3 Issue................................................................................................................................ 14
6.5.4 A Specific Language for Software Architecture Transformation ................................. 15
6.5.5 Static Verification of Transformation .......................................................................... 17
6.6 Dynamic Verification .............................................................................................................. 18
6.7 Assessment............................................................................................................................. 19
6.8 References .............................................................................................................................. 21

Group 1 Page i
 Software Architecture Evolution

Chapter 6

Software Architecture Evolution

6.1 Introduction

The value of flexible architectures in software development cannot be emphasized, especially

given that needs are always changing. However, when new request emerge from customer.
Traditional architectural description languages frequently lack the features required for smooth
integration. This presents a challenge for architects who must manually adjust various
architectural elements, running the risk of introducing inconsistencies into the system.
The chapter focus into modern approaches to describing and evolving software architectures,
emphasizing the growing significance of software architecture in crafting software-intensive
systems. It highlights how software architecture defines the structure and behavior of the
system while guiding development and integration processes.

When we are discussing the importance of Architecture Description Languages (ADLs) in

software architecture. ADLs help architects define system architecture precisely. However,
many ADLs struggle to support the evolving nature of architectures in response to changing
requirements. Software systems need to adapt dynamically both internally and externally,
which traditional architectures may find challenging, leading to widespread modifications and
potential errors.

Aspect-Oriented Software Development (AOSD) and similar methods address software

complexity but face challenges, highlighting the need for advanced tools to support seamless
integration and evolution of software architectures in response to ever-changing requirements.

Group 1 Page 1
 Software Architecture Evolution

6.2 Component-Based Software Architecture: Concepts and Open Issues

The software architecture of a system defines its structure and behavior at a high level. It
includes software components, their connections, and how they interact behaviorally.
Developing a software architecture enhances system comprehension and aids in the design
process. Architectural Description Language (ADL) is used to describe software architectures.

An Architecture Description Language (ADL) is a tool that simplifies specifying and

analyzing the architecture of a system. It uses readable formats for both humans and machines,
providing a high-level abstraction. ADLs support automatic generation of software system
parts. They consist of component (a computational element with multiple ports, allowing it to
communicate with its environment), connectors (the interaction between components.), and , a
configuration describes how components and connectors are arranged into a system.

In ADL design, three key areas are focused:

 The specification and analysis of the interaction between distributed

components, as illustrated by Darwin and Wright,
 The strong link with the implementation of the software system, as may be
found in Arch Java, Fractal and SOFA
 The building of an architecture-driven software development environment, as
promoted by Arch Studio, Acme Studio and Saf Archie. Finally, we evaluate
these works in terms of their support for evolution.

6.2.1 Architecture Specification and Analysis

Some ADLs focus on the specification and analysis of component interaction include Wright,
Darwin, and Rapid. Wright offers a formal approach for architectural description that is based
on Communicating Sequential Processes (CSP). To boost the architect's confidence in the
system design, it specifies a set of standard consistency and completeness properties based on
this model that can be verified using standard model checking technologies. Where as Darwin

Group 1 Page 2
 Software Architecture Evolution

is a formal language used to describe network topologies and software architecture in dynamic
distributed systems. It specifies the behavior of the system using Finite State Process (FSP)
Languages. A succinct description of Labelled Transition Systems (LTSs) may be found in
FSP.

6.2.2 System Configuration and Code Generation

A common practice in ADLs is to separate the design and the implementation, which might
result in an inconsistent architecture and implementation. The aim of SOFA, Fractal, and
ArchJava is to bring software architecture and implementation together. An extension to Java
called ArchJava focuses on a feature called communication integrity to bring together the
program architecture and the implementation. Because of this characteristic, component
implementations can only communicate across the channels specified in the design. To
guarantee that the implementation code has this attribute, Arch Java employs a type system.

According to the Fractal component model, there are two types of components: composites,
which are merely used as a way to combine components into a whole, and primitives, which
contain actual code. An XML-based ADL with constructs to define component types,
primitive templates, and composite templates is offered by Fractal. An implementation can be
made via a tool that parses a Fractal ADL specification and instantiates the relevant
components. A Java package called Julia is one of the Fractal implementations that makes it
possible to specify and modify components and architectures at runtime. Primitives in Julia
can be regular Java classes that follow certain coding guidelines.

A framework for creating applications with basic and composite software components is
offered by SOFA (Software Appliances). A component's architecture and frame serve as
descriptions. The architecture is an abstract implementation, and the frame is a component
interface. A frame, which can be implemented by multiple architectures, defines the services
that the component provides and needs. By instantiating direct subcomponents and defining
the links between them, a composite's architecture explains the component's structure. A
primitive only has an implementation, which could be binary, and no architecture. Component
Definition Language (CDL), a text-based ADL offered by SOFA, is derived from OMG IDL.

Group 1 Page 3
 Software Architecture Evolution

This ADL allows specifying the communication among SOFA components and embeds a
process algebra called behavior protocols to express the behavior of each component. The
ADLs ArchJava and Fractal provide a tight link between the architecture and the
implementation, but unlike Darwin or Wright do not provide any facilities for behavior
specification and analysis. Indeed, the only check on the interaction between components is to
ensure that connected ports provide and require services with compatible signatures. The
language CDL used with SOFA, however, additionally allows specifying behavior protocols
in terms of regular expressions on sequences of events, which constrains the set of admissible
traces of the component.

6.2.3 Architecture Centric integrated Development Enviroment

Finally, some work has focused on the design of ADLs that are targeted towards use with
architecture-centric software development tools, with the goal of improving the use of
software architecture concepts in the software industry.

Some of these ADLs are

 ArchStudio,
 AcmeStudio,
 SafArchie.

1. Arch Studio

Arch Studio is a software development environment that focuses on software development

from the perspective of software architecture. It supports the C2 architectural style.

A C2 architecture is a hierarchical network of concurrent components linked together by

connectors.. C2 components communicate via message passing. It is extensible, and many
extensions have been developed to analyze, refine, or deploy architecture specifications.

2. Acme Studio

Group 1 Page 4
 Software Architecture Evolution

It is a customizable editing environment and visualization tool for software architectural

designs based on the Acme ADL. Acme is extensible and is intended to be used as a common
interchange format for architecture design tools and as a foundation for developing new
architectural design and analysis tools.

It allows the designer to define new Acme families and customize the environment to work
with those families by defining diagram styles.

3. SafArchie Studio

It provides a hierarchical component model, including primitive and composite components.

Each component interface is associated with a contract. These contracts clarify both the
structure and the external behavior of the components, describing its interactions with its
environment

It allows a designer to describe an architecture and then to check its properties using either a
built-in model checker or the verification tool LTSA. Finally, it can generate code for use with
Arch Java or Fractal.

6.2.4 Evaluation: Managing Software Architecture Evolution

The languages in this section support describing software architecture. Tools can check the
model's correctness and generate code. However, once implemented, changing the architecture
is expensive due to the lack of a management system for evolution. This leads to architectures
quickly becoming outdated and serving only as documentation. These languages cannot
capture the internal dynamics of a system and do not handle external evolutions. For example,
architecture analysis tools lack support for incremental checks when integrating new concerns.
Component-based software platforms suffer from tangled code, making the integration or
modification of new concerns difficult and prone to errors. Architecture development
environments also lack facilities for integrating or modifying crosscutting concerns easily.

Group 1 Page 5
 Software Architecture Evolution

6.3 Dynamic Software Architecture Description

A running system often diverges from its initial architecture due to new components and
interactions. To effectively handle these changes, it is important to document and analyze the
potential alterations that can occur. Two main categories of approaches exist for addressing
system dynamics at the architectural level: explicit specification of all possible evolutions or
defining the space of potential evolutions.

6.3.1 Explicit Specification of Software Architecture Dynamics

A. Wright

The first solution to express the dynamics of a software architecture was an extension of
Wright. This extension utilizes the behavior notation of Wright to model reconfiguration. It
allows architects to view the architecture as a series of architectural snapshots, each with its
own steady-state behavior.

Transitions between these snapshots are represented by reconfiguration-triggering events. To

introduce dynamism in an architecture description, architects must extend the interface of each
component to describe when reconfigurations are allowed in each protocol it participates in.

A reconfiguration view consumes these events to trigger reconfigurations, enabling simulation

of the software architecture's evolution. However, this approach breaks the separation of
concerns principle and is limited to systems with a finite number of configurations.

B. Fractal/FScript

The execution model of Fractal is flexible, allowing for dynamic instantiation of components
and bindings at runtime, as well as changing the configuration of a composite. However, the
Fractal ADL limits the expression of system instantiation to a single instance, defining how
components are connected.

Group 1 Page 6
 Software Architecture Evolution

FScript, on the other hand, enables programmable reconfigurations of Fractal components,

ensuring properties such as termination, atomicity, consistency, and isolation. FScript
programs can be triggered by application events using reactive rules, providing a way to
model system dynamics with Fractal ADL.

C. ArchJava

ArchJava, described before the above lesson enables dynamic instantiation and connection of
statically defined components. Components have a parent component and adhere to
communication integrity. Interaction between subcomponents is documented using a
connection pattern, but ArchJava does not support explicit destruction of components or
connectors.

D. AADL

An international standard called AADL (Architecture Analysis & Design Language) is used in
model-based engineering for embedded and real-time applications. It is aimed at the
automotive, avionics, and space industries and draws inspiration from MetaH.

A lower-level model language called AADL concentrates on communication buses, ports,

components, and threads. It simulates the topologies of software and execution platforms as
well as their interactions. One of the first companies to model timing characteristics and
resource usage was AADL. Through modes, it also permits reconfiguration of known systems.
Events cause transitions, which are specified using a state transition diagram.

6.3.2 Evaluation
This section discusses languages that explicitly represent dynamic architectures. These
languages are based on a limited version of the CRUD primitives, allowing for the creation
and deletion of components or connections.

However, the reconfiguration policies are separate from the software architecture for
Fractal/FScript and AADL, but are intertwined with the components for ArchJava and

Group 1 Page 7
 Software Architecture Evolution

partially for Wright. Additionally, these languages have different goals in describing
dynamics.

6.3.3 Frame for Dynamic Software Architecture

Rather than explicitly specifying the set of potential snapshots of the system configuration,
some ADLs allow delimiting the space of potential evolutions in what we call a frame for
dynamic software architecture.

A. UML 2.0

UML 2.0 allows for the specification of logical components, both at the level of business and
process components, through the composite structure diagram.

The deployment diagram, on the other hand, is used to represent deployed components such as
artifacts and nodes. The system is modeled as a hierarchical structure of nested components
that provide and require interfaces.

Decomposition is supported through the use of structured classifiers, which can be internally
decomposed into classes, collaboration, and components.

The diagram represents a component as a self-contained unit that encapsulates the state and
behavior of a set of classifiers, with its own behavior specification and contract of
provided/required services. The relationships between components are represented by
connectors and ports. This type of diagram is particularly useful in designing software
architectures, where the variability of the architecture is confined within the subcomponents.

The connections between component instances must match the connection patterns declared in
the enclosing component between component types. However, UML 2.0 does not provide a
framework to illustrate the dynamics of the software architecture in cases where the nested
hierarchy is modeled with fixed cardinality instances.

B. Saf Archie

Group 1 Page 8
 Software Architecture Evolution

Saf Archie defines architecture types, which enforce constraints on component interfaces and
their interactions.

These types are used to ensure compatibility between components. An architecture type
consists of port types, component types, composite types, bindings, operations, and attributes.
Port types specify desired operations, component types define port types and their cardinality,
and composite types determine component types and their cardinality. Bindings enable
interactions between port types within composite types. Typed software architectures must
adhere to these constraints.

C. ACL

Tibermacine and his colleagues propose an Architectural Constraint Language (ACL) that
allows for the formal description of architectural choices in the component-based software
development process.

ACL is based on the UML's Object Constraint Language (OCL) but modifies the syntax and
semantics to limit the scope of constraints to specific components. Each constraint context in
ACL introduces an identifier corresponding to the name of an instance in the meta-class
context. ACL interprets constraints based on the meta-class context, but restricts them to the
specified instance. This enables components to define their own structural constraints. Unlike
OCL, ACL only expresses invariants and does not include pre- and post-conditions. By using
ACL, architects can define a set of invariants that all system configurations must adhere to,
providing a framework for software architecture.

Compared to using UML 2.0 or SafArchie, ACL allows for more precise constraints and is
easier for designers to define and understand compared to formal languages like OCL.

D. Arch Studio
Group 1 Page 9
 Software Architecture Evolution

Arch Studio introduces constraints to restrict runtime changes that compromise system
integrity. These constraints confine the set of changes and specify when they may occur. Arch
Studio supports transactional modifications, with the constraints checked only at the end,
allowing the system architecture to be temporarily in an invalid state.

However, there are limitations with current approaches. Firstly, there is a lack of connection
with component-based platforms, as existing models do not combine a scripting language with
architecture checks to evaluate evolutions. Secondly, defining valid architectures with
constraints or architecture types often results in an infinite number of possibilities, making it
impossible to check the correctness of all architectures using current model checkers.

6.4 Aspect-Oriented Architectures Description Language

6.4.1 Issue
An early version of ArchStudio proposes a method to restrict runtime changes that
compromise system integrity. This is achieved through the use of constraints, which confine
the types and timing of changes that can occur.

Arch Studio supports transactional modifications, where constraints are checked only at the
end of a transaction, allowing the system to be temporarily in an invalid state. However, there
are two main limitations with these approaches. Firstly, there is a lack of integration with
component-based platforms, as no approach combines scripting language with architectural
constraints. Secondly, the number of valid architectures defined by constraints or architecture
types can be infinite, making it impossible to evaluate all of them using current model
checkers.

Group 1 Page 10
 Software Architecture Evolution

6.4.2 Using Aspects in Architectural Description

A. IEEE 1471

IEEE 1471 is a formal standard that defines what an architectural description (AD) is for
software-intensive systems. It was developed by the IEEE Architecture Working Group
between 1995 and 2000 and later became a draft international standard. This standard
emphasizes the separation of concerns in software architecture description.

The framework establishes content requirements for an architectural description and specifies
how it should be organized and its information content. It is method-neutral and notation-
independent, allowing it to be used with a variety of existing and new architectural methods
and techniques. An AD in IEEE 1471 consists of a collection of products used to document an
architecture. It is governed by a set of rules that define its conformance to the standard. The
framework also identifies architectural concerns such as functionality, security, performance,
and reliability, which are considered as aspects managed at the design stage.

Architectural views in an AD are representations of the whole system from the perspective of
a set of concerns. Each view is governed by an architectural viewpoint, which provides
conventions and rules for constructing, interpreting, and analyzing the view. Stakeholder
concerns must be covered by at least one architectural viewpoint, otherwise, the AD is
considered incomplete.

While IEEE 1471 does not propose the use of Aspect-Oriented Modelling for composing
views, it recognizes the importance of stakeholder management and the separation of concerns
in software architecture description. It provides a conceptual framework that can be combined
with other tools and methods to support aspect-oriented software development.

B. Aspect-Oriented ADLs

Several ADLs have been developed to enhance modularity and component reusability by
integrating Aspect-Oriented (AO) abstractions. These abstractions, such as aspects, join
points, point cuts, and advice, address the modeling of crosscutting concerns. Cross cutting

Group 1 Page 11
 Software Architecture Evolution

interactions in software architecture descriptions require an equivalent abstraction to express

them, as traditional connectors cannot accurately model these interactions.

Architectural Aspects, composed of aspectual connectors and components, represent

crosscutting concerns in component-based architectures. Aspectual Acme introduces the
Aspectual Connector, an architectural connection element based on the connector element but
with a different interface and semantics.

The aspectual component interface includes a glue clause, base roles, and crosscutting roles,
specifying how the aspectual component affects regular components. Fractal Aspect
Component (FAC) extends the Fractal ADL by introducing Aspect Components (AC) to
specify crosscutting concerns. ACs can affect components through a special interception
interface, with bindings between components and ACs defined either directly or using pointcut
expressions.

PRISMA takes a symmetrical approach where functionality and aspects are treated equally,
with aspects representing specific behaviors of concerns that crosscut the software
architecture. PRISMA provides a homogeneous treatment of functional and non-functional
requirements. Aspects are considered first-order citizens in software architectures.

6.4.3 Evaluation
The lack of consensus among existing approaches regarding the definition of aspects in
software architecture is highlighted in this section. Some approaches view aspects as
components, while others consider them as a type of component or as components composed
of aspects. However, it is generally agreed upon that the semantics of composition should be
expanded to incorporate aspects into an Architecture Description Language (ADL). In
software architecture, software connectors facilitate interactions between components, and
numerous approaches modify the semantics of connectors to accommodate the principles of
Aspect-Oriented Software Development (AOSD) in architecture descriptions.

AOSD not only assists in separating concerns during software development but also helps
address issues related to software evolution. Enhancing separation at the architecture level can

Group 1 Page 12
 Software Architecture Evolution

enable coordination between various stakeholders and allow for independent modification of
concerns.

However, integrating or modifying a concern often necessitates invasive modifications to the

ADL specification, which is a laborious and error-prone process, posing difficulties in
incorporating such concerns.

The AOSD evolution paradox emphasizes how the evolution of a concern can disrupt the
consistency of the software architecture. Ensuring consistency when modifying the base
architecture with an aspect is a crucial concern in the software architecture community. To
explore this problem and propose a potential solution, the framework TranSAT is introduced
for in-depth study, which facilitates the integration of new concerns in a software architecture
incrementally.

6.5 The Safe Integration of New Concerns in a Software Architecture

6.5.1 Overview of Tran SAT

Tran SAT is a framework designed to enable the safe integration of new concerns into a
software architecture. It provides a structured approach to managing architectural changes by
facilitating concern specification, impact analysis, integration planning, verification and
validation, and monitoring and adaptation.

Tran SAT aims to streamline the integration process while minimizing disruptions and risks
to the system's functionality and integrity.

Group 1 Page 13
 Software Architecture Evolution

6.5.2 Integrating a Session Expiration Concern using TranSAT framework

Integrating a Session Expiration Concern using Tran SAT requires a systematic approach to
ensure safe and effective addition to software architecture. The process involves several steps:

 Concern Specification: Specify the Session Expiration Concern by defining

properties, dependencies, and interactions related to session management, including
session timeout duration, validation mechanisms, and user notification methods for
expired sessions.
 Impact Analysis: Conduct a thorough analysis to assess how the Session Expiration
Concern will affect other components and concerns within the architecture. Identify
potential conflicts, dependencies on authentication services, and impacts on system
performance.
 Integration Planning: Create an integration plan based on the impact analysis. This
plan outlines necessary modifications to existing session management components,
coordination with authentication services, and implementation tasks like updating user
interfaces.
 Verification and Validation: Perform testing and validation activities to ensure that
the integrated Session Expiration Concern meets the specified requirements. Test
session timeout functionality, verify validation mechanisms, and validate user
experience for expired sessions.
 Monitoring and Adaptation: Utilize Tran SAT's monitoring capabilities to track the
behavior and performance of the Session Expiration Concern. Monitor session timeout
events, user responses to expired sessions, and system performance metrics related to
session management. Adaptation mechanisms are also available to make adjustments
during runtime, optimizing session timeout configurations based on usage patterns.

6.5.3 Issue
Integrating a Session Expiration Concern using the Tran SAT framework may lead to various
issues. These include dependency conflicts, which can create challenges and runtime issues.
Performance may be impacted if session expiration mechanisms are not optimized or

Group 1 Page 14
 Software Architecture Evolution

thoroughly tested. Changes related to session expiration can also affect user experience and
require careful design and validation. Improper implementation could introduce security risks
like session hijacking. Integrating session expiration into the existing architecture may require
significant effort and coordination. Additionally, ongoing maintenance and updates may
increase system complexity.

6.5.4 A Specific Language for Software Architecture Transformation

It refers to a specialized language designed to facilitate the process of transforming software
architectures. This language is typically tailored to the specific needs and requirements of
architecture transformation tasks, providing a structured and efficient way to express the Join
Point Mask, The Transformation Rules, Computation Transformation primitives, Interaction Transformation
Primitives.

 
The Join Point Mask is a tool used in software architecture transformation. It helps identify
specific points within the architecture where transformations should be applied. It acts as a
filter, selecting relevant components, connectors, interactions, or other elements for
transformation. The mask uses criteria or patterns to determine what should be transformed.

These criteria can be based on attributes like component types, interface properties,
communication protocols, or data flow patterns. The mask can operate at different levels of
granularity within the architecture, targeting individual elements, groups, or entire subsystems.
It should be flexible enough to handle different scenarios, allowing for complex conditions
using logical operators, pattern matching, or custom predicates. It is important for the mask
language to be expressive and easily understood by architects, designers, and developers
involved in the process.

 
A Specific Language for Software Architecture Transformation involves transformation rules
that govern architectural changes. These rules have key aspects:

Group 1 Page 15
 Software Architecture Evolution

 Purpose: The rules aim to achieve specific goals like improving performance,
enhancing scalability, ensuring standards compliance, and addressing architectural
concerns.
 Conditions: Each rule has conditions based on architectural properties, system states,
context information, or user-defined constraints that must be satisfied for the rule to be
applied.
 Actions: The rules specify actions like adding/removing components, modifying
interfaces, adjusting configurations, optimizing algorithms, or reorganizing system
structure when conditions are met.
 Order of Application: Rules may specify the order of application to ensure the correct
sequence of transformations and avoid conflicts or inconsistencies.
 Dependencies: Rules may have dependencies on other rules or external factors, which
must be managed for a coherent transformation process.
 Validation and Verification: Rules should be validated and verified for correctness,
completeness, and effectiveness through testing, simulation, or formal techniques.
 Documentation and Explanation: Clear documentation and explanations of each rule's
purpose, rationale, and impact on the architecture help stakeholders understand them.

 
Computation transformation primitives are essential operations in software architecture
transformation. They focus on modifying computational aspects of the architecture, including
components' behavior, operations, and interfaces. These primitives serve the purpose of
introducing changes in the computational behavior of architectural elements. They enable
architects and developers to modify component interaction, data processing, and operations
within the software system.

There are several types of computation transformation primitives, such as creating ports to
facilitate communication, defining new operations to enhance functionality, replacing existing
operations to modify behavior while maintaining compatibility, destroying ports when they are
no longer needed, and moving operations within components for reorganization and
optimization.

Group 1 Page 16
 Software Architecture Evolution

These primitives are integrated with transformation rules to implement specific changes or
actions in the transformation process. They can operate at different levels of granularity, from
fine-grained operations like creating or destroying individual ports to coarse-grained actions
like redefining entire component behaviors.

Validating computation transformation primitives is crucial to ensure adherence to

architectural constraints, system consistency, and achieving desired architectural goals without
introducing errors or conflicts.

 
Interaction transformation primitives are essential components in a language for software
architecture transformation. They manage interactions between components, communication
protocols, and composite content. Their purpose is to modify interactions, communication
protocols, and composite structures within the software architecture.

They can manage component bindings by creating, modifying, or deleting bindings and
establishing communication paths. They can also modify or replace communication protocols
and mechanisms used for inter-component communication.

Furthermore, they can reconfigure composite components or structures by adding, removing,

or modifying elements. Interaction transformation primitives are integrated into transformation
rules to implement specific changes related to interactions and communication patterns. They
operate at various levels of granularity and must be validated to ensure compliance with
architectural constraints, maintain system coherence, and achieve desired interaction patterns
without errors or inefficiencies.

6.5.5 Static Verification of Transformation

Static verification of transformations involves analyzing static properties and performing
checks to ensure the correctness and consistency of transformation rules. Some key static
properties and checks in this process include:

Group 1 Page 17
 Software Architecture Evolution

 Syntactic Correctness: Verifying that transformation rules adhere to the syntax rules
of the language, ensuring proper structure, valid expressions, and absence of syntax
errors.
 Semantic Consistency: Checking that transformation rules are logically correct,
meaningful, and do not contain contradictory or nonsensical rules.
 Type Compatibility: Ensuring that types used in transformation rules match
appropriately, such as validating operations on architectural elements for validity and
type-safety.
 Rule Conformance: Validating that transformation rules comply with the language's
rules and specifications, including proper usage of language features and adherence to
transformation guidelines.
 Constraint Validation: Checking that constraints specified in transformation rules are
satisfied by the target architecture, verifying preconditions, post conditions, invariants,
and other specified constraints.
 Invariant Preservation: Ensuring that transformation rules preserve invariants and
architectural properties before and after applying transformations, avoiding violations
of system invariants or inconsistencies in the architecture.

6.6 Dynamic Verification

Dynamic verification in software architecture involves validating and testing architectural

transformations by executing them on real or simulated systems. Key points about dynamic
verification include:

 Execution-Based Testing: Transformation rules are executed and their effects on the
system's behavior, structure, and performance are observed. This can be done using
real system instances, simulated environments, or test beds designed for dynamic
testing.
 Test Scenarios: Different aspects of the architecture undergoing transformation are
tested by defining test scenarios and input data. This includes covering various use
cases, system states, edge cases, and performance benchmarks.

Group 1 Page 18
 Software Architecture Evolution

 Observation and Analysis: Developers observe and analyze the system's behavior and
outputs to assess the impact of transformations. This includes monitoring changes in
functionality, performance metrics, resource utilization, and compliance with
architectural constraints.
 Validation Criteria: Validation criteria and expected outcomes are defined for
dynamic verification tests. This includes specifying desired system behaviors,
performance targets, functional correctness, and compliance with transformation rules
and architectural requirements.
 Performance Testing: Performance testing is included to assess the impact of
transformations on system performance, scalability, responsiveness, and resource
utilization, identifying bottlenecks and potential degradation.
 Integration Testing: Dynamic verification is integrated with other testing processes to
ensure end-to-end validation of architectural transformations within the software
development lifecycle.

6.7 Assessment

Assessment is vital in software architecture transformation to evaluate the effectiveness and

impact on the software system. Key aspects of assessment include:
 Effectiveness Evaluation: Compare the pre- and post-transformation states to
determine the level of improvement achieved.
 Quality Metrics: Use criteria to evaluate attributes like performance, scalability,
reliability, security, and compliance with standards.
 Functional Correctness: Test the transformed architecture against requirements, use
cases, and scenarios to ensure it functions correctly.
 Non-Functional Attributes: Assess usability, accessibility, responsiveness, and
adaptability to address non-functional requirements and user experience.
 Validation against Constraints: Ensure the transformed architecture complies with
constraints, guidelines, and industry standards.

Group 1 Page 19
 Software Architecture Evolution

 Feedback and Iteration: Gather feedback to improve the architecture iteratively

based on assessment results.
 Risk Assessment: Identify risks, such as vulnerabilities, performance bottlenecks, and
dependencies, and develop strategies to mitigate them.
 Documentation and Reporting: Record findings, recommendations, and lessons
learned, generating reports for stakeholders

Group 1 Page 20
 Software Architecture Evolution

6.8 References

1. J. Aldrich, C. Chambers, and D. Notkin. Architectural reasoning in ArchJava. In

ECOOP ’02: Proceedings of the 16th European Conference on ObjectOriented
Programming, pages 334–367, London, UK,2002. Springer-Verlag.
2. R. Allen. A Formal Approach to Software Architecture. PhD thesis, Carnegie Mellon,
School of Computer Science, January 1997. Issued as CMU Technical Report CMU-
CS-97-144.
3. O. Barais and L. Duchien. SafArchie studio: An ArgoUML extension to build safe
architectures. In Pierre Dissaux, Mamoun Filali Amine, and Pierre Michel,editors,
Architecture Description Languages, pages 85–100. Springer, 2005.
4. O. Barais, L. Duchien, and A.-F. Le Meur. A framework to specify incremental
software architecture transformations. In 31st EUROMICRO Conference on Software
Engineering and Advanced Applications (SEAA), pages 62–70. IEEE Computer
Society,

Group 1 Page 21