INF123 – Software Architecture
INF 123 – Software Architecture
Thomas (Debeauvais)
tdebeauv@uci.edu
1
Software Architecture
• The set of most important design decisions
• “Most important”
– According to the stakeholders
• “Design decisions”
– Aware of the options
– Also called constraints
– More than just the code structure
– Elegant
2
Software architecture
• Components
• Connectors
• Data
• Style
– If you follow the constraints
– You’ll gain the benefits
3
How
• Basic tools: the MASC
– Modularity
– Abstraction
– Separation of Concerns
• More advanced tools
– Object-oriented paradigm
– Domain-specific architectures
4
Non-functional requirements
• Functional
– “The system prints medical records”
• Non-functional
– “The system prints medical records quickly and
confidentially.”
5
Connectors
• Allow components to transfer control and
data with each other
• Aka facilitating control flow and data flow
What is control?
6
Style: Main program and subroutines
main
Function calls
Subroutine 1
Subroutine 2
…
Subroutine N
Subroutines: no side-effects, and not calling each other.
7
Sequence diagram
8
Distributed system
•
•
•
•
Components run concurrently
Components fail independently
No global clock Host 2
Latency
Component 3
Component 1
Component 4
Host 1
Host 3
Component 2
Component 5
Network interface of the OS
9
OSI model: layers
Web browser
Web page
Transparent!
HTTP
HTTP
TCP
TCP
IP
IP
Physical link (copper wire, optic fiber, …)
10
TCP vs UDP
TCP
UDP
Connection
Yes. 3-packet handshake
(SYN/SYN-ACK/ACK)
Connectionless, Fire-and-forget
Reliability
By re-sending
None
Ordering
Through the sequence number
No. Packets can pass each other.
Congestion
control
Slow start, congestion
avoidance, fast retransmit
None
Fragmentation
of big packets
Handled automatically and
transparently.
You handle it. Don’t send big
packets anyways!
Error checking
Checksum, automatically resend to fix.
Checksum only. You decide what
to do with the mess.
Applications
(level 7)
HTTP, FTP
DNS, Voice over IP, FPS games,
streaming
11
Constraints
•
•
•
•
Clients initiate the communication
Communication usually over the network
Server has the main functionality
No client-to-client communication
• Fat vs thin clients
12
Client-server: pros and cons
• Pros
– Computation and data collocated
– Server = single authority, trusted
– Ignore bad clients without affecting good clients
• Cons
– Server = single point of failure
– Server can be a bottleneck
13
Pipe and filter
• Constraints:
– Each task runs in its own process
– Stream of data passed between tasks
• Input/output formats
• Gains: modularity, reuse, concurrency
input
simulation/
logic
display
14
Describing a Software Architecture
• “Just look at the source code!”
• Natural language
– Easy to discuss and contract-like, but long to read
• XML, JSON
– Good for hierarchical structures, but hard to read
• Images/screenshots
– Good for usability arch, not for system or deploy
• Box-and-arrow diagrams
– Back and forth with XML/JSON
15
Your own diagrams
•
•
•
•
Use the same symbol for the same things
Use standard symbols and representations
Don’t use the same symbol for different things
Add a legend if needed
Client 1
Client 2
Send position
Has a 2-way connection
server
16
p2p
• Each peer is client and server to other peers
• The topology can change
• Pros
– Scaling: each node provides CPU and storage
– Robust if one node fails
• Cons
– Complex protocols for resource discovery
– Security, trust management
17
Napster
Content
Directory
1) I have
Gangnam Style
Peer A
2) Who has
Gangnam Style?
4) Give me Gangnam Style
5) Here is Gangnam Style
Server = bottleneck
Server = single point of failure
3) A has Gangnam Style
Peer B
18
Flooding in Gnutella
Broadcast to discover resources
TTL flag limits flooding
Seeds = reliable list to start
19
Skype
Privacy + Security:
Hard to hack
20
Sensor networks
Non-functional properties:
Low energy consumption
Fault-tolerance
Scalability
21
Vanilla MVC
22
Reactive MVC
23
Web MVC
24
Pubsub
Eugster 2003: The many faces of publish/subscribe
25
Event broker vs pubsub
• Event broker = pubsub
– With an intermediary
– Where subscribers publish
– And publishers subscribe
– And usually with function callbacks rather than
over the network
• GUIs
26
Dr. Eval
eval(readline()), eval(message), …
27
generated
Sun RPC
caller.c
Import
function
signature
interface.h
Import
function
signature
Hand-written
callee.c
Generate
Call
caller_stub.c
interface.x
Generate
Send XDR
Call
callee_stub.c
Recv XDR
network
28
XML RPC - request
POST /RPC2 HTTP/1.1
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181
Verbose (SOAP!)
bandwidth
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><int>41</int></value>
</param>
</params>
</methodCall>
29
Remote Method Invocation
Client
Process
Object A
Proxy
Object
B
Remote
Reference
Module
Remote Reference
Module translates
between local and remote
object references.
Comm.
Module
Server
Process
Comm.
Module
Remote
Reference
Module
Dispatcher
Skeleton
for B’s
Class
Proxy object is a hollow
container of Method
names.
Object
B
Dispatcher sends the
request to Skeleton
Object
Skeleton deserializes
parameters, sends it to
the object, & marshals
the results for return
MIDDLEWARE
http://courses.engr.illinois.edu/cs425/fa2012/L8.fa12.ppt
30
Service-oriented architecture
Web Server
Client
(Browser)
Presentation
Web Server
Web Server
Business,
Mashups
Web Server
31
Good:
- Colorful
Bad:
- Yes goes down, then Yes
goes right (be consistent)
32
Good:
- Transition labels are verbs (“Coin” should be “insert coin”)
- States are participles (“locked”, “unlocked”)
- Verb+ing is fine too! (e.g. “waiting for user input”)
- States are circles
- No end state: don’t need any in this case
- Start state is obvious (nitpicking: convention is double circle)
33
Good:
- Server lifeline starts at the same
time as the computer’s
- The server lifeline is active only
when the server works
- Dotted arrow for the response
OK/meh:
- sendUnsentEmail has no arrow
back: what is happening on the
server? Maybe it does not
matter …
Bad:
- “response” label for the
response
34
Metadata vs verbosity
There are two kinds of pain. The sort of pain that makes you
strong, or useless pain that is only suffering.
35
SOAP vs REST
• SOAP is verbose: large overhead of metadata and
boilerplate text
• SOAP
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:body pb="http://www.acme.com/phonebook">
<pb:GetUserDetails>
<pb:UserID>12345</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>
• REST
GET http://www.acme.com/phonebook/UserDetails/12345
36
REST is made of several styles
•
•
•
•
•
•
Client-Server
Stateless
Cache
Layered
Code on demand
Uniform Interface
• These styles are not always inter-compatible
• But they are in the case of the WWW
37
Proxy for load balancing: nginx
38
Common security design decisions
•
•
•
•
•
•
Principle Of Least Authority – POLA
Separation of privilege
Complete mediation
Fail-safe defaults
Access control
…
39
POLA
Don’t touch it!
Something shiny!
40
Complete mediation
• Make sure every access is permitted
So easy …
Frodo’s path
Access
control
data
Mordor checkpoints
41
Impersonation
Bob
Alice
Bob is reliable and everyone
has a good opinion about Bob
“I am Bob”
Mallory
(malicious)
42