Chapter 1

Introduction to software architecture

Agenda! We are going to cover:-
• What is Software Architecture?
• Where does Software Design sit in the whole Software Development
Life Cycle(SDLC)?
• Software Architecture: Bridging Software Requirement and Software
Implementation
• Architecture Design Looks
• Architecture Styles
• Quality Attributes
• Software Architecture Design Guidelines
What is Software Architecture?

“Software Architecture is all about structure and vision.”

Simon Brown
Where;
• Application Structure: emphasis on how you divide your software
application.
While;
• Application Vision: emphasis on how your application will response to
future changes . Which is the role of software architect to make future
changes easy-to-change . This point also subject to non-functional
requirement such as reliability and scalability.
Con…
• According to the Book of Software Architecture in Practice (third
edition), Defined Software Architecture as:

• A set of structures needed to reason about the system, which comprise

elements, relations among them, and properties of both.
Where does
Software
Design sit in
the whole
Software
Development
Life
Cycle(SDLC)? Figure 1.1 Software Development Life Cycle
SDLC
Software Architecture: Bridging Software Requirement and Software
Implementation

• Software architecture plays a very important role in software

development. It is a blueprint guidelines for developing a large and
complex software system based on the Software Requirements
Specification (SRS ).
• Software Architecture highlights early design decisions that have a
decisive impact on the ultimate success of software products.
• Software Architecture covers the software functional requirements
and non-functional requirements.
• Software Architecture shows how the system is structured and how
its components work together, as depicted in the following slide.
Architectural design looks
Figure 1.2 Box-and-Line diagram showing sub-systems

• Sub-system also called elements, which plays a

sole responsibility such as interface presentation,
data gathering, business logic. It performs function
required by the system.
• Connectors that enables communication,
coordination, cooperation among elements and
components.
• Constraints that define how elements can be
integrated to form the system.
Architecture Styles (Patterns)

• Data flow styles: Batch Sequence, Pipe & Filter, Process Control.
• Data Centered: Repository, Blackboard.
• Object-Oriented.
• Hierarchy: Layered, Virtual Machine, Main/Subroutine.
• Distributed: Multi-tier, Client/Server.
• Asynchronous Communication: Event-Based, Buffered Messaging.
• Interaction Oriented: MVC, PAC.
Quality Attributes
• Each architecture design has its advantages, disadvantages and
potential risk.
• Choosing the right architecture style to satisfy required quality
attributes is very important in addition to function satisfaction.
• Quality attributes are identified in the requirement analysis
process.
• Quality attributes are non-functional requirements and
represent the architectural constraints of the system. It
describes the intended behaviors of a system and measure its
suitability.
Quality Attributes are categorized
into three categories:
• 1. Implementation attributes (Not observable at run time)

• Interoperability – the universal accessibility and the ability to exchange data with internal
components and outside world.

• Maintainability & extensibility – the ability to be fixed and extended conveniently.

• Testability – the degree to which the system facilitates the establishment of test cases, and low
risk of bugs and faults. It usually requires a complete set of documentation accompanied with
system design and implementation.

• Scalability – the ability to adapt to the increase of user requests volume.

• Flexibility – The ease of modification of a system to cater to the environment or problems that
the system is originally not design for.
Con…
• Runtime attribute (observable at runtime)

• Availability – the ability of a system to be available 24/7 days.

• Security – the ability to prevent malicious attacks from outside or
inside of the system.
• Performance – it usually includes times efficiency and resource
efficiency, which most of the time conflict with each other,
according to theory of computation.
• Useability – it usually includes the completeness of software,
correctness, compatibility, and user-friendliness.
Con..
• Business attributes

• Time to market: the time it takes from requirement analysis to the

date product is released.

• Cost: expense of the project.

• Lifetime: the period of time that the product is alive.

Software Architecture Design
Guidelines
1. Think of what to do before think of how to do it.
• All functional and non-functional requirements should be identified, verified, and
validated before the overall and detailed design.
• Using the abstract architecture design of a system to communicate with stakeholders
help avoid overhauling the system design in later stage of the software development
cycle.
• A successful analysis design relies on a successful and accurate requirement analysis.
• Note: Different stakeholders of software system have their different concerns, such as:
 Software Architects have to make sure what are needed and what can be traded off.
 Investors of the software project are usually concerned with system release date,
budget, usability, etc..
 Software developers focus on the implementation and are concerned with whether
the software design is detailed enough for coding.
 Software project managers may be concerned with software architecture evolution
and maintenance in the future
Con..
2. Think of non-functional requirements as early as possible.
• Should consider non-functional requirements while mapping functional
requirement to architecture design.
• Communicate with stakeholders and document their preferences of quality
attribute. Its not possible to find a design meeting all quality attributes. Thus,
tradeoff is required.
3. Think of software reusability and extensibility. For most software
systems, it is very likely that new functionalities will be added after they
are deployed. Reuse existing software components to increase
reliability and cost effectiveness of new system.
Con..
4. Try to promote the high cohesion within each element and loose
coupling between elements.
• For example, in OO design if a class is assigned to bear two unrelated responsibilities, it
is regarded as incoherent.
• A similar concern is that each architecture style should show a very clear division lines
between elements to guarantee loose-coupling. In most cases, loose coupling means less
interdependency between components. Hence, the change of one component will not
likely to cause ripple-changes of other component.
5. Tolerate refinement of design
• Never expect to have software design completed perfect within one step.
6. Avoid ambiguous design and over-detailed design
• Ambiguous design lacks constraints and over-detailed design restricts implementation.
Software Architecture
Design Space
Overview
• The architect responsibilities:
• Architect is responsible for proposing a concrete software
architecture to best support the detailed design and
implementation of a software project.
• Architect must know what design alternatives are available to
him, and which one supports the functional and non-
functional project requirement specification better.
“Software Architect must understand his software architecture design space”
Con..
• Basically, software architecture is a set of software elements
connected by a set of connector.

• A software element can be a process, an object, an instance of a software

component, or a service.

• “Different software elements may run on different hardware and software platform and
be implemented in different programing language or on different software frameworks.”
Also
• “Two software elements can run in the same process, on the same computer system,
within an intranet, or distributed over the internet.”
Con..
• Thus, depending on their relative location, the connectors between a
pair of software elements can be implemented in various forms,
includes:
• Local method invocations
• Remote method invocation
• Service calls
• Messaging through a message Queue

“Connectors can work in different modes including synchronous and

asynchronous.”
Types of Software Structure
A software architecture can be described with various software
structures, each from different perspective.
• Software code structure
A software project is implemented in multiple source file. During the deployment a project
includes many static file types including executable files, library files, binary software
component modules, deployment descriptors and other resource files.

At software development time, the main software elements are source code modules or
files. Each of these software modules will assigned functional and non-functional
attributes, and public APIs will be defined for each module to separate the interfaces and
implementations of a module.

The connector at this level are in the form of module dependency. Module A is connected
to module B if and only if A needs to invoke some method in module B during execution.
Con..
Such connectors have attributes including the following:
• Direction: If module A invokes a method of module B during execution, then
there is a unidirectional connector from module A to module B.
• Synchronization: A method invocation can be synchronous or asynchronous.
• Sequence: Some connector must be used in particular sequence.