![](bg4.png)
contains the following layers: Presentation,
Verification, Encryption, and Data Access.
2.2.6 Stage VI
Requirements: The application needs to execute
work units or groups of operations whose result to
be available only if the entire group was processed
successfully. Such an operation group should not
overwrite during its execution data that was already
modified by another.
Consequences: This stage is the first in which it
becomes necessary to preserve the operational
integrity of data. The application’s work units
composed of multiple operations defined in the
requirement are actually translated into database
transactions. The clients will therefore require the
ability to impose locks on the records that they read
with the purpose of modifying so that no other
instance will attempt to simultaneously do it. The
transaction execution can be done either by using the
native database support or by embedding the
transaction mechanisms in the application. Also,
there is a third option of implementing the
transactions as database stored procedures.
In case the transactions are processed using the
native database support or implemented as stored
procedures the 2-Tier physical architecture of the
application remains unchanged. However, if the
transactional support is implemented directly in the
application, its physical architecture will modify,
becoming 3-Tier. The additional tier will be
dedicated to transaction management.
Practically, the choice is about the best
transactional model for the application, the available
options being: TP-Less, TP-Lite and TP-Heavy.
As per the initial assumption that at each stage
the lowest impact solution will be chosen, the native
transactional support of the application will be used,
going for a TP-Less transaction processing strategy.
2.2.7 Stage VII
Requirements: The application needs to cope
with strict performance criteria, related both to the
processing speed and the bandwidth required for
data transfer from and to the database.
Consequences: Such non-functional
requirements will trigger modifications in the way
transactions are processed.
There are situations in which the use of the
native transactional support of the database does not
fulfill the required performance criteria, especially
because of the big amount of data transferred to and
from the client in order to be processed. The data set
resulted after each operation will be sent to the client
who will take the decision of continuing the
transaction or not.
The transaction’s implementation as stored
procedures will diminish the quantity of data
transferred through the physical communication
environment. I/O operations are probably the
bottleneck of any software systems, and they are
even slower if network transfer is also involved.
2.2.8 Stage VIII
Requirements: The application needs to support
a number of clients bigger than the maximum
number of connections accepted by the database.
Figure 5: Eighth’s Stage Architecture.
Consequences: The adoption of the above stated
requirement involves changes in the physical
architecture of the application. The transaction
processing strategy needs to change, going to TP-
Heavy and consequently adding a new tier. The
introduction of the additional tier consisting of a
transaction manager, one of the simplest types of
application servers, will change the physical
architecture to 3-Tier (Figure 5).
A transaction manager is doing a multiplex
operation between n clients and m connections,
where usually n is greater than m using a waiting
queue.
3 MATHEMATICAL MODEL
A software system like the one used for the above
case study mathematically modeled. Apart from
modeling the state of the system as any point of
time, its evolution can also be modeled.
Architecturally, a system evolves only when
exposed to stimuli or events, which in such a case
are new or modified requirements. Depending on the
new or modified requirements, the system will
change or not the architectural state, both physically
and/or logically. Therefore, the evolution of a
software system during successive development
cycles can be modeled as a discrete set of states X,
where
Xx
is any discrete state of the system.
MOLDING ARCHITECTURE AND INTEGRITY MECHANISMS EVOLUTION - An Architectural Stability Evaluation
Model for Software Systems
429