Introduction to Software Architecture
1
Lecture Objectives

What is software architecture?

What are popular architecture styles?

Quality attributes of a system?

Architecture Design Guidelines?
2
Overview
Goal of SW Design - is to build a model that meets all
customer requirements and leads to successful
implementation


Software systems grow in

Scale

Complexity

Distribution
How to deal with complexity?

Software engineering!
3
What is architectural design?
Any software, regardless of application domain, should have an
architectural design that guides its construction and development.
What is architectural design?
» It defines the relationship between major structural elements
» It also define the styles and design patterns used to achieve requirements.
» Also the constraints that affects the way architecture can be implemented.
4
What is architecture design?
Who is responsible for developing architecture design?
» Software architect and designer.
» They map the SW system requirements into architecture design.
» They apply various design strategies to divide and conquer the
complexities.
The architecture of a system is its 'skeleton'. It's the highest level of
abstraction of a system.
Software architecture is more about the design of the entire system, while
software design emphasizes on module/component/class level.
5
Why is SW architecture Design is important?
There are several reasons:
» Poor design

May result in deficient product (does not meet system
requirements)

Is not adaptive to future requirement changes

Not reusable

Exhibits unpredictable behaviour or perform badly
» Good design!!
» Risks
» Order
» Traceability
6
Software Development Life Cycle (SDLC)
7
Software Requirements Specification
8
Software Requirements Specification

Serves as contract between


Developer and Customer
Specifies

Functional requirements

Non-functional requirements


Speed

Reliability

Security

Program size ...
System constraints and pre-condition
9
Software Design Description (SDD)


Describes high and low level design

Components of the system

Modules of each components

Detailed information of each module

Data attributes

Operations

Developer
DB oriented application - data dictionary

Tables, columns and definition of terms.
10
Software Design Description (SDD)

A sample outline of SDD (IEEE 1016)

Design overview, purpose and scope

Decomposition description (module, data, and process)

Dependency and connection

Attributes

User interfaces

Detailed design
11
Software Design Description (SDD)
• House construction analogy
– Requirements
– Blueprints
• Styles available, functionality, features
12
Design
 In
summary, SDLC consists of
 Specification
Analysis
 Design
 Implementation
 Testing,
 We
Maintenance
are interested in Design
13
Design

Further split into two steps

Architectural Design

Detailed Design/Tactical design

Architecture design is front strategy for the detailed
design

Arch. Design: exposable components

Detailed Design: invisible components
14
Example

Architecture Decision:


A priority queue for all customers
Detailed Design Decision:

The priority queue implemented using

Array?

Linked List?

Double Linked List?

...
15
The Evolution of Software Design
• modular programs
• structured programming
• data flow or data structure
• object-oriented approach
• software architecture
• design patterns
• aspect-oriented
• effective modularity and architectural structure in the
designs
16
Motivation of Architecture Design

Question: can we directly start with detailed design?

Most likely NO! for large scaled systems

Example: build a house, many styles available:

Victorian, Colonial, Cap Cod, California Ranch

Depending on the system spec., a style has to be chosen
17
Software quality attributes
•
Performance
•
Reliability
•
Portability
•
Usability
•
Security
•
Testability
•
Maintainability
•
Adaptability
•
Modifiability
•
Scalability
•
tradeoff between time/resources and system reliability and availability
18
Introduction to Software Architecture

Software Arch: very important in software development

Highlights early design decisions

Shows how system is structured

Covers functional and non-functional requirements

Blueprint guideline for development
19
Box-Line Diagram
•Sub system sole responsibility (business logic, brokering, interface etc)
•Abstraction and UML diagrams
20
• This division of elements is based on their functionality, location, and
runtime images.
• The elements may be in the form of modules, objects, packages,
deployed elements, tasks, functions, processes, distributed programs,
etc.
• The topology of the static structure focuses on the system composition
configuration such as layered, flattened, star-typed, centralized, or
distributed.
• The dynamic runtime connectors may be batch-sequential,
multithreaded, explicit direct invocation, implicit indirect invocation
(such as message queue or event notification), synchronous or
asynchronous communication, peer-to-peer message exchange or
message broadcasting, or another applicable coordination and
cooperation mechanism among the elements.
21
Formal Definition of SW Architecture

By IEEE 1471

“the fundamental organization of a system embodied in its
components, their relationships to each other, and to the
environment, and the principle guiding its design and evolution”
 Garlan and Shaw define software architecture as
 “the description of elements that comprise a system, the
interactions and patterns of these elements, the principles that
guide their composition, and the constraints on these elements”
 Components vs. elelments
 Module, subsystem,
22
• Software design depends on the Software Requirement
Specification (SRS)
– information domain modeling, data modeling, function modeling,
behavioral modeling, and user interface modeling.
• functional and nonfunctional.
– functionality vs system qualities, constraints, and behaviors.
• Connectors, constraints and run time behavior
23
Analysis Model -> Design Model
sc e na r i o- ba se d
e l e me nt s
Co m p o n e n t L e v e l D e sig n
f l ow- or i e nt e d
e l e me nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e rf a c e D e sig n
Analysis Model
c l a ss- ba se d
e l e me nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e me nt s
A rc h it e c t u ra l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
24
Software Architect

Who does the architectural design?


System Analyst or Software Architect
Jobs of Software Architect:

System static partition and decomposition

Establishing dynamic control between subsystems

Considering and evaluating all alternative architectural styles

Analysis of trade-off on quality attributes

Distributed system vs web components
25
Architecture Style

What is architecture style?

It contains a set of rules, constraints, and patterns of how to
structure a system into a set of elements and connectors

It governs runtime interaction of flow control and data transfer.
It is an abstraction of a family of similar designs.
26
Architecture style
• An architectural style is a named collection of
architectural design decisions that
– are applicable in a given development context
– constrain architectural design decisions that are specific to a
particular system within that context
– elicit beneficial qualities in each resulting system
•
Reflect less domain specificity than architectural patterns
•
Useful in determining everything from subroutine
structure to top-level application structure
27
Architecture Style

Key components are:

Elements that perform functions

Connectors that enable communication, coordination, and cooperation
among elements

Constraints that define how elements are integrated

Attributes that describe the advantages and disadvantages of the chosen
structure
28
Example

Data Flow


Batch sequence, Pipe & Filter, Process Control
Data Centered

Repository and Blackboard

Object Oriented

Call and return

Hierarchy


Asynchronous Communication


Event-Based, Buffered Messaging
Interaction Oriented


Layered/ packages
MVC, PAC
Heterogeneous
29
Multi tier architecture
• Distributed architecture
– Front end
– Middleware
– Backend
30
Why Architecture Style?

Saves cost and time on design!


Architecture style represents


Think about house example
Layout topology of elements

connectors and interactions

semantic constraints and behaviors

data transfer and control transfer
Once overall structure determined, rest are easy
31
Benefits of Using Styles
• Reuse
– Design: Well-understood solutions applied to new problems
– Code: Shared implementations of invariant aspects of a style
• Understandability of system organization
– A phrase such as “client-server” conveys a lot of information
• Interoperability
– Supported by style standardization
• Style-specificity
– Analyses: enabled by the constrained design space
– Visualizations: depictions matching engineers’ mental models
32
How to decide architecture style?

Depends on how quality attributes are satisfied.

Three categories

Implementation attributes

Runtime attributes

Business attributes
33
Implementation Attributes


Interoperability

Universal accessibility and ability to exchange data among internal
components and the outside world

Requires loose dependency of infrastructure
Maintainability & Extensibility


The ability to modify the system and conveniently extend it
Testability

Whether the system allows easy debugging
34
Implementation Attributes (cont..)

Portability


Scalability


Can the system be deployed on different platforms
Can system adapt to increase of requests
Flexibility

Ease of modification of system to cater to a different environment
35
Run-Time Attributes


Availability

If system is available 24/7

Can be enhanced by replication
Security


Performance


The ability to defend against attacks
Time efficiency and resource efficiency
Usability

Completeness, correctness, compatibility and user friendliness
36
Business Attributes

Time to market:


Cost:


The time it takes from requirement analysis to the product is
released
Expense of the building, maintaining, and operating the system,
Lifetime:

The period of time that the product is alive before retirement.
37
Trade-Off

Many quality attributes conflicts with each other!

Example:

Space vs. Time



Algorithms, Hash Table
Reliability vs. performance

Java Program – array boundary check => performance down

C/C++ has no such checking and fast
Scalability vs. performance

Sacrifice performance for consistency

Replication of servers
38
Think of What to Do before How to Do It.

System requirements must be nailed down before design
starts

Notice, different stakeholders have different opinions,
e.g.,


Investor: system release date, budget

Developer: system performance, easy to maintain

User: user friendly
Clarify priority of all requirements before design
39
Think about abstract design before
thinking about concrete design.

Always starts with abstraction

Use multiple level of abstraction if necessary

Nail down the interface but leave room of change for
implementation
40
Think of non-functional requirements early
in design process

Speed, Reliability, Security have to be considered first

Otherwise, very hard to change your design to reflect
these requirements

The earlier, the better.
41
Think of reusability and extensibility!

User requirements can change frequently

Extensibility is very important

Leave room for expansion
42
High Cohesion and Loose Coupling

One component (module) should be assigned ONE
functionality only

Design should be logically clear!

The less correlation between modules, the better!

Easy debugging and maintenance

Also allows great extensibility
43
Thanks!
44