Software Architecture

Transcription

1 Software Architecture Lecture 5 Call-Return Systems Rob Pettit George Mason University

2 last class data flow data flow styles batch sequential pipe & filter process control! process control! looping structure to control environment variables! batch sequential! sequential processing steps, run to completion! typical of early MIS applications! pipe & filter Unix pipes! incremental transformation of streams Yahoo pipes! Unix pipes and Yahoo pipes are special cases (sub-styles) SWE 443 Software Architecture Call-Return Systems 2

3 Recap data flow data flow systems batch sequential pipe & filter process control Unix pipes Yahoo pipes! Availability of data controls the computation! Structure is determined by the orderly motion of data from component to component It s all about the data SWE 443 Software Architecture Call-Return Systems 3

4 Recap data flow pipe and filter batch sequential pipe & filter process control! Components (filters)! Read input stream (or streams)! Locally transform data! Product output stream (or streams)! Connectors (pipes)! Streams! E.g. Java piped data streams; FIFO buffers! Data processed incrementally as it arrives Unix pipes Yahoo pipes! Output can begin before input fully consumed! Filters must be (relatively) independent! Do not share state (i.e. not synchronized)! Don t know/care about upstream/downstream functionality SWE 443 Software Architecture Call-Return Systems 4

5 Recap data flow pipe and filter batch sequential pipe & filter process control! Strengths! Reuse! Any 2 filters can be connected as long as data format agrees! Ease of maintenance! Filters can be added or replaced! Potential for parallel processing! Filters can execute concurrently no need to wait on complete batch! Weaknesses! End-to-end functionality highly dependent on order of filters! Can be difficult to design incremental filters! Not appropriate for interactive application! Error handling is difficult! Data type often limited to low-level! E.g. byte streams Unix pipes Yahoo pipes SWE 443 Software Architecture Call-Return Systems 5

6 today call-return styles data flow batch sequential dataflow network (pipe & filter) acyclic, fan-out, pipeline, Unix closed loop control call-and-return main program/subroutines information hiding objects stateless client-server SOA interacting processes communicating processes event systems implicit invocation publish-subscribe data-oriented repository transactional databases stateful client-server blackboard modern compiler data-sharing compound documents hypertext Fortran COMMON LW processes hierarchical tiers interpreter N-tiered client-server SWE 443 Software Architecture Call-Return Systems 6

7 outline! call-return styles! single thread/process flavors! main-subroutine, layers, modules, objects! multi thread/process issues! synchronization SWE 443 Software Architecture Call-Return Systems 7

8 in call-return styles consumer components invoke functionality in provider components C call return P! usually the caller waits until an invoked service completes and returns results before continuing! components depend on invoked functionality to get their own work done! the correctness of each component may depend on the correctness of the functionality it invokes SWE 443 Software Architecture Call-Return Systems 8

9 call-return has had many flavors throughout history! subroutines! decomposition of main program into processing steps! functional modules! aggregation of processing steps into modules! abstract data types! bundle operations and data, hide representations and other decisions! objects! sub-typing, polymorphism, dynamic binding of methods! client-server! distribution, tiers! services! late binding of providers SWE 443 Software Architecture Call-Return Systems 9

10 in call-return styles system topology comes in different flavors! client-server! star: clients call servers! clients may register callbacks! tiered! hierarchical star: layer n calls layer n+1! peer-to-peer! no restriction! components define one or more interfaces! provides: a set of functionality that is offered! requires: a set of functionality that others must provide SWE 443 Software Architecture Call-Return Systems 10

11 in call-return styles connectors piggyback control & data! consumers know the identity of providers upon which they rely! control! building block: call! consumer blocks until a request is serviced! complex protocols may be built! example: client initializes server, starts a session, makes repeated requests, closes the session! data flows in 2 ways! parameters: from consumer to provider! return values: from provider to consumer SWE 443 Software Architecture Call-Return Systems 11

12 in call-return styles functional correctness is hierarchical! the correctness of each component may depend on the correctness of the functionality it invokes! leads to a pre/post-condition style of specification! pre = conditions under which a service may be requested! post = the result of having made a service request! binding time of a provider may vary! static = at compile time! example: traditional compilers & ADTs! dynamic = at run time! example: OO method dispatch for class hierarchies! brokered (also at run time)! use broker to find components/service providers SWE 443 Software Architecture Call-Return Systems 12

13 example dynamic binding! object 2D-Shape 2D-Shape Polygon Circle Triangle Square! 2D-Shape defines method Perimeter(): Real! same operation, but implemented differently for Triangle, Square, and Circle! if an object A is of any subtype of 2D-Shape a consumer may call A.Perimeter(), and the appropriate method will be chosen at run-time SWE 443 Software Architecture Call-Return Systems 13

14 outline! call-return styles! single thread/process flavors! main-subroutine, layers, modules, objects! multi thread/process issues! synchronization SWE 443 Software Architecture Call-Return Systems 14

15 main-subroutine flavor fairly unrestricted topology Main controller Sub 1 Sub 2 Sub 3 subroutine method call! frequently single thread of control! one component in the C&C view SWE 443 Software Architecture Call-Return Systems 15

16 main-subroutine flavor subroutines indicate code structure! hierarchical decomposition! based on definition-use relationship! hierarchical reasoning! correctness of a subroutine depends on the correctness of the subroutines it calls! subsystem structure implicit in the hierarchy! in large systems, hierarchy may become spaghetti SWE 443 Software Architecture Call-Return Systems 16

17 layers enforce hierarchy Useful Systems Basic Utility Core Level each layer! provides a set of services to the layers above! encapsulates a set of implementations and lower-level services! relies on services from the layers below Users SWE 443 Software Architecture Call-Return Systems 17

18 modules alternative way to rein in complexity Main controller Sub 1 Sub 2 Sub 3 subroutine method call module SWE 443 Software Architecture Call-Return Systems 18

19 modules are:! (naïve) a piece of code! compilation unit, including interface declarations! (Parnas) a place to encapsulate decisions modules are good for:! management: partition overall development effort! divide and conquer! understanding! divide and conquer! evolution: separation of concerns! changes to one module are isolated from others SWE 443 Software Architecture Call-Return Systems 19

20 in the 70 s, modules turned into Abstract Data Types (ADTs)! good programmers shared an intuition! if you get the manipulation of data structures right, the rest of the program is much simpler.! ADTs contributions:! structure representation bundled with operators! user defined types declarations! information hiding protect internal structure! This routine practice is now part of O-O SWE 443 Software Architecture Call-Return Systems 20

21 in the 80 s, ADTs turned into objects! inheritance! share definitions of functionality! polymorphism/dynamic binding:! determine actual operation to call at run-time! capture families of related designs! inheritance hierarchy! natural mapping to real world or domain! if we understand the domain then we are led to a natural system structure based on the domain! improve understandability, maintainability SWE 443 Software Architecture Call-Return Systems 21

22 objects have limitations:! scalability on the number of object classes! vast numbers of classes requires additional structuring! overall system behavior hard to understand! distributed responsibility for behavior! interaction (sequence) diagrams used in design to mitigate this! hard to capture similarities at the system level! push led to design patterns SWE 443 Software Architecture Call-Return Systems 22

23 outline! call-return styles! single thread/process flavors! main-subroutine, layers, modules, objects! multi thread/process issues! synchronization SWE 443 Software Architecture Call-Return Systems 23

24 Concurrency! Most software architectures make some use of concurrency! Strengths! Separation of concerns! Increased performance! Provide users with ability to perform several tasks in parallel! Weaknesses! Complex synchronization of concurrent tasks! Race conditions, deadlocks, etc.! Must analyze functionality to determine what can be executed in parallel! Limitations on performance improvement SWE 443 Software Architecture Call-Return Systems 24

25 Multi thread/process call-return Multiple processes on a multi-core processor or multiple machines p1 p2 p3 p1 p2 p3 time simultaneous processing t1 t2 t3 Multiple threads in a single OS process executing on a single processor p1 stack t1 data interleaving code t3 stack time concurrent computations (or events) may occur in any order, unless explicit steps are taken to synchronize them SWE 443 Software Architecture Call-Return Systems 25

26 Amdahl s Law! Often used to estimate speedup associated with parallel processing! Performance gain of going from 1 to n processors (or cores) is computed as: 1 (1 p) + p n Where 0 p 1 is the portion of the software that can be parallelized and n 1 is the number of processors or cores SWE 443 Software Architecture Call-Return Systems 26

27 Amdahl s Law Source: Wikipedia SWE 443 Software Architecture Call-Return Systems 27

28 concurrency challenges the predictability of effects P Q P and Q running concurrently a. b. x=0; x=x+2; c. d. x=3; x=x*2; how many possible values for x? SWE 443 Software Architecture Call-Return Systems 28

29 concurrency challenges the predictability of effects P a. x=0; b. x=x+2; Q c. x=3; d. x=x*2; P and Q running concurrently a 0 a 0 a 0 c 3 c 3 c 3 b +2 c 3 c 3 a 0 a 0 d *2 c 3 b +2 d *2 b +2 d *2 a 0 d *2 d *2 b +2 d *2 b +2 b +2 x= SWE 443 Software Architecture Call-Return Systems 29

30 concurrency challenges the predictability of effects P Q R P, Q, and R running concurrently a. b. c. x=0; x=x+2; x=x^2; d. e. f. x=3; x=x*2; x++; g. h. i. X=5; x=x-2; x=x^3; Any guesses on how many possible values? Consider the impact on testing! SWE 443 Software Architecture Call-Return Systems 30

31 monitors are used for explicit synchronization! Monitor provides a synchronized communication! Specific entry condition that is used to guarantee only one process operates on the critical section (data) at a time! Can be queued or single, synchronized buffer More details about threading and monitors in JVM: SWE 443 Software Architecture Call-Return Systems 31

32 example: the parking lot A controller only permits cars to enter when the parking is not full, and does not permit cars to leave when there are no cars in the parking lot. SWE 443 Software Architecture Call-Return Systems 32

33 example: the parking lot start by identifying structure and events! events or actions of interest?! arrival and departure! identify threads/processes! arrivals, departures and CarPark control! define structure and interactions CarPark ARRIVALS arrive CARPARK CONTROL depart DEPARTURES SWE 443 Software Architecture Call-Return Systems 33

34 example: the parking lot synchronization via shared object class Arrivals extends Thread { class Departs extends Thread { } Arrivals(CarParkControl CPC) { } void run() { CPC.arrive(); } } Departs(CarParkControl CPC) { } void run() { CPC.depart(); } class CarParkControl { } CarParkControl( ) { } synchronized void arrive() { } synchronized void depart() { } SWE 443 Software Architecture Call-Return Systems 34

35 example: the parking lot translate the structure into Java class CarParkControl { private int spaces; private int capacity; CarParkControl(int n) {spaces = n; capacity = n;} } synchronized void arrive() { while!(spaces > 0) wait(); --spaces; } synchronized void depart() { while!(spaces < capacity) wait(); ++spaces; } SWE 443 Software Architecture Call-Return Systems 35

36 example: the parking lot insert Java monitor primitives class CarParkControl { private int spaces; private int capacity; CarParkControl(int n) {spaces = n; capacity = n;} Java! provides a wait queue per object! guaranties only one thread at a time obtains the lock } synchronized void arrive() { while!(spaces > 0) wait(); --spaces; } synchronized void depart() { while!(spaces < capacity) wait(); ++spaces; } SWE 443 Software Architecture Call-Return Systems 36

37 example: the parking lot insert Java monitor methods class CarParkControl { private int spaces; private int capacity; CarParkControl(int n) {spaces = n; capacity = n;} java.lang.object.wait()! blocks the executing thread until notified by another thread } synchronized void arrive() { while!(spaces > 0) wait(); --spaces; } synchronized void depart() { while!(spaces < capacity) wait(); ++spaces; } what s missing? SWE 443 Software Architecture Call-Return Systems 37

38 example: the parking lot insert Java monitor methods class CarParkControl { private int spaces; private int capacity; CarParkControl(int n) {spaces = n; capacity = n;} java.lang.object.notify()! unblocks a single thread waiting on this object s queue! the unblocked thread must get the lock } synchronized void arrive() { while!(spaces > 0) wait(); --spaces; notify(); } synchronized void depart() { while!(spaces < capacity) wait(); ++spaces; notify(); } SWE 443 Software Architecture Call-Return Systems 38

39 Putting it all together: the parking lot example class CarParkControl { private int spaces; private int capacity; } CarParkControl(int n) {spaces = n; capacity = n;} synchronized void arrive() { while!(spaces > 0) wait(); --spaces; notify(); } synchronized void depart() { while!(spaces < capacity) wait(); ++spaces; notify(); } class Arrivals extends Thread { Arrivals(CarParkControl CPC) { } void run() { CPC.arrive(); } } class Departs extends Thread { } Departs(CarParkControl CPC) { } void run() { CPC.depart(); } SWE 443 Software Architecture Call-Return Systems 39