6. Architectural styles

Transkriptio

1 6. Architectural styles 6.1 Decomposition architectures - Layered architectures - Pipes-and-filters architectures 6.2 Service-based architectures - Client-server architectures - Message dispatcher architectures 6.3 Architectures related to application type - MVC architectures - Repository architectures - Interpreter architectures 1

2 Layered architectures Layered architecture: organization of a software system consisting of layers at rising levels of abstraction. Hardware Application, human layers 2

3 Hierarchy and bridging Bridging Hierarchy breach 3

4 Application orientedness Callbacks in a layered architecture Application layer normal service call callback Platform layer Must not make a lower layer dependent of an upper layer! 4

5 Describing layered architectures Non-bridging Bridging Bridging 5

6 Interfaces of layers Layer A Comp1 Comp2 Comp3 Layer B Comp4 Comp5 Comp6 6

7 Example: business application User interface Application logic Domain logic Database 7

8 Layered architecture can be multi-dimensional Core GUI Default GUI App GUI GUI Logical dimension Core Logic Default Logic App Logic Logic Core Support Default Support App Support Support 8

9 Layered architecture can be multi-dimensional Core GUI Default GUI App GUI Core Logic Default Logic App Logic Core Support Default Support App Support Specialization dimension Core Default App 9

10 row depends on col Layer dependency analysis P1 P2 P3 P4 P5 P1 X X P2 X X P3 X X P1 P2 P3 P4 P5 OK, bridging degree = 2 P4 X P5 10

11 row depends on col Layer dependency analysis P1 P2 P3 P4 P5 P1 X X P2 X Not OK, what to do? P1 P2 P3 P4 P5 P3 X X X P4 X P5 Exchange the places of P2 and P3 11

12 Designing a layered architecture Define the criteria for layer division Determine the layers, their names and rough responsibilities Define the provided & required interfaces of layers Make sure that the provided and required interfaces match Divide each layer into major components and specify their communication Make sure that a lower layer does not depend on an upper one Refine the layer division if needed Make sure that an upper layer does not depend on the implementation of a lower one Design exception handling 12

13 Harjoitus Suunnittele kerrosarkkitehtuuri seikkailupelille. Järjestelmään kuuluvat seuraavat osat: - Yleinen seikkailupelilogiikka (AL) - Tietokanta (DB) - Pelikäyttöliittymä (GUI) - Graafinen tuki seikkailupeleille (GS) - Pelitietokantapalvelut (GB) - Pelin logiikka (GL) - Yleinen graafinen kirjasto (G) Sijoita nämä osat kerroksiin. 13

14 Kuinka monella on jotain tämännt nnäköistä? GL AL GB DB GUI GS G - Yleinen seikkailupelilogiikka (AL) - Tietokanta (DB) - Pelikäyttöliittymä (GUI) - Graafinen tuki seikkailupeleille (GS) - Pelitietokantapalvelut (GB) - Pelin logiikka (GL) - Yleinen graafinen kirjasto (G) 14

15 Benefits and problems of layered architectures Benefits Nearly always applicable Supports the understanding and management of a system Understandable for various stakeholders (management, client, etc.) Reduces dependencies between software units Developers, testers, maintainers can concentrate on a particular layer Supports maintenance and modifiability Supports reuse Problems Efficiency costs Unnecessary work Difficulty to obtain appropriate granularity of layers Exception handling 15

16 Pipes-and and-filters architectures Pipes-and-filters architecture consists of subsystems that consume and produce data (filters), and of connectors which transmit the output of one subsystem to the input port of another subsystem (pipes). filter pipe filter pipe filter pipe pipe filter pipe filter 16

17 Requirements Filters are independent units (do not share state) Filters do not know the other filters Filters process their input incrementally, in one pass 17

18 Special case: Pipeline pipe pipe filter filter filter 18

19 Implementing control: push approach Source Filter1 Filter2 Sink push(data) process push(data) process push(data) push(data) process 19

20 Implementing control: pull approach Source Filter1 Filter2 Sink pull data pull pull process data process data pull 20

21 Buffered connections for concurrent filters Buffer filter filter Optimal time determined by the slowest filter The sizes of buffers are critical The data structure of a buffer can be a queue or more complicated 21

22 Example: a compiler Scanner Parser Semantic analyzer & code generator ascii symbols tokens syntax tree code passing syntax tree in small pieces may be inefficient conventional solution in one-pass compiler: make parser a main program calling scanner and code generator when needed global symbol table usually needed 22

23 Example: a sound processing system Loader Processing unit... Loud speakers 23

24 Benefits and problems of pipes-and and-filters Benefits: Complex processing can be understood as a combination of simpler filters Support for reuse: filters can be combined in various ways Support for maintenance: filters can be easily changed Support for concurrent execution Problems: Inappropriate for interactive systems Possible additional cost in interpreting data Error handling may be problematic Sharing state between filters problematic 24

25 Client-server architectures Client-server architecture: organization of a software system consisting of providers of service (server) and users of service (client). server1 server2 client1 client2 client3 25

26 Clients and servers Clients typically know the servers and their logical services do not know about each other are separate applications start and end a session are active Servers typically manage some resource hide technical aspects of the resource do not know about each other do not know the clients have their own thread 26

27 Examples Symbian OS communications architecture (non-distributed) Many data repository systems (distributed or non-distributed) Many business systems (distributed) 27

28 Benefits and problems of client-server architectures Benefits Supports the understanding and management of resource-oriented systems Reduces dependencies in the system Supports maintenance and modifiability Straightforward distribution when necessary Facilitates mutual exclusion Problems Efficiency costs Exception handling Clients depend on a particular server 28

29 Message dispatcher architectures Problem: A lot of (possibly concurrent) components communicating with each other Unknown, changing number and types of components Unknown, changing type of information 29

30 Message dispatcher architecture registered components create a message Common interface for components: receive(message) registered components identify and notify Message interpret and act 30

31 Message dispatcher architecture defines: Components Message types Message-operation binding Component & message type registration policy Message delivery policy Concurrency model 31

32 Example: Service monitoring system engine CU brake gear CAN bus (Controller Area Network) 32

33 Service monitoring system CANBusExaminer Messenger ServiceComponent receive(msg) MessageDispatcher send(msg) register(msgtype,component) BrakeUnit recordusage checkcondition getstate() setstate() EngineUnit recordusage checkcondition getstate() setstate() 33

34 CANBus SourceHandler MessageDispatcher XMLMsg Service- Messenger Msg type(): MsgType ServiceComponent receive(msg) send(msg) register(msgtype,component) BrakeModelIF BrakeViewIF update() Brake- View BrakeController handleevent(event) BrakeModel recordusage checkcondition register(view) getstate() setstate() DB 34

35 Benefits and problems of message dispatcher architectures Benefits: Easy to add new (kinds of) components, even at run time Easy to remove components, even at run time Flexible system configuration Easy to extend or modify functionality: no need to change interfaces Can support both asynchronous and synchronous message passing Tolerates unreceived messages Can be used to distribute exception messages as well Problems: Potential performance problem: message creation & interpretation (e.g. XML) Contents of services not visible in the interface 35

36 Class exercise Topology Linear Centralized Interfaces Servicebased Generic Fill in architectural style 36

37 Model-View View-Controller (MVC) architectures An architecture for interactive systems separating the user interface from the logical aspects of a system. Motivation: There should be support for different views of the same information User interface should reflect changes of the system state immediately It should be easy to change user interface It should be easy to port the system to another GUI platform 37

38 Responsibilities Model Provides logical functions & data of the application Registers interested views and controllers Notifies registered parties about interesting changes of the state of the model View Takes care of displaying (updated) model information Controller Accepts input from the user Transforms user events to requests for model or display services 38

39 MVC pattern Observer Model update() * update() attach(observer) detach(observer) notify() getdata() service() attach() getdata() View initialize(model) makecontroller() activate() display() update() Controller initialize(model,view) handleevent() update() attach() service() 39

40 MVC interaction Controller Model View handle- Event service notify update display getdata update getdata 40

41 Layered version of MVC GUI View controller.insertpressed(data) User requests model.add(data) newdata = model.getdata() view.showresult(newdata) Action requests Controller Application logic Model Domain logic Show results Provide results 41

42 Benefits and problems of MVC Benefits Multiple views of the same model Synchronized views Pluggable views and controllers Exchangable look and feel Natural core of a GUI framework Problems Increased complexity Potentially many updates Potentially inefficient model data access 42

43 actors Special case of client-server: Repository architectures access & modify data access & modify data actors Data Data repository (shared data) 43

44 Examples Programming environments (non-distributed) (common repository: internal program representation) Publication environments (non-distributed) (common repository: internal text representation) Many business systems (distributed) (common repository: various business information) 44

45 Benefits and problems of repository architectures Advantages: Concurrent actors possible (assuming locking policies) Actors operate on consistent data Actors do not depend on each other Easy to add new actors Problems: Potential performance problems (data interpretation for each actor, actors may reserve large parts of repository) Changing the repository API/schema very risky Repository API/schema may not be optimal for every actor 45

46 Interpreter architectures need to give functional descriptions as input need to combine some primitive operations in various ways that are not foreseen need to separate the logical execution platform from the actual one (e.g. to facilitate changing the latter) 46

47 Interpreter architectures Output Some description of a functionality (ascii, table, XML, internal representation) Interpreter Execution platform User Language specification Input 47

48 Interpretation as an abstraction of execution interface Abstract execution description Interpreter Concrete execution platform Example: DBMS Application SQL SQL interpreter DB 48

49 Examples of interpreted descriptions Table-driven systems State machine -driven systems Scripting systems XML-based interpretation systems Virtual machines 49

50 Designing interpretation: Interpreter design pattern for processing languages How to present interpreted programs with recursive language structures? Interpreter AbstractStruct interpret(rep) * TerminalStruct interpret(rep) CompositeStruct interpret(rep) 50

51 Deriving an architectural solution for presenting interpreted language structures Problem: How to map language structures to classes? For example: Script ::= "SCRIPT" Action {";" Action} "END" Action ::= CondAction PrimAction CondAction ::= "IF" Expr "THEN" Action "END" PrimAction ::= identifier "(" Expr ")" (call of some primitive oper) Expr ::=... How to map this grammar into classes with interpretation capability? 51

52 Nonterminals and structural terminals are natural candidates for classes Nonterminals ("välisymboli") and significant terminals: Script, Action, PrimAction, CondAction, Expr, identifier => classes Non-structural terminals ("loppusymboli"): SCRIPT END IF THEN ; ( ) Non-significant terminals needed only for parsing i.e. for creating the interpreted object structure => ignore 52

53 What does a production rule mean from the class viewpoint? View 1: Production rule means that the left-hand side class has the right-hand side classes as its parts: A ::= B C means: OK, but how about A ::= B C D E? A 1 1 B C 0..1 D A 0..1 E B C Not a good solution... 53

54 Alternative structures = subclasses A ::= B C D E => A ::= A1 A2 A1 ::= B C A2 ::= D E A A1 A2 B C D E 54

55 Script Example interpret() Action * interpret() 1 CondAction PrimAction Expr interpret() interpret() 1 1 val(): float 1 Identifier name(): String 55

56 Benefits and problems of interpreters Benefits: Flexibility - "poor-man's reflection" Interpreted language can be easily changed Interpretation can be easily changed Execution environment can be changed Problems: Potential performance problem: construction of the internal representation Potential performance problem: indirect, non-native execution Potential space problem: large internal representations of the interpreted program 56