1. INF123 – Software Architecture
Thomas (Debeauvais)

2. 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

3. Software architecture
Components
Connectors
Data
Style
If you follow the constraints
You’ll gain the benefits

4. How Basic tools: the MASC More advanced tools Modularity Abstraction
Separation of Concerns
More advanced tools
Object-oriented paradigm
Domain-specific architectures

5. Non-functional requirements
“The system prints medical records”
Non-functional
“The system prints medical records quickly and confidentially.”

6. Connectors
Allow components to transfer control and data with each other
Aka facilitating control flow and data flow
What is control?
Order in which statements and calls are executed – “you have the hand”

7. Style: Main program and subroutines
Function calls
Subroutine 1
Subroutine 2 …
Subroutine N
Subroutines: no side-effects, and not calling each other.

8. Sequence diagram

9. Distributed system Components run concurrently
Components fail independently
No global clock
Latency
Host 2
Component 3
Host 1
Host 3
Component 1
Component 4
Component 2
Component 5
Network interface of the OS

10. Physical link (copper wire, optic fiber, …)
OSI model: layers
Web browser
Web page
Transparent!
HTTP
HTTP
TCP
TCP IP IP
Physical link (copper wire, optic fiber, …)

11. 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
Fragmentation of big packets
Handled automatically and transparently.
You handle it. Don’t send big packets anyways!
Error checking
Checksum, automatically re-send to fix.
Checksum only. You decide what to do with the mess.
Applications (level 7)
HTTP, FTP
DNS, Voice over IP, FPS games, streaming

12. Constraints Clients initiate the communication
Communication usually over the network
Server has the main functionality
No client-to-client communication
Fat vs thin clients

13. Client-server: pros and cons
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

14. Pipe and filter Constraints: Gains: modularity, reuse, concurrency
Each task runs in its own process
Stream of data passed between tasks
Input/output formats
Gains: modularity, reuse, concurrency
input
simulation/
logic
display

15. 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

16. 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

17. 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

18. Napster Server = bottleneck Server = single point of failure
Content Directory
2) Who has
Gangnam Style?
1) I have
Gangnam Style
3) A has Gangnam Style
Peer A
4) Give me Gangnam Style
Peer B
5) Here is Gangnam Style

19. Flooding in Gnutella Broadcast to discover resources
TTL flag limits flooding
Seeds = reliable list to start

20. Skype
Privacy + Security:
Hard to hack

21. Sensor networks Non-functional properties: Low energy consumption
Fault-tolerance
Scalability

22. Vanilla MVC

23. Reactive MVC

24. Web MVC

25. Pubsub
Eugster 2003: The many faces of publish/subscribe

26. Event broker vs pubsub Event broker = pubsub GUIs With an intermediary
Where subscribers publish
And publishers subscribe
And usually with function callbacks rather than over the network
GUIs

27. Dr. Eval
eval(readline()), eval(message), …

28. Sun RPC generated Hand-written Import function signature
caller.c
interface.h
callee.c
Generate
Call
interface.x
Call
caller_stub.c
callee_stub.c
Generate
Send XDR
Recv XDR
network

29. 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
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><int>41</int></value>
</param>
</params>
</methodCall>
Verbose (SOAP!)
bandwidth

30. Remote Method Invocation
Client Process
Proxy
Object B
Object A
Proxy object is a hollow container of Method names.
Remote Reference Module translates between local and remote object references.
Remote Reference Module
Comm. Module
Server Process
Comm. Module
Remote Reference Module
Dispatcher sends the request to Skeleton Object
Skeleton deserializes parameters, sends it to the object, & marshals the results for return
Dispatcher
Object B
Skeleton
for B’s Class
MIDDLEWARE

31. Service-oriented architecture
Web Server
Client
(Browser)
Web Server
Web Server
Business,
Mashups
Presentation
Web Server

32. Good:
Colorful
Bad:
- Yes goes down, then Yes goes right (be consistent)

33. 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)

34. 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:
sendUnsent has no arrow back: what is happening on the server? Maybe it does not matter …
Bad:
“response” label for the response

35. Metadata vs verbosity
There are two kinds of pain. The sort of pain that makes you strong, or useless pain that is only suffering.

36. SOAP vs REST
SOAP is verbose: large overhead of metadata and boilerplate text
SOAP
REST
<?xml version="1.0"?>
<soap:Envelope xmlns:soap=" soap:encodingStyle="
<soap:body pb="
<pb:GetUserDetails>
<pb:UserID>12345</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>
GET

37. 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

38. Proxy for load balancing: nginx

39. Common security design decisions
Principle Of Least Authority – POLA
Separation of privilege
Complete mediation
Fail-safe defaults
Access control …

40. POLA
Don’t touch it!
Something shiny!

41. Complete mediation Make sure every access is permitted So easy …
Frodo’s path
Access
control
data
Mordor checkpoints

42. Impersonation Bob Alice Bob is reliable and everyone
has a good opinion about Bob
“I am Bob”
Mallory
(malicious)