Topics

Software Architecture Definition

Architectural Decisions & Key Concerns
Architecture Styles
Documenting Architecture: Views
Problem Structure vs. Solution Structure
 Hierarchical Organization of
Software
Product line (or product highest
family) abstraction level
System or
product
Subsystems/
Modules
Packa
ges

Classes/
Objects
Meth lowest
ods level
Source
code
Software is not one long list of program statements but it has
structure
The above is a taxonomy of structural parts (abstraction hierarchy),
but not representation of relationships between the parts and does not
specify the function of each part
The hierarchy shows a taxonomy of the system parts, but not the procedure for
decomposing the system into parts — how do we do it?
But first, why do we want to decompose
 Why We Want ToDecompose
Systems
Tackle complexity by “divide-and-conquer”
See if some parts already exist & can be reused
Focus on creative parts and avoid “reinventing
the wheel”
Support flexibility and future evolution by
decoupling unrelated parts, so each can evolve
separately (“separation of concerns”)
Create sustainable strategic advantage
Software Architecture Definition
Software Architecture =a set of high-level decisions that
determine the structure of the solution(parts of system-to-be
and their relationships)
Principal decisions made throughout the development and
evolution of a software system
made early and affect large parts of the system (“design
philosophy”) — such decisions are hard to modify later
Decisions to use well-known solutions that are proven to work
for similar problems
Software Architecture is not a phase of development
Does not refer to a specific product of a particular phase of
the development process (labeled “high-level design” or
“product design”)
Example Architectural Decisions

Example
Safe Home Access
System
decisions:
Subsyst Subsyste Subsyste
Decision on
em for m for m for
device administr remote system
control ation data decomposition
access
On On On user’s Decision on
embedde office smartphon mapping software-
d deskto e to-hardware
computer p (…and
Web?) Decision on
development platform
or operating system
(Android vs. iOS, etc.)
Decision on how to
fit the subsystems
together
Such decisions are made early on,
(“architecture
style”)
perhaps while discussing the requirements with the customer
to decide which hardware devices will be used for user interaction and
device control
Architectural Decisions—A matter
of scope
product line
product or architecture
system decisions
architecture systemic
decisions Product line impact
scope

Product/system A Product B
scope scope

Subsystem
scope local
Class
scope impact

Given the current level of system scope, a

decision is “architectural” if it can be made
only by considering the present scope
I.e. could not be made from a more narrowly-scoped, local
perspective
Architectural decisions should focus on high impact, high
priority areas that are in strong alignment with the business
Software ArchitectureKey Concerns
(Principal decisions to be
made)
System decomposition
how do we break the system up into pieces?
what functionality/processing or behavior/control to include?
do we have all the necessary pieces?
do the pieces fit together?
how the pieces interact with each other and with the runtime
environment
Cross-cutting concerns
broad-scoped qualities or properties of the system
tradeoffs among the qualities
Conceptual integrity
Software architecture provides a set ofwell-known
solutions that are proven to work for similar problems
 Architectural Decisions Often
Involve Compromise
The “best” design for a component considered in
isolation may not be chosen when components
considered together orwithin a broader context
Depends on what criteria are used to decide the
“goodness” of a design
E.g., car components may be “best” for racing cars
or “best” for luxury cars, but will not be best
together
Additional considerations include business priorities,
available resources, core competences, target customers,
competitors’ moves, technology trends, existing investments,
backward compatibility, …
 Module/Subsystem Views

Module Decomposition View

Top-down refinement (e.g., simple “block diagram”)

Dependency View
How parts relate to one another

Layered View
Special case of dependency view

Class View
“domain model” in OOA and “class diagram” in OOD
Component and Connector Views

Process View
Defined sequence of activities?System represented as a
series of communicating processes

Concurrency View

Shared Data View

…

Client/Server View
E.g., in Web browsing
UML Notation for Software Components

A component has its behavior defined in terms of

provided interfaces and required
interfaces (potentially exposed via ports)

Method call Called method

dependency
from consumer implemented
component by provider
(“output port”) component
(“input port”)

“Consumer”
component “Provider” component
accesses («use») provides («realize»)
functionality through functionality through
Required Interface. Provided Interface.

«component» «component»
Consumer Provider
Required Provided
Interface Interface
 How to Fit Subsystems Together:
Some Well-Known Architecture Styles
World Wide Web architecture style:REST
(Representational State Transfer)
UNIX shell script architecture style:Pipe-and-Filter
Client/Server
Central Repository (database)
Layered (or Multi-Tiered)
Development platform
Peer-to-Peer (e.g., Web vs. mobile
app, etc.) may dictate
Microservices the architecture style or
vice versa…
Real System is a Combination of
Styles

Central
Subsy
stem Repository
for Architecture
device
control Style Subsyst
em for
remote
data
access
- Valid
keys
Subsyste - Access
m for history
administr - Tenant
ation profiles
- …
Applicat Web
Web
ion browser
server
server

Tiered Architecture
Style
 Architecture Styles –Constituent
Parts
1. Components
Processing elements that “do the work”
2. Connectors
Enable communication among components
Broadcast Bus, Middleware-enabled, implicit (events),
explicit (procedure calls, ORBs, explicit communications bus)
…

3. Interfaces
Connection points on components and connectors
define where data may flow in and out of the
components/connectors

4. Configurations
Arrangements of components and connectors that form
an architecture
 Connectors: HTTP Protocol

POST method requests the server to create a new resource

GET method requests the server to read a resource
PUT method requests the server to update a resource
DELETE method requests the server to delete a resource
 Shared Database Connector— Data
Model for Restaurant
Entity-relationship diagram of the data
model:
entity set relationship set

employee assigned dining table food order menu item

- ordered
attribute - prepared
date - ready
- served
date shift
time status
emp-id
customers quantity
tbl-id availability
name salary status price
role capacity mi-id ingredients

Crow’s foot diagram of the same data

model:
employee assigned dining table food order menu item

exactly one zero or one

one or more zero or more

employee (identifier, name, role, salary, …)

assigned (date, working shift)
dining table (identifier, capacity, status, seated
customers)
food order (time, item, quantity, total price,
status)
menu item (identifier, price, ingredients,
Architecture Style: Pipe-and-Filter

Components: Filters transform input into output

Connectors: Pipe data streams
Example: UNIX shell commands
User

More complex configurations: Filter

Pipe
Filter

Pipe
Filter

% ls folder-name | grep –v match-string | more

Pipe Pipe Pipe

Filter Filter
Filter
Pipe Pipe
Pipe Filter Filter
Pipe Pipe
Pipe
Filter Filter
Pipe Pipe
Architecture Style: Client/Server
A client is a triggering process; a server is a reactive process. Clients make
requests that trigger reactions from servers.
A server component, offering a set of services, listens for requests upon
those services. A server waits for requests to be made and then reacts to
them.
A client component, desiring that a service be performed, sends a request at
times of its choosing to the server via a connector.
The server either rejects or performs the request and sends a response back
to the client
User Client Server
Connector

components Client Server

1: 4: 2: 3:

Packing a request Unpacking the response Unpacking the request Packing the response
for network transport for client use for server call for network transport

connector

packets Network connection packets

 Architecture Style: Layered
a.k.a. Tiered Software
Architecture
A layered system is organized hierarchically, each layer
providing services to the layer above it and using services of the
layer below it
Layered systems reduce coupling across multiple layers by
hiding the inner layers from all except the adjacent outer layer,
thus improving evolvability and reusability

User Interface Layer User Interaction

Application Logic Layer Algorithms &

(Business Policies) Data Processing

Technical Services Layer Storage, Networking,

(Mechanisms & Utilities) & Device Drivers
 REST: Hypermedia as the Engine of
Application State (HATEOAS)
REST: Representational state transfer
Conceptual model: hypermedia as the engine of application state
(HATEOAS)
 Hypermedia as the Engine of
Application State
Application state #1
Product Finding
Server resource:
hypermedia of
Application state #2 Application state #4
initial search page
Product Selecting Product Purchasing
Server resource:
Server resource:
State #1 representation: database record of
product catalog
hypermedia of search page Appl. state #3 billing/shipping options

… text text image Product Reviewing

user link text text …
Server resource:
State #2 representation: database record for State #4 representation:
hypermedia of search results hypermedia of product info
product information
… text text text … text link text
State transition text link text … text text text …
(HTTP GET keywords)
State #3 representation:
hypermedia of product info

State transition … text text link State transition

(HTTP GET retailer) image text text … (HTTP POST product to cart)

Web application:
A network of Web resources (a virtual state-machine), where the user by
following the links requests the transfer of next resource (“state”).
 REST physical model

Request (e.g., Server

HTTP) contains
Client all the information Data storage Stateless server:
Session state describing the no memory about
at client: desired resource Web resources past requests by
memory about
User interface
or service, a given client
past and current identified by URI Intermediary Response:
requests representation of
Response caching resource in standard Web resource:
text format (HTML, Identified using URI;
XML, JSON, …); Arbitrary representation
includes hyperlinks to internal to the server
other Web resources
 RESTful Resource Naming
(a) Conceptual representation of creating a new
employee record

(b) HTTP request message carrying the content of the HTML form that
was used to enter the employee data
 REST, a resource-based
architecture style
Client/server style that supports caching and replicated repositories
Uniform interface between components based on HTTP methods and URI-named resources,
which is efficient for coarse-grain hypertext/hypermedia data transfer
Server dynamically communicates to clients the application logic in hypertext or in code-on-
demand
Hypertext does not specify the operations allowed on a resource; it just contains embedded
hyperlinks that determine all possible transitions from the current to the next application state
For every media type, the server has defined a default processing model; standard formats for
message payload representation (HTML, XML, JSON, JPEG, …) ensure interoperability
between different clients and servers
Stateless sessions—each request must carry all the information needed for its processing
Statelessness may cause network inefficiency, so requires caching to avoid redundant
responses
A RESTful API looks like hypertext
Every addressable unit of information carries an address or identifier, either explicitly (e.g., link and
id attributes) or implicitly (e.g., derived from the media type definition and representation structure)
Every media type defines a default processing model
Hypertext doesn’t specify the operations allowed on a resource;it specifies which operation to use for
each potential state transition
RESTful API Design versusJSON-RPC
APIs over HTTP
RESTful APIs JSON-RPC APIs over HTTP
URIs for resource
URIs for object addresses
addresses
Focus on navigable Focus on data-processing
resources (nouns) procedures (verbs)
Application logic runs on the
HATEOAS, application client; the server manages the
logic runs on the server data using CRUD and
application-specific RPCs
HTTP methods for
HTTP methods for service
resource CRUD actions,
actions, plus application-specific
plus media-specific
server-side procedures explicitly
server-side controllers
addressed with the verb as part
activated by the media
of the request message URI
type
Message body can be
 Example Request
Cannondale Trail 1 12 Kids' Bike:
https://www.rei.com/product/145832/cannondale-trail-1-12-
kids-bike?
CAWELAID=120217890005260197&CAGPSPN=pla&CAAGID=1
5877514320&CATCI=aud-553371945779:pla-
539113402242&cm_mmc=PLA_Google
%7C404_1050512963%7C1458320001%7Cnone%7Ccb2b5bf7-
95ae-43d8-a53c-6a16aaf4a0d0%7Caud-553371945779:pla-
539113402242&lsft=cm_mmc:PLA_Google_LIA
%7C404_1050512963%7C1458320001%7Cnone%7Ccb2b5bf7-
95ae-43d8-a53c-6a16aaf4a0d0&kclid=cb2b5bf7-95ae-43d8-
a53c-
6a16aaf4a0d0&gclid=CjwKCAiAyrXiBRAjEiwATI95mcKyoLfTjKFA
aCiElWKC3Vt51nTPk0Fxyt9rm8S0Y99Dikidu_DQrxoC2CwQAvD_
BwE
Architecture Style:
Model-View-Controller
Model: holds all the data, state and application logic.
Oblivious to the View and Controller. Provides API to
retrieve state and send notifications of state changes to
“observer”
View: gives user a presentation of the Model.Gets data
directly from the Model
Controller: Takes user input and figures out what it
means to the Model
disp
lay View 5. I need your state (to
display)

4. I have Model
changed
3. Change your
1. The user did display
something Contro
us ller 2. Change your
er input
state
 Model-View-Controller
User
Interface Model
Controller
Inp Dom
Event Domain
ut ain
Interpret Model
dev mod
er
ice el
eve acti
nts on

Notificati
Visual
Model on
U feedback
Visualizer about
s of the
the
er altered
effects of
model
View the
action

3
2 1 1
Model: array of numbers [ 14, 1 6 3 4
4 ver 1
26, 31 ] 2
sus
6
➔ Different Views for the same
 Problem Structure

Subsystems derived from the requirements (“bottom-up” approach

 Typical Software Eng. Problems
1.a) System transforms input document to output
1. User works with computer document
system REQ-1: Map input data to IN
do
(problem domain is “virtual”, not output data as said by c
physical) given rules
U Sys OUT
s te doc
1.b) User edits information
e stored
m in a
Sys Problem repository r
U
s te domain
e m REQ-2: Allow repository editing,
r where “repository” is a collection
of data U Sys Reposi
s te tory
e m
2. Computer system controls the (physical) r
problem domain REQ-3: Autonomously
(user not involved) control a physical
object/device
U Sys Problem
s te domain
e m 3.a) System observes the problem domain and displays
3. Computer system intermediates
between
r information
the user and the problem domain REQ-5: Monitor and
display information
about an object U Sys Problem
s te domain
U Sys Problem 3.b) System controls the problem domain as commanded
e m
by the user r
s te domain
e m
REQ-4: Interactively
r
control a physical
object/device U Sys Problem
 5-dimensional Problem Space
The five elementary problem types
represent the coordinate system of
Softw
are the problem space
proble
m The “axis” projections represent
to the degree to which the whole
solve
problem contains a subproblem of
this type
Si Data Each subproblem can be analyzed
m
pl
transformat
ion
independently and eventually
e recombined into the whole problem
e Manual control
di (“Commanded The structure of the solution should
A
ut
ti
n
behavior”) be selected to fit the problem
on g structure
o
Information (“
displaym Si
ou m
s pl
co e
nt w
ro or
l kp
(“
Software (i.e., Solution) Structure
REQ-1: Map input data to output data as said by SYSTE
given rules
M
Feedin Transforma Receivi
1.a) g tion ng
Transformation: subsys subsystem subsys
tem tem
REQ-2: Allow repository editing, where “repository” is a SYSTE
collection of data
M
D
1.b) Simple at
editing: a
U ed Data
REQ-3: Automatically control a physical s ito SYSTE repository
object/device e r M
r Control Control
2. Required ling led
behavior: subsys subsys
tem tem
REQ-5: Monitor and display information about SYSTE
an object
M
Monito Monito
3.a) Information ring red
display: subsys subsys
Dis tem tem
REQ-4: Interactively control a physical pla SYSTE
object/device y M
Control Control
3.b) Commanded ling led
behavior: subsys subsys
Oper tem tem