LECTURE 6: Software Architecture

Ivan Marsic
Rutgers University
 Topics

 Software Architecture Definition

 Architectural Decisions & Key Concerns

 Architecture Styles

 Documenting Architecture: Views

 Problem Structure vs. Solution Structure

2
 Hierarchical Organization of Software
Product line (or product family) highest abstraction level

System or product

Subsystems/Modules

Packages

Classes/Objects

Methods lowest 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?
3
But first, why do we want to decompose systems?
 Why We Want To
Decompose 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

4
 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”)

5
 Example Architectural Decisions

Example decisions:
Safe Home Access System

Subsystem Subsystem Subsystem

Decision on system
for device for for remote
control administration data access decomposition

On embedded On office On user’s Decision on mapping

computer desktop smartphone software-to-hardware
(…and Web?)

Decision on development
platform or operating system
(Android vs. iOS, etc.)

Decision on how to fit

the subsystems together
(“architecture style”)
Such decisions are made early on,
perhaps while discussing the requirements with the customer
to decide which hardware devices will be used for user interaction and device control
6
 Architectural Decisions
—A matter of scope
product line
product or system architecture decisions
architecture decisions
systemic impact
Product line scope

Product/system A scope Product B scope

Subsystem scope
local impact
Class scope

• 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 strategy 7
 Software Architecture
Key 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 of
well-known solutions that are proven to work for similar
problems

8
 Architectural Decisions Often Involve
Compromise
 The “best” design for a component considered in isolation
may not be chosen when components considered together
or
within 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, …

9
 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

10
 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

11
 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
12
 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)
Development platform (e.g.,
 Layered (or Multi-Tiered) Web vs. mobile app, etc.)
may dictate the architecture
 Peer-to-Peer style or vice versa…

 Microservices
13
Real System is a Combination of Styles

Subsystem
Central Repository
for device Architecture Style
control

Subsystem
for remote
data access

- Valid keys
- Access history
Subsystem for - Tenant profiles
administration -…

Application Web
Web server
server browser

Tiered Architecture Style

14
 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
15
 Connectors: HTTP Protocol
Client Request Message
Client GET /index.html HTTP 1.1
Server
Host: caip.rutgers.edu
Accept: image/gif, image/x-xbitmap, image/
jpeg, image pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible, MSIE
5.01; Windows NT)
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Thu, 23 Feb 2006 21:03:56 GMT
Server: Apache/2.0.48 (Unix) DAV/2 PHP/4.3.9
Last-Modified: Thu, 18 Nov 2004 16:40:02 GMT
ETag: "1689-10a0-aab5c80"
Accept-Ranges: bytes
Content-Length: 4256
Content-Type: text/html; charset=ISO-8859-1
Time Connection: close

<HTML>
<HEAD>
<TITLE>CAIP Center-Rutgers University</TITLE>
</HEAD>

Server Response Message

 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
16
 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, availability)
payment (time, date, amount, confirmation number) 17
 Architecture Style: Pipe-and-Filter

 Components: Filters transform input into output

 Connectors: Pipe data streams
 Example: UNIX shell commands
User

Filter Filter Filter

Pipe Pipe

 More complex configurations:

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

Pipe Pipe Pipe

Filter Filter
Filter
Pipe Pipe
Pipe
Pipe Pipe Filter Filter
Pipe
Filter Filter
Pipe Pipe 18
 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

19
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 20
 REST: Hypermedia as the Engine of
Application State (HATEOAS)
REST: Representational state transfer

Conceptual model: hypermedia as the engine of application state (HATEOAS)

REST Client REST Server

Hypermedia representation
(webpage) of State S2 URI(S4)
HTTP Request State S4

… text link<S3> text State S2

image link<S4> text URI(S2)
URI(S2) State SN
text text image
link<S5> text … Hypermedia representation URI(S5)
(webpage) of State S5 URI(S3)
State S1 URI(S5)
… text text text
text link<S3>
text … URI(S3) State S5
State S3
State transition
HTTP GET URI(S5) URI(S3)
State transition HTTP Response
HTTP GET URI(S3)

21
 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”). 22
 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

23
 RESTful Resource Naming
(a) Conceptual representation of creating a new employee record

CRUD operation Resource name Input arguments

(verb) (noun)

c re a te e mp lo ye e s { na me , ro le , s a la ry }
 John Doe waiter 1000
Client Request Message Resource URI
(a) (noun)

POST /employees/ HTTP 1.1

Host: www.restaurant.com
...
HTTP method Content-Type: application/x-www-form-urlencoded
(verb) Content-Length: 45

name=John%20Doe&role=waiter&salary=1000
(b)

(b) HTTP request message carrying the content of the HTML form that was used
to enter the employee data
24
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

25
 RESTful API Design versus
JSON-RPC APIs over HTTP
RESTful APIs JSON-RPC APIs over HTTP
URIs for resource addresses URIs for object addresses
Focus on navigable resources (nouns) Focus on data-processing procedures (verbs)
Application logic runs on the client; the server
HATEOAS, application logic runs on
manages the data using CRUD and application-
the server
specific RPCs
HTTP methods for resource CRUD HTTP methods for service actions, plus
actions, plus media-specific server- application-specific server-side procedures
side controllers activated by the media explicitly addressed with the verb as part of the
type request message URI
Message body can be any standard
media format, as negotiated by clients Message body encoded as JSON objects
and servers
No code in response messages—only JSON
Code-on-demand
objects
Caching and replication of resource Caching and replication not relevant for
content procedures

26
 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=15
877514320&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=CjwKCAiAyrXiBRAjEiwATI95mcKyoLfTjKFAa
CiElWKC3Vt51nTPk0Fxyt9rm8S0Y99Dikidu_DQrxoC2CwQAvD_B
wE

27
 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
display
5. I need your state (to display)

View
4. I have changed

3. Change your display Model

1. The user did something

user Controller 2. Change your state

input device 28
 Model-View-Controller
User Interface
Model
Controller
Input Domain
Event Domain
device model
Interpreter Model
events action

Notification
Visual feedback
Model about the
User of the altered
Visualizer effects of the
model
action

View
31
26 14
Model: array of numbers [ 14, 26, 31 ] 14 31
versus
26
 Different Views for the same Model: 29
 Problem Structure
REQ1, REQ2,
REQ3 REQ3, REQ4
PROBLEM DOMAIN

(5) Device
(6) Photosensor
preferences
(7) Light
Subsystem-2
(3) Key

(1) Tenant (4) List of

Subsystem-1
valid keys
(3) Lock

REQ4
Subsystem-3 (8) Alarm bell (11) Log of
accesses
Software-to-be

(2) Landlord
(10) Tenant
Subsystem-4 (9) Desktop computer accounts

REQ5, REQ7,
REQ8, REQ9

Subsystems derived from the requirements (“bottom-up” approach or induction) 30

 Typical Software Eng. Problems
1.a) System transforms input document to output document
1. User works with computer system
(problem domain is “virtual”, not physical) REQ-1: Map input data to output IN doc
data as said by given rules
User System OUT doc

1.b) User edits information stored in a repository

User System Problem domain

REQ-2: Allow repository editing, where

“repository” is a collection of data
User System Repository

2. Computer system controls the (physical) problem domain

(user not involved) REQ-3: Autonomously
control a physical
object/device
User System Problem domain

3. Computer system intermediates between 3.a) System observes the problem domain and displays information
the user and the problem domain
REQ-5: Monitor and display
information about an object
User System Problem domain

User System Problem domain 3.b) System controls the problem domain as commanded by the user

REQ-4: Interactively control

a physical object/device 31
User System Problem domain
 5-dimensional Problem Space
 The five elementary problem types
represent the coordinate system of the
(“Simple workpieces”)

Software
problem problem space
Simple editing
(“Required behavior”)

n
io
Autonomous control

to solve

at
 The “axis” projections represent the
rm
fo
ns
degree to which the whole problem
tra
a

contains a subproblem of this type

at
D

 Each subproblem can be analyzed

independently and eventually
(“C recombined into the whole problem
o mm Ma
and n ua
ed l
beh contr
 The structure of the solution should be
lay
atio
nd
isp a vi o l
or”
)
selected to fit the problem structure
o rm
I nf

32
 Software (i.e., Solution) Structure
REQ-1: Map input data to output data as said by given rules SYSTEM

Feeding Transformation Receiving

1.a) Transformation: subsyste subsystem subsystem
m

REQ-2: Allow repository editing, where “repository” is a collection of data SYSTEM

Data
1.b) Simple editing: editor
User Data repository
REQ-3: Automatically control a physical object/device SYSTEM

Controlling Controlled
2. Required behavior: subsystem subsystem

REQ-5: Monitor and display information about an object SYSTEM

Monitoring Monitored
3.a) Information display: subsystem subsystem
Display
REQ-4: Interactively control a physical object/device SYSTEM

Controlling Controlled
3.b) Commanded behavior: subsystem subsystem
33
Operator