1

ConnectorsStyle: Main program and subroutines

INF 123 – Software architecturetdebeauv@uci.edu

2

Outline

• Some theory• Connector 1: Procedure call • Style: Main program and subroutines• Connector 2: Socket

3

SOME THEORY

4

Connector

• Architectural element in charge of the interactions among components

• Connector in implementations– No dedicated code – Scattered across modules

• Connector in architectures– Its own spec– To distinguish computations from interactions

5

Connectors

• Allow components to transfer control and data with each other

• Aka facilitating control flow and data flow

What is control?

6

Connectors

• “The guards at the gate of separation of concerns”

• Often domain-agnostic: the how, not the whatI protect that which matters most

7

Connectors

• Can be super smart and complex• E.g. order, filter, combine, or discard messages

I am a trafficker of information

8

4 interaction roles

• Communication– Transfer of data– Message passing

• Coordination– Transfer of control– Function calls

• Conversion– Translation– Wrapping

• Facilitation– Load-balancing– Locks

9

Connector examples vs concerns• Procedure call• Method call• Event broker• Pubsub• Interrupts• Socket• Load balancer• DB driver• SSH Tunnel• …

• Best effort vs exactly once vs reliable

• Encrypted vs cleartext• Uni/multi/broadcast• Static vs dynamic linkage• Serialization (JSON, XML,

binary)• Stateless vs stateful• Sync vs asynchronous• …

10

PROCEDURE CALL

11

Procedure call

• Communication role– Arguments, return values

• Coordination role– Control flow

• The most basic connector– “The Assembly language of sw interaction”

12

Examples

• Subroutines – Architectural style: Main program and subroutine

• Object-oriented methods• UNIX fork and exec• OS calls (open, read, write, poll, …)• Callbacks

• Basis for Remote Procedure Call

13

STYLE: MAIN PROGRAM AND SUBROUTINES

14

Style: Main program and subroutines

• Break down a long program into 1 main and N subroutines

• Subroutines– Self-contained

• No side-effects• Independent of each other

– Functionally meaningful and substantial• Good: detect_and_execute_collisions(me, enemies, walls)

returns True if the game is over• Bad: add_one_to_score(score) returns score+1

15

Style: Main program and subroutines

main

Subroutine 1 Subroutine 2 Subroutine N…

Function calls

16

Easy to follow the control flow

main

Subroutine 1 Subroutine 2 Subroutine N…

17

Style: Main program and subroutines

while keep_going:

keep_going, direction = process_input(direction) mybox = move(mybox, direction) if collide(mybox, borders): mybox, direction = create_box(dims) mybox, pellets = eat_colliding_pellet(mybox, pellets, dims) draw_everything(screen, mybox, pellets, borders) clock.tick(50)

18

Style: Main program and subroutines

game loop

process_input move draw_everything…

Function calls

Only these functions involve Pygame

19

Same loop, but replace Pygame display

20

IP SOCKETS

21

Socket

• Endpoint of inter-process communication across the network

• Most follow Internet Protocol (IP)• BSD standard IP socket API– Constructor, bind, listen, connect, accept, send, recv, close,

setsockopt, …– poll, select, epoll, or kqueue to know the socket state (is

there data to recv? The other end hung up?)• Client-server paradigm

22

Client-server paradigm

• Server socket bind() and listen()• Server poll() its sockets periodically• Client socket connect()• Client poll() its socket periodically• Server socket accept()– Creates a new socket for that client connection

• Both sockets send() and recv()• One socket close()• The other’s poll() will notify the closure

23

Client-server

• The client contacts the server• The server can’t pull a client in!– Neo must sit to connect

24

Sequence diagram

25

IP sockets in Python

• http://docs.python.org/2/howto/sockets.html• http://docs.python.org/2/library/socket.html