Software Architecture Testing

CT059-3-2

Principles of Architecture
 Topic & Structure of the lesson

• Principles First, Second and Third

• Creating architectural understanding

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 2 (out of 11)

 Learning Outcomes

• By the end of this lecture, YOU should be

able to :
– Explain the principles of architecture
– Discuss the importance of software
architecture

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 3 (out of 11)

 Key Terms you must be able to use

• If you have mastered this topic, you should

be able to use the following terms correctly
in your assignments and exams:
– Principles
– Evolution
– Maturation
– Rational 4+1 model

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 4 (out of 11)

 Introduction

• Creating, maturing and evolving, and sustaining

an architecture are guided by both architects
and developers
– Can be very simple, no bearing to architecture
– Can be very detailed and complicated

• Architects must have the skill to recognize and

evaluate and architecture, following some
principles

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 5 (out of 11)

 1st, 2nd and 3rd Principles of
architecture –
refer to week 4 on Architectural maturation and evolution

• 1st – Creation
– Start from small and individual component
– Use used components
– Well tested
• 2nd – Maturation
– Stability
– Reliability
– Availability
• 3rd – Evolution
– Add new technology
– More components
– Make common use architecture

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 6 (out of 11)

 Good Architectural Design
Principles
• Encapsulation
Separate and relatively independent pieces hides
internal implementation details from each other.

Example: In telephone billing system, one part is

responsible for creating, managing and tracking calls,
these data is fed into billing system which manage the
complexities of calculating fees. The billing system is
likely to have separate module for calculating the basic
bill, and then hide this complexity from other
components.

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 7 (out of 11)

 Good Architectural Design
Principles
• Interfaces
 The ways subsystems within larger design interact are clearly
defined.
 They are defined to remain stable through out the life span of the
system
 This accomplished by abstractions over solid implementation,
hence has variability and changes takes place.
 Isolation of aspects of the system

• Example: A program design to write output to a file, instead of programming

directly to the interface provided by a file, program an output mechanism to
the abstract interface, which in many languages is referred to as an output
stream. This allows the program to direct output to a file, the standard
output system or any other target with this interface. The most important
thing is defining initial interface.
CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 8 (out of 11)
 Good Architectural Design
Principles
• Loose coupling
• refers to the degree of interconnectedness,
dependency among the modules.
• Generally loosely coupled pieces are easier to
understand, test, reuse and maintenance because they
can be isolate from other pieces.
– Each sub system in a system should be independent
– Promotes parallelism in the implementation schedule.
– Reusability
– Maintainability

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 9 (out of 11)

 Good Architectural Design
Principles
•Appropriate Granularity
– Level of work performed by a component
– Loosely coupled, when created with too fine
granularity, can be harder , as you have to stitch
together so many modules to get a meaningful piece
of work
– Appropriate granularity is determined by the task
associated with the module

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 10 (out of 11)

 Good Architectural Design
Principles
•High Cohesion
 Describes how closely related the activities within a single
piece(component) or among a group of pieces.
 Highly cohesive module means that its elements strongly
relate to each other.
 highest marks are for cohesion to components that
contribute to only one task. So it should perform or to only
one task.

– Example: In the print module only doing print related activities,

and not something else such as sorting or updating a database….

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 11 (out of 11)

 Good Architectural Design
Principles
• Parameterization
 Components perform their task with some kind of
parameterization or instrumentation.

 The most effective component perform an

appropriate amount of task with the right number
of parameters that enable their user to adjust their
operation.

 A sophisticated form parameterization referred as

inversion of control.
 
CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 12 (out of 11)
 Good Architectural Design
Principles
• Deferral
– should handle certainty
 When the development team cannot make a decision
with certainty(sometimes for technical reasons like
choosing a library to perform a specific function or
sometimes because of the business reason like
choosing technology providers.
 By deferring these decisions as long as possible, the
development team gives themselves the best chance to
make a good decision

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 13 (out of 11)

 Creating Architectural
Understanding/ Developing
Team
• An important criterion for development
team is:-
– Some way to identify, describe, communicate
and modify their understanding of the
architecture, without resorting to source code
– One or more models exist to give a big picture
– The Rational 4 + 1 models recommends 5
primary views of an architecture

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 14 (out of 11)

 Creating Architectural
Understanding
• Philipe Kruchten’s Rational 4+1 model
recommends for primary view of the
architecture

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 15 (out of 11)

 Creating Architectural
Understanding
– Logical view
• Provides the static snapshot of the relationships that exist objects in the
proposed system, with two representation conceptual and the realization
of the model in the data base schema
– Process view
• Describes the design’s concurrency and synchronization aspects
– Physical view
• Describes the mapping of the software onto hardware, including distribution of
processing components created for goals such as availability, reliability,
fault tolerance
– Development view
• Describes the software’s static organization in its development environment
• All architectural decision evolve around these 4 views. In reality should be “n + 1”
• Important to note that the model is more for communication purposes whether it is 5 +
1 of more

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 16 (out of 11)

 The Team

• Team and architecture process cannot be separated.

– Initial development team is important, as they are the
creators of the system, making design choices, based
on their experience, others will have to live with their
choice
– That’s why many prefer to work on new systems
– Team should be small, to maximize cohesion, and
communication overheads 3 – 5 members

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slde 17 (out of 11)

 Summary of Main Teaching Points

• Principles First, Second and Third

• Creating architectural understanding

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slide 13 (of 15)

 Question and Answer Session

Q&A

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slide 14 (of 15)

 Next Session

• Why evaluate software architecture?

• When can software architecture be
evaluated?
• Who is involved?
• What result does a software
architecture evaluation produce?

CT059-3.5-3 Software Architecture Testing Principles of Architecture Slide 15 (of 15)